Year : 2013 | Volume
: 38 | Issue : 1 | Page : 1--3
Software safety in radiation therapy
Greg Salomons1, Diane Kelly2,
1 Department of Medical Physics, Cancer Center of Southeastern Ontario and Department of Physics, Queen's University, Kingston, ON, Canada
2 Department of Mathematics and Computer science, Royal Military College of Canada, Kingston, ON, Canada
Cancer Centre of South-Eastern Ontario, 25 King St. West,Kingston, ON, Canada, K7L 5P9
|How to cite this article:|
Salomons G, Kelly D. Software safety in radiation therapy.J Med Phys 2013;38:1-3
|How to cite this URL:|
Salomons G, Kelly D. Software safety in radiation therapy. J Med Phys [serial online] 2013 [cited 2023 Jan 28 ];38:1-3
Available from: https://www.jmp.org.in/text.asp?2013/38/1/1/106592
Radiation Therapy has always been computer intensive and its increasing reliance on software is a two-edged sword. Current software gives the ability to provide reliable and ubiquitous access to patient information, and to use complex treatment techniques such as Intensity Modulated Radiation Therapy (IMRT) to upload treatment parameters automatically, thereby, improving efficiency and accuracy. However, different and new technology brings different and novel errors. We've been trained to trust the software, but we also need to learn how to assess the software to validate that trust. We need software quality guidelines specific for radiation therapy software and specific to the medical physics community.
Improvements to patient treatment made possible by modern software have been significant. Software has reduced or eliminated many types of errors that have been known to occur in the delivery of radiation therapy. The problem is that software introduces new types of errors which we need to be wary of. We can look at examples of changes in types of errors under three different categories: Transcription errors, calculation errors, and system errors.
Transcription errors come from copying or entering incorrect information. This used to be the most commonly reported type of treatment error, but now, most data entry software is designed so that data is entered only once, stored in a database, and made available for multiple applications. In addition, most software does some limited checking on newly entered data to catch common and detectable mistakes.
The key problem is the phrase-limited checking. This means that wrong data can still be accepted by the software and disseminated across different applications. Following routine crosschecking procedures, a user might compare data on their screen to a printout of the same parameters from a different computer. This user may, unfortunately, be unaware that both have been generated from the same source; thus, if the data is wrong in the printout it will also be wrong in on the screen. As a result while the user appears to be verifying the data, in fact, no useful data checking has occurred.
Forms that are meant to ensure accurate data entry can also cause problems. The software handling the forms can be designed to only handle known and typical cases. An atypical case might then be rejected. For example, Record and Verify (R and V) software might be designed to accept a certain range of monitor units (MUs) per field, reflecting typical treatment doses. The software might then not allow the therapists to enter the large number of MUs necessary for a single fraction palliative treatment. Worse yet, it might accept the data but mishandle it. For example, a certain treatment planning system might allow a plan to be generated which contains multiple isocenters, while the R and V software might not recognize the dual isocenters. In this case, it is possible that all fields might end up being delivered to the same isocenter resulting in a significant treatment error.
Calculations, such as those used to determine the appropriate number of (MUs) for a given treatment field, have always carried the risk of error and typically more than one person performs the same calculation as a double check. In the past, calculation errors have resulted from forgotten factors, incorrect table lookup, or simply pushing wrong buttons on a calculator. Now, automatic and independent MU calculations are performed quickly and efficiently by the treatment planning software system and by a separate software system. However, the same problem with mistaken data entry can have an effect here. Even though the two software systems doing the MU calculations are independent, they can be using the same mistaken data source and give identical, but incorrect answers.
System error is taken as the traditional view of system aging with physical wear or failure of components, typically resulting in a gradual drift from correct values. Tests used to catch these types of error involve periodic measurements and follow a standard process. Significant changes in measured results indicate repairs or adjustments are needed. A good example of this type of error would be changes in linear accelerator output, which tend to drift over time and need to be corrected.
Unfortunately, it is often assumed that such repeated, identical tests will also catch errors in software. Software does not wear out. Software errors come from mistakes in the program logic, commonly referred to as bugs. Bugs can take on a myriad of different forms and can manifest themselves in the behavior of the software in a myriad of different ways. Even if bugs are present, the software, under many circumstances can operate correctly. There may be a set of "tests" that demonstrate that the software runs correctly. The software is likely to always run correctly when executed with those tests. The only way a bug can be found is by operating the software under new and untried conditions.
There is extensive literature on software testing. Any reasonably sized piece of software will have bugs. Except for a trivially simple piece of software, no software can be tested completely. The literature on software testing generally agrees that all software testing is sampling. The trick is to decide on a sampling that is effective for a particular application and validates the user's trust in the software.
Given the limitations of software testing and the reality of bugs existing in all software, then a systems' view of safe operation of the radiation therapy equipment has to be taken. What practices should be followed to mitigate mistakes and software failures?
In the last decade, over 80 original research articles specifically devoted to quality assurance for radiation therapy have been published. Unfortunately, quality and safety of the software itself has been ignored. In that same decade, only one paper on software quality in medical physics was published,  and this paper contained no original research. It was a list of recommendations based on the author's personal opinions, with no evidence that the recommendations were effective at preventing errors.
It has been suggested that the medical physics community should just look to standards and guidelines established for software quality by other industries. This has started happening for other aspects of quality assurance, such as control charts and failure modes analysis. However, other industries have different priorities and definitions of software quality. For example, is it preferable to have word processing software crash rather than use incorrect margins? Or is it preferable for an in-flight guidance system on a space rocket crash rather than degrade to a "best" estimate? For a monitor unit calculation, it is much better that the software crash than give an incorrect answer. This difference in priorities means that taking guidelines for software quality from other industries and applying them to clinical software may lull us into a false sense of security, or even be detrimental to the goals of the medical physics community. Being aware of ideas from other industries is useful, but the medical physics community needs to develop practices and guidelines that are tailored to their very specific requirements and circumstances.
Currently, there are two International Atomic Energy Agency (IAEA) reports that deal with treatment planning systems. Report No. 430,  published in 2004 and Report No. 1540,  published in 2007. In Report No. 430, the section on quality assurance focuses on required staffing and only minimally on procedures. Its recommendations regarding software quality can be summarized as "know the software". There are no specifics on how to do this. Report No. 1540 primarily addresses the functionality and accuracy of the software. It provides a list of very specific tests similar to the quality assurance measurements one would do periodically for a linear accelerator. These tests are useful to verify that the treatment planning system algorithms meet a certain standard of accuracy for specific cases, but do nothing to assure the safety of the software during routine and non-routine clinical uses.
The most recent American Association of Physicists in Medicine (AAPM) task group report on quality assurance for treatment planning systems is AAPM Report # 63 (Task Group #53),  published in 1998. This report is almost 15 years old. Many technological advances have occurred since then, but it provides good insights into the issue of software testing. The authors acknowledge the presence of software bugs and the fact that it will be impossible to find all of them. They also acknowledged the need to tailor tests to each specific system and institution.
A current AAPM task group (#201),  which originally was the Work Group on Information Technology, is addressing the quality assurance of external beam data transfer. It is currently scheduled to release its report at the end of 2013. This task group is addressing one specific aspect of software quality, but the results of their report may also provide guidance on other aspects of software quality.
The medical physics community is lacking the quality guidelines specific to the testing and use of software. Generating efficient and effective guidelines is best done based on an understanding of the medical physics community, its goals, priorities, and present circumstances related to hardware, software, personnel, medical policies, and environment. This is only possible after research is done. It is unwise to just copy what is being done in other industries. Instead, this community needs to establish its own priorities and formulate guidelines to meet those priorities. The opportunities are there for those willing to tackle this new challenge.
|1||Gersten, D. and Langer, S. Programming in the small Journal of Digital Imaging 24 (2011) 142-150.|
|2||Commissioning and Quality Assurance of Computerized Planning Systems for Radiation Therapy of Cancer. IAEA TRS-430. Vienna: International Atomic Energy Agency; 2004.|
|3||Specification and Acceptance Testing of Radiotherapy Treatment Planning Systems. IAEA TRS-1540. Vienna: International Atomic Energy Agency; 2007.|
|4||Fraass B, Doppke K, Hunt M, Kutcher G, Starkschall G, Stern R, et al. American Association of Physicists in Medicine Radiation Therapy Committee Task Group 53: Quality assurance for clinical radiotherapy treatment planning. Med Phys 1998;25:1773-829.|
|5||Status of AAPM Task Groups, American Associations of Medical Physicists; 2012. Available from: http://www.aapm.org/org/structure/report_stats.asp. [Last accessed on 2012 Nov 29].|