HL7 ADT A01 Message: Complete Guide to Admit/Visit Notification

HL7 a01 is the ADT event that announces a patient admission. When a registration clerk or bed-management workflow admits a patient, the source EHR sends an ADT^A01 message with patient identity, encounter details, and event metadata, and every subscribed system uses it to open the same inpatient visit. This guide covers the A01 message structure, a complete sample message, field mappings, how A01 drives downstream workflows, a Mirth Connect implementation, troubleshooting, how A01 compares with other ADT events, and security practices for production feeds.

HL7 ADT A01 Overview

A01 is the Admit/Visit Notification trigger event in the HL7 v2 admit, discharge, and transfer (ADT) family. It is sent when a patient is admitted, most commonly as an inpatient, and it starts the encounter that later events update and close: A02 transfers, A08 updates, and A03 discharges. An A11 cancels an A01 entered in error. For the wider event family, see our HL7 ADT messages guide.

An A01 communicates an event, not a full clinical record. Receivers should treat it as an instruction to create or confirm a patient and open a visit, then rely on later events and other message types (orders, results, charges) for everything that follows.

Message Structure and Segments

An A01 is a pipe-delimited HL7 v2 message that always begins with MSH. The core segments are MSH, EVN, PID and PV1. Depending on the sender, it may also carry PD1, NK1 (next of kin), PV2, OBX, AL1 (allergies), DG1 (diagnoses), PR1, GT1 (guarantor), and IN1/IN2 (insurance). Which of these appear, and which fields are required, is defined by the HL7 version and the sender's interface profile, not by a universal template.

MSH: message header

MSH-9 identifies the message as ADT^A01 (with ADT_A01 as the message structure in v2.3.1 and later). MSH-10 is the unique control ID used to correlate acknowledgments and detect replays, and MSH-12 states the HL7 version.

EVN: event type

EVN-1 repeats the event code and EVN-2 records when the event was entered. EVN-2 can differ from MSH-7 (message creation) and PV1-44 (actual admit time), so keep the three meanings separate.

PID: patient identification

PID-3 can hold several identifiers, each with an assigning authority and identifier type. Map the full structure rather than extracting only the numeric MRN, especially across facilities that share an enterprise patient index.

PV1: patient visit

PV1 carries the encounter: PV1-2 patient class, PV1-3 assigned location, PV1-4 admission type, PV1-7 attending doctor, PV1-10 hospital service, PV1-19 visit number, and PV1-44 admit date/time. PV1-19 is the key that later A02, A03 and A08 messages should match.

HL7 ADT A01 Example

The message below is an illustrative A01 using synthetic data. Each segment starts on a new line (a carriage return in transmission).

MSH|^~\&|REG|HOSP|DOWNSTREAM|HOSP|20261012101600||ADT^A01^ADT_A01|MSGA01001|P|2.5
EVN|A01|20261012101600
PID|1||MRN1001^^^HOSP^MR||DOE^JANE||19850101|F|||100 MAIN ST^^CHICAGO^IL^60607
PV1||I|ICU^312^1|E|||1234^SMITH^JOHN^^^DR|||MED|||||||||VIS1001|||||||||||||||||||||||||20261012101500

Explore each segment and its key fields:

How to read this example:MSH-9 identifies the event; PID-3 supplies the patient identifier with its assigning authority; PV1 places the patient in ICU room 312, bed 1, under an attending physician, with visit number VIS1001. Empty PV1 fields are intentional placeholders, and the sample must be adapted to the sender's version-specific profile.

HL7 A01 Field Mapping

A field mapping turns the sender's HL7 positions into the receiver's data model. The table below shows a typical mapping for the sample message. Your specification should add data types, required/optional flags, code-set translations, and the behavior when a value is missing. Our HL7 parsing and data mapping team builds these specifications for production interfaces.

Healthcare Integration Workflow

In production, an A01 usually travels from the registration system over MLLP to an interface engine, which validates it, transforms it for each destination, and returns an acknowledgment. One admission can fan out to many systems, and each reacts differently. For implementation support, see our HL7 v2 integration services and HL7 interface messaging offerings.

• Bed management and census mark PV1-3 as occupied and add the patient to the unit census.
• Laboratory and radiology create the patient and visit so orders and results can attach to the right encounter.
• Pharmacy sets up the inpatient medication profile and dispensing location.
• Billing opens an inpatient account using PV1-19, guarantor and insurance segments.
• Care coordination and patient engagement tools send admission alerts to care teams or primary care providers.

Each receiver must decide whether the patient and visit already exist, translate facility-specific codes, apply the event, and only then acknowledge it. Design each destination independently, because a failure in one should not block the others.

Mirth Connect Implementation

Mirth Connect is a common engine for A01 feeds. A typical channel has four parts. Our Mirth Connect development services team builds and supports these channels in production.

1. Source: a TCP Listener using MLLP framing, with the inbound data type set to HL7 v2.x.
2. Filter: accept only the events this channel handles, for example MSH-9.2 equal to A01.
3. Transformer: map PID and PV1 fields to the destination format and translate code sets.
4. Destinations: one per receiving system (HTTP, database, file, or another MLLP sender), each with its own queue and retry settings.

A minimal filter and transformer step might look like this:

// Filter: only process A01 events
return msg['MSH']['MSH.9']['MSH.9.2'].toString() == 'A01';

// Transformer: pull key identifiers into channel variables
var mrn       = msg['PID']['PID.3'][0]['PID.3.1'].toString();
var authority = msg['PID']['PID.3'][0]['PID.3.4']['PID.3.4.1'].toString();
var visitId   = msg['PV1']['PV1.19']['PV1.19.1'].toString();

if (!visitId) {
  throw 'A01 missing PV1-19 visit number for MRN ' + mrn;
}

channelMap.put('mrn', mrn);
channelMap.put('authority', authority);
channelMap.put('visitId', visitId);

For production, configure the source to send its acknowledgment only after destinations have processed the message (rather than immediately on receipt), enable destination queuing so a downstream outage does not lose admissions, use MSH-10 or the visit number to prevent duplicates on replay, and set up alerts for errored messages and growing queues.

Integration Troubleshooting

Even a syntactically valid A01 can create the wrong state if identity, timing, or workflow rules are unclear. Investigate the actual payload and processing logs together, and protect patient data while you do. Our EHR/EMR integration services can help align the interface with source and destination behavior.

Missing visit number

A blank PV1-19 can make separate admissions look identical. Confirm the sender's encounter identifier policy, use an agreed alternate only when documented, and quarantine records that cannot be matched safely.

Duplicate patients

A repeated MRN with a different assigning authority may refer to a different identifier namespace. Preserve PID-3 components, validate the authority, and never merge patients automatically just because numeric identifiers match.

Rejected or negative acknowledgments

An AE or AR response usually points to an unknown location code, a missing required field, or a version mismatch. Read the MSA and ERR segments, fix the root cause, and replay the message rather than editing data by hand in the receiver.

Duplicate encounters from retries

Network timeouts can cause the sender to resend an A01 that was already processed. Use MSH-10 and PV1-19 to make processing idempotent, and distinguish an exact replay from a legitimate corrected admission.

Timestamp ambiguity

A local timestamp without an offset can shift admission chronology across systems. Agree on timezone conventions, keep original values, and test daylight-saving transitions.

HL7 ADT Event Comparison

A01 is one of several ADT events that share similar segments. Routing on the event code and validating against PV1-2 patient class keeps them from being confused.

The most common confusion is between A01 and A04. A01 represents an inpatient admission, while A04 is typically used for outpatient or emergency registration. When an emergency patient is later admitted, senders may send A06 (change outpatient to inpatient) or a new A01, so confirm which pattern your source system uses.

Security and Best Practices

A01 messages contain names, dates of birth, addresses, and identifiers, so every hop must be treated as PHI in transit. For a deeper look, read our guide to HIPAA-compliant HL7 integration.

• Encrypt transport. Plain MLLP is unencrypted; use MLLP over TLS or a site-to-site VPN between facilities.
• Limit access. Restrict who can view message content in the interface engine, and use least-privilege service accounts for destinations.
• Keep audit trails. Log who viewed, edited, or replayed a message, and retain logs according to policy.
• Protect error logs. Log control IDs and error codes rather than full payloads wherever possible, and purge message stores on a defined schedule.
• Test with synthetic data. Use de-identified or synthetic messages outside production.
• Monitor continuously. Alert on queue growth, negative acknowledgments, and sudden drops in A01 volume.

HIPAA obligations depend on your organization's role and use case; legal or compliance review may also be needed.

Get a practical integration estimate: Tell us the number of sending and receiving systems, expected daily message volume, whether you have an existing interface engine, and your acceptance criteria. Discuss your HL7 integration requirements.

Frequently Asked Questions About HL7 ADT A01