If you read my recent blog post, you’re aware of Mike Monteiro. He’s a designer in the tech space, and he’s pretty outspoken. He runs his own design firm, so . . . he’s allowed to say what he thinks. In an interview this summer, he said something that stopped me in my tracks: “The two most important words in design are why and no.”
When I heard this, in my head, I replaced the word “design” with the words “electronic health record (EHR) configuration.” As many physicians have come to realize, once you’ve seen one implementation of Epic or Cerner or Allscripts, you’ve seen . . . one implementation of Epic or Cerner or Allscripts. Why is this so? Because the big EHR vendors sell very expensive software that can be configured or – heaven forbid – customized to meet the specific needs (or more likely wants) of the hospital or clinic. Didn’t realize that EHR Brand A can look and act very different at different locations? See my explanation here under Myth #5.
Large health systems with complicated EHRs employ specially-trained information technology (IT) analysts to set the levers and switches behind the scenes so the software behaves in the desired way. Those analysts depend on a variety of sources and information to help them do their jobs. Often, they have requests to create an alert to do that or develop a documentation tool that does this. It would be easy to just read the change order and implement it. As our parents told us, though, the easy way may not always be the best way.
Getting back to designer Mike Monteiro, in this interview he says:
Five letters and we can redefine an industry. “Hey, we need to collect all of these e-mail addresses.” Why? That doesn’t need to be an antagonistic question. That’s a question that you need to ask before you do anything. “Oh, so we can send them these valuable coupons. Oh, ok, that sounds pretty good.” You gotta know why you’re doing this stuff. If you ask why enough, and you’re not satisfied with the answer, or you believe the reasons you’re being asked to do something run detrimental to the people that you’re designing for, the people on the other side of the screen, you gotta be able to say, “No.”
This is true for designers, and it’s true for healthcare IT analysts. Just because a request comes in doesn’t mean that the request is valid. If we don’t understand the request or especially the rationale for the request, we must ask why. Why do you want to add a new order? Why is it important to force the physician to document this point discretely in this specific workflow? Why does the nurse have to stop what he/she is doing to get approval for the next step? Why, why, why? We must keep asking why until we’re satisfied with the answer.
We can’t rest on our laurels at this point, though. Now that the why is understood, it might be a good time for the no. No, I don’t think it’s a good idea create this new workflow as it’s almost identical to one that’s working just fine. No, we shouldn’t make this order question mandatory because it’s not essential to the order itself. No, the nurse shouldn’t have to manually drop the charge because we already know that he/she performed the action. No, no, no.
As Mike points out, asking why and saying no doesn’t have to be antagonistic. Oftentimes, clinicians and operations folks are asking for specific changes to the EHR because they don’t know what they don’t know. They may be clinical or operational subject matter experts (SMEs), but they don’t understand the EHR as well as the analyst (see my post for a deeper dive on this point.) Frequently, after a thoughtful and calm conversation, the requesting user is ecstatic to learn that there are other options out there to solve their particular problem. When all is said and done, users want the best option, not the option that they requested.
If a health system wants their analysts to be able to ask why and say no, excellent governance must be in place to “protect” the IT folks. While this might seem obvious, it’s often an afterthought. Rarely, someone up the food chain gets offended at the thought of an analyst even asking questions yet alone saying no. These folks must be protected from such unfortunate circumstances.
When I was a senior resident and I found an attending castigating one of my interns, I stepped between them and took the attending aside. I told the good doctor that if he/she had issues with my interns, he/she should yell at me, then I’ll deal with the intern on my own terms. A “fight” between an attending and an intern is inherently unfair, while such an interaction between an attending and a senior resident can be tenable. Similarly, if an attending or nurse is upset with an analyst and needs to vent, he/she should talk with the CMIO or Physician Champion, who often can take a figurative punch and give one back if appropriate.
With proper training and experience, why and no are powerful ideas that can lead to improvement all around. Leadership, however, must ensure that those who are in the trenches are free to do their jobs as best they can.
Have ideas about why and no? Contact me!