HL7 ADT A44 Message: Move Account Information, Structure, Segments & Examples

The HL7 A44 message is an Admit, Discharge, Transfer (ADT) event used to communicate the movement of patient account information between patient identity contexts. Officially known as ADT A44: Move Account Information - Patient Account Number, this event supports healthcare organizations when an account has been associated with the wrong patient and must be reassigned to the correct identity. A44 is particularly important for patient accounting, revenue cycle management, and billing integrations. Accurate processing requires validating patient identifiers, account numbers, assigning authorities, and the scope of the move. This guide explains A44 message structure, examples, Mirth Connect integration, acknowledgments, troubleshooting, and best practices.

What Is an HL7 ADT A44 Message?

An HL7 ADT A44 message communicates a patient account information move. It is used when an account associated with one patient identity must be moved to another patient identity through an authorized administrative correction.

A44 operates at the patient account level, rather than performing a complete patient merge or simply changing an account number. The account being moved retains its identity while its patient association changes. Receiving applications must verify the source patient, target patient, and account relationship before processing the move. For the wider event family, see our HL7 ADT messages guide.

Purpose of the HL7 A44 Event

A44 communicates the reassignment of patient account information to the correct patient identity. Receiving applications use the notification to reconcile account ownership and associated administrative records.

When Is an ADT A44 Message Generated?

An A44 notification may be generated after a patient accounting or registration team discovers that an account was assigned to the wrong patient and authorizes a correction.

Which Healthcare Systems Receive A44 Messages?

Hospital information systems, patient accounting applications, EHRs, revenue cycle management platforms, billing systems, and integration engines may receive A44 notifications.

How A44 Supports Revenue Cycle Management

A44 helps correct patient-account relationships that can affect billing workflows, account history, and administrative reporting. Proper processing helps maintain consistency across connected applications.

Why Accurate A44 Processing Matters

An incorrect account move may associate financial or clinical-administrative information with the wrong patient. Receiving applications must validate identity relationships and protect unrelated accounts.

HL7 ADT A44 Message Structure and Segments

HL7 A44 uses the delimiter-based message format defined by HL7 Version 2. The message identifies the sending system, receiving system, administrative event, patient information, and account information involved in the move. The important distinction is between the account number being moved and the patient identity context to which the account belongs.

In HL7 v2.5, the A44 trigger event uses the ADT_A43 message structure:

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

The patient group may repeat. The standard A44 structure does not require a PV1 segment, and no subordinate visit identifiers need to be populated in the A44 notification.

MSH Segment: Message Header

MSH identifies the sender, receiver, message timestamp, trigger event, control identifier, and HL7 version. MSH-9 distinguishes A44 from other ADT events.

EVN Segment: Event Information

EVN records administrative information about the account move, including its recorded timestamp. It supports event tracking and investigation of delayed corrections.

PID Segment: Correct Target Patient

PID identifies the correct target patient. PID-3 carries the target patient identifier, and PID-18, the patient account number field, may carry the account in the target context when the implementation populates it.

MRG Segment: Incorrect Source Patient and Account

MRG communicates prior identification information. MRG-1 identifies the incorrect source patient, and MRG-3 identifies the patient account number being moved.

Optional Segments

Optional SFT and PD1 segments may appear according to the applicable specification. Account-level moves should not depend on PV1 visit information.

HL7 ADT A44 Message Example With Field Explanation

Consider a hospital where account number ACC440001 was incorrectly associated with patient MRN440001. The patient accounting team determines that the account belongs to patient MRN440099. After an authorized review, the hospital initiates an account move, and the source application generates an A44 notification for connected systems.

The receiving patient accounting application must validate the account and both patient identity contexts before changing the account association. The HL7 specification describes A44 as moving the account identified by MRG-3 from the incorrect patient identified by MRG-1 to the correct patient identified by PID-3.

Complete HL7 ADT A44 Sample Message

MSH|^~\&|REGISTRATION|HOSPITAL|BILLING|MAIN|20261022183000||ADT^A44^ADT_A43|MSG44001|P|2.5
EVN|A44|20261022182500
PID|1||MRN440099^^^HOSPITAL^MR||MARTIN^OLIVIA||19890312|F||||||||||ACC440001^^^HOSPITAL^AN
MRG|MRN440001^^^HOSPITAL^MR||ACC440001^^^HOSPITAL^AN

All patient and account information is fictional. The patient account number remains ACC440001. The operation changes its patient association rather than replacing the account number.

The account is reassigned to the correct patient identity. It is not automatically merged with another account.

Explore each segment and its key fields:

MSH Segment Explained

MSH identifies the registration application as the sender and the billing application as the destination. ADT^A44^ADT_A43 identifies the account information move event.

EVN Segment Explained

EVN records the administrative event timestamp. This information helps receiving applications track when the account correction was recorded.

PID-3: Correct Target Patient

PID-3 identifies MRN440099, the patient who should own the account after the move. The receiving application must verify this patient and preserve the complete identifier domain.

MRG-1: Incorrect Source Patient

MRG-1 identifies MRN440001, the patient previously associated with the account. The destination uses this value to locate the incorrect account association before correcting it.

MRG-3 and PID-18: The Account Being Moved

MRG-3 identifies ACC440001, the account being reassigned. PID-18 carries the same account number in the target patient context. PID-18, not PV1, is the patient account number field.

Important HL7 ADT A44 Fields and Mapping

The most important fields in an A44 message are PID-3, PID-18, MRG-1, and MRG-3. These identify the correct patient, the account involved in the move, and the incorrect source patient.

Unlike an A41 account merge or an A49 account number change, A44 preserves the account identity while changing the patient to whom the account belongs. Our HL7 parsing and data mapping team can document account-level mapping rules for your interfaces.

PID-3: Correct Target Patient

PID-3 identifies the patient who should own the account after the move. The receiving application must verify this patient and preserve the complete identifier domain.

MRG-1: Incorrect Source Patient

MRG-1 identifies the patient previously associated with the account. The destination uses this value to locate the incorrect account association before correcting it.

MRG-3: Account Being Moved

MRG-3 identifies the account being reassigned. It is the key account-level field for A44 processing and must be validated against the source patient's account records.

PID-18: Patient Account Number

PID-18 is the patient account number field. When populated for A44, its use must follow the implementation agreement, particularly where a destination expects an account identifier in the target context.

Account Identifier Assigning Authority

Account identifiers may overlap across facilities or billing systems. Complete assigning authority information should be preserved when matching the account to prevent incorrect reassignment.

How HL7 ADT A44 Account Move Workflows Operate

An A44 workflow begins when an authorized team identifies an account associated with the wrong patient. The source application verifies the account, incorrect source patient, and correct target patient, then generates an A44 notification containing the relevant identifiers.

The integration engine validates and routes the message. The receiving application removes the incorrect patient-account association and establishes the correct association, while preserving the account and its subordinate information.

Step 1: Identify the Incorrect Patient-Account Association

A registration or patient accounting team identifies an account assigned to the wrong patient. The team verifies the account and affected records before initiating the correction.

Step 2: Confirm the Correct Patient Identity

Authorized staff determine which patient should own the account. They validate patient identifiers, assigning authorities, and supporting records to prevent moving the account to another incorrect identity.

Step 3: Generate the A44 Notification

The source creates an A44 message with the correct target patient in PID-3, incorrect source patient in MRG-1, and moved account in MRG-3.

Step 4: Validate and Route the Message

An integration engine checks the event, message structure, required identifiers, and sender authorization before forwarding the notification to approved receiving systems.

Step 5: Reassign and Reconcile the Account

The destination verifies the account and patient relationships, performs the authorized move, preserves subordinate data, and records the processing result.

How to Implement HL7 ADT A44 Messages Using Mirth Connect

Mirth Connect can receive, validate, transform, and route A44 messages between registration systems, EHRs, billing applications, and revenue cycle management platforms. An A44 integration should validate the correct patient, incorrect source patient, and account being moved.

It should not directly rewrite account ownership in application databases without an authorized interface. Instead, the integration can forward a structured account move request to the destination's supported API or HL7 processing workflow. Mirth Connect development services can support these requirements.

Configure the Mirth Connect Source Connector

Create an MLLP Listener with HL7 v2.x inbound data type. Configure authorized sending systems, secure transport, acknowledgment handling, message retention, and destination routing.

Filter HL7 ADT A44 Messages

Use a JavaScript filter to identify A44 notifications.

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 === 'A44' &&
       structure === 'ADT_A43' &&
       version === '2.5';

This example targets HL7 v2.5. Production validation should also verify sender authorization, required patient groups, complete identifier domains, and interface-specific constraints.

Extract Source Patient, Target Patient, and Account

The following transformer illustrates how to extract the three essential identity elements from a single-patient-group A44 message.

function getCX(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 !== 'A44' ||
    structure !== 'ADT_A43') {
    throw new Error(
        'Unsupported HL7 event or structure'
    );
}

// Demonstration supports one patient group.
// Production implementations must handle repeats.

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

var targetPatient =
    getCX(msg['PID'], 3);

var sourcePatient =
    getCX(msg['MRG'], 1);

var movedAccount =
    getCX(msg['MRG'], 3);

if (!targetPatient || !sourcePatient ||
    !movedAccount ||
    !targetPatient.value ||
    !sourcePatient.value ||
    !movedAccount.value) {
    throw new Error(
        'Missing required A44 identifiers'
    );
}

var accountMove = {
    eventType: 'A44',
    action: 'requestAccountMove',

    sourcePatient: sourcePatient,
    targetPatient: targetPatient,

    accountToMove: movedAccount,

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

    processingStatus:
        'pending_account_validation'
};

channelMap.put(
    'accountMoveEvent',
    JSON.stringify(accountMove)
);

This is illustrative Mirth Connect E4X code. Production implementations should validate full CX components, repeated patient groups, source and target identity relationships, and account ownership.

Transform A44 Into an Account Move Request

After validation, the channel can prepare a request for the destination's authorized account management API.

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

var request = {
    operation: 'movePatientAccount',

    sourcePatient:
        event.sourcePatient,

    targetPatient:
        event.targetPatient,

    account:
        event.accountToMove,

    accountOwnershipValidationRequired:
        true,

    status: 'pending_validation',

    sourceMessageControlId:
        event.sourceMessageControlId
};

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

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

Validate Account Ownership Before Processing

Confirm that the account belongs to the source patient and that the target patient identity is correct. Reject unresolved conflicts rather than guessing the intended association.

Configure Monitoring and Exception Handling

Configure acknowledgment correlation, controlled retries, duplicate detection, audit logging, and monitored exception queues for failed account moves.

HL7 ADT A44 ACK Message Examples and Error Handling

HL7 acknowledgments allow the sending application to determine whether an A44 message was accepted or rejected under the configured processing agreement. A typical acknowledgment includes MSH and MSA segments, with ERR providing diagnostic information when needed.

In original acknowledgment mode, AA indicates application acceptance, AE indicates an application error, and AR indicates rejection. An AA acknowledgment should not be interpreted as proof that every downstream billing or clinical application has completed the account reassignment.

Successful A44 ACK: AA

MSH|^~\&|BILLING|MAIN|REGISTRATION|HOSPITAL|20261022183001||ACK^A44^ACK|ACK44001|P|2.5
MSA|AA|MSG44001

Application Error ACK: AE

MSH|^~\&|BILLING|MAIN|REGISTRATION|HOSPITAL|20261022183002||ACK^A44^ACK|ACK44002|P|2.5
MSA|AE|MSG44001
ERR|||204^Unknown Key Identifier^HL70357|E

This illustrative error may occur when the destination cannot resolve the account or patient identity.

Application Rejection ACK: AR

MSH|^~\&|BILLING|MAIN|REGISTRATION|HOSPITAL|20261022183003||ACK^A44^ACK|ACK44003|P|2.5
MSA|AR|MSG44001

Correlate ACK Responses With Original Messages

MSA-2 should reference the original message's MSH-10 identifier. Monitoring should associate the response with the account, source patient, target patient, and processing outcome.

Handle Retries Without Duplicate Account Moves

Before resending an unacknowledged A44 message, determine whether the destination already processed the move. Repeated delivery must not create conflicting account ownership relationships.

Common HL7 ADT A44 Integration Errors and Troubleshooting

A44 integration errors commonly involve incorrect patient identifiers, missing account numbers, account ownership conflicts, and unsupported destination workflows. Some receiving applications incorrectly treat A44 as an account merge or account number change. Others fail to reconcile subordinate visit and billing information after moving the account.

Troubleshooting should focus on the relationship between the account and its source and target patients, along with the receiving application's account management rules.

MRG-3 Account Number Cannot Be Found

The destination may not recognize the account identified in MRG-3. Verify the account number, assigning authority, and source patient relationship before retrying.

Source and Target Patients Are Reversed

If PID-3 and MRG-1 are interpreted incorrectly, the account may remain associated with the wrong patient or move in the wrong direction.

Account Number Mapped to the Wrong Field

PID-18 is the patient account number field. Placing the account in PV1 or in a neighbouring PID field, such as PID-19 (SSN), causes the destination to miss or misread it. Validate field positions with a version-aware parser.

A44 Is Processed as an Account Merge

A44 moves an account between patient identities. A41 merges account identifiers. Treating the events identically can cause incorrect financial record associations.

Subordinate Billing Records Are Not Reconciled

Charges, payments, account-level adjustments, and visit associations may require reconciliation after the account move. Verify the destination's supported processing behavior.

Duplicate or Delayed A44 Messages Arrive

An older A44 message may arrive after a later correction. Use event history and idempotent processing to prevent stale updates from reversing valid account ownership changes.

HL7 ADT A44 vs A41, A43, A45, and A49

HL7 Version 2 distinguishes account moves from account merges, patient information moves, visit moves, and account number changes. These events have different meanings and should not be processed interchangeably. Related pages include A41 and A43.

A44 vs A41: Move and Merge

A44 moves an account between patient identities. A41 merges account identifiers. A move preserves the account identity while changing its patient association.

A44 vs A43: Account and Patient Levels

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

A44 vs A45: Account and Visit Levels

A44 moves account information between patient identities. A45 moves visit information between account contexts. Each requires different identifier validation and reconciliation.

A44 vs A49: Move and Account Number Change

A44 changes which patient owns an account. A49 changes an account number. The account's identifier and its patient association are separate concepts.

Best Practices for Reliable HL7 A44 Integration

Account moves require careful validation because they affect patient accounting and potentially related clinical-administrative records. The authoritative system should verify the account and both patient identities before distributing an A44 notification.

Receiving applications must preserve identifier domains, prevent duplicate processing, and reconcile subordinate records. Integration teams should test account moves involving existing charges, payments, active visits, historical encounters, and partially synchronized applications.

Require Authorized Account Corrections

Only trusted registration or patient accounting workflows should initiate A44 moves. Do not infer account ownership solely from demographic similarities.

Validate Source and Target Patient Identities

Verify PID-3 and MRG-1 using complete identifier domains. Confirm that the account identified in MRG-3 belongs to the source patient before reassignment.

Preserve Account and Financial History

Maintain account identifiers, transaction history, and audit information. The account move should not silently discard financial or administrative records.

Implement Idempotency and Audit Logging

Track message control identifiers, account numbers, source and target patients, timestamps, and processing results. Prevent repeated notifications from creating inconsistent ownership relationships.

Verify Downstream Revenue Cycle Consistency

After processing, confirm that billing, patient accounting, and connected applications reflect the correct patient-account relationship and preserve required subordinate information.

Frequently Asked Questions About HL7 ADT A44 Messages

Need Help With HL7 ADT A44 Integration?

Patient account moves require reliable communication between registration systems, EHRs, patient accounting platforms, and revenue cycle management applications. Taction Software supports HL7 interface development, Mirth Connect implementation, account identifier mapping, and healthcare interoperability.

HL7 Patient Account Move Interfaces

We develop HL7 A44 interfaces based on source and destination requirements, including patient identity mapping, account validation, and controlled account reassignment.

Mirth Connect Development and Integration

Our engineers configure Mirth Connect channels for account move notifications, including JavaScript transformations, secure routing, acknowledgment handling, and exception management.

EHR and Revenue Cycle Integration

We support integration between EHRs, registration applications, billing systems, and revenue cycle platforms using approved patient accounting workflows.

Production Monitoring and Troubleshooting

We help investigate failed account moves, incorrect patient associations, identifier mismatches, acknowledgment errors, and downstream billing inconsistencies.

Need help with HL7 patient account integration? Explore our HL7 interface messaging services and EHR and EMR integration services to discuss your requirements.