Scheduling with SIU

Why a scheduling message family exists

Appointments are rarely managed in only one system. A scheduling system of record holds the master calendar, but a department application, a patient-reminder service, or a billing feed each needs to know when an appointment is booked, moved, or dropped. The SIU (Scheduling Information Unsolicited) message family carries those events so downstream systems stay in step with the booking system. The pattern mirrors ADT: just as ADT keeps systems synchronized with admitting, SIU keeps them synchronized with scheduling ¹.

Trigger events

Like other v2 families, SIU uses the trigger-event model, with the event encoded in MSH-9. The most useful events are:

• S12 — notification of a new appointment booking.
• S13 — notification of an appointment rescheduling.
• S14 — notification of an appointment modification (a change other than time, such as a different resource or note).
• S15 — notification of an appointment cancellation.
• S17 — notification of an appointment deletion.
• S26 — notification that a patient did not show.

The family defines further events (for example, around appointment blocks and discontinuations), but these cover the common booking lifecycle ².

The core segments

Every SIU message centers on one SCH segment, the schedule activity for the appointment as a whole. SCH carries the placer and filler appointment identifiers, the appointment timing (start, end, and duration), and the appointment status (for example, booked or cancelled). It answers “which appointment, when, and in what state.”

Around SCH, resource and participant segments describe what the appointment consumes. Each typically pairs with its own timing information:

• AIS — appointment information for a service (the procedure or service code being scheduled).
• AIG — a general resource such as equipment.
• AIL — a location, such as a room or clinic.
• AIP — personnel, such as the attending clinician or technician.

A message includes whichever of these apply. A simple clinic visit may need only AIL and AIP; an imaging study might add AIG for the scanner and AIS for the procedure.

A SIU^S12 skeleton

The example below shows a new-appointment notification. PID identifies the patient; the AI* segments name the location and the personnel.

MSH|^~\&|SCHED|HOSPITAL|REMINDERS|HOSPITAL|20260601090000||SIU^S12|MSG0001|P|2.5.1
SCH|A12345^SCHED|F67890^SCHED|||||OFFICE^Office visit|||30^MIN|^^^20260610130000^20260610133000|||||DOE^JANE||||DOE^JANE
PID|1||100200300^^^HOSPITAL^MR||DOE^JANE||19850214|F
AIL|1||CLINIC3^Clinic 3 Room 4^HOSPITAL||||20260610130000|30^MIN
AIP|1||9988^SMITH^ALAN^^^DR|D^Attending|||20260610130000|30^MIN

Reading the key fields: MSH-9 (SIU^S12) sets the event. In SCH, the first two fields are the placer and filler appointment IDs, SCH-7 names the appointment reason and SCH-8 the appointment type, SCH-9 the duration with units, and SCH-11 the appointment timing (the start/end span). PID anchors the message to one patient. AIL identifies the location resource and repeats the start time and duration so a location-oriented system can act on its own; AIP does the same for the clinician, with the second field describing that person’s role.

Operational stakes

The booking event (S12) is the easy part; the lifecycle events carry the real operational weight. If an S13 reschedule or an S15 cancel is lost, the downstream calendar holds a slot the source system has already freed or moved. Stale schedules then cause double-booking, no-shows against appointments that no longer exist, and reminders sent for the wrong time. Because SIU messages are unsolicited notifications rather than queries, the downstream system cannot tell on its own that it missed one, so reliable delivery and acknowledgment of every change event matter as much as the initial booking ².