Bvdh sept2024 ballot technical corrections

source/async-bulk.html

@@ -54,7 +54,7 @@ <h5 id="headers">Headers</h5>
  <li>
  <p><code>Prefer</code> (string, required)</p>
  <p>Specifies whether the response is immediate or asynchronous. Setting this to <code>respond-async</code>
- triggers this async pattern.</p>
+ triggers the async pattern.</p>
  </li>
  </ul>
 

source/async-bundle.html

@@ -67,7 +67,7 @@ <h5 id="headers">Headers</h5>
  <li>
  <p><code>Prefer</code> (string, required)</p>
  <p>Specifies whether the response is immediate or asynchronous. Setting this to <code>respond-async</code>
- triggers this async pattern.</p>
+ triggers the async pattern.</p>
  </li>
  </ul>
 

source/async.html

@@ -35,6 +35,7 @@ <h3 id="use-case">Use Case</h3>
  </p>
 
  <h3 id="patterns">Patterns</h3>
+ <p>FHIR supports two asynchronous patterns:</p>
  <ul>
  <li><a href="async-bulk.html">Asynchronous Bulk Data Request</a> - for use in FHIR <a href="operations.html">Operations</a>
  and <a href="http.html">Defined Interactions</a> that return a large amount of data. This pattern returns a

source/consent/consent-example-notAuthor.xml

@@ -9,7 +9,7 @@
  <p>The following scenario is based on existing jurisdictional policy and are realized in existing systems in Canada. 
  The default policy is one of implied consent for the provision of care, so these scenarios all deal with withdrawal or withholding consent for that purpose. 
  This example is to withhold or withdraw consent for disclosure of records that were authored by a specific organization (or service delivery location).</p>
- <p>Patient "P. van de Heuvel" wishes to have all of the PHI collected at the Burgers University Medical Center restricted from disclosure to every provider.</p>
+ <p>Patient "P. van de Heuvel" wishes to have all of the PHI (Personal health information) collected at the Burgers University Medical Center restricted from disclosure to every provider.</p>
  </div>
  </text>
  <status value="active"/>

source/consent/consent-example.xml

@@ -8,7 +8,7 @@
  Authorize Normal access for Treatment
  </p>
  <p>
- Patient "Peter James Chalmers ("Jim")" wishes to have all of the PHI collected at the Burgers University Medical Center available for normal treatment use.
+ Patient "Peter James Chalmers ("Jim")" wishes to have all of the PHI (Personal health information) collected at the Burgers University Medical Center available for normal treatment use.
  </p>
  </div>
  </text>

source/contract/pcd-example-notAuthor.xml

@@ -12,7 +12,7 @@
  model is used (Opt-In), these would examples would contain the phrase "consent to" rather than
  "withhold" or "withdraw" consent for. <p> specific to use-case 5) Withhold or withdraw consent
  for disclosure of records that were authored by a specific organization (or service delivery
- location). </p><p> Patient "P. van de Heuvel" wishes to have all of the PHI collected at the
+ location). </p><p> Patient "P. van de Heuvel" wishes to have all of the PHI (Personal health information) collected at the
  Good Health Psychiatric Hospital restricted from disclosure to every provider. </p>
  </div>
  </text>

source/fivews/fivews-spreadsheet-introduction.xml

@@ -13,7 +13,8 @@ All resources include some attribution information. Classically, this informatio
  <li>Why</li>
 </ul>
 <p>
-This is classically known as the 'Five Ws' - hence the name of this pattern. The pattern also includes 
+
+This is classically known as the '<a href="https://en.wikipedia.org/wiki/Five_Ws">Five Ws</a>' - hence the name of this pattern. The pattern also includes 
 additional information that is common across many resources.
 </p>
 <p>

source/security.html

@@ -378,7 +378,7 @@ <h2>Audit Logging</h2>
 <p>
 For HTTP logs, implementers need to consider the implications of distributing
 access to the logs. HTTP logs, including those that only contain the URL itself, should be 
-regarded as being as sensitive as the resources themselves. Even if direct PHI is kept out of
+regarded as being as sensitive as the resources themselves. Even if direct PHI (Personal health information) is kept out of
 the logs by careful avoidance of search parameters (e.g. by using POST), the logs will
 still contain a rich set of information about the clinical records. 
 </p>

source/servicerequest/servicerequest-introduction.xml

@@ -33,11 +33,10 @@ Examples include:
 </p>
  <p>The principal intention of ServiceRequest is to support ordering procedures for one patient (which includes non-human patients in veterinary medicine). However, in many contexts, healthcare related processes include performing diagnostic investigations on groups of subjects, devices involved in the provision of healthcare, and even environmental locations such as ducts, bodies of water, etc. ServiceRequest supports all these usages. The service request may represent an order that is entered by a practitioner in a CPOE system as well as a proposal made by a clinical decision support (CDS) system based on a patient's clinical record and context of care. Planned procedures referenced by a <a href="careplan.html">CarePlan</a> may also be represented by this resource. </p>
  <p>The general work flow that this resource facilitates is that a clinical system creates a service request. The service request is then accessed by or exchanged with a system, perhaps via intermediaries, that represents an organization (e.g., diagnostic or imaging service, surgical team, physical therapy department) that can perform the procedure. The organization receiving the service request will, after it accepts the request, update the request as the work is performed, and then finally issue a report that references the requests that it fulfilled.</p>
- <p>The ServiceRequest resource allows requesting only a single procedure. If a workflow requires requesting multiple procedures simultaneously, this is done using multiple instances of this resource. These instances can be linked in different ways, depending on the needs of the workflow. For guidance, refer to the <a href="request.html">Request pattern</a>
+ <p>The ServiceRequest resource allows requesting only a single procedure. If a workflow requires requesting multiple procedures simultaneously, this is done using multiple instances of this resource. These instances can be linked in different ways, depending on the needs of the workflow. For guidance, refer to the <a href="request.html">Request pattern</a>.
  </p>
  </div>
  <div>
- <a name="bnr"></a><a href="request.html">Request pattern</a>
  <h2>Boundaries and Relationships</h2>
  <p>
  ServiceRequest is a record of a proposal/plan or order for a service to be performed that would result in a <a href="procedure.html">Procedure</a>,

source/servicerequest/structuredefinition-ServiceRequest.xml

@@ -498,7 +498,7 @@
  </extension>
  <path value="ServiceRequest.code"/>
  <short value="What is being requested/ordered"/>
- <definition value="A code or reference that identifies a particular service (i.e., procedure, diagnostic investigation, or panel of investigations) that have been requested."/>
+ <definition value="A code or reference that identifies a particular service (i.e., procedure, diagnostic investigation, or panel of investigations) that has been requested."/>
  <comment value="Many laboratory and radiology procedure codes embed the specimen/organ system in the test order name, for example, serum or serum/plasma glucose, or a chest x-ray. The specimen might not be recorded separately from the test code."/>
  <alias value="service requested"/>
  <min value="0"/>

source/subscription/structuredefinition-Subscription.xml

@@ -374,9 +374,9 @@
  </element>
  <element id="Subscription.parameter">
  <path value="Subscription.parameter"/>
- <short value="Channel type"/>
+ <short value="Channel type dependent information"/>
  <definition value="Channel-dependent information to send as part of the notification (e.g., HTTP Headers)."/>
- <comment value="Exactly what these mean depend on the channel type. They can convey additional information to the server or recipient and/or meet security requirements; for example, support of multiple headers in the outgoing notifications for rest-hook type subscriptions. Note that names are not required to be unique, but channel definitions can impose restrictions."/>
+ <comment value="Exactly what these mean depends on the channel type. They can convey additional information to the server or recipient and/or meet security requirements; for example, support of multiple headers in the outgoing notifications for rest-hook type subscriptions. Note that names are not required to be unique, but channel definitions can impose restrictions."/>
  <min value="0"/>
  <max value="*"/>
  <type>

source/subscription/subscription-introduction.xml

@@ -16,7 +16,7 @@
  the server.
  </p>
  <p>
- Via the <code>Subscription.content</code>, subscriptions can be configured to send notifications that include full resource content, just the ID of the triggering resource, or an empty notification body.
+ Using the <code>Subscription.content</code>, subscriptions can be configured to send notifications that include full resource content, just the ID of the triggering resource, or an empty notification body.
  </p>
  <p>
  Several channels are defined in the core specification:

source/subscription/subscription-notes.xml

@@ -18,7 +18,7 @@
  There are three options available when specifying the contents of a Notification: <code>empty</code>, <code>id-only</code>, and <code>full-resource</code>. These options change the level of detail conveyed in the notification <code>Bundle</code>.
  </p>
  <p>
- When deciding which payload type to request, systems SHOULD consider both ease of processing and security of PHI. To mitigate the risk of information leakage, systems SHOULD use the minimum level of detail consistent with the use case. In practice, <code>id-only</code> provides a good balance between security and performance for many real-world scenarios.
+ When deciding which payload type to request, systems SHOULD consider both ease of processing and security of PHI (Personal health information). To mitigate the risk of information leakage, systems SHOULD use the minimum level of detail consistent with the use case. In practice, <code>id-only</code> provides a good balance between security and performance for many real-world scenarios.
  </p>
  <p>
  If a server cannot or will not honor a payload type (e.g., will not send <code>full-resource</code> over HTTP), it SHOULD reject the Subscription request. A server MAY instead accept the subscription with modifications and return the accepted version to the client.

source/subscriptionstatus/subscriptionstatus-notes.xml

@@ -7,7 +7,7 @@
  </p>
 
  <a name="content-phi"/>
- <h2>Content and PHI</h2>
+ <h2>Content and PHI (Personal health information)</h2>
  <p>
  Subscription notifications MAY contain PHI. Applications are responsible for following <a href="security.html">FHIR security guidance</a> and compliance with relevant security requirements (e.g., corporate policy, government regulation, etc.). Hinting for the allowed amount of PHI is available in the relevant <code>Subscription</code> resource, via the channel and payload information.
  </p>

source/task/structuredefinition-Task.xml

@@ -46,7 +46,7 @@
  <value value="http://www.hl7.org/Special/committees/orders/index.cfm"/>
  </telecom>
  </contact>
- <description value="A task to be performed as a part of a workflow and the related informations like inputs, outputs and execution progress."/>
+ <description value="A task to be performed as a part of a workflow and the related information like inputs, outputs and execution progress."/>
  <fhirVersion value="6.0.0"/>
  <mapping>
  <identity value="workflow"/>
@@ -77,7 +77,7 @@
  <element id="Task">
  <path value="Task"/>
  <short value="A task to be performed"/>
- <definition value="A task to be performed as a part of a workflow and the related informations like inputs, outputs and execution progress. While very simple workflows can be implemented with Request alone, most workflows would require a Task (explicit or contained) as a means to track the execution data (i.e. inputs, outputs, status). Please refer to the workflow page for more details."/>
+ <definition value="A task to be performed as a part of a workflow and the related informations like inputs, outputs and execution progress. While very simple workflows can be implemented with Request alone, most workflows would require a Task (explicit or contained) as a means to track the execution data (i.e. inputs, outputs, status). Please refer to the <a href="workflow.html">FHIR Workflow</a> page for more details."/>
  <min value="0"/>
  <max value="*"/>
  <constraint>
@@ -320,7 +320,7 @@
  <element id="Task.intent">
  <path value="Task.intent"/>
  <short value="unknown | proposal | plan | order | original-order | reflex-order | filler-order | instance-order | option"/>
- <definition value="Indicates the &quot;level&quot; of actionability associated with the Task, i.e. i+R[9]Cs this a proposed task, a planned task, an actionable task, etc."/>
+ <definition value="Indicates the &quot;level&quot; of actionability associated with the Task, i.e. this a proposed task, a planned task, an actionable task, etc."/>
  <comment value="This element is immutable. Proposed tasks, planned tasks, etc. must be distinct instances.&#xA;&#xA;In most cases, Tasks will have an intent of &quot;order&quot;."/>
  <min value="1"/>
  <max value="1"/>
@@ -652,7 +652,7 @@
  </element>
  <element id="Task.requestedPerformer">
  <path value="Task.requestedPerformer"/>
- <short value="Who should perform Task"/>
+ <short value="Who should perform the Task"/>
  <definition value="The kind of participant or specific participant that should perform the task."/>
  <requirements value="Use to distinguish tasks on different activity queues."/>
  <min value="0"/>