Personal Health Device Implementation Guide
current - CI Build

Personal Health Device Implementation Guide, published by HL7 International - Health Care Devices Work Group. This is not an authorized publication; it is the continuous build for version current). This version is based on the current content of https://github.com/HL7/PHD/ and changes regularly. See the Directory of published versions

Generic and Extensible Model

To address the list of issues and conditions relevant to remote patient monitoring, Continua requires PHDs and PHGs to be based upon the IEEE 11073 20601 data model where measurements and device information are represented in a set of abstract objects. These objects contain attributes that describe the objects. In some sense, the IEEE 11073 20601 objects are analogous to FHIR resources, and the attributes are analogous to FHIR resource elements. The attributes, like resource elements, have specified data types. All IEEE 11073 20601 device types from thermometers to home ventilators use the same set of objects and associated attributes. The simplest PHDs, like a thermometer, may instantiate only one measurement object whereas more complex PHDs like a home ventilator may have several. The sleep apnea breathing therapy equipment PHD defines more than 80 measurement objects.

In addition, the only PHD information that is required to be mapped is information provided by protocol; the patient is not expected to provide PHD data. For example, the software revision will be mapped if provided in the production specification attribute transmitted by the PHD. If the data is not provided in the attribute but IS, nevertheless, printed on the device, the patient is not expected to enter it so it can be mapped.

Generic measurement modeling and extensibility are not easy concepts to understand but they make implementation and maintenance easier for the uploading and reading applications.

This Implementation Guide specifies how one maps the 11073 20601 objects and their associated attributes to FHIR resources and resource elements. Using this approach, all PHDs based upon the IEEE 11073 20601 model, regardless of what it measures, can be handled by the PHG without requiring the PHG to view the values of the attributes; only the type of the attribute is used. Thus, a numeric attribute is always mapped the same way regardless of whether it is a temperature value or pulse rate value. In addition, if the 11073 20601 model PHDs are based upon does not change, PHD device types made in the future can also be mapped by current PHG implementations.

In the IEEE 11073 20601 Domain Information Model (DIM), IEEE 11073 10101 nomenclature codes are used to indicate what the items are. Thus, a reader of FHIR resources mapped from these DIM objects can decode any of these resources if it knows what the codes are. If a future device is deployed the reader will only need an update of its code dictionary to interpret the resource. A PHG uploader will not even need to update its dictionary to perform the mapping to FHIR as the codes are provided by the PHD through protocol. Furthermore, PHDs and PHGs following the 11073 20601 exchange protocol self-configure, so the PHG does not need to be pre-programmed with any information about the PHD specialization. These two features eliminate the need for remote updating and/or servicing of PHGs when new IEEE 11073 20601 PHDs are used.

Note – The expression 11073 x and IEEE 11073 x are used interchangeably in this document to represent the IEEE 11073 x standard. ‘x’ is either 20601 (Optimized Exchange Protocol) or 10xxx (Device Specializations) or 10101 (Nomenclature).