This page is part of the IHE ITI Scheduling (v1.0.0-comment: Publication Ballot 1) 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

1:55 Scheduling

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

1:55.1 Scheduling Actors, Transactions and Content Modules

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/.

• Actors

  • Scheduling Client
  • Scheduling Server

• Transactions

  • Find Potential Appointments ITI_115
  • Hold Appointment ITI-116
  • Book Appointment ITI-177
  • Find Existing Appointments ITI-118

The figure below shows the actors directly involved in the Scheduling Profile and the relevant transactions between them.

Figure 1:55.1-1: Scheduling Actor Diagram

Table 1:55.1-1: Profile Acronym 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

1:55.1.1 Actors

The actors in this profile are described in more detail in the sections below.

1:55.1.1.1 Scheduling Client

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:

• The client needs a mechanism to properly identify the patient. Although the details of this capability is out of scope for this profile, it is recommended that the Scheduling Client is grouped with the Patient Demographics Consumer from the IHE PDQm Profile.
• The client SHOULD determine the FHIR Capability Statement for the Server.

Please see the FHIR Capability Statement for the Client.

1:55.1.1.2 Scheduling Server

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:

• The server expects that the Patient and Provider/ProviderRole resources are properly identified. The exact mechanisms for making sure that the client has this correct information is out of scope for this profile. In the case that the Scheduling Client is grouped with a Patient Demographics Consumer actor from the IHE PDQm Profile, it is recommended that the Scheduling Server is grouped the Patient Demographics Supplier from the same profile.
• The server decides on the types of appointments that are possible to make using the transactions of this profile. Such business rules are specific to the type of appointment, and other contexts surrounding the provision of care.
• The server MAY chose to implement the Hold Appointment transaction, if the supported use cases have such a need.

Please see the FHIR Capability Statement for Server.

1:55.1.2 Transaction Descriptions

The transactions in this profile are summarized in the sections below.

1:55.1.2.1 Find Potential Appointments [ITI-115]

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.

1:55.1.2.2 Hold Appointment [ITI-116]

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:

• appt-id
• appt-resource
• return

For more details see the detailed transaction description.

1:55.1.2.3 Book Appointment [ITI-117]

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:

• appt-id
• appt-resource
• cancelled-appt-id
• patient-id
• comment
• return

For more details see the detailed transaction description.

1:55.1.2.4 Find Existing Appointments [ITI-118]

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.

1:55.2 Scheduling Actor Options

There are currently no options for these actors.

1:55.3 Scheduling Required Actor Groupings

There are no required groupings for this profile.

1:55.4 Scheduling Overview

This section shows how the transactions of the profile are combined to address the use cases.

1:55.4.1 Concepts

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.

The overall functionality covered by this profile is as follows:

1. The Scheduling Client identifies the patient or patients for whom the appointment will be scheduled
2. The Scheduling Client determines the available parameters for requesting a list of available appointments
3. The Find Appointments transaction is completed.
4. (Optionally) The Hold Appointment transaction is completed.
5. The Book Appointment Transaction is completed.

1:55.4.2 Use Cases

1:55.4.2.1 Use Case #1: Provider-facing Scheduling Client

1:55.4.2.1.1 Post-discharge PCP Visit

1:55.4.2.1.2 Specialty Visit Scheduling

1:55.4.2.1.2.1 Specialty Visit Scheduling Use Case Description

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.

1:55.4.2.1.2.2 Provider-facing Scheduling Client Process Flow

Figure 1:55.4.2.1-1: Provider-facing Scheduling Client Process Flow

1:55.4.2.2 Use Case #2: Patient-facing Scheduling Client

1:55.4.2.2.1 Foreign Visitor Urgent Visit

1:55.4.2.2.1.1 Use Case Description

Mr. White feels sick on holidays 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 a Dr. Brown's practice as 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.

1:55.4.2.2.1.2 Foreign Visitor Urgent Visitor Process Flow

Figure 1:55.4.2.2-1: Patient-facing scheduling client Process Flow

1:55.5 Scheduling Security Considerations

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.

Implementers need to consider this 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. 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.

1:55.6 Scheduling Cross-Profile Considerations

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.

1:55.6.1 mCSD - Mobile Care Services Discovery

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 ITI-90 Find Matching Care Services transaction from the mCSD profile can be used for endpoint discovery prior to the use of the Find Appointments transaction.

1:55.6.2 360X - 360 Exchange Closed Loop Referral

The 360X Profile describes cross-organizations referral workflows, and it has a scheduling option, which is not required. The R 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.