NEWFree ROI Calculators — quantify what prior auth and siloed data are costing your organization.Prior Auth ROI Siloed Data ROI
HL7 v26 min read

ACK — Application Acknowledgements (AA / AE / AR)

Every HL7 message expects an ACK response. AA means Application Accept, AE means Application Error, and AR means Application Reject. Understanding all three codes is essential for reliable healthcare integration.

The ACK message is how receiving systems confirm receipt and processing of HL7 messages. Without proper ACK handling, you cannot build reliable healthcare integrations — lost messages and silent failures will occur.

What is an HL7 ACK?

Every HL7 v2 message sent over MLLP expects an acknowledgement. MSA-1 codes: AA=Application Accept (committed), AE=Application Error (retry may work), AR=Application Reject (permanent — do not retry same message).

  • AA — message fully processed and committed to the application
  • AE — processing failed (unknown MRN, invalid code, DB error) — transient
  • AR — message structurally invalid (malformed MSH, unsupported type) — permanent
  • No ACK / timeout — connection dropped; retry after reconnecting

Message Flow

Sender
HL7 Message
Receiver
ACK (AA/AE/AR)
Sender ACK Handler

Segments in this Message

Cardinality: [X] optional · {X} repeating · [{X}] optional & repeating

SegmentNameRequiredDescription
MSHMessage HeaderRequiredMSH-9 = ACK. MSH-3/5 and MSH-4/6 are swapped from the triggering message.
MSAMessage AcknowledgementRequiredMSA-1=code (AA/AE/AR), MSA-2=original message control ID (echo of MSH-10), MSA-3=optional description.
ERRError SegmentOptionalRequired when MSA-1=AE or AR. ERR-3=HL7 error code, ERR-4=severity, ERR-7=diagnostic text with human-readable explanation.

HL7 Message Example

HL7 v2.5.1
# ACK: AA (Application Accept) — message committed
MSH|^~&|LABSYS|MERCY|EPIC|MERCY|20240116143100||ACK|ACK001|P|2.5.1
MSA|AA|MSG004|Message successfully received and committed.

# ACK: AE (Application Error) — retry after fixing root cause
MSH|^~&|LABSYS|MERCY|EPIC|MERCY|20240116143100||ACK|ACK002|P|2.5.1
MSA|AE|MSG004|Patient MRN-78234 not found in receiving system.
ERR||1^3|HL70357|E|204^Unknown Key Identifier^HL70533|||PID-3 MRN not found — ensure A01 was received first.

# ACK: AR (Application Reject) — do NOT retry the same message
MSH|^~&|LABSYS|MERCY|EPIC|MERCY|20240116143100||ACK|ACK003|P|2.5.1
MSA|AR|MSG005|Unsupported message type ORX^Z01.
ERR||1^9|HL70357|E|200^Unsupported Message Type^HL70533|||Valid types: ADT, ORM, ORU, MDM.

FHIR Mapping

ACK has no direct FHIR equivalent. FHIR uses HTTP status codes: AA=200 OK, AE=422 Unprocessable Entity + OperationOutcome, AR=400 Bad Request + OperationOutcome.

Common Errors & Pitfalls

  • Not distinguishing AE from AR — AE is transient and may be retryable; AR is permanent. Implement separate retry logic.
  • Missing ERR on AE/AR — without ERR, the sender cannot diagnose the problem. Always include ERR with descriptive text.
  • Not logging MSA-2 control IDs — essential for audit trails and deduplication.
  • Treating timeout as AR — a timeout means the connection dropped, not that the message was rejected. Retry after reconnecting.
Vorro Integration Tip

Vorro stores every MSA-2 control ID for deduplication. Configure separate retry intervals: AE = exponential backoff (max 5 retries), AR = dead-letter queue (manual review required). Enable ACK timeout monitoring to detect silent connection failures.

← Back to HL7 Guide

Ready to Integrate This Into Your Workflow?

Talk to a Vorro expert about implementing HL7 v2 in your specific environment.

Browse HL7 Guides
ACK — Application Acknowledgements (AA / AE / AR) | Vorro Academy | Vorro