A web-based remote radiation treatment planning system using the remote desktop function of a computer operating system: a preliminary report

Introduction

The need for radiation therapy has been increasing rapidly in Japan as a consequence of the ageing population. In 2005, 190,000 patients received radiation therapy. ¹ However, the number of board-certified radiation oncologists in Japan – only 542 in 2007 – is much lower than the numbers in other countries such as the USA. ² Most of the board-certified radiation oncologists in Japan work at urban institutions, and as a result, the number of radiation oncologists in rural hospitals in Japan is inadequate. Thus most of the radiation oncologists in rural hospitals must work alone. Furthermore, some rural radiation oncology facilities have no regular attendant radiation oncologist.

The purpose of the present study was to construct a web-based remote radiation treatment planning (RTP) system which would allow staff at a rural centre to obtain help and support from a cancer centre or university hospital.

Methods

Network security for the RTP system (Figure 1) was based on a firewall (FortiGate-60A, Fortinet Inc., California, USA) and a virtual private network (VPN). The treatment planning server (Eclipse, Varian Medical Systems, California, USA) was set up at the Kushiro Municipal General Hospital initially and subsequently moved to the Hokkaido Cancer Center. The treatment planning application ran under the Windows XP Professional operating system, and we could remotely operate the computer using the Windows Remote Desktop function. Client computers (a PC with Windows XP Professional or a Macintosh computer with Mac OS) were installed at the home of one of the authors, to investigate the possibility of consultation for treatment planning, as well as in a university hospital.

OPEN IN VIEWER

Figure 1

Network architecture of the remote RTP system. One of RTP systems and one of the PCs were directly connected through the Internet. VPN routers were installed at the ends of the Internet connection for system security

The affiliated hospital, central cancer centre and university hospital used high-speed broadband Internet connections, and the client computer in the home was connected to a medium-speed ADSL (Asymmetric Digital Subscriber Line) service. Global IP addresses were acquired for all connections. Through the Internet, we remotely operated the Eclipse server to make a new treatment plan or to modify a plan already made.

Modified datasets for five patients (not including personal information) at an affiliated hospital were used for the study. No raw CT images or patient profile data were transferred between the server and client computers using the Remote Desktop function (the only data transferred between computers were key and mouse manipulations of the client and graphics on the monitor of the server). Ethics permission was not required.

We evaluated the accessibility and connection between facilities through the Internet, average throughput using an Internet connection speed test site (http://www.speedtest.jp), the subjective operating speed of the system (Eclipse and Remote Desktop function) using a scale we developed (Table 1), and the initial cost and running cost of the entire system. We determined the scale for assessing the operating speed by discussion among three of the authors based on their actual operation of the system.

Results

Discussion

Telemedicine in radiation oncology started in the mid 1990s. Initially, the main aim was to establish case conference systems in radiation therapy. Teslow et al. ³ reported that teleradiology case conferences were useful for radiation treatment planning, and Smith et al. ⁴ developed a network for radiotherapy image distribution. In 1998 Stitt ⁵ described a system for providing regional oncology services in Wisconsin. Their system allowed data transfer for radiation therapy treatment planning and quality assurance. In 2000 Olsen et al. ⁶ reported the requirements for remote RTP systems and proposed a classification for the systems. A ‘Level 3’ system according to their classification included the concept of real-time radiation treatment planning. This was the start of the second stage of telemedicine in radiation treatment planning.

There have been only a few reports about real-time remote RTP. Palta et al. ⁷ reported the RCET system consisting of two client RTP systems and a server computer. The two RTP systems were connected through the server to access the data for radiation treatment planning. Palta et al. emphasized the need for quality assurance and peer review and suggested that remote RTP would be useful for an affiliate hospital with insufficient staff. Ntasis et al. ⁸ developed an original remote RTP system, GALENOS, that consisted of two client RTP systems and a server computer similar to the RCET reported by Palta et al. GALENOS used ISDN lines and due to the rather large size of communicated data (5–25 MByte depending on the number of tomographic images), the transfer of datasets had to be performed before treatment planning by a special data-exchange application. Norum et al. ⁹ constructed a Helax-TMS system for remote RTP. Their system was simple and consisted of two identical RTP systems linked directly through the Internet which allowed real-time RTP. The RTP systems were set up at a central institution and an affiliated hospital, and the RTP system of the centre institution needed dosimetric data from all affiliated hospitals to perform remote RTP. Ogawa et al. ¹⁰ constructed a system for remote RTP with a remote disk-mount technique. Their system configuration resembled that of Helax-TMS, using two RTP systems, but it had a unique feature. The hard disk drive of the RTP system at an affiliated hospital was connected through the Internet and remotely mounted to the system of the central hospital, so that there was no need for synchronization of dosimetric data between the hospitals.

Our system is very simple compared to those described above. The minimum hardware required is one RTP system, one client PC and two VPN routers. Similar systems were reported by Baba et al. ¹¹ and by Kum. ¹² Based on previous reports and the present study, we categorized three system configurations of remote RTP (Figure 2). The Type A system consists of a server and two client RTP systems (e.g. RCET ⁷ and GALENOS ⁸ ). The Type B system consists of two RTP systems (e.g. Helax-TMS ⁹ and the remote disk-mount technique ¹⁰ ). The Type C system consists of an RTP system and a client PC (Remote Desktop Connection in the present study). The cost of a Type A system is the highest and that of a Type C system is the lowest. Doolittle et al. ¹³ analyzed costs for telemedicine in oncology consultation and reported that the average costs per consultation in 1995 and 2000 were $812 and $410, respectively. These costs included technical (e.g. equipment, line charges) and practice (e.g. physician contract, staff salaries) expenses. Wysocki et al. ¹⁴ reported that the high cost of tele-oncology would drop with frequent use of the equipment. Using a simple network with Windows built-in functions, the initial cost and running cost of our system are low, and the use of our system would therefore contribute to the spread of remote RTP. In addition, Type A and Type B systems, using two RTP systems, require synchronization of dosimetric data between hospitals. Our system, Type C, is a true virtual simulation of RTP and there is no need for synchronization. Using a PC as a client is convenient and enables easy access to the system by a user located anywhere in the world.

OPEN IN VIEWER

Figure 2

Three types of remote RTP systems: (A) two client RTP systems connected through a server, (B) two RTP systems connected directly and (C) an RTP system and a client PC connected directly

The subjective operating speed of our system was satisfactory. We could operate the system with only a slight delay (‘delay’ meaning a reduction of operating speed) in almost all experiments. We did not try a basic connection such as ISDN, by which the average throughput rate was reported by Ntasis to be 60.583 kbit/s.⁸ This is a low throughput rate compared to those of ADSL and broadband in the present study. In viewing the motion picture of a lung (10 frames per respiration), there was a moderate delay due to the throughput of the ADSL. This might be affected by data traffic conditions on the Internet. We consider ADSL or broadband to be satisfactory for real-time remote RTP.

Legal aspects of electronic patient data and network security are important and should not be neglected. ^15,16 The only data transferred between computers in our system are key and mouse manipulations of the client, and graphics on the monitor of the server. A VPN connection, using cryptographic tunneling protocols to provide the confidentiality and sender authentication, has good security against access from an outside network. We consider the security level of our system to be sufficient for protecting information on patients. However a VPN, even with a firewall, is relatively weak for illegal access inside the local network (LAN). If someone inside the LAN pretends to be a user of our remote RTP application (i.e. verifier impersonation), that person can easily access the system. Log files of the LAN will be helpful for identifying the user who accessed the system, but stronger security measures such as biometric fingerprint identification may be beneficial.