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

Computer Science - Research and Development manuscript No.

(will be inserted by the editor)

Peter Dadam ·Manfred Reichert

The ADEPT Project: A Decade of Research and

Development for Robust and Flexible Process Support

Challenges and Achievements

Submitted: date / Accepted: date

Abstract This paper gives insights into the ADEPT

project. Its target was to develop a next generation pro-

cess management technology, which is by orders of mag-

nitudes more powerful and flexible than contemporary

process management systems. The ADEPT technology

should provide advanced features and properties within

one system, which seem to exclude each other, but which

are required for the support of a broad spectrum of pro-

cesses: ease-of-use for end users and system developers,

high flexibility through the support of non-trivial ad-hoc

deviations at the process instance level, quick implemen-

tation of process changes through process schema evolu-

tion, and correctness guarantees enabling robust execu-

tion of implemented processes. This paper describes the

background and the real-world cases which motivated

our research. It further explains the technological chal-

lenges we faced, describes the solutions we elaborated,

and discusses the current status of the ADEPT project.

Keywords Workflow Management ·Business Process

Management ·Process Flexibility ·Process Change ·

Correctness by Construction ·Robustness

CR Subject Classification H.4.1 ·D.2.2 ·D.2.11

1 Background - how all began

In 1992 we started the OKIS1project – a pretty large and

broadly defined 3-years research project funded by the

State of Baden-W¨

urttemberg. In this project several cli-

nics, medical service units, and the computing center of

Peter Dadam and Manfred Reichert

Institute of Databases and Information Systems

University of Ulm

89069 Ulm, Germany

Tel.: +49/731/50-24131

Fax: +49/731/50-24134

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

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”

our university hospital were involved. The goal of OKIS

was to develop a concept for a cross-organizational, cli-

nical information system that is able to integrate auto-

nomous, heterogeneous departmental systems as well as

to offer services across system boundaries (e.g., schedu-

ling, 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 in-

formation systems involved (e.g., radiology information

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 developments (at that point in

time) like electronic patient record, communication ser-

vers, medical guidelines, and computer-assisted medical

diagnostics in order to understand which features a mo-

dern hospital information system should have [27].

The challenge of the service layer we wanted to de-

velop was rather clear in an early stage of the project:

Due to the heterogeneity of the underlying systems and

the evolutionary 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 complicated. Therefore, long before web services

came into the game, we had elaborated the concept of a

cross-organizational “service bus” (that we called “soft-

ware bus” in [28]; see Fig. 1) into which new services

can be easily plugged in such that application programs

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

While working on many different aspects of the over-

all 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 clo-

ser look at the clinical workday. During these activities

it became more and more clear that the really big pro-

blem was not the inconvenient access to medical data.

2 Peter Dadam and Manfred Reichert

Abb. 1 OKIS software bus [28]

The much bigger and more challenging problem was the

non-existing support of the clinical processes! These pro-

cesses were only in the users’ minds. Notes on paper or

entries in a calendar system were the only help for phy-

sicians and nurses to not forget things. No active process

support or assistance by an information system was pro-

vided to avoid problems like omission errors, unnecessa-

rily pending tasks, or non-optimal task sequences (see

[15] 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 we-

re convinced that a software technology, which is able

to cope with clinical processes, would be also adequa-

te for many other domains and enable completely new

perspectives for information management systems. The-

refore, 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. Ne-

vertheless 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.

Section 2 provides some insights into the clinical reali-

ty and identifies major requirements. Section 3 describes

relevant challenges and the research areas of the ADEPT

project. Section 4 discusses the overall technological chal-

lenges 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.

2ADEPT stands for “Application Development based on

Encapsulated Pre-modeled Process Templates”

2 Facing the clinical reality

Our initial insights into relevant requirements were de-

rived 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 pro-

ject we analyzed and documented the core processes of

this hospital, investigated organizational aspects (e.g.,

actor responsibilities, substitution rules, or legal regu-

lations), and evaluated what kind of exceptional cases

had occurred in the past and how good they were “pre-

dictable”. 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 [13]. The issues des-

cribed in the sequel represent consolidated insights from

both projects (and are valid until today).

Robustness. By nature, clinical information systems

should be highly reliable. However, process-aware infor-

mation systems (PAIS) are inherently more complex than

traditional function- and data-centric information sys-

tems, 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 on-

ly in the users’ minds [39]. Of course, humans also make

mistakes when performing processes, but these errors are

typically not charged to the information system. Howe-

ver, once processes are directly supported by a PAIS, all

process-related errors (e.g., deadlocks or program cras-

hes 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 clinical environment any

PAIS will not be accepted by users if rigidity comes with

it. Deviations from the standard procedure constitute

the normal case, and physicians and nurses are accusto-

med to perform such deviations. The physician always

has the ultimate professional authority and responsibili-

ty 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. However, the demand for fle-

xibility is not only present in hospitals, it can be found

in almost all domains (e.g., [4; 5; 32; 33; 35; 58]). 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 [35].

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

technological solution could then concentrate on control

The ADEPT Project 3

flow and would not have to deal with data flow issues.3

Instead, 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 ap-

plication integration. In addition, runtime flexibility can-

not be restricted to simple adjustments of a process sche-

ma (e.g., by replacing one activity by another), but more

complex structural changes at the process instance le-

vel should be possible as well. For example, an ongoing

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 de-

veloping 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 ma-

nagement technology in the clinical domain (and not on-

ly there). Clinical staff works under high time pressure,

must often deal with exceptional situations, and is con-

stantly confronted with an information overload [15; 29].

This situation especially applies to university hospitals

which typically receive all complicated treatment cases

that ordinary hospitals are not able to handle. In addi-

tion, university hospitals educate physicians and nurses;

i.e., there are many staff members who are not very expe-

rienced. This, in turn, increases the pressure on clinical

staff. Some staff members have stress because of their

own missing routine and experience, while others suf-

fer 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., somebo-

dy 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 mo-

dels) 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 ap-

plication programmers in order to avoid PAIS failures

3In this scenario there is no other data flow among pro-

cess activities than the document which is passed from one

activity to another during runtime.

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 imple-

menter, 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 pro-

ject 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 se-

veral 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 import-

ant that the process meta model is expressive enough. As

another relevant factor process implementers should not

need to know any implementation detail about the appli-

cation 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 applica-

tion 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 si-

de in order to ensure that the composed process will be

executable without runtime errors (e.g., concerning tes-

ting). 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 com-

plemented by comprehensive correctness checks [8; 14]

(cf. Fig. 2). Our target was to accomplish these checks in

such a way that runtime errors 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 so-

mehow made known to the PAIS to be incorporated into

the correctness checks. From our practical experiences

it further became clear that intuitively 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 er-

rors when checking correctness.

4 Peter Dadam and Manfred Reichert

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-

Abb. 2 Composition of processes using plug & play [11]

Another important issue concerns changes at the pro-

cess type level. In the clinical domain it is very important

that applied treatment procedures reflect the prevailing

state of medical knowledge. Therefore, it must be pos-

sible to adapt them when medical knowledge changes.

Such changes may also affect ongoing cases, i.e., it must

be possible to modify a process schema and to migrate its

instances to the new schema (we denote this as process

schema evolution [10; 49]). As motivated such change

feature should be easy to use (for the process specia-

list), 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 con-

fronted with legacy systems offering special application

functions to users. These legacy systems are implemen-

ted based on different platforms, have tasks which requi-

re 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 the-

se heterogeneous application functions in a homogenized

form to process implementers in order to make process

composition in a plug & play fashion a reality. Our visi-

on was that the process template fully encapsulates 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 addition,

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 pro-

vide an easy to use implementation framework with in-

tuitive application programming interfaces to perform

all these tasks. Our maxim was to make the implemen-

tation of application components for a PAIS not more

complicated than developing them for conventional ap-

plication 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., pla-

cement of information at the desktop, arrangement of

entry fields, use of buttons, or selection of colors. We al-

so 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 (sup-

posed that they have the permission to do that [54; 60]).

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 acceptan-

ce 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 pro-

vide a sufficient level of abstraction. 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 illustrate how the inter-

action between PAIS and end user may look like, pre-

suming that the user is able to understand the meaning

of a simplified (i.e. abstracted) process graph. Regar-

ding this example assume that during the execution of

a process instance (e.g., the treatment of a certain pati-

ent under risk) an additional lab test becomes necessary.

Assume that this has not been foreseen at process im-

plementation 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 func-

tions 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 exe-

cution 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

The ADEPT Project 5

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

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

as well as the necessary adaptations of the process struc-

ture, data flow, and instance state should be completely

performed by the PAIS. In addition, the PAIS should al-

low 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).

This example illustrates a rather simple user inter-

face. If more sophisticated, knowledge-based user inter-

faces are needed (e.g. [34; 19; 65]) 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

one activity by another or to just add a single activity

directly before or after the currently 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

6 Peter Dadam and Manfred Reichert

modeling and process 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 frequently, it is often desirable

to use a knowledge management system to support the

user in detecting whether or not a similar exception al-

ready 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 “recycle” previous deci-

sions and to automatically reapply changes at the process

instance level [51; 61; 63; 65].

Not directly related to ease of use, but also import-

ant 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, response 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 interac-

tive tasks.) This means that the resulting solution must

also use efficient algorithms for adapting process instan-

ces and for checking their correctness. Further, they must

ensure short response times for scenarios in which ma-

ny process instances are simultaneously executed by the

PAIS. And the latter will be the normal case in large-

scale environments where thousands of process instances

are concurrently executed at the same time [7].

3.4 Complex ad-hoc changes and schema evolution

As discussed in Section 3.3 a PAIS should allow to hand-

le all kinds of exceptional situations. In order to enable

this without need for circumventing the PAIS, arbitrari-

ly complex ad-hoc changes at the process instance level

must be possible; e.g., authorized 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 out-

sourcing or insourcing tasks, and so forth in order to im-

prove 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 chan-

ges 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 includes 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 process

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 tech-

nological 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 men-

tion 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 simultaneously. Therefore, any

PAIS which does not scale up and which does not work

in a cross-organizational setting will fail in such an envi-

ronment. As the clinics of a university hospital may be

geographically dispersed, it is rather unrealistic to assu-

me that a centralized PAIS will always be the appropria-

te solution. Instead, concepts for the flexible, distributed

execution of processes had to be found [6; 7; 40; 37].

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 in-

juries 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 complete-

ly independent from each other. Problems of this kind

require concepts for inter-process coordination [22; 23].

Deadlines and temporal constraints play an import-

ant role in the clinical domain as well. Typically an ap-

pointment (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 be-

come necessary. This drug should be administered not

The ADEPT Project 7

too early and not too late to achieve the desired effects.

Future PAIS should therefore incorporate appropriate

support for temporal constraint management [15; 20].

Finally, there are other challenges we have dealt with,

but which we cannot discuss in detail. They include issu-

es related to the learning from changes [21; 30], the effi-

cient representation of changes in adaptive PAIS [53; 52],

the visualization of business processes [9], and the evolu-

tion of organizational models and corresponding access

rules [31; 54; 55].

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 mo-

re powerful 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, re-

garding 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 storage

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 optimizati-

on, concurrency 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 ad-

ministrative processes, but also to highly dynamic and

complex ones (e.g., diagnostic and therapeutic processes

[24; 34; 19; 29]). The challenge was to develop a technolo-

gy which supports “correctness by construction” during

process composition and which guarantees correctness in

the context of ad-hoc changes at the process instance le-

vel. 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 conjunction with flexibili-

ty) as far as possible from system administrators and

application 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 structu-

red; e.g., comprising alternative/parallel branchings and

loops. A process meta model should therefore provide

appropriate concepts to represent these structures ade-

quately, 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 eit-

her required simple process models (e.g., without loops

[1], or without considering data flow [1; 66]), or required

expensive analyses to decide whether or not the desired

ad-hoc change can be granted [17].

Expressiveness of a process meta model has two ma-

jor aspects: One is the ability to model a large variety of

control flow structures in terms of process patterns [59].

Another one is how easy the semantics of the meta model

constructs or the resulting control flows can be under-

stood. 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, Activity Nets

[26] 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 sym-

bol for an activity node may represent a normal (sequen-

tial) 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 pro-

cedure 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 [41; 36] for details) does not look very fancy

at first glance. However, its “ingredients” were carefully

selected and complement each other. Thus the process

meta model is very helpful with respect to formal ve-

rification, ad-hoc changes, and process schema evoluti-

on. Its strength is the underlying theory which supports

both correctness by construction and efficient consisten-

cy checks [38; 64]. This theory precisely defines correct-

ness criteria for the ADEPT meta model (e.g., absence of

8 Peter Dadam and Manfred Reichert

deadlocks, no isolated nodes, all data flows correct under

all possible executions). It defines a comprehensive set of

change operations with pre-/post-conditions which ensu-

re that, if the desired change satisfies the preconditions,

the resulting process schema will again be correct. The

ADEPT change operations, for example, allow to serial-

ly 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 [38; 36].

Another important property of the ADEPT process

meta model is that it incorporates not only the infor-

mation on the current state at the instance level, but

also information on how this state was reached. This al-

lows to quickly decide whether a desired ad-hoc change

can be granted or whether it affects an already passed

region of the process instance. The latter could (among

other things) cause data flow problems and is therefore

prohibited (with some exceptions concerning loops [49]).

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 [38]. Third, it si-

gnificantly simplifies the resulting structural adaptations

of the process schema [64].

Abb. 4 ADEPT Process Meta Model

5 Achievements

The achievements described in the following refer to the

ADEPT2 technology, and are structured along the chal-

lenges 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 correctness 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.

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

Abb. 5 Markings in the process graph

In Fig. 5a no nodes are marked. As a result, all opera-

tions 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 se-

lection (e.g., to insert a surrounding AND block, a sur-

rounding 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 adjacent nodes are marked. The green co-

lor4indicates “begin of marked area” and the blue color5

indicates “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 operations of

the previous scenario, also the “in between” variants of

the insertions are now enabled as well as the operati-

on Insert Node. Finally, regarding the marking from

Fig. 5d, at first glance, it might be astonishing that on-

ly 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 re-

ported continuously in the problem window of the Pro-

cess Template Editor (cf. Fig. 7). Another goal was to

make the assignment of application functions to process

steps as simple as possible; i.e., a process implementer

should not need to know details about the implementa-

tion 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 informati-

on to the Process Template Editor about mandatory or

4light gray in a grayscale printout

5dark gray in a grayscale printout

The ADEPT Project 9

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

Abb. 6 Enabled change operations

optional input and output parameters, as well as infor-

mation about data dependencies to other activity tem-

plates. 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).

Depending on the intended purpose of usage, an ac-

tivity template can be very specific or rather generic.

When using a specific template everything can be fixed;

e.g., the input and output parameters and all settings. In

this case, the only remaining task for the process imple-

menter is to check whether the proposed mapping of in-

put/output parameters to process data elements (i.e., the

process variables used within this process to communica-

te among activities) is correct. Using a specific database

activity template, for example, allows to fix the input

and output parameters, the details of the database used,

the connection parameters, and the fully specified SQL

statement. A more generic Activity Template, in turn,

may leave open the SQL statement, the number and ty-

pes of input and output parameters, or the settings for

the database connection (in parts or even completely).

5.2 Achievement: Ease of use for application developers

As discussed in the previous section, all application func-

tions are represented by activity templates; i.e., a devel-

oper who wants to provide a new application function

or service must implement a corresponding activity tem-

plate and add it to the Activity Repository. This ma-

kes it then available and accessible within the ADEPT2

Process Template Editor during process modeling (cf.

Fig. 8). To simplify the implementation of such activity

templates, ADEPT2 provides several levels of abstrac-

tion. At the lowest one ADEPT2 provides a so-called

Execution Environment for each kind of basic operation

supported by ADEPT2. For example, ADEPT2 offers

execution environments for SQL statements, web ser-

vices, EXE files, BeanShell scripts, basic file operations,

and system-generated forms. However, the implementa-

tion of an execution environment requires some knowled-

ge about ADEPT2 internals and, therefore, will typically

not be the task of an ordinary application developer, but

will be performed by system implementers.

An execution environment defines the set of methods

needed to interact with the ADEPT2 runtime system as

well as to implement the operations and facilities that

shall be provided by the activity template. An activity

template for database access, for example, may allow the

user to specify connection details as illustrated in Fig. 9.

In general, the ADEPT2 runtime environment needs

some information about the runtime behavior of the acti-

vities; e.g., whether or not they may be aborted, suspen-

ded, or undone. The implementer of an activity templa-

te has to implement interface methods that inform the

ADEPT2 runtime environment which of these facilities

are supported by the activity. For this case he must al-

so provide the implementation of this functionality (see

[45] for background information on ADEPT2 internals).

The task of implementing a new activity template will

be simple, if it can be based on a generic activity tem-

plate. In this case, the implementation is essentially re-

duced to putting the appropriate entries into the set of

forms representing the activity template. For example, if

a database activity template shall be implemented which

selects a tuple from a predefined relation in a predefined

database based on a primary key value, one form will fix

the required input parameters and the output parame-

ters for the attribute values of the tuple, a second one

the database connection (cf. Fig. 9), and a third one the

SQL statement (cf. Fig. 10). Fig. 8 lists examples of

specialized activity templates which offer different kinds

of operations on a customer table.

10 Peter Dadam and Manfred Reichert