Hacker News new | ask | show | jobs
by pdkl95 3700 days ago
Is it going to take more deaths to convince people to learn from the Therac-25[1]? If you aren't designing for safety first, you have no business working on medical devices or anything else that might be a dangerous when it misbehaves.

[1] http://sunnyday.mit.edu/papers/therac.pdf

1 comments

I am not the parent poster, but may I ask why is this comment being down-voted? I'm not speaking for the parent, but he or she seems to be implying that medical equipment with anti-virus software with automatic updates (used as such) may potentially compromise a patient's safety, and may be indicative of further bad design practices, which could result in, at worst, death. Is this somehow off-topic, or not worthy of discussion?
That's exactly right. The article mentions that the doctors were fortunate enough to have five minutes during which they could reboot the device. If they were in the middle of some other procedure that had tighter time constraints, a reboot could have easily killed the patient.

Just like the Therac-25, this isn't about a single problem (the antivirus or the race condition in the Therac-25's software). Designing for safety has to happen at all levels of design. Using Windows (or Linux, or any other complex OS) in a medical device shows that the designer wasn't even considering the safety of major parts of their design.

Designing medical devices with an OS that can be infected with malware (and thus need an antivirus) is the same kind of idiocy that puts a car's steering and brakes on the same CAN bus as the music player and emergency radio. It's a sign that the designer needs either more education or a different job before someone is injured or killed.

Because it's really disingenuous to say that the medical device industry hasn't learned anything from Therac 25. The concept of two-fault failures is an industry standard that was learned from Therac.

The fact is that in the Medical software industry the best practice is to manage the entire software configuration of the medical device. Failing to do so, and especially failing to adhere to the guidelines of the manufacturer, is negligent at best. We all know that the behavior that led to the hazard is the wrong thing to do and that somebody screwed up.

The only other real insight that can be gained from this incident is that it's very important to have configuration management procedures that are easy to follow, and it's important to verify that they were correctly followed. I can't tell whether they were in this case, but I suspect given the use of Off-the-shelf software that there was some manual sequence of steps required to adhere to the approved configuration. Given that, I would have expected an error of this magnitude, because it's well known that humans make mistakes whenever they are made to follow a sequence of steps. The configuration should have been verified at installation time, at least.

If you're interested in the kinds of things the industry has to consider in the US, take a look at the FDA guidance for the 510k submittal process.