YAWL4Health

Background

In a competitive health-care market, hospitals have to focus on ways of streamlining their processes in order to deliver high quality care while at the same time reducing costs. Moreover, increasing pressure is being put on hospitals to work in the most efficient way possible given projected increases in demand for hospital care. Consequently, there is a need for technological support in controlling and monitoring healthcare processes for patients and workflow technology is potentially an interesting vehicle for achieving this end.

To this end, many hospitals are investigating the use of a workflow management system in order to provide support for care processes. However, modern workflow management systems significantly fall short in supporting care processes as flexibility is required for its execution. Here we will demonstrate how YAWL can implement a large and representative healthcare process of the Academic Medical Center (AMC), a large university hospital in the Netherlands.

Case of gynaecological oncology

As healthcare process, we studied the diagnostic part of the gynaecological oncology healthcare process. The process consists of around 325 activities and involves patients visiting the gynaecological oncology outpatient clinic of the AMC hospital. The gynecological oncology process studied has been translated into a YAWL model, as seen in Figure 1.

Figure 1 : General overview of the gynaecological oncology healthcare process.

The gynecological oncology process consists of two different processes. But for this demonstration, we will only use the first process, which is modeled in Figure 1. This process deals with the diagnostic process that is followed by a patient when referred to the AMC hospital for treatment, up to the point where the patient is diagnosed. In this process, the patient can have several consultations with a doctor, either via visiting the outpatient clinic or via telephone.

The first section deals with the "referral patient and preparation for first vist" task. Information about the patient has to be gathered. Then by using this information, a decision can be made on the course of action needed for the patient, as seen in Figure 3. Once a decison is made, the worklist of the staff involved is updated with the work items that need to be performed, as seen in Figure 4.

Once this initial stage is complete, the patient can come to the clinic for a consultation. During such a consultation, the status of the patient is discussed and a decision is made about whether examinations and consultations need to be requested, canceled or rescheduled. Moreover, during the course of the process, several administrative activities like giving brochures and registering a patient need to be done. Also, the doctor can request a number of different tests, performed by different specialists.
 
However, it is important to note, that in the future new tests can become available. There can even be new types of medical specialists. In Figure 1, we have included node “examinations”, which is a multiple instance task, for this purpose. In this way, it becomes clear, that in order to cater for varying interaction with medical specialists, an independent subprocess needs to be started for each requested diagnostic test. Taking into account that even new tests can become available we have chosen to connect node “examinations” to the worklet service. In this way, for each test the right worklet can be chosen. In case of a new test, it is possible to choose a corresponding process fragment, or to dynamically define a new process fragment, and thereby extending the ruleset.

The use of the worklet service for the diagnostic tests can be demonstrated in the following way. In Figure 7, we see a screenshot of the ruleseditor which shows graphically and textually the ruleset for when task “examinations” is performed. To be more precise, the ruleset defines under which conditions a certain worklet is chosen. So, in our case, depending on the decision of the doctor the right diagnostic test worklet will be started.

For example, if the doctor selected “MRI”, the radiology worklet will be started and that when the doctor selected “ANAESTHETICS”, the anaesthetics worklet will be started. However, the doctor could decide that a lab test was needed for which currently no rule exists in our ruleset. Therefore, as can be seen in Figure 8, the worklet “defaultDepartment” will be started.

Luckily, the worklet service allows for dynamically adding a rule to the ruleset, so that still the appropriate worklet can be chosen. What we actually want is that the “lab” worklet is started instead of the “defaultDepartment” worklet. In Figure 9 we see the screen in the ruleseditor where we define that the ‘lab’ department needs to be chosen instead and in Figure 10, we see the updated ruleset for task “examinations”. Finally, in Figure 11, we see that workitems for the “defaultDepartment” worklet are replaced by those for the “lab” worklet.

Figure 11 : Work items for the "DefaultDepartment" worklet are replaced by the work items for the "lab" worklet.

Clearly, we have seen that the gynaecological oncology healthcare process is a care process in which complex care needs to delivered. Moreover, in this care process, multiple departments are involved and the number of diagnostic tests chosen varies due to multidisciplinary affairs. The healthcare process can be supported by using YAWL because of the tool's flexibilty and ability to change for the needs of the user.