If you work on healthcare integration, ADT is the message type you will see most and depend on most. ADT — Admit, Discharge, Transfer — is the HL7 v2 message family that carries patient demographics and visit events, and it functions as the backbone feed of a healthcare ecosystem: the source of truth that tells every downstream system who the patients are and what is happening with their visits. Understanding ADT — its events, its structure, and how it actually flows — is foundational to building reliable healthcare interfaces. This guide explains it for developers, from the trigger events to the segments to the real-world patterns.

A scope note: this is a technical explainer, not legal advice, and ADT messages carry PHI, which must be protected with appropriate security and a BAA where applicable.

What ADT Is and Why It Matters

ADT messages communicate patient demographic information and visit (encounter) events between systems. When a patient is admitted, transferred, discharged, registered, or has their information updated, an ADT message announces that event, carrying the patient’s identity and visit details. ADT is the most common HL7 v2 message type in practice for a reason: nearly every system in a hospital needs to know about patients and their visits, and ADT is how that information propagates. It is, in effect, the patient-identity and encounter backbone of the entire integration landscape.

ADT’s Role in the Healthcare Ecosystem

In most environments, a registration or ADT system (often part of the EHR or a hospital information system) is the source of truth for patient identity and visits, and it emits ADT messages whenever something changes. Downstream systems — laboratory, radiology, pharmacy, billing, and many others — subscribe to the ADT feed so they know about patients and visits without each maintaining its own registration. When a lab system receives an order, it already knows the patient because an ADT message told it. This hub-and-spoke pattern, with ADT as the feed, is why ADT integration is so central: get it right and the downstream systems have trustworthy patient and visit data; get it wrong and errors ripple everywhere.

ADT Message Structure

An ADT message, like all HL7 v2 messages, is composed of segments — lines of pipe-and-hat-delimited fields — each carrying a part of the information. The core segments you will encounter in ADT include:

MSH (Message Header) — metadata about the message itself: sending and receiving systems, message type, timestamp, and control ID. Every message starts here.
EVN (Event Type) — the trigger event and when it occurred.
PID (Patient Identification) — the patient’s demographics: identifiers, name, date of birth, address, and more. This is the heart of ADT.
PV1 (Patient Visit) — the visit/encounter details: patient class, location, attending provider, admission and discharge information.

Beyond the core, ADT messages often carry additional segments depending on the event and configuration: PD1 (additional demographics), NK1 (next of kin), AL1 (allergies), DG1 (diagnosis), and others. Real-world messages also frequently include Z-segments — site-specific custom segments — which is one of the realities that makes ADT integration less uniform than the standard alone suggests.

The Key Trigger Events

ADT defines a large set of trigger events — the “A” codes — and there are over fifty of them, though most integrations care about a core subset. The most common include:

A01 – Admit/visit notification: a patient is admitted (typically inpatient).
A02 – Transfer a patient: the patient moves location within the facility.
A03 – Discharge/end visit: the patient is discharged or the visit ends.
A04 – Register a patient: registration for an outpatient or emergency visit (rather than an inpatient admit).
A05 – Pre-admit a patient: the patient is pre-admitted ahead of an expected visit.
A08 – Update patient information: a general update to patient or visit information — one of the most frequently used and important events.
A11 – Cancel admit / A12 – Cancel transfer / A13 – Cancel discharge: reversals of prior events, which downstream systems must handle correctly.
A28 – Add person information / A31 – Update person information: managing person-level (not just visit-level) records.
A40 – Merge patient: merging duplicate patient records — one of the trickiest events to handle correctly.

Knowing which events your integration needs to act on, and which it can ignore, is one of the first design decisions in building an ADT interface.

Acknowledgments

HL7 v2 messaging is acknowledged: when a system receives an ADT message, it returns an ACK to confirm receipt and outcome, using the MSA (Message Acknowledgment) segment to indicate acceptance, error, or rejection. There are two acknowledgment modes — original mode, where the receiver acknowledges after processing, and enhanced mode, which separates accept-level and application-level acknowledgments. Handling acknowledgments correctly is essential for reliability: a sender needs to know whether its message was received and processed, and silent failures in acknowledgment handling are a common source of lost or unprocessed messages.

How ADT Flows in Real Integrations

In practice, ADT messages rarely flow point-to-point from one system to every other; they flow through an interface engine that receives the ADT feed and routes, transforms, and filters messages to the systems that need them. Mirth Connect (NextGen Connect) is a common engine for this — receiving ADT, applying any transformation or filtering, and delivering to downstream systems, each of which may want different events or formats. See our Mirth Connect integration practice. This central routing is what makes the ADT feed manageable: rather than every system subscribing directly to the source and handling its own quirks, the engine normalizes and distributes, and it is where much of the real integration work — routing rules, transformations, error handling — actually lives.

Best Practices and Common Challenges

A few realities shape good ADT integration. Subscribe to the events you actually need and handle them explicitly, rather than trying to process everything. Handle A08 updates carefully, since patient and visit information changes frequently and downstream data must stay current. Treat merges (A40) as a special, tricky case, because merging patient records incorrectly can attach data to the wrong patient — a serious problem. Design for idempotency and ordering where possible, since messages can arrive out of order or more than once. Build robust acknowledgment and error handling so failures are visible and recoverable. And expect Z-segments and local variations, because real ADT feeds rarely match the textbook exactly. These are the things that separate an ADT interface that works in a demo from one that holds up in production.

ADT and the Move to FHIR

As organizations adopt FHIR, ADT events map into the FHIR world — an admit or discharge relates to an Encounter resource, patient demographics to a Patient resource, and so on. ADT does not disappear; it commonly continues to flow as v2 while a bridge translates the relevant events into FHIR for modern apps and APIs. If you are working across both standards, our HL7 v2 to FHIR migration guide covers how that bridging works, and our HL7 vs FHIR comparison covers how the two relate more broadly.

How Taction Helps

We build and maintain HL7 ADT integrations — designing the interfaces that consume and route the ADT feed, handling the events that matter (including the tricky updates and merges), implementing reliable acknowledgment and error handling, and managing the routing and transformation through interface engines like Mirth Connect. We also bridge ADT into FHIR where modern apps and APIs need it. With deep HL7 and integration experience, ISO 27001-certified security, and PHI handled under a signed BAA, we make the patient-and-visit backbone reliable. Our HL7 integration practice, within our healthcare software work, covers the full scope.

Frequently Asked Questions

What does ADT stand for in HL7?

ADT stands for Admit, Discharge, Transfer. ADT messages carry patient demographic information and visit (encounter) events, and they are the most common HL7 v2 message type — effectively the patient-identity and encounter backbone that tells downstream systems who the patients are and what is happening with their visits.

What are the most important ADT events?

The common core includes A01 (admit), A02 (transfer), A03 (discharge), A04 (register, for outpatient/ED), A05 (pre-admit), A08 (update patient information), the cancel events A11/A12/A13, the person-info events A28/A31, and A40 (merge patient). There are over fifty ADT events, but most integrations act on a subset, so deciding which to handle is an early design step.

What segments are in an ADT message?

The core segments are MSH (message header), EVN (event type), PID (patient identification), and PV1 (patient visit). Depending on the event and configuration, ADT messages may also include PD1, NK1 (next of kin), AL1 (allergies), DG1 (diagnosis), and often site-specific Z-segments.

What is an ACK in HL7 ADT?

An ACK is the acknowledgment a receiving system returns to confirm receipt and outcome of a message, using the MSA segment to indicate acceptance, error, or rejection. There are original and enhanced acknowledgment modes. Handling ACKs correctly is essential for reliability, since silent acknowledgment failures cause lost or unprocessed messages.

Why is the A40 merge event tricky?

A40 merges duplicate patient records, and handling it incorrectly can attach clinical data to the wrong patient — a serious safety and data-integrity problem. Merges require careful handling across all systems consuming the ADT feed, which is why they are treated as a special case rather than a routine update.

How does ADT relate to FHIR?

ADT events map into FHIR — an admit or discharge relates to an Encounter resource, demographics to a Patient resource, and so on. ADT does not disappear with FHIR adoption; it commonly keeps flowing as HL7 v2 while a bridge translates the relevant events into FHIR for modern apps and APIs.

Building or maintaining HL7 ADT integrations? Schedule a free consultation →

This article is a technical explainer, not legal advice. Reviewed by Taction Software’s healthcare integration engineering team. ISO 27001-certified information security management. ADT messages carry PHI, protected under a signed BAA.

HL7 ADT Messages Explained: Events, Segments & Use