Mapping IEEE 11073 PHD to FHIR - context The PCHA is working on a mapping from observations originating from IEEE 11073 Personal Health Devices to HL7 FHIR Resources This work is part of the H.812.5 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 11073 PoCD. This set of slides focuses on issues with the PHD FHIR usage.

Mapping PHD to Device[Component] in FHIR - details H.812.5 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.

Background: FHIR resources - UML

(Example) Mapping PHD to FHIR Note: IEEE PHD Metrics are not mapped (yet) to FHIR DeviceMetric IEEE 11073 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

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?

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

Current FHIR resources and references used for PHD IG

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

Modified FHIR resources and references used for PHD IG

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

Using DeviceMetric is an option

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