diff --git a/input/intro-notes/CodeSystem-ASN1ToHL7-intro.md b/input/intro-notes/CodeSystem-ASN1ToHL7-intro.md
index 921a383..ecbfd08 100644
--- a/input/intro-notes/CodeSystem-ASN1ToHL7-intro.md
+++ b/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.
diff --git a/input/intro-notes/Observation-coin-example-1-intro.md b/input/intro-notes/Observation-coin-example-1-intro.md
index d6f6efe..a18fb7f 100644
--- a/input/intro-notes/Observation-coin-example-1-intro.md
+++ b/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'.
\ No newline at end of file
+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'.
\ No newline at end of file
diff --git a/input/intro-notes/Observation-compound-numeric-observation-intro.md b/input/intro-notes/Observation-compound-numeric-observation-intro.md
index d6d7cd5..ce6252e 100644
--- a/input/intro-notes/Observation-compound-numeric-observation-intro.md
+++ b/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.
\ No newline at end of file
diff --git a/input/intro-notes/Observation-numeric-observation-not-a-number-intro.md b/input/intro-notes/Observation-numeric-observation-not-a-number-intro.md
index 05240f4..fd0ea23 100644
--- a/input/intro-notes/Observation-numeric-observation-not-a-number-intro.md
+++ b/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.
 
diff --git a/input/intro-notes/Observation-numeric-spotnumeric-intro.md b/input/intro-notes/Observation-numeric-spotnumeric-intro.md
index a9c6734..7a20ce0 100644
--- a/input/intro-notes/Observation-numeric-spotnumeric-intro.md
+++ b/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.
\ No newline at end of file
diff --git a/input/intro-notes/StructureDefinition-PhdBITsEnumerationObservation-notes.md b/input/intro-notes/StructureDefinition-PhdBITsEnumerationObservation-notes.md
index c1c89b7..dfb1f72 100644
--- a/input/intro-notes/StructureDefinition-PhdBITsEnumerationObservation-notes.md
+++ b/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.
 
diff --git a/input/intro-notes/StructureDefinition-PhdBaseObservation-intro.md b/input/intro-notes/StructureDefinition-PhdBaseObservation-intro.md
index 96a34a2..4111091 100644
--- a/input/intro-notes/StructureDefinition-PhdBaseObservation-intro.md
+++ b/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
 
diff --git a/input/intro-notes/StructureDefinition-PhdBaseObservation-notes.md b/input/intro-notes/StructureDefinition-PhdBaseObservation-notes.md
index 91ef9d4..7e123e6 100644
--- a/input/intro-notes/StructureDefinition-PhdBaseObservation-notes.md
+++ b/input/intro-notes/StructureDefinition-PhdBaseObservation-notes.md
@@ -29,15 +29,15 @@ An example of the this identifier from [this example](Observation-numeric-spotnu
 {% fragment Observation/numeric-spotnumeric JSON EXCEPT:identifier %}
 
 ### Obtaining the Type of observation
-One obtains the IEEE 11073-10101 observation type for the code element in the same manner for all metric observations. See the section [MDC Nomenclature codes](Nomenclaturecodes.html) for the details.
+One obtains the IEEE 11073-10101 observation type for the `code` element in the same manner for all metric observations. See the section [MDC Nomenclature codes](Nomenclaturecodes.html) for the details.
 
 ### Subject
-The subject element normally points to the PhdPatient resource using the logical id of the Patient resource, for example 'Patient/123546'. For device settings known to the PHG it should point to the PHD.
+The `subject` element normally points to the PhdPatient resource using the logical id of the Patient resource, for example 'Patient/123546'. For device settings known to the PHG it should point to the PHD.
 
 ### Performer
-In situations where the gateway knows that the patient is the person performing the measurement, a `Observation.performer` element can also point to the PhdPatient resource. However, in most situations this is unknown and the performer is not filled in. And for coincident timestamp observations, the performer should not be provided. This profile puts no constraints on the performer element.
+In situations where the gateway knows that the patient is the person performing the measurement, a `Observation.performer` element can also point to the PhdPatient resource. However, in most situations this is unknown and the `performer` is not filled in. And for coincident timestamp observations, the `performer` should not be provided. This profile puts no constraints on the `performer` element.
 
-### Timestamp: effective[x]
+### Timestamp: `effective[x]`
 PHDs report timestamps in various methods and may not report timestamps at all. The PHG will include a timestamp in every observation that is uploaded using a conversion as needed based on the timestamp data received from the PHD. The timestamp types and corresponding PHG conversions are summarized below:
 
 <style>table, th, td {
@@ -77,42 +77,42 @@ For IEEE 11073-10206 timestamps the following table can be used:
 | Tick counter | No      | n.a.   | n.a.   | Throw away                                                              | n.a.                               |
 
 The PHG maps the 'converted' timestamp to either an `Observation.effectiveDateTime` element or an `Observation.effectivePeriod` element. The second situation occurs when the metric observation includes a Measurement-Duration (duration) attribute. Then the timestamp attribute gives the start of the period and the end of the period is obtained by adding the Measurement-Duration value to it. If no timestamp is provided, the PHG, using the time of reception of the observation as its timestamp must then do the reverse; the time of reception is the end time and the start time is given by subtracting the Measurement-Duration value from it.
-When the PHG modifies an Observation's timestamp as received from the PHD it shall also generate a Coincident Timestamp observation that records how the Observation.effective[x] element is generated.
+When the PHG modifies an Observation's timestamp as received from the PHD it shall also generate a Coincident Timestamp observation that records how the `Observation.effective[x]` element is generated.
+
+### extension: Coincident timestamp reference
+This extension references Coincident Timestamp Observation resource that relates the PHD and PHG timelines. This occurs whenever the observation reported by the PHD has a timestamp. The Coincident Timestamp Observation reports how this `Observation.effective[x]` element is generated.
 
 ### Device
 The `Observation.device` element is a reference to the Device resource representing the PHD that generated the observation.
 
-### extension: Coincident timestamp reference
-This extension references Coincident Timestamp Observation resource that relates the PHD and PHG timelines. This occurs whenever the observation reported by the PHD has a timestamp. The Coincident Timestamp Observation reports how this Observation.effective[x] element is generated.
-
 ### derivedFrom and hasMember: related Observations
-The derivedFrom element references Observation resources that are in some manner related to this Observation resource. In the PHD use case, this situation occurs whenever the observation reported by the PHD contains a derivedFrom attribute referencing a related Observation.
+The `derivedFrom` element references Observation resources that are in some manner related to this Observation resource. In the PHD use case, this situation occurs whenever the observation reported by the PHD contains a `derivedFrom` attribute referencing a related Observation.
 
-The hasMember element is used when the PHD Observation reports a group of related observations. In GHS an Observation can have an Is Member Of attribute that references a group observation. When uploading to a FHIR server the gateway should report the group observation with a hasMember reference to all member Observations.
+The `hasMember` element is used when the PHD Observation reports a group of related observations. In GHS an Observation can have an Is Member Of attribute that references a group observation. When uploading to a FHIR server the gateway should report the group observation with a `hasMember` reference to all member Observations.
 
 In GHS the sensor related Observations are identified using a 32-bit Observation Id that is unique in the set of observations transferred during a connection.  
 Related observations are best uploaded in a single FHIR Bundle with logical ids assigned.
 
 #### Source-Handle-Reference case (concept from IEEE 11073-20601 - deprecated)
-A Source-Handle-Reference attribute points to a previously reported observation that is important to this observation. By previously it is meant that the observation is reported prior to the current observation but in the same connection. If multiple such observations have been received, the correct one is that which is most recently received. As an example, the cardiovascular specialization defines a session observation defining some type of exercise period, such as a run. All observations taken during that run have a source handle reference attribute pointing to the session observation. Since Source-Handle-Reference attributes use IEEE 11073-20601 Object handle values and not Logical resource ids to point to observations, the PHG will need to keep track of the Observation resources created during a connection to identify the correct Observation resource, and thus logical id, the Source-Handle-Reference attribute points to. Recent versions of the IEEE 11073-20601 standard also supports a Source-Handle-Reference-List containing a list of handles so there can be more than one entry generated due to these attributes. The references are placed in a derivedFrom element.
+A Source-Handle-Reference attribute points to a previously reported observation that is important to this observation. By previously it is meant that the observation is reported prior to the current observation but in the same connection. If multiple such observations have been received, the correct one is that which is most recently received. As an example, the cardiovascular specialization defines a session observation defining some type of exercise period, such as a run. All observations taken during that run have a source handle reference attribute pointing to the session observation. Since Source-Handle-Reference attributes use IEEE 11073-20601 Object handle values and not Logical resource ids to point to observations, the PHG will need to keep track of the Observation resources created during a connection to identify the correct Observation resource, and thus logical id, the Source-Handle-Reference attribute points to. Recent versions of the IEEE 11073-20601 standard also supports a Source-Handle-Reference-List containing a list of handles so there can be more than one entry generated due to these attributes. The references are placed in a `derivedFrom` element.
 
 This mapping is quite often semantically incorrect. In FHIR the session observation resource should have "hasMember" references to all observations that are part of the session.
 
 ### Category
-The category element identifies the observation as being generated by a PHD. This can be used in searches and distinguishes such observations from observations collected using clinical equipment or collected in a clinical context. PHGs shall include a category element with a fixed coding as specified by the profile.
+The `category` element identifies the observation as being generated by a PHD. This can be used in searches and distinguishes such observations from observations collected using clinical equipment or collected in a clinical context. PHGs shall include a `category` element with a fixed coding as specified by the profile.
 
-Note that for vital signs observations there also should be a category element as defined by the [Vital Signs profile]({{ site.data.fhir.path }}observation-vitalsigns.html).
+Note that for vital signs observations there also should be a `category` element as defined by the [Vital Signs profile]({{ site.data.fhir.path }}observation-vitalsigns.html).
 
 ### Supplemental Information - Components
-Component elements are used whenever the observation contains additional information attributes that further describe the observation. PHD observations can include Supplemental-Information that can be mapped to one or more FHIR Observation components.
+`component` elements are used whenever the observation contains additional information attributes that further describe the observation. PHD observations can include Supplemental-Information that can be mapped to one or more FHIR Observation components.
 
-The Supplemental Information attribute contains a list of one or more MDC codes that describe some property of the observation. There will be one component element for each entry in the list. For example, the code MDC_MODALITY_SPOT used in the pulse oximeter specialization indicates that the observation reported is a stable average. In contrast there is MDC_MODALITY_FAST and MDC_MODALITY_SLOW. 
+The Supplemental Information attribute contains a list of one or more MDC codes that describe some property of the observation. There will be one `component` element for each entry in the list. For example, the code MDC_MODALITY_SPOT used in the pulse oximeter specialization indicates that the observation reported is a stable average. In contrast there is MDC_MODALITY_FAST and MDC_MODALITY_SLOW.
 
 {% fragment Observation/numeric-spotnumeric JSON EXCEPT:component[0] %}
 
 <blockquote class="stu-note">
 	<strong>Should we move Supplemental Type information to an extension?</strong>
-	In the PHD IG v1.0 an attempt was made to avoid extensions as much as possible. In this version we are using extensions for less often used elements of the IEEE 11073-10206 model and in places were the conceptual models from PHD and FHIR model are too different to have a 1-1 mapping between data elements of these models.
+	In the PHD IG v1.0 an attempt was made to avoid extensions as much as possible. In this version we are using extensions for less often used attributes of the IEEE 11073-10206 model and in places were the conceptual models from PHD and FHIR model are too different to have a 1-1 mapping between parts of these models.
 
     The question is if this applies to Supplemental Type information as well. Should IEEE 11073-10206/20601 Supplemental Information be modeled as a FHIR `Observation.component` or as an extension in FHIR?
     Input is welcome.
@@ -120,7 +120,7 @@ The Supplemental Information attribute contains a list of one or more MDC codes
 
 
 ### Measurement Status
-The Measurement Status element from IEEE 11073-10206 ACOM is used to report errors or other special conditions.  The Bluetooth SIG GHS specification adds more possible conditions. It is possible to have multiple conditions simultaneously, but some combinations of conditions do not make sense and should not occur.
+The Measurement Status attribute from IEEE 11073-10206 ACOM is used to report errors or other special conditions.  The Bluetooth SIG GHS specification adds more possible conditions. It is possible to have multiple conditions simultaneously, but some combinations of conditions do not make sense and should not occur.
 
 To report these conditions in FHIR requires the use of different elements:
 - The `dataAbsentReason` element is used to report the error or not-available condition.
@@ -144,6 +144,6 @@ The table below lists the error conditions and the FHIR data elements to which t
 
 DAR: [Data Absent Reason CodeSystem](http://terminology.hl7.org/CodeSystem/data-absent-reason)
 HL7Status: [Observation Status CodeSystem]({{ site.data.fhir.path }}observation-status)
-PoCDStatus: [CodeSystem: Measurement Status Codes CodeSystem](https://hl7.org/fhir/uv/pocd/2021Sep/ValueSet-observation-interpretation.html)
-ActReason: [CodeSystem: Act Reason CodeSystem](http://terminology.hl7.org/CodeSystem/v3-ActReason)
+PoCDStatus: [Measurement Status Codes CodeSystem](https://hl7.org/fhir/uv/pocd/2021Sep/ValueSet-observation-interpretation.html)
+ActReason: [Act Reason CodeSystem](http://terminology.hl7.org/CodeSystem/v3-ActReason)
 
diff --git a/input/intro-notes/StructureDefinition-PhdCodedEnumerationObservation-intro.md b/input/intro-notes/StructureDefinition-PhdCodedEnumerationObservation-intro.md
index 2831103..35544a3 100644
--- a/input/intro-notes/StructureDefinition-PhdCodedEnumerationObservation-intro.md
+++ b/input/intro-notes/StructureDefinition-PhdCodedEnumerationObservation-intro.md
@@ -1,5 +1,5 @@
 The Coded Enumeration Observation Profile is used when the PHD metric measurement is represented by one of a limited set of codes. This corresponds to the Single Event Observation class in IEEE 11073-10206 ACOM and the Simple Discrete Observation in GHS.  
 
-The MDC code of the value in this observation resource corresponds to the value element in these ACOM and GHS observation classes.
+The MDC code of the value in this observation resource corresponds to the value attribute in these ACOM and GHS observation classes.
 
 One example of a coded measurement would be the Glucose Monitor meal context associated with a glucose concentration measurement. The code would indicate one of fasting, preprandial, postprandial, bedtime, etc. Coded measurements are often associated with other measurements. Another example would be the type of exercise in an activity session (walk, run, swim, hike, bike, etc.). Each of these enumerated options is given by a nomenclature code.
diff --git a/input/intro-notes/StructureDefinition-PhdCoincidentTimestampObservation-intro.md b/input/intro-notes/StructureDefinition-PhdCoincidentTimestampObservation-intro.md
index c1c694d..37d598a 100644
--- a/input/intro-notes/StructureDefinition-PhdCoincidentTimestampObservation-intro.md
+++ b/input/intro-notes/StructureDefinition-PhdCoincidentTimestampObservation-intro.md
@@ -1,11 +1,11 @@
-The Coincident Timestamp Observation Profile is used to compare the timelines of the PHD with the timeline of the PHG. The primary elements are the `Observation.effectiveDateTime`, which has the time of the PHG at the moment of generating the observation, and the `Observation.valueDateTime` or `Observation.valueQuantity`, which has the corresponding time of the PHD. The `valueDateTime` is used when the PHD uses a time-of-day clock, and the `valueQuantity` is used when the PHD uses a tick counter (relative time). The PHG reports its current time at the time it reads the current time of the PHD.
+The Coincident Timestamp Observation Profile is used to compare the timelines of the PHD with the timeline of the PHG. The primary elements are the `Observation.effectiveDateTime`, which has the time of the PHG at the moment of generating the observation, and the `Observation.valueDateTime` or `Observation.valueQuantity`, which has the corresponding time of the PHD. The `valueDateTime` is used when the PHD uses a time-of-day clock, and the `valueQuantity` is used when the PHD uses a tick counter (relative time). The PHG reports its current time at the time it reads the (current) time of the PHD.
 
-In remote patient monitoring, data can arrive from any location on the planet. Given that PHDs can be unsynchronized, have time clocks set by the user, default factory times, or no time clock at all, providing accurate timestamps to the healthcare provider is a challenge. The Coincident Timestamp Observation provides a mechanism to report the PHD clock status and links it to the timeline of the PHG.
+In remote patient monitoring, data can arrive from any location on the planet. Given that PHDs can be unsynchronized, have time clocks set by the user, default factory times, or no time clock at all, providing accurate timestamps in the Observation resources is a challenge. The Coincident Timestamp Observation provides a mechanism to report the PHD clock status and links it to the timeline of the PHG.
 
 For more details on the interpretation of the Coincident Timestamp, see the notes section below.
 
 A PHD Observation may reference a Coincident Timestamp Observation if the measurement reported from the PHD contains a timestamp and is from the current timeline of the PHD and needed correction. It will not reference a Coincident Timestamp Observation if the measurement reported from the PHD contains no timestamp or is from an older timeline after which a time adjustment occurred.
 
-A Coincident Timestamp Observation is created for every connection between PHG and PHD, so data duplication is not an issue. Therefore, the conditional create identifier element of this resource is not used in this profile.
+A Coincident Timestamp Observation is created for every connection between PHG and PHD, so data duplication is not an issue. Therefore, the conditional create `identifier` element is not used in this profile.
 
 If a PHD has its time clock altered during a connection, a new Coincident Timestamp Observation is generated, and all data sent after the adjustment will reference the new Coincident Timestamp Observation.
diff --git a/input/intro-notes/StructureDefinition-PhdCoincidentTimestampObservation-notes.md b/input/intro-notes/StructureDefinition-PhdCoincidentTimestampObservation-notes.md
index 225400a..cc1c67f 100644
--- a/input/intro-notes/StructureDefinition-PhdCoincidentTimestampObservation-notes.md
+++ b/input/intro-notes/StructureDefinition-PhdCoincidentTimestampObservation-notes.md
@@ -1,7 +1,7 @@
-Further notes on the elements of the PhdCoincidentTimeObservation resource:
+Further notes on elements and the use of the PhdCoincidentTimeObservation resource:
 
 ### Code
-The code element is used to report the type of time clock used by the PHD. The PHG obtains the type of time clock and its current setting by inspecting the PHD measurement timestamp and current time. The ACOM clock types are mapped as follows:
+The `code` element is used to report the type of time clock used by the PHD. The PHG obtains the type of time clock and its current setting by inspecting the PHD's measurement timestamp and the PHD's clock. The ACOM clock types are mapped as follows:
 
 <style>table, th, td {border: 1px solid black; border-collapse:collapse; padding: 6px;}</style>
 |ACOM clock type|`Observation.code.coding`|
diff --git a/input/intro-notes/StructureDefinition-PhdDevice-notes.md b/input/intro-notes/StructureDefinition-PhdDevice-notes.md
index b84263d..205a827 100644
--- a/input/intro-notes/StructureDefinition-PhdDevice-notes.md
+++ b/input/intro-notes/StructureDefinition-PhdDevice-notes.md
@@ -7,7 +7,7 @@ In order to discriminate between an identifier that is a system id and that whic
 
 When in the future other system identifiers such as ETSI-ICCID (International Circuit Card Identifier) are used, this coding scheme will need to be extended.
 
-Note that USB.vid (vendor id) and USB.pid (product id) pair identifies a product type from a vendor and cannot be used as system identifier. This information can be represented in a property element of the Device resource. 
+Note that USB.vid (vendor id) and USB.pid (product id) pair identifies a product type from a vendor and cannot be used as system identifier. This information can be represented in a `property` element of the Device resource.
 
 The transport addresses are as follows:
 
@@ -28,7 +28,7 @@ An example of a system identifier is:
 {% fragment Device/phd-74E8FFFEFF051C00.001C05FFE874 JSON EXCEPT:identifier %}
 
 ### UDI &rarr; `Device.udiCarrier`
- The UDI is included as an optional attribute of a PHD in the IEEE 11073-10206 ACOM standard. It is also supported in the Bluetooth SIG Device Information Service and the GHS Profile. The UDI elements supported are issuer, jurisdiction, Device Identifier, and the Human Readable Barcode String. The udiCarrier does have elements for each of these entries. The entryType code for this sourcing of the UDI `electronic-transmission` is used as the UDI is transmitted electronically.
+ The UDI is included as an optional attribute of a PHD in the IEEE 11073-10206 ACOM standard. It is also supported in the Bluetooth SIG Device Information Service and the GHS Profile. The UDI attributes supported are issuer, jurisdiction, Device Identifier, and the Human Readable Barcode String. The `udiCarrier` does have elements for each of these entries. The entryType code for this sourcing of the UDI `electronic-transmission` is used as the UDI is transmitted electronically.
 
 The UDI of a device consists of a Device Identifier (DI) and a Production Identifier (PI). The DI is the part of the UDI that identifies the specific model of the device. The PI is used to identify the specific instance of the device, such as its serial number or lot number. When the PI includes a serial number it identifies a specific instance of the devices of the model as specified by the DI. 
 
@@ -66,7 +66,7 @@ It contains the Continua version, list of certified PHD interfaces, and the regu
 The interface codes are mapped to a list of properties where the `property.valueCode` element carries a single PHD interface code. The `property.type` element, which identifies the property, is given by the MDC code `532353`. Its reference id is `MDC_REG_CERT_DATA_CONTINUA_CERT_DEV_LIST`. 
 
 #### Reg-Cert-Data-List Regulation Status
-The regulation status element has MDC code `532354` and carries a 16-bit ASN1 BITs 'state' value (see [ASN1 To HL7 CodeSystem](CodeSystem-ASN1ToHL7.html)). Only bit 0 is defined. Being a state value, both set and cleared states are reported. In fact, it is the cleared state which represents that the device is regulated. The regulation status is mapped to an additional `Device.property.valueCode` element. 
+The regulation status attribute has MDC code `532354` and carries a 16-bit ASN1 BITs 'state' value (see [ASN1 To HL7 CodeSystem](CodeSystem-ASN1ToHL7.html)). Only bit 0 is defined. Being a state value, both set and cleared states are reported. In fact, it is the cleared state which represents that the device is regulated. The regulation status is mapped to an additional `Device.property.valueCode` element. 
 
 A fragment:
 {% fragment Device/phd-74E8FFFEFF051C00.001C05FFE874 JSON BASE:property.where(type.coding.code='532354') %}
diff --git a/input/intro-notes/StructureDefinition-PhdNumericObservation-notes.md b/input/intro-notes/StructureDefinition-PhdNumericObservation-notes.md
index 41d4015..59d9ceb 100644
--- a/input/intro-notes/StructureDefinition-PhdNumericObservation-notes.md
+++ b/input/intro-notes/StructureDefinition-PhdNumericObservation-notes.md
@@ -40,16 +40,16 @@ The above states that the Continuous Glucose Monitor PHG is 95% sure that the re
 ### Examples:
 A basic simple numeric observation with a timestamp and a supplemental types attribute is shown in [Pulse Rate Spot Measurement](Observation-numeric-spotnumeric.html). Simple numeric measurements are common in PHDs.
 
-An example of a NaN (not a number) measurement is shown in [NaN Example](Observation-numeric-observation-not-a-number.html). Note that the value element is absent and replaced by a dataAbsentReason element.
+An example of a NaN (not a number) measurement is shown in [NaN Example](Observation-numeric-observation-not-a-number.html). Note that the value element is absent and replaced by a `dataAbsentReason` element.
 
 ### Consumer of the PHD Numeric Observation Profile
 The consumer of this profile does not need to concern itself with the complexities or the PHD-related entry for the `Observation.identifier` which is used by the uploader to prevent data duplication. There are some extensions introduced by this profile but the resource is consumable by any reader that understands the Observation resource. The following table summarizes the elements used describing the measurement:
 
 | **Measurement Item**         | **Element**                              | **Additional Information**                                                                                     |
 |-------------------------------|------------------------------------------|-----------------------------------------------------------------------------------------------------------------|
-| Measurement type              | `Observation.code.coding.code`          | There shall be one coding element using the MDC coding system.<br>If a vital sign, there will be an additional coding element using one of the LOINC vital-signs codes. |
+| Measurement type              | `Observation.code.coding.code`          | There shall be one `coding` element using the MDC coding system.<br>If a vital sign, there will be an additional `coding` element using one of the LOINC vital-signs codes. |
 | Measurement value             | `Observation.valueQuantity.value`       | The value has the precision of the original. measurement.                                                               |
-| Measurement units             | `Observation.valueQuantity.code`        | FHIR uses UCUM coding. system.                                                                                       |
+| Measurement units             | `Observation.valueQuantity.code`        | FHIR uses the UCUM coding system.                                                                                       |
 | Error                         | `Observation.dataAbsentReason`          | Contains error code. If present, no `Observation.valueQuantity` is present.                                    |
 | Timestamp                    | `Observation.effectiveDateTime`<br>`Observation.effectivePeriod` | If the measurement is a point in time.<br>If the measurement has a duration.                                   |
 | Coincident timestamp reference | `Observation.extension.valueReference` | Points to an Observation following the Coincident Timestamp Observation profile. For time quality auditing purposes. Not present if the sensor provides no timestamp. |
diff --git a/input/intro-notes/StructureDefinition-PhdPatient-notes.md b/input/intro-notes/StructureDefinition-PhdPatient-notes.md
index 6c8821a..f36c1e7 100644
--- a/input/intro-notes/StructureDefinition-PhdPatient-notes.md
+++ b/input/intro-notes/StructureDefinition-PhdPatient-notes.md
@@ -13,5 +13,5 @@ A Patient resource for a known or an unknown patient shall be created by the PHG
 ### Examples:
 An example of a PHD generated patient for a known patient is given [here](Patient-patientExample-1.html). 
 An example of a PHD generated patient for an unknown patient is given [here](Patient-patientExample-2.html). 
-These examples contain an optional name element.
+These examples contain an optional `name` element.
 
diff --git a/input/intro-notes/StructureDefinition-PhdRtsaObservation-intro.md b/input/intro-notes/StructureDefinition-PhdRtsaObservation-intro.md
index 6698272..e47a1ed 100644
--- a/input/intro-notes/StructureDefinition-PhdRtsaObservation-intro.md
+++ b/input/intro-notes/StructureDefinition-PhdRtsaObservation-intro.md
@@ -1,4 +1,4 @@
-The (Real Time) Sample Array (RTSA) Observation Profile is used when the measurement is a periodic sequences of scalars in time, typically waveforms. In theory, this measurement could be split up into a sequence of Numeric Observations but that would be inefficient especially if one is talking about a 1000 samples per second or more. Waveforms are used for spirometry, ECG, pulse oximeter pleth wave traces, etc. It is used to represent ACOM Sample Array Observations.
+The (Real Time) Sample Array (RTSA) Observation Profile is used when the measurement is a periodic sequences of scalars in time, typically waveforms. In theory, this measurement could be split up into a sequence of Numeric Observations but that would be inefficient especially if one is talking about a 1000 samples per second or more. Waveforms are used for spirometry, ECG, pulse oximeter pleth wave traces, etc. This profile is used to represent ACOM Sample Array Observations.
 
 <style>table, th, td {
 border: 1px solid black;
@@ -15,7 +15,7 @@ IEEE 11073-10206 ACOM and GHS support the concept of multi-dimensional arrays. R
 |number-of-samples-per-period|integer|#Dimensions of the measurement|
 |Actual-Range|Real range|Lowest-Highest unscaled value PHD can ever report \[A,B\]|
 |Scaled-range|Integer range|Low- and high-value used for scaling \[I,J\]|
-|Unit-code|UCUM code|The unit of the samples|
+|Unit-code|MDC code|The unit of the samples|
 |Samples|array of integer|The scaled measured samples|
 
 When mapping the samples directly to FHIR `SampledData.data`, the FHIR scale factor and origin can be derived from this:
diff --git a/input/intro-notes/StructureDefinition-PhdRtsaObservation-notes.md b/input/intro-notes/StructureDefinition-PhdRtsaObservation-notes.md
index 546e61d..f2fb01a 100644
--- a/input/intro-notes/StructureDefinition-PhdRtsaObservation-notes.md
+++ b/input/intro-notes/StructureDefinition-PhdRtsaObservation-notes.md
@@ -25,7 +25,7 @@ Using the variables 'b' and 's' as defined above the mapping to the FHIR Observa
 |IEEE 11073-10206 Sample Array Observation Attribute|FHIR Observation element|
 |--|--|
 |samples[i]     |`valueSampledData.data[i]`|
-|Unit-Code      |`valueSampledData.origin.code` (as UCUM when available)|
+|Unit-Code      |`valueSampledData.origin.code` (mapped to UCUM when available)|
 |See calculation of 'b' above|`valueSampledData.origin.value` = b|
 |See calculation of 's' above|`valueSampledData.scaleFactor` = s|
 |Sample-period|`valueSampledData.period` (milliseconds)|
diff --git a/input/pagecontent/ProfileConsumers.md b/input/pagecontent/ProfileConsumers.md
index 2bc2a4f..e3530c5 100644
--- a/input/pagecontent/ProfileConsumers.md
+++ b/input/pagecontent/ProfileConsumers.md
@@ -30,8 +30,8 @@ Every PHD generated measurement Observation resource contains the following info
 |IEEE 11073-10206 Observation attribute|FHIR Observation data element|Description|
 |---|---|---|
 |type|`code`|This element tells you what the measurement is. There should be a coding element using the MDC coding system.<br>If a vital sign, there will be an additional coding element using one of the [LOINC vital sign codes]({{ site.data.fhir.path }}valueset-observation-vitalsignresult.html).| 
-||`category`|The category element is present with at least the value `"phd"`. For vital signs, there will also be another element with value `"vital-signs"` as required by the vital signs profile.
-|measurement-status|`Observation.status`,<br> `Observation.dataAbsentReason`|This element tells what the status of the measurements is and has usually the value `final`. In error cases the data-absent-reason element is filled with an appropriate value.
+||`category`|The `category` element is present with at least the value `"phd"`. For vital signs, there will also be another element with value `"vital-signs"` as required by the vital signs profile.
+|measurement-status|`Observation.status`,<br> `Observation.dataAbsentReason`|This element tells what the status of the measurements is and has usually the value `final`. In error cases the `dataAbsentReason` element is filled with an appropriate value.
 |timestamp|`Observation.effectiveDateTime`,<br/>`Observation.effectivePeriod`|This element tells when the measurement occurred, and is a point in time or a period with a start- and end-time.|
 |PHG reference|`Observation.extension.valueReference`|This element points to the PHG Device that generated the FHIR Observation. The gateway extension is identified by `Observation.extension.url="http://hl7.org/fhir/StructureDefinition/observation-gatewayDevice"`|
 |patient reference|`Observation.subject`|Points to the Patient to whom this measurement refers|
@@ -86,7 +86,7 @@ In addition to the elements that are always present, the following set of elemen
 
 ##### The Profile: `Observation.meta.profile`
 An Observation may contain a `meta.profile` element that can help to identify the type of the Observation. For example, if `Observation.profile` entry contains ["http://hl7.org/fhir/uv/phd/StructureDefinition/PhdNumericObservation"](StructureDefinition-PhdNumericObservation.html) the measurement is a scalar. 
-Note that there is no requirement that the profile element be present. If it is not present, the consumer can determine the type of measurement value by looking at the Observation.value[x] element.
+Note that there is no requirement that the `profile` element be present. If it is not present, the consumer can determine the type of measurement value by looking at the Observation.value[x] element.
 
 ##### The Coincident Timestamp extension
 When present, the consumer can obtain further information about the timestamp from a referenced coincident timestamp Observation that adheres to the [PhdCoincidentTimeStampObservation profile](StructureDefinition-PhdCoincidentTimeStampObservation.html). This reference may be present in the [CoincidentTimeStampReference extension](StructureDefinition-CoincidentTimeStampReference.html). If the reference is NOT present, it means that the PHD did not provide a timestamp and the PHG used the time of reception as the timestamp or that the PHG determined that the PHD timestamp is reliable and can be used as is. PHDs that send stored data shall include timestamps in their measurements.
@@ -142,11 +142,11 @@ In normal situations PHD reported Observation resources have a `Observation.stat
 
 There are other non-error special conditions that may also be reported, such as the measurement is test or demo data.
 
-Depending upon what the special condition is, it is reported in either the dataAbsentReason, interpretation, or `meta.security` element. All of these entries are CodeableConcepts. When the condition is reported in the dataAbsentReason, there will be no measurement value entry in accord with the FHIR specification, even if the PHD reports a measurement value. Note that there may be multiple interpretation entries but only one dataAbsentReason element.
+Depending upon what the special condition is, it is reported in either the `dataAbsentReason`, interpretation, or `meta.security` element. All of these entries are CodeableConcepts. When the condition is reported in the `dataAbsentReason`, there will be no measurement value entry in accord with the FHIR specification, even if the PHD reports a measurement value. Note that there may be multiple interpretation entries but only one `dataAbsentReason` element.
 
 The exact mapping of IEEE 11073-10206 Observation status conditions to FHIR is covered in the [PhdBaseObservation profile](StructureDefinition-PhdBaseObservation.html).
 
-In addition to the conditions listed above, when the measurement value is a quantity, PHDs may also report one of a set of special FLOAT values, "Not a Number", "Not at this resolution", "Positive infinity", or "Negative infinity". These errors can results from a failure of the floating point software or hardware, or the inability of the sensor to completely acquire a value. These errors are reported in the dataAbsentReason element and will be discussed in the sections discussing the measurement values. "Not a Number" is the most common special condition reported by PHDs currently on the market. Reporting of the other special situations listed above are, in practice, rare.
+In addition to the conditions listed above, when the measurement value is a quantity, PHDs may also report one of a set of special FLOAT values, "Not a Number", "Not at this resolution", "Positive infinity", or "Negative infinity". These errors can results from a failure of the floating point software or hardware, or the inability of the sensor to completely acquire a value. These errors are reported in the `dataAbsentReason` element and will be discussed in the sections discussing the measurement values. "Not a Number" is the most common special condition reported by PHDs currently on the market. Reporting of the other special situations listed above are, in practice, rare.
 
 
 ### Measurement Values that are numeric or scalar
@@ -163,7 +163,7 @@ If the PHD reports a special FLOAT value an `Observation.dataAbsentReason` eleme
 |`Observation.valueQuantity.code`|units in UCUM|
 |`Observation.valueQuantity.system="http://unitsofmeasure.org"`|code system is UCUM|
 
-If a special FLOAT value is reported an `Observation.dataAbsentReason` then this replaces the valueQuantity. The dataAbsentReason is a CodeableConcept and will have the following possible codes from the data absent reason coding system "http://terminology.hl7.org/CodeSystem/data-absent-reason":
+If a special FLOAT value is reported an `Observation.dataAbsentReason` then this replaces the valueQuantity. The `dataAbsentReason` is a CodeableConcept and will have the following possible codes from the data absent reason coding system "http://terminology.hl7.org/CodeSystem/data-absent-reason":
 
  - `Observation.dataAbsentReason.coding.code="not-a-number"`
  - `Observation.dataAbsentReason.coding.code="positive-infinity"`
@@ -180,8 +180,7 @@ An example of the valueQuantity in the Phd Numeric Observation Profile for a the
 ### Measurement Values that are Compounds
 IEEE 11073-10206 (ACOM) supports compound observations where the components can have a numeric, a string, a code or a sample array value. This type of observation is mapped to the [Phd Compound Observation](StructureDefinition-PhdCompoundObservation.html) profile.
 
-There is no primary Observation.value[x] entry and there is no `Observation.dataAbsentReason` unless the *entire* measurement had an error, in which case there will be no compound entries either. It is possible for each compound entry to have its own error and that will be reported in an `Observation.dataAbsentReason` element. All `Observation.component` entries could have dataAbsentReason entry but that does NOT mean the entire measurement has an `Observation.dataAbsentReason` entry. It is also possible that a component will have its own interpretation element of the same type as shown in the Measurement Status section. Currently there are no market PHDs that generate an `Observation.interpretation` element.
-There is no primary Observation.value[x] entry and there is no `Observation.dataAbsentReason` unless the *entire* measurement had an error, in which case there will be no compound entries either. It is possible for each compound entry to have its own error and that will be reported in an `Observation.dataAbsentReason` element. All `Observation.component` entries could have dataAbsentReason entry but that does NOT mean the entire measurement has an `Observation.dataAbsentReason` entry. 
+There is no primary `Observation.value[x]` entry and there is no `Observation.dataAbsentReason` unless the *entire* measurement had an error, in which case there will be no compound entries either. It is possible for each compound entry to have its own error and that will be reported in an `Observation.component.dataAbsentReason` element. All `Observation.component` entries could have `dataAbsentReason` entry but that does NOT mean the entire measurement has an `Observation.dataAbsentReason` entry. It is also possible that a component will have its own interpretation element of the same type as shown in the Measurement Status section. Currently there are no market PHDs that generate an `Observation.component.interpretation` element.
 
 Compound Observations will have a code indicating what the 'entire' measurement is, for example, non-invasive blood pressure or acceleration. Each `Observation.component` element will have its own code describing each individual compound or vector entry, for example, the systolic, diastolic, and mean pressures for the blood pressure or x-, y-, and z-projections of an acceleration.
 
@@ -234,7 +233,7 @@ This measurement indicates that the glucose concentration measurement was taken
 ### Measurement Values that are Events or States
 PHDs support a measurement value type that indicate a set of states or events, for example, an independent living monitor may be surveilling an elderly patient's room and report its current state 'door closed', 'window closed', 'climate control on', 'patient in room', and 'lights off'. The report may have been triggered by an event like 'patient entered room'. (There is no such measurement type as a current room state but it illustrates the concept.) PHDs have an efficient way to package such reports into a single integer. This type of reporting is done when more than one state and/or event can occur simultaneously. In order to understand such a report one has to know what the state or event is, and its value. States and events are binary. A state is either on or off and an event either happens or it doesn't. There is no corresponding HL7 data type for this kind of measurement thus the [ASN1ToHL7](CodeSystem-ASN1ToHL7.html) code system has been developed to express these states and events as codes. A Boolean is used to express the corresponding values.
 
-Measurement values that fall into this category are mapped to an Observation following the [Phd Bits Enumeration Observation profile](StructureDefinition-PhdBitsEnumerationObservation.html).
+Measurement values of this type are mapped to an Observation following the [Phd Bits Enumeration Observation profile](StructureDefinition-PhdBitsEnumerationObservation.html).
 
 Each event or state is reported in a component element. The `Observation.code` will be the ASN1ToHL7 code indicating what the state or event is. The value of the state or event will be a Boolean value. It should be noted that 'state' values must be reported for either state. It is as important to know whether the door is opened or closed. Events are only required to be reported when they happen.
 
@@ -406,11 +405,11 @@ The example below shows an example of a PHD following the Glucose specialization
 
 
 #### Property
-The property element contains time clock information and certification information. There will be at least one property entry for every PHD and that is the time synchronization information. The entry will be present even if the PHD supports no time clock, and that will be 'no time synchronization'.
+`property` elements contain time clock information and certification information. There will be at least one `property` entry for every PHD and that reports the time synchronization information. The entry will be present even if the PHD supports no time clock, and in that case the value will be 'no time synchronization'.
 
-There are two types of properties, one that is described by a list of codes, and one that is described by a list of quantities. The list often contains only one entry. Though not obvious from the FHIR specification, a property cannot contain *both* a quantity and coded element.
+There are two types of properties, one that is described by a list of codes, and one that is described by a list of quantities. The list often contains only one entry. Though not obvious from the FHIR {{site.data.fhir.version}} specification, a `property` cannot contain *both* a quantity and coded element.
 
-The `Device.type` is a CodeableConcept which tells what the property is. There are [MDC](https://terminology.hl7.org/MDC.html) or [ASN1ToHL7](CodeSystem-ASN1ToHL7.html) codes for each property type a PHD can expose. They are as follows:
+The `property.type` is a CodeableConcept which tells what the property is. There are [MDC](https://terminology.hl7.org/MDC.html) or [ASN1ToHL7](CodeSystem-ASN1ToHL7.html) codes for each property type a PHD can expose. They are as follows:
 
 |description|Code|Reference identifier|
 |--|--|--|
@@ -426,7 +425,7 @@ The `Device.type` is a CodeableConcept which tells what the property is. There a
 |Continua Certified Device List|532353|MDC_REG_CERT_DATA_CONTINUA_CERT_DEV_LIST|
 
 ##### Time Synchronization
-There will always be a time synchronization entry. It is identified by a property.type.coding.code="68220". It indicates the method the PHD uses to externally synchronize to a time reference. The value is a single valueCode entry. MDC codes express the possible synchronization methods. A table of the possible codes can be found in the time synchronization section [here](StructureDefinition-PhdDevice.html). This value is TIME_SYNC_NONE (532224) if the PHD does not support a synchronization protocol or has no time clock at all. 
+There will always be a time synchronization entry. It is identified by a `property.type.coding.code="68220"`. It indicates the method the PHD uses to externally synchronize to a time reference. The value is a single valueCode entry. MDC codes express the possible synchronization methods. A table of the possible codes can be found in the time synchronization section [here](StructureDefinition-PhdDevice.html). This value is TIME_SYNC_NONE (532224) if the PHD does not support a synchronization protocol or has no time clock at all.
 
 An example of time synchronization property entry is shown below:
 {% fragment Device/phd-74E8FFFEFF051C00.001C05FFE874 JSON EXCEPT:property[4] %}
@@ -435,7 +434,7 @@ An example of time synchronization property entry is shown below:
 ##### Time Capabilities
 The time capabilities defines the types of real time clocks supported, whether the time can be set, whether external time synchronization is possible, etc. Each capability is treated as an event, so most PHGs will only report the capability if the PHD indicates it has the capability. The value is a single valueCode which will be either "Y" if the PHD has the capability or "N" if not. Most PHGs will not report the "N" case as that would significantly increase the size of the resource on the wire.  There may be several such time capability property entries.
 
-The time capabilities property is indicated by the `Device.code` having one of the ASN1ToHL7 codes of "68219.x" which is NOT a decimal number! The value is a valueCode with codes "Y" or "N".
+The time capabilities property is indicated by the `property.type.code` having one of the ASN1ToHL7 codes of "68219.x" which is NOT a decimal number! The value is a valueCode with codes "Y" or "N".
 
 The example below gives the time capabilities of a market pulse oximeter:
 
@@ -446,7 +445,7 @@ The time clock resolutions is given by one of four MDC codes for each of the pos
 
 The resolution value is a valueQuantity and it gives the time interval between clock 'pulses', regardless of the type of time clock, in units of microseconds.
 
-The property is indicated by the `Device.code` having one of four MDC codes "68222, 68223, 68224, and 68226". The value is a valueQuantity.
+The property is indicated by the `property.type.code` having one of four MDC codes "68222, 68223, 68224, and 68226". The value is a valueQuantity.
 
 An example of a time resolution property for a relative time clock with a time resolution of of one second is shown below:
 {% fragment Device/phd-74E8FFFEFF051C00.001C05FFE874 JSON EXCEPT:property[8] %}
@@ -461,7 +460,7 @@ ACOM-based ECGs do not use the time tick resolution to report R-R intervals.
 #### Regulation Status
 The Regulation status is a set of states where only one state is defined. Regulation Status is used to indicate which regulation body the PHD is regulated by. At the moment, the single defined state is assumed to be FDA. All market devices that currently report a regulated state are FDA regulated.
 
-The property is indicated by the `Device.code` having the ASN1ToHL7 code "532354.x" where the only currently defined entry is x=0. The value is a valueCode which can have a value "Y" or "N". The twist here is that the state has been defined in the negative. ***Thus a code value of "N" means regulated.***  Note that since this is a state, the PHG is required to report both the "Y" and "N" values *if* the PHD reports a regulation status.
+The property is indicated by the `property.type.code` having the ASN1ToHL7 code "532354.x" where the only currently defined entry is x=0. The value is a valueCode which can have a value "Y" or "N". The twist here is that the state has been defined in the negative. ***Thus a code value of "N" means regulated.***  Note that since this is a state, the PHG is required to report both the "Y" and "N" values *if* the PHD reports a regulation status.
 
 An example of an entry for an FDA regulated device is shown below:
 
@@ -470,7 +469,7 @@ An example of an entry for an FDA regulated device is shown below:
 #### Continua Certified PHD Interfaces
 This property contains a code that indicates a specialization and transport the PHD has been (self-)certified for. Note there is a difference between 'support' and 'certified' support. The Device specialization entries indicate what the PHD supports. Certified means the PHD has been (independently) placed through a set of extensive tests for the specialization and the transport over which the specialization operates. In the past, the Continua organization certified PHDs for compliance to its guidelines that referenced this IG.
 
-The property is indicated by the `Device.code` having the MDC code "532353". The value is a code from the [ValueSet for PHD Interfaces](ValueSet-ContinuaPHDInterfaces.html) code system.
+The property is indicated by the `property.type.code` having the MDC code "532353". The value is a code from the [ValueSet for PHD Interfaces](ValueSet-ContinuaPHDInterfaces.html) code system.
 
 An example of a property entry where a PHD is certified for the pulse oximeter specialization over both Bluetooth Low Energy, USB, and Continua version 1.0 where there was no transport indicated, is given below:
 
@@ -489,9 +488,10 @@ Only the entries that are different from the PHD are discussed in the following
 This field states that the device is a PHG. This IG uses the MDC code MDC_MOC_VMS_MDS_AHD that indicates a gateway. "AHD" stands for Application Hosting Device and is an older name for what is commonly known as a PHG.
 
 #### Continua Certified Health and Fitness Interfaces
-This property is a list of codes that indicate which Health and Fitness interfaces the PHG has been (self-)certified for. There is no certification body active for this IG, so this entry can be populated with Health and Fitness interfaces the PHG supports.
 
-The property is indicated by the `Device.code` having the MDC code "532355". The value is a list of valueCodes where the codes come from the [ContinuaHFS](CodeSystem-ContinuaHFS.html) code system. 
+The PHG can report the list of its certified Health and Fitness interfaces as a list of properties. Each of these properties report a code that indicates a Health and Fitness interface the PHG has been (self-)certified for. 
+
+The property is indicated by the `property.type.code` having the MDC code "532355". The  `valueCode` comes from the [ContinuaHFS](CodeSystem-ContinuaHFS.html) code system.
 
 An example of a PHG resource is given [here](Device-phg-example.html).
 
diff --git a/input/pagecontent/ProfilesOverview.md b/input/pagecontent/ProfilesOverview.md
index 04bb045..5f92ea3 100644
--- a/input/pagecontent/ProfilesOverview.md
+++ b/input/pagecontent/ProfilesOverview.md
@@ -29,7 +29,7 @@ The measurement observation profiles mirror more or less the measurement 'value-
 |                       |Multiple Event                   |[Compound Observation Profile](StructureDefinition-PhdCompoundObservation.html)                    |`component.valueCodeableConcept(s)`|
 |                       |Multiple Booleans (Bitstring)    |[BITs Enumeration Observation Profile](StructureDefinition-PhdBitsEnumerationObservation.html)     |`component.code`<br/>`component.valueCodeableConcepts`|
 |string                 |String                |[String Observation Profile](StructureDefinition-PhdStringObservation.html) |`valueString`|
-|peridoic samples       |Sample array                     |[Rtsa Observation Profile](StructureDefinition-PhdRtsaObservation.html)                            |`valueSampledData`|
+|periodic samples       |Sample array                     |[Rtsa Observation Profile](StructureDefinition-PhdRtsaObservation.html)                            |`valueSampledData`|
 |compound               |Compound                         |[Compound Observation Profile](StructureDefinition-PhdCompoundObservation.html)                    |`component.value[x]`|
 |compoundNumeric        |Compound Numeric                 |[Compound Numeric Observation Profile](StructureDefinition-PhdCompoundNumericObservation.html)     |`component.valueQuantity`|
 
@@ -43,7 +43,7 @@ Further information on the mapping of the ACOM Observation types to FHIR Observa
 The value-type of the measurement is the main difference between the observation-related profiles. The remaining attributes in the metric objects are common to all measurements and are thus mapped in the same way to FHIR.
 
 ### PHD Device Profile
-The PHD Device profile for the IEEE 11073-10206 ACOM System Information object supports the static device information like manufacturer name, model number, serial number, time properties, device type (blood pressure cuff, pulse oximeter, etc.), system identifier, transport address, etc. There is also a udiCarrier element that can support the UDI attribute.  
+The PHD Device profile for the IEEE 11073-10206 ACOM System Information object supports the static device information like manufacturer name, model number, serial number, time properties, device type (blood pressure cuff, pulse oximeter, etc.), system identifier, transport address, etc. There is also a udiCarrier element that supports the UDI attribute.
 
 ### PHG Device Profile
 A PHG is not part of IEEE 11073-10206 ACOM, but it is still software on a device and to work with a PHD it must support certain time features. The PHG is also responsible for correcting measurement timestamp data from the PHD if necessary. Thus, reporting the properties of the PHG, especially those properties that may have an influence on the reported measurement data, are considered important for this IG. To accomplish this task, the PHG is treated as if it has similar system information attributes as a PHD. In this manner a PHG can report its equivalent values of the information that would be in the PHD System Information. There is, however, no System-Type-Spec-List. It is clear that any measurement type a PHG decodes and maps it must support. Only the system-identifier and time synchronization values are required to be reported for a PHG.