Six Massive Overdoses: How Therac-25 Let Software Do the Job of Hardware Safety Interlocks

A beige DEC VT100 terminal in a blueprint-style editorial composition about the Therac-25 radiation therapy accidents.


On 21 March 1986, at the East Texas Cancer Center in Tyler, a patient lay face down on a treatment table for his ninth radiation session. Outside the shielded room, the operator typed in his prescription, noticed she had entered “x” for X-ray instead of “e” for electron, moved the cursor up, and fixed it. The screen said “beam ready.” She pressed “B.”

The machine stopped and displayed “Malfunction 54.” The dose monitor showed an underdose. Inside the room, the patient felt something like an electric shock. Later reconstructions suggested he may have received between 16,500 and 25,000 rads in under a second. A typical single treatment dose was around 200 rads.

The machine was a Therac-25. Between June 1985 and January 1987, it was involved in six known massive overdoses in the United States and Canada. Nancy Leveson and Clark Turner, who later reconstructed the accidents, called them the worst series of radiation accidents in the history of medical accelerators up to that point.

Timeline

June 1985, Marietta, Georgia: a patient is badly burned. The hospital physicist asks the manufacturer, Atomic Energy of Canada Limited (AECL), whether the machine could be responsible. AECL says no, and the accident is never carefully investigated.

July 1985, Hamilton, Ontario: a second overdose. AECL blames a turntable microswitch, changes it, and tells customers its analysis shows safety improved by at least five orders of magnitude.

December 1985, Yakima, Washington: a patient develops a striped burn. In February 1986, AECL replies in writing that the damage could not have been caused by the machine or by operator error.

21 March 1986, Tyler, Texas: the “Malfunction 54” overdose. AECL engineers cannot reproduce it and suggest an electrical problem. The machine returns to service on 7 April.

11 April 1986, Tyler: same machine, same operator, same message, another overdose.

17 January 1987, Yakima: a sixth overdose, caused by a different software bug.

February 1987: US and Canadian regulators tell users to stop routine treatment until the machine is fixed.

The design decision underneath

The Therac-25 had two older siblings, the Therac-6 and Therac-20. On those machines the computer was a convenience added to hardware that could work safely on its own. They had independent electrical and mechanical interlocks.

The Therac-25 was designed for computer control from the start. According to Leveson and Turner, AECL decided not to duplicate all of the existing hardware safety mechanisms and relied on software instead. Part of that software was reused from the Therac-6, and some routines came from the Therac-20.

That choice matters for what happened next. The software had been written largely by one person in PDP-11 assembly language, with little documentation. It ran several tasks at once that shared variables without proper synchronization.

Root cause 1: the eight-second window

After the second Tyler accident, the hospital physicist, Fritz Hager, worked with the operator to recreate exactly what she had done. They found the trigger was speed. If an experienced operator edited the prescription quickly enough, the error appeared.

The mechanism, as AECL later described it to the FDA, went like this. Once the operator finished entering data, a routine began setting the bending magnets, which took about eight seconds. During that time, a subroutine was supposed to check whether the operator had edited anything. But a flag was cleared after the first pass, so later passes stopped looking for edits.

If the operator changed the mode from X-ray to electron and got the cursor back to the bottom of the screen within those eight seconds, the screen showed the new setting. The machine did not fully apply it. It could fire a high-power beam meant for X-ray mode without the X-ray target and beam-shaping equipment in place.

A sheet on the side of the machine said “Malfunction 54” was a “dose input 2” error. Nothing available to the operators explained what that meant.

Root cause 2: a counter that wrapped to zero

The 1987 Yakima accident had a different cause. During setup, a one-byte variable called Class3 was incremented on every pass through a test routine. A nonzero value meant “check the collimator position before allowing treatment.”

A byte can only count to 255. On every 256th pass it rolled over to zero, and the check was skipped. If the operator pressed “set” at that exact moment, the machine could turn on the beam while the turntable was in the wrong position. AECL’s fix was simple: set the variable to a fixed nonzero value instead of incrementing it.

Why it was not caught

None of this required bad intentions. It required several reasonable-sounding assumptions to line up.

AECL’s 1983 safety analysis effectively treated software as reliable and focused on hardware failures. Error messages were cryptic, and the machine stopped so often for harmless reasons that operators learned to press “P” to continue. One operator testified that it was not out of the ordinary for something to stop the machine.

The clearest sign came from the older model. After the Tyler accidents, a physicist at the University of Chicago found that the Therac-20 had a similar software error. On that machine it only blew fuses, because hardware interlocks stopped the beam. The fuses had been blowing for years. The hardware had hidden the bug.

The cost

Leveson and Turner record that patients died from complications of their overdoses and others suffered severe injuries, including paralysis and the loss of a breast. The machines were taken out of routine use in early 1987. AECL’s final corrective plan, issued in July 1987, added independent hardware protection such as a single-pulse shutdown circuit and turntable monitoring, along with more than twenty software changes.

What would have caught it

  • Independent hardware interlocks that stop the beam no matter what the software believes.
  • Treating reused code as new code when it moves into a system with different safety assumptions.
  • Proper synchronization for shared state between concurrent tasks.
  • Error messages that tell operators how dangerous a fault is, and fail-safe stops that cannot be resumed with one key.
  • A process that investigates every reported injury as a possible system failure.

Leveson and Turner warned against reading the Therac-25 as the story of one bug. Focusing on particular software bugs, they wrote, is not the way to make a safe system. The question to ask about your own systems is sharper: if the software is wrong, what else is still standing between the error and the person on the other end?

Sources

Share this article
FacebookThreadsLinkedInX

Leave a Reply

Your email address will not be published. Required fields are marked *