Every HL7v2 message expects an acknowledgment. The receiving system returns a short ACK message carrying one of three codes: AA (application accept), AE (application error), or AR (application reject). The three codes look interchangeable in the spec and behave very differently in production. Understanding what each triggers upstream is what keeps retry loops from becoming runaway retry loops.
Naming the codes is the discipline. For related walkthroughs, the FHIR learning path collects the surrounding material.
AA — Everything Is Fine
AA means the receiving application accepted and processed the message. The sender treats AA as done; retry logic stops; the audit trail marks the message as delivered.
AA is the code every message should aim for. It is also the code some systems return when they should not, which produces silent data loss downstream. A pass through the site's HL7 v2 segment → FHIR mapping tool surfaces the segment context that shapes when AA is appropriate.
AE — The Application Saw a Problem
AE means the receiving application understood the message but could not process it. Missing required fields, invalid values, business-rule failures. AE tells the sender the message needs to be fixed before it can be retried.
Sending systems that treat AE as retryable produce the runaway loop. The right response to AE is to log the failure, alert an operator, and hold the message for human review. Never automatic retry.
AR — Reject the Message Entirely
AR means the message is malformed at a level the application cannot recover from. Bad segment structure, wrong version, unparseable encoding. AR tells the sender to stop sending this specific message shape.
AR is the code that gets confused with AE most often. The distinction: AE is a business-logic failure the sender might fix; AR is a structural failure that requires code changes on the sender.
The Enhanced ACK Layer
HL7v2.5 and later add an enhanced acknowledgment mode with two levels: accept ACK and application ACK. The accept ACK confirms the message was received; the application ACK confirms it was processed. This resolves the ambiguity around long-running processing.
Enhanced ACKs are more work to implement and more useful in high-volume integrations. For the wider message-anatomy framing, reading an HL7v2 message when you only know FHIR covers the segments around the ACK loop.
The MSA Segment Carries the Verdict
The ACK message uses MSA-1 to carry the code (AA, AE, or AR) and MSA-2 to reference the original message's control ID. MSA-3 optionally carries a text explanation.
Sending systems that trace by control ID depend on MSA-2 being correct. Missing or wrong MSA-2 breaks the trace and produces gaps in the audit trail. For the MSH-side story, MSH segment: the header that decides how the rest is parsed covers the identifier framing.
The Retry Behavior
Upstream systems' retry behavior is coupled to the ACK code:
- AA: no retry, message done.
- AE: no automatic retry, human review.
- AR: no retry, developer fix.
- Timeout with no ACK: retry per policy.
For the ADT-side vocabulary, the ADT event types you meet first in an integration covers the messages that expect ACKs.
The Transport Interaction
ACKs travel back over the same transport as the original message. For MLLP-transported traffic, that means MLLP-framed ACKs. For the transport framing, MLLP framing: the wire format that never dies is the accompanying reference.
Sending the right ACK is not glamorous. It is what keeps upstream systems from bombarding the receiver.
Sources
- HL7 canonical product overview describing acknowledgment - HL7 canonical product overview describing acknowledgment semantics