DoF Semantic Content Mapping
Overview
A key element to the DoF work is to ensure consistent and coherent mapping of device semantics from the ISO/IEEE 11073 domain information model (DIM) and related terminology to HL7 constructs, both V2 - which is in wide production system use today for device information reporting - and FHIR. The referenced materials and discussion topics below capture the details and challenges around achieving high quality mappings and conversions where the integrity of the abstract semantics are properly managed and maintained.
The ISO/IEEE 11073 standards for medical and personal health devices form the foundation for device information exchange. They include:
- ISO/IEEE 11073-10101 Nomenclature / terminology specialized for device semantics
- ISO/IEEE 11073-1010x Additional terminology support for specialized areas, such as Annotated ECG (aECG)
- ISO/IEEE 11073-10201 Domain Information Model (DIM) which provides an object model specialized for device-sourced information
- ISO/IEEE 11073-20601 Personal Health Device (PHD) optimized specifications, including a "simplified" version of the DIM specifically for the typicallly less complex PHDs
- ISO/IEEE 11073-104xx PHD specializations that include models based on -20601 (which is based on -10201)
There is a distinction made between two broad classes of devices:
- PoCD = Point-of-Care Devices which are primarily used in acute care settings and tend to have more complex capabilities (e.g., physiological monitors, infusion pumps, ventilators, anesthesia machines, etc.)
- PHD = Personal Health Devices which are primarily used in home / non-acute care settings and tend to be simpler (e.g., insulin pumps, weighing scale, 3-lead ECG, etc.)
Both classes of devices, though, derive from the same foundational semantic standards, namely IEEE 11073 DIM and terminology. This greatly simplifies the "mapping" effort.
Depending on the use context, though, and infrastructure architecture, device data may be exchanged using pure 11073 protocols and content or the 11073 content expressed in HL7 Version 2 messages or FHIR components.
For example, most acute care device data today is initially communicated from the device using company proprietary protocols - and semantics. IHE Patient Care Device (PCD) profile specifications, though map this 11073 semantic content onto HL7 Version 2 messages (primarily ORU message variations). The Continua PHD guidelines also adopt this IHE PCD messaging to send semantically consistent PHD data from a Personal Health Gateway (PHG) across a WAN to some other enterprise system.
Thus, the DoF mapping challenge is to leverage the 11073 semantic foundation, factor in the mappings to HL7 v2, and apply that to FHIR constructs.
It should be recognized that whereas PHD devices are primarily concerned with directly mapping from 11073 to FHIR, both and especially PoCD data streams may need an interim V2 mapping. Thus the materials provided below tend to have DIM to V2 to FHIR mapping sections. Keeping this match-up will help ensure consistency between the three.
Note: The deliverables of this DoF mapping initiative include ...
- Resource mapping sections in the FHIR specification
- Implementation Guide content
- White paper content - especially where there are unresolved topics, due to a lack of consensus or lack of time / resources to complete
- [NOTE: Consider adding a DIM overview section here ...that has content w/ graphics or at least links to where additional information can be found on-line; this may best be handled in the DEV WG wiki home page though.]
Mapping Discussion Materials
PoCD Mapping Documents
PHD Mapping and PHD Mapping Documents
FHIR Device resources (Brian Reinhold)
The latest version of the FHIR specification offers three resources that are directly related to devices; Device, DeviceComponent, and DeviceMetric. I would like to point out semantic shortcomings of these resources which means that most health care devices cannot be properly represented. Almost all health care devices, PHD and PoCD have a manufacturer name, model number, and serial number. Those are probably even required by law but that I can't say. Unfortunately, the serial number is part of the production specification which the powers that be decided to place in the DeviceComponent. Thus a PHD device and a PoCD device which may have N VMDs will need to have a Device and DeviceComponent to describe the 'MDS', and the PoCD will need additional DeviceComponents for the VMDs. That alone does not make sense but more problematic is that these VMDs may come from another company and thus they will each have a manufacturer name and model number as well as serial number. Where does one put the manufacturer name and model number?
The only solution I see is to add the production specification to the Device AND add the manufacturer name and model number fields to the DeviceComponent. This will allow PHD devices to be represented entirely by the static Device resource with no need to use the DeviceComponent and deal with the required 'time of last update' field of the DeviceComponent. For PHD devices, the 'time of last update' is not available by protocol and we do not expect end users (patients) to have to enter it. In fact, in the remote patient monitoring world the best we can hope from the users is that they know how to step on a scale, take their temperature, and some may even be able to take a BP measurement. Everything else needs to be handled automatically by protocol.
For simplicity, I would prefer the production specification to be entered as fields like the manufacturer name and model number. There are 7 production spec fields as I recall and this would definitely cover the 80/20. There would be no need to enter all the coding information; the quantity would be known from the field. I would suggest:
manufacturerName modelNumber serialNumber firmwareVersion hardwareVersion softwareVersion partNumber protocolVersion globalMedicalDeviceNomenclature unspecified regulationCertifications 0..* A vocabulary set for the different regulatory organizations FDA, PCHA, etc.
This proposal was not accepted. A proposed solution where the DeviceComponent would be eliminated and replaced by just the Device (issue 11006 [1] ) with parent and child reference pointers, a Production Spec, an optional time of last update, was also rejected. Thus in order to consistently and efficiently map a static PHD sensor PCHA has chosen to use an extension labeled 'Device Properties'. It consists of a code describing the property through a valueCodeableConcept where the valueCodeableConcept itself is extended to contain the device property value. This allows PCHA to express all its needed fields; the production spec entries, the Reg-Cert-Data-List entries, and the static time properties. MDC nomenclature codes for all of these properties have already been established for IHE PCD-01 messaging and they are re-used in these extensions in the valueCodeableConcept describing the device property.
Given that the PHD is static, this allows uploaders to upload the resource only once to a given server which saves bandwidth and cost to remote users. PCHA uploaders will spend most of their time just uploading Observation resources.
Sensor Device Mapping
A PHD sensor has the possibility of exposing the following static properties
The system-id (required)
The system-model (required)
The manufacturer name
The model number
The System-Type-Spec-List (required)
The Production Specification (optional 20601, PCHA requires two fields; serial number and firmware revision)
The Reg-Cert-Data-List (optional 20601 required by PCHA)
The MdsTimeInfo (required for sensors using time stamps in measurements; not all fields are static)
time capabilities
time synchronization
time sync accuracy
absolute or base offset time resolution
relative time resolution
hi-res relative time resolution
Only the system-id, system-model, and system-type-spec-list have homes in the Device resource. All the remaining fields are mapped to PCHA extensions.
A PHG is also considered to have all the properties of the sensor device except for the System-Type-Spec-List. The PHG properties are mapped to a separate Device resource with the major difference that the Device.type field is an MDC code indicating that it is a PHG. The Device.type field in the Sensor Device resource is the device specialization from the System-Type-Spec-List. However, only the system-id and time synchronization properties are required to be reported.
Mapping Measurements
All of the measurement types reported in 20601 metric instances had an analog in the FHIR Observation resource except the ASN.1 BITs field.
Final Agreed upon ASN1 Mapping
FHIR does not have a data type capable of representing a BITs measurement. So an ASN1 coding vocabulary was proposed with various ideas. All of the proposed ideas were based upon the principal that the code could be generated from data received via protocol but in the end the community settled upon the system described in the following:
The mapping has been structured by creating a code based upon the 32-bit nomenclature code of Type attribute of the Metric Object Instance that has an ASN.1 BITs measurement followed by the bit position of the ASN.1 BIT. This code becomes the Observation.component.code value. There will be a component for each bit setting that is mapped. The value of the bit setting is one of 'y' or 'n' from the binary V2 vocabulary set and would be mapped to the corresponding Observation.component.valueCodeableConcept element. There would be no value[x] element in the resource. In some sense, the mapping is similar to the mapping of compound measurements where there is now a Observation.component element for each bit to be mapped instead of each sub-component of the compound.
For example, the pulsatile quality of a pulse oximeter is defined as follows:
pulse-qual-nominal(0) Quality of the detected pulse is nominal, in that there are no recognized abnormalities in the detected pulse pulse-qual-marginal(1) Perfusion or quality of the detected pulse is marginal. pulse-qual-minimal(2) Perfusion or quality of the detected pulse is minimal. pulse-qual-unacceptable(3) Perfusion or quality of the detected pulse is unacceptable
The type of this measurement is defined as MDC_PULS_OXIM_PULS_CHAR whose value is 150584. The vocabulary for this set of ASN.1 BITs would be
150584.0 pulse-qual-nominal 150584.1 pulse-qual-marginal 150584.2 pulse-qual-minimal 150584.3 pulse-qual-unacceptable
The example is a poor example because the real strength of the ASN.1 BITs measurement is for the case when more than one bit can be set. In this usage by the Pulse Oximeter specialization that is not the case; only one bit can be set at a time. The specialization SHOULD have used MDC codes for this measurement instead of BIT settings. Nevertheless, one can see how the vocabulary is to work. A measurement with pulse-qual-minimal would then be mapped to the Observation as follows:
Observation.code.coding.code="150584" Observation.component.code.coding.code="150584.2" Observation.component.valueCodeableConcept.code.coding.code="y"
PCHA PHD Mapping of 11073 20601 Metric Object Instances to FHIR Observation resources
In general one can state that every 20601 Measurement is an instance of a Metric Object
There are three Metric Object instance types
• Numeric
• Real Time Sample Array (RTSA)
o The RTSA metric is conceptually the same as a Numeric metric and the data being transferred by a single RTSA metric instance could be done in several Numeric instances
BUT it would be inefficient. The RTSA is an efficient way to transfer a sequence of periodic numeric metrics.
• Enumeration
with a total of 12 possible observational measurement value attributes
• Basic Nu Observed Value • Simple Nu Observed Value • Nu Observed Value • Compound Basic Nu Observed Value • Compound Simple Nu Observed Value • Compound Nu Observed Value • Simple Sa Observed Value • Simple OID Enum Observed Value • Basic ASN1 BITs Enum Observed Value • Simple ASN1 BITs Enum Observed Value • String Enum Observed Value • Enum Observed Value
Every 11073 20601 metric instance representing a measurement will contain one and only one of the above twelve attributes. All the remaining attributes in the metric instance are just to help describe the measurement value OR to help the 20601 protocol in the agent to manager exchange. The latter are not of interest to the measurement itself.
Measurement value
The 12 measurement value attributes (italics) are mapped an Observation resource value[x] element (italics) as follows:
• Numeric Metric Objects
o Simple numerics
Basic Nu Observed Value maps to valueQuantity
Simple Nu Observed Value maps to valueQuantity
Nu Observed Value maps to valueQuantity
o Compound Numerics
Compound Basic Nu Observed Value[n] maps to component[n].valueQuantity
Compound Simple Nu Observed Value[n] maps to component[n].valueQuantity
Compound Nu Observed Value[n] maps to component[n].valueQuantity
• RTSA Metric Objects
o Simple Sa Observed Value maps to valueSampledData
• Enumeration Metric Objects
o Simple Enums
Simple OID Enum Observed Value with Type.partition maps to valueCodeableConcept
• If Enum Partition Attribute exists it replaces Type.partition in valueCodeableConcept
Basic ASN1 BITs Enum Observed Value maps to a component.code element for each setting being mapped
• with component.valueCodeableConcept the bit setting
Simple ASN1 BITs Enum Observed Value maps to a component.code element for each setting being mapped
• with component.valueCodeableConcept the bit setting
String Enum Observed Value maps to valueString
o Complex Enum
Enum Observed Value of type
• OID maps as Simple OID Enum above
• Simple ASN1 maps as Simple ASN1 Enum above (there is no 16-bit ANS1 Enum option in the Enum Observed Value attribute)
• String maps as String Enum above
A 20601 ObservationScan can be received that does NOT have one of the above measurement value attributes, such as Attribute Value Map and Unit Code updates. If such an ObservationScan is received, it is ignored as far as the mapping is concerned (but they are vital for the 20601 protocol!!)
Units
All Numeric Metrics have a Unit Code (may be dimensionless)
• Simple Numerics
o Unit Code maps to valueQuantity.code
or
o Nu Observed Value.unit-code maps to valueQuantity.code
• Compound Numerics
o Unit Code maps to all component[n].valueQuantity.code
or
o Compound Nu Observed Value[n].unit-code maps to component[n].valueQuantity.code
o There is NO value[x] entry
All RTSA Metrics have a Unit Code (may be dimensionless)
• Unit Code maps to valueSampledData.origin.code
Enumeration Metrics typically do not have a unit code (though they could in 20601). In any case FHIR does not support unit codes for anything but Quantities.
Measurement Type
All Metric Objects have attributes which state what the measurement is. Often the Type attribute alone does the job but not always. However, once the type code is obtained, mapping it to the FHIR Observation is easy.
Metric Instances with the following measurement value attributes
• Basic Nu Observed Value • Simple Nu Observed Value • Compound Basic Nu Observed Value • Compound Simple Nu Observed Value • Compound Nu Observed Value • Simple Sa Observed Value • OID Enum Observed Value • Basic ASN1 Enum Observed Value • Simple ASN1 Enum Observed Value • String Enum Observed Value
map the type as follows:
• Type attribute maps to code
o If metric-id exists, its value replaces Type.code in code
o If metric partition id exists, its value replaces Type.partition in code
Metric Instances with the following measurement value attributes
• Nu Observed Value • Enum Observed Value
map the type as follows:
• Nu/Enum Observed Value.metric-id replaces Type.code in code
o If metric partition id exists, its value replaces Type.partition in code
Compound sub element type mapping
Compounds have a primary type describing the overall measurement but they also need a sub-type to describe each sub-value.
Metric Instances with the following measurement value attributes
• Compound Basic Nu Observed Value • Compound Simple Nu Observed Value
map the component type as follows:
• metric id list[n] and Type.partition map to component[n].code • If metric partition id exists, its value replaces Type.partition in component[n].code
Metric Instances with the following measurement value attribute
• Compound Nu Observed Value
map the component type as follows:
• Compound Nu Observed Value[n] and Type.partition map to component[n].code • If metric partition id value replaces Type.partition in component[n].code
Time Stamps
All Metric Object instances contain a maximum of one time stamp (may contain none) which is one of
• Absolute Time Stamp • Base Offset Time Stamp • Relative Time Stamp • Hi Resolution Relative Time Stamp • Time of reception by PHG if no time stamp
If there is no duration attribute
• The time stamp maps to effectiveDateTime according to the coincident time stamp corrections (if any)
Summary Table:
The following table shows an overview of the metric object instance mapping to Observation elements based upon the observational value attributes. Every 11073 20601 metric instance will contain one and only one of 12 possible measurement value attributes. The PCHA mapping is done without regard to value of the attribute or the specialization of the device. It is based solely upon the attribute type. This approach allows the mapping to be used for any future specialization.
| Measurement Value Attribute | Observation Element Value | Type attributes | Observation Element Type | |
| 1 | Basic Nu Observed Value Unit Code |
valueQuantity valueQuantity.code |
Type, Metric-id, Metric-Id-Partition | code |
| 2 | Simple Nu Observed Value Unit Code |
valueQuantity valueQuantity.code |
Type, Metric-id, Metric-Id-Partition | code |
| 3 | Nu Observed Value Nu Observed Value.unit-code |
valueQuantity valueQuantity.code |
Type, Metric-id, Metric-Id-Partition | code |
| 4 | Compound Basic Nu Observed Value[n].value Unit Code |
component[n].valueQuantity component[n].valueQuantity.code value[x] absent |
Type Metric Id List[n], Metric-Id-Partition |
code component[n].code |
| 5 | Compound Simple Nu Observed Value[n].value Unit Code |
component[n].valueQuantity component[n].valueQuantity.code value[x] absent |
Type Metric Id List[n], Metric-Id-Partition |
code component[n].code |
| 6 | Compound Nu Observed Value[n].value Compound Nu Observed Value[n].unit-code |
component[n].valueQuantity component[n].valueQuantity.code value[x] absent |
Type Compound Nu Observed Value[n].metric, Metric-Id-Partition |
code component[n].code |
| 7 | Simple Sa Observed Value Unit Code |
valueSampledData valueSampledData.origin.code |
Type, Metric-id, Metric-Id-Partition | code |
| 8 | Simple OID Enum Observed Value | valueCodeableConcept | Type, Metric-id, Metric-Id-Partition | code |
| 9 | Simple ASN1 BITs Enum Observed Value | component.code component.valueCodeableConcept |
Type, Metric-id, Metric-Id-Partition | code |
| 10 | Basic ASN1 BITs Enum Observed Value | component.code component.valueCodeableConcept |
Type, Metric-id, Metric-Id-Partition | code |
| 11 | Simple String Enum Observed Value | valueString | Type, Metric-id, Metric-Id-Partition | code |
| 12 | Enum Observed Value | one of OID, ASN1, or String enum mappings | Type, Enum Observed Value.metric-id, Metric-Id-Partition | code |
Understanding the above table
This table only shows the basic mapping elements; the measurement value and possible units and the measurement type (the code that indicates what the measurement is). As stated there are 12 different measurement value attributes in 11073 20601. If an Observation Scan is received from the 20601 sensor that has one of these attributes, it is a measurement. When a measurement value listed in the column 'Measurement Value Attribute' is received, it is mapped to the Observation resource element in the column 'Observation element Value'. To find the type of this measurement value, one needs to examine the attributes in the metric instance listed in the column 'Type attributes'. Once the type is found, it is mapped to the Observation resource element given in the column 'Observation element Type'.
Example: An Observation Scan is received containing a Simple Nu Observed Value. This value is shown in row 2. Under the column 'Observation element Value' one sees valueQuantity. That entry indicates that the Simple-Nu-Observed-Value.value is mapped to the Observation.valueQuantity.value element. Of course a proper conversion has to be done. The Simple-Nu-Observed-Value is an ASN1 primitive consisting of an Mder FLOAT. The Mder FLOAT needs to be converted into the decimal number indicated by the precision before it is placed into the valueQuantity.value primitive. One will also note that under the Simple-Nu-Observed-Value one has the Unit Code attribute. The reason the two attributes are listed together is that FHIR does not separate the Units from the value like 20601. In FHIR, Units exist only in the context of a Quantity. Thus the two entries.
To find the type of the Simple-Nu-Observed-Value one needs to look at the attributes in the associated metric instance listed in the column 'Type attributes'. In the Simple-Nu-Observed-Value case one sees Type, metric-id, and metric-partition-id. What this means is one first looks at the Type and gets the partition and term codes. If there is also a metric-id attribute, one replaces the term code from the Type attribute with the term code of the metric-id attribute. Finally, if there is a metric-id-partition attribute, one replaces the partition from the Type attribute with the partition from the metric-id-partition attribute. The 32 bit code is computed from the final partition and term code and placed in the Observation element listed in the 'Observation element Type' column.
Yes, finding the measurement type in 11073 20601 metric instances is ugly. The list of attributes in the column 'Type Attributes' does attempt to detail the algorithm a FHIR encoder must follow to get the type, all it indicates is that one needs to examine all these attributes in order to determine the type. Fortunately, in most of the basic specializations implementations, only the Type attribute is present if the measurement is not a compound, and if it is a compound, one ALWAYS has a Type attribute describing the overall type and a metric-id-list describing the type of each sub-component of the compound. For example, the blood pressure has an overall type stating this is a non-invasive blood pressure. Then it has three entries in the metric-id-list stating the sub component types of systolic, diastolic, and mean.
Differences between PHD and PoCD mappings
First we are going to take a look at likely requirements that can lead to differences.
1. PHDs are low cost consumer devices and tend to have unreliable clocks. Many PHDs require the user to set the time through a UI. Some PHDs reset to factory defaults on battery changes and the user may forget to set the time. To solve these issues the PHG is responsible for correcting the PHD times. In addition, since PHGs can upload the data to any location in the world, PHGs must also map provide the offset to UTC. To perform these tasks the PHG must be able to synchronize to UTC and it must be able to obtain the PHDs sense of current time. The coincident time stamp Observation is a special FHIR resource that contains the PHDs sense of current time at the current time of the PHG. From this information, any corrections to measurement time stamps can be done. PoCDs are unlikely to need time correction or a coincident time stamp.
2. Again since PHDs are low cost, it becomes more important to get a measure of the 'quality' of the device. Thus it has been the practice in PCHA PCD-01 messages that a significant number of device properties are reported that do not seem to be reported by PoCDs. Two of these items is the regulation-certification and time properties information which has been required in PCHA uploads.
Mapping Challenges / Topics
The "devil is in the details" definitely applies to any detailed mapping and conversions between these systems, and that is definitely the case with device informatics and achieving semantic consistency and coherence between the various implementation architectures and technologies. The following issues were of particular interest during the DoF's discussions:
- 1. <list topics here with subordinate bullets OR link to wiki pages>
NOTE: Much of the content in this section and related wiki pages may be captured in the DoF Implementation Guide (IG) or white paper(s) for broader distribution to the community.
