Healthcare IT Glossary

What is ADT?
Admit-Discharge-Transfer

Every time a patient walks into a hospital, moves between departments, or gets discharged — a cascade of systems needs to know about it. The EHR needs an updated census. Billing needs to track length of stay. The lab needs to know where to send results. Dietary needs to know which beds are occupied. ADT messages are the trigger for all of it — a single event notification that keeps every system in the hospital synchronized in real time.

Certifications

Tell Us Your Requirements

Our experts are ready to understand your business goals.

What is 1 + 1 ?

100% confidential & no spam

Definition of ADT

ADT, which stands for Admit-Discharge-Transfer, is both a category of patient movement events and a family of HL7 messages that communicate those events between healthcare systems. ADT messages are the most common type of HL7 message in healthcare — they form the backbone of patient tracking and census management in hospitals and health systems.

An ADT event occurs whenever a patient’s status changes within a facility: admission to an inpatient bed, transfer from the emergency department to a medical floor, transfer between nursing units, discharge home, discharge to a skilled nursing facility, or death. Each event triggers an ADT message that broadcasts the patient’s updated location, status, and demographics to every connected system.

ADT messages belong to the HL7 Version 2 messaging standard — specifically the ADT message family (message type ADT, with event triggers like A01, A02, A03, etc.). While HL7v2 is decades old, ADT messages remain the dominant real-time patient tracking mechanism in virtually every hospital in the United States.

In simple terms: ADT messages are the hospital’s nervous system — the real-time notifications that tell every system where every patient is, at every moment.

How ADT Works in Healthcare

ADT messages flow from the source system (typically the EHR or hospital information system) to every downstream system that needs to know about patient movements.

Patient registration and admission (A04/A01)
When a patient arrives at the hospital and is registered, the EHR generates an A04 (Register a Patient) message. If the patient is admitted to an inpatient bed, an A01 (Admit/Visit Notification) message is sent. These messages contain the patient’s demographics, insurance information, attending physician, admitting diagnosis, and assigned bed location.
Patient transfer (A02)
When a patient moves from one unit to another — ED to ICU, ICU to medical floor, medical floor to rehab — the EHR generates an A02 (Transfer a Patient) message. The message includes the patient’s new location (point of care, room, bed) and the transferring/receiving providers. Systems like lab information systems, pharmacy, dietary, and nursing assignment boards update their records accordingly.
Patient discharge (A03)
When a patient is discharged, the EHR generates an A03 (Discharge/End Visit) message. This triggers downstream actions: the billing system finalizes charges and initiates claims processing, the bed management system marks the bed as available for cleaning and reassignment, and the care transition workflow generates a discharge summary for the patient’s outpatient providers.
Patient updates (A08, A28, A31, A40)
ADT also handles non-movement events: A08 (Update Patient Information) updates demographics, A28 (Add Person Information) creates a new patient record, A31 (Update Person Information) updates the master patient index, and A40 (Merge Patient) handles patient identity merges when duplicate records are discovered.
Cancel and swap events
ADT includes messages for correcting errors: A11 (Cancel Admit), A12 (Cancel Transfer), A13 (Cancel Discharge), and A17 (Swap Patients) — which handles the situation where two patients are accidentally assigned to each other’s beds.
The message flow
The EHR generates an ADT message → the message is sent to a Mirth Connect integration engine or similar middleware → the engine routes copies of the message to each downstream system (lab, pharmacy, billing, radiology, dietary, bed management, patient portal) → each system processes the message and updates its own records → acknowledgment messages (ACKs) flow back to confirm receipt.

Key ADT Standards and Specifications

Legacy
HL7v2 ADT Message Structure
Every ADT message follows the HL7v2 segment structure. The key segments in an ADT message are:
Legacy
ADT Event Triggers
The most common ADT event types: A01 (Admit), A02 (Transfer), A03 (Discharge), A04 (Register), A05 (Pre-admit), A06 (Change Outpatient to Inpatient), A07 (Change Inpatient to Outpatient), A08 (Update Patient Info), A11 (Cancel Admit), A12 (Cancel Transfer), A13 (Cancel Discharge), A28 (Add Person), A31 (Update Person), A40 (Merge Patient). Each event type has specific required and optional segments.
Legacy
ADT and FHIR
While ADT remains an HL7v2 domain, FHIR provides equivalent concepts through the Encounter resource (tracking admissions, transfers, and discharges) and FHIR Subscriptions for event-driven notifications. Organizations building new patient tracking capabilities should consider FHIR-based approaches, while maintaining HL7v2 ADT interfaces for legacy system connectivity.
Legacy
IHE Profiles
The IHE Patient Administration Management (PAM) profile standardizes how ADT messages are used in practice — defining precise message content and workflow expectations for admission, discharge, transfer, and merge events. Implementing against IHE PAM reduces the variability that plagues ad-hoc HL7v2 ADT implementations.
MSH(Message Header) — Message type, sending/receiving system, timestamp
EVN(Event Type) — Event trigger (A01, A02, A03, etc.) and event timestamp
PID(Patient Identification) — Patient demographics, medical record number, SSN
PV1(Patient Visit) — Admission type, assigned bed, attending physician, visit number
PV2(Patient Visit Additional) — Admit reason, expected discharge date, visit description
NK1(Next of Kin) — Emergency contacts and responsible parties
IN1/IN2(Insurance) — Primary and secondary insurance information
DG1(Diagnosis) — Admitting and working diagnoses (ICD-10 coded)
AL1(Allergy) — Patient allergy information
Building an ADT integration? Let’s talk.
Book a free call

Implementation Considerations

ADT integration is among the most critical — and most error-prone — HL7 interfaces in a hospital.

ADT is high-volume and real-time
In a busy hospital, hundreds or thousands of ADT messages flow per day. Every system receiving ADT must process messages in near real-time to maintain census accuracy. Message queuing, retry logic, and dead-letter handling in your integration engine must be production-grade — a backlog of unprocessed ADT messages means systems across the hospital are showing incorrect patient locations.
The “HL7 dialect” problem is worst with ADT
The HL7v2 standard is flexible by design, which means every hospital implements ADT slightly differently. Field mappings, segment usage, custom Z-segments, and local conventions vary between sites. When connecting to a new EHR or hospital system, expect to spend significant time on message mapping and transformation — even between two systems that both “support HL7v2 ADT.”
Patient merge (A40) is the hardest event to handle
When duplicate patient records are identified and merged, an A40 message instructs all downstream systems to combine the duplicate records into a single identity. Systems that don’t handle A40 correctly end up with orphaned records, split charts, and clinical safety risks. Test merge scenarios thoroughly during integration.
Bed management depends entirely on ADT accuracy
If ADT messages are delayed, dropped, or processed out of order, the bed management system shows incorrect occupancy — leading to double-bookings, delayed admissions, and housekeeping confusion. Build monitoring dashboards that track ADT message latency and error rates in real time.
ADT feeds
care coordination workflows. Admission and discharge notifications are increasingly shared outside the hospital — notifying primary care physicians, health plans, and health information exchanges that a patient has been admitted or discharged. These ADT-based notifications support care transition programs, readmission reduction, and payer care management workflows.
Security and compliance
ADT messages contain extensive PHI — patient names, medical record numbers, diagnoses, insurance information, and locations. All ADT interfaces must be secured with encryption in transit and access controls on the integration engine.

How Taction Helps with ADT

At Taction, our integration team has built and maintained ADT interfaces across hundreds of hospital and health system connections — from single-facility implementations to multi-site enterprise deployments.

What we do:

Whether you’re standing up ADT for a new facility, connecting a new downstream system, or troubleshooting interface reliability issues, our healthcare integration team delivers the HL7 depth and operational reliability these critical interfaces demand.

ADT interface development
We build custom HL7v2 ADT interfaces connecting EHR systems to labs, pharmacies, billing, bed management, dietary, and every downstream system that depends on patient movement data.
Integration engine configuration
We configure Mirth Connect ADT channels with message routing, transformation, filtering, error handling, and acknowledgment management — handling the vendor-specific “dialects” that make ADT integration complex.
Patient merge handling
We build robust A40 merge processing across all connected systems, ensuring patient identity consolidation is complete, consistent, and auditable.
ADT-based care notifications
We build ADT notification feeds for health plans, primary care networks, and HIEs — supporting readmission reduction and care transition programs.
ADT monitoring and alerting
We build real-time monitoring dashboards that track ADT message throughput, latency, error rates, and unacknowledged messages across all connected systems.

Explore Related Terms

Ready to discuss your ADT project?

Schedule a free call

Ready to Discuss Your Project With Us?

Your email address will not be published. Required fields are marked *

What is 1 + 1 ?

What's Next?

Our expert reaches out shortly after receiving your request and analyzing your requirements.

If needed, we sign an NDA to protect your privacy.

We request additional information to better understand and analyze your project.

We schedule a call to discuss your project, goals. and priorities, and provide preliminary feedback.

If you're satisfied, we finalize the agreement and start your project.