‘Known Software Bug’ Disrupts Brain-Tumor Zapping(wired.com)
wired.com
‘Known Software Bug’ Disrupts Brain-Tumor Zapping
http://www.wired.com/threatlevel/2009/10/gamma/
4 comments
Seems to me that medical devices should be programmed in the same style as the computers guiding the space shuttle. It's not exciting, but it works and keeps people alive.
I don't think that this is necessary. A medical devices just needs to shutdown if it is about to enter a potentially unsafe state. A space shuttle can't just shut down; it has to keep functioning no matter what. That's a much harder problem to solve, and would create unnecessary development expense. (Though some techniques are applicable; have a safety mechanism that shields the radiation-producer if the two CPUs disagree about a computation. If the two CPUs are running two different programs to calculate the 'next step', then this should prevent many random accidents.)
There was a great article posted about that here a bit back: http://www.fastcompany.com/node/28121/print
Bugs in things that radiation at people make headlines and people tend to remember them. It's called availability bias.
http://en.wikipedia.org/wiki/Availability_heuristic
http://en.wikipedia.org/wiki/Availability_heuristic
All software is faulty.
Most of these sorts of devices (patient-facing medical devices) are divided into two physically separated pieces: the part that touches the patient and the part that interacts with the other device.
In the imaging case, the system that actually shoots radiation at the patient should have a hardware failsafe, opto-coupled i/o, clean power, etc. The software is usually written in C or something on an embedded RTOS. Data processing is usually done in Windows or some flavor of *nix running well-tested software.
Most of these sorts of devices (patient-facing medical devices) are divided into two physically separated pieces: the part that touches the patient and the part that interacts with the other device.
In the imaging case, the system that actually shoots radiation at the patient should have a hardware failsafe, opto-coupled i/o, clean power, etc. The software is usually written in C or something on an embedded RTOS. Data processing is usually done in Windows or some flavor of *nix running well-tested software.
> All software is faulty.
D. J. Bernstein would disagree probably... (yes - I know his soft is faulty too, but his code is a couple orders of magnitude better than 99.999% of other programmers' code and people needed years to find those bugs)
D. J. Bernstein would disagree probably... (yes - I know his soft is faulty too, but his code is a couple orders of magnitude better than 99.999% of other programmers' code and people needed years to find those bugs)
Early on in my career I read about some medical device software and decided that this was not something I wanted to be involved with. The idea of worrying that something I wrote could potentially kill people is not a pleasant one.
Well you could potentially help people too ... :-)
I write medical software every day that is very close to patients. When I see our software (or maybe software I know the intricate workings of) helping doctors save patients, I am happy.
When stuff like what's in this article happens, it is quite disappointing. Luckily none of the projects I've worked on have come close to endangering patients.
When stuff like what's in this article happens, it is quite disappointing. Luckily none of the projects I've worked on have come close to endangering patients.
That was exactly what I told one of my professors. She pointed out that then I would also deprive the users of the benefit.
Never mind that - let somebody really good work on that.
Never mind that - let somebody really good work on that.
Wow.
Why would a bug like that not lead to an instant communication to halt all use of the devices until a patch could be distributed ?
Good thing the couch wasn't driven by a worm-wheel or there would have been no way to pull that person out.
An emergency switch should be independent of software anyway, that's the norm in machining tools, the 'e-stop' circuitry has to be set up according to very specific rules to be approved, you'd expect more stringent controls on hospital equipment.
Why would a bug like that not lead to an instant communication to halt all use of the devices until a patch could be distributed ?
Good thing the couch wasn't driven by a worm-wheel or there would have been no way to pull that person out.
An emergency switch should be independent of software anyway, that's the norm in machining tools, the 'e-stop' circuitry has to be set up according to very specific rules to be approved, you'd expect more stringent controls on hospital equipment.
An emergency switch should be independent of software anyway
Good advice. Essential for things that cut you or shoot radiation at you.
It would also be nice if consumer electronics devices did this. I remember badly reflashing my iPod once; the reflash locked up and the iPod was stuck displaying a message without the backlight on. There was no way to reboot it without waiting for the battery to drain itself (or to open the device up). This took a few days, but I did get it working again.
A simple hardware reset switch would have saved me a lot of time. I don't buy Apple products anymore.
Good advice. Essential for things that cut you or shoot radiation at you.
It would also be nice if consumer electronics devices did this. I remember badly reflashing my iPod once; the reflash locked up and the iPod was stuck displaying a message without the backlight on. There was no way to reboot it without waiting for the battery to drain itself (or to open the device up). This took a few days, but I did get it working again.
A simple hardware reset switch would have saved me a lot of time. I don't buy Apple products anymore.
This apparently does not work when a firmware flash has gone south. I tried the various combinations a million times while waiting for the battery to go flat :)
This type of equipment has many failsafes and lockouts, but clearly the electronic emergency release and radiation door closing didn't work in this case. The scandal is that is was a known bug. Obviously this bug only occurred in a specific scenario, because the clinics are required to test the emergency procedures on a regular basis.
In this case the US regulatory agency, NRC, initiated an investigation and forced Elekta to fix it. It sounds like they assumed it wasn't critical enough from the initial report that all treatments with this model should stop before the patch was distributed (the incident happened months ago).
In this case the US regulatory agency, NRC, initiated an investigation and forced Elekta to fix it. It sounds like they assumed it wasn't critical enough from the initial report that all treatments with this model should stop before the patch was distributed (the incident happened months ago).
As someone who works with software that is audited by the FDA (we build devices to collect data for clinical drug trials), I'm assuming the regulatory agency knew about this issue before the equipment was certified for use. Any bugs that we defer from a product release are documented, and therefore reviewed by anyone that decides to audit the company. We are routinely asked by auditors to explain why certain bugs were deferred prior to release.
The problem with that is that not using the machine can also cost lives.
I'd like to know the software company's side of the story. If the bug is rare enough (half a million people treated successfully so far) and the bug's outcome is not serious, then an emergency upgrade may not have been necessary. What we're missing here are the consequences for the patient in a worst case scenario. What we do know is that this particular patient apparently wasn't harmed (in any way?).
But anyway, I wonder what programming techniques are in use for these devices. They sound like they are very expensive but don't need much computational power, which is a good case for using a very high-level language. It may run slowly, but it's easier to get right. (The Therac-25 was controlled by a complicated application written in a very low-level language. A simple programming oversight which the language made very easy killed several people. Using a higher-level language would have prevented this bug.)