On Enabling Compliance of Cross-Organizational Business Processes [original]

On Enabling Compliance of

Cross-organizational Business Processes ⋆

David Knuplesch1, Manfred Reichert1, Walid Fdhila2, and

Stefanie Rinderle-Ma2

1Institute of Databases and Information Systems, Ulm University, Germany

2Faculty of Computer Science, University of Vienna, Austria

{david.knuplesch,manfred.reichert}@uni-ulm.de,

{walid.fdhila,stefanie.rinderle-ma}@univie.ac.at

Abstract. Process compliance deals with the ability of a company to

ensure that its business processes comply with domain-specific regula-

tions and rules. So far, compliance issues have been mainly addressed

for intra-organizational business processes, whereas there exists only lit-

tle work dealing with compliance in the context of cross-organizational

processes that involve multiple business partners. As opposed to intra-

organizational processes, for a cross-organizational process, compliance

must be addressed at different modeling levels, ranging from interaction

models to public process models to private processes of the partners. Ac-

cordingly, there exist different levels for modeling compliance rules. In

particular, we distinguish between local compliance rules of a particular

partner and global compliance rules to be obeyed by all partners involved

in the cross-organizational process. This paper focuses on checking the

compliance of interaction models. For this purpose, we introduce the no-

tion of compliability, which shall guarantee that an interaction model is

not conflicting with a set of imposed global compliance rules.

1 Introduction

Business process compliance has been identified as one of the core challenges

for process-aware information systems [23]. So far, the focus has been on intra-

organizational business processes, and a variety of proposals for checking the

compliance of a business process with domain-specific regulations and rules in

different phases of the process life cycle have been made [1, 20, 13, 21, 22]. Besides

few approaches (e.g., business contracts [2, 11]), compliance checking for cross-

organizational processes has been neglected so far, even though being crucial in

collaborative settings [14, 16]. Therefore, the consideration of compliance rules

in the context of cross-organizational processes and the provision of techniques

for checking them are indispensable. Compared to approaches checking the com-

pliance of intra-organizational business processes, however, additional challenges

⋆This work was done within the research project C3Pro funded by the German Re-

search Foundation (DFG) under project number RE 1402/2-1, and the Austrian

Science Fund (FWF) under project number I743.

2 Knuplesch, Reichert, Fdhila, Rinderle-Ma

emerge [14]. In particular, process compliance must be ensured at different levels.

Furthermore, compliance checking must cope with the fact that parts of cross-

organizational processes are not known by all partners, e.g. due to privacy reasons.

local compliance

rules

global

compliance rules

public

private local

compliance

global

compliance

compliability

AM5

BM3

private process model

public process model

interaction model

local view

T2 T3

P2 P3

M2 M3

Fig. 1. Different levels of compliance rules in a cross-organizational setting

Consider Fig. 1: Compliance rules relevant for setting up and running cross-

organizational processes refer to different levels as known from interaction mod-

eling [5]. First, the global view of the interactions (i.e. messages exchanged) be-

tween the partners of a cross-organizational process (i.e., the interaction model)

provides the top level. Second, each partner defines a public model of its process

taking its local view on the interaction model into account. Accordingly, a local

view refers to the behavior of the interaction model from the viewpoint of a

particular partner. Note that public models must conform with the behavior of

the respective local view. Finally, each partner maintains its own private pro-

cess model, which not only comprises activities for exchanging messages with the

other partners, but also private activities not relevant for the interactions with

the partners; i.e., due to privacy, a partner usually does not reveal all details

about its private processes to the other partners. However, the private processes

must conform with the public process model. Semantic constraints in respect

to such private processes are denoted as local compliance rules. In turn, global

compliance rules are imposed on interaction models and public process models.

Altogether, the public parts of a cross-organizational process include the interac-

tion model, public process models, and global compliance rules. In turn, private

process models and local compliance rules constitute private parts.

As opposed to intra-organizational processes, in the context of cross-organiza-

tional processes we must consider three levels of compliance. First, we must deal

with local compliance rules that constrain private partner processes. Second,

we must support global compliance rules that constrain the public parts of a

cross-organizational process scenario. Third, interaction models must enable the

partners to model both public and private processes meeting the global compli-

ance rules. This requires interaction models being not in conflict with the set of

global compliance rules.

This paper focuses on the latter level of compliance and provides a novel

On Enabling Compliance of Cross-organizational Business Processes 3

correctness criterion, which we denote as compliability in the following. Compli-

ability refers to the ability of an interaction model to comply with a given set of

global compliance rules without knowing all details of the private and public pro-

cess models of the partners. We denote an interaction model as not compliabile,

if it conflicts with the given set of global compliance rules. In particular, we pre-

sent an approach enabling automated compliability checking of interaction mod-

els against a given set of imposed global compliance rules. Note that compliability

must be ensured before the partners specify their public and private process mod-

els. Therefore, our approach extends interaction models with additional control

flow structures and activities to approximate the not yet specified behavior of

partners. Furthermore, it merges and adapts the global compliance rules, before

checking compliability through the application of model checking techniques.

Note that this paper focuses on compliability checking of interaction models

at build time, but does not consider any other phase of the process life cycle

(e.g., execution and change time). Furthermore, we focus on compliance rules

related to control-flow and do not explicitly address data, resources, or time.

Finally, our approach requires from the partners to publish the set of activities

they use for specifying their public and private processes.

The remainder of this paper is structured as follows: Sect. 2 illustrates an

example from the healthcare domain. Sect. 3 provides algorithms for complia-

bility checking as the main contribution of this paper. Sect. 4 discusses related

work and Sect. 5 closes with a discussion and outlook.

2 Example

Figs. 2 and 3 depict an example of a cross-organizational process from the health-

care domain using the BPMN 2.0 standard. This process involves three partners:

gynecologist,laboratory, and hospital. In particular, Fig. 2 depicts the in-

teractions (i.e., messages exchanged) between these partners. In turn, Fig. 3

shows their public process models. Note that the public process model of the

hospital is simplified due to space limitations. Tab. 1 shows and classifies ex-

amples of compliance rules imposed on the cross-organizational process from

Figs. 2 and 3.

Gynecologist

Lab

Sample

Lab

Gynecologist

Result

Gynecologist

Hospital

Results of

blood test

Gynecologist

Hospital

Patient data

Gynecologist

Hospital

Patient data

Interaction

AND-split

Start event

XOR-split

AND-join

XOR-join

End event

Fig. 2. Interaction model of a healthcare scenario [14]

The interaction model from Fig. 2 is compliable with the set of global com-

pliance rules, which comprise r1and r2. This can be easily shown, since the

collaboration of the public processes (cf. Fig. 3) complies with r1and r2. In gen-

eral, however, public processes will not have been specified yet when verifying

compliability (cf. Fig. 1).

4 Knuplesch, Reichert, Fdhila, Rinderle-Ma

Gynecologist

Hospital

Laboratory

Analyse

sample Send results

Receive

sample

Examine

patient

Blood

test

Admit patient

into hospital

Send

blood sample Receive

results

Send

patient data

Inform

patient

Admit patient

into hospital Send

patient data

Forward

results

Receive

results

Receive

patient data

Monitor

patient

Inform

patient

Task

Start event End event

XOR-split

AND-split XOR-join

AND-join

Fig. 3. Public models of a healthcare scenario [14]

- Classification Compliance rule

r1Global compliance Rule After a blood test, the blood sample has to be analyzed.

r2Global compliance rule After the patient is admitted to the hospital, she must be monitored.

r3Local compliance rule of The patient must be informed about the results of a blood test.

gynecologist

Table 1. Examples of compliance rules

3 Compliability Checking

When setting up a cross-organizational process, compliability constitutes a seman-

tic correctness criterion to be considered when designing interaction models. It

ensures that interaction models do not conflict with the set of imposed global

compliance rules. Consequently, if an interaction model is not compliable, the in-

volved partners are unable to implement their public and private processes in

such a way that the overall cross-organizational process satisfies all imposed

compliance rules. As input our approach takes the interaction model I, the set

of global compliance rules GR expressed in terms of linear temporal logic (LTL),

the set of partners P, and for each partner p∈Pthe set of activities Apthat p

may execute.

Similar to approaches checking compliance of intra-organizational processes,

we apply model checking to ensure compliability. As opposed to these intra-

organizational approaches, however, we do not want to show that all possible

executions of a model comply with all compliance rules in GR, but that there

exists at least one execution satisfying all compliance rules in GR, and hence I

and GR do not conflict. Furthermore, we cannot directly take the interaction

model Ias input for model checking, but must consider all tasks that might

be additionally executed by partners. Thus, we cannot apply model checking

directly, but have to add preprocessing steps.

Consider Fig. 4: We utilize the knowledge about the set of activities Apto

enrich interaction model Gwith parts simulating the behavior of the partners

involved (cf. Alg. 1), and obtain an extended interaction model (EIM) as re-

sult (cf. Fig. 5).This enrichment is expressed through the following constructs:

On Enabling Compliance of Cross-organizational Business Processes 5

sequence (SEQ), parallelism (PAR), choice (CHC), and repeated loop (RPT).

Note that this does not require the interaction model to be well-structured.

counterexample

Activities of P1

interaction model

Activities of P1

activities of P1

extend

interaction

model

EIM

combine

rules

Activities of P1

global

compliance rule 1

model

checking

CGR

Compliability Checking

true

truefalse

false

extended interaction model

conjunction of

global compliance rules

Fig. 4. Process of compliability checking

Algorithm 1: Extend interaction model

1Function extendInteractionModel(I,P, Ap);

2begin

3P M ∶=EM P T Y ;

4foreach partner p∈Pdo

5foreach activity a∈Apdo

6P M ∶=CHC(a, P M);

7end

8end

9EIM ∶=P AR(I, RP T (P M));

10 end

11 Output: EIM Extend interaction model

Algorithm 2: Combine global compliance rules

1Function combineRules(GR);

2begin

3CGR ∶=true;

4foreach global compliance rule r∈GR do

5CGR ∶=CGR ∧r;

6end

7end

8Output: CGR the combined global compliance rules

Algorithm 3: Compliability checking

1Function checkCompliability(GR, I,P, Ap);

2begin

3EIM ∶=extendInteractionModel(I,P, Ap);

4CGR ∶=combineRules(GR);

5MC Result ∶=LT LM odelCecking(M, ¬CGR);

6compliability ∶=¬MC Result.propertyV alid;

7end

8Output: compliability the compliability of Iwith GR

Blood

test

Analyse

sample

Examine

patient

Interaction

model

... ... ...

Fig. 5. Extended interaction model EIM

Next, we construct the conjunction of all global compliance rules GCR in

Alg. 2. Finally, we apply LTL model checking to the extended interaction model

EIM and the negation of GCR in Alg. 3. In case the enriched model EIM is

compliable, at least one trace τis producible through EIM satisfying all global

compliance rules. Consequently, the negated conjunction of the global compli-

ance rules does not hold. For this case, explicit LTL model checking returns

false (and outputs τas counter-example), which means that compliabily holds.

Otherwise, all traces violate at least one of the global compliance rules, and

EIM satisfies the negated formula. In this case, model checking returns true,

but compliability is violated. Basically, our algorithm for compliability check-

ing applies model checking over the enriched interaction model EIM and the

negated conjunction of the global compliance rules, and then negates the result

(cf. Alg. 3 and Fig. 4).

Algorithm 1: Extend interaction model

1Function extendInteractionModel(I,P, Ap);

2begin

3P M ∶=EMP T Y ;

4foreach partner p∈Pdo

5foreach activity a∈Apdo

6P M ∶=CHC(a, P M );

7end

8end

9EIM ∶=P AR(I, RP T (P M));

10 end

11 Output: EIM Extend interaction model

Algorithm 2: Combine global compliance rules

1Function combineRules(GR);

2begin

3CGR ∶=true;

4foreach global compliance rule r∈GR do

5CGR ∶=CGR ∧r;

6end

7end

8Output: CGR the combined global compliance rules

Algorithm 3: Compliability checking

1Function checkCompliability(GR, I,P, Ap);

2begin

3EIM ∶=extendInteractionModel(I,P, Ap);

4CGR ∶=combineRules(GR);

5MC Result ∶=LT LModelCecking(EIM, ¬CGR);

6compliability ∶=¬MC Result.propertyV alid;

7end

8Output: compliability the compliability of Iwith GR

Algorithm 1: Extend interaction model

1Function extendInteractionModel(I,P, Ap);

2begin

3P M ∶=EMP T Y ;

4foreach partner p∈Pdo

5foreach activity a∈Apdo

6P M ∶=CHC(a, P M );

7end

8end

9EIM ∶=P AR(I, RP T (P M));

10 end

11 Output: EIM Extend interaction model

Algorithm 2: Combine global compliance rules

1Function combineRules(GR);

2begin

3CGR ∶=true;

4foreach global compliance rule r∈GR do

5CGR ∶=CGR ∧r;

6end

7end

8Output: CGR the combined global compliance rules

Algorithm 3: Compliability checking

1Function checkCompliability(GR, I,P, Ap);

2begin

3EIM ∶=extendInteractionModel(I,P, Ap);

4CGR ∶=combineRules(GR);

5MC Result ∶=LT LModelCecking(EIM, ¬CGR);

6compliability ∶=¬MC Result.propertyV alid;

7end

8Output: compliability the compliability of Iwith GR

We have demonstrated the feasibility of our approach by a proof-of-concept

prototype. We applied this prototype to different application scenarios including

the sketched healthcare example [14]. More precisely, the presented compliance

checking techniques have been implemented as plug-in of the Aristaflow BPM

6 Knuplesch, Reichert, Fdhila, Rinderle-Ma

original interaction model

automatically generated

extended interaction model

Fig. 6. Proof-of-concept prototype enabling compliability checking

Suite [3]. The upper part of Fig. 6 shows an automatically generated, extended

interaction model for compliability checking, while the lower part depicts the

original interaction model.

4 Related Work

In many domains, process execution is subject to compliance rules and restric-

tions that stem from laws, regulations, and guidelines (e.g. Basel or Sarbanes-

Oxley-Act) [23]. Existing approaches differ with respect to the process lifecycle

phase in which compliance is considered [7]. Compliance rules are often consid-

ered as restrictions to the order in which process activities may be executed.

In literature, there exist approaches formalizing these rules with temporal logic

[1, 10], patterns [6], or graphical notations [1, 18]. To check whether compliance

rules are fulfilled by a process model at build time, most approaches apply model

checking [1, 10, 19, 12]. Furthermore, business process compliance along the pro-

cess lifecycle is discussed in [20, 13].

Only little work exists, which deals with compliance of cross-organizational

processes [2, 11]. In particular, compliability of interaction models with a given

set of compliance rules has not been addressed yet.

Various other issues related to the correctness of cross-organizational pro-

cesses and complementing compliability have been addressed. For example, [4,

8] discuss whether private processes are compatible with the public ones. In

turn, [17, 15] introduce the notion of realizability of interaction models, i.e., to

check whether involved partners are able to model public and private processes

On Enabling Compliance of Cross-organizational Business Processes 7

compatible with a particular interaction model. [9] discusses changes and their

propagation in cross-organizational scenarios.

5 Discussion and Outlook

To ensure compliance of business processes with existing guidelines, standards,

and laws is crucial for both intra-organizational and cross-organizational set-

tings. However, existing proposals have only dealt with intra-organizational pro-

cesses so far [14]. This paper constitutes an important step towards enabling

compliance of cross-organizational business processes at different levels. In par-

ticular, we introduced the notion of compliability, i.e., the general ability of an

interaction model to not conflict with a given set of compliance rules indepen-

dent from the concrete process models of the partners.

However, compliability does not guarantee that there exists a compliant re-

alization of an interaction model; i.e., public and private process models that

comply with the global compliance rules. For example, consider the interac-

tion model from Fig. 7 and the global compliance rules r4and r5from Tab. 2.

As indicated by the process log being the output of compliability checking (cf.

Fig. 7), there exists no conflict between the model and r4and r5. Nevertheless,

the partners are not able to specify compliant private and public processes, be-

cause the laboratory is unable to determine, when the patient is notified. Thus,

laboratory can not determine when activity analyse sample may be started

without violating r5. This is caused by a missing interaction. In the example, it

is easy to enhance the interaction model with an additional interaction to en-

able the partners to specify compliant private and public processes (cf. Fig. 7).

Generally, compliability remains a necessary, but not sufficient precondition for

the ability of the partners to specify their public and private models in such

a way that the overall cross-organizational process satisfies the set of imposed

compliance rules.

Gynecologist

Lab

Sample

Lab

Gynecologist

Result

Blood test

Message sample

Notify patient

Analyse sample

Message result

Gynecologist

Gynecologist → Lab

Gynecologist

Lab

Lab → Gynecologist

Activity#Partner

Gynecologist

Lab

Sample

Lab

Gynecologist

Result

Gynecologist

Lab

Notification

done

Fig. 7. An example indicating the limitations of compliability

- Classification Compliance rule

r4Global compliance rule After blood sample is sent to laboratory, the patient has to be notified.

r5Global compliance rule The analysis must start after the notification of the patient, but before

results are sent.

Table 2. Examples of compliance rules

In future work, we will present a comprehensive formal theory for compliance

and related criteria (e.g., compliability) in cross-organizational processes. Fur-

ther, we will present additional algorithms for checking compliability and global

compliance as well as related semantic correctness criteria. Finally, we will con-

sider additional process perspectives (e.g. data, time, resources) in the context

of compliance and compliability checking.

8 Knuplesch, Reichert, Fdhila, Rinderle-Ma

References

1. Awad, A., Decker, G., Weske, M.: Efficient compliance checking using BPMN-Q

and temporal logic. In: BPM’08. pp. 326–341 (2008)

2. Berry, A., Milosevic, Z.: Extending choreography with business contract con-

straints. Int J Coop Inf Sys 14(2-3), 131–179 (2005)

3. Dadam, P., Reichert, M.: The ADEPT project: a decade of research and devel-

opment for robust and flexible process support. Computer Science-Research and

Development 23(2), 81–97 (2009)

4. Decker, G., Weske, M.: Behavioral consistency for B2B process integration. In:

CAiSE’07. pp. 81–95 (2007)

5. Decker, G., Weske, M.: Interaction-centric modeling of process choreographies. Inf

Sys 35(8) (2010)

6. Dwyer, M.B., Avrunin, G.S., Corbett, J.C.: Property specification patterns for

finite-state verification. In: FMSP’98 (1998)

7. El Kharbili, M., et al.: Business process compliance checking: Current state and

future challenges. In: MobIS’08. pp. 107–113 (2008)

8. Fdhila, W., Rouached, M., Godart, C.: Communications semantics for WS-BPEL

processes. In: ICWS’08 (2008)

9. Fdhila, W., Rinderle-Ma, S., Reichert, M.: Change propagation in collaborative

processes scenarios. In: CollaborateCom’12. pp. 452–461. IEEE Comp Press (2012)

10. Ghose, A.K., Koliadis, G.: Auditing business process compliance. In: ICSOC’07.

pp. 169–180 (2007)

11. Governatori, G., Milosevic, Z., Sadiq, S.: Compliance checking between business

processes and business contracts. In: EDOC’06. pp. 221–232 (2006)

12. Knuplesch, D., Ly, L.T., Rinderle-Ma, S., Pfeifer, H., Dadam, P.: On enabling

data-aware compliance checking of business process models. In: ER’2010 (2010)

13. Knuplesch, D., Reichert, M.: Ensuring business process compliance along the pro-

cess life cycle. Tech. Rep. 2011-06, University of Ulm (2011)

14. Knuplesch, D., et al.: Towards compliance of cross-organizational processes and

their changes - research challenges and state of research. In: BPM Workshops. pp.

649–661 (2013)

15. Knuplesch, D., Pryss, R., Reichert, M.: Data-aware interaction in distributed and

collaborative workflows: modeling, semantics, correctness. In: CollaborateCom’12.

pp. 223–232. IEEE Comp Press (2012)

16. Leitner, M., Mangler, J., Rinderle-Ma, S.: Definition and enactment of instance-

spanning process constraints. In: WISE’2012. pp. 652–658 (2012)

17. Lohmann, N., Wolf, K.: Realizability is controllability. Web Services and Formal

Methods pp. 110–127 (2010)

18. Ly, L.T., et al.: Design and verification of instantiable compliance rule graphs in

process-aware information systems. In: CAiSE’10. pp. 9–23 (2010)

19. Ly, L.T., et al.: Seaflows toolset–compliance verification made easy for process-

aware information systems. Inf Syst Evolution pp. 76–91 (2011)

20. Ly, L.T., et al.: On enabling integrated process compliance with semantic con-

straints in process management systems. Inf Sys Frontiers 14(2), 195–219 (2012)

21. Maggi, F., et al.: Monitoring business constraints with linear temporal logic: an

approach based on colored automata. In: BPM’11. pp. 132–147 (2011)

22. Ramezani, E., et al.: Separating compliance management and business process

management. In: BPM Workshops. pp. 459–464 (2012)

23. Sadiq, S., Governatori, G., Naimiri, K.: Modeling control objectives for business

process compliance. In: BPM’07. pp. 149–164 (2007)