HL7 SIU Messages Explained: Scheduling and Appointments

SIU stands for Scheduling Information Unsolicited. The "unsolicited" part matters: the scheduling system pushes these messages out when something changes, rather than waiting for anyone to ask. Book an appointment, move it, cancel it, mark the patient as arrived — each generates an SIU message to whoever needs to know.

Appointment data is deceptively simple. It is a time, a place, a patient and a clinician. What makes SIU interfaces difficult is that appointments change constantly, and every change has to land in the right order in every downstream system, or two systems end up confidently displaying different times for the same appointment.

The SIU event types

• S12 — new appointment booking.
• S13 — appointment rescheduling. Same appointment, different time.
• S14 — appointment modification. Something other than the time changed — the resource, the location, the reason.
• S15 — appointment cancellation. It is not happening.
• S17 — appointment deletion. It should never have existed.
• S26 — patient did not show.
• S22, S23, S24 and neighbours cover blocked time, resource-level scheduling and related events.

The distinction between S15 (cancelled) and S17 (deleted) trips people up constantly, and the difference matters downstream. A cancelled appointment happened as a booking and was then called off — it belongs in reporting, in did-not-attend statistics, in a clinician's history of the patient. A deleted appointment was a booking error and should leave no trace. Systems that treat both as "remove the row" quietly corrupt their own activity reporting.

The segments that carry the detail

• SCH — the schedule activity: appointment identifier, start time, duration, status, reason.
• PID — the patient.
• AIS — the service being provided.
• AIG — resources: equipment, rooms, general resources.
• AIL — the location.
• AIP — the personnel: which clinician or staff member.
• RGS — resource group, which organises the AIS/AIG/AIL/AIP segments that follow.

A single appointment message can carry multiple resource groups. A theatre booking involves a surgeon, an anaesthetist, a theatre, and equipment — and each appears as its own segment within the message.

Why appointment interfaces drift

Ordering, again. Appointments are rescheduled repeatedly, sometimes within seconds when a clerk is fixing a mistake. If two S13 messages arrive out of order, the downstream system lands on the older time and stays there — confidently, and with no error anywhere. Any SIU interface handling meaningful volume needs either strict per-appointment ordering or a timestamp comparison that rejects stale updates.

Missing the patient. SIU messages reference a patient who is expected to already exist, courtesy of the ADT feed. When a new patient is registered and booked in the same breath, the SIU can arrive before the ADT. The receiving system needs to hold the message and retry rather than reject it outright.

Appointment identifiers that are not stable. Some systems reissue the appointment identifier on reschedule. If that happens, the downstream system sees a cancellation and a new booking rather than a move — which may be acceptable, but only if it is a deliberate decision rather than something you discover from a duplicate in a clinic list.

No reconciliation. Appointments have a natural reconciliation point that most integrations never use: tomorrow's clinic list. Comparing what the source system says is booked against what the downstream system holds, once a day, catches drift long before a patient turns up to an appointment that one system has and the other does not.

Testing appointment interfaces safely

SIU is one of the interface types where testing against production is most tempting and most dangerous — the data is right there, and it changes constantly. It is also the fastest route to a real appointment being cancelled by a test harness. I have written about building safe integration test environments for ADT and SIU interfaces, and appointment interfaces are the reason that article exists.

FHIR represents this domain as Appointment, Schedule, Slot and AppointmentResponse, with a status element covering the booked, cancelled and no-show states directly. As with everything else in healthcare interoperability, the events are unchanged; only the envelope is different.

If your scheduling interface is drifting out of step, that is fixable.