Skip to content

Software Device Description For IDE Baseline

Status: Reviewer summary Owner: BionicLoop engineering Last updated: 2026-06-06 10:50 EDT

Purpose

Describe the software-only investigational device baseline in one concise wrapper for IDE review. This document summarizes the software behavior, configuration, interfaces, risk controls, verification posture, and explicit limitations for the engineering-owned software packet. It does not replace the controlled SRS, SDD, SVVP, RA, RTM, IFU, or protocol documents.

Baseline Identity

Item Current Packet Value
Candidate software baseline SHA 963d717 (Gate fallback replay on pod continuity)
Freeze status Candidate baseline prepared for review; final freeze SHA remains to be recorded at package freeze
Source repository /Users/jcostik/BionicLoop
Primary app target BionicLoop iOS app
Core package BionicLoopCore Swift package
Local device packages LoopKit, G7SensorKit, G7SensorKitUI, OmniBLE
Algorithm bridge Embedded bridged dosing algorithm hosted through BionicLoopCore

Intended Investigational Use

BionicLoop is an investigational iPhone-based automated insulin delivery controller for study use. The accepted software baseline uses Dexcom G7 CGM data, Omnipod DASH pump communication, and an embedded dosing algorithm to calculate and apply insulin-delivery commands under runtime and safety guardrails.

The current IDE software packet claims the local controller software baseline only. It does not claim full cloud, Part 11, provider-policy, or commercial release closure.

Supported Configuration

Configuration Area IDE Baseline Position
Controller iPhone app running the checked-in BionicLoop target
CGM Dexcom G7 intake through embedded G7SensorKit; Dexcom remains the primary source of CGM alarm truth
Pump Omnipod DASH communication through embedded OmniBLE and LoopKit-derived support
Algorithm execution Algorithm-driven dosing only; no manual test-dose path
Study inputs Meal announcement and manual BG entry are participant-facing workflow inputs where allowed by runtime policy
Local records Local telemetry, alert history, and CSV/export behavior are part of the local software posture
Cloud/auth Development cloud/auth surfaces exist but broader cloud, authorization, provider policy, and Part 11 closure are deferred from this packet

High-Level Architecture And Data Flow

  1. BionicLoop receives CGM, pump, user workflow, app lifecycle, and timer/wake events.
  2. Runtime policy determines whether a loop step is due and whether inputs are fresh enough to execute.
  3. BionicLoopCore prepares algorithm inputs from accepted glucose history, pump status, meal/BG context, clinical settings, and persisted runtime state.
  4. The bridged dosing algorithm returns a recommendation and telemetry for the current step.
  5. Runtime applies pump commands only when pump status and safety gates permit.
  6. Step telemetry, fallback events, command outcomes, alerts, and local review data are persisted for user review and evidence support.
  7. Alerts are normalized into app alerts with severity, dedupe, acknowledgement, and background-notification behavior according to alert policy.

Device And Algorithm Boundaries

Boundary Current Claim
Algorithm Hosted locally through the core algorithm bridge; runtime supplies normalized inputs and records output telemetry
CGM BionicLoop consumes CGM readings and state; Dexcom remains source of truth for primary CGM alarms
Pump BionicLoop owns command policy, status normalization, alert mapping, and delivery reconciliation; DASH device/manufacturer controls remain inherited controls
Masked fallback Runtime may program/maintain masked fallback basal behavior only under active-session and pump-safety gates
Reconnect recovery Confirmed/corrected masked-fallback recovery uses credible same-pod pump-reported delivered-insulin delta for no-command missed-step primary/secondary algorithm replay with CGM=-1 and per-step delivered-insulin input; it does not reconstruct historical CGM, duplicate recovered insulin on the resumed live step, or replay after different/new pod, unknown pod identity, or delivery-history discontinuity evidence
Cloud Local packet does not claim cloud/device-to-cloud verification closure

Study-Relevant Software Requirements

The current packet focuses on local software behaviors that materially affect study use:

  • runtime wake-cause handling and step cadence
  • algorithm input normalization and command application
  • CGM freshness/degraded-mode handling
  • pump status, command blocking, and delivery reconciliation
  • meal announcement and manual BG workflow rules
  • masked fallback arm/refresh/recovery safety behavior
  • alert display, acknowledgement, dedupe, background notification, and no-active-pod repeat notification behavior
  • local telemetry, CSV/export, and review surfaces
  • clinical settings gate and configuration persistence

Controlled requirement and trace references:

Risk-Control Summary

Risk Theme Current Software Controls
Incorrect or mistimed insulin delivery Step cadence, wake-cause gating, pump-status gating, closed-loop-only dosing, command-result classification, and unavailable-pump command blocking
Stale or missing CGM/pump state CGM freshness policy, degraded execution rules, pump reconnect fallback policy, unavailable-status handling, and explicit skip/block outcomes
Masked fallback exposure Active-session arm gates, pump-safety maintenance gates, persisted fallback state, offline-expiry recovery blocking, credible same-pod pump-delta reconciliation, and ambiguous/different/new/unknown/logging-only recovery path
Alert failure Normalized alert inventory, severity/acknowledgement rules, background notification channel for non-CGM alerts, repeating no-active-pod notification attempts, and persistent active/recent alert state
Data integrity and local records Step telemetry persistence, command/fallback event logging, local review surfaces, CSV/export posture, and explicit cybersecurity defer/acceptability statements

Risk and cybersecurity details are maintained in:

Verification Posture

The current candidate baseline has development verification coverage across core algorithm-host behavior, app runtime behavior, alerting, persistence, Home workflows, meal/BG workflows, and masked fallback recovery. The latest candidate-baseline regression evidence includes:

  • full BionicLoopCore Swift package tests: 174 passing tests
  • full BionicLoopTests app unit target: passed
  • focused fallback exposure, fallback pump-delta accounting, masked fallback maintenance, alert-center, and pump-alert suites: passed
  • Swift lint report mode: 0 serious findings with baseline warning-level length/complexity findings
  • Swift format report mode: 0/246 files require formatting
  • Xcode static analysis: exit code 0
  • git diff --check: clean

This is development and handoff evidence. Formal IDE closure still requires freeze-time evidence promotion or rerun into Docs/Quality/Evidence/Formal/ for the rows actually claimed at freeze.

Verification references:

Cybersecurity And Privacy Boundary

The IDE software packet is proportionate to local controller software use:

  • local files, telemetry, logs, CSV export, and permissions are BionicLoop-owned controls
  • DASH and G7 device-side security controls are inherited controls requiring supplier/FDA artifact support
  • cloud/auth/provider-policy verification, broader Part 11 closure, and production-grade cybersecurity release posture are deferred from the current packet
  • the current local file-sharing/export posture requires explicit receiving-team freeze disposition before final IDE package freeze

Release And Configuration Controls

Before formal freeze, the receiving quality/submission team must record:

  • final freeze SHA or tag
  • exact included document versions and dates
  • scope/defer manifest
  • formal evidence execution plan and owners
  • post-freeze change-control rule

After freeze, behavior-changing code or controlled requirement/design changes should reopen the baseline and trigger explicit change-control review before they are included in the IDE package.

Known Limitations And Deferred Scope

The current engineering-owned IDE packet does not claim closure for:

  • full cloud/device-to-cloud verification
  • Part 11 readiness
  • broader auth/provider/session-continuity closure (SRS-SEC-003..009, TV-SEC-002..008)
  • step-0 BG rescue (SRS-BG-008, TV-BG-007)
  • full supplier/manufacturing/training/non-software QMS artifacts
  • full commercial cybersecurity/SBOM/advisory release closure

Scope references: