ADT stands for Admit-Discharge-Transfer, and the ADT event types are the first HL7v2 messages every integration engineer meets. Every hospital produces them; every EHR emits them; almost every downstream system consumes some subset. Learning the ADT vocabulary is the shortcut from theory into the mechanics of a real integration.
The vocabulary is small. For related walkthroughs, more on healthcare integration collects the surrounding material.
The Six Events You See Most Often
Six ADT events show up in almost every integration:
- A01: admit / register a patient.
- A02: transfer a patient between locations.
- A03: discharge a patient.
- A04: register an outpatient (walk-in, ED presentation).
- A08: update patient information without a state change.
- A11: cancel a previous admit.
Recognizing these six by their event code is the first step. A pass through the site's HL7 v2 segment → FHIR mapping tool surfaces the FHIR equivalents for each.
The FHIR Encounter Mapping
Most ADT events map to state transitions on a FHIR Encounter resource. A01 creates an Encounter in planned or arrived status; A02 updates the Encounter with a new location; A03 sets the Encounter status to finished. The transitions are cleaner in FHIR than they look in v2.
For the anatomy of a single v2 message that carries an ADT event, reading an HL7v2 message when you only know FHIR covers the shape.
A08 Is the Sneaky One
A08 is officially an update. In practice it is used for almost any change that does not fit another event code. Systems emit A08 for demographic updates, insurance changes, allergy updates, and sometimes for changes that another event code would describe better.
Integration engineers who assume A08 means "demographic update" learn otherwise. Treat A08 as "generic update" and parse the actual content to decide the FHIR consequence.
The Cancel Events Have Their Own Rules
A11 cancels a previous admit. A12 cancels a transfer. A13 cancels a discharge. These are the events integration teams forget to handle first, and the cost shows up when a cancelled admit leaves stale FHIR data downstream.
Every integration should handle the cancel events explicitly. Silent handling produces silent bugs. For the specific PID mapping questions these events raise, PID vs Patient: what maps and what doesn't covers the fields.
Merges and Reallocations
A18, A34, A40, and other higher-numbered events handle patient merges and reallocations. When two duplicate patient records get merged in the source system, the downstream integrations need to consolidate their own records to match.
Merges are the most operationally fragile part of ADT integration. Any FHIR-side representation should be able to link Patient resources together and mark the retired one accordingly.
The Acknowledgment Loop
Every ADT message expects an acknowledgment. The receiving system returns an ACK message with a success code (AA), an application error (AE), or a reject (AR). For the specific ACK-code framing, acknowledgment codes: AA vs AE vs AR in production covers what each means and when to send each.
Sending the right code matters because upstream systems adjust their retry behavior based on it. Wrong ACK codes produce runaway retry loops.
The Documentation Habit
Every integration team ends up maintaining a private catalog of which ADT events its upstream systems emit and how each is handled downstream. The catalog is the artifact the on-call reads at 3am when a message arrives with an unexpected event code.
Publishing the catalog internally is the small habit that saves the escalation. Every ADT integration that lands well documents the events explicitly rather than treating them as institutional memory.
Sources
- HL7 Confluence v2-to-FHIR project page including ADT event - HL7 Confluence v2-to-FHIR project page including ADT event mappings