HL7 ADT Integration Services

An ADT feed looks simple in a diagram and behaves badly in production. The message structure is standard, the trigger events are documented, and yet ADT is consistently the interface that causes the most downstream damage when it drifts. The reason is that ADT carries identity and encounter context rather than clinical content, so its failures do not surface as errors. They surface weeks later as a result filed against the wrong visit, a duplicate patient record, or a downstream system quietly holding a patient who was discharged in March.

The HL7 v2 standard defines ADT trigger events from A01 through A62, though a working integration typically acts on a core subset and acknowledges the rest. In US hospital environments the events you will encounter within minutes of connecting are A01, A02, A03, A04, A08, A11, A12, A13, A28, A31 and A40. Everything else appears occasionally, in site-specific configurations, or not at all. Scoping should state explicitly which events are handled, which are acknowledged and ignored, and what happens to anything unexpected.

Merge is where ADT integration is genuinely difficult, and where the consequences of getting it wrong are clinical rather than technical. When a hospital discovers that one patient exists twice in its system, it merges the records and sends an A40. Every downstream system must then reconcile its own copy of that patient, reassign historical data and retire the surviving identifier correctly. Systems that acknowledge A40 without acting on it create a permanent divergence, and the divergence is invisible until someone looks at the wrong chart.

A master patient index is the authority on who a patient is across systems, and ADT is the mechanism that keeps it current. Where an MPI exists, ADT feeds must respect its identifier hierarchy rather than treating any single system’s identifier as canonical. Where no MPI exists, the ADT feed frequently becomes the de facto identity mechanism by accident, which works until the first merge or the first patient registered twice at two facilities. Establishing which system holds identity authority is a design decision, not a technical detail.

ADT interfaces pass testing and fail in production more often than any other message family, because test extracts are clean and real registration behavior is not. Trauma cases, downtime entries, corrected records and out-of-sequence events do not appear in a sanitized sample set. We test against captured production traffic and deliberately exercise the paths that are normally assumed rather than verified, because an interface that has never seen a merge is an interface whose merge handling is unproven.

ADT problems cluster into a small number of recognizable patterns, and in newly assessed environments we usually find several of them at once. What they share is invisibility: none produces an obvious error, and all of them are discovered downstream, often by a clinician rather than by IT. Knowing the patterns is most of the diagnosis, which is why an assessment on an existing feed routinely returns findings within the first day.

ADT work is priced by scope rather than by hour. The drivers are the number of downstream consumers, whether merge and identity handling are in scope, how cleanly the source system follows specification, and how deep the validation requirement runs. Remediating an existing feed is frequently cheaper than organizations expect and delivers more immediate value than a new build, because the highest-impact findings usually exist already and are simply unseen.