Of all the HL7 ADT events, the patient merge — A40 — is the one most worth getting right, because mishandling it can attach one patient’s clinical data to another patient’s record. That is not a data-quality nuisance; it is a patient-safety problem. Merges happen constantly in real healthcare environments (duplicate registrations, identity resolution), and every system consuming the ADT feed has to handle them correctly and consistently. This guide focuses specifically on the hard ADT events — merges and the closely related A08 updates — and how to handle them safely.
If you want a general reference to all the ADT event types and HL7 message structures, see our ADT event types guide; this article assumes that grounding and goes deep on the merge problem specifically. A scope note: this is a technical guide, and ADT messages carry PHI to be protected appropriately.
Why Patient Merges Happen
Duplicate patient records are a fact of life. A patient gets registered twice — a slightly different name spelling, a typo’d date of birth, registration at two facilities — and the system ends up with two records for one person. When the duplication is discovered, or when a master patient index (MPI) resolves the two identities as the same person, the records must be merged: one record is designated the surviving (correct) record, and the other is deprecated. The A40 message is how that merge is announced to downstream systems so they can re-point everything from the deprecated identifier to the surviving one. Because patient identity is the foundation everything else hangs on, merges touch every system that holds data keyed to a patient.
The A40 Message and the MRG Segment
An A40 (merge patient — patient identifier list) message carries two key pieces of identity information. The PID segment carries the surviving patient’s identifiers — the record that should remain. The MRG (merge) segment carries the prior/incorrect identifiers — the record being deprecated. The receiving system reads the MRG segment to learn which identifier(s) are going away and the PID to learn which identifier they are being merged into, and then re-points its data accordingly. The MRG segment is the heart of merge handling; if your integration ignores or mishandles it, the merge does not actually happen on your side and your data diverges from the source of truth.
A note on the event family: HL7 versions define several related identity events — beyond A40, there are events for moving and changing identifier lists, and older versions used different merge events. The exact events and segment details vary by version and by the sending system’s configuration, so confirm what your specific source sends rather than assuming. A40 with an MRG segment is the modern, common case, and the principles here apply across the family.
The Real Danger: Re-Pointing Data Everywhere
Here is the crux. When a merge occurs, all the data tied to the deprecated patient ID — lab results, allergies, medications, encounters, documents — has to be re-associated with the surviving patient ID, in every system that holds it. If a downstream system fails to process the merge, that patient’s data splits across two identities: some under the surviving record, some orphaned under the deprecated one. A clinician viewing the surviving record might not see the orphaned allergies or results. Worse, a botched merge that maps data to the wrong surviving record attaches one patient’s clinical information to another patient. Both outcomes are serious. This is why merges demand far more care than a routine demographic update, and why merge handling has to be coordinated across the whole integration landscape, not implemented in isolation in one system.
A08 Updates: The Other Event That Bites
The A08 (update patient information) event is far more routine than a merge, but it earns a mention here because it is so frequent and so easy to under-handle. Patient and visit information changes constantly — a corrected name, a new address, updated insurance — and A08 carries those updates. A system that processes admits and discharges but quietly ignores A08 updates slowly drifts out of sync with reality, holding stale demographics. Handle A08 updates deliberately: apply the changes, keep your patient data current, and do not assume the initial registration data stays valid. Updates are low-drama individually but cumulatively important.
A Reliable Merge-Handling Process
Establish a Patient Identity Strategy
Decide how your system manages patient identity — ideally anchored to a master patient index — so you have a clear, authoritative notion of which identifier survives and how identifiers relate.
Parse the MRG and PID Segments Carefully
On an A40, read the MRG segment for the deprecated identifier(s) and the PID for the surviving identifier. Do not guess — map exactly what the message specifies.
Re-Point All Associated Data
Re-associate every record tied to the deprecated ID — results, allergies, medications, encounters, documents — to the surviving ID. Completeness here is what prevents orphaned or split data.
Design for Ordering and Replays
Messages can arrive out of order or be replayed. Make merge handling idempotent and resilient so a repeated or late merge does not corrupt state.
Audit and Log Every Merge
Record every merge — what was merged into what, when, and the outcome — so merges are traceable and reversible problems can be investigated.
Coordinate Across Downstream Systems
Ensure the merge propagates to every system consuming the ADT feed. A merge handled in one system but not another recreates the split-identity problem.
Plan for Reversals
Where your environment supports un-merges or merge corrections, plan how to handle them, since merges are sometimes made in error and must be safely undone.
Best Practices and Pitfalls
A few principles separate safe merge handling from fragile handling. Treat merges as high-risk and test them thoroughly with realistic scenarios, including edge cases, before relying on them in production. Never silently drop an MRG segment — if your integration cannot fully process a merge, it should surface that loudly rather than appear to succeed. Reconcile linked clinical data after a merge to confirm nothing was orphaned. Route merges through your interface engine deliberately — an engine like Mirth Connect can centralize and standardize how merges are handled and propagated (see our Mirth Connect integration practice). And remember the cross-system reality: a merge is only truly complete when every system that holds the patient’s data has applied it. The cost of getting merges wrong is high enough that the extra rigor always pays for itself.
How Taction Helps
We build HL7 ADT integrations that handle merges and updates safely — parsing MRG and PID segments correctly, re-pointing associated clinical data to the surviving identifier, designing for ordering and replays, auditing merges, and coordinating propagation across the systems consuming the feed, commonly through an interface engine like Mirth Connect. We treat merges with the rigor their patient-safety implications demand. With deep HL7 and integration experience, ISO 27001-certified security, and PHI handled under a signed BAA, we make identity events reliable. Our HL7 integration practice, within our healthcare software work, covers the full scope.
Related reading: HL7 ADT Event Types Guide · HL7 Message Types and Event Types
Frequently Asked Questions
What is an A40 in HL7 ADT?
A40 is the patient merge event (merge patient — patient identifier list). It announces that two patient records have been merged: the PID segment carries the surviving (correct) identifier and the MRG segment carries the prior/deprecated identifier, so downstream systems can re-point data from the deprecated ID to the surviving one.
Why is the MRG segment important?
The MRG (merge) segment carries the identifier(s) being deprecated in a merge, while the PID carries the surviving identifier. The receiving system reads MRG to know which identity is going away and PID to know what it merges into. If a system ignores or mishandles MRG, the merge never actually happens on its side and its data diverges from the source of truth.
What goes wrong if a merge is mishandled?
The patient’s data can split across two identities — some under the surviving record, some orphaned under the deprecated one — so a clinician may not see all of it. A merge mapped to the wrong surviving record can attach one patient’s clinical data to another patient. Both are serious patient-safety problems, which is why merges need extra rigor.
How is A08 different from a merge?
A08 (update patient information) is a routine update to existing patient or visit information — a corrected name, new address, updated insurance — not a merge of two records. It is far more frequent and lower-risk individually, but systems that ignore A08 drift out of sync with reality, so updates should still be handled deliberately.
How do we handle merges across multiple systems?
A merge must propagate to every system consuming the ADT feed; handled in one system but not another, it recreates the split-identity problem. Centralizing and standardizing merge handling through an interface engine, coordinating downstream propagation, and reconciling linked data afterward are how you keep identity consistent across the landscape.
Can a merge be reversed?
Merges are sometimes made in error and may need to be undone where the environment supports un-merges or corrections. Because reversals are tricky, plan for them deliberately — auditing every merge (what was merged into what, when) is what makes investigating and safely reversing a bad merge possible.
Handling HL7 ADT merges and identity events? Schedule a free consultation →
This article is a technical guide, not legal advice. Reviewed by Taction Software’s healthcare integration engineering team. ISO 27001-certified information security management. ADT messages carry PHI, protected under a signed BAA.
