Search Filters

Search Results

Found 1 results

510(k) Data Aggregation

    K Number
    K082783
    Date Cleared
    2008-12-17

    (85 days)

    Product Code
    Regulation Number
    880.5725
    Reference & Predicate Devices
    Why did this record match?
    Reference Devices :

    K053043,K053043

    AI/MLSaMDIVD (In Vitro Diagnostic)TherapeuticDiagnosticis PCCP AuthorizedThirdpartyExpeditedreview
    Intended Use

    The CADD® -Solis Medication Safety Software - Administrator allows use of a computer to create therapy based protocol libraries to be used with the CADD®-Solis Ambulatory Infusion Pump or CADD-Prizm® PCS II Ambulatory Infusion Pump (software revision H or higher).

    The CADD"-Solis Medication Safety Software -- Point of Care allows use of a computer to send therapy-based protocols developed by the CADD® -Solis Medication Safety Software -Administrator to the CADD®-Solis Ambulatory Infusion Pump and CADD-Prizm® PCS II Ambulatory Infusion Pump (software revision H or higher).

    Device Description

    The Smiths Medical MD, Inc. CADD® -Solis Medication Safety Software, a software program that operates on commercially available personal computers or similar hardware platforms such as tablets, is designed for pump programming of the CADD -Solis Planorms such as lables, is designed for pains programming so managers infusion Pump (software revision H or higher) through a therapy-based protocol database defined by the user. The CADD®-Solis Medication Safety Software consists of an Administrator and a Point-of-Care (POC) software module that employs serial communications to send and receive pump information. Both modules are compatible with barcode scanners (or similar input devices) through various PC connections. Barcode format is determined by the user; but is limited to 20 alphanumerical characters. The CADD®-Solis Medication Safety Software does not allow duplicative Drug, Protocol or User identification entries.

    The CADD®-Solis Medication Safety Software – Administrator module allows the user to create, cdit, and save therapy-based protocols and pump settings within user-defined protocol libraries. The Administrator user determines POC user access and library editing capabilities. Other Administrator module features include barcode printing, reports, and sending and receiving pump information.

    The CADD®-Solis Medication Safety Software – Point of Care module allows the user to download therapy based protocols to the CADD® Solis Ambulatory Infusion Pump and CADD-Prizm® PCS II Ambulatory Infusion Pump (software revision H or higher) and send and receive pump settings via serial communication. Additional features include storing and printing pump program settings and reports, verifying pump settings to established protocols and viewing history logs in the easier view of a PC monitor.

    AI/ML Overview

    The provided documentation for the CADD®-Solis Medication Safety Software does not contain the detailed acceptance criteria and study information typically associated with AI/ML device evaluations. This submission is for a software that manages infusion pump protocols, essentially a data management and programming tool, not an AI/ML diagnostic or predictive device.

    Therefore, many of the requested points are not applicable or cannot be answered from the provided text.

    Here's an analysis based on the available information:

    1. Table of Acceptance Criteria and Reported Device Performance

    Acceptance CriteriaReported Device Performance
    Not specified beyond "established specifications""Based upon the information provided, the CADD®-Solis Medication Safety Software is safe, effective and performs to established specifications."

    Explanation: The document states that functional testing was performed ("Test plans associated with software validation, verification of software controlled programming functions and pump operation were performed.") and that the device "performs to established specifications." However, it does not explicitly list what those specifications or acceptance criteria were (e.g., specific error rates, performance metrics, or thresholds). This is common for software tools that are not performing diagnostic or analytical tasks with clearly defined output metrics.

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

    • Sample Size (Test Set): Not applicable. The "study" was functional testing and software validation, not a test set of medical data in the way a diagnostic AI would use.
    • Data Provenance: Not applicable. The device processes therapy-based protocols and pump settings, not patient data in the typical sense.

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

    • Number of Experts: Not applicable. Ground truth, in the context of medical image interpretation or disease diagnosis, is not relevant here. The "ground truth" for this software would be the correctness of its programming functions and its ability to accurately manage and transfer drug protocols. This would typically be verified against design specifications and user requirements by software engineers and potentially clinical users, but it's not "expert-established ground truth" in the AI/ML sense.
    • Qualifications of Experts: Not applicable.

    4. Adjudication method for the test set

    • Adjudication method: Not applicable. The software's performance was evaluated through functional testing and software validation processes, not through adjudication of medical interpretations or diagnoses.

    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. This device is a software tool for managing infusion pump protocols, not an AI-assisted diagnostic or interpretive system that would involve human readers. Clinical studies were "deemed not necessary to evaluate the safety or effectiveness."

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

    • Standalone Performance: The "functional testing" performed would generally evaluate the software's performance in isolation (standalone) against its design specifications. However, the nature of the device (protocol management for infusion pumps) inherently involves a human-in-the-loop for creating and applying these protocols to the physical pumps. It's not an algorithm that makes independent clinical decisions.

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

    • Ground Truth Type: Not applicable in the context of AI/ML evaluation. The "ground truth" for this software would be the correct execution of its programming functions and the accurate storage/retrieval/transfer of defined therapy protocols and pump settings, as per its design specifications. This is typically verified through software quality assurance processes.

    8. The sample size for the training set

    • Training Set Sample Size: Not applicable. This software is not an AI/ML model that undergoes training on a dataset. It is a deterministic software application.

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

    • Training Set Ground Truth: Not applicable. As it's not an AI/ML model, there is no training set or associated ground truth establishment process in that context.
    Ask a Question

    Ask a specific question about this device

    Page 1 of 1