Patches in tarmedValidator100 build 1.00.125
using Tarmed 1.09/1.08.2


Below is a list of all patches included to the tarmedValidator100 build 1.00.125, that can be used to change the default runtime behavior of the validator. The patches are mostly for gathering additional and/or advanced information, a few change runtime behavior itself.

Apart from the patches, tarmedValidator100 build 1.00.125 further manages and operates two Tarmed versions in parallel, namely Tarmed 1.08.2 for social insurance cases and Tarmed 1.09 for KV | VV cases. The use of whatever version is based effectively on the supplied law in ITarmedInput::SetTreatment(). It is thus extremely important to set all data of the auxiliary interface ITarmedInput at the very beginning of a Tarmed session.


List of patches of tarmedValidator build 1.00.125:

  • IUtility::Expand("aCode#noTimeLimit", ...): the appended instruction "#noTimeLimit" performs a full expansion without obeying any time restrictions or limits. A suchwise generated expansion of a service chain might of course provoke validation errors and then generates messages about the violation of the quantity limit! The newly built-in time restrictions of Tarmed 1.09 are thus made "visible" and the over time is not silently discarded.
     
  • ISearch::GetAgeRestriction(dDaysFrom, dDaysTo): with the introduction of Tarmed 1.09, the negation of laying inside an age interval has been introduced ("younger than a certain age or older than another age").
    In a formal notation:
  • age x ∈ [limit_a, limit_b] means that x is inside the interval
  • age x ∈ not [limit_a, limit_b] means that x is outside the interval.
  • For example, the notation not [6a, 75a] logically implies that the patient's age must be less than 6 years or greater than 75 years.
     
    The negation of the age interval is expressed in GetAgeRestriction(dDaysFrom, dDaysTo) by the fact that dDaysFrom > dDaysTo and thus must be interpreted accordingly!
     
  • ISearch::FindDescendant("aCode#no123TypeServices",...) / ISearch::FindNextDescendant(...): when appending the instruction "#no123TypeServices" to bstrCode the space of descendent services is qualified, services of the type 123 aka "First-Next-Last" are filtered out from the result space and thus are neglected by the iterator pair.
     
  • ICatalog::GetFirstChapter("aCode#INFO",...) / ICatalog::GetNextChapter(...): the appended instruction "#INFO" does return chapter interpretations instead of chapter codes and names, where the interpretation title is returned in bstrCode and interpretation text is returned in bstrName.
     
  • With the introduction of Tarmed 1.09, the qualitative dignities have been supplemented by the aspect/qualification of "is FMH Specialist".
    ICatalog::GetFirstQualitativeDignity("aCode#FMH",...) / ICatalog::GetNextQualitativeDignity(...): the bstrCode appended instruction "#FMH" allows to retrieve a tag either "#FMH0" or "#FMH1" appended to the variable pbstrCode. The meaning of the tags is as follows:
    • #FMH0 == dignity is not a "FMH Specialist" dignity
    • #FMH1 == dignity is a "FMH Specialist" dignity

  • "Practical Physician" vs. "FMH Specialist": The self-declaration of the dignities controls the selection of available services. With the introduction of Tarmed 1.09, the medical TP is also affected, insofar as in the case of the dignity 3000 aka "Practical Physician" a TP reduction is automatically performed by means of the internal scaling factor. Whilst the addition of dignities enlarges to the spectrum of available services, there is a hierarchical approach regarding the TP reduction! The addition of any "FMH Specialist" dignity (cf. above) outdo the "Practical Physician" dignity and turns off the TP reduction!
     
    ITarmedInput::AddDignity(...,"3000#IMPORTANT", ...): when appending the instruction "#IMPORTANT" to the dignity 3000 aka "Practical Physician" the rather esoteric situation "performance spectrum of a FMH Specialist with TP reduction of a Practical Physician" can be realized. The "3000#IMPORTANT" switch ensures that other dignities of type "FMH Specialist" does not invalidate the TP reduction!