HL7 ADT A50 Message: Change Visit Number, Structure, Segments & Examples

The HL7 A50message is an Admit, Discharge, Transfer (ADT) event used to communicate a change to a patient's visit number. Officially known as ADT A50: Change Visit Number, this event belongs to the HL7 Version 2 patient administration message family.

Healthcare organizations use visit numbers to identify encounters, including inpatient admissions, outpatient appointments, emergency department visits, and other clinical interactions. These identifiers connect patient encounters with clinical documentation, laboratory orders, imaging studies, medication records, charges, and administrative information.

Occasionally, a visit number must be corrected because of a registration error, encounter identifier reassignment, migration, or synchronization issue. When an authorized encounter management process changes a visit number, an A50 notification can inform connected healthcare applications. For example, a hospital changes visit number VIS500002 to VIS500001. The source application generates an A50 message identifying the replacement visit number in PV1-19 and the previous visit number in MRG-5.

The important distinction is that A50 changes a visit identifier. It does not merge two visits or move information between separate encounters. A42 communicates a visit merge, while A45 communicates movement of visit information. A50 communicates a change to the visit number itself. This guide explains HL7 A50 message structure, important fields, examples, Mirth Connect implementation, acknowledgment handling, troubleshooting, and best practices.

What Is an HL7 ADT A50 Message?

An HL7 ADT A50 message communicates a change to an existing visit number. The event is used when an encounter identifier must be replaced while preserving the underlying encounter identity.

In HL7 Version 2, the visit number is represented in PV1-19. For A50, the previous visit number is communicated in MRG-5, Prior Visit Number. The receiving application uses these fields to locate the existing encounter and apply the approved identifier correction.

Understanding A50 within the broader HL7 ADT messaging framework helps integration teams distinguish visit number changes from encounter merges and visit information moves.

Purpose of the HL7 A50 Event

A50 communicates a change from a previous visit number to a replacement visit number. Receiving applications update supported encounter references while preserving the underlying visit identity and relevant clinical relationships.

When Is an ADT A50 Message Generated?

An A50 notification may be generated after an authorized registration or encounter management process corrects a visit number, replaces an outdated identifier, or updates identifiers during system migration.

Which Healthcare Systems Receive A50 Messages?

EHRs, laboratory information systems, radiology applications, billing platforms, clinical documentation systems, and other encounter-aware applications may receive A50 notifications when they support visit number changes.

How A50 Supports Encounter Data Accuracy

A50 helps connected applications maintain consistent encounter references after an authorized identifier correction. Accurate processing reduces the risk of disconnected clinical documentation, orders, results, and charges.

Why Accurate A50 Processing Matters

An incorrect visit number change can associate clinical information with the wrong encounter. Reliable integration requires validated identifiers, assigning authorities, duplicate detection, and preservation of encounter history.

HL7 ADT A50 Message Structure and Segments

An HL7 ADT A50 message follows the segment-based format defined by HL7 Version 2. In HL7 v2.5, A50 uses the ADT_A50 message structure, which it shares with A51. The important segments include MSH, EVN, PID, MRG, and PV1, in that order.

PV1-19 contains the replacement visit number, while MRG-5 contains the previous visit number. The message structure and segment ordering must be validated against the exact HL7 release and implementation profile used by the interface.

MSH Segment: Message Header

MSH identifies the sending application, receiving application, timestamp, trigger event, message control identifier, and HL7 version. MSH-9 identifies A50 and its associated message structure.

EVN Segment: Event Information

EVN provides administrative information about the visit number change, including the recorded event timestamp. It supports troubleshooting, reconciliation, and audit tracking.

PID Segment: Patient Identification

PID identifies the patient associated with the encounter. Receiving applications should verify patient identifiers and assigning authorities before changing visit references.

PV1 Segment: Replacement Visit Number

PV1 contains encounter information, including the replacement visit number in PV1-19. The receiving application should verify that the identifier belongs to the same underlying encounter.

MRG Segment: Previous Visit Number

MRG contains previous identifier information. MRG-5 identifies the prior visit number, allowing the receiving system to locate the existing encounter reference. MRG-1 is a required field; because the patient does not change, it repeats the patient identifier.

HL7 ADT A50 Message Example With Field Explanation

Consider a hospital where an encounter number must be corrected. The registration system previously identified the encounter as VIS500002. After an authorized review, the replacement identifier is established as VIS500001. The source generates an A50 notification to inform the receiving EHR. The following example illustrates the relevant fields using HL7 v2.5 conventions.

Complete HL7 ADT A50 Sample Message

MSH|^~\&|REGISTRATION|HOSPITAL|EHR|MAIN|20261022140000||ADT^A50^ADT_A50|MSG50001|P|2.5
EVN|A50|20261022135500
PID|1||MRN500001^^^HOSPITAL^MR||THOMAS^AMELIA||19870418|F
MRG|MRN500001^^^HOSPITAL^MR||||VIS500002^^^HOSPITAL^VN
PV1|1|O|CLINIC^201^A||||1234^SMITH^ANNA||||||||||||VIS500001^^^HOSPITAL^VN

All patient information is fictional. The intended visit number change is:

The receiving application must confirm that the previous and replacement visit numbers represent the same encounter before applying the correction.

Explore each segment and its key fields:

MSH Segment Explained

MSH identifies REGISTRATION as the sender and EHR as the receiver. ADT^A50^ADT_A50 identifies the visit number change event and its message structure.

EVN Segment Explained

EVN identifies A50 and records the event timestamp. Receiving applications use this information to investigate when the encounter identifier correction was communicated.

PID-3: Patient Identifier Explained

PID-3 contains MRN500001, the patient identifier associated with the encounter. The destination uses this information to validate encounter ownership.

PV1-19: Replacement Visit Number Explained

PV1-19 contains VIS500001, the replacement visit number. The receiving application should validate the identifier value, assigning authority, and relationship to the existing encounter.

MRG-5: Previous Visit Number Explained

MRG-5 contains VIS500002, the previous visit number. The receiving application uses this value to locate the existing encounter reference and validate the change.

Important HL7 ADT A50 Fields and Mapping

Accurate HL7 A50 integration depends on correct mapping of the Visit Number and Prior Visit Number fields. MSH-9 identifies the event, MSH-10 supports message tracking, and MSH-12 identifies the HL7 version. PV1-19 provides the replacement visit number, while MRG-5 identifies the previous visit number.

Both fields use structured identifiers that may include assigning authorities and identifier types. A reliable HL7 v2 integration should preserve complete identifier context rather than comparing visit number values alone.

PV1-19: Replacement Visit Number

PV1-19 contains the replacement encounter identifier. The receiving system should validate the identifier and confirm that it represents the same underlying visit as the previous number.

MRG-5: Prior Visit Number

MRG-5 identifies the previous visit number. Correct extraction is essential because the receiving application uses this field to locate the existing encounter reference.

PID-3: Patient Identity Context

PID-3 identifies the patient associated with the encounter. The receiving application should verify that the encounter belongs to the expected patient before applying the change.

CX Identifier Components and Assigning Authorities

Visit numbers use the CX data type, which can include identifier value, assigning authority, and identifier type. These components help distinguish encounters across facilities and systems.

MSH-10: Message Control Identifier

MSH-10 identifies the message for acknowledgment correlation, duplicate detection, and audit tracking. It should be preserved throughout the visit number change workflow.

How HL7 ADT A50 Visit Number Change Workflows Operate

An HL7 A50 workflow begins when a registration or encounter management system determines that a visit number must be corrected. An authorized process verifies the encounter and confirms the replacement identifier. The source generates an A50 notification containing the previous and replacement visit numbers.

An integration engine validates the message and routes it to connected applications. The receiving application applies its approved encounter identifier correction procedure and records the outcome.

Step 1: Identify the Visit Number Correction

A registration or encounter management workflow identifies an incorrect, outdated, or reassigned visit number. Authorized staff verify the encounter before approving the correction.

Step 2: Confirm the Replacement Visit Number

The source determines the replacement visit number and verifies its assigning authority. The identifier must not conflict with an unrelated encounter.

Step 3: Generate the A50 Notification

The source creates an A50 message containing the replacement visit number in PV1-19 and the previous visit number in MRG-5, together with event metadata.

Step 4: Validate and Process the Change

The receiving application locates the existing encounter, validates the replacement number, and applies its supported identifier correction procedure without merging unrelated visits.

Step 5: Acknowledge and Audit the Outcome

The destination returns an acknowledgment according to the configured processing mode. Audit records preserve the previous and replacement visit numbers, authorization, and processing result.

How to Implement HL7 ADT A50 Messages Using Mirth Connect

Mirth Connect can receive, validate, transform, and route HL7 A50 messages between registration systems, EHRs, laboratory information systems, radiology platforms, and other encounter-aware healthcare applications. A typical implementation receives an A50 notification through an MLLP listener, verifies the event type, extracts the previous and replacement visit numbers, and forwards the correction to an authorized destination application.

The integration engine should not independently rewrite clinical database records or merge encounters. The receiving application must verify that both visit identifiers refer to the same underlying encounter and that the requested correction is authorized. Organizations can use Mirth Connect development services to implement visit number change workflows with secure routing, validation, acknowledgment handling, and exception monitoring.

Configure the HL7 Source Connector

Create a Mirth Connect channel with an MLLP Listener and HL7 v2.x inbound data type. Configure trusted sending systems, connection security, acknowledgment behavior, message retention, and destination routing.

Filter HL7 ADT A50 Messages

Use a JavaScript filter to identify A50 messages and confirm the expected HL7 version and message structure.

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 structure =
    msg['MSH']['MSH.9']['MSH.9.3'].toString();

var version =
    msg['MSH']['MSH.12']['MSH.12.1'].toString();

return messageType === 'ADT' &&
       triggerEvent === 'A50' &&
       structure === 'ADT_A50' &&
       version === '2.5';

This filter assumes an HL7 v2.5 interface that includes MSH-9.3. If the sending application omits the message structure component, document that variation in the interface specification before changing the filter.

Extract Previous and Replacement Visit Numbers

Use a JavaScript transformer to extract the replacement visit number from PV1-19 and the previous visit number from MRG-5.

Mirth Connect JavaScript transformer:

function getComponent(segment, field, component) {
    var fieldName = segment + '.' + field;
    var componentName = fieldName + '.' + component;

    var fieldNode = msg[segment][fieldName];

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

    var componentNode = fieldNode[componentName];

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

    return componentNode.toString().trim();
}

var messageType = getComponent('MSH', 9, 1);
var triggerEvent = getComponent('MSH', 9, 2);
var structure = getComponent('MSH', 9, 3);
var version = getComponent('MSH', 12, 1);

var replacementVisit = getComponent('PV1', 19, 1);
var replacementAuthority = getComponent('PV1', 19, 4);
var replacementType = getComponent('PV1', 19, 5);

var previousVisit = getComponent('MRG', 5, 1);
var previousAuthority = getComponent('MRG', 5, 4);
var previousType = getComponent('MRG', 5, 5);

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

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

if (messageType !== 'ADT' ||
    triggerEvent !== 'A50' ||
    structure !== 'ADT_A50' ||
    version !== '2.5') {
    throw new Error(
        'Unsupported HL7 event, structure, or version'
    );
}

if (!replacementVisit || !previousVisit) {
    throw new Error(
        'Missing visit number change values'
    );
}

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

if (!replacementAuthority || !previousAuthority) {
    throw new Error(
        'Missing visit assigning authority'
    );
}

if (replacementVisit === previousVisit &&
    replacementAuthority === previousAuthority &&
    replacementType === previousType) {
    throw new Error(
        'Previous and replacement visits are identical'
    );
}

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

var visitNumberChange = {
    eventType: 'A50',
    hl7Version: version,

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

    previousVisit: {
        identifier: previousVisit,
        assigningAuthority: previousAuthority,
        identifierType: previousType
    },

    replacementVisit: {
        identifier: replacementVisit,
        assigningAuthority: replacementAuthority,
        identifierType: replacementType
    },

    messageControlId: controlId,
    eventTimestamp: eventTimestamp
};

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

This example reads the first occurrence of each identifier and the namespace component of its assigning authority. Production implementations should preserve complete CX and HD components, support relevant repetitions, and validate encounter ownership through the authoritative encounter management system.

Transform A50 Into a Visit Number Change Request

Create a destination-specific payload that preserves the previous and replacement visit identifiers and the original HL7 event metadata.

Example JSON transformation:

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

var request = {
    eventType: 'A50',
    action: 'requestVisitNumberChange',

    patient: event.patient,

    previousVisitNumber:
        event.previousVisit,

    replacementVisitNumber:
        event.replacementVisit,

    processingStatus: 'pending_encounter_validation',

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

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

This payload is illustrative, not a standardized HL7 API. The destination must independently verify that both identifiers represent the same encounter before applying the correction.

Validate Encounter Ownership Before Processing

Confirm that the previous visit exists, the replacement identifier is valid, and the change does not create an encounter collision. Verify the patient relationship and authoritative encounter record.

Configure Destination Processing and Error Handling

Use an approved encounter management API or supported HL7 interface. Configure acknowledgments, duplicate detection, exception queues, controlled retries, and alerts for rejected or partially completed visit number changes.

HL7 ADT A50 ACK Message Examples and Error Handling

HL7 acknowledgments allow sending applications to determine whether an A50 notification was accepted or rejected under the configured processing mode. A typical acknowledgment contains MSH and MSA segments. ERR may provide additional information about validation or processing failures.

In original acknowledgment mode, AA indicates application acceptance, AE indicates an application error, and AR indicates rejection. The interface agreement should distinguish message acceptance from successful completion of downstream encounter identifier updates.

Successful ACK Response: AA

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

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022140001||ACK^A50^ACK|ACK50001|P|2.5
MSA|AA|MSG50001

Application Error Response: AE

An AE acknowledgment indicates an application processing error. The destination may be unable to locate the previous visit number or validate the replacement identifier.

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022140002||ACK^A50^ACK|ACK50002|P|2.5
MSA|AE|MSG50001
ERR|||204^Unknown Key Identifier^HL70357|E

Application Rejection Response: AR

An AR acknowledgment indicates rejection. Unsupported events, invalid message structures, or unauthorized sending applications may cause the destination to reject the A50 notification.

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022140003||ACK^A50^ACK|ACK50003|P|2.5
MSA|AR|MSG50001

Correlate Acknowledgments With Visit Number Changes

MSA-2 references the original message control identifier. Integration teams should associate each acknowledgment with both visit numbers, the patient identifier, sending application, and destination processing result.

Handle Failed Acknowledgments and Safe Retries

Before retrying an unacknowledged A50 message, verify whether the destination already applied the visit number change. Repeated requests must not create duplicate encounters or incorrectly update clinical references.

Common HL7 ADT A50 Integration Errors and Troubleshooting

HL7 A50 integration problems frequently involve incorrect PV1 and MRG mappings, encounter identifier collisions, missing assigning authorities, and differences between source and destination encounter management systems. A receiving application may reject an A50 message because it cannot locate the previous visit or because the replacement identifier already belongs to another encounter.

Other failures occur when an integration engine treats A50 as a visit merge or assumes that changing a visit number requires moving clinical records between separate encounters. Accurate HL7 parsing and data mapping helps prevent these problems.

PV1-19 and MRG-5 Are Reversed

PV1-19 identifies the replacement visit number, while MRG-5 identifies the previous visit number. Reversing these values can restore an outdated identifier or update the wrong encounter.

Previous Visit Number Cannot Be Found

The destination may not recognize the previous visit number or its assigning authority. Verify the encounter against the authoritative registration system before resubmitting the notification.

Replacement Visit Number Already Exists

The replacement identifier may already belong to another encounter. Treat this as an encounter identity conflict requiring investigation rather than automatically merging visits.

Assigning Authorities Are Ignored

Different facilities may use identical visit number values. Comparing only the identifier component can cause incorrect matching when assigning authorities differ.

A50 Is Incorrectly Processed as A42 or A45

A50 changes a visit number, A42 merges visits, and A45 moves visit information. Applying the wrong operation can damage encounter relationships and clinical record associations.

HL7 ADT A50 vs A42, A45, A49, and A51

HL7 Version 2 defines separate events for visit merges, visit information moves, account number changes, visit number changes, and alternate visit identifier changes. A50 specifically communicates a change to a visit number. A42 merges visit numbers, A45 moves visit information, A49 changes patient account numbers, and A51 changes alternate visit identifiers.

These events have different business meanings and should not be treated as interchangeable.

A50 vs A42: Visit Number Change and Merge

A50 changes an encounter identifier, while A42 merges visit numbers. Changing a number should preserve the underlying encounter rather than consolidate two separate encounters.

A50 vs A45: Visit Number Change and Information Move

A50 replaces a visit number, while A45 moves visit information between visit identifiers. Information movement may require reconciliation beyond a simple identifier change.

A50 vs A49: Visit and Account Number Changes

A50 changes the visit number in PV1-19, while A49 changes the patient account number in PID-18. Encounter and financial account identities must remain distinct.

A50 vs A51: Visit and Alternate Visit Identifier Changes

A50 changes the primary visit number, while A51 changes the alternate visit identifier. The appropriate event depends on which encounter identifier the source application is correcting.

Best Practices for Reliable HL7 A50 Integration

Reliable HL7 A50 integration requires accurate encounter matching, controlled identifier corrections, and preservation of clinical record relationships. Healthcare organizations should identify the authoritative encounter management system and document how downstream applications respond to visit number changes.

Interfaces must distinguish visit identifier changes from encounter merges and information moves. They should also handle duplicate messages, delayed events, identifier collisions, and partial downstream failures.

Validate Complete Visit Identifiers

Compare visit number values together with assigning authorities and identifier types. Do not assume identical visit numbers from different facilities refer to the same encounter.

Preserve Existing Encounter Relationships

Verify that the previous and replacement identifiers represent the same encounter. Do not merge unrelated visits or move clinical information solely because an A50 notification was received.

Maintain Historical Visit Number References

Preserve the previous visit number and its relationship to the replacement identifier. Historical references may be needed for clinical documentation retrieval, billing reconciliation, audits, and troubleshooting.

Implement Idempotency and Controlled Retries

Track message control identifiers and destination encounter state. Before retrying, verify whether the correction has already been applied.

Monitor Downstream Encounter Consistency

Confirm that connected EHR, laboratory, imaging, and billing systems recognize the updated visit number. Investigate unresolved encounter references through a monitored exception workflow.

Frequently Asked Questions About HL7 ADT A50 Messages

HL7 A50 integration raises questions about visit number changes, PV1-19, MRG-5, and the differences between changing, merging, and moving encounter information. The following answers address common implementation requirements.

Need Help With HL7 ADT A50 Integration?

Visit number changes require coordination between registration systems, EHRs, laboratory information systems, radiology platforms, and billing applications. Taction Software supports HL7 interface development, Mirth Connect configuration, encounter identifier mapping, and healthcare interoperability.

Our engineers can help organizations implement A50 workflows, validate visit number mappings, investigate processing errors, and establish dependable monitoring and reconciliation procedures.

HL7 Visit Number Change Interfaces

We develop HL7 A50 interfaces based on source and destination requirements, including PV1-19 and MRG-5 mapping, encounter validation, and controlled identifier correction.

Mirth Connect Development and Integration

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

EHR and Encounter Management Integration

We support integration between EHRs, registration systems, laboratory applications, and other encounter-aware platforms using approved visit number correction workflows.

Production Monitoring and Troubleshooting

We help investigate failed visit number changes, identifier collisions, acknowledgment errors, and inconsistent downstream encounter references.

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