HL7 ADT A09 Message: Patient Departing, Message Structure, Segments & Examples

The HL7 ADT A09message is a patient administration event used to track a patient departing from a location within a healthcare facility. Officially called ADT A09: Patient Departing - Tracking, it communicates physical patient movement without necessarily changing the patient's official census bed assignment.

Hospitals use A09 notifications to support patient transport, radiology visits, operating room workflows, temporary movements, and departmental coordination. The message is commonly paired with ADT A10, which communicates patient arrival. This guide explains A09 structure, important PV1 fields, sample messages, Mirth Connect integration, acknowledgments, and troubleshooting.

What Is an HL7 ADT A09 Message?

HL7 ADT A09 communicates that a patient has departed a location for tracking purposes. The event is used when a patient's physical location changes without necessarily changing the official census bed assignment. For example, an inpatient may leave a nursing unit for a diagnostic imaging appointment while retaining the same assigned hospital bed.

A09 can also support patient movement where a later formal transfer notification is expected. The corresponding A10 event communicates patient arrival. Together, these events help connected systems maintain visibility into patient movement. Understanding A09 within the broader HL7 ADT messaging framework helps teams keep tracking events separate from census events.

Purpose of the HL7 A09 Event

A09 provides a departure notification for patient tracking. Receiving applications use it to update transport status, location visibility, and departmental workflows without automatically treating the movement as a formal transfer.

When Is an ADT A09 Message Generated?

An A09 notification may be generated when a patient leaves a nursing unit, departs for imaging, enters a transport workflow, or moves between clinical departments.

Which Healthcare Systems Receive A09 Messages?

EHRs, patient tracking applications, transport management systems, radiology information systems, operating room platforms, and hospital operational dashboards may receive A09 notifications.

How A09 Supports Patient Flow

A09 allows clinical and operational teams to track patient departures and identify patients in transit. This supports transport coordination, appointment readiness, and communication between departments.

Why Accurate A09 Processing Matters

Incorrect departure processing can create misleading patient location information. Receiving systems must distinguish temporary movements, in-transit states, and formal transfers before updating operational dashboards.

HL7 ADT A09 Message Structure and Segments

The HL7 v2.5 A09 message uses the ADT_A09 structure. The required core segments are MSH, EVN, PID, and PV1. Optional segments can provide additional patient demographics, visit information, observations, disability information, and diagnosis context.

The PV1 segment is especially important because it identifies the patient's assigned, prior, temporary, or pending locations. The precise location field used depends on whether the patient is temporarily moving, in transit, or being tracked before a formal transfer.

HL7 ADT A09 Message Structure

MSH
[{SFT}]
EVN
PID
[PD1]
PV1
[PV2]
[{DB1}]
[{OBX}]
[{DG1}]

Square brackets indicate optional segments, and braces indicate repeating groups in this simplified HL7 v2.5 representation.

MSH Segment: Message Header

MSH identifies the sending application, receiving application, timestamp, message type, control identifier, and HL7 version. MSH-9 contains ADT^A09^ADT_A09.

EVN Segment: Event Information

EVN provides administrative event information, including the recorded event timestamp. It helps receiving applications track when the patient departure was registered.

PID Segment: Patient Identification

PID identifies the patient associated with the departure notification. Receiving applications should validate patient identifiers and assigning authorities before updating patient tracking records.

PV1 Segment: Patient Visit and Location

PV1 contains patient visit information, including assigned location, prior location, temporary location, pending location, and visit number. These fields support movement tracking.

Optional Segments: PV2, OBX, and DG1

PV2 can provide additional visit context. OBX may contain observations, while DG1 can communicate diagnosis information in supported profiles. Their use depends on the interface agreement.

HL7 ADT A09 Message Example With Field Explanation

Consider a patient admitted to a medical ward who needs a CT scan. The patient leaves the ward at 10:30 AM and is transported toward the radiology department. The hospital sends an A09 message to notify connected systems that the patient has departed. The official census bed remains assigned to the patient. When the patient reaches the destination, the tracking system may receive an A10 arrival notification.

Complete HL7 ADT A09 Sample Message

MSH|^~\&|ADT_SYSTEM|HOSPITAL|TRACKING|MAIN|20261022103000||ADT^A09^ADT_A09|MSG09001|P|2.5
EVN|A09|20261022103000
PID|1||MRN090001^^^HOSPITAL^MR||WILSON^DANIEL||19790518|M
PV1|1|I|WARD6^ROOM15^BED1|||WARD6^ROOM15^BED1|||||||||||||VIS090001^^^HOSPITAL^VN

All patient information is fictional. This example represents a departure notification where the patient's official assigned location remains unchanged. It does not specify a destination or expected arrival time. Those details should be supplied through agreed location fields, such as PV1-11 or PV1-42, or a separate transport workflow.

Example A09/A10 patient tracking workflow:

The patient's official census bed can remain assigned during a temporary movement.

Explore each segment and its key fields:

MSH Segment Explained

MSH identifies ADT_SYSTEM as the sender and TRACKING as the destination. The message type ADT^A09^ADT_A09 identifies the departure tracking event.

EVN Segment Explained

EVN records the departure event timestamp. The receiving application can use this value to support patient movement history and operational tracking.

PID-3: Patient Identifier

PID-3 contains the medical record number MRN090001. The destination uses the identifier and assigning authority to locate the correct patient.

PV1-2: Patient Class

PV1-2 contains I, indicating inpatient classification. A09 does not inherently change the patient class from inpatient to outpatient or vice versa.

PV1-3 and PV1-6: Location Context

PV1-3 contains the assigned patient location, while PV1-6 contains prior location information. The exact values used depend on the tracking scenario and interface profile. PV1-19 carries the visit number, VIS090001, which links the departure to the correct encounter.

Important HL7 ADT A09 Fields and Mapping

A09 integration requires more than identifying a patient and an event code. The receiving application must determine whether the patient is moving to a temporary destination, traveling between locations, or departing ahead of a formal census transfer.

HL7 provides several PV1 fields for these situations. The implementation agreement should specify which fields carry the current, previous, temporary, and intended destinations. Misinterpreting these values can cause operational systems to display the wrong patient location.

The location-field interpretation should follow the selected tracking workflow and implementation profile. IHE patient administration guidance distinguishes non-temporary tracking, in-transit movement, and temporary location changes.

PV1-3: Assigned Patient Location

PV1-3 identifies the assigned patient location. For certain non-temporary tracking movements, it carries the new location, while PV1-6 identifies the previous location.

PV1-6: Prior Patient Location

PV1-6 provides previous patient location information. It supports departure tracking and helps downstream applications understand where the patient was located before movement.

PV1-11: Temporary Location

PV1-11 identifies a temporary location, such as an imaging or procedure department. It is relevant when the movement does not change the patient's permanent bed assignment.

PV1-42: Pending Location

PV1-42 can identify the intended destination while the patient is in transit. It helps transport and tracking systems distinguish a destination from the patient's current physical location.

PV1-43: Prior Temporary Location

PV1-43 identifies the prior temporary location. It supports movement tracking when patients leave a temporary area and continue to another destination.

How HL7 ADT A09 Patient Departure Workflows Operate

A09 workflows begin when a clinical or operational system records that a patient has departed a location. The sending application identifies the patient, encounter, departure timestamp, and relevant location context. It generates an A09 message and sends it to an integration engine or directly to receiving applications.

The destination updates the patient's tracking state according to the interface agreement. The patient may remain assigned to the same official census bed until a separate formal transfer or discharge event occurs.

Step 1: Record the Patient Departure

A nurse, transporter, or clinical system records the patient's departure. The source captures the encounter and location information needed for downstream tracking.

Step 2: Generate the A09 Message

The source generates an A09 notification containing the patient identifier, departure event, and supported location fields. The message reflects the movement type.

Step 3: Validate and Route the Notification

An integration engine validates the message structure, patient identifier, encounter, and location fields. It routes the event to approved receiving applications.

Step 4: Update the Patient Tracking Status

The receiving application records the departure and may mark the patient as in transit. It should not automatically discharge or formally transfer the patient.

Step 5: Reconcile the Subsequent Arrival

An A10 arrival notification may complete the tracking sequence. Systems should correlate both events using patient, encounter, timestamps, and location information.

How to Implement HL7 ADT A09 Messages Using Mirth Connect

Mirth Connect can receive, validate, transform, and route A09 messages between EHRs, patient transport systems, radiology applications, and operational dashboards. A typical channel receives an HL7 v2.x message through an MLLP Listener, validates the A09 event, extracts patient and location information, and forwards the tracking event to the destination.

The destination should determine whether the patient is temporarily moving or undergoing a formal transfer. The integration should not treat every A09 as an A02 transfer. Organizations can use Mirth Connect development services to build and support these channels.

Configure the Mirth Connect Source Connector

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

Filter HL7 ADT A09 Messages

Use a JavaScript filter to accept A09 notifications from the supported HL7 v2.5 interface.

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 === 'A09' &&
       structure === 'ADT_A09' &&
       version === '2.5';

Extract Patient, Encounter, and Location Information

The following Mirth Connect transformer extracts the important patient tracking fields.

function fieldValue(segment, number) {
    var name = segment.name().toString();
    var field = name + '.' + number;

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

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

function locationValue(pv1, number) {
    var field = 'PV1.' + number;

    if (pv1[field].length() === 0) {
        return null;
    }

    var location = pv1[field][0];

    return {
        pointOfCare:
            location[field + '.1'].toString().trim(),
        room:
            location[field + '.2'].toString().trim(),
        bed:
            location[field + '.3'].toString().trim(),
        facility:
            location[field + '.4'].toString().trim()
    };
}

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

var trigger =
    msh['MSH.9']['MSH.9.2'].toString();

if (trigger !== 'A09') {
    throw new Error('Unexpected ADT event');
}

var patientId =
    pid['PID.3']['PID.3.1'].toString();

var visitNumber =
    pv1['PV1.19']['PV1.19.1'].toString();

var controlId =
    msh['MSH.10']['MSH.10.1'].toString();

if (!patientId || !visitNumber || !controlId) {
    throw new Error(
        'Missing patient, encounter, or control ID'
    );
}

var trackingEvent = {
    eventType: 'A09',
    action: 'patientDeparting',

    patientId: patientId,
    visitNumber: visitNumber,

    patientClass: fieldValue(pv1, 2),

    assignedLocation:
        locationValue(pv1, 3),

    priorLocation:
        locationValue(pv1, 6),

    temporaryLocation:
        locationValue(pv1, 11),

    pendingLocation:
        locationValue(pv1, 42),

    priorTemporaryLocation:
        locationValue(pv1, 43),

    recordedTimestamp:
        evn['EVN.2']['EVN.2.1'].toString(),

    messageControlId: controlId,

    trackingStatus: 'departed'
};

channelMap.put(
    'patientTrackingEvent',
    JSON.stringify(trackingEvent)
);

This example is a starting point. Production code should preserve complete patient and encounter identifier domains, parse location components according to their HL7 data types, and validate the relevant movement scenario.

Transform A09 Into a Tracking Request

A destination connector can prepare a JSON payload for a patient tracking or transport management API.

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

var request = {
    event: 'patient_departure',

    patientId: event.patientId,
    encounterId: event.visitNumber,

    status: 'in_transit',

    locationContext: {
        assigned: event.assignedLocation,
        prior: event.priorLocation,
        temporary: event.temporaryLocation,
        pending: event.pendingLocation
    },

    recordedAt: event.recordedTimestamp,

    sourceMessageId: event.messageControlId
};

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

The JSON payload is illustrative and is not an HL7-defined API. The destination must interpret the movement according to its supported patient tracking workflow.

Validate Patient and Encounter Matching

Confirm that the patient and visit identifiers resolve to an active or otherwise valid encounter. Reject events that cannot be safely associated with the intended patient.

Configure Tracking and Exception Monitoring

Monitor unacknowledged messages, duplicate departures, missing arrivals, and inconsistent location states. Apply controlled retries and appropriate exception handling.

HL7 ADT A09 ACK Message Examples and Error Handling

HL7 acknowledgment messages indicate whether the receiving application accepted or rejected the departure notification. A typical ACK includes MSH and MSA segments. ERR may provide details when validation fails.

In original acknowledgment mode, AA indicates application acceptance, AE indicates an application error, and AR indicates rejection. A successful acknowledgment confirms processing according to the interface agreement, not necessarily that the patient has reached the destination.

Successful A09 ACK: AA

MSH|^~\&|TRACKING|MAIN|ADT_SYSTEM|HOSPITAL|20261022103001||ACK^A09^ACK|ACK09001|P|2.5
MSA|AA|MSG09001

Application Error ACK: AE

MSH|^~\&|TRACKING|MAIN|ADT_SYSTEM|HOSPITAL|20261022103002||ACK^A09^ACK|ACK09002|P|2.5
MSA|AE|MSG09001
ERR|||204^Unknown Key Identifier^HL70357|E

Application Rejection ACK: AR

MSH|^~\&|TRACKING|MAIN|ADT_SYSTEM|HOSPITAL|20261022103003||ACK^A09^ACK|ACK09003|P|2.5
MSA|AR|MSG09001

Correlate Acknowledgments With Departure Events

MSA-2 should reference the original MSH-10 identifier. Track the response alongside the patient, encounter, departure timestamp, and location information.

Handle Failed Messages and Retries

Before resending an unacknowledged A09 message, determine whether the destination already processed it. Duplicate departures should not create repeated or conflicting tracking states.

Common HL7 ADT A09 Integration Errors and Troubleshooting

A09 integration failures often involve incorrect location mapping, missing patient encounters, delayed messages, or confusion between temporary movement and formal transfer. Some applications assume that the assigned location changes whenever a patient departs. Others incorrectly treat A09 as a discharge event.

These mistakes can affect patient transport coordination, departmental readiness, and operational dashboards. Troubleshooting should examine the departure timestamp, movement type, location fields, and subsequent A10 or A02 events. Accurate HL7 parsing and data mapping helps prevent these problems.

A09 Is Mistaken for A02 Transfer

A09 tracks departure without necessarily changing the official census location. A02 communicates a formal transfer. Applying A02 logic to every A09 may incorrectly change bed assignments.

Temporary Location Is Missing

The destination may require PV1-11 for temporary movements. Validate the sending application's location mapping and the agreed tracking workflow.

A10 Arrival Notification Is Not Received

A patient may remain marked as in transit when an expected A10 message is missing. Monitor incomplete departure-arrival sequences and investigate discrepancies.

Patient Encounter Cannot Be Matched

The destination may not recognize the visit number or patient identifier. Verify PID-3, PV1-19, assigning authorities, and encounter status.

Duplicate or Out-of-Order Events Arrive

A10 may arrive before A09 because of interface delays. Use event timestamps, message tracking, and reconciliation rules to prevent incorrect location status. If a departure was recorded in error, the source should send an A33 Cancel Patient Departing rather than a new movement event.

HL7 ADT A09 vs A10, A02, A03, and A21

HL7 Version 2 defines separate events for patient departure, arrival, transfer, discharge, and leave of absence. A09 is specifically used for departure tracking. It does not inherently indicate a completed transfer, discharge, or authorized leave of absence.

Understanding these differences helps healthcare organizations maintain accurate patient location and encounter information.

A09 vs A10: Departure and Arrival

A09 communicates patient departure, while A10 communicates arrival. Together, they can support movement tracking between departments without automatically changing the census bed assignment.

A09 vs A02: Tracking and Transfer

A09 supports physical movement tracking. A02 communicates an official patient transfer. The destination should preserve the distinction between operational movement and census location changes.

A09 vs A03: Departure and Discharge

A09 does not mean the patient's encounter has ended. A03 communicates discharge or end of visit. Treating A09 as discharge may prematurely close the encounter.

A09 vs A21: Movement and Leave of Absence

A09 tracks patient movement within relevant operational workflows. A21 communicates a leave of absence. The two events represent different administrative situations.

Best Practices for Reliable HL7 A09 Integration

Reliable A09 integration requires accurate location mapping, encounter matching, and coordination between departure and arrival notifications. Healthcare organizations should define how temporary movements, in-transit states, and formal transfers are represented.

The receiving application must avoid modifying official census bed assignments unless the workflow requires it. Integration teams should also monitor missing arrival messages, duplicate departures, and delayed events to maintain reliable patient movement visibility.

Define the Patient Movement Workflow

Document whether A09 represents temporary movement, in-transit tracking, or departure before a formal transfer. Use the appropriate PV1 location fields for each scenario.

Preserve Official Census Bed Assignments

Do not automatically release or change the patient's assigned bed when processing A09. Apply census changes only through the appropriate administrative workflow.

Validate Patient and Encounter Identifiers

Match patient identifiers and visit numbers using complete assigning authority information. This helps prevent movement notifications from being associated with the wrong encounter.

Correlate A09 and A10 Events

Track departure and arrival events using patient, encounter, timestamps, and location information. Monitor incomplete sequences and unexpected location changes.

Implement Monitoring and Audit Logging

Record message control identifiers, movement timestamps, location values, acknowledgment results, and processing errors. Maintain sufficient history for operational troubleshooting.

Frequently Asked Questions About HL7 ADT A09 Messages

Need Help With HL7 ADT A09 Integration?

Patient tracking interfaces require reliable communication between EHRs, registration applications, transport management systems, radiology platforms, and operational dashboards. Taction Software supports HL7 ADT interface development, Mirth Connect implementation, location mapping, and healthcare interoperability.

HL7 Patient Tracking Interface Development

We develop A09 and A10 interfaces based on source and destination requirements, including patient movement tracking, location mapping, and encounter validation.

Mirth Connect Development and Integration

Our engineers configure Mirth Connect channels for patient departure notifications, including JavaScript transformations, secure routing, acknowledgments, and exception monitoring.

EHR and Hospital Operations Integration

We support integration between EHRs, patient transport applications, imaging systems, and hospital operations platforms using approved patient movement workflows.

Production Monitoring and Troubleshooting

We help investigate missing departure notifications, incomplete arrival sequences, location mapping errors, duplicate messages, and inconsistent patient tracking states.

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