We describe the experiences from a project in the medical domain where processes were modeled in modeling sessions in close cooperation with physicians. In this project, we experienced di culties in modeling exibilities within processes. Flexible and knowledge-intensive processes do not follow a xed sequence of steps, but rely on knowledge and experience of the medical sta . During the process execution process, the actors can decide for additional steps, change the execution order or skip a task. In standard business process modeling languages, it is not clear how to model such exible situations. We observed, however, that many exible situations can be described by recurring patterns. We argue that those patterns can be used as building blocks for communication among the stakeholders. The advantage is that those building blocks are close to the vocabulary that is used when domain experts describe a process. The patterns can support the process modeler to recognize exible situations in processes. In addition, a pattern catalog can recommend a way to model such situations in a suitable way in a standardized modeling language.
In the research project Process Intelligence in Healthcare (PIGE, see
www.pigeprojekt.de) four di erent complex medical processes were modeled in several
levels of detail (liver transplantation, living donor liver transplantation,
hepatocellular carcinoma and colon rectal carcinoma). The project ran from 2010
to 2013 at the University Hospital Jena, Germany. A modeling session involved
typically 2-3 physicians with experiences in the required process as well as 1-2
process modeling experts. Depending on the process and the required level of
detail, further participants, e.g., nurses or administrative personal, were invited to
the session or interviewed. From our experience with process modeling projects
[
In this paper, we build upon our practical experiences in modeling processes in the medical domain. We introduce patterns for the early stage of business process modeling. The aim of our patterns is to speak about variable parts of a process (model) using a vocabulary that is close to domain experts' understanding. 2
A medical treatment process is a typical scenario for a exible process. Physicians decide dynamically which treatment is needed depending on the health status of the patient. A certain order of steps is known advance, e.g., that some preliminary examinations have to be carried out before an operation. The sequence of these examinations might change due to availability of medical devices and physicians at a certain moment.
In our modeling projects, we used the language BPMN for documenting medical processes. The reason for this decision was that BPMN is the current industry standard for business process modeling. If a process was (partly) exible, the PIGE team experienced the following ways to model variability: 1. Only the typical process was modeled (covering only the control ow used in 80% of all cases) or the process was modeled at a low level of detail. This might be all right for domain experts who are already involved into the process. However, it is not easy for new employees to understand the process and possible options in full detail because some information is missing. 2. Text annotations were used to write down possible additional steps or alternatives in natural language (see Fig. 1) 3. All possible di erent pathways were modeled as shown in Fig. 2(a). Here, task A is an optional step, while B and C can be carried out in an arbitrary order (but not in parallel). In case of a lot of alternative pathways, the number of branches becomes very high and thus, make it confusing to understand the process. Therefore, this option was used very rarely in our modeling sessions.
One problem in modeling exible processes is the fact that there is no 1:1 correspondence between constructs of modeling languages such as BPMN and the vocabulary that is frequently used by domain experts. For example, in our project the physicians often use phrases such as \if executed successfully" or \if executed successfully in time". This applies to activities which can have an outcome that is interpreted as \positive" or \negative". An example of a positive outcome would be that some antibody is found in a blood-test. Note that this notion of \executed successfully" is di erent from the fact that the blood-test has been completed properly (without exception). Of course, BPMN allows to model the di erent outcomes of an activity by using an XOR split gateway followed by two labeled sequence ow arcs. However, using such constructs in a modeling workshop quickly leads to relatively large models for situations that can be expressed very shortly as e.g. \If needed, activity A is executed, afterward B and C are performed in arbitrary order". A possible notation that can replace Fig. 2(a) is shown in Fig. 2(b). This model would be easily understandable by domain experts, but is not in line with syntactically correct BPMN models that are needed by work ow engines. 3
The concept of patterns means to document known solutions to recurring
problems which are known to work well in a given context. Before the concept of
patterns was introduced in the eld of business process modeling, semantic patterns
have already been used for for creating unambiguous textual use case speci
cations. [
We brainstormed about typical situations in a process that are described by the stakeholders verbally as one fact. This means that the object of investigation was which building blocks are frequently used when people communicate about a process. An example for such a building block is when stakeholders (a) Process in BPMN (b) Same process say that activities are \performed at the same time / in parallel", etc. This is clearly di erent from the technically-oriented terminology of the work ow patterns which describe this situation as a combination of the patterns \Parallel Split" and \Synchronization". The human-oriented perspective of our patterns also means that it is important to use pattern names that can be understood and used intuitively by domain experts.
Based on our modeling experience, we identi ed a set of linguistic patterns that are frequently used to express common situations (and in particular variability) in processes. Using those patterns as \process building blocks" in a workshop with practitioners avoids large graphical models that might be di cult to read for some stakeholders. On the other hand, we do not lose preciseness, because each pattern can be transformed into formal modeling languages.
In addition to the most basic patterns (such as parallel execution, see
[
Due to space limitation, we can only give examples of three patterns here. We selected patterns that relate to a series of tests. Such situations occur quite often in medical processes, but also in other domains (e.g., approval procedures).
Our pattern catalog is organized by pattern templates. Each template contains the pattern name, the visual representation, a description of the situation where it is used and an example where this pattern occurred in a real process. For the purpose of this paper, the examples have been taken from the living liver donation process modeled in the PIGE project. Here, a healthy person who is closely related to the patient, donates a part of liver to that patient. Before the transplantation process, the donor undergoes an evaluation process to make sure that she/he is healthy enough and aware of procedures and consequences. Next, the pattern template contains a paragraph \Related Patterns" with references to sources where variants of this pattern have been discussed.
In addition to the extract published in this paper, the full pattern template also contains guidance how this pattern can be expressed in BPMN. This part can contain a discussion about modeling variants. In addition, some of the patterns contain a paragraph \Considerations for Optimization" which discusses challenges for process improvement in the given situation. It suggests questions and recommendations that can be worth discussing in a process workshop.
In the following subsections, we present the three variants of Pass All Tests. Please note that every time when we use the term \activity", it can refer either to a single (atomic) task or to a sequence of several tasks. Without limiting generality, in our diagrams we restrict ourselves to two tests. 3.1
Problem: Some object has to undergo a series of tests. The order in which the tests should be executed is known beforehand. The process can proceed by executing the next activities only if all tests have been passed successfully. As soon as the rst test fails, another path in the process ow is taken, and no further tests are necessary.
Example: A prospective liver donor needs to undergo a blood test to investigate the compatibility to the patient's blood. In case the blood is not compatible, the donor is not suitable, and no further tests are necessary. Otherwise, an investigation by a psychologist is planned. Here, too, the donor can be found to be not suitable if there are any contraindications.
Related Patterns: The iterative approval of an object (such as a document)
by multiple organizational roles is discussed as Iterative Approval pattern
in [
Problem: Some object has to undergo a series of tests. The order in which the tests should be executed has to be decided at run time. The process can proceed by executing the next activities only if all tests have been passed successfully. As soon as the rst test fails, another path in the process ow is taken, and no further tests are necessary.
Example: After the blood compatibility and psychological testing, a number of further investigations and tests are necessary. Their sequence can be decided by the medical personal, depending on the free time of specialists and the availability of CT and MRI scan devices, etc. If a mayor contraindication is found, the donor is not suitable, and no further tests are necessary. A transplant operation can only be planned if the whole evaluation procedure is completed successfully. 3.3
Alternative names: All-or-nothing [
Example: While the prospective liver donor is undergoing medical investigations, medical consultations (meetings among physicians from di erent disciplines) can take place to discuss the case and discuss possible contraindications. 4
Our proposed patterns can be directly used in a modeling session and support the modeling of exible process parts. While discussing the process, domain experts explain their activities and use phrases for expressing exibility, e.g., { The number of investigations on this list can usually be carried out in any order : This corresponds to our pattern Pass All Tests (Any Order). { The rst important step is ... the next step is ... If it fails, the whole procedure is canceled : This calls for our pattern Pass All Test (Ordered). { While the patient is still ... other investigations...: This leads to our pattern Pass All Tests (Parallel).
The application of our exible patterns as building blocks can help to transfer the process description of a domain expert to a valid BPMN model. We will illustrate this with an example from the living liver donor evaluation process. In one modeling session, the evaluation process was discussed together with the physicians. During the evaluation, several investigations have to me made to decide whether the person can donate a part of her/his liver. The physicians explained the rough process of donor evaluation: After drawing blood to test whether it is compatible with the receiving patient, the person has to pass a psychological test. Here, the motives for the donation are discussed and it has to be evaluated whether the donor can face consequences and risks. Afterward, physical investigations and some other investigations are undertaken. If at any point of these investigations a contraindication occurs, the evaluation process ends, because the person cannot donate a part of her/his liver. Using our patterns, this high level description leads to our Pass All Tests (Ordered) pattern. This information leads to the overall picture shown in Fig. 3. The + sign at the bottom center of some tasks shows that the details are elaborated in a more speci c diagram.
Next, for the Physical examination subprocess, the physicians explained that a number of investigations have to be done. For some of them, a special device is needed, that might be busy at the moment. Furthermore, a medical doctor from another department might be needed. Depending on the availability of those resources, an investigation might be postponed and another one can be done earlier to avoid waiting time. Needed investigations are written on on a paper evaluation list. If one investigation is planned with a concrete time, the date (and later also the result) is written down on the list. The nurses and physicians can see at a glance which investigations are still open, and whether a contraindication occurred. The possible donor has to undergo a number of investigations in any order, thus our pattern Pass All Tests (Any Order) can be used. All investigation results need to be positive in a way that the patient can be considered as a donor.
In the PIGE project, it turned out to be too confusing to model the execution of six tests in arbitrary order using only BPMN constructs. Therefore, a BPMN model with text annotations has been suggested (Fig. 4(a)). While the involved physicians understood the model thanks to their domain knowledge, the disadvantage is that such models still tend to be large and confusing. Furthermore, no transformation to a formal language would be possible. In contrast to Fig. 4(a), Fig. 4(b) is easy to understand and can additionally also be equipped with a formal syntax by transforming it to a formally de ned language such as BPMN.
One of the patterns discussed in Sect. 3 (Pass All Tests (Parallel)) was
discussed by Simon [
The usefulness of \building blocks" that are close to the usual vocabulary
of the domain experts has been con rmed in nearly 20 interviews with process
experts in various domains (see [
Fig. 3. Living Liver Donor Evaluation: Overall Picture (a) BPMN (Detail from a Larger Model) (b) Pattern Block that the modeling language should be adapted to the language that a domain expert uses in a modeling workshop - and not the other way round.
While the patterns we have already identi ed can be used to describe a considerable amount of situations, we do not claim that our pattern catalog is complete. Instead, we are sure that in order to cover more exible situations in business processes, further patterns have to be identi ed in future. Furthermore, the usefulness of our patterns needs to be evaluated in more modeling sessions.