MajwareMAJWARE
ACK
^ACK
Acknowledgment2 required / 1 optional segments

ACK^ACKGeneral Acknowledgment

The ACK message is sent in response to any received message to confirm receipt and processing status. It can acknowledge successful processing (AA), indicate an error (AE), or reject the message (AR).

When Is This Sent?

Automatically generated by the receiving system (or interface engine) in response to any inbound HL7 message, if the sending system's MSH.15 (accept acknowledgment type) or MSH.16 (application acknowledgment type) requests one.

Real-World Usage

ACK messages are the reliability backbone of HL7 interfaces. Without proper acknowledgment handling, you can't know whether messages were received and processed. Configure your interface engine to: (1) always wait for ACK before marking a message sent, (2) log all non-AA responses, (3) retry on AR/AE with a backoff strategy. Not handling ACKs properly is the #1 cause of silent message loss in production.

Message Structure

Segment names link to their field-level reference pages.

#SegmentPurpose in this messageReqRepeat
1MSHMessage header — MSH.9 should be ACK, MSH.10 is a new unique message IDR
2MSAAcknowledgment status: AA (accepted), AE (error), AR (rejected)R
3ERRStructured error details — present when MSA.1 is AE or AROYes

Example Message

Realistic example with fake patient data. Paste into the HL7 Message Viewer to explore interactively.

HL7 v2.x Message
1MSH||^~\&|PACS|HOSPITAL_A|EPIC|HOSPITAL_A|20260310143300||ACK^A01^ACK|ACK00001|P|2.5.1
2MSA||AA|MSG00001|Message accepted and processed

Troubleshooting Scenarios

Interface keeps retrying messages even though they're being processed

Cause

The sending system is not receiving ACK messages, or the ACK is not in the expected format. The sending system treats unacknowledged messages as undelivered.

Fix

Verify the ACK is flowing back to the sending system. Check: (1) is the return connection configured correctly, (2) is MSA.2 echoing the exact original message control ID, (3) is the ACK itself well-formed (valid HL7).

AE acknowledgments with no error detail

Cause

The receiving system sends AE but MSA.3 is empty and no ERR segment is included, making diagnosis impossible.

Fix

Work with the receiving system vendor to include ERR segments or populate MSA.3 with descriptive error text. As a workaround, check the receiving system's application logs for the same timestamp as the AE.

Common Confusions

Commit acknowledgment (CA/CE/CR) vs application acknowledgment (AA/AE/AR). CA means the interface engine committed the message to its queue (guaranteed delivery to the application). AA means the application itself successfully processed the message. Both can be enabled independently via MSH.15 and MSH.16. In most production interfaces, you want AA — not just CA — to confirm end-to-end processing.

Related Message Types

Segment Reference

Paste this message into our viewer

Interactive HL7 parser. Decodes every field, validates structure, highlights errors. Free, no signup.

Open HL7 Message Viewer →

Need mapping templates?

The HL7 Integration Toolkit includes field mapping worksheets and interface spec templates for every major HL7 message type including ACK^ACK.

View HL7 Integration Toolkit →
← Back to HL7 Message Types Reference