If you spend any time in healthcare IT integration, ADT messages will dominate your days. Admit, Discharge, Transfer — the three words behind the most important message type in HL7 v2.x. Every connected clinical system depends on ADT to maintain an accurate picture of who is in the hospital, where they are, and what their demographics look like.
This is a practitioner's breakdown, not a standards recitation. We cover the events that matter most, the fields that fail most often, and the operational patterns that keep ADT interfaces running cleanly.
What ADT Actually Does
An ADT message is a notification from your ADT source system (typically the EMR or HIS) to every downstream system that needs to know about patient movement or demographic changes. When a patient is admitted, every connected system — PACS, RIS, LIS, pharmacy, billing — receives an A01. When the patient's name is corrected, an A08 fans out to all of them.
The trigger event (the A-code) tells the receiver exactly what happened. Ignoring the trigger event and treating all ADT messages identically is one of the most common implementation mistakes.
The Trigger Events That Matter
A01 — Admit/Visit Notification
Sent when a patient is formally admitted or when an outpatient or emergency visit is registered. This is the message that creates the patient in downstream systems. PACS and RIS systems use A01 to pre-populate the patient index before any orders arrive.
What can go wrong: A01 arrives before demographics are complete (the patient is entered as "Unknown"). Always verify PID-3 (patient ID), PID-5 (name), and PID-7 (DOB) are populated before the message is sent.
A02 — Transfer a Patient
Sent when a patient moves between locations within the facility. Critical for inpatient imaging workflows — PACS worklist displays current ward and bed assignment.
What can go wrong: PV1-3 (Assigned Patient Location) not updated in the transfer message. The patient appears in the old ward in imaging worklists.
A03 — Discharge/End Visit
Signals that the patient's visit is over. Should close the encounter in PACS and trigger billing finalisation in RIS.
What can go wrong: A03 sent before all imaging is complete. Images arrive at PACS after the encounter is closed, causing them to be filed against a closed order.
A08 — Update Patient Information
The workhorse of demographic correction. Sent when any patient demographic changes — name correction, DOB update, address change, sex change, phone number update.
What can go wrong: Not all downstream systems handle A08 — they only understand A01 and may silently discard A08. During integration testing, explicitly verify A08 processing in every connected system.
A11 / A12 / A13 — Cancel Events
These reverse the corresponding A01, A02, and A03. A11 cancels an admission; A12 cancels a transfer; A13 cancels a discharge.
What can go wrong: Cancel messages not sent or not handled, leaving systems in an inconsistent state. Always implement cancellation handling.
A40 — Merge Patient Records
The most critical and most dangerous ADT event. A40 tells downstream systems that two patient records in the source system have been determined to be the same person and should be merged.
The A40 carries two PID segments:
- PID — the surviving (master) patient record
- MRG — the old (non-surviving) patient ID being merged into the master
Every downstream system that maintains a patient index must handle A40. If a PACS system doesn't process A40, a merged patient will have split imaging history — some studies under the old ID, some under the new — creating a clinical risk.
The Fields That Cause 80% of Problems
PID-3 — Patient Identifier List
This is the most complex field in the PID segment. It uses the CX data type and can carry multiple identifiers:
PID|||123456^^^CITYHOSP^MR~NHS9876543210^^^NHS^NHS
In this example, the patient has an MRN (123456 from CITYHOSP) and an NHS number. The assigning authority (CITYHOSP, NHS) distinguishes between them. Without it, the receiving system can't tell which is which.
Failure pattern: Assigning authority omitted in multi-site deployments. Patient ID 12345 exists at Site A and Site B for different patients. Without the authority qualifier, PACS merges them.
MSH-3 / MSH-5 — Sending and Receiving Application
Every interface engine routes on these. If a new ADT source goes live with different MSH-3 values than the existing configuration, messages are silently dropped or misrouted.
Always confirm MSH-3 and MSH-4 values with the vendor before any go-live. Treat them as case-sensitive string matches.
MSH-11 — Processing ID
P for production, T for test, D for debugging. Test systems sending T messages to production listeners is a classic go-live mistake. The interface engine, if correctly configured, should reject T messages on production listeners.
Building a Reliable ADT Interface
1. Start with a field inventory. Before writing a single routing rule, document every PID, PV1, and MSH field your downstream systems require. Gaps at this stage turn into production incidents.
2. Test all trigger events, not just A01. Most ADT interfaces are tested with A01 (admit) and considered done. A08, A11, A40 — these are the ones that break in production and cause serious operational problems.
3. Implement fan-out logging. When an ADT message fans out to multiple destinations, log every delivery and ACK code. A single non-AA ACK from one destination in a fan-out is easy to miss if you're not logging them all.
4. Set up a message replay capability. When a downstream system is down for maintenance and misses ADT messages during that window, you need the ability to replay the queued messages in order after it comes back.
5. Monitor lag, not just failures. A healthy ADT interface delivers messages within 10–30 seconds of the trigger event. Latency above 5 minutes means something is building up. Alert on queue depth, not just errors.
Connecting ADT to Imaging
ADT flows directly into your imaging workflow through the Modality Worklist. When an A01 arrives at the RIS, it creates the patient record that will be used to populate the MWL for the modality. If the ADT demographics are wrong, the modality picks up wrong demographics, and every image in that exam has wrong DICOM headers.
The chain is: EMR → ADT → RIS → MWL → Modality → DICOM headers → PACS. A data quality problem at the ADT layer propagates all the way to the image file. This is why ADT data quality matters far beyond the messaging layer.
For a deeper look at the DICOM side of this workflow, see our DICOM Protocol Reference and the Patient ID tag reference.
Part of the HL7 Integration for Healthcare IT Engineers guide series.