Slashdot Mirror
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."
maybe coders need PE powers and rules.
Make so they have to sign off and give them to power to say NO to boss about doing a rush job.
It seems like that should be of even more concern.
But think about how much money the accountants saved by outsourcing the work? The company saved .005% profit! What could possible could possible go wrong
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.
All ideas^H^H^H^H^Hprocesses in this post are Patent Pending. (as well as the process of patenting all postings)
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
I told them not to take Microsoft Dev's...
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.
http://saveie6.com/
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.
My Pacemaker becomes Flash Updateable or "We found a bug in your Pacemaker, come in for a minor procedure to upload the fix."...just DEAR GOD don't make the fixes downloadable via wireless.
...in bed
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.
That's just what we need - medical devices and implants with NSA backdoors in them.
Time to rethink the whole object-oriented thingy.
I looked through the report linked in the article and failed to see support for the opening claim of the article:
"Software failures were behind 24 percent of all the medical device recalls in 2011"
The closest thing I found was a figure 'fig 5' which has no explanation in the surrounding text. It shows a bar graph that looks close to 24% for 2011, but it is not clear if this is "all medical device recalls" for that year, or if it is just the recalls related to the company that is described in that section (they were being audited by the FDA, and it sounded like they had a pretty bad quality system process).
Am I missing something obvious in the report? I'm interested to know if this is accurate, because I had always been under the impression that medical device recalls were almost always a result of hardware/manufacturing issues. I've worked as a software engineer at a couple of med tech companies and can't think of a single instance at either company where there was ever a recall as a result of software defects.
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.
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.
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!
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. 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 volumes for their security, and is a better reputation than these device manufacturers have.
Besides, the NSA has much less incentive to mess with your devices than other organizations, such as the FBI, FDA, police, TSA, etc. Just because one organization can doesn't mean the others get to.
John
lets put the blame where it belongs -- on the people that write/test the software. sure, it is nice to blame this ambiguous 'software' thing. that way, no one made a mistake. that damned softwares brokes it.
The problem is that most of the time the vendors are not accountable, i.e. have no penalty, for delivering crap. There is no incentive for them to have a product sit for too long in the q&a or engineering lab.
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.
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.
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 the US.
Peace is easy to achieve, just surrender. Liberty is much harder get/keep.
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.
Listening on communications, is a different issue than securing a box.
I prefer the "u" in honour as it seems to be missing these days.
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
For many devices, Linux is a non-starter. Linux is not a real-time OS, which is typically a requirement for any life-sustaining device.
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.
You really have no clue what you're talking about. The technology isn't the problem, it's the process and people by which the technology is created that's the problem. I'm am so sick of f'ing platform-fanbois thinking their tools are the answer to every problem. Maybe if you spent a little more time seeking to understand you would get a clue to the big world outside the computer sandbox.
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
I would expect it is probably all from one company *Cough*Siemens*Cough*
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
It isn't hardware in the sense most slashdoters think. The vast majority is not electronic. Even less has software. Medical device means anything that is used with patients that isn't a pharmaceutical. Bandaids, catheters, hip implants, scalpels, beds, oxygen masks, and so on.
Recalls can occur from design defect or manufacturing defect. Design defects can range from just plain bad design to misjudging the conditions something might be used under to printing labels with typos or incorrect color. If the potential for unintended harm exists, it get's recalled. Manufacturing defects range from making something from the wrong material to out of spec parts to screw ups on documentation of a batch.
Since 99% (yeah, I'm pulling that number out of my ass) of medical devices have no software, the concern is devices with software need to be recalled an order of magnitude more often.
Because most of these devices don't use an OS. The software is more like a calculator than a pc. The smart thing to do is to avoid your suggestion like the plague.
Ours?
Is Linux yours?
And watch that % go down.
And don't tell me I'm pulling that out of my butt when their % is just as much BS.
Karen Sandler has a great talk 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.
___________________ I want to be free()!
Pretty much all PC software, tablet app, or other piece of software has a EULA that says "if this breaks your OS or PC or anything, you can't sue us." With software embedded in medical products, it's FDA law that you can't do that. So, write the equivilant of a Toyota Prius acceleration glitch into your pacemaker and it's lawsuit time and you're going to lose. Maybe they should take some of that 1000%+ profit margin on medical equipment and put it into hiring programmers who actually know what they're doing.
I worked on a medical device, an IV pump. One that didn't make it to market, thank the heavens.
What did they use as their OS? Windows CE. Even though it SPECIFICALLY says not to use it in mission critical, medical, or nuclear applications. Right on the box. How in the world could you read that and think "Hey! That doesn't apply to me! In she goes!"
So. My job was to write code into the bootloader. If CE crashed mid-operation (oh yeah unlikely I know) the bootloader upon reboot would recognize a bolus in progress and continue that process until complete. All in ASCII on the bootloader screen before CE reboots.
I still have nightmares thinking about this horrible kludge being plugged into someone's veins. I am SO glad this product never saw the light of day. It's the first time my code actually stood a decent chance of killing someone.
Posting as AC for obvious reasons.
Let me guess, the next step is for the FDA to recommend a "solution", such as expanding its charter or creating another agency to dictate software engineering practices, provide licensing for "critical" software and mandate occupational licensing for software developers.
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 reprogram without the audiologist (unless you're one). That has to be annoying! :(
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
https://www.youtube.com/watch?v=5XDTQLa3NjE&list=PL98382D6677F8E2D4&index=1&feature=plpp_video
Karen Sandler gives a talk about this topic, at linuxconf.au 2012.
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?
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 process than software failures. Why would this be so, given that one process failure can lead to multiple software failures? Maybe we (and out consumers) are just lucky.
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.
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.
Well, you are somebody who does not work in the medical equipment industry. Most today, and all that have 'SOFTWARE' failures, have an OS.
Actually a majority of product recalls are related to labeling issues.
Keep in mind, we are not talking about actual product failures, those are rare. We are talking about product recalls. A product gets recalled because the company can't adequately _demonstrate_ that the product is safe to use. This often times is related to documentation practices. Loss of product traceability is a huge deal. If you have a product in the field and you cant say exactly when it was made, by who, and with what materials (supplier lot number and date of manufacture for every component of that device) you have to recall it. It may function perfectly but it is still out of compliance. Furthermore, things like 'user dissatisfaction' ie a doctor having to pull to hard to open packaging, can be (in some cases) grounds for recall... (not super likely admittedly, but possible).
25% due to software problems is amazing to me, though of the 4 medical device companies Ive worked at over the last ~8 years none have had any software components. You are required to do a validation of any software that has anything to do with your product or _quality system_. Some companies go so far as to validate Excel spreadsheets used to calculate process averages (no macros, just a plain old spreadsheet).
For those of you interested Code of Federal Regulations chapter 21 is where the regs are housed:
http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm
Well, you are also somebody who does not work in the Avaiation OR Medical equipment industry. Many of the issues are not the upper code, but the OS code that is so poorly written that it requires constant change. The best thing is to get a fairly solid OS, with a solid library, and then update about once a year.
Also, as one that has worked on both FAA AND FDA, I can tell you that you have NO FUCKING CLUE of what you talk about. When MS was approached to do DO-178B (which would work for both Aviation and Medical), they said see us in about 3 weeks. When we called back, they were laughing and said not a chance in hell could any of their OS's make. So, when you punk platform-fanbois shut the fuck up and allow the adults in the room to develop. It is idiots like you that push Windows crap and make a disaster not just of business software, but also of aviation and medical world.
BTW, the reason for approaching MS to have them make their OS secured and decent, was because Airbus wanted to use more Windows in their planes. At this time, as the saying goes, if it ain't boeing, I ain't going. Airbus. What a fucking joke.
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.
I prefer the "u" in honour as it seems to be missing these days.
17 years in the industry. And most devices don't use an OS. They used embedded stuff made as simple and robust as possible.
But your point holds merit. Failures are much more common when there's an OS (and the stack of software that goes with it). Which is why OS's are avoided if at all possible.
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.
1. I didn't say anything about Windows. I said platform fanbois, which would include anyone who thinks platform X is a solution for everything. 2. Most medical devices, especially implantable ones, don't run on an OS... they run on embedded firmware. God help us all if people like you are programming airplanes and medical equipment.
You obviously have no clue of what you are talking about. There is an increasing amount of medical equipment that comes out of GE, HP, etc. that does NOT use firmware, but uses Windows OS with SOFTWARE in it. The fact that you have no clue about it, only tells me that you are a total idiot windows coder that has no grasp of the situation. BTW, I had years of working on z-80 assembler, 68000's, and then moved up to embedded RTs. What I have seen is that idiots like you moved in and have ZERO clue of how to code your way out of a bag. The industry has been pushed by PHBs to use Windows, which is the WORSE OS possible. Sadly, FDA has plenty of idiots, as does other companies (airbus comes to mind).
As I said, it is actually better to come up with a secured open OS, make it solid, and add in a number of SOLID open libraries. This will NEVER come from MS. And it will NEVER come from idiots like yourself.
Linux is the West's OS? Where is it stated in the GPL?
And secure it against who?
What's wrong with you, USA?
Are you joking that there trying to blame the software structure and the design? That is so much bull I can smell it from here. A good programmer doesn't need over structered code design and over engineered software solutions. Blame who's really responsible, blame the craptasktic programmers who can't do there job. Programmers who needs strict structure and standards to program need to change professioins.
The reason code standards are made is simply because there are programmers who need to have there hand held and be treated like a 5 year old.
Thank you for accpet low price for hi quarity device make. ~China
Thanking you 1000 times for 5 Rupee/hr firmware coding job. ~India
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 hardware protection I prefer is just straight redundant systems where the redundant unit initiates a separate set of alarms once activated. For example, if a buzzer fails, the switchover triggers a backup buzzer plus flashing lights or error messages on display.
Companies like GE, HP, and a few others have walked away from firmware and use WIndows HOPING that a powerful processor will cover RT issues. Then they HOPE that the lower stacks are solid, which NOTHING out of MS ever has been. It is long past time for us to switch to a well-known open stack that is solid, with a large number of solid libraries.
The real problem is that PHBs have taken over companies like GE and HP who have an MS salesperson attached to the front of their pants and basically fired the engineers to keep them from overriding their horrible choices.
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 about a year ago it was rolled out to all other departments in our transition to electronic records. This software is some of the most clunky, ham-fisted crap I've ever seen. We despise the software for a great number of reasons (not the least of which is that it actually takes 2-3x LONGER to do anything than it did with our old paper records), and with the push to get all hospitals and medical offices using electronic records, something better would be most welcome. Unfortunately, with what we paid (and continue to pay) for the software contract, there's no budget to get something different and probably never will be because as far as the board is concerned it does what we need it to do.
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 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.
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..
I think I see. It's not about eliminated or reducing modes of failure, it's reducing modes of silent failure.
Exactly!
Looks like there were at least a couple of other medical device developers in this discussion, but for the rest of the readers here suggesting "open source", it's just not as simple of a solution as that. There are no standard hardware or software platforms that could be used across the board for medical devices, or should there be. The hardware and software needs of a glucometer are completely separate of those for a CAT scanner. The term "Medical Device" is much too broad and applies to many disparate systems to think in that fashion.
On another note, it is worthwhile to remember than some of the medical devices that are in use in the field (and generate these complaints) are probably quite old. Yes, there have been failures associated with software, hardware, or human factors issues, however complaints associated with devices that have been in constant use in the field for 20+ years comprise at least a portion of this. Have these devices met their goal of reliability? Absolutely. Do these devices meet the current regulator's expectations for new devices (reference IEC 60601 series for basic safety, EMC, software design, usability, home use, etc)? Not necessarily. Is the expectation that medical device companies recall these devices so that hospitals are forced to buy a newer updated version of these devices? Risk analysis (see ISO 14971) wouldn't necessarily agree with this (depending on the failure modes) as an instant recall or end of support or not selling the consumable (if there is one) would result in the hospital's (or long-term care facility, or home user) inability to use the device until it can be replaced. Yeah, there could be ways to avoid or minimize this, but I'd be willing to wager there are millions of "old" devices (20+ years old) in active use in the field and there would be a definite impact to cost and a disruption to many users if this were the approach.
Final thought: Not surprised the idea of Linux comes up on Slashdot as a solution. Linux has been discussed by many development teams that I've been a part of. However, the 'ol Validation question always comes up. Not that Linux has never or will never be used on a device, but the cost of validating it becomes a much larger question (and cost) than either designing your own simple OS built specifically for its purpose, or purchasing an off-the-shelf "validated" OS. Many devices don't even really need an OS due to the device's simplicity (in the sense of what the average Slashdotter would think of as an OS), so the idea of Linux for everything is a bit off. Note: When I say Validation, I mean meeting the expectation of the FDA 21 CFR 820 as well as ISO 13485. There are more specific requirements depending on the device type/classification, but those are the starting points.