Using Modern IoT-Style Protocols For Next-Generation Connected Medical Devices

By Shahid Shah, president & CEO, Netspective Communications
Follow me on Twitter @ShahidNShah

Why a “thin” design based on Internet of Things (IoT) and distributed message techniques might be the right approach for your next product.

Medical devices traditionally have been well-bounded — the hardware and software necessary to perform their functions were designed, implemented, and tested together without much regard to the external connectivity or integration necessary in modern systems of systems. Requirements that used to be understood and handled with a small team of designers and engineers now extend to include systems integration, messaging, data interoperability, patient privacy, device utilization, billing, consumer-generated health data, and a variety of Internet of Things (IoT) topics.

In my years as a chief technology officer (CTO), chief information officer (CIO), chief architect, and engineer on numerous regulated safety-critical systems, I’ve found that as our medical devices encroached into health IT and digital health territory, they created undue design angst and navel gazing. Nextgeneration IT integration requirements led the best of my teams into days, weeks, and sometimes even months of design paralysis. The primary reasons for the paralysis have been due to (a) team members focusing on technical solutions too early in the process and (b) trying to make sure all the data integration and connectivity tasks were built into the device itself instead of offloading some tasks onto ancillary IT systems. What next-generation medical device designers need to learn is how to create layered, distributed systems that don’t fall neatly into a single boundary. This seemingly simple adjustment takes years to accomplish successfully.

For the past few years, I have been architecting “thin, mostly connected” platforms — where device connectivity is assumed to be common and devices aren’t operated standalone except during emergencies when networks have failed. A “thin” device, in modern IoT environments, is where some device functions like sensors and data acquisition are on the device, while others like patient identification, reporting, and analytics have been offloaded onto the network. “Fat” devices, in contrast, do not offload much and perform most if not all functions directly on the device (which makes the device “heavier”).

Alarm management is a great example of a common device function that has, in the past, been integrated into devices but these days can easily be externalized. While not the only such feature, alarms are so prevalent in devices that they make a good use case to study. In the world of disconnected or semiconnected medical devices (which is, of course, common today), alarms are often targeted to specific devices (e.g., pagers/ SMS) or workstations (popup windows).

Targeted or localized alarms can often be missed; distributed alarms with the ability to automatically escalate or propagate to ancillary systems would be both helpful and improve patient safety.

This article promotes the use of IoT and distributed messaging techniques to help connect medical devices and easily implement features like distributed alarms. These features can, without significant software work, easily use existing IT assets within hospitals and other high-acuity settings. Instead of building everything into a single integrated device, Internet-style protocols can broadcast and transmit alarms to those devices that are best equipped to handle them. Not only do thin devices enhance device features, but they also actually help improve clinical user workflows by creating a system of systems in which care providers decide how or whether they would like the alarm to sound (or choose to enable any other advanced functionality on other networked IT assets). The same capability can be extended to sensor data sharing, patient identification, data privacy, security, device utilization, and many other features that many device designers are trying to build into their next-generation devices.

The Need For A New Medical Device Connectivity Architecture
Before jumping into a functionalityspecific technology discussion, I’d like to talk about an overall architecture for next-generation device platforms, because my suggestion for distributed alarms or network-based patient identification can’t easily be implemented using current, disconnected device design. Future medical devices, especially those with connectivity built in, will be more like full computers and mobile phones than special legacy devices, and they need a safe, reliable, regulation-friendly, and extensible architecture.

A Next-Generation Medical Device Platform Architecture
My suggested architecture for such future device designs is shown in Figure 1. This architecture, when implemented properly, can make most new connectivity- driven device features a reality without significant work on the device designer’s part. Also, if appropriately implemented, the Connected Medical Device Architecture can help third parties such as hospitals or custom solutions integrators create their own device-centric and device-enhanced functionality on top of a modern framework of Internetstyle standards.

This part is key for future devices. They must work disconnected in emergencies, through their own gateways for functionality known in advance, or perhaps most importantly, through third-party integrations and application programming interfaces (APIs), because much of the functionality that is needed in the future may not be known in advance. The more the devices are designed as connected systems, the more likely the device designers and vendors can focus on their strengths (clinical sensors, algorithms, parameters, workflows, etc.) and leave areas of weakness or non-device-specific features to be filled by integration partners.1 When dealing with customer- specific functionality like alarm handling or positive patient ID, it would be great to have an integration strategy built into the devices.

Figure 1: The Connected Medical Device Architecture for future medical device platforms (see Table 1 for descriptions of labeled items)

The Device Architecture
In order to prepare for talking about externalizing device features in subsequent sections of this paper, let’s discuss what audiences like CIOs, health system informatics officers, and other customers are demanding in their new medical device designs. The following table articulates the specific components of the Connected Medical Device Architecture that should be pursued by device designers so that existing device features can be distributed to other systems on the network.

The Connected Medical Device Architecture approach allows distributed alarm notifications, device teaming (which means multiple devices can work with each other for alarm synchronization and escalation), connection to cloud services (for use in remote surveillance), cross-device application workflows, and many other important benefits. See Figure 2 for a summary of important capabilities on the enterprise IT side of the equation.

Figure 2: Enterprise IT benefits of the Connected Medical Device Architecture

DDS, XMPP, MQTT, And Other IoT Protocols For Distributed Messaging
I suggest that all next-generation connected medical devices embrace and extend either XMPP, DDS, MQTT, or other IoT protocols as depicted in Figure 3.

The Internet Engineering Task Force (IETF) Extensible Messaging and Presence Protocol (XMPP, RFC 2779) is an open protocol optimized for IM, but it is extensible and robust enough for arbitrary messaging use in modern medical device platforms. XMPP was defined to help with (a) presence management, (b) direct message exchange, and (c) querying for arbitrary data. XMPP is a reasonable choice for connected medical devices because it can eliminate polling for messages and device states, can facilitate two-way data exchange without firewall and network path issues, can pass binary or text data, and knows when devices or servers are on- or offline.

While not as well-known as its more generalized SOAP (Simple Object Access Protocol) and REST (representational state transfer) protocol cousins, XMPP is a capable protocol with wide and deep open source and commercial software support. XMPP is scalable, has built-in access control capabilities, has HIPAA-compliant support for message encryption and authentication, can be implemented in a reliable manner, and has been demonstrated to be performant in production environments.

Figure 3: Device connectivity options

XMPP’s primary weakness is that it is more verbose and uses up a bit more bandwidth than competing methods, but in a modern network infrastructure, compression and faster network components can usually overcome that weakness. Given what you get in return, the verbosity is something you should easily be able to accommodate. Keep in mind that while XMPP is a great choice, DDS and MQTT should also be considered based on device design requirements.

I have architected XMPP for intra-device communication (for components inside a medical device to use as a messaging layer) as well as inter-device communication (where devices are talking to other devices or servers / gateways). While intra-device communications is crucial — and if you use XMPP for messaging inside your device, it will be easy to use outside your device — for the remainder of this paper, our discussion of XMPP will be for use as an interdevice protocol. However, all of the lessons and designs discussed below can be used and applied within devices as well.

XMPP is a client-to-server and serverto- server communications protocol. For our purposes, a client may be one or more medical devices, and a server is a device gateway. Using simple email addresses (e.g., Device1@DeviceGateway. com), XMPP clients talk to the XMPP servers with which they are registered. The “X” in XMPP stands for “extensible,” which means XMPP can carry almost any kind of message (a sensor event, an alarm, a data logging request, and so on). XMPP clients (devices) send messages to their registered servers (gateways), and through this mechanism devices can talk with gateways and with other devices. Think of it as IM between robots (the devices are not people but robots sending messages to each other). As IM tools allow real-time communications between people, the XMPP protocol would allow real-time message exchange between devices in a completely standard and reusable way.

One of the most important aspects of XMPP that would be useful in our alarming use case is presence. Services such as IM are mostly useful because you know when a user is “present” or “away” — imagine that a user can simply look at a dashboard and know exactly which devices are on, where they are (because XMPP can broadcast their locations), what recent alarms were issued, and so on. Extended presence (an XMPP extension) supports features such as geolocation and location-based awareness. When an XMPP device connects to its gateway, the protocol registers presence automatically, which can give additional details such as “starting up,” “busy,” “battery low,” or anything else you can think of. The XMPP gateway has presence information for its devices. Each XMPP device maintains a list of patients and users on the XMPP gateway (think of a buddy list in IM systems), so it’s clear who is using any device at any given time, all without any custom coding.

The XMPP server determines presence status for each member of the roster and keeps this information up to date. Think about how powerful it is to get, basically for free, a presence management capability in a distributed environment where you know what state all your devices are in just by asking a single server.

XMPP, while optimized for real-time usage, can also be implemented using traditional store and forward message architecture. If an XMPP device is temporarily disconnected, the gateway could automatically know about it, and the XMPP client software stack would start to use local device storage to maintain alarm messages. When the device was reconnected to the network, it would forward its requests to the gateway and go back to real-time alarm connection mode.

Military networks, with their need for standardization and reliability, already use the XMPP protocol family, so safetycritical medical uses are similarly applicable. The military uses them to enable heterogeneous component connectivity and integration of devices with various armed services. Since hospitals desire integration in a similar way and without proprietary lock-ins, XMPP should be very suitable for the hospital IT environment. Like military networks, hospital networks are already overburdened — for this reason, XMPP users can utilize the built-in compression capabilities in the protocol itself or via Transport Layer Security (TLS). While it can’t be as optimized for specific uses as a custom-built protocol, XMPP has many more users and can be upgraded easily in the future with different implementations (open source or commercial).

Conclusion
If you treat distributed alarm management and similar next-generation device design requirements as a messaging framework problem and choose a stable, well-defined messaging framework like XMPP, DDS, or MQTT as your foundation built on a connected medical device architecture, you can save a great deal of time and resources (not to mention costs) over a custom solution. By choosing an IETF or OMG documented extensible messaging protocol like XMPP or DDS, you and your engineers will be able to focus on the device and allow customers to integrate and distribute your alarms outside your device safely.

Shahid Shah is an award-winning IoT mentor and medical device hardware / software design coach with 25 years of technology strategy and engineering experience. You can reach him via Twitter or email.

---

Notes
¹ This is the model used by almost all successful technology implementations – no single vendor can do
² Android is a special distribution of Linux designed for mobile and touch-sensitive devices
³ Health Insurance Portability & Accountability Act
⁴ The 2009 American Recovery & Reinvestment Act (ARRA) Health IT Provisions Section, where meaningful use (MU) was first defined
⁵ National Institutes of Standards & Technology, the Federal agency that sets national standards
⁶ Federal standard for encryption algorithms, required by the Department of Health and Human Services (HHS) and the Office of the National Coordinator for Health Information Technology (ONC) in MU
⁷ A method for ensuring that data hasn’t been tampered with or accidentally modified
⁸ A method for performing forward error correction in cases where network data can be interrupted
⁹ The standard protocol used for connecting browsers to web pages / servers
¹⁰ The standard protocol used for messaging middleware
¹¹ Wireless Communication Transfer Protocol
¹² The standard protocol used for trapping events across network nodes (like routers and computers)
¹³ Object Management Group’s Data Distribution Service
¹⁴ Message Queue Telemetry Transport