In order to address particular needs from the healthcare domain, the open-source YAWL Work ow Management System (WfMS) has been extended with features for scheduling support and inter-work ow support, the YAWL4Healthcare WfMS. As part of this undertaking, a WfMS development approach has been followed in which the same conceptual model is used for specifying, developing, testing, and validating the operational performance of a new system. In this paper, we elaborate on the features of YAWL that were essential for realizing our development approach.
Nowadays, hospitals are investigating the introduction of a Work ow Management System (WfMS) in order to support their care processes. However, due to the complex nature of healthcare processes, these systems need to be enriched with additional functionality. Furthermore, the introduction of new technology requires a seamless integration with running operational processes and no unexpected break-downs may occur.
For ensuring above mentioned aspects, as shown at the bottom of Figure 1, we propose a WfMS development approach consisting of ve phases. First, in the requirements phase, the required functionalities are identi ed. Second, during the design phase, a conceptual model is developed which is a formal, complete, and executable speci cation of the WfMS to be developed. Subsequently, the WfMS is developed in the implementation phase. Finally, during the testing and simulation phase, the conceptual model and the operational WfMS are used to both test and validate the operational performance of the WfMS.
The conceptual model has been de ned in terms of a Colored Petri Net
(CPN) [
WfMS development process
Problem functionality YAWL Workflow
Engine A
B A
B Resource Service X A
B X
Worklet
Service Requirements phase A
B Resource Service Design phase
Inter-Workflow Service YAWL Workflow
Engine A
B
X A
Worklet
TO-BE Solution Java application Interaction
Workflow
Client Application
B 1A
1B
B Adaptor (Axis 2 service) Outlook 2003 clients
WfMS: YAWL Implementation phase
Testing phase
Current + additional functionality YAWL custom B service Interaction Service 3 2
Scheduling service Axis 2 service
4 Calendars Java interface 4 Microsoft Exchange Server 2007
Simulation phase (operational
performance)
Conceptual model: Colored Petri Nets
When applying the development approach, in the requirements phase it has
been identi ed that for optimally supporting healthcare processes, WfMSs need
to be extended with facilities for both scheduling support and inter-work ow
support [
YAWL4Healthcare o ers both scheduling support and inter-work ow support. In this section, both facilities are discussed in detail and it is indicated which features of YAWL were essential for realizing them.
With regard to scheduling support, instead of only o ering a workitem to a user via a worklist, it also needs to be possible to make an appointment for a workitem. This appointment has a speci c duration and only appears in the calendars of these users that are involved in the execution of the workitem. The main scheduling features will be illustrated using a small scenario. The process de nition speci ed in the YAWL editor can be seen in Figure 2a. The \physical examination" and \consultation" tasks are annotated with a calendar icon as for both an appointment is needed. Moreover, they are called schedule tasks. Via the \extended attributes" feature of the editor, additional attributes are de ned for them. These attributes are also illustrated in Figure 2a in which for the \physical examination" it is de ned that the presence of the patient is required during a) Defining a model in the YAWL editor. For tasks annotated with a calendar icon an appointment is needed whereas for tasks annotated with a single person icon this is not needed. b) The details for the ‘physical examination’ task are defined via the extended attributes feature of the editor. c) State of the calendars after scheduling. The calendars of assistant ‘Jane’, assistant ‘Fred’, doctor ‘Marc’, doctor ‘Nick’, and patient ‘John’ are shown respectively. When scheduling the availability of resources is taken into account. the appointment (caseResource), the average duration of the appointment is 30 minutes (duration), an assistant and a nurse are required during the appointment (roles), and the task is a schedule task (type). The tasks for which workitems need to be o ered via a worktray are called ow tasks and are indicated by a person icon. Also, for this kind of task, additional information is de ned via the \extended attributes" feature of the editor (e.g. the average duration).
Once an instance of a process is started, appointments are automatically booked in the calendars of these persons that are involved in the execution of a schedule task. This is shown in Figure 2b in which an appointment is booked for the \consultation" task which appears in the calendars of doctor \Nick" and patient \John". Also, an appointment is booked for the \physical examination". Note that the system ensures that the nal scheduling of tasks occurs in the same order as the sequence of schedule tasks in the accompanying process de nition for the case. Moreover, su cient time is reserved between two scheduled tasks. In case it is found out that too little time is left for performing preced3 ing work-items for a scheduled schedule task, the corresponding appointment is automatically rescheduled. Also, users are able to express their dissatisfaction with the nominated scheduling by requesting: (1) the rescheduling of the appointment, (2) the rescheduling of the appointment to a speci ed date and time, or (3) the reassignment of the appointment to another employee.
In order to o er scheduling facilities (see Figure 1), YAWL has been extended with three components. The Calendars component provides a view on the calendars of users and allows for manipulating them. Based on the calendars, the Scheduling Service component provides the scheduling facilities to the WfMS. The workitems and any appointments for them can be seen via the Workow Client Application. The \Calendars", \Scheduling Service", and \Work ow Client Application" components have respectively been realized by developing a java service, using Microsoft Exchange Server 2007, and using Outlook 2003 clients. Via a speci c adaptor, communication takes place between the YAWL work ow engine and the \Scheduling Service" and the \Work ow Client Application". Moreover, in this way, only Interface B is needed for communication with the engine, i.e. starting and canceling instances, and the checking in and out of workitems. Note that the scheduling algorithm used by the Scheduling Service can easily be replaced by another algorithm, i.e., it is pluggable. Currently, a \naive" algorithm is implemented which searches for the rst opportunity in which one of the resources of a role can be booked for the respective work-item.
The need for inter-work ow support emerged from the fact that the
process of treating a patient typically consists of many smaller interacting work ow
fragments that run in conjunction with each other. These fragments may also
operate at di erent levels of granularity. The main inter-work ow support features
will be illustrated using a small scenario. Note that these features are based on
the Proclets framework [
cution is delegated to the Inter-Work ow service (see Figure 3b). Additionally, information about the involved entities is exchanged via the \entities" variable.
In order to o er inter-work ow support (see Figure 1), YAWL has been extended with the Inter-Work ow Service. The \Interaction Service" is responsible for the interactions between fragments at run-time and has been set-up as a YAWL custom service. As such, it communicates with the YAWL engine via Interface B. The \Interaction De nition Editor" o ers tools for de ning interactions between fragments at both design-time and run-time.
So, it can be concluded that the service oriented architecture of YAWL was of great help for realizing the desired extensions. That is, via the extended attributes feature of the editor, additional attributes of a task that need to be lled in, could easily be de ned. Furthermore, due to the fact that the YAWL engine is agnostic to its external services, it was possible via a single interface (Interface B) to focus only on implementing the functionalities that were needed for the desired scheduling support and inter-work ow support. So, we did not need to bother about basic work ow management functionalities as they were already provided by YAWL itself (e.g. a work ow engine and process editor). 3
As illustrated in Figure 1, the conceptual model developed using CPN Tools has been used for both testing and validating the operational performance of the implemented YAWL4Healthcare WfMS in respectively the testing and simulation phase. In Figure 4 it is schematically depicted how this has been realized.
The CPN conceptual model provides a complete, formal description of the functionality of the system. As this model is executable, it also serves as a prototype implementation of the system. So, in the testing phase, one or more parts of the CPN model can be replaced by the concrete implementation of these parts. So, in the gure, the light grey-colored rectangle represents the parts of the actual system that are tested. This is done by establishing connections between the CPN model and parts of the actual YAWL4Healthcare WfMS which need to be tested. During the testing, parts of the system, which are not tested, may be simulated using CPN Tools (the dark grey-colored rectangle). This allows for the testing of numerous scenarios facilitating the discovery of potential aws in both the architecture and the corresponding implementation.
In the simulation phase, our focus is on investigating the operational
performance of processes that are supported by both the designed and realized
system. Here we can bene t from the fact that CPN models can also be used for
simulation-based performance analysis in order to evaluate systems and to
compare alternative con gurations of a system [
At the time the above mentioned approach was applied, the \Inter-Work ow Service" was not developed yet. So, in the conceptual model, we only had comTesting phase Simulation phase CP Net model simulation for the part of the system that is not tested
CP Net model simulation model + reference environment part of the system that is not tested
YAWL4Healthcare replaced parts part of the system that is not used for simulation-based performance analysis
YAWL4Healthcare ponents for the \Work ow Engine", \Work ow Client Application", \Calendars", and \Scheduling Service". In the testing phase, we could easily replace the scheduling service and both the work ow engine and scheduling service by their implemented YAWL4Healthcare counterparts. Furthermore, the engine was provided with a simple process de nition. Also, four users where created in the \Work ow Client Application" together with the associated empty calendars in the \Calendars". Amongst others, 6 errors were identi ed in the \Scheduling Service" component and 6 errors were identi ed in the adaptor component. In the simulation phase, also both the \Work ow Engine" and \Scheduling Service" were replaced by their implemented counterparts. Furthermore, the engine was provided with a gynecological healthcare process such that a series of simulation experiments could be carried out in which 143 patients followed the process. For the schedule tasks, the corresponding appointments were made by our system. Therefore, the calendars of the simulated system were lled with appointments, etc. to mimic the true availability of the medical sta . As a result it was possible to explore di erent scenarios. For example, in one of the experiments we simulated the situation that the appointments for a CT, MRI, and pre-assessment are scheduled on the same day. This resulted in a considerably increased waiting time for both the pre-assessment and examination under anesthetic appointments.
Similarly, as in Section 2, also here we bene ted from the service-oriented architecture of the YAWL WfMS. Due to Interface B, components in the conceptual model could easily be replaced by their implemented counterparts. 4
In this paper, we focussed on the role of YAWL in a development approach in which the same conceptual model is used during the design, implementation, testing, and simulation phase. By applying this approach, YAWL has been extended with facilities for scheduling support and inter-work ow support.
As part of this undertaking, we greatly bene ted from the service oriented architecture of YAWL. As it turned out, this provided a powerful point of extensibility, allowing for the extension of the engine with additional desired functionalities. Moreover, it allowed for the applicability of our development approach in which there is a tight coupling between the conceptual model and the YAWL4Healthcare WfMS. While testing and validating, parts of the system may be simulated while connected to the actual system components.