Personal Health Device Implementation Guide
1.0.0 - STU 1 International flag

Personal Health Device Implementation Guide, published by HL7 International / Health Care Devices. This guide is not an authorized publication; it is the continuous build for version 1.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/phd/ and changes regularly. See the Directory of published versions

Profiles Overview

This Implementation Guide utilizes 10 profiles and one base measurement profile that is part of the six measurement profiles. The PHD Numeric, Compound Numeric, Coded Enumeration, BITs Enumeration, String Enumeration, and Rtsa Observation Profiles are used to report one of the six possible measurement types or classes sent by PHDs. The PHD Coincident Time Stamp Observation Profile is present for time auditing purposes. The PHD Device Profile is used to report the PHD features and properties. The PHG Device Profile is used to report the PHG properties and the PHD Patient Profile is used to report the patient data. In the Continua use case the Patient resource may contain only keys to identify the patient that only the health care provider can match to a person. It is also possible in the Continua architecture that the Patient resource is never sent on the wire by the uploader. In that case the logical id to a Patient resource on the destination server must be provided to the uploader by out-of-band means.

Notes on Examples

The examples referenced in these profile sections are what is uploaded. These examples will differ slightly from similar examples in the Artifacts section. The reason is that the examples in the Artificats section are required to represent the resource as it appears on the server. However, when uploading, create operations either have no logical ids or temporary logical ids. Resources on the server, however, are required to have logical ids.

Measurement Observation Profiles

The six measurement observation profiles mirror the six measurement ‘value-types’ of that a IEEE 11073-20601 PHD can report. The measurement value-types and their mapping to FHIR Observation elements are shown in the following table:

Measurement value-type IEEE attribute type FHIR Observation element
scalar single numeric valueQuantity
vector compound numeric component.valueQuantity
code coded enumeration valueCodeableConcept
bits (events or states) BITs enumeration component.code
component.valueCodeableConcept
string string enumeration valueString
peridoic samples sample array valueSampledData

The value-type of 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-20601 MDS object is for the device information like manufacturer name, model number, serial number, time properties, device type (blood pressure cuff, pulse oximeter, etc.), system identifier, transport address, etc. The Device resource in FHIR has just undergone major changes. The DeviceComponent resource, used in a preliminary version of this IG has been merged into the Device and the DeviceComponent no longer exists. The productionSpecification element no longer exists as a backbone element but has been broken up into its concomitant parts. A new specializations field has been added. There is also a udiCarrier element which will support the new 20601 MDS Udi attribute. Since there are no PHDs on the market which support an electronic UID via protocol, there is no mapping of the UDI considered in this Guide.

Though the changes in the Device related resources have been radical, the changes are much more suitable for PHDs.

MDS Attribute FHIR Device element
System-Id
Transport Address (not an attribute)		 identifier
System-Type-Spec-List specializations
device friendly name (not an attribute
but often available from transports)		 deviceName
Udi udiCarrier
System-Model manufacturer
modelNumber
Production-Specification serialNumber
version
partNumber
Reg-Cert-Data-List.continua_version version
Mds-Time-Info
Reg-Cert-Data-List.continua-certified-device-list
Reg-Cert-Data-List.regulation_status		 property

PHG Device Profile

A PHG does not have an MDS object 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 time stamp 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, has been considered important in the Continua architecture. To accomplish this task, the PHG is treated as if it has an MDS object with potentially all the attributes a PHD might have in its MDS. In this manner a PHG can report its equivalent values of the information that would be in the System-Id, System-Model, Production-Specification, Reg-Cert-Data-List, etc. There is, however, no System-Type-Spec-List. It is clear that any measurement type a PHG decodes and maps it must support. Using the ‘MDS’ concept, the PHG information is mapped to the PHG Device in the same manner as a PHD is mapped to the Device. However, only the System id and time synchronization values are required to be reported.

Some Notes for Implementers of Uploaders

One of the choices implementers have when uploading resources is to upload individual resources or upload a bundled set of resources. A challenge that implementers will have in either case as that the Observation resources have required references to Patient, PHD Device, and PHG Device resources, and often require references to a Coincident Time Stamp Observation resource and perhaps other Observation resources (when the PHD sends a source handle reference attribute). To obtain these references, one generally has to wait for the upload response from the server. When implementing a generic uploader that must be able to handle Coincident Time Stamps and source-handle-references, this wait can significantly complicate the code and place a burden upon memory requirements.

A transaction Bundle may prove useful in that case. A bundled upload will contain all or several of the resources, and resources within the Bundle that reference one another can be handled using temporary ids. One can use conditional creates on the Patient and Device resources and include them in the Bundle every time or at least until a response from the server gives one the logical ids. When the logical ids are obtained, the Patient and Device resources will no longer need to be included in the bundle. In the mean time, the conditional create assures no data duplication. One could refrain from ever checking the server response and always use conditional creates. However, that approach does put an extra burden on the server and does waste bandwidth. But platforms with limited hardware may have no other choice.

On the other hand, if the use case only involves PHDs that do not emit source-handle-references and do not need a Coincident Time Stamp, the single upload approach may prove to be much more efficient. It is also permissible to mix and match, using both single and Bundled uploads.

The Profiles