(30 days)
The t:slim X2 insulin pump with interoperable technology (the Pump) is intended for the subcutaneous delivery of insulin, at set and variable rates, for the management of diabetes mellitus in persons requiring insulin. The Pump is able to reliably and securely communicate with compatible, digitally connected devices, including automated insulin dosing software, to receive, execute, and confirm commands from these devices. The Pump is intended for single patient, home use and requires a prescription. The Pump is indicated for use with NovoLog or Humalog U-100 insulin. The Pump is indicated for use in individuals 6 years of age and greater.
The Subject Device is an ambulatory, battery operated, rate-programmable infusion pump designed for the subcutaneous delivery of insulin, at set and variable rates, for the management of diabetes mellitus in persons requiring insulin. The device includes a disposable cartridge which is motor driven to deliver patient programmed basal rates and boluses through an infusion set into subcutaneous tissue. The desired timing and quantity of insulin delivery (bolus or basal) is programmed by the patient based on their healthcare provider's recommendations. The Subject Device can send and receive data to and from other interoperable devices and is designed to act on commands from other authorized digital pump controller devices to adjust insulin dosing. The Subject Device is designed to be able to receive and display alerts and alarms to users based on information received from other interoperable devices. The Subject Device is compatible with Interoperable Automated Glycemic Controllers, such as Basal-IQ Technology (K193483) and Control IQ Technology (DEN190034) to aid in diabetes management. In addition, the Subject Device is compatible with iCGM systems cleared under 21 CFR 862.1355 and marketed separately from the ACE Pump and Interoperable Automated Glycemic Controllers.
The Tandem Diabetes Care t:slim X2 Insulin Pump with Interoperable Technology underwent non-clinical testing to confirm that its User Settable Max Basal Limit software update feature met specified requirements and performed as intended.
1. Table of Acceptance Criteria and Reported Device Performance:
| Feature | Acceptance Criteria | Reported Device Performance |
|---|---|---|
| User Settable Max Basal Limit | Users can safely and effectively use the feature. | Human factors study demonstrated users can safely and effectively use the feature. |
| Software Conformance | Software conforms to patient needs and intended uses. | Detailed software requirements, verification and validation, code inspection, walkthrough, static analysis, unit testing, and system level testing ensured conformance. |
| Compliance with Special Controls | Device adheres to Special Controls of the predicate device (DEN180058). | Adherence to Special Controls ensured continued assurance of safety and effectiveness. |
| Basal Rate Limit application | Software prevents setting a basal insulin rate or a temporary basal insulin rate higher than the user set Basal Limit. | A Temporary Rate cannot be set higher than the maximum rate set by the user (as per comparison table). The software feature prevents the user from setting a basal insulin rate or a temporary basal insulin rate higher than the user set Basal Limit (as per 'Purpose of Special 510(k) Notification'). |
2. Sample Size Used for the Test Set and Data Provenance:
The document mentions "human factors validation testing" but does not specify the sample size of participants in this study. The data provenance (e.g., country of origin, retrospective or prospective) is not explicitly stated. It is implied to be prospective and conducted by Tandem Diabetes Care Inc., as it's part of their submission for their device.
3. Number of Experts and Qualifications:
The document does not provide details on the number of experts used to establish ground truth or their specific qualifications for the human factors study. It refers to "intended users" as participants. For software verification and validation, it implies internal experts from Tandem Diabetes Care were involved in activities like code inspection and walkthroughs, but their specific number and qualifications are not mentioned.
4. Adjudication Method:
The document does not describe an adjudication method for the test set.
5. Multi-Reader Multi-Case (MRMC) Comparative Effectiveness Study:
No MRMC comparative effectiveness study was mentioned. The device is an insulin pump, and the evaluation focused on the safety and effectiveness of a new software feature, not on the interpretation of medical images or data by multiple readers.
6. Standalone Performance:
Yes, a standalone performance of the algorithm (or the software feature in this case) was done through "software verification and validation testing." This testing ensured the software conformed to patient needs and intended uses independently. The human factors study also evaluated the device's performance when used by intended users, but the software's foundational performance was assessed in isolation.
7. Type of Ground Truth Used:
For the human factors study, the ground truth was based on the ability of "intended users" to "effectively use the Subject Device for its' intended purpose in expected use environments" as evaluated against established usability standards (ANSI AAMI HE 75:2009, ANSI/AAMI/IEC 62366-1:2015, and FDA guidance).
For software verification and validation, the ground truth was conformity to defined "detailed software requirements," "patient needs," and "intended uses."
8. Sample Size for the Training Set:
The document does not explicitly mention a separate "training set" or its sample size. Software development and verification and validation processes were used, which would involve iterative development and testing, but a distinct training set in the context of machine learning is not applicable here as the description is of a feature update to an existing software, not a new AI algorithm that learns from data.
9. How Ground Truth for the Training Set Was Established:
Not applicable, as a distinct training set for a machine learning algorithm is not described. The ground truth for the overall software development and testing was established through detailed software requirements, patient needs, intended uses, and adherence to established software development and risk management standards (ISO 14971-2012, ANSI AAMI IEC 62304:2006/A1:2016, and FDA guidance).
§ 880.5730 Alternate controller enabled infusion pump.
(a)
Identification. An alternate controller enabled infusion pump (ACE pump) is a device intended for the infusion of drugs into a patient. The ACE pump may include basal and bolus drug delivery at set or variable rates. ACE pumps are designed to reliably and securely communicate with external devices, such as automated drug dosing systems, to allow drug delivery commands to be received, executed, and confirmed. ACE pumps are intended to be used both alone and in conjunction with digitally connected medical devices for the purpose of drug delivery.(b)
Classification. Class II (special controls). The special controls for this device are:(1) Design verification and validation must include the following:
(i) Evidence demonstrating that device infusion delivery accuracy conforms to defined user needs and intended uses and is validated to support safe use under actual use conditions.
(A) Design input requirements must include delivery accuracy specifications under reasonably foreseeable use conditions, including ambient temperature changes, pressure changes (
e.g., head-height, backpressure, atmospheric), and, as appropriate, different drug fluidic properties.(B) Test results must demonstrate that the device meets the design input requirements for delivery accuracy under use conditions for the programmable range of delivery rates and volumes. Testing shall be conducted with a statistically valid number of devices to account for variation between devices.
(ii) Validation testing results demonstrating the ability of the pump to detect relevant hazards associated with drug delivery and the route of administration (
e.g., occlusions, air in line, etc.) within a clinically relevant timeframe across the range of programmable drug delivery rates and volumes. Hazard detection must be appropriate for the intended use of the device and testing must validate appropriate performance under the conditions of use for the device.(iii) Validation testing results demonstrating compatibility with drugs that may be used with the pump based on its labeling. Testing must include assessment of drug stability under reasonably foreseeable use conditions that may affect drug stability (
e.g., temperature, light exposure, or other factors as needed).(iv) The device parts that directly or indirectly contact the patient must be demonstrated to be biocompatible. This shall include chemical and particulate characterization on the final, finished, fluid contacting device components demonstrating that risk of harm from device-related residues is reasonably low.
(v) Evidence verifying and validating that the device is reliable over the ACE pump use life, as specified in the design file, in terms of all device functions and in terms of pump performance.
(vi) The device must be designed and tested for electrical safety, electromagnetic compatibility, and radio frequency wireless safety and availability consistent with patient safety requirements in the intended use environment.
(vii) For any device that is capable of delivering more than one drug, the risk of cross-channeling drugs must be adequately mitigated.
(viii) For any devices intended for multiple patient use, testing must demonstrate validation of reprocessing procedures and include verification that the device meets all functional and performance requirements after reprocessing.
(2) Design verification and validation activities 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 shall be implemented to address device system hazards and the design decisions related to how the risk control measures impact essential performance shall be documented.
(ii) 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 validated interface specifications for digitally connected devices. These interface specifications shall, at a minimum, provide for the following:
(i) Secure authentication (pairing) to external devices.
(ii) Secure, accurate, and reliable means of data transmission between the pump and connected devices.
(iii) Sharing of necessary state information between the pump and any digitally connected alternate controllers (
e.g., battery level, reservoir level, pump status, error conditions).(iv) Ensuring that the pump continues to operate safely when data is received in a manner outside the bounds of the parameters specified.
(v) A detailed process and procedure for sharing the pump interface specification with digitally connected devices and for validating the correct implementation of that protocol.
(4) The device must include appropriate measures to ensure that safe therapy is maintained when communications with digitally connected alternate controller devices is interrupted, lost, or re-established after an interruption (
e.g., reverting to a pre-programmed, safe drug delivery rate). Validation testing results must demonstrate that critical events that occur during a loss of communications (e.g., commands, device malfunctions, occlusions, etc.) are handled appropriately during and after the interruption.(5) 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 system must, at a minimum, include:
(i) A record of all drug delivery
(ii) Commands issued to the pump and pump confirmations
(iii) Device malfunctions
(iv) Alarms and alerts and associated acknowledgements
(v) Connectivity events (
e.g., establishment or loss of communications)(6) Design verification and validation must include results obtained through a human factors study that demonstrates that an intended user can safely use the device for its intended use.
(7) Device labeling must include the following:
(i) A prominent statement identifying the drugs that are compatible with the device, including the identity and concentration of those drugs as appropriate.
(ii) A description of the minimum and maximum basal rates, minimum and maximum bolus volumes, and the increment size for basal and bolus delivery, or other similarly applicable information about drug delivery parameters.
(iii) A description of the pump accuracy at minimum, intermediate, and maximum bolus delivery volumes and the method(s) used to establish bolus delivery accuracy. For each bolus volume, pump accuracy shall be described in terms of the number of bolus doses measured to be within a given range as compared to the commanded volume. An acceptable accuracy description (depending on the drug delivered and bolus volume) may be provided as follows for each bolus volume tested, as applicable: Number of bolus doses with volume that is 250 percent of the commanded amount.
(iv) A description of the pump accuracy at minimum, intermediate, and maximum basal delivery rates and the method(s) used to establish basal delivery accuracy. For each basal rate, pump accuracy shall be described in terms of the amount of drug delivered after the basal delivery was first commanded, without a warmup period, up to various time points. The information provided must include typical pump performance, as well as worst-case pump performance observed during testing in terms of both over-delivery and under-delivery. An acceptable accuracy description (depending on the drug delivered) may be provided as follows, as applicable: The total volume delivered 1 hour, 6 hours, and 12 hours after starting delivery for a typical pump tested, as well as for the pump that delivered the least and the pump that delivered the most at each time point.
(v) A description of delivery hazard alarm performance, as applicable. For occlusion alarms, performance shall be reported at minimum, intermediate, and maximum delivery rates and volumes. This description must include the specification for the longest time period that may elapse before an occlusion alarm is triggered under each delivery condition, as well as the typical results observed during performance testing of the pumps.
(vi) For wireless connection enabled devices, a description of the wireless quality of service required for proper use of the device.
(vii) For any infusion pumps intended for multiple patient reuse, instructions for safely reprocessing the device between uses.