Search Results

The BD Intelliport™ System is an automated record keeping system that incorporates patient safety features that are aligned with hospital patient records and protocols. The system is comprised of an injection port and software that enables the identification, measurement, alerting and documentation of the administration of medications to patients.

The BD Intelliport™ System allows the clinician to record anesthesia-related medication administration events during pre-procedure, intra-procedure and recovery phase. The system is indicated for use by healthcare professionals in a hospital or medical center setting with patients who are receiving manually administered bolus intravenous injections as part of their care to facilitate documentation of the medications.

The BD Intelliport™ System is intended for patients with body weights >20 kg.

Do not use the BD Intelliport™ System with blood, blood products, biologics, or chemotherapeutics.

BD Intelliport™ System integrates into an intravenous line and automatically captures information about the anesthesia medications administered to the patient. It wirelessly transmits anesthesia medication administration information to the patient's Electronic Medical Record (EMR) via hospital server applications (Gateway software). The BD Intelliport™ System provides core technologies that enable key functions of the system:
• Medication Identification: Informs clinician of medication and concentration along with any informational notifications such as patient allergy and expired medication reminders. This occurs when syringes with the correct type of RFID encoded label are attached.
• Dose Measurement: Measures volume of drug administered to the patient through the system, then calculates dose weight.
• Automatic Charting: Wirelessly transmits measured doses to the EMR.

The following are the main system components:
• BD Intelliport™ Injection Site which is comprised of the following two components:

• BD Intelliport™ Sensor
• BD Intelliport™ Reader
  • BD Intelliport™ Mount (optional accessory)
  • BD Intelliport™ 2-Bay Charger (accessory)
  • BD Intelliport™ Gateway

The provided FDA 510(k) clearance letter and summary for the BD Intelliport™ System (K243062) describes the performance testing conducted to demonstrate substantial equivalence to its predicate device (K182092). However, it does not provide specific acceptance criteria or reported device performance values in a quantifiable table format, nor does it detail a standalone study with quantitative results, or a multi-reader multi-case (MRMC) comparative effectiveness study.

The document primarily focuses on demonstrating substantial equivalence through a comparison of technological characteristics and a list of performance tests completed.

Here's an attempt to structure the answer based on the available information, with caveats where data is missing:

Acceptance Criteria and Device Performance

The 510(k) summary states that "The subject device, the BD Intelliport™ System, has met all predetermined acceptance criteria for the non-clinical and human factors testing conducted in accordance with relevant FDA guidance, recognized consensus standards, and internal requirements." However, the specific numerical acceptance criteria and the quantitative reported device performance values for most tests are not explicitly stated in the provided document.

The only quantitative performance criteria and reported values mentioned are for "Volume measurement accuracy" and "Volume Measurement Resolution."

Note: The document states these are "Identical" to the predicate device, implying the reported performance matches the specified criteria.

Study Information

Due to the nature of a 510(k) summary, detailed study reports with specific quantitative results (beyond volume measurement accuracy) are not included. The document generally refers to "performance testing" and "human factors evaluation."

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

   • Test Set Sample Size: Not explicitly stated for each test. For "Volume Measurement Performance Window," the volume range tested was 0.5ml to 30ml, and average push speed 10ml/min to 400 ml/min. This implies tests were conducted across this range, but the number of injections or trials is not provided.
   • Data Provenance: Not explicitly stated (e.g., country of origin). The studies appear to be non-clinical (laboratory-based) and human factors studies. The human factors testing likely involved simulated clinical environments.

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

   • Not applicable/Not provided within the scope of this 510(k) summary. These types of details are usually found in full study reports, not the summary itself, especially for a device that primarily automates record-keeping and measurement, rather than making diagnostic assessments that require expert ground truth. The human factors testing involved "intended device users," but their specific qualifications or roles in establishing "ground truth" (in a diagnostic sense) are not outlined.

3. Adjudication method for the test set:

   • Not applicable/Not provided. Adjudication methods (like 2+1, 3+1) are typically used in studies where there is disagreement in expert interpretation of diagnostic data. This device automates measurements and record-keeping, so such a method is not relevant.

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:

   • No, an MRMC comparative effectiveness study was not explicitly reported or appears not to have been the primary method for demonstrating substantial equivalence. The device's primary function is "automated record keeping" and facilitating "documentation of the medications." It improves efficiency and accuracy of recording medication administration, rather than assisting human readers in interpreting medical images or data. The human factors evaluation assessed "critical tasks completed by intended device users," implying usability and user performance with the system, not a comparison of expert diagnostic accuracy with and without AI.

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

   • The document implies that standalone (algorithm-only) performance testing was conducted for various technical attributes. For example, "Bolus volume measurement accuracy," "Sensor flow rate," "Decoding response time," "Wifi functionality," and "Dose transmission time" are intrinsic functions of the system and its algorithms, which would have been tested independently of a human operator to verify their technical specifications. The "Flow Algorithm" itself was updated and "qualified through verification testing." However, explicit, detailed results from a standalone study with acceptance criteria are not presented in a formal table like format for all algorithm-driven functions.

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

   • For the technical performance tests (e.g., volume measurement), the "ground truth" would have been established using calibrated instruments and reference standards (e.g., known volumes, known flow rates) in a laboratory setting.
   • For the human factors evaluation, the "ground truth" would be defined optimal task performance and safety outcomes as determined by medical device standards and clinical best practices.

7. The sample size for the training set:

   • The document does not provide information on a training set size. The BD Intelliport System involves embedded software and algorithms (e.g., flow algorithm, RFID reading, EMR communication). While such systems often involve development and testing cycles, the summary does not detail a specific "training set" like one would find for a machine learning or AI algorithm that learns from data in a traditional sense. The "Flow Algorithm" was updated and "qualified through verification testing," which implies validation against known physical models or experimental data, rather than a statistical "training set" in the context of deep learning.

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

   • As no "training set" is explicitly mentioned for a machine learning model, this question is not applicable in the context of the provided information. The "ground truth" for verifying the updated flow algorithm would have been established through physical experiments and engineering measurements with known parameters (e.g., precise drug volumes, flow rates) to ensure the algorithm accurately processes the sensor data.

Ask a specific question about this device

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 information collected from compatible infusion pumps. 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. It is not intended to be a substitute for good clinical management practices, nor does its operation create decisions or treatment pathways.

The LifeShield™ Data Flow Management (DFM) software product is intended to facilitate bi-directional communication with compatible infusion pumps, information technology systems, and other LifeShield™ Infusion Safety Software Suite products. LifeShield™ DFM provides a way to automate the programming of infusion parameters, thereby decreasing the number of manual steps necessary to enter infusion data. LifeShield™ DFM forwards infusion-related information received from the infusion pump to compatible information technology systems.

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™ Precision IV infusion pump and Plum Solo™ Precision IV 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 is used by pharmacists to create approved drug libraries that can be downloaded by the infusion pumps. The latest software version introduces enhancements to its user interface and additional drug library settings for support of Plum Duo™ and Plum Solo™ pumps.

The LifeShield™ Clinical Dashboards & Reports (CDR) software is used by clinical administrators to view infusion or device-related information received from the infusion pumps via the LifeShield™ DFM. The information presented by the software does not create decisions or treatment pathways for patients. The latest version of the software improves the data presented for ongoing infusions and dashboards.

LifeShield™ Data Flow Management (DFM) software facilitates bidirectional communications between the infusion pump and hospital information systems (HIS); it routes pharmacy-validated orders to the connected pumps and infusion-related information to the HIS. The latest software version adds the ability to forward alarms to the HIS.

The provided FDA 510(k) clearance letter for the LifeShield™ Infusion Safety Software Suite (K242117) does not contain the specific details required to construct a table of acceptance criteria with reported device performance, nor does it detail a study that proves the device meets specific performance criteria in terms of accuracy or clinical outcomes.

This document primarily focuses on demonstrating substantial equivalence to a predicate device (K223606) based on non-clinical testing (design verification, design validation, cybersecurity, risk management, and human factors) and software modifications, rather than performance metrics related to clinical accuracy or diagnostic capabilities (which would be more common for AI/ML devices in image analysis, for example).

The submission explicitly states:

• "Summary of Clinical Testing: Not applicable. A clinical study is not required for this submission to support substantial equivalence."

Therefore, I cannot fulfill all parts of your request as the information is not present in the provided text. The device is a software suite for managing infusion pump data, not an AI/ML diagnostic or predictive tool that would have performance metrics like sensitivity, specificity, or AUC against a ground truth of disease.

However, I can extract information related to the types of testing performed and what they aimed to prove, which indirectly serve as acceptance criteria for this type of software device.

Analysis of Acceptance Criteria and Study Details based on the Provided Document

Given the nature of the device (infusion safety software suite) and the information provided in the 510(k) summary, the "acceptance criteria" here are aligned with software quality, safety, and functionality, rather than clinical performance metrics typically associated with AI/ML diagnostic tools.

The study proving the device meets acceptance criteria is a comprehensive set of non-clinical tests described below, rather than a single clinical trial.

1. Table of Acceptance Criteria and the Reported Device Performance

Since this is not an AI/ML diagnostic device with performance metrics like accuracy, sensitivity, or specificity against disease presence, the "acceptance criteria" relate to software design, functionality, safety, and usability. The document reports that all these tests "pass established acceptance criteria."

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

• Test Set Sample Size: The document does not specify a "sample size" in terms of patient data or clinical cases. For software verification and validation, the "test set" would consist of numerous test cases, simulated use scenarios, and functional tests. These numbers are not detailed in the summary.
• Data Provenance: Not applicable in the traditional sense of patient data. The testing is focused on software functionality, safety, and usability. There is no mention of retrospective or prospective data collection from patients or clinical settings for performance evaluation.

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

• Ground Truth Establishment: For this type of software, "ground truth" isn't established by clinical experts in the same way it would be for a diagnostic image. Instead, it's defined by design specifications, regulatory requirements, industry standards (e.g., IEC 62304, ISO 14971, IEC 62366-1), and best practices in software engineering and cybersecurity.
• Experts: The development team, regulatory affairs, quality assurance, and potentially third-party cybersecurity and human factors experts would define and verify these "ground truths" (i.e., whether the software behaves as intended and safely). The specific number or qualifications of these internal or external experts is not detailed in the provided K summary. The human factors study implies the use of representative users (trained healthcare professionals), but not necessarily "experts" defining a ground truth about a medical condition.

4. Adjudication Method for the Test Set

• Not applicable in the context of clinical expert adjudication of medical cases. Adjudication in software testing would involve bug reporting, resolution, and re-testing processes managed by the development and QA teams, not described here.

5. If a Multi-Reader Multi-Case (MRMC) Comparative Effectiveness Study was done

• No, an MRMC study was not done. The document explicitly states: "Summary of Clinical Testing: Not applicable. A clinical study is not required for this submission to support substantial equivalence." An MRMC study is a type of clinical study often done for diagnostic AI to compare human performance with and without AI assistance. This device is not a diagnostic AI.

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

• This concept is not directly applicable. The "LifeShield™ Infusion Safety Software Suite" is inherently a human-in-the-loop system designed to assist trained healthcare professionals. It manages data, facilitates communication, and supports drug library management but does not "decide" or "treat" on its own. Its "standalone" performance would pertain to its functional correctness in processing data and facilitating communication, which is covered by the general "design verification" and "performance" testing.

7. The Type of Ground Truth Used

• The "ground truth" for this software pertains to its functional correctness, adherence to specifications, safety requirements, cybersecurity posture, and usability standards. It is not based on clinical "outcomes data" or "pathology" in the medical sense, but rather on:
  • Design Specifications: Whether the software performs its programmed functions as intended.
  • Regulatory Standards: Compliance with relevant medical device software (IEC 62304), risk management (ISO 14971), and human factors (IEC 62366-1) standards.
  • User Needs/Requirements: Whether the software meets the needs of its intended users in its intended environment.

8. The Sample Size for the Training Set

• Not applicable. This device is a software suite, not an AI/ML model that undergoes a "training phase" with a distinct "training set" of data to learn patterns. The software's capabilities are based on explicit programming and configuration, not machine learning from a dataset.

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

• Not applicable, as there is no "training set" for this type of software.

In summary, the FDA 510(k) clearance for the LifeShield™ Infusion Safety Software Suite is based on a demonstration of substantial equivalence to a predicate device through extensive non-clinical software verification and validation, risk management, cybersecurity testing, and human factors analysis. The "acceptance criteria" are related to software quality, safety, and functionality, rather than clinical performance metrics against a medical ground truth or AI model training data.

Ask a specific question about this device

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.

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.

Ask a specific question about this device

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.

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.

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:

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.

Ask a specific question about this device

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."

• 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.

Ask a specific question about this device

Vigilant Master Med is part of a Dose Error Reduction System (DERS) for use with Adults, Pediatrics, and Neonates. It is intended to create, customize, and manage drug library data and device configurations to be uploaded to compatible Fresenius Kabi infusion devices which may reduce the risk of drug administration errors. It enhances safety by preventing infusion errors with the use of Dose Error Reduction System (DERS) in combination with the infusion devices.

Vigilant Master Med is a drug library software that is used by pharmacists to create and identify limits according to policy and procedure of the institution. The infusion devices will notify and clearly indicate to a clinician if the dose for the medication is beyond the limits entered by the pharmacist and provided by Vigilant Master Med in the drug library.

Vigilant Master Med is one component of Vigilant Software Suite (VSS) a multifunction device product. VSS Vigilant Master Med the subject of this submission, is also referred to as Drug Library Software. VSS Vigilant Master Med is drug library software that creates, customizes and manages drug lists, therapies, drug libraries, device configurations, profiles and data sets which are uploaded into compatible infusion pumps.

The provided text describes the 510(k) premarket notification for the "Vigilant Software Suite - Vigilant Master Med" and its comparison to a predicate device, "Vigilant Drug' Lib Agilia." However, the document primarily focuses on demonstrating substantial equivalence based on non-clinical testing and technological comparison. It explicitly states that "Clinical evaluation is not required for this submission to support substantial equivalence." and "no further clinical investigation or testing is needed."

Therefore, I cannot provide details on the acceptance criteria or a study that proves the device meets specific performance criteria in a clinical context, as such data is not included in the provided text. The submission relies on verification and validation of product requirements, human factors engineering testing, interoperability testing, performance testing at maximum capacity, and cybersecurity testing to demonstrate safety and effectiveness, and thus substantial equivalence.

Based on the information provided in the document, here's what can be extracted:

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

The document implicitly defines "acceptance criteria" through the comparison to the predicate device and the findings of non-clinical tests. The "reported device performance" is essentially the determination of "Similar," "Same," or "Different" with supporting statements that these differences do not affect safety or effectiveness, or that verification/testing found no new issues.

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

• Sample Size: The document does not specify exact "sample sizes" in terms of number of cases or data points for the non-clinical tests (verification, human factors, interoperability, performance, cybersecurity testing). It refers to the sufficiency of these tests to conclude safety and effectiveness.
• Data Provenance: Not specified in terms of country of origin. The data is generated from non-clinical (laboratory/engineering) testing rather than patient data. The studies are prospective in the sense that they are specifically conducted for the regulatory submission to verify and validate the new device.

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

• Number of Experts: Not explicitly stated. The "ground truth" for this device (software for managing infusion pump drug libraries) would primarily be established by:
  • Engineers/Developers: Defining correct software functionality and performance.
  • Quality Assurance personnel: Verifying adherence to requirements.
  • Human Factors Specialists: Assessing usability and safety in simulated clinical tasks.
  • Pharmacists and Clinicians (as users): Participating in human factors evaluations to ensure the software's design supports their workflow and safety goals. The document states "Human Factors studies have been conducted on the subject device demonstrating passing results," implying clinical domain experts were involved in a user capacity.
• Qualifications of Experts: Not explicitly stated for specific roles. However, given the context of medical device regulation, these would be qualified professionals in their respective fields (e.g., software engineers, human factors engineers, clinical experts - likely pharmacists and nurses for an infusion pump system).

4. Adjudication method for the test set:

• Since no multi-reader or multi-expert assessment of clinical "cases" is described (as it's a software substantial equivalence submission based on non-clinical tests), there is no mention of an adjudication method like 2+1 or 3+1. The "adjudication" is implicitly the outcome of the comprehensive verification and validation processes and the safety assurance case.

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:

• No MRMC study was done. This is not an AI-assisted diagnostic device where human reader improvement would be measured. The device is a software for drug library management for infusion pumps, not a medical image analysis or similar AI tool.

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

• The software's core function is to create and manage drug libraries, which is "algorithm only" in its processing of data and rules. However, its purpose is to be used with human-in-the-loop (pharmacists inputting data, clinicians interacting with the infusion pump).
• Standalone algorithmic verification: Yes, this is implied by "Verification testing of product requirements," "Performance testing at maximum capacity," and "Cybersecurity penetration testing." These tests assess the software's inherent functionality and robustness independent of user interaction, but within the context of its overall intended use.

7. The type of ground truth used:

• The primary "ground truth" used for this submission is:
  • Pre-defined product requirements and specifications: The software must perform according to these.
  • Safety standards and regulatory guidance: Adherence to these is the "truth" for demonstrating safety and effectiveness.
  • Usability goals derived from human factors analysis: The software's design must support safe and effective use by intended users.
  • Functionality of the predicate device: The new device's functions are compared to the legally marketed predicate.
• It is not based on expert consensus for clinical diagnosis, pathology, or outcomes data, as this is not a diagnostic device.

8. The sample size for the training set:

• Not applicable/Not provided. This is a traditional software engineering development and a 510(k) submission based on substantial equivalence, not a machine learning/AI model that requires a "training set" for its development. The "learning" here is human engineering and design, not algorithmic learning from data.

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

• Not applicable. As stated above, there is no "training set" in the machine learning sense.

Ask a specific question about this device

The BD Intelliport™ system is an automated record keeping system that incorporates patient safety features that are aligned with hospital patient records and protocols. The system is comprised of an injection port and software that enables the identification, measurement, alerting and documentation of the administration of medications to patients.

The BD Intelliport™ system allows the clinician to record anesthesia-related, medication administration events in the pre-op, intra-op, and PACU. The system is indicated for use by healthcare professionals in a hospital or medical center setting with patients who are receiving manually administered bolus intravenous injections as part of their care to facilitate documentation of the medications.

The BD Intelliport™ system is intended for patients whose body weights are >20kg.

The BD Intelliport™ system is not intended for use with blood, blood products, biologics, or chemotherapeutics.

The BD Intelliport™ system is not intended for use with refrigerated medications (excluding cefazolin)

Like the cited predicate device, the BD Intelliport Medication Management System, Version 1.2 is a system of hardware and software components that measures the delivered volume of intravenous (IV) bolus medications associated with anesthesiarelated, medication administration events in the pre-op, intra-op, and PACU, and provides automated documentation of medication identity, concentration, dose, delivered volume, and delivery timestamp to the hospital electronic medical record (EMR) system. There are two modes: EMR mode and Standalone mode. Standalone mode allows for printing dose history reports, but is not connected to an EMR

The device is organized by three subsystems, each of which includes several physical/software components:

• . Injection Site subsystem
• . Tablet subsystem
• . Gateway subsystem

The Injection Site subsystem is composed of two physical components (the Base and the ultrasonic Sensor) and the software residing inside the Base. The Tablet subsystem is composed of one physical component (the Tablet) and the software residing inside the Tablet. The Gateway subsystem consists of the Gateway software and the hospital server hardware on which the Gateway software resides. The device also includes an accessory for charging up to five Bases simultaneously.

During treatment, the clinician connects an intelligent injection port (the Injection Site) to a patient's fluid-delivery line and performs standard drug-delivery activities. The clinician injects the druq using BD Luer Lok, 1-60ml size syringes only, and then flushes with a separate normal, saline syringe. Flushing after each administration ensures all medication is administered to patient since there is a 0.334 ml dead space.

The device can be used with both encoded and non-coded syringes. If an encoded syringe is used, the device reads the two-dimensional barcode adhered to the syringe. The barcode contains information about the content in the syringe including the drug name and concentration. If a noncoded syringe is used, then the end user is prompted by the Tablet software to pick the drug name and concentration from the Encoded Drug List (EDL). When an encoded syringe is first connected to the device, the name of the drug is read back to the clinician and an allergy alert will trigger on the Injection Site base if the patient is allergic to the medication based on the patient's allergies record in their EHR (electronic health record). As the drug is injected, the device measures the volume of the injected drug via an ultrasonic sensor and records the time the drug was administered. Drug delivery information is stored and inserted into the patient's EHR by way of the Tablet and Gateway software in the EMR mode and available for printing in the Standalone mode.

Please find the requested information regarding the acceptance criteria and the study that proves the device meets the acceptance criteria for the BD Intelliport System, Version 1.2.

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 does not explicitly state the sample size for the test set in quantitative terms for the identified performance criteria. For volume measurement accuracy, it states "Testing was conducted on a set of drugs commonly used in Anesthesia, bracketed based upon speed of sound and solvent/dissolved solids composition," implying multiple drugs were tested.

The document does not provide information on the country of origin of the data or whether the data was retrospective or prospective. The study appears to be bench and simulated human use testing, rather than clinical data from human patients.

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)

The document does not specify the number of experts or their qualifications for establishing ground truth within the context of the technical performance testing (e.g., volume accuracy). For human factors testing, it refers to "intended device users" and "clinicians," but does not detail their number or specific qualifications for establishing ground truth beyond their role as users.

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

The document does not describe any specific adjudication method for establishing ground truth for the technical performance test sets. For human factors testing, it implies evaluation by human factors experts (though not explicitly stated as '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

There is no indication that a multi-reader multi-case (MRMC) comparative effectiveness study was performed. The device is described as an "automated record keeping system" and the studies reported are primarily non-clinical performance testing and simulated human use testing, not studies comparing human reader performance with and without AI assistance.

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

Yes, standalone (algorithm only) performance was assessed for aspects like volume measurement accuracy. The "Modification of the volume measurement algorithm to improve accuracy and precision" implies testing of the algorithm itself. The system also has a "Standalone mode" which allows for printing dose history reports without EMR connection, suggesting functionality independent of real-time human interaction for certain tasks.

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

For volume measurement accuracy, the ground truth would likely be established through precise, laboratory-grade measurements of administered fluid volumes using calibrated equipment, comparing these to the device's reported measurements. The document mentions "Testing was performed to ensure that the device volume measurements meet the volume accuracy specification with real drugs," which supports this interpretation. For software functionalities like error messages and drug tables, the ground truth would be based on predefined software requirements and verification of their correct implementation.

8. The sample size for the training set

The document does not provide information about a "training set" or its sample size. The studies described are primarily verification and validation testing of the device's performance against specifications, rather than development or training of a machine learning model.

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

As no training set is described in the provided text, there is no information on how its ground truth was established.

Ask a specific question about this device

The BD Intelliport System is an automated record keeping system that incorporates patient safety features that are aligned with hospital patient records and protocols. The system is comprised of an injection port and software that enables the identification, measurement, alerting and documentation of medications to patients.

The BD Intelliport System allows the clinician to record anesthesia related medication events in the pre-op, intra-op, and PACU areas. The system is indicated for use by healthcare professionals in a hospital or medical center setting with patients who are receiving manually administered bolus intravenous injections as part of their care to facilitate documentation of the medications.

The BD Intelliport System is used for automated documentation of medication, concentration, dose, volume and time of each IV injection for when intravenous bolus injections of medication are given to a patient.

During treatment, the clinician connects an intelligent injection port, called the Intelliport device, to a patient's fluid-delivery line and performs standard drug-delivery activities. The health practitioner injects the drug; the Intelliport reads the 2-D barcode adhered to the syringe containing the drug such as Becton Dickinson syringe K110771. This barcode contains the drug name and concentration. As the drug is injected, the Intelliport measures the volume of the injected drug and the time the drug was administered. Once the drug has been administered, the Intelliport transmits all of the information to an electronic record maintained by the Computer.

The provided text describes the BD Intelliport System, its indications for use, and a comparison to a predicate device (DocuSys Anesthesia Information and Digital-Drug Management System) to establish substantial equivalence. It also mentions performance testing. However, it does not provide a detailed study report that proves the device meets specific acceptance criteria with the level of detail requested in the prompt.

Therefore, I cannot fully complete all sections of your request based solely on the provided text. I will extract the information that is present and note where details are missing.

1. Table of Acceptance Criteria and Reported Device Performance

Note: The document explicitly states the accuracy of the BD Intelliport System, but it doesn't frame it as a "pre-defined acceptance criterion" in the same way a study protocol would. Instead, it justifies this performance by comparison to the predicate's reported accuracy (with a clarification on calculation methods) and manual syringe activation.

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

The document mentions "performance testing for the BD Intelliport System includes software unit testing and code reviews (verification), system validation testing, and testing to compliance standards for electrical and electromagnetic safety."

• Sample Size: Not specified for any specific test set.
• Data Provenance: Not specified. (e.g., country of origin, retrospective/prospective). The tests likely occurred in a lab or simulated environment.

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

Not specified in the provided text. The performance testing described appears to be technical in nature (software, electrical, volumetric accuracy) rather than requiring expert clinical assessment for ground truth.

4. Adjudication Method for the Test Set

Not specified.

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

Not applicable. This device is an automated record-keeping system with measurement capabilities, not an AI-assisted diagnostic tool that would typically involve human "readers" or interpretations. The comparison is between the BD Intelliport System and a predicate system, both of which are automated.

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

The accuracy testing for drug delivery (± 5% for bolus volumes > 1.0 mL to 55 mL and ± 20% for bolus volumes of 0.4 to 1.0 mL) can be considered standalone performance, as it quantifies the device's measurement capability independent of a human's interpretation of that measurement. The device itself is designed to automate aspects of medication administration documentation, which is inherently a "standalone" function in terms of data capture and measurement.

7. The Type of Ground Truth Used

For the accuracy testing of drug delivery, the ground truth would likely be established by controlled laboratory measurements using highly accurate reference instruments or gravimetric methods to determine the actual volume delivered, against which the BD Intelliport System's reported volume is compared. This is implied by the statement "Testing of the BD Intelliport System syringe delivery is conducted in accordance with the bolus delivery requirements as defined in IEC 60601-2-24 (Particular requirements for the safety of infusion pumps and controllers)."

8. The Sample Size for the Training Set

Not applicable/Not specified. The BD Intelliport System is described as a system for identification, measurement, alerting, and documentation of medications. It is not presented as an AI/ML device that requires a "training set" in the context of learning algorithms. Its functionality is based on predefined logic, sensors (ultrasonic for volume), and barcode scanning.

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

Not applicable, as no training set for an AI/ML model is indicated.

Ask a specific question about this device

Device Specific Reports provide the user information compiled from data generated by networked devices and stored in the PharmGuard Server. This information may be used to support continuous quality improvement programs. Reports generated from the data can be used to analyze and trend various aspects of the designated infusion pump systems and therapies used.

The Medfusion® 4000 Pump Device Specific Reports Software, Version 2.0 software is a medical device intended to be used in the analysis of infusion data, provide information used in forming clinical workflow decisions and improve infusion safety. The Medfusion® 4000 Pump Device Specific Reports Software, Version 2.0 is an infusion pump accessory compatible with the PharmGuard® Server, which stores data exported from networked infusion pumps. The Medfusion® 4000 Pump Device Specific Reports Software, Version 2.0 copies data from the PharmGuard® Server databases and uses it to create reports.

The Medfusion® 4000 Pump Device Specific Reports Software, Version 2.0 can be used for transferring, displaying or storing and retrieving historical clinical data, clinical and operational alarm events, fault events, power events, maintenance events, therapy and therapy change events and telemetry events that are generated by the networked infusion pumps and stored in the PharmGuard® Server. It is also intended for near real-time monitoring of infusion pump history. For the purposes of this device "near real-time" is associated with time intervals typically measured in minutes rather than in seconds or in hours.

The Medfusion® 4000 Pump Device Specific Reports Software, Version 2.0 manipulates and re-configures data to present information bevond the discrete data that is displayed on the pumps.

Reports include information on drug compliance, safety events, alarm history, drug program utilization, and pump technical status. Reports can summarize data and reveal trends in these areas by presenting results summarized by such parameters as time of day, facility, drug profile, alarm type and safety events. The information may be presented graphically, in table form and in some cases allows "drill through" to the underlying data used to produce the reports.

The Device Specific Reports Software comprises:

• . Instructions for Use and Help Files
• An executable file for launching the application .
• A Configuration Tool that provides a user interface to enter, update, and apply the . configuration parameters that operate the Data Mart associated with the Medfusion 4000® Device Specific Reports and associated SQL Server databases
• Metadata that is imported into the PharmGuard® Server System and that . determines what information within the PharmGuard® Server is available to be output via the Device Specific Report software
• Infrastructure files that interact to facilitate and coordinate the data acquisition, . storage, and processing between the PharmGuard® Repository and the Medfusion® 4000 Pump Device Specific Report data mart. The Reporting Infrastructure performs the following major tasks:
  • o Extract, Transform, and Load (ETL) data from the PharmGuard Repository into the Reporting Infrastructure data mart.
  • o Store device event data in the data mart
  • Process requests for data retrieval for device specific reports 0

I am sorry, but based on the provided text, I cannot provide a table of acceptance criteria and reported device performance or other detailed study information. The document is a 510(k) summary for the Smiths Medical Medfusion® 4000 Pump Device Specific Reports Software, Version 2.0.

Here's what the document does state regarding performance and studies:

• Performance Testing: "Smiths Medical performed software validation testing on the Medfusion® 4000 Pump Device Specific Reports Software, Version 2.0."
• Testing Conclusion: "All testing met pre-established specifications, and successfully demonstrated that the device performed as intended."
• Clinical Studies: "Human clinical studies were deemed unnecessary to evaluate the safety or effectiveness of the Medfusion® 4000 Pump Device Specific Reports Software, Version 2.0."
• Equivalence: The device was found substantially equivalent to a predicate device (K111386, Medfusion® Model 4000 Series Syringe Infusion Pump, PharmGuard® Toolbox 2.0 Medication Safety Software).

However, the document does not contain any specific details regarding:

• The actual "pre-established specifications" that served as acceptance criteria.
• The quantitative results of the "software validation testing" to show how the device performed against those criteria.
• Sample sizes for test sets or training sets.
• Data provenance, expert qualifications, adjudication methods, or ground truth types.
• Any multi-reader multi-case studies or standalone algorithm performance.

Therefore, I cannot fulfill your request for a table of acceptance criteria and reported performance, nor any of the other detailed study information, as these specifics are not present in the provided 510(k) summary.

Ask a specific question about this device