One of the more interesting dynamics in the EMR and EHR world has to do with large versus small EHR companies. I guess we’ve always loved a big versus small story ever since David slew the Giant Goliath. Plus, there’s something American that causes most of us to really root for the underdog. I don’t know what it is, but unless my team is playing I’m most often hoping that the underdog spoils the party and does something surprising. Maybe this is why so many of us love to pit the big EHR vendors against the small EHR vendors.

Personally I don’t have any particular preference for or against larger or small EHR vendors. I care more about choosing the right EHR vendor for the right situation. In some cases those are small EHR vendors and in some cases those are large EHR vendors. I only discriminate against EHR vendors who don’t perform. Many of those that don’t perform I call Jabba the Hutt EHRs. If you haven’t read my Jabba the Hutt EHR posts, you should.

Although, what prompted this post was a comment I read recently from a doctor who uses a large EHR vendor. I won’t say which EHR or who made this comment since it doesn’t matter to learn from the comment. They basically made this suggestion:I recommended a large EHR so that it can connect everything. Then he said that the large EHR vendor decreased productivity.

Certainly I realize this is only one person discussing why doctors should go with a large EHR vendor, but if I’m a large EHR vendor I’d be really upset if this is my message. And while this is one example, I’ve certainly heard it other times before.

Think about this message from a physician’s perspective. I can either go with an EHR product that decreases my productivity (Translation: I make less money) or with an EHR product that can connect everything (Translation: That’s nice, but does it save me time or make me more money?)

All the connections in the world are great, but if you hurt a clinical processes business in the process then that’s going to be a real problem. I’m a huge EHR software advocate. I think every doctor should use EHR. However, if EHR vendors continue to do EHR implementations that have a long term negative impact on EHR productivity, then physicians will continue to resist EHR software in their offices.

The good news is that I’m seeing more and more EHR vendors focused on maintaining and improving the productivity of an office during and after an EHR implementation. I hope that trend continues and that all EHR vendors become fanatical at maximizing the efficiency of a practice during and post EHR implementation.

As I said in my previous EMR and Health IT in 2012 post, I’m going to create some of my own lists for 2012. I decided to tackle the first one on the list: My 2012 EMR and Health IT Wish List. This was kind of fun to think about. I’m also sure that I’ll come up with other ideas once this is posted, so don’t be surprised if I add things to this list in a future post.

I should also note that I’m not sure any of these things are going to happen in 2012. In fact, I bet that many of them aren’t, but this list isn’t about what is going to happen. This list is about what I wish would happen.

EHR Companies Would Embrace Interoperability – It’s an incredible shame that in 2012 we still don’t have interoperable health records. EHR companies need to get off the stump and make this a reality. The technology is already there and has been there for a while. EHR companies need to start making this dead simple because it’s the right thing to do. Sometimes doing the right thing is more important than the bottom line. Plus, doing the right thing ends up often being the best long term strategy for your bottom line as well.

Start doing what’s right and making your EHR interoperable!

Meaningful Use Would Go Away – I’m actually certain that this one won’t be happening in 2012, but I wish it would. I guess there’s a small chance that it could go away if Republicans take control of Washington and start slashing everything Obama related. However, I have a feeling that even then meaningful use will find its way back into Washington. There’s too much invested in it.

My reasoning for wanting meaningful use gone is clear. It provides a perverse incentive to providers and often incentivizes them to choose an EHR software that doesn’t work well for their practice. As I’ve mentioned in some recent posts, far too many clinics are so focused on meaningful use and EHR incentive money that they’re ignoring the real and tangible business cases for implementing an EHR in their clinic. I think this is a bad thing for healthcare and EHR software in general. The short term bump in EHR adoption won’t be worth the cost of EHR implementations focused on the wrong criteria.

I also really hate how meaningful use has hijacked the software development cycle of pretty much every EHR vendor out there. This is a real travesty since rather than developing for user/customer requirements EHR vendors are developing for a criteria. Talk about a perfect method for destroying innovation. This is a real travesty in my opinion.

Of course, I’m a realist and realize that meaningful use isn’t going away. We have to make the most with what we’re given and live with the realities that exist. However, in this New Year Wish list, I wish that meaningful use would be a past memory.

New Healthcare Model that Provides Care, Not Reimbursement – I’m sure many of you might be thinking that I’m calling for ACO’s in this wish list item. We’ll see how ACO’s evolve, but my gut tells me that the ACO model still won’t make the fundamental change that I wish would happen in healthcare. There’s far too much focus on reimbursement the way our healthcare is structured today. I’m not arguing that doctors and other healthcare professionals not get paid what they deserve. I’m just wishing that there was more focus on care for patients and less worry on maximizing the reimbursement.

How does this have to do with health IT and EHR? I’ve long argued that the biggest bane to EHR systems is the onerous reimbursement requirements. I can’t imagine how much healthcare could benefit from fabulous EHR systems if the energy spent on maximizing reimbursement were spent on improving patient care.

Diabetes Prevention App – I’ll admit that this is a little personal. I come from a long line of diabetes in the genes and I love sweets far too much. I’m pretty much destine to be a diabetic. I think that mHealth apps can have amazing power if done correctly. My wish is for someone to create a Diabetes app that will help me overcome the seeming destiny I have in this regard. The key will probably be illustrating in a profound way the impact of the choices I’m making.

Of course, you could insert hundreds of other chronic illnesses into this wish list too. I’d love to see mobile health work to solve those as well.

A True Patient Identifier – I realize that America is a large place, but we’re also a really creative country that can figure out creative solutions to problems. The lack of a true patient identifier is a challenge and a problem in healthcare. I’d love to see this problem finally resolved. I think every EHR company would rejoice at this as well.

Real EMR Differentiation – My heart absolutely goes out to doctors, practice managers and others who have the unenviable job of trying to sift through the 300+ EMR companies. I’d love for some EMR companies to really do something so innovative to differentiate themselves from the rest of the pack.

No doubt part of this problem is what I stated above about meaningful use. Hard to create innovation and differentiation in EHR when you have to develop for a government list of requirements.

EHR Data Liberation – I’ve wanted EHR data Liberation for a long time, but I think in 2012 this is one thing on the list that could become a reality. It’s a bit of a long shot, but I think there’s potential for this to happen.

My gut tells me that if we can find a way to liberate the data that’s stored in EHR software, then we’d see a dramatic increase in adoption of EHR. One of the major concerns doctors have with selecting an EHR is that once they select an EHR they know they’re locked in with that EHR for the long run. If a doctor knew that they could switch EHR software if they made a bad choice, then they’d be much more likely to pull the trigger on EHR adoption.

We need a wave of EHR vendors that aren’t afraid of liberating their EHR data, because they:
1. Know that their EHR software is so good users won’t leave
2. Know that if someone wants to leave their EHR software it’s better that they find one that’s good for them than the few extra dollars the EHR company will make off an unhappy user.

How’s that for a wish list? I think achieving these things would do an amazing amount of good in healthcare and EHR. Of course, I won’t be holding my breathe on any of them happening any time soon. That doesn’t mean I won’t keep holding out hope.

While attending the EHR Summit by HBMA, I got the chance to learn more about the AZ REC and HIE. Here are some tweets about the things they said that worth noting with my own comments:

Arizona REC

AZ REC had trouble getting vendors to take their free EHR interns. #EHRSummit11

This was pretty interesting since they said that doctors were more than willing to take on their student interns, but vendors were reticent to take them on. I do love the education program that the AZ REC put together. Internships like this are valuable.

Biggest complaint the HIT students had was access to actual EHR software. AZ REC created a EHR software lab to solve it. #EHRSummit11

This is a really common complaint by the RECs. In fact, I just helped a REC get access to some EHR software to solve this problem. It’s amazing to me that more EHR vendors aren’t happy to provide their software for these education programs.

AZ REC has a list serv of 2500 doctors and a list for vendors. See: http://www.arizonarec.org/? #EHRSummit11

I found it interesting that they had a doctor list and a vendor list. Makes sense.

AZ REC looking at optimizing health IT for ACO’s to be sustainable. I think this will be a common strategy. #EHRSummit11

The idea of REC sustainability is an important one. I think many are looking towards the ACO requirements as one pathway to sustainability. Of course, how stable are ACO’s? One thing seems certain, the relationships the RECs create with doctors could be leveraged for good if done right.

Arizona HIE

The case for the benefits of good information from something like a HIE is easy. The problem is making it actually happen. #EHRSummit11

This was my gut response when the AZ HIE was talking about the benefits of having the information an HIE provides. I don’t think I’ve heard anyone say that exchanging information would be a bad thing and produce worse clinical outcomes. Sure, they want to ensure privacy of the data when it’s done, but the benefits of having the best information are completely apparent.

HINAz (AZ HIE) didn’t depend on grants to create the HIE. They focused on the benefits of the HIE to users. #EHRSummit11

This seems like something that’s a bit unique to AZ. Most HIE’s are so focused on the grant funding. In this sense, I think that this might give the AZ HIE a chance to be successful. Plus, I loved that they did actual research into which users benefited from the HIE.

AZ HIE, Hospitals pay 50% of costs, Plans pay 50% of costs. Physicians pay nominal fee to participate (cause nominal benefit). #EHRSummit11

This is where the real fun begins. The hospitals and plans are paying for the HIE since the AZ HIE found that they’re the ones that would benefit from it. They found that doctors received nominal benefits from using the HIE and so they shouldn’t be charged to use it. Of course, the other beneficiaries not mentioned here is the benefit to the patients. I’m sure hospitals and plans will pass the cost on to patients, so I guess that works out in the end.

Today and tomorrow I’ve got the opportunity to attend the EHR Summit that’s being held by the Healthcare Billing and Management Association (HBMA) in Phoenix (officially Scottsdale). I first heard of this conference about a year ago and loved the idea. In fact, this conference was kind of what I’ve dreamed of creating in an EHR conference. The idea is to have actual practical advice on how to select and implement EHR software.

Here’s a sample of some of the topics that will be covered:

• EHR: Where are we Today?
• Vendor Selection
• Medical Legal Considerations
• An Insider’s Perspective
• Training for Meaningful Use
• REC & HIE Update
• Market Needs Your Help with EHR
• Workflow & Process Management
• EHR Implementation Planning
• EHR Implementation Support
• EHR Adoption & Ongoing Support
• EHR Optimization, Meaningful Use & Use in Health Reform

That’s quite a bit different agenda than all the other EMR and healthcare IT related conferences that I’ve seen. I also love that the conference has some built in time for users to get some EHR demos. In fact, it’s almost like they’ve created a track of EHR demos as part of the conference. I do wish they’d had a session on EMR demos on the first day to better help attendees make the most of their EHR demos. Things like how to ask the right questions (ie. Don’t ask Yes/No questions)

I’ll be doing a number of posts talking about the messages shared at the EHR Summit on this site, EMR and EHR, and EMR Thoughts over the next couple of days.

If you don’t want to wait for the blog posts, I’ll be doing a fair amount of tweeting from the event on my @ehrandhit account.

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.

I saw a tweet of a picture from the front desk of a doctor’s office that’s implementing an Electronic Medical Record in their office. I’ll embed the image below, but since it’s a little hard to read, here’s the text from the sign:

UNDER CONSTRUCTION
Pardon us while we improve your visit.

In order to provide you with the most efficient visit possible, MedExpress is installing an EMR (Electronic Medical Records) system.

This technology enables MedExpress to provide you even more convenient care, and ensures that your records will hold more accurate documentation, in a safer, more concisely stored location.

By 2012, it is federally mandated that healthcare providers initiate electronic health records. MedExpress is keeping up with the current health information technology. In addition, this promotes “green practices” to lower our paper usage.

Please bear with us, as we are currently in training with this system.

This sign brings up a lot of interesting talking points. The first one that hits me is back about 5 years ago when I heard someone propose (mostly jokingly) the idea of having a “Got EMR?” sign for offices. This isn’t quite the same, but does use some of the same idea of the value of EHR to patients.

I’ll set aside the part of the sign that talks about the government EHR mandate since we’ve talked about it plenty of times before (and how it’s not really a mandate). I’ll also avoid commenting on the “green practices” section of the sign, but it’s amazing how green has infiltrated marketing.

Instead, does anyone else find it amazing that the anticipated slow down for this clinic’s EHR implementation was so big that they typed and printed up a sign explaining the slow down? Maybe it’s just during the time that the doctors are training and not actually a slow down that has to do with actual use of the EHR after training. Although, I know many EHR vendors that are now rolling their eyes when they hear about the EHR training and implementation time and its effect on physician productivity.

I can’t help but wonder which EHR software this clinic is implementing. That would be interesting to know.

Time for the latest entry in my series of Common EHR Implementation Issues. See also my previous posts on Unexpected EHR Expenses, EHR Performance Issues and a little follow up to avoiding the EHR performance issues altogether.

This weeks common EHR implementation issue is: Inadequate EHR Templates.

Before I begin with the major issues of inadequate EHR templates, it’s worth noting that there are a few EHR software out there that use a different EHR documentation paradigm than templates. For example, some use voice recognition to power their documentation. Others have a system that learns your documentation over time and based on that learning remembers how you want to document certain procedures. Others, use lots of independent documentation methods (one EHR vendor calls them controls – check box, radio button, freetext field, etc.) which can be grouped and used in interesting ways.

However, even with all of the above alternative documentation methods, there’s often an element of templating that’s occurring. They’re PR and marketing people will shudder at the term template, but concepts related to templates seem to pretty much always apply. For example, in voice recognition there’s something called a Macro. That’s basically a template. The EHR system that learns your documentation method is just using your initial documentation in the EHR to create personalized templates of how you like to document. The independent documentation methods often group those various “controls” into groups of common visits. That sounds like a template to me.

I’d be interested to hear of an EHR system that doesn’t use the principles of templates. It is worth noting that all EHR templates aren’t created equal. Some are much more flexible than others. Now to some details.

The inadequate EHR templates shows itself in a number of different ways.

No Specialty Specific EHR Templates – This has to be the complaint I hear the most. It usually goes something like this, “The EHR salesperson said they had templates, but they don’t have any templates I can use.” Did someone say EMR salesperson mis-communication? Yep, happens all the time. Let’s be honest for a second. How could the EHR salesperson know how good their cardiology or neurology templates really are? They just go by what they hear and what they’re told by the EHR company.

Incomplete or Unusable EHR Templates – You may have noticed a subtlety in the quote I put above. At the end the doctor says “templates I can use.” Maybe the EHR salesperson isn’t lying to you about them having those cardiology or neurology templates. Maybe they do have a bunch of templates for those specialties (or whatever specialty that interests you). However, just because they have templates for those specialties doesn’t mean that you’re going to want to use any of the templates that they’ve created.

My favorite complaint is when they say that the specialty templates seem to have been created be a general medicine doctor and not an actual specialist from that field. I’ve heard it far too much not to mention it.

The other major problem with this point is the unique documentation preferences of each doctor. Has there ever been any two doctors that document the same way? We could debate the good and bad merits of such documentation, but the point is that each doctor is very different. Some feel the need to over document the encounter. Other doctors want to just document the bare minimum. Plus, some (purposefully or not) do a terrible job documenting the visit. The templates in an EHR could reflect any of these various documentation patterns and depending on your perspective could mean that EHR has inadequate templates for your needs.

Hard to Modify, Add to, or Adjust – While not specifically an inadequate template, this is an important part of templates. Turns out that if a user can easily modify, add to or adjust a template that is inadequate, you’re going to be a lot better off. Some template systems are like pulling teeth to modify. Others are amazing at how you can on the fly modify the template.

One promise I can make you, You WILL want to modify their templates. I can’t say I’ve ever heard of someone using the templates perfectly out of the box. Well, maybe I’ve heard of one or two using them, but that was when they were complaining that they had no way to modify the things they wanted to change.

Avoiding EHR Template Inadequacies

The best way to avoid this issue is to test drive the EHR software and the specialty specific templates you hope to use. Run through the templates like you’re charting on some common patients. You’ll learn a lot about what templates are available doing this than anything else. You’ll see if the templates are overkill or below standard for your needs.

Another great test is to try using multiple templates for a complex patient. How easily is that done and how well does the documentation display?

Then, during your EHR demo with the EHR salesperson, ask them to modify part of the EHR template they’re using to document. Tell them you don’t like to ask one of those questions, so you’d like to see them remove it from the template. Many are likely to respond, “It can be done, but I’d have to switch systems to do it or I’d have to call in to tech support to make the change.” I think we all know the real message they’re sending.

For those not interested in EHR templates, you might take a second to read Dr. West’s Experience implementing EHR templates in his office.

Many of you might remember my recent post about EMR Performance Issues (ie. EMR Slowness). Turns out, the post had a pretty big impact on some readers of the site. In fact, it sounds like it was partially therapeutic for some to realize that they’re not alone.

I asked permission to share one of the responses with you so you could get some more first hand perspective on the issue of EMR slowness. I share it in the hopes that others can be aware and avoid it. Plus, I hope the EHR vendors that read this will take it to heart and be fanatically focused on EMR speed and customer support.

I’ve removed the name of the writer and the names of the vendors. Plus, realize that it was written originally in an email communication and not necessarily to be published.

OMG…you hit the nail on the head with this post. Our EMR is so slow. It often takes minutes between pages. My clinical and front office staffs so frustrated. We have had nothing but finger pointing going on ever since.

Part of the issue is the interface between our practice management system VENDOR A and our EMR VENDOR B It takes a minimum of 3-4 minutes for data entered into VENDOR A to roll into VENDOR B. My front office staff has taken to entering the data twice, once in each program in order to get our patients registered timely. When you see 80-100 patients in a day, a few minutes makes all the difference.

Additionally, certain criteria does not roll over, namely email addresses. This makes it impossible for us to send out patient visit summaries thus we are unable to meet meaningful use for that criteria. Referring physician is another part that does not roll over.

The most frustrating part is that no one will take any responsibility for the issue much less work on fixing it. These two vendors spend all day playing the blame game. Fortunately for our practice, we have a wonderful IT company that we work with. Our IT specialist has spend countless hours trying to mediate between these two vendors. Most times he just fixes what he can but we are paying for his services in addition to the tech support agreement with VENDOR A and VENDOR B.

A perfect example happened this week when the EMR went down in one of our exam rooms.. First we spend at least 10-20 minutes on hold waiting for a VENDOR B tech to pick up the call. In this particular case, they worked remotely for at least 4 hours on this one computer only to tell us they could not fix it.

I called my IT guy and he fixed it within 10 minutes. My staff spends countless hours on the phone most days trying to keep the system up and running. We are in the process of replacing all our PCs and I recently upgraded our Internet to a 10×10 fiber service however we still are not seeing any difference in speed.

It is at least comforting to know we are not alone. I plan to hang up your post for all my staff to see. It may not make our system work faster but hopefully it will give them some comfort knowing they are not alone.

Thanks for all the great information.

In my post about the common EHR implementation problem of EHR slowness, I mentioned that I’d follow up with a post on how you can avoid the EMR slowness issue altogether. It’s better to avoid than fix problems.

The best way to approach EHR performance issues is to make them part of your EHR selection process. EHR performance issues could and should be a deal breaker for you when you’re evaluating EHR companies. How then can you identify EHR software that might have these performance issues?

Red Flag #1 – EHR Demo Slowness – Bring a red pen to your demo and every time they say something like, “It’s not usually this slow?” or “It must be slow because it’s running on my laptop.” make a BIG RED mark on your paper (or tablet if you’re advanced like that). Even one red mark should be cause for concern and investigation.

Certainly there are situations where environmental issues can cause slowness to an EHR. So, you can’t completely rule them out completely for this, but this is their demo. This is there one time to shine. If they can’t get their EHR demo running at full speed, what makes you think an EHR production environment will be much better?

You can make an extra red mark if it’s a SaaS EHR that’s providing the demo. They might say it’s just “the internet connection.” Well, guess what? Soon, that’s going to be you using that EHR and often on similar internet connections.

Of course, the message to EHR vendors is to make sure your demo runs as fast as your production system.

Red Flag #2 – Site Visit Slowness – While the demo can tell you a lot about an EHR software, it can’t necessarily tell you the speed of the EHR software. Just because the EHR is fast during the EHR demo, doesn’t mean that same EHR software will be fast in a production environment. Add this to the multitude of reasons why a site visit to a current user of that EHR is so important.

Make sure to do that site visit at one comparable in size and users to your clinic. You don’t want to look at the EHR responsiveness of a solo practice if you’re going to be a 6 provider multi clinic setup. Size matters when it comes to EHR speed.

Once on site, you can get an idea of the speed and responsiveness of the EHR software in two ways. First, observe the users of the EHR in the clinic. See if they exhibit any of the systems listed in the first section of this post. Another observation is to see how quickly they’re clicking around the EHR. If you see a lot of clicks in a row with little waiting in between clicks, that’s a great thing. If you see them click, wait, click, wait, click, click , wait. Be afraid.

The second way is to ask the EHR users. The problem with doing this is that only one response has value. If they say the EHR is slow, then you’ve gleaned some important information that’s worth checking on. If they say the EHR is fast, then you don’t necessarily know. The problem is that you don’t know what the user considers fast. What’s their frame of reference for saying it’s fast? Do they know what fast is? Have they just been using the EHR software so long that they’ve hit a rhythm that makes it feel faster than it really is? It’s a good sign if they say that it’s fast, but take it with a grain of salt.

Red Flag #3 – Use A Demo EHR System Yourself – Most EHR vendors will provide you a way to demo the product yourself. This isn’t a fool proof method to test EHR slowness, but it’s another decent test of the EHR’s responsiveness. Try it out using your internet connection and your computer hardware. Nothing like first hand experience documenting some patient visits to learn about the speed of an EHR.

EHR Speed Suggestion – Don’t Skimp on Hardware
Far too often I see a clinic skimp on the hardware requirements and regret it later. In fact, they often end up spending the money twice since they have to buy new hardware since they skimped in the beginning.

Of course, this suggestion can be taken too far as well. The computer and laptop manufacturers will try to sell you the whole kitchen and you might only need the stove and refrigerator. To put it in more practical terms, you’re going to want plenty of RAM, but do you really need the webcam, Blu-ray player, and special 100 in 1 media device?

Just because an EHR vendor says their EHR software can work on a certain hardware configuration doesn’t mean it should be used on that hardware configuration. In the middle there’s a spot between can and overkill that’s called optimal. Find that hardware configuration and you’ll be a much happier EHR user.

Conclusion
Don’t accept an EHR that’s slow. Make sure that the EHR performs at a satisfactory level. I know of nothing that frustrates a clinic more than a slow EHR.

We’re back again with our ongoing series on Common EMR Implementation Issues. Seems like readers really liked my first entry in the series about Unexpected EHR Expenses. To be quite honest, I was really happy with how that post turned out myself. It’s one of the most comprehensive and useful posts I’ve written in the 5.5+ years I’ve been writing about EMR and EHR. Hopefully we can continue that trend.

Today’s Common EMR Implementation Problem: EHR Performance Issues

I have to admit that this is a really tough problem to crack. However, it’s also incredibly common. The symptoms for this problem usually are described as, “THIS EHR IS SOOOOOO SLOW!” (This is appropriate use of ALL CAPS since they are often yelling this.) Followed by a *huff* and an angry doctor or nurse leaving their computer in a fit of rage. Other symptoms might include drumming fingers on the desk while staring blankly at the screen, lots of mouse clicks that get progressively longer and more emphatic, or the sitting back in your chair staring at the screen hoping that something will happen.

Once you’ve identified that there’s a problem with EHR slowness, then begins the fun and exciting (that was written in the sarcasm font) journey to identify the real issue. The biggest challenge with identifying the slowness is that there are a multitude of places that could be the bottleneck that’s causing your slowness. Some of which you can fix, and others you have to rely on your EHR vendor to fix.

To assist you in the ugly process of improving EHR performance issues, here’s a list of possible reasons you could have a slow EHR.

EHR Slowness You’re Responsible For
Slow Computers and/or Laptops – I’ve heard of a few EHR vendors offering free iPad’s with their EHR, but for the most part, you’re responsible for buying the computers and laptops for your EHR implementation. See my “EHR Speed Suggestion – Don’t Skimp on Hardware” below for more info on buying the right hardware. Needless to say, I’ve seen many slow computers be replaced and the EHR went a lot faster.

Slow Local Internet – Your local internet (or LAN as it’s often referred) could be the cause of your EHR slowness. I could have split this point into a half dozen possible issues. Some of them might include: Bad network card, bad cabling, bad switch, bad router, bad routing configuration, bad DNS configuration, overwhelmed network, etc etc.

Of course, in most cases you’ll probably have to call your IT service provider to solve these issues. They should be able to easily test most of the above issues and prove that it works for other internet applications and so it must be some other issue causing your EHR slowness.

Slow ISP (external internet connection) – If you’re using an in house EHR server, you won’t have to worry about this as much (except for interfaces, or EHR updates). If you’re using a SaaS EHR, then this could be a major bottleneck. Good thing is that it’s easy to test your ISP speed. If you’re speed is great to other sites, but not your EHR then you can move on to another issue. If you’re speed is bad for all sites on the internet, you need to see if your ISP can make some changes to provide the speed you’ve purchases from them. Otherwise, you might just need a bigger ISP connection than you have and you’ll be able to get your EHR running much faster.

Also, be sure you don’t have employees using up all your bandwidth downloading illegal (or legal) music or videos. That can eat up your bandwidth really quickly. There’s a reason Netflix uses up 20% of bandwidth on the internet. Movie downloads/watching might be using up your internet connection as well.

Memory on Server – I see this issue most often when a clinic tries to re-provision an old server for their new EHR or when they don’t follow the suggested specs of their EHR vendor. It can also happen when you start your EHR with 1 doctor and then grow your practice to 5 doctors. More users usually requires more memory on the server. There are good tools on servers for analyzing how much memory is being used so you’ll know if this is the problem or not.

Hard Disk Space on Server – This definitely shouldn’t happen in a fresh EHR install, but often can happen over time. Servers don’t like to run out of hard disk space and can do all sorts of crazy and unexpected things if they do. Other things that cause a hard disk to run out space might be backups or large log files. I’ve also seen where the IT administrator takes a 500 GB hard drive and divides it into multiple partitions. One partition for the O/S and one partition for the data. Often they misjudge how much to give to one partition versus the other. So, the one partition runs out of space while the other one has TONS of space left.

Good planning and regular maintenance will avoid these issues.

CPU on Server – I believe this is pretty rare these days since memory is usually the bottleneck instead of CPU. However, if the EHR software isn’t written correctly, this could be an issue. Particularly on older boxes.

Complex Workstation Setup – Your IT service provider might have told you all the great benefits of a thin client setup or some sort of virtualized desktop software solution. When done right, these solutions can work fantastic and save you a LOT of money. When done wrong, they can cause you all sorts of slowness and heartache.

EHR Slowness Your EHR Vendor Must Fix
Slow Server Configuration – There are lots of ways to tweak a server to go faster with less resources. Unfortunately, most of these tweaks are likely going to have to come from your EHR vendor. In a larger hospital implementation, you might be able to work with your EHR vendor to implement some of these tweaks. In a small clinic, you’re basically at the mercy of your EHR vendor to configure the server to run fast.

Slow Server (SaaS EHR) – Yes, SaaS EHR vendor servers can go slow too. The good thing is that your EHR vendor likely has monitoring tools that are watching for any slowness so they can proactively fix it. The problem is that then you’re at their mercy to fix the slowness. Needless to say, an EHR vendor’s server support staff rarely feel the end user pain of EHR slowness. At least the pain isn’t nearly as poignant.

Of course, a chorus of calls from EHR users to the EHR support line will help them understand better and fix the slowness. One call about your in house server doesn’t resonate quite as loud.

Slow or Overwhelmed Data Center Connection – Data Center internet connections are generally quite robust and built with a lot of redundancy. However, since data centers usually host many many different systems, they can also get overwhelmed. Sometimes through spikes of traffic, but more often through other nefarious attacks on the systems in the data center. Often, it’s not even your EHR software that’s causing the issue, but it might suffer the consequence. Not very common, but possible.

A little more common could be an EHR vendor that’s growing so rapidly that they can’t keep up with the demand for their EHR software. Other times the EHR vendor just did a poor job planning to expand their EHR data center services.

Poor EHR Code – Not all code is created equal. Some programmers are good at creating code that will execute quickly, but most are not. Fixing speed issues aren’t trivial. Particularly if you have a large code base that’s been created over a long period of time.

Poor EHR Design – The design of an EHR software often determines how fast it work. Designing for speed from the beginning is crucial. Otherwise, a poorly structured EHR can almost never be made fast.

Related to this is EHR software built on old technology. To use a car analogy, you can only make a pinto go so fast without gutting the engine. Too many EHR vendors are built on engines that can only go so fast. They can keep squeezing a bit more speed out of the engine, but eventually you have no other speed benefits because of the legacy technology limitations.

I’m sure there are other possible bottlenecks. Let me know of any I missed in the comments and I’ll add them to the list.

EHR Performance Finger Pointing
Another big problem with the complex list above is that it often leads to a bunch of finger pointing. Yes, sometimes it will feel like you’re back in Kindergarten again. Your EHR vendor will point the finger at your IT setup. Your IT service provider will point the finger at the EHR vendor. Then, the EHR vendor will point the finger at the hardware vendor. You’ll never be able to talk to a person at the hardware vendor and so you’ll have to use other tricks to prove it’s not them.

Needless to say the finger pointing can get really tiring really quick. Not to mention it can be very expensive as you spend money proving to your EHR vendor that it really is their problem and not your setup.

I’ll follow up this post with another on how to avoid EHR Performance Issues during the EHR selection process. I’ll link to that post once it’s up.

Side Note: This post was much longer than expected. I guess I did have a lot to say about this issue.