Non 11073 20601 Devices

Not all Continua PHDs are based upon the 11073-20601 standard. Continua also supports Bluetooth Low Energy devices that follow the various Bluetooth Low Energy health device profiles and services. However, Continua requires that the information provided by the device is able to be mapped to 11073 20601 MDS and Metric objects by the PHG as specified in the transcoding white paper if the measurements are going to be propagated downstream by Continua transactions. The requirement does not mandate that the PHG actually create these objects but the resulting downstream messages have to be composed as if they had come from a compliant 11073 20601 device supporting the same type of measurement.

The transcoding requirements puts further demands on the Bluetooth Low Energy device over and above that specified in the Bluetooth Low Energy health device specifications. For example, the Bluetooth Low Energy Health Thermometer Profile and Service does not require that the device be able to report its sense of current time even if the device stores measurements. In addition, it does not require that stored measurements have a time stamp. Continua requires that all stored measurements have time stamps and all devices reporting measurements with time stamps are able to report its sense of current time. The reason is that PHDs often have unreliable time clocks that the PHG can correct if the PHG is able to obtain the PHD's sense of current time.

Bluetooth Low Energy devices use an exchange protocol that is not generic or extensible. Special implementation code is needed for every health device profile and service. The non-extensiblity means that PHDs supporting a new Bluetooth Low Energy health device specification will not interoperate with any PHGs that do not have pre-coded knowledge of that new health device specification.

In addition to Continua Bluetooth Low Energy PHDs, there are numerous proprietary medical devices on the market. It may be possible to map the measurements coming from these devices to the PHD profiles but that mapping would require that the resulting downstream resources be created and populated as if they had come from a compliant 11073 20601 device.

In this implementation guide, the PHD is treated as a 11073 20601 compliant device. When working with other device types, it is the responsibility of the FHIR encoder to 'virtually' map the data from the non 11073 20601 device to the 11073 20601 model before generating the PHD FHIR resources.