HL7 Table HL70008: Acknowledgment Code

HL70008 is the acknowledgment code table that drives every ACK message exchanged between HL7 v2 systems. It sits in MSA-1 Acknowledgment Code and tells the sending application whether its message was accepted, rejected, or errored — and at which layer of the two-tier Enhanced Mode acknowledgment protocol. The table contains six codes drawn from the ID data type and is one of the most operationally critical code tables in the entire v2 specification: misinterpreting an AE for an AA can cause silently dropped clinical data.

Purpose

HL70008 answers two questions at once: "did the message arrive intact" and "did the receiving application successfully process it." Original Mode acknowledgment collapses both questions into a single code (AA/AE/AR). Enhanced Mode, introduced in v2.2 and standard from v2.3 onward, splits the two questions across two ACK messages — first a commit-level ACK using CA/CE/CR (the message was received and parsed) and later an application-level ACK using AA/AE/AR (the receiving application processed the content).

The mode is negotiated through MSH-15 Accept Acknowledgment Type and MSH-16 Application Acknowledgment Type. When those fields are empty or NE, Original Mode is in effect and only AA/AE/AR are used.

Where it's used

MSA-1 Acknowledgment Code — the only home of HL70008, populated on every ACK message returned to a sender.
ACK messages of every trigger event: ADT^A01^ACK, ORM^O01^ACK, ORU^R01^ACK, and so on.
Application-level retry logic in every conformant interface engine.

Code list

Code	Display	Comment/Description
AA	Application Accept	Original mode: the receiving application accepted the message. Enhanced mode: application-level accept — the receiving application successfully processed the message.
AE	Application Error	Original mode: the receiving application encountered an error processing the message. Enhanced mode: application-level error — re-sending the same message will not help; the sender must correct the content.
AR	Application Reject	Original mode: the receiving application refused the message for reasons unrelated to content (e.g., the receiver is shutting down). Enhanced mode: application-level reject — the sender should stop sending this kind of message until the receiver signals readiness.
CA	Commit Accept	Enhanced mode only: the message was received, parsed, and committed to safe storage. An application-level ACK (AA/AE/AR) will follow.
CE	Commit Error	Enhanced mode only: the message could not be committed due to a transient receiver-side issue (disk full, queue offline). The sender should retry.
CR	Commit Reject	Enhanced mode only: the message was rejected at the commit layer — typically a malformed MSH or a version mismatch. The sender must not retry without fixing the envelope.

Code system OID

OID: 2.16.840.1.113883.18.9
Canonical URI: http://terminology.hl7.org/CodeSystem/v2-0008

Vorro emits this OID in CWE.14 when MSA-1 is profiled as CWE (rare; most profiles keep MSA-1 as ID).

HL7-defined vs user-defined

HL70008 is HL7-defined and normative. The six codes are the complete set — local extensions are not permitted, and any receiver that emits a non-HL70008 code in MSA-1 is non-conformant. Sites that need richer ACK semantics carry the detail in MSA-3 (Text Message) and the optional ERR segment rather than inventing new acknowledgment codes.

Version differences

v2.1 – v2.2 — Only AA, AE, AR existed. Original Mode acknowledgment was the only model.
v2.2 — Enhanced Mode acknowledgment was introduced as an option; CA, CE, CR were added to the table.
v2.3 – v2.8.1 — Set frozen at six codes. Enhanced Mode became the recommended default in v2.4, though Original Mode remained widely deployed.
v2.9 — HL70008 unchanged; FHIR Messaging began to absorb the equivalent semantics into Bundle.entry.response.

Common mistakes

Returning AA after a database write failure because the engine itself parsed the message successfully. In Original Mode AA means the application accepted the content; if the persist failed, the correct code is AE.
Mixing Original and Enhanced Mode within a single channel. If MSH-15 is AL the sender expects a CA/CE/CR first and a separate AA/AE/AR later; returning AA directly breaks the state machine.
Treating AR as a retryable error. AR means "do not resend"; only CE and (in some profiles) AE are retry-eligible.
Emitting MSA-1 in lowercase. HL70008 codes are case-sensitive uppercase two-character literals.
Using CA outside Enhanced Mode. Original Mode channels must never emit CA/CE/CR; downstream engines that key retry logic on those codes will deadlock.

Examples

A successful Original Mode ACK:

MSH|^~&|RECEIVER|HOSPITAL|SENDER|CLINIC|20260626120000||ACK^A01^ACK|2026062612000001|P|2.8.1
MSA|AA|2026062611593022

An Enhanced Mode commit-level ACK signalling that the message is safely queued:

MSH|^~&|RECEIVER|HOSPITAL|SENDER|CLINIC|20260626120000||ACK^A01^ACK|2026062612000002|P|2.8.1
MSA|CA|2026062611593022

A later application-level ACK reporting a content error:

MSH|^~&|RECEIVER|HOSPITAL|SENDER|CLINIC|20260626120030||ACK^A01^ACK|2026062612000003|P|2.8.1
MSA|AE|2026062611593022|PID-3 missing required assigning authority
ERR|PID^1^3^^101&Required field missing&HL70357

A commit-level reject (malformed MSH):

MSH|^~&|RECEIVER|HOSPITAL|SENDER|CLINIC|20260626120000||ACK^A01^ACK|2026062612000004|P|2.8.1
MSA|CR|2026062611593022|Unsupported version 2.0.5

FHIR mapping

FHIR does not publish a direct ConceptMap for HL70008 because the underlying transport model is different. v2 acknowledgment becomes a combination of FHIR MessageHeader.response.code (ok / transient-error / fatal-error) and OperationOutcome.issue.severity:

HL7 v2 (HL70008)	FHIR MessageHeader.response.code	OperationOutcome.issue.severity
AA	ok	(none)
CA	ok	(none)
AE	transient-error	error
CE	transient-error	error
AR	fatal-error	fatal
CR	fatal-error	fatal

The commit-vs-application distinction is lost in this mapping — both layers collapse onto the same MessageHeader.response. Engines that need to preserve the distinction stash the original HL70008 code in a MessageHeader.response.extension.

Engine considerations

State machine — Enhanced Mode channels must track that a CA has been emitted before the corresponding AA/AE/AR. Engines that emit AA directly skip the commit-layer guarantee.
Retry semantics — Only CE (and sometimes AE) should drive automatic retries. AR and CR are terminal; the queue must hold the message for human review.
Timeout handling — If no MSA-1 arrives within the configured ACK window, treat the situation as a transport failure, not as an implicit AR.
Audit logging — Persist MSA-1, MSA-3, and any ERR segments alongside the original message ID (MSA-2) for downstream forensics.

How Vorro handles HL70008

Vorro generates MSA-1 based on the outcome of the channel's full processing pipeline: a successful parse-and-persist yields AA in Original Mode or CA followed by AA in Enhanced Mode. Validation failures against profile rules yield AE with the offending field captured in MSA-3 and a structured ERR segment. Envelope-level failures (unknown sender, unsupported version, malformed MSH) yield CR immediately, before any application-layer processing is attempted.

On the inbound side, Vorro keys its retry, alert, and queue-hold logic on HL70008 directly: CE triggers exponential-backoff retry, AE opens a remediation ticket, and AR/CR pause the outbound channel until an operator releases it.

Sources

← Back to HL7 v2 Guide