EMP Tek E3c User Manual

Modellierung und Bewertungvon Integrationin KrankenhausinformationssystemenDissertationzur Erlangung des akademischen GradesDr. rer. med.an der medizi

4 Standards f¨ur InformationssystemarchitekturenOSI-Referenzmodell Referenzmodell f¨ur offene verteil-te Informationsverarbeitung(RM-ODP)Object Managem

4.6 Vergleichbarkeit von ArchitekturstandardsZachman-Rahmenwerk Architektur integrierterInformationssysteme (ARIS)Enterprise Applic ation Integration

5 Gesch¨aftsprozessmodellierung — Ei ne Einf¨uhrung5.1 VorbemerkungenDieses Kapitel stellt kurz drei Ans¨atze zur Gesch¨aftsprozessmodellierung vor: d

5 Gesch¨aftsprozessmodellierung — Eine Einf¨uhrungAbbildung 5.1: Beispiel f¨ur eine EPK (Quelle: [Langner et al. 1997], S. 481, Abb. 1)78

5.3 Die Business Process Modeling Language”(. . . ) wird der Funktionsbegriff im Sinne der Aufgabe verwendet, d. h. es stellt eine durch physische oder

5 Gesch¨aftsprozessmodellierung — Eine Einf¨uhrung<wsdl:message name="requestMessage"><wsdl:part name="orderID" element=&

5.4 Das Semantische ObjektmodellAbbildung 5.3: Beispiel f¨ur eine mit der BPMN erstellte Prozessbeschreibung (Quelle: [BPMI Notation WG 2004],S. 139,

5 Gesch¨aftsprozessmodellierung — Eine Einf¨uhrungAbbildung 5.4: Ebenen der Unternehmensarchitektur im SOM-Ansatz (Quelle: [Ferstl and Sinz 1995], S.

5.4 Das Semantische ObjektmodellAbbildung 5.5: Metamodell f¨ur die Gesch¨aftsprozessmodellier ung im SOM-Ansatz (Quelle: [Ferstl and Sinz 1995],S. 216

Inhalts¨ubersichtInhalts¨ubersicht IInhaltsverzeichnis IIIKastenverzeichnis IXAbbildungsverzeichnis XITabellenverzeichnis XVA Einleitung 1I Grundlagen

5 Gesch¨aftsprozessmodellierung — Eine Einf¨uhrunga)b)Abbildung 5.6: Beispiel f¨ur ein Interaktionsmodell (a) und ein Vorgangs-Ereignis-Modell (b) (Qu

Teil IIArchitekturmodellierung85

6 Einf¨uhrung in das 3LGM26.1 VorbemerkungenDas 3LGM2ist ein Metamodell f¨ur die Modellierung von Informationssystemen (vgl. Kasten”Grundbegriffe (4)“

6 Einf¨uhrung in das 3LGM2hervorgehoben, da alle weiteren Klassen ohne sie nicht sinnvoll verwendet werden k¨onnen.6.2.1 Fa chliche EbeneAuf der fachl

6.2 Die Ebenen des 3LGM2und ihre Hauptklassena)b)Abbildung 6. 1: Spezifikationen der fachlichen Ebene des 3LGM2mit der UML (vgl. [Winter et al. 2003],

6 Einf¨uhrung in das 3LGM2a)b)Abbildung 6.2: Spezifikationen der logischen Werkzeugebene des 3LGM2mit der UML (vgl. [Winter et al. 2003], S. 547,Abb. 3

6.2 Die Ebenen des 3LGM2und ihre Hauptklassena)b)Abbildung 6.3: Spezifikationen der physischen Werkzeugebene des 3LGM2mit der UML (vgl. [Winter et al.

6 Einf¨uhrung in das 3LGM26.2.3 Physische WerkzeugebeneAuf der physischen Werkzeugebene werden konventionelle physische Datenverarbeitungs-bausteine w

6.3 Klassen f¨ur die IntegrationsmodellierungAbbildung 6.4: Auszug des Informationssystems des UKL in Drei-Ebenen-Darstellungbetreffenden Objekttyps er

6 Einf¨uhrung in das 3LGM2HL7-Ereignistyp Beschreibung (Ausz¨uge aus dem Standard)A01”3.2.1 ADT/ACK - admit / visit notificat ion (event A01) An A01eve

6.4 Prozessmodellierungpierbasierter Kommunikation.6.4 ProzessmodellierungAuf der Basis der in [Brigl et al. 2003] beschriebenen Erg¨anzung des 3LGM2k

6 Einf¨uhrung in das 3LGM2Sowohl das zum urs pr¨unglichen 3LGM als auch das zum 3LGM2entwickelte Modellierungs-werkzeug pr¨asentieren Modelle grafisch,

6.5 Das 3LGM2und Ar chitekturstileDas 3LGM2als ArchitekturstilDas 3LGM2wurde als generisches Metamod ell entwickelt, das nicht auf einen bestimmtenArc

7 Flexible Architekturmodellierung —¨Uberarbeitung des 3LGM27.1 Begriffe f¨ur die Modellierung von Kompo n e n ten auf d e r Basis des 3LGM2In d en Abs

7 Flexible Architekturmo dellierung —¨Uberarbeitung des 3LGM2Einbettung in das 3LGM2, d. h. seine Assoziationsbeziehungen zu anderen Klassen, wird hie

7.2¨Uberarbeitung des 3LGM2 0..* 0..* greift_zu_auf Zugriffsart: {interpretierend, bearbeitend} Objekttyp 0..* Aufgabe ist_Teil_von 0..* 0..* ist_T

7 Flexible Architekturmo dellierung —¨Uberarbeitung des 3LGM2HL7-Ereignistyp HCM-EreignistypA01 (admit / visit notification) NP11I0 (Aufnahme anlegen (

7.2¨Uberarbeitung des 3LGM2 Organisations- einheit wird_ erledigt_in 0..* 0..* 0..* 0..* greift_zu_auf Zugr-art: {interpretierend, bearbeitend} wir

InhaltsverzeichnisInhalts¨ubersicht IInhaltsverzeichnis IIIKastenverzeichnis IXAbbildungsverzeichnis XITabellenverzeichnis XVA Einleitung 1A.1 Gegenst

7 Flexible Architekturmo dellierung —¨Uberarbeitung des 3LGM2Kasten 7.1: Das Weglassen de r Konfigurationen im 3LGM2AIm 3LGM2sind f¨ur die Verkn¨upfung

7.3 Transformation von Nachr ichtentypenOperationen und die fachliche Ebene des 3LGM2ADie Klasse Operation hat zwei unmittelbare Assoziationsbeziehung

7 Flexible Architekturmo dellierung —¨Uberarbeitung des 3LGM2Komponenten zu erf¨ullen sind. Daher wird in diesem Zusammenhang von Diensten (bzw.Spezifi

7.5 Kommunikationsverbindu ngen7.4.2 Modellierung von Diensten mit dem 3LGM2AnwendungsdiensteZur Beschreibung von Anwendungsdiensten (vgl. 7.4.1) stel

7 Flexible Architekturmo dellierung —¨Uberarbeitung des 3LGM2Abbildung 7.3: Eine Kommunikationsverbindung zur¨Ubertr agung von Falldaten im Informatio

7.6 Beispiele f¨ur die Modellierung verschiedener ArchitekturstileAbbildung 7.4: Eine einfache OMA-basierte Architektur1. Informationsklassen werden a

7 Flexible Architekturmo dellierung —¨Uberarbeitung des 3LGM2– je eine Bausteinschnittstelle f¨ur die letztgenannten Anwendungsbausteine,¨uber diesie

7.6 Beispiele f¨ur die Modellierung verschiedener ArchitekturstileAbbildung 7.5: Eine einfache OMA-basierte Architektur– die Anwendungsbausteine Patie

7 Flexible Architekturmo dellierung —¨Uberarbeitung des 3LGM2Abbildung 7.6: Eine einfache KommunikationsserverarchitekturBeispielEin einfaches Modell

7.7 Einf¨uhrung der Klasse Begriffssystem7.7 Einf¨uhrung der Klasse BegriffssystemUnabh¨angig von der Modellierung verschiedener Architekturstile wird i

Inhaltsverzeichnis3.3 Architekturstile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.4 Architekturstile f¨ur Information

7 Flexible Architekturmo dellierung —¨Uberarbeitung des 3LGM2Abbildung 7.8: Beis piele f¨ur die Zuordnung von Begriffssystemen zu greift_zu_auf-bezieh

7.7 Einf¨uhrung der Klasse Begriffssystem wird_erledigt_in mit_Hilfe_von mit_Hilfe_von 0..* 0..* 0..* 0..* kann_unterstützen Aufgabe 0..* kann_unterst

7 Flexible Architekturmo dellierung —¨Uberarbeitung des 3LGM2 Subnetz Netztyp Netzprotokoll Physischer Daten-verarbeitungsbaustein 0..* 0..* gehört_zu

Teil IIIArchitekturbewertung117

8 Theoretische Vorbereitung der Integrationsbewertung8.1 VorbemerkungenDieses Kapitel bereitet, aufbauend auf den Grundlagen zum 3LGM2in Kapitel 6 und

8 Theoretische Vorbereitung der IntegrationsbewertungAbbildung 8.1: Interpretation von ist_Teil_von-BeziehungenFraglich ist nun, ob auf objt auch dan

8.4 Pr¨adikate zu Assoziationsbeziehungen d es 3LGM2Aden Instanzmengen der Klassen des 3LGM2Azu kennzeichnen. Die Angabe auf ∈ AUF bedeutetbeispielswe

8 Theoretische Vorbereitung der Integrationsbewertungexistiert2.Ende — DefinitionF¨ur die fachliche Ebene d es 3LGM2Astehen mit Definition 8.2 u. a. fol

8.5 Zusammengesetzte Pr¨adikate f¨ur die Unterst¨utzung der BewertungDie Berechnungsvorschrift f¨ur benoetigt ist: awb ben¨otigt objt genau dann, wenn

Inhaltsverzeichnis7 Flexible Architekturmodellierung —¨Uberarbeitung des 3LGM2997.1 Begriffe f¨ur die Modellierung von Komponenten auf der Basis des 3L

8 Theoretische Vorbereitung der Integrationsbewertung8.5.3 Pr¨adikate f¨ur die Analyse von Kommunikation¨Ubermittlung von InformationenObjekttypen wer

8.5 Zusammengesetzte Pr¨adikate f¨ur die Unterst¨utzung der Bewertung¨Ubermittlung von Informationen zu BegriffssystemenIm 3LGM2Aist auch f¨ur Begriffs

8 Theoretische Vorbereitung der Integrationsbewertungund ruft_auf(auf, ergt, awb2, awb3) gelten, dann gilt auch ruft_auf(auf, ergt, awb1, awb3).8.6 Fo

8.6 Formalisierung von Kommunikationsverbindungen(bss1, bss2, op, h (vbss1,1, vbss1,2, vop1, h (vvbss1,1,1, vvbss1,1,2, vvop1,1, hi ) i ), (vbss2,1, v

9 Die Erf¨ullung von IntegrationsanforderungenDie bisherigen Ausf¨uhrungen zur Mod ellierung von Informationssystemen auf der Basis des3LGM2Awaren hau

9 Die Erf¨ullung von IntegrationsanforderungenAbbildung 9.1: Auszug aus der fachlichen Ebene des Informationssystems des UKLvon KIS zur Unterst¨utzung

9.2 Ein AnwendungsszenarioElemente HinweiseFachliche EbeneAufgabe Patientenaufnahme (station¨ar) das Aufnehmen (Registrieren) station¨arer PatientenAu

9 Die Erf¨ullung von Integrationsanforderungena)b)Abbildung 9.2: Ausz¨uge aus der logischen Werkzeugebene des Informationssystems des UKL132

9.3 Anforderungsdom¨anenElemente Hinweiselogische Werkzeugebene (Fortsetzung)Anwendungsbaustein Verschl¨usselungssystem zentrales Werkzeug f¨ur die Au

Inhaltsverzeichnis9.5.1 Pr¨ufung auf realisierte Datenintegration . . . . . . . . . . . . . . . . . . 1439.5.2 Pr¨ufung auf realisierte funktionale In

9 Die Erf¨ullung von IntegrationsanforderungenAbbildung 9.3: Datendom¨ane des Objekttyps Fallben. Die Definition sieht vor, dass eine Datendom¨ane jewe

9.3 Anforderungsdom¨anenAbbildung 9.4: Funktionale Dom¨ane der Aufgabe Diagnosen- und Prozedurenv erschl¨usselungdieselbe Aufgabe unterst¨utzen. Das U

9 Die Erf¨ullung von IntegrationsanforderungenEnde — Definition un d BerechnungsvorschriftAbbildung 9.4 zeigt ein Beispiel f¨ur eine funktionale Dom¨an

9.3 Anforderungsdom¨anena)b)Abbildung 9.5: Zuordnung der Begriffssysteme D RG, ICD10 und OPS301 zu greift_zu_auf-Beziehungen (a) undsemantische Dom¨an

9 Die Erf¨ullung von IntegrationsanforderungenAbbildung 9.6: Kontextdom¨ane des Objekttyps Fall und des physischen Datenverarbeitungsbausteines PC NCH

9.3 Anforderungsdom¨anenAbbildung 9.7: Pr¨asentationsdom¨ane des physischen Datenverarbeitungsbausteines PC NCH 15jekttypen weg, da sie unabh¨angig vo

9 Die Erf¨ullung von IntegrationsanforderungenAnwendungsbausteine gemeinsam auf dem physischen Datenverarbeitungsbaustein PCNCH 15 installiert sind un

9.4 Kommunikationsdom¨anenAbbildung 9.8:¨Ubermittlungsdom¨ane des Objekttyps Fall, des Ereignistyps NP11I0 und des AnwendungsbausteinesPatientenverwal

9 Die Erf¨ullung von IntegrationsanforderungenAbbildung 9.9: Aufrufdom¨ane der Aufgabe Diagnosen- und Prozedurenverschl¨usselung, des Ereignistyps DIA

9.5 Anwendung: Pr¨ufung der Er f¨ullung von IntegrationsanforderungenKasten 9.1: Ereignistype n und Kommunikationsdom¨anenDurch die Ber¨ucksichtigung

InhaltsverzeichnisZ.2.4 Fragen zu Ziel Z4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193Z.3 Diskussion . . . . . . . . . . . . . .

9 Die Erf¨ullung von Integrationsanforderungena)b)Abbildung 9. 10: Vergleich der Datendom¨ane des Objekttyps Fall und des Ereignistyps NP11I0 (a) mit

9.5 Anwendung: Pr¨ufung der Er f¨ullung von IntegrationsanforderungenEin Vergleich der Datendom¨ane des Objekttyps Fall und des Ereignistyps NP11I0 in

9 Die Erf¨ullung von Integrationsanforderungena)b)Abbildung 9.11: Vergleich der funktionalen Dom¨ane der Aufgabe Diagnosen- und Prozedurenverschl¨usse

9.5 Anwendung: Pr¨ufung der Er f¨ullung von Integrationsanforderungen9.5.3 Pr¨ufung auf realisierte semantische IntegrationSemantische Integration kan

9 Die Erf¨ullung von Integrationsanforderungena)b)Abbildung 9.12: Vergleich der semantischen Dom¨ane des Begriffssystems ICD10 (a) mit der¨Ubermittlun

9.5 Anwendung: Pr¨ufung der Er f¨ullung von Integrationsanforderungena)b)Abbildung 9.13: Ver gleich der semantischen Dom¨ane des Begriffssystems ICD10

9 Die Erf¨ullung von Integrationsanforderungendie semantische Dom¨ane von bgs Teilmenge jeder Aufrufdom¨ane von auf ist. Der Ausdruck∀ergti∈ ERGT∗,awb

9.5 Anwendung: Pr¨ufung der Er f¨ullung von Integrationsanforderungena)b)Abbildung 9.14: Vergleich der Kontextdom¨ane des Objekttyps Fall, des physisc

9 Die Erf¨ullung von Integrationsanforderungenenthaltene Anwendungsbaustein Bild- und Befundserver nicht in der¨Ubermittlungsdom¨aneenthalten ist (Abb

9.5 Anwendung: Pr¨ufung der Er f¨ullung von Integrationsanforderungena)b)Abbildung 9.15: Vergleich der Zugriffsdom¨ane des physischen Datenverarbeitung

InhaltsverzeichnisVIII

9 Die Erf¨ullung von Integrationsanforderungen∀ergti∈ ERGT∗,awbj∈ AWB∗: ZDom(pdvb) ⊆ UebDom(objt, ergti, awbj)ERGT∗= Menge der ergti, die zu einer Bea

9.5 Anwendung: Pr¨ufung der Er f¨ullung von Integrationsanforderungena)b)Abbildung 9.16: Vergl eich der Zugriffsdom¨ane des physischen Datenverarbeitun

9 Die Erf¨ullung von Integrationsanforderungenist also hier durch zentrale Zugriffsverwaltung mit funktionaler Integration aufgehoben.156

10 Abh¨angigkei t vo n Anwendungsbausteinen10.1 VorbemerkungenIm Zusammenhang mit Datenbanken, insbesond ere mit verteilten Datenbanken, wird das inde

10 Abh¨angigkeit von Anwen dungsbausteinenAbbildung 10.1: L¨osungsspektrum zur Unterst¨utzung heterogener Datenbanken (Quelle: [Rahm 1994], Abschnitt

10.2 Informationale und funktionale Abh¨angigkeittreffenden Objekttyps aktualisiert werden, d. h. es m¨ussen Kommunikationsverbindungen f¨urihren Abgle

10 Abh¨angigkeit von Anwen dungsbausteinenund ihre Assoziationsbeziehung zur Klasse Aufgabe modelliert werden.Auch zur formalen Beschreibung der funkt

10.3 Ausf¨uhrungsabh¨angigkeit, transaktionale Abh¨angigkeit und Transaktionsst¨arkehat:AAG(awb∈ AWB) := |{bssi∈ BSS}|besitzt(awb, bssi) ∧∃bssj∈ BSSop

10 Abh¨angigkeit von Anwen dungsbausteinen10.3.3 Die Transaktionsst¨arke einer Transaktionsausf¨uhrungSowohl informationale als auch funktionale Abh¨a

10.4 Ein Anwendungsszenario aus dem Universit¨atsklinikum Leipzigzul¨assige Ausf¨uhrungen: Trans aktionsausf¨uhrungen mit einer standardisierten Trans

Kastenverzeichnis2.1 Grundbegriffe (1): Informationen, Daten, Wissen . . . . . . . . . . . . . . . . . . . . . . . . 112.2 Grundbegriffe (2): Informatio

10 Abh¨angigkeit von Anwen dungsbausteinenhervor. Die Kommunikationsverbindungen 1 bis 5 ohne 3b gehen vom Patientenverwaltungssys-tem aus und f¨uhren

10.4 Ein Anwendungsszenario aus dem Universit¨atsklinikum LeipzigDie Startpunkte der elektronischen Kommunikationsverbindungen zum PIDS-Modul sind num

10 Abh¨angigkeit von Anwen dungsbausteinena)b)Bei a) sind die Endpunkte der Kommunikationsverbindungen vom Patientenverwaltungssystem zuden”Ziel“-Anwe

10.4 Ein Anwendungsszenario aus dem Universit¨atsklinikum LeipzigDie Kommunikationsverbindu ng 7 geht vom Patientenverwaltungssystem aus und f¨uhrt zu

10 Abh¨angigkeit von Anwen dungsbausteinenDiese Anwendungsbausteine sin d vom Patientenverwaltungssystem informational ab-h¨angig.3. AGF(awbi) = 0 f¨u

10.4 Ein Anwendungsszenario aus dem Universit¨atsklinikum LeipzigModul informational abh¨angig.3. AGF(awb1) = 1 f¨ur– das COPRA-basierte Patientendate

11 Heterogenit¨atsbewertung von Kommunikationsverbindungen11.1 VorbemerkungenIn vielen Informationssystemen werden viele unterschiedliche Integrations

11 Heterogenit¨atsbewertung von KommunikationsverbindungenKasten 11.1: Exkurs: Ausrichtung von Symbo lsequenzenNeedleman-Wunsch-AlgorithmusDer Algorit

11.2 Der absolute Heterogenit¨atsgrad von Kommunikationsverbindu ngen3.1. Die Kommunikationsbeziehungen werden entsprechend der Definitionsgleichung8.4

11 Heterogenit¨atsbewertung von KommunikationsverbindungenAuszurichtende Kommunikationsverbindungen:(bss1, bss2, op1, hi), (bss2, bss3, op3, hi), (bss

11.2 Der absolute Heterogenit¨atsgrad von Kommunikationsverbindu ngenZu vergleichende Ko mmunikationsverbindungen:(bss1, bss2, op1, )h (bss7, bss8, op

11 Heterogenit¨atsbewertung von Kommunikationsverbindungender aufgerufenen Bausteinschnittstellen plus Abweichung der Operationen (Regeln 3.3.3und 3.3

11.2 Der absolute Heterogenit¨atsgrad von Kommunikationsverbindu ngen(bss1, bss2, op1)(bss2, bss3, op2)(bss3, bss4, op3)(bss4, bss5, op4)(bss1, bss3,

11 Heterogenit¨atsbewertung von KommunikationsverbindungenAuch die Definition des Heterogenit¨atsgrades H f¨ur n Kommunikationsverbindungen erfolgtauf

11.3 Der relative Heterogenit¨atsgrad von Kommunikationsverbindu ngenWenn das 3LGM2um eine Gleichheitsrelation f¨ur Bausteinschnittstellen erweitert w

11 Heterogenit¨atsbewertung von Kommunikationsverbindungenme wird durch die Anzahl der Paare dividiert un d mit n − 1 multipliziert:pr(kb1, . . . , kb

11.4 Der kostenbewertete Heterogenit¨atsgrad von Kommunikationsverbindu ngen11.4 Der kostenbewertete Heterogenit¨atsgrad von Kommunikationsverbindunge

11 Heterogenit¨atsbewertung von Kommunikationsverbindungenwerte der einzelnen Vektoren von Kommunikationsbeziehungen werden die in denfolgenden Regeln

11.4 Der kostenbewertete Heterogenit¨atsgrad von Kommunikationsverbindu ngenDie Bedeutung der Berechnung f¨ur einen einzelnen Vektor von Kommunikation

Abbildungsverzeichnis1.1 Dimensionen der Qualit¨at von Informationssystemen (Quelle: [Stylianou and Kumar2000], S. 100 , Abb. 1, S. 103, Tab. 1) . . .

11 Heterogenit¨atsbewertung von KommunikationsverbindungenHier wird vorausgesetzt, dass eine detailliertere Modellierung zu einer vergr¨oßerten Anzahl

11.5 Ein Anwendungsszenario aus dem Universit¨atsklinikum Leipziga)b)Bei a) sind di e Endpunkte der Kommunikationsverbindungen vom Patientenverwaltung

11 Heterogenit¨atsbewertung von Kommunikationsverbindungena)(s1, s2, o1, 1000e) (s2, s3, o2, 200e) (s3, s8, o7, 2500e)(s1, s2, o1, 1000e) (s2, s4, o3,

Z AbschlussZ.1 VorbemerkungenIn den Kapiteln zwischen der Einleitung und dem hier beginnenden Abschluss wurde das T he-ma der Informationssystemarchit

Z Abschluss– physische Integration,– Datenintegration,– funktionale Integration,– semantische Integration,– Kontextintegration,– Pr¨asentationsintegra

Z.2 Beantwortung der Fragenanwend ungsbereichsbezogene Standards f¨ur Nachrichten- bzw. Dokumentenformate und ggf.zugeh¨orige Ereignistypen, z. B HL7.

Z AbschlussZ.2.2 Fra gen zu Ziel Z2F2.1Welche bekannten Architekturstandards gibt es und welche Charakteristika haben sie?Architekturstandards wurden

Z.2 Beantwortung der FragenDie in Abschnitt 4.2 vorgestellten technischen Rahmenwerke wurden, mit Ausnahme vonTOGAF, als Grundlage f¨ur spezielle Arch

Z AbschlussTOGAF TOGAF ist ein Rahmenwerk f¨ur den Entwu rf bzw. die Weiterentwicklung von In -formationssystemarchitekturen und damit auch f¨ur die A

Z.2 Beantwortung der FragenDie¨Uberarbeitung reflektiert das Objekt- bzw. Komponentenkonzept, das haupts¨achlich imRM-ODP und in den mit der OMA eng ve

Abbildungsverzeichnis4.20 Architekturkontinuum (a) und L¨osungskontinuum (b) in TOGAF, Vers ion 8 (Quelle:[The Open Group 2003], Part III, Enterprise

Z AbschlussF4.2Wie k¨onnen die in Frage F2.3 genannten Int egrationstechniken ausgetauscht werden undwelche Einbußen oder Gewinne an Funktionalit¨at e

Z.2 Beantwortung der Fragenunterteilt. Die¨Ubermittlung von Objekttypen steht d abei f¨ur das¨Ubermitteln bestimm-ter Daten zwischen Anwendungsbaustei

Z AbschlussAnwendung des Dom¨anenkonzeptes festgestellt werden, welche Integrationsanforderungen inden Architekturen erf¨ullt sind. Die Kennzahlen erm

Z.3 Diskussionangemessene Mod ellierung der Integrationsinfrastruktur (Bausteinschnittstellen, Operationenusw.).Verallgemeinerung durch Kennzahlberech

Z Abschluss· die Kennzahl Transaktionsst¨arke und· die Kennzahlen absoluter Heterogenit¨atsgrad, relativer Heterogenit¨atsgrad und kos-tenbewerteter H

Anhang A Anforderungskatal og f¨ur die Informationsverarbeitung i mKrankenhaus (Auszug)Der Anhang enh¨alt einen Auszug aus dem Anforderungskatalog f¨u

Anhang A Anforderungskatalog f¨ur die Informationsverarbeitung im Kr ankenhaus (Auszug) ii

iii

Anhang A Anforderungskatalog f¨ur die Informationsverarbeitung im Kr ankenhaus (Auszug) iv

Anhang B UML-Diagramme f¨ur die Ebenen des 3LGM2AFachliche Ebene 0..* 0..* greift_zu_auf Zugriffsart: {interpretierend, bearbeitend} Objekttyp 0..*

Abbildungsverzeichnis7.8 Beispiele f¨ur die Zuordnung von Begriffssystemen zu greift_zu_auf-beziehungen: Beider Interpretation und Bearbeitung von Dia

Anhang B UML-Diagramme f¨ur die Ebenen des 3LGM2ALogische Werkzeugebene wird_erledigt_in mit_Hilfe_von mit_Hilfe_von 0..* 0..* 0..* 0..* kann_unterst

Physische Werkzeugebene Subnetz Netztyp Netzprotokoll Physischer Daten-verarbeitungsbaustein 0..* 0..* gehört_zu 1..* Standort Bausteintyp 0..* ist_Te

Literaturverzeichnis[Abowd et al. 1995] Abowd, G., R. Allen and D. Garlan (1995): Formalizing style to understanddescriptions of software architecture

Literaturverzeich nis[CCOW 2000c] CCOW (2 000c): Health Level-Seven Standard Context Manag e ment Specification,Technology- and Subject-Independent Com

Literaturverzeich nis[HL7 1999] HL7 (1999): Health Level Seven (HL7). Version 2.3.1; Standard der HL7-Organisation;erh¨altlich f¨ur Mitglieder u. a.¨u

Literaturverzeich nis[Langner et al. 1997] Langner, P., C. Schneider and J. Wehler (1997): Prozeßmodellierung mitereignisgesteuerten Prozeßketten (EPK

Literaturverzeich nis[OMG 2002b] OMG (2002b): Genomic Maps Specificatio n. Version 1.0.[OMG 2002c] OMG (2002c): Persistent State Ser vice Specification.

Literaturverzeich nis[Washburn and Evans 1994] Washburn, K. and J. Evans, eds. (1994): TCP/IP. Bonn: Addison-Wesley.[Wendt et al. 2004] Wendt, T., A.

Stichwortverzeichnis1. . . 93LGM22, 3, 2 6, 28, 87–97, 192¨Uberarbeitung des ˜ 99–105fachliche Ebe ne 87, 88, 100Hauptklassen des ˜ 87–92Klassen f¨ur

Abbildungsverzeichnis10.2 Alte Architektur im Anwendungsszenario aus dem UKL; hervorgehoben sind die Anwen-dungsbausteine der Datendom¨ane des Objektt

StichwortverzeichnisBPML siehe Business Proc e ss Mo deling Lan-guageBusiness Process Modeling Language 79–81CCarnegie Mellon University 22School of C

StichwortverzeichnisEurop¨aisches Komitee f¨ur Normung 31, 46FFehlertoleranz 11File Transfer P rotocol 35, 52Framework for Information Systems Archite

StichwortverzeichnisInternationale Organisation f¨ur Standardisierung31, 32Internet 61Internet Engineering Task Force 34Internet Protocol 34, 52Interp

StichwortverzeichnisMPEG siehe Moving Picture Experts GroupMuster 24, 25, 27, 29, 30Architektur˜ f¨ur EAI 62Nnachrichtenbasierte Kommunikation siehe K

StichwortverzeichnisRolle 31SSatz 22Schicht 33, 44˜en des OSI-Referenzmodells siehe OSI-ReferenzmodellSchnittstelle 22, 35, 40, 72, 9 9, 102–105Schnit

StichwortverzeichnisTransaction Process ing Monitor 62Transaktion 157–159, 195Abgleichs˜ 158˜sausf¨uhrung 162 –163Kategorien von ˜en 162–163 , 168, 16

Stichwortverzeichnisxxii

Tabellenverzeichnis3.1 Beispiele f¨ur Architekturstile (zusammengestellt aus [Shaw and Garlan 1996], Abschnit-te 2.2-2.5, S. 21-25) . . . . . . . . .

A EinleitungIn vielen Krankenh¨ausern werden zur Zeit in großer Breite rechnerunterst¨utzte Anwendungs-systeme eingef¨uhrt. Sie dienen u. a. der Versc

A Ein leitung– Kontextintegration,verschiedene Integrationstechniken, z. B.– nachrichtenbasierte Kommunikation,– Remote Function Call,– Object Request

A.2 Zielsetzung un d FragestellungStandards kaum m¨oglich.Problem P2 F¨ur das Dokumentieren bzw. d as Mo dellieren von Integrationsanforderungenund In

Bibliographische BeschreibungThomas WendtModellierung und Bewertung von Integration in KrankenhausinformationssystemenUniversit¨at Leipzig, Dissertati

A Ein leitungZu Problem P4 ist kein spezielles Ziel angegeben, da die Werkzeugentwicklung in dieser Ar-beit nicht behandelt wird. Mit dem in [Wendt et

Teil IGrundlagen5

1 Bewertung der Integration: Ziel und GrundannahmenDie Bewertung des Einsatzes bestimmter Integrationstechniken nimmt, nach ausf¨uhrlicher Vor-bereitu

1 Bewertung der I ntegration: Ziel und GrundannahmenAbbildung 1.1: Dimensionen der Qualit¨at von Informationssystemen (Quelle: [Stylianou and Kumar 20

1.2 Grundannahmen der ArchitekturbewertungMit den beiden anderen Fragen wird unterstellt, dass die Komplexit¨at d es Informationssys-tems im Mittelpun

2 Integrationsanforderungen2.1 VorbereitungDie in diesem Kapitel vorgestellten Kategorien von I ntegrationsanforderungen sind wichtigeGrundlage f¨ur d

2 IntegrationsanforderungenKasten 2.2: Grundbegriffe (2 ): Informationssystem, Anwendungssystem,IntegrationEin Informationssystem sei nach [Haux et al.

2.2 Kategorien von Integrationsanforderungen Abbildung 2.1: IT-Infrastruktur-Integrationsprofile des IHE IT Infrastructure Technical Framework, Vol. 1

2 Integrationsanforderungenaus d er Kategorie . . .“ zu vermeiden.2.2.1 Physische IntegrationDefinition 2.1 : Physische Integration ist gegeben, wenn d

2.2 Kategorien von Integrationsanforderungen”Data integration means that a particular data item — once recorded — is immediately available for allrele

2 IntegrationsanforderungenDualit¨at von Datenintegration und funktionaler IntegrationZwischen Datenintegration und funktionaler Integration besteht e

2.2 Kategorien von IntegrationsanforderungenKasten 2.3: Exkurs zur semantischen IntegrationSemantische Integration von Anwendungssystemen soll sichers

2 Integrationsanforderungenselecting the same patient in multiple applications. It also improves patient safety by reducing the chanceof medical error

2.2 Kategorien von Integrationsanforderungen”Presentation integration implies that data from various applications are presented to the user in anadequ

3 Informationssystemar chitekturen — Ei ne Einf¨uhrung3.1 Vorbemerkungen”Ar|chi|tek|tur die; -, -en (aus gleichbed. lat. architectura): 1. a) (ohne Pl

3 Informationssystemarchitekturen — Eine Einf¨uhrung3.2 Architektur: Kompon e n ten und ihre BeziehungenDas Reference Model for Open Distributed Proce

3.2 Architektur: Komponenten und ihre BeziehungenKasten 3.2: Ausz¨uge aus ISO/IEC 1074 6-2 (RM-ODP Foun d ations)”8 Basic modelling conceptsThe detail

Modellierung und Bewertung von Integration in Krankenhaus-informationssystemen Thomas Wendt

3 Informationssystemarchitekturen — Eine Einf¨uhrung”(. . . ) we find components, both primitive and composite; rules of composition that allow the con

3.3 Architekturstilea) b)c)Abbildung 3.1: Ein Komponententyp (a), ein Konnektorentyp (b) und eine Konfiguration (c) (Quelle [Abowd et al.1995], S. 329-

3 Informationssystemarchitekturen — Eine Einf¨uhrungKasten 3.3: Grundbegriffe (4 )Definitionen f¨ur ModellDefinition aus [Sch¨utte 1998]”Grunds¨atze ordn

3.3 Architekturstile– Komponententypen, die die aktiven Einheiten eines Systems b eschreib en und f¨ur dieInteraktion mit an deren Komponenten Schnitt

3 Informationssystemarchitekturen — Eine Einf¨uhrungPipes und Fi lter Objekt-orientier-te OrganisationEreignisbasierte,implizite AufrufeGeschichtete S

3.4 Architekturstile f¨ur Informationssysteme — Metamod elle un d ReferenzmodelleKasten 3.4: Grundbegriffe (5): Modelle und ReferenzmodelleDefinition un

3 Informationssystemarchitekturen — Eine Einf¨uhrung3.4.3 Bestimmung von ArchitekturstilenIn [Abowd et al. 1995] wird f¨ur jeden der vorgestellten Arc

4 Standar ds f¨ur Informationssystemarchitekturen4.1 Orientierung durch RahmenwerkeRahmenwerke f¨ur Informationssystemarchitekturengeben Orientierungs

4 Standards f¨ur InformationssystemarchitekturenAuch Architektur-Referenzmodelle sind wesentlicher Bestandteil mancher Rahmenwerke,z. B. der Object Ma

4.2 Technische Rahmenwerke f¨ur InformationssystemarchitekturenISO/IEC 7498-1 bis -4: Information technology — Open Systems Interconnection — Basic Re

4 Standards f¨ur Informationssystemarchitekturena) b)Abbildung 4.2:¨Ubersichtsgrafik zum generischen Schichtenkonzept (a) und Kommunikation von Einheit

4.2 Technische Rahmenwerke f¨ur InformationssystemarchitekturenStandard Code for Information Interchange (ASCII) und seine Erweiterungen (z. B. [ISO J

4 Standards f¨ur InformationssystemarchitekturenKasten 4.1:¨Uberblick¨uber ISO-Standards zum RM-ODPISO/IEC 10746-1: Overview gibt einen¨Uberblick¨uber

4.2 Technische Rahmenwerke f¨ur InformationssystemarchitekturenKasten 4.2:¨Uberblick¨uber ISO-Standards zum RM-ODP (Fortsetzung)ISO/IEC 10 746-3: Arch

4 Standards f¨ur Informationssystemarchitekturendie Mechanismen und Funktionen f¨ur eine verteilte Interaktion zwischen Objekten imSystem in den Mitte

4.2 Technische Rahmenwerke f¨ur InformationssystemarchitekturenKasten 4.3: Erg¨anzende Standards zum RM-ODP: Spezifikation der inISO/IEC 10746-3 vorges

4 Standards f¨ur Informationssystemarchitekturen4.2.3 Die Object Management ArchitectureInnerhalb der zur¨uck liegenden etwa zehn J ahre3hat sich die

4.2 Technische Rahmenwerke f¨ur Informationssystemarchitekturen Abbildung 4.4: Das Object Management Architecture Reference Model (Quelle: [OMG 1997],

4 Standards f¨ur Informationssystemarchitekturente 4.1.5-4.1.7, S. 4-3 - 4-4):Objektdienste ( object services) sind Schnittstellen f¨ur allgemeine Die

4.2 Technische Rahmenwerke f¨ur InformationssystemarchitekturenMDA-Sichtweisen RM-ODP-Sichtweisenrechnerunabh¨angige Sichtweise Unternehmenssichtweise

F¨ur Kathrin und Lukas

4 Standards f¨ur Informationssystemarchitekturena) b) ist das Plattform-Symbol im MDA-KontextAbbildung 4.5: Das Model Driven Architecture Pattern (a)

4.2 Technische Rahmenwerke f¨ur InformationssystemarchitekturenKasten 4.4:¨Uberblick¨uber OMG-Standards zur ArchitekturentwicklungDie Object Managemen

4 Standards f¨ur InformationssystemarchitekturenIntegrationsanforderungen und die OMADie OMA wurde, wie das RM-ODP, f¨ur den Entwurf verteilter Inform

4.2 Technische Rahmenwerke f¨ur Informationssystemarchitekturen Abbildung 4.6: Die Schichten der Architektur von Informationssystemen im Gesundheitswe

4 Standards f¨ur Informationssystemarchitekturena)b)Abbildung 4.7: Informationsmodell f¨ur die Subject of Care Healthcare Common Services (a) und funk

4.2 Technische Rahmenwerke f¨ur Informationssystemarchitekturenin der HISA spezifizierten Dienstgrupp en beschreiben Informationen und zugeh¨orige Funk

4 Standards f¨ur InformationssystemarchitekturenDie TOGAF Architecture Development MethodDie TOGAF Architecture Development Method (TOGAF ADM) ist ein

4.2 Technische Rahmenwerke f¨ur InformationssystemarchitekturenAbbildung 4.9: Die Phasen der TOGAF Architecture Development Method und die Schritte de

4 Standards f¨ur Informationssystemarchitekturena) b)Abbildung 4.10: Einfache (a) und detailli ertere (b) Grafik zum TOGAF TRM (Quellen: [The Open Grou

4.3 Weitere Standards f¨ur IntegrationstechnikenIntegrationsanforderungen und TOGAFTOGAF wurde entwickelt, um Projekte zur Entwicklung bzw. Weiterentw

4 Standards f¨ur Informationssystemarchitekturen[CCOW 2000b]). Zur Standard-Reihe geh¨oren außerdem Standards zur Umsetzung der Kon-textsynchronisieru

4.4 Unternehmensbezogene Rahmenwerke f¨ur InformationssystemarchitekturenAbbildung 4.11: Das Zachman-Rahmenwerk f¨ur Informationssystemarchitektur (Qu

4 Standards f¨ur Informationssystemarchitekturentekturen. Es ist wesentliche Grundlage f¨ur die Entwicklung einer Reihe von US-amerikanischenRahmenwer

4.4 Unternehmensbezogene Rahmenwerke f¨ur InformationssystemarchitekturenAbbildung 4.12: Das ARIS-Haus (Quelle: [Scheer 1998b], S. 46, Abbildung 20)–

4 Standards f¨ur InformationssystemarchitekturenKasten 4.5: Beispiele f¨ur Methoden zur Datensicht un d zur Steuerungssichtder ARISHinweis: Die Beispi

4.4 Unternehmensbezogene Rahmenwerke f¨ur InformationssystemarchitekturenAbbildung 4.14: Das ARIS-Phasenmodell (Quelle: [Scheer 1998b], S. 39, Abbildu

4 Standards f¨ur Informationssystemarchitekturen4.4.3 Enterprise Application IntegrationUnter dem Titel Enterprise Application Integration (EA I) wurd

4.4 Unternehmensbezogene Rahmenwerke f¨ur Informationssystemarchitekturen c) Business-to-Customer Integration Business-to-Business Integration App

4 Standards f¨ur Informationssystemarchitekturendiese Komponenten sind Enterprise Java Beans (EJB) oder das Component Object Mo-del (COM/COM+). F¨ur d

4.4 Unternehmensbezogene Rahmenwerke f¨ur InformationssystemarchitekturenAbbildung 4.17: Einfaches A rchitektur-Referenzmodell f¨ur EAI (Quelle: [Schm

DanksagungDie vorliegende Arbeit wurde am Institut f¨ur Medizinische Informatik, S tatistik und Epide-miologie der Universit¨at Leipzig angefertigt. S

4 Standards f¨ur Informationssystemarchitekturena)b)c)d)e)Abbildung 4.18: EAI-Architekturmuster (Quelle: [Lutz 2000])Ein Vorgehens-Referenzmodell f¨ur

4.4 Unternehmensbezogene Rahmenwerke f¨ur Informationssystemarchitekturen4.4.4 The Open Group Architectural Framework, Version 8The Open Group Archite

4 Standards f¨ur Informationssystemarchitekturena)b)Abbildung 4.20: Architekturkontinuum (a) und L¨osungskontinuum (b) in TOGAF, Version 8 (Quelle: [T

4.4 Unternehmensbezogene Rahmenwerke f¨ur Informationssystemarchitekturena) b)c) d)Abbildung 4.21: TOGAF TRM in TOGAF, Version 8, (a und b) und Ableit

4 Standards f¨ur Informationssystemarchitekturenbildung 4.20a). Im TOGAF s elbst werden auch eine grundlegende Architektur, die TOGAFFoundation Archit

4.4 Unternehmensbezogene Rahmenwerke f¨ur InformationssystemarchitekturenAbbildung 4.22: Phasen des Enterprise A rchitecture Planning (Quelle: [Spewak

4 Standards f¨ur InformationssystemarchitekturenKasten 4.6: Schritte der EAP-Phasen und Beispiele f¨ur zugeh¨origeGegenst¨ande, erwartete Erge b n iss

4.4 Unternehmensbezogene Rahmenwerke f¨ur InformationssystemarchitekturenKasten 4.7: Schritte der EAP-Phasen und Beispiele f¨ur zugeh¨origeGegenst¨and

4 Standards f¨ur InformationssystemarchitekturenKasten 4.8: Schritte der EAP-Phasen und Beispiele f¨ur zugeh¨origeGegenst¨ande, erwartete Erge b n iss

4.6 Vergleichbarkeit von Architekturstandardsgruppen der HISA k¨onnen beispielsweise prinzipiell durch die von der OMG spezifiziertenDienste f¨ur den A