我们遇到过一些我们以前从未见过的东西。仔细阅读HL7文档/标准让我摸不着头脑。
我们正在发送标准的出站报告消息（ORU ^ R01）。它包含MSH，PID，OBR和OBX段。在我们实现系统的所有其他情况下，我们会收到如下所示的确认：
MSH | ^〜\＆安培; | PRODUCTNAME | DESTINATION | ^ P || || YYYYMMDDHHMMSS ACK | MESSAGEID | T | 2.5 \ MSA | AA | MESSAGEID | ACK
然而，有一个新系统正在返回：
MSH | ^〜\＆安培; | PRODUCTNAME | DESTINATION | ^ P || || YYYYMMDDHHMMSS的 ORU ^ R01 | MESSAGEID | T | 2.5 \
MSA | AA | MESSAGEID | ACK
注意ack中的MSH-9。它不是ACK它是ORU ^ R01。现在，我们使用HAPI处理HL7消息，它不喜欢这种响应。我不知道这是否符合HL7规范（2.5）。
有什么想法吗？
答案 0 :(得分：2)
为了扩展我之前的评论，我稍微阅读了HL7 v2.5标准。
根据我的理解，Components: <Message Code (ID)> ^ <Trigger Event (ID)> ^ <Message Structure (ID)>
字段包含三个组件定义如下：
MSH-9每个都有相应的合法值表：HL7表0076 - 消息类型，HL7表0003 - 事件类型和HL7表0354 - 消息结构。
查看这些表格，我会说ORU消息的ORU^R01^ORU_R01值应为ACK^R01^ACK，确认应为@foreach($datas as $data=>$key)
@for($i=0;$i<10;$i++)
<h1>{{$datas[$data][$i]['name']}}</h1>
@endfor
@if(is_array($key))
@foreach($key as $k=>$v)
@foreach($v as $venue=>$place)
<h1>{{$v['venue']['addressLine1']}}</h1>
<h1>{{$v['venue']['addressLine2']}}</h1>
@endforeach
@endforeach
@endif
@endforeach
。
因此，如果新系统试图根据标准验证消息，那么新系统似乎违反了标准并且HAPI拒绝它是正确的。
这里的要点是，接收应用程序应该能够决定，在哪里路由以及如何处理仅查看MSH字段的消息，而不进入以下段。因此，您无法在确认消息中输入与传入消息完全相同的MSH，因为它无法识别，因此标头与消息结构不匹配。
我主要参考了HL7标准版本2.5第2章的答案。