Clinical Processes - The Killer Application for Constraint-Based Process Interactions?

Clinical Processes - The Killer Application for Constraint-Based Process Interactions? Andres Jimenez-Ramirez1, Irene Barba1, Manfred Reichert2, Barbara Weber3,4, and Carmelo Del Valle1 1Departamento de Lenguajes y Sistemas Inform´aticos, University of Seville, Seville, Spain {ajramriez,irenebr,carmelo}@us.es 2Institute of Databases and Information Systems, Ulm University, Ulm, Germany [email protected] 3Department of Computer Science, University of Innsbruck, Innsbruck, Austria [email protected] 4Technical University of Denmark, Kongens Lyngby, Denmark [email protected] Abstract. For more than a decade, the interest in aligning information systems in a process-oriented way has been increasing. To enable operational support for business processes, the latter are usually specified in an imperative way. The resulting process models, however, tend to be too rigid to meet the flexibility demands of the actors involved. Declarative process modeling languages, in turn, provide a promising alternative in scenarios in which a high level of flexibility is demanded. In the scientific literature, declarative languages have been used for modeling rather simple processes or synthetic examples. However, to the best of our knowledge, they have not been used to model complex, real-world scenarios that comprise constraints going beyond control-flow. In this paper, we propose the use of a declarative language for modeling a sophisticated healthcare process scenario from the real world. The scenario is subject to complex temporal constraints and entails the need for coordinating the constraint-based interactions among the processes related to a patient treatment process. As demonstrated in this work, the selected real process scenario can be suitably modeled through a declarative approach. Keywords: Process flexibility ·Declarative process model Healthcare process ·Temporal constraints 1 Introduction For several years, there has been an increasing interest in aligning information systems in a process-oriented way [6,30]. Thereby, a business process (BP) consists of a set of activities which jointly realize a business goal and whose execution needs to be coordinated in an organizational as well as technical environment [30]. In this context, process-aware information systems (PAISs) offer promising perspectives by enabling enterprises to define their business processes in terms of explicit process models as well as to execute the corresponding process instances in a controlled and efficient manner [24,30]. Declarative approaches are becoming increasingly popular for modeling business processes as they are able to cope with some of the limitations imperative notations are facing [4,9,10,17,20,28,31]. Although declarative modeling languages have been extensively discussed in literature [5,19], even in the context of healthcare [21,25,29], to the best of our knowledge, they have not been used to model complex, real-world scenarios that comprise constraints going beyond control-flow. In this paper, we propose the use of a declarative language for modeling a sophisticated healthcare process scenario from the real world. Particularly, the latter is subject to complex temporal constraints and entails the need for coordinating the constraint-based interactions among all the processes contributing to the overall patient treatment process. We strongly believe that, if we are able to demonstrate the applicability of declarative modeling languages to clinical process, which can considered as a kind of killer application for PAISs, the respective approach can be applied to many other sophisticated process scenarios as well. Although the temporal perspective is present in many real-world process scenarios, it has not received sufficient attention yet. In previous work [14], we systematically derived 10 process time patterns (i.e., solutions for representing commonly occurring temporal constraints in PAISs) by analyzing a large collection of non-trivial process models from various domains. In particular, the time patterns (TPs for short) were defined independently of a specific language or paradigm for BP modeling [13]. Despite the needs for enabling process flexibility and dealing with temporal constraints, most existing approaches are unable to manage both. To fill this gap, we proposed the TConDec-R language [2], a declarative process modeling language that enables the specification of temporal constraints related to the TPs. As demonstrated in this work, TConDec-R is suitable for modeling a sophisticated and real-world process scenario from the healthcare domain. The remainder of the paper is organized as follows. Section 2presents backgrounds on temporal constraints in declarative process modeling languages and shows why TConDec-R was selected for modeling the considered scenario. Section 3motivates the need for coordinating the constraint-based interactions among all the processes in a hospital forming the overall patient treatment process. Section 4details how TConDec-R is used for modeling such a scenario. Section 5discusses our work. Finally, Sect. 6concludes the paper with a summary and an outlook. 2 Background This section discusses work related to the considered time patterns (cf. Sect. 2.1). It then presents a review of proposals that support temporal constraints in Table 1. Selected process time patterns. Cat Time pattern (TP) Example ITP1 (Time Lags between two Activities) enables the definition of different kinds of time lags between two activities The time lag between registering a Master thesis and submitting it must not exceed 6 months TP2 (Durations) allows specifying the duration of process activities Processing 100 requests must not take longer than 1 s II TP5 (Schedule Restricted Element) allows restricting the enactment of a particular activity by a schedule Comprehensive lab tests in a hospital can only be done from MO-FR between 8 am and 5 pm TP6 (Time-based Restrictions) provides support for restricting the number of times a specific process element may be executed within a given timeframe For a specific lab test at least 5 different blood samples have to be taken within 24 h contemporary declarative process modeling languages (cf. Sect. 2.2). Finally, it provides an overview of TConDec-R, a declarative process modeling language with extensive support for temporal constraints (cf. Sect. 2.3). 2.1 Process Time Patterns In [13,14], we systematically identified 10 process time patterns (TPs) by analyzing a large collection of process models from various domains. In this context, 4 of the 10 TPs are considered in the present work as they refer to aspects directly related to the considered scenario (cf. Table 4, column TP). Specifically, constraints C8, C17, C18, C19, C21, C22, and C23 correspond to TP1; C11, C12 and C20 correspond to TP5; finally, C3, C14, and C5 correspond to TP6. In addition, the duration of the activities (cf. Table 3) corresponds to TP2. We divided the time patterns into two categories according to pattern semantics (cf. Table 1). Category I (Durations and Time Lags) provides support for expressing the durations of different process granularities (i.e., activities, activity sets, processes, or sets of process instances) as well as time lags between activities or process events (e.g., milestones). Category II (Restricting Execution Times), in turn, allows constraining execution times of single activities or entire processes (e.g., deadlines). All considered time patterns are highly relevant for the support of patient treatment processes. Note that there exist numerous variants of the time patterns, also denoted as pattern variants [14]. To cope with this variability and to keep the number of patterns manageable, design choices allow for TP parametrization [14]. For example, whether a time lag represents a minimum value, maximum value, or both (i.e., an interval) constitutes a design choice of pattern TP1 (Time Lags between Activities). Additional variance of this time pattern is caused by the fact that time lags may be specified either between the start of two activities, the start of the first and the end of the second activity, the end of the first and the start of the second activity, or the end of the two activities. Other design choices, in turn, cover the fact that different time granularities (e.g., second or hour) or process granularities (i.e., activity, activity set, process, or set of process instances) may be applied in the context of the time patterns. A complete list of pattern design choices and, hence, pattern variants, is presented in [14]. 2.2 Temporal Constraints in Declarative Processes Modeling Languages This section reviews the works dealing with declarative process modeling languages that support the temporal constraints necessary for modeling the considered scenario. There exist several proposals for handling the temporal constraints in different domains. We exclude works that are not related to business processes, view temporal constraints solely in the sense of ordering relations, or only mention temporal constraints at an abstract level (i.e., no specific temporal constraints are discussed). In the end, several papers [2,4,9,10,15–18,20,26,32] were identified as relevant works in the context of our research. In order to asses the support each proposal provides for the time patterns, we analyzed the following temporal constraint features: F1. Does the proposal allow specifying time lags between activities? (cf. TP1) F2. Does the proposal allow specifying the duration of process activities? (cf. TP2) F3. Does the proposal consider constraints that may refer to a calendar or schedule? (cf. TP5) F4. Does the proposal allow for time-based constraints, restricting the number of times a particular process element may be executed within a pre-specified timeframe? (cf. TP6) The respective declarative approach allows specifying the temporal constraints related to the considered time patterns (cf. Table 1), if these four features can be checked. Note that we check whether the proposed modeling language directly supports the elements needed for assessing the feature. Hence, we do not check for workarounds of the respective approach possible in this context. Table 2includes the considered works together with the answers (i.e., yes () or no (X)) to each feature. It indicates that (1) patterns TP1 and TP2 are well supported, (2) pattern TP4 is only supported by [2,18], and (3) TConDec-R [2] is the only approach supporting TP6. Therefore, to the best of our knowledge, only TConDec-R supports the modeling of business processes enhanced with the temporal constraints related to the time patterns (cf. Table 1). Moreover, for every TConDec-R temporal constraint all relations stated in Allen’s interval algebra [1] (i.e., start-start, start-end, end-start, and end-end) can be specified. Table 2. Consolidated results of the review. Work Features F1 F2 F3 F4 Montali et al. [20]  X X Hildebrandt et al. [9]XXX Maggi et al. [15–17]XXX Jiang et al. [10]  X X Burattin et al. [4,26]XXX Mans et al. [18]XX Barba et al. [2]    =true,X=false 2.3 The TConDec-R Language As basis of the TConDec-R language [2], we use Declare [23] for specifying activities and their behavioral (i.e., control-flow) constraints. We consider this declarative modeling language as appropriate as it enables the specification of a wide range of process models in a flexible way. Respective process models are denoted as constraint-based, i.e., they comprise information about (1) the activities that may be performed during process enactment as well as (2) the constraints to be obeyed in this context. The activities of a constraint-based process model may be executed arbitrarily often unless this is restricted by any constraint. Declare constraints can be categorized as follows [23]: 1. Existence constraints are unary relationships constraining the number of times a particular activity may be executed in the context of a process instance. For example, Exactly(A,n) specifies that activity Amust be executed exactly ntimes for each process instance. 2. Relation constraints are positive binary relationships used to either enforce or allow for the enactment of activities in certain situations. For example, Precedence(A,B) specifies that activity Bmay only be executed if Ais executed before. 3. Negation constraints are negative binary relationships used to forbid the enactment of certain activities in specific situations. For example, NotCoexistence(A,B) expresses mutual exclusion of A and B, i.e., Amust not be executed if Bis executed, and vice versa. Definition 1. (TConDec-R activity).ATConDec-R activity act = (a, dur)refers to a process activity awith its estimated duration dur.1 1Respective estimates can be obtained by interviewing subject matter experts or by analyzing the event logs of completed process instances. Moreover, both approaches can be combined to obtain more reliable estimates. Definition 2. (TConDec-R process model).ATConDec-R process model TCR = (Acts, CT) corresponds to an extended constraint-based process model, where –Acts is a set of TConDec-R activities and –CTis a set of constraints that may include any control-flow constraint supported by Declare as well as any temporal constraint related to the time patterns (cf. Table 1). TConDec-R constraints are specified according to the graphical notation proposed for Declare constraints [23] and using the graphical notation proposed in [13] for visualizing the temporal constraints.2 TConDec-R process model B 2 [2h,4h] A 3 1h 75 6 12 11 10 84 2 1 93 Daily Schedule Start [8am,10am] 6h 75 6 12 11 10 84 2 1 93 12 5 3 4 Fig. 1. A simple TConDec-R process model. Example 1. (TConDec-R process model). Figure 1shows a simple example of a TConDec-R process model: –Acts ={(A, 1h),(B,6h)}consists of two activities Aand B;Ahas an estimated duration of 1 hour. In turn, Bhas an estimated duration of 6 hours; –CTcomprises the following constraints: (1) Exactly(A, 3), expressing that Ashall be executed exactly three times, (2) Exactly(B,2), expressing that Bshall be executed exactly twice, (3) Precedence(A, B), expressing that activity B may only be executed if A is executed before, (4) TimeLagEndStart(A, B, 2h, 4h), representing a temporal constraint corresponding to time pattern TP1; it expresses that for each execution Ai of A, there must be at least one execution Bjof B such that there is a time lag of at least 2 hours (2h) and at most 4hbetween the end time of Aiand the start time of Bj,and (5) DailyScheduleStart(A, 8am, 10am), expressing a temporal constraint related to TP5, i.e., each execution of Amust start between 8 and 10am. 2A complete formalization of the TConDec-R constraints is available at http:// azarias.lsi.us.es/TCR/Formalization.pdf. In order to provide support to the TConDec-R language, a web-based tool has been implemented based on previous approaches [2,11].3The tool consists of a light-weight web interface that allows for (1) textually modeling declarative business processes using the TConDec-R language or loading already created models, and (2) providing operational support for the models (e.g., generating valid execution traces or checking the conformance of models). For example, Fig. 2shows the tool where a TConDec-R model has been loaded and a valid trace is generated. The client uses a REST API layer to connect to a server being in charge of all the heavy-duty tasks requested by the user interface. Fig. 2. TConDec-R client interface. 3 Clinical Process Scenarios 3.1 General Insights into Clinical Practice In the following, an impression of the constraints driving the interactions between the clinical workflows of a patient treatment process is given to emphasize under which conditions constraint-based solutions need to operate in a healthcare environment. In the context of a patient treatment process, numerous clinical procedures have to be planned, ordered and prepared, appointments be made, and results be obtained and evaluated. Moreover, many procedures need preparatory measures of various complexity. Before a surgery may take place, a patient has to undergo numerous preliminary examinations (i.e., smaller processes), each of them requiring additional preparations. While some of them are known in advance, others may have to be scheduled dynamically, depending on the individual patient and her state of health. 3It is available at http://azarias.lsi.us.es/TCR/ModelChecker. In general, the various clinical workflows to be performed in a patient treatment process as well as their tasks may have to consider complex temporal constraints. After an injection with contrast medium was given to a patient, for example, some other tests cannot be performed within a certain period of time. In contemporary healthcare environments, physicians still have to coordinate the tasks related to their patients manually, taking into account all the constraints existing in this context. Therefore, changing a schedule is not trivial and requires time-consuming communication. For other procedures, medical staff from various departments have to collaborate. Thus, the process is subdivided into organization-oriented views leading to several problems. First, patients have to wait, because resources (e.g., physicians, rooms or technical equipment) are not available due to insufficient coordination. Second, medical procedures cannot be performed as planned if information is missing, preparations are omitted, or a preceding procedure is postponed, canceled or requires latency time. Depending procedures might then have to be re-scheduled resulting in time-consuming phone calls. Third, if urgently needed results are missing, clinical procedures may have to be performed repeatedly causing unnecessary costs and burdening patients. For all these reasons, from both the patient and the hospital perspective undesired effects occur: hospital stays can take longer than required and costs or even invasiveness of patient treatment increase. Therefore, healthcare process support, in particular regarding the many constraint-based interactions between processes, would be highly welcome by medical staff. 3.2 A Concrete Treatment Scenario This section deals with the considered clinical scenario, which we derived by interviewing subject matter experts as well as by analyzing process-relevant information (e.g., patient records, process handbooks) [22,27]. This clinical scenario deals with surgeries (including their preparations) in the context of ovarian carcinoma [22,27]. Usually, patients with ovarian carcinoma are treated in the women’s hospital (WH); on average 2 patients with this diagnosis emerge to the WH per day. After admitting a patient to the gynecological ward, one of the two ward physicians visits and examines the patient. Afterwards, the physician orders and schedules a number of medical examinations, which need to be performed before the surgery may take place. Additionally, the patient needs to be examined by an anesthetist who may then request additional medical examinations before the surgery. Some of the examinations are not carried out in the WH itself, but are provided by other clinical departments, which may be either internal or external (i.e., placed at a different location) to the WH. In the given scenario, five external departments (i.e., Endoscopy Department (ED), Radiology Department (RD), Comprehensive Cancer Centre (CCC), Otolaryngology Department (OD), and Neurology Department (ND)) are involved as well as an internal one comprising two units (i.e., Ultrasound Unit (UU) and Laparoscopy Unit (LU)). Each department has limited resources that provide services to many other departments and clinics respectively (including WH). In order to ensure a fair use of the shared resources, a particular department may only order a maximum number of a specific examination from the respective provider per day. Table 3. Processes relevant in the context of the considered clinical scenario. ID Description Dur Unit/Dep %Req Ex0 First visit and examination of the patient 30 m WH 100 Ex1 Pelvic Ultra-sound Imaging 30 m UU 100 Ex2 Cystoscopy & Rectoscopy 2 h 30 m ED 100 Ex3 Uretero Pyelography 1 h 30 m RD 100 Ex4 CT scanning 45 m RD 60 Ex5 Magnetic Resonance Imaging 1 h 15 m RD 40 Ex6 Colonoscopy 2 h 15 m CCC 100 Ex7 Colon Contrast Imaging 3 h 30 m CCC 40 Ex8 X-ray of the gastrointestinal tract 1 h 15 m RD 35 Ex9 Chest X-ray 30 m RD 85 Ex10 Blood test 10 m WH 70 Ex11 Laparoscopy 1h LU 100 Ex12 Doppler examinations 30 m UU 20 Ex13 Medical council with the Otolaryngology Department 60 m OD 20 Ex14 Medical council with the Neurology Department 30 m ND 10 AN The patient is examined and interviewed by an anesthetist 1h WH 100 SU The surgery is performed 2–6 h WH 75 h = hours, m = minutes All relevant processes and activities of the considered clinical scenario (i.e., appointments to be made with the physician and anesthetist, medical examinations to be performed, and the surgery to be carried out) are summarized in Table 3: Column ID contains the identifier of the activity, Dur its average duration, and Unit/Dep the unit/department the activity is performed at. Finally, %Req indicates the frequency with which the respective examination is requested for a patient (e.g., %Req = 100 expresses that the examination is requested once for every patient, i.e., in 100% of all cases). Estimates regarding the average duration of the activities were obtained by interviewing subject matter experts. Considering such indications, an example of the different processes involving 14 patients for the considered scenario can be generated using the provided tool (cf. Sect. 2.3).4 4A graphical example is depicted in http://azarias.lsi.us.es/TCR/PlanEx1.pdf. 3. Barba, I., Weber, B., del Valle, C., Jimenez-Ramirez, A.: User recommendations for the optimized execution of business processes. Data Knowl. Eng. 86, 61–84 (2013) 4. Burattin, A., Maggi, F.M., Sperduti, A.: Conformance checking based on multiperspective declarative process models. Expert Syst. Appl. 65, 194–211 (2016) 5. de Leoni, M., Maggi, F.M., van der Aalst, W.M.P.: Aligning event logs and declarative process models for conformance checking. In: Barros, A., Gal, A., Kindler, E. (eds.) BPM 2012. LNCS, vol. 7481, pp. 82–97. Springer, Heidelberg (2012). https://doi.org/10.1007/978-3-642-32885-5 6 6. Dumas, M., van der Aalst, W.M.P., ter Hofstede, A.H. (eds.): Process-Aware Information Systems: Bridging People and Software Through Process Technology. Wiley-Interscience, Hoboken (2005) 7. Haisjackl, C., Barba, I., Zugal, S., Soffer, P., Hadar, I., Reichert, M., Pinggera, J., Weber, B.: Understanding declare models: strategies, pitfalls, empirical results. Softw. Syst. Model. 15(2), 325–352 (2016) 8. Heuck, E., Hildebrandt, T., Kiærulff Lerche, R., Marquard, M., Normann, H., Iven Strømsted, R., Weber, B.: Digitalising the general data protection regulation with dynamic condition response graphs. In: Proceedings of BPM, pp. 124–134 (2017) 9. Hildebrandt, T., Mukkamala, R.R., Slaats, T., Zanitti, F.: Contracts for crossorganizational workflows as timed dynamic condition response graphs. J. Logic Algebraic Program. 82(5), 164–185 (2013) 10. Jiang, Y., Xiao, N., Zhang, Y., Zhang, L.: A novel flexible activity refinement approach for improving workflow process flexibility. Comput. Ind. 80, 1–15 (2016) 11. Jim´enez-Ram´ırez, A., Barba, I., del Valle, C., Weber, B.: Generating multiobjective optimized business process enactment plans. In: Salinesi, C., Norrie, M.C., Pastor, ´ O. (eds.) CAiSE 2013. LNCS, vol. 7908, pp. 99–115. Springer, Heidelberg (2013). https://doi.org/10.1007/978-3-642-38709-8 7 12. Jimenez-Ramirez, A., Barba, I., Fernandez-Olivares, J., del Valle, C., Weber, B.: Time prediction on multi-perspective declarative business processes. Knowledge and Information Systems, pp. 1–31 (in press) 13. Lanz, A., Reichert, M., Weber, B.: Process time patterns: a formal foundation. Inf. Syst. 57, 38–68 (2016) 14. Lanz, A., Weber, B., Reichert, M.: Time patterns for process-aware information systems. Requirements Eng. 19(2), 113–141 (2014) 15. Maggi, F.M.: Discovering metric temporal business constraints from event logs. In: Johansson, B., Andersson, B., Holmberg, N. (eds.) BIR 2014. LNBIP, vol. 194, pp. 261–275. Springer, Cham (2014). https://doi.org/10.1007/978-3-319-11370-8 19 16. Maggi, F.M., Dumas, M., Garc´ıa-Ba˜nuelos, L., Montali, M.: Discovering dataaware declarative process models from event logs. In: Daniel, F., Wang, J., Weber, B. (eds.) BPM 2013. LNCS, vol. 8094, pp. 81–96. Springer, Heidelberg (2013). https://doi.org/10.1007/978-3-642-40176-3 8 17. Maggi, F.M., Westergaard, M.: Using timed automata for a Priori warnings and planning for timed declarative process models. Int. J. Coop. Inf. Syst. 23(1), 1440003 (2014) 18. Mans, R.S., Russell, N.C., van der Aalst, W.M.P., Bakker, P.J.M., Moleman, A.J.: Simulation to analyze the impact of a schedule-aware workflow management system. Simulation 86(8–9), 519–541 (2010) 19. Mertens, S., Gailly, F., Poels, G.: Enhancing declarative process models with DMN decision logic. In: Gaaloul, K., Schmidt, R., Nurcan, S., Guerreiro, S., Ma, Q. (eds.) CAISE 2015. LNBIP, vol. 214, pp. 151–165. Springer, Cham (2015). https://doi. org/10.1007/978-3-319-19237-6 10 20. Montali, M., Maggi, F.M., Chesani, F., Mello, P., van der Aalst, W.M.P.: Monitoring business constraints with the event calculus. ACM Trans. Intell. Syst. Technol. 5(1), 17 (2013) 21. Mulyar, N., Pesic, M., van der Aalst, W.M.P., Peleg, M.: Declarative and procedural approaches for modelling clinical guidelines: addressing flexibility issues. In: ter Hofstede, A., Benatallah, B., Paik, H.-Y. (eds.) BPM 2007. LNCS, vol. 4928, pp. 335–346. Springer, Heidelberg (2008). https://doi.org/10.1007/978-3-540-78238- 435 22. Ovarian cancer (CG122) (2011). http://www.nice.org.uk/CG122. Accessed 11 Jan 2017 23. Pesic, M.: Constraint-based workflow management systems: shifting control to users. Ph.D. thesis, Eindhoven University of Technology, Eindhoven (2008) 24. Reichert, M., Weber, B.: Enabling Flexibility in Process-Aware Information Systems. Springer, Heidelberg (2012). https://doi.org/10.1007/978-3-642-30409-5 25. Rovani, M., Maggi, F.M., de Leoni, M., van der Aalst, W.M.P.: Declarative process mining in healthcare. Expert Sys. Appl. 23, 9236–9251 (2015) 26. Sch¨onig, S., Di Ciccio, C., Maggi, F.M., Mendling, J.: Discovery of multiperspective declarative process models. In: Sheng, Q.Z., Stroulia, E., Tata, S., Bhiri, S. (eds.) ICSOC 2016. LNCS, vol. 9936, pp. 87–103. Springer, Cham (2016). https://doi.org/10.1007/978-3-319-46295-0 6 27. Schultheiß, B., Meyer, J., Mangold, R., Zemmler, T., Reichert, M.: Designing the processes for ovarian cancer surgery. Technical report DBIS-6, University of Ulm (1996) 28. van der Aalst, W.M.P., Pesic, M., Schonenberg, M.H.: Declarative workflows: balancing between flexibility and support. Comput. Sci. Res. Dev. 23(2), 99–113 (2009) 29. van Hee, K., Schonenberg, H., Serebrenik, A., Sidorova, N., van der Werf, J.M.: Adaptive workflows for healthcare information systems. In: ter Hofstede, A., Benatallah, B., Paik, H.-Y. (eds.) BPM 2007. LNCS, vol. 4928, pp. 359–370. Springer, Heidelberg (2008). https://doi.org/10.1007/978-3-540-78238-4 37 30. Weske, M.: Business Process Management: Concepts, Languages, Architectures. Springer, Heidelberg (2007). https://doi.org/10.1007/978-3-642-28616-2 31. Westergaard, M., Maggi, F.M.: Looking into the future. In: Meersman, R., Panetto, H., Dillon, T., Rinderle-Ma, S., Dadam, P., Zhou, X., Pearson, S., Ferscha, A., Bergamaschi, S., Cruz, I.F. (eds.) OTM 2012. LNCS, vol. 7565, pp. 250–267. Springer, Heidelberg (2012). https://doi.org/10.1007/978-3-642-33606-5 16 32. Zeising, M., Sch¨onig, S., Jablonski, S.: Towards a common platform for the support of routine and agile business processes. In: Proceedings of CollaborateCom, pp. 94– 103 (2014) 33. Zugal, S., Soffer, P., Haisjackl, C., Pinggera, J., Reichert, M., Weber, B.: Investigating expressiveness and understandability of hierarchy in declarative business process models. Softw. Syst. Model. 14(3), 1081–1103 (2015)