Search Results
Found 1 results
510(k) Data Aggregation
(116 days)
Nihon Kohden Digital Health Solutions, Inc.
Next Generation NetKonnect is interface the Nihon Kohden monitoring network with networked client PCs to annunciate and display patient monitoring information to healthcare providers. The device is intended for use in near real-time monitoring of routing patient status and alarm events. Next Generation NetKonnect supplements the primary patient monitoring system by providing a forwarding for annunciating and displaying patient alarm events and event related information including vital signs values and waveforms. The system is intended for use on any patients as determined by qualified medical personnel within a hospital or clinical environment.
NGNK is a software product that runs on Microsoft Windows architecture. NGNK will communicate with Nihon Kohden devices by a network connection and through the Gateway. The NGNK is intended to interface the Nihon Kohden monitoring network to annunciate and display patient monitoring information to healthcare providers. The device is intended for use in near real-time monitoring of patient status and alarm events. NGNK supplements the primary patient monitoring system by providing remote monitoring capability, including vital signs, alarms and waveforms.
The provided document describes the FDA 510(k) clearance for the Next Generation NetKonnect device. This device is a software product designed to interface with the Nihon Kohden monitoring network to annunciate and display patient monitoring information to healthcare providers. It is an update to a previously cleared device, NetKonnect Remote Network Extension (K112637).
The document focuses on demonstrating substantial equivalence to the predicate device, rather than proving performance against specific quantitative acceptance criteria for a novel device. The primary changes are updates to the User Interface and support for current 64-bit Windows architectures.
Here's an breakdown of the requested information based on the provided text:
1. A table of acceptance criteria and the reported device performance
The document does not specify quantitative acceptance criteria in terms of performance metrics (e.g., sensitivity, specificity, accuracy) for physiological measurements or alarm detection. This is because the device primarily functions as a display and annunciation system for data already processed by the primary patient monitoring system, which itself has established performance.
Instead, the "acceptance criteria" appear to be implicit in demonstrating that the modified device performs its intended functions (displaying vital signs, waveforms, and alarm events) reliably and safely, consistent with its predicate. The "reported device performance" is summarized in a qualitative manner through the non-clinical testing.
| Feature/Requirement | Acceptance Criteria (Implied) | Reported Device Performance |
|---|---|---|
| Functional Equivalence | The device must perform the same core functions as the predicate: interface with the monitoring network, annunciate/display patient monitoring info (vital signs, waveforms, alarm events), and act as a supplementary system. | The "Description of Communication requirements" and "Performance Specification" sections indicate that the subject device (NGNK) "SAME" as the predicate for receiving and forwarding waveform/numerical data using Nihon Kohden's proprietary “NET9” protocol. The primary function of displaying patient history information (Trend Data, Hemodynamics lists, Arrhythmia recall, ST recall, Full disclosure, ECG 12 lead analysis) is also stated as "SAME". |
| Safety and Effectiveness | The modifications (UI update, OS support) must not introduce new questions of safety or effectiveness. The device must be as safe and effective as the predicate. | "The required testing of the Next Generation NetKonnect was performed in accordance with the requirements of the design control guidelines and established quality assurance processes to demonstrate substantial equivalence... The software testing demonstrated that the software version meets it design requirements." Conclusion: "Based on the design and results of testing, it can be concluded that the subject device - Next Generation NetKonnect - is as safe, as effective, and performs as well as or better than the predicate." |
| Alarm Notification | Alarm notification functionality should be clear and not replace the primary alarm system. (Note: NGNK differs slightly but is deemed substantially equivalent). | Predicate: "Alarm notification is a secondary notification system and does not replace the primary alarm notification at the bedside monitor." Subject device: "SAME." However, the subject device "NGNK does not forward alarm notification. This difference does not affect the device from performing in a manner in which it is intended to operate from the predicate device “NetKonnect”". This implies that while the mechanism might be different, it still serves the intended supplementary purpose without compromising the primary system. |
| Operating System Support | The device should run on a compatible and current operating system. | Predicate: "Micorsoft windows that support Win32 service processes." Subject device: "Substantially equivalent: NGNK now supports current standard 64 bit Windows archetures." This is an improvement to support modern IT environments. |
| User Interface (UI) Design | The UI should be updated to be consistent with current technology and user experience while maintaining clarity and functionality similar to connected FDA cleared devices. | Predicate: "User interface is similar to the connected FDA cleared devices Nihon Kohden bedside monitoring and primary central monitoring systems." Subject device: "Substantially equivalent: Updates in the user interface to be consistent with current user interfaces on connected FDA cleared devices Nihon Kohden bedside monitoring and primary central monitoring systems." The primary objective of NGNK was stated as "to update the User Interface due to advancements in technologies and match current on-market products for a consistent experience." |
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 states: "No clinical testing was required or performed since substantial equivalence of the device was supported by the non-clinical testing."
Therefore, there is no clinical test set, sample size, or specific data provenance (country, retrospective/prospective) to report for the performance of the device on patient data. The evaluation was primarily internal engineering and software testing.
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)
Given that no clinical testing was performed and the evaluation relied on non-clinical (software) testing, there were no external experts or "ground truth" derived from patient data for an independent performance evaluation. The "ground truth" for software testing usually refers to specified design requirements and expected outputs, which are internally verified by the manufacturer's engineering team.
4. Adjudication method (e.g. 2+1, 3+1, none) for the test set
There was no adjudication method used for a clinical test set, as no clinical testing was performed.
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 performed. The device is not an AI-assisted diagnostic tool that would typically involve human readers and their performance improvement. It is a display and annunciation system.
6. If a standalone (i.e. algorithm only without human-in-the-loop performance) was done
The device itself is software that operates "standalone" in the sense that it processes and displays data from patient monitors. However, its purpose is to complement human monitoring in a clinical environment. The software testing mentioned is effectively a standalone performance evaluation against its design requirements and functional specifications. The specific results of this software testing (e.g., bug reports, pass/fail rates for specific test cases) are not detailed in this summary.
7. The type of ground truth used (expert consensus, pathology, outcomes data, etc)
For the non-clinical (software) testing, the "ground truth" would be the design specifications and functional requirements of the software. This involves verifying that the software correctly receives, processes, and displays the data as intended, and that the user interface functions as designed, without introducing errors or safety concerns. This type of ground truth is established by the manufacturer during the design and development process.
8. The sample size for the training set
The document does not mention any training set. This is not an AI/machine learning device that typically requires training data. It is a communication and display software.
9. How the ground truth for the training set was established
As there is no training set, this question is not applicable.
Ask a specific question about this device
Page 1 of 1