Supporting Adaptive Workflows in Advanced Application Environments

Transcription

1 Supporting aptive Workflows in vance pplication Environments Manfre Reichert, lemens Hensinger, Peter Daam Department Databases an Information Systems University of Ulm, D Ulm, Germany {reichert, hensinger, aam bstract The nee for supporting aaptive workflows (WFs) is wiely recognize. For many business processes (Ps) it is nearly impossible to consier all possible task sequences alreay at the esign level. esies this, ongoing business cases may also have to be aapte to organizational an functional changes in their environment. basic step towars aaptive workflow management systems (WfMSs) is the support of run-time WF specification as well as of ynamic WF changes. Such changes may affect only a single active WF instance or may affect multiple instances of a particular WF type. To aequately support aaptive WFs, it is important to unerstan why processes change an which kins of changes may occur. In this paper we use clinical application scenarios to explain an to elaborate the functionality neee to support ynamic WF changes in an avance application environment. The paper aresses conceptual issues relate to a hoc changes of a single WF instance on the one han, an it iscusses issues relate to WF schema changes an their propagation to its active instances on the other han. We show that the ifferent levels of changes must be consiere in conjunction an we use the DEPT concepts to illustrate how an integrate approach coul look like. 1 Introuction While ata-centere application systems ten to remain stable (i.e., unchange) for rather long perios of time, process-oriente applications must be moifie whenever the P they support changes, an this may happen rather frequently in real working environments (see [EKR95], [Shet96], [ShKo97], an [Sieb96]). In a hospital, for example, we fin Ps whose planning an execution overlap, a-hoc cases for which no stanar plan exists, unforeseen events leaing to a-hoc eviations from the pre-planne P, or functional an organizational changes requiring moifications in the efinition of stanar processes. Once an application system has been mae to behave process-oriente, it shoul support these cases an reflect the changes of a P very quickly; otherwise its benefit woul be low. Process-oriente WfMSs offer a promising technology to achieve this goal. They allow moeling the control an the ata flow of a P explicitly an separately from the implementation of the application components. In principle, it is possible to implement the application functions as isolate components, which can expect that their input parameters are provie by the runtime environment upon invocation an which only have to worry about proucing correct values for their output parameters. If the components are properly implemente an the ata epenencies between them have been mae explicit, a WF can be ajuste to changes of a P with a relatively low effort when compare to conventional programming approaches [LeRo97]. Toay's WfMSs, however, have been primarily esigne for the support of well-structure Ps showing little variations in their possible task sequences. They implicitly assume that all aspects of a P an all tasks are known in avance to the WF esigner, an they rather enforce a strict execution of the pre-moele WF. aptive WFs an particularly ynamic WF changes are supporte only ruimentarily. t the level of single WF instances, some WfMSs allow users to eviate from the premoele WF at run-time, but at the risk of inconsistencies an errors. Finally, little support is available for changing the efinition of a WF type an for applying these changes to alreay active instances as well. To aequately support aaptive WFs, it is important to unerstan why processes change an which kins of changes occur in practice. In this paper we use clinical application scenarios to explain an to elaborate the functionality neee to support ynamic WF changes in an avance application environment. lthough clinical processes are use for explanatory purposes, the problems aresse are also vali for other non-trivial application areas (see [FG93], [ShKo97], [Sieb96], an [Wes98]). The paper is organize as follows: In Section 2 we escribe characteristic properties an requirements of clinical WFs, concentrating on ynamic WFs an on WF changes. In Section 3 we show that these aspects must be consiere in conjunction, an we use the DEPT concepts to illustrate how an integrate approach coul look like. Section 4 iscusses relate work an conclues with a summary.

2 2 linical Processes The in-epth unerstaning of the characteristic types of processing, the organizational structures, the flexibility requirements of the meical personnel, the kins of exceptions an eviations occurring in clinical processes, an the aequate reactions on such events is inispensable for the support of clinical processes. In hospitals, we fin Ps of ifferent complexity an uration: Simple ones, like orer entry an result reporting for laboratory an raiology, but also complex an longrunning (even cyclic) Ps like iagnostic treatment of a or chemotherapy. These Ps may be highly ynamic with an overlapping planning an execution of tasks on the one han, or may follow strictly preefine meical proceures that normally have to be obeye on the other han. ut even for well-structure an repetitive Ps, there are many circumstances uner which a-hoc eviations are manatory. 2.1 Working Situation When efforts are taken to automate the flow of clinical processes, it is important to realize the working situation uner which WF technology must prove its usefulness an applicability. The cooperation between organizationally separate units is an important task in a hospital with repetitive but nevertheless non-trivial character. Meical an nursing care involve clinical tasks that may be critical to care on the one han, an it comprises time-consuming organizational responsibilities on the other han. Meical proceures an tests must be planne an prepare, appointments be mae, an results be obtaine an evaluate. We fin personnel working uner extremely high time pressure who often must make important ecisions about treatment within a rather short perio of time, an we fin personnel who is confronte with a massive loa of unstructure ata that have to be processe an put into relation to the problems of their s. In aition, the working situation is burene by frequent context switches. Unforeseen events an emergency situations occur, status changes, information necessary to react is missing. ecause of this, many coorination problems result, leaing to unnecessary long hospital stays an increasing costs or invasiveness of treatment. In critical situations, missing or erroneous information may even cause late or wrong ecisions. For all these reasons, a process-oriente information system, which helps to coorinate an to scheule clinical an organizational tasks woul be highly welcome by the meical personnel hoc Deviations From Pre-Planne Processes For the WF-base support of even well structure an repetitive clinical processes it is extremely important not to restrict the physician or the nurse. ny attempt to automate the flow of processes will fail, if rigiity comes with it. Variations in the course of a isease or a pre-planne treatment process are eeply inherent to meicine; the unforeseen event is to some egree a "normal" phenomenon. Meical personnel must be free to react an is traine to o so. For example, if physicians come to the conclusion that for a an aitional meical test, which has not been anticipate in the process plan, is neee they will ajust the plan accoringly. In emergency situations, physicians may perform an intervention immeiately without finishing preparatory measures require for the normal case. In such situations, a process participant may wish to collect information about the (e.g., the result of a previous meical test) by phone an afterwars procee with the process, without waiting for the (electronic) report to be written; i.e., this ocumentation step is skippe an worke on later. Finally, if the prerequisites for a meical examination are issatisfie, the physician must be free to abort it an to repeat it later (incluing the repetition of preparatory steps), to scheule an alternative proceure, or to o anything else. Such exceptions are frequent an inherent to clinical processes. equate reactions on them inclue (among other things) that tasks are repeate, skippe, moifie, postpone, or unone, that pre-planne task sequences are change (i.e., the orer of tasks is rearrange), or that alternative or new tasks are scheule. For cyclic process structures as in the case of a chemotherapy such a-hoc changes may concern a single treatment cycle or all (or part) of them. 2.3 Dynamically Evolving Patient Processes esies well-structure an repetitive meical proceures, the personnel is involve in long-term processes for which the planning an execution of tasks overlap. In a treatment process, usually several wellstructure iagnostic an therapeutic proceures are carrie out. efore an invasive meical intervention is performe, for example, the has to unergo numerous preliminary meical examinations. Each of them may require aitional preparations an aftercare. While some of these measures are known in avance an may therefore be consiere in the overall process plan alreay at the esign level, others have to be scheule ynamically epening on the s state of health an on the results of previously performe tests. For these reasons, a process cannot be always moele on a fine-graine level before the execution of the process starts. The (ynamic) planning of the flow is a very complex an error-prone task, since activities may be closely relate to each other ue to clinical, organizational, or logistic reasons. ecause of this, they can neither be execute sequentially nor completely inepenent from each other. For a particular, for ex-

3 ample, meical interventions may have to be performe in a certain orer or with a minimum or maximum time istance between them (see [DaKl98] for an example). Such interepenencies between tasks are eeply inherent to meicine an must be consiere in the planning of the process. Finally, for ynamically evolving processes, again we are face with the problem of a-hoc changes as escribe in Section hanges of Stanar Processes Up to now we have only consiere changes that affect a single () process. Moifications in the efinition of a stanar process an the aaptation of its ongoing cases may become necessary as well. Reasons for them may be the availability of new iagnostic or therapeutic tests, the ajustment of processes to a new law, the optimization of processes in conjunction with reengineering an quality management efforts, or the restructuring of the hospital organization itself. process-oriente clinical application will therefore not accurately represent the Ps of the health care organization for long. Instea, mechanisms must be foreseen for hanling organizational changes at the system level; otherwise, over time the mismatch between the real () processes an those supporte by the system will increase. Ieally, changes of stanar processes can be introuce on the fly without substantial elays. Especially in the context of long-running Ps, it may also be esirable to apply them to alreay ongoing cases as well. 2.5 Requirements On the one han, process-oriente application systems woul be highly welcome by the meical personnel. On the other han, for clinical processes it is nearly impossible except in very simple cases to consier all possible task sequences an all eviations that may occur alreay at the esign level. For WF-base clinical applications, it is therefore extremely important that users may gain complete initiative whenever they nee it. process-oriente information system must offer simple to use interfaces to the meical personnel for the hanling of scheule tasks as well as for the a-hoc eviation from the pre-planne process. In aition, methoological support is neee for the ynamic planning of a single process i.e., for the ynamic composition of pre-efine tasks escriptions. The resulting plan must then be automatically mappe onto an operational WF moel. Depening on their privileges, users must be able to change the structure of a single WF instance temporarily or permanently by aing or eleting tasks, by rearranging the orer of tasks, by suspening single tasks or whole processes, or by changing task attributes (e.g., role assignments an ealines). orresponing changes must be properly integrate, especially with respect to authorization an ocumentation; i.e., any eviation from the stanar process must be recore. Furthermore, the alteration of a single WF instance must be possible without affecting its original template. Finally, to eviate from a pre-moele WF must not be complicate for the user. For example, the complexity concerning the re-mapping of input/output parameters of the components affecte by a change must be hien to a large egree from users. Generally, it is also not acceptable that the user must check whether an envisage moification may cause any run-time problems in the sequel (e.g., cyclic waits leaing to ealocks, lost upates, missing ata ue to the skipping of a process step, or violate temporal constraints). Such checks have to be one by the system, ieally without performance penalty. The issues iscusse so far mainly concern changes of a single WF instance without affecting its original template. In conjunction with changes in the efinition of a stanar P (see Section 2.4), moifications of a WF template may become necessary as well. s many clinical processes are of long uration, it must be possible to make corresponing changes on the fly an to apply them not only to future instances of the corresponing WF template, but to in-progress WF instances as well. This is not as trivial as it looks like at first glance, since the propagation of template changes to a WF instance may not only epen on the current state of the instance, but also on a-hoc changes previously applie to it. 3 onceptual Issues in Supporting Dynamic Workflow hanges Most of the issues aresse in the previous section cannot be treate reasonably well when consiere in an isolate fashion only. In the DEPT project we are trying to look at the ifferent facets of ynamic WF changes in an integrate manner. In the following, we illustrate some of the problems an sketch how an integrate solution for supporting ynamic WF changes coul look like. We only escribe here those parts of the DEPT methoology, which are necessary for this iscussion. 3.1 WF Moeling an Execution With increasing complexity an expressive power of a WF moel, it becomes more an more ifficult to hanle ynamic WF changes an their sie-effects in a proper an secure manner. The challenge on the one sie is to fin a moeling technique that allows the WF esigner to aequately escribe all types of relevant processes. The challenge on the other sie is to keep such moeling techniques learnable an usable for both, the WF esigner as well as (to some egree) the en-users. To change structural components of an active WF instance, its representation (or a partial view

4 ata elements I weight + height ET = DT_E ose NT: noe type ET: ege type another cycle? ND-split NT = STRTLOOP collect ata pre-orer calculate the right ose prouce valiate ose NT = ENDLOOP ND-join amit check recor give provie aftercare ischarge physical examination take specimen perform lab-test valiate meical reports on it) must be unerstanable to the en-user, or at least to those en-users which have the privilege to perform ynamic changes. part from this, users must be sure that any change initiate by them will not cause inconsistencies (e.g., unintene lost upates) or run-time errors (e.g., program crashes ue to the invocation of task components with missing input ata). s motivate in Section 2 the necessary checks have to be performe by the system an not by the en-user. To achieve this, the moel must efine consistency an correctness properties allowing to etect (or to avoi) problems like non-termination of the WF, the passing of wrong or missing input ata to an application component, or temporal inconsistencies, for example. For a given WF moel, these properties must be valiate alreay at the esign level, an they have to be preserve whenever a change is applie to instances of that moel at run-time. For all these reasons we have ismisse the iea of using rather unstructure moels like, for example, Petri nets or E rules for WF moeling. Instea, we have aopte concepts from block-structure process escription languages. We have enriche them by introucing aitional control structures (e.g., for synchronizing the execution of tasks from parallel execution branches) an by explicitly representing the process state in the moel. Figure 1 illustrates the main philosophy how processes are moele in DEPT. It shows a very simplifie part of a clinical WF: passes through multiple treatment cycles. In each of them she or he is treate with a of which the ose is taken epening on her or his current weight an height. In orer to avoi interactions with possible problems on the sie of the, an aitional labtest is performe before the meication. The graphical representation of the WF as shown in figure 1 is not intene for the physician or the nurse. However, even more "en-user-frienly" interfaces will somehow reflect the basic concepts escribe here to avoi too large iscrepancies between the user s mental moel an the moel use by the system. In the DEPT WF moel ifferent types of split an join noes can be use to escribe ifferent kins of branching (incluing parallel an conitional branching). In aition, in contrast to many other WF moels, DEPT provies an explicit loop construct (see figure 1). This oes not only improve the reaability of the WF moel, but it also allows istinguishing between intentionally moele loops an unintentionally moele cycles. Furthermore, at run-time the event triggering the next iteration of the loop is wellknown to the system, which allows supporting avance features like the (efficient) unoing of temporary structural changes before the next loop iteration is starte (see Section 3.2). branching or a loop is always moele in a block-oriente fashion having exactly one entry an one exit noe. These blocks may be neste but they are not allowe to overlap. s this limits the expressive power of the moel, in aition, DEPT provies ifferent types of so-calle synchronization eges which can be use to express ifferent kins of wait-for situations in concurrent executions (see also Section 3.2). The use of these synchronization eges has to meet several constraints in orer to avoi ba cycles leaing to termination problems of the WF at run-time. The ata flow of a WF is efine by a set of ata eges connecting the input/output parameters of tasks with global ata elements of the WF. Data elements store the ata versione to allow partial rollback even to an earlier iteration of a loop. DEPT imposes a set of constraints governing the nature of a correctly moele ata flow schema. efore a task component is invoke, for example, all manatory input parameters must be supplie. That means, all ata elements to which the task s input parameters are connecte must be written at least once within all vali task sequences leaing to the activation of the task. Furthermore, tasks from ifferent branches of a parallel branching may not no yes ET = ONTROL_E ET = LOOP_E Fig. 1: Moeling an Executing Processes in DEPT

5 write the same ata element, unless they are explicitly synchronize by a synchronization ege. The control structures escribe so far are the same for the escription of WF templates an of WF instance graphs. t the WF instance level, in aition, special labels are use to explicitly escribe the current status of noes (e.g.,, RUNNING, or OMPLE- TED) an the status of eges (e.g., or FLSE_SIGNLED). DEPT uses a set of marking rules, which efine the conitions uner which the labeling of noes an eges must be change. fter completing an ND-split noe, for example, all outgoing eges are signale as TRUE. This, in turn, may lea to the activation of succeeing steps. In summary, we have selecte the block structure because it is rather quickly unerstoo by users, it allows to provie syntax-riven WF eitors, an it also allows the implementation of efficient algorithms for checking the correctness properties efine by DEPT. For more etails on the DEPT workflow moel, the intereste reaer is referre to [ReDa98] hoc changes of a Single WF Instance When a WF instance graph is change, it must be ensure that the resulting graph is syntactically correct an has a legal state. ny moification must lea again to a proper block structure, an it must preserve the consistency of the WF instance graph. DEPT offers a set of change operations to en-users, which can be applie for the proper an secure hanling of a-hoc eviations from pre-moele WF templates. Depening on their privileges, users may a tasks as well as whole task blocks (as sequential or as parallel steps), may elete tasks, may rearrange the orer of tasks 1, may initiate a partial rollback of the WF, or may change task attributes (e.g., role assignments, ealines, or bining of resources). ll changes are registere in a history an they are properly integrate with respect to authorization an ocumentation. For each change operation, DEPT efines the preconitions for its use, graph transformation rules 2, the semantics of the resulting graph substitutions, mechanisms for etecting possible problems an sie-effects, an policies for hanling these problems. It is important to mention that even simple operations like skipping a task may require a non-trivial restructuring of the WF instance graph in orer to regain its correctness an consistency (see below). The applicability of a change operation epens on the state of the WF instance uner consieration an on its structural properties. For the eletion of a task, for 1 e.g., by skipping tasks with or without working on them later or by jumping forwar to a currently inactive part of a WF instance graph 2 These rules are base on a complete an minimal set of basic change primitives like Noe, DeleteNoe, SetNoettribute, Ege, DataElement, or SetEgeState, for example. example, the following state constraint must be mae: task may not be remove from a WF instance graph if it has alreay been labele as or RUNNING; i.e., the component associate with this task has alreay been invoke. s an example for a structural constraint take the aition of a new task to a WF instance graph as a successor of the noe X an as a preecessor of the noe Y. This insertion woul not be allowe if Y precees X in the flow structure; in this case ba cycles leaing to ealocks at run-time might result. Other kins of constraints (e.g., temporal constraints, security constraints, an user efine integrity constraints) are outsie the scope of this paper. Due to lack of space, we omit further etails an present an example instea. Let us assume that the WF instance graph at a certain point in time looks like as the one epicte in figure 1. The steps represente by the noes amit an physical examination have been complete in the current loop iteration an the task collect ata has been activate (i.e., route to worklists). Let us further assume that an exceptional situation occurs making it impossible for the nurse to perform the activate step at the moment; e.g., she may not know where her is. Instea the nurse may wish to skip this step for the time being (i.e., to shift it to a later point in time) an to work on the task check recor immeiately. This task is executable, in principle, as it is not ata-epenent on the task collect ata an all other preecessors have alreay been complete. Skipping the task collect ata means to remove it temporarily from the WF instance graph. In oing so, its ata eges are elete as well, which may lea to missing or incomplete input ata of succeeing steps an thus to a violation of the correctness of the WF instance graph. To avoi such cases, at first DEPT checks whether there are succeeing tasks that are ata-epenent on the step to be elete. In the example, there is exactly one successor of the task collect ata satisfying this criterion, namely the task calculate the right ose. ssume that this task represents an automate step of which the WF esigner has isallowe the eletion (by having marke the noe accoringly). If we ha remove the noe collect ata without any further aaptation, this woul have cause serious consequences. The component for the step calculate the right ose woul then be invoke later, although manatory input ata woul be missing. This might lea to a program crash or which woul be even more terrible to wrong output ata (i.e., a wrong ose). ecause of this, DEPT accepts a change request only if no violation of the efine correctness properties occurs. oncerning the eletion of a task X, for example, several policies are provie to eal with the problem of missing ata: 1. Data-epenent steps are elete as well

6 NT = NULL amit amit collect ata (proxy step) NT = NULL physical examination collect ata physical examination weight + height ET = SYN_E check recor check recor pre-orer take specimen pre-orer take specimen calculate the right ose perform lab-test perform X-ray calculate the right ose perform lab-test perform X-ray ose prouce valiate meical reports prouce valiate meical reports valiate ose valiate ose another cycle? provie aftercare ischarge no give yes give provie aftercare ischarge no yes Fig. 2: -hoc changes of a single WF instance graph in DEPT 2. ynamically generate form is activate when the user starts the task with the missing ata. 3. n aitional provier step X prox is inserte into the instance graph substituting X; i.e., X prox takes over the ata links of X an must be complete before any task ata-epenent on X is activate. In our example, the first two variants are not applicable. The step calculate the right ose may not be elete, an it is an automate activity; i.e., prompting the user for the missing ata when starting this task will not be possible. Instea, DEPT will offer the user to generate a form an to prompt for the missing values either immeiately or when neee; i.e., variant 3 is chosen. Now the restructuring of the WF graph can begin: First of all, the task collect ata is elete; this is realize by removing it from worklists an by substituting a null task for it in the graph. Then a corresponing provier task ( collect ata ) is inserte as a parallel path into the instance graph. s this insertion must lea to a proper block structure again, aitional noes an eges are ae by the system. Fig. 3: The same graph after entering the next loop iteration an after unoing the temporary change. This transformation alone woul not be correct, however, because we must ensure that the newly inserte step is complete before the task calculate the right ose is activate (why?). To enforce this, a synchronization ege leaing from the step collect ata to the step calculate the right ose is ae to the graph. Following this transformation, the status of noes an eges is re-evaluate accoring to the marking rules efine by DEPT. fterwars, the steps check recor an collect ata can be execute immeiately as in both cases all incoming eges are marke as. The resulting instance graph is shown in figure 2. This graph reflects a secon change, which we have not iscusse here, namely the insertion of the task perform X-ray between the two steps take specimen an valiate meical reports. t this point, it is important to mention that users are not really burene with the restructuring of the instance graph. They express a change request in a rather eclarative way ( skip task X, insert task Z between X an Y, etc.), an they may choose between ifferent

7 policies for hanling sie-effects. Internally, graph transformation an reuction rules (see [ReDa98]) are use to perform the necessary moifications. s a last interesting aspect, consier once again the WF instance graph epicte in figure 2. s alreay mentione, the skipping of a task together with the insertion of a substituting provier task may be only of temporary nature. That means, when the next loop iteration is entere, the moifications mae have to be unone. oncerning changes of an instance graph, users may also esire that the applie moifications remain permanent; i.e., the change must be vali for the current as well as for all future iterations of the loop. In our example from figure 2, this might be the case for the insertion of the task perform X-ray. The ifferentiation between loop-temporary an loop-permanent changes is essential when both, loops an ynamic changes are supporte in the same system. The hanling of them, however, is not as trivial as it looks like at first glance. DEPT efines aitional rules that escribe when a moification may be loop-permanent an when it can only become loop-temporary. The most important constraint is that a loop-permanent change must not epen on a previously performe loop-temporary moification; otherwise severe inconsistencies or run-time errors may result when the next iteration of the loop is entere. Figure 3 shows how the WF instance graph from figure 2 may look like when the next iteration of the loop is entere (In this graph we omitte the presentation of the ata flow.) The loop-temporary change is unone while the looppermanent one is maintaine more comprehensive treatment of theses issues can be foun in [ReDa98]. 3.3 Workfloype hanges an the Hanling of ctive Instances So far, we have concentrate on a-hoc changes at the level of a single WF instance; i.e., moifications of a WF instance graph either temporarily or permanently without affecting its original WF template. In this section, we aress issues relate to moifications in the efinition of a WF type. In this context, the important question arises how to eal with the active instances of a WF type when its efinition is change. Shall they be finishe accoring to the ol template version, or shall all (or part) of them be migrate to its new version? n, if the latter is the case, uner which circumstances are such on-the-fly changes esirable an possible, an how must we eal with in-progress instances that cannot be (immeiately) migrate to the new template? In the following we sketch how these issues are relate to each other an how DEPT treats them Template hanges an their omplexity Though there are similar problems between the ahoc moification of a WF instance graph an its aaptation ue to the release of a new template version, changes of a WF template an the necessary graph transformation ten to be more complex. s an example, think of a moification uring which it becomes necessary (among other things) to a a new loop to the WF graph surrouning an alreay existing block of the flow structure. Generally, we cannot expect the enuser to perform such changes. The WF moeler, however, must be free an is traine to o so. Nevertheless, DEPT escribes changes of a WF template similarly to a hoc changes of a WF instance graph. change correspons to a sequence of change operations c 1... c n that when applie to a correct WF template T lea again to a WF template T * with a proper block structure an a correct ata flow schema (see figure 4 for an example). To ensure this, DEPT provies a syntaxriven WF eitor to the moeler with built-in operations like ctivity, Deletectivity, lockstructure, SyncEge, or DataElement. The set of basic change operations offere is minimal an complete in the sense of allowing each possible form of restructuring of a given WF template. t this point, it is important to mention that the high-level change facilities offere to en-users (e.g., to skip a task or to jump forwar to currently inactive tasks) are realize base on the same set of basic change operations, which is also use by the WF moeler when changing a WF template. Finally, a new version of a WF template is release only if its correctness is ensure. Multiple versions may be erive from the same WF template. T T * NT = STRTLOOP ET = LOOP_E X Policies for hange Propagation Generally, ifferent policies for hanling the instances of a moifie WF template are conceivable. In rare cases it may not be esirable that instances of the same WF type, but which are base on ifferent template versions are operational at the same time. NT = ENDLOOP Fig. 4: hange of the template T leaing to the new template version T *. The ata element e has been ae, activity X has been inserte between an (together with two ata eges), an activity Y (reaing the ata element e) has been ae. e Y

8 When a new template version T * is installe, then all instances execute accoring to the ol version T must either be aborte (an re-starte if necessary) or, first of all, they must be finishe before instances of T * may be create. nother policy is to allow the WF esigner to generate a new version of a WF template an to base the execution of future instances on it, while alreay running instances of that type are still execute accoring to the ol template. For many practical cases, however, these simple approaches will not be sufficient. Especially in conjunction with long-running WFs think of, for example, a meical treatment process of which the uration may be up to several months or years it is often esirable that changes in the efinition of a WF type are applie to alreay active instances as well. DEPT oes therefore not har-wire any of these policies. Instea, the moeler is free to choose between them an to escribe which instances may be aapte to changes of their original template an which may not. For example, she or he may specify that template changes may be applie to a WF instance graph only if it has (not yet) reache a certain state or if it satisfies a set of conitions (like The instance was create after a certain point in time or No a-hoc changes have been applie to it ). For this, the corresponing WF instances must be qualifie in a preicate-like manner. In principle, it is also possible to erive ifferent versions of the same template T an to split the set of currently active instances of T accoringly. Finally, the moeler may fix a time interval in orer to efine when a new template version is vali Hanling of ctive Instances To propagate changes of a WF template to inprogress instances is not as trivial as it looks like at first glance. Whether a template change can be correctly applie to a WF instance graph or not, oes not only epen on the current state of the instance, but may also be influence by a-hoc changes previously applie to its instance graph (see Section 3.2). Further epenencies (e.g., temporal constraints) may be consiere as well, but are outsie the scope of this paper. In the following, let T * enote a WF template that has been erive from the template T by applying a set of change operations c 1...c n to it. ssume further that enotes a WF instance graph that was create from the template T an of which the execution has not yet been finishe. The instance graph may iffer from its original template T in two respects: the labeling (i.e., the status) of noes an eges an in some cases the structural components. The latter will be the case if ahoc changes are applie to (see Section 3.2). Propagating the template changes c 1...c n to the WF instance graph now means to apply these changes to this graph as well. Obviously, a necessary conition is that the resulting instance graph satisfies the efine correctness an consistency properties. Generally, this will not always be possible an even if, the propagation may not be esirable ue to semantic conflicts between the changes c 1...c n applie to the template T on the one han an a-hoc changes c 1 w...c m w applie to the instance graph on the other han. First of all, let us assume that no a-hoc structural changes have been applie to the instance graph so far. Then except for the labeling of noes an eges the graph an its original template T correspon to each other. For this case, the eciing factor whether the template changes c 1...c n may be propagate to the instance graph or not, is the current status of its noes an eges. For each change operation, DEPT efines the pre-conitions an instance graph must satisfy regaring its state. Template changes c 1...c n may be applie to the instance graph, only if for each change operation c i (1 i n) meets these conitions. 3 This will always be the case, for example, if the region of affecte by the change has not yet been entere; i.e., the noes an eges from this region have not been labele so far. s an example, consier the template evolution from T to T* as epicte in figure 4. In the figures 5a an 5b two instance graphs (1) an (2) are shown, which were create from the template T. s they have not been structurally moifie so far, the propagation of the template changes solely epens on the current a) b) c) ) (1) (2) (3) (4) Z RUNNING RUNNING Fig. 5: WF instance graphs create from the template T (cf. figure 4a). Note that a-hoc changes have been applie to the instance graphs shown in figures c) an ). onsequently, their structure iffers from the structure of the original template T.

9 state of the instance graphs. The template changes escribe in figure 4 may be immeiately applie to w (1) T as all change operations both, the insertion of the task X between an an the insertion of Y after the loop block are allowe in the current state of w (1) T. The instance graph resulting from this change propagation is epicte in figure 6a. Regaring the instance graph w (2) T, however, the template changes cannot be (immeiately) applie to it, since the insertion of the task X is not permitte in the current state of this graph. 4 In such cases, a simple approach woul be to ismiss the changes for the WF instance uner consieration an to procee with the flow accoring to the present template version T. Other solutions that can be evise an that have been propose in the literature (e.g., [PS97], [asa96]) inclue the partial rollback of the flow to a previous state, that allows correctly applying the changes c 1...c n the migration of the instance graph to an alternative template T**, which may be vali only temporarily to hanle such specific cases. These approaches are easy to hanle, but they will restrict the practical usability of this feature significantly. Think of the treatment cycle from figure 2; the partial rollback of the flow woul not be practicable here. Instea, it woul be esirable to ismiss the changes for the current iteration, but to apply them for following iterations of the loop. ecause of this, DEPT supports the propagation of template changes at a later point in time as well. The change request will not be ismisse, but will be registere if it cannot be immeiately applie to the instance graph ue to a a) b) RUNNING X X Z 3 Further checks are not necessary since the structural correctness of T * has been alreay valiate at the moeling level. 4 ssume that we have applie the two insert operations to (2) nevertheless. If the loop block is left after the current iteration, the component of the task Y will then be invoke with missing input ata. e e Y (1) (4) Fig. 6: WF instance graphs from figures 5a an 5 after propagating the template changes to them. Y status conflict. The moifications will then become effective at the next possible point in time. If no a-hoc changes are applie to the instance graph (2) in the following, this late propagation will be possible when the next iteration of the loop is entere. If both, changes at the instance level as well as at the type level are supporte in one system, the important question arises how to eal with WF instances to which a hoc changes have been previously applie by en-users when their original template T is change. One may argue that in such cases changes in the efinition of T may not be propagate to these instances at all. This, however, woul be too restrictive for many applications especially in clinical environments where both types of changes frequently occur an it woul also be not necessary in general. Similar like with concurrency control in cooperative environments (cf. [WKl96]), the problem is to avoi structural as well as semantic conflicts between changes mae inepenently from each other an applie to the same object in our scenario to the same WF graph (respectively to a copy of it). If such conflicts occur between the a-hoc changes c 1 w...c m w applie to the WF instance graph on the one han an changes c 1...c n of its original template T on the other han, the template changes may not be propagate to the instance graph (at least as long as these conflicts cannot be resolve). Due to lack of space, we omit technical etails (e.g., concerning conflict tests) as well as issues relate to the hanling of semantic conflicts. Instea we present two examples focusing on structural conflicts. s a first one, consier the WF instance graph (4) as shown in figure 5. This graph iffers from its original template T (see figure 4) since an a-hoc change the insertion of Z between an has been applie to it. Nevertheless, the changes of the template T (as shown in figure 4) may be propagate to (4) without causing structural conflicts. The instance graph resulting from this propagation is shown in figure 6b. s a secon example take the instance graph (3) from figure 5c, where the tasks an (together with their ata eges) have been elete. Due to this a-hoc change, the moifications of the template T may not be propagate to (3) at the moment; X reas the ata element, which is not currently supplie ue to the eletion of. If the eletion of the task is loop-temporary (see Section 3.2), the changes may be propagate to (3) at a later point in time; i.e., after the temporary changes, which have cause the structural conflict, are unone an no new conflicts o occur ue to a hoc changes applie in the meantime. In the presente example, this may be the case when the next iteration of the loop is entere (i.e., when the eletion of task is unone). If task was elete loop-permanently from (3), however, the template changes may not be propagate at all. In all these cases, the system

10 must allow performing the necessary checks very efficiently. 4 Discussion an Summary The nee for aaptive WFs has been ientifie by several groups (e.g., [PS97], [asa96], [DMP97], [EKR95], [ShKo97], [Sieb96], an [Wes98]). The majority of these approaches, however, concentrate only on some aspects relate to the ynamic change problem. The proposals mae in [PS97], [EKR95] an [asa96], for example, eal with WF type changes an their propagation to running WF instances. How to treat WF instances, to which a hoc changes have been previously applie, is not iscusse in this context. Issues concerning the consistency an correctness of ynamic changes (e.g., with respect to the flow of ata), the management of loop-temporary an looppermanent changes, or the late propagation of WF template changes are also not sufficiently aresse. Finally, some interesting proposals have been mae in the fiel of ynamic planning processes (e.g., [DMP97], [Hei96]), which aim at the methoological support of ynamically evolving WFs. More comprehensive treatments of these approaches an of other relate work can be foun in [ReDa98]. The iscussion on ynamic WF changes has shown that many non-trivial interepenencies exist between the ifferent varieties of ynamic changes, which must be carefully analyze an unerstoo. In the DEPT project we attempt to consier most of the challenges escribe in conjunction with each other. We provie a proper framework with a clear semantics, which also allows arguing on the correctness of ynamic WF changes. In aition, we have been working on issues like the transactional support of WF changes, the control of concurrent changes, the support of temporal constraints, an security. Human-machine-interaction is also a major issue in this context; users must be able to unerstan the consequences of a change they are going to perform, an they shoul also be able to unerstan why the system is refusing to perform a certain change request. The work on large-scale aspects as well as on supporting ynamically evolving WFs is on its way. During the last years, we have implemente several eicate prototypes to stuy implementation an usability aspects of some of these features. Recently we have finishe the implementation of the first version of the DEPT-WfMS, which comprises many of the features aresse within one system. The escription of the system architecture an the iscussion of implementation issues will be the subject of other papers. We are convince that the approach we have taken in the DEPT project will allow supporting the clinical as well as many other application omains in an aequate way. References [FG93] aninelli, S.; Fuggetta,.; Ghezzi,.: Software Process Moel Evolution in the SPDE Environment. IEEE Transactions on Software Engineering, 19(12): , [PS97] ichler, P.; Preuner, G.; Schrefl, M.: Workflow Transparency. Proc. 9 th Int l onf. on vance Information Systems Engineering (ise 97), pp , arcelona, 1997 [asa96] asati, F.; eri, S.; Pernici,.; Pozzi, G.: Workflow Evolution. Proc. 15 th Int l onf. on onceptual Moeling, pp , ottbus, Germany, [DaKl98] Daam, P., Klas, W.: The Database an Information System Research Group at the University of Ulm. SIGMOD Recor, 26(4):75-79, [DMP97] Dellen,.; Maurer, F.; Pews, G.: Knowlege ase Techniques to Increase the Flexibility of Workflow Management. Data & Knowlege Engineering, [EKR95] Ellis,..; Keara, K.; Rozenberg, G.: Dynamic hange Within Workflow Systems. Proc. OOS'95, pp , Milpitas,, [Hei96] Heimann, P. et al.: DYNMITE: Dynamic Task Nets for Software Process Management. Proc. 18 th Int. onf. Software Engin., pp , erlin, 1996, [LeRo97] Leymann, F.; Roller, D.: Workflow-base pplications. IM Systems Journal, 36(1): , [ReDa98] Reichert, M.; Daam, P.: DEPT flex - Supporting Dynamic hanges of Workflows Without Loosing ontrol. Journal of Intelligent Information Systems, Special Issue on Workflow an Process Management. 10 (2), March 1998 (to appear) [Shet96] Sheth,.; Georgakopoulos, D.; Joosten, S.; Rusinkiewicz, M. et al.: Report from the NSF Workshop on Workflow an Process utomation in Information Systems, SIGMOD Recor, 25 (4):55-67, [ShKo97] Sheth,.; Kochut, K.: Workflow pplications to Research gena: Scalable an Dynamic Work oorination an ollaboration Systems. Proc. NTO v. Stuy Institute on Workflow Management Systems an Interoperability. Istanbul, Turkey, [Sieb96] Siebert, R.: aptive Workflow for the German Public ministration. Proc. 1st Int. onf. on Practical spects of Knowlege Management, Workshop on aptive Workflow, asel, Switzerlan, 1996 [WKl96] Wsch, J.; Klas, W.: History Merging as a Mechanism for oncurrency ontrol in ooperative Environments. Proc. RIDE-NDS 96, New Orleans, pp , [Wes98] Weske, M.: Flexible Moeling an Execution of Workflow ctivities. Proc. 31 st Hawai'i Int l onf. on System Sciences, Software Technology Track (Vol VII), pp , 1998