LENS Learning Engineering for Next-Generation Systems
Case Studies
Part 1 · Healthcare & Patient Safety · What failed

Therac-25

1985 – 1987 healthcaretech

Impact. Six known massive radiation overdoses; at least three deaths; the canonical case in software safety engineering.

Ask AI about this case Opens a new chat prefilled with this case — explore it in your own context.

A radiation-therapy machine killed at least three patients, and every proximate cause investigators found was a line of code. But the deeper failure was a decision no one had flagged as a safety decision: a hardware interlock — the one thing standing between a typing error and a lethal dose — was deleted, its job handed to software, and nothing was built to take its place. That is the casebook’s first principle in its starkest form. Systems don’t fail because the technology breaks; they fail because someone could no longer do what the system required of them — and here the operator was kept in the loop while being stripped of any way to see what the machine was doing wrong.

In brief

The Therac-25, a radiation-therapy machine, massively overdosed at least six patients between 1985 and 1987, killing at least three. Its predecessors used hardware interlocks to stop the high-energy beam from firing without its target in place; judging the interlocks not worth duplicating and trusting software over hardware, the Therac-25 removed them and relied on software — adapted from the older machines and never engineered for safety — to keep the beam modes separated. At least two distinct software defects drove the overdoses — a data-entry race condition behind the cryptic "Malfunction 54" deaths at Tyler, and a counter overflow that silently skipped a collimator check in the fatal Yakima accident — either of which could fire the full beam with no target in place. Leveson and Turner's 1993 investigation, the founding case of software-safety engineering, found a systemic failure: a safeguard removed with nothing put in its place. The lesson — a safeguard you delete does not remove the hazard; it relocates it to whatever you failed to build.

The case in five beats

  1. Hardware interlocks dropped — judged not worth duplicating, software trusted instead; safety case migrated silently into software
  2. Two software defects — a race condition and a counter overflow — fired the full beam with no target
  3. Manufacturer denied harm; Leveson and Turner found systemic, not single-bug, failure
  4. Interlock was the safety case; nothing took its load when removed
  5. The canonical case of software-safety engineering; deleted safeguards relocate hazard to whatever replaces them
The Learning Engineering Lens

LE insight

Therac-25 is the moment when removing the human safety margin became visible as a design choice. The hardware interlock was not redundant — it was the safety case. When it was removed, no equivalent capability was put in its place. The operator was retained in the system but stripped of the ability to detect what it was doing wrong. Capability engineering would have asked, before removing the interlock, what function takes its load?

LENS approach

LENS frames Therac-25 as a Design-Out failure made visible through Interface and Governance pathologies. Studio projects ask students to produce capability-load diagrams tracing every safety function to a hardware backstop, a software check, or a trained operator action with the information needed to perform it — then to examine incident reporting as a governance function in its own right.

The LENS competency this case exercises
  1. 1 Systems Analysis
  2. 2 Iterative Development
  3. 3 Human-System Collaboration
  4. 4 Test & Evaluation
  5. 5 Sociotechnical Constraints

Problem type · PT3

Problem type
D3/PT3
Induced
3.1
CLO
3