HL7 ADT A62 Message: Cancel Change Consulting Doctor, Structure, Segments & Examples

The HL7 A62 message is an Admit, Discharge, Transfer (ADT) event used to cancel a previously recorded change to a patient's consulting doctor. Known as ADT A62: Cancel Change Consulting Doctor, this event allows healthcare applications to correct consulting physician assignments when an earlier A61 change was entered incorrectly or withdrawn. Consulting doctor information supports specialist coordination, clinical documentation, and encounter administration. When a change is canceled, receiving systems must reconcile the original provider assignment without overwriting later valid updates. This guide covers A62 message structure, important fields, examples, Mirth Connect integration, acknowledgments, and troubleshooting.

What Is an HL7 ADT A62 Message?

An HL7 ADT A62 message communicates the cancellation of a previously recorded consulting doctor change. It belongs to the HL7 Version 2 patient administration message family and is associated with reversing an earlier A61 event.

A62 does not represent a new consultation order, an attending doctor change, or a patient transfer. Instead, it informs connected systems that an administrative change involving consulting physician assignments has been canceled. Receiving applications should identify the original change, verify the affected encounter, and determine the correct resulting provider assignment. For the wider event family, see our HL7 ADT messages guide.

Purpose of the HL7 A62 Event

A62 communicates that an earlier consulting doctor change has been canceled. The receiving application uses the notification to reconcile consultation assignments and preserve an accurate administrative event history.

When Is an ADT A62 Message Generated?

An A62 notification may be generated when a consulting physician reassignment was entered incorrectly, applied to the wrong encounter, or withdrawn through an authorized workflow.

Which Healthcare Systems Receive A62 Messages?

EHRs, hospital information systems, registration applications, consultation management platforms, and clinical documentation systems may receive A62 notifications when their interfaces support consulting doctor cancellation events.

How A62 Supports Provider Assignment Accuracy

A62 helps connected applications correct invalid consulting physician changes. Accurate processing reduces discrepancies between registration records, provider assignment histories, and downstream consultation workflows.

Why Accurate A62 Processing Matters

An incorrect cancellation may remove a valid consultant or restore an outdated assignment. The destination must validate the original A61 event, provider identifiers, encounter identity, and subsequent administrative changes.

HL7 ADT A62 Message Structure and Segments

HL7 A62 uses the segment-based format defined by HL7 Version 2. In v2.5, A62 reuses the ADT_A61 message structure, so MSH-9 is ADT^A62^ADT_A61. The message identifies the cancellation event, patient, encounter, and consulting physician information according to the applicable version and implementation profile. Important segments commonly include MSH, EVN, PID, and PV1.

PV1-9 is associated with consulting doctor information in HL7 v2.5, while optional role-related segments may provide additional provider assignment context. The receiving application must interpret the provider information according to the interface agreement rather than assuming every A62 message carries both the original and restored consultant assignments.

MSH Segment: Message Header

MSH identifies the sending application, receiving application, timestamp, message type, control identifier, and HL7 version. MSH-9 identifies the A62 trigger event.

EVN Segment: Event Information

EVN provides administrative information about the cancellation, including the recorded event timestamp. This helps receiving applications investigate delayed messages and reconstruct provider assignment history.

PID Segment: Patient Identification

PID identifies the patient associated with the consulting doctor cancellation. The destination should validate patient identifiers and assigning authorities before modifying encounter records.

PV1 Segment: Patient Visit Information

PV1 provides visit information, including patient class, assigned location, provider assignments, and visit number. It helps identify the encounter affected by the cancellation.

Consulting Doctor and Role Information

PV1-9 can contain consulting doctor information in supported versions. Role-related segments, where allowed by the implementation profile, may provide additional context for consultation assignments.

HL7 ADT A62 Message Example With Field Explanation

Consider a hospital where patient Daniel Wilson is receiving inpatient care. The encounter is identified by visit number VIS620001. A previous A61 message changed the consulting physician from Dr. Michael Brown to Dr. Sarah Lee.

Hospital staff discover that the reassignment was recorded incorrectly. An authorized user cancels the change, and the source system generates an A62 notification. The receiving EHR must verify the original A61 event and determine the correct consulting physician assignment.

Complete HL7 ADT A62 Sample Message

MSH|^~\&|REGISTRATION|HOSPITAL|EHR|MAIN|20261022160000||ADT^A62^ADT_A61|MSG62001|P|2.5
EVN|A62|20261022155500
PID|1||MRN620001^^^HOSPITAL^MR||WILSON^DANIEL||19790518|M
PV1|1|I|WARD6^ROOM15^BED1||||1234^SMITH^ANNA||4567^BROWN^MICHAEL||||||||||VIS620001^^^HOSPITAL^VN

All patient and provider information is fictional. This example assumes the sender's interface profile represents the restored consulting doctor in PV1-9.

The canceled assignment is scenario context, not a separate field explicitly transmitted in this sample A62 message.

Explore each segment and its key fields:

MSH Segment Explained

MSH identifies REGISTRATION as the sender and EHR as the destination. ADT^A62^ADT_A61 identifies the consulting doctor change cancellation, while MSH-10 supports message tracking.

EVN Segment Explained

EVN records the administrative cancellation event and its timestamp. The destination can use this information for audit tracking and reconciliation with the original A61 message.

PID-3: Patient Identifier Explained

PID-3 contains MRN620001, the patient identifier associated with the encounter. The destination must verify the identifier and assigning authority before applying changes.

PV1-9: Consulting Doctor Explained

PV1-9 contains Dr. Michael Brown's provider information in this example. The destination must verify the intended resulting assignment against the original consulting doctor change.

PV1-19: Visit Number Explained

PV1-19 identifies encounter VIS620001. The receiving application should match the visit and its assigning authority to the original provider change before processing cancellation.

Important HL7 ADT A62 Fields and Mapping

Accurate A62 integration requires reliable identification of the patient, encounter, original consulting doctor change, and intended provider assignment. MSH-9 identifies the cancellation event, while MSH-10 supports message tracking. PID-3 identifies the patient. PV1-9 represents consulting doctor information in supported profiles, and PV1-19 identifies the encounter.

The destination should preserve complete provider identifier context and reconcile the cancellation against the original A61 event. Our HL7 parsing and data mapping team can document these reconciliation rules.

PV1-9.1: Consulting Doctor Identifier

PV1-9.1 contains the consulting provider identifier in supported profiles. The destination should resolve this value using the correct provider directory and assigning authority.

PV1-9.2 and PV1-9.3: Consulting Doctor Name

These components commonly represent the consulting physician's family and given names. Names support display and reconciliation but should not replace unique provider identifier matching.

PV1-19: Encounter Identification

PV1-19 identifies the patient encounter associated with the cancellation. It helps prevent a valid A62 notification from being applied to an unrelated visit.

PID-3: Patient Identity

PID-3 provides the patient identifier used for matching. Complete identifier context, including assigning authority, should be preserved to prevent collisions between facilities.

MSH-10: Message Control Identifier

MSH-10 identifies the A62 message for acknowledgment correlation and duplicate detection. It does not automatically identify the original A61 event being canceled.

How HL7 ADT A62 Consulting Doctor Cancellation Workflows Operate

An A62 workflow begins when an authorized user determines that a previously recorded consulting doctor change must be canceled. The source application identifies the original A61 event and affected encounter, validates the cancellation, and generates an A62 notification.

An integration engine validates and routes the message. The receiving application locates the original consulting doctor change, checks whether later assignments affect the cancellation, and reconciles the provider information. The resulting update should preserve unrelated attending doctor and encounter information.

Step 1: Identify the Original Consulting Doctor Change

The source identifies the earlier A61 provider change that requires cancellation. Authorized staff verify the patient, encounter, and original consulting physician assignment.

Step 2: Validate the Cancellation Request

The source confirms that the original change was entered incorrectly or withdrawn. It checks whether subsequent provider assignments affect the requested correction.

Step 3: Generate the A62 Notification

The source creates an A62 message containing patient, encounter, provider, and cancellation event information according to the supported implementation profile.

Step 4: Validate and Route the Message

An integration engine checks the trigger event, identifiers, and routing rules. The notification is forwarded to the application responsible for maintaining consulting doctor assignments.

Step 5: Reconcile and Acknowledge the Cancellation

The destination validates the original event and applies the approved correction. It returns an acknowledgment and records the result for audit and troubleshooting.

How to Implement HL7 ADT A62 Messages Using Mirth Connect

Mirth Connect can receive, validate, transform, and route HL7 A62 messages between hospital registration systems, EHRs, provider directories, and consultation management applications. A typical implementation receives an A62 notification through an MLLP listener, validates the message type, extracts patient and encounter identifiers, and forwards the cancellation request to the authoritative provider assignment system.

The receiving application must verify the original A61 event before reversing the change. This is especially important when an encounter has multiple consulting physicians or subsequent valid provider assignments. Mirth Connect development services can support these requirements.

Configure the Mirth Connect Source Connector

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

Filter HL7 ADT A62 Messages

Use a JavaScript filter to identify the expected trigger event and HL7 version. This prevents unrelated ADT notifications from entering the consulting doctor cancellation workflow.

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 === 'A62' &&
       version === '2.5';

Production validation should also check the sender, supported message structure, required segments, and interface-specific fields. Do not rely exclusively on the trigger event.

Extract Patient, Encounter, and Consulting Doctor Information

The following Mirth Connect JavaScript transformer extracts patient identity, encounter information, consulting doctor details, and cancellation metadata.

function component(segment, fieldNumber, componentNumber) {
    var segmentName = segment.name().toString();
    var fieldName = segmentName + '.' + fieldNumber;
    var componentName = fieldName + '.' + componentNumber;

    var field = segment[fieldName];

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

    return field[componentName].toString().trim();
}

var msh = msg['MSH'];
var pid = msg['PID'];
var pv1 = msg['PV1'];
var evn = msg['EVN'];

var messageType = component(msh, 9, 1);
var triggerEvent = component(msh, 9, 2);
var version = component(msh, 12, 1);

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

var visitNumber = component(pv1, 19, 1);
var visitAuthority = component(pv1, 19, 4);

var controlId = component(msh, 10, 1);
var eventTimestamp = component(evn, 2, 1);

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

if (!patientId || !visitNumber || !controlId) {
    throw new Error(
        'Missing patient, visit, or message identifier'
    );
}

var consultants = [];

for each (var doctor in pv1['PV1.9']) {
    var providerId = doctor['PV1.9.1'].toString().trim();

    if (!providerId) {
        continue;
    }

    consultants.push({
        identifier: providerId,
        familyName: doctor['PV1.9.2'].toString().trim(),
        givenName: doctor['PV1.9.3'].toString().trim(),
        assigningAuthority:
            doctor['PV1.9.9'].toString().trim()
    });
}

var cancellation = {
    eventType: 'A62',
    action: 'cancelConsultingDoctorChange',

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

    encounter: {
        visitNumber: visitNumber,
        assigningAuthority: visitAuthority
    },

    reportedConsultants: consultants,

    sourceEvent: {
        messageControlId: controlId,
        eventTimestamp: eventTimestamp,
        hl7Version: version
    }
};

channelMap.put(
    'consultingCancellation',
    JSON.stringify(cancellation)
);

This example illustrates the E4X scripting model used by Mirth Connect. Production code should handle all relevant identifier repetitions, complete assigning authority components, and provider role information defined by the interface agreement.

Transform A62 Into a Cancellation Request

After validation, create a destination-specific request that communicates the cancellation without automatically overwriting the current consulting doctor assignments.

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

var request = {
    action: 'requestConsultantChangeCancellation',
    eventType: 'A62',

    patient: event.patient,
    encounter: event.encounter,

    reportedConsultants:
        event.reportedConsultants,

    processingStatus:
        'pending_original_change_validation',

    sourceEvent: event.sourceEvent
};

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

This JSON structure is illustrative, not an HL7-defined API. The destination must identify the original A61 change and determine the correct provider assignment after cancellation.

Validate the Original A61 Event

Before applying A62, verify that a matching A61 change exists. Check the original consultants, effective assignment dates, and any subsequent provider updates.

Configure Safe Destination Processing

Use an approved EHR API or supported HL7 interface. Configure controlled retries, duplicate detection, acknowledgment processing, and monitored exception queues for cancellations that cannot be reconciled automatically.

HL7 ADT A62 ACK Message Examples and Error Handling

HL7 acknowledgments communicate whether an A62 notification was accepted or rejected under the configured processing agreement. A typical acknowledgment contains MSH and MSA segments. ERR may provide diagnostic details when message validation or application processing fails.

In original acknowledgment mode, AA indicates application acceptance, AE indicates an application error, and AR indicates rejection. An AA response should not be interpreted as proof that every downstream application has completed the consulting doctor correction.

Successful A62 ACK: AA

An AA acknowledgment references the original A62 message control identifier in MSA-2.

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022160001||ACK^A62^ACK|ACK62001|P|2.5
MSA|AA|MSG62001

Application Error ACK: AE

An AE acknowledgment may indicate that the destination cannot locate the original consulting doctor change or validate the encounter.

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022160002||ACK^A62^ACK|ACK62002|P|2.5
MSA|AE|MSG62001
ERR|||204^Unknown Key Identifier^HL70357|E

The error code is illustrative. Actual error responses must follow the receiving application's HL7 implementation profile.

Application Rejection ACK: AR

An AR acknowledgment may indicate an unsupported A62 event, unauthorized sender, or message that violates the destination's interface specification.

MSH|^~\&|EHR|MAIN|REGISTRATION|HOSPITAL|20261022160003||ACK^A62^ACK|ACK62003|P|2.5
MSA|AR|MSG62001

Correlate Acknowledgments With Original Messages

MSA-2 should reference the original MSH-10 identifier. Integration monitoring should associate each response with the patient, encounter, provider information, and processing result.

Handle Failed Acknowledgments and Retries

Before resending an unacknowledged A62 message, determine whether the destination already processed it. Idempotent processing prevents duplicate cancellations and protects later valid provider assignments.

Common HL7 ADT A62 Integration Errors and Troubleshooting

HL7 A62 integration failures often involve missing original A61 events, incorrect patient or encounter matching, provider identifier mismatches, and out-of-order notifications. Some applications also maintain multiple consulting physicians with different effective dates.

A cancellation that restores the wrong provider list may remove a valid consultant or create an outdated assignment. Troubleshooting should focus on the original change, current provider assignment history, message sequencing, and the destination's supported cancellation rules.

Original A61 Change Cannot Be Found

The destination may not have received or retained the original consulting doctor change. Review interface logs, encounter history, and source records before processing the cancellation.

A62 Is Processed as a New A61 Event

A61 communicates a consulting doctor change, while A62 cancels an earlier change. Treating both as ordinary provider updates can produce incorrect assignments.

Provider Identifiers Do Not Match

The destination may use a different provider identifier domain. Validate the complete identifier, assigning authority, and provider directory mapping before applying the correction.

Multiple Consulting Doctors Are Affected

A single encounter may involve several consulting physicians. The destination should identify which earlier change is being canceled instead of replacing the entire provider list without validation.

A Later Provider Change Already Exists

An A62 message may arrive after another valid A61 event. Reconcile the sequence and effective dates before restoring earlier provider information.

HL7 ADT A62 vs A61, A54, A55, and A08

HL7 Version 2 defines separate events for consulting doctor changes, cancellation of consulting doctor changes, attending doctor updates, and general patient information updates. These events have different administrative meanings. A62 specifically cancels a previously recorded A61 consulting doctor change. The destination should not treat it as a new consulting physician assignment or an attending doctor cancellation.

A62 vs A61: Cancellation and Change

A61 communicates a consulting doctor change, while A62 cancels a previously recorded change. The destination must identify the original A61 event before applying the cancellation.

A62 vs A54: Consulting and Attending Doctors

A54 changes the attending doctor. A62 cancels a consulting doctor change. These events affect different provider roles and require separate mapping rules.

A62 vs A55: Different Provider Cancellations

A55 cancels an attending doctor change, while A62 cancels a consulting doctor change. Processing should preserve the distinction between the two provider responsibilities.

A62 vs A08: Cancellation and General Updates

A08 communicates general patient or visit information updates. A62 has a specific cancellation meaning and may require historical provider assignment reconciliation.

Best Practices for Reliable HL7 A62 Integration

Reliable A62 integration requires accurate encounter identification, authoritative provider information, and validation of the original consulting doctor change. Healthcare organizations should define which system maintains the official consultation assignments and document how cancellations are processed.

Interfaces must account for multiple consulting physicians, delayed delivery, repeated messages, and subsequent provider updates. A well-designed integration preserves administrative history and prevents an old cancellation from overwriting a later authorized assignment.

Validate the Original Consulting Doctor Change

Confirm that a matching A61 event exists and is eligible for cancellation. Do not restore a historical provider assignment solely because an A62 message was received.

Preserve Provider Assignment History

Retain original consulting doctor changes, cancellation events, and subsequent assignments. This supports auditability, clinical coordination, administrative reporting, and troubleshooting.

Use Authoritative Provider Identifiers

Resolve consulting physicians through structured identifiers and assigning authorities. Provider names alone are insufficient because names may be duplicated or formatted differently.

Implement Event Sequencing and Idempotency

Track message control identifiers, encounter history, and provider assignment state. Reconcile delayed or repeated cancellations before modifying current assignments.

Monitor Downstream Consistency

Confirm that EHRs, consultation platforms, and administrative applications reflect the authorized provider assignments. Route unresolved discrepancies through monitored exception workflows.

Frequently Asked Questions About HL7 ADT A62 Messages

HL7 A62 integration raises questions about consulting doctor cancellations, PV1-9 mapping, original A61 events, and provider assignment reconciliation. The following answers address common technical requirements.

Need Help With HL7 ADT A62 Integration?

Consulting doctor cancellation workflows require reliable communication between registration systems, EHRs, provider directories, consultation management platforms, and administrative applications. Taction Software supports HL7 interface development, Mirth Connect implementation, provider identifier mapping, and healthcare interoperability.

Our engineers can help healthcare organizations implement A62 workflows, investigate provider assignment discrepancies, and establish reliable interface monitoring and reconciliation procedures.

HL7 Consulting Doctor Cancellation Interfaces

We develop HL7 A62 interfaces based on source and destination requirements, including original event validation, encounter matching, provider identifier mapping, and controlled cancellation processing.

Mirth Connect Development and Integration

Our engineers configure Mirth Connect channels for consulting doctor cancellations, including JavaScript transformations, secure routing, acknowledgment handling, and exception management.

EHR and Provider Directory Integration

We support integration between EHRs, registration systems, provider directories, and consultation platforms using approved consulting doctor assignment workflows.

Production Monitoring and Troubleshooting

We help investigate missing original events, failed cancellations, provider identifier mismatches, acknowledgment errors, and inconsistent downstream consultation assignments.

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