HL7 SRR_S01 (Schedule Request Response) | Integration Soup HL7 Reference Guide

HL7 SRR_S01 Schedule Request Response

The schedule owner answers a new appointment request.

HL7 message structure SRR_S01 groups and segments from HL7 v2.5.1 Hide structure

These are the generated groups and segments for the version selected at the top of the page. The article explains the workflow, and this panel follows the chosen HL7 version.

Message Structure

Segment	Name	Required	Repeatable
MSH	Message Header	Yes	No
MSA	Message Acknowledgment	Yes	No
ERR	Error	No	Yes
SRR_S01.SCHEDULE	Schedule group	No	No
SCH	Scheduling Activity Information	Yes	No
TQ1	Timing/Quantity	No	Yes
NTE	Notes and Comments	No	Yes
SRR_S01.PATIENT	Patient group	No	Yes
PID	Patient Identification	Yes	No
PV1	Patient Visit	No	No
PV2	Patient Visit - Additional Information	No	No
DG1	Diagnosis	No	Yes
SRR_S01.RESOURCES	Resources group	Yes	Yes
RGS	Resource Group	Yes	No
SRR_S01.SERVICE	Service group	No	Yes
AIS	Appointment Information	Yes	No
NTE	Notes and Comments	No	Yes
SRR_S01.GENERAL_RESOURCE	General Resource group	No	Yes
AIG	Appointment Information - General Resource	Yes	No
NTE	Notes and Comments	No	Yes
SRR_S01.LOCATION_RESOURCE	Location Resource group	No	Yes
AIL	Appointment Information - Location Resource	Yes	No
NTE	Notes and Comments	No	Yes
SRR_S01.PERSONNEL_RESOURCE	Personnel Resource group	No	Yes
AIP	Appointment Information - Personnel Resource	Yes	No
NTE	Notes and Comments	No	Yes

SRR_S01 is the response to an SRM_S01 request for a new appointment booking. It is more than a transport ACK. It tells the requester whether the scheduling application accepted the request and, when useful, returns the actual appointment details that were booked.

The response matters because appointment requests often negotiate with reality. The placer can ask for a time, service, room, and provider, but the filler owns the schedule. SRR is where the filler can say "yes, booked", "no, here is the error", or "accepted, but here are the identifiers and details you must use from now on."

A small SRR S01 example

MSH|^~\&|SCHED|CITYHOSP|REFERRAL|CITYHOSP|20260720101600||SRR^S01^SRR_S01|SRR00001|P|2.5.1 MSA|AA|SRM00001 SCH|REQ-20260720-001|FILL-883421||ROUTINE^Routine request^L|BOOKED|CARDREV^Cardiology review^L|30|min|^^^20260722101500^20260722104500|||||12345^Planner^Paula TQ1|1||||||20260722101500|20260722104500 PID|1||123456^^^CITYHOSP^MR||Smith^Jane^Anne^^Ms^^L||19800314|F PV1|1|O|CARD^ROOM2^^CITYHOSP RGS|1 AIS|1||CARDREV^Cardiology review^L|20260722101500|30|min AIL|1||CARD^ROOM2^^CITYHOSP|20260722101500|30|min AIP|1||12345^Careful^Clara|CARD^Cardiologist^L|20260722101500|30|min

What workflow it represents

The sender is the filler application, usually the system that owns the schedule. The receiver is the placer that sent the SRM request. If the request worked, the receiver should store the filler appointment identifier and the confirmed details. If it failed, the receiver should show or route the error instead of quietly assuming the appointment exists.

In many real interfaces, SRR is followed by an unsolicited SIU message such as SIU_S12. That can be helpful, but the two messages should not be treated as duplicates without a matching rule. SRR answers the request; SIU notifies interested systems of the schedule event.

How to read the structure

MSA carries the application acknowledgment code and echoes the request control ID. ERR can describe what went wrong when the filler could not book the appointment or could not understand the request.

When appointment detail is returned, the optional schedule group starts with SCH. TQ1 can add explicit timing, the patient group can return PID and visit context, and the resource group uses RGS, AIS, AIG, AIL, and AIP to show what was actually reserved.

Implementation traps

The biggest trap is throwing away the filler appointment ID. The placer appointment ID is useful for correlation, but future reschedule, modify, cancel, and delete requests often need the filler identifier returned by the scheduling owner.

Another trap is treating an AA in MSA as "all details are unchanged." The request may be accepted with a modified time, room, provider, or duration. If your workflow cannot handle alternatives, say that in the interface agreement instead of silently accepting surprises.

Reference notes

HL7 Chapter 10 says the successful S01 response may include appointment detail in SCH and related segments describing what was booked. The same chapter frames placer and filler applications as separate roles: the placer requests the schedule change and the filler controls the schedule.