Written by: John Lynn
I’m really excited that this Common EHR implementation issues series has been so popular. If you missed it, you can see the previous posts in the series: Unexpected EHR Expenses, EHR Performance Issues, a little follow up to avoiding the EHR performance issues altogether, and inadequate EHR templates.
This weeks common EHR implementation issue is: EMR Upgrade Problems
I’d like to categorize this EHR implementation issue into two areas. One is upgrading to an EHR from an old legacy EHR and/or PMS. The second is upgrading your existing EHR that’s just outdated. I’ll take them in reverse order.
Upgrade of Existing Outdated EHR
In this world of your web browser and operating system auto updating at regular intervals it’s sometimes hard to remember that not all software does that. In fact, it turns out that most software doesn’t auto update (often for good reason). Of course, this problem doesn’t apply to a SaaS based EHR software since those updates are applied whether you like it or not. The nice part is that the SaaS EHR updates appear to the user to just happen automatically with little to no intervention on their part. Of course, we’ll save what happens when a SaaS EHR update causes you problems for another post. In the client server world of EHR (or hybrid EHR as some like to call themselves when they’re web based on an in house server) you will have to deal with updating your EHR.
I think with rare exception, it’s a huge mistake to not keep your EHR software up to date (goes for most other software as well). I’m not suggesting that even client server software should auto update. Considering the deployment and upgrade model of most EHR software, it’s almost essential to review the new feature list before doing an update to ensure that the update won’t cause you unnecessary heartache. Understanding the changes that will happen with the EHR Upgrade will let you warn your users about it so that they don’t come running into your office after the upgrade wondering why their favorite feature was changed.
What’s the problem with not upgrading? Many might just think that they don’t need to update their EHR software since they don’t want/need the extra features that are part of the upgrade. This is a bad strategy for a couple reasons. First, there are often security fixes that are part of the EHR upgrade that you’ll be missing out on if you don’t upgrade. Second, a bunch of relatively minor updates is much better on a clinic than one massive one that requires a ton of change. Third, when a future update comes that has a feature you do want, it’s not always pretty to go through multiple upgrades at the same time. Fourth, try calling the EHR support when you’re on an old version. Most of the time they’re going to say you need to upgrade for them to appropriately support you.
One other suggestion on EMR Upgrades now that I’ve supported the idea of upgrading. Just because I suggest you upgrade to the latest version of your EHR, doesn’t mean you have to be the beta tester for the company. Do the upgrade early in the process, but not necessarily so early that you’re going to be the bug tester for the company.
Upgrading an EHR from a Legacy EHR or PMS
This situation happens most often when either a clinic decides to switch from their old hasn’t been updated legacy PMS (which might include some basic EHR features) or when a clinic decides to move off their existing EHR to a new one.
Upgrading from a legacy PMS could easily be a whole series of blog posts. Suffice it to say that the biggest challenge with the upgrade from the old legacy PMS system is often getting the data out of it. Some legacy PMS systems don’t provide that data willing. In fact, many will even charge you to get access to it. They’ve basically lost you as a customers, so they’re trying to maximize whatever revenue they can get. It’s not pretty.
Even if you can get access to the data, there’s often a lot of data manipulation that will have to occur. A common problem that’s related to this is whether you even want to get the data out of the old PMS. Far too often, the data in the old legacy system has so much junk in it, that it’s worth considering the option of starting from scratch. It’s not pretty to upload inconsistent and ugly data from a legacy system into your nice, new EHR software.
Switching from one EHR software to another is becoming more and more common. In 2-3 years I believe we’re going to see an amazing influx of EHR software switches. It will be the topic du jour. We’re already starting to see it in a number of situations: an EHR that isn’t certified, an EHR that the doctor hates, an EHR that’s gone under, an EHR that’s sold to another company, etc.
The biggest problem right now with switching EHR software is that there’s no standard for the data to be exported and imported into a new EHR company. Some of you might remember my post asking EHR vendors to consider the value of EHR data liberation. In it I describe why not only is it the right ethical thing to do, but it also can make a lot of business sense to do so. Sadly, I’ve only really seen one EHR software that has embraced the concept of really liberating the data in their EHR.
I’d love to support a movement from EHR vendors that embrace the concept of EMR data liberation. I imagine most are too afraid of giving their users an easy option to leave their EHR. It’s too bad EHR vendors are so focused on protecting their business instead of focusing everything they do on the customer experience, but I digress.
Considering the above described state of EHR data export, you can see why moving to an EHR is such an issue. It’s worth mentioning this topic before you even select an EHR. Before purchasing the EHR, ask the question, What if this EHR is terrible and I want to switch? This is water under a bridge if you’re already in a compromising position under contract with an EHR you don’t like.
Unfortunately, I don’t really have very many great suggestions for those in this position. Just some words of comfort. First, switching EHR software can actually be easier than implementing an EHR in the first place. You already have the computers and IT infrastructure. Plus, for some reason second EHR implementations have a much higher success and satisfaction rate from what I’ve seen. Second, while it’s a bitter bullet to bite, everyone that I know that’s done it wishes they’d done it earlier. Although, don’t rush into another EHR just because. Take your time to select an EHR properly if you’re going to switch, but don’t be afraid to switch based on what economists call sunk costs. Third, this is one case where it’s often good to hire someone who’s done these type of EHR switching before. They can be a big help.