Search Results

The indications for use of the BeneVision Central Monitoring System include:

• Real time viewing of patient clinical data and alarms from compatible physiological monitors. Viewing of non-real time patient clinical data of compatible anesthesia devices (i.e. not indicated for real-time monitoring of clinical data of compatible anesthesia devices).

• Storage and Historical review of patient clinical data and alarms from compatible physiological monitor, and anesthesia devices.

• Printing patient data from compatible physiological monitor, and anesthesia devices.

• Configuration of local settings as well as synchronizing settings across the network to remote compatible physiological monitors.

• Transfer of patient clinical data and settings between several CentralStations.

• Provides a Resting 12 Lead interpretation of previously stored data.

The BeneVision Central Monitoring System is a networked patient monitoring system intended for use in a fixed location, installed in professional healthcare facilities to provide clinicians remote patient monitoring. The network connections between the various devices can be any combination of Ethernet (Wired), Wireless WIFI (WLAN), and Wireless WMTS.

The BeneVision Central Monitoring System supports one or more Mindray compatible physiological monitors, anesthesia systems and will display, store, print, and transfer information received from the compatible monitors, anesthesia systems.

The telemetry monitoring systems are designed to acquire and monitor physiological data for ambulating patients within a defined coverage area. The BeneVision Central Monitoring System supports Telemetry Systems: TMS-6016, Telepack-608, TMS60, TM80, and TM70.

• The TMS-6016 transmitter is intended for use on Adult and Pediatric patients to monitor ECG and SpO2 physiological data.

• The Panorama Telepack-608 transmitter is intended for use on Adult patients to monitor ECG and SpO2 physiological data.

• The TMS60 transmitter is intended for use on Adult and Pediatric patients over three years old to monitor ECG, SpO2, NIBP and Resp physiological data. The physiological data can be reviewed locally on the display of the transmitter. The CentralStation will support ECG, Heart Rate, SpO2, NIBP, Resp, Pulse Rate, Arrhythmia analysis, QT monitoring, and ST Segment Analysis for the TMS60.

• The TM80/TM70 telemetry monitor is intended for use on Adult and Pediatric patients over three years old to monitor ECG, SpO2, NIBP and Resp physiological data. The physiological data can be analyzed, alarmed, stored, reviewed locally on the display of the monitor, and the CentralStation can config and display the physiological parameters from the TM80/TM70.

The BeneVision Central Monitoring System is intended for use in professional healthcare facilities under the direct supervision of a licensed healthcare practitioner.

The BeneVision Central Monitoring System (CMS) is a networked patient monitoring system intended for use in healthcare settings by, or under the direction of, a physician to provide clinicians remote patient monitoring. The target patient population is adult patients and pediatrics.

When connected to a compatible anesthesia device, BeneVision CMS can display the parameters, waveforms and alarms of the anesthesia device. The device does not contain bi-directional capabilities for the compatible anesthesia devices.

The BeneVision CMS includes the AlarmGUARD application. AlarmGUARD supports delivering notifications of physiological and technical alarms to clinical professionals' mobile devices. AlarmGUARD is not intended for real time monitoring of patients and is not intended to act as a primary source for alarms.

It appears the provided FDA 510(k) clearance letter and summary for the BeneVision Central Monitoring System (K242728) does not contain specific acceptance criteria, test results (like sensitivity/specificity, accuracy metrics), or detailed study methodologies that directly address how the device's performance meets quantitative acceptance criteria for its intended functions.

The document primarily focuses on demonstrating substantial equivalence to a predicate device (K220058) through:

• Comparison of Indications for Use: Showing minor differences (expanded compatibility to include anesthesia systems, but not for real-time monitoring).
• Technological Comparisons: Highlighting changes in operating systems, host configurations, and the addition of features like Multi-Patient Viewer separation and AlarmGUARD support.
• Performance Data Section: This section lists the types of testing conducted but does not provide the results of those tests or specific acceptance criteria met by those results. It merely states that "Software verification and validation testing was conducted" and "Verification of the BeneVision Central Monitoring System was conducted to ensure that the product works as designed. Validation was conducted to check the design and performance of the product."

Therefore, based solely on the provided text, I cannot extract the detailed information requested in your prompt regarding acceptance criteria, reported performance, sample sizes, expert qualifications, adjudication methods, MRMC studies, standalone performance, or training set details.

The document confirms the following regarding the study:

• Study Type: Software verification and validation testing, along with specific bench testing.
• Clinical Data/Animal Testing: Not applicable/not required for this submission to establish substantial equivalence. This suggests the clearance relies on non-clinical data and comparison to the predicate.
• Ground Truth: The document implies that the ground truth for software verification and validation would be the design specifications and expected behavior of the system, rather than clinical outcomes or expert consensus on a diagnostic task. For the "Waveform Display Accuracy from compatible Anesthesia Machine," the ground truth would likely be the direct output from the anesthesia machine itself.

What is present in the document that somewhat relates to your request:

• "Bench Testing" section (Page 19): This lists specific tests performed:
  • AlarmGUARD IEC 60601-2-27
  • AlarmGUARD IEC 60601-1-8
  • AlarmGUARD Human Factors
  • Waveform Display Accuracy from compatible Anesthesia Machine

To fulfill your request as best as possible with the given information, I will have to state that many details are explicitly absent from this public 510(k) summary.

Here's a structured response based on the provided document, indicating what information is present and what is absent:

Device Acceptance Criteria and Performance Study Summary (K242728)

Based on the provided FDA 510(k) Clearance Letter and Summary, detailed quantitative acceptance criteria and specific performance metrics (like accuracy, sensitivity, specificity) for the BeneVision Central Monitoring System are not explicitly presented. The submission primarily relies on demonstrating substantial equivalence to a predicate device (K220058) through verification and validation of software and specific bench testing.

The document states that "Software verification and validation testing was conducted and documentation was provided as recommended by FDA's Guidance 'Content of Premarket Submissions for Device Software Functions: Guidance for Industry and Food and Drug Administration Staff'." It also mentions that "Verification of the BeneVision Central Monitoring System was conducted to ensure that the product works as designed. Validation was conducted to check the design and performance of the product."

1. Table of Acceptance Criteria and Reported Device Performance

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

• Test Set Sample Size: Not specified in the provided document for any of the listed tests (AlarmGUARD, Waveform Display Accuracy, general software V&V).
• Data Provenance: Not specified (e.g., country of origin, retrospective/prospective). Given that no clinical data was used or required, the "data" would be synthetic, simulated, or derived from direct device connections during bench testing.

3. Number of Experts and Qualifications for Ground Truth

• Not applicable / Not specified. The document does not describe the use of human experts to establish ground truth for a diagnostic task or for the performance evaluation of this central monitoring system. The focus is on software function and electro-mechanical performance validation against design specifications and international standards.

4. Adjudication Method for the Test Set

• Not applicable / Not specified. No adjudication method is mentioned as human reader input for a test set is not described.

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

• No. The document explicitly states that "Clinical testing is not required to establish substantial equivalence to the predicate device" and does not mention any MRMC study. This device is a central monitoring system displaying physiological data, not an AI diagnostic tool requiring MRMC studies for improved human reader performance.

6. Standalone Performance (Algorithm Only)

• The "performance data" section lists "Software Verification and Validation Testing" and "Bench Testing" (including "Waveform Display Accuracy from compatible Anesthesia Machine"). These tests conceptually represent 'standalone' performance in that they evaluate the device's technical functions directly. However, no specific quantitative standalone performance metrics (e.g., classification accuracy, sensitivity, specificity for any internal algorithms) are provided in this summary beyond the statement that v&v was conducted to ensure the product "works as designed."

7. Type of Ground Truth Used

• The ground truth for the device's performance appears to be:
  • Design Specifications: For general software verification and validation.
  • External Reference Standards/Simulators: For tests like "Waveform Display Accuracy" (e.g., comparing the displayed waveform to the known, true signal generated by a simulator or the anesthesia machine itself).
  • International Standards: For AlarmGUARD functionality (e.g., IEC 60601-2-27, IEC 60601-1-8).

8. The Sample Size for the Training Set

• Not applicable / Not specified. This document describes a traditional medical device (patient monitoring system software) rather than a machine learning/AI device that typically requires a distinct "training set." Therefore, no training set size is mentioned.

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

• Not applicable / Not specified. As no training set for an AI/ML model is indicated, there is no mention of how its ground truth would be established.

Ask a specific question about this device

MFM-CMS central monitoring system (hereinafter referred to as MFM-CMS) supports centralized management of patients' clinical data provided by EDAN medical devices. Clinicians can obtain patient clinical data via MFM-CMS. The indications for use of the MFM-CMS central monitoring system include:

• · Viewing patient real-time clinical data and alarms.
• · Storing and reviewing patient clinical data and alarms.
• · Printing real-time and history patient data.
• · Configuring local settings as well as synchronizing settings to a remote device through network.
• · Accessing patient clinical data between several departments.

MFM-CMS is intended to be used only in clinical or hospital environment by well-trained healthcare professionals.

MFM-CMS is indicated for use when monitoring adult and/or pediatric and/or neonate patients as indicated by labeling of the medical device providing the data.

MFM-CMS is a central monitoring system product, which can connect and manage information from EDAN medical devices. MFM-CMS offers central management for monitoring information from the medical devices. All these collected information can be displayed, printed, alarmed and recorded.

The provided text is a 510(k) summary for the Edan Instruments, Inc. MFM-CMS Central Monitoring System. It describes the device, its intended use, and a comparison to predicate devices, but does not contain information related to specific acceptance criteria, reported device performance in those criteria, sample sizes, expert qualifications, or ground truth establishment for a diagnostic AI device.

The submission is for a "Central Monitoring System" (MFM-CMS), which supports centralized management of patient clinical data from other EDAN medical devices. It is classified as an "Arrhythmia detector and alarm (including ST-segment measurement and alarm)" with product code MHX. However, the summary focuses on the system's ability to display, store, review, and print data, and manage settings, rather than its performance as an arrhythmia detector itself.

Therefore, many of the requested details cannot be extracted from this document, as they are typically found in the clinical validation studies of algorithms that perform diagnostic or interpretative tasks.

Here's an analysis based on the information available in the document:

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

This information is not provided in the document. The submission focuses on functional changes and comparison to predicates, not specific performance metrics like sensitivity, specificity, or accuracy for an arrhythmia detection algorithm. The "Performance" section within the comparison table refers to features like "Bi-directional Configuration" and "Data Review," not numerical performance criteria.

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

This information is not provided. The document states "Clinical testing: Not applicable. Clinical testing is not required to establish substantial equivalence to the predicate device." This indicates that no clinical test set was used to validate the device's performance in a diagnostic capacity.

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)

This information is not provided, as no clinical test set for diagnostic accuracy was utilized.

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

This information is not provided, as no clinical test set for diagnostic accuracy was utilized.

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

There is no indication that an MRMC study was done. The device is a "Central Monitoring System" and is not described as an AI-powered diagnostic tool that assists human readers.

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

This information is not provided, as the document does not describe the MFM-CMS as a standalone diagnostic algorithm. Its primary function is a central data management system. Although it is classified under "Arrhythmia detector and alarm," the detailed description of its updates and comparison to predicates emphasizes data handling and system functionality rather than algorithm performance for arrhythmia detection.

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

This information is not provided, as no clinical validation study is described.

8. The sample size for the training set

This information is not provided. As the submission focuses on software updates and functional equivalence, details about training sets for an AI algorithm are not relevant or discussed.

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

This information is not provided, as no clinical validation study or AI training is described.

Summary of what is available in the document:

The document describes the MFM-CMS as a central monitoring system that connects to other EDAN medical devices to manage patient clinical data. The submission is for an updated version (K232694) of an existing device (K120727), with the primary predicate being the BeneVision Central Monitoring System (K220058).

Key changes and comparisons:

The main changes to the software include:

• Add distributed function.
• Add license authorization.
• Support department management, device management, and user management.
• Support time synchronization function.
• Support data automatic dump function.
• Replace the software development platform.
• Supports simultaneous login of multiple clients.
• Support domain account to log in to the CMS client.

The comparison table highlights similarities and differences in intended use, operating system support, data review features, calculations, telemetry support, print capabilities, and network connectivity between the subject device and its predicate.

Performance Data (as per the document):
The document states:

• Non-clinical test: Biocompatibility testing and Electrical safety & electromagnetic compatibility (EMC) are "Not applicable."
• Software Verification and Validation Testing: Conducted in accordance with FDA guidance for software in medical devices.
• Bench Testing: Functional and system-level testing was conducted to validate performance, and results "show that the subject device meets relevant consensus standards" (e.g., IEC 60601-1-8:2006 + Am1:2012 for alarm systems).
• Clinical testing: "Not applicable. Clinical testing is not required to establish substantial equivalence to the predicate device."

Conclusion: The submission concludes that "The bench testing data and software verification and validation demonstrate that MFM-CMS Central Monitoring System is substantially equivalent to the predicate devices."

In essence, this FDA 510(k) summary focuses on demonstrating that the updated MFM-CMS system maintains the safety and effectiveness of its predicate devices through non-clinical testing and software verification, rather than providing a detailed performance study of a diagnostic algorithm against specific clinical acceptance criteria.

Ask a specific question about this device

The indications for use of the BeneVision Central Monitoring System include:

• Real time viewing of patient clinical data and alarms .
• . Storage and Historical review of patient clinical data and alarms
• Printing of real time and historical patient data
• Configuration of local settings as well as synchronizing settings across the network to a remote device
• Transfer of patient clinical data and settings between several CentralStations
• Provides a Resting 12 Lead interpretation of previously stored data

The BeneVision Central Monitoring System is a networked patient monitoring system intended for use in a fixed location, installed in professional healthcare facilities to provide clinicians remote patient monitoring. The network connections between the various devices can be any combination of Ethernet (Wireless WIFI (WLAN), and Wireless WMTS. The BeneVision Central Monitoring System supports one or more Mindray compatible physiological monitors and will display, store, print, and transfer information received from the compatible monitors. The Bene Vision Central Monitoring System supports bi-directional configuration of the compatible monitors.

The telemetry monitoring systems are designed to acquire and monitor physiological data for ambulating patients within a defined coverage area. The BeneVision Central Monitoring System supports Telemetry Systems: TMS-6016, Telepack-608, TMS60, TM80 and TM70.

The TMS-6016 transmitter is intended for use on Adult and Pediatric patients to monitor ECG and SpO2 physiological data.

The Panorama Telepack-608 transmitter is intended for use on Adult patients to monitor ECG and SpO2 physiological data.

The TMS60 transmitter is intended for use on Adult and Pediatric patients over three years old to monitor ECG, . SpO2, NIBP and Resp physiological data. The physiological data can be reviewed locally on the display of the transmitter. The CentralStation will support ECG, Heart Rate, SpO2, NIBP, Resp, Pulse Rate, Arrhythmia analysis, QT monitoring, and ST Segment Analysis for the TMS60.

. The TM80/TM70 telemetry monitor is intended for use on Adult and Pediatric patients over three years old to monitor ECG. SpO2. NIBP and Resp physiological data. The physiological data can be analyzed, alarmed, stored, reviewed locally on the display of the monitor, and the CentralStation can config and display the physiological parameters from the TM80/TM70.

The BeneVision Central Monitoring System is intended for use in professional healthcare facilities under the direct supervision of a licensed healthcare practitioner.

The BeneVision Central Monitoring System (CMS) is a networked patient monitoring system intended for use in healthcare settings by, or under the direction of, a physician to provide clinicians remote patient monitoring. The target patient population is adult patients and pediatrics.

The provided text is a 510(k) premarket notification summary for the BeneVision Central Monitoring System. It details the device, its intended use, comparison to predicate devices, and various testing performed to demonstrate substantial equivalence.

However, the document does not contain information about an AI/algorithm where acceptance criteria and specific performance metrics (like sensitivity, specificity, or AUC) or information related to multi-reader multi-case (MRMC) comparative effectiveness studies would typically be found. The changes describe modifications to the software for an existing central monitoring system, primarily related to operating system compatibility, supported monitors, and the addition of a "Resting 12 Lead interpretation of previously stored data" feature.

The document discusses "Software Verification and Validation Testing" and "Bench Testing" to ensure the device meets its specifications, but these tests are for the overall system's functionality and accuracy, not for an AI component that would require the level of detail requested in the prompt.

Therefore, I cannot fulfill the request for a table of acceptance criteria and reported device performance for an AI model, sample sizes, expert qualifications, adjudication methods, MRMC studies, standalone performance, or ground truth establishment relevant to an AI/ML device, as this information is not present in the provided text.

The information that is available in the document regarding testing is general:

• Software Verification and Validation Testing: Conducted "as recommended by FDA's Guidance for Industry and FDA Staff, "Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices."" This ensures the product "works as designed" and validates its "design and performance."
• Bench Testing: Conducted "functional and system level testing to validate the performance of the devices." The results "show that the subject device meets its accuracy specification, and is substantially equivalent to the predicate device."
• Consensus Standards: The device meets relevant consensus standards, specifically mentioning IEC 60601-2-25:2011 for electrocardiographs.

The document explicitly states:

• Animal Testing: "Not applicable. Animal studies are not necessary to establish the substantial equivalence of this device."
• Clinical Data: "Not applicable. Clinical testing is not required to establish substantial equivalence to the predicate device."

Without an AI/ML component described with specific performance criteria and a study demonstrating its meeting those criteria, the detailed information requested in the prompt cannot be extracted from this document.

Ask a specific question about this device

The indications for use of the BeneVision Central Monitoring System include:

• Real time viewing of patient clinical data and alarms
• Storage and historical review of patient clinical data and alarms
• Printing of real time and historical patient data
• Configuration of local settings as well as synchronizing settings across the network to a remote device
• Transfer of patient clinical data and settings between several CentralStations

The Bene Vision Central Monitoring System is a networked patient monitoring system intended for use in a fixed location, installed in professional healthcare facilities to provide clinicians remote patient monitoring. The network connections between the various devices can be any combination of Ethernet (Wireless WIFI (WLAN), and Wireless WMTS. The BeneVision Central Monitoring System supports one or more Mindray compatible physiological monitors and will display, store, print, and transfer information received from the compatible monitors; The Bene Vision Central Monitoring System supports bi-directional configuration of the compatible monitors. No data processing is done by the BeneVision Central Monitoring System for data received from compatible monitors.

The telemetry monitoring systems are designed to acquire and monitor physiological data for ambulating patients within a defined coverage area. The BeneVision Central Monitoring System supports Telemetry Systems: TMS-6016, Telepack-608, TMS60, TM80, and TM70.

• The TMS-6016 transmitter is intended for use on Adult and Pediatric patients to monitor ECG and SpO2 physiological data.
• The Panorama Telepack-608 transmitter is intended for use on Adult patients to monitor ECG and SpO2 physiological data.
• The TMS60 transmitter is intended for use on Adult and Pediatric patients over three years old to monitor ECG, SpO2, NIBP and Resp physiological data. The physiological data can be reviewed locally on the display of the transmitter. The CentralStation will support ECG, Heart Rate, SpO2, NIBP, Resp, Pulse Rate, Arrhythmia analysis, QT monitoring, and ST Segment Analysis for the TMS60.
• The TM80/TM70 telemetry monitor is intended for use on Adult and Pediatric patients over three years old to monitor ECG, SpO2, NIBP and Resp physiological data. The physiological data can be analyzed, alarmed, stored, reviewed locally on the display of the monitor, and the CentralStation can configure and display the physiological parameters from the TM80/TM70.

The BeneVision Central Monitoring System is intended for use in professional healthcare facilities under the direct supervision of a licensed healthcare practitioner.

The BeneVision Central Monitoring System is a networked patient monitoring system intended for use in a fixed location, installed in professional healthcare facilities to provide clinicians remote patient monitoring. The network connections between the various devices can be any combination of Ethernet (Wired), Wireless WIFI (WLAN), and Wireless WMTS.

The BeneVision Central Monitoring System supports one or more Mindray compatible physiological monitors and will display, store, print, and transfer information received from the compatible monitors. The BeneVision Central Monitoring System supports bi-directional configuration of the compatible monitors. No data processing is done by the BeneVision Central Monitoring System for data received from compatible monitors or the TM80/TM70 Telemetry Monitors.

The BeneVision Central Monitoring System consists of the following components:

• 1. CentralStation
• 2. ViewStation
• 3. WorkStation
• 4. CMS Viewer
• 5. Telemetry Systems (TMS 6016, Telepak-608, TMS60, TM80, TM70)

The TMS 6016, Telepak-608, TMS60 telemetry monitoring systems operate in the 608M WMTS frequency range within a defined coverage area. All of the supported telemetry systems transmit data to the CentralStation for processing, display, and alarm.

The TM80 telemetry monitor uses the Wireless WIFI connection to transmit data to the CentralStation for display, storage, and printing.

The TM70 telemetry monitor operates in the 608M or the 1.4G WMTS frequency range within a defined coverage area, and transmits data to the CentralStation for display, storage, and printing.

The provided document is a 510(k) premarket notification for the BeneVision Central Monitoring System. It describes the device, its intended use, and comparisons to predicate devices, along with testing undertaken to demonstrate substantial equivalence. However, it does not explicitly define "acceptance criteria" in the format of a table with quantitative metrics for device performance (e.g., sensitivity, specificity, accuracy for an AI/algorithm). Instead, it explains that the modifications to the device (primarily updated host computers, increased connection/monitor support, and changes to telemetry modules and their wireless components) were assessed through functional and system-level testing to ensure they continue to meet specifications and have equivalent performance to the predicate devices.

The document is a regulatory submission for a medical device that monitors physiological data, not an AI/algorithm for diagnostic purposes, which typically involves sensitivity, specificity, or ROC curve analysis. The device's "performance" here relates to its ability to accurately acquire, display, store, print, and transfer physiological data, and its wireless connectivity capabilities, rather than a diagnostic accuracy measure that would be subject to stringent acceptance criteria for an AI model.

Therefore, many of the specific questions regarding AI/algorithm performance metrics, sample sizes for test sets, expert ground truth establishment, MRMC studies, and training set details are not directly applicable to this type of device submission as described in the provided text.

Based on the content, here's what can be extracted and inferred:

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

The document doesn't provide a table of quantitative acceptance criteria for "device performance" in the way one would expect for an AI algorithm (e.g., a specific sensitivity threshold). Instead, the acceptance criteria are implicitly tied to the device's ability to maintain its intended functions and specifications when new components or features are introduced, demonstrating "substantial equivalence" to predicate devices. The reported performance is the successful completion of various tests and compliance with relevant standards.

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

• Sample Size: Not specified quantitatively. The document refers generally to "functional and system level testing," "bench testing," and "wireless functionality testing." For wireless coexistence, it mentions testing was performed for "up to 16 wireless medical devices... within a single AP" for TM80, and "up to 14 wireless medical devices per single AP for 608 MHz and 16 wireless medical devices per single AP for 1.4 GHz" for TM70. For wireless networking stability, it mentions "Each of the TM70 roam 30 times, at least 3 TM70s roam at the same time." These are details about the test conditions (number of devices tested simultaneously or repetitively) rather than a statistical "sample size" of patient data for algorithm performance.
• Data Provenance: Not applicable in the context of physiological data for an AI model. The testing is primarily bench-top (in vitro) and system-level, concerned with internal device performance and wireless communication, not analysis of patient data by an algorithm to produce a clinical output. The device itself collects patient data, but the testing described here focuses on the device's functional integrity.

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

This is not applicable. This submission is for a central monitoring system and telemetry modules, not a device that relies on expert interpretation to establish a "ground truth" for an AI algorithm's diagnostic output. The "ground truth" for the device's performance would be engineering specifications and standards compliance, verified through bench testing and measurements.

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

Not applicable. Adjudication methods are typically used in studies involving human interpretation or clinical outcomes where there might be disagreement in ground truth labeling for AI model training or testing. This device's testing relates to hardware and software functionality and compliance with engineering standards.

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 is not an AI-assisted diagnostic device for human readers.

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

Not applicable. The "BeneVision Central Monitoring System" is a system for displaying and managing physiological data, not a standalone AI algorithm. It's a medical device system, where the listed software functions for pace detection or arrhythmia analysis are integral parts of the physiological monitoring, not separate AI algorithms in the sense of a standalone diagnostic tool. The document states "No data processing is done by the BeneVision Central Monitoring System for data received from compatible monitors." This implies the system primarily relays and displays data without independent algorithmic analysis beyond what the individual monitors (e.g., TMS60, TM70, TM80) might perform for parameters like arrhythmia or ST-segment analysis. The "software pace detection" mentioned is an update to how the hardware detects pacemakers, not an AI diagnostic algorithm.

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

The "ground truth" for this device's performance is not derived from clinical expert consensus or pathology. Instead, it is based on:

• Engineering specifications and design requirements: The device's components and system are tested against predefined performance parameters (e.g., signal accuracy, wireless range, data integrity, latency, alarm thresholds).
• Industry and regulatory standards: Compliance with consensus standards such as IEC 60601-1-2 (EMC), IEC 60601-2-27 (ECG monitoring), AAMI TIR 69 (wireless coexistence), and FCC certifications (wireless performance).
• Predicate device equivalence: Demonstrating that the modified device performs "equivalently" to previously cleared, substantially equivalent devices.

8. The sample size for the training set:

Not applicable. This is not an AI/ML device that requires a "training set" in the common sense (i.e., for a deep learning model). The software is developed using traditional software engineering processes (V&V testing).

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

Not applicable. As there's no stated AI/ML training set, the concept of establishing ground truth for it doesn't apply to this submission.

Ask a specific question about this device

The indications for use of the BeneVision Central Monitoring System include:

• · Real time viewing of patient clinical data and alarms
• · Storage and Historical review of patient clinical data and alarms
• · Printing of real time and historical patient data
• · Configuration of local settings as well as synchronizing settings across the network to a remote device
• · Transfer of patient clinical data and settings between several CentralStations

The Bene Vision Central Monitoring System is a networked patient monitoring system intended for use in a fixed location, installed in professional healthes to provide clinicians remote patient monitoring. The network connections between the various devices can be any combination of Ethernet (Wireless WIFI (WLAN), and Wireless WMTS. The Bene Vision Central Monitoring System supports one or more Mindray compatible physiological monitors and will display, store, print, and transfer information received from the compatible monitors; The Bene Vision Central Monitoring System supports bi-directional configuration of the compatible monitors. No data processing is done by the BeneVision Central Monitoring System for data received from compatible monitors.

The telemetry monitoring systems are designed to acquire and monitor physiological data for ambulating patients within a defined coverage area. The BeneVision Central Monitoring System supports Telemetry Systems: TMS-6016, Telepack-608, TMS60, and TM80.

· The TMS-6016 transmitter is intended for use on Adult and Pediatric patients to monitor ECG and SpO2 physiological data.

· The Panorama Telepack-608 transmitter is intended for use on Adult patients to monitor ECG and SpO2 physiological data.

· The TMS60 transmitter is intended for use on Adult and Pediatric patients over three years old to monitor ECG, SpO2, NIBP and Resp physiological data. The physiological data can be reviewed locally on the display of the transmitter. The CentralStation will support ECG, Heart Rate, SpO2, NIBP, Resp, Pulse Rate, Arrhythmia analysis, QT monitoring, and ST Segment Analysis for the TMS60.

· The TM80 telemetry monitor is intended for use on Adult and Pediatric patients over three years old to monitor ECG, SpO2, NIBP and Resp physiological data. The physiological data can be analyzed, alarmed, stored, reviewed locally on the display of the monitor, and the CentralStation can config and display the physiological parameters from the TM80.

The BeneVision Central Monitoring System is intended for use in professional healthcare facilities under the direct supervision of a licensed healthcare practitioner.

The BeneVision Central Monitoring System is a networked patient monitoring system intended for use in a fixed location, installed in professional healthcare facilities to provide clinicians remote patient monitoring. The network connections between the various devices can be any combination of Ethernet (Wired), Wireless WIFI (WLAN), and Wireless WMTS.

The BeneVision Central Monitoring System supports one or more Mindray compatible physiological monitors and will display, store, print, and transfer information received from the compatible monitors; The BeneVision Central Monitoring System supports bi-directional configuration of the compatible monitors. No data processing is done by the BeneVision Central Monitoring System for data received from compatible monitors.

The BeneVision Central Monitoring System consists of the following components:

• 1. CentralStation
• 2. ViewStation
• 3. WorkStation
• 4. CMSViewer
• 5. Telemetry Systems (TMS 6016. Telepak-608. TMS60. TM80)

Here's an analysis of the acceptance criteria and study information provided, structured as requested.

Acceptance Criteria and Device Performance

The provided document describes modifications to an existing device (BeneVision Central Monitoring System) and aims to demonstrate substantial equivalence to a predicate device (K162607). The document presents a comparison of technological characteristics as the primary proof of meeting acceptance criteria, rather than explicit quantitative acceptance metrics for performance. The "Performance Data" section details types of testing conducted to ensure the device performs as designed and meets relevant standards.

Table of Acceptance Criteria and Reported Device Performance

Since explicit quantitative acceptance criteria with specific threshold values for "device performance" in terms of accuracy, sensitivity, specificity, etc., are not directly stated in the tables for the subject device (as would be common for diagnostic AI), the "Acceptance Criteria" column will reflect the stated functionalities or characteristics of the subject device, and "Reported Device Performance" will indicate if the device meets these in comparison to the predicate. The overall "acceptance criterion" is essentially demonstrating that the changes do not raise new questions of safety and effectiveness and that the device continues to meet relevant standards.

Study Information

The document describes software verification and validation, electromagnetic compatibility, electrical safety, and bench testing to demonstrate substantial equivalence. It is important to note that this is a 510(k) Premarket Notification for a modified device, not a de novo submission or a claim of new clinical efficacy. Therefore, the "studies" outlined are primarily focused on engineering and performance verification of the changes.

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

   • The document does not specify sample sizes for test sets in terms of patient data or clinical cases. The testing appears to be focused on functional and system-level verification, as well as conformance to technical standards.
   • Data provenance (e.g., country of origin, retrospective/prospective) is not provided as the focus is on engineering verification.

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

   • This information is not applicable or provided. The document focuses on demonstrating substantial equivalence through technical comparisons and compliance with relevant standards, rather than establishing a clinical "ground truth" derived from expert interpretation of medical images or patient data in a comparative clinical study.

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

   • This information is not applicable or provided. Adjudication methods are typically used in clinical studies involving multiple readers and ground truth evaluation, which is not the focus of this 510(k) summary.

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 (BeneVision Central Monitoring System) is a patient monitoring system which, based on the description, primarily displays, stores, prints, and transfers physiological data and alarms. While it performs some analysis (e.g., arrhythmia, ST segment), it's not described as an AI-powered diagnostic tool requiring a human-in-the-loop performance study in the way an AI-CADx system would. The changes described are enhancements to the monitoring system's capabilities and compliance with updated standards.

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

   • The document implies that elements like the "Mindray ECG algorithm modifications" and "Intelligent arrhythmia alarm" have undergone verification to ensure they perform according to specifications (e.g., "enhanced performance," "same methods employed by the Central Station"). However, a formal "standalone performance study" with typical metrics like sensitivity, specificity, and F1 score against a reference standard on a clinical dataset is not explicitly detailed or quantified in the provided text. The verification likely involved testing against known waveforms and simulated conditions to confirm algorithm accuracy according to engineering specifications.

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

   • Given the nature of the device (a core patient monitoring system), the "ground truth" for its functional performance would typically involve:
     • Reference signals/simulators: For verifying ECG, SpO2, NIBP, RESP parameters against known inputs.
     • Standardized test conditions: For EMC, electrical safety, and alarm system performance.
     • Software testing (unit, integration, system): Using expected outputs for given inputs to verify logic and calculations.
     • Predicate device comparison: The predicate device itself acts as a reference for expected performance in many aspects of substantial equivalence.
   • Specific details about ground truth for individual algorithms (e.g., how the "enhanced performance" of the ECG algorithm was measured against a reference standard) are not provided beyond the general statement of "functional and system level testing."

7. The sample size for the training set:

   • The document does not mention a training set, as these are engineering changes and updates to a non-AI patient monitoring system, not a de novo AI/ML algorithm requiring a distinct training phase.

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

   • This section is not applicable, as no training set is mentioned.

Ask a specific question about this device

The CMS-2000 Central Monitoring System provides centralized monitoring and critical care management for patients monitored by bedside monitors. From the CMS-2000, clinicians can gain access to patient information for patients on the Network. The CMS-2000 displays waveforms, parameters and alarm status of bedside monitors for up to 32 patients on a single screen or up to 64 patients using two screens.

The CMS-2000 Central Monitoring System is a software production, which runs on a PC platform running under the Microsoft Windows XP or Windows 7 operating system. Through specified protocol, one CMS-2000 can connect with multi-monitors from ADVANCED INSTRUMENTATIONS to collect patients' information and monitoring data such as physiological waveforms, physiological parameters and alarms. The CMS-2000 can also send bidirectional control instruction to bedside monitors to change patients' information, alarm limits and conduct NIBP measurements. The bedside Patient Physiological Monitors have been cleared by the FDA under K123048 separately. The monitoring information collected by the CMS-2000 can be saved and printed. At the same time, the old records can be searched conveniently and quickly.

The provided text describes a 510(k) premarket notification for the "CMS-2000 Central Monitoring System." This document primarily focuses on establishing substantial equivalence to a legally marketed predicate device (EDAN Central Monitoring System, model MFM-CMS, K120727).

Therefore, the provided document DOES NOT contain the information needed to answer many of the questions regarding acceptance criteria, study design, and performance for a device that relies on novel AI/ML capabilities.

The CMS-2000 is described as a software product that collects and displays physiological data from bedside monitors. It is a Central Monitoring System, which implies it aggregates and visualizes data rather than performing complex analytical or diagnostic functions that would typically require extensive clinical validation studies with ground truth. The submission explicitly states "Clinical testing is not required." and emphasizes "The subject device has similar technology characteristics and has the same intended use, same design principle and same functionality as the predicate device. There are no differences between the devices." This means the FDA cleared the device based on its similarity to a previously cleared product, not on novel performance claims that would necessitate rigorous testing against specific acceptance criteria.

However, based on the information provided, here's what can be inferred or directly stated:

Acceptance Criteria and Device Performance (Limited Information based on the provided text):

As this submission is for a device establishing substantial equivalence to a predicate, the "acceptance criteria" are implicitly met by demonstrating comparable technical characteristics and intended use. There are no performance metrics provided in the format of a typical AI/ML device study.

Detailed Study Information (Based on the provided text, many fields are "Not applicable" or "Not provided" as it's a 510(k) based on substantial equivalence, not a de novo AI/ML device):

1. Sample sizes used for the test set and the data provenance:

   • Sample Size: Not applicable/Not provided. The document states "Clinical testing is not required." The evaluation was based on comparison to a predicate device's specifications, not a clinical test set.
   • Data Provenance: Not applicable. No patient data or clinical test set was described.

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

   • Not applicable. No ground truth was established from experts for a test set, as no clinical testing was deemed necessary for this type of device and submission pathway.

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

   • Not applicable. No test set requiring expert adjudication was used.

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:

   • Not applicable. This device is a central monitoring system for displaying already acquired physiological data and alarms from bedside monitors. It is not an AI/ML-driven diagnostic or interpretative tool designed to assist human readers or improve their performance. The submission explicitly highlights that its functionality and intended use are identical to the predicate device.

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

   • Not applicable. The device's "performance" is based on its ability to accurately reflect and transmit data from connected bedside monitors as per its technical specifications, which are compared to the predicate. It does not have a standalone "algorithm" with a specific output requiring a performance study in this context.

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

   • Not applicable. The "ground truth" for this 510(k) submission is effectively the technical specifications and performance claims of the legally marketed predicate device. The CMS-2000 demonstrated its functionality matched the predicate's without requiring independent clinical ground truth.

7. The sample size for the training set:

   • Not applicable. This device is described as a "software production" running on a PC, connecting to monitors. It is not presented as an AI/ML device that requires a training set in the contemporary sense of deep learning or machine learning models. Its functionality is explicitly stated as being "the same" as the predicate based on fixed design principles.

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

   • Not applicable. As no training set for an AI/ML model was described, no ground truth collection for such a set was needed.

Ask a specific question about this device

The Maternal Fetal Monitoring - Central Nurse System (hereinafter called "MFM-CNS") is a clinical data managing software application and is indicated for antepartum and intrapartum monitoring of pregnant women in a healthcare setting.

MFM-CNS is intended to manage perinatal monitoring data acquired from bedside monitors or manual input for viewing at the central nursing station. The system also produces an electronic medical record.

MFM-CNS has display fields for the following obstetric data:

• patient demographics
• provider notes
• fetal heart rate (FHR)
• uterine activity
• fetal movement
• maternal heart rate
• SpO2
• non-invasive blood pressure (NIBP)
• respiratory rate
• temperature
• pulse rate

MFM-CNS Lite (hereinafter called "Lite") is a clinical data managing software application and is indicated for antepartum monitoring of pregnant women in a healthcare setting.

Lite is intended to manage antepartum-monitoring data acquired from bedside monitors and produce electronic medical records.

Lite has display fields for the following obstetric data:

• patient demographics
• provider notes
• fetal heart rate (FHR)
• uterine activity
• fetal movement

The MFM-CNS v3.91 and MFM-CNS Lite v1.1 are clinical data managing software applications. Both applications manage clinical data of fetal monitoring and uterine activity, and the MFM-CNS v3.91 additional monitors maternal vital signs. Data are automatically acquired from bedside monitors, for the purpose of collecting, processing and saving the patient and/or clinical data that is normally provided on record papers and/or separate bedside monitors. They provide electronic medical records and operate with off-the-shelf software and hardware.

The MFM-CNS v3.91 and MFM-CNS Lite v1.1 are intended to be used in hospital clinical areas such as monitor units, delivery room, etc. They are intended to be operated by or under guidance of qualified healthcare professionals, not intended for home healthcare environment. During monitoring, the user should check the results on the bedside monitor in person, even though they could observe the results on the MFM-CNS v3.91 and MFM-CNS Lite v1.1 system interface. The user cannot only depend on the MFM-CNS v3.91 and MFM-CNS Lite v1.1 system to obtain monitoring data, because whether the data provided by the system are accurate depends on the stability of the operating system, the performance of PC station and the network.

The provided text is a 510(k) summary for a medical device (Edan Instruments, Inc.'s Central Monitoring System MFM-CNS Lite v1.1 and MFM-CNS v3.91). This type of submission focuses on demonstrating substantial equivalence to a predicate device rather than presenting a standalone study with defined acceptance criteria and performance metrics for the new device in the same way one might for a novel diagnostic algorithm.

Therefore, the document does not contain a table of acceptance criteria and reported device performance for the subject device, nor does it detail a clinical study proving the device meets specific performance criteria. Instead, it relies on demonstrating that the new devices (MFM-CNS v3.91 and MFM-CNS Lite v1.1) are substantially equivalent to a previously cleared predicate device (EDAN Instrument, Inc. Central Monitoring System, model MFM-CNS v3.82, K143695).

However, I can extract information related to the performance data provided to support the substantial equivalence claim.

Here's a breakdown of the available information based on your request:

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 for the subject device in clinical terms (e.g., sensitivity, specificity, accuracy). Instead, it states that "the non-clinical performance testing showed that the subject devices are as safe and as effective as the predicate device."

The "performance" described is in the context of software verification and validation, and compliance with standards.

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

This information is not provided in the document, as it focuses on software verification and validation, not a clinical test set. The device is a "clinical data managing software application," meaning its primary function is to display and manage data from other monitors, not to make independent diagnoses or measurements.

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

This information is not provided. The "ground truth" for software validation would typically be established by comparing the software's output to the expected output according to specifications and functional requirements, rather than expert interpretation of clinical cases.

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

This information is not provided.

5. If a multi-reader multi-case (MRMC) comparative effectiveness study was done, if so, what was the effect size of how much human readers improve with AI vs without AI assistance

An MRMC comparative effectiveness study was not done. The device is a data management system, not an AI-assisted diagnostic tool for human readers.

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

A standalone human-in-the-loop performance study was not done. The performance described is related to the software's functionality and safety, not its diagnostic accuracy in a clinical context. The document explicitly states: "During monitoring, the user should check the results on the bedside monitor in person, even though they could observe the results on the MFM-CNS v3.91 and MFM-CNS Lite v1.1 system interface. The user cannot only depend on the MFM-CNS v3.91 and MFM-CNS Lite v1.1 system to obtain monitoring data, because whether the data provided by the system are accurate depends on the stability of the operating system, the performance of PC station and the network." This indicates it's designed as an information display and management tool, not an independent diagnostic algorithm.

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

The concept of "ground truth" in the clinical sense (e.g., pathology, outcomes data) is not applicable to the performance data presented. The "ground truth" for the software validation would be its adherence to established software requirements and industry standards.

8. The sample size for the training set

This information is not applicable/not provided. The device is a software application for data management; it does not explicitly mention machine learning or AI models that require a training set in the conventional sense. The "training" here refers to software development and testing cycles rather than model training.

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

This information is not applicable/not provided for the reasons stated above.

Ask a specific question about this device

Central Monitoring System Software is intended to conduct centralized monitoring of adult, pediatrics and neonatal patient's vital sign information from compatible bedside monitors. The software collects, stores, displays and alarms the information provided on the bedside monitoring parameters include Electrocardiogram(ECG), Heart Rate(HR), Respiration(RESP), Pulse Oxygen Saturation(SpO2), Pulse Rate(PR), Non-invasive Blood Pressure (NIBP), Invasive Blood Pressure(IBP), Impedance Cardiograph(ICG), TEMP(Temperature), Carbon dioxide (CO2), Anesthetic Gas (AG), Fetal Heart Rate (FHR), Uterine contraction (TOCO) and Fetal Movement (FM) etc. It is intended to be used in the hospital or medical institutions, and it is not intended for home use.

M6000C central monitoring system software, the risk management object, can central monitor significant vital sign parameters of multi-patients, including ECG/HR, RESP, SpO2, PULSE, NIBP, IBP, ICG, TEMP, CO2, AG, FHR, TOCO and FM. It is connected by network with bedside units and receives data from bedside units. Then, the data are displayed on the screen or recorded or printed as per needs. When the monitored data exceed a set value, the central monitoring system software will start alarm system and gives out alarm to remind doctors and nurses for attention.

Here's a breakdown of the acceptance criteria and study information based on the provided text:

Acceptance Criteria and Reported Device Performance

The document does not explicitly state quantitative acceptance criteria or a direct comparison of the device's performance against such criteria. Instead, it focuses on non-clinical testing to verify design specifications and compliance with voluntary standards. The "Performance testing" mentioned is general and doesn't provide specific numerical results or target metrics.

Detailed Study Information:

1. A table of acceptance criteria and the reported device performance:
   (See table above)

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

   • Sample Size for Test Set: Not specified. The document mentions "Performance testing" but does not detail the number of test cases, patient data, or scenarios used in these tests.
   • Data Provenance: Not specified. It's unclear if the tests used simulated data, existing patient data, or newly acquired data. The country of origin is also not mentioned.

3. Number of experts used to establish the ground truth for the test set and the qualifications of those experts:
   Not applicable. The document describes non-clinical performance and software verification testing, which typically do not involve expert-established ground truth in the same way clinical studies or diagnostic AI algorithms do. The "performance testing" seems to focus on functional verification rather than accuracy against a clinical reference standard.

4. Adjudication method for the test set:
   Not applicable, as no external experts or adjudication process against a ground truth is described for the functional and performance testing.

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. The submission explicitly states: "No clinical study is included in this submission." Therefore, no MRMC study or AI assistance evaluation was performed.

6. If a standalone (i.e., algorithm only without human-in-the-loop performance) was done:
   Yes, in a sense. The described "Performance testing" and "Software verification and validation testing" are evaluations of the device (software) itself, without direct human-in-the-loop involvement in the performance assessment against a clinical outcome. These tests confirm the software's functionality, compatibility, and data processing capabilities, rather than its diagnostic or interpretative accuracy in a clinical context.

7. The type of ground truth used:
   Not explicitly stated as "ground truth" in the diagnostic sense. For the functional and performance tests, the "ground truth" would be the expected behavior or output of the software and system based on its design specifications and standard requirements. For example, for data latency, the ground truth would be the defined acceptable latency rate. For compatibility, it would be successful communication with specified bedside monitors.

8. The sample size for the training set:
   Not applicable. This device is a Central Monitoring System, which collects, stores, displays, and alarms vital sign information. It is not an AI/ML algorithm that is "trained" on a dataset in the typical sense. It performs rule-based monitoring and alarm generation.

9. How the ground truth for the training set was established:
   Not applicable, as there is no training set for this type of monitoring system.

Ask a specific question about this device

The indications for use of the BeneVision Central Monitoring System include:

• Real time viewing of patient clinical data and alarms
• Storage and Historical review of patient clinical data and alarms
• Printing of real time and historical patient data
• Configuration of local settings as well as synchronizing settings across the network to a remote device
• Transfer of patient clinical data and settings between several CentralStations

The Bene Vision Central Monitoring System is a networked patient monitoring system intended for use in a fixed location, installed in professional healthes to provide clinicians remote patient monitoring. The network connections between the various devices can be any combination of Ethernet (Wireless WIFI (WLAN), and Wireless WMTS. The Bene Vision Central Monitoring System supports one or more Mindray compatible physiological monitors and will display, store, print, and transfer information received from the compatible monitors; The Bene Vision Central Monitoring System supports bi-directional configuration of the compatible monitors. No data processing is done by the BeneVision Central Monitoring System for data received from compatible monitors.

The telemetry monitoring systems are designed to acquire and monitor physiological data for ambulating patients within a defined coverage area. The BeneVision Central Monitoring System supports Telemetry Systems: TMS-6016, Telepack-608, TMS60, and TM80.

• The TMS-6016 transmitter is intended for use on Adult and Pediatric patients to monitor ECG and SpO2 physiological data.
• The Panorama Telepack-608 transmitter is intended for use on Adult patients to monitor ECG and SpO2 physiological data.
• The TMS60 transmitter is intended for use on Adult and Pediatric patients over three years old to monitor ECG, SpO2, NIBP and Resp physiological data. The physiological data can be reviewed locally on the display of the transmitter. The CentralStation will support ECG, Heart Rate, SpO2, NIBP, Resp, Pulse Rate, Arrhythmia analysis, QT monitoring, and ST Segment Analysis for the TMS60.
• The TM80 telemetry monitor is intended for use on Adult and Pediatric patients over three years old to monitor ECG, SpO2, NIBP and Resp physiological data. The physiological data can be reviewed locally on the display of the monitor. The CentralStation will support ECG, Heart Rate, SpO2, NIBP, Resp, Pulse Rate, Arrhythmia analysis, QT monitoring, and ST Segment Analysis for the TM80.

The BeneVision Central Monitoring System is intended for use in professional healthcare facilities under the direct supervision of a licensed healthcare practitioner.

The BeneVision Central Monitoring System is a networked patient monitoring system intended for use in a fixed location, installed in professional healthcare facilities to provide clinicians remote patient monitoring. The network connections between the various devices can be any combination of Ethernet (Wired), Wireless WIFI (WLAN), and Wireless WMTS.

The BeneVision Central Monitoring System supports one or more Mindray compatible physiological monitors and will display, store, print, and transfer information received from the compatible monitors; The BeneVision Central Monitoring System supports bi-directional configuration of the compatible monitors. No data processing is done by the BeneVision Central Monitoring System for data received from compatible monitors.

The BeneVision Central Monitoring System consists of the following components:

• 1. CentralStation
• 2. ViewStation
• 3. WorkStation
• 4. CMSViewer
• 5. Telemetry Systems (TMS 6016, Telepak-608, TMS60,TM80)

The TMS 6016, Telepak-608, TMS60 telemetry monitoring systems operate in the 608M WMTS frequency range within a defined coverage area. All of the supported telemetry systems transmit data to the CentralStation for processing, display, and alarm.

The TM80 telemetry monitor uses the Wireless WIFI connection to transmit data to the CentralStation for processing, display, and alarm.

This document is a 510(k) Pre-market Notification for the BeneVision Central Monitoring System. It's a submission to the FDA to demonstrate that the new device is substantially equivalent to a legally marketed predicate device. This type of document generally focuses on comparing the new device's features and performance to an existing one, rather than presenting a standalone study showing general device performance against predefined acceptance criteria in the way a clinical trial for a new drug or diagnostic might.

Here's an analysis of the provided text in relation to your request:

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

The document does not explicitly present a table of acceptance criteria with corresponding device performance metrics in the format you requested. Instead, it relies on comparison to a predicate device and adherence to recognized standards. The "Performance Data" section states that Mindray "conducted functional and system level testing on the subject device. The testing provided an evaluation of the performance of the device relevant to each of the differences between the subject device and the predicate device. The functional and system level testing showed that the devices continue to meet specifications and the performance of the device is equivalent to the predicate."

This implies that the "acceptance criteria" are essentially to meet the performance specifications of the predicate device and relevant consensus standards. The performance is reported as meeting these specifications and being equivalent.

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

The document does not specify the sample size used for any test sets, nor does it provide details on data provenance (country of origin, retrospective/prospective). The testing mentioned is "functional and system level testing," which typically involves engineering and verification testing rather than testing on patient data in a clinical setting.

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)

This information is not provided. Given the nature of the device (a central monitoring system that displays, stores, and transfers data from other physiological monitors, rather than performing primary diagnostic analysis), the "ground truth" would likely be established through technical validation against known input signals or simulated data according to engineering specifications, rather than expert clinical consensus on actual patient cases.

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

Not applicable/not provided. Adjudication methods are typically relevant for studies involving human interpretation or labeling of complex data (e.g., medical images). The testing described appears to be technical validation.

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

An MRMC study was not conducted. This device is a central monitoring system, not an AI-powered diagnostic tool for interpretation by human readers. It primarily displays, stores, and transfers data. There is no mention of AI assistance in the document.

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

This is not applicable in the sense of a diagnostic algorithm. The "algorithm" here refers to the system's ability to accurately process and display physiological data. The performance section describes "functional and system level testing" and "Wireless functionality testing," which evaluate the system's technical operation in a standalone manner (i.e., the system's ability to perform its stated functions without direct human intervention in the data processing). The device description explicitly states: "No data processing is done by the BeneVision Central Monitoring System for data received from compatible monitors." This suggests it acts as a relay and display, not an analytical engine for raw data interpretation.

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

The document doesn't explicitly state the type of "ground truth." However, for a device like a central monitoring system, the ground truth for testing would primarily involve:

• Known input signals: Generating physiological signals (ECG, SpO2, NIBP, Respiration) with known values and waveforms to verify accurate reception, display, and storage by the BeneVision system.
• System specifications: Verifying that the system meets its own design specifications for data transfer, alarm functionality, display accuracy, and configuration synchronization.
• Compliance with standards: Demonstrating adherence to relevant consensus standards (e.g., AAMI/ANSI ES60601-1, IEC 60601-1-2, etc.) which often involve specific test methodologies and criteria.

8. The sample size for the training set

The document does not describe a "training set." This type of system (a central monitoring system) does not typically involve machine learning or AI models that require training sets in the conventional sense. Its functionality is based on established engineering principles for data acquisition, transfer, and display.

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

Not applicable, as there is no mention of a training set.

Summary of the study and acceptance criteria based on the provided document:

The submission for the BeneVision Central Monitoring System is a 510(k) Pre-market Notification, which primarily aims to demonstrate substantial equivalence to a predicate device (Hypervisor IX Monitoring System, K150632).

Acceptance Criteria (Implied, not explicitly stated numerically):

The implied acceptance criteria are that the BeneVision Central Monitoring System:

• Performs its stated functions (real-time viewing, storage, historical review, printing, configuration synchronization, data transfer) equivalently to or better than the predicate device.
• Meets its own design specifications for functional and system level performance.
• Complies with relevant national and international consensus standards for medical electrical equipment and patient monitoring.
• The differences from the predicate (e.g., added display sizes, increased monitor capacity, added TM80 telemetry support with NIBP/Resp/WiFi/6-lead ECG, increased data review storage) do not raise new questions of safety or effectiveness.

Reported Device Performance:

The document states:

• "Mindray conducted functional and system level testing on the subject device. The testing provided an evaluation of the performance of the device relevant to each of the differences between the subject device and the predicate device. The functional and system level testing showed that the devices continue to meet specifications and the performance of the device is equivalent to the predicate."
• "Mindray conducted Wireless functionality testing to ensure the performance of the BeneVision Central Monitoring System meets wireless specifications and is equivalent to the predicate device."
• "Mindray has conducted testing to ensure the subject device meets relevant consensus standards." (A list of specific standards is provided).

In essence, the "study" described is a series of engineering verification and validation tests (functional, system level, wireless functionality) performed by the manufacturer to demonstrate that the device meets its own specifications and relevant standards, and that its performance is equivalent to the legally marketed predicate device. It is not a clinical trial or a study involving human-in-the-loop performance measurement or AI comparative effectiveness.

Ask a specific question about this device

Central Monitoring System Software is intended to conduct centralized antepartum and intrapartum monitoring of pregnant women's vital sign information from compatible bedside monitors. The software collects, stores, displays and alarms the information provided on the bedside monitor. The monitoring parameters include Electrocardiogram(ECG), Heart Rate(HR), Respiration(RESP), Pulse Oxygen Saturation(SpO2), Pulse Rate(PR), Non-invasive Blood Pressure (NIBP), Invasive Blood Pressure(IBP), Impedance Cardiograph(ICG), TEMP(Temperature), Carbon dioxide (CO2), Anesthetic Gas (AG), Fetal Heart Rate (FHR), Uterine contraction (TOCO) and Fetal Movement (FM). It is intended to be used in the hospital or medical institutions, and it is not intended for home use.

The Central Monitoring System Software-only device that is intended to conduct centralized antepartum and intrapartum monitoring of pregnant women's vital sign information from compatible bedside monitors connected by a wired or wireless network. The Central Monitoring System consists of two models: M6000C and Truscope CNS. Both models provide functions including collecting, storing, displaying, and alarming (e.g. when the monitored data exceeds a set value, the device will alarm to alert medical personnel) the information which is received from the bedside monitor(s). Multiple patients can be monitored simultaneously. Parameters monitored include ECG/HR, RESP, SpO2, PULSE, NIBP, IBP, ICG, TEMP, CO2, AG, FHR, TOCO and FM.

The provided document does not contain details about specific acceptance criteria related to a numerical performance target (e.g., sensitivity, specificity, accuracy) for the Central Monitoring System Software, nor does it describe a study that proves the device meets such criteria in terms of clinical performance.

Instead, the document focuses on non-clinical testing to demonstrate:

• Compatibility with various bedside monitors.
• Acceptable data latency rates for the clinical environment.
• Software verification and validation testing, following FDA guidance.
• Compliance with voluntary standards (IEC 62366:2007 and IEC 62304:2006).

Therefore, I cannot populate a table of acceptance criteria and reported device performance directly from this text in the way that would typically be done for a diagnostic AI device requiring performance metrics. The information needed for almost all of your specific questions (sample size, data provenance, number of experts, etc.) is also not present because the study described is not a clinical performance study with defined ground truth.

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

1. Table of acceptance criteria and the reported device performance

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

• Sample Size: Not specified. The performance testing mentioned is non-clinical and focuses on system functionality and compatibility rather than clinical data performance.
• Data Provenance: Not applicable, as there is no mention of clinical data or patient-specific test sets.

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

• Number of Experts: Not applicable.
• Qualifications: Not applicable.

4. Adjudication method for the test set

• Adjudication Method: Not applicable.

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, an MRMC comparative effectiveness study was not done. The device is a "Central Monitoring System Software" for displaying and alarming vital sign data, not an AI diagnostic tool designed to assist human readers in interpretation.

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

• The described tests are for the standalone functionality of the software system (e.g., collecting, storing, displaying, alarming data) and its compatibility, not for an "algorithm only" in the sense of an AI diagnostic prediction. Its function is to operate independently of real-time human interpretation, presenting data from other devices.

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

• Type of Ground Truth: For the non-clinical tests, the "ground truth" would be the expected functional behavior and performance defined by the design specifications and relevant standards. For example, for data latency, the ground truth would be the maximum acceptable delay. For compatibility, it would be successful data exchange with target bedside monitors. No clinical ground truth (e.g., pathology, expert consensus on a diagnosis) is relevant or mentioned.

8. The sample size for the training set

• Sample Size: Not applicable. There is no mention of a machine learning or AI model being trained, so no training set is described.

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

• How Ground Truth Established: Not applicable, as there is no training set described.

In summary: This 510(k) summary focuses on the functional and technical performance of software that collects, displays, and alarms vital sign data from other monitors. It is not an AI diagnostic device that requires clinical performance metrics like sensitivity or specificity derived from interpreting medical images or complex data, and therefore, the types of studies and ground truth requested in questions 2-9 are not applicable to the information provided.

Ask a specific question about this device