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

The ALARIS Medical Systems, Inc., Medley" System with Medication Management System (MMS) is intended for use in today's growing professional healthcare environment for facilities that utilize infusion devices for the delivery of fluids, medications, blood and blood products.

The Medley™ System with MMS 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 Medley *** System (K950419) is a currently marketed modular infusion and monitoring system that consists of a Programming Module (PM) and attachable/detachable modules. Current infusion modules available are a Pump Module (K950419) and a Syringe Module (K023264). Monitoring modules currently include Pulse Oximetry (SpO2) using Nellcor (K022677) and Masimo (K010966) technology.

This traditional 510(k) Premarket Notification is being submitted to assist our customers in reducing the number of manual steps needed to program an infusion by allowing wireless communication capability to the currently marketed device, the Medley" Medication Safety System (Medley System) K950419. This Medication Management System (MMS) adds communication capability to the Medley" System thereby providing our customers with a "safety net" at the bedside to help reduce the number of programming errors at the point of care. This product will be called the Medley System with MMS.

As with the predicate device (B. Braun Medical Inc., Horizon™ Outlook with DoseCom™) this submission adds wireless communication to a server and to an existing infusion device. The Medley System was originally cleared with the capability of wired or wireless communication to include receiving infusion protocol information, uploading/downloading system configuration information and reporting infusion or system status. However, this capability was not well defined and did not include communication with a Server. It was also not clear about the local retrieval of data using optical laser scanning (bar-coding) or RF detection of information contained in documents, labels, RF ID Chips, etc. Adding MMS to the Medley System is simply an expansion of the original 510(k) indications for use for the Medley System. This submission will allow the Medley System to transmit and receive messages with the ALARIS® Server which in turn allows communication capability with external devices, including personal computers, Personal Digital Assistants (PDA's), hospital monitoring systems and Hospital Information Management Systems (HIMS).

The provided text is a 510(k) Premarket Notification for the ALARIS Medical Systems, Inc. Medley System with MMS. It describes the device, its intended use, and its substantial equivalence to a predicate device. However, it does not contain detailed information about specific acceptance criteria or a study proving the device meets those criteria, especially in the context of typical AI/ML device evaluations.

Here's a breakdown based on the information provided and what is missing:

1. A table of acceptance criteria and the reported device performance

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

• Sample Size: Not specified. The document states "performance data" was used but doesn't detail the nature or size of the dataset.
• Data Provenance: Not specified.

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: Not applicable. This device is an infusion pump system with communication capabilities, not an AI/ML diagnostic or prognostic device that typically requires expert-established ground truth for performance evaluation.
• Qualifications of Experts: Not applicable. The "ground truth" for this type of device would likely involve functional testing against specifications and comparison to the predicate device's operational characteristics, rather than expert interpretation of medical images or patient data.

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

• Adjudication Method: Not applicable. As noted above, this is not an AI/ML diagnostic device requiring expert 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

• MRMC Study: No. An MRMC study is typically for evaluating the impact of AI assistance on human reader performance in diagnostic tasks. This device is an infusion pump system, which does not involve "human readers" in this context.

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

• Standalone Performance: The performance data assessed the device's ability to "meet specified requirements" and be "substantially equivalent to the predicate device." This implies an evaluation of the system's functionalities, including its communication capabilities and automation features, as a standalone entity in relation to its intended purpose. However, the exact methodology is not detailed. The automation of programming infusion parameters is a key function described.

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

• Type of Ground Truth: Not explicitly stated as "ground truth" in the AI/ML sense. For this device, the "ground truth" would likely be based on:
  • Functional specifications: Whether the device performs as designed (e.g., transmits and receives data correctly, automates programming accurately).
  • Comparison to predicate device: Demonstrating that its technological characteristics and performance are equivalent to the legally marketed predicate device (B. Braun Medical Inc., Horizon™ Outlook with DoseCom™).
  • Safety standards: Adherence to relevant safety and performance standards for infusion pumps.

8. The sample size for the training set

• Training Set Sample Size: Not applicable. This device is a hardware/software system for infusion and communication, not an AI/ML model that undergoes a "training" phase with a dataset in the typical sense.

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

• Ground Truth for Training Set: Not applicable, as this is not an AI/ML device that requires a training set with associated ground truth for model development.

In summary: The provided 510(k) document focuses on establishing substantial equivalence for an infusion pump system with added communication capabilities. It references "performance data" indicating the device meets "specified requirements" and is "substantially equivalent" to a predicate device. However, it does not provide the detailed quantitative acceptance criteria, study design, or AI/ML-specific evaluation metrics (like sample sizes for test/training sets, expert adjudication, or MRMC studies) that would typically be found in a submission for an AI/ML-enabled diagnostic or prognostic device. The nature of this device means these AI/ML-specific questions often do not directly apply.

Ask a specific question about this device