(767 days)
Tidepool Loop, a mobile application with algorithm technology, is intended for use with compatible integrated continuous glucose monitors (iCGM) and alternate controller enabled (ACE) insulin infusion pumps to automatically increase, decrease, and suspend delivery of basal insulin based on iCGM readings and predicted glucose values. It can also recommend, and with the user's confirmation, control the delivery of correction boluses when glucose values are predicted to exceed user configurable thresholds.
Tidepool Loop is intended for the management of type 1 diabetes mellitus in persons six years of age and greater.
Tidepool Loop is intended for single patient use.
Tidepool Loop is Rx - For Prescription Use Only.
Tidepool Loop is a mobile application with algorithm technology that works to control an ACE (Alternate Controller Enabled) insulin pump to automatically increase, and suspend delivery of basal insulin based on readings from an iCGM (integrated continuous glucose monitor) and glucose values predicted by Tidepool Loop. Tidepool Loop can also recommend, and with the user's confirmation, control the delivery of correction boluses when glucose values are predicted to exceed user configurable thresholds.
Tidepool Loop predicts glucose levels up to 6 hours in the approximate duration of insulin action for U-100 rapid-acting insulin) based on prior iCGM readings, insulin delivery history, and user input (e.g., carbohydrate intake and exercise, and in some cases fingerstick glucose) and uses that prediction to adjust insulin delivery. Tidepool Loop can be used to adjust or suspend basal insulin delivery every 5 minutes based on actual CGM sensor and predicted glucose readings. iCGM values are automatically used by the Tidepool Loop Bolus Recommendation Tool (TLBRT) when the Tidepool Loop Algorithm technology is active, i.e. when the device is operating in closed-loop mode with an active iCGM sensor session. When closed-loop mode is off, such as when it is manually disabled or when there is no active iCGM sensor session, the Tidepool Loop Bolus Recommendation Tool (TLBRT) is disabled. The user will use Tidepool Loop's simple bolus calculator. into which iCGM values are not automatically populated into the glucose field.
Users must manually enter information about carbohydrates to initiate a meal bolus. When closed-loop mode is on, recommended bolus delivery is calculated using the Tidepool Loop Bolus Recommendation Tool (TLBRT) and can be manually adjusted.
The Tidepool Loop app requires that specific, initial therapy settings are established by a health care provider as part of creating the prescription order. These settings include:
- Target Correction Ranges for normal operation, Pre-Meal and Workout Presets .
- Carb to Insulin Ratios .
- Insulin Sensitivity Factors ●
- Basal Rates ●
- Max Basal Rate ●
- Max Bolus .
Tidepool Loop uses two glucose-specific settings that may be different from the user's experience with traditional glucose monitoring or CGM therapy. These are Correction Range and Glucose Safety Limit.
Correction Range is the range of glucose values that the user wants Tidepool Loop to work to bring their glucose to. Correction Range can be set as low as 87 mg/dL and as high as 180 mg/dL. Tidepool Loop will warn the user if values outside the recommended bounds of 100-115 mg/dL are selected. The user can add different Correction Ranges for different times of day. Tidepool Loop supports up to 48 Correction Range segments in a 24-hour period.
Tidepool Loop allows these user-customizable target Correction Ranges:
- . Normal operation
- Pre-meal Preset
- . Workout Preset
Glucose Safety Limit (mg/dL) is a safety feature of the Tidepool Loop algorithm. If the current CGM value or any future predicted glucose value is below this safety limit. Tidepool Loop will suspend insulin delivery in an effort to prevent low glucose. The algorithm will also not recommend a bolus.
Glucose Safety Limit can be set as low as 67 mg/dL. It can be set as high as 110 mg/dL or to the Correction Range minimum, whichever qlucose value is lower. Tidepool Loop will warn the user if values outside Tidepool's recommended bounds of 74 to 80 mg/dL are selected.
The Glucose Safety Limit is also part of the Dosing Safety Threshold, which is part of the Tidepool Loop insulin delivery algorithm. The Dosing Safety Threshold is a period of time that has the same duration as the insulin activity duration (i.e., 6 hours). The Dosing Safety Threshold is equal to the user's Glucose Safety Limit for the first half of the insulin activity duration (i.e., 3 hours), and then increases until it is at the midpoint of the Correction Range at the end of the insulin activity duration (i.e., 6 hours).
Tidepool Loop is designed to be installed on an iPhone running iOS operating systems (version 15 or higher). The Tidepool Loop application includes an optional extension for Apple Watch devices running watchOS operating system (version 6.1 or higher).
The provided text describes the acceptance criteria and the study that proves the Tidepool Loop device meets these criteria. The device is an Interoperable Automated Glycemic Controller (iAGC) intended for the management of type 1 diabetes mellitus.
Here's a breakdown of the requested information:
1. Table of Acceptance Criteria and Reported Device Performance
The document doesn't explicitly present a formal "acceptance criteria" table with corresponding "reported device performance" values in a single, consolidated format. However, the outcomes of the clinical study, particularly for the 'intended user population', implicitly serve as the performance demonstration against the safety and effectiveness expectations.
Based on the "Summary Diabetes Outcomes" and "Summary Safety Outcomes" for the "Study population limited to intended user population" (Page 19), and further elaborated in the "Results (Intended User Population)" section (Page 22), we can construct the following:
| Performance Metric (Implicit Acceptance Criteria) | Reported Device Performance (Intended User Population) |
|---|---|
| Safety Outcomes | |
| Incidence of Severe Hypoglycemia (SH) | Reduced from 192.0 events per 100 person-years (pre-Loop) to 42.3 events per 100 person-years (during Loop use). |
| Percentage of participants with no SH | 92% from baseline-6 months |
| SH events adjudicated "related to Loop" | 1 SH event (out of 23) |
| Incidence of SH resulting in seizure/loss of consciousness | 0 events per 100 person-years |
| Incidence of Diabetic Ketoacidosis (DKA) | 0.0 events per 100 person-years |
| Glycemic Outcomes (Effectiveness) | |
| Mean Time in Range (TIR) (70-180 mg/dL) | Improved from 62% (baseline) to 70% (1-6 months of use) |
| Mean Time |
§ 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.