[FLUX-YOU]

>There has to be proven documentation that the software functions correctly and does not endanger people or data.

Regulators are not sitting behind your engineers making sure every line of code is tested though. Documentation in this area would basically be QA documenting testing with pass/fail which is going to be similar in other enterprise projects with a QA department. You get functionality testing with, for example, prescription of controlled substances, but they are not reviewing the code for vulnerabilities or any sort of proof.

In more than one instance, I've seen updates from EMR vendors have needed hotfixes after they find some critical bug. This is pushed to production the next day so even if regulators were reviewing code, they couldn't review it that fast.

>Most hospitals and open source enthusiasts do not have the time, money and expertise to do these things.

The trouble for open source contributors is knowing what the demands of doctors/nurses are. Most EMRs have common functionality but workflows are incredibly varied between hospitals. This is not an industry where the software controls or teaches the workflow. Providers can and often ask for custom stuff built to handle their particular needs at the expense of the code base.

However, once you know these workflows, the code behind them is not that difficult technically for today's tools and methods.

The technical challenges facing certain EMRs today (that I have experience with) are really scaling issues. Most of the enterprise EMRs started a long time ago, so they are running into issues with bad design that needs patchwork fixes. Plus not blocking the UI thread for most operations.

[mmkhd]

Your coments about the application workflow are very true. And I think this strengthens my argument that it is hard for open source software to enter this market. The cosultants/companies that implement these systems for hospitals would have to get together to push open source. And I guess hat it would be very hard to find enough open source developers with the domain specific knowledge. This points to a development style with a single company behind such a software. These companies are often not as "open-sourcey" when it comes to documentation as "real" open source projects. And this would make it less interesting for the above mentioned consultants/companies to band together to push open source because only that single company that mainly develops the software and does consulting for it, would profit.

My comments on software validation were perhaps not as clear as I would have liked them to be. Of course the regulators are not looking at every line of code. It would have to be the buyer that would have to look at that documentation, so that everything is in order when an FDA inspection occurs (if at all). And maybe it is wishful thinking that the developers should take validation into account while developing, because you can only do so much with an operational/functional qualification on site. Perhaps I am thinking that way because I am looking at it from the perspective of a research organization that develops some of its software in house (workflow!). Companies contracting with us certainly do want to see the validation documentation that was produced during development.