Evaluation of Compliance Requirements for collaborative business process with process mining and a model of generic compliance controls

In last decades, business processes (BPs) have gained attention in organizations including efforts to model, register and evaluate their activities, events and decisions taken by participants. Their daily operation leaves a trail of BPs execution, which in collaborative BPs that are carried out by collaborating organizations, are distributed within them. Compliance requirements add specific control elements to process execution, e.g. sectorial and/or country regulations to be fulfilled, enforcing order of interaction messages or duration of activities, or security checks on roles and permissions. As the amount of available data in organizations grows everyday, using execution data to detect compliance violations and their causes, can help them to take corrective actions for improving their processes and comply to applying rules. In particular, compliance requirements violations can be detected in a post mortem way by using process mining to evaluate BPs execution data against the specified compliance requirements for the process, which in domains such as e-Government, is of utmost importance. In previous work we proposed a BP compliance Requirements Model (BPCRM) for collaborative BPs, defining generic compliance controls that can be leveraged to specify compliance requirements over BPs, which are used as input to assess compliance violations with process mining. BPCRM can be seen as a catalogue of predefined compliance rules or patterns. This paper presents a revised and extended version of BPCRM, including the complete set of defined controls as well as extending the example of application and showing evaluation results in our ProM plug-in, which enable the description of the complete approach.


Introduction
Business processes (BPs) [1], [2], [3] are present in most organizations business operation, mainly implicit in manual procedures and Information Systems (IS), without a clear definition and specification outside them. Nowadays BPs are of utmost importance for organizations, as over the last two decades their automation have been accelerated by the introduction of new technologies to better support their operation. Business Process Management Systems (BPMS) allow specifying BP models that will be enacted within a process engine enforcing the control flow execution as defined by the model. The Business Process Model and Notation (BPMN 2.0) [4] language is the one preferred nowadays by most BPMS for modeling and enacting BPs.
Compliance management involves ensuring that organizations are compliant with established regulations e.g. domain and/or country regulations [5], and involves several activities [6] [7]. In particular, compliance control involves assessing the fulfillment of such requirements and acting accordingly. Being compliant with regulations and laws is mandatory in some domains such as e-government environments [8] where most BPs are collaborative involving several participants from different organizations, each one with their own technological infrastructure [9]. Gathering execution data from different BPMS and data sources in order to reconstruct BPs execution can be a challenging task, that must be addressed in order to be able to analyze execution data in an integrated manner [10].
Process Mining [11] is a discipline within Data Science [11,12] and Process Science [11] that can be seen as a bridge between those areas, and has been developed in the last two decades to provide techniques, algorithms and tools to discover information from process execution data, as data mining does.
These data are registered within traditional organization's systems or BPMS, where events that occur within each process instance (case) are registered within traces in a so call event log. Process mining provides three main approaches [11]: i) discovering BP models from event logs i.e. generating process models based on execution process data; ii) process conformance i.e. checking the real execution in event logs against BP models; and iii) enhancing BP models with extra information such as roles and resources involved in the process execution.
Organizations are facing nowadays several challenges regarding not only they daily operation and technological support infrastructure, but also the large amount of data they are continuously gathering from different sources. A key challenge is how to seize all these data and get information and value from it to improve their business. This involves being able to process it in an integrated manner to get a complete picture of their processes and organizational data, they partners, suppliers and every variable that could impact in their results. Compliance requirements control can be performed at different stages i.e. design time, execution and post mortem [13]. Applying post mortem assessment using process mining to detect compliance violations and their causes, could help organizations to take corrective actions improving their processes, based on evidence.
In previous works [14] we have presented the framework Process and Data sCience for oRganIzational improvEment (PRICED), which aims to be a guide for organizations to be able to gather their data together from different and heterogeneous sources and analyze it in an integrated manner. The framework defines a lifecycle with three phases of Enactment, Data and Mining, with activities to guide the process and organizational data analysis (i.e. from collaborative and orchestration BPs and corresponding organizational data). It includes definitions and approaches to deal with specific aspects such as data integration and quality, compliance rules, process and data mining, business data analysis, among others.
Regarding BPs compliance, in [8] we have presented a language to specify compliance requirements over BPs, the Compliance Requirements Modeling Language (CRML), its metamodel and graphical notation, the high level view of the Dimensions and Factors comprising the BPCRM, and initial examples of the specification for a few Controls, based on a previous conceptualization made in [15]. This paper presents an extension of [16] where we presented the complete BP Compliance Requirements Model (BPCRM) which is part of the PRICED framework, and provides generic compliance controls (or patterns) for collaborative BPs. The BPCRM definition includes the complete set of controls we have defined for each factor and dimension, that apply to both the collaboration and choreography views of collaborative BPs, widely extending the initial presentation. These controls can be instantiated over each process to specify particular compliance requirements, and used as input to evaluate violations with process mining. In this sense, the proposed model can be seen as a catalogue of predefined and generic compliance controls (patterns), which can be used for two purposes: the specification of compliance requirements and the validation of compliance rules.
The contributions in this extended paper are twofold: i) we have specified 47 controls defined in the model with the extended Compliance Rule Graph (eCRG) [17] (only three of them were specified in [16]: "M cooccurs N after I", "A reads DO contained in M" and "B reads DO with value V written by A"), which provides a visual language to help communicating and understanding the controls (see Section 3), and ii) we have extended the example of application adding several control specification examples over the Passport Application BP for both the choreography and the collaboration view, showing the evaluation results in our ProM plug-in for the complete approach.
The rest of the document is organized as follows: in Section 2 we introduce a running example and preliminaries of our work. In Section 3 we present the definition of the BP Compliance Requirements Model (BPCRM) and in Section 4 an example of application of selected compliance requirements specification and assessment of compliance violations with process mining. In Section 5 we present related work and finally in Section 6 we discuss conclusions and future work.

Preliminaries
In this section we present preliminary work over a collaborative BP from a real e-Government scenario we have been working with throughout the application of our approach. We describe the compliance language we have defined to specify compliance requirements over collaborative BPs, as well as the Extended event logs we have defined for collaboration and choreographies, to be used as input for the process mining evaluation along with the compliance specification. Finally, we describe the extended Compliance Rule Graph (eCRG) [17], which is leveraged in this work in order to specify compliance controls.

Collaborative BP model
The collaborative BP is the "Passport Application" which enables citizens to get or renew their passport [18]. It involves three government organizations: the Technical Police National Directorate (DNPT), the Uruguayan e-government agency (AGESIC), and the Civil Identification National Directorate (DNIC). The process begins when a citizen apply for the passport within the AGESIC portal, for which dates for an appointment are provided by DNIC and confirmed by the citizen. DNIC interacts with the DNPT to get information on existing judicial records of the citizen, waiting a 24 hs period for an answer or cancelling the appointment. The appointment is carried out when the citizen does not present judicial records, otherwise it is cancelled. In any case DNIC notifies AGESIC. In Figure 1 the collaboration for the collaborative BP is presented. It can be seen that all messages between participants are named as the ones in the corresponding choreography as shown in Figure 2,interactions with the citizen are omitted.  The choreography model is based on the Uruguayan-Government Interoperability Platform (PDI) [19] from AGESIC, which provides government organizations with capabilities to interact by means of business services using web services technologies. The interaction between these organizations is carried out by invoking services exposed in the PDI instead of communicating directly with the organization providing the service. In this way, messages are sent and received by the three participant organizations: AGESIC, DNIC, DNPT.

Compliance Requirements
The Compliance Requirements Modeling Language (CRML) was introduced in [8], it is a Domain Specific Language (DSL) to specify compliance requirements. It is formalized by an Abstract syntax (metamodel) and a Concrete syntax in graphical form (notation). The CRML defines at the top level a ComplianceArea, e.g. BPs, which is composed of ComplianceDimension elements, e.g. Interaction or Resources, which in turn is composed of ComplianceFactor elements, e.g. Message Flow or Roles. For each ComplianceFactor specific ComplianceControl elements are defined e.g. M precedes N or A performed by R. Generic compliance controls as the ones we present in the BPCRM (c.f. Section 3), serve as basis for compliance requirements specification.
A ComplianceRequirement is a specific instantiation (i.e. a specific value) of a ComplianceControl over a ComplianceObject or a ComplianceObjectType i.e. specific message or element message type, a specific task or element of task type, or collaboration or choreography. A ComplianceControl is composed of ControlConfigurationProperty elements that are configured by means of ControlConfiguration PropertyValue for a ComplianceRequirement.
Also, a high level view of the BPCRM was introduced in [8] based on a previous conceptualization made in [15], including dimensions and factors and two examples of compliance controls for two factors of the Interaction and Time dimensions. It focused on showing how to specify compliance requirements for the choreography view of collaborative BPs. In Table 1 the high level view of the BPCRM is shown, extended with the Participant factor in the Resource dimension, as described in Section 2.3.

Extended Event Logs
The input for process mining efforts is an Event log [11] which includes only one process containing its BP cases (instances) which includes events that happened within the case execution. An event correspond to only one case and refers to elements in the process such as activity, including data of: the timestamp of its occurrence, who (role, people, system) performed it, a transaction type with the lifecycle event e.g. start or complete, attributes such as cost, etc. Events in a trace are ordered by execution time i.e. timestamp. The most used format for event logs is the XES (eXtensible Event Stream) format [20], which is an XML used by process mining tools such as ProM [21]. Within our framework proposal we defined a XES extension for the Event log to specifically include the participants involved in a collaborative BP (collaboration and choreography), and the type of the event element (i.e. task, message). Although there is an standard organizational extension 1 it only includes elements for specifying: resources, roles and groups, which are defined within an organization or participant. For the collaboration we add the <participant> tag to the event tag corresponding to the element in the trace, and we also include the <elemType> tag. For the choreography we add the <fromParticipant> and the <toParticipant> tags to the event tag of the element in the trace, along with the <elemType> too. These elements will allow us to check the compliance requirements we have specified for the collaborative process. In Figure 3 a) and b) we present an excerpt of the extended Event log for the choreography and collaboration respectively, for the "Passport application" choreography and collaboration.

Extended Compliance Rule Graph
The extended Compliance Rule Graph (eCRG) language enables the visual modeling of compliance rules considering multiple perspectives (i.e. control flow, interaction, time, data, and resources) [17]. Its purpose is to provide a well-defined visual language as well as a tool fostering the communication between IT and domain experts. An eCRG comprises nodes and edges that may be enriched with attachments. Nodes may be used to express events (e.g. the start of a task) or entities (e.g. a data object, staff member). In turn, the edges describe the relations between the nodes, such as the order of events and the hierarchical relations between staff members. Conditions may be attached to refine nodes as well as the relations (e.g. time distance between tasks, properties of staff members).
The specification of an eCRG comprises a precondition (i.e. when the compliance rule shall be applied) and a postcondition (i.e. what need to be met to satisfy the compliance rule). Thus, the elements of an eCRG are partitioned into an antecedence pattern (specifying the precondition) and at least one consequence pattern (specifying a postcondition). An eCRG may also specify instances of entities (e.g. a particular staff member or point in time), and not only the occurrence of events but also their absence.
In order to visually distinguish between the antecedent and consequence patterns, eCRG uses dashed lines and round shapes for the elements of a consequence pattern, and solid lines and square shapes for the ones of an antecedence pattern. Finally, absence nodes are crossed out by an oblique cross. Figure 4 presents an example of a compliance rule specified with eCRG, in the context of the collaborative BP "Passport Application" presented in Section 2.1 In particular, the rule specifies that whenever activity "Carry Out Appointment" occurs, then message "Notify Appointment Result" must be sent from DNIC to AGESIC.

BP Compliance Requirements Model (BPCRM)
In this section we present the Compliance Requirements Model (BPCRM) we have defined, which contains specific dimensions, factors and controls for collaborative BPs with integrated process and organizational data. As described in Section 2, in previous work [8] we have presented a high level view of the definition of the BPCRM, based on a previous conceptualization made in [15], and in the well-known proposals of [17,22]. On the one hand, [22] defines compliance patterns but is limited in the perspectives and elements it comprises. On the other hand, [17] defines a very rich set of building blocks and a complete set of perspectives, but does not provide any predefined compliance rule, which hinders the agile specification of requirements.
To define the BPCRM we use the set of perspectives proposed in [17] for defining dimensions and factors, and for defining compliance controls for each factor we use the patterns vision of [22]. The BPCRM model is intended to serve as a reference for specifying compliance requirements for collaborative BPs, which can be instantiated for any collaboration and choreography extended event log. The set of compliance controls defined are generic but specific for collaborative BPs to help users identifying and using compliance specification.
Next, we present the BPCRM including Dimensions, Factors and the complete set of Controls we have defined that apply to both collaboration and choreography views and elements of collaborative BPs, widely extending the initial presentation. We provide a table for each dimension in which each control is defined including a name, a description, to which elements it applies, and the properties that are involved. We use letters A,B,C for activities, M,N,Q for messages, P for participants with indexes Xi,j,k,l,f,g (with the identification of the activity or message of the participant (e.g. P Ai or P Mj ), R,S for roles, U,V for users, O for organizational unit, DO for data object and DC for data container. For further details on these and other concepts included in the model refer to [17] [22].

Control flow dimension
The Control Flow dimension comprises compliance aspects related to the occurrence and order of tasks as well as their flow [23]. As shown in Table 2, this dimension comprises five factors (i.e. Tasks, Sequence Flow, Parallel Flow, Exclusive Flow and Alternative Flow) and eleven controls. The Tasks factor comprises controls involving the occurrence or absence of tasks. The other four factors comprises controls involving the flow between tasks.
An example of compliance requirement that can be specified based on these controls for the running example Passport Application process is: "if task Receive appointment cancellation is present, then Notify appointment result must not be present, and vice versa". This compliance requirement is an instantiation of the compliance control A exclusive B shown in Table 2. Figure 5 presents the specification of some of the compliance controls of the control flow dimension using eCRG (cf. Section 2.4).

Interaction dimension
The Interaction dimension comprises aspects related to message exchanges between participants as well as their flow [23]. As shown in Table 3, this dimension comprises two factors (i.e. Send / Receive Messages, Message Flow) and the definition of eleven compliance controls. The Send / Receive Messages factor comprises controls involving the occurrence or absence of messages. The Message Flow factor comprises controls involving the flow between messages.
An example of compliance requirement that can be specified based on these controls for the Passport Application process is: "if message Notify Appointment Cancellation is exchanged, then Notify Appointment Result must not be exchanged", and vice versa. This compliance requirement is an instantiation of the compliance control M exclusive N shown in Table 3.

Time dimension
The Time dimension comprises compliance aspects related to points in time as well as time intervals and conditions [23]. As shown in Table 4, this dimension comprises three factors (i.e. Point in Time, Interval, Duration) and the definition of twelve compliance controls.    An example of compliance requirement that can be specified based on these controls for the Passport Application process is: "the message Judicial Records Response must be exchanged at most 24 hours later than the message Has Judicial Records? ". This compliance requirement is an instantiation of the compliance control "M cooccurs N within I" shown in Table 4. Figure 7 presents the specification of various of the compliance controls of the time dimension using eCRG (cf. Section 2.4).

Resources dimension
The Resources dimension comprises compliance aspects related to the resources used in processes as well as their relations [23]. As shown in Table, 5   Members altogether, since the same controls are defined for each of them, by replacing role R for the corresponding one.
An example of compliance requirement that can be specified based on these controls for the Passport Application process is: "role Coordinator must perform task Coordinate the dates for the appointment". This compliance requirement is an instantiation of the control A performed by R shown in Table 5. Figure 8 presents the specification of various compliance controls of the resource dimension using eCRG (cf. Section 2.4).

Data dimension
The Data dimension comprises compliance aspects related to data elements used in processes as well as their relations and flows [23]. As shown in Table 6, this dimension comprises four factors (i.e. Data Objects, Data Containers, Data Relations, Data Flow) and the definition of twenty controls.
The Data Objects factor comprises controls with a single data object and a single task. The Data Containers factor comprises controls with a single data container and a single activity. The Data Flow factor comprises controls involving a single data object or data container and at least two tasks with a data flow relation. Finally, the Data Relations factor comprises controls with more that one data element (e.g. data object, data value) related to each other and at least one task.
An example of compliance requirement that can be specified based on these controls for the Passport Application process is: "the activity Receive appointment result must read a data object appointment result written by the activity Notify appointment result". This compliance requirement is an instantiation of the compliance control "B reads DO written by A" shown in Table 6.

Example of application
This section presents an example of how the proposed model may be leveraged in order to facilitate and make more agile the specification of compliance requirements of collaborative business processes. In particular, the example focuses on the Passport Application BP presented in Section 2 and describes how compliance requirements may be specified based on the controls included in the model.
Note that as compliance controls are already defined in the model, the specification of compliance requirements only implies the configuration of properties. In addition, once requirements are specified in CRML, they can be assessed with the ProM plugin as presented in Section 4.3. An example of a CRML diagram specifying the compliance requirements graphically can be found in [8]. In the following we present examples for the choreography and collaboration views, with specification of controls for the dimensions and factors that applies to each one.

Compliance Requirements for choreography
In this subsection we present examples of compliance requirements controls specifications for controls defined for the choreography view of collaborative BPs, for different dimensions and factors.

Interaction Compliance Requirement
One of the interaction compliance requirements that the Passport Application CBP has for the choreography is: "CRQ1: Either message Notify Appointment Cancellation or message Notify Appointment Result must be exchanged". This requirement may be specified by leveraging the compliance control M muttex choice N of the Send Receive Messages factor, by configuring the properties of the control as shown in Table 7. Other interaction compliance requirement for the Passport Application CBP is: "CRQ2: Message Has judicial records is exchanged before Message Judicial records response". This requirement may be specified by leveraging the compliance control M precedes N of the Message Flow factor, by configuring the properties of the control as shown in Table 8.
Has judicial records Message N Judicial records response Participants: P Mi -P Mj DNIC -DNPT Participants: P Nk -P Nl DNPT -DNIC Another interaction compliance requirement for the Passport Application CBP is: "CRQ3: Message Confirm appointment is exchanged after Message Get available dates". This requirement may be specified by leveraging the compliance control M leads to N of the Message Flow factor, by configuring the properties of the control as shown in Table 9.

Time Compliance Requirement
One of the time compliance requirements that the Passport Application CBP has is: "CRQ4: If message Has Judicial Records is exchanged, then message Judicial Records Response must be exchanged within 24 hours". This requirement may be specified by leveraging the compliance control M cooccurs N within I of the Interval factor, by configuring the properties of the control as shown in Table 10.

Resources Compliance Requirement
A resources compliance requirement that the Passport Application CBP has is: "CRQ5: Message Get Available Dates must be send from role Coordinator and received by role System". This requirement may be specified by leveraging the compliance control M send and received by R, S of the Performer relations factor, by configuring the properties of the control as shown in Table 11.

Data Compliance Requirement
A data compliance requirement that the Passport Application CBP has is: "CRQ6: Message Notify appointment cancellation must contain Data object Appointment status with value: Cancelled ". This requirement may be specified by leveraging the compliance control DO must be contained in Message M with value V of the Data Relations factor, by configuring the properties of the control as shown in Table 12.

Compliance Requirements for collaboration
In this subsection we present examples of compliance requirements controls specifications for controls defined for the collaboration view of collaborative BPs, for different dimensions and factors.

Control Flow Compliance Requirement
One of the control flow compliance requirements that the Passport Application CBP has for the collaboration is: "CRQ7: If activity Receive appointment cancellation is present then Notify appointment result must not be present, and vice versa." This requirement may be specified by leveraging the compliance control A exclusive B of the Exclusive Flow factor, by configuring the properties of the control as shown in Table 13. Notify appointment result Participants: P Ai -P Bj AGESIC -DNIC Another control flow compliance requirements for the Passport Application CBP is: "CRQ8: Activity Send available dates must immediately follow Activity Get available dates". This requirement may be specified by leveraging the compliance control A xleads to B of the Sequence Flow factor, by configuring the properties of the control as shown in Table 14. Send available dates Participants: P Ai -P Bj AGESIC -DNIC Another control flow compliance requirements for the Passport Application CBP is: "CRQ9: Activity Send confirmation must follow Activity Confirm appointment". This requeriment differs from the previous one since the activity that must follow the defined one, can do it at any point within the case log, and not mandatory immediately following it. This requirement may be specified by leveraging the compliance control A leads to B of the Sequence Flow factor, by configuring the properties of the control as shown in Table 15. Send confirmation Participants: P Ai -P Bj AGESIC -DNIC It is worth mentioning that the last two controls for the sequence flow factor of the control flow dimension for Collaborations i.e. CRQ8 and CRQ9, have their corresponding controls in the message flow factor of the interaction dimension for choreographies as presented before in CRQ2 for CRQ8. This is by definition since the relations between activities from different participants (pools) of the collaboration, can also be defined by the messages the participants exchange within the corresponding choreography. This also happens for other factors from other dimensions such as time dimension (all factors), resources dimension (some factors) and data dimension (some factors), where it makes sense to define the corresponding controls for both views.

Resources Compliance Requirement
A resources compliance requirements that the Passport Application CBP has is: "CRQ10: The role Coordinator must perform the activity Coordinate dates for the appointment". This requirement may be specified by leveraging the compliance control A performed by R of the Roles factor, by configuring the properties of the control as shown in Table 16.

Data Compliance Requirement
One of the data compliance requirements that the Passport Application CBP has is: "CRQ11: Data object Judicial Records contained in message Judicial Records Response must be read by activity Receive judicial records". This requirement may be specified by leveraging the compliance control A reads DO contained in M of the Data Flow factor, by configuring the properties of the control as shown in Table 17.

Assessing Compliance Requirements with ProM
To assess compliance requirements with process mining using our proposal we have implemented a plug-in for the ProM framework, which is available here 2 . It takes two inputs: i) the Extended event logs we have presented in Section 2.3 for collaborative BPs in XES format, either a collaboration or a choreography, and ii) the specification of the compliance requirements in the language CRML (presented in Section 2.2) in XMI format, which were instantiated for the specific BP from the model BPCRM (presented in Section 3). Note that the type of event log (collaboration or choreography) to be used as input may be determined by the availability of logs in the specific scenario and by the type of requirements that need to be checked.
The Event log of the Passport Application collaborative BP we used for the example contains 100.000 cases and 646.476 events. We used as input two different Event logs: one for the choreography that uses the extension presented in Figure 2.3 a), and the other for the collaboration that uses the extension presented in Figure 2.3 b). The compliance requirements files in XML includes the specification presented before, for choreography the CRQ2 and CRQ3 examples, for the Interaction and Time dimensions respectively, and for collaboration the CRQ7 and CRQ8, to illustrate the evaluation with ProM.
The plug-in shows the results organized as follows: i) the left superior area shows the model of the process evaluated (optionally uploaded as input); ii) the right superior area shows two indicators: the percentage of traces that present at least one compliance violation and the dimension with most violations; and iii) the inferior area shows one card for each compliance rule that was evaluated (from the input compliance file), including to which control it belongs, the values of the specific instantiation for the process i.e. message "Has judicial records", and the number and percentage of non compliant traces over the total number of traces of the input event log. Figure 10 and Figure 11 depicts an excerpt of the output of the compliance requirements assessment in the ProM plug-in for the Passport Application BP and the choreography extension. Due to space reasons we only show the first two that fit the visualization window in all figures, but the results can be scroll down within the plug-in. In the first case the screenshot corresponds to the compliance requirements CRQ1 from the Interaction dimension and Send/Receive Messages factor and CRQ4 from the Time dimension Interval factor as specified before. In the second case the screenshot corresponds to the compliance requirements CRQ2 and CRQ3 from the Interaction dimension and Message Flow factor both. Figure 12 depicts an excerpt of the output of the compliance requirements assessment in the ProM plug-in for the Passport Application BP and the collaboration extension.

Discussion and implications
In the previous sections, we have shown how several compliance requirements controls defined for different dimensions and factors can be easily specified for a specific business process and view i.e. collaboration and choreography. We have focused on an e-Government process we have used before, extending the compliance analysis to several different aspects of the process. In the choreography view the focus is on different aspects regarding the exchange of messages between participants of the collaborative process, and in the collaboration view internal elements of each participant lead to include other aspects of the interaction between them that should be also taken into account.  As e-Government processes are mostly collaborative processes, being able to analyze process compliance from these two points of view is of utmost importance to get information not only on participant organizations but also on their interaction. Also, in the e-Government domain being compliant with existing normative, regulations and laws is mandatory, but many processes are not explicitly specified and process models are mostly missing, for which being able to analyze data from the real execution of processes will help in detect compliance violations and alert organizations in the way they are conducting their processes.
At the level of each organization, being able to analyze these data would be extremely useful to contrast the idea they have of their processes with the actual processes being executed. This will allow them to Figure 12: Example of the ouput of the ProM plug-in implementing our approach for collaboration focus improvement efforts on the specific elements that led to compliance violations, as part of a more ambitious continuous improvement plan, that could be firstly guided by these discoveries, and the tool support we provide. Another element that could be of interest and useful to organizations for implementing improvements, is to provide guides for correcting each compliance violation detected, as part of the model. These guides could be part of an extension of the controls defined in the model, which may also provide corrective actions associated to each one, with examples and possibly pointers to tools and guidelines to implement them.
Regarding the implications of the compliance requirements model for the e-Government sector, we think that having this complete catalogue of compliance requirements controls from which to choose the ones that need to be enforced on each process, will ease compliance management in a great manner. Instead of having to translate normative, regulations and laws that apply over a process to a definition and specification of compliance requirements controls, the approach enables the selection of the ones that apply to the process from the catalogue that the model provides, as well as their application for the actual process with actual data of its execution that should be considered for the compliance analysis. These benefits can be extended to other sectors as well, since collaborative processes are also present in many other domains such as banking, e-health, industry 4.0, among others.
We also claim that the compliance requirements model seen as a catalogue is easy to understand by business users, also with the eCGR visual specification that enhanced the text description. Also, the CRML language that we have defined to specify controls from the model eases such specification for users, since it provides a visual notation with few connected elements helping the understanding of the content that is being specified. However, we have not tested these claims for which as future work we plan to carry out an experiment with real e-Government users to get feedback on both the compliance requirements model generic controls as defined, and the CRML language to specify concrete controls for particular processes.

Related work
Related proposals define mechanisms (e.g. languages, formal approaches) to enable the specification of compliance requirements, as a first step towards assessing their fulfillment (at design time, runtime or after execution) [24] [13]. Several of them focus on reducing the gap between compliance concepts and technical or formal mechanisms. For instance, the COMPAS project [25] defines DSLs geared towards compliance specialists. Also, the SeaFlows proposal [26] and the C 3 Pro project [27] enable the visual specification of compliance requirements. Other proposals leverage pattern-based solutions [28] and policy-based approaches [29][7], among others.
Our work leverages some existing proposals (mainly [28] [27]) in order to define a broad and extensible compliance requirements model, with a catalogue of reusable controls and associated tools to link them to BPMN process specifications, with the goal of enabling an agile specification of compliance requirements over collaborative BPs. With respect to the assessment of compliance requirements, although there are some proposals which use the event log [30] [13], to the best of our knowledge none of them focus on business process models in BPMN 2.0 extended with specific compliance requirements elements.
Close to detecting compliance violations is anomaly detection, which refers to anomalous or infrequent behavior that deviates from the "normal" behavior in the process [31]. Different approaches are proposed to detect mostly control flow and data flow anomalies in business processes, using different techniques [31,32,33]. In particular, conformance checking compares an event log with a reference process model to detect deviations from it i.e. anomalous traces [31,11]. These approaches can be complementary to ours for some of the controls defined from those dimensions e.g. order of activities or messages, or resources executing tasks. However, some approaches such as conformance checking requires that a reference "normal" process model is in place in order to compare the event log behavior against it, and in most real settings in organizations this is not the case. Although the "normal" process model can be discovered from the event log applying several filters and measures such as fitness and precision [31] could be a challenging task to get the correct one without significant domain knowledge.
On the contrary, our approach does not need to discover the "normal" process since by specifying the set of compliance requirements over the process as input for the evaluation, event log traces can be compared against the compliance specification without discovering the model. Compliance requirements for processes can be easily elicit from business people with domain knowledge (even if they do not know the actual "normal" process model, they know which activities, messages, participants, etc. should comply with organization rules or even country laws), and specify them using our CRML language, from which the input file for the evaluation is obtained. We also provide a user-friendly dashboard in ProM to show violations results for each control and further inspection of non-compliant traces.

Conclusions and future work
In this paper we have presented a compliance requirements model, called BPCRM, that defines generic compliance controls for collaborative BPs. It intends to serve as basis for the specification of compliance requirements over BPs, and evaluation of compliance violations in a post mortem way with process mining, over an extended event log for collaborative BPs. The specification of compliance requirements for BPs allows to explicitly state the rules that should be enforced in BPs execution, and helps analyzing the deviations found.
The proposed BPCRM model is a general model that can be instantiated for any BP, by selecting the compliance controls that applies to the process regarding the compliance requirements that should be specified for the particular case. BPCRM constitutes a catalogue of generic compliance controls or patterns that are commonly used to describe compliance requirements, based on existing literature, with focus on the particularities of collaborative BPs. We illustrate the model application with an example of compliance requirements specification and evaluation with a ProM plug-in implementing the approach, both for the choreography and collaboration views.
We believe that the BPCRM can be a useful guide for organizations to select and specify compliance requirements and to evaluate to what extent do their processes comply with the normative and rules that apply to them. We are working on applying the approach over other collaborative BPs from e-Government to further assess the proposal.
In addition, the results of this work are a step forward towards performing other compliance-related activities such as violation traceability (i.e. provide the causes that led to the violation and the affected elements of the process model), compliance recovery (i.e. define and execute mechanisms to react to a violation and re-establish compliance) and compliance resolution (i.e. engage corrective actions to remove the causes of the violation) [34]. In this line, we are planning to advance in these matters by extending the approach, in particular, in the context of the considered collaborative BPs.