HL7 MSA Segment: Message Acknowledgment

MSA is the response segment. When a receiver answers an HL7 v2 message, it returns an acknowledgment whose MSA segment says one thing above all: did I accept your message or not. MSA-1 carries the acknowledgment code (AA, AE, AR and their enhanced variants), and MSA-2 echoes the original sender's Message Control ID so the sender can match the reply to the message it sent. Everything else in MSA is optional context. MSA never appears alone — it lives inside an ACK message (or the application-ack of another message type), always paired with the MSH of that acknowledgment.

Purpose

MSA tells the original sender whether its message was received and processed, and which message the reply is about. MSA-1 is the verdict; MSA-2 is the correlation key, copied verbatim from MSH-10 of the inbound message. When something went wrong, MSA-1 signals the class of failure and the accompanying ERR segment carries the detail.

Used in

MSA is the core segment of the ACK general acknowledgment message, where it follows MSH. It also appears in the application-level acknowledgment of most message types — the ACK returned for an ADT admit, an ORU result, an ORM order, and so on. See the messages index for the full list; any message that expects a reply is answered with an MSH + MSA pair, optionally followed by ERR.

Field-by-field reference

Source: official HL7 v2-to-FHIR IG. R = required (cardinality min ≥ 1). Repeat = field may repeat. Length pending authoritative v2.5.1 data.

Seq	Name	Data Type	Length	Req	Repeat	Table #	Description
MSA-1	Acknowledgment Code	ID	—	R	—	HL70008	The verdict: `AA`/`AE`/`AR` (original mode) or `CA`/`CE`/`CR` (enhanced mode).
MSA-2	Message Control ID	ST	—	R	—	—	Echo of MSH-10 from the message being acknowledged; the correlation key.
MSA-3	Text Message	ST	—	O	—	—	Optional human-readable text. Deprecated/retained; use ERR for error detail.
MSA-4	Expected Sequence Number	NM	—	O	—	—	Optional; used with the sequence-number protocol.
MSA-5	Delayed Acknowledgment Type	ID	—	O	—	—	Withdrawn in later versions; legacy deferred-ack indicator.
MSA-6	Error Condition	CE	—	O	—	HL70357	Deprecated in favor of ERR; coded error condition.
MSA-7	Message Waiting Number	NM	—	O	—	—	Optional; count of messages waiting. (Not present in all versions.)
MSA-8	Message Waiting Priority	ID	—	O	—	—	Optional; priority of waiting messages. (Not present in all versions.)

Most-used fields

MSA-1 Acknowledgment Code is the field interfaces branch on. In original processing mode the values are AA (Application Accept), AE (Application Error), and AR (Application Reject). In enhanced acknowledgment mode the commit-level codes are CA (Commit Accept), CE (Commit Error), and CR (Commit Reject). AE/CE means the message was understood but a problem occurred; AR/CR means it was rejected outright (often a structural or version problem).

MSA-2 Message Control ID must equal MSH-10 of the original message exactly. If it does not match, the sender cannot correlate the acknowledgment and the message is effectively unacknowledged. This is the single most important field for reliable delivery.

MSA-3 Text Message and MSA-6 Error Condition once carried error detail, but from v2.5 onward the ERR segment is the correct place for it. Most modern interfaces leave MSA-3 empty and read ERR instead.

Version differences (2.3 to 2.8.2)

2.3 / 2.3.1: MSA defined with MSA-1 through MSA-6, including MSA-5 Delayed Acknowledgment Type and MSA-6 Error Condition. Enhanced acknowledgment mode (commit codes CA/CE/CR) introduced alongside MSH-15/MSH-16.
2.4: MSA-5 Delayed Acknowledgment Type withdrawn. MSA-7 and MSA-8 (message waiting number/priority) exist in some chapters.
2.5 / 2.5.1: MSA-6 Error Condition deprecated; the ERR segment becomes the home for error detail. The segment effectively narrows to MSA-1 through MSA-3 for everyday use.
2.7+: MSA-3 Text Message marked as retained/withdrawn for backward compatibility; conformant systems rely on ERR. Receivers built for 2.3 simply ignore trailing fields they do not recognize.

Common mistakes

Putting error text in MSA-3 instead of populating an ERR segment, so modern receivers miss the detail.
Returning a different value in MSA-2 than the sender's MSH-10 — breaks ACK correlation and triggers resend storms.
Confusing commit-level codes (CA/CE/CR) with application-level codes (AA/AE/AR) when MSH-15/MSH-16 negotiated enhanced mode.
Sending AA while the application actually failed downstream, masking a real processing error.

Examples

Minimal valid MSA (required fields only):

MSA|AA|MSG00001

Fully-populated MSA:

MSA|AE|CTRL20260609-0001|Patient identifier not found|||207^Application internal error^HL70357

Annotated breakdown of the fully-populated example:

MSA                          ← segment ID
|                            ← field separator
AE                           ← MSA-1  Acknowledgment Code (Application Error)
CTRL20260609-0001            ← MSA-2  Message Control ID (echo of MSH-10)
Patient identifier not found ← MSA-3  Text Message (legacy; prefer ERR)
                             ← MSA-4  empty (Expected Sequence Number)
                             ← MSA-5  empty (Delayed Acknowledgment Type)
207^Application internal...  ← MSA-6  Error Condition (deprecated; prefer ERR)

In-context inside an ACK accepting an ADT^A01:

MSH|^~&|RECV|HOSP_B|EPIC|HOSP_A|20260609120001||ACK^A01^ACK|ACKMSG0001|P|2.5.1
MSA|AA|MSG00001

In-context inside an ACK rejecting an ORU^R01, with an ERR segment:

MSH|^~&|EHR|HOSP_A|LAB|HOSP_B|20260609131501||ACK^R01^ACK|ACKMSG0002|P|2.5.1
MSA|AR|CTRL-9931
ERR||OBR^1|101^Required field missing^HL70357|E

FHIR mapping

Target resource: MessageHeader, specifically the MessageHeader.response backbone element. Official ConceptMap: ConceptMap-segment-msa-to-messageheader (JSON).

MSA field	FHIR target
MSA-1 Acknowledgment Code	`MessageHeader.response.code`
MSA-2 Message Control ID	`MessageHeader.response.identifier`

Only MSA-1 and MSA-2 carry explicit targets in the IG ConceptMap. MSA-3 (Text Message), MSA-4 (Expected Sequence Number), MSA-5 (Delayed Acknowledgment Type), MSA-6 (Error Condition), MSA-7, and MSA-8 have no mapping in the published map. Error detail in a FHIR exchange is conveyed via MessageHeader.response.details pointing at an OperationOutcome, which is fed by the ERR segment rather than MSA-3/MSA-6.

Engine considerations

Always copy MSH-10 of the inbound message into MSA-2 byte-for-byte. Do not normalize, trim, or re-case it.
Decide MSA-1 from the real processing outcome, not just successful parse: an interface that returns AA before the downstream application has accepted the data defeats the point of an application ack.
Honor the negotiated ack mode: MSH-15 (accept ack type) and MSH-16 (application ack type) on the original message decide whether to emit commit-level codes (CA/CE/CR), application-level codes (AA/AE/AR), or both.
When MSA-1 is AE/AR (or CE/CR), attach an ERR segment with the specifics; leave MSA-3/MSA-6 empty in modern profiles.

How Vorro parses and produces MSA

On inbound acknowledgments, Vorro reads MSA-1 to set the delivery state of the original message and matches MSA-2 against the stored MSH-10 to close out the correlation; a mismatch is surfaced as an unmatched-ack alert rather than silently dropped. On the produce side, Vorro copies the inbound MSH-10 into MSA-2 unchanged, sets MSA-1 from the channel's actual processing result, selects original versus enhanced ack codes based on the negotiated MSH-15/MSH-16, and emits an ERR segment for any non-accept outcome.

MSH — the header whose MSH-10 control id is echoed in MSA-2.
ERR — the error segment that carries detail when MSA-1 is not an accept.
ACK messages — the acknowledgment message MSA lives inside.

Sources

← Back to HL7 v2 Guide