Workflow Patterns, Part III: Using Patterns as Clinical Workflow Modeling Hints

by Jerome Carter on September 2, 2013 · 0 comments

In the last post, we looked at the five basic patterns, and two that were more advanced, along with examples of how they can represent tasks.  Now, we are going to look at the graphical representations of these seven patterns.

I find that familiarity with the graphical representations of patterns not only helps me to remember them better, but also enables me to spot the patterns more quickly in real-world situations.  First, a Petri net review.

(The Petri nets discussed here are meant to be viewed as colored nets that allow for data, time, and expressions.   The practical meaning of this is that arcs and transitions are “intelligent” and can evaluate expressions such as “If choice = Yes, Then…” and tokens have data elements, e.g., a patient token can have a name and medical record number.)

Petri Net Symbols
Petri net diagrams are comprised of four simple components: places, transitions, arcs, and tokens.   Places are equivalent to states and are represented as circles.   Moving from one state to another requires going through a transition (represented by a square). Finally, arcs (arrows) connect places to transitions and vice versa.  Places are never connected directly to another place without an intervening transition; likewise, transitions must have intervening places.  In the diagram below, there are two places (place, place2), two arcs, and one transition.

Basic Petri net defintions

Places may represent states, conditions, or perhaps locations.   For example, we could model the fact that a patient is sitting in the waiting room as a place titled waiting.

regpat1Another example of how places can be used would be representing the fact that a patient has completed the check-in process and is now registered, which is not a location but a state.  Transitions represent actions, tasks, interventions, etc.  With this in mind, we could represent the process of checking in as a transition called check-in.   Note the three tokens in the place waiting.  They indicate that three patients are waiting.

Now that you know how Petri nets look, let’s look at Petri net representations of the seven patterns we have discussed thus far.  In these diagrams, assume that places are safe (i.e., they can hold only one token at a time).

Basic Patterns
 (Pattern diagrams are adapted from those found in Workflow Control-Flow Patterns: A Revised View,  by Russell and ter Hofstede, et al.  Click on image to see full-size version.)

This is a simple series of tasks and states.


Parallel Split (AND-Split)
A parallel split describes a situation in which a task gives rise to two or more additional tasks that continue on independently of one another.


Modeling Hint: Use when there are multiple required tasks and all of them must occur concurrently.

Example: Before a surgical procedure begins, vitals and oxygenation must be checked and found to be acceptable before the procedure is initiated.

Synchronization (AND-Join)
Synchronization is sort of the inverse of  a Parallel Split (PS).  It converges all task pathways from a PS and unites them into a single thread prior to moving forward to the next task in the workflow.


Modeling Hint: Use when the results of multiple tasks/events must be reconciled before a process can continue.

Example:  Once all vitals and oxygenation are recorded as normal, the event, initiate-procedure, will occur.

Exclusive Choice (XOR-Split)
Exclusive choice refers to a workflow situation in which a task execution path splits into two or more paths representing mutually-exclusive choices.  Once a path is chosen, competing paths do not continue.    Data obtained from the user, or another component, determines which path is executed.


Modeling Hint:  Use when a choice must be made between competing decisions, paths, alternatives and ONLY one is permitted.

Example: When selecting a blood pressure medication, only one from the class of calcium channel blockers may be selected.

Simple Merge (XOR-Join)
A simple merge joins two or more mutually-exclusive task execution paths.  The paths that are being joined need not have split earlier from a common ancestor.   Significantly, any one of the incoming paths, when it reaches the join juncture, will move execution forward to the next task in the workflow.  Other incoming paths are ignored.


Notice how the paths joined by a Simple Merge (XOR-join) pattern converge on a place, whereas the Synchronization join (AND-join)   converge on a transition.   This is a subtle but important point.  XOR joins converge on places.  The place where the join occurs may hold only one token at a time; therefore,   the first token to arrive fires the following transition and continues the process.  This design assures that XOR join choices are always mutually-exclusive.

Modeling Hint:  Use when more than one incoming path exists and the first incoming path that submits a token  is the only one allowed to move the executing process forward.

Example: When nifedipine is chosen as the calcium channel blocker, the prevent-additional-same-class-drug-selection event fires and all other drugs in that class become grayed-out on the drug selection screen.

Advanced Branching and Synchronization Patterns
Multi-Choice (MC) (OR-split)
A multi-choice is a type of split in which multiple task execution paths are available concurrently.   However, unlike the Parallel Split, which is designed to launch all outgoing paths automatically, MCs launch paths based on data available to the task at the time.


Modeling Hint: Use when multiple options are available and the following constraints are present: 1) more than one of the available options may be selected, and 2) option selection is based on data provided to the process.

Example: Hypertension treatment regimens can consist of multiple drugs from different classes. When adjusting a regimen, a provider may choose drugs from one or more of the following classes: diuretic, ace-inhibitor, calcium channel-blocker, or beta-blocker.

Notice the similarity of the graphical representations of the Parallel Split, Exclusive Choice, and Multi-Choice patterns.   This is because I am not using software designed for colored Petri nets.   In colored nets, branches can use data and evaluate expressions; these notations are not available in regular Petri net models, which I am using.    In this example, conditional expressions, such as “IF DiureticWanted = Yes,” guide branch selection.

Structured Synchronizing Merge (SSM)
This pattern is basically the inverse of a Multi-Choice.   Incoming execution paths will have originated from a common ancestor.  Execution moves forward ONLY after all choices have been recorded.


The left side of this diagram is an example of a Multi-Choice with two options and their alternatives.   Let’s say that the Multi-Choice represents treatment options for a patient with mild back pain, and the options are physical therapy referral and PO pain medication.  If so, Option A represents the physical therapy referral path.  The long path from Select-A_p1, A_t1,A_p2, A_t2, A_p_Finalized— is the “YES” path.  The single arc from Select to A_p_Finalized is the “NO” path. The diagram’s right side illustrates the merging of all option pathways into a single path.

Modeling Hint:  Use when multiple options/paths are possible, and all selections must be finalized before moving forward.

Example: Our patient opts for pain medication and declines the physical therapy referral.  Now the write-discharge-instructions event may proceed.

Applying Patterns
Knowing that our control-flow workflow pattern portfolio covers all common task execution sequences, we can be confident in seeking instances of these patterns in typical clinical processes.  Here is a scenario that you can use to test your grasp of the patterns discussed.

Patient John Doe enters Friendly Urgent Care Center, adds his name to the sign-in sheet, then takes a seat in the waiting area.   A front-desk staff person (FDSP) is responsible for reading the sign-in list and initiating registration.  In order to be registered, a patient must have contact information verified (done by the FDSP) and have insurance information verified (done by a different FDSP).  Once both actions have been completed, the patient is considered registered.  Once registered, three tasks follow. First, patients are sent for vitals.  Next, patients are assigned to one of five providers. When both vitals and provider assignment are done, an exam room is assigned.

John Doe has a painful dermatological problem, but no primary care physician.  Therefore, when the provider visit is over, he is presented with three management options:  PO pain medication, referral to a dermatologist, and referral to a primary care practice.  He may choose all, some, or none of the available options. Once all decisions are final, he checks-out and leaves the practice.

Self Assessment

  1. List the individual patterns that occur in the scenario. Explain your choices.
  2. Download the PNEditor, and try to create a PN diagram of the entire scenario. (I suggest this PN modeling tool because it was the easiest to learn and use.)

This brings us to the end of this installment.   Next Monday, I will post an extended solution that will include a PN model of the scenario along with suggested steps for converting the scenario into a clinical workflow model.  If you have a question, drop by the forum.

Until  Monday…


Leave a Comment

{ 0 comments… add one now }

Previous post:

Next post: