Prostate Cancer Diary: Day 115 — Therac 25 and a thankfully minor glitch in my radiotherapy
[Note to readers: I am not posting prostate cancer (PCa) diary entries every day. To be honest, I can't keep up. The hormone therapy (ADT) that I started three and a half months ago has slowed me down, as has the radiotherapy (RT) which I started on the first of July. I've been warned that the effects of RT build toward the end of the sessions and even beyond, before tapering off. Thankfully my last session is July 28. Hoping to pick up the pace mid-August. In the meantime, I will post what I can, when I can.]
July 24. 2026
This morning, I was off to a flying start at the Arden Cancer Centre. Arrived early for my 9:15 appointment thanks to light traffic. Was called in at 9:13. Bladder scan was positive and I was ushered into theatre right away. The team was in good mood, joking with M, one of the TRs I haven't met before. Apparently, she had "saved the day" the day before when a late start due to routine system checks backed up appointments pretty badly. (News that made me even more grateful that they had squeezed me in early yesterday.)
I hopped up on the scanning table, pulled my pants down, and they quickly placed the modesty wrapper in place. Then it was just a few minutes before the targeting scan was happening. Whir, whir, as the massive VersaHD head unit rotated, imaging my innards in great detail, then:
Click! The machine froze and started going beep, beep, beep...
Naturally, my first thought was: Therac-25! Quickly followed by: "Don't worry, the photon beam is not on, there's no radiation happening, this is just the targeting run." Also: "Surely they can hear this beeping."
Turns out, they could hear the beeping, and they spent several minutes trying various measures to clear the error that was causing it before coming into the room. They assured me it was nothing to worry and an engineer was on his way. They also started checking the equipment to find a way to silence the beeps. Eventually, the beeps stopped and the engineer arrived.
The decision was made to proceed with my session on a different, identical VersaHD machine, and the bed was lowered. I pulled up my pants and was helped down. As I was putting on my shoes to walk to the other machine, I said something like:
 |
| 1980s radiotherapy machine, the Therac-25 (Original source: untraceable) |
"At least it's not a Therac-25."
To which several of the team responded, "What's that?"
But to my delight, the engineer launched into a very good summary of the Therac-25 incident.
This was a series of six massive radiation overexposure accidents involving a computer-controlled radiation therapy machine called the Therac-25, between 1985 and 1987, driven by race conditions, poor software design, and removed hardware safety interlocks. These software faults caused patients to receive up to 250 times the intended radiation dose, resulting in severe burns and multiple deaths. (Wikipedia).
Fortunately, when the details of these horrific incidents came to light, the entire medical technology world took notice, and the Therac-25 was subjected to intense scrutiny. A range of problems was identified:
- a race condition in the software that allowed the high-power beam to fire without the beam-spreader plate in place,
- an overconfidence in software safety that led engineers to remove hardware interlocks present in earlier models,
- poor error reporting that displayed cryptic codes like "Malfunction 54" instead of clear warnings,
- and a culture at the manufacturer, AECL, that was slow to investigate and acknowledge the reports of injury.
The fallout reshaped how the industry thinks about safety-critical software. Nancy Leveson and Clarence Turner's 1993 investigation became a foundational case study, still taught in software engineering and systems safety courses today. It clarified the dangers of relying too heavily on software alone to enforce safety without independent hardware checks.
More concretely, the incidents contributed to tighter US FDA oversight of software in medical devices, spurring the development of formal standards such as IEC 62304 for medical device software lifecycle processes and IEC 60601 for electrical safety.
The Therac-25 failures also pushed the field toward practices like formal hazard analysis, independent redundant safety mechanisms, and rigorous change-control procedures for software updates, recognizing that a single software fix, applied without full re-verification, can introduce new failure modes just as dangerous as the ones it was meant to fix.
And that is why I was not too alarmed by today's glitch in the VersaHD that has been photon-beaming me. Although the hardware and software employed in prostate cancer radiotherapy today are orders of magnitude more complex than those of 40 years ago, I am confident they are far safer as well.
