<?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: Homegrown EMR</title> <atom:link href="http://www.kevinmd.com/blog/2007/11/homegrown-emr.html/feed" rel="self" type="application/rss+xml" /><link>http://www.kevinmd.com/blog/2007/11/homegrown-emr.html</link> <description></description> <lastBuildDate>Tue, 14 Feb 2012 17:14:00 +0000</lastBuildDate> <sy:updatePeriod>hourly</sy:updatePeriod> <sy:updateFrequency>1</sy:updateFrequency> <xhtml:meta xmlns:xhtml="http://www.w3.org/1999/xhtml" name="robots" content="noindex" /> <item><title>By: Anonymous</title><link>http://www.kevinmd.com/blog/2007/11/homegrown-emr.html#comment-81822</link> <dc:creator>Anonymous</dc:creator> <pubDate>Sat, 17 Nov 2007 21:05:00 +0000</pubDate> <guid isPermaLink="false">http://clients.emmense.com/kevinmd/2007/11/homegrown-emr.html#comment-81822</guid> <description>Anon 7:42&lt;br/&gt;&lt;br/&gt;In theory you are right.  However the EMR that I last worked with was homegrown in a leading organization at a cost of nearly 100 million over several years.  While it promised to do all those things you talked about in the future--the future was never today, and what actually happened is that it was simply the same paper chart data available on a screen that used to be in a manilla folder. &lt;br/&gt;&lt;br/&gt;The only real advantage was that most of the army of record clerks (it was a large multisite system) could be fired and the information delivered with greater consistency.&lt;br/&gt;&lt;br/&gt;For the solo practioner, all of that could be provided just as well with a simple system such as he uses.  How many people really need to link billing and medical records so tightly?  How much is that worth for solo practioners and small groups?  There are efficiency costs as well as benefits and the decision is an individual business decision for each practice.  &lt;br/&gt;&lt;br/&gt;Another issue is privacy.  Hundreds of thousands of data breaches have been documented and health care is not immune.  Depending on  the  specialty, it may be a major factor.  If one backup offsite, one has only the promises of the business one deals with to ensure privacy.  If one doesn&#039;t back up off site, you lose on of the major advantages of digital for the small office.&lt;br/&gt;&lt;br/&gt;The more complex the system, the greater the number of software and hardware vendors involved, the greater the risks of loss of privacy, loss of data access, expense of upgrade, etc.  An inhouse system composed of well documented classic components may be more reliable and resiliant because of it&#039;s greater simplicity.</description> <content:encoded><![CDATA[<p>Anon 7:42</p><p>In theory you are right.  However the EMR that I last worked with was homegrown in a leading organization at a cost of nearly 100 million over several years.  While it promised to do all those things you talked about in the future&#8211;the future was never today, and what actually happened is that it was simply the same paper chart data available on a screen that used to be in a manilla folder.</p><p>The only real advantage was that most of the army of record clerks (it was a large multisite system) could be fired and the information delivered with greater consistency.</p><p>For the solo practioner, all of that could be provided just as well with a simple system such as he uses.  How many people really need to link billing and medical records so tightly?  How much is that worth for solo practioners and small groups?  There are efficiency costs as well as benefits and the decision is an individual business decision for each practice.</p><p>Another issue is privacy.  Hundreds of thousands of data breaches have been documented and health care is not immune.  Depending on  the  specialty, it may be a major factor.  If one backup offsite, one has only the promises of the business one deals with to ensure privacy.  If one doesn&#8217;t back up off site, you lose on of the major advantages of digital for the small office.</p><p>The more complex the system, the greater the number of software and hardware vendors involved, the greater the risks of loss of privacy, loss of data access, expense of upgrade, etc.  An inhouse system composed of well documented classic components may be more reliable and resiliant because of it&#8217;s greater simplicity.</p> ]]></content:encoded> </item> <item><title>By: Anonymous</title><link>http://www.kevinmd.com/blog/2007/11/homegrown-emr.html#comment-81816</link> <dc:creator>Anonymous</dc:creator> <pubDate>Sat, 17 Nov 2007 12:42:00 +0000</pubDate> <guid isPermaLink="false">http://clients.emmense.com/kevinmd/2007/11/homegrown-emr.html#comment-81816</guid> <description>Really not an EMR in the applied understanding of that kind of product. Most of the value of any EMR is in the integration with a practice management product, so that documentation (which is what this Word product does) is linked in real time with coding and billing elements (with &quot;smart&quot; applications that optimize both as the work results are being entered) and completes the management cycle with claims submission and receivables. At the same time, the EMR should be able to generate a relational database for practice and payer analysis, from everything from check-in  and checkout times to vital signs and other clinical data to claims analysis and payer performance.</description> <content:encoded><![CDATA[<p>Really not an EMR in the applied understanding of that kind of product. Most of the value of any EMR is in the integration with a practice management product, so that documentation (which is what this Word product does) is linked in real time with coding and billing elements (with &#8220;smart&#8221; applications that optimize both as the work results are being entered) and completes the management cycle with claims submission and receivables. At the same time, the EMR should be able to generate a relational database for practice and payer analysis, from everything from check-in  and checkout times to vital signs and other clinical data to claims analysis and payer performance.</p> ]]></content:encoded> </item> <item><title>By: Anonymous</title><link>http://www.kevinmd.com/blog/2007/11/homegrown-emr.html#comment-81798</link> <dc:creator>Anonymous</dc:creator> <pubDate>Fri, 16 Nov 2007 14:14:00 +0000</pubDate> <guid isPermaLink="false">http://clients.emmense.com/kevinmd/2007/11/homegrown-emr.html#comment-81798</guid> <description>It&#039;s why we love Open Source EMR applications - most of the power, none of the cost.&lt;br/&gt;&lt;br/&gt;Search for &#039;EMR&#039; at sourceforge.net for the current range of projects.</description> <content:encoded><![CDATA[<p>It&#8217;s why we love Open Source EMR applications &#8211; most of the power, none of the cost.</p><p>Search for &#8216;EMR&#8217; at sourceforge.net for the current range of projects.</p> ]]></content:encoded> </item> </channel> </rss>
<!-- Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/

Minified using apc
Page Caching using disk: enhanced
Database Caching 2/6 queries in 0.004 seconds using memcached
Object Caching 363/367 objects using apc
Content Delivery Network via cdn.kevinmd.com

Served from: www.kevinmd.com @ 2012-02-14 12:17:03 -->
