What an ADT Message Is
An ADT message is an HL7 v2 message with message type ADT, sent when a patient event occurs, such as an admission or transfer. Our glossary entry on ADT explains the basics, and this catalog covers each event in detail.
Custom Software
HL7 ADT Message Catalog: Full Reference
The HL7 ADT message catalog is a reference to HL7 v2 Admit, Discharge and Transfer messages, the event notifications hospitals use to share patient registration, location, visit and identity changes between systems. It lists common trigger events, what each means and the segments it carries, helping teams build and troubleshoot ADT interfaces correctly.
ADT feeds are the backbone of hospital integration, and most interface failures trace back to misunderstood events: a missed cancel, a mishandled merge or a flood of updates. Taction Software builds and supports ADT interfaces as part of 200+ healthcare projects since 2013, and this catalog explains each event in practical terms. It expands on our guide to ADT event types in HL7.
Tell Us Your Requirements
Our experts are ready to understand your business goals.
Trusted Partners
Trusted by Industry Leaders Worldwide
Recognition
Awards & Recognitions
What the HL7 ADT Message Catalog Covers
ADT messages tell connected systems what is happening to a patient: who they are, where they are and what kind of visit they are on. Labs, pharmacies, billing systems, bed boards, patient apps and health information exchanges all depend on them. When ADT handling is wrong, results go to the wrong patient, charges are lost and duplicate records multiply. This catalog focuses on the events and segments teams actually encounter in production. The six points below explain how ADT messages work and how to use this reference when designing, testing or troubleshooting any ADT interface.
Message Structure
Every ADT message contains segments, such as MSH, EVN, PID and PV1, each holding related fields separated by pipe characters. The MSH segment identifies the message type and trigger event, for example ADT^A01, which tells receiving systems exactly how to interpret the rest of the message.
Trigger Events
The trigger event code, such as A01 or A08, identifies what happened. Receiving systems use it to decide how to update their records. Handling each trigger event correctly, including cancellations and merges, is the single most important factor in reliable ADT integration.
HL7 Versions
Most ADT interfaces use HL7 v2.3 through v2.5.1, although newer 2.x versions exist. Versions add fields and retire older events, so interface specifications must state the version each sending system uses. Mismatched assumptions about version are a frequent source of parsing errors.
Acknowledgments
Receiving systems usually return an ACK message confirming whether each ADT message was accepted or rejected. Proper acknowledgment handling ensures failed messages are noticed and resent. Ignoring rejected acknowledgments is a common reason ADT data silently goes missing downstream without anyone noticing.
How to Use This Reference
Use the event sections to understand what each trigger means and how downstream systems should respond, then use the segment section to confirm required fields. Our broader guide to HL7 message types and event types covers non-ADT messages as well.
Admission and Registration Events
Admission and registration events create visits and establish where and why a patient is being seen. They are the first messages most downstream systems receive about a patient encounter, so errors here ripple through every later message. Inpatient admissions, outpatient registrations, pre-admissions and pending admissions each have their own trigger event, along with cancellation events that reverse them. Downstream systems must handle all of them, not just the admission itself. The six events below cover admission and registration in HL7 ADT, with practical notes on how receiving systems should process each one correctly.
01
A01: Admit or Visit Notification
A01 signals that a patient has been admitted or has started a visit, most often for inpatients. It carries patient demographics, visit details and location. Receiving systems typically create an active encounter, so duplicate A01 messages for the same visit must be detected and handled safely.
02
A04: Register a Patient
A04 registers a patient for an outpatient or emergency visit rather than an inpatient admission. Many emergency departments and clinics send A04 at arrival. Receiving systems should create an encounter without assuming a bed assignment, because outpatient visits rarely include inpatient location details.
03
A05: Pre-Admit a Patient
A05 records a planned admission before the patient arrives, often for scheduled surgery. It lets labs, pharmacy and scheduling prepare in advance. Receiving systems must treat pre-admits as future visits and wait for A01 before marking the patient as actually present.
04
A14: Pending Admit
A14 indicates an admission is expected soon, such as when an emergency patient is waiting for a bed. Bed management and capacity tools use it to plan. Not every hospital sends A14, so interfaces should not depend on it for critical admission workflows.
05
A11: Cancel Admit or Visit
A11 reverses an A01 or A04, for example when a patient was registered in error. Receiving systems must cancel or void the encounter created earlier. Ignoring A11 leaves phantom visits that confuse clinicians, billing teams and reporting across every connected downstream system.
06
A38: Cancel Pre-Admit
A38 cancels a pre-admission created by A05, often when a scheduled procedure is postponed. Receiving systems should remove or void the planned visit. Missed A38 messages leave future encounters that never happen, cluttering schedules and preparing supplies or medications nobody needs.
Transfer and Movement Events
Transfer and movement events track where a patient is physically located and whether they are temporarily away. Accurate location is essential for bed management, nursing assignments, medication delivery, lab collection and patient tracking displays. Transfers happen frequently during inpatient stays, so these events often generate high message volumes. Each transfer-related event has a matching cancellation or pending variant that must also be handled properly. The six events below cover transfers, tracking and leave of absence in HL7 ADT, with notes on the processing mistakes we see most often in production interfaces.
A02: Transfer a Patient
A02 moves a patient from one location to another, such as between units, rooms or beds. The PV1 segment carries new and prior locations. Receiving systems must update location immediately, because medication delivery, lab collection and nursing lists depend on accurate bed assignments.
A12: Cancel Transfer
A12 reverses a transfer sent in error, returning the patient to their previous location. Receiving systems must restore the prior location rather than treating A12 as a new move. Mishandled transfer cancellations are a common cause of patients appearing in the wrong bed.
A15: Pending Transfer
A15 announces that a transfer is planned but not yet complete, helping receiving units and bed management prepare. Like other pending events, it should not change the patient’s current location. Only the subsequent A02 confirms that the physical move has actually taken place.
A09 and A10: Departing and Arriving
A09 signals a patient departing a location temporarily, such as for radiology, and A10 signals arrival at a new location. They support patient tracking without changing the assigned bed. Tracking systems use them to show where a patient physically is right now.
A21: Leave of Absence
A21 records that a patient has left temporarily, such as a weekend pass, while remaining admitted. Receiving systems should pause certain activities, like scheduled medication administration, without discharging the patient. Treating A21 like a discharge causes serious problems when the patient returns.
A22: Return From Leave of Absence
A22 records the patient’s return from leave of absence, resuming normal inpatient activity. Receiving systems should restore active status and schedules. Pairing A21 and A22 correctly keeps medication administration, nursing tasks and billing accurate throughout the patient’s admission. Missing A22 messages leave patients stuck on leave.
Discharge and Visit Change Events
Discharge and visit change events close encounters, reverse discharges and change a patient’s visit type. They directly affect billing, bed availability, follow-up workflows and quality reporting, so errors here cost money and create safety risks. Patient class changes, such as moving an observation patient to inpatient status, carry significant billing implications. Deletion events must be handled carefully to avoid removing valid data. The six events below cover discharges, reversals and visit type changes in HL7 ADT, with practical notes on how receiving systems should respond to each one in production environments.
A03: Discharge or End Visit
A03 signals that a patient has been discharged or a visit has ended. Receiving systems close the encounter, release beds and trigger follow-up workflows such as discharge summaries. Billing systems often use A03 to finalize charges, so late or missing discharges delay claims.
A13: Cancel Discharge
A13 reverses a discharge sent in error, reopening the encounter. Receiving systems must restore active status, bed assignment and any paused workflows. Hospitals send A13 more often than teams expect, so interfaces must support it rather than treating the first discharge as final.
A16: Pending Discharge
A16 indicates a discharge is expected, helping case management, transport and bed management prepare. It should not close the encounter. Pending discharge events improve patient flow planning when used, but downstream systems must wait for A03 before completing discharge processing.
A06: Change Outpatient to Inpatient
A06 converts an outpatient or observation visit into an inpatient admission, often when an emergency patient is admitted. It changes patient class, which affects billing and reimbursement. Receiving systems must update the existing encounter correctly rather than creating a duplicate admission.
A07: Change Inpatient to Outpatient
A07 converts an inpatient visit to outpatient status, sometimes after utilization review. Like A06, it changes patient class with billing consequences. Revenue cycle systems must process A07 carefully, because incorrect patient class often leads to denied or incorrectly paid claims.
A23: Delete a Patient Record
A23 removes a visit or record, typically one created in error. Receiving systems should apply it cautiously, often marking records inactive rather than physically deleting them. Audit requirements mean deletions must be logged, and some systems require manual review before deleting clinical data.
Patient Information and Identity Events
Patient information and identity events keep demographics, identifiers and allergies accurate across systems. Updates are the most frequent ADT messages in many hospitals, and identity events such as merges are among the most dangerous to get wrong. A mishandled merge can combine two different patients’ records or leave duplicates that split one patient’s history. Master patient index accuracy depends on these events. The six events below cover updates, person-level information, merges, identifier changes and allergy updates, and each needs careful testing before an interface is trusted in production. Identity errors are costly.
A08: Update Patient Information
A08 updates demographics or visit information, such as a new address, insurance or attending physician. Hospitals often send many A08 messages, sometimes for minor changes. Receiving systems should apply updates efficiently and ignore irrelevant changes to avoid unnecessary processing and noise.
A28: Add Person Information
A28 creates a person record without a visit, such as when a patient is registered in the master patient index before any encounter. Receiving systems should create the person without assuming an active visit, keeping person-level and visit-level data clearly separated.
A31: Update Person Information
A31 updates person-level demographics independent of any visit, keeping the master patient index current. It is common in environments that separate person records from encounters. Receiving systems should apply A31 to the person record without altering unrelated visit details. Order matters here.
A40: Merge Patient Identifier List
A40 merges two patient records when duplicates are discovered, identifying the surviving and retired identifiers. It is the most commonly used merge event. Our guide to HL7 ADT patient merge A40 handling explains safe processing. Test merges with realistic duplicate scenarios before trusting them in production.
A47: Change Patient Identifier List
A47 changes a patient identifier without merging records, for example correcting an identifier assigned in error. Receiving systems must update references to the old identifier carefully, so results, orders and documents remain linked to the correct patient after the change.
A60: Update Allergy Information
A60 updates allergy information for a patient, often carried in IAM segments in newer versions. Allergy accuracy is critical for medication safety, so receiving systems such as pharmacy and clinical decision support must process these updates promptly and reliably. Delays create risk.
Key ADT Segments and Fields
Every ADT message is built from segments, and knowing which segments and fields matter most speeds up interface design and troubleshooting. Some segments appear in almost every ADT message, while others appear only for certain events or organizations. Hospitals also add custom Z-segments for local data, which must be documented and agreed with each partner. The six segment groups below cover the fields integration teams rely on most often. For converting these segments into modern resources, our HL7 v2 to FHIR mapping reference shows common mappings. Document every field you depend on.
MSH: Message Header
MSH identifies the sending and receiving applications, message type, trigger event, control ID, processing mode and HL7 version. The control ID is essential for tracking and acknowledgments, and the message type field, such as ADT^A01, tells receiving systems how to parse the message.
EVN: Event Type
EVN records the trigger event, when it was recorded and, in some cases, when it actually occurred. The difference between recorded and event times matters for accurate timelines, especially when messages arrive late or out of order after system downtime.
PID: Patient Identification
PID carries identifiers, name, birth date, sex, address, phone and other demographics. PID-3 holds the patient identifier list, which drives patient matching. Our healthcare master patient index work relies on accurate PID data to prevent duplicates. Validate identifiers at the boundary before any downstream processing.
PV1: Patient Visit
PV1 carries patient class, assigned location, prior location, attending physician, visit number and admit and discharge times. It is central to encounter tracking, bed management and billing, and missing or inconsistent PV1 fields cause many downstream workflow problems. Validate location codes carefully.
NK1 and PD1: Contacts and Additional Demographics
NK1 carries next of kin and emergency contacts, while PD1 carries additional demographics such as primary care provider. These segments support care coordination and patient communication, and they often contain optional fields that different sending systems populate very inconsistently. Treat them as optional.
AL1, DG1 and IN1: Clinical and Insurance Data
AL1 carries allergies, DG1 carries diagnoses and IN1 carries insurance details. They support medication safety, clinical context and billing. Insurance segments are especially important for revenue cycle systems, which depend on accurate coverage information arriving through ADT feeds. Validate coverage fields early.
ADT Integration Pitfalls, Services and Cost
Most ADT problems are predictable, and fixing them early is far cheaper than cleaning up duplicate patients, misrouted results and lost charges later. The pitfalls below appear in almost every hospital environment we work with, and our HL7 ADT integration services address them from design onward. Our work is billed at a blended rate of $50 per hour, and the ranges below are planning figures, not quotes. If your ADT feed is causing problems, a free call will pinpoint where it breaks. The six items below cover the key pitfalls and what fixing them typically costs.
Out-of-Order Messages
After downtime or queue backlogs, messages can arrive out of sequence, such as a discharge before a transfer. Interfaces should use event timestamps and state checks to process messages safely, rather than blindly applying every message in the order it happened to arrive.
Mishandled Merges
Merge events that are ignored or applied incorrectly create duplicate or combined patient records, one of the most serious integration risks. We test merge scenarios thoroughly and add review steps for uncertain cases, protecting patient identity across every connected downstream system.
Update Floods and Local Z-Segments
High volumes of A08 updates and undocumented Z-segments overwhelm receiving systems and confuse mapping. We filter irrelevant updates, document local extensions and agree specifications with each partner. Our Mirth Connect channels handle filtering and transformation centrally. Receiving system performance improves immediately.
ADT Interface Build: $4,000 to $20,000
A single ADT interface typically takes 80 to 400 hours, depending on events handled, mapping complexity, merge logic and partner testing. Our HL7 ADT integration services cover design, build, testing, cutover and documentation. Merge testing and acknowledgment handling are always included.
ADT Interface Health Check: $1,000 to $4,000
For existing feeds causing problems, a health check typically takes 20 to 80 hours. We review event handling, merges, errors and acknowledgments, then deliver a prioritized fix list. Our guide to Mirth Connect error handling and reprocessing shows common fixes.
Ongoing ADT Support: $1,000 to $4,000 per Month
Support retainers typically cover 20 to 80 hours per month for monitoring, troubleshooting, partner changes and reprocessing failed messages. You can also hire HL7 integration engineers at $8,000 per engineer per month for continuous work. Failed messages are never silently dropped.
FAQs
Frequently Asked Questions
These are the questions interface analysts, developers and integration leads ask most often when they build or troubleshoot HL7 ADT interfaces, whether they are connecting a new application, onboarding a hospital customer or fixing a feed that keeps failing. The answers are short on purpose. If your question depends on your sending system, version or partner requirements, a short call with our integration team will give you a clearer answer. For a plain-language introduction to ADT for non-technical stakeholders, share our article on HL7 ADT messages explained with your team.
The most common are A01 admit, A02 transfer, A03 discharge, A04 register, A08 update and A40 merge, along with their cancellation events A11, A12 and A13. Most interfaces must handle all of these correctly to keep patient location, visits and identity accurate.
A01 is typically used for inpatient admissions, while A04 registers outpatients and emergency patients. Both create encounters, but A04 visits usually lack inpatient bed details. Receiving systems should handle each according to patient class rather than assuming every visit is an inpatient stay.
Apply relevant demographic and visit changes, and ignore updates that do not affect the receiving system. Many hospitals send frequent A08 messages, so filtering and efficient processing prevent unnecessary load, noise and repeated updates to records that have not meaningfully changed.
A40 combines duplicate patient records. Mishandling it can merge two different patients or leave split records, affecting results, medications and history. Merge processing should be carefully tested, logged and, where uncertain, routed for human review before records are combined. Safety depends on it.
We bill a blended $50 per hour. A new ADT interface typically costs $4,000 to $20,000, a health check for an existing feed $1,000 to $4,000, and ongoing support $1,000 to $4,000 per month, depending on scope. Partner fees are separate.
Yes. ADT events can be mapped to FHIR resources such as Patient and Encounter, often through an integration engine. This lets modern apps and APIs use hospital ADT feeds without parsing HL7 v2 directly, while existing interfaces continue running unchanged.
Share your sending system, HL7 version, events you receive and the problems you are seeing. In a 30-minute call we will identify the likely causes, recommend fixes and estimate what building or repairing your ADT interface would cost. Book a free consultation.