Search Results

The BD Alaris Infusion 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 2 and 3 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 Infusion System with Guardrails Suite MX is an interoperable system capable of communicating and exchanging data with compatible information technology systems.

The BD Alaris Infusion System with Guardrails Suite MX 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. EtCO2 Module is a capnograph that continuously monitors end-tidal carbon dioxide (EtCO2), fractional inspired carbon dioxide (FiCO2), and respiratory rate (RR).

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

The BD Alaris Infusion System with Guardrails Suite MX is a modular infusion and monitoring system designed to provide controlled delivery of drugs and fluids, and to provide monitoring of respiratory parameters. The BD Alaris Infusion System with Guardrails Suite MX has three (3) major components:

1. System Hardware: A core hardware unit with user interface (BD Alaris PC Unit or PCU) and attachable modules each with a distinct function.

   • BD Alaris Pump Module (LVP)
   • BD Alaris Syringe Module (SYR)
   • Alaris PCA Module (PCA)
   • BD Alaris EtCO2 Module (EtCO2)
   • Alaris Auto-ID Module (Auto-ID)

2. Guardrails Suite MX Software: Software applications for support and interaction with the system hardware

   • BD Guardrails Editor (GRE)
   • BD Alaris Systems Manager (SM)
   • BD Alaris Systems Maintenance (ASM)

3. Interoperability Software: Software applications for facilitating bi-directional communication between the PCU and attached LVP and SYR modules, and an electronic medical records (EMR) system via BD Alaris Infusion Systems Manager (SM) and Care Coordination Engine (CCE), a non-medical device Medical Device Data System (MDDS).

   • Calculation Services
   • Infusion Adapter (IA)

The PCU is the core of the BD Alaris Infusion System with Guardrails Suite MX and necessary for its operation. It provides a common user interface for programming, and powering and monitoring attached modules. 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 using inter-unit interface (IUI) connectors built into both sides of the PCU and modules, which also serve to provide power to the modules and communication between the PCU and attached modules. The PCU is powered by AC power and has a rechargeable battery to allow for continued therapy during power interruptions.

The attachable modules are dedicated to controlled delivery of fluids, pharmaceutical drugs, parenteral nutrition, and blood and blood products into patients, patient-controlled administration of analgesics, monitoring of end-tidal carbon dioxide, and scanning identifications of patient, physician, and infusates into the system.

• The BD Alaris Pump Module (LVP) delivers fluids accurately over programmed times and can detect and notify the user of situations that could impact patient safety, such as improper set loading, occlusion, and air-in-line. It can deliver fluids continuously or intermittently from any compatible container using a dedicated BD Alaris infusion set. Flow rates range from 0.1 to 999 mL/h and bolus doses can be programmed at the start or during continuous infusion.

• BD Alaris Syringe Module (SYR) is designed for injecting fluids from compatible syringes and can detect and notify the user of situations that could impact patient safety, such as an improperly loaded syringe and occlusion. It can deliver continuous or intermittent volumes from 1 to 50 mL syringes at flow rates of 0.01 to 999 mL/hr.

• The Alaris PCA Module (PCA) is designed for patient-controlled analgesia. It shares core components and functionality with the BD Alaris Syringe Module but includes additional features such as: a dose request cord for self-administering pain medication, software with a dose lockout interval, and a locking syringe enclosure door with a key. When configured for use with the BD Alaris EtCO2 Module, it can also trigger a pause of the PCA infusion if the respiratory rate of a patient falls outside the limits.

• The BD Alaris EtCO2 Module (EtCO2) a capnograph used for continuous, non-invasive monitoring of end-tidal CO2, fractional inspired CO2, and respiratory rate. It can be used to monitor respiratory depression in patients when using the Alaris PCA Module.

• The Alaris Auto-ID Module (Auto-ID) features an internal barcode image scanner and an optional handheld scanner. Scanning a clinician ID unlocks the PCU panel in authorized user mode and links clinical event logs with the clinician. Scanning a patient ID band associates logs with the patient, while scanning IV fluid or medication barcodes selects the specific item from the drug library for infusion modules.

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

The PCU with its attached modules is designed to be configured to communicate and interact with the Guardrails Suite MX software applications including software for interoperability with Electronic Medical Record (EMR) systems. Communication between the PCU and the software applications is accomplished through either a direct serial connection or through a wireless connection utilize the respective Guardrails Suite MX Software applications.

• The BD Guardrails Editor (GRE) allows for the creation of drug and fluid libraries and guidelines, called 'profiles,' for specific patient populations. GRE also provides a transfer tool to transfer a profile to PCU via serial cable.

• The BD Alaris Systems Manager (SM) manages connectivity and includes a web application, communications server, and database software for managing data, creating reports, connecting with a healthcare facility's network, and storing system configuration, user permissions, and historical data. Use of SM also supports transferring wireless software updates to the PCU during system servicing.

• BD Alaris Systems Maintenance (ASM) is used for standard maintenance tasks, including module calibration and network configurations

• The BD Alaris Interoperable software includes the Infusion Adapter (IA) and Calculation Services to support bi-directional communication between the BD Alaris Infusion System with Guardrails Suite MX and the healthcare facility's EMR. The Infusion Adapter facilitates data exchange ensuring correct message formats and content. Calculation Services performs pre-defined rule-based calculations to obtain infusion duration, body surface area (BSA), and weight-based dose.

It is important to note that interoperability does not include remote control of the BD Alaris Infusion System with Guardrails Suite MX. 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 at the bedside before they are activated.

The provided FDA 510(k) clearance letter and summary for the BD Alaris Infusion System with Guardrails Suite MX (K243855) do not contain detailed information about specific acceptance criteria and a study proving the device meets those criteria in the context of an AI/algorithm performance evaluation. Instead, the document focuses on the substantial equivalence of an infusion pump system to a predicate device, with an emphasis on its hardware, software (including safety management and interoperability features), and general electrical and functional safety.

The text does not describe an AI/algorithm in the sense of a diagnostic or assistive AI that requires expert-driven ground truth, MRMC studies, or standalone performance metrics typically associated with AI/ML-based medical devices. The "Guardrails Suite MX" and "Calculation Services" mentioned are primarily about drug library management, dose error reduction, and rule-based calculations, which are more akin to conventional software functionalities rather than adaptive AI algorithms that learn from data.

Therefore, many of the requested categories for describing an AI/algorithm acceptance study are not applicable to the information provided in this document. Given the nature of the device (an infusion pump system), the "acceptance criteria" discussed are related to its functional performance, safety, and compliance with regulations and standards.

However, I can extract the relevant "acceptance criteria" and "performance" data that are presented in the document, framed within the context of a traditional medical device's non-clinical testing.

Reported Device Performance and "Acceptance Criteria" (based on functional and safety requirements):

The document describes non-clinical testing to verify essential performance requirements. These requirements serve as the de facto "acceptance criteria" for the device's main functions.

Since the provided document is a 510(k) clearance letter for an infusion pump system, not an AI/ML-based diagnostic or assistive device, the following points are largely not applicable or not explicitly detailed in the text. I will state if the information is unavailable or implies "None" for the context of this specific device's clearance.

1. Sample sizes used for the test set and the data provenance:

   • Test Set Sample Size: Not explicitly stated for all performance tests. The document refers to "testing" and "statistical methods in sample size determination and data analysis" but does not provide specific numbers for each test (e.g., how many pumps were tested for flow rate accuracy). This is common for 510(k) summaries where detailed test reports are typically referenced but not fully included.
   • Data Provenance: Not specified regarding country of origin. The testing would generally be conducted by the manufacturer (BD/CareFusion) or their approved test labs. It describes "non-clinical testing" and "simulated clinical conditions," which indicates a prospective validation within a controlled environment.

2. Number of experts used to establish the ground truth for the test set and the qualifications of those experts:

   • Not Applicable in the AI/ML sense. Ground truth for an infusion pump's performance (e.g., flow rate accuracy, alarm function) is established through engineering measurements and adherence to international standards (like AAMI TIR 101, ISO 80601-2-55). It doesn't involve expert consensus on medical images or clinical outcomes in the way an AI diagnostic would. The "Human Factors evaluation" mentions "clinical assessment" and "biomedical engineering use," implying input from relevant experts, but not for "ground truth" labeling of data.

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

   • Not Applicable. This is a method for resolving discrepancies in expert labeling of data, which is not relevant for the type of objective functional performance testing described for an infusion pump.

4. 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 an infusion pump system, not an AI for human reader assistance in diagnostic tasks.

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

   • Partially Applicable / Different Context. The document details extensive "essential performance" testing of the device (hardware and embedded software) in a standalone capacity, demonstrating its accuracy, safety mechanisms, and compliance with standards. This constitutes "algorithm only" performance in the sense of the pump's control algorithms (e.g., for flow rate, pressure detection). However, it's not an "AI algorithm" in the typical understanding of machine learning where a "human-in-the-loop" interaction for clinical decision-making is assessed.

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

   • Engineering Measurements and Compliance with Standards. The "ground truth" for this device's performance is derived from precise engineering measurements, calibration standards, and adherence to established medical device performance standards (e.g., AAMI TIR 101 for flow rate accuracy requires specific test methods and reference measurements). For the EtCO2 module, it's based on accuracy against known gas concentrations.

7. The sample size for the training set:

   • Not Applicable (in the AI/ML sense). This device is not described as utilizing machine learning that requires a "training set" of data for algorithm development. Its software functionalities (e.g., Guardrails Suite MX) are rule-based systems or deterministic algorithms, developed through traditional software engineering and verification processes.

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

   • Not Applicable. As no AI/ML training set is indicated, this question is not relevant.

In summary, the provided document meticulously outlines the non-clinical validation of an infusion pump system, demonstrating its safety and effectiveness through adherence to performance specifications and regulatory standards. It does not, however, pertain to the clearance of an AI/ML diagnostic or assistive algorithm, which would involve the specific types of studies and ground truth methodologies requested in the prompt.

Ask a specific question about this device

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

Pressure Rated: The MaxZero™ Extension Set with Needle-Free Connector(s) is for single use only. The MaxZero™ Extension Set with Needle-Free Connector(s) may be used for direct injection, intermittent infusion or aspiration. This set may be used with power injector procedures to a maximum pressure of 325 psi at a flow rate of 10mL per second.

The MaxZero™ Extension Set with Needle-Free Connector(s) are intravascular extension sets intended for single patient use, including pediatrics (neonates, infants, children, adolescents) and immunocompromised patients, for direct injection, intermittent infusion continuous infusion or aspiration of drugs, blood and fluids, All MaxZero™ Extension Set with Needle-Free Connector(s) include the previously cleared zero reflux MZ1000 needleless Connector bonded to the extension set tubing. The MZ1000 needleless connector allows thorough and easy disinfection due to a solid, flat smooth surface and eliminates the risk of needle stick injuries. The MaxZero™ needleless connectors are sterile single patient devices that can be used for seven (7) days and 200 activations. All extension sets included in this submission are not made from natural rubber latex or DEHP.

The provided document is a 510(k) summary for the MaxZero™ Extension Set with Needle-Free Connector(s). It details the device's technical characteristics, its substantial equivalence to a predicate device, and the non-clinical testing performed to support its safety and effectiveness.

Here is a breakdown of the requested information based on the provided text:

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

The document states: "All test results met their acceptance criteria and support that the MaxZero™ Extension Set with Needle-Free Connector(s) are appropriately designed for their intended use." However, specific numerical acceptance criteria and the exact reported performance results for each test are not provided in this summary. The summary only lists the types of tests performed.

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

The document does not explicitly state the sample sizes for the individual non-clinical tests. It refers to "design verification performance testing" and lists various standards and additional tests. The data provenance is not specified, but the submission is from CareFusion, Inc., located in San Diego, CA, USA. The testing would have been conducted by or for a US-based company, likely in the US or in a facility adhering to international standards for medical device testing. The data is prospective, as these are engineering and laboratory tests conducted to qualify the device.

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)

This section is not applicable as the document is discussing a non-clinical evaluation of a medical device (intravascular administration set) rather than diagnostic or imaging software requiring expert interpretation for ground truth establishment. The "ground truth" here is defined by engineering specifications and recognized performance standards.

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

This section is not applicable for the same reason as point 3. Adjudication methods are typically used in clinical studies or evaluations of diagnostic systems where there might be disagreement in expert interpretations.

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

There is no MRMC comparative effectiveness study mentioned. The submission is for a physical medical device (extension set) and not an AI-assisted diagnostic tool.

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

This section is not applicable as the device is a physical medical device, not an algorithm or AI system.

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

For this medical device, the "ground truth" is established through:

• Engineering specifications and design requirements: The device must meet specific physical and performance parameters (e.g., pressure resistance, flow rates, bond strength).
• Recognized consensus standards: The device performance is evaluated against international standards such as ISO and ASTM for medical devices, luer connectors, sterilization, packaging, and biocompatibility.
• Biocompatibility guidelines: Specific ISO standards define acceptable biological responses and toxicity.
• Regulatory guidance: Adherence to FDA guidance documents for intravascular administration sets.

8. The sample size for the training set

This section is not applicable as there is no machine learning or AI component requiring a training set. The device is a physical product.

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

This section is not applicable as there is no machine learning or AI component requiring a training set and its associated ground truth establishment.

Ask a specific question about this device

The Multi-Link™ X2 ECG Adapter and Direct Connect Lead Wire System are used in telemetry to transmit ECG signals from the electrodes to the transmitters on ambulatory patients within a defined coverage area for monitoring purposes. The Multi-Link Direct Connect Lead Wires are single-patient-use, non-sterile and cannot be reprocessed. The Multi-Link Adapters are reusable, non-sterile and can be reprocessed. The Multi-Link X2 ECG Adapter and Direct Connect Lead Wire System are used with any patient population requiring ambulatory ECG, and are compatible with Philips, Mindray and Nihon Kohden electrocardiograph monitors.

The Multi-Link X2 ECG Adapter and Direct Connect Lead Wire System is a combination of reusable adapters, already cleared lead wires (reusable K980582 and disposable single patient use K101660) and direct connect disposable single patient use lead wires, used to transmit signals from patient electrodes to the transmitters on ambulatory patients within a defined coverage area for monitoring purposes. This type of device is common to both the industry and to most medical establishments. The Multi-Link X2 ECG Adapter and Direct Connect Lead Wire System are not stand alone devices, but are accessories to the host monitoring devices. The adapters and lead wires are conductors carrying the signal from the patient to the monitor.

This document is a 510(k) Premarket Notification from the FDA for a device called "Multi-Link X2 ECG Adapter and Direct Connect Lead Wire System" (K163316). It primarily focuses on demonstrating substantial equivalence to predicate devices through performance and biocompatibility testing against international standards.

Given the nature of the device (ECG adapters and lead wires), the acceptance criteria are based on meeting specified performance standards rather than measures like accuracy, sensitivity, or specificity often associated with diagnostic AI tools. Therefore, information related to AI-specific elements such as training/test sets, ground truth establishment, expert adjudication, or MRMC studies for improved human reader performance will not be relevant.

Here's the breakdown of the acceptance criteria and study information provided:

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)

The document describes performance testing of physical components (adaptors and lead wires) against established engineering and safety standards. It does not refer to a "test set" in the context of clinical data or patient records. Therefore, information about sample size for a test set or data provenance (country of origin, retrospective/prospective) is not applicable or provided. The testing is likely conducted in a laboratory setting on a sample of manufactured devices.

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)

This information is not applicable. The device is a medical accessory, and its performance is evaluated against engineering and safety standards, not against "ground truth" established by clinical experts for diagnostic accuracy.

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

This information is not applicable, as the testing involves meeting pre-defined objective engineering standards, not subjective clinical evaluations requiring 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

An MRMC study is not relevant to this device. This device is an ECG adapter and lead wire system, which transmits ECG signals. It is not an AI-powered diagnostic tool, and therefore, there is no human reader "improvement with AI vs without AI assistance" to measure.

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

This information is not applicable. The device is a physical accessory and does not contain an "algorithm" for standalone performance evaluation in this context.

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

The "ground truth" for this device's performance is defined by the objective pass/fail criteria outlined in the referenced international engineering and safety standards (e.g., AAMI ANSI ES60601-1, AAMI ANSI IEC 60601-2-27, AAMI ANSI EC53, ISO 10993 series). There is no clinical "ground truth" like expert consensus or pathology involved in evaluating these performance characteristics.

8. The sample size for the training set

This information is not applicable. The device is a physical accessory and does not involve training data or algorithms in the way an AI-driven diagnostic device would.

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

This information is not applicable for the reasons stated above.

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

The Alaris® PC Unit is the main user interface unit and power supply of the Alaris® System, a modular system to be used with Alaris® System modules (aka Medley™ System modules) intended for use in today's growing professional healthcare environment for facilities that utilize infusion and/or monitoring devices. The specific intended use for each Alaris® System module is specified in its respective submission.

The Alaris System is a modular system that consists of a point-of-care unit (PC unit) that provides the main user interface and power supply for the associated infusion and monitoring modules. This update is only for the Alaris PC unit Module 8000 software correction and does not require any change to the associated modules, systems, or accessories of the Alaris System. The basic functionality and existing features as described in the original and subsequent 510(k) submissions for the Alaris System and associated modules will not change.

The provided text is a 510(k) summary for a software correction to an existing infusion pump, the Alaris® PC unit Module 8000. It doesn't contain information about the device's acceptance criteria or a study proving that it meets specific performance metrics. It primarily focuses on demonstrating substantial equivalence to a predicate device and outlining the administrative details of the submission.

Therefore, many of the requested categories related to performance studies and ground truth cannot be extracted from this document.

Here's a breakdown of what can and cannot be answered based on the provided input:

Ask a specific question about this device

The Wireless Monitoring System is intended for use by health care professionals for routine surveillance of patient physiological parameters to include, pulse rate, respiratory rate and axillary temperature, in a hospital setting. Data is transmitted wirelessly to a central location. Notifications can be prospectively set to notify healthcare professionals to excursions outside of selected parameters.

The device is not intended to be used on critical care patients and is intended to supplement vital signs monitoring by healthcare professionals, not to replace current standards of care. The device is intended for use on general care patients and on patients who are 18 years of age or older.

The proposed device consists of a patient patch with integrated temperature sensor, an electronic bridge and server software. The patch is attached to the patient and connected to existing monitoring leads to capture heart rate, respiration and body temperature. This data is wirelessly transmitted to a bridge. Multiple bridges can be installed in a hospital setting to capture signals in case the patient is moved or becomes ambulatory. Data from the patch is transmitted through a hard-wire connection to the nurses' station for surveillance. The healthcare practitioner can set limits on the patient data which in turn may trigger an alert.

Here's a breakdown of the requested information based on the provided 510(k) summary:

1. Table of Acceptance Criteria and Reported Device Performance

The 510(k) summary primarily focuses on non-clinical performance and equivalence to predicate devices, rather than explicit acceptance criteria with specific thresholds for accuracy or sensitivity/specificity typical of clinical performance studies for diagnostic devices. However, the comparative information table provides implicit acceptance criteria by stating "Same or similar" to the predicate devices for key physiological parameters.

2. Sample Size Used for the Test Set and Data Provenance

• Test Set Sample Size:
  • Usability Testing: The summary does not specify the exact number of participants for the usability testing. It mentions "participants" in the context of user opinions.
  • Wireless Testing: The summary does not provide a specific sample size (e.g., number of patients, devices, or test points) for the wireless testing.
• Data Provenance:
  • Usability Testing: Conducted at "The University of Texas at Arlington."
  • Wireless Testing: Conducted at "Palomar Pomerado Hospital."
  • The studies appear to be prospective as they are described as "testing" of the new device's operation and usability.

3. Number of Experts Used to Establish the Ground Truth for the Test Set and Their Qualifications

• Usability Testing: "Staff opinions were positive with participants showing an interest in using the proposed device." No specific number of experts or their qualifications for establishing a "ground truth" on usability are provided, as usability is often assessed through user feedback rather than expert ground truth.
• Wireless Testing: "Testing for EMI and other parameters were monitored and recorded." No specific number of experts or their qualifications for interpreting these technical results are provided. The "ground truth" here is the measurement data itself against predefined technical standards.

4. Adjudication Method for the Test Set

• No formal adjudication method (e.g., 2+1, 3+1) is mentioned for either the usability or wireless performance testing. The reported results are summaries of observations and measurements.

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

• No MRMC study was done. This device is a physiological monitoring system, not an AI-assisted diagnostic imaging device that typically uses human readers. The clinical studies focused on usability and wireless functionality, not on improving human reader performance.

6. If a Standalone (i.e., algorithm only without human-in-the-loop performance) Was Done

• This device is not an algorithm-only device. It is a hardware system that collects and transmits physiological data for healthcare professionals to monitor. The "standalone" performance in this context would refer to its technical accuracy and reliable data transmission, which were broadly addressed by technical testing and wireless performance checks, not an AI algorithm.

7. The Type of Ground Truth Used

• Non-Clinical (Technical/Performance) Tests: The ground truth for these tests would be the established performance standards (e.g., IEC, ISO, FCC) against which the device's technical specifications and measurements were compared.
• Usability Testing: The "ground truth" was subjective user feedback and observation of the system's operation as intended.
• Wireless Testing: The "ground truth" was direct measurement of wireless transmission parameters and observation of interference, compared against expected operational norms.
• No pathology or outcomes data was used as ground truth because this device is for surveillance of physiological parameters, not for diagnosis based on pathology or for evaluating clinical outcomes directly tied to a specific diagnostic accuracy.

8. The Sample Size for the Training Set

• Not applicable. The device described is a hardware and software system for physiological monitoring, not a machine learning or AI model that requires a "training set" in the conventional sense. The development likely involved engineering design, testing, and refinement, but not machine learning training on a dataset.

9. How the Ground Truth for the Training Set Was Established

• Not applicable. As stated above, there is no mention of a "training set" for machine learning algorithms in this 510(k) summary.

Ask a specific question about this device