This page is part of the IHE ITI Scheduling (v1.0.0: Publication) 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

• HL7 FHIR Release 4

2:3.116.4 Messages

2:3.116.4.1 Hold Appointment Request

This transaction uses the $hold operation as defined in the Hold Appointment 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 Hold Appointment 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.

After a successful $hold operation, the Scheduling Client can use the $book operation using the appointment-reference parameter to complete the booking.

2:3.116.5 CapabilityStatement Resource

A Server implementing this transaction SHALL provide a CapabilityStatement Resource as described in ITI TF-2: 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

The Hold Appointment Transaction is a Patient Record event as defined in Table 3.20.4.1.1.1-1. The actors involved SHALL record audit events according to the following:

2:3.116.6.1.1 Client Audit

The Scheduling Client, when grouped with the ATNA Secure Node or Secure Application Actor, SHALL be able to record an audit event consistent with the Hold Appointment Source AuditEvent. Audit Example for a Hold Appointment transaction from the client perspective.

2:3.116.6.1.2 Server Audit

The Scheduling Server, when grouped with the ATNA Secure Node or Secure Application Actor, SHALL be able to record an audit event consistent with the Hold Appointment Recipient AuditEvent. Audit Example for a Hold Appointment transaction from the server perspective.

2:3.116.7 Other Profile Groupings

Both the Scheduling Client and Scheduling Server MAY be grouped with their respective Internet User Authentication (IUA) Actors.