Pc resolution

input/pagecontent/ITI-115.md

@@ -97,6 +97,8 @@ The Scheduling Server SHALL include a ```total``` attribute in the FHIR Bundle r
 
 The Scheduling Server MAY  use [pagination]({{site.data.fhir.path}}http.html#paging) allowing a Scheduling Client to page through the results.
 
+The Scheduling Server SHALL NOT include any held appointments (i.e. appointments that were reserved as a result of a previous ```$hold``` operation, and for which the holding period had not expired) in the list of potential appointments.
+
 ##### 2:3.115.4.2.4 Error Codes
 
 In the absence of any processing errors a http 200 (OK) error code is returned.

input/pagecontent/ITI-116.md

@@ -57,9 +57,11 @@ The response is an [ITI Scheduling Appointment Bundle](./StructureDefinition-ihe
 
 ##### 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.
+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.
+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
 

input/pagecontent/volume-1.md

@@ -133,12 +133,20 @@ There are no required groupings for this profile.
 
 ## 1:55.4 Scheduling Overview
 
-This section shows how the transactions of the profile are combined to address the use cases.
+This profile is intended to address use cases for cross-organizational or patient initiated scheduling of healthcare appointments.
+
+The following subsections show how the transactions of the profile are combined to address the use cases.
 
 ### 1:55.4.1 Concepts
 
 The FHIR specification defines several resources to describe scheduling-related information. The  [Schedule]({{site.data.fhir.path}}schedule.html), [Slot]({{site.data.fhir.path}}slot.html), and [Appointment]({{site.data.fhir.path}}appointment.html) resources are intended to be compatible with the [iCalendar specification](https://datatracker.ietf.org/doc/html/rfc5545). A survey of existing implementations, however, showed that there is very little commonality among existing FHIR server implementations, which suggests that an operation-based specification will improve interoperability in this area.
 
+#### 1:55.4.1.1 Scope
+
+There is wide variety of appointments that pertain to the healthcare domain. A core assumption of this profile is that the Scheduling Server actor is responsible for all the business logic for determining the type, duration, sequencing, and all other attributes an appointment may have. This is the reason that the response to the search for potential appointments only contains Appointment resources. The management of Schedule and Slot resources is out of scope for this profile.
+
+For example, the Scheduling server may modify existing appointments in order to free up time for an urgent appointment. While this may change the existing ```Schedule``` and ```Slot``` resources, the Scheduling Client that is attempting to book the urgent appointment only needs to know that a new appointment can be booked. Any changes to existing appointments can be detected using [\[ITI-118\]](./ITI-118.html), or, if the ITI Scheduling profile is implemented in an environment with an existing FHIR Subscription infrastructure, via a ```SubscriptionNotification``` for the changed appointment(s).
+
 The overall functionality covered by this profile is as follows:
 1. The Scheduling Client identifies the patient or patients for whom the appointment will be scheduled
 2. The Scheduling Client determines the available parameters for requesting a list of available appointments

input/resources/operationdefinition-appointment-find.xml

@@ -18,7 +18,7 @@
 		</coding>
 	</jurisdiction>
 	<code value="find"/>
-	<comment value="- For input parameters that are codes, the simple FHIR [token](https://hl7.org/fhir/R4/search.html#token) search parameter type is used instead of the complex `Coding` datatype. This allows either the 'GET'  or the 'POST' syntax to be used to initiate the interaction in many cases. The `Reference` datatype is used for resources references, which allows the requester to use either a reference to existing resource, or an identifier ([logical reference](https://hl7.org/fhir/R4/references-definitions.html#Reference.identifier)). Examples of both are shown below.  &#10;- If more than one actor type is present, the response SHOULD contain appointments with *all* of these actors (i.e, this is a logical 'AND').  If an actor type is repeated, the response SHOULD contain appointments with *any* of these actors and SHOULD be interpreted as the order of preference (i.e. this is a logical  'OR' and  does not drive a joint appointment with multiple practitioners. locations or organizations). Ultimately the server is responsible for determining the first/best available appointment options to return.  &#10;- References can be to an absolute URL, but the Scheduling Server can create or modify resources only  on the resources on the server or a defined domain.  &#10;- To set the upper limit on the total number of available appointment options to return use the standard [`_count`](https://hl7.org/fhir/R4/search.html#count) search parameter.  See the examples below for how this is implemented."/>
+	<comment value="- For input parameters that are codes, the simple FHIR [token](https://hl7.org/fhir/R4/search.html#token) search parameter type is used instead of the complex `Coding` datatype. This allows either the 'GET'  or the 'POST' syntax to be used to initiate the interaction in many cases. The `Reference` datatype is used for resources references, which allows the requester to use either a reference to existing resource, or an identifier ([logical reference](https://hl7.org/fhir/R4/references-definitions.html#Reference.identifier)). Examples of both are shown below.  &#10;- If multiple patients are provided as parameters, this conveys the need for a group appointment. &#10;- If more than one non-patient participant type of parameter is present (e.g. a Provider and a Location), the response SHOULD contain appointments with *all* of these participants (i.e, this is a logical 'AND'). If a particular participant type is repeated, the response SHOULD contain appointments with *any* of these participants and SHOULD be interpreted as the order of preference (i.e. this is a logical  'OR' and  does not drive a joint appointment with multiple practitioners. locations or organizations). Ultimately the server is responsible for determining the first/best available appointment options to return.  &#10;- References can be to an absolute URL, but the Scheduling Server can create or modify resources only  on the resources on the server or a defined domain.  &#10;- To set the upper limit on the total number of available appointment options to return use the standard [`_count`](https://hl7.org/fhir/R4/search.html#count) search parameter.  See the examples below for how this is implemented. &#10;- The Scheduling Server SHALL NOT include any held appointments (i.e. appointments that were reserved as a result of a previous ```$hold``` operation, and for which the holding period had not expired) in the list of potential appointments."/>
 	<resource value="Appointment"/>
 	<system value="false"/>
 	<type value="true"/>