Kopplungsstrategien für Anwendungssysteme im Krankenhaus; Strategies for coupling enterprise application systems in hospitals;

1 EinleitungKrankenhausinformationssysteme wie dasdes Universitatsklinikums Leipzig (UKL)bestehen oft aus vielen unterschiedlichenAnwendungssystemen, die auf Produktenverschiedener Hersteller basieren. Fur dieIntegration dieser Anwendungssystemewerden Losungen auf der Basis unter-schiedlicher Integrationstechniken ange-boten. Bei der Auswahl von Anwen-dungssystemen fur die medizinischeInformationsverarbeitung sind die Vor-und Nachteile der angebotenen Losungenoft nicht umfassend bekannt.

Im Kooperationsprojekt „EKKIS“ (EngeKopplung klinischer Informationssysteme[Offi01]) werden in Zusammenarbeit desUKL mit dem OFFIS (Oldenburger For-schungs- und Entwicklungsinstitut fur In-formatik-Werkzeuge und Systeme) undder Meierhofer AG [Meie02] Kopplungs-strategien fur KIS-Komponenten ent-wickelt. Der Artikel beschreibt Strategienund Techniken fur die enge Kopplungzur Integration von autonomen Anwen-dungssystemen beispielhaft fur das UKL.Daruber hinaus werden Losungsmoglich-keiten fur ausgewahlte Probleme derIntegration beschrieben. Dabei werdenkonzeptionelle Grundlagen wie Transak-tionskonzepte und Replikationsverfahrenberucksichtigt.

Bei der Vorstellung von Problemen mit In-tegrationslosungen wird unterschiedenzwischen Problemen, die sich unmittelbaraus den gewahlten Kopplungsstrategienund Integrationstechniken ableiten lassenund solchen, die sich aus organisatorischen

Randbedingungen ergeben. Die behandel-ten Kopplungsstrategien sind die synchro-ne Datenkommunikation, die asynchroneDatenkommunikation und die zentraleNummernvergabe. Die behandelten Inte-grationstechniken sind Remote FunctionCalls (RFC) des SAP R/3 Systems und derNachrichtentransfer uber einen Kommuni-kationsserver. Die behandelten Grundlagenfur Transaktionskonzepte beinhalten QueuedTransactions, Sagas und das 2-Phasen-Commit.

In Abschnitt 2 wird eine Vorgehensweisezur Integration von Anwendungssystemenerlautert. Die einzelnen Schritte und Er-gebnisse der Integration anhand dieserVorgehensweise wird im Abschnitt 3 be-schrieben, wobei in Unterabschnitten dieAnalyse der Geschaftsprozesse vorgenom-men, die Integration der Anwendungen be-trachtet und die technische Realisierungdurch Einsatz einer Middleware vorgestelltwird. Abschließend werden in Abschnitt 4die Losungen diskutiert und in Abschnitt 5ein Ausblick auf weitere Arbeitspunkte ge-geben.

2 Integration vonAnwendungssystemen

Zur systematischen Behandlung der Inte-grationsthematik wurden verschiedeneModelle geschaffen. In [Hass00] wird dieSystemintegration anhand eines 3-Ebenen-Modells diskutiert, in dem Organisations-einheiten durch drei Architekturebenenbeschrieben werden (vgl. Bild 1):

WIRTSCHAFTSINFORMATIK 44 (2002) 5, S. 425–434

Die Autoren

Heiko NiemannWilhelm HasselbringThomas WendtAlfred WinterMatthias Meierhofer

Dipl-Inf. Heiko Niemann, OFFIS,Escherweg 2,26121 Oldenburg,E-Mail: [email protected];Prof. Dr. Wilhelm Hasselbring,Carl von Ossietzky UniversitatOldenburg, Fachbereich Informatik,Abteilung Software Engineering,26111 Oldenburg,E-Mail: [email protected];Dipl-Inf. med. Thomas Wendt,Prof. Dr. Alfred Winter,Universitat Leipzig,Institut fur Medizinische Informatik,Statistik und Epidemiologie,Liebigstraße 27,04103 Leipzig,E-Mail:{wendt|winter}@imise.uni-leipzig.de;Dipl-Inf. Matthias Meierhofer,Meierhofer AG,Wamslerstraße 2,81829 Munchen,E-Mail: [email protected]

Kopplungsstrategienfur Anwendungssystemeim Krankenhaus

WI – Schwerpunktaufsatz

1. Geschaftsarchitektur: In dieser Ebenewerden die Organisationsstruktur unddie Arbeitsablaufe fur die Geschafts-regeln und -prozesse definiert.

2. Anwendungsarchitektur: Diese Ebenebeschreibt die Implementierung des Ge-schaftskonzepts durch die Unterneh-mensanwendungen.

3. Technologische Architektur: Die Infor-mations- und Kommunikationsinfra-struktur wird auf dieser Ebene darge-legt.

Eine moglichst effektive Unterstutzungder ubergreifenden Geschaftsprozesse er-fordert nun eine horizontale Integrationauf den verschiedenen Ebenen. Die Inte-gration auf der Anwendungsebene ist auchals EAI (Enterprise Application Integra-tion) bekannt. Auf der technologischenEbene setzt Middleware dabei die Integra-tion technisch um, z. B. durch CORBAObject Request Broker [Corb02].

Es konnen zwei grundlegende Strategienzur Herstellung von Integration unter-schieden werden: bottom-up oder top-down. Bei der Bottom-up-Strategie wirdauf der technologischen Ebene begonnen:

1. Installation der technischen Integra-tionsplattform

2. Verknupfung der Anwendungssysteme3. Anpassung der Geschaftsprozesse an

die neuen bzw. erweiterten Moglichkei-ten

Die Top-down-Strategie beginnt auf derGeschaftsebene:

1. Analyse der Geschaftsprozesse und Er-stellung eines Anforderungskataloges

2. Klarung der beteiligten Anwendungs-systeme und deren (benotigter) Inter-aktion

3. Entscheidung fur eine Integrationstech-nik

In der Praxis wird man sich ublicherweisenicht nur auf eine Strategie beschranken,sondern eine angemessene Kombinationanstreben, bei der aber top-down gestartetwerden sollte [Hass02]. Fur die Integra-tionsarbeiten im hier behandelten Inte-grationsszenario wurde eine Mischformgewahlt, bei der primar top-down vor-gegangen wird, jedoch unter Berucksich-tigung der am UKL vorhandenen Inte-grationslosungen.

3 Vorgehen und Ergebnissedes EKKIS-Projektes

3.1 Analyseder Geschaftsprozesse

Das gewahlte Top-down-Vorgehen siehtals ersten Schritt eine Analyse der fur dasProjekt relevanten Geschaftsprozesse vor.Fur das hier betrachtete Integrationsszena-rio wurden zwei Geschaftsprozesse identi-fiziert: Der Prozess der Patientenaufnahmeund der Prozess der Diagnosen- und Pro-zedurendokumentierung fur Operationen.Die Bilder 2 und 3 zeigen beide Prozesseals Aktivitatsdiagramme auf der Basis derUML [RuJB99].

Aufnahmen werden amUKL hauptsachlichdurch die Mitarbeiter der zentralen Patien-tenaufnahmestelle durchgefuhrt. Sie habenim Vergleich zu den Klinikmitarbeiternwesentlich bessere Kenntnis von adminis-trativen Aspekten, z. B. der Einstufung inBehandlungskategorien. Zusatzlich sollenauch in den Kliniken selbst Aufnahmendurchgefuhrt werden. Diese werden vorabals sogenannte Plan-Aufnahmen erfasst,um Patienten in die OP-Planung einbezie-hen zu konnen, auch wenn sie noch nichtvor Ort im Klinikum sind. Bereits bei derOP-Planung werden einige medizinischeInformationen dokumentiert. Deshalbmussen die Plan-Aufnahmen mit den spa-teren „echten“ Aufnahmen zusammenge-fuhrt werden.

Diagnosen und Prozeduren (¼ medizi-nische Maßnahmen), die in den Klinikendokumentiert werden, mussen fur die Fall-abrechnung in der Kostensicherungsstellezur Verfugung stehen. Diagnosen undProzeduren zu einer Operation oder ei-ner Untersuchung werden oft nicht zu-sammenhangend dokumentiert. Viele OP-Diagnosen konnen erst mehrere Tage nachder Operation gestellt und dokumentiertwerden, z. B. wenn Gewebsproben auf-wandig zu untersuchen sind. Fur Fall-abrechnungen ist die Vollstandigkeit derDokumentation wichtig. Fur eine Kom-munikation von Diagnosen und Prozedu-ren muss also im Geschaftsprozess ein Ab-schluss der Dokumentation vorgesehenwerden. Die Entlassung aus dem Kranken-haus reicht dafur nicht aus.

3.2 Anwendungsintegration

Die Probleme, zu deren Losung das EK-KIS-Projekt beitragen soll, ergeben sichdaraus, dass die im Patientenmanagementund in den Kliniken verwendeten An-wendungssysteme und die bestehendenSchnittstellen teilweise nicht fur die gefor-derten Geschaftsprozesse geeignet sind.

Wir beschranken uns hier auf die Betrach-tung

& des Patientenmanagementsystems aufder Basis des IS-H-Moduls im R/3-Sys-tem und

& des Operationsplanungs- und -doku-mentationssystems auf der Basis desMCC-Systems [Meie02].


OrganisationseinheitOrganisationseinheit

TechnologischeArchitektur

Anwendungs-architektur

Geschäfts-architektur

TechnologischeArchitektur

Anwendungs-architektur

Geschäfts-architektur

MiddlewareIntegration

EnterpriseApplicationIntegration

Geschäfts-prozess

Integration

Bild 1 Horizontale Integration zur Unterstutzung der Geschaftsprozesse

426 Heiko Niemann, Wilhelm Hasselbring et al.

3.2.1 Ein Modelldes Integrationsszenarios

Bild 4 zeigt ein einfaches Modell derKopplung von IS-H und MCC. Es erlaubt,die beteiligten Anwendungssysteme imZusammenhang mit Aufgaben bzw. Akti-vitaten der Geschaftsprozessmodellierungund mit genutzten physischen Werkzeugenzu betrachten. Das Bild wurde auf der Ba-sis des Metamodells 3LGM erstellt(3-Level Graph-Based Model2, [WiBW01],Nachfolger des 3LGM [WiHa95]). Das3LGM sieht ebenfalls drei Ebenen vor,macht aber detailliertere Modellierungsvor-gaben als in Abschnitt 2 diskutiert. Es un-terscheidet

& eine fachliche Ebene mit Aufgaben derInformationsverarbeitung und den inter-pretierten bzw. bearbeiteten Objekt-typen,

& eine logische Werkzeugebene mit An-wendungssystemen und Angaben zuSchnittstellen und Datenbanken,

& eine physische Werkzeugebene mit An-gaben zu Geraten, Netzverbindungenusw.

Die Anwendungsebene und die technolo-gische Ebene aus dem Abschnitt 2 sind hierzur logischen Werkzeugebene vereint. Diefachliche Ebene entspricht der Geschafts-modellierungsebene.

Zwischen IS-H und MCC sind zwei ver-schiedenartige elektronische Kommunika-tionsverbindungen realisiert:

1. �ber einen Kommunikationsserverwerden Daten zu Aufnahmen, Ver-legungen und Entlassungen von Patien-ten (ADT-Daten) von IS-H an MCCasynchron ubermittelt. Dazu werdenvon IS-H ADT-Nachrichten periodischin einer Datei zur Verfugung gestellt.Der Kommunikationsserver liest dieNachrichtendatei periodisch, loscht diegelesenen Nachrichten und leitet sie ineine andere Nachrichtendatei fur MCCweiter. Die Nachrichten werden nichtkonvertiert, aber uber einen Filter wer-den einige Nachrichtentypen, z. B.Nachrichten zum Anlegen von Opera-tionen, von der Weiterleitung aus-geschlossen (vgl. Bild 5). Die MCC-sei-tige Empfangskomponente liest undloscht den Inhalt der Nachrichtendateiperiodisch. In Log-Dateien wird fest-gehalten, welche Nachrichten erfolg-reich verarbeitet werden konnten undwelche nicht.

2. �ber eine RFC-Schnittstelle (RemoteFunction Call, [Sap02]) werden ausMCC an IS-H OP-Daten, insbesondereDiagnosen und Prozeduren, und Datenzu geplanten Aufnahmen synchronubermittelt. Aufnahmedatensatze wer-den in MCC erfasst, aber nicht unmit-telbar gespeichert. Die Speicherung er-folgt erst nach �bermittlung an IS-H,da von IS-H als Ruckgabewerte dieFallnummer zur Aufnahme bereit-gestellt wird. �ber die Fallnummerkonnen nachtragliche Aufnahmeande-rungen und auch OP-Daten direkt demBehandlungsfall zugeordnet werden.Das �bermitteln von Operationsdaten-satzen ist nicht an die Speicherungs-funktion geknupft, sondern an dasAbschließen von Operationsdokumen-tationen. In MCC werden uber eineAbschlussfunktion Operationsdoku-mentationen fur eine weitere Bearbei-tung gesperrt. Beim Abschließen einerOperation wird diese zunachst per RFCin IS-H gespeichert. IS-H gibt eine Be-wegungsnummer zuruck, die in derMCC-Datenbank gespeichert wird.Falls die Funktionalitat zum �ffnen,�ndern und wiederholten Abschließeneiner bereits abgeschlossenen Operationgenutzt wird, kann durch die Kenntnisder Bewegungsnummer auch in IS-Heine Korrektur vorgenommen werden.

Bild 5 zeigt die logische Werkzeugebeneaus Bild 4 mit den Kommunikationsver-bindungen. Das Patientenmanagementsys-tem und das OP-Planungs- und Doku-mentationssystem sind eingebettet in einkomplexes Informationssystem mit vielenweiteren Anwendungssystemen. Die logi-sche Werkzeugebene in Bild 6 zeigt beideSysteme in einem großeren Ausschnitt die-ses Informationssystems. Das Bild zeigtzusatzlich

& den Kommunikationsserver eGate, derNachrichten filtert, transformiert undweiterleitet,

& Anwendungssysteme sogenannter Leis-tungsstellen wie der Radiologie(MEDOS), des Zentrallabors (C-LAB),der Pathologie (DC-PATHOS) und derEndoskopie (PIA),

& ein Spezialsystem zur intensivmedizi-nischen �berwachung (COPRA) und

& ein System zur Erfassung und Auswer-tung innerbetrieblicher Leistungsdaten(LEDIS).

Da die verschiedenen Systeme gemeinsameDaten, wie Stamm- oder Dokumentations-daten, eines Patienten verarbeiten, wird eineKopplung dieser Systeme benotigt, umz. B. Doppelerfassung und Inkonsistenz zuvermeiden. Auch der Zeitfaktor spielt einegewichtige Rolle. So birgt der Austauschvon Daten per Beleg, per Diskette oder


Kernpunkte fur das Management

Krankenhausinformationssysteme bestehen in ihrem rechnerunterstutzten Teil auf Grund un-terschiedlichster Anforderungen der verschiedenen Bereiche im Krankenhaus aus hetero-genen und autonomen Anwendungssystemen. Eine Kopplung dieser Systeme bedeutet imAllgemeinen eine Replikation von Patientendaten.

& Die lose Kopplung uber einen Kommunikationsserver ist Stand der Technik in klinischenInformationssystemen.

& Eine engere Kopplung der Systeme wird durch eine synchrone Kommunikation mit Trans-aktionskontrolle erreicht, um eine hohere Konsistenz zu erreichen.

& Die Anforderungen an eine Replikationsstrategie im Krankenhaus bez. Konsistenz,Verfugbarkeit und Performanz konnen nur uber eine Kombination verschiedener Ver-fahren erreicht werden.

& Die Systemintegration sollte beginnend auf Ebene der Geschaftsprozesse uber die An-wendungslogik hin zur technischen Middleware idealerweise top-down erfolgen.

Stichworte: Krankenhausinformationssystem (KIS), synchrone/asynchrone Kommunikation,Kopplungsstrategie, Kommunikationsserver, Applikationsintegration, Schemaintegration,Datenreplikation

Kopplungsstrategien fur Anwendungssysteme im Krankenhaus 427

selbst uber einen langsamen Kommunika-tionskanal die Gefahr einer verspatetenAktualisierung.

Wesentlich ist der Aspekt der zentralenNummernvergabe: Um die medizinischenund administrativen Patientendaten zu-ordnen und austauschen zu konnen, wer-den einheitliche Identifikationsnummern

benotigt. IS-H zeichnet fur die Vergabeder Identifikationsnummern verantwort-lich. Wenn andere Anwendungssystemez. B. die Funktionalitat Patientenaufnah-me durchfuhren sollen, so wird eine Pa-tienten-ID (bzw. eine Fall-ID) von IS-Hbenotigt, was eine synchrone Kopplungsinnvoll macht.

In Bild 3 zur Prozessanalyse sind sowohldie alteren Ablaufe „Automatische Beleg-erstellung“ und „Manuelle Belegerstel-lung“ als auch der neue Prozess „Auto-matische �bertragung“ zu sehen. Dieautomatische �bertragung wird zurzeiteingefuhrt und vom EKKIS-Projekt be-gleitet.

3.2.2 Probleme auf derAnwendungsebene

Mit der Integration von MCC und IS-Hsind u. a. folgende Probleme verbunden:

1. Organisatorische Probleme:& Die Fallnummer wird zur Zuord-

nung von Daten benotigt und ist da-her ubergreifendes Organisationsmit-tel. Sie darf nicht von mehrerenunabhangigen Stellen bzw. Anwen-dungssystemen vergeben werden.

& Die elektronische �bermittlung er-folgt zunachst unsichtbar fur die An-wender. Wenn OP-Daten an IS-Hubermittelt wurden, gehen die IS-H-Anwender davon aus, dass die ab-rechnungsrelevanten Daten vorliegenund weiterverarbeitet werden kon-nen. Fur nachtragliche �nderungenuber die RFC-Schnittstelle, die wie-derum �nderungen an Rechnungennach sich ziehen, wird also ein Be-nachrichtigungsmechanismus beno-tigt. Nur dann konnen unter Um-standen �nderungsmeldungen an dieKostentrager, i. d. R. die Kranken-kassen, geschickt werden.

2. Technische Probleme:& Eine sehr enge Kopplung von An-

wendungssystemen hat zur Folge,dass der Ausfall eines der beteiligtenAnwendungssysteme unmittelbar dieArbeit mit dem Partnersystem behin-dert. Ein IS-H-Ausfall konnte alsodie Durchfuhrung von Plan-Aufnah-men mit MCC unmoglich machen.

& Die asynchrone Nachrichtenuber-mittlung uber den Kommunikations-server ist mit einem Zeitversatz (zur-zeit etwa sechs Minuten) verbunden.Wenn Aufnahmedaten aus IS-H sehrschnell benotigt werden, z. B. bei derOP-Planung, ist diese Zeit zu lang.

& Bei einer starken Belastung des SAP-Systems, z. B. wegen laufender Aus-wertungen des Controlling, ist dasMCC-System bei Freigabe einerOperation uber die RFC-Schnittstellelangere Zeit (etwa 30–40 Sekunden)blockiert.


PV gibt Daten ein[Normalfall]

Belege drucken

Patient geht zur Station

Patient versorgen, Daten aufnehmen

Daten zur PV bringen

[Notfall]

Daten verteilen

Patient zur Station bringen

PV gibt Daten ein

Belege drucken

Belege an P. geben

Belege per Hauspost verschicken

Bild 2 Aufnahme eines Patienten im UKL

Daten werden erfasst

[Automatische Übertragung]

Daten werden erfasst

[Automatische Belegerstellung]

Daten werden auf Beleg eingetragen

[Manuelle Belegerstellung]

Belege werden gedruckt

Belege werden zur PV gesendet

Dokumentation wird abgeschlossen

PV gibt Dokumentation ein

Daten werden zur PV übertragen

Bild 3 Dokumentation von Diagnosen, Prozeduren und OPs


3.2.3 Schemaintegration

Im betrachteten Szenario bedeutet Anwen-dungsintegration im Wesentlichen ein Re-plizieren von Daten. In diesem Abschnittsoll zunachst die Abbildung der Daten derbeteiligten Systeme, d. h. die Schemainte-gration untersucht werden. Anschließendwerden Replikationsstrategien und damiteinhergehende Transaktionskonzepte dis-kutiert.

In Kliniken ist die Kopplung der Informa-tionssysteme uber einen Kommunikations-server Stand der Technik, so auch im UKL(vgl. Bild 6). Der asynchrone Austauschder Daten erfolgt hier uber speziell fur Kli-niken entwickelte Systeme, die neben derFunktionalitat eines Kommunikationsser-vers (siehe z. B. [LaPH99]) insbesonderedie Transformation auf das Standardformatfur Krankenhauser HL7 (Health LevelSeven) bzw. der verschiedenen Versionenvon HL7 bietet. HL7 ist ein Kommunika-tionsstandard, der von der HL7-Organisa-

tion [Heal01] definiert wurde. Der Ent-wicklung des HL7-Standards wird einReference Information Model (RIM) zu-grunde gelegt, in dem die meisten der imGesundheitswesen zu kommunizierendenInformationen als Klassen und Klassenbe-ziehungen modelliert sind.

Auch bei der Schemaintegration gibt esgrundsatzlich zwei Strategien, die Integra-tion durchzufuhren (vgl. [Hass02]): Beider Bottom-up-Strategie wird ausgehendvon den lokalen Datenmodellen ein globa-


Bild 4 Einfaches Drei-Ebenen-Modell der Kopplung von IS-H und MCC


les Datenmodell entwickelt, wahrend beider Top-down-Strategie ausgehend von ei-nem globalen Datenmodell, am besten ei-nem standardisierten Referenzmodell, eineAbbildung zu den lokalen Datenmodellenerstellt wird. Das Top-down-Verfahrenbietet im Allgemeinen den Vorteil einerleichteren Erweiterbarkeit auf mehrereSysteme. Außerdem ist bei Vorhandenseineines geeigneten Referenzmodells die Ab-bildung einfacher zu erstellen, insbesonde-re dann, wenn die Systemhersteller neueVersionen ihrer Systeme an diesen Stan-dard anpassen.

Da im medizinischen Bereich mitHL7-RIM ein Referenzmodell vorliegt,soll die Abbildung uber dieses Standard-modell durchgefuhrt werden. Wie in Bild 7gezeigt, wird hierfur eine Abbildung vonHL7-RIM auf IS-H bzw. MCC gebildet.Die in Bild 7 dargestellten Datenmodellestellen nur einen groben Ausschnitt der tat-sachlichen Datenmodelle dar. Sind die Ab-bildungen von dem Referenzmodell zu denlokalen Modellen gefunden, so ergebensich indirekt auch die Abbildungen zwi-schen den lokalen Datenmodellen. Bei einerErweiterung um ein neues lokales Daten-

modell wird dann nur die Abbildung zumReferenzmodell benotigt und die Ab-bildung zu den anderen lokalen Modellenergibt sich automatisch. Auf Details der je-weiligen Datenmodelle und der Abbildun-gen konnen wir hier aus Platzgrundennicht eingehen.

3.2.4 Replikationsstrategien

Bei der Datenreplikation bestehen Ziel-konflikte bezuglich der Gewahrleistungvon: Konsistenz, Verfugbarkeit und Per-formanz (vgl. Bild 8). Eine Verbesserungbei einem dieser Kriterien zieht im All-gemeinen eine Verschlechterung bei denanderen Kriterien nach sich. Beispielsweisebedeutet eine Erhohung der Konsistenz-Anforderung eine verminderte Verfugbar-keit der Systeme, da bei jeder Schreibope-ration alle beteiligten Systeme verfugbarsein mussen. Im UKL ist einerseits Konsis-tenz gefordert, andererseits darf aber dieAutonomie der verschiedenen Anwen-dungssysteme nicht eingeschrankt werden:Bei Absturz eines Systems mussen die an-deren autonom weiterarbeiten konnen.

Somit unterscheiden wir analog zu denKommunikationsverfahren zwischen syn-chronen und asynchronen Replikationsver-fahren, d. h. im synchronen Fall werden alleKopien zeitgleich aktualisiert, im asyn-chronen Fall wird die Propagierung zeit-versetzt durchgefuhrt. Fur beide Variantensind in der Literatur verschiedenste Verfah-ren zu finden, z. B. in [Dada96]. In der Ta-belle 1 sind die Speicherkonzepte hinsicht-lich der oben genannten Kriterien bewertet.Zusatzlich werden als Grenzfalle Unikate,d. h., im Gesamtsystem tritt jedes Objektnur einmalig auf, und Duplikate, d. h., eswerden Kopien erstellt, die aber im Gegen-satz zu Replikaten nicht automatisch abge-glichen werden, aufgefuhrt.

Aus Sicht der Kopplung im UKL kommtfur die synchrone Replikation das Primary-Copy-Verfahren und fur die asynchroneReplikation das Peer-To-Peer-Verfahren inFrage. Da im UKL das administrative Sys-tem IS-H das zentrale System darstellt, bie-tet es sich als das System an, das beim Pri-mary-Copy-Verfahren die Primarkopiehalt. Somit erfolgen Datenmanipulationenim ersten Schritt der Primary-Copy-Replikation in IS-H, die Propagierung alszweiter Schritt dieses Verfahrens kanndann asynchron uber den Kommunika-tionsserver erfolgen. Da bei klinischen Sys-temen Einfuge-Operationen uberwiegen


Bild 5 Kommunikationsverbindung zur �bermittlung von ADT-Daten aus IS-H anMCC und von Operationsdaten aus MCC an IS-H (�bersicht)

Bild 6 Ausschnitt aus der elektronischen ADT- und Leistungsdatenkommunikation amUKL


[Hass97] und somit �nderungskonflikteeher selten sind, sollen gegenuber demStandard des Primary-Copy-Verfahrensfolgende Erweiterungen im UKL zulassigsein:

1. Inkonsistentes Lesen wird toleriert,d. h., ein lokales System darf die lokalenDaten lesen und muss nicht beim Pri-marsystem die Aktualitat prufen.

2. Das initiierende System andert sowohlauf der Primarkopie als auch auf demlokalen Datenbestand. Damit muss aufdiesem System nicht auf die Aktualisie-rung uber den Kommunikationsservergewartet werden, sondern die Verarbei-tung kann sofort fortgesetzt werden,d. h. die Performanz bleibt weitgehenderhalten.

3. Ist das Primarsystem, also IS-H, nichtverfugbar, so wird trotzdem lokal gean-dert und mit der Verarbeitung fort-gesetzt. Die �nderung am Primarsys-tem muss spater nachgeholt werden.

Der dritte Punkt dieser Erweiterungen be-deutet einen dynamischen Wechsel zurasynchronen Replikation, d. h., die Kopienwerden nicht zeitgleich aktualisiert. AufGrund der geforderten Autonomie der kli-nischen Systeme muss eine �nderung anjedem beteiligten System moglich sein, wasz. B. beim Peer-To-Peer-Verfahren gegebenist. Hier darf jedes Replikat geandert wer-den, die Propagierung erfolgt asynchronund Konflikte werden in Kauf genommen.Die durch dieses Verfahren gegebenenfallsentstehenden Konflikte mussen bei der Zu-sammenfuhrung behandelt werden.

3.2.5 Transaktionskonzepte

Replikation von Daten bedeutet Manipula-tion in verteilten Systemen. Um eine ord-nungsgemaße Verarbeitung in verteilten


MCC

IS-H

HL7

Entity

Living_subject

Person

Role

* *

Patient

Participation

* *

Act

* *

ProcedureMaterial

Non_Person

Employee Transportation

PatientArbeitgeber *1 Angehoerige

1 *

Hospitalisation

Ereignis

**

Bewegung

*

1

Zuordnung

* 1

Patient Fall

ProzedurenDiagnosen

11..*

1*

1*

Bewegung

1 1..*

Abbildung Abbildung

Bild 7 Top-down-Integration von HL7-RIM auf IS-H bzw. MCC (grober Ausschnitt derjeweiligen Datenmodelle)

Ziel-konflikte

Verfügbarkeit

KonsistenzPerformanz

Ziele:- viele Kopien- Zugriff zu jeder Kopie

Ziele:- wenige Kopien- asynchrone Änderung

Ziele:- 1-Kopie-Äquivalenz- wenige Kopien- synchrone Änderung

Bild 8 Zielkonflikte der Datenreplikation

Tabelle 1 Bewertung der Speicherkonzepte bezuglich der Zielkonflikte bei Replikation

Konsistenz Verfugbarkeit Performanz

Lesezugriff Schreibzugriff Lesezugriff Schreibzugriff

Duplikate Gering Hoch Hoch Hoch Hoch

AsynchroneReplikation

reduziert,wird automatischhergestellt

Hoch Hoch,geringe Einschrankung

Hoch Hoch,geringe Einschrankung

SynchroneReplikation

Hoch, aber Problemebei Knotenausfall

Hoch Reduziert Hoch Reduziert

Unikate Hoch Reduziert, abhangigvon der Lageder Unikate

Reduziert, abhangigvon der Lage der Unikate

Reduziert, abhangigvon der Lageder Unikate

Reduziert, abhangigvon der Lage der Unikate


Systemen zu gewahrleisten, werden Trans-aktionskonzepte benotigt (vgl. [GrRe93]).Je nach eingesetztem Replikationsverfah-ren konnen nun verschiedene Transak-tionssysteme zum Einsatz kommen. ImFolgenden soll kurz skizziert werden, wiedie im vorhergehenden Unterabschnitt dis-kutierten Replikationsstrategien transak-tionsorientiert umgesetzt werden konnen.

Das Standardverfahren fur die Replikationim UKL sollte das Primary-Copy-Verfah-ren sein, wobei hier dahingehend erweitertwird, dass zusatzlich das lokale Systemebenfalls zeitgleich die �nderung durch-fuhrt. Somit wird an mehreren verteiltenSystemen eine Aktion durchgefuhrt, diedurch ein Transaktionssystem gesichertwerden muss. Das Zwei-Phasen-Commit-Protokoll (2PC-Protokoll) als Transak-tionskonzept garantiert konsistenzwahren-de �nderung im verteilten Fall. DiesesKonzept wird von vielen Datenbankliefe-ranten in Form des XA-Protokolls umge-setzt. Das Anwendungssystem SAP R/3setzt zwar im Allgemeinen auf XA-fahigeDatenbanken auf, gibt diese Funktionalitataber nicht als Schnittstelle weiter. Somitmuss an dieser Stelle ein erweitertes Trans-aktionskonzept eingesetzt werden, dass of-fen geschachtelte Transaktionen zulasst. Dain der ersten Aktion auf IS-H geandertwird, danach auf dem lokalen System, kanndas Konzept der verketteten Transaktionen(sogenannte Sagas [GaSa87]) dieses Pro-blem losen. Auf Kompensationstransaktio-nen, die bei Sagas hinsichtlich des Back-ward Recovery von Interesse sind, soll hierverzichtet werden, sondern gegebenenfallswird die Transaktion neu aufgesetzt, wasdem Forward Recovery entspricht.

Fur die asynchrone Replikation kanndas Konzept der „Queued Transactions“[BeNe97] verwendet werden. Transak-tionsanforderungen werden hier in eineWarteschlange gestellt, die dann von einemServer abgeholt und bearbeitet werden.Anschließend wird ein Ergebnis wiederumin eine Warteschlange gestellt, von wo dasinitiierende System die Antwort entgegennimmt. Diese Funktionalitat wird im We-sentlichen beim Peer-To-Peer-Verfahrenbenotigt, wobei gegebenenfalls auf die Ant-wort verzichtet werden kann. Die Realisie-rung kann z. B. uber den Kommunika-tionsserver geschehen.

In Bild 9 ist ein Replikationsmanager dar-gestellt, der eine adaptive Replikations-strategie durch Kombination der Trans-aktionskonzepte 2PC, Sagas und QueuedTransactions umsetzt. Dieser globale Ma-nager kann zur Realisierung der Replika-tionsziele am UKL beitragen: Im Normal-fall werden die Daten der beteiligtenSysteme uber Sagas geandert. Steht einSystem wegen Ausfall nicht zur Ver-fugung, wird uber die Queued Transac-tions zur asynchronen Replikation ge-wechselt. Am UKL ist IS-H fuhrendesAnwendungssystem fur die Nummernver-gabe. Daher muss bei Nichtverfugbarkeitvon IS-H die Nummernvergabe andersgeregelt werden, z. B. kann in IS-H einNummernbereich gesperrt werden unddieser Bereich wird dann MCC zur Ver-fugung gestellt. Der dynamische Wechselvon synchroner zu asynchroner Replikati-on kann auch dann erfolgen, wenn z. B. diePerformanz des Systems IS-H nicht mehrakzeptabel ist.

3.3 Middleware Integration

Eine grobe Klassifizierung von Middlewareist in [RuMB00] zu finden, wo zwischenPrasentationsintegration, Datenbankinte-gration und Applikationsintegration unter-schieden wird:

& Die Prasentationsintegration ist die ein-fachste Form der Integration. Hier gehtes im Wesentlichen darum, den Benut-zern eine einheitliche Oberflache furden Zugriff auf verschiedene Anwen-dungen zur Verfugung zu stellen.

& Bei der Datenbankintegration greifendie globalen Anwendungen uber eineMiddleware direkt auf die Daten bzw.Datenbanksysteme der Anwendungenzu, z. B. uber ODBC. Die Komplexitatder Integration bei dieser Methodehangt von den Zugriffsmoglichkeitenauf die zugrundeliegenden Datenquellenab. Im Falle von relationalen Daten-banksystemen ist die Integration z. B.relativ einfach. Ein Nachteil besteht da-rin, dass bei �nderung des Daten-modells selbst nur einer Altanwendungdie Integrationslosung angepasst werdenmuss. Ein weiterer Nachteil ist, dass dieLogik der Altanwendungen nicht be-rucksichtigt wird bzw. redundant imple-mentiert werden muss und diese Alt-anwendungen konkurrierend auf dieDaten zugreifen.

& Die Applikationsintegration setzt nundirekt auf den Altanwendungen auf.Middleware wie MOM (Message-or-iented Middleware) oder DOT (Distrib-uted Object Technology) nutzen dabeidie von den Altanwendungen zur Ver-fugung gestellten Schnittstellen in Form


Adaptiver Replikationsmanager

Synchron: 2PC / Sagas Asynchron: Queued Transactions

K1 K2

T1 T2

Ausfall

ReplicaQueue

T2(Ausfall)

APP ADTCOM

MCC Client

MCC DB-Server

ODBC

MCC-COM

IS-H HL7

MCC Kommunikations-dienst

Socket

YACOB

MCC-COM

named pipe

andere Systeme

YA-COB

IS-H

SAP R/3

RFC

eGate HCM

ODBC

Bild 9 Adaptiver Replikationsmanager als Kombination von 2PC/Sagas und Queued Transactions

Bild 10 Architektur der engen Kopplung MCC ! IS-H


von Funktionen und Prozeduren (API).Damit ist also auch die Logik der Alt-anwendungen integriert und die glo-balen Anwendungen treten nicht inKonkurrenz zu den Altanwendungen,sondern bedienen sich deren Funktio-nalitat. Der Nachteil besteht in dergroßeren Komplexitat und in der Ab-hangigkeit von den APIs, die die Alt-anwendungen zur Verfugung stellen.

Da auf die Daten von SAP R/3 nicht direktzugegriffen werden sollte, sondern aus-schließlich uber Schnittstellen wie z. B.RFC oder BAPI, handelt es sich im betrach-teten Szenario um eine Applikationsinte-gration. Also kann fur die nachrichten-ori-entierte Integration eine lose Kopplung,z. B. ein Kommunikationsserver, oder furdie Objekt- bzw. Komponententechnologieeine enge Kopplung, Produkte der CORBA-bzw. EJB-Spezifikation [Corb02; Java02]verwendet werden. Auch die Microsoft-Komponententechnik COMþ [Plat99](vormals DCOM bzw. COM) zahlt zu denVarianten einer Applikationsintegration.

Technisch gesehen stellt die Kopplung ubereinen Kommunikationsserver eine eher ein-fache Integration dar. Sicherlich ist zu be-achten, wie die ausgetauschten Nachrichtenverarbeitet werden, insbesondere aus derSicht transaktionsorientierter Verarbeitung.An dieser Stelle sei auf [ScSS00] verwiesen.Im Folgenden soll die enge Kopplung uberdie Komponententechnologie vertieft wer-den. Da MCC bereits intern COMþ ver-wendet und seitens SAP entsprechendeSchnittstellen zur Verfugung stehen, botsich die Microsoft-Technologie als Middle-ware zur Integration der Systeme MCCund IS-H an. Weiterhin war es moglich, die„fertige“ Komponente YACOB (Yet An-other Communication Box [Unio02]) wie-derzuverwenden.

In Bild 10 ist die Architektur der engenKopplung von MCC zu IS-H dargestellt.Wird im MCC-Client die ADT-Kom-ponente angesprochen, so wird per Socket-Verbindung der MCC-Kommunikations-dienst aufgerufen. An diesen Dienst konntedie YACOB-Komponente angebundenwerden, die nun ihrerseits uber RFC aufein YACOB-spezifisches Modul in SAPzugreift, das letztendlich IS-H anbindet.Falls fur die angesprochene Operation sei-tens IS-H Identifikationsnummern ver-geben werden, so werden diese IDs nebendem Return-Code auf demselben Weg andie ADT-Komponente zuruckgeliefert.

Damit kann nun auch vom MCC-Clientbei erfolgreicher Durchfuhrung auf IS-Hdie Operation auf dem lokalen Datenbank-system durchgefuhrt werden (vgl. die An-merkungen zum erweiterten Primary-Copy-Verfahren im Abschnitt 3.2.4).

Die Propagierung einer �nderung in IS-Hwird uber das SAP-spezifische FormatHCM an den Kommunikationsserver eGa-te gesendet, der diese Nachricht an die ent-sprechenden Systeme verteilt, also auch anMCC selbst. Falls die Transaktion vorherschon in MCC lokal durchgefuhrt wurde,weil z. B. von MCC initiiert, so wird dieNachricht verworfen, andernfalls wird dieTransaktion auf dem lokalen Datenbank-system durchgefuhrt.

Bei einer von MCC angestoßenen Trans-aktion handelt es sich um eine Saga (vgl.Abschnitt 3.2.4), die in der ersten Teiltrans-aktion eine �nderung auf IS-H und in derzweiten Teiltransaktion eine �nderung aufMCC durchfuhrt. Falls nun wahrend derersten Teiltransaktion ein Fehler auftritt, sowird die komplette Transaktion neu auf-gesetzt. Wegen der geforderten Autonomieist denkbar, aber derzeit nicht realisiert,diese Teiltransaktion spater nachzuziehenund mit der lokalen Verarbeitung trotzdemfortzusetzen. Ein Fehlschlagen der zweitenTeiltransaktion wird dadurch neu auf-gesetzt, dass in diesem Fall uber den Kom-munikationsserver die �nderung erneutmitgeteilt wird, d. h., es wird ein ForwardRecovery gemaß dem Sagas-Konzeptdurchgefuhrt, was evtl. eine Konfliktlo-sung impliziert.

4 Diskussion

In diesem Artikel werden die Integrations-moglichkeiten von Anwendungssystemenim Universitatsklinikum Leipzig dis-kutiert, wobei sowohl die eher lose Kopp-lung uber einen Kommunikationsserver alsauch die eher enge Kopplung uber dieKomponententechnologie COMþ dar-gestellt werden. Es wird eine Vorgehens-weise anhand eines Drei-Ebenen-Modellszur Informationssystemintegration vor-geschlagen. Weiterhin werden Konzeptefur Replikationsstrategien und Transak-tionsverfahren vorgestellt.

Fur das UKL haben die Ausfuhrungen dervorhergehenden Abschnitte folgendenNutzen:

1. Die aktuell zur Kopplung von IS-H undMCC verwendeten Integrationstech-niken konnen besser bewertet werden.Es ist jetzt bekannt, welchen theoreti-schen Integrationsansatzen sie zugeord-net werden konnen und welche Vor-und Nachteile diese Ansatze haben.

2. Es ist besser bekannt, welche Problemenicht mit vorhandenen theoretischen/technischen Losungsansatzen gelostwerden konnen, also organisatorisch ge-lost werden mussen. Beispielsweisekann das Problem der Benachrichtigunguber �nderungen mit den behandeltenAnsatzen nicht gelost werden.

3. Es ist besser bekannt, welche Losungenfur die benannten Probleme angestrebtwerden konnen, z. B. durch Anforde-rungen bez. der Implementierung vonSagas zur Umsetzung des Primary-Copy-Verfahrens an die Hersteller/Lie-feranten der Anwendungssysteme.

Bei der Kopplung uber den Kommunika-tionsserver wird mit asynchronen Replika-ten gearbeitet, bei der Kopplung uber dieRFC-Schnittstelle mit synchronen Repli-katen. Die in Abschnitt 3.2.2 genannten In-tegrationsprobleme konnen mit den be-schriebenen Ansatzen wie folgt gelostwerden:

1. Zu den organisatorischen Problemen:& Beim Anlegen von Aufnahmen in

MCC kann uber die RFC-Schnitt-stelle die synchrone Replikation derFallnummer und anderer Falldatenerreicht werden. Mit dem aktuellenEntwicklungsstand der RFC-Schnitt-stelle ist die Transaktionssicherheitjedoch nicht vollstandig gewahrleis-tet.

& Das Fehlen eines Benachrichtigungs-mechanismus uber automatische Da-tenanderungen im Hintergrund be-einflusst die Datensicherheit nichtunmittelbar. Da ein Benachrichti-gungsmechanismus aber als Organi-sationshilfe unverzichtbar ist, warenalso zusatzlich zu Transaktions-konzepten auch Benachrichtigungs-konzpte umzusetzen, die im EKKIS-Projekt nicht behandelt werden.Theoretisch konnte uber das Sperrenvon Datensatzen eine nachtragliche�nderung verhindert werden. Prak-tisch ist ein solches Vorgehen nichtakzeptabel.

2. Zu den technischen Problemen:& Die Forderung nach zentraler Ver-

gabe der Fallnummer erfordert einesynchrone Replikation, wenn außer-



halb des fuhrenden Anwendungssys-tems (hier: SAP R/3 IS-H) neue Auf-nahmen angelegt werden. Bei Ausfallvon IS-H muss das Fehlen der zen-tralen Nummernvergabe in Kauf ge-nommen werden. Kompromiss-regelungen, die ein nachtraglichesZusammenfuhren von Daten auf diekorrekte Fallnummer vorsehen, sindmeist aufwandig und fehleranfallig.

& Da die OP-Planung in MCC-durch-gefuhrt wird, liegt es nahe, Plan-Auf-nahmen unmittelbar in MCC durch-zufuhren, wobei uber die RFC-Schnittstelle eine schnelle synchroneReplikation erreicht wird.

& Um bei Performance-Problemen ei-nes Anwendungssystems die anderenmoglichst wenig zu behindern, soll-ten nur diejenigen Daten synchronrepliziert werden, bei denen es unbe-dingt notwendig ist. Bei asynchronerKommunikation werden unter Um-standen keine Identifikationsnum-mern abgeglichen, sodass nachtragli-che �nderungen von Datensatzenschwierig sind. Adaptive Replika-tionstechniken sollen hier Abhilfeschaffen, befinden sich allerdingsnoch in der Entwicklung.

5 Ausblick

Generell konnten wir fur den Anwen-dungsbereich Krankenhaus aufzeigen, wiefur spezifische Anforderungen geeigneteKopplungsstrategien auf verschiedenenEbenen der Systemintegration entwickeltwerden konnen. Zusammenfassend kannfestgestellt werden, dass im Kontext einesgroßen Universitatsklinikums keine hun-dertprozentige Datenkonsistenz erreichtwerden kann, um die notwendige Auto-nomie der Teilsysteme zu wahren. Einenoptimalen Mittelweg bieten die vorgestell-ten adaptiven Replikationsverfahren.

Als zukunftiger Arbeitspunkt kann derEinsatz eines verbesserten Integrationsser-vers untersucht werden. Hier konnten Ba-sissysteme verwendet werden, die derJ2EE-Spezifikation [JNBL01] genugen.Eine enge Kopplung kann dann uber denTransaktionsdienst JTA, eine lose Kopp-lung uber den Nachrichtendienst JMS rea-lisiert werden. Moglicherweise kann beiBenutzung eines EJB-Servers [Java02] dieYACOB-Komponente durch die EJB-Konnektoren-Technologie [ShSN02] er-

setzt werden. Fur die Anbindung vonMCC erscheint auch die neue Microsoft.NET Technologie [Plat01] sinnvoll.

Literatur

[BeNe97] Bernstein, Philip; Newcomer, Eric: Prin-ciples of Transaction Processing. Morgan Kauf-mann Publishers, 1997.

[Corb02] CORBA: The OMG’s CORBAWebsite.http://www.corba.org, Abruf am 2002-03-01.

[Dada96] Dadam, Peter: Verteilte Datenbankenund Client/Server-Systeme. Springer-Verlag,1996.

[GaSa87] Garcia-Molina, Hector; Salem, Kenneth:Sagas. In: ACM SIGMOD, San Francisco (1987)S. 249–260.

[GrRe93] Gray, Jim; Reuter, Andreas: TransactionProcessing: Concepts and Techniques. MorganKaufmann, 1993.

[Hass97] Hasselbring, Wilhelm: Federated integra-tion of replicated information within hospitals.In: International Journal on Digital Libraries 1(1997) 3, S. 192–208.

[Hass00] Hasselbring, Wilhelm: Information Sys-tem Integration. In: Communications of theACM 43 (2000) 6, S. 32–36.

[Hass02] Hasselbring, Wilhelm: Web Data Integra-tion for E-Commerce Applications. In: IEEEMultimedia 9 (2002) 1, S. 16–25.

[Heal01] HL7-Organisation: Health Level Seven,HL7. http://www.hl7.org, Abruf am 2001–03-01.

[Java02] Java: Java 2 Platform, Enterprise Edition.http://java.sun.com/j2ee, Abruf am 2002-03-20.

[JNBL01] Juric, Matjaz; Nagappan, Ramesh;Basha, Jeelani; Leander, Rick; Long, Peter: Pro-fessional J2EE EAI. WROX, 2001.

[LaPH99] Lange, Matthias; Prokosch, Hans-Ul-rich; Hasselbring, Wilhelm: Eine Taxonomie furKommunikationsserver im Krankenhaus. In: In-

formatik, Biometrie und Epidemiologie in Medi-zin und Biologie 30 (1999) 1, S. 21–43.

[Meie02] Meierhofer AG: Projekte und Produkteder Meierhofer AG. http://www.meierhofer.de,Abruf am 2002-03-15.

[Offi01]OFFIS: EKKIS: Enge Kopplung klinischerInformationssysteme. http://www.offis.de/projekte/ekkis/projekt_ekkis.htm, Abruf am2002-03-01.

[Plat99] Platt, David: COMþ verstehen. MicrosoftPress, 1999.

[Plat01] Platt, David: Die Microsoft .Net Platt-form. Eine Einfuhrung. Microsoft Press, 2001.

[RuMB00] Ruh, William; Maginnis, Francis;Brown, William: Enterprise Application Integra-tion: A Wiley Tech Brief. John Wiley & Sons,2000.

[RuJB99] Rumbaugh, James; Jacobson, Ivar;Booch, Grady: The Unified Modeling LanguageReference Manual. Addison-Wesley, 1999.

[Sap02] SAP: SAPHelp Portal. http://help.sap.com,Abruf am 2002-03-01.

[ScSS00] Schuler, Christoph; Schuldt, Heiko; Schek,Hans-Joerg: Transactional Execution Guaranteesfor Data-Intensive Process in Medical Informa-tion Systems. In: Proceedings of the 1st Eur-opean Workshop on Computer-based Supportfor Clinical Guidelines and Portals, Leipzig(2000), S. 89–103.

[ShSN02] Sharma, Rahul; Stearns, Beth; Ng, Tony:J2EE Connector Architecture and EnterpriseApplication Integration. Addison Wesley, 2002.

[Unio02]UNIORG: External Transaction Services.http://www.uniorg.de/www/pdf/ETS_Handbuch.pdf, Abruf am 2002-03-01.

[WiBW01] Winter, Alfred; Brigl, Birgit; Wendt,Thomas: A UML-based ontology for describinghospital information system architectures. In:Medinfo, Netherlands 10 (2001) 1, S. 778–782.

[WiHa95] Winter, Alfred; Haux, Reinhold: AThree-Level Graph-Based Model for the Man-agement of Hospital Information Systems. In:Methods of Information in Medicine 34 (1995)4, S. 378–396.


Abstract

Strategies for coupling enterprise application systems in hospitals

The realization of specific coupling strategies and integration techniques is discussed exem-plarily for a university hospital, the Universitatsklinikum Leipzig (UKL) in Germany. The inte-gration of the central patient management system serving the administrative departmentwith the clinical workplace systems serving hospital wards is presented. We analyse the inte-gration with respect to the underlying theoretical conceptions and discuss information man-agement issues for deployment and maintenance of the overall IT infrastructure.This paper presents the pros and cons of synchronous and asynchronous patient data repli-cation, the practical experience with the deployment of a communication server, and theexperience with using an RFC interface, a proprietary interface to the enterprise resourceplanning system SAP R/3. Both, organizational and technical issues are addressed in thiscontext.

Keywords: hospital information system (HIS), synchronous/asynchronous communication,coupling strategies, communication server, enterprise application integration, schema inte-gration, data replication


Documents

Kopplungsstrategien für Anwendungssysteme im Krankenhaus; Strategies for coupling enterprise application systems in hospitals;