Search Results
Found 1 results
510(k) Data Aggregation
(29 days)
The intended use of the Ascom Unite Connect for Clinical Systems is to provide an interface with clinical systems to forward information associated to the particular event to the designated display device(s).
For medical, near real time alarms, Connect for Clinical Systems is intended to serve as a parallel, redundant, forwarding mechanism to inform healthcare professionals of particular medical related events. Connect for Clinical Systems does not alter the behavior of the primary medical devices and associated alarm annunciations. The display device provides a visual, and/or audio and/or vibrating mechanism upon receipt of the alert.
Connect for Clinical Systems is intended for use as a secondary alarm. It does not replace the primary alarm function on the monitor.
Ascom Sweden AB (Ascom) Unite Connect for Clinical Systems (Unite Connect) is a software application installed on a Windows server environment capable of acquiring alarms, events, parameters and waveforms from clinical systems and intelligently forwarding that information as notifications to designated display devices provided by Ascom or third-party mobile device companies. The device operates within the Ascom Unite Messaging Suite for Healthcare application environment.
Unite Connect is designed to accept inputs from a variety of clinical systems utilizing standardized and proprietary protocols including the following:
● Spacelabs XprezzNet
● Dräger Infinity Gateway
Users receive interactive, time-critical information from clinical systems directly via their display devices as text, alarms, static waveform images or data. Received attributes related to the presentation of alerts include color and quantity of tones (beeps) in addition to and in coordination with event priorities. Unite Connect allows users to be aware of their patients' status and alarm conditions when they are away from the patient and patient monitoring system.
Unite Connect connects to the information sources through wired ethernet connections which are part of the customer's infrastructure, and acquires patient data from clinical systems. The user configures Unite Connect to determine which information, including alarm notifications, is delivered to which users. Unite Connect then formats the data for wireless delivery to the display devices through Unite Connectivity Manager (Unite CM) or the Unite Communication Server (Unite CS).
All messaging activities are recorded in Unite CM or Unite CS providing real-time activity logging for audit trail records and reporting. Unite Connect delivers near real-time text messaging alerts and information to text-capable display devices.
Ascom provides wireless communications system platform for delivery of notifications to display devices, the technologies include DECT (Digital Enhanced Cordless Telecommunications), WiFi, Paging and GSM/3G/4G.
Unite Connect, combined with an Ascom wireless communication system, is part of an Ascom end-to-end solution designed to provide all the components necessary to optimize work flow, including display devices, gateways and device management.
The provided document is a 510(k) Premarket Notification from the FDA for the "Ascom Unite Connect for Clinical Systems." This type of document is for demonstrating substantial equivalence to a legally marketed predicate device, not for establishing clinical efficacy or a direct comparison of human reader performance with and without AI assistance through MRMC studies.
Therefore, the document does not contain the specific information required to answer many of the questions, as it pertains to a software interface managing and forwarding alarms, not an AI-powered diagnostic device.
Here's an analysis based on the available information:
This device is a software interface for forwarding alarms from clinical systems, not an AI-powered diagnostic device. As such, the concept of "acceptance criteria" and "study that proves the device meets the acceptance criteria" in the context of diagnostic accuracy (e.g., sensitivity, specificity, or human reader improvement with AI) is not directly applicable.
The performance testing described focuses on functional requirements, safety, and compliance with general standards for medical device software and alarm systems.
Here's what can be extracted and what information is not present:
1. A table of acceptance criteria and the reported device performance
The document details performance testing related to software verification and compliance with standards. It does not provide a table with quantitative performance metrics like sensitivity, specificity, or response times with specific acceptance criteria thresholds beyond general statements of compliance.
- Software Verification & Validation: The software was designed and developed according to a robust software development process and "rigorously verified and validated." "Test results indicate that Unite Connect complies with its predetermined specifications and the applicable guidance documents and standards."
- Performance Testing – Bench: "Unite Connect was verified for performance in accordance with internal requirements and the following standards: IEC 60601-1-8: 2006, Am1: 2012 (alarm systems), IEC 62366-1: 2015 (usability engineering)." "Verification results indicate that Unite Connect complies with its predetermined specifications and the applicable standards."
No specific numerical acceptance criteria or reported performance values (e.g., "alarm delivery within X seconds," "jitter < Y ms") are explicitly stated in this summary. The acceptance is based on conformity to specifications and regulatory/industry standards.
2. Sample sized used for the test set and the data provenance (e.g. country of origin of the data, retrospective or prospective)
This information is not provided. Given the nature of the device (alarm forwarding software), "sample size for a test set" typically refers to the number of test cases or scenarios executed during software verification and validation, rather than a dataset of patient images or readings. The document does not specify the number of test cases run.
Data provenance (country of origin, retrospective/prospective) is not relevant for this type of software, as it processes existing clinical alarms/data, it does not generate new data or interpretations from patient information in the way a diagnostic AI would.
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)
This is not applicable. For alarm forwarding software, "ground truth" would relate to the correct routing and delivery of alarms as per the system's configuration and intended functionality. This is established through functional testing against predetermined system requirements and specifications, not by clinical experts reviewing data for diagnostic accuracy.
4. Adjudication method (e.g. 2+1, 3+1, none) for the test set
Not applicable. Adjudication methods (like 2+1, 3+1) are used to resolve disagreements among human readers when establishing ground truth for diagnostic studies. This device does not involve human interpretation or diagnostic decision-making that would require such adjudication.
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. This type of study (MRMC comparative effectiveness) is specifically for evaluating the impact of AI on human reader performance in diagnostic tasks. The Ascom Unite Connect is an alarm management and forwarding system, not a diagnostic AI. Therefore, an MRMC study was not performed and is not relevant to its regulatory clearance.
6. If a standalone (i.e. algorithm only without human-in-the-loop performance) was done
Yes, in a sense. The "performance testing – bench" section describes verification activities for the "Unite Connect" software itself, independent of immediate human interaction, to ensure it meets its pre-determined specifications and standards for alarm handling and forwarding. This is effectively the "algorithm only" performance, but it's about software functionality and reliability, not diagnostic accuracy.
7. The type of ground truth used (expert consensus, pathology, outcomes data, etc)
The "ground truth" for this device is its defined functional specifications and compliance with relevant medical device software and alarm system standards (e.g., IEC 60601-1-8 for alarm characteristics). The software's performance is verified against these pre-determined requirements, rather than against clinical outcomes or expert labels on patient data.
8. The sample size for the training set
Not applicable. This device is an alarm forwarding software application, not a machine learning or AI algorithm that requires a "training set" in the context of data-driven model learning.
9. How the ground truth for the training set was established
Not applicable, as there is no "training set" for this software.
Ask a specific question about this device
Page 1 of 1