Slashdot Mirror
Hope For FOSS In Electronic Health Records
Fred Trotter writes "CCHIT is the dominant Electronic Health Record certification body in the US. It is also decidedly anti-FOSS and has been for years. Certification of one kind or another will be required for EHR systems to qualify for funding under the Stimulus Act. If CCHIT is chosen as the certification body, and the current certification strategies continue, it will not be possible to have a funded EHR that is both certified and truly FOSS. Now, however, CCHIT has agreed to meet the FOSS Health IT community at HIMSS 09 to address this issue." We discussed the shortcomings in the stimulus bill as it relates to FOSS a few days back.
I see a bigger issue here than the scam this particular group is running.
As I understand it, the stimulus bill allocates $17B to help hospitals across the country pay for medical record systems. Think about that number, $17 Billion.
There is absolutely no reason to distribute $17 Billion to a long list of organizations to individually license an EMRS. For far less than $17B the Federal government could buy any medical record system in the world to be deployed wherever and whenever they want at a fraction of the cost. Or, alternatively, for a lot less than $17B they could sponsor development of a standard, open source EMRS that could, again, be deployed by anyone who wants to at a fraction of what it would otherwise cost.
Obviously there are costs associated with deploying these systems, but the current "plan" amounts to a giveaway of $17B to Semens, GE and whatever other companies produce "certified" EMRS.
The problem is that the model breaks when the software environment breaks because of fees to make the software useful.
Requiring a certification isn't part of the normal software process or model. It's actually an add on that isn't necessarily needed but has advantages. If the model was changed and the vendor certified the software in house to pass a third party review and the customer had to cover the expense from a third party verification service, it would be the same model and nothing would be broke. But no where else in software, do you have to pay someone in order for your software to be used unless your licensing someone else' product. Of course if your licensing someone else' product and they don't want it open sourced, you can't open source your product that contains theirs.
And something you should note, it's only a problem currently because of the outrageous costs associated with certification. If the costs were lower and more reasonable, the problem disappears. It's disingenuous to associate the problems with the FOSS model or commercializing FOSS software without pointing to what broke it. It isn't like many other software packages ever require third party certifications that require large sums of money either. And of those that might, the sums generally aren't as outrageous and ongoing like this.
Something the poster didn't mention that could negate most all of his fears and black out the point you raised is that they could certify the software under a trademark name and do the releases with the normal name. This would lock the certification into something only he could use. For instance, he likes the program MirrorMed. Now he can create a company called Trotter inc. and certify MirrorMed as "Trotter's certified MirrorMed" software. He then distributes it under that name "Trotter's Certified MirrorMed" and distribute his code as MirrorMed. No one else could claim MirrorMed was certified under his certification because they couldn't use his trademark "Trotter's certified" in the name of the product even though he distributed the code and the certification is in his trademarked name.
In short, the certification would be locked to the "trotter's certified" which is the over package he provides instead of just the software MirrorMed. He could control this because MirrorMed itself as a name wouldn't have been certified. Now the code would have technically been certified so everyone else wanting to do the same could certify it themselves without fear of it failing, and most likely they would certify it under their own trademarked name too.
Disclaimer: I work in this industry.
To be blunt, CCHIT is among the least significant and cheapest of the regulatory considerations in healthcare software, particularly when you're talking hospital-caliber systems. Far more onerous are the FDA regulations and oversight (at this level, healthcare software is regulated as a medical device), and similar bodies in other countries. Software bugs can also create enormous legal risks; malpractice or wrongful death claims are never cheap, and bad code or human error does not get you off the hook. All of this means enormous testing and documentation costs, shared by both the software companies and the hospitals. (The VA, as an arm of the federal government, enjoys some legal advantages over other hospitals in this regard.)
Combine this with the enormous complexity and the domain expertise required to model what can occur in a hospital, and you have a market with a very high cost to enter - not the best opportunity for open source. Indeed, there's been several highly-capitalized and failed attempts to enter the market by tech giants ...
That said, most modern healthcare software contains and uses healthy quantities of open-source code, but generally not of the GPL variety. We regularly contribute to the projects we use, inasmuch as our employment contracts permit. However, generally speaking, these projects are not specifically healthcare oriented (though there are exceptions - hapi is a personal favorite.)