Search Filters

Search Results

Found 1 results

510(k) Data Aggregation

    K Number
    K130971
    Date Cleared
    2013-10-23

    (198 days)

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

    The Optum TeleHealth Application is a software application designed to retrospectively monitor vital signs. The following vital signs are collected: noninvasive blood pressure, pulse oximetry, pulse rate, weight, temperature, and blood glucose. The Optum TeleHealth Application collects, displays, and transmits vital sign measurements captured from commercially available FDA cleared medical devices designed for home use, or via manual input by the patient. Collected measurement data from the Optum TeleHealth Application can be transmitted via a secure communication mechanism to a central health data repository. Data can be viewed and analyzed via the Optum TeleHealth Web Application.

    The Optum TeleHealth Application is not intended for emergency use or real-time monitoring.

    The client application is available in two configurations:

    • stand-alone application .
    • pre-loaded on an Android tablet .
    Device Description

    The Optum TeleHealth Application is client/server software application which collects and transmits patient vital signs, and physiological data for review, and analysis by clinicians.

    The software consists of a web based application for clinician use, the client application for member use, and web services. Standard data communication protocols are used. The server hosts the web based application for user management, and patient information and care management. The client application is designed to work with Android tablets (Android OS 4.0 and higher), and allows for data input from external biometric measuring devices, review of clinician advice, response to clinician questions, and viewing of graphed data.

    The client application is available in two configurations:

    • stand-alone application .

    • pre-loaded on an Android tablet .
      The device is used in combination with various Class I 510(k) exempt devices and FDA cleared biometric measuring devices, as listed below:

    • A&D Medical, UA-767PBT Digital Blood Pressure Monitor (K043217)

    • A&D Engineering Inc., UC-321PBT Weight Scale (510(k) exempt)

    • TaiDoc Technology Corporation, Fora W310 Weight Scale (510(k) exempt) .

    • TaiDoc Technology Corporation, Fora IR20b Ear Thermometer (K090395) .

    • TaiDoc Technology Corporation, Fora P20 Blood Pressure Monitor (K092106) .

    • Nonin Medical Inc Onyx II Model 9560 Finger Pulse Oximeter (K081285) .

    AI/ML Overview

    The Optum TeleHealth Application is a software application designed to collect, display, and transmit patient vital signs and physiological data for review and analysis by clinicians. The device is not intended for emergency use or real-time monitoring.

    Here's an analysis based on the provided text:

    1. Table of Acceptance Criteria and Reported Device Performance

    Acceptance Criteria (Implied)Reported Device Performance
    Software functions as intended"Bench testing, including software validation, was performed to ensure that the product works as intended."
    Data collection from external biometric devices is accurateNot explicitly stated, but implied by integration with specific FDA-cleared devices.
    Data transmission is secure and reliable"Data is transmitted to the server over the internet using standard communication protocols." and "The client application connects to the server to synchronize with clinician updates via a secure connection."
    Data display and analysis capabilities for clinicians are present"Data can be viewed and analyzed via the Optum TeleHealth Web Application."
    Substantial equivalence to predicate devices"The Optum TeleHealth Application is substantially equivalent to the predicate devices identified above in terms of design, technological characteristics, and intended use."

    2. Sample size used for the test set and the data provenance

    The document does not specify a distinct "test set" in the context of a clinical study with patients. The testing performed was "Bench testing, including software validation." This typically involves internal testing by developers rather than a separate patient-based test set for performance evaluation. Therefore, information on data provenance (country of origin, retrospective/prospective) is not applicable.

    3. Number of experts used to establish the ground truth for the test set and the qualifications of those experts

    This information is not applicable as the testing described is limited to "bench testing" and "software validation," not a clinical study requiring expert-established ground truth.

    4. Adjudication method for the test set

    This information is not applicable as the testing described is limited to "bench testing" and "software validation," not a clinical study requiring adjudication.

    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

    A multi-reader multi-case (MRMC) comparative effectiveness study was not conducted. The device is a data collection and transmission application, not an AI-powered diagnostic tool requiring human reader interpretation improvements.

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

    The device itself is a standalone software application in the sense that it operates independently to collect and transmit data. However, its intended use inherently involves a "human-in-the-loop" (clinicians reviewing and analyzing the data). No study focused on "algorithm only without human-in-the-loop performance" was explicitly mentioned, other than software validation.

    7. The type of ground truth used

    For the "bench testing" and "software validation," the ground truth would likely be established through predefined software requirements, expected output values for simulated inputs, and adherence to communication protocols. It would not typically involve expert consensus, pathology, or outcomes data in the way a diagnostic device would.

    8. The sample size for the training set

    The document does not mention a "training set." This type of testing is characteristic of traditional software validation, not machine learning model training as understood in current AI contexts.

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

    Not applicable, as no training set for a machine learning model was identified. The device's validation relied on traditional software testing methodologies.

    Ask a Question

    Ask a specific question about this device

    Page 1 of 1