How v2 Messages Are Exchanged — Acknowledgments and MLLP

One send creates several claims

An interface needs to distinguish at least three outcomes:

1. a connection accepted bytes;
2. the receiver framed and parsed a message;
3. the receiving application accepted or rejected the requested work.

These are not interchangeable. TCP can deliver bytes that do not form a valid HL7 message. MLLP can frame a valid message that fails a profile. An application can accept a structurally valid message but later fail to update the intended workflow. HL7 v2 acknowledgments exist because transport delivery alone does not prove application processing ¹.

Correlate every response

The initiating message carries a control identifier in MSH-10:

MSH|^~\&|ADT1|HOSP|LAB|HOSP|202608091205-0500||ADT^A01^ADT_A01|MSG00001|P|2.5

The acknowledgment is a new message with its own MSH-10. Its MSA-2 echoes the initiating control ID:

MSH|^~\&|LAB|HOSP|ADT1|HOSP|202608091205-0500||ACK^A01^ACK|ACK90001|P|2.5
MSA|AA|MSG00001

This distinction matters in logs. ACK90001 identifies the acknowledgment message; MSG00001 identifies the message being acknowledged. Correlation should also retain source, destination, connection, timestamps, and route because different senders can accidentally reuse a control ID.

Read AA, AE, and AR as outcomes—not moods

The first field of MSA carries the acknowledgment code:

• AA — Application Accept: application processing succeeded under the receiver’s rules.
• AE — Application Error: the message was accepted far enough to process, but an application error occurred.
• AR — Application Reject: the message could not be processed as submitted, commonly because of structural, version, or control problems.

The precise behavior belongs in the interface contract. Do not build retry logic around a vague rule such as “retry everything that is not AA.” Some errors are transient; others require correction or human review. Blind retry of an invalid patient identifier only produces a larger error queue.

When available, the ERR segment supplies structured error location, code, severity, and diagnostics. Modern v2 guidance favors ERR over relying on free-text MSA error fields ¹. A useful receiver reports the narrowest safe location, such as a field or component, without exposing more patient data than support staff need.

Original and enhanced acknowledgment modes

MSH-15 and MSH-16 request accept- and application-level acknowledgments. Values such as AL (always), NE (never), ER (on error), and SU (on success) control when the corresponding response is expected. In original mode, one application acknowledgment usually represents the interaction. Enhanced mode separates acceptance of the message from later application processing ¹.

Write down which mode the interface actually implements. A sender waiting for two responses while the receiver sends one will manufacture timeouts. A receiver returning an immediate positive accept acknowledgment must not let the sender misinterpret that as proof of final application commit.

MLLP frames the byte stream

TCP is a stream, not a sequence of application messages. The Minimal Lower Layer Protocol wraps each payload with control bytes:

0x0B  <HL7 payload ending in segment CRs>  0x1C 0x0D
  VT                                      FS   CR

The start byte marks the beginning of the block; file separator plus carriage return marks the end. The HL7 MLLP specification documents this long-used transport convention and its reliable-transport extensions ².

Important implementation details include:

• do not assume one socket read equals one message;
• handle a message split across reads and multiple messages in one read;
• enforce maximum frame size and idle timeouts;
• reject or quarantine malformed framing without losing the next good frame;
• agree on character encoding and preserve segment carriage returns;
• use protected network transport where required—MLLP framing itself is not encryption.

The unavoidable ambiguous timeout

Consider this sequence:

1. The sender transmits MSG00001.
2. The receiver commits the admission.
3. The receiver sends AA.
4. The connection drops before the sender receives the ACK.
5. The sender times out.

The sender cannot tell whether step 2 occurred. If it retries, the receiver may see the same business event twice. Therefore reliable delivery requires idempotent or duplicate-aware processing, not only retries. A receiver might use the control ID plus sending application and facility within a defined retention window, but business identifiers and event rules may also be needed. Control IDs are not automatically globally unique.

A safe retry state machine distinguishes:

• connection failure before a complete frame was sent;
• complete send with no ACK;
• explicit transient error;
• explicit permanent rejection;
• positive acknowledgment with downstream reconciliation still pending.

Backoff, attempt limits, dead-letter handling, and human ownership should be documented. “Keep retrying forever” hides a clinical workflow problem and can overwhelm a recovered destination.

Observe the whole conversation

For each exchange, capture secure, minimum-necessary operational evidence:

• message control ID and acknowledgment correlation;
• event type, version, source, destination, and route;
• send, receive, parse, application, and ACK timestamps;
• outcome code and structured error location;
• retry count, queue age, transformation version, and final disposition.

Measure both technical delivery and workflow reconciliation. A queue can be empty while messages were routed to the wrong destination; all ACKs can be positive while expected encounters are missing.

Practice: design the failure table

For an ADT feed, create rows for connection refused, partial frame, invalid MSH, unsupported event, unknown code, database timeout, ACK lost after commit, and duplicate retry. For each row specify: expected ACK or connection behavior, retryability, duplicate control, alert threshold, responsible team, and reconciliation evidence. The exercise turns “reliable interface” into testable behavior.