HL7 ADT A43 Message: Move Patient Information, Structure, Segments & Examples

The HL7 A43 message is an Admit, Discharge, Transfer (ADT) event used to move patient information from one patient identifier context to another. Officially known as ADT A43: Move Patient Information, this event supports healthcare organizations when information has been associated with an incorrect patient identifier and must be reassigned through an authorized identity management workflow. A43 messages use PID and MRG segments to identify the identifier being moved. Unlike a patient merge, a move does not necessarily combine the two patient identities. This guide explains A43 message structure, examples, Mirth Connect integration, acknowledgments, troubleshooting, and best practices.

What Is an HL7 ADT A43 Message?

An HL7 ADT A43 message communicates the movement of patient information between patient identifier contexts. The event is part of the HL7 Version 2 patient administration framework. It is particularly relevant when information must be reassociated with a different patient identity without treating the operation as a complete patient merge.

For example, a registration error may result in an identifier and its records being associated with the wrong patient. An authorized correction workflow can move that identifier, with its subordinate information, to the appropriate patient identity. For the wider event family, see our HL7 ADT messages guide.

Purpose of the HL7 A43 Event

A43 communicates an authorized movement of patient information between identifier contexts. Receiving applications use the notification to update supported identity associations while maintaining record integrity.

When Is an ADT A43 Message Generated?

An A43 notification may be generated after an authorized identity management process determines that patient information must be moved from an incorrect patient identity to the correct one.

Which Healthcare Systems Receive A43 Messages?

EHRs, enterprise master patient index platforms, registration applications, clinical repositories, and other systems maintaining patient information may receive A43 notifications.

How A43 Supports Patient Identity Correction

A43 helps connected applications correct patient information associations without necessarily merging two distinct patient identities. This distinction protects the integrity of unrelated clinical records.

Why Accurate A43 Processing Matters

Moving patient information incorrectly can associate clinical data with the wrong person. Receiving systems must validate source and target identities, record scope, and authorization before applying changes.

HL7 ADT A43 Message Structure and Segments

HL7 A43 uses the segment-based format defined by HL7 Version 2. The message identifies the administrative event, the patient identifier being moved, and its prior identifier context. In HL7 v2.5, the ADT_A43 structure is:

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

The patient group can repeat. The exact identifiers needed to distinguish source and target identity contexts must be specified and tested with the implementation partner. The exact information being moved and the behavior of the receiving system must be defined by the implementation profile and identity management workflow.

MSH Segment: Message Header

MSH identifies the sending and receiving applications, timestamp, event type, control identifier, and HL7 version. MSH-9 identifies the A43 event.

EVN Segment: Event Information

EVN provides administrative information about the move event, including the recorded timestamp. It supports audit tracking and investigation of identity corrections.

PID Segment: Patient Identification

PID carries patient identification for the patient group. PID-3 contains the patient identifier list, including the identifier being moved.

MRG Segment: Prior Patient Identification

MRG contains prior patient identifier information. MRG-1 identifies the moved identifier in the context it is leaving.

Optional Patient and Visit Information

Optional SFT and PD1 segments may be included according to the applicable HL7 version and interface profile. Receiving applications must validate the message structure and scope of the move.

HL7 ADT A43 Message Example With Field Explanation

Consider a hospital where medical record number MRN430001, and the encounters and results filed under it, were mistakenly associated with the wrong patient. An authorized patient identity management team reviews the error and determines that MRN430001 and its subordinate information should be moved to the correct patient identity.

The registration system generates an A43 notification. The receiving application must verify the source and target identities and determine which information should be reassociated.

Important Implementation Detail: The Identifier Being Moved Must Match

The standard A43 event has a specific rule that is easy to miss: the identifier being moved appears with the same value in PID-3 and MRG-1. The incorrect source patient identity and the correct target patient identity are separate from that identifier. Any subordinate records associated with the moved identifier follow it to the correct target identity. An example that places different identifiers in PID-3 and MRG-1 is not a standard A43 move; it looks more like an A47 identifier change.

Complete HL7 ADT A43 Sample Message

MSH|^~\&|REGISTRATION|HOSPITAL|EHR|MAIN|20261022180000||ADT^A43^ADT_A43|MSG43001|P|2.5
EVN|A43|20261022175500
PID|1||MRN430001^^^HOSPITAL^MR||MARTIN^OLIVIA||19890312|F
MRG|MRN430001^^^HOSPITAL^MR

All patient information is fictional. The moved identifier is MRN430001 in both PID-3 and MRG-1.

The source and target patient contexts are resolved according to the sending and receiving systems' identity-management agreement. The actual scope of information being moved must be established by the applicable implementation profile and authorized workflow.

Explore each segment and its key fields:

MSH Segment Explained

MSH identifies REGISTRATION as the sending application and EHR as the destination. ADT^A43^ADT_A43 identifies the patient information move event, while MSH-10 supports message tracking.

EVN Segment Explained

EVN records the administrative event timestamp. Receiving applications can use this information for audit tracking and investigation of delayed corrections.

PID-3: Moved Identifier

PID-3 contains MRN430001, the identifier being moved. The destination must verify the identifier and assigning authority before moving any information.

MRG-1: Moved Identifier in Its Prior Context

MRG-1 also contains MRN430001. The receiving application uses it, together with the agreed identity-resolution rules, to locate the incorrect source patient context and the information affected by the move.

Patient Demographic Fields

PID-5, PID-7, and PID-8 provide supporting demographic context. These fields should not independently authorize moving clinical information between patient identities.

Important HL7 ADT A43 Fields and Mapping

An A43 integration must distinguish three concepts: the identifier being moved, the incorrect patient identity currently associated with it, and the correct target patient identity. PID-3 and MRG-1 are essential, but they must not be treated as a simple old-identifier-to-new-identifier replacement.

This distinction separates A43 from an A47 identifier change and an A40 patient merge. Our HL7 parsing and data mapping team can document identity-resolution rules for your interfaces.

PID-3: Patient Identifier List

PID-3 carries patient identifier information. In standard A43 move semantics, the identifier being moved must correspond to the identifier identified in MRG-1.

MRG-1: Prior Patient Identifier List

MRG-1 identifies the patient identifier being moved from the incorrect source patient context. The destination must resolve that relationship using its agreed identity-management model.

Source and Target Patient Identity Contexts

The incorrect source patient and correct target patient are different identities. Their representation and resolution must be agreed upon rather than inferred from a simplistic PID-to-MRG comparison.

Identifier Assigning Authorities

The identifier value alone may not be unique across healthcare organizations. Validate the complete identifier, assigning authority, and identifier type before processing a move.

Subordinate Clinical Records

Records subordinate to the moved patient identifier are included in the move semantics. The receiving system must preserve correct clinical associations and avoid changing unrelated patient records.

How HL7 ADT A43 Patient Information Move Workflows Operate

An A43 workflow begins when an authorized identity management team identifies a patient identifier associated with the wrong patient identity. The source determines the correct target identity, approves moving the identifier, and generates an A43 notification using the supported implementation profile.

The destination validates the moved identifier and both identity contexts, then transfers the associated subordinate information according to its supported move workflow. This operation must not be treated as an ordinary patient merge or identifier replacement.

Step 1: Identify the Incorrect Association

An identity management process identifies a patient identifier currently associated with the wrong patient identity. The team verifies the error using approved patient identity evidence.

Step 2: Determine the Correct Target Identity

Authorized staff identify the correct patient identity that should own the moved identifier. They also establish the scope of subordinate records affected by the correction.

Step 3: Generate the A43 Notification

The source generates an A43 message using the agreed representation of the moved identifier and patient identity contexts.

Step 4: Validate and Route the Message

The integration engine checks the event type, structure, identifiers, assigning authorities, and sender authorization before forwarding the notification.

Step 5: Move and Reconcile Patient Information

The receiving system validates the move and updates its identity associations and subordinate records. It preserves audit history and acknowledges the processing outcome.

How to Implement HL7 ADT A43 Messages Using Mirth Connect

Mirth Connect can receive, validate, transform, and route HL7 A43 notifications between registration applications, EHRs, and enterprise master patient index systems. Because A43 changes the patient identity association of an identifier and its subordinate records, the integration should not directly update clinical database tables.

Instead, it should validate the message, preserve the complete identifier context, and forward a controlled move request to the authoritative identity management system. The receiving application must verify the source and target patient identities before applying the change. Mirth Connect development services can support these requirements.

Configure the Mirth Connect Source Connector

Create an MLLP Listener channel with HL7 v2.x inbound data type. Configure approved sending applications, encrypted network transport, message acknowledgment behavior, and appropriate retention policies.

Filter HL7 ADT A43 Messages

Use a JavaScript filter to identify the correct event and message structure.

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

var event =
    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 type === 'ADT' &&
       event === 'A43' &&
       structure === 'ADT_A43' &&
       version === '2.5';

This filter targets HL7 v2.5. Production validation should also verify the sender, patient group structure, required fields, and any agreed local constraints.

Extract the Identifier Being Moved

The following example extracts identifier values from the first PID/MRG patient group. It verifies that the moved identifier appears in both fields, but leaves source and target identity resolution to the destination.

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

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

    var cx = field[0];
    var authority = cx[fieldName + '.4'];

    return {
        value:
            cx[fieldName + '.1'].toString().trim(),

        assigningAuthority: {
            namespaceId:
                authority[fieldName + '.4.1']
                    .toString().trim(),

            universalId:
                authority[fieldName + '.4.2']
                    .toString().trim(),

            universalIdType:
                authority[fieldName + '.4.3']
                    .toString().trim()
        },

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

var msh = msg['MSH'];

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

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

if (event !== 'A43' ||
    structure !== 'ADT_A43') {
    throw new Error('Unexpected HL7 event');
}

if (msg['PID'].length() !== 1 ||
    msg['MRG'].length() !== 1) {
    throw new Error(
        'Example supports one patient group only'
    );
}

var pidIdentifier =
    readIdentifier(msg['PID'], 3);

var mrgIdentifier =
    readIdentifier(msg['MRG'], 1);

if (!pidIdentifier || !mrgIdentifier ||
    !pidIdentifier.value ||
    !mrgIdentifier.value) {
    throw new Error(
        'Missing moved patient identifier'
    );
}

if (pidIdentifier.value !==
    mrgIdentifier.value) {
    throw new Error(
        'A43 moved identifier mismatch'
    );
}

var moveEvent = {
    eventType: 'A43',

    movedIdentifier: pidIdentifier,

    previousIdentifierContext:
        mrgIdentifier,

    sourceMessageControlId:
        msh['MSH.10']['MSH.10.1'].toString(),

    processingStatus:
        'pending_identity_resolution'
};

channelMap.put(
    'patientMoveEvent',
    JSON.stringify(moveEvent)
);

This is a deliberately limited demonstration. It does not resolve the source and target identities, support multiple patient groups, or compare all identifier repetitions. Production code must validate complete identifier equivalence, including assigning authorities, and implement the exact profile.

Transform A43 Into a Controlled Move Request

After validation, build a request for an authorized patient identity management service. The request should preserve the moved identifier and require authoritative resolution of the source and target identities.

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

var request = {
    operation: 'requestPatientIdentifierMove',

    movedIdentifier:
        event.movedIdentifier,

    previousIdentifierContext:
        event.previousIdentifierContext,

    identityResolutionRequired: true,

    subordinateRecordReviewRequired: true,

    status: 'pending_validation',

    sourceMessageControlId:
        event.sourceMessageControlId
};

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

This JSON is illustrative and is not a standardized HL7 API. The destination must resolve the correct source and target identities before moving records.

Validate the Move Before Processing

Confirm that the moved identifier belongs to the incorrect source patient identity and is authorized to be reassigned to the correct target patient. Reject unresolved conflicts.

Configure Safe Routing and Monitoring

Use an approved EHR or master patient index API. Configure acknowledgment handling, duplicate detection, audit logs, exception queues, and monitoring of downstream clinical record associations.

HL7 ADT A43 ACK Message Examples and Error Handling

HL7 acknowledgments communicate whether an A43 message was accepted or rejected under the configured processing agreement. An acknowledgment generally contains MSH and MSA segments. ERR can provide diagnostic details 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 information moves may require additional downstream processing, message acceptance does not necessarily confirm that every clinical record association has been updated.

Successful A43 ACK: AA

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022180001||ACK^A43^ACK|ACK43001|P|2.5
MSA|AA|MSG43001

Application Error ACK: AE

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022180002||ACK^A43^ACK|ACK43002|P|2.5
MSA|AE|MSG43001
ERR|||204^Unknown Key Identifier^HL70357|E

The error is illustrative. Actual ERR values must follow the destination's HL7 version and interface profile.

Application Rejection ACK: AR

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022180003||ACK^A43^ACK|ACK43003|P|2.5
MSA|AR|MSG43001

Correlate Acknowledgments With Move Events

MSA-2 should match the original MSH-10 message control identifier. Monitoring should associate the response with the moved identifier and processing outcome.

Handle Failed Acknowledgments and Retries

Before resending an unacknowledged A43 message, determine whether the destination already processed the move. Repeated processing must not produce inconsistent identity associations.

Common HL7 ADT A43 Integration Errors and Troubleshooting

A43 integration errors can arise when applications interpret the event as a patient merge or identifier replacement. Other failures involve incomplete identifier domains, unresolved source and target identities, duplicate notifications, or incorrect subordinate record handling.

The most important troubleshooting question is whether the destination understands which identifier is being moved and which patient identity should own it afterward.

PID-3 and MRG-1 Are Interpreted as Different Identifiers

In the standard A43 move relationship, the moved identifier appears in both PID-3 and MRG-1. Treating the fields as a simple old-to-new replacement can cause incorrect processing.

Source and Target Identities Cannot Be Resolved

The destination may be unable to determine the incorrect source patient or correct target patient. Route the event for authorized identity reconciliation rather than guessing.

Subordinate Records Remain With the Wrong Patient

Clinical records associated with the moved identifier may not be reassigned consistently. Validate the destination's handling of encounters, accounts, and other subordinate information.

A43 Is Processed as A40

A40 is a patient identifier merge event, while A43 moves a patient identifier and its associated information between identity contexts. Treating them identically can produce incorrect patient associations.

Duplicate or Delayed A43 Messages Arrive

A delayed notification may conflict with later identity changes. Use event history and idempotent processing to prevent stale updates from reversing valid corrections.

HL7 ADT A43 vs A40, A44, A45, and A47

HL7 Version 2 provides separate events for patient merges, patient information moves, account moves, visit moves, and identifier changes. The correct event depends on the administrative action and the level of information being affected. A43 operates at the patient identifier list level. A44 operates at the patient account number level, and A45 at the visit number level. A40 merges patient identifier lists, while A47 changes a patient identifier list.

A43 vs A40: Move and Merge

A43 moves patient information between identity contexts, while A40 merges patient identifier lists. A move should not automatically be interpreted as combining the two patient identities.

A43 vs A44: Patient and Account Levels

A43 operates at the patient identifier list level. A44 operates at the patient account number level. The distinction determines which subordinate information is affected.

A43 vs A45: Patient and Visit Levels

A43 moves information at the patient identifier list level. A45 moves information at the visit number level. Each requires different identity and record scope validation.

A43 vs A47: Move and Identifier Change

A43 changes the patient identity context associated with an identifier. A47 changes a patient identifier list. The message fields may overlap, but their administrative meanings differ.

Best Practices for Reliable HL7 A43 Integration

Patient information moves require careful governance because they can affect clinical records across multiple systems. The authoritative identity management application should verify the source and target identities and approve the move.

Receiving applications must preserve identifier domains, maintain audit history, and validate subordinate record associations. Integration teams should test moves involving active encounters, historical clinical documents, duplicate notifications, and partially synchronized systems.

Require Authorized Identity Review

Only approved patient identity management workflows should initiate A43 moves. Do not automatically reassign clinical records based solely on similar patient demographics.

Preserve Complete Identifier Context

Retain identifier values, assigning authorities, and identifier types. These components are essential for distinguishing patient identities across organizations.

Validate Subordinate Record Movement

Confirm that all records associated with the moved identifier are handled according to the authorized move scope. Protect unrelated patient records from modification.

Implement Idempotency and Audit Logging

Track message control identifiers, moved identifiers, source and target identity resolution, timestamps, and processing results. Prevent repeated messages from creating conflicting associations.

Verify Downstream Patient Record Accuracy

After processing, verify that encounters, laboratory results, medications, imaging records, and documents remain associated with the correct patient identity.

Frequently Asked Questions About HL7 ADT A43 Messages

Need Help With HL7 ADT A43 Integration?

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

HL7 Patient Information Move Interfaces

We develop HL7 A43 interfaces based on source and destination requirements, including identifier mapping, identity validation, and controlled patient information reassignment.

Mirth Connect Development and Integration

Our engineers configure Mirth Connect channels for patient information move notifications, including JavaScript transformations, secure routing, acknowledgments, and exception monitoring.

EHR and Master Patient Index Integration

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

Production Monitoring and Troubleshooting

We help investigate failed moves, identifier mismatches, acknowledgment errors, duplicate notifications, and downstream clinical record inconsistencies.

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