The importance of communication: The “right” technology approach starts with communication

Some years ago, while working for a health care organization, one of my duties was to work with clinicians and our electronic health record (EHR) vendor to tailor the EHR to the clinicians’ needs. One particular day, I was talking to a resident in the ICU, discussing the various places in the EHR where he could review patient data. I don’t remember all the places I showed him – probably an app that would show what had changed since the last time he logged on, a quick view app that showed abbreviated views of the data and an app that showed a more complete view, from which he could navigate to screens that showed data trends, ordering screens, clinical references or medication administration records. Eventually though, he said, “I just want something I can print out and write on while I’m rounding.” 

I had been showing him things that weren’t designed for what he wanted and didn’t suit his needs. The creators of those apps were accommodating other needs. And I was showing him things that weren’t what he wanted. 

The common thread in this series of blogs has been the importance of communicating clearly and achieving a common understanding. These pursuits are of critical importance in designing, building and implementing health care IT, where the clinicians and the computer geeks speak different languages and often have very different thought clouds bobbing above their heads. In this arena, it’s crucial that whichever of the two sides we find ourselves in, we shelve our assumptions about what the other side understands about our side and what we understand about the other side. Clear, open communication builds understanding – to the point that maybe we’ll find we aren’t on different “sides” after all. 

Now, just another word about that example I started with. It’s arguable whether what the resident wanted was the “right” thing. Maybe the EHR and all its apps provided a better solution to his needs than printing something out and writing on it. The customer/user doesn’t always recognize the possibilities that are out there. Consequently, some innovators, channeling Steve Jobs (“A lot of times, people don't know what they want until you show it to them”) and Henry Ford (“If I had asked people what they wanted, they would have said faster horses”) might say, “Don’t ask your customers what they want – in fact, don’t even talk to them. Just anticipate what they need, and build it.” 

I would suggest a slightly different, more tempered approach. The late Clayton Christensen (1952-2020) - author, consultant and former Harvard Business School consultant, used to talk about the job to be done. He posited that to design or identify what a customer needs, you need to hone in on what “job” customers need your product (or potential product) to do for them. And you need to separate that “job” from the solution. In the previous example, the “job” the resident needed the application to do was to quickly and conveniently show him his patients’ most salient data – no matter where he was – and allow him to record notes. The “job” was neither to provide a printable data sheet nor to provide a plethora of apps with lots of functions. Once that job was identified, IT people would then be free to explore several options and design or identify the solution that would best and most practically do that job. 

So, whether or not the tech guys ask the clinicians directly, “What do you want?” isn’t the point. The point is that two-way communication needs to take place to glean the “job to be done.” The more that both parties participate in such communication, the more likely it is that the result will be an application that does “the job.” 

Tom Oniki, PhD, is a director of medical informatics for 3M Health Information Systems.