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

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.