HL7 SIU_S12 (New Appointment Booking) | Integration Soup HL7 Reference Guide

HL7 SIU_S12 New Appointment Booking

The scheduling system booked something, and everyone else needs to know.

HL7 message structure SIU_S12 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

Segment	Name	Required	Repeatable
MSH	Message Header	Yes	No
SCH	Scheduling Activity Information	Yes	No
TQ1	Timing/Quantity	No	Yes
NTE	Notes and Comments	No	Yes
SIU_S12.PATIENT	Patient group	No	Yes
PID	Patient Identification	Yes	No
PD1	Patient Additional Demographic	No	No
PV1	Patient Visit	No	No
PV2	Patient Visit - Additional Information	No	No
OBX	Observation/Result	No	Yes
DG1	Diagnosis	No	Yes
SIU_S12.RESOURCES	Resources group	Yes	Yes
RGS	Resource Group	Yes	No
SIU_S12.SERVICE	Service group	No	Yes
AIS	Appointment Information	Yes	No
NTE	Notes and Comments	No	Yes
SIU_S12.GENERAL_RESOURCE	General Resource group	No	Yes
AIG	Appointment Information - General Resource	Yes	No
NTE	Notes and Comments	No	Yes
SIU_S12.LOCATION_RESOURCE	Location Resource group	No	Yes
AIL	Appointment Information - Location Resource	Yes	No
NTE	Notes and Comments	No	Yes
SIU_S12.PERSONNEL_RESOURCE	Personnel Resource group	No	Yes
AIP	Appointment Information - Personnel Resource	Yes	No
NTE	Notes and Comments	No	Yes

SIU_S12 is the unsolicited scheduling message for a new appointment booking. A scheduling or filler application sends it to auxiliary systems so they can place the patient, service, location, personnel, and resources onto their own calendars, worklists, reminders, or preparation workflows.

The message is not just an appointment date. It has a schedule header, timing, patient context, and resource groups. A good SIU interface preserves the difference between what is being done, where it is happening, who is involved, and which general resources are needed.

A small SIU S12 example

MSH|^~\&|SCHED|CITYHOSP|EHR|CITYHOSP|20260715120000||SIU^S12^SIU_S12|SIU00042|P|2.5.1 SCH|A100045|F100045||ROUTINE^Routine appointment^L|NEW|OFFICE^Office visit^L|30|min|^^^20260718100000^20260718103000|||||12345^Careful^Clara PID|1||123456^^^CITYHOSP^MR||Smith^Jane^Anne^^Ms^^L||19800314|F|||12 High Street^^Auckland^^1010^NZ^H PV1|1|O|CARD^ROOM2^^CITYHOSP RGS|1 AIS|1||CARDREV^Cardiology review^L|20260718100000|30|min AIL|1||CARD^ROOM2^^CITYHOSP|20260718100000|30|min AIP|1||12345^Careful^Clara|CARD^Cardiologist^L|20260718100000|30|min

What workflow it represents

The sender is usually a scheduling system, departmental application, or EHR scheduling module. Receivers may include EHR worklists, reminder systems, modality systems, patient portals, call centers, integration engines, and analytics systems. The message says a new appointment exists on the filler schedule.

Most receivers respond with an ACK. That ACK should say whether the notification was received and understood, not whether the patient will actually attend.

How to read the structure

SCH is the appointment header. It carries appointment identifiers, reason, appointment type, duration, timing, status-ish context, and placer/filler references. TQ1 can add more timing detail when the profile uses it.

The patient group carries PID, optional PV1, observations, and diagnoses. The resources group starts with RGS, then can include service information in AIS, general resources in AIG, location resources in AIL, and personnel resources in AIP.

Implementation traps

Do not put every scheduling fact into SCH just because it is the first visible segment. Services, rooms, providers, equipment, and general resources each have their own place. Keeping those separate makes rescheduling and downstream calendar logic much easier.

Duration also needs agreement. Some senders use SCH duration, some use AIS/AIL/AIP durations, and some send both. If the appointment is 30 minutes in one segment and 45 in another, the receiver needs a rule or the users get conflicting calendars.

Reference notes

HL7 Chapter 10 describes scheduling notifications as unsolicited transactions from filler applications to auxiliary applications, with ACKs used for receipt or interface errors. See HL7 v2 Chapter 10 scheduling and practical SIU summaries such as iNTERFACEWARE's SIU overview.