ACK Messages
Auto ACKnowledgments: When a message is sent and the data is consumed, the HL7 protocol requires that the receiver send back a valid HL7 ACKnowledgment message. Setting up ACKnowledgment messages can be an annoying detail of HL7. It is desirable to be able to alter the format of ACK messages on the fly without needing to alter your application’s source code (in the case of Chameleon). With Iguana, the format of ACK messages can be customized by editing the message definition file (VMD).
Messages
Every HL7 message is part of a two-way communication system between two applications. A message that is sent to a system must somehow be acknowledged by the recipient. Acknowledgments, known in the HL7 world as ACKs, let the sending system know that their original message was successfully received and processed. This two-way communication is demonstrated in the following diagram:
If the message was successfully sent, a positive ACK message is sent to the sending system and the communication is over for that particular message. A positive ACK is indicated by using an AA (Application Acknowledgment) value in the first field of the MSA segment. This code indicates that the message has been received and processed without any issues.
NACK Messages [top]
Negative Acknowledgments, known as NACKs, let the sending system know that there was an error while processing the message.
If there were problems processing the message, a negative ACK message is sent to the sending system.
The HL7 standard defines two types of negative ACK messages that can be sent:
- An AE (Application Error) message indicates that there was a problem processing the message. This could be related to the message structure, or the message itself. The sending application must correct this problem before attempting to resend the message.
- An AR (Application Reject) message indicates one of two things: either there is a problem with field 9, field 11 or field 12 of the MSH segment, or there is a problem with the receiving application that is not related to the message or its structure.
Anatomy of an ACK/NACK [top]
Generating an ACK or NACK message requires the definition of a generic mechanism to extract the standard MSH (MeSsage Header) fields from each incoming message, and use them to populate the required fields in the ACK message.
The following diagram labels the important parts of an ACK/NACK message:
You can see that it consists of two segments called MSH and MSA.
MSH Segments [top]
The MSH segment is the MeSsage Header segment. Every HL7 message starts with an MSH segment. This segment contains the following information that’s relevant to an ACK message:
| Location | Information | Description |
|---|---|---|
| MSH.3 – MSH.6 | Sending Application (MSH.3), Sending Facility (MSH.4), Receiving Application (MSH.5), Receiving Facility (MSH.6) | Indicates what application generated the message, and what facility generated the message. |
| MSH.10 | Message Control ID | Unique ID for the message being sent. This is used by the receiving system to distinguish between messages being sent to them. |
| MSH.12 | Version ID | Allows the sending system to indicate which version of the HL7 standard that their message complies with. |
For the inbound parsing of each message you want to acknowledge, it is important to store the message control ID and possibly other parameters like the sender, version, etc.
MSA Segments [top]
The MSA segment indicates what message is being acknowledged and whether it was successfully received and processed. There are two relevant types of information inside the MSA segment:
| Location | Information | Description |
|---|---|---|
| MSA.1 | Acknowledgment Code | Indicates whether or not the message was successfully received and processed (‘AA’ for a positive ACK; ‘AE’ or ‘AR’ for a negative ACK). |
| MSA.2 | Message Control ID | This represents the unique ID of the message that is being acknowledged. |