IHE ITI Scheduling
0.8.0-current - ci-build
IHE ITI Scheduling, published by IHE IT Infrastructure Technical Committee. This guide is not an authorized publication; it is the continuous build for version 0.8.0-current built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/IHE/ITI.Scheduling/ and changes regularly. See the Directory of published versions
This section corresponds to transaction [ITI-115] of the IHE Technical Framework. Transaction [ITI-115] is used by the Scheduling Client and Scheduling Server Actors. The Find Appointments [ITI-115] transaction is used to provide a set of parameters to the server, and based on them to get back a list of possible appointments.
The Find Potential Appointments [ITI-115] transaction allows a Scheduling Client to retrieve a list of available slots for potential appointments from a Scheduling Server based on certain search criteria.
Table: Actor Roles
Actor | Role |
---|---|
Scheduling Client | Sends a “Find Potential Appointments” request to Server |
Scheduling Server | Receives and processes the “Find Potential Appointments” request and responds with 0, 1 or more potential appointment slots |
FHIR-R4 HL7 FHIR Release 4.0
Figure: Find Potential Appointments Interactions
This transaction uses the $find
operation as defined in the Operation Definition.
When a Scheduling Client needs to needs to find potential slot to book a new appointment it issues a “Find Potential Appointments” request.
The Find Potential Appointment request is defined as a FHIR Operation. Please see the corresponding Operation Definition.
The request parameters in the table, which is part of the operation definition, are derived from search parameters defined for the FHIR Appointment Resource, and from additional functionally relevant entities, for example organization
or referral
.
'’TODO: discuss the Organization parameter. A FHIR Appointment Resource does not include an Organization reference. Hence, it may not be possible to use it as a search parameter. Since a location is always linked to an organization ‘’
Example: GET In case the Scheduling Client uses a GET method it the search parameters are added to the request URL like:
[base]/Appointment/$find?practitioner.identifier=urn:oid:2.16.840.1.113883.4.6|1234567&start=2023-10-30&end=2023-11-30
Example: POST In case the Scheduling Client uses a POST method it is expected to add the search parameters to the request payload like:
POST [base]/Appointment/$find
{
"resourceType": "Parameters",
"parameter": [{
"name": "start",
"valueDateTime" : "2017-07-15T20:00:00Z"
},
{
"name": "end",
"valueDateTime" : "2017-07-17T20:00:00Z"
},
{
"name": "practitioner.identifier",
"valueIdentifier: "urn:oid:2.16.840.1.113883.4.6|1234567"
}]
}
Binding to CodeSets and ValueSets are expected to be localized. In no localization is available the Scheduling Client is expected to use a code from the:
Note 1: Practice Setting Code ValueSet.
Note 2: Appointment Reason Code ValueSet.
Note 3: Service Category ValueSet.
Note 4: Service Type ValueSet.
The Scheduling Client shall support FHIR Pagination when the Scheduling Server paginates its response.
Upon receiving a Find Potential Appointments request the Scheduling Server apply internal (business) logic to determine possible appointment (slots) that meet the search criteria specified by the Scheduling Client. The Scheduling Server returns a list of potential Appointment option the Scheduling Client can choose from to reserve or book an appointment.
The list of potential appointments is returned as a FHIR Bundle of type searchset
is returned containing 0, 1 or more Appointment resources
'’TODO: include IHE ITI Appointment Bundle Profile ‘’
The Scheduling Server shall make a best effort to find potential Appointments. Each Appointment resource included in the response Bundle should me as complete as possible allowing the Scheduling Client to render the appointment information in such a way a (human) user is able to reserver or book an appointment.
The Scheduling Server shall honour the _count
request parameter when included in the Find Appointments Query request by a Scheduling Client by limiting the number of potential appointments to match the _count
value.
The Scheduling Server shall include a total
attribute in the FHIR Bundle response indicating the total number of potential appointments it has determined.
The Scheduling Server may use pagination allowing a Scheduling Client to page through the results.
In the absence of any processing errors a http 200 (OK) error code is returned
In case security or other constraints prevent a Scheduling Server from returning a response to the Scheduling Client a http 4xx error code is returned
Table: Error Codes
Error Code | Description | Explanation |
---|---|---|
400 | Bad Request | The server cannot or will not process the request due to an apparent client error |
401 | Unauthorized | The server cannot or will not process the request due to an authorization issue with the request |
403 | Forbidden | The server cannot or will not process the request because the Scheduling Client (or a user) is not authorized for the request |
The Scheduling Server may include an OperationOutcome to the response where it uses the values from the Error Codes table.
Table: OperationOutcome Attributes
Attribute | Value |
---|---|
severity | Fatal |
code | <http error description> |
diagnostics | <http error explanation> |
Server implementing this transaction shall provide a CapabilityStatement Resource as described in ITI TF-2x: Appendix Z.3 indicating the transaction has been implemented.
See MHD Security Considerations
'’TODO: The security audit criteria ‘’
'’TODO: the specifics’’
'’TODO: the specifics’’