My enthusiasm for workflow patterns stems, to a significant extent, from the fact that they provide an extraordinary library of process information. By providing a pattern library, van der Aalst et al. have made available a set of modeling hints that are detailed and very helpful to workflow analysts. Having them, one need not start from scratch when conducting an analysis. Over 120 patterns have been defined with formal syntax and operational semantics. Since workflow patterns address not only the sequence of tasks but also data use/movement and resource interactions (people or computers), they are also a wonderful starting point for formalizing clinical workflow analysis concepts.
A look at terminology
Because YAWL has a computer science/ business process automation (BPA) background, the terminology it uses for workflows and processes differs from that found in many healthcare resources. In healthcare learning resources, “process” and “workflow” are often used synonymously (the ONC curriculum does this); in the business process automation community, they have different meanings. Here is the definition of workflow from AHRQ:
Workflow is the sequence of physical and mental tasks performed by various people within and between work environments. It can occur at several levels (one person, between people, across organizations) and can occur sequentially or simultaneously.
For example, the workflow of ordering a medication includes communication between the provider and the patient, the provider’s thought process, the physical action by the provider of writing a paper prescription or entering an electronic prescription into an electronic health record and transmitting the order electronically or having the patient take the prescription to the pharmacy to have the prescription filled.
The paper, Workflow Data Patterns(1), published in 2004 as part of the Workflow Patterns Initiative, offers the following definitions for key terms:
A workflow or workflow model is a description of a business process in sufficient detail that it is able to be directly executed by a workflow management system.
A workflow model is composed of a number of tasks which are connected in the form of a directed graph. An executing instance of a workflow model is called a case or process instance.
A task corresponds to a single unit of work. Four distinct types of task are denoted: atomic, block, multi-instance and multi-instance block. We use the generic term components of a workflow to refer to all of the tasks that comprise a given workflow model.
An atomic task is one which has a simple, self-contained definition (i.e. one that is not described in terms of other work flow tasks) and only one instance of the task executes when it is initiated.
A block task is a complex action which has its implementation described in terms of a sub-workflow. When a block task is started, it passes control to the first task(s) in its corresponding sub-workflow. This sub-workflow executes to completion and at its conclusion, it passes control back to the block task.
While reading Modern Business Process Automation: YAWL and its Support Environment (2010) (2), which is by the same group of authors as the patterns paper, I noticed a slight change in terminology. In the book, the term “block task“ does not appear. It seems to have been supplanted by the term “composite task.” In addition, the term “sub-workflow” no longer appears, but there is mention of both “subnets” (page 223) and “sub-processes” (page 25).
Resolving the terminology/concept differences that exist between the health care and BPA communities is not a simple matter. The BPA community, from the beginning, has been focused on computerizing business processes such as those related to inventory management and order fulfillment. Whereas, on the healthcare side of things, workflow issues are increasingly being recognized as germane to not only automation of tasks, but also software design (user interface, safety, usability), implementation planning, and optimization. For clinical issues, the BPA terminology/concept set seems to be too generic, whereas on the healthcare side of things, there is very little structure at all. Unertl et al. noted these terminology/concept problems a few years back in their paper Traversing the Many Paths of Workflow Research: Developing A Conceptual Framework of Workflow Terminology Through a Systematic Literature Review(3).
Any attempt at formalization of clinical workflow analysis and modeling requires attention to concepts and terms, and indeed, this is one of my long-term goals. Workflow patterns provide a great starting point, but require adjustments for clinical use. And, again, my reason for choosing workflow patterns over other possible approaches is that they, being expressible in Colored Petri Nets, have a formal basis in mathematics, and math always eliminates ambiguity.
Because I am focused on clinical processes, with or without automation, going forward, I will give a nod to the AHRQ view of workflow because it acknowledges that mental tasks should be included in workflows (see presentation). The AHRQ definition does not define “process,” while the ONC treats “workflow” and “process” as synonyms and suggests they may be used interchangeably. Since my main goals for this series of posts are raising awareness of YAWL and making a case for formalization, I will keep things simple and save any further terminology discussions for another time. Meanwhile, here are the terms that will be used for the models I create: a “workflow” is a sequence of processes; a “process” is a sequence of tasks; a “task” is a sequence of steps. These terms allow for sufficient granularity for now.
The table below demonstrates how these terms apply to a typical office visit. Here, the workflow is for an Ambulatory Visit.
for Ambulatory Visit
for Review Demographics
Workflow modeling at the next level
Models that have sufficient detail to aid in software design and implementation must be able to account for a variety of information–actors, data inputs/outputs, time, sequences, states, and tasks. This requires new tools that are more capable than flowcharts. However, it also requires analysts with a deeper understanding of these aspects of workflow modeling. Workflow patterns provide the concepts analysts need, and YAWL provides the modeling sophistication required.
YAWL is a great tool, but before using it, some background information on the evolution of workflow modeling concepts will place it in the proper context. First, let’s look at the idea of a workflow net, another innovation of van der Aalst. Workflow nets were invented by van der Aalst in order to make Petri nets better suited to documenting workflows. An understanding of workflow nets makes both workflow modeling and YAWL easier to grasp.
Petri nets are very basic entities with few rules governing how they may be structured. Petri nets consist of places and transitions that are connected by directed arcs. Places are represented as circles, transitions as squares, and directed arcs as arrows. A place cannot connect to another place without an intervening transition, as pictured below. Similarly transition-transition links are not allowed–a place must be between them.
Places contain tokens. Below, the place waiting contains three tokens.
As with any other generic tool, such as flowcharts, having few rules means considerable freedom in how models are developed. However, freedom does not necessarily lead to productivity. In defining workflow nets, van der Aalst provided a set of ground rules and concepts that aided analysts in building workflow models that could be used in real-world process automation. Building workflow models that can be computerized is not a trivial undertaking. The models have to be executable, and they must be exact.
Van der Aalst stated two rules for workflow nets: 1) all workflow nets must have a single starting place and a single ending place, and 2) every transition in the net must be on a path from the “start” place to the “end” place. In addition, transitions and places were given specific meanings. Transitions denoted tasks; places denoted states/conditions.
The need to represent actors was added by allowing transitions to be labeled. Tasks could be labeled as automatic (executed by software), user (executed by a person), timed, or triggered by an external factor.
Concepts dealing with the flow of tasks (i.e., the sequence in which they occur) were recognized and given standard symbols, such as those for AND-splits/joins and OR-splits and joins. Taken together, these definitions and concepts transformed Petri nets from generic process tools into workflow nets that were suited to modeling business processes.
Below are examples of workflow net symbols.
From workflow nets to YAWL
Workflow nets are useful constructs, but they do not have the ability to model any arbitrary process completely. For example, they lack the ability to represent process cancellations. YAWL takes the concepts of workflow nets and adds support for workflow patterns. The result is a very capable workflow modeling language and environment.
I like YAWL—a lot. Workflow patterns and YAWL, together, offer real-world examples of the types of concepts and tools that clinical informaticists can use to improve the methods used for clinical workflow analysis and modeling.
In the next post, we will take a look at the basic features of the YAWL editor and create a simple group workflow model.
- Russell N, ter Hofstede AHM, Edmond D, van der Aalst WMP. Workflow Data Patterns. QUT Technical report, FIT-TR-2004-01, Queensland University of Technology, Brisbane, 2004.
- Hofstede A, van der Aalst WP, Adams M, Russel N. Modern Business Process Automation: YAWL and Its Support Environment. Heidelberg: New York, 2010.
- Unertl KM, Novak LL, Johnson KB, Lorenzi NM. Traversing the many paths of workflow research: developing a conceptual framework of workflow terminology through a systematic literature review. J Am Med Inform Assoc. 2010 May-Jun;17(3):265-73.