certification of FOSS EHRs
Dennis Wilson
We’re updating our policies/procedures for the new certification programs, and would appreciate your feedback on how things should work for when re-certification of health information technology is (and is not) required.
In the past, re-certification was required if there was a “major version” change to a product or application. Minor version updates could be added to existing certification listings by submitting paperwork and attestation to the continuity of functionality.
Going forward we are proposing re-certification is not required for new versions (minor or major). The rationale is that certifications are essentially effective for only two years (e.g. 2011, 2013, 2015), so the amount of time between re-certification has an outer bounds anyway.
There is another aspect to consider here. What happens when codebases split? Whether forking an open source project, or a snapshot of a proprietary codebase is sold, how are certifications for these derivatives handled?
One approach we looking at is:
· reiterating as above, no re-certification required for (minor or major) version changes within the same codebase
· however, if a previously certified project forks, creating a new project, development community and code repository, this new project does not inherit the certification of the original project.
In other words, certification does not propagate across forked projects – it is retained only by the original project.
This would equally apply to (the relatively rare) case of a proprietary code snapshot being sold/given to another organization.
Clearly the re-certification rule wouldn’t apply if a project repository is simply moved from one host organization to another, and no separate line of descent is created. Or if the fork is just a temporary development tactic within a (still) unified development community.
And none of this really applies to the “site” certifications we are expecting to launch next year. The scope of site certifications would be tied to particular provider organizations – not a product or project.
Would be very interested in hearing if you think it reasonable for project forks to trigger re-certification.
dw
Dennis Wilson
Certification Technology Director, CCHIT
Elwell, Tim
Dennis – how do you anticipate this working with the modular certification?
Tim Elwell
"Misys" is the trade name for Misys plc (registered in England and Wales). Registration Number: 01360027. Registered office: One Kingdom Street, London W2 6BL, United Kingdom. For a list of Misys group operating companies please go to http://www.misys.com/corp/About_Us/misys_operating_companies.html. This email and any attachments have been scanned for known viruses using multiple scanners. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. This email does not constitute the commencement of legal relations between you and Misys plc. Please refer to the executed contract between you and the relevant member of the Misys group for the identity of the contracting party with which you are dealing.
fred trotter
Excellent questions. You are striking at the core of the problems associated with certifying open source software generally. The fact that you are doing this is heart-warming, since I think it is final evidence that the relationship between CCHIT and the FOSS community has become healthy. While it pleases me that you are addressing this, I may not have much to offer. Perhaps I can help structure the problem here.
We, as a community need to decide if we want to ask that CCHIT certify in such a way that would A. Allow certification to be the asset of a particular group, or B. Allow certification to transfer along with a codebase, to random third parties.
The possible models are:
model A: certification transfers only from certifying vendor to customer
model B: certification transfers from certifying vendor to customer and from vendor to reseller to customer (like what WorldVista has done so far)
model C: certification transfers from certifying vendor to customer to a user without any relationship to the vendor
model D: certification transfers from certifying vendor to other vendor to customer
To qualify as FOSS, the code itself must work under model C/D... but there is no reason that the certification needs to work that way. It just needs to work in such a way that it is OK that the code works under model C/D. Organizations do not have to donate certification to the community for a codebase to be true FOSS.
The problem here is how we define "forking". All of the modern FOSS EHR systems are modular and configurable with the intent that the software might behave very differently at seperate installation. In some respects this natural customization represents a fork from the core project. In fact these "within project" differences can be much greater than "between company" differences in the same codebase. When I first started the MirrorMed project, to allow me to continue my work on the ClearHealth codebase, I simply downloaded ClearHealth and changed the branding to say "MirrorMed". My instance of the code at that point was much closer to the core ClearHealth project than any single ClearHealth Inc. customer, which all have substancial local config/module changes.
You are saying "fork" from the perspective of merely changes in/between repository, but many projects, like Linux, use a multiple repository model where the "next version" is a dynamic result of the contents of several repositories at a given point in time. In those projects "forking" is really just part of the process and has no implication of "parting ways". So in any case, what we are really talking about is an "approved version" of a codebase that is assigned certification by the organization that payed for the certification process.
I believe that it would be valuable to have certification capable of transfering across forks. But I cannot see how to do that easily. Someone, either CCHIT or the original project owner, must define to what degree a fork can change the code, before its certification must be repeated. At one point, some project OpenEMR members decided to start a new project in Java (OpenEMR was originally written in PHP) and just "borrow" the OpenEMR name for the new codebase. Obviously if a PHP codebase is downloaded, and "forked" by erasing everything and starting over with nothing but the same name... that does not work, certification obviously cannot follow.
CCHIT has made a good decision in avoiding the problem of determining if an EHR has "really" changed. It does not take much though to figure out why they are trying to get out of that business. Do we want to get into that business?
The problem is that the convention of "major" and "minor" version numbers does not actually have any strict meaning, or worse it does have a strict meaning, which happens to be dependent on which software package you are referring to and whether you are "marketing" the next version or "developing" the next version. There is a consensus understanding that major version numbers are for major changes to software architecture and systems, and minor numbers are for minor improvements and bug-fixes. However, there are some pretty substantial real-world deviations from that convention. To make a small list:
Software gets a change in numbering scheme as per Windows 3.x and Windows 95
Software gets a name change that would indicate a major code change... but without a corresponding code change as per Windows 98 and Windows ME
Software abandons numbers altogether but uses names for different versions of the same software Windows XP Home and XP professional
For Microsoft, versioning and marketing are the same thing. Numbers are used internally, but not externally any more.
Alternatively, a project can slowly have a change in versioning. Linux may never get to version three, but it is well understoof that a minor version jump is a big deal.
Also projects can use minor numbers in such a way that the certification should not jump to the next "minor" version, but skip a minor version. For instance the Linux kernel often uses odd minor numbers for development versions. If an EHR did that, then the minor version should not keep the certification.
When you add certification to the mix, and there is an economic incentive to have your software changes considered "minor" changes rather than "major" changes, you can bet that companies/people will begin to abuse the system.
What you need is a fair way to determine what CCHIT or an "enforcing certified organization" (like Medsphere or WorldVistA) will consider a "minor" revision vs. a "major" revision, outside of just having an single decided "certified" version that is maintained by that organization.
For our community I would say that you could simply use lines of code changed. (The way VistA upgrades is more complex than the patches that are applied to other EHR software systems, but a comparable metric could be achieved, perhaps th size of KIDS??), if a project has changed less than 10% between revisions, it is pretty obviously a minor revision. So that might be one valid way that a software base could assure CCHIT that it was not abusing the major/minor distinction.
However, that will only work for people who are comfortable showing CCHIT their code (we certainly do not mind). For the proprietary folks, you might want to make an external measure such as:
If the customer has to pay extra for the upgrade, then it is not a minor revision.
If the software update requires a completely new manual, then it is not a minor revision.
If you have a new manual and you are charging your customers, but you still want to be a minor revision, send CCHIT proof that less than 10% of the code is changing.
Our community would always skip steps 1 and 2 and jump straight to proving that it was a minor change.
If you are going to allow forks, then you have to sort out who is going to ensure that a fork has a "certifiable relationship" to the original codebase. Either the orginization that aquired the certification is going to have to do that, or CCHIT is going to have to do that.
You pretty much have to say something like
"versions of the open source code base that is not -the- approved version blessed by the organization that aquired the certification are not certified"
or
"versions of the open source code base that is not -an- approved version blessed by the organization that aquired the certification are not certified, and the criteria for being an approved version is X,Y, and Z"
In specific answer to your question, I think it is reasonable that certification not transfer to "unapproved" versions of a codebase, if only because sorting out the alternative is such an intractible problem as evidenced by my rambling assesment. I am inclined to just have the "site" version of CCHIT address the "freedom the certify" in our community, and allow vendors and non-profits the privilege to exclude others from the non-site certification process.
Can anyone see a compelling argument, in the context of site level certifications, to -not- reserve the privilege of "approved certified versions" to our non-profit and for-profit companies as competitive advantages? Am I missing something? It just seems like a big mess if you try to do anything else.
Thoughts?
-FT
--
Fred Trotter
http://www.fredtrotter.com