Workflow Patterns, Part I: A Pattern-based View of Clinical Workflows

by Jerome Carter on August 19, 2013 · 1 comment

Reconciling EHR workflows with the human activities they are supposed to support is one of the most challenging aspects of EHR implementation.   Much of the difficulty arises because EHR systems tend to have hard-coded workflows, and these workflows have no explicit standard representation.  That is, there are no standard charts or diagrams that are used by all EHR vendors to make the workflows of their products obvious to users.  Lacking explicit workflow representations, implementers are stuck with screen sequences, menus, and features/ functions as proxies for workflow information.

On the human side of things, workflow steps are typically documented graphically using flow charts, swim lane diagrams, or similar methods that lack the formal semantics of tools such as Petri nets.    While these graphical tools are useful for capturing human workflows, they are not enough to solve to the EHR-human workflow reconciliation problem.  Workflow reconciliation issues extend beyond EHR implementation; they also turn up in usability assessments and clinical decision support implementations.    While little can be done to get vendors to adopt workflow technologies for their products, we can move forward on the human side of things by formalizing how we document and discuss clinical processes.

This post is the first of a series that will look at how workflow patterns can help to formalize clinical workflow modeling and analysis.  Workflow patterns will be discussed from three perspectives: how they can be used to explore fundamental properties of clinical workflows; how they can support modelers in creating robust workflow analyses; and, finally, and how they can be used to standardize workflow documentation.

Of course, as with everything on EHR Science, there is a software design aspect to this series.    Information systems are supposed to help users become more efficient and productive.  This, in turn, requires software that can adjust to the demands of the work at hand.  Thus, workflow analysis and workflow models are important components of clinical software design.

Introducing Workflow Patterns
Workflow patterns were introduced by van der Aalst, Barros, ter Hofstede,  and Kiepuszewski  in a 2000 paper, titled Advanced Workflow Patterns.    According to the 2006 paper, Workflow Control-Flow Patterns: A Revised View,  by Russell and ter Hofstede, et al., the work on workflow patterns began as an attempt to  “… delineate the fundamental requirements that arise during business process modeling on a recurring basis and describe them in an imperative way.”   The authors go on to discuss an additional important driver for their work–review and comparison of workflow management systems.

One of the drivers for this research was the observation that although many workflow systems were based on similar conceptual underpinnings, they differed markedly in their expressive power and the range of concepts that they were able to capture. Indeed these differences were so significant that it raised the question of how the suitability of specific tools for specific purposes might be evaluated. Despite the plethora of workflow systems in both the commercial and research domains, there was a notable absence of core foundational concepts that individual offerings could be expected to support or that could be used as a basis for comparison. This absence differs markedly from other areas of information systems such as database design or transaction management which are based on formal conceptual foundations that have effectively become de facto standards.

Current approaches to clinical workflow analysis and documentation, much like workflow management system offerings in 2000, lack a core of foundational concepts that are accepted and used by all in the field.   While we have plenty of tools for documenting workflows, we have no standard semantics for clinical workflow elements to which everyone adheres.    Unertl and Novak, et al., explained this problem well in their 2010 paper,  Traversing the Many Paths of Workflow Research: Developing a Conceptual Framework of Workflow Terminology Through a Systematic Literature Review. 

Just as the workflow pattern initiative started by van der Aalst and colleagues has been a boon to workflow research and workflow management system design, a similar effort to define core concepts could lead to an analogous breakthrough in clinical workflow research.

What is a Pattern?
Patterns are abstractions of real-world solutions to problems that recur in a specific domain.   The idea of patterns began with Christopher Alexander and colleagues who used them as a means of conveying recurrent architectural themes.   The idea was introduced to computer science and software design by the Gang of Four in their book Design Patterns: Elements of Reusable Object-Oriented Software (see Design Patterns: The New Black).

Thus far, five categories of workflow patterns have been identified: control-flow, data, resource, exception handling, and presentation.  Since these patterns were derived with workflow management systems and business process modeling in mind, many go beyond what one would need when doing a typical clinical workflow analysis. Thus, for this series, only control-flow and data patterns will be discussed.   However, for those interested in detailed modeling of enterprise-level workflows (e.g., the range of activities and interactions that occur in a 500-bed hospital), I recommend reviewing the entire portfolio.

From Workflow Patterns to Clinical Workflows
Combined, there are more than 80 control-flow and data patterns.   Since patterns describe common workflow scenarios, one can use them as a reference guide for converting observed clinical workflows into formal representations such as Petri nets or workflow languages.    Speaking from personal experience,  I think workflow patterns are the best tool for teaching neophyte modelers.  Why?  Prior to discovering the work of van der Aalst, I tried a variety of books and papers to learn workflow analysis.  From these materials, I learned a lot about flow charts, swim-lane diagrams, activity diagrams, etc., but very little about the process of rendering my observations into a logical framework.   Further, each resource offered its own way of conducting an analysis and documenting tasks.  None offered the logical framework and expressive power of workflow patterns or Petri nets.    Of course, I performed workflow analyses prior to encountering van der Aalst’s work, but my work was much more “art” than it is now.

It is always easier to learn a new skill or develop domain competence when there exists a well-defined set of principles, rules-of-thumb, or precepts that can act as guides.   Workflow patterns provide a well-defined set of abstractions that can be rendered not only in graphical form, but also, when using colored Petri nets, in a Turing complete language; ergo, my enthusiasm for workflow patterns.

Important Workflow Terminology
Before looking at patterns, we need to review key workflow-related terms and concepts.   These terms will be used for all future workflow-related posts.

(Definitions are adapted from Workflow Data Patterns by Russell and ter Hofstede, et. al.)

Concept Definition Sub-Definition
Workflow/Workflow Model Description of a business process in sufficient detail to be executed by a workflow management system (WFMS).
Task A single unit of work      Four types of Tasks

  1. Atomic – self contained (there are no sub-tasks)
  2. Block – a task that consists of sub-workflow.
  3. Multi-instance – a task that may have multiple instances of itself running independently
  4. Multi-instance Block – amalgam of 2 & 3 above
Case/ Process Instance An executing instance of a workflow model
Task Instance Each task, when invoked by a WFMS, instantiates a task instance.

Well, now that you know the motivation for this series as well as key workflow terms and concepts, this seems like a good place to end this initial installment.

In the next post, we will look at Control-Flow patterns.  Before then, you may wish to review the paper by Unertl and Novak, mentioned above as well as the post Clinical Workflow Analysis: The Value of Task-Level Detail.  They provide additional insight into the current state of clinical workflow modeling/analysis.   (BTW, the workflow forum is available if you have questions or would like to share your workflow modeling experiences.)

Facebooktwitterpinterestlinkedinmail

Leave a Comment

{ 1 comment… read it below or add one }

Jerome Carter August 19, 2013 at 3:43 PM

Chuck, I like these definitions. As you well know, I see workflow as a key (maybe the key) unifying concept for EHR design, CDS, usability and EHR implementation. Thanks to Dr. van der Aalst and others, workflow has become a formal discipline that can be used to standardize healthcare informatics concepts. The more I consider this idea, the more I believe that it would be great to create an organization dedicated to bringing formal methods to clinical software design and implementation. (It would also provide an excuse for us geek informaticists to meet once a year).
How does the idea of an Association for Clinical Computing grab you? 🙂

Reply

Previous post:

Next post: