(502 days)
Dose IQ Safety Software is intended to be used with the Novum IQ Syringe 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 Novum IQ Syringe Pump.
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 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 is a 510(k) summary for a medical device called "Dose IQ Safety Software." This document focuses on demonstrating substantial equivalence to a predicate device and includes information about non-clinical testing, but it does not describe a clinical study that proves the device meets specific acceptance criteria in the way a clinical trial or performance study typically would.
Instead, the document emphasizes non-clinical testing, verification, and validation against design input requirements, user needs, and intended use, as well as demonstrating substantial equivalence to a predicate device. It explicitly states: "No clinical testing was performed in support of this premarket notification."
Therefore, I cannot provide a response that directly answers the request for "a table of acceptance criteria and the reported device performance" from a clinical study, "sample sizes used for the test set," "number of experts," "adjudication method," "MRMC comparative effectiveness study," or "standalone performance" in the context of real-world clinical performance evaluation against health outcomes or diagnostic accuracy via expert read. The provided text deals with software verification and validation, and human factors.
However, I can extract the information related to the non-clinical acceptance criteria and validation efforts described in the document:
1. Table of Acceptance Criteria (Non-Clinical) and Reported Device Performance
The document describes non-clinical testing against requirements for performance and safety. The acceptance criteria are broadly defined as meeting "design inputs and user needs" and "design and cyber security requirements."
| Acceptance Criteria Category (Non-Clinical) | Reported Device Performance (Non-Clinical) |
|---|---|
| Safety Assurance Case (SAC) | "Dose IQ Safety Software is adequately safe and effective for its intended use." |
- Potential risks mitigated, residual risk acceptable.
- Design verification and validation acceptable.
- Device meets clinically valid essential performance. |
| Performance and Safety Requirements | "Performance testing of the Dose IQ Safety Software was verified against requirements for performance and safety, and to provide objective evidence that the device intended use is met." - "Validation demonstrated that design inputs and user needs were met."
- "System verification demonstrated that design outputs meet design and cyber security requirements. All the testing met acceptance criteria." |
| Software Verification and Validation (FDA Guidance) | Per FDA guidance "Guidance for the Content of Premarket Submission for Software Contained in Medical Devices" (2005) (considered a major level of concern): - "Software testing included Functional testing. Regression Testing. Smoke & Sanity testing, code review, static analysis, and unit testing."
- Outcome: All testing met acceptance criteria. |
| Human Factors Evaluation (Usability) | Per IEC 62366-1ed. 1.0 b:2015 and FDA guidance "Applying Human Factors and Usability Engineering to Medical Devices" (2016): - Conducted in a simulated environment with intended user population, use environment, and scenarios.
- Outcome: "Results of the human factors study show the device is suitable for its intended use." |
2. Sample Size Used for the Test Set and Data Provenance:
The document does not specify a "sample size" for a test set in the traditional sense of a clinical study (e.g., number of patients/cases). The testing described is software verification and validation, and human factors testing.
- Software Testing: These tests typically involve testing code against requirements, not patient data in the sense of a clinical study. The document mentions "Functional testing. Regression Testing. Smoke & Sanity testing, code review, static analysis, and unit testing." The "test set" would be the collection of test cases designed to cover software functionalities and requirements.
- Human Factors Evaluation: Conducted in a "simulated environment." The "sample size" for this would be the number of "intended user" participants. This number is not specified in the document.
- Data Provenance: Not applicable for clinical data. The tests are focused on software functionality, safety, and usability in simulated environments.
3. Number of Experts Used to Establish Ground Truth for the Test Set and Qualifications:
Not applicable in the context of this submission. The "ground truth" for software functionality is defined by the design requirements and specifications themselves. For the human factors study, the "intended user population" was involved, but specific expert qualifications or adjudication for establishing a "ground truth" in terms of diagnostic reads or outcomes are not relevant to this type of testing.
4. Adjudication Method for the Test Set:
Not applicable, as there is no mention of a human-in-the-loop diagnostic study requiring adjudication.
5. If a Multi-Reader Multi-Case (MRMC) Comparative Effectiveness Study Was Done:
No. The document explicitly states: "No clinical testing was performed in support of this premarket notification." Therefore, no MRMC study or assessment of human reader improvement with AI assistance was conducted or reported.
6. If a Standalone (i.e., algorithm only without human-in-the-loop performance) Was Done:
The "Dose IQ Safety Software" is a standalone software application ("not embedded in pumps") that allows pharmacists to "create and maintain drug libraries." Its function is to configure pump settings. The "performance" assessment focuses on whether the software correctly generates these drug libraries according to specifications, and whether it is usable by pharmacists. Therefore, the non-clinical testing described effectively is a "standalone" performance assessment of the software's ability to meet its functional requirements and safety objectives. The document doesn't provide specific quantitative metrics of its "performance" (e.g., accuracy, precision) in the way one would for a diagnostic AI, but rather confirms its successful verification and validation.
7. The Type of Ground Truth Used:
- For software functionality: The "ground truth" is based on the defined "design input requirements" and "user needs."
- For human factors: The "ground truth" is based on the objectives of usability and safety in simulated clinical conditions, assessed by the "intended user population."
8. The Sample Size for the Training Set:
Not applicable. This is a software application for creating drug libraries, not a machine learning or AI model that is "trained" on a traditional dataset (e.g., medical images for diagnosis). The software's logic and rules are presumably programmed based on medical and engineering specifications relevant to infusion pump operation and drug administration safety.
9. How the Ground Truth for the Training Set Was Established:
Not applicable, as there is no "training set" in the context of machine learning. The "ground truth" for the software's design and functionality is established through established medical device development processes, regulatory standards, clinical guidelines for drug administration, and engineering specifications for infusion pumps.
§ 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).