Scheduling
1.0.0 - Trial-Implementation
This page is part of the IHE ITI Scheduling (v1.0.0: Publication) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. For a full list of available versions, see the Directory of published versions
The Scheduling Profile is a vendor agnostic specification providing FHIR APIs and guidance for access to, and booking of, appointments for patients by both patient and practitioner end users, including cross-organizational workflows. This specification is based on FHIR Version 4.0.1, and references the Schedule, Slot, and Appointment resources.
This workflow profile defines transactions that allow a scheduling client to obtain information about possible appointment opportunities based on specific parameters and based on that information, allow the client to book an appointment.
History and Acknowledgment:
This IHE profile is based on the Argonaut Scheduling Implementation Guide. The following are some of the major differences from the Argonaut IG:
- The IHE Profile is based on FHIR R4
- The IHE Profile is intended for international use, and it does not have required bindings or any dependencies to national profiles
- The operations described are $find, $hold, and $book
- A separate transaction describes the use of FHIR Search for the Appointment resource
- The operation parameters use explicit data types, and support only POST transactions
This section defines the actors, transactions, and/or content modules in this profile. General definitions of actors are given in the Technical Frameworks General Introduction Appendix A. IHE Transactions can be found in the Technical Frameworks General Introduction Appendix B. Both appendices are located at https://profiles.ihe.net/GeneralIntro/.
The figure below shows the actors directly involved in the Scheduling Profile and the relevant transactions between them.
Table 1:55.1-1: Scheduling Profile - Actors and Transactions
Actors | Transactions | Initiator or Responder | Optionality | Reference |
---|---|---|---|---|
Scheduling Client | Find Potential Appointments [ITI-115] | Initiator | R | ITI TF-2: 3.115 |
Hold Appointment [ITI-116] | Initiator | O | ITI TF-2: 3.116 | |
Book Appointment [ITI-117] | Initiator | R | ITI TF-2: 3.117 | |
Find Existing Appointment [ITI-118] | Initiator | O | ITI TF-2: 3.118 | |
Scheduling Server | Find Appointments [ITI-115] | Responder | R | ITI TF-2: 3.115 |
Hold Appointment [ITI-116] | Responder | O | ITI TF-2: 3.116 | |
Book Appointment [ITI-117] | Responder | R | ITI TF-2: 3.117 | |
Find Existing Appointment [ITI-118] | Responder | O | ITI TF-2: 3.118 |
The actors in this profile are described in more detail in the sections below.
The Scheduling Client determines an appropriate potential appointment based on the parameters it supplies to the Scheduling Server, and then books an appointment for a given patient. The following points apply to the Scheduling Client:
Please see the FHIR Capability Statement for the Client.
The Scheduling Server provides services for providing a list of available appointments, and for booking an appointment. The following points apply to the Scheduling Server:
Please see the FHIR Capability Statement for Server.
The transactions in this profile are summarized in the sections below.
This transaction searches for availability for one or more future appointments using the Find Appointments operation.
For more details see the transaction description and the corresponding operation definition.
Request for a hold on a selected Appointment in order for the user to complete entering data for booking an appointment. This operation precedes the booking and follows the determination of appointment availability using the Find Appointments operation. The Hold Appointments operation describes the following parameters:
For more details see the detailed transaction description.
This operation books an appointment following the determination of appointment availability using the Find Appointments operation. Using different combination of parameters, this operation can book a new appointment, cancel an already existing appointment, or reschedule an existing appointment. The Book Appointment operation describes the following parameters:
For more details see the detailed transaction description.
This transaction searches for existing appointments for the patient using FHIR Search against the Appointment resource. The client MAY search for existing appointments for the patient. The patient and a date range are required search parameters. The server capability statement has further details on the possible search parameters.
For more details see the detailed transaction description.
There are currently no options for these actors.
There are no required groupings for this profile.
This profile is intended to address use cases for cross-organizational or patient initiated scheduling of healthcare appointments.
The following subsections show how the transactions of the profile are combined to address the use cases.
The FHIR specification defines several resources to describe scheduling-related information. The Schedule, Slot, and Appointment resources are intended to be compatible with the iCalendar specification. A survey of existing implementations, however, showed that there is very little commonality among existing FHIR server implementations, which suggests that an operation-based specification will improve interoperability in this area.
There is wide variety of appointments that pertain to the healthcare domain. A core assumption of this profile is that the Scheduling Server actor is responsible for all the business logic for determining the type, duration, sequencing, and all other attributes an appointment may have. This is the reason that the response to the search for potential appointments only contains Appointment resources. The management of Schedule and Slot resources is out of scope for this profile.
For example, the Scheduling server may modify existing appointments in order to free up time for an urgent appointment. While this may change the existing Schedule
and Slot
resources on the server, the Scheduling Client that is attempting to book the urgent appointment only needs to know that a new appointment can be booked. Any changes to existing appointments can be detected using the [ITI-118] transaction, or, if the ITI Scheduling profile is implemented in an environment with an existing FHIR Subscription infrastructure, via a SubscriptionNotification
for the changed appointment(s).
The overall functionality covered by this profile is as follows:
Ms. Philips is being discharged from Green Valley General Hospital. One of the steps of the discharge process includes scheduling a follow-up appointment with Dr. Spears, Ms. Philip's primary care provider. Dr. Spears' practice is part of a different healthcare organization, which necessitates cross-organizational scheduling of the follow-up appointment.
Without the availability of the ITI Scheduling functionality, the hospital staff would have to contact Dr. Spears' practice to negotiate an appointment for the patient, or leave it to Ms. Philips to schedule the appointment by herself. This makes it likely that the follow-up appointment may not occur in a timely manner, or at all.
The ITI Scheduling profile would allow the two systems to communicate the request for an appointment, get a list of possible times, coordinate with the patient the best time for the appointment, and book the appointment with Dr. Spears. This will ensure the follow-up visit will happen on time, and that Ms. Philips will get the proper care.
Dr. Brown detects that a radiology examination is recommended to proceed with the treatment of her Patient Mr. White. Dr. Brown opens the radiology examination scheduling in her clinical information systems and selects a radiology facility for the examination. She asks the system to show the existing appointments for the patient and then asks for potential appointment slots for the radiology procedure.
From the list of available time slots presented in the clinical information system, Dr. Brown selects an appropriate time slot for the examination of Mr. White. Dr. Brown records the booking details (e.g., Mr. White demographics, treatment, body part to examine, etc.) in the booking details dialog of the clinical information system. Dr. Brown confirms the records and books the examination in the confirm dialog in her clinical information system.
Mr. White feels sick on holiday in a foreign country and wants to visit a healthcare provider for an examination. Mr. White opens the local patient portal and searches for a healthcare provider using search criteria (e.g., distance, opening hours, supported languages). Mr. White selects Dr. Brown's practice as the healthcare provider and opens the appointments view in the patient portal.
From the list of available time slots presented in the patient portal, Mr. White selects an appropriate time slot for the visit. Mr. White records the booking details (e.g., demographics, symptoms, etc.) in the booking details dialog in the patient portal. Mr. White confirms the records and books the examination in the confirm dialog of the patient portal.
Actors are expected to follow the recommendations and requirements found in Appendix Z.8 “Mobile Security Considerations”.
The resources exchanged in this profile could contain information which pose a privacy risk, or in some cases, a safety risk, to providers and other personnel, as well as patients. For example, practitioner or patient phone numbers and home addresses could be conveyed. Implementers need to determine what data will be exposed by the system and what level of public access there will be if any. Therefore the Audit Trails and Node Authentication (ATNA) Profile is required. This mandates Access Controls, Secure Communications, and an Audit Trail capability. The use of Basic Audit Log Patterns is foundational to the AuditEvent profiles defined in this Implementation Guide.
Implementers need to consider Privacy and Security when determining the access policies for these Resources. System administrators for the underlying host systems must follow industry best practices for authentication, authorization, auditing, timely application of software patches, etc.
There are many reasonable methods of security for interoperability transactions which can be implemented without modifying the characteristics of the transactions in the Scheduling Profile. The use of TLS is encouraged, specifically the use of the ATNA Profile (see ITI TF-1: 9).
User authentication on mobile devices and browsers is typically handled by more lightweight authentication schemes such as HTTP Authentication, OAuth 2.0, or OpenID Connect. IHE has a set of profiles for user authentication including Internet User Authentication (IUA) for REST-based authentication with ATNA "STX: HTTPS IUA Option" that uses OAuth for client authentication while using TLS server authentication. Implementers SHOULD implement the SMART on FHIR IG for the corresponding use cases (patient-facing or provider-facing). The network communication security and user authentication are layered in the HTTP transport layer.
The Scheduling Profile is intended to be used in varied settings and to satisfy multiple use cases. Some of these uses will benefit from using the Scheduling Profile together with other IHE profiles. The following cross-profile descriptions are not exclusive or exhaustive, and the list can be updated in the future.
When a patient needs to schedule an appointment outside their usual care providing environment, they could need to initially find the endpoint of the healthcare or service provider where an appointment can be requested. The [Find Matching Care Services ITI-117] transaction from the mCSD profile can be used for endpoint discovery prior to the use of the Find Appointments transaction.
The 360X Profile describes cross-organizations referral workflows, and it has a scheduling option, which is not required. The ITI Scheduling Profile can be used instead of the 360X Scheduling Option when there are appropriate business agreements that allow cross-organizational scheduling. The referral and patient identifiers used in the 360X transactions must be used in the corresponding parameters of the Find Appointments transaction in order to provide the necessary link between the appointment and the referral.