Skip to content
Contact Us

HL7 ADT Messages: Event Types & Structure

HL7 ADT (Admit, Discharge, Transfer) messages are the most widely used HL7 v2 message type, handling patient movement and registration events across healthcare facilities. Every hospital runs ADT interfaces — they are the backbone of patient census, bed management, and downstream system synchronization.

A typical ADT message contains these segments in order:

SegmentNameRequiredPurpose
MSHMessage HeaderYesSender, receiver, message type, version
EVNEvent TypeYesTrigger event code and timestamp
PIDPatient IdentificationYesMRN, name, DOB, demographics
PD1Additional DemographicsNoPrimary care provider, living will
PV1Patient VisitYesPatient class, location, attending MD
PV2Patient Visit (Additional)NoExpected length of stay, admit reason
NK1Next of KinNoEmergency contacts (repeating)
IN1InsuranceNoPrimary/secondary payer information
IN2Insurance (Additional)NoExtended insurance details
GT1GuarantorNoGuarantor demographics and employer
AL1AllergyNoPatient allergies (repeating)
DG1DiagnosisNoDiagnosis codes (repeating)

HL7 v2 defines over 40 ADT trigger events. These are the most commonly implemented:

EventNameDescription
A01Admit/Visit NotificationPatient admitted as inpatient or begins an encounter
A02Transfer a PatientPatient moved from one location to another
A03Discharge/End VisitPatient discharged from facility
A04Register a PatientOutpatient or emergency registration
A05Pre-Admit a PatientFuture admission scheduled
A06Change Outpatient to InpatientPatient class change
A07Change Inpatient to OutpatientPatient class change
A11Cancel AdmitReversal of A01
A12Cancel TransferReversal of A02
A13Cancel DischargeReversal of A03
EventNameDescription
A08Update Patient InformationDemographics or visit data changed
A28Add Person InformationNew person record (not visit-specific)
A31Update Person InformationPerson-level update (not visit-specific)
A40Merge PatientTwo patient records merged into one
A41Merge AccountTwo accounts merged
A44Move AccountAccount reassigned to different patient
EventNameDescription
A09Patient Departing (Tracking)Temporary departure from assigned location
A10Patient Arriving (Tracking)Arrival at temporary location
A15Pending TransferTransfer requested but not yet executed
A16Pending DischargeDischarge requested but not yet executed
A21Patient Goes on LeaveLOA from inpatient bed
A22Patient Returns from LeaveLOA return
A25Cancel Pending DischargeReversal of A16
A26Cancel Pending TransferReversal of A15

The most commonly implemented HL7 ADT message types are HL7 ADT A01 (admission), HL7 ADT A04 (registration), and HL7 ADT A08 (patient update). These three events account for the majority of ADT interface traffic in most hospitals.

A complete admission message with all common segments:

ADT^A01 — Admit/Visit Notification
Header Patient Clinical Order/Result Financial

A08 (Update Patient) vs A31 (Update Person)

Section titled “A08 (Update Patient) vs A31 (Update Person)”

The distinction between A08 and A31 trips up many implementers:

  • A08 updates patient information in the context of a visit (PV1 segment present). Use when the patient has an active encounter.
  • A31 updates person-level information independent of any visit. Used by master patient index (MPI) systems for demographic corrections.

Some EHR vendors (notably Epic) use A08 for both scenarios, while others strictly separate them. Always confirm with the sending system which events they fire and under what conditions.

Merge events are among the most complex ADT operations. When two patient records are merged, the surviving MRN absorbs the deprecated MRN. The A40 message contains:

  • MRG segment: The deprecated (old) patient identifier being merged away
  • PID segment: The surviving (correct) patient identifier

Receiving systems must update all references from the old MRN to the new MRN — lab results, orders, documents, and any other linked data. Incorrect merge handling is a patient safety risk.

In a large hospital, ADT feeds can generate thousands of messages per hour during shift changes, morning registrations, and discharge waves. Key design considerations:

  • Message queuing: Buffer ADT messages during downstream system outages
  • Idempotency: Handle duplicate messages gracefully (same control ID)
  • Order preservation: ADT events must be processed in chronological order per patient
  • Filtering: Not every downstream system needs every ADT event — route selectively