0

I'm generating a OML_O33 (for the IHE LAB-63 profile) HL7 v25 message using the Java HAPI v2.3. The message should support multiple ORDER groups (ihe message profile) but due to an ambiguous definition of the ORC/OBR sequences in the ORDER and ORDER_PRIOR groups, when parsing a flat HL7 string the parser fails to recognise multiple instances of ORDER groups, identifying them as ORDER_PRIOR groups.

I correctly modelled using the OML_O33 class and for a single OML_O33_SPECIMEN group, multiple OML_O33_ORDER groups have been added.

OML_O33 omlO33;

...

omlO33.getSPECIMENAll().size()  // displays 1
omlO33.getSPECIMEN(0).getORDERAll().size()  // displays 2

The message is correctly serialised as a HL7 string as expected, for instance:

MSH|^~\&|System Test|System Test|LIS Test|LIS Test|20190911105010.527+0200||OML^O33^OML_O33|2787136c-8885-4f7c-a0bb-8190b5c73ff1|D|2.5
PID|||patientIdFoo123^^^N/A||surnameFoo123^nameFoo123||20190911|M||||||||||accountNumberFoo123^^^N/A
SPM|1|barcodeFoo0||specimenFoo123|||||||||||||20190911105010.555+0200||||||||||0^REF1230
ORC|SC|bbc4bdaa-25bc-426f-830c-0737af9ecdb8||pgnFoo123||||||||doctorIdFoo^doctorSurnameFoo^doctorNameFoo
OBR||bbc4bdaa-25bc-426f-830c-0737af9ecdb8||orderIdFoo0^orderDescriptionFoo0||||||phlebotomistFoo123||||||doctorIdFoo^doctorSurnameFoo^doctorNameFoo|||||||||S
ORC|SC|8fa86d07-4f8d-4cda-ac64-3f58a5ab6acf||pgnFoo123||||||||doctorIdFoo^doctorSurnameFoo^doctorNameFoo
OBR||8fa86d07-4f8d-4cda-ac64-3f58a5ab6acf||orderIdFoo1^orderDescriptionFoo1||||||phlebotomistFoo123||||||doctorIdFoo^doctorSurnameFoo^doctorNameFoo|||||||||S

The message passes the Gazelle IHE Validator but when converted to string and parsed "back" (using the standard PipeParser with the DefaultHapiContext provided by the library) it is re-interpreted with a single ORDER group and a ORDER_PRIOR group. 

OML_O33 omlO33;

...

omlO33.getSPECIMENAll().size()  // displays 1
omlO33.getSPECIMEN(0).getORDERAll().size()  // displays 1
omlO33.getSPECIMEN(0).getORDER(0).getOBSERVATION_REQUEST().getPRIOR_RESULTAll().size() . // displays 1

I expected to see 2 ORDER groups and no ORDER_PRIOR groups at all.

If I add a FT1 empty segment to "break" the ambiguity, the message is parsed correctly (2 ORDER groups instead of 1) but this solution is not acceptable in my system.

I would prefer to avoid using the Terser to access the ORC/OBR segments instances, and rely on the model representation.

pirods
  • 43
  • 1
  • 7
  • Have you found a solution? – 4535992 Nov 29 '19 at 08:04
  • 1
    Not an official (nor clean) one. I found a "quick and dirty" way to override the HAPI library without having to modify the actual library source code. I've recreated the package path, copying and pasting the classes I needed to edit and edited them manually (see [prnt.sc/q61eas]) commenting the repetitions I wanted to exclude. I wouldn't advise replicating such implementation, but on a "static" library (latest release 07/2017) such as HAPI it should be "relatively safe" – pirods Dec 04 '19 at 11:28

0 Answers0