In most healthcare environments, patient registration events originate in the admission, discharge, and transfer system, then flow outward as HL7 ADT messages to every connected clinical platform. PACS, RIS, VNA, CVIS, scheduling systems, and reporting platforms all consume these messages to maintain a coherent view of who the patient is. That flow is invisible when it works and immediately disruptive when it does not.
Understanding ADT is practical knowledge for integration architects, imaging IT engineers, and anyone responsible for keeping clinical systems aligned. The event types matter, the message content matters, and the monitoring posture matters.
What ADT messages are and where they originate
ADT stands for Admit, Discharge, and Transfer in HL7 v2 terminology, but the message type covers significantly more than those three events. ADT is the primary HL7 mechanism for communicating patient demographic information, patient location changes, registration events, and patient identity updates across connected systems.
In most hospital environments, ADT messages originate from the registration system or the patient management module of the EHR/EMR platform. They are published outward through an interface engine or integration platform to every downstream system that needs to know about patient state. That population of downstream systems almost always includes imaging platforms.
The ADT event codes that matter most in imaging environments
HL7 v2 defines a large number of ADT event types. In practice, a smaller subset drives the majority of workflow behavior in imaging and clinical systems.
| Event | What it signals | Imaging relevance |
|---|---|---|
| A01 | Patient admitted | Creates or confirms the patient record in PACS, RIS, and VNA; triggers worklist and scheduling context |
| A04 | Patient registered (outpatient) | Registers outpatient and ED patients before formal admission; critical for same-day imaging and ED workflows |
| A08 | Patient information update | Updates demographic, insurance, or contact information in downstream systems; often the most frequent ADT event in volume |
| A28 | Add person information | Pre-registers a person in the system before an encounter begins; used in pre-scheduling workflows and outpatient imaging preparation |
| A31 | Update person information | Corrects or updates demographic data for an already registered person; imaging systems must apply this cleanly to avoid patient identity inconsistency |
| A40 | Merge patient | Resolves duplicate patient records into a single identity; one of the highest-risk ADT events for imaging due to potential for study misassignment if not handled correctly |
| A02 / A03 | Transfer / Discharge | Updates patient location and encounter status; relevant for inpatient imaging routing and bed-level context |
How imaging systems consume ADT
Imaging platforms do not passively receive ADT. They depend on it to construct and maintain the patient-level context that connects orders, priors, demographics, and study metadata. Each system in the imaging chain uses ADT differently.
The RIS uses ADT to manage scheduling, registration, and patient records. The PACS uses it to keep patient demographics aligned with study metadata. The VNA uses it to maintain archive integrity across patient identifiers. CVIS platforms in cardiology have their own ADT consumption patterns, which often differ subtly from radiology configurations. Reporting systems, worklist engines, and results routing layers all have their own interpretation of what specific ADT events should trigger.
In each case, the system is comparing incoming ADT data against what it already knows. When the incoming message is complete, timely, and consistent, the system stays aligned. When it is late, malformed, or missing a required field, alignment breaks in ways that are not always immediately visible.
What breaks when ADT is late, malformed, or missing
The failure modes vary by event type and by which system is the affected receiver. Some failures are immediately visible. Others accumulate silently until they surface in unexpected places.
- Missing A01 or A04 events mean imaging systems receive orders for patients who do not yet exist in their local registry. The result is either a rejected order or a ghost patient record that must be reconciled.
- Late A08 updates mean that demographic corrections made in registration do not reach imaging systems before a study is performed. Studies end up with stale name, date-of-birth, or identifier data that requires correction after the fact.
- Poorly handled A40 merges are the most consequential failure type. When duplicate patient records are merged and the downstream imaging system either ignores the event or handles it incorrectly, studies can become associated with the wrong patient identity or simply become inaccessible.
- Duplicated ADT messages can trigger redundant record creation, especially in systems that do not implement deduplication logic. This is a common source of ghost records in older PACS deployments.
- Encoding errors or malformed segments — particularly in PID, PV1, and MRG segments — cause messages to fail silently at the interface engine or arrive at the receiver with missing fields.
The ADT failures that do the most damage are not the ones that generate obvious errors. They are the ones that produce subtly incorrect records — wrong demographics, misassigned studies, stale identifiers — that only surface when a clinician or technologist notices something does not match.
Monitoring and exception handling for ADT in imaging environments
Effective ADT management requires more than a functioning interface engine. It requires visibility into what messages are flowing, what is being rejected, and what is being queued without delivery.
Integration teams managing imaging environments should monitor: message volume by event type so that unexplained drops are visible, ACK (acknowledgment) behavior from downstream systems to confirm delivery, rejection logs with structured parsing to identify malformed or rejected messages before they accumulate, and latency metrics to detect when processing delays are extending beyond acceptable thresholds.
For the A40 merge event specifically, a dedicated review process is warranted given the high-risk nature of the operation. Many organizations establish a workflow where merge events are queued for manual review before being pushed to imaging systems, particularly in multi-facility environments where MRN conflicts are more common.
Tools that provide message-level visibility, routing transparency, replay paths, diagnostics, and exception alerting make this monitoring work practical at scale. Platforms like Flow Bridge Integration, also known as FBI Engine, are designed to address this type of governed interoperability and operational triage need.
When ADT events also drive patient flow, worklists, queue state, and status management, teams need an operational layer that can connect interoperability events to action. VioFlow supports that broader patient operations context by helping organizations govern inbound clinical workflow data and make it usable for coordinated care.
Planning for ADT changes and upgrades
ADT interface changes happen frequently — EHR upgrades, registration workflow changes, new site go-lives, and interface engine migrations all affect ADT message structure or routing. Each change carries the risk of breaking downstream imaging behavior if it is not tested carefully before production.
A change management process for ADT should include: a test environment that accurately reflects current production message patterns, test scripts that exercise all relevant event types including edge cases, end-to-end validation that confirms downstream imaging system behavior, and a rollback plan for the period immediately following any change.
For larger programs such as EHR platform migrations or health system consolidations, ADT impact assessment should be part of the integration architecture review that happens before execution begins, not after. See the related article on EMR integration and clinical imaging migration for more on how integration dependencies affect migration risk.
Frequently asked questions
Does FHIR replace HL7 ADT messages in imaging environments?
Not in most current environments. HL7 v2 ADT remains the dominant mechanism for real-time patient registration and demographic events in clinical imaging. FHIR is increasingly used for API-based patient data access, but the operational event stream that drives PACS, RIS, and VNA workflows still runs on HL7 v2 in the vast majority of healthcare organizations. The two standards often coexist, with HL7 v2 handling operational workflows and FHIR supporting modern application access. The HL7 vs FHIR guide covers this relationship in more detail.
How should integration teams test ADT interface changes before go-live?
Testing ADT changes requires a non-production environment that mirrors the message patterns of the live system. Test scripts should cover all relevant event types including A01, A04, A08, A28, A31, and A40. Edge cases such as demographic corrections, MRN merges, and admitted-then-discharged-and-readmitted scenarios should be included. End-to-end validation should confirm that downstream imaging systems reflect the expected patient context after each event. Parallel testing with production traffic — where ADT messages are delivered to both old and new configurations simultaneously — is a useful technique for high-risk changes.
What is the difference between an A28 and an A31 ADT message?
Both events carry demographic updates, but they apply in different contexts. An A28 event adds a new person record to the system, typically for a pre-registered or outpatient patient who has not yet been formally admitted. An A31 event updates the demographic information for an already registered person. In imaging environments, both events can update patient data in PACS, RIS, and VNA — which is why their handling needs to be explicitly tested and monitored, particularly in environments with high outpatient and pre-registration volume.
Viogenx supports HL7 integration for clinical imaging environments
Viogenx works with healthcare organizations on HL7 interface design, integration governance, imaging workflow continuity, and the monitoring practices that keep clinical systems aligned.
Explore HL7 and FHIR integration services