Search Results

The Spectra Optia® Apheresis System, a blood component separator, is intended for use in therapeutic plasma exchange.

The Spectra Optia® Apheresis System is a centrifugal system that separates whole blood into its cellular and plasma components. The system is used therapeutically to remove and replace the removed plasma with healthy donor plasma (i.e. plasma exchange) from patients who suffer from adverse hematologic and other conditions.

The system includes a disposable Exchange Set through which the patient's blood passes, and a machine that controls the separation of blood and the removal and replacement of plasma. The Spectra Optia system's embedded software has been enhanced to reduce the likelihood of excessive platelet loss/removal during Therapeutic Plasma Exchange (TPE) procedures when there are repeated RBC spillover alerts and no remedial action is taken.

This 510(k) summary describes a software enhancement to the Spectra Optia® Apheresis System. The enhancement aims to reduce excessive platelet loss during Therapeutic Plasma Exchange (TPE) procedures when repeated RBC spillover alerts occur and no remedial action is taken.

Acceptance Criteria and Reported Device Performance

The provided documentation does not include a table of explicit acceptance criteria with numerical targets. Instead, it describes various verification activities to ensure the correct functioning of the software modifications. Since no specific performance metrics or acceptance thresholds are detailed, a table cannot be constructed as requested.

However, the "Discussion of Non-clinical Data" section implicitly outlines the areas where the device's enhanced software performance was assessed. The "Discussion of Clinical Data" explicitly states that clinical validation data were not necessary as the modifications did not impact the performance specifications of the system's therapeutic apheresis protocols.

Summary of Reported Device Performance (as inferred from the document):

Study Details

Based on the provided 510(k) summary, the study described is a non-clinical verification study for a software modification, rather than a clinical trial or a comparative effectiveness study involving human readers.

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

   • The document does not specify a "test set" in the context of patient data or clinical samples. The testing described focuses on software verification.
   • The sample sizes for the "tests to simulate expected usage profiles," "simulated use runs," and "boundary condition testing" are not explicitly stated.
   • Data provenance is not applicable in the sense of country of origin for patient data, as no clinical data was used for this 510(k) submission. All data used was generated through non-clinical simulation and testing of the software.

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

   • This information is not provided. As the study did not involve clinical data or diagnostic interpretation, the concept of "experts establishing ground truth" in the typical sense (e.g., radiologists for images) is not applicable. Software verification likely involved internal engineering and quality assurance teams.

3. Adjudication method for the test set:

   • Not applicable, as there was no interpretation of clinical data requiring adjudication.

4. If a multi-reader multi-case (MRMC) comparative effectiveness study was done:

   • No. An MRMC study was not conducted. This submission concerns a software modification to an existing therapeutic apheresis system, not a diagnostic device requiring human interpretation of results. The document explicitly states: "Clinical validation data were not necessary, as the modifications did not impact the performance specifications of the system's therapeutic apheresis protocols."

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

   • Yes, in essence. The verification described (reliability, usability, robustness, regression testing) evaluates the software's behavior and its interaction with the device, which can be considered "algorithm only" testing in the context of its function within the automated system. The software enhancement itself is designed to reduce the likelihood of excessive platelet loss when no remedial action is taken by the user, implying that the algorithm acts to mitigate issues without direct human intervention at that specific point.

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

   • For the software verification, the "ground truth" would be the expected and defined behavior of the software according to its design specifications. This is established through engineering requirements, functional specifications, and predefined output given specific inputs and boundary conditions. It is not based on biological or patient outcomes data for this submission.

7. The sample size for the training set:

   • Not applicable. This is not a machine learning model that requires a "training set." The software modification described is an update to the system's embedded software based on defined logic and rules, not learned patterns from data.

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

   • Not applicable, as no training set was used.

Ask a specific question about this device

The Spectra Optia Apheresis System, a blood component separator, is intended for use in therapeutic plasma exchange.

The Spectra Optia Apheresis System is a centrifugal system that separates whole blood into its cellular and plasma components. The system is used therapeutically to remove and exchange blood plasma in patients who suffer from adverse hematologic and other conditions.

The system includes a disposable Exchange Set through which the patient's blood passes. and a machine that controls the separation of blood into its components and monitors the exchange procedure for patient safety. The Spectra Optia machine and its embedded software have been modified to include and support a return line air detector, respectively. The return line air detector serves as a backup air detection system and represents an enhancement to the system's overall safety profile. This additional sensor actively monitors the return line and detects the presence of air, prior to its reaching the patient. In the unlikely event that the extracorporeal circuit is improperly anticoagulated and clotted material in the disposable set interferes with the system's primary air detection sensors, the modified device "alarms" when air is detected and instructs the operator to clear the return line. Because the operator must clear the line before the apheresis procedure can be continued, patients are protected from receiving potentially unsafe quantities of air - even when the operator has sub-optimally anticoagulated the circuit. In the further unlikely event that the operator disregards the system's instructions to clear air in the line, the software safely terminates the apheresis procedure.

The provided document describes a 510(k) submission for a modification to the Spectra Optia® Apheresis System to include a return line air detector. The submission is a special 510(k), indicating that the change does not alter the fundamental technology or intended use of the device.

Here's an analysis of the acceptance criteria and the study that proves the device meets them, based on the provided text:

1. Table of Acceptance Criteria and Reported Device Performance:

The document does not explicitly state formal, quantitative acceptance criteria in a tabular format, nor does it provide specific numerical performance metrics. Instead, it describes 4 activities to verify correct functioning. These activities served as the basis for demonstrating that the device meets its intended safety enhancement.

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

• Sample Size: The document does not specify a numerical sample size for any of the tests (physical testing, software tests, integration tests, simulated use tests). It uses general terms like "Extensive laboratory testing" and "simulated use tests."
• Data Provenance: The testing appears to be prospective laboratory testing and simulation, conducted internally by the manufacturer (CaridianBCT, Inc.). There is no mention of country of origin of data as it's not clinical data from patients.

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

The document does not mention the use of external experts or a ground truth established by a panel of experts for the technical and functional testing described. The "ground truth" for these tests would have been based on established engineering specifications, software requirements, and safety protocols defined by the manufacturer.

4. Adjudication Method for the Test Set:

Not applicable. The testing described focuses on engineering verification and validation (V&V) rather than subjective interpretation by multiple human readers. Therefore, an adjudication method for different human interpretations is not relevant.

5. Multi-Reader Multi-Case (MRMC) Comparative Effectiveness Study:

Not applicable. This device modification is for a safety feature (air detection) in an apheresis system, not for a diagnostic imaging or interpretive task where human readers would be evaluating cases. The study focuses on the technical functionality of the air detector, not improvement in human reader performance.

6. Standalone (Algorithm Only Without Human-in-the-Loop Performance) Study:

Yes, essentially. The verification and validation activities described, particularly "Software code reviews and unit tests" and "Simulated use tests," evaluate the system's performance (including the modified software and hardware) independently of a human operator's actions, except for the scenario where the operator fails to follow instructions, in which case the system is designed to safely terminate. The focus is on the correct functioning of the air detection mechanism and the system's automated response.

7. Type of Ground Truth Used:

The ground truth used for these tests was based on:

• Engineering Specifications: Ensuring the ultrasonic sensor does not interfere.
• Software Requirements: Verifying algorithms and code yield expected results.
• System Design Specifications: Confirming integrated hardware/software function.
• Safety Protocols: Demonstrating consistent detection of air and appropriate (safe) system responses during simulated use.

This is a technical/functional ground truth rather than a clinical ground truth like pathology or patient outcomes.

8. Sample Size for the Training Set:

Not applicable. This document describes the validation of a hardware and software modification to an existing device, not the development of a machine learning algorithm that requires a training set. The "software code reviews and unit tests" refer to standard software development practices, not AI model training.

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

Not applicable, as no training set for a machine learning algorithm was used.

Ask a specific question about this device