What It Means to Be a “Document Whisperer”

I’m writing today to share some stories from my career path in Applied Clinical Informatics, and how I became a ‘document whisperer’ with regard to clinical workflow design. This post stems from a common question I get asked:

‘If you care so much about clinical workflows, then why do you seem to care so much about bylaws, policies, procedures, guidelines, protocols, bylaws, charters, order sets, and other documents? Why don’t you just worry about the things inside the EMR?’

The reason is because all of these documents (whether they are inside or outside an EMR) work together to shape clinical workflow.

To explain, I need to first offer some context.

Back in 2007 when I first started my formal clinical informatics career, like most newcomers, I didn’t yet have enough experience to fully understand my role. I figured my job was to ‘help with the electronic medical record,’ so naturally, I focused mainly on the things that doctors interacted with inside the EMR.

After a while, however, I started to see challenges we had with some of our projects. There were order sets that, after we built them, didn’t get used. There were order sets that created turbulence with other workflows when we rolled them out. I received complaints from doctors who felt the computer was ‘too clunky’ and that ‘it takes too long to get things done.’

Initially, I wondered if this was simply a matter of an EMR just being more difficult to use. There were some people who told me, ‘Oh, some doctors are just resistant to change’ (which is partly true), and others who said, ‘Computers are just complicated and finicky’ (which can also sometimes be true).

But I kept looking for a better answer. There must be some sort of symmetry here that I was missing.

And then, over the next 2-3 years, I experienced two important things:

1. I once worked on a complex titration protocol, which required an extensive analysis to fully build out the protocol, and
2. One day, a registered nurse complained to me about a policy that would need to be updated — in conjunction with a project we were actively working on.

While confronting the question of, ‘How exactly do you write a protocol?’ I started to really confront this question: ‘What exactly is a protocol?’ This led to even more questions, such as:

Searching for more concrete answers, I looked to various potential sources, including various regulations, the International Standards Organization (ISO), the National Institute of Standards and Technology (NIST), the CMS web site, various Health IT/Informatics societies, ITIL, and even Black’s Law Dictionary, without much help.

And so, around 2010, I decided to look at this from a more analytical, design-thinking standpoint:

“If we gathered every document in healthcare — both those sitting on desks and on hard-drives — what would they be, and what would they look like?”

This led me to scribbling down some commonly-used words people use in healthcare, putting them into a spreadsheet, and in 2010 I came up with my first CMIO’s Checklist.

This turned out to be my first real foray into clearly-defined terms, tools, and functions. Yes, a sample size of one — based only on my own clinical and administrative experiences — but a fairly comprehensive function-based analysis, nonetheless, that helps to clarify concepts and increase shared understanding.

Now with this new function-based analysis in hand, I stumbled into two interesting functional definitions:

Template (n.) – Tool used to standardize and expedite the creation of a document

Document (n.) – Tool used to record and transmit information

Both of those shed light on an important concept. For many of you, this may be common-sense or trivial, but for me it was a ’Eureka’ moment:

• Definitions can be used to create templates.
• Templates can be used to create documents.
• Documents can be used to store and transmit the information needed to support workflows.

Around 2015, this led me to the realization that these concepts all depend on each other. And so, realizing that workflow inconsistencies sometimes arise from misalignment of these concepts, I wrote this blog post about workflow management and the Clinical Informatics domain

This also led me to the realization that all of the documents and tools contained in drawer #4 above:

• Needed to be aligned with the workflows, goals, and mission above it, and
• Were shaped by the concepts contained in #5, #6, #7, and #8 below it.

It also revealed to me that some of the documents and tools that support workflows are typically contained inside the EMR, and others were contained outside of it.

So now being able to mentally visualize this conceptual structure (above), I also realized the following:

• Workflow depends on all of these tools (above) for support.
• Changing workflow means changing all of the tools (both inside and outside the EMR) that are used to support the workflow.

Therefore, effective workflow change management means:

1. Clearly understanding each deliverable (tool) above.
2. Identifying the deliverables (both inside and outside the EMR) that are needed (or need to change) to support the desired workflow.
3. Quickly drafting those deliverables, to demonstrate to users and health IT professionals how the deliverables need to fit together,
4. Reviewing those draft deliverables with clinical stakeholders, to confirm their needs/expectations before committing them to a formal build, and to help get their input and align expectations.

To help quickly draft the deliverables in step #3 above, I had to quickly make templates for these roughly 24 documents that we commonly use in healthcare. And this brought me back to my pursuit for high-quality, high-grade definitions so that my workflow templates were quick, easy-to-use, and maybe most important – functionally sound.

And this is essentially how I became a document whisperer for good clinical workflow design and EMR support. Using this deeper understanding of how these common concepts are related has helped me to quickly draft the ‘workflow blueprints’ that help to outline workflows, identify deliverables, identify stakeholders, create clarity, develop understanding, and align expectations before beginning a project. (This understanding has proven especially useful when scoping/analyzing clinical project requests prior to approval.)

I hope sharing this journey helps give you a roadmap for your own journey, and helps you develop your own definitions, templates, and tools for rapid workflow analysis and scoping before undertaking any significant projects.

This piece was written Dirk Stanley, MD, a board-certified hospitalist, informaticist, workflow designer, and CMIO, on his blog, CMIO Perspective.