HL7 SRM_S01 (Request New Appointment Booking) | Integration Soup HL7 Reference Guide

HL7 SRM_S01 Request New Appointment Booking

The placer asks the schedule owner to create an appointment.

HL7 message structure SRM_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
ARQ	Appointment Request	Yes	No
APR	Appointment Preferences	No	No
NTE	Notes and Comments	No	Yes
SRM_S01.PATIENT	Patient group	No	Yes
PID	Patient Identification	Yes	No
PV1	Patient Visit	No	No
PV2	Patient Visit - Additional Information	No	No
OBX	Observation/Result	No	Yes
DG1	Diagnosis	No	Yes
SRM_S01.RESOURCES	Resources group	Yes	Yes
RGS	Resource Group	Yes	No
SRM_S01.SERVICE	Service group	No	Yes
AIS	Appointment Information	Yes	No
APR	Appointment Preferences	No	No
NTE	Notes and Comments	No	Yes
SRM_S01.GENERAL_RESOURCE	General Resource group	No	Yes
AIG	Appointment Information - General Resource	Yes	No
APR	Appointment Preferences	No	No
NTE	Notes and Comments	No	Yes
SRM_S01.LOCATION_RESOURCE	Location Resource group	No	Yes
AIL	Appointment Information - Location Resource	Yes	No
APR	Appointment Preferences	No	No
NTE	Notes and Comments	No	Yes
SRM_S01.PERSONNEL_RESOURCE	Personnel Resource group	No	Yes
AIP	Appointment Information - Personnel Resource	Yes	No
APR	Appointment Preferences	No	No
NTE	Notes and Comments	No	Yes

SRM_S01 is the request side of appointment scheduling. A placer application sends it when it wants a filler application to book a new appointment on a schedule the placer does not control. In plain integration terms, one system is saying, "please reserve this service, room, person, or resource for this patient and time."

That makes SRM different from SIU_S12. SIU tells interested systems that the schedule has already changed. SRM asks the system that owns the schedule to make the change. The response is usually SRR_S01, which says whether the request was accepted and may return the appointment details the filler actually booked.

A small SRM S01 example

MSH|^~\&|REFERRAL|CITYHOSP|SCHED|CITYHOSP|20260720101500||SRM^S01^SRM_S01|SRM00001|P|2.5.1 ARQ|REQ-20260720-001||1||ROUTINE^Routine request^L|BOOK^Book appointment^L|CARDREV^Cardiology review^L|30|min|^^^20260722100000^20260722103000|||||12345^Planner^Paula APR|||^^^20260722090000^20260722120000 PID|1||123456^^^CITYHOSP^MR||Smith^Jane^Anne^^Ms^^L||19800314|F|||12 High Street^^Auckland^^1010^NZ^H PV1|1|O|CARD^WAIT^^CITYHOSP RGS|1 AIS|1||CARDREV^Cardiology review^L|20260722100000|30|min AIL|1||CARD^ROOM2^^CITYHOSP|20260722100000|30|min AIP|1||12345^Careful^Clara|CARD^Cardiologist^L|20260722100000|30|min

What workflow it represents

The sender is usually a referral, order entry, portal, call-center, or departmental system that can request an appointment but cannot place it directly on the filler schedule. The receiver is usually the scheduling system or departmental application that owns the appointment book.

The filler should treat SRM_S01 as a request, not as a finished booking notification. It may accept the request, reject it, or accept it with different practical details. For example, the requested cardiology review might be booked into a different room, with a different provider, or at a slightly different time according to local scheduling rules.

How to read the structure

ARQ is the request header. It carries the placer appointment ID, requested action context, appointment reason, appointment type, requested timing, duration, and audit-style entered-by detail. APR adds appointment preferences, especially acceptable ranges or resource preferences that should not be forced into ARQ.

The optional patient group starts with PID and can add visit, observation, or diagnosis context. The required resources group starts with RGS, then carries service detail in AIS, equipment or general resource detail in AIG, location detail in AIL, and personnel detail in AIP.

Implementation traps

The first trap is assuming the request is the appointment. Until the filler accepts it, the placer has asked for a booking, not created one. Downstream reminders, worklists, and patient-facing messages should normally wait for the SRR or later SIU notification that confirms what actually happened.

The second trap is muddling service and resource identity. The service is what is being scheduled; resources are the people, places, or things needed to perform it. Keeping AIS, AIL, and AIP cleanly separated makes it much easier to explain why a request could not be fulfilled.

Reference notes

HL7 Chapter 10 describes S01 as a request from a placer application to a filler application to book a new appointment, with the response optionally returning an SCH segment and related detail describing the actual booked appointment. See the HL7 scheduling chapter for Chapter 10 scheduling.