Profiles

This implementation Guide utilizes 11 structure definition 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 ParentDeviceComponent Profile is used to report the PHD features and properties. The Phg DeviceComponent Profile is used to report the PHG properties and the Phd Patient Profile the patient data. In the Continua use case the Patient resource may contain only keys to identifiy 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.

Measurement Observation Profiles

The six measurement observation profiles mirror the six classes of measurements that a 11073 20601 PHD can report. The measurement classes and their mapping to FHIR Observation elements are shown in the following table:

The 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.

DeviceComponent Profiles

The two DeviceComponent profiles for the 11073 20601 MDS object are 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. In most cases, only the Parent DeviceComponent Profile is needed. The Child DeviceComponent Profile is used when the PHD supports sub-profiles such as a cardio specialization with a step counter sub-profile, and/or multiple specializations, such as a pulse oximeter and electrocardiogram. In those cases a Child DeviceComponent Profile is used to report each specialization or sub-profile. The only required device information related entry in the child resources is the DeviceComponent.type element indciating the specialization or sub-profile. The remaining elements are not populated with any device information and are, for the most part, empty.

In the case the Child DeviceComponent is needed the mapping is quite simple.

Rationale For the Child DeviceComponent

For those familiar with the Continua-IHE mapping of PHD data to PCD-01 messages, the use of a Child DeviceComponent to handle multiple specializations and sub profiles may seem inconsistent. In PCD-01, multiple specializations are handled using a HYDRA designation in the top-level OBX and the remaining specializations are handled in a System-Type-Spec-List OBX with OBX-5 containing the list of CWE data types containing the MDC codes for the specializations. One would then expect that the DeviceComponent.type would be HYDRA and that the remaining specializations would be placed in the DeviceComponent.property element. If the PCD-01 were to follow the above FHIR resource mapping, each specialization would be placed in an OBX with its own VMD OBX-4 hierarchy entry and all measurement OBXes from that specialization would be under that VMD. It was not done in PCD-01 since a PHD does not support a VMD. In the FHIR case the approach has changed to harmonize with Point of Care Devices which are based upon the 11073 10201 standard and do have VMD objects.

The problem with this approach is that it defeats future interoperability designed into the remainder of this implementation guide and requires that PHGs have a pre-installed dictionary relating all Type attribute codes to the specialization or sub profile. Supporting such a dictionary will require more resources which will pose problems on limited resource platforms.

PHG DeviceComponent 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 a MDS 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 DeviceComponent in the same manner as a PHD is mapped to the Parent DeviceComponent. There is no need for child DeviceComponents.