Medical Devices: The Therac-25 (1995)
sunnyday.mit.edu
Medical Devices: The Therac-25 (1995)
1–10 of 20 posts
Re: Medical Devices: The Therac-25 (1995)
#2Re: Medical Devices: The Therac-25 (1995)
#3Re: Medical Devices: The Therac-25 (1995)
#4http://web.mit.edu/6.033/www/assignments/rec-therac25.html
The Leveson paper is quite long, and not all parts are equally important:
Skim Sections 1 and 2. You should understand the basics of the Therac-25's design and how it was used. (You may also find this figure a helpful accompaniment to Figure 1 on page 4.)
Skim Sections 3.1-3.3, which detail a few of the Therac-25 incidents.
Read Sections 3.4 and 3.5. These detail a particular incident, the software bug that led to it, and the response to the bug. Pay close attention to 3.5.3, which describes the bug.
Skip Section 3.6. (It describes an additional incident and a different bug—feel free to read if you are interested, though)
Read Section 4 closely.Re: Medical Devices: The Therac-25 (1995)
#5I also think that we should be careful in trying to draw too much caution in what we do from this accident--the majority of software (EHR systems, apps, etc.) being developed in the medical field today would not be served by the sort of scrutiny that would've prevented this accident.
In fact, one could (and I will) make the argument that simply having faster release cycles and better customer interfacing (instead of, say, custom consulting work coughEpiccough) would cause a better increase in quality than some insanely rigorous pile of paperwork.
Re: Medical Devices: The Therac-25 (1995)
#6https://news.ycombinator.com/item?id=8374345
The Therac problem was a result of states getting out of sync and into an undesirable configuration. I think reading about the machine and then the above Carmack will cause one to see the connection.
Re: Medical Devices: The Therac-25 (1995)
#7Re: Medical Devices: The Therac-25 (1995)
#8I've always taken that machine as a argument against event driven programming. Why? Well John Carmack articulated the problems very nicely when he wrote about inline code, covered on HN here: https://news.ycombinator.com/item?id=8374345 The Therac problem was a result of states getting out of sync and into an undesirable configuration. I think reading about the machine and then the above Carmack will cause one to see…
It is mentioned almost summarily in the report - "Designs should be kept simple" is a phrase in there - but I think that this excessive complexity was one of the biggest factors.
This Hoare quote is relevant: "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies."
Re: Medical Devices: The Therac-25 (1995)
#9http://tinycast.in/2015/01/27/therac-25/
I used this PDF as one of the primary resources and it was a fascinating read.