· Dec 19, 2022 7m read

The quintessential message in HL7v2 - ACK

In the previous article, we talked about the flow of data to request the test and receive the results of the requested test. Now let's talk about one of the most important messages of HL7v2 standard.

Every time a receiving application accepts a message and consumes the message data, it is expected to send an ACKnowledgement (ACK) message back to the sending application. The sending application is expected to keep on sending a message until it has received an ACK message. It is done to inform the sending application that its message was successfully received, that it is (not) valid in accordance with HL7 rules and, if it is compliant, that it will be processed at some point.

The requesting message can choose between two modes of processing: original or enhanced processing rules are to be applied to the message. Based on this specification, the inbound message is processed differently and a different kind of ACK message is sent back. Original mode processing is indicated if both the 15th (Accept Acknowledgement Type) and 16th (Application Acknowledgement Type) fields of the MSH segment of the inbound message are null or empty. Enhanced mode processing is indicated if at least one of the 15th and 16th fields of the MSH segment of the inbound message is not null.

For the original mode two step process is used:

  1. Protocol validation
    • the message is sent to the correct receiver (the message type is one that is acceptable)
    • the message is sent using a correct version supported by the receiver
    • the message has a Processing ID appropriate for the application process handling the message
  2. Application validation (is returned in the field MSA.1)
    • the receiving application processes the message successfully, it will generate the functional response message with a value of AA in the acknowledgement code
    • the receiving application could not processes the message successfully, it will generate the functional response message with a value of AE in the acknowledgement code
    • the receiving  application fails to process (reject) the message because of system uptime or other reasons and not for format or validation errors. The response message contains a value of AR in the acknowledgement code. The message can sometimes be re-sent later but that is up to the sending system and the implementation to figure out.

For the enhanced mode, the receiving application takes on additional responsibility namely:

  1. the inbound message is received and stored;
  2. the message passes syntax validation;
  3. the message type, version and processing ID are correct - if not a commit reject (CR) message will be sent.

Based on these rules, the receiving system will send:

  • a commit accept (CA) if all is OK;
  • a commit reject (CR) as above
  • a commit error (CE) for any other error.

It is also possible to send a Non-HL7/Static String ACK. This is a custom acknowledgement and is simply a text string (rather than an HL7-formatted ACK). These types of ACKs are used when an inbound system is incapable of receiving HL7 formatted messages or creating them.

Since a lot of the information that is returned inside ACK message is taken from the original message, here is the list of fields you should take:

  1. Enter Original Message MSH.3 (Sending Application) into ACK MSH.5 (Receiving Application).
  2. Enter Original Message MSH.4 (Sending Facility) into ACK MSH.6 (Receiving Facility).
  3. Enter Original Message MSH.6 (Receiving Facility) into ACK MSH.4 (Sending Facility).
  4. Enter Original Message MSH.11 (Processing ID) into ACK MSH.11 (Processing ID).
  5. Enter Original Message MSH.10 (Message control ID) into ACK MSA.2 (Message control ID).
  6. ACK MSH.10 (Message control ID) should be unique and unrelated to Original Message MSH.10 (Message control ID).

Segments of HL7 ACK

Segment Description
MSH Message Header. Contains information about the sending and receiving applications and contains the Message Control ID of the message. The Message Control ID, which is specified in field 10 of the MSH segment, is a unique identifier that is associated with a particular HL7 message. When a message is processed and acknowledged, field 10 of the MSH segment of the acknowledgement message contains the same identifier as the message that it is acknowledging. This is how applications can keep track of what messages have been successfully acknowledged.
[{SFT}] Software Segment. This segment provides additional information about the software product(s) used as a Sending Application. The primary purpose of this segment is for diagnostic use. There may be additional uses per site-specific agreements.
MSA Message Acknowledgement. It contains information sent while acknowledging another message, whether it is accepted (successfully processed) or rejected.
[{ERR}] Error. It is used to add error comments to acknowledgement messages.

 [ ] = optional, { } = repeatable

Example of positive acknowledgement

Let's look at the following example, which shows a positive acknowledgement of the received message.

MSA|AA|9B38584D|Everything was okay!|
Segment MSH
Segment MSA

Example of negative acknowledgement

Now let's look at the negative acknowledgement message.

MSA|AR|MOE06082236987-957.1.4|Report is unreadable.
ERR|||207|E|UserError|||Report is unreadable|HD
Segment MSH
Segment MSA
Segment ERR

This is it. Hope it sheds some light on how HL7v2 works. Find out more about HL7v2 on the official portal.

Any comments/suggestions are welcome in the comments section.

Discussion (0)2
Log in or sign up to continue