Jerome Carter, MD June 28, 2016
BPMN 2.0 Analytic Level adds symbols for events, processes, and gateways. Using these symbols, more detailed process diagrams can be created. Coming from outside the business community, I find BPMN levels somewhat exasperating. To be fair, much of what I find irritating is likely due to BPMN’s origin as a modeling notation and eventual metamorphosis into an executable process language, which is a huge leap. Sometimes it feels like a programming language in its specificity, and at other times quite loose. Service tasks are a perfect example of this elasticity. According to Silver (1), a Service Task is any automated process unless the process model is executable. In executable processes, the Service Task refers specifically to a service request to an external system. Thus, Service Task changes meaning depending on the level of the model.
Descriptive Level BPMN is stated to be for high-level views of processes while executable BPMN requires the same detail as a programming language. What exactly is the value of declaring “levels”? As best I can determine, no modeling tools enforce levels. And aside from executable processes, why does it matter how much detail a model includes? When meeting with clinicians to capture a workflow, why could one not use abstract tasks for activities of no immediate interest and then use higher level task symbols for other parts of the model where there is concern about exactness?
As someone interested in creating applications, executable BPMN holds the most interest, yet much of it is NOT represented in process diagrams (e.g., process variables). It would be really helpful to have the ability to show executable-level details in process models when discussing work support issues during software design. Maybe BPMN 3.0 or another process language will emerge (or perhaps YAWL will become more commercial). For now, my advice to clinical modelers would be to learn executable-level BPMN and do your modeling using a BPM suite, then the required details can be captured, even if they are not explicit in the diagram.
Level 2 adds new events. (I strongly desire a way to tie events to workflow data patterns, but cannot come up with a reliable way that works 100% of the time.) Intermediate Events are the main new addition (there are a few new Start and End events, as well). Intermediate events occur during a process. There are five new types—Error, Escalation, Conditional, Link, and Signal. Events may be throwing or catching. Throwing events emit and catching events accept. Thus, a catching Start event might receive a message to initiate a process and throwing End event may send out an email. Here is a chart showing Level 1 and 2 symbols.
Messages are another loose BPMN concept. A message is any communication between a process and an external source – person, computer, device, another process, etc. The form that a message takes is likewise open – emails, completed job applications, and phone calls can all be modeled as messages.
Since Intermediate Events (IE) occur within a process, they may lie directly in the process flow path or be associated with a specific task. When associated with a specific task, they are referred to as boundary events.
In Figure 1, two intermediate events are shown. The first is a catching event and occurs in the flow between Schedule Visit and Set Appt Date/Time. The catching IE message event in the flow path indicates “waiting” for a message. In this case, the wait is for patient preferences for the appointment. The second IE message event is a throwing event. It is also non-interrupting, which means that if it receives a message before the task completes, it will initiate an additional flow path. In the current example, it leads to a task notifying the clinician that a special accommodation is required for this patient (i.e., the Set Appt Date/Time task cannot accommodate the patient’s request). However, the next task, Give Visit Summary does not require a definite appointment, so the summary is given and a special request is made. Had this IE throw event been interrupting, only the Request Special Accommodation path would continue.
Error events can either Boundary or End events. As boundary events, they are interrupting and cause an alternate path to be followed. As the name implies, they indicate that an error has occurred within a task.
Timers may occur within the flow path or at boundaries, and may be interrupting or non-interrupting. In flow paths, timers indicate a pause or delay in the path flow.
Figure 2 shows a treatment protocol that requires the second treatment occur at least 10 days after the first. An interrupting boundary timer appears on the Give Third Treatment task, indicating that if the third treatment has not occurred with three days, the clinician should be notified.
Conditional Events are triggered by a data condition/expression (e.g., when patientsWaiting > 10). The expression is monitored in a way such that when it becomes true, it fires. Start or Intermediate events may be conditional, and they may be catching or boundary (interrupting or non-interrupting).
Signal Events are basically broadcasts. They send out information globally. I have not found a good reason to use Link and Escalation Events for clinical work models.
As I spend more time testing clinical work models with BPMN, it is becoming obvious that I will prefer using the simplest set of symbols to create diagrams. For example, if a model can be created with the same meaning and without an Error Event, I will lose the Error Event.
Well, that’s all for now. In the next installment, I will look at Level 2 Tasks and Gateways. Below are suggested BPMN Learning Resources.
1. Silver B. BPMN Method And Style, 2nd Edition, with BPMN Implementer's Guide: a Structured Approach for Business Process Modeling and Implementation Using BPMN 2. Aptos: Cody-Cassidy Press; 2011.