Search Results

The BD Alaris System with Guardrails Suite MX is a modular infusion pump and monitoring system for the continuous or intermittent administration of fluids to adult, pediatric, and neonatal patients through clinically accepted routes of administration: intravenous (IV), intra-arterial (IA), subcutaneous, epidural, or irrigation of fluid spaces. See Pediatric*, Neonate**, and Adult Patient Population Tables for the module-specific variations. Administered fluids include pharmaceutical drugs, red blood cells, and other blood components (platelets and fresh frozen plasma) as required for patient therapy. The BD Alaris System is an interoperable of communicating and exchanging data with compatible information technology systems.

The BD Alaris System includes the PC Unit (PCU) and one or more of the following: Pump Module, Syringe Module, End-Tidal CO2 (EtCO2) Module, Auto-ID Module, Patient-Controlled Analgesia (PCA) Module, and associated software applications. The EtCO2 Module is a capnograph that continuously monitors end-tidal carbon dioxide (EtCO2), fractional inspired carbon dioxide (FiCO2), and respiratory rate (RR).

The BD Alaris Pump Module, and the Alaris PCA Module are indicated for varying patient populations, routes of administration, and infusates.

The BD Alaris System with Guardrails Suite MX v12 is a modular infusion and monitoring system designed to provide accurate, automated infusion of a broad range of drugs and fluids, and to provide monitoring of respiratory parameters. The BD Alaris System with Guardrails Suite MX v12 has three major components:

• System Hardware: a core hardware unit with user interface (BD Alaris PC Unit or PCU) and attachable modules each with . a distinct function.
• . Guardrails Suite MX Software: software applications for support and interaction with the system hardware (BD Alaris System Manager, BD Alaris Guardrails Editor, and BD Alaris System Maintenance).
• Interoperability Software: applications for bi-directional communication between the PCU/attached modules and an . electronic medical records (EMR) system. (Care Coordination Engine, Infusion Adapter, and Calculation Services).

The PCU is the core of the BD Alaris System with Guardrails Suite MX v12 and powers, programs, and monitors the attached modules must be physically connected to the PCU to operate. The connection is made by direct attachment to a PCU or through attachment to a module that is attached to a PCU. The attachment is made inter-unit interface connectors built into both sides of the PCU and modules.

The attachable modules are dedicated to infusion of fluids/medication, patient-controlled administration of analgesics, monitoring of end-tidal carbon dioxide, and scanning identifications of patient, physician, and infusates into the system.

Each system must include a PCU. The rules for attachment of the modules are as follows:

• · The PCU is designed to operate a maximum of four infusion or monitoring modules. Modules added in excess of four are not recognized, with the exception of the Auto-ID Module that can be included as a fifth module.
• · Up to four Pump or Syringe Modules may be attached to a PCU at one time
• Only one PCA and one EtCO2 module can be included within the four attached influsion or monitoring modules, since each BD Alaris System v12 is dedicated to a single patient.
• In order to keep the PCU with attached modules well balanced when attached to a pole, it is important to distribute the . modules as evenly as possible on both sides of the PCU unit.

The PCU and attachable modules have multiple processors running embedded software. The embedded software provides various functions, such as: bootloader, user interface, networking, motor control, data processing, power control, keypad processing, and communication.

Communication occurs within the PCU or modules, and between the PCU and attached modules. Communication between the units is by direct electrical connection through the mechanical supports on each side of the PCU and modules.

The PCU with its attached modules is designed to communicate and interact with the BD Alaris System with Guardrails Suite MX v12 software applications including software for interoperability with electronic medical records (EMR) systems. Communication between the PCU and the software application is accomplished through either a direct serial connection with the PCU or through a wireless connection with the PCU. If communication is interrupted, the PCU and modules will continue to function as programmed, but clinicians will need to make changes or inputs manually.

It is important to note that interoperability of the BD Alaris System v12 does not include remote control of the BD Alaris System v12 components. The PCU and attached modules cannot be programmed remotely. Only infusion parameters can be prepopulated on the pump using interoperability and these parameters must be manually confirmed by the clinician before they are activated.

The provided FDA 510(k) summary for the BD Alaris System with Guardrails Suite MX v12 explicitly states a "Summary of Non-Clinical Testing" and "No animal data was generated", and "No clinical data was generated". Therefore, the device performance is reported from non-clinical testing.

Here's a breakdown of the requested information based on the provided document:

1. Table of Acceptance Criteria and Reported Device Performance

Ask a specific question about this device

The Alaris System with Guardrails Suite MX is intended for use in professional healthcare facilities that utilize infusion devices for the delivery of fluids, medications, blood and blood products.

The Alaris System with Guardrails Suite MX is intended to provide trained healthcare caregivers a way to automate the programming of infusion parameters, thereby decreasing the amount of manual steps necessary to enter infusion data. All data entry and validation of infusion parameters is performed by the trained healthcare professional according to a physician's order.

The Alaris System with Guardrails Suite MX is an interoperable of communicating and exchanging data accurately, effectively, securely, and consistently with different information technology systems, software applications, and networks, in various settings; and exchanging data such that the clinical or operational purpose and meaning of the data are preserved and unaltered.

The Alaris System with Guardrails Suite MX is a modular infusion pump and vital signs monitoring system intended for adult, pediatric and neonatal care that includes safety management software to help reduce medication errors. The Alaris System consists of the PC Unit and up to four detachable infusion and/or monitoring modules (channels). The Auto-ID Module can be included as a fifth module.

The Alaris System with Guardrails Suite MX is intended for use by Healthcare Professionals in facilities that utilize infusion pumps for the delivery of fluids, medications, blood and blood products using continuous or intermittent delivery through clinically acceptable routes of administration such as intravenous (IV), intra-arterial (IA), subcutaneous, epidural, enteral or irrigation of fluid spaces.

This document is a 510(k) premarket notification for the Alaris System with Guardrails Suite MX, an infusion pump system. It focuses on demonstrating substantial equivalence to previously cleared devices, particularly regarding software enhancements (v10.5).

Based on the provided document, here's a breakdown of the acceptance criteria and study information:

Acceptance Criteria and Device Performance

The document does not present quantitative "acceptance criteria" in a typical table format with specific thresholds and device performance metrics for new features. Instead, the "acceptance criteria" appear to be implicit in demonstrating substantial equivalence to predicate devices. The primary method of fulfilling this is through comprehensive software verification and validation to ensure the new software enhancements (v10.5) meet design input and safety requirements.

The core assertion is that:

• The device has the "same indications for use and intended use."
• It "applies the same operational principles."
• It has the "same design, materials, components, and performance specifications."
• Any different technological characteristics (e.g., "Detect Closed Secondary Clamp feature") "do not raise different questions of safety and effectiveness."

Reported Device Performance (Implicit):
The document states: "Software verification and validation was performed to ensure that the proposed v10.5 software enhancements meet design input and safety requirements. Software testing included verification and validation of the closed secondary clamp detection functions, input and output functions and user interface modifications. The proposed v10.5 software enhancements do not affect the indications for use/intended use or introduce any unacceptable risks. Verification and validation testing to support the v10.5 software enhancements has been completed and demonstrate that design verification testing including software verification is acceptable and design outputs conform to the design input requirements. This confirms that the Alaris System with Guardrails Suite MX with the v10.5 software enhancements meet these requirements."

Therefore, the "performance" is stated as successfully meeting design requirements and not introducing new risks, thereby maintaining the established performance and safety profile of the predicate devices.

Study Details

Here's the information extracted from the document regarding the study, where available:

1. A table of acceptance criteria and the reported device performance:
   As explained above, there isn't a direct table of quantitative acceptance criteria and reported numerical performance. The "acceptance criteria" are implied by the demonstration of substantial equivalence and successful software verification and validation, ensuring the device performs as intended and safely, similar to its predicates, without introducing new risks.

2. Sample sizes used for the test set and the data provenance (e.g., country of origin of the data, retrospective or prospective):

   • Sample Size for Test Set: Not explicitly stated. The document refers to "software testing," "design verification testing," and "software verification" but does not quantify the number of test cases, units tested, or data points. It is standard for software verification and validation to involve a battery of tests, but their specific size is not disclosed in this summary.
   • Data Provenance: Not mentioned. It's a premarket notification for a device primarily based on software modifications to an existing system, so
     • Country of Origin: Not specified, but the applicant (CareFusion 303, Inc.) is based in San Diego, CA, USA. The testing would presumably have been conducted internally or by contractors.
     • Retrospective or Prospective: Not applicable in the context of device software verification and validation. This is engineering testing (prospective in the sense of designing and executing tests for specific functionalities) rather than a clinical study involving patient data.

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):

   • Number of Experts/Qualifications: Not applicable and not mentioned. Ground truth in this context refers to the defined functional and safety requirements of the software. These are established by engineering design specifications, risk analyses, and regulatory standards, not by clinical experts reviewing data in the same way they would for a diagnostic AI. The "ground truth" for the software's performance is adherence to these established requirements.

4. Adjudication method (e.g., 2+1, 3+1, none) for the test set:

   • Adjudication Method: Not applicable. This type of software verification and validation doesn't typically involve human adjudication of "ground truth" in the way a clinical image annotation or outcome study would. Test outcomes (pass/fail) are determined by comparing actual results against expected results defined by the design specifications.

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:

   • MRMC Study: No. The document explicitly states: "This 510(k) does not include clinical data." This indicates that no human-in-the-loop study (like an MRMC) comparing human performance with and without AI assistance was conducted or submitted. The device is not an AI diagnostic tool; it's an infusion pump system with safety software.

6. If a standalone (i.e., algorithm only without human-in-the-loop performance) was done:

   • Standalone Performance: Not a "standalone" performance study in the typical sense of a diagnostic AI algorithm. However, software verification and validation testing was performed. This testing evaluates the algorithm's (software's) behavior and performance against its design specifications in a controlled environment, essentially "algorithm only" testing, without direct human interaction as part of the performance measurement. The document states: "Software verification and validation was performed to ensure that the proposed v10.5 software enhancements meet design input and safety requirements."

7. The type of ground truth used (expert consensus, pathology, outcomes data, etc.):

   • Type of Ground Truth: For software verification and validation, the "ground truth" is typically defined by design input requirements, functional specifications, and risk analyses. For example, for the "closed secondary clamp detection function," the ground truth is simply whether the system correctly detects a closed clamp and responds as specified (e.g., alarms, stops infusion). There is no "external" ground truth like pathology for this device function.

8. The sample size for the training set:

   • Training Set Sample Size: Not applicable. This document pertains to the Alaris System with Guardrails Suite MX, an infusion pump with safety software. It is not an AI/Machine Learning device that utilizes a "training set" to learn. The software's logic is deterministically programmed based on engineering and clinical requirements, not learned from data.

9. How the ground truth for the training set was established:

   • Training Set Ground Truth Establishment: Not applicable, as there is no training set for this type of device. The "ground truth" for the device's design and functionality is established through a rigorous medical device development process, including risk management, standards compliance, and clinical input for defining safety parameters, which are then encoded into the software.

Ask a specific question about this device