[ieee 2010 8th ieee international conference on pervasive computing and communications workshops...

6
Teleo-Reactive Worows for Pervasive Healthcare Srdjan Marinovic, Kevin Twidle, and Naranker Dulay Department of Computing Imperial College London London, UK {srdjan, k.twidle, n.dulay}@imperial.ac.uk AbstracThere is growing interest in using workflows to describe, monitor and direct a wide-range of medical procedures in hospitals. Unlike their well-established business counterparts, medical workflows require a high degree of execution flexibility since it is impossible to anticipate all the possible circumstances that might influence their execution and it is important that staff are permitted to respond to situations flexibly. Medical workflows also need to be unobtrusive, since requiring staff to continually acknowledge task execution or enter workflow data will get in the way of delivering medical healthcare. In this paper we present a new approach to workflow specification based on Teleo-Reacve programs, where a workflow is not defined as a set of discrete steps, but rather as a goal-driven process. Workflow tasks are modelled as continuous context conditions or durative actions. TR workflows offer a high degree of flexibility and an easier way to model human-centric tasks than the traditional graph- based workflow models. We illustrate the approach with a small pervasive heaIthcare example and show how we also apply the approach to managing workflow resources and security. Kwords: Mecal workflows, Pervasive workflows, Teleo- Reactive programming and Secu. I. INTRODUCTION For over a decade, workflows have been successlly used in many large organisations to describe and enact business processes [I]. Conceptually, a workflow represents a plan to reach a certain goal by speciing how various tasks need to be executed. Workflows can be described using a formal model, such as high-level Petri Nets [23], or through a structured 'programming' language such as BPEL [16]. In the healthcare sector, there is a great deal of interest in using workflows to monitor and manage the numerous human-centric activities that take place. For example, in hospitals, to monitor the treatments given to patients, and to efficiently manage the workload of doctors and nurses [6, 10]. Hospital managers would like workflow systems that are capable of closely monitoring the work of employees, but are at the same time unobtrusive and sufficiently flexible to allow healthcare workers to override predefmed access controls and scheduled activities when required. Such requirements have led to research into integrating pervasive computing techniques such as activi recognition into workflow-like systems [4, 11] and to the development of more flexible workflow models [17, 22]. 978-1-4244-5328-3/10/$26.00 ©201O IEEE 316 A crucial aspect of medical workflows is the difficulty of anticipating and describing all the contingencies that could arise due to changes in the environment and the unexpected (and not necessarily wrong) behaviour of people. A human- centric medical workflow must be sufficiently flexible to allow people to override the predefined order of activities if the overall goal can still be lfilled. Although a post- completion review of the workflow could be undertaken in such circumstances to see if deviations were acceptable, this brings operational overheads that organisations would like to avoid. The concept of a flexible workflow, where some tasks may not be executed or where some tasks may be executed in an unexpected order, is not a concept that traditional workflow models support or attempt to address. In contrast, traditional models employ highly structured formalisms such as: Petri-nets, Pi-calculus or structured programming languages like BPEL. The main contribution of this paper is to show how workflows can be described using Teleo-Reactive (TR) programs [15]. TR programs have traditionally been used to control robots that are able to robustly respond to changes in the environment or to the world model. TR programs are appealing due to their goal-driven approach and recoverable properties. Rather than defining a workflow as a discrete explicit sequence of tasks, TR workflows consider tasks as mappings om context values. As a result they can adapt to changes in context or recover om unexpected actions without re-planning. Security is an important concern for many medical workflows. If an incompetent person performs a task a patient's health can be endangered. Also, medical workflows and people executing them equently need to access sensitive information or sensor readings. is important that access to personal data is context and workflow-aware and takes into account exceptional situations, e.g. at a particular location, during a particular task, in an emergency. The paper's second contribution is to show how TR programs can be used to speci the dynamic security policies of a TR workflow. II. TELEO-REACTIVE WORKFLOWS A. Patient Care Worow Figure 1 shows a simple workflow for a patient's stay in a hospital ward. The patient is expected to stay in bed most

Upload: naranker

Post on 16-Mar-2017

218 views

Category:

Documents


2 download

TRANSCRIPT

Teleo-Reactive Workflows for Pervasive Healthcare

Srdjan Marinovic, Kevin Twidle, and Naranker Dulay Department of Computing Imperial College London

London, UK

{srdjan, k.twidle, n.dulay}@imperial.ac.uk

Abstract-There is growing interest in using workflows to describe, monitor and direct a wide-range of medical procedures in hospitals. Unlike their well-established business counterparts, medical workflows require a high degree of execution flexibility since it is impossible to anticipate all the possible circumstances that might influence their execution and it is important that staff are permitted to respond to situations flexibly. Medical workflows also need to be unobtrusive, since requiring staff to continually acknowledge

task execution or enter workflow data will get in the way of delivering medical healthcare. In this paper we present a new approach to workflow specification based on Teleo-Reactive programs, where a workflow is not defined as a set of discrete steps, but rather as a goal-driven process. Workflow tasks are modelled as continuous context conditions or durative actions. TR workflows offer a high degree of flexibility and an easier way to model human-centric tasks than the traditional graph­

based workflow models. We illustrate the approach with a small pervasive heaIthcare example and show how we also apply the approach to managing workflow resources and security.

Keywords: Medical workflows, Pervasive workflows, Teleo­Reactive programming and Security.

I. INTRODUCTION

For over a decade, workflows have been successfully used in many large organisations to describe and enact business processes [I]. Conceptually, a workflow represents a plan to reach a certain goal by specifying how various tasks need to be executed. W orkflows can be described using a formal model, such as high-level Petri Nets [23], or through a structured 'programming' language such as BPEL [16].

In the healthcare sector, there is a great deal of interest in using workflows to monitor and manage the numerous human-centric activities that take place. For example, in hospitals, to monitor the treatments given to patients, and to efficiently manage the workload of doctors and nurses [6, 10]. Hospital managers would like workflow systems that are capable of closely monitoring the work of employees, but are at the same time unobtrusive and sufficiently flexible to allow healthcare workers to override predefmed access controls and scheduled activities when required. Such requirements have led to research into integrating pervasive computing techniques such as activity recognition into workflow-like systems [4, 11] and to the development of more flexible workflow models [17, 22].

978-1-4244-5328-3/10/$26.00 ©201O IEEE 316

A crucial aspect of medical workflows is the difficulty of anticipating and describing all the contingencies that could arise due to changes in the environment and the unexpected (and not necessarily wrong) behaviour of people. A human­centric medical workflow must be sufficiently flexible to allow people to override the predefined order of activities if the overall goal can still be fulfilled. Although a post­completion review of the workflow could be undertaken in such circumstances to see if deviations were acceptable, this brings operational overheads that organisations would like to avoid.

The concept of a flexible workflow, where some tasks may not be executed or where some tasks may be executed in an unexpected order, is not a concept that traditional workflow models support or attempt to address. In contrast, traditional models employ highly structured formalisms such as: Petri-nets, Pi-calculus or structured programming languages like BPEL.

The main contribution of this paper is to show how workflows can be described using Teleo-Reactive (TR) programs [15]. TR programs have traditionally been used to control robots that are able to robustly respond to changes in the environment or to the world model. TR programs are appealing due to their goal-driven approach and recoverable properties. Rather than defining a workflow as a discrete explicit sequence of tasks, TR workflows consider tasks as mappings from context values. As a result they can adapt to changes in context or recover from unexpected actions without re-planning.

Security is an important concern for many medical workflows. If an incompetent person performs a task a patient's health can be endangered. Also, medical workflows and people executing them frequently need to access sensitive information or sensor readings. It is important that access to personal data is context and workflow-aware and takes into account exceptional situations, e.g. at a particular location, during a particular task, in an emergency. The paper's second contribution is to show how TR programs can be used to specify the dynamic security policies of a TR workflow.

II. TELEO-REACTIVE WORKFLOWS

A. Patient Care Workflow

Figure 1 shows a simple workflow for a patient's stay in a hospital ward. The patient is expected to stay in bed most

of the time. This routine is broken up with a physical examination performed by a doctor, who based on the readings taken by the patient's body sensor network (BSN) and the patient's records can schedule additional tests. Based on the test results, the examination may need to be re-done and also the patient may have to start taking medicine at regular time intervals. Later in the day, a nurse will do a routine check-up. The patient's workflow is terminated when the patient is discharged from the hospital.

Figure I Workflow for a hospital patient's care and examination. Tasks are: tl (stay in bed), t2 (examination), t3 (CAT scan), t4 (MRI scan), t5 (blood check), t6 (collect and analyze results), t7

(check up), t8 (patient leaves).

However in medical workflows, there are often situations where the execution of certain tasks will be subject to deviations. For example, it might be the case that the patient has to wait for the MRI scanner to become available and thus retums to her bed. While she is waiting, a nurse can do her daily check-up. Putting the check-up task in parallel with the tests, wrongly suggests that the patient can to do the check­up before tests, but this decision is made by the nurse if the patient is in bed. Furthermore, the appointed tests might be scheduled in a certain order such as CAT scan then MRI scan, then blood test but might be changed by a doctor or the system. The workflow in Figure 1 fails to capture these requirements. It turns out that it is very hard to correctly specify them using typical workflow models [17], as they require a large number of possible paths and interleavings that lead to complex hard-to-understand workflows.

One approach to address these requirements is through exception handling. But these are not exceptional situations; these are normal tasks whose ordering needs to be adaptive and flexible. Treating them as exceptions can undermine reacting to occurrences of real exceptions, such as a patient's heart rate dropping, or the patient is not in her bed when she should be. Furthermore, workflow exception handling is usually specified over a certain subset of tasks and is treated as a completely separate process, therefore it is very hard to specify how the workflow should handle multiple exceptions and in which order some tasks need to be re-done.

In medical workflows is often important to activate tasks based on context. In our example, if the patient is required to start taking specific medicines at specific time of the day,

317

this task needs to be present somewhere in the workflow structure. However, this addition does not fit neatly into any particular place in the workflow structure.

All these issues have nothing to do with the basic workflow concept of organising tasks to reach a goal, but are rather the product of existing models that use a discrete explicit sequence of tasks to describe a workflow. To address these issues we advocate using Teleo-Reactive programs to model adaptive workflows for pervasive environments.

B. Teleo-Reactive Programs

In its simplest form a TR program is written as an ordered list of condition-action rules called a TR procedure:

Procedure =

Ci -> Ai C2 -> A2

Cn -> An true -> At

Ci are conditions over context values (sensed, derived or inferred) or any variables that the program has access to (the model of the world) while Ai are actions (on the world or which change the world). The last condition is unconditionally true to ensure that that there is a default action. TR procedures are goal-directed, with the simplest pair of condition-action appearing first and others following in order of complexity. For example, if the goal is complete, then no action is required. If the goal is a step away, take the appropriate action to achieve any earlier condition. If multiple steps are required, then take the first such that the system would become a step closer to the goal to activate a more specific rule. TR procedures should aim to have certain properties such as completeness (the conditions cover all cases) and the regression (conditions become more specific as the priority increases). Both these properties are necessary if you want to build universal TR procedures that can reach a goal from any starting situation.

The TR structure is not dependent on the low-level details of how actions are executed or how conditions are evaluated. The conditions in a TR program are continuously evaluated and the action corresponding to the first true condition is executed. Actions can be durative, which means that they are considered to execute indefinitely until terminated by an earlier (higher-priority) condition. It is also possible for an action to be a TR procedure. In this case all conditions at all levels of the TR procedure call hierarchy are continuously evaluated. A called TR procedure thus has no control over when it will be terminated; any parent (calling) TR procedure would terminate it if higher-priority conditions become true. Such hierarchical nesting of TR procedures and conditions leads to easier development of programs that are required to react robustly to an unpredictable changing environment since outer-level conditions take precedence over inner-level conditions

It is also possible to specify that several actions are to be executed concurrently by concatenating them with the "II" operator.

The elegance of TR program stems from the idea that it is not critical in which order the rules will be fired, what matters is to constantly react to changes in order to reach the goal. Hence TR programs deal with exceptions and deviations through their rule ordering and continuous action executions. Conversely if something good happens - an action achieves a condition higher in the TR program than expected, then the TR program will automatically take advantage of it.

C. Using TR programs to represent workflows

Viewing TR programs as workflows, one can easily see that TR programs are effectively executing a set of ordered context-dependent tasks in a goal-directed reactive manner.

In our experience with modeling workflows as TR programs, we have not found one single "correct". way of translating standard workflow structures (such as Figure 1) into TR programs. One of the reasons is that workflows represent tasks as black boxes, which are treated as something that is externally started and stopped. Within TR programs one can choose to represent a task as either a condition that has to be fulfilled or an action that is executed because a certain condition is true. For example, from Figure 1 it is not clear how the task t1 (stay in bed) or the task t7 (check-up) are actually performed. Most workflow systems assume that the user simply inputs some value into a form or ticks a box to signal that the task has been finished. TR programs on the other hand ask the designer to think in a goal-oriented fashion rather than an imperative structure. These views can be considered orthogonal and there does not seem to be a clear way how to convert from one to another.

Having the flexibility to represent tasks through durative actions and continuous conditions, it is arguably easier to specify not only the structure that is closer to th� real-wo

.rld

execution but also make it clear where and what mformatIon a workflow engine needs to be able to gather in order to execute context-aware workflows. To elaborate, consider the following TR program for the patient care workflow:

patientCare =

discharged -> terminate

droppingHeartRate -> lieDown I I fetchCarers

medicineNotTaken & pastTimeForMedicine -> fetchNurse

timeForMedicine -> takeMedicine

inBed & nurseAtBed -> doCheckUp

inExaminationRoom -> doExam

needToDoPhysicalExamination -> gOExaminatiOnRoom

newTestResultsReady -> gOExaminatiOnRoom

needToDoCAT -> doCATscan

needToDoMRI -> doMRIscan

needToDoBloodTest -> doBloodTest

periodOutOfBed > allowed -> returnToBed I I fetchNurse

outOfBed & not moving

318

-> returnToBed true

-> nil

fetchCarers not closeToNurse & not closeToDoctor

-> fetchNurse I I fetchDoctor not closeToDoctor -> fetchDoctor not closeToNurse -> fetchNurse true -> nil

doExam =

doctorlnRoom -> doPhysicalExamination true -> waitForDoctor

In this example, tasks can be both conditions and actions. The mapping of tasks from Figure 1 is as follows:

The task t1 is represented by the three lowest condition­action rules. They simply state that unless the patient is doing something, the patient ought to be in bed. In case the patient is not in bed, the patient's PDA will ask the patient to return to bed.

The task t2 is represented by the rules for "need to do physical examination" and "in examination room". These rules attempt to capture how the examination is executed from the patient's point of view. When the patient has a scheduled examination, she is notified by her PDA device to go to the examination room. If the doctor is not at the examination room, the patient's PDA device will attempt to notify the on-duty doctor. Once the patient has been notified that the results are ready she will need to go to the examination room once again (rule "new test results ready").

Individual medical tests are captured through the three "need to do TEST' rules. Based on the ordering of rules and which tests are scheduled, the patient will be instructed in which order they should be conducted.

The task t7 is represented by the rule "in bed and nurse at bed', which instructs the patient that it is time for the check up. .

Finally, when the patient is discharged the workflow IS terminated. The workflow also seamlessly includes exception handlers, which are represented by the rules "dropping heart rate" and "medicine not taken". It is also interesting to observe how the TR structure elegantly allows the workflow to adopt new execution paths. For example, if the patient is waiting in her room because the MRI scanner room is not free, the nurse can do her check-up. The time­based tasks (rule "time for medicine") are smoothly integrated into the workflow specification.

However, what we have found particularly interesting is that specifying human-centric workflows as TR programs has made us view workflows more as advisory processes rather than prescriptive ones. TR workflows are oriented towards reacting to conditions that individuals find themselves in. This approach has much in common with one of the aims of human-centric pervasive computing, that systems are designed to assist rather than strictly control.

III. TELEO-REACTIVE SECURITY

The TR paradigm not only gives us the ability and flexibility to specify high-level human-centric workflows but

also to co-design system-level management processes for resources, context, security etc. For example, we can easily instantiate a separate TR program that is run in parallel with the patient care workflow to regulate readings for patients' monitored using a Body Sensor Network:

BSN_manager (P) = II patient P failedSensor

-> fetchTechnician(p) I I fetchNurse(p) lowBattery

-> fetchTechnician(p) I I lowRateReadings inExaminationRoom

-> highRateReadings true

-> normalRateReadings

In a similar way, we model the security aspects of a TR workflow using a concurrent TR security program. This is used to specity context-aware and workflow-synchronised authorisation policies, and also to dynamically reconfigure security services such as authentication. The underlying authorisation framework used is Ponder2 [20], which structures individuals, devices, services and organisational units into a hierarchy of domains (i.e. directories).

The following TR program is run in parallel with the patient care workflow and is used to specity permissions to access a patient's resources such as data and devices.

Securitypolicy (P, BSN) = II patient P droppingHeartRate

-> permit(medicalStaff, operate, BSN)

I I permit(medicalStaff, read, p.medRecord) nextToNonMedicalStaff

-> skip II removes any held permissions inExaminationRoom & doctorlnROOm(D)

-> permit(D, update, p.medReCord)

I I permit(D, operate, BSN) visitingTime & visitorAtBed

-> skip II removes any held permissions inBed & doctorAtBed(D)

-> permit(D, update, p.medRecord) inBed & technicianAtBed(T) & nurSeAtBed(N)

-> permit(T, operate, BSN)

I I permit(N, read, p.medReCord) inBed & nurseAtBed(N)

-> permit(N, read, p.medRecord)

I I permit(N, operate, BSN) true

-> permit(medicalStaff, read, BSN)

This TR program shares many of the conditions as the patient care workflow (workflow-synchronised), but also

includes additional conditions for when the patient is next to a non-medical staff and also when the patient has visitors.

These rules prevent medical staff from reading the patient's record (context-aware) since the visitors may see some data

that the patient wants to keep private (see Figure 2). However, these constraints are overridden if

there is an emergency. Note that permissions are durative and are only true for the duration of the action. Such constraints are very hard to express and enforce using existing workflow security models and their access-control based implementations [3, 5, 9].

319

Figure 2. Screenshot of the Patient Security TR output (running on

patient's device) showing how the access to sensor data is denied

to a nurse if a visitor is near the patient.

IV. IMPLEMENTATION

To evaluate and assess our ideas we have implemented a Teleo-Reactive agent platform on top of our Ponder2 framework for managing distributed pervasive systems [20]. The Ponder2 framework has already been used successfully to implement Self-Managed Cell (SMC) platform, which controls and manages body sensor networks [25]. The techniques we describe below could however be incorporated into other agent platforms such as IBM's ABLE platform [26].

The Ponder2 framework is implemented in Java and views all objects and events that it can interact with as

special managed objects, and through these objects' exposed interfaces it is able to interact with them. So far, we have successfully run the framework on small devices such as

Gumstixs and Android G 1 phones (see Figure 2 and Figure 3).

Figure 3. Screenshot of the Patient Care TR workflow (running on patient's device) showing how the dropping heart rate exception is

handled. The debugging pane shows rule 2 is currently active.

The implementation of the TR agent consists of the following three abstractions: Rule, Procedure, and Percept.

PonderTalk is used to specify these abstractions. This language is Ponder2's object language and is a subset of Smalltalk targeted at policy-based management of pervasive and mobile ad-hoc environments.

I) Rule. A rule has a condition and one or more actions. The agent can query the rule to see if it is available to be run i.e. to evaluate its condition and return the result, true or false. Conditions are simply represented as objects that can query context managers and percepts. For example:

[location=="exam_room" & location ispresent(doctor) ]

An action is implemented as an invocation of a particular object's method. A rule can handle two or more parallel sequences of actions, it does this by spawning off separate threads and waiting for them all to finish before indicating that its actions have been completed. Parallel actions are introduced with the parallel keyword. The following will run action aI followed by a2 in parallel with action hI

rule action: a1; action: a2 ; parallel; action: b1;

A rule is interruptible, i.e. the TR agent can ask it to terminate. However individual actions are not currently interruptible (due to restrictions in Java's thread model). If a stop is received then the rule waits for the currently running action to complete and terminates before running the next action. In the case of parallel execution the agent waits for all the threads to complete their current actions before terminating.

II) Procedure. TR procedures are at the centre of TR programming. A procedure is an ordered set of rules. When started, the procedure asks each rule in tum if it can be run, the first rule to respond that it can, is run. The procedure then proceeds from the top evaluating the rules over and over again. Each time the rules are evaluated, the top-most rule is run. If the top-most rule is the currently running rule (and it is still running) then that rule is simply left alone to continue. If, however, a higher priority rule is ready to run then the currently running rule is told to stop. When it has stopped, the chosen rule is run.

In classical TR semantics, active procedures continuously re-evaluate their rules as if they were running as an electric circuit. Obviously, this is not always natural in a multi­threaded platform like Java, so TR procedures in Ponder2 have three options that can be used to modify a TR procedure's behavior to make it more thread friendly:

WaitForEvent - The procedure only re-checks the rules when it receives a new event. If a rule completes and no event is received then the procedure waits until one arrives.

WaitForRule - This option tells the procedure that it cannot terminate a rule before it finishes, even if a higher priority rule is ready to be run. The only exception is if the procedure, itself, has been told to stop then the currently running rule will be forced to stop. Actions can actually be other rules containing actions or even procedures for more complex actions. If this is the case then it is sometimes desirable to use the RunOnce option:

RunOnce - In this option the procedure passes over its rules executing one as necessary. When it reaches the end of the procedure or the rule it has executed has finished then the

320

procedure terminates. This makes it easy for a rule to perform an action that may itself be quite complex.

III) Percepts. Percepts contain the global knowledge that the TR procedure shares with all rules. The procedure is informed, by means of an asynchronous event, whenever a percepts value changes. Depending upon the options used, this could trigger a new evaluation of the rules and therefore possibly cause a new rule to be run. They are currently implemented using a dictionary object with concurrency control. More than one procedure can share the same percepts thus giving an event driven communication medium between them.

V. RELATED WORK

The notion of using workflows in pervasive environments, to orchestrate pervasive services, has been explored by Ranganathan [18] and Hackmann [7]. Their works are based on using a web-services workflow engines running on a user's PDA device. A different approach is taken in [12] where workflow instances migrate between web-services, while [8, 19, 21] workflow task execution is based on the state of the environment. An interesting approach to deal with uncertain context information has been to incorporate fuzzy rules for branching operators [2]. All these approaches however, still remain entrenched in the structured workflow model (most use some variant of the BPEL) and thus do not meet the requirements of flexibility and adaptability, nor do they try to express or model execution of human-centric tasks, but remain focused on modeling tasks as invocations of pervasive web-services.

In AgentWork [14] event-condition-action rules are used to add and remove tasks from the workflow specification based on external events. The approach is easy to understand on simple examples, but gets unwieldy and hard to reason about in general where the ordering and synchronization of when adaptations are permissible is dependent on previous adaptations that may have happened in the workflow. Marconi [24] propose task refinement and contextual constraints over workflow subgraphs in order to adapt workflow execution in the pervasive environment.

Support for flexibility in workflow modelling is addressed in the Declare tool [17, 22]. This tool implements a constraint-based language based on Linear Temporal Language (LTL) formulae. In this case, the workflow is not specified as a path of execution but rather as a set of constraints between tasks. It is clear that our work and Declare share the same ideals. However, we find that the TR paradigm is more appropriate for pervasive workflows, because TR workflows can adapt to changes in context or recover from unexpected actions without re-planning. Also, TR workflows are able to easily model human-centric tasks and incorporate exception handling as conditions within the workflow specification rather than treating them as black boxes.

VI. CONCLUSION AND FUTURE WORK

In this paper we have described a new approach, based on Teleo-Reactive programming, for describing, monitoring

and directing human-centric workflows in pervasive environments. TR workflows are not defined as a set of discrete steps, but rather as goal-driven processes, where tasks can be (i) contextual and activity sensing conditions, (ii) actions that guide users through a workflow, or (iii) management actions over the supporting pervasive system. TR workflows have no structured plans to achieve the goal, but rather they attempt to do whatever action is the most appropriate given a set of conditions. Having the ability to directly include contextual conditions as tasks allows the workflow to easily infer when tasks are done and subsequently increases the unobtrusiveness of the workflow. We also showed how TR programs can be used to flexibly manage the resources and security of workflows as separate processes that synchronise through shared TR conditions.

One aspect that we aim to explore is the choreography of TR workflows. Choreography advocates building smaller TR programs that through collaboration achieve higher-level goals. Our implementation already supports communication between workflows but we have not yet incorporated runtime protocols for reliable group communication and transaction processing.

Our current implementation runs on the Gumstix and Android platforms, as well as standard PCs. For our future work we would like to use these implementations in a real­life deployment to further validate our current approach.

VII. ACKNOWLEDGEMENTS

This research was supported by EU FP7 research grant 213339 (ALLOW).

VIII. REFERENCES

[1] W. M. P. Aalst and K. V. Hee, "Workflow Management:

Models, Methods, and Systems", MIT Press, 2004. [2] O. Adam, O. Thomas, and G. Martin, "Fuzzy Workflows -­

Enhancing Workflow Management with Vagueness",

EUROIINFORMS, 2003. [3] V. Atluri, "Security for Workflow Systems", Information

Security Technical Report, vol.6, 2001.

[4] J. E. Bardram, and H. B. Christensen, "Pervasive Computing Support for Hospitals: An overview of the Activity-Based Computing Project", IEEE Pervasive Computing, vol. 6, 2007.

[5] E. Bertino, J. Crampton, and F. Paci, "Access Control and Authorization Constraints for WS-BPEL", ICWS 2006.

[6] A. Dwivedi, R. K. Bali, A. E. James, and R. N. G. Naguib, "Workflow management systems: the healthcare technology

of the future?", Engineering in Medicine and Biology Society, vol 4,2001.

[7] G. Hackmann, M. Haitjema, C. Gill, and G.-C. Roman,

"Sliver: A BPEL Workflow Process Execution Engine for Mobile Devices", ICSOC, 2006.

321

[8] J. Han, Y. Cho, E. Kim, and J. Choi. "A Ubiquitous Workflow Service Framework", ICCSA,2oo6.

[9] M. H. Kang, J. S. Park, and J. N. Froscher, "Access control mechanisms for inter-organizational workflow", SACMA T. 2001.

[10] Dazzi, C. Fassino, R. Saracco, S. Quaglini, and M. Stefanelli, "A patient workflow management system built on guidelines." Proc AMIA Annu Fall Symp, 1997.

[11] Y. Li and J. A. Landay, "Activity-based prototyping of

ubicomp applications for long-lived, everyday human activities", SIGCHI, 2008.

[12] F. Montagut, and R. Molva, "Enabling pervasive execution of

workflows", CollaborateCom, 2005. [13] N. Mulyar, M. Pesic, W.M.P. van der Aalst, and M. Peleg,

"Declarative and Procedural Approaches for Modelling

Clinical Guidelines: Addressing Flexibility Issues", Business Process Management Workshops, 2007.

[14] R. Muller, U. Greiner, and E. Rahm, "AgentWork: a wokflow system supporting rule-based workflow adaptation". Data And

Knowledge Engineering, vol. 51,2004. [15] N. Nilsson, "Teleo-Reactive Programs for Agent Control",

Journal Of AI Research, 1994.

[16] OASIS Web Services Business Process Execution Language Version 2.0, http://docs.oasis-

open.orglwsbpel12 .Olwsbpel-v2 .O.html.

[17] M. Pesic, H. Schonenberg, and W.M.P. van der Aalst, "DECLARE: Full Support for Loosely-Structured Processes", EDOC, 2007.

[18] A. Ranganathan and S. McFaddin, "Using Workflows to Coordinate Web Services in Pervasive Computing Environments", ICWS, 2004.

[19] F. Tang, M. Guo, M. Dong, M. Li, and H. Guan, H. "Towards

Context-Aware Workflow Management for Ubiquitous Computing", ICESS, 2008.

[20] K. Twidle, E. Lupu, N. Dulay, and M. Sloman, "Ponder2 - A

Policy Environment for Autonomous Pervasive Systems", POLICY, 2008.

[21] M. Wieland, P. Kaczmarczyk, and D. Nicklas, "Context

Integration for Smart Workflows", PerCom, 2008. [22] W.M.P. van der Aalst, M. Pesic, and H. Schonenberg,

"Declarative workflows: Balancing between flexibility and support". Computer Science - R&D, vol. 23, 2009.

[23] W.M.P. van der Aalst and A. H. M. Hofstede "YAWL: yet another workflow language", Information Systems, vol. 30, 2005.

[24] A. Marconi, M. Pistore, A. Sirbu, H. Eberle, F. Leymann, T. Unger, "Enabling Adaptation of Pervasive Flows: Built-in Contextual Adaptation", ICSOC, 2009.

[25] E. Lupu, N. Dulay, M. Sloman, J. Sventek, S. Heeps, S. Strowes K. Twidle, S.L. Keoh, AB. Schaeffer-Filho, "Self­managed Cell: A Middleware for Managing Body-Sensor

Networks", MobiQuitous, 2007. [26] J.P. Bigus, DA. Schlosnagle, J.R. Pilgrim, W.N. Mills, Y.

Diao, "ABLE: a toolkit for building multiagent autonomic systems", IBM Syst. Journal, vol. 41, 2002.