HL7 ADT_A06 Change an Outpatient to an Inpatient

The encounter was already open, but the patient is now admitted.
HL7 message structure ADT_A06 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
MRG
 Merge Patient Information No No
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_A06.PROCEDURE
 Procedure group No Yes
PR1
 Procedures Yes No
ROL
 Role No Yes
GT1
 Guarantor No Yes
ADT_A06.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_A06 is sent when a patient who arrived as a non-admitted outpatient becomes an inpatient after clinical evaluation. It is not a fresh registration and it is not a normal transfer. The business fact is that the same patient encounter has crossed the line from outpatient handling into admitted inpatient handling.

Downstream systems usually care because patient class, bed status, charging, medication workflows, order routing, and census reporting may all change at once. If the receiver treats A06 like a new A01 admission, it may duplicate the visit. If it ignores the event, it may keep the patient in outpatient work queues long after the ward has taken over.

A small A06 example

MSH|^~\&|ADT|CITYHOSP|EHR|CITYHOSP|20260715114500||ADT^A06^ADT_A06|ADT060001|P|2.5.1 EVN|A06|20260715114300 PID|1||123456^^^CITYHOSP^MR||Smith^Jane^Anne^^Ms^^L||19800314|F PV1|1|I|WARD3^301^1^CITYHOSP^^BED|||EDOBS^12^1^CITYHOSP^^ROOM|12345^Ng^Grace|||||||||||VN000789^^^CITYHOSP^VN

What systems do with it

The sender is usually the PAS, registration system, or enterprise EHR. Receivers update the active visit from outpatient to inpatient, change the current location, adjust census state, and often switch order, pharmacy, billing, and notification rules to admitted-patient behavior.

The important fields are practical ones: PV1-2 for patient class, PV1-3 for the new assigned location, PV1-6 for the prior location when it matters, and visit/account identifiers in PV1 and PID.

How to read the structure

The backbone is MSH, EVN, PID, and PV1. ADT_A06 also allows the richer admission-style optional groups: next of kin, allergies, diagnoses, procedures, guarantor, insurance, accident, and UB billing data.

The optional MRG segment can appear when the account number changes during the outpatient-to-inpatient conversion. That does not make the message a patient merge. In this workflow MRG is only there to carry prior account context when local systems negotiated it.

Implementation traps

The classic mistake is to create a second visit. Match the message to the existing outpatient visit first, then update class, location, and account state as your profile requires. Another common mistake is sending every demographic correction inside A06. If patient demographics changed too, send or expect a proper A08 update alongside this event.

Reference notes

The HL7 v2+ ADT_A06 page describes the event as changing a patient's status from non-admitted to admitted, with the new class in PV1-2, new location in PV1-3, and old location in PV1-6 when different.