ADT and the Patient Lifecycle (A01 to A08 and Merges)

ADT is a state-change stream

ADT messages communicate patient-administration events: registration, admission, transfer, discharge, demographic update, cancellation, merge, and related changes. Laboratory, pharmacy, radiology, billing, bed management, portals, and analytics may all depend on this stream to know who the patient is, which encounter is active, and where care is occurring.

The trigger event in MSH-9.2 names what happened. The message structure supplies the data needed to apply that event. HL7’s Patient Administration chapter defines these events as distinct interactions rather than treating every message as a generic patient record ¹.

Common events and their intended transitions

The table is a learning map, not a universal local workflow. Message structure, required fields, and receiver behavior depend on version and implementation profile ².

Event, patient, and encounter are separate keys

An ADT message can carry several identifiers:

• MSH-10 identifies the message for correlation;
• PID-3 carries patient identifiers, potentially with multiple authorities and types;
• PV1-19 or a profiled equivalent may identify the visit;
• location, account, and episode identifiers may add more workflow context.

Do not substitute one for another. A message control ID is not a patient ID. A patient ID does not uniquely select one encounter. A room and bed are not stable encounter identifiers. The receiving system should resolve the patient and encounter using the agreed authorities before applying the state change.

This matters when the same person has an emergency visit and an inpatient stay, when two facilities issue similar numbers, or when a transfer message arrives after discharge. “Find the patient and update the latest visit” is a dangerous fallback.

A worked lifecycle

Imagine a scheduled surgical admission:

1. A05 creates a pre-admit encounter for Monday.
2. A08 corrects the patient’s phone number before arrival.
3. A01 converts or activates the encounter when the patient is admitted.
4. A02 transfers the patient from recovery to an inpatient unit.
5. another A02 changes the bed within that unit.
6. A03 discharges the encounter.

Each event should be idempotent or duplicate-aware. Replaying the second A02 must not create a second encounter or a fictional second transfer. The receiver should retain enough provenance to answer which message last changed the location and which source owns that attribute.

An A08 deserves special care. It is commonly described as “update patient information,” but the local profile must say which patient and visit fields may be updated, whether blanks mean no change, and who owns each value. An A08 should not become permission to overwrite every stored demographic or encounter field.

Corrections are new events

Distributed systems cannot “unsend” a message already applied elsewhere. A cancellation communicates a new fact: an earlier event should be reversed. To process one safely, a receiver needs the targeted encounter, a valid current state, and a rule for the downstream consequences.

If an A13 cancels discharge, questions follow:

• Is the bed assignment restored or must it be reassigned?
• Were orders closed and should any reopen automatically?
• Did billing, pharmacy, or notifications already act?
• Is a new event required to correct those systems?

Reversal is rarely equivalent to deleting a log row. Preserve the original event, cancellation, resulting state, and audit trail.

Merges require identity governance

An A40 communicates that identifiers previously treated as separate belong to one patient identity. A safe merge identifies the surviving and prior identifier sets under explicit assigning authorities. The receiver should not merely replace text everywhere or delete the prior record.

Controls should include:

• validation that both identities and authorities are recognized;
• a patient-identity or health-information-management review path;
• preservation of aliases, provenance, and merge history;
• propagation to dependent systems and indexes;
• a documented unmerge or correction process;
• safeguards against automatically combining contradictory clinical data.

A false merge is one of the most serious interoperability failures because it can put one person’s information in another person’s chart. Treat AA as confirmation of processing, not proof that the merge was clinically correct.

Expect duplicate and out-of-order events

Network retry, queue recovery, maintenance windows, multiple routes, and source defects can reorder or repeat ADT messages. Define receiver behavior for:

• A02 before the corresponding A01;
• A03 for an unknown visit;
• A08 before patient identity is established;
• a duplicate A01 with the same control ID;
• the same business event resent with a new control ID;
• late A02 after A03;
• cancel event without the original event.

Possible controls include temporary quarantine, source query, bounded retry, sequence checks, version timestamps, and human reconciliation. Silently applying an event to the most convenient record is not a control.

Reconcile the clinical census

Message counts and ACK rates are necessary but insufficient. Reconciliation asks whether destination state matches authoritative source state. Useful measures include:

• active encounters by facility and unit;
• missing, duplicate, or unmatched visit identifiers;
• ADT queue age and late-event count;
• merge and cancellation volume with unresolved exceptions;
• sampled comparison of patient, encounter, location, class, admit, and discharge values.

Practice: write the receiver state machine

Create states such as unknown, pre-admitted, active, discharged, and cancelled. Place A05, A01, A02, A03, A11, A12, and A13 on valid transitions. For each invalid transition, define whether to reject, quarantine, query, or route for human review. Then add duplicate detection and an A40 identity-merge procedure. The completed state table is more useful than a diagram that shows only the happy path.