Overview of Medical Device Integration Task

I provided an overview of integrating medical device systems and information into an EHR in a paper I wrote in 2008. The figure below provides a graphical representation of the overview.

The system architecture for medical device integration consists of a medical device which is attached to a network, and then a series of aggregators and ‘interface brokers’ for the medical device data to flow to the EHR.  Also shown in the figure is a process and system to affiliate the patient information with the specific medical device data (“patient ID binding”).  Generally, the process to implement medical device integration into an EHR consists of identifying a medical device, its networking capability, transforming that networking capability if needed, aggregating the data output from the medical device, and then mapping the data to the EHR or other consumer of the data from the sensors or setting of the medical device. It can be very difficult and time-consuming to implement a medical device integration system as there are many different vendors of medical devices with different sensors and networking capabilities.

Moorman Depiction of Medical Device Interfacing/Integration (Moorman, B., 2008)

Many times a medical device does not have the ability to send data or will require a networking transformation to integrate into the system and the EHR.  In addition, depending on the medical device integration vendor, there may not be a ‘driver’ which converts the medical device data to a format that can be accepted by the EHR.  The preparatory phase of identification of the medical device, networking and data state can be very time consuming and is currently mostly a manual process.  Having a quick way to identify the networking and sensor constraints described above would make the job of implementing the medical device integration system easier and less labor intensive.

Current Status

A brief review of the work done in this medical device integration area since my 2008 article has shown many ideas for development of “middleware” management techniques.  Interestingly, nearly all of the techniques require medical devices to have networking capability as well as sentience to report what they are and what they deliver and/or a device directory which has a knowledge base of the available devices and what they deliver (device specifications, meta-data, sensor and setting data).  At the same time as these middleware techniques have been published, the three device integration vendors I mentioned in the 2008 article have been ‘absorbed’ by larger companies:  CapsuleTech by Qualcomm, Nuvon by Cardiopulmonary Corporation (now Bernoulli Health), and iSirona by Nant. Moreover, many of the EHR vendors and medical device vendors now offer their own branded medical device aggregation and integration solutions.

Middleware Ideas Highlights

In “A reconfigurable middleware for on-demand integration of medical devices,” Kliem, et al (2016), describe a middleware platform for medical device integration that “handles standard and proprietary devices, can adapt to the rapidly changing sensor and device environment, and…  ...preserves interoperability at the application level, if devices are replaced.”  Interestingly, they describe a Device Directory (DD) as one of the components of their system which they envision as a directory service for medical devices comprising of specific knowledge about the medical devices to be accessed by the aggregator if an unknown medical device is “discovered” and needs to be integrated.  The main assumption here is that there is a device directory available and the authors envision a Global Device Directory which would contain several files about each type of device and its characteristics to aid in integration.  The information needed from the DD would be meta-data about the device such as vendor, class, unique identification, networking, and security.  Once integrated or connected to the middleware, device setting and sensor data would also be available for integration to a system using the middlware for an interface. The system described is assumed to be dynamic in nature and not manual as most currently available medical device integration systems.

In “Agent-based plug-and-play integration of role-enabled medical devices,”  Cabri, et al (2007), describe an agent-based solution for medical device integration which is comprised of three agents that interface, process and manage the medical device data to requestors of the data.  Interestingly, they assume that the medical device has networking capability and they state that device vendors should modify their device software to accommodate the different roles they assign the agents so that this middleware, which is also dynamic, could be enabled for medical device integration.

In “An open test bed for medical device integration and coordination,” King et al (2009), developed a java machine virtual integration engine which provided device connection and medical device data integration and closed-loop control.  Again, there was an assumption that the medical device had networking capability and they stated that devices should have a Java Virtual  Machine  (JVM) capability or ‘dongle’ which could manage the Java Messaging Service which managed the publish and subscribe mechanism underlying their integration system.  They also were going to expand their work using publicly available data streams from medical devices, so they also do not have a knowledge base of medical devices and their characteristics available to use their integration engine.

In “A proof of concept for medical device integration using web services,” Gregorczyk, et al (2012), published a proof of concept using the Device Profile for Web Services (DPWS) in a specific clinical area and use case for medical device integration.  For their demonstration, one of the devices in actual use (the surgical microscope) had to be replaced with another in the same device class as the original one did not have networking capability.  In addition, they required that the devices output information that was in the IEEE 11073 standard, which is not a widely implemented capability.  Yet again, there was no knowledge base available or built by them for device integration purposes.  They concluded that while theoretically possible to use DPWS for integration, several critical issues remain:  lack of patient context, no ability to use non-networkable devices, lack of security protocols, and lack of semantic interoperability capability (unless the device can output in IEEE 11073 format).

In  “Security and communication architecture for networked medical devices in mobility-aware eHealth environments, “ Kliem, et al (2012), described a middleware approach to manage medical device security and access to an aggregator for integration.  They specify a backend which has a global device directory and master and provider authorities which rely upon local device directories.   The aggregator connects to the backend and the device.  This paper describes an attempt to solve the issue in the Gregorczyk paper above with regard to security.  However, it is theoretical and does rely upon the device directories or knowledge bases to function correctly for the device discovery function.

In the last paper, “Medical device integration model based on the internet of things,”Hao, et al (2015) also describe a middleware approach that is dynamic and uses a four layer model to define their approach:  devices abstract layer, device adaptation layer, data access layer and data abstract layer.  The devices abstract layer is further subdivided into standardized output devices, non-standardized output devices, and imaging devices.  The device adaptation layer is further subdivided into a collection of inspection items (sensors), device type (class), and communication mode.  The device access layer deals with the hardware connection for networking and assumes that all of the devices have networking capability.  Lastly, the data abstract layer (also the data filtering layer) is further subdivided into inspection items (sensor items), inspection end value (sensor value), reference value, and inspection conclusions. However, again, they require the device to have networking capability and imply there is a knowledge base about the devices and the data they can output.

Summary

As seen above in each of the middleware proposed solutions  a medical device knowledge base that includes available devices (network capabilities) and what they deliver (device specifications, meta-data, sensor and settings data) and/or a capability of the medical device to report that information is required for all of the middleware integration techniques.  The current commercial device integration vendors have (proprietary) medical device knowledge bases which usually consist of a list of medical device drivers available for integration by each device integration vendor.  In all of the research above, I could not find a generalized available device directory that could be queried or integrate medical device integration knowledge.   There are several nomenclatures and ontologies that could be used in a device directory, however, none had all of the knowledge necessary for medical device integration.  Due to the lack of a knowledge base, I attempted to build a medical device integration knowledge base that would provide most of the knowledge and functionality needed to assist the middleware applications in their operations.  My next blog post will describe my attempt and the results.