Insights on EHR Implementation
Recently, the KLAS team shared an interesting statistic with me from their Arch Collaborative effort. In the course of KLAS’ research, there have been 340 instances where two physicians of the same specialty using the same EHR in the same organization have reported nearly opposite responses to the question, “Does the EHR enable you to deliver quality care?”
One physician responds, “Yes! It really does!” and the other responds, “Absolutely not!” In over 90% of these cases, the physicians who agreed that the EHR helps to provide better care also reported better training, more training, and more EHR personalization.
This aligns with my personal experience working at Asante. In general, I have found that the more time a doctor spends with someone who can help them navigate their EHR experience — whether it’s personalization and optimizing their existing EHR or learning a new tool — the better.
However, there are two sides to a clinician’s success with the EHR. Training the clinician is vital, but what about the development of the product by the vendor and organization’s IT leadership? Are they building something that is navigable, or are they simply pushing the vendor’s stock offering live without thinking through the end-user experience?
In my experience, I’ve seen too many clinicians placed in front of overly busy screens that are populated with too many flashing alerts and information demanding attention. Often, most of this noise doesn’t even correspond to that clinician’s workflow.
My EHR Implementation
We’ve been live on Epic at Asante for around five years. In that amount of time, I’ve learned a thing or two about optimizing the EHR for our clinicians. Reaching a functional state depends on the department. For example, the ED was pretty functional at our go-live.
Much of that functionality came from our engagement of key user physicians and nurses beforehand. Asante brought these users into the conversation early and paid for them to become credentialed trainers and key users. The resulting experience they gained transferred quickly to other users in a peer-to-peer model.
Moreover, these clinicians became intimately involved in the ED module design process. I was fortunate to be one of those credential trainers at the time. During this process, I and two other physicians recognized that some of the orders we tested did not actually work in production. When we uncovered the issue, we had no sense for its scale. We didn’t know whether we had happened to pick a couple of buggy orders or whether we’d found a dead canary in the coal mine and that tons of orders wouldn’t actually work in practice.
To solve the problem, the three of us got together and spent three weeks and a few gallons of coffee to compile a database of all of the possible medical scenarios that could find their way to the emergency department. I’m surprised the effort only took three weeks!
At the end of those long weeks, we had finally built out a comprehensive list of medical scenarios and their corresponding orders. We then divided the orders and began inputting them into our instance of Epic’s EHR. We discovered 400 orders that either did not exist or were broken in some fashion.
We then subdivided our list further into what we consider to be critical orders and noncritical orders. All told, we identified 80 broken orders as “critical.” We discovered all this just about a month before go-live. In an eleventh-hour save that meant working with our IT team, I am proud to say that all 80 critical orders were in production and fully functional a week before go-live. The difference this made for our ED doctors was palpable. Unfortunately, the other 320 orders required six months to fix, but we eventually got those in as well.
Getting the kinks worked out of our ED module meant bringing together both sides of the clinical divide. Both the clinician and the IT analysts had something to offer, and working together on our issues led us to success.
Healthcare's Jack of All Trades
EHR vendors never seem able to create an elegant human-computer interface. That is, they tend to make a product that tries to be all things to all people. So they pump out an EHR that includes every bell, whistle, and nuance as a potential model build. What many health systems seem to miss during implementation is the importance of sitting down in front of that multi-workflow screen and ripping out the specific pieces that do not fit the workflow of that role—be it physician, nurse, PSR, etc.
Imagine you’re on the assembly line at a Toyota factory, and your job is to make carburetors, but the computer that you leverage to do your work is flooded with information about tires, interior carpeting, and transmissions—none of which correspond to your world of making carburetors. That is the constant battle I fight in my role as CMIO.
I’ve come to find great joy in putting myself in the shoes of the people using these workflows and ripping out shiny distractions that don’t belong. It’s important to leverage strong relationships with clinicians with the intent of engaging them in conversations on what should stay and what should go (sung to the beat of the old Clash song). After all, these clinicians are best positioned to navigate their own workflow. I often find myself encouraging them to speak up and say, “Pull this out, pull that out, and pull those out, too.”
In the end, when it comes to working on EHR workflows, less is frequently more.