Scheduling
1.0.0-comment - ballot International flag

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

2:3.116 Hold Appointment [ITI-116]

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.

2:3.116.1 Scope

The Hold Appointment [ITI-116] transaction is used by a Scheduling Client to request a hold for a specific appointment from the Scheduling Server.

2:3.116.2 Actor Roles

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

2:3.116.3 Referenced Standards

FHIR-R4 HL7 FHIR Release 4.0

2:3.116.4 Messages

Scheduling ClientScheduling Server1. Hold Appointment Request [ITI-116]2. Hold Appointment Response [ITI-116]


Figure 2:3.116.4-1: Hold Appointment Interactions

2:3.116.4.1 Hold Appointment Request

This transaction uses the $hold operation as defined in the Operation Definition.

2:3.116.4.1.1 Trigger Events

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.

2:3.116.4.1.2 Message Semantics

The Hold Appointment request is defined as a FHIR Operation. Please see the corresponding Operation Definition.

2:3.116.4.1.3 Expected Actions

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.

2:3.116.4.2 Hold Appointment Response Message

2:3.116.4.2.1 Trigger Events

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.

2:3.116.4.2.2 Message Semantics

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.

2:3.116.4.2.3 Expected Actions

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.

2:3.116.5 CapabilityStatement Resource

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.

  • Requirements CapabilityStatement for Client
  • Requirements CapabilityStatement for Server

2:3.116.6 Security Considerations

See IHE Scheduling Security Considerations

2:3.116.6.1 Security Audit Considerations

''TODO: The security audit criteria ''

2:3.116.6.1.1 Client Audit

''TODO: the specifics''

2:3.116.6.1.2 Server Audit

''TODO: the specifics''