Abstract
We developed a web-based, remote radiation treatment planning system which allowed staff at an affiliated hospital to obtain support from a fully staffed central institution. Network security was based on a firewall and a virtual private network (VPN). Client computers were installed at a cancer centre, at a university hospital and at a staff home. We remotely operated the treatment planning computer using the Remote Desktop function built in to the Windows operating system. Except for the initial setup of the VPN router, no special knowledge was needed to operate the remote radiation treatment planning system. There was a time lag that seemed to depend on the volume of data traffic on the Internet, but it did not affect smooth operation. The initial cost and running cost of the system were reasonable.
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. 1 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. 2 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.

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 (
Scale for rating the operating speed of the remote RTP system
Results
Accessibility and connections between facilities
Acquisition of global IP addresses through the Internet provider service company was easy. The initial setup of the VPN router was complicated and needed expert knowledge, but other preparations, including the installation of the Remote Desktop Connection Client for the Mac, were easy. Once the connections between facilities had been established, the system was trouble-free with regard to Internet data communication. Data transfer rates seemed to depend on the state of traffic on the Internet. Average direct throughput (speed with the client and server directly connected via Internet) was 6.22 Mbit/s between Kushiro and the home of the staff member (ADSL) and average direct throughput was 12.8 Mbit/s between Kushiro and the Hokkaido Cancer Centre (broadband). There were no difficulties in connecting to the system using either a PC with Windows XP professional or a Macintosh computer with Mac OS and RDC for Mac.
Subjective operating speed
The speed of remote RTP in the connections between Kushiro Municipal General Hospital, Hokkaido Cancer Centre, the Medical Image Laboratory and the home of the staff member are shown in Table 2. We were able to perform remote RTP without difficulty in all connections (level 4 or 5 according to our scale). We also investigated the speed in displaying a video recording of experimental data of one of our patients (Table 3). The video was recorded at the rate of 10 frames per respiration. There was moderate delay in the connection to Kushiro from the staff member's home (level 3).
Subjective operating speed for treatment planning from different locations
Subjective operating speed for displaying video
Initial cost and running cost
The initial cost of the system included the cost of four VPN routers, the four contracts with the Internet service providers and the cost of two client computers. The total setup cost was 924,000 Yen (1 Yen is approx US$0.01) (see Table 4).
Initial cost and running cost of the remote RTP system
The running cost at each of the facilities included the broadband line fee, the Internet service provider charge and the cost of the global IP address. The total monthly cost was 62,400 Yen, i.e. 748,800 Yen per year.
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. 3 reported that teleradiology case conferences were useful for radiation treatment planning, and Smith et al. 4 developed a network for radiotherapy image distribution. In 1998 Stitt 5 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. 6 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. 7 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. 8 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. 9 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. 10 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. 11 and by Kum. 12 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 7 and GALENOS 8 ). The Type B system consists of two RTP systems (e.g. Helax-TMS 9 and the remote disk-mount technique 10 ). 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. 13 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. 14 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.

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.8 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.
Conclusions
Except for the initial setup of VPN routers, no special knowledge or operation was needed to use our remote RTP system. In use, there was a time lag that seemed to depend on the volume of data traffic on the Internet, but it did not affect smooth operation. Our system was easy to use and remote treatment planning was possible at a low cost using the Remote Desktop functions built-in to the Windows operating system.
Footnotes
Acknowledgements
This study was supported by a grant from the NOASTEC (H19-SHI-14), Hokkaido Japan. The authors have no conflicts of interest.
