Merge pull request #70 from HL7/ACOM-GHS-support

editorial improvements

Author: ErikMoll

input/intro-notes/CodeSystem-ASN1ToHL7-intro.md

@@ -4,13 +4,13 @@ The bit may either represent an event or a state. When an event, the defined eve
 
 The code values for the properties are included here as well, since the valueset extension for properties is not supported for FHIR R4.
 
-The uploader can generate the code from the data received from the PHD. No external information is necessary unless the uploader wants to populate the `display` element of the CodeableConcept data type. It is recommended that the uploader populates the display element as defined by the CodeSystem if known, or otherwise populates the `text` element with the Reference Id or the MDC code as decimal string followed by "bit *n*". It is not required because it is desired to have an uploader that can still work with future specializations and in that case, it is not possible for the uploader to know what to use as `display` as it is not sent over the wire; it is only available from the specialization documents.
+The uploader can generate the code from the data received from the PHD. No external information is necessary unless the uploader wants to populate the `display` element of the CodeableConcept data type. It is recommended that the uploader populates the `display` element as defined by the CodeSystem if known, or otherwise populates the `text` element with the Reference Id or the MDC code as decimal string followed by "bit *n*". It is not required because it is desired to have an uploader that can still work with future specializations and in that case, it is not possible for the uploader to know what to use as `display` as it is not sent over the wire; it is only available from the specialization documents.
 
 To generate the code, the uploader obtains the code for the type of measurement which is used to populate the `Observation.code.coding.code` –element. Then for each bit to be reported, a new code is generated by appending a period followed by the bit position being mapped.
 
 A bit can only have two values, set or cleared. Thus the value is reported in the `Observation.component.valueBoolean` –element using `true` for set and `false` for cleared.
 
- - As an example, the continuous glucose monitor specialization has a Device status measurement whose type is given by the code 8418060. If the value reported is 0001 1000 0000 0000 the bits set are bits 3 and 4. Note that bit 0 is the HIGH order bit. Bit 3 means 'sensor malfunction' and bit 4 means 'device specific alert'. This measurement would require two component elements and one would be 8418060.3 and the other would be 8418060.4. Note these are alpha-numeric strings and not decimal numbers. If one took the code 8418060.3 and looked it up in the ASN.1 Bits vocabulary one would find it meant 'sensor malfunctioned'.
+ - As an example, the continuous glucose monitor specialization has a Device status measurement whose type is given by the code 8418060. If the value reported is 0001 1000 0000 0000 the bits set are bits 3 and 4. Note that bit 0 is the HIGH order bit. Bit 3 means 'sensor malfunction' and bit 4 means 'device specific alert'. This measurement would require two `component` elements and one with code 8418060.3 and the other with code 8418060.4. Note these are alpha-numeric strings and not decimal numbers. If one took the code 8418060.3 and looked it up in the ASN.1 Bits vocabulary one would find it meant 'sensor malfunctioned'.
 
 ## Reporting Requirements
 If the ASN.1 bit represents an event, only the set condition needs to be reported. If the ASN.1 bit represents a state, both the set and cleared conditions need to be reported. If the device does not support the bit, it is not required to report the value. If the uploader would, nevertheless, desire to report the unsupported situation it is done in an `Observation.component.dataAbsentReason.coding.code` –element with code "unsupported". The `Observation.component.value[x]` element is absent. Undefined bits are never reported.

input/intro-notes/Observation-coin-example-1-intro.md

@@ -1 +1 @@
-This example shows a standard coincident timestamp where the PHG has superior time synchronization to the PHD. There is no identifier element in this Observation as Coincident Timestamps are never duplicates and are always 'created'.
+This example shows a standard coincident timestamp where the PHG has superior time synchronization to the PHD. There is no `identifier` element in this Observation as Coincident Timestamps are never duplicates and are always 'created'.

input/intro-notes/Observation-compound-numeric-observation-intro.md

@@ -1,3 +1,3 @@
-This example shows a compound (numeric) observation. The most common type of compound observation is the Blood Pressure. The systolic, diastolic, and mean values are treated as parts of the same observation. The compound elements are reported in `Observation.component` elements and that there is **no** `value[x]` in the 'primary' observation. In addition, the 'mean' component is not considered as one of FHIR's vital signs and no LOINC code is present for that component code.
+This example shows a compound (numeric) observation. The prototypical compound observation is the Blood Pressure. The systolic, diastolic, and mean values are treated as parts of the same observation. The compound elements are reported in `Observation.component` elements and that there is **no** `value[x]` in the 'primary' observation. In addition, the 'mean' component is not considered as one of FHIR's vital signs and no LOINC code is present for that component code.
 
 Note that the referenced resources - Patient, PHG, PHD, and coincident timestamp - are assumed to be present on the server already.

input/intro-notes/Observation-numeric-observation-not-a-number-intro.md

@@ -1,4 +1,4 @@
-This is an example of a device reporting a NaN (not a number). The important aspect of this case is that the value element is absent and replaced by a dataAbsentReason element.
+This is an example of a device reporting a NaN (not a number). The important aspect of this case is that the `value[x]` element is absent and replaced by a `dataAbsentReason` element.
 
-There is no logical id in this resource as this resource is being uploaded to the server in a create operation. The server will create the logical id and return it to the sender in the response. There is also no reference to the coincident timestamp since this observation is generated by a device that is streaming data and reporting no timestamp. The timestamp is taken to be the time of reception by the gateway.
+There is no logical id in this resource as this resource is being uploaded to the server in a create operation. The server will create the logical id and return it to the sender in the response. There is also no reference to the coincident timestamp since this observation is generated by a device that is streaming data as it is generated and without a timestamp. The timestamp is taken to be the time of reception by the gateway.
 

input/intro-notes/Observation-numeric-spotnumeric-intro.md

@@ -1,5 +1,5 @@
-This example shows a basic numeric observation. It does have a single component element as the measurement also contained a Supplemental Information attribute indicating the measurement is a SPOT (stable average).
+This example shows a basic numeric observation. It does have an additional component as the measurement also contained a Supplemental Information attribute indicating the measurement is a SPOT (stable average).
 
-Note there is no logical id in this resource as this resource is being uploaded to the server in a conditional create operation. The server will use the identifier to check that no other Observation resource exists on the server with the same identifier. If there is not such resource present, the server will create the logical id and return it to the sender in the response. Pulse oximeters reporting a SPOT measurement have a timestamp thus there is a reference to the coincident timestamp.
+Note there is no logical id in this resource as this resource is being uploaded to the server in a conditional create operation. The server will use the conditional create identifier to check that no other Observation resource exists on the server with the same identifier. If there is not such resource present, the server will create the logical id and return it to the sender in the response. Pulse oximeters reporting a SPOT measurement have a timestamp thus there is a reference to the coincident timestamp.
 
 The referenced resources are assumed to have been uploaded to the server before - Patient, PHD, PHG and coincident timestamp.

input/intro-notes/StructureDefinition-PhdBITsEnumerationObservation-notes.md

@@ -1,9 +1,9 @@
 The following section gives more details on the mapping of BITS to a FHIR Observation resource.
 
 ### Mapping BITs Enumerations to FHIR
-FHIR has no data type that corresponds to this kind of measurement. Consequently we developed a code system which maps the BITs measurement to a set of codes. The details of the mapping and how these codes are generated from data received from the PHD are given in [ASN1 To HL7 CodeSystem](CodeSystem-ASN1ToHL7.html). Basically each component has a code consisting of the MDC code followed by the bit number. In FHIR there is one component per reported bit setting. And similar to the compound measurement, there is no Observation.value[x] element. Each component has a value of `true` or `false`, corresponding to the bit being set or cleared.
+FHIR has no data type that corresponds to this kind of measurement. Consequently we developed a code system which maps the BITs measurement to a set of codes. The details of the mapping and how these codes are generated from data received from the PHD are given in [ASN1 To HL7 CodeSystem](CodeSystem-ASN1ToHL7.html). Basically each `component` has a code consisting of the MDC code followed by the bit number. In FHIR there is one `component` per reported bit setting. And similar to the compound measurement, there is no `Observation.value[x]` element. Each `component` has a value of `true` or `false`, corresponding to the bit being set or cleared.
 
-There may be an `Observation.dataAbsentReason` element if a measurement status indicates a measurement failure in which case no component elements representing the BITs setting are reported. 
+There may be an `Observation.dataAbsentReason` element if a measurement status indicates a measurement failure in which case no `component` elements representing the BITs setting are reported.
 
 When mapping Bluetooth GHS bitstring Observation values only supported bits are reported. For bits of type 'event' only set bits need to be reported. If of type 'state' both set and cleared states need to be reported. This means that some bits can be skipped and that the number FHIR Observation can be smaller than the number of bits in the GHS bitstring.
 

input/intro-notes/StructureDefinition-PhdBaseObservation-intro.md

@@ -1,15 +1,15 @@
 
 The PHD Base Observation profile contains the elements that are common to all PHD Observation profiles describing measurements. These element are: 
- - code: what the measurement is 
- - subject: the patient this measurement refers to
- - effective[x]: the timestamp and perhaps duration of the measurement
- - device: reference to the PHD taking the measurement
- - derivedFrom / memberOf: references to related observations
- - components: contains any additional measurement descriptions (Supplemental Information)
- - category: a fixed value identifying observations generated by PHDs
- - measurement status
- - gatewayDevice extension: reference to the PHG responsible for generating the upload
- - coincidentTimestamp extension: reference to the coincidentTimestamp observation that relates PHD time and PHG time
- - performer: optional, when the patient is known to be the performer this may refer to the patient
- - identifier: the PHD conditional-create identifier for this measurement to avoid duplicate uploads
+ - `code`: what the measurement is 
+ - `subject`: the patient this measurement refers to
+ - `effective[x]`: the timestamp and perhaps duration of the measurement
+ - `device`: reference to the PHD taking the measurement
+ - `derivedFrom / memberOf`: references to related observations
+ - `components`: contains any additional measurement descriptions (Supplemental Information)
+ - `category`: a fixed value identifying observations generated by PHDs
+ - `measurementStatus`: the status of the measurement
+ - `gatewayDevice` extension: reference to the PHG responsible for generating the upload
+ - `coincidentTimestamp` extension: reference to the coincidentTimestamp observation that relates PHD time and PHG time
+ - `performer`: optional, when the patient is known to be the performer this may refer to the patient
+ - `identifier`: the PHD conditional-create identifier for this measurement to avoid duplicate uploads