What Is an HL7 Acknowledgment?
In HL7 v2.x, an acknowledgment message (commonly called an ACK) is the reply a receiving application sends back to a sending application after processing an incoming message. Acknowledgments serve two critical functions in healthcare integration: they confirm that a message was received and processed correctly, and they provide a feedback mechanism for error reporting when something goes wrong. The HL7 v2.x specification defines the acknowledgment protocol in Chapter 2 as a core part of the standard's reliability model.
Without acknowledgments, a sending system has no way to know whether a lab order reached the laboratory information system, whether the ADT admission message updated the scheduling system, or whether a radiology order was accepted by the RIS. ACK messages close this loop by providing a structured, machine-readable confirmation (or rejection) for every transaction.
The Three ACK Codes: AA, AE, and AR
HL7 v2.x defines three application acknowledgment codes in MSA-1:
- AA — Application Accept: The receiving application successfully processed the message. The data has been stored, the order placed, or the event recorded. An AA ACK tells the sender to consider the transaction complete and not to retransmit.
- AE — Application Error: The receiving application received the message but encountered a non-fatal error during processing — for example, a required field was missing, a code value was not found in the receiver's lookup table, or a business rule was violated. The message may or may not have been partially processed. AE ACKs typically include MSA-3 (Text Message) and optionally an ERR segment with structured error details.
- AR — Application Reject: The receiving application rejected the message entirely without processing it. Common reasons include an unknown message type, an unsupported version, or a security or authorization failure. An AR ACK signals that the sending application must resolve the underlying issue before retransmitting.
MSH Mirroring: Routing the ACK Back to the Sender
The source of most ACK parsing errors is incorrect MSH field mirroring. The HL7 v2.x specification requires that when generating an ACK, the receiving system must swap the sending and receiving identifiers from the original message so the ACK is routed back to the original sender:
- MSH-3 ↔ MSH-5: Sending Application becomes Receiving Application, and vice versa.
- MSH-4 ↔ MSH-6: Sending Facility becomes Receiving Facility, and vice versa.
- MSH-10 (new): A new, unique message control ID is assigned to the ACK itself — not reused from the original message.
Errors in this mirroring are one of the most common causes of "ACK received but message considered lost" scenarios: the interface engine receives the ACK but cannot match it to the original transaction because the control ID or routing identifiers do not align.
The MSA Segment
Every ACK message contains an MSA (Message Acknowledgment) segment as its second segment. MSA contains three key fields:
- MSA-1 — Acknowledgment Code: One of AA, AE, or AR. This is the machine-readable status code the sending system uses to determine what to do next.
- MSA-2 — Message Control ID: The value of MSH-10 from the original message — not the ACK's own control ID. This links the ACK back to the specific transaction it is acknowledging, enabling deduplication and retry logic in the sending system.
- MSA-3 — Text Message: Optional free-text description. Commonly used for AE and AR responses to describe the error in human-readable form. Not machine-parseable; use the ERR segment for structured error codes.
Original vs. Enhanced Acknowledgment Modes
HL7 v2.x supports two acknowledgment modes, negotiated in MSH-15 (Accept Acknowledgment Type) and MSH-16 (Application Acknowledgment Type). In Original Mode, a single ACK serves both transport and application acknowledgment. In Enhanced Mode, two separate ACKs may be required: a commit ACK (CA/CE/CR) from the transport layer, and an application ACK (AA/AE/AR) from the application layer. Most production interfaces use Original Mode with application ACKs. This tool generates Original Mode ACKs as described in the HL7 v2.x Chapter 2 specification.
Practical Applications for Integration Teams
Interface analysts, integration engineers, and QA teams use ACK generation in several common scenarios. When testing a new interface without a live receiving system, generating a synthetic ACK response allows the sending system to exercise its acknowledgment-handling logic. When writing mapping documents or interface specifications, including a sample ACK alongside the trigger message gives reviewers a complete picture of the expected message exchange. When training new analysts, stepping through a generated ACK alongside the original message is one of the fastest ways to explain the HL7 handshake pattern. And when investigating production issues where messages are being retransmitted repeatedly, manually generating an ACK from the original message and comparing it to the received ACK can quickly pinpoint the mirroring or control ID discrepancy causing the problem.