Diabetes device interoperability is the ability of glucose sensors, insulin pumps, dosing algorithms, apps, and health record systems to exchange data and use it safely. FDA defines medical device interoperability as “the ability to safely, securely, and effectively exchange and use information among one or more devices, products, technologies, or systems.” In diabetes care, that exchange is what turns a CGM, a pump, and an algorithm from different companies into one automated insulin delivery (AID) system, and what puts a patient’s glucose data in front of their clinician.
This guide explains how interoperability works layer by layer, which standards apply at each layer, what FDA expects from interoperable devices, and how device makers can build for it from the start.
What diabetes device interoperability covers
Interoperability is not a single connection but a chain of connections. Each link has its own standards, risks, and owners.
Layer | What connects | Typical technology |
|---|---|---|
Device to device | CGM, insulin pump, and dosing algorithm | Bluetooth Low Energy, manufacturer interface specifications |
Device to app | Sensor or pump to a phone app | Bluetooth Low Energy, Bluetooth SIG services, IEEE 11073 |
App to cloud | Phone app to a manufacturer or third-party platform | Secure web APIs, cloud data models |
Cloud to EHR | Platform to the clinic’s electronic health record | HL7 FHIR, LOINC codes, SMART on FHIR |
Early artificial pancreas systems were built mostly within a single company. Today, a sensor from one manufacturer, a pump from a second, and an algorithm from a third can work together, because the FDA created classifications for interoperable components. For the market view of who builds what, see our guide to the diabetes technology ecosystem.
Why interoperability matters
Interoperability gives each stakeholder something different:
- People with diabetes can choose the sensor, pump, and algorithm that suit them, without giving up automation. One person may prioritize preventing lows, another tighter control.
- Clinicians can see device data inside the tools they already use, rather than logging into a separate portal for each brand. See why EHR interoperability matters for care teams.
- Device makers can focus on what they do best and reach more users through partners’ systems.
- AI and analytics depend on accurate, consistent data. Fragmented formats and missing context limit what predictive models can do.
The standards map: which standards apply where
Diabetes interoperability draws on general wireless and health IT standards, plus a few built specifically for glucose and insulin data.
Standard | Layer | What it covers | Status |
|---|---|---|---|
Bluetooth SIG Glucose Service (GLS) and Glucose Profile | Device to app | Glucose readings from a personal glucose sensor, such as a meter | Adopted; GLS v1.0 in 2012, v1.0.1 in 2022 |
Bluetooth SIG Continuous Glucose Monitoring Service (CGMS) and Profile (CGMP) | Device to app | Glucose and related data from a personal CGM sensor | Adopted; CGMS v1.0 in 2014, v1.0.2 in 2022 |
Bluetooth SIG Insulin Delivery Service (IDS) and Profile (IDP) | Device to app | Status and control of an insulin delivery device | Adopted; IDS v1.0 in 2018, v1.0.1 in 2022 |
IEEE 11073-10425 | Device to app | Personal health device specialization for CGMs | Published 2019 |
IEEE 11073-10417 and 11073-10419 | Device to app | Device specializations for glucose meters and insulin pumps | Published 2023 and 2024 |
IEEE 11073-20601 | Device to app | Optimized exchange protocol for personal health devices | 2022 edition; FDA-recognized consensus standard |
ITU-T H.810 (Continua Design Guidelines) | Device to cloud | End-to-end guidelines for personal connected health | Version 5, 2019 |
HL7 FHIR CGM Implementation Guide | Cloud to EHR | CGM summary reports, metrics, and readings sent to the EHR | STU 1, published September 2025 |
LOINC | Cloud to EHR | Codes for CGM metrics such as time in range and glucose management indicator | Active |
USCDI v3 | Cloud to EHR | Baseline data set for certified health IT in the US | Required baseline from January 1, 2026 |
ANSI/AAMI/UL 2800-1 | System | Safety standard for medical device interoperability | Published 2019 |
IEC 80001-1 | System | Risk management for IT networks that include medical devices | Edition 2, 2021 |
Two caveats matter in practice. First, standards rarely cover everything a dosing system needs, so commercial AID integrations also rely on interface specifications that each manufacturer shares with its partners. FDA requires ACE pumps and iAGCs to have a process for sharing those specifications. Second, a standard only helps if both sides implement the same version, so pin versions in your interface agreements.
What FDA expects from interoperable devices
FDA addresses interoperability in two places: a general guidance for any interoperable device, and specific special controls for diabetes components.
FDA’s interoperable medical devices guidance
FDA’s final guidance, Design Considerations and Pre-market Submission Recommendations for Interoperable Medical Devices (September 2017), asks manufacturers to deliberately design each electronic interface. It lists six design considerations:
- The purpose of the electronic interface
- The anticipated users
- Risk management
- Verification and validation
- Labeling
- Use of consensus standards
In a premarket submission, FDA expects “a discussion of each externally-facing electronic interface found on the device,” covered in the device description, risk analysis, verification and validation, and labeling.
Special controls for diabetes components
The classifications for iCGMs, ACE pumps, and iAGCs go further. Their special controls spell out how these devices must communicate.
Requirement | iCGM (21 CFR 862.1355) | ACE pump (21 CFR 880.5730) | iAGC (21 CFR 862.1356) |
|---|---|---|---|
Reliable, secure data transmission | Required: a “detailed strategy to ensure secure and reliable means of iCGM data transmission” | Required | Required |
Validated interface specifications | Not specified | Required | Required |
Secure authentication (pairing) | Not specified | Required | Required |
Process for sharing interface specifications with connected devices | Not specified | Required | Required |
Safe operation when communication fails or data is out of bounds | No clinically significant data gaps that would stop connected devices from working | Required | Required |
Postmarket responsibilities across companies | Not specified | Not specified | A plan for assigning postmarket responsibilities, including adverse event reporting |
The full text is in 21 CFR 862.1355, 21 CFR 880.5730, and 21 CFR 862.1356. For how FDA reviews the dosing algorithms themselves, see our guide to AI in diabetes devices. Connected devices also face cybersecurity requirements: a device with software capable of connecting to the internet is likely a “cyber device” under section 524B of the FD&C Act. See our guide to medical device cybersecurity.
Getting diabetes device data into the EHR
A person with diabetes may see several providers and use several devices, so their data often ends up in disconnected systems. Clinicians then work from partial information, or spend visit time compiling reports by hand. Three developments are changing that.
- iCoDE. The Diabetes Technology Society’s iCoDE project (Integration of Continuous Glucose Monitoring Data into the Electronic Health Record) published consensus standards for CGM-EHR integration in its 2022 iCoDE Report. It was described as the first consensus standard for integrating data from a wearable device into the EHR. A follow-up project, iCoDE-2, focuses on insulin delivery data.
- HL7 FHIR CGM Implementation Guide. Published by HL7 International as STU 1 in September 2025, the guide “provides a standardized approach for sharing Continuous Glucose Monitoring (CGM) data between actors.” It covers summary reports, metrics such as mean glucose, time in range, and glucose management indicators, and individual sensor readings, with a defined way for apps to submit data to the EHR.
- LOINC codes for CGM metrics. Standard codes now exist for key metrics, such as 97510-2 for time in range and 97506-0 for glucose management indicator, so every system can label the same number the same way.
Federal rules are also raising the baseline. Under ONC’s HTI-1 rule, USCDI v3 became the data standard baseline for certified health IT on January 1, 2026. CMS’s Interoperability and Prior Authorization final rule requires many payers to support new APIs, generally beginning January 1, 2027. For device makers, the practical step is to map your data to the FHIR CGM guide and LOINC codes now, so health systems can take it in without custom work.
Why interoperability is still hard
Even with standards and clear FDA expectations, diabetes interoperability projects run into the same six problems.
Challenge | What goes wrong | How to address it |
|---|---|---|
Gaps in standards | General standards lack diabetes-specific detail, so partners fill gaps with their own specifications | Use published standards first, then document every extension in a versioned interface specification |
Data volume and timing | CGMs produce continuous readings, and dosing decisions depend on timely, synchronized data | Define latency, gap handling, and time-stamping rules in the interface specification |
Regulatory scope | Regulators look at system-level safety, not just each device | |
Cross-company collaboration | Partners differ on timelines, data models, and testing practices | Agree on a shared integration plan, test protocol, and change process before development starts |
Testing and validation | Each component must work alone and in every supported combination | Build a combination test matrix and automate regression testing; see software validation for SaMD |
Postmarket synchronization | Firmware updates, app releases, and security patches can break compatibility | Coordinate release schedules and require compatibility testing before any partner ships an update |
Privacy rules add another layer. Data that flows to clinicians may fall under HIPAA, and data from EU users falls under GDPR.
How to build for interoperability
These steps help device and software teams design interoperability in rather than add it later.
- Map every interface. List each external connection your product will have, from Bluetooth links to cloud APIs, and its purpose, users, and risks, following FDA’s six design considerations.
- Choose standards by layer. Use Bluetooth SIG services or IEEE 11073 at the device level, and HL7 FHIR with LOINC codes at the EHR level, before writing any custom code.
- Write a versioned interface specification. Document data formats, timing, error handling, and pairing, and plan how you will share them with partners, as required by ACE pump and iAGC special controls.
- Design a modular architecture. Separate device communication, algorithms, data storage, and user interface so you can add partners without rebuilding. See component architecture for SaMD and the role of software development kits.
- Build security in. Authenticate every connection, encrypt data in transit and at rest, maintain a software bill of materials, and plan for post-market vulnerability management.
- Validate the system, not just the device. Test every supported combination, including failure cases such as lost connections and out-of-range data.
- Agree on postmarket responsibilities. Decide in writing who handles complaints, adverse event reports, and updates when a problem crosses company lines.
- Plan for EHR delivery. Map your summary data to the HL7 FHIR CGM Implementation Guide so clinicians can see it in their own systems.
When several companies are involved, a neutral partner can coordinate shared specifications, integration testing, and regulatory alignment, so no single company’s priorities slow the others.
Frequently asked questions
What is diabetes device interoperability?
It is the ability of glucose sensors, insulin pumps, dosing algorithms, apps, and health record systems to exchange data and use it safely. It lets components from different companies work together in automated insulin delivery systems, and lets device data reach clinicians in the EHR.
Which standards are used for CGM and insulin pump data?
At the device level, the main standards are the Bluetooth SIG Continuous Glucose Monitoring, Glucose, and Insulin Delivery services, and the IEEE 11073 personal health device standards. For sending CGM data to the EHR, the HL7 FHIR CGM Implementation Guide and LOINC codes define the format.
What does FDA require for interoperable medical devices?
FDA’s 2017 guidance asks manufacturers to address each electronic interface’s purpose, users, risks, verification and validation, labeling, and use of standards. For diabetes components, special controls for ACE pumps and iAGCs also require validated interface specifications, secure pairing, reliable data transmission, and a process for sharing specifications with partners.
How does CGM data get into the EHR?
Typically, a CGM app or cloud platform sends summary reports and metrics to the EHR through a FHIR interface. The HL7 FHIR CGM Implementation Guide, published in September 2025, standardizes that exchange, building on the Diabetes Technology Society’s iCoDE consensus standards and LOINC codes for CGM metrics.
What is the HL7 FHIR CGM Implementation Guide?
It is an HL7 International standard, published as STU 1 in September 2025, for sharing continuous glucose monitoring data. It defines how to exchange CGM summary reports, metrics such as time in range and glucose management indicators, and individual sensor readings between apps, platforms, and EHRs.
Build interoperable diabetes software with Sequenex
Interoperability now decides which diabetes products reach users and clinicians. Building it in from the first requirement is far easier than retrofitting it after a partner asks.
Sequenex helps device makers and their partners define shared interface specifications, build modular software, and validate the combined system. See our biosensor and CGM software development services, or contact us to discuss your integration.
