HL7 ADT A45 Message: Move Visit Information - Visit Number, Structure, Segments & Examples

The HL7 ADT A45 message is a patient administration event used to move visit information from an incorrect patient account number to the correct account number. Officially called ADT A45: Move Visit Information - Visit Number, it helps healthcare organizations correct which account owns an encounter without treating the operation as a patient merge or an account merge.

An A45 message identifies the correct target account in PID-18, the incorrect source account in MRG-3, and the visit being moved in MRG-5. It is particularly relevant when registration errors attach an encounter to the wrong account. This guide explains A45 message structure, PID, PV1, and MRG fields, sample messages, Mirth Connect integration, acknowledgments, troubleshooting, and implementation best practices.

What Is an HL7 ADT A45 Message?

An HL7 ADT A45 message communicates the movement of visit information from one patient account to another. This event is used when a visit has been associated with the wrong account and must be reassigned to the correct account. For example, a hospital may discover that an emergency department encounter was registered under the wrong account number.

After the registration team verifies the error, the encounter can be moved to the correct account using the authorized workflow. The source system generates an A45 notification so connected applications can update their visit-to-account associations. Unlike a merge, A45 does not combine two patient identities or two accounts. See the HL7 ADT messages guide for the full event family.

Purpose of the HL7 A45 Event

A45 communicates a correction to the account association of a visit. It helps downstream applications identify the correct account for encounter-level information.

When Is an ADT A45 Message Generated?

An A45 message may be generated when a hospital discovers that a visit was registered under the wrong account and an authorized correction moves it to the correct account.

Which Healthcare Systems Receive A45 Messages?

EHRs, laboratory systems, radiology applications, patient accounting platforms, clinical documentation systems, and integration engines may receive A45 messages when they maintain encounter-to-account relationships.

How A45 Differs From a Merge

A45 moves visit information between accounts. It does not consolidate two patient identities into one surviving patient, which is the purpose of a patient merge event, and it does not merge two accounts.

Why Accurate A45 Processing Matters

Moving a visit to the wrong account can misattribute orders, results, documentation, and charges. Receiving applications must validate the correct account, previous account, and visit before applying the change.

HL7 ADT A45 Message Structure and Segments

In HL7 Version 2.5, A45 uses the ADT_A45 message structure. The message contains MSH and EVN segments, a single PID segment with optional PD1, and one or more MRG/PV1 groups. PID identifies the patient and, in PID-18, the correct target account. Each MRG identifies the incorrect source account in MRG-3 and the prior visit number in MRG-5, and its paired PV1 supplies the visit number in PV1-19.

Because the MRG/PV1 group repeats, one message can represent multiple visit moves. The message should not be interpreted as a merge of the source and target accounts or of two patient records.

HL7 ADT A45 Message Structure

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

The PID segment occurs once before the repeating MRG/PV1 groups. This distinction is important when implementing the message in Mirth Connect. The exact repetition requirements must be validated against the HL7 version and receiving application's interface specification.

MSH Segment: Message Header

MSH identifies the sending and receiving systems, message timestamp, control identifier, and HL7 version. MSH-9 identifies the event as ADT^A45^ADT_A45.

EVN Segment: Event Information

EVN records administrative details about the visit move, including the event's recorded timestamp. It supports audit history and troubleshooting.

PID Segment: Patient and Target Account

PID identifies the patient. PID-18 identifies the correct target account that should own the visit after the correction.

MRG Segment: Source Account and Prior Visit

MRG-3 identifies the incorrect source account currently associated with the visit, and MRG-5 identifies the prior visit number being moved.

PV1 Segment: Visit Information

PV1 contains encounter information, including PV1-19, the visit number. The destination uses this information together with MRG-5 to identify the visit being reassigned.

HL7 ADT A45 Message Example With Field Explanation

Consider an emergency department encounter for patient MRN450001 that was incorrectly associated with account ACC450099. The correct account is ACC450001, and the visit number remains VIS450001. After verifying the registration error, the hospital's patient administration team authorizes the visit to be moved to the correct account. The source application generates an A45 notification, allowing connected applications to update their visit-to-account associations.

HL7 ADT A45 Sample Message

MSH|^~\&|REGISTRATION|HOSPITAL|EHR|MAIN|20261022170000||ADT^A45^ADT_A45|MSG45001|P|2.5
EVN|A45|20261022170000
PID|1||MRN450001^^^HOSPITAL^MR||WILSON^EMILY||19880215|F||||||||||ACC450001
MRG|||ACC450099^^^HOSPITAL^AN||VIS450001^^^HOSPITAL^VN
PV1|1|E|||||||||||||||||VIS450001^^^HOSPITAL^VN

All patient information is fictional. In this example, the visit is moved from the incorrect account to the correct account. The patient identifier remains unchanged. Production systems should validate identifier domains and exact field placement before processing.

Move visit VIS450001 to the correct account.

Explore each segment and its key fields:

MSH-9: Message Type and Trigger Event

ADT^A45^ADT_A45 identifies the visit move event. Receiving systems should validate the event and message structure before processing.

PID-3: Patient Identifier

PID-3 contains MRN450001. The patient identity does not change; only the account that owns the visit changes.

Why Move Direction Matters

Reversing PID-18 and MRG-3 would move the visit back to the incorrect account. The destination must validate source and target accounts before applying any change.

Important HL7 A45 Fields and Mapping

Under the standard HL7 v2.5 definition, A45 moves visit information from an incorrect patient account number to the correct patient account number. It is not, by itself, an instruction to move an encounter between two different patient identities. The defining fields are:

• PID-18: Correct target patient account number.
• MRG-3: Incorrect source patient account number.
• MRG-5: Prior visit number being moved.
• PV1-19: Visit number, which may identify a newly assigned visit identifier when supported by the implementation agreement.

Our HL7 parsing and data mapping team can document account and visit identifier mapping across every receiving system.

PID-18: Correct Target Account

PID-18 identifies the account that should own the visit after the correction. The destination must confirm that the account belongs to the intended patient.

MRG-3: Incorrect Source Account

MRG-3 identifies the account currently associated with the visit. It tells the receiving application where the visit information must be moved from.

MRG-5: Prior Visit Number

MRG-5 identifies the visit being moved. The destination should use this value with the source account identifier to locate the correct encounter.

PV1-19: Visit Number

PV1-19 can contain the target visit identifier. If the visit number changes during the move, that behavior must be explicitly agreed upon by the sending and receiving applications.

How HL7 ADT A45 Account-to-Account Visit Moves Work

An A45 workflow begins when the registration system identifies a visit attached to the wrong account. The correction must be approved and the correct account verified.

The integration engine receives the A45 message and validates the patient identifier, source account, target account, and affected visit number. The receiving application then moves the visit using its supported encounter management functionality.

Step 1: Identify the Incorrect Account

The registration team confirms that the visit belongs to a different account than the one currently associated with it.

Step 2: Confirm the Correct Target Account

The source application identifies the account that should own the visit and verifies that the correction is authorized.

Step 3: Generate the A45 Message

The source system generates an A45 message with the correct account in PID-18 and the previous account in MRG-3.

Step 4: Validate the Visit Identifier

The integration engine verifies MRG-5 and PV1-19, including assigning authorities and any agreed visit-number changes.

Step 5: Reconcile Downstream Records

Receiving systems update the visit-to-account relationship and reconcile associated clinical, administrative, and financial records.

How to Implement HL7 ADT A45 Using Mirth Connect

Mirth Connect can receive, validate, transform, and route A45 messages between hospital registration systems, EHRs, patient accounting platforms, and other applications. The most important implementation requirement is to preserve the correct account-to-account move direction. The channel must not interpret A45 as a patient identity merge or an account merge.

Production channels should also support repeating MRG/PV1 groups, validate complete account and visit identifiers, and prevent duplicate processing.

Configure the Source Connector

Create a channel with an MLLP Listener and HL7 v2.x inbound data type. Configure secure transport, trusted sending applications, acknowledgments, and appropriate message retention policies.

Filter A45 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 === 'A45' &&
       structure === 'ADT_A45' &&
       version === '2.5';

Extract Source and Target Account Identifiers

The following JavaScript illustrates extraction for a single MRG/PV1 pair in a normalized Mirth Connect HL7 XML representation.

function value(segment, field, component) {
    return segment[field][field + '.' + component]
        .toString().trim();
}

var targetAccount =
    value(msg['PID'], 'PID.18', 1);

var sourceAccount =
    value(msg['MRG'][0], 'MRG.3', 1);

var sourceVisit =
    value(msg['MRG'][0], 'MRG.5', 1);

var targetVisit =
    value(msg['PV1'][0], 'PV1.19', 1);

var patientId =
    value(msg['PID'], 'PID.3', 1);

if (!targetAccount ||
    !sourceAccount ||
    !sourceVisit ||
    !patientId) {
    throw new Error(
        'Missing required A45 identifiers'
    );
}

if (sourceAccount === targetAccount) {
    throw new Error(
        'Source and target accounts are identical'
    );
}

var moveRequest = {
    eventType: 'A45',
    operation: 'validateVisitAccountMove',
    patientId: patientId,
    sourceAccount: sourceAccount,
    targetAccount: targetAccount,
    sourceVisit: sourceVisit,
    targetVisit: targetVisit,
    status: 'pending_validation'
};

channelMap.put(
    'visitAccountMove',
    JSON.stringify(moveRequest)
);

This is illustrative code, not a production-ready transformer. Actual segment grouping, XML access, complete CX identifiers, and field repetitions must be tested against the channel's configured HL7 parser and destination interface.

Transform A45 Into a Destination Request

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

var payload = {
    action: 'validateVisitAccountMove',
    patientIdentifier: event.patientId,
    fromAccount: event.sourceAccount,
    toAccount: event.targetAccount,
    previousVisit: event.sourceVisit,
    resultingVisit: event.targetVisit,
    approvalRequired: true
};

channelMap.put(
    'destinationPayload',
    JSON.stringify(payload)
);

The JSON represents a hypothetical destination application request. It is not a standard HL7 or FHIR operation.

Handle Repeating MRG and PV1 Groups

The A45 message structure permits multiple MRG/PV1 pairs. Each pair must remain associated with its corresponding visit move. Do not independently collect all MRG segments and all PV1 segments without preserving their order and grouping.

Validate the Account Relationship

Before processing, verify that the source account, target account, and visit identifiers exist and that the proposed correction is authorized. Ambiguous cases should be quarantined for review.

HL7 ADT A45 ACK Message Examples

HL7 acknowledgments allow the sending application to determine whether the receiver accepted or rejected an A45 message. In original acknowledgment mode, AA indicates application acceptance, AE indicates an application error, and AR indicates rejection. An accepted message does not necessarily establish that all downstream records have been reconciled.

Successful ACK: AA

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022170001||ACK^A45^ACK|ACK45001|P|2.5
MSA|AA|MSG45001

Application Error: AE

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022170002||ACK^A45^ACK|ACK45002|P|2.5
MSA|AE|MSG45001
ERR|||204^Unknown Key Identifier^HL70357|E

Application Rejection: AR

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022170003||ACK^A45^ACK|ACK45003|P|2.5
MSA|AR|MSG45001

Correlate ACKs With the Original Message

MSA-2 should match the original message's MSH-10 value. This allows the sender to identify which A45 notification received the acknowledgment.

Prevent Duplicate Visit Moves

Before retrying a message, determine whether the destination has already moved the visit. Repeated A45 notifications must not create conflicting account relationships.

Common HL7 ADT A45 Integration Errors and Troubleshooting

A45 processing failures frequently involve incorrect account identifiers, missing visit numbers, unsupported message structures, or mismatched source and target relationships. Another significant issue is confusing the A45 account-to-account move with a patient-to-patient move.

Troubleshooting should focus on PID-18, MRG-3, MRG-5, PV1-19, and the destination's actual account and visit relationships. Our HL7 interface messaging team can help trace move failures across downstream systems.

Incorrect Source and Target Accounts

The destination may reverse PID-18 and MRG-3. Verify that PID-18 represents the correct target account and MRG-3 represents the incorrect source account.

Missing MRG-5 Visit Number

Without the prior visit number, the destination may not reliably identify which visit should move. Validate required identifiers before forwarding the message.

Unsupported Visit Identifier Changes

A receiving system may support account reassignment but not changing the visit number simultaneously. Agree on the use of PV1-19 and PV1-50 before deployment.

Incomplete Downstream Reconciliation

The visit may move successfully while orders, results, or charges remain associated with the previous account. Monitor dependent applications and reconcile affected records.

Incorrect Repeating Group Processing

A channel may process only the first MRG/PV1 pair or incorrectly associate visit identifiers across groups. Validate grouping and repetition with multiple test cases.

HL7 ADT A45 vs A42, A43, A44, and A50

These HL7 events perform different operations on patient, account, and visit identifiers. Choosing the wrong event, or mapping one event with another's field rules, can attach records to the wrong patient, account, or encounter.

A45 vs A42: Move and Merge

A42 consolidates two visit records into a surviving visit. A45 moves visit information from an incorrect account to the correct account. The two events have different effects on encounter relationships.

A45 vs A43: Visit and Patient Information

A43 moves patient-level information between patient identifiers. A45 operates at the visit level and identifies the source and target accounts involved in the move.

A45 vs A44: Visit and Account Information

A44 moves account information between patient identifiers. A45 moves visit information between account identifiers. These events represent different levels of the administrative hierarchy.

A45 vs A50: Move and Identifier Change

A45 changes the account association of a visit. A50 changes a visit identifier. A45 can also communicate a new visit identifier when supported by the implementation agreement.

Best Practices for Reliable HL7 A45 Integration

An A45 interface should be designed around accurate account ownership, encounter identification, and controlled record reconciliation. The source application must be authorized to initiate corrections, and the receiving system must validate the requested move before changing visit relationships.

Testing should include duplicate messages, incorrect account identifiers, changed visit numbers, and multiple MRG/PV1 groups.

Validate Account and Visit Identifiers

Verify the complete identifiers and assigning authorities for PID-18, MRG-3, MRG-5, and PV1-19. Do not rely solely on short identifier strings.

Preserve Patient Identity

A45 is not a patient merge. Do not combine patient records or change patient identity relationships solely because an A45 message was received.

Support Repeating Visit Groups

Preserve each MRG/PV1 pairing when multiple visits are moved. Validate the destination's ability to process every group correctly.

Maintain Historical Account Associations

Retain the previous account and visit relationships in an appropriate audit mechanism. Historical transactions must remain traceable after the correction.

Monitor Clinical and Financial Reconciliation

Verify that affected orders, results, documentation, and charges remain associated with the intended visit and account after the move.

Frequently Asked Questions About HL7 ADT A45

Need Help With HL7 ADT A45 Integration?

Correcting visit-to-account relationships requires reliable coordination between EHRs, registration systems, patient accounting platforms, and downstream clinical applications. Taction Software supports HL7 interface development, Mirth Connect implementation, encounter management integration, and healthcare interoperability.

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