HL7 ACK Codes Explained: AA, AE, AR, CA, CE and CR

Overview

An HL7 ACK is more than a yes or no

An HL7 Version 2 acknowledgement reports an outcome for a particular stage of message handling. The six familiar values in MSA-1 belong to two different acknowledgement families:

AA, AE and AR are application acknowledgement outcomes. They are also the codes used by the classic original acknowledgement mode.
CA, CE and CR are commit—or accept acknowledgement—outcomes used by enhanced acknowledgement mode.

The current HL7 Terminology publication keeps all six codes active and explicitly labels which family each code belongs to.^[1] This distinction matters because a CA does not mean the receiving application completed its business processing. It means the message reached the commit/accept stage successfully. An application acknowledgement may still follow.

Key principle: identify the acknowledgement mode and processing stage before interpreting the outcome code.

Quick reference

What the six acknowledgement codes mean

Code	Family	HL7 meaning	Practical reading
AA	Application	Application Accept	The receiving application reports acceptance at the application-processing stage.
AE	Application	Application Error	Application processing encountered an error. Read the ERR segment and local interface rules before deciding whether to correct or retry.
AR	Application	Application Reject	The application reports rejection. The exact operational distinction from AE depends on the HL7 version and implementation profile.
CA	Commit/accept	Commit Accept	The message passed the enhanced-mode accept/commit stage. This is not proof of completed application processing.
CE	Commit/accept	Commit Error	An error occurred during the enhanced-mode accept/commit stage.
CR	Commit/accept	Commit Reject	The message was rejected during the enhanced-mode accept/commit stage.

Do not infer a complete retry policy from the two-letter code alone. The response message, ERR details, interface specification, receiver logs, duplicate-handling rules, and current processing state all matter.

Acknowledgement modes

Original mode versus enhanced mode

Original acknowledgement mode

When MSH-15 and MSH-16 are omitted or both empty, the original acknowledgement rules apply in later HL7 versions.^[3] The receiver normally returns one acknowledgement containing an MSA result of AA, AE or AR.

This is the pattern many production interfaces use: send one HL7 message, wait for one application-level ACK, correlate MSA-2 with the original MSH-10, and then mark the outbound message accepted or failed according to the agreed rules.

Enhanced acknowledgement mode

Enhanced mode separates the exchange into an accept acknowledgement and an optional application acknowledgement. The sender indicates when each type is required through:

MSH-15 — Accept Acknowledgment Type
MSH-16 — Application Acknowledgment Type

The condition values come from HL7 Table 0155:^[2]

Value	Meaning	Operational effect
AL	Always	Return this acknowledgement type for successful and unsuccessful outcomes.
NE	Never	Do not return this acknowledgement type.
ER	Error/reject conditions only	Return it only when the corresponding stage reports an error or rejection.
SU	Successful completion only	Return it only when the corresponding stage succeeds.

CA, CE and CR are used for the enhanced-mode accept acknowledgement. AA, AE and AR are used for application acknowledgement outcomes. The application response may be a generic ACK or a message type defined by the relevant HL7 chapter and interface profile.

Do not call CA a TCP or MLLP acknowledgement. TCP confirms transport behaviour and MLLP supplies framing. CA is an HL7 message-processing acknowledgement carried inside an HL7 response message.

Interpretation workflow

Read an ACK in a reliable order

Confirm that it is the expected response. Check MSH-9, version, processing ID, and the interface's expected response message structure.
Correlate the message. Compare MSA-2 with the original message's MSH-10. HL7 defines MSA-2 as the message control ID of the message being acknowledged.^[3]
Identify the acknowledgement family. AA/AE/AR are application outcomes; CA/CE/CR are enhanced-mode accept outcomes.
Read every ERR segment. Inspect locations, HL7 error codes, severity, diagnostics, and user-facing guidance. A response can contain more than one error.
Apply the local state transition. Decide whether to complete, hold, correct, retry, investigate, or await a later application response according to the interface contract.

MSH-10 and MSA-2 perform different jobs

The ACK's own MSH-10 is the control ID of the response message. It should be newly assigned by the response sender. The MSA-2 value points back to the original message. Copying the original control ID into both fields makes logs and duplicate handling ambiguous.

Check sender and receiver reversal

The response normally reverses the sending and receiving application/facility values. For example, the original MSH-3/MSH-4 become the response's receiving application/facility, while the original MSH-5/MSH-6 become the response sender. Local profiles may further constrain these values.

Worked examples

Three common acknowledgement exchanges

1. Original-mode application acceptance

Original message
MSH|^~\&|ADT-SENDER|MAIN|EHR|MAIN|20260722101500||ADT^A01^ADT_A01|MSG000123|P|2.5.1
PID|1||TEST123^^^MAIN^MR||SAMPLE^PATIENT

Acknowledgement
MSH|^~\&|EHR|MAIN|ADT-SENDER|MAIN|20260722101501||ACK^A01^ACK|ACK000123|P|2.5.1
MSA|AA|MSG000123

The ACK has its own control ID, ACK000123. The MSA-2 value matches the inbound MSH-10, and AA reports application acceptance.

2. Application error with a precise ERR location

MSH|^~\&|EHR|MAIN|ADT-SENDER|MAIN|20260722101601||ACK^A01^ACK|ACK000124|P|2.5.1
MSA|AE|MSG000124
ERR||PID^1^3^1|102^Data type error^HL70357|E|||PID-3 did not match the expected datatype|Correct PID-3 and resend

The response reports an application error and points to PID-3 in the first PID segment and first repetition. The HL7 error code identifies a data-type problem, while the diagnostic and user-message fields explain what the receiver detected and what the sender should correct.

3. Enhanced mode: commit acceptance followed by application acceptance

Original message requests both acknowledgement stages
MSH|^~\&|LAB|MAIN|EHR|MAIN|20260722102000||ORU^R01^ORU_R01|MSG000125|P|2.5.1|||AL|AL

Immediate accept acknowledgement
MSH|^~\&|EHR|MAIN|LAB|MAIN|20260722102001||ACK^R01^ACK|ACK000125C|P|2.5.1
MSA|CA|MSG000125

Later application acknowledgement
MSH|^~\&|EHR|MAIN|LAB|MAIN|20260722102008||ACK^R01^ACK|ACK000125A|P|2.5.1
MSA|AA|MSG000125

The CA completes the accept/commit stage. The later AA reports the application-processing outcome. A sender that closes the transaction on CA alone would miss a later AE or AR when an application acknowledgement was requested.

Error detail

Use ERR rather than relying on free text

Modern acknowledgement handling should use the ERR segment for structured error detail. HL7 Version 2.8.1 notes that MSA-3 was deprecated as of Version 2.4 and removed from the standard as of Version 2.7, directing readers to ERR for richer error descriptions.^[3]

Useful ERR content can include:

Error location: segment, occurrence, field, repetition, component, and subcomponent.
HL7 error code: values such as required field missing, data type error, unsupported message type, or application error from the current message-error code system.^[4]
Severity: information, warning, error, or fatal where supported by the message version and profile.^[5]
Diagnostic information: technical detail for an interface analyst or developer.
User message: actionable wording suitable for the operational recipient.

ERR structure and field availability vary by HL7 version. Older responses may populate legacy error-location fields or provide only text. A parser should be version-aware and tolerant enough to report what is present without pretending that incomplete ERR content is fully conformant.

Operational handling

An ACK code is not a complete retry policy

Situation	What is known	Safer next step
AA received	The receiver reports application acceptance.	Complete the interface transaction, while remembering that later clinical or business workflows may still fail outside the ACK exchange.
CA received	The enhanced-mode commit stage succeeded.	Wait for the application response when MSH-16 and the interface contract require one.
AE or CE	The relevant processing stage reported an error.	Inspect ERR and logs, correct the identified condition, and retry only when the interface defines the retry as safe.
AR or CR	The relevant stage reported rejection.	Investigate the reason and receiver state. Do not blindly resend an unchanged message.
Timeout/no ACK	The sender does not know whether the receiver committed or processed the message.	Check receiver logs or query state where possible; use duplicate-safe retries and preserve the original control-ID strategy required by the contract.
MSA-2 mismatch	The response cannot be safely correlated to the expected outbound message.	Hold it for investigation rather than completing the wrong queue item.

Timeouts create an unknown outcome

A missing ACK is not proof that the receiver did nothing. The receiver may have processed the message and failed to return the response, the network may have dropped the ACK, or the sender may have timed out too quickly. Retrying without duplicate controls can create duplicate admissions, orders, results, or documents.

Preserve traceability across retries

Agree whether a retry keeps the original MSH-10 or receives a new control ID, how duplicates are detected, and which status is authoritative. There is no safe universal answer: some receivers use MSH-10 for idempotency, while others require a new message instance and use separate business identifiers for duplicate detection.

Troubleshooting

Common acknowledgement failures

The sender receives CA but waits forever

Check whether MSH-16 requested an application acknowledgement, whether the message pair defines a later response, and whether the receiving application generated it. Also confirm that the sender is listening on the correct channel and correlating the later response by MSA-2.

The sender receives two ACKs and treats one as a duplicate

The exchange may be using enhanced mode: the first response is CA/CE/CR and the second is AA/AE/AR. Store the acknowledgement stage separately rather than assuming every response closes the same queue item.

The receiver says it sent an ACK, but the sender cannot match it

Compare the original MSH-10 with response MSA-2. Then verify delimiters, whitespace, control characters, message framing, and whether an intermediary changed or regenerated identifiers.

An AA is received, but the intended update is not visible

AA reports the receiver's acknowledgement outcome, not necessarily every downstream workflow. Check whether the ACK was generated before business validation, whether the update was queued asynchronously, and whether a later application-specific response or audit record is the true completion signal.

The response contains AE but no useful error detail

Review receiver logs and request structured ERR population in the interface specification. At minimum, the response should make it possible to distinguish malformed content, unsupported message structure, missing required data, business-rule failure, and temporary application failure.

Checklist

What to define in an interface specification

Original or enhanced acknowledgement mode.
Permitted values for MSH-15 and MSH-16.
Expected response message type and structure for each inbound event.
Maximum response time for commit and application acknowledgements.
How MSA-2 correlates to the original MSH-10.
Required ERR locations, codes, severity, diagnostics, and user messages.
Whether AE/AR/CE/CR are retryable and under which conditions.
Timeout, retry, duplicate, and idempotency behaviour.
Whether a successful ACK is the final completion signal or only one processing milestone.
Logging and audit data retained by both sender and receiver.

FAQ

Frequently asked HL7 ACK questions

Is AA always a complete success?

AA means the receiving application reports acceptance at the acknowledgement stage represented by that response. It does not prove that every later clinical, financial, workflow, or downstream process completed.

Is CA better than AA?

No. They describe different stages. CA is a successful enhanced-mode accept/commit acknowledgement; AA is a successful application acknowledgement. An exchange may legitimately use both.

Should AE always be retried?

No. The error may be permanent until the message is corrected, temporary, or already partially applied. Read ERR, check receiver state, and follow the agreed retry and duplicate-handling rules.

What should MSA-2 contain?

MSA-2 should contain the message control ID of the message being acknowledged—normally the original message's MSH-10 value.

Do MLLP control characters count as an ACK?

No. MLLP frames the HL7 payload using transport control characters. The acknowledgement result is expressed in an HL7 response message, principally through MSA-1 and MSA-2.

Primary references

Standards and terminology sources

HL7 Terminology: Acknowledgment Codes, Table 0008 — current definitions for AA, AE, AR, CA, CE and CR.
HL7 Terminology: Accept/Application Acknowledgment Conditions, Table 0155 — AL, NE, ER and SU values used by MSH-15 and MSH-16.
HL7 Version 2.8.1, Chapter 2: Control — message processing, original and enhanced acknowledgement protocols, MSA fields and ERR usage.
HL7 Terminology: Message Error Condition Codes, Table 0357.
HL7 Terminology: Error Severity, Table 0516.
HL7 Version 2 product information.

Version-specific standards and local implementation guides may define different message structures or constraints. Confirm the version carried in MSH-12 and the profile agreed for the interface.

About the author

Colin McGrath is a healthcare integration specialist and software developer with more than 15 years of experience working with HL7, FHIR, CDA, APIs, PKI, XML security, and clinical system integrations.

Corrections

Technical corrections and synthetic examples are welcome through the site's GitHub issue tracker. Do not include patient data, credentials, or confidential logs.