Sometimes, when dealing with custom HL7 segments the correct FHIR resource for the segment differs
depending upon some value in the segment. For example, in our ZAL custom Alert segment field ZAL.2.1 denotes the Alert Category, and when the value is one of A1, A3, H2 or H4 then the correct FHIR resource is AllergyIntolerance; for all other
alert category values the correct FHIR resource is Flag
Two resources template entries with suitable condition expressions will direct each ZAL segment to its correct resource template.
resources:
- resourceName: AllergyIntolerance
segment: ZAL
resourcePath: resource/AllergyIntoleranceZAL
repeats: true
condition: ZAL.2.1 IN [A1, A3, H2, H4] ## Some of our custom ZAL segments are AllergyIntolerance
additionalSegments:
- resourceName: Flag
segment: ZAL
resourcePath: resource/FlagZAL
repeats: true
condition: ZAL.2.1 NOT_IN [A1, A3, H2, H4] ## The rest of our custom ZAL segments are more general alert Flags
additionalSegments:
The tricky bits are:
Existing expressions don't have IN and NOT_IN operators, and we really do need it for this kind of condition
Condition will be evaluated outside of the context of any ResourceTemplate so there will be no vars or constants available either.
Hl7SpecificationParser needed to be fixed to allow custom segments (beginning with Z) to be correctly handled when parsing field specification.
Sometimes, when dealing with custom HL7 segments the correct FHIR resource for the segment differs depending upon some value in the segment. For example, in our ZAL custom Alert segment field ZAL.2.1 denotes the Alert Category, and when the value is one of A1, A3, H2 or H4 then the correct FHIR resource is AllergyIntolerance; for all other alert category values the correct FHIR resource is Flag
Two resources template entries with suitable condition expressions will direct each ZAL segment to its correct resource template.
The tricky bits are:
varsorconstantsavailable either.Z) to be correctly handled when parsing field specification.