1. Introduction
Modern radiation oncology relies on advanced computer technology in every step of the treatment process including simulation, contouring, planning, and delivery. Treatment delivery with a linear accelerator (LINAC) in a clinical setting involves multiple interconnected computers working in parallel or serially. To prevent treatment misadministration, a robust quality management program needs to be established to detect any potential treatment errors [1] [2].
Most radiotherapy clinics use products from multiple vendors to meet their specific needs that are difficult to fulfill from a single provider. Even if the single-vendor solution is available, there is a concern that the vendor may mask potential flaws from system design and production. Although these multi-vendor systems are designed to ensure treatment accuracy and safety for both patients and therapy staff, navigating the complex communication between different software/hardware interfaces and multiple control computers exposes the process to potential procedural errors. Furthermore, the repetitive nature of radiation delivery and measurement can lead to operator fatigue that might jeopardize the quality of the quality assurance (QA) [3]. Therefore, system integration and workflow automation are crucial to a modern radiation oncology department.
In a previous publication from our group [4], we defined six automation levels for medical physics workflow, which is analogous to the car industry’s autonomous driving levels [5]. Those automation levels are defined based on the accessibility of operating systems of clinical workstations under stringent institution and/or FDA safety and security policies. The definition includes six automation levels ranging from L0 (no automation) to L5 (complete automation), where each level corresponds to the extent of automation replacing human involvement. This classification system facilitates informed decision-making and future development efforts in automating medical physics workflows.
In the previous study, we developed the AutoFrame platform for automating patient-specific quality assurance (PSQA) at our institution, which uses multiple workstations from different vendors. Specifically tailored for medical physics practice, the AutoFrame interface mimics the operations of human interactive devices (HIDs) like mouse, keyboard, and other external devices to control the graphical user interface (GUI) of diverse software packages, and coordinate the clinical operations performed on different stations over the network. At the L3 level, the mouse/keyboard commands are sent through general USB ports to overcome security obstacles from the operating system (OS) of the vendor computers. The AutoFrame interface enabled robust and flexible automation capabilities, which allows for variations in software access to be managed safely and appropriately.
However, obstacles are still present in the workflow, which prevent higher-level automation. For example, linear accelerator hardware like the Varian control console (VCC) is controlled by a combination of physical button-pushing and software input through the GUI. Although the GUI tasks can be automated with the previously developed AutoFrame interface, the physical button-pushing cannot. Therefore, L3 is the highest level of automation that could previously be achieved without the introduction of new tools with physical capabilities.
Recognizing this software limitation, we adopted a 6-axis robotic arm in this study for mechanical automation [6] [7] and upgraded the AutoFrame interface to access the robot control software through the network. The goal is to achieve L4 automation for our PSQA procedure by integrating this 6-axis robotic arm into our workflow, and automatically controlling the VCC, without any human operator inputs.
2. Methods
2.1. Overall Architecture
The study aims to achieve L4 Automation by integrating additional hardware and software into the AutoFrame workflow. Figure 1 illustrates the IMRT QA process workflow at the authors’ institution. In Figure 1, L2 and L3 automations (Purple and green boxes numbered 1, 2, 3, 4) were already implemented and published earlier [4], and L4 automation (Window labeled ‘BotFlow’, and ‘6-axis robotic arm’) is the focus of this study. As shown inside the blue box of Figure 1, a 6-axis robotic arm was employed to externally control the VCC while interfacing with other AutoFrame modules (AutoFlow, PyFlow, and BotFlow) for completing linear accelerator operations.
Figure 1. Workflow of the IMRT QA process at the authors’ institution from the perspective of AutoFrame’s modules. The items inside the blue box are those needed to be automated to achieve L4 automation.
2.2. Patient Specific QA Program and Automation Levels
Our PSQA procedure was meticulously designed to ensure reliable delivery and accurate verification of IMRT plans [2] [8]-[12]. Steps include (1) creating a verification plan in Varian Eclipse, (2) positioning the PTW Octavius detector array, (3) loading the PSQA plan in Varian Aria, (4) treatment setup in the Varian workstation, (5) manual beam delivery, (6) data collection on the PTW Octavius workstation, and (7) gamma index analysis.
Steps (1), (3), (6), and (7) belong to the L3 automation accomplished previously. In the previous study we also defined six levels of automation for our PSQA procedures, the details of which can be found in Table 1. We would like to point out that distinct levels of automation are defined based on the automation of three types of devices involved in the PSQA process:
1) Departmental computers: These are workstations running treatment planning systems or R&V applications.
2) Vendor computers: These are computers associated with the Varian LINAC.
3) Computer-controlled devices: These are equipment provided by controlled vendors’ computers like the ionization detector array/phantom and the LINAC VCC.
Note that each of the above three types of devices has its own security and safety policies that must be followed, so different approaches are needed when automating each type of device.
Table 1. A table that delineates the involvement of automation required to reach each ‘level’. Current standard practice operates at L1 with software developed to analyze results for the operator.
Automation Level |
L0 |
L1 |
L2 |
L3 |
L4 |
L5 |
Requirements |
No computer aided operations |
Human operations with computer assistance |
Automated operation of vendor computers that allow unrestricted access to OS |
Automated operation of vendor computers that do not allow unrestricted access to OS |
All operations excluding in-room detector/phantom setup |
Fully automated PSQA |
Clinical implications |
Point dose measurements for verification |
Computer aided measurements using PSQA devices with significant human involvement. Current practice |
Manual operations on working computers are automated, e.g., plan preparation and export in the treatment planning system |
Manual operations on the VARIAN computer controlling the LINAC are automated |
Manual operations on the Varian control console (e.g., treatment preparation, beam on/off…) are automated. |
In-room phantom setups are automated. |
2.3. Challenges of Achieving L4 Automation
In this study we focus on the automation of Steps (4) and (5) of our PSQA procedure, among which “Step (5) manual beam delivery” is the most challenging to automate. As shown in Figure 1, the VCC controls the LINAC beam delivery, but it does not have any universal input/output ports for users. Instead, all operations require the user to push certain buttons. Therefore, the ability to control the VCC externally without human intervention is crucial to achieve L4 automation. Attempting to crack the internal processes of the Varian computers was not an option as it would void vendor warranties, as well as FDA clearance for those treatment units. As a result, we chose to use a robotic arm that can mimic human operations of the VCC.
2.4. Robotic Arm
The 6-axis robotic arm utilized in this study is a highly adaptable automation tool as shown in Figure 2 [13]. The arm is controlled by a single board computer (SBC) with a powerful Quad-core ARM A57 processor and a 128-core NVIDIA Maxwell AI computing unit and has extension ports for host computers. The arm is made of anodized aluminum and consists of five 15-kg servos and an additional 6-kg servo, which provides precision control. It offers six degree-of-freedom motion and is equipped with a gripper capable of handling objects up to 200 gm straight or 500 gm clamped. This robot can extend its arm up to a radius of 30 cm with an excellent repeatability of ±0.5 mm.
With six servos enabling rotation on six axes, the arm of this robot can reach and press each button on the console effectively. The two appendages of the gripper can be programmed to press both of the “motion enable” buttons at the same time to allow the gantry to rotate. Preliminary testing was conducted to verify its accuracy, precision, and strength. Initial accuracy testing involved manually adjusting the arm to touch a dot on a piece of paper, recording servo positions, and commanding the arm to return to these positions to assess reproducibility. This testing utilized direct kinematics for evaluation.
Figure 2. The 6-axis robotic arm, as well as the raspberry Pi single board computer (SBC), and the V-Slot rail that is used to construct the frame.
2.5. Custom Fit Metal Frame
A custom metal frame made of V-slot linear rails was constructed to secure the robotic arm onto the VCC in an adjustable manner and ensure consistent and reproducible conditions for arm operations. As illustrated in Figure 3, the U-shaped design of the V-slot was clamped to the VCC securely during PSQA to minimize arm shifting. V-slot rails facilitated frame width adjustment by sliding against the console’s side. The rigid attachment of the arm to the VCC established a reference coordinate system for motion indexing. All motion trajectories were calculated relative to this coordinate system’s origin.
2.6. AutoFrame Interface and Design with Robot Control
AutoFrame served as the workflow controller by interpreting plain text scripts to execute functions that replace human operations. In L3 automation, automation was achieved by controlling HIDs of various workstations. In this study, human operations at VCC were replaced by the robotic arm to achieve L4 automation. To accomplish this goal, AutoFrame was extended to three interfaces: AutoFlow, PyFlow, and BotFlow, tailored for specific workstation types. AutoFlow runs on Windows operating system of departmental workstations and uses AutoIt V3 scripting to directly control computer’s GUI applications. PyFlow is coded with Python and operates in a non-Windows environment. It connects to the VCC (vendor) workstation via USB ports and simulates operator’s mouse/keyboard inputs. BotFlow oversees devices that lack support for external connections, like the VCC which requires physical button pressing. Each AutoFrame interface is comprised of a GUI, UDF scripts interpreter, and TCP/IP communication modules, facilitating real-time communication between running interfaces on different computers.
![]()
Figure 3. The custom-fit metal frame is made of V-slot linear rails for securing the robotic arm on the VCC in an adjustable fashion. The base of the arm was fastened directly onto the frame using v-slot nuts which allowed its position on the rails to be adjusted.
The robotic arm was managed via BotFlow interface on a Raspberry Pi with an expansion board (Figure 3). This setup enabled the Raspberry Pi to control the arm’s servos by converting command signals to voltage for servo rotation. Operating on Linux, the Raspberry Pi utilizes a custom Python library ‘armlib’ to write scripts for various arm actions. BotFlow’s user interface lists VCC task functions like “Motion Enable,” “Prepare,” and “Beam on” in dropdown menus, with motion trajectories stored in plain scripts. BotFlow interprets these scripts to execute motion commands, coordinating actions with other AutoFrame subsystems through TCP/IP communication. Integration of BotFlow and the robotic system within our AutoFrame framework allowed seamless execution in L4 automation of PSQA.
2.7. Implementation of PSQA Procedure with the New AutoFrame Design
As shown in Figure 1, L4 automated PSQA involves four computers, two Raspberry Pis (for BotFlow and PyFlow), one vendor workstation at VCC, and one single board computer attached to the robotic arm. These computers are interconnected through the institutional network and integrated within the AutoFrame interface framework.
During the QA plan delivery measurement, the user sets up the phantom and detectors inside the treatment room, after which AutoFrame takes over and manages device operations without human interventions. First, AutoFlow initiates Mosaiq operations. This is followed by PyFlow which coordinates actions on the Varian treatment computer to import plan parameters. BotFlow then performs a sequence of mechanical actions on the VCC beginning with pressing the motion enable twin button until the gantry has reached its ready position, followed by pressing the prepare button and waiting until the machine is ready. After receiving the beam-on command, the robot presses the MV ready button. During these button-pushing operations, PyFlow clears out the Varian GUI warnings if present. Before pressing the beam-on button, BotFlow also informs Autoflow in workstation 4 (PTW Verisoft computer) to start the measurements and record the results. At the completion of beam delivery, Autoflow in workstation 4 performs measurements and gamma analysis, and saves the reports to a designated network directory.
2.8. Testing of Pushing Individual Buttons
Our testing consisted of four consecutive button presses that would demonstrate the arm’s ability to press any button on the console. By pressing ‘Motion Enable’, it would prove capable of pressing both buttons simultaneously by opening its claw to a specified width. The ‘Motion Enable’ buttons needed to be held until all machine motion is complete. By pressing the ‘Prepare’ button, it would demonstrate the ability to reach to the far corner of the console and still be within range to press the button with enough leverage. The ‘MV Ready’ button had to be held for up to 4 seconds at a different range, so it was critical that the arm could generate enough consistent torque to hold this button. Finally, the ‘Beam on’ button was pressed to make sure it was not too proximal to the base of the arm for it to reach.
2.9. Testing of IMRT QA
L4 automation of IMRT QA was assessed using five PSQA plans. Each of the tested PSQA plans required 4 - 10 button actions on the VCC per plan, including the Motion Enable, Preview, Prepare, MV ready, and Beam ON buttons. Any failure in timing or button inaccuracy would result in the need for human intervention, therefore failing the test. Another aspect of this test was to show that the L4 automation system could time the button activations correctly in accordance with what is needed with the plan.
2.10. Testing of Time Difference between QA Technician and L4 System
The difference in time between manual and automated IMRTQA deliveries was also measured. In this test, twenty test plans were selected and delivered using both manual operation and L4 automation. For the manual operation, an independent observer was tasked with using a stopwatch to keep track of how long it took for the QA technician to operate the console and initiate the beam with the ‘Beam ON’ button. Any mistakes or misinputs were included in the data as this is a natural part of human operation. The same test was repeated for L4 automation. The purpose of this test was to characterize the effectiveness and qualities this automation system would bring to our PSQA program.
3. Results
For the preliminary test of the robotic arm, the robot was able to press all those buttons on VCC automatically and accurately without any human intervention for all cases. Figure 4 shows pictures for two of the four tested button actions by the robotic arm: (a) the “prepare” button, and (b) the “Beam on” button. The construction of the frame and how it clamps onto the VCC are also clearly demonstrated in those two figures.
In all tests of the five IMRT QA plans, the robot successfully communicated with the AutoFlow interface and received/executed commands for operating the VCC. A video that demonstrates the robot pressing “Motion enable”, “Preview”, “Prepare”, “MV ready”, and “Beam on” buttons can also be accessed through this link [14]. Regarding the operation time, the time for delivering a plan was 55 ± 5.7 (mean ± one standard deviation) seconds for manual operations, while the robotic arm took 62.5 ± 1.3 seconds to complete the same task. The L4 automation system took on average 7 seconds longer than the manual operation to complete the task. On the other hand, the performance L4 automation system was more consistent than the manual operation because it has a significantly lower (1.3 s vs. 5.7 s) standard deviation.
(a) (b)
Figure 4. Photos showing the arm pressing (a) the “prepare” button, and (b) the “Beam on” button. You can also see the construction of the frame and how it clamps onto the VCC.
4. Discussion
In this paper we report the progress of the second phase of our automation project aiming for the L4 automation of our clinical PSQA workflow. Based on the previously developed AutoFrame platform for L3 automation that automates the HID operations, we incorporated in this study a 6-axis robotic arm to externally control the Varian control console (VCC). The AutoFrame interface was also upgraded to include the remote-control function of the robot. The results showed that the 6-axis arm was able to push each button consistently with enough force and accuracy and complete the beam-on sequence. All tested beams were successfully delivered without interruption, and all data were successfully collected by the detector for PSQA analysis.
The viability of the arm chosen for this project was confirmed through physical testing at the console. The main considerations when choosing the robot were 1) if the robot can accurately move to the designated positions, and 2) if the robot has enough torque to push each button for a long enough time for beam delivery. According to the specifications, each servo of the robot is accurate to 1 degree, so it was assumed that there is about a ±1 degree of uncertainty in each servo’s rotation. The length of each arm segment is approximately 90 mm, and three main segments are needed to function as an ‘elbow’ to bring the claw down toward the console. Using basic trigonometry, we were able to perform preliminary error calculations and estimated the uncertainty at each segment’s distal end to be about 1.5 mm. Assuming the errors are independent, the combined uncertainty is the mean square error of those three arm segments, which is ~2.6 mm. Given the size of VCC buttons are on the order of a few centimeters, we concluded that an uncertainty of about 3 mm is acceptable, and the test results confirmed our hypothesis that this uncertainty did not impact the robot performance.
Safety is a concern when testing L4 automation since the beam is turned on by a robot instead of a trained individual. This is not an issue because like L3 automation developed earlier, the presence of a QA tech is mandatory when using the automation tools for PSQA. With this policy, the user will intervene immediately when something goes wrong with the automation procedure and prevent any unexpected incident.
Although 7 s (or 15%) longer is a significant increase in time for operating the console, this time difference might be negligible considering that the total time for running a QA plan is ~10 minutes. This difference is due to the limited motor speed, which is slower than the human arm. From this data, it can be concluded that while the L4 system is not faster than manual operation, it is measurably more consistent in its procedure than manual operation. This consistency is an asset, contributing to the overall efficiency of our PSQA workflow and reducing the likelihood of errors.
Moreover, the implementation of L4 automation has facilitated the smoothing of our PSQA workflow and enabled parallel operations. By automating operations involving HID and mechanical buttons pressing, we have alleviated the stress and cognitive load associated with previous manual tasks, affording technicians the opportunity to direct their focus towards other critical aspects of PSQA, such as unexpected safety events. Additionally, the ability to perform parallel operations could potentially improve overall workflow efficiency. Tasks such as importing patient information while generating QA reports of previous patients or preparing dose planes for gamma analysis while setting up beam delivery can now be performed simultaneously, further enhancing efficiency and productivity.
With human interventions minimized from the clinical workflow, AutoFrame serves as the backbone of our automation infrastructure, endowing our workflow with a remarkable degree of flexibility and adaptability. By modularizing and standardizing each step of the clinical workflow, AutoFrame could enable rapid adaptation to operational or personnel changes, and reduce risks associated with, for example, the new software or new QA tech in the PSQA procedure. Through the implementation of AutoFrame, we aimed to not only enhance the efficiency of clinical workflows but also ensure consistency and reliability across disparate systems. By reducing manual intervention and synchronizing operations across different workstations and machines, AutoFrame serves as a catalyst for advancing the quality and safety of radiation oncology practices.
In this study we proved the principle that L4 automation can be achieved for PSQA procedures and potentially more clinical applications in the future. However, unlike the L3 automation that has been routinely used by our QA techs for PSQA procedures, we do not expect the developed L4 automation procedure will be widely used soon by our QA techs. This is because all automation tools for the L3 automation are software and are already installed on various workstations. For the L4 automation, the 6-axis robot needs to be installed on the VCC and calibrated each time before use. The additional time spent on the robot installation and calibration might offset any gains from the L4 automation of the procedure. Therefore, a better integration of the robotic system with the clinical equipment needs to be developed in the next phase of our automation project.
5. Conclusion
In conclusion, we have further developed our AutoFrame platform and demonstrated that L4 automation of PSQA procedures can be achieved with a 6-degree robotic arm. Future work will focus on improving the system integration of the robotic arm with the clinical equipment and extending its operations to other QA tasks.