HL7 ADT_A40 (Merge Patient - Patient Identifier List) | Integration Soup HL7 Reference Guide

HL7 ADT_A40 Merge Patient - Patient Identifier List

Two patient identifiers turned out to belong to the same patient, and one must stop being used.

HL7 message structure ADT_A39 groups and segments from HL7 v2.5.1 Hide structure

These are the generated groups and segments for the version selected at the top of the page. The article explains the workflow, and this panel follows the chosen HL7 version.

Message Structure

Segment	Name	Required	Repeatable
MSH	Message Header	Yes	No
SFT	Software Segment	No	Yes
EVN	Event Type	Yes	No
ADT_A39.PATIENT	Patient group	Yes	Yes
PID	Patient Identification	Yes	No
PD1	Patient Additional Demographic	No	No
MRG	Merge Patient Information	Yes	No
PV1	Patient Visit	No	No

ADT_A40 is the patient-identifier-list merge event. It is sent when a patient was incorrectly filed under two identifiers and the source system has decided which identifier survives. This is one of the ADT messages where direction matters a lot: the target identifier is in PID, and the prior identifier to merge away is in MRG.

A40 commonly appears as ADT^A40^ADT_A39. The A40 trigger identifies the patient-identifier-list merge, while ADT_A39 is the shared merge structure in the local data. The generated panel below shows that backing structure.

A small A40 example

MSH|^~\&|MPI|CITYHOSP|EHR|CITYHOSP|20260715150000||ADT^A40^ADT_A39|ADT400001|P|2.5.1 EVN|A40|20260715145900|||MPIUSER^Patel^Rina PID|1||123456^^^CITYHOSP^MR~NHI1234^^^NATIONAL^NI||Smith^Jane^Anne^^Ms^^L||19800314|F MRG|999888^^^CITYHOSP^MR~OLDNHI9^^^NATIONAL^NI PV1|1|N

What systems do with it

The sender is usually an MPI, registration master, or EHR identity system. Receivers use A40 to re-point data from the prior identifier in MRG to the surviving identifier in PID. That can touch results, documents, appointments, orders, charges, images, medication history, portals, analytics, and audit/search indexes.

A40 is not just a demographic update. It tells the receiver to treat two identifiers as belonging to the same patient record. Many systems queue merges for special handling because filing the merge backward can be much worse than rejecting it.

How to read the structure

The ADT_A39 backing structure has MSH, EVN, and one or more patient groups. Each patient group requires PID and MRG. In the common A40 pattern, PID-3 carries the correct target patient identifier list, while MRG-1 carries the prior patient identifier list that should be merged away.

Optional PD1 and PV1 may appear, but the identity direction is the heart of the message. If the identifier type, assigning authority, or identifier list is incomplete, the receiver may not be able to merge safely.

Implementation traps

The biggest trap is reversing PID and MRG. PID is the survivor. MRG is the prior identifier. A receiver should log, monitor, and ideally validate this direction before changing durable patient links.

The second trap is using A40 to fix a simple identifier value typo. A40 is a merge: two patient records or identifier lists are being reconciled. If the task is changing one incorrect identifier value on the same patient record, a change-patient-identifier event such as A47 may be more appropriate in profiles that support it.

The third trap is forgetting downstream data. A merge is not complete just because the patient master table changed. Documents, imaging archives, lab results, billing, caches, search indexes, and interface correlation tables may each need to be updated or at least warned.

Reference notes

The HL7 v2+ ADT_A39 structure page describes A40 as signaling a merge where the prior identifier in MRG-1 is merged into the correct target identifier in PID-3. IHE Patient Identity Management maps A40 to ADT^A40^ADT_A39, states that A40 is for merging patient identifiers or identifier lists, and separates that workflow from A31 demographic updates.