Distributed Ad Hoc Cooperation in Healthcare

Christoph P. Neumann and Richard Lenz

Friedrich-Alexander-Universität Erlangen-Nürnberg,Computer Science 6 (Data Management), Erlangen, Germany,

{christoph.neumann|richard.lenz}@cs.fau.de

Abstract. Inter-institutional cooperation among physicians becomesincreasingly important. Yet, it is unrealistic to assume that coopera-tion can be supported via a homogeneous system that is pre-installed inevery organization. Instead, physicians will typically have their own au-tonomous systems that support internal processes. Traditional activity-oriented workflow platforms do not resolve inter-institutional integra-tion challenges. This paper presents an approach for distributed processmanagement, which enables ad hoc cooperation via active electronicdocuments without the need to integrate local systems. A distributedcase file is used to coordinate cooperating parties. Using this case filedoes not require any preinstalled system components, so genuine adhoc information exchange is enabled.

1 IntroductionSupporting inter-institutional cooperation by means of IT is a challenge. InGerman healthcare, the key factor of medical cooperation is currently aboutexchanging paper-based information (e.g., [1]). Such cooperations suffer fromsystem fragmentation which means that patients receive care from multipleproviders, who rarely coordinate the care they deliver (e.g., [2]). Since the 80s,system fragmentation in healthcare is countered by the concepts of continuity ofcare and integrated care (cf. [3]). However, inadequate information availabilityis still a well-known issue for healthcare scenarios (e.g., [4]). The primaryinhibiting factor for successful IT support is unsolved system integration (e.g.,[5]). Berger’s famous study [6] in 1997 described his vision of Electronic HealthRecords (EHRs) as IT solution to integrated care. Yet, a large-scale and nation-wide EHR environment EHR infrastructure is still far from sight.

As remainder of the introduction, the problem statement and objectives areoutlined and our vision of distributed case handling is illustrated in form of auser story. The following section describes methods of active documents andprocess management and discusses conceptual contributions of our approach.The third section provides a synopsis of the technical aspects of our prototypicalimplementation. The final section concludes the paper by discussing the benefitsof the overall approach.

1.1 Problem StatementOur primary use case is an inter-institutional healthcare scenario. When westarted our research project, we had the premise: “There is no adequate in-frastructure to support an emergent willingness to cooperate.” This remains

true for healthcare and any other domain. Thus, two primal scientific questionshave been the driver of our work: (1) “Can we develop an infrastructure thatallows us to enable emergent ad hoc processes?” and (2) “To which degree canwe establish information exchange without prior system integration?”. Suchan infrastructure must provide functionality beyond email, being adapted totypical needs of cooperation.

In order to minimize the initial effort for establishing an information ex-change, we were looking for an evolutionary and decentralized approach. Thetraditional approach to manage such healthcare processes is based on paperdocuments with a dedicated semantics, such as a referral or a discharge letter.We adopt and extend this paper-based interaction paradigm to support morecomplex cooperation scenarios.

Organizational independence at a nation-wide scale requires adhering tothe strict autonomy of the involved IT systems. Although comprehensive ITsupport for closely meshed treatment scenarios in general has unsolved legalboundary conditions, our approach outlines an architecture for distributed casefiles as a technical foundation. It is based on digital information units that areyielded1 from institutional EHR into a distributed publish-subscribe system thatsynchronizes the case files between participants. The case handling engine isbundled in an installation-free artefact, which is replicated and which managesindividual case file data.

The resulting artefact complies with the idea of ‘active’ document, whichhas been first described by Dourish et al. for their Placeless Documents in [7],and which will be further explained. Thus, the primary artefact of our approachis named α-Doc, with the “α” symbolically implying the term “active”. Theoverall approach is named distributed Document-oriented Process Management(dDPM) and our system implementation is called α-Flow. Various aspects aboutthe α-Flow system and the dDPM approach have been published in [8–14].The system is implemented and evaluated. Both the approach and furthertechnical details are described in a PhD thesis [15]. In comparison to [8–15] thecontribution of this paper is an overall summary of that work.

1.2 User Story: A Hypothetical Cooperation

To illustrate our vision of distributed inter-institutional case handling, thissection describes a user story of a hypothetical scenario. It is written as ananalogy to Berger’s study. Our user story has first been published in [14]. It isbased on a breast cancer treatment scenario2.

“... The patient prepares to leave the gynaecologist’s consulting room. Justyesterday she spotted a knot in her breast. The gynaecologist has just completeda sonography and the knot seems to be dubious. In his mind the future unfolds:he needs to send her first to a radiologist (for a mammography) and afterwards,if necessary, to a colleague at the local hospital (for biopsy and histology) in1 An important aspect about inter-institutionally shared information is that it must

necessarily be printable, thus, it can always be captured as digital document (in atleast one format; irrespective of the format’s suitability for semantic integration).

2 The analysis of the breast cancer scenario and its inter-institutional medical pro-cess, in [8, 9] and combined in [15], is part of our overarching contribution.

order to determine if it is breast cancer. Such misfortune will bring her to theuniversity hospital in the major city nearby for primary therapy. It is likelythat more than half a dozen of doctors will be involved and the referral to theradiologist is the potential beginning of a complex collaboration to save hispatient’s life.

The doctor sits before his desktop computer. He drops the original referralfile onto a special icon on his desktop and thereby transforms it into a case file.His colleagues will become participants to the case as soon as they have accessto a copy of the case file. The case file is an active document: changing thefile in one copy will automatically synchronize information with its distributedcopies. The case file supports emergent complexity.

The case file includes the referral as its first information unit and it includesthe gynaecologist’s own electronic address. The doctor stores the case file tothe patient’s chip card.

... The radiologist’s receptionist can open the case file without any particularinstallation on his system. Opening the case file will launch an embedded viewer,in which the receptionist can open the embedded referral with his local system.During the admission, the receptionist stores the case file into the local patientrecord as a file attachment for his boss to access after the examination.

... The radiologist has finished the mammography and his report is ready.Normally he would send the report to the gynaecologist. Instead, he just opensthe case file and drag-and-drops the electronic report into it. Because the casefile holds the electronic address information for the other participants, the activedocument will send the new report to the gynaecologist’s electronic post box.The radiologist likes it, because the active document holds the collaborationcontext and makes things easy.

... The patient returns to the gynaecologist’s office. The gynaecologist openshis copy of the case file and it automatically synchronizes its content with thegynaecologist’s electronic post box. The report of the radiologist appears asthe newest information unit. He opens the report. The value of the BI-RADSindicator is higher than four; the patient must go to the local hospital for abiopsy. Thus, he prepares another referral and puts it into the case file.

Again, he copies the current case file on the patient’s chip card. The hospitalwill contribute the report of the biopsy operation. The tissue and the case filewill be sent to the pathologist. He will contribute the histology report to thecase file. The gynaecologist’s case file will always receive any information thatis contributed by future participants.

The gynaecologist looks at his patient. He assures her that there is stillsome chance that the histology proves that it is not a malignant tumour. ...”

2 Methods and Contributions

The user story involves various types of human-machine interaction. First,we have the transformation from the case-initiating referral document intoan active document (i.e. α-Doc) for distributed case management. Figure 1illustrates the initiation and the changes to the distributed case file. It outlinesthe scenario from a more technical perspective. The referral is supposedly inHL7 CDA format, thus, it is illustrated in the figure by a circle being labelled

with “XML”. The four major rectangular shapes being labelled with “α-Doc”each illustrate the active document in different content states at various pointsin time and at the two different sites.

RVM XML

α-Doc (Gyn)

RVM XML

α-Doc (Gyn)

RRM PDF

RVM XML

α-Doc (Rad)

RVM XML

α-Doc (Rad)

RRM PDF

Desktop

ownership

read only

sync

Direct Interaction

Automation byActive Properties

put-c

ard

XML

Referral Voucher

Result Report

RV

RR

PDFAdmis-sion

Mammo-graphy

Content Payloads

open

-pay

l.

tran

sfor

m

The α-Doc Replicatesof the dDPM approach

are physically distributedbut logically centralised

Referral Voucher

copy α-Doc

as data file

file system transfer(email, flash drive, ...)

Case File asActive Document

α-DocReplicate

Content

Descriptors

Fig. 1. An α-Doc that changes during the user story

2.1 Active Document Characteristics

The initializing referral voucher is a data file (“file” as in computer file system).The referral and the mammography report become content units within thecase file (“file” like dossier, envelope, or ring binder). The case file is an activedocument that is ‘molecularly’ structured, internally. Physicians may assumethat it is basically something like a (self-executable) ZIP archive. More specifi-cally, the Java programming language allows for executable ZIP files in form ofJAR files.

The assimilation of the “XML”-labelled circle into the active document ismeant literally. The circles within the α-Doc are accompanied by small rectan-gles; these are small descriptor data files. Descriptors will ultimately allow forarbitrary process-relevant meta data about a content unit. For now, assumethat it just describes the name for its content unit and stores which participanthas contributed the content unit. The content unit and its descriptor are sym-bolized with a dashed frame if the content unit is not owned and contributedby the actor at the site.

The user story describes that the active document can be stored to a chipcard, it can also be a flash drive or anything that stores data files. Thus, froma file system perspective the molecular active document is still a coherentlyhandled and portable data file unit and it must be possible to apply file copy

or file move operations as well as to use it as an email attachment or fileattachment to a local patient record. This characteristic is symbolized by the“copy α-Doc” arrow in figure 1. It simply replicates the α-Doc.

At the radiologist’s site, the α-Doc can be executed and an embedded editorlists the included content units. For now, assume that the embedded editorallows for opening the payloads as easily as a file attachment within an email ap-plication. The payloads are opened with a locally available application, likewiseto the email attachment metaphor. Each participant can contribute further con-tent units, for example the “PDF”-labelled circle for the mammography report,by simple drag-and-drop.

After a contribution has been performed locally, all other known participantsmust be provided with a copy of the new content unit. This is illustrated withthe specially shaped “sync” arrow. For now, assume that each contribution mustbe synchronized with all other α-Doc replicates of the same case. Notably, theα-Docs are only active if they are explicitly executed by its user. The remotereplicates are not (necessarily) online at the same time; instead, an offlinecharacteristic is dominant. Thus, the synchronization facilities must involve anunderlying infrastructure for store-and-forward messaging.

In conclusion, our user story focuses on the operational embedding, i.e. theconduct of an α-Doc case file within healthcare routine. The user story naturallyemphasizes active document requirements. The complemental aspect is aboutthe process-related benefit for the user, i.e. which kind of process support isprovided by α-Docs.

2.2 Process Support CharacteristicsThe term “process” can be defined as an “organizational form that encapsulatesthe interdependence of tasks, roles, people, departments, and functions” [16].Further sub-classifications can be made. For example, Medina-Mora et al. distin-guish material process, information processes, and business processes (cf. [17]).McCready distinguishes three types of workflows in [18]: ad hoc workflows,administrative workflows, and production workflows. Georgakopoulos et al. pro-vide a classification of workflows in [19] and use system-oriented workflows andhuman-oriented workflows as antipodes. In addition, three degrees of processconception can be distinguished: process description, workflow specification,and workflow automation (cf. [19])

The well-known Workflow Management Coalition (WfMC) provides a refer-ence for activity-oriented workflow approaches in [20]. Yet, it does not considerprocesses in the broadest sense, instead, the WfMC view is restricted to “busi-ness processes” [20, p. 10] and regards a workflow solely as the part of a businessprocess that can be executed automatically. In conclusion, we consider the lit-eral and automation-centric WfMC definition of “workflow” as overly restrictivein the overarching context of process support. Rusinkiewicz and Sheth in [21]provide a more general definition: “Workflows are activities involving the coor-dinated execution of multiple tasks performed by different processing entities.A task defines some work to be done and can be specified in a number of ways,including a textual description in a file or an email, a form, a message, ora computer program. A processing entity that performs the tasks may be aperson or a software system”.

All things considered, the dividing line between process support in thebroadest sense and workflow management in the narrowest sense is not alwayssharp. The dDPM approach addresses human-oriented, knowledge-driven, adhoc information workflows. Process support is provided by managing a sharedwork-list that articulates the workflow in terms of what/when/where/who. En-actment support requires routing and/or synchronizing document artefacts. Inconclusion, the process support of dDPM comprises the following basic aspects:

– to capture process participants (Who?) at different institutions (Where?)– to capture work-items as process steps (What?)– to capture the process plan in form of a prioritized work-list (∼ When?)– to support consensus finding about the process plan by synchronizing the

work-list (in a document-oriented style) between different sites– to share the work-item results (in a document-oriented style, without nec-

essarily knowing of the content being processed)– to capture process-related status for each work-item– to manage a process history by versioning the work-list, -items, and results– to supplement process participation on demand.

It should be noted that the goal of healthcare cases, as it is generally illus-trated by the well-known diagnostic-therapeutic cycle, is to reduce uncertaintyabout the patient condition. In [15], a model for case closing is discussed assubstitute to traditional workflow termination models.

2.3 Document-Oriented Work-Lists: Cards and Adornments

For the purpose of document-orientation in process planning, the dDPM concep-tion adopts a “cards represent tasks” principle from agile software engineering.Methods like Kanban and Scrum [22] use a set of cards for managing the work-list of a team. In Scrum, for example, necessary system changes are writtenon task cards. During a development episode in Scrum (aka “Sprint”), the taskcards change their workflow status from unstarted, to ongoing, to completed.

There are many possible process-related attributes of a Scrum card. Adorn-ments3 are textual or graphical markers on the cards. Examples for Scrumadornments are a numerical score for a card’s costs estimation or dynamicallychanging markers for each developer who assigns him- or herself to a task card.In the end, several Scrum paradigms are constitutive to the α-Flow meta-model.These paradigms are i) to represent tasks as cards, ii) to measure workflowprogress by changing card status, and iii) to indicate card status by adornments.

Agile process planning has been successfully applied in concurrent engineer-ing and software engineering. In [15], it is explained how its characteristicsmatch well with the ones we experience from the diagnostic-therapeutic cycle(empirical process; tacit knowledge) and from medical guidelines (nonlinear; setsof possible solutions). However, the Scrum analogy does not implicate that wewant physicians to follow or obey any Scrum philosophy. Instead, the progress3 The term “adornment” is also used in the Unified Modeling Language (UML): a

UML adornment adds to the meaning and/or semantics of the element to which itpertains and has a textual and graphical representation; for example the diamondshaped indicators for composition or aggregation are UML adornments.

documentation by cards matches well with the clinical Problem-Oriented Med-ical Record (POMR) and its SOAP4-formatted progress notes in secondary care(cf. [23]). The Kanban and Scrum analogy enhances the POMR conception bycreating unfilled cards for planned treatment steps that can be considered as aplaceholder for a future POMR progress note. The plan can be rearranged by are-prioritization, addition, or deletion of cards.

In terms of process formalization, the idea of “content-oriented work-flows” has been adopted, which originates from several scientific workflowapproaches that articulate workflow progression by the presence of contentunits and by conditions on the state of the units. The current set of theseapproaches consists namely of “data-driven”/COREPRO, “resource-driven”,“artifact-centric”/ArtiFact™, and “object-aware”/PHILharmonicFlows research(cf. [15, 24]). Another idea that is adopted by dDPM are electronic circulationfolders like ProMInanD [25] and POLITeam [26] from the 90s. Circulations rep-resent ad hoc workflows based on dynamic re-routing of documents betweenparticipants. Finally, the dDPM assumption about process steps is that theycan be articulated by cards and fulfilled by contributing one result report asattachment. In [15], the correlation between card status progression and workitem fulfilment is further discussed.

In the end, dDPM combines (1) the content-oriented workflow paradigm,with (2) circulation folder aspects, with (3) agile process planning. Thus, dDPMprovides a process conception for document-oriented case handling. It is basedon a full-fledged process analysis of breast cancer treatment, relying on personalinterviews with accredited gynaecologists of the breast cancer centre in Amberg,Germany. In summary, twenty-three elements of a process model for distributedcase handling are identified and described in [15], providing a reference forour pilot implementation as well as a framework for evaluating the relatedapproaches in a comparative analysis. It should be noted that the resultingprocess model contains no direct healthcare-related elements or assumptionseven if the approach is primarily discussed in the context of healthcare.

2.4 System Comprehension

For the end user, an α-Doc embeds an engine for distributed case handling thatis something like a functional fusion of (1) group-based email with (2) a sharedwork-list editor with a (3) versioned content repository. Trying to provide aMicrosoft product metaphor, one could attempt to say that α-Docs are like aself-contained distributed mini-SharePoint. Yet, any such comparison shouldkeep in mind that groupware products generally predefine the data structuresthat model task entries in form of a fixed schema; in contrast, α-Flow integratesa run-time adaptive attribute model for its task entries (cf. [11]).

Furthermore, the α-Doc embeds a rule engine that guards status changesand executes actions as the kernel of the active document (cf. [10]). It cur-rently provides platform rules for versioning (cf. [12]) as well as publicationand distributed synchronisation (cf. [13]). Workflow benefits are process plan-ning, participant management, and process history as well as process templateexport/import for process structure and roles (cf. [15]).4 SOAP of POMR is an abbreviation for subjective, objective, assessment, and plan.

3 Synopsis of the α-Flow System Design

The active properties of an α-Doc implement an embedded α-Flow engine thatenacts the content-oriented process model of dDPM. In general, each α-Doccarries the workflow context in addition to the medical content. The cards areshared and managed as content units in the context of an α-Doc as α-Cardsand α-Adornments are process-related markers on these cards.

In α-Flow, information units are distinguished into two categories: contentcards and coordination cards. The content cards are essentially the content unitslike referrals and reports from the use case scenario. In addition, coordinationcards are utilized to store process structure and collaboration resources. Coordi-nation cards are independent of the local application systems and belong to thedistributed case handling. The α-Flow system uses three coordination cards:the Process Structure Artifact (PSA), Collaboration Resource Artifact (CRA),and Adornment Prototype Artifact (APA). The PSA captures the work-list. TheCRA captures the resources that are necessary to start and complete work-items. The APA captures the set of α-Adornments that is used as a clonebasefor creating new α-Card descriptors.

From a file replication and messaging perspective, the α-Doc is logically cen-tralized but physically distributed. That means that each replicate of an α-Docautonomously uses an embedded store-and-forward messaging for distributedsynchronization of the replicates. The messaging infrastructure is ultimatelyintended to build upon secure large-scale messaging platforms with guaran-teed delivery, as it is intended in Germany by the national government project“Elektronische Gesundheitskarte” (eGK). The α-Flow engine implements a syn-chronization protocol (cf. [12]). The protocol uses electronic post-box infor-mation, which is part of the recorded participant information. One appeal ofestablishing a peer-to-peer synchronized α-Doc for each individual case is thateach physician gains only access to exactly the same electronic files as they arealready accessible to him or her in paper-based working practice, today.

The α-Flow language elements can be set into relation to each other. Thus,figure 2 illustrates the α-Flow meta-model. The structural elements like theα-Doc, α-Card , descriptor, payload, and α-Adornments as well as the α-Episodeidentifier and the α-Card identifier have been highlighted in light blue . Theα-Card is only an abstract concept and is completely represented by a de-scriptor and a payload that share the same α-Card identifier. It captures awork-item both prospectively (planning purpose) and retrospectively (resultdocumentation).

The elements for collaboration resources, process structure, and adornmentprototype are highlighted in light green . For example, the patient informationis managed in form of the element “object under consideration” (OC). Conceptslike the OC, contributor, institution, and role are associated with the work-item,i.e. with the α-Card . Each contributor is also associated with an electronic post-box for messaging purposes. All these elements are considered as collaborationresources and they are stored in the CRA payload.

The PSA payload contains the complete prioritized set of α-Card iden-tifiers of an α-Doc. The process structure also allows content dependenciesbetween two work-items. Association types are the “cohesive-content relation-

α-Doc

Descriptor

α-Episode-ID

α-Card-ID{abstract}α-Card

Payload

α-Adornment

1

1

1

1

1

1

namevalue

node-ID

content

«coord»PSA-payload

«coord»CRA-payload

«coord»APA-payload

CorpusGenericus

Contributor

Institution

Role

Postbox

OC

ContentDependency

CollaborationResources

ProcessStructure

Adornment Prototype

Fig. 2. The α-Flow meta-model

ship”, “required-content dependency”, and “sub-lists” for aggregation, beingfurther detailed in [15].

The α-Adornments that are pre-defined by the α-Flow framework are col-lectively called the “corpus genericus” – which is an artificial term: the “corpus”indicates a “principal part” and “genericus” is a pseudo-Latin construct thatindicates the “generic framework layer”. Originally it was a wordplay but theterm stuck and was never replaced conceptually. Such term had been necessaryto distinguish pre-defined adornments from adaptively-defined adornments atrun-time. The overall concept of the adaptive adornment model has been pub-lished in [11]. Adornments act as trigger for rule-based actions (cf. [14]) andstate changes for adornments of the corpus genericus are framework-supported.The set of adornments was initially motivated and discussed in [8] and is furtherdetailed in [15]. The APA payload contains the pre-defined adornments.

The three special payload artefacts that are used to keep the coordination-related information are highlighted in light yellow . The purpose of the yellowdashed boxes for grouping the green elements is to provide a correlation totheir respective coordination card artefact.

Finally, the existence and relevance of the coordination cards and their pay-loads is ultimately hidden by the α-Flow engine as a graphical case handlingapplication. Thus, users do not necessarily need an explicit understanding ofcoordination cards. The reasoning behind this design is that the three coordi-nation cards can technically be handled like the content cards, for versioningand remote synchronization purposes.

The α-Flow model is further formalized in [15]. The formalization of theα-Doc provides a model by which all embedded content units can be consideredas mathematical sets of facts. In the end, the formal α-Doc representation

allows for applying an inference engine in order to query such sets of facts andto trigger rule-based actions on fact changes.

In the end, the α-Flow implementation currently comprises about one hun-dred thousand lines of code, split into eleven major sub-modules. A technicalevaluation is provided in [15], which analysis code metrics and compares theperformance of the embedded versioning system with Subversion and git.

A conceptual evaluation is provided by a comparative analysis with thecontent-oriented workflow approaches, mentioned in sect. 2.3. In addition, sixactive document approaches are identified and a comparative analysis is pro-vided. Finally, three additional approaches are identified that share some ofthe combined characteristics like the content-oriented workflow paradigm, ac-tive document paradigm, or agile process planning. The twenty-three processrequirements, mentioned in sect. 2.3, are reused for evaluation purposes. Theevaluation and its analytical preparation is a substantial part of the overallthesis in [15].

4 Conclusion: Case Files via Active Documents

Each active document carries the workflow context in addition to the domaincontent and provides autonomous coordination logic. The purpose is to allowaccess, viewing, and editing of the original content documents through com-mon editors in the local information systems without corrupting the processsemantics of the distributed case engine.

In contrast to the original Placeless active documents approach, the α-Docdoes not depend on a special middleware environment. It is a common file on theuser’s desktop. It can be handled as passive files like a PDF or a Word file. Thus,the local information systems could put an α-Doc into the context of a patientlike they would with any other externally provided data files. Still, the α-Doccontains both the document-oriented case data and the case handling enginefor the distributed cooperation. In addition, it can be replicated with its activeproperties like common files across any file system. α-Docs have the ability toautonomously change their life-cycle state. No pre-installed applications arerequired to interact with an α-Doc. Changes are remotely synchronized withreplicated clones. In the end, the α-Doc is an instantly available tool that needsno administration and that enables genuine ad hoc information exchange.

One appeal of the α-Flow approach is as follows: doctors become partici-pants by handing them over a copy of the α-Doc. This is the same interactionas making them participants by handing over referral vouchers. On the whole,the document-oriented concepts for distributed cooperation of α-Flow reflectand support the traditional paper-based working practice in healthcare.

In the final analysis, cf. [15], the prototypical implementation demonstrates(1) how to form a shared case file into a single molecular self-managing file unit,(2) how to support cooperation without the need to do data integration, (3) howto dynamically share a tool for case handling and to bring workflow articulationas close to end-users as possible, and (4) how to provide flexibility by means ofrun-time adaptibility. Even if the approach is primarily discussed in the contextof healthcare, all presented methods are applicable to other domains with case-driven characteristics like law (legal case management), sales (lead acquisition),

insurance (claim handling), or science (e.g., research funding processes). Theoverarching scientific contributions of the approach concern (1) human-machineinteraction by exploring the idea of active documents, (2) medical processesby analysing and modelling the breast cancer treatment episodes, (3) work-flow management by exploring the content-oriented workflow paradigm and bycombining it with case handling and card-based agile process planning, (4) dis-tributed systems by developing an offline-capable synchronization protocol,(5) content management by developing an embedded version control systemthat provides multi-module histories and validity-based navigation, and (6) evo-lutionary information systems by a run-time adaptive attribute model, varioustemplating support, and demand-driven process participation. However, thereare still many open research questions. Amongst others, unresolved challengesconcern (1) data security for replicate transfer and local storage protection,(2) run-time configurable behaviour of distributed active documents, (3) ex-ecution security and access control for active documents, and (4) workflowconsiderations about the teamwork between doctors and nurses.

References

1. R. Lenz, M. Beyer, C. Meiler, S. Jablonski, and K. Kuhn. Informationsintegrationin Gesundheitsversorgungsnetzen. Informatik-Spektrum, 28(2):105–119, 2005.

2. K. E. Thorpe, L. L. Ogden, and K. Galactionova. Chronic conditions account forrise in medicare spending from 1987 to 2006. Health Affairs, 29(4):718, 2010.

3. R. H. Fletcher, M. S. O’Malley, S. W. Fletcher, J. A. Earp, and J. P. Alexander.Measuring the continuity and coordination of medical care in a system involvingmultiple providers. Med Care, 22:403–411, May 1984.

4. P. R. Dexter, D. K. Miller, D. O. Clark, M. Weiner, L. E. Harris, L. Livin, I. Myers,D. Shaw, L. A. Blue, J. Kunzer, et al. Preparing for an aging population andimproving chronic disease management. In Proc of the AMIA Annual Symposium,volume 2010, page 162. American Medical Informatics Association, 2010.

5. Richard Lenz. Information Systems in Healthcare – State and Steps towardsSustainability. IMIA Yearbook 2009 – Yearbook of Medical Informatics as asupplement of Methods of Information in Medicine, pages 63–70, 2009.

6. Roland Berger. Telematik im Gesundheitswesen – Perspektiven der Telemedizinin Deutschland. Studie im Auftrag des Bundesministeriums für Bildung, Wis-senschaft, Forschung und Technologie in Zusammenarbeit mit dem Bundesmin-isterium für Gesundheit, München, 1997.

7. P. Dourish, W. K. Edwards, A. LaMarca, J. Lamping, K. Petersen, M. Salis-bury, D. B. Terry, and J. Thornton. Extending document management systemswith user-specific active properties. ACM Transactions on Information Systems(TOIS), 18(2):140–170, 2000.

8. Christoph P. Neumann and Richard Lenz. alpha-Flow: A Document-based Ap-proach to Inter-Institutional Process Support in Healthcare. In Proc of the3rd Int’l Workshop on Process-oriented Information Systems in Healthcare (Pro-Health’09), Ulm, DE, September 2009.

9. Christoph P. Neumann and Richard Lenz. The alpha-Flow Use-Case of BreastCancer Treatment – Modeling Inter-Institutional Healthcare Workflows by ActiveDocuments. In Proc of the 19th Int’l Workshops on Enabling Technologies: In-frastructures for Collaborative Enterprises (WETICE), Larissa, GR, June 2010.

10. Aneliya Todorova and Christoph P. Neumann. alpha-Props: A Rule-Based Ap-proach to ‘Active Properties’ for Document-Oriented Process Support in Inter-Institutional Environments. In Ludger Porada, editor, Lecture Notes in Infor-matics (LNI) Seminars 10. Gesellschaft für Informatik e.V. (GI), March 2011.

11. Christoph P. Neumann, Peter K. Schwab, Andreas M. Wahl, and Richard Lenz.alpha-Adaptive: Evolutionary Workflow Metadata in Distributed Document-Oriented Process Management. In Proc of the 4th Int’l Workshop on Process-oriented Information Systems in Healthcare (ProHealth’11), Clermont-Ferrand,FR, August 2011.

12. Christoph P. Neumann, Andreas M. Wahl, and Richard Lenz. Adaptive VersionClocks and the OffSync Protocol. In Proc of the 10th Int’l Symposium on Paralleland Distributed Processing with Applications (ISPA), Madrid, Spain, July 2012.

13. Christoph P. Neumann, Scott A. Hady, and Richard Lenz. Hydra Version Con-trol System. In Proc of the 10th Int’l Symposium on Parallel and DistributedProcessing with Applications (ISPA), Madrid, Spain, July 2012.

14. Christoph P. Neumann and Richard Lenz. The alpha-Flow Approach to Inter-Institutional Process Support in Healthcare. International Journal of Knowledge-Based Organizations (IJKBO), 2(4):52–68, 2012.

15. Christoph P. Neumann. Distributed Document-Oriented Process Managementin Healthcare. PhD thesis, Friedrich-Alexander-Universität Erlangen-Nürnberg,2012. Submitted.

16. J. Becker, L. Algermissen, and B. Niehaves. Processes in e-government focus: aprocedure model for process oriented reorganisation in public administrations onthe local level. Electronic Government, pages 1062–1062, 2003.

17. R. Medina-Mora, T. Winograd, R. Flores, and F. Flores. The action workflowapproach to workflow management technology. In Proc of the 1992 ACM Confon Computer-Supported Cooperative Work, pages 281–288, 1992.

18. S. McCready. There is more than one kind of workflow software. Computerworld,2:86–90, 1992.

19. D. Georgakopoulos, M. Hornick, and A. Sheth. An overview of workflow manage-ment: From process modeling to workflow automation infrastructure. Distributedand parallel Databases, 3(2):119–153, 1995.

20. Workflow Management Coalition. WFMC-TC-1011 Ver 3 Terminology and Glos-sary English, February 1999.

21. M. Rusinkiewicz and A. Sheth. Specification and execution of transactional work-flows. In Won Kim, editor, Modern Database Systems: The Object Model, Inter-operability, and Beyond, pages 592–620. Addison-Wesley, 1994.

22. H. Kniberg. Scrum and XP from the Trenches. Enterprise Software Development.Lulu Enterprises, 2007.

23. Lawrence L. Weed. Medical records that guide and teach. New England Journalof Medicine, 278(12):652–657, 1968.

24. Vera Künzle and Manfred Reichert. Towards object-aware process managementsystems: Issues, challenges, benefits. In Proc of the 10th Int’l Workshop on Enter-prise, Business-Process and Information Systems Modeling (BPMDS’09), pages197–210. Springer, June 2009.

25. B. Karbe, N. Ramsperger, and P. Weiss. Support of cooperative work by elec-tronic circulation folders. In Proc of the ACM SIGOIS and IEEE CS TC-OAConf on Office Information Systems (COIS’90), pages 109–117, April 1990.

26. K. Klöckner, P. Mambrey, et al. POLITeam Bridging the Gap between Bonn andBerlin for and with the Users. In Proc of the 4th European Conf on Computer-Supported Cooperative Work (ECSCW’95), pages 17–32, September 1995.