HL7 ADT_A05 Pre-Admit a Patient

A visit is being prepared before the patient is actually admitted.
HL7 message structure ADT_A05 groups and segments from HL7 v2.5.1 Hide structure

These are the generated groups and segments for the version selected at the top of the page. The article explains the workflow, and this panel follows the chosen HL7 version.

Message Structure

SegmentNameRequiredRepeatable
MSH
 Message Header Yes No
SFT
 Software Segment No Yes
EVN
 Event Type Yes No
PID
 Patient Identification Yes No
PD1
 Patient Additional Demographic No No
ROL
 Role No Yes
NK1
 Next of Kin / Associated Parties No Yes
PV1
 Patient Visit Yes No
PV2
 Patient Visit - Additional Information No No
ROL
 Role No Yes
DB1
 Disability No Yes
OBX
 Observation/Result No Yes
AL1
 Patient Allergy Information No Yes
DG1
 Diagnosis No Yes
DRG
 Diagnosis Related Group No No
ADT_A05.PROCEDURE
 Procedure group No Yes
PR1
 Procedures Yes No
ROL
 Role No Yes
GT1
 Guarantor No Yes
ADT_A05.INSURANCE
 Insurance group No Yes
IN1
 Insurance Yes No
IN2
 Insurance Additional Information No No
IN3
 Insurance Additional Information, Certification No Yes
ROL
 Role No Yes
ACC
 Accident No No
UB1
 UB82 No No
UB2
 UB92 Data No No

ADT_A05 is used when the organization knows about an upcoming admission or visit and wants downstream systems to prepare for it. The patient is not yet admitted in the same sense as A01, but the administrative shell exists: identity, planned visit, expected location or service, insurance, guarantor, and sometimes diagnosis or procedure context.

This event is useful when systems need to stage information before the patient arrives. It can also be dangerous if receivers treat it exactly like an active admission. The interface agreement should be very clear about what "pre-admit" means operationally.

A small A05 example

MSH|^~\&|ADT|CITYHOSP|SURGERY|CITYHOSP|20260714113000||ADT^A05^ADT_A05|ADT00005|P|2.5.1 EVN|A05|20260714112500 PID|1||789012^^^CITYHOSP^MR||Ngata^Moana^^^^^L||19751102|F|||44 Harbour Road^^Auckland^^1011^NZ^H PV1|1|P|SURG^PREOP^^CITYHOSP||||67890^Plan^Peter|||||||||||VN000998^^^CITYHOSP^VN DG1|1||K80.20^Calculus of gallbladder without cholecystitis^I10|||A IN1|1|PLAN-B|INS002|Southern Care

What systems do with it

Scheduling, perioperative, billing, eligibility, bed planning, and clinical preparation systems may use A05 to create a pending visit. The patient record can be matched, insurance can be checked, and pre-arrival tasks can be started without saying the patient is already in a bed.

PID is still the patient anchor. PV1 usually carries patient class, planned location, planned attending provider, and visit number. If the visit number is later reused by A01, downstream matching becomes much easier.

Optional groups

The generated structure includes next of kin, allergy, diagnosis, procedure, guarantor, insurance, accident, and billing-oriented groups. Populate them only when the receiver will use them. A pre-admit feed stuffed with half-known demographics can cause more cleanup than help.

Insurance and guarantor data are common on A05 because eligibility and authorization workflows often happen before arrival. If those values are provisional, make that part of the receiving workflow rather than letting provisional data look final.

Implementation traps

The classic trap is an A05 that never becomes an A01 or never gets cancelled. Receivers need to know whether stale pre-admits expire, get cancelled by a specific event, or remain pending until a later update. Otherwise worklists slowly fill with planned visits that are no longer real.

Reference notes

HL7 ADT workflows distinguish pre-admission from admission so downstream systems can prepare without treating the patient as fully arrived. Local profiles decide whether pre-admits are visible on census, billing, scheduling, and clinical worklists.