K Number
K132618
Device Name
ONETOUCH REVEAL
Manufacturer
Date Cleared
2013-12-16

(117 days)

Product Code
Regulation Number
880.5725
Panel
HO
Reference & Predicate Devices
AI/MLSaMDIVD (In Vitro Diagnostic)TherapeuticDiagnosticis PCCP AuthorizedThirdpartyExpeditedreview
Intended Use

OneTouch® Reveal™ is indicated for use by individuals or health care professionals in the home or health care facilities for transmitting data from home monitoring devices such as glucose meters and insulin pumps to a server database to support diabetes management. The device is indicated for professional use and over-the-counter sales.

Device Description

OneTouch® Reveal™ is a Web-based Diabetes management system. The application is designed to assist health care professionals and people with diabetes to track blood glucose levels and insulin doses. The application identifies patterns to help patients manage glycemic control. OneTouch® Reveal™ includes pattern recognition messages, reports, and the ability to view patient data remotely.

AI/ML Overview

Here's an analysis of the acceptance criteria and study information for the LifeScan OneTouch® Reveal™ device, based on the provided text:

Device: OneTouch® Reveal™ (Web-based Diabetes management system)

The provided document is a 510(k) Summary, which typically focuses on demonstrating substantial equivalence to a predicate device rather than detailing specific performance acceptance criteria for a new clinical study. For software devices like OneTouch® Reveal™, "performance" often refers to software verification and validation, and usability, rather than a clinical accuracy study directly analogous to a blood glucose meter.

Based on the available information, here's what can be extracted and what is not explicitly stated:

Acceptance Criteria and Reported Device Performance

Acceptance Criteria CategorySpecific Acceptance Criteria (Inferred/Stated)Reported Device Performance
Software FunctionalityMeets required specificationsDemonstrated to meet required specifications and perform as intended.
Usability/Human FactorsSatisfactory usability for intended usersDemonstrated satisfactory performance in Human Factors Usability Studies.
Intended UseSuccessfully transmits data and supports diabetes management as intended.The device performs as intended, supporting diabetes management by tracking blood glucose and insulin doses, identifying patterns, and viewing patient data remotely.
Safety and EffectivenessNo new questions of safety and effectiveness raised compared to predicate.Substantially equivalent to predicate device (Aidera Diasend System) in intended use, performance, safety, effectiveness, and underlying scientific and operating principles.

Important Note: The document does not provide specific numerical acceptance criteria (e.g., minimum accuracy percentages, specific error rates) that are typical for diagnostic devices, as this is a software system for data management. The "performance data" section broadly states that the device "meets its required specifications and performs as intended."

Study Information

  1. Sample size used for the test set and the data provenance:

    • Sample Size: Not explicitly stated. The document mentions "software verification and validation testing" and "Human Factors Usability Studies," but does not provide specific sample sizes (e.g., number of test cases for software, number of participants for usability).
    • Data Provenance: Not explicitly stated. For software testing, this would typically involve synthetic data, simulated data, and potentially real patient data for validation. For Human Factors, this would involve participants simulating real-world use. The location of these activities is not mentioned.
  2. Number of experts used to establish the ground truth for the test set and the qualifications of those experts:

    • Not explicitly stated. For software verification, "ground truth" would be the expected output based on specifications, which is established by software engineers and subject matter experts. For usability, "truth" is often observed user behavior against defined tasks. No specific number or qualifications of such experts are provided.
  3. Adjudication method (e.g. 2+1, 3+1, none) for the test set:

    • Not explicitly stated. Adjudication methods like 2+1 or 3+1 are typically used for clinical endpoints where expert consensus is needed on a subjective interpretation (e.g., image reading). For software functionality and usability testing, this type of adjudication is generally not directly applicable.
  4. 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 comparative effectiveness study was not done. This device is a data management system, not an AI-assisted diagnostic tool that would be evaluated with human readers. Its primary function is to track, identify patterns, and display data for users, not to provide interpretations that human readers would then review or be assisted by.
  5. If a standalone (i.e. algorithm only without human-in-the-loop performance) was done:

    • Yes, in essence, the "software verification and validation testing" evaluates the algorithm's performance in a standalone manner against its specifications (i.e., does the software correctly process data, identify patterns, and generate reports as designed). The document implies this was done when it states the device "meets its required specifications and performs as intended."
  6. The type of ground truth used (expert consensus, pathology, outcomes data, etc.):

    • For software verification: The "ground truth" would be the expected outcomes and behaviors defined by the software requirements and design specifications. This is derived from scientific principles of glucose monitoring and diabetes management.
    • For human factors: The "ground truth" would be the successful completion of tasks by users, adherence to usability principles, and user satisfaction metrics.
  7. The sample size for the training set:

    • Not applicable as this is not a machine learning/AI device in the sense of requiring a "training set" for model development. It's a rules-based software system for data management and pattern recognition. The "patterns" it identifies are likely based on predefined clinical rules or thresholds, not derived from a machine learning training dataset.
  8. How the ground truth for the training set was established:

    • Not applicable for the same reason as point 7. The "ground truth" for the system's logic (e.g., what constitutes a "pattern" or "high glucose event") would be established by clinical experts and engineers based on established medical guidelines for diabetes management, not through a machine learning training process with labeled data.

§ 880.5725 Infusion pump.

(a)
Identification. An infusion pump is a device used in a health care facility to pump fluids into a patient in a controlled manner. The device may use a piston pump, a roller pump, or a peristaltic pump and may be powered electrically or mechanically. The device may also operate using a constant force to propel the fluid through a narrow tube which determines the flow rate. The device may include means to detect a fault condition, such as air in, or blockage of, the infusion line and to activate an alarm.(b)
Classification. Class II (performance standards).