Search Results

The Phoenix® Hemodialysis delivery system is intended to be used to provide high flux and low flux hemodialysis, hemofiltration and ultrafiltration on patients weighing 15 Kilograms or more. The Phoenix system is to be used with either high or low permeability dialyzers. The device is intended to be used by trained operators when prescribed by a physician, in a chronic care dialysis facility or acute care unit.

Phoenix is a self-contained, microprocessor-controlled device that provides hemodialysis, hemofiltration and ultrafiltration therapies. The system consists of the Hemodialysis Machine in use with a blood tubing set designed for the machine, a dialyzer, a heparin-filled syringe, a BiCart® column (sodium bicarbonate powder), and other appropriate dialysate concentrates. The machine has many built-in features which are intended to enhance the ease of providing patient dialysis treatments. The Phoenix Hemodialysis Machine pumps blood from the patient, in a blood tubing set properly designed for the machine, through the dialyzer where purification takes place, and back to the patient. In the dialyzer, the blood and the dialysate fluid flow on opposite surfaces of a thin Semipermeable membrane. As the blood passes through the filter, the desired treatment processes take place. Depending upon the therapy in use, the treatment processes can include fluid removal and/or solute clearance. Phoenix has a modular structure. It is made up of five modules that carry out independent functions: Master Module, Hydraulic Module, Blood Module, Protection Module and Bio Module. The unit consisting of the Master, Hydraulic and Blood Modules is called the Control System. The Control System manages the implementation of the physical functions.

The provided document describes a Special 510(k) submission for the Phoenix® Hemodialysis Delivery System - version 3.40. This type of submission is used when the modification to a previously cleared device (the predicate device, in this case, Phoenix® version 3.35) does not affect the intended use or fundamental scientific technology. Therefore, the acceptance criteria and the study performed focus on demonstrating that the updated software (version 3.40) maintains equivalence and does not degrade the safety or effectiveness of the device compared to the predicate.

Here's an analysis of the requested information:

1. Table of Acceptance Criteria and Reported Device Performance

The acceptance criteria for this Special 510(k) are primarily based on maintaining the performance parameters of the predicate device (Phoenix® version 3.35) and ensuring that the new software version (3.40) does not negatively impact these. The "reported device performance" is essentially that the updated device meets or exceeds the specifications of the predicate.

The key "performance improvement" highlighted in relation to the acceptance criteria is the elimination of manual calculations for low weight - low volume sets with software version 3.40. Previously, users had to divide displayed blood flow, liters processed, and pump speed by 4 to get actual values. The new software directly displays the actual values, which is a usability and safety enhancement.

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

The document does not explicitly state a "sample size" in the conventional sense (e.g., number of patients or cases) for a test set. This is because no clinical studies were performed for this software modification (Page 4). The testing performed was non-clinical performance data, consisting of verification and validation activities for the software and the system.

The data provenance is internal to the manufacturer's development and testing processes; there's no mention of external data sources or country of origin for a specific "test set" in the context of clinical data. It falls under "retrospective" in the sense that the testing was based on the existing device design and specifications.

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

Since no clinical studies were performed and the testing was non-clinical, there isn't a "ground truth" derived from expert clinical opinion in the traditional sense for a test set of patient data.

Instead, the "ground truth" for the non-clinical testing was established by:

• System and software requirements and specifications.
• International safety standards (IEC 60601-1-2, 60601-2-16, 60601-1-4, 60601-1-6, 62366).
• The performance of the legally marketed predicate device (version 3.35).

The experts involved would be the manufacturer's software engineers, quality assurance personnel, regulatory affairs specialists, and potentially clinical representatives who defined and verified these requirements and standards. Their qualifications would be in their respective technical and domain expertise.

4. Adjudication Method for the Test Set

Again, given the non-clinical nature of the testing, there was no "adjudication method" in the sense of multiple experts reviewing and reaching a consensus on clinical outcomes or images.

The verification and validation activities inherently involve review and approval processes by qualified personnel. These would include:

• Static activities: impact analysis, final phase reviews, code inspections.
• Dynamic tasks: baseline verification, system and software test protocols execution, regression testing, Graphical User Interface and Use Cases test execution.

These processes ensure that the software performs as intended and meets specifications, which is a form of "adjudication" through technical review and testing.

5. If a Multi-Reader Multi-Case (MRMC) Comparative Effectiveness Study Was Done, and Effect Size

No, a Multi-Reader Multi-Case (MRMC) comparative effectiveness study was not done. The document explicitly states: "No clinical studies were performed for the software modification." Therefore, there is no effect size reported for human readers with or without AI assistance.

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

The device is a hemodialysis delivery system, which is a piece of medical equipment, not an AI algorithm in the contemporary sense. It is microprocessor-controlled and performs automated functions, but it always operates with a human-in-the-loop (trained operators). The "standalone" performance thus encompasses the device's ability to execute its programmed functions accurately and safely on its own, but within the context of human use and oversight.

The non-clinical performance data focuses on this "standalone" (device-only) functionality through:

• Static activities (code reviews, impact analysis).
• System and software functional tests.
• Regression testing.
• Graphical User Interface and Use Cases test execution.

These tests verify the algorithm's (software's) internal logic and its interaction with the hardware.

7. The Type of Ground Truth Used

The ground truth used for this submission is based on:

• Technical specifications and performance requirements defined by the manufacturer.
• Compliance with international safety standards (relevant IEC standards listed).
• Functional equivalence to the legally marketed predicate device (Phoenix® version 3.35).
• Usability requirements verified through formative and summative usability validation.

It is not based on expert consensus for clinical diagnosis, pathology, or patient outcomes data, as no clinical studies were performed.

8. The Sample Size for the Training Set

This question is not applicable in the context of this device and submission. The Phoenix® Hemodialysis Delivery System is a hardware/software medical device that performs defined physiological functions, it is not an AI/Machine Learning algorithm that undergoes a "training phase" with a "training set" of data in the manner typically associated with such terms.

The software development would involve stages of coding, unit testing, integration testing, and system testing, which are forms of continuous verification and validation, but not "training" with a distinct "training set" of data for learning purposes.

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

As established in point 8, there is no "training set" in the context of this device. Therefore, the ground truth for a training set was not established.

Ask a specific question about this device

The Phoenix® Hemodialysis delivery system is intended to be used to provide high flux and low flux hemodialysis, hemofiltration and ultrafiltration on patients weighing 15 Kilograms or more. The Phoenix system is to be used with either high or low permeability dialyzers. The device is intended to be used by trained operators when prescribed by a physician, in a chronic care dialysis facility or acute care unit.

Phoenix® is a self-contained, microprocessor-controlled device that provides hemodialysis and ultrafiltration-only therapies. The system consists of the Hemodialysis Machine in use with a blood tubing set designed for the machine, a dialyzer, a heparin-filled syringe, a BiCart® column (sodium bicarbonate powder), and other appropriate dialysate concentrates. The machine has many built-in features which are intended to enhance the ease of providing patient dialysis treatments. Phoenix® has a modular structure.

The provided text describes a 510(k) submission for the Phoenix® Hemodialysis Delivery System 3.35. This document focuses on demonstrating substantial equivalence to a predicate device and includes information about nonclinical testing.

Here's an analysis to extract the requested information:

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

The document uses the predicate device (Phoenix® Hemodialysis Delivery System Version 3.00) as a benchmark for acceptance criteria and performance. The performance metrics for the modified device (Version 3.35) are compared directly against those of the predicate. The "Accuracy" values for the modified device represent 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 mentions "component level hardware testing," "static and dynamic software testing (e.g., unit testing, code inspections, testing targeted to the changes implemented in software version 3.35, regression testing)," and "human factors evaluations." However, it does not specify sample sizes for these tests, nor the country of origin or whether the data was retrospective or prospective. The information points to internally conducted engineering and software verification and validation activities.

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 states that testing was performed by "internal and external independent personnel with the appropriate skills" for the nonclinical testing and human factors evaluations. However, it does not specify the number of experts, their qualifications, or their role in establishing a ground truth for a test set. The context is about engineering and system performance validation, not clinical image interpretation or diagnosis.

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

The document does not describe any adjudication method for a test set. This type of method is typically associated with studies involving human interpretation (e.g., radiology reads) where discrepancies need resolution. The testing described is primarily technical performance validation.

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 comparative effectiveness study was done or mentioned. This submission is for a medical device (hemodialysis system), not an AI-powered diagnostic tool, and therefore, the concept of "human readers improving with AI assistance" is not applicable to the context of this device.

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

This refers to the performance of the device itself (the "algorithm only" in this context refers to the device's automated functions). The entire nonclinical testing section, which evaluated parameters like flow rates, accuracies, and pressures, represents standalone performance testing of the Phoenix® System 3.35. The tables directly report these standalone performance metrics.

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

For the nonclinical testing, the "ground truth" would be established by controlled engineering measurements against known standards and specifications. For example, a calibrated flow meter would provide the "ground truth" for blood flow rate accuracy, or a calibrated pressure sensor for pressure measurements. These are physical and electrical measurements, not expert consensus, pathology, or outcomes data in the clinical sense.

8. The sample size for the training set

The document does not mention a training set sample size. This is not an AI/machine learning device that typically requires a large training dataset. The development and testing revolve around hardware and software engineering principles.

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

Since there is no mention of a training set, there is no information on how its "ground truth" was established.

Ask a specific question about this device

Ask a specific question about this device