Medical software is a different beast, compared to, say, your next online shop or bloggin plattform.
Bugs in medical software can (and will) kill people. My work takes me to medical software development courses on a regular base and they usually consist of looking at the ways, medical software can kill people; sadly often enough by example.
One case for example was a PACS system where due to a bug in the way the database managed timestamps only the very first of a series of pictures was shown to the user. And since once could not navigate the pictures via "previous" and "next", but one always had to go through a purely text based menu (this was in the mid 1990-ies, where memory was scarse) it was not immediately apparent that only the first image in a time series was shown. Enter the patient with a tumor; when it was finally realized the images the medtech took were not the same the specialist saw it was already too late for the patient and tumor growth progression too far advanced.
So your medical database software kills someone (prescription error due to wrong dataset shown or such), how do you determine whose liability it is/was? Medical software certification is in large part about identifying what harms to a patient could be done and which parts of the software may cause it. You don't even rule out in a "this can't happen" way, but it goes like:
- patient dies: no matter how well it was tested, these are the possible offenders in the program - patient gets seriously harmed: no matter how well it was tested, these are the possible offenders in the program - patient gets injured: no matter how well it was tested, these are the possible offenders in the program
The bottom line is you're ending up with something that is either close to or outright is waterfall.
And even more important: These are the components a program uses, what possible failure modes are there that could harm patients. So they're using CouchDB? Well, is CouchDB medically certified (AFAIK not), so this is considered SOUP (Software Of Unknown Pedigree) which means that to legally use this in medical applications you have to certify the SOUP yourself.
Oh and putting medical records into the Cloud? What could possibly go wrong…
Unless we are talking foolish regulation, FOSS backed by taxpayer development money is likely to produce better and more open, transparent and testable code than proprietary companies competing against each other.
Government regulation perhaps should focus on building automated test suites as a first high level bar.
You cannot just install some software and start putting patient data into it.
Each country has a regulation process how the said software can be used and there are international standards as well.
This area is known as "Electronic Health Record" and "Health information technology" systems
For example, for devices : ISO IEC 62304 Medical device software – Software life cycle processes
I guess this kind to enforce on an Open Source projects with "open contributions".
It's important to remember that EMRs are there to support healthcare professionals who are used to working with incomplete / incorrect information all the time. For example, a patient isn't going to have a drug dispensed to them without a pharmacist checking it (and, frequently, asking the prescribing doctor to clarify/amend questionable doses or instructions).
That is indeed the case (medical record software not being classified as a medical device software product in Europe). However medical record software has been added to also be covered some ISO 80xxx standard. However in the USA medical record software is considered a class B or even class C medical product by the FDA, depending on if the software is used just for record keeping or actively used for therapy planning.
I'm assuming there'd need to be a services business installing and maintaining the software, and adding improvements particular customers need.