SIU messages carry scheduling information in HL7 v2, telling downstream systems when appointments are booked, changed, cancelled or missed. SIU^S12, the notification of a new appointment booking, is the most common. Reminder platforms, telehealth tools, transport services, analytics systems and departmental applications all rely on SIU feeds to stay synchronized with the scheduling system. This guide explains SIU event types, message structure, key segments, a full example and best practices for reliable scheduling interfaces. For the wider picture of message types, see our HL7 message types and event types guide. Building a scheduling feed? Request a free HL7 interface review.
What SIU Messages Are Used For
SIU stands for Schedule Information Unsolicited. The scheduling system pushes appointment events to subscribers as they happen, without subscribers requesting them. This keeps many connected systems aligned with one source of truth for appointments across a hospital or clinic network.
Appointment reminders
Reminder vendors subscribe to SIU feeds to send texts, calls and emails before visits. New bookings, reschedules and cancellations all trigger updates. Our patient no-show reduction software work shows how accurate scheduling feeds improve reminder effectiveness. Missed updates quickly erode patient trust.
Telehealth and virtual visits
Telehealth platforms use SIU messages to create virtual visit sessions, send join links and track appointment status. Accurate appointment types and provider details ensure patients and clinicians land in the right session at the right time. Test virtual visit types carefully.
Departmental and resource systems
Departments such as imaging, therapy and surgery use SIU feeds to prepare rooms, equipment and staff. Resource segments in SIU messages describe locations, personnel and equipment, letting downstream systems plan capacity without duplicating scheduling work. Accurate resource data prevents double booking.
Analytics and operations
Operations teams analyze scheduling events to measure access, utilization, cancellations and no-shows. SIU feeds provide timely data for dashboards, complementing reporting databases that update less frequently. Consistent event handling is essential for accurate operational metrics. Validate counts against reporting data.
Common SIU Event Types
SIU uses different trigger events for different scheduling actions. Receivers must handle each correctly, because a cancellation processed as a new booking, or a reschedule ignored, quickly creates confusion for patients and staff relying on downstream systems.
S12: new appointment booking
S12 notifies subscribers that a new appointment was booked. Receivers create the appointment, linking it to the patient, provider, location and appointment type. Most scheduling integrations start by handling S12 correctly before adding other events. Validate every required field on arrival.
S13 and S14: reschedules and modifications
S13 notifies that an appointment was rescheduled to a new time. S14 notifies that appointment details were modified without rescheduling. Receivers must update the existing appointment, identified by its appointment ID, rather than creating a duplicate entry. Test both events carefully.
S15 and S17: cancellations and deletions
S15 notifies that an appointment was cancelled, while S17 indicates deletion. Receivers must remove or mark appointments accordingly and stop related actions, such as reminders. Missing cancellations cause patients to receive reminders for visits that no longer exist. Test both events.
S26: no-shows
S26 notifies that the patient did not arrive for the appointment. Analytics and outreach systems use this event to measure no-show rates and trigger follow-up. Not every scheduling system sends S26, so confirm availability with each source. Plan alternatives where needed.
SIU^S12 Message Structure
SIU messages begin with scheduling details in SCH, followed by optional patient information and one or more resource groups. Resource groups describe the services, people, locations and equipment involved in the appointment, which downstream systems need for planning.
| Segment | Name | Usage | Purpose |
| MSH | Message Header | Required | Sender, receiver, message type, version |
| SCH | Scheduling Activity Information | Required | Appointment IDs, reason, type, status |
| TQ1 | Timing/Quantity | Optional, repeating | Appointment timing in newer versions |
| NTE | Notes and Comments | Optional, repeating | Appointment notes |
| PID | Patient Identification | Optional in base, usually required | Patient identifiers and demographics |
| PV1 | Patient Visit | Optional | Visit context |
| DG1 | Diagnosis | Optional, repeating | Reason-related diagnoses |
| RGS | Resource Group | Required, repeating | Starts each resource group |
| AIS | Appointment Information – Service | Optional | Service or procedure booked |
| AIG | Appointment Information – General Resource | Optional | Equipment or other resources |
| AIL | Appointment Information – Location | Optional | Room or location |
| AIP | Appointment Information – Personnel | Optional | Provider or staff |
Key Segments Explained
Most scheduling interface issues involve SCH and the appointment information segments. Getting appointment identifiers, timing, status and resources right covers most real-world integration work and prevents duplicate or orphaned appointments in downstream systems.
SCH: the appointment itself
SCH carries placer and filler appointment IDs, event reason, appointment reason, appointment type, duration and filler status. Receivers use appointment IDs to link later updates and cancellations to the original booking, so these identifiers must remain stable. Validate IDs on every message.
Timing: SCH-11 versus TQ1
Older interfaces carry appointment timing in SCH-11, using the timing/quantity data type. Newer versions move timing to TQ1 and retain SCH-11 for backward compatibility. Confirm which approach each source uses, because parsing the wrong field produces incorrect appointment times. Test both formats.
AIP and AIL: who and where
AIP identifies the provider or staff member for the appointment, while AIL identifies the location, such as a clinic room or virtual visit. Downstream systems rely on these to route reminders, prepare rooms and assign telehealth sessions correctly. Validate resource codes regularly.
AIS: what service
AIS describes the service or procedure booked, often with start times and durations for multi-step appointments. Departments use it to prepare for specific procedures. Map service codes consistently, because local codes vary widely between scheduling systems. Document mappings for every scheduling source.
PID: which patient
PID identifies the patient with identifiers and demographics. Receivers match appointments to patients through identifiers with assigning authorities. Validate PID on every message, because scheduling feeds often reach systems that also receive ADT and must stay consistent. Consistency across feeds prevents duplicates.
Example SIU^S12 Message
The example below shows a new 30-minute follow-up appointment with patient, provider and location details. Data is fictional. Segments are separated by carriage returns in real messages. Use examples like this to validate parsing before connecting live systems.
MSH|^~\&|SCHED|HOSP|REMIND|VENDOR|20261016100000||SIU^S12^SIU_S12|MSG00003|P|2.5.1
SCH||APT1001^HOSP_SCHED|||||ROUTINE^Routine follow-up|FOLLOWUP^Follow-up|30|MIN|^^^20261020093000^20261020100000||||||||||||||Booked
PID|1||MRN123456^^^HOSP^MR||Doe^Jane^Marie||19850214|F
RGS|1
AIP|1||1234567890^Smith^John^A^^^MD
AIL|1||CLINIC1^^^HOSP
Reading the header and appointment
MSH shows the scheduling system sending to a reminder vendor, message type SIU^S12 and version 2.5.1. SCH-2 holds filler appointment ID APT1001. SCH-7 and SCH-8 give reason and type, SCH-9 and SCH-10 a 30-minute duration. Each value sits exactly where receivers expect it.
Reading timing and status
SCH-11 carries start and end times in its fourth and fifth components, here 9:30 to 10:00 on October 20. SCH-25 shows the filler status Booked. Newer interfaces may carry timing in TQ1 instead. Confirm which approach your source uses before parsing.
Reading patient and resources
PID identifies the patient by MRN with assigning authority. RGS starts the resource group, AIP identifies the provider and AIL the location CLINIC1. Downstream systems use these resources to route reminders and prepare for the visit. Validate each resource code during testing.
Implementation Best Practices
Reliable scheduling interfaces depend on stable identifiers, complete event handling and careful timing logic. These practices reflect lessons from building scheduling feeds for reminder platforms, telehealth companies and hospital departments.
Handle every event type
Support new bookings, reschedules, modifications, cancellations and deletions from the start. Interfaces handling only S12 quickly accumulate stale appointments. Test each event with the source system, confirming identifiers link updates to the original booking correctly. Document expected behavior for each event.
Manage time zones carefully
Appointment times may arrive with or without time zone offsets. Agree on conventions with every source, especially for organizations spanning several time zones or offering virtual visits. Wrong time handling sends patients reminders for incorrect times. Test daylight saving transitions too.
Process messages in order
Scheduling updates must apply in sequence. If a cancellation arrives before its booking due to retries or parallel processing, receivers may create orphaned appointments. Use ordered queues and timestamps to process events correctly. Log ordering issues for later review. Test with retries.
Monitor and reconcile
Monitor message volumes, errors and acknowledgments, and periodically reconcile downstream appointments with the scheduling system. Reconciliation catches missed messages early. Our HL7 integration services include monitoring for scheduling feeds. Weekly reconciliation reports work well for most organizations and catch silent failures early.
How Taction Helps With Scheduling Interfaces
Taction has delivered 200+ healthcare projects, including scheduling feeds, reminder integrations and telehealth platforms. We help organizations build SIU interfaces that keep every connected system aligned with the scheduling source of truth.
Free HL7 interface review
Share sample SIU messages and partner specifications. We review event handling, identifiers, timing and resources, then flag risks and fixes. You get clear, prioritized recommendations. Request your free review. We also flag quick fixes you can apply immediately to reduce stale or duplicate appointments.
Scheduling interface development
We build SIU feeds through integration engines with validation, ordering, acknowledgments and monitoring. Every interface handles the full appointment lifecycle, preventing stale or duplicate appointments in downstream reminder, telehealth and departmental systems. Each interface is documented for your support team and monitored after go-live.
Scheduling platforms
When organizations need more than feeds, we build scheduling experiences that integrate with EHRs. Explore our appointment scheduling platform solutions for patient self-scheduling and capacity management. Each platform is designed with patients and staff, tested for accessibility and connected securely to your EHR scheduling system.
HL7 engineers on demand
Need experienced interface engineers? Hire HL7 integration engineers who understand scheduling workflows, SIU events and engine development. They join your team quickly and document every interface thoroughly. Engagements scale with your roadmap, from a single scheduling feed to support across many connected systems and partners.
Frequently Asked Questions
These answers cover common questions about HL7 SIU messages. Because scheduling systems and partners add rules beyond the base standard, always confirm requirements with the specifications for your specific interface.
What is an SIU^S12 message?
SIU^S12 is the HL7 v2 notification of a new appointment booking. The scheduling system sends it to subscribers such as reminder platforms, telehealth tools and departmental systems so they can create the appointment and prepare for the visit. Most scheduling feeds use it.
What do SIU S13, S14 and S15 mean?
S13 notifies that an appointment was rescheduled, S14 that appointment details were modified, and S15 that an appointment was cancelled. Receivers must update or cancel the existing appointment using its identifier rather than creating duplicates. Test each event with every source.
Which segments are in an SIU message?
SIU messages include MSH and SCH, optional TQ1, NTE, PID, PV1 and DG1, and one or more resource groups starting with RGS. Resource groups contain AIS, AIG, AIL and AIP segments describing services, equipment, locations and personnel. Partners often add requirements.
Where is the appointment time in SIU?
Older interfaces carry appointment timing in SCH-11, while newer versions use the TQ1 segment and retain SCH-11 for backward compatibility. Confirm which approach each scheduling source uses before building parsers and mappings. Test both formats carefully during interface development and validation.
Does every system send no-show events?
No. S26 notifies that a patient did not show, but not every scheduling system sends it. Confirm availability with each source. When unavailable, organizations sometimes infer no-shows from visit status in other feeds or reporting data. Confirm this early in planning.