Diabeloop’s FDA Clearance: The SiMD to SaMD Transformation Case Study

Diabeloop’s FDA Clearance: A Landmark Victory for the SaMD Least Burdensome Pathway 🔗

The Evolution from SiMD to SaMD: Decoupling from Hardware 🔗

Diabeloop’s first-generation product, the DBLG1 system, was a classic example of Software in a Medical Device (SiMD). The system’s powerful algorithm was hosted on a dedicated, locked-down handset that served as the central hub, communicating via Bluetooth with a continuous glucose monitor (CGM) and an insulin pump. While effective, this model meant the entire system, including the proprietary hardware, was part of the regulated medical device. This subjected the product to the full spectrum of hardware validation requirements, from electrical safety and biocompatibility to supply chain management and manufacturing controls.

In contrast, the newly cleared DBLG2 system is a masterclass in regulatory efficiency. It has been refactored as Software as a Medical Device (SaMD). The core of the product—the AI-driven algorithm—is now encapsulated in a software application that can be downloaded directly onto a patient’s personal smartphone. This seemingly simple change has profound regulatory implications.

As Diabeloop noted in its CE mark announcement for DBLG2, "The application, downloadable directly on the patient’s personal phone after a certifying training, eliminates the need for a dedicated terminal."

By shedding the dedicated handset, Diabeloop effectively decoupled its core intellectual property from the burdens of hardware manufacturing and validation. The smartphone is treated as a general-purpose computing platform, not part of the medical device itself. This strategic pivot allowed Diabeloop to focus its regulatory efforts exclusively on the software, leveraging the FDA’s progressive framework for SaMD.

A New Precedent for High-Risk, Closed-Loop SaMD 🔗

A common misconception is that the SaMD pathway is primarily for lower-risk applications, such as diagnostic aids or data analysis tools. Diabeloop’s clearance shatters this perception. The DBLG2 algorithm operates in a therapeutic closed-loop system where the stakes are incredibly high. An error in the algorithm could lead to incorrect insulin dosing, resulting in severe hypoglycemia or hyperglycemia—both life-threatening conditions.

The FDA’s decision to clear DBLG2 as a Class II interoperable automated glycemic controller (i-AGC) confirms that the agency is confident in the safety and efficacy of SaMD in a control loop for a critical life-sustaining therapy. This sets a crucial precedent for other AI/ML developers working on high-risk applications. It signals that, with robust validation, appropriate special controls, and a clear risk management framework, software can be trusted to make autonomous therapeutic decisions.

The Least Burdensome Pathway in Action 🔗

For MedTech CEOs and executive teams, the term "least burdensome" is often discussed but rarely seen in such a clear-cut example. The transition from DBLG1 to DBLG2 is a textbook case of finding a more efficient regulatory path.

Hardware is, by its nature, hard. The process of clearing a hardware-based medical device is fraught with complexities that add significant time and cost to a project:

• Electrical Safety & EMC Testing: Rigorous testing to ensure the device doesn’t interfere with other electronics or pose an electrical risk to the patient.
• Biocompatibility: For any patient-contacting materials.
• Accelerated Aging & Durability: Proving the device can withstand years of use.
• Sterilization and Packaging: If applicable, adding another layer of validation.
• Supply Chain & Manufacturing Controls: Establishing and maintaining a QMS for hardware production.

By moving to a SaMD model, Diabeloop sidestepped the majority of these hardware-specific hurdles. Their focus shifted to the core of their innovation: the software itself. This allows for faster development cycles, easier updates (facilitated by the FDA’s Predetermined Change Control Plan, or PCCP), and a dramatically lower barrier to entry for new markets. Additionally, the user experience is better because it is one less thing to carry around and keep charged.

Key Comparison: SiMD vs. SaMD Architecture 🔗

The following table breaks down the fundamental differences between the two systems, illustrating how DBLG2 sheds the hardware dependency of its predecessor.

Feature	DBLG1 System (SiMD)	DBLG2 System (SaMD)
Core Architecture	The algorithm is hosted in a dedicated handset. This handset is a piece of proprietary medical hardware.	The algorithm is a standalone mobile application that can be downloaded directly onto a patient's smartphone.
Controller Hardware	Requires a dedicated, regulated handset. This is the central piece of evidence for its SiMD classification.	Uses the patient's personal smartphone. The phone itself is not the medical device; it is a general-purpose platform running the SaMD app.
Software Delivery	Software is pre-installed and updated on the proprietary handset, managed as part of the medical device.	Software is delivered as a downloadable app, allowing for easier updates and distribution via app stores (pending regulatory approvals).
Regulatory Classification	SiMD (Software in a Medical Device). The entire system, including the handset, is the regulated device. This brings hardware validation burdens (electrical safety, manufacturing, etc.).	SaMD (Software as a Medical Device). Only the software application is the regulated medical device. This follows the "least burdensome pathway."
"All-in-One" Controller	The dedicated handset is the all-in-one controller.	The smartphone becomes the all-in-one controller, managing the pump, CGM, and loop mode.
Data Flow	Glucose data is sent from the CGM to the dedicated handset (DBLG1) for analysis.	Glucose data is sent from the CGM to the mobile application (DBLG2) for analysis.

The Future is an Interoperable Ecosystem 🔗

Finally, the i-AGC classification underscores the FDA’s commitment to fostering an interoperable ecosystem. Diabeloop is not manufacturing pumps or CGMs; it is providing the intelligence that connects them. The clearance validates their position as a reference AID partner for any pump or CGM manufacturer that adheres to the interoperability standards.

This is a powerful message for the industry: you don’t have to build everything yourself. Companies can focus on their core competencies and collaborate to bring best-in-class solutions to patients. An AI/ML startup can now realistically aim to develop a cleared therapeutic algorithm that partners with established hardware players, without ever needing to build a factory.

In conclusion, Diabeloop’s DBLG2 clearance is far more than just another algorithm entering the market. It is a strategic masterstroke that provides a clear, actionable roadmap for any AI/ML medical device company. It proves that the SaMD pathway is not only viable but is the most intelligent and least burdensome approach for bringing high-impact, software-driven innovations to patients.

Frequently Asked Questions 🔗

Does Innolitics support AI/ML regulatory submissions?

Yes. We specialize in software-intensive medical devices, including AI/ML algorithms. Our team works directly with your engineers to ensure your submission—including Predetermined Change Control Plans (PCCP)—is technically sound and compliant.

What is the Diabeloop DBLG2 system?

It is an automated insulin delivery (AID) algorithm cleared by the FDA as Software as a Medical Device (SaMD). Unlike its predecessor, it runs as an app on a patient’s smartphone rather than requiring a dedicated medical handset.

Can Innolitics help my company transition from SiMD to SaMD?

Yes. Innolitics offers regulatory strategy and pre-submission services to help manufacturers determine if their device qualifies for the SaMD pathway. We also provide "done-for-you" services to accelerate the clearance process and train internal teams on these regulatory shifts.

How does DBLG2 differ from DBLG1?

DBLG1 was "Software in a Medical Device" (SiMD), meaning the algorithm and its dedicated hardware handset were regulated together. DBLG2 decouples the software, treating the smartphone as a general-purpose platform. This removes hardware validation burdens like electrical safety testing.

What is the regulatory classification of DBLG2?

The FDA cleared it as a Class II interoperable automated glycemic controller (i-AGC). This confirms that high-risk, closed-loop therapeutic AI can be regulated as software only, provided there are robust controls.

Why is the SaMD pathway considered "least burdensome"?

It allows manufacturers to focus on validating the software algorithm without the overhead of hardware manufacturing controls, supply chain management, or physical durability testing. This accelerates development and simplifies updates.

What is the Innolitics 510(k) clearance guarantee?

We guarantee 510(k) clearance for clients whose algorithms meet our acceptance criteria and who prioritize FDA clearance organization-wide. We also guarantee submission timelines for algorithms that are complete and containerized.

Does DBLG2 work with any insulin pump?

As an interoperable device, it is designed to connect with any pump or CGM that meets the necessary interoperability standards, rather than being locked to a single proprietary hardware system. The sponsor has submitted a PCCP and, although we don’t know what the scope of the PCCP is yet, I think it will include adding more pumps and continuous glucose monitor compatibility.

Is it safe to run a high-risk medical device on a patient's personal phone?

Yes, provided the software includes robust cybersecurity and risk mitigation measures. The FDA's clearance of DBLG2 demonstrates that consumer smartphones can serve as reliable computing platforms for Class II therapeutic devices when the software effectively manages interruptions, connectivity issues, and background processes.

DBLG2 likely relies on the pump manufacturer risk controls to be resilient to connectivity drops but we won’t know until the 510(k) summary gets released.

Does SaMD reduce the cybersecurity burden?

It shifts the burden rather than reducing it. You are no longer responsible for hardening a physical device, but you must implement rigorous defensive coding to protect against threats on an uncontrolled open platform (the smartphone), including OS updates and malware.

Ready to follow this roadmap? 🔗