Scheduling
1.0.0-current - ci-build
Scheduling, published by IHE IT Infrastructure Technical Committee. This guide is not an authorized publication; it is the continuous build for version 1.0.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-116] of the IHE Technical Framework. Transaction [ITI-116] is used by the Scheduling Client and Scheduling Server Actors. The Hold Appointment [ITI-116] transaction is used to request that a specific appointment (selected from one of the available potential appointments returned with the response of a preceding [ITI-115] query) is held by the Scheduling Server, until the appointment is booked, cancelled, or the hold expires.
The Hold Appointment [ITI-116] transaction is used by a Scheduling Client to request a hold for a specific appointment from the Scheduling Server.
Table 2:3.116.2-1: Actor Roles
Actor | Role |
---|---|
Scheduling Client | Sends a "Hold Appointment" request to Server |
Scheduling Server | Receives and processes "Hold Appointment" request and responds with a successful hold or an unsuccessful outcome |
Figure 2:3.116.4-1: Hold Appointment Interactions
This transaction uses the $hold
operation as defined in the Operation Definition.
This is an optional transaction in the ITI Scheduling Profile. and in cases where the requester needs additional information, or needs to perform additional steps before an appointment is booked, the Scheduling client can request a hold for a specific potential appointment that is the result of a Find Potential Appointments [ITI-115] transaction.
The Hold Appointment request is defined as a FHIR Operation. Please see the corresponding Operation Definition.
The Scheduling Server is expected to hold the necessary time slots and resources for the potential appointment to take place at the given time and for the given duration.
Note that it is possible that between the time the Find Potential Appointments [ITI-115] response was received, and the time the Hold Appointment [ITI-116] request is issued, the requested appointment is no longer available. In such case, the server SHALL respond with an OperationOutcome that describes the issue.
The response to the $hold operation is an Appointment resource or an OperationOutcome resource. The Appointment resource SHALL have the Appointment.status
set to pending
.
The response is an ITI Scheduling Appointment Bundle. A successful $hold operation SHALL return a single Appointment resource within the bundle, and MAY have an additional OperationOutcome resource with supplemental information. An unsuccessful $hold operation SHALL return only an OperationOutcome resource describing the problem with satisfying the operation.
A successful $hold
operation SHALL result in the server refusing any other attempts to schedule the time slot and any other needed resources that MAY invalidate the held Appointment.
For the case where the Appointment is not available to be held, the server SHALL return an OperationOutcome with at least one issue
with severity
of fatal
and code
of not-found
for the Appointment resource.
After a successful $hold
operation, the Scheduling Client can use the $book
operation using the appointment-reference
parameter to complete the booking.
A 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 IHE Scheduling Security Considerations
''TODO: The security audit criteria ''
''TODO: the specifics''
''TODO: the specifics''