Phd Parent DeviceComponent Profile

The properties and specifications of the PHD are reported in the DeviceComponent. These are the static fields of the attributes reported in the PHD MDS object or Bluetooth Low Energy Device Information Service.

There are six MDS attributes that are reported. The Mds-Time-Info attribute has fields that are dynamic and static, and it is only the static entries which are considered. The following table summarizes these attributes and the DeviceComponent elements to which they are mapped:

The transport address is not required unless the PHD does not report a System Id. It is still strongly recommended that the transport address is reported as it is often beneficial to consumers. Most PHD transports provide a means of obtaining a transport address or an equivalent identifier such as a USB VID and PID.

There are several CodeableConcept data types in this mapping where the Coding data type has a 'display' element. It is recommended to put the MDC reference identifier as part of the display element if known and when the system element indicates the MDC coding system "urn.iso.std.iso:11073:10101".

The structure definition for the Parent DeviceComponent Profile is shown below:

phdParentDeviceComponent

urn:oid:1.2.840.10004.1.1.1.0.0.1.0.0.1.2680

urn:iso:std:iso:11073:10101

urn:iso:std:iso:11073:10101

http://hl7.org/fhir/specification-type

A JSON example is given in Phd Parent DeviceComponent JSON Example

This structure definition is missing the property element as it is based upon a tool that does not yet support version 3.2.0 of FHIR. The structure definition will be updated when support for 3.2.0 is available.

Meta Data Profile

The uploader shall populate the DeviceComponent.meta.profile with http://pchalliance.org/phdfhir/StructureDefinition/PhdParentDeviceComponent indicating this resource was generated following the PHD Implementation Guide.

System Identifier

All 11073 20601 PHDs are required to have a system identifier. It is an EUI-64 consisting of 8 bytes. The system id is mapped to the DeviceComponent.identifier.value element as a sequence of 8 2-digit bytes as HEX separated by dashes without the '0x' prefix commonly used in programming languages. An example of such a string is FE-ED-AB-EE-DE-AD-77-C3. Though required for Continua compliance, it is not required in the Bluetooth Low Energy health device specifications. When a PHG encounters such a device it shall enter 00-00-00-00-00-00-00-00 and the uploader is required to provide a transport address as a means of uniquely identifying the PHD. The transport addresses are as follows:

The System-Id entry shall be first and the transport entry, if present, shall be second.

System Type Spec List - Single Entry

The System-Type-Spec-List attribute contains a list of specializations as 16-bit MDC term codes supported by the PHD. The partition is assumed to be 'Infra' (8). In most cases there is just one entry. When there is just one entry, the 32-bit value is mapped to the DeviceComponent.type.coding.code element.

The table below gives a list of some of the most common specializations and their codes:

System Type Spec List - Multiple Entries

TODO: using the proposed mapping is both non-extensible and complex as it reverses the 11073-10201 multiple VMDs to 11073-20601 System-Type-Spec-List. However, the PHG does not get VMD objects information from the PHD and thus must reconctruct VMDs from the single attribute. The PHG has no way to determine which PHD measurements are associated with this artificially created set of VMDs without having a pre-defined mapping. When future specializations emerge, the mapping will be unknown. - Will enter a comment to use a simple extension and report the extra specializations in the extension as is done in PCD-01. If an extension is used, there will be no need for a Child Device Component profile.

Note - it is hoped to eliminate this requirement and either use an extension (as in PCD-01) or make the DeviceComponent.type 1..*

Parent

The parent element is used to reference the PHG Device Component Profile.

Production Specification and System Model

The DeviceComponent.productionSpecification is natively designed to handle the eight currently-defined 11073 Production-Specification attribute entries;

• unspecified, serial-number, part-number, hw-revision, sw-revision, fw-revision, protocol-revision, and prod-spec-gmdn.

These eight codes have been adopted by FHIR into a special value set DeviceSpecificationSpecType to define what the DeviceComponent.productionSpecification.productionSpec value is. Thus if

• DeviceComponent.productionSpecification.specType.coding.code="serial-number" and
• DeviceComponent.productionSpecification.specType.coding.system="http://hl7.org/fhir/specification-type",

then

• DeviceComponent.productionSpecification.productionSpec="1234567" would be interpreted as the serial number.

As an alternative, one could use the MDC coding system to report the same information

• DeviceComponent.productionSpecification.specType.coding.code="531972" and
• DeviceComponent.productionSpecification.specType.coding.system="urn.iso.std.iso:11073:10101"
• DeviceComponent.productionSpecification.productionSpec="1234567"

MDC codes have been defined for the Production-Specification, System-Model, and Reg-Cert-Data-List, and Mds-Time-Info attribute entries for use in HL7 V2 PCD-01 messages. These MDC codes are as follows:

This profile requires that the MDC coding system is used. Since FHIR versions 3.0.1 and later added the requirement that the DeviceSpecificationSpecType value set be used when the value set has such a code, if a production specification value is being mapped using one of the eight original fields, a code entry for both the MDC and DeviceSpecificationSpecType is required.

When both coding systems are present, the MDC coding system entry shall be first.

The final mapping of MDS attributes to the DeviceComponent.productionSpecification element is as follows:

Property

The property element is introduced in version 3.2.0 of FHIR. This element is used to report the regulation status, Continua certified PAN (Personal Area Network) interfaces, and the static time properties such as synchronization state, synchronization accuracy, type of time clock, and the resolution of the time clock. The sources of this information come from the Reg-Cert-Data-List and Mds-Time-Info attributes.

Reg-Cert-Data-List Contributions

In addition to the Continua version reported in the DeviceComponent.productionSpecification, the Reg-Cert-Data-List attribute reports the list of Continua certified PAN interfaces and the regulation status. The certified PAN interfaces are reported as a list of Continua-specified codes and the regulation status element is a 16-bit ASN1 BITs 'state' value with only Mder bit 0 currently defined.

The Continua-specified certification codes are a combination of a transport 'Tcode' and a specialization code which is based on the 16-bit term code of the MDC code for the specialization. The reported code is generated by

• reportedCode = Tcode * 8192 + (specialization term code - 4096)

The transport 'Tcodes' are as follows:

The special Tcode of 0 is for Continua version 1.0 when there was no transport component in the reported certified PAN interface codes.

The regulation status Mder bit-0 is defined 'backwards' in that the set value is unregulated and the cleared value is regulated. Given that this bit is a 'state' value, it is required to report both the cleared or set states.

The mapping of these Reg-Cert-Data-List attribute values to the DeviceComponent.property element is as follows:

Note that the cardinality of the property.valueCodeableConcept and property.valueQuantity element is 0 to many thus one is able to report a list of related properties (such as the list of certified PAN interfaces) with limited overhead.

Mds-Time-Info Contributions

The Mds-Time-Info attribute is required on PHDs that support a real time clock of some type and report time stamps in their measurements. In Bluetooth Low Energy devices these properties must be inferred from other information like the Current Time Service. If the PHD does NOT report a time stamp in any of its measurements, there is no need to report the static time information.

Time Capabilities

The Mds-Time-Info attribute has a 16-bit ASN1 BITs field for the time capabilities. They are mapped as follows:

The required remaining property elements in each reported case are as follows:

• property.type.coding.system="placeholder/fhir/IEEE.ASN1"
• property.valueCodeableConcept.coding.code="Y/N"
• property.valueCodeableConcept.coding.system="http://hl7.org/fhir/v2/0136 "

Only the static fields shall be reported and all the static fields are treated as events thus they only need to be reported if set. Reporting cleared static states is optional. Reporting dynamic values is not allowed.

Time Synchronization

The Mds-Time-Info.time-sync-protocol indicates the method of time synchronization which has one of the term code values in the following table:

If the Mds-Time-Info.time-sync-protocol indicates some other value besides 7936 (no time synchronization) the uploader must look at the time capabilities bits 8, 9, 10, or 13 to see if the PHD actually is synchronized. If the time capabilities bits indicate that the PHD is synchronized, then the time synchronization method in Mds-Time-Info.time-sync-protocol is reported in the DeviceComponent.property element otherwise the uploader reports that the PHD is unsynchronized.

The uploader maps the state of synchronization to the DeviceComponent.property as follows:

• DeviceComponent.property.type.coding.code="68220"
• DeviceComponent.property.type.coding.system="urn.iso.std.iso:11073:10101"
• DeviceComponent.property.type.coding.display="MDC_TIME_SYNC_PROTOCOL" (optional)
• DeviceComponent.property.valueCodeableConcept.coding.code="32-bit code for sync method"
• DeviceComponent.property.valueCodeableConcept.coding.system="urn.iso.std.iso:11073:10101"
• DeviceComponent.property.valueCodeableConcept.coding.display="the ref id" (optional)

To date there are no PHDs that support an external time synchronization. However, many PHDs have the PHG set its time and PHGs are required to support an external time synchronization. The IEEE PHD WG is working on providing some means to indicate synchronization by the PHG. In lieu of that, a consumer can only infer that the PHG probably set the time on the PHG if

• the PHD indicates that set time is supported
• the coincident time stamp indicates that the current time differences between the PHG and PHD are about 0.

Time Synchronization Accuracy

The time synchronization accuracy is given by the Mds-Time-Info.time-sync-accuracy field. This value shall not be reported if the PHD reports a value of 0xFFFFFFFF which indicates unknown. Otherwise the value reported is in units of 1/8^th millisecond. When reported in the DeviceComponent.property element it is scaled to microseconds. The mapping is as follows:

• DeviceComponent.property.type.coding.code="68221"
• DeviceComponent.property.type.coding.system="urn.iso.std.iso:11073:10101"
• DeviceComponent.property.type.coding.display="MDC_TIME_SYNC_ACCURACY" (optional)
• DeviceComponent.property.valueQuantity.value="125 x Mds-Time-Info.time-sync-accuracy"
• DeviceComponent.property.valueQuantity.system="urn.iso.std.iso:11073:10101"
• DeviceComponent.property.valueQuantity.code="264339" (MDC code for microseconds)
• DeviceComponent.property.valueQuantity.units="us" (Optional UCUM string)

Time Resolution

Then Mds-Time-Info attribute has fields that report the resolution of its time clocks.

The Mds-Time-Info.time-resolution-abs-time represents the resolution of the absolute-time clock when the sensor supports an absolute time clock. If the sensor supports a base-offset time clock it represents the resolution of the base-offset time clock. The sensor is not able to support both time clocks simultaneously. Which time clock is supported is indicated by the settings of the Mder 0 and 7 bits of the time capabilities (Mds-Time-Info.mds-time-caps-state).

The sensor may additionally support both relative time clocks or just the relative time clocks without any ‘wall time’ clock. In practice, support of more than one real time clock at the same time is rare.

If the respective time resolution has a value of 0, it indicates that the resolution is unknown and it shall not be reported. In all other cases, the resolutions may be reported.

When reported, all time resolutions values shall be scaled to units of microseconds. When supporting absolute time, the Mds-Time-Info.time-resolution-abs-time is in units of 1/100th of a second. When supporting base-offset time, the Mds-Time-Info.time-resolution-abs-time is in units of 1/65536th of a second. In the base-offset case, the special value of 0xFFFF means one second. The Mds-Time-Info.time-resolution-rel-time is in units of 1/8th millisecond and the Mds-Time-Info.time-resolution-hi-res-relative-time is in units of microseconds.

If the time resolutions are reported, each time resolution the application wishes to report shall be encoded as follows:

Consumer of the PHD DeviceComponent Profile

For the Consumer of this profile the following table gives a quick guide to the main features