1 Introduction

During the last decades a variety of techniques for verifying the correctness of business process models were proposed. While early approaches focused on issues related to structural and behavioral model correctness (e.g., absence of deadlocks and livelocks) [80, 94], the semantic correctness of process models with respect to imposed compliance rules (i.e., business process compliance) has been subject to recent works [6, 30, 41, 61]. Compliance rules constrain the execution order (i.e., control flow) of tasks and may originate, for example, from security constraints, domain-specific guidelines, corporate standards, and legal regulations. Besides the control flow perspective, other fundamental perspectivesFootnote 1 relevant in the context of business process compliance refer to time, data, and resources as well as the interactions a business process has with partner processes [16, 47, 77].

1.1 Problem statement

In practice, compliance rules are represented in a rather verbose and ambiguous way. To enable the computer-based verification of business process compliance, i.e., to verify that a particular business process meets imposed compliance rules, subject matter experts and business analysts should provide unambiguous descriptions of compliance rules, which then can be translated into a machine-readable representation by IT experts. For the latter purpose, several approaches for the formal specification of compliance rules exist, e.g., applying linear temporal logics (LTL) [26] or using the formal contract language (FCL) [29]. As formal rule languages would be too intricate for subject matter experts and business analysts, rule patterns hiding formal details and providing informal explanations were suggested [20, 76, 78, 93]. Although few approaches exist that consider not only the control flow perspective, but also the data, time, and resource perspectives, these approaches only support a pre-specified set of rule patterns.

As shown by empirical studies, business process modeling and compliance rule description languages, which both employ visual notations, offer advantages compared to purely text-based specifications [34, 73]: First, visual notations significantly increase model and rule comprehensibility after providing some training to users. Second, they foster the communication among business analysts and subject matter experts on one hand and process engineers on the other. As a prerequisite for the computerized support of visual specifications, the latter should be machine-readable, relying on a precise formal semantics.

Examples of visual notations for compliance rules include Compliance Rule Graphs [62], BPMN-Q [5], and BPSL [58]. Like visual process modeling languages (e.g., YAWL [96], ADEPT [81], and BPMN [71]),Footnote 2 these approaches combine an intuitive notation with the advantages of a formal language. Existing visual compliance rule languages, however, lack a comprehensive support of the time, data, resource, and interaction perspectives of a business processes, which hinders their use in more sophisticated scenarios.

1.2 Contribution

Although there exist pattern-based approaches for modeling compliance rules also covering the time, data, and resource perspectives, a respective visual modeling support has not been provided so far [76, 93]. To remedy this drawback, this paper provides an approach for the visual modeling of compliance rules that may refer to these perspectives as well as to the interactions a business process may have with partner processes. In particular, the paper shows how the various perspectives can be visually represented with the extended Compliance Rule Graph (eCRG) language. We evaluate the expressiveness of the latter based on well-known patterns and apply the eCRG language to a real-world healthcare scenario. Furthermore, understandability issues are considered in an empirical study. Finally, we present a proof-of-concept prototype that supports the modeling of eCRGs as well as their verification. The latter is based on a profound formal semantics of the eCRGs, which is provided in a technical report [45]. Altogether, the eCRG language allows domain experts to capture compliance requirements at both an abstract and a visual level, while enabling the specification of verifiable compliance rules that consider the various perspectives.

This paper significantly extends our previous work, which introduced fundamentals of the eCRG language [46, 90]: In [46], we provided a very brief overview of the eCRG language, whereas in [90] we focused on the resource perspective solely. In addition to these preliminary works, this paper provides

  • the first detailed presentation of the eCRG elements covering the interaction, time, data, and resource perspectives,

  • an empirical study on the comprehensibility of the eCRG language,

  • a proof-of-concept prototype, which comprises a modeling environment as well as an eCRG compliance checker verifying the compliance of given process execution logs with a set of eCRGs, and

  • an extended and more profound discussion of related work.

The remainder of the paper is organized as follows: Sect. 2 provides an application scenario from the healthcare domain, which we will use as illustrating example throughout the paper. In Sect. 3, we introduce the eCRG language step-by-step. Specifically, this language supports the visual modeling of compliance rules that may refer to the control flow, interaction, time, data, and resource perspectives. To assess the approach, Sect. 4 provides a pattern-based evaluation and demonstrates the modeling of real-world compliance rules with the eCRG language. Furthermore, it presents an empirical study and the proof-of-concept prototype we developed. Related Work is discussed in Sect. 5. Section 6 concludes the paper and provides an outlook on future work.

2 Application scenario

This section introduces a healthcare scenario dealing with compliance rules and processes captured in the context of a large process engineering project in a university hospital [49, 52]. We will refer to this scenario throughout the paper to illustrate how the elements of the eCRG language can be applied.

Fig. 1
figure 1

Organizational units and partners

Full size image

Selected organizational units and related sub-units are depicted in Fig. 1 [49, 52]. On the right, two sub-units of the university hospital are shown, i.e., the woman’s hospital, together with its wards (e.g., postnatal ward 1) and service units (e.g., admission unit), and the radiology department. On the left, external partners of the hospital are depicted, e.g., a gynecologist, a general practitioner, and a blood center.

The example refers to six actors (i.e., Mrs. A, Mr. B, Mr. C, Mrs. E, Mrs. G, and Mr. H) having different roles and being assigned to different organizational units. Mrs. A, Mr. B, and Mr. C are members of the radiology department, whereas Mrs. E, Mrs. G, and Mr. H are assigned to ward 1. Mr. B and Mrs. E both have role physician, whereas Mrs. A has role MTA (i.e., medical technical assistant); Mrs. G and Mr. H are nurses and Mr. C is the secretary of the radiology department.

Table 1 depicts compliance rules C1–C10, which emphasize the need for covering the control flow, time, data, and resource perspective of business processes as well as the interactions a business process has with partner processes.

All rules from Table 1 consider the control flow perspective. For instance, C1 requires the execution of tasks order X-ray and fill order form prior to the one of task X-ray examination. C2 states that the document informed consent must be received and checked prior to the execution of task X-ray examination. C4 requires that task refer patient shall be succeeded by task admit patient. Rules C2 and C3 additionally refer to the interaction perspective of a business process (i.e., the sending and receipt of messages). More precisely, C2 requires the receipt of a message including document informed consent, whereas rule C3 requires waiting for the receipt of a message containing the X-ray images.

The time perspective is considered by rules C4, C5, C7, and C10. Rule C4 defines a maximum time distance between tasks refer patient and admit patient (i.e., 1 week), whereas C5 and C7 specify minimal time distances (see [56, 57] for relevant process time patterns). More precisely, C5 constrains the time minimum distance between tasks order blood bags and surgery, and C7 the minimum time distance between two different occurrences of task administer, i.e., one occurrence with drug Aspirin and another one with drug Marcumar. In addition, C10 refers to a fixed point in time; i.e., October 26, 2013.

Rules C2, C7, and C8 constitute examples of compliance rules referring to the data perspective. According to C2, document informed consent needs to be first transmitted through a message and then be checked. Rule C7 expresses that drugs Aspirin and Marcumar are used by task administer. C8 requires an additional tolerance test if the value of data object age is greater than 75.

Table 1 Examples of healthcare compliance rules based on [52]
Full size table

Compliance rules C1, C2, C3, and C6 refer to the resource perspective. On one hand, C1 reflects the resource perspective by requiring the assignment of a performer with role physician to the respective ward. On the other, C1 requires that both tasks (i.e., order X-ray and fill order form) are performed by the same person (i.e., binding of duties). Rule C2 requires performers with different roles being assigned to the same organizational unit. By contrast, C3 solely refers to role physician. Finally, compliance rule C6 provides another example of a binding of duties constraint; i.e., one and the same physician should perform tasks request informed consent and inform patient.

Table 2 provides an example of a possible execution log of a healthcare process that shall comply with the rules from Table 1.

Table 2 Execution log of a healthcare process
Full size table

3 The extended Compliance Rule Graph language

This section introduces the extended Compliance Rule Graph language, which enables the visual modeling of compliance rules considering multiple perspectives, i.e., control flow, interaction, time, data, and resources. We discuss the fundamental language design in Sect. 3.1, whereas Sect. 3.2 presents the elements of the eCRG language in detail.

3.1 Language design

The eCRG language enables the visual modeling of compliance rules in terms of rule graphs. It extends the CRG language introduced in [62, 63] by adding elements to explicitly cover the interaction, time, data, and resource perspectives as well. The overall purpose of the eCRG language is not only to provide a well-defined visual language, but to provide a tool fostering the communication between IT experts on one side and domain experts on the other.

Basically, an eCRG comprises nodes and edges that may be further enriched with attachments. Nodes may be used to either express events (e.g., the start or completion of a task, the receipt of a message, or the occurrence of a particular point in time) or entities (e.g., a data object, staff member, or role). In turn, the edges of an eCRG describe the relations between the nodes. Examples of such relations include the order of events or hierarchical relations between the staff members. Moreover, conditions may be attached to refine event and entity nodes as well as the relations (i.e., edges between them). Examples of respective attachments include restrictions on the data flow, the time distance between tasks, and the properties of staff members (e.g., a threshold for data flow values, maximum time distances, or required capabilities). Figure 2 depicts the various kinds of nodes, edges, and attachments supported by the eCRG language.

Fig. 2
figure 2

Nodes, edges, and attachments of an eCRG

Full size image
Fig. 3
figure 3

Components of an eCRG

Full size image

The specification of an eCRG comprises a pre- and a postcondition. The precondition specifies when the compliance rule shall be applied, whereas the postcondition needs to be met to satisfy the compliance rule. Accordingly, the elements of an eCRG (i.e., its nodes, edges and attachments) are partitioned into an antecedence pattern (A), which specifies the precondition, and at least one consequence pattern (C) specifying a postcondition. An eCRG may further contain references to instances of entities like a particular staff member (e.g., Mr. Smith), data container (e.g., credit points), or point in time (e.g., October 26, 2013). Note that certain instance nodes are neither part of the antecedence nor the consequence patterns as they are independent from both the pre- and postcondition of the eCRG.

Since the pre- and postconditions (i.e., the antecedence and consequence patterns) of an eCRG may require both the occurrence and the absence of certain events, the two patterns are further sub-divided into an occurrence sub-pattern on the one hand and an absence sub-pattern on the other. Note that elements of the antecedence occurrence (AO) and the consequence occurrence (CO) patterns require the occurrence of events, whereas elements of the antecedence absence (AA) and the consequence absence (CA) patterns require certain events to not occur. To visually distinguish between the patterns, the eCRG language uses dashed lines and round shapes for the elements of a consequence pattern and, by contrast, solid lines and square shapes for the ones of an antecedence pattern. Thick lines and square shapes are used to represent elements referring to particular instances of entities. Absence nodes are crossed out by an oblique cross in order to differentiate them from occurrence nodes.

Figure 3 illustrates the partitioning of an eCRG into its antecedence and consequence patterns as well as corresponding sub-patterns.

Fig. 4
figure 4

eCRG elements covering the control flow perspective

Full size image
Fig. 5
figure 5

Basic examples referring to the control flow perspective

Full size image

Considering this partitioning of an eCRG, an execution log is compliant with an eCRG, iff for each match of the eCRG antecedence pattern (i.e., satisfaction of the precondition), at least one corresponding match of a consequence pattern of the eCRG can be found (i.e., satisfaction of the postcondition). If the log does not include any match of the antecedence pattern (i.e., violation of the precondition), the process log is trivial compliant. If there is a match of the antecedence pattern (i.e., satisfaction of the precondition), for which no corresponding match of a consequence pattern exists (i.e., violation of the postcondition), the execution log violates the eCRG. Once compliance violations are detected, proper actions can be triggered in order to compensate the rule violation or to at least ensure its reporting.

A match of a particular antecedence or consequence pattern requires suitable events regarding the nodes of the occurrence sub-pattern. In addition, these events must satisfy all conditions imposed by the other elements of the pattern (i.e., edges, attachments, and entity nodes). For each absence node, in turn, the corresponding events must be missing or not meet the conditions imposed by connected edges and attachments.

Note that the design of the eCRG language partially considers the principles for designing effective visual notations [69]. Particularly, the concepts of semiotic clarity, perceptual discriminability, semantic transparency, graphic economy, and cognitive fit were taken into account.

Fig. 6
figure 6

Advanced examples referring to the control flow perspective

Full size image

3.2 eCRG modeling

This section shows how the different process perspectives can be modeled with the eCRG language. For each perspective, we first introduce the corresponding eCRG elements before illustrating their semantics along simple examples.

3.2.1 Control flow perspective

A fundamental process perspective of compliance rules concerns the control flow, which constrains the execution sequence as well as the occurrences of tasks. The elements of the eCRG language referring to the control flow perspective are shown in Fig. 4.

Task nodes express whether or not tasks of the given task type shall be executed. In detail, four kinds of task nodes are provided, which refer to the antecedence occurrence, antecedence absence, consequence occurrence, and consequence absence pattern. Note that the specification of the task type may be omitted, if the latter is not relevant.

In addition to task nodes, antecedence and consequence sequence flow connectors are provided. These connectors allow constraining the execution sequence of tasks. The absence of sequence flow indicates a parallel flow; i.e., then any possible execution sequence is allowed for the respective tasks. To clearly distinguish between start-start, start-end, end-start, and end-end constraints with respect to the execution sequence of tasks, sequence flow connectors are connected to either the right or left border of a task node. Exclusive connections express that exactly one of the connected tasks must be executed. In turn, alternative connections express that at least one of the connected tasks shall occur. Exclusive as well as alternative connections may be part of both the antecedence and the consequence pattern, but they must solely connect nodes within a particular pattern. Exclusive as well as alternative connections may involve more than two nodes.

Fig. 7
figure 7

eCRG elements covering the interaction perspective

Full size image
Fig. 8
figure 8

Examples referring to the interaction perspective

Full size image

Figure 5 provides basic examples of compliance rules referring to the control flow perspective. The eCRG from Fig. 5a refers to compliance rule C6, whereas the eCRG from Fig. 5b models a variation of C1. Figure 5c, d refers to the control flow perspective of C8 and C9, respectively. All eCRGs from Fig. 5a–c use one antecedence and one consequence occurrence task node as well as a consequence sequence flow connector that connects both task nodes restricting their execution order. Figure 5d shows an antecedence sequence flow connector specifying the order of two antecedence occurrence task nodes, whereas two consequence sequence flow connectors link the consequence occurrence task node placed between them.

More sophisticated examples are depicted in Fig. 6. Figure 6a uses two consequence occurrence task nodes as well as a consequence sequence flow connector to provide a more precise specification of compliance rule C1 (cf. Table 1). In order to capture the control flow perspective of C7, Fig. 6b provides two consequence absence task nodes linked by a consequence alternative connection. In turn, Fig. 6c solely uses an antecedence occurrence task node on the left and a consequence absence task node on the right side (i.e., no connector is used). Figure 6d refers to compliance rule C4; note that its consequence sequence flow connector does not express an end-start constraint (as, e.g., the rule in Fig. 6a), but an end-end constraint on the execution sequence of tasks.

3.2.2 Interaction perspective

The interaction perspective constrains the interactions a process may have with external partner processes, i.e., the exchange of messages with other organizations and information systems. The eCRG language offers specific nodes for representing the events of sending and receiving messages. Sending and receiving message nodes may be part of the antecedence occurrence, antecedence absence, consequence occurrence, or consequence absence patterns. As indicated in Fig. 7, labels on the message node allow not only specifying the message type, but also the message receiver and message sender, respectively. Similar to task nodes, the sender, receiver, and message type label may be omitted. Antecedence and consequence message flows connect message nodes referring to the sending and receipt of the same message.

Fig. 9
figure 9

eCRG elements covering the time perspective

Full size image
Fig. 10
figure 10

Examples referring to the time perspective

Full size image

Figure 8 uses the elements from Fig. 7 to model compliance rules referring to the interaction perspective. In particular, Fig. 8a shows a start-start constraint that uses the consequence absence variant of the receiving message node to model the control flow and interaction perspectives of compliance rule C3 (cf. Table 1). Figure 8b reflects C5 and includes a consequence occurrence sending message. The combination of an antecedence occurrence receiving message as precondition and a consequence occurrence sending message as postcondition is shown in Fig. 8c, whereas Fig. 8d depicts a consequence occurrence receiving message.

3.2.3 Time perspective

When having a closer look on the informal definition of compliance rules C4 and C7 from Table 1, it becomes clear that Fig. 6b–d does not fully cover them yet. The time distance between the interactions and tasks of C4 is not considered by the eCRGs from Fig. 6d. The eCRGs from Fig. 6b \(+\) c completely disallow for the co-occurrence of the two tasks instead of solely defining the required minimum time distance between them.

The time perspective of the eCRG language provides elements for covering such kinds of constraints (cf. Fig. 9), i.e., for modeling points in time and time conditions. Similar to task and message nodes, antecedence occurrence, antecedence absence, consequence occurrence, and consequence absence point-in-time nodes are supported. Additionally, instance point-in-time nodes enable the specification of a concrete point in time (e.g., October 26, 2013). Antecedence and consequence time conditions may be attached to task nodes as well as sequence flow connectors to constrain either the duration of a task or the time distance between tasks/messages. Finally, antecedence and consequence time distance connectors may constrain the time distance between tasks/messages without implying a particular order between them.

Figure 10 depicts examples of eCRGs considering the time perspective as well. Figure 10a connects two antecedence occurrence task nodes using a consequence time distance connector. This eCRG exactly corresponds to compliance rule C7 from Table 1. In turn, Fig. 10b enriches a consequence sequence flow connector with a time condition to model compliance rule C4. To visually specify compliance rule C10, Fig. 10c uses an instance point-in-time node and attaches a time duration condition attachment to an antecedence occurrence task node. The eCRG from Fig. 10d models compliance rule C5.

Fig. 11
figure 11

eCRG elements covering the data perspective

Full size image
Fig. 12
figure 12

Examples referring to the data perspective using data objects

Full size image
Fig. 13
figure 13

Examples referring to the data perspective using data containers

Full size image

3.2.4 Data perspective

Figure 11 depicts elements for modeling the data perspective of eCRGs: Data container nodes, data object nodes, data flow connectors, and data conditions are provided. Data containers refer to process data elements or global data stores, whereas data objects refer to specific data values and object instances, respectively. Similar to point-in-time nodes, data container and data object nodes may be part of the antecedence occurrence, antecedence absence, consequence occurrence, or consequence absence patterns, whereas instance data nodes refer to specific data containers or data objects (e.g., data container current diagnosis or data object X-ray image of Mr. Smith).

Fig. 14
figure 14

Examples referring to the data perspective using data conditions

Full size image

Antecedence and consequence data flow connectors define which process tasks read from (write to) which data objects or data containers. To enable the distinction of different data flows, labels may refer to input/output parameters. The caption of a data object/container may specify the parameter name as well. Finally, antecedence and consequence data relation connectors express relations among data objects.

To constrain values of data flow or parameters of tasks/messages, antecedence or consequence data conditions may be attached to data flow connectors and task/message nodes. Timed condition connectors may be added to the antecedence or consequence patterns to constrain the values of data containers at particular points in time.

Figure 12 provides examples of eCRGs with data object nodes. Figure 12a depicts an eCRG with a consequence occurrence data object and a consequence data flow connector. Figure 12b \(+\) c depicts a variant of compliance rule C1 (cf. Table 1) and highlight the specification of input/output parameters based on labeled consequence occurrence data objects and consequence data flow connectors. An antecedence occurrence data object and the corresponding antecedence data flow are shown in Fig. 12d, whereas Fig. 12e uses two particular instances of data objects (i.e., Marcumar and Aspirin) to model compliance rule C7.

Figure 13 illustrates the use of data container nodes. The eCRG from Fig. 13a uses a consequence occurrence data container and consequence data flow. The use of an antecedence absence data container is illustrated by Fig. 13b, whereas the eCRG from Fig. 13c comprises an antecedence occurrence data container. Figure 13d \(+\) e refers to instance data container nodes.

Figure 14 provides examples illustrating the use of data condition attachments. In Fig. 14a, a consequence data condition constrains the value of a data flow, whereas the consequence data condition in Fig. 14b refers to a data object. An antecedence timed data condition of a data container is depicted in Fig. 14c. Figure 14d provides an antecedence data condition constraining the execution parameter of an antecedence occurrence task node. Finally, Fig. 14e attaches an antecedence data condition to a data object.

3.2.5 Resource perspective

The resource perspective of the eCRG language covers various kinds of human resources as well as their relations. Furthermore, it allows constraining the assignment of resources to tasks (cf. Fig. 15).

Fig. 15
figure 15

eCRG elements covering the resource perspective

Full size image

The eCRG language covers various resources, including staff member, role, group, and organizational unit, as well as their relations with tasks. Similar to data nodes, resource nodes may be part of the antecedence occurrence, antecedence absence, consequence occurrence, and consequence absence pattern of an eCRG or refer to particular instances of resource entities (e.g., staff member Mrs. A or role physician). Performing relation connectors indicate the performers of tasks. Resource relation connectors express relations among resources. Both connectors are either part of the antecedence or the consequence pattern. Resource condition attachments constrain the corresponding resource nodes. Note that the resource perspective can be easily extended with other kinds of resources if required.

Figure 16 illustrates the application and semantics of the performing relation connector. In Fig. 16a, antecedence performing relations are used to connect two antecedence tasks with the same antecedence staff member. Figure 16b depicts a consequence performing relation and an antecedence performing connector. In Fig. 16c, two consequence performing relations connect both antecedence tasks with the same consequence staff member. Note that the eCRGs from Fig. 16b \(+\) c express the same, as we assume that each task always has exactly one performer. Figure 16d shows how a consequence task can be connected to an antecedence task by using a consequence performing relation, whereas Fig. 16e uses a consequence absence staff member that is connected to two antecedence tasks through two consequence performing relations.

Fig. 16
figure 16

Examples referring to the resource perspective using performing relations

Full size image

Figure 17 illustrates the use and semantics of the resource relation connector. Figure 17a uses antecedence resource relations to connect two antecedence staff members with an antecedence absence organizational unit. Figure 17b depicts an antecedence as well as a consequence resource relation connecting two different antecedence staff members with the same antecedence organizational unit. Figure 17c comprises a consequence resource relation that connects antecedence and consequence staff members, whereas an antecedence resource relation connects the same antecedence staff member with the particular instance role physician. Figure 17d applies a consequence resource relation connector to refer from the antecedence staff member to instance role physician. Finally, Fig. 17e \(+\) f shows how the performing relation connector can directly refer to organizational unit and role nodes in order to specify the performers of tasks.

Fig. 17
figure 17

Examples referring to the resource perspective using resource relations

Full size image

Resource conditions and their semantics are illustrated in Fig. 18. Figure 18a illustrates the use of an antecedence resource condition constraining an antecedence organizational unit. Figure 18b applies a consequence resource condition to the same antecedence organizational unit, whereas a consequence organizational unit is subject to this condition in Fig. 18c. Despite this difference, Fig. 18b \(+\) c expresses the same. Note that the meaning of Fig. 18d would change when turning the constrained consequence organizational unit into an antecedence consequence organizational unit.

Fig. 18
figure 18

Examples referring to the resource perspective using resource conditions

Full size image

To enable a formal analysis and verification of eCRGs, we provide formal semantics for the eCRG language as well (for details, we refer to a technical report [45]). This semantics provides a transformation of eCRGs to first-order logic (FOL) defining how to interpret and evaluate an eCRG over execution logs.

Fig. 19
figure 19

Modeling control flow BPCPs as eCRGs

Full size image

4 Evaluation

This section evaluates the eCRG language and illustrates its use. First, Sect. 4.1 evaluates the expressiveness of the eCRG language based on well-known compliance patterns. Second, Sect. 4.2 assesses the suitability of the eCRG language with respect to the modeling of compliance rules from the real world. Third, Sect. 4.3 evaluates the comprehensibility of the eCRG language through an empirical study. Finally, Sect. 4.4 presents a proof-of-concept prototype demonstrating the feasibility of an eCRG-based tool enabling compliance modeling and automated compliance checking.

4.1 Pattern-based evaluation

This section evaluates the expressiveness of the eCRG language taking existing compliance pattern sets as benchmark. Respective patterns [57, 76, 93] resulted from extensive studies of regulations, standards, frameworks, process collections, and literature. Hence, they constitute suitable references for assessing the expressiveness of compliance rule modeling languages. More precisely, we tried to model the patterns covered by the business process control patterns [93], compliance rule patterns [76], and time patterns [56, 57] using the eCRG language. In addition, we checked for the semantic correspondence between eCRGs and related compliance patterns.

In [93], 27 business process control patterns (BPCP) were presented. These also include the property specification patterns [20]. Out of the 27 patterns, 15 focus on the control flow perspective, 7 on the resource perspective, and 5 on the time perspective. The data perspective is covered implicitly by each of the patterns, which do not distinguish between tasks and data conditions. Figure 19 illustrates how the 15 control flow patterns can be modeled using the eCRG language, and Figs. 20 and 21 show eCRGs covering the 7 resource patterns and the 5 time patterns, respectively.

Fig. 20
figure 20

Modeling resource BPCPs as eCRGs

Full size image
Fig. 21
figure 21

Modeling time BPCP as eCRGs

Full size image

Altogether we are able to model 26 out of the 27 business process control patterns (BPCP) with the eCRG language, including the 5 time patterns and 6 out of the 7 resource patterns. The only pattern for which we cannot provide a generic eCRG is the Multi-Segregated BPCP. Note that Fig. 20 only shows the eCRG for a special case of this BPCP, which requires the numbers of performers and tasks to be equal. Other variants of the Multi-Segregated BPCP can not be expressed when solely using one consequence pattern. For example, if the Multi-Segregated BPCP requires 4 tasks to be executed by 3 different performers (i.e., one performer must execute two tasks), \({\left( \begin{array}{l}4\\ 2\end{array}\right) }\) \(= 6\) consequence patterns are needed.

In [76], 55 control flow compliance rule patterns (CRP) were introduced. Additionally, Ramezani et al. [76] provides examples of the data and resource perspectives. The control flow compliance rule patterns are partitioned into 15 categories. We are able to show that the eCRG language supports all categories as well as their corresponding rules. Furthermore, the mentioned examples of the data and resource perspectives can be mapped to eCRGs as well. The respective eCRGs are described in a technical report [45], which also shows that the eCRG language is able to cover well-known time patterns [57].

4.2 Modeling real-world compliance rules as eCRGs

To evaluate the practical suitability of the eCRG language, we modeled real-world compliance rules from the healthcare domain [89]. Six process model collections were analyzed by a Master student from Management Science, i.e., someone with competencies comparable to a business analyst rather than to an IT expert. The student checked whether the process model collections are related to compliance rules and, if yes, whether these can be modeled with the eCRG language. The student performed these analyzes within a period of 6 month.

The process model collections and related artifacts had been created in the context of a large process reengineering project at a university hospital (cf. Sect. 2). The collections contain process models related to laboratory examinations [51], radiological services [52], therapeutic treatments [86, 88], and surgeries [50, 87]. The corresponding process models are described both visually and as text, providing information about the data and resource perspectives (e.g., organizational units, human resources) as well. Finally, the organizational structure of the hospital is described in terms of organization charts [49].

Before the study, the Master student received specific training. She attended a course on business process management, which included a lecture on business process compliance [82], and received a 30-min introduction into the eCRG language. Furthermore, relevant eCRG documentations (i.e., [45, 46]) and Microsoft Visio shapes representing the eCRG elements were handed over to her.

Altogether the Master student identified 30 compliance rules in the context of the six process model collections. Out of these 30 compliance rules, 5 refer to the interaction perspective, 8 to the time perspective, 14 to the data perspective, and 17 to the resource perspective. Note that a particular compliance rule may refer to multiple perspectives as well. The Master student was able to model each of the 30 compliance rules using the eCRG language and Microsoft Visio as modeling tool. The correctness of the eCRGs was reviewed twice. An IT expert, being familiar with the eCRG language, checked the syntax. The semantics (i.e., meaning) of the eCRGs was validated by a subject matter expert involved in the aforementioned process reengineering project.

Modeling real-world compliance rules revealed a few drawbacks regarding the modeling of the control flow, interaction, and time perspectives. In particular, it emphasizes the missing ability to refine tasks or to constrain business partners sending or receiving messages. Finally, a specific symbol for explaining periodic time events was missing. Such a symbol might ease the distinction between point-in-time nodes that refer to periodic and one-time events.

4.3 Experimental evaluation

To evaluate the comprehensibility of the eCRG language, we conducted a controlled experiment. The latter investigated the use of the eCRG language by students from Management Science (i.e., prospective business analysts) and Computer Science. All subjects had been provided with a short training before.

First, we tested whether the reading of eCRGs supports subjects in understanding the meaning of the respective rules (cf. Hypothesis H1 \(+\) H2). Second, we compared the understanding of the eCRG language for the two subject groups (i.e., Management Scientists and Computer Scientists—cf. Hypothesis H3).

  1. H1

    Trained Management Scientists are able to understand eCRGs; i.e., reading eCRGs increases their domain understanding.

  2. H2

    Trained Computer Scientists are able to understand eCRGs; i.e., reading eCRGs increases their domain understanding.

  3. H3

    There is no large difference between Management Scientists and Computer Scientists regarding the understanding of eCRGs.

As subjects 80 students from Ulm University were chosen, 59 of them were male and 21 female. Fifty-five subjects studied Management Science [MS], and 25 Computer Science [CS]. All subjects attended a course on business process management at the time the experiment took placeFootnote 3 and received course credit points for participating in the study. Furthermore, the course included a lecture on business process compliance [82], which covered the eCRG language as well. As additional material, a course book was distributed to the students.

The study is based on a questionnaire that, first of all, requests general information from the subjects (e.g., age, gender, and study program of the subject). Then, it asks for self-ratings regarding the familiarity of the respective subject with the eCRG language and related notations (e.g., BPMN). The main part of the questionnaire comprises 10 eCRGs. For each eCRG, 3 questions related to domain understandability (i.e., the expressed compliance rule) were asked. A correct answer scores with one point. Accordingly, the maximum total score is 30, expressing that the respective subject was able to answer all questions correctly. Each time after answering 6 questions (i.e., after processing two eCRGs), the subject is asked additional questions.

To rule out learning effects due to the labeling of the eCRG elements, we provided two versions of the questionnaire that alternately abstract the elements of eCRGs; i.e., concrete labels are replaced by abstract identifiers (e.g., using label Task A instead of label check job application). This ensures that any measured increase in understandability can be directly related to the eCRG language; i.e., it is not biased due to existing domain knowledge of the subjects. Finally, we recorded the time needed by the respective subjects to process the questionnaire.

Table 3 provides the descriptive statistics of the experiment regarding the scores of the subjects. Figure 22 shows the corresponding distribution. As we cannot assume a normal distribution,Footnote 4 we apply nonparametric tests in addition to parametric t tests. While parametric tests are only considered as robust in the context of non-normal distributions [59, 79], nonparametric tests are independent from this assumption.

Table 3 Descriptive statistics: score
Full size table
Fig. 22
figure 22

Distribution of the score

Full size image

To test H1 and H2 we check whether the scores of groups MS and CS significantly differ from random guessing. In this context we consider solely score points related to abstracted eCRGs in order to ensure that results are not biased due to the understanding of labels or domain knowledge. We perform a one-sample t test and a one-sample Wilcoxon signed-rank test. The p values of the tests are provided in Table 4. Both tests support H1 and H2; i.e., both tests show a very significant difference based on a 0.05 significance level.

Table 4 Increase in domain understanding (H1 and H2)
Full size table
Table 5 Comparing group MS with group CS (H3)
Full size table
Fig. 23
figure 23

Modeling component

Full size image

In order to test H3, we compare the complete score of group MS with the one of group CS. For this purpose, we performed an unpaired two-sample t test and a Mann–Whitney U signed-rank test (cf. Table 5 for p values). Both tests do not reveal a significant difference between the scores of the two groups when presuming a 0.05 significance level. Note that this does not mean that there is no difference between the two groups, but that this difference is too small to be detected by the experiment and corresponds to a trivial effect (effect size according to Cohen is \(d = 0.16\)). As shown in Table 5, the power of the tests is high enough to detect medium and large effects based on the recommended 0.80 level. Such an effect corresponds to a difference of at least 3.27 points in the context of our experiment [17, 24].Footnote 5

Altogether the experiment confirms that Management Scientists (i.e., no IT experts) are able to understand eCRGs and their eCRG understanding can reach a level not largely differing from the one of Computer Scientists (i.e., IT experts).

Limitations Apparently, the experiment faces several limitations. First, we did not involve and compare professional business analysts and IT experts from industry, but prospective ones (i.e., students). Although various investigations have shown that students are proper substitutes for professionals in empirical studies (e.g., [38, 92]), the results for professionals may differ. Second, the experiment uses 10 prespecified eCRGs that address all process perspectives supported by the eCRG language as well as its core elements. However, the questionnaire neither included all elements of the eCRG language nor did it consider all possible combinations of language elements. Accordingly, we cannot ensure that we always obtain similar results for the various eCRGs. Finally, the sample size of the experiments only allows detecting medium and large differences.

4.4 Proof-of-concept prototype

To demonstrate the feasibility of a posteriori compliance checking [43] based on the eCRG language, we implemented a proof-of-concept prototype.

The modeling component of this prototype is depicted in Fig. 23. On the left, the elements of the eCRG language (i.e., nodes, edges and attachments) are displayed, which may then be dragged and dropped on the drawing panel in the center. The latter allows layouting the elements and connecting them with each other. The map on the bottom left highlights the active region of the drawing panel. Furthermore, the modeling environment supports different export formats including svg, jpg, pdf, and xml.

Another component of the prototype (cf. Fig. 24) enables a posteriori compliance checking of execution logs; i.e., it allows determining whether logs comply with a given eCRG. For this purpose, eCRGs created with the modeling tool can be imported.

Based on the formal semantics of the eCRG language (see [45] for details), the tool enables a posteriori analyses of process execution logs to determine whether completed or running process instances comply with a particular eCRG. Users may load eCRGs and execution logs dynamically. Compliance verification starts when pressing the verify button on the bottom left. The corresponding result, in turn, is shown below the button. Finally, users may visualize eCRGs and execution logs.

The described prototype was applied to various scenarios and compliance rules, respectively, including the ones from the presented healthcare example. Figure 24 provides a screenshot of the eCRG checker.Footnote 6

Fig. 24
figure 24

Compliance checking component

Full size image

5 Related work

The eCRG language enables the visual modeling and verification of compliance rules referring to multiple perspectives of business processes. Beyond the control flow perspective, the interaction, time, resource, and data perspectives of business processes are considered. Accordingly, we structure related work into three categories: Sect. 5.1 presents approaches addressing the interaction, time, resource, and data perspectives in the context of process modeling. Business process compliance and compliance verification are addressed in Sect. 5.2. Finally, Sect. 5.3 discusses other notations for modeling process compliance rules.

5.1 Perspectives of business processes beyond control flow

Modeling issues related to the interaction, time, resource, and data perspectives of business processes have been addressed by a plethora of approaches and languages. For example, van der Aalst et al. [97], Decker and Weske [18], Barros et al. [9] deal with the interaction perspective, i.e., the exchange of messages between partners involved in a cross-organizational process. The integration of temporal constraints into business process models (i.e., time perspective) is addressed in [21, 57], whereas [54, 55, 67] focus on the data perspective. In turn, Russell et al. [84], Cabanillas et al. [14, 15] deal with the assignment of resources to business process activities (i.e., resource perspective). However, there is only little work dealing with the interplay of multiple perspectives. For example, Knuplesch et al. [42] and Meyer et al. [66] deal with the data perspective of cross-organizational business processes (i.e., the data and interaction perspective). The modeling of process-aware enterprises with respect to multiple perspectives is addressed in [13, 25].

5.2 Business process compliance

Business process compliance has gained increasing attention over the last years, and several surveys have emerged [1, 11, 23, 40, 47]. On the one hand, there exist frameworks that address the integration of business process compliance throughout the entire process lifecycle [43, 61, 77]. On the other, there are approaches dealing with business process compliance in a particular stage of the process lifecyle. In particular, van der Aalst et al. [95], Ramezani et al. [76], Outmazgin and Soffer [74] provide techniques for a posteriori verifying the compliance of execution logs with a set of constraints. Certain approaches not only focus on the control flow perspective, but take the time perspective [78] or resource perspective [10] into account as well. To be able to quickly react to compliance violations or to prevent them, compliance monitoring [12, 27, 63–65] and continuous auditing [4] allow detecting process compliance violations during runtime. A framework for comparing respective approaches is proposed by Ly et al. [60]. To verify whether compliance rules are met by a particular process model at design time, a multitude of approaches exists applying model checking techniques (e.g., [26, 58]). In this context, Awad et al. [6], Knuplesch et al. [41] consider the data perspective and [44, 48] the interaction perspective. An approach checking the compliance of process models with respect to given semantic constraints and ensuring the validity of process change operations based on mixed integer programming formulation is proposed in [53]. The latter further introduces notions like degree of compliance, validity of change operations, and compliance by compensation. Other approaches for verifying compliance at design time apply the notion of semantic congruence [37] or use Petri Nets [2], considering the data and time perspectives as well. Finally, declarative approaches [3, 28, 33, 75, 99] ensure compliance in an elegant way. Since processes are defined by means of a set of constraints, imposed compliance rules only have to be added to the process definition to ensure business process compliance.

5.3 Compliance rule notations

To enable the verification of business process compliance rules, the latter must be specified unambiguously in a machine-readable way. For this purpose, Governatori and Sadiq [31] developed a logic-based formalism for describing both the semantics of normative specifications and compliance checking procedures. This approach allows modeling business obligations and regulating the execution of business processes. In turn, Dwyer et al. [20], Namiri and Stojanovic [70], Turetken et al. [93], Ramezani et al. [76] apply patterns to specify compliance rules. Furthermore, there are approaches using semantic annotations to ensure compliance [29]. Other approaches rely on temporal logics (e.g., [22, 26, 41]), like the LTL, with which the control flow perspective can be modeled based on operators like next, eventually, always, and until.

An approach for visually modeling compliance is described in [6, 7]. It considers the control flow and data perspectives; [85] additionally includes security constraints. There exist other visual approaches for compliance rule modeling [22, 58, 62], which focus on the control flow and partially on the data perspective, but ignore the other perspectives.

A generic querying language which can be applied to a wide range of conceptual models is presented in [19]. In particular, this language can be used to specify compliance rules as well.

An approach connecting visual compliance rule notations with informal and textual specifications is presented in [91], whereas [98] deals with the transformation of natural text into formal compliance rules.

Visual notations for declarative business processes (e.g., DECLARE [75], DCR Graphs [36]) could be used to model compliance rules as well. Note that some of these approaches address the data and/or time perspectives [8, 68].

Artifact-centric approaches [39] and business rules [35] emerged recently. Furthermore, there exist commercial as well as open source business rule engines (e.g., IBM ILOG and JBoss Drools) and related standards (e.g., BRML [32], SBVR [72]). Note that respective approaches are expressive and allow addressing the different perspectives of business processes and compliance rules. As a drawback, however, these approaches are mainly text-based; i.e., they do not provide a visual notation with an explicit support of the control flow, interaction, time, data, and resource perspectives.

6 Summary and outlook

While compliance rule modeling has been addressed by a plethora of approaches, the integrated visual modeling of the control flow, interaction, time, data, and resource perspectives has not been sufficiently addressed yet [16, 76, 93]. To remedy this drawback, this paper proposes the eCRG language. This language not only considers the control flow perspective, but enables the visual modeling of compliance rules with the support of the other mentioned perspectives as well.

Taking our previous work on the eCRG language [46, 90] into account, we introduced the elements of the eCRG language in detail and illustrated them along examples. We showed that the eCRG language covers the various perspectives one faces when modeling compliance rules from real-world scenarios. The provided pattern-based evaluation further confirmed the expressiveness of the eCRG language. To enable tool support for both the modeling and the verification of compliance rules, a formal semantics of the presented visual compliance rule language has been provided in a technical report [45]. Based on this semantics, we implemented a proof-of-concept prototype that a-posteriori analyzes whether execution logs comply with given eCRGs, taking the control flow, interaction, time, data, and resource perspectives into account. To support the visual modeling of eCRGs another component of this proof-of-concept prototype is provided by the modeling environment for the eCRG language.

In future work, we will consider the feedback we gathered during the modeling of real-world compliance rules to enhance the visual compliance rule language. Furthermore, we will compare the eCRG language with pattern- and logic-based approaches in another empirical study. Our overall aim is to ensure multi-perspective compliance for all phases of the process life cycle, including runtime compliance monitoring as well as a priori compliance checking at design time. Finally, we will consider compliance checking in the context of process changes.