In my last post, I discussed how I think the Broken Windows theory can be applied to the electronic health record (EHR) and most things health IT-related. Essentially, I posited that minor problems with the tools that doctors and nurses use all day long can – over time – decrease the trust that users must have in the system that is provided to them. While typos and insignificant miscues may seem meaningless to the IT team, they can be confidence killers over the long term. I argued that these issues must be rooted out and fixed, but I made no recommendations about how to perform said rooting out. Here, dear readers, are some ideas.
For the same reason that it is difficult to edit your own writing, we often need to look outside the IT team to evaluate our EHR build and configuration. To the project managers and analysts who built and maintain the Epic or Cerner or MEDITECH (shall I go on?) system, their code and decisions are their babies. It’s a truism that all babies are beautiful to their parents (I’m a pediatrician, and I learned that early on!), hence perhaps it’s not a good idea to ask the “parents” of the EHR to point out its ugly bits. No, to do that work, we need outsiders. Folks who are not too close to the build are the ones best suited to give constructive criticism.
Another problem that needs to be overcome is that silly human trait called adaptability. We naturally adapt to the environment around us, and when it comes to technology, this is both good and bad. A clarifying example of this is to look at what happens when you wake up in the morning and notice that your favorite phone app has been updated overnight. It used to work like “this” but now for some insane reason the developers moved a button and added some odd color and now it works like “that.” Naturally, you hate it. The app was perfect before, but now it’s evil and you’ve lost your muscle memory, and why did the engineer fix what clearly was not broken? Here comes the funny part: a few weeks later, you can’t even remember how it used to work. You’ve regained your muscle memory, the app seems fine, and you might very well believe that it always worked like this.
Clinicians who have been using an app (or a documentation template containing typos) naturally adapt, and many begin to overlook or just accept the problems. To do a great job at identifying these broken windows, it can be helpful to have a fresh set of eyes on the problem. New clinicians to your organization fit the bill. Minor issues that others may have subconsciously glossed over may stand out like a sore thumb to new doctors and nurses. Empower these folks to seek out and report on issues no matter how seemingly insignificant the issues may be. You may have to convince the newbies that you are truly interested in hearing about everything that is not perfect in order to overcome the natural disinclination to complaining when brand new at an organization.
While most of us adapt and move on, a select few among us just never give up. We call these people stubborn; some call them “complainers.” I call them “dedicated perfectionists” and I salute them! (Many who know me realize that I count myself in this group, so in full disclosure, my positive spin on their attributes may be somewhat self-serving.) These folks see the two periods in the third sentence of the fifth paragraph of the documentation template and demand change. Detail-oriented clinicians who want everything to be “just so” are excellent resources to point out broken windows. While you might want to avoid them at med staff meetings, don’t do it! Embrace the help they can offer.
If you’ve identified who can help you find problem areas and have communicated to them that you want to hear about the problems, yet it’s still all quiet, don’t assume you’re in the clear. If you’re looking for feedback about your build, configuration, and content, yet your help desk isn’t set up to make it easy to send that information, I promise that you’ll never get it. I’m imagining a monkey with its hands over its eyes: see no evil! Do your clinicians need to call the help desk to submit a ticket? Do they need to jump out of their EHR to log into a different system to get the issues to you? Do they have to send an email? The more obstacles you place in front of them, the less surprised you should be that you’re not hearing from them. Make certain that your help desk makes it easy to send you the information that you want. (And if it doesn’t, let’s talk. We can run the diagnostics on your help desk to make sure it’s actually helping.)
You might see a pattern with these blog posts. A few weeks ago, I wrote about why broken windows in your EHR are important to fix. This post focuses on how to find those problem areas. Will the next post deal with how to fix them? Heck no! These should be minor things that can be easily remedied. You’re definitely on your own at this point. I’m going to go do something important like binge watch a new series on Netflix, or HBO, or one of the other fifteen services I pay for. Now get back to fixing your windows!
