The Tragic Software Error That Killed 4 People

On March 21, 1986, a man called Ray Cox woke up and got ready for his appointment at the East Texas Cancer Center. Because he suffered from a tumor on his back, he was scheduled to receive a radiation treatment — his ninth treatment so far. Once at the hospital, he lay down on the treatment table. The table was part of a radiation treatment machine developed and installed a few years earlier by a Canadian company. It was capable of delivering different types of ionizing radiation to damage tumor cells.

While the first eight treatments had gone as planned, something very unexpected happened the ninth time: When the operator pressed the button to deliver the radiation, Cox felt a sudden and sharp pain in the back — a pain he would later describe as an electric shock. Since he knew from earlier treatments that this was not normal, he immediately got up to ask for help. But because the video livefeed of the treatment room was out of order that day, this went unnoticed.

As Cox was getting up, the operator pressed the button again. Cox felt another shock of electricity, this time through his arm — it felt as if it was being torn off. He ran for the door and started banging against it until the operator opened it. A doctor was called to check in on the injuries and observed an intense reddening of the patient’s skin where Cox had felt the shocks earlier. The doctor didn’t think too much of it: To him, it seemed like a simple electric shock, so he decided to send the patient home. The machine was subjected to a test run and performed normally, so it was put back into operation and used to treat more patients that day.

Over the following weeks, Cox stopped being able to move his left arm and suffered from recurrent vomiting and nausea. Shortly after, he lost control of his vocal cords. Five months later, he was dead. As would later become apparent, Cox had not received the prescribed radiation dose of 180 rads on the day of his treatment. Instead, a dose between 16,500 and 25,000 rads had been administered in a much more concentrated area than planned. His symptoms and eventual death were caused by the acute radiation syndrome that he developed as a response to this overdose of ionizing radiation.

Unfortunately, this was not the only case where this machine, the Therac-25, would malfunction. Over the course of its operation, 5 other patients would be affected: 3 more would die in a similarly horrible manner, 2 would suffer from lifelong damage. This is a short story about one of the deadliest software errors in medical history.

How Radiation Therapy Should Work

Before we get into what went wrong, let us first have a look at how a radiation therapy machine normally works. Usually, the machine sends a predefined amount of ionizing radiation at the body part that is supposed to be treated. The radiation is called ionizing because it consists of particles that carry enough energy to rip electrons out of molecules, allowing it to create changes in chemical bonds. This is different from most everyday radiation you encounter, for example the radiation emitted by your phone to connect to the wireless communication tower.

When ionizing radiation interacts with our DNA, it causes damage that needs to be taken care of by the cell to ensure all processes continue functioning properly. Our cells are usually very successful at these repairs, unless the amount of damage reaches a certain threshold: Too much radiation damage and the cell decides to shut down entirely. This is a protection mechanism that makes sure the cell is not turned into a cancer cell by the accumulated DNA mutations.

If you have ever had a severe sunburn, you have witnessed your cells performing such a coordinated self-destruction: The skin you can peel off after a sunburn consists of a collection of cells that have decided to shut down because of too much DNA damage caused by the sun’s UV light.

But how can we use ionizing radiation to treat cancer? For every tumor cell that we kill with it, won’t we also affect a large number of healthy cells?

The first secret is to use the right type of radiation. For example, when a patient is irradiated with electrons, most damage occurs in superficial cell layers. This makes electrons an ideal treatment option for skin cancer — they are treated effectively while the deeper tissue layers remain mostly unharmed.

X-rays on the other hand can be used to reach deeper layers of tissue, which is useful for targeting brain tumors or breast cancer, for example. You can see where these two types of radiation generally deposit most of their dose in the graph below:

The second reason why radiation therapy is effective lies in the nature of tumor cells: They are constantly dividing. As it turns out, cells are most sensitive to radiation while they are performing cell division. Since tumor cells spend more of their time dividing than healthy cells, they are affected more strongly than healthy tissue.

Tumor cells are also worse at repairing radiation damage in general. So if we perform multiple radiation treatments with some time in between, the healthy tissue will have an easier job of regenerating while the tumor cells will struggle. Repeat the procedure enough times and hopefully, every tumor cell is dead and the patient is healed.

The Fatal Flaw That Caused the Disaster

So now that we understand the working principle, let’s come back to our malfunctioning radiotherapy machine. The main selling point of the Therac-25 was that it could provide you with X-rays or electrons depending on the patient’s requirements. We just saw that this is useful to treat a larger range of tumors that may sit at different locations in the patient’s body. The machine achieved this by using a small particle accelerator to speed up electrons, which could then be aimed directly at the patient.

For irradiating patients with X-rays, the machine simply moved a piece of metal into the flight path of the electrons. The electrons then strike the metal and slow down abruptly, causing them to emit energy in the form of X-rays. Because this conversion process from electrons to X-rays is very inefficient, the electron beam needs to be a lot more intense than in the electron mode:

All that was needed to switch between these two modes was a quick hit of a button on the keyboard. The machine would then either move in the metal piece and prepare for an intense electron beam, or remove the piece of metal and use a weaker electron beam. The operator would make the choice by typing either “E” or “X” into the interface below:

But as it turns out, the “quick hit of a button” could also be too quick. Let’s say you select the X-ray mode by error and want to correct your choice. If you type in “E” fast enough after submitting “X”, the machine is still in the process of preparing for X-ray mode. This leads to a bug in the software in which the machine is set up for a disaster: The metal target is not placed in the beam path, but the electron beam is still configured for high power.

Putting too much trust into software

You may ask yourself at this point: How is that even possible? Shouldn’t there be a safety mechanism in place that prevents the electron beam from being fired when the machine’s hardware is in an incorrect configuration? As it turns out, there was a safety mechanism — but unfortunately, only in the predecessor model of the machine. The previous model had a sensor for the metal target that would have prevented such a catastrophic behaviour: If the metal target was not in the right place, no beam could be fired.

For the Therac-25, the company decided to rely on software only to verify the safety of the machine. While this is a questionable choice in itself, it was even worse because of the software developer team. That is, if you consider a single person a “team”. The software for the Therac-25 was developed by a single programmer with questionable qualifications based on code of the predecessor machine, the Therac-6 — code written by colleagues who no longer worked at the company. That same programmer was also responsible for testing his own code; no external review of the code ever took place. The first time the software was actually tested in conjunction with the hardware was in the hospital, when the machine had already been installed.

Operators of the machine were often confronted with cryptic error messages, which would consist of the word “MALFUNCTION” combined with a number from 1 to 64. On the day of the treatment of Mr Cox, the machine displayed “MALFUNCTION 54” multiple times, which was ignored by the operator.

As it turns out, the user manual of the machine did not explain the error codes. It would even fail to address some of them entirely. The description of “MALFUNCTION 54”, for example, simply read “dose input 2 error”. Only by later interviewing a technician of the company was it found out that this means the dose delivered to the patient was either too high or too low. In the manual, there was also no indication that these malfunctions could be dangerous to patients.

When Simple Errors Turn Into Catastrophes

The whole situation reminds me of the Swiss cheese model of accident causation. In aviation, medicine, and other high-stakes fields, disasters rarely stem from a single catastrophic mistake. Instead, they happen when multiple smaller failures line up in exactly the wrong way, like a perfect storm of human error and system breakdown. Think of safety mechanisms like slices of Swiss cheese stacked on top of each other. Each slice has holes — flaws, oversights, or moments of human error — but when you layer them together, the holes rarely align. An error that slips through one safety net gets caught by the next. But every once in a while, all the holes line up perfectly, creating a clear path from mistake to disaster. That’s when people die.

The Therac-25 was a textbook example of Swiss cheese gone wrong. If the hardware interlock from the previous model had stayed in place, no software bug could have delivered a lethal dose — the beam simply wouldn’t have fired. If anyone besides the lone programmer had reviewed the code, they might have caught the timing error that caused the whole mess. And if the manual had actually explained what “MALFUNCTION 54” meant instead of leaving operators to guess, Ray Cox and other patients might have lived.

But every single safety layer failed at once. The hardware protection was removed, the code review never happened, and the documentation was useless. All the holes lined up.

The Therac-25 disaster teaches us something that goes far beyond medical devices. Today, we’re putting software in charge of everything from our cars to our bank accounts, often with the same dangerous assumption: that newer technology is automatically safer technology. But as Ray Cox and the other victims learned in the most tragic way possible, a computer program is only as reliable as the humans who built it. And humans, as it turns out, are pretty good at making mistakes.

The real lesson isn’t to fear technology, but to remember that every line of code was written by someone who probably had a deadline, limited resources, and no crystal ball to predict every possible failure. When lives are on the line, redundancy isn’t wasteful. It is the difference between a system that fails safely and one that fails catastrophically.