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

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.

Scope

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

Actors Roles

Table: 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

Referenced Standards

FHIR-R4 HL7 FHIR Release 4.0

Interactions

Figure: Hold Appointment Interactions

Hold Appointment Request

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

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

Message Semantics

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

Expected Actions

'’TODO: define expected actions’’

Go Response Message

Trigger Events

'’TODO: define the triggers’’

Message Semantics

'’TODO: define the message – usually with a StructureDefinition’’

Expected Actions

'’TODO: define expected actions’’

CapabilityStatement Resource

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

Security Considerations

See MHD Security Considerations

Security Audit Considerations

'’TODO: The security audit criteria ‘’

Client Audit

'’TODO: the specifics’’

Server Audit

'’TODO: the specifics’’