From Task Descriptions via Coloured Petri Nets Towards an Implementation of a New Electronic Patient Record

Transcription

1 From Task Desriptions via Coloured Petri Nets Towards an Implementation of a New Eletroni Patient Reord Jens Bæk Jørgensen 1, Kristian Bisgaard Lassen 1, and Wil M. P. van der Aalst 2 1 Department of Computer Siene, University of Aarhus, IT-parken, Aabogade 34, DK-8200 Aarhus N, Denmark {jbj,k.b.lassen}@daimi.au.dk 2 Department of Tehnology Management, Eindhoven University of Tehnology P.O. Box 513, NL-5600 MB, Eindhoven, The Netherlands. w.m.p.v.d.aalst@tm.tue.nl Abstrat. We onsider a given speifiation of funtional requirements for a new eletroni reord system for Fyn County, Denmark. The requirements are expressed as task desriptions, whih are informal desriptions of work proesses to be supported. We desribe how these task desriptions are used as a basis to onstrut two exeutable models in the formal modeling language Colored Petri Nets (CPNs). The first CPN model is used as an exeution engine for a graphial animation, whih onstitutes an Exeutable Use Case (EUC). The EUC is a prototype-like representation of the task desriptions that an help to validate and eliit requirements. The seond CPN model is a Colored Workflow Net (CWN). The CWN is derived from the EUC. Together, the EUC and the CWN are used to lose the gap between the given requirements speifiation and the realization of these requirements with the help of an IT system. We demonstrate how the CWN an be translated into the YAWL workflow language, thus resulting in an operational IT system. Keywords: Workflow Management, Exeutable Use Cases, Colored Petri Nets, YAWL. 1 Introdution In this paper, we onsider how to ome from a speifiation of user requirements to a realization of these requirements with the help of an IT system. Our starting point is a requirements speifiation for a new Eletroni Patient Reord (EPR) system for Fyn County [10]. Fyn County is one of the 13 ounties in Denmark and is responsible for all hospitals and other health-are organizations in its ounty. We fous on funtional requirements for the new EPR system for Fyn County; speifially, we look at seven work proesses that must be supported. The work proesses over what an happen from the moment a is onsidered for treatment at a hospital until the is eventually dismissed or dead.

2 In the requirements speifiation, these work proesses are presented in terms of task desriptions [18, 19], in the sense of Søren Lauesen. A task desription is an informal, prose desription. An essential harateristi of a task desription is that it speifies what users and IT system do together. In ontrast to a use ase [9], the split of work between users and IT system is not determined at this stage. Task desriptions are meant to be used at an early stage in requirements engineering and software development projets. This means that there is a natural and large gap between a task desription and its atual support by an IT system. To help bridging this gap, we propose to use Colored Petri Nets (CPNs) [14, 17] models. CPNs provide a well-established and well-proven language suitable for desribing the behavior of systems with harateristis like onurreny, resoure sharing, and synhronization. CPN are well-suited for modeling of workflows or work proesses [4]. The CPN language is supported by CPN Tools [27], whih has been used to reate, simulate, and analyze the CPN models that we will present in this paper. Figure 1 outlines the overall approah to be presented in this paper. insights insights insights informal desription requirements model speifiation model implementation Task Desriptions Exeutable Use Cases (EUCs) (CPN + animation) Colored Workflow Net (CWN) YAWL desription of the problem devising the solution Fig. 1. Overall approah. The boxes in the figure present the artifats that we will onsider in this paper. A solid arrow between two nodes means that the artifat represented by the soure node is used as basis to onstrut the artifat represented by the destination node. The leftmost node represents the given task desriptions. Going from left to right, the next node represents an Exeutable Use Case (EUC) [16], whih is a CPN model augmented with a graphial animation. EUCs are formal and exeutable representations of work proesses to be supported by a new IT system, and an be used in a prototyping fashion to speify, validate, and eliit requirements. The node Colored Workflow Net (CWN) represents a CPN model, derived from the EUC CPN, that is loser to an implementation of the given requirements. The rightmost node represents the realization of the IT system itself. In this ase study, a prototype has been developed using the YAWL workflow management system [1]. The vertial line in the middle of the figure marks a signifiant division between analysis artifats to the left and design and implementation artifats

3 to the right. The analysis artifats represent desriptions of the problems to be solved, in the form of speifying the ore work proesses that must be supported by the new IT system. To the left of the line, the fous is on desribing the problems, not on devising solutions to these problems. In partiular, to the left of the line, it is not speified exatly what we want the new IT system itself to do. The arrow between the nodes Exeutable Use Cases and Colored Workflow Nets represents the transition from analysis, in the form of desribing the problem, to design, in the form of devising the solution. It should be noted that we are not advoating any partiular kind of development proess in this paper. Figure 1 should not be read to imply that we are proposing waterfall development. There will often be iterations bak and forth between the artifats in onsideration, as is indiated by the dashed arrows. The ase-study presented in this paper is used to illustrate Figure 1. It has been taken from the medial domain. As pointed out in [22, 23] areflow systems pose partiular requirements on workflow tehnology, e.g., in terms of flexibility. Classial workflow-based approahes typially result in systems that restrit users. As will be shown in this paper, task desriptions aim at avoiding suh restritions. Moreover, the state-based nature of CPNs and YAWL allows for more flexibility than onventional event-based systems, e.g., using the deferred hoie pattern [2], hoies an be resolved impliitly by the health-are workers (rather than an expliit deision by the system). This paper is related to one of our previous publiations [3] where we also apply CPN Tools to model EUCs and CWNs. However, in the earlier work, we onsidered a different domain, namely banking, we did not onsider task desriptions, and we used BPEL as target language instead of YAWL. This paper is strutured as follows: Setion 2 is about task desriptions, both in general and about the speifi task desription we will use as ase study. Setion 3, in a similar fashion, is about Exeutable Use Cases (EUCs). In Setion 4, we desribe the Colored Workflow Net (CWN). Setion 5 onsiders the realisation of the system. Related work is disussed in Setion 6 and the onlusions are drawn in Setion 7. 2 Task Desriptions In this setion, we first present task desriptions in general and then we introdue the speifi task desription related to Fyn County s Eletroni Patient Reord (EPR) that we will fous on in this paper. Finally, we motivate why we move from task desriptions only to EUCs rather than diretly implementing the system. 2.1 Task Desriptions in General In this ontext, a task is a unit of work that must be aomplished by users and an IT system together. A task forms a unit in the sense that after having ompleted a task, it will feel natural for the user to take a break. Tasks may be split into subtasks. An example of a subtask is register.

4 The desriptions of subtasks in a task desription are on the left side of the dividing line in Figure 1. However, a task desription may also ontain proposals about how to support the given subtasks. Solution proposals onstitute desriptions, whih are to the right of the split line in Figure 1. The expliit division into subtasks and solution proposals enfores a strit split between desribing a problem and proposing a solution. With solution proposals, the desription then properly hanges name to a Task and Support desription. A solution proposal for the subtask register ould be transfer data eletronially from own dotor. Variants in task desription are used to speify speial ases in a subtask. Instead of writing a omplex subtasks, [19] suggests to extrat the speial ases in variants, making the subtasks and variants easier to read. 2.2 Task Desriptions for Fyn County s EPR The task desriptions for Fyn County s EPR that we onsider are the following: 1. Request before arrives 2. Patient arrives without prior appointment 3. Reeption aording to appointment 4. Mobile linial session 5. Stationary linial session 6. Terminate ourse of events 7. Patient dies Task desriptions for eah of these seven work proesses are given in [10] (in Danish). In this paper, we will use the task desription for Request before arrives to illustrate our approah. This task desription is translated into English and presented in Table 1. As an be seen, it is a task and support desription. Exept from the translation from Danish to English, the task desription is presented here unhanged (whih explains the presene of question marks and other peuliarities).

5 Table 1: Task desription: Request before arrives Task 1: Request before arrives Establish episode of are or ontinue the establishment proess if it had been parked or transferred. The request an involve a linial session where the episode of are is refined before the arrives. Start Request from the s pratitioner, speialist dotor, other hospital, or authority. Request an also be supplementary information that were missing previously, or when the task was transferred to another person (e.g. from the seretary to the dotor). End When the episode of are is established/adjusted and the alled in or added to the waiting list. Frequeny Per user:??. For the whole hospital:??. Critial situations Users The seretary is the immediate user, but the task an be transferred to others. Subtask Subtask Solution proposal and variant number 1. Register. (See data desription) Transfer data eletronially from the s dotor, et. (Medom) 1a. Patient exist in system. Update data 1b. Healthy partner must be enrolled?? 1. Personal seurity???? 2. Establish episode of are and register data, i.e., the preliminary diagnosis. (See data desription, inluding support in use of SKS lassifiation.) 2p. Problem: Diverging ode systems and strutures in the eletroni messages. 2a. Episode of are is already established. Data may need to be adjusted, e.g., date of appointment. 2q. Problem: The an onurrently be involved in other episodes of are and be enrolled more plaes and in more departments. It an be hard to get an overview of who has the nursing responsibility and who is providing a bed. Also, there may be a need to see previous episode of are, given that the agrees. Transfer data eletronially from own dotor, et. (Medom) Support the manual transfer of data from the eletroni data form to the system form.

6 3. Possible linial session to plan the episode of are (e.g. if the establishment proess is transferred to a dotor). 4. Print all-up (or other form of all-up). 4a. Patient is transferred to the waiting list 4b. Information is missing and the task is parked with time monitoring 4. The ase is transferred to another, perhaps with time monitoring. 4d. The request is possibly denied. 5. Request interpreter for the time of admission. 2.3 From Task Desriptions to Exeutable Use Cases One of the main motivations behind task desriptions is to alleviate some problems related to use ases. A use ase desribes an interation between a omputer system and one or more external ators. In the sense of Sommerville [25], use ases are effetive to apture interation viewpoints, but not adequate for domain requirements. A task desription typially has a broader perspetive than a use ase, and, as suh, is a means to address domain requirements as well. In a use ase desription, the split of work between users and system is determined. In ontrast, in a task desription, this split of work is not fixed. A task desription desribes what the user and the system must do together. Deiding who does what is done at a later stage. Thus, a task desription an help to avoid making premature (and sometimes arbitrary) design deisions. In other words, a task desription is a means to help users to keep fous on their domain and the problems to be solved, instead of drifting into designing solutions of sometimes ill-defined and badly understood problems. On the other hand, use ases and task desriptions share the salient harateristis that they are stati desriptions: They are mainly prose text (may be strutured or semi-strutured) possibly supplemented with some drawings, e.g., ontaining ellipses, boxes, stik men, and arrows as in UML use ase diagrams. Both task desriptions and use ases may be read, inspeted, and disussed, and in this way, they may be improved. However, both use ases and task desriptions lak the ability to talk bak to the user. Even though they desribe behavior, the desriptions themselves are not dynami and annot be made subjet for experiments and investigations in a trial-and-error fashion. In omparison, prototypes have these properties. A traditional prototype, though, tends to fous on an IT system itself, in partiular on that system s GUI, more than expliitly on the work proesses to be supported by the new IT systems. This has been a main motivation to introdue EUCs as a means to be used in requirements engineering; to provide exeutable desriptions of new work proesses and possibly of their intended omputer support, and in this way, be able to talk bak to the user failitating disussions about both work proesses and IT systems support.

7 3 Exeutable Use Cases (EUCs) In this setion, we first present EUCs in general and then we introdue the speifi EUC related to Fyn County s EPR that we will fous on in this paper. We also onsider how to ome from EUCs to CWNs. 3.1 Exeutable Use Cases in General An EUC onsists of three tiers, as indiated in Figure 2. Insights Tier 3 - Animation User responses Insights Tier 2 - Formal Tier 1 - Informal Insights Domain analysis Fig. 2. Exeutable Use Cases. Eah tier represents the onsidered work proesses that must be supported by a new system. The tiers use different representations: Tier 1 (the informal tier) is an informal desription; Tier 2 (the formal tier) is a formal, exeutable model; Tier 3 (the animation tier) is a graphial animation of Tier 2, whih uses only onepts and terminology that are familiar to and understandable for the future users of the new system. As indiated by Figure 2, the three tiers of an EUC should be reated and exeuted in an iterative fashion. The first version of Tier 1 is based on domain analysis, and the first version of tiers 2 and 3, respetively, is based on the tier immediately below. The formal tier of an EUC may in general be reated in a number of formal modeling languages. We have hosen CPN beause we have good experiene with this language and its tool support, but other researhers and pratitioners may have other preferenes, e.g., other options ould be stateharts [12] or UML ativity diagrams [20]. As was mentioned in Setion 2.3, EUCs have notable similarities with traditional high-fidelity prototypes of IT systems; this omparison is made in more detail in [8]. In [15], it is desribed how an EUC an be used to link and ensure onsisteny between, in the sense of Jakson [13], user-level requirements

8 and tehnial software speifiations. Jakson s division into requirements and speifiations resembles the division into subtasks and solution proposals in task desriptions. User-level requirements and subtasks lie to the left of the dividing line in Figure 1; tehnial software speifiations and solution proposals lie to the right. Like a task desription, an EUC an have a broader sope than a traditional use ase. The latter is a desription of a sequene of interations between external ators and a system that happens at the interfae of the system. An EUC an go further into the environment of the system and also desribe potentially relevant behavior in the environment that does not happen at the interfae. Moreover, an EUC does not neessarily fully speify whih parts of the onsidered work proesses will remain manual, whih will be supported by the new system, and whih will be entirely automated by the new system. An EUC an be similar to, indeed, a task desription. Therefore, Exeutable Use Cases do not neessarily have the most suitable name. The name exeutable use ases was originally hosen to make it easy to explain the main idea of our approah to people, who were already familiar with traditional prose use ases. 3.2 Exeutable Use Case for Fyn County s EPR We have made an EUC that overs all seven task desriptions listed in the beginning of Setion 2.2. The EUC lies stritly on the left-hand side of the dividing line in Figure 1, i.e., the EUC does not inlude solution proposals. In this setion, we will present the part of the EUC that orresponds to the task desription of Table 1. The informal tier of the EUC is the task desription itself. An extrat of the formal tier is shown in Figure 3; this figure presents the CPN model that orresponds to the task desription from Table 1. Note that this is only one of the seven task desriptions for Fyn County s EPR. Thik lines denote the path that the user and system has to omplete to solve the task; i.e. to go from the plae Ready to make appointment to Patient ready for arrival. Solid lines denote subtasks and variants of subtasks. Dashed lines denote added struture to the model to assert that desired interleavings of subtasks/variants are possible. In Figure 4, we outline how the formal and animation tiers are related. At the bottom, we see the formal tier exeuting in CPN Tools. Please note that the shown module of the CPN model ontains seven transitions (the retangles), and that eah of these transitions orresponds to one of the onsidered tasks (f. the list in the beginning of Setion 2.2). At the top is the animation tier in BRITNeY, the new animation faility of CPN Tools. The two tiers are onneted by adding animation drawing primitives to transitions in the CPN model. These primitives update the animation. The animation tier is a view on the state of, and ations in the formal tier. When a transition ours in the formal model it is refleted by updates to the animation tier. Therefore, the behaviors of the two tiers remain synhronized.

9 Ready to make appointment In PATIENT Register (1) Establish episode of are (2) Transfer iinompatiable data (2p) PATIENT Intake Registering Continue 1 Go bak 1 Patient exists (1a) Add ompanion (1b) Seurity (1) Adjust data (2a) Establishing episode of are PATIENT Consilidate plans (2q) Possible linial session (3) Continue 2 PATIENT Go bak 2 Finalize request Print notifiation (4) Transfer to waiting list (4a) Park task (4b) Appointment made Transfer ase (4) Deny request (4d) Patient ready for arrival Out PATIENT Request interpreter (5) Fig. 3. Task 1 modeled in CPN Using the animation tier the user an interat with eah of the seven tasks. Within the animation of eah task, subtasks an be seleted and exeuted. When a subtasks is hosen for exeution, the animation user an see visually what is happening and see whih entities that are involved in ompleting the subtask. In the snapshot shown in Figure 4, the animation visualizes Task 1. It shows that the animation user has hosen to exeute subtasks 1, 3, 4, and is about to exeute Subtask 4a. We also see that Subtask 4a involves a omputer and a seretary.

10 Subtask 1 Subtask 3 Subtask 4 Subtask 4a Fig. 4. Connetion between animation and formal layer In the task desription in Table 1, it was not mentioned, who does what. It is us, the reators of the EUC (software people), who have interpreted the subtasks in this way, i.e., desribed who does what and what a normal exeution of a task is. When showing this animation to the staff at a hospital in Fyns County, we

11 are likely to get more feedbak on our interpretations of their daily work than we ould get with the stati task desriptions only. 3.3 From Exeutable Use Cases to Colored Workflow Nets The EUC we have presented above desribes real-world work proesses at a hospital. When these work proesses are to be supported by a new IT system, of ourse, what goes on inside that system is highly related to what goes on in the real world. In the approah of this paper (f. Figure 1), we make separate models of real-world work proesses at a hospital (the EUC) and the IT system that must support these work proesses (the CWN). This is done to learly distinguish between the real world, on one hand, and the software, on the other hand. This distintion is advoated by a number of software experts, see, e.g., [13]. Not making this distintion may ause serious onfusion. In this way, the CWN we will now present desribes the IT system, and, as we will see, an be used to automatially generate parts of that system. 4 Colored Workflow Nets A Colored Workflow Net (CWN) [3] is a CPN as defined in [17]. Although both the CWN and the formal tier of the EUC use the same language, there are some notable differenes. First of all, the sope of the CWN is limited to the IT system, i.e., only those ativities that are supported by the system appear in the model. Seond, the CWN overs the ontrol-flow perspetive, the resoure perspetive, and the data/ase perspetive [4]. In the ase study of this paper, the EUC overed the ontrol-flow perspetive only, but as we move to the right in Figure 1, it is neessary to inlude the other perspetives as well (if they have not already been inluded). Finally, CWNs are restrited to a subset of the CPN language, i.e., CWNs need to satisfy some syntatial and semantial requirements to allow for the automati onfiguration of a workflow management system [3]. Although a CWN overs the ontrol-flow, resoure, and data/ase perspetives, it abstrats from implementation details and language/appliation speifi issues. A CWN should be a CPN with only plaes of type Case or Resoure. These types are as defined in Table 2. A token in a plae of type Case refers to a ase and some or all of its attributes. Eah ase has an ID and a list of attributes. Eah attribute has a name and a value. Tokens in a plae of type Resoure represent resoures. Eah resoure has an ID and a list of roles and organizational units. The distribution of resoures over roles and organizational units an be used in the alloation of resoures. For more details on CWNs, we refer to [3]. Figure 5 shows the CWN for the task Request before arrives. When omparing this CWN with the EUC CPN shown in Figure 3, several differenes an be observed. First of all, some subtasks shown in the EUC CPN

12 Table 2. Plaes in a CWN need to be of type Case or Resoure olset CaseID = union C:INT; olset AttName = string; olset AttValue = string; olset Attribute = produt AttName * AttValue; olset Attributes = list Attribute; olset Case = produt CaseID * Attributes timed; olset ResoureID = union R:INT; olset Role = string; olset Roles = list Role; olset OrgUnit = string; olset OrgUnits = list OrgUnit; olset Resoure = produt ResoureID * Roles * OrgUnits timed; are not inluded in the CWN beause they will not be supported by the IT system. Subtask 1b (Add ompanion) and Subtask 2q (Consolidate plans) are not inluded beause of this reason. Seondly, Figure 5 inludes more expliit referenes to the resoure and data/ase perspetives. Note that Figure 5 shows three resoure plaes of type Resoure defined in Table 2. These resoure plaes hold information on the availability and apabilities of people. Using the onept of a fusion plae [14, 27], these plaes together form one logial entity. Plaes of type Case hold information on ases. Cases have several attributes suh as name, id, address, birth date, preliminary diagnosis, et. In Figure 5, the relevant attributes are only shown for the task Register, but, for the sake of readability, not shown for all other tasks. One of the advantages of using Petri nets is the availability of a wide variety of analysis tehniques. In CPN Tools it is possible to simulate models and to do state-spae analysis. We have used both failities. For the state-spae analysis we have abstrated from time and olor to asses soundness [4]. Initially, we disovered a minor error (a deadlok beause we did not onnet Subtask 4d properly). However, after repairing this, the CWN was sound. Note that reahability graph of the CWN shown in Figure 5 for one has only 14 nodes and 29 ars, so it is easy to verify its orretness by hand. However, for more ompliated CWNs, automated state-spae analysis of CPN Tools is indispensable to asses orretness before implementation. 5 Realization of the System Using YAWL In [3], it was shown that for some CWNs it is possible to automatially generate BPEL template ode [7]. The Business Proess Exeution Language for Web Servies (BPEL4WS or short BPEL) [7] is a textual XML based language that has been developed to form the glue between webservies. Although it is an expressive language, it tends to result in models that are diffiult to under-

13 resoures Resoure Resoure 2 Resoure [has_role(r,"dotor")] [has_role(r,"seretary")] r Transfer inompatiable data (2p) r [has_role(r,"seretary")] r Establish episode of are (2) Adjust data (2a) Case Ready to make appointment In Continue 1 Intake Registering _out _in Go bak 1 Establishing episode of are Case input (_in); output (_out); ation let val _out = set_att(_in,"patient Name") val _out = set_att(_out,"address") Case val _out = set_att(_out,"patient Id") val _out = set_att(_out,"zipode") val _out = set_att(_out,"city") in _out end; [has_role(r,"seretary")] Register (1) r [has_role(r,"seretary")] Patient exists (1a) r resoures Resoure Resoure 1 Resoure r [has_role(r,"seretary")] Clinial session (3) Continue 2 Case Finalize request Go bak 2 [has_role(r,"seretary")] Print notifiation (4) Transfer to waiting list (4a) [has_role(r,"seretary")] r Transfer ase (4) r r resoures Resoure Resoure 3 Resoure Appointment made [has_role(r,"seretary")] r Patient ready for arrival Out Case Deny request (4d) [has_role(r,"seretary")] Fig. 5. CWN for the task Request before arrives stand and maintain. For example, it is not possible to show BPEL ode to end users (e.g., to visualize management information or to allow for dynami hange [24]). Moreover, BPEL offers little flexibility and no support for the resoure perspetive. 3 Therefore, we deided to use YAWL [1] rather than BPEL. YAWL (Yet Another Workflow Language) [1] is based on the well-known workflow patterns ( [2]) and is more expressive than any of the other languages available today. Beause of its native and unrestrited support of the deferred hoie pattern [2], it is possible to leave the seletion of 3 Note that only reently people started to investigate adding the resoure perspetive to BPEL, f. the WS-BPEL Extension for People (BPEL4People) initiative

14 the next task to the user. This offers more flexibility than BPEL, beause it is possible to define for eah state what tasks are possible without seleting one (in BPEL this is restrited to the inside of a pik ativity [7]). Moreover, YAWL also supports the resoure perspetive (in addition to the ontrol-flow and data perspetives). The language YAWL is also supported by an open soure workflow management system that an be downloaded from Fig. 6. Sreenshot of YAWL editor Given the fat that YAWL an be seen as a superset of CWNs, it was easy to translate the running example from CPN in YAWL. Figure 6 shows the top-level workflow and the omposite task Request before arrives. Although both models look quite different, a fairly diret mapping was possible from the CWN shown in Figure 5 to the YAWL model shown in Figure 6. All plaes of type Case in Figure 5 are mapped onto onditions in YAWL and transitions in Figure 5 are mapped onto YAWL tasks. 4 After mapping the CWNs onto a YAWL speifiation, it is possible to enat the assoiated workflows. Figure 7 shows a work-list and a form generated by YAWL. The left-hand side of the figure shows the work-list of the seretary with user ode seretary4. It shows work-items assoiated to three ases. Eah of these three ases is in the state registering where three tasks are enabled. Therefore, there are 3*3=9 possible work-items. After seleting a work-item related to task register, three work-items disappear from the work- 4 Note that subtasks in Task Desriptions orrespond to transitions in CWNs and tasks in YAWL.

15 Seretary 4 selets a work-item from her worklist and start filling out information of Anne Jansen Fig. 7. Sreenshot of the YAWL worklist and the form assoiated to task register

16 list (the ompeting tasks beome disabled for this ) and seretary4 an fill out a form with data. After ompleting the form there are again nine work-items, et. The realization of the workflow proess in YAWL ompletes the overall approah shown in Figure 1, i.e., we moved from informal task desriptions, then to EUCs, after that to CWNs, and finally realized the task desriptions in terms of YAWL. Note that, given the availability of a running YAWL system and a CWN, it is possible to onstrut a running system in a very short period, e.g., in a few hours it is possible to make the proess shown in Figure 6 operational. This does inlude the generation of user forms as shown in Figure 7 but does not inlude system integration or the development of dediated appliations. The task of mapping a CWN onto YAWL an be partly automated by using the automati translation provided by ProM (f. ProM is able to automatially map Petri nets in PNML format onto various other formats, inluding YAWL. However, this translation does not take data and resoures into aount, so some manual work remains to be done. Nevertheless, it shows that the overall proess shown in Figure 1 is feasible. Moreover, we would like to argue that initially more time is spent on the requirements, but onsiderably less time is spent on the atual realization and testing. The intermediate steps (i.e., EUCs and CWNs) enable an effiient implementation. Moreover, less time needs to be spent on testing the system beause its design has been validated and verified earlier. Also, the system is more likely to be aepted by the end-users. 6 Related Work This paper builds on the work presented in [3], where we also apply CPN Tools to model EUCs and CWNs. However, in [3], EUCs are not linked to task desriptions and we used BPEL as target language instead of YAWL. The extension with task desriptions was inspired by the work of Lauesen [18, 19]. Compared to existing approahes for requirements engineering and use ase design [9, 11, 13, 25], our approah puts more emphasis on the two intermediate steps. First of all, we make EUCs with both an animation and formal tier. Seond, we use CWNs to link these EUCs to onrete implementations. Today, workflow tehnology is used in areas suh as radiology [26]. However, there is no systemati and broader support for workflows in health-are organizations. Vendors and researhers are trying to implement areflow systems but are often onfronted with the need for more flexibility [22, 23]. The state onept in CPN and YAWL (e.g., plaes with multiple outgoing ars modeling a hoie whih is resolved by the organization rather than the system) allows for more flexibility than lassial workflow systems. We know of one other appliation of YAWL in the health-are domain. Giorgio Leonardi, Silvana Quaglini et al. from the University of Pavia have used YAWL to build a areflow management system for outs. However, they did not use task desriptions, EUCs, and CWNs. Instead they diretly implemented the system in YAWL.

17 7 Conlusions In this paper, we realized a small areflow system using the four-step approah depited in Figure 1 and motivated the added value of eah of the three transformation steps in our approah. Obviously, the system made using YAWL is not the full EPR for Fyn County. It is just a prototype illustrating the viability of our approah. To ome from an extensive and detailed set of task desriptions as the seven task desriptions we have been onsidering to their implementation requires large amounts of work and extensive involvements of the stakeholders. A weaknesses of the work presented in this paper is the unavailability of stakeholders in oming from the task desriptions to the EUC, the CWN, and the YAWL implementation (stakeholders have been extensively involved in the writings of the task desriptions, but this is beyond the sope of this paper). The language we used both for Exeutable Use Cases (EUCs) and Colored Workflow Nets (CWNs) is CPN. For the atual realization of the system we used YAWL whih an be seen as a superset of CPNs (extended with OR-joins and anellation sets [1]) dediated towards the implementation of workflows. The state-based nature of these modeling languages fits well with task desriptions, i.e., in a given state it is possible to enable multiple tasks and let the environment selet one of these tasks. This is not possible in many workflow systems beause there the system selets the next step to be exeuted. Although CPNs and YAWL allow for more flexibility than lassial workflow management systems, we would like to argue that in the health-are domain more flexibility is needed than what is provided by YAWL as it has been used in this paper. Work on omputer-interpretable guidelines [21] shows that lassial workflow languages tend to be too restritive. Health-are workers should be allowed to deviate and selet alternative pathways if needed. To onlude this paper, we would like to disuss three extensions to allow for more flexibility. Dynami hange. The basi idea of dynami hange is to allow for hanges while ases are being handled [24]. A hange may affet one ase (e.g., hanging the standard treatment for an individual ) or many ases (e.g., a new virus foring a hospital to deviate from standard proedures). Although this approah is very flexible, it requires end-users to be able and willing to hange proess models. Case handling. Case handling [5] omprises a set of onepts to enable more flexibility without the need for adapting proesses. The basi idea is that there are several mehanisms to deviate from the standard flow, e.g., unless expliitly disabled people an skip and roll-bak tasks. Moreover, the ontrol-flow perspetive is no longer dominating, i.e., based on the available data the state is onstantly re-evaluated and the olletion and visualization of data is no longer bound to speifi tasks. Worklets. Worklets [6] allow for the late binding of proess fragments, e.g., based on the ondition of a the appropriate treatment is seleted. YAWL supports the uses of worklets, i.e., based on ripple-down rules an

18 appropriate subproess is seleted. The set of ripple-down rules and the repertoire of worklets an be extended on-the-fly thus allowing for a limited form or dynami hange. Eah of these approahes an be ombined with the four-step approah depited in Figure 1. However, further work is needed to develop EUCs and CWNs that an apture the degree of required flexibility and link this to onrete workflow languages allowing for more flexibility. Currently, even the most innovative systems support only one form of flexibility. For example, Adept [24] only supports dynami hange, FLOWer [5] only supports ase handling, and YAWL [6] only supports worklets. Hene, future work will aim at an analysis of the various forms of flexibility in the ontext of the approah presented in this paper. Aknowledgements We thank Søren Lauesen for permission to use the task desriptions for the Fyn County EPR as basis for this paper. We also thank Søren for fruitful disussions and feedbak on this paper. Referenes 1. W.M.P. van der Aalst and A.H.M. ter Hofstede. YAWL: Yet Another Workflow Language. Information Systems, 30(4): , W.M.P. van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, and A.P. Barros. Workflow Patterns. Distributed and Parallel Databases, 14(1):5 51, W.M.P. van der Aalst, J.B. Jørgensen, and K.B. Lassen. Let s Go All the Way: From Requirements via Colored Workflow Nets to a BPEL Implementation of a New Bank System. In Pro. of 13th International Cooperative Information Systems Conf., volume 3760 of LNCS, pages 22 39, Agia Napa, Cyprus, Springer. 4. W.M.P. van der Aalst and K. van Hee. Workflow Management: Models, Methods, and Systems. MIT Press, W.M.P. van der Aalst, M. Weske, and D. Grünbauer. Case Handling: A New Paradigm for Business Proess Support. Data and Knowledge Engineering, 53(2): , M. Adams, A.H.M. ter Hofstede, D. Edmond, and W.M.P. van der Aalst. Failitating Flexibility and Dynami Exeption Handling in Workflows. In O. Belo, J. Eder, O. Pastor, and J. Falao e Cunha, editors, Proeedings of the CAiSE 05 Forum, pages FEUP, Porto, Portugal, T. Andrews, F. Curbera, H. Dholakia, Y. Goland, J. Klein, F. Leymann, K. Liu, D. Roller, D. Smith, S. Thatte, I. Trikovi, and S. Weerawarana. Business Proess Exeution Language for Web Servies, Version 1.1. Standards proposal by BEA Systems, International Business Mahines Corporation, and Mirosoft Corporation, C. Bossen and J.B. Jørgensen. Context-desriptive Prototypes and Their Appliation to Mediine Administration. In Pro. of Designing Interative Systems (DIS) 2004, pages , Cambridge, Massahusetts, ACM Press. 9. A. Cokburn. Writing Effetive Use Cases. Addison-Wesley, Krav til Fyns Amts EPJ-system (udkast) Requirements to Fyn County s EPR System (Draft). Fyns Amt, 2003.

19 11. P. Grünbaher, A. Egyed, and N. Medvidovi. Reoniling software requirements and arhitetures with intermediate models. Software and Systems Modeling, 3(3): , Springer. 12. D. Harel. Stateharts: A Visual Formalism for Complex Systems. Siene of Computer Programming, 8: , M. Jakson. Problem Frames Analyzing and Struturing Software Development Problems. Addison-Wesley, K. Jensen. Coloured Petri Nets Basi Conepts, Analysis Methods and Pratial Use. Vol. 1, Basi Conepts. Monographs in Theoretial Computer Siene. An EATCS Series. Springer, J.B. Jørgensen and C. Bossen. Exeutable Use Cases as Links Between Appliation Domain Requirements and Mahine Speifiations. In Pro. of 3rd International Workshop on Senarios and State Mahines (at ICSE 2004), pages 8 13, Edinburgh, Sotland, IEE. 16. J.B. Jørgensen and C. Bossen. Exeutable Use Cases: Requirements for a Pervasive Health Care System. IEEE Software, 21(2):34 41, L.M. Kristensen, S. Christensen, and K. Jensen. The Pratitioner s Guide to Coloured Petri Nets. International Journal on Software Tools for Tehnology Transfer, 2(2):98 132, S. Lauesen. Software Requirements Styles and Tehniques. Addison-Wesley, S. Lauesen. Task Desriptions as Funtional Requirements. IEEE Software, 20(2):58 65, OMG Unified Modeling Language Speifiation, Version 1.4. Objet Management Group (OMG); UML Revision Taskfore, M. Peleg and et al. Comparing Computer-interpretable Guideline Models: A Case-study Approah. Journal of the Amerian Medial Informatis Assoiation, 10(1):52 68, S. Quaglini, M. Stefanelli, A. Cavallini, G. Miieli, C. Fassino, and C. Mossa. Guideline-based Careflow Systems. Artifiial Intelligene in Mediine, 20(1):5 22, S. Quaglini, M. Stefanelli, G. Lanzola, V. Caporusso, and S. Panzarasa. Flexible Guideline-based Patient Careflow Systems. Artifiial Intelligene in Mediine, 22(1):65 80, S. Rinderle, M. Reihert, and P. Dadam. Corretness Criteria For Dynami Changes in Workflow Systems: A Survey. Data and Knowledge Engineering, 50(1):9 34, I. Sommerville. Software Engineering Seventh Edition. Addison-Wesley, T. Wendler, K. Meetz, and J Shmidt. Workflow Automation in Radiology. In H.U. Lemke, editor, Proeedings of Computer Assisted Radiology and Surgery (CAR98), pages Elsevier, CPN Tools.

20