<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Embracing the new CCHIT certifications</title>
	<atom:link href="http://www.fredtrotter.com/2009/06/24/embracing-the-new-cchit-certifications/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.fredtrotter.com/2009/06/24/embracing-the-new-cchit-certifications/</link>
	<description>Hacktivist, coding for social change</description>
	<lastBuildDate>Wed, 25 Jan 2012 14:14:05 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
	<item>
		<title>By: Graham Chiu</title>
		<link>http://www.fredtrotter.com/2009/06/24/embracing-the-new-cchit-certifications/comment-page-1/#comment-5338</link>
		<dc:creator>Graham Chiu</dc:creator>
		<pubDate>Fri, 26 Jun 2009 23:12:12 +0000</pubDate>
		<guid isPermaLink="false">http://www.fredtrotter.com/?p=239#comment-5338</guid>
		<description>I&#039;m not reading it like that.  It reads to me as a virtual visit where someone looks over your shoulder while you demonstrate that the system can meet the functional requirements.  No automated suites.

In your scenario, if there is only 1 FTE where the FTE is using the same software, there can be no reason to ask to certify each user.  Certification is for software, and not for users.

Of course the logical follow on is that if CCHIT gets away with this, they will then want to impose a &quot;drivers license&quot; on each doc, where each doc gets certified to use a particular system - renewable yearly of course. Think of the revenue stream that will bring them!</description>
		<content:encoded><![CDATA[<p>I&#8217;m not reading it like that.  It reads to me as a virtual visit where someone looks over your shoulder while you demonstrate that the system can meet the functional requirements.  No automated suites.</p>
<p>In your scenario, if there is only 1 FTE where the FTE is using the same software, there can be no reason to ask to certify each user.  Certification is for software, and not for users.</p>
<p>Of course the logical follow on is that if CCHIT gets away with this, they will then want to impose a &#8220;drivers license&#8221; on each doc, where each doc gets certified to use a particular system &#8211; renewable yearly of course. Think of the revenue stream that will bring them!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ftrotter</title>
		<link>http://www.fredtrotter.com/2009/06/24/embracing-the-new-cchit-certifications/comment-page-1/#comment-5337</link>
		<dc:creator>ftrotter</dc:creator>
		<pubDate>Fri, 26 Jun 2009 15:30:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.fredtrotter.com/?p=239#comment-5337</guid>
		<description>Remember EHR-S is going to be a lot of work for CCHIT. They are going to have to fully automate some relatively complex tests and then provide a standard interface to those tests, that FOSS developers like me are going then write to. Once that has happened, then CCHIT needs to charge on a per doctor basis for the following reasons.

&lt;ul&gt;
	&lt;li&gt;It is the only way to be fair to single Docs. To turn your question around, why should it cost more for a single practitioner than the per-doc cost for a group?&lt;/li&gt;
	&lt;li&gt;CCHIT needs to be able to continue to fund the considerable development required to automated these tests. Granted CCHIT will make more money when docs at a site share an EHR, but compared to the costs of EHR-C, it is still chump change.&lt;/li&gt;
        &lt;li&gt;It is only a &#039;good&#039; assumption that all 5 docs in a 5 doc practice are using the same software. So CCHIT may be certifying 5 separate EHR systems for the group. &lt;/li&gt;
	&lt;li&gt;There is an upper limit here for the EHR-S model. For instance, if there were a group with 200 providers it might be cheaper to sponsor the EHR-C cert for a project &lt;/li&gt;
&lt;/ul&gt;

Now, what I -am- concerned about it the issue of FTE doctor vs mere user. There are many volunteer clinics that rely on hundreds of doctors to participate once or twice a year. These small clinics would go out of business if they had to treat every user as a doctor under the CCHIT EHR-S certification. In fact such a site might only have 1 FTE doctor per year... it just happens to be made up of 100 different individual docs. But these kinds of issues are the kinds of things that I believe CCHIT will effectively address using their workgroup model as they move forward. 

-FT</description>
		<content:encoded><![CDATA[<p>Remember EHR-S is going to be a lot of work for CCHIT. They are going to have to fully automate some relatively complex tests and then provide a standard interface to those tests, that FOSS developers like me are going then write to. Once that has happened, then CCHIT needs to charge on a per doctor basis for the following reasons.</p>
<ul>
<li>It is the only way to be fair to single Docs. To turn your question around, why should it cost more for a single practitioner than the per-doc cost for a group?</li>
<li>CCHIT needs to be able to continue to fund the considerable development required to automated these tests. Granted CCHIT will make more money when docs at a site share an EHR, but compared to the costs of EHR-C, it is still chump change.</li>
<li>It is only a &#8216;good&#8217; assumption that all 5 docs in a 5 doc practice are using the same software. So CCHIT may be certifying 5 separate EHR systems for the group. </li>
<li>There is an upper limit here for the EHR-S model. For instance, if there were a group with 200 providers it might be cheaper to sponsor the EHR-C cert for a project </li>
</ul>
<p>Now, what I -am- concerned about it the issue of FTE doctor vs mere user. There are many volunteer clinics that rely on hundreds of doctors to participate once or twice a year. These small clinics would go out of business if they had to treat every user as a doctor under the CCHIT EHR-S certification. In fact such a site might only have 1 FTE doctor per year&#8230; it just happens to be made up of 100 different individual docs. But these kinds of issues are the kinds of things that I believe CCHIT will effectively address using their workgroup model as they move forward. </p>
<p>-FT</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Graham Chiu</title>
		<link>http://www.fredtrotter.com/2009/06/24/embracing-the-new-cchit-certifications/comment-page-1/#comment-5336</link>
		<dc:creator>Graham Chiu</dc:creator>
		<pubDate>Fri, 26 Jun 2009 05:00:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.fredtrotter.com/?p=239#comment-5336</guid>
		<description>Fred, explain to me please why you agree that $150-300 per provider for EHR-S is such a good idea.

To me that implies for a 5 user site of a FOSS EHR, CCHIT wants to extract $150-300 from each of those 5 physicians.  In which case I have to ask ... what are they certifying?</description>
		<content:encoded><![CDATA[<p>Fred, explain to me please why you agree that $150-300 per provider for EHR-S is such a good idea.</p>
<p>To me that implies for a 5 user site of a FOSS EHR, CCHIT wants to extract $150-300 from each of those 5 physicians.  In which case I have to ask &#8230; what are they certifying?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Fred Trotter on open source and the new CCHIT certifications &#8212; EHR Decisions</title>
		<link>http://www.fredtrotter.com/2009/06/24/embracing-the-new-cchit-certifications/comment-page-1/#comment-5333</link>
		<dc:creator>Fred Trotter on open source and the new CCHIT certifications &#8212; EHR Decisions</dc:creator>
		<pubDate>Thu, 25 Jun 2009 17:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.fredtrotter.com/?p=239#comment-5333</guid>
		<description>[...] Trotter offered his feedback on the efforts in a post entitled &#8220;Embracing the new CCHIT certifications&#8220;: I am happy to say that Mark, Dennis and the other members of the CCHIT team have won my [...]</description>
		<content:encoded><![CDATA[<p>[...] Trotter offered his feedback on the efforts in a post entitled &#8220;Embracing the new CCHIT certifications&#8220;: I am happy to say that Mark, Dennis and the other members of the CCHIT team have won my [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ftrotter</title>
		<link>http://www.fredtrotter.com/2009/06/24/embracing-the-new-cchit-certifications/comment-page-1/#comment-5332</link>
		<dc:creator>ftrotter</dc:creator>
		<pubDate>Thu, 25 Jun 2009 13:39:19 +0000</pubDate>
		<guid isPermaLink="false">http://www.fredtrotter.com/?p=239#comment-5332</guid>
		<description>John,
            I think there can be considerable improvements to the way CCHIT certifies, but they do have a process for change. They are a workgroup driven organization. Before, FOSS was essentially frozen out of the certification process for very fundamental reasons, now I think participants from the FOSS community will be much more common. To discuss your specific complaints, both EHR-S and EHR-M are intended to be much simpler certification models, much close to whatever ARRA &#039;meaningful use&#039; will end of meaning. EHR-C will continue to be large and burdensome for the -people that want that-
            Regarding interoperability, while CCHIT has not done enough, they have created Laika which is probably the most substantial step towards true interoperability, with the possible exception of Mirth and the Connect project. But efforts like that take time. 
 
           Usability is also a good point, and they are considering how to handle usability scoring now. But again, this is a participatory organization. You can volunteer and have a say....

-FT</description>
		<content:encoded><![CDATA[<p>John,<br />
            I think there can be considerable improvements to the way CCHIT certifies, but they do have a process for change. They are a workgroup driven organization. Before, FOSS was essentially frozen out of the certification process for very fundamental reasons, now I think participants from the FOSS community will be much more common. To discuss your specific complaints, both EHR-S and EHR-M are intended to be much simpler certification models, much close to whatever ARRA &#8216;meaningful use&#8217; will end of meaning. EHR-C will continue to be large and burdensome for the -people that want that-<br />
            Regarding interoperability, while CCHIT has not done enough, they have created Laika which is probably the most substantial step towards true interoperability, with the possible exception of Mirth and the Connect project. But efforts like that take time. </p>
<p>           Usability is also a good point, and they are considering how to handle usability scoring now. But again, this is a participatory organization. You can volunteer and have a say&#8230;.</p>
<p>-FT</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John</title>
		<link>http://www.fredtrotter.com/2009/06/24/embracing-the-new-cchit-certifications/comment-page-1/#comment-5331</link>
		<dc:creator>John</dc:creator>
		<pubDate>Thu, 25 Jun 2009 13:18:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.fredtrotter.com/?p=239#comment-5331</guid>
		<description>Fred, interesting to hear that you are now comfortable with the new CCHIT, three-tiered certification process.  Agree with you that CCHIT has certainly made an effort to hear concerns from the market including yourself, other smaller vendors &amp; physicians with RYO solutions. I commend them for such outreach.

Unfortunately, I can not share your support of CCHIT as a certifying org (and this is not just CCHIT, but any certification org that wishes to place a heavy hand on the market) as I still believe the overall CCHIT certification process to be too complex, burdensome and to date has not shown any impact on EHR adoption or improved interoperability for data sharing and care coordination.  Yes, it is not completely CCHIT&#039;s fault as interop depends on how a solution is ultimately configured and implemented, but is that not the point - CCHIT and its certification process, at the end of the day, does not guarantee interop, which leads to the conclusion, so why bother?  

And please, don&#039;t even get me started on usability testing.</description>
		<content:encoded><![CDATA[<p>Fred, interesting to hear that you are now comfortable with the new CCHIT, three-tiered certification process.  Agree with you that CCHIT has certainly made an effort to hear concerns from the market including yourself, other smaller vendors &amp; physicians with RYO solutions. I commend them for such outreach.</p>
<p>Unfortunately, I can not share your support of CCHIT as a certifying org (and this is not just CCHIT, but any certification org that wishes to place a heavy hand on the market) as I still believe the overall CCHIT certification process to be too complex, burdensome and to date has not shown any impact on EHR adoption or improved interoperability for data sharing and care coordination.  Yes, it is not completely CCHIT&#8217;s fault as interop depends on how a solution is ultimately configured and implemented, but is that not the point &#8211; CCHIT and its certification process, at the end of the day, does not guarantee interop, which leads to the conclusion, so why bother?  </p>
<p>And please, don&#8217;t even get me started on usability testing.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

