HL7 ADT A35 Message: Merge Patient Information, Account Number Only, Structure, Segments & Examples

The HL7 A35 message is a legacy Admit, Discharge, Transfer (ADT) event used to communicate the merging of patient account numbers. Known as ADT A35: Merge Patient Information, Account Number Only, it belongs to the HL7 Version 2 patient administration message family.

Healthcare organizations use account numbers to associate administrative and financial information with a patient account. These identifiers may be connected to billing activity, charges, insurance information, and revenue cycle workflows. When duplicate account numbers are identified and an authorized workflow determines that they should be consolidated, an A35 message can communicate the account merge to systems that support this legacy event.

A35 should not be confused with a patient identifier merge or an encounter merge. The primary purpose is to reconcile account identifiers, not automatically combine patient identities or clinical visits.

Later HL7 Version 2 specifications introduced more explicit merge events, including A41 for patient account number merging. Understanding the distinction is important when maintaining legacy interfaces or modernizing older healthcare integration environments. This guide explains HL7 A35 message structure, examples, important fields, Mirth Connect implementation, acknowledgment handling, troubleshooting, and best practices.

What Is an HL7 ADT A35 Message?

An HL7 ADT A35 message communicates the merging of patient account numbers in a legacy HL7 Version 2 workflow. The event applies when an authorized source system determines that two account identifiers should be reconciled and communicates which account number remains authoritative.

Receiving applications use the message to locate the surviving account and the prior account. They then apply their supported account reconciliation procedures. A35 belongs to the broader HL7 ADT messaging framework, but its account-level purpose differs from patient identity and visit-level merge events.

Purpose of the HL7 A35 Event

A35 communicates an authorized patient account number merge. Receiving applications use the notification to reconcile account identifiers while preserving appropriate administrative and financial relationships.

When Is an ADT A35 Message Generated?

An A35 notification may be generated when registration or revenue cycle staff identify duplicate account numbers and approve their consolidation through an authorized account management workflow.

Which Healthcare Systems Receive A35 Messages?

Legacy patient administration systems, billing applications, revenue cycle platforms, EHRs, and financial data repositories may receive A35 messages when their interfaces support account number merging.

How A35 Supports Account Data Consistency

A35 helps connected applications recognize the surviving account identifier and reconcile references to the prior account. Correct processing reduces inconsistencies across administrative and financial systems.

Why Accurate A35 Processing Matters

Incorrect account merging can associate charges, claims, or financial information with the wrong account. Reliable integration requires account ownership validation, correct merge direction, and audit controls.

HL7 ADT A35 Message Structure and Segments

An HL7 ADT A35 message follows the segment-based format used by HL7 Version 2. Important information includes the message header, event details, patient identification, account context, and the prior account number involved in the merge.

Legacy implementations commonly use MSH, EVN, PID, PV1, and MRG segments. The exact structure and field requirements depend on the HL7 version and implementation profile. This article uses HL7 v2.3 conventions for its illustrative legacy example. Newer account merge workflows may use A41 and different field mappings.

MSH Segment: Message Header

MSH identifies the sending and receiving applications, trigger event, message control identifier, and HL7 version. MSH-9 identifies A35 as the legacy account merge event.

EVN Segment: Event Information

EVN records information about the account merge event, including the event timestamp. Receiving applications can use it to investigate the sequence of account reconciliation changes.

PID Segment: Patient Identification

PID identifies the patient associated with the account merge and carries the surviving account number in PID-18. Receiving systems should validate the patient identity before modifying account relationships.

PV1 Segment: Patient Visit Information

PV1 provides visit context. In HL7 Version 2, PV1-19 identifies the visit number, while PID-18 is the patient account number field. The two should not be treated as interchangeable.

MRG Segment: Prior Account Identification

MRG carries prior identity and account information used by merge events. For account number merging, the prior account number is carried in MRG-3. MRG-1 is still populated with the patient identifier, which does not change in an account-only merge.

HL7 ADT A35 Message Example With Field Explanation

The following example illustrates a fictional patient whose duplicate account numbers are being consolidated. The message uses HL7 v2.3 conventions and identifies ADT^A35 in MSH-9. The surviving account number is represented in PID-18, while MRG-3 carries the prior patient account number.

The example assumes that an authorized account management workflow has already determined that both account identifiers belong to the same patient and should be merged.

Complete HL7 ADT A35 Sample Message

MSH|^~\&|REGISTRATION|HOSPITAL|BILLING|MAIN|20261014120000||ADT^A35|MSG35001|P|2.3
EVN|A35|20261014115500
PID|1||P350001^^^HOSPITAL^MR||DAVIS^EMILY||19850521|F||||||||||ACC350001
PV1|1|O|CLINIC^101^A||||1234^SMITH^ANNA||||||||||||V35001
MRG|P350001^^^HOSPITAL^MR||ACC350002

All patient information is fictional. In this example, ACC350001 is intended to be the surviving account number and ACC350002 the prior account number.

The example is illustrative. Confirm the segment positions, repetitions, and account identifier data types against the exact legacy interface specification before using it in production.

Explore each segment and its key fields:

MSH Segment Explained

MSH identifies REGISTRATION as the sender and BILLING as the receiver. ADT^A35 identifies the legacy account merge event, and MSH-12 specifies HL7 version 2.3.

EVN Segment Explained

EVN identifies the A35 event and records its timestamp. This helps integration teams investigate when the account merge was initiated.

PID-3: Patient Identifier Explained

PID-3 provides patient identity context. The destination should use the appropriate patient identifier and assigning authority to confirm that the account merge applies to the correct person.

PID-18: Surviving Patient Account Number

PID-18 represents the surviving account number in this example. The receiving application should match this value against its authoritative account records before processing.

MRG-3: Prior Patient Account Number

MRG-3 identifies the prior account number in the illustrated legacy workflow. The intended operation consolidates the prior account into the surviving account, subject to the destination's approved rules.

Important HL7 ADT A35 Fields and Mapping

Reliable HL7 A35 integration depends on accurate account identification, correct merge direction, and careful handling of financial relationships. MSH-9 identifies the legacy merge event, MSH-10 supports message tracking, and MSH-12 identifies the HL7 version. PID-3 provides patient identity context, PID-18 identifies the patient account number, and MRG-3 provides the prior account number in the illustrated legacy format.

Receiving applications should not assume that two account numbers belong to the same patient simply because they appear in a valid HL7 message. The merge must follow an authorized account reconciliation process. Clear HL7 v2 integration specifications help prevent incorrect financial data consolidation.

MSH-9: Identifying the A35 Event

MSH-9 identifies A35 as the trigger event. Integration engines should route it through account merge processing rather than patient identity or encounter merge workflows.

PID-18: Identifying the Surviving Account

PID-18 carries the patient account number in the illustrated message. Receiving applications should validate its identifier domain and confirm that the account is eligible to survive the merge.

MRG-3: Identifying the Prior Account

MRG-3 identifies the prior account number in the illustrated legacy format. Incorrect mapping can reverse the intended merge or associate financial information with the wrong account.

PID-3: Validating Patient Identity

PID-3 helps identify the patient associated with the accounts. Receiving systems should validate the relationship between the patient and both account identifiers before consolidation.

PV1-19: Preserving Visit Identification

PV1-19 identifies the visit number, which is distinct from the patient account number. Account merging should not automatically merge separate encounters.

How HL7 ADT A35 Messages Work in Healthcare Integration

An HL7 ADT A35 workflow begins when an authorized registration or revenue cycle application identifies duplicate patient account numbers. The source determines which account will remain authoritative and generates an A35 notification. An integration engine receives the message, validates the HL7 version and account identifiers, and routes it to the destination.

The receiving application locates the surviving and prior accounts, confirms their relationship to the patient, and applies its approved account reconciliation workflow. Because account merging can affect charges, claims, and payment relationships, production processing requires strong validation and audit controls.

Step 1: Duplicate Account Numbers Are Confirmed

Authorized staff or an approved account management process determine that two account numbers should be consolidated. The workflow identifies the surviving and prior accounts.

Step 2: Generate the A35 Merge Notification

The source application generates an A35 message containing the patient identity and account information required by the legacy interface specification.

Step 3: Validate the Message and Account Identifiers

The integration engine checks the trigger event, HL7 version, surviving account, prior account, and patient identifier. Invalid notifications enter an exception workflow.

Step 4: Apply the Authorized Account Merge

The destination confirms account ownership and applies its approved reconciliation procedure. Financial transactions and encounter relationships must remain accurate.

Step 5: Acknowledge and Audit the Outcome

The destination returns an acknowledgment according to the configured processing mode. Audit records document both account identifiers, merge direction, and processing result.

How to Implement HL7 ADT A35 Messages Using Mirth Connect

Mirth Connect can receive, validate, transform, and route legacy HL7 A35 messages between patient registration systems, billing platforms, EHRs, and revenue cycle applications. A typical integration receives an A35 notification through an MLLP listener, identifies the legacy account merge event, extracts the surviving and prior account numbers, and forwards the request to an authorized account management service.

Because account merging can affect claims, charges, payments, and financial reporting, the integration engine should not directly consolidate billing database records. The receiving application must enforce its own account reconciliation rules. Organizations can use Mirth Connect development services to support these integrations.

Configure the HL7 Source Connector

Create a Mirth Connect channel using an MLLP Listener and configure HL7 v2.x as the inbound data type. Set message validation and acknowledgment behavior according to the agreed legacy interface specification.

Filter HL7 ADT A35 Messages

Use a JavaScript filter to identify A35 messages and verify that the source is using the expected HL7 version.

Mirth Connect JavaScript filter:

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 === 'A35' &&
       version === '2.3';

This example assumes a channel specifically configured for HL7 v2.3. Other legacy versions and local profiles may require different validation and field mappings.

Extract Patient and Account Identifiers

Use a transformer to extract the patient identifier, surviving account, prior account, message control identifier, and event timestamp.

Mirth Connect JavaScript transformer:

function component(segment, field, part) {
    var fieldName = segment + '.' + field;
    var partName = fieldName + '.' + part;

    var fieldNode = msg[segment][fieldName];

    if (fieldNode.length() === 0) {
        return '';
    }

    return fieldNode[partName]
        .toString()
        .trim();
}

var eventType = component('MSH', 9, 2);
var version = component('MSH', 12, 1);

var patientId = component('PID', 3, 1);
var patientAuthority = component('PID', 3, 4);

var survivingAccount = component('PID', 18, 1);
var priorAccount = component('MRG', 3, 1);

var visitNumber = component('PV1', 19, 1);

var controlId = component('MSH', 10, 1);
var eventTimestamp = component('EVN', 2, 1);

if (eventType !== 'A35' || version !== '2.3') {
    throw new Error(
        'Unsupported account merge event or version'
    );
}

if (!patientId) {
    throw new Error('Missing patient identifier');
}

if (!survivingAccount || !priorAccount) {
    throw new Error(
        'Missing surviving or prior account number'
    );
}

if (survivingAccount === priorAccount) {
    throw new Error(
        'Cannot merge an account into itself'
    );
}

if (!controlId) {
    throw new Error(
        'Missing message control identifier'
    );
}

var accountMerge = {
    eventType: 'A35',
    hl7Version: version,

    patient: {
        identifier: patientId,
        assigningAuthority: patientAuthority
    },

    survivingAccount: survivingAccount,
    priorAccount: priorAccount,

    visitNumber: visitNumber,
    messageControlId: controlId,
    eventTimestamp: eventTimestamp
};

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

The transformer assumes Mirth Connect has parsed the message into XML. It extracts the first component of each account identifier. Production implementations must preserve complete identifier domains, handle missing or repeating fields, and validate the exact legacy data types.

Transform A35 Into an Account Merge Request

A destination-specific JSON payload can communicate the requested account consolidation to a billing or account management service.

Example JSON transformation:

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

var request = {
    eventType: 'A35',
    action: 'requestPatientAccountMerge',

    patient: event.patient,

    survivingAccount: {
        identifier: event.survivingAccount
    },

    priorAccount: {
        identifier: event.priorAccount
    },

    encounterContext: {
        visitNumber: event.visitNumber
    },

    processingStatus: 'pending_validation',

    sourceEvent: {
        hl7Version: event.hl7Version,
        messageControlId: event.messageControlId,
        eventTimestamp: event.eventTimestamp
    }
};

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

This JSON payload is illustrative, not a standardized HL7 API. The receiving system must independently validate account ownership, merge authorization, and the financial records affected.

Validate Account Ownership Before Processing

Confirm that both account identifiers exist and are eligible for reconciliation. Verify their patient associations, billing status, and any restrictions involving finalized claims or posted payments.

Configure Acknowledgment and Exception Handling

Configure ACK responses according to the interface agreement. Route invalid accounts, authorization failures, and reconciliation conflicts to a monitored exception workflow rather than repeatedly retrying them.

HL7 ADT A35 ACK Message Examples and Error Handling

HL7 acknowledgments allow sending applications to determine whether an A35 notification was accepted or rejected under the configured processing mode. An acknowledgment typically contains MSH and MSA segments. In original acknowledgment mode, AA indicates application acceptance, AE indicates an application error, and AR indicates rejection.

For account merging, the interface agreement should define whether acceptance means successful receipt, validation, or completion of the underlying account reconciliation.

Successful ACK Response: AA

An AA acknowledgment indicates application acceptance under the configured mode. MSA-2 identifies the original A35 message control identifier.

MSH|^~\&|BILLING|MAIN|REGISTRATION|HOSPITAL|20261014120001||ACK|ACK35001|P|2.3
MSA|AA|MSG35001

Application Error Response: AE

An AE response indicates an application processing error. The destination may reject processing because an account cannot be found or a financial reconciliation rule has failed.

MSH|^~\&|BILLING|MAIN|REGISTRATION|HOSPITAL|20261014120002||ACK|ACK35002|P|2.3
MSA|AE|MSG35001|Prior account number not found

Application Rejection Response: AR

An AR response indicates rejection. Unsupported merge events, invalid message versions, or unauthorized source applications may cause the destination to reject the notification.

MSH|^~\&|BILLING|MAIN|REGISTRATION|HOSPITAL|20261014120003||ACK|ACK35003|P|2.3
MSA|AR|MSG35001|Account merge not authorized

Correlate ACK Responses With Account Merges

MSA-2 references the original message control identifier. Integration teams use this value to correlate acknowledgments, retry attempts, and account reconciliation outcomes.

Handle Failed Acknowledgments and Retries

Use idempotency checks and verify the destination's account state before retrying. A lost acknowledgment must not cause duplicate account consolidation or repeated financial transactions.

Common HL7 ADT A35 Integration Errors and Troubleshooting

HL7 A35 integration problems often involve incorrect legacy field mappings, unknown account numbers, reversed merge direction, and conflicts with existing financial records. A destination may reject an A35 notification because the prior account has already been merged or because the accounts belong to different patients.

Other failures occur when account identifiers are confused with visit numbers or when the receiving system expects A41 instead of the legacy A35 event. Troubleshooting should examine the original message, supported HL7 version, account identifiers, acknowledgment responses, and destination reconciliation history. Accurate HL7 parsing and data mapping helps reduce these errors.

Incorrect PID-18 or MRG-3 Mapping

The integration engine may extract the wrong field because it uses mappings from another HL7 version. Verify the exact legacy message definition and account identifier data types.

Surviving and Prior Accounts Are Reversed

Incorrect merge direction can affect financial information associated with the wrong account. Validate the surviving and prior account numbers before allowing reconciliation.

Prior Account Number Cannot Be Found

The destination may not recognize the prior account or may have already consolidated it. Check account history, identifier domains, and existing merge relationships.

Account Number Is Confused With Visit Number

PID-18 identifies the patient account number, while PV1-19 identifies the visit number. Treating these identifiers as interchangeable can create incorrect account and encounter relationships.

Account Merge Conflicts With Financial Transactions

The destination may block consolidation because claims, payments, or other transactions require additional reconciliation. Route these cases to an authorized financial workflow rather than bypassing validation.

HL7 ADT A35 vs A34, A36, A40, and A41

HL7 Version 2 includes different events for merging patient identifiers, patient account numbers, and visit information. A35 represents the legacy account-number-only merge event. A34 concerns patient ID merging, while A36 historically combines patient ID and account number merge information.

Later specifications introduced A40 for patient identifier list merging and A41 for patient account number merging. These events have different scopes and field requirements. Receiving applications should follow the supported HL7 version and implementation guide.

A35 vs A34: Account and Patient ID Merging

A35 concerns account number consolidation, while A34 concerns patient identifier merging. Their effects on billing records and patient identity relationships differ.

A35 vs A36: Account-Only and Combined Merges

A35 communicates an account-number-only merge. A36 historically supports a combined patient ID and account number merge, requiring additional identity validation.

A35 vs A40: Account and Patient Identifier Scope

A35 concerns patient account identifiers, while A40 concerns patient identifier list merging. A billing account merge should not automatically consolidate patient identities.

A35 vs A41: Legacy and Later Account Merging

A35 is a legacy account merge event. A41 provides the later Merge Account, Patient Account Number event and should be evaluated when modernizing older interfaces.

Best Practices for Reliable HL7 A35 Integration

Reliable HL7 A35 integration requires accurate account matching, version-aware parsing, and controlled financial reconciliation. Healthcare organizations should document the authoritative account management application and define which account remains after a merge.

Interfaces should distinguish patient identifiers, account numbers, and visit numbers. They should also detect duplicate messages and conflicting account relationships. Because account consolidation may affect claims and payments, production workflows must preserve financial integrity and maintain detailed audit records.

Document the Supported HL7 Version

Record the exact HL7 version and implementation profile used by the legacy interface. Validate every account identifier field against that specification.

Verify Account Ownership and Merge Direction

Confirm that both accounts belong to the intended patient and that the correct account survives. Reject ambiguous or conflicting reconciliation requests.

Preserve Billing and Financial Integrity

Use the destination's approved account merge functionality. Maintain correct relationships with charges, claims, payments, adjustments, and encounter records.

Prevent Duplicate and Out-of-Sequence Processing

Track message control identifiers and current account relationships. Prevent repeated notifications or older merge requests from causing unintended changes.

Maintain Audit Trails and Exception Workflows

Record both account identifiers, source application, merge direction, authorization, and processing outcome. Investigate failed merges through a controlled reconciliation process.

Frequently Asked Questions About HL7 ADT A35 Messages

HL7 A35 integration raises questions about account merging, legacy field definitions, and the differences between patient IDs, account numbers, and visit numbers. Healthcare developers must understand which identifier survives, where the prior account is carried, and how to prevent account reconciliation from affecting unrelated clinical records. The following answers address common implementation questions. Exact requirements depend on the supported HL7 version and interface specification.

Need Help With HL7 ADT A35 Integration?

Patient account number merging requires accurate field mapping and careful coordination between healthcare registration and billing systems. Taction Software supports HL7 interface development, Mirth Connect configuration, patient account mapping, and revenue cycle application integration.

Our engineers can help organizations maintain legacy A35 interfaces, validate account merge workflows, investigate mapping errors, and plan transitions to supported account reconciliation events. Whether you are integrating a registration platform with a billing system or modernizing existing HL7 interfaces, reliable account messaging helps maintain consistent administrative and financial information.

Legacy HL7 Account Merge Interfaces

We help organizations analyze and maintain older HL7 account merge workflows, including A35 parsing, account validation, and destination mapping.

Mirth Connect Development and Migration

Our engineers configure Mirth Connect channels for account merge notifications, including version-aware transformations, secure routing, and exception handling.

EHR and Revenue Cycle Integration

We support HL7 connectivity between registration systems, EHRs, billing platforms, and revenue cycle applications using approved account reconciliation workflows.

Production Monitoring and Troubleshooting

We help investigate failed account merges, incorrect mappings, acknowledgment errors, and inconsistent downstream account relationships.

Need help with HL7 account number merging? Explore our HL7 interface messaging services to discuss your requirements.