(162 days)
The T3 Software is intended for the recording and display of multiple physiological parameters of adult, pediatric and neonatal patients from supported bedside devices. T3 is not intended for alarm notification or waveform display, nor is it intended to control any of the independent bedside devices to which it is connected. T3 is intended to be used by healthcare professionals for the following purposes:
- · To remotely consult regarding a patient's status, and
- · To remotely review other standard or critical near real-time patient data in order to aid in clinical decisions and deliver patient care in a timely manner.
T3 can display numeric physiologic data captured by other medical devices:
- · Airway flow, volume and pressure
- · Arterial blood pressure (invasive and non-invasive, systolic, diastolic, and mean)
- · Bispectral index (BIS, signal quality index, suppression ratio)
- Cardiac Index
- · Cardiac output
- · Central venous pressure
- · Cerebral perfusion pressure
- · End-tidal CO2
- · Heart rate
- · Heart rate variability
- · Intracranial pressure
- · Left atrium pressure
- · Oxygen saturation (intravascular, regional, SpO2)
- · Premature ventricular counted beats
- · Pulmonary artery pressure (systolic, diastolic, and mean)
- · Pulse pressure variation
- · Pulse Rate
- · Respiratory rate
- · Right atrium pressure
- · Temperature (rectal, esophageal, tympanic, blood, core, nasopharyngeal, skin)
- · Umbilical arterial pressure (systolic, diastolic, and mean)
WARNING: T3 Software is not an active patient monitoring system; it is intended to supplement and not replace any part of the hospital's device monitoring. Do not rely on the T3 Software as the sole source of patient status information.
The Tracking, Trajectory, Trigger (73) intensive care unit software solution allows clinicians and quality improvement teams in the ICU to aggregate data from multiple sources, store it in a database for analysis, and view the streaming data in real-time. System features include:
- Customizable display of physiologic parameters over entire patient stay ●
- Configurable annotation ●
- Web-based visualization that may be used on any standard browser ●
- Minimal IT footprint ●
- Software-only solution no new bedside hardware required ●
- Highly reliable and robust operation ●
- Auditable data storage ●
The T3 Software is intended for the display and recording of multiple physiological parameters of adult, pediatric and neonatal patients. T3 is not intended for alarm notification or waveform display, nor is it intended to control any of the independent bedside devices to which it is connected.
The T3 software can display user-defined, derived measures. These measures include the percentage of time within a time period that a particular variable is above or below a threshold. The user can configure the time period, threshold, and label of the resulting derived measure for ease of use considerations, only.
The T3 Software is not an active patient monitoring system. It is intended to supplement and not replace any part of the hospital's device monitoring.
T3 has a web architecture consisting of a user interface that runs in a browser, and a central web server. The T3 server, a set of cooperating web services written in Java, processes data as it is received, caches it in memory, and writes out copies of the data to a relational database and to the file system. In this manner, the data is available to the user interface to be visualized by the end user – a clinician.
Clinicians access the T3 user interface in a web browser. T3 runs in current browsers that support HTML5, Javascript and web sockets, such as Chrome, Firefox, Safari and Internet Explorer. The clinicians may be in the hospital, or may be outside the hospital accessing T3 over a Virtual Private Network (VPN). Clinicians use T3 in addition to the physiometric devices themselves and other information sources such as the electronic medical record to monitor the patient's condition.
The T3 Software is a medical device intended for the recording and display of multiple physiological parameters of adult, pediatric, and neonatal patients from supported bedside devices. It is not intended for alarm notification, waveform display, or to control independent bedside devices. It is meant to aid healthcare professionals in remote consultation and review of patient data for clinical decisions.
Here's an analysis of the acceptance criteria and the study that proves the device meets them:
1. Table of Acceptance Criteria and Reported Device Performance:
The document does not provide a formal table of quantitative acceptance criteria with specific performance metrics (e.g., sensitivity, specificity, accuracy) and corresponding reported device performance. Instead, it states that:
| Acceptance Criteria (Implied) | Reported Device Performance |
|---|---|
| Software functions as intended | Confirmed through unit tests, integration and manual performance tests, and unscripted exploratory testing. |
| Meets all performance specifications | Confirmed through unit tests, integration and manual performance tests, and unscripted exploratory testing. |
| Safe and effective for intended use | Demonstrated through performance testing and comparison to predicate device. |
| Does not introduce new safety or effectiveness questions compared to predicate | Minor technological differences do not raise new safety or effectiveness questions. |
2. Sample Size Used for the Test Set and Data Provenance:
The document does not specify a "test set" in the traditional sense of a dataset used for performance evaluation of a clinical algorithm. The performance evaluation was focused on software verification and validation rather than clinical outcomes. Therefore, information on sample size for a test set and its data provenance (e.g., country of origin, retrospective/prospective) is not applicable and not provided in this context.
3. Number of Experts Used to Establish Ground Truth for the Test Set and Qualifications of those Experts:
Since there isn't a traditional "test set" and clinical ground truth in the context of an algorithm's diagnostic or predictive performance, this information is not applicable and not provided. The assessment was purely technical for software functionality.
4. Adjudication Method for the Test Set:
As there was no traditional test set with clinical ground truth requiring adjudication, this information is not applicable and not provided.
5. Multi-Reader Multi-Case (MRMC) Comparative Effectiveness Study:
A MRMC comparative effectiveness study was not conducted. The document focuses on software verification and validation, and demonstrating substantial equivalence to a predicate device, not on improving human reader performance with AI assistance.
6. Standalone (Algorithm Only) Performance:
The T3 Software itself is a "standalone" software solution in the sense that it processes data and displays it without direct human intervention in its core data processing. However, it is explicitly stated that this software is not an active patient monitoring system and is intended to supplement and not replace any part of the hospital's device monitoring. Therefore, it's not a standalone diagnostic or predictive algorithm for which performance metrics like sensitivity/specificity would typically be reported. Its "standalone" performance is its ability to accurately record and display parameters.
7. Type of Ground Truth Used:
The "ground truth" for the software validation was defined by the software requirements and performance specifications. The software was tested to confirm it functions as intended and meets these predetermined specifications. This is a technical "ground truth" rather than a clinical ground truth (e.g., pathology, outcomes data, or expert consensus on a diagnosis).
8. Sample Size for the Training Set:
The document describes software verification and validation, not the training of a machine learning algorithm. Therefore, there is no training set in this context, and this information is not applicable and not provided.
9. How the Ground Truth for the Training Set Was Established:
As there was no training set for a machine learning algorithm, the concept of establishing ground truth for it is not applicable and not provided.
§ 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).