Guide to the Supporting Documents
We have provided a set of supporting documents that should help the teacher of this case provide depth and analysis for much of the case. Please be aware that some of these items are copyrighted (e.g. the Leveson excerpts). Other items have been changed slightly from their originals to protect the identity of some individuals.
The case narrative materials provide only information up until the time of the accidents. This nicely puts students in the decision maker's seat, but one is left wondering what decisions actually were made by the main actors. This document provides answers to those questions.
The case history is an overview of the case from the design of Therac-25 to the eventual shut-down of the machine pending redesign. It serves as a short history and guide to the case to give you your bearings.
We use aliases for the victim names in this case. We do so because we do not want to focus on who the players are in this case, but rather on the predicaments in which they found themselves. However, if you must know who is who, we provide a key.
These excerpts are from the article Leveson published in 1993 in IEEE Computer. You can find a more current version of the article at her web site at http://sunnyday.mit.edu/papers/therac.pdf. We selected these excerpts because we felt they described the most critical issues in the case. They go into much more detail on the software problems, the design of the machine and software, and the interface on the VT100 terminal.
Therac History: An overview of the history and physical design of the Therac-25.
The TurnTable. A close look at how the turntable was constructed and how its position was monitored. The turntable position was a critical issue in all the overdoses.
Software Design. An overview of the design of the software in Therac-25. Particular attention is given to how real-time issues resulted in race conditions.
Interface. A description of the operator interface on the VT100 operator console. Particular attention is given to the difficulties with error messages and with editing.
Tyler Software Problem. A description of the software problem that resulted in overdoses at Tyler, TX.
Yakima Software Problem. A description of the software problem that resulted in overdoses at Yakima, and possibly Hamilton, Ontario.
This is a transcription of the memo that the medical physicist at the Tyler, Texas produced upon discovering how to produce the "malfunction 54." Malfunction 54, produced in this way would deliver a dose 25,000 rads of 25 MeV electrons in less than two seconds. The standard therapeutic dose is about 200 rads at any one time. A dose of 500 rads over the entire body is considered lethal to 50% of individuals who receive it. Two persons were killed from the malfunction 54 overdose. One died in 5 months, the other within one month.
There are two documents in this section. Both are derived from an interview we conducted with an operator of a Therac machine. This person was trained as a linear accelerator operator just before the transition to computer controlled linear accelerators in the mid-1980s. One of the first machines she worked on was a Therac-4. This machine had similar computer controls to the Therac-25, but it was not dual mode, and so all the accidents based on dual mode operation were not a possibility. In her interview she speaks of the training (or lack thereof) that operators receive, of the financial pressures on hospitals and cancer treatment facilities, and of the production pressures that operators experience.
First, there is the verbatim interview. This is somewhat closely transcribed, and so shows the standard awkwardness of spoken language transcribed into written language.
In addition, there is a summary of the interview. This provides most of the kernel without the need to wade through the chaff of the entire interview.
In addition to an attempt at a comprehensive bibliography, we provide annotations to those references that we think would be the most useful to students of this case.
This is a chronological listing of events that we felt pertinant to the Therac-25 case.
This is a paper on teaching the Therac-25 case with particular reference to understanding the race conditions that underlie some of the errors. We contend that, given the poor understanding of race conditions in the 1970s, it is anachronistic to blame AECL programmers for not handling these with correct syncronization techniques. This does not absolve AECL of blame for many other system safety errors, but it places the case in its historical context.
The Therac case is created around a medical device and many students may not be familiar with some of the terminology. We have included a case-specific glossary.