【问题标题】:What a standard HL7 acknowledgement message?什么是标准的 HL7 确认消息?
【发布时间】:2018-11-27 11:03:43
【问题描述】:

我们遇到了以前从未见过的事情。翻阅 HL7 文档/标准让我摸不着头脑。

我们正在发送标准出站报告消息 (ORU^R01)。它包含 MSH、PID、OBR 和 OBX 段。在我们实施系统的所有其他情况下,我们会收到如下所示的确认:

MSH|^~\&|产品名称|目的地|^P||YYYYMMDDHHMMSS||ACK|MESSAGEID|T|2.5\ MSA|AA|MESSAGEID|ACK

但是,有一个新系统正在返回:

MSH|^~\&|产品名称|目的地|^P||YYYYMMDDHHMMSS||ORU^R01|MESSAGEID|T|2.5\
MSA|AA|MESSAGEID|ACK

请注意确认中的 MSH-9。它不是 ACK,它是 ORU^R01。现在,我们使用 HAPI 处理 HL7 消息,它不喜欢这个响应。我不知道这是否符合 HL7 规范 (2.5)。

有什么想法吗?

【问题讨论】:

  • 似乎可以按照here 的建议进行。此外,here, R01 被描述为 > R01 ORU/ACK - 观察消息的主动传输。所以 ORU^R01 也可以作为一个 ACK​​。
  • 我的(有限的)理解是,表中的这个 ORU/ACK 实际上意味着您发送了 ORU^R01 消息,并且对此的确认应该是 ACK^R01。原始消息和确认必须具有相同的 MSH-9 值是没有意义的 - 消息处理器现在如何根据标头是入站报告还是对先前发送的出站报告的确认?

标签: hl7 hapi


【解决方案1】:

为了扩展我之前的评论,我稍微阅读了 HL7 v2.5 标准。

据我了解,MSH-9 字段包含三个组件,定义如下:

Components: <Message Code (ID)> ^ <Trigger Event (ID)> ^ <Message Structure (ID)>

每个都有一个对应的合法值表:HL7 表 0076 - 消息类型、HL7 表 0003 - 事件类型和 HL7 表 0354 - 消息结构。

看看这些表,我会说 ORU 消息的 MSH-9 值应该是 ORU^R01^ORU_R01,而确认应该是 ACK^R01^ACK

因此,新系统似乎违反了标准,如果 HAPI 尝试根据标准验证消息,则拒绝它是正确的。

这里的要点是,接收应用程序应该能够仅查看 MSH 字段来决定将消息路由到哪里以及如何处理消息,而无需进入后续部分。因此,您不能在确认消息中放入与传入消息完全相同的 MSH,因为它无法识别,然后标头与消息结构不匹配。

我主要参考了 HL7 Standard version 2.5 Chapter 2 这个答案。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2019-12-28
    • 1970-01-01
    • 1970-01-01
    • 2011-04-16
    • 1970-01-01
    • 2015-06-10
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多