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
Brian Reinhold - proposed "property" element for DeviceComponent
See page DoF DeviceComponent "property" proposal
- [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: Harmonization with PoCD (Brian Reinhold)
In recent discussions a harmonized PHD/PoCD mapping has been proposed. The proposed mapping would be such that the PHD mapping would be a subset of the PoCD which is really the goal. PHDs are always static and in the IEEE model, only have an MDS which perhaps, semantically, is more like a single VMD in PoCD. The intent of PoCD is to map both MDS and VMD as DeviceComponents; at least that is what I was informed. One could day that the DeviceComponent represents the medical sensor device and the Device represents the framework in which one or more sensor devices are held. PHDs are simple stand-alone consumer devices typically used in the home and thus will not have a 'Device' in the same context as a PoCD might. PHDs are just medical sensor devices. One could say a PoCD is a collection of PHDs. Given this notion, the following mapping has been proposed for PHDs:
1. PHDs are be mapped to the DeviceComponent resource; they would not make use of the Device resource. STU3 version 3.0.0 now has the lastSystemChange element as optional. In addition the DeviceComponent.identifer has [0..*] cardinality and OO has accepted adding the DeviceComponent to the list of resources that can be referenced by the Observatation.device element.
2. The DeviceComponent.productionSpecification element would be used to map both the System-Model, Production-Specification, and the Continua Version from the Reg-cert-Data-List attribute. This approach is much like the BTLE Device Information Service which contains ALL device-related information including the reg-cert-data-list data. It is also noted that the extensibility of the productionSpecification element makes it useful for future features such as, perhaps, the UDI if the UDC doesn't get its own entry. PCHA/11073 has already defined the following MDC codes for these fields
MDC_ID_PROD_SPEC_SERIAL MDC_ID_PROD_SPEC_PART MDC_ID_PROD_SPEC_HW MDC_ID_PROD_SPEC_SW MDC_ID_PROD_SPEC_FW MDC_ID_PROD_SPEC_PROTOCOL MDC_ID_PROD_SPEC_GMDN MDC_ID_PROD_SPEC_UNSPECIFIED MDC_ID_MODEL_MANUFACTURER MDC_ID_MODEL_NUMBER MDC_REG_CERT_DATA_CONTINUA_VERSION
which can be used in the productionSpecification CodeableConcept element to identify the value (which is a string). The System-Model attribute entries are the next-to-last two codes in the list. FHIR defines its own set of codes that match the current names in the 11073 Production-Specification attribute. However, it would probably be better to use the MDC codes since the MDC system is used in several places in PoCD and PHD mapping, and its not a bad idea to get HL7 familiar with the MDC coding and start to view it as they do LOINC.
3. PHDs also regularly encode static time information from the Mds-Time-Info attribute and certification, version, and regulation information from the Reg-Cert-Data-List attribute. PoCDs tend not to propagate this information though there is an interest in the possibility to do that. The current version of FHIR has no way to record this information without extensions. Thus there is a proposal to add an element that is extensible (like the productionSpecification) that can report these (and future) properties. A proposal for this element is discussed below.
4. Data from PHDs is typically propagated over the world wide web via a Gateway such as a mobile phone, PC, or a dedicated set-top box. Because PHDs are consumer devices and tend to be operated by patients and not health care professionals, the gateway is responsible for doing certain quality checks and corrections to the data (typically time) and providing an audit trail of these corrections. Information about the gateway is also transmitted in V2 PCD-01 messages. Following the sensor mapping, the information can be provided in a FHIR DeviceComponent. Previously, PHD was using the Device resource and was faced with the problem that there was no way to point to both the gateway and sensor resource from the Observation and no way to point to gateway Device resource from the sensor Device resource. This 'orphaned' the gateway Device resource. However, using the DeviceComponent, the parent element can now point to the gateway DeviceComponent
5. PHDs do not need a DeviceMetric resource. In most cases, all the info in the DeviceMetric that is obtainable by protocol is repeated and required in the Observation. With OO's acceptance of the addition of the DeviceComponent to the Observation.device allowances, the DeviceMetric can be skipped, saving bandwidth.
6. Multiple specializations and profiles. In PoCD these are effectively VMDs. In PHDs the same approach is used, where the individual specialization DeviceComponents would point to a master parent DeviceComponent resource containing the master type (such as HYDRA or basic specialization in the case of a Profile) where all the remaining device properties would be specified. The additional child DeviceComponent resources would not repeat that information in the parent but only contain the type. This approach would reduce overhead and be consistent with PoCD multiple VMD approach.
PHD Observation Mappings
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 DeviceComponent resource with the major difference that the DeviceComponent.type field is an MDC code indicating that it is a PHG. The DeviceComponent.type field in the Sensor DeviceComponent resource is the device specialization from the System-Type-Spec-List. However, in the PHG DeviceComponent 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 have 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. If the state were unsupported the Observation.component.value[x] would be absent and there would be an Observation.component.dataValueAbsentReason element instead. In all cases there would be no Observation.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 device and sensor annunciation status states of a pulse oximeter are defined as follows:
sensor-disconnected(0) Agent reports that the sensor is disconnected from the instrument. sensor-malfunction(1) Agent reports that the sensor is malfunctioning or faulting. sensor-displaced(2) Agent reports that the sensor is not properly attached or has been dislodged, and accurate measurement is, therefore, prevented. sensor-unsupported(3) An unsupported sensor is connected to the agent. sensor-off(4) Agent reports that sensor is not connected to the user. sensor-interference(5) Agent reports that there is interference due to ambient light or electrical phenomena. signal-searching(6) Signal analysis is currently in progress prior to measurement availability. signal-pulse-questionable(7) Agent determines that a questionable pulse is detected. signal-non-pulsatile(8) Agent detects a nonpulsatile signal. signal-erratic(9) Agent reports that the signal is erratic or is not plausible. signal-low-perfusion(10) Agent reports a consistently low perfusion condition exists. signal-poor(11) Agent reports a poor signal exists, possibly affecting accuracy. signal-inadequate(12) Agent reports that the incoming signal cannot be analyzed or is inadequate for producing a meaningful result. signal-processing-irregularity(13) Agent has determined that some irregularity has been detected while processing the signal. device-equipment-malfunction(14) A general device fault has occurred in the agent. device-extended-update(15) An extended display update is currently active.
The type of this measurement is defined as MDC_PULS_OXIM_DEV_STATUS whose value is 150604. The vocabulary for this set of ASN.1 BITs would be
150604.0 sensor-disconnected(0) Agent reports that the sensor is disconnected from the instrument. 150604.1 sensor-malfunction(1) Agent reports that the sensor is malfunctioning or faulting. 150604.2 sensor-displaced(2) Agent reports that the sensor is not properly attached or has been dislodged, and accurate measurement is, therefore, prevented. 150604.3 sensor-unsupported(3) An unsupported sensor is connected to the agent. 150604.4 sensor-off(4) Agent reports that sensor is not connected to the user. 150604.5 sensor-interference(5) Agent reports that there is interference due to ambient light or electrical phenomena. 150604.6 signal-searching(6) Signal analysis is currently in progress prior to measurement availability. 150604.7 signal-pulse-questionable(7) Agent determines that a questionable pulse is detected. 150604.8 signal-non-pulsatile(8) Agent detects a nonpulsatile signal. 150604.9 signal-erratic(9) Agent reports that the signal is erratic or is not plausible. 150604.10 signal-low-perfusion(10) Agent reports a consistently low perfusion condition exists. 150604.11 signal-poor(11) Agent reports a poor signal exists, possibly affecting accuracy. 150604.12 signal-inadequate(12) Agent reports that the incoming signal cannot be analyzed or is inadequate for producing a meaningful result. 150604.13 signal-processing-irregularity(13) Agent has determined that some irregularity has been detected while processing the signal. 150604.14 device-equipment-malfunction(14) A general device fault has occurred in the agent. 150604.15 device-extended-update(15) An extended display update is currently active.
A measurement with signal-low-perfusion and signal-poor would then be mapped to the Observation as follows:
Observation.code.coding.code="150604" Observation.component.code.coding.code="150604.10" Observation.component.valueCodeableConcept.code.coding.code="y" Observation.component.code.coding.code="150604.11" Observation.component.valueCodeableConcept.code.coding.code="y"
This same coding approach could be used for enumeration values. Though there are no cases in PHD where enumerations are mapped to FHIR, if there were one could create a code where the attribute id would provide the base and the enumeration value would be placed after the dots. For example, if attribute with id code 32499 had enumeration values 1,2,8,and 255 the mapped codes would be
32499.1 32499.2 32499.8 32499.255
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 the component.valueCodeableConcept the bit setting
Simple ASN1 BITs Enum Observed Value maps to a component.code element for each setting being mapped
• with the 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 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 PHD's sense of current time. The coincident time stamp Observation is a special FHIR resource that contains the PHD's 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 are the regulation-certification and time properties information which has been required in PCHA uploads.
3. PHDs and PHGs perform uploads typically from the home. PHGs may also be embedded low power devices. Consequently, data costs may be significant thus the size of the payload and security are important factors. As security tends to increase the bandwidth, reducing data size becomes more important. Data payload size and perhaps even security is unlikely an issue for PoCDs which often transmit data within the health care enterprise.
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.
