Search Results

LD-Oxi system is intended for use:

To spot check or monitor Oxygen saturation of arterial hemoglobin (SpO2%) and pulse rate.

To analyze the pulse waveform (Photoelectrical Plethysmography or PP) provided by the oximeter. It only provides mathematical analyses of the input of the SpO2 measurement.

To analyze the basic rhythms of the NN or RR intervals in heart rate, both in the time domain and in the frequency domain (short time 5 minutes). It only provides mathematical analysis of the heart rate variability.

The mathematical analysis of Photoelectrical Plethysmography and HRV ARE NOT intended use for diagnosis. The software provides a visual alarm for the values of the heart rate and/or SpO2 percent out of the normal range and for the bad quality signal transmission.

The data are stored in PC in the Backup system of the LD-Oxi software. The device is intended use only for adult subjects (> 20 years old) This Oximeter is intended to be used in spot-checking (5 minutes).

The device is intended use in licensed practitioner's office

This device is no intended to be used at home, in hospital or out-of-hospital transport

The device is not intended use in support life and not for continuously monitoring

The system will be use by practitioner.

The LD-Oxi System is a programmable electro medical system (PEMS) including:

2 USB plug and play Pulse oximeter device including an electronic circuit and reusable Adult SpO2 probe

2 Software installed on a computer

Description of the features

Displays SpO2%, pulse rate value and vertical bar graph pulse amplitude (photoplethysmography).
Mathematical analysis of the pulse waveform (photoelectrical Plethysmography feature).
Mathematical analysis of the Heart Rate Variability (HRV feature).

The provided document does not contain full details of a specific study proving the device meets acceptance criteria, specifically not in the format of a typical clinical validation study with detailed performance metrics, sample sizes, and expert ground truth establishment.

However, based on the information provided in the 510(k) Summary for the LD-Oxi System (K160956), here's what can be inferred and pieced together regarding acceptance criteria and performance, as well as the types of studies mentioned:

1. Table of Acceptance Criteria and Reported Device Performance

The document primarily focuses on establishing substantial equivalence to a predicate device (Electro Sensor Oxi K102442) rather than defining explicit acceptance criteria with numerical targets. For performance, it largely relies on the general equivalence to the predicate and standard compliance. The specifications table (page 4) compares the LD-Oxi with the predicate (ESO) for various parameters.

2. Sample Size for Test Set and Data Provenance

The document does not explicitly mention "test sets" or provide details on sample sizes for clinical performance evaluation. The "Performances and Effectiveness" section (page 7) lists general tests, but no specific human subject data or sample sizes for these tests are provided.

3. Number of Experts and Qualifications for Ground Truth

The document mentions "Peer reviews for the photoelectrical plethysmography mathematical analysis" and "Peer review reference for the heart rate variability mathematical analysis." However, it does not specify the number or qualifications of these experts.

4. Adjudication Method

No adjudication method is mentioned for any "test set" or peer review process.

5. Multi-Reader Multi-Case (MRMC) Comparative Effectiveness Study

No MRMC study comparing human readers with and without AI assistance is mentioned. The device's primary function is as a monitor and analyzer, not as an AI-assisted diagnostic tool for human readers. The mathematical analyses (PP and HRV) are explicitly stated "ARE NOT intended use for diagnosis."

6. Standalone Performance Study

The document refers to the following for performance and effectiveness:

• Calibration tests (simulator oximeter): This implies standalone testing of the oximeter's core functionality against known standards.
• Software verification (SRS/SDS/STD/STR/ Software algorithms tests with input data from the MIT-BIH database): This indicates standalone testing of the software algorithms (including PP and HRV analysis) using a recognized physiological database. This could be considered a form of standalone performance evaluation for the algorithmic components.
• Peer reviews: As mentioned above, these are qualitative assessments of the mathematical analysis.

7. Type of Ground Truth Used

• For the core oximeter function (SpO2% and pulse rate), the ground truth for calibration would likely come from simulator oximeter standards.
• For the software algorithms (PP and HRV), the mention of the MIT-BIH database suggests that the ground truth for these analyses would be derived from the expert-annotated physiological data contained within that database. (The MIT-BIH Arrhythmia Database, for example, is known for its expert annotations of ECG signals, which can be related to HR and HRV).

8. Sample Size for Training Set

The document does not specify a separate "training set" or its sample size. The description of the device and its validation focuses on direct measurement, software verification against existing databases, and established principles of oximetry and physiological analysis, rather than a machine learning model that requires a distinct training phase.

9. How Ground Truth for Training Set was Established

Since a "training set" as commonly understood in machine learning is not explicitly detailed, the method for establishing its ground truth is also not described. If the device uses algorithms developed using physiological databases like MIT-BIH, then the ground truth for those underlying algorithms would have been established by the experts who curated and annotated those databases.

In summary:

The LD-Oxi System's acceptance criteria and proven performance rely heavily on demonstrating substantial equivalence to a predicate device (ESO) and compliance with relevant medical device standards (IEC 60601-1, IEC 60601-1-2, IEC 80601-2-61). Performance claims are supported by calibration tests using simulators and software verification using data from established databases like MIT-BIH, implying a form of standalone algorithmic testing. Detailed clinical trial data with specific sample sizes, expert qualifications, or adjudication methods for new data collection are not provided in this 510(k) summary, as the nature of the modifications and the intended use (monitoring and analysis, not diagnosis from AI) did not necessitate such extensive studies for this particular submission.

Ask a specific question about this device

LifeStream 5 is a stand alone, prescription-based software program designed to operate in a clinical setting by healtheare professionals. It consists of a hosted web server, a hosted database server and two types of client interfaces - one that is provided by Windows client and one that is provided by a web client interface.

LifeStream software's intended use is to retrospectively receive, display and store monitored vital signs parameters and related data. Such data includes patient blood pressure (NIBP), oxygen saturation (SpO2), weight, blood glucose, temperature, dispensed medicine, ECG, peak flow, prothrombin time and retrospective PERS messages.

LifeStream retrospectively displays the data, user-defined data alerts for review and interpretation by a healthcare professional. LifeStream is not intended for emergency use or real-time monitoring.

LifeStream 5 is a stand alone, prescription-based software program designed to operate in a clinical setting by healthcare professionals. It consists of a hosted web server and two types of client interfaces, one that is provided by Windows client and one that is provided by a web client interface. LifeStream 5, like the predicate LifeStream 4.0, is configured to accept patient data that is acquired periodically and displayed retrospectively from Honeywell HomMed Patient Monitors (e.g. Genesis Touch). LifeStream 5 can also interface with 3nd party compatible medical device data systems (e.g. Govsphere TV). LifeStream 5 has the same intended use as the predicate, LifeStream 4.0. LifeStream 5, like LifeStream 4.0 is not intended for emergency use or real-time monitoring. Both are designed to retrospectively receive, display and store scheduled vital sign parameters and related data. Such data includes patient blood pressure (NIBP), oxygen saturation (SpO2), weight, blood glucose, temperature, ECG, peak flow, prothrombin time and retrospective PERS messages.

The Honeywell HomMed LifeStream™ 5 is a software program designed to retrospectively receive, display, and store monitored vital signs parameters and related data for review and interpretation by healthcare professionals. It is not intended for emergency use or real-time monitoring.

Here's an analysis of its acceptance criteria and the study that proves the device meets them:

1. Table of Acceptance Criteria and Reported Device Performance

The provided document is a 510(k) summary, which focuses on demonstrating substantial equivalence to a predicate device rather than detailing specific quantitative acceptance criteria for performance. The "acceptance criteria" here are implied by the claim of substantial equivalence in intended use, users, use environment, technological characteristics, and safety to the predicate device, LifeStream™ 4.0.

The performance reported is qualitative, stating that LifeStream 5 is substantially equivalent to LifeStream 4.0 and that differences "do not affect the relative safety and/or effectiveness."

2. Sample Size Used for the Test Set and the Data Provenance

The document does not specify a "test set" in the context of clinical performance evaluation using patient data. This 510(k) submission primarily relies on demonstrating substantial equivalence through non-clinical performance testing (bench testing) and comparison of technological characteristics with a predicate device.

Therefore, there is:

• No specific sample size for a test set of patient data mentioned.
• No data provenance (country of origin, retrospective/prospective) related to a clinical test set.

The "validation testing of complete systems" and "black box testing" likely used simulated data or internal test cases, but no details on their size or origin are provided.

3. Number of Experts Used to Establish the Ground Truth for the Test Set and the Qualifications of Those Experts

Since there is no mention of a clinical test set requiring expert ground truth, this information is not applicable and not provided in the document.

4. Adjudication Method for the Test Set

As there is no clinical test set with expert ground truth mentioned, no adjudication method is described.

5. If a Multi-Reader Multi-Case (MRMC) Comparative Effectiveness Study Was Done

No, an MRMC comparative effectiveness study was not done. The submission focuses on substantial equivalence based on technical and functional comparison to a predicate device and non-clinical testing, not on comparative effectiveness with human readers.

6. If a Standalone (i.e., algorithm only without human-in-the-loop performance) Was Done

The device itself is a "standalone, prescription-based software program" for retrospective display and storage of vital signs, intended for use by healthcare professionals for review and interpretation. The "Performance / Bench Testing" section describes functional, validation, automated regression, black box, localization, and deployment testing, along with "External evaluation by Honeywell clinical team." This evaluation represents the standalone performance of the software in its intended function of receiving, displaying, and storing data correctly, as it is a device intended to assist human professionals, not to make diagnoses autonomously. However, these are engineering/software tests, not clinical performance studies measuring diagnostic accuracy of an algorithm.

7. The Type of Ground Truth Used

For the non-clinical performance/bench testing, the "ground truth" would be established by the expected behavior and output defined in the software's functional specifications and requirements. For example:

• Functional Testing: The "ground truth" is that the software correctly performs its intended function (e.g., displaying specific vital sign data accurately, registering alerts based on defined thresholds).
• Validation Testing: The "ground truth" is that the complete system meets all specified requirements.
• Automated Regression Testing: The "ground truth" is that previously corrected defects remain fixed and new changes haven't introduced new errors.

There is no mention of pathology, outcomes data, or expert consensus serving as ground truth for a clinical dataset in this submission.

8. The Sample Size for the Training Set

Not applicable. This submission describes a medical device, LifeStream™ 5, which is a software system for managing vital signs data. It is not an AI/Machine Learning algorithm that typically requires a "training set" of data to learn patterns or make predictions. The software's functionality is pre-programmed based on defined rules and specifications.

9. How the Ground Truth for the Training Set Was Established

Not applicable, as there is no training set for an AI/Machine Learning algorithm. The software's "ground truth" for its development would be its functional and system requirements.

Ask a specific question about this device

The Pulse Oximeter CMS50EW is a non-invasive device intended for spot-check or continuous monitoring of non-invasive oxygen saturation of arterial hemoglobin (SpO2) and the pulse rate through the finger of adult patients in home and hospital environments (including clinical use internist/surgery, anesthesia, and intensive care settings). The device is reusable and not intended for out-of-hospital transport use.

The proposed device, Pulse Oximeter CMS50EW is a battery powered fingertip device, which can display % SpO2, pulse rate value and pulse strength. It is based on digital blood oxygen technology.

The proposed device is composed of power module, signal acquisition module, control and signal processing module. The power source of it is a built-in rechargeable lithium battery. And it has alarm function, to raise the user's attention for exceeding of physiological limit and device error via visual and audio alarming indicator. And the pulse oximeter can communicate with computer by USB data wire and Bluetooth.

The proposed device, Pulse Oximeter CMS50EW, is a modification to the predicate device, CMS50E, cleared under K090671; the modification is to add the blue tooth functionality, however, the oximetry technology including the sensor was unchanged.

The provided text focuses on the 510(k) summary for the Contec Medical Systems Co., Ltd.'s Pulse Oximeter CMS50EW, which is seeking substantial equivalence to its predicate device, the Pulse Oximeter CMS50E (K090671). The key modification is the addition of Bluetooth functionality, while the oximetry technology and sensor remain unchanged.

Here's an analysis of the requested information based on the provided text:

1. Table of Acceptance Criteria and Reported Device Performance

The acceptance criteria provided are primarily in the context of performance specifications for SpO2 and Pulse Rate (PR) measurement, which are identical to the predicate device. The "reported device performance" is implicitly that the device meets these existing specifications due to the unchanged oximetry technology.

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

The document explicitly states: "Clinical testing was not necessary in this submission to support the device modification because the oximetry technology including the sensor is unchanged from the predicate device."

Therefore, there is no information provided regarding a specific clinical test set, sample size, or data provenance (country of origin, retrospective/prospective) for this device modification. The equivalence is based on the predicate device's established performance and non-clinical testing for the new Bluetooth functionality.

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

As no clinical testing was deemed necessary for the oximetry performance, there is no mention of experts establishing ground truth for a test set related to SpO2 or PR accuracy for the CMS50EW. Any such data would pertain to the original clearance of the predicate device (K090671) and is not detailed here.

4. Adjudication method for the test set

Not applicable, as no clinical test set for oximetry performance was performed for this submission.

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

Not applicable. This device is a pulse oximeter, not an AI-assisted diagnostic tool that would involve human readers or MRMC studies.

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

This refers to the performance of the device's core functionality (SpO2 and PR measurement). The device's performance is standalone in the sense that it provides direct measurements. The non-clinical tests conducted (IEC standards, wireless transmission tests) assess this standalone performance. No detailed "algorithm only" performance separate from the device's integrated operation is described in a way that suggests a disaggregated study.

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

For the SpO2 and PR measurements, the ground truth would typically be established by established measurement techniques (e.g., co-oximetry for SpO2, ECG for heart rate) during the original clinical validation of the predicate device. However, this specific submission does not detail the ground truth methodology for this device because it relies on the predicate's established oximetry technology. For the new wireless functionality, the "ground truth" would be the expected technical specifications and performance indicators for wireless transmission.

8. The sample size for the training set

Not applicable, as this is not an AI/machine learning device requiring a training set in the conventional sense. The device's oximetry technology is formula-based, using the Lambert-Beer Law.

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

Not applicable for the same reason as point 8. The device's operation is based on established biophysical principles and calibrated with known values, not trained on a dataset.

Ask a specific question about this device