Catastrophes as Turning Points: Therac-25 Radiation Therapy Failure - Case Study Example

Catastrophes as Turning Points: Case Study Name: Institute: Therac-25 Radiation Therapy Failure The Context Human error has for decades been cited as the key contributing factor or cause in accidents or disasters in industries. These purported mistakes and accidents are actually just brought about by lack of concentration from the humans. In a time where technology have turned out to be part of day after day living, as well as with the current innovation rate, mistakes by humans are bound to happen. Between 1985 and1987, this type of error did take place, resulting in the loss of 6 people (Leveson & Turner, 1993). This error was acknowledged as Therac-25; a machine utilised in radiation therapy for patients having cancer. As mentioned by Israelski and Muto (2004), this catastrophe remains to be the most unfortunate and biggest case of human mistake with regard to radiation controlled by computer as well as human death. The Therac-25 as per Spiegel (2014) was a medical linear accelerator, created by the Atomic Energy of Canada Limited (AECL) as well as a French company known as CGR. Therac-25 was the latest version of their earlier models, the Therac-20 as well as Therac-6 (Koopman, 2014). Through such machines, electrons were accelerated, thus, creating energy beams which destroyed tumours. The electrons were used for shallow tissue penetration; and then converted into x-ray form for deeper tissue penetration. The a million dollar device was designed to offer radiation treatments to patients having cancer. The majority of such patients had previously undertaken surgery to chuck out most of the tumour, and so the radiation was used to remove any remaining growth. A separate room was used to control Therac-25 was so as to shield the operator from any redundant radiation doses. Patients regularly arrived for a sequence of low energy radiation treatments in order to slowly and securely do away with any residual tumour (Israelski & Muto, 2004). The Therac-25 had two key operation ways: a high energy mode and a low energy mode. The higher energy mode utilised the total machine power at 25 mega-electron volts while the low energy mode had an electron beam of 200 rads, which was directly aimed at the patient. When Therac-25 was used practically, between the patient and the beam a metal plate was slotted in, which changed the electron beam into an x-ray. The machine was created to be exclusively controlled by the computer. An additional feature of Therac-25 was that the utilised software had more duty in safety control considering that the previous versions had separate hardware and machinery pieces for monitoring factors of safety (Leveson & Turner, 1993). The Therac-25 designers held the view that they could save money as well as time in the machine by simply using software as safety control. The last feature is that a number of the previous software utilised in Therac-20 and Therac-6 was utilised in the Therac-25 and so the bug that was found in Therac-25 was afterwards also discovered in the Therac-20. The Method This case study will draw information from various primary as well as secondary sources. The primary sources in this case will be from the time period when Therac-25 catastrophe took place. The primary source in the case study will be original materials through which other research are rooted, and so they will be the first formal results appearances in print, physical, or electronic format. Primary sources included in this study include: audio recordings (radio recording talking about the catastrophe), interviews (such as oral histories), peer-reviewed journal articles; newspaper articles written during that time; proceedings of symposia, conferences and meetings; records of government agencies and organizations (such as annual report and government document); in addition to web site. On the other hand, the secondary data will be gathered from social science such as organisational records as well as censuses, through qualitative research. Evidently, analysis of secondary data will be time effective compared to the time needed for quantitative data, which offers bigger as well as higher-quality databases, which may be impracticable for a single researcher to gather individually. Secondary sources included in this study include: biographical works; magazine and newspaper articles, and textbooks. The Catastrophe Ray Cox, in 1986 went to the clinic for his normal shoulder radiation treatment, but the technician erroneously typed “x” into the PC, which implied x-ray beam. Afterward after instantly realizing the mistake, the technician changed the “x”’ for x-ray into an ‘e’ for electron beam, and then pressed ‘enter’; thus confirming to the Therac-25 machine that it was time for treatment. This sequence took place in not more than 8 seconds considering that this certain sequence, in 8 seconds, had by no means been tested in the original trials of the Therac-25 machine. The computer offered the ‘beam ready’ signal and the technician without hesitation pressed “b” in order to deliver the beam to Ray Cox (Reynard & Stevenson, 2009). However, afterward the computer answered with a message of error, and normally this message signified the failure in delivering the treatment. As a result, the technician did again the process and failed to succeed in delivering another beam to Ray Cox (the patient) because an error message cropped up yet again. In the meantime, Ray experienced sharp piercing pains in his back, and this was a lot different as compared to his normal treatments, and so he got out subsequent to three attempts that were shocking. In this case, since the commands were quickly changed from ‘x’ to ‘e’, the computer failed to correctly respond. The metal plate had shifted away indicating to the technician that the electron beam needed was low energy mode; however, the beam from the machine was a discharge of 25 000 rads with 25MeV, a setting for high energy mode, which as per Leveson and Turner (1993) was over 125 times the normal dose. As a result, the health of Ray quickly become worse, and finally he lost his life 4 months later due to major radiation burns’ complications. Ray case was just one of the six unlucky victims of the Therac-25 machine. The other 5 victims died because of more similar incidents that took place between 1985 and1987. No one knew why patients like Ray were experiencing such undesirable responses to the low energy electron beam. However, they never knew that patients were receiving many radiation dosages than the needed, resulting in terminal effects (Sackman, 1997). When the problem was finally realized, it was too little too late, given that six people had already lost their lives. The Causes A commission was instituted following the catastrophe and in their findings they concluded that the key reason for the failure was due to the poor software design as well as development practices, and not because of a number of coding mistakes, which were discovered. Institutional causes were among the causes that led to Therac-25 radiation therapy failure, as evidenced in a number of research studies. Some of the institutional causes include: failure by AECL to have software code reviewed separately as well as AECL failure to take into account the software design during its evaluation of how the Therac-25 machine could generate the preferred results as well as the failure modes that subsisted (McDaniel, 2002; Leveson & Turner, 1993). In Ray Cox case, the computer discerned something wrong and stopped the X-ray beam from being administered to the patient, but the user manual failed to give details or even deal with the error codes, and that is why he technician pressed ‘p’ to make the warning ineffective and carry on with the treatment. Because of overconfidence, AECL workers together with operators of the machine made them to less believe on complaints. Another mistake was that, AECL had not at all put the Therac-25 into test with the connection of hardware as well as software until it was completely assembled (Dojat, Keravnou, & Barahona, 2003). A number of engineering issues that could have caused the failure were also discovered: for instance, the failure took place only when a certain substandard keystrokes sequence was entered on the VT-100 terminal controlling the PDP-11 computer. When the technician pressed "x" to (mistakenly), and rectify it by pressing "e", and afterwards pressing "enter", all in 8 seconds, made the keystrokes sequence to become impossible (Spiegel, 2014). Furthermore, the design lacked hardware interlocks for preventing the electron-beam from functioning in its high-energy mode devoid of the placed target. Furthermore, the software from previous models was reused by the engineers bearing in mind that these models had hardware interlocks masking the defects of the software. Therefore, those safeties of the hardware lacked reporting means, so there lacked sign of the subsistence of flawed software commands. Furthermore, the hardware offered no means for verification by the software that sensors were functioning properly besides, the task of equipment control failed to correctly synchronize with the interface task of the operator, in order that race conditions could take place in case the setup is rapidly changed by the operator. According to Ellis (1998), this was lacking during the time of testing, given that it took a number of practices before operators could operate hastily enough to generate this mode of failure. The Turning Point The Therac-25 catastrophe formed substratum principles for the critical software community with regard to safety. From this catastrophe it became apparent that accidents are rarely simple since they normally include a multifaceted network of interacting incidents with manifold organizational, human, and technical causes. This made the software community learn that by fixing a certain mistake it will not stop future accidents from occurring given that there is forever another software bug. System engineering failures occurring at higher level are time and again pertinent, like: insufficient follow-through on every accident reported, software engineers overconfidence, software engineering practices that are less-than-acceptable, as well as not viable risk evaluations (which in Therac-25 case involved an evaluation that the software was free from bugs) (Dojat, Keravnou, & Barahona, 2003). Thanks to the Therac-25 failure, the IEC 62304 standard that brings in standards in development life cycle, mainly in medical device software as well as certain direction on making use of software of unknown pedigree, was developed (Furht & Agarwal, 2013). After the failure, it became official that designing any unsafe system in manner that a failure may result in an accident infringes the basic principles of the system-engineering. Therefore, software has since then been treated as a single part of the system. Practically, this connotes that if any software flaw on the system may result in an accident, then that is a one point failure rendering the system unsafe. Basic practices in software-engineering that actually were infringed with the Therac-25 such as documentation are no longer a later addition; assurance practices and standards for software quality has since been established; designs have remained simple; means of getting error information have been included; and the software has since then been subjected to wide-ranging testing as well as formal evaluation at the software and module level. From that time, testing of the system alone is no longer adequate, rather systems are no more designed where one software error result in disaster. It has become apparent that software error must not be the very last investigated possibility in an accident like in Therac-25, so engineers must design systems for the most unpleasant case. After the Therac-25 incident, companies developing risky equipment have since then included hazard tracking as well as logging, accident reporting and analysis as part of procedures for quality control. Numbers of risk assessment has become consequential, and statistics have been treated with prudence. Software audit as well as error logging trail reporting has from that time been designed in all health-related software, and projects for safety-critical software have been incorporated in design as well as safety-analysis procedures (Spiegel, 2014; Leveson & Turner, 1993). As evidenced in the Therac-25 case, reusing software modules cannot assure safety in the novel system this created the need for additional training for software engineers, with regard to working on safety-critical systems. References Dojat, M., Keravnou, E., & Barahona, P. (2003). Artificial Intelligence in Medicine. 9th Conference on Artificial Intelligence in Medicine in Europe, AIME 2003 (pp. 1-316). Protaras, Cyprus: Springer Science & Business Media. Ellis, J. R. (1998). Objectifying Real-Time Systems . Cambridge : Cambridge University Press. Furht, B., & Agarwal, A. (2013). Handbook of Medical and Healthcare Technologies. New York: Springer Science & Business Media. Israelski, E., & Muto, W. (2004). Human factors risk management as a way to improve medical device safety: a case study of the therac 25 radiation therapy system. The Joint Commission Journal on Quality and Patient Safety, 30(12), 689-695. Koopman, P. (2014, February 17). The Therac 25: A Case Study in Unsafe Software. Retrieved from Better Embedded System SW: http://betterembsw.blogspot.com/2014/02/the-therac-25-case-study-in-unsafe.html Leveson, N., & Turner, C. (1993). An investigation of the Therac-25 accidents. IEEE Computer, 21(4), 18 - 41. McDaniel, J. G. (2002). Improving system quality through software evaluation. Computers in Biology and Medicine, 32(3), 127 - 140. Reynard, J., & Stevenson, P. (2009). Practical Patient Safety. Oxford : Oxford University Press. Sackman, H. (1997). Biomedical Information Technology: Global Social Responsibilities for the Democratic Information Age. Waltham, Massachusetts: Academic Press. Spiegel, R. (2014, October 20). Engineering disasters: Deadly Zaps from the Therac-25. Retrieved from Tech online India: http://www.techonlineindia.com/techonline/news_and_analysis/298361/engineering-disasters-deadly-zaps-therac/page/2 Read More