Mapping between ISO/IEEE 11073-10201 Domain Information Model, IHE PCD DEC, and FHIR Resources
- 1 Overview of ISO/IEEE 11073-10201 Domain Information Model (11073 DIM) for Point-of-care Devices
- 2 Use models for device observation reports and hierarchical versus flattened representation of device data
- 3 The 11073 DIM as applied in IHE Patient Care Device DEC (Device Enterprise Communications) observation reporting
- 4 Representation of 11073 DIM hierarchy in FHIR resources
- 5 Differences in Modeling Point-of-Care Device versus Personal Health Devices (ISO/IEEE 11073-20601 and -104xx)
- 6 Mapping particular entities between 11073 DIM, IHE PCD DEC (PCD-01) and FHIR resources
- 6.1 Example: Single-purpose Personal Health Device device model, representation in IHE PCD PCD-01 message, representation with FHIR resources
- 6.2 Example: Multiparameter patient monitor device model, representation with FHIR resources (by Stefan Karl)
Overview of ISO/IEEE 11073-10201 Domain Information Model (11073 DIM) for Point-of-care Devices
Point-of-care devices such as patient monitors, ventilators, anesthesia machines, infusion pumps can present a large number of clinical measurements and device-state variables (in the hundreds) often with complex logical organization, reflecting subsystems of the device and related measurements within each subsystem, in contrast to personal health devices which typically present a small number of measurements and accompanying data that usually have a close logical relationship with each other.
The DIM organizes the data and reflects the logical relationships in an object-oriented hierarchy: the whole device is represented by a Medical Device System (MDS) object, which logically encloses one or more Virtual Medical Devices (VMD). These may be reflections of physical subsystems such as plug-in modules in a patient monitor, or logical subsystems such as the gas-delivery and ventilator functions of an anesthesia machine, or indeed a VMD may model a software component such as a multivariable oxygenation calculator or a software component integrating multiple measurements from other VMDs into a clinical decision support (CDS) risk score.
The DIM also provides for Channels within a Virtual Medical Device, since a VMD may measure multiple instances of a particular kind of measurement, or need to disambiguate between, for example, multiple solution sources in a single infusion pump.
The basic unit of data delivery is the Metric object, generally representing a particular measurement or observation kind and associated with a specific code from the ISO/IEEE 11073-10101 Nomenclature, the most comprehensive list and ontology of logical entities, measurement categories, and particular measurements and state variables reported by devices. This standard grows constantly with the development of device technology. The 11073 committees work closely with the LOINC maintainers with the goal of having LOINC cross-mappings available for device-derived clinical observations, but the codes linked to the functioning of the devices themselves have different use models and are outside the scope of other nomenclature systems, so seem likely be the province of only 11073 nomenclature for some time to come.
It is important that the MDS, VMD, Channel, and Metric levels of the 11073 DIM all have their own sets of logically pertinent attributes and nomenclature. For example, when a whole device is powered by a battery, the battery state variables logically belong to the MDS, and so are reported there. As another example, the whole device (MDS), and subsystems like plugin modules (VMDs), may have their own specific identifiers such as manufacturer, model number, and FDA Unique Device Identifier (UDI), and version identifiers for, say, hardware, firmware, and various software components. These are all provided for in the DIM, and this is highly important "metadata" for recording provenance and traceability of data.
Use models for device observation reports and hierarchical versus flattened representation of device data
Device data "flattening" for simple charting
For charting in a clinical unit, the DIM hierarchy may not need to be visible on charting from an electronic medical record system. Since the device manufacturer or the middleware provider is in control of the modeling of a particular device, an expedient that is sometimes used is to ignore the specific instrumental sources and logical relationships by suppressing the identification of VMDs and Channels and treating all the measurements as, simply, coming from the MDS (a nonhierarchical, "flattened" representation). This provides the EMR with an undifferentiated bundle of measurements. This may meet the immediate charting purpose. In this application, this approach forces the EMR to any advantages in data presentation that it might derive from having any sort of logical grouping of the observations - all measurements are alike as far as the content of the device observation feed is concerned. When there are potentially hundreds of observations being reported, this presents the EMR and the people configuring the data feed for a particular clinical unit with a higher-order set of problems.
Traceability and data-mining of hierarchically organized data
But particularly when a healthcare delivery organization has a use model for data that contemplates warehousing observational data with full metadata allowing a measurement to be traceable to a particular instrumental source, the advantages of fuller metadata for analysis of adverse events, or for flagging devices for maintenance or testing, or a myriad for other more complex uses of big data, are obvious
The 11073 DIM as applied in IHE Patient Care Device DEC (Device Enterprise Communications) observation reporting
The intended use of the IHE Patient Care Device DEC (Device Enterprise Communication) profile is reporting device observations and device state data in an HL7 Version 2 form that:
- Provides for the delivery of the value of an observation together with an unambiguous identification of the measurement based on the ISO/IEEE 11073-10101 nomenclature, optionally with properly mapped equivalents from other coding systems such as LOINC, when available, together with unambiguously idenfied (by UCUM or 11073 nomenclature) scientifically correct units of measure, measurement reliability indicators, abnormal value indicators
- represents the DIM hierarchy of device data logical objects
The representation of the DIM hierarchy is something that ordinary HL7 Version 2 does not provide for, so the Observation Sub-ID field (OBX-4) used in an unusual fashion to support this. Details are covered in Volume 2 of the IHE PCD Technical Framework [ed.: provide link]
Mindmap of IEEE 11073 Domain Information Model objects used in mapping
Mindmap of IHE Patient Care Devices PCD-01 Message
Combined Mindmap of IEEE, IHE PCD, and FHIR Resource objects
Spreadsheet with objects from IEEE and FHIR objects
Representation of 11073 DIM hierarchy in FHIR resources
FHIR represents device data with a flexible combination of resources for Observation, Patient, Device, DeviceComponent, and DeviceMetric. As can be easily seen, this is not a one-to-one mapping of the basic 11073 DIM objects, but allows for a tailored representation of the full form of the DIM as well as simplified versions, appropriate to the particular device data use model.
Differences in Modeling Point-of-Care Device versus Personal Health Devices (ISO/IEEE 11073-20601 and -104xx)
A guiding goal of both the IEEE 11073 Personal Health Devices group and the parallel group for Point-of-Care devices has been strive for consistency in the conceptual framework, nomenclature, and presentation to external systems of both personal and acute-care devices. This simplifies life for everyone, particularly for healthcare delivery organizations needing to be able to access both categories of device data seamlessly.
This consistency goal has guided the design of HL7 Version 2 profiles of the IHE Patient Care Devices domain (a PCD-01 observation from an acute-care device and a comparable from personal device differ in as few ways as possible, basically affected only by the relative simplicity of the personal device). and is intended to do so in the design of
This is also a prime design goal of "Devices on FHIR" - the flow of data from a small portable device should differ from a similar flow of data from an acute-care device in no fundamental ways, but only in simplifications of metadata details.
[add discussion by Brian and John supplying examples, details]
Two of the main differences between PHD and PoCDs are the environment where they are used and the quality of the sensors. PHDs are inexpensive consumer devices and cannot be expected to have the same type of reliability as hospital PoCDs. PHDs are also used in the home environment by the patients and thus the infrastructure for getting these measurements to EHRs has to be highly automated. Getting patients to take the measurements can be a difficult enough task, and additional technical savvy to operate a system cannot be expected. In addition, data bandwidth costs can be a significant issue for patients, thus efficiency of the uploads is important. It may be nice to have as much information as possible but if only 20% of it gets used paying for that other 80% becomes questionable.
Otherwise the PHD mapping should be able to be made equivalent to the PoCD mapping where one simply removes those resources not needed in the PHD case. One of the most significant simplification in the PHD over the PoCD is that the PHD is static. VMDs and Channels do not exist in the PHD world. In PCD-01 this simplification is expressed in the OBX-4 sub-id where the domain hierarchy sets the VMD and Channel levels to 0.
The PHD environment does add a complication typically not seen in the PoCD environment. Due to the remote environment and the lower reliability of PHDs, device information about the gateway (PHG) is recorded and transmitted. In addition, PCD-01 uploads from PHDs tend to contain significantly more device properties and regulation information than recorded in equivalent messages from PoCDs. The difference is likely due to the questionable reliability of PHDs and thus the desire to be able to audit the results should they be questionable.
Mapping particular entities between 11073 DIM, IHE PCD DEC (PCD-01) and FHIR resources
Example: Single-purpose Personal Health Device device model, representation in IHE PCD PCD-01 message, representation with FHIR resources
[to be added]
Example: Multiparameter patient monitor device model, representation with FHIR resources (by Stefan Karl)
11073 DIM Representation
This is an ISO/IEEE 11073-10201 (aka “Classic”) DIM representation of a patient monitor with ECG and noninvasive blood pressure (NBP) measurements. It shows only a subset of the attributes.
There is a Hydra MDS object containing two VMDs. The ECG VMD has two Channel objects, one for the ECG RTSA (waveform) and one for the Heart Rate Numeric. The NBP VMD has one Channel and one Numeric object, which is a compound numeric for systolic/diastolic/mean values. The MDS contains also a Patient Demographics object, an Alert Monitor for alarming capabilities, and several Scanner objects.
This is an output file from the Device Profile Editor. The HTML file shows MDS, VMD, and Metric containment tree hierarchy with “dot” notation. The compound NBP numeric is split into three entries.
FHIR Resource Representation
This is a representation with FHIR resources. The model consists of Device, DeviceComponent, DeviceMetric, Observation, Location, and Patient resources. In some cases, more than one resource is needed to map one DIM object.
The DeviceComponent.parent and DeviceMetric.parent references indicate resource hierarchy. DeviceComponent.source and DeviceMetric.source link them to the Device. Each Observation refers to a DeviceMetric and a Patient resource. The Device refers to a Location (e. g., room or bed).
Open issue: FHIR resources for mapping the DIM Alert-related objects?
|11073 DIM||FHIR Resources|
|MDS||Physio Monitor Device|
Physio Monitor DeviceComponent
|VMD||ECG VMD DeviceComponent||NBP VMD DeviceComponent|
|Channel||ECG Channel DeviceComponent||Heart Rate Channel DeviceComponent||NBP Channel DeviceComponent|
ECG Observation (tbd.)
|Heart Rate DeviceMetric
Heart Rate Observation
In the examples, the mandatory DeviceComponent.identifier and DeviceMetric.identifier get UUIDs as temporary identifiers. It's proposed to make these elements optional (change cardinality to 0..*). In this case the temporary identifiers are no longer needed.
There is also an example of a Transaction Bundle, which has POST requests for all resources in the table above. Note that the POSTed resources don't have an id element, because the Resource.id will be assigned by the FHIR server. Therefore each entry has a temporary UUID as Bundle.entry.fullUrl for reference by other resources in the same transaction bundle. The server's transaction response contains the assigned ids. Both server and client need to substitute the ids in resource references for further updates.