HL7 · ErikMoll · Jul 28, 2025 · Jul 28, 2025 · Jul 28, 2025
diff --git a/input-cache/schemas/R5/fhir-single.xsd b/input-cache/schemas/R5/fhir-single.xsd
@@ -47,7 +47,7 @@
   POSSIBILITY OF SUCH DAMAGE.
 
 
-  Generated on Thu, Jul 24, 2025 22:57+0000 for FHIR v6.0.0-ballot2 
+  Generated on Sat, Jul 26, 2025 01:41+0000 for FHIR v6.0.0-ballot2 
 -->
 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://hl7.org/fhir" xmlns:xhtml="http://www.w3.org/1999/xhtml" xmlns:xml="http://www.w3.org/XML/1998/namespace" targetNamespace="http://hl7.org/fhir" elementFormDefault="qualified" version="6.0.0-ballot2">
   <!-- Note: When using this schema with some tools, it may also be necessary to declare xmlns:xml="http://www.w3.org/XML/1998/namespace", however this causes performance issues with other tools and thus is not in the base schemas. -->
@@ -32016,7 +32016,7 @@ RegisteredName | UserFriendlyName | PatientReportedName.</xs:documentation>
           </xs:element>
           <xs:element name="device" minOccurs="1" maxOccurs="1" type="Reference">
             <xs:annotation>
-              <xs:documentation xml:lang="en">Describes the link to the Device.  This is also known as a channel device.</xs:documentation>
+              <xs:documentation xml:lang="en">Describes the link to the Device. This is also known as a channel device.</xs:documentation>
            </xs:annotation>
           </xs:element>
           <xs:element name="operationalStatus" minOccurs="0" maxOccurs="1" type="DeviceMetricOperationalStatus">
@@ -32036,7 +32036,7 @@ RegisteredName | UserFriendlyName | PatientReportedName.</xs:documentation>
           </xs:element>
           <xs:element name="measurementFrequency" minOccurs="0" maxOccurs="1" type="Quantity">
             <xs:annotation>
-              <xs:documentation xml:lang="en">The frequency at which the metric is taken or recorded. Devices measure metrics at a wide range of frequencies; for example, an ECG might sample measurements in the millisecond range, while an NIBP might trigger only once an hour. Less often, the measurementFrequency may be based on a unit other than time, such as distance (e.g. for a measuring wheel). The update period may be different than the measurement frequency, if the device does not update the published observed value with the same frequency as it was measured.</xs:documentation>
+              <xs:documentation xml:lang="en">The frequency at which the metric is taken or recorded. Devices measure metrics at a wide range of frequencies; for example, an ECG might sample measurements in the millisecond range, while an NIBP might trigger only once an hour. Less often, the measurementFrequency may be based on a unit other than time, such as distance (e.g., for a measuring wheel). The update period may be different than the measurement frequency, if the device does not update the published observed value with the same frequency as it was measured.</xs:documentation>
            </xs:annotation>
           </xs:element>
           <xs:element name="availability" minOccurs="0" maxOccurs="1" type="CodeableConcept">

diff --git a/input/intro-notes/StructureDefinition-PhdRtsaObservation-intro.md b/input/intro-notes/StructureDefinition-PhdRtsaObservation-intro.md
@@ -5,7 +5,7 @@ border: 1px solid black;
 border-collapse:collapse;
 padding: 6px;}</style>
 
-The values are scaled to reduced bandwidth. The bandwidth reduction can be significant in cases where the actual values are small fluctuations about a large average value. The scale factors, number of bits in each sample, the period, and the number of data elements in the sequence are given by a set of support attributes.
+The values are scaled to reduced bandwidth. The bandwidth reduction can be significant in cases where the actual values are small fluctuations about a large average value. The scale factors, number of bits in each sample, the period, and the number of samples in the sequence are given by a set of support attributes.
 
 IEEE 11073-10206 ACOM and GHS support the concept of multi-dimensional arrays. Reporting a sequence of x, y, z acceleration components from a PHD can be done by reporting 3 samples per period, that all share the same unit and scaling factors. FHIR also support the concept of multi-dimensional arrays. 
 

diff --git a/input/intro-notes/StructureDefinition-PhdStringEnumerationObservation-intro.md b/input/intro-notes/StructureDefinition-PhdStringEnumerationObservation-intro.md
@@ -1,4 +1,4 @@
 The PHD String Observation Profile is used when the PHD observation reports a human readable string. As an example, it is used in the Cardiovascular device specialization to report the name of an exercise program option. These types of observations have the disadvantage of being language dependent. Codes are often used instead where the end user can display them appropriately based upon locale.
 
-This profile is used to map ACOM and GHS String Observations. The ACOM/GHS string value is mapped to the `Observation.valueString` data element.
+This profile is used to map ACOM and GHS String Observations. The ACOM/GHS string value is mapped to the `Observation.valueString` element.
 
diff --git a/input/intro-notes/StructureDefinition-PhgDevice-intro.md b/input/intro-notes/StructureDefinition-PhgDevice-intro.md
@@ -13,7 +13,7 @@ padding: 6px;}</style>
 
 |Required field|Device element|
 |--|---|
-|System Identifier|identifier|
-|Time sync protocol|property|
+|System Identifier|`identifier`|
+|Time sync protocol|`property`|
 
-A transport address is not required. It is still strongly recommended that the transport address is reported as it is often beneficial to consumers. Most PHD-PHG transports provide a means of obtaining a transport address or an equivalent identifier such as a MAC address. In addition, it may be beneficial to report the transport address of the H&FS interface as well.
+A transport address is not required. It is recommended that the transport address is reported as it is often useful to consumers. Most PHD-PHG transports provide a means of obtaining a transport address or an equivalent identifier such as a MAC address. In addition, it may be beneficial to report the transport address of the H&FS interface as well.
diff --git a/input/intro-notes/StructureDefinition-PhgDevice-notes.md b/input/intro-notes/StructureDefinition-PhgDevice-notes.md
@@ -9,7 +9,7 @@ PHGs are required to have a system identifier.  This identifier follows the same
 The PHG `Device.type` is given by the MDC code 531981. The reference identifier for this code is `MDC_MOC_VMS_MDS_AHD`. "AHD" stands for Application Hosting Device and is an old  name for what is commonly known as a PHG.
 
 #### Time synchronization
-The time synchronization is mapped to a device property element with as type the MDC code 68220. The possible codes for the time synchronization method come from the [MDC Time Synchronization Methods value set](ValueSet-MDCTimeSyncMethods.html).
+The time synchronization is mapped to a `property` element with as type the MDC code 68220. The possible codes for the time synchronization method come from the [MDC Time Synchronization Methods value set](ValueSet-MDCTimeSyncMethods.html).
 
 #### Remaining Optional Data
 The treatment of further optional information in a mock SystemInfo object is similar as in the Phd Device Profile.
@@ -21,7 +21,7 @@ The specializations supported by the PHG may be reported. If reported, they shal
 
 If the PHG supports multiple versions of the specialization and the uploader wants to report this information, additional specializations entries for the additional versions are made. Alternatively the uploader can leave the version field empty.
 
-A PHG is often designed to support all current and future PHDs that support a given version of the IEEE 11073-10206 standard. Instead of listing all the specializations individually (which could greatly increase the size of the message) one can use the 'generic' device code. In this case, the `specialization.version` element, if populated, indicates the version of the IEEE 11073-10206 standard. If multiple versions of the IEEE 11073-10206 standard are supported and the uploader wants to report this information, a separate 'generic' entries for each version are reported. Alternatively, the version element can be left empty.
+A PHG is often designed to support all current and future PHDs that support a given version of the IEEE 11073-10206 standard. Instead of listing all the specializations individually (which could greatly increase the size of the message) one can use the 'generic' device code. In this case, the `specialization.version` element, if populated, indicates the version of the IEEE 11073-10206 standard. If multiple versions of the IEEE 11073-10206 standard are supported and the uploader wants to report this information, a separate 'generic' entries for each version are reported. Alternatively, the `version` element can be left empty.
 
 An example of generic code use would be as follows
 

diff --git a/publication-request.json b/publication-request.json
@@ -2,10 +2,10 @@
     "package-id" : "hl7.fhir.uv.phd",
     "version" : "2.1.0",
     "path" : "http://hl7.org/fhir/uv/phd/2.1.0",
-    "mode" : "milestone",
+    "mode" : "working",
     "status": "ballot",
     "sequence": "STU 2",
-    "desc": "This version is a technical correction based on IEEE 11073-10206 - ACOM with Bluetooth GHS support.",
+    "desc": "STU 2 - 2nd ballot. This version is based on IEEE 11073-10206 - ACOM with Bluetooth GHS support.",
     "changes" : "input/pagecontent/changes.md",
     "first" : false
   }