The ADEPT Project: A Decade of Research and Development for Robust and Flexible Process Support [original]

Ulmer Informatik Berichte | Universität Ulm | Fakultät für Ingenieurwissenschaften und Informatik

The ADEPT Project: A Decade of Research

and Development for Robust and

Flexible Process Support

Challenges and Achievements

Peter Dadam, Manfred Reichert

Ulmer Informatik-Berichte

Nr. 2009-01

Januar 2009

The ADEPT Project: A Decade of Research and

Development for Robust and Flexible Process Support

Challenges and Achievements

Peter Dadam and Manfred Reichert

Institute of Databases and Information Systems, Ulm University, Germany

{peter.dadam, manfred.reichert}@uni-ulm.de

Abstract. This paper gives insights into the ADEPT project. Its target was to

develop a next generation process management technology, which is by orders of

magnitudes more powerful and flexible than contemporary process management

systems. The ADEPT technology should provide advanced features and proper-

ties within one system, which seem to exclude each other, but which are required

for the support of a broad spectrum of processes: ease-of-use for end users and

system developers, high flexibility through the support of non-trivial ad-hoc de-

viations at the process instance level, quick implementation of process changes

through process schema evolution, and correctness guarantees enabling robust

execution of implemented processes. This paper describes the background and

the real-world cases which motivated our research. It further explains the techno-

logical challenges we faced, describes the solutions we elaborated, and discusses

the current status of the ADEPT project.

1 Background - how all began

In 1992 we started the OKIS1project - a pretty large and broadly defined 3-years re-

search project funded by the State of Baden-Württemberg. In this project several clin-

ics, medical service units, and the computing center of our university hospital were in-

volved. The goal of OKIS was to develop a concept for a cross-organizational, clinical

information system that is able to integrate autonomous, heterogeneous departmental

systems as well as to offer services across system boundaries (e.g., scheduling, resource

management, and medical data exchange). At the beginning of OKIS we looked at many

aspects of hospital information systems to understand the different types of relevant

information, the different kinds of information systems involved (e.g., radiology infor-

mation system, picture archiving and communication systems, and lab systems), the

privacy issues, the different types and roles of doctors and nurses, characteristic proper-

ties of planning and scheduling tasks, and so forth. We further investigated new devel-

opments (at that point in time) like electronic patient record, communication servers,

medical guidelines, and computer-assisted medical diagnostics in order to understand

which features a modern hospital information system should have [1].

1OKIS is derived from the German name of the project and stands for “Open Clinical Database

and Information System for the Integration of Autonomous Subsystems”

The challenge of the service layer we wanted to develop was rather clear in an early

stage of the project: Due to the heterogeneity of the underlying systems and the evolu-

tionary nature of the clinical domain one has to decouple service provision from service

implementation. However, the discovery of services and their usage must not be com-

plicated. Therefore, long before web services came into the game, we had elaborated

the concept of a cross-organizational “service bus” (that we called “software bus” in

[2]; see Fig. 1) into which new services can be easily plugged in such that application

programs (providing the end-user interfaces) can use them.

Fig. 1: OKIS software bus [2]

While working on many different aspects of the overall problem we got the dim

feeling that providing data integration together with some electronic services would

be an improvement, but not be the big step forward our colleagues from the university

hospitals were hoping for. Therefore, we had additional discussions with them as well as

other clinical staff members, and also took a closer look at the clinical workday. During

these activities it became more and more clear that the really big problem was not the

inconvenient access to medical data. The much bigger and more challenging problem

was the non-existing support of the clinical processes! These processes were only in

the users’ minds. Notes on paper or entries in a calendar system were the only help for

physicians and nurses to not forget things. No active process support or assistance by an

information system was provided to avoid problems like omission errors, unnecessarily

pending tasks, or non-optimal task sequences (see [3] for a description of the problem).

This meant that services provided by the Software Bus should be offered to users in a

process-oriented way.

We got fascinated about this challenge and we were convinced that a software tech-

nology, which is able to cope with clinical processes, would be also adequate for many

other domains and enable completely new perspectives for information management

systems. Therefore, in 1995 we decided to start the ADEPT2project as a dedicated

research activity in that subject area. At the beginning we were confronted with many

problems and questions, not knowing where to start with and also not knowing which

aspects were highly relevant for the final solution and which ones could be neglected.

Nevertheless we made a decision which should guide and determine our whole research

until today: "We face the clinical reality - we do not define any problem away!" This

motto resulted in the insights, requirements, and technological challenges described in

this paper.

The remainder of this paper is organized as follows: Section 2 provides some in-

sights into the clinical reality and identifies major requirements. Section 3 describes

relevant challenges and the research areas of the ADEPT project. Section 4 discusses

the overall technological challenges and the general “vision” of the ADEPT project. In

Section 5 we present some of the achievements made. Section 6 describes the current

development status and the transition from a research prototype to an industrial product.

Finally, Section 7 concludes with a summary.

2 Facing the clinical reality

Our initial insights into relevant requirements were derived from the OKIS project.

Following this, from 1996 to 1997 we performed a dedicated workflow project with

Siemens-Nixdorf and our Women’s Hospital. In this project we analyzed and docu-

mented the core processes of this hospital, investigated organizational aspects (e.g., ac-

tor responsibilities, substitution rules, or legal regulations), and evaluated what kind of

exceptional cases had occurred in the past and how good they were “predictable”. These

insights were extremely helpful for us to extend and refine the requirements identified

in the OKIS project, and to evaluate any suggested solution against these real-world

scenarios [4]. The issues described in the sequel represent consolidated insights from

both projects (and are valid until today).

Robustness. By nature, clinical information systems should be highly reliable. How-

ever, process-aware information systems (PAIS) are inherently more complex than tra-

ditional function- and data-centric information systems, simply because of the fact that

the incorporated process support is another source of errors. In traditional information

systems the processes are more or less only in the users’ minds [5]. Of course, hu-

mans also make mistakes when performing processes, but these errors are typically not

charged to the information system. However, once processes are directly supported by

a PAIS, all process-related errors (e.g., deadlocks or program crashes due to missing

input data) will now be charged to the PAIS and will directly affect its acceptance.

Flexibility and adaptivity of the clinical processes must not be restricted. In a clin-

ical environment any PAIS will not be accepted by users if rigidity comes with it. De-

viations from the standard procedure constitute the normal case, and physicians and

2ADEPT stands for “Application Development based on Encapsulated Pre-modeled Process

Templates”

nurses are accustomed to perform such deviations. The physician always has the ulti-

mate professional authority and responsibility regarding decisions about diagnostic and

therapeutic procedures. No computer program and thus no PAIS is allowed to overrule

or to restrict the doctors’ judgment. Being faced with this aspect it became clear that any

kind of process technology that does restrict flexibility will fail in such a domain. How-

ever, the demand for flexibility is not only present in hospitals, it can be found in almost

all domains (e.g., [6–11]). No enterprise can take the risk to become inflexible, i.e., to

be unable to quickly and flexibly react on changes in the market or in legal conditions,

on detected inefficiencies in their processes, or on exceptional situations [10].

The support of clinical processes cannot be simply restricted to document-centered

workflows, which would make the realization of a PAIS much easier, because any tech-

nological solution could then concentrate on control flow and would not have to deal

with data flow issues.3Instead, we are faced with the full spectrum of process support

ranging from simple form- or document-based, human-centric workflows to production

workflows with manual activities, automatic activities, and need for application inte-

gration. In addition, runtime flexibility cannot be restricted to simple adjustments of a

process schema (e.g., by replacing one activity by another), but more complex structural

changes at the process instance level should be possible as well. For example, an on-

going treatment process might have to be changed to a large extent due to the physical

reaction of the patient on his current medical drugs. However, such process flexibility

must not lead to a high risk of PAIS failures at runtime or to a significant increase of

the complexity when developing application functions. The great challenge for us was

to find a solution which ensures a high degree of runtime flexibility on the one hand,

and robustness as well as ease of use on the other hand.

Ease of use. Although listing this requirement may sound like the typical lip service,

we considered ease of use as very important for a broad usage of process management

technology in the clinical domain (and not only there). Clinical staff works under high

time pressure, must often deal with exceptional situations, and is constantly confronted

with an information overload [3, 12]. This situation especially applies to university hos-

pitals which typically receive all complicated treatment cases that ordinary hospitals are

not able to handle. In addition, university hospitals educate physicians and nurses; i.e.,

there are many staff members who are not very experienced. This, in turn, increases the

pressure on clinical staff. Some staff members have stress because of their own missing

routine and experience, while others suffer from stress because they have to supervise

the less experienced colleagues in addition to their own duties. Therefore, any PAIS

which increases this stress because of complicated handling will not be successful.

Ease of use must not only be achieved for end users, but should also hold for the

developers of processes and corresponding application services. The problem is that

ease of use for users does not come for free; i.e., somebody has “to pay the price”.

Supporting ad hoc changes at the process instance level, or changing a process schema

at the process type level and propagating these changes to running instances, requires

a profound understanding of basic PAIS concepts (e.g., correctness of process models)

3In this scenario there is no other data flow among process activities than the document which

is passed from one activity to another during runtime.

as well as deep knowledge about PAIS internals (e.g., the physical representation of

process instances at the machine level). If such a detailed and system-near knowledge

is required for process administrators or application programmers in order to avoid

PAIS failures in the context of dynamic process instance changes, the battle will be lost

before it will have begun.

3 Challenges

Taking all together, the ease of use aspect was probably the most influential one for

our whole research. However, ease of use has different aspects and can be regarded

from different perspectives: the end user, the process implementer, and the application

developer. Our goal was to develop a technology which enables ease of use for all

of them. Sections 3.1 to 3.3, therefore, focus on this aspect. Other important aspects,

addressed in the ADEPT project as well, are discussed in Sections 3.4 and 3.5.

3.1 Challenge: Ease of use for process implementers

Ease of use for process implementers is influenced by several factors. An important

one is how complicated it is to create a new process schema; i.e., which constructs

and symbols are offered by the used process meta model, what is their semantics, how

intuitive is their usage, and what kind of meta model related constraints have to be

obeyed during process modeling? And it is also important that the process meta model is

expressive enough. As another relevant factor process implementers should not need to

know any implementation detail about the application functions the activities of a given

process schema shall be associated with; i.e., for them, preferably, there should be no

differences whether an application function is implemented as web service, Java library

routine, or call interface to a legacy system. Instead, these application functions should

all look like procedures or methods having input/output parameters. Finally, ease of use

for process implementers is also significantly influenced by the implementation effort

becoming necessary at their side in order to ensure that the composed process will be

executable without runtime errors (e.g., concerning testing). From the very beginning it

was clear for us that these factors must not exclude each other, but have to be considered

in conjunction.

To speed up application development we pursued the idea of process composition

in a “plug & play” style complemented by comprehensive correctness checks [13, 14]

(cf. Fig. 2). Our target was to accomplish these checks in such a way that runtime er-

rors during process execution can be excluded to a large extent. As prerequisite, data

flows and other dependencies among application services, which are relevant for their

execution order, must be somehow made known to the PAIS to be incorporated into

the correctness checks. From our practical experiences it further became clear that in-

tuitively usable modeling constructs and automated correctness checks alone will be

not sufficient. A too liberal process meta model may result in too many undetected

(semantical) modeling errors when checking correctness.

Another important issue concerns changes at the process type level. In the clini-

cal domain it is very important that applied treatment procedures reflect the prevailing

ADEPT-CSRD--39.doc − 5 −

Process

Templates

Application

Functions

Repository

Process

Templates

Application

Functions

Repository

Figure 2: Composition of correct processes using plug & play [Dada97]

Another important issue in this context are process changes, more precisely changes of the process

schema. In the clinical domain it is very important that the applied diagnostic and therapeutic procedures

reflect the prevailing state of medical knowledge. Therefore, it must be possible to change these proce-

dures when the medical knowledge changes. Such a change may also affect ongoing process instances.

It must be possible to modify an existing process schema and to migrate its instances (as far as possible)

to the new schema, i. e. to perform process schema evolution [CCPP98]. However, as above, it must be

easy to use (for the process specialist), comprehensive changes must be possible, and correctness

checks on the system level should ensure robust execution of the adapted process instances.

3.2 Challenge: Ease of use for application developers

In the clinical domain (as typical for many other domains as well), one is confronted with existing (“leg-

acy”) applications, with specialized information systems, with different kinds of application functions and

services, different underlying implementations, with tasks which require user involvement, and with tasks

which can be automated. The challenge was to provide all these heterogeneous application functions and

services in a homogenized form to process implementer so that process composition in a plug & play

fashion as outlined in the previous section becomes reality. Our vision was that the process template fully

encapsulates the process with all its application functions and services, so that the process has just to be

“plugged” into the PAIS execution environment to be present. In addition, any manual activity coming with

a graphical (e. g. form-based) user interface shall smoothly integrate itself into the user’s desktop. Any

kind of “window over window over window” effect should be avoided. – This vision of “encapsulated proc-

ess templates” also gave the project its name: ADEPT = “Application Development based on Encapsu-

lated Premodeled Process Templates”.

Ease of use for application developers has meant to us, that we have to provide an easy to use imple-

mentation framework with easy to use application programming interfaces to perform these tasks. The

maxime was here: implemention of application components for PAIS should become not more compli-

cated than developing them for conventional application systems without process support. Especially, all

the complexity coming along with the support of ad-hoc flexibilty should not be put onto their shoulders, if

any possible.

3.3 Challenge: Ease of use for end-users

One aspect of “ease of use” for end-users is certainly to obey the typical human factors when designing

the user interface, like placement of information at the desktop, arrangement of entry fields, buttons, se-

lection of colors etc. We also experimented a little bit with user interface design, but this was not our main

focus. Instead, we concentrated on the issue how to make ad hoc deviations at the process instance level

simple so that, in principle, a doctor or a nurse can perform them autonomously in most cases (supposed

that they have the permission to do that). From the explanations above it should be clear that every solu-

tion approach which requires at the users’ side a deeper understanding of system-internals like “process

states” and “data flows” would have to fight with big acceptance problems. And the approach would com-

pletely fail if it is the users’ responsibility to ensure that their modifications do not lead to any subsequent

run-time errors when continuing the execution of the process instance. No doctor or nurse would accept

to take this risk!

When providing an end-user interface for ad hoc modifications it is very important to provide a reasonable

level of abstraction. Ideally, users should only express what they want to have and it should be the PAIS’

task to figure out how to do that, in case the action is admissible, in principle. Figure 3a – h illustrate how

the interaction between the PAIS and the end-user may look like, presuming that the user is able to un-

Fig. 2: Composition of processes using plug & play [15]

state of medical knowledge. Therefore, it must be possible to adapt them when medical

knowledge changes. Such changes may also affect ongoing cases, i.e., it must be pos-

sible to modify a process schema and to migrate its instances to the new schema (we

denote this as process schema evolution [16, 17]). As motivated such change feature

should be easy to use (for the process specialist), comprehensive schema changes must

be possible, and correctness checks on the system level should ensure robust execution

of the adapted process instances.

3.2 Challenge: Ease of use for application developers

As typical for other domains, in a hospital we are confronted with legacy systems of-

fering special application functions to users. These legacy systems are implemented

based on different platforms, have tasks which require user involvement and such which

can be automated, and differ in their system interfaces, user interfaces, and interaction

styles. The challenge was to provide all these heterogeneous application functions in a

homogenized form to process implementers in order to make process composition in

a plug & play fashion a reality. Our vision was that the process template fully encap-

sulates the process with all its application functions and services, such that the process

just has to be “plugged” into the PAIS runtime environment to be executable. In ad-

dition, any manual activity coming with a graphical (e.g. form-based) user interface

should smoothly integrate itself into the user’s desktop; i.e., any kind of “window over

window over window” effect had to be avoided. - This vision of “encapsulated process

templates” also gave the project its name: ADEPT = “Application Development based

on Encapsulated pre-modeled Process Templates”.

Ease of use for application developers meant to provide an easy to use implementa-

tion framework with intuitive application programming interfaces to perform all these

tasks. Our maxim was to make the implementation of application components for a

PAIS not more complicated than developing them for conventional application systems

without process support. Particularly, all complexity coming along with the support of

ad-hoc flexibility should not be put onto their shoulders.

3.3 Challenge: Ease of use for end users

Ease of use for end users includes adherence to typical human factors when designing

a user interface; e.g., placement of information at the desktop, arrangement of entry

fields, use of buttons, or selection of colors. We also experimented a little bit with

user interface design, but this was not our primary focus. Instead, we studied how to

make ad-hoc deviations at the process instance level as simple as possible, such that

- in principle - a doctor or nurse can perform them autonomously (supposed that they

have the permission to do that [18, 19]). From the above explanations it should become

clear that every solution approach that requires from users a deeper understanding of

system internals (e.g., “process states” and “data flows”) would have to fight with big

acceptance problems. And such approach would completely fail if it had been the user’s

responsibility to ensure that their ad-hoc changes do not lead to any subsequent runtime

errors in the execution of the modified process instance. No doctor or nurse would

accept to take this risk!

An end user interface for ad-hoc changes has to provide a sufficient level of ab-

straction. Users should only express what they want to be changed, but it should be the

PAIS’ task to figure out how to do that (in case the change is admissible). Fig. 3a-h illus-

trate how the interaction between PAIS and end user may look like, presuming that the

user is able to understand the meaning of a simplified (i.e. abstracted) process graph.

Regarding this example assume that during the execution of a process instance (e.g.,

the treatment of a certain patient under risk) an additional lab test becomes necessary.

Assume that this has not been foreseen at process implementation time (cf. Fig. 3a). As

a consequence, this particular process instance will have to be individually adapted if

the change request is approved by the system. After pressing the “exception button” (cf.

Fig. 3b), the user can specify the type of the intended ad-hoc change (cf. Fig. 3c). If an

insert operation shall be applied, for example, the system will display the application

functions that can be selected in the given context (cf. Fig. 3d). These can be simple

or complex application services, interactive or automatic application functions, or even

complete processes. Following this, the user simply has to state after which activities(s)

in the process the execution of the newly added activity shall be started and before

which activities(s) it shall be finished (cf. Fig. 3e). If the activity to be inserted requires

additional data for its input parameters, the PAIS will have to suggest the insertion of an

appropriate auxiliary task. Finally, the system checks whether or not resulting process

instance adaptations are valid (cf. Fig. 3f and Fig. 3g). All the validations needed to

avoid runtime errors in the sequel as well as the necessary adaptations of the process

structure, data flow, and instance state should be completely performed by the PAIS.

In addition, the PAIS should allow for “intelligent” adaptations. For example, in order

to enable a maximal degree of freedom in executing the newly added task, it should

be insertable in parallel to the activities which are located between the ones marked

as “after” and “before” in Fig. 3e (except that data flow dependencies require a more

restricted execution).

Note that this example illustrates a rather simple user interface. If more sophis-

ticated, knowledge-based user interfaces are needed (e.g. [20–22]) this dialog can be

simplified or even omitted. However, our process studies also revealed that ad-hoc

changes are not always that simple. In certain cases it is not sufficient to only replace

ADEPT-CSRD--39.doc − 6 −

derstand the meaning of a simplied (i. e. abstracted) process graph. In this example it is assumed that

during the execution of a particular process instance (e.g., the treatment of a certain patient under risk) an

additional lab test becomes necessary. Assume that this has not been foreseen at process implementa-

tion time (cf. Figure 3a). As a consequence, this particular process instance will have to be individually

adapted if the change request is approved by the system. After the user has pressed the "exception but-

ton" (cf. Figure 3b), he can specify the type of the intended ad hoc change (cf. Figure 3c). If an insert

operation shall be applied, for example, the system will display the application functions that can be se-

lected in the given context (cf. Figure 3d).

Examinations

Wallace, Edgar

Smith, Karl

Miller, Anne

Jones, Isabelle

Exceptional case –

we need an additional

lab test !

Examinations

Wallace, EdgarWallace, Edgar

Smith, KarlSmith, Karl

Miller, AnneMiller, Anne

Jones, IsabelleJones, Isabelle

Exceptional case –

we need an additional

lab test !

Examinations

Wallace, Edgar

Smith, Karl

Miller, Anne

Jones, Isabelle

Exception

Examinations

Wallace, EdgarWallace, Edgar

Smith, KarlSmith, Karl

Miller, AnneMiller, Anne

Jones, IsabelleJones, Isabelle

Exception

a) An exception occurs b) User presses the "exception button"

Examinations

Wallace, Edgar

Smith, Karl

Miller, Anne

Jones, Isabelle

Exception

Insert task?

Delete task?

Shift task?

Examinations

Wallace, EdgarWallace, Edgar

Smith, KarlSmith, Karl

Miller, AnneMiller, Anne

Jones, IsabelleJones, Isabelle

Exception

Insert task?

Delete task?

Shift task?

Select Activity

Schedule counsel examination

Lab Test

Prepare patient for operation

Inform patient

Wash patient

Schedule examination date

.........

Examinations

U Wallace, Edgar

U Miller, Anne

U Smith, Karl

U Jones, Isabelle

Select Activity

Schedule counsel examination

Lab Test

Prepare patient for operation

Inform patient

Wash patient

Schedule examination date

.........

Examinations

U Wallace, Edgar

U Miller, Anne

U Smith, Karl

U Jones, Isabelle

c) User selects type of the ad hoc change d) User selects activity to be inserted

Explanation

Operation Risks

X-Ray

Check

Anesthesiology

Examination

End

Start

Examinations

U Wallace, Edgar

U Miller, Anne

U Smith, Karl

U Jones, Isabelle

Start immediately,

,results are

needed before explanation of

operation risks

Explanation

Operation Risks

X-Ray

Check

Anesthesiology

Examination

EndEnd

StartStart

Examinations

U Wallace, Edgar

U Miller, Anne

U Smith, Karl

U Jones, Isabelle

Start immediately,

,results are

needed before explanation of

operation risks

Explanation

Operation Risks

X-Ray

Check

Anesthesiology

Examination

End

Start

Examinations

U Wallace, Edgar

U Miller, Anne

U Smith, Karl

U Jones, Isabelle

ADEPT

Checking if insertion

of step is possible

- Please wait -

Explanation

Operation Risks

X-Ray

Check

Anesthesiology

Examination

End

Start

EndEnd

StartStart

Examinations

U Wallace, Edgar

U Miller, Anne

U Smith, Karl

U Jones, Isabelle

ADEPT

Checking if insertion

of step is possible

- Please wait -

ADEPT

Checking if insertion

of step is possible

- Please wait -

e) User specifies where to insert the activity f) System checks validity of the change

Explanation

Operation Risks

X-Ray

Check

Anesthesiology

Examination

End

Start

Examinations

U Wallace, Edgar

U Miller, Anne

U Smith, Karl

U Jones, Isabelle

ADEPT

Insertion is possible!

Great !!

Explanation

Operation Risks

X-Ray

Check

Anesthesiology

Examination

End

Start

EndEnd

StartStart

Examinations

U Wallace, Edgar

U Miller, Anne

U Smith, Karl

U Jones, Isabelle

ADEPT

Insertion is possible!

ADEPT

Insertion is possible!

Great !!

Lab Test

Examinations

U Wallace, Edgar

U Miller, Anne

U Smith, Karl

U Jones, Isabelle

Explanation

Operation Risks

X-Ray

Check

Anesthesiology

Examination

OK, now let us

continue with the

examination !

Lab TestLab Test

Examinations

U Wallace, Edgar

U Miller, Anne

U Smith, Karl

U Jones, Isabelle

Explanation

Operation Risks

X-Ray

Check

Anesthesiology

Examination

OK, now let us

continue with the

examination !

g) Change can be applied h) User continues work

Figure 3: Executing an ad hoc modification from the end-user's point of view

These can be simple or complex application components (e.g., "write letter” or "send email” vs. applica-

tion services), interactive or automatic functions, or even complete processes. Now the user simply has to

Fig. 3: Executing an ad hoc modification from the end-user’s point of view

one activity by another or to just add a single activity directly before or after the cur-

rently activated one. And it is also not predictable in advance which parts of the process

may be affected by a change. Therefore, we must also enable comprehensive structural

changes that may rearrange large parts of the process or even completely replace them.

Such complex changes are certainly beyond that what normal end users are able to do.

Instead they require someone with appropriate knowledge in process modeling and pro-

cess change. Such a person should have an interface which offers a comprehensive set

of change operations. However, also in this case the PAIS should ensure robustness of

the modified process instance.

In environments where exceptions and thus ad-hoc deviations occur rather fre-

quently, it is often desirable to use a knowledge management system to support the

user in detecting whether or not a similar exception already occurred in the past. Such

a component should store which decisions were made with which success to solve the

problem. By coupling it with the PAIS, it would become possible to conveniently “re-

cycle” previous decisions and to automatically reapply changes at the process instance

level [23–25, 22].

Not directly related to ease of use, but also important for end users are response

times in connection with ad-hoc changes. Especially in the clinical domain, very likely,

ad-hoc changes often will have to be performed under time pressure. Therefore, re-

sponse times of the PAIS in the range of several seconds or even minutes (e.g., to decide

on the correctness of an intended ad-hoc change) are not acceptable. (Usually 3 seconds

of response time are considered as upper limit for interactive tasks.) This means that the

resulting solution must also use efficient algorithms for adapting process instances and

for checking their correctness. Further, they must ensure short response times for sce-

narios in which many process instances are simultaneously executed by the PAIS. And

the latter will be the normal case in large-scale environments where thousands of pro-

cess instances are concurrently executed at the same time [26].

3.4 Complex ad-hoc changes and schema evolution

As discussed in Section 3.3 a PAIS should allow to handle all kinds of exceptional sit-

uations. In order to enable this without need for circumventing the PAIS, arbitrarily

complex ad-hoc changes at the process instance level must be possible; e.g., autho-

rized users should be allowed to move activities or whole process fragments to another

position in the process graph.

Another important change aspect is to enable process schema evolution at the type

level. Like other companies, hospitals are continuously adapting their organizational

structures, are changing staff responsibilities, are outsourcing or insourcing tasks, and

so forth in order to improve their (business) processes or to adequately react on changes

in legislation or market demands. Many of these changes directly affect the processes

supported by their (clinical) PAIS, i.e., these processes have to be adapted accordingly.

While in some cases only simple attribute changes are required (e.g., to adapt the staff

assignment rule of an activity), in others complex structural changes of the process

schema become necessary. In case of short-running processes, usually, it is sufficient

to finish the already started process instances according to the old process schema,

while new process instances refer to the new schema. However, at the presence of long-

running processes (months up to years) or in case of important and pressing changes

this is not sufficient. Then it must be possible to perform process schema evolution,

i.e., to migrate the process instances to the new schema version. Note that this also in-

cludes process instances which have been individually modified. - This is typical for

today’s environments where processes are executed manually; it will be hard to accept

for companies if a PAIS does not support that. Both, complex ad-hoc changes and pro-

cess schema evolution must be easy to accomplish for process experts. They should not

require deep knowledge about system internals and not require to modify processes at

a low level of abstraction.

3.5 Further requirements and challenges

To stay focused this paper concentrates on the technological challenges related to the

described ease-of-use aspects showing how they influenced our solutions and how we

dealt with the constraints we had to obey. In order to give a somewhat more complete

picture of the problem domain, however, we want at least briefly mention some other

challenges we were also confronted with.

Hospitals and especially university hospitals are large enterprises comprising many

specialized clinics, having a large number of employees (often several thousand), and

being confronted with thousands of “cases” (i.e. patients) which must be handled si-

multaneously. Therefore, any PAIS which does not scale up and which does not work

in a cross-organizational setting will fail in such an environment. As the clinics of a

university hospital may be geographically dispersed, it is rather unrealistic to assume

that a centralized PAIS will always be the appropriate solution. Instead, concepts for

the flexible, distributed execution of processes had to be found [27, 26, 28, 29].

Hospitals are often confronted with patients having multiple injuries, e.g., as a result

of a traffic accident. Assume that such a patient has a broken leg and some injury to his

head which have to be treated. It is not very likely that a process schema exists to

handle these two injuries in common. Instead, a process schema for handling injured

extremities and another for dealing with head injuries may exist. Obviously, as they

affect the same patient in this case, they cannot be executed completely independent

from each other. Problems of this kind require concepts for inter-process coordination

[30, 31].

Deadlines and temporal constraints play an important role in the clinical domain as

well. Typically an appointment (e.g., for performing a surgery) is made for a certain day

and time which requires some preparatory activities. These should be scheduled at the

appropriate points in time and warnings should be given by the PAIS if processing of the

remaining activities at normal speed would jeopardize the deadline. Or in preparation

of an examination the administration of some drug might become necessary. This drug

should be administered not too early and not too late to achieve the desired effects.

Future PAIS should therefore incorporate appropriate support for temporal constraint

management [3, 32].

Finally, there are other challenges we have dealt with, but which we cannot discuss

in detail. They include issues related to the learning from changes [33, 34], the efficient

representation of changes in adaptive PAIS [35, 36], the visualization of business pro-

cesses [37], and the evolution of organizational models and corresponding access rules

[38, 18, 39].

4 Technological challenges and our vision

The technological challenges elaborated in the previous sections can be summarized

as follows: We wanted to develop a PAIS which is by order of magnitudes more pow-

erful and flexible than contemporary PAIS are, and whose change features are easy to

use for end users, process implementers, and application developers. This sounds like

a contradiction in itself, because we all know: “There ain’t no such thing as a free

lunch.” However, regarding the mentioned user groups for which ease of use shall be

achieved, we can see that one party is missing: the implementers of the fundamental

PAIS technology. And we had one shining example to follow which had enabled ease

of use by hiding the complexity beneath the surface: relational database technology. On

the one hand, it was the first database technology which made it possible to support at

the system level automatic query optimization, data independence from physical stor-

age structures (relations, indexes), and powerful transaction-based concurrency control.

On the other hand, it offered a user interface (SQL) which was by orders of magnitudes

easier to learn and to use than the database interfaces before. And this was possible

because it was based on powerful theories (relational algebra, query optimization, con-

currency control). - Our hope (and basic belief) was that we can achieve a similar effect

for PAIS if we are able to develop the adequate underlying theory.

Our ambition was to develop a technology for PAIS, which is broadly applicable,

i.e., not only to simple administrative processes, but also to highly dynamic and com-

plex ones (e.g., diagnostic and therapeutic processes [40, 20, 21, 12]). The challenge

was to develop a technology which supports “correctness by construction” during pro-

cess composition and which guarantees correctness in the context of ad-hoc changes

at the process instance level. This challenge was probably the most influential one for

the whole ADEPT project. It had significant impact on the development of the ADEPT

process meta model as well as on our work on process flexibility and process adaptivity.

It meant, in essence, the following:

1. We have to hide the inherent complexity of process-orientation (especially in con-

junction with flexibility) as far as possible from system administrators and applica-

tion programmers; i.e, we have to perform all complex things “beneath the surface”

in the process management system.

2. We have to provide powerful, high-level interfaces to application programmers,

based on which they can implement easy to use end user interfaces.

When developing the ADEPT process meta model we were in a dilemma. On the

one hand our analyses had shown that clinical processes can be complex structured;

e.g., comprising alternative/parallel branchings and loops. A process meta model should

therefore provide appropriate concepts to represent these structures adequately, i.e., it

should be expressive enough. On the other hand our goal was to enable comprehensive

and efficient correctness checks during process modeling as well as in conjunction with

ad-hoc instance changes. The available theoretical works on flexible processes at that

time either required simple process models (e.g., without loops [41], or without consid-

ering data flow [41, 42]), or required expensive analyses to decide whether or not the

desired ad-hoc change can be granted [43].

Expressiveness of a process meta model has two major aspects: One is the ability

to model a large variety of control flow structures in terms of process patterns [44]. An-

other one is how easy the semantics of the meta model constructs or the resulting control

flows can be understood. First experiences indicated that process modeling based on

states and transitions (as used in Petri Nets for example) is not very easy to understand

for end users (i.e., doctors and nurses in our case). Another issue was that this notation

quickly leads to large process models due to many symbols. Opposed to that, Activ-

ity Nets [45] were much easier to understand, but this approach had other weaknesses,

including the missing support of loops and the context-dependent execution semantics

of nodes; e.g., depending on its context the syntactic symbol for an activity node may

represent a normal (sequential) node, an XOR split/join, or an AND split/join. We also

elaborated other formalisms (e.g., state and activity charts, rule based approaches), but

considered them not being appropriate for our purpose. Altogether the procedure of

defining the ADEPT process meta model was no easy task and lasted several months

during which we evaluated many aspects and their impact on the meta model and vice

versa. Most headaches were caused by two partially conflicting goals: expressiveness

and formal verification. All ideas were evaluated against the clinical processes we had

acquired in our hospital projects.

The resulting process meta model as illustrated in Fig. 4 (see [46, 47] for details)

does not look very fancy at first glance. However, its “ingredients” were carefully se-

lected and complement each other. Thus the process meta model is very helpful with re-

spect to formal verification, ad-hoc changes, and process schema evolution. Its strength

is the underlying theory which supports both correctness by construction and efficient

consistency checks [48, 49]. This theory precisely defines correctness criteria for the

ADEPT meta model (e.g., absence of deadlocks, no isolated nodes, all data flows cor-

rect under all possible executions). It defines a comprehensive set of change operations

with pre-/post-conditions which ensure that, if the desired change satisfies the precon-

ditions, the resulting process schema will again be correct. The ADEPT change opera-

tions, for example, allow to serially insert an activity between two nodes, to insert it in

parallel or between two node sets, to move activities, to delete activities, and so forth.

All these operations obey that data flow correctness is not violated [48, 47].

Another important property of the ADEPT process meta model is that it incorpo-

rates not only the information on the current state at the instance level, but also infor-

mation on how this state was reached. This allows to quickly decide whether a desired

ad-hoc change can be granted or whether it affects an already passed region of the pro-

cess instance. The latter could (among other things) cause data flow problems and is

therefore prohibited (with some exceptions concerning loops [17]).

The block structuring of the process meta model was motivated by three aspects:

First, experiments have shown that they are easier to handle and to understand for users

when compared to unstructured process models. Second, it allows to restrict the area in

the graph which has to be analyzed in the context of ad-hoc changes. This, in turn, helps

to speed up the required analyses [48]. Third, it significantly simplifies the resulting

structural adaptations of the process schema [49].

Fig. 4: ADEPT Process Meta Model

5 Achievements

The achievements described in the following refer to the ADEPT2 technology, and are

structured along the challenges identified in Section 3.

5.1 Achievement: Ease of use for process implementers

For process modeling, ADEPT2 provides an intuitive graphical editor. It applies a cor-

rectness by construction principle by providing at any time only those operations to the

process implementer which allow to transform a structurally correct process schema

into another one.

Operations are enabled or disabled according to which region in the process graph

is marked for applying an operation. Fig. 5 and Fig. 6 illustrate this relationship.

In Fig. 5a no nodes are marked. As a result, all operations in Fig. 6a are disabled,

except Insert Data Element (which is not visible here). In Fig. 5b only activity “Or-

derProc” is marked and, therefore, those operations are enabled (cf. Fig. 6b) whose

effects comply with this selection (e.g., to insert a surrounding AND block, a surround-

ing XOR block, a surrounding loop block, or to delete the selected activity). In addition,

Insert Data Element (which is always applicable) is selectable again. In Fig. 5c two

ADEPT-CSRD--39.doc − 10 −

formal verification, ad hoc changes, and process schema evolution. Its strength is the underlying theory

which supports both, correctness by construction as well as efficient consistency checks [ReDa98,

WRR08]. This theory precisely defines correctness criteria for the ADEPT process model (e. g. absence

of deadlocks, no isolated nodes, exactly one start end and one end node, all data flows correct under all

possible executions). It defines a comprehensive set of change operations with preconditions and post-

conditions which ensure that – if the desired change satisfies the preconditions – the resulting process

graph is again correct. The change operations comprise simple serial inserts between two nodes, parallel

insert between node sets, move operations, delete operations, etc. Of course, all these operations obey

that the correctness of the data flows is not violated (for a detailed description see [ReDa98]).

Another important property of the ADEPT process meta model is that it incorporates not only the informa-

tion on the current state at the instance level but also information how this state has been reached. This

allows to quickly decide whether a desired ad hoc change could be granted or if it would affect an histori-

cal state of the process instance. The latter could (among other things) cause data flow problems and,

therefore, is prohibited. – The block structuring of the process meta model was motived by three aspects:

Fristly, some experiments with users have shown that they are easier to handle and to understand for

them than when using unstructered process models. Secondly, it allows to restrict the area in the graph

which has to be analyzed in the context of ad hoc changes which in turn helps to speed up the required

analyses [ReDa98]. Thirdly, it simplifies significantly the resulting structural adaptations of the process

graph.

5 Achievements

For the subsequent discussion we refer to the challenges described in Section 3.

5.1 Achievement: Ease of use for process implementers

For process modelling, ADEPT2 provides an easy to understand graphical user interface. It applies a

"correctness by construction" principle by providing at any time only those operations to the process im-

plementer which transform a structurally correct process scheme into another structurally correct process

scheme. Operations are enabled or disabled according to which region in the graph has been marked for

applying an operation. Figure 5 and Figure 6 illustrate this relationship. In Figure 5.a no nodes are

marked. As a result, all operations in Figure 6.a are disabled, except "Insert Data Element" (which is not

visible here). In Figure 5.b only the node "OrderProc" is marked and, therefore, those operations are

enabled (cf. Figure 6.b) whose effects are precisly defined by this marking, like, e. g., Insert a surrounding

AND block, a surrounding XOR block, a surrounding loop block, or the deletion of the selected node. Also

"Insert data element" (which is always applicable) would be selectable again. In Figure 5.c two directly

adjacent nodes are marked. The green color indicates "begin of marked area" and the blue color indi-

cates "end of marked area". Again, those operations are enabled whose effect is precisely defined by

such kind of marking (cf. Figure 6.c): In addition to the operations of the previous example, also the "in

between" variants of these insertions are now enabled as well as the operation "Insert Node". At first

glance it may be astonishing that the marking illustrated in Figure 5.d only enables the operations illus-

trated in Figure 6.d (plus "Insert Data Element"). However, only for these operations the effect is precisely

defined by these markings. – Deficiencies not prohibited by this approach are checked on the fly and

reported continuously in the problem window of the Process Template Editor as illustrated in Figure 7.

Figure 5: Markings in the process graph

Fig. 5: Markings in the process graph

ADEPT-CSRD--39.doc − 11 −

a) b) c) d)

Figure 6: Enabled change operations

Another important goal was make the assignment of application functions or services to process steps as

simple as possible. That is a conventional process implementer should not need to have any detailed

knowledge about implementation details of these components. However, this should not be achieved for

the price to undermine the correctness by construction principle. Both goals have been fully achieved. All

kinds of executables which can be associated with process steps are first registered in the Activity Re-

pository as so-called Activity Templates. An activity template provides all information to the Process

Template Editor (more precisely: the ADEPT2 service functions it is utilizing for this purpose) about man-

datory or optional input and input parameters as well as data dependencies to other activity templates.

The process implementer just drags and drops an activity template from the Activity Repository Browser

window of the Process Template Editor (see Figure 8) onto the desired location in the process graph like

indicated in Figure 2.

Figure 7: Reporting of detected deficiencies

Fig. 6: Enabled change operations

adjacent nodes are marked. The green color4indicates “begin of marked area” and the

blue color5indicates “end of marked area”. Again, those operations are enabled whose

effect is precisely defined by such kind of marking (cf. Fig. 6c): In addition to the op-

erations of the previous scenario, also the “in between” variants of the insertions are

now enabled as well as the operation Insert Node. Finally, regarding the marking

from Fig. 5d, at first glance, it might be astonishing that only the operations depicted in

Fig. 6d (plus Insert Data Element) are enabled. However, only for these operations

the effect is precisely defined for the given markings.

Deficiencies not prohibited by this approach (e.g., concerning data flow) are checked

on-the-fly and are reported continuously in the problem window of the Process Tem-

plate Editor (cf. Fig. 7). Another goal was to make the assignment of application func-

tions to process steps as simple as possible; i.e., a process implementer should not

4light gray in a grayscale printout

5dark gray in a grayscale printout

need to know details about the implementation of application functions. However, this

should not be achieved by undermining the correctness by construction principle. Both

goals have been achieved. All kinds of executables, that may be associated with process

steps, are first registered in the Activity Repository as activity templates. An activity

template provides all information to the Process Template Editor about mandatory or

optional input and output parameters, as well as information about data dependencies

to other activity templates. The process implementer just drags and drops an activity

template from the Activity Repository Browser window of the Process Template Editor

(cf. Fig. 8) onto the desired location in the process graph (cf. Fig. 2).