Abstract
Background:
Interoperability is a critical enabler for integrated Personalized Diabetes Management (iPDM), automated insulin delivery (AID), and the digital transformation of healthcare in general. However, manufacturers still create closed ecosystems (ie, solutions designed to work end-to-end minimizing collaboration with other organizations) with proprietary interfaces because of various interoperability challenges. Therefore, the aim of this article is to provide an overview of how to achieve organizational interoperability in an open ecosystem (ie, solutions designed to integrate different organizations via interoperability standards) for diabetes management.
Methods:
The proposed interoperability design approach called Secure Plug and Play Interoperability (SPPI) supports building and using interoperable system elements in an open ecosystem. Secure Plug and Play Interoperability enables interoperability over the entire system life cycle with its reference architecture, secure interoperability standards, and organizational capabilities. These standards were developed with participation from healthcare providers, regulatory authorities, payers, academia, and manufacturers. Publicly available information provides examples of implementation support and practical usage.
Results:
Organizational interoperability in an open ecosystem can be achieved through organizational capabilities and a selection of secure interoperability standards. ISO/IEEE 11073, Bluetooth profiles, and HL7 FHIR with test specifications, test tools, software development kits, and quality assurance programs represent a coordinated selection suitable for building an open ecosystem. Practical usage is demonstrated with real-world solutions that build on these standards.
Conclusions:
Secure Plug and Play Interoperability facilitates the end-to-end integration of devices, digital products, and services from partners in an open ecosystem. Moreover, even a single manufacturer, who provides all system elements of a solution, can use and benefit from SPPI.
Keywords
Introduction
Diabetes is one of the fastest-growing global health emergencies. According to the International Diabetes Federation Diabetes Atlas 2021, 1 approximately 537 million (one in ten) adults aged 20 to 79 years are living with diabetes worldwide. This number is projected to reach 643 million (one in nine) by 2030 and 783 million (one in eight) by 2045. Of these people living with diabetes in 2021, approximately 44% were undiagnosed and 6.7 million (one in every five seconds) died because of diabetes. Thus, the World Health Organization (WHO) 2 reports diabetes among the top 10 causes of deaths worldwide.
Diabetes management is complex, personal, and achieving therapy goals is an ongoing challenge. Integrated Personalized Diabetes Management (iPDM) 3 is the key to limit progression of the disease,4-9 strengthen patient-healthcare provider (HCP) collaboration,4,6,7,9 and to improve outcomes to contribute to healthcare system sustainability.4-7 The elements of iPDM are depicted in Figure 1. Patient-relevant data, combined with an intelligent platform, can transform data into personalized insights and improve outcomes. The people with diabetes and the involved groups receive the information that they need for optimal care. Interoperability enables iPDM, allowing solutions to come together in an open ecosystem (ie, solutions designed to integrate different organizations via interoperability standards).10-12
Elements of integrated Personalized Diabetes Management (iPDM).
Another example where interoperability is an important enabler is automated insulin delivery (AID) systems with system elements from different manufacturers. An AID system consists of an insulin pump, a continuous glucose monitor (CGM), and an AID algorithm (eg, algorithm embedded in the insulin pump, algorithm in an app on smartphone) as depicted in Figure 2. Automated insulin delivery systems showed in studies and meta-analyses the improvement of glycemic control, time in range, and quality of life. 13
System elements of a multi-manufacturer AID system.
In this context, interoperability is the ability of two or more system elements (ie, devices, digital products, services) from the same or different manufacturers to exchange information and use the information.14-16 Interoperability is a critical enabler for the digital transformation of healthcare.16,17 The two primary goals of healthcare interoperability are to (1) provide secure, timely, and seamless portability of information and (2) optimize health outcomes for individuals and populations. 12 The benefits of interoperability include the following:16,18
Advanced clinical decision support. Ready-to-use patient-centric information facilitates advanced clinical decision support in both diagnostics and treatment.
Care coordination. Sharing data in uniform formats accessible to all care teams enhances care coordination.
Patient empowerment. Providing patients with access to their health data empower them to actively manage their conditions.
Improving business and administrative processes. Operational data streamline workflows and support outcome-driven improvement cycles.
Value-based care. Population-level data analysis is crucial for managing high-risk patients and public health. Access to longitudinal health data reduces duplicate testing and closes information gaps.
Within and across organizations, standards enable interoperability. Standards are published documents that establish a mutually agreed-upon course of action. From proven practices to requirements, standards help ensure a common approach and repeatable outcome in the design and development of solutions. 19 There are four levels of interoperability building on each other and supported by different kinds of interoperability standards as described in Table 1. 18
Interoperability Levels and Standards.
Some standards from standards development organizations (SDOs), like the International Organization for Standardization (ISO) and the Institute of Electrical and Electronics Engineers (IEEE) Standards Association, are de jure standards (ie, legally recognized). Other specifications come from leading technology organizations, such as the Bluetooth Special Interest Group (SIG) and the USB Implementers Forum (USB-IF), which are de facto standards (ie, in practice).
Regulatory authorities promote the development and availability of interoperable medical devices. For example, in the United States, there is a dedicated Food and Drug Administration (FDA) 14 guidance document for Interoperable Medical Devices. The FDA 20 has recognized various consensus standards that support healthcare device interoperability. For AID systems, the FDA created a modular class II 510(k) clearance process, so that, the manufacturers of the different system elements can develop and maintain them independently from each other:
Continuous glucose monitor according to “FDA 21 CFR 862.1355 integrated Continuous Glucose Monitoring System” (iCGM). 21
Insulin pump according to “FDA 21 CFR 880.5730 Alternate Controller Enabled Infusion Pump” (ACE pump). 22
AID controller according to “FDA 21 CFR 862.1356 interoperable Automated Glycemic Controller” (iAGC). 23
In Europe, the Medical Device Regulation (MDR) 15 and In Vitro Diagnostic Regulation (IVDR) 24 demand that devices intended to be operated together are designed and manufactured in such a way that the interoperability is reliable and safe. Guidance documents provide specific regulatory considerations for interoperability, such as hardware-software combinations, 25 cybersecurity, 26 qualification, and classification of software 27 from the same and different manufacturers. Both regulations demand that medical devices and in vitro diagnostics are state-of-the-art and standards are a source for that. 28 There are various European Standards that support healthcare device interoperability. 29 In Europe, a CGM system is classified as class IIa, an insulin pump system as class IIb, and an AID system as class III.27,30,31
With the benefits of interoperability, on one hand, two examples from outside the healthcare sector may help illustrate why the lack of interoperability is no longer acceptable. For instance, the right combination of tires, rims, air pressure, and fasteners tailored to the car model and season is crucial for driving safety. Without interoperability, only the car manufacturer’s wheels could be used, they would have to be assembled by the car manufacturer, and would likely be sold at a higher cost.
If we apply this lack of interoperability to smartphones, for example, only the smartphone manufacturer’s headphones and charger could be used with a given smartphone model. The user would not be able to choose their preferred headphones and non-reusable chargers would create unnecessary waste.
These scenarios are no longer acceptable for users and the population. The ability to combine system elements based on user needs in both the automotive and smartphone industries has been made possible through interoperability based on standards, supporting regulations, and the drive to reduce long-term costs and waste.
However, manufacturers still build closed ecosystems (ie, solutions designed to work end-to-end minimizing collaboration with other organizations) 11 with proprietary interfaces for diabetes management. In 2024, the insulin pumps of the six AID systems in the US market can only be controlled by the specific AID controller sold by the same insulin pump manufacturer. This restricts user choice to specific ACE pump and iAGC algorithm combinations along with one or more iCGMs. 32 In addition, all devices using Bluetooth technology have to declare compliance with Bluetooth Core Specification (ie, level 1 interoperability), so that, they can use the wireless technology, but so far, only one insulin pump and one CGM are Bluetooth-qualified on profile level enabling higher-level interoperability.33,34 At first glance, closed ecoystems and proprietary interfaces may be seen as an advantage because the manufacturer can build a more optimized solution for their use cases and have tighter control over it. Furthermore, if already closed ecosystems from one manufacturer have communication issues resulting in adverse events 35 and recalls,36-38 how should manufacturers even develop interoperable system elements and combine them in an open ecosystem? Security issues are also frequent with standardized interfaces, such as Bluetooth LE39-45 and Health Level Seven International (HL7) Fast Healthcare Interoperability Resources (FHIR). 46 Another challenge is that over 40 SDOs, 18 responsible for developing and maintaining health information exchange (HIE) standards, have numerous standards with overlapping use cases. Moreover, even when organizations agree on standards, they are subject to misinterpretation, potentially making system elements incompatible.
Therefore, the aim of this article is to provide an overview of how to achieve organizational interoperability in an open ecosystem. To that end, the interoperability design approach called Secure Plug and Play Interoperability (SPPI) is introduced. Secure Plug and Play Interoperability supports diabetes management by facilitating the end-to-end integration of devices, digital products, and services from the same manufacturer and partners based on secure interoperability standards. Furthermore, the article discusses interoperability challenges and how to overcome them.
Methods
Enabling an open ecosystem requires an interoperability design approach across the entire system life cycle, taking a holistic view of contradictory needs. Interoperability, for example, does not imply that unauthorized entities have full control or access to all data. Too strong cybersecurity, on the contrary, can make plug and play less useful by making user interactions more complicated (ie, decrease user experience) or even stopping interoperability when proprietary security protects an interoperable transport. Therefore, the author conceived SPPI as an interoperability design approach and contributed to underlying standards in collaboration with various stakeholders. Secure Plug and Play Interoperability based on secure interoperability standards emphasizes: 47
Secure. Cybersecurity is the process and the capability of preventing unauthorized access, unauthorized modification, misuse, denial of use, or unauthorized use of any data that are stored on, processed from, or transferred between system elements.48,49
Plug and Play. Good user experience is an integral part of SPPI. Ideally, the user (eg, patient, caregiver, HCP) only needs to approve the connection between the system elements. The involved system elements automatically communicate with each other without further human interaction. 47
Interoperability. Organizations can use secure interoperability standards to build a closed ecosystem with interoperable system elements and participate in open ecosystems when combined with organizational capabilities. 18
To address the challenge with many HIE standards and establish a foundation for SPPI, a reference architecture is applied. A reference architecture defines system elements, their relationships, common terminology, and practices using them. For SPPI, the architecture as depicted in Figure 3 was derived by the author from the International Telecommunication Union (ITU) “ITU-T H.810 Interoperability design guidelines for personal connected health systems.” 50 Unlike ITU-T H.810, the Healthcare Device Interface solely utilizes Bluetooth LE and USB to facilitate communication between healthcare devices, such as personal health devices (PHDs), point-of-care devices (PoCDs), and health and fitness (H&F) devices, or a healthcare gateway. The healthcare service interface supports exchanging data between healthcare services or with a healthcare gateway based on HL7 FHIR. 51
Healthcare end-to-end reference architecture.
Secure interoperability standards are the foundation of SPPI. These standards were developed collaboratively across healthcare providers, regulatory authorities, payers, academia, and manufacturers.19,47 Among others, the author contributed to standards for insulin pumps,52,53 CGMs,54,55 and cybersecurity48,49,56 as well as their alignment between the standardization organizations.
However, an interoperability design approach does not demonstrate implementation support and practical usage. Therefore, this article uses publicly available information combined with the author’s hands-on experience in creating interoperable solutions to provide real-world examples.
Results
To reach organizational interoperability, organizations must develop capabilities as described in Table 2. Any organization building healthcare solutions requires a certain maturity in these organizational capabilities. However, integrating system elements in an open ecosystem is much easier when they are designed for interoperability from the concept phase onward. This is where the created interoperability design approach called SPPI comes in. The SPPI design facilitates the creation of interoperable system elements suitable for closed and open ecosystems.
Capabilities for Organizational (Level 4) Interoperability Over the System Life Cycle.
System life cycle phases according to the ISO/IEC/IEEE 15288 standard for system life cycle processes. 57
Enterprise frameworks like the Open-Group Architecture Framework (TOGAF) 58 for enterprise interoperability, NIST Cybersecurity Framework (CSF) 59 for enterprise security architecture, Scaled Agile Framework (SAFe) 60 for business agility, and business process management for healthcare (BPM +Health) 61 for clinical knowledge interoperability.
Standards of care like from the American Diabetes Association (ADA) 3 and the European Association for the Study of Diabetes (EASD). 62
For more details, see Table 3.
Information visualization standards like the standard ambulatory glucose profile (AGP) report. 3
For more details, see the book “The Craft of MBSE.” 63
Secure Interoperability Standards for Health Information Exchange (HIE) Supporting iPDM.
HIE of observations.
HIE of observations, settings, and commands.
HIE of clinical, diagnostics, including observations, medications, workflow, and financial.
These terminology standards build on the corresponding content standards.
These content standards build on the corresponding transport, security, and privacy standards.
The following provides an overview of the various organizational capabilities listed in Table 2.
Planning: From organizational vision through goals, decision-makers must provide guidance to build interoperable solutions. Roadmapping then shows where the organization is today, where it wants to be, and the steps to reach those goals. An SPPI plan supports this by outlining the processes for developing and maintaining interoperable system elements throughout the system life cycle. To increase partnering capabilities, the SPPI plan should also include standard clauses for legal agreements.
Legal: Reconciling various legal aspects, such as the protection of personal health information (PHI) and the right of individuals to access their data, is crucial.64,65 Furthermore, the necessary agreements depend on the risk the system element poses. For example, to read out the logbook of a blood glucose meter, may not require a legal agreement between organizations. On the contrary, an interoperable AID system with system elements from two or more organizations necessitates legal agreements to protect the user and the participating organizations’ business interests.
Design: Manufacturers develop system element interfaces according to interoperability standards. The interface control document (ICD) is a mandatory deliverable according to the SPPI plan. The ICD offers an overview of a system element’s data communication interfaces, its security measures, and the application of interoperability standards. During the development process, Software Development Kits (SDKs) for stacks, operating systems, and services speed up the implementation and reduce mistakes. This is followed by in-field updates, which support incremental improvements to released system elements.
Testing: Manufacturers test system element interfaces against interoperability standards and test tools. The SPPI plan defines what each partner has to do for his own system element and the combination. Depending on the system element risk for the user and how much functionality of the user interface from one system element is transferred to another (eg, patch pump warnings displayed on a smartphone app), combined system design verification and validation are required (see Figure 4). Generally, manufacturers of regulated healthcare system elements must conduct quality assurance assessments with each release and at regular intervals (ie, due care). In addition, manufacturers can use certified quality assurances as evidence in regulatory filings and for customers.
Design verification and validation strategy for independent, modular system element and system integration testing.
Foundational: Provides the environment to create and maintain system elements in an open ecosystem. Secure interoperability standards are the foundation of SPPI. Members of the working groups from IEEE 11073, Bluetooth SIG, and HL7 Devices created interoperability standards. Table 3 lists ISO/IEEE 11073 standards that are FDA-Recognized Consensus Standards 20 and European Standards, 29 making them directly usable in regulatory filings. Bluetooth’s implementations of the corresponding ISO/IEEE 11073 standards are the Bluetooth profiles. In addition, implementation guides66,67 and quality assurance reduce the initial hurdle and help overcome misinterpretations of standards. While regulations and standards for security and privacy are an important starting point, ongoing quality assurance must establish processes (ie, due diligence). Moreover, identity and access management (IAM) must be established for both users (eg, OpenID Connect) and system elements (eg, X.509 certificates), which enforces security and privacy in a zero-trust environment.
Interoperability standards are broadly supported. For example, operating systems,68-70 vendors,71-75 and quality assurance programs76,77 support the healthcare device interface over USB or Bluetooth LE. The USB-IF Compliance Program and the Bluetooth Qualification Program enforce foundational interoperability. On top of that, a few diabetes management solutions are certified products, reaching semantic interoperability.33,34
The healthcare service interface with FHIR is also supported by operating systems, services, and SDKs.78-80 To ensure interoperability, a testing framework 81 and several testing platforms exist. 82 At the time of writing, two healthcare services for diabetes management had publicly declared their FHIR interface. 83
Discussion
Although the lack of interoperability is a critical obstacle in healthcare, manufacturers still create system elements with proprietary interfaces. Furthermore, both proprietary and standardized interfaces must address security and privacy concerns. Therefore, this article introduces an interoperability design approach called SPPI. Secure Plug and Play Interoperability enables up to organizational interoperability with its reference architecture (see Figure 3), organizational capabilities (see Table 2), and selection of secure interoperability standards (see Table 3).
In contrast to the reference architecture in ITU-T H.810, a healthcare device can be a PHD, PoCD, or H&F device (see Figure 3). These devices have distinct purposes, users, and regulatory considerations. Nevertheless, for an open ecosystem that should support the complete patient journey from early screening over diagnostics to monitoring and therapy, there is a need to have a reference architecture that enables data exchange between all of them. In addition, the proposed SPPI architecture combines multiple services into the healthcare service because a gateway can communicate with all of them.
Table 3 lists an aligned selection of HIE standards that enable end-to-end interoperability from a device over a gateway to a service. The Bluetooth health device profile (HDP), 84 an alternative to the listed healthcare device interface standards, is not used because iOS and Android do not support HIE over Bluetooth Classic. Even when Bluetooth GHSP 85 supports generic upload of observations, Bluetooth CGMP and IDP are selected for diabetes devices because GHSP does not support configuring CGMs or commanding insulin pumps. On the contrary, GHSP has the advantage of using MDC codes, which the FHIR code systems support. Nonetheless, this does not save gateway developers from the need to implement transcoding from the device to the service interface and mapping vital signs into Logical Observation Identifiers Names and Codes (LOINC). 86 For the service interface, FHIR 51 was preferred over HL7 v2 87 because more countries are selecting FHIR as the HIE format of choice for electronic health records (EHRs).65,88-90
To achieve organizational interoperability (see Table 2), the challenges depicted in Figure 5 must be overcome. The following paragraphs discuss these and how SPPI helps to overcome them.91,92
Interoperability challenges and how SPPI helps to overcome them.
Often raised challenges are that interoperability means “loss of control” and “security challenges.” This “fear” is unfounded when an IAM for users and system elements is in place. There are also security and privacy standards (see Table 3) that support the design and implementation of application layer security (ie, end-to-end security from the sending to the receiving application). It is particularly important to use proven security algorithms according to standards, which were checked by different people and organizations, instead of “homebrew” solutions. Moreover, open ecosystems do not have greater security challenges than closed because of Kerckhoffs’s principle stating cryptosystems should be secure, even if everything about the system is public knowledge except the key. 93
Another counterargument is “delayed productivity” because of a presumed “steep learning curve” and “more effort.” However, creating and maintaining proprietary interface specifications, test cases, test tools, and so on is also an effort. As developers use external standards, this effort decreases, making alignment easier against agreed standards, and allowing asset reuse. Furthermore, test-driven development against the interoperability test tools de-risks the development, verification, and external certification. Altogether, this reduces time to market risks.
Standards may raise “antipathy” because they are “not invented here” and therefore are not optimized for the manufacturer-specific use cases. Thus, standards are perceived as overengineered. However, interoperability standards scale without the need to re-design interfaces from scratch when the initial use cases must be extended. Consensus standards can achieve this by considering different viewpoints that aim for broader use case coverage and robustness. It is also about saving time by not reinventing the wheel. The selected HIE standards also support proprietary extensions to enable new innovative solutions that are not covered by standards, ensuring at least structural interoperability.
Teams that want to use secure interoperability standards may face the criticism of “high costs” and “no unique selling point” resulting in “no priority and no budget.” However, the “sunk costs” of a proprietary interface (eg, development costs) may prevent the manufacturer from later extending the ecosystem when they want to scale with external partners. Using interoperability standards reduces the burden for organizations to enter open ecosystems because not every proprietary interface must be implemented from scratch. Ultimately, organizations can focus on developing unique selling points and innovative solutions instead of reinventing HIE.
In addition, manufacturers are facing many challenges, and there is “no time to look into” interoperability standards or “incomplete knowledge” results in “unawareness.” However, it is more effort to onboard and train new internal people and external partners on proprietary interfaces from scratch compared with when they already have knowledge about established standards. Moreover, for those who see a standard the first time it is an investment into the future. Therefore, this article intends to provide an overview of how to achieve interoperability using SPPI with references to detailed information.
With a presumption of “no benefits” comes a “lack of willingness” in using interoperability standards. With a differentiated look at interoperability as described above, the benefits of SPPI are: 47
Enhance the confidence of patients, caregivers, HCPs, and regulatory authorities in the ability of interoperable system elements to function as intended while maintaining security.
Simplify the regulatory review process by implementing common definitions across manufacturers and using quality assurance certifications as evidence.
Reduces the effort for system integrators to change system elements and ultimately avoids vendor lock-in.
Reduces the cost of care for payers by providing proven secure interoperability, thus easing implementation and ongoing maintenance.
Help manufacturers to reduce implementation efforts, de-risk development, and improve time to market by reusing assets and focusing on innovations.
Furthermore, all participants in the open ecosystem can benefit from the network effect. Interoperability has the effect of making the network (ie, ecosystem) bigger, which increases the value of the network to users. Interoperability achieves this by increasing potential connections and attracting new participants to the network, further expanding the network. 94
An overview cannot describe all aspects of SPPI. Therefore, the references can be consulted for further information. Since organizations have to consider various aspects to participate successfully in an open ecosystem, further research and standardization should address the remaining gaps. For example, the Bluetooth GHSP should be accompanied with a “General Health Actor,” which covers command and control functionalities between gateways and devices. This, combined with standardizing the exchange of configurations from services to gateways via FHIR, could further streamline the number of HIE standards for diabetes management.
Conclusions
Interoperability is a critical enabler for diabetes management and the digital transformation of healthcare in general. At the same time, manufacturers face a variety of interoperability challenges while maintaining adequate security. To overcome these challenges, this article introduces an interoperability design approach called SPPI. Selecting secure interoperability standards suitable for diabetes management reduces the difficulties associated with numerous HIE standards. Security standards and IAM enforcement mitigate security & privacy challenges. In addition, implementation guides and quality assurance programs address standard misinterpretations and prevent incompatibility. Overall, secure interoperability standards with test specifications, test tools, and quality assurance programs are available to build interoperable solutions from one or more manufacturers.
Footnotes
Acknowledgements
The author thanks the members of the IEEE 11073 PHD/PoCD Working Groups, Bluetooth SIG Medical Device Working Group, and HL7 Devices Working Group for their countless efforts and support toward secure interoperability standardization. A special thanks goes to Ali Khan, Beate Buss, Bernd Schneidinger, Catalin Raduta, Chris Kelsey, Craig Carlson, Diederik den Hartog, Gabriele Chemnitius, Hans Jensen, Lane Desborough, Martin Rosner, M. Isabel Tejero-Taldo, Ralf Panse, Sabine Doerhoefer, Sheraz Docrat, Tapani Otala, Victor Fernandez Castano, and Wolfgang Handel for their constructive feedback on this article.
Abbreviations
ACP, authorization control profile; ADA, American Diabetes Association; AGP, ambulatory glucose profile; AID, automated insulin delivery; API, application programming interface; CGM, continuous glucose monitor; CGMP, continuous glucose monitoring profile; EASD, European Association for the Study of Diabetes; EHR, electronic health record; FDA, Food and Drug Administration; FHIR, Fast Healthcare Interoperability Resources; GHSP, generic health sensor profile; GLP, glucose profile; H&F, health and fitness; HCP, healthcare provider; HDP, health device profile; HIE, health information exchange; HL7, Health Level Seven International; IAM, identity and access management; ICD, interface control document; IDP, insulin delivery profile; IEEE, Institute of Electrical and Electronics Engineers; iPDM, integrated Personalized Diabetes Management; ISO, International Organization for Standardization; ITU, International Telecommunication Union; LoAs, letter of authorizations; LOINC, Logical Observation Identifiers Names and Codes; MBSE, model-based systems engineering; MDC, medical device communication; PHI, personal health information; PHD, personal health device; PHDC, personal healthcare device class; PoCD, point-of-care device; QAAs, quality assurance agreements; QMS, quality management system; SLAs, service-level agreements; SDKs, software development kits; SDOs, standards development organizations; SIG, special interest group; SPPI, Secure Plug and Play Interoperability; USB-IF, USB Implementers Forum.
Declaration of Conflicting Interests
The author(s) declared the following potential conflicts of interest with respect to the research, authorship, and/or publication of this article: Christoph Fischer is an employee of Roche Diabetes Care GmbH.
Funding
The author(s) received no financial support for the research, authorship, and/or publication of this article.
