Difference between revisions of "DoF Semantic Content Mapping"
| Line 109: | Line 109: | ||
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 attribute. It is based solely upon the attribute type. This approach allows the mapping to be used for any future specialization. | 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 attribute. It is based solely upon the attribute type. This approach allows the mapping to be used for any future specialization. | ||
| − | <table | + | <table padding="5" style="border:1px solid black;border-collapse:collapse;> |
<tr> | <tr> | ||
<td><b>Measurement Value Attribute</b></td> | <td><b>Measurement Value Attribute</b></td> | ||
Revision as of 23:37, 20 March 2017
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.]
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.
ASN.1 BIT mapping proposal: Vocabulary set.
FHIR and CDA templates have no good home for ASN.1 BITs fields. So the way I would propose to remedy this is to create a vocabulary which converts each bit setting into a code. In that manner one can use the CodeableConcept elements of FHIR and the code element of CDA templates to represent these values. To generate the codes the following in proposed:
For Enumeration metric measurements create the code using the enumeration metric Type attribute code, Mder bit position, and the bit setting:
type-attribute-value.mder-bit-position.value
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.0 pulse-qual-not-nominal 150584.0.1 pulse-qual-nominal 150584.0.2 pulse-qual-nominal-unknown 150584.1.0 pulse-qual-not-marginal 150584.1.1 pulse-qual-marginal 150584.1.2 pulse-qual-marginal-unknown 150584.2.0 pulse-qual-not-minimal 150584.2.1 pulse-qual-minimal 150584.2.2 pulse-qual-minimal-unknown 150584.3.0 pulse-qual-not-unacceptable 150584.3.1 pulse-qual-unacceptable 150584.3.2 pulse-qual-unacceptable-unknown
where the 'unknown'case has been added (2 is NOT a possible bit setting!). The 'unknown' case indicates that the device does not support the setting of that particular bit therefore its state is unknown. This state has been included because 20601 is working on including a 'mask' which indicates which of the options of the possible a sensor may support.
If the gateway endpoint is only required to report bits that are set, this coding system allows a gateway endpoint to generate the code from protocol without the aid of a lookup table. It also allows a gateway written today to generate the codes for ASN.1 BITS defined in future specializations. The recipient, however, will need to have a coding table. It is also necessary to require that a gateway 'know' the specialization in order to send optional settings (the cleared state or unknown state).
There are a few catches. There are some cases where the cleared bit is important. These are rare and I hope in the future generation of IEEE specialization standards that ASN.1 BITs are only used if it is the set case that is important. Right now the Independent Living specialization defines several ASN.1 BITs measurements that contain only one bit. These binary cases cover items like 'patient in room', 'patient not in room' or 'door opened', 'door closed'. In this case both settings are important to report. I wish OIDs had been used for these cases instead of BITs. The other case is the regulation status of a device. For some reason the unregulated state was defined as the 'set' state. I have no idea why. It would have made much more sense to define the regulated state as set (reporting that when it occurs and if it doesn't assume unregulated). However, to report that a device is regulated, one has to report the cleared state. Its a confusing double negative.
A rarer situation is ASN.1 BITs that are not enumeration metric attributes like the regulation status. In these cases the type-attribute-value is replaced by the attribute-d or attribute-component-value. The attribute-id is obtainable on the wire (such as the PowerStatus) but the attribute-component-values are not. But the latter are few (eg MdsTimeInfo time capability and RegCertDataList regulation status) and are not likely to increase in number.
The vocabulary will only contain define bits. For example, in the pulsatile quality only bits 0-3 are defined. Bits 4-15 are not. Since a gateway is only required to report set bits and must know the specialization in order to report the optional bits, they will not generate undefined codes like 150584.11.0.
Final Agreed upon ASN1 Mapping The mapping has been structured using 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 mapped. The value of the bit setting is one of 'y' or 'n' from the binary vocabulary and would be mapped to the corresponding Observation.component.valueCodeableConcept element. The table above is now:
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 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
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 attribute. 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 |
| Basic Nu Observed Value | valueQuantity |
| Unit Code | valueQuantity.code |
| Simple Nu Observed Value | valueQuantity |
| Unit Code | valueQuantity.code |
| Nu Observed Value | valueQuantity |
| Nu Observed Value.unit-code | valueQuantity.code |
Mapping Discussion Materials
PoCD Mapping Documents
PHD Mapping Documents
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.
