HL7 ADT A40 Message: Merge Patient Identifier List, Structure, Segments & Examples

The HL7 A40 message is an Admit, Discharge, Transfer (ADT) event used to communicate the merging of patient identifier lists between healthcare systems. Officially known as ADT A40: Merge Patient Identifier List, this event helps organizations reconcile duplicate patient identities while maintaining access to clinical and administrative records. A40 messages identify the surviving patient identifier in PID-3 and the prior identifier in MRG-1. Accurate processing is essential because an incorrect merge can associate medical information with the wrong patient. This guide explains A40 message structure, real-world workflows, sample messages, Mirth Connect implementation, acknowledgments, troubleshooting, and best practices.

What Is an HL7 ADT A40 Message?

An HL7 ADT A40 message communicates the merging of patient identifier lists when two identifiers are determined to represent the same patient. Healthcare organizations may encounter duplicate identifiers when patients register at different facilities, demographic information is entered inconsistently, or patient matching processes fail.

A40 enables an authoritative patient identity system to communicate the merge to connected applications. The receiving system must identify the surviving patient record and the prior identifier being merged. Unlike an A47 identifier correction, a patient merge may require reconciling clinical information associated with two previously separate identity records. For the wider event family, see our HL7 ADT messages guide.

Purpose of the HL7 A40 Event

A40 communicates an authorized patient identifier merge. Receiving systems use the notification to reconcile the prior identifier with the surviving patient identity while preserving appropriate clinical and administrative record associations.

When Is an ADT A40 Message Generated?

An A40 notification may be generated after an authorized patient identity management process confirms that duplicate identifiers belong to the same person and approves the merge.

Which Healthcare Systems Receive A40 Messages?

EHRs, enterprise master patient index systems, laboratory systems, pharmacy applications, radiology platforms, billing systems, and health information exchanges may receive A40 messages.

How A40 Supports Patient Identity Management

A40 helps connected applications maintain consistent patient identity associations. It reduces fragmentation when records for the same person were previously associated with different identifiers.

Why Accurate A40 Processing Matters

An incorrect merge can combine information belonging to different patients. Receiving systems must validate identifiers, assigning authorities, patient identity evidence, and merge authorization before making changes.

HL7 ADT A40 Message Structure and Segments

HL7 A40 uses the standard HL7 Version 2 segment format. In v2.5, A40 uses the ADT_A39 message structure. The message identifies the source, destination, merge event, surviving patient identity, and prior identifier.

The PID segment contains the surviving patient identifier list, and the MRG segment contains the prior patient identifier list that is being merged. Together, these segments communicate the relationship between the surviving and prior identities. The exact required segments and optional groups depend on the HL7 version and implementation profile.

MSH Segment: Message Header

MSH identifies the sender, receiver, message timestamp, event type, control identifier, and HL7 version. MSH-9 identifies the A40 merge event.

EVN Segment: Event Information

EVN provides administrative event information, including the recorded timestamp. It supports audit tracking and reconstruction of patient identity changes.

PID Segment: Surviving Patient Identification

PID identifies the surviving patient identity. PID-3 contains the patient identifier list that remains authoritative after the merge.

MRG Segment: Prior Patient Identification

MRG identifies the prior patient identifier list. MRG-1 is essential because it tells the receiving application which previous identifier is being merged into the surviving identity.

Optional Patient and Visit Information

Additional segments may be included according to the applicable message profile. Receiving applications should validate segment requirements rather than assume every optional field is present.

HL7 ADT A40 Message Example With Field Explanation

Consider a hospital that discovers two medical record numbers for the same patient. The patient's primary identifier is MRN400099, while a duplicate registration created identifier MRN400001. After an authorized identity review, the hospital approves merging the duplicate identity into the surviving patient record.

The registration system generates an A40 notification. The receiving EHR must locate both identifiers, verify the approved merge, and reconcile the associated patient records.

Complete HL7 ADT A40 Sample Message

MSH|^~\&|REGISTRATION|HOSPITAL|EHR|MAIN|20261022173000||ADT^A40^ADT_A39|MSG40001|P|2.5
EVN|A40|20261022172500
PID|1||MRN400099^^^HOSPITAL^MR||MARTIN^OLIVIA||19890312|F
MRG|MRN400001^^^HOSPITAL^MR

All patient information is fictional.

MRG-1 identifies the prior identifier; PID-3 identifies the surviving patient identifier.

Explore each segment and its key fields:

MSH Segment Explained

MSH identifies REGISTRATION as the sending application and EHR as the destination. ADT^A40^ADT_A39 identifies the merge event, while MSH-10 supports message tracking.

EVN Segment Explained

EVN records the administrative merge event and timestamp. This information helps receiving applications investigate delayed notifications and maintain identity history.

PID-3: Surviving Patient Identifier

PID-3 contains MRN400099, the identifier that remains authoritative after the merge. The receiving application should preserve its assigning authority and identifier type.

MRG-1: Prior Patient Identifier

MRG-1 contains MRN400001, the identifier being merged. The destination uses it to locate the previous identity association and reconcile its records with the surviving patient.

Patient Demographic Fields

PID-5, PID-7, and PID-8 provide supporting demographic information. These values can help with validation but should not independently authorize a merge.

Important HL7 ADT A40 Fields and Mapping

Accurate A40 processing depends on distinguishing the surviving patient identity from the prior identity being merged. PID-3 contains the surviving patient identifier list, and MRG-1 contains the previous patient identifier list. Both fields may include structured identifier components such as assigning authority and identifier type.

Receiving applications should compare complete identifier contexts rather than treating medical record number strings as globally unique. Our HL7 parsing and data mapping team can document identifier-domain rules for your merge interfaces.

PID-3.1: Surviving Identifier Value

PID-3.1 contains the surviving patient identifier value. The destination should confirm that this identifier belongs to the approved patient identity.

PID-3.4: Assigning Authority

PID-3.4 identifies the authority responsible for the identifier. It helps distinguish identifiers issued by different hospitals or patient identity systems.

PID-3.5: Identifier Type Code

PID-3.5 indicates the identifier type, such as a medical record number. Preserving identifier types helps receiving applications distinguish different identity domains.

MRG-1: Prior Identifier List

MRG-1 contains the prior patient identifier list. The receiving application uses this information to locate the identity being merged into the surviving record.

MSH-10: Message Control Identifier

MSH-10 identifies the message for acknowledgment correlation, audit tracking, and duplicate detection. It does not replace the need for patient identity validation.

How HL7 ADT A40 Patient Merge Workflows Operate

An A40 workflow begins when a healthcare organization identifies duplicate patient identifiers and confirms that they represent the same person. An authorized identity management process determines which identifier will survive and which identifier will be merged, and the source application generates an A40 message containing both identifiers.

An integration engine validates the notification and routes it to connected systems. Each destination verifies the merge relationship, updates its patient identity associations, and preserves clinical records according to its supported merge workflow.

Step 1: Identify Duplicate Patient Records

A patient identity team identifies records that may represent the same person. Matching may involve demographic information, historical encounters, registration records, and other approved identity verification methods.

Step 2: Confirm and Authorize the Merge

Authorized staff verify that the records belong to the same patient. They select the surviving identity and approve the merge according to organizational policies.

Step 3: Generate the A40 Message

The source creates an A40 message containing the surviving identifier in PID-3 and the prior identifier in MRG-1, including the relevant assigning authorities.

Step 4: Validate and Route the Merge

An integration engine checks the event type, message structure, identifiers, and sender authorization. It forwards the message to systems that support patient identity merging.

Step 5: Reconcile Records and Acknowledge Processing

The destination validates the merge and updates patient identity associations. It records the processing result, maintains the required audit history, and returns an acknowledgment.

How to Implement HL7 ADT A40 Messages Using Mirth Connect

Mirth Connect can receive, validate, transform, and route HL7 A40 messages between registration systems, EHRs, enterprise master patient index platforms, and other healthcare applications. Patient merge processing requires stronger controls than ordinary demographic updates because an incorrect merge may affect clinical records belonging to different people.

A typical integration validates the event, extracts PID-3 and MRG-1, and submits a merge request to the authorized destination. The integration engine should not directly merge patient database records without the destination's supported identity management workflow. Mirth Connect development services can support these requirements.

Configure the Mirth Connect Source Connector

Create a channel with an MLLP Listener and HL7 v2.x inbound data type. Configure secure transport, authorized senders, message retention, acknowledgment handling, and routing to approved patient identity systems.

Filter HL7 ADT A40 Messages

Use a JavaScript filter to accept the expected merge event.

var messageType =
    msg['MSH']['MSH.9']['MSH.9.1'].toString();

var triggerEvent =
    msg['MSH']['MSH.9']['MSH.9.2'].toString();

var messageStructure =
    msg['MSH']['MSH.9']['MSH.9.3'].toString();

var version =
    msg['MSH']['MSH.12']['MSH.12.1'].toString();

return messageType === 'ADT' &&
       triggerEvent === 'A40' &&
       messageStructure === 'ADT_A39' &&
       version === '2.5';

This filter targets an HL7 v2.5 interface using the ADT_A39 message structure. Other versions and profiles may require different validation rules.

Extract Surviving and Prior Patient Identifiers

The following JavaScript transformer extracts the identifiers from PID-3 and MRG-1 while retaining their structured components.

function getCX(segment, fieldNumber) {
    var segmentName = segment.name().toString();
    var fieldName = segmentName + '.' + fieldNumber;
    var field = segment[fieldName];

    if (field.length() === 0) {
        return [];
    }

    var identifiers = [];

    for each (var cx in field) {
        identifiers.push({
            value: cx[fieldName + '.1']
                .toString().trim(),

            assigningAuthorityNamespace:
                cx[fieldName + '.4']
                  [fieldName + '.4.1']
                .toString().trim(),

            assigningAuthorityUniversalId:
                cx[fieldName + '.4']
                  [fieldName + '.4.2']
                .toString().trim(),

            assigningAuthorityIdType:
                cx[fieldName + '.4']
                  [fieldName + '.4.3']
                .toString().trim(),

            identifierType: cx[fieldName + '.5']
                .toString().trim()
        });
    }

    return identifiers;
}

var msh = msg['MSH'];

var messageType =
    msh['MSH.9']['MSH.9.1'].toString();

var triggerEvent =
    msh['MSH.9']['MSH.9.2'].toString();

var version =
    msh['MSH.12']['MSH.12.1'].toString();

var controlId =
    msh['MSH.10']['MSH.10.1'].toString();

if (messageType !== 'ADT' ||
    triggerEvent !== 'A40' ||
    version !== '2.5') {
    throw new Error(
        'Unsupported HL7 message or version'
    );
}

var survivingIdentifiers =
    getCX(msg['PID'], 3);

var priorIdentifiers =
    getCX(msg['MRG'], 1);

if (survivingIdentifiers.length === 0 ||
    priorIdentifiers.length === 0 ||
    !controlId) {
    throw new Error(
        'Missing patient identifiers or control ID'
    );
}

var mergeEvent = {
    eventType: 'A40',
    action: 'requestPatientIdentityMerge',

    survivingIdentifiers:
        survivingIdentifiers,

    priorIdentifiers:
        priorIdentifiers,

    sourceMessageControlId:
        controlId,

    processingStatus:
        'pending_identity_validation'
};

channelMap.put(
    'patientMergeEvent',
    JSON.stringify(mergeEvent)
);

This example demonstrates the Mirth Connect E4X scripting approach. Production code must validate required identifier components, reject empty identifiers, and handle repeated patient groups where permitted by the message profile.

Transform A40 Into a Patient Merge Request

The integration engine can prepare a structured request for an authorized master patient index or EHR identity management API.

var event = JSON.parse(
    channelMap.get('patientMergeEvent')
);

var request = {
    operation: 'mergePatientIdentifiers',

    survivingPatient:
        event.survivingIdentifiers,

    priorPatient:
        event.priorIdentifiers,

    validationRequired: true,

    mergeStatus:
        'pending_authoritative_approval',

    sourceEvent: {
        type: event.eventType,
        controlId:
            event.sourceMessageControlId
    }
};

channelMap.put(
    'jsonPayload',
    JSON.stringify(request)
);

This JSON structure is illustrative and is not a standardized HL7 or FHIR merge API. The receiving application must enforce authorization, identity validation, and merge-specific business rules.

Validate Patient Identity Before Merging

Confirm that the prior and surviving identifiers resolve to the intended records and that the merge is authorized. Reject conflicting identities and route ambiguous cases for manual review.

Configure Monitoring and Merge Reconciliation

Configure duplicate detection, controlled retries, acknowledgment correlation, and audit logs. Monitor whether downstream systems successfully reconcile the merged identity and associated clinical records.

HL7 ADT A40 ACK Message Examples and Error Handling

HL7 acknowledgments communicate whether an A40 message was accepted or rejected according to the configured processing agreement. An acknowledgment commonly contains MSH and MSA segments. ERR can provide diagnostic information when validation or application processing fails.

In original acknowledgment mode, AA indicates application acceptance, AE indicates an application error, and AR indicates rejection. Because patient merges may require additional downstream reconciliation, acknowledgment acceptance does not always mean that every connected application has completed its merge operation.

Successful A40 ACK: AA

An AA acknowledgment indicates application acceptance under the configured processing mode.

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022173001||ACK^A40^ACK|ACK40001|P|2.5
MSA|AA|MSG40001

Application Error ACK: AE

An AE acknowledgment may indicate that the destination cannot locate the prior patient identifier or cannot complete the requested merge.

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022173002||ACK^A40^ACK|ACK40002|P|2.5
MSA|AE|MSG40001
ERR|||204^Unknown Key Identifier^HL70357|E

The ERR content is illustrative. Production error handling must follow the receiving application's HL7 implementation profile.

Application Rejection ACK: AR

An AR acknowledgment may indicate an unsupported event, unauthorized sender, or message that violates the destination's validation requirements.

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022173003||ACK^A40^ACK|ACK40003|P|2.5
MSA|AR|MSG40001

Correlate Acknowledgments With Merge Requests

MSA-2 should reference the original message's MSH-10 identifier. Monitoring should associate each response with the surviving and prior identifiers and the processing result.

Handle Failed Acknowledgments and Safe Retries

Before resending an unacknowledged A40 message, determine whether the destination already processed the merge. Duplicate processing must not create conflicting identity relationships or reverse a completed merge.

Common HL7 ADT A40 Integration Errors and Troubleshooting

Patient merge failures commonly involve incorrect surviving identifiers, missing prior records, assigning authority mismatches, and out-of-order administrative events. Some destinations may have received clinical information under both identifiers before the merge, while others may maintain separate identity repositories that require additional reconciliation.

A poorly implemented merge can create duplicate patient associations, lose references to historical records, or incorrectly combine information belonging to different people. Troubleshooting should examine the original merge authorization, both identifier domains, and the destination's identity management history.

Surviving and Prior Identifiers Are Reversed

If PID-3 and MRG-1 are interpreted incorrectly, the destination may retain the wrong patient identity. Validate the direction of the merge before processing.

Prior Patient Identifier Cannot Be Found

The destination may not recognize MRG-1 because the previous identity was never received or has already been merged. Review identity history and interface logs before retrying.

Assigning Authority Does Not Match

Identical medical record numbers can exist in different facilities. Verify the complete identifier domain to prevent merges between unrelated patients.

Patient Records Contain Conflicting Clinical Information

The prior and surviving records may contain conflicting demographics or clinical data. Route unresolved discrepancies to an authorized identity reconciliation process.

Duplicate or Delayed Merge Messages Arrive

A delayed A40 notification may arrive after another identity change. Apply idempotency and event sequencing to prevent conflicting merge relationships.

HL7 ADT A40 vs A47, A43, A18, and A08

HL7 Version 2 includes several administrative events related to patient identity. A40 communicates a merge of patient identifier lists. A47 communicates a change to a patient identifier list. A43 communicates movement of patient information. A18 is a legacy merge-related event in earlier implementations, while A08 communicates general patient information updates. These distinctions matter because each event can affect patient records differently.

A40 vs A47: Merge and Identifier Change

A40 merges patient identifier lists, while A47 changes an existing identifier. A merge may reconcile information associated with duplicate identities, whereas a change updates identifier information.

A40 vs A43: Merge and Move

A40 communicates a patient identifier merge. A43 addresses movement of patient information between identifier contexts. Receiving systems should follow the event-specific workflow.

A40 vs A18: Modern and Legacy Merge Events

A18 appears in older HL7 merge implementations. A40 provides a more specific patient identifier list merge event used in later HL7 Version 2 workflows.

A40 vs A08: Identity Merge and General Update

A08 communicates general patient information changes. A40 specifically represents a patient identifier merge and requires reconciliation of the prior and surviving identities.

Best Practices for Reliable HL7 A40 Integration

Patient merges require careful governance because the operation can affect clinical records across many healthcare applications. The authoritative identity management system should validate and approve merges before notifications are distributed.

Receiving systems must preserve complete identifier domains, protect patient record integrity, and support duplicate detection. Integration teams should test merge workflows with realistic patient histories, including existing encounters, laboratory results, medications, and documents.

Require Authorized Merge Decisions

Only trusted patient identity management processes should initiate merges. Do not infer that two records belong to the same patient solely because their demographic details are similar.

Preserve Previous Patient Identifiers

Maintain prior identifier relationships and historical references where supported. This helps connected systems locate clinical information created before the merge.

Validate Complete Identifier Domains

Use identifier values, assigning authorities, and identifier types. Do not assume that a medical record number is unique across every connected facility.

Implement Idempotency and Audit Logging

Track merge messages, source authorization, previous and surviving identifiers, processing results, and timestamps. Prevent repeated messages from generating inconsistent identity changes.

Verify Downstream Clinical Record Continuity

After processing a merge, confirm that encounters, laboratory results, medication records, imaging studies, and documents remain associated with the correct patient identity.

Frequently Asked Questions About HL7 ADT A40 Messages

Need Help With HL7 ADT A40 Integration?

Patient identity merges require reliable coordination between registration systems, EHRs, enterprise master patient index platforms, laboratory systems, and other connected applications. Taction Software supports HL7 interface development, Mirth Connect implementation, patient identity mapping, and healthcare interoperability.

Our engineers can help healthcare organizations implement A40 workflows, configure PID and MRG transformations, investigate merge errors, and establish monitoring and reconciliation procedures.

HL7 Patient Merge Interface Development

We develop HL7 A40 interfaces based on source and destination requirements, including surviving and prior identifier mapping, merge validation, and patient record continuity.

Mirth Connect Development and Integration

Our engineers configure Mirth Connect channels for patient merge notifications, including JavaScript transformations, secure routing, acknowledgment handling, and exception management.

EHR and Master Patient Index Integration

We support integration between EHRs, registration systems, and enterprise master patient index platforms using approved patient identity management workflows.

Production Monitoring and Troubleshooting

We help investigate failed merges, identifier domain mismatches, duplicate notifications, acknowledgment errors, and downstream patient record inconsistencies.

Need help with HL7 patient merge integration? Explore our HL7 interface messaging services or EHR and EMR integration services to discuss your requirements.