Modeling the Resource Perspective of
Business Process Compliance Rules with the
Extended Compliance Rule Graph⋆
Franziska Semmelrodt, David Knuplesch, and Manfred Reichert
Institute of Databases and Information Systems,
Ulm University, Germany
firstname.familyname@uni-ulm.de
Abstract. Process-aware information systems must ensure compliance
of the business processes they implement with global compliance rules re-
lated to security constraints, domain-specific guidelines, standards, and
laws. Usually, respective compliance rules cover multiple process per-
spectives; i.e., they not only deal with the control flow perspective that
restricts the sequence in which the process activities shall be executed,
but also refer to other process perspectives like data, time, and resource.
Although there are various approaches for specifying compliance rules
(e.g., based on temporal logic and narrative patterns), only few languages
allow for the visual modeling of compliance rules. In turn, existing visual
languages focus on the control flow perspective, but treat the other pro-
cess perspectives as second class citizens. To remedy this drawback, this
paper presents an approach for the visual modeling of business process
compliance rules, including the resource perspective. The suitability of
this approach is evaluated in a case study that was performed by business
analysts in the healthcare domain.
1 Introduction
During the last decades many frameworks were proposed that aim to ensure the
correctness of business process models. While early works focused on structural
and behavioral model correctness (e.g., absence of deadlocks and livelocks) [1, 2],
the semantic correctness of process models with imposed compliance rules (i.e.,
business process compliance) has been subject to recent work [3, 4, 5]. Com-
pliance rules formally capture security constraints, domain-specific guidelines,
corporate standards, and laws in a machine-readable manner. Besides control
flow (i.e. sequence of activities), the resource perspective on business processes
constitutes another fundamental aspect of business process compliance and re-
spective rules (e.g. separation and binding of duties) [6, 7, 8].
For example, consider the compliance rules from Table 1. These refer to a
woman’s hospital [9, 10, 11, 12]. In particular, they highlight the need for covering
⋆This work was done within the research project C3Pro funded by the German Re-
search Foundation (DFG) under project number RE 1402/2-1.
2 Semmelrodt, Knuplesch, Reichert
C1 An X-ray examination for an inpatient must be ordered by a ward physician. In
this context, the same physician must fill in an order form [9].
C2 An X-ray checkup in the radiology department must be performed by a radiologist.
Prior to this, the informed consent of the patient must be checked by a medical
technical assistant (MTA) of the radiology department [9].
C3 Diagnoses must be made by ward physicians after receiving the X-ray diagnosis
and the X-ray images from the secretary of the radiology department [9].
C4 The central patient admission should admit a patient at the latest one week after
she was referred to the hospital by a gynecologist [10].
C5 At least one day before a surgery takes place, blood bottles must be ordered by
award physician of the surgery ward [10].
C6 Before a physician requests an informed consent (IC), the same physician must
inform the patient about risks [9, 10, 11, 12].
Table 1. Healthcare compliance rules
the resource perspective in the context of business process compliance rules. On
one hand, compliance rule C1 considers the resource perspective by requiring a
performer with role physician assigned 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). C6 constitutes another example of such
a binding of duties rule. In turn, the resource perspective related to compliance
rule C2 requires performers having different roles, but being assigned to the
same organizational unit. By contrast, C3 and C4 relate tasks to performers
with different roles and organizational units. Altogether, the rules from Table 1
emphasize the high relevance of the resource perspective in business process
compliance rules.
While there exist pattern-based approaches [13, 14] for modeling compliance
rules that also cover the resource perspective, the latter has been neglected in
the design of visual languages for modeling compliance rules so far. To remedy
this drawback, this paper provides an approach for the visual modeling of com-
pliance rules that covers the resource perspective as well. In particular, we will
show how the resource perspective can be captured with the extended Compli-
ance Rule Graph (eCRG) language. Further, we evaluate the applicability and
expressiveness of the eCRG language in respect to the resource perspective in
the context of a case study. In the latter we analyze various processes and related
compliance rules from a woman’s hospital.
Note that we have already introduced the fundamentals of the eCRG lan-
guage in previous work [15]. However, [15] only briefly deals with the resource
perspective of the eCRG as one out of multiple perspectives. By contrast, this
paper provides the first detailed presentation of those eCRG elements covering
the resource perspective. The remainder of this paper is structured as follows:
Section 2 introduces fundamentals required for understanding this work. Sec-
tion 3 discusses the eCRG based modeling of the resource perspective of busi-
ness process compliance rules along examples. In particular, we first introduce
a scenario referring to the organizational model of a woman’s hospital. Second,
we present the specific elements of the eCRG language for covering the resource
Modeling the Resource Perspective of Business Process Compliance Rules 3
perspective. Third, these eCRG elements are applied to model the rules from
Table 1. Finally, results from a case study (i.e. evaluation) we conducted in the
healthcare domain are discussed. Related work is presented in Section 4, while
Section 5 concludes the paper.
2 Backgrounds
This paper introduces the resource perspective of the extended Compliance Rule
Graph (eCRG) modeling language. Since the eCRG language is based on the
Compliance Rule Graph (CRG) language, we first introduce CRG and then
present the fundamentals of the eCRG language.
2.1 Compliance Rule Graph
The Compliance Rule Graph (CRG) language allows for the visual modeling
of compliance rules focusing on the control flow perspective (i.e. sequence flow)
of business processes [16, 17, 18]. More precisely, a CRG constitutes an acyclic
graph that consists of an antecedence pattern and one or several related conse-
quence patterns. Both patterns are modeled using occurrence and absence nodes,
which either express the occurrence or absence of events (e.g. related to the ex-
ecution of a particular task). Edges between such nodes indicate control flow
dependencies.
As illustrated in Fig. 1, a trace is considered as compliant with a CRG iff for
each match of the antecedence pattern there is at least one corresponding match
of every consequence pattern. Furthermore, a trace is considered as trivially
compliant iff there is no match of the antecedence pattern. For example, the
CRG from Fig. 2 expresses that for each B not preceded by an A, a D must
occur, which is not preceded by any C that, in turn, precedes the respective B.
C D C D
Antecedent pattern Consequence pattern
only match < E, D, F, G, B >
only match < D, F, C, E, B >
no match (A is before B!)
only match < C, F, B, G, E >
1st match < B, C, D, E, B >
2nd match< B, C, D, E, B >
< E, D, F, G, B >
< D, F, C, E, B > (C is after D!)
-
no match (missing D)
< B, C, D, E, B >
no match (C is before D!)
A B A B A B
< E, D, F, G, B >
< D, F, C, E, B >
< A, B, C, E, D >
< C, F, B, G, E >
< B, C, D, E, B >
compliant
compliant
trivially compliant
violation
violation
Antecedence
Occurrence
Antecedence
Absence
Consequence
Absence
Consequence
Occurrence
CRG
Example traces
Fig. 1. CRG example and semantics [15]
4 Semmelrodt, Knuplesch, Reichert
2.2 Extended Compliance Rule Graph
The CRG language focuses on the control flow perspective of compliance
rules, but factors out other perspectives. In [15], we introduced the extended
Compliance Rule Graph (eCRG) as a visual language for modeling compliance
rules that not only covers the control flow perspective, but provides integraed
support for the resource, data, and time perspectives as well.
To enable such a support of multiple perspectives, the eCRG language al-
lows for attachments in addition to nodes and connectors (i.e. edges). Respective
attachments represent constraints of the nodes or edges they are linked to. Fur-
thermore, an eCRG may contain instance nodes referring to particular objects,
which exist independently from the respective rule (e.g. Mr. Smith, postnatal
ward, physician). Note that instance nodes are neither part of the antecedence
nor the consequence pattern. Fig. 2 provides an overview of eCRG elements.
OccurenceAbsence
Antecedence Consequence
Task
Task Task
Task
Sequence Exclusion
Antecedence Connectors
Sequence Exclusion
Consequence Connectors
< value
> value
Antecedence
Consequence
Resource Conditions
Data
Object
Data
Object
Data Nodes
AntecedenceConsequence
Group Organizational
Unit
Staff
Member
Role
Group Organizational
Unit
Staff
Member
Role
Resource Nodes
Antecedence
Relation Connector
Data Container
Data Container
Requests
Request
Particular
Data Nodes
Quality
Managers
Radiology
Department
Computer
Scientist
Mr X
Occurence
Anteced.
Point-in-
Time Nodes
Antecedence
Consequence
Time
Conditions
>2d
>2d
Antecedence. Time
Distance Connector
Consequece Time
Distance Connector
Absence
March 23th
2013
Particular
Point in TimeConsequ.
Extended Compliance Rule Language (eCRG)
Process Perspective Time Perspective
Resource Perspective Data Perspective
< value
> value
Antecedence
Consequence
Data Conditions
Antecedence
Data Flow Connector
Consequence
Data Flow Connector
AntecedenceConsequence
Particular
Resources
Antecedence
Performing Connector
Consequence
Performing Connector
Consequence
Relation Connector
Alternative
Alternative
Fig. 2. Elements of the eCRG language
Control flow perspective. Modeling the control flow perspective of com-
pliance rules is supported through four kinds of task nodes, i.e., antecedence
occurrence, antecedence absence, consequence occurrence, and consequence ab-
sence task nodes. Based on these nodes it can be expressed whether or not
particular tasks shall be executed. In addition, two kinds of sequence flow con-
nectors are provided that allow constraining the execution sequence of tasks.
Note that the absence of a sequence flow indicates parallel flow. Furthermore,
Modeling the Resource Perspective of Business Process Compliance Rules 5
exclusive connectors express mutual exclusion of the tasks they refer to. Finally,
alternative connectors express that at least one of the connected tasks must oc-
cur [15].
Time perspective. The eCRG language offers the following elements for
modeling the time perspective: Point-in-time nodes,time condition attachments,
and time distance connectors (cf. Fig. 2). Like task nodes, point-in-time nodes
can be either antecedence occurrence, antecedence absence, consequence occur-
rence, or consequence absence nodes. Furthermore, a particular date or point in
time (e.g. 26th October 2014) can be expressed using instance nodes. Time con-
ditions may be attached to task nodes and sequence flow connectors to constrain
the duration of a task or the time distance between task nodes and point-in-time
nodes. Finally, time distance connectors allow constraining the time distance
without implying a particular sequence.
Data perspective. Data container nodes and data object nodes support the
modeling of the data perspective in eCRGs. Furthermore, data flow connectors
and data conditions are provided. Data container nodes refer to process data
elements or global data stores. By contrast, data object nodes refer to particular
data values and data object instances. Both kinds of data nodes may be part of
the antecedence or consequence pattern, or represent a particular data container
and data object respectively. Data flow connectors define which process tasks
read or write which data objects or data containers. To constrain data contain-
ers, data objects and data flow, data conditions may be attached. Finally, data
relation connectors may either be used to compare different data objects or to
constrain the value of data containers at particular points in time.
Resource perspective. For modeling the resource perspective of compli-
ance rules resource nodes are provided, i.e., staff member, role, group, and orga-
nizational unit nodes. Similar to task nodes, resource nodes may be part of the
antecedence or consequence pattern. Alternatively, they may represent a par-
ticular resource instance (e.g. Mr. Smith, postnatal ward, physician). To spec-
ify dependencies among resources, resource relation connectors are provided. In
turn, resource conditions constrain a particular resource node. Finally, the per-
forming relation indicates the performer of a task node. This paper focuses on
the resource perspective of process compliance rules. Respective elements are
therefore described in more detail in Section 3.
3 The Resource Perspective of Compliance Rules
After having introduced the fundamentals of the eCRG and CRG languages, we
discuss how the resource perspective of business process compliance rules can
be modeled when using eCRG. For this purpose, we first provide an examplary
application scenario from a woman’s hospital. This scenario is then used to
illustrate the resource perspective of the eCRG language.
6 Semmelrodt, Knuplesch, Reichert
3.1 Scenario
This section illustrates the resource perspective along a healthcare scenario,
which refers to clinical processes from the woman’s hospital. Fig. 3 illustrates
our resource meta-model. It comprises the entity types organizational unit,group,
staff member, and role as well as the relation types between them. However, our
approach is not restricted to the entity and relation types from Fig. 3. For exam-
ple, our scenario refers to additional relation types and properties (e.g. relation
type supervisor, property ’is surgery ward’) as well.
Fig. 4 shows the organizational units relevant in the context of our scenario.
On one hand, these units are subordinated ones of the university hospital in-
cluding the woman’s hospital with its wards (e.g. postnatal ward 1/2) and other
units (e.g. admission) as well as the radiology department. On the other hand,
Fig. 4 further refers to external medical practices of a gynecologist and a general
practitioner.
organizational
unit
staff member
group
role
has role / is
assigned to
subordinated
member of
related
Fig. 3. Meta-model
woman‘s hospital
general
practitioner radiology department
gynecologist
ward
postnatal
ward 1 ward 1
ward 2
ward 3
postnatal
ward 2
intensive
care unit
function area
surgery
department
laboratory
department
university hospital
admission
Fig. 4. Organizational units
Fig. 5 provides the assignment relation (cf. Fig. 3) of an anonymized extract
of the staff database relevant in our scenario. The roles of the respective actors
are shown in Fig. 6. For example, Mrs. A,Mr. B, and Mr. C are assigned to the
radiology department, while Mrs. E is assigned to wards 1 and 2(cf. Fig. 5). In
turn, Mr. B and Mrs. E are both physicians, while Mrs. A has role MTA (i.e.,
medical technical assistant).
To complement our scenario, Fig. 7 specifies the relation supervisor. For
instance, Mr. B is supervisor of Mrs. A. In turn, Fig. 8 provides two attributes
of the aforementioned wards; i.e., capacities and information on whether or not
the ward is a surgery ward.
Finally, Fig. 9 shows a possible execution log of a healthcare process from
our scenario [9].
Modeling the Resource Perspective of Business Process Compliance Rules 7
surgery
department
laboratory
department
postnatal
ward 1
postnatal
ward 2
intensive
care unit
ward 1
ward 2
ward 3
…
Mrs. A
X
Mr. B
X
Mr. C
X
…
Mr. D
X
…
Mrs. E
X X
Mr. F
X X
Mrs. G
X X
Mr. H
X X
…
Mr. I
X
…
assigned
gynecologist
general practitioner
university hospital
woman's hospital
radiology
department
admission
function
area
ward
Fig. 5. Staff members and relation assignment
3.2 Resource Perspective in Detail
As outlined in Sect. 2, the resource perspective of the eCRG language provides
elements referring to organizational units,groups,roles, and staff members. In
has role
/ is …
physician
nurse
secretary
MTA
…
…
Mrs. A X
Mrs. B X
Mr. C X
…
Mr. D X
…
Mrs. E X
Mr. F X
Mr. G X
Mr. H X
…
Mr. I X
…
Fig. 6. Staff members and their roles
8 Semmelrodt, Knuplesch, Reichert
is
supervisor
of
…
Mrs. A
Mr. B
Mr. C
…
is
supervisor
of
…
Mrs. E
Mr. F
Mrs. G
Mr. H
…
…
…
Mrs. A Mrs. E
X
X
Mr. B
X
X
X
Mr. F
Mr. C Mrs. G
…
Mr. H
…
Fig. 7. Relation supervisor
attributes
postnatal
ward 1
postnatal
ward 2
intensive
care unit
ward 1
ward 2
ward 3
…
is surgery ward X X
capcity 20 20 15 30 30 20
…
ward
Fig. 8. Ward attributes
step date time activity performer data/documents
1 05.02.2009 09:20 examine patient Mrs. E
2 05.02.2009 09:40 order X-ray Mrs. E
3 05.02.2009 09:45 fill request form Mrs. E request form
4 05.02.2009 09:50 inform patient Mrs. E
5 05.02.2009 09:55 answer questions Mrs. E
6 05.02.2009 09:58 request IC Mrs. E signed IC
7 05.02.2009 10:10 transfer patient Mrs. G
8 05.02.2009 10:12 transmit IC Mr. H signed IC
9 05.02.2009 10:45 check IC Mrs. A signed IC
10 05.02.2009 10:50 prepare patient Mrs. A
11 05.02.2009 11:05 perfom X-ray Mr. B X-ray image
12 05.02.2009 11:20 transfer patient Mrs. G
13 05.02.2009 11:35 document result Mr. C X-ray diagnosis
14 05.02.2009 11:45 transmit X-ray image & X-ray diagnosis Mr. C X-ray image & diagnosis
15 05.02.2009 14:10 make diagnosis Mrs. E X-ray image & diagnosis
16 05.02.2009 14:15 prescribe therapy Mrs. E
17 05.02.2009 14:40 document diagnosis and therapy Mr H
Fig. 9. Execution log of radiology process
turn, these may either be part of the antecedence pattern (solid) or consequence
pattern (dashed), or be a particular instance (bold) (cf. Fig 2). The performing
relation connector allows using these elements in order to specify the perform-
ers of both antecedence and consequence task nodes in detail. Accordingly, the
performing relation connector can either be antecedence (solid) or consequence
(dashed). Fig. 10 illustrates the application of the performing relation connector
Modeling the Resource Perspective of Business Process Compliance Rules 9
and its semantics in detail. In Fig. 10a, the antecedence performing relation is
used to connect antecedence tasks with an antecedence staff member. In turn,
Fig. 10b shows a consequence performing relation connecting an antecedence
task with an antecedence staff member. In Fig. 10c, two consequence performing
relations are used to connect both antecedence tasks with a consequence staff
member. Note that the eCRGs from Figs. 10b and 10c have the same meaning.
Fig. 10d shows how a consequence task can be connected to an antecedence
task by using a consequence performing relation, while Fig. 10e shows how the
consequence performing relation connects two consequence tasks with the same
consequence staff member. Note that antecedence performing relation connectors
must not be connected to any element of the consequence pattern.
a
order
X-ray
b
fill
request
form
order
X-ray
fill
request
form
fill
request
form
order
X-ray
fill
request
form
order
X-ray
cde
order
X-ray
fill
request
form
WHENEVER task order X-ray
occurs before task fill request
form, and both tasks are
performed by the same staff
member, THEN ...
WHENEVER task order X-ray
occurs before task fill request
form THEN fill request must be
performed by the same actor,
who performed order X-ray.
WHENEVER task order X-ray
occurs before task fill request
form THEN both tasks must
be performed by the same
staff member.
WHENEVER task order X-ray
occurs THEN task fill request
form must occur afterwards
and be performed by the
performer of order X-ray.
WHENEVER … THEN task
order X-ray must occur before
task fill request form and both
tasks must be performed by the
same staff member.
Fig. 10. Performing relation
As indicated by the examples from Table 1, compliance rules refer to rela-
tions between different elements of the resource perspective. The resource rela-
tion connector can specify relations between resources in the antecedence as well
as the consequence pattern. Accordingly, each resource relation connector is ei-
ther part of the antecedence pattern (solid) or the consequence pattern (dashed).
The corresponding resource relation can be expressed by attaching rectangles in
case of antecedence relation connectors and ovals in case of consequence rela-
tion connectors. Fig. 11 shows the use of the resource relation connector and its
semantics in more detail. Fig. 11a uses antecedence resource relations to con-
nect antecedence staff members with an antecedence organizational unit. In turn,
Fig. 11b illustrates an antecedence and a consequence resource relation both con-
necting an antecedence staff member with an antecedence organizational unit.
Fig. 11c comprises a consequence resource relation that connects antecedence
and consequence staff members, while an antecedence relation connects the same
antecedence staff member with resource physician. In turn, Fig. 11d applys a con-
sequence relation connector to refer from the staff member to resource physician.
Finally, Figs. 11e and 11f show how the performing relation can implicitly incor-
porate the assignment relation and the role relation of our meta-model in some
special cases (cf. Fig. 3). Note that antecedence resource relation connectors can
only connect elements of the antecedence pattern, but must not be connected to
any consequence resource.
10 Semmelrodt, Knuplesch, Reichert
a b
check IC
perform
X-ray
c
order
X-ray
fill
request
form
order
X-ray
fill
request
form
supervisor
of
e
order
X-ray
fill
request
form
check IC
perform
X-ray
d
is
is
WHENEVER task order X-ray
occurs before task fill request
form, and both performers are
assigned to the same
organizational unit, THEN ...
WHENEVER task order X-ray
occurs before task fill request
form THEN the performer of
fill request form must be
assigned to the same orga-
nizational unit as the performer
of task order X-ray.
WHENEVER task perform
X-ray is performed by a
physician THEN task check
IC must occur before and be
performed by a subordinated
staff member.
WHENEVER task perform X-
ray is performed THEN its
performer must be a
physician, and task check IC
must occur before and be
performed by a subordinated
staff member.
WHENEVER task order X-ray
occurs before task fill request
and both performers are
assigned to the same
organizational unit THEN …
WHENEVER task perform X-
ray is performed THEN its
performer must be a physician.
perform
X-ray
f
assigned
assigned
assigned assigned
physician
supervisor
of
physician
physician
Fig. 11. Resource relations
Finally, resource conditions may be attached to the elements of the resource
perspective. Resource conditions may either be part of the antecedence (rect-
angle) or consequence pattern (oval). Their semantics is illustrated in Fig. 12.
In particular, Fig. 12a shows the use of an antecedence condition constrain-
ing an antecedence organizational unit. In turn, Fig. 12b applies a consequence
condition to the same antecedence organizational unit, while in Fig. 12c a con-
sequence organizational unit is used. Despite this difference, Figs. 12b and 12c
have the same meaning. The meaning of Fig. 12d changes, when turning the an-
tecedence organizational unit into a consequence organizational unit. Note that
antecedence resource conditions may only be attached to antecedence resource
nodes, but not to elements of the consequence pattern.
a
order
blood
bottles
surgery
assigned
WHENEVER task order
blood bottles occurs before
task surgery, and its
performer is assigned to an
organizational unit being a
surgery ward, THEN …
WHENEVER task order
blood bottles occurs before
task surgery, and its
performer is assigned to a
organizational unit, THEN this
unit must be a surgery ward.
WHENEVER task order
blood bottles occurs before
task surgery THEN the staff
member perfoming order
blood bottles must be
assigned to a surgery ward.
WHENEVER both tasks perform X-ray and
prepare patient are performed before task
surgery and both performers are assigned to
the same organizational unit THEN this
organizational unit must be a surgery ward.
surgery ward
b
order
blood
bottles
surgery
assigned
surgery ward
c
order
blood
bottles
surgery
d
order
blood
bottles
prepare
patient surgery
assigned
assigned
surgery ward
assigned
surgery ward
Fig. 12. Resource conditions
Modeling the Resource Perspective of Business Process Compliance Rules 11
A simple formal specification of the eCRG language, including the resource
perspective, is provided in [19].
Compliance rule C1
perform
X-ray
check IC
IC
refer
patient
administrative
admission
< 1 week
surgery
order
blood
bottles
< 1 day
request
IC
inform
patient
IC
order
X-ray
request form
is assigned
fill
request form
make
diagnosis
transmit
X-ray image &
X-ray diagnosis
X-ray image and
X-ray diagnosis
ward
physician
is
physician
gynecologist
assigned
admission
assigned
is
physician
radiology
department
assigned
is
MTA
assigned
is
physician
is surgery
ward
assigned
is assigned
ward
physician
is
secretary
radiology
department
assigned
is
physician
ward
Compliance rule C2
Compliance rule C3
Compliance rule C4
Compliance rule C5
Compliance rule C6
Fig. 13. Healthcare compliance rules
In Fig. 13, the six compliance rules from Table 1 are visualized using the
eCRG language, including its elements for capturing the resource perspective.
Note that the execution log from Fig. 9 complies with each of these eCRGs.
Trivially, the log complies with rules C4 and C5, since it does not contain any
of the tasks refer patient and surgery; i.e., there is no match of the antecedence
patterns of rules C4 and C5. In turn, there exist matches for the antecedence
patterns of rules C1, C2, C3, and C6 as well as the corresponding consequence
12 Semmelrodt, Knuplesch, Reichert
patterns. Step 2(i.e. order X-ray) matches with the antecedence pattern of C1,
while the following Step 3matches with the consequence pattern of C1 since
it refers to task fill request form and is performed by the same staff member
Mrs. E. As required by the consequence pattern, Mrs. E has role physician and
is assigned to organizational unit ward. The antecedence pattern of C2 matches
with Step 11 (i.e. perform X-ray). As specified in the consequence pattern of C2,
the performer of Step 11 (i.e. Mr. B) is assigned to the radiology department.
Further, this performer has role physician. The consequence pattern is com-
pleted by Step 9(i.e. check IC), which is performed by Mrs. A with role medical
technical assistant (MTA). Furthermore, Mrs. A is assigned to unit radiology
department. Step 15 (i.e. make diagnosis) triggers C3; i.e., it matches with the
antecedence pattern of C3. As required by the consequence pattern of C3, the
performer (i.e. Mrs. E) of Step 15 has role physician and is assigned to the unit
ward. Furthermore, Step 15 is preceded by Step 14 (i.e. transmit X-ray image
& X-ray diagnosis), which is performed by Mr. C. The latter is a secretary of
the radiology department. Finally, the antecedence pattern of C6 matches with
Step 6(i.e. request IC). Step 4(i.e. inform patient) satisfies the corresponding
consequence pattern. Hence it is performed by the same staff member (i.e. Mrs.
E), who also possesses role physician.
3.3 Evaluation
To evaluate the suitability of the eCRG language with respect to the modeling of
the resource perspective, we conducted a case study in the healthcare domain. In
particular, business analysts (i.e., non-IT-specialists) analyzed six process model
collections stemming from the woman’s hospital [11, 12, 10, 9]. Altogether, they
identified 30 compliance rules and modeled them using the eCRG language. Out
of these 30 compliance rules, 17 rules refer to the resource perspective. For these
17 compliance rules, the business analysts were able to capture the resource
perspective with eCRG; i.e., the eCRG language allowed them to capture all rel-
evant aspects of the resource perspective. Besides this, they revealed drawbacks
regarding the modeling of the control flow and time perspectives. In particular,
the business analysts emphasized the missing support for periodic time events
and the missing ability to refine tasks. Table 2 summarizes study results.
Perspective Status
Control flow perspective black box character of Tasks
Data perspective ✓
Resource perspective ✓
Time perspective periodical points in time
Table 2. Evaluation of the eCRG language
Modeling the Resource Perspective of Business Process Compliance Rules 13
4 Related Work
Modeling issues related to the resource perspective of business processes are
addressed in [20]. In turn, [21, 22, 23, 24, 25, 26] discuss the interaction, time,
and data perspectives of business processes.
The integration of business process compliance throughout the entire pro-
cess lifecycle is investigated in [7, 18, 27]; [28] examines compliance issues in the
context of cross-organizational processes developing a logic-based formalism for
describing both the semantics of normative specifications and compliance check-
ing procedures. In turn, [29] introduces a semantic layer that interprets process
instances according to an independently designed set of internal controls.
To verify whether compliance rules are fulfilled by process models at design
time, many approaches apply model checking [4, 5, 30, 31, 32]; some of them
address the data and time perspectives as well. [13] uses alignments to detect
compliance violations in process logs. Other approaches for verifying compliance
apply the notion of semantic congruence [33], use petri-nets [34], or rely on
mixed-integer programming [35]. In turn, [36, 37, 38] deal with the compliance
of interaction models and cross-organizational process collaborations. Finally,
there exist visual approaches for compliance rule modeling [4, 16, 31, 39, 40].
As opposed to eCRG, they focus on the control flow and - partly - the data
perspective, but factor out the resource perspective.
5 Summary and Outlook
While compliance rule modeling has been addressed by a plethora of approaches,
the visual modeling of the data, time, and resource perspectives has not been
sufficiently addressed yet [6, 13, 14]. To remedy this drawback, this paper intro-
duces an extension of the compliance rule graph (CRG) language [16, 17, 18] in
order to cover the resource perspective in visual compliance rules as well. Each
language element has been presented in detail and illustrated along an exam-
ple. In turn, all examples were gathered in a healthcare case study that was
performed by business analysts. This case study further contributes to evaluate
our approach, proving its suitability for modeling the resource perspective of
business process compliance rules.
To enable tool support for both the modeling and verification of compliance
rules, the semantics of the introduced visual compliance rule language has been
formalized in a technical report [19].
In a next step, we will consider the feedback we gathered in the case study
in order to enhance the visual compliance rule language. Furthermore, we are
developing techniques for verifying the compliance of business processes with
imposed multi-perspective compliance rules during runtime. However, our overall
aim is to ensure multi-perspective compliance for all phases of the process life
cycle, including a priori compliance checking at design time as well as a posteriori
compliance checking after process execution. Finally, we will consider compliance
checking in the context of process changes.
14 Semmelrodt, Knuplesch, Reichert
References
1. van der Aalst, W.M.P.: Verification of workflow nets. Application and Theory of
Petri Nets (1997) 407–426
2. Reichert, M., Dadam, P.: ADEPTflex – supporting dynamic changes of workflows
without losing control. Intelligent Inf Sys 10(2) (1998) 93–129
3. Governatori, G., Milosevic, Z., Sadiq, S.: Compliance checking between business
processes and business contracts. In: EDOC’06. (2006) 221–232
4. Awad, A., Weidlich, M., Weske, M.: Specification, verification and explanation of
violation for data aware compliance rules. In: ICSOC’09. (2009) 500–515
5. 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. Volume
6412 of LNCS., Springer (2010) 332–346
6. Cabanillas, C., Resinas, M., Ruiz-Cortés, A.: Hints on how to face business process
compliance. In: JISBD’10. (2010)
7. Ramezani, E., Fahland, D., van der Werf, J.M., Mattheis, P.: Separating com-
pliance management and business process management. In: BPM Workshops,
Springer (2012) 459–464
8. Schaad, A., Spadone, P., Weichsel, H.: A case study of separation of duty properties
in the context of the austrian "elaw" process. In: SAC’05, ACM (2005) 1328–1332
9. Konyen, I., Schultheiß, B., Reichert, M.: Prozessentwurf für den Ablauf einer
radiologischen Untersuchung. Technical Report DBIS-15, University of Ulm (1996)
10. Schultheiß, B., Meyer, J., Mangold, R., Zemmler, T., Reichert, M., Dadam, P.,
Kreienberg, R.: Prozessentwurf am Beispiel eines Ablaufs aus dem OP-Bereich -
Ergebnisse einer Analyse an der Universitätsfrauenklinik Ulm. Technical Report
DBIS-6, University of Ulm (1996)
11. Konyen, I., Schultheiß, B., Reichert, M.: Prozessentwurf eines Ablaufs im Labor.
Technical Report DBIS-16, University of Ulm (1996)
12. Schultheiß, B., Meyer, J., Mangold, R., Zemmler, T., Reichert, M., Dadam, P.,
Kreienberg, R.: Prozessentwurf für den Ablauf einer ambulanten Chemotherapie.
Technical Report DBIS-7, University of Ulm (1996)
13. Ramezani, E., Fahland, D., van der Aalst, W.M.: Diagnostic information in com-
pliance checking. In: BPM’12, Springer (2012)
14. Turetken, O., Elgammal, A., van den Heuvel, W.J., Papazoglou, M.: Capturing
compliance requirements: A pattern-based approach. IEEE Soft (2012) 29–36
15. Knuplesch, D., Reichert, M., Ly, L.T., Kumar, A., Rinderle-Ma, S.: Visual modeling
of business process compliance rules with the support of multiple perspectives. In:
ER’13. Volume 8217 of LNCS., Springer (2013) 106–120
16. Ly, L.T., Rinderle-Ma, S., Dadam, P.: Design and verification of instantiable com-
pliance rule graphs in process-aware information systems. In: CAiSE’10. (2010)
9–23
17. Ly, L.T., Rinderle-Ma, S., Knuplesch, D., Dadam, P.: Monitoring business process
compliance using compliance rule graphs. In: CoopIS’11. (2011) 82–99
18. Knuplesch, D., Reichert, M.: Ensuring business process compliance along the pro-
cess life cycle. Technical Report 2011-06, Ulm University (2011)
19. Knuplesch, D., Reichert, M., Ly, L.T., Kumar, A., Rinderle-Ma, S.: On the formal
semantics of the extended compliance rule graph. Technical Report 2013-05, Ulm
University (2013)
20. Russell, N., van der Aalst, W.M.P., ter Hofstede, A.H.M., Edmond, D.: Workflow
resource patterns: Identification, representation and tool support. In: CAiSE’05,
Springer (2005) 216–232
Modeling the Resource Perspective of Business Process Compliance Rules 15
21. Kumar, A., Wang, J.: A framework for document-driven workflow systems. In:
Int’l Handbook on Business Process Management. Springer (2010) 419–440
22. Eder, J., Tahamtan, A.: Temporal conformance of federated choreographies. In:
DEXA’08. (2008) 668–675
23. Lanz, A., Weber, B., Reichert, M.: Time patterns for process-aware information
systems. Requirements Engineering (2012)
24. Decker, G., Weske, M.: Interaction-centric modeling of process choreographies. Inf
Sys 35(8) (2010)
25. Barros, A., Dumas, M., ter Hofstede, A.: Service interaction patterns. In: BPM’05.
(2005) 302–318
26. Knuplesch, D., Pryss, R., Reichert, M.: Data-aware interaction in distributed and
collaborative workflows: Modeling, semantics, correctness. In: CollaborateCom’12,
IEEE (2012) 223–232
27. Ly, L.T., Rinderle-Ma, S., Göser, K., Dadam, P.: On enabling integrated process
compliance with semantic constraints in process management systems. Inf Sys
Front 14(2) (2012) 195–219
28. Governatori, G., Sadiq, S.: The journey to business process compliance. In: Hand-
book of Research on BPM. IGI Global (2009) 426–454
29. Namiri, K., Stojanovic, N.: Pattern-Based design and validation of business process
compliance. In: CoopIS’07. (2007) 59–76
30. Ghose, A.K., Koliadis, G.: Auditing business process compliance. In: ICSOC’07.
(2007) 169–180
31. Liu, Y., Müller, S., Xu, K.: A static compliance-checking framework for business
process models. IBM Systems Journal 46(2) (2007) 335–261
32. Kokash, N., Krause, C., de Vink, E.: Time and data aware analysis of graphical
service models. In: SEFM’10. (2010)
33. Höhn, S.: Model-based reasoning on the achievement of business goals. In: SAC
’09, New York, NY, USA, ACM (2009) 1589–1593
34. Accorsi, R., Lowis, L., Sato, Y.: Automated certification for compliant cloud-based
business processes. Business & Inf Sys Engineering 3(3) (2011) 145–154
35. Kumar, A., Yao, W., Chu, C.: Flexible process compliance with semantic con-
straints using mixed-integer programming. INFORMS J on Comp (2012)
36. Knuplesch, D., Reichert, M., Mangler, J., Rinderle-Ma, S., Fdhila, W.: Towards
compliance of cross-organizational processes and their changes. In: Proc SBP’12.
Volume 132 of LNBIP., Springer (2012)
37. Knuplesch, D., Reichert, M., Fdhila, W., Rinderle-Ma, S.: On enabling compliance
of cross-organizational business processes. In: BPM’13. Volume 8094 of LNCS.,
Springer (2013) 146–154
38. Knuplesch, D., Reichert, M., Pryss, R., Fdhila, W., Rinderle-Ma, S.: Ensuring
compliance of distributed and collaborative workflows. In: CollaborateCom’13,
IEEE (2013) 133–142
39. Awad, A., Weidlich, M., Weske, M.: Visually specifying compliance rules and exp-
laining their violations for business processes. Vis Lang Comp 22(1) (2011) 30–55
40. Feja, S., Speck, A., Witt, S., Schulz, M.: Checkable graphical business process
representation. In: ADBIS’11, Springer (2011) 176–189
