Search Results

Panther QIS|R&V is an information management system used to manage medical data and clinical workflow in a hospital or clinic. To support radiation oncology users, it allows the user to:

• . Enter or import, modify, store and archive treatment plans and images from treatment planning systems.
• Import, view, manipulate, enhance, annotate, store, and archive radiological . images.
• Select and provide radiation treatment plans to a radiation treatment delivery . system for patient treatment.
• Store and view treatment records provided by the radiation treatment delivery . system.
• Monitor and track treatment progress. +
• When Panther OIS|R&V is acting as an R&V system, verify the delivery device's . settings against the planned parameters, record the treatment parameters settings and prevent treatment if the parameters are out of tolerance.

Panther OIS|R&V is medical device software which allows the user to deliver radiation treatment on linear accelerator to a patient. The software has been developed to be a record and verify system that also manages oncology medical information in order to simplify the oncologist administrative tasks and to optimize the quality of patient treatment. It is a Windows® based system, which uses a single database that can be accessed by any Panther OIS|R&V client station in the treatment facility. Additionally, Panther OIS|R&V is capable of performing such functions as:

• lmporting treatment plans in DICOM or RTP format -
• Downloading of beams contained in the treatment plans to the linear accelerator ﺖ
• Verifying that the beams from the treatment plan are correctly set up on the linear accelerator
• Recording treatments delivered by the linear accelerator -
• Managing patient schedules ・
• Managing schedules for resources such as treatment machines and personnel "
• Maintaining a central repository of treatment plans and records -
• Documenting, monitoring and updating treatments and treatment plan information -
• Performing administrative tasks such as patient management. -
• Data locking or warning to prevent simultaneous access to patient (Tx) data -
• -Reports of patients and treatment history
• Manual Recording of treatment beams ﺖ
• Late Resumption of incomplete treatments -

The provided text describes the Panther OIS|R&V, a medical device software for radiation therapy record and verify systems. The 510(k) summary (K122616) details how the device meets its acceptance criteria through non-clinical testing.

Here's a breakdown of the requested information:

1. Table of Acceptance Criteria and Reported Device Performance

The document does not provide a specific table of quantitative acceptance criteria with corresponding performance metrics like sensitivity, specificity, accuracy, or AUC for the Panther OIS|R&V device. Instead, it discusses meeting predetermined specifications and pass/fail criteria through verification and validation.

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

• Sample Size: Not explicitly stated as a number of cases or patients. The document mentions "clinical cases" were used by the beta-site for testing.
• Data Provenance: The beta-site testing was conducted at Community Memorial Hospital. This suggests the data is prospective in nature, as it was part of device development and external testing in a clinical setting. The country of origin would be USA, given Community Memorial Hospital is referenced and the submission is to the FDA.

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

• Number of Experts: Not explicitly stated for the beta-site testing itself.
• Qualifications of Experts: The document mentions "clinical physicists contracted by Prowess" were involved in verifying mitigation strategies identified during risk analysis. While not directly stated as establishing ground truth for the test set, this indicates that qualified clinical experts were involved in the overall safety and effectiveness assessment. For the beta-site, it would be implied that hospital staff (oncologists, radiation therapists, physicists) were the "experts" using the system and providing feedback.

4. Adjudication Method for the Test Set

The document does not describe a specific adjudication method (e.g., 2+1, 3+1, none) for the beta-site testing. The nature of testing a Record & Verify (R&V) system is often based on functional validation against expected behavior and safety checks rather than consensus-based ground truth on diagnostic findings.

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 involving human readers and AI assistance is described in this document. The device is not an AI-assisted diagnostic tool but rather an information management and R&V system. The comparison is primarily against existing predicate R&V systems, focusing on functional equivalence and safety, not on improving human reader performance.

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

Yes, the core of the submission (and the "Summary of Non-clinical Tests") indicates that extensive standalone testing (algorithm only) was performed in-house to verify and validate the software according to its protocol and specifications. The "beta-site" testing, while involving human users in a clinical setting, was also focused on validating the system's intended functions and safety in a real-world scenario, essentially testing the "algorithm only" in its operational environment. The system's primary functions (importing plans, downloading beams, verifying settings, recording treatments) are automated or semi-automated functions of the software itself.

7. The Type of Ground Truth Used

The "ground truth" for verifying this type of software system (an R&V system) would not typically be pathology or outcomes data in the traditional sense, but rather:

• Predetermined Specifications/Expected Behavior: The software's outputs and actions are validated against predefined system requirements, design documents, and expected behavior.
• Functional Accuracy: Verification that the system correctly imports, processes, verifies, and records data according to established radiation therapy protocols and standards. For instance, whether the system accurately verifies that linear accelerator settings match planned parameters.
• Safety Requirements: Validation that the system correctly prevents treatment delivery if parameters are out of tolerance, manages data access securely, and maintains data integrity.
• Comparison to Predicate Devices: Demonstrating that its performance and functionality are equivalent to legally marketed predicate devices.

8. The Sample Size for the Training Set

The document does not provide information about a "training set" in the context of machine learning. The Panther OIS|R&V system, as described, is a record and verify software system, not an AI/ML diagnostic or predictive algorithm that typically requires a large training dataset. Its development would involve traditional software engineering and testing methodologies rather than machine learning training.

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

Since the device is not described as utilizing machine learning or AI that requires a "training set," this question is not applicable based on the provided information. The "ground truth" for its development and testing would be derived from clinical requirements, software specifications, and established radiation oncology best practices, rather than labeled data for algorithm training.

Ask a specific question about this device

The intended use of Puma is to allow the radiation therapist to deliver treatment to the patient via linear accelerator (linac). This entails selection of the patient, selection of the day's correct treatment for the patient, set up, and delivery of the treatment fields and recording of the treatment. Puma supports auto-sequencing, a process of automatically downloading a group of fields or segments from the record and verify system to the control of the linear accelerator sequentially, without user intervention. In addition, Puma also supports IMRT (Intensity Modulated Radiation Therapy), a process of shaping, modifying and moving the beam around a target to maximize the dose at the target and minimize the dose to normal structures.

Puma is a medical device, which allows the user to deliver radiation treatment on linear accelerator to a patient. The software has been developed to be a record and verify system that also manages oncology medical information in order to simplify the oncologist administrative tasks and to optimize the quality of patient treatment. It is a Windows® based system, which uses a single database that can be accessed by any Puma client station in the treatment facility. Additionally, Puma is capable of performing such functions as:

• Importing treatment plans in DICOM or RTP format -
• Downloading of beams contained in the treatment plans to the linear accelerator -
• Verifying that the beams from the treatment plan are correctly set up on the linear accelerator -
• Recording treatments delivered by the linear accelerator ・
• Managing patient schedules -
• Managing schedules for resources such as treatment machines and personnel -
• Maintaining a central repository of treatment plans and records -

Here's an analysis of the provided text regarding the acceptance criteria and study for the Prowess Puma device:

The provided text (K100801 for the Puma device) is a 510(k) summary, which focuses on demonstrating substantial equivalence to predicate devices rather than establishing novel safety and effectiveness criteria through extensive clinical trials. As such, the information on specific acceptance criteria and detailed study results, particularly for standalone performance or comparative effectiveness with human readers, is limited.

Here's a breakdown of the requested information based on the provided document:

1. Table of Acceptance Criteria and Reported Device Performance

The document doesn't explicitly state quantitative acceptance criteria or performance metrics in a table format. Instead, it relies on general statements of meeting specifications and being "as safe and effective" as predicate devices.

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

• Sample Size for Test Set: The document mentions "real patient cases" were used during beta testing at Auburn University, but does not specify the sample size (number of cases or patients) for this test set.
• Data Provenance: The beta testing was conducted at "Auburn University," which is in the USA. The data was from "real patient cases" and was likely retrospective as it refers to "clinical cases" used for testing a developed device.

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

• Number of Experts: The document states "medical physicists/dosimetrists at Auburn University" conducted functional testing and "clinical physicists contracted by Prowess" verified risk mitigation. It does not provide an explicit number of experts.
• Qualifications of Experts: "Medical physicists/dosimetrists" and "clinical physicists" are mentioned. No specific experience levels (e.g., "10 years of experience") are provided.

4. Adjudication Method for the Test Set

The document does not describe an explicit adjudication method (e.g., 2+1, 3+1). The testing involved "medical physicists/dosimetrists" and "clinical physicists" validating the system, implying their professional judgment served as the benchmark, but the process for resolving disagreements is not detailed.

5. If a Multi-Reader Multi-Case (MRMC) Comparative Effectiveness Study Was Done, If So, What Was the Effect Size of How Much Human Readers Improve with AI vs. Without AI Assistance

• MRMC Study: No, an MRMC comparative effectiveness study involving human readers assisting with or without AI was not conducted or described.
• Effect Size: Therefore, no effect size for human reader improvement with AI assistance is reported. The Puma device is a record and verify system, not primarily an AI-driven diagnostic or interpretative tool designed to "assist human readers" in the typical sense of AI-enabled image analysis.

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

• Standalone Performance: The non-clinical tests involved "Verification and validation of the software... Functional testing was conducted both in-house and by medical physicists/dosimetrists." This implies extensive standalone (algorithm only) testing against predetermined specifications. The core function of Puma is as a "record and verify system" that automates certain processes (like auto-sequencing), meaning its performance inherently relies on the algorithm operating correctly without continuous human intervention during those automated steps. The clinical physicist/dosimetrist involvement was to validate these functions.

7. The Type of Ground Truth Used

The ground truth for the testing appears to be based on:

• Predetermined Specifications: The software "has met its predetermined specifications."
• Expert Consensus/Clinical Judgment: Functional testing by "medical physicists/dosimetrists" and verification by "clinical physicists" against "real patient cases" implies that the correct operation and output were judged against established clinical practice and expert knowledge in radiation therapy planning and delivery.
• Comparison to Predicate Devices: The overall goal was to demonstrate substantial equivalence, meaning the device's performance aligned with that of legally marketed, safe, and effective predicate devices.

8. The Sample Size for the Training Set

The document does not specify any sample size for a training set. As a record and verify system, especially one cleared in 2010, it's highly unlikely that it relied on machine learning models requiring large "training sets" in the modern AI sense. Its development would have followed traditional software engineering and validation processes against designed specifications.

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

As no training set is described (due to the nature of the device and the development era), the method for establishing its ground truth is not applicable/not provided.

Ask a specific question about this device