Skip to content

External beam planning

Jump to bottom
Csaba Pinter edited this page Nov 5, 2018 · 5 revisions

Overview

External Beam Planning module has started to gain interest from outside our core team: previously it was used solely by Kevin Wang and Greg Sharp and their students, but recently several other people expressed their interest in using this as an open-source treatment planning platform. Thus it is needed to make it more generic, so that other dose calculation engines can be easily integrated into this framework.

The ticket corresponding to this project is #743

People: Csaba, Kevin, Greg

Plan

  • Beam visualization

    • Slice intersections look chaotic, semi-transparent fill would be much better in 2D
    • Change color of beam when it is selected (in EBP module and in Data / SH)
    • Beam node not sublass of model, implement displayable manager (2D too). After the dose is calculated, show that in 2D?

  • Dose engine plugins

    • Operations: two buttons on the bottom of the module widget
      • Calculate apertures: detach it as a separate button
      • Compute dose
    • Matlab adaptor, interface with MatRad
    • Default engine in Application Settings

  • Ports

    • Apertures (cerrobend blocks), MLC (different kinds! + dynamic), Target volume. Mix&match, because you want to be able to choose any of those
      • MLC import from DICOM
    • New MRML node and UI (tab) for that
    • In EBP core, and provide routines for calculating MLC patterns, and applying those to calculation
    • Port is a 2D concept so may need to think more
    • Create port button instead of tab?

  • Beam groups: plan contains one or more beam groups, a beam group contains one or more beams

    • Properties defined for each beam group, which the contained beams share: Plugin dose engine, Isocenter, Target segment, Isocenter specification
    • Rethink beam cloning

  • Allow re-weighing beams without re-calculating individual doses

    • Add flag (or compare modified times) for whether beam parameters changed, only do dose accumulation otherwise

  • Make weights add up to one (because prescription is for the total dose)

  • DRR

    • DRR calculation logic to separate class but still within EBP logic
    • Use Planar Image module to show DRR
    • When loading or creating DRRs, put them under the corresponding beam (also when loading from DICOM-RT)

  • Lots of TODOs and commented-out code need cleaned up

  • Add documentation to the top of this page for creating EBP plugin

Future

  • Sequence node can be used for:

    • This will work good for the energy map for spot scanning
    • Maybe also for WEPL images
    • Investigate how they are saved

  • Allow different types of beams in one plan (also beam groups?)

  • Beam groups

    • Different isocenters per beam group

  • Add function for adding 2d image to beams, used for DRR and fluence images as well (?)

  • WED: outsource to a plugin (we do not want to sum up the doses for this! - option to disable that?)

    • Inputs: CT, gantry angle, isocenter, aperture

  • Support non-external beam plans (ablation (Dionne), brachy (Sunnybrook?))

Notes

  • User workflow

    • User clicks "Add beam"
    • User cannot edit UI of beam settings prior to clicking "Add beam"
    • EBP identifies plugin (based on "radiation type").
      • Plugin offers pre-set beams with default values for the new beam
      • The user can choose the preset being used for the new beam
    • Plugins to define tabs in the UI if necessary (and use the basic UI for that particular beam type in general)
      • Version 1.0 of EBP will keep proton UI in EBP

  • Creating a node

    • Paradigm A
      vtkSmartPointer x = vtkSmartPointer::New() scene->AddNode(x)
    • Paradigm B
      X* x = X::New()
      scene->AddNode(x)
      x->Delete(); // Without this there is a leak

  • Module startup logic, from reverse engineering

    • vtkModule (logic object) created

    • User clicks module

    • qModule (UI object) created

      • Is the logic already set at this time?

    • qModule::setup

    • qModule::setMRMLScene

    • qModule::enter

Done

  • Kevin will check in the update to the Beams module Done

  • Greg will make subclass of vtkMRMLRTBeamNode for proton beam Done

  • Greg continues moving code from EBP MRML node into Plan / Beam nodes Done

  • CreateDefaultRTBeamNode() in vtkSlicerBeamsModuleLogic should be modified to create models for beams already created Done

  • Model creation routines are all already moved into Beams module, therefore can be deleted from EBP module Done

  • Greg will work on getting AddBeam in EBP not to crash Done

  • Displayable nodes

    • It would be nice for plan/beams nodes to have displayables

  • Beams module

    • Beams module holds all the MRML node definitions

      • Beam MRML nodes in Dicom RT / EBP are moved to Beams

    • vtkMRMLRTPlanHierarchyNode: Remove this, SH instead

    • vtkMRMLRTPlanNode::RTPlanDoseEngine: Use the plugins instead

  • Plugins

    • Beam nodes contain different data per plugin: subclass vtkMRMLRTBeamNode

      • Define subclasses for the different beam types to store beam parameters (vtkMRMLRTPhotonBeamNode <= vtkMRMLRTBeamNode)
      • Remove vtkRTBeamData (not really used for anything, use attributes instead)

    • Input: beam node, CT volume (, target volume, skin surface, isocenter (this should be part of a beam))

    • Output: one dose volume per beam, EBP adds them together (this will allow beam weighting too)

    • Logic provides

      • InitializeAccumulatedDose -> Removed
      • ComputeDoseByPlastimatch (move this from logic to Plastimatch plugin)
      • GetPresetBeamNodes -> Not created (can be got from plan node)

    • Widget provides UI file defining new beam parameters tab and widget class synchronizing the new tab's content with the proper beam subclass

      • Use CLI UI generator if possible (idea rejected)
      • Use Qt engine plugins and allow them to define beam parameters and widgets

    • vtkSlicerDoseCalculationEngine: Becomes the first plugin class, rename to vtkSlicerProtonPlastimatchDoseCalculationEngine

      • Use DoseAccumulation logic instead RegisterAccumulatedDose to add beam doses (apply weights too)

    • Need new directory to hold the proton plugin

  • Create Beams table widget

    • Table rows and current table row should be moved to MRML and parameter nodes respectively -> table widget takes care of this

  • Consider what to do about Beams logic class

    • EBP should create logic object? Beams logic functions moved to MRML class? Same question for qSlicerBeamsModuleWidget. It can probably be stripped down to a dummy module widget
    • -> EBP was splitted to EBP and Beams, so that EBP handles the plan and Beams handles the beams, as the convention in Slicer suggests (each module handles its own node).
      • Re-usable beams table widget shows the beams, Edit button next to each beam takes user to the Beams module and the requested beam is selected
      • Add a button in Beams module to switch to EBP selecting the parent plan node
      • Beams logic should contain all beam-specific functions
      • Result: Less cramped UI, adhering to Slicer conventions, more readable and maintainable code

  • Figure out what to do with dose calculation output

    • Need new function in RTBeam to add a dose volume

  • Add automatic test

    • C++ logic test

  • vtkMRMLRTBeamNode:

    • currently it only has a reference to a model node (maybe in the future This will subclass (or reference) the model node)

  • Isocenter markup and coordinates widget need to be synchronized

  • Figure out what to do with dose calculation output

    • Decide what to do about aperture and range compensator image

  • Plugins

    • Plugin infrastructure for C++ dose engines, proton is the first plugin
    • Plugins to define tabs in the UI if necessary (and use the basic UI for that particular beam type in general)
    • Add Cobalt60 plugin (won't do)
    • Allow defining dose engine plugins in separate extensions
Clone this wiki locally