Personal Health Device Implementation Guide
2.0.0-ballot2 - STU 2 - Ballot 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 2.0.0-ballot2 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

Plain Language Summary goes here

Personal Health Device Implementation Guide Home Page

Official URL: http://hl7.org/fhir/uv/phd/ImplementationGuide/hl7.fhir.uv.phd Version: 2.0.0-ballot2
IG Standards status: Trial-use Maturity Level: 1 Computable Name: PhdImplementationGuide

Overview

This Implementation Guide (IG) defines the use of FHIR resources to convey measurements and supporting data from communicating Personal Health Devices (PHDs) to receiving systems for various purposes such as electronic medical record keeping, clinical decision support, medical data archiving, aggregate quality measurements and research purposes. PHDs are typically consumer devices designed to be used by people without medical background. These devices are often used in the home and on the patient's body and are a key element in remote patient monitoring program. Communicating PHDs use a communication protocol to transmit personal health data. In most cases there is a Personal Health Gateway (PHG) that handles the PHD communications. The PHG translates the PHD data to the appropriate form and uploads it to the receiving systems. Uploads generated by PHGs compliant to this IG shall use this the mapping defined by this implementation guide when transforming the PHD data to FHIR resources.

PHD IG context diagram
Context diagram of the PHD IG

A partner IG is the Point of Care Devices (PoCD) Implementation Guide. PoCDs focus on acute care and are operated by medical professionals. PoCDs are more complex than PHDs but both are based upon the IEEE 11073-10201 Domain Information Model (DIM) and use the same coding system, IEEE 11073-10101. The PoCD DIM is defined by the IEEE 11073-10201 standard while the PHD DIM is based upon the subset defined by the IEEE 11073-10206 Abstract Content Information Model (ACOM) standard. The purpose of both the PHD and PoCD IGs is to ensure that the DIM is mapped to FHIR in a complete, standardized, and consistent manner. Since both IGs are based on the IEEE 11073-10201 DIM, they are harmonized as much as possible. Neither IG provides any interpretation of the mapped data or guidance on actions to be taken with the data once it has been uploaded to a FHIR server.

Profile Consumers

Those readers who are interested in consuming the uploaded data do not need to know much about the IEEE 11073-10206 standard or the mapping algorithms defined in this IG. Instead one can go directly to the Profile Consumers chapter.

PHG Implementation Guidance

Those readers who are implementing a PHG are going to need an understanding of the IEEE 11073-10206 standard and the communication protocol used by the PHD being mapped. The Technical Implementation Guidance section gives an overview of the essential components of the IEEE 11073-10206 model and how its concepts are related to FHIR, but it is not a tutorial. The Profiles section gives the normative mapping between IEEE 11073-10206 concepts and FHIR resources, making several references to sub-sections in the Technical Implementation Guidance section for reminders. The IEEE 11073-10206 model is supported by the Bluetooth SIG Generic Health Sensor profile and service (GHS).

This implementation guide bases its mapping algorithm on the IEEE 11073-10206 model and standard (IEEE 11073-10206 Personal Health Device Communication - Abstract Content Model), which provides a generic and extensible model for observations and ensures consistent time management. However, this guide is not limited to IEEE 11073-10206 compliant PHDs using the mentioned protocols; it can be applied to any PHD that enables the establishment of a PHG-validated timestamp for its observations. The mapping defined in this guide is compatible with many existing PHDs, including Bluetooth Low Energy PHDs, whether proprietary or adhering to specific Bluetooth Low Energy Health Device Profiles. For more details, see Non-IEEE 11073-10206 PHD Devices.

A PHG-validated timestamp can be generated if a PHD gives access to its clock and the PHD is capable of reporting its clock status. The PHG can then use this information to generate a timestamp that is consistent with the PHG's externally synchronized UTC clock. This is important for ensuring that the data from the PHD is accurate and reliable.

Scope

The scope of this guide is limited to the modeling, mapping and usage of data from communicating PHDs, primarily consisting of physiological measurements, and device information. Furthermore, these PHDs must communicate a sufficient amount of information to guarantee the generation of reliable timestamps for observations.

It is anticipated that this guide will be used in any scenario where observations generated by PHDs are needed. For example, a patient care profile that requires a patient take one or more measurements using appropriate PHDs and upload those measurements as FHIR Observation resources. The patient care profile could specify the use of this IG to perform the uploads. The patient care profile would then know what FHIR resources to read and how to extract the information of interest from those resources.

This guide is concerned with the FHIR data model and specifies how one maps PHD information into FHIR resources and defines FHIR profiles of the FHIR resources involved. This mapping will typically be implemented in a PHG that uploads the PHD information to a FHIR Server.

The purpose of this Implementation Guide is to specify the mapping of PHD information to FHIR resources. No interpretations of the data or assumptions about what data is important are specified. PHG implementations following this guide map all viable data provided by the PHDs. PHGs are not required to upload all mapped data. Examples of not uploading everything include a fitness tracker and app on a mobile phone that uploads distance but not location or a HR monitor app not uploading "battery low" observations to the FHIR server. The receiver may handle the data as it sees fit for its use case. For example, a consumer may only be interested in the Observation resources and therefore discards the Device resources. For this reason, there is no use of the must-support criteria made by this IG.

This guide does not cover data provenance, security, privacy, or consent management. It is assumed that the PHG and FHIR Server will implement appropriate measures as required by local regulations and organizational policies.

Use Cases

The use cases for this guide are primarily focused on the remote patient monitoring domain, where PHDs are used to collect health data from patients in their homes or other non-clinical settings. See the Use Cases section for some of the use cases that this guide addresses.

History

The IEEE 11073-20601 specification is a predecessor of the IEEE 11073-10206 ACOM standard that supports almost the same DIM and in addition defines a binary presentation of the objects and a stateful application layer protocol. This standard was the basis for the Continua Design Guidelines and a certification programme by the Personal Connected Health Alliance (PCHA). This programme failed to gain a significant market position and is no longer operational, but nevertheless this IG can to a large extent also be used with PHDs and PHGs supporting the IEEE 11073-20601 specification. Where appropriate, this IG will explain the differences between the two standards.

References used throughout this IG

For a list of organizations referenced in this guide and their relevance, see the Organizations page.

For definitions of abbreviations used in this guide, see the Glossary page.