HL7 SIU messages carry scheduling information — the notifications that an appointment has been booked, rescheduled, modified, cancelled, or completed, together with the resources reserved for it. Where an ADT feed keeps every system aligned on the patient's administrative state, the SIU feed keeps them aligned on the patient's appointments. This page explains what an SIU message represents, when each trigger event fires, every segment the message can carry and what each one holds, and how an SIU message maps to a FHIR Bundle. Sample content is constructed for illustration with fictional identifiers.
What an SIU message represents
An SIU message communicates an unsolicited notification about a scheduled appointment. When a scheduling system books, moves, modifies, or cancels an appointment, it emits an SIU message describing the event, and downstream subscribers update their own view of the schedule. The message is unsolicited — the scheduling system pushes it as appointments change — which distinguishes SIU from the SRM schedule request that asks the scheduling system to act and the SRR response that answers it.
The core of the message is the SCH segment — the schedule activity information — which carries the appointment's placer and filler identifiers, its status, timing, duration, and reason. The resources reserved for the appointment follow in one or more repeating RESOURCES groups, each opened by an RGS resource group segment and populated by appointment-information segments: AIS for a service, AIG for a general resource, AIL for a location, and AIP for a person. The sender is the scheduling system; the receivers are the EHR, the department systems that own the reserved resources, billing, and any reminder or patient-portal system.
Every SIU message shares the same skeleton — an MSH header, an SCH schedule segment, an optional patient group, and one or more resource groups — and the trigger-event code in MSH-9 tells the receiver which scheduling event occurred.
When SIU messages are sent
SIU messages are sent the instant a scheduling event occurs, which makes the SIU feed a continuous real-time stream. A single appointment produces a sequence of related events over its lifetime: a booking, possibly a reschedule or a modification, and finally either a completion, a cancellation, or a no-show.
Common SIU messages
Each event reuses the SIU skeleton with the same segment structure; the trigger event in MSH-9 states what happened to the appointment. The S12 event — new appointment booking — is the one with a published FHIR Bundle map. The events an integration team handles most often:
SIU^S12– Notification of new appointment booking.SIU^S13– Notification of appointment rescheduling.SIU^S14– Notification of appointment modification.SIU^S15– Notification of appointment cancellation.SIU^S16– Notification of appointment discontinuation.SIU^S17– Notification of appointment deletion.SIU^S26– Notification that patient did not show up for scheduled appointment.
The event in MSH-9 drives the handling, and the v2-to-FHIR Implementation Guide publishes a Bundle map for SIU_S12. Treat cancellation, discontinuation, and no-show events as state transitions on an appointment you already hold rather than as new appointments.
Integration topology
The diagram shows the scheduling system broadcasting appointment events through the integration engine to every downstream subscriber.
{{diagram: scheduling system → SIU message → integration engine → EHR / department systems / billing / reminder & portal systems}}
Typical senders: enterprise scheduling system, department scheduling application, practice management system.
Typical receivers: EHR, department systems that own the reserved resources, billing, patient reminder and portal systems.
Direction: unidirectional broadcast from the scheduling source of truth to many subscribers.
Segments in an SIU message
The SIU_S12 message opens with the required MSH header and SCH schedule segment, followed by optional timing and notes, an optional repeating PATIENT group, and one or more required repeating RESOURCES groups. Cardinality follows HL7 notation: [X] optional, {X} repeating, [{X}] optional and repeating; a bare code is required. Each segment code links to its canonical field-by-field reference.
| Segment | Description |
|---|---|
MSH | Message Header. Opens every SIU message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (for example SIU^S12), carries the message control id in MSH-10, and pins the HL7 version. Receivers route on MSH-9 and deduplicate on MSH-10. |
SCH | Schedule Activity Information. The heart of the SIU message. It carries the placer appointment id in SCH-1 and the filler appointment id in SCH-2, the appointment reason and type, the appointment duration, the appointment timing in SCH-11, the placer and filler contact details, and the filler status code in SCH-25 that states whether the appointment is booked, rescheduled, cancelled, or complete. Required. |
[{TQ1}] | Timing/Quantity. Conveys the timing of the appointment where the newer timing representation is used alongside or in place of the SCH timing fields. Optional and repeating. |
[{NTE}] | Notes and Comments. Free-text notes about the appointment as a whole. Optional and repeating. |
[PID] | Patient Identification. Opens the optional PATIENT group and identifies the patient the appointment is for — the identifier list in PID-3, the name in PID-5, birth date in PID-7, and sex in PID-8. The PATIENT group is optional and repeating because a single scheduled activity can involve more than one patient. |
[PD1] | Patient Additional Demographic. Supplements PID within the PATIENT group with data such as the primary-care provider. Optional. |
[PV1] | Patient Visit. The visit context associated with the appointment within the PATIENT group — patient class and location. Optional. |
[PV2] | Patient Visit Additional. Companion to PV1 within the PATIENT group, carrying supplemental visit data such as the appointment reason. Optional. |
[{OBX}] | Observation/Result. Observations relevant to the appointment within the PATIENT group — for example a reason-for-visit observation or a pre-appointment measurement. Optional and repeating. |
[{DG1}] | Diagnosis. The diagnosis associated with the appointment within the PATIENT group, coded in ICD-10, SNOMED CT, or a local system. Optional and repeating. |
RGS | Resource Group. Opens each required RESOURCES group and identifies a group of resources reserved for the appointment, with the resource group id and an action code. Required, and the RESOURCES group repeats once per resource grouping. |
[AIS] | Appointment Information — Service. Within a RESOURCES group, describes a service being scheduled — the universal service identifier and its timing. Opens the optional repeating SERVICE subgroup; may carry its own repeating NTE. |
[AIG] | Appointment Information — General Resource. Within a RESOURCES group, describes a general resource reserved for the appointment — equipment, for example — with its type and timing. Opens the optional repeating GENERAL RESOURCE subgroup; may carry its own repeating NTE. |
[AIL] | Appointment Information — Location Resource. Within a RESOURCES group, describes a location reserved for the appointment — a room or clinic — with its location and timing. Opens the optional repeating LOCATION RESOURCE subgroup; may carry its own repeating NTE. |
[AIP] | Appointment Information — Personnel Resource. Within a RESOURCES group, describes a person reserved for the appointment — the provider or staff member — with their identity, role, and timing. Opens the optional repeating PERSONNEL RESOURCE subgroup; may carry its own repeating NTE. |
[ ] = optional, { } = repeating
The PATIENT group from PID through DG1 is optional and repeats; the RESOURCES group opens with a required RGS followed by any mix of the optional repeating SERVICE, GENERAL RESOURCE, LOCATION RESOURCE, and PERSONNEL RESOURCE subgroups, and each of those subgroups may carry its own repeating NTE. A single SIU message can therefore describe an appointment that reserves a service, a room, a piece of equipment, and a clinician together. The canonical segment pages carry the full field-by-field detail.
Sample SIU message
Note. Constructed for illustration. Patient identifiers, appointment ids, dates, and names are fictional.
MSH|^~&|SCHEDULING|MERCYGEN|EHR|MERCYGEN|202006151030||SIU^S12^SIU_S12|MSG00061|P|2.5.1
SCH|APPT10001^MERCYGEN|APPT10001^MERCYGEN|||CARDCONSULT^Cardiology Consult|OFFICE^Office Visit|OFFICE|30|MIN|^^30^202006201400^202006201430||||JONES^RICHARD^^^MD|||||JONES^RICHARD^^^MD|||||BOOKED
PID|1||MR98765^^^MERCYGEN^MR||SMITH^JANE^A||19651022|F|||123 OAK ST^^SPRINGFIELD^IL^62701
PV1|1|O|CARDCLINIC^^^MERCYGEN||||1234^JONES^RICHARD^^^MD
RGS|1|A
AIS|1|A|CARDCONSULT^Cardiology Consult^L|202006201400|||30|MIN
AIL|1|A|CARDCLINIC^^^MERCYGEN^^ROOM12||||202006201400|||30|MIN
AIP|1|A|1234^JONES^RICHARD^^^MD|CARD^Cardiologist^L||202006201400|||30|MIN
What this sample shows
The SIU^S12 in MSH-9 marks a new appointment booking. The SCH carries the placer and filler appointment ids APPT10001, a cardiology consult reason, a 30-minute duration, the appointment window starting 202006201400, and the filler status code BOOKED in SCH-25. PID identifies the patient as Jane Smith with medical record number MR98765, and PV1 gives the outpatient visit context. The single RESOURCES group opens with RGS, then reserves a service through AIS (the cardiology consult), a location through AIL (room 12 in the cardiology clinic), and a person through AIP (Dr. Jones as the cardiologist), all for the same 30-minute window.
Working with SIU messages
Identify the appointment and its status
The appointment's identity lives in the placer and filler ids in SCH (SCH-1 and SCH-2), and its state lives in the filler status code in SCH-25. Route on the trigger event in MSH-9 for the kind of change, but read SCH-25 for the resulting status — booked, rescheduled, cancelled, or complete — before applying the event to your own schedule.
Idempotency and deduplication
Use MSH-10, the message control id, as the deduplication key for the message, and treat the filler appointment id in SCH-2 as the natural business key for the appointment. Scheduling feeds are replayed after outages; a repeated filler appointment id should update the existing appointment rather than create a duplicate.
Model the appointment lifecycle
An appointment moves through a sequence of SIU events — a S12 booking, a S13 reschedule or S14 modification, and finally a S15 cancellation, S26 no-show, or completion. Apply each event as a transition on the appointment identified by its filler id rather than as an independent record, so the schedule reflects the current state and its history stays intact.
Reserved resources come in groups
Each RESOURCES group opens with an RGS and can reserve any mix of services, general resources, locations, and personnel through AIS, AIG, AIL, and AIP. Read all of the appointment-information segments within a group rather than assuming only one type is present, since a single appointment commonly reserves a provider, a room, and a service together.
Vendor variance. Scheduling systems differ in which appointment-information segments they populate and in how they express appointment timing — some use the
SCHtiming fields, others populateTQ1, and theAIxsegments each carry their own start-time and duration fields. Confirm a partner's field usage against their interface specification rather than assuming the base standard.
FHIR equivalent
An SIU message maps to a FHIR Bundle whose backbone is a MessageHeader plus the Appointment the event concerns. The v2-to-FHIR Implementation Guide derives the MessageHeader and Provenance from MSH, the Appointment from SCH and the appointment-information segments, the Patient from PID, and the Encounter from PV1, with optional ServiceRequest, Coverage, Observation, Condition, and Basic resources produced from the corresponding segments when present.
The Implementation Guide publishes an official Bundle map for SIU_S12; other SIU trigger events are composed from the per-segment maps.
| Trigger event | FHIR Bundle contents | Official IG map |
|---|---|---|
SIU_S12 | MessageHeader + Appointment + Patient + Encounter + Provenance (+ optional ServiceRequest, Coverage, Observation, Condition, Basic) | yes |
SIU_S13 | Compose from segment maps | no |
SIU_S15 | Compose from segment maps | no |
Common pitfalls
Pitfall. Reading the trigger event but ignoring
SCH-25. The trigger event inMSH-9states the kind of change, but the filler status code inSCH-25is the authoritative resulting status; a modification event, for example, can leave an appointment booked or move it to cancelled.
Pitfall. Treating a reschedule as a new appointment. A
S13reschedule carries the same filler appointment id inSCH-2as the original booking. Match on the filler id and update the existing appointment rather than creating a second one.
Pitfall. Reading only the first appointment-information segment in a RESOURCES group. A group can carry a service, a location, and a personnel resource together; parse every
AIS,AIG,AIL, andAIPin the group rather than stopping at the first.
How Vorro handles SIU messages
Vorro ingests the SIU feed over MLLP or another transport, deduplicates on MSH-10, routes by the trigger event in MSH-9, and fans each appointment event out to every subscribed destination in the format that system expects. Vorro reads the appointment identity and status from SCH, uses the filler appointment id in SCH-2 as the upsert key so a reschedule or modification updates the existing appointment rather than creating a duplicate, and reads the full set of reserved resources from each RESOURCES group. Where the v2-to-FHIR Implementation Guide provides a published map, Vorro emits the corresponding FHIR Bundle with its Appointment resource; for other events it composes the Bundle from the per-segment maps.
Related messages
- SRM — the schedule request message that asks the scheduling system to book, modify, or cancel an appointment.
- SRR — the scheduled request response that answers an SRM request.
- ADT — the patient administration feed that establishes the patient context an SIU appointment is booked against.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms the SIU_S12 message map
- HL7 v2-to-FHIR IG — SIU_S12 to Bundle ConceptMap
- HL7 Messaging Standard Version 2.5.1 product brief
