Entwicklung eines computergestützten „Critical Incident ... - Risikous

HOCHSCHULE ZITTAU/GÖRLITZ (FH)
FACHBEREICH INFORMATIK
Entwicklung eines computergestützten
„Critical Incident Reporting System“ für das
Klinikum Görlitz
Diplomarbeit
zur Erlangung des Grades eines Diplom-Informatikers (FH)
des Studienganges Allgemeine Informatik
der Hochschule Zittau/Görlitz (FH)
vorgelegt von:
Lars Rönisch
geboren am 24. August 1978 in Görlitz.
Stephan Schnabel
geboren am 09. Mai 1984 in Görlitz.
Referent:
Prof. Dr. rer. nat. Christian Wagenknecht
Görlitz, 14.10.2007

Danksagung
An dieser Stelle bedanken wir uns bei den Menschen, die uns bei der Erstellung
der Diplomarbeit in vielfältiger Weise unterstützt haben. Bei Herrn Prof. Dr. rer.
nat. Christian Wagenknecht bedanken wir uns für die angenehme Betreuung der
Arbeit und für die konstruktiven Vorschläge während der Umsetzung.
Wir danken allen Mitgliedern der Projektgruppe CIRS des Klinikum Görlitz für
ihre tatkräftige Unterstützung bei der Entwicklung des Softwaresystems. Bei
Herrn Prof. Dr. med. habil. Ekkehart Paditz, Geschäftsführer des Klinikum Görlitz,
bedanken wir uns für die gute Zusammenarbeit. Frau Ursula Reiche und
Herrn Alexander Goertchen danken wir für die angenehmen und konstruktiven
Gespräche und für die Bereitstellung von Unterlagen zum Thema Qualitäts- und
Risikomanagement im klinischen Bereich.
Dank gilt der Firma Protec aus Würzburg, die den Meldebogen für das System
zur Verfügung stellte und eine Forschungskooperation mit der Hochschule Zittau/Görlitz
eingegangen ist.
Herzlicher Dank gebührt allen Studenten, die mit Ideen und Kritiken zu diesem
Projekt beigetragen haben. Auch unseren Kommilitonen Fabian Schlegel,
Richard Krüger und Timotheus Israel danken wir für ihre Verbesserungsvorschläge
während der Implementierung.
Lars Rönisch dankt
Dank gebührt meinen Eltern, die mir dieses Studium durch ihre Unterstützung
in jeglicher Hinsicht ermöglicht haben.
Meiner Lebensgefährtin Manuela Schmidt danke ich ganz besonders für ihr Verständnis
und ihre Geduld, gerade im letzten Abschnitt meines Studiums.
Stephan Schnabel dankt
Ich danke meinen Eltern, die mir das Studium der Informatik ermöglicht haben.

Ein besonderer Dank gilt Henry Talke, für die Unterstützung während meines
Studiums.

Inhaltsverzeichnis
1 Einleitung 12
1.1 Problembeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2 Zielsetzung und Vorgehensweise . . . . . . . . . . . . . . . . . . . . . 12
1.3 Begriffsdefinitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2 Risikomanagement 16
2.1 Klinisches Risikomanagement . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Risikomanagement-Prozess . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Fehler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.1 Fehlerquelle „Mensch“ . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.2 Fehlermeldesysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3 Entwicklung CIRS für das Klinikum GR 28
3.1 Ausgangssituation im Klinikum GR . . . . . . . . . . . . . . . . . . . 28
3.2 Entwicklungsziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.1 CIRS Szenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.2 funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3.3 nichtfunktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . 34
3.3.4 Akteure und Rechte im System . . . . . . . . . . . . . . . . . . . . . . 35
3.3.5 Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.6 Entwicklung der Benutzungsoberfläche . . . . . . . . . . . . . . . . . 39
3.4 Softwaredesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.4.1 Basis-Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.4.2 CIRS-Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4 Auswahl geeigneter Mittel 48
4.1 Client-Server-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2 Webanwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3 Webanwendungen mit Java . . . . . . . . . . . . . . . . . . . . . . . . 50
4.4 Vegleich von Webframeworks für das CIRS . . . . . . . . . . . . . . . 52
4.4.1 Apache Struts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.4.2 Apache Struts2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.4.3 Spring Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.4.4 Apache Cocoon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.4.5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5 Implementierung 63
5.1 Architektur und Komponenten . . . . . . . . . . . . . . . . . . . . . . 63
5.2 Persistierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.3 Meldebogenrepräsentation . . . . . . . . . . . . . . . . . . . . . . . . 66
5.3.1 Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.3.2 XML-Schema des Meldebogens . . . . . . . . . . . . . . . . . . . . . . 69
5.4 Benutzungsoberfläche - Ergonomie . . . . . . . . . . . . . . . . . . . 69
5.5 Internationalisierung des CIRS . . . . . . . . . . . . . . . . . . . . . . 72
5.6 Erzeugen von PDF-Dateien . . . . . . . . . . . . . . . . . . . . . . . . 73
6 Einsatzerprobung 76
7 Ergebnisse und Ausblick 78
7.1 Vorstellung ausgewählter Resultate . . . . . . . . . . . . . . . . . . . 78
7.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
A Funktionsweise der Webframeworks 84
A.1 Apache Struts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

A.2 Apache Struts2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
A.3 Spring-MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
A.4 Apache Cocoon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
B Zusätzliche Quellcodebeispiele 94
B.1 XML-Meldebogen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
B.2 Benutzungsoberfläche - Ergonomie . . . . . . . . . . . . . . . . . . . 97
B.3 PDF erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
C Dokumentationen 107
C.1 Entwicklungsdokumentation . . . . . . . . . . . . . . . . . . . . . . . 107
C.2 Benutzungsdokumentation . . . . . . . . . . . . . . . . . . . . . . . . 108
C.3 Installationsdokumentation . . . . . . . . . . . . . . . . . . . . . . . . 109
D Datenträgerbeschreibung 110
Literaturverzeichnis 112

Abbildungsverzeichnis
2.1 Risiko etymologisch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Risikomanagement-Prozess . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Risikomatrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4 Tabelle 2 Berliner Ärzte Nov. 2001 . . . . . . . . . . . . . . . . . . . . . 24
3.1 QM-Organigramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2 Integration von Risikous im Klinikum . . . . . . . . . . . . . . . . . . 33
3.3 Use Case Risikous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4 Use Case Risikomanagement . . . . . . . . . . . . . . . . . . . . . . . . 38
3.5 GUI-Mockup Meldebogen . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.6 GUI-Mockup MessageReader . . . . . . . . . . . . . . . . . . . . . . . 41
3.7 Softwaredesign – Meldebogen . . . . . . . . . . . . . . . . . . . . . . . 43
4.1 Client-Server Kommunikation . . . . . . . . . . . . . . . . . . . . . . . 49
4.2 Drei-Tier-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3 Übersicht Spring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.1 Risikous Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.2 Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.3 Erzeugen von PDF-Dateien . . . . . . . . . . . . . . . . . . . . . . . . . 74
7.1 Benutzungsoberfläche Mitarbeiter . . . . . . . . . . . . . . . . . . . . . 79
7.2 MessageReader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.3 MessageReader Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . 81

7.4 Auswertung PDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
A.1 Systemaufbau Struts1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
A.2 Systemaufbau Struts2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
A.3 Bearbeitung eines Request . . . . . . . . . . . . . . . . . . . . . . . . . 90
A.4 Pipeline-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
B.1 Grafische Darstellung des XML-Schemas . . . . . . . . . . . . . . . . . 97

Quellcodeverzeichnis
5.1 XML Meldebogen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.2 Ausschnitt aus der Period JSP . . . . . . . . . . . . . . . . . . . . . . . 70
5.3 Login – Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.4 package.properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
B.1 XML-Schema des Meldebogens . . . . . . . . . . . . . . . . . . . . . . 94
B.2 Layout JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
B.3 Tiles Konfigurationsfile . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
B.4 createQuestionnaire() . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
B.5 createPdf() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Abkürzungsverzeichnis
ALARP . . . . . . .
API . . . . . . . . . . .
CIRS . . . . . . . . . .
CSS . . . . . . . . . . .
DAO . . . . . . . . . .
DB . . . . . . . . . . . .
DTD . . . . . . . . . .
DTO . . . . . . . . . .
ERS . . . . . . . . . . .
FOP . . . . . . . . . . .
gGmbH . . . . . . .
GmbH . . . . . . . .
GR . . . . . . . . . . . .
GUI . . . . . . . . . . .
HQL . . . . . . . . . .
HTML . . . . . . . .
HTTP . . . . . . . . .
IRS . . . . . . . . . . .
JSP . . . . . . . . . . . .
MVC . . . . . . . . . .
As Low As Reasonably Practicable
Application Programming Interface
Critical Incident Reporting System
Cascading Style Sheet
Data Access Object
Datenbank
Document Type Definition
Data Transfer Object
Error Reporting System
Formatting Objects Processor
gemeinnützige Gesellschaft mit begrenzter Haftung
Gesellschaft mit begrenzter Haftung
Görlitz
Graphical User Interface
Hibernate Query Language
HyperText Markup Language
HyperText Transfer Protocol
Incident Reporting System
JavaServer Pages
Model View Controll

OGNL . . . . . . . . Object Graph Navigation Language
OP . . . . . . . . . . . . Operationssaal
ORM . . . . . . . . . Object Relational Mapping
PDF . . . . . . . . . . . Portable Document Format
POJO . . . . . . . . . Plain Old Java Object
PS . . . . . . . . . . . . PostScript
QM . . . . . . . . . . . Qualitätsmanagement
RM . . . . . . . . . . . Risikomanagement
SVG . . . . . . . . . . Scalable Vector Graphics
UML . . . . . . . . . . Unified Modeling Language
URL . . . . . . . . . . Uniform Resource Locator
W3C . . . . . . . . . . World Wide Web Consortium
WYSIWYG . . . . What You See Is What You Get
XML . . . . . . . . . . eXtensible Markup Language
XSL . . . . . . . . . . . eXtensible Stylesheet Language
XSL-FO . . . . . . . eXtensible Stylesheet Language Formatting Objects
XSLT . . . . . . . . . . eXtensible Stylesheet Language Transformation

- 12 -
1 Einleitung
1.1 Problembeschreibung
Critical Incident Reporting Systeme entwickeln sich in den letzten Jahren in
Deutschland und in Europa zu einem Thema, welches in den Krankenhäusern,
aber auch in den Versicherungsunternehmen große Aufmerksamkeit erfährt. Die
Praxis zeigt jedoch, dass bei Einführung, Umsetzung und Integration in das bestehende
Risikomanagement solcher Systeme oft große Hürden zu überwinden
sind. Computergestützte Systeme die den CIRS-Prozess abbilden und den Risikomanagementprozess
unterstützen bieten Möglichkeiten, um erfolgreich kritische
Ereignisse zu vermeiden, eine Fehlerkultur zu entwickeln und dabei die
Kosten überschaubar zu halten.
1.2 Zielsetzung und Vorgehensweise
Das Ziel dieser Arbeit soll es sein, ein computergestütztes CIRS für das Melden
von Beinahefehlern zu entwickeln. Dabei soll die Software auch den Risikomanagementprozess
im Klinikum Görlitz unterstützen, die Patientensicherheit erhöhen
und gleichzeitig Kosten einsparen. Um diese Ziele entsprechend effektiv
verwirklichen zu können, wurde ein Kooperationsvertrag zwischen Klinikum
Görlitz, der Firma Protec aus Würzburg und der Hochschule Zittau/Görlitz geschlossen.

- 13 -
Basis für die Entwicklung der Software sind die Grundbegriffe des Risikomanagements.
Hierzu werden in Kapitel 2 die Grundlagen des klinischen Risikomanagements
sowie die der Fehlermeldesysteme erläutert.
In Kapitel 3 wird ausgehend von der Struktur des Risikomanagements im Klinikum
Görlitz eine Anforderungsanalyse für das CIRS durchgeführt. Dazu wird
ein Szenario beschrieben, welches den zukünftigen Einsatz der Software im Klinikum
darstellt. Aufbauend darauf werden die Anforderungen an das Softwaresystem
formuliert und mit Anwendungsfällen und GUI-Mockups untermalt.
Vor der Implementierung des Softwaresystems ist die Auswahl geeigneter Mittel
für die softwaretechnische Umsetzung notwendig. Hierfür wurden verschiedene
Webframeworks anhand von praktischen Tests, in Form von Beispielanwendungen,
auf ihre Einsatztauglichkeit hin untersucht. In Kapitel 4 werden diese
Frameworks vorgestellt, miteinander verglichen und bewertet.
Die Umsetzung einzelner Problemstellungen wie beispielsweise die Repräsentation
des Meldebogens, das Erzeugen von PDF Dateien, die Internationalisierung
und die Persistierung werden in Kapitel 5 erläutert.
Die durchgeführten Einsatzerprobungen sowie das Result dieser werden im Kapitel
6 dargestellt.
Zum Abschluss der Arbeit werden einige ausgewählte praktische Ergebnisse
präsentiert und ein Ausblick zu möglichen Erweiterungen des Systems gegeben.
1.3 Begriffsdefinitionen
„Beinahefehler
Im englischen: Near miss, ein → F ehler, wobei das Abweichverhalten
rechtzeitig erkannt wird und so ein tatsächlicher Fehler vermie-

- 14 -
den wird. Als Beinahefehler gilt jedes Vorkommnis, das unerwünschte
Folgen hätte haben können, es im konkreten Fall jedoch nicht hatte
und abgesehen vom Ergebnis (Outcome) von einem richtigen unerwünschten
Ereignis nicht zu unterscheiden war. Beinahefehler erinnern
uns wirksam an Systemrisiken und verhindern, dass die Angst
vor Fehlern allzu schnell in Vergessenheit gerät.“ 1)
„CIRS
Zwischenfallerfassung (Incident Reporting/Monitoring) ist die Meldung
von Beinahefehlern (→ Zwischenfall → Beinahefehler) bzw.
von kritischen Beinahefehlern/Ereignissen. Je mehr Zwischenfälle erfasst
werden, desto größer ist die Chance, Schwachstellen im System
zuerkennen und durch geeignete Maßnahmen zu eliminieren. Werden
Beinahefehler reduziert, entstehen weniger echte Fehler.“ 2)
„Fehlerkultur
Beschreibt einen gewandelten Umgang mit Fehlern von einer oberflächlichen,
reaktiven Kultur der Schuldzuweisung (Culture of Blame),
hin zu einer systemanalytischen, proaktiven Sicherheitskultur
(Safety Culture) mit vorurteilsfreiem Umgang mit Fehlern. Es mag
in der Natur des Menschen liegen Fehler zu machen, aber es liegt
ebenso in der Natur des Menschen Lösungen zu entwickeln, bessere
Alternativen zu finden und sich den Herausforderungen der Zukunft
zu stellen.“ 3)
„Kritisches Ereignis
Ein Ereignis, das mit einem Schädigungspotential einhergeht, das eintreten
wird, wenn nicht gegengesteuert wird.“ 4)
„Patientensicherheit
Patientensicherheit ist das Produkt aller Maßnahmen in Klinik und
Praxis, die darauf gerichtet sind, Patienten vor vermeidbaren Schäden
in Zusammenhang mit der Heilbehandlung zu bewahren.“ 5)
1) [AZfQidM05], Seite 4
2) [AZfQidM05], Seite 4
3) [AZfQidM05], Seite 4
4) [AZfQidM05], Seite 7
5) [AZfQidM05], Seite 8

- 15 -
„Schaden (vermeidbarer)
Eine Schädigung, die bei Einhaltung der notwendigen Sorgfaltspflicht
nicht eingetreten wäre.“ 6)
„Unerwünschte Ereignisse
Vorkommnisse bzw. Ereignisse, die möglicherweise aber nicht zwangsläufig
zu einem konsekutiven Schaden für den Patienten führen
(engl. „adverse events“).“ 7)
„Zwischenfall
Ein Ereignis (Incident) im Rahmen einer Heilbehandlung, welches zu
einer unbeabsichtigten und /oder unnötigen Schädigung einer Person
oder zu einem Verlust hätte führen können oder geführt hat.“ 8)
6) [AZfQidM05], Seite 8
7) [AZfQidM05], Seite 9
8) [AZfQidM05], Seite 10

- 16 -
2 Risikomanagement
Bevor die Frage beantworten werden kann, was sich hinter Risikomanagement
verbirgt, muss der Begriff Risiko verstanden sein.
Die Begrifflichkeit Risiko erhält in der Literatur verschiedene Auffassungen.
Die Literatur bezeichnet Risiko im allgemeinen als Wagnis, Gefahr. Wirtschaftlich
als Verlustgefahren, Unsicherheits- und Zufälligkeitsfaktoren, die mit jeder
wirtschaftlichen Tätigkeit verbunden sind. 1) Mathematisch als „Risiko = Wahrscheinlichkeit
x Schadensausmaß [R=WxS]“ 2) .
Eine allgemeine Definition wurde auf der Webseite www.risknet.de gefunden.
„Die Möglichkeit eines Schadens oder Verlustes als Konsequenz eines
bestimmten Verhaltens oder Geschehens; dies bezieht sich auf
Gefahrensituationen, in denen nachteilige Folgen eintreten können,
aber nicht müssen. Ethymologisch kann man Risiko zum einen auf riza
(griechisch = Wurzel, Basis) zurückverfolgen; siehe auch risc (arabisch
= Schicksal). Auf der anderen Seite kann Risiko auf ris(i)co
(italienisch) zurückverfolgt werden, die Klippe, die es zu umschiffen
gilt.“ 3)
1) Vgl.[LO]
2) Vgl.[KW05], Seite 13
3) [Ris], Risknet.de

- 17 -
Abbildung 2.1: Risiko etymologisch
Bezieht man sich auf die allgemeine Definition, kann gesagt werden, dass sich
das Risikomanagement mit der Analyse, Bewertung, Verhinderung, Beherrschung
und Folgen von Risiken befasst.
2.1 Klinisches Risikomanagement
Das klinische Risikomanagement stellt ein Präventionssystem dar. Durch den
Einsatz von Präventionssystemen sollen Risiken bei der Patientenversorgung reduziert
werden und letztlich auch der Abwehr ungerechtfertigter Anspruchstellungen
seitens der Patienten gegenüber dem Klinikum dienen. Klinisches Risikomanagement
ist kein theoretisches System, sondern viel mehr ein praktisches
Werkzeug zur Prozessanalyse und Prozesssteuerung im Behandlungsumfeld. So
hat es auch zum Ziel, das Risikobewusstsein aller Mitarbeitern zu fördern und

- 18 -
diese für mögliche Gefahrenherde zu sensibilisieren. An dieser Stelle muss gesagt
werden, das Risikomanagement alle Mitarbeiter im System Krankenhaus
betrifft und auf deren Mitarbeit angewiesen ist. Nur so kann eine effektive Fehlerkultur
im Klinikbereich erreicht werden, um eine maximale Patientensicherheit
zu erzielen.
2.2 Risikomanagement-Prozess
Die Basis des Risikomanagements bildet der Risikomanagement-Prozess. Abbildung
2.2 zeigt die einzelnen Phasen des Prozesses.
Ausgehend von der festgelegten Strategie werden in den ersten Phasen des Risikoprozesses
die Risiken identifiziert, erfasst und bewertet. Im Rahmen der Risikobewältigung
erfolgt die Einleitung von Maßnahmen zur Steuerung der Risiken.
Die Wirksamkeit der eingeleiteten Maßnahmen wird im Prozessschritt Risiken
überwachen beurteilt.

- 19 -
Abbildung 2.2: Risikomanagement-Prozess

- 20 -
Risikostrategie
Die Klinikleitung legt die Risikostrategie fest und schafft die Rahmenbedingungen
für das gesamte Risikomanagement im Klinikum. Die Riskostrategie soll
dazu beitragen, die unternehmensspezifischen Ziele zu erreichen und umfasst
alle risikopolitischen Grundsätze der Organisation.
Risiken identifizieren
Dieser Schritt im Risikomangement-Prozess dient dem Finden von Risiken und
Risikoursachen mit anschließender Erstellung einer Bestandsliste. Hierbei sollen
Schwachstellen systematisch erfasst werden. Der Prozess ist stark abhängig vom
Risikobewusstsein und von der Motivation der Mitarbeiter.
Risiken erfassen
Der Prozess Risiken erfassen ist ein systematischer Vorgang zur Ursachensuche.
Dabei werden die Risiken in Teilrisiken zerlegt, um Ursachen-Wirkungs-
Beziehungen zu finden.
Risiken bewerten
Um Risiken bewerten zu können, nutzt die Risikobewertung zwei Größen. Die
Eintrittswahrscheinlichkeit und die Schadenshöhe. Resultierend aus den beiden
Größen kann das Ergebnis in die Risikomatrix eingetragen werden. Die Risikomatrix
gibt Aufschluss über den Handlungsbedarf. Die folgende Abbildung
verdeutlicht dies.

- 21 -
Abbildung 2.3: Risikomatrix
Der gelb markierte Bereich ist der sogenannte ALARP-Bereich. Die Risiken, die
sich in diesem Bereich befinden, sollen auf ein vernünftiges und durchführbares
Maß minimiert werden. Befindet sich beispielsweise ein Risiko in diesem Bereich,
sollte zunächst abgeschätzt werden, welche Kosten bei Eintritt dieses Risikos
entstehen. Sind die Kosten für die Minimierung des Risikos höher als die
Kosten bei Eintritt des Risikos, so kann das Risiko als tolerierbar eingeschätzt
werden, da hier weitere Maßnahmen nicht praktikabel wären.

- 22 -
Risiken steuern
Risiken steuern ist der Teil im Prozess, der darüber entscheidet, auf welche Weise
die Organisation mit den erfassten und bewerteten Risiken umgeht. Die folgende
Aufzählung bietet fünf Möglichkeiten an mit Risiken umzugehen.
• Risikovermeidung
• Risikoverminderung
• Risikoteilung
• Risikoübertragung
• Risikoselbsttragung
Risiken überwachen
Risiken überwachen dient der kontinuierlichen Kontrolle des gesamten Risikoprozesses
und seiner Wirksamkeit. In diesem Prozess sollen folgende Fragen beantwortet
werden:
• “Wurden im Vorfeld alle Risiken identifiziert? Sind neue Risiken
hinzugekommen? Sind Risiken entfallen?
• Ist die Bewertung der Risiken noch zutreffend?
• Wurden die Risiken in ihrem potenziellen Schadensausmaß zu
gering/zu hoch eingeschätzt?
• Konnten die Maßnahmen zur Risikovermeidung umgesetzt werden,
haben diese den erwünschten Erfolg ergeben?
• Ist die Versicherungsdeckung korrekt? (Ist es günstiger mehr
oder weniger Schäden selbst zu tragen? Muss eine höhere Schadensdeckung
erfolgen?)“ 4)
4) [KW05], Seite 55

- 23 -
2.3 Fehler
Im klinischen Umfeld wird ein Fehler wie folgt definiert:
„Ein richtiges Vorhaben wird nicht wie geplant durchgeführt, oder
dem Geschehen liegt ein falscher Plan zugrunde. Beispiele: diagnosebezogene
oder arzneimittelbezogene Fehler.“ 5)
2.3.1 Fehlerquelle „Mensch“
Die Fehlerforschung der NASA in der Luftfahrt hat herausgefunden, dass 70%
der Flugunfälle auf menschlichem Fehlverhalten beruhen.
„Das Fehler passieren, ist unvermeidlich. So beträgt zum Beispiel
die allgemeine Fehlerrate bei einer banalen Tätigkeit, etwa beim Ablesen
von Instrumenten, bereits drei Promille. Komplexer wird die
Situation beispielsweise bei miteinander agierenden Personengruppen
verschiedener Qualifikation, die entsprechende Geräteüberprüfungen
vornehmen sollen. Hier beträgt die Fehlerquote, wenn keine
schriftlichen Anweisungen Entsprechendes festlegen, bis zu 10
%. Die allgemeine Fehlerrate bei Aktivitäten mit hohem Stresslevel,
wenn gefährliche Ereignisse schnell aufeinander folgen, beträgt sogar
bis zu 25 %. Wie schwer es dabei ist, „fehlerfrei“ bzw. auf dem viel
zitierten 99 % Sicherheitsniveau zu arbeiten, sollen folgende Ausführungen
kurz darstellen.
Grundsätzlich gilt: Die Gesamtleistung eines Teams ist gleich dem
Produkt aller Einzelleistungen. Dies verdeutlicht Tabelle 2, modifiziert
nach Nolan und Park: Wenn 1 einem Niveau von 100 % entspricht,
so ist zum Beispiel nach 50 Einzelschritten (oder bei 50 miteinander
agierenden Personen) das Gesamtniveau auf 95 % gesunken.
“
5) [AZfQidM05], Seite 4

- 24 -
Abbildung 2.4: Tabelle 2 Berliner Ärzte Nov. 2001
„Übertragen auf das tägliche Leben bedeutet dies nichts anderes als
folgendes:“
• „Je mehr Menschen miteinander, selbst auf höchstem Sicherheitsniveau
agieren, desto wahrscheinlicher wird es, dass ein Fehler
geschieht.“
• „Je mehr Arbeitsschritte bzw. Verrichtungen (am Patienten) geschehen,
desto wahrscheinlicher wird es, dass ein Fehler passiert.“
6)
Der Mensch als Risikofaktor ist im Bereich der Luftfahrt als natürlicher Teil des
Systems identifiziert. Betrachtet man sich ein Flugzeugcockpit mit Piloten, wird
man leicht Parallelen zu einem Operationssaal feststellen können. Teamarbeit
ist nicht nur im Cockpit gängiger Alltag, sondern auch im OP. Diese Tatsache
zeigt, dass die Erkenntnisse aus der Luftfahrt auch eine Bedeutung für die Medizin
haben. Das Menschen Fehler machen, ist unvermeidlich und bedingt durch
physiologische und psychologische Grenzen des Menschen. Fehlermeldesysteme
stellen eine Möglichkeit dar, Fehler und Beinahefehler im Medizinbereich zu
identifizieren.
6) [Tho01]

- 25 -
2.3.2 Fehlermeldesysteme
Die wichtigste Komponente im klinischen Risikomanagement nehmen die Fehlermeldesysteme
ein. Sie stellen die Kommunikation zwischen Mitarbeiter und
dem Risikomangement her. Wobei der Mitarbeiter die Funktion des Meldenden
besitzt und das Risikomanagement die Funktion des Auswertenden besitzt.
Durch diesen Aufbau bietet das System eine hervorragende Möglichkeit Fehler
zu entdecken. Meldesysteme stellen daher die Basis, „aus Fehlern lernen“ zur
Verfügung. Entdeckt beispielsweise ein Mitarbeiter einen Fehler oder Beinahefehler,
kann er diesen im Meldesystem dokumentieren. Das verantwortliche Risikomanagement
erhält die Meldung und kann gezielt Maßnahmen ergreifen.
Ziele von Fehlermeldesystemen
Die Ziele von Fehlermeldesystemen unterscheiden sich nach dem entsprechenden
Anwendungskontext. Unterschieden wird zwischen zwei Fehlermeldesystemen,
dem „mandatory reporting system“ und dem „voluntary reporting systems“.
Das „mandatory reporting systems“ erfasst meist bestimmte, in der Regel
schwerwiegende Ereignisse, beispielsweise den Tod des Patienten. Bei diesem
System liegt das primäre Ziel in der Bestrafung oder im Verhängen von Sanktionen
für fehlerhafte Handlungen. Der Einsatz solcher Systeme wird meist behördlich
angeordnet und beruht damit nicht auf Freiwilligkeit. In einigen Bundesstaaten
der USA existiert diese Form des Fehlermeldesystems.
Das „voluntary reporting systems“ basiert auf Freiwilligkeit und verfolgt als primäres
Ziel die Patientensicherheit. In der Regel werden durch solche Systeme
Beinahefehler oder Fehler, die zu keiner schwerwiegenden Schädigung des Patienten
geführt haben, erfasst. Durch die Auswertung der erfassten Meldungen
sollen Schwachstellen im System erkannt und Maßnahmen zu dessen Beseitigung
ermöglicht werden.

- 26 -
Damit wird deutlich, dass zwei unterschiedliche Formen von Fehlermeldesystemen
existieren.
Error Reporting Systeme
Das Error Reporting dient zur Erfassung von Fehlern, die zu einem nicht gewünschtem
Ergebnis führen.
Critical Incident Reporting (CIRS) / Incident Reporting (IRS)-Systeme
Diese Systeme dienen zur Erfassung von Beinahefehlern oder Fehlervorstufen.
Das primäre Ziel ist die Erfassung von kritischen Zwischenfällen zum kontrollierten
Gegensteuern, um Fehler zu vermeiden. Dabei bieten solche Systeme die
Möglichkeit durch das Sammeln von Zwischenfällen Muster zu erkennen, die
immer wieder zu kritischen Zwischenfällen hinleiten. Durch das Erkennen von
Mustern können gezielt Gegenmaßnahmen eingeleitet werden. Es gilt, je mehr
Meldungen erfasst werden, desto größer ist die Wahrscheinlichkeit Schwachstellen
im System zu identifizieren. Der Vorteil von CIRS/IRS im Gegensatz zu
anderen Meldeystemen ist die größere Erfassung von Daten, da Beinahefehler
häufiger auftreten als mittelschwere oder schwere Fehler (Heinrichs Gesetz). 7)
Weiterhin spricht die fehlende Haftungsproblematik für das System, da bei Beinahefehlern
noch nichts passiert ist.
Eigenschaften von Fehlermeldesystemen
Fehlermeldesysteme bringen entsprechend ihres Einsatzgebietes verschiedene
Eigenschaften mit. So können Fehlermeldesysteme auf freiwilliger („voluntary“)
oder verpflichtender („mandatory“) Basis beruhen. Sie können Anonymität oder
7) Heinrichs Gesetz, wurde 1941 vom Ingenieur Heinrich erfunden und beschreibt den statistischen
Zusammenhang zwischen der Auftrittswahrscheinlichkeit von Beinaheunfällen, mittelschweren
Unfällen und einem Katastrophenfall. Das Heinrichs Gesetz sagt aus, dass auf
300 Beinaheunfälle, 29 mittelschwere Unfälle und schließlich eine Katastrophe kommen.

- 27 -
Vertraulichkeit gewährleisten. Bei anonym arbeitenden Systemen wird die Identität
des Meldenden gewahrt, wobei bei vertraulichen Systemen die Identität des
Meldenden bekannt ist, Dritten gegenüber aber verschwiegen bleibt. Dadurch
wird bei Bedarf die Kontaktaufnahme zum Meldenden vereinfacht oder aber
auch die Möglichkeit eines direkten Feedbacks seitens des Riskiomanagements
gewährleistet. Meldesysteme können bestrafend oder nichtbestrafend arbeiten.
Wobei ersteres eher eine Eigenschaft von Error Reporting Systemen ist. Dies ist
bedingt durch das Ziel des ERS. Zweiteres wird eher bei CIRS/IRS eingesetzt, da
Nichtbestrafung eine Voraussetzung für eine breite Beteiligung aller Mitarbeiter
darstellt.

- 28 -
3 Entwicklung CIRS für das
Klinikum GR
Das folgende Kapitel befasst sich mit der Entwicklung eines computergestützten
CIRS für das Klinikum Görlitz. Es beschreibt im ersten Teil die Ausgangssituation
im Städtischen Klinikum Görlitz. Anschließend werden die Anforderungen
an das Software-System, dessen Integration in das bestehende Risikomanagement
und ausgesuchte Anwendungsfälle erläutert.
3.1 Ausgangssituation im Klinikum GR
Das Städtische Klinikum Görlitz gGmbH wurde 1905 gegründet. Es stellt heute
einen zentralen Krankenhauskomplex mit 16 Kliniken, 2 Instituten und 2 Tochter
GmbHs zur Verfügung. Mit über 1000 Mitarbeitern ist das Klinikum einer der
größten Arbeitgeber der Region. Jährlich werden durchschnittlich 22000 stationäre
und 50000 ambulante Patienten behandelt. Das Städtische Klinikum Görlitz
trägt das international anerkannte Qualitätszertifikat der Joint Commission
International Accreditation (JCIA) aus den USA. Das Risikomanagement ist im
Klinikum Görlitz ein fester Bestandteil des Qualitätsmanagements und wird im
Qualitätshandbuch dokumentiert. Das Qualitätsmanagement beschäftigt sich
unter anderem mit der kontinuierlichen Überwachung, Analyse und Verbesserung
von klinischen und organisatorischen Verfahren. Es schafft klare Richtlini-

- 29 -
en für die Analyse und Überwachung von Prozessen. So auch für den Risikomanagementprozess
im Klinikum GR. Die Geschäftsführung legt dabei die Strategie
für die verschiedenen Prozesse fest. Ausgehend von der Strategie erfolgt im
Klinikum Görlitz die Analyse und Überwachung meist durch die verantwortlichen
Projektgruppen. Eine Projektgruppe besteht immer aus einem Projektgruppenleiter
und einer Anzahl von Spezialisten aus verschiedenen Bereichen.
Die Projektgruppen werden durch die Geschäftsführung, die Stabsstelle Qualitätsmanagement
sowie durch die Pflegedienstleitung kontrolliert und angeleitet.
Die Abbildung 3.1 zeigt die Struktur des Qualitätsmanagements in Form eines
Organigramms.
Um Daten für den Risikomanagementprozess verarbeiten zu können, müssen
diese entsprechend gesammelt werden. Zum Sammeln von Daten werden zum
größten Teil Papierfragebögen verwendet, die an den entsprechenden Stellen
ausgefüllt werden und später an die jeweilige Kontrollinstanz übergeben werden.
Diese wertet dann die Bögen 1) entsprechend aus und leitet, wenn nötig,
Maßnahmen ein oder ruft bei Bedarf die entsprechende Projektgruppe zusammen.
Im Rahmen der Risikoüberwachung werden in dem Bereich, wo die Maßnahmen
eingeleitet worden sind, nach einer Zeit Checklisten vom RM ausgegeben.
Diese müssen vom entsprechenden Abteilungsleiter ausgefüllt und an das
RM zurückgesendet werden. Diese Checklisten werden vom RM geprüft und
ausgewertet. Greifen Maßnahmen nicht, werden die Risiken wieder in den Risikomanagementprozess
gesteckt und neu bewertet.
1) Der Begriff „Bögen“ bezeichnet in dieser Arbeit alle Arten von „Meldebögen“, „Ereignisbögen“,
„Fragebögen“ und „Fehlerbögen“.

- 30 -
Abbildung 3.1: QM-Organigramm – Die dicke schwarze Linie zeigt den
Steuerfluss der QM-Prozesse, Geschäftsführung legt fest, Qualitätsmanagement
leitet ein und kontrolliert, Pflegedienstleitung, Qualitätsbeauftragter
Pflege kontrolliert und Projektgruppen führen durch.

- 31 -
3.2 Entwicklungsziele
Mit der Einführung von CIRS will die Klinikleitung nicht nur die Patientensicherheit
und damit die Qualität im Klinikum weiter steigern, sondern auch den
Bearbeitungsprozess der eingehenden CIRS-Meldungen beschleunigen und damit
den Risikomanagementprozess optimieren. Nachfolgend werden die Ziele
genannt, die aus Sicht der Projektmitglieder und der späteren Nutzer mit der
Entwicklung des computergestützten CIRS verfolgt werden. Dabei ist zu unterscheiden
zwischen den Zielen, die sich direkt auf die Mitarbeiter beziehen und
den Zielen, die sich auf das Qualitätsmanagement beziehen.
Ziele aus Sicht des Mitarbeiters
• Möglichkeit Beinahefehler schnell, anonym und ohne Umwege dem Risikomanagement
zu melden.
• Über die aktuelle Beinahefehler-Situation im Klinikum informiert zu sein.
Ziele aus Sicht des Qualitätsmanagements
• Computergestützt Daten über Beinahefehler zu erfassen und dadurch eine
Möglichkeit zu besitzen, Fehlern vorzubeugen.
• Computergestütze Verwaltung von Bögen.
• Unterstützung des Risikomanagementprozesses und damit Senkung von
Kosten. (Bsp. durch Vorabbewertung muss Projektgruppe nur bei Handlungsbedarf
einberufen werden)
• Durch einfache Benutzung der Meldebögen das Risikobewusstsein aller
Mitarbeitern zu fördern und diese für mögliche Gefahrenherde zu sensibilisieren.

- 32 -
• Senkung der Versicherungsprämien.
• Senkung der Papierkosten.
• Verkürzung der Informationswege (Meldung geht direkt an das Risikomanagement)
3.3 Anforderungen
Anforderungen sind ein Teil des Softwareentwicklungsprozesses und verfolgen
das Ziel, die vom Kunden an die zu entwickelnde Software gestellten Anforderungen
zu ermitteln. Im Folgenden werden die Anforderungen an die zu entwickelnde
Software kurz dargestellt und die Integration der Software in das bestehende
Risikomanagement gezeigt. Im weiteren Verlauf der Arbeit wird der
Begriff Risikous verwendet, er steht für das zu entwickelnde Softwaresystem.
3.3.1 CIRS Szenario
Um den Mitarbeitern einen Meldebogen über das Intranet computergestützt
zur Verfügung stellen zu können, muss dieser vom Risikomanager vorbereitet
und in Risikous eingegeben werden. Dazu muss die Software eine Möglichkeit
bieten, um Meldebögen aufnehmen und verarbeiten zu können. Anschließend
muss die Software den Meldebogen veröffentlichen und dem Mitarbeiter anonym
zur Verfügung stellen. Der Mitarbeiter kann über das Intranet eine Webseite
mit dem Meldebogen aufrufen und diesen ausfüllen. Risikous muss sicherstellen,
dass nur berechtigte Mitarbeiter Zugriff auf den Meldebogen haben. Die
Software muss alle ausgefüllten Meldebögen zentral sammeln und bei Bedarf
dem Risikomanagement zur Verfügung stellen. Dazu muss die Software dem Risikomanager
eine Funktion zum Lesen der ausgefüllten Meldebögen zur Verfügung
stellen. Erkennt der Risikomanager ein Risikopotential, muss die Software

- 33 -
eine Funktion mitbringen, um das Resultat aus Eintrittswahrscheinlichkeit und
Schadenshöhe grob bestimmen zu können. Ergibt sich nun Handlungsbedarf
ruft der Risikomanager die Projektgruppe zusammen. Die Projektgruppe untersucht
die Risiken und entscheidet über einzuleitende Maßnahmen. Um diese
Maßnahmen zu dokumentieren, muss die Software diese an die entsprechende
Meldung anhängen können. Um den Überblick über alle Meldungen zu behalten,
muss Risikous eine statistische Auswertung führen, die bei Knopfdruck
als PDF Datei ausgegeben werden kann. Diese Auswertungsdaten können im
Intranet veröffentlicht werden, damit alle Mitarbeiter über die Beinahefehlersituation
im Klinikum informiert sind. Die Geschäftsführung nutzt die Daten der
Auswertung zur Kontrolle der Risikostrategie. Abbildung 3.2 verdeutlicht die
Anforderungen an die Software und die Integration in das Risikomanagement.
Abbildung 3.2: Integration von Risikous in das Risikomanagement des
Klinikum Görlitz

- 34 -
3.3.2 funktionale Anforderungen
Das CIRS-Szenario hat einen ersten Einblick auf die Funktionalität der Software
gegeben. Dabei wurden im Szenario die Anforderungen mit den Wörtern muss,
kann und soll beschrieben. Sie geben Aufschluss darüber, was zwingende Anforderungen
sind und welche Anforderungen als optional betrachtet werden. Die
funktionalen Anforderungen beschreiben die konkreten Funktionen an die zu
entwickelnde Software.
Die Software soll Funktionen zum Verwalten von CIRS-Umfragen zur Verfügung
stellen:
• CIRS-Umfrage anlegen/editieren/ansehen (Vorschau)/veröffentlichen/
löschen
• CIRS-Umfrage muss Bogen aufnehmen/anzeigen
• CIRS-Umfrage muss Bogen dem Mitarbeiter zum Ausfüllen zur Verfügung
stellen und die Anonymität gewährleisten
• CIRS-Umfrage muss ausgefüllten Bogen verwalten
Darauf aufbauend sollen Funktionen zur Bewertung und Auswertung von eingegangenen
Meldungen (ausgefüllte Bögen) angeboten werden:
• Meldungen anzeigen/drucken/dokumentieren/löschen
• Risikomatrix zum Bewerten von Risiken (Bewertung)
• alle bewerteten Meldungen auswerten/anzeigen (statistische Auswertung)
3.3.3 nichtfunktionale Anforderungen
Weiterhin existieren nichtfunktionale Anforderungen an das Softwaresystem.
Sie legen fest, welche Eigenschaften das Softwareprodukt besitzen soll.

- 35 -
Benutzerfreundlichkeit
Die Software sollte intuitiv zu bedienen sein. Beim Ausfüllen eines Bogens muss
die Software dem Mitarbeiter einen Status über die verbleibende Befragung anzeigen.
(Statusbar)
Kennzeichnung von Pflichtfeldern
Pflichtfelder müssen in der Benutzungsoberfläche angezeigt sein.
Plausibilitätsprüfung
Fehlereingaben muss die Software dem Nutzer mitteilen.
Browserkompatibilität
Da im Klinikum der Standartbrowser der Mozilla Firefox ist, muss die Software
auf diesen Browser optimiert sein.
Plattformunabhängigkeit
Das Programm muss auf Linux- und Windows- Plattformen lauffähig sein.
Sicherheit
Um ausgefüllte Meldebögen gegen Missbrauch zu schützen, sind Zugriffskontrollen
in die Software zu integrieren.
3.3.4 Akteure und Rechte im System
Bei einem Softwaresystem, welches mehrere Nutzer bedienen soll, macht ein
Rollenmanagement Sinn. Es legt die Rechte der Nutzer im System fest und kontrolliert
diese. Dabei soll im computergestützten CIRS zwischen drei Akteuren 2)
unterschieden werden, den meldenden Mitarbeiter, den Risikomanager und den
Administrator. Der meldende Mitarbeiter soll nur das Recht besitzen, sich frei im
Meldebogen zu bewegen, ihn ausfüllen und ihn absenden zu können. Der Administrator
soll die Möglichkeit haben, neue Nutzer mit der Rolle Risikomanager
2) Nutzer werden in der Softwareentwicklung als Akteure bezeichnet. Dabei nimmt ein Akteur
eine entsprechende Rolle ein, ähnlich wie bei einer Theateraufführung.

- 36 -
anzulegen und diese mit entsprechenden Rechten zu versehen. Der Administrator
verfügt dazu standardmäßig über alle verfügbaren Rechte. Der Risikomanager
kann entsprechend seiner zugelassenen Rechte die Software nutzen. Die
Rechte, die im System vergeben werden sollen, sind in der folgenden Aufzählung
zu sehen.
• CIRS-Umfragen erstellen und bearbeiten
• Meldebogen lesen
• Meldebogen bewerten
• Auswertung erstellen
3.3.5 Anwendungsfälle
Anwendungsfälle werden in der Softwareentwicklung mit sogenannten Use Cases
modelliert. Das Use Case ist ein Diagramm aus der Unified Modeling Language
(UML) und soll das Verhalten aus der Sicht des Nutzers veranschaulichen,
der als Akteur an einem Anwendungsfall beteiligt ist.
Die folgenden Use Cases zeigen ausgesuchte Anwendungsfälle der Risikoussoftware.
Jeder einzelne der Anwendungsfälle kann in einem weiteren Use Case
verfeinert werden.
Die Abblidung 3.3 zeigt Anwendungsfälle der Risikoussoftware und dessen Akteure.
Bedingt durch das Rollenmanagement sind einige Anwendungsfälle nur
für bestimmte Akteure zugänglich. Risikomanagement ist der Anwendungsfall
der die Bewertung, die Auswertung und Funktionen rund um die CIRS-Umfrage
beinhaltet. Ereignis melden ist der Anwendungsfall, der die Ereignisse mit Hilfe
des Meldebogens entgegennimmt und diese nach dem Ausfüllen entsprechend
an das Risikomanagement weiterleitet. Das Use Case Benutzerverwaltung dient

- 37 -
Abbildung 3.3: Use Case Risikous
dem Administator, um neue Risikomanager im System anzulegen oder zu löschen,
beziehungsweise die Rechte des Nutzers entsprechend anzupassen. Der
Anwendungsfall User Einstellungen stellt dem Risikomanager Funktionen zum
ändern seines Nutzerprofils zur Verfügung.
Die Abbildung 3.4 zeigt den Anwendungsfall Risikomanagement. Er enthält alle
Anwendungsfälle, die im Risikomanagement enthalten sind. So haben die Akteure
die Möglichkeit, ein oder mehrere CIRS-Umfragen zu erstellen. Mehrere CIRS-
Umfragen machen dann Sinn, wenn in den einzelnen Kliniken verschiedene
Meldebögen verwendet werden oder wenn eine separate Auswertung erfolgen
soll. Das Reporting dient zur statistischen Auswertung aller eingegangenen bewerteten
Meldebögen. Der MessageReader stellt den primären Anwendungsfall
des Risikomanagers dar. In diesem Anwendungsfall hat der Manager die Möglichkeit,
eingegangene Meldebögen anzuschauen und diese zu bewerten. Auf-

- 38 -
Abbildung 3.4: Use Case Risikomanagement
bauend darauf kann er den Meldebogen inklusive Risikomatrix als PDF Datei
erstellen lassen. Im Anwendungsfall Meldebogen Vorschau stellt das System eine
Vorschau des Meldebogens zur Verfügung. Der Risikomanager kann den Meldebogen
voll durchspielen, ohne dass die Daten die er erzeugt, in eine Auswertung
einfließen. Sollte er einen Fehler feststellen, kann er diesen mit Hilfe des Anwendungsfalls
CIRS Umfrage bearbeiten beseitigen. Der Fall CIRS Umfrage bearbeiten
ermöglicht das Bearbeiten aller Umfrageparameter. CIRS Meldebogen ausfüllen ist
ähnlich der Vorschau, mit dem Unterschied, dass hier alle erzeugten Daten in die
Auswertung einfließen. Dieser Fall ist notwendig, wenn neben dem softwaregestützten
CIRS noch ein papierbasiertes CIRS existiert, weil eventuell nicht jede
Klinik über Computer verfügt oder Mitarbeiter diese nicht bedienen können. So

- 39 -
kann der Risikomanger den ausgefüllten Papiermeldebogen in das System übertragen.
Dieser wird dann bei der Auswertung mit berücksichtigt.
3.3.6 Entwicklung der Benutzungsoberfläche
Bei der Entwicklung der Benutzungsoberfläche wurden sehr detaillierte GUI-
Mockups erstellt. Ein GUI-Mockup in der Softwareentwicklung bezeichnet einen
rudimentären Wegwerfprototyp der Benutzungsoberfläche einer zu erstellenden
Software. Sie dienen in erster Linie zum besseren Verständnis zwischen
Entwickler und Auftraggeber. 3) Des Weiteren können die Mockups zum Vermessen
einzelner GUI-Elemente eingesetzt werden, um so eine ergonomische
Benutzungsoberflächen-Gestaltung zu gewährleisten.
Die Benutzungsoberfläche in der Risikoussoftware wird zwei Hauptansichten
besitzen, eine Meldebogenansicht und eine Managementansicht. Die Meldebogenansicht
ist die Oberfläche, die dem Mitarbeiter den Meldebogen zum Ausfüllen
breitstellt. Der Risikomanager benutzt die Managementansicht. Sie stellt alle für
den Manager relevanten Funktionen und Ansichten bereit. Die folgenden zwei
GUI-Mockups zeigen die jeweiligen Ansichten.
Die in Abbildung 3.5 abgebildete Meldebogenansicht besteht aus dem Header, der
Navigationsleiste und dem Fragenbereich. Der Header trägt das Logo des Städtischen
Klinikums Görlitz. Der Navigationsbereich bietet auf der linken Seite
Funktionen in Form von Buttons an. Auf der rechten Seite wird ein Statusbar
angezeigt, der dem meldenden Mitarbeiter den Verlauf signalisiert. Im Meldebogenteil
werden die entsprechenden Fragen mit den dazugehörigen Antworten
angezeigt. Neben den Antworten befinden sich Radiobuttons 4) . Sie dienen
3) Vgl.[DfE07]
4) Ein Radiobutton ist ein Benutzungsoberflächenelement. Es kann zwei Zustände besitzen: angewählt
oder nicht angewählt. Angewählt wird ein Radiobutton mit der Computermaus.

- 40 -
Abbildung 3.5: GUI-Mockup Meldebogen
zum Selektieren einer Antwort. Um die einzelnen Fragen übersichtlich darstellen
zu können, werden diese mit Rahmen voneinander abgegrenzt. Im oberen
Teil befindet sich eine Leiste, die den entsprechenden Blocknamen enthält. Der
Blockname beschreibt eine Kategorie von Fragen. In Abbildung 3.5 ist der Block
Ereignis mit seinen entsprechenden Fragen dargestellt. Der Fragenbereich kann
bei Bedarf mit Hilfe der Scrollbar 5) vertikal bewegt werden.
Das GUI-Mockup MessageReader zeigt einen Teil aus der Managementansicht.
Diese Ansicht teilt sich in den Header, den Navigationsbereich, die Titelleiste
und in den Funktionsbereich auf. In den Funktionsbereich wird entsprechend
der angewählten Funktion die Ansicht angezeigt. In diesem Fall der Message-
5) Die Scrollbar wird durch den Browser bereitgestellt. Der Browser blendet die Scrollbar ein,
wenn der Inhalt der Webseite größer ist als der Anzeigebereich des Browserfensters.

- 41 -
Abbildung 3.6: GUI-Mockup MessageReader
Reader. Um die Navigation unter den verschiedenen Ansichten des Managementbereiches
zu gewährleisten, befindet sich ein weiterer Navigationsbereich im oberen
Teil der Funktionsansicht. Dieser enthält auf der rechten Seite jeweils auch
Funktionen bereit, die in der jeweiligen Ansicht angewendet werden können. In
der Abbildung 3.6 stellt die Ansicht MessageReader dem Manager die Funktionen
pdf, bewerten und löschen bereit.
Wie auf den GUI-Mockups zu sehen ist, soll die Software überwiegend die Farbe
blau tragen. Blau ist die beliebteste Farbe bei Männer und Frauen und assoziiert
viele positive Eigenschaften wie Sympathie, Harmonie, Freundlichkeit, Vertraulichkeit
und Verläßlichkeit. Sie wirkt still und entspannend. 6) Diese Eigenschaf-
6) Vgl. [uHR]

- 42 -
ten sind eine wichtige Voraussetzung für den erfolgreichen Einsatz der Software
im Klinikumfeld.
3.4 Softwaredesign
Aus den Anforderungen geht hervor, das Risikous verschiedene Meldebögen
verwalten und veröffentlichen soll. Diese Forderung ist notwendig, da es vorkommen
kann, dass speziell angepasste Meldebögen einzelnen Kliniken bereitgestellt
werden sollen. Diese Tatsache hat einen entscheidenen Einfluss auf das
Design der Software. Der Inhalt 7) der Meldebögen kann natürlich variieren, was
zur Folge hat, dass auch sein softwaretechnisches Abbild variabel sein muss.
Um die Forderung zu erfüllen, muss eine softwaretechnische Repräsentation
des Meldebogens bereitgestellt werden, welche die Struktur des Bogens vorgibt,
vom Inhalt aber vollkommen abstrahiert. Diese Repräsentation soll mittels Extensible
Markup Language 8) erreicht werden. Der XML-Bogen wird vom Mitarbeiter
mit Hilfe eines Editors erstellt. Nach dem Erstellen wird dieser vom
System aufgenommen und in einer Datenbank gespeichert. Danach erzeugt das
System den Online-Bogen, der anschließend dem Mitarbeiter zum Ausfüllen zur
Verfügung steht.
Die Abbildung 3.7 verdeutlicht die eben erläuterte Funktionsweise.
Durch den „flexiblen“ Bogen entsteht die Möglichkeit, nicht nur CIRS-Meldebögen
in das System zu laden, sondern jegliche andere Arten von Bögen. Im Krankenhausbereich
existieren weitere Bögen, wie beispielsweise Sturzmelde-, Besch-
7) Der Inhalt eines Meldebogens besteht in der Regel aus Fragen, Antworten und verschiedenen
Antwortmöglichkeiten (Freitext, Felder zum Ankreuzen)
8) Bei der Extensible Markup Language (XML) handelt es sich um eine Metasprache. Eine Metasprache
hat die Eigenschaft, dass man mit dieser weitere Sprachen für einen konkreten
Anwendungsfall bilden kann.

- 43 -
Abbildung 3.7: Softwaredesign – Meldebogen
werde-, Patientenbefragungs-, Mitarbeiterbefragungsbögen und viele andere. Allerdings
existieren unterschiedliche Anforderungen beim weiteren Verarbeiten
der ausgefüllten Bögen. Um diese Anforderungen entsprechend zu strukturieren
soll Risikous modular aufgebaut sein. Das heißt, dass für jeden Prozess der
abgebildet werden soll, ein entsprechendes Modul entwickelt werden muss. In
dieser Arbeit werden neben dem Meldebogensystem (Basis) für die Weiterverarbeitung
von Bögen nur Module, welche die CIRS Funktionalität betreffen, entwickelt.
3.4.1 Basis-Module
Die Basis der Software soll in vier Modulen abgebildet werden. Diese Module
sollen Funktionen zum Erstellen, Veröffentlichen, Speichern, Löschen und Bearbeiten
von Umfragen implementieren. Eine Umfrage besteht in der Software
immer aus einem Bogen und Parametern.

- 44 -
Modul setup
Dieses Modul soll den Bogen im XML-Format entgegennehmen und diesen in
der Datenbank abspeichern. Das Setup-Modul soll weiterhin Funktionen zum
Konfigurieren von Parametern für eine Umfrage zur Verfügung stellen. Die einzelnen
Parameter werden im Folgenden aufgelistet:
• Name der Umfrage
• Start- und Endzeitpunkt der Umfrage
• Email und Hotline Funktion
• anonyme Feedbackfunktion
• PDF-Dokument herunterladen (Mitarbeiter)
• Zugangsparole (für anonymen Zugriff auf Umfrage)
• Umfrage-Startseite mit Inhalt
• Umfrage für Mitarbeiter verfügbar
Das Modul soll nach dem Erstellen der Umfrage einen Link erzeugen, der auf
die entsprechende Umfrage zeigt. Dieser URL wird ein vom Modul erzeugter,
eindeutiger Code angehangen, welcher der Umfrage zugeordnet ist.
Modul questionnaire
Dieses Modul soll alle Funktionen enthalten die notwendig sind, um die Umfrage
dem Mitarbeiter über eine Webeite zur Verfügung zu stellen. Dazu verwendet
es die im Modul Setup konfigurierten Parameter und passt entsprechend

- 45 -
die Umfrageelemente 9) an. Ist beispielsweise der Parameter Zugangsparole aktiviert,
soll das Modul eine Startseite erzeugen, die den Mitarbeiter nach der Parole
fragt und diese entsprechend überprüft. Weiterhin soll das Modul Funktionen
zum Speichern des ausgefüllten Meldebogens enthalten.
Modul usermanagement
Das Modul usermanagement soll die komplette Benutzerverwaltung 10) implementieren.
Es soll Funktionen zum Anlegen, Bearbeiten und Löschen von Nutzern
enthalten. Folgende Parameter sollen einen Nutzer beschreiben:
• Vorname
• Nachname
• Email
• Passwort
Mögliche Rechte im System (Beziehen sich auf das Risikomanagement, für die
Weiterverarbeitung von Bögen):
• Administrator (besitzt alle Rechte, die es in der Anwendung gibt)
• Umfragen erstellen, bearbeiten, löschen
• Bogen lesen, drucken, löschen
• Reporting erstellen
9) Umfrageelemente sind in diesem Fall Buttons, welche die einzelnen Funktionen dem Mitarbeiter
verfügbar machen.
10) Standartmäßig bezieht sich die Benutzerverwaltung im Fall der CIRS-Webanwendung für das
Klinikum Görlitz nur auf den Teil der Risikomanager. Das Modul kann auch den Zugriff auf
die Umfrage steuern, dann wäre aber im Fall des CIRS die Anonymität nicht mehr gewährleistet.

- 46 -
Modul XML
Das XML-Modul ist eher als ein Hilfs-Modul anzusehen, da es keinen konkreten
Geschäftsprozess abbildet. Dennoch ist es für die Basisfunktionalität der Software
nicht wegzudenken. Es soll Funktionen bereitstellen, um Daten entsprechend
ausserhalb der Software weiterverarbeiten zu können. Zu nennen wären das Erzeugen
von XML- und PDF-Dateien.
3.4.2 CIRS-Module
Modul messages
Das Modul messages soll alle Funktionen für ausgefüllte Meldebögen enthalten.
Das wären die Bewertung, das Lesen, das Löschen und die Dokumentation von
Meldungen. Für die Bewertung und Dokumentation von Meldungen soll das
System folgende Parameter zur Verfügung stellen:
• Bewertung des Risikos einer Meldung durch Riskomatrix
• Datum der Bewertung
• Datum, wann die Meldung abgeschlossen wurde
• Dokumentation zu Maßnahmen/Weiterverfolgung sowie Notizen zur Meldung
Um über die ausgefüllten Meldungen einen Überblick zu haben, soll das Modul
einen Baum implementieren, der die Meldungen in folgende Kategorien unterteilt:
• ungelesene Meldungen
• gelesene, aber unbewertete Meldungen

- 47 -
• bewertete Meldungen
• unbewertbare Meldungen
Modul reporting
Das Reporting-Modul soll Funktionen zur statistischen Auswertung aller bewerteten
Meldebögen enthalten. Dabei sollen jeweils die abgegebenen Antworten
in allen bewerteten Meldungen erfasst werden sowie die Gesamtanzahl aller bewerteten
Meldungen. Die Antworthäufigkeit jeder einzelnen Antwort soll absolut
und prozentual ermittelt werden. Um die jeweiligen Ergebnisse besser bewerten
zu können, soll das Modul die Ergebnisse grafisch aufarbeiten und als
PDF zur Verfügung stellen. Zum Auswerten von einzelnen Zeiträumen soll die
Software entsprechende Möglichkeiten implementieren.

- 48 -
4 Auswahl geeigneter Mittel
Dieses Kapitel beschäftigt sich mit der Auswahl der geeigneten Mittel für die
Implementierung des computergestützten CIRS. Dabei werden im ersten Abschnitt
die Funktionsweise und die Grundlagen von Webanwendungen kurz
erläutert. Anschließend werden verschiedene Webframeworks kurz vorgestellt
und an Hand verschiedener Kriterien, die für die Entwicklung des computergestützten
CIRS ausschlaggebend waren, verglichen. Der Vergleich beruht dabei
auf einem ausgiebigen, praktischen Test der einzelnen Frameworks 1) . Abschließend
wird eine Bewertung vorgenommen, welche den Einsatz eines der verglichenen
Webframeworks begründet.
4.1 Client-Server-Architektur
Das CIRS für das Klinikum Görlitz soll laut den Anforderungen eine Webanwendung
werden. Webanwendungen setzen auf einer Client-Server-Architektur
auf. Das heißt, es gibt einen Server, auf dem die Webanwendung läuft und einen
Client, auf dem ein Browser installiert ist. Der Client kann mit Hilfe des Browsers
eine Anfrage (HTTP-Request) an den Server stellen. Dazu schickt ein Benutzer
über eine URL einen HTTP-Request an den Server. Der Server empfängt
1) Als Framework bezeichnet man eine Menge von verknüpften Klassen, welche zusammen ein
wiederverwendbares und erweiterbares Gerüst für die Entwicklung von Software eines bestimmten
Typs bilden. [Vli94]

- 49 -
den HTTP-Request und bearbeitet diesen mit Hilfe von serverseitigen Zusatzprogrammen.
Nach der Bearbeitung der Anfrage wird eine Antwort (HTTP-
Response) generiert und diese an den Client geschickt. Der Browser zeigt dem
User nun die angeforderte Webseite an. Abbildung 4.1 zeigt die Kommunikation
zwischen Client, Server und serverseitigen Programmen.
Abbildung 4.1: Client-Server Kommunikation
4.2 Webanwendungen
Für Webanwendungen wird auf dem Client nur ein Browser benötigt, welcher
heutzutage auf jedem Rechner installiert ist. Dies hat die zwei Vorteile, dass
man clientseitig keine Software installieren muss und zweitens somit auch Plattformunabhängigkeit
gewährleistet ist. Webanwendungen haben weiterhin den
Vorzug, dass der Client immer mit der aktuellsten Version der Anwendung arbeitet,
da die Anwendung komplett auf dem Server ausgeführt wird und durch
den Client nur Nutzereingaben getätigt werden. Dadurch ist es möglich, eine
Webanwendung zentral auf dem Server zu warten. Von Vorteil ist auch, dass
auf einem Client eingegebene Daten anschließend auf dem Server gespeichert
werden und sofort anderen Clients zur Verfügung stehen.
Allerdings hat dies den Nachteil, dass immer eine Verbindung zum Server erforderlich
ist. Ein großes Problem bei Webanwendungen stellt auch die unterschiedliche
HTML, CSS und Javascript Interpretation der gängigen Browser In-

- 50 -
ternet Explorer, Mozilla Firefox, Opera und Apple Safari dar, obwohl Standards des
W3C 2) dafür existieren. Teilweise wird HTML und CSS sogar von unterschiedlichen
Browserversionen anders interpretiert.
Die serverseitige Verarbeitung der Daten und das Erstellen der HTML-Seite kann
durch Technologien wie PHP, CGI, ASP, ASP.NET oder Java-basierte Technologien
wie Servlets und JavaServer Pages realisiert werden. Dazu ist je nach Technologie
ein entsprechender Server oder Module für den bestehenden Webserver
notwendig. Um das CIRS zu implementieren wurden Java-basierte Technologien
gewählt. Java ist eine objektorientierte Programmiersprache, welche unter
anderem die Vorteile hat, dass sie plattformunabhängig ist und eine Vielzahl an
Frameworks für diese Sprache verfügbar ist, welche die Entwicklung von Software
beschleunigen.
4.3 Webanwendungen mit Java
Für die Entwicklung von verteilten Anwendungen in Java hat sich die „Java
Plattform Enterprise Edition“ (JavaEE) durchgesetzt. Sie spezifiziert eine Technologieplattform
und Architekturplattform für eben diese Anwendungen. Dafür
werden eine Reihe von „Application Programming Interfaces“ (kurz API)
mitgeliefert, welche als klar definierte Programmierschnittstellen zwischen den
Schichten und Komponenten des Systems dienen. Zur Ausführung von JavaEE-
Anwendungen werden spezielle, erweiterte Webserver benötigt, sogenannte Applikationsserver.
Diese müssen alle APIs bereitstellen, um als Webapplikationsserver
zu gelten. Als kleinsten Nenner stellt Sun Referenzimplementierung der
Schnittstellen zur Verfügung. Für das CIRS wurden unter anderem die Servlet
API und die JavaServer Pages API genutzt. JavaEE-Anwendungen stellen immer
eine Drei-Tier-Architektur dar. Bei einer Drei-Tier-Architektur wird eine Anwendung
in drei Schichten unterteilt:
2) Das W3C ist ein Verband zur Standardisierung der World Wide Web betreffenden Techniken.

- 51 -
• Präsentationsschicht (client tier) - auch Front End genannt. Sie enthält nur
minimalste Anwendungslogik, die zum Darstellen der Benutzungsoberfläche
erforderlich ist. Im Fall einer Webanwendung wäre es der auf dem Client
installierte Webbrowser, der nur die Verbindung herstellt und die Daten
zur Anzeige bringt. Die Präsentationsschicht stellt somit dem Nutzer
die Möglichkeit bereit mit der Anwendung zu interagieren. Dabei nimmt
sie Benutzer-Events entgegen, steuert das Benutzer-Interface und die Präsentation
der Daten.
• Applikationsschicht (application-server tier) - auch Middelware genannt.
Sie wird oft noch einmal in Webschicht (web tier) und Businessschicht
(business tier) unterteilt. Die Webschicht steuert das Verhalten der Applikation
und die Businessschicht enthält die Geschäftslogik und den kompletten
Verarbeitungsmechanismus. Weiterhin verfügt die Businessschicht
über Funktionen zum Schutz der Datenbestände und stellt eine Schnittstelle
(Dienst) zur Verfügung, auf die die Webschicht zugreifen kann. Weitere
Schnittstellen sind denkbar, wie beispielsweise die Bereitstellung der Datenbestände
an bereits bestehende Anwendungen. Beide Schichten befinden
sich auf einem Applikationsserver, wie zum Beispiel dem JBoss.
• Datenschicht (data-server tier) - auch Backend genannt. Sie ist für das Laden
und Speichern von Daten verantwortlich, was in den meisten Fällen
durch eine Datenbank realisiert wird. Die Datenschicht enthält keine Geschäftslogik.
Durch die klare Trennung von Präsentationsschicht, Applikationsschicht und
Datenschicht ist eine Applikation gut skalierbar, da die einzelnen Schichten logisch
von einander getrennt sind. So kann, im Fall einer Webanwendung, beispielsweise
die Datenschicht auf einem zentralen Datenbank-Server und die Applikationsschicht
auf einem Applikationsserver laufen. Die Präsentationsschicht
wird durch den Browser des Clients realisiert. Weiterhin bietet diese Architektur
bei der Wartung und Erweiterbarkeit einen großen Vorteil, da die Funktiona-

- 52 -
lität der einzelnen Schichten relativ leicht auszutauschen ist, ohne die anderen
Schichten ändern zu müssen. Abbildung 4.2 zeigt eine Webapplikation nach der
Drei-Tier-Architektur:
Abbildung 4.2: Drei-Tier-Architektur
4.4 Vegleich von Webframeworks für das CIRS
Webframeworks helfen bei der Entwicklung von größeren Webanwendungen.
Sie abstrahieren von JavaEE und verbergen dessen Komplexität vor dem Entwickler.
Sie geben auch eine grundlegende Struktur der Webanwendung vor,
zu welcher es sonst keine Vorgaben gibt. Die meisten Webframeworks bringen
auch nützliche Software-Pakete für Validierung, Internationalisierung oder Datenbankzugriff
mit, welche dem Entwickler Arbeit abnehmen. Durch Webframeworks
erreicht man also bessere Wartbarkeit, Wiederverwendbarkeit einzelner
Komponenten, einfache Erweiterbarkeit sowie Konfigurierbarkeit und vor
allem kürzere Entwicklungszeiten
Um das passende Framework für die Entwicklung der CIRS-Software für das
Klinikum Görlitz zu finden, wurden die folgenden Kriterien aufgestellt:
• Konfigurationsaufwand des Webframeworks
• Implementierungsaufwand

- 53 -
• Darstellung
• Validierung von Benutzereingaben
• Internationalisierung (i18n)
• Vorhandensein von Literatur und Dokumentation
Die vier großen Webframeworks Spring, Struts1, Struts2 und Cocoon wurden
mit Hilfe einer Beispielanwendung auf ihre Einsatztauglichkeit hin überprüft
und anhand dieser Kriterien bewertet. Die Beispielanwendung bestand aus einer
Seite, welche durch Internationalisierung in mehreren Sprachen verfügbar
sein soll. Auf dieser Seite soll ein Nutzer Daten eingeben können, welche im
Anschluß validiert werden. Je nach Erfolg der Validierung soll der Nutzer auf
unterschiedliche Seiten weitergeleitet werden.
4.4.1 Apache Struts
Apache Struts, auch Struts1 oder Struts Classic genannt, ist ein Open-Source-
Framework für die Präsentations- und Steuerungsschicht von Webanwendungen.
Es wurde von Craig McClanahan entwickelt und im Jahr 2000 an die Apache
Software Foundation zur weiteren Entwicklung übergeben. Seit dem Jahr
2005 besitzt Struts1 den Status eines „Apache Toplevel Project“. Struts1 ist das
derzeit am weitesten verbreitete Framework zur Entwicklung von Webanwendungen.
Eine genauere Erläuterung der Funktionsweise von Struts ist im Anhang
unter A.1 zu finden

- 54 -
Bewertung von Struts an Hand der Kriterien
Der Konfigurationsaufwand ist bei Struts1 recht groß, da alle Formklassen 3) und
Actionklassen 4) in der zentralen Konfigurationsdatei angemeldet werden müssen.
Im Anschluß wird das Verhalten der Actionklassen definiert, indem die jeweilige
Formklasse zugewiesen wird und die „ActionForwards“ angelegt werden,
welche auf eine JSP-Seite bzw. Tiles-Zusammenstellungen verweisen. Optional
kann auch angegeben werden, ob die Eingabedaten validiert werden sollen
oder nicht. Wird Tiles 5) genutzt, müssen in einer extra XML-Datei die Tiles-
Zusammenstellungen definiert werden.
Aufgrund der Tatsache, dass man für jede Action immer eine neue Actionklasse
und für jedes Formular eine Formklasse schreiben muss, kann der Implementierungsaufwand
als recht hoch eingeschätzt werden, worunter auch die Wartbarkeit
leidet. In der View-Komponente profitiert Struts1 von der mitgelieferten
Template Engine Tiles, welche die einzelnen JSP-Seiten leicht wiederverwendbar
und diese Komponente leicht wartbar macht.
Die Validierung von Nutzereingaben ist einfach gehalten, da man entweder die
Validierung in der „validate“-Methode in der entsprechenden Formklasse selbst
implementiert oder die Validierung in einer XML-Datei beschreibt. Das Schema
dieser Datei ist mit dem Schema des Commons Validator 6) Projekts identisch, wodurch
Entwickler mitgebrachte Erfahrungen mit diesem Projekt nutzen können.
Mehrsprachigkeit wird in Struts1 durch „Resource Bundles“ gelöst. Dazu existiert
eine Datei mit mehreren Schlüssel/Wert-Paaren. Für jede zu unterstützende
Sprache muss eine Datei, mit der jeweiligen Übersetzung angelegt werden, wobei
jeder Datei der jeweilige Ländercode im Dateinamen angehangen wird. In
einer JSP-Seite wird mittels der mitgelieferten Tags über einen Schlüssel zugegriffen
und das Tag durch den jeweiligen Wert ersetzt. Aus dem Request des Cli-
3) Eine Formklasse ist eine JavaBean, welche Nutzereingaben aufnimmt und speichert.
4) Anfragen eines Clients werden von Actionklassen bearbeitet.
5) Tiles ist eine Template Engine, siehe Anhang A.1
6) http://commons.apache.org/validator/

- 55 -
ents wird dabei der Ländercode ausgelesen und die entsprechende Sprachdatei
ausgewählt. Dieses Verfahren kann als recht einfach und effizient eingeschätzt
werden. Ein Problem bei Struts1 stellt die Literatur und Dokumentation dar. Einerseits
existieren viele Bücher, Tutorials zu Struts1, andererseits sind viele von
eher schlechter Qualität, oberflächlich oder regelrecht falsch.
4.4.2 Apache Struts2
Bei der Entwicklung von Struts1 wurde sehr auf die Wünsche der Industrie
eingegangen, unter anderem die vollständige Abwärtskompatibilität zu älteren
Versionen. Dadurch war es nicht immer möglich, Verbesserungen und neue Features
laut Roadmap der Entwickler zu implementieren oder zumindest nur mit
großer Verspätung. Aufgrund dieses Umstandes entstand das Framework Apache
WebWork, welches eine Alternative zu Struts1 darstellen sollte. Im Jahr 2005
wurde beschlossen, Struts1 komplett neu zu implementieren, wobei die Roadmap
für die Neuimplementation mit der Roadmap für das WebWork Framework
nahezu identisch war. Aufgrund dessen wurde die Weiterentwicklung von
WebWork im Jahr 2007 eingestellt. Alle Entwickler und ein Großteil des Quellcodes
wurden in die Neuimplementation übernommen, welche später Struts2
getauft wurde. Die erste Version von Struts2 erschien im Oktober 2006 und besitzt
aktuell den Status eines „Apache Toplevel Project“. Auf die Funktionsweise
von Struts2 wird in A.2 näher eingegangen.
Bewertung von Struts2 an Hand der Kriterien
Aufgrund dessen, dass die Konfiguration der Actions nur aus einem Namen,
optional einer Klasse mit dazugehörigen Interceptoren 7) sowie einer Liste von
Results bestehen, kann der Konfigurationsaufwand als recht gering eingeschätzt
7) Interceptoren werden vor der Ausführung einer Action aufgerufen und bereiten Daten auf.

- 56 -
werden. Viele Einstellungen haben Standartwerte, die ohne Änderungen übernommen
werden können. Sollte die Konfigurationsdatei zu groß werden, kann
diese in mehrere Teile unterteilt werden. Die Implementierung einer auf Struts2
basierenden Webanwendung kann als recht einfach bezeichnet werden. Die benötigten
Actions sind alle normale Java-Klassen. Zusätzlich hilft in Struts2 ein
sogenannter Entwicklungsmodus. Ist dieser aktiviert, werden bei jedem Aufruf
alle JSP-Seiten neu zu Servlets übersetzt. Die Konfigurationsdatei, „Resource
Bundles“ wird neu eingelesen und der Browser wird angewiesen nichts zu cachen.
In der View-Komponente von Struts2 sind vielfältige Technologien, wie
JSP, XSLT, Freemarker, Velocity oder auch JasperReports möglich. Für JSP-Seiten
kann das Tiles-Framework genutzt werden.
Die Validierung von Nutzereingaben wird in Struts2 mit der Object Graph Navigation
Language (kurz OGNL) verwirklicht. Mit dieser Sprache ist es möglich
auf Daten von Java-Objekten zuzugreifen. Diese Daten können dann mit Hilfe
von regulären Ausdrücken verglichen werden. Wie Eingabedaten validiert werden
sollen, ist in einer XML-Datei definiert. Mit Hilfe des Javascript-Themes ist
es möglich die Daten bereits clientseitig zu validieren. Die Syntax dieser XML-
Datei ist dem „Commons Validator“ Projekt ähnlich und somit leicht zu erlernen.
Die Mehrsprachigkeit wird exakt genauso wie in Struts1 über „Resource
Bundles“ und Tags zum Auslesen dieser erreicht.
Für Struts2 ist nur wenig Dokumentation verfügbar, Bücher existieren fast keine
und Tutorials sind schwer zu finden. Die ist dem Umstand geschuldet, dass
Struts2 ein recht neues Framework ist. Das Struts2-Projekt stellt aber eine Beispielanwendung
bereit, welche die verschiedenen Funktionen von Struts2 verdeutlicht.
Weiterhin existiert eine vorkonfigurierte, leere Webanwendung, wodurch
der Einstieg in die eigene Anwendung recht leicht gelingt.

- 57 -
4.4.3 Spring Framework
Das Spring Framework ist ein Open-Source-Framework. Es bietet eine komplette
Umgebung zur Entwicklung von JavaEE-Applikationen. Spring ist modular
aufgebaut, wobei die einzelnen Module sich durch andere, bereits existierende
Lösungen wie Hibernate austauschen lassen. Man bezeichnet Spring aus diesem
Grund auch als Metaframework. Der Kern des Frameworks kann für jede Java-
Applikation genutzt werden. Für die Programmierung von JavaEE-Anwendungen
stehen weitere Module wie Spring-MVC, Spring-DAO oder Spring-AOP zur
Verfügung. Spring setzt dabei auf ein POJO-basiertes Programmiermodell, dass
heißt, die Businessschicht wird mit Hilfe von POJOs realisiert. Die Verbindungen
zwischen diesen Objekten wird mit Dependency Injection hergestellt, dass heißt,
Konfigurationsparameter und zu verwendende Beans werden vom Framework
zur Laufzeit, bei der Instanziierung der POJOs injiziert. Die Konfiguration dazu
erfolgt deklarativ in XML-Dateien, wodurch es möglich ist, einzelne Programmbausteine
recht einfach durch andere zu ersetzen. In Abbildung 4.3 sind alle Module
von Spring dargestellt. Für die Webschicht einer JavaEE-Webanwendung
ist das Modul Spring-MVC verantwortlich. Die Funktionsweise dieses Moduls
ist im Anhang unter A.3 kurz erläutert.
Bewertung von Spring-MVC an Hand der Kriterien
Die Konfiguration einer Spring-MVC Anwendung ist einfach gehalten, kann
aber umfangreich werden. Zu jedem Servlet muss eine XML-Konfigurationsdatei
angelegt werden, welche die Definition für die Controller, ViewResolver sowie
das URL-Mapping enthält. Bei dem URL-Mapping wird jedem Request ein Controller
zugeordnet. Der Aufwand bei der Implementierung ist gering, da für jede
Klasse eine Referenzimplementation zur Verfügung gestellt wird, welche bei
Bedarf ersetzt werden kann. Die Möglichkeiten zu Darstellung sind im Spring-
MVC recht umfangreich. Neben JSP-Seiten sind zum Beispiel ebenfalls die View-

- 58 -
Abbildung 4.3: Übersicht Spring 8)
Technologien XSLT, Velocity oder PDF möglich.
Die Validierung von Nutzereingaben kann wahlweise über eine selbst geschriebene
Klasse geschehen oder wie bei Struts1 mit Hilfe des „Commons Validator“
Projekts über eine XML-Datei. Internationalisierung wird erreicht, indem man
„Resource Bundles“ am Servlet anmeldet. Im Anschluß kann man, wie bereits in
Struts1 und Struts2, in Java-Klassen oder in JSP-Seite durch Custom-Tags darauf
zugreifen.
Zu Spring existiert eine umfangreiche Dokumentation und eine Vielzahl an Büchern.
Im Internet findet man auch leicht eine Vielzahl guter Tutorials.
4.4.4 Apache Cocoon
Apache Cocoon ist ein Open-Source-Framework und basiert auf dem komponentenbasierten
Framework Apache Avalon. Cocoon ist hauptsächlich als XML-
Publishing-System konzipiert, weshalb viele Content Management Systeme wie
8) http://static.springframework.org/spring/docs/1.2.x/reference/

- 59 -
Apache Lenya oder Daisy auf Cocoon aufbauen. Es wurde 1998 von Stefano
Mazzocchi entwickelt und später an die Apache Software Foundation übergeben.
Mittlerweile existiert eine Neuimplementation, welche die Versionsnummer
2 trägt. Die Funktionsweise dieses Frameworks ist im Anhang unter A.4
beschrieben.
Bewertung von Cocoon an Hand der Kriterien
Cocoon läßt sich zentral in der „SiteMap“ einfach konfigurieren. Diese läßt sich
auch in „SubSiteMaps“ unterteilen. Bei einer Neuentwicklung einer Webanwendung,
auf Basis von Cocoon, entsteht vorerst ein immens hoher Konfigurationsaufwand.
Allerdings nimmt dieser Aufwand ab, da sich einzelne Komponenten
später wiederverwenden lassen.
Der Implementationsaufwand von Cocoon kann nicht direkt mit dem von Struts1,
Struts2 oder Spring verglichen werden. In Cocoon ist es nicht zwingend
nötig Java-Code zu schreiben, da alles mit XML-Dateien beschrieben wird. Allerdings
kann der Aufwand für das Schreiben dieser XML-Daten höher als bei
den restlichen Frameworks eingeschätzt werden. Auch muss ausführlicher getestet
werden, da keine Validierung der Komponenten zur Übersetzungszeit geschieht.
Durch die Trennung von Inhalt und Präsentation müssen selbst für einfache
Seiten mehrere Dateien, wie XML-Dokumente, XML-Schemas und XSL-
Dokumente, geschrieben werden. Zu Gute kommt Cocoon allerdings die Wiederverwendbarkeit
der einzelnen Komponenten. Wurde zum Beispiel eine Komponente
definiert, kann diese beliebig wiederverwendet werden. Als Ausgabeformat
sind unter anderem XML, HTML, PDF, PS oder SVG möglich.
Für Eingabedaten steht das „Cocoon Forms“-Framework, welches auf XForms
basiert, zur Verfügung. Mit diesem ist es möglich Formulare zu definieren und
gegebenenfalls zu validieren. Forms bestehen aus einem Template und einer
Definition. Um Formulare ausliefern zu können, werden spezielle Formular-
Generatoren und Transformatoren, benötigt. Für die Internationalisierung exis-

- 60 -
tiert ebenfalls ein Transformator, welcher den SAX-Stream der jeweiligen Sprache
entsprechend transformiert. Hier wird ebenfalls über einen Schlüssel auf den
jeweiligen Wert zugegriffen. Allerdings sind diese Schlüssel/Wert-Paare bei Cocoon
in XML-Dateien beschrieben.
Die verfügbare Literatur für Cocoon ist ausgesprochen hochwertig und die Dokumentation
des Projekts selbst hervorragend.
4.4.5 Fazit
Das CIRS für das Klinikum nimmt einen Meldebogen in XML-Form auf und
soll auch Ausgaben in XML-Form abliefern können. Hierfür eignet sich Apache
Cocoon besonders, da Cocoon komplett auf XML basiert und somit kein Technologiewechsel
nötig ist. Ein weiterer Vorteil von Cocoon ist die leichte Austauschbarkeit
des Ausgabeformats, ohne viel zu implementieren. Neben XML
und XHTML können auch PDF und Excel-Dokumente ausgegeben werden.
Cocoon setzt allerdings fundiertes Wissen über XML, XPath, XForm und XSL
voraus. Als Nachteil muss die Validierung über „cForms“ angesehen werden,
mit deren Hilfe man beispielsweise bei weitem nicht die Möglichkeiten der OG-
NL von Struts2 erreicht. Die Internationalisierung von Cocoon ist ebenfalls etwas
komplexer, da die Schlüssel/Wert-Paare nicht in einfachen Text-Dateien,
sondern in XML-Dateien abgelegt sind. Da die einzelnen Komponenten, wie
XSL-Dokumente nicht zur Übersetzungszeit validiert werden, entsteht später
ein erhöhter Testaufwand. Aufgrund dieser Tatsachen wurde vom Einsatz von
Cocoon abgesehen.
Struts1 ist ein leicht zu erlernendes Frameworks und unterstützt den Entwickler
in einer Reihe von Punkten wie Internationalisierung, Validierung oder Modularisierung
der View durch Tiles stark. Zu Struts1 existieren eine Reihe von Tutorials
und Bücher.
Ein großer Kritikpunkt ist das System der Action- und Formklassen. Wurde ei-

- 61 -
ne Actionklasse einmal instanziiert, so wird diese Instanz für jeden Request benutzt.
Dies kann zu Fehlern führen, wenn man bei der Entwicklung nicht auf
die Nebenläufigkeit der Actionklasse achtet. Struts1 Actionklassen und Formklassen
sind keine POJOs und müssen immer von einer abstrakten Klasse ableiten,
was den Entwickler dazu zwingt, spezielle Implementationsdetails zu beachten
und schränkt ihn somit in seiner Flexibilität ein. Unnötige Komplexität
wird dadurch erzeugt, dass zu jedem Eingabeformular immer eine Formklasse
existieren muss. Problematisch beim Füllen von Eingabedaten aus einem übertragenen
Formular in eine Formklasse ist die fehlende Typenkonvertierung. Alle
Daten müssen den Typ String haben und werden nicht automatisch in Integer-,
Boolean-, Long- oder Date-Werte konvertiert. Aufgrund dieser Probleme wurde
vom Einsatz des Struts1 Frameworks abgesehen.
Das Spring Framework bietet eine Grundlage zur Entwicklung kompletter JavaEE
Anwendungen. Für die Webschicht einer Webanwendung ist das Spring-
MVC gedacht. Das Spring-MVC ist dabei einfach strukturiert und schnell zu
verstehen. Verglichen mit Struts1 und Cocoon kann der Konfigurations- und
Implementierungsaufwand als wesentlich geringer eingeschätzt werden. In der
View-Komponente sind vielfältige Technologien möglich. Das Spring-MVC ermöglicht
es dem Entwickler Nutzereingaben recht einfach zu validieren und vereinfacht
die Internationalisierung einer Webanwendung.
Struts2 ist ein recht junges Webframework, welches momentan noch stark weiterentwickelt
wird. Der Implementierungsaufwand kann mit dem vom Spring-
MVC verglichen werden. Der Aufwand zur Konfiguration kann allerdings bei
Struts2 als geringer eingeschätzt werden. Struts2 geht bei der Validierung von
Nutzereingaben soweit, dass mit Hilfe der OGNL auf Java-Objekte zugegriffen
werden kann, was die Möglichkeiten der Validierung erweitert. Die Internationalisierung
wird ähnlich einfach wie bei Spring erreicht. Ein Problem bei Struts2
stellt die Literatur dar, weil kaum Bücher zu Struts2 existieren. Die projekteigene
Dokumentation ist recht knapp, wird aber immer wieder erweitert und verbes-

- 62 -
sert.
Mit beiden Frameworks ist es möglich, einfach und schnell Webanwendungen
zu entwickeln. Als Basis für die Implementierung des CIRS wurde das Webframework
Struts2 ausgesucht. Den Ausschlag dazu gaben zusätzliche Features,
wie das automatische Einbinden von Javascript für Interaktivität auf Clientseite,
der Entwicklungsmodus, die OGNL sowie die umfangreichen Tag-Bibliotheken.
Zusätzlich stellt das Struts2-Projekt eine leere, aber vorkonfigurierte Webanwendung
bereit, wodurch der Start der Implementierung stark beschleunigt wird.

- 63 -
5 Implementierung
Ausgehend von der Architektur der CIRS-Webanwenendung sollen in diesem
Kapitel einzelne Technologien und deren Zusammenspiel anhand von einigen
Codebeispielen erläutert werden. Dazu wird im ersten Teil des Kapitels die Drei-
Tier-Architektur mit den eingesetzten Komponenten dargestellt. Ausgehend davon
werden die verwendeten Komponenten im weiteren vorgestellt.
5.1 Architektur und Komponenten
Als Container für die Webanwendung soll das Struts2-Framework dienen, welches
sich nicht nur hervorragend zur Abbildung der Geschäftslogik eignet, sondern
auch in der Lage ist weitergehende Funktionalität, wie zum Beispiel das
PDF-Generieren, zu integrieren. Dementsprechend sind die Komponenten auf
dem Apache Tomcat Server in der Programmiersprache Java implementiert. Des
weiteren wurde Hibernate zur Anwendung gebracht, um die Arbeit der Persistierung
zu übernehmen. In diesem Zusammenhang wurde auch das Konzept
des DataAccessObjects verwendet, um persistenz-bezogene Funktionalität zu
kapseln. Zur Darstellung wurden ausschließlich JavaServer Pages unter Zuhilfenahme
der Struts2-Tag-Bibliothek eingesetzt. Die Abbildung 5.1 zeigt die Architektur
mit den einzelnen Komponenten. Alle wesentlichen Komponenten der
Webanwendung werden von Struts2 verwaltet und miteinander verknüpft. Dies
geschied maßgeblich in der Struts2-Konfigurationsdatei /Risikous/src/struts.xml.

- 64 -
Abbildung 5.1: Risikous Systemarchitektur
Neben den Komponenten werden in der Konfigurationsdatei auch Parameter
gesetzt, die das Verhalten der Webanwendung beinflussen. Das wären beispielsweise
der Entwicklermodus, das Cacheverhalten des Browsers und die Internationalisierung.
Da die Webanwendung aus mehreren Modulen besteht, wurden
für die jeweiligen Module extra Konfigurationsdateien angelegt. Das hat den
Vorteil, dass die Konfiguration übersichtlich bleibt und auch neuen Entwicklern
den Einstieg in die Software erleichtert.
5.2 Persistierung
In Webanwendungen existieren Daten nur eine begrenzte Zeit. Möchte man diese
Daten speichern, muss man auf eine Persistenzlösung zurückgreifen. Eine
Möglichkeit besteht darin, die Daten in Dateien zu speichern, was aber bei großen
Datenmengen zu Unübersichtlichkeit und schlechter Leistung führt. Eine Datenbank
ist eine weitere Möglichkeit. Sie kümmert sich selbst um die Verwaltung
und einen effektiven Zugriff auf die Daten. Allerdings hat sie den Nachteil, dass

- 65 -
exakt festgelegt werden muss, wie alle Objekte der Anwendung auf die Datenbank
abgebildet werden sollen. Eine Möglichkeit, diesen Nachteil zu umgehen,
ist Object-Relational-Mapping (kurz: ORM) . Dabei wird der Zustand eines Objekts
in einer relationalen Datenbank gespeichert und aus entsprechenden Datensätzen
wiederum Objekte erzeugt.
Bei Risikous fiel die Wahl auf das Open-Source-Framework „Hibernate“. Es gilt
als stabil und ist leicht über externe XML-Dateien konfigurierbar. Mit Hilfe der
Hibernate Query Language (kurz HQL) wird auf die persistenten Objekte zugegriffen.
Die persistenten Objekte stellen in der Webanwendung die Modellklassen
dar. Die Abbildung 5.2 zeigt das Klassendiagramm der Modellklassen. Die zu
Abbildung 5.2: Klassendiagramm DataTransferObjects
speichernden Klassen werden, unter Verwendung von Hibernate, auf Tabellen
in der Datenbank gemappt. Diese Klassen sind einfache JavaBeans. Der Zugriff
aus der Businesslogik auf die Modellklassen wird mit Hilfe von DataAccessObjects
(kurz DAO) realisiert. Sie entkoppeln die Persitenzlogik von der Geschäftslogik
und sind für den Datenzugriff optimiert.

- 66 -
5.3 Meldebogenrepräsentation
Risikous soll die Möglichkeit bieten, verschiedene CIRS-Umfragen im Klinikum
durchführen zu können. Dabei soll die Software den Meldebogen im einheitlichen
Layout, als Webseite dem Mitarbeiter zur Verfügung stellen. Als Vorlage
für den Aufbau der Webseite wurde der Meldebogen der Firma Protec verwendet.
Der Meldebogen teilt dabei die verschiedenen Fragen in Blöcke ein. Jeder
Block enthält die entsprechenden Fragen und die dazugehörige Auswahl
an Antworten. Für die Abgabe der Antwort stellt der Meldebogen Felder zum
Ankreuzen zur Verfügung. Weiterhin stellt der Meldebogen die Möglichkeit bereit,
ausgesuchte Fragen schriftlich zu beantworten, beispielsweise „Was ist passiert?“.
Aufbauend auf dem Meldebogen der Firma Protec und dessen Aufbau
wurde XML 1) als Sprache zur Repräsentation gewählt. Die Entscheidung für den
Einsatz von XML beschreibt der folgende Satz recht präzise.
„Die EXTENSIBLE MARKUP LANGUAGE (XML) ist ein einfaches,
universales Format für den Austausch strukturierter Informationen.“ 2)
Der Satz erwähnt, das XML Informationen strukturiert weitergegeben und gespeichert
werden können. Der Aufbau des Meldebogens der Firma Protec besitz
auch eine Struktur, bestehend aus Blöcken, Fragen und Antworten. Diese
lässt sich mittels XML wunderbar abbilden. Zum Abbilden der einzelnen Informationen
werden in XML so genannte Tags verwendet. Die Tags besitzen
einen Bezeichner, welcher in spitzen Klammern geschrieben wird. Die Tags treten
meist paarweise auf. Das erste dieser Tags ist das öffnende Tag () und
das schließende Tag besitzt nach der öffnenden, spitzen Klammer einen Schrägstrich
(). Zwischen den Tags stehen die jeweiligen Informationen, beziehungsweise
können auch weitere Tags eingeschlossen werden. Es gibt allerdings
1) Bei XML handelt es sich um eine Metasprache. Eine Metasprache hat die Eigenschaft, dass
man mit dieser weitere Sprachen für einen konkreten Anwendungsfall bilden kann.
2) [WK03], Seite 17

- 67 -
auch leere Tags, welche vor der schließenden Klammer mit einem Schrägstrich
geschlossen werden (). In einem Tag können auch Attribute stehen, welche
aus einem Schlüssel und einem dazugehörigen Wert bestehen. Die Kombination
aus Starttag und Endtag nennt man Element. Das Listing 5.1 zeigt einen
Ausschnitt aus dem aktuellen Meldebogen in XML. Wie zu sehen ist, kann die
XML-Datei vom Menschen gelesen werden, was einer der Vorteile von XML
ist.
1
2
3
4
5
6 verantwortlich
7 verursachend
8 helfend, zum Ereignis hinzu gerufen
9 beobachtet
10 selbst vom Ereignis betroffen
11 sonstiges
12
13
14
15
Quellcode 5.1: Ausschnitt aus der XML-Datei des Meldebogens der Firma Protec
5.3.1 Aufbau
Das Listing 5.1 enthält einen Teil des ersten Blocks des Meldebogens. Am Anfang
des XML-Dokuments wurde eine Deklaration

- 68 -
UTF-8“?> eingefügt. Das encoding=“UTF-8“ gibt den verwendeten Zeichensatz
an. Beim Meldebogen von Protec wurde der Unicode Zeichensatz UTF-8 verwendet.
Dadurch besteht die Möglichkeit, die Fragen und Antworten im Meldebogen
in einer beliebigen Sprache, zu schreiben. Die Zeile 2 im Listing 5.1 enthält
sogenannte Processing Instruction. Sie richten sich an ein „nichtmenschliches
Publikum“, nämlich an ein Anwendungsprogramm, dass das XML-Dokument
ganz oder teilweise verarbeiten soll. Im Kommenden sollen die wichtigsten Tags
des Meldebogens kurz vorgestellt werden.
Das Block-Tag repräsentiert, wie im Meldebogen der Firma Protec, einen Block
bestehend aus Fragen und Antworten. Weiterhin enthält das Tag ein Attribut
Text, welches als Wert den Namen des Blockes enthält. Ist das -Tag geöffnet,
folgt danach das question-Tag.
Das question-Tag repräsentiert eine Frage und enthält als Attribut den Text der
Frage. Nach dem question-Tag folgen die möglichen Antworten.
Mit dem -Tag kann angegeben werden, ob es sich bei der
Frage um eine Pflichtfrage handelt oder nicht. Dazu wird der Wert des Attributes
auf true für keine Pflichtfrage oder auf false für eine Pflichtfrage verwendet.
verantwortlich
Da es im Meldebogen mehrere Möglichkeiten zum Beantworten von Fragen gibt,
müssen diese auch im XML-Meldebogen entsprechend angegeben werden. Dazu
stehen zwei Tags zur Verfügung. Das -Tag repräsentiert die Antwortmöglichkeit
des Ankreuzens und das -Tag repräsentiert Freitextfelder.
Zwischen den Tags wird die entsprechende Antwort formuliert, beispielsweise
verantwortlich.

- 69 -
5.3.2 XML-Schema des Meldebogens
Da mit XML beliebige XML-basierende Markup-Sprachen definiert werden können,
ist es erforderlich, dass Regeln für die entsprechende Sprache existieren.
Diese Regeln werden in XML-Schemas oder mit Hilfe der Document Type Definition
(DTD) umgesetzt. Das XML-Schema ist dabei eine Sprache zum Definieren
von XML-Strukturen. Für den XML-Meldebogen wurde ein XML-Schema
entworfen, dieses befindet sich im Anhang B.1. Das XML-Schema wird beim
Laden eines XML-Meldebogens in die Software zum Validieren benötigt. Entspricht
der XML-Meldebogen nicht dem Regelwerk, erkennt das der Parser anhand
des Schemas und gibt einen Fehler zurück.
5.4 Benutzungsoberfläche - Ergonomie
Um die Anwendung mit einer intuitiven Benutzungsoberfläche zu versehen,
werden verschiedene Technologien eingesetzt. Die Benutzungsoberfläche wird
bei Webanwendungen in Form von HTML-Seiten in einem entsprechenden Webbrowser
dargestellt. Diese HTML-Seiten werden von der Risikous-Anwendung
mittels JSP’s erzeugt. JavaServer Pages sind meist normale HTML-Dokumente,
welche mit speziellen Tags Serlvetfunktionalitäten einbinden. Das Framework
Struts2 stellt eine umfangreiche Tag-Bibliothek zur Verfügung. Dabei teilt die
Struts2 Tag-Bibliothek die Tags in die Kategorien Control Tags, Data Tags, Form-
Tags, Non-Form UI Tags und in JavaScript Tags ein. 3) Die einzelnen Struts2-
Tags werden in einer JSP immer mit dem Präfix benutzt. Eine Neuheit
stellt Struts2 mit den JavaScript Tags zur Verfügung. Sie ermöglichen es, ohne
große JavaScript Kenntnisse, clientseitige Dynamik zu implementieren. In Risikous
wurde der Kalender für das Reporting und das Setup mit Hilfe der Ajax-
3) Die komplette Tagreferenz stellt das Struts2 Projekt auf der Webseite
http://struts.apache.org/2.x/docs/tag-reference.html bereit.

- 70 -
Tags implementiert. Weiterhin wurde auch das Nachladen von
verschiedenen Teilen einer Ansicht mit den JavaScript-Tags realisiert.
Die Abbildung 5.2 zeigt einen Ausschnitt aus der period.jsp, welche für die Angabe
des Zeitraumes für das Reporting zuständig ist.
1
2
3
4 :
5
6
7
8
Quellcode 5.2: Ausschnitt aus der Period JSP
Weiterhin wurde das Tiles-Framework, welches mit Struts2 mitgeliefert wird,
eingesetzt. Es ermöglicht die Webseite komponentenbasiert aufzubauen. Im Fall
von Risikous ist die Benutzungsoberfläche in Header, Titel, Navigation, Content
und Footer eingeteilt, wobei nicht in jeder Ansicht alle Komponenten benötigt
werden. Durch den Einsatz von Tiles wird zur Laufzeit das benötigte Layout
mit den jeweiligen Komponenten erstellt. Um dies Realisieren zu können, existiert
in der Risikous-Anwendung eine layout.jsp, welche das globale Layout enthält.
In dieser sind die View-Elemente enthalten, die in jeder Ansicht verwendet
werden sowie Tiles-Attribute. Die Tiles-Attribute werden während der Laufzeit
mit den entsprechenden Komponenten verknüpft. Damit die Webanwendung
die entsprechenden Komponenten zuordnen kann, werden diese in der tiles.xml
konfiguriert. Dies hat den Vorteil, dass das Layout zentral in einer XML-
Konfigurationsdatei festlegt werden kann, was vor allem die Wartbarkeit der
Software erhöht. Soll zum Beispiel global das Layout ausgetauscht werden, so

- 71 -
ist nur ein Eintrag in der tiles.xml zu ändern. Die komplette layout.jsp sowie die
Tiles-Konfiguration der Webanwendung kann im Anhang B.2 und B.3 eingesehen
werden.
Für die Eingabe von Daten stellt die Anwendung dem Nutzer entsprechende
Eingabefelder zur Verfügung. Bei einigen dieser Eingabefelder, beispielsweise
beim Login, muss eine Überprüfung der Eingabedaten stattfinden. Dabei prüft
das System beim Login, ob es sich um eine Email-Adresse handelt oder ob die
Länge des Passwortes aus min. 8 Zeichen besteht. Im Fehlerfall signalisiert die
Anwendung den Fehler, in dem es die fehlerhafte Eingabe mit der Farbe rot
anzeigt. Die Validierung ist in Risikous in XML-Dateien definiert. Um die Validierung
zu aktivieren, muss sich der Interceptor, welcher die Validierung durchführt,
in dem Interceptor-Stack der Action befinden. In den XML-Dateien kann
nach Integerwerten, Emails, Zeichenketten validiert werden, oder für komplexere
Begriffe können reguläre Ausdrücke definiert werden. Auf Java-Objekte und
deren Eigenschaften kann durch OGNL zugegriffen werden.
1
2
3
4
5 true
6
7
8
9 true
10
11
12
13
Quellcode 5.3: Login – Validation

- 72 -
In Listing 5.3 ist ein Ausschnitt der XML-Datei zu sehen, welche die Validierung
der Eingaben auf der Login-Seite beschreibt. Der Ausschnitt gibt an, wie das
Email-Eingabefeld validiert wird. Für das Feld existieren zwei Validierungsregeln.
Mit der ersten Regel wird überprüft, ob überhaupt eine Eingabe getätigt
wurde. Wurde eine Eingabe getätigt, wird in der zweiten Regel geprüft, ob die
Eingabe eine gültige Email ist, wobei führende und nachstehende Leerzeichen
mit Hilfe des Parameters „trim“ entfernt werden. Beide Regeln verweisen auf
einen Key, welcher die Fehlermeldung in der jeweils verwendeten Sprache beschreibt.
5.5 Internationalisierung des CIRS
Um die vielen Bezeichnungen innerhalb der Webanwendung einheitlich und
zentral verwalten zu können, wurden der Struts2 Message Resources eingesetzt.
Der Struts2 Message Resource besteht aus einer oder mehreren Properties-Dateien.
Sie enthalten einzelne Bezeichnungen, die in der Webanwendung verwendet
werden. Die einzelnen Bezeichnungen werden zur Laufzeit entsprechend
von Struts2 aus der Properties-Datei ausgelesen und an die entsprechenden Stellen
der Webanwendung geschrieben. Dieses Verfahren hat den Vorteil, dass die
einzelnen Bezeichnungen zentral an einer Stelle verwaltet werden können, ohne
den Quellcode antasten zu müssen. Das Listing 5.4 stellt einen Teil aus einer
Properties-Datei der Webanwendung dar. Bei der Risikous Webanwendung
wurde für jedes Modul eine extra Propertie-Datei angelegt. Das hat den Vorteil,
dass nicht erst in einer langen Datei nach der entsprechenden Bezeichnung gesucht
werden muss.

- 73 -
1 # Resources for parameter ’de.klinikum.struts.action.questionnaire’
2 # Project CIRS for Klinikum Görlitz
3 # Application Resource for German Language
4
5 # Info
6 questionnaire.link.hotline=Hotline
7 questionnaire.link.email=Email
8 questionnaire.link.feedback=Feedback
9 questionnaire.link.help=Hilfe
Quellcode 5.4: Teil aus der package.properties des CIRS-Umfrage Package
Weitherhin lässt der Struts2 Message Source die Möglichkeit offen, die Software
zu einem späteren Zeitpunkt zu internationalisieren. Dazu müssen nur weitere
Propertie-Dateien mit den entsprechenden Bezeichnungen in der neuen Sprache
erstellt werden. Diese müssen aber am Ende des Dateinamens die entsprechende
Länderkennung angehängt bekommen. Für die Englische Sprache würde
ein „en“ angehangen werden. Die Datei sollte dann package.properties_en heißen.
Wird die Risikous-Webanwendung nun von einem Browser gestartet, der
als Standardsprache 4) Englisch eingestellt hat, wird automatisch die Webanwendung
in der Sprache Englisch ausgeliefert.
5.6 Erzeugen von PDF-Dateien
Zur Weiterverarbeitung der erzeugten Daten wird an den entsprechenden Stellen
in der Webanwendung die Möglichkeit geboten, PDF-Dateien zu erstellen.
Die PDF-Dateien sollen über eine Download-Funktion dem Nutzer bereitgestellt
werden. Das Layout dieser Dateien soll dem Klinikum üblichen Style genügen.
4) Die Sprachen können im Firefox unter Extras->Einstellung->Erweitert->Sprachen eingestellt
werden.

- 74 -
Dieser schreibt vor, dass das Logo oben über die ganze Seite und die Seitenanzahl
mittig unten zu platzieren sind. Zum Erstellen von PDF-Dateien wird in
Risikous ein XML Dokument benötigt, welches die Parameter enthält, die im zu
erstellenden PDF angezeigt werden sollen. Das XML Dokument wird von der
Methode createQuestionnaire() zur Laufzeit erzeugt. Dabei legt die Methode den
erzeugten XML-Stream nicht auf die Festplatte in Form einer Datei ab, sondern
behält diesen für die Weiterverarbeitung im Speicher. Den kompletten Quellcode
der Methode createQuestionnaire() finden Sie im Anhang B.4.
Abbildung 5.3: Vorgang zum Erstellen einer PDF-Datei Mittels XSL-
FO
Weiterhin ist für das Erzeugen von PDF-Dateien eine XSL-Datei notwendig. Sie
enthält Regeln für die Transformation des XML-Dokuments in das XSL-FO-

- 75 -
Dokument 5) . Die Transformation wird durch einen XSLT-Prozessor durchgeführt.
Im Falle von Risikous wurde der Xalan 6) XSLT-Prozessor verwendet. Der XSLT-
Prozessor wählt aus dem XML-Dokument die erforderlichen Elemente aus und
transformiert diese mit Hilfe des XSL-Stylesheets in eine Kombination aus XSL-
FO-Elementen und -Attributen. Das fertige XSL-FO-Dokument enthält nun das
Erscheinungsbild des Zielmediums. Das sind im Falle des Meldebogen-PDF’s,
das Logo, die Überschrift, die Fragen mit den entsprechenden Antworten und
die Seitenzahl. Weiterhin sind auch Formatierungsoptionen für das Dokument
und für einzelne Elemente im XSL-FO-Dokument enthalten.
Im letzten Schritt wird durch einen Formatierer das XSL-FO-Dokument in das
PDF-Format übersetzt. In Risikous wird der frei verfügbare Apache Formatting
Objects Processor 7) verwendet. Dazu wird die Methode createPdf() aufgerufen,
diese nimmt als Parameter den XSL-FO-Bytestream und gibt als Resultat das
fertige PDF zurück. Die Methode createPdf() ist im Anhang B.5 dieser Arbeit einzusehen.
5) Extensible Stylesheet Language Formatting Objects (XSL-FO) ist eine XML-Spezifikation, die der
grafischen Aufarbeitung von XML-Dokumenten dient. Bei XSL-FO geht es darum, Dokumente
in druckbare Formate wie PDF oder PostScript umzuwandeln.
6) Xalan ist ein XSLT-Prozessor, der mit Hilfe von XSL-Stylesheets XML-Dokumente in ein Zielformat
überführt, beispielsweise in XSL-FO oder XHTML.
7) Der Formatting Objects Processor (FOP) erstellt aus XSL-FO-Dokumenten verschiedene Ausgabeformate.
Der Processor wurde von der Apache Foundation entwickelt.

- 76 -
6 Einsatzerprobung
Nach dem Abschluss der Implementierung von Riskous fand eine Einsatzerprobung
mit verschiedenen Kommilitonen des Matrikels II03 des Fachbereiches Informatik
der Hochschule Zittau/Görlitz statt. Dazu wurde die Webanwendung
auf einem virtuellen Server ausserhalb des Klinikums installiert. Für den Test
wurde der Meldebogen der Firma Protec verwendet. Die Testkandidaten erhielten
über „https“ Zugriff auf die CIRS-Umfrage und konnten diese testen. Über
die in der CIRS-Umfrage eingebaute Feedback-Funktion konnte bei Bedarf Kontakt
mit den Entwicklern aufgenommen werden. Das Feedback war recht positiv,
es wurde die gut strukturierte Anordnung der Fragen und Antworten sowie
der Statusbar gelobt. Die Erprobung verlief recht reibungslos bis auf einen
Fehler, der auf ein MySQL Problem zurückgeführt werden konnte. So trennte
die Datenbank standartmäßig nach 8 Stunden Inaktivität, zwischen der Webanwendung
und der DB, die Verbindung. Das Problem wurde versucht mit der
AutoReconnect Funktion von Hibernate zu lösen, was aber nicht zu einem zufriedenstellenden
Ergebnis führte. Aus diesem Grund wurde in Riskous eine Methode
implementiert, die auf das MySQL Ereignis reagiert. Nach dem Beheben
des Fehlers traten keine Probleme mehr zwischen Webanwendung und Datenbank
auf.
Nach der Präsentation der Webanwendung vor der Projektgruppe CIRS im Klinikum
GR wurde die Software zum Testen der Projektgruppe freigegeben. Dazu
wurde wie schon im ersten Test ein virtueller Server aus der Hochschule Zittau/Görlitz
benutzt. Weiterhin wurde eine Testwebseite eingerichtet, welche die

- 77 -
Teile Risikomanagement und Meldebogen ausfüllen, trennt. Dadurch konnten
die Projektmitarbeiter einmal das System aus Sicht des Mitarbeiters und aus
der Sicht des Risikomanagers testen. Für das Benutzen des Risikomanagements
wurde für jedes Projektmitglied ein extra Konto mit vollen Rechten in der Software
angelegt. Dadurch war jedes Mitglied in der Lage, alle Funktionen und Ansichten
der Software zu testen. Der Test verlief ohne große technische Probleme.
Es wurde lediglich anhand der Tomcat Logfiles ein java.lang.OutOfMemoryError
festgestellt, der auf zu wenig Arbeitsspeicher des Servers zurückgeführt werden
konnte. Nach Anpassung der Speicherkonfiguration des virtuellen Servers
trat der Fehler nicht mehr auf. Von seitens der Tester gab es keine technischen
Beanstandungen, lediglich inhaltliche Fragen zum Meldebogen wurden gestellt.
Diese Fragen wurden in einer weiteren Sitzung der Projektgruppe CIRS diskutiert.
Das Resultat wurde in den Meldebogen der Firma Protec integriert.

- 78 -
7 Ergebnisse und Ausblick
In diesem Kapitel sollen die erreichten Ergebnisse präsentiert werden. Dazu
werden ausgewählte Ergebnisse des praktischen Teils der Diplomarbeit in Bezug
auf die Anforderungen kurz vorgestellt. Anschließend soll ein Ausblick über
weitere Ideen zur Weiterentwicklung von Risikous gegeben werden.
7.1 Vorstellung ausgewählter Resultate
Ziel dieser Arbeit war es, ein computergestütztes CIRS zu entwickeln, welches
den Risikomanagementprozess unterstützt und die Patientensicherheit im Klinikum
Görlitz steigert. Dazu wurde ausgehend von den Anforderungen ein webbasiertes
CIRS implementiert, was zum einen dem Mitarbeiter einen Meldebogen
für Beinahefehler zur Verfügung stellt und zum anderen dem Risikomanagement
ein Mittel für die Bewertung und Auswertung dieser bereitstellt.
Um Maßnahmen zum Vermeiden von Beinahefehler ergreifen zu können, müssen
diese erkannt und erfasst werden. Zum Erfassen eines Beinahefehlers ist ein
Bogen notwendig, der für Risikous mittels einer XML-Datei repräsentiert wird.
Dazu wurde ein XML-Schema entwickelt, welches beliebige Bögen als XML abbilden
kann. Dadurch können unterschiedliche Bögen erstellt werden und von
Riskous aufgenommen werden. Zum Erstellen von CIRS-Umfragen wurden in
die Software umfangreiche Funktionen implementiert. Wie beispielsweise die

- 79 -
zeitliche Begrenzung von Umfragen, die Feedbackfunktion, Zugangsbeschränkung
und andere. Zum Ausfüllen des Meldebogens stellt das System nach dem
Einrichten automatisch den Bogen als Webseite dem Mitarbeiter dar. Die Webseite
besitzt eine ergonomische Benutzungsoberfläche, welche intuitiv zu bedienen
ist. Dabei werden die Fragen und Antworten in Kategorien eingeteilt, damit
der Mitarbeiter stehts den Überblick über diese behält. Des Weiteren wurden
die Fragen durch Rahmen von einander getrennt, damit diese übersichtlich wirken.
Ein Statusbar signalisiert dem Mitarbeiter stets den Verlauf der Meldung.
Mit Hilfe der Navigationsbuttons weiter und zurück kann sich der Mitarbeiter
problemlos im Meldebogen bewegen. Abbildung 7.1 zeigt einen Ausschnitt aus
einem Online-Meldebogen.
Abbildung 7.1: Benutzungsoberfläche aus der Sicht des meldenden Mitarbeiters
Eine der Hauptfunktion des Riskomanagers ist das Lesen und Bewerten von eingegangenen
Meldungen. Für diese Aufgabe wurde in Risikous der MessageReader
implementiert, der nicht nur Meldungen anzeigen kann, sondern diese auch
in einem Baum strukturiert darstellt. Wird im Baum auf eine Meldung geklickt,
wird diese angezeigt. Meldungen die schon bewertet wurden, werden im MessageReader
entsprechend ihrer Einteilung in der Risikomatrix rot, gelb oder grün

- 80 -
markiert. Die Abbildung 7.2 zeigt den MessageReader. Weiterhin wurde eine
XML-Schnittstelle eingebaut, welche das Weiterverarbeiten des Meldebogens,
beispielsweise in anderen Anwendungen erlaubt. Zum Bewerten von Risiken
Abbildung 7.2: Die Abbildung zeigt den MessageReader
wurde in die Software eine Risikomatrix implementiert, die nach dem Ausfüllen
der entsprechenden Meldung mit angehangen wird. Zum Dokumentieren
von Maßnahmen wurde in die Bewertungsansicht ein Textfeld aufgenommen,
wo eingeleitete Maßnahmen oder auch Notizen hinterlegt werden können. Abbildung
7.3 stellt die Bewertungsansicht mit Risikomatrix dar.
Als letztes Resultat dieser Arbeit soll noch die Auswertung kurz vorgestellt werden.
Die Auswertung von Risikous bietet einen Überblick über alle bewerteten
Meldungen. Dazu wurde eine Webseite erstellt, die alle Fragen und die dazugehörigen
Antworten dieser Meldungen auflistet. Hinter jeder Antwort ist jeweils
eine Zahl angezeigt, die Auskunft darüber gibt, wie oft diese Antwort bei
den bewerteten Meldungen ausgewählt wurde. Weiterhin wurde eine grafische

- 81 -
Abbildung 7.3: Dialog zum Bewerten von Meldungen
Auswertung implementiert, die Mittels PDF ausgegeben werden kann. Die Abbildung
7.4 zeigt einen Teil der Auswertung, welche als PDF-Datei ausgegeben
wurde. Um die Auswertung später eventuell anderweitig weiterzuverarbeiten,
wurde eine XML-Schnittstelle eingebaut.
Abbildung 7.4: Teil einer Auswertung als PDF

- 82 -
7.2 Ausblick
Trotz der kompletten Implementierung der CIRS-Software ergeben sich für die
Zukunft noch weitere Entwicklungsstufen. So ist das Erstellen und Bearbeiten
von Bögen für Nichtinformatiker nicht ganz trivial. Gewisse Kenntnisse im Umgang
mit XML sollte für das erfolgreiche Erstellen und Bearbeiten vorhanden
sein. Da das in der Praxis nicht immer der Fall ist, wäre hier ein grafischer Editor
(WYSIWYG) zum Erstellen und Bearbeiten von Bögen eine sinnvolle Ergänzung.
Für die Realisierung eines solchen Editors liefert die Risikous-Software ein
XML-Schema mit, was die Grundlage für den grafischen Editor bildet.
Eine weitere Ergänzung zum bisherigen System wären Werkzeuge für die Risikoüberwachung.
Beispielsweise könnte die Software eine zweite Risikomatrix
zur Verfügung stellen. Diese kann dann nach einem bestimmten Zeitraum, nachdem
Maßnahmen eingeleitet wurden, ausgefüllt werden. Anhand der Unterschiede
zwischen der Riskomatrix, die bei der Bewertung ausgefüllt wurde und
der zweiten Matrix, kann dann überprüft werden, wie sich das Risiko verändert
hat und ob die eingeleiteten Maßnahmen gegriffen haben.
Weiterhin könnte in das System ein Maßnahmenkatalog für kritische Ereignisse
integriert werden, der bei der Bewertung von Risiken von der Software zur
Verfügung gestellt wird. Natürlich müssen die verschiedenen Maßnahmen erst
einmal zusammengetragen werden, aber auch die Software kann bei jeder eingeleiteten
neuen Maßnahme diese im Maßnahmenkatalog speichern. So entsteht
mit der Zeit ein brauchbares Sammelsurium an Maßnahmen, auf das zu jeder
Zeit zurückgegriffen werden kann.
Abschliessend soll noch erwähnt werden, dass das Softwaresystem Risikous nur
eine kleine Spitze des Risikomanagements implementiert. Und es ist natürlich
denkbar, dass je nach Anforderung, weitere Prozesse des Risikomanagements
computergestützt abgebildet werden können. Risikous kann in dem Fall als Ba-

- 83 -
sis für weitere Implemenetierungen betrachtet und entsprechend weiterentwickelt
werden.

- 84 -
A Funktionsweise der
Webframeworks
A.1 Apache Struts
Struts1 liegt das JSP Model 2 und somit auch dem Entwurfsmuster „Model View
Controller“ zu Grunde, durch welches die Daten (Model) von der Präsentation
(View) abgekoppelt werden und über die Logik (Controller) miteinander verbunden
werden. Der Controller besteht in Struts1 aus einem Servlet namens
„ActionServlet“, Actionklassen und Formklassen. Das „ActionServlet“ nimmt
den Request eines Client entgegen und leitet ihn an eine JSP-Seite bzw. Tiles-
Zusammenstellung oder an eine Actionklasse und wenn nötig an die dazugehörige
Formklasse weiter. Welche Actionklasse den jeweiligen Request verarbeiten
soll oder an welche JSP-Seite weitergeleitet werden soll, ist in einer zentralen
Konfigurationsdatei abgespeichert. Dieser Systemaufbau ist in Abbildung A.1
dargestellt.
Wurde bei dem Request ein Formular übertragen, wird die dazugehörige Formklasse
instanziiert. Formklassen sind JavaBeans, denen die Daten des Formulars
über Setter-Methoden übergeben werden. Über die „validate“-Methode können
die Eingaben durch selbst geschriebenen Java-Code validiert werden. Alternativ
kann zu der Formklasse eine XML-Datei angelegt werden, in welcher beschrieben
ist, wie die Eingaben zu validieren sind. Schlägt die Validierung der Nut-

- 85 -
Abbildung A.1: Systemaufbau Struts1
zereingaben fehl, wird dem Client die zuletzt angezeigte Seite mit Hinweisen
auf die fehlerhaften Eingaben erneut zugesandt.
War die Validierung erfolgreich oder nicht nötig, wird die Actionklasse instanziiert
und die „execute“-Methode ausgeführt. Dieser wird, sofern vorhanden,
die Instanz der Formklasse als Parameter übergeben. Nachdem der Request bearbeitet
wurde, gibt die „execute“-Methode ein „ActionForward“ an das „ActionServlet“
zurück. Ein „ActionForward“ ist ein Objekt, welches angibt, welche
Seite nach der Ausführung der Action an den Client geliefert werden soll. Die
Seite liest die benötigten Daten des Models aus und liefert dem Client den Response.
Tiles
Tiles ist eine für Struts1 entwickelte Template Engine. Durch Tiles ist es möglich,
Webseiten aus einzelnen Komponenten aufzubauen und diese auf Wunsch

- 86 -
auszutauschen. Wie die einzelnen Seiten aufgebaut sind, ist in einer zentralen
Konfigurationsdatei beschrieben. Um Tiles-Seiten zu verwenden, muss eine Actionklasse
auf den Namen einer Tiles-Zusammenstellung verweisen. Mit Tiles
erreicht man eine Modularisierung der View, wodurch die Wiederverwendbarkeit
der einzelnen Komponenten gefördert wird.

- 87 -
A.2 Apache Struts2
In Struts2 wird das komplette Verhalten der Webanwendung in einer zentralen
Konfigurationsdatei definiert. Diese Datei besteht aus Konstanten und Packages,
welche voneinander ableiten können. Konstanten beschreiben, wie sich das
System verhält, so kann zum Beispiel die Kodierung fest eingestellt oder die Erweiterung
für Struts2 Actions festgelegt werden. Packages beinhalten Definitionen
für die Actions, Fehlerbehandlung, globale Weiterleitungen, Interceptoren
oder Interceptor-Stacks. Interceptoren werden vor dem Ausführen einer Action
aufgerufen und bereiten für diese Action zum Beispiel Daten auf, validieren
Nutzereingaben oder stellen „Resource Bundles“ für die Internationalisierung
bereit. Ein Interceptor-Stack ist eine geordnete Liste von Interceptoren. Vor jeder
Action können beliebig viele Interceptoren ausgeführt werden. Bei der Fehlerbehandlung
kann jeder Exception einer Action zugeordnet werden, welche aufgerufen
werden soll, wenn die Exception auftritt.
Eine Action besitzt immer einen Namen über den sie angesprochen werden
kann, sowie mindestens ein „Result“. Optional kann eine Java-Klasse angegeben
werden, welche den Request behandelt. In diesem Fall können verschiedene
Interceptoren bzw. Interceptor-Stacks angegeben werden, andernfalls wird
der Standartstack verwendet. Bei dem Namen ist Wildcard-Mapping möglich,
wodurch eine Action mehrere Requests bedienen kann. Ein „Result“ hat immer
einen Typ, welcher das weitere Vorgehen vorgibt. Hier ist zum Beispiel eine
Weiterleitung auf eine andere Action, auf eine JSP-Seite bzw. andere View-
Technologie möglich oder einen Stream für Downloads.
Bei einem Request wird durch das Struts2 Servlet die entsprechende Action aufgerufen.
Besitzt die Action eine dazugehörige Klasse, wird diese instanziiert und
alle angegebenen Interceptoren der Action aufgerufen. Im Anschluß wird die
gewünschte Methode der Action aufgerufen und der Request verarbeitet. Die
Actionklasse liefert den Namen des „Result“ zurück, welches nun aufgerufen
werden soll. Ist dieser „Result“ eine View-Technologie, wird der Response an

- 88 -
den Client geliefert. Der Systemaufbau des Struts2 Frameworks ist in Abbildung
A.2 abgebildet.
Abbildung A.2: Systemaufbau Struts2 1)
Tag Bibliotheken
Struts2 bringt eine umfangreiche Tag-Bibliothek mit, in welcher fast alle HTML-
Elemente zur einfacheren Nutzung definiert sind. Diese Tags besitzen ein Theme,
welches angibt wie sie verarbeitet werden sollen. Struts2 liefert einige Themes
für zum Beispiel HTML oder XHTML mit, es ist aber auch möglich eigene
1) http://struts.apache.org/2.x/docs/big-picture.html

- 89 -
Themes zu definieren. Ein spezielles Theme bindet die Javascript-Funktionalitäten
des Javascript-Toolkits Dojo ein. So können zum Beispiel Eingabedaten clientseitig
validiert werden.

- 90 -
A.3 Spring-MVC
Das Spring-MVC setzt das MVC Paradigma folgendermaßen um:
• Model:
Das Model wird durch JavaBeans realisiert, welche in XML-Konfigurationsdateien
verwaltet werden.
• View:
In der View sind vielfältige Technologien möglich. Neben JSP-Seiten können
unter anderem die View-Technologien XSLT oder Velocity eingesetzt
werden.
• Controller:
Ein „DispatcherServlet“ genanntes Servlet verteilt die Requests auf Controller,
welche diese bearbeiten.
Abbildung A.3: Bearbeitung eines Request

- 91 -
Das „DispatcherServlet“ nimmt den Request entgegen und ruft den entsprechenden
Controller auf. Welcher Controller welchen Request bedient ist in einer
XML-Konfigurationsdatei definiert. Nachdem der Controller den Request bearbeitet
hat, liefert er ein ModelAndView-Objekt zurück. Im Anschluss ruft das
Servlet einen ViewResolver auf, welcher zurück gibt, welche View an den Client
geliefert wird. Welche View jeweils zurückgeliefert wird, ist ebenfalls in der
XML-Datei beschrieben. Die View liest die auszugebenden Daten aus dem Model
und liefert dem Client den Response aus. Die Bearbeitung eines Request ist
in Abbildung A.3 dargestellt.

- 92 -
A.4 Apache Cocoon
Technisch basiert Cocoon auf der Servlet-Technologie. Ein „CocoonServlet“ genanntes
Servlet nimmt einen Requests entgegen, erzeugt ein SAX-Stream, welcher
im Anschluß mit XSLT transformiert und das Ergebnis an den Client geliefert
wird. Diese Architektur wird Pipeline-Architektur genannt und ist in Abbildung
A.4 aufgezeigt. Zum Parsen von XML-Dokumenten und Erzeugen des
SAX-Streams bedient sich Cocoon des Apache Projekts „Xerces“. Die Transformation
mit Hilfe des Apache Projekts „Xalan“ durchgeführt.
Abbildung A.4: Pipeline-Architektur
In Cocoon wird die Software ebenfalls in die drei Komponenten Model, View
und Controll nach dem MVC-Paradigma unterteilt. Der Controller besteht aus
dem „CocoonServlet“ und der „SiteMap“. Die SiteMap ist eine XML-Datei in
der die Cocoon Komponenten definiert sind. Welche Komponenten, bei welchem
Request in einer Pipeline verarbeitet werden, ist ebenfalls in dieser Datei
beschrieben. Komponenten einer Pipeline sind:
• Matcher: Ein Matcher prüft mit Hilfe eines Pattern ob ein bestimmter Request
vorliegt. Ist dies der Fall, so werden die Komponenten aufgerufen,
die für diesen Request verantwortlich sind.
• Generatoren: Jede Pipeline beginnt mit einem Generator, welcher einen
SAX-Stream erzeugt.
• Transformatoren: Der von einem Generator erzeugt SAX-Stream wird durch
Transformatoren umgewandelt. Dabei kümmert sich ein Transformator

- 93 -
meist nur um einzelne Elemente des Streams, weshalb es in einer Pipeline
beliebig viele Transformatoren geben kann.
• Serializer: Ein Serializer wandelt den SAX-Stream in ein Ausgabeformat
um, welches an den Client gesendet wird.
• View: Views stellen Ausstiegspunkte in einer Pipeline dar und liefern immer
den aktuellen Zustand des SAX-Streams.
• Selektor: Als eine Art Switch-Anweisung können Selektoren verstanden
werden, sie werten bestimmte Informationen des Requests aus und verweisen
auf unterschiedliche Zweige innerhalb der Pipeline.
• Reader: Bilder- und Videodateien müssen nicht geparst und verarbeitet
werden. Für die Auslieferung dieser Dateien an den Client sind Reader
zuständig.
• Actions: Actions erzeugen keine Ausgabe und nehmen nicht an der XML-
Verarbeitung teil, können aber Parameter und den Verlauf der Pipeline beeinflussen.

- 94 -
B Zusätzliche Quellcodebeispiele
B.1 XML-Meldebogen
Das folgende Listing und die folgende Abbildung beziehen sich auf den Abschnitt
XML-Schema im Kapitel Implementierung. Der XML-Code B.1 und die
Abbildung B.1 sind das Regelwerk für die Dokumentenstruktur des Meldebogens.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

- 95 -
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

- 96 -
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
Quellcode B.1: XML-Schema für den Meldebogen

- 97 -
Abbildung B.1: Grafische Darstellung des XML-Schemas für den Meldebogen
B.2 Benutzungsoberfläche - Ergonomie
Das Listing B.2 und das Listing B.3 bezieht sich auf den Abschnitt Benutzungsoberfläche
- Ergonomie. Die layout.jsp enthält das globale Layout der Anwendung.
Listing B.3 zeigt die Teils-Konfiguration von Risikous.
1
2
3
4
5

- 98 -
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32 document.onkeypress = disableKey;
33 showClock();
34
35
36
Quellcode B.2: Layout JSP

- 99 -
1
2
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

- 100 -
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

- 101 -
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76

- 102 -
77
78
79
80
81
82
83
84
85
86
87
Quellcode B.3: Tiles Konfigurationsfile
B.3 PDF erstellen
Die kommenden Code-Ausschnitte beziehen sich auf den Abschnitt PDF erzeugen
und zeigen die Methoden createQuestionnaire() und createPdf() aus der
Klasse XMLCreator.
1 public static Document createQuestionnaire( Questionnaire
questionnaire ) throws ParserConfigurationException
2 {
3 DocumentBuilderFactory docBFac = DocumentBuilderFactory.
newInstance();
4 DocumentBuilder docBuild = docBFac.newDocumentBuilder();
5 Document doc = docBuild.newDocument();
6

- 103 -
7 Element questionnaireElement = doc.createElement( "
questionnaire" );
8 questionnaireElement.setAttribute( "name" , questionnaire.
getName() );
9
10 // Blöcke addieren
11 for( int i = 0 ; i < questionnaire.getContent().size() ; i++ )
12 {
13 Block block = ( Block ) questionnaire.getContent().get( i );
14 Element blockElement = doc.createElement( "block" );
15 blockElement.setAttribute( "text" , block.getText() );
16 questionnaireElement.appendChild( blockElement );
17
18 // Fragen addieren
19 for( int j = 0 ; j < block.getQuestions().size() ; j++ )
20 {
21 Question question = ( Question ) block.getQuestions().get(
j );
22 Element questionElement = doc.createElement( "question" );
23 questionElement.setAttribute( "text" , question.getText()
);
24 blockElement.appendChild( questionElement );
25
26 // Radio addieren
27 for( int k = 0 ; k < question.getContent().size() ; k++ )
28 {
29 QuestionRadio questionRadio = ( QuestionRadio ) question
.getContent().get( k );
30 Element questionRadioElement = doc.createElement( "radio
" );
31 // optional
32 questionRadioElement.setAttribute( "optional" , String.
valueOf( questionRadio.getOptional() ) );
33 // text
34 if( questionRadio.getText() != null )
35 questionElement.setAttribute( "text" , question.
getText() );

- 104 -
36 questionElement.appendChild( questionRadioElement );
37
38 for( int l = 0 ; l < questionRadio.getContent().size() ;
l++ )
39 {
40 String value = ( String ) questionRadio.getContent().
get( l );
41 Element questionradioElement = doc.createElement( "
radio.value" );
42 questionradioElement.setTextContent( value );
43 questionRadioElement.appendChild( questionradioElement
);
44 }
45
46 if( questionRadio.hasFreetext() )
47 {
48 Element freetextElement = doc.createElement( "radio.
freetext" );
49 freetextElement.setTextContent( questionRadio.
getFreetext() );
50 questionRadioElement.appendChild( freetextElement );
51 }
52 }
53
54 if( question.hasFreetext() )
55 {
56 Element freetextElement = doc.createElement( "freetext"
);
57 freetextElement.setTextContent( question.
getFreetextDefault() );
58 freetextElement.setAttribute( "text" , question.getText
() );
59 freetextElement.setAttribute( "optional" , String.
valueOf( question.getFreetextOptional() ) );
60 freetextElement.setAttribute( "row" , String.valueOf(
question.getFreetextRows() ) );
61 questionElement.appendChild( freetextElement );

- 105 -
62 }
63 }
64 }
65 doc.appendChild(questionnaireElement);
66
67 return doc;
68 }
69 }
Quellcode B.4: Methode createQuestionnaire() aus der Klasse XMLCreator. Diese
Methode gibt als Rückgabewert einen Meldebogen in Form von XML zurück.
1
2 public static ByteArrayOutputStream createPdf( ByteArrayInputStream
xmlFo ) throws TransformerException, FOPException
3 {
4 FopFactory fopFactory = FopFactory.newInstance();
5 FOUserAgent foUserAgent = fopFactory.newFOUserAgent();
6
7 ByteArrayOutputStream out = new ByteArrayOutputStream();
8
9 // Construct fop with desired output format
10 Fop fop = fopFactory.newFop( MimeConstants.MIME_PDF ,
foUserAgent , out );
11
12 // Setup JAXP using identity transformer
13 TransformerFactory factory = TransformerFactory.newInstance();
14 Transformer fotransformer = factory.newTransformer(); //
identity transformer
15
16 // Setup input stream
17 Source src = new StreamSource( xmlFo );
18
19 // Resulting SAX events (the generated FO) must be piped
through to FOP
20 Result res = new SAXResult( fop.getDefaultHandler() );

- 106 -
21
22 // Start XSLT transformation and FOP processing
23 fotransformer.transform( src, res );
24
25 return out;
26 }
Quellcode B.5: Die Methode createPdf() erzeugt aus einem XSL-FO-Stream eine PDF-
Datei.

- 107 -
C Dokumentationen
C.1 Entwicklungsdokumentation
Bitte beachten Sie, dass es sich bei der Entwicklungsdokumentation um ein separates
Dokument handelt.

- 108 -
C.2 Benutzungsdokumentation
Bitte beachten Sie, dass es sich bei der Benutzungsdokumentation um ein separates
Dokument handelt.

- 109 -
C.3 Installationsdokumentation
Bitte beachten Sie, dass es sich bei der Installationsdokumentation um ein separates
Dokument handelt.

- 110 -
D Datenträgerbeschreibung
Auf der beiliegenden CD befinden sich der Quellcode der Risikous Webanwendung,
die Benutzungsdokumentation, die Entwicklungsdokumentation, die Installationsanleitung
sowie die Diplomarbeit in digitaler Form. Weiterhin befinden
sich für die Inbetriebnahme der Webanwendung alle benötigten Server auf
der CD. Die Server sind alle ab dem Betriebssystem Windows2000 lauffähig. Für
Linuxanwender müssen die entsprechenden Server noch gedownloaded werden,
Hinweise dazu befinden sich in der Installationsanleitung.
Die folgende Auflistung gibt Aufschluss über die Struktur der CD.
documents/
Diplomarbeit.pdf Diplomarbeit als PDF-Dokument.
Entwicklungsdokumentation.pdf Entwicklungsdokumentation als PDF-
Dokument
Benutzungsdokumentation.pdf Benutzungsdokumentation als PDF-
Dokument
Installationsanleitung.pdf Installationsanleitung als PDF-Dokument
software/
Server/
tomcat 5.5.25.exe Tomcat Servlet-Container

- 111 -
mySql 5.1.22.zip MySql Datenbankserver
tools/
mysql-gui-tools.msi MySql Datenbankwerkzeuge
risikous
Risikous.war Risikous-Webanwendung
sourcefiles/
Risikous/ Quellcode-Dateien der Risikous-Webanwendung

- 112 -
Literaturverzeichnis
[AZfQidM05] Ärztliches Zentrum für Qualität in der Medizin. Glossar Patientensicherheit,
Definitionen und Bergiffsbestimmungen.
http://www.forum-patientensicherheit.de/glossar_faqs/
pdf/glosspatsich.pdf, 2005. [Online: Stand 01. Juli 2007].
[DfE07]
[KW05]
[LO]
[Ris]
[Tho01]
[uHR]
Wikipedia Die freie Enzyklopädie. Mock-up.
http://de.wikipedia.org/wiki/Diskussion:Mock-up, 2007. [Online:
Stand 03 August 2007].
Heike A. Kahla-Witzsch. Praxis des Klinischen Risikomanagements.
ecomed, 2005.
Meyers Lexikon Online. Begriff Risiko.
http://lexikon.meyers.de/meyers/Risiko. [Online: Stand 23. Juli
2007].
Risknet.de. Definition Risiko.
http://www.risknet.de/Glossar.93.0.html?&tx_simpleglossar_
pi1[headerList]=R&tx_simpleglossar_pi1[showUid]=159. [Online:
Stand 19. Juli 2007].
Dr. med. Christian Thomeczek. Fehlerquelle Mensch. BERLINER
ÄRZTE, 2001.
Brigitte Hallenberger und Hartmut Rudolf. Tutorial: Farben im
Webdesign.

- 113 -
http://www.metacolor.de/farben/lieblingsfarben.htm. [Online:
Stand 07 August 2007].
[Vli94]
[WK03]
Erich Gamma; Richard Helm; Ralph Johnson; John Vlissides. Design
Patterns: Elements of reusable object oriented software. Addison-
Wesley Publishing Company, 1994.
Wittenbrink, Heinz and Köhler, Werner. XML – Wissen, das sich
auszahlt. Teia Lehrbuch Verlag, 2003.

- 114 -
Arbeitsaufteilung zwischen den Autoren
Die Webanwendung, die Diplomarbeit sowie die einzelnen Dokumentationen
wurden gemeinsam von beiden Autoren entwickelt. Dennoch war jeder einzelne
für bestimmte Aufgaben verantwortlich, oder hat sie zum größten Teil selbstständig
bewältigt. Selbstverständlich gab es dabei auch viele Überschneidungen,
da gerade dem Zusammenspiel und der Verbindung verschiedener Teilergebnisse
große Aufmerksamkeit geschenkt werden musste.
Lars Rönisch
Diplomarbeit
Kapitel 1
Abschnitt: komplett, Seite 9 - 12
Kapitel 2
Abschnitt: komplett, Seite 13 - 24
Kapitel 3
Abschnitt: 3.0, Seite 25
Abschnitt: 3.1, Seite 25 - 27
Abschnitt: 3.2, Seite 28 - 29
Abschnitt: 3.3.5, Seite 33 - 36
Abschnitt: 3.3.6, Seite 36 - 39
Kapitel 5
Abschnitt: 5.0, Seite 59
Abschnitt: 5.1, Seite 59 - 60
Abschnitt: 5.3, Seite 62 - 63
Abschnitt: 5.3.1, Seite 63 - 64
Abschnitt: 5.3.2, Seite 65

- 115 -
Abschnitt: 5.6, Seite 69 - 71
Kapitel 7
Abschnitt: komplett, Seite 74 - 79
Entwicklungsdokumentation
Kapitel 1
Abschnitt: komplett, Seite 3
Kapitel 2
Abschnitt: komplett, Seite 4 - 5
Kapitel 3
Abschnitt: komplett, Seite 6 - 7
Kapitel 4
Abschnitt: 4.5, Seite 22
Abschnitt: 4.6, Seite 22 - 23
Abschnitt: 4.7, Seite 24 - 25
Benutzungsdokumentation
komplett, Seite 4 - 33
Implementierung der Webanwendung
Erstellung des Layouts und der Grafiken
Implementierung der JSP-Files
Implementierung der CSS-Files
Implementierung des XML-Moduls
Meldebogenrepräsentation (xsd)

- 116 -
Implementierung der Helferklassen

- 117 -
Stephan Schnabel
Diplomarbeit
Kapitel 3
Abschnitt: 3.3, Seite 29
Abschnitt: 3.3.1, Seite 29 - 30
Abschnitt: 3.3.2, Seite 31
Abschnitt: 3.3.3, Seite 31 - 32
Abschnitt: 3.3.4, Seite 32 - 33
Abschnitt: 3.4, Seite 39 - 40
Abschnitt: 3.4.1, Seite 40 - 42
Abschnitt: 3.4.2, Seite 42 - 43
Kapitel 4
Abschnitt: komplett, Seite 44 - 58
Kapitel 5
Abschnitt: 5.2, Seite 60 - 61
Abschnitt: 5.4, Seite 65 - 68
Abschnitt: 5.5, Seite 68 - 69
Kapitel 6
Abschnitt: komplett, Seite 72 - 73
Entwicklungsdokumentation
Kapitel 4
Abschnitt: 4.0, Seite 8
Abschnitt: 4.1, Seite 8 - 9
Abschnitt: 4.1.1, Seite 9 - 11

- 118 -
Abschnitt: 4.1.2, Seite 11 - 12
Abschnitt: 4.2, Seite 12 - 13
Abschnitt: 4.3 komplett, Seite 13 - 16
Abschnitt: 4.4 komplett, Seite 16 - 21
Installationsanleitung
komplett, Seite 3 - 10
Implementierung der Webanwendung
Konfiguration von Struts2 sowie der verwendeten Plugins
Mapping mit Hibernate
DataAccessObjects
DataTransferObjekts
Implementierung der Geschäftslogik der einzelnen Module

Eidesstattliche Erklärung
Hiermit erkläre ich, dass ich diese Arbeit selbstständig verfasst und keine anderen
als die angegebenen Quellen und Hilfsmittel benutzt habe.
Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch
noch nicht veröffentlicht.
Görlitz, 14.10.2007
Lars Rönisch

Eidesstattliche Erklärung
Hiermit erkläre ich, dass ich diese Arbeit selbstständig verfasst und keine anderen
als die angegebenen Quellen und Hilfsmittel benutzt habe.
Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch
noch nicht veröffentlicht.
Görlitz, 14.10.2007
Stephan Schnabel