Edit: It would be interesting to see more open source collaboration. Maybe you do not see it that much because all the people that have the expertise do not work for the hospitals but get snatched up by the vendors? Maybe you do not see that many start ups enering this sector because while individual contracts are lucrative there are fewer customers around than for consumer apps/products?
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.
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.
The main issue for more OSS is that for pure software-based solutions (i.e. not the software of a medical device), the biggest cost for an hospital is usually maintenance, not the license, since (obviously) the hospital will want someone responsible for any issue and ready to fix it right away. This is a cost that is more difficult to share with others.
This is at least my experience with Italian public healthcare, which may be much different from the US market.
At least there is a lot of work on open protocols and interoperability [1], which is good because it can be another good way to reduce costs (by reducing lock-in).
That actually seems like it would make OSS more competitive, not less. The ability to sell services and maintenance contracts really lowers the barrier to open-sourcing your software. When the main thing that customers are buying is your company's expertise with the software, the barrier for releasing your software open source is much lower, and you can reap the benefits that come along with that.