Jerome Carter, MD   March 21, 2016

The Basic Visit model from the last article was too simplistic. It lacked sufficient detail to be useful for understanding where kinks in a patient's visit might be. Whether the goal is selecting an EHR, optimizing a practice, or designing new software from scratch, detail is important. With BPMN 2.0 one can add detail to whatever level desired.

In the last installment, we focused on learning the basic BPMN 2.0 elements. Now it is time to learn how to add detail to the diagram. When creating models, it is always best to start with a simple model and add detail as one's understanding of the process increases. Models may evolve over not only weeks, but also as processes evolve -- even over a period of years. A process model is a tool for understanding and managing what happens in the real world. Therefore, they are not a one-off type of thing. A good model will pay for itself many times over.

Basic Visit 1.0

Figure 1. Basic Visit 1.0

While still using only Descriptive Level BPMN elements, we will begin by adding a pool with lanes, indicating who performs each task. A Pool in BPMN represents a process boundary. That is, everything that happens within the pool is considered to be part of the same process. Pool boundaries are important when mapping data and message movements, but those are more advanced topics than we are interested in at the moment.


Figure 2. Pool with two lanes

Lanes make workflow models easier to read and understand. They indicate roles, and in the Basic Visit workflow, there are four roles: Front Desk Staff, Nurse, Provider, and Lab Tech.

Previously, only Abstract tasks (tasks with no type) were used for all activities. Abstract tasks hide important activity details. Essentially, Abstract tasks simply let one know that an activity occurs and nothing else. Moving to specific task types allows one to capture a richer understanding of the activity. Accordingly, we will change Abstract tasks to one of the other activity types allowed at the Descriptive Level: User, Service, Call Activity (will be discussed next week), and Subprocess.



Figure 3. Activity types

User tasks, as the name implies, are performed by humans. They are different from Manual tasks (these are from a higher level), which are also performed by humans. The difference arises out of the fact that BPMN is both a modeling notation and a visual programming language. Built into BPMN is the assumption that a process may be automated, which is to say that the task may be performed with the assistance of workflow technology. Remember that BPM suites are systems that can be used to execute BPMN models. With this in mind, a User task is a type of activity that a human would perform and a BPMN process engine/workflow engine would orchestrate.

Let's assume that in the Basic Visit model when a patient arrives, validation of current insurance coverage is required. If the practice has a workflow-based software system, once the staff person enters the patient's name into the system he/she is prompted by the workflow engine to perform the Check Insurance task. This task consists of asking for the patient's insurance card, determining whether the insurance info in the computer system is either unchanged, changed, or has never been entered. After making the determination, the staff person then makes any required entries and presses the "Update Insurance" button on the computer screen--indicating the task has been completed. The workflow engine then prompts for the next task. The workflow engine directs/controls the Check Insurance User task while Manual tasks are not directed/controlled by workflow engines. An example of a manual task would be a staff person validating parking. In BPMN models that are not intended to be executable, only User tasks are used for modeling. Since our model is meant for office optimization purposes, and no executable model is planned, User tasks are sufficient for our modeling needs when we want to indicate a person is involved in performing the task.

Service tasks are performed automatically without human involvement. For instance, say that after the staff person completes the Check Insurance task and presses the "Update Insurance" button, a new task, Calculate Co-Pay, is started by the workflow engine. Calculate Co-Pay consists of contacting the insurer's computer, validating the patient's info and returning a co-pay amount to the practice's computer system. All of these steps consist of actions taken by computers without oversight by any human. There is more to Service tasks than this, but those properties are not pertinent to our current modeling level.

OfficeVisit2 DESC

Figure 4. Office Visit 2.0 with lanes, data, and task types

Subprocesses are compound activities, which means they consist of other tasks. At our current modeling level, that is all one needs to know. (We will look at Subprocesses in more detail in the next installment.)

The Descriptive level of BPMN 2.0 offers two data elements: Data Objects and Data Stores. Data Stores are the easiest to understand; they are what most would think of as traditional database. Data Stores hold persistent data that is independent of any process. An EHR is a good example of a data store. It is accessed while interacting with patients and all data continue to exist when everyone leaves for the day.

Data objects are ephemeral; they exist (from the perspective of the process) only while the process is running. Once the process completes, the data object is no longer available. In the Basic Visit example, the patient’s insurance card is treated as a data object. Once the patient leaves, the insurance card leaves as well. (Yes, there is a copy of the insurance info on file, but it could easily change before the next encounter, which is why we check insurance info at each visit).

Office Visit 2 is an update of Basic Visit with job roles, task types, and a few data elements. When a patient arrives, a staff person asks for her insurance card (data object). Once registered, the patient is sent to the nurse who looks up her record in the EHR and then adds new vital signs. The practice’s EHR is rendered as a Data Store, indicating that the data it contains persists beyond the actual processes. Next, the provider sees that patient, checks the EHR to see the nurse’s’ input, then adds exam findings and plans. If labs are required, the patient sees the lab tech. Otherwise, she returns to the front desk, where, on checking out, she receives her printed visit summary (a data object).

Office Visit 2 is a more detailed model, but more is required if one is trying to fix workflow glitches or design software. In the next installment, we will take a closer look at events and messages and use a Subprocess to add detail to the Register Patient Activity.