Search Results

The t:slim® Insulin Delivery System is indicated for the subcutaneous delivery of insulin, at set and variable rates, for the management of diabetes mellitus in persons requiring insulin, for individuals 12 years of age and greater. The device is indicated for use with NovoLog or Humalog U-100 insulin.

The t:flex™ Insulin Delivery System is indicated for the subcutaneous delivery of insulin, at set and variable rates, for the management of diabetes mellitus in persons requiring insulin, for individuals 12 years of age and greater. The device is indicated for use with NovoLog or Humalog U-100 insulin.

The Tandem® Device Updater™ System consists of software which allows for communication between a computer and a t:slim® or t:flex™ Insulin Delivery System. It allows for remote software installation and update of a Tandem Insulin Delivery System.

The t:slim® and t:flex™ Insulin Delivery Systems facilitate the subcutaneous delivery of insulin, at set and variable rates, for the management of diabetes mellitus in persons requiring insulin.

The accessory Tandem Device Updater™ System consists of software which allows for communications between a computer and a Tandem Diabetes Care. Inc. Insulin Delivery System. The Tandem Device Updater™ allows for software installation and update.

The Tandem Device Updater System is comprised of a personal computer application, a web server (HAL), an embedded firmware application (Homer), and a Tandem pump (t.slim or t.flex). The goal of the Tandem Device Updater System is to provide a process for the user to perform updates to the firmware components of a Tandem pump. The Tandem Device Updater System provides communication security consisting of message authentication and encryption, two commonly used methods to secure communication protocols (i.e. USB). Communication between the pump and the Tandem Device Updater System can only occur while the pump is connected to a computer via USB cable.

The HAL Web Server (HAL) is a web server that is responsible for storing and delivering the firmware components of a pump.

The Homer Firmware Application (Homer) is a software application which is part of Tandem Device Updater System that runs on the main MCU incorporated in the pump. Homer is used to update the Bootloader Software in each MCU, essentially rewriting the contents in the flash memory of the MCU. In addition to updating the Bootloader Software, Homer will provide an interface for the secure exchange of security keys during the enabling of communication security. Homer authenticates critical messages received from the PC application.

The Tandem pumps (i.e., t.flex and t:slim described above) incorporate three separate microcontroller units (MCUs), and each MCU runs two separate pieces of firmware, known as the Bootloader Software, and Application Software. The Application Software running on the main MCU, utilizes a graphics library to generate the screens for the pump display. The Tandem Device Updater downloads files from Tandem and installs them on the pump. All binary images for use on the pump transmitted by the Tandem Device Updater are encrypted.

The software components on the pump that may be updated by the Tandem Device Updater System include: the Bootloader Software stored in each MCU, the Application Software stored in each MCU, and the graphics library files stored in the nonvolatile flash memory module.

The software version of the t:slim and t:flex Insulin Delivery Systems for this submission is version 4.3.5.1. The software version of the Tandem Device Updater System for this submission is version 1.0.

This document is a 510(k) summary for the Tandem® Insulin Delivery Systems and the Tandem® Device Updater™ System. It discusses the substantial equivalence to predicate devices and provides performance data primarily in the form of assurance cases and verification/validation testing. However, it does not provide specific numerical acceptance criteria or reported device performance in the format of a table as requested. It also lacks details about specific studies with sample sizes, ground truth establishment, or expert involvement as typically found in diagnostic device evaluations.

Here's an attempt to answer your questions based only on the provided text, but please note the significant limitations due to the nature of this type of submission (a 510(k) for an infusion pump system, not a diagnostic device with specific performance metrics like sensitivity/specificity).

1. A table of acceptance criteria and the reported device performance

The document does not provide a table of numerical acceptance criteria or detailed reported device performance in the context of diagnostic metrics (e.g., sensitivity, specificity, accuracy). The performance data cited are primarily related to safety risks and compliance with guidance documents for infusion pumps.

The "acceptance criteria" are implied by the stated goals of the assurance cases:

• "The safety risk resulting from use of t:slim/t:flex pump is reduced to acceptable levels and is As Low As Reasonably Practicable (ALARP) through use of mitigating technologies and the risks are substantially equivalent to the predicate device."
• "The safety risk resulting from use of Tandem Device Updater is reduced to acceptable levels and is As Low As Reasonably Practicable (ALARP) through use of mitigating technologies and the risks are substantially equivalent to the predicate device."

Reported device performance focuses on successful verification and validation testing, risk mitigation, and substantial equivalence to predicate devices. Specific quantitative results (e.g., "device achieved X% accuracy") are not present.

2. Sample size used for the test set and the data provenance (e.g. country of origin of the data, retrospective or prospective)

The document does not specify a "test set" sample size in the context of diagnostic performance. It refers to "Software verification and validation testing" and "Hardware changes were supported by verification testing." These are likely internal engineering tests, and details on sample sizes or data provenance (country, retrospective/prospective) are not provided. "Human factor formative and summative studies" were conducted for the Tandem Device Updater System's user interface, but details on participant numbers, data type, or provenance are not given.

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 is not applicable in the context of this document. The device is an insulin pump system and a software updater, not a diagnostic tool where expert ground truth establishment for a test set is typically required. The "ground truth" for these types of devices is typically compliance with technical specifications, safety standards, and functional requirements, established through engineering and quality assurance processes, not expert review of medical images or patient data.

4. Adjudication method (e.g. 2+1, 3+1, none) for the test set

This is not applicable. There is no mention of a "test set" requiring adjudication in the diagnostic sense within this document. The testing described is verification and validation, which would follow established engineering protocols rather than adjudication by medical experts.

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

No such study was done or is mentioned. This is an insulin pump system, not an AI-assisted diagnostic tool for human readers.

6. If a standalone (i.e. algorithm only without human-in-the loop performance) was done

While the device's software components (including the Tandem Device Updater) operate "standalone" in the sense of executing code, the performance is evaluated in the context of its function within the medical device system. Standalone "algorithm only" performance in the diagnostic sense (e.g., classifying images) is not relevant or described here. Instead, software verification and validation testing was performed on the device's software.

7. The type of ground truth used (expert consensus, pathology, outcomes data, etc.)

The concept of "ground truth" in the diagnostic sense (e.g., pathology, outcomes data) is not applicable to this submission. For an insulin pump and its updater, the "truth" against which performance is measured is its adherence to design specifications, safety requirements, and proper functionality as determined by engineering tests and regulatory standards. For example, for software, "truth" would be its adherence to specified algorithms and absence of critical bugs.

8. The sample size for the training set

The document does not mention a "training set." This type of submission does not involve machine learning algorithms that typically require training sets. The software development likely follows traditional software engineering paradigms, including design, coding, verification, and validation.

9. How the ground truth for the training set was established

As there is no mention of a "training set," this question is not applicable.

Ask a specific question about this device