(267 days)
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
| Acceptance Criteria Category | Specific Criteria (as implied by document) | Reported Device Performance (as summarized by document) |
|---|---|---|
| Software Functionality | Compliance with design specifications. | Met all design specifications. |
| Compatibility | Compatible with various bedside monitors. | Performance testing confirmed compatibility. |
| Data Latency | Acceptable data latency rates for the clinical environment. | Performance testing confirmed acceptable data latency rates. |
| Software Validation | Adherence to FDA guidance for software contained in medical devices. | Software verification and validation testing completed as recommended. |
| Standards Compliance | Compliance with IEC 62366:2007 (Usability Engineering), IEC 62304:2006 (Software Life Cycle Process). | Tests demonstrated compliance with these standards. |
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.
§ 884.2740 Perinatal monitoring system and accessories.
(a)
Identification. A perinatal monitoring system is a device used to show graphically the relationship between maternal labor and the fetal heart rate by means of combining and coordinating uterine contraction and fetal heart monitors with appropriate displays of the well-being of the fetus during pregnancy, labor, and delivery. This generic type of device may include any of the devices subject to §§ 884.2600, 884.2640, 884.2660, 884.2675, 884.2700, and 884.2720. This generic type of device may include the following accessories: Central monitoring system and remote repeaters, signal analysis and display equipment, patient and equipment supports, and component parts.(b)
Classification. Class II (performance standards).