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

Scheduling Home

Official URL: https://profiles.ihe.net/ITI/Scheduling/ImplementationGuide/ihe.iti.scheduling				Version: 1.0.0-comment
Active as of 2024-08-13				Computable Name: IHE_ITI_Scheduling

The IHE FHIR Scheduling Profile is a specification providing FHIR APIs and guidance for access to and booking of appointments for patients by both patient and practitioner end users. This specification is based on FHIR Version 4.0.1 and specifically the Schedule, Slot, and Appointment resources, and on the previous work of the Argonaut Project.

Organization of This Guide

This guide is organized into the following sections:

1. Volume 1:
   1. Introduction
   2. Actors and Transactions
   3. Actor Options
   4. Required Actor Groupings
   5. Overview
   6. Security Considerations
   7. Cross Profile Considerations
2. Volume 2: Transaction Detail
   1. Find Potential Appointments [ITI-115]
   2. Hold Appointment [ITI-116]
   3. Book Appointment [ITI-117]
   4. Search Patient Appointments [ITI-118]
3. Other
   1. Changes to Other IHE Specifications
   2. Download and Analysis
   3. Test Plan

See also the Table of Contents and the index of Artifacts defined as part of this implementation guide.

Conformance Expectations

IHE uses the normative words: “REQUIRED”, “REQUIRED NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “recommended”, “MAY”, and “OPTIONAL” according to standards conventions.

Required Support

The use of RequiredSupport in StructureDefinition profiles equivalent to the IHE use of R2 as defined in Appendix Z.

RequiredSupport of true - only has a meaning on items that are minimal cardinality of zero (0), and applies only to the source actor populating the data. The source actor SHALL populate the elements marked with RequiredSupport, if the concept is supported by the actor, a value exists, and security and consent rules permit. The consuming actors SHOULD handle these elements being populated or being absent/empty. Note that sometimes RequiredSupport will appear on elements with a minimal cardinality greater than zero (0), this is due to inheritance from a less constrained profile.