Where Did I Misbehave? Diagnostic Information in Compliance Checking

Abstract

Abstract. Compliance checking is gaining importance as today's organizations need to show that operational processes are executed in a controlled manner while satisfying predefined (legal) requirements. Deviations may be costly and expose the organization to severe risks. Compliance checking is of growing importance for the business process management and auditing communities. This paper presents a comprehensive compliance checking approach based on Petrinet patterns and alignments. 55 control flow oriented compliance rules, distributed over 15 categories, have been formalized in terms of Petri-net patterns describing the compliant behavior. To check compliance with respect to a rule, the event log describing the observed behavior is aligned with the corresponding pattern. The approach is flexible (easy to add new patterns), robust (the selected alignment between log and pattern is guaranteed to be optimal), and allows for both a quantification of compliance and intuitive diagnostics explaining deviations at the level of alignments. The approach can also handle resource-based and data-based compliance rules and is supported by ProM plug-ins. The applicability of the approach has been evaluated using various real-life event logs.

Diagnostic Information for Compliance Checking of Temporal Compliance Requirements

“…They originate from legislations and restrict one or several perspectives of a process (control flow, data flow, process time or organizational aspects), they can restrict each case individually or a group of cases, or prescribe properties of process executions or process design [21]. These different aspects of compliance give rise to the compliance rule framework shown in Fig.…”

“…After each cycle of 3 treatments, in case of necessity, the treatment can be extended for other cycles; but there should be delay of at least one week between two subsequent cycles of treatment". [21] This requirement can be divided into three different compliance rules: (1) (control flow) "antibiotics must be administered in cycles of 3 occurrences", (2) (process time) "between two subsequent administration of antibiotics in a cycle, there should be one day delay", and (3) (process time) "between two subsequent cycles, there should be at least one week delay", each taking only one perspective (control flow or process time) into account. The compliance checking technique of [21] is able to check control-flow compliance rules, but does not provides a notion of time and therefore cannot check temporal compliance rules.…”

“…[21] This requirement can be divided into three different compliance rules: (1) (control flow) "antibiotics must be administered in cycles of 3 occurrences", (2) (process time) "between two subsequent administration of antibiotics in a cycle, there should be one day delay", and (3) (process time) "between two subsequent cycles, there should be at least one week delay", each taking only one perspective (control flow or process time) into account. The compliance checking technique of [21] is able to check control-flow compliance rules, but does not provides a notion of time and therefore cannot check temporal compliance rules. In the following, we investigate the relation between the control-flow and time perspective, then present a new technique that supports time to check temporal compliance rules, and finally show how to integrate diagnostic information from both perspectives for comprehensive compliance diagnostics.…”

“…Some example rules with their category are given next. The complete collection of compliance rules and their formalization is described in [22].…”

“…Compliance violations regarding time cannot be detected using existing control-flow checking techniques such as [21]; as these techniques abstract from a concrete notion of time, both when specifying compliance rules and when checking reality recorded in the event log against specified behavior. Therefore for temporal compliance checking, it is required to express temporal constraints with an explicit notion of time, capture notion of time in the event log and compare the specified time in temporal constraints with time recorded in the event log.…”