Jerome H Carter, MD March 14, 2016
After using Colored Petri Nets, YAWL, Flowcharts, and multiple programming languages, BPMN 2.0 feels awkward in small ways. BPMN began as a tool for business analysts, and morphed, in version 2.0, into an executable language—and it feels that way. It has programming constructs (e.g., sub-process [inside the scope of the running process], call activity [outside the scope of the running process], and global task [something akin to a library routine in a programming language]) that are similar to the scoping of subroutines or procedures in BASIC or Pascal.
Workflow patterns (there are more than 100) capture stereotypical ways in which workflows progress from start to finish. There are patterns for control and flow of activities, data movement, and resource use. Workflow patterns grew out of the work of van der Aalst, ter Hofstede, Russell, and colleagues. Having been proposed by computer scientists, WF patterns are algorithm-oriented and are easy to understand from a math or programming perspective. BPMN 2.0 has incorporated pattern behavior, which has made process logic easier to master.
Few informaticists, clinicians, human factors professionals (and possibly programmers) are familiar with BPMN 2.0. Making BPMN known among these communities is one of the main goals of this tutorial series. Consequently, I will focus initially on essential modeling concepts and simple diagrams.
Creating software systems that support clinical work requires modeling and programming tools that can capture the intimate details of clinical work accurately. In its current form, BPMN 2.0 has most of the concepts required to model clinical workflow details. However, there are no standards for modeling clinical workflows. No standard concept terms, task definitions, or modeling conventions are shared among all professional groups that focus on clinical workflow analysis. Thus, engendering discussion about formalizing clinical workflow analysis and modeling methods is the second major series goal.
BPMN 2.0 has 90+ symbols(elements). The BPMN formal specification recognizes different levels of BPMN usage (they appear below).
Descriptive is concerned with visible elements and attributes used in high-level modeling. It should be comfortable for analysts who have used BPA flowcharting tools.
Analytic contains all of Descriptive and in total about half of the constructs in the full Process Modeling Conformance Class. It is based on experience gathered in BPMN training and an analysis of user-patterns in the Department of Defense Architecture Framework and planned standardization for that framework.
Both Descriptive and Analytic focus on visible elements and a minimal subset of supporting attributes/elements.
Common Executable focuses on what is needed for executable process models.
The descriptive level is all that is needed to create basic workflow models. The analytic level provides a richer set of elements that add more detail and nuance to models. When it is time to discuss richer clinical work models, the analytic level will be used for examples. The common executable level will be discussed in a different series about BPM suites and workflow engines.
BPMN 2.0 has three basic elements: activities, events, and gateways (BPMN Quick Guide). Each of these types has multiple variations as one proceeds from descriptive to the common executable level.
Activities come in two basic flavors: atomic tasks and sub-processes. Activities are modeled using rounded rectangles.
Atomic tasks are defined as a single unit of work. Exactly what constitutes a “single unit of work” is determined by the modeler and the process being analyzed. If this seems vague, it is; however, you will see that is not an issue on high-level diagrams. A sub-process consists a set of tasks that accomplish work within the main process.
BPMN allows for multiple types of tasks that can be used to add detail. For instance, the specification includes manual tasks, user tasks, send tasks, and others. At present, we are only interested in descriptive level tasks -- abstract tasks, user tasks, and service tasks. The type of task is indicated in the upper left corner of the task element. An abstract task is one that has no type. A user task is one performed by a person, and service tasks are those performed without any human intervention. We will start modeling with only abstract tasks.
Events are represented using circles. At the descriptive level, we are only concerned with two event types: start and end. The BPMN specification does not require that a process begin with a start event. However, it is a widely-held practice, and coming from Petri nets, it feels right.
Gateways are the final major element. They are diamonds. Gateways control the path taken through a model. At the descriptive level, gateways represent three flow concepts. Exclusive-OR, Inclusive-OR, and AND (parallel).
Exclusive-OR (X) splits allow only one of many possible pathways to proceed. AND (+) gateways split the path into parallel tracks, all of which move forward concurrently.
The paths through a model are indicated by sequence lines, which are solid arrows with black tips.
I have only discussed a sampling of the descriptive element set. Even so, we have covered enough to do a simple workflow model. Let’s look at a common workflow in offices, a patient visit. This will be a high-level diagram that shows the most important tasks during a visit.
Scenario – Basic Visit
A patient arrives for a visit. She checks in with the front desk staff who review demographics info, check insurance status, and determine whether she has a co-pay. If everything is okay, the patient is assigned to a provider’s schedule, completing registration. Next, she is placed in a room where a nurse checks her vitals. Then the provider encounter occurs. After the provider encounter, if labs are required, she is sent to the lab; otherwise, she checks out with the front desk staff. Here is a high-level view of this visit.
The start event begins the process. Then the three abstract activities follow. Once the patient leaves the provider, the next step is determined by whether or not she requires labs. An exclusive-OR (XOR) gateway is used to control flow to the next task. Each branch of the XOR is labeled. If the provider has ordered labs, then a visit to the lab occurs; otherwise, the patient checks out.
BPMN offers the flexibility of making diagrams as simple or as complex as one desires. The above diagram is fine for basic discussion concerning office policy. However, if the goal were to look deeper into any of these tasks, more detail would be required. For example, if there were problems with incorrect/old demographics data on file, then perhaps a closer look at registration is warranted. If so, the Register Patient task could be broken down into as many smaller tasks as needed to represent all actions related to demographics data collection.
When more detail is required within a model, it could be added in one of two ways. First, more tasks could be added directly to the main process model (as described above for Register Patient). A second option would be to create a separate model file for the Register Patient task and place all of the smaller tasks there. Next, the Register Patient task in the original Basic Visit process model would be changed from a simple abstract task to a sub-process (with plus sign) with a link connecting it to the newly-created model file. This allows for hierarchy within BPMN models and makes it easy to add detail to models without making them messy. Another way of adding detail would be to add participants to the diagram using swimlanes to show who performs each task.
I will stop here for now. I have put together a Clinical and Business Process Management Resources page. It contains links to books, websites, and articles that you will find helpful in learning and applying BPMN. Next time we will explore ways of adding detail to the Basic Visit model.