Skip to content

Commit 0118e55

Browse files
ErikMollErikMoll
authored
Merge pull request #71 from HL7/ACOM-GHS-support
Updated pub request & minor editorials
2 parents 6967ac1 + e46cfe6 commit 0118e55

6 files changed

Lines changed: 12 additions & 12 deletions

‎input-cache/schemas/R5/fhir-single.xsd‎

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -47,7 +47,7 @@
4747
POSSIBILITY OF SUCH DAMAGE.
4848

4949

50-
Generated on Thu, Jul 24, 2025 22:57+0000 for FHIR v6.0.0-ballot2
50+
Generated on Sat, Jul 26, 2025 01:41+0000 for FHIR v6.0.0-ballot2
5151
-->
5252
<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">
5353
<!-- 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>
3201632016
</xs:element>
3201732017
<xs:element name="device" minOccurs="1" maxOccurs="1" type="Reference">
3201832018
<xs:annotation>
32019-
<xs:documentation xml:lang="en">Describes the link to the Device. This is also known as a channel device.</xs:documentation>
32019+
<xs:documentation xml:lang="en">Describes the link to the Device. This is also known as a channel device.</xs:documentation>
3202032020
</xs:annotation>
3202132021
</xs:element>
3202232022
<xs:element name="operationalStatus" minOccurs="0" maxOccurs="1" type="DeviceMetricOperationalStatus">
@@ -32036,7 +32036,7 @@ RegisteredName | UserFriendlyName | PatientReportedName.</xs:documentation>
3203632036
</xs:element>
3203732037
<xs:element name="measurementFrequency" minOccurs="0" maxOccurs="1" type="Quantity">
3203832038
<xs:annotation>
32039-
<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>
32039+
<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>
3204032040
</xs:annotation>
3204132041
</xs:element>
3204232042
<xs:element name="availability" minOccurs="0" maxOccurs="1" type="CodeableConcept">

‎input/intro-notes/StructureDefinition-PhdRtsaObservation-intro.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@ border: 1px solid black;
55
border-collapse:collapse;
66
padding: 6px;}</style>
77

8-
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.
8+
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.
99

1010
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.
1111

‎input/intro-notes/StructureDefinition-PhdStringEnumerationObservation-intro.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
11
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.
22

3-
This profile is used to map ACOM and GHS String Observations. The ACOM/GHS string value is mapped to the `Observation.valueString` data element.
3+
This profile is used to map ACOM and GHS String Observations. The ACOM/GHS string value is mapped to the `Observation.valueString` element.
44

‎input/intro-notes/StructureDefinition-PhgDevice-intro.md‎

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -13,7 +13,7 @@ padding: 6px;}</style>
1313

1414
|Required field|Device element|
1515
|--|---|
16-
|System Identifier|identifier|
17-
|Time sync protocol|property|
16+
|System Identifier|`identifier`|
17+
|Time sync protocol|`property`|
1818

19-
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.
19+
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.

‎input/intro-notes/StructureDefinition-PhgDevice-notes.md‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -9,7 +9,7 @@ PHGs are required to have a system identifier. This identifier follows the same
99
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.
1010

1111
#### Time synchronization
12-
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).
12+
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).
1313

1414
#### Remaining Optional Data
1515
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
2121

2222
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.
2323

24-
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.
24+
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.
2525

2626
An example of generic code use would be as follows
2727

‎publication-request.json‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -2,10 +2,10 @@
22
"package-id" : "hl7.fhir.uv.phd",
33
"version" : "2.1.0",
44
"path" : "http://hl7.org/fhir/uv/phd/2.1.0",
5-
"mode" : "milestone",
5+
"mode" : "working",
66
"status": "ballot",
77
"sequence": "STU 2",
8-
"desc": "This version is a technical correction based on IEEE 11073-10206 - ACOM with Bluetooth GHS support.",
8+
"desc": "STU 2 - 2nd ballot. This version is based on IEEE 11073-10206 - ACOM with Bluetooth GHS support.",
99
"changes" : "input/pagecontent/changes.md",
1010
"first" : false
1111
}

0 commit comments

Comments
 (0)