HL7 ADT A16 Message: Pending Discharge, Structure, Segments & Examples

The HL7 A16 message is an Admit, Discharge, Transfer (ADT) notification used to communicate a pending patient discharge. Also known as ADT A16 or Pending Discharge, this HL7 Version 2 event allows healthcare systems to share information about an anticipated discharge before the patient actually leaves or the encounter is formally completed. Hospitals may use A16 notifications to coordinate discharge planning, bed availability, administrative workflows, and communication between connected applications. Unlike an A03 discharge notification, A16 does not confirm that the patient has been discharged. This guide explains message structure, field mapping, examples, Mirth Connect implementation, acknowledgments, and troubleshooting.

What Is an HL7 ADT A16 Message?

An HL7 ADT A16 message communicates that a patient's discharge is anticipated but has not yet occurred. It belongs to the HL7 v2 patient administration message family and allows connected applications to prepare for discharge-related activities without closing the encounter. The message may include patient identifiers, visit information, current location, and anticipated discharge details. Receiving applications should distinguish planned discharge information from actual discharge events to prevent premature encounter closure. Understanding A16 within HL7 ADT messaging helps healthcare integration teams coordinate patient discharge workflows while maintaining accurate encounter records.

Purpose of the HL7 A16 Event

The A16 event informs receiving applications that a patient discharge is planned. It supports advance coordination without confirming that the patient has left the facility or completed the encounter.

When Is an ADT A16 Message Generated?

An A16 notification may be generated when hospital staff record an anticipated discharge. The exact trigger depends on the patient administration system and the organization's discharge planning workflow.

Which Healthcare Systems Receive A16 Messages?

EHRs, bed management platforms, discharge planning applications, and hospital information systems may receive A16 notifications. Each destination handles planned discharge information according to its supported interface and operational requirements.

How A16 Supports Discharge Planning

A16 helps connected systems prepare for anticipated patient departures. Applications may display pending discharge status or support planning activities without prematurely marking beds as vacant.

Why Accurate A16 Processing Matters

Incorrect A16 processing can close encounters too early, release occupied beds, or disrupt downstream workflows. Reliable integration must distinguish pending discharge notifications from actual discharge events.

HL7 ADT A16 Message Structure and Segments

An HL7 ADT A16 message follows the segment-based format defined by HL7 Version 2. Common segments include MSH, EVN, PID, and PV1, with additional segments depending on the HL7 version and interface profile. MSH identifies the sending and receiving applications, message type, and version. EVN records event information, PID identifies the patient, and PV1 provides encounter context. In HL7 v2.5, A16 uses the ADT_A16 message structure. PV1-45 represents discharge date and time, but implementations must define whether and how planned discharge information is communicated through that field or another agreed mechanism.

MSH Segment: Message Header

MSH identifies the sender, receiver, message timestamp, control identifier, and HL7 version. MSH-9 identifies the A16 pending discharge event and its associated message structure.

EVN Segment: Event Information

EVN contains event metadata, including the recorded timestamp. Receiving applications may use this information for auditing, message sequencing, and troubleshooting delayed discharge notifications.

PID Segment: Patient Identification

PID contains patient identifiers and demographic information. Receiving applications use these values to identify the correct patient before associating pending discharge information with an encounter.

PV1 Segment: Patient Visit Information

PV1 provides encounter information, including patient class, assigned location, visit number, and discharge-related fields. Receiving systems should interpret these values within the pending discharge workflow.

Optional Segments in A16 Messages

Additional segments may contain visit, diagnosis, or administrative information depending on the implementation profile. Receiving systems should follow documented requirements for optional data.

HL7 ADT A16 Message Example With Field Explanation

The following HL7 ADT A16 example illustrates a fictional inpatient whose discharge is being planned. The message follows HL7 v2.5 conventions and contains patient identification, event information, and encounter details. MSH-9 identifies the notification as ADT^A16^ADT_A16. PID-3 identifies the patient, PV1-3 contains the assigned location, and PV1-19 identifies the visit. The example intentionally omits an actual discharge timestamp because the patient has not yet been discharged. Planned discharge dates, when exchanged, should follow the sending and receiving applications' agreed interface specifications.

Complete HL7 ADT A16 Sample Message

MSH|^~\&|ADT_SYSTEM|HOSPITAL|EHR|MAIN|20261013120000||ADT^A16^ADT_A16|MSG16001|P|2.5
EVN|A16|20261013115500
PID|1||P890123^^^HOSPITAL^MR||TAYLOR^MARIA||19880619|F
PV1|1|I|WARD6^610^A||||5678^JONES^DAVID||||||||||||V16001

All patient information is fictional. This message indicates a pending discharge for an existing inpatient encounter. It does not represent a completed discharge.

Explore each segment and its key fields:

MSH Segment Explained

MSH identifies ADT_SYSTEM as the sending application and EHR as the receiver. ADT^A16^ADT_A16 identifies the pending discharge event and message structure, while MSG16001 supports message tracking.

EVN Segment Explained

EVN identifies A16 as the event and records its timestamp. Integration teams may use this information to investigate delayed notifications and discrepancies between planned and actual discharge events.

PID-3: Patient Identifier Explained

PID-3 identifies fictional patient Maria Taylor using identifier P890123. Receiving applications should validate the identifier and assigning authority before associating the pending discharge with an existing encounter.

PV1-3: Assigned Patient Location Explained

PV1-3 contains the patient's assigned location. During pending discharge processing, receiving systems should preserve the confirmed location until an appropriate actual discharge event occurs.

PV1-19: Visit Number Explained

PV1-19 identifies the encounter associated with the pending discharge. Accurate visit matching helps prevent pending discharge notifications from affecting unrelated encounters.

Important HL7 ADT A16 Fields and Mapping

Reliable HL7 A16 integration depends on accurate patient identification, encounter matching, and pending discharge status handling. Important fields include MSH-9 for event identification, PID-3 for patient matching, PV1-3 for assigned location, and PV1-19 for visit identification. PV1-45 may contain discharge date and time information, but its interpretation must follow the sending application's interface specification. Receiving systems should avoid treating a planned date as confirmation of discharge. Developers should document required fields and encounter state rules before implementing HL7 v2 integration.

MSH-9: Identifying the Pending Discharge Event

MSH-9 identifies the A16 trigger event. Integration engines use this value to apply pending discharge processing rather than completed discharge, admission, transfer, or cancellation logic.

PID-3: Matching the Correct Patient

PID-3 contains patient identifiers and assigning authorities. Receiving applications should use the complete identifier context to associate the pending discharge with the correct patient record.

PV1-3: Current Patient Location

PV1-3 identifies the assigned patient location. Receiving systems should preserve this information during pending discharge processing and avoid marking the bed vacant prematurely.

PV1-19: Encounter Identification

PV1-19 contains the visit number associated with the pending discharge. Accurate matching prevents the notification from changing unrelated patient encounters or historical records.

PV1-45: Discharge Date and Time

PV1-45 represents discharge date and time. Implementations should document whether this field is omitted, populated, or interpreted differently during pending discharge notifications.

How HL7 ADT A16 Messages Work in Healthcare Integration

An HL7 ADT A16 workflow begins when a healthcare organization records an anticipated patient discharge. The source patient administration system generates an A16 notification containing patient and encounter information. An integration engine receives the message, validates its structure, and routes it to connected applications. Receiving systems record the pending discharge according to their supported workflows while keeping the encounter active. When discharge actually occurs, a separate A03 notification may communicate the completed event. Reliable processing requires accurate encounter matching, duplicate prevention, acknowledgment handling, and monitoring.

Step 1: Planned Discharge Is Recorded

The patient administration system records an anticipated discharge. The source generates an A16 message containing patient identifiers and visit information for connected applications.

Step 2: Message Validation

The integration engine validates the A16 trigger event, patient identifiers, and encounter information. Invalid notifications should enter an exception workflow rather than modify encounter status.

Step 3: Identify the Existing Encounter

Receiving applications locate the patient and active encounter associated with the pending discharge. Accurate matching prevents unrelated visits from being affected.

Step 4: Record Pending Discharge Status

The destination stores or displays the planned discharge according to its supported workflow. The encounter should remain active until an actual discharge is confirmed.

Step 5: Confirm or Cancel the Discharge

A subsequent A03 may confirm the discharge, while A25 may cancel the pending discharge. Receiving applications should correlate these events with the existing discharge plan.

How to Implement HL7 ADT A16 Messages Using Mirth Connect

Mirth Connect can process HL7 ADT A16 messages through source connectors, filters, transformers, and destination connectors. A typical workflow receives pending discharge notifications over MLLP, validates the event, extracts patient and encounter identifiers, and forwards the information to connected applications. The receiving system should preserve the patient's active encounter while recording the planned discharge. Production implementations must also address duplicate notifications, event sequencing, acknowledgment handling, and canceled discharge plans. Organizations can use Mirth Connect development services to support implementation and ongoing interface maintenance.

Configure an HL7 Source Connector

Create a Mirth Connect channel using an MLLP listener or another supported transport connector. Configure the expected HL7 version, message data type, network endpoint, access controls, and acknowledgment settings.

Filter ADT A16 Messages

Configure a source filter to accept A16 notifications and exclude unrelated events. This ensures pending discharge processing remains separate from completed discharge, admission, and transfer 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 === 'A16';

Extract Patient and Encounter Information

Use a JavaScript transformer to extract patient identifiers, visit numbers, current locations, and message control identifiers. Validate required values before sending the pending discharge information to downstream applications.

Mirth Connect JavaScript transformer:

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

var assigningAuthority =
    msg['PID']['PID.3']['PID.3.4'].toString();

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

var patientClass =
    msg['PV1']['PV1.2']['PV1.2.1'].toString();

var currentUnit =
    msg['PV1']['PV1.3']['PV1.3.1'].toString();

var currentRoom =
    msg['PV1']['PV1.3']['PV1.3.2'].toString();

var messageControlId =
    msg['MSH']['MSH.10']['MSH.10.1'].toString();

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

if (eventType !== 'A16') {
    throw new Error('Unexpected ADT event');
}

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

channelMap.put('patientId', patientId);
channelMap.put('assigningAuthority', assigningAuthority);
channelMap.put('visitNumber', visitNumber);
channelMap.put('patientClass', patientClass);
channelMap.put('currentUnit', currentUnit);
channelMap.put('currentRoom', currentRoom);
channelMap.put('messageControlId', messageControlId);
channelMap.put('eventType', eventType);

This example assumes the message has been parsed into Mirth Connect's HL7 v2 XML representation. Production interfaces should account for repeating patient identifiers, assigning authorities, and application-specific encounter matching rules.

Transform A16 Data for Destination Systems

Create a destination-specific payload that explicitly identifies the event as a pending discharge. Preserve the encounter identifier and current location so downstream applications do not prematurely close the visit.

Example JSON transformation:

var pendingDischarge = {
    eventType: 'A16',
    action: 'pendingDischarge',
    status: 'pending',
    patient: {
        id: channelMap.get('patientId'),
        assigningAuthority:
            channelMap.get('assigningAuthority')
    },
    visitNumber: channelMap.get('visitNumber'),
    patientClass: channelMap.get('patientClass'),
    currentLocation: {
        unit: channelMap.get('currentUnit'),
        room: channelMap.get('currentRoom')
    },
    messageControlId:
        channelMap.get('messageControlId')
};

var jsonPayload = JSON.stringify(pendingDischarge);

channelMap.put('jsonPayload', jsonPayload);

The JSON structure is illustrative. Each destination must define its own pending discharge data model, encounter state transitions, and validation requirements.

Test and Monitor Pending Discharge Processing

Test valid A16 notifications, missing encounters, duplicate messages, canceled discharge plans, and delayed A03 notifications. Confirm that receiving applications do not close encounters or release occupied beds prematurely.

HL7 ADT A16 ACK Message Examples and Error Handling

HL7 acknowledgment messages allow sending applications to determine whether A16 pending discharge notifications were accepted or rejected under the configured acknowledgment mode. An ACK includes an acknowledgment code and the original message control identifier. Common application acknowledgment codes include AA for acceptance, AE for application error, and AR for rejection. These responses help integration teams identify successful processing and investigate errors. However, an accepted A16 notification does not confirm that discharge occurred. Receiving applications should maintain separate records of message acceptance and actual discharge status.

Successful ACK Response: AA

An AA acknowledgment indicates application-level acceptance under the configured acknowledgment mode. MSA-2 contains the original A16 message control identifier, allowing the sender to correlate the response.

MSH|^~\&|EHR|MAIN|ADT_SYSTEM|HOSPITAL|20261013120001||ACK^A16^ACK|ACK16001|P|2.5
MSA|AA|MSG16001

Application Error Response: AE

An AE acknowledgment indicates an application processing error. Missing patient identifiers, unknown encounters, or unsupported discharge planning workflows may cause the destination to return an error.

MSH|^~\&|EHR|MAIN|ADT_SYSTEM|HOSPITAL|20261013120002||ACK^A16^ACK|ACK16002|P|2.5
MSA|AE|MSG16001
ERR|||204^Unknown Key Identifier^HL70357|E

Application Rejection Response: AR

An AR acknowledgment indicates that the destination rejected the notification. The sending system should investigate the rejection before correcting or retransmitting the pending discharge message.

MSH|^~\&|EHR|MAIN|ADT_SYSTEM|HOSPITAL|20261013120003||ACK^A16^ACK|ACK16003|P|2.5
MSA|AR|MSG16001

Correlate ACK Responses With Original Messages

MSA-2 identifies the message being acknowledged. Integration engines use this value to associate acknowledgment responses with transmitted A16 notifications and track processing outcomes.

Handle Failed Acknowledgments Safely

Distinguish temporary transport failures from application validation errors. Implement controlled retries and duplicate detection to prevent retransmitted notifications from creating inconsistent pending discharge records.

Common HL7 ADT A16 Integration Errors and Troubleshooting

HL7 A16 integration problems commonly involve premature encounter closure, incorrect discharge date interpretation, duplicate notifications, and missing encounter identifiers. These issues can affect bed management, patient administration, billing, and downstream clinical workflows. A16 notifications may also arrive after an actual A03 discharge because of interface delays, creating inconsistent encounter states. Troubleshooting should examine the original message, acknowledgment response, receiving application rules, and encounter history. A documented HL7 parsing and data mapping process helps reduce these errors and supports reliable discharge planning.

Pending Discharge Treated as Completed

A destination may incorrectly process A16 as A03 and close the encounter. Apply event-specific rules so pending discharge notifications do not trigger completed discharge workflows.

Incorrect Discharge Date Interpretation

A planned discharge timestamp may be mistaken for the actual discharge time. Document how anticipated dates are exchanged and prevent them from automatically closing encounters.

Duplicate Pending Discharge Notifications

Repeated A16 messages may create duplicate discharge plans or administrative tasks. Implement idempotent processing and correlate notifications with existing patient encounters and pending records.

A16 Arrives After A03

An A16 message may arrive after the completed discharge notification because of transmission delays. Receiving applications should avoid reopening or reverting the encounter to pending status.

Pending Discharge Is Never Completed

Some planned discharges are delayed or canceled. Establish reconciliation procedures to identify unresolved pending discharge records and determine whether an A03 or A25 notification was missed.

HL7 ADT A16 vs A03, A13, A15, and A25

HL7 ADT events distinguish planned discharge activities from actual encounter completion and cancellation workflows. A16 communicates a pending discharge, while A03 records an actual discharge or end of visit. A13 cancels a previously recorded actual discharge, whereas A25 cancels a pending discharge. A15 communicates a pending transfer rather than a planned departure from the facility. Although these events may share patient and encounter fields, their operational meanings differ. Receiving systems should use event-specific processing to maintain accurate encounter states and bed management information.

A16 vs A03: Pending and Actual Discharge

A16 communicates that discharge is anticipated, while A03 communicates actual discharge or encounter completion. Receiving applications should preserve active encounter status until an appropriate completed discharge event occurs.

A16 vs A13: Planning and Discharge Reversal

A13 cancels a previously recorded discharge, while A16 communicates a future planned discharge. These events should follow different processing rules to prevent incorrect encounter state changes.

A16 vs A15: Discharge and Transfer Planning

A15 communicates an anticipated transfer between locations, while A16 communicates an anticipated discharge. Their workflows differ because a planned transfer does not necessarily end the patient's encounter.

A16 vs A25: Pending Discharge and Cancellation

A25 cancels a pending discharge previously communicated through A16. Receiving systems should match the cancellation to the correct discharge plan without changing unrelated completed encounters.

Best Practices for Reliable HL7 A16 Integration

Reliable HL7 A16 integration requires accurate encounter matching, separation of pending and actual discharge states, and consistent discharge planning rules. Healthcare organizations should document how receiving applications handle planned departures, estimated discharge dates, duplicate notifications, and canceled plans. Interface specifications should define required identifiers, acknowledgment behavior, exception processing, and event sequencing. Because A16 messages may contain protected health information, secure transmission and controlled access are essential. Combining validation, monitoring, and reconciliation helps healthcare systems maintain dependable discharge planning information across connected applications.

Preserve Active Encounter Status

Ensure A16 notifications remain classified as pending. Avoid closing encounters, releasing occupied beds, or initiating final discharge workflows before the appropriate actual discharge event.

Validate Patient and Visit Identifiers

Use patient identifiers, assigning authorities, and visit numbers to match pending discharge notifications with the correct encounter. Investigate ambiguous matches before updating administrative records.

Support Confirmation and Cancellation Events

Define how A16 notifications transition after A03 confirmation or A25 cancellation. Maintain consistent discharge states and avoid leaving outdated pending plans active.

Secure Patient and Encounter Information

Protect HL7 message transmission, restrict access to integration channels, and minimize sensitive information in operational logs. Apply appropriate healthcare security and privacy controls throughout processing.

Monitor Pending Discharge Exceptions

Track rejected notifications, unresolved discharge plans, duplicate messages, and out-of-sequence events. Establish reconciliation procedures to identify discrepancies between planned and actual encounter states.

Frequently Asked Questions About HL7 ADT A16 Messages

HL7 A16 integration involves planned patient discharges, encounter matching, and event lifecycle management. Healthcare developers and IT teams often need to understand how A16 differs from an actual discharge, which fields identify the affected encounter, and how pending discharge cancellations are communicated. The following questions address common implementation concerns using HL7 v2 conventions. Actual processing requirements depend on the healthcare organization, sending application, receiving system, and agreed interface implementation guide.

Need Help With HL7 ADT A16 Integration?

Reliable pending discharge messaging helps healthcare organizations coordinate patient departures while preserving accurate encounter and bed occupancy information. Taction Software supports HL7 interface development, Mirth Connect configuration, patient matching, and discharge workflow integration. Our engineers can help organizations implement event-specific processing, prevent premature encounter closure, and establish dependable acknowledgment and monitoring procedures. Whether you are connecting a patient administration system to an EHR or improving existing ADT interfaces, accurate message handling supports more consistent discharge planning across connected healthcare applications.

Custom HL7 Pending Discharge Interfaces

We develop HL7 A16 interfaces based on source and destination requirements. Implementation includes patient matching, encounter validation, pending status mapping, routing, and acknowledgment handling.

Mirth Connect Channel Development

Our engineers configure Mirth Connect channels for pending discharge notifications, including event filtering, JavaScript transformations, destination connectivity, and exception handling.

Discharge Planning and Encounter Mapping

We help organizations distinguish planned discharge information from actual encounter completion. These controls support accurate administrative workflows and reduce premature discharge processing.

Production Monitoring and Support

We support HL7 interfaces through monitoring, failure alerts, mapping updates, and recovery procedures. These services help maintain dependable discharge notifications as healthcare workflows evolve.

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