In clinical radiation physics, it is common practice to subject all treatment plans to a secondary dose check before they are applied to the patient. This can be done either via some kind of measurement, or with an independent dose calculation. In both cases, the result is compared to the TPS dose, and, if agreement is found within specified limits, the plan is approved for treatment.

Evolution at our Institute

The most simple method of secondary dose checks is point dose (1D) calculation. We mentioned our home-made iCheck software in 2005. DIAMOND, introduced in 2013, was mainly used for calculating Hybrid IMRT (breast) plans, i.e. plans that contain both static1 and sliding window IMRT fields.

Varian Portal Dosimetry (VPD) is a 2D method which uses images aquired with the MV detector and compares them to predicted images. VPD was first covered in 2005, then more thoroughly in 2007 and 2011 (PD in ARIA10). In 2013, we presented the QA results of the first 313 clinical VMAT arcs delivered on the TrueBeams. The table referenced also lists the results of EPIQA, which is an alternative way of evaluating the same portal images. EPIQA was described in 2011 (Clinac) and 2012 (FFF on TrueBeam). The DIAMOND and Portal Dosimetry QA results between 2013 and 2015 contains a long list of 943 plan evaluations. Both VPD and EPIQA can handle the highly modulated HyperArc fields.

3D verification results so far could only be achieved at our institute by using the PTW Octavius 4D system. Calling this system the "gold standard" is a neat way of saying that it is not used very often. This is true. The simple reason is that on a TrueBeam machine with fully integrated VPD, a VMAT plan can be prepared, measured, evaluated and documented in about 3 minutes. Setting up a phantom on a regular basis2 is simply no desirable option.

Fully Automated QA

For fast routine plan QA, we recently purchased VERIQA from PTW. VERIQA RT MonteCarlo 3D uses the proven SciMoCa™ Monte Carlo algorithm to calculate 3D dose. After right-clicking a plan in Eclipse3 and sending it to VERIQA, the system performs calculation and analysis in a fully automated way.

VERIQA
(The web interface offers a simple slice viewer.)

The level of interaction is up to the user. Finished evaluations can be reviewed in the web interface, typically by selecting the recent results. The simple slice viewer (only showing transversal slices) can be used to display MC and TPS dose, dose difference and the Gamma map. It is very convenient to identify regions of discrepancy (see below).

This page was written after only two days of experimenting with VERIQA RT MonteCarlo 3D, the basic MC module. More importantly, this is the status before any software training by PTW took place4. At the time of writing, there is not even a scheduled date for the training. We still think it makes sense not to wait and present a few findings, as this might be interesting for the reader at a similar stage of implementation. It also proves that the system is very easy to set up and configure without the help of PTW or user manuals5.

Ready, Set, Go ...

The "Go" came on June 7, when we received a download link from Oliver Schrenk, Head of Customer Success Management at PTW Freiburg. We downloaded a ZIP archive called "Wien_2024-06-07" on June 11. This archive contained a "Linac Models and Reports" folder which again contained another "LinacModels.zip" archive plus six PDF files: one "VERIQA_VerificationReport" for each energy, plus a "VERIQA Configuration Protocol" with a summary and a simple bullet list of instructions how to proceed. The verification reports give an impression of how good the MC model is able to reproduce the user data (PDD, profiles, OF).

After logging in on the VERIQA web interface6, we started to follow the bullet list in the "Radiation Units" section:

Then came the "Beam Models" section, which started with a crucial bullet:

We had previously been concerned about how it would be possible to transfer files to the Linux server, as hospital networks today are secured in a similar way to Area 51 in the early 60s. We were therefore very pleased to see a large "upload file" button on a web page. For uploading the customized beam models from PTW the user communicates with the Linux server via VERIQA's web interface, which is very convenient.

We now left the bullet list because it pretty much ended at that point. We felt the next thing to try was to send VERIQA a plan from Eclipse and to see what happens.

One Step at a Time

In Eclipse, we created an "VERIQA Export" filter of type DICOM Storage Export Filter (pic1, pic2). We exported the first plan from Eclipse which yielded an "Incomplete data" entry in the Rejected Plan section of VERIQA's Worklist page. Nevertheless, we felt like Elon Musk who sees his Starship explode: Success!

There seems to be no simple way of finding out why VERIQA rejects a plan as incomplete, as there is no log file. But we found the reason quickly when reviewing the Export filter settings: when setting up the filter, it is worthwile checking the "Options" at the bottom, because these options define which DICOM objects get exported from Eclipse. We simply had forgotten to check some boxes in the relevant tabs7 (pic3, pic4, pic5). In the first "launch test", it was probably only the pilot who got launched without his spaceship!

The next success was to see "Incomplete data" being replaced by "No CT calibration". Knowing what to do, we defined a CT calibration curve under Home > Settings > Dose Calculation > CT Calibration. We did this by copying the Eclipse mass density calibration point by point8. To have Conditions of Applications which are always true, we selected the DICOM tag (0008,0080) (institution name), which is always equal to "KFJ" in our case.

Proceeding in this style step by step, we saw "No CT calibration" being replaced by "No template", which were persistent even after templates had been defined. The crux is: all these objects need a Condition of Application that matches, so we came back to our bullet-proof DICOM tag (0008,0080) which is the institution name - a switch which is always ON. Refinements can come later.

After these succesful "staging tests", always getting one stage further before the ship explodes, the ultimate success was when the first plan entered orbit aka the "Worklist", and no longer was trashed as "Rejected Plan". The message "Dose engine running" appeared under "Status" for the first time on June 11. We were so excited that we forgot to record the exact time of day.

The Refinement Loop

As already mentioned, to get an evaluation done, at least one so-called Template has to exist which can contain Gamma Protocols and/or DVH Protocols. In order to get results quickly, we felt that implementing Gamma would be faster, because setting up a DVH Protocol means dealing with Structures and defining DVH acceptance limits for each Structure separately, while comparing two 3D dose distributions inside the entire patient volume with e.g. a 3%/3mm local dose Gamma test would be more straightforward.

The first thing we noted was that our Hybrid IMRT breast plans failed. Using the slice viewer, we discovered that these plans typically contain several dummy structures of type CONTROL, which extend beyond the Eclipse BODY structure. While Eclipse ignores such voxels outside the BODY, VERIQA does not. These regions therefore had a high Gamma index, which caused the Gamma evaluation to fail.

VERIQA

A solution to this problem was to use the "ROI Density Overrides". A DICOM Structure Set file (RS-file) has to be imported under Home > Settings > Regions of Interest. From the list of structures, the relevant (dummy) structures can be selected to create a ROI Density Overrides list9. This can be used by the template. When a plan is processed by VERIQA, structures are either removed or density is overridden with a fixed value (We used the latter for an "Artefacts" structure). This solved the problem with our breast plans.

VERIQA

More refinements will surely take place in the future. For instance, right above the IRO density overrides in the "Default Gam33local" template screeenshot, there is a parameter called Minimum ROI Occupancy,10 with the default value 0, We felt that after changing the occupancy to 0.5, the surface zones of TPS and MC showed a more similar dose coverage than with the default setting. The VERIQA manual simply states that the correct TPS value should be looked up in the TPS documentation.

Regarding timing, we experimented with different precision settings (0.5%, 1%, 2%, 4%), which of course have a big impact on the MC calculation time. We currently think that 2% gives a good compromise between speed and accuracy. Increasing the precision from 2% to 1% or even 0.5% does not change the overall results so much that it is worth the extra time. But this may change in the future.

With the standard settings of a browser like Chrome, web pages have to be refreshed manually in order to see whether a plan is still queued, the dose engine is still running or it is done and appears on the Recent Plan Evaluations page.

We found it convenient to add a Chrome extension such as "Easy Auto Refresh":

VERIQA

For each page, a refresh timer can be individually configured, and the settings are remembered. We added a 3-5s refresh timer to the Recent Plan Evaluations page and the Worklist page.

Preliminary Results

After the first two days and more than 100 plan evaluations, we can conclude the following:

We also purchased licenses for the software products VERIQA RT View and VERIQA RT Evaluate, which offer many more viewing and evaluation options. We did not install them yet.

VERIQA is a great tool with a huge potential. Its Raptor engine, the SciMoCa™ algorithm, provides fast clinical plan QA in 3D. So far, we only scratched the surface (We only wanted to get the rocket launched).

After training is complete and the Templates are properly set up, VERIQA RT MonteCarlo 3D will be commissioned for clinical use.

Notes

1 Before VERIQA, iCheck and DIAMOND were our only methods of checking static fields.
2 About 95% of our treatments use modulated plans, i.e. contain IMRT and/or VMAT fields.
3 If no plan is specified, VERIQA cannot know which plan is to be checked.
4 It also means that VERIQA is not yet commissionned for clinical use.
5 The information density in the VERIQA user manual is rather low.
6 The platform has a default user login with "Admin" rights. Any Admin can create other users, either with or without Admin rights.
7 We do not fully understand what each checkbox does, but this is the setting that works. The "Anonymization" tab is not relevant here.
8 In contrast to Eclipse, the HU number in VERIQA must be integer.
9 The list contains a structures named "PTV MAM Dext " and "PTV MAM Sin", which are to be removed. This is no error. They are really dummy structures, because they are generated from the respective CTVs and therefore extend into air.
10 The manual says: "The minimum ROI occupancy has an effect on the dose calculation as it defines the voxels located inside and outside the outer contour and, thus, voxels with or without density. The minimum ROI occupancy also affects the voxels to override with a defined density value in the case of a ROI density override. The minimum ROI occupancy has no direct effect on the DVH or gamma calculation."


back to Medical Physics home