HL7 Z 段上的 HAPI 扼流圈
我正在尝试使用 HAPI 解析外部系统生成的 HL7 (v2.3) 消息。这些消息包括自定义 Z 段，其中包括消息的第二段（MSH 和 EVN 之间）。
MSH
Z
EVN
...
问题是，对于遇到第一个 Z 段后解析的任何段，HAPI 将生成消息结构，但该结构中的所有数据均为空。因此，我仍然有一个 EVN 段对象，但其中没有任何数据。
我已经尝试过：
- 什么都没有，只需使用开箱即用的 HAPI 解析消息，并忽略此段
- 通过创建我自己的 ADT 消息类（扩展默认类）在 Z 段中连接来扩展 HAPI：
- addNonstandardSegment()
- add() 以及 AbstractSegment 的自定义实现
我当前的解决方法是在 HAPI 获取消息之前对其进行预解析并剪掉该段，但这绝对是错误的方法。有人对我应该做什么有想法吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
知道了。事实证明，由于 Z 段不合适（下面会详细介绍），EVN 对象在内部被编目为“EVN2”，并且添加了第二个空白 EVN。我不太确定为什么代码会这样，但我将在 HAPI 项目的问题报告中讨论这一点。
解决方法是更改 ADT 消息的扩展名。我必须复制原始 ADT_A* 类并修改其 init() 方法，以按照预期的正确顺序添加 Z 段类，而不是扩展它并在子类构造函数中使用 this.add() 添加 Z 段信息。
顺便说一句，我之前提到的解决方法可以使用 子类化解析器来完成，这对于修复损坏的消息是有效的 - 但不是这个，因为它本身并没有“损坏”。
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.