1. Mapping IEEE 11073 PHD to FHIR - context
The PCHA is working on a mapping from observations originating from IEEE Personal Health Devices to HL7 FHIR Resources
This work is part of the H implementation guide – for trial use
This work also defines an HL7 implementation guide that profiles a number of FHIR resources.
Similar work is done for IEEE PoCD.
This set of slides focuses on issues with the PHD FHIR usage.

2. Mapping PHD to Device[Component] in FHIR - details
H uses 3 FHIR resource types to map IEEE PHD data to FHIR:
Patient – to identify the patient to whom the observations apply
DeviceComponent – data identifying the PHD device and its status
Observation – measurements or assertions on a patient or on a PHD device
Issues:
A PHD that supports multiple specializations is mapped to multiple DeviceComponents – one per specialization and a top-level DeviceComponent that contains the productionSpecification
This is done since DeviceComponent.type is a single attribute that can contain only one device type value
To map the System-Type-Spec-List multiple DeviceComponents are needed that reference a top-level DeviceComponent – to avoid repeating the productionSpecification
This is a rather complex mapping
The FHIR Device resource does include UDI as an attribute and DeviceComponent does not and vice versa the FHIR Device resource does not include the productionSpecification.
=> a Device resource will be needed or UDI should be added to DeviceComponent
The conceptual difference between Device and DeviceComponent is unclear and many of the attributes overlap already.
Note that FHIR Observations can reference a Device, a DeviceComponent or a DeviceMetric
Since EHRs are, due to CDA, more likely to support Device, we prefer to use Device for the mapping.

3. Background: FHIR resources - UML

4. (Example) Mapping PHD to FHIR
Note: IEEE PHD Metrics are not mapped (yet) to FHIR DeviceMetric
IEEE PHD
MDS Object
With prodSpec and UDI
SpO2 Numeric
Pulse Rate Numeric
Body Mass Numeric
Height Numeric
BMI Numeric
Event report
(carrying a metric)
FHIR Resources
Device
FHIR
Observation
UDI
WeightScale
DeviceComponent
TopLevel DeviceComponent
Body Mass DeviceMetric
Height DeviceMetric
BMI DeviceMetric
productionSpec
PulseOx DeviceComponent
SpO2 DeviceMetric
PulseRate DeviceMetric

5. PCHA Requested changes on HL7 FHIR resources
Can Device and DeviceComponent be merged in the next FHIR release?
If a merge cannot be achieved, can UDI be added to DeviceComponent?
Can there be an attribute in DeviceComponent and/or Device that can carry multiple device types?
E.g. DeviceComponent.type with 1..* multiplicity
Question: would a mapping of the IEEE Metric objects to FHIR DeviceMetric resources be useful?