Easing the Tension of Physician Documentation

How much structure should your physician documentation include?

It’s a question CMIOs, CIOs and other hospital IT leaders wrestle with every day. You already know the answer: “It depends on my CDI tool.” You also know that’s not the answer your physicians want to hear. That’s why these end users wonder – rightfully so – why they’re forced to use solutions that don’t solve their daily challenges.

The May issue of Healthcare Informatics outlines this struggle accurately in its cover story, “Balancing Act: Can CMIOs and CIOs Make Physician Documentation Work for Everyone?” In particular, this segment perfectly illustrates the tensions felt by physicians – and, by extension, the CIO:

Part of what makes all this so hard is two sets of overlapping tensions, says Bobbie Byrne, M.D., vice president for health information technology at Edward Hospital, a 309-bed, community hospital-based integrated health system in the Chicago suburb of Naperville. “There are really two tensions,” Byrne says. “One is the free text-versus-structured-documentation tension, and the other is the tension between the physician documentation as a billing vehicle and as a clinical communication tool. […] Identify the data elements that need to be structured and then leave the rest to the individual physicians’ preferences, because in reality, a relatively small proportion needs to be structured.”

So how can this tension be eased? Is it even possible, given the natural divide between the clinical data needs of the hospital and the fluid workflow of physicians? We certainly believe it is; our business is built on providing solutions that close this gap. It comes down to one simple suggestion: Give physicians the freedom to design their own documentation.

Too many CDI solutions approach the clinical note as a commodity. They offer a rigid electronic documentation structure that heavily prioritizes downstream data requirements. Right out of the box, end user productivity is compromised. Physicians tune out. They develop workarounds and avoid using the CDI tool as much as possible. The irony is that without physician adoption, the data-driven benefits these tools aim to provide won’t come close to fruition.

We can’t lose sight of the fact that we’re asking physicians to alter a very important – and very personal – part of their jobs. And the only way to know we’re getting it right is to let the end users guide the design of the finished product. By achieving high rates of physician adoption, CIOs can finally focus attention on other priorities.

“Structured versus unstructured documentation? I let my physicians determine the mix they want.” Wouldn’t it be nice to give that answer – and mean it?