Automated contrast painting for position verification in radiotherapy Putora PM*, Plasswilm L*, Paulis L# *Klinik für Radio-Onkologie, Kantonsspital St. Gallen, St. Gallen, CH Institute of Pathophysiology, Comenius University, Bratislava, SVK
#
Abstract The influence of information technology in medicine has been constantly rising and represents a central part in many medical disciplines, especially radio-oncology. For the proper delivery of radiation treatment, the correct position of the patient is essential. To verify the correct position of the patient radiological images are made. In order to compare positions, contours of structures (often bones) may be used, these need to be identified and painted. The software that was provided with the linear accelerator contains a bitmap paint program, where these structures are painted manually. This manual painting of structures could be replaced by automated algorithms. However, amendments, innovations or customization of the original software are costly and difficult to achieve due to copyright, license and certification issues. The concept described here aims to get around these issues by creating an automated algorithm on the user level, with no interference of the underlying original software. This system uses the Java platform; with the help of the Java Robot class user input can be simulated. The developed tool proved to be time-saving, functional and the development could easily be accomplished and individually tailored to users’ needs. Introduction In Radiation Oncology cancer patients are treated with ionizing radiation. A key element of treatment is precision of delivery of radiotherapy. The correct position of the patient is crucial for a correct radiotherapy procedure (1). After the radiotherapy plan has been established from the planning CT scan a digitally reconstructed radiograph (DRR) is generated representing a two dimensional image from a defined angle (also called the beams eye view, which is the angle from which the radiotherapy is delivered) (2). In the following therapeutic sessions, the patient is positioned according to skin markings that have been applied during the CT scan. Once the patient is in position at the linear accelerator. The linear accelerator has an integrated cone beam CT, which is also capable of producing two dimensional radiographic images. To verify the position of the patient the radiographic image, created in the treatment position, is compared to the „expected“ image, which is represented by the DRR. The comparison of these two images is enabled by structures that are identified/marked in the DRR and then placed over the actual image of the patient. Patient positioning may be affected by errors in the treatment change or changes of the patient. The skin markers might change their relative position to irradiated structures if the patient looses weight during therapy for example. First, the patient is positioned with the help of a light system and skin markers. In case an incorrect position is identified using the radiographic structures, the direction and distance can be calculated from the difference between the expected and actual structures. This difference is then applied to the table position. The structures that are relevant for position verification vary from location to location and even from patient to patient. There is however one condition that they must fulfill: they have to be visible in both the DRR and treatment image. In most cases these structures are bones, the main reason being their high contrast to the environment and their stability. Aim
1
Because these bony structures were not recognized automatically, they had to be drawn with a painting tool in the verification software. The aim of our project was to automatize identification of these structures. The goal was to produce a tool that would identify and draw bone structures in the image, the main benefit being less time needed to paint the structures manually. The method, which the structures are painted with, resembles all common pc bitmap painting programs. It was necessary to find a solution that would not change the original software which was part of the software package of the linear accelerator. Methods The Linear Accelerators used in our department are from Elekta, Synergy series with integrated Cone-Beam CT. The software included in the Package was IVIEW. The DRRs were exported from the Eclipse planning system. The IDE used to write the code was Eclipse Platform Version: 3.4.1, Ganymede, Eclipse Foundation and the programming language was JAVA from Sun Microsystems (3).
The first step was to identify the proper software solution for such an implementation. We decided to use the JAVA programming language with the JVM readily available on all hospital personal computers. Because we could not change the original software, we could only move on a user level within the program.
The first step of the desired process was to acquire an image that was to be analyzed. The Robot class provides a printscreen method with which a rectangular portion of the displayed screen can be captured in a BufferedImage. The identification of the appropriate was rather simple, because the displayed image always had the same x and y coordinates and a constant window size. We added a small function with which the Region Of Interest (ROI) could be displayed by a automated mouse movement and changed within the Graphic User Interface (GUI) of our tool. After acquiring the BufferedImage from the Region of Interest, the software would provide several methods that could be run over the BufferedImage. The main principle being reducing the black and white images to a matrix of pixels containing the number “1” where the contrast in comparison to surrounding pixels was relatively high and a “0”, where it was low. By this the resulting matrix represented the regions of high contrast, which were primarily bone borders. After the above mentioned processes the matrix contains a representation of the pixels of the ROI, where the contrast rich points are represented by the number “1”. With the Java Robot Class the mouse was sent to each pixel of the ROI where the corresponding value in the contrast matrix contained a “1”. At this position the Robot class caused an event: a left mouse click. This automated left mouse click on the user level caused the underlying software to draw a point of a contrast structure. By cycling through all points of the ROI structures of high contrast were painted automatically. When the new tool was applied, several adjustments (calibration of parameter combinations) were required to obtain useful images. The graphic user interface provides the possibility of identifying structures by contrast or in certain situations by grayscale value. In Addition the field borders are included in the DRRs in yellow color, these can be highlighted too. Though for standard use the parameters are pre-set, the GUI provides an option for manual setup. To further increase the speed, one can adjust the pause frequency and duration as well as skip a certain amount of pixels. Results As expected our simple algorithm would not provide as elegant structures as a human would. The proposed structures would in most cases provide sufficient information for a precise positioning. Due to the rigid algorithm, the tool recognized and painted structures where the human would have not even suspected relevant contrast differences. These irrelevant structures did not hinder correct position identification. An unexpected problem arose due to the speed at which the tool painted the pixels, this actually caused the underlying software to crash during several test runs. The exact cause could not be identified. For this reason a small delay between a specified number of points was introduced. To reduce the total amount of drawing done by the tool a variable number of points could be skipped. For example the tool
2
could be set to draw every fourth point. For the human eye this did not cause a significant reduction of structure quality. The software merely provided a proposal of structures that could be used. In case the structures were not helpful, they would have to be drawn by a human. The program would not run by itself but had to be started by a real user, after a desired image was opened in the original software. The lower images show a DRR of a pelvis. The application is run and contours structures where the contrast is relatively high. Due to the character of the imported images the yellow field markings and the red planned target volume are recognized too. This does not present a problem in position recognition. Discussion Radiation therapy represents one of the main modalities implied in the treatment of neoplasias of different cellular type and origin. However, it is also associated with radiation damage to the surrounding tissue. Therefore there is a continuous search for solutions aimed to enhance the effectiveness and to reduce the radiotoxicity of radiation therapy (4). Proper and exact positioning of the patient is a crucial condition for allowing sufficient dosage to the target area, whereby limiting the exposure of vulnerable tissues (5). However, there are many technical difficulties which make correct positioning difficult. Some of the current algorithms base the position of the patient on the localization of bone structures. In some cases the identification of these structures might be very time-consuming. Here we present a tool, which should help the physician recognize relevant structures automatically, while she/he still has the opportunity to set the markings manually. The tool is based on the Java platform and simulation of user input with the help of the Java Robot (1) class. This solution enabled us to overcome the problems and costs associated with license agreements concerning the original software supplied with the linear accelerator and to develop a highly specific, individualized and customized tool. Moreover, this routine is open and easy accessible for further extensions and debugging. In our first experiences with this application, we have removed several bugs to achieve the desired stability by ensuring sufficient resolution of pictures supplied by the software. However, because this software was tested only on a limited number of cases, it still requires further debugging, assessment and customization. On the other hand, the use of the presented tool does not apply any transfer of responsibility from the physician to the software. After the contours have been recognized and suggested by the JAVA application, the physician still needs to verify the recognition of the proposed structures and can alter them manually. No irradiation is initiated till the position is confirmed by the responsible operator, who needs to input data on the user level. Furthermore the irradiation is initiated from a separate personal computer. Thus, development, customization, debugging and the trial use of the proposed solution does not expose the patient to an increased risk of improper irradiation compared to the standard procedure. On small trial in our clinic, the time needed per image when using the tool was in the range of seconds while on average several minutes was required for manual recognition. However, there were specific situations where very simple borders of structures were sufficient enough for accurate matching. In these situations the tool did not offer any advantage and simply drawing the contour would be even faster. More data is required to consequently evaluate the impact of this tool on the workflow of the department and its reliability. Later, the algorithm could be applied automatically to the verification software files. Until then, the input at the user level seems to be an acceptable, though not ideal, solution. Despite the advantages of the presented solution, its acceptance by the personnel might still be in question. The introduction of such a tool is time-sparing but still requires effort and time to implement properly. At our institution, there are two workstations where the verification software is manipulated by several radiation therapists and physicians. In order to achieve a smooth and regular use of the tool, education and training of all employees is required. We conclude that we have developed an automated algorithm for bone structure recognition aimed to save time in the process of position verification before radiotherapy. Our solution works on the user level with no interference of the underlying original software, thus overcoming associated license and copyright issues. In our early trials, the tool proved to be time-saving, functional and the development could easily be accomplished and individually tailored to users’ needs. It is possible to implement individual customized IT solutions with basic knowledge of informatics, data handling and simple programming capabilities.
3
More tests and trials are still required to asses the reliability and time saving provided by the current tool. However, it is clear, that the presented approach using small JAVA programs working on user level will prove very useful in different areas of medical informatics. Bibliography 1. Bakai A, Paulsen F, Plasswilm L, Bamberg M, NĂźsslin F. Positioning accuracy in conformational prostatic irradiation using portal imaging. Strahlenther Onkol 178:84-90, 2002. 2. Senan S, De Ruysscher D, Giraud P, Mirimanoff R, Budach V (Radiotherapy Group of European Organization for Research and Treatment of Cancer). Literature-based recommendations for treatment planning and execution in high-dose radiotherapy for lung cancer. Radiother Oncol 71:139-146, 2004. 3. SUN. [Online] Sun Microsystems, Inc. [Accessed 1. 06 2009.] http://java.sun.com/j2se/1.4.2/docs/api/java/awt/Robot.html 4. Meeks SL, TomĂŠ WA, Willoughby TR, Kupelian PA, Wagner TH, Buatti JM, Bova FJ. Optically guided patient positioning techniques. Semin Radiat Oncol 15:192-201, 2005. 5. Van den Berge DL, Ridder MD, Storme GA. Imaging in radiotherapy. Eur J Radiol 36:41-48, 2000.
4