While Ignacio has been taking a hard-line Free Software
approach, I have been (in a twist for me) taking an 'Open Source'
approach. The people who approached me at DOHCS were unanimous in
their belief that what FOSS needed from the government was merely a
level playing field, so that we could compete, and win, on our own
merits.
The largest single threat to the future of FOSS in
healthcare in the US is the certification process mandated by the
stimulus act. The language provides funding for -certified- EHR
systems and eventually penalties for not using -certified- EHR
systems.
The best established certification body is CCHIT. They have
not been named as the certification body, but they are likely lobbying
for that role. However, CCHIT has had an anti-open source stance for
years. For years, I and other activists in the community have chosen
to largely ignore this bias. Simply because CCHIT was an optional
certification. Now, things have changed. It is possible that the
government will mandating a certification program that is either CCHIT
or similarly unfriendly to FOSS.
Recently I submitted my complaints to Dennis Wilson
(associated with both FOSS Laika and employed by CCHIT) who put me in
touch with Mark Leavitt. As a main result of that discussion, Mark has
agreed to have a meeting with the community-at-large about this issue
at HIMSS (please see the forwarded message from the CCHIT e-newsletter
below).
Granted, this is like offering to meet with the Rebel
Alliance at the annual Death Star conference. However, Mark has also
agreed to provide some kind of remote access capability for those of
us who cannot afford the time, cost or moral compromise required to
attend HIMSS.
The meeting will be held at HIMSS on Monday, April 6, Room
10d, Session #2 2:00 – 3:00 PM
I have heard from several of the HIMSS 'regulars' in our
community that they will be going. However, it is critical that we
have a show of force within the community from precisely those people
who have the most to lose with regards to the certification issue:
small support companies and individual consultants.
I am going on vacation next week, so I will be silent on
the mailing lists for a while. Would someone else please take the lead
on coordinating the sharing of hotel rooms, etc etc. If you are
already going and you would not mind 'putting someone up' so that they
could attend this conference, please speak up. I have space for one in
my hotel room starting Sunday. If you live in Chicago and you have a
couch to spare, please speak up.
We are becoming more 'organized' as we speak. Please watch
this space for more announcements on how you can participate to keep
the US government from making anti-FOSS blunders now and in the
future.
Best,
-Fred Trotter
http://www.fredtrotter.com
---------- Forwarded message ----------
From: Sue Reber <sre...@cchit.org>
Date: Fri, Mar 13, 2009 at 3:07 PM
Subject: FW: CCHIT eNews: Seeking volunteers, Expansion,
Interoperability and Open Source
To: fred trotter <fred.t...@gmail.com>
Cc: Dennis Wilson <dwi...@cchit.org>
Fred – see below “Commission Hosts Interoperability and Open Source
Roundtables on Certification” in our regular electronic newsletter.
C Sue Reber
Marketing Director, CCHIT
Certification Commission for Healthcare Information Technology
503.288.5876 office | 503.703.0813 cell | 503.287.4613 fax
--- majority of newsletter removed for brevity ---
Commission Hosts Interoperability and Open Source Roundtables on Certification
In addition to its annual Town Hall at the upcoming HIMSS09 Annual
Conference in Chicago, the Certification Commission will be hosting
two technical roundtables, co-located with the conference, for health
IT vendors and developers. The first, “Interoperability 09 and Beyond:
a look at CCHIT’s roadmap for the future”, will present the
Commission’s interoperability roadmap and explore the standards and
testing tools with which developers need to be familiar.
The second, “Open Source Forum: a dialogue on certification for open
source EHRs”, is designed to continue the discussion with open source
developers with an interest in certifying EHRs. This session will
allow an open exchange of the challenges and opportunities for making
certified open source EHRs available to providers.
The times and locations of sessions are below. Both Health IT
Technical Roundtables will also be available via free remote access.
Details will be available at cchit.org prior to the date.
CCHIT Town Hall at HIMSS09 Annual Conference
Sunday, April 5
Room W192b, McCormick Convention Center, Chicago
9:45 - 11:15 AM
Health IT Technical Roundtables at Hyatt McCormick Conference Center
Monday, April 6
Room 10d, Hyatt McCormick Conference Center, Chicago
Session #1 1:00 – 2:00 PM
Interoperability 09 and Beyond: a look at CCHIT’s roadmap for the future
Session #2 2:00 – 3:00 PM
Open Source Forum: a dialogue on certification for open source EHRs
--- sections removed for brevity ----
Contact : eN...@cchit.org | www.cchit.org
Copyright © 2005-2009 Certification Commission for Healthcare
Information Technology
Privacy Policy | Terms of Use | Contact
________________________________
If you no longer wish to receive these emails, please reply to this
message with "Unsubscribe" in the subject line or simply click on the
following link: Unsubscribe
________________________________
Certification Commission for Healthcare Information Technology
200 S Wacker Dr
Suite 3100
Chicago, Illinois 60606
US
Read the VerticalResponse marketing policy.
Fred -- Thanks for posting this. I have been asked to participate in the CCHIT Meeting at HIMSS during the 2-3pm timeslot. Who else will be participating?
Perhaps we could use this forum to collect, aggregate and consolidate concerns representing various OS community stakeholders and reduce to a White Paper for submission.
Pronunciation: \ˈstāk-ˌhōl-dər\
Function: noun
Date: 1708
1 : a person entrusted with the stakes of bettors 2 : one that has a stake in an enterprise 3 : one who is involved in or affected by a course of action
Anyone who has concern about OS and the impact of CCHIT on the development, distribution, promotion and use of OS EHRs, especially as it pertains to being a “certified” EHRs, falls under stakeholder definition 3.
Relative to your comment that ‘significant community members’ don’t have an interest in FOSS EHRs in the US is <blatantly> incorrect. [I am using hyperbole here because it appears that this is the only way to discuss such matters in this forum – as if all things relative to a purist view of OS are either black or white.] And I am speaking as one of your noted ‘significant community members’ – whatever that means.
Again Fred, you have gone out of your way to divide the various OS constituents. WHY? I am gratified that you are now beginning to use the ‘inclusive’ word in your discussions here. I think this is very important and although there may be differences of opinions, we need to find the things that we can agree on first. No organization can be all things to all groups but there appears to be a symbolic ‘olive branch’ that is being offered by CCHIT and instead of making this a religious argument, can we agree to be pragmatic and look on real ways to ‘level the playing field’ and insure that OS interests are not extinguished or hampered. I believe that OS represents another channel to introduce innovation into an industry that is starved for a better way. I, like you, believe that anything that stands in the way of OS development and distribution and use should be stopped and our reasons for feeling this way may be different – and that’s ok. So if we are concerned that CCHIT may represent a threat to ultimate use and adoption of OS technologies (in this case EHRs), why do we feel that way and what needs to be changed?
A couple of arguments that I have heard include:
Smaller EHR proprietary companies have raised the certification cost as a major concern. (It used to be $28K for Year 1 and then $4.5K for years 2 and 3 – pretty hefty for an OS community project or even a small proprietary company). Is this the major issue for OS development? Might a regressive pricing structure or a proportional pricing based be more appropriate?
OS Projects and contributions are made all the time. OS could not possibly be expected to have to be subjected to ongoing certification costs. Might the governance of the project include version control mechanisms that can track changes and demonstrate that significant re-engineering of the core code has not been made and that re-certification is not required? If recertification is required, might it be contained to the major re-engineering element(s) and charges would be made on a prorated basis.
Others have argued that the criteria needed for certification is overkill for the smaller provider market. Having to include features and functionality into a product that customers don’t want seems to be orthogonal to good product design. Might there be a recommendation that there be appropriate certification requirements based on various market segments and that the market segments have different certification costs? This might be justifiable since it would appear that the cost to certify less requirements is less than a larger, more complex feature and function set.
BOTTOM LINE: What is CCHIT doing that is getting in the way of developing, distributing and using OS EHR solutions? And what do we want them to do to remove the impediment?
CCHIT’s stated mission is to “accelerate the adoption of robust, interoperable health information technology by creating a credible, efficient certification process.” On face value, CCHIT sees value in OS or they wouldn’t be giving us the forum to discuss the matter. OS EHR provides good products and solutions to the market that need to be offered as equal options to providers if there is any sincere desire to accelerate EHR adoption. Certification, by itself, does nothing to accelerate HIT adoption. However, certification that impedes access to these technologies is bad. Let’s work pragmatically to identify the issues and offer reasonable solutions.
Tim Elwell
Misys Open Source Solutions
Main Entry: stake·hold·er <image001.gif>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Open eHealth Collaborative" group.
To post to this group, send email to open-ehealth-...@googlegroups.com
To unsubscribe from this group, send email to open-ehealth-collab...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-ehealth-collaborative?hl=en
-~----------~----~----~----~------~----~------~LS1+LS0tPGJyPg0KPC9ib2R5Pg0KDQo8L2h0bWw+DQo8YnI+DQo=ICZxdW90O09wZW4gZUhlYWx0aCBDb2xsYWJvcmF0aXZlJnF1b3Q7IGdyb3VwLiA8YnI+IFRvIHBv st to this group, send email to open-ehealth-...@googlegroups.com
To unsubscribe from this group, send email to open-ehealth-collab...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-ehealth-collaborative?hl=en
-~----------~----~----~----~------~----~------~LS1+LS0tPGJyPg0KPC9ib2R5Pg0KDQo8L2h0bWw+DQo8YnI+DQo=nI+DQo=
I agree with much of what you have to say, particularly that there is not a single point of view within the OS community (which is OK). However, I think you left out another crucial problem in the current CCHIT process. The OS model is naturally oriented toward component integration (technology stacks from different sources). CCHIT is inherently oriented toward certification of comprehensive (some might say bloated), monolithic systems. Are there any examples of systems with have been certified recently based on integration of components from different code bases?
That is why I believe the emphasis for a "certified" EHRs should, and could be much simpler than the large list of feature-functionality outlined by CCHIT today. Namely, certified systems should be interoperable and allow for the elimination of paper records - specific implementation details (and associated price/performance) should be governed by the marketplace.
I also think it is positive that CCHIT is interested in dialog with the OS community. Perhaps there is common ground out there somewhere.
Jeff Soble
On Sat, Mar 14, 2009 at 10:07 PM, Elwell, Tim <Tim.E...@misys.com> wrote:
Main Entry: stake·hold·er <image001.gif>
Good comments Jeff. Are you thinking that there might be a place for ‘certified components’? If I am tracking with your recommendation, if previously certified components are used, then it will be a matter of ‘certifying’ the integration. Correct?
Frankly, I am of the opinion that certification should only concentrate on the interoperability, safety (including secure handling of information) and integration of components and systems anyway and the ‘customer’ should determine what features are needed in the application. Certifying the chosen components certainly makes the overall argument much more palatable. But, I don’t think that the components should be mandated by anyone. Kinda like buying a car. There are many choices of cars and features. It shouldn’t be mandated that I get the air conditioning and power windows if I don’t want them. However, if I go to the aftermarket to upgrade my headlights to halogens, I want to rest assured that 1.) they will work in my car, and 2.) they won’t create a hazard (i.e. catch on fire), and 3.) it will pass state inspection.
Certainly organizations like CCHIT (and others) can make recommendations on what the optimal ‘stack’ looks like with recommended specified features and functions so that the dizzying array of options are manageable and providers can concentrate on what they are getting reimbursed to do. But at the end of the day, like the UL (Underwriters Laboratories) label, I want to make sure that the integrated product 1.) does what I want it to do, and 2.) is safe.
Tim Elwell
Thanks David for a great overview of what you are hearing. The debate appears to be quite pragmatic indeed. Concentrating on the exchange of information makes a ton of sense. I, for one, am encouraged by the approach and think you are correct that this bodes well for OS and associated innovations. With this as a backdrop for what is going on in Washington, does the discussion we are having CCHIT change?
Thanks David for a great overview of what you are hearing. The debate appears to be quite pragmatic indeed. Concentrating on the exchange of information makes a ton of sense. I, for one, am encouraged by the approach and think you are correct that this bodes well for OS and associated innovations. With this as a backdrop for what is going on inWashington, does the discussion we are having CCHIT change?
"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 tohttp://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
http://www.fredtrotter.com
"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.
Good comments Jeff. Are you thinking that there might be a place for ‘certified components’? If I am tracking with your recommendation, if previously certified components are used, then it will be a matter of ‘certifying’ the integration. Correct?
That all depends. If the certification standard is onerous (as I would characterize the current CCHIT requirements), then certifying components that can handle large chunks of the requirement set "out of the box" might be appropriate. If the certification process is "thin" (as David's post this morning describes), than certification of the integrated system (which utilizes components that may or may not be certified in their own right) makes more sense
Frankly, I am of the opinion that certification should only concentrate on the interoperability, safety (including secure handling of information) and integration of components and systems anyway and the ‘customer’ should determine what features are needed in the application.
Certifying the chosen components certainly makes the overall argument much more palatable. But, I don’t think that the components should be mandated by anyone. Kinda like buying a car. There are many choices of cars and features. It shouldn’t be mandated that I get the air conditioning and power windows if I don’t want them. However, if I go to the aftermarket to upgrade my headlights to halogens, I want to rest assured that 1.) they will work in my car, and 2.) they won’t create a hazard (i.e. catch on fire), and 3.) it will pass state inspection.
Well, again I think the certification of components vs. systems boils down to the scope of the certification process. The larger it gets, the more it makes sense to certify components to handle specific parts.
Certainly organizations like CCHIT (and others) can make recommendations on what the optimal ‘stack’ looks like with recommended specified features and functions so that the dizzying array of options are manageable and providers can concentrate on what they are getting reimbursed to do. But at the end of the day, like the UL (Underwriters Laboratories) label, I want to make sure that the integrated product 1.) does what I want it to do, and 2.) is safe.
Do not worry Tim, I know when you say it, it has its normal meaning
and is used for good!
But so far CCHIT and HIMSS have both embraced all of the
"stakeholders" except for us. So when they say it, I am not sure what
it means.
Also, our culture is not based around "stakeholders", it is a
meritocracy. I do not respect you or Alesha because you are simply
here on this list. I know exactly what kind of excellent work that you
have done and are doing. MOSS has -earned- a seat at the table in our
community. The idea that all voices are equal is simply not the way we
work.
>
>
> Anyone who has concern about OS and the impact of CCHIT on the development,
> distribution, promotion and use of OS EHRs, especially as it pertains to
> being a “certified” EHRs, falls under stakeholder definition 3.
>
I can agree that there are more groups with a legitimate concern. But
at breakfast, it is different to be the pig vs. the chicken. I am
primarily concerned with those in our community that might end up as
'bacon' during this process.
> Relative to your comment that ‘significant community members’ don’t have an
> interest in FOSS EHRs in the US is <blatantly> incorrect. [I am using
> hyperbole here because it appears that this is the only way to discuss such
> matters in this forum – as if all things relative to a purist view of OS are
> either black or white.] And I am speaking as one of your noted ‘significant
> community members’ – whatever that means.
Well said and point taken.
> Again Fred, you have gone out of your way to divide the various OS
> constituents. WHY?
pig vs chicken.
> I am gratified that you are now beginning to use the
> ‘inclusive’ word in your discussions here. I think this is very important
> and although there may be differences of opinions, we need to find the
> things that we can agree on first. No organization can be all things to all
> groups but there appears to be a symbolic ‘olive branch’ that is being
> offered by CCHIT
CCHIT has not offered -anything-, they are merely continuing to talk
to us. There is a very real danger here of being "heard and ignored".
That does not mean I am not thrilled that they are meeting with us,
but that is -only- the first step.
> and instead of making this a religious argument, can we
> agree to be pragmatic and look on real ways to ‘level the playing field’ and
> insure that OS interests are not extinguished or hampered. I believe that OS
> represents another channel to introduce innovation into an industry that is
> starved for a better way. I, like you, believe that anything that stands in
> the way of OS development and distribution and use should be stopped and our
> reasons for feeling this way may be different – and that’s ok. So if we are
> concerned that CCHIT may represent a threat to ultimate use and adoption of
> OS technologies (in this case EHRs), why do we feel that way and what needs
> to be changed?
We need some kind of mechanism to have fundamental compatibility with
the business, people and process of the FOSS community. We need the
flexibility to not have to live with the limitations of a black-box
process. Will Ross in particular has been adamant about fundamentally
improving the process. In short the entire certification process needs
to be subject to the same meritocracy that everything else is in FOSS.
>
>
>
> Smaller EHR proprietary companies have raised the certification cost as a
> major concern. (It used to be $28K for Year 1 and then $4.5K for years 2 and
> 3 – pretty hefty for an OS community project or even a small proprietary
> company). Is this the major issue for OS development? Might a regressive
> pricing structure or a proportional pricing based be more appropriate?
Sounds like an important component for being compatible with our
business community.
>
> OS Projects and contributions are made all the time. OS could not possibly
> be expected to have to be subjected to ongoing certification costs. Might
> the governance of the project include version control mechanisms that can
> track changes and demonstrate that significant re-engineering of the core
> code has not been made and that re-certification is not required? If
> recertification is required, might it be contained to the major
> re-engineering element(s) and charges would be made on a prorated basis.
>
Sounds like respecting our process!!
>
> Others have argued that the criteria needed for certification is overkill
> for the smaller provider market. Having to include features and
> functionality into a product that customers don’t want seems to be
> orthogonal to good product design. Might there be a recommendation that
> there be appropriate certification requirements based on various market
> segments and that the market segments have different certification costs?
> This might be justifiable since it would appear that the cost to certify
> less requirements is less than a larger, more complex feature and function
> set.
One of many-many good ideas about how to really overhaul things in a
positive way!!
> BOTTOM LINE: What is CCHIT doing that is getting in the way of developing,
> distributing and using OS EHR solutions? And what do we want them to do to
> remove the impediment?
I have suggested two entirely different ideas to them, so far..
silence on both.
> CCHIT’s stated mission is to “accelerate the adoption of robust,
> interoperable health information technology by creating a credible,
> efficient certification process.” On face value, CCHIT sees value in OS or
> they wouldn’t be giving us the forum to discuss the matter.
I see no justification for this. I would conjecture that they either
respect us as you suggest or fear us. Either of which I am satisfied
with. Much better than apathy which is how I have been treated in the
past.
> OS EHR provides
> good products and solutions to the market that need to be offered as equal
> options to providers if there is any sincere desire to accelerate EHR
> adoption. Certification, by itself, does nothing to accelerate HIT adoption.
I would argue that -good- certification can improve trust, and
improved trust can accelerate adoption.
> However, certification that impedes access to these technologies is bad.
> Let’s work pragmatically to identify the issues and offer reasonable
> solutions.
Agreed.
This whole discussion is predicated on the assumption that certification serves some purpose. Has there been any study that has shown that CCHIT certification has had any effect on "accelerating the adoption" of EHR's which is CCHIT's mission? One could argue that it has had the opposite effect by forcing companies to spend resources on the certification process that could have gone into product development. Or giving buyers a false sense of security that their certified system will meet their interoperability needs, for example, as I have seen quoted in one article.
Certification doesn't absolve the EHR purchaser from due diligence. Caveat emptor!
And it is so kind of the self appointed CCHIT to deign to meet with the rabble of the OS community at HIMSS. Now that their monopoly is being threatened, they need all the friends that they can get!
Mike Ginsburg