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 either scalars or vectors. Enumeration Metric objects are used to describe measurements that are represented by a finite set of items. RTSA Metric objects are used to represent a sequence of periodic numeric scalar measurements. An RTSA could be expressed as a sequence of scalar numeric metrics but that would be inefficient.
The static attributes of the MDS object are mapped to a Device resource and the 'measurement' attributes of the Metric objects are mapped to Observation resources. The description 'measurement' is used as there are some attributes, such as the attribute value map, that only aid in the formatting of the APDU packets and have nothing to do with the measurement values themselves. Those attributes are not of interest in the 20601 to FHIR mapping.
The Metric 'Model'
The 20601 metric model describes a measurement using a value, an optional unit, a type (to indicate what the measurement is), an optional time stamp, and an optional set of extra descriptions.This information is present in the Metric Object attributes.
The Metric Model Values
The Metric Object handles six types of measurement values:
- scalar values: Scalars are the familiar simple quantities such as temperature and glucose concentration. Scalars are mapped to Observation.valueQuantity elements.
- Compound or vector values: Compound quantities are measurements that need more than one value to describe, such as the x, y and z components of an acceleration or the systolic, diastolic, and MAP components of a blood pressure. Each vector sub-value is mapped to an Observation.component.valueQuantity element.
- coded values: Coded values are used when the measurements are described by a finite set of options such as the meal context of a glucose measurement. The options might be one of breakfast, lunch, dinner, snack, fasting, etc. A code is used for each option. Coded values are mapped to Observation.valueCodeableConcept elements.
- BITs values: BITs values are measurements where each bit in a 16- or 32-bit 'integer' represents an event or state. An event would be something like 'marginal signal' in a pulse oximeter. An event is only of interest when it occurs and the bit is set when the event occurs. A state, on the other hand, would be something like 'averaging-on' or 'averaging-off'. Both settings of a state are of interest. BITs values are used when multiple events and/or states can occur simultaneously. The mapping of BITs values is complicated as FHIR (and HL7 in general) has no support for this type of measurement. Instead Continua has developed a code system where each bit position is mapped to a code. Each code is mapped to an Observation.component.code element and the bit setting is mapped to a binary Observation.component.valueCodeableConcept element.
- human readable strings: String values are just that; a line of arbitrary text. These rarely used values cannot be generically processed by a machine but are only meant for display. An example of such a measurement would be the program name of a workout on a piece of cardio equipment at a gym. String values are mapped to Observation.valueString elements.
- sequences of periodic scalars: Waveform traces are a sequence of periodic scalars that may have a high frequency such as 1000 samples per second. An example of such a measurement would be a digitized ECG trace. Waveforms are mapped to Observation.valueSampledData elements.
Only scalar and vector values may have a unit. In earlier versions of 20601 it was possible to have a Unit-Code attribute in an Enumration Metric Object. This inconsistency has been corrected in the latest versions of the 20601 standard. In addition, there is no specialization that uses a unit code in an enumeration measurement.
In 20601, units are expressed as 11073-10101 nomenclature codes. In FHIR, these unit nomneclature codes are mapped to UCUM codes.
The Metric Model Type
All Metric objects contain one or more attributes that specify a 11073-10101 nomenclature code expressing what the measurement is. In most cases this code is given by the Type attribute. In more complex cases the Type attribute alone is not sufficient; the decoder must look for the existence of several addtional but optional attributes. If these additional attributes, such as the Metric-Id and Metric-Id-Partition among others, are present, their values, along with the Type attribute are needed to determine the final code. In the end, the decoder gets a single code specifying what the 'overall' measurement is. For example, a body temperature, body mass, medication dosage, or non-invasive blood pressure. The overall code is mapped to the Observation.code element. The expression 'overall' is used because in compound cases, the decoder must look at additional metric attributes to obtain the sub-types of the measurement, for example the systolic, diastolic, and MAP values of the non-invasive blood pressure. These sub-type codes are mapped to Observation.component.code elements representing each sub-type.
The Metric Model TimeStamp
Time stamps are more complicated because PHDs have different types of time clocks, may include a duration, may be out of sync when using wall-clock times, and may send no time stamp at all. The PHG is responsbile for placing the measurements on a UTC synchronized time line with local offset. That includes using the time of reception as the time stamp if the PHD sends no time stamp, mapping simple relative time 'ticks' to UTC and local offset, and correcting the wall clock time stamps reported by PHDs when they are wrong. 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 Coincident Time Stamp Observation, if needed, is placed in the Observation.related element.
The Metric Model Descriptions
The Metric Object contains a set of optional attributes that provide additional information about the measurement. The Supplemental-Types and Accuracy are examples of such attributes. When these attributes occur, they are mapped to component elements in the FHIR Observation resource. The component.code is given by the 11073-10101 nomenclature code of the respective attribute. The component.value[x] is given by the attribute value(s). In the case of the Accuracy, the value[x] is a valueQuantity, and in the case of the Supplemental-Types, the value[x] is a valueCodeableConcept. Since the Supplemental-Types is actually a list of codes, one may need several component elements.
The examples below show the most common basic measurement types where the PHD provides one of the wall-clock type time stamps.
Scalar Numeric Metric Object Mapping Example
The simplest example of a mapping of a Numeric Metric object to a FHIR Observation resource is as follows
| IEEE Attribute | Meaning | Observation element |
|---|---|---|
| Type | Tells what the measurement is as a 11073 10101 code | .code |
| Absolute-Time-Stamp Base-Offset-Time-Stamp |
Gives the time of the measurement | .effectiveDateTime |
| Simple/Basic-Nu-Observed-Value | Gives the value of the measurement | .valueQuantity.value |
| Unit-Code | Gives the units of the measurement as a 11073 10101 code. Will need to be translated to the UCUM code system | .valueQuantity.code |
This mapping applies to several simple types of PHD measurements that are scalars, 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 scalar Numeric Metric measurements.
Scalar 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:
| IEEE Attribute | Meaning | Observation element | |
|---|---|---|---|
| Type | Tells what the 'overall' measurement is as a 11073 10101 code | .code | |
| Absolute-Time-Stamp Base-Offset-Time-Stamp |
Gives the time of the measurement | .effectiveDateTime | |
| Metric-Id-List.entryN | Gives the code of Nth component of the measurement | componentN.code | |
| Compound Simple/Basic-Nu-Observed-Value.valueN | Gives the Nth component of the measurement | componentN.valueQuantity.value | |
| Unit-Code | Gives the units of the measurement as a 11073 10101 code. Will need to be translated to the UCUM code system | .valueQuantity.code | componentN.valueQuantity.code |
This mapping applies to simple types of PHD measurements that are represented by vectors, for example, the blood pressure and the user feedback. The Type attribute indicates what the overall measurement is, and the Metric-Id-List attribute indicates what each component of the overall 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.
Outside of the blood pressure monitor, 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:
| IEEE Attribute | Meaning | Observation element |
|---|---|---|
| Type | Tells what the measurement is as a 11073 10101 code | .code |
| Absolute-Time-Stamp Base-Offset-Time-Stamp |
Gives the time of the measurement | .effectiveDateTime |
| Enum-Observed-Value-Simple-OID | Gives the value of the measurement as 11073 10101 code | .valueCodeableConcept |
This mapping applies to simple types of PHD measurements whose value is given by a finite list of codes, for example the pulsatile 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 typically used to report events, statuses, or conditions when more than one of these situations can happen at the same time. They are classed as either events or states. 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. Undefined bits are never reported (what bits are defined is given in the respective specialiation documents).
Since the earlier versions of the 20601 standard do not provide state/event information, the ASN.1 code set does. There is no way to determine if a given device supports a defined bit setting so one has to assume that all defined settings are supported. Since most BITs measurements are events, the lack of support information tends not to be a problem.
The simplest example of a mapping of an ASN1 BITs enumeration object to a FHIR Observation resource is as follows:
| IEEE Attribute | Meaning | Observation element |
|---|---|---|
| Type | Tells what the measurement is as a 11073 10101 code | .code |
| Absolute-Time-Stamp Base-Offset-Time-Stamp |
Gives the time of the measurement | .effectiveDateTime |
| ASN1 Code for BIT N | Gives the code of Nth BIT setting | componentM.code |
| Enum-Observed-Value-Simple/Basic-Bit-Str.BitN | Gives the Nth bit setting as binary yes/no | componentM.valueCodeableConcept (Y/N) |
M (the number of the component) is different from N (the bit-position) because cleared event bits do 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 attributes and Observation elements 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 (the endpoint that receives and decodes IEEE 20601 data) will, in general, need to look at other attributes, should they be sent, to get the final code to enter in the Observation.code element. The same goes for the unit code. The Unit-code attribute can be overridden if certain other attributes exist.
However, this complexity is of no concern to the consumer or reader of the FHIR resources, only to the PHD decoder and creator of the FHIR resources, such as the Continua PHG.