K Number
K223606
Manufacturer
Date Cleared
2023-08-24

(265 days)

Product Code
Regulation Number
880.5725
Panel
HO
Reference & Predicate Devices
AI/MLSaMDIVD (In Vitro Diagnostic)TherapeuticDiagnosticis PCCP AuthorizedThirdpartyExpeditedreview
Intended Use

The LifeShield™ Infusion Safety Software Suite is a collection of software products that facilitates networked communication between compatible systems. The Infusion Safety Software Suite provides trained healthcare professionals the ability to manage data for compatible infusion pumps. All data entry and validation of infusion parameters on compatible infusion pumps is performed by a trained healthcare professional. LifeShield™ Infusion Safety Software Suite is indicated for use in patients including adult, pediatric and neonate undergoing infusion therapy with connected compatible infusion pumps (as per the indications for use specified for the compatible infusion pump).

The LifeShield™ Drug Library Management (DLM) software product is intended to be used by pharmacists to create, configure, edit, and manage drug library data, including infusion pump settings, for use with compatible infusion pumps. Drug library contents are constructed based on the healthcare provider's defined best practices.

The LifeShield™ Clinical Dashboards & Reports (CDR) software product provides trained healthcare professionals with the capability to view and manage infusion collected from compatible infusion pumps. Healthcare professionals may choose to use the collected information to support continuous quality improvement programs, or to analyze and trend various aspects of the infusion pumps and therapies used. It is not intended to be a substitute for good clinical management practices, nor does its operation create decisions or treatment pathways.

Device Description

The LifeShield™ Infusion Safety Software Suite is a cloud-based platform provided as a software-as-a-service (SaaS) designed to be compatible with the Plum Duo™ infusion pump. The LifeShield Infusion Safety Software Suite is hosted by Amazon Web Services (AWS) as its cloud provider. LifeShield™ Infusion Safety Software Suite consists of a collection of software services which, when used together, provide a comprehensive set of data management capabilities for trained healthcare professionals when working with infusion pumps. LifeShield™ Infusion Safety Software Suite does not remotely control or program the infusion pump or provide the ability to remotely manage pump alarms such as real-time monitoring, clearing and silencing alarms.

The LifeShield™ Drug Library Management (DLM) software product is used by pharmacists to create approved drug libraries that can be downloaded by the infusion pumps. Drug libraries contain information on medications along with rulesets and associated clinical care areas (CCA) defined by pharmacists in accordance to their facility's best practices. Certain infusion pump parameters are also defined in the drug library. The LifeShield™ Device Manager (DM) and LifeShield™ Data Flow Management (DFM) are used to make the drug libraries available for the infusion pump to download and install. Download and installation of a drug library to the infusion pump establishes alert parameters for a medication that is being programmed for infusion. Additionally, the infusion pump applies the userdefined drug library settings for the configurable features of the pump.

The LifeShield™ Clinical Dashboards & Reports (CDR) software is used by clinical administrators to view infusion or device-related information received from the Plum Duo™ infusion pump via the LifeShield™ DFM. It provides a near real-time view of ongoing infusions and their status; a view of all infusion pumps with their asset information and operational status; dashboards that provides easy navigation of key infusion or asset metrics; and an analytics viewer that users can use to view historical infusion and/or asset information. Healthcare professionals may choose to use the collected infusion information to support continuous quality improvement programs, or to analyze and trend various aspects of the infusion pumps and therapies used. The information presented by the software does not create decisions or treatment pathways for patients. LifeShield™ CDR is able to display infusion and infusion pump information from a single or multiple facilities within the customer account.

LifeShield™ Infusion Safety Software Suite can be configured to interface with a facility's Hospital Information System (HIS) / EHR system to support auto-programming and infusion documentation. When the autoprogramming feature license is enabled, the LifeShield™ Infusion Safety Software Suite can receive a pharmacy-validated order (also referred as auto-program order) from the HIS/EHR and route it to the infusion pump where the therapy program is pre-populated with physician-prescribed medication and infusion parameters, helping to reduce manual entry by the clinician when programming the pump. LifeShield™ Infusion Safety Software Suite does not modify the contents of the auto-program order received from the HIS/EHR.

When the infusion documentation feature license is enabled, the LifeShield™ Infusion Safety Software Suite forwards the infusion data it receives from the infusion pump to the HIS/EHR system to support the facility's documentation of infusion information and HIS/EHR dashboards. Infusion data includes infusion status (e.g. volume change) and events (e.g. infusion start, stop, complete). LifeShield™ Infusion Safety Software Suite does not modify the contents of the infusion data sent to the HIS/EHR.

AI/ML Overview

Here's an analysis of the acceptance criteria and study information for the LifeShield™ Infusion Safety Software Suite based on the provided document:

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

The document primarily focuses on demonstrating substantial equivalence to a predicate device rather than presenting specific quantitative acceptance criteria and device performance metrics in a direct table format. However, it implicitly states that the device met acceptance criteria through various tests.

Here's an interpreted table based on the non-clinical testing summary:

Acceptance Criteria CategoryReported Device Performance (as stated in the document)
Design Requirements MetDesign verification tests passed established acceptance criteria, confirming the subject device meets design requirements.
Software VerificationSoftware verification followed the software development process outlined in IEC 62304:2015.
Performance, Reliability, CompatibilityVerification activities also included performance, reliability, compatibility tests, and systems integration tests with the compatible infusion pump, which were passed.
System IntegrationSystems integration tests with the compatible infusion pump were passed.
CybersecurityCybersecurity evaluation and testing demonstrate that the software is reasonably secure.
User Needs Met (Design Validation)Design validation tests passed established acceptance criteria, confirming the subject device meets all intended users' needs.
Risk ManagementRisk mitigations have been incorporated into the design and have been tested for correct implementation and effectiveness as part of design verification and validation.
User Interface Effectiveness (Human Factors)Human Factors studies demonstrate the effectiveness of the user interface design for key features and their associated critical tasks.

2. Sample size used for the test set and the data provenance:

The document does not specify the sample size used for any of the test sets (design verification, design validation, cybersecurity, human factors). It also does not mention the country of origin of the data or whether the data was retrospective or prospective.

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

The document does not provide information on the number of experts used or their specific qualifications for establishing ground truth for any of the tests. It refers to "trained healthcare professionals" for the intended use and "pharmacists" for drug library creation but does not detail their involvement in formal ground truth establishment for testing.

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

The document does not describe any adjudication method used for establishing ground truth or evaluating test results.

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:

The document states, "A Clinical Study is not required for this submission to support substantial equivalence." Therefore, no MRMC comparative effectiveness study was done, and there is no information on human reader improvement with or without AI assistance. This device is a software suite for managing infusion pump data, not an AI-powered diagnostic or assistive tool for human interpretation.

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

The device is described as a "software-as-a-service (SaaS)" that facilitates data management and communication for infusion pumps. It explicitly states that "All data entry and validation of infusion parameters on compatible infusion pumps is performed by a trained healthcare professional." While portions of the software may operate automatically (e.g., routing data), the core functionality involves human interaction and oversight. Therefore, a purely standalone algorithm-only performance study as typically understood for AI algorithms would not be applicable or detailed here. The "non-clinical testing" and "design verification" cover its functional performance.

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

The document does not explicitly state the type of "ground truth" used for its internal verification and validation studies. Given the nature of the device (infusion safety software), the "ground truth" would likely involve:

  • Design requirements and specifications: For design verification, the software's output and functionality are compared against its documented requirements.
  • User needs: For design validation, the software's ability to meet the needs of trained healthcare professionals (pharmacists, clinical administrators) for tasks like drug library management, data viewing, and auto-programming would be assessed.
  • Industry standards: Adherence to standards like IEC 62304 for software and ISO 14971 for risk management implies these standards served as a form of "ground truth" for compliance.

8. The sample size for the training set:

As this is not an AI/ML device that requires a training set in the conventional sense, the document does not mention a training set or its sample size. The software development process aligns with IEC 62304, focusing on verification and validation of designed functionality.

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

Not applicable, as there is no mention of a training set.

§ 880.5725 Infusion pump.

(a)
Identification. An infusion pump is a device used in a health care facility to pump fluids into a patient in a controlled manner. The device may use a piston pump, a roller pump, or a peristaltic pump and may be powered electrically or mechanically. The device may also operate using a constant force to propel the fluid through a narrow tube which determines the flow rate. The device may include means to detect a fault condition, such as air in, or blockage of, the infusion line and to activate an alarm.(b)
Classification. Class II (performance standards).