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 SE Infusion System with 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 SE Infusion 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 addition of the Medication Management System (MMS) to the SE Infusion System will allow wireless bi-directional communication with the Alaris Server and external devices. MMS is the combination of RF communication from the SE Infusion System to/from the Alaris Server and the Alaris Proprietary software called the Inter-Server Interface Protocol (ISIP). The ISIP allows for communication between the SE Infusion System, the Alaris Server, and external devices.

The SE Infusion System with MMS is intended to provide 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 verification of infusion or monitoring parameters using MMS is performed by trained healthcare professionals prior to administration of medication(s).

The provided text does not contain specific acceptance criteria or a detailed study description with performance metrics for the Cardinal Health, Alaris Products SE Infusion System with MMS. It primarily focuses on the device description, its intended use, and its substantial equivalence to a predicate device. The "Performance Data" section states broadly that "The performance data indicate that the SE Infusion System with MMS meets specified requirements, and is substantially equivalent to the predicate device," but it does not provide any quantitative data, study design, or specific acceptance criteria.

Therefore, I cannot fulfill most of your request from the given information. Below is a response based on what can be extracted and a clear indication of what information is missing.

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

• Acceptance Criteria: Not specified in the provided text.
• Reported Device Performance: Not quantified in the provided text. The document only states that "The performance data indicate that the SE Infusion System with MMS meets specified requirements, and is substantially equivalent to the predicate device."

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 for Test Set: Not specified.
• 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)

• Not applicable as no specific test set and ground truth establishment is described in the provided text. The document mentions "trained healthcare professionals" for data entry and validation, but this pertains to the device's intended use in clinical practice, not a study's ground truth establishment.

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

• Not applicable as no specific test set and adjudication method is described.

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. The device is an infusion pump system with a Medication Management System (MMS) for automating programming parameters, not an AI diagnostic tool involving human readers interpreting cases.

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

• Not explicitly described as a standalone study in the context of an algorithm's performance. The device's primary function is to automate programming parameters, and it is intended for use by "trained healthcare professionals." The functionality of the MMS relies on communication and software, which could be considered algorithmic, but its performance is always in conjunction with a user.

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

• Not applicable as no specific ground truth for a study is described. The device's functionality is about accurately processing and delivering infusion parameters according to orders, validated by healthcare professionals.

8. The sample size for the training set

• Not applicable as no machine learning model or training set is described.

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

• Not applicable as no machine learning model or training set is described.

Summary of what is available from the text:

The provided text describes the Cardinal Health, Alaris Products SE Infusion System with MMS as a device intended to automate the programming of infusion parameters, thereby reducing manual steps. It communicates wirelessly with an Alaris Server using proprietary software. The document asserts that "The performance data indicate that the SE Infusion System with MMS meets specified requirements, and is substantially equivalent to the predicate device," which is the Medley System with MMS (K030459). However, no specific performance data, acceptance criteria, or study details are provided to support this claim in the given excerpts. The review by the FDA (K043590) confirms substantial equivalence, allowing the device to be marketed.

Ask a specific question about this device

The Hospira MedNet™ Medication Management Suite (MMS) is intended to facilitate networked communication between MMS compatible computer systems and Hospira infusion pumps. The MMS provides trained healthcare professionals with the capability to send, receive, report, and store information from interfaced external systems, and to configure and edit infusion programming parameters.

The MMS is intended to provide 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 a trained healthcare professional according to physician's orders.

The Hospira MedNet™ Medication Management Suite is an optional software product intended for use in healthcare facilities by trained healthcare professionals to facilitate networked communications (wired or wireless) between MMS compatible hospital information systems and Hospira infusion pumps, such as the Plum A+ 9. The feature of pre-populating infusion parameters is being added to reduce the number of manual steps to program an external infusion pump.

The MMS provides healthcare professionals with the capability to send, receive, and store information from infusion pumps. The bi-directional communication includes infusion parameters, pump default configurations, pump location, history, events, trending, alarms and status. The MMS cannot remotely start, modify, or terminate ongoing infusions.

The provided text does not contain any information about acceptance criteria or a study proving the device meets acceptance criteria.

The document is a 510(k) summary for the Hospira MedNet™ Medication Management Suite. It primarily focuses on demonstrating substantial equivalence to predicate devices, describing the device's intended use and technological characteristics. It does not detail specific performance metrics, clinical studies, or the methodologies typically associated with proving a device meets predefined acceptance criteria.

Therefore, I cannot provide the requested information based on the input text.

Ask a specific question about this device