Search Results
Found 1 results
510(k) Data Aggregation
(27 days)
UNITY NETWORK PATIENT DATA SERVER
The Unity Network® Patient Data Server (PDS) is intended for use under the direct supervision of a licensed healthcare practitioner. The Unity Network® Patient Data Server is intended to provide centralized intermediate term storage of patient centric events and physiological data on adult, pediatric and neonatal patients within a hospital or facility providing patient care. Patient events and physiological data stored at the Unity Network® Patient Data Server can be accessed via any (authorized) device that implements the PDS data exchange protocol. The Unity Network Patient Data Server is NOT intended to be the sole source for patient data and is to be used in conjunction with the data at the bedside monitor and central monitoring station.
The Unity Network® Patient Data Server provides a caregiver the ability to view patient centric events and physiological data that was collected from acquisition devices on the Unity Network prior to the current monitoring session. The Unity Network® Patient Data Server stores at least 500 alarm histories (400 arrhythmia events and 100 ST history events) and at least 72 hours of physiological data per unique patient identifier. Information from the Unity Network® Patient Data Server can be accessed by a GEMS-IT device that implements the Unity Network® Patient Data Server's proprietary data exchange protocol.
The Unity Network® Patient Data Server is a system of hardware and software that operates on standard commercially available server class hardware and interfaces with the Unity Network®. The Unity Network® Patient Data Server system obtains and stores data from devices that are connected and admitted to a monitoring device on the Unity Network® and relays that data to connected clients for viewing. Only clients that are connected to Unity Network® and have access to a proprietary application protocol interface can access the data stored in the Unity Network® Patient Data Server.
The Unity Network® Patient Data Server system provides data to central station monitoring devices, and is NOT a patient monitoring device. The clinician is instructed to always reference the primary bedside monitor before making any patient care decisions. In the event that data is not available via the Unity Network® Patient Data Server, the clinician is instructed to obtain the data from the primary bedside monitor.
The Unity Network® Patient Data Server is a medical device, and the information provided details its intended purpose and the general testing conducted to ensure its safety and effectiveness. However, it does not present specific acceptance criteria in the form of quantitative performance metrics (e.g., accuracy, sensitivity, specificity, data retention rates within a certain tolerance) that a study would then prove the device meets.
Instead, the submission focuses on validation of the development process and system functionality rather than a statistical performance study against defined clinical endpoints or ground truth.
Here's an breakdown based on the provided text, addressing your questions where possible:
1. Table of Acceptance Criteria and Reported Device Performance
| Acceptance Criteria Category (Derived from document) | Reported Device Performance (Derived from document) |
|---|---|
| Compliance with Voluntary Standards | Complies with voluntary standards as detailed in Section 9 of the submission. |
| Risk Analysis Conducted | Applied in development. |
| Requirements Reviews Conducted | Applied in development. |
| Design Reviews Conducted | Applied in development. |
| Unit Level Testing (Module Verification) | Conducted. |
| Integration Testing (System Verification) | Conducted. |
| Final Acceptance Testing (Validation) | Conducted. |
| Performance Testing | Conducted. |
| Safety Testing | Conducted. |
| Environmental Testing | Conducted. |
| Functional Equivalence to Predicate Device | "The results of these measurements demonstrated that the Unity Network® Patient Data Server is as safe, as effective, and perform as well as the predicate device." |
| Storage Capacity (Events) | Stores at least 500 alarm histories (400 arrhythmia events and 100 ST history events). |
| Storage Capacity (Physiological Data) | Stores at least 72 hours of physiological data per unique patient identifier. |
Important Note: The document does not provide specific numerical "acceptance criteria" for metrics like data integrity, retrieval speed, or specific error rates. The acceptance is based on the successful completion of various testing phases within the product development lifecycle and a general claim of equivalence to the predicate device.
2. Sample Size for Test Set and Data Provenance
The document does not specify a "test set" in the context of patient data or clinical cases to evaluate performance against a ground truth. The testing described (unit, integration, acceptance, performance, safety, environmental) refers to software and hardware validation, not a clinical performance study with annotated data. Therefore, information on sample size and data provenance (e.g., retrospective/prospective, country of origin) is not applicable in the sense of a diagnostic or predictive AI device.
3. Number of Experts and Qualifications for Ground Truth
Not applicable. Since there is no mention of a "test set" requiring ground truth established by experts for clinical performance, this information is not provided. The device is a data server, not a diagnostic tool that interprets physiological data.
4. Adjudication Method
Not applicable. As there's no clinical performance test set, there's no need for an adjudication method by experts.
5. Multi-Reader Multi-Case (MRMC) Comparative Effectiveness Study
Not applicable. The Unity Network® Patient Data Server is a data storage and retrieval system, not an AI algorithm that assists human readers in interpreting medical images or data. Therefore, an MRMC study comparing human readers with and without AI assistance was not performed or described.
6. Standalone (Algorithm Only) Performance Study
Not applicable. The device is a data server. While its software has functionalities and performance metrics (e.g., data storage capacity, retrieval speed, which are alluded to with "performance testing"), it's not a standalone "algorithm" in the sense of a medical AI that generates diagnostic or prognostic outputs. Its performance is evaluated through system tests and validation of its intended functions.
7. Type of Ground Truth Used
The concept of "ground truth" as typically understood in AI/medical device performance studies (e.g., pathology reports, follow-up outcomes, expert consensus on disease presence) is not applicable to this device. The "ground truth" for a data server would more appropriately be the accurate storage, retrieval, and integrity of the original physiological data and events as generated by the monitoring devices. The document implies that the "tests" (unit, integration, acceptance) verified this functional accuracy.
8. Sample Size for Training Set
Not applicable. This device is not an AI algorithm that undergoes "training" on a dataset. It is a software and hardware system designed for data management.
9. How Ground Truth for Training Set Was Established
Not applicable. Since there is no training set for an AI algorithm, this information is not relevant.
Ask a specific question about this device
Page 1 of 1