Event logs

Hi, and welcome to this lecture on event logs. In this lecture, I would like to explain to you what an event log looks like, and what data we need for process mining. So we continue with the simple example of a patient treatment process that we’ve shown you in the previous lecture. And while executing this process, we will fill a table using these columns. So when a patient arrives for a first consult, we write a record in this table, saying that patient Bob had his first consult with Dr. Anna in January, 2017 at a quarter past 11. Well, Dr. Anna prescribes three more tests, and these were executed in this order on these dates.

And for some, you have some extra notes, describing some of the details. Next, we have a second consult, also performed by Dr. Anna. And in this case, we go to surgery by Dr. Charlie. And there’s a final consult, again with Dr. Anna, at the end of January. So now you see, that by executing this simple process, we can actually record certain events taken place. So using this data, what data do we actually need to be able to do process mining? Well we need the what. What happened, when, and for who? In this case, a patient. These three columns are crucial for process mining. What happened, when, and for which case, in this… or for who?

Additionally, you can also record, by who. So who performed this activity? And you can have extra data columns being added text, or numeric columns, describing all the attributes that you would like to include in your process analysis. But these three, or actually four, columns can be used natively by process mining. However, in process mining, we have a case oriented view. So for example, if your data contains… looks like this, it contains several patients. What we do is we pull out all the events that occurred for one patient, one case. So, for instance, on this data, we could extract a Bob case, with the first consult by Dr.

Anna, then a blood test by the lab, and a Sarah case, first consult, and then an x-ray scan. So the event data contains cases. Event data is often recorded or eventually stored in the XES data standard. You don’t have to know much about it, I’ll show you in a later lecture how you can convert from a table to the XES. But just for your convenience, it might be good to know some of the terms that we will use in the XES standard. And I will repeat them in later lectures. So a case, we actually call a trace, because it’s actually a trace of events.

And every row in the table, so the what happened when and for who, is becoming an event. So the first consult in January was an event, and the blood test is an event. Similarly, the x-ray scan is also an event. For every event, we have the activity. So what happened? And this is stored in the concept name. So the name of this concept, or the name of this event, is what we call an activity. And for example, the first consult is such a concept name.

We also record a resource, in the ‘org:resource’ attribute

and a time in the ‘time:timestamp’ attribute So whenever you see these attributes, they relate to the activity resource or timestamp. And finally, where do you get this data? And we will discuss that often in this lecture. There are several sources where you can get the data. For instance, hospital information systems, from the electronic health records, or from the appointments data, you can extract what happened and when, and often also for which patient, also the patient information. But mainly the financial information is, of course, very well up to date of what happened when, for which patient. But also laboratory or imaging databases can be used to extract event data. But more on this in later lectures.

So I hope you now have a clear idea of what is required to do process mining. And in the next lectures, we will show you what you can do with process mining and where to get this data. I hope to see you again soon.