Jerome Carter, MD March 28, 2016
Thus far, workflow models have used two types of events: Start and End. Start events initiate a process while End events conclude a process. Events are things that happen, and BPMN 2.0 provides a way to say why events happen. BPMN 2.0 allows one to indicate what triggered the start of a process with various types of Start events, and it also provides a means to say what should happen when a process ends with End event subtypes.
At the Descriptive level, there are three types of Start events defined: None, Message, and Timer. None events have either an unspecified trigger or they are triggered by a manual task that is not controlled by the process (workflow) engine. If one is not interested in the specifics of how a process is triggered, then a None event will do fine. However, good workflow models capture details, so knowing what initiates a process is important.
Figure 1. Start Event Types.
Few processes can occur without any communication, so messages are a valuable modeling tool for Start events. In BPMN parlance, messages are not limited to emails or phone calls, as one might expect from the term “message.” Messages in BPMN 2.0 can be just about any communication directed at a specific target. An envelope inside a Start event element indicates that a message triggers the process. In Office Visit 3 (Figure 4), the message that triggers the start of the visit is the patient’s arrival at the front desk. We indicate this using a Message event called Receive Patient Greeting.
Timer events are appropriate for events that happen on a scheduled basis. A good example of a Timer start event would be the automatic generation of the monthly quality metrics report.
End events conclude processes; there are four types: None, Message, Multiple, and Terminate.
Figure 2. End Events
When a process ends, it may simply stop, or the process may alert anyone interested that it has concluded. The former is a None End event and the latter, a Message End event. The message sent by the event could be any number of things. In Office Visit 3, the message is an email to the patient containing a survey about the visit.
Terminate events are a little more interesting in that they stop all process-related activities that are underway. Perhaps the office visit equivalent of a terminate event would be the nurse checking the vital signs and finding the patient had a temp of 104 and had just arrived from a vacation in West Africa two days earlier. Suspecting Ebola, the visit would come to an abrupt halt, and the patient would be transferred to a hospital.
Subprocesses consist of tasks, and at the Descriptive modeling level, Subprocesses are a good way to prevent workflow models from becoming cluttered. A series of connected tasks in the main workflow model can be removed and placed in a separate model.
Figure 3. Register Patient Subprocess
In place of the removed tasks, a single activity element is used -- the “+” sign indicates that the activity consists of additional tasks. In Office Visit 3, the Register Patient activity now shows that it is a subprocess. The diagram of the subprocess version of Register Patient now appears in a separate model (Figure 3).
Consider this scenario: The office manager has noticed that copayments are not being handled properly because insurance info on file in the practice management system is incorrect, on average, for 15% of patients. In order to investigate, a more detailed workflow model is created to locate the problem.
The Register Patient activity was analyzed and found to have four components: Check Demographics, Check Insurance, Calculate Copay, and Assign Provider.
Check Demographics – When a patient arrives, name, address, and contact information are reviewed against that on file in the system. A staff person updates patient info as needed.
Check Insurance – A copy of the insurance card (data object connevted with dotted lines) is made and verified for currency with the patient. A staff person updates patient info as needed.
Calculate Copay – Once insurance info is verified and recorded, a computer-to-computer query is made to determine that the copay amount is accurate and up-to-date.
Assign Provider – A staff person places the patient on the roster of a provider.
Notice that the subprocess begins with a None event (a requirement for subprocesses). Check Demographics, Check Insurance, and Assign Provider are User tasks, while Calculate Copay is a Service task.
Figure 4. Office Visit 3
Another word about messages…
BPMN 2.0 provides a way to indicate the movement of messages across pool boundaries. In Office Visit 3, we know that the patient’s arrival triggers the start of visit because we have made this explicit with a message start event. The patient, however, is not actually shown in the diagram. What if we wanted to show communications with the patient? BPMN allows this via message links, represented as dashed lines with open-headed arrows. An empty pool, called a black-box pool, represents the patient and messages flow between the patient pool and the process pool. In Office Visit 3, there are two messages: patient to front-desk staff (trigger for start of visit) and a survey emailed to the patient at check out.
Thus far, we have looked at a generic office visit. Now that we have a basic BPMN vocabulary, we will look specifically at clinical workflows; that is, clinical work.