HL7 SRR messages carry the filler system's answer to an SRM schedule request — confirming a new booking, accepting a reschedule, acknowledging a cancellation, or rejecting the request with an error. SRR is the response half of HL7 scheduling: a placer application sends an SRM, and the filler that owns the schedule answers with an SRR that either accepts the request and carries the filler-assigned appointment details in the SCH segment, or refuses it with an error in the ERR segment. This page explains what an SRR message represents, the trigger events it carries, every segment the message can contain and what each one holds, and how a schedule request response relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What an SRR message represents
An SRR message — SRR stands for Schedule Request Response — communicates the filler application's decision on a schedule request. The placer asked for something to be done to an appointment through an SRM; the SRR tells the placer whether the filler accepted or rejected that request. When the filler accepts a new booking, the SRR carries the SCH segment — Scheduling Activity Information — which is the key segment the SRR adds over the SRM structure. The SCH delivers the filler-assigned appointment identifier, the appointment reason, type, and duration as the filler has recorded them, and the confirmed start and end datetimes, making it the authoritative record of what was actually booked.
The sender is always the filler application that controls the schedule; the receiver is the placer that originated the SRM request. The SRR is a point-to-point response, not a broadcast: other systems learn about the resulting schedule change through SIU unsolicited notifications that the filler emits separately. Because the filler owns the schedule, an SRR that carries an SCH — not the original SRM request — is the authoritative confirmation of what is booked.
When an SRR message is sent
An SRR message is sent every time a filler application processes an SRM request. There is one SRR for every SRM — the trigger event code in the SRR MSH-9 mirrors the code from the originating SRM, so the placer can match each response to its request. The filler sends the SRR whether it accepts or rejects the request; a rejection carries an MSA application acknowledgement code of AE or AR and an ERR segment with the reason, while an acceptance carries a MSA code of AA and, for events that result in a booked state, the full SCHEDULE group with the SCH and resources.
Trigger events
All SRR trigger events share one message structure; the event code in MSH-9 mirrors the originating SRM trigger. HL7 v2.5.1 defines eleven SRR trigger events, one for each SRM counterpart:
SRR^S01– Response to request for new appointment booking.SRR^S02– Response to request for appointment rescheduling.SRR^S03– Response to request for appointment modification.SRR^S04– Response to request for appointment cancellation.SRR^S05– Response to request for appointment discontinuation.SRR^S06– Response to request for appointment deletion.SRR^S07– Response to request for addition of service/resource on appointment.SRR^S08– Response to request for modification of service/resource on appointment.SRR^S09– Response to request for cancellation of service/resource on appointment.SRR^S10– Response to request for discontinuation of service/resource on appointment.SRR^S11– Response to request for deletion of service/resource on appointment.
The receiver's handling turns on the event code in MSH-9 and the acknowledgement code in MSA-1 — together they indicate which request the filler is answering and whether it was accepted or refused.
Integration topology
The diagram shows the filler application returning an SRR response through the integration engine to the placer that originated the SRM request.
{{diagram: placer application → SRM request → filler system → SRR response → integration engine → placer application; filler also emits SIU notifications to subscribers}}
Typical senders: the schedule filler application that owns the resource calendar — a radiology scheduler, surgical scheduler, clinic scheduling system, or enterprise scheduling platform.
Typical receivers: the ordering or clinical application, referral and registration system, or any placer that sent the originating SRM request.
Direction: a point-to-point response from the filler back to the placer. The filler also broadcasts SIU notifications to inform other subscribers of the resulting schedule change, but those are separate messages.
Segments in an SRR message
The SRR message opens with the header, an MSA application acknowledgement, and optional error segments. When the filler accepts a request that results in a booked appointment, the message continues with an optional SCHEDULE group: the SCH scheduling activity segment, followed by optional timing, notes, and role segments, and then one or more RESOURCES groups — each introduced by RGS and containing optional service, general-resource, location-resource, and personnel-resource subgroups. 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 SRR message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (for example SRR^S01^SRR_S01), carries the message control id in MSH-10, and pins the HL7 version. The trigger event mirrors the corresponding SRM event so the placer can match the response to its request. |
MSA | Message Acknowledgement. Required. Carries the acknowledgement code in MSA-1 — AA for application accept, AE for application error, AR for application reject — and the message control id from the originating SRM in MSA-2, which the placer uses to correlate the response with the request. |
[{ERR}] | Error. Present when the filler rejects or partially rejects the request. Carries the error code, the location of the error within the original message, the severity, and a human-readable description. Optional and repeating to allow the filler to report multiple error conditions. |
[SCH] | Scheduling Activity Information. The defining segment of the SRR and the key segment the response adds over the request structure. Present when the filler accepts a request that results in or modifies a booked appointment. It carries the filler-assigned appointment id in SCH-2 (the authoritative booking identifier the placer must record), the appointment reason in SCH-6, the appointment type in SCH-7, the appointment duration and units in SCH-9 and SCH-10, the confirmed appointment start datetime in SCH-11, the appointment end datetime in SCH-12, and the occurrence count in SCH-16. The SCH segment is absent when the filler rejects the request. |
[{TQ1}] | Timing/Quantity. The dosing or scheduling timing for the appointment as the filler has confirmed it. Optional and repeating; within the SCHEDULE group. |
[{NTE}] | Notes and Comments. Free-text notes from the filler that apply to the appointment as a whole. Optional and repeating; within the SCHEDULE group. |
[{ROL}] | Role. Identifies a person playing a specific role in relation to the scheduled appointment — for example the ordering provider, the attending physician, or the scheduler. Optional and repeating; within the SCHEDULE group. |
RGS | Resource Group. Opens each RESOURCES group and identifies relationships between the resources for the scheduled event. It carries the set id in RGS-1, a segment action code in RGS-2 (conditionally required for the modify-style events), and a resource group id in RGS-3. Required and repeating within the SCHEDULE group — at least one RGS appears when a SCHEDULE group is present. |
[{AIS}] | Appointment Information – Service. Opens the optional SERVICE subgroup and describes a schedulable service as the filler has confirmed it — the universal service identifier, the start time and duration offset, the allow-substitution code, and the filler status code. Required within the SERVICE subgroup; the subgroup is optional and repeating. |
[{NTE}] | Notes and Comments. Notes scoped to the service in the preceding AIS. Optional and repeating, within the SERVICE subgroup. |
[{AIG}] | Appointment Information – General Resource. Opens the optional GENERAL_RESOURCE subgroup and describes a resource other than service, location, or personnel — typically equipment — by resource id in AIG-3, resource type in AIG-4, and resource quantity in AIG-6, as confirmed by the filler. Required within the subgroup; the subgroup is optional and repeating. |
[{NTE}] | Notes and Comments. Notes scoped to the general resource in the preceding AIG. Optional and repeating, within the GENERAL_RESOURCE subgroup. |
[{AIL}] | Appointment Information – Location Resource. Opens the optional LOCATION_RESOURCE subgroup and describes a location assigned by the filler — a meeting room, operating room, or examination room — by location resource id in AIL-3 and location type in AIL-4. Required within the subgroup; the subgroup is optional and repeating. |
[{NTE}] | Notes and Comments. Notes scoped to the location resource in the preceding AIL. Optional and repeating, within the LOCATION_RESOURCE subgroup. |
[{AIP}] | Appointment Information – Personnel Resource. Opens the optional PERSONNEL_RESOURCE subgroup and describes a person assigned by the filler — a technician, physician, nurse, or surgeon — by personnel id in AIP-3 or a resource type in AIP-4. Required within the subgroup; the subgroup is optional and repeating. |
[{NTE}] | Notes and Comments. Notes scoped to the personnel resource in the preceding AIP. Optional and repeating, within the PERSONNEL_RESOURCE subgroup. |
[ ] = optional, { } = repeating
The SCHEDULE group — from SCH through the last RESOURCES group — is absent when the filler rejects the request; when present, the RESOURCES group from RGS onward repeats, and within it each of the four appointment-information subgroups (service, general resource, location resource, personnel resource) is optional and repeating. The canonical segment pages carry the full field-by-field detail.
Sample SRR message
Note. Constructed for illustration. Patient identifiers, appointment ids, dates, and names are fictional.
MSH|^~&|RADIOLOGY|MERCYGEN|SCHEDULER|MERCYGEN|202006150901||SRR^S01^SRR_S01|MSG00022|P|2.5.1
MSA|AA|MSG00021
SCH|APPT1001^SCHEDULER|FILL9901^RADIOLOGY||||||ROUTINE^Routine^L|71020^Chest X-ray^C4|FOLLOWUP^Follow-up^L|30|min|^^^202006160900^202006160930|||||BOOKED^Booked^L
NTE|1||Booked in Radiology Suite 1; arrive 15 minutes early.
RGS|1|A
AIL|1|A|XR1^^^MERCYGEN^^Radiology Suite 1|EXAM|||202006160900|0|min|Y
AIP|1|A|TECH07^ROE^PAT^^^^RT|RT|||202006160900|0|min|Y
What this sample shows
The SRR^S01 in MSH-9 marks a response to a new appointment booking request. The MSA carries AA — application accept — and echoes the originating SRM control id MSG00021 in MSA-2, allowing the placer to match this response to its request. The SCH carries the placer appointment id APPT1001 from the original request and the filler-assigned appointment id FILL9901 (SCH-2), which is the identifier the placer must record as the authoritative booking reference. The confirmed start is 202006160900 and the end 202006160930, reflecting a 30-minute slot the filler found between 08:00 and 12:00 as requested. The BOOKED filler status in SCH confirms the appointment is scheduled. The NTE carries a note from the filler about early arrival. The RGS opens the resource group, and within it the AIL confirms the examination location and the AIP confirms the assigned radiologic technologist.
Working with SRR messages
Record the filler appointment id from SCH
The filler-assigned appointment id in SCH-2 is the booking reference the placer must capture and store. Every subsequent interaction with the filler — rescheduling, cancellation, resource changes — requires the filler appointment id to locate the booking. A placer that stores only its own appointment id from the original SRM will be unable to reference the booking in future requests.
Check MSA before processing SCH
The acknowledgement code in MSA-1 must be checked before treating the response as a confirmation. An AE or AR code means the filler rejected the request; the SCHEDULE group with SCH will be absent, and the ERR segment carries the reason. Processing a response that carries no SCH as if the appointment were booked creates a booking the filler never accepted.
Correlate on MSH-10 and MSA-2
Use MSA-2 — the control id echoed from the originating SRM's MSH-10 — to match each SRR to its request. When multiple SRM requests are in flight simultaneously, this correlation is the only reliable way to associate a response with the correct pending request.
SRR is the confirmation; SIU is the notification
The SRR is the filler's point-to-point answer to the placer's request; it does not replace the SIU notifications the filler sends to inform all subscribed systems of the schedule change. A placer that receives an accepted SRR can treat the appointment as confirmed, but other systems in the environment learn about it only through SIU.
Vendor variance. Some filler systems return the full resource group in the SRR even for rejection responses; others omit the
SCHEDULEgroup entirely unless the request is accepted. Some fillers populateSCH-11andSCH-12with the confirmed times while others leave them blank and rely on the resource-level timing inAIS,AIL, andAIP. Confirm a partner's field usage against their interface specification rather than assuming the base standard.
FHIR equivalent
A schedule request response corresponds conceptually to the FHIR Appointment resource — the SCH segment conveys the filler's confirmed appointment, which in FHIR terms is an Appointment resource in booked status with participants drawn from the resource groups.
There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for any SRR trigger event — among the scheduling messages, only SIU_S12 has a published message map, and that is the unsolicited notification, not the request response. A FHIR Appointment produced from an SRR is therefore mapped manually, taking the filler appointment identifier, reason, type, confirmed timing, and resources from SCH and the RGS resource groups.
Common pitfalls
Pitfall. Processing SCH without first checking MSA. When the filler rejects a request,
MSA-1carriesAEorARand noSCHEDULEgroup is present; a parser that assumesSCHfollows every SRR will fail or silently discard the rejection.
Pitfall. Storing the placer appointment id instead of the filler appointment id. The booking reference the filler uses for all future interactions is in
SCH-2; the placer's own id inSCH-1was supplied with the original request. Using the placer id to reference the appointment in subsequent SRM messages will cause the filler to be unable to locate it.
Pitfall. Assuming a fixed date-time precision. The confirmed start and end times in
SCH-11andSCH-12can be sent at different precisions and with or without a timezone offset; do not assume a timezone — normalize on ingest.
How Vorro handles SRR messages
Vorro ingests the SRR response over MLLP or another transport, checks MSA-1 to determine whether the filler accepted or rejected the SRM request, and correlates the response to the originating request using MSA-2. On acceptance, Vorro reads the filler-assigned appointment id from SCH (SCH-2), captures the confirmed appointment reason, type, and timing, and walks the RGS resource groups to record the services, locations, and personnel the filler confirmed. On rejection, Vorro surfaces the ERR detail to the originating system so it can act on the refusal. Where a FHIR destination is configured, Vorro maps the confirmed appointment to an Appointment resource — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.
Related messages
- SRM — the schedule request message that every SRR responds to.
- SIU — the unsolicited scheduling notification the filler broadcasts to subscribers after the schedule changes.
- SQR — the schedule query response that returns available slot information.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for any SRR trigger event
- HL7 v2-to-FHIR IG — segment maps index
- HL7 Messaging Standard Version 2.5.1 product brief
