Skip to content

March 20, 2026 IDE Readiness Briefing

Last updated: 2026-03-27 11:05 EDT Status: Working meeting packet

Meeting Context

  • Meeting: March 20, 2026 at 11:00 AM
  • Duration: 30 minutes
  • Purpose: align on the highest-impact decisions and blockers needed to stay on track for the March 26 detailed review and a realistic IDE submission target

Leave the meeting with:

  1. A clear statement of whether protocol and consent are ready for final sign-off, or exactly what edits remain.
  2. A short list of submission-critical blockers with owners and due dates.
  3. Explicit decisions on what must close before March 26 versus what will be formally deferred from the IDE baseline.

Executive Summary

The current documentation does not support claiming full IDE submission readiness yet. The main open gaps are not core app feature coding; they are final-draft package preparation, formal verification packaging, unresolved requirement dispositions, risk/security closure, and final baseline-scope decisions.

The March 20 meeting should be run as a decision-and-assignment meeting, not as a final readiness sign-off.

Based on the current closure workload, mid-April 2026 is a more defensible submission target than early April 2026 unless multiple ownership and scope decisions are closed immediately.

Ownership Clarification

  • software quality document authoring and technical trace closure
  • recommended owner: engineering / technical integrator
  • scope: author RA, SRS, SDD, SVVP, RTM updates, align implementation with traceability, generate technical V&V evidence, and prepare the final-draft package for handoff
  • controlled-document review, approval, and release handling
  • recommended owner: quality / design assurance
  • scope: document-control workflow, revision/review status completion, approval routing, RTM closure discipline, formal evidence acceptability, and release handling
  • IDE construction and submission package assembly
  • recommended owner: regulatory / submission lead
  • scope: baseline lock, include/defer decisions, final document index, submission readiness memo, package assembly
  • protocol and consent sign-off
  • recommended owner: clinical lead / investigator plus consent/human-subjects reviewer
  • algorithm acceptance and investigational-plan technical sign-off
  • recommended owner: algorithm owner plus clinical lead
  • privacy, auth, cybersecurity, and any Part 11 claim boundary
  • recommended owner: privacy / security owner

What to resolve in the meeting

  • Who owns software-quality document authoring?
  • Who owns controlled-document review/approval/release handling?
  • Who owns the actual IDE package construction?
  • Who has final authority on defer/include decisions?

Without explicit assignment of those roles, the package is likely to stall even if technical docs continue to improve.

What to bring

  • Latest protocol baseline and edit status:
  • Protocol
  • Latest consent form redlines and exact sign-off status for Camille, Melissa, John, and Ed.
  • A one-page table listing:
  • document
  • current version/date
  • owner
  • final edits remaining
  • ready for sign-off: yes/no

Suggested approver fields

For protocol, consent, and IDE-readiness sign-off tracking, use these fields:

  • approver name
  • approver role
  • review domain
  • approval authority
  • status (not started, in review, approved with edits, approved, blocked)
  • decision date
  • blocking comments / required edits

Suggested roles and review domains

  • clinical lead / investigator
  • domain: protocol clinical intent, investigational plan, subject-safety workflow, alert/escalation expectations
  • consent / human-subjects reviewer
  • domain: consent wording, subject-facing disclosures, investigational-use language, data-use language
  • algorithm owner
  • domain: algorithm behavior, uncovered-branch rationale, parameter mapping, investigational-plan technical correctness
  • software engineering lead
  • domain: implemented behavior, verification posture, runtime/device integration readiness, technical scope/defer recommendations
  • quality / design assurance owner
  • domain: controlled-document review/approval/release handling, RTM closure, verification packaging, residual-risk sign-off readiness
  • regulatory / submission owner
  • domain: IDE package completeness, defer/include decisions, submission baseline lock
  • privacy / security owner
  • domain: authentication scope, cloud-access policy, cybersecurity claims, Part 11 / audit-trail claim boundaries

Suggested approval-authority labels

  • clinical
  • consent
  • algorithm
  • engineering
  • quality
  • regulatory
  • privacy/security

What to say

  • The repo contains the protocol baseline, but I did not find a dedicated controlled consent/sign-off tracker in the current doc set.
  • If protocol or consent are not fully closed, the meeting should identify the last remaining edits and owners, rather than trying to force final sign-off.
  • Protocol review is still worth doing now; it is one of the fastest ways to surface missing requirement, alert, or workflow assumptions before the March 26 review.

Decision needed on March 20

  • Are protocol and consent ready for final sign-off now?
  • If not, what exact edits must be complete before March 26?
  • For each remaining edit, who is the approving authority by domain?

2. Algorithm / Investigational Plan Update

Current state to report

  • Runtime and algorithm implementation work has advanced materially, including:
  • clinical-settings driven algorithm configuration
  • guarded pump-reconnect fallback stepping
  • step-based interruption alerting
  • meal-announce hardening and relaunch-safe lifecycle telemetry
  • The main remaining algorithm risk is formal verification closure, not baseline implementation.

Current verification posture

Main open algorithm items

  • Lock TV-ALG-001..011 protocol definitions and acceptance criteria.
  • Finalize official STR artifact layout for formal algorithm evidence.
  • Add remaining replay vectors and long-run soak coverage.
  • Complete algorithm-owner and clinical-lead review of uncovered-line/branch rationale.
  • Close the final formal verification decision package.
  • Review whether any protocol updates are still needed to reflect implemented algorithm/runtime behavior, especially around alerts, BG handling, and investigational workflow wording.

Decision needed on March 20

  • Confirm whether the current investigational plan is acceptable pending formal verification closure.
  • Confirm who owns the uncovered-branch sign-off and by what date.

Suggested approvers for this section

  • algorithm owner
  • authority: algorithm
  • clinical lead / investigator
  • authority: clinical
  • software engineering lead
  • authority: engineering
  • quality / design assurance owner
  • authority: quality

3. Submission Readiness

Major blockers to surface

  • Controlled quality docs still need final-draft metadata for later review/approval:
  • revision history
  • reviewer / approver fields
  • decision/effective date placeholders
  • draft-language cleanup
  • Several requirements still require explicit disposition:
  • SRS-BG-008
  • SRS-MEAL-004
  • SRS-CLIN-002
  • SRS-SEC-003 through SRS-SEC-009
  • Controlled STP-* protocol docs are still needed to back the TV-* verification layer.
  • RTM closure and formal evidence packaging remain incomplete for multiple in-scope rows.
  • Risk acceptance model and residual-risk sign-off model are not fully closed.
  • Cybersecurity plan is still high-level relative to submission needs.
  • Part 11 device-to-cloud posture is not ready to be claimed closed unless explicitly deferred.

Current outstanding development topics to review

  • alert review and cleanup
  • still worth explicit review because protocol-required alert mapping and alert-drill planning remain open in the execution plan
  • telemetry review
  • worth doing, but only as a submission-critical workstream if cloud telemetry remains in IDE scope; otherwise keep it bounded
  • algorithm request for BG alert flow
  • should be clarified now if protocol or clinical workflow expects specific fingerstick/BG-related guidance or escalation behavior
  • web app analysis / demo current state
  • useful for stakeholder review, but should stay a secondary lane unless the web app is explicitly in IDE baseline scope
  • protocol update review
  • recommended before March 26 so missing operational or safety wording does not get discovered late

Requirement-disposition details to bring

  • SRS-BG-008
  • Requirement text: step 0 BG-rescue would permit algorithm execution from fresh manual BG when fresh in-range CGM is unavailable.
  • Current state: still marked provisional; current implemented baseline is the opposite policy, with CGM-only step 0 locked through SRS-BG-012.
  • Meeting decision needed: formally defer BG-rescue from the IDE baseline, or explicitly approve it and create the associated controlled implementation/verification work. Based on current implementation, the cleanest answer is likely defer.
  • SRS-MEAL-004
  • Requirement text: if meal announce is requested after the next scheduled slot is already due/missed, runtime executes meal input on the current due step instead of rejecting it as too late.
  • Current state: implemented in runtime policy, but the SRS still says it requires explicit clinical/team confirmation before release lock.
  • Meeting decision needed: clinically accept this as release behavior, or change the requirement and implementation back to strict reject-on-late policy.
  • SRS-CLIN-002
  • Requirement text: Clinical Settings access is gated by a passcode prompt; current development default is 020508.
  • Current state: implemented, but explicitly temporary. The SRS already says this must be replaced by authenticated, role-based gating before production release.
  • Meeting decision needed: confirm whether the IDE baseline can carry this as an investigational temporary control, and define the transition/justification language clearly.
  • SRS-SEC-003
  • Requirement text: protected cloud features require authenticated Cognito-managed identity.
  • Current state: still provisional; partial app-side baseline exists.
  • Meeting decision needed: in IDE baseline now, or defer cloud-auth scope.
  • SRS-SEC-004
  • Requirement text: onboarding supports Sign in with Apple, Google, and Email, with final provider mix set by policy.
  • Current state: provisional; current planning does not show final provider-policy lock.
  • Meeting decision needed: lock final allowed provider set for IDE scope.
  • SRS-SEC-005
  • Requirement text: authorization enforces least-privilege role/scope checks for telemetry and dashboard access.
  • Current state: provisional; broader role/authority model still open.
  • Meeting decision needed: either close the role/scope model for IDE or defer this claim.
  • SRS-SEC-006
  • Requirement text: auth/session failures fail closed for protected cloud operations while preserving safe local app behavior.
  • Current state: provisional, but much of the investigational baseline is already implemented.
  • Meeting decision needed: confirm this behavior is accepted and lock wording, or keep it provisional until privacy/security review is complete.
  • SRS-SEC-007
  • Requirement text: email/password onboarding includes code-based password recovery with explicit feedback.
  • Current state: implemented for the current email/password path, but final onboarding policy is still open.
  • Meeting decision needed: keep email/password in final IDE baseline and confirm this recovery path stays in scope.
  • SRS-SEC-008
  • Requirement text: authenticated launch attempts secure session restore/refresh and keeps authenticated UX when restore succeeds.
  • Current state: provisional requirement with implemented investigational baseline.
  • Meeting decision needed: lock this as accepted IDE behavior or mark it as temporary investigational policy.
  • SRS-SEC-009
  • Requirement text: if restore fails while local loop state remains active, Home bypass is allowed for therapy continuity and a persistent login-recovery alert is shown.
  • Current state: provisional requirement with implemented investigational baseline.
  • Meeting decision needed: confirm this continuity policy is acceptable for IDE scope, since it directly affects local therapy continuity versus cloud access expectations.

Primary source docs

  • Use a short blocker list, not a full quality-system walkthrough.
  • Focus on what can realistically be closed before March 26 and what needs explicit defer/scope language.
  • Do not let secondary web/cloud topics consume the main decision lane unless they are explicitly in the IDE baseline.

Suggested approvers for this section

  • quality / design assurance owner
  • authority: quality
  • regulatory / submission owner
  • authority: regulatory
  • privacy / security owner
  • authority: privacy/security
  • software engineering lead
  • authority: engineering

4. Priorities To Address Before March 26

These are the highest-value items to assign immediately after the March 20 meeting:

  1. Lock IDE baseline scope decisions:
  2. cloud telemetry included or deferred
  3. Cognito/auth flows included or deferred
  4. Part 11 claimed now or deferred
  5. offline fallback and reinstall continuity out-of-scope status
  6. Finalize the unresolved SRS-* dispositions and remove provisional/pending language.
  7. Create controlled STP-* protocol documents and map them to in-scope TV-* rows.
  8. Close high-risk RTM rows with formal evidence first.
  9. Complete algorithm-owner and clinical-lead sign-off on the uncovered-branch rationale.
  10. Close or formally defer:
  11. protocol-required alert mapping
  12. manual alert-drill protocol/evidence planning
  13. legal/privacy/consent onboarding content confirmation
  14. Run a focused protocol review/update pass to make sure implemented runtime, alert, and BG/meal behavior are not missing from the study-facing narrative.
  15. Keep web-app review in a bounded parallel lane unless it is explicitly confirmed in IDE scope.

Current recommendation

  • March 20, 2026:
  • assign owners
  • lock include/defer decisions
  • identify final protocol/consent edits
  • March 26, 2026:
  • detailed package review against near-final quality docs and evidence posture
  • week of April 13, 2026:
  • more realistic primary target for IDE package close if dedicated documentation and V&V time is applied
  • week of April 20, 2026:
  • safer contingency target if formal evidence, review cycles, or protocol/consent closure run long

Why this is the safer target

  • formal verification and evidence closure are still active
  • final-draft document-control metadata is still open
  • unresolved requirement dispositions still need explicit approval
  • risk/security and possible Part 11 scope decisions are not fully closed
  • remaining alert/protocol cleanup is still likely to generate wording updates

6. Proposed March 20 Discussion Flow

For the 30-minute meeting, keep the discussion tight:

  1. Protocol and consent sign-off readiness: 5 minutes
  2. Algorithm / investigational plan update: 7 minutes
  3. Top submission blockers: 10 minutes
  4. Priorities before March 26: 5 minutes
  5. Owner assignments and timeline check: 3 minutes

7. Proposed Outputs From The Meeting

Capture these live:

  • final yes/no on protocol readiness
  • final yes/no on consent readiness
  • named owner for software-quality document authoring
  • named owner for controlled-document review/approval/release handling
  • named owner for IDE package construction
  • owner/date for each major blocker
  • explicit IDE baseline defer decisions
  • what must be ready for the March 26 detailed review

8. Pre-Read Packet

Open these during the meeting:

9. Suggested Readout

If you want a short readout in the meeting, use this:

“As of March 20, 2026, the main IDE risk is not basic app feature completeness. The bigger gaps are submission packaging and closure: final-draft package preparation, unresolved requirement dispositions, formal STP/STR evidence closure, algorithm verification sign-off, and remaining risk/security/Part 11 scope decisions. I can drive the software quality docs and technical V&V closure through a handoff-ready final draft package, but we still need explicit ownership for controlled-document review/approval/release handling and the actual IDE package construction. Based on the current workload, mid-April is a more realistic target than early April unless we close scope and ownership decisions immediately.”