什么标准的HL7确认消息？

Question

We've encountered something we haven't seen before. Looking through the HL7 documentation/standards has left me scratching my head.

We are sending in a standard outbound report message (ORU^R01). It contains MSH, PID, OBR, and OBX segments. In all other cases where we've implemented our system, we get back an acknowledgement that looks like this:

MSH|^~\\&|PRODUCTNAME|DESTINATION|^P||YYYYMMDDHHMMSS||ACK|MESSAGEID|T|2.5\\ MSA|AA|MESSAGEID|ACK

However, there is a new system that is returning this:

MSH|^~\\&|PRODUCTNAME|DESTINATION|^P||YYYYMMDDHHMMSS|| ORU^R01 |MESSAGEID|T|2.5\\
MSA|AA|MESSAGEID|ACK

Notice MSH-9 in the ack. It isn't ACK it is the ORU^R01. Now, we use HAPI to process HL7 messages and it doesn't like this response. I can't tell if this conforms to the HL7 spec (2.5).

Any ideas?

Answer 1

To expand on my previous comment, I read the HL7 v2.5 standard a little bit.

According to my understanding the MSH-9 field contains three components defines as follows:

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

Each of those has a corresponding table of legal values: HL7 Table 0076 - Message type, HL7 Table 0003 - Event type and HL7 Table 0354 - Message structure.

Looking at these tables, I would say that an ORU message should have an MSH-9 value of ORU^R01^ORU_R01 and an acknowledgement should be ACK^R01^ACK .

Therefore the new system seems to be breaking the standard and HAPI is right to reject it, if it tries to validate the message against the standard.

The main point here is, that the receiving application should be able to decide, where to route and what to do with the message only looking at the MSH fields, without going in to following segments. Therefore you cannot put into the acknowledgment message the exact same MSH that the incoming message had, because it would not identify then the header does not match the message structure.

I mainly referenced HL7 Standard version 2.5 Chapter 2 for this answer.