An imaging exam gets scheduled long before a scanner ever sees a patient, and the message that carries that fact is HL7 SIU. SIU is short for Schedule Information Unsolicited, the HL7 Version 2 message family a scheduling system sends whenever an appointment changes: booked, rescheduled, modified, cancelled, or missed. For an imaging integration, HL7 SIU is not a peripheral message type. It is the one that decides whether a booked appointment ever turns into a study a scanner can acquire.
That is a specific claim worth being precise about. An SIU message does not talk to a scanner; it updates whatever system is keeping the schedule, typically a RIS or a broker in front of it. A separate DICOM mechanism is what a scanner queries later, and Where a Radiology Information System Ends and PACS Takes Over covers that seam directly. This piece stays on the HL7 side of it: what an SIU message contains, and what an integrator has to get right before that appointment is usable downstream.
HL7 SIU: Fifteen Trigger Events, Fourteen Sharing One Structure
HL7’s own trigger event table lists fifteen distinct SIU trigger events, covering a first booking, a blocked time slot, a no-show, and everything between. Fourteen of them, S12 through S24 plus S26, share one underlying message structure, SIU_S12. They also use the acknowledgment pattern HL7 v2 uses generally: the sender expects an ACK back.
That single structure matters. A new booking and a cancellation are not different message types with different fields. They are the same segments, carrying the same appointment identifiers, with a different trigger event in the header and a different status value inside the message itself. Get the event code wrong at the sending end, and a downstream system can misread a cancellation as an update, or the reverse.
The Trigger Events That Matter in Practice
Five events cover most of what an integrator has to handle in an imaging context.
- S12, new appointment booking. The appointment did not exist before this message. Prep instructions, resource reservations, and staffing all start from here.
- S13, appointment rescheduling. The same appointment moves to a new date or time. The appointment identifiers carried in the message stay the same; only the timing changes.
- S14, appointment modification. Something about the appointment changes without moving it: the resources booked, the reason for the visit, a note. The identifiers and the timing can both stay fixed.
- S15, appointment cancellation. The appointment is stopped before it happens. HL7’s filler status code table defines Cancelled as an appointment “stopped from occurring,” distinct from Deleted, which records the appointment as removed from the filler application entirely.
- S26, patient no-show. The slot came and went as booked, but the patient never arrived. This is a fact about attendance, not a change to the schedule itself.
The distinction between S13 and a cancel-then-rebook pair is worth sitting with, because it is where real integrations quietly diverge from the standard. A genuine reschedule carries the original placer and filler appointment identifiers forward. The receiving system matches it to the appointment it already knows about and simply updates the timing.
Send an S15 cancellation followed by a fresh S12 booking instead, and the receiving system sees two unrelated events: an appointment that ended and a new one that started. Nothing in the message says they are the same visit. Anything keyed off the appointment identifier (prep instructions already sent, a room already held) has to be torn down and rebuilt rather than adjusted in place.
SCH: The Segment That Carries the Appointment
Every SIU message, per HL7’s own message structure for SIU_S12, opens with MSH and then exactly one SCH segment: Schedule Activity Information. SCH is where the appointment itself lives.
SCH’s field list carries the identifiers that tie everything else to this one appointment. A Placer Appointment ID comes from the system that requested it; a Filler Appointment ID comes from the system that owns the schedule. It carries the appointment’s timing too: SCH-11, Appointment Timing Quantity, is a repeatable field built from a composite datatype that bundles start time and duration into each entry. And it carries the field that actually answers what state the appointment is in right now: Filler Status Code.
That status field does more work than it looks like. Filler Status Code sits on SCH separately from the trigger event carried in MSH, and every resource segment below carries its own copy of the same field. A well-built receiving system reads status directly off SCH-25, and off the matching field on AIS, AIG, AIL, and AIP, rather than inferring state purely from which trigger event arrived. A message that arrives out of order or gets replayed still carries an accurate status value on its own.
The Resource Segments: What Gets Reserved, Not Just When
An appointment is more than a time slot. It reserves things: a room, a piece of equipment, a staff member, and the procedure being performed. HL7 groups those into four repeatable segment types, wrapped together under a Resource Group segment, RGS, that ties them to one scheduled activity.
- AIS, Appointment Information, Service. The procedure or service being scheduled: the CT chest, the MRI with contrast, the study type itself.
- AIG, Appointment Information, General Resource. Equipment. AIG’s field list carries a Resource ID and a Resource Type: the scanner or device being reserved for this slot.
- AIL, Appointment Information, Location Resource. The room. AIL carries a Location Resource ID identifying where the appointment happens.
- AIP, Appointment Information, Personnel Resource. Staff. AIP carries a Personnel Resource ID and Resource Type, covering the technologist, the reading radiologist, or anyone else the appointment books time from.
Each of these four segment types repeats independently and can appear multiple times in one message: an appointment can book two pieces of equipment or two staff members inside the same RGS group. And each one carries its own Filler Status Code, separate from SCH’s. A room can be released while the appointment itself stays booked, or a piece of equipment can be swapped without touching the timing at all. Status lives at the level of the thing being reserved, separately from the appointment itself.
Where SIU’s Job Ends
An HL7 SIU message updates a scheduling system, typically the RIS or a broker sitting in front of it. It does not update a scanner, and it is not what a scanner reads to know what to acquire next.
The device-facing side of scheduling runs on a separate mechanism entirely: the DICOM Modality Worklist service. DICOM’s own documentation describes it as a service that “provides a list of imaging procedures that have been scheduled for performance by an image acquisition device.” A CT scanner or other modality “queries a service provider, such as a RIS, to get this information.” HL7 never reaches that far; its job stops at getting the appointment into the RIS, in a state the RIS can later expose over DICOM.
That handoff is why the resource segments matter beyond bookkeeping. The room, device, and staff identifiers an SIU message carries have to reconcile with what the RIS later exposes through its Modality Worklist service. Eventually they have to reconcile with how the modality itself identifies its own equipment. A mismatch anywhere in that chain surfaces as a worklist entry the scanner cannot match to itself, not as an HL7 error.
Failure Modes an Integrator Actually Meets
Three specific patterns account for most of the real-world trouble on the HL7 side of scheduling.
A Cancellation That Never Arrives
If an S15 message is lost, never sent, or fails silently at the receiving end, the schedule keeps showing a booked appointment the source system has already dropped. The room, device, and staff time stay reserved against a study that will never happen. Acknowledgment handling on every SIU message, not just the ones that look important, is what catches this before it becomes a staffing or capacity problem.
A Reschedule Delivered as a Second Booking
Covered above as a modeling distinction, this shows up constantly as an implementation bug. A sending system that cannot cleanly represent “this appointment moved” falls back to cancelling and rebooking instead. The receiving system has no way to tell the two events were meant to be one continuous appointment unless the same appointment identifiers carry across both messages.
A Resource Identifier That Does Not Match the Modality
AIG’s Resource ID has to correspond to something the RIS, and eventually the DICOM side, recognizes as that specific scanner. If the scheduling system’s resource catalog and the modality’s own station identity drift apart, an integration can look correct at the HL7 layer. It can still produce a worklist entry that never resolves to the right device.
None of these three surface as an obvious error message. They surface as a schedule that looks fine and an acquisition workflow that quietly does not match it.
Evaluating an SIU Feed Before You Build On It
Evaluating an SIU feed, whether it originates from a hospital’s enterprise scheduling system, a standalone ambulatory scheduling platform, or the RIS itself, comes down to a short list of concrete questions. Does the sender use S13 for a true reschedule, or does it fall back to cancel-and-rebook? Does the receiving RIS act on Filler Status Code directly, or does it infer status from trigger events alone? Do the resource identifiers in AIG, AIL, and AIP match a catalog the RIS and the modality both recognize?
A vendor who can answer those with a specific mechanism, not a general assurance, has actually tested the seam between HL7 and the modality worklist.
HL7 messaging, including SIU, is not part of the integration surface EBM mAIn PACS® offers in this market today. Its supported surface is deliberately the DICOM side: native Modality Worklist, C-STORE, Query/Retrieve and Storage Commitment. Modality Worklist is the one that meets the RIS, or the broker in front of it, once an appointment like this has already landed. Getting an SIU feed right is what makes that worklist entry trustworthy in the first place, before EBM’s side of the pipeline is ever reached.
For a partner, that split is the useful part. The scheduling feed stays theirs to own and test, S13 semantics and resource catalog included. From the worklist entry onward, the four services named above are the documented surface they build to. Taking that to market under their own brand is what EBM Fabric™ is for.