HL7 ACK Message: Acknowledgment & Errors

HL7 ACK (Acknowledgment) messages confirm receipt and processing of HL7 v2 messages. Every production HL7 interface relies on acknowledgment handling for reliable message delivery — without proper ACK processing, messages can be silently lost or duplicated.

The ACK message is the simplest HL7 v2 message type — just 2-3 segments. However, its correct implementation is critical to interface reliability.

MSA-2 echoes the MSH-10 (Message Control ID) of the original message. This is how the sending system correlates an ACK to the message that triggered it:

Original:  MSH|...|MSG00001|P|2.5.1
Response:  MSA|AA|MSG00001

If MSA-2 does not match any pending MSH-10, the sender should log a correlation error and alert operators.

When MSA-1 is AE or AR, the ERR segment provides diagnostic information:

HL7 v2 supports two acknowledgment modes, controlled by MSH-15 and MSH-16:

A single ACK for each message. MSH-15 = AL (Always) means the receiver sends one ACK. MSH-16 = NE (Never) means no separate application-level ACK. This is the configuration used by the vast majority of HL7 interfaces.

Two separate acknowledgments — one for transport, one for application. Enhanced mode adds complexity but provides confirmation that the message was both received (transport) and successfully processed (application). In practice, enhanced mode is rare.

When a sender does not receive an ACK within the configured timeout:

1. Wait: Allow adequate time (typically 30-120 seconds depending on message type)
2. Retry: Resend the original message with the same MSH-10 control ID
3. Limit retries: Cap at 3-5 attempts before alerting operators
4. Exponential backoff: Increase delay between retries (30s → 60s → 120s)

The receiving system should use MSH-10 deduplication to handle retransmitted messages — processing the first instance and returning AA for subsequent duplicates without reprocessing.

Integration engines (Mirth Connect, Rhapsody, etc.) typically manage ACK processing automatically:

• Outbound channels: Track pending ACKs per message, trigger retry on timeout or AE/AR
• Inbound channels: Generate ACK immediately after parsing (AA) or after processing (AA/AE depending on configuration)
• Queue depth monitoring: Alert when unacknowledged messages exceed thresholds — indicates downstream system issues

• Missing MSA-2 correlation: Sending an ACK without echoing MSH-10 makes it impossible for the sender to match the response
• Ignoring AE responses: Treating all non-AR responses as success leads to silently lost data
• Timeout too short: Network latency and processing time vary — timeouts under 30 seconds cause unnecessary retransmissions
• No deduplication: Failing to check MSH-10 for duplicates can result in double-processing (duplicate orders, duplicate charges)