The meeting with CCHIT worked. The FOSS community, to the degree that such a thing is possible, had authorized me to go nuclear on the issue before the meeting. I had been given assurance that the community has been so frustrated with dealing with CCHIT that if they did not work with us that if I started an alternative certification program that I would be backed up with the dollars and brains from the community needed to make an alternative certification go.
At this time it appears that such dramatic actions will be unnecessary. Mark Leavitt and Dennis Wilson were willing to consider the profound practical and cultural implications of the ‘rules’ of the FOSS. These implications are difficult enough for FOSS insiders like me to fully grasp that I realized during the meeting that there is still work for me to do make these problems accessible.
CCHIT has recorded the talk and published it here on their website. I have converted the file to an ogg, for those who care about patent issues in audio files. Contact me if you would like a copy. (its too big to host from this server)
So let’s take a 10,000 foot view of FOSS + Health IT + Certification of any kind.
The first thing to understand is that ‘ownership’ of FOSS projects is spread across all of the users and developers of a FOSS system. The true owner of the copyright involved is usually irrelevant and often impossible to calculate. ClearHealth for instance is a high level LAMP (Linux Apache MySQL PHP) application. Besides needing the considerable portions of LAMP, ClearHealth also makes use of tens or hundreds of sub-projects like smarty, phpgacl, scriptalicious, and adodb.
More importantly ClearHealth contains contributions from probably hundreds of people who have contributed bug fixes, clinical templates or modules. In the case of ClearHealth one company, which wisely has chosen the same name as the project, produces 99% of the core. While ClearHealth Inc. produces the vast majority of the code, there are several other companies, (including my own <- shameless plug) that support the same codebase.
It is not really possible to determine in any consistent way who is responsible for a codebase. Often ClearHealth Inc. employees will take code that I and others contribute on the forums and copy into the code repository in such a way that it appears that a ClearHealth developer wrote the code. The contributors do not care and ClearHealth Inc. does not care. My contributions are meaningless outside of what the ClearHealth Inc. team has given to me, and the license requires that my contribution falls under the GPL. There is no way to determine who truly responsible for a codebase, only to make good guesses.
Under the current certification model I could wait for ClearHealth Inc. to figure out how to pass the current CCHIT tests, and then republish the changes to the current ClearHealth codebase required to pass CCHIT. ThenI could apply for CCHIT certification with my friendly fork of ClearHealth. The real cost of doing the certification is the preparation, which is essentially an annual cost (You do not have to do it annually, but your are at a competitive disadvantage if you do not) of about 300k and which will probably be going up.
So I would be getting a certification for about 1/10th the price that ClearHealth pays.
The problem that is that while we collaborate extensively, ClearHealth Inc. and I still compete for customers. If I can offer support for my certified, re-branded version of ClearHealth without participating in the practical price of certification I would be able consistently undercut the support rates of ClearHealth Inc. This represents a disincentive for ClearHealth Inc. to pursue CCHIT certification.
Now consider the OpenEMR project. This project is made up of about 10 major contributors who all share the development duties. There is no single benevolent dictator and there are several companies with developer commit access. Like WorldVista there is a central non-profit that serves as a focal point for community issues for that project. Both of these non-profits will have trouble coming up with 200k a year for continued re-certification and no participating company is large enough to easily take that role.
The lesson here is that in the FOSS community everyone benefits from good code, not just the original developers. If the ‘Tax’ of certification falls to any one party in the community usually it becomes too great a burden for that party.
Practically, it is also impossible to allow a costless download of a CCHIT certified open source EHR. CCHIT requires CPT codes, (which it should not) and CPT codes are owned by the AMA. It is not possible to distribute CPT codes for no cost without violating AMA copyright.
Take away lessons:
- Under the current model it is difficult to have the cost and benefit of the certification evenly distributed.
- There is no way to easily ‘share’ the certification
- There is no maintainable benefit to being the organization that sacrifices to get a certification for a particular FOSS codebase.
- It is not possible to prevent other organizations to certify a system that has already been certified.
- proprietary ontologies, like CPT, are a problem for the distribution of FOSS EHR systems.
Most of these issues were brought up in the meeting, and CCHIT is listening to everyone. I just wanted to put down these issues all in one place for reference. Feel free to comment on this post with other issues that you feel are central to the problem with certifying FOSS EHR projects.
-FT
Hmmmm,
I’m still not certain what the “FOSS community” that you are speaking of really wants. Due to the nature (as you well describe above) of FOSS development; and the fact that the scripts and requirements from CCHIT are publicly available. Then why isn’t it sufficient (and in fact natural) for the MyFOSSEMR” community to do their own testing using the CCHIT protocols (isn’t this kind of like unit/functional testing anyway?) and then individuals/companies can run these tests and certify themselves.
This PROVES the validity of the FOSS process.
There will be those that claim self-certification via CCHIT but they won’t last long. They will easily be discovered through functionality defects and lack of interoperability. Their lack of integrity will be well noted in blogs and on mailing lists.
Maybe the one thing that CCHIT attorney’s could do is draft a provision for self-certification that will give the individual/company the right to claim that they have self-certified but they they can be held liable to customers and maybe even patients?
This is starting to sound better as I think out loud here. The FOSS application is available, the test scripts are available. The potential customer can do their own verification on all or selected sections of the application.
Let the big commercial vendors spend their money on the CCHIT seal. Small and FOSS vendors can self-certify and put their integrity where the mouth is.
–Tim
Fred, your discussion of certification in FOSS mostly fall into the business case sphere. I would find it interesting for the ‘need’ for certification to also be analyzed. From the CCHIT’s web site, an Introduction … http://ehrdecisions.com/2009/01/14/an-introduction-to-health-it-certification/, it is stated that certification is necessary to deliver on the benefits of electronic health records. Furthermore it is stated that the certification entity is the ‘trusted advocate for the physician community”.
The close linkages between standards bodies and certifications lead to me to believe that certification has other, business objectives as well that are not explicity stated.
It’s all well and good to declare oneself the protector of all things good but the kind of top down spread of assertions is something that FOSS has always had a problem with. The very phenomena of ‘forking’, which has a long cultural history outside of software, especially among societies which value freedom, is more of a bottom up to the middle and then out to side reaction against the inevitable rigidity of top down organization!
FOSS software is, at it’s best, the small upstart business, which exists as a viable niche because of the failures of the larger and more rigid software industry.
So, to the extent that certification does have a business model, and uses money to create a ‘trade association’ of the status quo, there will always be a tension between FOSS and certification.
logistical question: This meeting with CCHIT was a very good beginning. What are we doing to facilitate (formalize?) on-going communications between CCHIT staff and the FOSS community? Are they subscribing to the appropriate mailing lists or RSS feeds or online asynchronous discussion forums? Are they aware of these and how to access them? Will additional synchronous (real-time) discussions like face-2-face or teleconferences be scheduled? How do we ensure they learn more about FOSS HIT and it’s concerns, as they admitted they needed to do, and desired to do?
-keith
@Tim Cook
Along the lines of self-testing suggested by Tim, shouldn’t the Laika project be useful as a standardized tool for certification testing? Perhaps that or something like it could be used for a truly open testing model for verification and validation of EHR testing.
http://laika.sourceforge.net/
-Lorie
@Lorie
Self certification is a model that a few vendors follow, like VMWare, but it is not really successful without a support organization. So what you really need in FOSS is an organization that will promise to make the software compliant (a support organization) to the certification objectives (Of course the real objective is to make the software functional to the end users and perhaps somewhat inter-operable with other software that also claims to be functional – one would hope that if one could achieve such functionality and inter-operability, one would also have no problems being certified and thus self-certification is a reasonable approach).
Thanks for the great write-up, Fred. Your comment on AMA’s copyright of CPT codes especially caught my attention.
As the co-founder of a company building medical coding tools, I am extremely frustrated by the combination of AMA’s copyright on the CPT code set and CMS’s requirement that primary health organizations indirectly purchase multiple copies of an AMA licenses.
This environment clearly stifles to innovation, especially as new high quality & low cost products come to market. The fact that every system a provider uses that leverages CPT codes must pay a licensing fee (EMR + encoder + billing services = $25 x 3/user/year) means that providers are paying multiple times for precisely the same information.
I would like to help raise awareness of this issue, be a part of a coalition to address it, and eventually see an equitable system put in place. Do you know of any efforts to address this issue that I and my organization might be able to contribute our time & voice to? If not, where would you suggest someone start to build a coalition of interested parties?
Thank you for your time and all of your efforts.