The Name of the Game
IMRT, IGRT, VMAT, IMAT, CBT, ART, DART, BART, VGRT, DGRT, SGRT, ...
These are only a few acronyms for techniques currently en vogue in radiotherapy. Who knows what they all mean? Some of them stick (like IMRT), but others are mentioned only in a few papers or press-releases and will probably soon be forgotten.
Varian calls its VMAT/IMAT/WHATever-solution RapidArc, which, at least, gives a hint of what it does: it's an Arc treatment and it is (said to be) fast. The key paper by Karl Otto gives the best description in a compact form: RapidArc is "IMRT in a Single Arc".
When we speak of IMRT here, we mean fixed-gantry IMRT with several fields, dynamic MLC and the sliding-window-technique. This is what we have been doing in KFJ for nearly ten years now. We cannot treat RapidArc on our old machines, so we can only comment on RapidArc planning.
RapidArc and IMRT
We assume you are familiar with Eclipse IMRT planning. The Plan Geometry Optimizer (PGO), also called Beam Angle Optimizer, helps a lot in the cumbersome process of finding the best beam angles, because it determines the "optimal" angles in an optimization process. But compared to IMRT planning with Eclipse and the PGO, RapidArc Planning is even easier:
- There is no question about how many treatment fields are optimal. Defining a single static field with the desired machine and energy is sufficient. When "Arc Optimization ..." is selected from the menu, the static field is converted into a 360° Arc field.
- There is no calculation of leaf motions after leaving the optimization loop - the leaf motions are inherently created during optimization.
- There is no manual start of 3D-dose calculation after the leaf motions are calculated. After the optimization, Eclipse automatically proceeds to dose calculation.
The last point is the biggest time-saver of all: it means that once the "Optimization" button is clicked, one can leave the workstation, and come back after 45 minutes or so, to evaluate a calculated plan.
Some more things to know:
- Dose constraints for targets, organs at risk, normal tissue etc. are defined in the same way as during IMRT planning - same user interface, same constraints library, same handling of precalculated dose distributions that are be taken into account during optimization ("Base dose plans").
- While in the loop, constraints can be modified, new constraints can be added.
- The Arc can also have less than 360° - if the user manually defines an Arc field instead of a static field and specifies start and stop angle, Eclipse respects this and assumes that this is the Arc it should optimize.
- The plan can have multiple Arc fields: if the user has a reason to define more than one Arc, he/she can do so. The limit currently (version 8.6.14) is a total Gantry angle of 1000° (about 2.8 full rotations).
- Before clicking "Optimize", the user may choose to optimize Collimator rotation, Isocenter position, and Couch rotation. All three are on by default.
- Up to two avoidance sectors can be defined (see also the page on couch dosimetry).
- MU constraints can be defined, setting lower and upper MU limits (never tried).
Progressive Resolution Optimizer
The Progressive Resolution Optimizer (PRO) is a feature of RapidArc. It produces Arc plans with highly dynamic MLC movements, variable dose rate and variable gantry speed.
The power of the PRO can be best seen by watching the real optimization process. The following movie is captured from a rather complex head and neck optimization with a lot of structures (the uncut AVI is here).
The movie runs at 4 times the normal speed. The time diplayed in the Optimization window starts when the user clicks "Optimize". The first minutes are skipped, because during preprocessing, there is nothing to see:
The Progressive Resolution Optimizer has five resolution levels, which correspond to an increasing number of control points. In all plans we optimized up to now, the final number of control points at the end of level 5 was 177, which means that upon exiting the loop, there is a control point about every 2° of Gantry angle.
Here is a movie of a head and neck Simultaneoulsy Integrated RapidArc Boost treatment (what about SIRAB as a new acronym?) in Beam's-Eye View. The supraclavicular lymph nodes are included in the treatment.
While in the loop, one can always press the Pause button ("Level Hold"), which locks the optimization to the current level. One can also jump back one level or jump forward. This may make sense if the user adds new constraints or changes existing constraints while optimizing. One could reason that jumping back one or two levels after such an interaction reduces the danger of being "trapped" in a higher local minimum. Another reason to jump back one level is to get to a coarser control point sampling after the optimization has been restarted from a previous run.
As can be seen in the movie, whenever the optimization reaches a new level, the value of the optimization function drops considerably. Actual MU are continuously displayed, MU go up as plan complexity increases. At the beginning of a new level, the MU values in this example are: 209 - 327 - 370 - 410 - 430. Optimization finishes with 436MU (the final number may change a little depending on the type of plan normalisation). A conventional fixed-gantry IMRT plan with five fields and the same constraints needed 633MU.
The PRO converges fast, is absolutely stable (not a single crash since installation!) and fit for routine use. A typical prostate plan takes about 15 minutes to optimize, complex head and neck cases about twice as long.
Memory consumption is quite reasonable (about one GB while optimizing). The only drawback compared to fixed-gantry IMRT is that 3D-dose calculation of RapidArc takes quite long (about 30 minutes), if dose is calculated on a single workstation. This is the same situation as for Conformal MLC Arc plans, which also are subdivided into 180 control points for a full 360° Arc. A simple forward-calculated Conformal MLC plan with one Arc field takes over 40 minutes to calculate. RapidArc and Conformal MLC are therefore ideal candidates for parallelization on the Distributed Calculation Framework.