HL7 ADT A05 Message: Pre-Admit a Patient, Structure, Segments & Examples

The HL7 A05 message is a pre-admission notification used in HL7 Version 2 healthcare interfaces to communicate information about a patient expected to be admitted in the future. Also known as ADT A05 or Pre-Admit a Patient, it helps EHRs, hospital registration systems, scheduling applications, and other healthcare platforms prepare for upcoming encounters. The message can contain patient identifiers, demographics, planned visit information, and an expected admission date. This guide explains the HL7 ADT A05 message structure, MSH, EVN, PID, PV1, and PV2 segments, complete HL7 examples, Mirth Connect JavaScript, acknowledgment responses, and troubleshooting practices.

What Is an HL7 ADT A05 Message?

An HL7 ADT A05 message communicates a planned patient admission before the actual admission takes place. It belongs to the Admit, Discharge, Transfer family of HL7 v2 messages and is commonly generated when a hospital records pre-admission information for a scheduled inpatient encounter. Receiving applications can prepare patient and visit records without marking the patient as formally admitted. Unlike A01, which communicates an actual admission, A05 represents a future admission workflow. Understanding this distinction is important for reliable HL7 ADT message integration.

Purpose of the HL7 A05 Pre-Admission Event

The A05 event communicates information about a planned admission. Receiving systems use it to prepare patient and encounter records, coordinate administrative workflows, and associate identifiers before the actual admission occurs.

When Is an ADT A05 Message Generated?

An A05 message is commonly generated when a hospital records an expected admission for a scheduled procedure or inpatient stay. The notification may be distributed before the patient's arrival.

Which Healthcare Systems Receive A05 Messages?

EHRs, hospital information systems, scheduling applications, bed management platforms, and financial systems may receive A05 notifications. Each application processes the information according to its pre-admission workflow requirements.

How A05 Supports Patient Pre-Registration

A05 notifications allow connected applications to prepare demographic and planned encounter information before admission. This supports consistent patient identification and reduces repeated administrative data entry across systems.

Why Accurate A05 Processing Matters

Incorrect A05 processing can create duplicate planned encounters or mistakenly classify patients as admitted. Reliable integration requires accurate patient matching, visit identification, and clear separation between planned and active encounters.

HL7 ADT A05 Message Structure and Segments

An HL7 ADT A05 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 interface profile. MSH identifies the message and its routing information, EVN records event metadata, PID identifies the patient, and PV1 describes the planned visit. PV2 can contain supplementary information, including the expected admission date and time. In HL7 v2.5, the A05 trigger event uses the ADT_A05 message structure. Developers should validate segment requirements against the relevant HL7 version and destination specification.

MSH Segment: Message Header

The MSH segment identifies the sending application, receiving application, message timestamp, control identifier, and HL7 version. MSH-9 identifies the A05 trigger event and associated message structure.

EVN Segment: Event Information

The EVN segment records information about the pre-admission event, including its timestamp. Integration teams use this information to track event generation and investigate delayed notifications.

PID Segment: Patient Identification

The PID segment contains patient identifiers and demographics. Receiving applications use these values to locate the correct patient record before establishing or updating planned encounter information.

PV1 Segment: Patient Visit Information

The PV1 segment describes the planned visit, including patient class, location, attending provider, and visit number. Receiving systems should interpret these values within the pre-admission workflow.

PV2 Segment: Additional Visit Information

The PV2 segment can communicate supplementary visit details, including expected admission date and time in PV2-8. This information helps receiving applications prepare for the anticipated encounter.

HL7 ADT A05 Message Example With Field Explanation

The following HL7 ADT A05 example illustrates a planned inpatient admission using fictional patient information and HL7 v2.5 conventions. The message contains patient identifiers, demographic details, a planned encounter, and an expected admission timestamp. MSH-9 identifies the message as ADT^A05^ADT_A05. PID-3 contains the patient identifier, PV1-19 identifies the planned visit, and PV2-8 communicates the expected admission date and time. The example demonstrates common interface concepts, but actual production requirements depend on the sending and receiving systems' agreed implementation profiles.

Complete HL7 ADT A05 Sample Message

MSH|^~\&|REG_SYSTEM|HOSPITAL|EHR|MAIN|20261012100000||ADT^A05^ADT_A05|MSG50001|P|2.5
EVN|A05|20261012095500
PID|1||P789012^^^HOSPITAL^MR||MILLER^SARAH||19780612|F
PV1|1|I|PREADM^101^A||||4567^JONES^EMILY||||||||||||V30001
PV2||||||||20261015090000

The message represents a pre-admission notification created on October 12, 2026, for an expected admission on October 15, 2026. All patient information is fictional.

Explore each segment and its key fields:

MSH Segment Explained

MSH identifies REG_SYSTEM as the sending application and EHR as the receiving application. ADT^A05^ADT_A05 identifies the pre-admission event, while MSG50001 supports message tracking and acknowledgment correlation.

EVN Segment Explained

EVN identifies A05 as the event and records the notification timestamp. This information supports auditing and helps integration teams investigate delayed or out-of-sequence pre-admission messages.

PID Segment Explained

PID identifies fictional patient Sarah Miller through identifier P789012. Receiving applications should evaluate the identifier and assigning authority before associating pre-admission information with a patient record.

PV1 Segment Explained

PV1 identifies the planned encounter, including inpatient classification, a planned location, an attending provider, and visit number V30001. These details do not independently confirm that admission has occurred.

PV2 Segment Explained

PV2-8 contains the expected admission timestamp, 20261015090000. Receiving systems may use this information for scheduling and administrative coordination without treating the expected time as an actual admission timestamp.

Important HL7 ADT A05 Fields and Mapping

Reliable HL7 A05 integration depends on accurate patient identification, planned encounter information, and expected admission details. Receiving applications must determine whether the patient already exists and how the pre-admission should be represented. Important fields include MSH-9 for the event, PID-3 for patient identification, PV1-19 for visit matching, and PV2-8 for expected admission timing. Although HL7 defines standard field positions, vendor-specific implementation guides may impose additional requirements. Developers should document mandatory fields, accepted values, and transformation rules before deploying HL7 v2 integration interfaces.

MSH-9: Pre-Admission Event Identification

MSH-9 identifies the A05 event. Integration engines inspect this field to distinguish planned admissions from actual admissions, transfers, discharges, and registration updates before applying event-specific processing.

PID-3: Patient Identifier List

PID-3 contains patient identifiers and assigning authorities. Receiving systems should use the complete identifier context to match pre-admission information with existing records and avoid duplicate patients.

PV1-2: Patient Class

PV1-2 identifies the planned encounter classification. Even when the value indicates inpatient care, the A05 event itself represents pre-admission rather than confirmation of an active inpatient admission.

PV1-19: Visit Number

PV1-19 identifies the planned encounter. Accurate visit matching helps receiving systems associate subsequent admission messages with the correct pre-admission record instead of creating duplicate visits.

PV2-8: Expected Admission Date and Time

PV2-8 communicates the anticipated admission date and time when populated. Receiving applications can use this value for planning, but it should not be confused with an actual admission timestamp.

How HL7 ADT A05 Messages Work in Healthcare Integration

An HL7 ADT A05 workflow begins when a healthcare organization records a planned admission. The source application generates a message containing patient identifiers, planned visit information, and any available expected admission details. An integration engine receives the notification, validates required fields, performs necessary transformations, and distributes it to connected applications. Receiving systems identify the patient and create or update the planned encounter according to their workflow rules. A05 processing should not automatically mark the patient as admitted. Reliable interfaces also require acknowledgments, duplicate prevention, and recovery procedures.

Step 1: Pre-Admission Registration

The hospital registration or scheduling system records an expected admission and generates an A05 notification. The message contains patient and planned visit information needed by downstream applications.

Step 2: HL7 Message Validation

The integration engine validates the message structure, event type, patient identifiers, and required encounter fields. Invalid notifications should enter a controlled exception workflow instead of creating incomplete records.

Step 3: Patient and Visit Matching

Receiving applications use patient identifiers and visit numbers to identify existing records. Accurate matching prevents duplicate pre-admission encounters and supports later admission processing.

Step 4: Planned Encounter Creation

The receiving application creates or updates a planned encounter according to its workflow. It should maintain a clear distinction between expected admission and actual admission status.

Step 5: Acknowledgment and Monitoring

The receiving application returns an acknowledgment according to the configured HL7 processing mode. Integration teams monitor failed messages, retries, and reconciliation exceptions to maintain reliable pre-admission synchronization.

How to Implement HL7 ADT A05 Messages Using Mirth Connect

Mirth Connect supports HL7 ADT A05 integration through configurable source connectors, filters, transformers, and destination connectors. Developers can receive pre-admission notifications through MLLP, identify the A05 event, extract patient and visit fields, and transform information into destination-specific formats. JavaScript steps can validate required identifiers and prepare structured payloads for receiving applications. Production implementations also need acknowledgment handling, monitoring, and duplicate prevention. Organizations managing multiple healthcare interfaces can use Mirth Connect development services to support channel implementation and 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, network endpoint, security requirements, and message data type.

Filter ADT A05 Messages

Configure a source filter that checks MSH-9 and accepts the A05 trigger event. This prevents unrelated admission, transfer, and discharge messages from entering pre-admission processing 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 === 'A05';

Extract Patient and Pre-Admission Fields

Use a JavaScript transformer to extract patient identifiers, planned encounter information, and expected admission timing. Validate required values before routing messages to receiving applications.

Mirth Connect JavaScript transformer:

var patientId = msg['PID']['PID.3']['PID.3.1'].toString();
var lastName = msg['PID']['PID.5']['PID.5.1'].toString();
var firstName = msg['PID']['PID.5']['PID.5.2'].toString();

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

var expectedAdmission = '';

if (msg['PV2'].length() > 0) {
    expectedAdmission =
        msg['PV2']['PV2.8']['PV2.8.1'].toString();
}

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

channelMap.put('patientId', patientId);
channelMap.put('patientName', firstName + ' ' + lastName);
channelMap.put('patientClass', patientClass);
channelMap.put('visitNumber', visitNumber);
channelMap.put('expectedAdmission', expectedAdmission);

This example assumes an HL7 v2 message parsed into Mirth Connect's XML representation. Production validation should also account for repeating identifiers, assigning authorities, optional segments, and destination requirements.

Transform Pre-Admission Data for Destinations

Use a transformer to prepare the receiving application's required payload. Preserve patient and visit identifiers and clearly indicate that the event represents pre-admission rather than completed admission.

Example JSON transformation:

var preAdmissionData = {
    eventType: 'A05',
    encounterStatus: 'planned',
    patientId: channelMap.get('patientId'),
    patientName: channelMap.get('patientName'),
    patientClass: channelMap.get('patientClass'),
    visitNumber: channelMap.get('visitNumber'),
    expectedAdmission: channelMap.get('expectedAdmission')
};

var jsonPayload = JSON.stringify(preAdmissionData);

channelMap.put('jsonPayload', jsonPayload);

The encounterStatusvalue is an illustrative application mapping, not an HL7 field. Use the destination's supported status terminology.

Test and Monitor Pre-Admission Processing

Test new patients, returning patients, missing identifiers, duplicate notifications, changed admission dates, and destination failures. Monitor acknowledgments and processing exceptions to identify synchronization problems.

HL7 ADT A05 ACK Message Examples and Error Handling

HL7 acknowledgment messages help sending applications determine whether pre-admission notifications were accepted or rejected under the agreed acknowledgment mode. An ACK response contains 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 support message tracking and controlled recovery. However, acknowledgment behavior depends on interface configuration, and successful acceptance does not necessarily mean every downstream process has completed. Integration teams should document acknowledgment semantics, retry behavior, and reconciliation requirements.

Successful ACK Response: AA

An AA acknowledgment indicates application-level acceptance under the configured acknowledgment mode. The MSA segment contains the original message control identifier so the sender can correlate the response.

MSH|^~\&|EHR|MAIN|REG_SYSTEM|HOSPITAL|20261012100001||ACK^A05^ACK|ACK50001|P|2.5
MSA|AA|MSG50001

Application Error Response: AE

An AE acknowledgment indicates an application error during message processing. Additional error information may identify missing identifiers, invalid encounter information, or another condition requiring correction.

MSH|^~\&|EHR|MAIN|REG_SYSTEM|HOSPITAL|20261012100002||ACK^A05^ACK|ACK50002|P|2.5
MSA|AE|MSG50001
ERR|||204^Unknown Key Identifier^HL70357|E

Application Rejection Response: AR

An AR acknowledgment indicates that the receiving application rejected the notification. The sender should investigate the reason and determine whether correction or retransmission is appropriate.

MSH|^~\&|EHR|MAIN|REG_SYSTEM|HOSPITAL|20261012100003||ACK^A05^ACK|ACK50003|P|2.5
MSA|AR|MSG50001

How to Correlate ACK Responses

MSA-2 contains the original message control identifier. Sending applications use this value to associate an acknowledgment with the corresponding pre-admission notification and support reliable message tracking.

How to Handle Failed Acknowledgments

Failed acknowledgments require controlled recovery procedures. Integration teams should distinguish temporary transport failures from permanent validation errors and apply retries without creating duplicate planned encounters.

Common HL7 ADT A05 Integration Errors and Troubleshooting

HL7 A05 integration problems commonly involve missing patient identifiers, duplicate planned encounters, incorrect expected admission timestamps, or confusion between pre-admission and actual admission events. These issues can create inconsistent visit information across connected healthcare applications. Vendor-specific field requirements may introduce additional validation failures. Troubleshooting should begin with the original HL7 payload, acknowledgment response, field mappings, and receiving application behavior. A documented HL7 parsing and data mapping process helps teams identify errors and improve pre-admission message reliability.

Missing Patient Identifiers

Missing or incorrect PID-3 values can prevent reliable patient matching. Validate identifier requirements and route ambiguous records for investigation rather than creating potentially duplicate patients.

Duplicate Pre-Admission Encounters

Repeated A05 notifications may create duplicate planned encounters when visit matching rules are inadequate. Use patient identifiers, visit numbers, and idempotent processing to prevent unnecessary duplicates.

Incorrect Expected Admission Date

Missing or malformed PV2-8 values can affect scheduling workflows. Validate date and time formats and apply the agreed timezone conventions before forwarding planned admission information.

Incorrect Encounter Status Mapping

Receiving systems may incorrectly treat A05 as an actual admission. Apply event-specific processing rules so planned encounters remain distinguishable from active inpatient admissions.

Failed ACK and Message Delivery

Network interruptions and destination errors can prevent successful processing. Review acknowledgment codes, interface logs, and retry configuration before correcting or safely replaying messages.

HL7 ADT A05 vs A01, A04, A06, and A08

HL7 ADT trigger events represent different patient administration activities. A05 communicates pre-admission information, while A01 represents an actual admission. A04 commonly handles patient registration, A06 communicates a change from outpatient to inpatient status, and A08 updates existing patient information. These messages may share patient and visit segments, but their trigger events have different workflow meanings. Receiving applications should distinguish planned admissions from active encounters and status conversions to prevent incorrect encounter classification, duplicate visits, and inconsistent administrative information.

A05 vs A01: Pre-Admission and Admission

A05 communicates a planned admission, while A01 indicates an actual admission. Receiving applications should maintain distinct encounter states and avoid treating pre-admission notifications as completed admissions.

A05 vs A04: Pre-Admission and Registration

A04 commonly represents patient registration, while A05 communicates a planned admission. The appropriate event depends on the source workflow and the receiving application's encounter management requirements.

A05 vs A06: Pre-Admission and Status Conversion

A06 communicates a change from outpatient to inpatient status. A05 represents a planned admission rather than conversion of an existing outpatient encounter to inpatient classification.

A05 vs A08: Pre-Admission and Information Updates

A08 updates existing patient information, while A05 communicates a pre-admission event. Receiving systems should distinguish these notifications to avoid creating planned encounters during routine demographic updates.

Best Practices for Reliable HL7 A05 Integration

Reliable HL7 A05 integration depends on consistent patient matching, accurate planned encounter information, and clear separation between pre-admission and actual admission workflows. Healthcare organizations should document how receiving applications store planned visits and how subsequent admission events relate to those records. Interface specifications should define required identifiers, expected admission fields, duplicate prevention, and error handling. Because A05 messages may contain protected health information, secure transmission and controlled access are essential. Combining validation, monitoring, and reconciliation helps maintain dependable pre-admission information across connected healthcare systems.

Define Pre-Admission Workflow Rules

Document when A05 messages are generated and how receiving systems represent planned encounters. Establish clear rules for distinguishing pre-admission records from active admissions.

Maintain Consistent Patient Identifiers

Use patient identifiers and assigning authorities to match pre-admission information with existing records. Investigate uncertain matches before creating new patients or planned encounters.

Prevent Duplicate Planned Encounters

Use appropriate message identifiers, patient context, and visit numbers to detect repeated notifications. Ensure retries do not create unnecessary duplicate pre-admission records.

Protect Patient Information

Secure message transmission, restrict endpoint access, and minimize identifiable patient information in operational logs. Apply appropriate healthcare privacy and security requirements throughout the integration workflow.

Monitor Pre-Admission Processing

Track acknowledgments, validation failures, processing delays, and reconciliation exceptions. Establish alerts so integration teams can identify incomplete or inconsistent pre-admission records before they affect downstream workflows.

Frequently Asked Questions About HL7 ADT A05 Messages

HL7 A05 integration involves planned admissions, patient registration, encounter matching, and message processing. Healthcare developers and IT teams often need to distinguish pre-admission notifications from actual admissions and understand how receiving applications handle expected visits. The following questions address common implementation concerns, including message purpose, required segments, field mappings, and Mirth Connect support. Answers reflect general HL7 v2 conventions, while individual healthcare systems may apply additional requirements through their interface implementation guides.

Need Help With HL7 ADT A05 Integration?

Reliable pre-admission messaging helps healthcare organizations prepare patient and encounter information across EHRs, scheduling platforms, registration systems, and administrative applications. Taction Software supports HL7 interface development, Mirth Connect configuration, patient identifier mapping, and production troubleshooting. Our engineers can help organizations distinguish planned admissions from active encounters, improve patient matching, and implement dependable acknowledgment and recovery procedures. Whether an organization is connecting a new hospital registration application or improving existing HL7 channels, careful validation and monitoring support consistent pre-admission information exchange.

Custom HL7 Pre-Admission Interface Development

We develop HL7 A05 interfaces based on source and destination requirements. Implementation includes patient identifier mapping, planned encounter processing, message validation, routing, and acknowledgment handling.

Mirth Connect Channel Development

Our engineers configure Mirth Connect channels to receive, filter, transform, and deliver pre-admission messages. We address destination connectivity, field mapping, and error handling during implementation.

Patient and Encounter Matching

We help organizations improve pre-admission processing through identifier validation, assigning authority mapping, and duplicate prevention. These controls support consistent patient and planned encounter records.

Production Monitoring and Support

We support HL7 interfaces through monitoring, failure alerts, mapping updates, and recovery procedures. These services help maintain dependable pre-admission messaging as connected healthcare systems evolve.

Need help with HL7 pre-admission integration? Explore our HL7 interface messaging services to discuss your requirements.