Risk Analysis (Quality)
Status: Submission-candidate risk analysis (approval and freeze metadata pending)
Version: 1.06
Owner: BionicLoop engineering
Prepared by: BionicLoop engineering
Reviewer: ____
Approver: ____
Decision date: ____
Effective date: ____
Baseline freeze SHA: ____
Scope: BionicLoop investigational closed-loop app (Dexcom G7 + OmniPod DASH + Algo2015)
Last updated: 2026-06-18
Revision History
| Version | Date | Author | Summary of Changes |
|---|---|---|---|
| 0.1 | 2026-03-25 | Engineering | Initial controlled draft baseline |
| 0.9 | 2026-04-06 | BionicLoop engineering | Added handoff-ready metadata and refined software-only cybersecurity boundary language for RA-009 |
| 0.91 | 2026-04-07 | BionicLoop engineering | Tightened residual-risk wording for local telemetry exposure, investigational clinical gating, and reconnect-fallback behavior to match the current baseline and remaining freeze-time evidence posture |
| 0.92 | 2026-04-08 | BionicLoop engineering | Added masked-fallback maintenance and restore guardrail wording for the active offline-fallback feasibility branch |
| 0.93 | 2026-04-08 | BionicLoop engineering | Clarified masked-fallback deferred-maintenance and recoverable-restore controls for the active feasibility branch |
| 0.94 | 2026-04-14 | BionicLoop engineering | Added reconciliation-required blocked-state controls after offline mask expiry for the active masked-fallback feasibility branch |
| 0.95 | 2026-04-14 | BionicLoop engineering | Added reconnect restore/disarm retry and explicit fresh re-arm controls for pending masked-fallback recovery |
| 0.96 | 2026-04-14 | BionicLoop engineering | Updated masked-fallback recovery risk controls to describe same-session unreconciled resume as the current feasibility path after successful restore |
| 0.97 | 2026-04-15 | BionicLoop engineering | Added pod total-delivery baseline and modeled-vs-pump-reported fallback review controls for the active masked-fallback feasibility branch |
| 0.98 | 2026-04-15 | BionicLoop engineering | Added confirmed/corrected basal-only reconnect replay controls, persisted replay-plan state, and replay-detail review visibility for the active masked-fallback feasibility branch |
| 0.99 | 2026-06-02 | BionicLoop engineering | Updated masked-fallback controls to pump-delta missed-step algorithm replay and added repeated no-active-pod critical alert controls |
| 1.00 | 2026-06-06 | BionicLoop engineering | Added same-pod continuity as a replay authorization control and formalized explicit-operator-only algorithm session lifecycle |
| 1.01 | 2026-06-08 | BionicLoop engineering | Added schedule-weighted replay allocation controls and zero-weight no-replay behavior for credible same-pod pump delta |
| 1.02 | 2026-06-11 | BionicLoop engineering | Clarified that fallback replay is bounded to confirmed fallback-active missed slots and excludes pre-activation disconnected gaps |
| 1.03 | 2026-06-12 | BionicLoop engineering | Added generalized issued-dose attribution controls for interrupted automatic bolus commands and different/new-pod no-replay disposition |
| 1.04 | 2026-06-13 | BionicLoop engineering | Hardened issued-dose risk controls for non-credible delivered-unit evidence, old-pod delivery input scrubbing, and automatic resume blocking |
| 1.05 | 2026-06-15 | BionicLoop engineering | Updated different/new-pod issued-dose control to assume delivered without blocking replacement-pod dosing; documented possible 4-hour adaptation-forget control pending team signoff |
| 1.06 | 2026-06-18 | BionicLoop engineering | Added retired/expired/no-active-pod fallback recovery control that uses assumed modeled fallback exposure when connected pump evidence is no longer recoverable. |
| 1.06 | 2026-06-17 | BionicLoop engineering | Added explicit meal-progress pod-replacement escape that records assumed-delivered evidence before clearing trapped UI state |
Method
Each hazard is tracked with:
RA-ID- hazard statement
- initial severity/probability
- controls
- linked requirements (
SRS-*) - linked verification (
TV-*/ manual protocol IDs) - residual-risk note
Severity and probability are currently qualitative (Low, Medium, High) and can be replaced with numeric scoring later.
Risk Register
| RA-ID | Hazard | Initial Risk | Key Controls | SRS Links | Verification Links | Residual Risk |
|---|---|---|---|---|---|---|
| RA-001 | Loop step not executed on expected cadence due to iOS wake variability | High | CGM-triggered doWork, bounded wake-cause policy, cadence anchor, skip logic, stale-state visibility | SRS-RUN-001, SRS-RUN-002, SRS-RUN-003, SRS-UI-001 | TV-RUN-001, TV-RUN-002, TV-RUN-003 | Medium |
| RA-002 | Invalid CGM values used as real glucose input | High | Out-of-range sanitize to unavailable (-1), step-0 gate, degraded-step safety policy, explicit blocked-state messaging |
SRS-CGM-001, SRS-CGM-002, SRS-CGM-003, SRS-CGM-004 | TV-CGM-001, TV-CGM-002, TV-CGM-003, TV-CGM-004 | Medium |
| RA-003 | Pump unavailable causes incorrect delivery behavior | High | Degraded algorithm input with unavailable pump fields, command block on unavailable pump, auto-refresh delivery-state convergence, and closed-loop-only command exposure (no manual bolus path). Ongoing masked offline-fallback feasibility work adds additional guardrails: maintenance arm/refresh is gated to active algorithm sessions with a newly completed successful step, newly computed first-arm fallback is attempted before the same step's pump command so step 0 bolus delivery cannot outrun fallback schedule programming and masking, pre-command first-arm maintenance skips unavailable/unknown refreshed pump status instead of bypassing normal pump-command classification, pre-execution arm/renew/refresh maintenance requires a fresh idle pump-status refresh and defers without pod mutation when status is unavailable/unknown/delivering or refresh fails, disruptive schedule writes are blocked during active bolus / unsafe / unknown pump-delivery states, an already-active 0 U/hr mask enters renewal in the final 20 minutes of its 30 minute window and blocked renewals are treated as deferred while the current mask is still active, clean first-arm blocks leave fallback unarmed but do not automatically suppress the normal step command or retry again in the same cycle, any remask failure after possible schedule mutation or mask replacement, including late post-schedule pump blocks and existing-mask renewal failures, persists reconciliation-required recovery and blocks normal command flow, the mask may be allowed to expire only when successful loop stepping stalls or deferred maintenance runs out of remaining mask time so fallback insulin can autonomously resume, offline mask expiry now persists reconciliation-required recovery state instead of allowing ordinary authoritative live stepping to continue, reconnect/start/foreground now retry connected restore/disarm while that recovery remains pending, confirmed/corrected basal-only reconnect evidence now drives no-command missed-step primary/secondary algorithm replay only for missed delivery slots overlapping confirmed fallback-active time using CGM=-1 and per-step pump-delivery allocations only from credible pump-reported delivered insulin with proven same-pod continuity, disconnected missed slots before offline fallback activation are left missing rather than replayed as synthetic delivery rows, replay allocation weights those pump-reported units by the persisted programmed fallback schedule rather than by a scalar guess, positive pump delta with missing/zero schedule weight suppresses replay, invalid/not-required/stale pending replay plans are cleared after trace emission rather than retried against later wakes, ambiguous/new-pod/unknown-identity/history-discontinuous reconnect evidence remains explicitly marked as unreconciled/no-replay for operator review instead of being treated as authoritative reconciliation, and retired/expired/no-active old-pod recovery may use persisted schedule-modeled exposure as assumed delivered with explicit assumed-delivered labeling when pump-counter evidence is no longer recoverable. Broader ambiguous/non-basal reconstruction remains follow-on work. |
SRS-PUMP-001, SRS-PUMP-002, SRS-PUMP-005, SRS-PUMP-006, SRS-PUMP-007, SRS-PUMP-008, SRS-PUMP-009, SRS-RUN-006 | TV-PUMP-001, TV-PUMP-002, TV-PUMP-005, TV-PUMP-006, TV-PUMP-007, TV-PUMP-008, TV-RUN-008 | Medium |
| RA-004 | Meal announce accepted while pump not safe/ready | High | Meal announce pump-ready gating, unavailable-reason messaging, retry-timing feedback, borrow-window enforcement, and reconnect/recovery-required blocking when masked fallback may have become active offline | SRS-MEAL-001, SRS-MEAL-002, SRS-MEAL-003, SRS-MEAL-004, SRS-MEAL-005 | TV-MEAL-001, TV-MEAL-002, TV-MEAL-003, TV-MEAL-004, TV-MEAL-005, TV-MEAL-006 | Medium |
| RA-005 | Dose quantization mismatch with DASH minimum deliverable dose | Medium | Algorithm constants + command quantization validation + telemetry reconciliation | SRS-PUMP-003, SRS-LOG-001 | TV-PUMP-003, TV-LOG-001 | Low/Medium |
| RA-006 | App relaunch/reset causes state mismatch and unsafe cadence | High | Persisted runtime/algorithm/device-manager state, explicit full reset semantics, explicit-operator-only algorithm start/stop/reset/session replacement, and for the masked offline-fallback feasibility branch additional persisted maintenance state capturing original programmed basal schedule, current fallback schedule/rate, safety target, connected pod identity plus total-delivery baseline/timestamp, maintenance timestamps, restore-failed or reconciliation-required recovery context, and any pending pump-delta reconciliation state so refresh/disarm decisions, reconnect/start/foreground restore retry, post-expiry blocked-state recovery, confirmed/corrected missed-step algorithm replay, and ambiguous logging-only resume remain reconstructible across app/session boundaries without silently creating a new session | SRS-STATE-001, SRS-STATE-002, SRS-STATE-003, SRS-STATE-004, SRS-STATE-005 | TV-STATE-001, TV-STATE-002, TV-STATE-003, TV-STATE-004, TV-STATE-005 | Medium |
| RA-007 | Home pod status stale despite reconnect | Medium | Connection-driven refresh path, observer wiring | SRS-PUMP-004 | TV-PUMP-004 | Low |
| RA-008 | Missing auditability of algorithm inputs/outputs/commands | High | Per-step telemetry capture and traceability mapping. The masked offline-fallback feasibility branch extends operator review coverage with explicit fallback lifecycle events (armed, maintenance deferred, mask renewed, schedule checked unchanged, schedule refreshed, mask expired offline, disarmed, restore/remask failed) carrying fallback rate, source, safety target, duration, reconciliation status, pod-continuity result, failure detail, modeled fallback delivery, pump-reported delivered insulin delta when the reconnect baseline is proven same-pod and available, persisted fallback schedule metadata, schedule-weighted pump-delta reconciliation detail when confirmed/corrected reconnect recovery occurs, explicit assumed-delivered status when retired/expired/no-active pod recovery uses modeled fallback exposure because pump evidence is unrecoverable, replay rows only for reconciled or assumed fallback-active missed slots, and no-replay reason when replay cannot be safely allocated. Pre-activation disconnected gaps remain absent from replay telemetry rather than being represented as delivered-insulin rows. |
SRS-LOG-001, SRS-LOG-002, SRS-LOG-009 | TV-LOG-001, TV-LOG-002, TV-LOG-009 | Medium |
| RA-009 | Investigational telemetry artifacts stored or exported locally are accessed outside intended site/operator controls | High | Current baseline automatically writes detailed step telemetry to a Documents-based CSV export path; risk is bounded only by site/device physical control, operator handling procedures, explicit local file-access review, and receiving-team freeze disposition of the current UIFileSharingEnabled / LSSupportsOpeningDocumentsInPlace posture. Cloud/auth/provider controls are documented for system context but are deferred from this IDE software baseline and are not claimed as active mitigations for this row. |
SRS-SEC-001, SRS-SEC-002 | TV-SEC-001 | High (accepted only if the investigational local export/file-sharing posture is explicitly approved at freeze) |
| RA-010 | User workflow errors (profile, meal UI, status interpretation, stale/unreliable CGM value interpretation, incorrect device date/time leading to misleading recency context) | Medium | Explicit UI states, startup-cancel paths, background-auto-cancel for meal composer, stale/unreliable-CGM display masking (-- and no trend arrow after 11 minutes or when hasReliableGlucose == false), boundary CGM rendering (LOW/HIGH), stepped CGM chart scaling (300/350/400), UTC clock-drift checks with actionable warning (>10 min skew, 24-hour warning rate limit), SOP-driven usability checks |
SRS-UI-001, SRS-UI-002, SRS-UI-003, SRS-UI-004, SRS-UI-005, SRS-UI-006, SRS-UI-007, SRS-UI-008, SRS-VAL-001, SRS-LOG-006 | TV-UI-001, TV-UI-002, TV-UI-003, TV-UI-004, TV-UI-007, TV-UI-008, TV-UI-009, TV-UI-010, TV-LOG-006 | Medium |
| RA-011 | Critical device/runtime alerts are missed, delayed, or masked by lower-severity messages | High | Multi-source alert normalization, severity precedence, debounce/coalescing rules, repeated no-active-pod notification attempts, explicit ack/clear policy, protocol-aligned wording | SRS-ALERT-001, SRS-ALERT-002, SRS-ALERT-003, SRS-ALERT-004, SRS-ALERT-005, SRS-ALERT-006, SRS-ALERT-017 | TV-ALERT-001, TV-ALERT-002, TV-ALERT-003, TV-ALERT-004, TV-ALERT-005, TV-ALERT-016 | Medium |
| RA-012 | Manual BG entry is stale, invalid, duplicated, misapplied to wrong step, or executed while loop is off, causing incorrect algorithm input or user confusion | High | Dedicated bgCheck policy with single pending candidate, immediate-next-step-only validity, replace-on-new submit semantics, explicit stale/duplicate guards, loop-armed gating, accepted manual BG range 20...600 mg/dL, source-tagged telemetry, and explicit user feedback for rejected BG actions |
SRS-BG-001, SRS-BG-002, SRS-BG-003, SRS-BG-004, SRS-BG-005, SRS-BG-006, SRS-BG-007, SRS-BG-008, SRS-BG-009, SRS-BG-010, SRS-BG-011, SRS-BG-012 | TV-BG-001, TV-BG-002, TV-BG-003, TV-BG-004, TV-BG-005, TV-BG-006, TV-BG-007, TV-BG-008, TV-BG-009, TV-BG-010, TV-BG-011, TV-BG-012 | Medium |
| RA-013 | Clinical settings misconfiguration or unauthorized access leads to unsafe algorithm/session configuration (target/upfront/TMAX/subject/weight/start-reset controls) | High | Dedicated clinician-gated settings surface, subject-scoped offline clinical unlock verifier, validated app-side material installation/refresh into Keychain-backed per-subject verifier material/local state, single-use monotonic counter burn before unlock, accepted-counter preservation across material refresh, active-unlock clearing on material refresh, local unlock expiration/manual lock with storage-failure visibility, malformed/non-ASCII/reused/wrong-subject/beyond-lookahead/unsupported-version rejection, no production master secret in app source, strict selector bounds/step validation, lbs->kg normalization, persisted defaults/migration, clinician-controlled participant target-access profile (Pregnancy / Standard), required approval capture before participant target changes, profile-bounded clinician target options with nearest-allowed normalization on profile switch, and unchanged start/reset behavior semantics under relocated controls. This remains an investigational single-device clinical unlock control and is not a full production role-based authorization system. |
SRS-CLIN-001, SRS-CLIN-002, SRS-CLIN-003, SRS-CLIN-004, SRS-CLIN-005, SRS-CLIN-006, SRS-CLIN-007, SRS-CLIN-008, SRS-CLIN-009, SRS-CLIN-010, SRS-CLIN-011, SRS-CLIN-012, SRS-VAL-001, SRS-LOG-008 | TV-CLIN-001, TV-CLIN-002, TV-CLIN-003, TV-CLIN-004, TV-CLIN-005, TV-CLIN-006, TV-CLIN-007, TV-CLIN-008, TV-CLIN-009, TV-CLIN-010, TV-CLIN-011, TV-CLIN-012, TV-CLIN-013, TV-LOG-008 | Medium (accepted investigational residual; production authorization hardening deferred) |
| RA-014 | Algorithm logic regression or latent C++ branch defects remain undetected due to insufficient structural/deterministic test coverage, leading to incorrect dosing recommendations under specific input sequences | High | Dedicated Algo2015 structural-coverage campaign, deterministic golden-vector replay suite, bridge-contract edge-case testing, persistence/restart continuity testing, mandatory static-analysis lane on formal runs, and risk-based conditional MISRA closure (report+deviations or explicit N/A rationale) with IDE-traceable STR evidence packaging | SRS-ALG-001, SRS-ALG-002, SRS-ALG-003, SRS-ALG-004, SRS-ALG-005, SRS-ALG-006, SRS-ALG-007 | TV-ALG-001, TV-ALG-002, TV-ALG-003, TV-ALG-004, TV-ALG-005, TV-ALG-006, TV-ALG-007, TV-ALG-008, TV-ALG-009, TV-ALG-010, TV-ALG-011 | Medium |
| RA-015 | The armed loop stops achieving timely successful steps and scheduled dosing recommendations may remain unserved without actionable user escalation | High | Current baseline monitors successful-step continuity rather than CGM receipt alone: while armed, the app computes a 15-minute interruption deadline from the most recent successful step (or session start / first-step wait state if none exists yet), raises ALERT-ALGORITHM-STEPPING-INTERRUPTED with local notification when that deadline is missed, preserves Home status visibility, and clears interruption state on the next successful step or loop disarm/reset. The alert remains distinct from stronger CGM unavailable/failed and pump-native alerts and may include blocker-specific detail (No CGM, No Pod, signal loss, other runtime gates). Runtime now also permits guarded reconnect-based fallback execution after the first anchored step exists using the current due step only without re-anchoring or backlog replay. Current implementation executes this path when accepted CGM receipt age exceeds the approved freshness limit and also when CGM freshness is unavailable; freeze closure shall either narrow the implementation to the stale-CGM-only gate or explicitly accept and verify the broader behavior. Remaining closure work is real-device validation of reconnect/background behavior. |
SRS-CGM-005, SRS-RUN-004, SRS-RUN-005, SRS-ALERT-013, SRS-ALERT-014, SRS-UI-001, SRS-UI-002 | TV-CGM-005, TV-RUN-004, TV-RUN-005, TV-RUN-006, TV-RUN-007, TV-ALERT-012, TV-ALERT-013, TV-UI-001 | Medium |
| RA-016 | Meal announce is duplicated, silently lost, or ambiguously applied because submit/outcome state is not durable across relaunch, comms interruption, or competing triggers | High | Implemented baseline now persists pending meal-request state plus correlated meal flow_id across relaunch, blocks duplicate meal entry while the intended execution step remains unresolved, defers Home success messaging/telemetry until runtime/coordinator result is known, blocks repeat meal entry with explicit operator guidance when command outcome is uncertain until reconciliation or session reset/disarm, rejects competing-trigger slot conflicts with explicit retry guidance instead of silently reassigning meal intent to a later borrowed step, provides an explicit user-confirmed pod-replacement escape for unconfirmed old-pod meal delivery after timeout or known pod unavailability, and emits accepted / resolved telemetry closure when the request is accepted, reconciles after uncertainty, or is cleared by session reset. Loop command telemetry preserves uncertain-vs-blocked semantics for cloud reconstruction. |
SRS-MEAL-007, SRS-MEAL-008, SRS-MEAL-009, SRS-MEAL-010, SRS-MEAL-012, SRS-LOG-007, SRS-UI-002 | TV-MEAL-008, TV-MEAL-009, TV-MEAL-010, TV-MEAL-011, TV-MEAL-013, TV-LOG-007 | Medium |
| RA-017 | Automatic bolus delivery is interrupted or unreconciled, causing the primary/secondary algorithms to miss delivered insulin or issue additional insulin before prior delivery is safely dispositioned | High | Runtime now persists issued-dose attribution for any applied or uncertain automatic bolus command, including meal, correction, mixed, and basal micro-dose commands. Active delivery blocks live step advancement. Matching same-request same-pod pump evidence replays missed primary/secondary steps with CGM=-1, actual delivered insulin injected only at the first missed attribution step, no catch-up commands, and monotonic/non-duplicating coordination with fallback replay; if the first eligible attribution step is the live due step, persisted evidence is fed into that live step without synthetic replay rows. When a same-pod reconnect pump-total delta spans both an in-flight issued dose and fallback basal exposure, runtime partitions the known pending issued-dose request from that pump total only when the request, pod identity, completion timing, and residual fallback exposure are credible; the residual is used for fallback replay and the raw pump total remains telemetry/operator-review evidence. Non-credible delivered-unit evidence outside 0...requested, absent evidence, mismatched evidence, missing-identity evidence outside the explicit user-confirmed unavailable-pod clinical-policy path, or non-credible pump-total partition keeps the attribution pending/ambiguous and skips live advancement or replay rather than guessing delivered insulin; ambiguous raw pump total is not displayed or persisted as actual fallback residual delivery. If a different/new pod appears before reconciliation, runtime records that disposition, preserves the same algorithm session, assumes the issued dose was delivered, feeds that assumed amount into the first eligible attribution step by replay or live-step input, clears the old-pod pending attribution after consumption, scrubs unrelated replacement-pod lastDelivery from the resumed live algorithm input, and does not block later insulin-adding automatic commands solely because the original pod cannot be reconciled. If the operator explicitly confirms pod replacement from an unresolved meal-progress modal after the old pod is unavailable or timed out, runtime records user_abandoned_unavailable_pod, stores assumed-delivered evidence, clears only meal-progress UI state, and leaves attribution for replay/live-step consumption; missing original pod identity is accepted only for this assumed-delivered path when step, units, delivered bounds, and non-active pump state match. Possible future mitigation, pending clinical/algorithm team signoff, is to forget or discount larger unconfirmed assumed-delivered doses after about 4 hours; this is deferred because it requires algorithm-owner design for opaque Algo2015 adaptation state. |
SRS-PUMP-010, SRS-MEAL-012, SRS-STATE-004, SRS-STATE-005, SRS-LOG-001 | TV-PUMP-009, TV-MEAL-013, TV-STATE-004, TV-STATE-005, TV-LOG-001 | Medium |
Residual Risk Acceptance Notes
RA-009: The current local export/file-sharing posture requires explicit receiving-team acceptance for the investigational baseline and is not suitable for a broader production claim without hardening.RA-013: Offline single-use Clinical Settings unlock is accepted as an investigational single-device control; broader production authorization/role-based access remains deferred unless explicitly pulled into scope.RA-014,RA-015,RA-016, andRA-017: Residual-risk closure depends on formal freeze-lane evidence promotion; current documented residuals remain provisional until those artifacts are executed and linked.