(385 days)
Dose IQ Safety Software is intended to be used with the Novum IQ Syringe Pump and Novum IQ Large Volume Pump to support the controlled administration of fluids.
Dose IQ Safety Software is intended to allow users to create and maintain drug libraries, including the configuration of pump settings for the compatible pumps.
Dose IQ Safety Software is intended to allow users to establish the facility-defined syringe list, which is a subset of Baxter's approved compatible syringes, for the Novum IQ Syringe Pump.
Dose IQ Safety Software is intended to be used by licensed pharmacists.
Dose IQ Safety Software is intended to be used in hospitals and outpatient health care facilities.
Dose IQ is a standalone (not embedded in pumps) browser-based software application that is installed on a hospital-provided computing platform. It provides the hospital's pharmacists the ability to create and configure a facility-specific drug library file for the either the Novum IQ Large Volume Pump or the Novum IQ Syringe Pump. Dose IQ stores the created drug library for future transfer to an infusion pump that is compatible with the drug library file through the IQ Enterprise Gateway, or via a USB. It is intended to be used by multiple users simultaneously. Authorized users access the software though a Google Chrome web browser (build 76.0.3809.100 and above).
Creating a facility-specific drug library in Dose IO is one method to implement a Dose Error Reduction System (DERS) – a safety system intended to reduce medication errors. A hospital-defined drug library defines medications with individual concentrations, concentration limits, dosing units, dosing limits, alarm configuration settings, and administration requirements that are specific to each patient care area. Pump programming values are checked against these hospital-defined limits. The pump alerts clinicians if programmed values exceed these limits. Also included in the drug library are hospital-defined individual care area settings and general pump settings. DERS is not active when programming an infusion using Basic Mode, which requires the pump user to manually specify the parameters for the infusion on the pump, therefore only individual Care Area settings, general pump settings, and pump default settings apply.
Dose IQ does not directly interface with or control the compatible infusion pump. It solely provides the ability to create a drug library file that can then be loaded to the compatible infusion pump. Dose IO does not deploy the file to the pump; this is done by USB media or the IQ Enterprise Gateway software. A copy of the drug library file is stored in each pump, so that the pump can operate, without real-time interaction, with other components of the Novum IQ Platform.
Baxter provides a list of syringe containers that are permissible with the Novum IQ Syringe pump based on specific syringe brands and sizes. The Approved Syringe List is available on Baxter's Technical Service Portal and must be uploaded into Dose IQ. The Approved Syringe List cannot be modified in Dose IQ. The pharmacist selects the required syringe brands and sizes from this Approved Syringe List to create the Facility Syringe List for use within the hospital. Dose IQ incorporates the Approved Syringe List and the Facility Syringe List as part of the drug library file for the Novum Syringe pump.
The provided text describes the 510(k) premarket notification for the Baxter Dose IQ Safety Software. However, it explicitly states, "No clinical testing was performed in support of this premarket notification." Therefore, there is no information in the provided document about "acceptance criteria" based on clinical performance, a "study that proves the device meets the acceptance criteria" in a clinical context, or details like sample size, expert ground truth establishment, MRMC studies, or standalone performance.
The document primarily focuses on non-clinical testing, verification, and validation to demonstrate substantial equivalence to a predicate device. It details software testing and a human factors evaluation.
Based on the provided text, here's what can be extracted regarding acceptance criteria and performance, primarily from a non-clinical testing and verification/validation perspective:
1. A table of acceptance criteria and the reported device performance:
Since the document does not present clinical acceptance criteria, the "acceptance criteria" implied here are related to software verification and validation, and meeting design inputs and user needs. The reported performance is a general statement of successful completion of these tests.
| Acceptance Criteria (Implied from Non-Clinical Testing) | Reported Device Performance |
|---|---|
| Potential risks mitigated and residual risk acceptable | Confirmed: Potential hazards identified and adequately mitigated. |
| Design verification and validation acceptable | Confirmed: Design verification and validation acceptable. |
| Meets clinically valid essential performance | Confirmed: Device meets clinically valid essential performance. |
| Design inputs and user needs met | Confirmed: Validation demonstrated design inputs and user needs were met. |
| Design outputs meet design and cybersecurity requirements | Confirmed: System verification demonstrated design outputs meet design and cybersecurity requirements. |
| All testing met acceptance criteria | Confirmed: All the testing met acceptance criteria. |
| Software verification and validation (functional, regression, smoke & sanity, code review, static analysis, unit testing) performed according to FDA guidance | Confirmed: Performed according to FDA Guidance "Guidance for the Content of Premarket Submission for Software Contained in Medical Devices." issued May 11, 2005. |
| Human factors evaluation results suitable for intended use | Confirmed: Results show the device is suitable for its intended use. |
2. Sample size used for the test set and the data provenance:
- Test Set Sample Size: Not applicable in the context of clinical data, as no clinical testing was performed. For non-clinical software testing, the "sample size" would refer to the number of test cases, which is not specified but implied to be comprehensive enough for "functional testing, regression testing, smoke & sanity testing, code review, static analysis, and unit testing."
- Data Provenance: Not applicable for clinical data. For non-clinical testing, the tests were conducted by Baxter Healthcare Corporation. The document does not specify the country of origin of the test data (e.g., specific testing labs or environments), but it implies internal company testing or external contracted testing. The testing is non-clinical verification and validation, not retrospective or prospective clinical data.
3. Number of experts used to establish the ground truth for the test set and the qualifications of those experts:
- Not applicable as no clinical ground truth was established from expert readings or similar methods for a clinical test set. The "truth" for software testing is defined by the functional and non-functional requirements and design specifications.
- For the human factors study, it was conducted "with the intended user population." The number and specific qualifications of these users (e.g., licensed pharmacists, as per the indications for use) are not detailed.
4. Adjudication method (e.g., 2+1, 3+1, none) for the test set:
- Not applicable as no clinical test set requiring adjudication of expert opinions was used.
5. If a multi-reader multi-case (MRMC) comparative effectiveness study was done:
- No. The document explicitly states, "No clinical testing was performed."
6. If a standalone (i.e., algorithm only without human-in-the loop performance) was done:
- Again, no clinical performance studies were conducted. The device itself is "standalone (not embedded in pumps) browser-based software application that is installed on a hospital-provided computing platform." Its primary function is to create drug libraries for infusion pumps, not to directly perform real-time patient-facing actions or diagnoses that typically warrant standalone algorithm performance metrics. It's a tool for pharmacists to configure other medical devices.
7. The type of ground truth used:
- For non-clinical software testing: The ground truth is effectively the design requirements, specifications, and established functional behavior of the software as defined by the developers and verified against those specifications.
- For the Human Factors evaluation: The "ground truth" would be the successful completion of tasks by intended users in a simulated environment, demonstrating the usability and safety in typical use scenarios.
8. The sample size for the training set:
- Not applicable. This is not an AI/ML device that learns from a "training set" of data in the typical sense (e.g., image datasets). It's a configuration and management software.
9. How the ground truth for the training set was established:
- Not applicable, as there is no "training set" for an AI/ML model described.
§ 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).