Search Results

The device is intended to be used for measuring, storing, and to generate prompts for, multiple physiological parameters of adults and pediatrics (including neonates). The device is intended for use by trained healthcare professionals in hospital environments. Parameters include: NIBP, SpO2, PR (pulse rate), TEMP. The F3000 Quick Temp module is not intended for neonates. The device is not intended for MRI environments.

The iM3s series vital signs monitors including iM3s\iM3As\iM3Bs\ iHM3s are intended to be used for measuring, storing, reviewing of, and generating prompts for multiple physiological parameters of adults and pediatrics.

The provided documentation describes the FDA 510(k) clearance for the Edan Instruments Vital Signs monitor, Model: iM3s, iM3As, iM3Bs, iHM3s. However, the document primarily focuses on demonstrating substantial equivalence to a predicate device through non-clinical performance testing and software verification/validation, rather than detailing a clinical study with specific acceptance criteria for AI/algorithm performance.

Therefore, many of the requested details regarding acceptance criteria, sample size, expert involvement, and ground truth establishment for a study proving device performance in an AI/algorithm context are not applicable or not provided in this specific FDA clearance document. The device is a vital signs monitor, not explicitly described as incorporating AI for diagnosis or interpretation that would necessitate an MRMC study or detailed ground truth establishment in the context of AI performance.

The document states "Clinical data: Not applicable," further confirming the absence of a clinical study for this clearance.

Here's a breakdown based on the information available in the document:

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

The document refers to compliance with consensus standards for device performance, where the "acceptance criteria" are implied by adherence to these standards and the "reported device performance" is that the device "meets its accuracy specification and meet relevant consensus standards." Specific numerical acceptance criteria are mentioned for the measurement accuracy of SpO2, PR, and NIBP, and various temperature modules.

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

• The document explicitly states "Clinical data: Not applicable." The "test set" for performance was conducted through "Non-clinical data" including "Electrical safety and electromagnetic compatibility (EMC)" and "Performance testing-Bench."
• No specific sample sizes (e.g., number of patients/measurements) for "bench" testing are provided.
• Data provenance (e.g., country of origin, retrospective/prospective) is not applicable given no clinical study.

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

• Not applicable as no clinical ground truth or expert-adjudicated test set was used. Device performance was assessed against established engineering and safety standards.

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

• Not applicable as no clinical test set requiring adjudication was used.

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 MRMC study was performed as this device is a vital signs monitor, not an AI-assisted diagnostic device requiring human reader improvement assessment. Clinical data was deemed "Not applicable."

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

• The performance assessment focused on the device's ability to accurately measure vital signs according to specifications and consensus standards (e.g., IEC 80601-2-30 for NIBP, ISO 80601-2-56 for temperature, ISO 80601-2-61 for pulse oximetry). This is essentially a "standalone" performance evaluation of the measurement algorithms within the device against physical standards, but not in the context of an AI-driven diagnostic algorithm.

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

• For the non-clinical performance testing, the "ground truth" would be the reference measurements from calibrated and traceable sources, as specified by the relevant international standards (e.g., simulated physiological signals/conditions, calibrated temperature sources, etc.).

8. The sample size for the training set:

• Not applicable. This document describes the clearance of a vital signs monitor, not an AI/machine learning algorithm requiring a separate training set.

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

• Not applicable, as no AI training set is described.

Ask a specific question about this device

The Comarch e-Care Platform is intended to connect with physiological measurement devices (weight scales, blood pressure meters, pulse oximeters, peak flow meters, thermometers, glucometers) intended to use at home and send the measurement results to central server. Comarch e-Care Platform serves as Software as a Medical Device and can be used only with FDA cleared measurement devices.

Comarch e-Care Platform displays the collected measurements on the Web application and securely stores them in a database server, where the caregiver can view them, leave comments and contact patient if necessary. Caregivers are able to set thresholds individually for each patient. Measurement results sent to e-Care Platform from connected devices are analyzed and if result is beyond the threshold, caregiver gets the notification.

The Comarch e-Care Platform is not interpretive, nor is it intended for diagnosis or as a substitute for medical care, and it is not intended to provide real time data. It is made available to patients when time-critical care is not required.

The Comarch e-Care Platform is contraindicated for patients requiring direct - medical supervision or emergency intervention. It is intended for patients who are willing and capable of managing its use. Clinical judgment and experience by a caregiver are required to check and interpret the information delivered.

Comarch e-Care Platform is a software intended for use in remote patient monitoring outside of traditional healthcare settings (e.g. at home). Components of Comarch e-Care Platform are: Comarch SMA application, Comarch e-Care application, application server, database server.

Comarch SMA is a software application intended to use by patients. It is designed to collect, display and transmit vital sign measurements captured from commercially available home monitoring devices.

The following vital signs are collected: temperature, glucose, noninvasive blood pressure, pulse oximetry, weight and spirometry.

The Comarch e-Care Platform is a software intended for use in remote patient monitoring outside of traditional healthcare settings (e.g. at home). It connects with physiological measurement devices (weight scales, blood pressure meters, pulse oximeters, peak flow meters, thermometers, spirometers, glucometers) and sends the measurement results to a central server. The platform displays collected measurements on a web application, securely stores them, and allows caregivers to view and analyze them, leave comments, and contact patients. Caregivers can set individual thresholds for each patient, and the platform notifies the caregiver if a measurement result is beyond the set threshold. The device is not interpretive, not intended for diagnosis or as a substitute for medical care, and does not provide real-time data. It is for patients who are able and willing to manage its use, and clinical judgment by a caregiver is required to interpret the information.

Here's an analysis of the acceptance criteria and supporting study information:

1. Table of Acceptance Criteria and Reported Device Performance:

The provided document does not explicitly present a table of quantitative acceptance criteria for device performance. Instead, the substantial equivalence determination for the Comarch e-Care Platform is based on similarities to predicate devices in terms of:

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 states that "no clinical tests were conducted." Therefore, there is no specific test set or data provenance mentioned for clinical performance evaluation. The evaluation was based on non-clinical verification and validation.

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)

Since no clinical tests were conducted and no specific test set-based ground truth was established, this information is not applicable and not provided in the document.

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

Since no clinical tests were conducted and no test set ground truth was established by experts, this information is not applicable and not 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

The document explicitly states "no clinical tests were conducted." Therefore, no MRMC comparative effectiveness study was done, and no effect size regarding human reader improvement with/without AI assistance is provided.

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

The substantial equivalence is based on the device's functional similarities to predicate devices in remote patient monitoring, data transmission, storage, and caregiver notification, rather than a standalone performance evaluation of a diagnostic algorithm. The device itself is described as "not interpretive" and "not intended for diagnosis." The non-clinical verification and validation focused on the software's functionality and adherence to design specifications. Therefore, a standalone performance study in the context of diagnostic accuracy was not performed for this device.

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

As no clinical tests were performed, there was no "ground truth" derived from patient data, expert consensus, pathology, or outcomes data for the purpose of validating diagnostic or interpretive accuracy. The "ground truth" for the non-clinical verification and validation would have been the design specifications and requirements of the software.

8. The sample size for the training set

The document states "no clinical tests were conducted." This implies that the device did not undergo a process involving a "training set" for machine learning model development in the context of clinical performance. The platform's functionality is about data handling and alerts based on pre-set thresholds, not on learning from a dataset to perform interpretations. Therefore, this information is not applicable and not provided.

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

As no training set was used for clinical performance evaluation, this information is not applicable and not provided.

In summary, the Comarch e-Care Platform's acceptance was based on a demonstration of substantial equivalence to existing predicate devices through comprehensive non-clinical verification and validation testing, ensuring the software's functionality, adherence to design specifications, and addressing identified risks. No clinical studies or performance evaluations requiring test sets, ground truth establishment, or expert adjudication were conducted, as the device is not interpretive and does not provide diagnostic insights.

Ask a specific question about this device

The Optum TeleHealth Application is a software application designed to retrospectively monitor vital signs. The following vital signs are collected: noninvasive blood pressure, 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 three configurations:

• stand-alone application for both Android and iOS operating systems
• pre-loaded on an Android tablet

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 devices (OS 4.0 and higher) and Apple devices (iOS 9 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 for both Android and iOS operating systems .
• . 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, including, but not limited to:

• 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) ●

The provided document is a 510(k) premarket notification letter and summary for the Optum TeleHealth Application. It describes a software application designed to collect, display, and transmit vital sign measurements for retrospective monitoring. As such, it is a data handling and transmission device, not a diagnostic or prognostic medical imaging AI device.

Therefore, the document does not contain the information requested for acceptance criteria and a study proving device performance as typically expected for a medical imaging AI device. Specifically, it does not include:

• A table of acceptance criteria with reported device performance (e.g., sensitivity, specificity, AUC).
• Details on sample size, data provenance, ground truth establishment, or expert involvement for a test set designed to evaluate diagnostic or prognostic performance.
• Information on MRMC studies or standalone algorithm performance.

Instead, the document focuses on:

• Indications for Use: Retrospective monitoring of vital signs (noninvasive blood pressure, pulse rate, weight, temperature, blood glucose). It explicitly states it's not intended for emergency use or real-time monitoring.
• Technological Characteristics: How it collects data (manual input, Bluetooth from external devices) and transmits it to a central repository.
• Predicate Devices: Claiming substantial equivalence to a previously cleared Optum TeleHealth Application (K130971).
• Pre-Clinical Testing: A generic statement that "Bench testing, including software validation, was performed to ensure that the product works as intended." and "Results of bench testing show that the product is safe, and effective for use." This implies functional verification and validation of the software, rather than clinical performance evaluation against a diagnostic ground truth.

In summary, this device's function is data aggregation and transmission, not medical image analysis or diagnosis. The typical performance metrics and study designs (like MRMC, standalone performance, or detailed ground truth establishment for diagnostic accuracy) are not applicable or described for this type of device in the provided document.

Ask a specific question about this device

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 .

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) .

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

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 specific question about this device