Motivation
Interoperability is an important topic within the medical domain. Interchanging information throughout different systems in a hospital environment is still a challenge. Adopting standards like HL7 FHIR will ease the process of interchanging information. This applies between different systems inside a hospital and between distributed medical facilities. In the Point Of Care (PoC) domain, like ICUs or operating rooms, there is still a lack of interoperability. This issue persists between medical devices. A today’s PoC like an operating room is fully packed of different medical devices, often mixed from different vendors. All the different devices, including pumps, sensors, and monitoring displays, work towards a common goal. They support and enable the perfect treatment for the patient. But without a proper integration the goal to create a more sophisticated overall system is missed.
Room for improvements
That’s why there many unresolved use cases for improvements. One particular problem is Alarm-Fatigue e.g. in an ICU. Each medical device does have its own alarm system. A pump yields an alarm when a specific pressure is not met. Another device for blood measurement will alarm when it detects a wrong blood saturation of the patient. To react to all the different alarms you have to evaluate their priority, recognize false alarms and finally acknowledge them. Reacting to alarms is quite hard in a stressful situation. These conditions include hard time constraints faced by the medical staff. This leads to alarms being active for a longer time. It also reduces the awareness of new alarms coming in. This kind of information overload leads to a high stress level of the medical staff. The high noise level due to the alarms affects the patients and their healing process as well. Dräger, one of the leading forces behind the SDC standards, have already showcased a prototype of silent ICU solution based on SDC (https://www.draeger.com/en_seeur/Hospital/Interoperability-Future-ICU).
The lack of a synchronized date and time on all the devices is another topic that occurs often in PoC environments. Each device has to be configured on its own to be set to the correct date and time. So it’s quite common to have different date and time on each device. When exporting data from devices for later evaluations missing or wrong timestamps might lead to invalid data. A common way of an automated synchronize of clocks among devices should be the way to go.
To close the interoperability gap between medical devices in a PoC, many vendors develop their own proprietary solutions. These solutions interconnect their devices. But Vendor specific isolation makes it difficult to integrate the entire device chain of the PoC. In some cases, it is impossible to do this appropriately. To finally improve this situation, a new standard Service-Oriented Device Connectivity (ISO/IEEE 11073 SDC) was born. We would like to examine the standard more closely. We aim to understand how it works. Additionally, we want to learn about the technical concepts used.
Service-Oriented Device Connectivity (SDC)
SDC is a web services-based architecture. It enables a secure and dynamic networking of distributed Point-of-Care Medical Devices and Medical IT Systems. SDC-enabled medical devices can communicate with each other bi-directionally. They interchange data using a standardized communication nomenclature. The standard explicitly addresses securing device connectivity. It protects transmitted data with modern encryption principles. It also introduces authentication and authorization concepts. These ensure what kind of communication is allowed between devices. Furthermore, dynamic networking will support a distributed system of devices. Devices can become part of the system in a dynamic plug-and-play way.
A very common way of presenting all of these parts is the cathedral model:
CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0/legalcode
Like a cathedral the whole family of SDC standards are build on top of each other. The base of this cathedral and therefore the core of the SDC standard consists of 4 different parts. We would like to focus on these core standards which is sufficient to understand the fundamental functionality.
- IEEE 11073:10207: Domain Information and Service Model for Service-Oriented Point-of-Care Medical Device Communication (BICEPS)
- IEEE 11073:20702: Medical Devices Communication Profile for Web Services (MDPWS)
- IEEE 11073:20701: Point-of-care medical device communication — Service oriented medical device exchange architecture and protocol binding
- IEEE 11073:1010X Coding Systems
Let’s have a closer look at these different standards.
IEEE 11073:10207: Domain Information and Service Model for Service-Oriented Point-of-Care Medical Device Communication (BICEPS)
The best starting point is to have a look into the IEEE 11073:10207: Domain Information and Service Model for Service-Oriented Point-of-Care Medical Device Communication (BICEPS). The BICEPS model describes various aspects of the medical devices. It details what information is available. It explains how interaction will occur from a high-level perspective.
BICEPS addresses 3 different aspects:
- a Participant Model, representing all the medical devices inside a SDC network, including information and interactions it does offer
- a Communication Model, which does describe what kind of services and messages must be provided to exchange model information and doing interactions between devices, like data reading or manipulation
- a Discovery Model for defining a informational protocol how a device enter or leaving the distributed SDC network and how other devices get acknowledged of each others availability
From a technically point of view this standard gives you a nomenclature and semantics. For the models and messages it does offer XML schemes including semantics for its elements. The XML schemes can be downloaded for free (https://standards.ieee.org/wp-content/uploads/import/download/11073-10207-2017_downloads.zip). However, it lacks detailed specifications. It does not explain how the services are implemented. It also does not describe how the discovery takes place in a technical way. These open topics are handled by the other two core standards.
IEEE 11073:20702: Medical Devices Communication Profile for Web Services (MDPWS)
BICEPS defines nomenclature and semantics. However, it does not define how device discovery, messaging, and event propagation are actually to be implemented. This standard was created to answer these open questions.
While not reinventing the wheel this standard is more of a specialization of already existing and proved standards. The introduced new standard is the Medical Devices Communication Profile for Web Services (MDPWS). It completely relies on the existing Devices Profile for Web Services (DPWS) standard as a communication foundation. One of the main additions is the introduction of protocols for stream advertisement, which are called Waveforms in this context. Relying on standards like DPWS and Soap Web Services can be annoying from today’s perspective. SDC was introduced in 2018 and developing and evolving standards on medical devices takes a lot of time. So relying on old but well proven technologies is understandable.
IEEE 11073:20701: Point-of-care medical device communication — Service oriented medical device exchange architecture and protocol binding
This standard does combine the other two and completing the core SDC standard. It acts as some kind of glue between the other core standards. It brings them all together and completes the core standard. It does introduce several things:
- Completing the BICEPS communication model with a technical definition via a Web Service API (a WSDL File is provided) which does implement the BICEPS communication model
- Requires the usage of IEEE 11073:1010X Coding Systems standards when addressing medical metrics (standard code tables for different medical KPIs and units)
- Defines Flows and constraints for using the services and discovery mechanisms a device does offer
- Define non-functional quality requirements about security and safety
Wrap Up
With SDC it is possible to allow medical devices to build up a more sophisticated overall system. SDC does consists of a whole bunch of standards which make it hard to get into it. We have given an overview about the core standards and how do they relate to each other. In this followup blog post , we will examine parts of these standards more deeply. This will help build up an understanding of how they work in detail.