Introducing "Track-it"
What It Is
PTW Track-it is a server-based, multi-user software which collects and manages QA measurement results from various PTW software programs in a single database. It can be used to generate periodic QA reports in a more or less automated way. All typical linac QA procedures the medical physicist performs in the clinic can be implemented in Track-it.
The software does not perform any analysis of raw measurement data. Track-it is neither supposed to replace the software programs which are used for data acquisition, nor is it meant as an data archive for measured raw data. Beam scanning data within Track-it always shows up together with the respective analysis results, which are based on some QA protocol. However, if manually entered data is processed, the term "analysis result" has a more general meaning: a pass/fail result of a visual check is an analysis result per se, and can be used in a report.
(Part of Track-it report during testing)
Track-it is accessed via any modern web browser, which means that also mobile devices (iOS, Android) can be used. We describe the current software version, which is 1.1.
What It Does
The typical workflow is the following: measurements are recorded with PTW software (QUICKCHECK, MultiCheck, Mephysto tbaScan, VeriSoft, epidSoft, ...) and analysed according to a certain international (DIN 6800-2, AAPM-TG51, ...) or home-made protocol. Data plus analysis results are exported to Track-it. Nearly all of the latest PTW software releases provide an "Export to Track-it" button.
When Track-it receives data, the protocol templates can be populated either automatically or manually. Automatic data filling works if input can be "linked" to the protocol template's tasks. All tasks with numeric contents can have defined (upper and lower) limits. Based on these limits, protocols will mark the tasks either as passed or as failed. The resulting reports (e.g., the "First biannual QA on TrueBeam 1469 in 2017") can be approved and printed.
A dedicated trends section allows the user to track changes in the performance characteristics of a machine, in a way which is otherwise hard to achieve: each data acquisition software only tracks its "own" data (if it offers this functionality at all), like the 6 MV dose output of a certain machine over time (as in QUICKCHECK) or the inplane beam symmetry for 10 FFF and 40 x 40 cm over time (as in MultiCheck). At least in theory, collecting all QA results in a single place gives more information on the performance status of a linac, which means better quality control. PTW seems to quote Aristotle (who was later condensed by Euclid): "The whole is greater than the part." In the context of linac QA however, proof is still pending.
Track-it Lingo
When performing the first steps in Track-it, newbies may face the challenge of understanding the terminology. What is the difference between a measurement parameter and a data type? What is a category and what is a task?
Data Types and Measurement Parameters
Data types are the analysis parameters of a measurement. The quality index (Qi) of a depth dose curve is a data type in Track-it, with value type floating-point and a value of, e.g., 0.667. Other available value types are integer (Sick physicists = 3) or Boolean (Safety test passed = Yes).
Data types sometimes show up in Track-it with a definition, but not always. Definition means the underlying protocol (DIN 6800-2, ...). Where does it come from? If a curve is analysed in Mephysto or MultiCheck, it is always analysed based on a user-selected protocol. This information (only the name of the protocol, not the formulas) is also forwarded to Track-it. On a machine with FFF energies, there will be probably at least two "field size" data types: one "field size" with definition "Varian 2016" which describes the FFF field size results (special FFF analysis formalism!), and a second definition for the "ordinary" flattened beam sizes (definition is "KFJ" in our case):
Note that "field size" can either be a data type (if the field size is the result of a measurement, i.e., the field size was measured), or a measurement parameter.
The measurement parameters specify all the details regarding machine and measurement setup which are needed to reproduce the measured value. If "field size" or "energy" are not specified (along with some more measurement parameters), a measured "R50" value of an electron depth dose curve won't be of much value.
On the other hand, if too many (unnecessary) measurement parameters are specified in a task, problems can arise. For instance, if the protocol template with a task for Electron data contains the measurement parameter "Block = None" (this is the case in the predefined DIN templates), then the automatic linking will not work, if the electron data is exported from Mephysto 3.4, because exported results simply do not contain any "Block" information. A similar example with Photon data: If the Photon task in a protocol template contains "Applicator = None", linking will not work either, because the export of photon data from Mephysto does not contain any "Applicator" information. If the set of measurement parameters in a given task is reduced to the necessary minimum, all works well (well, most of the time, see below).
Tasks are the "atoms" of a QA report, under the assumption that atoms cannot be further divided. The inplane symmetry of a 6 MV, 10 x 10 cm field is an example of a task. During protocol template creation (or editing), the task looks like this:
(Sample task for a single symmetry value. The task still contains three "unnecessary" measurement parameters.)
Similar tasks are grouped into categories. They typically correspond to section titles in QA protocols (e.g., "Depth dose - Photons"), when the section requires depth dose measurements of various energies and field sizes.
Finding a Good Starting Point
The building blocks fall in place more quickly - in our experience - if one starts with an empty database and does some experimenting, in a repeated cycle of sample data export and "clean up". The export of a single PDD curve from Mephysto or a single beam profile from MultiCheck to an empty Track-it database creates several objects, such as radiation units (linacs), measuring devices (e.g., MP3, STARCHECKmaxi), and more. New data types will show up under "Home / Settings / Data types". Some of them will have a definition or a unit, but this is not necessarily the case. At least, they always have a value type such as "Boolean", "Integer" or "Floting-point number".
After a single export to Track-it has been fully understood, we "clean up" by deleting everything: all data, data types, measurement parameters, radiation units etc., in order to reestablish the pristine and empty database.
It is evident that the deletions have to be done top-down, not bottom-up. Underlying objects can never be deleted. Trying to delete the measuring device "MP3" will fail, as long as other objects still reference to it:
Likewise, imported data cannot be deleted if it is already used in a protocol, so the protocol has to be deleted first.
Then we repeat the sequence by exporting either something different or the same beam profile but this time analysed with a different analysis protocol. This is a very efficient way of checking whether analysis results "arrive" in Track-it as expected.
Getting Data Types Consistent
As already mentioned, PTW provides some predefined protocol templates, which shall help to implement DIN or TG-142 QA procedures. Experimenting with them in the described way reveals that automatic linking not always works, if new data types are created based on these templates. For instance, when a depth dose curve is exported from Mephysto, the data type "Surface dose" will be created in Track-it. However, the DIN protocol template expects the data type "Ds".
Another example, which reveals a "home-made" problem, is the electron depth dose analysis parameter R80, which in our institution is the common name for the therapeutic range. We were surprised that instead of the expected "R80", the data type "Rt" was generated in Track-it. A look into the protocol reveals that the real name of the analysis parameter is "Rt", not "R80":
R80 is only the caption, and the user can change the value and the caption to whatever he wants. Some institutions will define R90 as their therapeutic range. However, the data type in Track-it will always be Rt. It's good to be aware of such things.
These kind of problems can be circumvented by first exporting sample data (which will create new data types), and then selecting these data types during protocol template creation:
It is therefore smarter to use the data types which were created by a sample data export, because this makes sure they match the ones the template expects.
Which Data Types are Needed in Track-it Anyway?
It is a good idea to think about this question. The following image shows the home made KFJ protocol for Electron PDDs, with only three analysis parameters checked: dmax, R50 and R80:
In the context of Electron depth dose measurements, the Austrian standard ON S5290-1 only requires certain analysis parameters to be determined. Mephysto offers many more, like the "practical range", Rp, the "mean energy at phantom surface", E0(mean), or the "X-ray background". What sense would it make to export them to Track-it if they will not show up in a report? We therefore reduced our protocol to the minimum to make sure that when the "Track-it" button is hit, only the analysis parameters which are really needed will be exported.
Automatic Filling of a Sample Report
The most basic task which involves automatic filling shall be demonstrated next. On the TrueBeam, we have measured PDD curves (field size: 10 x 10 cm) for all five Photon energies (6, 10, 15, 6FFF, 10FFF). The three analysis parameters dmax (depth of dose maximum in mm), Qi (quality index) and D100 (relative dose in 100 mm depth) shall be transferred to Track-it.
The depth of dose maximum is called "R100" on the Mephysto side (left screen). It is identical to the caption name (see small insert), which is also "R100". But this is a coincidence. It is not the caption name which is transferred. The caption can have any name. It is best to find out via test export, as described above.
The right screen shows the task which will capture R100. Only four measurement parameters are defined: "energy", "field size", "modality" and "scan type". We don't use gantry rotation, collimator rotation or SSD. If all measurements in a QA program are performed at gantry 0° (very common for water phantom scans!) and at SSD 100 cm, it is not necessary to set them as measurement parameters.
Note that data input is set to linked, not manual. Similar tasks exist for Qi and D100. Three tasks times five energies gives a total of 15 tasks forthe category Photon depth dose.
The DataAnalyze window on the left has the Track-it button armed, which starts data export. We now export the five PDD curves (not shown).
In Track-it, a new semi-annual report is created for the second half-year of 2017, which means that only data from this period will be used. In this new report, at the beginning all tasks are blue which means "open". We click on the magic wand to "auto link data":
A second later, nine tasks turn green. This tells us that they are now populated:
We open the report and identify the nine tasks where linking was succesful:
Linking did not work for the six tasks of 6 MV and 10 MV (flattened beams). The reason is the following:
When a task in a protocol template requires the measurement parameter "FFF = No" in order to link some non-FFF result, automatic linking of imported data will not work for non-FFF data, because DataAnalyze of Mephysto (currently) only adds "FFF = Yes" in the case of an FFF beam, but it does not add "FFF = No" to non-FFF data. Since the information is not provided, no automatic linking is performed. "No FFF" is not the same as "FFF = No"!
To resolve the issue, we click on "Select data point" to choose the correct data set. This brings up a data selection dialog:
Two wide rows are displayed. The second one would be within limits (green background). By clicking on it we select it but we want to scroll to the right for find the definite information which identifies the correct data set and proves that we were right:
As expected, the second row contains the non-FFF 6 MV data set, which is the correct one for this task, so we were right to select it.
In this case, the following workflow would have been smarter, because it avoids the "select data point" step.
Instead of exporting all five PDD curves and then auto-linking them, we first export only the non-FFF curves, and immediately link them. This works automatically, as before. Now we export the FFF curves to Track-it. Since the non-FFF curves have already been auto-linked, there is only one PDD per energy which still requires auto-linking, and auto-linking works without user-intervention!
This is the report with all tasks linked:
The second column displays the data type dash definition. "R100 - KFJ" and "QI - KFJ" have the definition KFJ, but why not D100? PTW's logic is this: If the definition offers a choice between different analysis formulas, then the definition is printed, otherwise not. Compare the definitions of Qi, R100 and D100. The quality index can be calculated in various ways, and even the dmax finding which gives R100 can either be simple or "optimized". But D100 is just the relative dose in 100 mm depth, period. No choice, therefore no definition.
Finally, this is how the PDD section of a semi-annual check would look like when printed:
The contents of the header (institution name, address, english or local language etc.) can be controlled via the file "print.config" on the Track-it server. Hint: if special characters are used in the header's contents ("für", Straße"), the utf-8 encoding in the header of "print.config" must be changed to an encoding which supports these characters (e.g., iso-8859-1), otherwise PTW Track-it Service in the server will not start.
Summary
This should give a first impression of Track-it as a report generator. It is not an in-depth discussion of all of its capabilities. As far as we can say so far, Track-it is a software with considerable potential for clean and well-structured linac QA.