Merge pull request #55 from IHE/mlj_ITI_Scheduling_prepub_edits_Rev1-0-0

Prepublication edits of the ITI Scheduling IG Rev. 1.0.0

input/pagecontent/ITI-115.md

@@ -31,14 +31,14 @@ This transaction uses the `$find` operation as defined in the [Find Potential Ap
 
 ##### 2:3.115.4.1.1 Trigger Events
 
-When a Scheduling Client needs to find potential slot to book a new appointment it issues a "Find Potential Appointments" request.
+When a Scheduling Client needs to find potential slot to book a new appointment, it issues a "Find Potential Appointments" request.
 
 ##### 2:3.115.4.1.2 Message Semantics
 The Find Potential Appointment request is defined as a [FHIR Operation]({{site.data.fhir.path}}operations.html). Please see the corresponding [Find Potential Appointments Operation Definition](./OperationDefinition-appointment-find.html).
 
 ###### 2:3.115.4.1.2.1 Request Parameters
 
-The request parameters in the [table, which is part of the operation definition](OperationDefinition-appointment-find.html#root), are derived from search parameters defined for the [FHIR Appointment Resource]({{site.data.fhir.path}}appointment.html#search), and from additional functionally relevant entities, for example `organization` or `referral`.
+The request parameters in the [table, which is part of the operation definition](OperationDefinition-appointment-find.html#root), are derived from search parameters defined for the [FHIR Appointment Resource]({{site.data.fhir.path}}appointment.html#search) and from additional functionally relevant entities, for example `organization` or `referral`.
 
 **Example:**
 The Scheduling Client uses an HTTP POST with the body containing the search parameter like this:
@@ -65,7 +65,7 @@ POST  [base]/Appointment/$find
 
 ##### 2:3.115.4.1.3 Expected Actions
 
-Binding to CodeSets and ValueSets are expected to be localized. In no localization is available the Scheduling Client is expected to use a code from the: 
+Binding to CodeSets and ValueSets are expected to be localized. If no localization is available the Scheduling Client is expected to use a code from the: 
 
 Note 1: [Practice Setting Code ValueSet](https://hl7.org/fhir/R4/valueset-c80-practice-codes.html).
 
@@ -75,7 +75,7 @@ Note 3: [Service Category ValueSet](https://hl7.org/fhir/R4/valueset-service-cat
 
 Note 4: [Service Type ValueSet](https://hl7.org/fhir/R4/valueset-service-type.html).
 
-The Scheduling Client SHALLsupport [FHIR Pagination]({{site.data.fhir.path}}http.html#paging) when the Scheduling Server paginates its response.
+The Scheduling Client SHALL support [FHIR Pagination]({{site.data.fhir.path}}http.html#paging) when the Scheduling Server paginates its response.
 
 #### 2:3.115.4.2 Find Potential Appointments Response Message
 
@@ -97,13 +97,13 @@ 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.
+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.
+In the absence of any processing errors an http 200 (OK) error code is returned.
 
-In case security or other constraints prevent a Scheduling Server from returning a response to the Scheduling Client a http 4xx error code is returned.
+In case security or other constraints prevent a Scheduling Server from returning a response to the Scheduling Client an http 4xx error code is returned.
 
 <p id ="t3.115.4.2.4-1" class="tableTitle"><strong>Table 2:3.115.4.2.4-1: Error Codes</strong></p>
 

input/pagecontent/ITI-116.md

@@ -1,3 +1,4 @@
+
 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
@@ -63,13 +64,13 @@ After a successful `$hold` operation, the Scheduling Client can use the `$book`
 
 ### 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. 
+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](CapabilityStatement-IHE.Scheduling.client.html)
 - Requirements CapabilityStatement for [Server](CapabilityStatement-IHE.Scheduling.server.html)
 
 ### 2:3.116.6 Security Considerations
 
-See [IHE Scheduling Security Considerations](volume-1.html#security-considerations)
+See [IHE Scheduling Security Considerations](volume-1.html#security-considerations).
 
 #### 2:3.116.6.1 Security Audit Considerations
 

input/pagecontent/ITI-118.md

@@ -7,7 +7,8 @@ The Client [ITI-118] transaction requests a list of existing appointments from a
 ### 2:3.118.2 Actor Roles
 
 <p id ="t3.118.2-1" class="tableTitle"><strong>Table 2:3.118.2-1: Actor Roles</strong></p>
-|Actor | Role |
+
+| Actor | Role |
 |-------------------------------------------|
 | [Client](volume-1.html#client)  | Requests a list of appointments matching the supplied set of criteria (example: status, patient, service location, etc.) from the Scheduling Server. The Scheduling Client MAY choose to persist the information received, and/or render it for viewing |
 | [Server](volume-1.html#server) | Returns information from appointments matching the supplied set of criteria provided by the Scheduling Client |
@@ -43,11 +44,12 @@ The Scheduling Client MAY use a GET or POST based search. The Scheduling Server
 See the Server and Client Capability Statements for the search parameters applicable to the \[ITI-18\] transaction.
 
 <p id ="t3.118.4.1.3-1" class="tableTitle"><strong>Table 2:3.118.4.1.3-1: Search Parameters</strong></p>
+
 | Parameter | Type | Definition |
 |---------------------------------------------|
-| patient | ```reference``` | This parameter identifies the patient actor participating in this appointment either by its fhir resource id (if known to the Scheduling Client), or by a business identifier known for this patient. In case of a business identifier it is strongly recommended to use both the identifying system and value (i.e. patient.identifier=\<system>\|\<value>). If no \<system> is supplied the Scheduling Server MAY use internal logic to interpret the \<value> |
+| patient | ```reference``` | This parameter identifies the patient actor participating in this appointment either by its fhir resource id (if known to the Scheduling Client), or by a business identifier known for this patient. In case of a business identifier it is strongly recommended to use both the identifying system and value (i.e., patient.identifier=\<system>\|\<value>). If no \<system> is supplied the Scheduling Server MAY use internal logic to interpret the \<value> |
 | date | ```date``` | This parameter defines the date range to search for appointments. Normal [date]({{site.data.fhir.path}}search.html#date) prefixes apply. |
-| practitioner | ```reference``` | This parameter identifies the practitioner actor participating in this appointment either by its fhir resource id (if known to the Scheduling Client), or by a business identifier known for this practitioner. In case of a business identifier it is strongly recommended to use both the identifying system and value (i.e. practitioner.identifier=\<system>\|\<value>). If no \<system> is supplied the Scheduling Server MAY use internal logic to interpret the \<value> |
+| practitioner | ```reference``` | This parameter identifies the practitioner actor participating in this appointment either by its fhir resource id (if known to the Scheduling Client), or by a business identifier known for this practitioner. In case of a business identifier it is strongly recommended to use both the identifying system and value (i.e., practitioner.identifier=\<system>\|\<value>). If no \<system> is supplied the Scheduling Server MAY use internal logic to interpret the \<value> |
 | status | ```token``` | This parameter reflects the overall status of the appointment as defined in [AppointmentStatus]({{site.data.fhir.path}}codesystem-appointmentstatus.html) |
 | location | ```reference``` | This parameter identifies the location actor participating in this appointment either by its fhir resource id (if known to the Scheduling Client), or by a name known for this location.|
 | specialty | ```token``` | This parameter identifies the specialty of a practitioner that would be required to perform the service requested in this appointment |
@@ -58,11 +60,11 @@ For example, search appointments for patient (identifier 12345), after October 2
 ```GET https://server.example.com/fhir/4/Appointment?patient.identifier=urn:oid:1.2.3.4.5|12345&date=gt20231021&practitioner.identifier=urn:oid:2.16.840.1.113883.4.6|12345678```
 
 ###### 2:3.118.4.1.3.1 Patient Identifiers
-Patient identifier SHALL be fully qualified and consist of an identifier value and system (a.k.a. assigning authority or patient identity domain). Preferably identifier systems are identified with an OID value (e.g. urn:oid:1.2.3.4.5). Alternatively a URI value MAY be used (e.g. http://hl7.org/fhir/sid/us-ssn or http://hospital-1.org). 
+Patient identifier SHALL be fully qualified and consist of an identifier value and system (a.k.a. assigning authority or patient identity domain). Preferably identifier systems are identified with an OID value (e.g., urn:oid:1.2.3.4.5). Alternatively a URI value MAY be used (e.g., http://hl7.org/fhir/sid/us-ssn or http://hospital-1.org). 
 
 In the case when the Scheduling Server is not able to process a identifier system in a Find Existing Appointments Query transaction it SHALL return a FHIR bundle of type `searchset` with 0 entries.
 
-The case where the Scheduling Client mey need to provided multiple patient.identifiers, all belonging to the same patient as known to the client, is considered out of scope for the ITI Scheduling Profile. 
+The case where the Scheduling Client may need to provided multiple patient.identifiers, all belonging to the same patient as known to the client, is considered out of scope for the ITI Scheduling Profile. 
 
 ###### 2:3.118.4.1.3.2 _count
 A Scheduling Client MAY add a `_count` parameter to the Find Appointment Query request to limit the number of responses. 
@@ -72,7 +74,7 @@ A Scheduling Client MAY add a `_include` parameter to request a Scheduling Serve
 
 ##### 2:3.118.4.1.4 Expected Actions
 
-<p id ="t3.118.4.1.4-1" class="tableTitle"><strong>Table 2:3.118.4.1.4-1: Search parameter optionality</strong></p>
+<p id ="t3.118.4.1.4-1" class="tableTitle"><strong>Table 2:3.118.4.1.4-1: Search Parameter Optionality</strong></p>
 
 | Parameter | Client | Server |
 |-------------------|
@@ -114,6 +116,7 @@ In the absence of any processing errors a http 200 (OK) error code is returned.
 In case security constraints prevent a Scheduling Server from returning a response to the Scheduling Client a http 4xx error code is returned as described in Volume 2, Appendix Z.
 
 <p id ="t3.118.4.2.4-1" class="tableTitle"><strong>Table 2:3.118.4.2.4-1: Error Codes</strong></p>
+
 |Error Code | Description | Explanation |
 |----------------------|
 |400 | Bad Request | The server cannot or will not process the request due to an apparent client error |
@@ -124,6 +127,7 @@ In case security constraints prevent a Scheduling Server from returning a respon
 The Scheduling Server MAY include an OperationOutcome to the response where it uses the values from the Error Codes table.
 
 <p id ="t3.118.4.2.4-2" class="tableTitle"><strong>Table 2:3.118.4.2.4-2: OperationOutcome Attributes</strong></p>
+
 | Attribute | Value | 
 |---------|
 | severity | Fatal |

input/pagecontent/issues.md

@@ -12,14 +12,14 @@ For those without GitHub access, issues can be submitted to the [PCC Public Comm
 As issues are submitted they will be managed on the [ITI.Scheduling GitHub Issues](https://github.com/IHE/ITI.Scheduling/issues), where discussion and workarounds can be found. These issues, when critical, will be processed using the normal [IHE Change Proposal](https://wiki.ihe.net/index.php/Category:CPs) management and balloting. 
 It is important to note that as soon as a Change Proposal is approved, it carries the same weight as a published Implementation Guide (i.e., it is testable at an [IHE Connectathon](https://www.ihe.net/participate/connectathon/) from the time it is approved, even if it will not be integrated until several months later).
 
-#### Open Issues
+### Open Issues
 
-* ITI-Scheduling-001: `$book` only, or `$book` and `$modify`? The current approach is to provide three distinct uses for the `$book` operation. See the [`$book` operation](./OperationDefinition-appointment-book.html) for details. \([Issue 31](https://github.com/IHE/ITI.Scheduling/issues/31)\)
-* ITI-Scheduling-002: Should there be a named option for supporting the [Appointment Hold \[ITI-16\]](./ITI-116.html) transaction? \([Issue 32](https://github.com/IHE/ITI.Scheduling/issues/32)\)
-* ITI-Scheduling-003: Should there be a named option for supporting the [Find Existing Appointments \[ITI-18\]](./ITI-118.html) transaction? \([Issue 33](https://github.com/IHE/ITI.Scheduling/issues/33)\)
-* ITI-Scheduling-004: Need to add Resource Examples \([Issue 26](https://github.com/IHE/ITI.Scheduling/issues/26)\)
-* ITI-Scheduling-005: Need a Test Plan \([Issue 20](https://github.com/IHE/ITI.Scheduling/issues/20)\)
-* ITI-Scheduling-006: Need Audit Events for \[ITI-115\], \[ITI-116\], and \[ITI-118\] \([Issue 30](https://github.com/IHE/ITI.Scheduling/issues/30)\)
+- ITI-Scheduling-001: `$book` only, or `$book` and `$modify`? The current approach is to provide three distinct uses for the `$book` operation. See the [`$book` operation](./OperationDefinition-appointment-book.html) for details. \([Issue 31](https://github.com/IHE/ITI.Scheduling/issues/31)\)
+- ITI-Scheduling-002: Should there be a named option for supporting the [Appointment Hold \[ITI-16\]](./ITI-116.html) transaction? \([Issue 32](https://github.com/IHE/ITI.Scheduling/issues/32)\)
+- ITI-Scheduling-003: Should there be a named option for supporting the [Find Existing Appointments \[ITI-18\]](./ITI-118.html) transaction? \([Issue 33](https://github.com/IHE/ITI.Scheduling/issues/33)\)
+- ITI-Scheduling-004: Need to add Resource Examples \([Issue 26](https://github.com/IHE/ITI.Scheduling/issues/26)\)
+- ITI-Scheduling-005: Need a Test Plan \([Issue 20](https://github.com/IHE/ITI.Scheduling/issues/20)\)
+- ITI-Scheduling-006: Need Audit Events for \[ITI-115\], \[ITI-116\], and \[ITI-118\] \([Issue 30](https://github.com/IHE/ITI.Scheduling/issues/30)\)
 
-#### Closed Issues
+### Closed Issues
 No closed issues.

input/pagecontent/other.md

@@ -10,8 +10,8 @@ This section contains modifications to other IHE publications and profiles and i
 
 | Actor                         | Definition                                                                                |
 | ----------------------------- | ------------------------------------------------------------------------------------------|
-| Scheduling Client | A system which can request information about existing appointments, about potential appointments, and can request the creation, modification or cancellation of an appointment. |
-| Scheduling Server | A system which manages existing appointments and provides an API for clients to query, create, modify, or cancel an appointment. |
+| Scheduling Client | Requests information about appointments and requests the creation, modification or cancellation of an appointment. |
+| Scheduling Server | Manages appointments and provides an API for clients to query, create, modify, or cancel an appointment. |
 {:.grid .table-striped}
 
 

input/pagecontent/testplan.md

@@ -2,16 +2,16 @@
 
 ## Test Plan
 
-**TODO: include actor based tests, include positive and edge cases. **
+**TODO: include actor based tests, include positive and edge cases.
 
 ### Unit Test Procedure
 
 Unit Tests in this context is where a SUT is tested against a simulator or validator.  A simulator is a implementation of an actor that is designed specifically to test the opposite pair actor. The simulator might be a reference implementation or may be a specially designed test-bench. Where a reference implementation is used the negative tests are harder to simulate. A validator is a implementation that can check conformance. A validator may be a simulator, but may also be a standalone tool used to validate only a message encoding. Some reference implementations may be able to validate to a StructureDefinition profile, but often these do not include sufficient constraints given the overall actor conformance criteria. 
 
 ### Integration Test Procedure
 
-Integration Tests in this context is where two SUT of paired actors test against each other. In this case the subset of tests that can be tested is the intersection. Testing only this intersection is necessary but not sufficient. The testing must also include the capability of the client to exercise the test scenarios that this SUT can test, to determine that failure-modes are handled properly by both SUT.
+Integration Tests in this context is where two SUT of paired actors test against each other. In this case, the subset of tests that can be tested is the intersection. Testing only this intersection is necessary but not sufficient. The testing must also include the capability of the client to exercise the test scenarios that this SUT can test, to determine that failure-modes are handled properly by both SUT.
 
 ### Cucumber
 
-**TODO: Write specific Cucumber statements, might use external tooling?**
+**TODO: Write specific Cucumber statements, might use external tooling?