search

Aidbox / Issues

Issue tracker for Aidbox FHIR backend by Health Samurai
7 stars 0 forks source link

I need help with parsing HL7v2 message with repeatable segments: ZXC, ZTA #565

Closed zakharych closed 8 months ago

zakharych commented 9 months ago

Question

We are trying to parse an HL7v2 message with repeatable segments: ZXC and ZTA. Currently, after parsing, we only get the outcome for the first segment. Is there a way to parse both similar segments?

Hl7v2Config:

resourceType: Hl7v2Config
id: exsample
isStrict: false
mapping:
  resourceType: Mapping
  id: exsample
extensions:
  - msh: RAS_O17:encoding
    fields:
      - key: ZXE1
        name: ZXE.1
        type: ST
      - key: ZXE2
        name: ZXE.2
        type: ST
      - key: ZXE3
        name: ZXE.3
        type: ST
      - key: ZXE4
        name: ZXE.4
        type: ST
      - key: ZXE5
        name: ZXE.5
        type: ST
      - key: ZXE6
        name: ZXE.6
        type: ST
      - key: ZXE7
        name: ZXE.7
        type: ST
      - key: ZXE8
        name: ZXE.8
        type: ST
      - key: ZXE9
        name: ZXE.9
        type: ST
      - key: ZXE10
        name: ZXE.10
        type: ST
      - key: ZXE11
        name: ZXE.11
        type: ST
      - key: ZXE12
        name: ZXE.12
        type: ST
      - key: ZXE13
        name: ZXE.13
        type: ST
      - key: ZXE14
        name: ZXE.14
        type: ST
      - key: ZXE15
        name: ZXE.15
        type: ST
      - key: order_pharmaceutical_class
        name: ZXE.16
        type: ST
      - key: order_therapeutic_class
        name: ZXE.17
        type: ST
    segment: ZXE
  - msh: RAS_O17
    fields:
      - key: ZXC1
        name: ZXC.1
        type: ST
      - key: pharmacy_component
        name: ZXC.2
        type: CX
    segment: ZXC
  - msh: RAS_O17
    fields:
      - key: ZTA
        name: ZTA.1
        type: ST
      - key: ZTA
        name: ZTA.2
        type: ST
      - key: ZTA
        name: ZTA.3
        type: ST
      - key: code_1
        name: ZTA.4
        type: ST
      - key: code_2
        name: ZTA.5
        type: ST
    segment: ZTA
mput commented 9 months ago

Hi @zakharych.

I have added the option 'quantifier' to the field schema. The default value is '?', and it remains unchanged. The possible values are: '+', '', and '?', which have the same semantics as in regular expressions. When the value is set to '+' or '', the corresponding section in the result will be an array, even if only one segment is present in HL7v2.

Example: 

msh: RAS_O17
quantifier: '*'
fields:
- key: ZTA
  name: ZTA.1
  type: ST
- key: ZTA
  name: ZTA.2
  type: ST
- key: ZTA
  name: ZTA.3
  type: ST
- key: code_1
  name: ZTA.4
  type: ST
- key: code_2
  name: ZTA.5
  type: ST
segment: ZTA
mput commented 9 months ago

Also, here is a metadata of message structure in use for parsing. It will help you understand what to use as the msh value postfix for complex cases when Z-segments are not at the end of a message.

https://gist.github.com/mput/b0d786657209600c8a5bec7df759bf42

zakharych commented 9 months ago

Hi, @mput !

I tested the new approach. It functions as expected when the repeating segments are located sequentially. However, when duplicate keys are mixed up (an example is provided below), I still only retrieve the first value. Is there a way to handle such a scenario? 

MSH|^~\&|SENDING_APP|SENDING_FAC|RECEIVING_APP|RECEIVING_FAC|20231004120000||RAS^O17|123456789|P|2.5|||
PID|1|12345|12345|DOE^JOHN|SMITH^JANE|19800101|M|||123 Main St^^Springfield^IL^62701^USA||(555)555-5555|||||12345^67890|
PV1|1|I|^^^WARD_A|||||||||||||1||||||||||||||||||||||||||20231004120000|
ORC|NW|123456||123456||CM||||20231004120000||
RXE|1|123456|987654|Amoxicillin 500mg Capsules^Amoxicillin^500||1|CAP||||||||||||||||||||||||||||||||||||
RXA|0|3|20231004120000||20231004120000^propofol (Diprivan) 10 mg/ml infusion^NDC|10|mg|||01^Administered^HL70162|OR|||||||||Given||20230428134257||||
RXR|IM^Intramuscular^HL70162|L^Left^HL70163|
ZXC||00264-1800-31^0.9% NACL IV (VOLUME BASED BOLUS)^REPNDC
ZTA||||127|1038
ZXC||00264-1800-31^SODIUM CHLORIDE 0.9 % INTRAVENOUS SOLUTION^REPNDC
ZTA||||535|1023

I also noticed that I get the expected result if I add the searched segments twice in Hl7v2Config. Like in the example below. But I'm not sure if this is the correct way to do this.


isStrict: false
extensions:
  - msh: RAS_O17
    fields:
      - key: ZXC1
        name: ZXC.1
        type: ST
      - key: pharmacy_component
        name: ZXC.2
        type: CX
    segment: ZXC
    quantifier: '*'
  - msh: RAS_O17
    fields:
      - key: ZTA
        name: ZTA.1
        type: ST
      - key: ZTA
        name: ZTA.2
        type: ST
      - key: ZTA
        name: ZTA.3
        type: ST
      - key: code_1
        name: ZTA.4
        type: ST
      - key: code_2
        name: ZTA.5
        type: ST
    segment: ZTA
    quantifier: '*'
  - msh: RAS_O17
    fields: _Same like in first one_
    segment: ZXC
    quantifier: '*'
  - msh: RAS_O17
    fields: _Same like in first one_
    segment: ZTA
    quantifier: '*'
id: test
resourceType: Hl7v2Config
NikitaSinc commented 9 months ago

Hi @zakharych It is required to be located sequentialy for top-level segments. If you switch to strict mode, you will notice that repeating segments in mixed order are clarified as extra input that is ignored when strict mode is off. There is currently no way to work around this without breaking the logic of the other segments. Your way of handling it seems kind of tricky, but it would work for individual cases. If keeping order in z-segments causes difficulties for a wide range of your messages - we can probably add some pre-parsing logic to sort such extensions. Please let us know how much this affects you.

NikitaSinc commented 8 months ago

@zakharych I have added a new option for cases like yours. So you can now set the sortTopLevelExtensions flag on top of your configuration for message with mixed z-segment order, but it will only work for segments that are not in a group. Let us know if this works for you. Also, here is an example of HL7v2Config with sortTopLevelExtensions option on:

isStrict: false
sortTopLevelExtensions: true
extensions:
  - msh: RAS_O17
    fields:
      - key: ZXC1
        name: ZXC.1
        type: ST
      - key: pharmacy_component
        name: ZXC.2
        type: CX
    segment: ZXC
    quantifier: '*'
  - msh: RAS_O17
    fields:
      - key: ZTA
        name: ZTA.1
        type: ST
      - key: ZTA
        name: ZTA.2
        type: ST
      - key: ZTA
        name: ZTA.3
        type: ST
      - key: code_1
        name: ZTA.4
        type: ST
      - key: code_2
        name: ZTA.5
        type: ST
    segment: ZTA
    quantifier: '*'
id: test-sorted
resourceType: Hl7v2Config
VarvaraSemenova commented 8 months ago

@zakharych Hi, please respond if the issue is resolved

zakharych commented 8 months ago

Hi @VarvaraSemenova @NikitaSinc Thanks for the new option. It seems that it works good for me.