<?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: Being Ricky Roma, or Tales from the Dark Side, Episode V &#8211; The Empire Strikes Gold</title>
	<atom:link href="http://histalk2.com/2009/03/23/being-ricky-roma-or-tales-from-the-dark-side-episode-v-the-empire-strikes-gold/feed/" rel="self" type="application/rss+xml" />
	<link>http://histalk2.com/2009/03/23/being-ricky-roma-or-tales-from-the-dark-side-episode-v-the-empire-strikes-gold/</link>
	<description>Healthcare IT News and Opinion</description>
	<lastBuildDate>Thu, 09 Feb 2012 04:50:12 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3</generator>
	<item>
		<title>By: The Good Guys...</title>
		<link>http://histalk2.com/2009/03/23/being-ricky-roma-or-tales-from-the-dark-side-episode-v-the-empire-strikes-gold/comment-page-1/#comment-3815</link>
		<dc:creator>The Good Guys...</dc:creator>
		<pubDate>Sun, 29 Mar 2009 13:36:06 +0000</pubDate>
		<guid isPermaLink="false">http://histalk2.com/2009/03/23/being-ricky-roma-or-tales-from-the-dark-side-episode-v-the-empire-strikes-gold/#comment-3815</guid>
		<description>What DrM is referring to is extremely important.  Medicine is a constantly changing thing, and the regulations around it (and semi-regulations, think Joint Comission) are changing even more rapidly.  So if you are at a (typically big) company with multi-year software builds, by the time the software is done it is already out of date, and your implementation staff is already figuring work-arounds for the current environment, and the software is not even live.

Smaller, more agile companies move with the environment, which aligns the clinicans &quot;what&#039;s in it for me&quot; with the current regulatory, risk, and financial incentives.

John Glaser made some very good comments the other day about the solution to an HIS department becoming more agile, in order to bring more value to the clinicans, patients, and administration at a hospital.  How are you going to achieve this with a product from the dark side on a 3 year release cycle?  

As a clinician I&#039;m looking at the rapidly changing healthcare regulatory environment and changes that the new balance in congress is likely to make, and I&#039;m not looking to the death star for answers.</description>
		<content:encoded><![CDATA[<p>What DrM is referring to is extremely important.  Medicine is a constantly changing thing, and the regulations around it (and semi-regulations, think Joint Comission) are changing even more rapidly.  So if you are at a (typically big) company with multi-year software builds, by the time the software is done it is already out of date, and your implementation staff is already figuring work-arounds for the current environment, and the software is not even live.</p>
<p>Smaller, more agile companies move with the environment, which aligns the clinicans &#8220;what&#8217;s in it for me&#8221; with the current regulatory, risk, and financial incentives.</p>
<p>John Glaser made some very good comments the other day about the solution to an HIS department becoming more agile, in order to bring more value to the clinicans, patients, and administration at a hospital.  How are you going to achieve this with a product from the dark side on a 3 year release cycle?  </p>
<p>As a clinician I&#8217;m looking at the rapidly changing healthcare regulatory environment and changes that the new balance in congress is likely to make, and I&#8217;m not looking to the death star for answers.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: MM</title>
		<link>http://histalk2.com/2009/03/23/being-ricky-roma-or-tales-from-the-dark-side-episode-v-the-empire-strikes-gold/comment-page-1/#comment-3784</link>
		<dc:creator>MM</dc:creator>
		<pubDate>Thu, 26 Mar 2009 00:14:07 +0000</pubDate>
		<guid isPermaLink="false">http://histalk2.com/2009/03/23/being-ricky-roma-or-tales-from-the-dark-side-episode-v-the-empire-strikes-gold/#comment-3784</guid>
		<description>The responses exceeded my expectations.  That was fun.  We should do this again soon. :)</description>
		<content:encoded><![CDATA[<p>The responses exceeded my expectations.  That was fun.  We should do this again soon. <img src='http://histalk2.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bignurse</title>
		<link>http://histalk2.com/2009/03/23/being-ricky-roma-or-tales-from-the-dark-side-episode-v-the-empire-strikes-gold/comment-page-1/#comment-3779</link>
		<dc:creator>Bignurse</dc:creator>
		<pubDate>Wed, 25 Mar 2009 11:10:07 +0000</pubDate>
		<guid isPermaLink="false">http://histalk2.com/2009/03/23/being-ricky-roma-or-tales-from-the-dark-side-episode-v-the-empire-strikes-gold/#comment-3779</guid>
		<description>Reefdiver gets it right - clunky EMR products slow down physicians too much. If products were intuitive and fast, adoption levels would be much higher. Also, it only takes one or two episodes of unplanned downtime to make the entire project fail.

What is needed goes beyond a &quot;hybrid EMR&quot; - it&#039;s a Virtual Care Plan.  Let all products support the patient&#039;s care plan in a virtual space, from every perspective.</description>
		<content:encoded><![CDATA[<p>Reefdiver gets it right &#8211; clunky EMR products slow down physicians too much. If products were intuitive and fast, adoption levels would be much higher. Also, it only takes one or two episodes of unplanned downtime to make the entire project fail.</p>
<p>What is needed goes beyond a &#8220;hybrid EMR&#8221; &#8211; it&#8217;s a Virtual Care Plan.  Let all products support the patient&#8217;s care plan in a virtual space, from every perspective.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: DrM</title>
		<link>http://histalk2.com/2009/03/23/being-ricky-roma-or-tales-from-the-dark-side-episode-v-the-empire-strikes-gold/comment-page-1/#comment-3778</link>
		<dc:creator>DrM</dc:creator>
		<pubDate>Wed, 25 Mar 2009 02:53:20 +0000</pubDate>
		<guid isPermaLink="false">http://histalk2.com/2009/03/23/being-ricky-roma-or-tales-from-the-dark-side-episode-v-the-empire-strikes-gold/#comment-3778</guid>
		<description>I&#039;m reminded of a concept I learned in evolution called &quot;gambler&#039;s ruin&quot;.  The basic concept is that anything that sticks around long enough will eventually fail/die/collapse, because success doesn&#039;t guarantee permanent success, and failure is a one-way sort of thing.

Health IT projects are some of the longest IT projects around, with EMR installs taking 3-5 years, and even longer if you measure from point of conception to goal achievement.  That&#039;s longer than the lifespan of the average hospital CIO (actually 2 lifespans!).  Everything people say is needed is obviously needed to make these succeed, the problem is that there are way to many chances for the project to fail due to calamities outside its control over such a long period of time (budget, change of priorities, loss of champions, change of business needs, vendor or product issues, general mismanagement, etc.).  Until you can get the systems good enough that you can do these quickly and without years of configuration (seriously, are all hospitals/clinics _that_ different?), this will never change because the healthcare market isn&#039;t exactly getting any more politically or financially stable.</description>
		<content:encoded><![CDATA[<p>I&#8217;m reminded of a concept I learned in evolution called &#8220;gambler&#8217;s ruin&#8221;.  The basic concept is that anything that sticks around long enough will eventually fail/die/collapse, because success doesn&#8217;t guarantee permanent success, and failure is a one-way sort of thing.</p>
<p>Health IT projects are some of the longest IT projects around, with EMR installs taking 3-5 years, and even longer if you measure from point of conception to goal achievement.  That&#8217;s longer than the lifespan of the average hospital CIO (actually 2 lifespans!).  Everything people say is needed is obviously needed to make these succeed, the problem is that there are way to many chances for the project to fail due to calamities outside its control over such a long period of time (budget, change of priorities, loss of champions, change of business needs, vendor or product issues, general mismanagement, etc.).  Until you can get the systems good enough that you can do these quickly and without years of configuration (seriously, are all hospitals/clinics _that_ different?), this will never change because the healthcare market isn&#8217;t exactly getting any more politically or financially stable.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Skeptical</title>
		<link>http://histalk2.com/2009/03/23/being-ricky-roma-or-tales-from-the-dark-side-episode-v-the-empire-strikes-gold/comment-page-1/#comment-3777</link>
		<dc:creator>Skeptical</dc:creator>
		<pubDate>Wed, 25 Mar 2009 00:38:25 +0000</pubDate>
		<guid isPermaLink="false">http://histalk2.com/2009/03/23/being-ricky-roma-or-tales-from-the-dark-side-episode-v-the-empire-strikes-gold/#comment-3777</guid>
		<description>RR, thanks for the link and the &#039;clarification&#039; that you didn&#039;t blame 66% of project failures on the vendor...  but you did.  How else were we supposed to interpret your last paragraph?  Your final sentence says it all:   

&quot;Why do you keep paying for, and keep buying, s@#! that don’t work?&quot;

Listen, maybe your experience was selling s@#!, maybe you feel like s@#! for all those BS demos you did, but don&#039;t assume we were all like you and don&#039;t BS us when you &#039;clarify&#039; now that you didn&#039;t mean the 66% failure rate wasn&#039;t all the s@#! software&#039;s fault.

If you want to write a column on how projects can be more successful, that&#039;s a good topic.  If you want to write a column about some bad vendors, that&#039;s fine too.  But quit the broad brush that HIS vendors are lying sacks of s@#!.  We&#039;re not all like your employer.</description>
		<content:encoded><![CDATA[<p>RR, thanks for the link and the &#8216;clarification&#8217; that you didn&#8217;t blame 66% of project failures on the vendor&#8230;  but you did.  How else were we supposed to interpret your last paragraph?  Your final sentence says it all:   </p>
<p>&#8220;Why do you keep paying for, and keep buying, s@#! that don’t work?&#8221;</p>
<p>Listen, maybe your experience was selling s@#!, maybe you feel like s@#! for all those BS demos you did, but don&#8217;t assume we were all like you and don&#8217;t BS us when you &#8216;clarify&#8217; now that you didn&#8217;t mean the 66% failure rate wasn&#8217;t all the s@#! software&#8217;s fault.</p>
<p>If you want to write a column on how projects can be more successful, that&#8217;s a good topic.  If you want to write a column about some bad vendors, that&#8217;s fine too.  But quit the broad brush that HIS vendors are lying sacks of s@#!.  We&#8217;re not all like your employer.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

