HL7 ADT A46 Message: Change Patient ID, Structure, Segments & Examples

The HL7 ADT A46message is a patient administration event used to notify connected healthcare systems that an existing patient's identifier has changed. Officially named ADT A46: Change Patient ID, it supports legacy applications that maintain patient identifiers in PID-2.

Unlike a patient merge, A46 communicates a correction or replacement of an identifier without instructing systems to combine two separate patient records. The event is retained for backward compatibility, while A47 is preferred for modern patient identifier list changes. This guide explains A46 message structure, PID and MRG field mapping, practical HL7 examples, Mirth Connect integration, acknowledgment handling, troubleshooting, and implementation best practices.

What Is an HL7 ADT A46 Message?

An HL7 ADT A46 message communicates a change to a patient's existing identifier. The event is used when the patient record remains the same but its identifier must be corrected or replaced. For example, a registration system may discover that a patient ID was entered incorrectly or must be changed following an administrative correction.

The system generates an A46 notification to inform connected applications of the new identifier and the previous value. A46 differs from a patient merge because it does not indicate that two patient records should be combined. See the HL7 ADT messages guide for the full event family.

Purpose of the HL7 A46 Event

A46 communicates a patient ID replacement so connected applications can update references to the same patient record without treating the change as a merge.

When Is an ADT A46 Message Generated?

An A46 message may be generated when a legacy registration system corrects an incorrectly assigned patient ID or replaces an identifier under an approved administrative workflow.

Which Healthcare Systems Receive A46 Messages?

Legacy EHRs, patient registration platforms, laboratory systems, radiology applications, master patient indexes, and integration engines may receive A46 notifications.

Why A46 Is Considered a Legacy Event

A46 uses the older Patient ID field, PID-2. Modern HL7 integrations generally use A47 for changes involving the patient identifier list in PID-3.

Why Accurate A46 Processing Matters

An incorrect identifier change can disconnect clinical records, orders, and results from their patient. Receiving systems must validate the previous and replacement identifiers before processing.

HL7 ADT A46 Message Structure and Segments

In HL7 Version 2.5, A46 uses the ADT_A30 message structure. The core message contains MSH, EVN, PID, and MRG segments. SFT and PD1 may also appear according to the supported version and implementation profile.

The PID segment identifies the patient using the new, correct patient ID. The MRG segment carries the previous patient ID that is being replaced. For the legacy A46 event, PID-2 contains the new patient ID and MRG-4 contains the previous patient ID.

HL7 ADT A46 Message Structure

MSH
[{SFT}]
EVN
PID
[PD1]
MRG

MSH Segment: Message Header

MSH identifies the sending application, receiving application, timestamp, message control ID, and HL7 version. MSH-9 contains ADT^A46^ADT_A30.

EVN Segment: Event Information

EVN records administrative details about the patient ID change, including when the event was recorded.

PID Segment: New Patient Identifier

PID-2 contains the new patient ID. This is the replacement identifier that receiving systems should use after the approved correction.

MRG Segment: Previous Patient Identifier

MRG-4 contains the prior patient ID. It allows receiving systems to locate the existing patient record and update its identifier.

Optional PD1 Segment: Additional Demographics

PD1 may carry additional patient demographic information when supported by the interface. It does not determine the identifier change direction.

HL7 ADT A46 Message Example With Field Explanation

Consider a hospital that discovers an incorrectly assigned patient ID. The patient's previous identifier is PAT460099. The correct replacement identifier is PAT460001. The patient remains the same person, and no duplicate patient records are being merged. After the registration team approves the correction, the source system generates an A46 notification. Connected applications use the new identifier in PID-2 and the previous identifier in MRG-4 to update the existing patient's identity references.

Complete HL7 ADT A46 Sample Message

MSH|^~\&|REGISTRATION|HOSPITAL|EHR|MAIN|20261022173000||ADT^A46^ADT_A30|MSG46001|P|2.5
EVN|A46|20261022173000
PID|1|PAT460001|||WILSON^EMILY||19880215|F
MRG||||PAT460099

All patient information is fictional. The sample shows the new patient ID in PID-2 and the previous patient ID in MRG-4.

Replace the old ID for the same patient record.

Explore each segment and its key fields:

MSH-9: Message Type and Trigger Event

ADT^A46^ADT_A30 identifies the change patient ID event and the message structure used by HL7 v2.5.

EVN-2: Recorded Date and Time

EVN-2 records when the identifier change was entered. It supports audit history and helps downstream applications track administrative corrections.

PID-2: New Patient ID

PID-2 contains PAT460001, the new identifier. The receiving application should use this value after validating the change.

MRG-4: Previous Patient ID

MRG-4 contains PAT460099, the identifier being replaced. It enables the receiving application to locate the existing patient record.

Why A46 Is Not a Patient Merge

A46 changes an identifier associated with an existing patient record. It does not instruct the receiving system to combine two different patient records.

Important HL7 A46 Fields and Mapping

A46 requires the receiver to distinguish the old patient identifier from its replacement. Both values refer to the same patient identity, rather than representing two records to be merged.

HL7 specifies that the identifier change occurs at the PID-2 level. Subordinate account and visit identifiers normally remain unchanged, although their association follows the corrected patient identifier. Where an implementation changes subordinate identifiers as well, the old and new values must be mapped as corresponding pairs. Our HL7 parsing and data mapping team can document identifier mapping across every receiving system.

PID-2: Correct Replacement Patient ID

PID-2 identifies the corrected patient ID that should be used after the change. It must be interpreted within the identifier namespace agreed upon by the sender and receiver.

MRG-4: Incorrect Previous Patient ID

MRG-4 identifies the old patient ID being replaced. The destination uses this value to locate the existing record and apply the authorized identifier correction.

PID-3: Additional Patient Identifiers

PID-3 may provide additional patient identity information, but it is not the defining replacement field for A46. Newer interfaces should consider A47 for identifier-list changes.

MSH-10: Message Control Identifier

MSH-10 identifies the message for acknowledgment correlation, duplicate detection, and operational monitoring. It is not a patient identifier and must not be used for patient matching.

EVN-2: Recorded Event Time

EVN-2 records when the administrative event was entered. It helps downstream applications reconcile the timing of identifier changes and related transactions.

How HL7 ADT A46 Patient ID Change Workflows Operate

An A46 workflow begins when a registration or identity management system identifies an incorrectly assigned patient ID. An authorized user or automated identity process verifies the correct replacement value. The source system updates the identifier and generates an A46 notification for connected legacy applications.

An integration engine validates the message and routes it to the relevant destinations. Each receiving system locates the existing patient record using the previous ID and updates its reference to the replacement ID, preserving clinical and administrative history.

Step 1: Identify the Incorrect Patient ID

Registration staff or an identity management application discovers an identifier that must be corrected. The patient identity and reason for the change are verified.

Step 2: Approve the Replacement Identifier

The authorized process determines the correct patient ID and confirms that it does not conflict with another patient's identifier in the relevant namespace.

Step 3: Generate the A46 Notification

The source system generates an A46 message with the new ID in PID-2 and the previous ID in MRG-4.

Step 4: Validate and Route the Message

The integration engine validates message structure, identifier values, sending application, and configured authorization rules before forwarding the change.

Step 5: Update Downstream Patient References

Receiving systems replace the old identifier while preserving the patient's clinical history, account relationships, visit references, and audit trail.

How to Implement HL7 ADT A46 Using Mirth Connect

Mirth Connectcan receive A46 messages, validate the previous and replacement patient IDs, and route controlled identifier changes to approved destination applications. Because A46 modifies an existing patient's identifier, the interface should prevent accidental patient merges and identifier collisions.

The channel must also confirm that the sender is authorized to initiate the correction. The following examples use an HL7 v2.5 message parsed into Mirth Connect's XML representation. They illustrate validation and transformation rather than directly modifying patient records.

Configure the Mirth Connect Source Connector

Create an MLLP Listener with HL7 v2.x inbound data type. Configure trusted sending systems, appropriate transport security, acknowledgments, and access-controlled logging.

Filter HL7 ADT A46 Messages

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

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

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

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

return messageType === 'ADT' &&
       triggerEvent === 'A46' &&
       structure === 'ADT_A30' &&
       version === '2.5';

Extract the Previous and Replacement Patient IDs

function getComponent(segment, field, number) {
    if (segment[field].length() === 0) {
        return '';
    }

    return segment[field][0]
        [field + '.' + number]
        .toString().trim();
}

var msh = msg['MSH'];
var pid = msg['PID'];
var mrg = msg['MRG'];

if (pid.length() === 0 ||
    mrg.length() === 0) {
    throw new Error(
        'Missing PID or MRG segment'
    );
}

var newPatientId =
    getComponent(pid, 'PID.2', 1);

var oldPatientId =
    getComponent(mrg, 'MRG.4', 1);

var messageControlId =
    getComponent(msh, 'MSH.10', 1);

if (!newPatientId ||
    !oldPatientId ||
    !messageControlId) {
    throw new Error(
        'Missing required A46 identifiers'
    );
}

if (newPatientId === oldPatientId) {
    throw new Error(
        'Old and new patient IDs are identical'
    );
}

var changeEvent = {
    eventType: 'A46',
    operation: 'changeLegacyPatientId',

    previousPatientId: oldPatientId,
    replacementPatientId: newPatientId,

    messageControlId: messageControlId,

    status: 'pending_validation'
};

channelMap.put(
    'patientIdChange',
    JSON.stringify(changeEvent)
);

This example assumes an agreed identifier namespace. Production validation must also consider complete CX values, assigning authorities, and identifier collisions.

Transform A46 Into a Controlled Change Request

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

var request = {
    operation: 'validatePatientIdChange',

    previousIdentifier:
        event.previousPatientId,

    replacementIdentifier:
        event.replacementPatientId,

    approvalRequired: true,

    sourceMessageId:
        event.messageControlId
};

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

The JSON is an illustrative application payload, not a standardized HL7 or FHIR API.

Validate Identifier Ownership and Uniqueness

Confirm that the old identifier belongs to the intended patient and that the replacement value is valid and available within the relevant assigning authority.

Monitor Identifier Changes and Retries

Track acknowledgments, rejected changes, duplicate messages, and downstream synchronization. Preserve an audit trail showing the previous and replacement identifiers.

HL7 ADT A46 ACK Message Examples and Error Handling

An HL7 acknowledgment communicates whether the receiving application accepted or rejected the A46 message. A typical ACK contains MSH and MSA segments. ERR may provide diagnostic information when processing fails. In original acknowledgment mode, AA indicates application acceptance, AE indicates an application error, and AR indicates rejection.

For identifier changes, an accepted message does not necessarily establish that every downstream system has updated its patient references. Reconciliation should be monitored separately.

Successful A46 ACK: AA

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022173001||ACK^A46^ACK|ACK46001|P|2.5
MSA|AA|MSG46001

Application Error ACK: AE

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022173002||ACK^A46^ACK|ACK46002|P|2.5
MSA|AE|MSG46001
ERR|||204^Unknown Key Identifier^HL70357|E

Application Rejection ACK: AR

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022173003||ACK^A46^ACK|ACK46003|P|2.5
MSA|AR|MSG46001

Correlate ACKs With the Original Message

MSA-2 should reference the original A46 message's MSH-10 identifier. This allows the sending system to correlate responses with the correct identifier change.

Handle Duplicate and Failed Messages

Before retrying an unacknowledged change, determine whether the destination already updated the identifier. Avoid repeating a change that has already succeeded.

Common HL7 ADT A46 Integration Errors and Troubleshooting

A46 integration failures often involve missing legacy identifiers, incorrect mapping between old and new values, or applications that no longer support PID-2. Some systems also confuse A46 with A40, which represents a patient merge, or A47, which changes the patient identifier list.

These distinctions are critical because an identifier replacement should not combine two separate patient records. Troubleshooting should begin with the sender's identifier namespace, the receiving application's supported events, and the previous and replacement identifiers. Our HL7 interface messaging team can help trace identifier change failures across downstream systems.

PID-2 Is Missing

Modern applications may not populate PID-2 because it is retained for backward compatibility. Confirm that the source supports the legacy field before using A46.

MRG-4 Contains an Incorrect Previous ID

If the old identifier does not match the intended patient record, the destination may reject the change or update the wrong record. Verify the previous identifier.

Old and New IDs Are Reversed

A reversed mapping can replace the correct identifier with the incorrect value. Confirm that PID-2 contains the replacement ID and MRG-4 contains the previous ID.

Receiving System Supports Only A47

Some modern applications accept A47 but not A46. Review the interface specification and determine whether a supported identifier-list change workflow is available.

Identifier Change Is Incorrectly Processed as a Merge

A46 should not be interpreted as combining two patient identities. Use the destination's identifier-change operation rather than its patient-merge operation.

HL7 ADT A46 vs A47, A39, A40, and A48

HL7 defines different events for changing patient identifiers, merging patient identities, and changing alternate identifiers. A46 is a legacy identifier-change event using PID-2. A47 is the preferred event for changes involving PID-3, the patient identifier list. A39 and A40 are merge events, while A48 concerns a legacy alternate patient identifier. Selecting the correct event prevents downstream systems from applying an unintended identity operation.

A46 vs A47: Legacy and Modern Identifier Changes

A46 uses PID-2 and MRG-4 to replace a patient ID. A47 uses PID-3 and MRG-1 for patient identifier list changes and is preferred for newer interfaces.

A46 vs A39: Identifier Change and Patient Merge

A46 replaces an incorrect identifier for an existing patient record. A39 merges patient records previously maintained under different legacy patient IDs.

A46 vs A40: Change and Merge Operations

A46 changes an identifier without merging patient identities. A40 consolidates patient identifier lists as part of a patient merge operation.

A46 vs A48: Primary and Alternate Patient IDs

A46 changes the legacy patient ID field. A48 changes a legacy alternate patient ID. Both are retained for compatibility with older applications.

Best Practices for Reliable HL7 A46 Integration

Reliable A46 processing requires precise old-to-new identifier mapping, controlled authorization, and preservation of historical patient references. Healthcare organizations should confirm that an identifier change is the correct operation rather than a patient merge.

Integration teams should also verify the receiving system's support for PID-2 and MRG-4. Testing should include missing identifiers, collisions, duplicate messages, out-of-order events, and applications that support A47 instead of A46.

Verify the Patient Identity

Confirm that the previous and replacement identifiers refer to the same patient. Do not apply an identifier change based solely on demographic similarity.

Preserve Old-to-New Identifier Direction

Use MRG-4 for the previous identifier and PID-2 for the replacement. Validate the mapping before forwarding the message.

Maintain Historical Identifier References

Preserve the previous identifier in an appropriate audit or cross-reference mechanism so historical transactions remain traceable after the change.

Prevent Identifier Collisions

Verify that the replacement identifier is not already assigned to a different patient within the same identifier namespace.

Prefer A47 for New Implementations

When both systems support it, use A47 for patient identifier list changes rather than introducing a new legacy A46 interface.

Frequently Asked Questions About HL7 ADT A46 Messages

Need Help With HL7 ADT A46 Integration?

Legacy patient ID changes require accurate coordination between EHRs, registration systems, master patient indexes, and downstream clinical applications. Taction Software supports HL7 interface development, Mirth Connect implementation, patient identity management integration, and healthcare interoperability.

Legacy HL7 Identifier Change Interfaces

We help healthcare organizations maintain A46 interfaces, validate old-to-new mappings, and preserve historical patient identifiers.

Mirth Connect Development and Integration

Our engineers develop Mirth Connect channels for identifier changes, including validation, transformations, acknowledgments, secure routing, and monitoring.

EHR and Master Patient Index Integration

We support integration between EHRs, patient registration platforms, master patient indexes, and clinical applications using approved identity management workflows.

Migration From A46 to A47

We help assess legacy A46 integrations and plan transitions to A47 where supported by the participating applications.

Need help with HL7 patient ID changes? Explore HL7 Integration and Taction Software's EHR integration services to discuss your requirements.