Standards for Medical Device Interoperability and Integration
January/February 2011
Standards for Medical Device Interoperability and Integration
At the point-of-care, medical devices provide clinicians with real-time status of the patient’s condition, including the patient’s vital signs. This data is vital for treatment and can be a critical aspect of patient safety since it provides near real-time surveillance of patient status to locations beyond the patient’s bedside. And when archived appropriately and used for retrospective studies, the data has the potential for insights into the progression of disease and treatment that help with assessing the quality of care overall.
The clinical information system (CIS) or electronic medical record (EMR) is the user interface where the clinician and other hospital personnel throughout the hospital interact with this data. This means that the data is extremely time- and context-sensitive. Delays, inaccuracies, or errors may have severe adverse consequences including misdiagnosis or a potential for harm including patient mortality. Manual transcription and entry of patient data can lead to these delays and errors (Wager, et. al.). To solve these problems, many hospitals are implementing or investigating the implementation of medical device integration.
However, hospitals quickly realize that they have hundreds of different devices and models of devices they want to integrate. Many of these devices cannot send their data in a format or frequency that the CIS or EMR can receive. The idea of medical device interoperability standards has been proposed to try to solve this dilemma, to make it easier for hospitals to integrate any medical device they need to.
Over the past several years, the clinical engineering and informatics communities have come together to try to develop a set of standards for device vendors to follow so that all devices will be able to send data to the CIS and therefore make devices and systems interoperable. Yet, the practicality of true interoperability must overcome many technical and political challenges before it becomes a reality.
Will the availability of interoperability standards make the vendor-neutral device integration or middleware systems redundant or irrelevant? As I will explain, that is unlikely, since these systems handle integration and implementation-specific details that are beyond the scope of these standards.
Paradoxically, although the need for device interoperability has existed for quite some time, it has lacked a strong advocate in the design and development stages of most medical devices. As a result, in most cases, medical device interoperability standards have developed as an isolated endeavor outside device development and design, not as the integral and organic growth that should have been.
Device Data Transfer
Let’s first explore how the transfer of vital signs data from the devices to the CIS occurs. The actual physical transfer of data happens over a wired or wireless network connection or a serial data connection that allows the bytes from the source to get transferred reliably to the receiving information system.
The clinical device data format and encoding vary widely among vendors and sometimes even among different device models from the same vendor. This proprietary data encoding has to be decoded and imported into the receiving systems before it can be presented at the clinical user interface of the CIS/EMR and before it can be archived in the patient’s chart. Typically, a software component (a device driver) provided by the device vendor, the CIS vendor, or a 3rd party vendor does this decoding and translation, and provides a clinically usable metric with clinical context (time stamp, clinical measurement, units of measure, patient or location of the data source) for clinical presentation and storage. In many other cases the data is transferred through a device “gateway.” These are usually server or central station computers that collate and consolidate the data-streams from several medical devices (typically patient bedside monitors or infusion pumps). These gateways then forward the filtered and collated data to the CIS to be presented at the clinical user interface.
One major impediment to a successful device data integration project is the mapping of the clinical parameters from the various different devices and systems from different vendors to the patients’ chart. This mapping is required in order to maintain a unified and consistent representation of the clinical parameters and their units of measure. The different identifiers used by each vendor have to be harmonized such that the same or clinically equivalent parameters are correctly mapped together to ensure that a consistent vocabulary is used across the systems. This “semantic interoperability” is crucial for both patient safety and clinical usability (Rhoads et al., 2010).
The bottom line is that there are potentially hundreds of different types of connections and interfaces to manage. Therefore one can obviously conclude why the aspirations of trying to create a set of uniform standards to manage the interoperability of medical devices and help facilitate medical device integration is important. However, one will also see how and why a set of uniform standards cannot possibly solve all of the needs and issues surrounding medical device integration. (See pages 22 and 23 for a detailed description of the current standards.)
Benefits of Standardization
For clinicians and end-users of the device data, the benefits of standardization are:
Any component on either side of the interface could be substituted for an equivalent, without painful customization or reconfiguration. This would undoubtedly save time and resources.
- Standardization would allow hospitals to select best-in-class devices and systems based on effectiveness and suitability, rather than require compromises based on integration abilities.
- The entire workflow or process could be framed around the standard, and end-to-end verification and validation facilitated and codified into the clinical/biomedical process.
- Testing with automated test tools and frameworks would become the norm because the same tooling could be used to test all systems and device data exchange and acquisition since they would all conform to the standards’ specification (Garguilo, Martinez & Cherkaoui, 2008).
- Rigorous testing would in turn make the data stream more reliable, leading end-users to trust and adopt it more, consequently developing a safe and effective solution for healthcare delivery.
- For device, CIS, and EMR vendors, the uncertainty and redundancy of rewriting vendor-specific drivers and software would become unnecessary, and a single unified standards-based interface that is robust and has been tested rigorously would be used for all device data. Over time, this would translate into lower cost device integration solutions for hospitals.
Drawbacks to Standardization
There are also several drawbacks and issues not addressed by standardization. These include:
- Some advanced functionality of devices and systems, especially vendor-specific or those protected as intellectual property (i.e. patented), cannot be incorporated quickly into standards.
- Clinical or end users would have to adopt separate use case or workflow changes for data acquisition methods not supported by standards, therefore making the integration more difficult to implement.
- Legacy medical devices and systems may not directly support a standardized output format, so the data feeds from these would need to be processed by a proprietary gateway device from the device manufacturer or a third-party device integration vendor that can provide a standardized output stream.
- When a new device is hooked up or reconnected to a patient, the logistics of associating (the patient’s identifiers, including patient names, numbers, bed and unit location, and the clinicians assigned) automatically or semi-automatically with the device is not trivial.
- Having device manufacturers adopt standards across the board for their devices will be difficult to manage and enforce. Even with a viable standard, the critical mass needed to support it would take some time to develop.
These drawbacks make it apparent that one overarching standard may not be a panacea to all device connectivity issues; rather, a set of interdependent, complementary standards, each addressing a specific use case or workflow may be the ideal solution. At the current time, most of the device connectivity initiatives and standards discussed in this article are still under development and not “locked down” to be implementable in a commercially available, FDA-classified device or system.
Practical Implications
So what are the practical implications in an actual medical device connectivity implementation? If you have a heterogeneous environment of devices (from multiple vendors), you will need a vendor-independent device integration solution or “middleware,” preferably one that fully supports the relevant standards.
These middleware systems handle all the implementation-specific nuances and functionality that are beyond the scope of the standards, as described in the drawbacks section.
The middleware serves as a shim or glue layer between the various devices and systems, resolving or mitigating most of the key drawbacks of the standards like legacy devices and patient identification and association. The middleware also maps the dynamically evolving clinical workflows of real life to the ideal use cases as framed in the standards.
Conclusion
Standards are important and will help with the overall implementation of device integration. In fact, the IHE-PCD initiative has seen widespread support from most of the major device vendors, and may begin to appear in commercially available systems as the IHE-PCD profiles transition into their final implementation versions (Rhoads et al., 2010). However, full adoption by vendors and their live deployments are still out there in the future. If you are considering device integration at your hospital, you have some options available today; options that may just get a bit more “standardized” in the future. Standards will probably make it easier and quicker to develop integration solutions and possibly cheaper over time: all of that will benefit the clinical end user and improve the quality of care delivery, but cannot solve all of the technical, clinical and workflow issues related to device integration. The optimal solution, therefore, for hospitals considering device integration may be the implementation of a device integration system that can achieve interoperability today and that, when combined with any final standards, will deliver the most robust, flexible, scalable device integration solution possible to meet a hospital’s evolving connectivity needs.
Bikram Day is a senior clinical informatics engineer at Capsule. He is involved in various aspects of Capsule’s hardware and systems product development lifecycle from specification and design to product validation. He represents Capsule at standards bodies like IHE-PCD (Integrating the Healthcare Enterprise–Patient Care Device) Workgroup. He is also affiliate faculty at the OHSU School of Medicine, Department of Medical Informatics & Clinical Epidemiology. He has been involved with clinical informatics, medical devices, and healthcare IT for over 15 years. He may be contacted at bikramd@capsuletech.com.
|
Reviewing the Standards Fundamental or Base Standards IEEE 11073. This standard includes several sections that address various aspects of medical device connectivity and data exchange, including the physical and electrical connections and connector form factors, parameter nomenclature and units of measure, and variable semantics, to name a few. This standard began as the Medical Information Bus (MIB), and its successor, the IEEE 1073 standard. These gradually increased in scope and have now evolved into the ISO/IEEE 11073 set of standards (2004). Commercial implementations of this standard in medical devices are very scarce, with at the most two device vendors supporting this, in an insignificant fraction of their medical device offerings. The important work done by this standards body has not gone disregarded—several other derivative standards utilize the IEEE11073 standards both directly and indirectly as described in the following sections (Rhoads, et al., 2010; Workshop on Medical Device Interoperability, 2010). HL7. The HL7 standard is the most widely used data exchange format in healthcare, and has also been adopted as the most widely supported high level syntax for data transfer from medical devices or device gateways. There are currently two versions of HL7: HL7 Version 2.X. The 2.X versions of HL7 are the most commonly used versions in device connectivity data interchange. Most of these versions are reasonably backwards compatible with minor differences. HL7 Version 3.X. Although the version 3 of the HL7 standard supports more complex data semantics, and a Domain Object Model (DOM), it has not been utilized for device connectivity so far by any vendor. The primary downside for vendors of using HL7 as the only standard for device data exchange is that HL7 only provides the syntax for the data exchange. There are no semantics to actually use this data without additional context or nomenclature information, in a portable manner. There is another reason why HL7 is not the normal output data format for most patient-care devices: by its very nature and design, the HL7 syntax is extremely verbose with a lot of repetitive fields and characters, partly in order to be human readable. This makes it an extremely inefficient format for medical devices that need to send out large volumes of data in a short amount of time. Also, it is prohibitive to implement such a verbose and large syntax on firmware or hardware implementations where bits, bytes and clock cycles are expensive commodities. Finally, since there are multiple flavors of HL7 and could be more in the future, it is yet one more update that device manufacturers would need to maintain and upgrade on all their devices and therefore not practical in terms of implementation. Composite or Meta-standards IHE–PCD Workgroup (Integrating the Healthcare Enterprise–Patient Care Device Workgroup). The IHE-PCD is an initiative sponsored by the American College of Clinical Engineering (ACCE) and the Health Information Management Systems Society (HIMSS). IHE-PCD defines use case-bounded “Profiles” to describe clinical “transactions” that involve “actors” (e.g. entities like the sending device and the receiving CIS) (Rhoads, et al., 2010). The messaging syntax used primarily is HL7 version 2.6, with additional constraints and reduced optional fields, so that the messages are unambiguous, reproducible, and well defined between the sending and the receiving systems. This constraining of the underlying standards allows the semantics and the syntax of the messages to be rigorously defined and specified. In essence, the conversation between the sending device or system and the receiving system has been pre-defined to a high degree of detail. This allows systems that are independently developed, but adhere to the IHE-PCD “Profile,” to interoperate without individual customized configuration. The section below elaborates the different IHE-PCD profiles that are currently in draft or final implementations: IHE-PCD Profiles* Device Enterprise Communication (DEC) establishes communications between point-of-care devices and CIS/EMR systems. Point-of-care Infusion Verification (PIV) supports communication of a 5-Rights validated medication order from a Barcode Medication Administration (BCMA) system to an infusion pump or pump management system. Alarm Communication Management (ACM) enables the remote communication of point-of-care medical device alarm conditions ensuring the right alarm with the right priority to the right individuals with the right content. Implantable Device Cardiac Observation (IDCO) supports implanted cardiac device messaging other systems. *Adapted from http://www.ihe.net/pcd. These and several other profiles under development are described in greater detail at this url. The IHE-PCD initiative has seen widespread support from most of the major device vendors, and will be slowly appearing in commercially available systems as the IHE-PCD profiles are transitioning into their final implementation versions. Medical Device “Plug and Play”(MDPnP) Interoperability Program’s Integrated Clinical Environment (ICE)(ASTM F2761:2009) seeks to build an architecture for plug-and-play compatibility between medical devices and systems that will allow for exchange of clinical data, settings, and alarms and alert conditions (Workshop on Medical Device Interoperability, 2010). This architecture will facilitate the integration of diagnostic and therapeutic devices so that safety interlocks may be put in place that will prevent adverse and patient endangering situations from occurring. It may be noted that ICE architecture framework also utilizes the IEEE 11073 standard as one of its underlying standards. HITSP (Healthcare Information Technology Standards Panel) selects standards and profiles for use in the United States particularly focused on government initiatives. It has been coordinating with IHE–PCD to prevent replication of efforts. IEC 80001 is a standard currently under development that addresses the complexity of medical devices and systems in network environments and when they are aggregated to form “systems of systems.” This standard has been initiated to develop a framework for risk management of these complex infrastructures and their components. The standard shall address the process of identification and management of hazards and risks caused by this networked aggregation that may not have been foreseen when the original products were developed. This will be used to develop or implement safe and effective medical systems consisting of complex components in a distributed network environment. Continua Health Alliance focuses on home healthcare devices and unregulated medical gadgets. This initiative has been widely supported by many vendors seeking connectivity for home healthcare devices, which are completely disparate from the IHE-PCD devices used in the clinical environment, which are all FDA-classified products. All the device connectivity standards initiatives described above are working together closely to prevent unnecessary overlap and redundancies, at the same time leveraging each other’s strengths to complement their own standards. This has been possible due to significant overlap in the membership and leadership of individuals and vendors represented at these standards entities. ACRONYM GLOSSARY
|