(287 days)
The CIVNET CIV-ob software application is intended for automatic fetal monitor patient data management. The application does this by:
a) Displaying on-line fetal heart rate and TOCO data received from the patient Displaying on mic recar near representation as it is displayed on the fetal monitor paper printout.
b) Providing the means to control and display multiple beds simultaneously.
c) Providing automatic Archiving of the data.
c) Frovide the ability to interface with different fetal monitors operating with the same interface protocol.
e) Easy interfacing with any IT patient record system for data acquisition, viewing and storage of electronic patient record.
f) Provide visual notification of when acquired fetal monitor heart rate exceed I to ride visual nothlous for high and low fetal heart rate and poor signal quality.
g) Providing the ability to record, with patient record, fluid input and output information that is defined by the user.
h) Providing the ability to archive files to a secondary or tertiary storage medium (i.e. optical disk).
Providing the ability to print (locally or remote) patient records. i)
i) I roviding the ability to review fetal monitor data remotely over the TCP/IP
The CIVNET CIV-ob is a software application that is intended for use as a clinical data management system (also referred to as a clinical information system - CIS). The function of the system is the management of fetal and maternal vital heart rate and uterine vital signs clinical data automatically acquired from a bedside fetal monitor, for the purpose of providing, ready and organized access to patient and/or clinical data that would normally be provided on paper records and/or separate clinical systems/devices. The CIV-ob serves as an electronic medical record. The CIV-ob operates with off-the-shelf software and hardware. The device is intended for use in a hospital/clinical environment.
Here's a breakdown of the acceptance criteria and study information for the CIV-ob Obstetrical Monitoring Software Application based on the provided K051175 document:
1. Table of Acceptance Criteria and Reported Device Performance
| Acceptance Criteria Category | Specific Criteria/Tests (as described) | Reported Device Performance (as described) |
|---|---|---|
| Voluntary Standard Compliance | IEC 60601-1-4 Computer Controlled Medical Devices | Complies with IEC 60601-1-4 standard. |
| Software Risk Analysis | Addressing risks related to: | Checked as part of CIVnet's Software Test Procedure for validation. Results not numerically reported in this document. |
| - Communication | ||
| - Loss of power conditions | ||
| - Out of limit conditions | ||
| - Server communication | ||
| - Installation | ||
| - Memory capacity | ||
| Hardware Risk Analysis | Risks associated with off-the-shelf devices and their possible failure. | Not explicitly detailed as a separate test result, but implied to be addressed. |
| User Interface Risk Analysis | Addressing: | Not explicitly detailed as a separate test result, but implied to be addressed. |
| - Patient Data Security | ||
| - Patient Data Accuracy |
Important Note: The provided document is a 510(k) Summary, not a full study report. It states that the acceptance criteria are detailed in CIVnet's IEC 60601-1-4 report and Risk Analysis, and that software risks are "checked as part of CIVnet's Software Test Procedure for validation." However, the document does not provide numerical results, performance metrics, or specific pass/fail rates for any of the criteria in this 510(k) Summary. The performance is broadly stated as "compliance" or "addressed."
2. Sample Size Used for the Test Set and Data Provenance
- Sample Size for Test Set: Not specified in the provided document.
- Data Provenance: Not specified in the provided document.
3. Number of Experts Used to Establish Ground Truth for the Test Set and Qualifications of Experts
- This information is not provided in the document. The submission focuses on software and system validation rather than a clinical efficacy study requiring expert-established ground truth for a specific diagnostic outcome.
4. Adjudication Method for the Test Set
- This information is not provided in the document. As no clinical ground truth establishment or reader study is described, adjudication methods are not applicable here.
5. If a Multi-Reader Multi-Case (MRMC) Comparative Effectiveness Study was Done, What was the Effect Size of How Much Human Readers Improve with AI vs. Without AI Assistance
- No MRMC comparative effectiveness study is described or implied in the provided document. The device is a "clinical data management system" and an "Obstetrical Monitoring Software Application," focusing on data management, display, and archiving, rather than an AI diagnostic tool designed to directly improve human reader performance on a diagnostic task.
6. If a Standalone (i.e., algorithm only without human-in-the-loop performance) was Done
- The document describes the device as a "software application" that performs functions like displaying data, providing control, archiving, and interfacing. The validation mentioned ("Software Test Procedure for validation of the software") implies testing of the algorithm/software's functionality and adherence to specifications. While not explicitly termed a "standalone performance study," the software validation would assess the algorithm's ability to precisely execute its programmed functions (e.g., accurately display data, archive data correctly, provide visual notifications when heart rates exceed limits). However, no specific performance metrics for this standalone functionality (e.g., accuracy of visual notifications, data fidelity during archiving) are reported in this summary beyond general compliance.
7. The Type of Ground Truth Used
- For the software testing described, the "ground truth" would be the expected functional behavior and output of the software based on its design specifications and the standards it aims to comply with (e.g., IEC 60601-1-4). For example, if the software is supposed to display a fetal heart rate value from a monitor, the ground truth would be that the displayed value matches the input value received from the monitor. If it's supposed to trigger a visual alert for a heart rate exceeding a threshold, the ground truth would be that the alert triggers precisely when that threshold is met by the input data. This is more akin to systematic verification and validation against specifications rather than traditional clinical ground truth methods like pathology or expert consensus.
8. The Sample Size for the Training Set
- This information is not applicable/not provided. The CIV-ob is described as a "clinical data management system" and software application, not a machine learning or AI algorithm that typically requires a training set. Its functionality appears to be rule-based and deterministic, focused on data handling, display, and alerts according to predefined criteria.
9. How the Ground Truth for the Training Set was Established
- This information is not applicable/not provided for the same reasons as in point 8.
§ 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).