An open‐source tool to visualize potential cone collisions while planning SRS cases

Abstract Purpose To create an open‐source visualization program that allows one to find potential cone collisions while planning intracranial stereotactic radiosurgery cases. Methods Measurements of physical components in the treatment room (gantry, cone, table, localization stereotactic radiation surgery frame, etc.) were incorporated into a script in MATLAB (MathWorks, Natick, MA) that produces three‐dimensional visualizations of the components. A localization frame, used during simulation, fully contains the patient. This frame was used to represent a safety zone for collisions. Simple geometric objects are used to approximate the simulated components. The couch is represented as boxes, the gantry head and cone are represented by cylinders, and the patient safety zone can be represented by either a box or ellipsoid. These objects are translated and rotated based upon the beam geometry and the treatment isocenter to mimic treatment. A simple graphical user interface (GUI) was made in MATLAB (compatible with GNU Octave) to allow users to pass the treatment isocenter location, the initial and terminal gantry angles, the couch angle, and the number of angular points to visualize between the initial and terminal gantry angle. Results The GUI provides a fast and simple way to discover collisions in the treatment room before the treatment plan is completed. Twenty patient arcs were used as an end‐to‐end validation of the system. Seventeen of these appeared the same in the software as in the room. Three of the arcs appeared closer in the software than in the room. This is due to the treatment couch having rounded corners, whereas the software visualizes sharp corners. Conclusions This simple GUI can be used to find the best orientation of beams for each patient. By finding collisions before a plan is being simulated in the treatment room, a user can save time due to replanning of cases.


| INTRODUCTION
Stereotactic radiation surgery (SRS) is a high-dose procedure for treating a variety of malignant and nonmalignant diseases. The dosimetric goal for these treatments is to get adequate target coverage while having the dose falloff as sharply as possible outside the target. Linac-based SRS is a common technique for delivering these treatments. Multiple, non-coplanar beam arcs are used with this technique to achieve the sharpest falloff possible. Additionally, stereotactic cones can be used for small and/or spherical targets.
Compared to multileaf collimators (MLCs), cones produce a more predictable beam output and improved beam penumbra. 1 However, the cones are closer to the patient than the rest of the linac, which when combined with the non-coplanar arcs produces potential collisional issues.
A collision with either the patient or treatment couch could result in very serious injuries. This is a possibility that must be checked in person for each arc. Even when checking each arc in person though, there are still two additional issues: the need for replanning a colliding arc and overly conservative arc geometries.
Efficiency in a busy clinic is very important. If this collision problem could be addressed before the patient is on the table or before the plan is being physically simulated in the treatment room, there would be great time savings. There are certain table angles that have a very low probability of causing a collision but using only these table angles can produce nonideal dose falloffs.
An open-source visualization program was developed to help with these issues for intracranial cases. First, this program does not replace in-person collision evaluation, which is a necessity. It is only meant to avoid replanning and overly conservative beam geometries.
The program allows for a visual representation of gantry angles, couch angles and spatial positioning of the gantry, cone, and patient. This program can be used at the time of treatment planning to prescreen a treatment geometry for collisions. This will reduce the probability of replanning and could improve dose falloff for some patients. It is estimated that this visualization ability would help find the optimum beam geometry for at least one third of the cases in our clinic. Additionally, even when employing conservative geometries for problematic target locations, it is estimated that one out of ten cases still needed to be replanned due to a collisional issue. Some solutions have been used for other treatments and have even taken into consideration the computed tomography (CT) of the patient. 2,3 Another way has been to create and solve sets of equations to determine collisions based off input angles and couch position. 4,5 Our solution swiftly models any linac and localizing frame to visualize potential collisions when supplied with beam parameters (e.g., angles, isocenters, etc.). This visual model allows one to see the position of the gantry, cone, and couch throughout the treatment planning phase therefore avoiding workflow issues. Beyond this, instructions are given here for commissioning this software. The program was developed for the MATLAB programming language (Math-Works, Natick, MA), but utilizes code that is fully compatible with GNU Octave to enable easier access. This method is not any faster or more accurate than those presented in literature. [2][3][4][5] The value this work brings is through its focus on an open-source implementation. It takes a significant amount of work to convert mathematical concepts to clinically utilized software. This method was made to be as practical as possible for others to implement.
For this reason, the code is included as a supplementary document and this manuscript focuses on the steps needed to put the software into practice. Beyond this, the implementation was made to be as simple and concise as possible so that others can more readily understand and possibly modify the code. More specifically, the fully self-contained SRS collision code, including comments, is 174 lines long.

2.B | Component visualization
Calculations within the software are performed with Cartesian coordinates. More specifically the IEC 61217 fixed system coordinates are utilized. For a head-first, supine patient, the variable x points in the patient left direction, the variable y points in the superior direction, and the variable z points in the anterior direction (see Fig. 1).
For simplicity, the code relies on the surf function. When given the x, y, and z coordinates for the vertices of a surface mesh, this code will create a three-dimensional rendering of it. Beyond this, the function also enables one to modify color and transparency of these surface meshes. Note, however, at the time of writing this manuscript, transparency was not yet supported by GNU Octave.
Creating the representative objects consisted of three steps.  1. Define unit object values: x unit , y unit , and z unit .

Scale and translate. x scaled
After these transformations of the unit objects, the locations can be directly visualized by passing the x final , y final , z final coordinates to the surf command.
2.C | Isocenter, patient safety zone center, and reference point Calculating the object translations for the couch and safety zone relies on knowing the position of three points in space: the treatment isocenter, the center of the patient safety zone, and a reference point. One of the goals of the software is to display the patient safety zone correctly in relation to the treatment (and machine) isocenter. While the treatment isocenter is readily visible in a treatment planning system, the same is not necessarily true for the center of the safety zone. For this reason, an additional reference point, which is visible on the patient CT image is introduced here.
During commissioning, the relationship between the reference point and the safety zone is established. Then, during treatment planning, knowing the relationship between the reference point and the isocenter allows one to place the safety zone and treatment couch correctly in relationship to the isocenter. Figure 2 shows an illustration of the three points. In this work, a localization box is used for the patient safety zone and the tip of a rod in the mask base, near the right ear, is utilized for the reference point. Note, not all systems utilize a localization box, but the safety zone concept should be adaptable to other treatment systems.

2.D | Commissioning
Commissioning consists of a set of measurements made to determine the scaling factors, translations, and sign notations for the couch and gantry rotations. Figure 3 provides a physical representation of where each measurement came from along with a description and abbreviation in Table 1. The measurements were taken manually but dimensions from machine blueprints may also be beneficial.
These measurements are then manually entered into the MATLAB script. The developed program has no inherent distance units to it.
However, it is critical to be consistent in putting measurements in Beyond the information needed to visualize the collisions, the color of the different elements can also be changed. Red, green, blue (rgb) values can be varied (from 0 to 1) for the safety zone (SZcolor), couch (CHcolor), cone (Ccolor), and gantry head (Hcolor). In this case, these colors were set to red, dark gray, light gray, and dark yellow, respectively. Additionally, the labels presented to the user for the AP, lateral, and sup/inf directions can be changed. For example, in Brainlab, the AP direction is labeled as "Y," the lateral direction as "X," and the sup/inf as "Z." The final step of commissioning is to validate the software and run end-to-end tests (see Section 2.F).

2.E | Software usage
The software is contained fully within one script. If the folder contain-  properly replicated for each isocenter tested.

| RESULTS
The measurements needed to create this collision software were gathered in 20 min and easily added to the code. Once the code was altered with the proper dimensions, the end-to-end validation was shortly followed. The total time spent on commissioning this, including end-to-end validation, was 2 h. Three patients and a total of three isocenters were tested for accuracy between the GUI and the treatment room. Each shift was checked to ensure coincidence with the target coordinates provided by BrainLab. Each treatment arc was visualized in the software and verified in the vault. The arc results were recorded as one of three classifications: (a) the cone will clear, (b) the cone is close enough (<1 cm) to cause concern for collisions for the patient setup, and (c) the cone collides.
Two of the patient plans tested here had collision issues. Tables   2 and 3 show the results for the simulated plans on the software versus the actual in-room result. The other plan was a plan without collisions which was treated successfully at our clinic. The results for this simulated plan are shown in Table 4. These patient cases included a total of 20 arcs. For the in-room assessment, two of these arcs were found to collide. The software correctly identified both of these as collisions. Four of the arcs were found to be close with the in-room assessment. The software also correctly identified all four of these cases. The remaining 14 arcs were found to clear in the room.
In the software, 11 of these were also clear, two appeared to be close, and one appeared to collide.
The GUI was tested for coincidence at multiple isocenters, gantry angles, couch kicks, and collimator angles. Figure 5 demonstrates a collision while Fig. 6 demonstrates a noncollision with the GUI replicated next to it. The software and in-room comparison showed similar results in terms of collisions, close, and complete clears. There were times though when the software appeared closer than the inroom evaluation. This is due to the treatment couch having rounded corners, whereas the software visualizes sharp corners. For this treatment couch, this distance is 2 cm. For arcs passing by these corners, the cone would appear in the software to be 2 cm closer to the table than in the room.

| DISCUSSION
The GUI provides a fast and simple way to discover collisions in the treatment room before the treatment plan is completed. It is simple to use and can be used to find the best orientation of beams for each patient. By finding collisions before a plan is being simulated in the treatment room, the clinic can save time in the treatment room.
This collision software will also provide a better idea of colliding beam geometries to avoid having to make multiple plans.    head. This would also overpredict cone collisions. In the future, this design could include patient outlines for a more exact design but for now, the simplified geometric shapes provide a conservative approximation for the location of the gantry, couch, and patient.
The GUI was found to be very accurate in replicating the room geometry but did predict collisions in cases that would clear in the room. The only case that did not fit this trend was a collision which resulted from the cone-locking mechanism. This locking mechanism included a clip which is not a component on the GUI created. In this particular case, the latch passed closer to the table than 1 cm for one arc. The treatment was not replanned though. The couch and gantry angle remained the same, but the collimator was rotated to avoid a collision between the clip on the cone-locking mechanism and the table.

| CONCLUSION
This simple GUI can be used by the planner, physician or physicist to find the best orientation of beams for each patient. By finding collisions before a plan is being simulated in the treatment room, the clinic can save time due to replanning of cases and avoid overly conservative beam configurations.

CONFLI CT OF INTEREST
No conflict of interest.