Universität Ulm | 89069 Ulm | Germany Fakultät für
Ingenieurwissenschaften,
Informatik und
Psychologie
Institut für Datenbanken
und Informationssysteme
Konzeption und Realisierung eines
Patientenmoduls für eine
interdisziplinäre und multinationale
Tinnitusdatenbank
Bachelorarbeit an der Universität Ulm
Vorgelegt von:
Leyla Ernst
leyla.er[email protected]
Gutachter:
Prof. Dr. Manfred Reichert
Betreuer:
Dr. Rüdiger Pryss
2017
Fassung 21. Februar 2018
c
2017 Leyla Ernst
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
A
TEX2ε
Kurzfassung
Tinnitus ist eine schwer zu erfassende Krankheit. Jedem Betroffenen äußert sich die
Krankheit in unterschiedlichem Ausmaß und mit verschiedenen Symptomen. So kann
der Tinnitus dauerhaft oder zeitweise auftreten, verschiedene Töne annehmen oder an
unterschiedlichen Stellen des Kopfes wahrgenommen werden. Die Patienten fühlen sich
oft in ihrer Lebensweise eingeschränkt, während sich viele Ärzte hilflos fühlen und nicht
genau wissen, wie Tinnitus zu behandeln ist.
Aus diesem Grund benötigt man möglichst viele Daten von einem Patienten, um einen
Ansatz der Hilfe zu finden und außerdem die Forschung vorantreiben zu können. Die
am Institut für Datenbanken und Informationssysteme der Universität Ulm in Zusammen-
arbeit mit dem Uniklinikum Regensburg und der Tinnitus Research Initiative entwickelte
TinnitusDatabase unterstützt diesen Vorgang. Aktuell ist es den Ärzten dort möglich,
Patientendaten einzugeben und anschließend auswerten zu lassen. Die Eingabe dieser
Daten soll nun auch den Patienten selbst ermöglicht werden, um mehr Daten zu erfas-
sen und die Arbeit und Forschung mit Tinnitus zu erleichtern. Da das bisherige System
jedoch nicht für Patienten gedacht ist, soll ein neues spezielles System für Patienten
entwickelt werden.
Diese Arbeit zeigt eine beispielhafte Entwicklung eines solchen Patientenmoduls für
Patienten mit Tinnitus. Es wird erläutert wie das System architektonisch entworfen wird.
Außerdem betrachtet die Arbeit ausgewählte Implementierungsaspekte und stellt das
realisierte System vor.
iii
Danksagung
An dieser Stelle möchte ich mich bei den Personen bedanken, die diese Arbeit ermöglicht
und zu ihrem Gelingen beigetragen haben.
Ein besonderer Dank geht an Dr. Rüdiger Pryss für die Unterstützung bei der Themen-
findung und die Betreuung während der Arbeit.
Außerdem danke ich Herrn Prof. Dr. Manfred Reichert für die Genehmigung sowie
Begutachtung dieser Arbeit.
Weiterhin möchte ich mich bei Michael Stach bedanken, der mir sowohl mit Anregungen,
als auch mit Hilfestellungen tatkräftig zur Seite stand.
Zu guter Letzt danke ich meinem Partner, unseren Familien und allen Freunden für die
Unterstützung und das Verständnis während des gesamten Studiums.
v
Inhaltsverzeichnis
1 Einleitung 1
1.1 Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Struktur der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Verwandte Arbeiten und Projekte 5
2.1 The Swedish Rheumatology Quality Register (SRQ) . . . . . . . . . . . . 5
2.2 Designkonzept für eine Überarbeitung der Tinnitus-Datenbank . . . . . . 7
2.3 Konzeption und Realisierung eines Patientenmoduls . . . . . . . . . . . . 8
2.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3 Anforderungsanalyse 11
3.1 Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Nicht-funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . 15
4 Architektur 17
4.1 Ablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Datenbank-Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3 Aufbau des Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5 Ausgewählte Implementierungsaspekte 23
5.1 Fragebogengestaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2 Zwischenspeichern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.3 Mehrsprachigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
vii
Inhaltsverzeichnis
6 Walkthrough 31
6.1 Tinnitus-Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.2 Patientenmodul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.2.1 Registrieren und anmelden . . . . . . . . . . . . . . . . . . . . . . 34
6.2.2 Fragebögen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.2.3 Passwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.2.4 Abmeldung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
7 Abgleich der Anforderungen 41
7.1 Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.2 Nicht-funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . 42
8 Zusammenfassung und Ausblick 45
8.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.2 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.3 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
A Manuelle Tests 53
viii
1
Einleitung
Unter Tinnitus versteht man ein Symptom gestörter Hörwahrnehmung, welches sich
durch eine Phantomwahrnehmung von Geräuschen äußert [
1
]. Viele Ärzte sehen sich
hilflos im Umgang mit Tinnitus und seinen Patienten [
2
]. Die Problematik wird besonders
deutlich wenn man bedenkt, dass mittlerweile zwischen fünf und 15 Prozent der Gesamt-
bevölkerung von einem Tinnitus berichten [
3
] und sich ein Prozent sogar erheblich in
ihrer Lebensqualität eingeschränkt fühlen [
4
]. Die Behandlung von Tinnitus erweist sich
jedoch als sehr schwer. So gibt es beispielsweise Patienten, bei denen laute Geräusche
die Ursache des Tinnitus sind, doch kann Musik in angemessener Lautstärke ebenso
die Behandlung unterstützen [
5
]. Die Behandlung von Tinnitus hat folglich noch keine
festen Handlungsvorgaben, woraus die erwähnte Hilflosigkeit resultiert.
Ein Ansatz die Therapiefindung zu unterstützen sind Fragebögen. Anhand von ihnen
werden Patienten in bestimmte Schweregrade und Formen des Tinnitus eingeteilt. Je
nach Form kann man dann einen Therapieansatz wählen. Doch im Gegensatz zu früher
leben wir heutzutage in einer digitalen Welt, die mittlerweile auch im Gesundheitssystem
zu erkennen ist. Anstatt die Fragebögen von Hand auszuwerten, wird mittlerweile alles
Mögliche über Computer festgehalten und berechnet [6, 7, 8].
Aus diesem digitalisierten Grundgedanken heraus entstand die bisher einmalige
"TinnitusDatabase" [
9
] (auch "Tinnitus-Datenbank" genannt). In der Datenbank können
die Ärzte Daten von Patienten während der verschiedenen Untersuchungen im Laufe
der Zeit eingeben und mit statistischen Methoden bewerten lassen. Mit Hilfe der ausge-
werteten Daten kann dann eine Behandlungsmethode gewählt werden. Zudem ist diese
Erfassung so vieler Patientendaten eine große Chance für die Forschung, da man für
1
1 Einleitung
aussagekräftige Studien eine Menge an Daten benötigt. Die Tinnitus-Datenbank bietet
also viele Möglichkeiten für die zukünftige Entwicklung unseres Wissens über Tinnitus.
1.1 Problemstellung
Wie bereits erwähnt (vgl. Abschnitt 1) ist der aktuelle Stand der Tinnitus-Datenbank,
dass die Ärzte die Patientendaten erfassen und eingeben, wenn die Patienten bei
ihnen erscheinen. Sie befragen die Patienten und füllen die Fragebögen aus. Dann
können sie verschiedene Bewertungsmethoden auf die Daten anwenden und Statistiken
ablesen. Dies ergibt komplexe Datensätze, sodass dies nicht für Patienten vorgesehen ist.
Dementsprechend wurde die Tinnitus-Datenbank auch nicht für die Ansprüche von ihnen
entworfen und umgesetzt. Doch die Erfassung von den Patientendaten ist ein Vorgang,
der auch von Patienten selbst ohne medizinisches Hintergrundwissen ausführbar wäre
und zukünftig auch sein soll. So sind mehr Daten in weniger Zeit erfassbar, da nicht
erst eine Befragung stattfindet und der Arzt dann die Daten eingibt. Der Patient gibt sie
stattdessen direkt ein.
1.2 Zielsetzung
Ziel dieser Bachelorarbeit ist es ein solches Modul für die Patienten zu entwickeln und
zu realisieren. Daher ist die einfache Bedienbarkeit das vorrangige Ziel. Die selbst-
erklärende Darstellung des gesamten Systems steht hier im Mittelpunkt. Außerdem
soll die Multinationalität der TinnitusDatabase fortgeführt werden. Deshalb soll das
Patientenmodul mehrsprachig sein bzw. es muss die Möglichkeit geben, schnell und
einfach weitere Sprachen einzubinden. Abschließend muss die Anwendung natürlich
mit der Tinnitus-Datenbank zusammenarbeiten können. Hierzu muss einerseits eine
Schnittstelle existieren, die es Ärzten in der Tinnitus-Datenbank ermöglicht auszuwählen,
welcher Patient welche Fragebögen ausfüllen soll, andererseits soll eine Schnittstelle
vorhanden sein, die beendete Fragebögen an die Tinnitus-Datenbank sendet, sodass
die Ärzte dort Zugriff auf die Daten haben. Da es den Umfang dieser Arbeit weit über-
2
1.3 Struktur der Arbeit
schreiten würde, dies für alle in der Tinnitus-Datenbank vorhandenen Fragebögen zu
entwickeln, beschränkt man sich hier auf drei wichtige Fragebögen: TSCHQ [
10
], THI
[11] und Tinnitus Fragebogen (auch "TQ"genannt) [12].
1.3 Struktur der Arbeit
In den insgesamt acht Kapiteln dieser Arbeit werden also sowohl die Entwicklung als
auch die tatsächlich vorgenommene Realisierung eines solchen Patientenmoduls für die
Tinnitus-Datenbank erläutert.
Das folgende Kapitel 2 beschäftigt sich mit einer verwandten Arbeit zum Thema des
Patientenmoduls in einem anderen Gebiet, als auch mit zwei bestehenden Arbeiten zur
Tinnitus-Datenbank. Die Arbeiten werden untersucht und Zusammenhänge zu dieser
Arbeit erschlossen.
Darauf baut die Anforderungsanalyse in Kapitel 3 auf. Es werden die Anwendungsfälle
erfasst und damit die funktionalen und nicht-funktionalen Anforderungen an das System
erstellt.
Im 4. Kapitel wird dann die Architektur der Anwendung vorgestellt. Der generelle Ablauf
wird aufgezeigt, sowie die Datenstrukturen und der Aufbau des Systems.
Kapitel 5 stellt dann drei ausgewählte Implementierungsaspekte vor. Das heißt es wird
zunächst die Lösung der einfachen Bedienbarkeit in den Fragebögen betrachtet und dann
die gewählte Strategie zum Zwischenspeichern. Außerdem wird die Implementierung
der Mehrsprachigkeit vorgestellt.
Nachdem man nun die Struktur und Implementierung des Patientenmoduls betrachtet
hat, stellt Kapitel 6 einen "Walkthrough"durch jenes dar. Anhand von Screenshots wird
das System vorgestellt und die Bedienung erläutert.
In Kapitel 7 werden anschließend die in Kapitel 3 erstellten Anforderungen mit der
Umsetzung verglichen. Es wird analysiert ob die Anforderungen umgesetzt werden
konnten.
Kapitel 8 fasst dann die Arbeit noch einmal zusammen und zeigt einen Ausblick auf.
3
2
Verwandte Arbeiten und Projekte
Zum Thema dieser Arbeit existieren verwandte Arbeiten und Projekte. In den folgenden
Abschnitten sollen drei davon erläutert werden. Zunächst wird ein Projekt betrachtet,
das dem der Tinnitus-Datenbank und des Patientenmoduls ähnelt, sich jedoch auf
Rheumapatienten spezialisiert hat. Die zweite Arbeit untersucht den Stand der Tinnitus-
Datenbank und befasst sich mit den Schwachstellen, die für das Patientenmodul wichtig
sind, da diese in der vorliegenden Arbeit vermieden werden sollen. Die letzte Arbeit
befasst sich ebenso mit einem Patientenmodul für die Tinnitus-Datenbank. In dieser
Arbeit wurde ein Konzept und ein Entwurf vorgestellt, jedoch nichts implementiert, sodass
man Schlüsse aus dieser Arbeit für die vorliegende ziehen kann.
2.1 The Swedish Rheumatology Quality Register (SRQ)
Das Projekt Swedish Rheumatology Quality Register (kurz: SRQ) sagt über sich selbst:
"The SRQ is a Swedish national quality registry that aims to dramatically improve health
for people with chronic disease" [
13
]. Das SRQ ist also eine Plattform mit dem Ziel
die Gesundheit für Patienten chronischer Krankheiten zu verbessern. Dabei hat sich
das Projekt auf Rheumapatienten spezialisiert und arbeitet mit Kliniken zusammen. Die
Patienten selbst geben Daten in die Plattform ein, um dem System einen aktuellen
Stand ihrer Gesundheit zu liefern. Durch mehrere Eingaben entsteht ein graphisch
erkennbarer Trend ihrer Gesundheit und der Behandlungen. Die Daten werden mit
Untersuchungsergebnissen der Klinik vervollständigt. So entsteht eine Zusammenarbeit,
die es Patient und Behandler ermöglicht, die bestmögliche Therapie zu finden.
Das SRQ-System besteht aus drei verschiedenen Komponenten.
5
2 Verwandte Arbeiten und Projekte
Eine Komponente ist das Patientenmodul. Der Patient gibt Daten über seine aktuelle
Lebenssituation ein und erhält Auswertungen über seinen Zustand und Informationen,
die ihn auf den bevorstehenden Klinikbesuch vorbereiten sollen. Das Modul zeigt nicht
nur seinen aktuellen Zustand, sondern wertet auch Reaktionen auf Behandlungen aus,
sofern aktuell welche durchgeführt werden. Zugang erhält der Patient nur über ein
bestimmtes sicheres nationales Internetportal oder vor Ort in der Klinik über einen
Computer bzw. ein Tablet.
Das Klinikmodul soll die Klinik unterstützen. Es ist die Datenbank und hilft außerdem
den behandelnden Ärzten durch verschiedene Bewertungsmethoden für die Labor- und
Patientendaten, Entscheidungen zu treffen. Die Anwendung stellt Zusammenhänge zwi-
schen Medikamenten und gesundheitlichen Veränderungen her. Dabei kann das Modul
nicht nur den einzelnen Patienten bewerten, sondern bietet ebenso die Möglichkeit eine
bestimmte Gruppe von Patienten, oder gar alle Patienten der gesamten Klinik statistisch
auszuwerten.
Das dritte Modul ist das nationale. Eine Zusammenfassung der Klinikmodule von ver-
schiedenen Rheuma-Kliniken innerhalb Schwedens wird an das nationale Register
übermittelt. Auch hier gibt es verschiedene Analyse- und Bewertungsmethoden, die die
Forschung und Öffentlichkeitsarbeit der Nation unterstützen können.
Dieses Projekt verdeutlicht den Nutzen einer solchen gesundheitlichen Datenbank für un-
terschiedliche Krankheiten. Die Patienten werden vorbereitet, die Behandlung unterstützt
und die Forschung im Bereich der Krankheit vorangetrieben. Außerdem erkennt man
den Sinn der Trennung zwischen der Datenbank und dem Patientenmodul selbst. Jedes
System als eigenes kann unterschiedliche Funktionen bieten. Dadurch, dass diese
hierbei voneinander getrennt sind, hält man die Komplexität der einzelnen Anwendung
möglichst gering und fördert die Effizienz. Sämtliche Informationen zu diesem Projekt
findet man auf seiner Internetseite [13].
6
2.2 Designkonzept für eine Überarbeitung der Tinnitus-Datenbank
2.2 Designkonzept für eine Überarbeitung der
Tinnitus-Datenbank
Die folgende Arbeit ist eine Übersicht und kritische Untersuchung der Tinnitus-Datenbank
und ihrer Schwachstellen mit dem Titel "Designkonzept für eine Webanwendung zum
Zugriff auf eine interdisziplinäre und multinationale Datenbank zur Erfassung Tinnitus-
geschädigter Patienten"[
14
]. Sie ist gedacht um eine Überarbeitung der Tinnitus-Datenbank
zu unterstützen. Da das Patientenmodul eine Erweiterung der Tinnitus-Datenbank sein
soll, die einige Funktionen dieser beinhaltet, ist diese Untersuchung auch für die vorlie-
gende Arbeit wichtig. Betrachtet man die Schwachstellen und Anforderungen an eine
überarbeitete Tinnitus-Datenbank können Lehren gezogen werden, um im Patientenmo-
dul möglichst viele der Schwachstellen, die auch für die Patienten relevant wären, zu
verhindern. Die Arbeit setzt sich dabei ebenso kritisch mit der Oberflächengestaltung,
wie mit der Möglichkeit neuer Funktionen auseinander. Dabei wurden die Wünsche der
realen Nutzer und Auftraggeber berücksichtigt, sodass die Wünsche auch denen der
zukünftigen Nutzern des Patientenmoduls entsprechen. In diesem Abschnitt werden wir
uns dabei auf genau die festgestellten Anforderungen dieser Arbeit beschränken, die
auf das Patientenmodul übertragbar sind.
Der erste Punkt ist die Mehrsprachigkeit. Auch schon in dieser Arbeit wurde festgestellt,
dass diese wichtig für die Tinnitus-Datenbank ist, da die Mitarbeiter in verschiedenen
Landessprachen arbeiten. Zudem wurde darauf hingewiesen, dass bei der Umsetzung
die Kodierung beachtet werden muss, da die Ansicht für den Benutzer sonst eventuell
Fragezeichen statt Sonderzeichen darstellt, oder Ähnliches. Als Lösung wird die UTF-8
Kodierung zum Beispiel gegeben und auf die Vergrößerung der Textfenster hingewiesen.
Ebenso betrachtet die Arbeit verschiedene Benutzerrollen. Den verschiedenen Benut-
zern sollen nur die Funktionen angezeigt werden, die sie auch nutzen sollen. Bisher gibt
es so viele Informationen und Funktionen auf einer Seite, dass der Nutzer nicht immer
sicher sein kann, was für ihn relevant ist. Dazu soll ein Rechtesystem eingeführt werden.
Dies hängt auch mit der Nutzerfreundlichkeit zusammen. Das System soll möglichst
einfach und selbsterklärend sein und nicht zu solchen Verwirrungen führen. Ein weiterer
Punkt sind die Voreinstellungen. Die Arbeit stellt fest, dass Voreinstellungen in den
7
2 Verwandte Arbeiten und Projekte
Fragebögen zum Überspringen der Fragen bei Nutzern führen können und dies zu
vermeiden ist. So sollen künftig sämtliche Eingabefelder leer sein.
Diese Anforderungen führen zu möglichen Umsetzungstechniken. Diskutiert wird die
Umsetzung als Webanwendung, die sowohl Vor- als auch Nachteile bietet. Eine We-
banwendung bedeutet, dass das System ausschließlich mit Internetzugang nutzbar ist
und die Ansicht sich in unterschiedlichen Browsern verschieden gestalten kann. Jedoch
muss keine Software installiert werden um das System zu nutzen und es ist dadurch
plattformunabhängig. Außerdem bringt die Webanwendung Mobilität mit sich. Überall wo
ein Internetzugang und ein Browser vorhanden sind, kann das System genutzt werden.
Als Techniken werden HTML [
15
] und CSS [
16
] vorgeschlagen, um die Nutzerfreund-
lichkeit zu fördern und ansprechende Seiten zu gestalten. Für die Datenspeicherung
wird in der Arbeit MySQL [
17
] in Verbindung mit PHP [
18
] als gute Variante gesehen.
So zeigt diese Arbeit verschiedene nicht-funktionale Anforderungen und Techniken, die
die Umsetzung der Anforderungen unterstützen können. Das erarbeitete Konzept zeigt
die Wichtigkeit einer möglichst übersichtlichen Seite, die für jeden und vor allem von
Nutzern von überall und mit mehreren Landessprachen nutzbar sein soll. Dafür eignet
sich eine dynamisch gestaltete Webanwendung.
2.3 Konzeption und Realisierung eines Patientenmoduls
Die letzte betrachtete Arbeit ähnelt der vorliegenden, unterscheidet sich jedoch in einem
wichtigen Punkt. In der Arbeit "Konzeption und Realisierung eines Patientenmoduls für
eine multinationale und interdisziplinäre Datenbank" [
19
] wird ein ausführliches Kon-
zept zur Realisierung eines Patientenmoduls für die Tinnitus-Datenbank ausgearbeitet.
Ebenso wird es komplett mittels Grafiken entworfen, jedoch nicht implementiert. Die
Arbeit stellt also einen Wunsch-Zustand des Patientenmoduls dar. Anschließend wird
eine Evaluierung zum aktuellen Nutzverhalten und den Wünschen der Zielgruppe des
Patientenmoduls durchgeführt. Durch die Betrachtung dieser Arbeit können wertvol-
le Ergebnisse für die tatsächliche Implementierung des Patientenmoduls gewonnen
werden.
8
2.3 Konzeption und Realisierung eines Patientenmoduls
So weist man darauf hin, dass die Fragebögen als die wichtigste Funktion für die Patien-
ten überarbeitet werden müssen. Bisher mussten die Nutzer die Seiten der Fragebögen
gezielt anklicken um sie ausfüllen bzw. einsehen zu können. Dadurch besteht die Gefahr,
dass Fragen übersprungen werden. So bietet es sich an, den Nutzer gezielt durch den
Fragebogen zu führen. An dieser Stelle könnte das System durch Breadcrumps den
Vorgang unterstützen. Breadcrumps helfen dem Nutzer zu sehen an welchem Punkt
er sich gerade befindet und es wird klar dargestellt, welche Seiten schon bearbeitet
wurden. Es ist außerdem möglich auf bearbeitete Seiten zurückzublicken. Abbildung
2.3 zeigt den beispielhaften Verlauf mit Breadcrumps. Ebenso kann eine Funktion des
Zwischenspeicherns die Patienten animieren, bei eventuell sehr langen Fragebögen
nicht abzubrechen, sondern zu einem späteren Zeitpunkt weiter zu machen. Zudem
Abbildung 2.3.1: Breadcrumps [19]
befasst sich die Arbeit mit datenschutzrechtlichen Themen. Die Speicherung und Verar-
beitung personenbezogener Daten unterliegt einem besonderen Schutz. So muss sich
für das Patientenmodul ausführlich mit diesen Bestimmungen befasst werden und für
die tatsächliche Nutzung eine Einwilligungserklärung ausgearbeitet werden. Es sollen
9
2 Verwandte Arbeiten und Projekte
die Daten so gespeichert werden, dass sie anonymisiert sind und bei einem eventuellen
Angriff von außen keine Gefahr für die Patienten besteht.
2.4 Fazit
Mithilfe dieser drei Arbeiten können im folgenden Kapitel die Anforderungen für das
Patientenmodul erstellt werden. Es wurden sowohl funktionale als auch nicht-funktionale
Bedingungen erläutert, die das System erfüllen soll. So kristallisieren sich vor allem die
Nutzerfreundlichkeit mit unterschiedlichen Punkten und die Mehrsprachigkeit und deren
Umsetzung als wichtigste Merkmale des Patientenmoduls heraus.
10
3
Anforderungsanalyse
Im folgenden Kapitel werden die Anforderungen an das Projekt und das System darge-
stellt. Ziel ist es, während der gesamten Entwicklung diese Anforderungen zu berück-
sichtigen und schlussendlich umzusetzen.
Zunächst werden die Anwendungsfälle aufgezeigt, also in welchen Situationen, von wem
und wofür das Patientenmodul genutzt werden soll. Aus den Anwendungsfällen können
dann die funktionalen und schließlich die nicht-funktionalen Anforderungen definiert
werden.
3.1 Anwendungsfälle
Das Patientenmodul soll dem Patienten ermöglichen selbstständig an der Tinnitus-
Datenbank teilzunehmen. Eine Möglichkeit die Systemfunktionen und eventuelle Be-
ziehungen zu beschreiben, ist das Anwendungsfalldiagramm. Es stellt grafisch einen
Überblick über das System dar und setzt sich aus Akteuren und den dazugehörigen
Anwendungsfällen zusammen.
In unserem System gibt es verschiedene Akteure:
Anonym:
Mensch, der dem System noch nicht bekannt ist, also entweder noch nicht
registriert oder nicht angemeldet.
Arzt:
Mensch, der Tinnitus-Patienten behandelt und mit der Tinnitus-Datenbank bzw.
dem Patientenmodul zusammenarbeitet.
Nutzer/Patient: Mensch, der an Tinnitus leidet und das Patientenmodul nutzen soll.
11
3 Anforderungsanalyse
ausfüllenausfüllen
Anonym
Registrieren
Anmelden
Patient
Abmelden
Passwort ändern
Fragebögen anzeigen
Absenden
Fragebogen auswählen
<<erweitern>>
<<erweitern>>
Arzt
Patient freigeben
Fragebögen auswählen
Fragebogen einsehen
<<erweitern>>
<<erweitern>>
<<erweitern>>
Fragebogen ausfüllen
<<erweitern>>
Zwischenspeichern
<<erweitern>>
Abbildung 3.1.1: Anwendungsfalldiagramm
In Abbildung 3.1 sieht man diese Akteure und die Funktionen, die für sie bereitgestellt
werden sollen.
12
3.2 Funktionale Anforderungen
3.2 Funktionale Anforderungen
Die funktionalen Anforderungen ergeben sich aus dem Anwendungsfalldiagramm. Sie
beschreiben welche Funktionen das Patientenmodul und die entwickelten Schnittstellen
für die Tinnitus-Datenbank aufzuweisen haben. Die Tabelle 3.2 gibt eine Übersicht über
die Anforderungen an die Schnittstelle der Tinnitus-Datenbank. Tabelle 3.2 zeigt die
Anforderungen des gesamten Patientenmoduls.
Tabelle 3.1: Anforderungen Tinnitus-Datenbank
Nr. Bezeichnung Beschreibung
1.
Patient Fragebögen frei-
schalten
Das System soll dem Arzt die Möglichkeit bieten für
einen Patienten im Patientenmodul die Fragebögen
freizuschalten, die er ausfüllen soll.
2. Fragebogen speichern
Hat ein Patient einen Fragebogen über das Pati-
entenmodul abgeschickt, sollen sie in der Tinnitus-
Datenbank gespeichert sein.
Tabelle 3.2: Anforderungen Patientenmodul
Nr. Bezeichnung Beschreibung
1. Registrieren
Ohne Benutzerkonto kann das System nicht benutzt
werden. Es soll daher den Patienten ermöglichen sich
zu registrieren. Dabei werden keine persönlichen Da-
ten gespeichert und der Patient bleibt anonym.
2. Anmelden
Ein registrierter Nutzer soll sich anmelden können um
so Zugang zu den Funktionen des Patientenmoduls
zu bekommen.
3. Abmelden
Ein im System angemeldeter Nutzer muss sich auch
wieder abmelden können. Ein abgemeldeter Nutzer
soll keinen Zugriff auf die Funktionen des Patienten-
moduls haben.
13
3 Anforderungsanalyse
Tabelle 3.3: Anforderungen Patientenmodul zweiter Teil
Nr. Bezeichnung Beschreibung
4. Passwort ändern
Die Anwendung muss einem Benutzer die Mög-
lichkeit bieten sein Passwort zu ändern, falls er es
vergessen hat oder ändern möchte. Das alte Pass-
wort soll unwiderruflich in der Datenbank mit dem
neuen überschrieben werden.
5. Fragebögen anzeigen
Einem angemeldeten Nutzer sollen die Fragebögen
angezeigt werden, die für ihn freigeschaltet wurden.
6. Fragebogen anzeigen
Ein Patient soll sich einen einzelnen Fragebogen
anzeigen lassen können.
7. Fragebogen ausfüllen
Das Patientenmodul muss dem Nutzer ermöglichen
jede Frage eines Fragebogens einzeln zu beant-
worten.
8. Zwischenspeichern
Während des Ausfüllens soll es die Möglichkeit des
Zwischenspeicherns geben.
9. Keine Voreinstellungen
Wenn bei verschiedenen Daten schon ein Wert
voreingestellt ist (z. B. Geburtsdatum: 1.1.1980,
Tinnitusbelastung: 3) wird es zum Teil unabsichtlich
übersprungen. Damit die Eingabe nichtmehr beein-
flusst wird, sollen diese Werte nicht voreingestellt
sein.
10.
Mehrsprachigkeit
Die Nutzer und Ärzte der Tinnitus-Datenbank leben
in verschiedenen Ländern mit unterschiedlichen
Landessprachen. Damit jeder das Patientenmo-
dul nutzen kann, soll das komplette System die
Möglichkeit bieten die Anzeigesprache zu ändern.
Dadurch muss das System in einer Kodierung für
Unicode-Zeichen verwendet werden (z. B. UTF-8),
damit für eventuelle Sonderzeichen keine Fragezei-
chen oder Ähnliches erscheinen.
11.
Sprachen einbinden
Das System soll die Möglichkeit bieten, relativ ein-
fach neue Sprachen einzubinden.
14
3.3 Nicht-funktionale Anforderungen
3.3 Nicht-funktionale Anforderungen
Im Gegensatz zu den funktionalen erläutern die nicht-funktionalen Anforderungen nicht
was das Patientenmodul können soll, sondern wie das System die Funktionen ausführt.
Der folgende Abschnitt zeigt diese Anforderungen.
Verfügbarkeit
Das System soll jederzeit von überall zur Verfügung stehen. Dazu soll es
als Webanwendung umgesetzt sein.
Technische Unabhängigkeit
Die Anwendung soll möglichst auf allen Betriebssystemen
und mit den üblichen Browsern laufen.
Stabilität und Robustheit
Das Modul soll robust funktionieren und sollte eine Fehl-
funktion auftreten, muss nach einem Neustart des Systems die Anwendung fortgeführt
werden können.
Fehlervermeidung
Aufgrund der Vielzahl an Informationen in der bisherigen Anwen-
dung wäre es schnell möglich, dass Patienten Fragen übersehen. Das Patientenmodul
soll den Patienten so durch die Fragebögen oder Visiten führen, dass dies nicht mehr
passiert.
Nutzerfreundlichkeit
Alle Funktionen des Patientenmoduls sollen möglichst selbster-
klärend sein, sodass es von Patienten ohne Vorwissen genutzt und effizient mit dem
System gearbeitet werden kann.
15
4
Architektur
Dieses Kapitel beschreibt die Architektur des Patientenmoduls. Zuerst wird ein typischer
Ablauf im System gezeigt, daraufhin eine Beschreibung der Datenbankstruktur. Zum
Abschluss wird im Abschnitt 4.3 der Aufbau des Systems erläutert.
4.1 Ablauf
Um das Patientenmodul nutzen zu können ist ein Benutzerkonto notwendig. Das System
bietet auf der Startseite die Möglichkeit sich ein solches zu erstellen. Dazu muss er im
Registrieren Bereich ein Passwort wählen und seinen Betreuer angeben. Bei erfolgrei-
cher Registrierung erhält der Arzt eine E-Mail zur Bestätigung und zur Verifizierung des
Patienten. Der Arzt aktiviert durch klicken auf einen Link den Patienten.
Ab diesem Moment ist der Nutzer dazu in der Lage sich im Patientenmodul anzumelden.
Anschließend kann der Arzt über die Tinnitus-Datenbank die Fragebögen auswählen,
die dieser Patient ausfüllen soll. Nur diese sind dann für den Patienten zugänglich. Nach
dem Einloggen hat der Patient Zugang zu den verschiedenen Bereichen des Systems. Er
kann zu seinem Profil, wo er die E-Mail Adresse seines Arztes angezeigt bekommt. Dort
kann er außerdem sein Passwort ändern. Dazu muss er sein altes, sowie zwei Mal sein
gewünschtes neues Passwort eingeben. Darüber hinaus gelangt der Nutzer von seiner
Startseite aus zu den Fragebögen. Nach der Auswahl gelangt er zur Seite um diesen
zu beantworten. Jede Frage kann einzeln beantwortet werden. Möchte der Nutzer die
Beantwortung unterbrechen, kann er die gegebenen Antworten zwischenspeichern. Die
gespeicherten Antworten werden dem Patienten dann beim nächsten Besuch angezeigt
und können entweder nochmal verändert oder so weiterverwendet werden.
17
4 Architektur
Sind alle Fragen beantwortet, kann der Fragebogen abgesendet werden. Er wird dann
an die Tinnitus-Datenbank gesendet und dort in der Datenbank gespeichert. Bei er-
folgreicher Speicherung wird der Fragebogen außerdem in der Datenbank des Patien-
tenmoduls als beendet gekennzeichnet, wodurch der Patient keinen Zugang mehr zu
diesem Fragebogen hat. Hat der Nutzer seine Aktionen beendet, kann er sich ausloggen.
Dadurch sind die Funktionen des Systems nicht mehr zugänglich. Die Abbildung 4.1
zeigt den schematischen Ablauf durch die Systemfunktionen.
Registrierung Bestätigung des
Patienten Anmelden
Zu beantwortende
Fragebögen laden
Hauptseite
Fragebögen
freischalten
Fragebogen
beantworten Profil anzeigen
Fragebogen
zwischenspeichern
Nicht fertig beantwortet
Fragebogen
absenden
Fertig
Passwort ändern
Meldung anzeigen
Fehler
Meldung anzeigen
Fehler
erfolgreich
Fragebögen
freigeschaltet
Fragebögen nicht freigeschaltet
Benutzereingaben
prüfen
Fragebogen in
TInnitus-Datenbank
speichern
erfolgreich
Abbildung 4.1.1: Genereller Ablauf
18
4.2 Datenbank-Schema
Abbildung 4.2.1: Patientenmodul Datenbank
4.2 Datenbank-Schema
In diesem Abschnitt wird der Aufbau der Datenbank vorgestellt. Dazu betrachten wir
zum besseren Verständnis sowohl die Datenstruktur im Patientenmodul als auch die der
Tinnitus-Datenbank.
Da das Patientenmodul selbst die Fragebögen nicht speichert, werden in seiner Daten-
bank nur Tabellen zur Organisation der Nutzer und für die Zuordnung von Fragebögen
und Patienten benötigt. Das Patientenmodul besteht daher aus einer Tabelle ’users’ und
einer Tabelle ’patients’. Die Tabelle ’users’ speichert nach der Registrierung den User-
key des Nutzers sowie die zugeordnete E-Mail-Adresse seines Betreuers. Außerdem
wird sein gehashtes Passwort und ein Wert, der anzeigt ob der Nutzer aktiviert wurde,
gespeichert. Der Aktivationcode ist dabei der Code, mit dem ein Nutzer sein Passwort
zurücksetzen kann, falls er es ein Mal vergessen hat. Dabei bekommt jeder Nutzer bei
der Registrierung außerdem eine einmalige User-Id.
Die Tabelle ’patients’ speichert dagegen den Nutzer und seine auszufüllenden Frage-
bögen. Diese Tabelle wird von der Tinnitus-Datenbank aus befüllt. Der Nutzer wird mit
seiner Id und dem Userkey gespeichert, welche er innerhalb des Patientenmoduls bei
der Registrierung bekam, zusammen mit einer Spalte für jeden Fragebogen. Jeder Fra-
gebogen der beantwortet werden soll enthält eine ’1’, die anderen eine ’0’. Dazu existiert
eine Spalte, die das Datum und die Uhrzeit speichert, zu dem diese Zeile eingefügt
wurde. Die Abbildung 4.2 zeigt die Datenbankstrukturen.
19
4 Architektur
Abbildung 4.2.2: Datenbank Tinnitus-Datenbank
Nun werden die Tabellen der Tinnitus-Datenbank erläutert, die für das Patientenmodul
notwendig sind. Das sind die drei Tabellen der Fragebögen sowie eine extra Tabelle
für den TSCHQ, in dem die Medikamente gespeichert werden, die die Nutzer bei einer
Frage im TSCHQ angeben können. Jede Frage wird mit ihrer Antwort in der Fragebogen-
Tabelle gespeichert. Außerdem gibt es die Spalten zur Identifikation eines einzelnen
Fragebogens. Dies geschieht mit einer eindeutigen Id für jeden Fragebogen, sowie
einer Id für die Session und einem Namen. Die Tabelle ’tschqmedications’ speichert
Medikamente, von denen Patienten angeben sie zu nehmen. Dazu speichert sie, wel-
chen Einfluss die Medikamente auf den Tinnitus haben. Um die Angaben zuordnen
20
4.3 Aufbau des Systems
zu können wird außerdem die Id des dazugehörigen Fragebogens gespeichert. Alle
Tabellen speichern zudem wann die Zeile eingefügt und wann zuletzt bearbeitet wurde.
4.3 Aufbau des Systems
Personal
Profile
ResetPw
NewPw
ChangeProfile
Tschq
Thi
Tq
User DatabaseManager
ApiController
PasswordController
StartController
UserController
Activate
Legende:
Erstellt
Objekt
Verweise
Abbildung 4.3.1: MVC-Klassen
21
4 Architektur
Das System wurde als dynamische Website nach dem Model-View-Controller (auch
MVC genannt) Prinzip aufgebaut. Dadurch sollen die Wartbarkeit und die Erweiterbarkeit
gefördert werden. Das bedeutet es gibt eine Präsentationsschicht, die für den Nutzer
sichtbar, jedoch vom restlichen System abgekoppelt ist. Dies sind die View-Klassen.
Sie greifen auf die Controller zu, die die Datenbankzugriffe und den Ablauf der Sys-
temfunktionen steuern. Diese Schicht dient als Schutzschicht, denn die eigentliche
Datenverarbeitung geschieht dann in den Model-Klassen. Die vorhandenen Klassen
des Patientenmoduls und ihre Einordnung in dieses Prinzip sind in Abbildung 4.3 zu
erkennen. Die Raute an einer Linie zeigt dabei an, dass das Objekt am Ende der Raute
Verweise auf das Objekt am anderen Ende enthält. Die andere Verbindung mit Kreis
und Strich dagegen bedeutet, dass das Objekt am Ende des Symbols von der anderen
Klasse erstellt wird.
22
5
Ausgewählte Implementierungsaspekte
Dieses Kapitel stellt bestimmte Bereiche der Implementierung des Patientenmoduls vor.
Durch die verschiedenen Methoden sollen die Anforderungen erfüllt werden. Allgemein
ist das Projekt ein webbasiertes PHP [
18
]-Projekt mit einer MySql [
17
]-Datenbank. Die
optische Gestaltung geschah mittels HTML [
15
] und CSS [
16
]. Genauer wurden hier die
CSS-Dateien der Tinnitus-Datenbank genutzt um ein einheitliches Aussehen zu sichern
(siehe Quellcode [
9
]). Außerdem gab es wenige Punkte, die mit Javascript [
20
] bzw.
Jquery [21] erstellt wurden. Diese werden unter anderem in diesem Kapitel vorgestellt.
Als erstes wird die optisch ansprechende Gestaltung der Fragebögen erläutert. Danach
wird gezeigt, wie die Funktion des Zwischenspeicherns implementiert wurde. Der drit-
te Punkt in diesem Kapitel ist die Mehrsprachigkeit und wie einfach neue Sprachen
hinzugefügt werden können.
5.1 Fragebogengestaltung
Da die Fragebögen vom Patienten selbst beantwortet werden, müssen sie entsprechend
gestaltet sein. Das bedeutet ein Fragebogen muss sehr übersichtlich sein und dem
Patienten deutlich zeigen, wie weit er im Fragebogen fortgeschritten ist. Dafür wurde
bei der Implementierung das Plugin Jquery-Steps [
22
] benutzt. Es wurde speziell für
die User-Interface Gestaltung entwickelt und man benötigt nur die Javascript Bibliothek
Jquery und Jquery-Steps selbst.
Der Quelltext zeigt die entsprechenden Code-Zeilen im Patientenmodul. Man gibt zu-
nächst an an welchem Punkt die neue Fragebogen Seite beginnt. In dieser Arbeit ist
23
5 Ausgewählte Implementierungsaspekte
das in Zeile vier geschehen. Jedes Mal, wenn ein <h3> Tag kommt, wird also eine neue
Fragebogen Seite gestartet. Dann wird der Inhalt einer Seite gekennzeichnet (vgl. Zeile
5). Der Inhalt einer Seite ist also innerhalb eines <section> Tags zu finden. Daraufhin
folgen verschiedene Effekte und Zusatzfunktionen. So kann man einen Übergangs-
effekt wählen oder die Bedienung über die Tastatur ermöglichen. Außerdem gibt es
verschiedene Gestaltungsmöglichkeiten. Der Fragebogen kann horizontal oder vertikal
angeordnet werden und es können Überschriften und die einzelnen Bereiche unter-
schiedlich angezeigt werden (vgl. Zeilen 6, 10-14). Für das Patientenmodul wurde eine
horizontale Ausrichtung gewählt, da bei einer vertikalen eventuell nicht alle Seiten in der
Übersicht auf der ersten Seite sichtbar sind. Für eine einfache Bedienung sollen jedoch
alle angezeigt werden. Die Navigation über die Tastatur wurde ebenfalls aktiviert um die
nutzerfreundliche Bedienung zu fördern. Zeile 9 ist dazu da, eine Abwicklung des Frage-
bogens über Javascript zu ermöglichen. Setzt man sie auf true, wird automatisch ein
Button am Ende des Fragebogens angezeigt, um ihn abzusenden. Was dann geschieht,
kann man ebenfalls mit dem Plugin implementieren. Im Patientenmodul soll dies jedoch
nicht über Javascript geschehen, sondern mittels PHP, sodass es false gesetzt ist.
Insgesamt wurde so eine übersichtliche Ansicht des Fragebogens geschaffen. Der
Nutzer sieht an welchem Punkt er sich im Fragebogen befindet und alles wird groß und
deutlich dargestellt.
24
5.2 Zwischenspeichern
1$(document).ready(function(){
2var form = $("#formular").show();
3form.steps({
4headerTag: "h3",
5bodyTag: "section",
6transitionEffect: "slideLeft",
7enableKeyNavigation: true,
8autoFocus:true,
9enableFinishButton: false,
10 stepsOrientation: "horizontal",
11 titleTemplate: ’<span class="number">#index#.</span> #title#’,
12 loadingTemplate: ’<span class="spinner"></span> #text#’
13 });
14 });
Listing 5.1: Code Jquery-Steps
5.2 Zwischenspeichern
Die Funktion des Zwischenspeicherns wurde ebenfalls mit Javascript implementiert. Es
ist angedacht das Patientenmodul bei Besuch des Arztes in der Klinik direkt vor Ort zu
nutzen, oder Zuhause. Es ist also aktuell nicht vorgesehen, dass ein Nutzer das System
mobil oder an verschiedenen Geräten benutzt. Da dies nicht geplant ist, reicht eine
lokale Speicherung. Eine Speicherung über die Datenbank wäre deutlich aufwendiger.
Für das Patientenmodul wurde deshalb die Funktion des localStorage ausgesucht. Es
ist eine client-seitige Speicherung.
1$(function () {
2$("#store").click(function (e) {
3e.preventDefault();
4localStorage.setItem("flag","set");
5var data = $("#form").serializeArray();
6$.each(data, function (i, obj) {
7localStorage.setItem(obj.name + ’<?php echo $userid; ?>’, obj.value);
8$(’input[type="radio"]:checked’).each(function (index, element) {
9localStorage.setItem($(this).attr(’name’) +
10 ’<?php echo $userid; ?>’, $(this).val());
25
5 Ausgewählte Implementierungsaspekte
11 });
12 $(’input[type="checkbox"]:checked’).each(function (index, element) {
13 localStorage.setItem($(this).attr(’name’) +
14 ’<?php echo $userid; ?>’, $(this).val());
15 });
16 });
17 console.log(data);
18 });
19 if (localStorage.getItem("flag")=="set") {
20 var data = $("#form").serializeArray();
21 $.each(data, function (i, obj) {
22 $("[name=’" + obj.name + "’]").val(localStorage.getItem(obj.name +
23 ’<?php echo $userid; ?>’));
24 $(’input[type="radio"]’).each(function (index, element) {
25 if ($(this).val() == localStorage.getItem($(this).attr(’name’) +
26 ’<?php echo $userid; ?>’)) {
27 $(this).prop(’checked’,true);
28 }});
29 $(’input[type="checkbox"]’).each(function (index, element) {
30 if ($(this).val() == localStorage.getItem($(this).attr(’name’) +
31 ’<?php echo $userid; ?>’)) {
32 $(this).prop(’checked’,true);
33 }
34 });});
35 }});
Listing 5.2: Javascript LocalStorage
Bei jedem Klick auf den Zwischenspeichern- Button wird ein sog. "flag"gesetzt (vgl.
Zeile 4). Dabei wird für jedes Feld im Fragebogen der Wert zusammen mit der User-Id
gespeichert. Hier muss unterschieden werden von welcher Art die Felder sind, was
man ab Zeile 7 bis Zeile 16 sehen kann. Bei Radio- bzw. Checkboxen wird gespeichert,
ob sie ausgewählt sind oder nicht, während bei anderen Feldern, wie Freitext- oder
Zahlenfeldern, der Inhalt selbst gespeichert wird. Deshalb findet bei dem Setzen des
flags eine Fallunterscheidung statt. Die User-Id wird mit abgespeichert, damit eine
eindeutige Zuordnung stattfindet und dem richtigen User nur seine gespeicherten Werte
angezeigt werden.
26
5.3 Mehrsprachigkeit
Bei jedem Start der Seite wird dann geprüft ob ein flag gesetzt wurde (vgl. Zeile 19) und
falls ja, wird für jedes Feld der gespeicherte Wert geholt und wieder ausgegeben. Dies
geschieht in Zeile 22 bis 34.
Im Gegensatz zu Cookies werden die Daten bei Server-Requests durch dieses Ver-
fahren nicht automatisch übertragen, sodass diese Methode sicherer und schneller ist.
Die Speicherung hat kein Verfallsdatum, wie beispielsweise bei dem SessionStorage-
Verfahren [
23
]. Insgesamt wurde so eine schnelle und flexible Lösung zur dauerhaften
Speicherung gefunden, die für Zwecke des Patientenmoduls ausreicht und weniger
Aufwand als eine Datenbankspeicherung bedeutet.
5.3 Mehrsprachigkeit
Da das System in mehreren Ländern eingesetzt werden soll, war die Mehrsprachigkeit
ein wichtiger Punkt. Beispielhaft wurde das Modul bisher zweisprachig auf Deutsch und
Englisch umgesetzt. Das Wichtigste war dabei die Anwendung so zu gestalten, dass die
Einbindung neuer Sprachen möglichst einfach ist.
1if ($_SESSION[’language’]=="en") {
2require(’/languages/en/index_en.php’);
3}else if ($_SESSION[’language’]=="de") {
4require(’/languages/de/index_de.php’);
5}else {
6require(’/languages/de/index_de.php’);
7}
Listing 5.3: Session Überprüfung und Spracheinbindung
Die ausgewählte Sprache wird in einer sog. "language"-Session gespeichert. Standard-
mäßig ist die Anwendung auf Deutsch eingestellt, da dies aktuell das Herkunftsland
der meisten Nutzer ist. Wählt der Nutzer eine Sprache explizit aus, wird diese Sprache
gespeichert. In den View-Klassen wurden die Inhalte durch Variablen ersetzt. Je nach
Inhalt der language-Session werden dann die PHP-Dateien mit den Inhalten geladen
27
5 Ausgewählte Implementierungsaspekte
und füllen die Seite.
1<label for="q1_dateofbirth"><?php echo $q1; ?>:</label> <br />
2<input type="date" name="q1_dateofbirth"/> <br /> <br />
3
4<label for="q2_sex"><?php echo $q2; ?>:</label> <br />
5<input type="radio" name="q2_sex" value="1"/><?php echo $a21; ?>
6<input type="radio" name="q2_sex" value="2"/><?php echo $a22; ?><br />
Listing 5.4: Erstes Code-Beispiel mit PHP-Variablen für den Text
1<h1>Log-In</h1>
2<p><?php echo $welcometext; ?></p>
3<br/>
4<div class ="text-south">
5<form action="controllers/user_controller.php" method="post">
6<label> Userkey </label> <br/>
7<input style="color:black" type="text" name="userkey" value="" />
8<br/>
9<label> <?php echo $pass; ?> </label> <br/>
10 <input style="color:black" type="password" name="userpass" value="" />
11 <br/>
12 <br/>
13 <button id="login" name="login" type="submit" class="btn btn-primary">
14 <?php echo $submit; ?>
15 </button>
16 </form>
17 </div>
Listing 5.5: Zweites Code-Beispiel mit PHP-Variablen für den Text
Dieses Prinzip erkennt man gut an den beiden Code-Beispielen. Sämtliche Texte, die
bei einem Sprachwechsel zu übersetzen sind, wurden nicht direkt in den HTML-Code
geschrieben, sondern über PHP eingebunden. Beispielsweise der Text unter der Log-In
Überschrift. In der View ist er mittels der Variable "welcometext" eingebunden. In der
dazugehörigen deutschsprachigen Datei im Ordner "languages/de", ist der Variablen der
Inhalt ßur Seite der PatientsTinnitusDatabaseßugewiesen. In der englischsprachigen
Datei im Ordner "languages/enïst dann die englische Zuordnung "to the website of
PatientsTinnitusDatabase".
28
5.3 Mehrsprachigkeit
Die Ordnung ist dabei folgendermaßen: Es gibt den Ordner "languages", darin befindet
sich pro Sprache ein weiterer Ordner. Es gibt jeweils eine "basic" Datei, die die Variablen
enthält, die auf mehreren Seiten genutzt werden. Für jeden Bereich bzw. falls eine
Seite sehr viel Inhalt hat auch für einzelne Seiten, gibt es dann in den Ordnern eine
Datei, die den Inhalt der Variablen speichert. Möchte man also eine weitere Sprache
speichern, fügt man einen weiteren Ordner ein, kopiert die Dateien und ändert den Inhalt
der Variablen in den entsprechenden der neuen Sprache.
Zudem muss natürlich die Auswahl dieser neuen Sprache angeboten werden. Das
bedeutet im Header muss eine Auswahlmöglichkeit in der folgenden Form hinzugefügt
werden:
1<form action="" method="post">
2<input type="image" name="lang_de" src="../graphic/german.gif" />
3<input type="image" name="lang_en" src="../graphic/gb.gif" />
4</form>
Listing 5.6: Graphische Auswahlmöglichkeiten für die Sprache
Es wurden kleine Flaggen als intuitive Symbole genutzt um die Sprache auszuwählen.
Hier muss also ein Input inklusive kleinem Bild hinzugefügt werden. Dies hängt dann
mit dem Code zu Beginn dieses Abschnitts zusammen, der den StartController zeigt.
Im StartController wird geprüft ob bzw. welche Flagge angeklickt wurde. Dies wird ge-
speichert und dementsprechend kann dann die Sprache geladen werden. Hierzu muss
noch eine Abfrage eingefügt werden, dass bei entsprechender Auswahl die richtige
language-Session gespeichert wird, wie in dem Code des StartControllers zu sehen.
1if(isset($_POST[’lang_en_x’]) && isset($_POST[’lang_en_y’])){
2$user->language="en";
3}
4else if(isset($_POST[’lang_de_x’]) && isset($_POST[’lang_de_y’])){
5$user->language="de";
6}
Listing 5.7: StartController überprüft Sprachauswahl
29
5 Ausgewählte Implementierungsaspekte
Zusammengefasst wird die Sprache über die Auswahl des Nutzers in einer Session
gespeichert. Je nach Inhalt dieser Session werden dann Dateien geladen, die die
Inhalte der Seiten befüllen. Nach Ausloggen des Nutzers, sind die Inhalte der Sessions
geleert. Außerdem kann ein Nutzer während einer Sitzung mehrfach die Auswahl ändern,
sodass die Session eine flexible und einfache Möglichkeit bietet, die Mehrsprachigkeit
zu implementieren, weshalb dieses Verfahren auch gewählt wurde.
30
6
Walkthrough
Dieses Kapitel führt ein Mal durch alle gesamten entwickelten Funktionen. Anhand von
Screenshots wird die Bedienung und die Möglichkeiten des Systems erklärt, sodass das
Patientenmodul auch zu einem späterem Zeitpunkt nachvollziehbar ist. Hierbei werden
sowohl die Funktionen, die für das Patientenmodul selbst entwickelt wurden gezeigt, als
auch die Schnittstelle, die in die Tinnitus-Datenbank eingebaut werden kann um mit dem
Patientenmodul zu kommunizieren. Der Einfachheit halber werden wir uns im Folgenden
auf die deutschsprachige Ansicht beschränken.
Tabelle 6.1: Abbildungsübersicht Walkthrough
Abbildung Beschreibung
6.1
Freischaltung von Fragebögen für Patient in der Tinnitus-
Datenbank.
6.2 Startseite des Patientenmoduls.
6.2 Startseite des Patientenmoduls zweiter Teil.
6.2.1 Registrierungsmail.
6.2.1 Leere Nutzerseite.
6.2.1 Gefüllte Nutzerseite.
6.2.1 Navigationsleiste.
31
6 Walkthrough
Tabelle 6.2: Abbildungsübersicht Teil 2 Walkthrough
Abbildung Beschreibung
6.2.2 Anzeige und Ausfüllen eines Fragebogens.
6.2.2 Fragebogen abschicken.
6.2.3 Passwort zurücksetzen und neues anfordern.
6.2.3 Wahl des neuen Passworts.
6.2.3 Profilanzeige.
6.2.3 Passwort ändern.
6.1 Tinnitus-Datenbank
Abbildung 6.1.1: Schnittstelle der Tinnitus Datenbank
Zunächst wird die Schnittstelle der Tinnitus-Datenbank erläutert. Die Abbildung 6.1
zeigt die Ansicht, die in die Tinnitus-Datenbank eingebaut werden soll. Ein Arzt kann
hier einfach den sog. userkey eines im Patientenmodul registrierten Patienten einge-
ben. Dann wählt er aus welche Fragebögen ausgefüllt werden sollen und schickt die
Informationen ab. Damit werden dem Patienten nur die ausgewählten Fragebögen im
Patientenmodul angezeigt. Waren für den Patienten bereits vorher schon im System
Fragebögen gespeichert als zu bearbeiten, bleiben sie das auch weiterhin.
32
6.2 Patientenmodul
Abbildung 6.2.1: Startseite des Patientenmoduls
6.2 Patientenmodul
Abbildung 6.2.2: Startseite des Patientenmoduls - Registrierung
Nach der Schnittstelle der Tinnitus-Datenbank wird nun das Patientenmodul gezeigt.
Die Abbildungen 6.2 und 6.2 zeigen die Startseite. Oben rechts ist eine Verlinkung zur
Tinnitus-Datenbank enthalten sowie die Möglichkeit eine andere Sprache über den Klick
auf die Flagge zu wählen. Standardmäßig wird die Seite auf Deutsch angezeigt. Wählt
man eine andere Sprache, so werden auch die folgenden Seiten in dieser angezeigt.
33
6 Walkthrough
6.2.1 Registrieren und anmelden
Registrierungsprozess
Abbildung 6.2.3: Bestätigung der Registrierung
Auf dem unteren Teil der Startseite (vgl. Abbildung 6.2) findet man den Teil für die Regis-
trierung. Man gibt hier die E-Mail-Adresse seines Arztes ein, der einen zur Anmeldung
aufforderte und wählt ein Passwort. Dieses muss mindestens die Länge 5 haben und zur
Sicherheit wiederholt werden. Der Arzt muss außerdem im Patientenmodul als solcher
angelegt sein. Wie in Abbildung 6.2.1 zu sehen, bekommt man nun mitgeteilt, dass eine
Aktivierungsmail an den Betreuer bzw. Arzt versandt wurde. Außerdem bekommt man
seine Id mitgeteilt. Falls der Arzt eine Vielzahl an Patienten hat, kann er anhand der Id
die richtige E-Mail herausfiltern. In der E-Mail steht dann der generierte Userkey für den
Patienten. Dies ist eine einzigartige Aneinanderreihung von Zahlen und Buchstaben.
Sie ersetzt den Benutzernamen oder ähnliches und dient als anonyme Identifikation der
Nutzer. Außerdem ist in der E-Mail ein Link, über den der Arzt diesen Patienten für das
Modul freischalten kann. Dort erhält er dann die Mitteilung Äctivated". Nun kann der
Nutzer sich anmelden. Vorher hat der Nutzer keinen Zugriff auf die Anwendung.
Anmeldung
Hat ein Nutzer sich registriert, kann er sich über den Userkey und sein gewähltes
Passwort im oberen Bereich der Startseite einloggen (vgl. Abbildung 6.2). Sollte der
Nutzer sein Passwort vergessen haben, so klickt er auf "Passwort vergessen" und kann
dort ein neues erhalten. Wie das funktioniert wird zu einem späteren Zeitpunkt (vgl.
6.2.3) genauer erklärt. Meldet sich ein gerade registrierter Nutzer an, kommt er auf
eine leere Startseite (vgl. Abbildung 6.2.1). Wie in Abschnitt 6.1 beschrieben, muss der
34
6.2 Patientenmodul
Abbildung 6.2.4: Leere Startseite des Nutzers
Abbildung 6.2.5: Gefüllte Startseite mit auszufüllenden Fragebögen
Betreuer erst die Fragebögen für den Nutzer über die Tinnitus-Datenbank freischalten.
Ist dies geschehen, sieht der Patient die Fragebögen, die er beantworten soll. Dies wird
in Abbildung 6.2.1 gezeigt. Außerdem hat jeder Nutzer stets Zugriff auf sein Profil (vgl.
6.2.3) und die Möglichkeit sich auszuloggen (vgl. 6.2.4). Diese Funktionen werden über
die Navigationsleiste (vgl. Abbildung 6.2.1) bereitgestellt.
Abbildung 6.2.6: Navigationsleiste
35
6 Walkthrough
6.2.2 Fragebögen
Fragebögen ausfüllen
Abbildung 6.2.7: Ansicht eines Fragebogens
Wählt der Patient auf seiner persönlichen Startseite einen Fragebogen aus, wird ihm
dieser wie in Abbildung 6.2.2 angezeigt und er kann ihn beantworten. Oben sieht er den
Namen des Fragebogens, den er aktuell ausfüllt. Darunter ist ein Button, mit dem er die
aktuellen Eingaben speichern kann. Dadurch werden seine Eingaben so gespeichert,
dass sie dem Patienten auch nach einem eventuellen Log-Out wieder zur Verfügung
stehen. Dies bedeutet, dass die Felder bei einem erneuten Log-In so ausgefüllt sind
wie sie es in dem Moment der Zwischenspeicherung waren. Wichtig ist, dass die Daten
nur lokal auf genau diesem Gerät (Rechner, Tablet, usw.) gespeichert werden. Sollte
der Nutzer das Gerät wechseln sind die aktuellen Antworten also nicht mehr vorhanden
(vgl. 5.2). Darunter wird angezeigt wie viele Seiten der Fragebogen hat und auf welcher
er sich gerade befindet. Schließlich werden die Fragen aufgelistet, sowie "Vor"- und
SZurück"-Buttons, mit denen der Nutzer zwischen den Seiten eines Fragebogens hin
und her blättern kann. Um die Bedienung zu erleichtern, ist das Durchblättern jedoch
auch mit den Pfeiltasten der Tastatur möglich. Daher wurden die Buttons übersichtlich
gehalten.
36
6.2 Patientenmodul
Fragebögen absenden
Abbildung 6.2.8: Ende eines Fragebogens
Auf der letzten Seite angelangt, ist der "VorButton verschwunden und stattdessen
direkt unter der letzten Frage ein "BestätigenButton erschienen. Ist der Nutzer mit
allen(!) Fragen fertig, kann er damit den Fragebogen absenden. Dadurch werden die
Antworten an die Tinnitus-Datenbank gesendet und der Nutzer hat keinen Zugriff mehr
auf diesen Fragebogen. Soll er ihn erneut ausfüllen, muss der Arzt diesen wieder
freischalten. Dadurch wird verhindert, dass die Patienten zu viele und eventuell unnötige
Fragebögen beantworten. Der Fragebogen ist dann in der Datenbank der Tinnitus-
Datenbank gespeichert, sodass die Nutzer der Tinnitus-Datenbank wie üblich Zugriff auf
die Daten haben. Damit sind die Daten der Tinnitus-Datenbank und des Patientenmoduls
vereint gespeichert.
6.2.3 Passwort
Damit ist die wichtigste Funktion des Patientenmoduls erläutert, doch es gibt noch
eine weitere Tätigkeit, die in der Anwendung ausgeführt werden kann. Das Passwort
ändern. Dies geht auf zwei verschiedene Arten. Die erste ist das Passwort neu zu setzen,
37
6 Walkthrough
Abbildung 6.2.9: Neues Passwort anfordern
falls man es vergessen hat. Dazu wählt der Nutzer auf der Startseite die "Passwort-
VergessenOption unter dem Log-In Bereich (vgl. Abschnitt 6.2). Der Nutzer gelangt dann
zur Seite, wo er seinen Userkey eingeben kann (vgl. Abbildung 6.2.3). Da der Nutzer für
die Anwendung anonym bleiben soll, sind von ihm keine E-Mail-Adresse oder andere
Kontaktdaten gespeichert. Daher wird der Code zum Zurücksetzen des Passworts
an den zuständigen Betreuer geschickt. Außerdem enthält die E-Mail den Link, über
den dies funktioniert. Auf der Seite angekommen, gibt der Nutzer den Code, seinen
Abbildung 6.2.10: Passwort neu wählen
Userkey und zwei Mal sein neues Passwort ein (vgl. Abbildung 6.2.3). Anschließend
hat der Patient nur noch mit diesem neuen Passwort Zugriff auf das System. Die zweite
Möglichkeit sein Passwort zu bearbeiten existiert für angemeldete Nutzer. Über den
"Profil" Reiter in der Navigationsleiste gelangen Sie zu einer Seite, auf der ihnen die
E-Mail-Adresse ihres Betreuers angezeigt wird (vgl. Abbildung 6.2.3). Außerdem können
Nutzer hier über die Auswahl des "ÄNDERN" Knopfes zur Wahl eines neuen Passworts
38
6.2 Patientenmodul
Abbildung 6.2.11: Profil anzeigen lassen
gelangen. Hier muss zunächst das alte Passwort eingegeben werden, bevor man sein
neues Passwort wählen kann. Dies muss zur Sicherheit zwei Mal eingegeben werden.
Anschließend klickt der Nutzer auf " OK ". Nun ist sein neues Passwort statt dem alten
gespeichert.
Abbildung 6.2.12: Passwort ändern
6.2.4 Abmeldung
Hat der Patient seine Tätigkeiten beendet, kann er sich aus dem System abmelden.
Dies geschieht über den "LOGOUT"-Button in der Navigationsleiste (vgl. Abbildung
6.2.1). Anschließend gelangt er wieder auf die Startseite des Patientenmoduls und er
hat keinen Zugriff auf die Anwendung. Möchte er diesen wieder haben, muss er sich
erneut anmelden. Das Abmelden ist wichtig, damit eventuelle andere Nutzer des Gerätes
keinen Zugriff auf seine Daten haben.
39
7
Abgleich der Anforderungen
In Kapitel 3 haben wir eine Auflistung der Anforderungen erstellt. Das folgende Kapitel
untersucht, ob die Anforderungen umgesetzt wurden. Hierzu werden sie aufgelistet und
anschließend bewertet ob sie erfüllt wurden.
7.1 Funktionale Anforderungen
Wir stellen nun die funktionalen Anforderungen ihrer tatsächlichen Umsetzung gegen-
über.
Tabelle 7.1: Anforderungsabgleich funktionale Anforderungen Tinnitus-Datenbank
Nr. Bezeichnung Umsetzung
1
Patient Fragebögen frei-
schalten
Die Anforderung wurde erfüllt (siehe 6.2.2)
2 Fragebogen speichern
Da die Fragebögen über die Schnittstelle in der Da-
tenbank der Tinnitus-Datenbank gespeichert werden,
wurde die Anforderung wie definiert umgesetzt und
damit erfüllt. (siehe 6.2.2)
41
7 Abgleich der Anforderungen
Tabelle 7.2: Anforderungsabgleich funktionale Anforderungen Patientenmodul
Nr. Bezeichnung Beschreibung
1. Registrieren Die Anforderung wurde erfüllt (siehe 6.2.1)
2. Anmelden Die Anforderung wurde erfüllt (siehe 6.2.1)
3. Abmelden Die Anforderung wurde erfüllt (siehe 6.2.4)
4. Passwort ändern Die Anforderung wurde erfüllt (siehe 6.2.3)
5. Fragebögen anzeigen Die Anforderung wurde erfüllt (siehe 6.2.3)
6. Fragebogen anzeigen Die Anforderung wurde erfüllt (siehe 6.2.3)
7. Fragebogen ausfüllen Die Anforderung wurde erfüllt (siehe 6.2.2)
8. Zwischenspeichern Die Anforderung wurde wurde erfüllt (siehe 6.2.2)
9. Keine Voreinstellungen
Die Anforderung wurde erfüllt. Alle Eingabefelder sind
zu Beginn leer.
10.
Mehrsprachigkeit
Die Anforderung wurde erfüllt. Aktuell gibt es die Mög-
lichkeit das System auf Deutsch oder auf Englisch zu
nutzen.
11.
Sprachen einbinden Die Anforderung wurde erfüllt (siehe 5.3)
Nach dem Abgleich wird festgestellt, dass alle gestellten funktionalen Anforderungen
erfüllt wurden.
7.2 Nicht-funktionale Anforderungen
In diesem Abschnitt werden die aufgestellten nicht-funktionalen Anforderungen aufgelis-
tet und überprüft.
42
7.2 Nicht-funktionale Anforderungen
Tabelle 7.3: Anforderungsabgleich nicht-funktionale Anforderungen
Nr. Bezeichnung Beschreibung
1. Verfügbarkeit
Die Anforderung wurde erfüllt. Das System ist eine
Webanwendung und läuft damit von überall und un-
ter der Bedingung der Server-Erreichbarkeit auch zu
jedem Zeitpunkt.
2.
Technische Unabhängig-
keit
Die Anforderung wurde erfüllt. Das Modul wurde un-
abhängig von Browser und Betriebssystem entwickelt.
3. Stabilität und Robustheit
Die Anforderung wurde erfüllt. Das Patientenmodul
konnte sehr robust entwickelt werden und durch die
niedrige Komplexität wurden eventuelle Fehlerquellen
möglichst gering gehalten, bzw. sogar vermieden (vgl.
Anhang A).
4. Fehlervermeidung
Die Anforderung wurde erfüllt. Durch die geringe Kom-
plexität und die gut übersichtlichen Fragebögen wer-
den Fehler möglichst gering gehalten.
5. Nutzerfreundlichkeit
Die Anforderung wurde erfüllt (siehe 6.2). Das System
wurde sehr einfach, mit deutlicher Schrift, Buttons und
Farbunterstützung gestaltet.
Da neben den funktionalen auch die nicht-funktionalen Anforderungen komplett erfüllt
werden konnten, sind zusammenfassend alle Anforderungen erfüllt.
43
8
Zusammenfassung und Ausblick
Im letzten Kapitel sollen noch einmal die wichtigsten Aspekte der Arbeit zusammen-
gefasst werden. Wir greifen sie auf und heben die Besonderheiten hervor, sodass ein
Überblick über das Konzept und die Realisierung des Systems entsteht. Dazu werden im
folgenden Abschnitt zuerst die vorliegenden Kapitel zusammen gefasst und im Abschnitt
8.2 wird daraus ein Fazit gezogen. Im letzten Schritt (vgl. 8.3) soll dann ein Ausblick
über die weitere Entwicklung des Moduls und der Tinnitus-Datenbank gegeben werden.
8.1 Zusammenfassung
Die Einführung der Arbeit befasste sich mit der Erkrankung Tinnitus. Tinnitus wurde
als störendes Phantomgeräusch vorgestellt, das an verschiedenen Stellen im Kopf,
meist aber in einem oder in beiden Ohren wahrgenommen wird. Die Problematik des
Tinnitus besteht hierbei aus seinen vielfältigen Ausprägungen. So gibt es verschiedene
Tonarten, Tonhöhen, Zeiten der Wahrnehmung, verschiedene begleitende Symptome,
usw. Dadurch sind viele Patienten und Ärzte hilflos und überfordert mit der Behandlung.
Deshalb wurde die Tinnitus-Datenbank entwickelt. Mit Hilfe von Fragebögen soll der
richtige Therapieansatz gefunden und die Entwicklung eines Patienten, sowie eventuelle
Erfolge oder Misserfolge der gewählten Behandlung festgehalten werden. Auch können
statistische Bewertungsmethoden auf den Daten angewandt werden. Dieses System ist
folglich sehr komplex und kann nur von Personen mit geeignetem Vorwissen bedient
werden, sodass aktuell nur die Ärzte Patientendaten eingeben.
Das Patientenmodul soll eine Erweiterung darstellen, um diesen Prozess zu vereinfachen.
Die Patienten können selbst Daten eingeben ohne mit den ganzen Zusatzfunktionen
45
8 Zusammenfassung und Ausblick
in Berührung zu kommen, oder gar verwirrt zu werden. Dadurch wird die Datensamm-
lung vereinfacht und es kann mehr gespeichert werden. Dies soll die Forschung und
Behandlung voran treiben.
In Kapitel 2 wurden Arbeiten vorgestellt, die sich ebenfalls mit der Tinnitus-Datenbank
beschäftigt haben (vgl. 2.2 und 2.3). Außerdem wurden auch Arbeiten erläutert, die sich
mit Projekten beschäftigen, in denen Patienten ebenfalls selbst teilnehmen sollen wie
in dem Fall dieser Arbeit (vgl. 2.1). Die Anwendung wurde dann entwickelt mit einer
prototypischen Einbindung von drei Fragebögen, dem TSCHQ, THI und dem Tinnitus
Fragebogen. Dazu wurden zunächst in Kapitel 3 die Anforderungen aufgestellt, die das
System aufweisen muss. Es existieren hierbei funktionale und nicht-funktionale Anfor-
derungen. In Kapitel 7 wurde dann überprüft, inwiefern die Anforderungen umgesetzt
wurden.
8.2 Fazit
Das Ziel dieser Arbeit war es eine leicht bedienbare Anwendung zu entwickeln, mit
der Patienten selbstständig an der Tinnitus-Datenbank teilnehmen können. Die Umset-
zung erfolgte als PHP-Webanwendung. Es wurden dabei drei Fragebögen angelegt.
Das Konzept der Anwendung ist ein System mit geringer Komplexität, das nahezu
selbsterklärend ist und mit einfachem und doch ansprechendem Design die Nutzer zum
Mitmachen animiert. Durch die Nutzung von Jquery-Steps konnte das ansprechende
Design gestaltet werden und auch das restliche System wurde durch die Auslassung
von unnötigen Funktionen gut verständlich gehalten. Zudem bietet die Mehrsprachigkeit
Nutzern weltweit die Möglichkeit das Patientenmodul zu nutzen. Die einfache Einbindung
neuer Sprachen fördert dabei, dass viele Nutzer in ihrer Landessprache antworten
können.
Das Patientenmodul erweist sich damit als gute Option für die Weiterführung und Wei-
terentwicklung der TinnitusDatabase. Es kann zum Wachstum der Datenbank einen
wertvollen Teil liefern und somit langfristig die Behandlung von vielen Patienten un-
terstützen. Zusammenfassend lässt sich voraussagen, dass das System einen hohen
46
8.3 Ausblick
Zuspruch erwarten kann, sodass eine Motivation besteht die Anwendung weiter voran
zu treiben. Im folgenden Abschnitt werden Ideen vorgestellt, wie dies geschehen kann.
8.3 Ausblick
Das aktuelle Konzept beschränkte sich darauf alle Fragebögen, die beantwortet werden
sollen anzuzeigen. Dies funktioniert bei drei umgesetzten Fragebögen auch noch gut.
Für den realen Einsatz des Systems gibt es allerdings noch viele weitere Fragebögen,
sodass darüber nachgedacht werden kann, die Fragebögen nacheinander freizuschalten.
Hierzu muss eine Kategorisierung und eventuell Priorisierung der Fragebögen stattfinden
und eine Funktion eingeführt werden, die nach dem Beantworten eines Fragebogens
den nächsten freischaltet. In der Arbeit [
24
] wurde beispielsweise der Nutzen einer
Klassifizierung von Krankheiten mittels mehr als einer Variable vorgestellt. So kann der
Tinnitus über seine Lautstärke oder auch die psychischen Auswirkungen bewertet wer-
den. Auch in dieser Richtung könnten die Fragebögen des Patientenmoduls kategorisiert
werden.
Um die Übersichtlichkeit für den Nutzer beizubehalten muss dann auch über eine Anzei-
ge nachgedacht werden, beispielsweise eine Leiste die anzeigt wie viele Fragebögen
man bearbeitet hat und wie viele noch kommen werden. Dies könnte ähnlich der aktuel-
len Umsetzung der Seitenanzeige innerhalb eines Fragebogens sein. Außerdem könnte
das Patientenmodul ähnlich wie das SRQ (vgl. 2.1) weitere Funktionen für den Patienten
beinhalten, wie beispielsweise Informationen für bevorstehende Untersuchungen oder
unkomplizierte Übersichten seiner Werte.
Außerdem könnte das Patientenmodul die Lücke zwischen verschiedenen Zielgruppen
schließen. In der Arbeit [
25
] wurde ein unterschiedliches Publikum auf unterschiedlichen
Plattformen festgestellt. So sind die Nutzer von mobilen Anwendungen eher jünger als
die Patienten in Kliniken. Dies könnte beispielsweise über eine App ermöglicht werden.
Die Arbeit [
26
] befasste sich beispielsweise mit einer Studie, die die Umsetzung auf einer
Smartwatch beurteilte. Da dieses Verfahren gut angenommen wurde, ist zu erwarten,
47
8 Zusammenfassung und Ausblick
dass die Nutzer eine Anwendung auf anderen mobilen Endgeräten ebenso annehmen
würden. Dazu müsste die Darstellung auf mobile Endgeräte angepasst werden.
Zuletzt ist die Ausdehnung auf weitere medizinische Bereiche ein bisher nicht genutztes
Entwicklungspotenzial. Die Tinnitus-Datenbank selbst, ebenso wie das Patientenmodul,
sind zusammen in der Form eine Seltenheit. Die Suche nach verwandten Arbeiten zu
Patientenmodulen gestaltete sich sehr schwierig, sodass offensichtlich ist, dass hier
viele offene Optionen bestehen. Das Projekt SRQ(vgl. 2.1) zeigt, dass die Idee auch er-
folgreich auf andere Krankheiten anwendbar ist. Viele Krankheiten eignen sich für dieses
System und die Krankheitsraten, vor allem bei psychischen Krankheiten, wie beispiels-
weise Depressionen, steigen stetig [
27
]. Zu erwarten ist, dass eine solche Datenbank
inklusive Patientenmodul auch bei Patienten solcher Krankheiten gut angenommen wird,
da sich auch hier vielfältige Therapieansätze vorfinden lassen.
Abschließend bietet das Patientenmodul viele Möglichkeiten sich weiter zu entwickeln
und die Forschung zu unterstützen. So kann das System selbst erweitert, oder aber
auch auf andere Gebiete übertragen werden. Wie sich das System jedoch tatsächlich
langfristig in den täglichen Gebrauch der Ärzte und Patienten integrieren lässt, wurde
im Rahmen dieser Arbeit nicht untersucht. Die Überprüfung bleibt demnach ebenso für
folgende Arbeiten offen.
48
Literaturverzeichnis
[1]
Møller, A., Kleinjung, T.: Textbook of tinnitus. Springer, New York (2011) 11: 302.
CrossRef MEDLINE PubMed Central.
[2]
Hall, D., Lainez, M., Newman, C., Sanchez, T., Egler, M., Tennigkeit, F., et al.:
Treatment options for subjective tinnitus : self reports from a sample of general
practitioners and ENT physicians within Europe and the USA. BMC Health Serv
Res (2011) 11: 302. CrossRef MEDLINE PubMed Central.
[3] Snow, J.B.: Tinnitus Theory and Management. BC Decker Inc (2004) p.6-41.
[4]
Hebert, S., Canlon, B., Hasson, D., Hanson, L.M., Westerlund, H., Theorell, T.:
Tinnitus
severity is reduced with reduction of depressive mood-a prospective
population
study in Sweden. PLoS One (2012) 7: e37733. CrossRef MEDLINE
PubMed Central.
[5]
Serquera, J., Schlee, W., Pryss, R., Neff, P., Langguth, B.: Music technology for
tinnitus treatment within tinnet, In: Audio Engineering Society Conference: 58th
International Conference: Music Induced Hearing Disorders, Audio Engineering
Society (2015)
[6]
Schobel, J., Pryss, R., Wipp, W., Schickler, M., Reichert, M.: Mobile Service Engine
Enabling Complex Data Collection Applications. In: 14th International Conference
on Service Oriented Computing. (Number 9936 in LNCS) ICSOC 2016.
[7]
Schobel, J., Pryss, R., Schickler, M., Reichert, M.: A Lightweight Process Engine
for Enabling Advanced Mobile Applications. In: 24th International Conference on
Cooperative Information Systems (CoopIS 2016). Number 10033 in LNCS. Springer
(2016)
[8]
Schobel, J., Pryss, R., Schickler, M., Reichert, M.: A Configurator Component for
End-User Defined Mobile Data Collection Processes. In: Demo Track of the 14th
International Conference on Service Oriented Computing. (ICSOC 2016)
49
Literaturverzeichnis
[9]
Tinnitus-Database: https://www.tinnitus-database.de/welcome. (zuletzt besucht:
07.01.2018)
[10]
Tinnitus Research Initiative: TINNITUS
SAMPLE
CASE HISTORY
QUESTIONNAIRE
(TSCHQ). http://www.tinnitusresearch.org/images/files/migrated
/consensusdocuments/en
/TINNITUS_SAMPLE_CASE_HISTORY
_QUESTIONNAIRE.pdf (zuletzt besucht: 25.01.2018)
[11]
Newman, C.W., Jacobson, G.P., Spitzer, J.B.: Development of the tinnitus handicap
inventory. Archives of Otolaryngology–Head and Neck Surgery, vol. 122, no. 2, pp.
143–148 (1996)
[12]
Hallam, R.S.: TQ – manual of the tinnitus questionnaire – revised and updated.
(2008)
[13]
Svensk Reumatologis Kvalitetsregister, SRQ: SRQ. http://srq.nu/en/ (zuletzt
besucht: 07.01.2018)
[14]
Hagenlocher, R.: Designkonzept für eine Webanwendung zum Zugriff auf eine
interdisziplinäre und multinationale Datenbank zur Erfassung Tinnitus-geschädigter
Patienten. Universität Ulm - Institut für Datenbanken und Informationssysteme
(2015)
[15]
SELFHTML e.V.: HTML. http://wiki.selfhtml.org/wiki/HTML (zuletzt besucht:
20.01.2018)
[16]
W3.CSS: CSS Tutorial. https://www.w3schools.com/css/ (zuletzt besucht:
20.01.2018)
[17] Oracle: MySQL. https://www.mysql.com/de/ (zuletzt besucht: 10.12.2017)
[18]
The PHP Group: PHP-Handbuch. http://www.php.net/manual/de/ (zuletzt besucht:
20.12.2017)
[19]
Baltakiranoglu, B.: Konzeption und Realisierung eines Patientenmoduls für
eine
multinationale und interdisziplinäre Datenbank. Universität Ulm - Institut für
Datenbanken und Informationssysteme (2015)
50
Literaturverzeichnis
[20]
javascript.com: javascript.com. https://www.javascript.com/ (zuletzt besucht:
15.01.2018)
[21] The jQuery Foundation: jQuery. https://jquery.com/ (zuletzt besucht: 10.12.2017)
[22]
Staib, R.: jQuery Steps. http://www.jquery-steps.com/ (zuletzt besucht: 12.01.2018)
[23]
Mozilla: Window.localStorage. https://developer.mozilla.org/de/docs/Web/API/
Window/localStorage (zuletzt besucht: 19.02.2018)
[24]
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)
[25]
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. Frontiers in Aging Neuroscience, 9 . p. 113 (2017)
[26]
Elsässer, V.: Konzeption und Realisierung für ein mobiles
Smartwatch
-
Fragebogensystem zur Erfassung klinischer Parameter Tinnitus-geschädigter
Patienten
. Universität Ulm - Institut für Datenbanken und Informationssysteme
(2016)
[27]
Bundesministerium für Gesundheit: Depression. (https://www. bundesgesundheits-
ministerium.)
[28]
Witte, F.: Testmanagement und Softwaretest - Theoretische Grundlagen und
praktische Umsetzung. Springer (2015)
51
A Manuelle Tests
Zu testende
Funktion
Ablauf gewünschtes Ergebnis Testergebnis
Registrieren
Gehe auf die Startseite und
dort zum Bereich "Registrie-
ren". Gebe zwei Mal das glei-
che Passwort ein und eine gül-
tige E-Mail-Adresse eines be-
kannten Betreuers. Drücke auf
"Bestätigen".
Ein inaktiver Nutzer ist in
Datenbank angelegt wor-
den. Meldung mit zuge-
wiesener Id erscheint. E-
Mail an den Betreuer mit
dem Userkey wurde ge-
sendet. Der Nutzer hat
noch keinen Zugang zum
System.
OK.
Nutzer akti-
vieren
Ein Nutzer registriert sich mit
gültigen Eingaben. Der Betreu-
er erhält eine E-Mail. In der E-
Mail ist ein Aktivierungslink ent-
halten. Klicke auf den Link.
Es erscheint eine Mel-
dung, dass der Nutzer ak-
tiviert wurde und er hat
nun Zugang zum Sys-
tem.
OK.
Anmelden
Gehe auf die Startseite und ge-
be den Userkey des eben re-
gistrierten Nutzers, sowie sein
Passwort ein. Klicke auf "Bestä-
tigen".
Nutzer hat Zugriff auf
Systemfunktionen.
OK.
Abmelden
Klicke in der Navigationsleiste
des eben angemeldeten Nut-
zers auf den "Logout" -Button.
Es erfolgt eine Weiter-
leitung zur Startseite
des Patientenmoduls.
Der Nutzer hat keinen
Zugriff mehr auf die
Systemfunktionen
OK.
Passwort ver-
gessen
Klicke auf der Startseite auf
"Passwort vergessen". Gebe
auf der folgenden Seite User-
key von eben registriertem Nut-
zer ein. Klicke auf " Send ".
Nutzer wird in Daten-
bank als inaktiv markiert.
Betreuer erhält E-Mail
mit Aktivierungscode und
Link.
OK.
54
Zu testende
Funktion
Ablauf gewünschtes Ergebnis Testergebnis
Passwort zu-
rücksetzen
Melde das Passwort als ver-
gessen. Klicke auf den Link
in der E-Mail an den Betreuer.
Gebe dort Den Code, Userkey
und zwei Mal das gleiche neue
Passwort ein. Klicke auf " Send
".
Nutzer ist in der Daten-
bank wieder als aktiv
gekennzeichnet. Neues
Passwort ist gespeichert.
Nutzer hat nun damit Zu-
gang zum System, je-
doch nicht mehr mit dem
alten Passwort.
OK.
Profil anzei-
gen
Melde einen Nutzer an. Kli-
cke in der Navigationsleiste auf
"Profil".
Die E-Mail des Betreuers
wird angezeigt. Darunter
ein "Ändern" -Button.
OK.
Passwort än-
dern
Klicke im Bereich " Profil " auf
"Ändern". Gebe auf folgender
Seite das alte Passwort, so-
wie zwei Mal das gleiche neue
Passwort ein. Klicke auf " OK ".
Logge dich aus.
Neues Passwort ist in Da-
tenbank gespeichert. Der
Nutzer hat nur noch mit
dem neuen Passwort Zu-
griff auf das System.
OK.
Fragebögen
freischalten
Gehe auf die Schnittstelle der
Tinnitus-Datenbank. Gebe den
Userkey von eben registriertem
Nutzer an und wähle alle drei
Fragebögen aus. Klicke auf "
SEND ".
Nutzer wurde in die ’pati-
ents’ Datenbank des Pa-
tientenmoduls eingefügt
und alle drei Fragebögen
als auszufüllen markiert.
Nach dem Log-In wer-
den dem Nutzer alle an-
gezeigt und er hat Zugriff
auf diese.
OK.
TSCHQ aus-
wählen
Melde einen Nutzer an, der den
TSCHQ auszufüllen hat laut
Datenbank. Klicke auf der Start-
seite auf "TSCHQ".
Der TSCHQ wird wie
in Abbildung 6.2.2 ange-
zeigt und die Fragen sind
beantwortbar.
OK.
TSCHQ ab-
senden
Angemeldeter Nutzer füllt den
TSCHQ aus. Jedes Feld ist be-
füllt. Auf der letzten Seite klicke
auf "Bestätigen".
Der Fragebogen wird in
die Tinnitus-Datenbank
gespeichert. In der ’pa-
tients’ Tabelle ist der
TSCHQ nicht mehr als
auszufüllen markiert. Der
Nutzer hat keinen Zugriff
mehr auf den TSCHQ.
OK.
55
A Manuelle Tests
Zu testende
Funktion
Ablauf gewünschtes Ergebnis Testergebnis
THI auswäh-
len
Melde einen Nutzer an, der den
THI auszufüllen hat laut Daten-
bank. Klicke auf der Startseite
auf "THI".
Der THI wird wie in Ab-
bildung 6.2.2 angezeigt
und die Fragen sind be-
antwortbar.
OK.
THI absen-
den
Angemeldeter Nutzer füllt den
THI aus. Jedes Feld ist befüllt.
Auf der letzten Seite klicke auf
"Bestätigen".
Der Fragebogen wird in
die Tinnitus-Datenbank
gespeichert. In der ’pati-
ents’ Tabelle ist der THI
nicht mehr als auszufül-
len markiert. Der Nutzer
hat keinen Zugriff mehr
auf den THI.
OK.
TQ auswäh-
len
Melde einen Nutzer an, der den
TQ auszufüllen hat laut Daten-
bank. Klicke auf der Startseite
auf "Tinnitus Fragebogen".
Der TQ wird wie in Ab-
bildung 6.2.2 angezeigt
und die Fragen sind be-
antwortbar.
OK.
TQ absen-
den
Angemeldeter Nutzer füllt den
TQ aus. Jedes Feld ist befüllt.
Auf der letzten Seite klicke auf
"Bestätigen".
Der Fragebogen wird in
die Tinnitus-Datenbank
gespeichert. In der ’pati-
ents’ Tabelle ist der TQ
nicht mehr als auszufül-
len markiert. Der Nutzer
hat keinen Zugriff mehr
auf den TQ.
OK.
Letzter Fra-
gebogen ab-
geschickt
Lasse einen Nutzer nacheinan-
der alle Fragebögen beantwor-
ten, die er auszufüllen hat.
Ist der letzte Fragebogen
ausgefüllt, wird der Nut-
zer aus der Tabelle ’pati-
ents’ entfernt.
OK.
Zwischenspei-
chern
Melde Nutzer an, der einen be-
liebigen Fragebogen auszufül-
len hat (bspw. TSCHQ). Wähle
den TSCHQ aus und fülle eine
beliebige Anzahl von Feldern
(mindestens eins). Klicke auf
" Zwischenspeichern ". Logge
Nutzer aus.
Bei erneutem Log-In wird
dem Nutzer der Fragebo-
gen so angezeigt, wie er
ihn ausgefüllt hatte zum
Zeitpunkt des Zwischen-
speicherns.
OK.
56
Tabelle A.1: Negativ-Tests
Zu testende
Funktion
Ablauf gewünschtes Ergebnis Testergebnis
Registrieren
Gehe auf die Startseite und
dort zum Bereich "Registrie-
ren". Gebe zwei unterschiedli-
che Passwörter und einen gül-
tigen Betreuer ein. Drücke auf
"Bestätigen".
Eine Fehlermeldung er-
scheint. E-Mail an den
Betreuer mit dem User-
key wurde nicht gesen-
det. Der Nutzer hat kei-
nen Zugang zum System
und es wurde auch kein
neuer Nutzer in der Da-
tenbank angelegt.
OK.
Registrieren
Gehe auf die Startseite und
dort zum Bereich "Registrie-
ren". Gebe zwei mal das glei-
che Passwort und einen dem
System unbekannten Betreuer
an. Drücke auf "Bestätigen".
Eine Fehlermeldung er-
scheint. Es wurde kein
Nutzer in der Datenbank
des Patientenmoduls an-
gelegt. Eine E-Mail an
den Betreuer mit dem
Userkey wurde nicht ge-
sendet. Der Nutzer hat
keinen Zugang zum Sys-
tem.
OK.
Anmelden
Gehe auf die Startseite und ge-
be den Userkey eines registrier-
ten Nutzers, sowie ein ungül-
tiges Passwort ein. Klicke auf
"Bestätigen".
Eine Fehlermeldung er-
scheint. Der Nutzer hat
keinen Zugriff auf Sys-
temfunktionen.
OK.
Passwort ver-
gessen
Klicke auf der Startseite auf
"Passwort vergessen". Gebe
auf der folgenden Seite einen
ungültigen Userkey ein. Klicke
auf " Send ".
Fehlermeldung erscheint.
Kein Nutzer wird in Da-
tenbank als inaktiv mar-
kiert. Betreuer erhält kei-
ne E-Mail mit Aktivie-
rungscode und Link.
OK.
57
A Manuelle Tests
Tabelle A.2: Negativ-Tests zweiter Teil
Zu testende
Funktion
Ablauf gewünschtes Ergebnis Testergebnis
Passwort zu-
rücksetzen
Melde das Passwort als verges-
sen. Klicke auf den Link in der
E-Mail an den Betreuer. Gebe
dort Den Code, Userkey und
zwei unterschiedliche Passwör-
ter ein. Klicke auf " Send ".
Eine Fehlermeldung er-
scheint. Nutzer ist in der
Datenbank nicht wieder
als aktiv gekennzeichnet.
Kein neues Passwort ist
gespeichert.
OK.
Passwort än-
dern
Klicke im Bereich " Profil äuf
"Ändern". Gebe auf folgender
Seite ein anderes Passwort als
das alte ein, sowie zwei Mal
das gleiche neue Passwort ein.
Klicke auf " OK ".
Eine Fehlermeldung er-
scheint. Das neue Pass-
wort ist nicht in Daten-
bank gespeichert. Der
Nutzer hat immer noch
mit dem alten Passwort
Zugriff auf das System.
OK.
TSCHQ ab-
senden
Angemeldeter Nutzer füllt den
TSCHQ aus. Nicht jedes Feld
ist befüllt. Auf der letzten Seite
klicke auf "Bestätigen".
Ein Fehler wird ange-
zeigt. Der Fragebogen
wird nicht in die Tinnitus-
Datenbank gespeichert.
In der ’patients’ Tabel-
le ist der TSCHQ immer
noch als auszufüllen mar-
kiert.
OK.
THI absen-
den
Angemeldeter Nutzer füllt den
THI aus. Nicht jedes Feld ist be-
füllt. Auf der letzten Seite klicke
auf "Bestätigen".
Ein Fehler wird ange-
zeigt. Der Fragebogen
wird nicht in die Tinnitus-
Datenbank gespeichert.
In der ’patients’ Tabelle
ist der THI immer noch
als auszufüllen markiert.
OK.
TQ absen-
den
Angemeldeter Nutzer füllt den
TQ aus. Nicht jedes Feld ist be-
füllt. Auf der letzten Seite klicke
auf "Bestätigen".
Ein Fehler wird ange-
zeigt. Der Fragebogen
wird nicht in die Tinnitus-
Datenbank gespeichert.
In der ’patients’ Tabelle
ist der TQ immer noch
als auszufüllen markiert.
OK.
58
Abbildungsverzeichnis
2.3.1 Breadcrumps [19] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1 Anwendungsfalldiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.1 Genereller Ablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.1 Patientenmodul Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.2 Datenbank Tinnitus-Datenbank . . . . . . . . . . . . . . . . . . . . . . . 20
4.3.1 MVC-Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1.1 Schnittstelle der Tinnitus Datenbank . . . . . . . . . . . . . . . . . . . . 32
6.2.1 Startseite des Patientenmoduls . . . . . . . . . . . . . . . . . . . . . . . 33
6.2.2 Startseite des Patientenmoduls - Registrierung . . . . . . . . . . . . . . 33
6.2.3 Bestätigung der Registrierung . . . . . . . . . . . . . . . . . . . . . . . . 34
6.2.4 Leere Startseite des Nutzers . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2.5 Gefüllte Startseite mit auszufüllenden Fragebögen . . . . . . . . . . . . 35
6.2.6 Navigationsleiste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2.7 Ansicht eines Fragebogens . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.2.8 Ende eines Fragebogens . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.2.9 Neues Passwort anfordern . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.2.10 Passwort neu wählen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.2.11 Profil anzeigen lassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.2.12 Passwort ändern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
59
Tabellenverzeichnis
Tabellenverzeichnis
3.1 Anforderungen Tinnitus-Datenbank . . . . . . . . . . . . . . . . . . . . . 13
3.2 Anforderungen Patientenmodul . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Anforderungen Patientenmodul zweiter Teil . . . . . . . . . . . . . . . . 14
6.1 Abbildungsübersicht Walkthrough . . . . . . . . . . . . . . . . . . . . . . 31
6.2 Abbildungsübersicht Teil 2 Walkthrough . . . . . . . . . . . . . . . . . . 32
7.1 Anforderungsabgleich funktionale Anforderungen Tinnitus-Datenbank . 41
7.2 Anforderungsabgleich funktionale Anforderungen Patientenmodul . . . . 42
7.3 Anforderungsabgleich nicht-funktionale Anforderungen . . . . . . . . . . 43
A.1 Negativ-Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
A.2 Negativ-Tests zweiter Teil . . . . . . . . . . . . . . . . . . . . . . . . . . 58
60
Name: Leyla Ernst Matrikelnummer: 854488
Erklärung
Ich erkläre, dass ich die Arbeit selbstständig verfasst und keine anderen als die angege-
benen Quellen und Hilfsmittel verwendet habe.
Ulm,den .............................................................................
Leyla Ernst
