Back to EHR Basics (Part 2)

Let me recap my previous blog post: I made the argument that the customer (aka EHR user) doesn’t always know what she wants, and it’s up to the IT analyst to provide for the users’ needs. I also posited that standardization and EHR vendor alignment is often a good thing, and that sophisticated healthcare systems across the country are pulling out perfectly good build to replace it with recommended configuration from the company that produces the software. Some IT folks are understandably uncomfortable with these changes because they now see themselves as “the heavy” and must tell end users that they can’t always get what they want.

As a CMIO and former vendor myself, I understand why anxious IT analysts don’t like saying no. I have to say no a lot. Saying yes is a lot more fun!

• “Can we duplicate the workflow they do on the floor below us but change it ever so slightly for no good reason?” Absolutely! Why not?
• “Those doctors won’t document the thing we want them to document, so we’re creating a new order that’s not really an order so that they can order the thing. Sound good?” Are you kidding me? Good? It sounds fabulous!

Sure, it feels good to say yes, but it’s probably not in the best interest of anyone (clinician, hospital, or patient) to say yes to these requests.

Personally, I love following vendors’ recommendations. Why? Because if it doesn’t work out, I know where to go for resolution. (Vendors, I’m looking at you! Do you feel my eyes searing through your souls? You do? Good.) My team has heard my mantra over and over: we follow industry best practices and vendor recommendations for all build decisions unless we have clinical or operational reasons to do otherwise. Seems pretty obvious, but saying it aloud and often helps me and our IT analysts do the right thing with minimal pain.

When a physician asks for build or configuration that we know is a bad idea, we shouldn’t just say, “Sorry, doctor. No can do. Our vendor doesn’t like us to do it that way.” If we go with that tact, everyone should expect fireworks. And rightly so! If I were that doctor and you told me that the vendor to whom we just paid millions (maybe tens of millions) of dollars doesn’t “like us to do it that way,” I’d be . . . unhappy. And vocal about my unhappiness.

How should IT analysts and physician informaticists respond to requests for “bad build”? With data and evidence and experience, that’s how. Try these responses on for size:

• “I know you want this list to have items that you often choose at the top, but not everyone is like you. Different people frequently choose different items from this list. We try to follow usability principles and order items in a list in a predictable way. In this case, we’ll order the items alphabetically. Is there a reason that won’t work for you?”
• “I understand you want a customized report that is almost identical to the report that’s already available. Is there a clinical or operational reason that the existing report won’t meet your needs? If so, we can likely modify the existing report so that it can meet your needs as well as those who are already successfully using it.”
• “Thanks for requesting a new EHR alert to remind physicians about the NEJM study. Industry best practice tells us that alerts should be actionable, so we’ll be modifying your proposed verbiage and adding links to take doctors right to the order set that they’ll need to care for the patient. Do you agree that the changes help make it easier for physicians to do the right thing?”

In my experience, when most loud users are unhappy with build decisions, they have no logical or rational explanation as to why. Most commonly, I hear, “That’s how we’ve always done it” or “That’s not how I was trained.” Instead of arguing, I go back to my mantra: “Doctor, do you have a clinical or operational reason as to why the proposed build won’t work? If you do, let’s talk about it. If you don’t, let’s try it this way.”

Helping users understand the downstream and future implications of their desired build is also an effective way to redirect them. Do your users understand the need for discrete documentation for accurate and easy reporting? Do they realize that the way they order may impact the ability to serve up clinical decision support that they actually want? Do the users with whom you work regularly think about the billing implications of different yet similar EHR tools? Typically, the answer to these questions is no, but when you point them out, folks often understand why a different way might be best.

In summary, clinicians can be an ornery bunch when it comes to IT build (shocking, I know!) Yet, almost by definition, clinicians respond to evidence and best practices. Just ask doctors why they prescribe this medication or operate in that way – the answer: evidence and best practice. If we can apply evidence and best practice to our IT build, and explain it in a way that our clinical users can understand, we’ll change a lot of negatives to positives.