Tips and Tricks for Clinical Workflow Redesign

 Hi fellow CMIOs, CNIOs, and other Informatics friends,

Today I thought I'd share some materials I delivered in a talk back in 2023 for Dr. Judi Binderman, a really seasoned Clinical Informaticist and good friend of mine. I recently discovered these when going through some old slides. At the time, Dr. Binderman had asked me to speak briefly to her team at Community Medical Centers in Fresno, CA about some helpful tips and tricks of clinical workflow redesign : 

My talk was mostly related to workflow analysis, change management, documenting workflows, and workflow design. So I opened up first with a brief discussion about workflow analysis and change management : 

The first point that I usually emphasize for any new Clinical Informatics leaders is that work can be measured and estimated through a workflow gap analysis. The distance from the current state to the future state gives you a good estimate of the stakeholder(s) you will need to involve in a project, what they will need to learn and do (to achieve your future state), and so this gives you a good estimate of your project deliverables and project scope (for planning purposes) :

Once you have completed your gap analysis to get a sense of the current-state and future-state workflows, you can then review a list of common deliverables, to select what you will need to get your users from current to future state : 

Note that some of these deliverables (above) are inside of the Electronic Health Record (EHR), and other deliverables are outside of the EHR. You will want to identify all of the deliverables you anticipate needing/using, and then identify who you will need on your project team to help develop each deliverable.

Remember that workflow change management is a team sport - A common mistake is to think that you can make a change with 'only Doctors' or 'only Nurses'. Almost all clinical workflows depend on many stakeholders, from different enterprises, with a number of different roles. Understanding the different enterprises of your organization, and the different roles you may engage with, is helpful to make sure you've thought through all of the stakeholders you will need to make your project successful : 

Once you have a sense of the estimated stakeholders and deliverables, it's helpful to think through the steps you will need to develop your workflow. For teaching purposes, I usually shrink this down into ten (10) easy steps, that you can talk through with your development team : 

This discussion almost always brings up the debate (question?) about change / project management methodologies. Two common methodologies include : 

• Waterfall Methodology - Linear, step-by-step, good for plan-first approach, takes longer but especially well-suited for Healthcare or new high-risk scenarios where one build is all you can plan for.
• Agile (Software Development) Methodology - Iterative, emphasizes rapid feedback and adaptation, sometimes useful when clinical workflows are evolving or need user-centered design - but not ideal for Healthcare scenarios. Better built for speed and iterations.

Some people will argue that Waterfall can take too long, and they prefer the speed and flexibility of Agile. Personally, I'm not sure how well Agile fits into the many high-risk clinical workflows of Healthcare (since there is usually little room for error), and so I've condensed those ten (10) helpful steps in the slide above into this 'general-purpose change recipe' below :

Once you've gone through the exercise of writing out those ten steps, and developing your own change recipe - You can then import it into a spreadsheet, and add your common roles across the top to build out your own Responsibility Assignment (RACI) Matrix : 

This Responsibilty Assigment (RACI) Matrix can then walk you through the first step of your change management - Documentation of Request and Expectations ('Intake') - And help you to develop key questions that your requestor and their supervisor (e.g. Chief, Chair, or Director) can answer before you do further analysis.

Once you have their preliminary input and feedback, you (Clinical Informaticist) can then pursue the next steps of your journey - Analysis, scoping, prioritization, resource allocation, and project approvals - To help evaluate and develop the request, and make sure your Clinical and Administrative Leadership have the information they need to prioritize and approve the project : 

After your Administrative and Clinical Leadership understands :

• the project priority, estimated scope, estimated stakeholders, estimated deliverables, and necessary resources, 
• the estimated Total Cost of Ownership (TCO) and Return on Investment (ROI)

... they can effectively prioritize and approve the project, leading you to formal project initiation, project development, and the drafting, building, testing, approval, education, implementation, and support of your future-state workflows : 

So - What tips can I offer a new Clinical Informaticist for documenting workflows and workflow design?

My first tip is to closely examine the similarities between a 'Swimlane diagram' (Visio) and a Procedure : 

If we break down a a 'Swimlane diagram' (Visio), it basically answers the questions : 

Q : Who is doing what, and in what sequence (order)?

So with a small adaptation, we can revisit the traditional swimlane diagram as :

... which leads me to share a helpful discussion of what exactly a procedure is (adapted from Charles Webster, MD aka @wareflo, another brilliant Clinical Informatics mind I have had the fortune of learning from)

Procedure (n.) (synonym : workflow, recipe, process, algorithm) - An ordered series of tasks that uses people, time, and resources to achieve a desired goal or outcome.

Now, if you accept the definition above as true, then you can create a simple template for writing a task, the most basic building block of a procedure (synonym : workflow, recipe, process, algorithm) : 

Task = [ WHO ] will/may [ WHAT ] { how } { when } { where } { why } 

where : 

• [ WHO ] = Role of the person that will perform the task
• will/may = Use "WILL" for required tasks, "MAY" for optional tasks
• [ WHAT ] = Brief description of the task
• { how } = Optional modifier, use only when needed to clarify how the task is performed
• { when } = Optional modifier, use only when needed to clarify when the task is performed (for timing/duration)
• { where } = Optional modifier, use only when needed to clarify where the task is performed
• { why } = Optional modifier, use only when needed to clarify why the task is formed

You can then include this in your own 'workflow glossary', where you define and organize your favorite high-grade (policy-grade) terminology related to workflow design : 

... but you can also use it to start writing out procedures for all sorts of things. My favorite teaching example is to take a poorly-written process (in this case, a poorly-developed process for baking and delivering cupcakes) :  

... and turn this into a well-developed process that identifies not only the necessary steps and deliverables of the workflow, but also the necessary stakeholders and their Directors/Chiefs : 

So that's a very helpful skill for the new Clinical Informaticist - Learning how to write an effective procedure. Procedures create clarity and helps you develop solutions. And this also means that your policy manual will be an excellent source of common clinical workflows, their stakeholders, and their deliverables : 

Plus, once you understand how to write a task and a procedure, you can then easily estimate the cost of the procedure by assigning either : 

• Cost = Labor + Materials
• Cost = (Salary * Time) + Materials

... to each step : 

Just for fun, you can use this trick to estimate the cost of a box of macaroni and cheese, if different clinical roles made it : 

... and so, by writing out a procedure and assigning an estimated cost to each step -  you can see the different estimated costs for an MD, an RN, a LPN, and a MA making mac and cheese :

Understanding this (and the regulatory scope-of-practice questions that naturally arise from this level of analysis) can not only help you estimate costs, but also save money, and help your clinicians to work at the top of their license - See the estimated cost of this workflow below, with an RN giving a cupcake to the patient : 

... versus the estimated cost of the workflow if an LPN gives the cupcake to the patient : 

And so, to summarize : 

And some helpful final thoughts : 

And one more final thought (wisdom once passed to me by another experienced Clinical Informaticist, early in my career) : If you're ever lost, start to untangle your workflows by writing a good procedure. 

I hope this has been a helpful journey into how to document, analyze, and develop your own clinical workflows. If you have any questions, please feel free to leave them in the feedback/comment section below! (And special thank you to both Dr. Judi Binderman and Dr. Charles Webster for their contributions to this post!)

REMEMBER : This blog is for education and discussion purposes only - Your mileage may vary. Have any other helpful tricks for quickly untangling or developing clinical workflows? Feel free to leave them in the comments section below! 

How I Became a 'Document Whisperer'

Hi fellow CMIOs, CNIOs, and other Applied Clinical #Informatics and #HealthIT friends,

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 told me, '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.

So it was while confronting the question of 'How exactly do you write a protocol?' that I started to really confront the question : "What exactly is a protocol?" This led to even more questions, like : 

Trying to find 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 HealthIT/Informatics societies, ITIL, and even Black's Law Dictionary, without much help. 

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 : 

[ FIRST DRAFT ] Note : My workflow definitions have evolved since this 2010 version.

[ FIRST DRAFT ] Note : My workflow definitions have evolved since this 2010 version.

... which 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.

(What good, functional, policy-grade definitions do to clarify concepts

and increase shared understanding - Hit PLAY to see animation)

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

Template (n.) - A tool used to standardize and expedite the creation of a document. 

... and ...

Document (n.) - A tool used to record and transmit information.

... both of which 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.

So 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 : 

[ SCREENSHOT ] From Informatics Domain and Workflow Management, 2015

 

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 the EMR : 

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

• 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.

... and so 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 HealthIT 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.

So 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. 

Remember this blog is for educational purposes only - Your mileage may vary. Have any anecdotes or stories to share about workflow analysis or development? Feel free to leave them in the comments section below!

A Tale of Applied Clinical #Informatics, in Four Parts

Hi fellow CMIOs, CNIOs, #HealthIT, and other Applied Clinical #Informatics friends,

Today I'm writing today to share a tale of Applied Clinical #Informatics, in four parts. (Or, "Why workflow analysis, naming conventions, indexing, and usability all really do matter.")

Feel free to leave comments at the end - Hope you enjoy it!

1. PART ONE - 

"I'm sorry, I don't have time to talk about workflow analysis, naming conventions, indexing, or usability - just give me everything I need in one place, and quick!!"

2. PART TWO - 

"Wait, that's not right, I can't use that. I still don't have time to talk about any of that workflow or usability stuff, but can you just put everything I need in one place so I can see it all and easily access everything I need with just one click?"

3. PART THREE - 

"Wait, that still doesn't look right, and I'm afraid I'm going to be scrolling forever. I still don't have the time to meet, but I heard there's some tool they use at another organization - Can you just find out what tool they use to do this, and then just put my stuff into whatever tool they use?"

4. PART FOUR - 

"OK, wait... I think I see the problem. Let's make some time to talk about workflow, including exactly what these tools do - Both what I use them for, and when I use them. Then let's talk about the naming conventions and indexing for each tool, so they all have a standard look and feel. Then let's talk about usability, so that I keep the most commonly-needed tools in one place, and the less common tools in a separate but nearby place. And then finally after you build it - I'll help test it to make sure it's both functional (what-we-need) and also easy-to-use."

"Eureka - That's it!" 

[ THE END ] 

Remember, this blog is for educational/discussion purposes only - Your mileage may vary. Have a good teaching example you'd like to share? Feel free to leave in the comments section below!

Signal-to-Noise, Provider Communication, and Provider Education

Hi fellow CMIOs, CNIOs, Clinical Informatics, HealthIT friends, (and other Clinical Jedi!),

Happy 2020! May this year bring us all peace, happiness, and good clinical workflows.

Speaking of good clinical workflows, thought I'd introduce today's piece by sharing some recent #HealthIT Tweets - One I was connected with on January 1st came from the great Janae Sharp (@CoherenceMed), via her @SharpIndex account: 

(For those of you who don't know the Sharp Index, 

it's a 501c 3 non-profit dedicated to improving awareness and tools to combat physician burnout.)

In any case, it's an honor being mentioned in this group with other fantastic people who are working on the same or similar issues - So I figured I'd simply respond with: 

So with this 2020 goal in mind, let's get to today's post. 

Communication with your clinical providers is vitally important. Often when discussing provider communication, I get the question, "Why is it so hard to communicate with providers?", sometimes followed by some kind of joke, usually about providers not being able to read their email in a timely basis. 

At that point, I usually have to explain exactly why provider communication is particularly challenging. To help explain the unique challenges providers face, there's a little concept that's fairly well-known in engineering circles, that is not as well-known in clinical circles - So with this blog post, I thought I'd bridge the gap. 

It's called a signal-to-noise ratio, sometimes written in engineering circles as "S/N". And it's super-helpful concept in a lot of situations - from everything including tuning your car radio, to developing communication strategy in emergencies, to clinical workflow design, to provider communication and education strategies.

You can read more about the engineering principles behind a signal-to-noise ratio on the Wikipedia page ( https://en.wikipedia.org/wiki/Signal-to-noise_ratio ), where on this day I retrieved it (1/3/2020) it defines the signal-to-noise ratio as : 

Signal-to-noise ratio is defined as the ratio of the power of a signal (meaningful information) to the power of background noise (unwanted signal).

The Wikipedia article then has a lot of complex math and descriptions of modulation and decibels, but you don't need to understand any of that math to appreciate the concepts behind a signal-to-noise ratio: 

Slide 1 - Introduction slide showing signal-to-noise ratio

In any environment, as humans, we always seek meaningful information (signal). Sometimes, finding that meaningful information (signal) is easy, provided the surrounding noise is fairly low. And sometimes, finding the signal can be a challenge, especially when the noise is high.

You can experiment with signal-to-noise ratios by visiting a restaurant with a friend before routine dinner hours - and trying to have a conversation. 

Before dinner hours - your conversation may start with a relatively normal signal, where you can both hear each other fairly well, with only a limited amount of ambient noise in the background; perhaps from waitstaff speaking or preparing for the dinner rush: 

Slide 2 - Signal-to-noise ratio before dinner crowd arrives 

in restaurant

But as more people come into the restaurant, it starts the race-to-the-top. Gradually more people arrive, the noise in the restaurant goes up, and pretty soon you can't hear each other as well: 

Slide 3 - Signal-to-noise ratio as more people arrive, 

and it gets harder to hear conversation

At this point, it starts to become a little uncomfortable - So to compensate, you will both need to speak louder (increase your signal), to continue your conversation in the setting of increasing noise:  

Slide 4 - Both people start speaking louder, to hear 

signal above noise and continue conversation

But then eventually everyone in the restaurant starts speaking louder to hear each other, and the noise goes up again - So it starts to get more uncomfortable: 

Slide 5 - Everyone in restaurant is speaking louder, 

noise goes up, conversation is harder to hear.

And perhaps, just a few times, you can't actually hear what the other person is saying: 

Slide 6 - Noise in restaurant is higher than 

your friend's voice (signal) - Conversation fails.

So to keep talking to your friend, you will need to increase your signal, and raise your voice again: 

Slide 7 - To maintain conversation, you have to raise your 

voice again (increase signal).

... at which point you will start to shout, get a sore throat, or speak only in short sentences (because you can't get enough air to increase your signal above the noise). 

If you've ever experienced this, you probably know it can make for a fairly unpleasant dining experience. Eventually, you'll leave the restaurant, and the first thing you might experience is this: 

Slide 8 - First reaction on leaving the noisy restaurant, 

when everyone seems to be 'speaking loudly'

... after which your friend may say "You don't need to shout anymore!". Soon after, the dinner crowd will empty out, and the restaurant will go back to a more normal signal-to-noise ratio again: 

Slide 9 - The restaurant goes back to a normal signal-to-noise ratio - 

but may wonder why the diners report an unpleasant experience. 

This same principle applies to provider communication and email boxes, which often have an unusual signal-to-noise ratio when compared with other clinical and administrative roles. Whether it's by email, page/text, phone call, or other communications means, here's roughly what most providers and nurses have to contend with: 

Operationally, the above table looks something like this (in no particular order, and Nurses have a very similar-looking communications map) : 

... where you can imagine, being the operator/orchestrator at the center of this communications chain - It's easy for the signal-to-noise ratio to get out-of-hand. This is why, nationally, provider communications and education strategies are particularly challenging.

This is also why, when there are critical safety issues, and patient-care is on the line - The most reliable mechanism you can use to ensure proper communication (and confirm receipt of that information) is a direct telephone call. Other methods (pages, texts, emails, etc.) are all valid forms of communication, but they are asynchronous, and may be prone to delays, or worse yet, they may get lost in the signal-to-noise ratio the provider is currently experiencing. Telephone calls are synchronous, and if it fails - You know immediately that it has failed, so you can try another provider or try another mechanism.

This is also why a good provider communication/education strategy does not just rely on just one mechanism :

[ DRAFT ] LIST - Sample modes of provider communication/education

1. Telephone Calls - Directly to the provider
2. Pages - Requesting a call-back from a provider
3. Texts - Directly to the provider
4. Emails - To the provider's email inbox
5. EMR Inbox/Inbasket messages - To the provider's EMR inbox/inbasket
6. Posters - On the walls of the hospital, office, nursing unit, or staff bathrooms
7. Department Meetings - Scheduled meetings with the department members
8. Workgroup Meetings - Scheduled meetings with a select set of clinical staff
9. Committee Meetings - Regular meetings with selected committees
10. Face-to-face communication - Meeting in a common location (e.g. cafeteria, staff lounge)
11. Intranet - Creating a high-value communication/learning ecosystem for providers (containing high-value blogs, videos, and links to training and solutions)
12. Social Media - Creating easy links to high-value communication/learning (e.g. videos, blogs, and links to training)
13. Classroom Training / Web Instruction - Creating a defined curriculum and assessment tool, for use in a classroom or virtual web environment
14. Configuration / Clinical Decision Support - Embedding EMR alerts, order set templates, and other tools inside the common EMR workflows, to help guide staff to desired outcomes
15. Policies/Procedures - Tools used to define organizational standards and how to achieve them
16. Guidelines - Tools used to educate staff about how to achieve desired outcomes
17. Onboarding / Credentialing - Tools used to educate staff when they join your organization
18. Recredentialing - Tools used to educate staff at regular intervals (e.g. recredentialing)
19. Screen Savers - Tools on the computers in clinical and non-clinical areas that display important messages during periods of non-use
20. And more...

Each of these tools has it's own costs, risks, and benefits - And so which tools you use, and who you direct them to, requires thoughtful analysis and consideration of things like : 

• What exactly is the purpose of the communication?
• Who (exactly) is the desired recipient/audience for the communication? (Careful not to confuse provider service with provider specialty!)
• What is the criticality of the communication? (What if the communication fails to reach the desired recipient/audience?)
• What details need to be included in the communication? 
• When and how often does the communication need to be delivered? (Once? Before a project go-live? Or a series of emails leading up to the go-live?)
• Which of the above tools are likely to be most effective with the desired recipient/audience?
• How often will the communication need to be updated? (Is it a one-time communicaiton based on a particular project? Or trying to communicate a TJC standard that may be updated next year? Or trying to communicate a long-standing HR standard that is unlikely to change?)
• How often will the communication need to be delivered? (Once? In a sequence leading up to an event? Only during credentialing/onboarding? Yearly? Bi-yearly with recredentialing?)

And why I'd like to leave off with a few take-home points : 

• It's helpful to understand the concept of signal-to-noise ratios, when analyzing your clinical workflows and provider communication and education strategies.
• Some ways to help minimize noise include fully building out workflows (to minimize communications related to clarifications), changing the supervision model (to help off-load some communications to other members of the care team, e.g. APPs), or changing communications modes and timing (to better target communications and minimize disruptions during patient care hours.)
• Good provider communication and education strategies do not rely on a single tool - They are a toolbox of tools.
• The tool(s) you use for communications and education should depend on a thoughtful analysis of the exact message, the desired recipient(s), the timing, the criticality, the frequency, and the anticipated need to update the message(s) in the future.
• Every role will have a different communication map - You can streamline your workflows for any role by making a map and then working to streamline your communications.

Hope this is helpful in guiding your clinical workflow analysis and your provider communications and education strategies! If you have any thoughts or feedback, feel free to leave in the comments section below!

Remember, this blog is for educational discussion only - Your mileage may vary. Always discuss with your Clinical Leadership, Administrative Leadership, Legal/Compliance Team, and Senior Leadership before making any strategic changes to your clinical workflows or communications or training strategies.

Have any thoughts or feedback? Or other communications or educational secrets to share? Feel free to leave them in the comments section below!