Medical Technology
Therac-25
A radiation-treatment machine placed critical safety functions in software without the engineering, feedback, and independent protections needed to make that trust safe.
The knowledge that remained
Knowledge that outlived the failure.
- 01
Safety-critical software must be analyzed as part of the whole medical system, not as an isolated program.
- 02
Operators need feedback that explains hazardous state, not cryptic codes that encourage routine overrides.
- 03
Independent hardware interlocks and incident reporting are defenses against both unknown bugs and organizational blind spots.
Therac-25 became a foundational case in medical-device software, human-centered safety engineering, defense in depth, and the obligation to report and connect adverse events.
Timeline
The sequence of failure.
- 01Investigation1985
Overdose accidents begin
Patients receiving radiation treatment report severe injuries after abnormal Therac-25 exposures.
- 02DecisionOPERATION
Cryptic errors appear
The interface presents terse malfunction codes while operators lack direct visibility into the dangerous machine state.
- 03InvestigationINVESTIGATION
Timing faults are reconstructed
Software race conditions can bypass safety checks during particular sequences of rapid operator input.
- 04InvestigationAFTERMATH
The system failure becomes the lesson
The case exposes failures in software, testing, reporting, human factors, and regulatory control.
The event.
Therac-25 was a computer-controlled medical linear accelerator designed to deliver radiation therapy. During the 1980s, a series of patients received severe overdoses instead of the prescribed treatment.
Patients suffered catastrophic radiation injuries and deaths. The exact casualty count varies across accounts, so the archive preserves the documented systemic mechanism rather than asserting a disputed total.
The mechanism.
Timing faults, opaque error messages, weak safety analysis, and inadequate independent interlocks allowed hazardous high-power treatment states.
Investigators documented software timing faults, inadequate safety analysis, opaque operator feedback, weak incident communication, and excessive confidence that software made earlier hardware interlocks unnecessary.
Sources & references
Trace the evidence.
Media rights record: The machine photograph is recorded as public domain; the interface image is used under its documented free-use terms. Original causal diagrams are Instinto Archive editorial work.
Discovery edition
The case in under one minute.
The Short introduces the failure. This archive record preserves the mechanism, evidence, and engineering lesson beyond the video.
Short ready for releaseEditorial derivatives
Editions from this case.
A portable, source-backed edition of the complete case.
The failure sequence formatted for print and classroom display.
Mechanism, consequence, and lesson in one visual system.
Discussion prompts, activities, and a structured answer guide.
The question to remember
Was Therac-25 caused by a single software bug?
No. Timing faults were part of the mechanism, but the accidents required a wider system that trusted software too much, removed independent defenses, obscured operator feedback, and failed to learn quickly from earlier injuries.
