Many processes within health care are very similar to those in other domains. The ambulatory visit workflow discussed in the last post has examples of generic processes. Check-in, for example, occurs in any business where customers present for service. Likewise, checking a patient’s insurance status is not that different from checking whether an extended warranty is still in effect. Since so many business processes that occur in healthcare settings are not unique to the field, it is easy to overlook areas where health care differs significantly from other domains. Those differences are most obvious at the level of individual clinical professionals (allied health, doctors, nurses, etc.).
I use the term clinical professional to apply to anyone who delivers direct care to patients and who has to record that information in the patient’s record. Paper charts maintain a record of what is done on behalf of patients, acting as shared archives for those delivering care. Electronic health record systems also provide a shared archived. However, they also attempt to support clinical processes as they unfold, which is not an easy task because process support requires an intimate knowledge of process properties and parameters.
Who performs a task, the information required to make decisions, the data generated by a process, and what is recorded are examples of process properties and parameters. Usable, safe EHR systems account for process properties and parameters in their designs while systems that do not cause misery and lower productivity. The problem, of course, is how to capture and represent process information in a way that allows it to be used for EHR system design or implementation.
One major impediment to capturing workflow information suitable for software requirements has been the lack of a commonly-accepted vocabulary and concept set for clinical processes. Workflow patterns, though generic, provide a formal way of denoting what occurs during process execution, and they can be adapted to any domain. With a few tweaks and adjustments, workflow pattern concepts and vocabulary can be transferred to health care.
While workflow patterns largely address vocabulary/concept issues, decomposing real-world clinical processes remains a challenge. Decomposition requires teasing out details such as mapping information requirements to specific steps. The lack of detail is most egregious for mental tasks, which are a significant part of any clinical process. Making decisions requires access to information, and software systems that support care processes must anticipate and meet information needs.
Passive vs active systems
Consider how a clinical professional might interact with a paper system. A physical therapist interviews and assesses a patient, decides on a treatment plan, then writes it all down. Next, she interacts with the patient, executes the treatment plan, then writes down the patient’s status after her intervention. Here, the paper record is a passive archive. An electronic system designed to support physical therapy must do more than act as an archive; it must also help to make physical therapy processes more efficient and productive. In order for a system to do so, it must know the information required, the tasks that typically occur, and the types of communications and interactions in which a therapist is most likely to engage. This, in essence, is why simply replicating paper forms electronically works so poorly. A passive electronic system is no more helpful than paper, but it is usually more intrusive and counterproductive.
Looking at both mental and physical tasks
Modeling individual clinical workflows can be difficult because once professionals have developed well-defined work habits, they run on “automatic.” Asking them what they do will result in a response, but it will not necessarily be accurate. As a result, observation is required to get the complete picture. This means that models must be developed iteratively.
Modeling individual workflows means looking at common processes more closely than is traditionally advocated (see Clinical Workflow Analysis: The Value of Task-Level Detail). The following scenario illustrates the challenges of decomposing an individual clinical workflow.
Scenario: Writing a prescription
Prescription writing is a common clinical process that electronic systems support. Let’s take a look at this process in a paper-based setting. We’ll start very simply with a high-level outline for the first iteration.
|Process — Writing a Prescription|
Write medication information
Table 1. Tasks that occur when writing a prescription manually
Figure 1. High-level view of manual prescription writing (click to enlarge image)
The task Choose medication is an example of a mental task. Mental tasks consume and produce information, and modeling them at the correct level of detail requires analyzing and documenting information movements. Below, the steps that occur during the task Choose medication are listed with the information required at each step.
|Task steps — Choose medication||Required Information|
|1. Consider suitable drugs
2. Select candidate drug
3. Check for allergy
4. Check for interactions
|1. Evidence-based disease info
2. Drug efficacy, side effects, cost
3. Patient medication history
4. Drug information resource
Table 2. Steps and information requirements for the task Choose medication
The step Consider suitable drugs requires that one knows all reasonable medication regimens that might be appropriate for the problem at hand. Paper-based providers might consult a disease monograph, a book, or go from memory. In Figure 2, information inputs are shown in yellow. This is an, admittedly, oversimplified workflow as I have not included all possible decision branches that might occur. However, my goal is highlighting the information required to complete the task, not sequences or branching.
Figure 2. Choose medication (click to enlarge image)
Once a list of potential medications has been settled on, the next step is determining the best mix of efficacy, side effects, and cost. This, too, requires addition data. At this point, drug monographs and formularies are the best information sources.
Check for allergy and Check for interactions require accessing the patient’s medication history and either consulting a PDR-type resource or going from memory.
The first task, Choose medication, has four distinct information requirements. Failure to capture these requirements when modeling workflows, whether for implementation or EHR system design, leads to usability problems. Knowing about information requirements does not mean it becomes obvious as to how to meet them. Building a system to meet users’ information needs requires attention to the user interface and the system’s internal design. For any information presented to the user, EHR designers must determine both the optimal format and where/when it is needed during a process. Is the patient’s medication history visible at all times, or is it obscured by the prescription writing screen? Are interactions done automatically? Can interaction alerts be managed by the user so that minor alerts can be easily dismissed or turned off? Are important alerts tied to easy-to-read, succinct explanations? There are no simple answers to these questions.
The physical process of writing the prescription (e.g., the medication name, dose, frequency, etc.) usually proceeds once a specific medication has been selected. By hand, this usually takes only a few moments–usually 30-45 seconds or less in my experience. This process can be supported in many different ways in an electronic system. One way to speed things up is by keeping a library of the each provider’s most frequently prescribed medications. In such cases, an incremental search that occurs while the drug’s name is being typed could lead to an appropriate selection very quickly.
Workflow data patterns as modeling hints
Data patterns are part of the 126 identified workflow patterns. While the data patterns are discussed mostly in terms of software interactions (by value, by reference, task-to-task, etc.), the patterns speak to general data movements quite well. As a result, data patterns can be used as templates for information movement between people and software (e.g., pulls/pushes to environment). Analysts who are familiar with data workflow patterns can use this knowledge as hints when looking for information requirements in clinical processes.
The role of modeling tools
Prescription writing provides another example of how the features of YAWL make the modeling more efficient. One can start with a simple outline of the overall workflow, and then iteratively enhance the model with subnets, notes, and even actual data/variables, if desired.
Interviews are an integral part of workflow analysis, and when combined with observation, lead to more accurate models. A tool like YAWL aids interactions with interviewees because it allows analysts to ask questions, observe, and update models in real-time with ease.
EHR systems that seamlessly assist with clinical work must provide support for task sequences and data movements that match those of the clinical work being done. Information must be presented at the correct time and in an easy-to-understand format. Clinical workflow analysts who capture the parameters and properties of clinical processes at the level of detail required can improve EHR implementation success and aid in EHR system design. A pattern-based, workflow-centric system like YAWL is exactly the type of tool needed to document clinical work. Give YAWL a try!
- Hofstede A, van der Aalst WP, Adams M, Russel N. Modern Business Process Automation: YAWL and Its Support Environment. Heidelberg: New York, 2010.
- YAWL User Manual (PDF)
- YAWL Environment (Download)
- Workflow Patterns Initiative (Data patterns)
- Workflow Patterns Posts (Link)