A medical device’s user interface must be designed according to previously specified User Interface (UI) requirements, verified, and validated during the conformity assessment. The situation becomes more complex when open interoperability, according to the IEEE 11073 SDC (Service-oriented Device Connectivity) standard family, is introduced within the operating room (OR) or the clinic. SDC defines a communication protocol that enables medical devices to communicate with each other over the network by providing technical device descriptions and functionalities. In open networks, multiple types of participants are involved, where one provides device functionalities (SDC Provider), and the other consumes/uses such services (SDC Consumer). Typical use cases are remote data display or remote device control. Usability-related errors remain a leading contributor to adverse events in healthcare (1–3).

The technical documentation becomes a challenge if the SDC Consumer doesn’t have enough information from the SDC Provider. Providing private, sensitive information to third parties is not in the interest of the SDC Provider since it contains internally valuable and critical information. Nevertheless, the SDC Consumer has to develop some kind of user interface based on the provided information and their own understanding of the device. The SDC Provider has a very deep insight into its own device. Performing risk assessments and applying and providing UI Profiles can substantially harness the expertise of the Provider and mitigate potential risks for the Consumer. With this method, foreseeable risks can already be considered during the design phase and be tested against in the verification phase. This information could be provided using different methods, but so far, no standardized, machine-readable language exists to do this.

Both SDC and UI Profile usage can significantly impact patient safety and clinical workflow in the operating room. While interoperable medical device systems create use-cases, such as remote control or remote monitoring, they also introduce additional risks: Inconsistent user interfaces, mismatch between remotely displayed and device information (e.g., different units), unintuitive interfaces, or just missing essential information for safe device operation. The controls used for critical tasks need to be designed in a way to prevent accidental activation, for instance, by requiring the user to confirm critical adjustments (1) or implementing design modifications (2).

These risks can interrupt clinical workflows, increase a user’s mental workload, and overall increase the risk of human error. By embedding UI Profiles into the development and evaluation process, foreseeable device-related risks can be identified and mitigated, thereby increasing patient safety and improving clinical workflows.

Finally, a Health Delivery Organization needs testing tools and processes to operate such interoperable systems. Without those, having open SDC interoperability will still be limited to manufacturer-to-manufacturer collaborations and solutions.

The BMBF (German Federal Ministry of Education and Research) lighthouse research project “OR.NET—Secure Dynamic Networking in the Operating Room and Clinic” (2012–2016, funding no. 16KT1238) aimed to develop the technical basis for safe and dynamic networking of components in the operating room and clinic. An architecture and communication language were developed, and novel approaches for trust and distribution of responsibilities in open networked systems. The SDC Standard family consists of three parts, which will be explained in detail in the following subchapters (4, 5).

The device specializations (IEEE 11073-107XX) describe how medical devices present themselves (their available functions) in an SDC network and the technical requirements other network participants must comply with to interact with them in a safe way. So far, those device profiles do not include HMI characteristics, which are necessary for remote display and device control and especially for safe and usable interfaces. Previous work identified and addressed a need for user interface requirements (16–22).

A device-specific user interface profile was proposed, and different but very similar definitions exist to date: •

2016 from Thorn et al. (23): The UI profile describes devices’ requirements for displaying their features and functions on other devices. These are guidelines for visualizing metrics and triggering actions based on information from ISO 24752 (Universal Remote Console). However, it does not prescribe the specific design of the user interface but provides limitations and suggestions for designing the interface.

The approach from Janß et al. focused heavily on grouping, positioning items, and the technical specifications of input and output devices. This increases the chances of developing usable interfaces but may limit the design freedom of a potential user. It also contains technical restraints and proposes concrete dimensions for visual elements. This version has been overhauled to develop the current version of the UI Profile (See Figure 2 and Table 1). It now doesn’t specify user interface controls or control mechanisms but focuses additionally further requirements directly derived from risk management and (e.g., SDC-) standards (control speed, feedback mechanism, user task, update frequency, labeling, display precision, etc.) in addition to the already considered usability engineering requirements (effectiveness, efficiency, feedback, labeling) (16). We used clinical use-cases to identify device-specific UI-requirements. The use-cases included tele-supervision (24), ventilator development (25), common neurosurgery (26), and dorsal cervical decompression and spinal fusion for myelopathy treatment employing surgical navigation. The categories of the UI Profiles were iteratively presented and discussed with medical device manufacturers, designers, and software developers. Requirements from particular device standards such as the IEC 60601-2-2 for high frequency devices were also included as far as applicable.

The goal was to systematically consider requirements from the different stakeholders involved. They were also applied several times by different users on medical devices (e.g., endoscopy, high-frequency device, OR-light, infusion pump, and OR-table), and some interfaces have already been evaluated by clinical users. The formative evaluation of a user interface developed based on using UI Profiles will be part of an upcoming publication. Usability evaluations of SDC Workstations have already taken place in smaller studies (24, 27, 28).

UI Profiles specifications can be included in an early design phase and used to design a user interface that meets specifications determined by an SDC Consumer. In addition to HMI-related risks, the technical specifications of input and output devices also play a vital role. Wickel et al. proposed technical attributes (idle state, actuation force threshold, actuation area ratio, manual precision, etc.) for input devices to be included in the ISO IEEE 11073-10207 (17).

While developing a graphical user interface (GUI), a designer has to consider the user’s knowledge, expertise, goal, experience, environment, internal and external shaping factors, as well as their mental workload and other upcoming performing shaping factors.

In addition, a medical device’s GUI has to meet regulatory requirements regarding risk and usability engineering, including safety, efficiency, effectiveness, learnability, and user satisfaction, according to IEC 62366-1. The chosen UI elements heavily influence those categories. A radio button might be faster when selecting one of two options, while a dropdown might be faster for numerous options (29).

Almost all modern design guidelines have addressed the usage of GUI elements and their characteristics; examples are shown in (30–36). Those guidelines consider the number of options, the type of task, the input device, size, and additional task-related factors to create selection tables and matrices over the years, containing partly HMI-related criteria (1, 37–39).

In previous work, UI elements from those guidelines have been collected for mutually exclusive, non-mutually exclusive, and numeric selections (40). Those UI Elements have different efficiency, accuracy, and error rate characteristics while having different labels and sizes. Different studies determined some of those characteristics in 1995 (37) and 1999 (38). Since those studies were performed more than 25 years ago, a lot has changed. Tablets have higher resolutions, are more responsive, and allow for faster interaction. UI elements have simple animations during interactions, and their design has changed (e.g., rounded corners, bigger interaction fields, more compact and animated). More UI elements have been developed since then [e.g., animated toggle buttons (31), chips (33)], and some actions stemming from hardware buttons have been transferred to touchscreens (e.g., swipe, rotate, tap and hold).

Some studies use “expert knowledge” or see the rendering task as an optimization problem to determine the right UI elements, their positioning, and their grouping (41). A study to determine objective criteria to define UI elements’ efficiency, effectiveness, and error rate is currently being conducted and could, therefore, in the future, serve as a filter when choosing appropriate UI elements using the UI Profile.

SDC Communication uses a service-oriented medical device architecture (SOMDA), which has been standardized as part of the IEEE 11073 SDC Standard (42). In this chapter, we will focus on tasks, responsibilities, and requirements of different participants in the SDC Architecture. The results of several research projects and manufacturers’ efforts have been written into the SDC standards. The PKP defines a set of requirements that support manufacturers in making valid assumptions about other network participants. This enables performing risk management, verification, validation, and, therefore, risk analysis and usability engineering for the safe use of device functions. It also specifies requirements for the allocation of responsibilities (10–12).

Several meetings were conducted with the IG-NB (alliance of notified bodies for medical devices in Germany), during which concepts for risk management in open networked solutions were presented and discussed. In the latest Gemini SDPi Ecosystem Pathway Summit 03/2024, a broad set of stakeholders, including the FDA, IG-NB, 13 medical device manufacturers, and two research institutes, discussed ongoing challenges in SDC, including the regulatory pathway for market approval (43).

Figure 3 provides a high-level overview of SDC actors, their responsibilities, tasks, and where a UI Profile could be included. It shows their respective roles and their relations with each other. Directly affected participants in such a system are •

Responsible Organization (Also called Healthcare Delivery Organization)

Indirectly affected participants are •

SDC Software Stack Supplier

The primary goal of this chapter is to determine if UI Profiles are necessary, beneficial during the design and verification phase, capable of mitigating risks prior to device usage, and feasible for use in developmental stages.

To evaluate the effectiveness and practicality of UI Profiles, a questionnaire was filled out by eight medical device manufacturers who participated in the “SDPi Developer Workshop 2024” (49). The workshop was chosen since medical device manufacturers participated with experience in risk management, SDC interoperability, and usability engineering. The participation was voluntary. The questionnaire was designed to gather feedback in four key areas: the necessity of UI Profiles, their usefulness during the design process, their ability to preemptively address risks, and their feasibility for usage by the manufacturers. Pre-testing was performed with associated research assistants with experience in SDC, usability engineering, and risk management.

Each participant was asked to rate 20 statements on a Likert Scale from 1 (Strongly Disagree) to 5 (Strongly Agree). The results are displayed in Figure 4 (Need Assessment), Figure 5 (Development and Testing Phase), Figure 6 (Risk Analysis Support), and Figure 7 (UI Profile Creation Process) and provide insight into manufacturers’ views toward UI Profiles.

The integration of User Interface Profiles into the existing SDC architecture and standardization presents a pivotal advancement in medical device interoperability within the clinic and the OR. Our findings, supported by comprehensive feedback from medical device manufacturers through a questionnaire, highlight the critical need and benefits of standardized UI Profiles.

Statements regarding the “development and testing phase” received particularly positive and statistically significant ratings, suggesting that medical device manufacturers find UI Profiles especially valuable for guiding design and validation processes. By contrast, most other statements showed weaker (p < 0.10) or no statistical significance—outcomes likely influenced by a small pool of respondents rather than an absence of meaningful effects. Consequently, while these results underscore the potential benefits of UI Profiles, they also highlight the need for broader participation to solidify the statistical power and generalizability of the findings.

A majority of respondents agreed that current SDC standards lack effective methods for sharing risk-related requirements for safe device usage, highlighting the existing gap that the UI Profile aims to fill. Despite a significant reluctance to share sensitive risk management files with third parties, manufacturers still wish to limit how other SDC participants use their devices, indicating a clear need for UI Profiles.

Responses indicated high agreement that UI Profiles can serve as input for the design phase, supporting consistency and standardization. Additionally, feedback showed that UI Profiles has the potential to support risk management through the identification and mitigation of human-induced risks. However, the high percentage of neutrality (37.5%–62.5%) in the risk analysis part suggests a need for concrete and practical examples to demonstrate the benefits of UI Profiles. The participants also had reservations regarding a potential design process speed-up and the question of whether fewer formative tests would be necessary.

From a clinical standpoint, ensuring a consistent and risk-aware user interface across multiple medical devices can significantly enhance patient safety by reducing the likelihood of use errors, especially in high-stress OR environments. Standardized UI Profiles have the potential to minimize confusion arising from inconsistent labeling or UI design, and thus decrease human error rates. Furthermore, designing, verifying, and using GUI elements in line with these standardized profiles can foster the development of user-friendly, device-specific GUIs, improve efficiency, and ultimately improve patient outcomes.

By embedding such requirements into the development lifecycle, organizations can more confidently navigate regulatory pathways, demonstrating alignment with recognized international standards and focusing on patient-centered, safe device interoperability.

While our results show promise, the real-world validation of UI Profiles remains to be confirmed. We have yet to demonstrate the direct clinical impact of UI Profiles. A validation study, including user testing with actual medical personnel in a hospital environment, is currently underway and will provide empirical data on user performance, error rates, and efficiency.

By encapsulating design, risk management, and usability engineering aspects into machine-readable UI Profiles, this approach has the potential to significantly enhance the safety and usability of medical device interactions in open networks. It helps to fulfill regulatory requirements stated by the FDA, Notified Bodies for Medical Devices in Europe, and medical device manufacturers (43). This work addresses a critical gap in current interoperability standards by providing a standardized method for communicating UI requirements across medical devices, ensuring that interfaces are consistent and optimized for user needs and safety requirements.

In actual clinical applications, the use of UI Profiles prior to operation could enable device-to-device tests and provide testable and objective criteria to prevent resource conflicts, such as not having enough or suitable input, and output controls/devices (22), confirmations of critical functions prior to releasing (C-Ray, HF power) or to fulfill requirements by particular device standards (e.g., DIN EN 60601-2-2). Without those or similar UI Profiles, providing “real” interoperability becomes a challenge, since exchanging risk management and usability files are necessary to develop an MDR and FDA-compliant, safe, and usable solution.

The proposal of a concrete schema for UI Profiles marks a significant step toward achieving automated UI generation processes, supporting future dynamic creation of user interfaces that fulfill the specific requirements of various medical devices, potentially revolutionizing the way interfaces are designed and implemented in networked operating rooms.

As the UI Profile language evolves, it will be crucial to continue refining the XML-Schema to remain adaptable to the ever-changing landscape of medical technology and user needs. The collaborative efforts of medical device manufacturers, healthcare professionals, and regulatory bodies will be key in advancing this initiative, aiming for a future where medical devices not only communicate seamlessly but also contribute to safer and more effective medical device control and, therefore, better patient care.

In conclusion, the introduction of UI Profiles into the SDC architecture represents an advancement in open, interoperable, and user-centered medical device control systems. Using a standardized approach to define UI requirements, this initiative paves the way for fulfilling SDC standard requirements, mitigating risks already at the design phase, and creating safe, effective, efficient, and intuitive medical device interfaces.