什么標准的HL7確認消息？

Question

我們遇到過一些我們以前從未見過的東西。 瀏覽HL7文檔/標准讓我摸不着頭腦。

我們正在發送標准的出站報告消息（ORU ^ R01）。 它包含MSH，PID，OBR和OBX段。 在我們實現系統的所有其他情況下，我們得到一個如下所示的確認：

MSH | ^〜\\＆| PRODUCTNAME | DESTINATION | ^ P || YYYYMMDDHHMMSS || ACK | MESSAGEID | T | 2.5 \\ MSA | AA | MESSAGEID | ACK

但是，有一個新系統正在返回：

MSH | ^〜\\＆| PRODUCTNAME |目的地| ^ P || YYYYMMDDHHMMSS || ORU ^ R01 | MESSAGEID | T | 2.5 \\
MSA | AA | MESSAGEID | ACK

請注意ack中的MSH-9。 它不是ACK它是ORU ^ R01。 現在，我們使用HAPI處理HL7消息，它不喜歡這種響應。 我不知道這是否符合HL7規范（2.5）。

有任何想法嗎？

Answer 1

為了擴展我之前的評論，我稍微閱讀了HL7 v2.5標准。

根據我的理解， MSH-9字段包含三個組件定義如下：

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

每個都具有相應的合法值表：HL7表0076-消息類型，HL7表0003-事件類型和HL7表0354-消息結構。

看一下這些表，我會說ORU消息應該具有ORU^R01^ORU_R01的MSH-9值，並且確認應該是ACK^R01^ACK 。

因此，如果新系統試圖根據標准驗證消息，那么新系統似乎違反了標准，HAPI拒絕它是正確的。

這里的要點是，接收應用程序應該能夠決定，在哪里路由以及如何處理僅查看MSH字段的消息，而不需要進入以下段。 因此，您無法在確認消息中輸入與傳入消息完全相同的MSH，因為它無法識別然后標頭與消息結構不匹配。

對於這個答案，我主要參考HL7標准版本2.5第2章。