(415 days)
The iLet Dosing Decision Software is intended for use with compatible integrated continuous glucose monitors (iCGM) and alternate controller enabled (ACE) pumps. A self-monitoring of blood glucose (SMBG) meter may also be used for manual input of blood glucose values to continue insulin dosing for a limited period of time when input from the iCGM is temporarily not available. The iLet Dosing Decision Software autonomously determines and commands an increase, decrease, maintenance, or suspension of all basal doses of insulin and autonomously determines and commands correction doses of insulin based on input from an iCGM, and it autonomously determines and commands meal doses of insulin based on meal announcements. iLet Dosing Decision Software is intended for the management of type 1 diabetes mellitus in people 6 years of age or older. iLet Dosing Decision Software is intended for single patient use and requires a prescription.
The iLet Dosing Decision Software is an iAGC indicated for the management of type 1 diabetes mellitus. It autonomously determines and commands an increase, decrease, maintenance, or suspension of all basal doses of insulin and autonomously determines and commands correction doses of insulin based on input from an iCGM, and it autonomously determines and commands meal doses of insulin based on meal announcements. The iLet Dosing Decision Software is intended for the management of type 1 diabetes in people 6 years of age or older. The iLet Dosing Decision Software works in conjunction with a compatible alternate controller enabled (ACE) pump. The dosing decision software includes adaptive control algorithms that autonomously and continually adapt to the ever-changing insulin requirements of each individual to enable lifelong adaptive learning. The iLet Dosing Decision Software only requires initialization with the user's body mass (body weight). The iLet Dosing Decision Software does not require carbohydrate counting by the user or the use of carbohydrate- to-insulin ratios. Although the iLet system does not require a user to enter an exact carb amount to calculate and administer a meal bolus, it does require that the user announce the meal (e.g., breakfast, lunch, dinner) AND provide an estimated carb content as "Usual", "More", or "Less" than is routine for that meal type. The iLet Dosing Decision Software does not require any information about the user's total daily dose of insulin, basal or long-acting insulin requirements, or insulin correction factors. It is an insulin titration system that requires no insulin-dose determinations by the user or provider. During normal operation, the iLet bionic pancreas (iLet ACE Pump with the iLet Dosing Decision Software installed) autonomously responds every five minutes to a glucose signal, from an iCGM that is worn by the user, by computing a control signal that translates to a dose of insulin, which is intended to be delivered to the user through the subcutaneous (SC) route. The iLet dosing decision software has three insulin controllers (algorithms) running in parallel: an adaptive basal insulin controller, which continually adapts to each individual's basal metabolic need for insulin, an adaptive bolus controller which provides doses that are required above and beyond the basal metabolic needs, and an adaptive meal dose controller which provides insulin in response to a meal announcement. The iLet is intended to dose insulin based on CGM data. In the events where CGM stops providing glucose data to the iLet Dosing Decision Software BG-run mode feature will serve to temporarily continue insulin delivery. BG-run mode will determine and command basal insulin based on past requirements and will allow announcement of meals and entry of fingerstick BG measurements, which will be treated as iCGM data and may result in commanding administration of insulin or temporary suspension of basal insulin. BG-run mode use should always be for the shortest duration possible with the goal to resume CGM.
The provided text describes the iLet® Dosing Decision Software, an interoperable automated glycemic controller (iAGC), and the study conducted to demonstrate its performance.
Here's an analysis of the acceptance criteria and study as requested:
1. A table of acceptance criteria and the reported device performance
The document doesn't explicitly list "acceptance criteria" in a bulleted or numbered format with corresponding performance metrics like a typical FDA performance table. However, the "Endpoints" section in the Clinical Performance summary serves as the de facto acceptance criteria for the clinical study outcomes. The "Conclusions" section then describes how the device performed against these.
| Acceptance Criteria (Study Endpoint) | Reported Device Performance (Conclusion) |
|---|---|
| Primary Endpoint: | |
| HbA1c at 13 weeks | The study concluded that use of the bionic pancreas (with iLet Dosing Decision Software) with Novolog/Humalog or Fiasp was safe when compared with standard of care. (Implicitly, the changes in HbA1c in the iLet group were considered clinically acceptable and superior based on results not fully detailed in this summary for the exact change, but the substantial equivalence claim implies positive results.) |
| Key Secondary Endpoints: | |
| Time 180 mg/dL | (Details not explicitly provided in the "Conclusion" section of the summary, but implied to be acceptable for safety and efficacy.) |
| Time > 250 mg/dL | (Details not explicitly provided in the "Conclusion" section of the summary, but implied to be acceptable for safety and efficacy.) |
| Standard deviation | (Details not explicitly provided in the "Conclusion" section of the summary, but implied to be acceptable for safety and efficacy.) |
| Additional CGM metrics | (Details not explicitly provided in the "Conclusion" section of the summary, but implied to be acceptable for safety and efficacy.) |
| Safety Outcomes: | |
| Severe hypoglycemia | Use of the bionic pancreas was safe when compared with standard of care. |
| Diabetic ketoacidosis (DKA) | Two DKA events occurred in the iLet Group related to infusion set failures (not directly attributed to the software's dosing decision). Overall, the conclusion states it was "safe". |
| Other serious adverse events | Use of the bionic pancreas was safe when compared with standard of care. |
| BG-run feature performance (Ancillary Study) | The bionic pancreas can be safely used with blood glucose meter input temporarily instead of CGM should this become necessary for a user. |
2. Sample size used for the test set and the data provenance (e.g. country of origin of the data, retrospective or prospective)
- Sample Size for the Clinical Study (RCT): 440 adult and child participants.
- Country of Origin: United States (16 clinical sites).
- Study Design: Prospective, multi-center, randomized controlled trial (RCT).
- Ancillary Study (BG-run feature): Participants in the BP Groups had the option of participating in this ancillary study, but a specific sample size for this ancillary study is not provided, only that it followed the RCT.
3. Number of experts used to establish the ground truth for the test set and the qualifications of those experts (e.g. radiologist with 10 years of experience)
This information is not provided in the document. The ground truth for the clinical study was established by the actual physiological responses and clinical outcomes of the participants with Type 1 Diabetes, measured by standard medical metrics (HbA1c, CGM data, adverse events). There is no mention of external experts establishing a "ground truth" for the device's dosing decisions themselves, as the device is designed to operate autonomously. The study evaluated the effectiveness and safety of the device's autonomous decisions.
4. Adjudication method (e.g. 2+1, 3+1, none) for the test set
This is not applicable to this type of study. Adjudication methods like 2+1 or 3+1 refer to expert consensus processes for evaluating medical images or diagnoses, typically used when establishing ground truth for AI algorithms in diagnostic imaging. For this device, which makes automated dosing decisions for diabetes management, the "ground truth" is physiological response, not expert interpretation. Adverse events would typically be adjudicated by a Clinical Events Committee (CEC), but the specific method (e.g., how many members reviewed each event) is not detailed.
5. If a multi reader multi case (MRMC) comparative effectiveness study was done, If so, what was the effect size of how much human readers improve with AI vs without AI assistance
- A Multi-Reader Multi-Case (MRMC) comparative effectiveness study was not done.
- This type of study is primarily relevant for diagnostic imaging AI where human readers interpret medical images. The iLet Dosing Decision Software is an automated glycemic controller, not an imaging interpretation aid.
- The study was a randomized controlled trial comparing the iLet system (which is the AI, managing insulin autonomously) to "standard care" (human-managed insulin delivery, either by pump or injections, though with CGM monitoring). It assesses the device's performance versus standard human-led care, not how human readers improve with AI assistance.
6. If a standalone (i.e. algorithm only without human-in-the-loop performance) was done
- Yes, a standalone study was done in the sense that the iLet Dosing Decision Software operates autonomously, commanding insulin doses without real-time human intervention in its decision-making process. The clinical trial directly evaluated this autonomous "algorithm only" performance within the iLet Bionic Pancreas System.
- The comparison was between the iLet system (operating autonomously) and standard human-managed care.
7. The type of ground truth used (expert consensus, pathology, outcomes data, etc)
The ground truth for evaluating the iLet Dosing Decision Software's performance in the clinical study was primarily outcomes data and physiological measurements:
- HbA1c (a measure of average blood glucose over time).
- Continuous Glucose Monitoring (CGM) metrics (e.g., time in target range, time spent in hypo/hyperglycemia, mean glucose, standard deviation).
- Safety outcomes (severe hypoglycemia, diabetic ketoacidosis, other serious adverse events).
8. The sample size for the training set
The document does not provide information regarding the sample size used for the training set of the iLet Dosing Decision Software algorithm. It only details the clinical study for validation of the device.
9. How the ground truth for the training set was established
The document does not provide information on how the ground truth for the training set was established. The iLet Dosing Decision Software employs "adaptive control algorithms that autonomously and continually adapt to the ever-changing insulin requirements of each individual to enable lifelong adaptive learning." This suggests a machine learning or adaptive control approach, which would have been trained on or developed using a dataset, but the specifics of that training data and ground truth establishment are not disclosed in this summary.
§ 862.1356 Interoperable automated glycemic controller.
(a)
Identification. An interoperable automated glycemic controller is a device intended to automatically calculate drug doses based on inputs such as glucose and other relevant physiological parameters, and to command the delivery of such drug doses from a connected infusion pump. Interoperable automated glycemic controllers are designed to reliably and securely communicate with digitally connected devices to allow drug delivery commands to be sent, received, executed, and confirmed. Interoperable automated glycemic controllers are intended to be used in conjunction with digitally connected devices for the purpose of maintaining glycemic control.(b)
Classification. Class II (special controls). The special controls for this device are:(1) Design verification and validation must include:
(i) An appropriate, as determined by FDA, clinical implementation strategy, including data demonstrating appropriate, as determined by FDA, clinical performance of the device for its intended use, including all of its indications for use.
(A) The clinical data must be representative of the performance of the device in the intended use population and in clinically relevant use scenarios and sufficient to demonstrate appropriate, as determined by FDA, clinical performance of the device for its intended use, including all of its indications for use.
(B) For devices indicated for use with multiple therapeutic agents for the same therapeutic effect (
e.g., more than one type of insulin), data demonstrating performance with each product or, alternatively, an appropriate, as determined by FDA, clinical justification for why such data are not needed.(C) When determined to be necessary by FDA, the strategy must include postmarket data collection to confirm safe real-world use and monitor for rare adverse events.
(ii) Results obtained through a human factors study that demonstrates that an intended user can safely use the device for its intended use.
(iii) A detailed and appropriate, as determined by FDA, strategy to ensure secure and reliable means of data transmission with other intended connected devices.
(iv) Specifications that are appropriate, as determined by FDA, for connected devices that shall be eligible to provide input to (
e.g., specification of glucose sensor performance) or accept commands from (e.g., specifications for drug infusion pump performance) the controller, and a detailed strategy for ensuring that connected devices meet these specifications.(v) Specifications for devices responsible for hosting the controller, and a detailed and appropriate, as determined by FDA, strategy for ensuring that the specifications are met by the hosting devices.
(vi) Documentation demonstrating that appropriate, as determined by FDA, measures are in place (
e.g., validated device design features) to ensure that safe therapy is maintained when communication with digitally connected devices is interrupted, lost, or re-established after an interruption. Validation testing results must demonstrate that critical events that occur during a loss of communications (e.g., commands, device malfunctions, occlusions, etc.) are handled and logged appropriately during and after the interruption to maintain patient safety.(vii) A detailed plan and procedure for assigning postmarket responsibilities including adverse event reporting, complaint handling, and investigations with the manufacturers of devices that are digitally connected to the controller.
(2) Design verification and validation documentation must include appropriate design inputs and design outputs that are essential for the proper functioning of the device that have been documented and include the following:
(i) Risk control measures to address device system hazards;
(ii) Design decisions related to how the risk control measures impact essential performance; and
(iii) A traceability analysis demonstrating that all hazards are adequately controlled and that all controls have been validated in the final device design.
(3) The device shall include appropriate, as determined by FDA, and validated interface specifications for digitally connected devices. These interface specifications shall, at a minimum, provide for the following:
(i) Secure authentication (pairing) to connected devices;
(ii) Secure, accurate, and reliable means of data transmission between the controller and connected devices;
(iii) Sharing of necessary state information between the controller and any connected devices (
e.g., battery level, reservoir level, sensor use life, pump status, error conditions);(iv) Ensuring that the controller continues to operate safely when data is received in a manner outside the bounds of the parameters specified;
(v) A detailed process and procedures for sharing the controller's interface specification with connected devices and for validating the correct implementation of that protocol; and
(vi) A mechanism for updating the controller software, including any software that is required for operation of the controller in a manner that ensures its safety and performance.
(4) The device design must ensure that a record of critical events is stored and accessible for an adequate period to allow for auditing of communications between digitally connected devices, and to facilitate the sharing of pertinent information with the responsible parties for those connected devices. Critical events to be stored by the controller must, at a minimum, include:
(i) Commands issued by the controller, and associated confirmations the controller receives from digitally connected devices;
(ii) Malfunctions of the controller and malfunctions reported to the controller by digitally connected devices (
e.g., infusion pump occlusion, glucose sensor shut down);(iii) Alarms and alerts and associated acknowledgements from the controller as well as those reported to the controller by digitally connected devices; and
(iv) Connectivity events (
e.g., establishment or loss of communications).(5) The device must only receive glucose input from devices cleared under § 862.1355 (integrated continuous glucose monitoring system), unless FDA determines an alternate type of glucose input device is designed appropriately to allow the controller to meet the special controls contained within this section.
(6) The device must only command drug delivery from devices cleared under § 880.5730 of this chapter (alternate controller enabled infusion pump), unless FDA determines an alternate type of drug infusion pump device is designed appropriately to allow the controller to meet the special controls contained within this section.
(7) An appropriate, as determined by FDA, training plan must be established for users and healthcare providers to assure the safety and performance of the device when used. This may include, but not be limited to, training on device contraindications, situations in which the device should not be used, notable differences in device functionality or features compared to similar alternative therapies, and information to help prescribers identify suitable candidate patients, as applicable.
(8) The labeling required under § 809.10(b) of this chapter must include:
(i) A contraindication for use in pediatric populations except to the extent clinical performance data or other available information demonstrates that it can be safely used in pediatric populations in whole or in part.
(ii) A prominent statement identifying any populations for which use of this device has been determined to be unsafe.
(iii) A prominent statement identifying by name the therapeutic agents that are compatible with the controller, including their identity and concentration, as appropriate.
(iv) The identity of those digitally connected devices with which the controller can be used, including descriptions of the specific system configurations that can be used, per the detailed strategy submitted under paragraph (b)(1)(iii) of this section.
(v) A comprehensive description of representative clinical performance in the hands of the intended user, including information specific to use in the pediatric use population, as appropriate.
(vi) A comprehensive description of safety of the device, including, for example, the incidence of severe hypoglycemia, diabetic ketoacidosis, and other relevant adverse events observed in a study conducted to satisfy paragraph (b)(1)(i) of this section.
(vii) For wireless connection enabled devices, a description of the wireless quality of service required for proper use of the device.
(viii) For any controller with hardware components intended for multiple patient reuse, instructions for safely reprocessing the hardware components between uses.