Search Results

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 MyHealthPoint Telehealth Manager is an accessory software that wirelessly collects, records and transmits biometric data (including glucose, blood pressure, weight, body composition, activity, body temperature, ECG and pulse oximeter readings) from a variety of supported home-monitoring devices as well as supporting manual uploading of data. The MyHealthPoint application uses the same data repository platform that is already cleared, MyGlucoHealth Software System (K081703).

MyHealthPoint TeleHealth Manager is intended to be used by patients in non-clinical settings (e.g. home) to collect, record and transmit their biometric data to a remote secure server. Stored data is accessible by healthcare professionals and caregivers for analysis, messaging and intervention using standard digital communication technologies and protocols. Patients may also view the data to assist in self-management of their specific health condition. The MyHealthPoint Telehealth Manager is intended to be used in combination with a variety of external vital sign devices.

The MyHealthPoint Telehealth Manager is intended to be used by patients identified by their healthcare organization that would benefit from remote monitoring. It is not intended as a replacement of the oversight of healthcare professionals nor does it provide "real-time" or emergency monitoring. It does not measure, interpret or make any decisions on the data that it conveys.

The MyHealthPoint Telehealth Manager is a software platform accessible via PC or mobile smart phone that collects member's biometric data such as activity, blood pressure, blood glucose, ECG, body temperature, body composition/weight and pulse oximetry, and has the ability to send medication reminders. The MyHealthPoint TeleHealth Manager can be used by patients during their daily lives to collect biometric readings from various personal health monitors from a variety of manufacturers to assist in maintaining wellness regimens and the clinical monitoring of patients with chronic disease. The system can be accessed by members, clinicians and caregivers for analysis and intervention using standard digital communication technologies and protocols. The MyHealthPoint Telehealth Manager is intended for use in remote monitoring of patient biometrics and supports messaging between member's, clinicians and caregivers. In addition to monitoring, MyHealthPoint TeleHealth Manager supports reminders, alerts, and online graphical reports to help patients and their healthcare professionals better understand and manage their conditions.

The provided document is a 510(k) premarket notification for the MyHealthPoint TeleHealth Manager, a software platform. The document primarily focuses on demonstrating substantial equivalence to predicate devices rather than presenting a detailed clinical study with specific acceptance criteria and performance metrics for an AI algorithm.

Here's a breakdown of the requested information based on the provided text, with explicit notes where information is not available or not applicable to this type of submission:

1. Table of Acceptance Criteria and Reported Device Performance

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

• Sample Size for Test Set: Not specified. The submission describes "extensive bench testing" and "user performance testing" but does not provide any details on the number of cases, data points, or users involved in these tests.
• Data Provenance: Not specified. The document does not mention the country of origin of any data, nor whether it was retrospective or prospective. Given the nature of a 510(k) for a software platform emphasizing substantial equivalence and verification of data transfer/storage, the focus is on functional testing rather than clinical data from a patient population.

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

• Not Applicable / Not Specified. The submission does not detail any expert-derived ground truth or clinical interpretations. The "performance" assessment focuses on the software's ability to capture, transmit, and store data correctly, and the usability of the manual. It's a technical verification, not a clinical validation requiring expert ground truth.

4. Adjudication Method for the Test Set

• Not Applicable / Not Specified. No adjudication method is mentioned as there's no indication of a diagnostic or interpretive task requiring expert consensus for ground truth establishment.

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

• No. An MRMC study was not done. The device is a data management and communication system, not an AI algorithm performing diagnostic interpretations that would typically be evaluated in an MRMC study. The document states it "does not measure, interpret or make any decisions on the data that it conveys."

6. Standalone (Algorithm Only Without Human-in-the-Loop Performance) Study

• Partially Applicable / Not Explicitly Described as "Standalone Study". The "Verification testing that product meets product performance and functional specifications" and "Verification that biometric data submitted by personal home-use devices are captured (wirelessly or manually), transmitted and stored properly" essentially describe standalone testing of the software's core functionalities (data handling, transmission, storage). However, it's not structured as a typical "standalone algorithm performance study" for an AI diagnostic device, as the MyHealthPoint TeleHealth Manager itself is not an AI diagnostic algorithm.

7. Type of Ground Truth Used

• Functional/Technical Verification. The "ground truth" for the tests described would be based on expected software behavior and data integrity rather than clinical outcomes, pathology, or expert consensus on a medical diagnosis. For example, for data integrity, the ground truth would be that the transmitted data perfectly matches the source data. For functional specifications, the ground truth would be the defined expected behavior of the software.

8. Sample Size for the Training Set

• Not Applicable / Not Specified. The MyHealthPoint TeleHealth Manager is described as a software platform for data collection and display, not a machine learning or AI algorithm that requires a training set. There is no mention of an algorithm being trained on data.

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

• Not Applicable / Not Specified. As there is no mention of a training set or an AI algorithm requiring training, the establishment of ground truth for such a set is not discussed.

Ask a specific question about this device

Intel-GE Care Innovations Connect RCM is intended to collect vital sign measurements from physiological measurement devices intended for use in the home. Patients can review the stored vital sign measurement information and receive educational and motivational content from caregivers. Patients can also engage in videoconferences with caregivers and answer the caregivers' questions by participating in surveys.

Care Innovations Connect RCM 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.

Care Innovations Connect RCM 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.

Care Innovations Connect RCM will be available for over the counter use.

Care Innovations™ Connect RCM is a software application for use with measurement devices commercially available for home use. The software executes on a web server and is accessed via a browser from the patient's COTS personal computing device. A small validated software application known as Device Connector runs on patients' home COTS platforms. Off the Shelf (OTS) software is also used with the internally developed software to provide functionality such as: setting & receiving email and text-based notifications, creating & editing calendar entries, playing Learn More videos, and holding a video conference with a clinician.

Care Innovations™ Connect RCM is a software application for use with measurement devices commercially available for home use. Connect RCM provides the same client capabilities of collecting and transmitting patient data to the clinician database system as the predicate devices, and uses the existing clinician database system in the Intel-GE Care Innovations 10 Guide (K130290). No changes were required to the existing clinician database system to support the new client software.

Patients can also enter measurement data manually entered data is stored in the backend clinician database as well as the Personal Health Data Record. It is flagged as manually entered data.

The provided document, K130821, states that the "Connect RCM does not rely on an assessment of clinical performance data." It asserts that "The device will conform to FDA 's recognized consensus standards and relies on its conformity to demonstrate the safety and efficacy." Therefore, there is no study described that proves the device meets specific acceptance criteria based on clinical performance.

Instead, the submission relies on demonstrating substantial equivalence to predicate devices and conformity to recognized consensus standards for safety and efficacy.

Given this, I cannot fill out the requested table or answer most of the follow-up questions because the submission explicitly states that clinical performance data was not used.

Here's what I can provide based on the document:

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

The document does not provide a table of acceptance criteria and reported device performance in the context of clinical studies. The "acceptance criteria" for this device appear to be its conformity to FDA recognized consensus standards and its substantial equivalence to predicate devices.

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

Not applicable. The device does not rely on clinical performance data for its 510(k) submission.

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

Not applicable. No clinical test set described.

4. Adjudication method

Not applicable. No clinical test set described.

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. The device is a remote patient monitoring system, not an AI-assisted diagnostic tool, and no such study was performed or described.

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

Not applicable. The device is software for collecting and displaying patient data, not an algorithm for standalone performance evaluation in a clinical sense.

7. The type of ground truth used

Not applicable. No clinical performance data was used for the 510(k) submission. The "ground truth" for regulatory approval appears to be the documented functionality of the predicate device and the adherence to safety standards.

8. The sample size for the training set

Not applicable. No machine learning model or training set is described in the context of clinical performance for this 510(k).

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

Not applicable. No training set is described.

Ask a specific question about this device

Tempus IC is intended to aid with the diagnosis of a person presenting as unwell or sick when they are in a location remote from immediate medical assistance. The device allows the User to take vital signs data from a patient and to transmit that data to medical professionals located at the response centre elsewhere. Typical examples are remote land, sea or air locations.

Tempus IC is intended primarily to be used by medically unqualified people who have received basic training in the use of the device. Medical expertise is provided through communication with the Response Centre which would be staffed by physicians who would advise the operator on the nature of the medical incident.

Tempus IC is intended to be used where a physician or other medically trained staff may or may not be present but where remote physician support is required.

Tempus IC measures non-invasive blood pressure, SpO2, pulse rate, respiration rate and ETCO2, 12 Lead ECG, tympanic temperature (via a wireless external module) and blood glucose (via a wireless external module).

Tempus IC is suitable for use on adults or children (over 10 years old and over 20kg in weight).

The TempusIC™ is an advanced multi-parameter vital signs monitor designed for use in remote locations by trained non-expert users. It provides a wide range of features in a highly robust package, including integrated voice link and video camera.

The device remains unchanged from its previous/existing clearance with the exception that the device is now capable of receiving (wirelessly over a Bluetooth™ link) both tympanic temperature readings from a tympanic thermometer (cleared under K101264) and blood glucose data from the Entra Health Systems MyGlucoHealth glucometer (cleared under K081703),

Voice and data connections are made automatically via existing satellite or terrestrial communications systems.

The TempusIC™ is used in conjunction with TempusNET™ software, which provides a system for receiving real-time voice and vital signs data. The system enables users to receive voice, vital signs data, and still video pictures from TempusICTM devices located anywhere in the world.

The TempusNET™ system can be used by commercial response centre service providers or by individuals or organisations wishing to provide their own internal service.

It also provides a synchronised user interface, and remote control of the TempusIC™.

TempusNET™ also supports a full patient records database.

The provided 510(k) summary for the RDT Tempus IC Patient Monitor indicates that the device's clearance is based on its substantial equivalence to a legally marketed predicate device (itself, prior to the addition of wireless peripherals). The study details focus on the newly added functionalities (wireless temperature and blood glucose measurement) and their reliable and accurate transmission.

Here's an analysis based on the provided document:

1. Table of Acceptance Criteria and Reported Device Performance:

The document does not explicitly present a table of "acceptance criteria" with specific numerical targets for performance metrics (e.g., accuracy, precision) for each vital sign parameter. Instead, the "acceptance criteria" are implied by the demonstration of equivalence to predicate devices and the reliability and accuracy of data transmission for the new wireless peripherals.

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

The document primarily refers to "testing" without providing specific sample sizes for individuals or data points for the comparative or bench tests.

• Sample Size: Not explicitly stated. The description mentions "comparative testing," "bench testing," and "wireless range/co-existence testing," but details on the number of measurements, subjects, or data points are absent.
• Data Provenance: Not explicitly stated. The tests are described as being performed to "benchmark" the device and confirm reliable/accurate data transmission. It's likely these were internal laboratory or engineering tests, but no geographic or retrospective/prospective details are given.

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

This information is not provided in the document. The testing described primarily focuses on the technical performance of the wireless data transmission features of the new peripherals, rather than diagnostic accuracy established by medical experts on a "test set" of patients.

4. Adjudication Method for the Test Set:

This information is not provided. Given the nature of the testing described (benchmarking data transmission, wireless performance), an adjudication method as typically applied to clinical diagnostic studies is not relevant or described.

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

No, an MRMC comparative effectiveness study is not described. The document focuses on the device's performance and its equivalence to predicates, not on how human readers' effectiveness might improve with or without AI assistance. This device is a vital signs monitor, not an AI-powered diagnostic system.

6. Standalone (Algorithm Only Without Human-in-the-Loop Performance) Study:

The document describes testing of the device's components, particularly the wireless glucometer and its data transmission. This would be analogous to a standalone performance evaluation of those specific functionalities (e.g., how accurately and reliably the glucometer transmits data). However, it's not an "algorithm-only" study in the context of an AI-powered diagnostic algorithm. It's a hardware/software system performance evaluation.

The "bench testing" and "wireless range/co-existence testing" for the glucometer can be considered standalone performance evaluations of those specific functionalities.

7. Type of Ground Truth Used:

For the glucometer functionality, the ground truth would likely be established by a reference method for blood glucose measurement to determine the "accuracy" of the data received. For wireless reliability, the "ground truth" is simply whether the data was successfully transmitted and received without error, and if it matched the source data.

• For Glucometer Accuracy (implied): A reference blood glucose measurement. The document states "benchmarking to confirm the MyGlucoHealth data was received reliably and accurately," implying a comparison to a known standard.
• For Wireless Reliability: Successful transmission and reception of data without corruption, verified against the original transmitted data.

8. Sample Size for the Training Set:

This information is not applicable and not provided. The Tempus IC Patient Monitor is a vital signs monitoring device, not a machine learning or AI system that requires a "training set." Its functionality relies on established physiological measurement technologies and data transmission protocols.

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

This information is not applicable. As stated above, there is no "training set" for this device in the context of machine learning. The device's operation is based on physical sensors and software logic, not learned patterns from a training dataset.

Ask a specific question about this device