Point-of-Care Device Implementation Guide
current - CI Build International flag

Point-of-Care Device Implementation Guide, published by HL7 International - Devices Work Group. This is not an authorized publication; it is the continuous build for version current). This version is based on the current content of https://github.com/HL7/uv-pocd/ and changes regularly. See the Directory of published versions

Mapping from IEEE 11073-10201 DIM to FHIR

Within the context of the ISO/IEEE 11073 Point-of-care medical device communication standards, ISO/IEEE 11073-10201 provides an abstract, object-oriented domain information model (DIM) that defines a hierarchical model for structuring medical device data as well as events and services.

DIM Object Classes

Most object classes in ISO/IEEE 11073 DIM can be mapped to FHIR resources as outlined in the following table.

DIM Object Class FHIR Resource
SimpleMDS
HydraMDS
CompositeSingleBedMDS
CompositeMultipleBedMDS
Device (according to the MDS Device profile) and
Location (if needed)
VMD Device (according to the VMD Device profile)
Channel Device (according to the Channel Device profile)
Numeric DeviceMetric (according to the Numeric DeviceMetric profile) and
Observation (according to the Numeric Observation profile or Compound Numeric Observation profile)
Enumeration DeviceMetric (according to the Enumeration DeviceMetric profile) and
Observation (according to the Enumeration Observation profile)
TimeSampleArray
RealTimeSampleArray
DistributionSampleArray
DeviceMetric (according to the Sample Array DeviceMetric profile) and
Observation (according to the Sample Array Observation profile)
Alert
AlertStatus
AlertMonitor
to be completed
PatientDemographics Patient

DIM Object Attributes

Please refer to the Mappings tab of each profile page for mapping ISO/IEEE 11073 DIM object attributes to FHIR resource elements.

Mapping Details

Measurement Status

Observed values in ISO/IEEE 11073 DIM include a bit field that indicates measurement status. FHIR Observations do not have a single element for this purpose. Instead there is security metadata, dataAbsentReason for missing values, and interpretation to report significance of a result.
Measurement status information is mapped to Resource.meta.security, Observation.dataAbsentReason or Observation.component.dataAbsentReason, and Observation.interpretation or Observation.component.interpretation elements. The interpretation value set binding is extended to add relevant codes from the Measurement status codes defined in this implementation guide.

MeasurementStatus Bit meta.security dataAbsentReason interpretation
invalid (0) UNRELIABLE error  
questionable (1) UNCERTREL   questionable
not-available (2)   not-performed  
calibration-ongoing (3) UNCERTREL   calibration-ongoing
test-data (4) HTEST    
demo-data (5) HTEST    
validated-data (8) HRELIABLE   validated-data
early-indication (9)     early-indication
msmt-ongoing (10)   temp-unknown msmt-ongoing
msmt-state-in-alarm (14)     in-alarm
msmt-state-al-inhibited (15)     alarm-inhibited

Note that dataAbsentReason and interpretation are mutually exclusive: dataAbsentReason shall only be present if there is no observation value, whereas interpretation adds relevant information about an existing observation value.