Over the last two years, I have written three series of posts that address workflow-related topics. The first, Preventing Your EHR from Working Against You, was a view of workflow issues from the standpoint of product selection and test script creation. Petri Nets and Clinical Information Systems, the second, focused on the basics of Petri nets.  The final series, Workflow Patterns, looked at the efforts undertaken by van der Aalst, Russell, and ter Hofstede to discover and define recurrent patterns that occur in task control/flow, data use and resource (people and devices)  interaction.  All of these posts point toward a specific goal –formalizing clinical workflow analysis and modeling techniques.  Currently, very little in the domain of clinical workflow analysis has been formalized.  There is no widely-used terminology for clinical processes or tasks, no specific methodology for performing analyses, and no tools designed specifically to support clinical workflow modeling and analysis.

Admittedly, putting clinical workflow analysis and modeling on a formal foundation is a fairly bold undertaking.  However, it is not as daunting as it seems because of the work done by van der Aalst, Jensen and others who have made major contributions to Petri nets, workflow patterns, and formalization of workflow and process concepts.   In addition, I have no intention of trying to do this single-handedly. Should I come up with something that I deem worthwhile, I will likely turn it into an open source project.

At present, my efforts are proceeding along two parallel paths: one that focuses on mathematical foundations and another that looks at best practices in performing and documenting clinical processes.   It is my hope that, taken together, this work will make it easier to design and implement software that seamlessly supports clinical care.

In the three series mentioned above, my aim was to share my views about performing and documenting workflow analysis as well as the tools and research I had discovered.   Now that Petri nets and workflow pattern concepts are familiar to blog readers, it is time to take the next step and introduce what I consider the best workflow modeling tool ever—YAWL.   YAWL is a graphical workflow language that is gaining mindshare in the business process automation domain.   Like other Petri net-influenced technologies, YAWL started out in computer science and is now targeted at business process automation, making its application to clinical care an interesting challenge.

From business processes to clinical processes
Business process automation, as might be expected, addresses processes that occur across a variety of businesses.  Linking inventory levels to sales, fulfilling orders, and approving vacation leave are examples.  While clinical care has similar processes and tasks (ordering supplies, admitting a patient), it also has complex tasks and processes that are performed primarily by a healthcare professional (HCP) who expects varying levels of support from a software system.  In other words, many of the processes that make clinical care possible take place in the minds of HCPs. These processes can be assisted, but not automated.

In the past, I have referred to processes such as managing a hospital admission or ordering supplies as group workflows, where work is passed among a group of people in order to complete a process (see Preventing Your EHR from Working Against You, Part I: EHR Workflow and Personal Work Habits).   A second type of process, where the mental and physical work of a single person completes a process, I labeled individual workflows.

Individual workflows occur when a physical therapist assesses a patient, a nurse does an intake, or a doctor selects the most appropriate drug for hypertension.   Often these processes are not sufficiently studied as part of a workflow analysis (see Clinical Workflow Analysis: The Value of Task-Level Detail).  Perhaps this is because clinical workflow analysts are often trained in methods taken directly from the business domain, where process automation is focused more on group processes.  In any case, the failure to address individual workflows is problematic because they are absolutely critical for the success of EHR systems and other clinical care support software.

Software designs that do not adequately support individual workflows make for unhappy users, and more training is not the answer. Training cannot make up for poorly designed software. Ultimately, the failure to capture individual process details is likely to be a source of usability, implementation, and optimization problems.   Thus, a major objective in formalizing clinical workflow analysis is defining what process information should be captured at the individual workflow level.

Starting with Petri nets
Basic Petri nets (usually referred to as place-transition nets) were used to create models for previous posts.  I like them because they are easy to learn and the diagrams are easy to understand.  Even better, Petri nets are based on graph theory, and thus can be defined mathematically. Plus, even the simplest Petri net modeling tools have some level of simulation capability, which really helps in verifying that the model captures what was expected.    Basic Petri nets cannot model every aspect of clinical processes. For example, they do not handle time, rules, data, or complex control-flow sequences well.    Fortunately, there are derivatives that do manage these properties well—YAWL and Colored Petri nets to name two.  If one is new to these two tools, understanding exactly how they differ can be confusing (at least it was to me) because there is significant overlap between them, and both are constantly evolving.

Colored Petri Nets (CPNs) are the marriage of Petri nets and ML, a functional programming language. They are Turing-complete; any program that one wishes to write can be rendered in CPNs.   Of course, being derived from Petri nets, CPNs have a graphical representation that can be used to model processes and workflows.     I have used CPNs only sparingly for two reasons.  First, they allowed for models that were far more complex than I desired to build. Second, I did not find CPN tools, the graphical environment for CPN modeling, to be intuitive, which is somewhat of an understatement. Almost nothing worked as I expected.   More recent versions, however,  seem to be much improved.

YAWL began life primarily as a graphical modeling tool that supported workflow patterns.   Over time YAWL and CPNs have converged somewhat in functionality; YAWL can produce CPN output.   YAWL, with CPN underpinnings, can support 118/126 workflow patterns.     Why, then, choose one over the other?     From personal experience, I would say the CPN Tools environment is for those with a decidedly technical bent (computer scientists, engineers, software architects) who want to perform detailed modeling of complex systems, especially if simulation and concurrency are required.  YAWL I would say is better suited for business analysts, clinical informaticists and others who want a graphical modeling tool, but who do not wish to delve too far into the deep things of Petri nets.   (These are my personal observations; their creators might have different views.)   YAWL and its environment are open source, which is another factor in its favor.

In the next post, I will review basic workflow concepts and take a closer look at the origins of YAWL.  Until then…



  1. Chuck, thanks for your comment. You are correct. YAWL is much more than a language and an editor. However, in this series of posts, I hope to draw attention to the need for more a formal approach to clinical workflow analysis, not process automation and workflow engines. Glad that you already see this as an important issue. Perhaps we will end up working on it together.

    I chose YAWL over other systems because it is so closely linked to the research on workflow patterns. I consider workflow patterns and related work to be genius-level contributions to software design. Every book on software design/software engineering should have a chapter on workflow patterns.


    1. I really appreciate your article on the use of YAWL and I would like to link to your project in the YAWL User Group (http://yaug.org). In this group we are trying to gather experience from YAWL users all over the world.

      I also believe that YAWL can be used for more than just process automation. It is also an elegant and very compact graphical notation for discussing business processes with subject matter experts.


      1. Andreas, thanks for your comment. I share your enthusiasm for YAWL, and I am pleased to know that you want to link to EHR Science. Workflow patterns and tools like YAWL are greatly under-appreciated for what they offer. I have not tried the latest version of YAWL, but look forward to doing so, as I have a few exciting projects in mind.


        1. Jerome, you should definitely try the new editor 3.0. It is really a major improvement and much easier to operate than the 2.3 version. The structure of a YAWL specification is now represented on the left hand side of the editor.

          1. I intend to try it soon. I am in he middle of revising my development stack and related tools and moving everything from Windows to Mac.

          2. Looks good! I hope to do a lot more work with YAWL (and publish) over the next few months

Leave a Reply

Your email address will not be published. Required fields are marked *