[x0x0]

I worked on similar software that ran on Windows, though the decision was made 18 years ago. It was driven by:

* GUI dev tools were an order of magnitude better than under linux

* nidaq (very common daq and dio cards) didn't have or had flaky linux drivers. usb may be a better choice today but was not then available. Plus it's convenient/less expensive to push functionality to the computer side and minimize embedded development.

* in the beginning (though we fixed this mistake), we shipped software, our machine, and a ni-daq card; users provided a computer. This was a nightmare. We ended up shipping whole computers custom built by Dell to our specs with ni-daq cards installed (and later glued in to prevent them slipping out during shipping) plus our custom system images. At the time, I don't think Dell would do this for linux; you could find other vendors that would, but they weren't easy to work with or much more expensive.

* Nobody is eager to switch OSes because every software update to the machine has to be FDA certified (ie kiss at least $100k goodbye), so the company is very risk averse. Beyond even the cost to rewrite what has evolved into a relatively complicated gui app.

* As mentioned elsewhere, once you leave windows you have to train people to use linux guis that historically had window managers / gui toolkits that didn't work like windows.

All of the above is complicated by the fact most of these medical device companies pay their devs shit and have trouble hiring good devs. (Engineering shortage, obviously!)

[tremon]

every software update to the machine has to be FDA certified

Interesting. Does that imply that every Windows update Microsoft releases has been FDA-certified already?

[icegreentea]

I don't know how it works out for stuff used during surgery, but for diagnostic devices (where if a device fails by becoming inoperable, the stakes are a lot lower), you can lump basically any software that you don't have total control and design history on (so this includes random proprietary software and most FOSS stuff) as "software of unknown providence" (SOUP).

Now based on the class of medical device you are developing, you can either get to use SOUP without justifying at all, or you have to explain/justify why you can use SOUP at all.

For example, even if your OS was Linux, because you don't have formal documentation on verifying that Linux infact does all the things its suppose to do (hell, does Linux even have a true spec?), you would then have to justify why you're using Linux. If a kernel update comes out, you then have to justify why you're using it.

What you WOULD have to do is verify/validate that your software that interacts with SOUP (so in this case running on an OS) still works correctly. You would not have to verify/validate the OS update per se.

[HeyLaughingBoy]

His characterization is not quite accurate. FDA does not certify it; rather, the company building the medical device certifies to the FDA that it has been properly validated for use and the FDA accepts their validation.

Trust in the company's ability to properly validate the device is tempered by regular FDA (and other regulatory bodies) audits of their development process and process data, test reports and a general desire to stay in business. FDA can and will take your product off the market if it appears to be unsafe and the company does not respond appropriately.

[x0x0]

Yeah, you have to create a testing/validation procedure and run the procedure with your hardware and software. So for human diagnostic devices, we had to purchase samples and basically show that we diagnosed to our prescribed accuracy levels. So there's a bunch of wetlab time/disposables involved.

Our machines were actually purchasable in two ways: one certified for human diagnostics (FDA Class III, I think), and one not, for eg veterinary or scientific use. The former got 1-2x/year software updates, while the latter got monthly releases. We had to enforce usage requirements both with contracts, download restrictions, and in-machine checking. ie you couldn't use the non-diagnostic firmware or software on a diagnostic-certified device. You also had to use certified reagents -- enforced in hardware -- in diagnostic devices.

It's a lot of work, but given some of the software I've seen, and the fact that if these machines get the diagnosis wrong you either won't be treated for deadly diseases or will be treated in very toxic ways for diseases you don't have, the requirements are reasonable.