# A Goal-Driven Evaluation Method Based On Process Mining for Healthcare Processes
## 5 Case Study
### PM Analysis and Generating Answers to Questions  
In this phase, the results of a detailed analysis of the surgery process are presented. Scenarios including PM features were employed using the existing PM tool of Disco; therefore, in this paper, the outputs (map, statistics and case view) of Disco were used to answer the questions. In the PM analysis stage, each question was answered based on the PM features and the answer was quantitatively evaluated via measuring indicators as follows:  
1. How does the process look like? The operational scenario to answer this question shows the general characteristics of the process in terms of process map, statistics, and patterns. It includes two PM features explained below. _Log and Patterns Inspection:_ Disco provided detailed statistics of the process. Table 6 shows that there were 1172 cases and 6299 events under nine main activities; thus, the dataset was relatively small. The timeframe of the data was approximately three months. The average length of hospital stay was five days (12.8 days for groups of A1-A2-A3; 5.1 days for group of B; 3.8 days for group of C; 37.8 h for group of D; and 60 h for group of E). For some cases, however, the process lasted up to 129 days. The greatest relative frequency value belonged to the gynecology department (22%), operation room (for day of surgery) (54%), and cataract surgery (7%). There were 58 process variants and five events belonging to the first process variant. _Process Discovery:_ A process map of the surgery process was created to demonstrate how the process looks (Figure 2). This map was generated by Disco Miner, which is a further developed version on Fuzzy Miner [53]. Fuzzy miner is one of the younger process discovery algorithms and uses significance/correlation metrics to interactively simplify the process model at the desired level of abstraction. The starting point of the process map in the figure is a little triangle on the top, which shows 1172 patients. All the patients started either with \"Admission to Hospital\", the first step of the process, or directly with the \"Surgery Started\" activity. After admission to the hospital, the process is split into four alternative paths. The thicker arrow reflects the most frequent activities; e.g., \"Surgery Started\" activity undertaken by 992 patients after admission. There is no dominant network loop around the activities; only 25 patients were admitted to the hospital again after having been discharged. Ending activities are \"Discharged\", \"Ex\", \"Surgery Finished\", and \"Transfer to a Service\". At the time of the study, 13 patients had not been discharged yet and 1159 patients had completed the surgery process and been discharged. When the activity slider is pulled down to the lowest point, it is seen that there are only five main activities performed. Missing patients may be observed between activities due to the simplified view and the examination of only the most important flows. When the path slider is pulled to the top, all the paths are revealed as shown in Figure 3, and the process map becomes more complicated. 2. What are the most followed paths and exceptional paths? The operational scenario for this question includes two PM features explained below: _Log and Patterns Inspection:_ In the case view of this process, there are 58 different process variants belonging to 1172 individual patients. _Process Variant Analysis:_ As shown in Table 7, the most frequent variants of the surgery process were derived. Variant 1 covers around 65% of the events related to 767 different patients (doctors' varying operations and timestamps) that follow the same path within the average length of hospital stay of two days. The most followed path is the same as in the main process. There are many process variants in terms of traces of the surgery process. Twenty-nine variants (0.09%), having a single patient, follow a distinct path from others. * Where are the bottlenecks in the process?