I’m trying to use HAPI to parse HL7 (v2.3) messages generated by an external system. These messages include custom Z segments, including the second segment of the message (between MSH and EVN).
MSH
Z
EVN
...
The problem is that for any segments parsed after encountering this first Z segment, HAPI will generate the message structure but all data in that structure is null. So, I’ll still have an EVN segment object, but it won’t have any data in it.
I’ve tried:
- Nothing, just parse the message with out-of-the-box HAPI, and ignore this segment
- Extending HAPI by creating my own ADT message classes (extending the default classes) connecting in the Z segment with:
- addNonstandardSegment()
- add() with a custom implementation of AbstractSegment
My current workaround is to pre-parse the message before HAPI gets it and cut out this segment, but this is definitely the wrong approach. Does anyone have ideas on what I should be doing?
Got it. It turns out that, because of the out-of-place Z-segment (more on this below), the EVN object was being cataloged internally as “EVN2” and a second blank EVN was being added in. I’m not quite sure why the code behaved this way, but I’ll take that up in an issue report in the HAPI project.
The workaround is to alter the extension of the ADT message. Instead of extending it and adding the Z-segment with this.add() in my subclass constructor, I had to copy the original ADT_A* class and modify its init() method to add the Z segment class in the proper order as the expected message.
BTW, the previous workaround I mentioned can be done with a subclassed parser, which is valid for fixing broken messages – just not this one, since it isn’t “broken” per se.