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