Since there are more than 80 control-flow and data workflow patterns, an exhaustive review in a blog post (even a series) is unrealistic. Accordingly, my goal is to present a select group of patterns in order to: 1) demonstrate the value of focusing on core workflow concepts, and 2) illustrate how patterns can be applied when documenting clinical workflows.
Control-flow is an aspect of workflow with which every clinical workflow modeler is familiar. It is what is captured in any flow chart. According to Russell and ter Hofstede, et al., there are 43 control-flow patterns that can be categorized into six groups as listed below. (These descriptions are adaptations of those found in Workflow Control-Flow Patterns: A Revised View. I hope my edits convey the meanings intended by the authors).
|Basic Patterns||Patterns that capture elementary aspects of process control (e.g., splits, merges, and synchronization)|
|Advanced Branching and Synchronization (AB&S)||Patterns for more complex branching and merging concepts.|
|Structural Patterns||Patterns that address issues related to cycles /loops (do-while, repeat-until, recursion) or the termination of a process instance.|
|Multiple Instance Patterns||Patterns that cover situations where multiple instances of the same task are active within the same process/case.|
|State-Based Patterns||Patterns that cover data regarding the current state of the process are used to determine future subsequent execution|
|Cancellation patterns||Patterns that halt an in-progress task or case|
Specific Control-Flow Patterns
I have chosen seven patterns (all of the Basic group and two of the Advanced Branching and Synchronization group) to illustrate the value of a pattern portfolio. They appear below (the descriptions are taken verbatim from Workflow Control-Flow Patterns: A Revised View).
|Sequence||An activity in a workflow process is enabled after the completion of a preceding activity in the same process.|
|Parallel Split||The divergence of a branch into two or more parallel branches each of which execute concurrently.|
|Synchronization||The convergence of two or more branches into a single subsequent branch such that the thread of control is passed to the subsequent branch when all input branches have been enabled.|
|Exclusive Choice||The divergence of a branch into two or more branches. When the incoming branch is enabled, the thread of control is immediately passed to preciselyone of the outgoing branches based on the outcome of a logical expression associatedwith the branch.|
|Simple Merge||The convergence of two or more branches into a single subsequent branch. Each enablement of an incoming branch results in the thread of control being passed to the subsequent branch.|
|Multi-Choice||The divergence of a branch into two or more branches. When the incoming branch is enabled, the thread of control is passed to one or more of theoutgoing branches based on the outcome of distinct logical expressions associated with each of the branches.|
|Structured Synchronizing Merge||The convergence of two or more branches (which diverged earlier in the process at a uniquely identifiable point) into a single subsequent branch.|
Keep in mind that these patterns are defined in terms of workflow management systems. Therefore, they have properties that make sense for executable programs. This means there is more information provided about the patterns in the papers cited than is required to understand how they can be used as aids when conducting workflow analyses. Of course, if the goal is implementing the modeled workflows in a workflow management system, then the detailed information provided is essential.
Basic patterns represent constructs that model the most fundamental aspects of task sequence flow. Advanced patterns build upon basic patterns to provide finer-grained control over how tasks are executed. Many patterns can be modeled/implemented as implicit or explicit constructs. However, since my goal is to demonstrate to clinical workflow analysts the value of patterns, I will emphasize explicit representations.
Workflow Patterns and Common Practice Activities
For clinical workflow analysts, the value of knowing patterns lies in the portfolio of templates they provide that can be used to recognize and model real-world workflow situations. In fact, clinical workflow analysts already informally make use of the idea of patterns. For example, anyone familiar with clinical workflow modeling knows that in an ambulatory setting there exists a set of well-defined patient activities such as registration, Rx-refill, lab-test, obtain-vitals, see-provider, etc.
Knowing that these patient-activity patterns exist prevents the workflow analyst from having to discover them, anew, for every ambulatory practice. However, awareness of patient activities does not eliminate the necessity of performing a workflow analysis because the actual steps that comprise each activity and the data involved vary among practice sites. With this in mind, think of the 80+ control-flow and data workflow patterns as hints that can be used when documenting workflow steps.
For example, knowing that a practice has a registration process, one can use his/her knowledge of workflow patterns and immediately begin looking for simple sequences, parallel splits, or structured synchronized merges because he/she knows that one or more of these patterns must exist as part of the registration process. Thus, knowing workflow patterns can save time and improve one’s ability to capture workflow details correctly. Moreover, since there are tools (YAWL) designed to document workflow patterns, moving from observation to documentation (and even simulation) is less cumbersome than when using general tools such as flow charts or swim lane diagrams. Now, let’s look at a few patterns.
This is a simple series of tasks. For example, a patient visit might consist of the sequence: waiting->check-in-> medical-assistant->vital-signs->doctor.
Parallel Split (AND-Split)
A parallel split describes a situation in which a task gives rise to two or more additional tasks that run concurrently and independently of one another.
Example: When a patient arrives in an ER with trauma, the tasks check-vitals, establish-airway, and insert-IV are attempted concurrently.
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.
Example: Using the ER scenario above, an example of synchronization would be requiring that all assessment/stabilization tasks (check-vitals, establish-airway, and insert-IV) be completed before the obtain-X-Ray task is initiated.
Exclusive Choice (XOR-Split)
Exclusive choice refers to a 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 required for the choice may come from another software component or directly from a user. In the example below, the user supplies the needed information.
Example: When the select-medication task is run, a provider may choose as an administration route either oral or IV, but not both. Depending on the route selected, either the select-pill-or-capsule or select-IV-fluid task will run next.
Simple Merge (XOR-Join)
A simple merge joins two or more task execution paths. Significantly, any 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.
Example: On checking in for a primary care visit, billing options are insurance or self-pay. Once an option is selected, registration proceeds.
Advanced Branching and Synchronization Patterns
I have included these advanced patterns mainly to illustrate how they build on Basic Patterns, and in doing so, permit finer control over task execution.
Multi-Choice (MC) (OR-split)
A multi-choice is a type of split in which multiple task execution paths are initiated simultaneously. The paths run concurrently; however, unlike the Parallel Split (which is designed to launch ALL outgoing paths automatically), MC launches paths based on data available to the task at the time. It differs from the Exclusive Choice pattern in that more than one path may be activated by the user (i.e., choices are not mutually exclusive).
Example: Consider the case of a patient newly diagnosed with Type II DM. A care protocol based on a Parallel Split pattern might require that, along with various assessments, appointments with a nephrologist and an ophthalmologist must be made as soon as the diagnosis is confirmed. Conversely, in an MC pattern version, referrals would be ordered only if certain conditions were true (e.g., refer only after 24-hour urine results are available; refer only if no ophthalmologic exam within the last 12 months).
Structured Synchronizing Merge (SSM)
This pattern is basically the inverse of a Multi-Choice. Using the above example, the SSM would allow the next task in the care protocol sequence, Calculate-Health-Risk-Score, to move forward only after the results for all assessments and the two appointments are available. In this way, it synchronizes all incoming paths into a single task execution path before allowing a process to move forward.
In the next post, we will look at graphical representations of the above patterns and demonstrate how to apply them when conducting an analysis. In the meantime, stop by the forum and let me know what you think of this series thus far.