Search Results

The Monaco system is used to make treatment plans with prescriptions for external beam radiation therapy. The system calculates dose for photon and electron treatment plans and displays, on-screen and in hard-copy, two- or three-dimensional radiation dose distributions inside patients for given treatment plan set-ups.

The Monaco product line is intended for use in radiation treatment planning. It uses generally accepted methods for:

• contouring
• image manipulation
• simulation
• image fusion
• plan optimization
• QA and plan review

Monaco is a radiation treatment planning system that first received FDA clearance in 2007 (K071938). The modified system received clearance in 2009, when Volumetric Modulated Arc Therapy (VMAT) planning capability was added (K091179), when Dynamic Conformal Arc planning was added (K110730), and most recently when the system's intended use was expanded to include electron treatment planning, among other changes (K132971). The Monaco system accepts patient diagnostic imaging data and "source" dosimetry data from a linear accelerator. The system then permits the user to display and define (contour) the target volume to be treated and critical structures which must not receive above a certain level of radiation on these diagnostic images.

Based on the prescribed dose, the user, a Dosimetrist or Medical Physicist, can create multiple treatment scenarios involving the number, position(s) and energy of radiation beams and the use of beam modifiers between the source of radiation and the patient to shape the beam. The Monaco system then produces a display of radiation dose distribution within the patient, indicating doses to the target volume and surrounding structures. The "best" plan satisfying the prescription is then selected, one that maximizes dose to the target volume while minimizing dose to surrounding healthy volumes. The Monaco system supports 3D conformal planning, IMRT, and Dynamic Conformal. It supports inverse and forward planning workflows.

The provided text describes the Monaco RTP System, a medical device for radiation treatment planning. It includes information on its intended use, technological characteristics, and a comparison with predicate devices. However, the document does not contain specific acceptance criteria, a detailed study proving the device meets acceptance criteria, or information on ground truth establishment, sample sizes for training/test sets, expert qualifications, or adjudication methods in the manner typically expected for AI/ML device submissions.

The document states:

• Clinical trials were not performed.
• Validation testing involved simulated clinical workflows.
• Over 600 test procedures were executed (verification tests) to ensure the system works as designed, including new functionality, risk mitigations, and regression tests.

Therefore, most of the requested information cannot be extracted from this document as it pertains to a different type of device (a treatment planning system, not an AI/ML diagnostic aid) and an earlier regulatory submission context where such detailed performance studies for AI/ML were not standard.

Here's a breakdown of what can be extracted and what cannot:

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

This document does not present quantitative acceptance criteria or corresponding reported device performance metrics like sensitivity, specificity, or AUC, which are common for AI/ML devices. Instead, it states that "Monaco passed testing and was deemed safe and effective for its intended use." The "performance" described is in terms of functionality and passing verification tests.

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

• Sample Size for Test Set: Not specified. The document mentions "over 600 test procedures" but doesn't detail the number of cases or data points used within these procedures.
• Data Provenance: Not specified. The testing involved "simulated clinical workflows," but the origin (e.g., country of origin of data, retrospective or prospective) of the data used in these simulations is not mentioned.

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

This information is not provided. The testing described is verification-based ("system is working as designed"), not ground truth establishment by experts for specific diagnostic or prognostic outcomes.

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

Not specified.

5. If a multi-reader multi-case (MRMC) comparative effectiveness study was done, and if so, what was the effect size of how much human readers improve with AI vs without AI assistance:

No MRMC study was performed or mentioned. The device is a treatment planning system, not an AI-assisted diagnostic device, and clinical trials were explicitly stated as not being performed.

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

The device's performance is described as standalone in the sense that its functional verification tests ensure it performs its calculations and operations correctly. However, it's explicitly stated that "Monaco does not directly control the linear accelerator that delivers the radiation. Once completed, plans are reviewed and approved by qualified clinicians and may be subject to quality assurance practices before treatment actually takes place." This implies that the system is always used with human oversight, but its core calculation and planning functionalities are "standalone" in their execution. The document does not describe specific "standalone performance" metrics in the context of an AI/ML algorithm.

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

The concept of "ground truth" as typically applied to diagnostic AI/ML devices based on expert consensus or pathology is not present in this document. The "truth" for this device's performance would be the accuracy of its physical dose calculations and the correct execution of its planning algorithms against established physics models and pre-defined test cases, rather than clinical outcomes or diagnostic interpretations.

8. The sample size for the training set:

The document does not refer to a "training set" as this is not an AI/ML device in the modern sense that learns from data. It's a deterministic software system.

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

Not applicable, as there is no "training set."

Summary of what is available from the document:

The Monaco RTP System is a radiation treatment planning system. Its regulatory submission (K151233) describes its intended use, technological characteristics, and compares it to predicate devices (Monaco K132971, AdvantageSim MD K132944) to demonstrate substantial equivalence.

Device Performance and Testing:

• Type of Study: Verification testing and simulated clinical workflows.
• Number of Tests: Over 600 test procedures were executed.
• Purpose of Tests: To verify requirements for new product functionality, ensure risk mitigations function as intended, and regression tests to ensure continued safety and effectiveness of existing functionality.
• Outcome: "Monaco passed testing and was deemed safe and effective for its intended use."
• Clinical Trials: Explicitly stated as not performed because "Clinical testing on patients is not advantageous in demonstrating substantial equivalence or safety and effectiveness of the device since testing can be performed such that no human subjects are exposed to risk."
• Human-in-the-Loop: The system's plans are always "reviewed and approved by qualified clinicians and may be subject to quality assurance practices before treatment actually takes place."
• "Level of Concern": Classified as "major level of concern" because "should a flaw in the treatment plan escape the notice of the qualified professionals using the Monaco system, serious injury or death could result."

Ask a specific question about this device

MOSAIO® is an oncology information system used to manage workflows for treatment planning and delivery. It supports information flow among healthcare facility personnel and can be used wherever radiotherapy and/or chemotherapy are prescribed.

Users can configure MOSAIQ® for Medical Oncology use, Radiation Oncology use, or the two together. It lets users:

• . Assemble electronic patient charts and treatment plans, order diagnostic tests, and prescribe medications.
• Generate and keep medication formulary lists and calculate applicable medication . dosages for medical oncology.
• Import, view, annotate, adjust, enhance, manage and archive images.
• Compare radiation treatment plans and evaluate dose coverage.
• Design leaf plans for operation with radiotherapy treatment machines that have multileaf ● collimators.
• Make sure radiation treatment plans imported from treatment planning systems agree with treatment machine constraints. MOSAIO® reads actual settings from the treatment machine through the machine communication interface. It compares these settings with predefined values. If a mismatch occurs between the planned values and the actual machine settings, the system warns the user.
• . View reference images to setup treatment. MOSAIQ® refers to predefined settings to help treatment machine setup, and communicates patient and machine setup instructions.
• Record actual delivered radiation values in an electronic chart to track treatment. ●
• Use stereotactic localization to calculate set-up coordinates for treatments. .

MOSAIQ® is not intended for use in diagnosis. Medical oncology dose calculation functions are designed for use with patients 18 years or older only.

MOSAIQ is a multi-functional, integrated software suite that forms a comprehensive electronic oncology management system for medical and radiation oncology facilities. For both medical and radiation oncology users, MOSAIQ provides image-enabled electronic patient charting and record management as well as medical transcription and billing functionality. For radiation oncology users, it also includes the ability to import and export radiation treatment plan information, stereotactic localization, treatment plan review, the ability to plan multileaf collimator (MLC) shapes, and verify and record treatment setup and delivery.

This Premarket Notification addresses the addition of the Locate module for Radiation Oncology, which adds stereotactic localization capability to MOSAIQ.

The provided document is a 510(k) premarket notification for the MOSAIQ Oncology Information System. It describes the device's intended use, functionalities, and a comparison with predicate devices to establish substantial equivalence. However, it does not contain the detailed information necessary to fully answer all aspects of your request regarding acceptance criteria and a specific study proving device performance against those criteria.

Here's a breakdown of what can and cannot be extracted from the document:

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

The document does not explicitly state quantitative acceptance criteria in a table format with corresponding quantitative performance metrics for the MOSAIQ Oncology Information System. Instead, it describes a summary of non-clinical testing where "Verification tests were written and executed to ensure that the system is working as designed. Over 100 test procedures were executed, including tests to verify requirements for new product functionality were met, tests to ensure that risk mitigations function as intended, and regression tests to ensure continued safety and effectiveness of existing functionality. Pass/fail criteria for this testing effort was similar to past testing efforts for the previous versions of MOSAIQ. MOSAIQ passed testing and was deemed safe and effective for its intended use."

While it confirms tests were performed and passed, specific numerical acceptance criteria (e.g., accuracy percentages, error rates, time limits) and the detailed study results meeting those criteria are not provided. The "reported device performance" is a qualitative statement of "passed testing and was deemed safe and effective."

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 states, "Bench testing was performed...using simulated clinical workflows and ad hoc testing where appropriate, with actual patient data."

• Sample Size for Test Set: The exact number of patient data samples used for testing is not specified. It mentions "actual patient data," but not how many cases or the size of this dataset.
• Data Provenance: The country of origin for the "actual patient data" is not specified. It does not indicate whether the data was retrospective or prospective, though the term "simulated clinical workflows" often implies a retrospective or synthetic approach.

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)

This information is not provided in the document. The document refers to "actual patient data" and "simulated clinical workflows," but it does not describe the process of establishing ground truth for this data, nor does it mention the involvement or qualifications of experts.

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

This information is not provided in the document. There is no mention of any adjudication process for the test results or the ground truth.

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, "Clinical trials were not performed as part of the development of this product. Clinical testing on patients is not advantageous in demonstrating substantial equivalence or safety and effectiveness of the device since testing can be performed such that no human subjects are exposed to risk."
Therefore, a multi-reader multi-case (MRMC) comparative effectiveness study evaluating human reader improvement with or without AI assistance was not performed. The device, an Oncology Information System, is not an AI-assisted diagnostic tool in the sense of image interpretation where MRMC studies are typically applicable.

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

The document describes "Verification tests were written and executed to ensure that the system is working as designed." These tests would inherently represent a form of standalone testing of the software's functionality against its requirements.
However, the device is designed to interface with human users ("alerting the user," "warns the user") and is an "Oncology Information System" that "supports information flow among healthcare facility personnel." This implies a human-in-the-loop system where the software provides information and alerts, but human clinicians make final decisions. While individual sub-functions of the software (e.g., dose calculation, mismatch detection) would have been tested in a standalone manner, the overall system is not purely "algorithm only" without human interaction in its intended use.

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

The document uses "actual patient data" in its bench testing but does not specify the type of ground truth established for this data (e.g., whether it was based on pathology, expert consensus, or clinical outcomes). The testing focused on verifying the system's design and functionality rather than diagnostic accuracy against a specific ground truth. For instance, for the "mismatch" warning function, the ground truth would be whether a mismatch truly existed between planned and actual settings, rather than a clinical outcome.

8. The sample size for the training set

This information is not applicable or not provided. The MOSAIQ Oncology Information System, as described, appears to be a rule-based software system for managing workflows and information in oncology, rather than a machine learning or AI system that requires a "training set" in the conventional sense. The document does not mention any machine learning components that would necessitate training data.

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

This information is not applicable or not provided as there is no mention of a "training set" or machine learning models.

In summary, the provided document focuses on establishing substantial equivalence for an Oncology Information System based on its functionalities and comparison with predicate devices, rather than detailed performance metrics against specific acceptance criteria relevant to diagnostic or AI algorithms. The "study" referenced is a series of "verification tests" performed internally, without the rigorous quantifiable metrics often associated with AI/ML device evaluations.

Ask a specific question about this device

The Monaco system is used to make treatment plans for patients with prescriptions for external beam radiation therapy. The system calculates dose for photon and electron treatment plans and displays, on-screen and in hard-copy. two- or three-dimensional radiation dose distributions inside patients for given treatment plan set-ups.

The Monaco product line is intended for use in radiation treatment planning. It uses generally accepted methods for:

• contouring
• image manipulation
• simulation
• image fusion
• plan optimization
• QA and plan review

Monaco is a radiation treatment planning system that first received FDA clearance in 2007 (K071938). The modified system received clearance in 2009, when Volumetric Modulated Arc Therapy (VMAT) planning capability was added (K091179) and again when Dynamic Conformal Arc planning was added (K110730). The Monaco system accepts patient diagnostic imaging data and "source" dosimetry data from a linear accelerator. The system then permits the user to display and define (contour) the target volume to be treated and critical structures which must not receive above a certain level of radiation on these diagnostic images.

Based on the prescribed dose, the user, a Dosimetrist or Medical Physicist, can create multiple treatment scenarios involving the number, position(s) and energy of radiation beams and the use of beam modifiers between the source of radiation and the patient to shape the beam. The Monaco system then produces a display of radiation dose distribution within the patient, indicating doses to the target volume and surrounding structures. The "best" plan satisfying the prescription is then selected, one that maximizes dose to the target volume while minimizing dose to surrounding healthy volumes.

Acceptance Criteria and Study for Monaco RTP System

The Monaco RTP System is a radiation treatment planning system. The provided document focuses on demonstrating its substantial equivalence to previously cleared devices rather than defining specific performance acceptance criteria against a new clinical standard. The "acceptance criteria" in this context are implicitly that the device performs comparably to its predicate devices for the stated intended uses and technological characteristics.

1. Table of Acceptance Criteria and Reported Device Performance

Given the nature of the 510(k) submission, the "acceptance criteria" are not explicit numerical targets but rather a demonstration of substantial equivalence to predicate devices across various features and functionalities. The "reported device performance" is the assertion that the Monaco RTP System with new features meets or exceeds these characteristics.

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

The document states: "Validation testing involved simulated clinical workflows, and algorithm testing, described in detail in section 20, which validated the accuracy of dose calculation functions using a simulated clinical setup."

• Sample Size for Test Set: Not explicitly stated. The phrase "simulated clinical workflows, and algorithm testing" suggests a variety of test cases, but the exact number or type of "simulated clinical setups" or specific test patients/scenarios is not quantified in the provided text.
• Data Provenance: The data is generated from "simulated clinical workflows" and "algorithm testing using a simulated clinical setup." This indicates the data is synthetic or derived from controlled test environments, not from real patient data. There is no mention of country of origin as it's not real-world data. The nature of the testing is retrospective in the sense that it's against predefined test cases and expected outcomes.

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

• Number of Experts: Not specified.
• Qualifications of Experts: Not specified. However, the document notes that "Dosimetrist or Medical Physicist" are the users who create treatment plans and qualified clinicians review and approve them. It is implied that any "ground truth" for simulated scenarios would be established by similarly qualified professionals or based on established physics principles and industry standards.

4. Adjudication Method for the Test Set

Not specified. The testing involved "verification tests" and "algorithm testing" against "simulated clinical workflows" and "simulated clinical setup." This implies that the correctness of the output was compared against expected results, likely determined by established physics models or known solutions for the simulations, rather than requiring expert adjudication of discrepancies.

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

No. The document explicitly states: "Clinical trials were not performed as part of the development of this product. Clinical testing on patients is not advantageous in demonstrating substantial equivalence or safety and effectiveness of the device since testing can be performed such that no human subjects are exposed to risk." This confirms that no human reader studies (MRMC or otherwise) were conducted.

• Effect Size of human readers improvement with AI vs without AI assistance: Not applicable, as no MRMC study was performed.

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

Yes. The validation testing included "algorithm testing, described in detail in section 20, which validated the accuracy of dose calculation functions using a simulated clinical setup." This specifically refers to the performance of the algorithm itself in dose calculation. Additionally, "Over 500 test procedures were executed, including tests to verify requirements for new product functionality" and "regression tests," which would inherently involve evaluating the algorithm's output against expected results in a standalone manner.

7. The Type of Ground Truth Used

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

• Established physics principles and models: Given that the device calculates radiation dose, the ground truth for dose calculation functions would be derived from known physics equations and simulated or theoretical benchmarks.
• Engineering specifications and requirements: The "over 500 test procedures" and "requirements for new product functionality" suggest that many ground truths were the expected behavior and output defined by the device's design specifications.
• Expected outcomes from simulated clinical setups/workflows: This implies a comparison against a "correct" or "ideal" treatment plan result for a given simulated patient scenario.

8. The Sample Size for the Training Set

The document does not mention a "training set" in the context of machine learning. The Monaco RTP System is a software system based on physics models and algorithms for radiation treatment planning, not a system that is "trained" on a dataset in the typical machine learning sense. Therefore, this information is not applicable.

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

Not applicable, as there is no mention of a training set for machine learning. The "ground truth" for the device's underlying physics models and algorithms would be established through principles of radiation physics, mathematical derivations, and prior validation of these computational methods.

Ask a specific question about this device

MOSAIQ® is an oncology information system used to manage workflows for treatment planning and delivery. It supports information flow among healthcare facility personnel and can be used wherever radiotherapy and/or chemotherapy are prescribed.

Users can configure MOSAIQ® for Medical Oncology use, Radiation Oncology use, or the two together. It lets users:

• · Assemble electronic patient charts and treatment plans, order diagnostic tests, and prescribe medications.
• Generate and keep medication formulary lists and calculate applicable medication dosages for medical oncology.
• Import, view, annotate, adjust, enhance, manage and archive images.
• Compare radiation treatment plans and evaluate dose coverage.
• Design leaf plans for operation with radiotherapy treatment machines that have multileaf . collimators.
• . Make sure radiation treatment plans imported from treatment planning systems agree with treatment machine constraints. MOSAIQ® reads actual settings from the treatment machine through the machine communication interface. It compares these settings with predefined values. If a mismatch occurs between the planned values and the actual machine settings, the system warns the user.
• View reference images to setup treatment. MOSAIQ® refers to predefined settings to . help treatment machine setup, and communicates patient and machine setup instructions.
• Record actual delivered radiation values in an electronic chart to track treatment. .

MOSAIQ® is not intended for use in diagnosis. Medical oncology dose calculation functions are designed for use with patients 18 years or older only.

MOSAIQ is a multi-functional, integrated software suite that forms a comprehensive electronic oncology management system for medical and radiation oncology facilities. For both medical and radiation oncology users, MOSAIQ provides image-enabled electronic patient charting and record management as well as medical transcription and billing functionality. For radiation oncology users, it also includes the ability to import and export radiation treatment plan information, the ability to plan multileaf collimator (MLC) shapes, and verify and record treatment setup and delivery.

This Premarket Notification addresses the addition of the "Evaluate" module, which calculates and displays dose volume histograms (DVHs) for the purpose of review and evaluation of radiation treatment plans.

Here's an analysis of the provided text regarding the acceptance criteria and study for the MOSAIQ Oncology Information System:

It's important to note that this document is a 510(k) Premarket Notification summary for software, specifically an Oncology Information System (MOSAIQ). Such notifications primarily focus on demonstrating substantial equivalence to a predicate device and usually involve software verification and validation, not clinical trials in the sense of demonstrating diagnostic accuracy or efficacy in a patient population. Therefore, many of the typical acceptance criteria and study components you'd expect for an AI/algorithm-based diagnostic device will not be present.

Based solely on the provided text, many of the requested categories (especially those related to clinical performance, ground truth, and expert evaluation) are not applicable or not reported as they would be for a typical AI diagnostic device.

Acceptance Criteria and Reported Device Performance

The document doesn't explicitly state quantitative performance-based acceptance criteria for a "device" in the sense of an AI algorithm producing a measurement or diagnosis. Instead, the "device" is an information system, and its acceptance criteria are implicitly tied to the successful completion of non-clinical verification and validation testing, ensuring it functions as designed and meets safety requirements.

Study Details: MOSAIQ Oncology Information System

This submission focuses on software validation rather than a clinical study evaluating diagnostic performance.

1. Sample size used for the test set and the data provenance (e.g., country of origin of the data, retrospective or prospective):

   • Test Set Description: "Bench testing was performed... using simulated clinical workflows and ad hoc testing where appropriate, with actual patient data."
   • Sample Size: Not specified for the "actual patient data" used within the bench testing. The total number of test procedures was "Over 100."
   • Data Provenance: "actual patient data" implies retrospective, but no country of origin is mentioned.

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

   • Number of Experts: Not specified.
   • Qualifications: Not specified. For software verification and validation, "ground truth" would typically be defined by engineering specifications, expected outputs, and clinical input from subject matter experts (e.g., oncologists, physicists, dosimetrists) who validate the functional correctness of the system rather than establishing a diagnostic truth for patient cases.

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

   • Not applicable as this was not a human reader study requiring adjudication of interpretations. The "adjudication" would be through verifying test procedure results against expected outcomes defined during the software development lifecycle.

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 MRMC comparative effectiveness study was done. The document explicitly states: "Clinical trials were not performed as part of the development of this product." and "Clinical testing on patients is not advantageous in demonstrating substantial equivalence or safety and effectiveness of the device."

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

   • Yes, in a sense. The non-clinical testing was focused on the software's ability to perform its functions independently ("algorithm only") under simulated conditions, but the device's intended use is with a human in the loop, as an information system for workflow management and to warn users. The testing verified the software's functional correctness.

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

   • The "ground truth" for this type of software would be based on:
     • Functional Specifications/Requirements: The software must perform according to its design documents.
     • Clinical Domain Knowledge: Accuracy of calculations (e.g., dosage, DVHs) and correctness of comparisons (e.g., planned vs. actual machine settings) would be validated against established medical/physics principles and expected clinical outcomes.
     • Expected Outputs: For test cases, the correct output (e.g., a specific DVH curve, a warning message for a mismatch) would be predefined and compared to the software's actual output.

7. The sample size for the training set:

   • No "training set" in the context of machine learning was mentioned or indicated. This is a rule-based/deterministic software system, not an AI/ML-based system that requires training data.

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

   • Not applicable, as there was no machine learning training set mentioned.

Ask a specific question about this device

MOSAIQ is an image-enabled electronic medical record system (EMR) used for oncology workflow management. It lets users:

• Supply electronic patient charts and assemble care plans, order diagnostic . tests, and prescribe medications.
• Import, view, annotate, manipulate, enhance, and archive images. .
• Import, keep, and export information related to patient treatments to ● monitor treatment progress from a central location. This includes orders, documents, lab information, and other related information from compatible programs.
• Generate and keep medication and formulary lists and calculate applicable . medication dosages for medical oncology.
• Design leaf plans for operation with radiotherapy treatment machines that . have multileaf collimators. Users can give, view and change geometric data related to treatment fields, including the MLC accessory.
• Ensure plans imported from treatment planning systems agree with . treatment machine constraints.
  Additionally, MOSAIQ:
• . Supplies other administrative functionality necessary to operate medical and radiation oncology departments.
• . Shows reference images for setup purposes, refers to predefined settings to help treatment machine setup, and tells clinicians of necessary steps before treatment.
• Reads actual settings from the treatment machine through the machine's ● communication interface. It compares these settings with predefined values. If a mismatch occurs between the planned values and the actual machine settings, the system inhibits treatment.
• . Verifies the actual treatment against radiation treatment plans. At applicable points during the treatment, it records the actual delivered values to provide treatment tracking.

MOSAIQ supports information flow among healthcare facility personnel. It can be used wherever radiotherapy and/or chemotherapy are prescribed. MOSAIQ is not intended for use in diagnosis. Medical oncology dose calculation functions are designed for use with patients 18 years or older only.

MOSAIQ is a multi-functional, integrated software suite that forms a comprehensive electronic oncology management system for medical and radiation oncology facilities. For both medical and radiation oncology users. MOSAIQ provides image-enabled electronic patient charting and record management as well as medical transcription and billing functionality. For radiation oncology users, it also includes the ability to import and export radiation treatment plan information, the ability to plan multileaf collimator (MLC) shapes, and verify and record treatment setup and delivery.

Previously, three of the components within MOSAIQ were cleared through the 510(k) process individually. The ViewStation software (K011694) provides the ability to to import, view, annotate, manipulate, enhance, manage and archive medical images and includes patient positioning functionality. The MLC Fit software (K991133) allows users to define MLC leaf shapes for radiation treatment plans. The SEQUENCER software (K981313) connects to the treatment unit (e.g. linear accelerator) and compares its setup to the predefined treatment field in the treatment chart. SEOUENCER inhibits treatment if errors are detected, records actual treatment unit parameters, and allows this information to be stored and/or printed as part of the treatment record.

MOSAIQ includes the ViewStation, MLC Fit and SEQUENCER software applications as well as other applications that were not classified as medical devices when considered as individual products.

The provided document is a 510(k) Premarket Notification for the MOSAIQ Oncology Information System. It does not contain information about acceptance criteria or specific studies demonstrating the device's performance against such criteria.

The document explicitly states:

• "Clinical trials were not performed as part of the development of this product." (Page 3)
• "Clinical testing on patients is not advantageous in demonstrating substantial equivalence or safety and effectiveness of the device since testing can be performed such that no human subjects are exposed to risk." (Page 3)
• "Bench testing was performed... using simulated clinical workflows and ad hoc testing where appropriate, with actual patient data. The product was deemed fit for clinical use." (Page 3)

Therefore, the specific information requested in the prompt regarding acceptance criteria, reported performance, sample sizes, expert qualifications, adjudication methods, MRMC studies, standalone performance, and ground truth establishment for clinical studies is not available within this document.

The document asserts substantial equivalence to predicate devices based on intended use, safety, and effectiveness, citing its components (ViewStation, MLC Fit, SEQUENCER) that were previously cleared individually. The main claim for this 510(k) is the integration of these components and other non-medical device applications into a comprehensive oncology management system, with the highest concern being the "verify and record" functionality which interfaces with linear accelerators to detect mismatches between planned and actual machine settings.

Ask a specific question about this device

ViewStation supports image and information flow among health care facility personnel. ViewStation can be used whenever digital images and associated data are the means for communicating information. ViewStation is not intended for use in diagnosis.

The intended use of ViewStation is to provide health care facility personnel with an effective means to utilize patient images during the course of therapy or treatment. ViewStation allows users to import, view, annotate, manipulate, enhance, manage, and archive patient images and associated information are stored in a database, providing users access to the information necessary to perform their functions.

The primary function of ViewStation is to provide a means to more effectively manage image information in a therapy or treatment environment. ViewStation provides the ability to import, view, annotate, manipulate, enhance, and archive patient images during the course of therapy, treatment, and follow-up.

ViewStation imports existing digital images acquired or generated by other products. ViewStation retains the original image, which was acquired or generated by a third party product. With these facts in mind, the goal of ViewStation is to make electronic patient image information more accessible throughout the department. IMPAC is providing a tool to increase department productivity since digital images, unlike films, do not have to be physically transferred from one station to another.

The ViewStation is an Image Management System which is explicitly not intended for diagnostic use but rather for managing images and information flow in a healthcare facility. Given this, the submission does not contain a study involving clinical efficacy or diagnostic performance. Instead, the "acceptance criteria" and "study" are focused on demonstrating that the updated software maintains the safety and effectiveness of the predicate device for its intended non-diagnostic use.

Here's an breakdown:

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

The submission does not present a table of acceptance criteria in the traditional sense of diagnostic performance metrics (e.g., sensitivity, specificity, AUC). Instead, the "acceptance criteria" are implied by the requirements for regulatory compliance, internal quality standards, and successful software development and testing. The "reported device performance" is the successful completion of these processes, affirming that the updated ViewStation maintains its intended non-diagnostic functionality and safety.

2. Sample size used for the test set and the data provenance (e.g. country of origin of the data, retrospective or prospective)

This information is not applicable and therefore not provided in the submission. Since the device is explicitly not intended for diagnosis and the changes are evolutionary software updates to an existing image management system, no clinical "test set" of patient data (images) was used to evaluate diagnostic performance. The testing performed was related to software verification and validation, hazard analysis, and functional integrity.

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)

This information is not applicable and therefore not provided in the submission. As no clinical "test set" using patient data for diagnostic evaluation was involved, no experts were required to establish ground truth for such a purpose. The "experts" involved would be software engineers, quality assurance personnel, and potentially medical professionals (users) providing feedback on the system's usability and functionality, but not establishing diagnostic ground truth.

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

This information is not applicable and therefore not provided in the submission. Adjudication methods are typically used in studies involving expert review of diagnostic performance. The testing described focuses on software functionality, safety, and compliance with quality systems, not diagnostic accuracy.

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

A Multi-Reader, Multi-Case (MRMC) comparative effectiveness study was not done. The ViewStation is an image management system and explicitly states it is "not intended for use in diagnosis." Therefore, there is no AI component for diagnostic assistance, and no study to evaluate reader improvement with or without AI.

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

This information is not applicable. The ViewStation is a software system with human-in-the-loop functionality, and not a standalone diagnostic algorithm. Its purpose is to manage images for human users.

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

This information is not applicable. The device is not for diagnosis, so there is no "ground truth" related to disease presence or absence established from pathology, expert consensus, or outcomes data. The "ground truth" for the software testing would be the expected functional behavior and safety requirements defined in the design specifications.

8. The sample size for the training set

This information is not applicable and therefore not provided in the submission. The ViewStation is a conventional image management software, not a machine learning or AI-driven diagnostic algorithm that requires a "training set" of data in the typical sense. The software's development is guided by established engineering principles and quality systems rather than data-driven machine learning.

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

This information is not applicable. As there is no "training set" in the context of machine learning, there is no ground truth establishment for such a set. The "ground truth" for software development is based on user requirements, regulatory standards, and design specifications.

Ask a specific question about this device

The QwikSIM Virtual Simulation System may be used by radiation oncologists, medical physicists, and medical dosimetrists for patient localization, image import and review, tumor and normal tissue delineation, and virtual simulation of treatment unit setup during the treatment planning process of external beam radiotherapy treatment. This information may then be exported to a treatment planning system for dose calculation.

The QwikSIM Virtual Simulation System provides fast and accurate visualization, contouring and beam definition to streamline the radiation therapy planning process. QwikSIM imports image data, and provides an array of tools to straining and adjusting images. Manual and automatic contouring tools allow for anatomical and tumor contour definition. Beam placement and visualization tools facilitate treatment port definition, isocenter placement and laser center placement. The resulting plan data can then be used with laser positioning systems for patient marking and exported to therapy planning systems for dose calculation.

The provided document is a 510(k) Premarket Notification summary for the QwikSIM Virtual Simulation System (Version 2.00). This type of submission is for demonstrating substantial equivalence to a legally marketed predicate device, rather than proving safety and effectiveness through clinical trials with specific acceptance criteria. As such, the document does not contain specific acceptance criteria or a study designed to prove the device meets those criteria in the way a clinical trial for novel devices would.

Instead, the document focuses on demonstrating substantial equivalence to existing predicate devices. Here's what can be extracted and what is not present based on your request:

Acceptance Criteria and Reported Device Performance

The document states that "Clinical performance data is not required for determination of substantial equivalence for this type and class of device." Therefore, there are no specific quantitative acceptance criteria (e.g., sensitivity, specificity, accuracy thresholds) or corresponding reported device performance metrics in the submission summary. The acceptance criteria for this submission are based on demonstrating that the intended use and technological characteristics are substantially equivalent to predicate devices, and that any differences do not raise new safety or effectiveness concerns.

The closest analogue to "reported device performance" is the statement "The testing demonstrated that the functionality of QwikSIM was successfully implemented." This is a qualitative statement about successful implementation rather than a quantitative performance metric.

Remaining Information Based on Document's Content:

Due to the nature of a 510(k) submission for a virtual simulation system, many of the requested details about clinical studies, expert-established ground truth, and training data are not included or applicable.

Ask a specific question about this device

ViewStation supports image and information flow among health care facility personnel. ViewStation can be used whenever digital images and associated data are the means for communicating information. ViewStation is not intended for use in diagnosis. The images and associated information are stored in a database, providing users access to the information necessary to perform their functions.

The intended use of ViewStation is to provide health care facility personnel with an efficient and effective means to utilize patient images during the course of therapy or treatment. ViewStation allows users to import, view, annotate, manipulate, enhance, manage, and archive patient images.

The primary function of ViewStation is to provide a means to move image information in a therapy or treatment environment. ViewStation provides the ability to import, view, annotate, manage, and archive patient images during the course of therapy, treatment, and follow-up.

ViewStation imports existing digital images acquired or generated by other products. ViewStation retains the original image, which was acquired or generated by a third party product.

The provided text describes a Premarket Notification (510(k)) Summary of Safety and Effectiveness for "ViewStation, Image Processing System" by IMPAC Medical Systems, Inc. This document focuses on establishing substantial equivalence to a predicate device, rather than presenting a detailed study with acceptance criteria and performance metrics typically seen for standalone diagnostic AI/ML devices.

Here's an analysis based on the provided text, highlighting what is present and what is absent in relation to your request:

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

The document does not provide a table of acceptance criteria or specific reported device performance metrics in the way one would expect for a diagnostic or AI/ML algorithm that generates specific output values (e.g., accuracy, sensitivity, specificity, AUC).

Instead, the "acceptance criteria" can be inferred from the document's claims about equivalency and safety:

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

• Test Set Sample Size: Not specified. The document states "Engineering testing was also performed to ensure that the algorithms and all other technical changes function exactly as intended." This implies internal testing, but no details on the size or characteristics of the test data are provided.
• Data Provenance: Not specified.

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

• Not applicable as this is not a diagnostic device undergoing a typical clinical validation study with ground truth established by experts. The "effectiveness" is primarily about the algorithms functioning as intended, not about diagnostic accuracy against expert consensus.

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

• No MRMC or comparative effectiveness study is mentioned. The device's purpose is to automate a previously manual process (identifying a treatment field edge and ordering images), not to provide a diagnostic AI/ML assistant to human readers. The document explicitly states: "No additional or changed diagnostic or therapeutic claims arise as the result of the ViewStation product. Therefore, demonstration of clinical efficacy is not a required element of this Premarket Notification. Further, clinical performance data is not required for determination of substantial equivalence for this type and class of device."

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

• Yes, in a sense. The algorithms perform automated functions without human intervention in the specific tasks they are designed for (determining treatment field images, identifying edges, ordering images). The document focuses on the standalone functioning of these algorithms as part of the overall ViewStation system. "Engineering testing was also performed to ensure that the algorithms and all other technical changes function exactly as intended."

7. The type of ground truth used

• The concept of "ground truth" for diagnostic accuracy (e.g., pathology, outcomes data, expert consensus) is not directly applicable here. The "ground truth" for the engineering testing would relate to whether the algorithms correctly identify the treatment field image, correctly identify the field edge (based on pre-defined criteria or reference images), and correctly order the images. This would be a technical ground truth related to the algorithm's intended function, not clinical ground truth for diagnosis.

8. The sample size for the training set

• Not specified.

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

• Not specified.

Summary of Device and its Purpose:

The ViewStation is an image processing system primarily for radiation therapy, designed to import, view, annotate, manipulate, enhance, manage, and archive patient images during therapy. The reported changes involve new automated image processing algorithms to:
* Determine which of two portal images is the treatment field portal image.
* Employ an edge detection algorithm to identify the treatment field edge in a portal image.
* Modify an existing histogram optimization algorithm to accept dynamic inputs from the new edge detection algorithm.
* Superimpose a polygon of the field edge onto an open field image and automatically order images.

Crucially, the document states, "ViewStation is not intended for use in diagnosis." and explicitly notes that "No additional or changed diagnostic or therapeutic claims arise as the result of the ViewStation product." This means it is a tool to enhance workflow and image management in a therapy setting, not a device that provides diagnostic outputs requiring traditional clinical performance metrics. The "study" referenced is the internal verification and validation testing to ensure the algorithms function as intended and that the changes do not introduce new safety concerns or alter the intended use, maintaining substantial equivalence to its predicate device.

Ask a specific question about this device

MLC Fit is to be used to define leaf plans for use with radiation treatment machines equipped with multileaf collimators manufactured by Siemens Medical Systems, Varian Associates, and With manned conniness Inc. This method of defining the geometric parameters associated with treatment fields can be used whenever a conformal treatment field is desired.

The primary function of MLC Fit is to provide a means to define multileaf collimator leaf plans based on a user defined shape of a desired treatment area for use with a cancer radiotherapy treatment machines equipped with multileaf collimators manufactured by Siemens Medical Systems, Varian Associates, or Elekta Oncology Systems, Inc. Users may create, view, and edit MLC leaf data as well as other geometric parameters associated with treatment field definitions.

The provided document MLC Fit - 510(k) - Response to Request for Additional Information is a 510(k) submission from 1999 and therefore does not contain the structured information typically found in modern AI/ML device submissions regarding acceptance criteria and performance studies. The document describes a software called MLC Fit designed to define multileaf collimator leaf plans for cancer radiotherapy. It emphasizes the software's function in eliminating manual calculation errors and its compliance with quality systems but does not detail specific performance metrics, clinical studies, or acceptance criteria in the manner requested.

However, based on the text, we can infer some aspects and highlight what is missing relative to modern AI/ML device descriptions.

Inferred Information and Missing Details:

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

   • Inferred Acceptance Criteria: The primary goal of MLC Fit is to "provide the leaf positions for a given treatment shape in a manner that eliminates the slow and error prone method of hand calculating the position for each leaf." This suggests implicit acceptance criteria related to accuracy and efficiency compared to manual methods.
   • Reported Device Performance: The document states, "The primary functions of MLC Fit are, in effect, the same as those of MLC Fit product (K962335) currently being marketed by IMPAC Medical Systems, Inc." This implies equivalence to a previously cleared device, which served as its predicate. However, no specific quantitative performance metrics (e.g., accuracy, precision, speed improvements) are provided in this document. There is no table presenting performance data against defined thresholds.

2. Sample size used for the test set and the data provenance (e.g. country of origin of the data, retrospective or prospective):

   • Not provided. The document does not mention any specific test sets, sample sizes, or data provenance from clinical sources.

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):

   • Not applicable/Not provided. Since no specific test set or ground truth establishment based on expert consensus for clinical accuracy is described, this information is not present. The software's function is geometrical definition, not diagnostic interpretation.

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

   • Not applicable/Not provided. There is no mention of an adjudication process for a clinical test set.

5. If a multi-reader multicase (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, not done/applicable. This device is not an AI/ML diagnostic or assistive tool for human readers in the traditional sense of interpreting images. It is a tool for defining treatment field geometry. The effect size of how human planners improve in efficiency and accuracy with MLC Fit vs. manual methods is implied as beneficial ("eliminates the slow and error prone method"), but no quantitative study or effect size is provided.

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

   • The MLC Fit is a standalone algorithm in its core function: "It only provides the definition of the treatment field as a hardcopy and to a database file." However, this is not an "AI algorithm" in the modern sense. Its performance relates to its ability to generate correct geometric parameters based on user input, not to make independent clinical decisions or interpretations. The users can "adjust" parameters, indicating it's a human-in-the-loop tool whose output can be modified. No formal standalone performance study report is provided.

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

   • Not applicable/Not explicitly stated for a clinical context. For a geometry definition tool, the "ground truth" would likely be the mathematically correct or clinically desired geometric configuration for a given treatment plan. This would be established by physics principles and clinical requirements, rather than pathology or outcomes data. The document mentions "Software Requirements Specifications and documented by Software Design Descriptions" which would define the expected behavior and correctness (the 'truth') of the geometric calculations.

8. The sample size for the training set:

   • Not applicable/Not provided. This device, as described in 1999, does not appear to be an AI/ML device that uses a "training set" in the contemporary sense. It is a rule-based or algorithmic software tool implementing geometric calculations.

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

   • Not applicable/Not provided. As there's no mention of a training set, the establishment of its ground truth is also not applicable or discussed.

Summary of Missing Information (Common in Modern AI/ML Submissions):

• Quantitative performance metrics (e.g., sensitivity, specificity, accuracy, precision, AUC)
• Specific acceptance criteria with numerical thresholds
• Details of a validation dataset (size, characteristics, provenance)
• Methodology for establishing clinical ground truth (e.g., expert panel, histopathology, long-term outcomes)
• Results of comparative studies (e.g., non-inferiority trials, MRMC studies)
• Specific information about AI/ML model training (training set size, annotation methods, type of model)

This 510(k) submission from 1999 primarily focuses on describing the device's function, its equivalence to a predicate device, and the adherence to quality systems in its development. It predates the widespread regulatory requirements for detailed performance evaluation of AI/ML-driven medical devices.

Ask a specific question about this device

SEQUENCER is to be used to facilitate the delivery of defined radiotherapy treatment plans. SEQUENCER verifies the settings on a radiotherapy treatment machine prior to treatment and records the actual parameters after treatment. SEQUENCER can be used whenever radiotherapy treatment is prescribed.

The primary function of SEQUENCER is to assist in setting up the patient for treatment and verifying that the treatment setup is correct for a patient undergoing radiation therapy. SEQUENCER may be used to help in the setup of geometric and console parameters and verify the set parameters on the treatment machine with the planned values. After treatment the actual values can be recorded. This assists in tracking the dose given to the specified location.

This document is a 510(k) Pre-market Notification for a device called "SEQUENCER." It describes the intended use and development process of the software. However, the provided text does not contain any information about specific acceptance criteria, performance studies, sample sizes, ground truth establishment, or expert involvement.

The document focuses on:

• Intended Use: To assist in setting up and verifying radiation therapy treatment parameters and recording actual values after treatment.
• Context: Used in radiation therapy to reduce setup errors and track dose delivery.
• Development Process: Developed under IMPAC's Quality System, adhering to 21 CFR 820, with Software Requirements Specifications, Design Descriptions, and Hazard Analysis.
• Regulatory Status: A 510(k) clearance (K981313) from the FDA, indicating substantial equivalence to a predicate device.

Therefore, I cannot fulfill the request to describe acceptance criteria and the study that proves the device meets them because this information is not present in the provided text.

The document is primarily a regulatory submission outlining the device's purpose and compliance with quality systems, not a clinical or performance study report.

Ask a specific question about this device