Skip to content

BionicLoop IDE Software Submission Core

Field Value
Device software BionicLoop investigational automated insulin-delivery controller
Baseline tag ide-software-freeze-2026-08-21
Baseline commit 91c0e98a9bc9429a0486bebdebffc7d8dbbe300e
Last product-source commit in frozen baseline ae00e754
Status Approved software package for IDE submission; predeployment condition identified in section 6
Date 2026-09-08

1. Executive Summary

The final protocol, Optimizing Automated Insulin Delivery to Meet Pregnancy Glycemic Targets, Version 1.0, dated 1 September 2026, describes a significant-risk, 20-participant crossover investigation of Standard and Pregnancy automated-insulin-delivery configurations in nonpregnant female adults ages 18 through 49 with type 1 or type 2 diabetes.

BionicLoop is an investigational iPhone application that receives glucose data from a Dexcom G7, executes the sponsor-controlled Algo2015 dosing logic, and commands an Omnipod DASH insulin pump. The app also provides participant and study-staff workflows for meal announcements, fingerstick blood-glucose entry, device status, alerts, temporary targets, insulin suspension and resumption, clinical configuration, and study-data recovery.

Primary software safety mechanisms are the independent primary and safety controller instances, guarded pump-command application, and programmed backup basal with degraded-state alerting during device-data loss.

The software source baseline is frozen at the tag and commit identified above. Engineering completed freeze execution of the algorithm, automated app, simulation, and the 68 local cybersecurity controls defined by TV-SEC-001. All 24 IDE-scope risk-analysis rows have freeze execution evidence mapped in the Requirements Traceability Matrix.

Recorded verification limitations and the accepted predeployment condition are summarized in section 6. Software-package approvals are summarized in section 8.

1.1 FDA Documentation Level

BionicLoop is documented at the Enhanced Documentation Level because a software failure or latent defect could contribute to incorrect or delayed insulin delivery and serious injury. Technical Appendix A00 records the rationale and maps the FDA Enhanced Documentation Level content to the controlled package.

2. Investigational Device and Software Baseline

2.1 System Components

The study system comprises:

  • BionicLoop app user interface and orchestration
  • BionicLoopCore runtime, persistence, safety policy, and algorithm-host logic
  • two symbol-isolated compilations of the same unmodified Algo2015 source for the primary and safety controller tracks
  • G7SensorKit integration for Dexcom G7 data intake
  • OmniBLE integration for Omnipod DASH communication and delivery
  • local protected telemetry, active-session step evidence, and clinical-gated recovery export
  • supportive BionicScout telemetry and study-support services used as corroborating backup rather than a local dosing dependency

OmniBLE and G7SensorKit are inherited open-source components. Their exact Build 843 source, including local modifications, is part of the controlled software baseline and is addressed by applicable software requirements, risk management, configuration control, and verification. External regulatory decisions are not used as substitute verification for these components.

2.2 Configuration Identification

The controlled source identity, algorithm hashes, toolchain, dependency resolution, and document revisions are listed in Software Version and Configuration Identification. Commit ae00e754 is the last product-source change in the frozen baseline; later freeze commits contain test, labeling, and package records. Build 843 is the signed, installed archive with exact tracked dependencies and recorded real-Pod operation. It was approved as the IDE submission build on 2026-09-03.

2.3 Operating Model

The app performs algorithm-driven dosing only; it has no manual test-dose path. The primary inputs are accepted Dexcom G7 readings, validated fingerstick BG entries when permitted, pump status and delivery feedback, and qualitative meal announcements. Pump commands are guarded by current runtime and pump-state policy. Loss of CGM or pump communication is handled through explicit degraded states, participant alerts, programmed backup-basal behavior, and bounded reconciliation logic.

3. Study-Use Software Scope

3.1 Included

  • runtime scheduling, state persistence, relaunch recovery, and guarded dosing
  • CGM acquisition, availability, replacement-sensor targeting, and BG entry
  • DASH status, delivery, suspension/resumption, and alert normalization
  • algorithm execution, command construction, and accepted delivery feedback
  • meal-announcement lifecycle and interrupted-dose attribution
  • programmed backup basal, masked-fallback lifecycle, and reconnect accounting
  • Pregnancy-mode temporary targets with the permanent safety/fallback basis
  • participant alerts and study-staff Clinical Settings access controls
  • protected local study records, telemetry retention, and recovery export
  • software-facing IFU and training references

3.2 Deferred or Not Claimed

  • step-0 fingerstick rescue; the frozen baseline remains CGM-only at step 0
  • historical CGM reconstruction during fallback replay
  • commercial cloud, broad provider/authentication, and Part 11 closure
  • production role-based authorization beyond the investigational offline Clinical Settings unlock
  • independent manufacturer-level validation of Dexcom G7 or Omnipod DASH hardware or firmware; the applicable Build 843 software integrations are within the controlled software scope and supporting real-device observations are retained, but no separate formal hardware-validation study is claimed
  • a separate formal participant usability or summative human-factors study

The software package uses protected local records and the clinical-gated exact-session recovery ZIP as primary session-reconstruction evidence, with Scout as corroborating backup. The scope boundary is defined in Cloud Telemetry Submission-Scope Decision.

4. Software Risk and Cybersecurity Posture

4.1 Principal Software Risks

The principal hazards are incorrect or mistimed insulin delivery (RA-001, RA-004, RA-005, RA-014, RA-017, RA-020, RA-021, RA-022); use of stale or unavailable glucose and pump state (RA-002, RA-003, RA-012, RA-015, RA-018, RA-023); loss or duplication of insulin-delivery feedback (RA-008, RA-014, RA-016, RA-017, RA-020); incorrect backup-basal reconciliation (RA-003, RA-015, RA-018, RA-020); unrecognized interruption or alert conditions (RA-001, RA-010, RA-011, RA-018); unauthorized or unsafe Clinical Settings changes (RA-013, RA-019, RA-021, RA-022); loss of study records (RA-008, RA-009, RA-019, RA-024); and misleading UI state (RA-007, RA-008, RA-010, RA-011).

Controls include:

  • guarded algorithm execution and pump-command application
  • explicit freshness, identity, continuity, and delivery-evidence checks
  • exactly-once issued-dose attribution keyed to the request step
  • bounded fallback replay and insulin-conservation checks
  • programmed backup basal and masked-fallback recovery behavior
  • validated manual-BG timing and single-consumption rules
  • normalized alert severity, deduplication, persistence, and escalation
  • local single-use Clinical Settings unlock counters and expiration
  • protected, backup-excluded clinical records and recovery staging
  • traceability from RA-* hazards through SRS-*, SDD-*, TV-*, and formal evidence

The detailed hazard analysis is Appendix A03. Residual policies and anomalies are summarized in section 6 and in the controlled anomaly register.

4.2 Cybersecurity

The freeze local-control lane passed all 68 tests defined by TV-SEC-001. It covered protected retention, migration, export staging, backup exclusion, clinical share gating, session-isolated recovery export, and absence of participant Files-sharing/open-in-place keys.

Build 843 passed the dependency checks, pump cryptographic/session vectors, core, canonical app, and TV-SEC-001 security suites. Its signed archive identity, installed-build identity, and focused real-Pod use are recorded.

The TV-SEC-001 result does not include inherited supplier controls, commercial cloud, Part 11, broader provider/authentication policy, or continuous vulnerability-management services. Scout is supportive for the software package; available sequence-correlated cloud records are retained as corroborating backup. Any later decision to rely on Scout for required endpoint or safety data would reopen the narrow contract and cloud verification scope.

5. Prior Testing and Current Verification

5.1 Freeze Results

Lane Execution result Recorded limitation or follow-up
STP-ALG-001 Behavioral suites passed; coverage and host regression completed; freeze linkage companion passed 6/6 ALG-DEV-SA-006 closed by companion evidence
STP-AUTO-001 Original app target: 997 total, 996 passed, 1 intentional IFU reference-table generation helper skip gated by an export directory, 0 failures; original UI target: 41 passed and 3 harness deviations; corrected UI companion: 44/44 passed AUTO-DEV-001 and AUTO-DEV-002 closed by companion evidence
STP-SIM-001 Core, pod, alert, and real-engine simulation lanes passed None identified in execution
TV-SEC-001 All 68 local controls defined by TV-SEC-001 passed None identified in scoped execution
Build 843 IDE submission archive Dependency controls 6/6, OmniBLE crypto/session 8/8, Core 471/471, canonical app 997 executed with zero failures and one intentional IFU reference-table generation helper skip gated by an export directory, TV-SEC-001 security 68/68; signed archive, installed identity, real-Pod operation, and recovery ZIP observed Approved for IDE submission 2026-09-03; real-Pod records are supporting evidence and no separate formal hardware-validation study is claimed

In this report, a "companion" run is a supplemental verification pass against the same frozen source that corrects or supplements a deviation identified in the original run without changing the immutable original evidence records.

The intentional skip is an IFU reference-table generation helper that runs only when its export directory is supplied. It does not omit a dosing requirement or runtime verification.

Technical Appendix A11, the Freeze Execution Report, preserves the original execution counts and deviations. The Formal Evidence Index links the companion and designation records that close all four non-product deviations.

5.2 Traceability Status

RTM version 1.86 maps freeze evidence to all 24 IDE-scope risk-analysis rows in its canonical current-state matrix. Rows involving retained hardware, alerts, cloud transport, or deviations identify their applicable limitations and follow-up in the matrix and remaining-work checklist.

6. Known Anomalies, Deviations, and Residual Limitations

6.1 Verification Deviations

Four non-product deviations are closed. The original execution records remain preserved.

  • ALG-DEV-SA-006: closed by a freeze companion that passed all six static-analysis/linkage assertions and linked the frozen SHA to SRS-ALG-001 and SRS-ALG-002.
  • AUTO-DEV-001 and AUTO-DEV-002: closed by test-harness-only corrections and a complete serial UI companion run with 44/44 tests passed.
  • CYBER-DEV-001: closed on 2026-09-03 by designation of Build 843 with the controlled CryptoSwift 1.10.0 resolution; archive-826 history remains preserved. The corrections did not change participant-facing or dosing behavior. The original execution records remain unchanged for audit history.

6.2 Material Residual Limitations

  • Formative real-Pod observations are described as supporting evidence. The package does not claim a separate formal hardware-validation study.
  • Fallback replay may preserve total insulin while retaining limited within-window attribution precision (RA-003, RA-016, RA-017, RA-020).
  • Assumed-delivered policy can conservatively over-account insulin when the old pod cannot provide final evidence; the assumption is explicitly labeled (RA-017).
  • Some backup-basal model outputs remain operator-review estimates when the old pod is unavailable and are not treated as confirmed pump delivery (RA-003, RA-015, RA-020).
  • CGM outage and manual-BG behavior depend on trained response to alerts and timely valid fingerstick entry (RA-002, RA-012, RA-015, RA-018).
  • No separate formal participant usability or summative human-factors study is claimed for the use risks in RA-010, RA-011, and RA-012; the available engineering UI, formative real-device, and clinical-review evidence boundary was clinically approved on 2026-08-27.
  • Scout is supportive and outside local dosing control (RA-008, RA-009, RA-024).
  • Manual or device-lifecycle-triggered replacement acquisition has no authoritative Dexcom handoff identity and can encounter another nearby G7 advertiser. Staleness alone never releases the bound sensor. Physical isolation for planned replacement and post-connection comparison reduce risk, but comparison does not gate the first accepted reading. The September 3 adversarial review also identified replacement-episode loss through CGM setup reentry and a non-atomic concurrent-candidate path; no wrong-sensor adoption was observed in the supporting field event. The accepted D06 disposition defers the controlled RA-023 exercise and final disposition until before first participant deployment. No participant deployment may occur until objective testing supports use of unchanged Build 843 or a corrected, classified, verified study build is available.

The full anomaly and residual register is part of the Core package.

7. Human Factors, Training, and Labeling

The final protocol describes nonpregnant female participants ages 18 through 49 with type 1 or type 2 diabetes and trained clinical/study personnel. Use occurs during clinic setup and supervised outpatient/home activity with an iPhone, Dexcom G7, Omnipod DASH, glucose meter, and study escalation support.

Safety-critical tasks include device setup, interpreting status and alerts, announcing meals, entering and confirming fingerstick BG, replacing a sensor or pod, responding to communication loss, suspending and resuming insulin, reviewing temporary targets, and contacting study staff when instructed.

The software has engineering UI tests, formative real-device observations, operator protocols, and a workflow-based IFU. These support design evaluation; the package does not claim a separate formal participant usability or summative human-factors study. Clinical review approved this evidence description on 2026-08-27. The detailed use-related risk summary identifies the available evidence and residual use risks.

The final protocol is titled Optimizing Automated Insulin Delivery to Meet Pregnancy Glycemic Targets, Version 1.0, dated 1 September 2026. Software review verified that its descriptions of fingerstick handling, meal availability during CGM interruption, target configurations, Pregnancy meal setting, supported weight range, Same-Participant Reset, G7 startup, official study-data sources, and software-evidence boundaries are consistent with Build 843. The final protocol source remains under study-team document control.

The current labeling reference is IFU-BL-001, revision 1.17, approved for IDE submission on 2026-09-04. The app and final device labeling identify the software as investigational. The synchronized device-labeling attachment names BionicLoop 1.0 Build 843 and IFU-BL-001 revision 1.17.

8. Software-Package Approvals

The IDE Submission Decision Register is the authoritative software-package approval record. Clinical direction for the target sets and all eight software-consistency recommendations is recorded. Build 843 and the ZIP/CSV collection, transfer, and storage approach were approved on 2026-09-03; IFU revision 1.17 was approved on 2026-09-04; and the RA-023 submission disposition, residual risks, verification evidence, traceability, cybersecurity scope, participant Scout service environment, final software-package approver, and synchronized device label are closed in the register. Software consistency was verified against the final protocol, consent, and device labeling.

9. Technical Appendices

The IDE Software Technical Appendices - Manifest provides the following review path:

  • A00, Enhanced Documentation Level and FDA Content Crosswalk: documentation-level rationale and package mapping.
  • A01, Software Requirements Specification: implemented software requirements.
  • A02, Software Design Description: architecture and control design.
  • A03, Risk Analysis: hazards, controls, residual ratings, and benefit-risk.
  • A04, Software Verification and Validation Plan: verification methods and protocols.
  • A05, Requirements Traceability Matrix: requirement/design/test/evidence links.
  • A06, Cybersecurity Plan: local, device, dependency, and deferred cloud controls.
  • A07, Formal Evidence Index: formal execution bundles and results.
  • A08, Software Composition and Dependency Inventory: software-component identities.
  • A08A, Build 843 Dependency Verification: exact external-dependency verification.
  • A08B, Build 843 SBOM and Advisory Review: machine-readable composition and dated review boundary.
  • A08C, IDE Cybersecurity Closure Matrix: completed, open, and deferred cybersecurity controls.
  • A09, IFU-BL-001: revision 1.17 participant and study-staff labeling, approved for IDE submission on 2026-09-04.
  • A10, Version and Configuration Identification: source, toolchain, and build inputs.
  • A10A, Build 843 Tester Release Record: archive, signing, upload, and installation identity.
  • A10B, Build 843 Working Hardware Evidence Review: hardware and recovery-export support evidence.
  • A10C, Build 843 Freeze Delta and Study-Build Designation: executable delta assessment supporting the 2026-09-03 submission-build approval.
  • A11, Freeze Execution Report: original formal runs, deviations, and companions.
  • A12, Post-Approval Change-Control Procedure: change classification and approvals.
  • A13, Sponsor and Nonsoftware Ownership Map: nonsoftware IDE owners and gaps.
  • A13A, Clinical Policy Confirmation: accepted fallback and weight-range decisions.
  • A14, Cloud Telemetry Scope Decision: Scout role and authoritative-data-source decision.
  • A15, Protocol Fingerstick Consistency Issue: resolved in the final protocol, consent, and IFU document set.
  • A16, Clinical Approval of Software IDE Decisions: seven approved software/IDE statements, official study-data/safety-report sources, and the August 31 approval to implement all eight software-consistency recommendations.
  • A17, Insulin Delivery CSV Data-Management Procedure: approved ZIP/CSV collection, transfer, and storage approach with detailed integrity, retention, and chain-of-custody controls.
  • A18, Final Software Approvals: Build 843 and the ZIP/CSV operating approach approved on 2026-09-03; IFU revision 1.17 approved on 2026-09-04.

Internal administrative, execution, and working records are classified separately and are not part of this primary FDA narrative.