RTLS-based Process Mining: Towards an Automatic Process Diagnosis in Healthcare
This article is an extract from the paper that has been presented by the AGILEA’s team; to the IEEE International Conference on Automation Science and Engineering (IEEE CASE 2015), in August 2015 (Sweden).
General context for hospitals
Today, hospitals are confronted to the necessity to focus their energy on improving their process. Beyond the efficacy that must be imperative, hospital processes must become efficient and relevant. As a result, more and more improving approaches are launched with process focus often inspired by industrial methods .(lean hospital, process management, continuous improvement…).
Recently, Toulouse Hospital has decided to redesign an outpatient clinic in order to mutualize the 11 consulting services of 6 medical specialties; urology, nephrology, plastic surgery, digestive surgery, gynecology and anesthetic consultations related to these surgery specialties.
Main characteristics of this mutualized consulting center are:
- 75 000 patients per year
- 90 doctors, 50 nurses and nursing auxiliaries, 15 administrative agents
- 300 potential medical paths for the patients (without in/out administrative processes)
This consulting process is therefore a complex system.
So, analytical methods are inadequate when seeking to monitor and anticipate performance of this process. Human (serious games) or software tools based on simulations are relevant tools to support design phase of this project.
However, processes have to be described qualitatively and quantitatively before being improved. And this description may be laborious with hundreds hours of manual observations and stakeholders interviews.
Especially, these efforts are not automatically synonymous of three critical dimensions: completeness (representativeness), reliability and usability.
The two first are imperative for the success of improving approach.
In addition to reliable results, they allow confident intentions from medical and paramedical staff who are mostly defiant toward engineering methods in hospital environment. In the next step, simulation should be used with pedagogic and conviction purposes in order to succeed in changing management.
Usability is essential toward the considerable labor required to prepare then to exploit the amount of data (manually) collected. Establishing link between process mapping and statistical analysis is time consuming and subject to error.
The weakness of this classical approach is its inherent incapacity to acquire a meaningful part of accessible knowledge about the process. In Toulouse Hospital, the approach has called up 2 engineers during 3 months. However, processes have been observed and measured during a little part of this period with extreme difficulties to cover the whole patient path at any moment.
Often, it is impossible to rebuild Key Performance Indicators such as length of stay, added value ratio (care or inevitable administrative activities) and human or material resources utilization…
Process Mining clearly appears as a good solution to support continuous improvement of complex and continuous (24/24) hospital processes.
Process Mining is a method enabling to automatically model the process thanks to a log file . Furthermore, it could be a relevant tool in diagnosis phase and also to monitor activities.
As we can see in literature, Process Mining presents advantages such as numerous (and fast) input data treatment, automatic process modeling and output data enabling an accurate diagnosis. However this tool required an adapted log file: that is to say having enough representative events collected.
The problem is that it is really complicated and time consuming to manage to manually get a correct log file and model the corresponding process. Currently more and more data is available in hospital IT systems. Therefore we can extract log files from IT systems in order to use Process Mining.
It could appear quite simple to directly use the extracted file as an input for a Process Mining tool, however an analysis step is necessary.
In this study, we will deal with real cases where we used Disco®; a Process Mining software, in order to highlight the main issues discovered for getting a complete and a correct log file.
Why manual data gathering is not relevant for organizational diagnosis in healthcare environment?
Firstly, in many cases, the stakeholders manually write information about events in the database. They write each time they clock in the corresponding activity name. However after the extraction, there were more than 10 syntaxes in the log file for each activity.
This problem needs a long time in order to gather all these syntaxes and change it in the log file. Secondly, if the clock in is done manually, there are some timestamps non informed.
So for these events, we must delete the entire event otherwise information about duration will be totally wrong .(e.g. for Disco®; if there is nothing for a timestamp, it is the year 0, so the activity duration is more than 2000 years…).
But the modeling given by Process Mining will be less representative if there is some data missing.
In other cases, some activities are not recorded by the IT system. In this case too, the process will be not totally representative. A solution could be to manually change and validate the events in the log file, but it is time-consuming. As regards timestamps, there are often not accurate enough. In lots of cases, data is only recorded by increment of 1 day.
As a result with the log file, an activity that lasts for example three hours has the same timestamp (because it is the same day). With Disco® the activity is modeled as instantaneous. Or worse, if the activity is done between 11:55 pm and 00:05am, it is recorded as two different days so the activity lasts 1 day for Disco®.
Furthermore when files are extracted, there are often events stuck in IT system or events without timestamp that have a date automatically written such as “00/00/0000“ or “01/01/1901“.
A filtering step is unavoidable to remove events with this kind of timestamp.
It is long with often more than one hundred thousand events in the file and the process is also less representative from the reality. Another difficulty often found in log files deals with an incomplete extraction from the IT system. Indeed there are often references missing, all the activities in the scope of study are not extracted… Therefore if the analysis is already done, it has to be done another time with a complete file.
We have just seen that it is not the best way to get manually a log file, and when we manage to extract directly from the IT system a log file, there are always mistakes or traps. The hypothesis here is to own an IT system able to record events and to export this data. That is not (or rarely) true in hospital complex. In our case we do not have a log file dealing with patient pathways.
Our proposal: Mixed use of RTLS and Process Mining systems
In this study, we propose to use Real-Time Location System (RTLS) to automatically collect event data and create log files (figure 1) rather than using a combination of existing data sources and manually entered status updates.
Patient location in a hospital complex has numerous advantages (but also some risks, as all systems enabling to locate people geographically). Most of time safety is highlighted in order to justify using this type of system. Locating in real-time an infant in a maternity, an elderly patient suffering from Alzheimer disease in a gerontology service, a complicated or dangerous patient in a psychiatric service is a purpose researched by the whole hospital complex to guarantee patient and personnel safety.
RTLS systems sold often highlight this argument.
Using such systems in order to help to model patient pathways with a diagnosis goal is really less widespread . Indeed beacons getting signals broadcast by tags are intended to be installed permanently (e.g. fixed on walls). When the system is used for As-Is diagnosis, the installation must be temporary (from a few days to a few weeks). It must also be easily set up and taken off without deterioration.
In this study we deal with an experiment we are realizing in the Toulouse university hospital. Our proposition includes an As-Is Business Process Modeling step: data must be collected in order to analyze patient pathways.
For each patient the chronological sequence must be modeled, whether it is administrative, waiting, medical or paramedical activities. For each activity location, human resources, starting and finishing timestamp must be recorded.
As explained in one of the previous chapter, this work done manually is time-consuming, can be misinterpreted and limited to a small group of patients that is not representative. The model should be incoherent and imply a wrong diagnosis and inappropriate solutions.
That is why we have set up a mobile RTLS enabling to collect patient pathways data under a log file format (with events log).
These events include an ID (the tag worn by the patient), starting and finishing timestamps and the corresponding activity.
RTLS currently used is supplied by Purelink (www.purelink.ca) with a RFID-UWB technology.
After positioning and calibrating the different RTLS receivers and antennas thanks to the computer engine, the next step is to locate on the map the activity areas corresponding to the different places where a patient is taken care of or await.
Figure 2 shows the area locations in an existing urology outpatient clinic:
1 waiting room, 3 diagnosis rooms, 7 consultation boxes, 1 uroflowmetry room and 1 announcement consultation room.
Figure 3 represents 9 activity areas defined for the experimental place with “Fundamental“ application by Purelink.
These 9 areas are similar to the activity areas in the existing urology outpatient clinic; (1) registration waiting room, (2)(3) registration #1 and #2, (4) Urology waiting room; (5) Notification room, (6) Consultation room, (7) Flowmetry room, (8) Discharge queue and (9) Discharge office.
Then we must declare into the software the event rules, when a tag enter or go away an area: in our case study we need both.
That means each time a patient enter or leave an area an event is recorded with the corresponding ID and activity. Figure 6 shows a part of a log file obtained. (raw 1 = Event ID, raw 2 = timestamp, raw 3 = entry or exit; raw 4 = user message, raw 5 = Tag ID, raw 6 = patient name).
In order to collect this data, each patient is given a tag as soon as he comes to the office desk and the tag is brought back when he leaves. This is the only manual task to realize, as location data recording is automatically done and imperceptible for personnel or patients.
Recording duration can vary from one to several days according to the admission number and the variability of these admissions. In comparison with a manual record, RTLS has a lot of advantages; we can simultaneously follow as many patients as there are tags; the tag is unnoticeable for the patient who forgets it rapidly; as tag is unnoticeable for patient, his behavior is less affected (rather than having someone following him).
As soon as we get a representative log file, we can use Process Mining to get statistics and a process view such as the figure 4.
This view is got from the Table 1 (log file) and automatically analyzed with Disco®. As shown in the picture, we notice that “urology waiting room“ is the nerve center in the process with numerous links with other activities.
Another observation enables to see that the “Registration #2“ was only used once contrary to the “Registration #1“ used 5 times. It may suggest analysing and seeing why there is such a difference.
However we would need more data from more patients to get a representative log file. We have only 6 patients followed here in this experimental phase. That is why a complete diagnosis cannot be proposed. The issue of this study was not to get a complex log file but to show feasibility of this complete approach.
