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…