(43 days)
The intended use of the Spacelabs Medical Clinical Event Interface is to interface with the Spacelabs monitoring network in order to provide a secondary means of annunciating and displaying patient alarm information to mobile healthcare providers. The device is indicated for use in real-time monitoring of routine patient status and alarm events. The pager is intended to serve as a parallel, redundant mechanism to inform the clinical staff of patient events. The Clinical Event Interface System is intended for use as a secondary alarm in any hospital environment currently using or intending to use a Spacelabs patient monitoring network. The Clinical Event Interface supplements the primary patient-monitoring system by providing a forwarding mechanism for annunciating and displaying patient alarm events and the critical information associated with the events - including parameter values and waveforms, typically within 4 - 8 seconds of an alarm event on the patient monitor. The pager provides an audio or vibrating alert along with a series of displays showing patient identification, alarm parameters, and up to a 12-second waveform snapshot.
The Spacelabs Medical Clinical Event Interface is a secondary alarm. It does not replace the primary alarm function on the monitor.
The Spacelabs Medical Clinical Event Interface (CEI), model 91847, is a software module intended to be installed on an Off-The-Shelf (OTS) computer system utilizing a Microsoft operating system. The primarv purpose of the CEI is to forward patient monitor alarm event information, originating from a Spacelabs Patient Monitoring network, to a messaging and notification system for delivery to the healthcare provider via wireless pagers. The system is also capable of providing vital signs updates at regular intervals. CEI allows nurses to be aware of their patients' alarm conditions when they are away from the patient and the monitoring system.
CEI is an open design utilizing an OTS messaging system that is compatible with the Motorola CP1250 paging systems. The Clinical Event Interface includes a software module, created by Spacelabs Medical, that accesses patient data acquired from a Spacelabs Medical Patient Monitoring System. The monitoring system forwards the data to a database. The Spacelabs Medical software module recognizes when new information has become available. It accesses and formats that data for delivery to the Emergin Integrated Messaging System, an OTS software package. The Emergin software accepts input from the Spacelabs program, reformats it and passes it on to the paging encoder, an OTS component of the system. The paging encoder formats the data for the Motorola CP1250 pager and forwards it to the pager base station for transmission to the pager. The Spacelabs Medical CEI provides a complete, end-to-end solution for paging and incorporates all of these components in a single offering.
The CEI messaging system provides for the sending patient information in a text only or text and graphic format to the Motorola CP1250 pager. The CEI system is designed to forward alarm information as the alarms are recognized by the patient monitoring network. The system is also cable of being set up to periodically forward a patient's physiological data at predetermined intervals.
The Spacelabs Medical ICS Clinical Event Interface (CEI), model 91847, system is a secondary alarm notification system. It does not replace the primary alarm function of the bedside monitor.
The provided text describes the Spacelabs Medical Clinical Event Interface (CEI), Model 91847, a software module designed to forward patient monitor alarm event information to a messaging and notification system for delivery to healthcare providers via wireless pagers.
Here's an analysis of the acceptance criteria and study information, based solely on the provided text:
1. Table of Acceptance Criteria and Reported Device Performance
The document does not explicitly state specific, quantifiable acceptance criteria (e.g., "alarm delivery must occur within X seconds with Y% reliability") or a table comparing them to reported device performance. It only mentions the expected typical performance.
| Acceptance Criteria | Reported Device Performance |
|---|---|
| Alarm Delivery Latency | "typically within 4 - 8 seconds of an alarm event on the patient monitor" |
| Information Presented | "patient identification, alarm parameters, and up to a 12-second waveform snapshot" |
| Alert Mechanism | "audio or vibrating alert" |
2. Sample size used for the test set and the data provenance
The document does inform that the device "was validated through rigorous testing." However, it does not specify:
- The exact sample size used for the test set.
- The data provenance (e.g., country of origin of the data, retrospective or prospective).
3. Number of experts used to establish the ground truth for the test set and the qualifications of those experts
The document does not provide information on:
- The number of experts used to establish the ground truth for the test set.
- The qualifications of those experts.
4. Adjudication method for the test set
The document does not describe any adjudication method (e.g., 2+1, 3+1, none) used for the test set. The validation focused on the technical performance of the system in forwarding alarms.
5. Multi-reader multi-case (MRMC) comparative effectiveness study
The document does not mention a multi-reader multi-case (MRMC) comparative effectiveness study. The device is a "secondary alarm notification system" designed primarily for technical function (forwarding alarms to pagers), not for interpretation by human readers in a diagnostic setting that would typically involve MRMC studies.
6. Standalone (algorithm only without human-in-the-loop performance) study
A standalone study was conducted, focusing on the technical performance of the CEI software module and its interaction with off-the-shelf (OTS) components. The text states: "CEI was validated through rigorous testing that, in part, support the compliance of the CEI software module and its OTS components... The test program included all of the components of the system and verified that as data became available to CEI it was acquired and forwarded through to the pager." This indicates a focus on the automated system's performance in transmitting alarms.
7. The type of ground truth used
The "ground truth" in this context is the actual occurrence of an alarm event on the primary patient monitoring network and the subsequent successful and timely transmission of that information through the CEI system to the pager. The testing verified the system's ability to "acquire[] and forward[] through to the pager" data that "became available to CEI" from the patient monitoring network. This is essentially a functional verification against the real-time events generated by the patient monitors.
8. The sample size for the training set
The document does not specify a training set size. The CEI is a software module for forwarding existing alarm data, rather than a machine learning model that would typically require a training set. The validation described is more akin to system integration and functional testing.
9. How the ground truth for the training set was established
As the CEI is not a machine learning model, the concept of a "training set" and establishing ground truth for it in the traditional sense is not applicable. The validation focused on the functional performance of the system in a controlled testing environment, where the "ground truth" would be the known and controlled generation of alarm events from the Spacelabs Patient Monitoring network.
§ 870.2300 Cardiac monitor (including cardiotachometer and rate alarm).
(a)
Identification. A cardiac monitor (including cardiotachometer and rate alarm) is a device used to measure the heart rate from an analog signal produced by an electrocardiograph, vectorcardiograph, or blood pressure monitor. This device may sound an alarm when the heart rate falls outside preset upper and lower limits.(b)
Classification. Class II (performance standards).