The Ways of “Workflow”

by Jerome Carter on October 10, 2016 · 3 comments

Workflow issues are in fashion.   Unfortunately, discussions of workflow-related problems often go off track because the term “workflow” sometimes takes on different meanings based on user and context.   It reminds me of my early consulting days when I was engaged to help a hospital’s executive leadership determine whether their facility was ready for an EHR. (This was a few years before MU was conceived).   Knowing that buy-in from leadership was a key indicator of the likelihood of success, I (after much diplomatic maneuvering and pleading) managed to get most of the C-suite group to meet with IT and medical staff representatives. With maybe 15 people sitting around the conference table discussing the pros and cons of buying an EHR system, I noticed that terms such as “database” and “network” were being used by everyone, but with slightly different meanings. For example, when IT folks said “database” they were referring to a software system (RDBMS). On the other hand, the executives using the term generally meant a collection of information without regard to any type of software.   Over the years, I have seen this type of semantic confusion many times. And, every time, resolving the confusion led to real progress.

Lately, “workflow” seems to be suffering from the same semantic drift. Like “database” before it, confusion and unnecessary fruitless rounds of discussion can be the result. Here are the four usages of workflow I have encountered that require separation:

  1. The static, hard-coded navigation paths in EHR systems (EHR workflow)
  2. The series of steps/tasks that a clinician performs when delivering care (clinician workflow)
  3. An abstract representation of a process that includes steps, tasks, information needs, error conditions, and alternate paths (process model/process workflow)
  4. Directed “best practice” suggestions/requirements issued by various authorities (clinical guideline).

Below are explanations for each item.

EHR workflow
Clinicians who complain about EHR usability and too many clicks are actually complaining about navigating through the features and functions of an EHR system in order to complete a task.   Thus, an EHR workflow is really the series of static, hard-coded navigation paths that one must follow to get anything done (i.e., the navigation tree). All possible navigation paths can be visualized as an upside-down tree where one starts at the trunk (log-on), gains access to the first large branches, and then gradually proceeds to a leaf (invocation of the feature/function desired).     Training is an exercise in learning a navigation tree. The more complex and unintuitive the tree, the longer and more painful the training experience.

I suggest that instead of talking about EHR workflows that we instead refer to EHR navigation trees. Doing so would make this key usability issue more apparent while helping irritated users better understand how to focus their feedback when making suggestions or lodging complaints.

The navigation pathways of an EHR include all possible ways of moving from one feature to another, and thus they include more items than those selectable from the application’s main menu. Context-sensitive pop-up menus accessed by right-clicking are a good example.

Clinical workflow
Interacting with patients, reviewing labs, and writing prescriptions are all processes that are completed via a series of steps.   Processes have specific start points and end points, and for any process, the “workflow” consists of the steps, resources, and information required to move from the start point to the end point.  Clinical workflows, therefore, happen when typical care processes are carried out. Clinical workflows can be (should be) studied when trying to improve care quality and efficiency. Of course, it also makes sense to study clinical workflows when there are safety concerns or when software is required to support clinical processes. When describing clinical work and how it occurs, “clinical workflow” is an appropriate term.

One caveat: When clinicians interact with an EHR to deliver care, those interactions with the EHR become part of the clinician’s workflow. However, it is important to keep separate the steps of the clinical process at hand (say, documenting a patient’s history) and accesses of the EHR’s navigation tree.   Maintaining the separation allows software designers and anyone studying the clinical process to avoid confounding one with the other. An example of how conflation of the two is detrimental can be seen in discussions of patient safety.   Safety mishaps can occur because of clinician missteps (e.g., failure to ask about medication allergies), poor software design (e.g., correct path to enter allergy data is unclear) or both (e.g., clinician error – orders an unnecessary test; navigation path complexity – path to chart info that would show test was unnecessary is confusing, so clinician does not see the information).

The interplay between clinical workflows and EHR navigation is one thing that makes EHR usability testing challenging while also making it difficult to compare usability results from different EHR systems.

Process model/ process workflow
Process models are abstract representations of the steps and that tasks occur from the start of a process until its completion. Process models may be high-level, covering only the main tasks and steps or low-level, capturing all the steps, resources, people/roles, equipment, data use/creation, alternate paths, and error conditions that occur during the process. As such, low-level process models represent the actual work that occurs during the process and how that work gets done.

High-level process models may be useful for overviews and general discussions, but when enactment/implementation of a process model is the future goal, low-level (i.e., workflow) detail is required. Simply saying “process workflow model” (or process workflow diagram) instead of simply “workflow” is enough to remove any confusion about what is intended when discussing process models.

Process workflow models can be implemented manually and/or supplemented with automated support using workflow technology. For example, a clinic that wishes to improve its new patient intake process could create a high-level process model, and then refine it into a proper workflow model, which could then be implemented manually. If later, it is decided that electronic support would make things even better, then a workflow technology application or a software system specifically designed to support the intake process could be added.

Clinical guideline
A clinical guideline is a collection of “best practice” and/or evidence-based suggestions that address a specific clinical condition or concern. Typically, they are issued by various authorities (professional societies or governmental agencies).   Often, they are portrayed using diagrams (e.g., decision trees, flow charts), so they can resemble process models. While any clinical guideline could be used as the basis of a clinical process model, guidelines are written as advisory documents. Turning a guideline into an actual process workflow model is far easier said than done, as the efforts spent on computer-interpretable guideline languages can attest.

So to summarize:

  • EHR systems have navigation trees, not workflows.
  • Those doing clinical work are performing processes that have a specific start point (A) and an end point (Z), and one gets from A to Z via a clinical workflow.
  • Process workflow models are detailed diagrams showing the steps, resources, data needs, alternate paths, and error conditions that occur during a process, and they can be implemented. High-level process models are good for discussion, but lack the workflow details required for implementation.
  • Clinical guidelines can be represented visually using flowcharts and decision trees, but implementation (manual or automated) requires a proper process workflow model.

Keeping these four concepts separate can save a lot of time and frustration.

Well, that’s my two cents. What do you think?

Facebooktwitterpinterestlinkedinmail

Leave a Comment

{ 3 comments… read them below or add one }

John Dorsky October 11, 2016 at 1:50 PM

Jerome,
Great idea and job to break this down, and specifically to separate out “clinical workflow” and “EHR navigation trees”. It is the navigation trees that are obstructive to clinical workflows. Workflow models should focus on EHR navigation trees that would facilitate, not obstruct,. clinical workflows. Easier said than done, and the C-Suite at a hospital has little impetus because the billing side of the EHR has already facilitated up-charging. So this burden would fall to the software company. If you already have a large percentage of the market, and the hospital/doctor employer/EHR purchaser execs are satisfied, why would you invest in changing your software.

Reply

Jerome Carter October 11, 2016 at 2:28 PM

Innovation in clinical software will happen first in small practices then move upward. Hospital-focused systems will be the last to evolve.
Practices do not have to have an EHR in order to experiment with automation of standard clinical processes.

Patient engagement strategies: Managing patient communications with workflow technology (tutorial series). https://www.clinicalworkflowcenter.com/articles/bpm-workflow-technology/52-managing-patient-communications-with-workflow-technology-part-i

Reply

Chuck Webster, MD, MSIE, MSIS @wareflo October 10, 2016 at 10:07 AM

I like my definitions of workflow and workflow technology:

“I’ve looked at literally hundreds of definitions of workflow, all the way from a “series of tasks” to definitions that’d sprawl across several presentation slides. The one I’ve settled on is this:

“Workflow is a series of tasks, consuming resources, achieving goals.”

Short enough to tweet, which is why I like it, but long enough to address two important concepts: resources (costs) and goals (benefits).

So what is workflow technology? Workflow technology uses models of work to automate processes and support human workflows. These models can be understood, edited, improved, and even created, by humans who are not, themselves, programmers. These models can be executed, monitored, and even systematically improved by computer programs, variously called workflow management systems, business process management suites, and, for ad hoc workflows, case management systems.

Workflow tech, like health IT itself, is a vast and varied continent. As an industry, worldwide, it’s probably less than a tenth size of health IT, but it’s also growing at two or three times the rate. And, as both industries grow, they increasingly overlap. Health IT increasingly represents workflows and executes them with workflow engines. Workflow tech vendors increasingly aim at healthcare to sell a wide variety of workflow solutions, from embeddable workflow engines to sprawling business process management suites. Workflow vendors strenuously compete and debate on finer points of philosophy about how best automate and support work. Many of these finer points are directly relevant to workflow problems plaguing healthcare and health IT.

Why is workflow tech important to health IT? Because it can do what is missing, but sorely needed, in traditional health IT, including electronic health records (EHRs). Most EHRs and health IT systems essentially hard-code workflow. By “hard code” I mean that any series of tasks is implicitly represented by Java and C# and MUMPS if-then and case statements. Changes to workflow require changes to underlying code. This requires programmers who understand Java and C# and MUMPS. Changes cause errors. I’m reminded of the old joke, how many programmers does it take to change a light bulb? Just one, but in the morning the stove and the toilet are broken. Traditional health IT relies on frozen representations of workflow that are opaque, fragile, and difficult to manage across information system and organizational boundaries.

Well, OK, I’ll steal my own thunder just a little bit. Process-aware tech, in comparison to hardcoded workflows, is an architectural paradigm shift for health IT. It has far reaching implications for interoperability, usability, safety, and population health.

BPM systems are ideal candidates to tie together disparate systems and technologies. Users experience more usable workflows because workflows are represented so humans can understand and change then. Process-aware information systems are safer for many reasons, but particularly because they can represent and compensate for the interruptions that cause so many medical errors. Finally, BPM platforms are the right platforms to tie together accountable care organization IT systems and to drive specific, appropriate, timely action to provider and patient point-of-care.”

http://chuckwebster.com/2014/06/healthcare-bpm/bpm-based-population-health-management-care-coordination-workflow-usability-safety-interoperability-perspectives

Then of course is my 2003 description of workflow tech as the “workflow of workflow”!

http://chuckwebster.com/papers/workflow_of_workflow_white_paper.pdf

Cheers Chuck

Reply

Previous post:

Next post: