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:
- The static, hard-coded navigation paths in EHR systems (EHR workflow)
- The series of steps/tasks that a clinician performs when delivering care (clinician workflow)
- An abstract representation of a process that includes steps, tasks, information needs, error conditions, and alternate paths (process model/process workflow)
- Directed “best practice” suggestions/requirements issued by various authorities (clinical guideline).
Below are explanations for each item.
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.
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.
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?