Article

Service-oriented Device Connectivity (SDC) for Medical Applications

Medical Devices

3/23/2025

Introduction

The healthcare industry has long faced challenges with medical device interoperability. Manufacturers often develop proprietary solutions that create isolated ecosystems, making it difficult to integrate devices from different vendors.

The IEEE 11073 Service-oriented Device Connectivity (SDC) family of standards aims to solve this problem by enabling manufacturer-independent medical device interoperability.

This article explores the theoretical foundations of SDC and demonstrates its practical applications in healthcare settings, also considering security risks.

The Interoperability Challenge in Healthcare

Medical device integration remains a significant challenge in healthcare settings, particularly in high-acuity environments like operating rooms (ORs) and intensive care units (ICUs). Clinicians need solutions that facilitate the integration of medical devices, IT systems, and software from multiple vendors. This integration must allow for independent innovation and product life cycles through loose coupling of individual components while providing increased flexibility over proprietary solutions with predefined clinical functionality.

Traditional approaches to device connectivity have resulted in vendor-specific isolation, making it difficult or sometimes impossible to integrate the entire device chain at the point of care. While many vendors have developed their own proprietary solutions to interconnect their devices, this fragmentation limits the potential for comprehensive integration.

Fundamentals of IEEE 11073 SDC

The IEEE 11073 SDC standards family was developed to address these interoperability challenges. SDC is a web services-based architecture that enables secure and dynamic networking of distributed Point-of-Care medical devices and medical IT systems. It allows SDC-enabled medical devices to communicate with each other bi-directionally and interchange data using a standardized communication nomenclature.

SDC was envisioned and developed by OR.NET, a non-profit organization bringing together industrial specialists, clinicians, and researchers [1]. Major medical device manufacturers are among its members and have contributed to the efforts that resulted in the SDC standards published by the IEEE. "SDC Conformance Principles" is a complimentary document provided by OR.NET [2].

The architecture of the IEEE 11073 SDC standards family is optimized for the advanced requirements of high-acuity environments. It enables the integration of relevant devices, applications, and hospital IT systems while providing reliable multi-directional data exchange, which can include remote control of medical devices.

Service-Oriented Architecture Approach

SDC is based on the paradigm of a service-oriented architecture (SOA). In this model, devices are encapsulated as services, analogous to enterprise services in SOA, to create interoperable virtual devices (device services). This approach overcomes interoperability issues by abstracting the manufacturer-specific device interfaces behind standardized service interfaces.

The main advantage of this service-oriented approach is that neither the service consumer nor the programmer needs to know the manufacturer-specific device interface, as it is encapsulated by a standardized service interface. This enables the extension of IT-supported medical processes by devices and allows new functionalities to be added to the device service that are logically related to the device but not offered by the device itself.

SDC Architecture and Components

The IEEE 11073 SDC family of standards comprises three main parts: Core Standards, Participant Key Purpose (PKP) standards, and Devices Specialisation (DevSpec) standards.

Core Standards

The Core Standards consist of three essential components:

ISO/IEEE 11073-20702 Medical Devices Communication Profile for Web Services (MDPWS): This transport standard ensures technical interoperability by utilizing Web-Services standards. It provides a transport mechanism for various payloads that need to be exchanged between medical devices. Based on OASIS DPWS, it includes safety measures for use in medical devices. OASIS DPWS is a standard that defines a minimal set of implementation constraints to enable secure Web Service messaging, discovery, description, and eventing on resource-constrained devices. The DPWS specification was initially developed by Microsoft and later submitted for standardization to OASIS (Organization for the Advancement of Structured Information Standards). MDPWS defines extensions/restrictions to DPWS for safety-critical environments (e.g., mandatory encryption, time synchronization, and QoS requirements).
ISO/IEEE 11073-10207 Domain Information and Service Model (BICEPS): This standard provides the building blocks for modeling the network representation of real-world medical devices. BICEPS stands for "Basic Integrated Clinical Environment Protocol Specification". It is structured as a tree, where higher-level nodes denote components of a participant and leaf nodes represent metrics, i.e., parameters such as measurements and settings. The BICEPS model describes various aspects of the medical devices, detailing what information is available and how interaction will occur from a high-level perspective. BICEPS defines both a Participant Model (device data structure), a Communication Model (service interactions like data exchange and remote control), and a Discovery Model (dynamically join, leave, and detect each other in an SDC network). BICEPS enables semantic interoperability through standardized nomenclature, and is agnostic to technology-implementation capabilities.
ISO/IEEE 11073-20701 Architecture and Protocol Binding: This standard combines the other two standards and completes the core SDC standard. It acts as a kind of glue between the other core standards, bringing them all together. It introduces a Web Service API that implements the BICEPS communication model, requires the usage of IEEE 11073-1010X Coding Systems (Nomenclature) standards, defines flows and constraints for using services and discovery mechanisms, and defines non-functional quality requirements about security and safety. Time Synchronization is an important aspect: it binds to Network Time Protocol (NTP) for coordinated device timing. Quality of Service (QoS) is implemented via Differentiated Services (DiffServ) to prioritize critical medical data traffic.

Base Participant Key Purposes (PKP)

The IEEE 11073-10700 Base PKP standard defines the foundational "Base Participant Key Purposes (PKP)" layer for SDC implementations. This intermediary layer serves as the cornerstone for safe, interoperable medical device networks in acute care environments like operating rooms. It aims also at facilitating the approval process for interconnected medical devices from different manufacturers.

PKPs are independent of particular medical devices and their concrete medical use cases. However, they restrict the IEEE 11073 SDC Core standards to enable safe and interoperable medical device systems and to facilitate the regulatory approval process.

The IEEE 11073-10700 Base PKP is supported by:

ISO/IEEE 11073-10701 Metric Provider/Consumer: Provides and consums information in terms of metric data. It was published on September 13, 2024, with a focus on enabling safe, effective, and secure interoperability in acute care environments. It addresses both product development processes and technical requirements for SDC metric participants.
IEEE P11073-10702 Alert Provider/Consumer: Addresses providing and consuming alerts. This standard is still under development, with balloting expected in late 2024 and publication projected for mid-2025.
P11073-10703 External Control Provider/Consumer: Covers providing and consuming external control functionalities. This standard is also still under development, with no confirmed publication date.

Modular Specifications (ModSpecs) and Device Specializations (DevSpecs)

In contrast to PKPs, the DevSpecs are standards for particular classes of medical devices. They describe how the devices are modeled in the network representation and define requirements for the interaction of provider and consumer via SDC when necessary.

New standardization layers enable targeted implementations that reside under the umbrella of the P11073-10720 ModSpecs standard, which as a separate standard has not yet achieved final approval and publication.

ModSpecs (P11073-10720): These define modular, reusable elements that can be shared across multiple DevSpecs. For example, they may include common components like user interaction elements (e.g., foot switches) or other functionalities that are applicable to various device classes. The purpose of ModSpecs is to promote reusability and consistency across different device specializations.
DevSpecs (P11073-1072X series): These are specific standards for particular classes of medical devices, such as high-frequency surgical equipment or endoscopic devices. DevSpecs describe how a specific type of medical device is represented in a networked environment and define its interaction requirements. DevSpecs can incorporate modules from ModSpecs where applicable to avoid redundancy and ensure standardization.

The approach of DevSpecs enhances reusability by defining aspects that multiple device classes have in common, and helps to streamline the development of DevSpecs for specific medical device types. Current development includes DevSpecs for High-Frequency Surgical Equipment, endoscopic camera and light source and insufflators.

SDC in Comparison with Other Medical Standards

The IEEE 11073 SDC standards integrate well with Health Level Seven (HL7) and DICOM. While SDC provides unique capabilities such as bidirectional device communication, alert management, and external control, gateways may leverage HL7 version 2 and HL7 Fast Healthcare Interoperability Resources (FHIR) for retrieving administrative data and for reporting to clinical information systems, as well as DICOM for medical imaging.

SDC now challenges proprietary systems of connected medical devices by providing a manufacturer-independent ecosystem for interoperable participants based on layered sets of requirements to support a wide range of use cases and deployment scenarios.

Practical Applications in the Operating Room

SDC has been successfully implemented in operating room environments, enabling manufacturer-independent interoperability between medical devices.

Case Studies and Implementations

A project at the Innovation Center for Computer-Assisted Surgery (ICCAS) at the University Clinic Leipzig, Germany, played a key role in the definition and implementation of SDC [3]. In 2022 the first medical devices utilizing this technology have become available on the market from leading medical technology manufacturers. The first European hospitals began integrating the technology into their daily operations in the same year.

One notable implementation is a telemedical supervision system for anesthesiology that enables remote patient monitoring and communication between anesthesia providers and supervisors. The system includes connected medical devices via SDC, a central anesthesia workstation (AN-WS), and a mobile remote supervision workstation (SV-WS). It allows for audio/video connections and text chatting between workstations and enables the supervisor to switch between cameras in the OR [4].

Another study evaluated the latency of an SDC-based tracking system, using two real-time Linux systems as consumer and provider, an atracsys fusionTrack500 tracking camera, and a single infrared LED as a fiducial. The results showed that even with additional devices and simulated data traffic on the network, the latency remained acceptable for most navigational tasks, with mean latencies ranging from 14.4 ms to 19.8 ms across different test scenarios [5].

Medical Devices Implementing SDC

Major medical device manufacturers like Dräger are implementing SDC in their patient monitors, anesthesia machines, and intensive care ventilators to enable information exchange with other point-of-care devices for optimal therapy decisions [6].

Before SDC, point-of-care devices with network capability would typically connect only to their own proprietary networks.

Security in SDC Environments

Security is a critical aspect of SDC implementations, especially considering the sensitive nature of medical devices and patient data.

Security Architecture in SDC

The IEEE 11073-20701 standard defines security requirements for SDC implementations. It mandates secure channels for end-to-end communication between SDC participants using mutual TLS with X.509v3 certificates, leveraging Public Key Infrastructure (PKI) trust. SSL and TLS 1.0, TLS 1.1 are explicitly prohibited, while the highest TLS version (e.g., TLS 1.3) is recommended. Trust between SDC participants is established through mutual verification of the certificate chain, ensuring proper authentication and authorization. An X.509 certificate ensures that the public key used in asymmetric encryption genuinely belongs to the entity it claims to represent by verifying its identity through a trusted Certificate Authority (CA).

Certificates should include the device's Unique Device Identifier (UDI) in the Common Name field to support allow/deny lists. Public Key Infrastructure (PKI) is used to manage cryptographic keys and digital identities. Authorization is enforced via Extended Key Usage (EKU) in the X.509 Certificate, which restricts access to specific device functions, such as Participant Key Purposes.

It's important to note that while SDC standards cover communication security, network-layer access control (e.g., port blocking) is outside their scope and must be implemented separately.

Threat Modeling for Connected Devices

When evaluating security risks in SDC implementations, it's essential to adopt a "hostile ecosystem" mindset. This means assuming attackers could be anywhere in the network and that medical devices should not trust other connected devices implicitly. The security of one device should not depend on the security of another in the network, and each device should provide sufficient security to protect against direct attacks or chaining of attacks.

Threat modeling could utilize a qualitative approach or by applying the CVSS (Common Vulnerability Scoring System) to rate the exploitability and severity of identified threats. The STRIDE model (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) provides a framework for categorizing threats and identifying appropriate mitigation controls.

Security Mitigation Techniques

Several mitigation techniques should be considered for securing SDC implementations:

Authentication: External devices must authenticate themselves using X.509 certificates
Digital signature: Secure Boot implementation
Authorization: Device role as part of the certificate
Encryption: AES-256 encryption for data at rest, TLS 1.3 for data in transit
Filtering: Implementation of allow-lists
Input validation: Validation of data received from external devices
Audit trail: Security event logging

Implementation Challenges and Benefits

Implementing SDC in medical devices presents both challenges and benefits that need to be carefully considered.

Challenges

One of the main challenges in implementing SDC is the lack of visibility and inventory capabilities for medical devices in healthcare ecosystems. Medical IoT, IoT, and smart devices often don't support inventory agents and are frequently missed by network discovery scans, making it difficult for security teams to get a clear understanding of their true risk.

There are also inherent security control limitations for medical devices. While traditional enterprise devices support a host of security tools, many medical devices run proprietary operating systems that do not support agents. Even devices running mainstream operating systems like Windows are often certified by vendors with specific configuration parameters, making it impossible to use traditional agent-based security tools or install native security patches without risking unresponsiveness or unexpected behavior that could impact patient safety.

Benefits of SDC

Despite these challenges, SDC offers significant benefits:

Manufacturer-independent interoperability: SDC enables medical devices from different manufacturers to communicate and work together, breaking down the silos created by proprietary solutions. Secure communication: SDC implementations use mutual authentication to ensure that only approved devices and systems can interact, while transmitted data is encrypted to protect hospital assets and patient information.
Dynamic scalability: Devices can connect to create a dynamically scalable system based on fundamental risk management and approval concepts.
Enhanced clinical functionality: By enabling device-to-device communication, SDC supports the development of advanced clinical functionalities that span multiple devices, potentially improving patient outcomes and clinical workflows.

Checklist by the German Notified Bodies

The German Notified Bodies Alliance ("Interessengemeinschaft für Benannte Stellen der Medizintechnik in Deutschland") has very recently published a helpful questionnaire [7] to ensure that interoperability such as SDC is considered before the medical device is brought into the market. Here an excerpt of some of the checklist questions:

Do the reviews cover also interoperability issues at each stage during development?
Are there dedicated provisions for interoperability verification to give objective evidence, that the interface works according to the specification?
Have minimum requirements concerning hardware been specified?
Have minimum requirements concerning IT networks characteristics been specified?
Have IT security measures, including protection against unauthorized access been specified?
Has the manufacturer specified the extent the Health Delivery Organization (HDO) has to perform system integration verification and confirmation?

Conclusion: The Future of Medical Device Connectivity

The IEEE 11073 SDC standard represents a significant advancement in medical device interoperability, addressing long-standing challenges in connecting devices from different manufacturers. By adopting a service-oriented architecture approach, SDC enables secure, effective, and efficient communication between medical devices, supporting the development of integrated systems that can improve patient care and clinical workflows.

For medical device companies looking to participate in SDC, understanding both the theoretical foundations and practical applications of the standard is essential. This includes knowledge of the core standards (MDPWS, BICEPS, and the Architecture and Protocol Binding), the safety risk management process according to ISO 14971, and security risk considerations specific to connected medical devices.

As more manufacturers adopt SDC, the potential for truly integrated medical systems will continue to grow, leading to innovative solutions that can enhance patient care, clinical efficiency and safety.

References:

[1] OR. NET e.V. https://ornet.org/

[2] https://ornet.org/wp-content/uploads/2019/05/20190208-D2.1-SDC-Conformance-Principles.pdf

[3] https://www.uniklinikum-leipzig.de/presse/Seiten/Pressemitteilung_7772.aspx

[4] Concept and development of a telemedical supervision system for anesthesiology in operating rooms using the interoperable communication standard ISO/IEEE 11073 SDC, J. Roth et al., De Gruyter, October 25, 2024

[5] Integrating a Tracking Camera in the OR Using the IEEE 11073-SDC Communication Standard, M. Vossel et al., EPiCSeries in Health Sciences, Volume 3, 2019, Pages 409-414

[6] https://www.draeger.com/en_in/Hospital/Medical-Device-Interoperability/SDC-Service-Oriented-Device-Connectivity

[7] Questionnaire “Interoperability of Medical Devices”, IG-NB, (Version 1, 28.01.2025), can be downloaded from https://www.ig-nb.de/veroeffentlichungen

Go back