HL7 SRM Messages: Schedule Request

HL7 SRM messages carry requests to schedule something — to book a new appointment, reschedule or modify an existing one, cancel or discontinue it, or add and adjust the services and resources an appointment needs. SRM is the request half of HL7 scheduling: a placer application sends the SRM to the filler application that owns the schedule, the filler decides what it can do, and it answers with an SRR response and broadcasts the outcome through SIU notifications. This page explains what an SRM message represents, the trigger events it carries, every segment the message can contain and what each one holds, and how a schedule request relates to FHIR. Sample content is constructed for illustration with fictional identifiers.

What an SRM message represents

An SRM message — SRM stands for Schedule Request Message — communicates a request from a placer application to a filler application that controls a schedule. The placer is asking the filler to do something to an appointment: create it, move it, change it, cancel it, or alter the resources attached to it. The filler owns the schedule and remains the authority on what is actually booked; the SRM is a request, not a statement of fact, and the filler may decline it.

The core of the message is the ARQ segment — Appointment Request — which carries the placer's and filler's appointment identifiers, the schedule the appointment belongs to, the reason and type of appointment, the requested duration, and the requested start date-and-time range. Every SRM, regardless of trigger event, also carries at least one resource group introduced by RGS, describing the services, equipment, locations, and people the appointment needs. The request says what the placer wants; the filler answers with an SRR.

When an SRM message is sent

An SRM message is sent whenever a placer application needs the filler to act on a schedule — when a clinician's system books a clinic slot, when a patient's appointment is moved, or when an extra resource is added to an already-booked appointment. The request always names the appointment it concerns through the placer and filler appointment identifiers in ARQ, so the filler can locate the existing booking for every event except a brand-new one.

Trigger events

All SRM trigger events share one message structure; the event code in MSH-9 tells the filler what action the placer is requesting. HL7 v2.5.1 defines eleven SRM trigger events:

SRM^S01 – Request new appointment booking.
SRM^S02 – Request appointment rescheduling.
SRM^S03 – Request appointment modification.
SRM^S04 – Request appointment cancellation.
SRM^S05 – Request appointment discontinuation.
SRM^S06 – Request appointment deletion.
SRM^S07 – Request addition of service/resource on appointment.
SRM^S08 – Request modification of service/resource on appointment.
SRM^S09 – Request cancellation of service/resource on appointment.
SRM^S10 – Request discontinuation of service/resource on appointment.
SRM^S11 – Request deletion of service/resource on appointment.

The first six events (S01–S06) act on the appointment as a whole — book it, move it, change it, cancel it, discontinue it, delete it. The last five (S07–S11) act on the services and resources within an appointment that already exists. Because every event uses the same segments, the receiver's handling turns on the event code in MSH-9 together with the appointment identifiers and segment action codes inside the message.

Integration topology

The diagram shows a placer application sending a schedule request through the integration engine to the filler that owns the schedule, which answers and then notifies subscribers.

{{diagram: placer application → SRM request → integration engine → schedule filler → SRR response + SIU notifications to subscribers}}

Typical senders: ordering or clinical applications, referral and registration systems, and any placer that needs to book or change an appointment.

Typical receivers: the schedule filler application that owns the resource calendar — a radiology scheduler, surgical scheduler, clinic scheduling system, or enterprise scheduling platform.

Direction: a request from the placer to the filler. The filler replies with an SRR acknowledging or rejecting the request, and announces the resulting schedule change to other systems with SIU notifications.

Segments in an SRM message

The SRM message opens with the header and the ARQ appointment request, followed by an optional PATIENT group identifying the patient the appointment is for, and one or more RESOURCES groups — each introduced by RGS and containing optional service, general-resource, location-resource, and personnel-resource subgroups. At least one RGS is required even when no real grouping is needed, so a parser can read the structure consistently. 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 SRM message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in `MSH-9` (for example `SRM^S01`), carries the message control id in `MSH-10`, and pins the HL7 version. Receivers route on `MSH-9` and deduplicate on `MSH-10`.
`ARQ`	Appointment Request. The core of the message — it defines the request for the appointment. It carries the placer appointment id in `ARQ-1` and the filler appointment id in `ARQ-2`, the occurrence number in `ARQ-3`, the schedule id in `ARQ-5`, the request event reason in `ARQ-6` and the appointment reason in `ARQ-7`, the appointment type in `ARQ-8`, the requested duration in `ARQ-9`, the requested start date-and-time range in `ARQ-11`, and the priority in `ARQ-12`. Required and non-repeating.
`[APR]`	Appointment Preferences. Parameters and preference specifications the placer attaches to the request — preferred times and days, resource and location preferences, and override flags. Optional; here it applies to the appointment as a whole.
`[{NTE}]`	Notes and Comments. Free-text notes that apply to the appointment request. 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`. Required within the group; the group itself is optional and repeating, since a single request can concern more than one patient (for example a group session) and some resource bookings concern no patient at all.
`[PV1]`	Patient Visit. The visit context for the appointment — patient class and assigned location — when the request is tied to a known encounter. Optional, within the PATIENT group.
`[PV2]`	Patient Visit Additional. Companion to `PV1` with admit reason and expected dates when a visit is present. Optional, within the PATIENT group.
`[{OBX}]`	Observation/Result. Scheduling-relevant observations carried with the patient, such as a height or weight that affects resource selection. Optional and repeating, within the PATIENT group.
`[{DG1}]`	Diagnosis. The diagnosis that justifies the appointment, coded for the filler and for downstream billing. Optional and repeating, within the PATIENT 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, drawn from HL7 Table 0206), and a resource group id in `RGS-3`. Required and repeating — at least one `RGS` appears even when no real grouping is needed.
`[{AIS}]`	Appointment Information – Service. Opens the optional SERVICE subgroup and describes a schedulable service — the universal service identifier, the start time and duration, an allow-substitution code, and the filler status code. Required within the SERVICE subgroup; the subgroup is optional and repeating.
`[APR]`	Appointment Preferences. Preferences scoped to the service in the preceding `AIS`. Optional, within the SERVICE subgroup.
`[{NTE}]`	Notes and Comments. Notes scoped to the service. 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`. Required within the subgroup; the subgroup is optional and repeating.
`[APR]`	Appointment Preferences. Preferences scoped to the general resource in the preceding `AIG`. Optional, within the GENERAL RESOURCE subgroup.
`[{NTE}]`	Notes and Comments. Notes scoped to the general resource. Optional and repeating, within the GENERAL RESOURCE subgroup.
`[{AIL}]`	Appointment Information – Location Resource. Opens the optional LOCATION RESOURCE subgroup and describes a location to be scheduled — 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.
`[APR]`	Appointment Preferences. Preferences scoped to the location resource in the preceding `AIL`. Optional, within the LOCATION RESOURCE subgroup.
`[{NTE}]`	Notes and Comments. Notes scoped to the location resource. Optional and repeating, within the LOCATION RESOURCE subgroup.
`[{AIP}]`	Appointment Information – Personnel Resource. Opens the optional PERSONNEL RESOURCE subgroup and describes a person to be scheduled — a technician, physician, nurse, or surgeon — by personnel id in `AIP-3` or, when no individual is yet named, a resource type in `AIP-4`. Required within the subgroup; the subgroup is optional and repeating.
`[APR]`	Appointment Preferences. Preferences scoped to the personnel resource in the preceding `AIP`. Optional, within the PERSONNEL RESOURCE subgroup.
`[{NTE}]`	Notes and Comments. Notes scoped to the personnel resource. Optional and repeating, within the PERSONNEL RESOURCE subgroup.

[ ] = optional, { } = repeating

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, so a single request can name several resources of several kinds. The canonical segment pages carry the full field-by-field detail.

Sample SRM message

Note. Constructed for illustration. Patient identifiers, appointment ids, dates, and names are fictional.

MSH|^~&|SCHEDULER|MERCYGEN|RADIOLOGY|MERCYGEN|202006150900||SRM^S01^SRM_S01|MSG00021|P|2.5.1
ARQ|APPT1001^SCHEDULER|||||ROUTINE^Routine^L|71020^Chest X-ray^C4|FOLLOWUP^Follow-up^L|30^min|^^^202006160800^202006161200|R
PID|1||MR12345^^^MERCYGEN^MR||DOE^JOHN^Q||19800101|M
RGS|1|A
AIL|1|A|XR1^^^MERCYGEN^^Radiology Suite 1|EXAM
AIP|1|A|TECH07^ROE^PAT^^^^RT|RT

What this sample shows

The SRM^S01 in MSH-9 marks a request to book a new appointment. The ARQ carries the placer appointment id APPT1001 (ARQ-1); because this is a new booking, there is no filler appointment id yet (ARQ-2). It states the appointment type (ARQ-8), a requested 30-minute duration (ARQ-9), a requested start window of 08:00–12:00 the next day in ARQ-11, and routine priority R (ARQ-12). PID identifies the patient by medical record number MR12345. The RGS opens the single resource group, and within it the AIL requests an examination location and the AIP requests a radiologic technologist as the personnel resource.

Working with SRM messages

Route on the trigger event, act on the appointment ids

Switch on MSH-9 to know which action the placer wants — book, reschedule, modify, cancel, discontinue, delete, or one of the service/resource events. For every event except a new booking, locate the existing appointment by the placer and filler appointment ids in ARQ (ARQ-1, ARQ-2). A new S01 carries a placer id but no filler id, because the filler has not yet assigned one.

SRM is a request, not a confirmation

An SRM expresses intent; it does not change the schedule on its own. The filler owns the schedule and answers with an SRR that accepts or rejects the request, and the booked state is announced through SIU notifications. Do not treat the SRM as the authoritative record of what is scheduled — wait for the filler's response.

Resource groups and the required RGS

Every SRM carries at least one RGS, even when the appointment needs no real grouping, so the message structure parses consistently. Within each group, services appear in AIS, equipment and other general resources in AIG, locations in AIL, and people in AIP. When a specific resource is not yet chosen, the request can name a resource type instead — AIG-4, AIL-4, or AIP-4 — and let the filler select.

Segment action codes on modify events

For the modification-style events, the segment action code in RGS-2 (and the corresponding action fields on the appointment-information segments) tells the filler whether each resource is being added, updated, or deleted, using HL7 Table 0206. Read these action codes rather than assuming the whole resource set is being restated.

Vendor variance. Schedule fillers differ in which trigger events they accept and in how they expect resources to be named — by a specific id versus a resource type, and in how the optional APR preferences are interpreted. Confirm a partner's supported events and field usage against their interface specification rather than assuming the base standard.

FHIR equivalent

A schedule request corresponds conceptually to the FHIR Appointment resource, with the filler's calendar represented by Schedule and the bookable openings by Slot. The SRM trigger events map in spirit onto Appointment lifecycle changes — book, reschedule, cancel — but FHIR models these as RESTful operations on an Appointment rather than as a single request message.

There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for any SRM trigger event — among the scheduling messages, only SIU_S12 has a published message map, and that is the unsolicited notification, not the request. A FHIR Appointment produced from an SRM is therefore mapped manually, taking the appointment identifiers, reason, type, requested timing, and resources from ARQ and the RGS resource groups.

Common pitfalls

Pitfall. Treating the SRM as the booked appointment. The SRM is the placer's request; the filler decides, replies with an SRR, and broadcasts the result via SIU. Recording the request as a confirmed booking creates appointments that the filler never accepted.

Pitfall. Ignoring the segment action codes on the modify events. The service/resource events (S07–S11) and the modification events change part of an appointment; reading RGS-2 and the resource action fields tells you what changed, where assuming a full restatement of the resource set does not.

Pitfall. Assuming a fixed date-time precision. The requested start range in ARQ-11 and the resource timings can be sent at different precisions and with or without an offset; do not assume a timezone — normalize on ingest.

How Vorro handles SRM messages

Vorro ingests the SRM feed over MLLP or another transport, deduplicates on MSH-10, and routes by the trigger event in MSH-9 to the schedule filler the request is bound for. Vorro reads the appointment identifiers, reason, type, and requested timing from ARQ, walks the RGS resource groups to resolve the requested services, equipment, locations, and personnel, and correlates each request with the filler's SRR response and the resulting SIU notifications. Where a FHIR destination is configured, Vorro maps the request to an Appointment resource — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.

SIU — the unsolicited scheduling notification the filler broadcasts when the schedule changes.
SQM — the schedule query that asks a filler about available slots before requesting one.
SRR — the scheduling response the filler returns to acknowledge or reject an SRM request.

Sources

HL7 v2.5.1 standard — Chapter 10 Scheduling (hl7.eu mirror) — SRM trigger events S01–S11 and message structure
HL7 v2 ARQ segment definition (hl7.eu)
HL7 v2 RGS segment definition (hl7.eu)
HL7 v2 AIS segment definition (hl7.eu)
HL7 v2 AIG segment definition (hl7.eu)
HL7 v2 AIL segment definition (hl7.eu)
HL7 v2 AIP segment definition (hl7.eu)
HL7 v2 APR segment definition (hl7.eu)
HL7 v2-to-FHIR IG — message maps index — confirms no message map for any SRM trigger event
HL7 v2-to-FHIR IG — segment maps index
HL7 Messaging Standard Version 2.5.1 product brief

← Back to HL7 v2 Guide