Which HL7 ADT events do you actually need to handle?
ADT (Admit, Discharge, Transfer) is the most important message family in HL7 v2 — it's the feed that tells every downstream system who the patient is and where they are. There are over 50 defined ADT trigger events, but you will spend nearly all your time on a handful. This guide covers the ADT events that actually matter in practice, what they mean, and the state-management traps (updates, merges, cancellations) that quietly corrupt patient data when handled naively.
What ADT is for
ADT messages communicate patient administration events: admissions, discharges, transfers, registrations, and demographic updates. They are the source of truth for patient context across the hospital — when the EHR fires an ADT, the lab system, pharmacy, billing, and every ancillary application update their picture of the patient. Because so much depends on it, a broken ADT feed doesn't fail loudly; it silently leaves downstream systems with stale or wrong patient state.
The events you'll actually handle
- A01 — Admit/visit notification: a patient is admitted. Downstream systems create or activate the encounter.
- A02 — Transfer: the patient moved location (unit, bed). Update the current location, don't create a new encounter.
- A03 — Discharge/end visit: the encounter is closed. Stop associating new activity with it.
- A04 — Register a patient: often an outpatient/ED registration rather than an inpatient admit.
- A08 — Update patient information: a demographic or visit change. The workhorse update event — you'll see far more A08s than anything else.
- A11 / A13 — Cancel admit / cancel discharge: reverse a prior event. Must undo, not duplicate.
- A40 — Merge patient identifiers: two records were the same person; merge them. The single most dangerous event to get wrong.
Treat ADT as state, not just messages
The mistake that breaks ADT interfaces is processing each message in isolation. ADT is a stream of changes to patient and encounter state, and order and idempotency matter. An A08 update that arrives out of order can overwrite newer data with older; a re-sent A01 must not create a second encounter. Design your handler around the patient/encounter it mutates, keyed on stable identifiers, and make processing idempotent so a replayed message is safe.
Cancellations and updates are where bugs live
A01 (admit) is easy. The hard part is everything that corrects it. A11 cancels an admit that shouldn't have happened — if you only handle admits, that patient stays 'admitted' forever downstream. A08 quietly changes demographics or visit fields and you must apply exactly the changed state. Handling the happy-path events but ignoring the cancel/update events is the most common ADT integration defect, and it manifests as ghost encounters and drifting demographics weeks later.
The A40 merge: handle with care
A patient merge (A40) says two identifiers refer to the same person and one must be retired in favor of the other. Every downstream system has to re-point historical data from the retired MRN to the surviving one. Get it wrong and you either orphan a patient's history or, worse, merge two different people. Because the blast radius is enormous, merges deserve explicit handling, logging, and often a human-review path rather than silent automatic processing.
Key segments in an ADT message
- PID — patient identification: MRN, name, DOB, and other demographics.
- PV1 — patient visit: encounter class, location, attending provider, admit/discharge times.
- MRG — merge information: present in A40, names the identifier being merged away.
- EVN — event type: the trigger event and its timestamp, corroborating MSH-9.
Building a robust ADT consumer
A dependable ADT interface reads the trigger event, resolves the patient and encounter by stable identifiers, applies the change idempotently, and handles the full lifecycle — admit, transfer, update, discharge, cancel, and merge — not just the happy path. It logs every state transition so you can reconstruct how a patient's record reached its current state. That discipline is what separates an ADT feed you trust from one that quietly drifts out of sync with reality.
