Contract analysis

I. Executive Summary This memorandum presents a comprehensive analysis of the software documentation posture for the Solstice Lumina™ Continuous Glucose Monitoring ("CGM") System in preparation for two critical regulatory milestones: (a) the Pre-Submission ("Q-Sub") meeting package targeted for submission to the FDA Center for Devices and Radiological Health ("CDRH") on June 16, 2025, with a meeting anticipated on or

II. Background A. Device and Software Overview The Solstice Lumina™ CGM System is an integrated continuous glucose monitoring system designed for use by adults (18 years and older) with Type 1 or Type 2 diabetes mellitus. The system consists of two device variants that are being submitted as a single 510(k) system: the Lumina C14 subcutaneously implantable continuous glucose monitoring sensor and the Lumina R7 wearab

1. Lumina Firmware v3.4.2 — This is the embedded firmware resident in the C14 sensor's onboard microcontroller. The firmware controls electrochemical signal acquisition from the PtIr-4G enzymatic electrochemical biosensor, analog-to-digital conversion of the raw electrochemical signal, initial signal conditioning (including noise filtering and baseline correction), and BLE 5.2 data transmission to the R7 reader. The

2. Lumina Reader OS v2.1.0 — This is the embedded operating system and application software resident in the R7 arm-worn reader/transmitter. The Reader OS receives BLE data streams from the C14 sensor, executes the LuminaPredict algorithm (discussed separately below), displays real-time glucose values, trend arrows, and 8-hour trend graphs on the R7's integrated display, manages configurable hypo/hyperglycemia alerts

3. LuminaPredict Algorithm v2.1 — This is Solstice's proprietary glucose prediction algorithm, which runs as a software module within the R7 reader's processing environment. The algorithm processes raw sensor signals received from the C14 firmware to produce calibrated glucose readings across a measurement range of 40–400 mg/dL. The algorithm incorporates signal processing, calibration modeling, rate-of-change calcul

4. Lumina Mobile App v1.0.3 — This is the companion mobile application available on iOS and Android platforms. The mobile app receives and displays glucose data from the R7 reader via BLE, provides extended trend history (up to 90 days), data logging functionality, the ability to share glucose data with healthcare providers, and cloud connectivity for data backup and remote access. The mobile app serves as a secondar

III. Software Level of Concern Determination A. Framework FDA's guidance on software contained in medical devices establishes a three-tier framework for determining the "Level of Concern" associated with medical device software. The Level of Concern classification determines the scope and depth of software documentation required in a premarket submission: • Minor Level of Concern: Software that is not directly involv

1. Software Description — A comprehensive overview of the software's purpose, functionality, architecture, and operating environment.

2. Device Hazard Analysis — An analysis of the hazards associated with the device, with specific focus on software-related hazards, conducted in accordance with ISO 14971:2019.

3. Software Requirements Specification (SRS) — A complete specification of all software requirements, including functional requirements, performance requirements, interface requirements, and safety requirements.

4. Architecture Design Chart — A graphical representation of the software architecture showing major modules, interfaces, data flows, and external system interactions.

5. Software Design Specification (SDS) — Detailed design documentation for each software module, including data structures, algorithms, interfaces, and module-level behavior specifications.

6. Traceability Analysis — A bidirectional traceability matrix linking requirements to design elements, and requirements to verification and validation test cases, demonstrating complete coverage.

7. Software Development Environment Description — A description of the hardware and software tools used in the software development process, including compilers, integrated development environments ("IDEs"), version control systems, build tools, and static analysis tools.

8. Verification and Validation Documentation — Complete test protocols, test reports, and test coverage analysis for unit testing, integration testing, and system-level testing.

9. Revision Level History — A complete change log documenting all software versions from initial release through the current version.

10. Unresolved Anomalies List — A list of all known software anomalies (bugs, defects) that remain unresolved at the time of submission, with an assessment of the clinical significance of each anomaly and the rationale for deferring resolution. All of these documents must be provided for each of the four software components. For the Mobile App (classified as Moderate), a subset may be acceptable, but given the argume

IV. IEC 62304:2006/A1:2015 Compliance Assessment A. Software Safety Classification Mapping IEC 62304:2006/A1:2015 uses a three-tier software safety classification system that parallels, but is not identical to, FDA's Level of Concern framework: • Class A: Software system that cannot contribute to a hazardous situation. • Class B: Software system that can contribute to a hazardous situation but cannot result in unacce

V. Current Documentation Inventory and Status This section provides a component-by-component inventory of the software documentation currently in existence, its compliance status, and identified gaps. The inventory is based on our review of documents provided by Solstice engineering, our discussions with Dr. Aisling Burke and Fiona Drennan, and our assessment against FDA's documentation requirements for Major Level o

VI. Detailed Gap Analysis and Remediation Recommendations Based on the documentation inventory presented in Section V, we have identified seven discrete documentation gaps requiring remediation. These are presented below in order of priority, with detailed descriptions, risk assessments, remediation recommendations, timelines, and responsible party assignments. Gap 1: Software Bill of Materials (SBOM) — All Component

VII. SBOM Requirements — Detailed Specification Given the critical importance of the SBOM gap (Gap 1) and the novelty of the SBOM requirement for Solstice's engineering team, this section provides a detailed specification of SBOM requirements to guide the remediation effort. A. Regulatory Basis FDA's guidance document "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submission