HL7 ADT A47 Message: Change Patient Identifier List, Structure, Segments & Examples

The HL7 A47message is a patient administration event used to communicate a change to a patient's identifier list. Officially known as ADT A47: Change Patient Identifier List, it helps healthcare systems update identifiers while maintaining continuity between existing clinical and administrative records. A47 is especially important when a patient identifier is corrected or replaced without merging two separate patient records. Accurate processing requires careful mapping of PID-3 and MRG-1, including identifier assigning authorities and types. This guide covers A47 message structure, realistic examples, Mirth Connect integration, acknowledgment handling, and patient identity troubleshooting.

What Is an HL7 ADT A47 Message?

HL7 ADT A47 communicates a change to a patient identifier list. It is part of the HL7 Version 2 patient administration framework and is distinct from patient merge events. An A47 message identifies the patient's updated identifier and the previous identifier that needs to be changed.

Receiving applications use the message to maintain the correct relationship between the patient's identity and associated records. This operation must be controlled carefully because identifiers connect encounters, laboratory results, prescriptions, documents, and billing information. For the wider event family, see our HL7 ADT messages guide.

Purpose of the HL7 A47 Event

A47 communicates that an existing patient identifier has changed. The receiving system should update its patient identity mapping while preserving clinical and administrative record associations.

When Is an A47 Message Generated?

A47 may be generated when an incorrect medical record number is corrected, an identifier is replaced, or an authoritative registration system changes a patient identifier.

Which Healthcare Systems Receive A47 Messages?

EHRs, master patient index systems, laboratory systems, pharmacy platforms, billing applications, and health information exchanges may receive A47 messages when they support identifier corrections.

Why A47 Is Different From a Patient Merge

A47 changes an identifier associated with a patient. A40 merges patient identifier lists. These events should not be processed using identical rules because their effects on patient identity differ.

Why Accurate A47 Processing Matters

Incorrect patient identifier changes can disconnect clinical information from its intended patient. Receiving systems must validate identifier domains, previous values, new values, and patient identity before applying updates.

HL7 ADT A47 Message Structure and Segments

An HL7 A47 message uses the standard HL7 Version 2 segment format. In v2.5, A47 uses the ADT_A30 message structure, shared with other identifier events. The message contains administrative metadata, patient identification, and information about the previous identifier.

The PID segment identifies the patient using the updated identifier list, and the MRG segment identifies the previous patient identifier that is being changed. These two segments are central to correctly interpreting the A47 operation. The exact segment requirements and optional groups depend on the HL7 version and implementation profile.

MSH Segment: Message Header

MSH identifies the sender, receiver, message timestamp, trigger event, control identifier, and HL7 version. MSH-9 identifies the A47 event.

EVN Segment: Event Information

EVN records administrative information about the identifier change, including the event timestamp. It supports audit tracking and message reconciliation.

PID Segment: Updated Patient Identification

PID contains patient identification information, including the updated patient identifier list in PID-3. The destination uses these values to identify the intended resulting patient identity.

MRG Segment: Previous Patient Identification

MRG identifies previous patient information. For A47 processing, MRG-1 is especially important because it carries the prior patient identifier list.

Optional Patient and Visit Information

Additional patient or visit segments may appear according to the implementation profile. The receiving application must validate the message structure rather than assuming all optional information is present.

HL7 ADT A47 Message Example With Field Explanation

Consider a hospital registration system that discovers an incorrect medical record number. The patient currently has identifier MRN470001, but the authoritative registration system determines that the correct identifier is MRN470099. The patient remains the same person, and no separate patient records are being merged.

The registration system generates an A47 notification. The receiving EHR must replace the previous identifier association while preserving the patient's existing clinical records.

Complete HL7 ADT A47 Sample Message

MSH|^~\&|REGISTRATION|HOSPITAL|EHR|MAIN|20261022170000||ADT^A47^ADT_A30|MSG47001|P|2.5
EVN|A47|20261022165500
PID|1||MRN470099^^^HOSPITAL^MR||MARTIN^OLIVIA||19890312|F
MRG|MRN470001^^^HOSPITAL^MR

All patient information is fictional.

MRG-1 identifies the previous identifier; PID-3 identifies the updated identifier.

Explore each segment and its key fields:

MSH Segment Explained

MSH identifies the registration application as the source and the EHR as the destination. ADT^A47^ADT_A30 identifies the patient identifier change event.

EVN Segment Explained

EVN records the administrative event timestamp. Receiving systems can use this information to investigate delayed changes and reconstruct the identifier correction history.

PID-3: Updated Patient Identifier

PID-3 contains the updated medical record number MRN470099. Its assigning authority and identifier type provide essential context for patient matching.

MRG-1: Previous Patient Identifier

MRG-1 contains the previous identifier MRN470001. The destination uses it to locate the existing patient identity association before applying the correction.

Patient Demographic Fields

PID-5, PID-7, and PID-8 provide patient name, birth date, and administrative sex information in this example. These fields support validation but should not replace authoritative identifier matching.

Important HL7 ADT A47 Fields and Mapping

A47 integration depends on correctly distinguishing the updated patient identifier from the previous identifier. The updated value is communicated in PID-3, while the previous value is communicated in MRG-1.

Both fields use structured identifier information that may include an identifier value, assigning authority, and identifier type. A receiving application should compare the complete identifier context, not just the medical record number string. Our HL7 parsing and data mapping team can document identifier-domain rules for your interfaces.

PID-3.1: Updated Identifier Value

PID-3.1 contains the updated identifier value. The destination should verify that it belongs to the expected patient identifier domain before applying the change.

PID-3.4: Assigning Authority

PID-3.4 identifies the authority responsible for the identifier. It is essential when multiple hospitals or applications may issue similar identifier values.

PID-3.5: Identifier Type Code

PID-3.5 indicates the identifier type, such as a medical record number. Receiving applications should preserve this distinction when maintaining multiple identifiers.

MRG-1: Previous Identifier List

MRG-1 identifies the previous patient identifier. It enables the destination to locate the existing patient record association and reconcile it with the updated identifier.

MSH-10: Message Control Identifier

MSH-10 provides a unique identifier for message tracking and acknowledgment correlation. It also supports duplicate detection and troubleshooting.

How HL7 ADT A47 Patient Identifier Change Workflows Operate

A47 workflows begin when an authoritative registration or patient identity system determines that an existing identifier must change. The source verifies the patient and both identifier values, then generates an A47 notification containing the updated identifier in PID-3 and the previous identifier in MRG-1.

An integration engine validates the message and routes it to connected systems. The destination confirms the existing patient association and applies the identifier correction without creating a second patient or merging unrelated records.

Step 1: Identify the Incorrect or Replaced Identifier

The source identifies the patient identifier that needs correction. Authorized staff or identity management processes confirm that the action is an identifier change rather than a patient merge.

Step 2: Validate the Previous and Updated Values

The source verifies both identifiers and their assigning authorities. The updated identifier must not conflict with an unrelated patient record.

Step 3: Generate the A47 Message

The source creates an A47 message containing the updated identifier in PID-3 and the previous identifier in MRG-1.

Step 4: Validate and Route the Message

An integration engine checks the event type, patient identifiers, assigning authorities, and message structure before forwarding the notification.

Step 5: Apply and Acknowledge the Identifier Change

The destination verifies the existing patient record and updates its identifier association. It records the processing result and returns an acknowledgment.

How to Implement HL7 ADT A47 Messages Using Mirth Connect

Mirth Connect can receive, validate, transform, and route A47 messages between patient administration systems, EHRs, and master patient index platforms. A typical implementation uses an MLLP listener, validates the A47 event, extracts PID-3 and MRG-1, and forwards an identifier change request to an authorized destination.

The destination should perform the actual patient identity update after checking for conflicts and preserving record associations. Mirth Connect development services can support these requirements.

Configure the Mirth Connect Source Connector

Create a channel using an MLLP Listener with HL7 v2.x inbound data type. Configure sender authorization, transport security, acknowledgment behavior, and protected health information retention policies.

Filter HL7 ADT A47 Messages

Use a JavaScript filter to identify A47 messages.

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

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

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

return messageType === 'ADT' &&
       triggerEvent === 'A47' &&
       version === '2.5';

This filter assumes HL7 v2.5. Production interfaces should additionally validate MSH-9.3, sender identity, segment requirements, and the agreed implementation profile.

Extract Previous and Updated Patient Identifiers

Use a JavaScript transformer to extract PID-3 and MRG-1.

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

    var field = segment[fieldName];

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

    return {
        value: field[fieldName + '.1'].toString().trim(),
        assigningAuthority:
            field[fieldName + '.4'].toString().trim(),
        identifierType:
            field[fieldName + '.5'].toString().trim()
    };
}

var msh = msg['MSH'];

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

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

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

if (messageType !== 'ADT' ||
    eventType !== 'A47' ||
    version !== '2.5') {
    throw new Error(
        'Unsupported HL7 event or version'
    );
}

var updatedId = getCX(msg['PID'], 3);
var previousId = getCX(msg['MRG'], 1);

if (!updatedId || !previousId ||
    !updatedId.value || !previousId.value) {
    throw new Error(
        'Missing previous or updated patient identifier'
    );
}

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

var identifierChange = {
    eventType: 'A47',

    previousIdentifier: previousId,
    updatedIdentifier: updatedId,

    messageControlId: controlId,

    processingStatus:
        'pending_identity_validation'
};

channelMap.put(
    'identifierChange',
    JSON.stringify(identifierChange)
);

This example demonstrates basic extraction. Production implementations must preserve complete CX assigning authority components, support relevant identifier repetitions, and validate patient identity relationships.

Transform A47 Into an Identity Update Request

Create a destination-specific request that identifies the previous and updated identifiers without directly modifying patient records.

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

var request = {
    action: 'requestPatientIdentifierChange',

    previousIdentifier:
        event.previousIdentifier,

    updatedIdentifier:
        event.updatedIdentifier,

    processingStatus:
        'pending_conflict_check',

    sourceMessageControlId:
        event.messageControlId
};

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

This JSON structure is illustrative, not an HL7-defined API. The destination must verify the identifier change and confirm that the updated identifier does not belong to another patient.

Validate Identifier Conflicts

Before applying the change, verify that the previous identifier resolves to the expected patient and the updated identifier does not conflict with an unrelated record.

Configure Monitoring and Exception Handling

Configure acknowledgment correlation, duplicate detection, controlled retries, audit logging, and exception queues for identifier changes that cannot be safely processed.

HL7 ADT A47 ACK Message Examples and Error Handling

HL7 acknowledgments communicate whether an A47 message was accepted or rejected according to the configured processing agreement. In original acknowledgment mode, AA indicates application acceptance, AE indicates an application error, and AR indicates rejection.

Because identifier changes can affect many linked records, message acceptance should not be confused with completion of every downstream identity reconciliation process.

Successful A47 ACK: AA

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022170001||ACK^A47^ACK|ACK47001|P|2.5
MSA|AA|MSG47001

Application Error ACK: AE

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022170002||ACK^A47^ACK|ACK47002|P|2.5
MSA|AE|MSG47001
ERR|||204^Unknown Key Identifier^HL70357|E

This illustrative error may occur when the destination cannot locate the previous identifier.

Application Rejection ACK: AR

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022170003||ACK^A47^ACK|ACK47003|P|2.5
MSA|AR|MSG47001

Correlate ACK Responses With Original Messages

MSA-2 should reference the original message's MSH-10 identifier. Monitoring records should preserve both patient identifier values and the processing result.

Handle Retries Without Duplicate Changes

Before resending an A47 message, determine whether the destination already processed the identifier change. Repeated processing must not create duplicate patient records or reverse a later correction.

Common HL7 ADT A47 Integration Errors and Troubleshooting

Patient identifier changes can fail because of missing previous identifiers, assigning authority mismatches, duplicate patient records, or unsupported identity operations. A destination may locate the previous identifier but discover that the updated identifier is already associated with another patient.

Another application may incorrectly process A47 as a merge event, potentially affecting unrelated clinical records. Reliable troubleshooting requires examining both identifier values, their domains, and the destination's patient identity history.

Previous Identifier Cannot Be Found

The destination may not recognize MRG-1. Verify the previous identifier, assigning authority, and patient identity records before attempting the change.

Updated Identifier Already Exists

The updated identifier may already belong to another patient. Route the conflict to an authorized identity management workflow rather than overwriting the existing record.

Assigning Authority Is Incorrect

Two facilities may issue identical identifier strings. Validate assigning authority components so the destination can distinguish identifiers belonging to different domains.

A47 Is Mistaken for A40

A47 changes a patient identifier list, while A40 merges patient identifier lists. Treating these events identically can cause incorrect patient record associations.

Downstream Records Retain the Previous Identifier

Some connected applications may continue referencing the old identifier. Monitor synchronization and preserve appropriate identifier history or aliases according to the destination's identity management policy.

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

HL7 Version 2 includes different events for changing patient identifiers, merging patient records, moving identity information, and updating general patient information. These events should not be used interchangeably. Related identity events on this site include A43, A30, A18, and A08.

A47 vs A40: Change and Merge

A47 changes an identifier associated with a patient. A40 merges patient identifier lists. The distinction is essential for protecting unrelated patient records.

A47 vs A43: Change and Move

A47 communicates an identifier change, while A43 is used for moving patient information. Receiving applications must follow the specific event's identity management rules.

A47 vs A46: Current and Legacy Events

A46 is retained for backward compatibility in relevant HL7 versions. A47 provides the patient identifier list change event used in newer identity workflows.

A47 vs A08: Identity and Demographic Updates

A08 communicates general patient information changes. A47 specifically addresses a patient identifier list change and requires handling of previous identifiers through MRG.

Best Practices for Reliable HL7 A47 Integration

Patient identifier changes require strong controls because identifiers connect records across multiple healthcare applications. The authoritative source should verify the correction and communicate complete identifier information.

Receiving applications must check for collisions, preserve historical associations, and prevent accidental merges. Integration teams should test changes involving duplicate values across facilities, delayed messages, and partial downstream synchronization.

Preserve Complete Identifier Domains

Use identifier values, assigning authorities, and identifier types. Never assume that a medical record number string is globally unique.

Validate Before Applying Changes

Confirm that the previous identifier belongs to the intended patient and that the updated identifier does not conflict with another patient record.

Maintain Historical Identifier Associations

Retain previous identifier information where supported. Historical associations can help reconcile documents, laboratory results, and encounters created before the correction.

Implement Idempotency and Audit Logging

Track message control identifiers and identity changes. Record the previous identifier, updated identifier, processing result, and authorized source.

Test Downstream Patient Record Continuity

Verify that existing encounters, laboratory results, prescriptions, and clinical documents remain associated with the correct patient after the identifier change.

Frequently Asked Questions About HL7 ADT A47 Messages

Need Help With HL7 ADT A47 Integration?

Patient identifier changes require careful coordination between registration systems, EHRs, master patient index platforms, and connected clinical applications. Taction Software supports HL7 interface development, Mirth Connect implementation, patient identifier mapping, and healthcare interoperability.

HL7 Patient Identity Interface Development

We develop HL7 identity management interfaces based on source and destination requirements, including PID and MRG mapping, identifier validation, and patient record continuity.

Mirth Connect Development and Integration

Our engineers configure Mirth Connect channels for identifier changes, including JavaScript transformations, secure routing, acknowledgments, and exception monitoring.

EHR and Master Patient Index Integration

We support integration between EHRs, registration systems, and patient identity platforms using approved identifier change and reconciliation workflows.

Production Monitoring and Troubleshooting

We help investigate identifier conflicts, missing previous values, duplicate messages, acknowledgment failures, and downstream patient identity discrepancies.

Need help with HL7 patient identity integration? Explore our HL7 interface messaging services and EHR and EMR integration services.