Search Results
Found 10 results
510(k) Data Aggregation
(272 days)
MOD
EveryWare is indicated to support clinicians by managing data of patients who are prescribed compatible therapy devices in accordance with the intended use of those therapy devices. EveryWare provides remote patient data collection & viewing and is intended to be used by healthcare representatives in conjunction with compatible non-life support therapy devices to adjust prescription and/or performance settings. EveryWare is intended to be used in hospital, institutional, provider, and home care settings.
EveryWare is a platform that gathers treatment information from Breas respiratory devices in a secure cloud-based system. The data from ventilator is sent over a cellular modem through a cellular network to a cloud-hosted secure data storage system. The authenticated users access this cloud hosted system from a browser in their computer.
EveryWare securely connects compatible medical devices located at the point of patient care to the cloud, and provides authorized healthcare representatives the means to manage patient and device information and settings. EveryWare does NOT alter the intended use of connected medical devices or provide functions to automate diagnosis or therapy.
This document is a 510(k) clearance letter for the medical device "EveryWare." It focuses on establishing substantial equivalence to previously cleared predicate devices. Therefore, it does not contain the detailed study information typically found in a clinical trial report or a performance validation study for a novel device.
Based on the provided text, here's what can be extracted and what is NOT available:
1. Table of Acceptance Criteria and Reported Device Performance
- Acceptance Criteria: Not explicitly stated as quantifiable metrics (e.g., "sensitivity $\ge 90%$"). The document primarily focuses on demonstrating that EveryWare's functionalities and technical characteristics are similar to its predicates, and that its differences "do not raise new questions of safety and effectiveness."
- Reported Device Performance: Instead of performance metrics, the document lists functional and technological characteristics and states their similarity or difference compared to predicates. Performance is broadly assessed through "non-clinical testing" listed below.
| Characteristic | Acceptance Criterion (Implied) | EveryWare Performance (Reported) |
|---|---|---|
| Intended Use | Must be within or similar to predicate devices. | "EveryWare is indicated to support clinicians by managing data of patients... provides remote patient data collection & viewing and is intended to be used by healthcare representatives... to adjust prescription and/or performance settings." Similar to predicates. |
| Environment of Use | Must be similar to predicate devices. | "EveryWare is intended to be used in hospital, institutional provider, and home care settings." Similar to predicates. |
| User Population | Must be similar to predicate devices. | "EveryWare is intended to be used by... Prescribing physicians, nurses, respiratory therapists, physiotherapists and technicians - Durable Medical Equipment (DME)/Homecare providers (HCPs)/Home Medical Equipment providers (HMPs)." Similar to predicates. |
| Application Type | Must be similar to predicate devices. | "Web-based application." Same as predicates. |
| Product Codes Supported by Remote Prescription Change Functionality | Must support relevant product codes, with differences not raising new safety/effectiveness questions. | MNS, MNT. Similar to K152356 (which supports MNS, MNT, BZD), but EveryWare does not support BZD. This difference is not presented as raising safety/effectiveness concerns. |
| Product Codes NOT Supported by Remote Prescription Change Functionality | Must align with predicates or have justified differences. | NOU, CBK. Similar to predicates. |
| Data Transfer Technology | Must be robust and achieve remote data transfer. | Wireless (cellular modem), SD Card, File upload/Internet. Uses iLink cellular modem. Similar to predicates. |
| Functionality | Must include core features of data management and settings. | Centralized database, Patient Management, Display therapy data, Generate reports, Settings management for non-life supporting devices. Same as predicates. |
| Therapy Mode Change (for non-life support devices) | Justified difference from predicates if not raising new safety/effectiveness questions. | No. Predicates Yes. Different, but "The absence of Therapy Mode Change does not raise new questions of safety and effectiveness." |
| Target Volume Setting | Must be present if offered by predicates. | Yes. Same as predicates. |
| IPAP & EPAP Settings | Must be present if offered by predicates. | Yes. Same as predicates. |
| Breath Rate and Insp. Time Setting | Must be present if offered by predicates. | Yes. Same as predicates. |
| Rise Time & Ramp Pressure Setting | Must be present if offered by predicates. | Yes. Same as predicates. |
| Humidifier Setting | Justified difference from predicates if not raising new safety/effectiveness questions. | No. Predicates Yes. Different, but "The absence of Humidifier Setting does not raise new questions of safety and effectiveness." |
| High Minute Volume, Disconnection & Apnea alarm | Must be present if offered by a predicate and relevant. | Yes. Similar to K152356. |
| Mask Resistance & Mask Resistance Lock | Must align with predicates or have justified differences. | No. Similar to K151901. |
| View Optional Screen | Must align with predicates or have justified differences. | No. Similar to K151901. |
| Tubing Type & Tubing Type Lock | Must align with predicates or have justified differences. | No. Similar to K151901. |
| Automated Airway Management | Must align with predicates or have justified differences. | No. Similar to K151901. |
| Reports | Must provide compliance reports. | Detailed report (includes compliance information). Same as predicates. |
| Labeling | Must include online help. | Online help file within the application. Same as predicates. |
| Viewing of data | Must allow interactive viewing based on date range. | Interactive viewing of data based on user selected date range. Same as predicates. |
| Safety and Effectiveness | Must be demonstrated through compliance with recognized standards and lack of new safety/effectiveness questions. | EveryWare was designed and subjected to performance testing in accordance with listed non-clinical standards (e.g., Software, Cybersecurity, Human Factors, EMC). "EveryWare, by itself, is not intended for diagnosis and treatment of disease or medical condition. EveryWare does not change the performance specification of the connected therapeutic devices. Therefore, no further performance data is required to demonstrate substantial equivalence." |
2. Sample Size Used for the Test Set and Data Provenance
This information is not provided in the clearance letter. The document mentions "performance testing" and adherence to various standards but does not detail a specific test set, its sample size, or data provenance (e.g., country of origin, retrospective/prospective nature). The focus is on software and system validation rather than clinical dataset performance.
3. Number of Experts Used to Establish the Ground Truth for the Test Set and Qualifications of Those Experts
This information is not provided. As the device is primarily a data management and remote settings platform aiming for "substantial equivalence" based on functional and technical characteristics, and not for diagnostic or therapeutic AI, there is no mention of experts establishing a clinical ground truth for a test set.
4. Adjudication Method for the Test Set
This information is not provided. Given the nature of the device and the presented documentation, it's unlikely an adjudication method for a clinical test set would be applicable or detailed here.
5. If a Multi-Reader Multi-Case (MRMC) Comparative Effectiveness Study Was Done, and the Effect Size of How Much Human Readers Improve with AI vs. Without AI Assistance
A MRMC study was not performed nor mentioned. EveryWare is a data management and settings adjustment platform, not an AI-assisted diagnostic or therapeutic tool that would typically involve human readers interpreting AI output.
6. If a Standalone (i.e., algorithm only without human-in-the-loop performance) Was Done
The device itself is a "platform that gathers treatment information from Breas respiratory devices in a secure cloud-based system" and allows "authorized healthcare representatives the means to manage patient and device information and settings." It does not involve a "standalone algorithm" in the typical sense of a diagnostic or predictive AI. Its performance is tied to its functionality in securely collecting, displaying, and allowing modification of therapy data, which relies on system integrity rather than algorithmic output interpretation. Therefore, a standalone algorithmic performance study in the context of AI was not done or reported.
7. The Type of Ground Truth Used
For EveryWare, the "ground truth" relates to:
- The accurate and secure transmission, storage, and display of patient data from compatible devices.
- The correct implementation of remote prescription/performance settings onto compatible devices.
- Compliance with various software, cybersecurity, human factors, and electromagnetic compatibility standards.
This is fundamentally different from a clinical ground truth (e.g., pathology, outcomes data, or expert consensus for disease detection). The ground truth for this type of device would be defined by technical specifications, data integrity, security protocols, and successful functional validation against a known correct behavior.
8. The Sample Size for the Training Set
This information is not provided. EveryWare is described as a data management platform rather than a machine learning model that would require a "training set" in the context of AI. The development would involve software engineering and validation practices.
9. How the Ground Truth for the Training Set Was Established
This information is not applicable as there is no "training set" mentioned in the context of an AI/ML model for this device. The development process would have involved establishing requirements and validating the software against those requirements, rather than training against a ground-truth dataset.
Ask a specific question about this device
(273 days)
MOD
The Care Cycle Connect software application is intended for use with Trilogy Series ventilators by both caregivers and clinicians. The application pairs with the Trilogy device via a Bluetooth connection. The application provides the caregiver remote patient monitoring, and alarm surveillance. Alarm surveillance consists of both an audible tone and a visible alert if an alarm condition exists. The application provides the clinician with the ability to view, collect and store patient ventilator usage data. Care Cycle Connect also provides educational information on ventilator use to both caregivers and clinicians. It is intended to be used in the home, and hospital/ institutional settings. The Care Cycle connect application is intended to supplement and not replace any part of the current device monitoring procedures.
The Care Cycle Connect application is an accessory to a continuous ventilator (product code MOD). Care Cycle Connect is intended for use with the Trilogy Series of Ventilators cleared by the US FDA under K083526, K093416, K093905, and K111610. Care Cycle Connect (CCC) is a mobile software application designed to provide features and functions related to respiratory care in the home, hospital and institutional healthcare settings. The application provides the caregiver remote patient monitoring and alarm surveillance. The CCC application has been designed with two users in mind, the caregiver and the clinician. The functionality of the application is tailored to the different needs of these users and is configured when the application is installed. At the initial start-up of the application, users are asked to choose either careqiver (for patients and their in-home caregivers) or clinician mode. Functionality is based on the configuration selected. Once this choice is made, users cannot switch back and forth between the two configurations. The primary users expected to interact with Care Cycle Connect in the context of patient care in the home (the main use scenario) are caregivers and respiratory therapists (clinicians). CCC may also be used if the patient is in a hospital or institutional environment (sub-acute care facility). Caregivers are not expected to use CCC in a hospital or institutional setting. Care Cycle Connect provides constant feedback to the caregiver while the app is connected to the ventilator. This feedback is displayed via the Manometer Display feature within the application. This constant display provides data on the patient's use of the ventilator, ensuring that the ventilator is providing therapy. Care Cycle Connect will also provide educational information on the use of the ventilator to the caregiver or clinician, independent of being connected to the ventilator. The respiratory therapist will use the app when connected to a patient ventilator while on a home visit to gather ventilator data. It provides an interface for keeping patient information. When the app is not connected to the patient ventilator, the clinician can review stored data, such as appointments, journal, and vent check records. In the hospital or institutional environment. CCC may be used by clinicians to schedule and perform vent checks, which would be completed in the patient's room. Care Cycle Connect is an application that can be loaded onto an Apple device (iPad) that uses iOS 8.0 or more recent. The application relies on a Bluetooth Class 1 radio connection to a Trilogy ventilator. With the exception of low level communication protocol information (i.e., handshake connection), the Trilogy device does not accept any data, commands, or controls from the CCC Application. The Trilogy device functionality is not changed in any manner by connecting to the CCC Application. The Trilogy device simply sends information to the CCC Application on a periodic basis.
The provided text describes the acceptance criteria and study information for the "Care Cycle Connect" software application.
1. Table of Acceptance Criteria and Reported Device Performance
| Acceptance Criteria Category | Specific Criteria (from standards & testing) | Reported Device Performance |
|---|---|---|
| Software Verification & Validation | Adherence to IEC 62304:2006 (Medical Device Software Life Cycle Processes) for "moderate" level of concern software. | Software verification and validation testing was conducted and documentation provided. Testing confirmed all product requirements met with passing results. |
| Usability Engineering | Compliance with IEC 60601-1-6:2010 + A1:2013 (General requirements for basic safety and essential performance – Usability) and IEC 62366:2007 + A1:2014 (Application of Usability Engineering to Medical Devices). Usability testing completed. | Usability testing was completed on the Care Cycle Connect application. (Specific performance metrics not detailed, but implied successful completion). |
| Alarm Systems | Compliance with IEC 60601-1-8:2006 + Am.1:2012 (General requirements, tests and guidance for alarm systems in medical electrical equipment and medical electrical systems). Alarm functionality designed accordingly. | Alarm functionality of the Care Cycle Connect application was designed in accordance with IEC 60601-1-8. |
| Home Healthcare Environment | Compliance with IEC 60601-1-11:2015 (Requirements for medical electrical equipment and medical electrical systems used in the home healthcare environment). Risk assessment per ISO 14971 for home use. | Home use of the Care Cycle Connect application has been evaluated through the Risk Assessment process per ISO 14971. Testing was completed in accordance with IEC 60601-1-11:2015. |
| Feature Functionality | Device pairing and connectivity. Clinician and caregiver login. Clinician patient information, journal entries, "vent check" records. Caregiver appointment and journal entries. Help assistant information. Legibility of Alarm and Information Signals. | Complete system level testing verified these functionalities. |
| Cybersecurity | Assessment per FDA guidance "Content of Premarket Submissions for Management of Cybersecurity in Medical Devices" (October 2, 2014). | A Cybersecurity Hazard Analysis (Security Risk Assessment) was performed. All identified risks were controlled to acceptable levels. |
| Risk Management | Evaluation through Risk Assessment process per ISO 14971. | Both caregiver and clinician uses, and home use, have been evaluated through Risk Assessment process per ISO 14971. |
| Essential Performance | No features or functions defined as essential performance that, if absent or degraded, would render the Trilogy device unsuitable. | Assessment confirmed no essential performance features. |
2. Sample Size Used for the Test Set and Data Provenance
The document does not explicitly state the numerical sample size for the test set used in "Software Verification and Validation Testing" or "Usability Testing." It mentions "complete system level testing" and "usability testing was completed," implying a sufficient set of tests were performed.
- Data Provenance: Not explicitly stated as retrospective or prospective patient data. The testing appears to be primarily laboratory/bench testing and simulated use, as it focuses on software verification, validation, and usability with the device itself, rather than clinical patient outcomes. The origin is implicitly related to the manufacturer's testing facilities (Respironics Inc., USA).
3. Number of Experts Used to Establish the Ground Truth for the Test Set and Their Qualifications
The document does not specify the number of experts or their qualifications used to establish ground truth for the test set. The ground truth for the testing described seems to be based on compliance with international standards (IEC, ISO) and the device's functional design specifications, rather than expert consensus on medical images or diagnoses.
4. Adjudication Method for the Test Set
The document does not mention an adjudication method for the test set. The testing described focuses on discrete pass/fail criteria against engineering requirements and established standards.
5. Multi-Reader Multi-Case (MRMC) Comparative Effectiveness Study
No. The document explicitly states: "Clinical tests were not required to demonstrate the substantial equivalence of Care Cycle Connect. Product functionality has been adequately assessed by non-clinical tests." Therefore, an MRMC comparative effectiveness study was not performed.
6. Standalone Performance (Algorithm Only without Human-in-the-Loop Performance)
Yes, a standalone performance assessment was effectively done. The "Software Verification and Validation Testing" and "Non-Clinical Tests" describe the evaluation of the Care Cycle Connect application's functionality, adherence to software life cycle processes, alarm system compliance, and usability independent of a clinical human-in-the-loop study. These tests evaluate the algorithm's (software's) performance against its design requirements and relevant standards.
7. Type of Ground Truth Used
The ground truth used for the testing of Care Cycle Connect appears to be:
- Compliance with International Standards: e.g., IEC 62304, IEC 60601-1-6, IEC 60601-1-8, IEC 60601-1-11, IEC 62366, ISO 14971.
- Product Requirements/Design Specifications: The software was tested against "product requirements" and various listed functionalities (device pairing, login, information display, alarm signals, etc.).
- Guidance Documents: Adherence to FDA guidance documents (e.g., for software, human factors, mobile medical apps, cybersecurity, wireless technology, home use devices).
Essentially, the "ground truth" is a combination of regulatory compliance, engineering specifications, and validated functional behavior.
8. Sample size for the Training Set
Not applicable. The document describes the verification and validation of a software application for remote monitoring and data display for a medical device. It does not mention any machine learning or AI components that would require a dedicated "training set." The software appears to be rule-based or deterministic, rather than data-driven in a way that requires a training set.
9. How the Ground Truth for the Training Set was Established
Not applicable, as there is no mention of a training set for machine learning/AI.
Ask a specific question about this device
(88 days)
MOD
The Bernoulli MS software is intended to be used on a central monitoring station on patients using supported devices in a hospital or hospital type environment. It is used to provide a secondary display of ventilator, respiratory monitor, IV infusion (including PCA) pump, feeding pump, and/or multi parameter monitor data (ECG, respiratory rate, pulse oximetry, ETCO2, blood pressure, cardiac output, temperature and associated derived outputs) to the central station, and to provide remote monitoring and alarm surveillance. The Bernoulli MS is intended to supplement and not replace any part of the current device monitoring procedures.
Not Found
This appears to be a 510(k) clearance letter from the FDA for the Bernoulli™ Management System, and not a study describing acceptance criteria and device performance. The letter states that the device is substantially equivalent to legally marketed predicate devices and outlines general regulatory information.
Therefore, the requested information about acceptance criteria, device performance, study design, sample sizes, ground truth establishment, expert qualifications, adjudication methods, and MRMC/standalone study results is not present in the provided document.
The document specifically states: "We have reviewed your Section 510(k) premarket notification of intent to market the device referenced above and have determined the device is substantially equivalent...". This indicates a regulatory review based on equivalence to existing devices, not a detailed performance study where specific acceptance criteria and their fulfillment are described.
Ask a specific question about this device
(84 days)
MOD
The VentLink system is intended for use with specified or validated ventilator devices to obtain ventilator data and provide the user with the ability to display, store, print and otherwise process that data to other interfaced systems. VentLink is not connected directly to any patient nor does the VentLink device remotely control any connected ventilator device.
The VentLink system is intended for use in any clinical setting while interfaced to any specified or validated ventilator device. The VentLink system is intended to provide a secondary display of data received from an interfaced ventilator device to appropriately configured workstations and wireless laptop computers and to be made available to any interfaced hospital information system (HIS).
The VentLink system is a device composed of MediServe Information Systems' proprietary software and various off-the-shelf hardware, operating system software and third-party proprietary software intended to be interfaced with specified or validated ventilator devices to allow authorized users to move ventilator patient data to wireless laptops and workstations configured with MediServe Information Systems' MediLinks data storage software. Additionally, the VentLink system allows users to move ventilator data to the user's hospital information system (HIS). It is intended to be used in an environmentally controlled hospital and hospital type environment.
The VentLink system software allows users to:
- Enable or disable automatic device data collection.
- Set a default data collection time interval.
- Specify how long unauthenticated data will be retained.
- Alert the user when data collection is paused.
After user review and validation of results received via the Ethernet the results are stored short-term on the VentLink system and transmitted to MediLinks for acceptance and storage.
Specified or validated ventilator devices are interfaced and added to the VentLink system through VentLink's devices' dictionary.
The VentLink system does not alter or change any patient data, but does allow the user to display the received patient data.
VentLink will function within a wide array of connectivity modules which allow VentLink to adapt to the evolving connectivity technology.
VentLink also has advanced device-management functionality.
The provided document is a 510(k) Premarket Notification for the VentLink™ System, submitted to the FDA in 2005. This type of submission focuses on demonstrating substantial equivalence to a predicate device rather than comprehensive clinical performance studies with detailed acceptance criteria and statistical analyses as would be expected for a novel device or a PMA submission.
Therefore, much of the requested information regarding detailed acceptance criteria, specific study designs (like MRMC), sample sizes, and ground truth establishment, which are typical for clinical performance evaluations, is not present in this 510(k) summary.
Here's an attempt to answer the questions based only on the provided text, highlighting where information is absent:
1. Table of Acceptance Criteria and Reported Device Performance
The document does not explicitly state quantitative "acceptance criteria" or provide a table of "reported device performance" in a manner typical of a clinical efficacy study. Instead, the "acceptance criteria" for this 510(k) submission are implicitly tied to demonstrating substantial equivalence to the predicate device, the Ventnet system (K963633).
The key "performance" objective stated is:
- The VentLink system is "Safe, and As effective as the predicate device, the Ventnet system, and Performs as well or better than the predicate device, the Ventnet system."
The "reported device performance" is framed as the successful completion of verification and validation testing, confirming it meets its stated intended use and functions similarly to the predicate.
| Acceptance Criteria Category | Specific Criteria (Implicit for 510(k) equivalence) | Reported Device Performance (from text) |
|---|---|---|
| Safety | Device does not introduce new safety concerns compared to predicate. | "The nonclinical testing... documents that the VentLink system is Safe." Implicitly, this is demonstrated through addressing identified hazards, EMI certifications for off-the-shelf components, and functional testing. |
| Effectiveness/Functionality | Functions as intended: collects, displays, stores, and processes ventilator data. | "Alpha validation testing included testing of all functionality and confirmation that all identified hazards have been adequately addressed by software functionality, the user interface or documentation." "Validation testing fully documents that specified ventilator device's data is transmitted from the ventilator through the VentLink system into the submitter's MediLinks device with user control of data review and acceptance." "No changes were made to transmitted ventilator data." |
| Substantial Equivalence | Similar indications for use and technological characteristics to the predicate. | "The VentLink system has the same indications for use as the Ventnet system, K963633." "The VentLink system has the same technological characteristics as the Ventnet system." Differences noted are evolutionary and do not change equivalence. |
| Clinical Performance | (Not applicable, since no clinical claims or studies were required/submitted) | The submitter notes, "The predicate device, Ventnet system, did not provide or reference any clinical tests submitted in compliance with 807.92(b)(2), therefore the submitter believes such clinical testing is not appropriate or required by FDA and has not made or provided any summary of such testing." |
2. Sample Size Used for the Test Set and the Data Provenance
The document does not specify a numerical "sample size" for a test set in a statistical or clinical sense. The testing described is "Alpha validation testing" and "beta testing environments."
- Test Set (Alpha Validation): Refers to testing all functionality and hazard mitigation. The number of test cases or specific data points is not mentioned.
- Test Set (Beta Testing): Involves user validation of each specified ventilator system "PRIOR to implementation." The number of "specified ventilator systems" or "users" is not quantified.
- Data Provenance: The nature of the data (e.g., patient data, simulated data) used during these validation tests is not explicitly stated, nor is the country of origin. Given the function of the device (data management from ventilators), it would likely involve ventilator data, but its source and context are not detailed. These are non-clinical tests.
3. Number of Experts Used to Establish the Ground Truth for the Test Set and the Qualifications of Those Experts
This information is not provided. The document describes "user review and validation of results" and validation by "users in beta testing environments," but it does not specify the number or qualifications of these "users" or "experts" involved in establishing ground truth. For a data management system that does not alter data, the "ground truth" would likely be the original data from the ventilator.
4. Adjudication Method for the Test Set
This information is not provided. The testing described is functional validation rather than a clinical interpretation task requiring adjudication of expert opinions.
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, an MRMC comparative effectiveness study was not done. This type of study is specifically designed for image interpretation or diagnostic aid devices. The VentLink system is a data management system for ventilators, not an AI or diagnostic aid that "improves" human readers' performance.
6. If a Standalone (i.e. algorithm only without human-in-the-loop performance) Was Done
The VentLink system is primarily an algorithm/software system for data handling. Its performance, as described, is inherently "standalone" in how it processes data. However, it's explicitly designed to integrate with "MediLinks," which "provides the user interface to the VentLink service." So, while the data collection service is algorithmic, the overall system involves human interaction for configuration, review, and authentication. The testing described (alpha and beta validation) evaluates this combined system functionality rather than a purely isolated "algorithm only" performance devoid of its intended human-in-the-loop environment. The device "does not alter or change any patient data, but does allow the user to display the received patient data," indicating its role as a data conduit and display, not an independent decision-making algorithm.
7. The Type of Ground Truth Used (expert consensus, pathology, outcomes data, etc.)
The document does not explicitly state the "type of ground truth" in a clinical sense. For this device, which focuses on transmitting ventilator data accurately and without alteration, the "ground truth" for its validation would be the original, unaltered data output directly from the ventilator device. The testing confirmed that this data was correctly transmitted, displayed, and stored.
8. The Sample Size for the Training Set
The document refers to verification and validation testing, but it does not describe any "training set." This is because the VentLink system is a data management interface software, not a machine learning or AI model that requires a training set for model development.
9. How the Ground Truth for the Training Set Was Established
As no "training set" is mentioned or implied for this device, information on how its ground truth was established is not applicable and therefore not provided.
Ask a specific question about this device
(57 days)
MOD
IISIS is intended to be used on a central monitoring station on mechanically ventilated patients in a hospital or hospital type environment. It is used to provide a secondary display of the ventilator data to the central station and to provide remote monitoring and alarm surveillance. IISIS is intended to supplement and not replace any part of the current device monitoring procedures.
IISIS software provides continuous display of ventilator data at a central station and remote workstations. IISIS utilizes wireless technology to interface with most critical care and home care ventilators that have RS-232, Ethernet, or nurse call. IISIS is accessed and displays ventilator data and waveforms through web-based technology. IISIS provides real-time alarm annunciation, displays and stores ventilator settings, parameters, and ventilator waveforms as a secondary tool to the primary ventilator alarm and data display.
The provided document describes the IISIS software, an accessory to continuous ventilators, and its 510(k) premarket notification. The focus of the document is on establishing substantial equivalence to a predicate device, the Bernoulli Ventilator Management System, rather than on detailed performance metrics as would typically be found in direct medical device performance studies.
Therefore, many of the requested categories for acceptance criteria and study details cannot be fully satisfied from this document alone because it pertains to software validation rather than a clinical effectiveness study.
Acceptance Criteria and Reported Device Performance
| Acceptance Criteria (Functional Requirements) | Reported Device Performance |
|---|---|
| Performs all input functions according to the functional requirements specified in the Software Requirements Specification. | Validation testing was provided that confirms that IISIS V 1.0 performs all input functions. |
| Performs all output functions according to the functional requirements specified in the Software Requirements Specification. | Validation testing was provided that confirms that IISIS V 1.0 performs all output functions. |
| Performs all required actions (e.g., real-time alarm annunciation, displaying and storing ventilator settings, parameters, and waveforms) according to the functional requirements specified in the Software Requirements Specification and user requirements. | Validation testing was provided that confirms that IISIS V 1.0 performs all required actions. This includes providing continuous display of ventilator data at a central station and remote workstations, utilizing wireless technology to interface with critical care and home care ventilators, accessing and displaying ventilator data and waveforms through web-based technology, providing real-time alarm annunciation, and displaying and storing ventilator settings, parameters, and waveforms. The device is confirmed to perform to specifications, Federal Regulations, and User Requirements. The Validation and Verification Process has been followed in accordance with software development practices. |
| Does not introduce new potential safety risks. | The IISIS V 1.0 does not result in any new potential safety risks, as determined by a Hazard Analysis where potential hazards were identified and controlled (by designing controls, introducing protective measures, and/or warning users). |
| Performs in accordance with its intended use. | The IISIS V 1.0 performs in accordance with its intended use (as a secondary display of ventilator data for central monitoring and remote surveillance). |
| Is substantially equivalent to the predicate device (Bernoulli Ventilator Management System). | The IISIS V 1.0 is considered substantially equivalent to the Bernoulli Ventilator Management System (K011861) in terms of features and specifications, and performs similarly for providing secondary display of ventilator data and remote monitoring/alarm surveillance. |
Study Details (as inferable from the document):
-
Sample size used for the test set and the data provenance:
- The document mentions "Validation testing was provided" for software functions. This refers to software verification and validation activities rather than testing with patient data. It does not specify a "test set" in the context of clinical data or patient samples. Therefore, not applicable for patient/clinical data.
- Data Provenance: Not specified, as it's a software validation claim.
-
Number of experts used to establish the ground truth for the test set and the qualifications of those experts:
- Not applicable. This information is for software functional validation, not clinical ground truth establishment. Software requirements are established by a team (likely including subject matter experts) and validated against those requirements.
-
Adjudication method (e.g., 2+1, 3+1, none) for the test set:
- Not applicable. This refers to software functional validation, not clinical case adjudication.
-
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 document describes a software system as an accessory for continuous ventilators that provides a secondary display and alarm annunciation. It is not an AI-assisted diagnostic tool for which MRMC studies would typically be conducted.
-
If a standalone (i.e., algorithm only without human-in-the-loop performance) was done:
- The device, IISIS V 1.0, is inherently a "standalone" software system in the sense that it operates independently to collect, display, and annunciate ventilator data. Its function is to supplement existing procedures and provide secondary information, not to make diagnostic or therapeutic decisions on its own. While it provides "real-time alarm annunciation," it explicitly states it is "intended to supplement and not replace any part of the current device monitoring procedures." Therefore, its performance is evaluated in its functional display and alarm capabilities. The "validation testing" confirms the algorithm's performance of its intended functions.
-
The type of ground truth used (expert consensus, pathology, outcomes data, etc.):
- Functional Requirements and Specifications. The "ground truth" for the validation of IISIS V 1.0 is adherence to its "functional requirements specified in the Software Requirements Specification" and "User Requirements." This isn't a clinical ground truth but a validation against predefined software behavior.
-
The sample size for the training set:
- Not applicable. The document describes a software system that displays data and annunciates alarms, not a machine learning or AI model that requires a training set.
-
How the ground truth for the training set was established:
- Not applicable. No training set is mentioned or implied, as it's not an AI/ML device.
Ask a specific question about this device
(77 days)
MOD
Model 3500/01 is a replacement part for the ventilator. The Inlet Filter removes particles of 0.3 micron size (or larger) from entering the ventilator. It is a HEPA grade particulate filter for use with the NPB Achieva or LP 10 ventilators. The filter is in the gas flow pathway. As a HEPA particulate filter for the inlet air to be supplied to the patient from the ventilator.
Model 3500/01 is a replacement part for the ventilator. The Inlet Filter removes particles of 0.3 micron size (or larger) from entering the ventilator. It is a HEPA grade particulate filter for the NPB Achieva or LP 10 ventilators, which is in the gas flow pathway. Screw-in cartridge to fit the inlet air filter port of the ventilator housing.
The Air Safety HEPA Model 3500 Filter is an inlet filter designed to remove particles of 0.3 micron size or larger from entering ventilators, specifically the NPB Achieva and LP 10 models. It is a HEPA grade particulate filter.
1. Table of Acceptance Criteria and Reported Device Performance:
| Attribute | Acceptance Criteria | Reported Device Performance |
|---|---|---|
| Resistance to flow | ≤ 0.9 cm H2O @ 40 Lpm | ≤ 0.9 cm H2O @ 40 Lpm |
| ≤ 1.25 cm H2O @ 60 Lpm | ≤ 1.25 cm H2O @ 60 Lpm | |
| HEPA – particulate filtration efficiency (retention) | ≥ 99.97% of 0.3 micron DOP particle at 60 Lpm | > 99.97% of 0.3 micron DOP particle at 60 Lpm |
| ≥ 99.97% of 0.3 micron DOP particle at 100 Lpm | > 99.97% of 0.3 micron DOP particle at 100 Lpm |
2. Sample size used for the test set and the data provenance:
The document describes performance testing based on "standard DOP aerosol testing methods" and references specific standards (DOE 3025-99, DOE 3020-97, and ASTM D2986 - DOP). However, it does not specify the sample size for the test set used to generate the reported performance data. The data provenance is implied to be from internal testing conducted by Air Safety Ltd. in England. It's a prospective testing for the device's performance characteristics.
3. Number of experts used to establish the ground truth for the test set and the qualifications of those experts:
This device is a physical filter, and its performance (filtration efficiency and resistance to flow) is assessed through objective laboratory testing using recognized standards. Therefore, the concept of "experts establishing ground truth" in the way it applies to image analysis or clinical diagnoses is not relevant in this context. The ground truth is the result of the objective measurements obtained through the specified test methods.
4. Adjudication method for the test set:
Not applicable. As described above, the performance is determined by objective, standardized measurements, not through expert judgment or consensus.
5. If a multi-reader multi-case (MRMC) comparative effectiveness study was done:
No, an MRMC comparative effectiveness study was not done. This type of study is typically used for diagnostic or imaging devices where human interpretation is involved. This device's performance is quantifiable through laboratory testing.
6. If a standalone (i.e. algorithm only without human-in-the loop performance) was done:
Yes, the performance testing of the HEPA filter can be considered a standalone assessment. The filtration efficiency and resistance to flow are measured attributes of the device itself, independent of human interaction in its primary function (filtering air).
7. The type of ground truth used:
The ground truth used for this device's performance assessment is based on objective measurements obtained through standardized laboratory protocols. Specifically, it involves:
- DOP aerosol testing for particulate filtration efficiency (retention).
- Measurement of resistance to flow at specified flow rates.
These are established engineering and scientific methods to quantify the physical properties of filters.
8. The sample size for the training set:
Not applicable. This device is a physical product, not an algorithmic model that requires a training set.
9. How the ground truth for the training set was established:
Not applicable, as there is no training set for this type of device.
Ask a specific question about this device
(315 days)
MOD
Impact Universal Single-Limb Ventilator Circuit is intended for use in conjunction with ventilators having a single-limb circuit interface. The ventilator circuits are used as a means by which to transfer breathing gases from a ventilator to a patient (inhalation) and from a patient to atmosphere (exhalation). The device is intended for use with adults and medium to large pediatric patients.
The Impact, Universal Single-Limb, Portable Ventilator Circuit is comprised of disposable connectors, tubing and exhalation valve.
The provided text describes the Impact, Universal Single-Limb, Portable Ventilator Circuit and its substantial equivalence to a predicate device. However, it does not contain information about "acceptance criteria" and "device performance" in the format of a table with numerical values, nor does it detail a study that explicitly demonstrates the device meets specific acceptance criteria in the way typically found for AI/ML-based medical devices.
The document focuses on demonstrating substantial equivalence for a physical medical device (a ventilator circuit). This involves showing that the new device has the same intended use and performance attributes as a legally marketed predicate device. The performance attributes are evaluated through biological qualification safety tests and industry-recognized test methods.
Therefore, many of the requested elements for an AI/ML device study are not applicable or not present in this document. I will extract the information that is available and indicate where the requested information is not provided.
1. A table of acceptance criteria and the reported device performance
The document does not provide a table of acceptance criteria with numerical performance metrics for the device. Instead, it refers to general compliance with safety and performance standards.
| Acceptance Criteria Category | Reported Device Performance |
|---|---|
| Material Safety | Evaluated through biological qualification safety tests as outlined in: ISO 10993 Part 1 "Biological Evaluation of Medical Devices"ISO 10993 Part 5 "Tests for in vitro cytotoxicity"ISO 10993 Part 12 "Sample Preparation and Reference Materials"USP 25 "Biological Reactivity Tests, in vivo -Classification of Plastics"21 CFR 177.1350 "Ethylene-Vinyl Acetate Copolymers" |
| Functional Performance | Tested in accordance with industry recognized test methods contained in ASTM F-1100, Table 2, and found to be acceptable for its intended use. Performance attributes are stated to be the same as the predicate device (Allegiance Healthcare Corporation, Catalog Number 1755, Airlife™ Universal Portable Volume Ventilator Circuit). |
2. Sample size used for the test set and the data provenance
The document does not specify a "test set" in the context of clinical data for an AI/ML device. The testing described involves material and functional performance of the device itself, not a dataset for an algorithm. Therefore, information on sample size for a test set, country of origin, or retrospective/prospective nature is not applicable.
3. Number of experts used to establish the ground truth for the test set and the qualifications of those experts
Not applicable. "Ground truth" for a physical device's performance is typically established through adherence to engineering specifications and performance standards, not expert consensus on data.
4. Adjudication method for the test set
Not applicable. There is no "test set" or adjudication process described as would be relevant for an AI/ML device's output.
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
Not applicable. This device is a physical ventilator circuit, not an AI/ML diagnostic or assistive tool. Therefore, MRMC studies and human reader improvement with AI are not relevant.
6. If a standalone (i.e. algorithm only without human-in-the-loop performance) was done
Not applicable. This is not an algorithm-based device.
7. The type of ground truth used
The "ground truth" equivalent for this device is based on compliance with established international and national standards for medical device materials and functional performance. This includes:
- Biological qualification safety tests (ISO 10993, USP 25, 21 CFR 177.1350)
- Industry-recognized test methods (ASTM F-1100, Table 2)
- Demonstration of performance attributes being the same as the predicate device.
8. The sample size for the training set
Not applicable. This device does not have a "training set" as it is not an AI/ML model.
9. How the ground truth for the training set was established
Not applicable.
Ask a specific question about this device
(625 days)
MOD
Ask a specific question about this device
(145 days)
MOD
The Bernoulli VMS software is intended to be used on a central monitoring station on mechanically ventilated patients in a hospital or hospital type environment. It is used to provide a secondary display of the ventilator data to the central station, and to provide remote monitoring and alarm surveillance. The Bernoulli VMS is intended to supplement and not replace any part of the current device monitoring procedures.
Bernoulli™ Ventilator Management System
The provided text describes a 510(k) clearance for the Bernoulli™ Ventilator Management System but does not contain information about the acceptance criteria, reported device performance, or details of a study demonstrating such performance. It is a regulatory clearance letter and an "Indications for Use Statement".
Therefore, I cannot provide the requested information.
Ask a specific question about this device
(96 days)
MOD
The VentNet system consists of a PC based Central Monitoring Station and either a hardwire or wireless communication means allowing the remote monitoring of up to 24 continuous mechanical ventilators. VentNet further has a means of communication via paging system for the remote notification of alarms or changes in ventilator status. The VentNet automatically records ventifator setting changes and alarm events with patient physiological data from the monitored ventilators. The user may then review this information in a ventilator flowsheet format or print it as pre-formatted reports.
VentNet's intended use is to supplement the operation of dispersed or remotely located mechanical ventilators. VentNet allows the remote monitoring of multiple ventilators from a central station. VentNet displays ventilator settings, ventilator alarm status and physiological patient information as communicated from the monitored mechanical ventilator. VentNet also includes an optional feature which causes automatic notification, via paging system to defined users of certain ventilator alarms. VentNet is not intended to replace on-hand competent medical staff in monitoring for, or responding to ventilator alarms but is intended to support that staff by notifying other respiratory care staff or ventilator specialists in the event of certain alarm conditions.
VentNet's secondary intended use is the automation of some of the record keeping and reporting functions performed during mechanical ventilation.
The VentNet system consists of a PC based Central Monitoring Station and either a hardwire or wireless communication means allowing the remote monitoring of up to 24 continuous mechanical ventilators. VentNet further has a means of communication via paging system for the remote notification of alarms or changes in ventilator status. The VentNet automatically records ventifator setting changes and alarm events with patient physiological data from the monitored ventilators. The user may then review this information in a ventilator flowsheet format or print it as pre-formatted reports.
The provided document is a 510(k) Premarket Notification summary for the VentNet Central Monitoring Station. It focuses on demonstrating substantial equivalence to predicate devices rather than proving the device meets specific acceptance criteria through a dedicated study.
Therefore, the requested information regarding acceptance criteria, reported device performance, sample sizes, data provenance, expert qualifications, adjudication methods, MRMC studies, standalone performance, and ground truth establishment for a clinical study is not available within this document. The document primarily describes the device's technical specifications and compares them to predicate devices to establish substantial equivalence based on non-clinical performance data.
Here's an analysis of the information that is available, based on the prompt's request:
1. A table of acceptance criteria and the reported device performance:
The document does not explicitly present a "table of acceptance criteria and reported device performance" in the way a clinical study would for an AI/medical device. Instead, it lists "Product and Technical Specifications" and "Device Claims" which implicitly serve as performance goals, and then leverages a comparison matrix to predicate devices to argue equivalence. No quantitative "reported device performance" against these specifications from a formal study is detailed.
However, we can infer some "acceptance criteria" from the "Device Claims" and "Product and Technical Specifications" sections. The "reported device performance" is then implicitly demonstrated by stating these specifications and implying they are met, as part of the overall argument for substantial equivalence via non-clinical testing.
| Acceptance Criteria (Inferred from Claims/Specifications) | Reported Device Performance (As stated in the document) |
|---|---|
| Monitoring Capacity (Wireless) | Up to 24 continuous mechanical ventilators |
| Monitoring Capacity (Hardwire) | Up to 16 continuous mechanical ventilators |
| Remote Monitoring Features | Displays ventilator settings, alarm status, and physiological patient information |
| User Interface | Uses graphical user interface conventions, compatible with mouse or touchscreen for ease of learning and operation |
| Ventilator Compatibility | Compatible with Nellcor Puritan-Bennett 7200 Series Ventilator (host port or DCI) and future compatible ventilators |
| Automatic Record Keeping | Automatically records ventilator settings and alarm events (up to 1000 records) with time and date stamps; records physiological patient information with alarm events. |
| Reporting Features | Predefined report formats; archiving data; exporting data to third-party information systems. |
| Alarm Status Display | Color-coded software buttons for each ventilator, with labels for patient ID and location; ability to investigate specific active alarm codes. |
| Paging System Integration | Optional configuration with paging systems for remote notification of certain alarm conditions; user-definable alarm message paths and notification conditions (primary/secondary message paths, individual ventilator/alarm conditions). |
| Security | Passcode protection to restrict access to functions that interrupt monitoring or cause data loss. |
| Central Station Electrical | 115 Vac, 60 Hz, 5 A (maximum) or 230 Vac, 50 Hz, 2.6 A (maximum) |
| Remote Radio Transceiver Defibrillation Protection | Not damaged by defibrillation, returns to normal operation within 15 seconds. |
| Computer Hardware | Pentium-100 MHz, 16 MB RAM, 1 GB Hard Drive, 3.5-inch Floppy Drive, Hercules Dynamite Video Board, Serial Mouse, 101-key Keyboard |
| Monitor Specifications | 15 inch or 17 inch diagonal screen, Touchscreen hardware installed, 800 x 600 pixel resolution, 256 colors |
| Operating Temperature | +10° C to +35° C (+50° F to +95° F) |
| Operating Relative Humidity | 30% RH to 80% RH (noncondensing) |
| Radio Transceiver Frequencies | Central Transceiver: 902-928 MHz; Remote Transceiver: 902-928 MHz |
| Radio Transceiver Output Power | Central Transceiver: +20 dBm (100 mW) minimum; Remote Transceiver: +15 dBm nominal, ±2.0 dB |
| Radio Transceiver FCC Compliance | Spectrum Usage: Spread spectrum (IAW FCC Par. 15.247) |
| Printer Compatibility | HPGL/2 and PCL5 compatible, minimum 2 MB printer memory. |
2. Sample size used for the test set and the data provenance:
- Sample Size for Test Set: Not applicable. The document describes "non-clinical performance data review" based on testing for EMI, software verification/validation, environmental testing, and stress testing. This implies technical testing, not a study with a patient "test set."
- Data Provenance: Not applicable for a clinical test set. The data provenance mentioned is related to engineering and software testing.
3. Number of experts used to establish the ground truth for the test set and the qualifications of those experts:
- Not applicable. There is no mention of a test set with an associated ground truth established by experts. The device's function is data presentation and alarm relay, not diagnostic interpretation.
4. Adjudication method for the test set:
- Not applicable. No clinical test set.
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 is not an AI diagnostic device. It's a central monitoring station for ventilators. No MRMC study was conducted or mentioned.
6. If a standalone (i.e. algorithm only without human-in-the-loop performance) was done:
- The document implies standalone system performance was evaluated through "software verification and validation of both the system software performance as well as the operating system software performance, environmental testing and stress testing both at the integration level and the system level." However, this refers to the system's technical functionality, not a standalone diagnostic algorithm's performance. The device is explicitly designed to support human staff, not replace them.
7. The type of ground truth used (expert consensus, pathology, outcomes data, etc.):
- Not applicable. The performance data reviewed involved validation of technical specifications and software functionality, not clinical diagnostic accuracy against a ground truth.
8. The sample size for the training set:
- Not applicable. This device is not an AI/machine learning device that would require a "training set" for model development.
9. How the ground truth for the training set was established:
- Not applicable. As above, no training set is relevant for this type of device.
Study Proving Acceptance Criteria:
The document states: "The determination of substantial equivalence was based on an assessment of nonclinical performance data. The data includes testing for EMI compatibility and susceptability, software verification and validation of both the system software performance as well as the operating system software performance, environmental testing and stress testing both at the integration level and the system level. The conclusion drawn from a review of the data indicates that the VentNet is substantially equivalent to the predicate devices."
This statement indicates that the "study" proving the device meets its (implicitly stated) performance criteria and is "substantially equivalent" involved:
- EMI Compatibility and Susceptibility Testing: To ensure the device operates correctly in its intended electromagnetic environment without interference and is not unduly affected by external electromagnetic sources.
- Software Verification and Validation: To confirm that the software performs as designed and meets all specified technical and functional requirements. This would involve unit testing, integration testing, system testing, and potentially user acceptance testing.
- Environmental Testing: To ensure the device can withstand specified operating and storage conditions (temperature, humidity, etc.).
- Stress Testing: To evaluate the system's robustness and stability under extreme or heavy load conditions.
- Integration and System Level Testing: To confirm that all components work together correctly as a complete system.
This approach demonstrates meeting technical specifications and equivalency to predicate devices, rather than a clinical performance study with patient data and a diagnostic ground truth.
Ask a specific question about this device
Page 1 of 1