(53 days)
EndoTool IV is a glucose management software system, designed for use by healthcare professionals in all patient care settings to recommend intravenous and subcutaneous transition dosing, as well as carbohydrates. Evaluating current and cumulative glucose levels, the software adjusts and maintains the glucose level within a configurable clinician-determined target range. The system is indicated for use in adult and pediatric patients ages 2 years and above, who weigh 12 kgs. or more. EndoTool IV logic is not a substitute for, but rather an adjunct to clinical reasoning. No medical decision should be based solely on the recommended guidance provided by this software system.
EndoTool IV is a software system for glucose management which uses the current and cumulative glucose values provided by the user to calculate and recommend intravenous insulin or carbohydrate doses, to adjust and maintain the patient's glucose level within a provider-ordered target range. In addition, the application can recommend a subcutaneous Basal transition insulin therapy is no longer required.
The provided text describes the 510(k) premarket notification for the EndoTool IV System, a glucose management software. However, it does not include specific acceptance criteria or details of a study proving the device meets those criteria, particularly in the context of clinical performance or human-AI interaction.
The document states that the device is a software-only device and that clinical testing was not required to demonstrate safety and effectiveness. Instead, substantial equivalence to a predicate device (EndoTool IV 1.10, K200443) is based upon benchtop performance testing (Software Verification and Validation Testing).
Therefore, many of the requested details about acceptance criteria, sample sizes for test and training sets, expert involvement, adjudication methods, MRMC studies, standalone performance, and ground truth types are not available in the provided document because the nature of the device and the regulatory pathway chosen (510(k) based on substantial equivalence to a predicate, with bench testing for software verification) did not require them.
Below is a table summarizing the information that is available and explicitly stating what is not available based on the provided text.
Acceptance Criteria and Device Performance (Based on available information for EndoTool IV System)
Given that this is a software-only device and substantial equivalence was determined based on benchtop performance testing (software verification and validation), the "acceptance criteria" discussed are likely related to software quality, functional correctness, and adherence to design specifications, rather than clinical performance metrics in a patient population. The document states that the device performs "as well as the predicate device" in terms of its indications for use and overall performance.
1. Table of acceptance criteria and the reported device performance
| Acceptance Criteria (Implied from Software V&V) | Reported Device Performance (Summary from text) |
|---|---|
| Functional Correctness/Accuracy: Calculations and recommendations for IV insulin, carbohydrate doses, and subcutaneous basal transition dosing are accurate. | The device performs "as well as the predicate device (K200443)." It correctly calculates and recommends doses and adjusts/maintains glucose levels within configurable target ranges, evaluating current and cumulative glucose values. The software was validated per IEC 62304. |
| Software Quality/Reliability: Adherence to software development lifecycle standards and risk management. | Software verification and validation testing conducted per IEC 62304 standards, including: |
- Requirements-based, module, and integration tests
- Endo-Tool regression testing (requirements-based for risk-related requirements, automated algorithm test cases for complete application)
- Static analysis of the software code. |
| User Interface and Functionality: Interface and functionality are as designed and equivalent to the predicate. | "The predicate and subject device are equivalent in design. The subject device is an updated version of the predicate software with minor changes to the interface and functionality." All listed features (e.g., user inputs, alarm advisories, GUI interface) are present and function as intended. |
| Safety Warnings/Precautions: Appropriate warnings and controls are implemented. | New warning/controls regarding low potassium added (compared to predicate). Warnings, precautions, and labeling are present and equivalent to the predicate. |
| Compatibility: Operates on specified systems and browsers. | Compatible with "All" operating systems (as vague as stated) and specific browsers (Internet Explorer, Microsoft Edge, Google Chrome, Mozilla Firefox). Hardware requirements are server, PC, printer, barcode scanner (optional). |
2. Sample size used for the test set and the data provenance:
- Not explicitly stated in terms of patient data or clinical samples. The "test set" likely refers to software test cases and simulated data used for verification and validation.
- Data Provenance: Not applicable in the context of clinical data for this 510(k) submission, as clinical studies were not required. The "data" used would be input data for software testing, derived from theoretical scenarios, and potentially representative patient profiles (though specifics are not provided).
- Retrospective/Prospective: Not applicable as clinical studies were not conducted.
3. Number of experts used to establish the ground truth for the test set and the qualifications of those experts:
- Not applicable for this type of software verification and validation. The "ground truth" for software functionality is established by its specification and requirements, and verified through testing against those requirements. This does not typically involve a panel of clinical experts adjudicating cases for a test set.
4. Adjudication method (e.g., 2+1, 3+1, none) for the test set:
- Not applicable. As no clinical test set requiring expert interpretation or adjudication was used, this method is not relevant to the data provided.
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, an MRMC study was NOT done. The document explicitly states: "Clinical testing was not required to demonstrate the safety and effectiveness of the EndoTool IV." The device is a "Drug Dose Calculator," which provides recommendations and is an adjunct to clinical reasoning, but the document does not describe it as an AI-powered diagnostic tool requiring human-AI comparative effectiveness studies.
6. If a standalone (i.e., algorithm only without human-in-the-loop performance) was done:
- Yes, in essence. The entire basis for this 510(k) is the "Software Verification and Validation Testing," which represents the standalone performance of the algorithm against its requirements and specifications. The document states it's "a software system for glucose management which uses the current and cumulative glucose values... to calculate and recommend..." This is the "algorithm only" performance.
- No specific performance metrics (e.g., accuracy, precision relative to a ground truth clinical outcome) are provided because clinical studies were not performed. The performance is deemed "as well as the predicate device" based on software verification.
7. The type of ground truth used (expert consensus, pathology, outcomes data, etc.):
- Not applicable in the clinical sense. The "ground truth" for software validation testing is typically the expected output based on the defined algorithms and inputs, derived from mathematical models, clinical guidelines incorporated into the algorithm, or predefined correct outputs for specific test cases. This is not derived from expert consensus on patient cases, pathology, or outcomes data in the way a diagnostic AI would require for clinical validation.
8. The sample size for the training set:
- Not applicable/Not stated. This device is presented as an update to a predicate software system, and the filing focuses on demonstrating substantial equivalence based on engineering and software validation. There is no mention of a machine learning component requiring a "training set" of data in the common AI/ML sense. It is a rule-based or algorithm-based system ("Algorithm B" is mentioned).
9. How the ground truth for the training set was established:
- Not applicable. As there is no mention of an ML training set, the establishment of its ground truth is not relevant here. The "ground truth" for the core algorithms would be embedded in established medical principals for glucose management.
§ 868.1890 Predictive pulmonary-function value calculator.
(a)
Identification. A predictive pulmonary-function value calculator is a device used to calculate normal pulmonary-function values based on empirical equations.(b)
Classification. Class II (performance standards).