HL7^® Reference Guide

The ACK is the small message that decides whether an interface is calm or noisy. A sender posts an HL7 message, the receiver responds with an ACK, and the sender uses that response to decide whether to mark the message delivered, retry it, stop the feed, or put the message into an error queue for someone to fix.

In simple interfaces, the ACK is almost entirely MSH and MSA. In better-supported interfaces, ERR tells you exactly what failed and where. That difference matters. A vague reject creates a support call; a useful ERR segment points straight at the bad field, value, or business rule.

A small ACK example

This accepted ACK says the receiver processed message control ID ORU00001. It is synthetic, but it is the shape you want when testing basic request and response handling.

What workflow it represents

The ACK is not usually a clinical event. It is transport and application choreography. The receiving system sends it back to the sending system or integration engine to say whether the original message was accepted, rejected, or accepted with errors. In production, Integration Soup-style routing and retry logic should treat that ACK as operational evidence, not as an afterthought.

The big trap is assuming that a network-level send means success. It does not. MLLP, HTTP, file delivery, or a queue can all say "delivered" while the receiving application says AE or AR. The ACK is the application-level answer.

MSH, MSA, and ERR

MSH identifies the ACK itself. Its sending and receiving applications are usually reversed from the original message. MSH-10 gets a new control ID for the ACK, while MSA-2 echoes the original message control ID so the sender can match the response to the outbound message.

MSA carries the outcome. AA usually means accepted, AE means accepted with an application error, and AR means rejected. Commit acknowledgments may use the CA, CE, and CR family instead. Do not flatten those codes to one local "success" flag unless you really mean to lose useful state.

ERR is optional in the base structure but extremely useful when something failed. A good receiver uses ERR to identify the segment, field, repetition, severity, and diagnostic text. A sender can then log the real failure instead of showing "ACK rejected" with no clue.

Operational traps

Always check that MSA-2 matches the message you sent. A stale ACK, duplicate response, or response from the wrong connection can otherwise look valid. Also agree whether the receiver sends an ACK for every message, only errors, or only under the enhanced acknowledgment rules in MSH-15 and MSH-16.

Timeout handling should be boring and explicit. If no ACK arrives, the sender should know whether to retry, hold, or alert. If an ACK arrives with an error, retrying the same bad message forever is usually just a very tidy way of filling a queue.

Reference notes

HL7 v2 control choreography defines general ACK behavior and the role of MSA. Public interoperability guidance for immunization ACKs also emphasizes the practical importance of MSA-1 and ERR severity. See the HL7 v2.5.1 control chapter and implementation guidance such as HL7 v2.5.1 Chapter 2 and AIRA ACK guidance.