Engaging Conversations on Healthcare and Technology

  • TwitterFacebookRSS

HL7 Acknowledgements and Interface Pacing

The HL7 ACK Message.

What are my options?

When sending and receiving HL7 messages, the sender connections may be configured in one of two ways:

  1. to wait for an acknowledgement before sending the next message (HL7 ACK message)
  2. to wait a specified amount of time before sending the next message (interface pacing)

How do HL7 ACKS work?

An HL7 ACK message contains an MSH segment that mirrors the MSH segment found in the original message. The difference is that the MSH-9 field of the ACK message contains a specific type of ACK as the message type.

The ACK message will also contain an MSA segment:

  • The MSA-1 field gives the type of ACK.
  • The MSA-2 field contains the ID number, which can be checked against the message ID for the original message.

What types of ACKs are defined by HL7?

The ACK code is found in the MSA-1 field of the ACK message. The following codes are supported by HL7:

  • AA – Application Accept
  • AE – Application Error
  • AR – Application Reject

We often hear about “negative acknowledgements.” A negative ACK does not really exist. The term “negative acknowledgement” actually refers to an ACK that is received with AE or AR in the MSA-1 field, meaning the message was not accepted by the receiver and needs to be re-sent.

What about interface pacing?

With interface pacing, messages continue to flow at a specified pace whether or not an ACK message is received. The danger with interface pacing is that there is no way to tell if the receiver actually received the messages, and received them correctly. It also means that the message logs are not very useful.

Interface pacing is generally discouraged for this reason. Configuring your system to wait for an acknowledgement before sending the next message is ideal.

When selecting an interface engine, be sure that you are able to configure the sender options for negative or no ACKs. You should be able to configure your engine to either re-send the message, or wait indefinitely for an ACK.

  • Pingback: Tweets that mention HL7 Acknowledgements and Interface Pacing | HL7 Standards -- Topsy.com

  • Rene Spronk

    Please read chapter 2 of the standard. The Acks that are most often used are so-called ‘accpet acks’, which have to have a code in MSA-1 that’s equal to either CA, CE or CR.

    The above mentioned codes (AE, AA, AR) may only be used in ‘application acknowledgements’. These two types of acknowledgement are quite different in nature.

  • Mike Stockemer

    Hi Rene

    The most common ack method that we see in healthcare interfacing in the United States is ‘original acknowledgement rules’ or a variation of those rules. As described in the standard, section 2.13.1.2.1 ’2.13.1.2 – When the original acknowledgment rules apply’, the receiving system receives the message, does some validation and potentially some processing of the message, and then responds with one of three codes, AE-AA or AR.

    The level of actual processing that applications do prior to returning an ack varies greatly from system to system. Some systems will do more processing, and actually return an error code if the message fails for reasons such as an Order being received with an unknown procedure code, or an Order being received for an unknown patient.

    The ack mode you are referring to is described in section ’2.13.1.2.2 When enhanced acknowledgment rules apply’. While this is a perfectly valid approach to communicating HL7 data between 2 systems I would kindly disagree with your assertion that this is the ‘most often’ used form of ack handling with HL7. At least in the United States this is not the case.