DIM to FHIR Mapping: Basics

There are two classes of 11073 20601 objects that are relevant for uploading; the Medical Device System (MDS) object and the Metric object. The remaining objects assist in the PHD to PHG exchange protocol and are not of interest downstream. The MDS object is used to describe the device features and properties. The Metric object is used to model measurements. A PHD contains a single MDS object and may contain many Metric objects, each one representing a single measurement. There are three sub-classes of Metric objects, Numeric, Real-Time-Sample-Array (RTSA), and Enumeration. Numeric Metric objects are used to describe all measurements that are numbers, such as glucose concentration, body mass, body temperature, pulse rate, etc. Enumeration Metric objects are used to describe measurements that are represented by a finite set of codes, such as a meal context (breakfast, fasting, snack, lunch, etc.) in a glucose meter. RTSA Metric objects are used to represent periodic numeric measurements such as a digitized ECG traces or pleth waves. Numeric Metric objects contain either an attribute representing a single numeric value such as a temperature or body mass or an attribute containing a compound numerical value such as the x, y, z components of an accelleration or the systolic, diastolic, and MAP components of a blood pressure.

In general, the MDS object is mapped to a DeviceComponent resource and Metric objects are mapped to Observation resources. Numeric attributes are mapped to valueQuantities, enumeration attributes are mapped to valueCodeableConcepts, and RTSA attributes are mapped to valueSampledDatas. All Metric objects contain a Type attribute which contains a code indicating what the measurement is, for example, a body temperature, body mass, medication dosage, etc. These are mapped to the Observation.code element. Time stamps are more complicated because PHDs have different types of time clocks, may include a duration, or may send no time stamp at all. Here the PHG has to do some extra work including using the time of reception as the time stamp if the PHD sends no time stamp. For auditing purposes a summary of this work by the PHG is reported in the so-called Coincident Time Stamp Observation resource. In the end, the PHG maps time stamps to the Observation.effectiveDateTime if the time stamp is a point in time such as a body temperature, or the Observation.effectivePeriod if the metric contains a Measure-Active-Period (duration) attribute such as a running session. A reference to the Coicident Time Stamp Observation, if needed, is placed in the Observation.related element.

The examples below show the most common basic measurement types where the PHD provides one of the wall-clock type time stamps.

Single Numeric Metric Object Mapping Example

The simplest example of a mapping of a Numeric Metric object to a FHIR Observation resource is as follows

This mapping applies to several simple types of PHD measurements that are single numbers, for example body temperature, body mass, body height, glucose concentration, among many others. This implementation guide specifies a structure definition profile that applies to all single-number Numeric Metric measurements.

Single numeric measurements are the most common type of PHD measurement.

Compound Numeric Metric Object Mapping Example

The simplest example of a mapping of a Compound Numeric Metric object whose value has N components to a FHIR Observation resource is as follows

This mapping applies to simple types of PHD measurements that are represented by multiple numbers, for example, the blood pressure and the user feedback. The Type attribute indicates what the general measurement is and the Metric-Id-List attribute indicates what each component of the general measurement is. In the blood pressure case, the Type states that this is a non-invasive blood pressure and the Metric-Id-List attribute identifies the systolic, diastolic, and MAP components. This implementation guide specifies a structure definition profile that applies to all compound Numeric Metric measurements.

Compound numeric measurements are relatively uncommon in PHDs.

Enumeration Coded Value Metric Object Mapping Example

The simplest example of a mapping of Enumeration Metric object where the enumeration is a code to a FHIR Observation resource is as follows:

This mapping applies to simple types of PHD measurements whose value is given by a finite list of codes, for example the pulseatile characteristics measurement of a pulse oximeter. In this case there are three codes defined that can be reported, trigger on a beat, trigger on a maximum inrush, and no pulsatile event occurred. The latter is only reported by the device in special conditions and is usually not reported.

Enumeration BITs Value Metric Object Mapping Example

The ASN.1 BITs measurement is the most difficult measurement class to map because HL7 does not support this measurement type. An ASN.1 BITs value is a 16 or 32 bit integer where each bit can mean something. The bit is either set (value = 1) or cleared (value = 0). This type of measurement is typcially used to report events, statuses, or conditions when more than one of these situations can happen at the same time. To map this measurement to HL7 the BITs integer needs to be converted to codes. Continua has created a code system for this purpose allowing one to map a BITs value to a set of valueCodeableConcepts. The code system has a code for each possible setting, so a 16/32-bit ASN.1 BITs value can result in up to 16/32 codes. Since a BITs value can contain multiple settings, each setting is mapped to an Observation.component.

In the latest version of 11073 20601, two sets of support attributes for an ASN1 BITs measurements have been added. The Capability-Mask-Simple/Basic attribute indicates whether a given bit is supported (set) or not (cleared). The State-Flag-Simple/Basic attribute indicates whether a given bit is an event (cleared) or state (set). Unsupported bits do not need to be reported, and cleared event bits do not need to be reported. Both set and cleared state bits need to be reported.

The simplest example of a mapping of an ASN1 BITs enumeration object to a FHIR Observation resource is as follows:

M is different from N because some bits may not need to be reported. What is not shown in the table is that the ASN1 Code entered in the componentM.code element can be generated from data sent by the PHD. The ASN1 code is generated by converting the 32-bit code from the Type attribute to a string, concatenating a dot (.) followed by the Mder bit position N. A reader will still need to refer to the ASN1 code dictionary to interpret the meaning.

The Devil is in the Details

Unfortunately the Metric object to Observation resource mapping is not always a simple one-to-one relation between 11073 20601 attribute and Observation element as shown in the tables above. For example, the code that ends up in the Observation.code element does not always come from the Type attribute. The PHD decoder will, in general, need to look at other attributes, should they be sent, to get the final code to enter into the Observation.code element. The same goes for the unit code. The Unit-code attribute can be overriden if certain other attributes exist.

However, this complexity is of no concern to the consumer of the FHIR resources, only to the PHD decoder and creator of the FHIR resources.

There are also other attributes that may be sent that further qualify the measurement. A good example of such an attribute is the Supplemental-Types. In a pulse oximeter, this attribute is used to indicate the measurement technique; short average value, longer average value, or stable average value. These additional attributes are only used in a few specializations, but when they are, they are mapped to an Observation.component element. These details are shown in the section describing the profiles.