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 Honeywell HomMed Genesis Touch Retrospective Physiological Monitoring System is designed to retrospectively monitor vital signs include noninvasive blood pressure, pulse oximetry, pulse rate, weight and manually entered temperature. The Genesis Touch Retrospective Physiological Monitoring System collects, displays and transmits vital signs measurements captured from commercially available FDA cleared wireless medical devices designed for home use. Collected measurement data from the Genesis Touch System can be transmitted.via a communication module to a central viewing station where the data can be viewed and analyzed by a healthcare professional.

The Genesis Touch Retrospective Physiological Monitoring System is intended for home use by adult and pediatric patients over twelve years of age or in a healthcare related environment by healthcare providers. The Genesis Touch Retrospective Physiological Monitoring System is not intended for emergency use or real-time monitoring and does not have auditory or visual alarms for out-of-limit parameters.

The Honeywell HomMed Genesis Touch™ Retrospective Physiological Monitoring System uses text and voice prompts to help the user acquire vital signs information. Once all data is collected, it is forwarded at the user's discretion, as a data packet to a central viewing station for retrospective review by a healthcare provider. The Genesis Touch Retrospective Physiological Monitoring System is intended for use with adult and pediatric patients over twelve years of age. The Genesis Touch Retrospective Physiological Monitoring System is not intended for emergency use or real-time monitoring.

The provided text does not contain specific acceptance criteria or reported device performance metrics in a tabular format. It focuses on regulatory aspects and substantial equivalence to a predicate device rather than detailed performance study results.

Here's an analysis based on the available information:

1. Table of Acceptance Criteria and Reported Device Performance:

The document does not provide a table specifying acceptance criteria (e.g., minimum accuracy percentages, specific thresholds for vital sign measurement agreement) or corresponding quantitative device performance results. The performance section mentions "Risk based verification and validation testing" but does not elaborate on specific metrics or acceptance thresholds.

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

The document states, "Due to the equivalent indications for use of this system to its predicate, no clinical tests were performed as part of the performance testing." This implies that there was no dedicated test set with human or patient data for a clinical performance study of the Genesis Touch System itself, as its performance relies on the FDA-cleared wireless medical devices it connects to.

3. Number of Experts Used to Establish Ground Truth and Their Qualifications:

As no clinical tests were performed, there were no experts used to establish ground truth for a test set related to the Genesis Touch System's vital sign measurement accuracy. The system's function is data collection, display, and transmission, relying on the accuracy of connected, already-cleared medical devices.

4. Adjudication Method for the Test Set:

Not applicable, as no clinical test set for performance was used.

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

No MRMC study was conducted or reported. The device is a "Retrospective Physiological Monitoring System" that collects and transmits data; it is not an AI-driven diagnostic tool that would typically involve human reader improvement studies.

6. Standalone Performance:

The document states, "Risk based verification and validation testing based on FDA guidance... was performed to ensure that the data is collected and transmitted as intended to the central server."

While this indicates standalone testing of the software's functionality, it does not provide specific standalone performance metrics like accuracy, sensitivity, or specificity for vital sign measurements, as the device itself does not measure vital signs directly but rather collects them from other FDA-cleared devices. The "performance" refers to the correct collection, display, and transmission of data.

7. Type of Ground Truth Used:

For the "Risk based verification and validation testing," the ground truth would likely be established by:

• Known input values: For data collection and transmission tests, the input from the connected vital sign devices would be considered the "ground truth" for what the system should collect and transmit.
• System specifications/requirements: The ground truth for software functionality would be whether the software performs according to its defined specifications for data handling, user interface, and communication protocols.

8. Sample Size for the Training Set:

The document does not mention a "training set" in the context of machine learning or AI, as the device is described as a "proprietary software application" for data collection and transmission, not an AI model that requires training.

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

Not applicable, as there is no mention of a training set for an AI model.

Ask a specific question about this device

The Honeywell HomMed Genesis DM Monitor is designed to retrospectively monitor vital signs. Vital signs include noninvasive blood pressure, pulse rate, and weight. Data from optional commercial stand-alone products extend Genesis DM Monitor's measurement capabilities. Data from the Genesis DM Monitor can be transmitted via a communication module to a central viewing station for display. The Genesis DM Monitor is not intended for emergency use or realtime monitoring.

The Honeywell HomMed Genesis DM Monitor is designed to retrospectively monitor vital signs. Vital signs include noninvasive blood pressure, pulse rate, and weight. Data from optional commercial stand-alone products extend Genesis DM Monitor's measurement capabilities. Data from the Genesis DM Monitor can be transmitted via a communication module to a central viewing station for display. The Genesis DM Monitor is not intended for emergency use or realtime monitoring.

Here's an analysis of the provided text regarding the Honeywell HomMed Genesis DM Monitor, focusing on acceptance criteria and study details.

Based on the provided document, there is no explicit mention of specific numerical acceptance criteria or a comparative study (like MRMC) for the device's performance in measuring vital signs. The document primarily focuses on regulatory compliance and the intended use of the device.

Here's what can be extracted and inferred:

Acceptance Criteria and Reported Device Performance

Study Details

1. Sample size used for the test set and the data provenance (e.g. country of origin of the data, retrospective or prospective):
   The document does not specify a sample size for any test set or the provenance of data used for performance testing. The 'performance data' section refers to general compliance testing (EMC, electrical, mechanical durability, safety, temperature/humidity) and software validation. These are typically engineering tests rather than clinical performance studies with patient data.

2. 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):
   This information is not provided in the document. Given the nature of the tests described (EMC, electrical, mechanical, software validation), "experts" in the sense of medical professionals establishing a ground truth for diagnostic accuracy would not be applicable here. The ground truth for these engineering tests would be established by the specifications and standards themselves.

3. Adjudication method (e.g. 2+1, 3+1, none) for the test set:
   This information is not provided and is not applicable to the types of engineering and software validation tests described. Adjudication methods are typically used in clinical studies where expert consensus is needed for ground truth.

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 MRMC comparative effectiveness study was done or reported. The device described is a vital signs monitor, not an AI-assisted diagnostic tool for human readers. It's intended to collect and display vital signs retrospectively.

5. If a standalone (i.e. algorithm only without human-in-the-loop performance) was done:
   The document mentions "software validation results demonstrated that the Genesis DM Monitor was in compliance... and that it performed within its specifications and functional requirements for software." This implies a standalone software validation was performed to ensure its functionality and adherence to specifications. However, this is distinct from a clinical performance study measuring diagnostic accuracy.

6. The type of ground truth used (expert consensus, pathology, outcomes data, etc.):
   For the mentioned tests:

   • EMC, electrical, mechanical durability, safety, temperature/humidity testing: The "ground truth" would be the specific technical standards and regulatory requirements (e.g., IEC standards, UL standards, etc.) that the device was tested against.
   • Software validation: The "ground truth" would be the pre-defined software specifications and functional requirements themselves, alongside relevant FDA guidelines for medical device software.

7. The sample size for the training set:
   Not applicable. The Honeywell HomMed Genesis DM Monitor is a vital signs monitoring device, not a machine learning or AI algorithm that requires a "training set" in the conventional sense of data-driven model development. The performance data refers to engineering and software validation tests.

8. How the ground truth for the training set was established:
   Not applicable for the same reasons as point 7. No training set for an AI model is mentioned or implied.

Summary of what the document does provide:

The document details the regulatory submission for the Honeywell HomMed Genesis DM Monitor. It states that the device primarily passed various engineering and software validation tests to demonstrate compliance with applicable standards and its own specifications. These tests ensure the device is safe, functions as intended, and meets regulatory requirements for its class. The device's intended use is retrospective monitoring of vital signs, not real-time or emergency monitoring, and it does not appear to involve AI or diagnostic interpretation that would require clinical performance studies with expert consensus or MRMC studies.

Ask a specific question about this device

Central Station's intended use is to retrospectively receive; display and store monitored vital signs parameters and related data. Central Station displays the data and system alerts for review and evaluation by a healthcare professional. Central Station is not intended for emergency use or real-time monitoring.

Central Station is a software system that operates on a commercially available PC system with the minimum performance specifications consistent with typical PC hardware and equipment specifications. Central Station accepts data from Honeywell HomMed Patient Monitors (e.g. Sentry and Genesis) as well as the Honeywell HomMed MedPartner.

The provided text describes a 510(k) submission for the Honeywell HomMed Central Station version 4.0. It primarily focuses on the device's intended use and the general compliance of its software. However, it does not contain detailed acceptance criteria, specific device performance metrics, or a study that rigorously proves the device meets such criteria in a quantitative sense as typically expected for medical device performance evaluation (e.g., accuracy, sensitivity, specificity).

Here's an analysis based on the provided text, highlighting what is present and what is missing:

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

Missing Information: The document does not provide quantitative acceptance criteria (e.g., specific accuracy thresholds, uptime requirements, response times, or error rates for display/storage) or specific performance metrics that would typically be a result of a direct performance study. The reported "performance" is a high-level statement of compliance with general expectations.

2. Sample sized used for the test set and the data provenance (e.g. country of origin of the data, retrospective or prospective)

• Sample Size for Test Set: Not specified.
• Data Provenance: Not specified. The data refers to "monitored vital signs parameters and related data" but there is no information on the origin or nature of this data used for validation. The device's intended use is to "retrospectively receive; display and store" data, which implies it handles retrospective data, but this doesn't clarify the nature of data used for testing its own performance.

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)

• Number of Experts: Not applicable. The device is a "Patient Vital Signs Monitor Viewing Station" and its validation focused on software compliance, specifications, and functional requirements. It does not involve interpretation tasks where expert ground truth would be established for diagnostic accuracy, for example. The "review and evaluation by a healthcare professional" refers to the intended use of the displayed data, not the validation of the device itself by experts.
• Qualifications of Experts: Not applicable.

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

• Adjudication Method: Not applicable. The validation described is for software compliance and functionality, not for diagnostic or interpretive performance requiring adjudication of expert opinions.

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

• MRMC Study: No, an MRMC study was not done.
• Effect Size of Improvement: Not applicable. This device is not an AI-assisted diagnostic tool; it is a data display and storage system.

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

• Standalone Performance: The description of "software validation results demonstrated that the Central Station System was in compliance with the guidelines and standards ... and that it performed within its specifications and functional requirements for software" implies a standalone evaluation of the software's ability to process, display, and store data. However, it's not "algorithm only" in the sense of a predictive or diagnostic algorithm. It's a functional software system.

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

• Type of Ground Truth: Not explicitly stated as "ground truth" in a clinical sense. For software validation, the "ground truth" would be the expected behavior or outcome based on the software's specifications and requirements. For example, if a vital sign reading is X, the "ground truth" for the display function is that it should display X correctly. The document only mentions that the software "performed within its specifications and functional requirements," implying that its output was compared against its design requirements for proper functioning.

8. The sample size for the training set

• Sample Size for Training Set: Not applicable. This is not a machine learning or AI device that requires a training set. It is a software system for data display and storage.

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

• How Ground Truth for Training Set was Established: Not applicable, as there is no training set for this type of device.

In summary: The provided 510(k) summary focuses on the regulatory compliance and general functional validation of a software system designed to receive, display, and store vital sign data. It explicitly states that "the software validation results demonstrated that the Central Station System was in compliance with the guidelines and standards referenced in the FDA reviewer's guides and that it performed within its specifications and functional requirements for software." This type of submission relies on demonstrating that the software meets its pre-defined design and functional requirements rather than clinical performance metrics often associated with diagnostic or AI-powered devices. The absence of quantitative performance data, expert reviews, or MRMC studies is consistent with the nature of this device as a data viewing station rather than a diagnostic tool.

Ask a specific question about this device

The Honeywell HomMed Genesis OTC Monitor is designed to retrospectively monitor vital signs. Vital signs include noninvasive blood pressure, pulse rate, and weight. Data from optional commercial stand-alone products extend Genesis OTC Monitor's measurement capabilities. Data from the Genesis OTC Monitor can be transmitted via a communication module to a central viewing station for display. The Genesis OTC Monitor is not intended for emergency use or real-time monitoring.

The Honeywell HomMed Genesis OTC Monitor System is a vital signs monitoring system. The system measures noninvasive blood pressure, pulse rate, and weight. The Genesis OTC Monitor has four serial ports available for external options. The Genesis OTC Monitor acquires vital signs data and displays it. The data can also be transmitted via the communication system to a central viewing station.

Here's an analysis of the provided text regarding the acceptance criteria and supporting study for the Honeywell HomMed Genesis OTC Monitor System:

1. Table of Acceptance Criteria and Reported Device Performance

The provided text does not explicitly state specific numerical acceptance criteria for the device's performance in terms of vital signs measurement accuracy (noninvasive blood pressure, pulse rate, weight). Instead, it relies on compliance with general standards and demonstrating equivalence to a predicate device.

The reported device performance is described in terms of compliance with these standards and functional specifications.

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

The document does not specify a sample size for any clinical or performance test set. It mentions "testing" but provides no details on the number of subjects or data points.

The data provenance is not explicitly stated as retrospective or prospective, or country of origin. The study described appears to be a series of engineering and compliance tests rather than a clinical trial with patient data.

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 "ground truth" in this context appears to be defined by the technical standards (e.g., EN 60601-1, IEC 601-1-2, ISO 10993) and the performance of the predicate device, rather than expert consensus on medical measurements from a test set.

4. Adjudication Method for the Test Set

This information is not applicable or not provided. Since no clinical test set with human measurements requiring adjudication is described, there's no mention of adjudication methods.

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

No, a Multi-Reader Multi-Case (MRMC) comparative effectiveness study was not done. The submission focuses on device equivalence and compliance with technical standards, not on human reader performance with or without AI assistance. This device is a vital signs monitor, not typically an imaging-based AI diagnostic tool that would involve human readers interpreting AI output.

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

The study described is essentially a standalone (device-only) performance evaluation against technical standards and comparison to a predicate device's specifications. The device's function is to measure vital signs, and its compliance is assessed independent of a human interpreting its readings in a "human-in-the-loop" clinical trial setting. The "OT" in "OTC" (Over-The-Counter) implies direct user interaction without a clinician interpreting the raw data in real-time.

7. Type of Ground Truth Used

The ground truth used in this submission appears to be:

• Compliance with established engineering and safety standards: EN 60601-1, IEC 601-1-2, ISO 10993-5,10-11, and FDA reviewer's guides for respiratory devices.
• Performance of the legally marketed predicate device: HomMed Genesis Patient Monitor System (K040799). The new device is deemed "as safe, as effective and performs as well as" the predicate.

8. Sample Size for the Training Set

The document does not mention a training set. This device likely uses traditional signal processing and measurement algorithms, not machine learning or AI that would require a distinct training set for model development.

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

As no training set is mentioned or implied, this information is not applicable.

Ask a specific question about this device

The Honeywell HomMed Sentry OTC Monitor is designed to retrospectively monitor vital signs. Vital signs include noninvasive blood pressure, pulse rate, oral temperature and weight. Data from optional commercial stand-alone products extend the Sentry OTC Monitor's measurement capabilities. Data from the Sentry OTC Monitor can be transmitted via a communication module to a central viewing station for display. The Sentry OTC Monitor is not intended for emergency use or real-time monitoring.

The Honeywell HomMed Sentry OTC Monitor is a vital signs monitoring system. The system measures noninvasive blood pressure, pulse rate, oral temperature and weight. The Sentry OTC Monitor has six serial ports available for external options. The Sentry OTC Monitor acquires the vital signs data and displays it. The data can be transmitted via the communication module to a central viewing station.

The provided text is a 510(k) summary for the Honeywell HomMed Sentry OTC Monitor, which is a vital signs monitoring system. It leverages a predicate device (HomMed Sentry IIIB Patient Monitor System K040651) and highlights compliance with various voluntary standards.

Here's an analysis of the acceptance criteria and study information, based on the provided document:

1. Table of Acceptance Criteria and Reported Device Performance

The document does not explicitly state numerical acceptance criteria for specific vital sign measurements (e.g., blood pressure accuracy in mmHg, pulse rate deviation). Instead, it uses a qualitative statement of compliance with standards and equivalence to a predicate device.

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

The document does not specify a separate "test set" with a defined sample size for clinical validation focusing on vital sign accuracy. The "Test Summary" refers to engineering and quality assurance testing (EMC, electrical, mechanical durability, safety, temperature/humidity).

• Sample Size for Test Set: Not specified for clinical performance validation. The document focuses on regulatory compliance testing.
• Data Provenance (e.g., country of origin, retrospective or prospective): Not specified. The testing described appears to be laboratory-based engineering and quality assurance testing rather than a clinical trial with patient data.

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

Given that the testing described is primarily engineering and compliance-oriented, there is no mention of "experts" in the sense of clinical specialists establishing a "ground truth" for patient data. The ground truth for electrical, mechanical, and temperature/humidity tests would be established by reference standards and calibrated equipment.

4. Adjudication Method for the Test Set

Not applicable. The testing described does not involve a human-reader or diagnostic output that would require an adjudication method.

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

No, an MRMC comparative effectiveness study was not done. This device is a vital signs monitor, not an imaging or diagnostic device requiring human interpretation, so such a study would not be relevant.

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

Yes, the testing described appears to be standalone performance of the device against engineering standards and compliance requirements. The statement "The Honeywell HomMed Sentry System (Sentry OTC and its predicate Sentry IIIB) utilized within the environments for which it is marketed performs consistent with guidelines and standards..." implies standalone performance evaluation. No human interpretation of the output is involved for the device's basic function of measuring vital signs.

7. Type of Ground Truth Used

The ground truth used for the reported tests would be:

• Reference Standards/Calibrated Equipment: For electrical, mechanical, EMC, temperature, and humidity testing.
• Regulatory Standards: For safety and biocompatibility.
• Predicate Device Performance: The primary "ground truth" for demonstrating substantial equivalence is the performance of the legally marketed predicate device, the HomMed Sentry IIIB Patient Monitor System (K040651). The device is stated to perform "as safe, as effective and performs as well as" the predicate.

8. Sample Size for the Training Set

Not applicable. This device is a vital signs monitor, not an AI/ML-based diagnostic algorithm that requires a training set of data.

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

Not applicable, as there is no training set for this type of device.

Ask a specific question about this device

Central Station's intended use is to retrospectively receive, display and store monitored vital signs parameters and related data. The Central Station displays the data and system alerts for review and interpretation by a healthcare professional. Central Station is not intended for emergency use or real-time monitoring.

Central Station is a software system that operates on a commercially available PC system with the minimum performance specifications consistent with typical PC hardware and equipment specifications. Central Station accepts data from Honeywell HomMed Patient Monitors (Sentry and Genesis) as well as the Honeywell HomMed MedPartner.

The provided text describes the Honeywell HomMed Central Station, Version 3.5, a software system for retrospectively receiving, displaying, and storing monitored vital signs parameters and related data.

Here's an analysis of the acceptance criteria and study information based on the provided document:

1. Table of Acceptance Criteria and Reported Device Performance

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

The document does not explicitly state a specific "test set" in the traditional sense of a clinical or image-based study. The performance data section refers to "software validation results." This suggests that the testing was primarily focused on the software's functionality, data integrity, and compliance with specifications, rather than a clinical trial with patient data.

• Sample Size for Test Set: Not specified, but likely refers to various data inputs and scenarios used during software validation.
• Data Provenance: Not specified. Given the nature of a software validation for a "Central Station," it's probable that various types of simulated or recorded vital signs data would have been used to test the system's ability to receive, display, and store. It's not a direct patient study with geographical or temporal data provenance.

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

This information is not provided in the document. For a software system like the Central Station, "ground truth" would likely refer to the correctness of the data received, displayed, and stored, and the proper functioning of alerts based on predefined thresholds. The "experts" would likely be software testers, quality assurance personnel, and potentially clinical subject matter experts validating the accuracy of the displayed information against expected results. However, their numbers and specific qualifications are not mentioned.

4. Adjudication Method for the Test Set

This information is not provided in the document. Given that this is a software system for data display and storage, traditional adjudication methods for diagnostic images or clinical outcomes might not directly apply. The "adjudication" would likely be the verification of software outputs against expected behavior, potentially involving multiple testers or a structured review process, but no specific method is detailed.

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

No, an MRMC comparative effectiveness study was not done. The device is a "Central Station" software system, not an AI-powered diagnostic tool that directly assists human readers in interpreting medical images or making clinical diagnoses. Its function is to display and store vital signs data for review by healthcare professionals.

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

The entire study implicitly describes a standalone performance, as the "Central Station" software is the primary subject. The "software validation results demonstrated that the Central Station 3.5 System was in compliance... and that it performed within its specifications and functional requirements for software." This indicates a focus on the algorithm's direct functionality in processing and presenting data. However, it's crucial to understand that while the software operates standalone in processing, its intended use is for review and interpretation by a healthcare professional, meaning it's inherently part of a human-in-the-loop workflow.

7. Type of Ground Truth Used

The ground truth for this device would be defined by the correctness of software functionality and data integrity. This means:

• The system accurately receives data from specified patient monitors.
• The system accurately displays the vital signs parameters and related data.
• The system accurately stores the data.
• System alerts function correctly based on intended logic.
• The software complies with established guidelines and standards.

This is fundamentally a functional and performance validation against predefined software requirements and industry standards, rather than a clinical ground truth like pathology or patient outcomes.

8. Sample Size for the Training Set

This information is not applicable/not provided. The Honeywell HomMed Central Station is described as a software system that receives, displays, and stores vital signs data. It is not an AI/ML device that requires a "training set" in the context of machine learning model development. The software's logic and functionality are likely rule-based or algorithmic, programmed to perform specific tasks, rather than learned from a dataset.

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

This information is not applicable as there is no "training set" for this type of software device.

Ask a specific question about this device

The HomMed Genesis Patient Monitor with Options is a system designed to monitor patient vital signs at home and/or in healthcare facilities. Vital signs include pulse oximetry (optional), noninvasive blood pressure, pulse rate, and weight. Data from optional commercial stand-alone products including glucose meter, spirometer, and prothrombin time can be exported via the Genesis communication module. Vital signs data is transmitted via modem to a central viewing station for display, analysis and monitoring by healthcare professionals. All patient data is collected, stored, forwarded and displayed in a retrospective manner, and is not intended to provide real-time critical care monitoring of patients, nor any local alarms or alerts of patient status.

The HomMed Genesis Patient Monitor System with Options (HomMed Genesis) is a portable patient vital signs monitoring system. The system measures pulse oximetry (optional), noninvasive blood pressure, pulse rate, and weight. HomMed Genesis will have four serial ports available for external options. The Genesis acquires the patient vital signs data and displays it. The data can also be transmitted via the communication system through the Skytel or PageNet Pager Network to a central station for storage with retrospective display and analysis.

The provided text is a 510(k) summary for the HomMed Genesis Patient Monitor System. It outlines the device description, intended use, and a comparison with a predicate device. However, it does not contain acceptance criteria for device performance or a detailed study proving the device meets specific performance criteria beyond general compliance with voluntary standards.

The summary states:

• "The HomMed Genesis employs the same technologies as the predicate Technology: device, HomMed Sentry III Patient Monitor System with Card Reader."
• "The Genesis monitor complies with the following voluntary standards: Medical Electrical Safety EN 60601-1, EMC Compliance IEC 601-1-2, Biocompatibility ISO 10993-5,10-11."
• "It is the HomMed position that the results of these measures demonstrate Conclusion: HomMed Genesis is as safe, as effective and performs as well as the leqally marketed predicate device, HomMed Sentry III Patient Monitor System with Card Reader."

This indicates that the device's acceptance is primarily based on substantial equivalence to a predicate device and compliance with general safety and EMC standards, rather than specific performance metrics (like accuracy, sensitivity, specificity, etc.) for its vital sign measurements as would be expected for a diagnostic AI/ML device.

Therefore, many of the requested details about acceptance criteria and a study proving device performance cannot be extracted directly from this document.

Here's an attempt to answer based on the available information, noting the missing details:

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

Comment: The document focuses on regulatory compliance and equivalence rather than specific performance metrics for the vital sign measurements themselves. For a device measuring vital signs like blood pressure, pulse oximetry, and pulse rate, one would typically expect to see performance criteria related to accuracy, bias, and precision against a reference standard. These are absent here, likely because the 510(k) process in this instance relies heavily on the predicate device's established performance.

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

• Sample Size (Test Set): Not specified. The document does not describe a clinical performance study with a test set.
• Data Provenance: Not applicable, as no specific performance study with a test set is detailed.

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

• Not applicable, as no specific performance study with a ground truth-established test set is detailed.

4. Adjudication method for the test set

• Not applicable, as no specific performance study with a test set requiring adjudication is detailed.

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, a multi-reader multi-case (MRMC) comparative effectiveness study was not done. The device is a vital signs monitor, not an AI-assisted diagnostic imaging tool with human-in-the-loop performance.

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

• The device itself is a standalone vital signs monitor. Its performance is compared to a predicate device, and it complies with voluntary standards. However, the document does not detail specific standalone performance studies for accuracy of the vital sign measurements against a gold standard as one might see for an AI algorithm. Its function is to acquire and transmit data, not to perform complex algorithmic interpretations that require "human-in-the-loop" interaction in the typical AI/ML sense.

7. The type of ground truth used

• Not applicable, as no specific performance study with a ground truth is detailed. Performance is asserted based on technological equivalence to a predicate device and compliance with general safety standards.

8. The sample size for the training set

• Not applicable, as this device does not appear to involve AI/ML that would require a "training set" in the conventional sense (e.g., for image recognition or predictive modeling). It is a hardware system for measuring physiological parameters.

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

• Not applicable.

Ask a specific question about this device

The HomMed Sentry IIIB-F Patient Monitor System is designed to measure Patient Vital Signs in the home by patients or in clinical environments by health care providers. The HomMed Sentry IIIB-F Patient Monitor System is available with physicians' orders only.

The HomMed Sentry IIIB-F Patient Monitor System measures the following parameters: Non-Invasive Blood Pressures (Systolic and Mean Arterial Pressure), Functional Oxygen Saturation (%SpO₂), Peripheral Pulse Rate (PPR), Pulse Strength, Oral Temperature and Patient Weight via an external scale. The HomMed Sentry IIIB-F Patient Monitor System's optional, compatible devices extend those measurements to glucometer, spirometer, electrocardiogram (ECG) and prothrombin time (PT/INR) monitoring and digital image acquisition. The patient parameter data is collected and displayed by the HornMed Sentry IIIB-F Patient Monitor System. Data can be transmitted via the communication module to a central station where the patient data can be viewed and analyzed.

The HomMed Sentry IIIB-F Patient Monitor System (Sentry IIIB-F) is a portable patient vital signs monitoring system. The system measures noninvasive blood pressure, pulse rate, oral temperature, oximetry, and weight. In addition, the system has optional glucometer, spirometer, electrocardiogram (ECG) and prothrombin time (PT/INR) measuring, and digital image acquisition capabilities. The Sentry IIIB-F acquires the patient vital signs data and displays it. The data can also be transmitted via the communication system through the Skytel or PageNet Pager Network to a central station for storage with retrospective display and analysis.

Sentry IIIB-F provides a noninvasive blood pressure (NIBP) monitor for measurements of a patient's systolic, diastolic, and mean arterial (MAP) blood pressures; pulse oximeter, acquires a pulse rate using an oximeter; oral temperature via an electronic thermometer; weight from an electronic scale. All data collected from these functions as well as optional glucometry, ECG devices, PT/INR monitor and acquired digital images are sent through an internal communication module.

The provided 510(k) summary for the HomMed Sentry IIIB-F Patient Monitor System states that the device's performance has been confirmed to be equivalent to its predicate device (HomMed Sentry III Patient Monitor System with Card Reader, K014025). The summary also mentions compliance with various national and international standards. However, it does not provide a detailed list of specific acceptance criteria or the reported device performance in a numerical or quantitative format. Instead, it offers a general statement regarding compliance and consistency with guidelines.

Therefore, the requested table of acceptance criteria and reported device performance, as well as several other detailed study parameters, cannot be fully extracted from the provided text. The document focuses on regulatory compliance and equivalence to a predicate device rather than presenting a standalone clinical or performance study with detailed statistical results.

Here's a breakdown of what can and cannot be extracted from the provided document:

1. Table of Acceptance Criteria and Reported Device Performance

2. Sample size used for the test set and the data provenance (e.g. country of origin of the data, retrospective or prospective)

• Not specified. The document mentions "testing done on the Sentry III IIIB-F" but does not provide details on sample size (e.g., number of patients, number of measurements), data provenance, or whether the study was retrospective or prospective.

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)

• Not applicable/Not specified. The nature of the device (vital signs monitor) suggests that ground truth would typically be established by validated reference devices rather than human experts interpreting complex data. The document does not mention any expert involvement in establishing ground truth for testing.

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

• Not applicable/Not specified. This type of adjudication is typically used for subjective interpretations by multiple human readers (e.g., in imaging studies). For a vital signs monitor, performance is usually assessed against a known standard or reference device, not via subjective 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

• No. This is not an AI-assisted device, nor is it a device that involves human readers interpreting complex cases in the way that an MRMC study would apply. Therefore, no such study was conducted or reported.

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

• Yes, implicitly. The "Performance Data" section describes "testing done on the Sentry III IIIB-F" to assure compliance with standards and to demonstrate it "performed within its specifications and functional requirements." This refers to the device's inherent performance. Since this is a direct vital signs measurement device, its "standalone" performance is its primary mode of operation. There is no "algorithm only" in the sense of an AI model being evaluated separately from the device's physical sensors and processing.

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

• Implicitly, reference standards or validated measurement methods. For vital signs, ground truth would be established by highly accurate, often invasive or gold-standard, reference devices (e.g., intra-arterial blood pressure for NIBP, co-oximetry for SpO2, calibrated scales for weight, etc.). The document does not explicitly state the specific reference devices used but implies comparison to established and validated measurement techniques.

8. The sample size for the training set

• Not applicable/Not specified. This device is not an AI/machine learning device that requires a training set in the conventional sense. Its performance is based on traditional signal processing and sensor technology, not a learned model.

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

• Not applicable/Not specified. As mentioned above, there is no "training set" for this type of device.

Ask a specific question about this device

The HomMed Central Station intended use is to retrospectively receive, display, and store certain monitored physiological parameters received from adult and pediatric (over 12 years of age) patients within healthcare and home environments. Central Station, Version 3.3H includes a HL7 interface to transfer data from HomMed Central Station to vendor systems and storage media. The physiologic patient parameters available for retrospective display and evaluation include NIBP, pulse rate, SpO2, temperature, and weight. Additionally monitoring device data from optional commercial stand-alone products including glucometry, spirometry, prothrombin time, ECG and digital camera images can also be received, displayed and stored. The Central Station displays patient data and system alerts for review and interpretation by physicians and/or physician supervised nurses. Central Station is a retrospective data monitor system and is not intended for emergency use or real-time monitoring.

The HomMed Central Station is a software system that operates on a commercially available PC system with the minimum performance specifications consistent with typical PC hardware and equipment specifications. The HomMed Central Station is a software system that accepts data from the HomMed Sentry Patient Monitors.

The provided text describes the HomMed Central Station, Version 3.3H, a device intended to retrospectively receive, display, and store physiological parameters. However, the document does not contain information regarding specific acceptance criteria, a detailed study proving performance, sample sizes for test/training sets, expert qualifications for ground truth, adjudication methods, MRMC studies, or how ground truth was established beyond a general statement of "software validation results."

The "Performance Data" section states that "The software validation results demonstrated that the HomMed Central Station 3.3H System was in compliance with the guidelines and standards referenced in the FDA reviewer's guides and that it performed within its specifications and functional requirements." This is a high-level summary and does not provide the specific details requested in the prompt.

Therefore, I can only provide limited information based on the text.

Here's a breakdown of the requested information based on the provided document:

1. Table of acceptance criteria and the reported device performance

The document does not specify quantitative acceptance criteria. The performance is stated generally:

2. Sample size used for the test set and the data provenance (e.g. country of origin of the data, retrospective or prospective)

• Sample size for the test set: Not specified in the provided document.
• Data provenance: Not specified in the provided document. The device itself retrospectively receives data, but the provenance of data used for validation is not mentioned.

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)

• Not specified in the provided document.

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

• Not specified in the provided document.

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 comparative effectiveness study is mentioned or implied. The device is a data display and storage system, not an AI-powered diagnostic tool for human reader improvement.

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

• The document implies a standalone software validation was performed ("The HomMed Central Station is a software system... The software validation results demonstrated..."), but specific details on the methodology (e.g., comparison to a reference standard without human involvement) are not provided. The phrase "algorithm only" might not be fully applicable as it's a data management system, not a diagnostic algorithm.

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

• Not specified. The statement "performed within its specifications and functional requirements" suggests validation against predetermined software requirements and potentially functional testing, but the nature of the "ground truth" for the physiological parameters themselves is not detailed.

8. The sample size for the training set

• Not specified in the provided document.

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

• Not specified in the provided document.

Ask a specific question about this device