HL7 ADT Integration Guide: A01 to A08 and What Breaks
HL7 ADT integration is the most commonly built interface in healthcare, because almost every clinical, ancillary and billing system needs to know who the patient is and where they are. ADT feeds carry admissions, discharges, transfers, registrations and demographic updates in real time. When they work, nobody notices. When they break, results land on the wrong chart and duplicates multiply. This practitioner guide covers the events, merges, identity rules and troubleshooting steps that keep feeds reliable. Need a feed built or fixed? Talk to our HL7 engineers.
How HL7 ADT Integration Works
An ADT message integration sends patient administration events from a registration or EHR system to every downstream system that depends on them. Labs, radiology, pharmacy, dietary, bed management and billing all subscribe to the same feed, often through an integration engine that filters and routes messages. Each message carries an event code, patient identity, visit details and sometimes insurance, diagnoses and next of kin. Understanding the structure first makes every later design and troubleshooting decision much easier for your team.
The Source System
The EHR or patient administration system generates ADT events when staff register, admit, transfer or discharge patients. Its configuration decides which events are sent, how often and with which optional segments.
The Integration Engine Layer
Most organizations route ADT through an engine that fans messages out to many receivers, filters irrelevant events and transforms fields. Our Mirth Connect consulting team designs these channels. Channels stay documented.
Key ADT Segments
MSH identifies the message, EVN records the event, PID carries patient identity, PV1 describes the visit, and optional NK1, AL1, DG1 and IN1 segments add contacts, allergies, diagnoses and insurance.
Downstream Receivers
Each receiver uses ADT differently. A lab needs current location and identifiers, billing needs insurance and account numbers, and bed management needs precise transfer timing. Our EHR/EMR integration team documents each receiver's needs separately.
Acknowledgements and Ordering
Receivers must acknowledge each message, and events must be processed in order. An A08 update processed before its A01 admission can create orphaned records or incorrect demographics downstream. Sequencing must be guaranteed.
ADT Events You Must Handle: A01 to A13
Most ADT A01 A03 A08 specifications cover the same core events, but the details of each one matter. Every event triggers different actions downstream, and many interfaces fail because a receiver treats two different events the same way or ignores cancellations completely. Before building a patient admission interface, agree with each receiving system exactly which events it needs, how it should respond, and what happens when an event arrives out of the expected order.
A01 Admit and A04 Register
A01 admits an inpatient, while A04 registers an outpatient or emergency patient. Both create encounters, but encounter class, billing rules and downstream workflows differ, so receivers must handle them explicitly and separately.
A02 Transfer
A02 moves a patient to a new location, bed or service. Receivers rely on it for accurate room numbers, specimen collection routes and nursing assignments, so transfer timestamps must be precise.
A03 Discharge
A03 closes the encounter. Downstream systems, including those covered by our lab integration services, should stop accepting new charges or orders for that visit, finalize documentation and trigger discharge workflows like follow-up scheduling and summary distribution. Late discharges distort reporting.
A08 Update Patient Information
A08 updates demographics or visit details and is usually the highest-volume ADT event. Receivers must apply changes carefully and compare timestamps, so delayed messages never overwrite newer information already stored.
A11 and A13 Cancellations
A11 cancels an admission and A13 cancels a discharge. Receivers that ignore cancellations keep ghost encounters open or closed incorrectly, which causes billing errors and confusing patient lists for clinical staff.
Merge Events and Patient Identity Matching
Patient identity is where most ADT feeds eventually break. Hospitals use local medical record numbers, enterprise identifiers and sometimes external identifiers from payers or health information exchanges. Duplicate records are inevitable, and merge events exist to fix them. However, every downstream system must process merges correctly, or results, orders and documents remain attached to retired identifiers. This is also a core healthcare interoperability challenge across organizations. The sections below explain how to handle it.
A40 Merge Patient
A40 merges a duplicate record into a surviving one, using PID for the surviving identifier and MRG for the retired one. It is where most ADT feeds break, because receivers handle it inconsistently.
MRN Versus Enterprise ID
PID-3 can carry several identifiers, each with an assigning authority. Specifications must state which identifier each receiver uses, or systems will match patients on the wrong number and create duplicates.
Matching Rules for Receivers
When identifiers are missing or conflicting, receivers fall back on demographics. Define matching rules clearly, avoid automatic matching on name alone, and route uncertain matches to a human review queue.
Handling Merges Downstream
Each receiving system must move historical results, orders and documents to the surviving record. Test merges explicitly, including merges of patients with open encounters, because these cases fail most often.
Preventing Duplicates at the Source
The best merge is one you never need. Strong registration search, identity verification at check-in and an enterprise master patient index reduce duplicate creation before it spreads across every connected system.
Troubleshooting HL7 ADT Integration Failures
When an ADT feed misbehaves, symptoms usually appear far from the cause. A clinician sees a missing result, a biller sees an unmatched account, or a lab finds orders for a discharged patient. Good troubleshooting starts with the symptom, identifies the likely cause and checks specific places in the message flow. The patterns below cover the problems we see most often across HL7 integration projects in hospitals and clinics. Start with the symptom you see.
Symptom: Duplicate Patients Downstream
Likely cause: receivers matching on the wrong identifier or ignoring A40 merges. Check PID-3 assigning authorities, receiver matching rules and whether merge messages are filtered out by the engine. Fix rules first.
Symptom: Wrong Patient Location
Likely cause: A02 transfers missing, delayed or processed out of order. Check engine queues, channel filters and message timestamps against EVN event times to confirm processing sequence. Clear stuck queues promptly.
Symptom: Demographics Reverting
Likely cause: delayed A08 messages overwriting newer data. Check whether receivers compare message timestamps before applying updates, and whether engine retries are resending older messages after outages. Enforce timestamp checks everywhere.
Symptom: Ghost Encounters
Likely cause: A11 or A13 cancellations ignored by receivers. Check receiver event handling, engine filters and whether cancellations reach every system that received the original admission or discharge. Audit receiver logs.
Drift Between Systems
Even well-built feeds drift over time. Run periodic reconciliation reports comparing active encounters and identifiers between the EHR and key receivers, and fix discrepancies before they affect patient care. Schedule reconciliation at least monthly.
Frequently Asked Questions
What is HL7 ADT integration?
HL7 ADT integration sends admit, discharge, transfer and registration events from an EHR or registration system to downstream systems like labs, radiology, pharmacy and billing. Each message carries patient identity, visit details and event information, keeping every connected system synchronized with the patient's current status in near real time.
What is the difference between ADT A01 and A04?
A01 is an inpatient admission, while A04 registers an outpatient or emergency patient without inpatient admission. Both create encounters, but they differ in encounter class, billing and downstream workflows. Receiving systems should process them explicitly rather than treating them as identical events, which avoids reporting and billing errors.
Why do ADT A40 merge messages cause problems?
A40 messages require every downstream system to move results, orders and documents from a retired patient identifier to a surviving one. Many systems handle merges inconsistently or not at all, especially for patients with open encounters. That leaves data on retired records and creates confusion, so merges need explicit testing.
Which ADT events should an interface support?
Most interfaces support A01, A02, A03, A04 and A08, plus cancellations A11 and A13 and merges such as A40. Some receivers also need pre-admissions, leaves of absence or account updates. Agree the exact event list with each receiving system, because unnecessary events add noise and missing events cause errors.
How do you test an HL7 ADT interface?
Test with synthetic messages covering every event, including cancellations, merges, out-of-order delivery and missing optional segments. Validate receiver behavior for each scenario, confirm acknowledgements, and run parallel testing against production-like volumes. Include identity edge cases, such as patients with multiple identifiers, since these cause most production failures.
How long does it take to build an ADT interface?
A standard ADT interface to one receiver typically takes two to six weeks, depending on events, mapping requirements and vendor test environment availability. Feeds serving many receivers take longer, because each needs its own filtering, transformation and validation. Discovery with every system owner keeps timelines realistic and avoids late rework.
Need an ADT Feed Built or Fixed?
Our integration engineers are ready to help. Free consultation, no obligation.