HL7 ACK messages carry an acknowledgement — the receiver's reply that a message arrived and how it was handled. ACK is the general acknowledgement message: rather than defining a bespoke reply for every message type, HL7 uses a single, minimal structure to confirm receipt, report an error, or reject a message, keyed to the original by its message control id. This page explains what an ACK message represents, how original and enhanced acknowledgement modes differ, every segment the message can contain and what each one holds, the acknowledgment codes in HL7 table 0008, and why FHIR handles acknowledgement at the transport level rather than as a mapped message. For the wider acknowledgement model — accept versus application acknowledgement across the messaging layer — see the acknowledgements overview. Sample content is constructed for illustration with fictional identifiers.
What an ACK message represents
An ACK message communicates the outcome of receiving another message. When a system receives an HL7 message, it can reply with an ACK that says the message was accepted, that it contained an error, or that it was rejected, and it names the original message by echoing its control id so the sender can correlate the reply to what it sent. The ACK is the response half of a request/response pair: the sender emits a message and, depending on the acknowledgement mode in force, waits for an ACK before considering the exchange complete.
The core of the message is the MSA segment, the Message Acknowledgment, which carries the acknowledgment code in MSA-1 and the control id of the original message in MSA-2. When something went wrong, an optional ERR segment carries the error detail. The ACK is deliberately minimal — a header, an acknowledgment, and optional error information — because its job is only to report an outcome, not to carry clinical data.
Original versus enhanced acknowledgement mode
HL7 v2 defines two acknowledgement modes, and which one is in force determines how many acknowledgements a message gets and what each one means. The mode is negotiated per message through two fields in the header: MSH-15 (Accept Acknowledgment Type) and MSH-16 (Application Acknowledgment Type).
In original mode, a message receives a single acknowledgement that conflates transport receipt and application processing. The receiver accepts the message and processes it, then returns one ACK whose MSA-1 code — AA, AE, or AR — reports the combined outcome. Original mode is in force when MSH-15 and MSH-16 are empty.
In enhanced mode, receipt and processing are acknowledged separately. The receiver first returns an accept acknowledgement confirming it has safely taken custody of the message (MSA-1 = CA, CE, or CR), and later, once the application has processed the message, returns an application acknowledgement reporting the processing outcome (MSA-1 = AA, AE, or AR). The two fields govern this independently:
MSH-15(Accept Acknowledgment Type) — whether, and under what conditions, an accept acknowledgement is required:ALalways,NEnever,ERon error only,SUon successful receipt only.MSH-16(Application Acknowledgment Type) — the same conditions applied to the application acknowledgement.
Enhanced mode lets a receiver acknowledge safe receipt immediately and defer the processing result, which decouples a fast transport confirmation from slower application handling. The overview page covers the two-level model in more depth: see acknowledgements.
Acknowledgment codes (HL7 table 0008)
The acknowledgment code in MSA-1 is drawn from HL7 table 0008. The A-prefixed codes carry the application (or, in original mode, the combined) outcome; the C-prefixed codes carry the enhanced-mode accept outcome.
| Code | Meaning |
|---|---|
AA | Original mode: Application Accept. Enhanced mode: Application acknowledgment — Accept. The message was accepted and processed successfully. |
AE | Original mode: Application Error. Enhanced mode: Application acknowledgment — Error. The message was received but an error occurred in processing; error detail follows in ERR. |
AR | Original mode: Application Reject. Enhanced mode: Application acknowledgment — Reject. The message was rejected for a reason unrelated to its content, such as a version or sequence problem. |
CA | Enhanced mode: Accept acknowledgment — Commit Accept. The receiver has safely taken custody of the message; processing is acknowledged separately. |
CE | Enhanced mode: Accept acknowledgment — Commit Error. The message could not be accepted for a reason such as a decoding or storage error. |
CR | Enhanced mode: Accept acknowledgment — Commit Reject. The message was rejected at the accept stage, for example on a validation or configuration problem. |
AA, AE, and AR appear in both modes; CA, CE, and CR appear only in enhanced mode.
Integration topology
The diagram shows the receiver returning an acknowledgement to the original sender through the integration engine.
{{diagram: sending system → HL7 message → integration engine → receiving system → ACK (MSA) → sending system}}
Typical senders: any system that received a message and must acknowledge it — an EHR, a laboratory system, a pharmacy system, or the integration engine acting on a partner's behalf.
Typical receivers: the original sender of the message being acknowledged.
Direction: the reply half of a request/response exchange — the ACK travels back to whoever sent the original message.
Segments in an ACK message
The ACK message is short: its backbone is the MSH header and the MSA acknowledgment, with an optional SFT software segment and an optional, repeating ERR for error detail. The structure below is the general ACK form verified in HL7 v2.5.1. Cardinality follows HL7 notation: [X] optional, {X} repeating, [{X}] optional and repeating; a bare code is required. Each segment code links to its canonical field-by-field reference.
| Segment | Description |
|---|---|
MSH | Message Header. Opens the ACK. It names the sending and receiving applications and facilities (typically the reverse of the original message), stamps the creation time, declares the message type in MSH-9 (ACK, often with the acknowledged trigger event), carries this acknowledgement's own control id in MSH-10, and pins the HL7 version. It also carries the acknowledgement mode fields MSH-15 and MSH-16. |
[{SFT}] | Software Segment. Identifies the software product behind the acknowledging system — vendor, product, and version. Optional and repeating. |
MSA | Message Acknowledgment. The core of the message. MSA-1 carries the acknowledgment code from HL7 table 0008 (AA, AE, AR, CA, CE, or CR), and MSA-2 echoes the message control id of the original message being acknowledged — the key the sender correlates the reply on. Required. |
[{ERR}] | Error. Carries error detail when the acknowledgment code reports a problem — the location of the error, an error code and severity, and a human-readable message. Present on AE, AR, CE, and CR; absent on a clean AA or CA. Optional and repeating, so several errors can be reported at once. |
[ ] = optional, { } = repeating
The whole message is at most four segment types, and only MSH and MSA are required — the ACK carries an outcome, not data. The canonical segment pages carry the full field-by-field detail.
Sample ACK message
Note. Constructed for illustration. Application names, control ids, and dates are fictional.
MSH|^~&|EHR|MERCYGEN|REGISTRATION|MERCYGEN|202006031201||ACK^A01^ACK|ACK00001|P|2.5.1
MSA|AA|MSG00001
What this sample shows
This is a successful acknowledgement of the ADT admit message MSG00001. The ACK in MSH-9 marks it as a general acknowledgement (echoing the acknowledged A01 trigger), and the sending and receiving applications are the reverse of the original — the EHR is now replying to REGISTRATION. The MSA carries AA in MSA-1 (accepted and processed) and echoes the original control id MSG00001 in MSA-2, letting the sender mark that message acknowledged. Because the outcome is clean, no ERR segment is present.
An error acknowledgement would instead carry AE in MSA-1 and add an ERR:
MSH|^~&|EHR|MERCYGEN|REGISTRATION|MERCYGEN|202006031201||ACK^A01^ACK|ACK00002|P|2.5.1
MSA|AE|MSG00002
ERR||PID^1^3|207^Application internal error^HL70357|E
Here MSA-1 is AE and the ERR points at the field in error (PID-3), giving an error code and a severity of E (error).
Working with ACK messages
Correlate on MSA-2, not MSH-10
The acknowledgement's own control id in MSH-10 is new to the ACK; the key that ties the reply to the original message is MSA-2, which echoes the original MSH-10. Correlate outstanding messages on MSA-2 so an acknowledgement is matched to the message it acknowledges, not to itself.
Read the mode before deciding the exchange is complete
In original mode a single ACK completes the exchange; in enhanced mode a CA accept acknowledgement only confirms safe receipt, and the sender must still wait for the application acknowledgement (AA/AE/AR) before treating the message as processed. Read MSH-15 and MSH-16 on the original message to know which acknowledgements to expect.
Treat AR and CR as terminal, AE as actionable
AR and CR are rejections — resending the same message unchanged will fail again, so a corrected message or manual intervention is needed. AE and CE report an error that may be transient; consult the ERR detail to decide whether a retry is appropriate.
Do not discard the ERR detail
The ERR segment localises the problem to a field and carries a coded reason and severity. Log it against the original message rather than collapsing every non-AA outcome to a generic failure, because the error location is what makes an interface problem diagnosable.
Vendor variance. Systems differ in whether they operate in original or enhanced mode, in how they populate
MSH-15andMSH-16, and in how much detail they place inERR. Some emit onlyAA/AEand never the commit codes. Confirm a partner's acknowledgement behaviour against their interface specification rather than assuming the base standard.
FHIR equivalent
FHIR does not model acknowledgement as a message of its own. In FHIR messaging, a system that receives a message Bundle replies with its own message Bundle whose MessageHeader carries a response element — MessageHeader.response.identifier echoes the id of the message being acknowledged and MessageHeader.response.code reports the outcome (ok, transient-error, or fatal-error), which maps conceptually onto the MSA-1 outcome. In RESTful FHIR the acknowledgement collapses further into the HTTP status of the response. In both cases acknowledgement is handled at the transport and MessageHeader.response level rather than as a mapped resource.
Accordingly, the HL7 v2-to-FHIR Implementation Guide publishes no message map for ACK — there is no target Bundle to produce, because the acknowledgement is expressed by the response half of the exchange, not by a resource. The MSA-1 code corresponds to MessageHeader.response.code and the ERR detail to MessageHeader.response.details, but this correspondence is realised in the transport layer, not through a published ConceptMap.
Common pitfalls
Pitfall. Correlating on
MSH-10instead ofMSA-2. The acknowledgement carries its own new control id inMSH-10; the original message's id is echoed inMSA-2, and that is the correlation key.
Pitfall. Treating a
CAas processing confirmation. In enhanced modeCAonly confirms safe receipt; the message is not processed until the application acknowledgement arrives. Marking the exchange complete onCAloses track of a laterAE.
Pitfall. Collapsing every non-
AAoutcome to one error.AEmay be a retryable transient error whileARis a rejection that a retry cannot fix; distinguishing them, and reading theERRdetail, is what makes the interface operable.
How Vorro handles ACK messages
Vorro generates and consumes acknowledgements on both sides of an interface. When Vorro receives a message it returns the acknowledgement the sender's mode requires — an accept acknowledgement, an application acknowledgement, or a single original-mode ACK — with the outcome in MSA-1 and the original control id echoed in MSA-2. When Vorro sends a message it correlates the returned ACK on MSA-2, reads MSH-15 and MSH-16 to know which acknowledgements to expect, retries on transient AE/CE outcomes, and routes AR/CR rejections to exception handling with the ERR detail attached. Where a FHIR destination is configured, Vorro expresses the outcome through MessageHeader.response rather than a mapped ACK message.
Related messages
- Acknowledgements overview — the accept-versus-application acknowledgement model that ACK implements.
- MFK — the master-file acknowledgement, a message-specific acknowledgement used in the master-file workflow.
- ADT — a representative unsolicited feed whose messages are acknowledged with ACK.
Sources
- HL7 Terminology — CodeSystem v2-0008 (Acknowledgment code) — codes AA, AE, AR, CA, CE, CR
- HL7 Messaging Standard Version 2.5.1 product brief
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for ACK
- HAPI v2.5.1 ACK message structure
