Solving workflow problems requires an orderly approach to discovering details. One can start by capturing a narrative description of the workflow to be analyzed. Analyzing narratives for important verbs and nouns is a common technique for developing use cases (1). It works just as well for documenting workflows. The great thing about starting with a narrative is that it can be obtained from those doing the workflows. Simply ask them to write a brief explanation of how things work. A good example would be asking them to write down what happens from the time a patient enters the practice until he/she is placed in an exam room. This type of question gets those involved thinking about processes, and it also provides the workflow analyst a good start in understanding what occurs. Keep the initial narrative simple–no more than a few paragraphs. From there, individual and group interviews, which help to keep everyone engaged, can be used to obtain and refine the narrative.
Once the narrative is sufficiently detailed, work can begin on the visual model. First, review and highlight important actions (verbs) and states/locations (nouns). (My selections are in bold text.)
Patient John Doe enters Friendly Urgent Care Center, adds his name to the sign-in sheet, then takes a seat in the waiting area. A front-desk staff person (FDSP) is responsible for reading the sign-in list and initiating registration. In order to be registered, a patient must have contact information verified (done by the FDSP) and have insurance information verified (done by a different FDSP). Once both actions have been completed, the patient is considered registered. Once registered, three tasks follow. First, patients are sent for vitals. Next, patients are assigned to one of five providers. When both vitals and provider assignment are done, an exam room is assigned.
John Doe has a painful dermatological problem, but no primary care physician. Therefore, when the provider visit is over, he is presented with three management options: PO pain medication, referral to a dermatologist, and referral to a primary care practice. He may choose all, some, or none of the available options. Once all decisions are final, he checks-out and leaves the practice.
Once the main actions/states are identified in the narrative, list them in the order they seem to occur. Don’t worry about getting them exactly right; modeling is an iterative process. Using this approach, I have the following as key tasks/states in the scenario:
- Verify contact
- Verify insurance
- Obtain vitals
- Vitals done
- Assign provider
- Provider assigned
- Assign room
- Room assigned
- See provider
- Provider visit completed
- Select management options
- Options finalized
It is surprising how many different notions there can be about how common tasks occur, even when only a few people are involved. Therefore, use group interviews when finalizing the exact order. Once an exact order has been agreed on, work on the actual workflow diagram can begin.
First, look for any of the basic patterns. They cover many workflow situations, and if the need arises they may be replaced with more advanced patterns. Obviously, we could model this workflow as a simple sequence of tasks, but that would lose the detail of what occurs at each step. One way to get to the details associated with each of the 14 items on my list is to look for those items that may require decisions/choices or where tasks occur concurrently. Looking at the seven patterns discussed thus far, we see that, with the exception of the basic sequence, all others involve branching and/or decision-making.
|Category||Pattern Name||Actions Support|
|Sequence||A then B then C|
|Parallel Split (AND split)||A initiates B & C always|
|Synchronization(AND Join)||C brings together A and B|
|Exclusive Choice (XOR split)||A initiates B or C, not both|
|Simple Merge(XOR join)||C results from A or B, not both|
|Multi-Choice(OR split)||A initiates B or C, or both|
|Structured Synchronizing Merge||C is the result of A or B, or both|
Matching Patterns to the Actions and States (For full-size, click image)
Since we are not interested in the details of entering the building or signing in, we can model the first three items on the list as a simple Sequence.
We know that once a front desk staff member (FDSP) calls a patient, both contact and insurance information MUST be verified before moving forward. The pattern that best matches this requirement is a Parallel Split.
Think about this for a moment. We have a modeling rule taken from a pattern: Any time there are multiple tasks that are required, initiated by the same task (start-registration), AND all MUST occur before some future task can begin, use a Parallel Split (AND-split). This knowledge goes the other way as well. When conducting workflow interviews, knowing about patterns alerts one to look for rules that interviewees might otherwise forget to include. This is simply another way of identifying important links and dependencies between tasks.
Knowing that we have a parallel split, and that all conditions must be met before registration can be completed, we need a construct that will unite these tasks into a single path. Synchronization (AND-join) meets this requirement.
Vitals, Room, and Provider Assignment
According to the actions/states list, after registered, the next steps are obtain-vitals, vitals-done, assign-provider, provider-assigned, assign-room, and room-assigned. These steps could be modeled as a simple sequence or another parallel split. The choice of pattern is guided by what one wishes to convey. If the goal is indicating that each step happens in this exact order, and none ever happen concurrently, then a simple sequence would work fine. However, if vitals are always done before the provider and room assignments, and rooms and providers are assigned concurrently, then we can use another Parallel Split.
Since both room and provider assignments MUST occur before the provider examines the patient, these tasks must be synchronized and, once more, the Synchronization pattern is an appropriate pattern choice.
Provider Visit and Management Options
Moving along in the scenario, the provider visit occurs next. Here, I am modeling the provider-exam as an atomic task consisting of a single transition because we are not concerned about the steps of the actual exam. However, if this analysis were being done in advance of an EHR implementation, then the provider’s actions during a patient visit would be very important.
When the patient reaches the state exam-done, management options come next. There are three in the scenario: pain-medications, dermatology-referral, and primary-care-referral. Mr. Doe may choose some, all or none of the options, which makes reconciling the workflow more complex. In order for the record-options task to fire, Mr. Doe must give a yes/no answer for EACH option.
Accomplishing this level of workflow expressiveness requires two patterns. On the left side is a Multi-choice split (OR-split). The right side is a Structured Synchronizing Merge. This diagram is more complex than the others because these patterns are both in the advanced branching and synchronization group.
The Multi-choice initiates multiple paths and all, none, or any permutation of the alternatives may be selected. In this scenario, the patient has three possible management options: pain-medications, dermatology-referral, and primary-care-referral. The long paths represent “YES” choices. The arcs that go directly from the transition select-options directly to the places finalized represent “NO” choices.
A Structured Synchronizing Merge is obviously more complex than a simple merge because it must account for all choices/selections before moving forward. As its name implies, it synchronizes all choices before allowing the next event to occur. In our case, record-options makes the patient’s selections official and moves the patient’s state to visit–done. Mr. Doe may now proceed to check-out and leave the practice (feeling better, I hope).
Multi-choice and Structured Synchronizing Merge workflow patterns model complex decisions/choices. This complexity can be a real problem when computers are involved. What seems obvious to humans—for example, instructions in a policy & procedures manual–can be difficult to mirror in software. As we have seen in this exercise, workflow patterns can act as alerts to lurking complexity and, as a result, improve the fidelity of the generated workflow model. Even better, since workflow patterns were conceived in terms of workflow management systems, patterns can provide software design hints as well. (Here is the link to the complete model.)
This wraps up the look at control-flow patterns. However, since only seven of the 43 patterns were discussed, there are more to learn and explore. I hope these posts have demonstrated the value of control-flow patterns as workflow analysis tools.
The final post in this series will look at workflow data patterns and the movement of information in clinical workflows. If you have a question or comment, please drop by the forum.
- McLaughlin B, Pollice G, and West D. Head First Object-oriented Analysis and Design. Sebastopol, CA: O’Reilly; 2007.