YAWL and Clinical Workflow Modeling, Part III: A Group Workflow Example

by Jerome Carter on February 10, 2014 · 0 comments

The YAWL platform is a very sophisticated collection of tools that supports not only graphical modeling, but also enterprise-level workflow management capability.  It offers a workflow engine, web services, and other features required for business process management.     The graphical modeling environment is the focus of this series of posts.

The YAWL Editor is the tool used to model workflows.  It has numerous features, some of which are quite advanced.  For example, in order to support the sophisticated branching required of some workflow patterns, the editor allows for the use of variables/data that can guide branching.      These variables are made available to the workflow engine, which executes the workflow model.   In addition, resources, such as job roles and skill sets, may be entered and used to assign work items during workflow model execution.    The YAWL environment is not something one masters in a few hours.  Becoming a YAWL expert requires at least as much time and effort as would be required to become an Oracle DBA or Epic EHR guru.   Fortunately, however, the editor is well-designed and approachable, making it easy to pick up the basics needed to create useful models.

Analyzing and Modeling Clinical Workflows
Analysis and modeling are iterative activities where one alternately collects information, builds a model, refines it, and repeats these steps until the model is deemed complete.   Analysis begins with data collection, which can take the form of interviews with those performing the work, assessments of the forms they use, and reviews of policy and procedure manuals or other potential sources of information.   The information collected has to be organized into logical groupings.  Once the analyst feels that he/she has things sufficiently organized, then modeling begins.  (See Workflow Patterns, Part IV: A Clinical Workflow Analysis Case Study for a discussion of how one goes from data collection to an initial process/task list.)

A Scenario
You are invited to analyze and model the workflows for ACME Primary Care, Inc.  This is a large primary group with offices on the same floor as a pharmacy, lab, and radiology diagnostic center.   They are considering an EHR and want to determine which product would be the best fit.   They are specifically interested in usability issues and fear decreased productivity might result from using an EHR.   After conducting interviews with the staff, looking at policy and procedure manuals, and paper forms, you determine that an ambulatory visit is the predominant workflow that occurs and decide to model it first.  Here are the main processes identified after the initial analysis.

Workflow Processes for Ambulatory Visit
Ambulatory Visit Check-inObtain Vitals
Provider Exam
Lab VisitPharmacy Visit

Table 1.  Processes that occur during an ambulatory visit

At this point, the notes documenting what occurs during an ambulatory visit should be extensive.   However, text descriptions of movement (e.g., after, next, while) are not as clear as visual models in terms of  indicating the actual flow, so this is a good time to create an initial graphical model.

Below is the model of the first version of the workflow. In YAWL terms, the model is referred to as a net.


Figure 1.  Main Workflow Net: Initial Ambulatory Visit Workflow Model (click image for larger version)

Those who are familiar with Petri net models will notice that no circles (states/conditions) are shown between tasks in this model.   YAWL does not require states to be listed explicitly; however, they may be included if desired.  The only conditions listed explicitly are the start condition (Waiting) and the stop condition (Done).

Now let’s discuss terminology a bit.   YAWL has two basic types of tasks, atomic and composite (there are multiple instance versions of both these types, but they are not germane to this discussion).    In the table below, we can see that Check-in is not actually atomic (i.e., a single task), but consists of four tasks: Review Demographics, Check Insurance, Check Co-Pay, and Update Records.    Thus, in official YAWL jargon, Check-in is a composite task. I refer to Check-in as a process.

Tasks for the process Check-in
Review Demographics
Check Insurance
Check Co-Pay
Update Records

Table 2.   Tasks that occur during the check-in process

Recall from the last post that I proposed (and will be using) a slightly different set of terms than those used by YAWL.   Here are my preferred terms: a “workflow” is a sequence of processes; a “process” is a sequence of tasks; a “task” is a sequence of steps.    I decided on this set of terms because using the word “task” with qualifiers can be confusing as one cannot tell the level of analysis from the term alone.    Thus, when I say workflow, one knows that I am referring to a set of processes that are linked.  Similarly, when I speak of a process, I am referring to a set of tasks that are linked.

With the above in mind, the Check-in process symbol should be changed to show that it consists of a series of tasks.  In YAWL, this is denoted by the symbol of a square within a square as shown below.

Second ACME1

Figure 2. Main Workflow Net: Check-in represented by a composite task symbol

A YAWL feature that greatly aids workflow modeling is the ability to create subnets.    A subnet is simply a lower level model.  In this case, the process/composite task Check-in can be rendered in its own model, which YAWL links to the originating process/composite task.   The tasks that occur during Check-in are listed in Table 2 and shown in Figure 3 (the tasks Check Co-Pay and Update Records do not appear in the model  because they are not essential for this discussion). However, each of these tasks may be broken down into a series of steps.


Figure 3.  Check-in subnet model

Notice that both the Review Demographics and Review Insurance tasks contain a small, blue person icon, indicating that these tasks are performed manually.   In this way, YAWL offers an easy way to indicate how tasks are completed.  When using a workflow engine, these tasks could be assigned by job role or even by the level of expertise of a specific employee — a good example of how workflow technology can help to build responsive, adaptable software systems.

By providing the subnet feature, YAWL permits modelers to iteratively design complex models. Models can be expanded to accommodate new information as needed.

The value of patterns
In Figure 3, the task Check Insurance has been modeled by the series of steps and conditions that comprise it (Table 3): Review Insurance, Co-Pay Required, No Co-Pay Required, and Resolve Pay.

Steps for task Check Insurance
Review Insurance (manual)
Resolve Pay

Table 3.  Steps that occur during insurance checks

The step Review Insurance is an example of the Exclusive OR (XOR) pattern.  This pattern permits only one path to succeed.  The YAWL symbol for this step is the XOR split, as shown in Figure 3.

Consider Review Insurance in light of workflow patterns.    Being aware of the existence of the basic XOR pattern (i.e., a choice must be made, and the options are mutually-exclusive) is quite helpful when modeling because, as with other patterns, that knowledge provides hints on how work can be controlled.

Life is replete with XOR choices–IV or PO, have a procedure or not, green or blue, coffee or tea—and knowing about the XOR pattern means one is more likely to spot its presence during analysis or modeling.  An analyst with pattern knowledge is better equipped to create high fidelity models.

Model level of detail
When doing an analysis, the level of detail required is often an issue.  Obviously, by using all of the features of YAWL, one could create a very detailed visit model.   The optimal level of detail is determined by how the model will be used. If the goal is providing everyone in the practice an overview of what happens during an average visit, then a high-level model might suffice.  However, if the goal is to select an EHR or train a new employee, then much more detail is required.  For example, knowing which tasks will be manual is essential (e.g., whether checking insurance requires a phone call or a website visit).  (See Clinical Workflow Analysis: The Value of Task-Level Detail.)

Usability is another area where details are important.    If a task, such as reviewing demographic data, is required for every visit, then the analyst needs to know what demographic elements are to be checked, the number of screens required to review all elements, the number of screens required to edit all elements, and the number clicks per screen.    This brings me to the final YAWL feature that I want to mention—its ability to store notes for tasks and conditions.  Notes can be entered in a window that appears  at the bottom of the work area by simply clicking on the task/condition of interest.  Notes can be used to capture key details, such as data requirements and time-motion information.

Why use YAWL
The YAWL editor has many features that support workflow modeling and business process automation.   Modeling basics can be learned in a couple of hours, yet it still offers major firepower for would-be power users.  For clinical analysts, it is a great tool that offers a workflow-centric modeling environment along with the ability to export models as PNG files or as nets that others can review and change.   Hello YAWL, goodbye flowcharts!

The final post in this series will look at the challenges of modeling individual workflows.     Until then…



Leave a Comment

{ 0 comments… add one now }

Previous post:

Next post: