<?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: Readers Write 6/8/09</title>
	<atom:link href="http://histalk2.com/2009/06/08/readers-write-6809/feed/" rel="self" type="application/rss+xml" />
	<link>http://histalk2.com/2009/06/08/readers-write-6809/</link>
	<description>Healthcare IT News and Opinion</description>
	<lastBuildDate>Tue, 22 May 2012 14:25:13 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3</generator>
	<item>
		<title>By: former co-worker</title>
		<link>http://histalk2.com/2009/06/08/readers-write-6809/comment-page-1/#comment-4489</link>
		<dc:creator>former co-worker</dc:creator>
		<pubDate>Thu, 11 Jun 2009 13:01:33 +0000</pubDate>
		<guid isPermaLink="false">http://histalk2.com/2009/06/08/readers-write-6809/#comment-4489</guid>
		<description>I worked with Mike Q. at the publicly traded company and have also worked at privately held companies.  I concur with his thoughts.  Publicly traded companies focus so much on the short term earnings targets at the expense of client service.  The executive decision making is all about managing quarter to quarter results.  I think it would serve the public well to move more towards financial reporting every 6 months for publicly traded companies.  It wouldn&#039;t cure everything, but it would hopefully allow management to make better long term decisions and allow them to focus more on service / partnerships.</description>
		<content:encoded><![CDATA[<p>I worked with Mike Q. at the publicly traded company and have also worked at privately held companies.  I concur with his thoughts.  Publicly traded companies focus so much on the short term earnings targets at the expense of client service.  The executive decision making is all about managing quarter to quarter results.  I think it would serve the public well to move more towards financial reporting every 6 months for publicly traded companies.  It wouldn&#8217;t cure everything, but it would hopefully allow management to make better long term decisions and allow them to focus more on service / partnerships.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Unfrozen Caveman CIO</title>
		<link>http://histalk2.com/2009/06/08/readers-write-6809/comment-page-1/#comment-4487</link>
		<dc:creator>Unfrozen Caveman CIO</dc:creator>
		<pubDate>Wed, 10 Jun 2009 20:14:41 +0000</pubDate>
		<guid isPermaLink="false">http://histalk2.com/2009/06/08/readers-write-6809/#comment-4487</guid>
		<description>Very good feedback.  I appreciate your comments.

My experience is SOA has a very low total cost of ownership.  They are easy to write and modify.  Once written they don&#039;t change unless the ancillary system is upgraded or replaced.  We added a developer but he does much more than SOA.  In fact, he has trained our want-to-be developers into SOA developers.  It is a good path for those with some development experience.  Much easier than training them to migrate to OO programming and the MVC framework.  MVC is a real challenge for those moving from other frameworks.

I have a group on LinkedIn called SOA in healthcare IT.  Not very active but I&#039;m looking for people with an interest to contribute.  Check it out at:

http://www.linkedin.com/groups?gid=1705517</description>
		<content:encoded><![CDATA[<p>Very good feedback.  I appreciate your comments.</p>
<p>My experience is SOA has a very low total cost of ownership.  They are easy to write and modify.  Once written they don&#8217;t change unless the ancillary system is upgraded or replaced.  We added a developer but he does much more than SOA.  In fact, he has trained our want-to-be developers into SOA developers.  It is a good path for those with some development experience.  Much easier than training them to migrate to OO programming and the MVC framework.  MVC is a real challenge for those moving from other frameworks.</p>
<p>I have a group on LinkedIn called SOA in healthcare IT.  Not very active but I&#8217;m looking for people with an interest to contribute.  Check it out at:</p>
<p><a href="http://www.linkedin.com/groups?gid=1705517" rel="nofollow">http://www.linkedin.com/groups?gid=1705517</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: DrM</title>
		<link>http://histalk2.com/2009/06/08/readers-write-6809/comment-page-1/#comment-4482</link>
		<dc:creator>DrM</dc:creator>
		<pubDate>Wed, 10 Jun 2009 16:03:55 +0000</pubDate>
		<guid isPermaLink="false">http://histalk2.com/2009/06/08/readers-write-6809/#comment-4482</guid>
		<description>I agree completely on your point of a CDR not being great for translational; most CDRs are designed to do patient-based queries (one pt at a time) and optimized for that purpose, but most reporting is population-based (multiple patients), and those two don&#039;t really mix well.  I should have been more specific, we&#039;re actually planning on the population-based data repository, and (second, if we get the funding) a regular CDR for risk mitigation reasons.

It also makes sense to me that it would be less expensive.  Would be a great case study, but hard to find a good place to get the comparative data.  A fully operational CDR would cost us about $2M in hw/sw and other things, whereas a database that can run slowly if need be and where big queries are scheduled is &lt;$500k.  SOA is pretty capital cheap.  Neither of these is brain-cheap, though, and so that cost could go up if you&#039;re supporting both.  You shouldn&#039;t be doing both for the same reasons, though, so I&#039;m not sure it would go up by much, you just need extra SOA ppl in addition to DBAs, but probably fewer DBAs.</description>
		<content:encoded><![CDATA[<p>I agree completely on your point of a CDR not being great for translational; most CDRs are designed to do patient-based queries (one pt at a time) and optimized for that purpose, but most reporting is population-based (multiple patients), and those two don&#8217;t really mix well.  I should have been more specific, we&#8217;re actually planning on the population-based data repository, and (second, if we get the funding) a regular CDR for risk mitigation reasons.</p>
<p>It also makes sense to me that it would be less expensive.  Would be a great case study, but hard to find a good place to get the comparative data.  A fully operational CDR would cost us about $2M in hw/sw and other things, whereas a database that can run slowly if need be and where big queries are scheduled is &lt;$500k.  SOA is pretty capital cheap.  Neither of these is brain-cheap, though, and so that cost could go up if you&#8217;re supporting both.  You shouldn&#8217;t be doing both for the same reasons, though, so I&#8217;m not sure it would go up by much, you just need extra SOA ppl in addition to DBAs, but probably fewer DBAs.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Unfrozen Caveman CIO</title>
		<link>http://histalk2.com/2009/06/08/readers-write-6809/comment-page-1/#comment-4474</link>
		<dc:creator>Unfrozen Caveman CIO</dc:creator>
		<pubDate>Tue, 09 Jun 2009 22:23:32 +0000</pubDate>
		<guid isPermaLink="false">http://histalk2.com/2009/06/08/readers-write-6809/#comment-4474</guid>
		<description>DrM

My experience is that using web services to get data  and using a seperate data store specially designed for clinical and financial decision support has a lower cost and lower total cost of ownership than the CDR model.

That may sound odd.  However, hardware costs of a CDR and redundant hardware AND the cost of maintaining a highly accurate, highly available structured, transactional database are the key drivers to the higher cost of a CDR.</description>
		<content:encoded><![CDATA[<p>DrM</p>
<p>My experience is that using web services to get data  and using a seperate data store specially designed for clinical and financial decision support has a lower cost and lower total cost of ownership than the CDR model.</p>
<p>That may sound odd.  However, hardware costs of a CDR and redundant hardware AND the cost of maintaining a highly accurate, highly available structured, transactional database are the key drivers to the higher cost of a CDR.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Unfrozen Caveman CIO</title>
		<link>http://histalk2.com/2009/06/08/readers-write-6809/comment-page-1/#comment-4473</link>
		<dc:creator>Unfrozen Caveman CIO</dc:creator>
		<pubDate>Tue, 09 Jun 2009 22:14:01 +0000</pubDate>
		<guid isPermaLink="false">http://histalk2.com/2009/06/08/readers-write-6809/#comment-4473</guid>
		<description>DrM,

Good feedback.  An alternative view is that a CDR does not make a good clinical and financial decision support system.  We are building a data store specially designed for translational queries.  The advantages are 1) queries run much faster and thus make decision support analysis much more interactive, 2) queries can be run any time and don&#039;t degrade the performance of clinical transaction queries, 3) data integrity issues are little concern as the differences should be &quot;noise&quot; and statistically insignificant, 4) lower cost than a CDR - no need for the high-level of redunancy required of a single-point-of-failure clinical system.

Good discussion.  A key reason I visit HIStalk is to interact with others on the nuts-and-bolts of healthcare IT.</description>
		<content:encoded><![CDATA[<p>DrM,</p>
<p>Good feedback.  An alternative view is that a CDR does not make a good clinical and financial decision support system.  We are building a data store specially designed for translational queries.  The advantages are 1) queries run much faster and thus make decision support analysis much more interactive, 2) queries can be run any time and don&#8217;t degrade the performance of clinical transaction queries, 3) data integrity issues are little concern as the differences should be &#8220;noise&#8221; and statistically insignificant, 4) lower cost than a CDR &#8211; no need for the high-level of redunancy required of a single-point-of-failure clinical system.</p>
<p>Good discussion.  A key reason I visit HIStalk is to interact with others on the nuts-and-bolts of healthcare IT.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

