Article Preview
TopIntroduction
In healthcare organizations, such as hospitals, many complex processes are performed which are lengthy in duration. These are concerned with the diagnosis and treatment of patients. Workflow Management Systems (WfMSs) present an attractive vehicle in order to provide support and monitoring for patient processes. Based on process definitions, WfMSs are able to manage the flow of work in these processes such that individual work items are done at the right time by the proper person (van der Aalst & van Hee, 2002; Weske, 2007).
However, a number of difficulties commonly arise when hospitals attempt to automate patient processes. This is because the entire process for an individual patient typically consists of a number of workflow fragments that need to cope with different levels of granularity and that run at different speeds. Moreover, the doctor proceeds in a step-by-step way when deciding about the steps to be taken next. This can be illustrated by the example that is depicted in Figure 1.
Figure 1. Interacting workflow fragments. The arcs show the interactions that need to take place between fragment instances.
Figure 1 shows two possible instances of a patient process. For patient ‘Sue’ the process is as follows. First, she visits the outpatient clinic (the process instance named ‘visit:Sue 25/01’). Here, a doctor decides during the ‘decide’ task about the next step(s) that need to be taken. As indicated by the outgoing arcs, a second visit is necessary (‘visit:Sue 10/02’), a lab test needs to be taken (‘lab:Sue 25/01’), and Sue's case needs to be discussed during a multidisciplinary meeting (MDM) (‘MDM:05/02’). For the lab test the resulting report is needed as input for the second visit. This is indicated by the arc leading from the ‘send report’ task to the ‘receive’ task of the second visit. At the multidisciplinary meeting, multiple patients are discussed individually. For this meeting, patients need to be registered via the ‘registration’ task. Finally, reports are sent out (task ‘send reports’). Note that Sue is registered for the meeting and that the resulting report is necessary as input for the second visit.
For patient ‘Anne’ a similar process is followed. However, note that Anne and Sue are discussed at the same multidisciplinary meeting. So, process instance ‘MDM 05/02’ operates at a different level of granularity (a group of patients rather than a single patient).
Clearly, the entire patient process should be seen as a cloud of standardized workflow fragments for which the ultimate selection of these fragments and the interactions between them is patient specific. Current workflow languages require that the complete workflow is described as one monolithic overarching workflow (van der Aalst, Mans, & Russell, 2009). Consequently, it is hard to describe such a cloud of loosely coupled workflow fragments and all the possible interactions between them.
For delivering the desired support, the Proclets framework (van der Aalst, Barthelmes, Ellis, & Wainer, 2000, 2001) provides an interesting means in order to model and execute patient processes. Proclets are lightweight interacting processes that can be used to divide complex entangled processes into simple fragments and, in doing so, place increased emphasis on interaction-related aspects of workflows. Moreover, fragments may reside at different levels of granularity.