Notorious Software Bug Was Killing People 40 Years Ago — At Least Three People Died After Radiation Doses That Were 100x Too Strong From The Buggy Therac-25 Radiation Therapy Machine

Therac-25 software bug lawsuit
Therac-25 software bug lawsuit

A Crackle and a Cry: The Moment Everything Changed

Spring. East Texas. The hum of hospital machinery, the hopeful tension of patients fighting for survival. But beneath the sterile calm, one fateful afternoon in 1986, an innocuous treatment session turned into a scene from a thriller — a “crackle” from the radiation machine, pain surging like fire, and a desperate banging on the door[2]. It was another day for technicians. For the patient, it would be the day everything changed.

This was the Therac-25: a marvel of modern medicine, a computer-controlled radiation therapy machine meant to cure cancer with pinpoint accuracy[2]. But inside its metal body lurked a silent menace — a software bug buried so deep, so subtle, no one realized its power until too late.

The Invisible Malfunction: When Code Went Rogue

What went wrong that day? A seasoned operator noticed an error: “Malfunction 54.” Just a number on the screen. The manual offered no help. People were used to these cryptic glitches; some happened four times a day[1]. Most were harmless, a nuisance in busy clinics. But this one was different.

Because instead of stopping, operators were trained — almost conditioned — to press “P” to proceed. Few knew that behind this shortcut lay a collision: an unseen bug in 100,000 lines of code, ready to deliver a lethal overdose of radiation in an instant[1][2]. The dosimeter, a safety monitor, read low values. But the patient’s body told the truth: unbearable burning, paralysis, the relentless march of radiation poisoning[2].

Unraveling the Code: How Could This Happen?

To understand the Therac-25’s fatal flaw, you don’t need to be a programmer. Imagine a factory robot that checks 256 times before refilling a part. If a worker enters the wrong command at exactly the moment the robot resets its counter, disaster strikes. The Therac-25’s “housekeeper task” did something similar: it checked the machine’s position in memory, but a single misstep — a technician fast on the keys, a second of timing — could let the bug slip through[1].

Worse still, the error codes served as false comfort. Operators grew accustomed to ignoring warnings. Nobody understood that error 54 was the tip of an iceberg: a system built on blind faith in software, trusting that high-tech meant high-safety[1][2].

The Human Toll: A Family’s Nightmare

Consider the story of Voyn Ray Cox, a real man whose ninth cancer treatment marked the beginning of the end. He felt something was wrong, but the pace of the hospital, and the faith in technology, pushed people forward. Within weeks, Cox faced paralysis, nausea, and ultimately, death — all caused not by the disease, but by the cure[2].

Now, picture his wife at home, cradling paperwork, searching for answers in the language of error codes. For families, the tragedy wasn’t just scientific; it was deeply, heartbreakingly personal.

Expert Insights: Ignoring the Red Flags

Why did it take so long to respond? Dr. Fritz Hager, the local physicist, refused to accept official denials. He stayed after hours, frantically recreating the bug until he succeeded. His calls to the manufacturer triggered a flurry of memos and investigations. The FDA launched its own inquiry, demanding immediate fixes[1].

But the real culprit was systemic. Government reports later revealed that Atomic Energy of Canada Limited (AECL), the Therac-25’s creator, had never tested the integration of software and hardware together. Safety procedures, code review, independent testing — all were bypassed in the rush to innovate[2].

The Ripple Effect: Industry and Government on Alert

Once the truth emerged, panic spread. Memos circulated warning operators not to use certain keys, hospitals halted treatments, and communities demanded answers[1]. The defects forced a sea change: new regulations, mandatory independent code review, and tougher standards for medical device software.

Silicon Valley took note, too. The story of Therac-25 became the go-to cautionary tale for software engineers, taught in ethics courses and whispered in the halls of every tech company building code that might one day save — or end — lives.

What’s Next / Could It Happen Again?

Looking forward, many wonder: are today’s AI-powered machines truly safe from similar disaster? Have we learned enough, or does invisible code still rule our lives in ways we can’t see?

As software becomes the heartbeat of medical innovation (and vehicles, and homes), the lessons of Therac-25 remain painfully relevant. Will future algorithms be held to a higher standard — or will the next bug merely wait in silence?

If software can deliver life-saving miracles, it must be held accountable for its mistakes. Who’s watching the machines that watch over us?


FAQ

What was the Therac-25 bug?
The Therac-25 bug was a critical software error in a 1980s radiation therapy machine that led to massive overdoses of radiation, causing multiple deaths and injuries[2].

How did the Therac-25 error happen?
A combination of rapid data entry and a hidden flaw in the machine’s “housekeeper” routine let a single mistimed command trigger a lethal dose, undetected by safety systems[1].

How did the Therac-25 accidents impact medical software safety?
The disasters led to major reforms, including mandatory independent code reviews and tougher safety protocols for medical devices worldwide.

Could a software bug like Therac-25 happen again?
While regulations have improved, medical devices remain vulnerable to errors. The Therac-25 tragedy still serves as a warning against blind trust in software-driven healthcare.

Who’s responsible for medical device safety today?
Manufacturers, regulators like the FDA, and the hospitals themselves all share responsibility. Software is now subject to extensive testing, though no system is infallible.

How do modern medical devices avoid similar errors?
Most use redundant safety checks, independent audits, and user-tested interfaces, but complex software always carries inherent risk.

Why is the Therac-25 tragedy still taught today?
It’s a textbook example of why software engineering standards, ethics, and rigorous independent testing are essential in any industry where lives depend on code.

Leave a comment

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