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?

6. Current FHIR resources and references used for PHD IG
PHG
DeviceComponent
PHD Observation
device
parent
PHD top-level
DeviceComponent
source
Production specification
Properties
PHD DeviceComponent
Per System-Type-Spec-List entry
PHD DeviceComponent
Per System-Type-Spec-List entry
PHD DeviceComponent
Per System-Type-Spec-List entry

7. Current FHIR resources and references used for PHD IG

8. Modified FHIR resources and references used for PHD IG
PHG
Device
PHG Device and PHD Device could profile Device;
without needing extensions
parent
PHD Device
PHD Observation
device
production specification
properties
udi
type: 0..*

9. Modified FHIR resources and references used for PHD IG

10. Using DeviceMetric is an option
PHG
Device
DeviceMetric could be used for better alignment with PoCD.
Strictly speaking, no PHD information is lost without them.
Observations would then reference the metric.
The parent device reference could link to the PHG.
parent
parent
PHD Device
DeviceMetric
(per PHD metric object)
PHD Metric
Observation
DeviceMetric
(per PHD metric object)
device
DeviceMetric
(per PHD metric object)
production specification
properties
source
udi
type: 0..*

11. Using DeviceMetric is an option

12. Merged Device resource table+
DeviceComponent resource =
modified Device resource
notes
identifier
0..*
udi
0..1
operationalStatus
0..*??
status
type
1..1
status | operationalStatus
one status attribute probably suffices
lastSystemChange
this one can be plural for multifunction PHD devices
lotNumber
source - reference
manufacturer
parent - reference
manufactureDate
parameterGroup
expirationDate
measurementPrinciple
model
productionSpecification
version
languageCode
patient - reference
property
owner - reference
contact
location - reference
url
note
safety