FDA: Software Failure Behind 24% of Last Year's Medical Device Recalls
chicksdaddy writes "Software failures were behind 24 percent of all the medical device recalls in 2011, according to data from the U.S. Food and Drug Administration's (FDA's) Office of Science and Engineering Laboratories (OSEL). The absence of solid architecture and 'principled engineering practices' in software development affects a wide range of medical devices, with potentially life-threatening consequences, the FDA warned. In response, FDA told Threatpost that it is developing tools to disassemble and test medical device software and locate security problems and weak design."
It seems like that should be of even more concern.
It would seem they don't do backups either. Every time I've had my hearing aids sent in for repair, I've had to have them reprogrammed from scratch because they never save the settings first.
I have an appointment to have them repaired again in 3 hours. Any bets on whether its a software issues?
In my experience there is way way more software failures. The vendor just sends software updates every couple months. Oh yeah the previous version had a problem where if you did things in the wrong order it would change the patient that the radiation machine was programmed for. Sorry about that but here is the fix. Or worse notices saying their is a problem so telling users to double check all the time until they release a new version ... sometime.
Can someone please remind me why people should be unable to examine the software in their medical devices, software that their lives may depend on? Why these programs are not open to public review?
Oh wait, I got sidetracked thinking that the point of medical devices is to keep people healthy, rather than to rake in profits for the companies that make them.
Palm trees and 8
Seriously, the smart thing is to develop an Open platform on Linux, with libraries for equipment to use. Likewise, offer up secured ways of updating the equipment. If FDA was smart, they would talk to NSA.
I prefer the "u" in honour as it seems to be missing these days.
Those things can cause hardware failure, but they generally don't cause recalls. Remember that we're talking about device recalls, here. The hardware failures are also likely to "be present in every single instance of the device" if they need to fix all of them.
In a distopian novel, the government would do this so that they could turn off your heart, if you said anything out of turn.
It wouldn't work on politicians or lawyers. They don't have hearts.
Excellent point. I work for a med device company, too, and know for a fact that the cost of a recall and/or patient lawsuits far outweighs any software development expenses. Cutting corners is not considered and the level of design and qualtiy controls is very high.
I would suggest that Billy Gates is absolutely being too cynical. //24 years in the med device business
They might as well just start from scratch then. I used to work for a huge healthcare company and dealt with some of the debacles that these devices cause. "Our device only supports WEP....is that going to be a problem?" Pathetic. Luckily the place I worked was big enough to push them around and do things like force them to implement EAP-TLS, but it was tough going. Then you have all the BS with how the FDA "doesn't allow us to upgrade software without extensive testing", which of course is not entirely true.
These companies are just like every other medical software vendor...for some reason they feel entitled to produce absolutely terrible products that are 10 years behind the rest of the world. I don't know why the medical industry is like this, or why customers put up with it. The general attitude where I used to work was, "OH NO DON'T UPSET THE POOR VENDORS!!". I was like, "aren't we paying them? tell them to fix their product or go to hell". This was true of desktop software, medical devices...everything. They wanted to bring a new system online for tracking blood donations and the software required "act as part of the operating system" privileges. Really? We're going to update our Group Policy which already gives every user local admin rights to allow that too? Why, exactly, would that be? Especially since it's nothing but a database application. Another application we had on the network would crash when our vulnerability scanner would probe its port. The entire piece of software would just die because it got a packet of a type it wasn't expecting. This wasn't an aggressive scan, this was just a probe looking for open ports. I told the department, we can give you a scan exception, but this is not a problem that's going to go away just because we stop scanning your device.
I think the entire Medical IT industry has a day of reckoning coming. The unnecessary proprietary requirements, the poor design, the unreasonable legacy OS requirements, the poor security...it's endemic to the industry. There's this attitude that they want to use IT extensively in healthcare, but not change the workflows of providers in any way (including things like requiring strong passwords). It's not a sustainable model.
So, you think that by TALKING to the NSA, who added a nice security module to Linux, they will put a back door into medical equipment?
If you are going to make wild assertions, you might want to look up what NSA's mission is: listen to other system AND SECURE OURS.
NSA has some of the best security ppl on-board. I would trust them to handle my medical devices, before I continue to trust the idiots at MS and those that use Windows.
I prefer the "u" in honour as it seems to be missing these days.
I like how everybody likes to blame their problems on "weak design" on the part of the developers. That may very well be true, but who is to say what is weak design and what isn't? As a developer, I often find that when beginning a project that has some characteristics that I have never worked with before, that it is almost impossible to find solid established information as to what actually is "strong design." And by that I mean good patterns and practices for a specific applications that really aren't very common. Sure there are a few good basic/general practices to adhere to, but for the most part its each coder for their own. So I wonder, what the hell the FDA things they are going to contribute to a world of code that they likely cant even comprehend? You can sit on the outside and say something like; I require 6 9's of up time, and such and such SLA, and this square brick fits into this hole; but what is done to make that happen will vary infinitely behind the scenes.
If they really want to improve the stability and reliability of the code that supports these systems the need to open up the architecture to the entire community instead of keeping everything closed off for patent reasons or whatever. Obviously the companies that make this stuff are more concerned about their profit margin than they are about the safety of the patients that their equipment is treating. That's my opinion on the matter at least.
IP restrictions on medical devices' source code, no peer review or approval structure in place from FDA or health organisations. Complex medical devices that are implanted in humans bodies, e.g. insulin pumps, heart defibrillators etc. run software and operate more and more like computers. Here is a case of Karen Sandler, a woman who asked to see the code for the device she was to be implanted with to verify that is was safe. And what she discovered in the process.
OSCON 2011: Karen Sandler
www.youtube.com/watch?v=nFZGpES-St8
Riiight... Ever heard of RTlinux? RTAI maybe ? OSADL? You already find it in a lot of cool life/time critical systems already... esp in the defense world.
Obligatory THERAC-25 mention. Software has killed before:
http://en.wikipedia.org/wiki/Therac-25
For hardware, to combat failures you overdesign it. E.g., if it's powered by the AC line, you make sure the power supply components are overrated for their worst case load (derating of parts makes them last much longer).
If there's an alarm, you add a microphone and light sensors to determine that if you're in the alarm state, there is an alarm sound playing and the lights are flashing. You build in extra annunciators as well just in case the LED dies. You count 75% battery capacity as "low battery".
And yes, I've seen those countermeaures actually implemented for a medical device.
Of course, it also impacts software as now it's even more complex as it has to handle and detect these conditions as well
As a developer working for a medical device company, I am very interested in this story.
However, I am not able to find in the linked report either that "24%" figure or the direct quote from TFA.
The Agency is also acquiring expertise in areas like "detecting malware inside device designs...(and) reverse engineering certain types of malware to best identify the specific protective practices which manufacturers should be employing," the report reads.
The word "malware" appears twice in the quoted passage, but not at all in the report. And 24 only appears as a page number or date.
Am I just not hitting CTRL-F right today?
You will find that Linux is everywhere in the aviation and medical arena, except for where DO-178B is required. However, you have bluecat linux that has the same API as Lynx's DO-178B system. In addition, several groups are hard at work on doing DO-178B for Linux.
In the mean time, there are PLENTY of equipment, mainly those using Windows, in which an open platform makes far more sense. And yes, Linux does have more of a real-time OS, than is windows.