Podcast Episode 7: Building a Better EMR (EMR Part II)
Episode Summary: Our previous episode dealt with EMR issues relating to documentation quality and ease of use. In this follow-up episode, hosts Neal Sheth and Dr. Piyush Sheth explore concepts on creating a better user environment in EMRs and, on a wider level, improving EMR infrastructure.
EPISODE TRANSCRIPT:
NEAL SHETH: How can the complexities of medical documentation and coding be simplified? Can healthcare providers and professional medical coders maintain efficiency in an environment of ever-increasing complexity? This is Unraveling Medical Coding, and I'm your host, Neal Sheth. As usual, I'm joined by Dr. Piyush Sheth, also a Certified General Surgery Coder and author of Coding Solutions: General Surgery. Hi dad.
PIYUSH SHETH: Hey Neal.
NEAL: Before we get started today, just a quick note. Today's episode is going to build on our previous episode, episode 6, in which we discuss EMR best practices. So, if you haven't already listened to it, I recommend you go back, give that episode a listen, and then come back here.
Okay, let's get into it. Today we're going to do something different. Last episode, we talked about common pitfalls that EMRs present to healthcare providers. Since documentation drives coding, we discussed how EMRs can be problematic if they're not used correctly. Overall, it was a little bit of a depressing episode.
PIYUSH: That's right, Neal. We discussed a lot of examples of things going wrong when documenting in EMRs.
NEAL: Yep. You and I were talking after we recorded that episode and we realized that there are many fundamental design issues with Electronic Medical Records. We then got on the subject of how we would fix EMRs. It actually was a great talk, so much so, that I said, "we should make this into an episode!"
So here we are. Today, we're going to pretend that you and I have just been put in charge of fixing Electronic Medical Record software and utilization, and that we are able to build an EMR that is designed from the ground up to help document and code properly. This episode is a bit of a wish list for us, and we hope it resonates for you, the listener. A chance to imagine a better set of tools for the work we do.
PIYUSH: That's right. I've used EMRs, EPIC in particular, for over 12 years. I definitely have a lengthy wish list.
NEAL: Now, we realize that there are extraordinarily talented people who build these EMRs who must juggle all kinds of considerations when building these incredibly complex pieces of software. I'm sure that a lot of the stuff we talk about today may be difficult to implement or may lead to entirely new problems. I hope that the utility of today's episode will go beyond that and provide a chance to open a dialog between healthcare providers and EMR builders and do something that we really haven't had a chance to do yet on this show and try and come up with some foundational solutions to the problems we see. We hope that maybe it can inspire you, the listener, to more deeply consider how you use EMRs.
Without further ado, let's get started. What do you want to talk about first dad?
PIYUSH: I think the most logical way to proceed is to start by discussing how to improve the user interface, then practice and institutional optimization, and finally global infrastructure and implementation strategies.
NEAL: Sounds good. In Episode 6, We both agreed that a lot can be done to improve the user interface of EMRs. The user interface is often complex and difficult to navigate and allows errors to creep into patient charts while making these errors difficult to correct. There isn’t a lot of consistency and standardization in EMR software, which makes it difficult for people to effectively learn and use the software.
PIYUSH: That’s right Neal. I’ve got a couple of ideas about that. First, it’s important to know that EMRs like Epic were fundamentally written for primary care physicians. The interface is not easily customizable for other types of healthcare providers and specialists. Some providers, like nurses, have different interfaces, but as a whole EMRs provide a one-size-fits-all interface.
End users easily become frustrated and settle into using bad habits and shortcuts to complete tasks. For example, there is a phenomenon called “alert fatigue”. There are so many alerts presented to providers that most providers ignore the alerts. What if something important was ignored. What we need instead are “smart alerts”. Also, we need to improve the user experience. What if the EMR automatically found duplicate erroneous medical diagnoses or surgical procedures and flagged it for correction. EMR vendors can also do a much better job in providing education for physicians. I’m not kidding when I say that you need a PhD if you want to learn how to use everything in an EMR. Even after 12 years of using an EMR, I still don’t know how to use all the functionality that is built into them. Not that I need to know everything that’s under the hood but I think the user interface can be significantly improved.
NEAL: So, what’s to be done?
PIYUSH: Well, I think there are some potential solutions. First, let’s talk about software that can be easily customized for different types of users to offer better user experiences. Let’s look at Adobe Photoshop, a software program for photo manipulation that I feel is extremely well designed. Photoshop allows you to select from multiple different workspaces such as Essentials, Painting, and Photography. Each workspace interface is streamlined to show only those tasks that can be used for those individual purposes. This makes the software easier to use for people who may want to just do a simple photo touch up. A more robust workspace is available for Photoshop superusers that require much more functionality. And the best part is that you can switch workspaces with just a few clicks.
NEAL: To apply this to EMRs, it would make sense to have a simplified interface for say, primary care physicians, and yet another interface for each type of specialist, with each interface showing only those functionalities that each user would need.
PIYUSH: That’s right, and to go one step further, the interfaces should be much more modular. It should be easy for IT departments to create customized interfaces for individual types of providers by adding and subtracting modules.
NEAL: Yes, it’s like LEGOS. Each provider should also be able to personalize his specialty interface that contains what they need and nothing else. And, this wouldn’t take away from standardization because the standard interface would always be available to those providers and organizations that want it.
PIYUSH: Exactly. It makes much more sense to have a main screen containing the most important and basic functions, and then let the user add a “surgeon’s module” or a “primary care module,” depending on each users’ needs. One of my main criticisms of EPIC is that the user interface I use as a general surgeon is the same as that used by a primary care physician or an orthopedic surgeon. Rarely in the real world does one size fit all.
I will say one thing for EPIC. I am a big fan of their ‘Communication’ module. This is where I tag my documented note to be sent to the referring physician. Just a few clicks and EPIC then takes care of sending it to that physician behind the scenes. No more standing at the fax and hearing a busy signal. Once I click send, EPIC does all the heavy work on its own.
NEAL: Okay, so let’s go up to the next level. Practice and institutional optimization. I know from previous jobs I’ve worked in that maintaining server infrastructure is usually a huge undertaking for any institution. There is a huge burden on IT departments to stay up to date and ensure that the EMR runs without glitches. Unfortunately, the burden and expense sometimes force institutions to cut costs by using outdated software, becoming lax on the maintenance of server infrastructure, and causing the system to work less than optimally. It begs the question: what is your IT department’s budget and is it enough to give the most up to date EMR experience?
PIYUSH: Good point Neal. Hospital systems are often forced to be middlemen in delivering the technology, which is not something many are good at doing. In the early days of EMRs this made sense, but now these burdens are really preventing EMR’s from being used optimally. Software is not being kept up to date, which is preventing standardization and keeping costs high.
NEAL: Yes, and it’s interesting to me in this era of cloud-based, standardized, high economy of scale solutions, EMRs have remained decidedly stuck in an earlier era.
I think one of the main issues is that there is actually a disincentive to implement new improvements. Because of the requirement for institutions to finance backend infrastructure, each IT department must take new versions of Epic and customize it for their institutional implementation. The software upgrade may need to be modified and vetted. Vital signs, ICU monitor data, ICU monitors, laboratory machines, and a host of other equipment must flawlessly communicate with the EMR. This process can take up to 6 months. This is incredibly expensive and time-intensive, often leading to bugs, incompatibilities, and other headaches. Thus, many IT departments will continue using older versions of EMR software until they absolutely have no choice but to upgrade. This can often result in a cascade of issues that ends up costing more than the upgrade is worth in lost productivity and technical issues.
PIYUSH: Also, because this system causes so many headaches during upgrades, many users now associate any software updates or changes as bad, and resist these changes. This resistance to change, and the lack of education surrounding how EMRs actually work, creates an aversion to maintaining up-to-date, efficient EMR systems in favor of the status quo. Think back to when Microsoft Office was sold to each end user on CD disk. The end user was responsible for installing, upgrading when necessary, and in general dealing with lots of headaches when the product didn’t work well. Compare this to the ease of using Google Docs, with its always available, up to date software that can be reached from any browser.
Of course, all this raises the question, what is to be done about it?
NEAL: Well, if an institution is going to use its own servers and delivery infrastructure, I’d recommend making sure the software is as close to the stock version of the software. In EPIC, this is called the Foundational version.
For this, Epic should take more direct control. I’m thinking of something along the lines of Microsoft Enterprise. Just like Microsoft does with its popular “Enterprise” business software, Epic could create a required list of necessary server hardware and infrastructure each institution must provide for Epic to run on. This strategy has helped Microsoft Enterprise offer a standardized solution to businesses large and small while maintaining security and ease-of-use. If EPIC were to centralize the software, institutions would only need to maintain the server infrastructure.
PIYUSH: Well, all of these solutions still depend on healthcare organizations maintaining the EMR infrastructure. Are there any other solutions?
NEAL: I’m so glad you asked. Yes, there is in fact a solution that gives providers a way to plug into an EMR without having to maintain the backend infrastructures themselves. This is by using a cloud-based EMR. An example of this is Practice Fusion. Practice Fusion is targeted at smaller practices, but the concept goes like this: A company maintains cloud servers containing the software that any provider can subscribe to, just like Netflix provides a reliable and streamlined service by using Amazon Web Services to hold their content thereby allowing any user to get an excellent experience on virtually any device configuration. Healthcare institutions would essentially outsource EMR services to experts who can leverage economies of scale to provide better, cheaper EMR implementations.
PIYUSH: This seems like the ideal solution! Why isn’t anyone doing it?
NEAL: There’s some movement in this space, and I’m convinced that it is the way of the future. But, it’s important to note that many hospital systems are reluctant to cede control of EMR software, even if it means lower costs and better EMR implementation for everyone. And the vendors are reluctant to implement these solutions as well. After all, right now Epic has it pretty good. It makes software that organizations buy, and then it is those organizations, not Epic, that have to deal with the headaches of implementation. If Epic were to offer its software in the cloud, all of a sudden it would be responsible for implementing its own software. That’s my theory anyway.
In the end, it may take a spectrum of solutions to improve EMR implementations, from simple standardization and centralization all the way to cloud-based EMRs. My gut feeling however, is that once a few big systems go cloud-based, the dominos will start to fall. The cost-benefit is just too good.
PIYUSH: Okay, one more thing I wanted to talk about. As a physician who’s worked during the entire COVID-19 pandemic, I’ve seen a lot of changes to the way the healthcare industry has embraced digital tools. I wanted to talk about some of them, especially in relation to EMRs. The rise of Telehealth has been profound. When it became imperative that even with social distancing, wearing masks and quarantining, that we still needed to provide healthcare services, EMR’s developed modules to allow for Telehealth services. How they did this so fast was impressive. Yet when providers call IT to ask for something to be changed in the software, it can take years if at all for those changes to be implemented. COVID exposed the fact that if EMR vendors are mandated to change, they will.
NEAL: Well, I think that may have been our longest episode to date!
PIYUSH: Sure feels like it!
NEAL: Ha, well let's just end there then. We hope you enjoyed this episode. If you want to find more episodes of Unraveling Medical Coding, just search for and subscribe to Unraveling Medical Coding wherever you find you podcasts. You can also rate the podcast and leave us a review on Apple Podcasts. Please share this podcast with friends or colleagues who you feel would benefit from learning about medical documentation and coding.
Also, before we go, I just want to make one shameless plug. My dad has written a book on General Surgery coding aptly titled Coding Solutions: General Surgery. It's full of an unbelievable amount of coding knowledge distilled from his 26 years of experience as a General Surgeon. It's like a cheat sheet to getting all that experience without, you know, having to spend all that time learning it. It's great! You can find a link to buy it on our website unravelingmedicalcoding.com.
Stay safe and stay healthy.