Konzeption und Realisierung eines generischen Export-Moduls für interdisziplinäre Forschungsdatenbanken [original]

Universität Ulm | 89069 Ulm | Germany Fakultät für

Ingenieurwissenschaften,

Informatik und Psychologie

Institut für Datenbanken

und Informationssysteme

Konzeption und Realisierung eines

generischen Export-Moduls für

interdisziplinäre Forschungsdatenbanken

Masterarbeit an der Universität Ulm

Vorgelegt von:

Andreas Rein

[email protected]

Gutachter:

Prof. Dr. Manfred Reichert

Dr. Rüdiger Pryss

Betreuer:

Michael Stach

2017

Fassung 15. Oktober 2017

2017 Andreas Rein

This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0

License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/de/

or send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California,

94105, USA.

Satz: PDF-L

TEX2ε

Kurzfassung

Moderne Informations- und Kommunikationstechnologien spielen bei der Diagnose, Be-

handlung, Überwachung und Verwaltung von Patienten eine stetig wachsende Rolle. Die

allgemeine Verfügbarkeit mobiler Endgeräte in der Bevölkerung eröffnet neue Chancen für

ein deutlich stärkeres Wachstum der Datenbestände in patientenorientierten Forschungs-

datenbanken. Mittels spezifischer Apps und Webanwendungen kann, sowohl im statio-

nären als auch im mobilen Umfeld, eine komfortable und effiziente Eingabe bei gleichblei-

bender oder verbesserter Datenqualität erreicht werden. Diese und weitere Entwicklungen

steigern die Wertigkeit der erfassten Daten und der begleitenden wissenschaftlichen Pu-

blikationen. Die systematische und regelmäßige Auswertung der erfassten Daten bietet

somit ein großes Potential für neue Erkenntnisse, die Verbesserung bestehender und die

Entwicklung neuer Behandlungsmethoden.

Die im Jahr 2006 gegründete gemeinnützige Tinnitus Research Initiative hat sich dem

besseren Verständnis des Tinnitus aurium (lat. für „Klingeln in den Ohren“, kurz Tinnitus)

und der Entwicklung von effektiveren Behandlungsmethoden verschrieben. Sie verfolgt

einen Ansatz zur systematischen Erfassung von Patienten in klinischen Zentren mit stan-

dardisierten Instrumenten wie psychoakustischen Messungen und Fragebögen. Die Spei-

cherung der Patientendaten der Tinnitus Research Initiative erfolgt in der sogenannten

Tinnitus Database, in der bereits mehr als 4700 Patienten aus weltweit zwölf Zentren

verwaltet werden. Einer der wesentlichen Beweggründe für die zentrale Erfassung von

Patienten-, Behandlungs- und Studiendaten ist das Bestreben den Umfang und die Aus-

sagekraft der abgeleiteten wissenschaftlichen Auswertungen und Publikationen zu erhö-

hen.

Das primäre Ziel dieser Arbeit ist es Modelle, Vorgehensweisen und Konzepte zu erar-

beiten, zu erproben und zu diskutieren, die dazu geeignet sind Forschungsdatenban-

ken zu analysieren und deren Daten abzufragen. Es soll hierzu geprüft werden wie die

Möglichkeiten zur Verarbeitung und Auswertung der Daten erweitert und ergänzt werden

können. Das praktische Ziel dieser Arbeit ist es ein Software-Modul zu spezifizieren, zu

entwerfen und umzusetzen, dass Domänenexperten bei der Identifikation, Auswahl und

Filterung von Daten unterstützt. Der Nachweis der Tragfähigkeit der erarbeiteten Ergeb-

iii

nisse wird anhand einer exemplarischen Realisierung für die Tinnitus Database geführt,

die erarbeiteten Konzepte und Lösungen können jedoch ebenso auf vergleichbare For-

schungsdatenbanken übertragen werden. Das realisierte Modul soll Domänenexperten

ein benutzerfreundliches System zur Definition und Durchführung von Datenexporten bie-

ten und somit die Erstellung von umfangreichen und differenzierten wissenschaftlichen

Auswertungen erleichtern.

Diese Arbeit eröffnet somit neue Möglichkeiten Patientendaten mit Verfahren und Werk-

zeugen für statistische Berechnungen, Visualisierungen und Analysen auswerten zu kön-

nen. Die exemplarische Realisierung des Export-Moduls für die Tinnitus Database konnte

in stetiger direkter Zusammenarbeit mit den Domänenexperten der Tinnitus Research

Initiative kritisch diskutiert und umgesetzt werden. Sie erlaubt es der TRI zukünftig um-

fangreichere und aussagekräftigere Auswertungen und Publikationen zu erstellen und so-

mit im Bereich der Erforschung und Behandlung von Tinnitus führend zu bleiben. Es wur-

den außerdem Synergieeffekte für andere Forschungsdatenbanken wie die der European

School for Interdisciplinary Tinnitus Research (ESIT) aufgezeigt. Es handelt sich dabei

um ein von der Europäischen Union gefördertes Projekt zur Verbesserung bestehender

und Entwicklung neuer Behandlungsmethoden für Tinnitus.

Der modulare Aufbau der Tinnitus Database und die generische Realisierung des Export-

Moduls sollen zur schnellen Wiederverwendbarkeit und dem langfristigen Erfolgt der vom

Team des Instituts für Datenbanken und Informationssysteme der Universtät Ulm und des

Lehrstuhls für Psychiatrie und Psychotherapie an der Universität Regensburg entwickel-

ten Plattformen beitragen. Diese Arbeit dient zwar dem besseren Verständnis und der

Entwicklung von effektiveren Behandlungsmethoden im Bereich des Tinnitus, die erarbei-

teten, erprobten und diskutierten Modelle, Vorgehensweisen und Konzepte können aber

auch in der Erforschung und Behandlung anderer Leiden Wiederverwendung finden.

Danksagung

Mein tiefster Dank gilt all denjenigen, die diese Arbeit und die damit verbundenen

Wünsche und Hoffnungen ermöglicht und unterstützt haben.

Besonders möchte ich Herrn Prof. Dr. Manfred Reichert für die Begutachtung dieser

Arbeit und auch dafür danken, dass er die Durchführung am Institut für Datenbanken und

Informationssysteme der Universität Ulm ermöglicht und unterstützt hat. Michael Stach

möchte ich für die ausgesprochen engagierte Betreuung und die ebenso gute

Zusammenarbeit danken. Außerdem möchte ich mich bei Herrn Dr. Winfried Schlee für

das Einbringen seiner Kompetenz und Arbeitskraft als Mediziner, Fachanwender und

Koordinator bedanken.

Mein besonderer Dank gilt Herrn Dr. Rüdiger Pryss für die Begutachtung dieser Arbeit

und seinen intensiven, geduldigen und motivierenden Einsatz während meines gesamten

Masterstudiums.

Ich möchte mich zudem bei den vielen Korrekturlesern,Kommilitonen,Freunden und

Bekannten bedanken die mich sowohl im Laufe der Ausarbeitung dieser Abschlussarbeit,

als auch während der lehrreichen und schönen Studienjahre unterstützt und begleitet

haben.

Den größten Dank schulde ich meiner Frau Sarah, die mir immer zur Seite stand und ohne

deren pausenlose Unterstützung diese Arbeit niemals entstanden wäre.

Abschließend möchte ich meinen Eltern für ihre Weisheit und ihren immerwährenden

Einsatz in allen Lagen und bei allen Dingen des Lebens danken.

Inhaltsverzeichnis

1 Einleitung 1

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Grundlagen 7

2.1 Tinnitus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Definition und Klassifikation . . . . . . . . . . . . . . . . . . . . . . 7

2.1.2 Ursachen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.3 Pathophysiologie . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1.4 Diagnose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1.5 Prävention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1.6 Therapie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1.7 Epidemiologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2 TRI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.1 Tinnitus-Database . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2.2 Tinnitus-Flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2.3 Fragebögen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3 Related Work 25

3.1 Visuelle Abfrage Editoren . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Generische Programmierkonzepte . . . . . . . . . . . . . . . . . . . . . . 27

3.3 Codegeneratoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

vii

Inhaltsverzeichnis

4 Anforderungsanalyse 31

4.1 Ist-Stand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1.1 Ablauf einer Patientenstudie . . . . . . . . . . . . . . . . . . . . . 32

4.1.2 Gliederungsebenen . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.1.3 Datenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2 Soll-Stand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2.1 Soll-Prozess der Export-Konfiguration . . . . . . . . . . . . . . . . 39

4.2.2 Soll-Prozess der Export-Generierung . . . . . . . . . . . . . . . . 42

4.3 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.3.1 Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . 46

4.3.2 Nicht-Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . 52

5 Entwurf 55

5.1 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.1.1 Ansicht und Erstellung von Konfigurationen . . . . . . . . . . . . . 56

5.1.2 Bearbeitung von Konfigurationen . . . . . . . . . . . . . . . . . . . 56

5.1.3 Export-Generierung . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.2 Datenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6 Ausgewählte Implementierungsaspekte 71

6.1 Generische Programmierkonzepte . . . . . . . . . . . . . . . . . . . . . . 71

6.1.1 Code-Generierung . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6.1.2 Dynamische Ausführung von generiertem Code . . . . . . . . . . . 73

6.1.3 Informationen zum Datenmodell . . . . . . . . . . . . . . . . . . . 75

6.2 Technische Limitationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6.2.1 Maximale Anzahl von Spalten . . . . . . . . . . . . . . . . . . . . 78

6.2.2 Maximale Anzahl von Joins . . . . . . . . . . . . . . . . . . . . . . 80

7 Anforderungsabgleich 85

7.1 Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 85

7.2 Nicht-Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . 87

8 Zusammenfassung und Ausblick 89

8.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

viii

Inhaltsverzeichnis

8.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

8.2.1 Mögliche Anpassungen am Datenmodell . . . . . . . . . . . . . . 91

8.2.2 Zukunft der Tinnitus Database . . . . . . . . . . . . . . . . . . . . 92

Literaturverzeichnis 95

1 Einleitung

In diesem Kapitel wird zunächst die Motivation für die Erfassung von Patienten in

interdisziplinären Forschungsdatenbanken skizziert. Die sich bei der Auswertung und dem

Export von Patientendaten ergebenden Problemstellungen werden exemplarisch anhand

eines multinationalen und interdisziplinären Datenbankprojektes erörtert. Die mit dieser

Arbeit verfolgten Ziele werden schließlich begründet und festgelegt. Das Kapitel schließt

mit einer Erläuterung zum Aufbau und den internen Zusammenhängen dieser Arbeit.

1.1 Motivation

Moderne Informations- und Kommunikationstechnologien spielen bei der Diagnose, Be-

handlung, Überwachung und Verwaltung von Patienten eine stetig wachsende Rolle. Die

allgemeine Verfügbarkeit mobiler Endgeräte in der Bevölkerung eröffnet neue Chancen für

ein deutlich stärkeres Wachstum der Datenbestände in patientenorientierten Forschungs-

datenbanken. Mittels spezifischer Apps und Webanwendungen kann, sowohl im statio-

nären als auch im mobilen Umfeld, eine komfortable und effiziente Eingabe bei gleichblei-

bender oder verbesserter Datenqualität erreicht werden [55]. Diese und weitere Entwick-

lungen steigern die Wertigkeit der erfassten Daten und der begleitenden wissenschaft-

lichen Publikationen. Die systematische und regelmäßige Auswertung von Forschungs-

datenbanken bietet somit ein großes Potential für neue Erkenntnisse, die Verbesserung

bestehender und die Entwicklung neuer Behandlungsmethoden.

Ein Leiden, dass die Lebensqualität einer wachsenden Anzahl von Betroffenen in teil-

weise erheblichem Maße beeinträchtigt, ist der sogenannte Tinnitus. Die medizinische

Bezeichnung Tinnitus aurium (lat. für „Klingeln in den Ohren“) bezeichnet die Wahrneh-

1 Einleitung

mung von Geräuscheindrucken denen keine externe Schallquelle zugrunde liegt. Der Ur-

sprung der wahrgenommenen Geräusche liegt also stets im Betroffenen selbst, wobei

eine Vielzahl von physischen oder psychischen Störungen ursächlich sein können. Allein

in Deutschland sind bereits 1,5 Millionen Menschen von Tinnitus betroffen und jährlich

kommen 250.000 neue Fälle von chronischem Tinnitus hinzu [42]. Tinnitus ist ein Phäno-

men das viele Menschen bereits einmal erlebt haben. Zahlreiche durchgeführte Studien,

die keine schlüssigen Ergebnisse liefern konnten, weisen darauf hin, dass die Erfolgs-

aussichten unterschiedlicher Behandlungsoptionen von Patient zu Patient stark variieren

können [54]. Die Wahl der erfolgversprechendsten Vorgehensweise für einen bestimmten

Patienten kann daher als eine der wesentlichen Herausforderung bei der Behandlung und

Erforschung von Tinnitus genannt werden.

Die im Jahr 2006 gegründete gemeinnützige Tinnitus Research Initiative hat sich dem

besseren Verständnis des Tinnitusleidens und der Entwicklung von effektiveren Behand-

lungsmethoden verschrieben. Sie verfolgt einen Ansatz zur systematischen Erfassung von

Patienten in klinischen Zentren mit standardisierten Instrumenten wie psychoakustischen

Messungen und Fragebögen [58]. Die systematische Erfassung der Patientendaten der

Tinnitus Research Initiative erfolgt in der sogenannten Tinnitus Database, in der bereits

mehr als 4700 Patienten aus weltweit zwölf Zentren verwaltet werden.

Die Tinnitus Database eignet sich aufgrund ihrer hohen Reife, der Verwendung gängiger

Technologien, wie des relationalen Datenbank Management Systems MySQL1, und des

realen Datenbestandes um Problemstellungen und Zielsetzungen zu diskutieren die sich

bei der Erfassung und dem Export von Patientendaten ergeben können.

1MySQL ist ein schnelles, robustes, relationales Datenbank Management System (RDBMS) [64]

1.2 Problemstellung

Einer der wesentlichen Beweggründe für die zentrale Erfassung von Patienten-, Behand-

lungs- und Studiendaten ist das Bestreben den Umfang und die Aussagekraft der abge-

leiteten wissenschaftlichen Auswertungen und Publikationen zu erhöhen. Die Auswertung

von Forschungsdatenbanken kann beispielsweise mit spezifischen statistischen Verfahren

und entsprechenden Werkzeugen und Programmiersprachen wie R2und SPSS3erfolgen.

Es ist bei diesen und anderen Werkzeugen und Programmiersprachen zwar üblicherweise

technische möglich relationale Datenbanksysteme als Datenquellen einzubeziehen, aller-

dings kann es dennoch zu Problemen bei der Identifikation, Auswahl und Filterung von

relational verwalteten Daten kommen. Diese sollen exemplarisch anhand der interdiszipli-

nären Tinnitus Database erörtert werden.

Die Tinnitus Database wird von einem Team des Instituts für Datenbanken und Informati-

onssysteme der Universtät Ulm und des Lehrstuhls für Psychiatrie und Psychotherapie an

der Universität Regensburg entwickelt und betreut. Das System umfasst ein relationales

Datenbankmanagement System zur Speicherung und eine modulare Weboberfläche zur

Eingabe, Pflege und Einsicht der Daten. Der modulare Aufbau erleichtert die Erweiterung

um neue Funktionalitäten und ermöglicht somit eine stetige Weiterentwicklung des Sys-

tems bei neuen oder sich ändernden Anforderungen. Das System eignet sich somit um

Problemstellungen und Zielsetzungen im Umfeld interdisziplinärer Forschungsdatenban-

ken zu diskutieren.

Einer der entscheidenden Gründe für die Erfassung der Patientendaten der Tinnitus

Research Initiative in einer zentralen Datenbank ist der Wunsch diese mit Verfahren und

Werkzeugen für statistische Berechnungen, Visualisierungen und Analysen auswerten zu

können. Das medizinische und wissenschaftliche Fachpersonal, im Folgenden als Do-

mänenexperten bezeichnet, ist mit den Abläufen und Zusammenhängen innerhalb der

Tinnitus Database, allerdings nicht mit dem zugrundeliegenden relationalen Schema oder

der Abfragesprache SQL vertraut. Ein vollständiger Zugriff auf die Datenbank über das

Internet ist überdies aus verschiedenen Gründen abzulehnen. Dieser ist bisher nicht not-

2R ist eine freie Softwareumgebung für statistische Berechnungen und Visualisierungen [57].

3SPSS ist ein weit verbreitetes Computerprogramm zur Untersützung der statistischen Analyse von Daten,

insbesondere von Daten die im Zuge von Forschungsarbeit gesammelt wurde [7].

1 Einleitung

Domänenexperten Tinnitus Database

PatientendatenServeranwendung

Zwölf Zentren

Tinnitus Research Initiative

Internet

Abbildung 1.1: Tinnitus Research Initiative und Tinnitus Database

wendig, da alle Zugriffe auf die Patientendaten rein serverseitig erfolgen und ist aus Grün-

den der Datensicherheit auch weiterhin nicht erwünscht. Abbildung 1.1 veranschaulicht

dies.

Soll eine neue Auswertung durchgeführt werden, so wird bisher eine Anfrage an die Mit-

glieder des TRI-Teams an der Universität Ulm formuliert, die diese in eine SQL-Abfrage

umsetzen. Der erhebliche manuelle Aufwand, die zeitliche Verzögerung und eine gewisse

Fehleranfälligkeit sind als wesentliche Schwachpunkte dieser Vorgehensweise zu nennen.

Es erscheint aufgrund der identifizierten Schwachstellen lohnenswert zu prüfen ob die

Tinnitus Database um ein Modul erweitert werden kann, dass die Domänenexperten bei

der Identifikation, Auswahl, Filterung und dem Export von Daten unterstützt.

1.3 Zielsetzung

Das primäre Ziel dieser Arbeit ist es Modelle, Vorgehensweisen und Konzepte zu erar-

beiten, zu erproben und zu diskutieren, die dazu geeignet sind Forschungsdatenbanken

zu analysieren und deren Daten abzufragen. Es soll hierzu geprüft werden wie die Mög-

lichkeiten von Domänenexperten zur Verarbeitung und Auswertung von Daten erweitert

und ergänzt werden können. Es soll gezeigt werden, wie ein Software-Modul spezifiziert,

entworfen und umgesetzt werden kann, dass Domänenexperten bei der Identifikation,

Auswahl und Filterung relationaler Daten unterstützen kann. Der Nachweis der Tragfähig-

keit der erarbeiteten Ergebnisse soll anhand dieser exemplarischen Realisierung geführt

werden.

1.3 Zielsetzung

Das praktische Ziel dieser Arbeit ist somit die Konzeption und Realisierung eines gene-

rischen Moduls zum Export der Patientendaten der Tinnitus Research Initiative. Es soll

exemplarisch für die Tinnitus Database realisiert werden, die erarbeiteten Konzepte und

Lösungen sollen jedoch ebenso auf vergleichbare Forschungsdatenbanken übertragen

werden können. Das zu entwickelnde Modul soll Domänenexperten ein benutzerfreund-

liches System zur Definition und Durchführung von Datenexporten bieten und somit die

Erstellung von umfangreichen und differenzierten wissenschaftlichen Auswertungen er-

leichtern. Das Modul soll die Domänenexperten hierzu bei der Identifikation, Auswahl und

Filterung der zu exportierenden Daten unterstützen. Es ist dabei, im Sinne einer mög-

lichst kurzen Einarbeitungszeit, auf der einen Seite wünschenswert, eine möglichst hohe

Ähnlichkeit zu den bereits vorhandenen relevanten Bestandteilen und Abläufen der For-

schungsdatenbank zu erreichen. Es ist auf der anderen Seite wünschenswert, dass po-

tentielle Änderungen keine oder nur geringe Anpassungen an der Implementierung des

Moduls erforderlich machen. Es sollen daher bei der Konzeption und Realisierung geeig-

nete generische Ansätze und Lösungen erarbeitet und dokumentiert werden. Eine intensi-

ve Kooperation mit Domnänenexperten der Tinnitus Research Initiative soll sicherstellen,

dass das Export-Modul praxistaugliche Lösungen für die identifizierten und weitere Pro-

blemstellungen liefert.

Es soll abschließend geprüft werden, ob die in dieser Arbeit erarbeiteten, erprobten und

diskutierten Modelle, Vorgehensweisen und Konzepte dazu geeignet sind Forschungs-

datenbanken zu analysieren und deren Daten zu exportieren. Die exemplarische Rea-

lisierung des Export-Moduls soll bewertet und in den Kontext aktueller und zukünftiger

Entwicklungen im Bereich der Tinnitus Database und der Tinnitus Research Initiative ein-

geordnet werden.

Die Erfüllung der genannten Ziele soll die systematische und regelmäßige Abfrage von

Patienten-, Behandlungs- und Studiendaten aus Forschungsdatenbanken vereinfachen

und somit den Umfang und die Aussagekraft der abgeleiteten Auswertungen und Publi-

kationen erhöhen. Es sollen dadurch langfristig neue Erkenntnisse und idealerweise die

Verbesserung von bestehenden und die Entwicklung neuer Behandlungsmethoden für ei-

ne Vielzahl von Leiden ermöglicht werden.

1 Einleitung

1.4 Aufbau der Arbeit

Diese Arbeit lässt sich in acht Kapitel gliedern. In Kapitel 2 werden die zum Verständ-

nis der Arbeit relevanten Grundlagen betrachtet. Es werden dabei zunächst wesentliche

Begriff der Erforschung und Behandlung von Tinnitus und der im Rahmen der Tinnitus

Research Initiative erfassten Daten erörtert.

In Kapitel 3 werden Arbeiten gesucht und geprüft die Modelle, Vorgehensweisen oder

Konzepte für die Analyse von Datenbanken beitragen oder anregen können. Es sollen

dadurch Erkenntnisse über Anforderungen und Problemstellungen des Exports von Daten

aus relationalen Forschungsdatenbanken gewonnen werden.

Die während der Anforderungsanalyse gewonnen Erkenntnisse werden in Kapitel 4 doku-

mentiert. Es werden hierzu zunächst die relevanten Bestandteile und Abläufe der Tinnitus

Database benannt und beschrieben. Darauf aufbauend werden Soll-Prozesse für das

Export-Modul entworfen und die dabei identifizierten funktionalen und nicht-funktionalen

Anforderungen an das Export-Modul definiert und priorisiert.

Der Entwurf des Export-Moduls erfolgt in Kapitel 5 auf Grundlage der während der Anfor-

derungsanalyse gewonnen Erkenntnisse. Der Aufbau und die Komponenten des Export-

Moduls werden dabei sukzessive erarbeitet und beschrieben.

In Kapitel 6 werden schließlich ausgewählte Aspekte der Implementierung vorgestellt und

diskutiert. Es wird dabei insbesondere auf generische Konzepte eingegangen die eine

Erweiterbarkeit und Übertragbarkeit des Export-Moduls ermöglichen.

Eine Beurteilung der Umsetzung bezüglich der identifizierten Anforderungen erfolgt in

Kapitel 7. Die funktionalen und nicht-funktionalen Anforderungen werden einzeln abge-

glichen und bewertet.

Die Arbeit wird in Kapitel 8 mit einer Zusammenfassung und einem Ausblick auf potenti-

elle zukünftige Anpassungen und Erweiterungen der Tinnitus Database abgeschlossen.

2 Grundlagen

Die in diesem Kapitel beschriebenen grundlegenden, medizinischen und organisatori-

schen Begriffe dienen der Schaffung einer einheitlicher Definition für diese Arbeit. Kapitel

2.1 beschäftigt sich diesbezüglich mit der Definition und Klassifikation von Tinnitus. Da-

von ausgehend werden einige Ursachen für Tinnitus genannt und die Pathophysiologie

beschrieben. Auf Prävention, mögliche Therapie und die Epidemiologie wird nachfolgend

eingegangen. Die Tinnitus Research Initiative wird in Kapitel 2.2 eingeführt. Die von den

Zentren der Tinnitus Research Initiative verwendeten Tinnitusfragebögen werden geson-

dert in Abschnitt 2.2.3 benannt.

2.1 Tinnitus

Tinnitus, das sogenannte Klingeln in den Ohren, ist ein Symptom das unter Umständen

großen Einfluss auf die Lebensqualität des Betroffenen hat. Allein in Deutschland sind

bereits 1,5 Millionen Menschen betroffen und jährlich kommen 250.000 neue Fälle von

chronischem Tinnitus hinzu [42]. Tinnitus ist ein Phänomen das viele Menschen bereits

einmal erlebt haben. Eine Heilung ist allerdings nur in den wenigsten Fällen möglich. Die

Behandlungsmöglichkeiten sind vielfältig und zeigen gute Ergebnisse. Im nachfolgenden

werden die Ursachen, Diagnostik und Behandlung von Tinnitus erläutert. Zusätzlich wird

auf die Aspekte Pathophysiologie und Epidemiologie eingegangen.

2.1.1 Definition und Klassifikation

Der Begriff Tinnitus aurium oder kurz Tinnitus (lat. für „Klingeln in den Ohren“) bezeichnet

ein Symptom, bei dem Betroffene Geräusche ohne die Präsenz einer tatsächlich vorhan-

2 Grundlagen

den Geräuschquelle wahrnehmen. Tinnitus kann in verschiedene Dimensionen differen-

ziert werden. Diese sind in Tabelle 2.1 aufgeführt.

Eine Unterteilung erfolgt zwischen dem objektiven und subjektiven Tinnitus. Beim objekti-

ven Tinnitus erfolgt eine Wahrnehmung einer in der Nähe des Innenohrs gelegenen kör-

pereigene Schallquelle. Im Gegensatz liegt beim subjektiven Tinnitus eine fehlerhafte In-

formationsverarbeitung im Hörsystem vor. Diese Form tritt deutlich häufiger auf als der

objektive Tinnitus [6].

Tinnitus wird auch auf einer zeitlichen Ebene in den akuten, subakuten und chronischen

Tinnitus klassifiziert. Die zeitliche Einteilung erfolgt bisher nach Erfahrungswerten, wobei

von einem akuten Tinnitus gesprochen wird, wenn dieser bis zu drei Monate andauert.

Dauert der Tinnitus länger als drei Monate an so wird dieser als subakut bezeichnet.

Persistiert der Tinnitus länger als sechs Monate so wird er als chronisch bezeichnet [16].

Tinnitus wird unterschiedlich von den Betroffenen wahrgenommen. Es erfolgt daher oft-

mals eine Einteilung in Höreindrücke und Intensitäten. Der Tinnitus kann dabei in einem

oder beiden Ohren auftreten und als Pfeifen, Rauschen, Sausen, Surren oder Piepen

wahrgenommen werden. Ebenso können laute, leise, hoch- oder tieffrequente Töne er-

lebt werden [37]. Zur Beschreibung des Tinnitus dienen neben der Art des Geräusches

und dem Frequenzbereich auch das zeitliche Muster, die subjektive Lautstärke und die

Konstanz des Geräusches [17].

Eine weitere Einteilung erfolgt im Bezug auf die Auswirkung auf die Lebensqualität. Es

wird dabei von einem kompensierten oder dekompensierten Tinnitus gesprochen [16].

Tinnitus wird nach ICD-10 als “Krankheiten des Ohres und des Warzenfortsatzes“ klas-

sifiziert. Im Speziellen in die Gruppe H90-95 “Sonstige Krankheiten des Ohres“. Tinnitus

entspricht der Notation H93.1 [11].

2.1.2 Ursachen

Tinnitus ist ein Symptom für eine Störung im auditorischen System, das heißt den Ohren,

dem auditorischen Nerv, der das innere Ohr mit dem Gehirn verbindet und Teilen des

Gehirns, welche Geräusche verarbeiten. Die Ursachen des Tinnitus sind sehr vielfältig.

2.1 Tinnitus

Beschreibungsebenen Ausprägungen des Tinnitus

Lokalisation Rechtes Ohr

Linkes Ohr

Beide Ohren

Im Kopf

Art des Geräusches Ton

Rauschen

Anderes Geräusch

Frequenzbereich Tief

Mittel

Hoch

Zeitmuster Rhythmisch

Pochend

Gleichförmig

Subjektive Lautstärke

(nach Klockhoff u. Lindblom 1967)

Hörbar nur bei Stille

Hörbar bei geringen Umgebungsgeräuschen,

maskierbar durch gewöhnlichen Lärm oder

Konzentration

Permanent hörbar bei normalen Umgebungs-

geräuschen, auch bei Konzentration

Variabilität der Lautstärke Gleichbleibend

Schwankend

Konstanz des Tinnitus Ständig vorhanden

Kurze Phasen ohne Tinnitus

Ganze Tage ohne Tinnitus

Tabelle 2.1: Verschiedene Differenzierungen von Tinnitus [63]

2 Grundlagen

Es wird zwischen einem objektiven und subjektiven Tinnitus unterschieden. Dies ist vor

allem für das therapeutische Vorgehen relevant, da Ursachen kategorisch voneinander

getrennt werden können. Tinnitus selbst ist oft Ursache für ernsthafte mentale und emo-

tionale Erkrankungen. So können bei Menschen, die unter Tinnitus leiden, Depressionen,

Probleme mit dem Gedächtnis und der Konzentration entstehen [37].

Ursachen subjektiver Tinnitus

Die Ursachen für den subjektiven Tinnitus können von einem Fremdkörper, der den Ge-

hörgang blockiert, bis hin zu einem Gehirntumor reichen. Bei lang andauernden Einwir-

kung von Geräuschen können kleine Sensoren in den Haarzellen im inneren Ohr geschä-

digt werden, die dabei helfen Töne an das Gehirn zu übertragen. Dies tritt vor allem bei

Menschen auf, die in lautstarken Umgebung arbeiten, wie Handwerker oder auch Musi-

kanten. Eine Schockwelle einer Explosion kann den Schädel quetschen und dabei Scha-

den am Gehirngewebe verursachen. Darüber hinaus kann Tinnitus ein erstes Anzeichen

für den Gehörverlust im Alter sein. Mehr als 200 verschiedene Drogen können ebenfalls

Tinnitus sowohl bei Beginn der Einnahme als auch bei dem Entzug verursachen. Oftmals

tritt Tinnitus auch idiopatisch auf [37].

Mögliche Ursachen des subjektiven Tinnitus sind

•Fremdkörper im Gehörgang (z. B. Pfropfen aus Ohrenschmalz) [9]

•Knalltrauma

•Entzündungen des Ohrs

•Otitis media (Mittelohrentzündung)

•Otitis externa

•Mittelohrerkrankungen mit Störung der Schallübertragung (z. B. Otosklerose)

•Virale und bakterielle Infekte (z. B. Borreliose)

•Schalltrauma (akut oder chronisch)

•Hörsturz

•Tauchunfälle

2.1 Tinnitus

•Dekompressionskrankheit

•Barotrauma

•Morbus Menière

•Costen-Syndrom

•Hydrops cochleae

•Endolymphschwankungen

•Autoimmunerkrankungen des Innenohrs

•Ototoxische Substanzen

•Akustikusneurinom (ein Tumor der Gehörnerven)

•Bogengangsdehiszenz

•Schwerhörigkeit/Hypakusis (Tinnitus als Phantomschmerzäquivalent bei sensori-

scher Deprivation) [60]

•Arzneimittel, z. B. Loratadin [3]

•Craniomandibuläre Dysfunktion (CMD)

Ursachen objektiver Tinnitus

Beim objektiven Tinnitus wird ein Ohrgeräusch wahrgenommen, welches von einer realen

Schallquelle erzeugt wird. Die Ursachen dafür können vaskuläre oder muskuläre Prozesse

und auch atemabhängige Geräusche sein [37].

Mögliche Ursachen für den objektiven Tinnitus sind

•Gefäßmissbildungen

•Gaumensegelnystagmus

•Tubenfunktionsstörungen

•Bluthochdruck

•Otoakustische Emissionen

2 Grundlagen

2.1.3 Pathophysiologie

Die Theorie, dass Tinnitus eine Erkrankung des Innenohrs ist, kann heute nicht mehr

aufrecht erhalten werden. Es erfolgte auf Grund dieser Annahme in einigen Fällen eine

Durchtrennung des Hörnerven. Der Tinnitus blieb jedoch bestehen, was die Bedeutung

des zentralen Nervensystems für die Pathophysiologie des chronischen Tinnitus aufzeigt

[23]. Dem Tinnitus liegt, wie heutzutage bekannt, eine gesteigerte Erregung entlang der

gesamten zentralen auditorischen Bahn zugrunde. Ähnlich wie bei Phantomschmerzen

entsteht Tinnitus als kompensatorische Reaktion auf die in den meisten Fällen vorhan-

dene Hörminderung [39] [51] [71]. In klinischen Untersuchungen zeigte sich das auch

Halswirbelsäulen- und Kiefergelenkschmerzen Tinnitus verursachen können [61] [28] [50].

Bei Patienten mit chronischem Tinnitus zeigen sich zusätzlich zu den funktionellen Verän-

derungen in den auditorischen Strukturen auch Veränderungen in limbischen, parietalen

und frontalen Arealen [53] [1] [26]. Im Gegensatz zu gesunden Patienten stehen diese

Regionen in intensiverer funktioneller Verbindung zur Hörrinde [53] [52].

Etabliert hat sich zum jetzigen Zeitpunkt ein dreistufiges Konzept zur Tinnituspathophy-

siologie [17], basierend auf der anatomischen Unterteilung des Hörsystems in folgende

Abschnitte:

•Äußeres Ohr mit Ohrmuschel und Gehörgang,

•Mittelohr mit Trommelfell, Gehörknöchelchen und Warzenfortsatz sowie Tube,

•Innenohr mit Hörsinneszellen und Gleichgewichtsapparat,

•Retrokochleärbereich mit Hörnerven und zentraler Hörbahn

2.1.4 Diagnose

Die Tinnitusdiagnostik gliedert sich in die Schritte Anamnese, HNO-ärztliche Untersu-

chung, audiometrische Untersuchung, psychoakustische Diagnostik und psychometrische

Diagnostik, die im folgenden näher beschrieben werden.

2.1 Tinnitus

Anamnese

Der Begriff „Anamnese“ stammt aus dem Griechischen und bedeutet „Erinnerung“. Es

bezeichnet dabei das Gespräch zwischen dem Patienten und dem Arzt. Während die-

ses Gesprächs werden dem Patienten Fragen zu Erkrankungen gestellt, um mögliche

Hinweise zur Entstehung des Ohrgeräusches, den Einflussfaktoren und den Sekundär-

symptomen zu bekommen. Für diese Anamnese stehen verschiedene wissenschaftlich

evaluierte Fragenkataloge und Fragebögen zur Verfügung [47].

HNO-ärztliche Untersuchung

Die HNO-ärztliche Untersuchung umfasst eine Otoskopie sowie die Untersuchung des

Nasopharynx und der Tube. Die Auskulkation des Gehörgangs, des Mastoids und der

Halsweichteile ist notwendig, um objektive Ohrgeräusche zu erfassen [17].

Audiometrische Untersuchung

Das Ziel der audiometrischen Untersuchung besteht darin den Ort und Schweregrad einer

begleitenden Hörstörung sowie die Schädigung von Haarzellen zu ermitteln. Gegebenfalls

dient es der Abklärung von Hinweisen auf einen objektiven Tinnitus. Die audiometrische

Untersuchung umfasst dabei die Tonaudiometrie, otoakustische Emissionen, Hirnstam-

maudiometrie und die Impedanzaudiometrie/Tympanometrie [63].

Psychoakustische Diagnostik

Das Ohrgeräusch wird durch die Tinnituscharakterisierung genau differenziert. Dies er-

folgt durch Bestimmung der Hauptfrequenz (Matching) und der Bestimmung der Tinnitus-

maskierung mit Angabe des minimalen Maskierungslevels (MML). Außerdem wird eine

Maskierungskurve nach Feldmann erstellt. Die residuale Inhibition kann als Dauer der

Nachwirkung eines Maskierungseffekts bestimmt werden [17].

Psychometrische Diagnostik

Zwischen der subjektiv angegeben Tinnituslautheit und der psychoakustische bestimmten

Intensität des Tinnitus in Dezibel (über der Hörschwelle) können Diskrepanzen entstehen.

Mit Hilfe von psychometrischen Verfahren lassen sich der subjektive Schweregrad durch

2 Grundlagen

die Verwendung von Fragebögen und visuellen Analogskalen besser bestimmen. Diese

eignen sich ebenfalls gut zur Beurteilung der Therapie wobei eine von der Therapieme-

thode unabhängige Beurteilungsmöglichkeit gegeben wird, die in den Therapiestunde ein-

gesetzt werden sollte [17].

2.1.5 Prävention

Die häufigste Ursache für Tinnitus (subjektiven Tinnitus) ist ein Schaden im inneren Ohr,

der durch Lärm verursacht wurde [12]. Das Vermeiden von übermäßigem Lärm bezie-

hungsweise der Schutz des Gehörs vor lauten Geräuschquellen kann die Wahrscheinlich-

keit des Auftretens von geräusch-induziertem Tinnitus senken. Erholungsphasen für den

Körper und die Reduzierung von Stress können sich ebenfalls positiv auf die Vorbeugung

von Tinnitus auswirken [12].

2.1.6 Therapie

Die Tinnitusbehandlung kann in zwei Kategorien eingeteilt werden. Die Behandlung, die

versucht direkt die Intensität des Tinnitus zu verringern, und die, die versucht dem Patien-

ten zu helfen, mit dem Tinnitus im Alltag umzugehen [37]. Die Wirksamkeit von multimo-

dalen, verhaltenstherapeutisch orientieren Ansätzen konnte dabei wissenschaftlich belegt

werden [63]. Die Auswahl der therapeutischen Maßnahme sollte dabei jedoch im Einzelfall

und in Abhängigkeit vom zeitlichen Verlauf und Schweregrad des Tinnitus erfolgen [63].

Im Folgenden Kapitel werden einige häufig verwendete Verfahren vorgestellt.

Therapie des akuten Tinnitus

Der akute Tinnitus wird primär ohrenärztlich mit vasoaktiven Infusionen behandelt. Die

Erfolgsaussichten zur Beseitigung des Tinnitus sind damit jedoch als eher gering einzu-

schätzen. Andere medikamentöse Behandlungsformen, wie die Behandlung mit Antiar-

rhythmika, Antikonvulsiva oder Kalziumantagonisten, zeigte nur bei einem sehr kleinen

Prozentsatz der Betroffenen Besserung und muss gegen die hohe Nebenwirkungsrate

sowie den ausgeprägten Placeboeffekt abgewogen werden [27]. Bei einem akuten Tin-

nitus ist das sogenannte Counseling zu empfehlen. Dabei wird der Betroffene frühzeitig

2.1 Tinnitus

über den Tinnitus, Ursachen, Verläufe und therapeutische Maßnahmen aufgeklärt. Die

häufig stark ausgeprägten Ängste des Betroffenen vor dem Tinnitus und dessen Folgen

können dabei reduziert werden. Zu diesem Zeitpunkt kann es ebenso hilfreich sein erste

konkrete Verhaltenshinweise zu geben.

Der Einsatz von Psychopharmaka sollte auch bei einem akuten Tinnitus in Betracht ge-

zogen werden, wenn der Patient bereits komorbide Störungen wie Depressionen, Angst-

oder Schlafstörungen zeigt, da diese positive Effekte auf den Tinnitus also auf die beglei-

tenden Symptome haben kann [17]. Bei Vorliegen von Funktionsstörungen der Halswirbel-

säule oder des Kiefergelenks sollte ebenso eine orthopädische Behandlung durchgeführt

werden. Dazu können physiotherapeutische Übungen für die Hals-/Nackenmuskulatur

und die Kiefermuskulatur, Chirotherapie oder auch die Anpassung einer Bissführungs-

schiene gehören [63].

Chronischer Tinnitus

Tinnitus wird als chronisch bezeichnet, wenn er länger als drei Monate anhält. Der Be-

handlungsfokus des chronischen Tinnitus liegt, im Gegensatz zum Akuten, nicht in erster

Linie auf der Verminderung oder Beseitigung des Tinnitus sondern auf der Verringerung

der Tinnitusbelastung [63].

Apparativ-akustische Therapie und Tinnitus-Retraining

Die apparativ-akustische Therapie sieht bei Betroffenen mit einer bestehenden Hörmin-

derung eine Anpassung des Hörgerätes oder den Einsatz eines Tinnitus-Noiser vor. Ein

Tinnitus-Noiser sendet ein gleichmäßiges, breitbandiges Rauschsignal, welches den Tin-

nitus nicht überdeckt, durch die Erhöhung der akustischen Hintergrundaktivität jedoch die

Detektion des Tinnitus erschweren soll. Diese Maßnahmen werden nicht als singuläre

Technik eingesetzt, sondern im Rahmen der Tinnitus-Retraining-Therapie [63].

Entspannungsverfahren und Biofeedback

Entspannungsverfahren, wie beispielsweise die angewandte Entspannung (Öst), die pro-

gressive Muskelentspannung (Hofmann) oder das autogene Training spielen eine große

Rolle um die Tinnitusbelastung des Betroffenen zu verringern. Der Grund zum Einsatz von

2 Grundlagen

Entspannungsverfahren liegt darin, dass Betroffene eine erhöhte psychophysiologische

Erregung aufzeigen, die die Habituation beeinträchtigen. Außerdem wird angenommen,

dass durch die Erlangung von Selbstkontrolle das oft auftretende Gefühl der Hilflosigkeit

bei Tinnituspatienten verringert wird. Entspannungstherapieren können beim Umgang mit

alltäglichen Stresssituationen helfen, da die Stressbewältigungskapazität von Tinnituspati-

enten durch des Stressfaktor Ohrgeräusch schneller überfordert ist. Diese sollten im Rah-

men multimodaler Behandlungstherapieren eingesetzt werden, da die Anwendung als Mo-

noverfahren oft nur geringe Effekte erzielt. Dies gilt ebenso für das Biofeedback. Wird es

unterstützend zu verhaltenstherapeutischen Behandlungen eingesetzt, so kann die Wirk-

samkeit der Behandlung verstärkt werden. Beim Biofeedback wird das Bewusstsein für

die Muskelaktivität gefördert, womit gezielt angespannte Muskelbereiche entspannt wer-

den können. Dies betrifft bei Tinnituspatienten vor allem die Muskelbereiche des Kopfes

und der Schultern [63].

Kognitive Verhaltenstherapie

Kognitive Verhaltenstherapien werden zur Verringerung der Tinnitusbelastung eingesetzt.

Es existieren Programme, die in Einzel- oder Gruppentherapie und im stationären oder

ambulanten Rahmen eingesetzt werden. Zusätzlich wurden selbsthilfeorientierte Behand-

lungsprogramme entwickelt. Dabei werden Informationen und therapeutische Übungen

mit Hilfe von Büchern oder über Onlineprotale vermittelt und eine therapeutische Beglei-

tung über Telefon oder E-Mail angeboten.

Eine Metaanalyse konnte die Wirksamkeit der kognitiv-behavioralen Ansätze zur Verringe-

rung der Tinnitusbelastung nachweisen. Es zeigte sich eine Verringerung der subjektiven

Tinnitusbelastung, eine leichte Verbesserung der emotionalen Befindlichkeit und die Auf-

rechterhaltung der erzielten Veränderungen. Die Behandlung sieht dabei mehrere Schrit-

te vor. Am Beginn wird eine umfassende Psychodiagnositk und eine ausführliche Psy-

choedukation zu Tinnitus, Hörsystem und ätiologischen Faktoren durchgeführt. Außer-

dem wird ein individuelles Störungsmodell des Patienten erstellt. Ein wichtiger Schritt ist

die Erarbeitung von realistischen Zielsetzungen. Es wird dabei mit dem Patienten heraus-

gearbeitet, dass das Ziel darin besteht den Tinnitus zu behandeln, nicht zu heilen. Die

Bearbeitung dysfunktionaler Bewertungen spielt eine wichtige Rolle bei der Behandlung

zur Verringerung der Tinnitusbelastung.

2.2 TRI

Spezifische Coping-Strategien, wie Strategien zu Aufmerksamkeitslenkung, Tinnitusum-

deutung und Verbesserung der Entspannungs- und Konzentrationsfähigkeit, erleichtern

zudem den Umgang mit dem Tinniuts [63].

2.1.7 Epidemiologie

Etwa 30 - 40 % der Bevölkerung kennt das Phänomen Tinnitus, jedoch fühlen sich nicht

alle dadurch beeinträchtigt. Die akustische Qualität und Intensität des Tinnitus ist dabei

jedoch kein hinreichender Parameter für die Abschätzung des Behandlungsbedürftigkeit

und des Leidensdruckes [18]. Etwa 10% der erwachsenen Bevölkerung der USA hatte

Erfahrung mit wenigstens fünf Minuten andauernden Tinnitus im letzten Jahr. Eine Be-

völkerungsbasierte Studie zum Hörverlust im Alter zeigte zudem, dass Erwachsene im

Alter von 48 - 92 eine Tinnitusprävalenz von 8.2% aufzeigen und eine Inzidenz von 5.7%

in den folgenden fünf Jahren [38]. Die Prävalenz für Tinnitus wächst zudem mit zuneh-

mendem Alter [9]. Tinnitus ist vor allem im Erwachsenenalter und in jungen Jahren ein

verbreite Erfahrung. Ältere Daten des MRC Institute of Hearing Research [60] zeigen,

dass in Großbritannien etwa 10% der Erwachsenen Erfahrungen mit länger andauernden

spontan auftretenden Tinnitus haben und in 5% der Fälle wird der auftretende Tinnitus

als störend empfunden. In 1% der Fälle hat der Tinnitus einen erheblichen Effekt auf die

Lebensqualität. In Deutschland leben 1.5 Millionen mittelschwer bis stark Betroffene. Jähr-

lich kommen 250.000 neue chronische Tinnitusfälle hinzu, so besagt eine Studie von PD

Dr. Manfred Pilgramm [35].

2.2 TRI

Die Tinnitus Research Initiative ist eine gemeinnützige Stiftung, die sich zum Ziel gesetzt

hat, die Lebensqualität von Tinnituspatienten zu verbessern. Historisch wurde die Tinni-

tusforschung von Einzelpersonen oder kleinen Gruppen durchgeführt, die meist unabhän-

gig voneinander arbeiteten. Die TRI versucht nun die Zusammenarbeit dieser Gruppen zu

unterstützen, da dies für ein besseres Verständnis von Tinnitus und die Entwicklung von

effektiveren Behandlungen unerlässlich ist [44] [58].

2 Grundlagen

2.2.1 Tinnitus-Database

Tinnitus ist eine häufig auftretende Störung die signifikante Morbidität hervorrufen kann.

Die Behandlung wird dadurch erschwert, dass die verschiedenen Formen von Tinnitus

sich in der Pathophysiologie und deren Reaktion auf die Behandlung stark unterscheiden

können. Die größte Herausforderung in der Behandlung ist demnach die Identifikation der

erfolgversprechendsten Therapie für jeden spezifischen Patienten.

Ein wichtiger Schritt zur Verbesserung und Erleichterung der Behandlung wäre, wenn

therapeutische Entscheidungen sich auf gültigen Prädiktoren für eine mögliche positive

Behandlungsreaktion bei einem einzelnen Patienten stützen könnten. Bisher fehlen sol-

che Prädiktoren weitgehend. Die Bestimmung wird durch die Tatsache behindert, dass die

meisten Behandlungsstudien nur mit wenigen Patienten durchgeführt werden und die Ver-

gleichbarkeit aufgrund unterschiedlich angewandter Methoden in der Tinnitus-Bewertung

und verschiedenen Ausgangsparameter limitiert ist. Klinische Versuche, aufbauend auf

einer standardisierten Methodik und der Zusammenführung von Daten in einer internatio-

nalen Datenbank, können sowohl die klinische Subtypisierung der verschiedenen Tinni-

tusformen, als auch die Identifikation der vielversprechendsten Behandlung erleichtern.

Das Tinnitus Research Initiative Datenbankprojekt ist die erste internationale Kooperation

von spezialisierten Tinnituskliniken, die diesem Ziel folgen. Aktuell nehmen 19 Zentren

aus elf Ländern an diesem Projekt teil. Seit Beginn des Projektes im Sommer 2008 wur-

den über 4700 Tinnitus-Patienten weltweit nach dem TRI Consensus unter Verwendung

des standardisierten Case Report Form (CRF) dokumentiert. Die Ziele des Projekts kön-

nen wie folgt zusammengefasst werden:

•Subtypisierung verschiedener Formen von Tinnitus, basierend auf ihren spezifi-

schen Symptomen und / oder deren Reaktion auf Behandlungsmodalitäten, bei-

spielsweise durch Clusteranalysen

•Identifizierung von Prädiktoren für die Behandlungsreaktion auf spezifische Behand-

lungen

•Beurteilung des Behandlungsergebnisses für spezifische Behandlungen mit einem

modularen Ansatz

•Identifizierung von potentiellen klinischen Merkmalen zur Abgrenzung von neurobio-

2.2 TRI

logisch unterschiedlichen Formen von Tinnitus

•Erläuterung der unterschiedlichen Ergebnisse verschiedener Studien, beispielswei-

se durch die Möglichkeit Unterschiede zwischen den Studienpopulationen zu iden-

tifizieren

•Sammlung epidemiologischer Daten

•Kreuzvalidierung verschiedener Bewertungsinstrumente in verschiedenen Sprachen

•Entwicklung eines individualisierten Behandlungsalgorithmus für jeden einzelnen

Patienten basierend auf dem individuellen Diagnoseprofil

•Abgrenzung von Untergruppen mit ähnlichen Merkmalen und Erstellung von Daten

über die verschiedenen diagnostischen Verfahren

2.2.2 Tinnitus-Flowchart

Tinnitus ist ein Symptom für eine Vielzahl an verschiedenen zugrundeliegenden Patholo-

gien und kann von vielen verschiedenen Komorbiditäten begleitet werden. Dies erschwert

die Leitung und Verwaltung der Tinnitusbehandlung. Aus diesem Grund besteht die Not-

wendigkeit einer umfassenden multidisziplinären Diagnostik. Das TRI Tinniuts Clinic

Network hat dafür im August 2008 das TRI Flowchart for Patient Management auf Grund-

lage einer sorgfältigen Literaturforschung entwickelt. Das Flowchart, wie in Abbildung 2.1

dargestellt, ist ein interaktives freizugängliches PDF, welches dazu beitragen soll die Dia-

gnose und Behandlung von Tinnitus zu unterstützen. Das Flowchart visualisiert ein Vor-

gehensmodell zur Tinnitusbehandlung. Im ersten Schritt zeigt es die Vorgehensschritte

des sogenannten Screenings. Dabei wird beim Patienten eine eingehende Anamnese,

Befragungen mit Hilfe von Fragebögen, eine klinische Untersuchung und audiologische

Messungen durch einen Spezialisten durchgeführt. Diese Schritte sind in weiß darge-

stellt. Mögliche Erstbefunde, beispielsweise die Einordnung des Tinnitus als „pulsatile“

or „non-pulsatile“, können roten Kästen entnommen werden. Es sind darauf aufbauend

weitere Untersuchungen, durch gelbe Kasten visualisiert, vorgesehen. Es ergeben sich

schließlich mögliche Befunde die in blau dargestellt sind und aus denen sich Behand-

lungsmethodiken ableiten lassen können. Während des ganzen Vorgehens ist ein Coun-

celling vorgesehen.

2 Grundlagen

‐

Carotidstenosis

‐

Aneurysm

‐

Arteriovenous

malformation

‐

Aud.nerve

compression

‐

Epilepsy

‐

Prevention

‐

Middleear

aplasia

‐

Otosclerosis

‐

NVIIItumor

‐

Endolymphatic

hydrops

‐

MVC

‐

Suicidality

‐

Insomnia

‐

Depression

‐Bloodtest

Psych.exam

‐

Ossicular

chain

disruption

Neckexam

‐

Perilymphatic

fistula

Conductive Sensory

neural

Ifcausaltreatmentnotpossible/notsuccessful:symptomatictreatment

PharmacotherapyAuditorystimulation Cognitivebehavioraltherapy Neurobiofeedback Neuromodulation

Psych.

Exam.

COUNSELLING

‐Cardiovascular

examination

‐Echo‐doppler

‐Angio‐MRI

‐Angiography ‐

MRI

‐

BAEP

‐

VEMP

‐

Electro

cochleography

‐

MRI

‐

Furosemide

test

‐

Lumbar

puncture

Imaging&

functional

exam.for:

Neck TMJ

‐

Sinus

thrombosis

‐Highjug

bulb

‐

BIH

‐

Overcrowding

‐

Chiari

‐

BIH

‐

Chiari

‐

Space

occupying

lesion

‐

Basilar

impression

Disorders

Neck

TMJ

‐

Noisetrauma

Cran.+cerv.

CT/MRI

BAEP

EEG

Echodoppler

‐

Blood

test

‐

OAE

‐

MRI

‐

BAEP

‐

EEG

‐

BAEP

‐

MRI

BAEP=Brainstemauditoryevokedpotential,BIH=Benignintracranialhypertension,MVC=Microvascular

compression,OAE=Otoacoustic

emissions,

PTSD=Posttraumaticstressdisorder,SOL=Spaceoccupyinglesion,TMJ=Temporomandibular

joint,VEMP=Vestibularevokedmyogenic

potential

Abbreviations:

‐

PTSD

‐

Petrous

bone

fracture

‐

Posttraumatic

epilepsy

‐

Carotiddissection

‐

Necktrauma

‐

Otic

barotrauma

‐

Cochlear

concussion

‐

Anx.disorder

‐

Somatoform

disorder

‐

Ménière

‐

Canaldehiscence

‐

Chronic

hearingloss

‐

Otitis

‐Eustachian

tube

dysfunction

‐

MVC

‐

Myoclonus

‐Sinusthrombosis

‐

Glomus

tumor

‐

BIH

Tinnitus

ResearchInitiative

Audiological

measurements

‐

Audiometry

‐

Psychophysicalmeasurements

‐

Tympanometry

‐

Tubalimpedance‐manometry

‐

Distortion

product

OAE

History

Self‐performed

questionnaires

‐

TinnitusHandicapInventory

‐

TinnitusQuestionnaire

‐

CaseHistoryQuestionnaire

‐

TinnitusSeverityGrading

(E.Biesinger)

Specializedneuro‐/otologist

Pulsatile

tinnitus Non‐pulsatile

tinnitus

Arterial Venous Paroxysmal Constant

+Vertigo +Headache +Psychiatric

+Hearing

loss Posttraumatic

tinnitus

Acutetreatment

AcuteTinnitus

withsudden

hearingloss

+Somatosens.

Neck

TMJ

Flowchart

Clinicalexamination

‐

Otoscopy

‐

Cranio‐mandibular

&neck

examination

‐

Auscultations

Abbildung 2.1: TRI Flowchart for Patient Management [5]

2.2 TRI

2.2.3 Fragebögen

Tinnitusfragebögen sind Teil der psychometrischen Diagnostik. Die Fragebögen werden

vom Patienten selbst ausgefüllt (Selbsterfassung) und geben Auskunft über konkrete Be-

lastung und spezielle Symptomausprägung. Es lassen sich mit diesen Fragebögen eben-

so Veränderungen beispielsweise durch eine erfolgreiche Therapie belegen [22].

Tinnitus Handicap Inventory (THI)

Der THI-Fragebogen umfasst 25 Fragen und ist in die drei Untergruppen, die funktiona-

le, emotionale und katastrophale Gruppe unterteilt. Die funktionale Untergruppe, die aus

elf Fragen besteht, spiegelt die Rolle der Beeinträchtigung der mentalen, sozialen und

physikalischen Funktion wider. Die emotionale Untergruppe, bestehend aus neun Fragen,

enthält ein breites Spektrum affektiver Reaktionen auf Tinnitus. Die dritte Untergruppe

untersucht katastrophale Reaktionen auf die Symptome des Tinnitus.

Jeder Antwort wird ein Punktewert zugeschrieben, wobei bei einem „ja“ vier Punkte, bei

„manchmal“ zwei Punkte und bei „nein“ keine Punkte zugewiesen werden. Je höher die

Endpunktzahl desto größer ist die wahrgenommene Beeinträchtigung [36].

Tinnitus Impairment Questionnaire (TBF-12)

Der Tinnitus-Beeinträchtigungsfragebogen TBF-12 ist ein 12-Item-Fragebogen nach

Greimel et al. von 1999 [18]. Die Testkonstruktionen sind hierbei gut und eigenen sich

zu Screening-Untersuchung. Nachteilig an diesem Fragebogen ist die Nicht-kompatibilität

mit dem THI, da die Antwortvorgaben abweichend sind.

Tinnitus Schweregrad

Der Schweregrad gibt an wie stark der Tinnitus ausgeprägt ist. Es hat sich eine Einteilung

in vier Schweregrade bewährt. Der Schweregrad 1 beschreibt ein kompensiertes Ohr-

geräusch ohne Leidensdruck. Vom Schweregrad 2 wird gesprochen, wenn der Tinnitus

insbesondere bei Stille wahrgenommen wird. Außerdem äußert sich der Tinnitus störend

bei Stress und körperlichen oder seelischen Belastungen. Besteht eine dauerhafte tinni-

tusbedingte Beeinträchtigung im privaten und beruflichen Umfeld, sowie eine seelische,

2 Grundlagen

geistige und körperliche Störung so entspricht dies dem Schweregrad 3. Der Schwere-

grad 4 beschreibt eine völlige tinnitusbedingte Dekpompensation im privaten Bereich [43]

[13] [45].

Beck Depression Inventory (BDI)

Das Beck Depression Inventar (BDI,BDI-1A,BDI-II) ist ein psychologisches Testverfah-

ren entwickelt von Aaron T. Beck. Mit Hilfe des 21-Item-Fragebogens kann die Schwere

depressiver Symptomatik im klinischen Bereich erfasst werden. Der Fragebogen erfasst

dabei nicht die Depression selbst sondern den Schweregrad. Der Betroffene wählt bei

diesem Testverfahren eine der vier Aussagen aus, die in der letzten Woche auf ihn zutraf.

Durch Aufsummieren der Werte der einzelnen Fragen kann der Fragebogen ausgewertet

werden und die Schwere der Depression erfasst werden [69].

Major Depression Inventory (MDI)

Das Major Depression Inventory ist ein von der Weltgesundheitsorganisation entwickel-

ter Fragebogen. Dieser unterscheidet sich zu anderen Selbstbeurteilungsfragebögen, wie

dem BDI, dahingehend, dass eine ICD-10 oder DSM-IV Diagnose einer klinischen De-

pression festgestellt werden kann, nicht nur der Schweregrad. Die Auswertung erfolgt

durch Aufsummieren der Werte der einzelnen Antworten. Ein höherer Wert weist auf eine

schwerere Depression hin. Bei der Verwendung der Skala zur Diagnose der Depression

nach ICD-10 gibt es folgende Möglichkeiten:

•Leichte Depression (mild): Ein Score von mindestens vier bei zwei der ersten drei

Fragen und ein Score von mindestens drei bei zwei oder drei der letzten sieben

Fragen.

•Mittlere Depression (moderate): Ein Score von mindestens vier bei zwei der ersten

drei Fragen und ein Score von mindestens drei bei vier der letzten sieben Fragen.

•Schwere Depression (severe): Ein Score von mindestens vier bei den ersten drei

Fragen und ein Score von mindestens drei bei mindestens fünf der letzten sieben

Fragen.

2.2 TRI

Fragen zum Allgemeinen Gesundheitszustand (WHOQOL-BREF)

Das World Health Organization Quality of Life (WHOQOL) Projekt wurde 1991 mit dem

Ziel gegründet ein internationales kulturübergreifendes Messsystem für die Lebensqualität

zu entwickeln. Der WHOQOL-100 und der WHOQOL-BREF sind dabei zwei Instrumente

zur Erfassung der subjektiven Lebensqualität.

Das WHOQOL-BREF umfasst 26 Fragen aus den Domänen physische Gesundheit, psy-

chologische Gesundheit, sozialen Beziehungen und Umwelt [70]. Der WHOQOL-100 um-

faßt 100 Fragen, die den Domänen Physisches Wohlbefinden, Psychisches Wohlbefinden,

Unabhängigkeit, Soziale Beziehungen, Umwelt und Religion/Spiritualität zugeordnet sind

[29].

Fragebogen zur Funktionsfähigkeit mit Tinnitus (TFI)

Der TFI Fragebogen umfasst 25 Fragen und ist in die acht Untergruppen Intrusive, Sense

of Control, Cognitive, Sleep, Auditory, Relaxation, Quality of Life, and Emotional gegliedert

[21]. Der Fragebogen erfasst das Befinden der Betroffenen jeweils in der zurückliegenden

Woche. Jede Frage wird auf einer 11-Punkte Skala bewertet.

Das Verfahren zum Scoring1des TFI folgte durch Meikle et al. (2012). Die Summe aller

Punkte wird durch 2,5 geteilt, um eine globale Punktzahl von 100 zu erzielen. Höhere

Scores spiegeln einen größeren Einfluss auf das tägliche Befinden des Betroffenen wider

[14].

Tinnitus Handicap Questionnaire (THQ)

Mit Hilfe des THQ kann die, durch den Tinnitus hervorgerufene Beeinträchtigung des Be-

fragten, untersucht werden. Im Besonderen wird die Auswirkung auf das Hören und die

Kommunikation, auf die körperliche Gesundheit und den sozialen und emotionalen Status

gemessen. Der Fragebogen umfasst 27 Punkte denen der Befragte jeweils seine Zustim-

mung auf einer Skala zwischen 0 (stark nicht einverstanden) bis 100 (stark zustimmen)

zuweist. Die gemittelte Summe der Punkte spiegelt die Tinnitusbeeinträchtigung wider, so

deutet eine höhere Punktzahl auf ein höheres Niveau der Tinnitus-Beeinträchtigung [14].

1Hilfsmittel in der Diagnostik, um anhand von Erfahrungswerten eine Risikoeinschätzung duchzuführen.

2 Grundlagen

Clinical Global Impressions Scale (CGI)

Der CGI wurde entwickelt, um eine kurze, eigenständige Bewertung des Patienten aus

Sicht des Arztes zu ermöglichen. Es wird dabei der gesamte klinische Eindruck vor und

nach der Einleitung eines Medikaments beurteilt und berücksichtigt dabei die Geschichte

des Patienten, die psychosozialen Umstände, die Symptome sowie das Verhalten und die

Auswirkung der Symptome auf die Funktionsfähigkeit des Patienten.

Es existieren zwei Subskalen für den CGI. Zum Einen der Clinical Global Impression of

Severity (CGI-S), die Skala der Symptomschwere. Zum Anderen der Clinical Global Im-

pression of Change (CGI-C), die Skale der Symptomveränderungen. Zur Beurteilung des

Patienten mit Hilfe des CGI ist viel Erfahrung mit der Krankheit notwendig [62].

3 Related Work

Es sollen an dieser Stelle Arbeiten gesucht und geprüft werden die Modelle, Vorgehens-

weisen oder Konzepte für die Analyse von Forschungsdaten beitragen oder anregen kön-

nen. Im Fokus stehen dabei zunächst Möglichkeiten Fachanwender bei der Identifikation,

Auswahl und Filterung von Daten zu unterstützen. Visuelle Abfrage Editoren werden in Ka-

pitel 3.1 als eine Möglichkeit diskutiert SQL-Statements zu erstellen die genutzt werden

können um Daten aus relationalen Datenbanken zu exportieren.

Das praktische Ziel dieser Arbeit ist die Konzeption und Realisierung eines generischen

Moduls zum Export der Patientendaten der Tinnitus Research Initiative. Das hierzu ex-

emplarisch für die Tinnitus Database zu realisierende Modul soll als Beispiel für eine

mögliche Implementierung der in Kapitel 3.2 untersuchten Programmierkonzepte dienen.

Es wird dabei insbesondere auf verschiedene Entwurfsmuster und die Generierung von

Quellcode eingegangen.

3.1 Visuelle Abfrage Editoren

Visuelle Abfrage Editoren sind in zahlreichen Datenbank-Entwicklungsumgebungen wie

Microsoft Access und Oracle SQL Developer oder als eigenständige Werkzeuge verfüg-

bar. Eine Beschreibung der verschiedenen Werkzeuge und ihres jeweiligen Funktionsum-

fanges würde den Rahmen dieser Arbeit übersteigen, die wesentlichen Funktionalitäten

sollen daher lediglich am Beispiel von Microsoft Access (Abbildung 3.1) genannt und kurz

beschrieben werden.

•Auflistung der vorhandenen Tabellen beziehungsweise Views

Eine Übersicht der vorhandenen Tabellen beziehungsweise Views kann es auch An-

3 Related Work

Abbildung 3.1: Screenshot des visuellen Abfrage Editors aus Microsoft Access [25]

wendern ohne Detailwissen des Datenmodells ermöglichen Tabellen beziehungs-

weise Views zu identifizieren, die für die Erstellung einer Abfrage relevant sind. Eine

Auswahl der abzufragenden Tabellen beziehungsweise Views kann per Drag-and-

Drop erfolgen, sodass es für den Anwender nicht zwangsläufig notwendig ist die

exakten Bezeichner zu kennen.

•Setzen von Joins

Der Anwender kann die Verknüpfungen der ausgewählten Tabellen beziehungswei-

se Views mittels einer gesonderten visuellen Oberflächenfunktionalität setzen und

muss diese somit nicht selbstständig in SQL formulieren. Informationen über vor-

handene Fremdschlüsselbeziehungen unterstützen den Anwender bei diesem Ar-

beitsschritt.

•Auswahl der zu selektierenden Spalten

Eine Übersicht der verfügbaren Spalten unterstützt den Benutzer bei der Identifi-

kation und Auswahl der zu selektierenden Spalten, sodass es für den Anwender

nicht zwangsläufig notwendig ist die Attribute einer Tabelle beziehungsweise View

3.2 Generische Programmierkonzepte

zu kennen.

•Setzen von Filterkriterien

Der Anwender kann über die Oberfläche Filterkriterien setzen und muss diese somit

nicht selbstständig in SQL formulieren.

Die genannten Funktionalitäten ermöglichen es auch solchen Anwendern die kein Detail-

wissen über das Datenmodell und die Sprache SQL haben Abfragen zu formulieren. Sie

können dazu geeignet sein Domänenexperten bei der Identifikation, Auswahl und Filte-

rung von Daten zu unterstützen und sollen daher für die exemplarische Realisierung des

Export-Moduls der Tinnitus Database berücksichtigt werden.

3.2 Generische Programmierkonzepte

Entwurfsmuster, sogenannte Design Patterns, spielen für die generische Programmie-

rung eine große Rolle. Entwurfsmuster werden für häufig wiederkehrende Probleme in

der Softwareentwicklung und -architektur verwendet. Diese können den Prozess der Soft-

wareentwicklung beschleunigen, indem sie getestete, bewährte Entwicklungsparadigmen

anbieten. Design Pattern steigern die Effektivität des Software-Design, da bereits frühzei-

tig kleinere Probleme erkannt werden können, die später zu größeren führen könnten. Zu-

dem bieten Entwurfsmuster den Vorteil der besseren Code-Lesbarkeit für Entwickler und

Architekten [20] [67]. Im folgenden wird auf Entwurfsmuster eingegangen die einen Bei-

trag zur exemplarischen Realisierung eines generischen Export-Moduls für die Tinnitus

Database leisten können.

Erzeugungsmuster

Erzeugungsmuster sind eine Teilmenge der Entwurfsmuster und dienen der Erzeugung

von Objekten. Dabei wird die Konstruktion eines Objektes von der Repräsentation ent-

koppelt. Grundsätzlich beinhalten die Erzeugungsmuster zwei Ideen. Zum einen wird das

genaue Wissen über die konkreten Klassen verborgen. Zum Anderen verbergen sie wie

die Instanzen dieser Klassen erzeugt und verbunden werden.

3 Related Work

Die Erzeugungsmuster können ebenfalls in Objekt- und Klassenentwurfsmuster unterteilt

werden [66].

•Abstrakte Fabrik (englisch abstract factory)

•Einzelstück (englisch singleton)

•Erbauer

•Fabrikmethode (englisch factory method)

•Multiton

•Prototyp (englisch prototype)

Strukturmuster

Strukturmuster erleichtern durch die Herstellung von Beziehungen zwischen Entitäten den

Entwurf einer Software.

Der Adapter ist ein Beispiel eines Strukturmusters. Dieses Muster dient zur Übertragung

einer Schnittstelle für eine Klasse in eine andere, welche vom Client erwartet wird. Bei

einer Adapter-Pipeline werden mehrere Adapter verwendet, um Code zu testen. Ein Ad-

apter kann auch als Schnittstelle für mehrere Klassen verwendet werden, dies wird als

Nachrüstungsschnittstellenmuster (engl. retrofit interface pattern) bezeichnet [68].

Weitere Beispiele für Strukturmuster sind:

•Aggregat

•Die Brücke

–Grabstein

•Erweiterbarkeit

•Fassade

•Fliegengewicht

•Kompositum

•Pipes und Filter

3.3 Codegeneratoren

•Privatklassendaten (englisch private class data pattern)

•Stellvertreter

Verhaltensmuster

Verhaltensmuster modellieren ein komplexes Verhalten einer Software, wodurch die Fle-

xibilität der Software hinsichtlich des Verhaltens erhöht wird. Die Umsetzung kann mit

objektorientierten, dynamischen und funktionalen Programmiersprachen erfolgen [69].

•Akkumulator

•Beobachter (englisch observer pattern) [15]

•Besucher (englisch visitor pattern) [15]

•Interpreter [15]

•Iterator [15]

•Memento [15]

•Nullobjekt

•Protokollstapel

•Schablonenmethode (englisch template method pattern) [1]

•Spezifikation (englisch specification pattern)

•Vermittler (englisch mediator pattern) [15]

•Wrapper

•Zustand (englisch state pattern) [15]

•Zuständigkeitskette (englisch chain of responsibility pattern) [15]

3.3 Codegeneratoren

Codegenerierung ist die automatische und effiziente Erzeugung von Quellcode einer be-

stimmten Programmiersprache. Das Computerprogramm welches diesen Quellcode, das

3 Related Work

sogenannte Generat, erzeugt wird als Codegenerator bezeichnet. Die Generierung von

Code kann bei einer Vielzahl von Anwendungsfällen vorteilhaft sein. Die bekannteste

ist die Erzeugung von Quellcode aus einem Modell oder Diagramm, wie einem UML-

Modell oder einem Struktogramm. Compiler erzeugen aus einer Programmierhochspra-

che Assembler-, Maschinen oder Bytecode. Die Steuerung des Codegenerator kann au-

tomatisiert oder manuell geschehen.

Automatisierte Codegeneratoren

Automatisierte Codegeneratoren erstellen automatisch Quellcode anhand von Meta-

Informationen, die den Vorgang der Codeerzeugung und die Eigenschaften des Quell-

codes beschreiben. Die Meta-Informationen können als separate Datei vorliegen oder in

Form von sogenannten Annotationen (Anmerkungen, Attribute) im Programmcode vorlie-

gen. Der Quellcode wird während oder vor des Kompilierens erzeugt.

Manuell gesteuerte Codegeneratoren

Codegeneratoren können manuell durch den Programmierer beispielsweise über eine

grafische Benutzeroberfläche bedient werden. Der Programmcode kann so durch die Nut-

zung des Codegenerators oder auch durch manuelle Ergänzungen erzeugt werden. Ma-

nuell gesteuerte Codegeneratoren sind oftmals Teil einer Entwicklungsumgebung (IDE)

oder eine CASE-Werkzeuges.

4 Anforderungsanalyse

In diesem Kapitel werden die im Zuge der Anforderungsanalyse gewonnenen Erkenntnis-

se beschrieben. Der Ist-Stand des Prozess- und Datenmodells der Tinnitus Database wird

zunächst in Kapitel 4.1 mithilfe geeigneter Modellen dokumentiert. Es werden, aufbauend

auf den zuvor gewonnenen Erkenntnissen, und in Zusammenarbeit mit Domänenenexper-

ten, Soll-Prozesse für den Export von Daten erarbeitet und in Kapitel 4.2 in geeigneten

Modellen grafisch dargestellt.

Es werden schließlich in Kapitel 4.3 funktionale und nicht-funktionale Anforderungen ab-

geleitet, dokumentiert und priorisiert. In Kapitel 4.3.2 werden nicht-funktionale Qualitäts-

krierterien untersucht die sowohl für die exemplarische Realisierung des Export-Moduls

der Tinnitus Database, als auch für die Übertragbarkeit der erarbeiteten Lösungen auf

andere Forschungsdatenbanken relevant sein können.

4.1 Ist-Stand

Eine möglichst generische Implementierung eines Export-Moduls erfordert eine detaillier-

te Analyse des zugrundeliegenden Systems. Es werden hierzu zunächst die für den Ex-

port relevanten Bestandteile der Tinnitus Database benannt, im Kontext des Ablaufs einer

Patientenstudie beschrieben und schließlich in einem grafischen Prozessmodell veran-

schaulicht. Die dabei gewonnenen Erkenntnisse bilden die Grundlage für die nachfolgen-

de Untersuchung des Datenmodells der Tinnitus Database, bei der die relevanten En-

titätstypen, Attribute und Beziehungen identifiziert und der Bezug zu den Komponenten

des Prozessmodells hergestellt werden.

4 Anforderungsanalyse

4.1.1 Ablauf einer Patientenstudie

Die an der Tinnitus Research Initiative beteiligten Zentren führen Patientenstudien nach

einem einheitlichen Schema, dem sogenannten TRI Consensus, durch. Dies ermöglicht

die Vergleichbarkeit von Ergebnissen für unterschiedliche Patienten und verschiedene

Zentren, vereinfacht die Durchführung von Auswertungen und erhöht deren Aussagekraft.

Es wurden seid Beginn des Projektes im Sommer 2008, weltweit über 4700 Patienten

gemäß dem standardisierten Case Report Form, kurz CRF, mit über 40 verschiedenen

Behandlungsstrategien, dokumentiert [4]. Die Teilnahme an einer Patientenstudie erfolgt

auf freiwilliger Basis parallel zu einer Behandlung im entsprechenden Zentrum. Der Ab-

lauf und die Elemente sind in Abbildung 4.1 dargestellt. Die Weboberfläche der Tinnitus

Database bietet für jedes der aufgelisteten Elemente eine separate Karteikarte zur Pflege

der Daten an. Eine einzelne Studienteilnahme, die in der Tinnitus Database als Record

bezeichnet wird, gilt als vollständig wenn mindestens die Prozessschritte Screening,Ba-

seline,Visit,Final Visit und Followup ausgeführt wurden. In diesen Schritten sind jeweils

die nachstehenden Fragebögen, im Folgenden als Basis-Fragebögen bezeichnet, auszu-

füllen:

•Tinnitus Handicap Inventory (THI)

•Tinnitus Impairment Questionnaire (TBF-12)

•Tinnitus Schweregrad

•Beck Depression Inventory (BDI)

•Major Depression Inventory (MDI)

•Fragen zum Allgemeinen Gesundheitszustand (WHOQOL-BREF)

•Tinnitus Fragebogen

•Fragebogen zur Funktionsfähigkeit mit Tinnitus (TFI)

Das wiederholte Ausfüllen derselben Fragebögen in unterschiedlichen Prozessschritten

ermöglicht dabei eine chronologische Nachvollziehbarkeit von positiven bzw. negativen

Auswirkungen der Behandlung.

4.1 Ist-Stand

TSCHQ

Fragebögen Untersuchungen

Audiologische

Untersuchung

Otologische

Untersuchung

Audiologische

Untersuchung

CGI

Audiologische

Untersuchung

Behandlungs-

schäden

Begleitende

Medikation

Begleit-

erkrankungen

Nicht-

pharmakologische

Eingriffe

Tinnitus

Fragebogen

Record

Basis-

Fragebögen

Basis-

Fragebögen

CGI

Basis-

Fragebögen

Screening

Baseline

Visit

Final Visit

Followup

Catamnesis

Erfassungen

CGI

Basis-

Fragebögen

Basis-

Fragebögen

Abbildung 4.1: Ablauf und Elemente einer Patientenstudie in der Tinnitus Database

4 Anforderungsanalyse

Eine Studie beginnt mit dem sogenannten Screening, in dem neben den Basis-Fragebögen

der Tinnitus Sample Case History Questionnaire (TSCHQ) auszufüllen sowie eine au-

diologische und eine otologische Untersuchung durchzuführen sind. Die Ergebnisse der

otologischen Untersuchung werden zum Zeitpunkt der Erstellung dieser Arbeit nicht se-

parat, sondern als Teil des TSCHQ-Fragebogens gepflegt. Es folgt die Erstellung einer

sogenannten Baseline, in der erneut die Basis-Fragebögen auszufüllen und eine audio-

logische Untersuchung durchzuführen sind. Screening und Baseline Messungen können

am selben Tag durchgeführt werden. In diesem Fall werden die Fragebögen nur einmal

ausgefüllt und die audiologische Untersuchung nur ein mal durchgeführt [4].

Es folgen bis zu zwölf wöchentliche Besuche (Visits) des Patienten, bei denen erneut die

Basis-Fragebögen sowie der Clinical Global Impression (CGI) Fragebogen auszufüllen

sind. Der letzte Besuch wird als Final Visit bezeichnet bei dem zusätzlich erneut eine au-

diologische Untersuchung durchzuführen ist. Eine oder mehrere nachfolgende Besuche

(Followups), bei denen wiederum die Basis-Fragebögen und der CGI-Fragebogen aus-

zufüllen sind, bilden den formalen Abschluss einer einzelnen Patientenstudie. Es kann

zudem ein finaler Krankenbericht (Catamnesis) erstellt werden, in dem der Tinnitus Fra-

gebogen auszufüllen ist.

Die Tinnitus Database bietet neben der Umsetzung des beschriebenen Ablaufs die Mög-

lichkeit weitere Behandlungsinformationen zu erfassen. Es existieren hierzu separate Kar-

teikarten für die Erfassung der folgenden Daten:

•Behandlungsschäden (Adverse Events)

•Begleitende Medikation (Concomittant)

•Begleiterkrankungen (Comorbidity)

•Nicht-pharmakologische Eingriffe (Non Pharmalogical)

Ein einzelner Patient kann, typischerweise zeitlich versetzt, an mehreren Patientenstudi-

en desselben Zentrums teilnehmen. Records dienen der logischen Trennung einzelner

Teilnahmen desselben Patienten.

4.1 Ist-Stand

4.1.2 Gliederungsebenen

Die Gliederungsebenen Zentrum, Patient, Studienteilnahme (Records) und die Begriffe

Prozessschritt, Fragebögen, Untersuchungen und Erfassungen sollen an dieser Stelle

nochmals zusammengefasst und in Beziehung gesetzt werden:

•Zentrum

•Patient

•Records [1-N]

– Screening [1-N]

- TSCHQ- & und Basis-Fragebögen

- Audiologische und Otologische Untersuchung

– Baseline

- Basis-Fragebögen

- Audiologische Untersuchung

– Visits [1-N]

- CGI- & und Basis-Fragebögen

– Final Visit

- CGI- Basis-Fragebögen

- Audiologische Untersuchung

– Followups [1-N]

- CGI- & Basis-Fragebögen

– Catamnesis

- Tinnitus Fragebogen

– Behandlungsschäden (Adverse Events)

– Begleitende Medikation (Concomittant)

– Begleiterkrankungen (Comorbidity)

– Nicht-pharmakologische Eingriffe (Non Pharmalogical)

Die mit [1-N] markierten Prozessschritte können während einer einzelnen Patientenstudie

mehrfach durchlaufen werden.

4 Anforderungsanalyse

4.1.3 Datenmodell

Das Datenmodell der Tinnitus Database umfasst zum Zeitpunkt der Erstellung dieser Ar-

beit 52 Entitätstypen mit 701 Attributen und 44 Fremdschlüsselbeziehungen. Es sollen im

Rahmen einer Untersuchung die für den Export relevanten Entitätstypen, Attribute und

Beziehungen identifiziert und der Bezug zu den Komponenten des zuvor skizzierten Pro-

zessmodells hergestellt werden.

Abbildung 4.2 stellt einen Teil der relevanten Entitätstypen dar. Ausgangspunkt für die

nachfolgenden Ausführungen ist der Entitätstyp patients, in dem die allgemeinen Eigen-

schaften von Patienten wie Geburtsdatum (Attribut dateofbirth) und Geschlecht (Attribut

sex) abgebildet sind.

Die Zuordnung von Patienten zu Zentren (Entitätstyp centers) erfolgt über den Entitätstyp

id_translation, der die jeweiligen Primärschlüssel patient_id und center_id verknüpft. Das

Datenmodell erlaubt somit zwar, dass ein Patient mehreren Zentren zugeordnet sein kann,

es existiert zum Zeitpunkt der Erstellung dieser Arbeit allerdings keine entsprechende

Funktionalität in der Tinnitus Database.

Die Studienteilnahmen eines Patienten, in der Oberfläche und im Prozessmodell als

Records bezeichnet, sind im Entitätstyp sessions abgebildet. Die Verknüpfung zum En-

titätstyp patients erfolgt über den Entitätstyp patient_records. Das Datenmodell erlaubt

zwar, dass einem Patienten mehrere Entitäten in patient_records zugeordnet werden kön-

nen, die Implementierung der Tinnitus Database sieht zum Zeitpunkt der Erstellung dieser

Arbeit allerdings genau eine Entität pro Patient vor.

Die Prozessschritte Screening,Baseline,Visit,Final Visit,Followup und Catamnesis sind

jeweils als separate Entitätstypen mit einer Fremdschlüsselbeziehung zum Entitätstyp

sessions abgebildet. Die Prozessschritt-Entitätstypen enthalten jeweils die Attribute

session_content_id und type_name. Die unterschiedlichen Arten von Erfassungen sind in

separaten Entitätstypen abgebildet und jeweils über einen eigenen Entitätstyp mit dem En-

titätstyp sessions verknüpft. Beispielsweise ist der Entitätstyp non_pharmalogical für die

Erfassung von nicht-pharmakologische Eingriffen über den Entitätstyp

session_content_non_pharmalogical verbunden. Die unterschiedlichen Fragebögen und

Untersuchungen sind ebenso in separaten Entitätstypen abgebildet (Abbildung 4.3).

4.1 Ist-Stand

Erfassungen

session_content_comorbidity

session_content_non_pharmalogical

session_content_adverse

session_content_concomittant concomittant

comorbidity

non_pharmalogical

adverse_events

Prozessschritt-Entitätstypen

session_content_final_wardround

session_content_wardround

session_content_baseline

session_content_screening

session_content_catamnesis

session_content_followup

1..*1..*

1..*

1..*11

1..*1..*

1..*

1..*11

1..*1..*

1..*

1..*11

1..*1..*

1..*

1..*11

id_translation

patients centers

patient_records

sessions session_content_description

1..*1..*

1..*

1..*1..*

1..*

1..*1..*

1..*

1..*1..*

1..*

1..*1..*

1..*

1..*1..*

1..*

1..*1..*

1..*

1..*1..*

1..*

1..*1..*

1..*

1..*1..*

1..*

1..*1..*

1..*

1..*1..*

1..*

1..*1..*

1..*

1..*1..*

1..*

1..*1..*

1..*

1..*11

session_content_comorbidity

session_content_non_pharmalogical

session_content_adverse

session_content_concomittant concomittant

comorbidity

non_pharmalogical

adverse_events

session_content_final_wardround

session_content_wardround

session_content_baseline

session_content_screening

session_content_catamnesis

session_content_followup

Abbildung 4.2: Übersicht der relevanten Entitätstypen - Teil 1 37

4 Anforderungsanalyse

Untersuchungen

otologic_examination

audiological_examination

Basis-Fragebögen

tfi

bdi

tinnitus_questionnaire_gundh

whoqol-bref

mdi

tinnitus_severity

tbf12

thi

Weitere Fragebögen

cgi tschq_medications

tschq

1..*1..*

1..*

base_types

1..*1..*

1..*

1..*1..*

1..*

1..*1..*

1..*

1..*1..*

1..*

1..*1..*

1..*

1..*1..*

1..*

1..*1..*

1..*

1..*1..*

1..*

1..*1..*

1..*

1..*1..*

1..*

1..*11

1..*1..*

1..*

1..*1..*

1..*

otologic_examination

audiological_examination

tfi

bdi

tinnitus_questionnaire_gundh

whoqol-bref

mdi

tinnitus_severity

tbf12

thi

cgi tschq_medications

tschq

Abbildung 4.3: Übersicht der relevanten Entitätstypen - Teil 2

4.2 Soll-Stand

Die Prozessschritt-Entitätstypen enthalten jeweils die Attribute session_content_id und

session_content_name. Die Verknüpfung mit den Prozessschritt-Entitätstypen ist nicht ex-

plizit mittels Fremdschlüsselbeziehungen modelliert. Die Zuordnung von Fragebögen- und

Untersuchungs-Entitäten zu Prozessschritt-Entitäten erfolgt über die Werte der Attribu-

te session_content_id und session_content_name beziehungsweise session_content_id

und type_name. Das Attribut session_content_name fungiert somit als eine Art Diskrimi-

nator [48].

4.2 Soll-Stand

Es werden an dieser Stelle, aufbauend auf den in Kapitel 4.1 gewonnenen Erkenntnissen,

und in Zusammenarbeit mit Domänenenexperten, Soll-Prozesse für den Export von Pati-

entendaten erarbeitet und mit geeigneten Modellen grafisch dargestellt. Die nachfolgen-

den Prozessmodelle entsprechen der in [55] angegebenen Notation, wobei die Farbpalet-

te für diese Arbeit angepasst wurde. In Kapitel 4.2.1 wird ein exemplarischer Soll-Prozess

für die Konfiguration eines Exports erarbeitet. Dieser soll die von den Domänenenexper-

ten und Anwendern gewünschten beziehungsweise durchzuführenden Arbeitsschritten

zur Identifikation, Auswahl und Filterung der Daten enthalten. Der in Kapitel 4.2.2 vorge-

stellte Soll-Prozess der Export-Generierung umfasst alle Schritte die notwendig sind um

einen, durch eine sogenannte Export-Konfiguration spezifizierten, Export für die Tinnitus

Database zu generieren.

4.2.1 Soll-Prozess der Export-Konfiguration

Die Erstellung und Pflege von Export-Konfigurationen kann aus Anwendersicht als maß-

gebliche Funktionalität eines entsprechenden Moduls bezeichnet werden. Der mit den

Domänenexperten der Tinnitus Research Initiative erarbeitete Soll-Prozess ist in Abbil-

dung 4.4 dargestellt. Der Prozess beginnt mit der Entscheidung ob eine neue Konfigu-

ration erstellt oder eine bereits vorhandene Konfiguration wiederverwendet werden soll.

Der Anwender soll hierzu sowohl die von ihm als auch von anderen Anwendern erstellten

Konfigurationen einsehen und nutzen können. Eine bereits vorhandene Konfiguration soll

4 Anforderungsanalyse

bearbeitet oder dupliziert werden können. Es folgt auf alle drei Fälle die Möglichkeit die

Bezeichnung und Beschreibung der Konfiguration sowie Filterkriterien für die nachstehen-

den Fragestellungen festzulegen:

•Sollen nur validierte Datensätze eingeschlossen werden?

•Sollen sogenannte Drop-out-Patienten mit vorzeitigem Studienabschluss einge-

schlossen werden?

•Sollen nur Patienten eines bestimmten Geschlechtes eingeschlossen werden?

•Sollen nur Patientenstudien mit einem bestimmten Behandlungscode eingeschlos-

sen werden?

•Sollen nur Patienten eines bestimmten Zentrums eingeschlossen werden?

•Sollen nur Patienten eines bestimmten Alters eingeschlossen werden?

Der Anwender soll außerdem für jeden der in Kapitel 4.1.1 identifizierten Prozessgegen-

stände, Fragebögen, Untersuchung und Erfassungen, im Folgenden als Items zusammen-

gefasst, separat festlegen können ob die entsprechenden Daten bei der Generierung des

Exportes miteinbezogen werden sollen. Die Liste der auswählbaren Items soll, in Anbe-

tracht von potentiellen Änderungen an der Tinnitus Database, erweiterbar sein. Es sollen

in einem solchen Fall keine Anpassungen an der Implementierung des Moduls notwendig

sein. Der Anwender soll, separat für jedes von ihm gewählte Item, bei der Identifikation

und Auswahl der relevanten Item-Attribute unterstützt werden. Es soll hierzu, falls vor-

handen, der lokalisierte Bezeichner aus der Tinnitus Database wiederverwendet werden.

Die Liste der auswählbaren Item-Attribute soll, in Anbetracht von potentiellen Änderun-

gen an der Tinnitus Database, ebenso erweiterbar sein. Es sollen in einem solchen Fall

keine Anpassungen an der Implementierung des Moduls notwendig sein. Der Anwender

soll für jedes Item-Attribut, unabhängig davon ob es ausgewählt ist, Filterkriterien definie-

ren können. Es sollen dabei verschiedene Datentypen unterschieden und entsprechend

angepasste Filtermöglichkeiten angeboten werden. Es soll für den Anwender jederzeit

möglich sein zu prüfen, ob die Anzahl der durch die Filterkriterien bestimmten Datensätze

der gewünschten Stichprobengröße entspricht. Es ist zu prüfen ob dies automatisch bei

jeder Änderung eines Filterkriteriums erfolgen kann.

Sobald der Anwender alle gewünschten Konfigurationsschritte durchgeführt hat kann der

4.2 Soll-Stand

Start Export konfigurieren

Neue

Konfiguration?

Vorhandene

Konfigurationen

durchsuchen

Ja Nein Vorhandene

Konfigurationen

Konfiguration

gefunden? Nein

Vorhandene

Konfigurationen

auswählen

Bezeichnung und

Beschreibung festlegen

Gewünschte

Fragebögen,

Untersuchungen, bzw.

Erfassungen auswählen

Filterkriterien festlegen

Auswählbare

Fragebögen,

Untersuchungen,

bzw. Erfassungen

Gewünschte Attribute

auswählen

Auswählbare

Attribute

Filterkriterien für

Attribute festlegen

Neue Konfiguration

erstellen

Export generieren

Ende

Export-Datei

Konfiguration

duplizieren?

Konfiguration

duplizieren Ja

Nein

Export prüfen

Export wie

gewünscht?

Stichprobengröße

wie gewünscht?

Stichprobengröße

prüfen

Nein

Abbildung 4.4: Soll-Prozess der Export-Konfiguration

4 Anforderungsanalyse

Subprozess der Export-Generierung ausgeführt werden. Die Export-Datei soll nach er-

folgreichem Abschluss direkt zum Download angeboten werden, sodass der Anwender

den Export manuell oder mit externen Werkzeugen prüfen kann. Entspricht der Export

nicht den Erwartungen des Anwenders kann dieser zu einem vorhergehenden Prozess-

schritt zurückkehren und die Konfiguration erneut anpassen. Andernfalls ist der Prozess

der Export-Konfiguration abgeschlossen. Die heruntergeladene Datei kann im Rahmen

von nachgelagerten Prozessen mit spezifischen statistischen Verfahren und entsprechen-

den Werkzeugen ausgewertet werden. Der vorgestellte Prozess ist somit geeignet das

wissenschaftliche Fachpersonal bei der Identifikation, Auswahl und Filterung von Patien-

tendaten zu unterstützen.

4.2.2 Soll-Prozess der Export-Generierung

Der Prozess der Export-Generierung umfasst die notwendigen Schritte eines Exports von

Daten der Tinnitus Database anhand einer gegebenen Export-Konfiguration. Das Format

der Ausgabedatei wurde aufgrund von organisatorischen und technischen Rahmenbedin-

gungen bereits im Vorfeld mit den Fachanwender abgestimmt. Es wurden aus nachfolgen-

den Gründen Kommaseparierte Wertelisten (engl. Comma-separated values, kurz CSV)

favorisiert:

•Der eingangs beschriebene, manuelle Prozess der Erstellung von Auswertungen

nutzt ein CSV-Ausgabeformat. Es sollen bereits erarbeitete Prozessbestandteile

wiederverwendet werden können.

•Die bisher und zukünftig eingesetzten statistischen Verfahren erfordern, dass die

Daten eines einzelnen Patienten als Datenreihe vorliegen. Ein separater Zwischen-

verarbeitungsschritt erübrigt sich, wenn die Daten bereits in einem passenden For-

mat exportiert werden.

•CSV-Formate können von zahlreichen Datenverarbeitungswerkzeugen, wie beispiels-

weise Microsoft Excel [31] oder OpenOffice Calc [2], insbesondere aber durch die

relevanten wissenschaftlichen Werkzeuge und Programmiersprachen R[46] und

SPSS [24] gelesen und verarbeitet werden.

4.2 Soll-Stand

Die genaue Ausprägung des Ausgabeformates, beispielsweise ob als Trennzeichen ein

Komma oder ein Semikolon zu verwenden ist, soll im Verlauf dieser Arbeit festgelegt und

begründet werden.

Die Festlegung auf ein CSV-Ausgabeformat verlangt eine Transformation der relational

vorliegenden Daten in eine denormalisierte Form. Abbildung 4.5 stellt diesen Sachver-

halt exemplarisch dar. Patient A hat an zwei Studien teilgenommen. Er ist im Rahmen

Patient A

Record 1 Record 2 ...

Screening Baseline ... Followup 1 Followup 2 Adverse Events ... Non Pharmalogical

TSCHQ BF AU OU BF AU ... CGI BF CGI BF AE1 AE2 ... ... NP1 N/A N/A

Screening ...

TSCHQ ... ...

Patient B

Record 1 Record 2 ...

Screening Baseline ... Followup 1 Followup 2 Adverse Events ... Non Pharmalogical

TSCHQ BF AU OU BF AU ... CGI BF N/A N/A AE1 AE2 N/A ... NP1 NP2 ...

Screening ...

TSCHQ ... ...

BF = Basis-Fragebögen | AU = Audiologische Untersuchung | OU = Otologische Untersuchung

Abbildung 4.5: Exemplarische Struktur eines Exports

der ersten Studienteilnahme (Record 1) unter anderem zu zwei Followups erschienen bei

denen jeweils der CGI und die Basis-Fragebögen (BF) ausgefüllt wurden. Es wurden au-

ßerdem mehrere Behandlungsschäden (AE1,AE2, ...) und ein Nicht-pharmakologischer

Eingriff (NP1) erfasst. Patient B ist im Rahmen seiner ersten Studienteilnahme lediglich

zu einem Followup erschienen. Es wurden zwei Behandlungsschäden und mehrere Nicht-

pharmakologische Eingriffe erfasst.

Es kann anhand dieses Beispieles erkannt werden, dass die Anzahl der Spalten eines

CSV-Exports von folgenden Fragestellungen abhängt:

•Wie viele Studienteilnahmen müssen eingeschlossen werden?

•Welche Prozessschritte wurden durchlaufen?

•Wie oft wurden einzelne Prozessschritte durchlaufen?

•Welche Erfassungsarten müssen eingeschlossen werden?

•Wie viele Erfassungen müssen eingeschlossen werden?

Die Bestimmung dieser Faktoren anhand des, zum Zeitpunkt der Generierung, verfügba-

ren Datenbestandes ist für die Korrektheit des Exports zwingend erforderlich und muss

4 Anforderungsanalyse

daher bei der Modellierung des Prozesses entsprechend berücksichtigt werden.

Der erarbeitete Soll-Prozess ist in Abbildung 4.6 dargestellt. Die Bestandteile einer gege-

benen Konfiguration werden wie folgt verarbeitet:

•Filterkriterien

Es müssen zunächst die in den Export einzuschließenden Patienten anhand der in

Kapitel 4.2.1 genannten Filterkriterien bestimmt werden. Es muss anschließend die

Anzahl der einzuschließenden Studienteilnahmen dieser Patienten bestimmt wer-

den. Die in Kapitel 4.2.1 identifizierten relevanten Attribute der session-Entitäten

müssen in die SELECT-Liste des zu generierenden SQL-Statements aufgenommen

werden.

•Ausgewählte Items

Es müssen die maximalen Anzahlen der ausgewählten Item-Entitätstypen bestimmt

werden.

Im Fall von Fragebögen und Untersuchungen muss hierzu bestimmt werden welche

Prozessschritte wie oft durchlaufen wurden. Sollen beispielsweise CGI-Fragebögen

exportiert werden, so muss die maximale Anzahl aller CGI-Fragebögen aller einzu-

schließenden Patienten bestimmt werden.

Im Fall von Erfassungen müssen die Erfassungsarten und die jeweilige Anzahl von

Einträgen bestimmt werden. Sollen beispielsweise Behandlungsschäden exportiert

werden, so muss die maximale Anzahl aller Behandlungsschäden aller einzuschlie-

ßenden Patienten bestimmt werden.

Die ausgewählten Item-Entitätstypen müssen außerdem, einschließlich der notwen-

digen Verknüpfungen, in den FROM-Teil des SQL-Statements aufgenommen wer-

den.

•Ausgewählte Item-Attribute

Die ausgewählten Item-Attribute müssen, abhängig von der Anzahl der jeweiligen

Item-Entitäten in die SELECT-List aufgenommen werden.

•Filterkriterien für Item-Attribute

Die für die Item-Attribute festgelegten Filterkriterien müssen, abhängig von Datentyp

und Filterart, in WHERE-Bedingungen übersetzt werden.

4.2 Soll-Stand

Start Export generieren

Einzuschließende

Patienten bestimmen

Maximale Anzahl der

Session-Entitäten pro

Patient bestimmen

Maximale Anzahlen der

Item-Entitäten

bestimmen

SELECT-Liste generierenFROM-Liste generieren WHERE-Bedingungen

generieren

SQL-Statement

zusammenfügen

SQL-Statement

ausführen

Ergebnissmenge

serialisieren

Export-Datei

Ende

Konfiguration

verarbeiten

Filterkriterien Ausgewählte

Items

Ausgewählte

Item-Attribute

Filterkriterien

für Item-

Attribute

Export protokollieren

Abbildung 4.6: Soll-Prozess der Export-Generierung

4 Anforderungsanalyse

Das zusammengefügte Statement muss schließlich ausgeführt und die Ergebnismenge in

einem CSV-Format als Datei serialisiert werden. Die Durchführung der Generierung muss

außerdem, einschließlich der Export-Konfiguration, protokolliert werden. Der Prozess ist

damit abgeschlossen. Er ist geeignet um, innerhalb der organisatorischen und techni-

schen Rahmenbedingungen der Tinnitus Database, einen durch die Domänenexperten

konfigurierbaren Export durchzuführen und in einem CSV-Format als Datei zu serialisie-

ren.

4.3 Anforderungen

Es werden an dieser Stelle, aufbauend auf den in Kapitel 4.1 gewonnenen Erkenntnis-

sen, und den in Kapitel 4.2 erarbeiteten Soll-Prozessen, funktionale und nicht-funktionale

Anforderungen abgeleitet, dokumentiert und priorisiert.

Die zur Erfüllung der Zielsetzung notwendigen funktionalen Anforderungen werden in Ka-

pitel 4.3.1 beschrieben. Sie beschreiben die, für die exemplarische Realisierung notwen-

digen, Funktionalitäten aus Sicht der Domänenexperten und anderer Anspruchsgruppen.

In Kapitel Kapitel 4.3.2 werden nicht-funktionale Qualitätskriterien genannt die sowohl für

die exemplarische Realisierung eines Export-Moduls für die Tinnitus Database, als auch

für die Übertragbarkeit der erarbeiteten Lösungen auf andere Forschungsdatenbanken

relevant sein können.

Jeder Anforderung ist ein eindeutiger Identifikator (ID), eine eindeutige Bezeichnung und

eine Priorität nach der MoSCoW-Priorisierung (MUSS, SOLL, KANN, NOCH NICHT)

[65] zugewiesen.

4.3.1 Funktionale Anforderungen

Die zur Erfüllung der Zielsetzung notwendigen Funktionalitäten des Export-Moduls der

Tinnitus Database werden durch die funktionalen Anforderungen beschrieben. Sie bilden

die Basis für die Architektur und das Verhalten des Systems. Sie können anhand der in

Kapitel 4.2 erarbeiteten Soll-Prozesse in zwei Gruppen unterteilt werden.

4.3 Anforderungen

ID Bezeichnung Priorität Seite

Export-Konfiguration

F01 Technische Rahmenbedingungen MUSS 48

F02 Autorisierung MUSS 48

F03 Konfiguration neu erstellen MUSS 48

F04 Vorhandene Konfigurationen sichten MUSS 48

F05 Konfigurationen anderer Anwender MUSS 48

F06 Vorhandene Konfiguration bearbeiten MUSS 48

F07 Vorhandene Konfiguration duplizieren MUSS 48

F08 Bezeichnung und Beschreibung festlegen MUSS 49

F09 Filterkriterien festlegen MUSS 49

F10 Gewünschte Items auswählen MUSS 50

F11 Liste der Items erweiterbar SOLL 50

F12 Filterkriterien für Item-Attribute festlegen MUSS 50

F13 Gewünschte Item-Attribute auswählen MUSS 50

F14 Liste der Item-Attribute erweiterbar SOLL 50

F15 Anzahl der Datensätze prüfbar SOLL 50

F16 Export-Generierung starten MUSS 50

F17 Download der Export-Datei MUSS 51

Export-Generierung

F18 Verarbeitung von Konfigurationen MUSS 51

F19 Generierung der SELECT-Liste MUSS 51

F20 Generierung der FROM-Liste MUSS 51

F21 Generierung der WHERE-Bedingungen MUSS 51

F22 Standardisierte Serialisierung SOLL 51

F23 Ablage der Export-Datei MUSS 51

F24 Protokollierung von Exporten MUSS 51

F25 Protokollierung der Konfiguration SOLL 52

F26 Weitere Ausgabeformate KANN 52

Tabelle 4.1: Funktionale Anforderungen an das Export-Modul

4 Anforderungsanalyse

F01 Technische Rahmenbedingungen

Das Modul muss mit den für die Tinnitus Database festgelegten Technologien umgesetzt

werden. Es handelt sich dabei um MySQL in der Version 5.5, PHP1in der Version 5.6 und

Laravel2in der Version 4.2.

F02 Autorisierung

Das Modul muss so in die Tinnitus Database integriert werden, dass nur autorisierte An-

wender auf die Funktionalitäten zugreifen können.

F03 Konfiguration neu erstellen

Autorisierte Anwender müssen die Möglichkeit haben neue Export-Konfigurationen anzu-

legen.

F04 Vorhandene Konfigurationen sichten

Autorisierte Anwender müssen eine Übersicht der vorhandenen Export-Konfigurationen

aufrufen können. Sie müssen einzelne Konfigurationen öffnen und sichten können.

F05 Konfigurationen anderer Anwender

Autorisierte Anwender müssen die von anderen Anwendern erstellen Export-Konfigurati-

onen sichten und verwenden können.

F06 Vorhandene Konfiguration bearbeiten

Autorisierte Anwender müssen vorhandene Export-Konfigurationen bearbeiten können.

Es müssen dieselben Bearbeitungsmöglichkeiten gegeben sein, die auch bei einer neu

erstellten Export-Konfiguration angeboten werden.

F07 Vorhandene Konfiguration duplizieren

Autorisierte Anwender müssen vorhandene Export-Konfigurationen duplizieren können.

Eine duplizierte Konfiguration ist eine zum Zeitpunkt ihrer Erstellung exakte Kopie einer

vorhandenen Konfiguration. Duplikat und Original müssen nach der Erstellung unabhän-

gig voneinander sein. Es müssen für das Duplikat dieselben Bearbeitungsmöglichkeiten

1PHP ist eine speziell für das Web entwickelte serverseitige Skriptsprache [64].

2Laravel ist ein in PHP geschriebenes Rahmenwerk für die Webentwicklung [30].

4.3 Anforderungen

gegeben sein, die auch bei einer neu erstellten Export-Konfiguration angeboten werden.

F08 Bezeichnung und Beschreibung festlegen

Es muss für jede Export-Konfiguration eine Bezeichnung und eine Beschreibung festge-

legt und geändert werden können.

F09 Filterkriterien festlegen

Es müssen Filterkriterien für die nachstehenden Fragestellungen festgelegt werden kön-

nen:

•Sollen nur validierte Datensätze eingeschlossen werden?

Filterkritiern: Nein/Ja

Entitätstyp & Attribut: sessions.inputstate_validated

•Sollen sogenannte Drop-out-Patienten mit vorzeitigem Studienabschluss eingeschlos-

sen werden?

Filterkritiern: Nein/Ja

Entitätstyp & Attribut: sessions.inputstate_dropout

•Sollen nur Patienten eines bestimmten Geschlechtes eingeschlossen werden?

Filterkritiern: Alle/Weiblich/Männlich

Entitätstyp & Attribut: patients.sex

•Sollen nur Patientenstudien mit einem bestimmten Behandlungscode eingeschlos-

sen werden?

Filterkritiern: Alle/Element aus der Liste aller vorhandenen Behandlungscodes

Entitätstyp & Attribut: session_content_description.code_intervention_protocol

•Sollen nur Patienten eines bestimmten Zentrums eingeschlossen werden?

Filterkritiern: Alle/Element aus der Liste aller Zentren

Entitätstyp & Attribut: center.center_name

•Sollen nur Patienten eines bestimmten Alters eingeschlossen werden?

Filterkritiern: Alle/Größer als x Jahre/Kleiner als x Jahre/Zwischen x und y Jahren

Entitätstyp & Attribut: patients.age

Die unterstrichenen Werte sind die jeweilige initiale Belegung des Filterkriteriums.

4 Anforderungsanalyse

F10 Gewünschte Items auswählen

Es muss möglich sein, die zu exportierenden Items (Fragebögen, Untersuchungen und

Erfassungen) auswählen zu können.

F11 Liste der Items erweiterbar

Die Liste der auswählbaren Items soll, in Anbetracht von potentiellen Änderungen an der

Tinnitus Database, generisch erweiterbar sein. Es sollen in einem solchen Fall also keine

Anpassungen an der Implementierung des Moduls notwendig sein.

F12 Filterkriterien für Item-Attribute festlegen

Es muss, separat für jedes vom Anwender gewählte Item, möglich sein Filterkriterien für

die jeweiligen Item-Attribute zu definieren. Es sollen dabei verschiedene Datentypen un-

terschieden und entsprechend angepasste Filtermöglichkeiten angeboten werden.

F13 Gewünschte Item-Attribute auswählen

Es muss möglich sein, die zu exportierenden Item-Attribute auswählen und die Auswahl

nachträglich ändern zu können.

F14 Liste der Item-Attribute erweiterbar

Die Liste der auswählbaren Item-Attribute soll, in Anbetracht von potentiellen Änderungen

an der Tinnitus Database, generisch erweiterbar sein. Es sollen in einem solchen Fall also

keine Anpassungen an der Implementierung des Moduls notwendig sein.

F15 Anzahl der Datensätze prüfbar

Es soll für den Anwender möglich sein zu prüfen, ob die Anzahl der durch die Filterkriterien

bestimmten Datensätze der gewünschten Stichprobengröße entspricht.

F16 Export-Generierung starten

Der Anwender muss den Subprozess der Export-Generierung manuell starten können.

Dies muss insbesondere auch möglich sein solange der Export noch nicht vollständig

konfiguriert ist.

4.3 Anforderungen

F17 Download der Export-Datei

Die durch den Subprozess der Export-Generierung erstellte Datei muss heruntergeladen

werden können. Dies muss insbesondere auch für von anderen Anwendern generierte

Export-Dateien möglich sein.

F18 Verarbeitung von Konfigurationen

Es müssen, die anhand des entsprechenden Prozesses erstellten, Export-Konfigurationen

verarbeitet werden können.

F19 Generierung der SELECT-Liste

Es muss eine SELECT-Liste generiert werden, welche die laut der Konfiguration ausge-

wählten Item-Attribute für die einzuschließenden Patienten, abhängig von der Anzahl der

Studienteilnahmen, den durchgeführten Prozessschritten und der Art und Anzahl der Er-

fassungen, enthält.

F20 Generierung der FROM-Liste

Es muss eine FROM-Liste generiert werden, welche die laut der Konfiguration ausge-

wählten Items für die einzuschließenden Patienten, abhängig von den durchgeführten

Prozessschritten, enthält.

F21 Generierung der WHERE-Bedingungen

Es müssen WHERE-Bedingungen für die, durch die Konfiguration festgelegten, Filterkri-

terien generiert werden.

F22 Standardisierte Serialisierung

Die Serialisierung der Ergebnismenge in einem CSV-Format soll unter Beachtung aner-

kannter Standards realisiert werden.

F23 Ablage der Export-Datei

Die Export-Datei muss serverseitig persistent abgelegt werden.

F24 Protokollierung von Exporten

Die Ausführung der Generierung muss protokolliert werden. Insbesondere muss nachvoll-

ziehbar sein wann und durch welchen Anwender ein Export durchgeführt wurde.

4 Anforderungsanalyse

F25 Protokollierung der Konfiguration

Es soll, zusätzlich zu den in Anforderung F24 genannten Merkmalen, die vollständige

Export-Konfiguration protokolliert werden.

F26 Weitere Ausgabeformate

Eine Unterstützung für weitere Ausgabeformate kann einen weiteren Nachweis für die

Tragfähigkeit der erarbeiteten Lösung liefern. Es soll geprüft werden ob im Rahmen dieser

Arbeit eine entsprechende Lösung prototypisch umgesetzt werden kann.

4.3.2 Nicht-Funktionale Anforderungen

Die zu erbringende Qualität der exemplarischen Realisierung kann in Form von nicht-

funktionalen Anforderungen festgelegt werden. Diese können außerdem für die Übertrag-

barkeit der erarbeiteten Lösungen auf andere Forschungsdatenbanken relevant sein. Die

nicht-funktionalen Anforderungen des Export-Moduls werden im folgenden genannt und

beschrieben.

ID Bezeichnung Priorität Seite

NF1 Zuverlässigkeit MUSS 52

NF2 Sicherheit/Datenschutz MUSS 52

NF3 Benutzerfreundlichkeit SOLL 53

NF4 Effizienz SOLL 53

NF5 Übertragbarkeit SOLL 53

NF6 Wartbarkeit MUSS 53

Tabelle 4.2: Nicht-funktionale Anforderungen an das Export-Modul

NF1 Zuverlässigkeit

Das Modul muss stets zuverlässig, also frei von Fehlern und Datenverlusten arbeiten.

NF2 Sicherheit/Datenschutz

Der Schutz von vertraulichen, personenbezogenen Daten muss sichergestellt sein. Die

4.3 Anforderungen

in der Tinnitus Database gespeicherten Patientendaten müssen in besonderem Maße

geschützt werden [10].

NF3 Benutzerfreundlichkeit

Das Design und die Bedienbarkeit der Weboberflächen des Moduls sollen für Domänen-

experten selbsterklärend gestaltet sein. Es sollen hierzu beispielsweise gewohnte Ele-

mente, Farben und Abläufe der Tinnitus Database wiederverwendet werden.

NF4 Effizienz

Die Implementierung des Moduls soll effizient und performant sein. Die begrenzten IT-

Ressourcen der TRI-Zentren sollen geschont werden. Es soll hierzu unter anderem ge-

prüft werden welche Prozessschritte serverseitig ausgeführt werden können.

NF5 Übertragbarkeit

Die Komponenten des Moduls sollen sich, sofern dies technisch möglich ist, auf andere

Systeme, wie beispielsweise andere RDBMS, übertragen lassen.

NF6 Wartbarkeit

Die Implementierung des Moduls muss auf gute Wart- und Erweiterbarkeit ausgelegt sein.

Sie ist hierzu angemessen zu dokumentieren. Die relevanten funktionalen Anforderungen

sind entsprechend umzusetzen.

4 Anforderungsanalyse

5 Entwurf

In diesem Kapitel wird gezeigt, wie die während der Anforderungsanalyse erarbeiteten Er-

kenntnisse, Soll-Prozesse und Modelle schrittweise konkretisiert werden können. Es wer-

den hierbei zueinander abgrenzbare Komponenten und Abläufe differenziert und schließ-

lich exemplarisch für das Export-Modul der Tinnitus Database entworfen. Es wird in Kapi-

tel 5.1 zunächst eine exemplarische Architektur vorgeschlagen und anschließend schritt-

weise begründet welche Konzepte und Lösungen geeignet sind um die in Kapitel 4.3 doku-

mentierten Anforderungen zu erfüllen. Es können aus den erarbeiteten Modellen Entitäts-

typen, Attribute und Beziehungen für ein exemplarisches Datenmodel des Export-Moduls

der Tinnitus Database abgeleitet werden. Die einzelnen Entitätstypen, ihre Attribute und

die relevanten Beziehungen werden in Kapitel 5.2 zusammengefasst und konkret benannt.

Es wird dabei nochmals begründet wie die Systemkomponenten interagieren um das Ziel

eines verlässlichen, benutzerfreundlichen und generischen Moduls für den Export von

Daten der Tinnitus Database zu realisieren.

5.1 Architektur

Die Architektur des Export-Moduls wird an dieser Stelle zunächst schrittweise entworfen.

Es werden hierzu, anhand der in der Anforderungsanalyse erarbeiteten Prozessmodelle

und Erkenntnisse, logisch zusammenhängende Funktionalitäten identifiziert und sukzes-

sive zu zueinander abgrenzbaren Komponenten differenziert. Es wird schrittweise begrün-

det welche Konzepte und Lösungen genutzt werden um die in Kapitel 4.3 dokumentierten

Anforderungen zu erfüllen.

5 Entwurf

5.1.1 Ansicht und Erstellung von Konfigurationen

Diejenigen Komponenten die den Anwendern die Ansicht und Erstellung von Konfigu-

rationen ermöglichen, können wie in Abbildung 5.1 dargestellt, modelliert werden. Die

Serveranwendung implementiert eine Schnittstelle die von den Anwendern mittels Web-

clients aufgerufen werden kann. Dieser Aufruf wird mit einem HTML-Dokument, dass die

aus der Datenbank ausgelesene Liste der vorhandenen Konfigurationen enthält, beant-

wortet. Der Anwender kann diese in seinem Webclient prüfen und auswählen ob eine

vorhandene Konfiguration bearbeitet oder dupliziert oder eine neue Konfiguration erstellt

werden soll. Es wird, je nach Auswahl des Anwenders, eine entsprechende Schnittstelle

der Serveranwendung aufgerufen in deren Ablauf eine spezifische Datenbankprozedur

ausgeführt wird. Die bei einem Export einzuschließenden Items1und Item-Attribute sowie

die gesetzten Filterkriterien werden in entsprechenden Datenbanktabellen verwaltet. Die

Prozeduren legen die entsprechenden Datensätze im Falle der Neuerstellung einer Kon-

figuration anhand der potentiellen Items und Item-Attribute und im Falle der Duplizierung

einer Konfiguration als Kopie der zugehörigen Datensätze an. Der Anwender wird schließ-

lich auf die Bearbeitungsmasken für die ausgewählte, neue bzw. duplizierte Konfiguration

weitergeleitet.

5.1.2 Bearbeitung von Konfigurationen

Die Bearbeitung einer Konfiguration kann, wie in Abbildung 5.2 dargestellt, modelliert wer-

den. Ein Aufruf der entsprechenden serverseitigen Schnittstelle wird mit einem HTML-

Formular2beantwortet, welches dem Anwender das Editieren der Konfiguration ermög-

licht. Die in der funktionalen Anforderung F9 spezifizierten Fragestellungen sind im Da-

tenmodell als Spalten der Datenbanktabelle Export-Konfigurationen modelliert. Die ser-

verseitige Implementierung generiert, anhand der Liste der potentiell möglichen Items,

Oberflächenelemente die dem Anwender die Auswahl der einzuschließenden Items er-

möglichen. Die Modellierung der potenziell möglichen Items als separate Datenbankta-

belle ermöglicht die Erweiterung dieser Liste ohne Anpassungen an der Implementierung

1Fragebögen, Untersuchungen und Erfassungen

2Die Verwendung von Formularen ist der effektivste Weg relevante Daten des Benutzers zu erfassen[19].

5.1 Architektur

MySQL

(Datenbank)

PHP/Laravel

(Server)

Weboberfläche

(Client)

Export-Konfigurationen

Potentielle

Items/Item-Attribute

Übersicht generieren

Neue Konfiguration

erstellen

Konfiguration

duplizieren

Items/Item-Attribute

der Konfiguration

Neue Konfiguration

erstellen

Konfiguration

duplizieren

Konfiguration bearbeiten

(Abbildung 5.2)

Export 1 Beschreibung 1

Export 2 Beschreibung 2

... ...

Legende

Der Bereich „Weboberfläche“ stellt

Oberflächenelemente (Seiten, Tabellen,

Buttons) dar.

Der Bereich „PHP/Laravel“ stellt

Schnittstellen der Serveranwendung

dar.

Der Bereich „MySQL“ stellt

und

dar.

Datenbanktabellen

Datenbankprozeduren

Datenfluss:Kontrollfluss:

Schnittstellen

Abbildung 5.1: Ansicht und Erstellung von Konfigurationen

5 Entwurf

des Moduls vornehmen zu müssen. Der Anwender kann seine Änderungen durch die

Übertragung des Formulars speichern und wird anschließend auf eine zweite Bearbei-

tungsmaske weitergeleitet.

Diese Bearbeitungsmaske ermöglicht dem Anwender die Auswahl und das Setzen von

Filterkriterien für die Attribute der eingeschlossenen Items. Die serverseitige Implemen-

tierung generiert anhand der Liste der potentiell möglichen Item-Attribute Oberflächen-

elemente die das Setzen von Filterkriterien abhängig vom Datentyp des Item-Attributs er-

möglichen. Der Bezeichner wird dabei, falls verfügbar, durch die lokalisierte Variante aus

der Tinnitus Database ersetzt. Beispielsweise wird für die erste Frage des

WHOQOL-BREF-Fragebogens in der deutschen Spracheinstellung „1. Wie würden Sie

ihre Lebensqualität beurteilen?“ und in der englischen Spracheinstellung „1. How would

you rate your quality of life?“ angezeigt. Die Modellierung der potentiell möglichen

Item-Attribute als separate Datenbanktabelle ermöglicht die Erweiterungen dieser Liste

ohne Anpassungen an der Implementierung des Moduls vornehmen zu müssen.

Der Anwender kann seine Auswahl und die gesetzten Filterkriterien jederzeit übertragen

und die Generierung des Exports starten. Die infolgedessen generierte Export-Datei wird

nach erfolgreichem Abschluss direkt zum Download angeboten.

5.1.3 Export-Generierung

Die Generierung von Exporten kann, wie in Abbildung 5.3 dargestellt, modelliert werden.

Die Serveranwendung ruft zunächst eine Datenbankprozedur auf um die in Kapitel 4.2.2

skizzierten Fragestellungen anhand des verfügbaren Datenbestandes zu beantworten:

•Wie viele Studienteilnahmen müssen eingeschlossen werden?

Die Liste der einzuschließenden Patienten und Studienteilnahmen wird anhand der

im Entitätstyp Export-Konfiguration abgelegten Filterkriterien entsprechend der funk-

tionalen Anforderung F9 bestimmt. Es wird hierzu eine View verwendet die die erfor-

derlichen Entitätstypen verknüpft und spezifische Filter für die relevanten Attribute

implementiert.

5.1 Architektur

BehandlungsschädenWHOQOL-BREF

MySQL

(Datenbank)

PHP/Laravel

(Server)

Weboberfläche

(Client)

Bezeichnung

Beschreibung

Nur validierte Datensätze?

...

WHOQOL-BREF

Audiologische Untersuchungen

Behandlungsschäden

...

Export 1

Beschreibung... Laden

Speichern

Laden

Formulardaten

übertragen

1. Wie würden Sie ihre

Lebensqualität

beurteilen?

2. Wie zufrieden sind Sie

mit Ihrer Gesundheit?

...

< 4

> 2

...

Laden

Speichern

Laden

Export generieren

(Abbildung 5.3)

Formulardaten

übertragen

Konfiguration bearbeiten Export-Konfiguration

Attribut einschließen

Filtertyp

Filterwert

Item-Attribute der Konf.

Potentielle Item-Attribute

Bezeichnung

Datentyp

Potentielle Items

Items der Konfiguration

Bezeichnung

Item einschließen

Bezeichnung

Beschreibung

Nur Validierte

...

Legende

Der Bereich „Weboberfläche“ stellt

Oberflächenelemente (Seiten,

Formulare, Eingabefelder, Buttons) dar.

Der Bereich „PHP/Laravel“ stellt

Schnittstellen der Serveranwendung

dar.

Der Bereich „MySQL“ stellt

und die zugehörigen

dar.

Datenfluss:Kontrollfluss:

Schnittstellen

Spalten

Datenbanktabellen

1:N-Beziehungen:

Export-Datei

(Download)

Abbildung 5.2: Bearbeitung von Konfigurationen

5 Entwurf

•Welche Prozessschritte wurden durchlaufen?

Die während der einzuschließenden Studienteilnahmen durch die Patienten durch-

laufenen Prozessschritte3können anhand der Datensätze in den entsprechenden

Datenbanktabellen identifiziert werden. Beispielsweise können finale Krankenbe-

richte (Catamnesis) anhand der Datensätze in der Datenbanktabelle

session_content_catamnesis identifiziert werden. Sie dienen, entsprechend den Aus-

führungen zum Datenmodell in Kapitel 4.1.3, als Verbindung zwischen den Daten-

banktabellen für Fragebögen und Untersuchungen und den Studienteilnahmen der

Patienten. Sie sind in der Datenbanktabelle Link konfiguriert. Die im Prozessmodell

identifizierten Zusammenhänge zwischen Prozessschritten und Fragebögen bezie-

hungsweise Untersuchungen sind als Datensätze in einer Verbindungsrelation [56]

der Datenbanktabellen Item und Link konfiguriert. Die Verbindungen, beispielswei-

se Screening-TSCHQ,Screening-Audiologische Untersuchung, Visit-CGI, werden

mittels der jeweiligen Primärschlüssel abgebildet. Es können somit, anhand der laut

Konfiguration einzuschließenden Fragebögen und Untersuchungen, die zu prüfen-

den Item-Link-Kombinationen bestimmt werden.

•Wie oft wurden einzelne Prozessschritte durchlaufen?

Es wird für jede zu prüfende Item-Link-Kombination ein Statement generiert, wel-

ches pro Prozessschritt bestimmt wie oft dieser maximal durch die einzuschließen-

den Patienten durchlaufen wurde. Diese Statements werden durch die Datenbank-

prozedur ausgeführt und die Ergebnisse in einer Tabelle zwischengespeichert.

•Welche Erfassungsarten müssen eingeschlossen werden?

Die einzuschließenden Erfassungsarten4können direkt anhand der entsprechenden

Item-Entitäten der Konfiguration bestimmt werden.

•Wie viele Erfassungen müssen eingeschlossen werden?

Die Verbindung zwischen den Entitätstypen für Erfassungen und den Studienteil-

nahmen der Patienten ist, vergleichbar mit den Prozessschritt-Entitätstypen, in se-

3Screening,Baseline,Visit,Final Visit,Followup,Catamnesis (Kapitel 4.1.1)

4Behandlungsschäden (Adverse Events), Begleitende Medikation (Concomittant), Begleiterkrankungen

(Comorbidity), Nicht-pharmakologische Eingriffe (Non Pharmalogical) (Kapitel 4.1.1)

5.1 Architektur

MySQL

(Datenbank)

PHP/Laravel

(Server)

Export generieren

Legende

Der Bereich „PHP/Laravel“ stellt Schnittstellen der

Serveranwendung dar.

Der Bereich „MySQL“ stellt Entitätstypen ,

Datenbankprozeduren und Views dar.

Datenfluss:Kontrollfluss:

Schnittstellen

N:M-Beziehungen:

Export-Konfiguration

Potentielle Items

Patienten

Zentren

Sessions

Einzuschließende

Patienten und Sessions

Potentielle Links

Zu prüfende

Item-Link-Kombination

Aktuellen

Datenbestand

prüfen

Anzahlen der

Item-Entitäten

Item/Link-

Datenbanktabellen

SELECT-Liste

FROM-Liste

Item-Attribute der Konf.

WHERE-Liste

Aktuellen Datenbestand prüfen

Statement zusammenfügen

Statement ausführen und

Ergebnismenge serialisieren

Export-Datei

Datenbanktabellen

Datenbankprozeduren Views

Items der Konfiguration

Abbildung 5.3: Generierung von Exporten

5 Entwurf

paraten Entitätstypen modelliert. Beispielsweise ist der Entitätstyp für die Erfas-

sung von nicht-pharmakologische Eingriffen (non_pharmalogical) über den Enti-

tätstyp session_content_non_pharmalogical verbunden. Die Erfassungen und zu-

gehörigen Verbindungen werden analog zu Fragebögen beziehungsweise Untersu-

chungen und den Prozessschritten als Items und Links konfiguriert. Es wird somit

gleichermaßen für jede einzuschließende Erfassungsart ein Statement generiert,

welches bestimmt wie viele Erfassungen maximal für die einzuschließenden Pa-

tienten vorhanden sind. Diese Statements werden durch die Datenbankprozedur

ausgeführt und die Ergebnisse in einer Tabelle zwischengespeichert.

Die in Kapitel 4.2.2 identifizierten relevanten Bestandteile des zu generierenden SQL-

Statements werden in jeweils einer View zur Verfügung gestellt. Die SELECT-Liste wird

anhand der ermittelten Informationen und der einzuschließenden Item-Attribute bestimmt.

Die Entitätstypen der relevanten Item-Link-Kombination werden einschließlich der not-

wendigen Verknüpfungsbedingungen in den FROM-Teil des SQL-Statements aufgenom-

men. Die für die Item-Attribute gesetzten Filterkriterien werden, abhängig vom Datentyp

des Attributes, in WHERE-Bedingungen übersetzt.

Die Serveranwendung liest die Bestandteile des generierten SQL-Statements aus den

Views aus und setzt diese zusammen. Das Statement wird ausgeführt und die Ergebnis-

menge in einem CSV-Format serialisiert. Der funktionalen Anforderung F22 entsprechend

wird hierzu die von PHP bereitgestellte Funktion fputcsv[41] verwendet. Das CSV-Format

der Export-Datei wird daher den in [41] genannten Bestimmungen entsprechend festge-

legt. Die Export-Datei wird abschließend persistent auf dem Server abgelegt.

5.2 Datenmodell

Es können, aus den in Kapitel 5.1 erarbeiteten Modellen, Entitätstypen, Attribute und Be-

ziehungen für ein exemplarisches Datenmodel des Export-Moduls der Tinnitus Database

abgeleitet werden. Die einzelnen Entitätstypen, ihre Attribute und die relevanten Bezie-

hungen werden an dieser Stelle zusammengefasst und benannt. Es wird nochmals be-

gründet wie das Ziel der exemplarischen Umsetzung eines verlässlichen, benutzerfreund-

lichen und generischen Moduls, für den Export von Daten der Tinnitus Database, realisiert

5.2 Datenmodell

exp_attribute_types

exp_attribute_type_id INT(11)

description VARCHAR(45)

Indexes

exp_attributes

exp_attribute_id INT(11)

exp_item_id INT(11)

column_name VARCHAR(255)

language_var VARCHAR(255)

exp_attribute_type_id INT(11)

min_value INT(11)

max_value INT(11)

pos INT(11)

Indexes

exp_item_link

exp_item_id INT(11)

exp_link_id INT(11)

is_direct_link BIT(1)

Indexes

exp_items

exp_item_id INT(11)

table_name VARCHAR(255)

language_file VARCHAR(255)

gui_name VARCHAR(255)

Indexes

exp_links

exp_link_id INT(11)

table_name VARCHAR(255)

short_name VARCHAR(45)

Indexes

exp_configs

exp_config_id INT(11)

name VARCHAR(255)

description VARCHAR(1000)

validated_only TINYINT

include_dropouts TINYINT

sex CHAR(1)

age_from INT

age_to INT

age_exp_filter_type_id INT

treatment_code TEXT

center_name VARCHAR(45)

created_at DATETIME

updated_at DATETIME

user_id INT

Indexes

exp_config_attributes

exp_config_attribute_id INT

exp_attribute_id INT(11)

exp_config_id INT(11)

from_value INT

to_value INT

include_attribute TINYINT

exp_filter_type_id INT

Indexes

exp_filter_types

exp_filter_type_id INT

description VARCHAR(45)

Indexes

exp_config_items

exp_config_item_id INT

exp_config_id INT(11)

exp_item_id INT(11)

include_item TINYINT

Indexes

exp_item_numbers

exp_config_id INT(11)

exp_item_id INT(11)

exp_link_id INT(11)

position VARCHAR(45)

number INT

Indexes

Abbildung 5.4: Datenmodell des Export-Moduls

5 Entwurf

werden kann. Das finale Datenmodell des Export-Moduls ist in Abbildung 5.4 dargestellt.

Entitätstyp exp_items

Der Entitätstyp exp_items dient der, entsprechend der funktionalen Anforderungen F9 und

F11 geforderten, Verwaltung der Liste der auswählbaren Items. Die Attribute sind wie folgt

festgelegt:

Attribut Beschreibung

exp_item_id Der Primärschlüssel der jedes Item eindeutig identifiziert.

table_name Der Name der Item-Tabelle im relationalen Modell. Dieser wird benö-

tigt um die nach F20 geforderte FROM-Liste für die laut Konfiguration

ausgewählten Items zu generieren.

language_file Dieses Attribut enthält eine Referenz auf eine Item-spezifische Überset-

zungsdatei. Diese ist erforderlich um die Bezeichner der Item-Attribute

in der Weboberfläche, falls verfügbar, durch die lokalisierten Varian-

ten aus der Tinnitus Database zu ersetzen. Beispielsweise sind die

Bezeichner für die Fragen des WHOQOL-BREF-Fragebogens in den

Übersetzungsdateien mit dem Dateinamen questionnaire-whoqol.php

abgelegt. Die für Domänenexperten gewohnten Bezeichner verbessern

die, nach der nicht-funktionalen Anforderung NF3 geforderte, Benutzer-

freundlichkeit des Export-Moduls.

gui_name Dieses Attribut enthält den in der Weboberfläche anzuzeigenden Item-

spezifischen Bezeichner, da die Übersetzungsdateien teilweise keinen

Bezeichner definieren.

5.2 Datenmodell

Entitätstyp exp_links

Der Entitätstyp exp_links dient der Verwaltung der sogenannten Links, also der möglichen

Prozessschritte und einem Link-Datensatz pro Erfassungsart. Die Attribute sind wie folgt

festgelegt:

Attribut Beschreibung

exp_link_id Der Primärschlüssel der jeden Prozessschritt und jede Erfassungsart

eindeutig identifiziert.

table_name Der Name der Link-Tabelle im relationalen Modell. Dieser wird benötigt

um die nach F20 geforderte FROM-Liste für die laut Konfiguration aus-

gewählten Items zu generieren.

short_name Ein Kurzname der für die Generierung der eindeutigen Spaltennamen

der SELECT-Liste genutzt wird.

Entitätstyp exp_item_links

Der Entitätstyp exp_item_links dient der Verwaltung der im Prozessmodell identifizierten

Zusammenhänge zwischen Prozessschritten und Fragebögen beziehungsweise Untersu-

chungen. Erfassungen und die zugehörigen Verbindungen werden analog zu Fragebö-

gen beziehungsweise Untersuchungen und den Prozessschritten konfiguriert. Die Attribu-

te sind wie folgt festgelegt:

Attribut Beschreibung

exp_item_id Der Primärschlüssel der jedes Item eindeutig identifiziert.

exp_link_id Der Primärschlüssel der jeden Prozessschritt und jede Erfassungsart

eindeutig identifiziert.

is_direct_link Spezifiziert ob die Verbindung im Datenmodell der Tinnitus Database

explizit modelliert ist.

5 Entwurf

Entitätstyp exp_attribute_types

Es ist, entsprechend der funktionalen Anforderung F12, erforderlich die Datentypen der

Item-Attribute innerhalb des Export-Moduls eindeutig zu identifizieren. Der Entitätstyp

exp_attribute_types dient der Verwaltung der unterstützten Datentypen. Die Attribute sind

wie folgt festgelegt:

Attribut Beschreibung

exp_attribute_type_id Der Primärschlüssel der jeden unterstützten Datentyp eindeu-

tig identifiziert.

description Eine Beschreibung des Datentyps. Diese dient lediglich der in-

ternen Dokumentation.

Entitätstyp exp_filter_types

Es ist, beispielsweise entsprechend der funktionalen Anforderung F9 für das Alter der

einzuschließenden Patienten und entsprechend F12 für Item-Attribute mit numerischem

Datentyp, erforderlich Filtertypen innerhalb des Export-Moduls eindeutig zu identifizie-

ren. Es können für numerische Datentypen beispielsweise Größer-, Kleiner-, Gleich- und

Bereichs-Filter unterschieden werden. Die Attribute sind wie folgt festgelegt:

Attribut Beschreibung

exp_filter_type_id Der Primärschlüssel der jeden unterstützten Filtertyp eindeutig

identifiziert.

description Eine Beschreibung des Filtertyps. Diese dient lediglich der internen

Dokumentation.

5.2 Datenmodell

Entitätstyp exp_attributes

Der Entitätstyp exp_attributes dient der, entsprechend der funktionalen Anforderung F14

geforderten, Verwaltung der Liste der auswählbaren Item-Attribute. Die Attribute sind wie

folgt festgelegt:

Attribut Beschreibung

exp_attribute_id Der Primärschlüssel der jedes Item-Attribut eindeutig

identifiziert.

exp_item_id Der Primärschlüssel des Items zu dem das Item-Attribut

gehört.

column_name Der Bezeichner der Spalte des Item-Attributes in der

Tinnitus Database

language_var Dieses Attribut enthält eine Referenz auf eine Item-

Attribut-spezifische Variable. Diese ist erforderlich um

die Bezeichner der Item-Attribute in der Weboberflä-

che, falls verfügbar, durch die lokalisierten Varianten aus

der Tinnitus Database zu ersetzen. Beispielsweise ist

die Variable für die erste Frage des WHOQOL-BREF-

Fragebogens in der deutschen Spracheinstellung mit

„1. Wie würden Sie ihre Lebensqualität beurteilen?“ und

in der englischen Spracheinstellung mit „1. How would

you rate your quality of life?“ belegt.

exp_item_attribute_type_id Spezifiziert den Datentyp des Item-Attributes.

min_value Wenn der Datentyp des Item-Attributes nummerisch ist,

enthält dieses Attribut den minimal gültigen Wert in der

Tinnitus Database, ansonsten ist es unbelegt (NULL).

max_value Wenn der Datentyp des Item-Attributes nummerisch ist,

enthält dieses Attribut den maximal gültigen Wert in der

Tinnitus Database, ansonsten ist es unbelegt (NULL).

pos Spezifiziert die Position des Item-Attributes innerhalb des

Items.

5 Entwurf

Entitätstyp exp_configs

Der Entitätstyp exp_configs dient der Verwaltung der Export-Konfigurationen. Die Attribute

ergeben sich unter anderem aus der funktionalen Anforderungen F08 und den in F09

spezifizierten Fragestellungen:

Attribut Beschreibung

exp_config_id Der Primärschlüssel der jede Export-Konfiguration eindeutig iden-

tifiziert.

name Der durch den Anwender festlegbare Name der Export-

Konfiguration.

description Die durch den Anwender festlegbare Beschreibung der Export-

Konfiguration.

validated_only Spezifiziert ob nur validierte Datensätze eingeschlossen werden

sollen.

include_dropouts Spezifiziert ob sogenannte Drop-out-Patienten mit vorzeitigem Stu-

dienabschluss eingeschlossen werden sollen.

sex Spezifiziert ob nur Patienten eines bestimmten Geschlechtes ein-

geschlossen werden sollen.

age_filter_type_id Spezifiziert den Filtertyp für das Alter der einzuschließenden Pati-

enten.

age_from Falls nur Patienten eines bestimmten Alters eingeschlossen wer-

den sollen, spezifiziert dieses Attribut die untere Altersgrenze.

age_to Falls nur Patienten eines bestimmten Alters eingeschlossen wer-

den sollen, spezifiziert dieses Attribut die obere Altersgrenze.

treatment_code Spezifiziert ob nur Patientenstudien mit einem bestimmten Be-

handlungscode eingeschlossen werden sollen.

center_name Spezifiziert ob nur Patienten eines bestimmten Zentrums einge-

schlossen werden sollen.

created_at Der Erstellungszeitpunkt der Export-Konfiguration.

updated_at Der Zeitpunkt an dem die Export-Konfiguration zuletzt bearbeitet

wurde.

user_id Die Generierung eines Exports wird protokolliert indem die zugrun-

deliegende Konfiguration dupliziert und der eindeutige Identifikator

des Anwenders in diesem Attribut gespeichert wird.

5.2 Datenmodell

Entitätstyp exp_config_items

Der Entitätstyp exp_config_items dient der Verwaltung der Items einer Export-Konfiguration.

Die Attribute ergeben sich aus der funktionalen Anforderungen F10:

Attribut Beschreibung

exp_config_item_id Der Primärschlüssel der jedes Item einer Export-Konfiguration

eindeutig identifiziert.

exp_config_id Der Primärschlüssel der zugehörigen Export-Konfiguration.

exp_item_id Der Primärschlüssel der zugehörigen exp_items-Entität.

include_item Spezifiziert ob das Item beim Export eingeschlossen werden soll.

Entitätstyp exp_config_attributes

Der Entitätstyp exp_config_attributes dient der Verwaltung der Item-Attribute einer Export-

Konfiguration. Die Attribute sind wie folgt festgelegt:

Attribut Beschreibung

exp_config_attribute_id Der Primärschlüssel der jedes Item-Attribut einer Export-

Konfiguration eindeutig identifiziert.

exp_config_id Der Primärschlüssel der zugehörigen Export-Konfiguration.

exp_attribute_id Der Primärschlüssel der zugehörigen exp_attributes-Entität.

exp_filter_type_id Spezifiziert den Typ des Filters der für das Item-Attribut an-

gewendet werden soll.

from_value Falls ein entsprechender numerischer Filter für das Item-

Attribut angewendet werden soll, spezifiziert dieses Attribut

die untere Grenze.

to_value Falls ein entsprechender numerischer Filter für das Item-

Attribut angewendet werden soll, spezifiziert dieses Attribut

die obere Grenze.

include_attribute Spezifiziert ob das Item-Attribut beim Export eingeschlossen

werden soll.

5 Entwurf

Entitätstyp exp_item_numbers

Der Entitätstyp exp_item_numbers dient der temporären Speicherung der Anzahl der Pro-

zessschritte beziehungsweise Erfassungen während der Generierung des Export-Statements

für eine gegebene Export-Konfiguration. Die Attribute sind wie folgt festgelegt:

Attribut Beschreibung

exp_config_id Der Primärschlüssel der zugehörigen Export-Konfiguration.

exp_item_id Der Primärschlüssel der zugehörigen exp_items-Entität.

exp_link_id Der Primärschlüssel der zugehörigen exp_links-Entität.

position Die Daten der Prozessschritte sollen nach dem, in allen entspre-

chenden Entitätstypen vorhandenen, Attribut position geordnet expor-

tiert werden. Beispielweise sollen die Attribute des Screenings mit

position 1 vor den Attributen des Screenings mit position 2 exportiert

werden.

number Die Daten der Erfassungen sollen nach dem, in allen entsprechenden

Entitätstypen vorhandenen, Attribut number geordnet exportiert wer-

den. Beispielweise sollen die Attribute der Nicht-pharmakologischen

Eingriffs mit number 1 vor den Attributen der Nicht-pharmakologischen

Eingriffs mit number 2 exportiert werden.

6 Ausgewählte

Implementierungsaspekte

In diesem Kapitel werden ausgewählte Implementierungsaspekte der in Kapitel 5 entwor-

fenen Komponenten vorgestellt und diskutiert. Es wird zunächst in Kapitel 6.1 auf gene-

rische Konzepte eingegangen die eine Erweiterbarkeit des Export-Moduls im Sinne der

funktionalen Anforderungen F11 und F14 ermöglichen. Diese vereinfachen zudem die

Übertragbarkeit des Moduls auf andere System und Forschungsdatenbanken im Sinne

der nicht-funktionalen Anforderung NF5. In Kapitel 6.2 werden während der Durchführung

dieser Arbeit identifizierte technische Limitationen des RDBMS MySQL1genannt und ent-

sprechende Lösungsansätze präsentiert.

6.1 Generische Programmierkonzepte

Es werden in diesem Kapitel drei Konzepte vorgestellt die einen wesentlichen Beitrag

zum generischen Aspekt der Implementierung des Export-Moduls leisten. Es wird in Ka-

pitel 6.1.1 zunächst die Generierung von Code mittels Datenbank-Views erläutert. Die

dynamische Ausführung des generierten Codes wird in Kapitel 6.1.2 dargestellt und ins-

besondere in Bezug auf mögliche Sicherheitsrisiken beleuchtet. Es wird schließlich in

Kapitel 6.1.3 auf die Extraktion und Verwendung von Informationen aus dem Datenmodell

der Tinnitus Database eingegangen.

1MySQL Version 5.5

6 Ausgewählte Implementierungsaspekte

Export-Konfiguration

Zusätzliche Informationen

steuert

nutzen

erzeugen

 Filterkriterien

 Items

 Item-Attribute

 Bezeichner von Tabellen und Spalten

 Anzahl der Prozessschritte

beziegungsweise Erfassungen

Generatoren SQL-Code

Abbildung 6.1: Abstrakte Darstellung der SQL-Codegenerierung

6.1.1 Code-Generierung

Die Generierung der Bestandteile des für einen Export notwendigen SQL-Statements soll,

wie in Abbildung 6.1 dargestellt, zunächst abstrakt betrachtet werden.

Eine gegebene Export-Konfiguration steuert mehrere Generatoren. Beispielsweise legt

die Konfiguration fest welche Patienten eingeschlossen, welche Items und Item-Attribute

exportiert und welche Filterkriterien berücksichtigt werden sollen. Die Generatoren nutzen

zusätzliche Informationen, wie beispielsweise die Bezeichner von Tabellen und Spalten

oder die Anzahl der Prozessschritte beziehungsweise Erfassungen, um die Konfiguration

zu verarbeiten. Diese Daten werden wie in Kapitel 5.2 beschrieben verwaltet beziehungs-

weise gespeichert. Die Generatoren erzeugen jeweils Teilstücke einer SQL-Abfrage, die

schließlich an die Datenbank übermittelt werden kann.

Die Implementierung der für das Export-Modul notwendigen Generatoren kann sowohl auf

Seite der Serveranwendung mit PHP als auch auf Seite der Datenbank mit SQL erfolgen.

Eine Implementierung auf Seite der Datenbank bietet den Vorteil, dass die zur Steuerung

notwendigen Daten der Konfiguration und die zusätzlich erforderlichen Informationen di-

rekt aus den Datenbanktabellen ausgelesen werden können. Ein weiterer Vorteil ergibt

sich daraus, dass der Aufruf und die Ausführung der Generatoren mit jeder Program-

miersprache beziehungsweise Technologie realisiert werden kann die mittels SQL auf ein

RDBMS zugreifen kann. Abbildung 6.2 veranschaulicht dies.

6.1 Generische Programmierkonzepte

Datenbank

Generator View

erzeugen

SELECT part

FROM v_generator

ORDER BY part_order

SELECT ...

FROM ...

WHERE ...

fragt ab

Generator View

Export-Konfiguration

Zusätzliche Informationen

steuert nutzen

zusammengefügt

SQL-Code

fragt ab

Aufrufer

Abbildung 6.2: Veranschaulichung der Code-Generator-Schnittstellen

6.1.2 Dynamische Ausführung von generiertem Code

Der von den Generatoren dynamisch erzeugte SQL-Code wird in der Serveranwendung

zunächst zusammengefügt und anschließend in Form einer sogenannten Raw Expression

ausgeführt. In der Tinnitus Database wird soweit möglich das Eloquent ORM2zum Zugriff

auf die Datenbank verwendet, da die Ausführung von Raw Expressions das Risiko für Si-

cherheitslücken durch sogenannte SQL-Injections erhöht [40]. Sogenannte SQL-Injection-

Points können von Angreifern genutzt werden um eigene SQL Statements auszuführen.

Dies geschieht in vielen Fällen dadurch, dass Eingabeparameter so gewählt beziehungs-

weise manipuliert werden, dass nicht autorisierte SQL Statements auf die Datenbank

übertragen und ausgeführt werden [8].

Die Implementierung eines Export-Moduls muss, vor allem auch in Hinblick auf die in be-

sonderem Maße zu schützenden Patientendaten [10], sorgfältig in Bezug auf mögliche

Risiken bei der Ausführung des dynamisch generierten SQL-Codes geprüft werden. Es

kann hier insbesondere durch die von den Anwendern festlegbaren Filterkriterien, die in

WHERE-Bedingungen übersetzt werden, zu sogenannten Second-Order-Injections kom-

2Object-Relational Mapping, Objektrelationale Abbildung [59]

6 Ausgewählte Implementierungsaspekte

...TSCHQ

MySQL

(Datenbank)

PHP/Laravel

(Server)

Weboberfläche

(Client)

...

13. Bitte beschreiben Sie

mit eigenen Worten, wie

der Tinnitus

normalerweise klingt:

...

Speichern

Item-Attribute der Konf.

Legende

Der Bereich Weboberfläche stellt

Oberflächenelemente (Seiten,

Formulare, Eingabefelder, Buttons) dar.

Der Bereich PHP/Laravel stellt

Schnittstellen der Serveranwendung

dar.

Der Bereich MySQL stellt ,

und die zugehörigen

dar.

Datenfluss:Kontrollfluss:

Schnittstellen

Spalten

Datenbanktabellen

Attribut

einschließen Filterwert

XXX' UNION ALL SELECT

pwd_hash FROM users

WHERE 'a' = 'a

WHERE-Liste

... ...

SELECT-Liste

FROM-Liste

Export Statement

SELECT tschq.question13

FROM tschq

WHERE

AND tschq.question13 =

'XXX' UNION ALL SELECT

pwd_hash FROM users WHERE

'a' = 'a'

Export generieren

Statement ausführen und

Ergebnismenge serialisieren

Export-Datei

tschq_question13

$2y$10$NzuWFJvVukH6iA5isn6UQOImtIy1i

$2y$10$/xMyZJTpwNo4Fp.nEV/8UIQdsPes6

$2y$10$ZBJxScMtyMAis6QZtFfDn.vfHPFXG

$2y$10$TjSDhJo2gQw571Odf6eNth3lkwGci

Export-Datei

(Download)

Views

users

pwd_hash

XXX' UNION ALL SELECT pwd_hash

FROM users WHERE 'a' = 'a

Abbildung 6.3: Beispiel einer Second-Order-Injection

6.1 Generische Programmierkonzepte

men. Es handelt sich dabei um Fälle bei denen Werte zunächst sicher und korrekt in

die Datenbank geschrieben, zu einem späteren Zeitpunkt ausgelesen und erst dann als

Teil eines dynamischen SQL Statements verwendet werden [8]. Abbildung 6.3 stellt eine

potentielle Second-Order-Injection am Beispiel der Tinnitus Database dar.

Der Angreifer gibt in einem Textfeld eine Zeichenkette ein die zunächst korrekt und si-

cher mittels des Eloquent ORM in die Datenbank gespeichert wird. Diese Zeichenkette

wird beim Erstellen des für den Export notwendigen SQL-Statements aus der Datenbank

ausgelesen und an der markierten Stelle im Statement eingefügt. Der Angreifer kann so-

mit unautorisiert Daten aus der Datenbank auslesen die nicht durch das Export-Modul

exportiert werden sollen. Im aufgezeigten Beispiel wird für die 13. Frage des TSCHQ-

Fragebogens „Bitte beschreiben Sie mit eigenen Worten, wie der Tinnitus normalerweise

klingt:“ ein Filterkriterium gewählt, durch das mittels Second-Order-Injection die Passwort-

Hashes aller Anwender ausgelesen werden können. Im Falle der Tinnitus Database wurde

im Zuge dieser Feststellung festgelegt, keine speziellen Filtermöglichkeiten für Zeichen-

ketten anzubieten, da diese zudem für die nachfolgenden Auswertungen nicht relevant

sind.

6.1.3 Informationen zum Datenmodell

Das RDBMS MySQL stellt Informationen zu Tabellen, Spalten und Beziehungen in Form

von mittels SQL abfragbaren Tabellen bereit. Diese sind im sogenannten

information_schema zusammengefasst und können genutzt werden um die initiale Konfi-

guration des Export-Moduls festzulegen. Dies soll am Beispiel der für die

Tinnitus Database auswählbaren Item-Attribute erläutert werden. Diese werden in Enti-

täten des Typs exp_attributes verwaltet, deren Attribute wie folgt belegt werden sollen:

•exp_attribute_id

Der Primärschlüssel der jedes Item-Attribut eindeutig identifiziert. Dieser wird initial

automatisch fortlaufend festgelegt.

•exp_item_id

Der Primärschlüssel des Items zu dem das Item-Attribut gehört. Beispielsweise 15

6 Ausgewählte Implementierungsaspekte

für TSCHQ. Die weiteren initialen Konfigurationswerte können der Datei tinnitusre-

search_db.sql entnommen werden.

•column_name

Der Bezeichner der Spalte des Item-Attributes in der Tinnitus Database. Beispiels-

weise „question_1“ für die erste Frage des WHOQOL-BREF Fragebogens.

•language_var

Dieses Attribut enthält eine Referenz auf eine Item-Attribut-spezifische Variable.

Diese ist erforderlich um die Bezeichner der Item-Attribute in der Weboberfläche,

falls verfügbar, durch die lokalisierten Varianten aus der Tinnitus Database zu er-

setzen. In der Tinnitus Database sind ist der Variablennamen im Großteil der Fälle

identisch zu dem Bezeichnern der Spalte und können daher initial mit diesem vor-

belegt werden. Beispielsweise lautet der Variablennamen für die erste Frage des

WHOQOL-BREF Fragebogens, analog zum Bezeichner der Spalte, „question_1“.

•exp_item_attribute_type_id

Spezifiziert den Datentyp des Item-Attributes. Die initialen Konfigurationswerte kön-

nen der Datei tinnitusresearch_db.sql entnommen werden.

•min_value

Wenn der Datentyp des Item-Attributes nummerisch ist, enthält dieses Attribut den

minimal gültigen Wert in der Tinnitus Database, ansonsten ist es unbelegt (NULL).

•max_value

Wenn der Datentyp des Item-Attributes nummerisch ist, enthält dieses Attribut den

maximal gültigen Wert in der Tinnitus Database, ansonsten ist es unbelegt (NULL).

•pos

Spezifiziert die Position des Item-Attributes innerhalb des Items. Diese kann mit der

ordinalen Position der Spalte vorbelegt werden.

Es kann anhand dieser Vorgaben ein SQL-Statement formuliert werden, mit dem die in-

itiale Belegung der Item-Attribute teilautomatisiert werden kann. Dies verringert den ma-

nuellen Aufwand und das damit einhergehende Risiko von vergessenen oder falsch kon-

figurierten Item-Attributen. Das entsprechende Statement für die initiale Konfiguration der

Tinnitus Database kann dem Quellcode-Listing 6.1 entnommen werden.

6.1 Generische Programmierkonzepte

Listing 6.1: Statement für teilautomatisierte Konfiguration

1INSERT INTO exp_attributes

2(-- exp_attribute_id -- Wird automatisch fortlaufend vergeben

3exp_item_id, column_name, language_var,

4exp_attribute_type_id,

5min_value, max_value, pos )

6SELECT i.exp_item_id, c.column_name, c.column_name AS language_var,

7CASE c.DATA_TYPE WHEN ’int’ THEN 2-- Int

8WHEN ’tinyint’ THEN 3-- Bit

9ELSE 1-- other

10 END AS exp_attribute_type_id,

11 NULL AS min_value, NULL AS max_value, c.ordinal_position AS pos

12 FROM exp_items AS i-- Für alle Items,

13 JOIN information_schema.columns AS c-- finde jede Spalte,

14 ON c.table_name = i.table_name -- die zu der Item-Tabelle

15 WHERE c.table_schema -- und dem Schema

16 = ’tinnitusresearch_db’ -- der Tinnitus Database

17 -- gehört,

18 -- -----------------------------------

19 AND COLUMN_KEY -- Und kein Schlüssel-

20 NOT IN ( ’PRI’, ’MUL’ ) -- attribute ist,

21 -- -----------------------------------

22 AND COLUMN_NAME NOT IN (-- Und keine der folgenden

23 -- ------------------------------ Spalten ist:

24 ’session_content_id’, -- Weitere Schlüssel-

25 ’record_id’, ’type_name’, -- attribute

26 ’session_content_name’, --

27 -- -------------------------------

28 ’number’, -- Nicht gewünscht

29 -- -------------------------------

30 ’created_at’,’updated_at’, -- Werden vom Laravel-

31 ’deleted_at’, -- ORM benötigt

32 -- -------------------------------

33 ’q1_dateofbirth’, -- Attribute des TSCHQ-

34 ’q2_sex’ -- Fragebogens die nicht

35 -- gewünscht sind

36 );

6 Ausgewählte Implementierungsaspekte

Die im Sinne der funktionalen Anforderung F14 gewünschte Erweiterung der Liste der

Item-Attribute kann ferner durch das Hinzufügen der folgenden WHERE-Bedingung un-

terstützt werden.

Listing 6.2: Identifikation von nicht konfigurierten Item-Attributen

1AND NOT EXISTS(-- Spalten sollen zudem nur dann

2SELECT 1-- ausgewählt werden wenn diese

3FROM exp_attributes att -- nicht bereits konfiguriert sind.

4WHERE att.exp_item_id = i.exp_item_id

5AND att.column_name = c.column_name

Es können hiermit, beispielsweise im Falle einer Anpassung oder Erweiterung der Tinnitus

Database, neu hinzukommende Item-Attribut sicher identifiziert und initial konfiguriert

werden. Dies verringert den manuellen Aufwand für die im Sinne der nicht-funktionalen

Anforderung NF5 gewünschte Übertragbarkeit auf andere Systeme und Forschungsda-

tenbanken.

6.2 Technische Limitationen

Es wurden im Rahmen dieser Arbeit zwei für Export-Module relevante technische Limi-

tationen des RDBMS MySQL identifiziert. Diese werden an dieser Stelle genannt sowie

geeignete Lösungsansätze präsentiert.

6.2.1 Maximale Anzahl von Spalten

Die Anzahl der mit einem einzelnen Statement in MySQL der Version 5.5 selektierbaren

Spalten kann begrenzt sein. Dies ist laut der Dokumentation abhängig von der verwende-

ten Storage Engine, den Item-Attribut Datentypen und weiteren Faktoren [34]. Das Limit

für Exporte der Tinnitus Database konnte mit 1000 Spalten pro Abfrage bestimmt wer-

den. Es können beispielsweise bei dem Export des WHOQOL-BREF Fragebogens bis zu

26 Item-Attribute, bei dem des Tinnitus Fragebogens 52, insgesamt also 78 Item-Attribute

ausgewählt werden. Diese Fragebögen werden jeweils in insgesamt fünf Prozessschritten

6.2 Technische Limitationen

MySQL

(Datenbank)

PHP/Laravel

(Server)

Export generieren

Anzahlen der

Item-Entitäten

SELECT-Liste

FROM-Liste

Item-Attribute der Konf.WHERE-Liste

Select-Liste stückweise zusammenfügen

Ergebnismengen stückweise serialisieren

Export-Datei

Items der Konfiguration

Einheitliche Anteile des Statements zusammenfügen

Legende

Der Bereich PHP/Laravel stellt Schnittstellen der

Serveranwendung dar.

Der Bereich MySQL stellt Entitätstypen ,

Datenbankprozeduren und Views dar.

Datenfluss:Kontrollfluss:

Schnittstellen

N:M-Beziehungen:

Datenbanktabellen

Datenbankprozeduren Views

SELECT

Attr1

Attr1000

FROM

WHERE...

SELECT

Attr1001

Attr2000

FROM

WHERE...

Block 1, Patient 1

Block 1, Patient 2

Block 1, Patient M

Block 2, Patient 1

Block 2, Patient 2

Block 2, Patient M

SELECT

FROM

WHERE...

Block N, Patient 1

Block N, Patient 2

Block N, Patient M

Patient 1

Patient 2

Patient M

Allgemeine Daten

Abbildung 6.4: Stückweise Abfrage der Daten

6 Ausgewählte Implementierungsaspekte

ausgefüllt, wobei der Prozessschritte Visit bis zu elf mal wiederholt wird (Siehe Kapitel

4.1.1). Es sind also bereits bei dem Export einer vollständigen Studienteilnahme 1170

Spalten für diese Fragebögen notwendig. Es existieren in der Tinnitus Database bereits

Patienten die an mehreren Studien teilgenommen haben, die Zahl der benötigten Spalten

vervielfacht sich entsprechend.

Die in Kapitel 5.1.3 beschriebene Implementierung des Export-Moduls wurde entspre-

chend so erweitert, dass pro Export mehrere Export-Statements generiert werden. Das

nicht zu überschreitende Limit für die Anzahl der selektierbaren Spalten kann individuell

konfiguriert werden. Die Statements werden entsprechend der in Abbildung 6.4 darge-

stellten Vorgehensweise zusammengefügt, separat ausgeführt und die Ergebnismengen

schließlich Zeilen- und Blockweise serialisiert.

6.2.2 Maximale Anzahl von Joins

In MySQL der Version 5.5 können maximale bis zu 61 Tabellen in einem einzelnen Join

referenziert werden [33]. Diese Schwelle kann, je nach gewählter Join Struktur und in Ab-

hängigkeit der zu exportierenden Items, von generierten Statements überschritten wer-

den. Sollen beispielsweise TSCHQ und WHOQOL-BREF Daten exportiert werden, könn-

te die notwendigen Entitätstypen wie im folgenden Quellcode-Listings 6.3 dargestellt ver-

knüpft werden.

Es werden fünf Referenzen für die Entitätstypen patients,id_translation,centers,

patient_records und sessions benötigt um Patienten- beziehungsweise Zentrums-Daten

abfragen zu können. Die Prozessesschritt-Entitätstypen werden zwar jeweils nur ein mal

referenziert, die Item-Entitätstypen hingegen immer wieder. Das gegebene Beispiel ent-

hält somit 16 Referenzen auf Tabellen. Es liegt unterhalb des von MySQL gesetzten Limits

und wird daher fehlerfrei ausgeführt.

In der Tinnitus Database existieren zwischen den sechs Prozesschritt-Entätstypen3und

den zehn Fragebögen- und zwei Untersuchungs-Entitstypen 53 gültige Verbindungen, was

zu maximal 59 Referenzen in einem einzelnen Join führen kann.

3session_content_screening,session_content_baseline,session_content_wardround,

session_content_final_wardround,session_content_followup,session_content_catamnesis

(Kapitel 4.1.3)

6.2 Technische Limitationen

Listing 6.3: Potentielle Join Struktur

1SELECT ...

2-- ------------------------- Patienten- und Zentrums-Daten --

3FROM patients AS p-- (1)

4JOIN id_translation AS id ON p.patient_id = id.patient_id -- (2)

5JOIN centers c ON id.center_id = c.center_id -- (3)

6JOIN patient_records r ON p.patient_id = r.patient_id -- (4)

7JOIN sessions s ON r.patient_record_id = s.patient_record_id -- (5)

8-- ------------------------------ Prozessschritt Screening --

9LEFT JOIN session_content_screening AS scr -- (6)

10 ON s.session_id = scr.session_id --

11 -- -------------------------- TSCHQ - Nur in Screenings! --

12 LEFT JOIN tschq AS scr_tschq ON ... -- (7)

13 -- -------------------------- WHOQOL-BREF der Screenings --

14 LEFT JOIN whoqol-bref AS scr_whoqol ON ... -- (8)

15 -- ------------------------------- Prozessschritt Baseline --

16 LEFT JOIN session_content_baseline AS bas -- (9)

17 ON s.session_id = bas.session_id --

18 -- --------------------------- WHOQOL-BREF der Baselines --

19 LEFT JOIN whoqol-bref AS bas_whoqol ON ... -- (10)

20 -- --------------------------------- Prozessschritt Visite --

21 LEFT JOIN session_content_wardround AS vis -- (11)

22 ON s.session_id = vis.session_id --

23 -- ----------------------------- WHOQOL-BREF der Visiten --

24 LEFT JOIN whoqol-bref AS vis_whoqol ON ... -- (12)

25 -- -------------------------- Prozessschritt Finale Visite --

26 LEFT JOIN session_content_final_wardround AS fin -- (13)

27 ON s.session_id = fin.session_id --

28 -- --------------------- WHOQOL-BREF der Finalen Visiten --

29 LEFT JOIN whoqol-bref AS fin_whoqol ON ... -- (14)

30 -- ------------------------------- Prozessschritt Followup --

31 LEFT JOIN session_content_followup AS fol -- (15)

32 ON s.session_id = fol.session_id --

33 -- --------------------------- WHOQOL-BREF der Followups --

34 LEFT JOIN whoqol-bref AS fol_whoqol ON ... -- (16)

Der Export einer Erfassung4benötigt jeweils zwei Referenzen, insgesamt also maximal

4Behandlungsschäden (Adverse Events), Begleitende Medikation (Concomittant), Begleiterkrankungen

6 Ausgewählte Implementierungsaspekte

acht. Beispielsweise kann ein Statement für Fragebögen- und Untersuchungs-Daten so-

wie einer beliebigen Erfassungsart mit exakt 61 referenzierten Tabellen fehlerfrei ausge-

führt werden. Das Hinzufügen einer weiteren Erfassungsart würde hingegen einen Fehler

verursachen. Ein weiteres gültiges Beispiel wäre ein Statement für alle Erfassungsarten

und Untersuchungen sowie alle außer zwei der Basis-Fragebögen. Das Hinzufügen ei-

nes weiteren Basis-Fragebogens würde hingegen mit 62 Referenzen das durch MySQL

gegebene Limit übersteigen.

Die beschriebene Problematik tritt also nicht immer auf, sondern ist abhängig von den zu

exportierenden Items. Sie kann für die Tinnitus Database durch eine Anpassung der Join

Struktur, nach dem in Listing 6.4 dargestellten Schema, vermieden werden.

Die Entitätstypen die die Prozessschritte Screening,Baseline,Visit,Final Visit,Followup

und Catamnesis abbilden sind, bezogen auf Anzahl, Typen und Bezeichner ihrer Attri-

bute, kongruent. Sie können in einer Unterabfrage mittels des UNION ALL Operators

wie in Listing 6.4 zusammengefasst werden. Im gegebenen Beispiel wird die Unterab-

frage mit dem Alias sc benannt. Die Item Entitätstypen können über diese Unterabfrage

verknüpft werden. Es werden weiterhin sechs Referenzen für die Prozessschritte benö-

tigt, es ist hingegen nicht notwendig die Items immer wieder zu referenzieren. Die An-

zahl der maximal notwendigen Referenzen verringert sich somit für die Tinnitus Database

von 67 auf 31:

•Fünf Referenzen für die Abfrage der Patienten- beziehungsweise Zentrums-Daten

•Sechs Referenzen für die Prozessschritte

•Maximal zehn Referenzen für die Fragebögen-Entitstypen

•Maximal zwei Referenzen für die Untersuchungs-Entitstypen

•Maximal acht Referenzen für Erfassungen

(Comorbidity), Nicht-pharmakologische Eingriffe (Non Pharmalogical) (Kapitel 4.1.1)

6.2 Technische Limitationen

Listing 6.4: Angepasste Join Struktur

1SELECT ...

2-- ------------------------- Patienten- und Zentrums-Daten --

3FROM patients AS p-- (1)

4JOIN id_translation AS id ON p.patient_id = id.patient_id -- (2)

5JOIN centers c ON id.center_id = c.center_id -- (3)

6JOIN patient_records r ON p.patient_id = r.patient_id -- (4)

7JOIN sessions s ON r.patient_record_id = s.patient_record_id -- (5)

8JOIN --

9(SELECT session_content_id, session_id, type_name --

10 FROM session_content_screening -- (6)

11 UNION ALL --

12 SELECT session_content_id, session_id, type_name --

13 FROM session_content_baseline -- (7)

14 UNION ALL --

15 SELECT session_content_id, session_id, type_name --

16 FROM session_content_wardround -- (8)

17 UNION ALL --

18 SELECT session_content_id, session_id, type_name --

19 FROM session_content_final_wardround -- (9)

20 UNION ALL --

21 SELECT session_content_id, session_id, type_name --

22 FROM session_content_followup -- (10)

23 UNION ALL --

24 SELECT session_content_id, session_id, type_name --

25 FROM session_content_catamnesis -- (11)

26 )AS sc ON s.session_id = sc.session_id --

27 -- ------------------------------------------------- TSCHQ --

28 LEFT JOIN tschq ON ... -- (12)

29 -- ------------------------------------------- WHOQOL-BREF --

30 LEFT JOIN whoqol-bref ON ... -- (13)

Es konnte für die Tinnitus Database mittels einer symmetrischen Differenz nachgewiesen

werden [49], dass die vorgestellten Join Strukturen dieselbe Ergebnismenge produzieren.

6 Ausgewählte Implementierungsaspekte

7 Anforderungsabgleich

Es werden an dieser Stelle die in Kapitel 4.3 dokumentierten und priorisierten Anforde-

rungen mit der exemplarischen Realisierung des Export-Moduls für die Tinnitus Database

abgeglichen. Die funktionalen und nicht-funktionalen Anforderungen werden dabei einzeln

begutachtet und der Grad der Zielerfüllung auf einer einheitlichen Skala bewertet. Es soll

so sichergestellt werden, dass das Export-Modul geeignete Lösungen für die identifizier-

ten und weitere Problemstellungen liefert. Die Skala wird wie folgt festgelegt:

(5) Die Anforderung wurde vollständig erfüllt.

(4) Die Anforderung wurde zufriedenstellend erfüllt.

(3) Die Anforderung wurde nicht zufriedenstellend erfüllt.

(2) Die Anforderung ist noch nicht fertiggestellt.

(1) Die Anforderung wurde vorbereitet.

(0) Die Anforderung wurde nicht erfüllt.

7.1 Funktionale Anforderungen

Die zur Erfüllung der Zielsetzung notwendigen Funktionalitäten des Export-Moduls wer-

den durch die in Kapitel 4.3.1 beschriebenen funktionalen Anforderungen festgelegt. Die

Anforderungen sollen einzeln begutachtet und der Grad der Zielerfüllung anhand der ein-

gangs vorgestellten Skala bewertet werden.

7 Anforderungsabgleich

ID Bezeichnung Priorität Erfüllungsgrad

Export-Konfiguration

F01 Technische Rahmenbedingungen MUSS (4)

F02 Autorisierung MUSS (5)

F03 Konfiguration neu erstellen MUSS (4)

F04 Vorhandene Konfigurationen sichten MUSS (4)

F05 Konfigurationen anderer Anwender MUSS (4)

F06 Vorhandene Konfiguration bearbeiten MUSS (4)

F07 Vorhandene Konfiguration duplizieren MUSS (4)

F08 Bezeichnung und Beschreibung festlegen MUSS (4)

F09 Filterkriterien festlegen MUSS (4)

F10 Gewünschte Items auswählen MUSS (5)

F11 Liste der Items erweiterbar SOLL (5)

F12 Filterkriterien für Item-Attribute festlegen MUSS (4)

F13 Gewünschte Item-Attribute auswählen MUSS (4)

F14 Liste der Item-Attribute erweiterbar SOLL (5)

F15 Anzahl der Datensätze prüfbar SOLL (5)

F16 Export-Generierung starten MUSS (5)

F17 Download der Export-Datei MUSS (4)

Export-Generierung

F18 Verarbeitung von Konfigurationen MUSS (4)

F19 Generierung der SELECT-Liste MUSS (4)

F20 Generierung der FROM-Liste MUSS (4)

F21 Generierung der WHERE-Bedingungen MUSS (4)

F22 Standardisierte Serialisierung SOLL (5)

F23 Ablage der Export-Datei MUSS (4)

F24 Protokollierung von Exporten MUSS (4)

F25 Protokollierung der Konfiguration SOLL (5)

F26 Weitere Ausgabeformate KANN (2)

Tabelle 7.1: Bewertung der funktionalen Anforderungen an das Export-Modul

7.2 Nicht-Funktionale Anforderungen

Die zu erbringende Qualität der geforderten Funktionalitäten kann in Form von nicht-

funktionalen Anforderungen festgelegt werden. Die in Kapitel 4.3.2 beschriebenen nicht-

funktionalen Anforderungen des Export-Moduls werden im Folgenden einzeln begutachtet

und der Grad der Zielerfüllung anhand der eingangs vorgestellten Skala bewertet.

ID Bezeichnung Priorität Erfüllungsgrad

NF1 Zuverlässigkeit MUSS (4)

NF2 Sicherheit/Datenschutz MUSS (4)

NF3 Benutzerfreundlichkeit SOLL (5)

NF4 Effizienz SOLL (3)

NF5 Übertragbarkeit SOLL (4)

NF6 Wartbarkeit MUSS (4)

Tabelle 7.2: Bewertung der Nicht-funktionalen Anforderungen an das Export-Modul

7 Anforderungsabgleich

8 Zusammenfassung und Ausblick

Die Inhalte und erarbeiteten Ergebnisse werden in Kapitel 8.1 nochmals zusammenfas-

send wiedergegeben. Kapitel 8.2 schließt die Arbeit mit einem Ausblick auf Chancen für

Erweiterungen und Ergänzungen der Tinnitus Database und der Möglichkeiten die in For-

schungsdatenbanken verwalteten Patienten-, Behandlungs- und Studiendaten zu analy-

sieren und aufzubereiten.

8.1 Zusammenfassung

Das primäre Ziel dieser Arbeit war es Modelle, Vorgehensweisen und Konzepte zu erarbei-

ten, zu erproben und zu diskutieren, die dazu geeignet sind Forschungsdatenbanken zu

analysieren und deren Daten abzufragen. Es sollte hierzu geprüft werden wie die Möglich-

keiten von Domänenexperten zur Verarbeitung und Auswertung von Daten erweitert und

ergänzt werden können. Es wurde gezeigt, wie ein Software-Modul spezifiziert, entworfen

und umgesetzt werden kann, dass Domänenexperten bei der Identifikation, Auswahl und

Filterung relationaler Daten unterstützt.

Das praktische Ziel dieser Arbeit, die Konzeption und Realisierung eines generischen Mo-

duls zum Export der Patientendaten der Tinnitus Database konnte erfolgreich umgesetzt

werden. Der Nachweis der Tragfähigkeit der erarbeiteten Ergebnisse konnte anhand die-

ser exemplarischen Realisierung geführt werden. Es konnte diesbezüglich argumentiert

werden, dass die erarbeiteten Konzepte und Lösungen ebenso auf vergleichbare For-

schungsdatenbanken übertragen werden können. Es wurde darüber hinaus eine intensive

Kooperation mit Domänenexperten der Tinnitus Research Initiative aufgebaut um sicher-

zustellen, dass das Export-Modul geeignete Lösungen für praktische Problemstellungen

liefert.

8 Zusammenfassung und Ausblick

Das entwickelte Modul bietet Domänenexperten ein benutzerfreundliches System für die

Definition und Durchführung von Datenexporten und erleichtert somit die Erstellung von

umfangreichen und differenzierten wissenschaftlichen Auswertungen. Das Modul unter-

stützt die Domänenexperten hierzu bei der Identifikation, Auswahl, Filterung und dem

Export von Patientendaten. Es konnten Vorgehensweisen und Konzepte diskutiert und

erprobt werden, die eine generische Erweiterbarkeit der exemplarischen Realisierung

des Export-Moduls ermöglichen. Diese vereinfachen zudem die Übertragbarkeit des Mo-

duls auf andere System und Forschungsdatenbanken. Es wurden außerdem während der

Durchführung dieser Arbeit identifizierte technische Limitationen des RDBMS MySQL ge-

nannt und entsprechende Lösungsansätze präsentiert.

Es konnte anhand von funktionalen Anforderungen und nicht-funktionalen Qualitätskrite-

rien argumentiert werden, dass die in dieser Arbeit erarbeiteten, erprobten und diskutier-

ten Modelle, Vorgehensweisen und Konzepte dazu geeignet sind Forschungsdatenban-

ken zu analysieren und deren Daten zu exportieren. Die exemplarische Realisierung des

Export-Moduls der Tinnitus Database wurde abschließend anhand der funktionalen und

nicht-funktionalen Anforderungen geprüft und bewertet. Es kann zusammenfassend fest-

gestellt, dass das Export-Modul geeignete Lösungen für die in dieser Arbeit identifizierten

Problemstellungen liefert.

8.2 Ausblick

Die an der Tinnitus Database durchgeführten Analysen ergaben verschiedene mögliche

Anpassungen am Datenmodell die in Kapitel 8.2.1 beschrieben und bewertet werden.

Die Erfüllung der Ziele dieser Arbeit eröffnet außerdem zahlreiche Lösungsmöglichkei-

ten für weitere sich bei der Auswertung und dem Export von Patientendaten ergebende

Problemstellungen. In Kapitel 8.2.2 werden potentielle Erweiterungspunkte der Tinnitus

Database identifiziert die dazu genutzt werden können generische Schnittstellen für eine

Kette von Werkzeugen zu implementieren. Dies soll, basierend auf dem in dieser Arbeit

realisierten Datenexport, eine Vielzahl von Ausgabeformaten und Repräsentation für die

Daten der Tinnitus Database ermöglichen.

8.2 Ausblick

8.2.1 Mögliche Anpassungen am Datenmodell

Die in 4.1.3 durchgeführte Untersuchung ergab verschiedene mögliche Anpassungen am

Datenmodell der Tinnitus Database. Es sollen an dieser Stelle zwei Beispiele beschrieben

und in Bezug auf Aufwand und Risiko bewertet werden.

Entfernung des Entitätstyp patient_records

Der Entitätstyp patient_records verknüpft den Entitätstyp patients mit dem Entitätstyp

sessions. Das Datenmodell erlaubt zwar, dass einem Patienten mehrere Entitäten in

patient_records zugeordnet werden können, in der Implementierung der Tinnitus Database

ist zum Zeitpunkt der Erstellung dieser Arbeit allerdings genau eine Entität pro Patient

vorgesehen. Der Entitätstyp sessions könnte somit direkt mit dem Entitätstyp patients

verknüpft werden wodurch der Entitätstyp patient_records nicht mehr benötigt würde. Der

Nutzen dieser Anpassung lässt sich zu einem gewissen Maße mit der Maxime eines mög-

lichst kompakten Datenmodells beziehungsweise einer möglichst kompakten Implemen-

tierung, insbesondere aber mit der Auflösung einer Diskrepanz begründen. Diese ergibt

sich aus dem Umstand, dass die Studienteilnahmen eines Patienten auf der Oberfläche

und dementsprechend im Prozessmodell als Records bezeichnet werden im Datenmo-

dell jedoch nicht im Entitätstyp patient_record sondern im Entitätstyp sessions abgebildet

werden. Die bei Entfernung des Entitätstypen notwendigen Anpassungen an der Imple-

mentierung und der Aufwand für die Nachführung der vorhandenen Datensätze können

als verhältnismäßig gering betrachten werden. Das potentielle Risiko, beispielsweise von

Datenverlust, Inkonsistenzen oder Programmierfehlern, kann gleichermaßen als gering

eingeschätzt werden.

Zusammenfassung der Prozessschritt-Entitätstypen

Die Entitätstypen die die Prozessschritte Screening,Baseline,Visit,Final Visit,Followup

und Catamnesis abbilden sind, bezogen auf Anzahl, Typen und Bezeichner ihrer Attribute,

kongruent. Das Attribut type_name wird durch die Implementierung der

Tinnitus Database stets mit demselben Wert, dem Namen des Entitätstypes1, belegt,

1Beispielsweise die Zeichenkette ’session_content_screening’ im Fall des Entitätstypen für den Prozess-

schritt Screening

8 Zusammenfassung und Ausblick

was der Maxime eines möglichst redundanzfreien Datenmodells widerspricht. Eine Un-

terscheidung der Prozessschritt-Entitäten kann also nicht nur über den Bezeichner des

Entitätstypen, sondern ebenso über den Wert des Attributes type_name erfolgen. Die

Prozessschritt-Entitätstypen könnten somit zu einem Entitätstypen zusammengefasst wer-

den. Der Nutzen dieser Anpassung lässt sich zum einen mit der Maxime eines möglichst

kompakten Datenmodells begründen. Es wäre dann jedoch insbesondere möglich die,

aktuell durch die Implementierung, implizit vorgegebenen Fremdschlüsselbeziehungen zu

den Fragebögen- beziehungsweise Untersuchungs-Entitätstypen explizit im Datenmodell

festzuschreiben. Der Aufwand für die Nachführung der vorhandenen Datensätze kann als

verhältnismäßig gering betrachtet werden. Das Potential für Programmierfehler kann, auf-

grund der Menge der notwendigen Anpassungen an den unterschiedlichen Modulen, hin-

gegen als sehr hoch eingeschätzt werden. Eine Umsetzung ist dennoch empfehlenswert,

falls die Notwendigkeit für Anpassungen an den Modulen im Rahmen einer umfassenden

Neugestaltung der Tinnitus Database entfällt.

8.2.2 Zukunft der Tinnitus Database

Einer der wesentlichen Beweggründe für die zentrale Erfassung von Patienten-, Behand-

lungs- und Studiendaten ist das Bestreben den Umfang und die Aussagekraft der abgelei-

teten Auswertungen und Publikationen zu erhöhen. Diese Arbeit eröffnet neue Möglichkei-

ten Daten mit Verfahren und Werkzeugen für statistische Berechnungen, Visualisierungen

und Analysen auswerten zu können. Die exemplarische Realisierung des Export-Moduls

für die Tinnitus Database konnte im Rahmen eines Workshops in direkter Zusammenar-

beit mit den Domänenexperten der Tinnitus Research Initiative nochmals kritisch diskutiert

und finalisiert werden. Sie erlaubt es der TRI zukünftig umfangreichere und aussagekräf-

tigere Auswertungen und Publikationen zu erstellen und somit im Bereich der Erforschung

und Behandlung von Tinnitus führend zu bleiben. Die vorgeschlagenen Anpassungen am

Datenmodell können außerdem Synergieeffekte für andere Forschungsdatenbanken wie

die der European School for Interdisciplinary Tinnitus Research (ESIT ) ermöglichen.

Es handelt sich dabei um ein von der Europäischen Union gefördertes Projekt zur Verbes-

serung bestehender und Entwicklung neuer Behandlungsmethoden für Tinnitus. Im Rah-

men dieses Projektes sollen innovative Forschungsmethoden implementiert, die weltweit

8.2 Ausblick

erste genetische Studie über Tinnitus durchgeführt und der größte paneuropäische Tinni-

tus Datensatz aufgebaut werden. Dies soll die Implementierung von innovativen Lösungen

für personalisierte Tinnitus Behandlung erlauben und somit dabei helfen das individuelle

Leid der Betroffen zu lindern. ESIT wird damit eine zukünftige Generation von kreativen,

energischen und innovativen Forschenden für die Europäische Forschungslandschaft auf-

bauen, die dazu ausgebildet sind die aufkommenden Herausforderungen in ihren Feldern

zu meistern, nachhaltige Lösungen im klinischen Management von Tinnitus zu implemen-

tieren und PhD-Studiengänge für nachfolgenden Studierende zu gestalten [32].

Der modulare Aufbau der Tinnitus Database und die generische Realisierung des Export-

Moduls sollen zur schnellen Wiederverwendbarkeit und dem langfristigen Erfolg der vom

Team des Instituts für Datenbanken und Informationssysteme der Universtät Ulm und des

Lehrstuhls für Psychiatrie und Psychotherapie an der Universität Regensburg entwickel-

ten Plattformen beitragen. Diese Arbeit dient zwar dem besseren Verständnis des Tinni-

tusleidens und der Entwicklung von effektiveren Behandlungsmethoden, die erarbeiteten,

erprobten und diskutierten Modelle, Vorgehensweisen und Konzepte können jedoch auch

in der Erforschung und Behandlung anderer Leiden Wiederverwendung finden.

Literaturverzeichnis

[1] ADJAMIAN, P. ; SEREDA, M. ; HALL, D. A.: The mechanisms of tinnitus: Perspectives

from human functional neuroimaging. In: Hearing Research 253 (2009), Nr. 1-2, S.

15–31. – ISSN 1878–5891

[2] APACHE OPENOFFICE WIKI:Comma Separated Values – Apache OpenOffice Wiki.

https://wiki.openoffice.org/wiki/Csv. Version: 07.10.2017. – Online;

zuletzt besucht am 07.10.2017

[3] BAGULEY, D. M. ; MCFERRAN, D. J.: Current perspectives on tinnitus. In: Archives of

Disease in Childhood 86 (2002), Nr. 3, S. 141–143. – ISSN 0003–9888

[4] BERNER, D. : Tinnitus Subtyping Study: Case Report Form. 2013

[5] BIESINGER, E. ; L, D. B. ; DE, R. D. ; GOODEY, R. ; HERRAIZ, C. ; KLEINJUNG, T.

; LAINEZ, J. M. ; M, L. ; LANGGUTH, B. AND, L. A. ; PAOLINO, M. ; QUESTIER, B. ;

SANCHEZ, T. ; SEARCHFIELD, G. ; SPRINGER (Hrsg.): Algorithm for the Diagnostic &

Therapeutic Management of Tinnitus. 2008. – Online; zuletzt besucht am 07.10.2017

[6] BOENNINGHAUS, H.-G. ; LENARZ, T. : Hals-Nasen-Ohrenheilkunde. 12., Aufl. Berlin

[u.a.] : Springer, 2005 (SpringerLink: Springer e-Books). – ISBN 3540219692

[7] BRACE, N. ; KEMP, R. ; SNELGAR, R. : SPSS for psychologists. Basingstoke :

Palgrave Macmillan, 2009. – ISBN 0–230–59459–X

[8] CLARKE, J. : SQL injection attacks and defense. 2nd ed. Waltham, Mass. : Elsevier,

2012. – ISBN 978–1–59749–973–6

[9] DANIELL, W. E. ; FULTON-KEHOE, D. ; SMITH-WELLER, T. ; FRANKLIN, G. M.:

Occupational hearing loss in Washington state, 1984–1991: II. morbidity and

Literaturverzeichnis

associated costs. In: American Journal of Industrial Medicine 33 (1998), Nr. 6, S.

529–536. – ISSN 1097–0274

[10] DEUTSCHER BUNDESTAG:Bundesdatenschutzgesetz: BDSG.https:

//www.gesetze-im-internet.de/bdsg_1990/BJNR029550990.html.

Version: 14/01/2003. – Online; zuletzt besucht am 07.10.2017

[11] DEUTSCHES INSTITUT FÜR MEDIZINISCHE DOKUMENTATION UND INFORMATION:

Krankheiten des Ohres und des Warzenfortsatzes: DIMDI - ICD-10-WHO

Version 2016.http://www.dimdi.de/static/de/klassi/icd-10-who/

kodesuche/onlinefassungen/htmlamtl2016/block-h90-h95.htm.

Version: 2016. – Online; zuletzt besucht am 07.10.2017

[12] DOBIE, R. A.; SNOW, J.B.: Overview: suffering from tinnitus: Tinnitus: Theory and

management. (2004), S. 1–7

[13] DT. GES.F. HNO-HEILKUNDE: Tinnitus: Leitlinien der Dt. Ges. f. Hals-Nasen-

Ohren-Heilkunde, Kopf- und Hals-Chirurgie. (1998). http://www.phoniatrie-

paedaudiologie.com/Informationen/HoersturzTinnitus/assets/

AWMFonline-Leitlinie%20HNO-Tinnitus.pdf. – Online; zuletzt besucht

am 07.10.2017

[14] FACKRELL, K. ; HALL, D. A. ; BARRY, J. G. ; HOARE, D. J.: Psychometric properties

of the Tinnitus Functional Index (TFI): Assessment in a UK research volunteer

population. In: Hearing Research 335 (2016), S. 220–235. – ISSN 1878–5891

[15] GAMMA, E. ; RIEHLE, D. : Entwurfsmuster: Elemente wiederverwendbarer

objektorientierter Software. München [u.a.] : Addison Wesley, 2009 (Programmer’s

choice). – ISBN 978–3827321992

[16] GEERS HÖRAKUSTIK GMBH & CO. KG: Tinnitus – Ursachen und Behandlung.

https://www.geers.de/tinnitus#2. – Online; zuletzt besucht am 07.10.2017

[17] GOEBEL, G. ; HILLER, W. ; HOGREFE VERLAG (Hrsg.): Strukturiertes Tinnitus-

Interview - Medizinpsychologische Verfahren - Tests – Hogrefe, Verlag für

Psychologie.https://www.testzentrale.de/shop/strukturiertes-

tinnitus-interview.html. Version: 2001. – Online; zuletzt besucht am

07.10.2017

Literaturverzeichnis

[18] GREIMEL, K. V. ; LEIBETSEDER, M. ; UNTERRAINER, J. ; ALBEGGER, K.: Ist

Tinnitus meßbar? Methoden zur Erfassung tinnitusspezifischer Beeinträchtigungen

und Präsentation des Tinnitus-Beeinträchtigungs-Fragebogens (TBF-12). In: HNO

47 (1999), Nr. 3, S. 196–201. – ISSN 0017–6192. – Online; zuletzt besucht am

07.10.2017

[19] GUPTA, G. : Mastering HTML5 forms. Birmingham, UK : Packt Pub, 2013 (create

dynamic and responsive web forms with this in-depth, hands-on guide). – ISBN 978–

1–78216–466–1

[20] HAHN, J. B.: Generische Programmierung bei der Entwicklung von

rahmenwerkbasierten Software-Architekturen. Hamburg, Universität Hamburg,

Diplomarbeit, 21/05/2005. https://swa.informatik.uni-hamburg.de/

files/abschlussarbeiten/Diplomarbeit.8hahn.pdf. – Online; zuletzt

besucht am 07.10.2017

[21] HENRY, JAMES A.: Tinnitus Functional Index: Development and Clinical

Application. (2014). https://www.audiology.org/sites/default/

files/publications/tinnitusFunctionalIndex.pdf. – Online; zuletzt

besucht am 07.10.2017

[22] HESSE, G. (Hrsg.) ; SCHAAF, H. (Hrsg.): Manual der Hörtherapie: Schwerhörigkeit,

Tinnitus und Hyperakusis. 1. Aufl. Stuttgart and New York : Thieme, 2012. – ISBN

9783131639219

[23] HOUSE, J. W. ; BRACKMANN, D. E.: Tinnitus: surgical treatment. In: Ciba Foundation

symposium 85 (1981), S. 204–216. – ISSN 0300–5208

[24] IBM: Is it possible to import a .csv file into IBM SPSS Statistics? - Deutschland.

http://www-01.ibm.com/support/docview.wss?uid=swg21480145.

Version: 21.12.2016. – Online; zuletzt besucht am 07.10.2017

[25] KOBALTZ:visual sql query generator for ruby on rails - Stack Overflow.

https://stackoverflow.com/questions/15366762/visual-sql-

query-generator-for-ruby-on-rails. – Online; zuletzt besucht am

07.10.2017

Literaturverzeichnis

[26] LANTING, C. P. ; KLEINE, E. de ; VAN DIJK, P. : Neural activity underlying tinnitus

generation: Results from PET and fMRI. In: Hearing Research 255 (2009), Nr. 1-2,

S. 1–13. – ISSN 1878–5891

[27] LENARZ, T. : Medikamentöse Tinnitus-Therapie: Klinische und tierexperimentelle

Untersuchung zur Pharmakologie der Hörbahn. Stuttgart : Thieme, 1989

[28] LEVINE, R. A.: Somatic (craniocervical) tinnitus and the dorsal cochlear nucleus

hypothesis. In: American Journal of Otolaryngology 20 (1999), Nr. 6, S. 351–362. –

ISSN 0196–0709

[29] M.C. ANGERMEYER ; R. KILIAN ; H. MATSCHINGER:WHOQOL-100 und

WHOQOL-BREF. Handbuch für die deutsche Version der WHO Instrumente zur

Erfassung von Lebensqualität. 1. Göttingen : Hogrefe Verlag, 2000. – Online; zuletzt

besucht am 07.10.2017

[30] MCCOOL, S. : Laravel Starter. Birmingham : Packt Publishing, 2012

[31] MICROSOFT:Import or export text (.txt or .csv) files.https://

support.office.com/en-us/article/Import-or-export-text-txt-

or-csv-files-5250ac4c-663c-47ce-937b-339e391393ba. – Online;

zuletzt besucht am 07.10.2017

[32] MUNDBROT, N. : European School for Interdisciplinary Tinnitus Research (ESIT):

About ESIT.https://esit.tinnitusresearch.net/index.php/esit/

about-itn-esit. Version: 2017. – Online; zuletzt besucht am 07.10.2017

[33] MYSQL: MySQL 5.5 Reference Manual: Limits on Joins.https://

dev.mysql.com/doc/refman/5.5/en/joins-limits.html. Version: 2017.

– Online; zuletzt besucht am 07.10.2017

[34] MYSQL: MySQL 5.5 Reference Manual: Limits on Table Column Count

and Row Size.https://dev.mysql.com/doc/refman/5.5/en/column-

count-limit.html. Version:2017. – Online; zuletzt besucht am 07.10.2017

[35] NEUHAUS, C. : Terror im Ohr: Tinnitus. In: Psychotherapeut 47 (2002), Nr. 5, S. 315.

– ISSN 0935–6185. – Online; zuletzt besucht am 07.10.2017

Literaturverzeichnis

[36] NEWMAN, C. W. ; SANDRIDGE, S. A. ; JACOBSON, G. P.: Psychometric adequacy of

the Tinnitus Handicap Inventory (THI) for evaluating treatment outcome. In: Journal

of the American Academy of Audiology 9 (1998), Nr. 2, S. 153–160. – ISSN 1050–

0545

[37] NIDCD: Tinnitus.https://www.nidcd.nih.gov/health/tinnitus.

Version: 2017. – Online; zuletzt besucht am 07.10.2017

[38] NONDAHL, D. M. ; CRUICKSHANKS, K. J. ; WILEY, T. L. ; KLEIN, R. ; KLEIN, B. E. K.

; TWEED, T. S.: Prevalence and 5-year incidence of tinnitus among older adults:

The epidemiology of hearing loss study. In: Journal of the American Academy of

Audiology 13 (2002), Nr. 6, S. 323–331. – ISSN 1050–0545

[39] NOREÑA, A. J.: An integrative model of tinnitus based on a central gain controlling

neural sensitivity. In: Neuroscience & Biobehavioral Reviews 35 (2011), Nr. 5, S.

1089–1109. – ISSN 0149–7634

[40] OTWELL, T. : Laravel - The PHP Framework For Web Artisans: Database Query

Builder.https://laravel.com/docs/4.2/queries#raw-expressions.

Version: 2017. – Online; zuletzt besucht am 07.10.2017

[41] PHP GROUP:PHP: fputcsv - Manual.http://php.net/manual/de/

function.fputcsv.php. Version: 2017. – Online; zuletzt besucht am 07.10.2017

[42] PILGRAMM, M. ; RYCHLIK, R. ; LEBISCH, H. ; SIEDENTOP, H. ; GOEBEL, G. ;

KIRCHHOFF, D. : Tinnitus in der Bundesrepublik Deutschland. Eine repräsentative

epidemiologische Studie. In: HNO aktuell 7 (1999), Nr. 4, S. 261–265

[43] PROBST, R. : Hals-Nasen-Ohren-Heilkunde. 3. Auflage. Stuttgart : Iro, H., 2008

[44] PROBST, T. ; PRYSS, R. ; LANGGUTH, B. ; SPILIOPOULOU, M. ; LANDGREBE, M. ;

VESALA, M. ; HARRISON, S. ; SCHOBEL, J. ; REICHERT, M. ; STACH, M. ; SCHLEE, W.

: Outpatient Tinnitus Clinic, Self-Help Web Platform, or Mobile Application to Recruit

Tinnitus Study Samples? In: Frontiers in Aging Neuroscience 9 (2017), April, S. 113–

113

[45] REISS, M. : Facharztwissen HNO-Heilkunde: Differenzierte Diagnostik und Therapie

; mit 142 Tabellen. Heidelberg : Springer, 2009. – ISBN 978–3–540–89441–4

Literaturverzeichnis

[46] RIPLEY, B. : R Data Import/Export.https://cran.r-project.org/doc/

manuals/r-release/R-data.html. Version:02.10.2017. – Online; zuletzt

besucht am 07.10.2017

[47] RITTER, J. ; EISLER, R. : Historisches Worterbuch Der Philosophie: Völlig

Neubearbeitete Ausgabe Des Worterbuchs Der Philosophischen Begriffe / Von

Rudolf Eisler, Band 1 : A-C. Basel : Schwabe, 1971. – ISBN 978–3–7965–0115–

[48] RUSSELL, C. : Bridging the Object-Relational Divide. In: Queue 6 (2008), Nr. 3, S.

18–28. – ISSN 1542–7730

[49] SAAKE, G. ; HEUER, A. ; SATTLER, K.-U. : Datenbanken: Implementierungstechniken.

3. Aufl. Heidelberg [u.a.] : mitp, 2011. – ISBN 978–3826691560

[50] SANCHEZ, T. G. ; ROCHA, C. B.: Diagnosis and management of somatosensory

tinnitus: Review article. In: Clinics (Sao Paulo, Brazil) 66 (2011), Nr. 6, S. 1089–

1094. – ISSN 1980–5322

[51] SCHAETTE, R. ; KEMPTER, R. : Development of tinnitus-related neuronal hyperactivity

through homeostatic plasticity after hearing loss: A computational model. In:

European Journal of Neuroscience 23 (2006), Nr. 11, S. 3124–3138. – ISSN 1460–

9568

[52] SCHLEE, W. ; MUELLER, N. ; HARTMANN, T. ; KEIL, J. ; LORENZ, I. ; WEISZ, N. :

Mapping cortical hubs in tinnitus. In: BMC biology 7 (2009), S. 80. – ISSN 1741–

7007

[53] SCHLEE, W. ; WEISZ, N. ; BERTRAND, O. ; HARTMANN, T. ; ELBERT, T. : Using

Auditory Steady State Responses to Outline the Functional Connectivity in the

Tinnitus Brain. In: PLOS ONE 3 (2008), Nr. 11, S. e3720. – ISSN 1932–6203. –

Online; zuletzt besucht am 07.10.2017

[54] SCHNECK, A. ; KALLE, S. ; PRYSS, R. ; SCHLEE, W. ; PROBST, T. ; LANGGUTH,

B. ; LANDGREBE, M. ; REICHERT, M. ; SPILIOPOULOU, M. : Studying the Potential

of Multi-Target Classification to Characterize Combinations of Classes with Skewed

Distribution. In: 30th IEEE International Symposium on Computer-Based Medical

Systems (CBMS 2017), IEEE Computer Society Press, June 2017

100

Literaturverzeichnis

[55] STACH, M. : Konzeption und Realisierung eines Rahmenwerks zur Unterstützung

von Therapeuten bei der Durchführung von Patientenbehandlungen. Ulm, Universität

Ulm, Masterarbeit, 2016

[56] STAUD, J. L.: Datenmodellierung und Datenbankentwurf: Ein Vergleich aktueller

Methoden. 1. Aufl. Berlin : Springer, 2005. – ISBN 978–3–540–26684–6

[57] THE R FOUNDATION:The R Project for Statistical Computing.https://www.r-

project.org/. Version: 2017. – Online; zuletzt besucht am 07.10.2017

[58] TINNITUS RESEARCH INITIATIVE:Tinnitus Database - About.https://

www.tinnitus-database.de/welcome. Version: 2017

[59] TÜRKER, C. ; SAAKE, G. : Objektrelationale Datenbanken: Ein Lehrbuch. 1. Aufl.

Heidelberg : Dpunkt-Verl., 2006. – ISBN 978–3–89864–190–6

[60] TYLER, R. S.: Tinnitus handbook. Africa and United Kingdom : Singular, 2000

(Singular audiology textbook). – ISBN 1565939220

[61] VIELSMEIER, V. ; STRUTZ, J. ; KLEINJUNG, T. ; SCHECKLMANN, M. ; KREUZER, P. M. ;

LANDGREBE, M. ; LANGGUTH, B. : Temporomandibular Joint Disorder Complaints in

Tinnitus: Further Hints for a Putative Tinnitus Subtype. In: PLOS ONE 7 (2012), Nr.

6, S. e38887. – ISSN 1932–6203. – Online; zuletzt besucht am 07.10.2017

[62] VOOS, D. Dr. m.: Clinical Global Impression Scale (CGI-Skala).https:

//www.medizin-im-text.de/blog/2013/563/clinical-global-

impression-scale/. Version:2013. – Online; zuletzt besucht am 07.10.2017

[63] WEISE, C. : Tinnitus. In: Psychotherapeut 56 (2011), Nr. 1, S. 61–78. – ISSN 0935–

6185. – Online; zuletzt besucht am 07.10.2017

[64] WELLING, L. : PHP and MySQL web development. Hoboken, NJ : Addison-Wesley,

2017. – ISBN 978–0–321–83389–1

[65] WIKIPEDIA:MoSCoW-Priorisierung — Wikipedia, Die freie Enzyklopädie.

https://de.wikipedia.org/w/index.php?title=MoSCoW-

Priorisierung&oldid=141959307. Version: 2015. – Online; zuletzt

besucht am 07.10.2017

101

Literaturverzeichnis

[66] WIKIPEDIA:Erzeugungsmuster — Wikipedia, Die freie Enzyklopädie.https:

//de.wikipedia.org/w/index.php?title=Erzeugungsmuster&oldid=

157700738. Version: 2016. – Online; zuletzt besucht am 07.10.2017

[67] WIKIPEDIA:Entwurfsmuster — Wikipedia, Die freie Enzyklopädie.https:

//de.wikipedia.org/w/index.php?title=Entwurfsmuster&oldid=

165231189. Version: 2017. – Online; zuletzt besucht am 07.10.2017

[68] WIKIPEDIA:Strukturmuster — Wikipedia, Die freie Enzyklopädie.https:

//de.wikipedia.org/w/index.php?title=Strukturmuster&oldid=

167718720. Version: 2017. – Online; zuletzt besucht am 07.10.2017

[69] WIKIPEDIA:Verhaltensmuster (Software) — Wikipedia, Die freie

Enzyklopädie.https://de.wikipedia.org/w/index.php?title=

Verhaltensmuster_(Software)&oldid=165295352. Version: 2017. –

Online; zuletzt besucht am 07.10.2017

[70] WORLD HEALTH ORGANIZATION:WHO | WHO Quality of Life-BREF

(WHOQOL-BREF).http://www.who.int/substance_abuse/

research_tools/whoqolbref/en/. – Online; zuletzt besucht am 07.10.2017

[71] YANG, S. ; WEINER, B. D. ; ZHANG, L. S. ; CHO, S.-J. ; BAO, S. : Homeostatic

plasticity drives tinnitus perception in an animal model. In: Proceedings of the

National Academy of Sciences of the United States of America 108 (2011), Nr. 36,

S. 14974–14979. – ISSN 1091–6490

102

Abbildungsverzeichnis

1.1 Tinnitus Research Initiative und Tinnitus Database . . . . . . . . . . . . . 4

2.1 TRI Flowchart for Patient Management [5] . . . . . . . . . . . . . . . . . . 20

3.1 Screenshot des visuellen Abfrage Editors aus Microsoft Access [25] . . . . 26

4.1 Ablauf und Elemente einer Patientenstudie in der Tinnitus Database . . . 33

4.2 Übersicht der relevanten Entitätstypen - Teil 1 . . . . . . . . . . . . . . . . 37

4.3 Übersicht der relevanten Entitätstypen - Teil 2 . . . . . . . . . . . . . . . . 38

4.4 Soll-Prozess der Export-Konfiguration . . . . . . . . . . . . . . . . . . . . 41

4.5 Exemplarische Struktur eines Exports . . . . . . . . . . . . . . . . . . . . 43

4.6 Soll-Prozess der Export-Generierung . . . . . . . . . . . . . . . . . . . . 45

5.1 Ansicht und Erstellung von Konfigurationen . . . . . . . . . . . . . . . . . 57

5.2 Bearbeitung von Konfigurationen . . . . . . . . . . . . . . . . . . . . . . . 59

5.3 Generierung von Exporten . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.4 Datenmodell des Export-Moduls . . . . . . . . . . . . . . . . . . . . . . . 63

6.1 Abstrakte Darstellung der SQL-Codegenerierung . . . . . . . . . . . . . . 72

6.2 Veranschaulichung der Code-Generator-Schnittstellen . . . . . . . . . . . 73

6.3 Beispiel einer Second-Order-Injection . . . . . . . . . . . . . . . . . . . . 74

6.4 Stückweise Abfrage der Daten . . . . . . . . . . . . . . . . . . . . . . . . 79

103

Tabellenverzeichnis

2.1 Verschiedene Differenzierungen von Tinnitus [63] . . . . . . . . . . . . . . 9

4.1 Funktionale Anforderungen an das Export-Modul . . . . . . . . . . . . . . 47

4.2 Nicht-funktionale Anforderungen an das Export-Modul . . . . . . . . . . . 52

7.1 Bewertung der funktionalen Anforderungen an das Export-Modul . . . . . 86

7.2 Bewertung der Nicht-funktionalen Anforderungen an das Export-Modul . . 87

104

Name: Andreas Rein Matrikelnummer: 811584

Erklärung

Ich erkläre, dass ich die Arbeit selbständig verfasst und keine anderen als die angegebe-

nen Quellen und Hilfsmittel verwendet habe.

Ulm,den ...............................................................................

Andreas Rein