drbowen wrote on Friday, December 18, 2009:
Dear Rod,
There have been separte discussions about this with Dennis Wilson of CCHIT. The peculiar nature of open source causes a lto of trouble with traditional definitions of “ownership” because most of these rules were by proprietary software owners for proprietary software owners. CCHIT is trying to address these differences. To my knowledge HHS has not addressed this specifically but perhaps Dr. Brody has additonal information on this.
This is the final working version of the language that is being proposed by Dennis Wilson:
Seems like a good point to summarize conclusions, and say thanks to all
who shared your opinions. It is important to us these policies are
workable and fair to all segments of EHR suppliers.
Overall, it sounds like most of you believe the policy, as proposed, is
workable. For you convenience, here again is the statement in question:
“CCHIT will indicate the version of the technology that was tested on
our Website, however, once technology is certified, applicants may, at
their option, notify CCHIT when new versions are released and request to
have their version information updated on the Website. CCHIT will allow
subsequent versions of a certified technology to be marketed as
certified as long as the applicant has not removed capabilities needed
for compliance with the certification criteria. For technology offered
under an Open Source licensing model, the organization or community
submitting the technology for certification shall be responsible for
determining and enforcing its own policy regarding labeling of
subsequent versions of the technology as certified.
Applicants who would like multiple listings of 2 or more versions of a
technology on the CCHIT Web site may request this using the Product
Update Form and submitting the required fee…”
In going over all the responses I wanted to respond to a couple of
comments:
Regarding clarification of who are “applicants”: the organization or
community submitting the application for certification, paying the
certification fees, and signing the certification agreement. All of
these details are described in the Certification Handbook available at
our website.
The comments about publically providing access to the project and change
history (for purposes of transparency of continued conformance) are
good. We can easily accommodate that within the descriptive fields of
certification listings. Turns out we’re overhauling our records
publishing process right now.
Keep in mind the whistle-blower process as well, for helping ensure
continuity of conformance.
Regarding comments about equality between COTS and FOSS applicants, our
goal is for the policies to be fair to all - including those providers
developing their own solutions. From a careful reading of the above,
hopefully you see the terms about versions and derivations apply equally
to all. The only reference to Open Source is clarifying applicants are
the ones to indicate which subsequent versions are certified. The
additional listing procedure is actually something COTS vendors have
used to get “private labeled” versions of products into the
certification listings.
The series of comments about incremental certification prompts me to
mention one of the features of the Preliminary ARRA certification
program is the ability to incrementally add more of the 28 Meaningful
Use categories to an existing certification. Doing it this way prices
out a bit higher than certifying those same MU categories in one shot,
but incremental certification does accommodate growth in functionality
over time.
Finally, there were some interesting questions posed about end-users
modifying certified products, and whether this would still qualify for
ARRA incentive payments. Seems (to me) if a provider can demonstrate
meaningful use to HHS then this case would still be in the spirit of the
rules. That, however, along with many other questions about how
providers will report their meaningful use data are to be sorted by HHS.
Again, thanks to all for the thoughtful feedback. Very helpful to us.
I’d like to solicit your responses again by starting another thread (in
a couple of days) about pursuing benefactors for funding FOSS EHR
certifications.
cheers,
dw
This is obviously still an area of flux. Dennis Wilson is sensitive to and a proponent of open source software. CCHIT is under fire from HHS and may possibly be replaced. There may eventually be more than one certifying body.
My recommendation would be that the non-profit Open Source Medical Software make this application to CCHIT and be responsible for maintaining this list. I think $1,000 for a CD is probably not going to be very well accepted. I do think this is a situation where registration of a practice using OpenEMR is no longer optional but mandatory. This is the only real way to keep track of these “certified installations”. This is obviously something that will need to be discussed by the Open Source Medical Software board.
In terms of ownership of the software, I for one have encouraged software developers to either retain ownership of their intellectual property rights or to donate them to the non-profit. Either way we have been requiring the use of the General GPL license version 2. (Version 3 is also acceptable).
I proposed that practitioners that are in the business of actively using and testing this type of software be allowed to get the incentive payments even though they are using unstable versions of the software. This would include physicians such as Brady Miller, Michael Brody, Mark Leeds, and myself to assist in the active development of this type of software. I think that this type of physican involvement in our project is one of the things that makes OpenEMR so unique.
My organization has budgeted the $35,000 for the certification fee. Eventually, as the non-profit Open Source Medical Software gets financially stronger it should take over future certifications. There is some legal risk in taking over this responsibility. This is one of the purposes of the Open Source Medical Software, to allow this type of activity to happen and to protect the individual developers from legal action.
Sam Bowen, MD<br>
http://openmedsoftware.org/