The Astroid Launcher will house the various applications that will be used as part of the Astroid Treatment Planning system. Any updates to these applications will automatically be deployed to the Launcher. The user will be notified that there is an update or a new version that will need installation once they have chosen an application. This will ensure that cloud version of Launcher and the local version of Launcher remain synchronized. Use the following steps to open the Launcher and launch the Astroid Planning App:
The Astroid Planning App stores a list of DICOM files (only CT Image Set and Structure Set files are supported at this time) that are available and ready for Import. There are several approaches that can be used to upload DICOM files into this list.
For clinical users, a DICOM receiver is generally installed, allowing for direct exporting from contouring software or other planning systems for use within Astroid. In such cases, this DICOM receiver service will be pre-configured to upload the incoming files directly to Thinknode and will also create the records necessary for the DICOM files to be populated into the Astroid Planning App list of available Imports.
DICOM files can also be uploaded directly from the Astroid Planning App. The steps below describe the process in detail.
Note: This section requires the user to be familiar with python and the existing .decimal python libraries.
Importing a new patient into the Planning App requires taking a local DICOM directory and posting each of the files through the Dicom App utilizing Thinknode. Each DICOM patient is posted to the Thinknode ISS and an entry is then added to the thinknode RKS that allows the Planning App to see that a new patient has been added. The steps below explain how to upload patient DICOM files using the open source python Astroid Script Library.
# Post patient data into ISS obj_list_id = dicom.make_dicom_object_from_dir(iam, 'F:/Datasets/demo-patient/prostate')
Now that a patient has been uploaded from DICOM, the Planning App should recognize that new patient files are available to import into a Planning patient.
There are multiple levels that various structures can live at. Each level and structure type will effect how the structure will relate to the plan. Refer to the Structure Data Model Guide for more details.
The Astroid patient data model uses a hierarchy of items to model the real world workflow patterns of the radiotherapy treatment process. Please refer to the Heirarchy (Data Model) page if you are not familiar with these concepts.
During patient creation (i.e. Importing) a patient record is created containing a Course and a Patient Model. During Import the required data for the Course and Patient Model are entered, however, the Course remains incomplete. The Course will still require physician directive information including the breakdown of the treatment Prescriptions and (optionally) the specification of Clinical Goals. Before creating a Plan this information must be entered. Once the Prescription is complete, plans can be created. The following sections provide a walk through for completing the Course information.
Prescriptions are cumulative. For example: when adding a second prescription, it is assumed that the highest dose from the first Rx has already been delivered to the target for the second prescription. Therefore, the total dose to all targets in the second prescription will have the first prescription's highest dose added.
Once the Course has been completed the next block will be the Patient Model. The Patient Model contains a single CT image set and all contour variants (targets and organs at risk) associated with these images.
There are multiple levels that various structures can live at. Each level will effect how the structure will relate to the plan.
Note:
Site level structures are predefined templated structures. The user is not allowed to edit any aspect of a Site Level structure. Site level structures may be used for prescriptions as long as they have been designated as a Target.
Course level structures are not predefined templated structures (Site Level Structures). Course level structures may have certain properties edited within the planning user interface (e.g.: their type). A structure may be assigned as a Course level structure by choosing the box “New Course Structure” option at the time of import for any structure that does not automatically match a Site Level Structure. Structures that have been changed to Course level will have be designated as such by the word “course” appearing in parentheses beside the structure name during import. This is useful when a structure was misnamed during the contouring process. Course level structures that have been designated as Target structures can also be used for prescriptions. Any structure with TV as part of its name will automatically be designated as a Course Level structure.
Custom structures show up at the Patient Model level. These are structures that were not part of the templated structures nor assigned as a Course Level structure. The user has the option to edit the properties of a custom structure from within the Patient Model task.
Plan level structures are structures created with the Astroid TPS. These structures are derived from existing structures (e.g.: expansions, combinations). See Patient Geometry on how these are created.
The structures type determines the options available to the user when specifying constraints and objectives for the treatment plan optimization (refer to Optimization Constraints and Optimization Objectives for definitions of Constraints and Objectives). Below explains the structure types and options available for each type during optimization:
For structure types that are not Target or Other the user only has the ability to set constraints and objectives that drive the dose downward.
For structure types that are Targets and Other the user has the ability to set constraints and objectives that drive the dose upward and downward.
Within Astroid the planner has the ability to view the Patient Model details and edit certain structures in a limited capacity.
The Patient or External structure is one of key importance in Astroid. This structure is used to define the extents of the dose calculation process. This includes the extents of the dose grid, as well as useful area of the CT images for the purposes of Relative Stopping Power conversion. Planners should be aware that all area outside of the External contour is considered to have an RSP value of 0.001 (air). As a result please ensure that any devices that need to be considered in the calculation such as: patient immobilization or positioning devices or the couch are contoured as part the external contour if they will be present during treatment and may impact the delivery beams. Please note in the example below how the planner included the head holder, mask, and S-frame as part of the External contour so that all of these devices will be included in the dose calculations. The couch was safely excluded in this example because no “through couch” beams were going to be used in this treatment. This “air” override is applied BEFORE any manual user overrides are applied.
Within Astroid the planner has the ability to create additional structures that may be needed when building a treatment plan. The Astroid Planning App allows for new structure creation using modifications of existing structures only. These modifications include boolean combinations, expansions/contractions, rinds, and clipping (i.e. splitting by a plane).
The following is a detailed explanation of each of the structure geometry functions that may be used to create or edit structures within Astroid.
Allows for the combination of two or more structures using set (boolean) operations. The planner must choose which type of set operation they desire to create the new structure.
Allows for creation of a new structure as an expansion or contraction of an existing structure. The base structure is selected from a simple drop down menu. An expansion is performed by entering a positive number for the expansion amount. Conversely, a contraction is performed by entering a negative number for the expansion amount. Structures may be expranded in two dimensions (structure will only expand/contract within its original slice planes) or three dimensions (structure will expand onto other slices as a true 3D expansion). Please note that the resulting structures are still slice based entities, therefore an expansion by an amount less than a single CT slice thickness may not result in the structure expanding out to additional slices. Refer to this expansion example for a sample of an expansion structure being created.
Allows for creation of a new structure as a thin ring around the surface of an existing structure. The base structure is selected from a simple drop down menu and then both an inner margin and outer margin are specified. Inner margin is the thickness of the ring toward the inside of the existing base structure. Outer margin is the thickness of the ring outside the existing base structure. Negative margins are not permitted, although zero is permitted for either value, allowing for the creation of one-directional rinds. It should also be noted that the resulting rind structures are still slice based entities, therefore rind thicknesses may not be fully uniform at the superior and inferior ends, as contours are limited by the CT slice positions. Refer to this rind example for a sample of a rind structure being created.
Creates a new structure by splitting an existing structure by a user defined plane (and discarding the portion on the positive side of the plane). Any existing structure may be selected for splitting from a simple drop down menu. The split plane is defined by a single point and a normal vector pointing away from the portion of the structure that will be kept. The normal vector is defined by its three direction components XYZ and the point may be selected (or created) from the available point list menu. The XYZ normal vector directions refer to patient coordinates so that X is left-right, Y is ant-post, and Z is inf-sup (note: if the “wrong” side of the structure is removed, simply reverse the direction of the normal vector by changing the sign of each XYZ value). Refer to this clipping example of a clipped structure being created.
This section walks the user through the creation of a of a new planning structure (an expansion structure is used herein for illustration purposes).
Within Astroid the planner has the ability to create additional points that may be needed when building a treatment plan. These points include Isocenter, Point of Interest (POI) and Localization points.
The RSP Image block allows the user to choose (if not chosen during patient import) or change the HU (Hounsfield Unit) to RSP (Relative Stopping Power) curve to use during the planning process. The user may also choose any density overrides for a particular structure at this point. An example of when to choose an override is the case of hip prosthesis. The user will need to know the RSP to be used for the chosen structure.
The order in which density overrides are applied can often be important to users. The Planning App first applies the override outside the “external” structure and then applies any user added overrides in the order added by the user.
Note- Please see patient_geometry as to how RSP outside of the patient external contour is handled
Astroid utilizes a calculation grid that allows for local grid resolution to be specified on a per structure basis. This allows for improved optimizer performance in terms of both speed and resultant plan quality. A uniform sized base calculation grid is created over the entire patient structure. This base resolution can generally be set to a size much larger than the value needed for accurate clinical dose resolution. The user can then reduce the grid sizes in critical areas, generally the high gradient regions and target areas that require homogeneous dose, by assigning appropriate structures a smaller grid spacing value. A common configuration is to use a base resolution of 8mm, 4mm within critical OARs and the PTV/CTV and 2mm in a thin (rind) region surrounding the PTV. This provides sufficient dose information for the optimizer to maintain uniform dose to targets, drive down dose to OARs, and achieve steep dose fall at the boundaries of targets and healthy tissue. An example of constructing such a grid is given below.
Defining treatment beams will be one of the most important tasks within the Astroid planning system. Defining appropriate beams will require users to use their knowledge and experience to properly select many of the parameters that define a treatment beam. These parameters include the target, geometry (isocenter, gantry and couch angles), beamline devices, air gap, and spot placement options. The Beam task utilizes a series of blocks to organize the beam creation process into a common step-by-step sequence. Several blocks are optional as not all beams will use all features. Additionally, it is important to point out that the treatment room & default spot placement parameters are set outside of the individual beam creation tasks as these apply to all beams (however, spot placement parameters can be overridden within each beam if desired). An example of constructing a lateral beam, with the isocenter at the centroid of the PTV is given below to illustrate the features available when defining a beam.
The General block is used to set general beam details including:
For PBS beams the following additional options will be available:
For SOBP beams the following additional options will be available:
In the Approach block specify the desired isocenter from the dropdown. You may choose to use the centroid of the Geometric Target (as shown below) or you can select or create a new point to define the location for the isocenter. The gantry angle and couch angles are also entered here as well. Editing these values can be done by typing directly in the provided fields or by using the sliders. The patient in this example is feet first so we will use 90 for the Gantry angle and 0 for the Couch Angle to create a left lateral beam.
In the snout block a list of snouts associated with the specified treatment room will be available to choose from. Selecting a snout can change what beamline devices are available based on the facility model in the site info.
An option to add an aperture can be found within the Aperture block. An Aperture was not chosen in the PBS beam example. Although selecting an aperture is optional for PBS beam plans, selecting an aperture is required for SOBP beam plans.
The Range Shifter block is only available for PBS treatment modes.
Once the beam line devices are defined, we can move to specify the Air Gap distance. The valid air gap range will be listed based on the selected snout. The user may choose any value in this range. 30mm was chosen in the below example.
The Spot Placement block is only available for PBS treatment modes.
Proton DRRs do not impact the beam and are used purely for visualization purposes so that you can set the DRR Options to levels that generate appropriate anatomy visualizations. An example DRR is shown below. Note that Astroid allows you to define 2 distinct DRRs and then blend them together using a simple weight factor to create a single DRR image on the screen. This gives users the freedom to create high contrast, high quality DRR visualizations. A single image was used in the example below as the second set of DRR options has the weight set to 0.
An aperture can be added for any snout that has slabs defined for use in the site specific machine model. The site model also includes a definition for the aperture milling tool and Astroid enforces the “millability” of all apertures so that dose is only computed using a device that exactly matches what will be manufactured. The user has the ability to utilize apertures for all types of proton delivery including: PBS, DS, and US. The major steps involved in creating an aperture are common to all delivery modes, so the PBS beam example below can be referenced for all cases.
The manual edits contain an “undo” feature, so that the user can successively remove the last manual edit step by pressing Ctrl+Z. Please note that the undo functionality only tracks edits performed in the active session, so as soon as you leave this block or disable manual edits, you will be unable to use the undo functionality on those changes when returning to this task.
Note: Range compensators can only be added to SOBP beams.
A range compensator is automatically added for any snout that has range compensator information defined for use in the site specific machine model. The site model also includes the maximum and minimum possible thickness values, the material, and the extents (outer dimensions) of the range compensators for each snout.
With intensity modulated PBS treatment plans the variety of possible dose distributions is quite large. Typically if a physician does not like a plan they will request it to be re-run. This requires the planner to input new constraints and objectives and a new plan to be run from the beginning of the optimization process. This is a time consuming process. Astroid eliminates this cycle using a Multi-Criteria Optimization (MCO) approach that allows planners and physicians to visualize the trade-offs of target volume coverage vs reduced dose to the OAR's in real time. MCO treatment planning is based on a set of Pareto optimized plans, where a plan is considered Pareto optimal if it satisfies all the constraints and none of the objectives can be improved without worsening at least one of the other objectives. So instead of creating just one plan, Astroid creates a set of optimal plans that satisfies the treatment plan constraints and puts an interactive exploration of the objectives at the planners and physicians fingertips via a unique, highly intuitive, solution navigation slider bar system.
Constraints play an important role in the optimization process, as they bound the solution space and ensure your navigation process is focused only on plans that meet your non-negotiable, highest priority dosimetric needs. It should be noted that if the constraints are too tight, there may be no feasible plans. However, if the constraints are too loose, too many solutions will exist and the navigation will be too broad to provide adequate resolution over the truly clinically useful plans. Therefore care should be taken to ensure appropriate constraints are set, which is facilitated using the Astroid Feasibility check feature. So while constraints supply hard limits, objectives are the negotiable goals, they do not have a hard level that must be obtained, but “pushing” them harder does result in benefit to the patient. The number and type of objectives chosen should be such that all the relevant trade-offs can be demonstrated and explored.
The user is able to select the MCO optimization algorithm from a list defined in the site configuration settings. The default option is the first algorithm in this site level list of pluggable_functions designated with the mco_optimizer key.
As of Planning 2.3.2 the available optimizers are Art3+O and Nymph. Both optimizers use the same constraints and objectives. However Nymph does not use a separate feasibility stage and has it built in to the optimization step.
Defining Fraction Groups is the first step in the PBS Optimization process within Astroid. Most commonly, a fraction group is simply an arrangement of beams that will be used in a typical daily treatment fraction. The Fraction Group contains some basic group information, as well as Fraction Group level constraints and collections of Beam Sets and Constraints for each target of the fraction group. The Beam Set and various Constraint levels are key concepts within Astroid that allow for high levels of control over the Astroid PBS Optimization engine. Further details of these critical items are provided below and additionally, examples of some common cases and how fraction groups, targets, and beam sets can be constructed to meet the clinical needs of various clinical cases can be found in the Prostate Plan Walkthrough.
Single Field Optimized treatments are created using this type option. Simply select SFO from the Type drop down and then add any number of beams and constraints. Each constraint will be equally divided among each beam during optimization. For example, if three beams are included in the Fraction Group and a PTV min constraint of 60 Gy(RBE) is added, then each beam will be individually set to have a constraint of 20 Gy(RBE) (60/3) when running the optimization.
Note: A fraction group with only one beamset and a single beam will always be considered to be an SFO fraction group.
Intensity Modulated Proton Therapy treatments are created using this type option. Simply select IMPT from the Type drop down and then add any number of beams and constraints. These constraints will be applied to the collective (total) dose from all beams in the Fraction Group. Using the same example as the SFO section, if three beams are included and a PTV min constraint of 60 Gy(RBE) is added, then the total dose from the three beams must be above 60 at all points within the PTV, however, no restrictions are placed per beam, so that each beam is free to give any portion of the 60 Gy(RBE) dose. This allows for maximum flexibility in sculpting dose to the target, but generally at the expense of increased sensitivity to motion and patient positioning uncertainty.
Advanced type fraction groups are needed only in rare occasions when beams must be mixed such that a standard IMPT or SFO approach simply doesn't provide the necessary control over the constraints. Since the advanced more UI is significantly more complex, the following section is dedicated to providing a more detailed understanding of the available options. It should be noted that Advanced mode allows for multiple targets and for constraints to be specified at the Fraction Group level and the Beam Set level and it is important to learn these differences in order to make proper use of the advanced options.
Simply speaking, a Fraction Group Target is just a collection of Beam Sets and Constraints that together will provide a specified dose to a particular target. In clinical practice, most standard single lesion treatments will use only one Fraction Group Target. More complex prescriptions, such as Simultaneous Integrated Boosts (SIB), generally contain two Fraction Group Targets, one for the primary target and a second for the boost target. Within the Fraction Group Target, a target structure is specified along with one or more Beam Sets and any beam set level constraints necessary to meet the clinical goals for this target.
The Beam Set is the lowest level unit for the Astroid PBS Optimizer and proper arrangement of the beams within a beam set allows for both Single Field Optimized (SFO) and Intensity Modulated Proton Therapy (IMPT) fields to be included within the same fraction. A careful review of the Beam Set Level (BSL) Constraints described above, should reveal how to properly arrange beams within Beam Sets to achieve a desired type of treatment. Since BSL Constraints are equally split and are then applied individually to each Beam Set, SFUD beams can easily be achieved by placing each beam in its own Beam Set. Conversely, IMPT beams are created when multiple beams are included within a single Beam Set. Further details of these two cases are presented below, as this will provide the information necessary to allow users to construct complex constraint relationships, which is the purpose of the Advance type UI.
Single Field Optimized treatment beams are produced by including each beam in a separate Beam Set. This is best understood by example. Suppose a target is intended to receive 20 Gy (2 Gy per day for 10 fractions) from a two beam Fraction Group using a SFO approach. This is achieved by specifying a min dose of 18 Gy and a max dose of 22 Gy using Beam Set Level Constraints. Now two beam sets are created, each containing a single beam, as shown below. Since the BSL constraints are split between the beam sets, this actually tells the optimizer that each beam must provide a min dose of 9 Gy and a max dose of 11 Gy (1/2 of the BSG constraint doses). Therefore, each individual beam will be providing coverage to the entire target as is expected for a SFO approach.
Intensity Modulated Proton Therapy treatment beams are produced by including all desired beams in a single Beam Set. This is again best understood by example. Suppose a target is intended to receive 20 Gy (2 Gy per day for 10 fractions) from a two beam Fraction Group using an IMPT approach. This is achieved by specifying a min dose of 18 Gy and a max dose of 22 Gy using Beam Set Level Constraints. Now one Beam Set is created, containing both beams, as shown below. Since there is only Beam Set, the BSL constraints will be applied to the combined dose from the two beams. Therefore, there are no guarantees regarding the uniformity of dose from either beam and instead there is simply the guarantee that the combined dose from the two beams meets the given constraints, thereby producing an IMPT treatment approach.
By understanding the notion that Beam Set Level Constraints are equally split among the Beam Sets, it can also be seen how SFUD and IMPT may be mixed within a Target and even the most complex of treatment scenarios can be handled seamlessly in Astroid.
Constraints can be specified at various levels (Plan, Fraction Group, Target/Beam Set) with Astroid and they will affect different groups of beams depending on their level. Constraints at the Plan level are applied to the total dose resulting from all beams. Constraints at the Fraction Group level are applied to the total dose resulting from only the beams in the current Fraction Group. Constraints at the Target/Beam Set level are split evenly and applied individually to each Beam Set. In other words, the Constraint dose is divided by the number of Beam Sets in the Target, and this dose is then applied as a constraint to each Beam Set, so that either SFUD and IMPT can be achieved (see Fraction Groups). The section below will provide a walk through of the different levels and how constraints are applied at each one.
It should be noted that all constraints are considered “hard limits”- values that must be achieved. Constraints drive the feasibility calculation- whether the plan is achievable and should be used to ensure certain minimal clinical parameters are met.
The following constraint types are available. Note certain constraints are available only for Target type structures.
The user can choose to apply one or multiple of these constraints to any number of structures.
Constraints at the Fraction Group level are applied to the total dose resulting from only those beams in the current Fraction Group. Constraints at the Target / Beam Set level are equally split among the Beam Sets within the Target and are applied to the total dose resulting from the beams in each of the Beam Sets. The following steps are a brief walkthrough for creating a max constraint of 79.2 Gy(RBE) to the PTV for the whole Fraction Group, and then creating two SFO beams that each provide a minimum dose of 39.6 Gy(RBE). Note that this configuration with the max constraint at the Fraction Group Level is different than if we had put both the min and max at the Target / Beam Set level. In the case shown, it is only the total dose from the two beams that is constrained to be below 73 Gy(RBE). Had both constraints been placed at the Target Level, then each beam would instead be constrained to a max of 36.5 Gy(RBE).
Constraints at the Plan level are applied to the total dose across all beams.
After the Constraints have been entered, the user may start the Feasibility calculation by clicking calculate in the Feasibility block. The Feasibility calculation is based solely on the constraints and, it should be used to ensure that it is possible to meet the specified constraints. The Feasibility calculation may be an iterative processes in order to get appropriate constraints established for a particular plan. In other words, the user may need to enter one or more constraints, check the feasibility, then progressively tighten the constraints and re-check the feasibility until the plan is no longer feasible, then back-off to the last feasible values. It is recommended practice to start by obtaining a feasible plan utilizing only target Constraints then add OAR Constraints as desired. Remember, using a narrow range of constraints can improve the optimizer performance and improve the resolution of the solution navigation.
The user also needs to be aware of the impact of Constraints being set at the Fraction Group level versus the Plan level. For example, it is possible to have a Constraint set in the Plan level so that the whole dose to an OAR is given on one day and none on the other day. This could happen when there are two Fraction Groups and the OAR dose is not split between the two by using Fraction Group level constraints.
Objectives communicate to the optimizer the goals that are important to strive for in your plan. Objectives are set at the Plan level under Plan Constraints/Objectives and they apply to the total, combined dose from all beams. Objectives are not given any relative importance at this point (i.e. their order within the list is not meaningful). The Objectives drive the solution of the Multi Criteria Optimization (MCO) and for each Objective, a corresponding Navigation Slider will be presented to allow for exploration of trade-offs in the case of competing objectives (for more information about the MCO process and how objective importance/weighting is handled in Astroid refer to this article).
The following objective selections are available in Astroid:
Once all the Objectives have been set, the user is ready to run the MCO solver, which is performed in the Objectives/Optimizer block.
The Objectives, as stated before are the negotiable goals where there may be no hard limit, but there is benefit to improving them. Astroid allows Objectives on both Targets and OAR's. Objectives can be placed on structures to either increase or decrease dose. The Objectives are the sole driving force guiding the MCO and it is important to recall from the discussion above that Astroid will only navigate to plans that are “optimal” in at least one objective (meaning again that this objective cannot be improved without another objective getting worse). Unlike Constraints, Objectives should be added all at once and there is no need to place them in any particular order (order is irrelevant). Additional information about Objectives can be found here. Since the MCO is finding a large set of optimal solutions the optimization can be a lengthy process. The following factors have the largest impact on the optimization run time:
The number of calculation points and number of spots will have a direct impact on the calculation times meaning that increases in these values will also increase the MCO calculation time. The number of objectives does not always increase the overall run time of the calculation however, thanks to the parallelization that be achieved using the Astroid cloud services, though the number of objectives does impact the usable capacity of calculations that can run on the Astroid cloud. The speed and number of running calculations will depend on the availability and load on the Astroid cloud calculation servers. Each objective of the MCO calculation is computed on a separate thread of a calculation server, therefore understanding the usage of these servers can help users make decisions regarding resource usage for a given set of objectives. The Astroid MCO calculations are designed to use servers in CPU increments of 16 and the MCO calculations are posted to calculation servers as follows:
Understanding this pattern is important, as it can be seen that using less than 16 objectives generally will have minimal impact on MCO run-time and no impact on resource usage. Using between 17-32 objectives will use additional resources, but generally not impact run-time, but using >32 objectives will increase the MCO run-time without using additional resources.
Once all the desired Objectives are entered the MCO calculation is started just by clicking the calculate option in the Navigation block. It should be noted that the Feasibility will be re-checked if any of the Constraints have changed since the feasibility was last run. The MCO calculations will run in the cloud and the user can simply leave the Astroid application running and move on to other things while the calculations process. Please note that at this time the Astroid App should be left open in this state to ensure the calculations run to completion, however, users may open additional instances of Astroid and work on other plans while these calculations proceed (no performance issues should be encountered when using multiple instances since the “heavy” calculations are off-loaded to the cloud calculation servers).
During the calculation process the user may check to see the status of the calculations. The example below shows a Feasibility calculation that is 4% complete. As calculations finish the user will notice this number increasing. By clicking on Show Details a detailed list of what calculations have been finished and which are running will be displayed. In the example below the dij's are completed and the Feasibility is currently running. In the detailed view if the user chooses show completed subcalculations they will be able to obtain the identification number of each calculation.
The user has many options for how the dose is displayed in Astroid. The options for controlling the display of the dose are on the right hand side of the display under Dose Options. The Dose Options provide controls over the DVH type (relative or absolute volume), the colors and scaling of the display dose, the type of dose display shown (colorwash, isolines, or isobands), as well as the scope of dose to display (full plan, single fraction group, or individual beam dose).
The planner has the option of viewing the dose for the DVH in relative volume (dose per percentage of the volume) or in absolute volume (dose per cc of the structure) using the Absolute DVH option. The user may also hover over any area of the DVH curve to obtain the dose and percentage of a given structure or click on one or more lines to start tracking the cursor value for the lines.
The planner has the option of viewing the original MCO dose and the currently navigated MCO dose in the DVH graph. By selecting the Show Secondary Doses option under the Dose Options, the DVH graph will display the following doses:
With the Show Secondary Doses option disabled, only the current navigated dose will be displayed within the DVH graph.
As in the DVH the user has multiple options for displaying the dose. The user may change the percentage isodose line and its corresponding Gy they would like displayed. This is done by entering the appropriate numbers in the boxes under Levels. The user may turn on and off specific levels by clicking on the X to the left of the line. The user also can choose to view the dose as either isobands, isolines, color wash or combinations of these. The user may use the sliders to set the opacity for each of these as well. They may choose the line width and whether it is solid, dashed or dotted for isolines.
In the case of a plan with multiple Fraction Groups the user may choose to view the dose:
To pick one of the above the user must choose from the dropdown list under Scope. The Scope automatically defaults to Full Plan.
Note: When in a sliced image display containing dose, slice scrolling positions will be based on the smallest voxel size of the calculation grid. For any sliced image displays that do not show dose, scrolling positions will be based on the CT image slice thicknesses directly.
Isobands are an interpolation of dose from isodose line to isodose line. Isobands take a range of interpolated dose and fills it in with color.
Isolines display either the absolute or relative dose in the form of closed lines of constant dose value (i.e. these are lines that pass through the points of equal dose).
Color Wash shows the raw dose across the given range of values, blending colors according to the dose levels.
The user does have the ability to combine multiple representations. Below shows a combination of Isobands and Isolines.
Once the plan has been calculated the Navigation block will become active. This block contains entries for all the active objectives and under each objective is a slider bar. This slider bar allows the user to adjust the importance of an objective and to see, in real time, how the change will affect the dose to the patient.
The Navigation Sliders should provide an intuitive process for finding the optimal plan, but by gaining a complete understanding of the Navigation Sliders users will be better equipped to quickly reach their plan goals. It should also be noted that sliders for minimize objectives will slide to the left and sliders for maximize objectives will slide to the right. On each slider there are two vertical bars. The thick white bar is the user controlled slider handle and it represents the worst value of an objective that the user wants to allow. Simply stated, the objective will not go past this limit. The thin blue bar denotes the actual current value of the objective. Astroid calculates this value by balancing the solution over the available ranges of each objective. It should now be clear that moving a slider does not directly set an objective, but rather it places limits on the allowable range of an objective. It is this feature that makes navigating the solution space very clear and effective.
The blue and white numbers to the upper right of each slider correlate to the objective value for the current plan and the objective limit based on the slider position, respectively. So in the image above, it can be seen that the top slider has been set such that allowable maximum dose to the CTVbreast_L is 10.46 Gy(RBE), but the current value is 10.33 Gy(RBE). The numbers at the end of each slider bar denote the overall range for the objective value (i.e worst and best possible values). The main slider horizontal bar is also separated into two sections. The thicker, lighter grey horizontal bar is the range or window that the objective is currently limited to stay within (it is limited due to the positioning of all sliders by the user). The user will notice as they drag the slider handle (white bar) on one objective, this light grey area will change on some of the other sliders. This allows the user to know the limits they have to work in and the impacts (trade-offs) that one objective is having on the others. Sliders should be adjusted such that all physician goals are achieved and the best balance of target coverage and normal tissue doses are realized for the unique patient at hand.
All of these adjustments are able to be done without running a new plan as would needed to be done in traditional treatment planning systems. This allows the user to look at many different solutions in a short amount of time.
If the user likes the adjustments that were made to the sliders they may click the Save button in the bottom right hand corner. This will save the objectives at their current position. If the user does not like the adjustments they have made to the sliders, they may hit the Reset button to reset all the objective sliders to their last saved state. The Cancel button will close the Navigation block in its current state.
Defining Fraction Groups is the final step in the SOBP planning process within Astroid. A fraction group is simply an arrangement of beams that will be used in a typical daily treatment fraction. The Fraction Group contains a list of beams where each beam can be weighted and normalized based on the needs of the patient at hand. Beam normalizations allow for minor field independent adjustments of dose and these factors are limited to stay within 0.90 - 1.10. Beam Weights established the relative fluence of each beam within the fraction group and therefore the sum of the beam weights in each fraction group must be 1.0. Further details of defining fraction groups are provided below.
Since the Astroid system captures and stores the user inputs (rather than the results), it is able to maintain an exhaustive history of all edits made to your data with relatively low storage needs. Users are able to benefit from this information through the Plan History feature that is available within each treatment plan. The Plan History is a feature that allows the user to see and explore all the changes and modifications made to a plan. Each modification to a plan will result in a new Revision of the plan (note: in a complex plan there may be hundreds of revisions). If the user is not satisfied with the results of a modification they may go back to any of the previous revisions and restore it to the active instance (note: this will cause another Revision to be created for the reversion). Below is a walk through and more detailed explanation of this feature.
Once a physician has approved a plan it should be Published. Publishing a plan allows the user to lock the plan. This means that once a plan has been Published no changes may be made to that plan. A plan that has been Published will be available to “view only”. The Plan History will show the date and time a plan is Published as well as the user who Published it. A plan may not be changed or archived once it has been Published. If a user needs to make a change to a Published plan they will need to copy the Published plan in order to do so. Once the Published plan is cloned they may proceed to make any changes desired.
The following steps outline how to publish a plan in the Astroid Planning App:
This section contains general information regarding the various displays available in the Astroid Planning Application. During most tasks, there is a top bar that contains a list of available single and composition views. In most instances these include standard two dimensional sliced views: transverse (axial), sagittal, and coronal. Additional common views include: three dimensional view, Beam's Eye View (BEV), and Dose Volume Histogram (DVH) View.
The Beam's Eye View is a projection of the three dimensional beamline and patient structures into a flat plane as viewed from the beam's proton source. Since certain proton machines may not have a single source point, the BEV supports a dual source projection process as described for aperture devices in the following article, but this is equally applicable to all patient and beamline entities. All projection for the BEV are done to the isocenter plane, therefore all distances measured within the application in the BEV are as projected to isocenter.
Plan Templates are a powerful feature of Astroid that can greatly reduce the time spent in creating high quality treatment plans. In a simple sense, a Plan Template is just a starting point that can be used when creating new treatment plans for this or other patients. When a Plan Template is applied during new plan creation (see here for creating a new plan), all user specified plan parameters from the template are copied into the new plan. In essence you are applying the plan to a new set of images and structures, therefore it is important that structure names and other data are consistent in your Patient Models when using Plan Templates.
Plan Templates can be defined globally at the site level for all users at your institution and each user is also free to create their own private list of user level Plan Templates. A Plan Template can be easily created from any existing plan by opening the General/History block. At the bottom of this block the user may then choose either Save as User Plan Template or Save as Site Plan Template. The user then provides name for the Template and fills in any description information as desired.
When saving an existing plan as a template, there are a few rules/tips that should be kept in mind which will help make your templates easier to use in the future:
Plan Templates are applied when creating a new plan:
The Export Block is available in Astroid to allow for saving patient and plan information in DICOM file format. Typically this feature is used once a plan has been completed, the physician has approved the plan, and the plan is ready to be sent to the Record and Verify system for QA and then patient treatment. The process of exporting files and the options available to the user are described below.