Rule-Based Conformance Checking"

In processcheckR: Rule-Based Conformance Checking of Business Process Event Data

knitr::opts_chunk$set(
  collapse = TRUE,
  comment = "#>"
)

The goal of processcheckR is to support rule-based conformance checking. Currently the following declarative rules can be checked:

Cardinality rules:

• contains: activity occurs n times or more
• contains_exactly: activity occurs exactly n times
• contains_between: activity occures between min and max number of times
• absent: activity does not occur more than n - 1 times

Ordering rules:

• starts: case starts with activity
• ends: case ends with activity
• succession: if activity A happens, B should happen after. If B happens, A should have happened before.
• response: if activity A happens, B should happen after
• precedence: if activity B happens, A should have happend before
• responded_existence: if activity A happens, B should also (have) happen(ed) (i.e. before or after A)

Exclusiveness:

• and: two activities always exist together
• xor: two activities are not allowed to exist together

Rules can be checked using the check_rule function (see example below). It will create a new logical variable to indicate for which cases the rule holds. The name of the variable can be configured using the label argument in check_rule.

Installation

You can install processcheckR from github with:

# install.packages("devtools")
devtools::install_github("gertjanssenswillen/processcheckR")

Example

library(bupaR)
library(processcheckR)
sepsis %>%
  # check if cases starts with "ER Registration"
  check_rule(starts("ER Registration"), label = "r1") %>%
  # check if activities "CRP" and "LacticAcid" occur together
  check_rule(and("CRP","LacticAcid"), label = "r2") %>%
  group_by(r1, r2) %>%
  n_cases() 

processcheckR documentation built on Oct. 3, 2022, 5:05 p.m.