HL7 ADT A32 Message: Cancel Patient Arriving, Structure, Segments & Examples

The HL7 A32 message is an Admit, Discharge, Transfer (ADT) event used to cancel a previously recorded patient-arriving tracking event. Known as ADT A32 or Cancel Patient Arriving, it belongs to the HL7 Version 2 patient administration event family.

A32 is relevant to healthcare workflows that track patient movement before a patient reaches a department, care area, or other designated location. It allows connected applications to reverse the tracking status established by an earlier A10 Patient Arriving event. Unlike an A12 event, which cancels a patient transfer, A32 concerns the patient tracking workflow rather than automatically reversing an actual transfer.

Accurate A32 processing helps hospitals maintain consistent patient movement information across tracking applications, patient administration systems, and connected clinical platforms. This guide explains HL7 A32 message structure, examples, important fields, Mirth Connect implementation, acknowledgments, troubleshooting, and best practices.

What Is an HL7 ADT A32 Message?

An HL7 ADT A32 message communicates the cancellation of a previously recorded Patient Arriving tracking event. It is part of the HL7 Version 2 patient administration family and is associated with tracking events used to monitor patient movement through healthcare facilities.

A32 typically relates to an earlier A10 event. When the arriving event is canceled, receiving applications should update the relevant tracking state without automatically changing the patient's encounter status or physical location.

Understanding A32 within the broader HL7 ADT messaging framework helps integration teams distinguish tracking cancellations from completed transfers and admissions.

Purpose of the HL7 A32 Event

A32 communicates that a previously recorded patient-arriving tracking event has been canceled. Receiving applications use it to reverse the relevant tracking status without automatically modifying an active encounter.

When Is an ADT A32 Message Generated?

An A32 notification may be generated when a patient-arriving event was recorded incorrectly or when an authorized workflow determines that the tracking event must be canceled.

Which Healthcare Systems Receive A32 Messages?

Patient tracking platforms, patient administration systems, EHRs, and departmental applications may receive A32 notifications when they support the relevant movement tracking workflow.

How A32 Supports Patient Tracking Accuracy

A32 helps connected applications remove an incorrect arriving status. Accurate processing reduces inconsistencies between patient tracking boards, departmental queues, and actual patient movement.

Why Accurate A32 Processing Matters

Incorrect A32 processing can leave inaccurate arrival statuses active or mistakenly reverse completed patient movements. Reliable integration requires encounter matching, tracking state validation, and event sequencing.

HL7 ADT A32 Message Structure and Segments

An HL7 ADT A32 message follows the segment-based format defined by HL7 Version 2. In HL7 v2.5, A32 uses the ADT_A21 message structure. Important segments include MSH, EVN, PID, and PV1, with additional segments depending on the applicable implementation profile.

MSH identifies the message and source application, EVN records event information, PID identifies the patient, and PV1 provides encounter and location context. Because A32 cancels a tracking event, receiving applications should not interpret it as a new admission, completed transfer, or discharge.

MSH Segment: Message Header

MSH identifies the sender, receiver, message timestamp, control identifier, and HL7 version. MSH-9 identifies A32 as the Cancel Patient Arriving trigger event.

EVN Segment: Event Information

EVN records event metadata, including the timestamp associated with the cancellation. Receiving applications can use it to investigate the order of patient tracking changes.

PID Segment: Patient Identification

PID identifies the patient whose arriving event is being canceled. Receiving applications should validate patient identifiers and assigning authorities before updating tracking information.

PV1 Segment: Patient Visit Information

PV1 provides encounter information, including patient class, assigned location, and visit number. These fields help identify the encounter associated with the tracking cancellation.

Optional Segments and Tracking Context

Additional segments may provide administrative or location information under the agreed interface profile. Receiving systems should process them according to the supported HL7 version and workflow.

HL7 ADT A32 Message Example With Field Explanation

The following HL7 ADT A32 example illustrates a fictional inpatient whose previously recorded Patient Arriving tracking event is being canceled. The message uses HL7 v2.5 conventions and identifies ADT^A32^ADT_A21 in MSH-9. PID-3 identifies the patient, while PV1-19 identifies the existing encounter. PV1-3 provides the assigned patient location.

The example assumes that an earlier A10 Patient Arriving event was recorded for the same encounter. The receiving application should cancel the appropriate tracking state without automatically reversing a completed transfer or changing the patient's authoritative location.

Complete HL7 ADT A32 Sample Message

MSH|^~\&|PATIENT_TRACKING|HOSPITAL|EHR|MAIN|20261013180000||ADT^A32^ADT_A21|MSG32001|P|2.5
EVN|A32|20261013175500
PID|1||P320001^^^HOSPITAL^MR||HARRIS^DANIEL||19790812|M
PV1|1|I|WARD4^420^B||||1234^SMITH^ANNA||||||||||||V32001

All patient information is fictional. The message communicates cancellation of an arriving tracking event. It does not by itself establish that the patient has moved to another location.

Explore each segment and its key fields:

MSH Segment Explained

MSH identifies PATIENT_TRACKING as the sending application and EHR as the receiver. ADT^A32^ADT_A21 identifies the cancellation event and message structure.

EVN Segment Explained

EVN identifies A32 as the event and records its timestamp. Integration teams can use this information to investigate when the arriving event was canceled.

PID-3: Patient Identifier Explained

PID-3 identifies fictional patient Daniel Harris using identifier P320001. The assigning authority helps receiving applications locate the correct patient record.

PV1-3: Assigned Patient Location Explained

PV1-3 provides the patient's assigned location. Receiving applications should not automatically interpret the cancellation as a change to the patient's actual location.

PV1-19: Visit Number Explained

PV1-19 identifies the encounter associated with the tracking cancellation. Accurate matching helps prevent changes to unrelated patient movement events.

Important HL7 ADT A32 Fields and Mapping

Reliable HL7 A32 integration depends on accurate event identification, patient matching, and tracking state validation. MSH-9 identifies the cancellation event, MSH-10 supports message tracking, PID-3 identifies the patient, and PV1-19 identifies the encounter. EVN-2 records the event timestamp, while PV1-3 provides assigned location information.

Receiving applications should verify that the relevant arriving event exists before applying the cancellation. A32 should not automatically reverse a completed transfer or modify the authoritative patient location. Clear HL7 v2 integration specifications help prevent inconsistent tracking states.

MSH-9: Identifying the A32 Event

MSH-9 identifies A32 as the trigger event. Integration engines should apply patient-arriving cancellation logic rather than admission, transfer, or discharge processing.

PID-3: Matching the Correct Patient

PID-3 contains patient identifiers and assigning authorities. Receiving applications should validate the complete identifier context before modifying tracking information.

PV1-19: Identifying the Existing Encounter

PV1-19 contains the visit number associated with the tracking event. Accurate matching prevents the cancellation from affecting unrelated patient encounters.

PV1-3: Preserving Patient Location Context

PV1-3 provides assigned location information. Receiving systems should preserve the authoritative patient location unless another validated workflow requires an update.

EVN-2: Sequencing Tracking Events

EVN-2 records event timing. Integration teams can use it alongside tracking history to investigate delayed cancellations and determine the appropriate processing order.

How HL7 ADT A32 Messages Work in Healthcare Integration

An HL7 ADT A32 workflow begins when an authorized application records the cancellation of a previously reported Patient Arriving event. The source generates an A32 message containing patient and encounter information. An integration engine receives the notification, validates its structure, and routes it to connected applications.

Receiving systems identify the patient encounter and locate the relevant arriving tracking event. They then cancel the tracking state according to their supported workflow. The cancellation should not automatically reverse a completed transfer or modify the patient's authoritative location. Reliable processing depends on accurate encounter matching, event sequencing, duplicate prevention, and acknowledgment handling.

Step 1: Patient Arriving Cancellation Is Recorded

An authorized tracking workflow cancels a previously recorded arriving event. The source application generates an A32 notification for connected systems.

Step 2: Validate the HL7 Message

The integration engine checks the A32 event, patient identifier, visit number, and message metadata. Invalid notifications should enter an exception workflow.

Step 3: Match the Existing Encounter

The receiving application identifies the patient and encounter associated with the arriving event. Accurate matching prevents changes to unrelated tracking records.

Step 4: Cancel the Arriving Tracking State

The destination cancels the relevant arriving event according to its workflow rules. It should not automatically reverse an actual transfer or create another encounter.

Step 5: Update Tracking Applications and Acknowledge

Connected systems update supported tracking boards and departmental queues. The receiving application returns an acknowledgment and records the processing outcome.

How to Implement HL7 ADT A32 Messages Using Mirth Connect

Mirth Connect can receive, validate, transform, and route HL7 ADT A32 messages between patient tracking systems, EHRs, patient administration applications, and departmental platforms. A typical implementation receives an A32 notification through an MLLP listener, validates the event type, extracts patient and encounter identifiers, and forwards a cancellation request to the destination tracking application.

The destination should confirm that a corresponding arriving event exists before applying the cancellation. Production interfaces must also account for missing A10 notifications, duplicate cancellations, delayed messages, and conflicts with completed patient movements. Organizations can use Mirth Connect development services to support these workflows.

Configure the HL7 Source Connector

Create a Mirth Connect channel using an MLLP Listener or another supported transport. Configure HL7 v2 parsing, authenticated connectivity, acknowledgment behavior, and appropriate message retention.

Filter HL7 ADT A32 Messages

Use a source filter to identify A32 notifications. Keep patient-arriving cancellations separate from patient departure, transfer, admission, and discharge workflows.

Mirth Connect JavaScript filter:

var messageType =
    msg['MSH']['MSH.9']['MSH.9.1'].toString();

var triggerEvent =
    msg['MSH']['MSH.9']['MSH.9.2'].toString();

return messageType === 'ADT' &&
       triggerEvent === 'A32';

This filter identifies A32 events. Production channels should also validate the sending application, HL7 version, and supported message profile.

Extract Patient and Encounter Information

Use a JavaScript transformer to extract the patient identifier, assigning authority, visit number, location, event timestamp, and message control identifier.

Mirth Connect JavaScript transformer:

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

    var node = msg[segment][fieldName];

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

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

var messageType = getComponent('MSH', 9, 1);
var triggerEvent = getComponent('MSH', 9, 2);

var patientId = getComponent('PID', 3, 1);
var assigningAuthority = getComponent('PID', 3, 4);
var identifierType = getComponent('PID', 3, 5);

var visitNumber = getComponent('PV1', 19, 1);
var patientClass = getComponent('PV1', 2, 1);

var unit = getComponent('PV1', 3, 1);
var room = getComponent('PV1', 3, 2);
var bed = getComponent('PV1', 3, 3);

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

if (messageType !== 'ADT' ||
    triggerEvent !== 'A32') {
    throw new Error('Unexpected HL7 event');
}

if (!patientId || !assigningAuthority) {
    throw new Error(
        'A32 missing patient identifier or authority'
    );
}

if (!visitNumber) {
    throw new Error(
        'A32 missing visit number'
    );
}

if (!messageControlId) {
    throw new Error(
        'A32 missing message control identifier'
    );
}

var cancellationEvent = {
    eventType: 'A32',

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

    encounter: {
        visitNumber: visitNumber,
        patientClass: patientClass
    },

    assignedLocation: {
        unit: unit,
        room: room,
        bed: bed
    },

    eventTimestamp: eventTimestamp,
    messageControlId: messageControlId
};

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

This example assumes Mirth Connect has parsed the HL7 message into its XML representation. Production implementations should support repeating identifiers, complete assigning-authority components, and destination-specific encounter matching rules.

Transform A32 Into a Tracking Cancellation Request

Create a destination-specific payload identifying the patient, encounter, and tracking event type. The destination should locate the applicable arriving event before canceling it.

Example JSON transformation:

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

var cancellationRequest = {
    eventType: 'A32',
    action: 'cancelPatientArriving',

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

    trackingEventToCancel: 'A10',

    assignedLocation: event.assignedLocation,

    processingStatus: 'pending_validation',

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

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

This payload is illustrative rather than a standardized HL7 API. Production systems may require a separate tracking event identifier or additional workflow context to identify the correct A10 event.

Validate the Original Tracking Event

Confirm that the encounter has an eligible arriving event. If the patient has already completed a transfer or another movement event, route the cancellation through the approved reconciliation workflow.

HL7 ADT A32 ACK Message Examples and Error Handling

HL7 acknowledgment messages allow sending applications to determine whether an A32 notification was accepted or rejected under the configured acknowledgment mode. An acknowledgment typically contains MSH and MSA segments, with ERR providing additional information when necessary.

In original acknowledgment mode, AA indicates application acceptance, AE indicates an application error, and AR indicates rejection. For patient tracking cancellations, the interface agreement should distinguish message acceptance from successful cancellation of the corresponding tracking event. A positive acknowledgment does not necessarily confirm that every connected tracking board has been updated.

Successful ACK Response: AA

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

MSH|^~\&|EHR|MAIN|PATIENT_TRACKING|HOSPITAL|20261013180001||ACK^A32^ACK|ACK32001|P|2.5
MSA|AA|MSG32001

Application Error Response: AE

An AE acknowledgment indicates an application processing error. Missing encounters, unknown tracking events, or invalid identifiers may prevent successful cancellation.

MSH|^~\&|EHR|MAIN|PATIENT_TRACKING|HOSPITAL|20261013180002||ACK^A32^ACK|ACK32002|P|2.5
MSA|AE|MSG32001
ERR|||204^Unknown Key Identifier^HL70357|E

Application Rejection Response: AR

An AR acknowledgment indicates rejection by the receiving application. Unsupported event types, invalid message profiles, or unauthorized sources may cause rejection.

MSH|^~\&|EHR|MAIN|PATIENT_TRACKING|HOSPITAL|20261013180003||ACK^A32^ACK|ACK32003|P|2.5
MSA|AR|MSG32001

Correlate ACK Responses With Tracking Cancellations

MSA-2 identifies the original message control identifier. Integration teams use this value to associate acknowledgments, retries, and destination outcomes with the corresponding A32 notification.

Handle Failed Acknowledgments and Retries

Distinguish temporary connectivity failures from permanent application errors. Apply idempotency checks and verify the current tracking state before retrying cancellation requests.

Common HL7 ADT A32 Integration Errors and Troubleshooting

HL7 A32 integration problems commonly involve missing A10 events, incorrect encounter identifiers, delayed cancellation messages, and confusion between tracking cancellation and completed transfer reversal. A receiving application may reject A32 because it never received the original Patient Arriving notification or because the tracking event has already been completed or canceled.

Another problem occurs when a destination incorrectly treats A32 as an A12 transfer cancellation and modifies the patient's actual location. Troubleshooting should examine the original HL7 message, patient identifiers, visit number, tracking history, acknowledgment responses, and destination rules. Accurate HL7 parsing and data mapping helps prevent these issues.

Original A10 Tracking Event Cannot Be Found

The destination may not have received the original A10 notification or may store it under another tracking identifier. Verify the authoritative movement history.

A32 Is Mistaken for A12

A32 cancels a Patient Arriving tracking event, while A12 cancels a transfer. Incorrect mapping can modify actual patient location records instead of tracking status.

Incorrect Patient or Encounter Identifier

The destination may fail to match PID-3 or PV1-19. Validate assigning authorities, visit numbers, and the correct patient encounter before processing.

Duplicate Cancellation Notifications

Repeated A32 messages may arrive after a tracking event has already been canceled. Use message control identifiers and event state to avoid duplicate processing.

Cancellation Arrives After Subsequent Movement Events

A delayed A32 may arrive after another tracking or transfer event. Reconcile the authoritative movement history rather than automatically changing the latest patient status.

HL7 ADT A32 vs A10, A11, A12, and A33

HL7 patient administration events distinguish patient tracking notifications from admission and transfer cancellations. A10 communicates Patient Arriving, while A32 cancels that arriving event. A11 cancels an admission or visit notification, and A12 cancels a transfer. A33 is associated with canceling a Patient Departing tracking event.

Although these messages may contain similar patient and encounter information, their meanings differ. Receiving applications should use event-specific rules rather than treating all cancellation events as interchangeable.

A32 vs A10: Cancellation and Arrival Tracking

A10 communicates a Patient Arriving tracking event, while A32 cancels that event. Receiving applications should identify the correct tracking record before applying the cancellation.

A32 vs A11: Tracking and Admission Cancellation

A11 cancels an admission or visit notification, while A32 cancels a patient-arriving tracking event. Their effects on the patient administration workflow are different.

A32 vs A12: Tracking and Transfer Cancellation

A12 cancels a transfer event, while A32 cancels arrival tracking. A32 should not automatically reverse a completed transfer or change the patient's assigned location.

A32 vs A33: Arriving and Departing Cancellation

A32 cancels Patient Arriving tracking, while A33 cancels Patient Departing tracking. The correct event depends on which movement notification is being reversed.

Best Practices for Reliable HL7 A32 Integration

Reliable HL7 A32 integration requires accurate encounter matching, clear tracking cancellation rules, and coordination between patient tracking and patient administration systems. Healthcare organizations should document how A10 and A32 events affect departmental queues, movement status displays, and downstream notifications.

Interfaces should validate patient identifiers, visit numbers, and existing tracking events before processing cancellations. They should also account for duplicate messages, delayed notifications, and conflicts with completed transfers. Secure transmission, appropriate audit records, and controlled exception handling help maintain reliable patient movement information.

Validate the Original Arriving Event

Confirm that the relevant A10 event exists and is eligible for cancellation. Missing or conflicting tracking states should enter a controlled reconciliation workflow.

Preserve the Authoritative Patient Location

Cancel only the applicable tracking event. Do not automatically change the patient's current assigned location or reverse a completed transfer.

Coordinate Departmental Tracking Updates

Notify connected tracking applications when an arriving event is canceled. Ensure departmental queues and status boards reflect the approved movement history.

Prevent Duplicate and Out-of-Sequence Processing

Use message control identifiers, event timestamps, and current tracking state to prevent repeated cancellations or outdated notifications from overwriting newer movement information.

Monitor Exceptions and Maintain Audit Records

Track rejected messages, missing original events, invalid encounter identifiers, and delayed cancellations. Maintain appropriate audit records and recovery procedures.

Frequently Asked Questions About HL7 ADT A32 Messages

HL7 A32 integration raises questions about patient tracking cancellations, encounter matching, and the difference between arrival tracking and actual patient transfers. Healthcare developers often need to identify the original A10 event, understand which PID and PV1 fields are relevant, and handle notifications that arrive after subsequent movement events. These questions are important when several healthcare applications independently maintain patient movement information. The following answers address common technical concerns using HL7 Version 2 conventions. Actual processing requirements depend on the supported version and implementation profile.

Need Help With HL7 ADT A32 Integration?

Reliable patient tracking cancellation messaging helps healthcare organizations maintain accurate movement information across EHRs, patient administration systems, and departmental applications. Taction Software supports HL7 interface development, Mirth Connect configuration, patient and encounter mapping, and healthcare application integration.

Our engineers can help organizations implement A32 processing, validate tracking events, manage cancellation workflows, and establish dependable acknowledgment and monitoring procedures. Whether you are connecting a patient tracking platform to an EHR or improving existing ADT interfaces, accurate A32 processing supports consistent movement information across connected healthcare systems.

Custom HL7 Patient Tracking Interfaces

We develop HL7 A32 interfaces based on source and destination requirements, including patient matching, tracking event validation, cancellation processing, and acknowledgment handling.

Mirth Connect Channel Development

Our engineers configure Mirth Connect channels for patient movement notifications, including JavaScript transformations, event filtering, secure routing, and exception management.

EHR and Departmental Tracking Integration

We help organizations connect EHRs, patient administration platforms, and departmental tracking applications through reliable HL7 messaging workflows.

Production Monitoring and Support

We support HL7 interfaces through monitoring, failure alerts, mapping updates, and reconciliation procedures that help maintain dependable patient movement messaging.

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