From 770c6beca66fe757aa78930b3c110bc6690929e1 Mon Sep 17 00:00:00 2001 From: i1es <73138008+i1es@users.noreply.github.com> Date: Sun, 22 Jan 2023 15:03:55 +0000 Subject: [PATCH] =?UTF-8?q?Deploying=20to=20gh-pages=20from=20@=20bupavers?= =?UTF-8?q?e/docs@baca4644601b2d4eed9dbdfb5e6804b3d9fd4f39=20=F0=9F=9A=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- advanced_maps.html | 30 +- animate_maps.html | 100 +++---- augment.html | 14 +- case_filters.html | 12 +- collapse.html | 18 +- create_logs.html | 516 +++++++++++++++++--------------- event_filters.html | 4 +- frequency_maps.html | 24 +- generic_filtering.html | 28 +- multi_dimensional_analysis.html | 24 +- mutate.html | 14 +- organisational_analysis.html | 4 +- performance_maps.html | 41 +-- unite.html | 8 +- 14 files changed, 429 insertions(+), 408 deletions(-) diff --git a/advanced_maps.html b/advanced_maps.html index 8546bee..d491333 100644 --- a/advanced_maps.html +++ b/advanced_maps.html @@ -658,16 +658,16 @@

Advanced maps

library(bupaverse)

Combining different profiles

-

The profile used for edges and nodes can be differentiated using the -type_edges and type_nodes attributes instead +

The profile used for nodes and edges can be differentiated using the +type_nodes and type_edges attributes instead of the type argument. In this way, information about frequencies and performance, or any other value, can be combined in the same graph.

patients %>%
     process_map(type_nodes = frequency("relative_case"),
                 type_edges = performance(mean))
-
- +
+

Adding secondary information

@@ -676,23 +676,23 @@

Adding secondary information

patients %>%
     process_map(type = frequency("relative_case"),
                 sec = frequency("absolute"))
-
- -

Both primary and secondary layers can be differentiated between edges -and nodes.

+
+ +

Both primary and secondary layers can be differentiated between nodes +and edges.

patients %>%
     process_map(type_nodes =  frequency("relative_case"),
                 type_edges = performance(units = "hours"),
                 sec_nodes = frequency("absolute"),
                 sec_edges = performance(FUN = max, units = "hours"))
-
- +
+

Customizing colors

Both frequency() and performance() have the argument color_scale and color_edges to -customize the colors in the process map.

+customize the colors in the process map:

Customizing the layout

-

The layout of the process map can be further customized.

+

The layout of the process map can be further customized:

diff --git a/animate_maps.html b/animate_maps.html index 430aa69..e068c6e 100644 --- a/animate_maps.html +++ b/animate_maps.html @@ -668,41 +668,42 @@

bupaR Docs | Animate Process Maps

Animate Process Maps

library(bupaverse)
 library(processanimateR)
-

We use the patients event log provided by the eventdataR package.

+

Here, we use the patients event log provided by the +eventdataR package.

A basic animation with static color and token size:

animate_process(patients)
-
- +
+

Default token color, size, or image can be changed as follows:

animate_process(patients, mapping = token_aes(size = token_scale(12), shape = "rect"))
-
- +
+ 
animate_process(patients, mapping = token_aes(color = token_scale("red")))
-
- +
+

The example animation on the top of this site:

animate_process(patients, mode = "relative", jitter = 10, legend = "color",
   mapping = token_aes(color = token_scale("employee", 
     scale = "ordinal", 
     range = RColorBrewer::brewer.pal(7, "Paired"))))
-
- +
+

Tokens can also be assigned images, for example:

animate_process(patients,
    mapping = token_aes(shape = "image",
     size = token_scale(10),
     image = token_scale("https://upload.wikimedia.org/wikipedia/en/5/5f/Pacman.gif")))
-
- +
+

Use external data

It is possible to use a secondary data frame to determine the -aesthetics of tokens irregardless of the times at which activities -occurred. This can be useful if measurement are taken throughout a -process, but the measurement event itself should not be included in the -process map.

-

For example, the lactic acid measurements of the sepsis data could be -used in that way:

+aesthetics of tokens regardless of the timestamps at which activities +occurred. This could be useful if some measurements were taken +throughout a process, but the measurement event itself should not be +included in the process map.

+

For example, the lacticacid measurements of the +sepsis data set could be used in that way:

library(processanimateR)
 library(dplyr)
 library(bupaR)
@@ -729,13 +730,13 @@ 
Use external data

                 mapping = token_aes(color = token_scale(lactic, 
                                                         scale = "linear", 
                                                         range = c("#fff5eb","#7f2704"))))
-
- -

ProcessanimateR animation can be also used interactively as part of a -(Shiny) web-application. Here, an example application that expects -attributes are of an appropriate data type and automatically chooses -appropriate color scales is given. We first define a function -ianimate_process that defines our Shiny application as +

+ +

processanimateR animation can be also used interactively +as part of a (Shiny) web-application. Here, an example application that +expects attributes are of an appropriate data type and automatically +chooses appropriate color scales is given. We first define a function +ianimate_process() that defines our Shiny application as follows:

@@ -848,7 +849,6 @@

Shiny

}

Then, the application can be, for example, launched by calling:

-



library(eventdataR)
 library(edeaR)
 library(dplyr)
@@ -859,17 +859,12 @@ 
Shiny

   # the token size option currently only support numeric attributes
   mutate_at(c("lacticacid", "leucocytes", "crp", "age"), as.numeric) %>%
   mutate_at(c("disfuncorg", "sirscriteria2ormore", "infectionsuspected"), as.logical))
-

ProcessanimateR animation can be also used interactively as part of a -(Shiny) web-application. Here, an example application that expects -attributes are of an appropriate data type and automatically chooses -appropriate color scales is given. We first define a function -ianimate_process that defines our Shiny application as follows:

Selections

-

Selections made in the processanimateR animation be used as input by -Shiny applications. Here a simple example in which a Shiny module is -created that renders the case identifiers of selected tokens and the -identifiers and names of selected activities:

+

Selections made in the processanimateR animation can be +used as input by Shiny applications. Here a simple example in which a +Shiny module is created that renders the case identifiers of selected +tokens and the identifiers and names of selected activities:

library(shiny)
 library(processanimateR)
 library(eventdataR)
@@ -948,9 +943,9 @@ 
User defined bins

 
Contributed by Dominic
 Rowney. 

 
It is possible to change the aesthetics of tokens based on the
-timestamp of the animation

+timestamp of the animation.

 
For example, the number of days a ‘patient’ has been in the
-system

+system.

 
# Libraries ---------------------------------------------------------------
 library(dplyr)            ##pipes
 library(tidyr)            ##tidy data, partcularly the crossing() function

@@ -975,8 +970,8 @@ 
User defined bins

             mutate(day = days(value)) #convert numeric value into days

This will change the colour of the token at 0, 2, 4, 8, and 16 days.

-

The crossing() function joins the cases of ‘patients’ to ‘my_flags’ -and creates all possible combinations.

+

crossing() joins the cases from patients to +my_flags and creates all possible combinations.

# Create timestamps of flags ----------------------------------------------
 
 my_timeflags <- patients %>% 
@@ -985,11 +980,11 @@ 
User defined bins

                 mutate(time = start_timestamp + day) %>% 
                 filter(time <= complete_timestamp) %>% 
                 select("case" = patient,time,value) ##must be case, time, value
-

The data for the token_scale() function must have the column headings -‘case, time, value’.

-

Without the domain = my_flags$value argument the flags follow +

The data for the token_scale() must have the column +headings ‘case, time, value’.

+

Without setting domain = my_flags$value the flags follow alphabetic order (e.g. 0, 16, 2, 4, 8) rather than the numeric order we -wants. See d3-legend for further information.

+want. See d3-legend for further information.

# Animate process ---------------------------------------------------------
 
 patients %>%
@@ -1002,16 +997,17 @@ 
User defined bins

                                         , domain = my_flags$value
                                         , range = rev(RColorBrewer::brewer.pal(5,"Spectral"))
                     )))
-
- -

The colors can be modified through the range argument. In this case -the scale is reversed with rev() to go from blue to red. See

+ +

The colors can be adjusted by the range argument. In +this case the scale is reversed with rev() to go from blue +to red. See RColorBrewer::brewer.pal.info for all options:

Acknowledgement

Thanks to Dominic Rowney -for this nice example of advanced processanimateR usage. The original -example code can be found processanimateR usage. +The original example code can be found here.

@@ -1026,8 +1022,8 @@

Ordinal scales

mapping = token_aes(color = token_scale("employee", scale = "ordinal", range = RColorBrewer::brewer.pal(8, "Paired"))))
-
- +
+

Linear scales

@@ -1044,8 +1040,8 @@

Time scales

mapping = token_aes(color = token_scale("time", scale = "time", range = c("blue","red"))))
-
- +
+

Source: https://bupaverse.github.io/processanimateR/

diff --git a/augment.html b/augment.html index 6eec825..76b284b 100644 --- a/augment.html +++ b/augment.html @@ -653,8 +653,8 @@

bupaR Docs | Augment logs

Augment logs

library(bupaverse)
 library(dplyr)
-

Enriching your log with calculated metrics can be done -using augment(). For example, consider Enriching an event log with calculated metrics can be done using +augment(). For example, consider trace_length().

traffic_fines %>%
     trace_length(level = "case")
@@ -750,8 +750,9 @@

Select variables

## 6 Blood test 3.08… 4.7… 5.5… 5.46… 6.2… 8.1… 1.06 1.51 1311… 0.0871 ## 7 MRI SCAN 2.48… 3.6… 4.1… 4.09… 4.6… 5.9… 0.735 1.09 979… 0.0867 ## # … with abbreviated variable name ¹​relative_frequency -

Calling augment without any further arguments will add all columns, -from min until relative_frequency to the data.

+

Calling augment without any further arguments will add +all columns, from min until relative_frequency to the +data.

patients %>% 
     processing_time(level = "activity", units = "hours") %>%
     augment(patients) %>%
@@ -820,8 +821,9 @@ 
Adding multiple metrics

 
As you can see only the trace_coverage()
 values of the second augment are added, while the first augment is lost.
-This is because the patients dataset did not get updated after the first
-augment() call. The proper way would be as follows.

+This is because the patients data set did not get updated
+after the first augment() call. The proper way would be as
+follows.

 
patients %>%
     trace_length(level = "case") %>%
     augment(patients, prefix = "trace_length") -> patients
diff --git a/case_filters.html b/case_filters.html
index 1859fc0..449fe64 100644
--- a/case_filters.html
+++ b/case_filters.html
@@ -1055,8 +1055,8 @@ 
Endpoints

 
patients %>%
     filter_endpoints(start_activities = "Registration", end_activities = "Check-out") %>%
     process_map()

-

-
+

+
 

 

 
Endpoints Condition

@@ -1323,16 +1323,16 @@ 
Infrequent Flows

 href="https://bupaverse.github.io/docs/frequency_maps.html">process
 map below.

 
traffic_fines %>% process_map()

-

-
+

+
 
In this map, we can observe several unique directly follows
 relations, as well as flows occurring only 2 or 3 times. Using the
 filter, we can remove the cases that lead to these flows as follows:

 
traffic_fines %>%
     filter_infrequent_flows(min_n = 5) %>%
     process_map()

-

-
+

+
 
We can immediately observe less very infrequent flows in the process
 map.

 
It is important to note that filter_infrequent_flows()
diff --git a/collapse.html b/collapse.html
index 587730d..aebe05b 100644
--- a/collapse.html
+++ b/collapse.html
@@ -572,20 +572,20 @@ 
bupaR Docs | Collapse Activities

 
Collapse Activities

 
library(bupaverse)

 
Using act_collapse() you can replace a set of closely
-related activities by one higher level activity. For example, consider
-the patients process map.

+related activities by one higher-level activity. For example, consider
+the process map of patients data set.

 
patients %>%
     process_map()

-

-
-
Let’s say we want to combine the activities “Blood test”, “MRI SCAN”
-and “X-Ray” scan into a single “Examination” activity. This can be done
-as follows.

+

+
+
Let’s say we want to combine the activities Blood test,
+MRI SCAN and X-Ray scan into a single
+Examination activity. This can be done as follows:

 
patients %>%
     act_collapse(Examination = c("Blood test","MRI SCAN","X-Ray")) %>%
     process_map()

-

-
+

+
 

 
Read more:

 

diff --git a/create_logs.html b/create_logs.html
index e091580..096ee54 100644
--- a/create_logs.html
+++ b/create_logs.html
@@ -724,51 +724,51 @@ 
Logs: eventlog vs activitylog

 
 
 Registration
-428
+22
 r1
-428
+22
 start
-2018-02-17 00:45:15
+2017-01-19 20:00:08
 
 
-Triage and Assessment
-428
-r2
-928
-start
-2018-02-17 02:57:27
-
-
 Registration
-428
+22
 r1
-428
+22
 complete
-2018-02-17 02:57:27
+2017-01-19 22:44:07
+
+
+Triage and Assessment
+22
+r2
+522
+start
+2017-01-20 12:49:46
 
 
 Triage and Assessment
-428
+22
 r2
-928
+522
 complete
-2018-02-17 16:34:28
+2017-01-21 00:03:01
 
 
-X-Ray
-428
-r5
-1700
+Blood test
+22
+r3
+1012
 start
-2018-02-20 00:56:41
+2017-01-21 11:56:45
 
 
-X-Ray
-428
-r5
-1700
+Blood test
+22
+r3
+1012
 complete
-2018-02-20 06:52:49
+2017-01-21 16:35:48
 
 
 
@@ -859,27 +859,27 @@ 
Logs: eventlog vs activitylog

 
 
 Registration
-428
+22
 r1
-428
-2018-02-17 02:57:27
-2018-02-17 00:45:15
+22
+2017-01-19 22:44:07
+2017-01-19 20:00:08
 
 
 Triage and Assessment
-428
+22
 r2
-928
-2018-02-17 16:34:28
-2018-02-17 02:57:27
+522
+2017-01-21 00:03:01
+2017-01-20 12:49:46
 
 
-X-Ray
-428
-r5
-1700
-2018-02-20 06:52:49
-2018-02-20 00:56:41
+Blood test
+22
+r3
+1012
+2017-01-21 16:35:48
+2017-01-21 11:56:45
 
 
 
@@ -951,40 +951,40 @@ 
Scenario 1

 
 
 
-415
+370
 Blood test
-2018-02-07 13:33:50
-2018-02-07 19:49:54
+2017-12-22 19:14:55
+2017-12-23 00:48:40
 
 
-415
+370
 Check-out
-2018-02-08 19:17:04
-2018-02-08 22:25:09
+2017-12-31 09:30:37
+2017-12-31 11:42:12
 
 
-415
+370
 Discuss Results
-2018-02-08 14:29:35
-2018-02-08 17:11:02
+2017-12-30 14:15:51
+2017-12-30 16:35:06
 
 
-415
+370
 MRI SCAN
-2018-02-08 00:38:50
-2018-02-08 05:16:57
+2017-12-23 05:59:22
+2017-12-23 09:36:33
 
 
-415
+370
 Registration
-2018-02-04 08:11:08
-2018-02-04 09:54:23
+2017-12-12 10:43:15
+2017-12-12 14:00:48
 
 
-415
+370
 Triage and Assessment
-2018-02-04 09:54:23
-2018-02-04 19:17:58
+2017-12-13 12:56:20
+2017-12-14 03:42:51
 
 
 
@@ -1013,7 +1013,7 @@ 
Scenario 1

 ## 1 case 
 ## 6 instances of 6 activities 
 ## 0 resources 
-## Events occurred from 2018-02-04 08:11:08 until 2018-02-08 22:25:09 
+## Events occurred from 2017-12-12 10:43:15 until 2017-12-31 11:42:12 
 ##  
 ## # Variables were mapped as follows:
 ## Case identifier:     patient 
@@ -1024,12 +1024,12 @@ 
Scenario 1

 ## # A tibble: 6 × 5
 ##   patient handling              start               complete            .order
 ##   <chr>   <fct>                 <dttm>              <dttm>               <int>
-## 1 415     Blood test            2018-02-07 13:33:50 2018-02-07 19:49:54      1
-## 2 415     Check-out             2018-02-08 19:17:04 2018-02-08 22:25:09      2
-## 3 415     Discuss Results       2018-02-08 14:29:35 2018-02-08 17:11:02      3
-## 4 415     MRI SCAN              2018-02-08 00:38:50 2018-02-08 05:16:57      4
-## 5 415     Registration          2018-02-04 08:11:08 2018-02-04 09:54:23      5
-## 6 415     Triage and Assessment 2018-02-04 09:54:23 2018-02-04 19:17:58      6
+## 1 370 Blood test 2017-12-22 19:14:55 2017-12-23 00:48:40 1 +## 2 370 Check-out 2017-12-31 09:30:37 2017-12-31 11:42:12 2 +## 3 370 Discuss Results 2017-12-30 14:15:51 2017-12-30 16:35:06 3 +## 4 370 MRI SCAN 2017-12-23 05:59:22 2017-12-23 09:36:33 4 +## 5 370 Registration 2017-12-12 10:43:15 2017-12-12 14:00:48 5 +## 6 370 Triage and Assessment 2017-12-13 12:56:20 2017-12-14 03:42:51 6

Note that in case a resource identifier is available, this information can be added in the activitylog call.

@@ -1060,100 +1060,84 @@

Scenario 2

-341 +440 Registration r1 -341 +440 started -2017-11-21 06:22:06 +2018-02-22 16:10:42 -341 -Triage and Assessment -r2 -841 -started -2017-11-21 07:50:23 - - -341 +440 Registration r1 -341 +440 completed -2017-11-21 07:50:23 +2018-02-22 18:28:31 - -341 + +440 Triage and Assessment r2 -841 -completed -2017-11-21 18:20:28 - - -341 -Blood test -r3 -1157 +940 started -2017-11-23 03:29:17 +2018-02-24 06:39:51 -341 -Blood test -r3 -1157 +440 +Triage and Assessment +r2 +940 completed -2017-11-23 09:58:24 +2018-02-25 00:05:45 -341 -MRI SCAN -r4 -1394 +440 +X-Ray +r5 +1703 started -2017-11-23 15:35:09 +2018-02-28 09:58:05 -341 -MRI SCAN -r4 -1394 +440 +X-Ray +r5 +1703 completed -2017-11-23 19:19:43 +2018-02-28 14:36:19 -341 +440 Discuss Results r6 -2075 +2174 started -2017-11-25 12:01:31 +2018-02-28 21:53:51 -341 +440 Check-out r7 -2570 +2669 started -2017-11-25 14:40:34 +2018-03-01 00:52:42 -341 +440 Discuss Results r6 -2075 +2174 completed -2017-11-25 14:40:34 +2018-03-01 00:52:42 -341 +440 Check-out r7 -2570 +2669 completed -2017-11-25 16:56:58 +2018-03-01 02:26:09 @@ -1220,84 +1204,100 @@

Scenario 3

-141 +227 Registration -r5 -141 +r1 +227 started -2017-05-17 14:25:06 +2017-08-09 19:55:30 -141 +227 +Triage and Assessment +r3 +727 +started +2017-08-09 22:17:43 + + +227 Registration r2 -141 +227 completed -2017-05-17 16:33:53 +2017-08-09 22:17:43 - -141 + +227 Triage and Assessment r7 -641 +727 +completed +2017-08-10 15:21:30 + + +227 +Blood test +r7 +1109 started -2017-05-18 16:57:46 +2017-08-17 03:01:24 -141 -Triage and Assessment -r7 -641 +227 +Blood test +r6 +1109 completed -2017-05-19 07:57:15 +2017-08-17 09:17:20 -141 -X-Ray -r1 -1545 +227 +MRI SCAN +r4 +1346 started -2017-05-19 17:33:49 +2017-08-17 13:15:04 -141 -X-Ray -r6 -1545 +227 +MRI SCAN +r2 +1346 completed -2017-05-19 22:58:46 +2017-08-17 18:47:44 -141 +227 Discuss Results r1 -1875 +1961 started -2017-05-21 14:03:26 +2017-08-22 13:33:38 -141 +227 Check-out -r2 -2370 +r3 +2456 started -2017-05-21 17:29:34 +2017-08-22 15:38:38 -141 +227 Discuss Results r6 -1875 +1961 completed -2017-05-21 17:29:34 +2017-08-22 15:38:38 -141 +227 Check-out -r5 -2370 +r4 +2456 completed -2017-05-21 19:55:31 +2017-08-22 17:12:46 @@ -1325,13 +1325,13 @@

Scenario 3

timestamp = "time", resource_id = "employee") 
## Warning in validate_eventlog(eventlog): The following activity instances are
-## connected to more than one resource: 141,1545,1875,2370
-
## # Log of 10 events consisting of:
+## connected to more than one resource: 1109,1346,1961,227,2456,727
+
## # Log of 12 events consisting of:
 ## 1 trace 
 ## 1 case 
-## 5 instances of 5 activities 
-## 5 resources 
-## Events occurred from 2017-05-17 14:25:06 until 2017-05-21 19:55:31 
+## 6 instances of 6 activities 
+## 6 resources 
+## Events occurred from 2017-08-09 19:55:30 until 2017-08-22 17:12:46 
 ##  
 ## # Variables were mapped as follows:
 ## Case identifier:     patient 
@@ -1341,19 +1341,21 @@ 
Scenario 3

 ## Timestamp:           time 
 ## Lifecycle transition:        registration_type 
 ## 
-## # A tibble: 10 × 7
+## # A tibble: 12 × 7
 ##    patient handling           emplo…¹ handl…² regis…³ time                .order
 ##    <chr>   <fct>              <fct>   <chr>   <fct>   <dttm>               <int>
-##  1 141     Registration       r5      141     start   2017-05-17 14:25:06      1
-##  2 141     Registration       r2      141     comple… 2017-05-17 16:33:53      2
-##  3 141     Triage and Assess… r7      641     start   2017-05-18 16:57:46      3
-##  4 141     Triage and Assess… r7      641     comple… 2017-05-19 07:57:15      4
-##  5 141     X-Ray              r1      1545    start   2017-05-19 17:33:49      5
-##  6 141     X-Ray              r6      1545    comple… 2017-05-19 22:58:46      6
-##  7 141     Discuss Results    r1      1875    start   2017-05-21 14:03:26      7
-##  8 141     Check-out          r2      2370    start   2017-05-21 17:29:34      8
-##  9 141     Discuss Results    r6      1875    comple… 2017-05-21 17:29:34      9
-## 10 141     Check-out          r5      2370    comple… 2017-05-21 19:55:31     10
+##  1 227     Registration       r1      227     start   2017-08-09 19:55:30      1
+##  2 227     Triage and Assess… r3      727     start   2017-08-09 22:17:43      2
+##  3 227     Registration       r2      227     comple… 2017-08-09 22:17:43      3
+##  4 227     Triage and Assess… r7      727     comple… 2017-08-10 15:21:30      4
+##  5 227     Blood test         r7      1109    start   2017-08-17 03:01:24      5
+##  6 227     Blood test         r6      1109    comple… 2017-08-17 09:17:20      6
+##  7 227     MRI SCAN           r4      1346    start   2017-08-17 13:15:04      7
+##  8 227     MRI SCAN           r2      1346    comple… 2017-08-17 18:47:44      8
+##  9 227     Discuss Results    r1      1961    start   2017-08-22 13:33:38      9
+## 10 227     Check-out          r3      2456    start   2017-08-22 15:38:38     10
+## 11 227     Discuss Results    r6      1961    comple… 2017-08-22 15:38:38     11
+## 12 227     Check-out          r4      2456    comple… 2017-08-22 17:12:46     12
 ## # … with abbreviated variable names ¹​employee, ²​handling_id, ³​registration_type

Note that we need an eventlog irrespective of which attribute values are differing, i.e. it can be resources, but also any @@ -1500,95 +1502,113 @@

Inconsistent Resources

-144 +484 Registration r7 -144 +484 start -2017-05-19 03:19:05 +2018-04-22 13:40:27 1 -144 -Registration -r6 -144 -complete -2017-05-19 05:09:47 +484 +Triage and Assessment +r4 +984 +start +2018-04-22 16:18:42 2 -144 -Triage and Assessment -r5 -644 -start -2017-05-19 23:16:49 +484 +Registration +r4 +484 +complete +2018-04-22 16:18:42 3 -144 +484 Triage and Assessment -r2 -644 +r6 +984 complete -2017-05-20 12:48:08 +2018-04-23 06:52:27 4 -144 -X-Ray -r5 -1548 +484 +Blood test +r3 +1232 start -2017-05-21 10:16:14 +2018-04-24 22:03:51 5 -144 -X-Ray -r7 -1548 +484 +Blood test +r3 +1232 complete -2017-05-21 14:27:23 +2018-04-25 01:24:25 6 -144 -Discuss Results +484 +MRI SCAN r6 -1878 +1469 start -2017-05-25 03:47:56 +2018-04-25 04:50:02 7 -144 -Discuss Results -r1 -1878 +484 +MRI SCAN +r2 +1469 complete -2017-05-25 05:53:21 +2018-04-25 08:06:00 8 -144 -Check-out -r2 -2373 +484 +Discuss Results +r1 +2218 start -2017-05-25 11:35:23 +2018-04-25 18:47:12 9 -144 +484 Check-out r1 -2373 -complete -2017-05-25 13:10:05 +2713 +start +2018-04-25 22:21:00 10 + +484 +Discuss Results +r7 +2218 +complete +2018-04-25 22:21:00 +11 + + +484 +Check-out +r2 +2713 +complete +2018-04-26 01:01:25 +12 +

If you have a large dataset, and want to have an overview of the @@ -1600,11 +1620,11 @@

Inconsistent Resources

## # A tibble: 5 × 5
 ##   patient handling              handling_id complete start
 ##   <chr>   <fct>                 <chr>       <chr>    <chr>
-## 1 144     Check-out             2373        r1       r2   
-## 2 144     Discuss Results       1878        r1       r6   
-## 3 144     Registration          144         r6       r7   
-## 4 144     Triage and Assessment 644         r2       r5   
-## 5 144     X-Ray                 1548        r7       r5
+## 1 484 Check-out 2713 r2 r1 +## 2 484 Discuss Results 2218 r7 r1 +## 3 484 MRI SCAN 1469 r2 r6 +## 4 484 Registration 484 r4 r7 +## 5 484 Triage and Assessment 984 r6 r4

If you want to remove these inconsistencies, a quick fix is to merge the resource labels together with fix_resource_inconsistencies(). Note that this is not @@ -1622,18 +1642,18 @@

Inconsistent Resources

## # A tibble: 5 × 5
 ##   patient handling              handling_id complete start
 ##   <chr>   <fct>                 <chr>       <chr>    <chr>
-## 1 144     Check-out             2373        r1       r2   
-## 2 144     Discuss Results       1878        r1       r6   
-## 3 144     Registration          144         r6       r7   
-## 4 144     Triage and Assessment 644         r2       r5   
-## 5 144     X-Ray                 1548        r7       r5
+## 1 484 Check-out 2713 r2 r1 +## 2 484 Discuss Results 2218 r7 r1 +## 3 484 MRI SCAN 1469 r2 r6 +## 4 484 Registration 484 r4 r7 +## 5 484 Triage and Assessment 984 r6 r4 
## Inconsistencies solved succesfully.
-
## # Log of 10 events consisting of:
+
## # Log of 12 events consisting of:
 ## 1 trace 
 ## 1 case 
-## 5 instances of 5 activities 
-## 5 resources 
-## Events occurred from 2017-05-19 03:19:05 until 2017-05-25 13:10:05 
+## 6 instances of 6 activities 
+## 6 resources 
+## Events occurred from 2018-04-22 13:40:27 until 2018-04-26 01:01:25 
 ##  
 ## # Variables were mapped as follows:
 ## Case identifier:     patient 
@@ -1643,19 +1663,21 @@ 
Inconsistent Resources

 ## Timestamp:           time 
 ## Lifecycle transition:        registration_type 
 ## 
-## # A tibble: 10 × 7
+## # A tibble: 12 × 7
 ##    patient handling           emplo…¹ handl…² regis…³ time                .order
 ##    <chr>   <fct>              <chr>   <chr>   <fct>   <dttm>               <int>
-##  1 144     Registration       r6 - r7 144     start   2017-05-19 03:19:05      1
-##  2 144     Registration       r6 - r7 144     comple… 2017-05-19 05:09:47      2
-##  3 144     Triage and Assess… r2 - r5 644     start   2017-05-19 23:16:49      3
-##  4 144     Triage and Assess… r2 - r5 644     comple… 2017-05-20 12:48:08      4
-##  5 144     X-Ray              r7 - r5 1548    start   2017-05-21 10:16:14      5
-##  6 144     X-Ray              r7 - r5 1548    comple… 2017-05-21 14:27:23      6
-##  7 144     Discuss Results    r1 - r6 1878    start   2017-05-25 03:47:56      7
-##  8 144     Discuss Results    r1 - r6 1878    comple… 2017-05-25 05:53:21      8
-##  9 144     Check-out          r1 - r2 2373    start   2017-05-25 11:35:23      9
-## 10 144     Check-out          r1 - r2 2373    comple… 2017-05-25 13:10:05     10
+##  1 484     Registration       r4 - r7 484     start   2018-04-22 13:40:27      1
+##  2 484     Triage and Assess… r6 - r4 984     start   2018-04-22 16:18:42      2
+##  3 484     Registration       r4 - r7 484     comple… 2018-04-22 16:18:42      3
+##  4 484     Triage and Assess… r6 - r4 984     comple… 2018-04-23 06:52:27      4
+##  5 484     Blood test         r3      1232    start   2018-04-24 22:03:51      5
+##  6 484     Blood test         r3      1232    comple… 2018-04-25 01:24:25      6
+##  7 484     MRI SCAN           r2 - r6 1469    start   2018-04-25 04:50:02      7
+##  8 484     MRI SCAN           r2 - r6 1469    comple… 2018-04-25 08:06:00      8
+##  9 484     Discuss Results    r7 - r1 2218    start   2018-04-25 18:47:12      9
+## 10 484     Check-out          r2 - r1 2713    start   2018-04-25 22:21:00     10
+## 11 484     Discuss Results    r7 - r1 2218    comple… 2018-04-25 22:21:00     11
+## 12 484     Check-out          r2 - r1 2713    comple… 2018-04-26 01:01:25     12
 ## # … with abbreviated variable names ¹​employee, ²​handling_id, ³​registration_type

 

 
Read more:

diff --git a/event_filters.html b/event_filters.html
index b42f27e..cd57a52 100644
--- a/event_filters.html
+++ b/event_filters.html
@@ -792,8 +792,8 @@ 
Trim to Endpoints

 
patients %>%
     filter_trim(start_activities = "Registration", end_activities =  c("MRI SCAN","X-Ray")) %>%
     process_map(type = performance())

-

-
+

+
 
 

 
Trim to Time Window

diff --git a/frequency_maps.html b/frequency_maps.html
index 5283ff8..09131ed 100644
--- a/frequency_maps.html
+++ b/frequency_maps.html
@@ -728,14 +728,14 @@ 
Absolute

 the end of the case in 4436 times.

 
tmp %>%
     process_map(frequency("absolute"))

-

-
+

+
 
Note that this is the default process map configuration, and is thus
 equivalent to the following.

 
tmp %>%
     process_map()

-

-
+

+
 

 

 
Absolute case

@@ -745,8 +745,8 @@ 
Absolute case

 because of the self-loop on the activity.

 
tmp %>%
     process_map(frequency("absolute-case"))

-

-
+

+
 

 

 
Relative

@@ -756,8 +756,8 @@ 
Relative

 was followed by another Payment.

 
tmp %>%
     process_map(frequency("relative"))

-

-
+

+
 

 

 
Relative case

@@ -766,8 +766,8 @@ 
Relative case

 Payment.

 
tmp %>%
     process_map(frequency("relative-case"))

-

-
+

+
 

 

 
Relative antecedence

@@ -789,8 +789,8 @@ 
Relative consequent

 executions.

 
tmp %>%
     process_map(frequency("relative-consequent"))

-

-
+

+
 

 
Read more:

 

diff --git a/generic_filtering.html b/generic_filtering.html
index 1846506..8060e3b 100644
--- a/generic_filtering.html
+++ b/generic_filtering.html
@@ -920,12 +920,12 @@ 
sample_n

 patients.

 
patients %>%
     sample_n(size = 10)

-
## # Log of 112 events consisting of:
+
## # Log of 108 events consisting of:
 ## 2 traces 
 ## 10 cases 
-## 56 instances of 7 activities 
+## 54 instances of 7 activities 
 ## 7 resources 
-## Events occurred from 2017-02-05 23:01:36 until 2018-01-29 14:14:10 
+## Events occurred from 2017-02-05 23:01:36 until 2018-04-12 21:41:01 
 ##  
 ## # Variables were mapped as follows:
 ## Case identifier:     patient 
@@ -935,20 +935,20 @@ 
sample_n

 ## Timestamp:           time 
 ## Lifecycle transition:        registration_type 
 ## 
-## # A tibble: 112 × 7
+## # A tibble: 108 × 7
 ##    handling     patient employee handling_id regist…¹ time                .order
 ##    <fct>        <chr>   <fct>    <chr>       <fct>    <dttm>               <int>
 ##  1 Registration 33      r1       33          start    2017-02-05 23:01:36      1
-##  2 Registration 44      r1       44          start    2017-02-19 04:38:51      2
-##  3 Registration 64      r1       64          start    2017-03-09 14:27:30      3
-##  4 Registration 105     r1       105         start    2017-04-21 02:19:09      4
-##  5 Registration 133     r1       133         start    2017-05-11 18:15:57      5
-##  6 Registration 166     r1       166         start    2017-06-13 02:52:24      6
-##  7 Registration 181     r1       181         start    2017-06-25 11:18:08      7
-##  8 Registration 271     r1       271         start    2017-09-24 04:52:06      8
-##  9 Registration 321     r1       321         start    2017-11-04 14:55:02      9
-## 10 Registration 397     r1       397         start    2018-01-21 04:23:48     10
-## # … with 102 more rows, and abbreviated variable name ¹​registration_type

+##  2 Registration 81      r1       81          start    2017-03-30 13:32:50      2
+##  3 Registration 200     r1       200         start    2017-07-15 08:23:12      3
+##  4 Registration 205     r1       205         start    2017-07-19 15:48:14      4
+##  5 Registration 230     r1       230         start    2017-08-13 13:11:31      5
+##  6 Registration 279     r1       279         start    2017-09-27 16:22:38      6
+##  7 Registration 295     r1       295         start    2017-10-14 00:21:58      7
+##  8 Registration 448     r1       448         start    2018-03-04 00:25:10      8
+##  9 Registration 450     r1       450         start    2018-03-06 11:30:03      9
+## 10 Registration 464     r1       464         start    2018-03-20 19:07:17     10
+## # … with 98 more rows, and abbreviated variable name ¹​registration_type

 
Note that this function can also be used with a sample size bigger
 than the number of cases in the event log, if you allow for the
 replacements of drawn cases.

diff --git a/multi_dimensional_analysis.html b/multi_dimensional_analysis.html
index 3d77b29..3a304f8 100644
--- a/multi_dimensional_analysis.html
+++ b/multi_dimensional_analysis.html
@@ -570,7 +570,7 @@ 
Multi-dimensional analysis

 
library(bupaverse)

 
By combining metrics with group_by() and augment, you can perform analysis
+href="augment.html">augment(), you can perform analysis
 that combine multiple perspectives.

 
For example, let’s say we want to compare throughput time
 (performance) with trace length (control-flow). We start by computing
@@ -667,10 +667,10 @@ 
Multi-dimensional analysis

 ## 2 (1,17.9]               2428
 ## 3 (17.9,85.1]            2484
 ## 4 (85.1, Inf]            2521
-

Now, instead of using group_by and n_cases, -we can use group_by followed by trace_length. -This gives us the distribution of the trace length, for each of the -groups.

+

Now, instead of using group_by() and +n_cases(), we can use group_by() followed by +trace_length(). This gives us the distribution of the trace +length, for each of the groups.

tmp %>%
     mutate(throughput_time_bin = cut(as.numeric(throughput_time), breaks = c(-Inf, 1, 17.85, 85.14, Inf))) %>%
     group_by(throughput_time_bin) %>%
@@ -682,7 +682,7 @@ 
Multi-dimensional analysis

 ## 2 (1,17.9]                2     2      2  2.02     2     6  0.237     0
 ## 3 (17.9,85.1]             2     5      5  4.78     5     9  1.28      0
 ## 4 (85.1, Inf]             5     5      5  5.08     5     9  0.417     0
-

This information, we can plot() as well.

+

We plot this new information:

tmp %>%
     mutate(throughput_time_bin = cut(as.numeric(throughput_time), breaks = c(-Inf, 1, 17.85, 85.14, Inf))) %>%
     group_by(throughput_time_bin) %>%
@@ -690,13 +690,13 @@ 
Multi-dimensional analysis

     plot()

While the resulting default plot might not be ideal for your situation -(as here, it doesn’t work well with trace lengths discreet +(as here, it doesn’t work well with trace lengths discrete characteristic), you can get a first insight without needing any additional visualization expertise.

-

Note that, if we turn the analysis the other way around, e.g. what is -the impact of trace length on throughput time, things get even easier, -as the discreet trace length variable can be directly feeded to -group_by.

+

Note that, if we turn the analysis the other way around (e.g. what is +the impact of trace length on throughput time?), things get even easier +as the discrete trace length variable can be directly fed to +group_by().

traffic_fines %>%
     trace_length(level = "case") %>%
     augment(traffic_fines, prefix = "length") %>%
@@ -704,7 +704,7 @@ 
Multi-dimensional analysis

     throughput_time() %>%
     plot()

-

Finally, not that you are not limited to combining calculated +

Finally, note that you are not restricted to combining calculated metrics. You can also combine metrics with data attributes.

eventdataR::hospital %>%
     group_by(group) %>%
diff --git a/mutate.html b/mutate.html
index 18b8256..73c98e6 100644
--- a/mutate.html
+++ b/mutate.html
@@ -654,10 +654,10 @@ 
Mutate logs

 
library(bupaverse)
 library(dplyr)

 
Next to augment() for
-enriching log with calculated merics, you can use mutate()
-to add more custom new variables to a log, or change existing ones. The
-use of mutate() is especially conventient in combination
-with group_by().

+enriching an event log with calculated metrics, you can use
+mutate() to add more custom new variables to a log, or
+change the existing ones. The use of mutate() is especially
+convenient in combination with group_by().

 

 
Transforming variables

 
The code below transforms the lacticacid variable, stored as
@@ -668,9 +668,9 @@ 
Transforming variables

 

 
Calculating variables

 
Below, we group the data by case using group_by_case(),
-and subsequently calculate the total lacticacid value. Note that
-na.rm = TRUE is required as there are missing values for
-this variable.

+and subsequently calculate the total lacticacid value. Note
+that setting na.rm = TRUE is required as there are missing
+values present for this variable.

 
sepsis %>%
     group_by_case() %>%
     mutate(total_lacticacid = sum(lacticacid, na.rm = TRUE)) %>%
diff --git a/organisational_analysis.html b/organisational_analysis.html
index 3e5fb18..8a73f69 100644
--- a/organisational_analysis.html
+++ b/organisational_analysis.html
@@ -708,8 +708,8 @@ 
Handover-of-work network

 process_map function.

 
patients %>%
     resource_map()

-

-
+

+
 

 

 
Resource precedence matrix

diff --git a/performance_maps.html b/performance_maps.html
index 40e1023..c944527 100644
--- a/performance_maps.html
+++ b/performance_maps.html
@@ -656,13 +656,14 @@ 
bupaR Docs | Performance Maps

 

 
Performance profile

 
library(bupaverse)

-
Instead of a frequencies, process maps can also be used to visualize
-performance of the process, by using performance() to
-configure the map, instead of frequency().

+
Instead of a frequencies, process maps can also be
+used to visualize performance of the process, by using
+performance() to configure the map, instead of
+frequency().

 
patients %>%
     process_map(performance())

-

-
+

+
 
There are three different parameters specific to the
 performance() configuration: the aggregation function, the
 time units, and the flow time type.

@@ -674,8 +675,8 @@ 
Aggregation function

 the maximum, for example.

 
patients %>%
     process_map(performance(FUN = max))

-

-
+

+
 
Any function that takes a numerical vector and returns a single value
 can be used. For example, let’s say we want to show the 0.90
 percentile.

@@ -685,36 +686,36 @@ 
Aggregation function

 
 patients %>%
     process_map(performance(FUN = p90))
-
- +
+

Note that the ... is mandatory as -process_map will automatically add na.rm = T +process_map() will automatically add na.rm = T to the aggregation function call.

Time units

-

The units argument allows to specificy the time unit to +

The units argument allows to specify the time units to be used.

patients %>%
     process_map(performance(mean, "days"))
-
- +
+ 
patients %>%
     process_map(performance(mean, "hours"))
-
- +
+

Flow time type

Finally, you can set the flowt_time argument.

There are two different duration types that can be displayed on the -edges.

+edges:

diff --git a/unite.html b/unite.html index 0d077a2..f518db1 100644 --- a/unite.html +++ b/unite.html @@ -567,8 +567,8 @@

bupaR Docs | Unite activities

Unite activities

You can use act_unite() to remove unwanted differences -between activities. For example, consider the sepsis -activities.

+between activities. For example, consider activities from the +sepsis data set.

sepsis %>%
     activities()
## # A tibble: 16 × 3
@@ -590,8 +590,8 @@ 
Unite activities

 ## 14 Release C                        25           0.00164 
 ## 15 Release D                        24           0.00158 
 ## 16 Release E                         6           0.000394
-

We can replace all Release X activities with a single -unique Release activity.

+

We can replace all Release X activities with a single unique +Release activity.

sepsis %>%
     act_unite(Release = c("Release A","Release B","Release C","Release D","Release E")) %>%
     activities()