Jerome Carter, MD July 6, 2016
Well, we have reached the final installment of the introductory BPMN modeling tutorial. While this series has focused on BPMN, the underlying goal was looking at clinical work modeling challenges. With this in mind, only BPMN elements most helpful in modeling clinical work have been used.
Send and Receive tasks make their first appearance in Level 2 BPMN 2.0. Send tasks make it possible to create explicit messages within a process flow and attach conditions; something events cannot do. Send tasks may have boundary events (e.g., an error), which is not possible with message events. In clinical settings, this comes in handy. The definition of what constitutes an error within a process is up to the modeler. There are many times when a communication MUST happen, and one needs a way to react if the message is not sent. For example, one could have a Send task that represents STAT lab results, and failure to send the results (for whatever reason) would result in an error. In executable BPMN 2.0, a Send task is equated with an automated action (e.g., web service).
Figure 1. Send STAT Results
This is a good point to discuss another potentially jarring aspect of using BPMN 2.0. As mentioned earlier, BPMN began as a modeling notation that morphed (on-going) into an executable process language. The real-world side effect of this growth path is that many BPM suites only support a subset of the notation in executable form. Some BPM suites support all BPMN 2.0 tasks and others only a subset. One vendor product I used supports Send Tasks as web service entities, another does not support them at all. Determining who supports what requires reading the fine print.
Support for workflow patterns varies among vendors, as well. Most BPMN systems support all control-flow patterns, but resource and data pattern support is more unusual—which is why I continue to root for YAWL. YAWL is a better workflow language than BPMN 2.0, but has only one source (as far as I know, a full YAWL implementation is available only from the YAWL Foundation).
Receive tasks accept incoming messages, and they can be used to pause a process until the message arrives. Like Send tasks, they can have boundary events, which makes them more flexible (at least to me) than intermediate catching message events.
Level 2 BPMN 2.0 has two new gateways: Inclusive and Event-based. The Inclusive (OR) gateway appears to be implemented consistently across all BPM suites used to-date. It allows for multiple incoming (join) or outgoing (split) paths that are based on conditions (e.g., age > 50). Inclusive gateways add a much-needed level of expressiveness for modeling common clinical scenarios.
Consider a situation where a patient presents to an ER with acute abdominal pain. The workup approach can be modeled as an OR gateway where each possible intervention represents a path. The interventions are not mutually exclusive, and one or more of them will be done. The OR gateway split captures this workflow well.
Figure 2. Work-up approach
The determination of how to proceed is influenced by the result of each pathway. Thus, the final decision is based on the pooled results from all paths taken, which requires a join. In the figure, the join occurs and then the Make Admit Decision task can proceed. If an AND-join were used, it would wait for all paths to complete. The OR-join, however, waits only for those paths that were activated.
Event-based gateways are triggered by an incoming event. The first event that occurs activates the path that will ultimately continue. An event-based gateway with timer and catching message events can capture a common problem: Patients who have a follow-up visit to discuss the results of a consultation. If the consultation report has not been received before the patient’s return, the visit will be a waste of time. Here, this workflow issue is modeled to trigger a call to the consultant if a report has not been received within three weeks of the consultation visit. (Standard policy is that all outside referrals are tracked, and consultants notify the practice when patients appear for their appointments. Further, all reports are expected back within three weeks of the patient’s appointment with the consultant.)
Figure 3. Event-based gateway with timer event.
Those are the BPMN Level 2 elements that I have found to be most helpful. Translating clinical concepts into BPMN can be tricky, but it is doable. The origin of BPMN as a business modeling notation shows in many places. Messaging rules, for example, seem to be heavily influenced by service-oriented architecture practices. YAWL is more generic in outlook and is easier to mold to clinical concepts.
Moving forward, I will be focusing on two activities. The first will be refining clinical process management concepts and methods, which entails adapting workflow patterns to clinical work and formalizing the rules for modeling clinical processes. Using a BPM suite to create a clinical application based on clinical process management practices is the second. Each will have its own series. Until then…