Search Results

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