Automatic treatment planning implementation using a database of previously treated patients

Purpose: Using a database of prior treated patients, it is possible to predict the dose to critical structures for future patients. Automatic treatment planning speeds the planning process by generating a good initial plan from predicted dose values. Methods: A SQL relational database of previously approved treatment plans is populated via an automated export from Pinnacle3. This script outputs dose and machine information and selected Regions of Interests as well as its associated Dose-Volume Histogram (DVH) and Overlap Volume Histograms (OVHs) with respect to the target structures. Toxicity information is exported from Mosaiq and added to the database for each patient. The SQL query is designed to ask the system for the lowest achievable dose for a specified region of interest (ROI) for each patient with a given volume of that ROI being as close or closer to the target than the current patient. Results: The additional time needed to calculate OVHs is approximately 1.5 minutes for a typical patient. Database lookup of planning objectives takes approximately 4 seconds. The combined additional time is less than that of a typical single plan optimization (2.5 mins). Conclusions: An automatic treatment planning interface has been successfully used by dosimetrists to quickly produce a number of SBRT pancreas treatment plans. The database can be used to compare dose to individual structures with the toxicity experienced and predict toxicities before planning for future patients.


Introduction
Treatment planning involves taking a set of patient specific structures and designing a dose distribution which meets clinical objectives. Unfortunately, beyond the clinical objectives, it can be difficult to estimate the minimum achievable normal tissue dose or even which planning objectives are achievable. By using a database approach, this information can be captured from prior patients to give a good estimate of the achievable dose for a future patient. The use of a database in treatment planning improves plan quality by suggesting the lowest known achievable dose from prior patients whose Organs at Risk (OARs) are closer to the target volumes, which are harder to spare. This system also improves safety by indicating plans that do not meet the objectives met by prior similar patients.

Database and Software
The automatic treatment planning software uses a Microsoft SQL Server 2005 relational database to store dose and structure information from the clinically approved treatment plans for a set of prior patients. The schema [1] of this database additionally allows for the storage of demographic and toxicity information.
The software interface to the database is written in Python using Tk to generate a user interface. To aid in the building of the database, a series of scripts are used to automatically export the information from the Pinnacle 3 treatment planning system. While this software is initially developed to interface with Pinnacle 3 , the software and database exist outside of the planning system and can be interfaced with any other system that permits a scripting interface, or can be used to manually enter the results to the planning system.

Plan generation and naming Consistency
Unfortunately, using a database to store the vast amount of information used in treatment planning requires consistency in the naming of structures and other plan information. To make the process quicker and easier to use, a renaming interface (Figure 1) is developed to automatically map known alternate names to a common set of names. The general naming scheme is based upon published naming recommendations [2]. The naming interface automatically converts all names to lowercase and removes any non-standard characters. The interface also prompts the user if any expected structures are missing. In the case of missing structures, the user can manually rename structures if they were not matched in the automatic process, otherwise the missing structure may need to be contoured.  For use in automatic planning, each structure must also be tagged as a target or OAR. Structures may also be tagged as none, which excludes them from the database. The renaming interface is also used to generate the basic components of the plan. The contours are cleaned to remove small (<0.1 cm 2 ) non-contiguous curves outside of the structure, ring structures are expanded outside of the target structure to reduce dose outside of the target in planning and combined structures are such as "combined_kidney" are joined from their smaller components (rt_kidney, lt_kidney). The user can select a machine and energy as well as a predefined beam arrangement. The isocenter is set based upon the target selected by the user and the dose grid is automatically specified to cover all of the selected structures.
After the basic plan is generated, overlap volume histograms (OVHs) [3][4][5][6][7] are generated for each target/OAR combination. OVHs are used to select patients from the database which are harder to plan than the current patient. OVH calculation requires approximately 1.5 minutes for a pancreas SBRT plan, but the time depends on the number of contoured structures -roughly proportional to the number of targets multiplied by the number of OARs.

Database query and plan optimization
Once the OVHs have been computed for the current patient, an objective query interface (Figure 2) is used to select the optimization objectives to be used. The user selects a predefined protocol for optimization which contains the basic objectives to be used. The dose value for each objective is queried from the database by selecting the lowest OAR dose from all patients that have the minimum target coverage required and the same or lower distance to overlap for the specified structure. This effectively takes the lowest achievable OAR dose from all patients that are the same or more difficult to plan. Each planning objective is queried separately from the database. A color coded system is used to indicate the success of the query. Successful queries are colored in green, unsuccessful queries are colored orange. Generally, an unsuccessful query indicates that the current patient has a lower distance to overlap than all other patients in the database. For unsuccessful queries, the user can manually enter a value or accept the tolerance limit which is automatically populated into the field.
New protocols can be developed by creating a new comma separated values file which contains the new objectives and limits for optimization. This allow for easy deployment of the software to new treatment sites and changes of protocol without modifying the software. The software allows for specification of absolute volumes as well as relative volumes for objectives. In the case of absolute volumes for a protocol, the relative volume will be automatically calculated to be exported to the treatment planning system. Querying the database currently takes approximately 4 seconds for each objective. As the number of patients in the database increases, the time required to query objectives will increase. If the time increases sufficiently to slow planning, pre-computed dose values may be stored in the database for commonly used volumes. This gives up the flexibility of arbitrary volumes in the query but greatly reduces the time required. After the objectives have been queried from the database, a scripting interface allows for the objectives to be directly loaded into the treatment planning system and optimization automatically started.

Plan evaluation
To aid in evaluating the optimized plans, a protocol check tool (Figure 3) is developed which highlights the clinical objectives that are not met by the current plan. This tool automatically exports the dose from the planning system and displays a color coded interface with achieved objectives in highlighted green, acceptable deviations in yellow and unacceptable deviations in red. This tool can be used to determine which planning objectives need to be adjusted to improve the desired trade-offs of the plan and serves as a one click took for quick evaluation.

Database Submission
Upon completion of a treatment plan and clinical approval, the plan can be submitted to the database with all structure and dose information. By adding new plans to the database, the quality of future plans is improved. An automated interface is used to export all required data from the planning system and submit it to the appropriate database. Each new plan added to the database improves the quality of future plans queried.

Results
A database driven automatic planning tool has been developed and put into clinical use for SBRT pancreas patients. OVH calculations require less than 1.5 minutes for a typical pancreas patient and database lookup time is approximately 4 seconds per objective. We estimate the overall time required for patient to be processed using this tool is less than the time required for one plan optimization step. If the tool results in even one less optimization step to generate an acceptable plan, a net time savings is realized.

Conclusions
Automatic planning has the ability to improve quality and safety of treatment plans while reducing the overall planning time required. A database approach allows for similar patients to be selected and has the potential to select similar patient plans based upon dose and toxicity information. Automatic planning tools allow for less experienced planners to generate high quality plans based upon prior patients.