An embedded solution for medical device interoperability

The idea of medical device interoperability has been around for quite some time. The standards have been debated and discussed since the end of the 20^th century. Today, we seem to be closer and closer to the reality of “plug and play” medical devices. With the ever increasing costs of healthcare, organizations have existed for the standardization of clinical devices (hospital rooms and operating rooms) and the emerging home-health industry.

Previously, it was very expensive and took too much time and effort for a third party to create an interoperable environment. The definite of a standard is that it eliminates this need of time and money.

We have displayed the effectiveness of interoperable devices with 802.11 Wi-Fi Networks and with Bluetooth accessories for one’s cell phone. We should be able to apply these same ideas to medical devices. With the implementation of a “plug and play” environment, there is the ability to have many advantages to the market and most importantly to patients. Some of these advantages include increased in productivity, a reduction in medical errors, real-time information gathering/sharing, and improved patient safety.

An Overview of the Concept and Implementation

Medical device interoperability is implemented via a combination of standardized, well-know and vetted hardware with robust, yet flexible firmware. By incorporating established, proven hardware with the firmware, a design that is robust, efficient, and relatively straight forward can be created.

Continua Health Alliance, a one of a few standards organizations in the area of medical device interoperability, was created to address the emerging home-health device market. The Alliance has attracted the support of many large corporations including medical device manufacturers as well as hospitals, insurance companies and other standards organizations. Recently, Continua has even decided to expanded its reach from the home health market to address more of the healthcare ecosystem; end-to-end from patient to electronic medical records (EMR).

Continua decided to select standard interfaces in order to leverage what is available and known to the electronics community. So far, Continua has selected the following standards:

• USB for Wireline Interface
• Bluetooth for Wireless Interface
• Zigbee for low power LAN sensor interface
• Bluetooth Low Energy for low power PAN interface

As for the firmware portion, the utilization of established technology makes it very attractive and offers an ease of implementation. However, a variant needs to be added to each standard in order to follow a specific data format so that efficient flow of data is possible. Continua decided, in addition to the hardware and firmware standards, they would also follow the data format of the medical device specific IEEE11073 standard (www.ieee.org).

The IEEE11073 stack works in conjunction and sits between the established lower layer of the communication stack and the medical device application code, Figure 1.

Figure 1. Diagram of Firmware Layers for Interoperable devices

IEEE11073 has defined the information transport as well as the device specifications for particular medical device applications. Table 1 is a small example of what has been defined:

The Possible Embedded Solutions

The design and industrialization of a medical device on its own (regardless of interoperability) is not a trivial task. Design cycles can range from one to three years or more depending on the application. In addition, there can be clinical trials as well as FDA approval. Adding a function such as "Plug and Play" communication is one more thing to worry about and may or may not be something the design team is familiar or comfortable with

When one is considering a course or strategy in implementation this solution, a few issues come to mind:

• Time and resources
• Cost
• Space
• Power consumption
• System resources

Upon addressing these issues, one can start to figure out what solution or combination of solutions will work for the design. Depending on the time available, the amount of resources/expertise, cost and level of integration, a design team has a few different choices.

The figures below show two different potential solutions. These are by no means the only ways of implementation, but offer varied approaches to the problem. These solutions could be mixed and matched based on the needs of the design.

Figure 2 illustrates a fully integrated solution. This is where the stack software and the various protocols reside on the application microcontoller and the wireless section and USB interface is implemented with the lowest cost in mind.

Figure 2. Integrated Approach of Interoperable Device

The external radios with their accompanying circuitry (including antenna) are connected to the application microcontroller via well-known communication interfaces such as SPI, UART, and others. The USB interface is embedded in the microcontroller and requires additional circuitry for the physical interface and connection to the outside world. The solution is split between "application," where the data acquisition is taking place and the communication where the acquired and processed data is passed on.

Of course, the memory inside the microcontroller would need to be big enough to handle both the application code and selected communication stacks. The STM32 ARM Cortex microcontroller has scalable memory and is pin-for-pin compatible over most memory densities. The benefit of this is that if a design called for one or all communication protocols, the designer could adjust the amount of memory necessary in order to fulfill the requirements without a need for re-layout of the microcontroller.

It is understood that the microcontroller would need to have enough performance/resources to handle the various communication protocols and also handle the application code as well. This is a resource allocation exercise to be evaluated. A real-time operating system could be chosen as well in order to manage the resources of the microcontroller, but this would add to the memory needed in the design.

The second figure, Figure 3, displays a more modular approach. This figure shows the same application microcontroller and application code as the first figure, but this is a solution where cost and space aren't as much of a concern and ease of implementation is critical to the design timeline.

Figure 3. Module Approach of Interoperable Devices

The main difference is that the communication section is facilitated by a self contained IC or module. In other words, the design engineer would not need to know anything about the modules in order to implement the communication protocols.

The application microcontroller is using the same standard communication ports as before (SPI, UART, etc.) and external modules/ICs incorporate the necessary protocol stacks internally. The application microcontroller only needs to handle the application code and send the acquired and processed data to the communication modules. The application microcontroller sends simple commands over the communication interfaces to the modules, which convert the data to medical specific information and then forwarded out.

This design example is easier to implement because the protocol stacks are self contained, but the modules and additional microcontroller add more cost to the hardware of the design. It is clear that the first is less expensive than the second, but depending on the criteria set for the design, one could select one idea from Figure 2 and one idea from Figure 3. The understanding is that the design can be as flexible as needed with cost, timeline, resources, performance all being taken into account.

These designs are not meant to show how easy they are to implement. More to the point, that there are options available and components available make the design choices and implementation as straight forward as possible.

Communication is not a simple concept and is becoming more and more necessary in our connected world. Although the purposes of this article are to show that Medical device manufacturers do not have to become experts in wireless standards, USB, IEEE standards, electrical medical record format, among others.

The concept of Medical Device Interoperability isn't a trivial one. Although with the inception of more system-on-chip microcontrollers, large flash memories and a plethora of communication ports, a design engineer can be flexible and scalable with their design.

The implementation of "plug and play" communication in the medical-device field has become a reality. Over time, as tools and solutions become more and more intuitive, designer will be able to spend more and more of their time and resources on the application and less time on the communication protocols. Hopefully this leads to a more productive, safer and less expensive medical-device market.

About the author

Andrew Leone is a Market Development Engineer for STMicroelectronics with a concentration solely on the Medical/Healthcare Sector. His experience includes biosensors, MEMs, wireless and microcontroller based solutions. Andrew holds a degree in Electrical Engineering from Johns Hopkins University. He can be reached at andrew.leone@st.com.