CALDERWOOD & HARKNESS LLP 1700 Pennsylvania Avenue, NW, Suite 800 Washington, DC 20006
Healthcare & Life Sciences Practice Group
May 28, 2025
PRIVILEGED & CONFIDENTIAL ATTORNEY-CLIENT PRIVILEGED ATTORNEY WORK PRODUCT
MEMORANDUM
TO: Miriam Calloway, Responsible Partner, Healthcare & Life Sciences, Calderwood & Harkness LLP
CC: Amy Whitfield, Lead Associate, Healthcare & Life Sciences, Calderwood & Harkness LLP Joel Strauss, Billing Partner, Healthcare & Life Sciences, Calderwood & Harkness LLP
FROM: Sean Morrissey, Working Associate, Healthcare & Life Sciences, Calderwood & Harkness LLP
RE: Software Documentation Gap Analysis — Solstice Lumina™ CGM System (Lumina C14 Sensor, Lumina R7 Reader/Transmitter, LuminaPredict Algorithm, Lumina Mobile Application)
CLIENT: Solstice Biomedical Devices Ltd. / Solstice Biomedical Inc.
ENGAGEMENT REFERENCE NO.: 1037-00002
Right-click to update Table of Contents
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 about August 14, 2025; and (b) the ultimate traditional 510(k) submission covering both the Lumina C14 sensor and the Lumina R7 reader/transmitter as a system, targeted for filing on April 30, 2026.
The scope of this analysis encompasses all four software components that constitute the Lumina CGM System's software architecture: (1) Lumina Firmware v3.4.2, embedded in the C14 subcutaneously implantable sensor; (2) Lumina Reader OS v2.1.0, embedded in the R7 wearable reader/transmitter; (3) LuminaPredict Algorithm v2.1, the proprietary glucose prediction algorithm executing on the R7 reader; and (4) Lumina Mobile App v1.0.3, the companion mobile application for iOS and Android platforms.
Overall Assessment. Based on our review of the existing documentation package, correspondence with Solstice engineering leadership, and an analysis of applicable FDA guidance documents and recognized consensus standards, we have reached the following principal conclusions:
• The Software Level of Concern for the Lumina CGM System is Major, driven by the safety-critical nature of the C14 firmware, R7 operating system software, and the LuminaPredict algorithm.
• Several material documentation gaps have been identified that must be remediated prior to the 510(k) submission. The most critical of these are (i) the complete absence of Software Bills of Materials ("SBOMs") across all four software components, and (ii) the lack of standalone, FDA-compliant documentation for the LuminaPredict v2.1 algorithm, which is one of five key technological differences from the primary predicate device and will therefore be subject to heightened FDA scrutiny.
• SBOM preparation is in early stages and requires significant additional effort by the Solstice engineering team. Given the requirements of FDA's September 2023 cybersecurity guidance, the absence of SBOMs represents a submission-blocking deficiency that must be addressed as a matter of first priority.
• IEC 62304:2006/A1:2015 software lifecycle compliance is substantially in place, leveraged from the EU MDR CE certification issued by Meridian Conformity Assessment GmbH (Notified Body 0483), Certificate No. MCA-2024-07319, dated September 12, 2024. However, certain FDA-specific requirements and documentation formatting expectations diverge from the EU documentation package, necessitating targeted adaptation and supplementation.
• All identified gaps are remediable within the current project timeline, provided that focused remediation effort commences immediately and is sustained through the 510(k) submission preparation period.
Coordination Note. Pinnacle Regulatory Consulting Group LLC ("Pinnacle"), specifically Dr. Sandra Ellison and Thomas Greenbaum, is concurrently preparing technical summaries and performance testing protocols for the Lumina CGM System under a separate engagement with Solstice. This memorandum identifies areas where Pinnacle's workstreams and Solstice's internal engineering documentation must be aligned. Section X below provides detailed coordination recommendations to avoid duplication of effort and ensure consistency across the regulatory submission package.
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 wearable reader/transmitter worn on the upper arm. The C14 sensor is designed for a 14-day wear duration (336 hours) and employs a fourth-generation enzymatic electrochemical biosensor with a platinum-iridium ("PtIr-4G") electrode coating to measure interstitial glucose levels. The R7 reader/transmitter receives glucose signal data from the C14 sensor via Bluetooth Low Energy ("BLE") 5.2, processes the raw signal data through the proprietary LuminaPredict algorithm, and displays real-time calibrated glucose values, trend arrows, and 8-hour trend graphs to the user.
Software is embedded in and integral to both device variants, as well as the companion mobile application. The system's clinical utility depends fundamentally on the correct and reliable operation of its software components. No aspect of the Lumina CGM System's core diagnostic function — the measurement and display of calibrated glucose values and the generation of hypo/hyperglycemia alerts — can be accomplished without the software. Accordingly, the software documentation package is a critical element of the 510(k) submission and will be subjected to rigorous FDA review.
The Lumina CGM System comprises four distinct software components, each of which requires independent documentation and assessment:
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 firmware also manages sensor self-diagnostics, power management for the implanted battery, and data encryption for the wireless link. The firmware version has progressed from v1.0.0 (initial development) to the current v3.4.2, with the v3.4.0 to v3.4.2 updates representing the most recent changes, including optimizations to the BLE 5.2 communication stack and improvements to signal conditioning algorithms.
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 with a specified alert latency of five minutes or less, and communicates with the Lumina Mobile App via a separate BLE connection. The Reader OS also manages device pairing, user interface interactions, data storage (up to 90 days of glucose data), and firmware update reception.
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 calculation, and predictive trending. The LuminaPredict algorithm is a core differentiator from the predicate device algorithms — specifically, the NovaSense proprietary algorithms used in the GlucoTrack NX-500 (510(k) No. K211034) and GlucoTrack NX-700 (510(k) No. K230489). As one of the five key technological differences from the primary predicate, the algorithm will receive heightened scrutiny from FDA reviewers, making its documentation completeness and quality a matter of particular importance.
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 secondary display interface for glucose data and provides functionality that extends beyond what is available on the R7 reader's integrated display. The app also generates independent alerts based on configurable thresholds, enabling users to receive notifications on their smartphone.
B. Regulatory Context
The Solstice Lumina™ CGM System is being submitted to FDA through the traditional 510(k) premarket notification pathway as a Class II medical device.
Predicate Devices. Solstice has identified two predicate devices for the substantial equivalence demonstration:
• Primary Predicate: NovaSense GlucoTrack NX-500, 510(k) No. K211034, cleared June 18, 2022. Product code QKQ (Glucose test system, over the counter). Class II. The NX-500 is a 10-day wear CGM system with a subcutaneous sensor and arm-worn reader, using BLE 5.0 for sensor-to-reader communication and a proprietary glucose calculation algorithm.
• Secondary Predicate: NovaSense GlucoTrack NX-700, 510(k) No. K230489, cleared March 7, 2024. Product code QKQ. Class II. The NX-700 is an updated version of the NX-500 with a 14-day wear duration and enhanced algorithm capabilities.
Classification and Regulation. The anticipated regulation number is 21 C.F.R. § 862.1355 (Glucose test system), as updated by the FDA reclassification order effective March 2024. This regulation establishes special controls for integrated CGM systems, including software-related requirements.
Key Differences from Primary Predicate. Solstice has identified five key technological differences between the Lumina CGM System and the primary predicate NX-500 (K211034). Among these, the algorithm difference — LuminaPredict v2.1 versus the NovaSense proprietary algorithm — is of particular significance for the software documentation analysis. Because the algorithm directly affects the clinical performance of the device (i.e., the accuracy, precision, and reliability of glucose readings), FDA will expect robust documentation demonstrating that the algorithmic differences do not raise new questions of safety or effectiveness that are not addressed by the substantial equivalence comparison. This makes the software documentation for the LuminaPredict algorithm a critical element of the overall 510(k) submission strategy.
EU MDR CE Certification. Solstice obtained CE certification under the EU Medical Devices Regulation (EU 2017/745) for the Lumina CGM System through Meridian Conformity Assessment GmbH, Notified Body 0483. The CE certificate, No. MCA-2024-07319, was issued on September 12, 2024. As part of the CE certification process, Solstice substantially complied with the requirements of IEC 62304:2006/A1:2015 (medical device software lifecycle processes) and IEC 62366-1:2015/A1:2020 (usability engineering). The EU MDR technical file contains extensive software documentation that provides a strong foundation for the FDA submission. However, as detailed throughout this memorandum, FDA expectations have specific nuances — both in substance and formatting — that are not fully addressed by the EU documentation package, necessitating targeted supplementation.
C. Applicable FDA Guidance and Standards
The following FDA guidance documents and recognized consensus standards are directly relevant to the software documentation requirements for the Lumina CGM System 510(k) submission:
FDA Guidance Documents:
• "Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices" (current edition) — This is the foundational FDA guidance document for software documentation in 510(k) submissions. It establishes the framework for software level of concern determination and defines the documentation requirements at each level (Minor, Moderate, Major). All software documentation for the Lumina CGM System must comply with this guidance.
• "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions" (September 2023) — This guidance establishes the SBOM requirement and broader cybersecurity documentation expectations for premarket submissions. The cybersecurity-specific requirements are addressed in detail in the companion cybersecurity checklist memorandum being prepared by Amy Whitfield; software-related cybersecurity elements are cross-referenced in this memorandum where relevant.
• "Integrated Continuous Glucose Monitoring Systems" (September 2023) — This guidance contains software-specific expectations for integrated CGM ("iCGM") class devices, including performance requirements (e.g., Mean Absolute Relative Difference ("MARD") ≤ 9.0% for adult populations), algorithm validation expectations, and alert performance specifications. These requirements are directly relevant to the LuminaPredict algorithm documentation and the overall software performance validation framework.
Recognized Consensus Standards:
• IEC 62304:2006/A1:2015 — "Medical device software — Software life cycle processes." This standard is recognized by FDA as a consensus standard and provides the framework for software lifecycle management, including development planning, requirements analysis, architectural design, detailed design, unit implementation and verification, integration testing, system testing, and software release. For Class C software (equivalent to FDA's Major Level of Concern), all clauses of IEC 62304 apply without exception.
• IEC 62366-1:2015/A1:2020 — "Medical devices — Application of usability engineering to medical devices." This standard is relevant to the documentation of software user interface design, usability validation, and the integration of human factors considerations into the software development process. It applies particularly to the R7 Reader OS user interface and the Lumina Mobile App interface.
Applicable Regulations:
• 21 C.F.R. Part 820 (Quality System Regulation) — The design controls requirements of § 820.30 are directly applicable to the software design and development documentation. The traceability analysis required by FDA guidance is an expression of the design controls requirement that design outputs trace to design inputs and that verification and validation activities confirm that design outputs meet design inputs. Compliance with these design controls is a prerequisite for an adequate 510(k) submission.
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 involved in clinical decision-making and for which a failure or latent design defect would not be expected to result in injury to the patient or user, and would not result in erroneous diagnosis or treatment decisions.
• Moderate Level of Concern: Software for which a failure or latent design defect could result in minor injury to the patient or user, or could result in incorrect or delayed diagnosis or treatment that is not expected to cause serious injury.
• Major Level of Concern: Software for which a failure or latent design defect could directly result in death or serious injury to the patient or user, either through the software's direct action or through the provision of erroneous information upon which clinical decisions are based.
The Level of Concern is determined by considering the most severe reasonably foreseeable harm that could result from a software failure, taking into account both the probability of the harm occurring and the severity of the consequences. For systems containing multiple software components, each component is assessed individually, and the overall system Level of Concern is set to the highest level assigned to any individual component.
B. Analysis for Lumina CGM System
We have assessed each of the four software components against FDA's Level of Concern framework. The analysis below reflects our considered judgment, informed by the device's intended use, the role of each software component in the system architecture, and the clinical consequences of software malfunction.
Lumina Firmware v3.4.2 (C14 Sensor): Major. The C14 firmware controls electrochemical signal acquisition from a subcutaneously implanted glucose sensor. The firmware is responsible for the initial capture and conditioning of the raw electrochemical signal upon which all downstream glucose calculations depend. A failure in signal acquisition — whether due to a software defect in the analog-to-digital conversion, signal conditioning, or data transmission modules — could result in fundamentally inaccurate glucose readings being transmitted to the R7 reader. Because the user relies on the displayed glucose value for diabetes management decisions (including insulin dosing), an inaccurate reading caused by a firmware defect could result in missed hypoglycemia or hyperglycemia alerts, leading to potentially life-threatening consequences including severe hypoglycemia (seizures, loss of consciousness, death) or diabetic ketoacidosis. Additionally, a failure in the BLE 5.2 communication module could result in data loss or interrupted communication with the reader, causing gaps in glucose monitoring that could have serious clinical consequences during periods of rapid glucose change. Accordingly, the firmware warrants a Major Level of Concern designation.
Lumina Reader OS v2.1.0 (R7 Reader/Transmitter): Major. The R7 Reader OS executes the glucose prediction algorithm, generates the calibrated glucose values displayed to the user, renders trend arrows and 8-hour trend graphs, and manages the configurable hypo/hyperglycemia alert system upon which patients rely for diabetes management decisions. The reader is the primary user interface through which patients interact with the CGM system. A software defect in the Reader OS could manifest as erroneous glucose readings on the display, incorrect or misleading trend arrows, or — critically — delayed or missed alerts. The alert latency specification is five minutes or less; a software defect that causes alert latency to exceed this threshold during a hypoglycemic episode could result in the patient failing to receive timely warning of dangerously low glucose levels, with potentially fatal consequences. The Reader OS therefore warrants a Major Level of Concern designation.
LuminaPredict Algorithm v2.1: Major. The LuminaPredict algorithm is the core computational engine that converts raw sensor signals into calibrated glucose values. The algorithm directly calculates the glucose concentration displayed to the user across the full measurement range of 40–400 mg/dL. An algorithmic error — whether systematic or intermittent — could produce clinically significant inaccurate glucose values. For example, a systematic bias of even 15–20 mg/dL at low glucose concentrations (40–70 mg/dL) could cause the system to display a glucose value in the normal range when the patient is actually in a hypoglycemic state, resulting in failure to take corrective action. Given that the algorithm is the direct mechanism by which the device produces its clinical output, and given that errors in the algorithm could affect all glucose readings for all users, the LuminaPredict algorithm warrants a Major Level of Concern designation.
Lumina Mobile App v1.0.3: Moderate. The Lumina Mobile App receives and displays glucose data that has already been processed by the R7 reader. In this sense, the app functions as a secondary display rather than the primary means of patient interaction with the CGM system. The primary display is the R7 reader's integrated screen. However, the classification is not straightforward: the mobile app also generates independent alerts based on configurable thresholds, enables data sharing with healthcare providers for clinical decision-making, and provides extended trend history that may influence treatment decisions. There is a reasonable argument that some patients will use the mobile app as their primary interface, particularly those who keep their phone readily accessible but do not continuously monitor the R7 reader display. On balance, we assess the mobile app as warranting at minimum a Moderate Level of Concern designation. We note, however, that FDA may take the position that the app's independent alert functionality and its role in clinical decision support elevate it to Major. This is one of the questions we recommend raising during the Pre-Submission meeting.
Overall System Level of Concern: Major. The overall Level of Concern for the Lumina CGM System software is Major, driven by the classifications of the C14 firmware, R7 Reader OS, and LuminaPredict algorithm. This determination is consistent with the classifications assigned to comparable cleared CGM systems and aligns with FDA's published expectations for integrated CGM software.
Pre-Submission Confirmation. This Level of Concern determination should be confirmed with FDA during the Pre-Submission meeting currently targeted for August 14, 2025. One of the proposed questions in the Pre-Sub package specifically addresses software documentation requirements and the Level of Concern designation. Early confirmation from FDA will enable Solstice to calibrate the documentation effort appropriately and avoid unnecessary rework.
C. Documentation Implications of Major Level of Concern
Under the Major Level of Concern designation, FDA expects the full complement of software documentation to be provided in the premarket submission. Specifically, the following documents are required for each software component classified as Major:
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 arguments for Major classification, we recommend preparing the full documentation set for all four components. The documentation requirements are further specified in Section IX below.
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 unacceptable risk after consideration of risk control measures external to the software.
• Class C: Software system that can contribute to a hazardous situation resulting in unacceptable risk after consideration of all risk control measures, and where the hazardous situation could result in death or serious injury.
For the purposes of aligning the IEC 62304 classification with the FDA Level of Concern determination, the mapping is as follows: FDA Major Level of Concern corresponds to IEC 62304 Class C. This mapping is consistent with FDA's recognition of IEC 62304 as a consensus standard and with the agency's expectation that Class C software documentation will satisfy the Major Level of Concern documentation requirements.
Applying this mapping to the Lumina CGM System components:
• Lumina Firmware v3.4.2: Class C — The firmware controls safety-critical signal acquisition and transmission functions for an implanted sensor. A firmware failure could contribute to a hazardous situation resulting in death or serious injury.
• Lumina Reader OS v2.1.0: Class C — The Reader OS executes the glucose prediction algorithm and generates safety-critical alerts. A software failure could result in erroneous glucose readings or missed alerts, contributing to a hazardous situation with potentially fatal consequences.
• LuminaPredict Algorithm v2.1: Class C — The algorithm directly produces the calibrated glucose value upon which clinical decisions are based. An algorithmic error could result in clinically significant inaccurate readings across the patient population.
• Lumina Mobile App v1.0.3: Class B (possibly Class C) — The mobile app is a secondary display with independent alert functionality. The Class B classification reflects the presence of external risk control measures (the R7 reader serves as the primary display and alert system). However, if FDA determines that patients rely on the app as a primary interface, Class C may be more appropriate. This classification should be revisited following the Pre-Submission meeting.
B. Software Lifecycle Process Review
Solstice's Quality Management System ("QMS") is ISO 13485:2016 certified by Meridian Conformity Assessment GmbH (NB 0483). The software development process was audited as part of the EU MDR CE certification process leading to the issuance of Certificate No. MCA-2024-07319 on September 12, 2024. The audit scope included review of Solstice's software development plan, configuration management plan, and software maintenance plan, all of which were developed for EU MDR compliance and aligned with IEC 62304.
IEC 62304 requires documented processes for each phase of the software development lifecycle. For Class C software (applicable to the Firmware, Reader OS, and LuminaPredict Algorithm), all of the following clauses apply without exception:
• § 5.1 — Software Development Planning: Solstice must maintain a documented software development plan covering all aspects of the development lifecycle.
• § 5.2 — Software Requirements Analysis: Comprehensive requirements analysis must be documented, including functional, performance, interface, and safety requirements.
• § 5.3 — Software Architectural Design: The software architecture must be documented, showing decomposition into software items and the relationships between them.
• § 5.4 — Software Detailed Design: Detailed design of each software unit must be documented, including algorithms, data structures, and interfaces.
• § 5.5 — Software Unit Implementation and Verification: Each software unit must be implemented according to the detailed design and verified against its requirements.
• § 5.6 — Software Integration and Integration Testing: Integration of software units must be planned and tested, with test results documented.
• § 5.7 — Software System Testing: System-level testing must verify that the integrated software meets the software requirements specification.
• § 5.8 — Software Release: A documented release process must be followed, including release notes and configuration identification.
Assessment. Based on our review of the documentation provided by Solstice and our discussions with Dr. Aisling Burke (Solstice CTO) and Fiona Drennan (Solstice Quality Assurance Director), Solstice has documented most lifecycle processes to a level consistent with IEC 62304 Class C requirements. The EU MDR certification process required Meridian Conformity Assessment GmbH to verify compliance with IEC 62304, and the successful issuance of the CE certificate provides substantial assurance that the lifecycle processes are in place. However, as detailed in Sections V and VI below, specific documentation gaps exist within certain lifecycle phases — particularly in the areas of detailed design documentation (§ 5.4) and traceability analysis — that must be addressed for the FDA submission.
C. Software Maintenance Process (§ 6)
IEC 62304 § 6 addresses the software maintenance process, including procedures for problem resolution, analysis of modification requests, implementation of modifications, and change control. Adequate maintenance processes are critical not only for the initial 510(k) submission but also for the post-clearance phase, during which software updates and modifications will be evaluated under FDA's guidance on determining whether a change to a cleared device requires a new 510(k).
Our assessment of Solstice's software maintenance plan indicates that it is generally adequate for IEC 62304 compliance. The plan documents processes for receiving and evaluating problem reports, classifying software problems by severity, implementing corrective modifications, and verifying that modifications do not introduce new defects. The configuration management system (Solstice uses a Git-based version control system with a validated branching and release management workflow) supports the maintenance process.
From an FDA perspective, the maintenance process documentation is relevant to the 510(k) submission because FDA will want assurance that post-clearance software changes will be managed through a validated change control process consistent with the design controls requirements of 21 C.F.R. § 820.30. We recommend that Solstice include a summary of the software maintenance and change control process in the software description section of the 510(k) submission.
D. Software Risk Management Process (§ 7)
IEC 62304 § 7 requires integration of software risk management activities with the overall product risk management process, which should be conducted in accordance with ISO 14971:2019 (Application of risk management to medical devices). The software risk management process must identify potential causes of software contributing to hazardous situations, evaluate the resulting risks, implement and verify risk control measures, and monitor the effectiveness of those measures.
Our review of Solstice's software risk management file, which is integrated into the broader ISO 14971 product risk management file, indicates that it addresses the following categories of software-related hazards with varying levels of completeness:
• Algorithm accuracy risks (LuminaPredict v2.1): The risk file identifies the risk of inaccurate glucose readings due to algorithmic errors. Risk control measures documented include algorithm verification against reference datasets, clinical validation through clinical studies, and post-market surveillance. However, the risk file does not specifically address the risk of algorithmic degradation over the 14-day sensor wear period due to sensor signal drift — a scenario that requires specific algorithmic compensation and represents a distinct hazard. This should be supplemented.
• BLE communication failure modes: The risk file identifies the risk of communication loss between the C14 sensor and R7 reader (BLE 5.2), as well as between the R7 reader and the mobile app (BLE). Risk control measures include automatic reconnection protocols, data buffering, and user alerts for communication interruption. The documentation is generally adequate but should be supplemented with specific analysis of the BLE 5.2 protocol implementation (as distinct from BLE 5.0 used in the predicate devices).
• Sensor Signal drift during 14-day wear duration: The risk file partially addresses this hazard. The 14-day (336-hour) wear duration means that the enzymatic electrochemical sensor is subject to biofouling, membrane degradation, and electrode aging, all of which can cause signal drift that must be compensated by the LuminaPredict algorithm. The risk file should be updated to explicitly document the algorithm's signal drift compensation mechanisms and the residual risk associated with drift that exceeds the algorithm's compensation range.
• Cybersecurity threats: The risk file addresses cybersecurity in a general manner, referencing the STRIDE threat model that Solstice has developed. However, detailed cybersecurity risk analysis is contained in the separate cybersecurity documentation being prepared under the companion cybersecurity premarket submission checklist. Cross-referencing between the software risk management file and the cybersecurity documentation should be formalized.
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 of Concern software.
A. Lumina Firmware v3.4.2 (C14 Sensor)
B. Lumina Reader OS v2.1.0 (R7 Reader/Transmitter)
C. LuminaPredict Algorithm v2.1
D. Lumina Mobile App v1.0.3
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 Components
Gap Description. No SBOM exists for any of the four software components comprising the Lumina CGM System. Per FDA's guidance document "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions" (September 2023), an SBOM is a mandatory element of all premarket submissions for devices containing software, including 510(k) submissions. The SBOM requirement applies regardless of the software's Level of Concern designation.
The SBOM must include, at a minimum: (i) a complete listing of all commercial, open-source, and off-the-shelf software components incorporated into each software deliverable; (ii) for each component, the component name, version number, and manufacturer or developer; (iii) for open-source components, the applicable license type; (iv) known vulnerabilities associated with each component, cross-referenced to the Common Vulnerabilities and Exposures ("CVE") database maintained by MITRE and the National Vulnerability Database ("NVD") maintained by NIST; and (v) the support and end-of-life status of each component (i.e., whether the component is actively maintained and receiving security patches).
The absence of SBOMs across all four software components represents a systemic gap in Solstice's cybersecurity documentation posture. This gap likely reflects the fact that SBOM preparation was not required for the EU MDR CE certification process, as the September 2023 FDA guidance post-dates the initiation of the EU submission and SBOM requirements under EU MDR are addressed differently.
Risk Level: Critical. FDA will not accept the 510(k) submission without compliant SBOMs for all software components. This is a submission-blocking deficiency. Furthermore, if SBOMs are not at least in draft form by the Pre-Submission meeting, FDA may raise concerns during the meeting about Solstice's readiness to address cybersecurity requirements, potentially undermining the credibility of the submission timeline.
Remediation. The following remediation steps are recommended:
(a) Solstice CTO Dr. Aisling Burke and the software engineering team must conduct a comprehensive inventory of all third-party components used across Firmware v3.4.2, Reader OS v2.1.0, LuminaPredict v2.1, and Mobile App v1.0.3. This inventory should be conducted using a combination of manual review and automated software composition analysis ("SCA") tools.
(b) SBOMs should be generated in an industry-standard machine-readable format. We recommend either SPDX (Software Package Data Exchange, ISO/IEC 5962:2021) or CycloneDX (OWASP), both of which are widely accepted by FDA. The choice of format should be confirmed with Pinnacle Regulatory, which may have insight into FDA reviewer preferences based on recent submissions.
(c) Upon completion of the component inventory, a known vulnerability scan should be run against the National Vulnerability Database for all identified third-party components. Any identified vulnerabilities must be assessed for relevance and severity in the context of the Lumina CGM System, and mitigation measures must be documented.
(d) For each component, the support and end-of-life status must be determined. Any components that are no longer actively maintained (i.e., have reached end-of-life or end-of-support) should be flagged for replacement or risk mitigation, as FDA will scrutinize the use of unsupported software components in a premarket submission.
Timeline. SBOMs should be in draft form by August 1, 2025, in advance of the Pre-Submission meeting on August 14, 2025. While the full, finalized SBOMs are not required for the Pre-Sub package (which will include only a summary of the cybersecurity approach and SBOM plans), having draft SBOMs available will enable the team to respond to specific FDA questions and will demonstrate Solstice's progress. Final, submission-ready SBOMs must be completed by March 2026 for inclusion in the April 30, 2026 510(k) submission.
Responsible Parties. Solstice engineering (Dr. Aisling Burke's team) bears primary responsibility for the component inventory and SBOM generation. Pinnacle Regulatory (Thomas Greenbaum) will provide support on formatting and FDA compliance verification. Calderwood & Harkness will review the completed SBOMs for consistency with the cybersecurity premarket submission documentation.
Gap 2: LuminaPredict Algorithm v2.1 — Standalone Documentation
Gap Description. The LuminaPredict Algorithm v2.1 lacks standalone documentation suitable for FDA review. This gap is multifaceted:
(a) The algorithm's requirements are embedded within the R7 Reader OS SRS rather than presented as a standalone Software Requirements Specification. This commingling makes it difficult for FDA reviewers to identify, evaluate, and trace the algorithm-specific requirements independently.
(b) The algorithm design documentation is incomplete. While a high-level algorithmic flow exists, the detailed mathematical model underlying the glucose calculation, the calibration methodology (including how factory calibration parameters are derived and applied), the signal processing pipeline details, the rate-of-change calculation methodology for trend arrow generation, and any descriptions of training data (if the algorithm incorporates machine learning or pattern recognition elements) are not fully documented in a form that would satisfy FDA's expectations for a Major Level of Concern algorithm.
(c) There is no standalone traceability matrix for the algorithm. Without a standalone matrix, the team cannot demonstrate that every algorithm requirement has been traced to a design element and that every requirement has been verified through testing.
(d) The algorithm description does not map algorithm output to clinical performance metrics (MARD, Clarke Error Grid zone distributions, Consensus Error Grid analysis) in the manner FDA reviewers will expect.
The significance of this gap cannot be overstated. The LuminaPredict algorithm is one of the five key technological differences between the Lumina CGM System and the primary predicate device (NovaSense GlucoTrack NX-500, K211034). FDA's substantial equivalence determination will turn in part on whether Solstice can demonstrate that the LuminaPredict algorithm achieves comparable or superior clinical performance to the predicate device's algorithm. Without standalone, comprehensive algorithm documentation, FDA reviewers will not be in a position to make this determination, and the submission is likely to receive an Additional Information ("AI") request — or worse, a Not Substantially Equivalent ("NSE") determination — on the basis of insufficient algorithm documentation.
Risk Level: Significant. Insufficient algorithm documentation could result in an AI request from FDA during 510(k) review, delaying the targeted Q3 2026 clearance date. In a worst-case scenario, it could undermine the substantial equivalence argument.
Remediation. The following standalone documents should be created for the LuminaPredict Algorithm v2.1:
(a) Standalone Algorithm Description Document — A comprehensive description of the algorithm's purpose, inputs, outputs, processing steps, mathematical model, calibration methodology, signal drift compensation approach, rate-of-change calculation method, and edge-case handling (including behavior at the boundaries of the 40–400 mg/dL measurement range). The description should explicitly map algorithm output to clinical performance metrics.
(b) Standalone Software Requirements Specification — Extracted and expanded from the current R7 Reader OS SRS, covering all functional, performance, accuracy, and safety requirements specific to the algorithm.
(c) Detailed Design Document — Including the mathematical model, signal processing flow diagrams, calibration model details, and, if applicable, any machine learning model architecture, training data description, and model validation methodology.
(d) Standalone Traceability Matrix — Linking algorithm requirements to design elements and to verification/validation test cases, demonstrating complete bidirectional traceability.
(e) Standalone Revision History — Consolidating all changes from v1.0 through v2.1 into a single, clear document.
(f) AI/ML Assessment — If the algorithm uses any form of artificial intelligence or machine learning (including but not limited to supervised learning, neural networks, or adaptive algorithms), additional documentation per FDA's "Artificial intelligence/Machine Learning (AI/ML)-Based Software as a Medical Device" framework may be required. Solstice engineering must confirm whether any AI/ML elements are present and, if so, document the predetermined change control plan per FDA's framework.
Timeline. First drafts of all standalone algorithm documents should be completed by July 15, 2025. This timeline is driven by the Pre-Sub meeting date of August 14, 2025 — while full algorithm documentation is not required in the Pre-Sub package, having draft documentation available will enable the team to respond to FDA questions about the algorithm documentation approach with specificity and confidence. Final versions must be completed by March 2026 for inclusion in the 510(k) submission.
Responsible Parties. Solstice engineering (algorithm development team, under Dr. Aisling Burke's direction) bears primary responsibility for the technical content. Pinnacle Regulatory will assist with formatting and FDA compliance verification. Calderwood & Harkness will review the completed documentation for consistency with the substantial equivalence arguments and for regulatory adequacy.
Gap 3: Firmware v3.4.2 — Detailed Design Specification for BLE 5.2 and signal conditioning Modules
Gap Description. The Software Design Specification for the C14 firmware is incomplete at the module level for two specific functional areas: the BLE 5.2 communication stack and the signal conditioning modules. High-level design documentation exists for these modules, but the detailed, module-level design — including data structures, state machines, error handling logic, and interface specifications — has not been fully documented.
This gap is particularly important because the Lumina CGM System uses BLE version 5.2 for sensor-to-reader communication, whereas the primary predicate device (NovaSense GlucoTrack NX-500, K211034) used BLE version 5.0. The BLE version upgrade is one of the technological differences identified between the Lumina system and the predicate. FDA will want to understand the software implementation of the upgraded BLE 5.2 communication protocol, including any differences in data throughput, connection management, error handling, reconnection logic, and security features compared to the BLE 5.0 implementation in the predicate device.
Similarly, the signal conditioning modules represent the first processing step applied to the raw electrochemical sensor signal, and their correct operation is essential to the accuracy of all downstream glucose calculations. Detailed design documentation for these modules is necessary to demonstrate that the signal conditioning approach is sound and does not introduce artifacts or biases that could affect glucose measurement accuracy.
Risk Level: Moderate. While the absence of detailed design documentation for these modules would not, by itself, block the 510(k) submission, it represents a gap that FDA reviewers are likely to identify during their review, potentially resulting in an AI request. Given that BLE 5.2 is a difference from the predicate, FDA may specifically request detailed documentation of the BLE implementation.
Remediation. The Solstice firmware engineering team should complete the module-level SDS for both the BLE 5.2 communication stack and the signal conditioning modules. The documentation should cover, at a minimum:
(a) Module architecture and decomposition into software units;
(b) Data flow diagrams showing the flow of data from the electrochemical sensor through the signal conditioning pipeline and into the BLE transmission buffer;
(c) State machine diagrams for BLE connection management, including pairing, connection establishment, data transmission, error detection, and reconnection logic;
(d) Data integrity assurance mechanisms for wireless transmission, including any checksums, error correction codes, or acknowledgment protocols;
(e) Error handling and fault tolerance mechanisms, including behavior when BLE connection is lost, when signal quality degrades below acceptable thresholds, and when sensor self-diagnostic checks fail;
(f) Detailed algorithm description for signal conditioning, including filter types, filter parameters, and the rationale for the chosen conditioning approach.
Timeline. Completed by July 31, 2025.
Responsible Parties. Solstice firmware engineering team, with review by Dr. Aisling Burke.
Gap 4: Traceability Matrices — Multiple Components
Gap Description. Traceability matrices are incomplete across multiple software components:
(a) Firmware v3.4.2: Requirements-to-test-case traceability is incomplete for firmware features added or modified in the v3.4.0 through v3.4.2 updates. These recent updates — which included optimizations to the BLE 5.2 communication stack and improvements to signal conditioning algorithms — introduced new or modified requirements that have not been fully traced to verification test cases.
(b) Reader OS v2.1.0: Usability-related software requirements (derived from the IEC 62366-1 usability engineering process) are not fully traced to verification and validation test cases. This gap represents an integration failure between the software traceability matrix and the usability engineering file.
(c) LuminaPredict Algorithm v2.1: No standalone traceability matrix exists (as discussed in Gap 2).
(d) Mobile App v1.0.3: Requirements related to cloud data integrity, data synchronization, and privacy features are not fully traced to verification test cases.
Risk Level: Moderate to Significant. Complete, bidirectional traceability is a hallmark of FDA design control compliance under 21 C.F.R. § 820.30. The traceability analysis is one of the documents FDA reviewers examine most closely, because it provides the most efficient means of assessing whether the software has been systematically developed and verified. Gaps in traceability suggest gaps in either the design process or the verification process (or both), which will raise concerns for FDA reviewers. The significance of this gap is elevated by the fact that traceability gaps exist across multiple components, suggesting a systemic rather than isolated issue.
Remediation. All traceability matrices should be updated to achieve full bidirectional traceability: requirements ↔ design elements ↔ verification/validation test cases. The remediation should proceed as follows:
(a) For each component, identify all requirements that lack forward traceability to design elements or test cases, and all test cases that lack backward traceability to requirements.
(b) For requirements lacking test cases, determine whether appropriate test cases exist but are simply not linked in the matrix (a documentation gap), or whether the test cases themselves do not exist (a verification gap requiring test case development and execution).
(c) For the Reader OS usability requirements, coordinate with the usability engineering team to ensure that usability validation test results (from the IEC 62366-1 usability validation study) are properly cross-referenced in the software traceability matrix.
(d) For the LuminaPredict algorithm, develop a standalone traceability matrix as part of the broader Gap 2 remediation effort.
(e) Coordinate with Fiona Drennan (Quality Assurance Director) to ensure that all updated traceability matrices are consistent with the Design History File maintained under Solstice's ISO 13485:2016 QMS.
Timeline. Traceability matrix updates should be completed by September 2025. This allows sufficient time for the matrices to be reviewed and finalized before the 510(k) submission preparation period begins in January 2026.
Responsible Parties. Solstice QA (Fiona Drennan), software engineering teams for each component, and Pinnacle Regulatory for review and formatting.
Gap 5: Mobile App — Cloud Connectivity and Platform Compatibility Documentation
Gap Description. Two related gaps exist in the Mobile App documentation:
(a) Cloud Connectivity Design Documentation: The Software Design Specification for the mobile app does not fully document the cloud data synchronization features, data integrity assurance mechanisms, encryption protocols for cloud communication, and the handling of network interruption and data reconciliation scenarios. These cloud connectivity features were introduced in the v1.0.2 update and have not been fully reflected in the detailed design documentation.
(b) Platform Compatibility / Intended Use Environments: The minimum iOS and Android operating system versions supported by the Lumina Mobile App, and the specific smartphone and tablet device models that have been tested and are supported, are not formally documented in a format suitable for FDA submission. FDA expects clear documentation of the intended use environment for mobile medical applications, including minimum platform requirements, tested device configurations, and any known incompatibilities or limitations.
Risk Level: Moderate. FDA places increasing emphasis on mobile medical application documentation, and the intended use environment specification is a basic expectation. The cloud connectivity design documentation gap is important because cloud-synchronized data is used for provider data sharing and clinical decision support, and FDA will want to understand the mechanisms by which data integrity is assured across the cloud synchronization pathway.
Remediation.
(a) Complete the SDS section on cloud connectivity, covering: cloud architecture overview, data flow between the mobile app and Solstice's cloud infrastructure, data integrity mechanisms (checksums, reconciliation protocols), encryption at rest and in transit (TLS version, cipher suites), authentication and authorization mechanisms, and error handling for network interruptions.
(b) Prepare an Intended Use Environment specification document listing: supported iOS versions (minimum and maximum tested), supported Android versions (minimum and maximum tested), tested device models (smartphone and tablet), minimum hardware specifications (processor, RAM, Bluetooth version), and any known incompatibilities or limitations.
(c) Align the cloud connectivity documentation with the cybersecurity documentation, particularly the STRIDE threat model analysis of the cloud communication pathway.
Timeline. Completed by August 2025.
Responsible Parties. Solstice mobile development team, with support from Pinnacle Regulatory for formatting.
Gap 6: Unresolved Anomalies — Clinical Significance Assessment
Gap Description. Open anomalies exist across multiple software components: seven (7) in the C14 Firmware, three (3) in the R7 Reader OS, and twelve (12) in the Lumina Mobile App, for a total of twenty-two (22) open anomalies across the system. While the existence of unresolved software anomalies at the time of submission is common and acceptable to FDA, each anomaly must be assessed for its potential impact on safety and effectiveness, and the rationale for deferring resolution must be clearly documented.
The Reader OS anomalies have already been assessed by Solstice engineering as non-critical. However, the Firmware and Mobile App anomalies have not been formally assessed for clinical significance in the context of the FDA submission. Without this assessment, FDA reviewers may identify one or more anomalies as potentially safety-relevant, resulting in an AI request or, in a worst case, a request to resolve the anomaly before clearance can be granted.
Risk Level: Low to Moderate. The twelve mobile app anomalies are the most likely source of concern, given the large number of open items. However, many mobile app anomalies are typically cosmetic or related to edge-case behavior on specific platform configurations and are unlikely to have clinical significance.
Remediation. Conduct a formal clinical significance triage of all twenty-two open anomalies. For each anomaly:
(a) Determine whether the anomaly could result in an erroneous glucose reading, a missed or delayed alert, incorrect trend information, data corruption, or any other clinically meaningful consequence.
(b) Assign a clinical significance classification (e.g., no clinical significance; minor clinical significance, mitigated by [specified risk control]; significant clinical significance, planned for resolution in [specified software update]).
(c) For anomalies assessed as having no clinical significance, document the rationale.
(d) For anomalies assessed as having some clinical significance, document the risk assessment per ISO 14971 and the risk control measures that mitigate the risk to an acceptable level.
(e) Compile the results into a summary table for inclusion in the 510(k) submission as part of the Unresolved Anomalies List for each component.