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!!

Is The Cloud The Best EHR Model For Small Practices?

Posted on June 5, 2013 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

Over the last few years, the use of EMRs in medical practices has grown dramatically, with over 50 percent of office-based physicians now using such systems.  However, physicians still face major barriers in adopting EMRs, including costs, usability issues and impacts on doctor productivity.

One way of reducing the complexity of EMR installations — doing more for less — is to go with a Web-based model of EMR  use, argues “The Cloud: The Best EHR Solution for Small Practices.”

This model, also known as “software as a service” (SaaS) stores patient data in the cloud, accessible from any secure device connected to the Internet.

Not only does the cloud/SaaS model make it easy to access patient data,  it saves practices having to come up with a large up-front installation fee to set up software on site. Instead, practices pay a monthly fee which is predictable (and usually, manageable).

The price difference is very striking. The average cost of a client-server implementation over five years ranges from $30K to a whopping $80K per provider, not including the cost of training, interfaces, patient portals and conversions from other systems, the white paper notes.

But cost isn’t the only reason for small practices to go with a cloud/SaaS EHR. Increasingly, physicians are going mobile with care, via smartphone and tablet. As the Bring Your Own Device phenomenon explodes, practices are going to want an EHR which can easily be accessed and used via the Internet.

Read this paper to learn more about mHealth and how a cloud/SaaS solution can support your small practice’s mobile strategy while protecting critical data offsite in the event of a disaster; being sure that your data is encrypted at rest as required by Meaningful Use; and even how doctors can use voice to chart notes.

Of course, there are many who still argue against a cloud based EHR. They have their reasons that are worthy of consideration. An in house client server EHR does have its advantages over SaaS EHR. You have to weigh the pros and cons of each. Then, you can make a great decision for your organization.

What SaaS EHR Users Can Learn from the Megaupload Takedown

Posted on July 5, 2012 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.

It’s time to talk about a subject near and dear to my readers hearts: SaaS EHR. In this article, we’re going to take a serious look at some of the risks associated with the pure SaaS EHR model. I’m sure this will leave many concerned about SaaS EHR software. Before I get into that, I want to be clear that I can (and probably will) make a future post about client server EHR software that will likely leave you just as concerned.

The point isn’t that SaaS EHR or client server EHR is better than the other. I take a much more “switzerland” approach to the topic. I think both approaches to EHR have their risks, challenges, benefits and advantages. To me it’s much more important that users are educated on the risks of each so that they can address them properly.

With that in mind, I was recently reading one of my favorite venture capital bloggers, Brad Feld, who posted a guest post by Dave Jilk about what SaaS software vendors can learn from the Megaupload and its impact on the future of Multi Tenant Services. For those not familiar with the Megaupload situation, the Feds basically took down Megaupload and seized everything they had in response to copyright infringement violations. Wired has an interesting article about the case.

What then can we learn from the Megaupload case that applies to SaaS EHR companies. I think Dave Jilk describes the SaaS risks better than I could:

What this particular case illustrates is that a company that provides your online service is a single point of failure. In other words, simply offering multiple data centers, or replicating data in multiple locations, does not mitigate all the risks, because there are risks that affect entire companies. I have never believed that “availability zones” or other such intra-provider approaches completely mitigate risk, and the infamous Amazon Web Services outage of Spring 2011 demonstrated that quite clearly (i.e., cascading effects crossed their availability zones). The Megaupload situation is an example of a non-technical company-wide effect. Other non-technical company-wide effects might be illiquidity, acquisition by one of your competitors, or changes in strategy that do not include the service you use.

So again, while this is a striking and unfortunate illustration, the risk it poses is not fundamentally new. You need to have an offsite backup of your data and a way to use that backup. The situation where the failure to do this is most prevalent is in multi-tenant, shared-everything SaaS, such as Salesforce.com and NetSuite. While these are honorable companies unlikely to be involved in federal data confiscations, they are still subject to all the other risks, including company-wide risks. With these services, off-site backups are awkward at best, and more importantly, there is no software available to which you could restore the backup and run it. In essence, you would have to engage in a data conversion project to move to a new provider, and this could take weeks or more. Can you afford to be without your CRM or ERP system for weeks? By the way, I think there are steps these companies could take to mitigate this risk for you, but they will only do it if they get enough pressure from customers. Alternatively, you could build (or an entrepreneurial company could provide) conversion routines that bring your data up and running in another provider or software system fairly quickly. This would have to be tested in advance.

As many of you know, I’ve been quite interested in this topic and risk for quite a while. I’m sympathetic to those doctors that want at least a copy of their data stored somewhere that they control. Yes, most SaaS EHR vendors have a good set of backup, disaster recovery and business continuity plans. However, as the above quote points out so well, that doesn’t deal with the “non-tecnical company-wide effects.”

I’ve long considered the idea of creating a set of standards that SaaS EHR vendors could adopt. Things like making a practice’s entire EHR data available in an easily downloadable XML format. That could be the starting point. I think it would also create a real competitive advantage to those EHR vendors that adopted these type of common sense, good customer service practices.

I’d even be happy to lead the EHR agnostic team that it would take to make this happen. Client Server EHR software vendors could be involved as well. Not to mention I’d be happy to provide a voice to the movement on my network of EMR websites. I think the key to success would be getting a couple EHR vendors to get on board with the idea and fully invested in seeing this happen. The challenge is that too many EHR vendors are blinded by the meaningful use lights.

Let’s just imagine for a minute that doctors that select an EHR didn’t have to worry about their data being safe. They knew that they could have their data available to them when they needed it where they needed it regardless of what happened to the vendor. I have that with my blog data. Although, instead of that making me wanting to change blogging platforms, it’s endeared me to WordPress even more.

I wonder if Todd Park could add this idea to his concept of EHR Data Liberacion.

Cloud Computing Won’t Be the Death of Client Server EMR – Something Else Will Be

Posted on May 9, 2012 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.

One of the all time favorite topics of discussion here at EMR and HIPAA is around SaaS EHR software versus client server EHR software. They each go by many other names and the technical among us might know the hard core technical difference between each, but most doctors don’t know and don’t care. SaaS EHR software is often called hosted EHR software or ASP EHR software or even Cloud Computing if you want to use a general term. Client Server EHR software is sometimes called in house EHR software or self hosted EHR software. I’m sure there are other names I missed.

Regardless of what you call it, many people (usually those from SaaS software vendors) believe that client server software will lose out to the cloud. It’s hard to argue with them since in almost every other industry cloud based software has won.

Here’s why I don’t think we’re going to spell the death of client server software for a long time to come. Client server is going to be here for a long time because of such wide adoption by so many doctors. Not to mention, many of the client server EHR systems are really large implementations that would be hard to displace. Plus, there are many doctors who don’t care about the mobile benefits of a SaaS based EHR software. Quite a few doctors want to only use their EHR software in their office.

Certainly there are others on a client server based EHR system which will want to access their EHR outside of their office. Unfortunately, instead of EHR replacement we’re likely to see a hybrid environment that supports client server and some sort of app environment come out of the various client server EHR vendors.

Sure, a lot of doctors will also use Citrix or other remote desktop environments and hate the user experience, but it will pacify them until the hybrid EHR environment is built. In fact, that hate towards the remote desktop environment on a mobile device will drive the development of this hybrid approach. The advantages of a client server environment with an app connection will keep the client server environment around for a while.

So, while many want to declare the death to client server, I’m not ready to do so. Sure, SaaS EHR software has its advantages, but client server software isn’t going to go down without a fight and they’re going to be around for a while since in many cases they hold the high ground.

GE Centricity Advance Ceasing Operations

Posted on January 26, 2012 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.

Yesterday I had the opportunity to talk with the people from GE who briefed me that GE is in the process of shutting down their GE Centricity Advance product line. This was pretty big news to me since I remember just last year at HIMSS meeting with GE and hearing that for the small practice (I believe 1-10 docs) GE Centricity Advance was where they were putting all their effort. You could see the energy they had behind it. In fact, their iPad EHR app was built on top of the GE Centricity Advance solution (which is now being moved to their other EHR product lines).

You might remember that the GE Centricity Advance solution was actually created out of the purchase of MedPlexus in March 2010. At the time, MedPlexus had 100 employees out of California with the development team out of India. At the time of purchase it seemed GE’s acquisition would provide a SaaS based EHR option to the independent physician market. Plus, MedPlexus (which became GE Centricity Advance) also provided an integrated Practice Management System with the EHR.

The GE Centricity Advance website is already forwarding to the Centricity Practice Solution website and a letter was sent out to all Centricity Advance customers informing them that the product line was ceasing operation. I’ve asked for a copy of that letter and if I get it, I’ll add it to this post (or if you’re a customer that received it and doesn’t mind sharing we’d welcome it).

I was told that GE is offering Centricty Advance users a free transfer to their Centricity Practice Solution EHR software. From what they told me it seems this will include data migration, training on the new system and a license for Centricity Practice Solution. Of course, Centricity Advance was paid on a subscription model so they’ll have to continue paying the monthly fee. As with most data migrations, I don’t think we’ll know how good GE is at migrating the data from GE Centricity Advance to Centricity Practice Solution until they start to do them.

Since both Centricity Advance and Centricity Practice Solution have ONC-ATCB complete EHR certification, there shouldn’t be any problems for those that transfer to Centricity Practice Solution when it comes to EHR stimulus money. Those not wanting to move to the Centricity Practice Solution will have this as part of their decision on what to do once Centricity Advance is no longer supported. I expect there will be many in this situation since while Centricity Practice Solution is available through GE’s partners as a “SaaS” offering, I think many will want to find a true from the ground up web based SaaS EHR offering.

I asked how many providers would be effected by the end of the Centricity Advance product line, but it’s GE’s policy to not comment on those numbers.

Where does this leave GE Centricity EMR software?
GE Healthcare IT still does a couple billion dollars of business and still has three EMR software offerings:
*Centricity Practice Solution – The replacement for Centricity Advance and will be GE’s EMR offering for the 1-100 provider practices.
*Centricity EMR – Still ambulatory EMR, but for the 100+ provider practices.
*Centricity Enterprise – Acute care EMR

I’m sure that many will wonder how good the Centricity Practice Solution will do in the small practice arena. Will this basically mean that GE is no longer a player in the small 1-10 provider practices? It’s hard to say for sure, but I’ll be interested to see how the Centricity Practice Solution EHR does in this market. There must have been a reason they purchased what became Centricity Advance instead of going with Centricity Practice Solution in the first place.

On the other hand, I could see people making the argument that this is a sound strategy by GE since movements like accountable care organizations (ACO’s) and related initiatives are putting the small practice in jeopardy. We know that many hospital systems are purchasing up group practices as they prepare to become an ACO among other reasons. While we still have many small group practices, it’s worth considering how many of them will survive the changing landscape. If not many survive, then this strategy by GE could end well for them. Although, I personally believe that practice consolidation is cyclical and so I’m not ready to announce the death of small group practices yet.

Another trend that might make this a good decision on GE’s part is what I call the Smart EHR. Our current phase of EHR adoption is basically converting paper to electronic. Once doctors start requiring EHR software to do things far more advanced (see Artificial Intelligence and Genomics EHR), it will require a new kind of EHR. Maybe Centricity Advance wasn’t prepared to make this shift. We’ll see if GE’s other EHR software is ready for it.

Many have argued that EHR consolidation is inevitable. I guess I shouldn’t be surprised that part of that EHR consolidation is happening within the same EHR company. I’m sure there are more on the way as we see which EHR companies survive the meaningful use winter and come out on the other side and which EHR companies close up shop.

Update: I asked GE for some more clarification on when GE Centricity Advance would be sunset and which data they’ll be migrating as part of the data migration process. Here are their answers:
Sunset Period: We have announced that we will cease operations of Centricity Advance on June 30, 2012. The data will be available in read-only mode until December 31, 2012.

Data Migration: We are working with our partners and customers to figure out the best way to migrate data. We have told customers that we will migrate the following data:
a. Patient Demographics, Patient Insurance data, Fee Schedules, Appointments
b. Patient Summary
c. Patient chart
We will migrate all clinical data. We are working with our partners to determine which financial information should be automatically migrated.

Conflicting Indications of the Move to SaaS Based EHR

Posted on November 29, 2011 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.

One of the really interesting things I noted while attending the NextGen user group meeting had to do with the move to SaaS based EHR and other SaaS based EHR software. I partially mentioned this in the write up I did at the conference, including a tweet where I talk about how Scott Decker really pushed the idea of NextGen making the move into the SaaS based software world.

I think there’s little doubt that NextGen sees the value of SaaS based software. I think they see the convenience to doctors of not having to manage a server. Most importantly, I think they see the value of not having the healthcare data stored in EHR in silos.

One thing that Scott Decker mentioned in his keynote was improving their coding rules engine based on the feedback and experience across all of their SaaS based EHR users. I found this really intriguing since it highlighted some of the challenges and limitations of the client server EHR model that’s so prevalent in healthcare.

After hearing these comments about NextGen’s move towards more and more SaaS based software, I wondered what users at the meeting thought about the move by NextGen to SaaS EHR. The nice part of a user group meeting is I had a chance to talk to a number of them.

One company I talked to said basically, “We have 30 Citrix servers in our NextGen EHR installation. That’s a huge investment we’ve made and I don’t see us changing that any time soon.” They’ve got an interesting point. There’s a lot of money invested in training, equipment, software, and general understanding of the current client server EHR installs that NextGen employs (or is it employed?) for its large EHR customers.

It’s quite a stark contrast to consider this entrenched client server user base that is unlikely to change even if NextGen’s direction is headed towards SaaS EHR software. To be completely honest, I’m not exactly sure how this “conflict” is going to play out.

The iPad Opportunity – A Decent EMR Interface

Posted on November 4, 2011 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.

Yesterday, I created a post on EMR & EHR called The Must Have EMR Feature – An iPad Interface. that post has driven quite a bit of discussion on Twitter and Google Plus. One comment from @2charlie hit me the most though:

2charlie – Charlie Gaddy
A decent web interface wouldn’t hurt either. RT @ehrandhit: The Must Have EMR Feature – An iPad Interface dlvr.it/tYkN7

Charlie’s twitter response highlights a number of interesting ideas. The first point that every SaaS EHR company will point out is that he said a web interface. We could go into the semantics of what is “the web”, but I have little doubt that Charlie meant a browser based interface when he said web. I’ll leave the rest of the discussion of “web” EMR interfaces for another post (plus, we’ve had that discussion many times on this site).

Instead, I want to focus on his use of the word “decent.” That adjective is interesting because no one would really argue that there aren’t plenty of web EMR interfaces out there. If you look at the EHR Scope EMR Comparison site, you’ll see a huge number of web based EMR companies listed. However, when you add the word “decent” to web EMR interface, I think we could have some really interesting discussion.

At least a couple times a week I get a doctor sending me an email or posting a comment on my website saying that “all of the EMR interfaces are terrible.” I don’t necessarily agree that “all” EMR interfaces are terrible, but a lot of them do fit the description quite well. I’m sure at this point all the EMR companies are thinking about their competitors and agreeing with me.

The iPad Opportunity for EMR Interfaces
As I thought on Charlie’s comment of a “decent web interface” as compared with an iPad EMR interface, I realized that the iPad provides a unique opportunity for EMR vendors with less than stellar web interfaces. While it would be great for EMR vendors to create stellar web interfaces or improve their current web interfaces, that’s much easier said than done. Many are working on older technologies. Others have so much company culture built into their interface that it’s hard to change. Many have large user bases that will freak out at the idea of a new web interface. Etc etc etc! The point being that the culture and history of many EMR interfaces make it hard to change.

In these cases, I see the iPad as a great opportunity to start fresh with your EMR interface. Many EHR vendors could use the iPad as a way to be able to create a new interface for their EMR with all the knowledge they’ve learned over the years baked in. Doctors expect the iPad interface to be different and unique.

I’ll be interested to see which EMR companies take this opportunity and make something of it. It’s the perfect chance for EMR companies to create a paradigm shift in their EMR software without having to admit publicly the mistakes they made in their first EMR interface. Unless you happen to be from an EHR company who built the perfect EMR interface from the start. Then, this need not apply.

Avoiding EHR Performance Issues in the First Place

Posted on August 26, 2011 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 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.

Common EMR Implementation Issue – EHR Performance Issues

Posted on August 24, 2011 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.

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.

SaaS EMR versus Client Server EMR

Posted on January 2, 2011 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 think the debate over a SaaS based EMR versus a Client Server EMR is never going to end. Maybe we should just have a peace treaty and decide that whoever has a SaaS EMR is going to love the SaaS model and the benefits and features of a hosted EMR solution. The client server EMR people are going to love their in house “doctor controlled” EMR software with its inherent features and benefits.

What inspired this post? A few old threads popped up on my stats page. First, is a SaaS EMR versus Client Server EMR poll I did back in June of 2009 about which type of EMR setup people prefer. Here’s the results (as of this posting):
Client Server EMR (Client Install) – 35 Votes
Client Server EMR (Web based) – 28 Votes
Hosted Web based EMR (SaaS/ASP) – 84 Votes
Huh? – 3 Votes
Doesn’t Really Matter – 7 votes

That’s good enough as a tie for me. Probably reflects the chasm we have in EHR and EMR companies. There’s plenty of each to go around.

The above poll also led me to this post about the myth that a SaaS EHR is required to show meaningful use. I forgot that some EMR companies (or likely their sales people) were spreading these crazy myths about meaningful use.

SaaS EMR vs. Client Server EMR and AAFP in Denver

Posted on September 22, 2010 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 knew that my previous post about the cost to update an EMR would bring out the people who like to back the SaaS EMR model versus those who like to back the Client Server EMR. As I’ve said before, it’s one of the most heated debates you can have in the EMR space.

I realized in the comments of that post why it’s such a heated topic. It’s because once an EMR software chooses to go down one path or the other, it’s nearly impossible to be able to switch paths. Why? Cause if you do choose to switch you basically have to just code a new application all over. Basically, the switching costs are enormous. So, only a few software companies (let alone EMR software companies) ever change from one to the other.

Considering the high switching costs, that basically means that an EMR vendor that is SaaS based has a strong vested interest in the benefits and upside of the SaaS model of software development. The same is true for Client Server EMR software and client server EMR companies looking at the benefits and upside of the client server model of software development.

This entrenching around a software development methodology (for which they can’t change) is what makes discussing each model so interesting. Each party dutifully makes the most of whichever software development methodology they’ve been given.

Of course, from the clinical perspective it’s sometimes hard to cut through all this discussion and get good information on the real pros and cons of each model.

In that vein, I’m looking for a couple EMR and HIPAA readers that would be interested in making the case for one or the other. All you’d need to do is create a guest blog post on the pros and cons of your preferred method. If needed, you’d also be welcome to do a response post to the other method’s post as well.

If this interests you, leave a comment or let me know on my Contact Us page. I think this could be really interesting.

On a different note, it looks like I’m going to be attending the AAFP conference in Denver next week. Is anyone else planning to be there? Anything I should know about the conference to get the most out of it?