therac-25 therac-25 the therac-25 was a computer-controlled radiation therapy machine produced by atomic energy of canada limited (aecl) in 1982 after the therac-6 and therac-20 units (the earlier units had been produced in partnership with compagnie générale de radiologie (cgr) of france). it was involved in at least six accidents between 1985 and 1987, in which patients were given massive overdoses of radiation.: 425 because of concurrent programming errors (also known as race conditions), it sometimes gave its patients radiation doses that were hundreds of times greater than normal, resulting in death or serious injury. these accidents highlighted the dangers of software control of safety-critical systems, and they have become a standard case study in health informatics, software engineering, and computer ethics. additionally, the overconfidence of the engineers: 428 and lack of proper due diligence to resolve reported software bugs are highlighted as an extreme case where the engineers' overconfidence in their initial work and failure to believe the end users' claims caused drastic repercussions. design the machine had three modes of operation, with a turntable moving some apparatus into position for each of those modes: either a light, some scan magnets, or a tungsten target and flattener. a "field light" mode, which allowed the patient and collimator to be correctly positioned by illuminating the treatment area with visible light. direct electron-beam therapy, in which a narrow, low-current beam of high-energy (5 to 25 mev (0.80 to 4.01 pj)) electrons was scanned over the treatment area by magnets; megavolt x-ray (or photon) therapy, which delivered a beam of 25 mev x-ray photons. the x-ray photons are produced by colliding a high current, narrow beam of electrons with a tungsten target. the x-rays are then passed through a flattening filter, and then measured using an x-ray ion chamber. the flattening filter resembles an inverted ice-cream cone, and it shapes and attenuates the x-rays. the electron beam current required to produce the x-rays is about 100 times greater than that used for electron therapy. problem description simulated therac-25 user interface the six documented accidents occurred when the high-current electron beam generated in x-ray mode was delivered directly to patients. two software faults were to blame. one, when the operator incorrectly selected x-ray mode before quickly changing to electron mode, which allowed the electron beam to be set for x-ray mode without the x-ray target being in place. a second fault allowed the electron beam to activate during field-light mode, during which no beam scanner was active or target was in place. previous models had hardware interlocks to prevent such faults, but the therac-25 had removed them, depending instead on software checks for safety. the high-current electron beam struck the patients with approximately 100 times the intended dose of radiation, and over a narrower area, delivering a potentially lethal dose of beta radiation. the feeling was described by patient ray cox as "an intense electric shock", causing him to scream and run out of the treatment room. several days later, radiation burns appeared, and the patients showed the symptoms of radiation poisoning; in three cases, the injured patients later died as a result of the overdose. root causes a commission attributed the primary cause to general poor software design and development practices rather than single-out specific coding errors. in particular, the software was designed so that it was realistically impossible to test it in a rigorous, automated way.: 48 researchers who investigated the accidents found several contributing causes. these included the following institutional causes: aecl did not have the software code independently reviewed and chose to rely on in-house code, including the operating system. aecl did not consider the design of the software during its assessment of how the machine might produce the desired results and what failure modes existed, focusing purely on hardware and asserting that the software was free of bugs. machine operators were reassured by aecl personnel that overdoses were impossible, leading them to dismiss the therac-25 as the potential cause of many incidents.: 428 aecl had never tested the therac-25 with the combination of software and hardware until it was assembled at the hospital. the researchers also found several engineering issues: several error messages merely displayed the word "malfunction" followed by a number from 1 to 64. the user manual did not explain or even address the error codes, nor give any indication that these errors could pose a threat to patient safety. the system distinguished between errors that halted the machine, requiring a restart, and errors which merely paused the machine (which allowed operators to continue with the same settings using a keypress). however, some errors which endangered the patient merely paused the machine, and the frequent occurrence of minor errors caused operators to become accustomed to habitually unpausing the machine. one failure occurred when a particular sequence of keystrokes was entered on the vt-100 terminal which controlled the pdp-11 computer: if the operator were to press "x" to (erroneously) select 25 mev photon mode, then use "cursor up" to edit the input to "e" to (correctly) select 25 mev electron mode, then "enter", all within eight seconds of the first keypress, well within the capability of an experienced user of the machine. these edits were not noticed as it would take 8 seconds for startup, so it would go with the default setup. the design did not have any hardware interlocks to prevent the electron-beam from operating in its high-energy mode without the target in place. the engineer had reused software from the therac-6 and therac-20, which used hardware interlocks that masked their software defects. those hardware safeties had no way of reporting that they had been triggered, so preexisting errors were overlooked. the hardware provided no way for the software to verify that sensors were working correctly. the table-position system was the first implicated in therac-25's failures; the manufacturer revised it with redundant switches to cross-check their operation. the software set a flag variable by incrementing it, rather than by setting it to a fixed non-zero value. occasionally an arithmetic overflow occurred, causing the flag to return to zero and the software to bypass safety checks. leveson notes that a lesson to be drawn from the incident is to not assume that reused software is safe: "a naive assumption is often made that reusing software or using commercial off-the-shelf software will increase safety because the software will have been exercised extensively. reusing software modules does not guarantee safety in the new system to which they are transferred..." in response to incidents like those associated with therac-25, the iec 62304 standard was created, which introduces development life cycle standards for medical device software and specific guidance on using software of unknown pedigree.