HL7 ADT Messages Explained: A Complete Guide to Patient Event Notifications

HL7 ADT (Admit, Discharge, Transfer) messages are the most widely used message type in healthcare interoperability. Every time a patient is admitted to a hospital, discharged, transferred between units, or has their demographic information updated, an ADT message fires — notifying downstream systems in real time.

Understanding ADT messages is foundational for anyone working in HL7 integration. This guide explains what ADT messages are, the most important event types, the key HL7 segments they carry, and how to implement ADT processing using Mirth Connect.

What are ADT Messages?

In HL7 v2, ADT stands for Admit, Discharge, Transfer. ADT messages belong to the A category of HL7 v2 message events and are used to communicate patient registration and movement events between healthcare systems.

An ADT message is triggered by a clinical or administrative event in the source system — typically the EHR or patient registration system. The message is then transmitted (usually via MLLP over TCP/IP) to any system that needs to know about that patient event: labs, pharmacies, radiology systems, billing systems, care management platforms, and more.

ADT messages share a common structure defined by HL7 v2:

• MSH — Message Header segment (always the first segment)
• EVN — Event Type segment (identifies the specific event)
• PID — Patient Identification segment (patient demographics)
• PD1 — Patient Additional Demographic segment (optional)
• NK1 — Next of Kin segment (emergency contacts, guarantors)
• PV1 — Patient Visit segment (encounter/visit information)
• PV2 — Patient Visit - Additional Information (optional)
• DG1 — Diagnosis segment (optional, included in some ADT types)
• AL1 — Patient Allergy Information (optional)
• OBX — Observation/Result segment (optional, for clinical data)

Common ADT Event Types

HL7 v2 defines ADT events from A01 through approximately A60, though not all are widely used. Here are the most important ones:

Patient Registration & Admission Events

• A01 — Admit/Visit Notification: A patient is admitted to an inpatient unit. This is the most common ADT event. It triggers lab, pharmacy, billing, and bed management workflows.
• A04 — Register a Patient: A patient is registered for an outpatient visit or emergency department encounter. Similar structure to A01 but for non-inpatient settings.
• A05 — Pre-Admit a Patient: A pre-admission is recorded before the patient arrives. Used for scheduled procedures and elective admissions.
• A14 — Pending Admit: Notification that an admission is expected in the near future.

Transfer & Movement Events

• A02 — Transfer a Patient: A patient is physically moved from one location to another within the facility (e.g., from ICU to a step-down unit). The PV1 segment reflects the new location.
• A06 — Change Outpatient to Inpatient: An outpatient or observation patient is converted to an inpatient admission.
• A07 — Change Inpatient to Outpatient: The reverse — an inpatient is reclassified to outpatient status.

Discharge Events

• A03 — Discharge/End Visit: A patient is discharged from the facility. This event closes the encounter in downstream systems and triggers billing, care management, and post-discharge workflows.
• A16 — Pending Discharge: Notification that discharge is expected soon — useful for care coordination and transport planning.

Demographic Update Events

• A08 — Update Patient Information: Patient demographic information has been updated (name, address, insurance, etc.) without a physical patient movement. A08 is critical for keeping downstream systems in sync with the MPI (Master Patient Index).
• A28 — Add Person Information: A new person record is created in the system (pre-registration or MPI update).
• A31 — Update Person Information: An existing person record is updated.
• A40 — Merge Patient — Patient Identifier List: Two patient records are merged — typically used to resolve duplicate MRN situations.

Cancel Events

• A11 — Cancel Admit/Visit Notification: Cancels a previously sent A01. Downstream systems should reverse any workflow triggered by the original admit.
• A12 — Cancel Transfer: Cancels a previous A02 transfer event.
• A13 — Cancel Discharge/End Visit: Cancels a previous A03. The encounter is re-opened in downstream systems.

Key HL7 Segments in ADT Messages

MSH — Message Header

The MSH segment is the first segment of every HL7 v2 message. It identifies the sending application, sending facility, receiving application, receiving facility, date/time, message type, message control ID, and HL7 version. Critical fields for ADT integration:

• MSH-3: Sending Application (e.g., "Epic", "Cerner")
• MSH-9: Message Type (e.g., "ADT^A01^ADT_A01")
• MSH-10: Message Control ID (unique identifier for this message — used in ACK responses)
• MSH-12: HL7 Version (e.g., "2.5.1")

PID — Patient Identification

The PID segment carries all patient demographic information. It is present in virtually every ADT message and is the primary source of patient identity data:

• PID-3: Patient Identifier List — MRN, SSN, and other identifiers (as a repeating field)
• PID-5: Patient Name (Last^First^Middle^Suffix^Prefix)
• PID-7: Date of Birth (YYYYMMDD format)
• PID-8: Administrative Sex
• PID-11: Patient Address
• PID-13: Phone Number (Home)
• PID-18: Patient Account Number
• PID-19: SSN Number (use with caution — PHI)

PV1 — Patient Visit

The PV1 segment describes the patient's current visit or encounter:

• PV1-2: Patient Class (I=Inpatient, O=Outpatient, E=Emergency, P=Preadmit)
• PV1-3: Assigned Patient Location (Point of Care ^ Room ^ Bed ^ Facility)
• PV1-7: Attending Doctor
• PV1-17: Admitting Doctor
• PV1-19: Visit Number (the encounter/visit identifier)
• PV1-44: Admit Date/Time
• PV1-45: Discharge Date/Time

EVN — Event Type

The EVN segment captures metadata about the event itself:

• EVN-1: Event Type Code (A01, A03, A08, etc.)
• EVN-2: Recorded Date/Time (when the event was recorded in the system)
• EVN-6: Event Occurred (when the event actually happened clinically)

NK1 — Next of Kin

The NK1 segment carries emergency contact, next of kin, and guarantor information. It is a repeating segment — multiple NK1 segments can appear in one message.

ADT in Real Healthcare Systems

In a typical hospital environment, ADT messages flow constantly. A large hospital may generate thousands of ADT messages per day. Here are the most common ADT integration patterns in production systems:

• ADT to Lab System: When a patient is admitted (A01), the lab system receives the ADT to create the patient record and associated visit. Subsequent A08 updates keep demographics current. When the patient is discharged (A03), the lab is notified to finalize the encounter.
• ADT to Pharmacy: The pharmacy system uses ADT events to maintain an accurate patient census, trigger medication reconciliation workflows, and track patient location for medication administration routing.
• ADT to Billing: Admissions, transfers, and discharges drive billing workflows. DFT messages carry charge data, but ADT events establish the encounter context.
• ADT to Care Management Platforms: Population health and care management systems consume ADT feeds to trigger care coordination — identifying high-risk patients, alerting care managers to admissions, and tracking transitions of care.
• ADT Notifications (Event-Driven Alerting): Many state HIEs and health information networks distribute ADT event notifications to PCPs and care teams, alerting them when their patients are admitted to or discharged from any participating facility.

Implementing ADT Processing with Mirth Connect

Mirth Connect is the most popular open-source integration engine for HL7 v2 processing and is widely used to build ADT interfaces. Here is the typical implementation pattern:

1. Create an MLLP listener channel — Configure a TCP/MLLP source connector on the port your sending system will connect to. Set the HL7 v2.x data type.
2. Parse the incoming message — Mirth's built-in HL7 parsing converts the raw pipe-delimited message into an XML structure navigable with JavaScript (Rhino engine) or the built-in message tree.
3. Filter by event type — Use a Filter step to route messages based on MSH-9 (message type) or EVN-1 (event type code). You may want separate channels for A01/A04, A02, A03, and A08 events.
4. Transform the message — Use the Transformer to map fields from the incoming HL7 message to the format required by your destination system. This may include field extraction, data type conversions, and value translations (e.g., mapping facility codes).
5. Send to destination — Configure a destination connector — another MLLP channel for an HL7-native destination, an HTTP connector for a REST API, or a database connector to write directly to a database.
6. Handle acknowledgments — Ensure your channel sends HL7 ACK (acknowledgment) messages back to the sender. Configure retry logic for failed deliveries.
7. Monitor and alert — Set up Mirth dashboard alerts for channel errors, message processing failures, and connection timeouts.

For complex ADT routing scenarios — such as multi-facility fan-out, MPI matching, or real-time de-duplication — our HL7 interface messaging team can design and implement a robust, production-grade solution.