FDA: Software Failure Behind 24% of Last Year's Medical Device Recalls 128
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."
Re: (Score:1)
Re: (Score:2)
Programmers have desperately needed the backdrop of legal liability for the last 20 years. Unfortunately, I think the no liability clauses in illegal EULAs will continue unchallenged for quite some time. Whenever I hear the phrase, "tort reform," I always think the opposite of controlling legal liability and instead spreading the misery of lawyers on a variety of fields (mostly software development) until they can perform their jobs to the competency level of McDonald's. My pet peeve though is UI scalabil
What are they doing about the 76% HW failure rate? (Score:5, Insightful)
It seems like that should be of even more concern.
Re: (Score:3, Insightful)
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.
Re: (Score:2)
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.
What you describe are not software failures. If there's something wrong in the code, it's likely a bug. That the wrong software made it through testing and QC and was released may be a failure of process. But a software failure is an event, not a condition.
If the software would do the wrong thing is certain conditions occur, but the software is fixed before those conditions are actually encountered, then there was no software failure.
In my experience there are way way more failures of the development pro
Re: (Score:2)
Hardware can fail for a much wider variety of reasons; poor maintenance, overuse, physical abuse, one off manufacturing defects, etc. Software failures are caused by an error in design or implementation; they are almost guaranteed to be present in every single instance of the device even if it takes an oddball corner case to set it off.
Re: (Score:3)
Re: (Score:3)
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 (d
Re: (Score:2)
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.
How do you add serial complexity to the system without increases the risk of failure? Now you've got to account for failure of the sound-detection process as well as the sound-producing process.
Why not, for example, add a second alarm? With 2 alarms, the system fails only if BOTH alarms fail to sound. With the detection loop, you get an error condition if EITHER the alarm or the microphone fails.
Re: (Score:2)
How do you add serial complexity to the system without increases the risk of failure? Now you've got to account for failure of the sound-detection process as well as the sound-producing process.
Actually, you don't. All you have to know is that one of them isn't working. The goal isn't to have the thing run for as long as it possibly can before failing silently, it's to make sure it doesn't fail silently. If either the alarm OR the microphone fail, the device is no longer dependable so you enter the unit failed state and signal that condition through LEDs and behavior..
Re: (Score:2)
I think I see. It's not about eliminated or reducing modes of failure, it's reducing modes of silent failure.
Re: (Score:2)
Exactly!
Re: (Score:2)
Derating power supplies and such is great, but microphones and light sensors to check on buzzers and lights is quite backwards. Both can be spoofed by ambient noise or light assuming simple to moderate detection models. Cheap, easy, and reliable would be to just measure the current and voltage drop across critical components. Bonus is that you can use one detection method and likely IC for multiple subsystems and that programming it into the software is trivial compared anything else.
The other method of
Re: (Score:2)
Just because 100 - 24 = 76 does not mean that all the other recalls were hardware failures. Sometimes, a device functions well, but it's use is difficult or confusing.
Suppose the device is too heavy for the average nurse to carry, and it can't be used safely. There's no material defect.
Good point (though I might consider "portal device is too heavy" to be a hardware failure).
There are so many links in this chain which can require a field action. Hardware, software, wetware. Typo on a label, instructions doctors aren't able to follow, etc.
Re: (Score:2)
I would expect it is probably all from one company *Cough*Siemens*Cough*
Re: (Score:2)
Where are you getting a 76% failure rate from hardware?
Medical devises can be recalled for reasons other than hardware failure.
76% would be the ratio of recalls not due to Software failures to total failures (though Mcmonkey points out [slashdot.org] that the 24% reported is not found in the underlying report).
A failure rate would be the ratio of the number of failures to total deployments or uses of medical devices.
DMCA? (Score:1)
In response, FDA told Threatpost that it is developing tools to disassemble and test medical device software and locate security problems and weak design
Do we, the patients, have the right to do this, or does it have to go on behind closed doors and NDAs?
In a distopian novel, the government would do this so that they could turn off your heart, if you said anything out of turn.
Re:DMCA? (Score:5, Funny)
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.
Backups (Score:3)
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?
Re: (Score:3)
If the medical company follows a process, and you should hope they do, they will send the equipment back to you in a known good state. Your settings are not part of the known good state even though they are within guidelines. Further, if a new setting is added to the hearing aid, where should they set it? Is setting it to the default compatible to your previous settings?
It's a feature.
PS, a company following a process will do the same thing even if it's something like my tractor. Every time John Deere c
Re: (Score:2)
They have the capability to save the settings most of the time, they just choose not to. Even if the manufacturer doesn't do it, I would expect the audiologist to (in most cases, the audiologist acts as intermediary) without me needing to ask for it. It'd be like them reinstalling Windows if you took your laptop in because the exhaust fan died.
The more technology improves, the more quality control seems to go down the can. I've had more problems with my current set than any other before it. My last set befo
Re: (Score:2)
Re: (Score:2)
Since it's already in the device and they can in theory access it, the liability exists now.
Re: (Score:3)
The more technology improves, the more quality control seems to go down the can.
As a medical professional, I'd say a company that takes in a device on RMA and returns it to a known good, known tested state, is far superior in "quality control" than a vendor who would individualize each service routine.
What you're asking for is exactly why personalized medicine is doomed to fail.
Re: (Score:2)
What I'm asking for is that my newer hearing aids need to be sent in for repair less often, not more often. All of these new features are great, but I need reliability more than I need bluetooth.
Re: (Score:2)
IF the update renders the old settings invalid, it's a feature. Otherwise it's just flushing other people's time and money down the crapper so they can shave a few seconds off of their own.
Analog FTW. (Score:2)
I still use analog ones. Currently Oticon 380p, a bone conduction hearing aid. It only has three rotatory settings and three switches. 380p model was released in 1994 and I had three different sets with that model since Oticon doesn't make newer analog models anymore since everything is digital now. It's easy to reconfigure since the settings are the same and my hearing is stable. They just break down physically after about five years. Headband breaks down faster (three years?). :(
Too bad you can't reprogra
Re: (Score:2)
There's a world of difference in quality between digital and analog, especially if you're like a lot of people and hear better in some frequencies and worse in others (especially higher pitches). However, I never once had an issue with any of my analog hearing aids but the digital ones have to be repaired every 12-24 months.
My biggest beef with the audiologist is that they won't give me a setting for better-than-normal hearing. I figure as long as I'm paying this much money I might as well use one of the ot
Re: (Score:2)
Wow, they break that easily? If I want digital, then I will have to get an implants since I have no ear holes and cochlear. :(
Demand Free Software (Score:5, Insightful)
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.
Re:Demand Free Software (Score:5, Insightful)
Hiding the source code is not an effective way to prevent hacking, if it were my Windows box wouldn't need a hardware firewall, a software firewall, 3rd party antivirus software, and regular sweeps initiated from a different OS.
Re: (Score:2)
He said "review" the software, not "replace" it. That confusion seems to lie at the heart (no pun intended) of all these discussions. There seems to be fear, whether intentionally spread by the manufacturers or not, that if the software was publicly viewable that it would immediately lead to people hacking the medical devices.
And in the short term that's likely to be a valid concern, because the software is so badly written* that an ordinary hacker armed with the source COULD physically attack a victim.
Re: (Score:2)
Why stop at the software ? For a complete review, the hardware design should be open too.
Re:Demand Free Software (Score:5, Informative)
The MRI machine I use has a complete circuit diagram along with design notes in a binder set next to the machine. In the US, you get the hardware manual for service. I don't believe the same is true for Europe and I have no idea about the rest of the world.
Re: (Score:2)
I hope that binder doesn't have metal rings:
http://www.howstuffworks.com/question698.htm [howstuffworks.com]
Re: (Score:2)
You don't get the source code to their software. You probably rely on results of an FDA audit of the MRI vendor. The FDA auditor would look at the validation protocols for the software. If they say they are using a "waterfall" development paradigm, they will go through all the documentation for that and look for evidence of proper code review and sign offs. This is the sort of things auditors are trained to do. Theoretically they could audit and review the vendor's source code - in reality there are pro
Re: (Score:2)
I can tell you one reason based on a conversation I had with 2 doctors. Medical professionals are almost apprehensive about giving "unnecessary" information to patients because it leads to problematic self-diagnosing. Say there's an article in Time about a new disease. They then seen a spike of people coming it with timesmagazinitis, and if patients get fixated on some notion of what they might have, it makes it harder to get accurate information from them; e.g. "I have timesmagazinitis, so the fact that
Re: (Score:2)
Ugh, yeah, I've noticed the age of the Internet has made that worse, too. People erroneously think that medical diagnosis is simply a matter of checking off a bunch of symptoms. "Well, I have 8 out of the 10 symptoms listed for African megalocephalitic herpes! I'm going to die!"
Simple answer. (Score:1)
Capitalism is god. Whether or not the product does as it's advertised is inconsequential as long as the seller gets paid.
As far as your health? You shouldn't have gotten sick in the first place.
Re: (Score:3, Insightful)
Re: (Score:1)
taken from wikipedia:
Code signing can provide several valuable features. The most common use of code signing is to provide security when deploying; in some programming languages, it can also be used to help prevent namespace conflicts. Almost every code signing implementation will provide some sort of digital signature mechanism to verify the identity of the author or build system, and a checksum to verify that the object has not been modified. It can also be used to provide versioning information about an object or to store other meta data about an object.
Where in that statement does it also convey that the software is defect free? Zero bugs?? Look, I'm not even arguing against malware or malicious intent here. Rather that there are few, perhaps even zero, engineers out there qualified to do software updates for all manner of medical devices from different manufacturers if it were done in house. Downloading some "code signed" version from joe schmo does not protect the hospital from fault if the device then malfunctions.
That's my big
Re: (Score:2)
It can be inspected
It can be verified
Patches can be written (and then submitted to the manufacturer)
The idea is not that the little IT captain at your local hospital is going to rewrite the MRI. It's that he's going to run into an issue, pull up the source code, write up a patch, submit it to the manufacturer, then the manufacturer is going to throw it out, force their engineers to write it again, ru
Re: (Score:3)
The open source zealots love these types of comments. It's not a valid solution, and if you allowed yourself to think outside the open source box you're in you might see it too.
Allowing anyone to view the code means anyone can then modify it.
As far as I am concerned, "anyone" can modify it all he wants just as long as he doesn't install it in an in-service medical device without proper approval. If we don't yet have legal, organization, and technical means to prevent this from happening, we should.
We are not talking about opensource software here. We are talking about allowing anyone who wants to to audit a piece of proprietary software.
I do though think that we should restrict access to the text of our laws. Think what would happen if somebody
Re: (Score:3)
Allowing anyone to view the code means anyone can then modify it.
As the Mythbusters like to say, "Well, there's your problem!" Your entire argument is based on the extension of this premise to imply that you can then install this modified software on the medical device. But that's not a given at all. You can modify the downloaded copy of the code that you have squirreled away somewhere in /users/autocannon/src, but it doesn't mean you can modify the exact copy of the code that's running on the CPU in your insulin pump.
It may not even be physically possible. Consider
Re: (Score:1)
In response to both David and plover, what is the device manufacturer's incentive to publish their proprietary source to allow for public scrutiny? There's 3 consequences to allowing that.
1. Process must be established to allow reporting of defects, evaluation of the defect, code correction, unit testing, and finally QA testing. (ongoing costs)
2. Competitors now have full access to all of your device's capabilities. Unscrupulous though it is, they have a competetive advantage as well as the ability to
Re: (Score:2)
I didn't say this was an incentive for the manufacturers to open their source. (f they're basing it on an open source platform that's covered by GPL and not LGPL, they're bound to, but I don't think any medical device maker wants to take responsibility for all of Linux in their devices.) If open source were mandated, however, you still raise valid issues.
Regarding your points, #1 is true regardless of the source. In the case of open source, they would have more sources of input from external people who r
Re: (Score:1)
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?
That's a good idea! We really need people changing the code on their medical devices, that will fix all the problems ...
Re: (Score:2)
As far as the FDA goes I believe they are allowed to inspect actual software and development processes during audits, closed or open source.
As for public review, many devices do include components from other manufacturers that include non disclosure agreements. Many rely upon trade secrets; ie, they're the only company with a new technique that gives them a competitive advantage. Opening this up to public review means opening up to the competitors. I don't doubt that giants like GE (lots of money, bland
devs (Score:1)
Outsourcing (Score:1)
What do you want to bet this company outsourced to save .03% profit and used the cheapest overseas bidder? But the analyst got his bonus. Maybe I am being too cynical but many of these medical companies are the greediest folks imaginable and when all software is viewed just as a cost center the MBAs start doing dumb things based on GAAP rules rather than common sense.
Re: (Score:1)
You're being too cynical. I work for a medical company and I can assure you that the general awareness is that doing things properly has a lower cost than patching things up afterwards. Our devices depend heavily on software and there are no costs being save there. Not much is outsourced.
If figure that there are companies that have a different mentality, but I figure that the majority would operate by this rule.
Re: (Score:2)
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
Re: (Score:2)
Good info, thanks. It raises a thousand more questions in my mind, though, about your quality processes. I would really like to know if your industry has specific mandated or regulated software quality standards you follow, like an ANSI or ISO standards? Or did your firm develop your quality processes entirely in house? Do you use Test Driven Development? Iterative methodologies, such as Agile? Or do you do big designs up front, and hold formal walkthroughs and reviews of those designs?
Do you have stan
FDA should develop an open platform like NSA did (Score:4, Insightful)
Re: (Score:2)
That's just what we need - medical devices and implants with NSA backdoors in them.
It's a matter of trust. I'd trust the NSA not to mess with my medical device far more than I'd trust a random device manufacturer to properly update a medical device over the internet. Only one of these organizations has a well deserved reputation for maintaining secrecy and security. Can the NSA sniff your internet traffic? Undoubtedly. [wired.com] But is someone at the NSA's Panopticon Central actually looking at your data? That's the key: you don't know for sure, and you will never know for sure. That speaks
Re: (Score:3)
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.
Re: (Score:1)
Ours?
Is Linux yours?
Re: (Score:2)
Ours? Is Linux yours?
secure ours, means secure the west's OSs. Linux is just closer to being a secured system, and much easier, than trash would be.
Re: (Score:1)
Linux is the West's OS? Where is it stated in the GPL?
And secure it against who?
What's wrong with you, USA?
Re: (Score:2)
Riggght. The NSA already has enough trouble telling us how many people they are eves dropping on... let's get them officially into the medical gear too!
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2, Informative)
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.
I'm waiting for the day (Score:1)
Re: (Score:2)
It probably already is. But the wireless range is quite short.
I know my wife goes in regularly for reading, and they read it with a magnetic wand that they place on her skin over the device. I believe that they've occasionally added a patch, though I admit I'm not certain about this. (The doctors are not communicative in this area, and may not be knowledgeable. It's hard to tell. They seem to often just be following a guidebook...not necessarily a bad thing.)
Re: (Score:2)
Glad I'm not the only one who noticed this.
That fig. 5 appears after a section addressing issues involving...
..incorrect or missing patient results in a laboratory information system, and incorrect or missing notifications to clinicians that test results were out of range.
Basically, problems with LIMS or other systems. It's not that the device released the incorrect dose, it's that the record keeping system had an incorrect does history or test result, causing a doctor or nurse to administer an incorrect dose.
To /.'s credit TFA does say what the summary says. However the reported linked from TFA does not say anything approaching what's in TFA.
Linked to the wrong re
"locate security problems and weak design." eh? (Score:2, Insightful)
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 tru
Class III devices (Score:1)
Letting me see it as a programmer would be interesting perhaps, but modifiable? Again, no way in hell.
Everyone who gets an implantable cardiac device is by definition trying to die, and likely will from the problem that indicated an implant in the first place.
The potential company liabilities are profound to say the least. Particularly with the sorry state of tort liability in th
Re: (Score:2)
Everyone who gets an implantable cardiac device is by definition trying to die, and likely will from the problem that indicated an implant in the first place.
They are taking a calculated risk in the hope of dying later than they would otherwise. Or am I missing something?
Weak design?? (Score:3)
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.
Karen Sandler (Score:2, Informative)
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/wa
Re: (Score:1)
I listened to that talk, it was very eye-opening. Made me want to contact my senators.
Disassembling the code?! (Score:2)
Why would the FDA have to disassemble the code in the devices? The FDA approval process requires giving the FDA examiners access to the source code, along with design docs, schematics, etc. Why would they need to reverse-engineer a device? Something's not right here.
Re: (Score:1)
Because software validation requires that every state of the machine be tested. Disassembling the compiled code would be another tool to achieve this. Having "source code, along with design docs, schematics, etc" is considered "design inputs." The compiled code is the design output (the actual thing doing something), which is what must be tested. Checking the design inputs is also required, but is not considered sufficient.
This requirement isn't for software. It's for every medical product.
Fro referenc
When Software Attacks (Score:3)
Obligatory THERAC-25 mention. Software has killed before:
http://en.wikipedia.org/wiki/Therac-25 [wikipedia.org]
Heart Terminated Remotely (Score:2)
Karen Sandler has a great talk [youtube.com] about how pacemaker-type devices (she has one) are completely closed-source, nobody (including the doctors who install them) cares, and the FDA doesn't/can't do much more than rubber stamp the software. Most of these devices now have unencrypted wireless access.
sudo kill -9 heartbeat Is a real possibility with these devices.
a really important difference (Score:2)
Where does the report say this? (Score:4, Interesting)
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?
Re: (Score:2)
It's on page 22. It's not spelled out but it seems to be close to that number on the chart. Not sure how they got to the 24% though - in the text they cite 13 removal and recall actions. The closest number of total software attributable recalls would then be 3 - which is 23.07% of 13.
On a side note - is it really that alarming that 3 out of a total of 13 recalled system were due to software error? If anything, it is a surprisingly low number.
Re: (Score:2)
From that section on pg 22:
In collaboration with the inspection team, Ms.Simone identified a trend in customer complaints that the firm had not been aware of. This trend involved incorrect or missing patient results in a laboratory information system, and incorrect or missing notifications to clinicians that test results were out of range.
Basically, problems with LIMS or other systems. It's not that the device released the incorrect dose, it's that the record keeping system had an incorrect dose history or test result, causing a doctor or nurse to administer an incorrect dose.
Similar to the issue discussed here:
http://www.economist.com/blogs/babbage/2012/05/medical-devices [economist.com]
Re: (Score:2)
Don't blame the software (Score:1)
The reason code standards are made is simply because there are programmers who need to have t
a related problem (Score:1)
A major related problem is that hospitals and other organizations get stuck using poorly-implemented devices because they are too fucking expensive to replace with something else. The expense in and of itself isn't totally unreasonable, because manufacturers of medical devices need to comply with a great deal of regulations and safety testing. However, that doesn't help the users any.
The hospital I work at, for example, bought a software suite years ago for our pharmacy and financial departments to use, and
Overly Simplistic (Score:1)