Trivial editorial changes

https://jira.digitalhealth.gov.au/browse/AN-472
https://jira.digitalhealth.gov.au/browse/AN-473
https://jira.digitalhealth.gov.au/browse/AN-474

examples/PractitionerRole/practitionerrole-strempel-sonia-gp.xml

@@ -4,19 +4,6 @@
     <meta>
         <profile value="http://ns.electronichealth.net.au/fhir/StructureDefinition/dh-practitionerrole-core-1" />
     </meta>
-    <text>
-        <status value="additional"/>
-        <div xmlns="http://www.w3.org/1999/xhtml" lang="en-AU">
-            <p><b>Practitioner Role</b>: General Practitioner Registrar</p>
-            <p><b>Identifier</b>: Medicare Provider Number = 5544887B</p>
-            <p><b>Practitioner</b>: Dr Sonia Strempel; telecom = email
-                [email protected] (work)</p>
-            <p><b>Organization</b>: Top End Medical Clinic; HPI-O = 8003621566684455;
-                ABN = 51824754455; telecom = phone (08) 8948 9999 (work); telecom = url
-                = https://territorymedicalcentre.com.au (work); address = 159 Clematis
-                Street, Nightcliff NT 0810</p>
-        </div>
-    </text>
     <identifier>
         <type>
             <coding>

pages/_includes/conformance.md

@@ -23,7 +23,7 @@ To support an ADHA profile:
 
 ## Must Support
 
-Labelling an element [Must Support]( https://www.hl7.org/fhir/conformance-rules.html#mustSupport) means that implementations that produce or consume resources **SHALL** provide "support" for the element in some meaningful way. ADHA profiles impose a core set of must support obligations on classes of implementations based on roles and data services. Some implementation contexts require additional support, e.g. ePrescribing. The publications and/or profiles that define a particular implementation context **SHALL** make clear the required "support" for that context. 
+Labelling an element [Must Support]( https://www.hl7.org/fhir/conformance-rules.html#mustSupport) means that implementations that produce or consume resources **SHALL** provide "support" for the element in some meaningful way. ADHA profiles impose a core set of must support obligations on classes of implementations based on roles and data services. Some implementation contexts require additional support, e.g. ePrescribing. The specifications and/or profiles that define a particular implementation context **SHALL** make clear the required "support" for that context. 
 
 A sending system:
 - when making a request to an endpoint **SHALL** conform to the Conformance/CapabilityStatement for that endpoint and conform to all applicable ADHA conformance requirements 
@@ -52,7 +52,7 @@ A persisting system:
 
 When viewing the raw JSON of a profile, elements labelled *Must Support* are flagged with a boolean element `mustSupport` set to "true". 
 
-Example: ADHA Core AllergyIntolerance profile showing clinicalStatus and verificationStatus flagged with Must Support.
+Example: ADHA Core AllergyIntolerance profile showing clinicalStatus and verificationStatus flagged with Must Support
 ~~~
 {
     "resourceType" : "StructureDefinition",
@@ -85,10 +85,10 @@ Implementers should take note that the full set of constraints (i.e. invariants)
 
 **Interpreting profile elements labelled Must Support**
 
-Profiles defined in this publication flag Must Support only on elements and not on subelements of a data type. 
+Profiles defined in this implementation publication flag Must Support only on elements and not on subelements of a data type. 
 The explanation on how to interpret Must Support for an element does not address rules defined in each profile - in implementation the rules defined in the profile must be applied and may limit or extend what is allowed for each element.
 
-The allowed subelements for each supported element in a profile are defined by a combination of the data type from the core publication and any additional rules included in the profile. 
+The allowed subelements for each supported element in a profile are defined by a combination of the data type from the core specification and any additional rules included in the profile. 
 A profile may include rules that:
 - limit what is considered 'valid'
 - extend the potential subelements by including an extension
@@ -99,14 +99,14 @@ Typically ADHA profiles will extend the potential subelements by inheriting from
 The full set of subelements is visible in the "Snapshot Table" which shows the subelements defined in this profile (shown in the "Differential Table") and the subelements inherited from a base profile.
 
 
-*Must Support elements of primitive type*
+*Must support elements of primitive type*
 
 - A sending system **SHALL** be capable of providing a meaningful, valid, value in the element
 - A receiving system **SHALL** be capable of meaningfully processing the value in the element
 - A persisting system **SHALL** be capable of persisting the value in the element
 
 
-*Must Support elements of complex type*
+*Must support elements of complex type*
 
 - A sending system **SHALL** be capable of providing a meaningful, valid, value in the element
 - A receiving system **SHALL** be capable of meaningfully processing the value in all parts of the complex type (since the receiver cannot anticipate which subelements might be populated)
@@ -116,14 +116,14 @@ The full set of subelements is visible in the "Snapshot Table" which shows the s
 For some complex types a meaningful, valid, value can be populated with only one subelement, but usually more than one subelement is needed.
 
 
-*Must Support elements of Reference type*
+*Must support elements of Reference type*
 
 - A sending system **SHALL** be capable of populating the element with a valid reference
 - A receiving system **SHALL** be capable of meaningfully processing the element with a valid reference that conforms to the profile
 - A persisting system **SHALL** be capable of persisting the element with a valid reference that conforms to the profile
 
 
-*Must Support elements with a choice of data types or profiles*
+*Must support elements with a choice of data types or profiles*
 
 - A sending system **SHALL** be capable of populating the element with a value that conforms to at least one choice, and **SHOULD** be capable of populating every choice for which the sending system might possess data
 - A receiving system **SHALL** be capable of meaningfully processing all choices (since the receiver cannot anticipate which data type or profile might be populated) 
@@ -135,15 +135,15 @@ A profile may slice an element that has a choice of data types or profiles to co
 - A persisting system **SHALL** be capable of persisting all supported identifier choices (since the persister cannot anticipate which data type or profile might be populated)
 
 
-*Must Support between two elements that are a choice between CodeableConcept and Reference*
+*Must Support elements where there is a choice between an element of type CodeableConcept and type Reference*
 
 A resource may support two elements that are used to indicate a reason, e.g. `Encounter.reasonCode` and `Encounter.reasonReference` in the profile [ADHA Core Encounter](StructureDefinition-dh-encounter-core-1.html). Where both elements are optional and flagged with Must Support in a profile they **SHALL** be treated as a choice of data types:
 - A sending system **SHALL** be capable of populating at least one choice, and **SHOULD** be capable of populating every choice for which the sending system might possess data
 - A receiving system **SHALL** be capable of meaningfully processing all choices (since the receiver cannot anticipate which element might be populated) 
 - A persisting system **SHALL** be capable of persisting all choices (since the persister cannot anticipate which element might be populated)
 
 
-*Must Support elements with a choice of terminology bindings*
+*Must support elements with a choice of terminology bindings*
 
 A profile may slice an element that has a choice of terminology bindings to constrain the set of choices to be supported. For example, the profile [ADHA Core Medication](StructureDefinition-dh-medication-core-1.html) constrains the optional terminology choices for `Medication.code` defined in [AU Base Medication](http://hl7.org.au/fhir/4.0.0/StructureDefinition-au-medication.html) to support AMT and PBS:
 - A sending system that supplies a coded value **SHALL** be capable of populating the element with a value that conforms to at least one of those two terminology choices, and **SHOULD** be capable of populating every choice for which the sending system might possess data

pages/_includes/dh-bodystructure-aodr-1-intro.md

@@ -3,10 +3,10 @@ The purpose of this profile is to represent an organ or tissue that may be donat
 This profile identifies the additional constraints, extensions, and value sets that build on and extend [BodyStructure](http://hl7.org/fhir/R4/bodystructure.html) that are supported. 
 
 This profile is designed to set a BodyStructure standard for:
-* Recording or updating body structures in an AODR record of consent ([Consent](http://hl7.org/fhir/R4/consent.html) resource)
-* Reading body structures in an AODR record of consent ([Consent](http://hl7.org/fhir/R4/consent.html) resource)
+* Recording or updating body structures in an AODR record of consent (Consent resource)
+* Reading body structures in an AODR record of consent (Consent resource)
 
-Operations, including querying, on body structures in an AODR record of consent ([BodyStructure](http://hl7.org/fhir/R4/bodystructure.html) resource) are expected to be within the context of a Consent resource query.
+Operations, including querying, on body structures in an AODR record of consent (BodyStructure resources) are expected to be within the context of a Consent resource query.
 
 
 #### Profile specific guidance

pages/_includes/dh-condition-core-1-intro.md

@@ -8,7 +8,7 @@ This profile is designed to set a core Condition standard for:
 
 
 #### Profile specific guidance
-- `Condition.category` provides an efficient way of supporting system interactions, e.g. restricting searches. Implementers should understand that data categorisation is somewhat subjective. The categorisation applied by the source may not align with a receiver’s expectations.
+- `Condition.category` provides an efficient way of supporting system interactions, e.g. restricting searches. Implementers need to understand that data categorisation is somewhat subjective. The categorisation applied by the source may not align with a receiver’s expectations.
 - An active condition is represented using "active" in `Condition.clinicalStatus`.
 - To represent that a patient does not have a condition or history of condition, an appropriate negation code is used in `Condition.code`.
 - Refutation is not expected to be handled except as above - an appropriate negation code in `Condition.code` and `Condition.verificationStatus` of "confirmed" or "unconfirmed".

pages/_includes/dh-device-system-1-intro.md

@@ -3,7 +3,7 @@ In the context of an exchange of health information a system device is part of t
 
 This profile identifies the additional constraints, extensions, and value sets that build on and extend [Device](http://hl7.org/fhir/R4/device.html) that are supported. 
 
-The [Device](http://hl7.org/fhir/R4/device.html) resource, profiled as a SystemDevice, is used within the context of a referencing resource. 
+The [Device](http://hl7.org/fhir/R4/device.html) resource, profiled as a system device, is used within the context of a referencing resource. 
 
 This profile is designed to set a Device standard for:
 * Recording or updating a system device referenced by another resource

pages/_includes/dh-encounter-core-1-intro.md

@@ -9,7 +9,7 @@ This profile is designed to set a core Encounter standard for:
 
 
 #### Profile specific guidance
-- `Encounter.type` supports categorisation and provides an efficient way of supporting system interactions, e.g. restricting searches. Implementers should understand that data categorisation is somewhat subjective. The categorisation applied by the source may not align with a receiver’s expectations. 
+- `Encounter.type` supports categorisation and provides an efficient way of supporting system interactions, e.g. restricting searches. Implementers need to understand that data categorisation is somewhat subjective. The categorisation applied by the source may not align with a receiver’s expectations. 
 - In an exchange with the My Health Record system `Encounter.status` is "finished".
 - The Encounter resource can represent a reason using either a code with `Encounter.reasonCode`, or a reference with `Encounter.reasonReference` to a Condition or other resource.
   - Although both are marked as must support, sending systems are not required to support both a code and a reference, but they **SHALL** support *at least one* of these elements.

pages/_includes/dh-medicationrequest-pbs-claim-1-intro.md

@@ -3,10 +3,10 @@ The purpose of this profile is to define a representation of the prescription it
 This profile identifies the additional constraints, extensions, and value sets that build on and extend [MedicationRequest](http://hl7.org/fhir/R4/medicationrequest.html) that are supported. 
 
 This profile is designed to set a MedicationRequest standard for:
-* Recording or updating a prescription item in an PBS claim ([ExplanationOfBenefit](http://hl7.org/fhir/R4/explanationofbenefit.html) resource)
-* Reading a prescription items in an RPBS claim ([ExplanationOfBenefit](http://hl7.org/fhir/R4/explanationofbenefit.html) resource)
+* Recording or updating a prescription item in a PBS claim (ExplanationOfBenefit resource)
+* Reading a prescription items in an RPBS claim (ExplanationOfBenefit resource)
 
-Operations, including querying, on prescription items in PBS claims ([MedicationRequest](http://hl7.org/fhir/R4/medicationrequest.html) resource) are expected to be within the context of an [ExplanationOfBenefit](http://hl7.org/fhir/R4/explanationofbenefit.html) resource query.
+Operations, including querying, on prescription items in PBS claims (MedicationRequest resources) are expected to be within the context of an ExplanationOfBenefit resource query.
 
 
 #### Profile specific guidance

pages/_includes/dh-observation-core-1-intro.md

@@ -10,7 +10,7 @@ This profile is designed to set a core Observation standard for:
 
 
 #### Profile specific guidance
-- `Observation.category` provides an efficient way of supporting system interactions, e.g. restricting searches. Implementers should understand that data categorisation is somewhat subjective. The categorisation applied by the source may not align with a receiver’s expectations.
+- `Observation.category` provides an efficient way of supporting system interactions, e.g. restricting searches. Implementers need to understand that data categorisation is somewhat subjective. The categorisation applied by the source may not align with a receiver’s expectations.
 - Antenatal observations will represent the pregnant individual as `Observation.subject` and the fetus as `Observation.focus`.
 
 

pages/_includes/dh-organization-core-1-intro.md

@@ -32,7 +32,7 @@ This profile is referenced by
 [ADHA Core Patient](StructureDefinition-dh-patient-core-1.html), 
 [ADHA Core Observation](StructureDefinition-dh-observation-core-1.html), 
 [ADHA Core Organization](StructureDefinition-dh-organization-core-1.html), 
-[ADHA Authoring PractitionerRole](StructureDefinition-dh-practitionerrole-author-1.html) and
+[ADHA Authoring PractitionerRole](StructureDefinition-dh-practitionerrole-author-1.html), and
 [ADHA Core PractitionerRole](StructureDefinition-dh-practitionerrole-core-1.html). 
 
 

pages/_includes/dh-procedure-core-1-intro.md

@@ -8,7 +8,7 @@ This profile is designed to set a core Procedure standard for:
 
 
 #### Profile specific guidance
-- `Procedure.category` provides an efficient way of supporting system interactions, e.g. restricting searches. Implementers should understand that data categorisation is somewhat subjective. The categorisation applied by the source may not align with a receiver’s expectations.
+- `Procedure.category` provides an efficient way of supporting system interactions, e.g. restricting searches. Implementers need to understand that data categorisation is somewhat subjective. The categorisation applied by the source may not align with a receiver’s expectations.
 - In an exchange with the My Health Record system `Procedure.status` is "completed".
 - The Procedure resource can represent a reason as a code with `Procedure.reasonCode`, or a reference with `Procedure.reasonReference` to a Condition or other resource.
   - Although both are marked as must support, sending systems are not required to support both a code and a reference, but they **SHALL** support *at least one* of these elements.

pages/_includes/guidance.md

@@ -64,7 +64,7 @@ assigner" : {
 }
 ~~~
 
-Example: PractitionerRole resource with an employee number (local identifier).
+Example: PractitionerRole resource with an employee number (local identifier)
 ~~~
 {
   "resourceType" : "PractitionerRole",
@@ -120,7 +120,7 @@ assigner" : {
 }
 ~~~
 
-Example: Patient resource with a medical record number (local identifier).
+Example: Patient resource with a medical record number (local identifier)
 ~~~
 {
   "resourceType" : "Patient",
@@ -166,7 +166,7 @@ References to a patient **SHALL** populate `identifier` and when applicable popu
 - `identifier` **SHOULD** be populated with a verified IHI
 - if referencing a specific Patient resource instance `reference` **SHALL** be populated and it **SHALL** resolve
 
-Example: Observation resource with a Reference to a Patient resource as identifier and reference.
+Example: Observation resource with a Reference to a Patient resource as identifier and reference
 ~~~
 {
   "resourceType" : "Observation",
@@ -214,7 +214,7 @@ There are situations when information for a particular data element is missing a
   - if the ADHA profile mandates a child element, such as a valid identifier or reference, then the resource must contain that element otherwise the instance will not be conformant.
   - use the code `unknown` where the value is expected to exist but is not known.
 
-    Example: ExplanationOfBenefit resource where the patient's insurance coverage is not available.
+    Example: ExplanationOfBenefit resource where the patient's insurance coverage is not available
     ~~~
     {
       "resourceType" : "ExplanationOfBenefit",
@@ -245,7 +245,7 @@ There are situations when information for a particular data element is missing a
         - the appropriate "unknown" concept code **SHALL** be present if the binding strength is *extensible*.
         - if the value set does not have an appropriate "unknown" concept code, use `unknown` from the [DataAbsentReason Code System](http://terminology.hl7.org/CodeSystem/data-absent-reason).
 
-        Example: AllergyIntolerance resource where the manifestation is unknown.
+        Example: AllergyIntolerance resource where the manifestation is unknown
         ~~~
         ...
         "reaction" : [
@@ -356,7 +356,7 @@ These data elements may be supported as coded, or text, and systems are likely t
       - form and strength are also provided in `form`, `ingredient.itemCodeableConcept` and `ingredient.strength`
       - manufacturer = `manufacturer.identifer`
 
-    Example: Medication with coded brand name, generic name, manufacturer, item form and strength.
+    Example: Medication with coded brand name, generic name, manufacturer, item form and strength
     ~~~
     {
       "resourceType": "Medication",
@@ -474,7 +474,7 @@ These data elements may be supported as coded, or text, and systems are likely t
         - item form and strength = `code.text`
         - manufacturer = `manufacturer.display`
 
-    Example: Medication with text only brand name, generic name, item form and strength.
+    Example: Medication with text only brand name, generic name, item form and strength
     ~~~
     {
       "resourceType": "Medication",