DoF Semantic Content Mapping

(Return to DoF home page)

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

OpenSDC - HL7 V2 to FHIR Conversion white paper (Schlichting/Draeger; distributed 2016.07.15)

OpenSDC - HL7 V2 to FHIR Conversion poster (pptx) (Schlichting/Draeger; distributed 2016.07.15)

Mapping between ISO/IEEE 11073-10201 Domain Information Model, IHE PCD DEC, and FHIR Resources

PHD Mapping and PHD Mapping Documents

FHIR Device resources (this comment by 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.

Final Agreed upon ASN1 Mapping

There was also the issue of mapping ASN1 BITs measurements to FHIR. 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.

PHD to PCD/V2 to FHIR Mapping Spreadsheet (Reinhold; distributed 2016.08.10)

PHD Attributes Spreadsheet (Reinhold; distributed 2016.07.14)

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.