Free EMR Newsletter Want to receive the latest news on EMR, Meaningful Use, ARRA and Healthcare IT sent straight to your email? Join thousands of healthcare pros who subscribe to EMR and HIPAA for FREE!!

5 Minute EMR Install

Posted on January 25, 2009 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

I’ve been really intrigued with how various EMR software has been touting how quickly they can get an EMR installed for a doctor’s office.  I’m sure that many people can tell of experiences where they spent literally years getting their EMR ready for use.  This is what makes these 5 minute EMR installs that I’ve seen recently seem so intriguing.

Practice Fusion’s Live in Five

Practice Fusion has a “Live in Five” marketing campaign and promise that they can get a practitioners charting in an EMR in five minutes.  Here’s their full description of Live in Five:

Forget everything you know about software. Practice Fusion’s exclusive ‘Live in Five’ program allows you to be up and charting in less than five minutes. There are no sales contracts, no consultants to go on-site, no installation of hardware, software, and databases.

Of course, I think that Live in Five is a better marketing tool than it is reality.  Not that you won’t be charting in 5 minutes.  You certainly will be, but that doesn’t mean that there’s not going to be a more configuration and setup needed in order to move your paper charts to EMR.  There’s just more to the process than 5 minutes allows.

It is true that a hosted solution like Practice Fusion is much much faster to implement than a regular client server install.  However, no one should assume that they’ll be ready to ditch their paper charts after 5 minutes.

Open Source elementalClinic 5 Minute Install

I’m a strong proponent of open source software.  So much so that EMR and HIPAA is completely done using open source software.  I think that’s why I’m so impressed with that elementalClinic is doing to try to make installing an open source EMR in 5 minutes.  Here’s a link to install elementalClinic in 5 minutes.

Of course, if you aren’t technical you’re eyes are going to glaze over if you look at the instructions listed on that site.  However, for someone with any experience using Ubuntu linux (which is most technical people), those instructions are about as easy as you can create.  The cool part is that it makes updating the software that easy as well.

Install Thoughts

Certainly installing an EMR is just one step in the implementation of an EMR.  There’s always a lot of configuring, setup, and workflow questions that must be answered when implementing an EMR.  The cool part of the 5 minute install is that it makes answering all of those questions so much easier since you can spend 5 minutes doing an install and literally test the EMR out of the box.  You don’t have to just trust what a sales person tells you it can do.  Now you can drive exactly what your EMR software will provide before spending all the money and signing long term contracts.

Challenges with EMR and EHR Data Sharing

Posted on January 7, 2009 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

In the last blog post, Dr. Rowley discussed an interesting example where data sharing would be useful and various methods of sharing that data.

I think we can all agree with Dr. Rowley that in the ideal world #6 (sharing patient data within the same EHR system) is the best way to facilitate sharing of clinical information between doctors. Having a unified database of all patient records would of course make sharing information easier. However, there are a number of challenges with this scenario. Let’s discuss a few of these.

The first problem is that the dream of one system is just a dream. There are just too many disparate systems already in place and so we have to be practical and plan for scenarios that aren’t ideal (ie. multiple EHR systems). It’s hard enough to get consensus around one EHR vendor amongst a small set of doctors in a group practice. Try selling the same EHR to doctors from multiple specialties across a geographic region to choose the same EHR. At the end of the day, even if you had the best EHR it is likely that one doctor will just want to be different for different’s sake. Thus killing the idea of a unified system across all providers.

Just for fun, let’s say every doctor in the area does implement the same hosted EHR system. Even then it’s not very likely at all that the hospital is going to use the same EHR. Software that works well in a hospital setting doesn’t usually work well in an ambulatory setting. So, you still don’t have the patients hospital information because they’re using a different system.

I don’t want to be a complete naysayer about the idea. I have seen this implemented rather effectively in a Hospital system which had 116 multi-specialty clinics. From what I heard, they had a huge majority of the health care in their regional market. At the time they’d only implemented 25% of those clinics, but they’d implemented an EHR across specialties of almost every kind. They have a unified database where patient information was available regardless of where it was done. They even had an interface with the hospital system (the hospital system owned the clinics so this made sense). I also think it’s important to mention the interface they had with their various labs. Essentially, they had the dream that Dr. Rowley espouses. Interesting that this was all done with a client server based EHR.

While I describe the above scenario as a wonderful example, they aren’t without their challenges. They faced head on some of the challenges I described in my previous post. For example, an update to the EHR software affected every clinic using the EHR whether they liked the update or not. Anyone that’s gone through an update to an EHR is familiar with some “new feature” causing untold heartache because the EHR company didn’t realize how that “new feature” would affect the doctors using the EHR. Often the “new feature” isn’t listed in the release notes and so there was no notification to prepare for the change. Even more difficult is that with 116 clinics of varying specialties it’s nearly impossible to know how changes to the EHR software will affect each of the doctors. I’ve seen both of these problems happen even with a small 2 clinic implementation. Multiply this times 58 and you can imagine the challenge.

One other problem this implementation faced and certainly PracticeFusion or other one database web 2.0 type implementations will face is scalability. Obviously, it’s possible to scale the application if done right. Google’s done a pretty good job proving it’s possible. However, that’s much easier said than done. Many a Web 2.0 company has gone under due to their inability to scale properly. A doctor relying on a web 2.0 EHR will not likely support any significant down time. Once an EHR is implemented, most doctors become nearly paralyzed and unable to function when they can’t connect to it. While not impossible to scale a web EHR, amazing attention must be paid to the reliability of the web application. Any significant down time by a web EHR will ensure that it won’t need to worry about scaling their application for long since no doctors will want a web EHR that isn’t reliable.

My point is that in order to reach the Nirvana state of a unified web 2.0 EHR where data sharing is possible, you’ll need to be able to scale the application with near 100% reliability. Users of an EHR won’t be nearly as forgiving as social networking users when downtime occurs.

I also think it’s worth mentioning that sharing becomes much more complicated when it’s done in a unified database. Let me explain. Sharing with a fax machine (or the likes) requires a request for information to be made and a reply made. With a unified database you open up a new world of sharing which can be very powerful, but also difficult to manage. For example, if I sign a release of information which is in effect for 90 days, then why not allow me to turn on sharing of the information for the entire 90 days? Then again, one clinic might have a policy that they want to share prescriptions with another clinic for 90 days. Another clinic might want to share all clinical notes except those marked confidential with another clinic for 30 days. Once again, this can all be coded into an EHR, but it adds one more layer of complexity for the EHR to program and support and for the end users to have to learn.

At the end of the day, my biggest question is not whether there’s value in sharing data between clinics. It’s not whether the technology can support sharing of data in any number of ways. My question is increasingly whether the barriers to sharing patient data are so large that the cost is not worth the benefit. The jury’s still out on this one….and may not be back for a while.