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.