Free Software, a Matter of Life and Death 197
ChiefMonkeyGrinder writes "Software on medical implants is not open to scrutiny by regulatory bodies. Glyn Moody writes: 'Software with the ability to harm as well as help us in the physical world needs to be open to scrutiny to minimise safety issues. Medical devices may be the most extreme manifestation of this, but with the move of embedded software into planes, cars and other large and not-so-large devices with potentially lethal side-effects, the need to inspect software there too becomes increasingly urgent.' A new report 'Killed by Code: Software Transparency in Implantable Medical Devices' from the Software Freedom Law Center points out that, as patients grow more reliant on computerized devices, the dependability of software is a life-or-death issue. 'The need to address software vulnerability is especially pressing for Implantable Medical Devices, which are commonly used by millions of patients to treat chronic heart conditions, epilepsy, diabetes, obesity, and even depression.' Will making the source code free to scrutiny address the issue of faulty devices?"
Crowd sourcing your Quality Assurance department? (Score:3, Interesting)
Double-edged sword (Score:3, Interesting)
Making the code available for scrutiny is a double-edged sword. Sure, it might help to catch critical bugs in the software faster. But with some devices, it really raises a host of new issues. Some pacemakers out there are configurable wirelessly once they are in the patient's body. This is actually a very critical feature. But do you want to risk everyone being able to reverse-engineer the protocol used for adjusting the settings for such a device? A wrongly configured pacemaker can be deadly. Right now these things are fairly secure because they are rather rare and not interesting enough as targets for hacking.
Besides, proving that some piece of code works as intended (or at least fails gracefully in all circumstances) in an essentially uncontrolled environment is quite a feat. Embedded equipment is hard to service, has to have a longer hardware lifespan than normal hardware, is often custom designed for a single application and thus may have subtle hardware defects not reproducible on similar test systems... oh, and who says that the compiler or even the CPU is bug free? This is all common knowledge around here, but I just want to give the full list. What this means is that just opening the source code might not cut it. The validation would have to be performed on the hardware it was designed to run. So, where's the call to open up the hardware design and documentation to public scrutiny as well?
How about software escrow? (Score:1, Interesting)
With rigorous testing and regulation, I don't worry too much about a device while the company that made it is still thriving, but what if the they go out of business?
I propose that the FDA require all design data for "complex" devices, including the software" be placed into some form of escrow so it can be released if the company goes under.
The code is going to do you a whole lot of good .. (Score:4, Interesting)
Really. Finding security holes in software that runs on a plain vanilla PC is one thing, finding the cause of glitches in the nanosecond range on an embedded system is another thing entirely.
Re:Same article different day (Score:3, Interesting)
Running out of pills is one thing.
Having your pace-maker shut down due to non-compliance with an EULA is quite another.
Sure, corporations can make a killing...but it will come with a murder conviction.
I seriously doubt it would EVER be legal to remotely disable a pace-maker.
After Therac-25, there is no excuse (Score:3, Interesting)
Then some numbskull decided, "Hey, let's let the software handle the safety interlocking, and we can cut down on hardware manufacturing costs!" The result was the Therac-25 [wikipedia.org], which maimed and killed people.
After the machine was recalled, someone finally sat down and did a real analysis of the code, and found a whole raft of problems and bad assumptions. Nancy Leveson wrote the definitive report [mit.edu] (PDF) on the failures in the R&D processes that made the Therac-25 so deadly.
Yet, armed with this warning (among many others), both manufacturers and purchasers keep human lives as transactions on a double-entry ledger. It simply comes down to, how many deaths per thousand uses are "acceptable"? Manufacturers and medical facilities already have so many costs. Is it worth it to add on the cost of formal code analysis?
But nobody will ask the Therac-25 victims and their families.
I decided early on in my I.T. career, that I didn't want the stress of people's lives depending on my correct code. I hadn't had any training in formal verification. In hindsight, I see my worries would have come from incompetent management, more than from myself.
Re:Makes sense (Score:3, Interesting)
The cheap Chinese copies made from the "open to scrutiny" plans are probably not going to be as safe as the Boeing originals.
Re:Same article different day (Score:3, Interesting)
do you really want to have a corporation that you have absolutely no control over to be in control of a device that sustains your very life?
I'm glad my eye implant [slashdot.org] is mechanical and doesn't have any software.
medical devices are tested extensively before being deployed
I'm damned glad of that, too, but as it was only approved three years before I had the surgery, I do worry that the struts might break twenty or thirty years down the road. OTOH, I wouldn't have wanted to wait until I was 70 to have it; it's an acceptable risk to me.
Re:Makes sense (Score:3, Interesting)
I almost totally agree. Most parts are made to be replaced as a module. When's the last time you replaced the bearings in a hard drive, or soldered a pin on a memory stick? But, sometimes we do, and that's without the assistance of technical schematics.
A few months ago, I was given a hard drive to fix. The machine had been hit by a power surge, and a chip on the control board (the one on the bottom of the hard drive) melted. I replaced the board, and the drive started working again. Normally I wouldn't have touched it, but there's a long back story on it, and I didn't want to send them off for a very expensive hard drive recovery. Even still, I could have opted to replace the chip, rather than replacing the whole board.
In my car (4th gen TransAm), the headlight motor stopped working. Normal procedure is to replace the motor. The better fix is to replace the worn gear with a better one, which involves dismantling the defective component. GM doesn't provide documentation on doing that.
I know with aircraft, if it's not done the "right" way, the FAA gets a bit upset. I'm not an aircraft mechanic, but I'd suspect if you cracked open a modular component and swapped a piece of the inside, they would be less than entertained.