(130 days)
SmartGuard technology is intended for use with compatible integrated continuous glucose monitors (iCGM), compatible Medtronic continuous glucose monitors (CGMs), and alternate controller enabled (ACE) pumps to automatically adjust the delivery of basal insulin and to automatically deliver correction boluses based on sensor glucose values.
SmartGuard technology is intended for the management of Type 1 diabetes mellitus in persons 7 years of age and older requiring insulin.
SmartGuard technology is intended for single patient use and requires a prescription.
Predictive Low Glucose technology is intended for use with compatible integrated continuous glucose monitors (iCGM), compatible Medtronic continuous glucose monitors (CGMs), and alternate controller enabled (ACE) pumps to automatically suspend delivery of insulin when the sensor glucose value falls below or is predicted to fall below predefined threshold values.
Predictive Low Glucose technology is intended for the management of Type 1 diabetes mellitus in persons 7 years of age and older requiring insulin.
Predictive Low Glucose technology is intended for single patient use and requires a prescription.
SmartGuard Technology, also referred to as Advanced Hybrid Closed Loop (AHCL) algorithm, is a software-only device intended for use by people with Type 1 diabetes for ages 7 years or older. It is an interoperable automated glycemic controller (iAGC) that is intended for use with compatible integrated continuous glucose monitors (iCGM), compatible interoperable Medtronic continuous glucose monitors (CGM) and compatible alternate controller enabled (ACE) pumps to automatically adjust the delivery of basal insulin and to automatically deliver correction boluses based on sensor glucose (SG) values.
The AHCL algorithm resides on the compatible ACE pump, which serves as the host device. It is meant to be integrated in a compatible ACE pump and is an embedded part of the ACE pump firmware.
Inputs to the AHCL algorithm (e.g., SG values, user inputs) are received from the ACE pump (host device), and outputs from the AHCL algorithm (e.g., insulin delivery commands) are sent by the algorithm to the ACE pump. As an embedded part of the firmware, the AHCL algorithm does not connect to or receive data from compatible CGMs; instead, sensor glucose (SG) values or other inputs received by the ACE pump from compatible CGMs via Bluetooth Low Energy (BLE) technology are transmitted to the embedded AHCL algorithm.
The AHCL algorithm works in conjunction with the ACE pump and is responsible for controlling insulin delivery when the ACE pump is in Auto Mode. It includes adaptive control algorithms that autonomously and continually adapt to the ever-changing insulin requirements of each individual.
The AHCL algorithm requires specific therapy settings (target setpoint, insulin-to-carb ratios and active insulin time) that need to be established with the help of a health care provider (HCP) before activation. It also requires five (5) consecutive hours of insulin delivery history, a minimum of two (2) days of total daily dose (TDD) of insulin, a valid sensor glucose (SG) and blood glucose (BG) values to start automated insulin delivery.
When activated, the AHCL algorithm adjusts the insulin dose at five-minute intervals based on CGM data. A basal insulin dose (auto basal) is commanded by the AHCL algorithm to manage glucose levels to the user's target setpoint of 100 mg/dL, 110 mg/dL or 120 mg/dL. The user can also set a temporary target of 150 mg/dL for up to 24 hours. In addition, under certain conditions the algorithm can also automatically command correction boluses (auto correction bolus) without user input.
Meal boluses are the responsibility of the user. The AHCL algorithm includes an integrated bolus calculation feature for user-initiated boluses for meals. When the user inputs their carbohydrate intake, the AHCL algorithm automatically calculates a bolus amount based off available glucose information, entered carbohydrate amount and other patient parameters.
The AHCL algorithm contains several layers of "safeguards" (mitigations) to provide protection against over-delivery or under-delivery of insulin to reduce risk of hypoglycemia and hyperglycemia, respectively.
The AHCL algorithm is a software-only device and does not have a user interface (UI). The compatible ACE pump provides a UI to the user to configure the therapy settings and interact with the algorithm. The AHCL-related alerts/alarms are displayed and managed by the pump.
Predictive Low Glucose Technology, also referred to as the Predictive Low Glucose Management (PLGM) algorithm is a software-only device intended for use by people with Type 1 diabetes for ages 7 years or older. It is an interoperable automated glycemic controller (iAGC) that is intended for use with compatible integrated continuous glucose monitors (iCGM), compatible interoperable Medtronic continuous glucose monitors (CGM) and compatible alternate controller enabled (ACE) pumps to automatically suspend delivery of insulin when the sensor glucose value falls below or is predicted to fall below predefined threshold values.
The PLGM algorithm resides on the compatible ACE Pump, which serves as the host device. It is meant to be integrated in a compatible ACE pump and is an embedded part of the ACE pump firmware.
Inputs to PLGM algorithm (e.g., sensor glucose values, user inputs) are received from the ACE pump (host device), and outputs from PLGM algorithm (e.g., suspend/resume commands) are sent by the algorithm to the ACE pump. As an embedded part of the ACE pump firmware, the PLGM algorithm does not connect to or receive data from compatible CGMs; instead, sensor glucose (SG) values or other inputs are received by the ACE pump from compatible CGMs via Bluetooth Low Energy (BLE) technology are transmitted to the embedded PLGM algorithm.
The PLGM algorithm works in conjunction with the ACE pump. When enabled, the PLGM algorithm is able to suspend insulin delivery for a minimum of 30 minutes and for a maximum of 2 hours based on current or predicted sensor glucose values. It will automatically resume insulin delivery when maximum suspend time of 2 hours has elapsed or when underlying conditions resolve. The user is also able to manually resume insulin at any time.
The PLGM algorithm is a software-only device and does not have a user interface (UI). The compatible ACE pump provides the UI to configure therapy settings and interact with the algorithm. The PLGM-related alerts/alarms are displayed and managed by the pump.
The provided FDA 510(k) clearance letter and supporting documentation detail the acceptance criteria and the studies conducted to prove that Medtronic's SmartGuard Technology and Predictive Low Glucose Technology meet these criteria.
It's important to note that the provided text focuses on demonstrating substantial equivalence to a predicate device, as is typical for 510(k) submissions, rather than establishing de novo acceptance criteria for an entirely novel device. The "acceptance criteria" here refer to the performance benchmarks that demonstrate safety and effectiveness comparable to the predicate and compliance with regulatory special controls.
Here's an analysis of the acceptance criteria and the study that proves the device meets them, based on the provided text:
Acceptance Criteria and Device Performance
The acceptance criteria are generally implied by the comparative data presented against the predicate device (Control-IQ Technology) and the compliance with "iAGC Special Controls requirements defined in 21 CFR 862.1356." The clinical study primarily aims to demonstrate non-inferiority or beneficial outcomes in key glycemic metrics compared to baseline (run-in period).
Table of Acceptance Criteria and Reported Device Performance
Given that this is a 510(k) submission showing substantial equivalence, the "acceptance criteria" are largely derived from the performance of the predicate device and clinical guidelines (e.g., ADA guidelines for Time Below Range). While specific numerical thresholds for acceptance are not explicitly listed as "acceptance criteria" in a table format within the provided text, the results presented serve as the evidence that these implicit criteria are met.
For the purpose of this response, I will synthesize the implied performance targets from the "Pivotal Study Observed Results" and "Supplemental Clinical Data" sections and present the device's reported performance against them.
Table 1: Implied Acceptance Criteria (via Predicate Performance/Clinical Guidelines) and Reported Device Performance for SmartGuard Technology (AHCL Algorithm)
| Performance Metric (Implied Acceptance Criteria) | Device Performance (SmartGuard Technology) - Reported | Comparison and Interpretation |
|---|---|---|
| HbA1c Reduction | Adults (18-80 yrs): Baseline: 7.4% ± 0.9. End of Study: 6.7% ± 0.5. | Shows a mean reduction of 0.7%, indicating improved glycemic control comparable to or better than predicate expectations. |
| Pediatrics (7-17 yrs): Baseline: 7.7% ± 1.0. End of Study: 7.3% ± 0.8. | Shows a mean reduction of 0.4%, indicating improved glycemic control. | |
| Percentage of subjects with HbA1c 180 mg/dL | Adults (18-80 yrs): Decrease from 31.8% ± 13.1 (run-in) to 18.2% ± 8.4 (Stage 3). | Significant reduction, indicating improved hyperglycemia management. |
| Pediatrics (7-17 yrs): Decrease from 44.0% ± 16.1 (run-in) to 26.7% ± 10.1 (Stage 3). | Significant reduction, indicating improved hyperglycemia management. | |
| Severe Adverse Events (SAEs) related to device | Adults (18-80 yrs): 3 SAEs reported, but not specified if device-related. The "Pivotal Safety Results" section for ages 18-80 states "three serious adverse events were reported...". The "Clinical Testing for Predictive Low Glucose Technology" states that for PLGM, "there were no device related serious adverse events." Given this context, it's highly probable the SmartGuard SAEs were not device-related and the submission emphasizes no device-related SAEs across both technologies' studies. | Absence of device-related SAEs is a critical safety criterion. |
| Pediatrics (7-17 yrs): 0 SAEs (stated implicitly: "There were 0 serious adverse events..."). | Absence of device-related SAEs is a critical safety criterion. | |
| Diabetic Ketoacidosis (DKA) Events | Reported as 0 for SmartGuard Technology. | Absence of DKA events is a critical safety criterion. |
| Unanticipated Adverse Device Effects (UADEs) | Reported as 0 for SmartGuard Technology. | Absence of UADEs is a critical safety criterion. |
Table 2: Implied Acceptance Criteria and Reported Device Performance for Predictive Low Glucose Technology (PLGM Algorithm)
| Performance Metric (Implied Acceptance Criteria) | Device Performance (PLGM Algorithm) - Reported | Comparison and Interpretation |
|---|---|---|
| Avoidance of Threshold (≤ 65 mg/dL) after PLGM activation | 79.7% of cases (pediatric study). | Demonstrates effectiveness in preventing severe hypoglycemia. |
| Mean Reference Glucose Value 120 min post-suspension | 102 ± 34.6 mg/dL (adult study). | Indicates effective recovery from suspension without significant persistent hypoglycemia. |
| Device-related Serious Adverse Events | 0 reported. | Critical safety criterion. |
| Diabetic Ketoacidosis (DKA) Events related to PLGM | 0 reported. | Critical safety criterion. |
| Unanticipated Adverse Device Effects (UADEs) | 0 reported. | Critical safety criterion. |
Study Details
1. Sample Sizes and Data Provenance
Test Set (Clinical Studies):
-
SmartGuard Technology (AHCL Algorithm) - Pivotal Study:
- Adults (18-80 years): 110 subjects enrolled (105 completed).
- Pediatrics (7-17 years): 112 subjects enrolled (107 completed).
- Total: 222 subjects enrolled (212 completed).
- Provenance: Multi-center, single-arm study conducted across 25 sites in the U.S. This implies prospective data collection, specifically designed for this regulatory submission. Home-setting study.
-
Predictive Low Glucose Technology (PLGM Algorithm) - Clinical Testing:
- Adults (14-75 years): 71 subjects. In-clinic study.
- Pediatrics (7-13 years): 105 subjects. In-clinic evaluation.
- Total: 176 subjects.
- Provenance: Multi-center, single-arm, in-clinic studies. Location not explicitly stated but part of a US FDA submission, implying US or international sites adhering to FDA standards. Prospective data.
Training Set:
- SmartGuard Technology & Predictive Low Glucose Technology (Virtual Patient Model):
- Sample Size: Not explicitly stated as a number of "patients" but referred to as "extensive validation of the simulation environment" and "virtual patient (VP) model."
- Data Provenance: In-silico simulation studies using Medtronic Diabetes' simulation environment. This is synthetic data generated by computational models, validated against real patient data.
2. Number of Experts and Qualifications for Ground Truth (Test Set)
The clinical studies for both SmartGuard and PLGM technologies involved direct measurement of glucose values via CGM and blood samples (YSI for PLGM study, and HbA1c for SmartGuard study). These are objective physiological measures, not subjective interpretations requiring external expert consensus for "ground truth."
- For SmartGuard Technology: Glucose values were measured by the Simplera Sync CGM and HbA1c by laboratory tests. These are considered objective measures of glycemic control.
- For Predictive Low Glucose Technology: Hypoglycemia induction was monitored with frequent sample testing (FST) and frequent blood sampling for glucose measurements (likely laboratory-grade methods like YSI [Yellow Springs Instrument]).
- Expert involvement: While healthcare professionals (investigators, study coordinators, endocrinologists, nurses) were undoubtedly involved in conducting the clinical studies, managing patient care, and interpreting results, their role was not to establish "ground truth" through consensus or adjudication in the sense of image review. The ground truth was physiological measurements.
3. Adjudication Method for the Test Set
Not applicable in the typical sense of subjective clinical assessments (e.g., radiology image interpretation). Ground truth was established by direct physiological measurements (CGM data, HbA1c, YSI/FST blood glucose). The clinical studies were single-arm studies where subject outcomes were measured, not comparative assessments where multiple readers adjudicate on decisions.
4. Multi-Reader Multi-Case (MRMC) Comparative Effectiveness Study
No, an MRMC comparative effectiveness study was not described. The clinical studies were single-arm (evaluating the device's performance in a standalone setting against a baseline or predefined safety/efficacy metrics) and did not involve human readers interpreting data from the device to make clinical decisions and then comparing human performance with and without AI assistance. Instead, the AI (algorithm) directly controlled insulin delivery and was evaluated based on patient physiological outcomes.
5. Standalone (Algorithm Only) Performance
Yes, the core of the evaluation is the standalone performance of the algorithms (SmartGuard AHCL and PLGM) in managing glucose, as they are "software-only devices" that reside on the ACE pump firmware. The clinical studies directly measured the physiological impact of the algorithm's actions on glucose levels, HbA1c, and safety parameters in a human population.
6. Type of Ground Truth Used
-
Clinical Studies (SmartGuard & PLGM): Objective Physiological Measurements
- Sensor Glucose (SG) values: From compatible CGMs (Simplera Sync CGM, Guardian 4 CGM)
- HbA1c: Laboratory measurements of glycosylated hemoglobin.
- Frequent Sample Testing (FST) / Blood Glucose (BG) values: Clinical laboratory measurements (e.g., YSI) to confirm hypoglycemia during PLGM induction.
- Adverse Events (AEs): Clinically reported and documented events.
- These are considered the definitive "ground truth" for evaluating glycemic control and safety.
-
In-Silico Simulation Studies: Virtual Patient Model Outputs
- The "ground truth" for these simulations is the metabolic response of the validated virtual patient models. This computational modeling is used to extend the clinical evidence to various parameter settings and demonstrate equivalence to real-world scenarios.
7. Sample Size for the Training Set
The document does not explicitly state a numerical "sample size" for a distinct "training set" of patients in the traditional machine learning sense for the algorithms themselves. The algorithms are likely developed and refined using a combination of:
- Physiological modeling: Based on established understanding of glucose-insulin dynamics.
- Historical clinical data: From previous similar devices or general diabetes patient populations (though not specified in this document for algorithm training).
- Clinical expertise: Incorporated into the algorithm design.
- The "Virtual Patient Model" itself is a form of simulated data that aids in development and testing. The validation of this model is mentioned as "extensive validation" and establishment of "credibility," implying a robust dataset used to verify its accuracy against real patient responses.
It's typical for complex control algorithms like these to be developed iteratively with physiological models and potentially large historical datasets, but a specific "training set" size for a machine learning model isn't detailed.
8. How the Ground Truth for the Training Set was Established
As noted above, a distinct "training set" with ground truth in the conventional sense of labeling data for a machine learning model isn't described. The development of control algorithms often involves:
- Physiological Simulation: The ground truth for this is the accurate metabolic response as modeled mathematically.
- Clinical Expertise & Design Principles: The ground truth is embedded in the scientific and medical principles guiding the algorithm's control logic.
- Validation of Virtual Patient Model: The "equivalency was demonstrated between Real Patients (RPs) and Virtual Patients (VPs) in terms of predetermined characteristics and clinical outcomes." This suggests that real patient data was used to validate and establish the "ground truth" for the virtual patient model itself, ensuring it accurately mirrors human physiology. This validated virtual patient model then serves as a crucial tool for in-silico testing.
§ 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.