Abstract

The nature of healthcare processes in a multidisciplinary hospital is inherently complex. In this paper, we identify particular problems of modeling healthcare processes with the de-facto standard process modeling language BPMN. We discuss all possibilities of BPMN adressing these problems. Where plain BPMN fails to produce nice and easily comprehensible results, we propose a new approach: Encorporating role information in process models using the color attribute of tasks complementary to the usage of lanes.

1 Introduction

Recently, business process management (BPM) has become to be considered a valuable asset in the healthcare domain [ 14 ]. BPM heavily relies on process models to identify, review, validate, represent and communicate process knowledge [ 17 ]. Among the wide variety of process modeling languages, the Business Process Model and Notation 2.0 [ 10 ] (BPMN) can be considered a de-facto standard [ 3 ]. Nonetheless, the utilization of BPMN as modeling language in specific domains may prove to be difficult. The healthcare domain serves as a good example, since the nature of healthcare processes in a multidisciplinary hospital is inherently complex [ 8 ].

In this paper, we identify particular problems of healthcare processes concerning roles and task assignment. These problems arose during process elicitation in a medical environment. We present and discuss possibilities of BPMN addressing these problems. Further, in the case that plain BPMN fails to produce nice and easily comprehensible results, we introduce a new and tailored approach: We propose to incorporate role information in process models using the color attribute of tasks as a complementary visualization to the usage of lanes. The rest of this paper is organized as follows. In Sect. 2, we introduce specific modeling requirements of the healthcare domain. Section 3 is devoted to the presentation and evaluation of existing and new approaches for handling them. Finally, Sect. 4 concludes the paper and gives directions for future work. In the context of the SOAMED graduate school1 we elicit healthcare processes at Charité SPZ2. Latter consists of five separate departments jointly working together to

1 http://www.soamed.de

2 http://spz.charite.de

provide long-time care for disabled or chronically ill children. All departments have to synchronize their actions and knowledge, resulting in inherently complex processes. This complex setting creates specific requirements concerning roles, which need to be supported by a modeling language capturing the processes: Many roles participate in one process. In the described setting many specialist roles, e.g., office staff, nurses, different kinds of doctors and therapists, work together to offer the patients a highly tailored and professional treatment.

Several specialists work together on a shared task. The most common example for

this requirement is a surgery, where, besides the head surgeon, different assistants, nurses and other personnel work together to treat the patient.

A task can be alternatively performed by different roles. An example for this case

is that a doctor may perform a task which is usually done by a nurse, i.e., taking blood of a patient.

A task can optionally involve additional roles. An example is a doctor who may re

quest a specialist on demand for consultation-hours.

In this paper, we focus on the first two requirements, since the two latter ones can be seen as special form of a shared task. In the next section, we discuss BPMN and its capabilities of modeling many roles and shared tasks, as well as the issues arising. 3

BPMN for Healthcare Processes

BPMN by the OMG3 is designed to be understandable by both business professionals and IT-specialists. The explicit design for non-technical users makes it a promising candidate for healthcare process modeling, where medical staff need to understand and discuss the process models. In his book, Silver [ 13 ] emphasizes the possibility to model different events and exceptions for routing a process. This matches with healthcare processes again, which tend to have many exceptions [ 7 ]. Furthermore, BPMN is an open and free standard, which enjoys broad tool support. As of writing, the official BPMN webpage4 lists 73 implementations.

3 http://www.omg.org 4 http://www.bpmn.org

The core modeling elements of BPMN are depicted in Fig. 1. Pools and lanes are used to structure the process diagram and separate organizational units (lanes) and organizations (pools). There are three categories of flow objects: Events, activities, and gateways. Connecting objects set these flow objects in relation to each other. In a pool, a sequence flow indicates the order in which flow objects are performed. Message flows are used between pools to model communication with other organizations. Associations relate artifacts to other elements, and artifacts are either data objects, groups or comments.

Recently, version 2.0 of BPMN was released. Several important issues regarding execution semantics and interchange formats have been addressed by the new version, yet still some open issues remain. One of these open issue is the proper integration of role modeling concepts [ 10 ]. Note that the rudimentary concept of pools and lanes, which is generally used for that purpose, has no semantic meaning in BPMN. Several other deficiencies of BPMN have been addressed by the research community [ 1 ], e.g., its lack of support for resource allocation modeling, user interface modeling or data modeling.

Figure 2 shows one process fragment we elicited at Charité SPZ describing the preparation process for a difficult surgery. This example captures the requirements of many roles and shared tasks simultaneously: Seven different roles participate in the process (visualized by seven lanes), of whom four perform a shared task, i.e., the surgery indication. In the following, we discuss the capabilities of BPMN of modeling many roles and shared tasks, as well as the issues arising.

a itrsg itonPatient e R arrives e c iff O e s r u

N

Fig. 2. Process of the preparation for a surgery at Charité SPZ. 3.1

Many Roles in BPMN

Of particular interest in this paper is the question: How does BPMN deal with role information of specific tasks? In plain BPMN, we distinguish two main approaches: The use of space as indicator for roles, or the use of annotations.

BPMN provides the notion of lanes for these roles in an organization. Thus, a diagram can be split into horizontal compartments containing the tasks assigned to a specific role. Role members can look at the diagram, search their lane and scan it for tasks they have to perform in the process. It is also fairly easy to identify handover of work, by looking at crossings of lane borders and control flows. Though these are nice features, the drawback of this visualization method is wasted space, particularly if each role has only one or proportionally few tasks in the process. Hence, lanes usually cause a disproportionate rise in diagram size while encoding only simple role information. In the worst case, a waterfall layout, the diagram size grows quadratically with the task count.

Another possibility to add role information is the use of an annotation for each task, similar to role information in EPCs [ 6 ]. The annotation may be a comment, an artifact or any kind of unique symbol. The drawback of annotations for each task is hindered readability, especially if many tasks are involved.

Both previously mentioned approaches suffer from specific drawbacks when dealing with many roles, either wasted space or hindered readability. Thus, we present a third approach for adding role information to tasks in BPMN: We use colored tasks instead of lanes in order to capture role information of a process in a more compact way. In contrast to the method proposed in [ 15 ], we do not encode levels of care, but roles in the colors of tasks. Since this approach alters the visual representation of the model, it can be considered a process view according to [ 12 ]. In the following, the patterns used to derive the different views on the process model are given in brackets.

In BPMN, there is flexibility in the size, color, line style, and text positions of the defined graphical elements (unless specified otherwise). Among others, the specification explicitly permits colored elements, and “the coloring may have specified semantics that extend the information conveyed by the element” ([ 10 ], p. 38). Hence, a first idea is to map each role in a process to a different color. After coloring each task (appearance pattern [ 12 ]) with the afore mapped color of its corresponding role, we can remove all potentially present lanes from the BPMN diagram without losing any role information (omission pattern [ 12 ]).

Figure 3 illustrates the effect of such a mapping on the size and readability of a BPMN diagram. The diagram in Fig. 2 depicts the same process as the one in Fig. 3. Yet, the former consists of seven different lanes representing different roles of the underlying surgery preparation process. Although from minor complexity, the diagram is large and unnecessarily hard to read. Figure 3 encodes the same role information in colors instead of lanes. The corresponding mapping is given as a comment in the diagram (insertion pattern [ 12 ]). Note that by using colors instead of lanes, the resulting diagram is both smaller in size and easier to read. 3.2

Shared Tasks in BPMN

BPMN does not support explicit modeling of shared tasks [ 18 ]. However, as workarounds, different methods have been proposed to capture this behavior in BPMN:

To draw the shared task on the border between two lanes. This approach is not ap

plicable for more than two roles participating in a shared task. Besides, it is not standard-conform, as a task needs to be associated to one lane only [ 10 ].

To create a new lane for the team working on the shared task. This approach breaks

the convenience of scanning a single lane for all the tasks assigned to a role. Another drawback is that the diagram size grows further with each new combination of roles sharing a task.

To have the shared task only in the responsible role’s lane. Although this solution has

no drawbacks on diagram size, it causes a quite important loss of information. Role related information is completely left out for supporting roles in a shared task. To annotate role information in associated comments. Similarly to EPCs [ 6 ] it is possible to create comments for each task containing the names of the associated roles. This approach is also used in [ 11 ], where the authors propose to use comments in YAWL [ 2 ] diagrams with one primary resource/role and optional additional resources attached to a shared task. This approach scales reasonably well for multiple roles and resources. The tradeoff is, that in order to identify all tasks a role participates in, all attached comments need to be parsed sequentially. To have a copy of the shared task in each lane and group them. This approach scales reasonably well for multiple lanes, but an additional overhead of parallelizing the control flow and adding groups around the shared tasks spanning over different lanes is introduced. It is the most promising workaround for this situation, because it is standard-compliant, no information is lost, no additional lanes are introduced and only little additional diagram space is used for the gateways splitting and joining the control flow around the shared task.

All the presented solutions above have minor or major drawbacks. Fortunately, encoding role information in colors instead of lanes enables us to model shared tasks as well: We allow tasks to be colored with more than one color, meaning more than one role participating in that task. See Fig. 4 for an example. The process depicted contains the same information as the one in Fig. 3, but unnecessary artifacts as the group, the comment and additional control flow nodes could be eliminated. The aggregation pattern [ 12 ] is quite similar, we restrict the usage to tasks with the same label executed in parallel, though.

Z PS Patient ié arrives t r ah Registration C Office

Nurse Physiotherapist The colored approach retains all of the previously mentioned advantages of the currently most promising workaround for shared tasks, i.e., commented groups: It is standardcompliant to BPMN 2.0 and there is no information lost. Furthermore, no additional diagram space for lanes, control flow or groups is necessary. Beyond its aesthetic qualities, converging behavioral, neurophysiological and neuropsychological evidence suggest that color enhances the manner in which we perceive and recognize objects [ 16 ]. At the lower level, color segments the complex visual input into coherent regions. Thus, it should be rather easy to identify all tasks of a single role in the colored diagram. To sum up, the resulting colored diagram usually becomes more compact and easier to read as the uncolored one.

However, we are aware of some disadvantages of our proposal: Color-blind people may have problems differentiating the colors capturing role information, thus losing these information. Furthermore, for printed versions of the process model, a color printer is necessary. One idea for solving both problems is the usage of a pattern-based encoding instead of colors. This enables greyscale printing of diagrams and helps color-blind people to distinguish the roles. Another rather pragmatic solution would be the addition of a label to each colored part of a task. Unfortunately, this would add more elements to the diagram resulting in more cognitive load on the readers. Scalability of our method can become a problem, when too many roles exist in a diagram, or too many roles work together in a shared task. The ability to quickly distinguish many colors or patterns decreases with increasing number of colors and patterns. However, there is evidence that quality and understandability of a process model decreases with the size of the model [ 9 ]. This lead to a rule of thumb to create BPMN models which fit on a single printed page, and resort to subprocesses to specify further details when required. In the rare case that still too many roles exist after a reasonable hierarchical restructuring of a process model, we suggest the addition of labels to the view, or the usage of the original lane approach.

Finally, the use of colors in BPMN is currently non-normative. The semantics of colors may vary user to user or tool to tool, potentially leading to misinterpretations. Moreover, BPMN Diagram Interchange does not address or define the interchange of color information. But since the colored representation can be generated from the interchangeable models and is not limited to specific tools, these issues can be tackled by adding the capability to display the colored view to tools. 4

Conclusion and Future Work

We identified several role-related process modeling requirements of the healthcare domain. We argued that BPMN is suitable for this domain, even though there exist some deficits fulfilling these requirements. We discussed existing workarounds and presented the idea to incorporate role information in colors of tasks in BPMN models. Using this approach we gained more compact, yet still understandable process models that can capture the identified role requirements. Finally, we debated both advantages and disadvantages of our proposal.

As the approach proposed in this paper is still at idea stage, we have to figure out how to cope with the disadvantages mentioned in Sect. 3.3. However, some first ideas are presented there as well. Besides the discussed workarounds in BPMN, there exist other modeling languages which can cope with the specific requirements of many roles and shared tasks, e.g., Colored Petri Nets [ 5 ]. Future research includes comparing those with our solution and answering the question which modeling language fits best the healthcare domain.

There exist mature tools which support the modeling and analysis of BPMN models, e.g., Oryx5. For future works, we would like to implement colored BPMN in one of these tools. We imagine automated support for switching between the alternate visual representations of process models of either pools and lanes, task annotations, or colorencoded roles. In this paper we restricted the possible solutions for handling complex role requirements to stay in the BPMN standard. If we lift this restriction, the most appropriate solution for these problems would be to use a similar notation as in the choreography models [ 10 ], i.e., to add (a) colored partition(s) to a task labeled with the role(s). By supporting the notion of shared tasks, we introduced a new concept to BPMN: An 1:n assignment of a task. Future work includes the formalization of this concept. Finally, there is ongoing research on the topic of layout aesthetics for business process models [ 4 ]. Future work includes how the colored BPMN performs in terms of the layout catalogue in comparison to plain BPMN. This could require the definition of a concrete BPMN layout metric beforehand.

5 http://bpt.hpi.uni-potsdam.de/oryx

References

1. Aagesen , G. , Krogstie , J.: Analysis and design of business processes using BPMN . Handbook on Business Process Management 1 pp. 213 - 235 ( 2010 )

2. van der Aalst , W.M., ter Hofstede , A.: YAWL: yet another workflow language . Information Systems 30 ( 4 ), 245 - 275 ( Jun 2005 )

3. Allweyer , T. : BPMN 2.0-Business Process Model and Notation: Einführung in den Standard für die Geschäftsprozessmodellierung . BoD, Norderstedt ( 2009 )

4. Effinger , P. , Jogsch , N. , Seiz , S. : On a Study of Layout Aesthetics for Business Process Models Using BPMN . In: Business Process Modeling Notation: Second International Workshop, Potsdam, Germany. Springer Verlag ( 2010 )

5. Jensen , K. , Kristensen , L.M. : Coloured Petri Nets - Modelling and Validation of Concurrent Systems . Springer ( 2009 )

6. Keller, G., Nüttgens , M. , Scheer , A. : Semantische Prozeßmodellierung auf der Grundlage "Ereignisgesteuerter Prozeßketten (EPK)" . Inst. für Wirtschaftsinformatik ( 1992 )

7. Lenz , R. , Reichert , M.: IT support for healthcare processes - premises, challenges, perspectives . Data and Knowledge Engineering 61 ( 1 ), 39 - 58 ( 2007 )

8. Mans , R. , Schonenberg , M. , Song , M. , Aalst , W. , Bakker , P. : Application of Process Mining in Healthcare-A Case Study in a Dutch Hospital. Biomedical Engineering Systems and Technologies pp. 425 - 438 ( 2009 )

9. Mendling , J. , Strembeck , M. : Influence Factors of Understanding Business Process Models. Lecture Notes in Business Information Processing , vol. 7 , pp. 142 - 153 . Springer Berlin Heidelberg ( 2008 )

10. OMG: Business Process Model and Notation (BPMN) - Version 2 .0 ( January 2011 )

11. Ouyang , C. , Wynn , M. , Fidge , C. , ter Hofstede , A. , Kuhr , J.: Modelling complex resource requirements in Business Process Management Systems . ACIS 2010 Proceedings ( 2010 )

12. Schumm , D. , Leymann , F. , Streule , A. : Process Viewing Patterns . In: Proceedings of the 14th IEEE International EDOC Conference , Vitória, Brazil. pp. 89 - 98 . IEEE Computer Society ( 2010 )

13. Silver , B. : BPMN Method and Style . Cody-Cassidy Press ( 2009 )

14. Stefanelli , M. : Knowledge and Process Management in Health Care Organizations . Methods of Information in Medicine 43 ( 5 ) ( 2004 )

15. Svagård , I. , Farshchian , B. : Using business process modelling to model integrated care processes: Experiences from a european project . Distributed Computing, Artificial Intelligence , Bioinformatics, Soft Computing, and Ambient Assisted Living pp. 922 - 925 ( 2009 )

16. Tanaka , J. , Weiskopf , D. , Williams , P. : The role of color in high-level vision . Trends in cognitive sciences 5 ( 5 ), 211 - 215 ( 2001 )

17. Weske , M. : Business Process Management: Concepts, Languages, Architectures . SpringerVerlag New York Inc ( 2007 )

18. White , S.A. , Miers , D. : BPMN Modeling and Reference Guide: Understanding and Using BPMN. Future Strategies Inc . ( 2008 )