HL7 ADT A10 Message: Patient Arriving, Message Structure, Segments & Examples

The HL7 ADT A10message is a patient administration event used to communicate a patient's arrival at a location within a healthcare facility. Officially called ADT A10: Patient Arriving - Tracking, this event helps hospitals monitor patient movement between nursing units, radiology departments, operating rooms, procedure areas, and other clinical locations.

A10 is commonly used alongside A09, which records patient departure. Unlike a formal transfer event, A10 does not necessarily change the patient's assigned census bed. This guide explains A10 message structure, important PV1 fields, sample HL7 messages, Mirth Connect integration, acknowledgments, troubleshooting, and implementation best practices.

What Is an HL7 ADT A10 Message?

An HL7 ADT A10 message communicates that a patient has arrived at a location for tracking purposes. Hospitals use this event to maintain accurate visibility into patient movement without necessarily changing the patient's official admission or census status.

For example, an inpatient may arrive at a radiology department for a CT scan while remaining assigned to a bed on the medical ward. The receiving system records the arrival and updates the patient's tracking status. A10 is often associated with a preceding A09 departure notification, although interface workflows must account for missing or delayed events. See the HL7 ADT messages guide for the full event family.

Purpose of the HL7 A10 Event

A10 provides a patient arrival notification to connected healthcare applications. It allows receiving systems to update location tracking, transport status, and departmental workflows.

When Is an ADT A10 Message Generated?

An A10 message may be generated when a patient reaches a diagnostic department, procedure area, temporary care location, or destination after being transported from another location.

Which Healthcare Systems Receive A10 Messages?

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

How A10 Supports Hospital Patient Flow

A10 helps staff identify patients who have reached their destinations. It supports transport completion, departmental readiness, patient tracking, and communication between clinical teams.

Why Accurate A10 Processing Matters

Incorrect arrival processing can create misleading patient location information, prematurely complete transport tasks, or change official bed assignments when only temporary movement was intended.

HL7 ADT A10 Message Structure and Segments

The HL7 Version 2.5 A10 event uses the ADT_A09 message structure. Its core segments include MSH, EVN, PID, and PV1. Optional segments may provide additional demographics, visit information, diagnoses, observations, and other clinical-administrative details.

PV1 is particularly important because it contains the location information needed to understand where the patient has arrived. The implementation agreement must distinguish temporary locations from official assigned locations, especially when an inpatient travels to another department but retains the same census bed.

HL7 ADT A10 Message Structure

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

This is a simplified representation of the HL7 v2.5 ADT_A09 structure. Optional and repeating segments must follow the exact implementation profile.

MSH Segment: Message Header

MSH identifies the sender, receiver, message timestamp, event type, control identifier, and HL7 version. MSH-9 identifies the arrival event as ADT^A10^ADT_A09.

EVN Segment: Event Information

EVN records administrative event information, including the recorded timestamp. It helps receiving systems establish when the arrival was registered.

PID Segment: Patient Identification

PID identifies the patient involved in the arrival event. The destination uses patient identifiers and assigning authorities to locate the correct patient record.

PV1 Segment: Patient Visit and Location

PV1 contains the patient class, assigned location, prior location, temporary location, pending location, and visit number. These fields support patient arrival tracking.

Optional Segments: PV2, OBX, and DG1

PV2 provides additional visit information, OBX can carry observations, and DG1 can communicate diagnoses where supported by the applicable interface profile.

HL7 ADT A10 Message Example With Field Explanation

Consider an inpatient who leaves a medical ward for a scheduled CT scan. The patient departs the ward at 10:30 AM, generating an A09 notification. At 10:42 AM, the patient arrives at the radiology department. The tracking system generates an A10 notification to communicate the arrival. The patient's assigned census bed remains on the medical ward because the radiology visit is temporary. Connected applications update the patient's physical tracking location and mark the transport as completed.

Complete HL7 ADT A10 Sample Message

MSH|^~\&|ADT_SYSTEM|HOSPITAL|TRACKING|MAIN|20261022104200||ADT^A10^ADT_A09|MSG10001|P|2.5
EVN|A10|20261022104200
PID|1||MRN100001^^^HOSPITAL^MR||WILSON^DANIEL||19790518|M
PV1|1|I|WARD6^ROOM15^BED1||||||||RADIOLOGY^CT1^AREA1

All patient information is fictional. In this example, PV1-3 retains the patient's assigned ward location, while PV1-11 identifies the temporary radiology location. The message represents an arrival at a temporary destination, not a formal transfer of the patient's assigned bed.

The assigned inpatient bed remains unchanged during this temporary movement.

Explore each segment and its key fields:

MSH Segment Explained

MSH identifies the sending and receiving applications. ADT^A10^ADT_A09 identifies the arrival tracking event, while MSH-10 provides the message control identifier.

EVN Segment Explained

EVN records the arrival event timestamp. This helps receiving applications track the patient's arrival and reconcile the event with previous departure notifications.

PID-3: Patient Identifier

PID-3 contains the patient's medical record number. The receiving application uses this identifier and its assigning authority to match the correct patient.

PV1-3: Assigned Patient Location

PV1-3 identifies the patient's assigned location. In this temporary movement example, the patient's assigned medical ward bed remains unchanged.

PV1-11: Temporary Location

PV1-11 identifies the temporary radiology destination. This allows the receiving application to distinguish the patient's physical arrival from a formal census bed transfer.

Important HL7 ADT A10 Fields and Mapping

A10 processing depends on accurate patient, encounter, and location information. The receiving application must identify which patient has arrived, which encounter the movement belongs to, and whether the arrival changes a temporary tracking location or an assigned census location.

The PV1 segment provides several fields for these purposes. However, not every A10 workflow populates the same location fields. Hospitals should define consistent mapping rules for temporary movements, in-transit tracking, and non-temporary location changes. Our HL7 parsing and data mapping team can document these rules field by field.

PV1-3: Assigned Patient Location

PV1-3 identifies the assigned patient location. For temporary movements, this may remain the original inpatient bed. For other tracking workflows, its interpretation depends on the agreed profile.

PV1-6: Prior Patient Location

PV1-6 identifies the previous location. It can help the receiving system understand where the patient was located before the arrival event.

PV1-11: Temporary Location

PV1-11 can identify the patient's temporary destination, such as radiology, endoscopy, or another procedure area. It helps distinguish temporary movement from formal transfer.

PV1-19: Visit Number

PV1-19 identifies the encounter associated with the arrival. Correct encounter matching is essential when a patient has multiple active or historical visits.

PV1-42 and PV1-43: Pending and Prior Temporary Locations

PV1-42 supports pending destination information, while PV1-43 identifies the prior temporary location. These fields can help reconstruct movement sequences where supported by the interface.

How HL7 ADT A10 Patient Arrival Workflows Operate

An A10 workflow begins when a patient reaches a destination and the hospital's tracking application records the arrival. The source application identifies the patient, encounter, destination, and event timestamp. It generates an A10 message and transmits it to an integration engine or receiving application.

The destination validates the notification and updates the patient's location tracking state. If the movement is temporary, the patient's official census bed remains assigned. The receiving application should reconcile the arrival with an earlier A09 departure when available.

Step 1: Record the Patient Arrival

A transporter, nurse, or departmental system confirms that the patient has reached the destination. The source records the arrival timestamp and relevant location information.

Step 2: Generate the A10 Notification

The sending application generates an A10 message containing patient identification, encounter information, and supported location fields. The message reflects the arrival tracking event.

Step 3: Validate Patient and Encounter Information

The integration engine verifies the patient identifier, visit number, message structure, and required location details before routing the notification.

Step 4: Update the Patient Tracking Status

The receiving application updates the patient's physical tracking location and may mark the transport task as completed. It should preserve the official census location when appropriate.

Step 5: Reconcile the Departure and Arrival

The destination correlates the A10 arrival with the preceding A09 departure. Missing or delayed messages should be investigated without automatically changing the patient's admission status.

How to Implement HL7 ADT A10 Messages Using Mirth Connect

Mirth Connect can receive, validate, transform, and route A10 messages between EHRs, patient transport applications, radiology systems, and operational dashboards. A typical channel receives the message through an MLLP Listener, verifies the A10 trigger event, extracts patient and encounter identifiers, and maps the location information.

The destination connector forwards the event to a patient tracking application or another approved endpoint. Because patient movement and formal bed assignment are different concepts, the integration must preserve the workflow distinction.

Configure the Mirth Connect Source Connector

Create a channel using an MLLP Listener and HL7 v2.x inbound data type. Configure authorized sending applications, transport security, acknowledgments, and destination routing.

Filter HL7 ADT A10 Messages

Use a JavaScript filter to accept A10 messages using the HL7 v2.5 ADT_A09 structure.

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

var event =
    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 type === 'ADT' &&
       event === 'A10' &&
       structure === 'ADT_A09' &&
       version === '2.5';

Extract Patient, Encounter, and Arrival Location

The following transformer extracts the important tracking fields and stores a structured arrival event in the Mirth Connect channel map.

function getField(segment, fieldName, component) {
    var field = segment[fieldName];

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

    return field[0][fieldName + '.' + component]
        .toString().trim();
}

function getLocation(pv1, fieldNumber) {
    var fieldName = 'PV1.' + fieldNumber;
    var field = pv1[fieldName];

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

    var location = field[0];

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

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

var event =
    getField(msh, 'MSH.9', 2);

if (event !== 'A10') {
    throw new Error('Unexpected HL7 event');
}

var patientId =
    getField(pid, 'PID.3', 1);

var encounterId =
    getField(pv1, 'PV1.19', 1);

var controlId =
    getField(msh, 'MSH.10', 1);

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

// Encounter ID is validated when required
// by the destination implementation profile.

var arrivalEvent = {
    eventType: 'A10',
    action: 'patientArriving',

    patientId: patientId,
    encounterId: encounterId,

    patientClass:
        getField(pv1, 'PV1.2', 1),

    assignedLocation:
        getLocation(pv1, 3),

    priorLocation:
        getLocation(pv1, 6),

    temporaryLocation:
        getLocation(pv1, 11),

    pendingLocation:
        getLocation(pv1, 42),

    priorTemporaryLocation:
        getLocation(pv1, 43),

    recordedTimestamp:
        getField(evn, 'EVN.2', 1),

    messageControlId: controlId,

    trackingStatus: 'arrived'
};

channelMap.put(
    'patientArrivalEvent',
    JSON.stringify(arrivalEvent)
);

The code is illustrative. Production implementations should preserve complete patient and visit identifier domains, validate required fields, and handle any repeating structures permitted by the interface.

Transform A10 Into a Patient Tracking Request

A destination connector can convert the validated arrival event into a structured request for a transport management or patient tracking API.

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

var request = {
    operation: 'recordPatientArrival',

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

    status: 'arrived',

    location: {
        assigned: event.assignedLocation,
        temporary: event.temporaryLocation,
        prior: event.priorLocation
    },

    recordedAt: event.recordedTimestamp,

    sourceMessageId: event.messageControlId
};

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

This JSON is an illustrative application payload, not a standardized HL7 or FHIR API. Adapt it to the receiving system's documented endpoint.

Correlate A09 Departure With A10 Arrival

Use patient identifiers, encounter identifiers, event timestamps, and location information to associate the arrival with the corresponding departure. Handle delayed or missing notifications explicitly.

Configure Monitoring and Exception Handling

Monitor failed acknowledgments, duplicate arrivals, missing departures, inconsistent location values, and unresolved encounters. Use controlled retries and an exception queue for events requiring review.

HL7 ADT A10 ACK Message Examples and Error Handling

HL7 acknowledgments communicate whether the receiving application has accepted or rejected an A10 notification. The acknowledgment commonly contains MSH and MSA segments, with ERR providing additional information when processing fails.

In original acknowledgment mode, AA indicates application acceptance, AE indicates an application error, and AR indicates rejection. An AA acknowledgment confirms acceptance according to the agreed processing rules. It does not necessarily mean every connected operational system has completed its patient location update.

Successful A10 ACK: AA

MSH|^~\&|TRACKING|MAIN|ADT_SYSTEM|HOSPITAL|20261022104201||ACK^A10^ACK|ACK10001|P|2.5
MSA|AA|MSG10001

Application Error ACK: AE

MSH|^~\&|TRACKING|MAIN|ADT_SYSTEM|HOSPITAL|20261022104202||ACK^A10^ACK|ACK10002|P|2.5
MSA|AE|MSG10001
ERR|||204^Unknown Key Identifier^HL70357|E

This error is illustrative. Actual ERR values must follow the receiving application's implementation profile.

Application Rejection ACK: AR

MSH|^~\&|TRACKING|MAIN|ADT_SYSTEM|HOSPITAL|20261022104203||ACK^A10^ACK|ACK10003|P|2.5
MSA|AR|MSG10001

Correlate ACK Responses With Original Messages

MSA-2 should contain the original MSH-10 message control identifier. Monitoring should connect the response with the patient, encounter, arrival timestamp, and location.

Handle Duplicate Arrivals and Retries

Before resending an unacknowledged A10 message, determine whether the destination already processed it. Repeated arrival notifications should not create duplicate transport completions or conflicting location states.

Common HL7 ADT A10 Integration Errors and Troubleshooting

A10 integration failures often result from missing encounter identifiers, incorrect location mapping, delayed messages, or unexpected event sequences. A receiving application may also interpret an arrival as a formal transfer when the movement is temporary. These errors can create misleading operational dashboards and inaccurate transport status.

Troubleshooting should examine the A10 message, any preceding A09 departure, patient and encounter identifiers, location-field mapping, and downstream processing history. Our HL7 interface messaging team can help trace failures across the full message flow.

A10 Arrives Before A09

Network delays or asynchronous routing may cause A10 to arrive before its corresponding departure notification. Use event timestamps and reconciliation logic instead of assuming arrival order.

Temporary Location Is Incorrect

PV1-11 may contain an incorrect department or room. Validate the location against the hospital's approved location directory and interface mapping rules.

Patient Encounter Cannot Be Matched

The receiving application may not recognize PID-3 or PV1-19. Verify the identifiers, assigning authorities, and encounter status before updating the tracking record.

A10 Is Processed as a Formal Transfer

A10 communicates arrival tracking. Treating it as A02 may incorrectly change the patient's assigned census bed or create an unintended transfer.

Duplicate Arrival Notifications Are Processed

Repeated messages can create duplicate transport completions or conflicting patient movement histories. Use message control identifiers and event-based deduplication.

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

HL7 Version 2 distinguishes arrival tracking from departure tracking, formal transfers, discharge, and changes in patient classification. These events serve different administrative purposes. A10 communicates arrival at a location. A09 communicates departure. A02 represents a formal patient transfer, A03 communicates discharge or end of visit, and A07 changes an inpatient to an outpatient.

A10 vs A09: Arrival and Departure

A09 records departure, while A10 records arrival. Together, these messages support patient tracking across clinical departments without necessarily changing the official census bed.

A10 vs A02: Tracking and Formal Transfer

A10 communicates physical arrival for tracking. A02 communicates a formal patient transfer. The receiving application must distinguish temporary movements from changes to the assigned location.

A10 vs A03: Arrival and Discharge

A10 indicates arrival at a location, while A03 indicates discharge or end of visit. Processing an arrival should not automatically close an encounter.

A10 vs A07: Arrival and Patient Class Change

A10 communicates patient arrival. A07changes the patient's classification from inpatient to outpatient. These events affect different aspects of patient administration.

Best Practices for Reliable HL7 A10 Integration

Reliable A10 integration depends on consistent patient identification, encounter matching, location mapping, and event sequencing. Healthcare organizations should define when an arrival represents temporary movement and when another ADT event is needed for a formal transfer.

Integration teams should test realistic scenarios involving delayed departures, missing arrival notifications, duplicate messages, and patients visiting multiple departments. The goal is to maintain accurate operational visibility without unintentionally changing admission status or assigned beds.

Define Location Mapping Rules

Document which PV1 fields represent assigned, temporary, prior, and pending locations. Use consistent location codes across sending and receiving applications.

Preserve Census Bed Assignments

Do not automatically change the patient's official bed assignment when processing a temporary arrival. Apply formal transfer rules only when the appropriate event occurs.

Validate Patient and Encounter Identifiers

Use complete identifier domains and encounter references. This helps prevent arrival events from being associated with the wrong patient or visit.

Implement Event Sequencing and Deduplication

Correlate A09 and A10 events, handle delayed messages, and prevent repeated notifications from creating inconsistent movement histories.

Monitor Incomplete Patient Tracking Workflows

Track patients whose departure and arrival events do not reconcile. Provide operational alerts or exception queues for unresolved movement states.

Frequently Asked Questions About HL7 ADT A10 Messages

Need Help With HL7 ADT A10 Integration?

Reliable patient arrival tracking requires accurate communication between EHRs, registration applications, transport management systems, radiology platforms, and operational dashboards. Taction Software supports HL7 interface development, Mirth Connect implementation, patient location mapping, and healthcare interoperability.

HL7 Patient Arrival Tracking Interfaces

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

Mirth Connect Development and Integration

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

EHR and Hospital Operations Integration

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

Production Monitoring and Troubleshooting

We help investigate missing arrival notifications, incomplete movement sequences, incorrect location mappings, duplicate events, and inconsistent patient tracking states.

Need help with HL7 patient arrival integration? Explore HL7 Integration and Taction Software's EHR integration services to discuss your requirements.