Point-of-Care Device Implementation Guide
current - CI Build
Point-of-Care Device Implementation Guide
current - CI Build
Point-of-Care Device Implementation Guide, published by HL7 International - Devices Work Group. This is not an authorized publication; it is the continuous build for version current). This version is based on the current content of https://github.com/HL7/uv-pocd/ and changes regularly. See the Directory of published versions
Most Point-of-care devices used by professional in acute care settings are complex in structure and communicate much more information than is typically reported in a clinical flowsheet display.
This simplified display represented by an Observation pointing to a single device as its sources is sufficent for clinican use when it is desired to emphasize the most important for hour-to-hour and minute to minute care of the patient, without overwhelming the user with complexity. For other use cases, more context for how the measurement was made can be important.
The backbone for representing a device for this implementation guide is the generic model for a device from the IEEE 11073 Medical Device Communications Domain Information Model.
This is a widely-used standard model, straightforwardly based on a hierarchical representation of a typical medical device as an overall system with logically distinct subsystems, which in turn have additional levels of contained objects.
The containment tree is rooted at the overall system, with is identified in the model as a Medical Device System (MDS object). representing the whole device, with logical subsystems identified as Virtual Medical Devices (VMDs)
These VMD logical subsystems may also have a physical aspect – they may be detachable, as in a measurement module in a multi-parameter physiological monitor, so have an individual identity (model and serial number), and may move from MDS to MDS. The tracking of this dynamic relationships is required for the results to be traceable to their precise source.
VMDs may need to have the measurements they report grouped into logical channels. This is sometimes not necessary to model, but in cases like certain infusion pumps, or EEG modules, there is a meaningful partition of the data into channels that may be critical to the safe treatment of the patient.
At the lowest level, observations correspond to what the IEEE 11073-10101 Domain Information Model calls a ‘Metric’. These are not necessarily single quantitative measurements. They may be:
An individual measurement has a context made up of all the levels of the containment tree. At each level there are attributes that condition the understanding of the measurements
An Observation may link to the DeviceMetric to gain access to all levels of the containment tree. See the “Implementation Guidance” sections of this Implementation Guide for further details.
LOINC and SNOMED nomenclature systems have concept codes for the majority of the most often used device observations, and when they are known for a particular device observation they should certainy made available in device data.
Why, then, are MDC codes useful, and under what circumstances? The IEEE 10101-11073 Medical Device Communications Nomenclature standard is driven by a consensus process with input from subject matter experts from the device designer/manufacturer community as well as other clinical and regulatory experts with a goal of expeditiously providing a code for a concept needed in medical device communications as soon as possible, for practical use including device communications testing and research. The code comprehensively supports communicating identity of physiological measurements, from common to somewhat obscure. Of course many of these have LOINC equivalents, SNOMED equivalents, or both and once the correspondences are established, makers of devices and associated software should provided muliple codes for the convenience of clients preferring any of the systems.
Besides the physiological measurements, MDC also services the needs of device implementers with a large set of concepts and codes for communicating internal device structure and function including device state, and also event and alert messages connected with technical as well as clinical patient state changes that are covered in no other widely used set of standards. The MDC codes for physiological measurements are also used by many manufacturers becase of their role in IHE DEC Device Enterprise Communications profiles. See the “Profiles” pages for examples of the use of the MDC Object Partition codes.
The ongoing nomenclature development process is a collaboration of the IEEE Point-of-Care Device Committee, which ballots and issues updated versions of the standard, and the IHE Patient Care Device Program’s Rosetta Terminology Mapping Committee, with representatives of many manufacturers as well as independent experts. The database of record for proposed and provisional, as well as published, concept definitions and codes is currently maintained by the US National Institute of Standards and Technology and is available on the web as the Rosetta Terminology Mapping Management System. IEEE permits royalty-free use of the codes and most of the supporting information under conditions described on the RTMMS website and in the FHIR specification “Using MDC Codes with FHIR” page at https://www.hl7.org/fhir/mdc.html
The most commonly used form of HL7 Version 2 used in acute-care device data reporting is that of the IHE Device Enterprise Communications profile PCD-01 transaction. That is the basis for the mappings ouerlined here. Like this Guide, it is based on the IEEE 11073-10201 Medical Device Communications Domain Information Model.
For details see IHE Patient Care Device (PCD) Technical Framework Volume 2, Transactions https://www.ihe.net/uploadedFiles/Documents/PCD/IHE_PCD_TF_Vol2.pdf. See also “Technical Implementation Guidance” -> “Mapping from HL7 v2 to FHIR” in this Guide.
Devices are a key part of keeping current situational awareness in treating high-acuity patients. Information not normally provided in the Observation resource ay be relevant to care, as, for example, is the device or one of its subsystems or measurements in standby mode or otherwise disabled because of user action. Technical metadata such as battery performance may be valuable for early warning of potential device problems.
It is expected that some institutions will choose to set up an archival system saving all available detail from devices as well as other data created in near real time, such as provider notes during a procedure, including device data and context details that may not be displayed in real time. Assuming that there is such an archive system, the ability to retrieve and “look back on” all such data on request of a person or of another hospital information system can serve many use cases, including those listed. Since FHIR seems to be becoming a common interoperability medium or “lingua franca” for passing around models to retrieve data retrospectively. The strong support for search and filtering designed into FHIR are highly valuable in such uses.
Proper integration of clinical measurements in algorithms may depend on the method of measurement being used or even the particular model of device being used. For plug-in modules, which are modeled as Virtual Medical Devices, this information is available from the Device resource representing the module.
Comprehensive recording of device configuration and state information in addition to the measurements recorded supports including more kinds of information in analytics models.
In this scenario, comprehensive device configuration and state information is valuable for both real-time and post analysis of state and function of the innumerable devices clinical engineering and healthcare technology management departments are responsible for tracking and maintaining. Devices themselves record and communicate much of this: power-up self test results, calibrations performed, operational state history, location.
When it is necessary to investigate an adverse event, the context information provided by thorough archiving of all background information about the state and performance of the device allows, for example, identification of specific subsystems and components of the device may have malfunctioned.
A key characteristic of research uses of data is the need to be able to summon up the data needed to answer unanticipated questions that are raised.
** The following use cases are not in this release of the Implementation Guide but are intended to be covered in the next release**
Devices report a rich variety of clinical and technical alerts that may require prompt or immediate action by members of the clinical care and technical teams. Current proprietary systems, and systems using the Alert Communications Management (ACM) HL7 V2 Profile serve this sector. As FHIR broadens its coverage of hospital needs, this should be supported.
Events from one device system to another, or to other clinical information systems,play a role in important use cases, such as are seen in the IHE PCD infusion verification profile.
Some of the details in this Guide are mainly of concern to implementers of device and device gateway software and is not of primary importance to users of the data.
For implementers of systems consuming rather than constructing FHIR resource representations, the important aspects of the Guide to pay attention to are the point that Observatons are embedded in a containment structure of different levels of logical organization, discoverable by following links between Device resources, each carrying information about one logical containment level of the ultimate Observation.
Implementers of such applications may already be familiar with the IHE Device Enterprise Communications profiles, and Data Observation Reporter transactions such as PCD-01, and can leverage their knowledge of the IEEE 11073 Domain Information Model to help in understanding the FHIR forms of this Implementation Guide. The “Implementation Guidance” page “Mapping HL7 V2 to FHIR” may be helpful.
Imlementers working with data from devices designed with the IEEE 11073 Domain Information Model in mind, or with existing IHE PCD-01 capabilities, may find it relatively easy to use this as a basic template for constructing FHIR representations in this Implementation Guide
If no compatible model for a device exists, consider the following steps:
In collaboration with subject matter experts in the functions of the device and in the clinical uses of the device data, gather information on what the device can communicate and how it maps to the needs of:
not neglecting the non-clinical information that the device can communicate about, devise a containment tree that represents the devices capabilities and their logical arrangement.
If this is a “green field” project for a device that is in the design phase, consider the range of uses for the device
It is probably commoner that you are retrofitting FHIR output to a device that already has a legacy form of data output and you must fit a “gateway” to convert data in a form the device already uses to a form compatible with a “containment tree”.
See especially the “Implementation Guidance”, “Profiles”, and “Terminology” sections of this Implementation Guide for needed details.
IG © 2017+ HL7 International - Devices Work Group. Package hl7.fhir.uv.pocd#current based on FHIR 4.0.1. Generated 2023-08-07
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change