In healthcare, processes concerning the diagnosis and treatment of patients can be best characterized as weakly-connected interacting light-weight work ows where tasks reside at di erent levels of granularity. Moreover, in hospitals many workitems are linked with appointments. To date, Work ow Management Systems (WfMSs) fall short in supporting healthcare processes as no scheduling support and interwork ow support is o ered. To address these problems, we present the YAWL4Healthcare WfMS which supports the seamless integration of unscheduled ( ow) and scheduled (schedule) tasks and which allows for dividing complex entangled processes into simple autonomous fragments that may cope with di erent levels of granularity. Note that our system has been realized by adding signi cant extensions to the open-source YAWL WfMS.
In healthcare organizations, many complex are undertaken. Here, Work ow Management Systems (WfMSs) are interesting as, based on process de nitions, they are able to manage the ow of work such that individual workitems are done at the right time by the proper person.
However, in order to identify the limitations for applying work ow
technology in the healthcare domain we have performed a large case study in which
a representative healthcare process of the AMC hospital in Amsterdam, The
Netherlands, has been implemented in multiple WfMSs [
First, contemporary WfMSs o er workitems to users via speci c worklists. Users select the workitems they will perform without having a schedule in mind. However, in hospitals, many workitems are linked to appointments. Moreover, for these appointments enough time needs to be reserved in which they can be performed in order to prevent the need for rescheduling. Unfortunately, current WfMSs do not provide support for the calendar-based scheduling of workitems such that they are performed by one or more resources and at a speci ed time.
Second, the process of diagnosing or treating a patient typically consists of the execution of a number of smaller work ow fragments that run in conjunction with each other. Although these fragments execute independently from each other, a certain \magnetic force" exists between them, i.e. these fragments interact with each other. Additionally, these fragments need to cope with di erent levels of granularity. For example, a doctor may decide during a rst visit of a patient that a lab test is needed, the patient needs to be discussed during a multidisciplinary meeting, and that the results of the latter two need to be available for the second visit of the patient. To date, contemporary WfMSs only support monolithic processes and do not o er support for weakly-connected interacting lightweight work ows which can cope with di erent levels of granularity.
In order to deal with the two above mentioned shortcomings, we have focused
on the general problem of how WfMSs can be extended with facilities for both
scheduling support and inter-work ow support [
In this section, the YAWL4Healthcare system will be discussed in detail. First, we focus on the provided scheduling and inter-work ow support. Next, we focus on the architecture of the system. 2.1
The main scheduling support features will be illustrated using a small scenario for which the corresponding process de nition is shown in the YAWL process editor in Figure 1a. As for the \physical examination" and \consultation" tasks a concrete appointment is needed they are annotated with a calendar icon. Moreover, they are called schedule tasks. The tasks annotated with a person icon are called ow tasks and workitems for them are o ered via an ordinary work-list. Moreover, with regard to the scheduling of appointments, for each task its duration is indicated and the \roles" attribute de nes the role for each resource that is required to perform the task. For schedule tasks it can also be indicated whether the patient is required to be present.
Assume that an instance of the process has been started and that it has been indicated that the availability of patient \John" needs to be taken into account. As a result, as can be seen in Figure 1, an appointment is booked for the \physical examination" task which appears in the calendars of patient \John", assistant \Jane", and nurse \Sue" and an appointment is booked for the \consultation" 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. Moreover, the ‘physical examination’ task needs to be done by both an assistant and a nurse whereas the ‘consultation’ task only needs to be done by a ‘doctor’. b) State of the calendars after scheduling. The calendars of patient ‘John’, assistant ‘Fred’, assistant ‘Jane’, doctor ‘Marc’, and doctor ‘Nick’ are shown respectively. When scheduling the availability of resources is taken into account. task which appears in the calendar of patient \John" and doctor \Nick". 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 preceding work-items for a scheduled schedule task, the corresponding appointment is automatically rescheduled. Also, a user can trigger the rescheduling of a task. 2.2
Our extensions for augmenting YAWL with inter-work ow support are based on
the Proclets framework [
Proclet instances interact via channels. A channel can be used to send a performative (a speci c kind of message) to one Proclet instance or a group of Proclet instances. Proclet classes are connected to channels via ports. Each outgoing port is connected with exactly one incoming port called an external interaction. Furthermore, every port is connected to one interaction point representing a speci c point in a Proclet class at which interactions with other Proclet classes may take place. Furthermore, for an interaction point having only incoming ports, it may be desired that the receipt of an individual performative is followed by the subsequent sending of a performative at a later point in the execution of that Proclet instance. In that case, two interaction points are connected via an internal interaction.
visit 1,1 performative lab 1,1
At run-time, for a certain entity (e.g. a patient or a lab test), interaction points allow for easily nominating interactions with existing and future Proclet instances. That is, for a task instance which is linked with an interaction point which has only outgoing arcs, it is automatically identi ed which potential interactions with existing and future Proclet instances are possible. Afterwards, the desired interactions can be nominated. For each entity these interactions are saved in an interaction graph (Figure 3b). For example, assume that for patient \Sue" it is decided during the \decide" task of the rst visit, that a next visit is necessary, a lab test is required, and that she needs to be discussed during a multidisciplinary meeting. Finally, the result of the lab test and the multidisciplinary meeting need to be available for the second visit. The rst part of this scenario is de ned in the interaction graph of Figure 3. The \decide" task is represented by the \visit,69,decide" node, the creation of the second instance of the \visit" fragment by the \visit,-63,createCondition" node, the creation of the lab fragment by the \lab,-62,createCondition" node, and the registration for the multidisciplinary meeting by the \mdo meeting,70,register" node. Note that for the \visit,69,decide" node it is automatically calculated that the aforementioned interactions are possible. 2.3
In Figure 4 the architecture of our system is shown. The main components are the following.
{ The Work ow Engine is the 'core' of the system and takes care of the routing of cases. The engine is realized by using the YAWL WfMS. { For a task that becomes available for execution, the corresponding work item is communicated to users via the Work ow Client Application. This component is realized using Outlook 2003 clients. { The Scheduling Service is responsible for providing scheduling facilities to the WfMS. This service has been realized as a Java service which communicates with the Work ow Engine and the Calendars component via SOAP messages. { The Calendar component is responsible for providing a view on the calendars of users and for manipulating their contents. Here we selected Microsoft Exchange Server 2007 as the system for storing the calendars of users. { The Inter-Work ow Service adds the desired inter-work ow support. Here, the Interaction Service is responsible for managing interactions between Proclet instances at runtime and has been set-up as a YAWL Custom Service. The Interaction De nition Editor o ers tools that allow for de ning the remaining aspects of Proclet classes on top of process de nitions that are de ned in the YAWL editor (e.g. interaction points, ports). Additionally, tools are o ered such that at instance level human actors can de ne necessary interactions between Proclet instances. This subcomponent has been implemented as a Java application.
The YAWL4Healthcare WfMS has been developed as a research prototype. So far, we tested the entire system with a number of processes. However, regarding Inter-Workflow Service Java YAWL applica custom tion service Interaction Interaction Definition Service Editor
5 adaptor (Axis2 service)
AXIS2 service
4 Java interface
Microsoft Exchange
Server 2007
Calendars
the scheduling support related components of the system, an approach has been
applied in which the \Work ow Engine" and the \Scheduling service" have been
systematically tested [
For the YAWL4Healthcare system an environment to test and play with the
system is provided via SHARE [