Search Results

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

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

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.

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

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

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

The Maternal Fetal Monitoring – Central Nurse System (hereinafter called "MFM-CNS") is a clinical data managing software application. Its function is to manage clinical data of fetal heart and maternal vital signs (CTG - Cardiotocography), which is 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. It provides electronic medical records and operates with off-the-shelf software and hardware.

The MFM-CNS is intended to be used in hospital clinical areas such as monitor units, delivery room, etc. It is 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 system interface. The user cannot only depend on the MFM-CNS system to obtain monitoring data, because whether the data provided by the system is accurate depends on the stability of the operating system, the performance of PC station and the network. Although the software has its independent alarm system, the alarm information provided by the system is just for reference.

The provided document is a 510(k) premarket notification for the Edan Instruments Inc. "Central Monitoring System" (MFM-CNS). It outlines the device's description, indications for use, comparison to predicate devices, and non-clinical testing for safety and effectiveness.

However, the document explicitly states:

• "Clinical test: Clinical testing is not required." (Page 8)
• The non-clinical tests relate to software validation, risk analysis, usability analysis, and software life cycle management, not direct performance criteria against a ground truth.

Therefore,Based on the provided document, the following information regarding acceptance criteria and a study proving the device meets them cannot be provided:

1. A table of acceptance criteria and the reported device performance: The document states no clinical testing was required, and the non-clinical tests focused on software quality assurance (validation, risk, usability, lifecycle management) rather than performance metrics against specific acceptance criteria.
2. Sample size used for the test set and the data provenance: No clinical test set was used.
3. Number of experts used to establish the ground truth for the test set and the qualifications of those experts: Not applicable as there was no clinical test set.
4. Adjudication method for the test set: 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: Not applicable. This device is described as a "clinical data managing software application" for viewing perinatal monitoring data, not an AI-assisted diagnostic tool that would enhance human reader performance.
6. If a standalone (i.e., algorithm only without human-in-the-loop performance) was done: Not applicable, as there's no indication of an algorithm performing diagnoses or analyses independently that would require standalone performance testing against a ground truth.
7. The type of ground truth used (expert consensus, pathology, outcomes data, etc.): No ground truth was established or used for performance evaluation since no clinical testing was deemed necessary.
8. The sample size for the training set: Not applicable, as there's no mention of Machine Learning/AI training in the document.
9. How the ground truth for the training set was established: Not applicable.

Summary from the document:

The device, MFM-CNS, is a "clinical data managing software application." Its purpose is to facilitate the management, viewing, and electronic record-keeping of perinatal monitoring data (FHR, uterine activity, maternal vital signs, etc.) acquired from bedside monitors or manual input. The substantial equivalence determination was based on non-clinical software quality assurance measures and a comparison to predicate devices, noting that the differences do not affect safety and effectiveness.

Ask a specific question about this device

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

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

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

• patient demographics
• provider notes
• FHR
• uterine activity (via tocodynamometry or IUP)
• maternal heart rate
• SpO2
• NIBP
• respiratory rate
• temperature
• pulse rate

MFM-CNS is a software production who runs on PC station with Microsoft Windows XP operating system. MFM-CNS by connecting one central station with some bedside fetal / maternal monitors, carries out centralized monitoring management for many beds. It can monitor a pregnant woman during the whole parturition process, and all the monitoring information can be recorded, saved and printed, and alarm when the parameter exceed the user defined limit and poor signal quality. At the same time, the old records can be searched conveniently and quickly.

Device features:

• Connect maximum 32 bedside fetal / maternal monitors with Ethernet.
• Display FHR, UA, Maternal HR, PR, SpO2, NIBP, RR and TEMP numerics on the screen.
• The screen displays all the monitors simultaneously, or displays one monitor in full screen.
• 24-hour CTG, 1440-group Maternal Vital Sign data, 200-group NIBP data review.
• Print CTG report, Maternal Vital Sign list, NIBP list on the paper
• Audible & visible alarm when FHR or maternal vital sign exceeds the user defined limit or poor signal quality.
• Patient information, CTG, Maternal Vital Sign list and NIBP list can be saved, and burned into CDs for backup.
• Support user accessing control.

This 510(k) submission for the Edan Instruments, Inc. Central Monitoring System (MFM-CNS) does not contain detailed information about specific acceptance criteria and a study proving the device meets those criteria in the way a typical diagnostic or AI/ML device submission would. This is because the MFM-CNS is a "perinatal monitoring system and accessories," primarily a data management and display software for existing medical devices (bedside fetal/maternal monitors), not a device performing independent diagnostic analysis or making clinical decisions. Its "performance" is more related to its functionality, reliability, and accuracy in data handling and display, rather than diagnostic accuracy metrics like sensitivity or specificity.

Therefore, many of the requested categories (e.g., sample size for test set, number of experts for ground truth, MRMC study, standalone performance, ground truth type for training set) are not applicable or not provided in the document for this type of device.

Here's an analysis of the information provided, addressing the questions where possible:

Acceptance Criteria and Device Performance Study for Edan Instruments, Inc. Central Monitoring System (MFM-CNS)

1. Table of Acceptance Criteria and Reported Device Performance

The provided 510(k) summary does not outline specific numerical acceptance criteria (e.g., "accuracy must be >X%") or report quantitative device performance metrics (e.g., sensitivity, specificity, AUC). Instead, the "acceptance criteria" for this type of device are implicitly tied to its stated functionality, safety, and substantial equivalence to a predicate device.

The "reported device performance" is essentially a confirmation that the device functions as intended and meets safety and performance requirements through various testing methods.

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

The document states "Verification and validation testing was done on MFM-CNS." However, it does not specify the sample size used for the test set (e.g., number of patient records, number of monitoring sessions).

Given the nature of the device as a data management system, the "test set" would likely constitute a series of simulated or real-world data streams from connected monitors, and various user interactions. The document does not provide details on the data provenance (e.g., country of origin, retrospective or prospective).

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. As a data management system, the "ground truth" for its performance would primarily involve confirming the accurate display and storage of data as received from the connected monitors, not an independent clinical diagnosis requiring expert consensus. Human experts may have been involved in verifying the UI/UX and data integrity, but their number and qualifications are not listed.

4. Adjudication Method for the Test Set

This information is not provided and is generally not applicable in the context of testing a data management and display system.

5. If a Multi Reader Multi Case (MRMC) Comparative Effectiveness Study was done, If so, what was the effect size of how much human readers improve with AI vs without AI assistance

No MRMC study was conducted or reported. This device is not an AI-assisted diagnostic tool; it is a display and management system for perinatal monitoring data. Therefore, the concept of "human readers improving with AI vs without AI assistance" does not apply.

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

This information is not explicitly stated in the provided text. However, as it is a "Central Monitoring System" that displays data acquired from other devices and allows for manual input and user-defined limits, its primary function inherently involves a "human-in-the-loop." It is a software application designed to provide information to clinicians, not to make autonomous diagnostic decisions. Its validation would focus on the accuracy of data acquisition, display, archiving, and alarming functions, which are analogous to "standalone" performance of the software functions themselves.

7. The Type of Ground Truth Used

For a data management and display system like the MFM-CNS, the "ground truth" would be:

• Accurate input data: Ensuring the data received from bedside monitors is correctly interpreted and displayed.
• Functional correctness: Verification that display fields show the correct information, alarms trigger appropriately based on predefined limits, data is stored and retrieved accurately, and printing functions work as expected.
• User Interface/Experience (UI/UX) adherence: Conformance to design specifications for how information is presented.

It is not expert consensus, pathology, or outcomes data in a diagnostic sense, but rather a verification of the system's faithful handling and presentation of information.

8. The Sample Size for the Training Set

This information is not provided and is typically not relevant for a deterministic software application like this, which does not employ machine learning or AI models that require specific training data sets.

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

This information is not provided and is generally not applicable as there's no indication of a "training set" in the context of an AI/ML algorithm. If the term "training set" refers to internal development and testing data, the "ground truth" would have been established through a combination of simulated data, test cases with known outputs, and direct comparison to the behavior of the predicate device or established specifications.

Ask a specific question about this device