HL7 ADT Messages: Admission, Discharge, Transfer

HL7 ADT messages carry patient administration events — the admissions, discharges, transfers, and registrations that establish and update the patient context every other system depends on. ADT is usually the first interface a hospital builds and the busiest one it runs, because nearly every clinical and ancillary system needs to know who the patient is and where they are. This page explains what an ADT message represents, when each trigger event fires, every segment the message can carry and what each one holds, and how an ADT message maps to a FHIR Bundle. Sample content is constructed for illustration with fictional identifiers.

What an ADT message represents

An ADT message communicates a change in a patient's administrative state. When registration admits, transfers, discharges, or updates a patient, the source system emits an ADT message describing the event, and every downstream subscriber applies that change to its own copy of the patient and visit. The message is unsolicited: the source pushes it to all interested systems rather than waiting to be asked.

The sender is typically the registration or patient-administration system, and the receivers are many — the EHR, the laboratory, radiology, pharmacy, dietary, and billing. A single admission can reach all of them at once, which is the pattern integrators mean when they talk about the ADT feed. Because so many systems consume it, ADT is the foundation other interfaces build on: an order or result interface assumes the patient already exists from a prior ADT message, so a gap in the feed surfaces as failures in seemingly unrelated places.

Every ADT message shares the same skeleton — an MSH header, an EVN event segment, a PID patient segment, and a PV1 visit segment — and the trigger-event code in MSH-9 tells the receiver which event occurred.

When ADT messages are sent (the ADT feed)

ADT messages are sent the instant an administrative event occurs, which makes the ADT feed a continuous real-time stream rather than a batch. A single inpatient stay produces a sequence of related events: an admit, one or more transfers, and a discharge, with demographic updates interspersed. Corrections and cancellations are sent as their own events rather than as edits to a prior message.

Common ADT messages

Each event reuses the ADT skeleton with different optional segments and cardinality. The ones an integration team handles most often:

• ADT^A01 – Admit / visit notification — inpatient admit, the first message in most encounters.
• ADT^A02 – Transfer a patient — movement between units, rooms, or beds.
• ADT^A03 – Discharge / end visit — the encounter ends.
• ADT^A04 – Register a patient — outpatient or emergency registration.
• ADT^A05 – Pre-admit a patient — a scheduled pre-admission ahead of arrival.
• ADT^A06 – Change an outpatient to an inpatient — an outpatient encounter becomes an admission.
• ADT^A08 – Update patient information — a demographic or visit change.
• ADT^A11 – Cancel admit — reverses a prior A01.
• ADT^A13 – Cancel discharge — reverses a prior A03.
• ADT^A17 – Swap patients — exchanges two patients' locations.

ADT defines more than sixty trigger events in total. The event in MSH-9 drives the handling, and the v2-to-FHIR Implementation Guide publishes Bundle maps for A01, A02, A05, A06, A09, A11, and A17. Treat cancellation events as compensating transactions that reverse a prior event rather than as deletions.

Integration topology

The diagram shows the ADT system broadcasting events through the integration engine to every downstream subscriber.

{{diagram: registration/ADT system → ADT message → integration engine → EHR / Lab / Radiology / Pharmacy / Billing}}

Typical senders: registration system, patient-administration system, EHR.

Typical receivers: EHR, laboratory information system, radiology, pharmacy, dietary, billing, and ancillary clinical apps.

Direction: unidirectional broadcast from the source of truth to many subscribers.

Segments in an ADT message

Below is every segment that can appear in an ADT message, in the order it occurs, with what each carries in this context. Cardinality follows HL7 notation: [X] optional, {X} repeating, [{X}] optional and repeating; a bare code is required. Each segment code links to its canonical field-by-field reference.

[ ] = optional, { } = repeating

Exact composition varies by trigger event: a discharge populates the discharge fields in PV1 that an admit leaves empty, allergy and insurance segments appear only when that data accompanies the event, and several segments above were added in later v2 releases. The canonical segment pages carry the full field-by-field detail.

Sample ADT message

Note. Constructed for illustration. Patient identifiers, dates, and names are fictional.

MSH|^~&|REGISTRATION|MERCYGEN|EHR|MERCYGEN|201912312359||ADT^A01^ADT_A01|MSG00001|P|2.5.1
EVN|A01|201912312359||01|JSMITH
PID|1||MR12345^^^MERCYGEN^MR||DOE^JOHN^Q||19800101|M||C|100 MAIN ST^^SPRINGFIELD^IL^62704||(555)555-0100
NK1|1|DOE^JANE^A|SPOUSE||(555)555-0142
PV1|1|I|3WEST^301^A||||1234^SMITH^JANE^A^^^MD|||MED||||ADM|A0|||1234^SMITH^JANE^A^^^MD|S|V0001|A|||||||||||||||||||MERCYGEN|||||201912312359
DG1|1|ICD-10|R51.9^Headache, unspecified^I10|HEADACHE|201912312359|A

What this sample shows

The ADT^A01 in MSH-9 marks an inpatient admission, and the matching A01 in EVN repeats the trigger with its timestamp. PID carries the medical record number MR12345 and a compound name, NK1 records a spouse contact, and PV1 places the patient as an inpatient (I) in a specific room with an attending provider. The DG1 carries a coded admit diagnosis.

Working with ADT messages

Identifying the trigger event

Switch on MSH-9 to route. The trigger event — A01, A03, A08, and so on — determines whether the receiver opens a visit, closes one, or updates an existing record, so the event drives the handling far more than the message type alone.

Idempotency and deduplication

Use MSH-10, the message control id, as the deduplication key. ADT feeds are frequently replayed after an outage, and treating a repeated control id as a duplicate prevents a replayed admit from creating a second visit.

Out-of-order delivery

An A02 transfer can arrive before its A01 admit if a connection drops and recovers. Sequence by the event time in EVN-2 or the admit timestamp in PV1-44 rather than trusting arrival order.

Cancel and correction events

Events such as A11 cancel a prior admit and A13 cancel a prior discharge. Handle them as compensating transactions that reverse the earlier state, not as record deletions, so the audit trail of what happened stays intact.

Vendor variance

Vendor variance. Epic and Cerner both emit ADT but differ in how they populate visit and account identifiers and in which optional segments they include; confirm a partner's field usage against their interface specification rather than assuming the base standard.

FHIR equivalent

An ADT message maps to a FHIR Bundle whose backbone is a MessageHeader plus the Patient and Encounter the event concerns. The v2-to-FHIR Implementation Guide derives the MessageHeader and Provenance from MSH and EVN, the Patient from PID, and the Encounter from PV1, with optional Coverage, AllergyIntolerance, and Condition resources produced from the insurance, allergy, and diagnosis segments when present.

The Implementation Guide publishes official Bundle maps for seven ADT trigger events; messages outside that set are composed from the per-segment maps.

Common pitfalls

Pitfall. Reading identifiers from PID-2 instead of PID-3. PID-3 is the repeating identifier list that carries the medical record number and other ids; PID-2 is deprecated and many systems leave it blank.

Pitfall. Assuming a fixed date-time precision. Some senders use YYYYMMDD and others a full timestamp with an offset; do not assume a timezone — normalize on ingest.

Pitfall. Treating A08 as a small update. An update can completely restate the demographics in PID, so apply it as a full upsert of every field present rather than a partial patch.

How Vorro handles ADT messages

Vorro ingests the ADT feed over MLLP or another transport, deduplicates on MSH-10, routes by the trigger event in MSH-9, and fans each event out to every subscribed destination in the format that system expects. Where the v2-to-FHIR Implementation Guide provides a published map, Vorro emits the corresponding FHIR Bundle; for other events it composes the Bundle from the per-segment maps.

Related messages

• ORM — orders that assume the patient context an ADT message establishes.
• ORU — results that return against that same patient and visit.
• MDM — documents filed for the patient identified in the ADT feed.

Sources

• HL7 v2-to-FHIR IG — message maps index
• HL7 v2-to-FHIR IG — ADT_A01 to Bundle ConceptMap
• HL7 Version 2.5.1 product brief