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

The HL7 ADT A48message is a patient administration event used to communicate a change to a patient's alternate identifier in legacy healthcare systems. Officially named ADT A48: Change Alternate Patient ID, this event helps synchronize identifier corrections across registration systems, electronic health records, laboratory applications, and other connected platforms.

A48 is retained for backward compatibility with applications using PID-4, the legacy Alternate Patient ID field. Unlike a patient merge, A48 changes an identifier associated with an existing patient identity. This guide explains the A48 message structure, PID and MRG fields, HL7 examples, Mirth Connect implementation, acknowledgments, troubleshooting, and integration best practices.

What Is an HL7 ADT A48 Message?

An HL7 ADT A48 message notifies connected healthcare applications that an alternate patient identifier has changed. Older patient administration systems may maintain multiple identifiers for the same person, including a primary patient ID and an alternate ID used by another department or application.

When the alternate identifier must be corrected, the source system can generate an A48 message. The receiving application uses the previous and replacement identifiers to update the same patient's identity references. A48 does not instruct the receiving system to merge two separate patient records. See the HL7 ADT messages guide for the full event family.

Purpose of the HL7 A48 Event

A48 communicates an alternate patient identifier replacement. It helps legacy applications maintain consistent patient references when an alternate identifier is corrected or changed.

When Is an ADT A48 Message Generated?

An A48 message may be generated when a registration application corrects an incorrectly assigned alternate patient ID or replaces an outdated identifier through an approved workflow.

Which Healthcare Systems Receive A48 Messages?

Legacy EHRs, patient registration applications, laboratory systems, radiology platforms, master patient indexes, and integration engines may receive A48 notifications when they maintain alternate patient identifiers.

Why A48 Is a Legacy Event

A48 uses PID-4, a field retained for backward compatibility. Modern interfaces generally use PID-3, the Patient Identifier List, and the A47 event for identifier changes.

Why Accurate A48 Processing Matters

An incorrect alternate identifier change can disconnect laboratory results, orders, or historical records from the correct patient. The receiving application must validate identifier ownership before applying the correction.

HL7 ADT A48 Message Structure and Segments

In HL7 Version 2.5, A48 uses the ADT_A30 message structure. The message contains MSH, EVN, PID, and MRG segments, with optional SFT and PD1 segments. PID identifies the patient and provides the replacement alternate patient identifier. MRG provides the previous alternate identifier that must be replaced.

For A48, the defining fields are PID-4 for the new alternate patient ID and MRG-2 for the previous alternate patient ID. These fields should not be confused with PID-3 and MRG-1, which are used for patient identifier list changes.

HL7 ADT A48 Message Structure

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

MSH Segment: Message Header

MSH identifies the sender, receiver, timestamp, message control ID, and HL7 version. MSH-9 identifies the event as ADT^A48^ADT_A30.

EVN Segment: Event Information

EVN records administrative information about the alternate patient ID change, including the recorded event timestamp.

PID Segment: Replacement Alternate Patient ID

PID-4 contains the new alternate patient identifier. PID-3 may also identify the patient using the primary identifier list.

MRG Segment: Previous Alternate Patient ID

MRG-2 contains the previous alternate patient identifier. It allows receiving systems to locate and update the existing alternate identifier reference.

Optional PD1 Segment: Additional Demographics

PD1 may carry additional patient information when supported by the interface. It does not replace the required identifier-change mapping.

HL7 ADT A48 Message Example With Field Explanation

Consider a hospital that maintains an alternate patient identifier for a legacy laboratory application. The patient's primary medical record number is MRN480001. The old alternate identifier is ALT480099, but the correct replacement identifier is ALT480001. The hospital confirms that the change affects only the alternate identifier, not the patient's identity or primary medical record number. The registration system generates an A48 message to notify connected applications.

Complete HL7 ADT A48 Sample Message

MSH|^~\&|REGISTRATION|HOSPITAL|EHR|MAIN|20261022180000||ADT^A48^ADT_A30|MSG48001|P|2.5
EVN|A48|20261022180000
PID|1||MRN480001^^^HOSPITAL^MR|ALT480001^^^HOSPITAL^AN|WILSON^EMILY||19880215|F
MRG||ALT480099^^^HOSPITAL^AN

All patient information is fictional. In this example, PID-3 identifies the patient, PID-4 contains the new alternate patient ID, and MRG-2 contains the previous alternate patient ID.

Change the alternate ID for the same patient.

Explore each segment and its key fields:

MSH-9: Message Type and Trigger Event

ADT^A48^ADT_A30 identifies the alternate patient ID change event and its HL7 v2.5 message structure.

PID-3: Patient Identifier List

PID-3 identifies the patient using the current patient identifier list. It provides identity context for the alternate identifier correction.

PID-4: New Alternate Patient ID

PID-4 contains ALT480001, the replacement alternate identifier that should be used after the approved correction.

MRG-2: Previous Alternate Patient ID

MRG-2 contains ALT480099, the previous alternate identifier being replaced. The receiving system uses this value to locate the existing reference.

Why A48 Is Not a Patient Merge

A48 changes an alternate identifier belonging to the same patient. It does not instruct connected systems to consolidate two separate patient records.

Important HL7 A48 Fields and Mapping

An A48 message must clearly identify the previous alternate patient ID and its replacement. The event operates at the alternate patient identifier level, meaning the patient identity remains unchanged.

The standard also indicates that subordinate account and visit identifiers ordinarily remain unchanged, although their association follows the corrected alternate patient identifier. If subordinate identifiers must also change, old and new values must be supplied as corresponding pairs. This distinction is important because A48 should not be processed as a patient merge or as a general demographic update. Our HL7 parsing and data mapping team can document identifier mapping across every receiving system.

PID-4: Correct Replacement Alternate ID

PID-4 contains the new alternate patient ID. The destination should verify that the replacement belongs to the intended patient and is valid within the appropriate identifier namespace.

MRG-2: Incorrect Previous Alternate ID

MRG-2 identifies the previous alternate patient ID. The receiving application uses this value to locate the existing reference before applying the approved correction.

PID-3: Patient Identifier List

PID-3 provides additional patient identification context. It should remain consistent with the patient's established identity and must not be confused with the alternate ID being changed.

MSH-10: Message Control ID

MSH-10 identifies the HL7 message for acknowledgment correlation and duplicate detection. It should be stored separately from patient identifiers and merge history.

EVN-2: Recorded Event Timestamp

EVN-2 records when the alternate identifier change was entered. It supports audit history and helps troubleshoot delayed or out-of-order administrative notifications.

How HL7 ADT A48 Alternate Patient ID Changes Work

An A48 workflow begins when a registration or identity management application identifies an incorrect alternate patient identifier. The source system verifies the patient identity and determines the correct replacement value. After the correction is approved, the application generates an A48 notification.

The integration engine validates the message and routes it to connected systems that maintain the alternate identifier. Each receiving application locates the previous identifier and updates it to the new value while preserving the patient's clinical history and existing identity relationships.

Step 1: Identify the Incorrect Alternate ID

Registration staff or an identity management system discovers an alternate identifier that must be corrected. The source verifies the patient and the reason for the change.

Step 2: Confirm the Correct Replacement ID

The authorized workflow determines the replacement alternate ID and verifies that it does not conflict with another patient in the same identifier domain.

Step 3: Generate the A48 Notification

The source application creates an A48 message with the correct alternate ID in PID-4 and the previous alternate ID in MRG-2.

Step 4: Validate and Route the Message

The integration engine checks the event type, sender, patient identifier, previous alternate ID, and replacement alternate ID before forwarding the notification.

Step 5: Update Downstream References

Receiving applications replace the previous alternate ID and maintain appropriate historical references, audit records, and existing patient relationships.

How to Implement HL7 ADT A48 Using Mirth Connect

Mirth Connect can receive legacy A48 messages, extract alternate patient identifiers, validate the correction, and route the change to approved applications. The channel should verify that the operation is an identifier change rather than a patient merge. It must also confirm that the previous and replacement identifiers belong to the same patient and identifier namespace.

The examples below illustrate a single A48 message using Mirth Connect's HL7 v2.x XML representation. Production implementations require additional identity validation, error handling, and destination-specific mapping.

Configure the Mirth Connect Source Connector

Create an MLLP Listener using the HL7 v2.x inbound data type. Configure trusted sending applications, secure transport, acknowledgments, and restricted message logging.

Filter HL7 ADT A48 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 === 'A48' &&
       structure === 'ADT_A30' &&
       version === '2.5';

Extract the Previous and Replacement Alternate 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 patientId =
    getComponent(pid, 'PID.3', 1);

var newAlternateId =
    getComponent(pid, 'PID.4', 1);

var oldAlternateId =
    getComponent(mrg, 'MRG.2', 1);

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

if (!patientId ||
    !newAlternateId ||
    !oldAlternateId ||
    !controlId) {
    throw new Error(
        'Missing required A48 identifiers'
    );
}

if (newAlternateId === oldAlternateId) {
    throw new Error(
        'Old and new alternate IDs are identical'
    );
}

var changeEvent = {
    eventType: 'A48',

    operation: 'changeAlternatePatientId',

    patientId: patientId,

    previousAlternateId:
        oldAlternateId,

    replacementAlternateId:
        newAlternateId,

    messageControlId:
        controlId,

    processingStatus:
        'pending_validation'
};

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

This example extracts the first identifier component only. Production channels must validate complete CX identifiers, assigning authorities, identifier types, and any supported repetitions.

Transform A48 Into a Controlled Change Request

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

var request = {
    operation: 'validateAlternatePatientIdChange',

    patientIdentifier:
        event.patientId,

    previousAlternateIdentifier:
        event.previousAlternateId,

    replacementAlternateIdentifier:
        event.replacementAlternateId,

    approvalRequired: true,

    sourceMessageId:
        event.messageControlId
};

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

This JSON is an illustrative destination payload, not a standardized HL7 or FHIR API.

Validate Identifier Ownership

Confirm that both alternate identifiers refer to the same patient and that the replacement does not conflict with an identifier assigned to another patient.

Monitor Processing and Audit History

Track successful changes, rejected messages, duplicate notifications, and downstream synchronization. Preserve an audit trail containing both the previous and replacement alternate IDs.

HL7 ADT A48 ACK Message Examples and Error Handling

HL7 acknowledgments communicate whether the receiving application accepted or rejected an A48 notification. A typical ACK contains MSH and MSA segments. ERR can provide additional diagnostic information when processing fails. In original acknowledgment mode, AA indicates application acceptance, AE indicates an application error, and AR indicates rejection.

An accepted acknowledgment does not necessarily prove that every downstream application has updated its alternate patient identifier. Reconciliation should be monitored separately.

Successful A48 ACK: AA

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022180001||ACK^A48^ACK|ACK48001|P|2.5
MSA|AA|MSG48001

Application Error ACK: AE

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022180002||ACK^A48^ACK|ACK48002|P|2.5
MSA|AE|MSG48001
ERR|||204^Unknown Key Identifier^HL70357|E

Application Rejection ACK: AR

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022180003||ACK^A48^ACK|ACK48003|P|2.5
MSA|AR|MSG48001

Correlate ACKs With the Original Message

MSA-2 should match the original message's MSH-10 value. This allows the sender to identify which alternate patient ID change received the acknowledgment.

Handle Duplicate and Failed Messages

Before retrying an A48 notification, determine whether the destination already processed the identifier change. Avoid repeating successful updates or introducing conflicting identity references.

Common HL7 ADT A48 Integration Errors and Troubleshooting

A48 integration failures often occur when legacy alternate identifier fields are missing, incorrectly mapped, or unsupported by receiving applications. Some interfaces also confuse A48 with A47, which operates on the modern patient identifier list. Another risk is reversing the previous and replacement identifiers, causing the receiving system to restore an incorrect value.

Troubleshooting should focus on PID-4, MRG-2, identifier namespaces, message version, and the destination's actual patient identity records. Our HL7 interface messaging team can help trace identifier change failures across downstream systems.

PID-4 Is Missing

Modern systems may not populate PID-4 because it is retained for backward compatibility. Confirm that the source application supports the legacy field.

MRG-2 Contains an Incorrect Previous ID

If the previous alternate ID does not match the intended patient record, the destination may reject the message or update an incorrect reference.

Previous and Replacement IDs Are Reversed

An incorrect mapping can replace a valid identifier with an outdated value. Confirm that MRG-2 contains the previous ID and PID-4 contains the replacement.

Receiving System Supports Only A47

Some applications support A47 rather than A48. Review the receiving system's interface specification before translating legacy identifier changes.

Identifier Change Is Processed as a Patient Merge

A48 does not merge patient records. Using a patient merge operation can create incorrect clinical associations and serious data integrity problems.

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

HL7 defines separate events for changing patient identifiers, alternate identifiers, account numbers, and merging patient records. A48 specifically changes the legacy alternate patient ID stored in PID-4. A46 changes the legacy patient ID in PID-2. A47 is the recommended event for modern patient identifier list changes, while A49 changes an account number. A40 is a patient merge event rather than an identifier replacement.

These differences determine which fields should be mapped and which operation the receiving application should perform.

A48 vs A46: Alternate and Primary Legacy IDs

A48 changes the alternate patient ID in PID-4. A46 changes the legacy patient ID in PID-2. Both events are retained for backward compatibility.

A48 vs A47: Legacy and Modern Identifier Changes

A48 uses PID-4 and MRG-2. A47 uses PID-3 and MRG-1 and is preferred for new patient identifier list integrations.

A48 vs A49: Patient and Account Identifiers

A48 changes an alternate patient ID. A49 changes a patient account number. The two events operate at different levels of patient administration.

A48 vs A40: Identifier Change and Patient Merge

A48 replaces an alternate identifier associated with an existing patient. A40 merges patient identifier lists as part of a patient identity merge.

Best Practices for Reliable HL7 A48 Integration

Reliable A48 processing requires accurate old-to-new identifier mapping, patient identity verification, and controlled handling of legacy fields. Healthcare organizations should document which applications maintain alternate patient IDs and how those identifiers relate to the patient identifier list.

Integration teams should verify that the receiving application supports A48 and does not require A47 instead. Testing should include missing identifiers, collisions, duplicate notifications, out-of-order messages, and subordinate account or visit references.

Verify Patient Identity Before Changes

Confirm that the previous and replacement alternate IDs belong to the same patient. Do not rely solely on matching names or dates of birth.

Preserve Correct Identifier Direction

Use MRG-2 for the previous alternate ID and PID-4 for the replacement. Validate the direction before forwarding the change.

Maintain Historical Identifier References

Retain previous alternate identifiers in an appropriate audit or cross-reference mechanism so historical transactions remain traceable.

Prevent Identifier Collisions

Confirm that the replacement alternate ID is not already assigned to another patient within the same identifier namespace.

Prefer A47 for New Integrations

When supported by both applications, use A47 for patient identifier list changes rather than introducing a new A48 interface.

Frequently Asked Questions About HL7 ADT A48 Messages

Need Help With HL7 ADT A48 Integration?

Legacy alternate patient identifier changes require reliable 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 modernization of legacy healthcare interfaces.

Legacy HL7 Identifier Change Interfaces

We help healthcare organizations maintain A48 interfaces, validate old-to-new mappings, and preserve historical alternate 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 A48 to A47

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

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