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

Top 5 Ways Healthcare Applications Slow Down and What To Do About It

Posted on October 4, 2018 I Written By

The following is a guest blog post by Jeff Garbus and  Alvin Chang from Soaring Eagle Consulting.

We spend a lot of our lives tuning applications that people complain are too slow. In no particular order, here are some of our findings.

Poor indexing #1 – Unused Indexes, Missing Indexes can cause problems

While I’ve said, “in no particular order,” I do have to say this one is usually first. When applications go through Q/A / Stress test, there is often a lot more horsepower than there is data. As a result, the memory and CPU combination mask the otherwise bad performance. Once the application hits production, larger volumes of data are not managed as effectively.

On the plus side, you can almost always add an index (or indexes) without causing other application side effects.

Warning: Do NOT automatically add indexes as recommended by a DBMS’ tuning advisor; they often miss opportunities, and also often significantly over index by recommending multiple similar indexes rather than one enveloping one.

Be wary of overindexing as too many indexes can also create overhead that will cause processes to slow.

Bad queries #2 – Too much data returned by a query

Sometimes you are simply bringing too much data back from the database to the front end. I saw a search recently that brought about a half million rows of data back to the end user. I asked, “What is the user going to do with that much data?” Answer: “They are going to look at the first few rows and refine the search.”

This unnecessarily stresses the disk CPU, memory, and the network.

Easiest solution: Bring back only the data the user is going to work with. Perhaps the first few hundred rows. Save time, disk resources, and network resources.

Bad queries #3 – Overuse of temporary tables

Many applications use temporary tables incorrectly or are wasteful with them. For example, they are used

  • When the programmer wants to avoid joins (which the server is very good at!);
  • Are filled with lots of data, then rows are deleted (why load them in the first place?);
  • Or too many columns are used (why select * when the columns aren’t being used?) – this increases network bandwidth, as well as making the table unnecessarily big
  • Joining temp tables is another way developers often misuse server resources. Without indexes, this is very costly

Avoid temporary tables

Bad Queries #4 – Attempting to do it all in one Giant Query. 

Sometimes the opposite can also be true. When attempting to write a query for a process, Developers can get stuck in the mindset that a single query can solve all possible conditions of a query.  This leads to large complicated queries that in addition to being difficult to decipher. Can also generate excessive numbers of worktables as it attempts to place large subsets of data into worktables.

Large Reports #5 Combine reporting and transactional activity

It is very common to allow reporting off highly transactional databases. The problem is that reporting creates shared locks on resources, and transactions can not modify the data while the locks are held. In addition, reports are often ad hoc, so that the load on the server is unpredictable.

Easy solution: replicate production data to a reporting server. If replication or other high availability is unavailable, use dump/load to keep day old data for reporting purposes (this is often sufficient).

Allow direct downloads of data

Some companies allow “super users” (also sometimes called “analysts”) to download production data, real time, to applications like Microsoft Access. In addition to being a likely security violation, this also creates blocking issues for the online users.

Solution: Data replication, as above.

If you’d like to learn more about how to improve slow applications, sign up for our webinar “Are your Servers, Apps, and EHR systems ready for a spike in website traffic?

About Jeff Garbus and Alvin Chang
Jeff Garbus founded Soaring Eagle Consulting 20 years ago, and Alvin has been his right hand for almost 30 years now. Together they have authored or coauthored 20 books and dozens of articles on Database Management. Soaring Eagle Consulting is an On Shore HIPPA and PCI compliant remote database management company that is available for projects and consulting work on Architecture, Performance and Tuning, Scalability, application development, migrations and 24×7 full operational support. Do your DBAs need a best friend? Jeff, Alvin, and the On Shore GURU level database team are here to help you!

Soaring Eagle is a proud sponsor of Healthcare Scene.

“Our EMR is So Slow”

Posted on September 1, 2011 I Written By

John Lynn is the Founder of the 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 and John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

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.