Universität Ulm | 89069 Ulm | Germany Fakultät für
Ingenieurwissenschaften
und Informatik
Institut für Datenbanken
und Informationssysteme
Entwicklung und Konzeption einer Kom-
ponente zur Konfiguration von therapeu-
tischen Interventionen
Masterarbeit an der Universität Ulm
Vorgelegt von:
Andreas Reiter
Gutachter:
Prof. Dr. Manfred Reichert
Dr. Rüdiger Pryss
Betreuer:
Marc Schickler
2017
Fassung 14. November 2017
c
2017 Andreas Reiter
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
Mit der weiten Verbreitung von Smartphones und Tablets und deren Fülle an Anwen-
dungsmöglichkeiten eröffnen sich im Gesundheitssektor bis dato ungeahnte Möglichkei-
ten. Gerade Anwendungen die Therapien unterstützen, bieten ein großes Potential. In
dieser Arbeit soll ein Prototyp einer Therapieplanungsanwendung erstellt werden, der
es Therapeuten ermöglicht Hausaufgaben und Übungen zu definieren, die in einem
Prozessmodell resultieren.
Der webbasierte Planer ermöglicht das Erstellen und Verwalten eigener Therapien, die
Terminierung von Präsenzveranstaltungen, sowie die Konfiguration von Hausaufgaben
und der dazugehörigen Übungen. Das Herzstück des Prototypen bildet das eigens
entwickelte und umgesetzte Konzept für die Übungserstellung und -konfiguration.
Im Nachgang zur Entwicklung und Realisierung soll eine Studie darlegen, in wie weit
dieser Ansatz zur Therapieplanung und Übungskonfiguration umsetzbar ist.
iii
Inhaltsverzeichnis
1 Einleitung 1
1.1 Ziel der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Grundlagen 5
2.1 Therapeutische Interventionen . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Therapieplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Hausaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1 Übungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.2 Benachrichtigungen . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.3 Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3 Related Work 11
3.1 SimpleSet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Physitrack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 TheRehablab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4 Anforderungsanalyse 17
4.1 Nicht funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5 Entwurf 23
5.1 Benutzeroberfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.1.1 Bedienkonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1.2 Übungskonfigurator . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.1.3 Prozessmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2 Datenbankschema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6 Realisierung 31
6.1 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.1.1 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
v
Inhaltsverzeichnis
6.1.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.1.3 Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.2 UI-Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.3 Übungskonfigurator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.3.1 Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.3.2 Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.3.3 Möglichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.3.4 Einschränkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.4 Prozessmodellgenerator . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.4.1 Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.4.2 Datenkonzept und Funktion . . . . . . . . . . . . . . . . . . . . . . 42
7 Anforderungsabgleich 45
7.1 Nicht Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . 45
7.2 Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.3 Ergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
8 Studie 53
8.1 Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.2 Durchführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
8.3 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
9 Diskussion 61
10 Zusammenfassung und Ausblick 65
vi
1
Einleitung
Smartphones und Tablets sind aus dem heutigen Alltag nicht mehr wegzudenken. Die
Fülle an Anwendungen, die für diese Geräte zur Verfügung stehen erstrecken sich in die
unterschiedlichsten Bereiche. Alleine im Bereich Gesundheit gibt es mehr als 400.000
Anwendungen. Die SmartHealth-Studie 2016 der Techniker Krankenkasse ergab unter
anderem, dass die Mehrheit der Befragten fest davon ausgehen, dass der Einsatz von
Gesundheitsapps in zehn Jahren fest zu ihrem Alltag gehören wird. Gerade junge Leute
können sich zukünftig eine mobile Anwendung als Teil einer Therapie vorstellen [
Meu16
].
Der Umfang solcher Therapien kann von einfachen Erinnerungen an die Einnahme eines
Medikaments bis hin zu vielschichtigen Therapieformen mit Hausaufgaben an Patienten,
reichen. Gerade für solch komplexe Behandlungen ist therapeutisches Fachpersonal
nötig, um den Patienten bestmöglich zu unterstützen. Der Sachverhalt, dass mit Hilfe
von Smartphones und Tablets Therapieinhalte auch von zu Hause aus erledigt werden
können, ermöglicht ein weites Feld an Anwendungsmöglichkeiten für Therapeuten und
Ärzte [
SPS+17b
,
BSVV07
]. Mit dieser Möglichkeit lassen sich zum Beispiel körperliche
Übungen, Fragen nach dem Befinden oder auch Messdaten von den Praxisräumen
direkt zum Patienten übertragen.
Medizinisches Fachpersonal hat jedoch meist keinerlei Kenntnis über Prozesse und
deren Modellierung, die für umfangreiche Therapien nötig sind. Daraus ergibt sich die
Frage, ob es möglich ist, komplexe Behandlungen mit Hausaufgaben und Übungen für
den Patienten auch ohne dieses Wissen planen zu können. In der nachfolgenden Arbeit
soll anhand einer modellhaften Therapieplanungsanwendung versucht werden, diese
Frage zu beantworten.
1
1 Einleitung
1.1 Ziel der Arbeit
Ziel dieser Arbeit ist es eine prototypische Plattform
Albatros
zu realisieren, mit der
es möglich ist therapeutische Interventionen zu planen. Dazu gehört die Umsetzung
eins Therapieplaners mit dazugehörigen Terminen, an denen der Teilnehmer beim
Therapeuten präsent ist, sowie Hausaufgaben für den Patienten. Als Beispiel für einen
solchen Termin könnte man ein Einführungs- oder Abschlussgespräch zur jeweiligen
Therapie anführen, zu denen der Patient in die Praxis kommen müsste. Den Hauptteil
der Plattform nimmt der Hausaufgabenbereich ein. Dort sollen Benachrichtigungen
und Rückmeldungen als Kommunikationspunkte mit dem Anwender entstehen. Zudem
sind Übungen ein essentieller Bestandteil einer Hausaufgabe, denn anhand dieser
Aufgaben soll der Patient seine Beschwerden und Probleme lindern, beziehungsweise
im Optimalfall lösen. Somit lassen sich innerhalb einer Hausaufgabe die drei eben
genannten Bestandteile zusammenfassen.
Der Fokus bei diesem Projekt liegt vor allem auf der Erstellung von Übungen, die einem
Patienten zum Beispiel auf einer mobilen Anwendung zur Verfügung gestellt werden
können. Einen Teil dieser Aufgaben stellen Übungen dar, die wie Prozesse gestaltet sein
sollen. Da für die Erstellung von Übungsprozessen spezielles Fachwissen im Bereich
Prozessmodellierung nötig ist, soll ein neues Konzept entworfen werden, um diese kom-
plexe Aufgaben auch ohne diese Kenntnisse, erfüllen zu können. Dieses Konzept soll
konkret mit einem dafür geeigneten Konfigurationswerkzeug in die Plattform integriert
werden. Der realisierte webbasierte Prototyp soll im Anschluss anhand einer Studie
evaluiert werden, um herauszufinden in wie weit das entwickelte Konzept praktisch an-
wendbar wäre. Dabei sollen die Probanden sowohl bereits existierende Prozessmodelle
textuell beschreiben, als auch anhand dieser Beschreibungen Übungen mittels des
Konfigurationstools erstellen.
2
1.2 Aufbau der Arbeit
1.2 Aufbau der Arbeit
Zunächst werden die nötigen Grundlagen und Begrifflichkeiten (Kapitel 2) geklärt, die
für diese Arbeit nötig sind. Im Anschluss daran erfolgt eine Analyse von verwandten
Arbeiten (Kapitel 3). Alle nachfolgenden Kapitel befassen sich mit der Entwicklung und
Umsetzung des Prototypen. Vor Beginn des Entwicklungsprozesses werden zunächst
die dafür nötigen Anforderungen (Kapitel 4) definiert. Darauf folgen der Entwurf (Kapitel
5) der Anwendung, sowie deren Realisierung (Kapitel 6). Nach Abschluss der Planungs-
und Implementierungsarbeiten werden die zu vor definierten Anforderungen mit dem
umgesetzten Prototypen gegeneinander abgeglichen (Kapitel 7). Im Kapitel 8 wird die
Anwendbarkeit des erarbeiten Therapieplaners und dessen Komponenten anhand einer
Studie untersucht und die Ergebnisse ausgewertet. Im Anschluss daran werden diese
Studienergebnisse in einer Diskussion (Kapitel 9) erläutert. Den Abschluss dieser Arbeit
bilden eine Zusammenfassung des Projektes und einen Ausblick in die Zukunft (Kapitel
10). Die nachfolgende Abbildung 1.1 stellt den Aufbau dieser Arbeit nochmals grafisch
dar.
Abbildung 1.1: Übersicht - Aufbau der Arbeit
3
2
Grundlagen
In diesem Abschnitt soll auf die nötigen Grundlagen eingegangen werden. Dabei ste-
hen zunächst die allgemeinen Grundlagen für therapeutische Interventionen im Fokus.
Im Anschluss daran wird auf das grundlegende Konzept für den zu entwickelnden
Therapieplaner und dessen Bestandteile näher eingegangen.
2.1 Therapeutische Interventionen
Im Zusammenhang mit diesem Projekt sind als therapeutische Interventionen sämtliche
Formen professioneller psychologischer Unterstützung bei der Bewältigung vorwiegend
psychischer, aber auch sozialer und körperlicher Beeinträchtigungen und Störungen zu
verstehen. Klinisch-psychologische Interventionen umfassen also nicht nur Psychothera-
pien im engeren Sinne, sondern auch psychologische Beratung, Kriseninterventionen,
Selbsthilfe und Trainings. Gegenstand der Behandlung sind dabei eben auch körperliche
Beeinträchtigungen, sodass sich Überschneidungen mit der Gesundheitspsychologie
ergeben [DE07].
Aus informationstechnischer Sicht lässt sich eine therapeutische Intervention durch
folgende Abbildung 2.1 schematisch darstellen. Dabei soll der in diesem Projekt zu
erstellende Prototyp den Abschnitt der
IT Solution
am oberen Rand der Abbildung
abdecken und somit dem Therapeuten als Werkzeug für Interventionen dienen.
Um das Behandlungsszenario zu vervollständigen, müssen die geplanten Vorgänge dem
Patienten zugänglich gemacht werden. Hierfür sind wie Eingangs bereits beschrieben
mobile Endgeräte wie Smartphones geeignet. Mit der Wahl dieser Geräte eröffnet sich,
5
2 Grundlagen
zusätzlich zu den Interaktionsmöglichkeiten mit dem Teilnehmer, ein breites Feld an
Sensoren, die für therapeutische Zwecke genutzt werden können. Beispielsweise ließen
sich Bewegungsdaten oder auch die Herzfrequenz des Benutzers ermitteln. Diese Daten
können zum Einen als Erfolgskontrolle der eigentlichen Therapie genutzt werden. Zum
Anderen könnten diese Daten auch der Wissenschaft zugänglich gemacht werden, um
sie für Forschungszwecke zu verwenden. Ein weiterer Punkt ist die Adressierung von
Benachrichtigungen. Da sich mobile Endgeräte in der Regel in der Nähe des Patienten
befinden, kann dieser somit zum Beispiel an eine Hausaufgabe oder einen Termin
erinnert werden [SPS+17b, WPH+04, SPSR16].
Die Umsetzung der geplanten therapeutischen Interventionen auf Geräte in Form einer
Anwendung ist nicht mehr Bestandteil dieses Projektes.
Abbildung 2.1:
Schema - Therapeutische Intervention aus informationstechnischer Sicht-
weise [SPS+17b]
6
2.2 Therapieplanung
2.2 Therapieplanung
Für eine erfolgreiche und sachgerechte Therapie ist eine vorausschauende Planung des
konkreten Vorgehens notwendig. Dabei gilt es, die therapeutischen Optionen mit Hinblick
auf den aktuellen fachlichen Kenntnisstand zu Wirksamkeit und Sicherheit abzuwägen,
sowie patientenbezogene individuelle Faktoren einzubeziehen. Dies ermöglicht eine
transparente und verständliche Kommunikation mit dem Patienten in Hinblick auf die
geplante Therapie [
Woh14
]. Im konkreten Projekt soll für den prototypischen Planer
folgende Abbildung 2.2 den grundlegenden Aufbau beschreiben.
Generell sind für die Planung einer Therapie Präsenztermine nötig, um die Kommunikati-
on zwischen Therapeuten und Patienten zu verwalten. Als Beispiel können Vorabgesprä-
che, Sitzungen oder auch Anwendungen gesehen werden, bei denen die Anwesenheit
beider Parteien notwendig ist. Als weiteren Punkt stehen Hausaufgaben im Zentrum
dieses Planers. Diese bilden alle weiteren Inhalte, wie Benachrichtigungen, Übungen die
der Teilnehmer zu absolvieren hat, und Feedback an den Therapeuten, ab. Da gerade
komplexe Aufgaben planbar sein sollen, sind diese zweigeteilt. Die Hauptübung legt da-
bei den generellen Ablauf fest. Erst in den Detailübungen soll eine genaue Beschreibung
der einzelnen Abläufe erstellt werden können.
Abbildung 2.2: Übersicht - Genereller Aufbau eines Therapieplanes
7
2 Grundlagen
2.3 Hausaufgaben
Wie bereits in der Einleitung (siehe Kapitel 1) erwähnt, sollen für diese Plattform Haus-
aufgaben im Kontext von therapeutischen Interventionen umgesetzt werden. In diesem
Zusammenhang sind Hausaufgaben als eine Kombination von Benachrichtigungen an
den Patienten, einer oder mehrerer durchzuführenden Übungen und einer Rückmeldung
in Form von Feedbacks, zu verstehen. Damit bildet die Hausaufgabe die eigentliche
Schnittstelle zwischen der geplanten Therapie und dem Patienten, da mittels deren
Inhalte kommuniziert beziehungsweise interagiert wird.
Somit bildet die Hausaufgabe das zentrale Element einer Therapie, da anhand der
Übungen oder auch dem Feedback direkt auf den Patienten eingewirkt, oder durch
ihn beeinflussbar ist. Nachfolgend werden die einzelnen Elemente einer Hausaufgabe
nochmals näher beschrieben [SPS+17a, SPS+17c].
2.3.1 Übungen
Eine Übung bildet das Kernstück einer zuvor definierten Hausaufgabe. Generell ist eine
Übung immer in eine Hauptübung und verschiedene Teilübungen zu unterteilen. Die
übergeordnete Übung bildet den groben Verlauf der einzelnen zu erledigenden Aufgaben
ab. Zum Beispiel lässt sich ein Ausdauertraining in eine Aufwärmphase, einen Leistungs-
teil und eine Phase zum Auslaufen, einteilen. Diese Bereiche sollen danach genauer mit
detaillierten Teilübungen beschrieben werden. Als Beispiel könnte die Aufwärmphase
durch Laufen gefolgt von Dehnen spezifiziert werden. Die Komplexität lässt sich durch
das Anbieten von alternativen Aufgaben oder Aufgabenfolgen deutlich erhöhen. Im vor-
her genannten Beispiel würde die Aufwärmphase alternativ durch Schwimmen oder auch
Fahrradfahren anstatt von Laufen definiert. Für ein breiteres Anwendungsspektrum sorgt
die Möglichkeit nicht nur Aktionen beziehungsweise Handlungsanweisungen abzubilden,
sondern auch die Planbarkeit von Messungen während dieser Übungseinheiten. Diese
können wiederum alternativ oder parallel mit anderen Schritten kombiniert werden.
Die nachfolgende Abbildung 2.3 verdeutlicht den eben beschriebenen Aufbau noch-
mals. Hierbei ist neben der Aufteilung der Hausaufgabe in die drei Bereiche deutlich zu
8
2.3 Hausaufgaben
erkennen, wie eine Übung in die unterschiedlichen Ebenen eingeteilt wird. Neben der Auf-
teilung der Hauptübung in einen Part für Messungen und Aktivitäten erfolgt im Anschluss
die genauere Ausführung der jeweiligen Komponenten in Form von Detailübungen.
Abbildung 2.3: Schema - Aufteilung des Übungsprozesses [SPSR17a]
2.3.2 Benachrichtigungen
Einen weiteren grundlegenden Bestandteil von Hausaufgaben stellen Benachrichtigun-
gen an den Patienten dar. Um diese Benachrichtigungen schlussendlich anwenden zu
können, müsste die geplante Therapie für Patienten auf einem Smartphone oder Tablet
verfügbar sein. Diese Nachrichten könnten dann unter vorher definierten Bedingungen
zugestellt werden. Ein Beispielszenario:
Der Patient soll jeden Abend eine Entspan-
9
2 Grundlagen
nungsübung absolvieren.
Für diese Übung bekommt der Teilnehmer eine Erinnerung
an seine Aufgabe sobald er zu Hause ist, die Übung noch nicht gemacht wurde und
es bereits 20:00 Uhr ist. Somit können Benachrichtigungen an den jeweiligen Kontext
gebunden werden um bestmöglich auf den Teilnehmer einzuwirken. Im Beispiel wird
anhand der Position im Zusammenspiel mit der Uhrzeit eine Erinnerung erstellt. Mit
diesem Szenario wird deutlich wie man mit Hilfe von Sensorik in heutigen Mobilgerä-
ten Benachrichtigungen zur Unterstützung an den Patienten weitergeben kann. Mittels
Benachrichtigungen lassen sich Erinnerungen, Mitteilungen über Änderungen oder Neu-
igkeiten, aber auch Warnungen realisieren. Eine Warnung könnte beispielsweise bei
einer zu hohen Herzfrequenz während einer anstrengenden Übung ausgelöst werden
[SPSR17c].
2.3.3 Feedback
Den abschließenden Part bildet die Möglichkeit der Feedbacks. Diese dienen dazu um
Ergebnisse oder Informationen vom Teilnehmer an den Therapeuten zu übermitteln. Da-
her wirken sie genau umgekehrt im Vergleich zu den Benachrichtigungen, die Daten zum
Teilnehmer transportieren. Um diese Rückmeldungen zu verdeutlichen, lässt sich das
Beispiel aus 2.3.2 erweitern: Nach Abschluss der Entspannungsübung möchte der Arzt
gerne mehr über das Befinden des Patienten wissen. Dazu definiert er Fragen, die vom
Teilnehmer im Anschluss an seine Übung beantwortet werden sollen. Hierbei kann es
sich um Fragen mit offene Antworten, oder bereits vorgegebenen Auswahlmöglichkeiten
handeln.
10
3
Related Work
Dieses Kapitel befasst sich mit bereits bestehenden Ansätzen und Umsetzungen von
Therapieplanern beziehungsweise deren Konzepte. Dabei sollen die Möglichkeiten
und Vorzüge sowie Beschränkungen und auch Nachteile der betrachteten Plattformen
diskutiert werden.
3.1 SimpleSet
Die Plattform
SimpleSet
wurde von einer Gruppe kanadischer Physiotherapeuten entwi-
ckelt, um den Patienten eine bessere Hilfestellung bei Übungen und Hausaufgaben zu
geben. Bei dieser Plattform können Therapeuten ihre Übungen online oder per mobi-
ler Anwendung für den Patienten ausarbeiten. Diese Übungen sind mit Videomaterial
und Beschreibungen zur Ausführung ausgestattet und können im Anschluss an den
Patienten per Mail oder in gedruckter Form ausgehändigt werden. Die Plattform als
Anwendung steht auch dem Therapeuten bei der täglichen Arbeit mit den Patienten zur
Verfügung um Übungsabläufe besser erklären und veranschaulichen zu können [Sim].
Nachfolgend sind die Kernpunkte dieser Plattform angeführt:
•
Komplexer Konfigurator und eine große Datenbank mit Übungen zur Erstellung
von Übungseinheiten.
•Vielzahl an einstellbarer Parameter für einzelne Übungen
•
Möglichkeit Übungseinheiten als Vorlage abzuspeichern und mit anderen Thera-
peuten zu teilen.
11
3 Related Work
•
Die erstellten Hausaufgaben oder Übungseinheiten lassen sich wie ein Handout
gestalten und als Dokument speichern.
•Mailversand oder Druck der Übungsblätter für den Patienten.
Die nachfolgende Abbildung 3.1 zeigt den Aufbau des Konfigurators. Die Anzahl der
Einstellungsmöglichkeiten und verschiedenen Schaltflächen ist enorm. Im Beispiel wurde
nur eine einzige Übung ausgewählt und es stehen dort bereits neun Standardparameter
zur Verfügung um diese Aufgabe einzustellen. Somit lassen sich durch das Verschieben
der einzelnen Übungseinheiten von der Datenbankseite (links) in eine zusammengesetz-
te Übung (rechts) verschieben und einstellen. Zusätzlich ist es möglich ein Deckblatt wie
bei einem Handbuch anzufertigen.
Abbildung 3.1: Ausschnitt aus dem Übungskonfigurator von SimpleSet
Diese Plattform realisiert die Therapieplanung nur soweit, in dem es möglich ist unter zu
Hilfenahme des Konfigurators komplexe Übungen zu erstellen. Eine Möglichkeit, Übun-
gen in Anlehnung an Prozesse zu definieren und daraus ein Modell abzuleiten, existiert
hier nicht.
SimpleSet
legt den Fokus auf die Erstellung von Handouts und detailreiche
Übungen, wobei die mobile Anwendung nur dem Therapeuten an sich als Hilfsmittel an
12
3.2 Physitrack
die Hand gegeben wird. Es fehlen auch die Möglichkeiten zur Kommunikation (Benach-
richtigungen und Rückmeldungen in Form von Feedback) mit dem Fachpersonal, da
es keine Anwendung für Patienten gibt. Zusammenfassend ist der Übungskonfigurator
eine gute Möglichkeit facettenreiche und anspruchsvolle Aufgaben für die Patienten zu
erstellen. Jedoch fehlen wichtige Punkte, wie zum Beispiel Feedback um von einem
kompletten Therapieplaner sprechen zu können.
3.2 Physitrack
Die Plattform
Physitrack
verspricht eine umfassende Patientenbetreuung, indem auf
videobasierte Übungen, im Zusammenspiel mit mobilen Anwendungen, gesetzt wird. Die
Plattform erlaubt es einzelnen Therapeuten Übungspläne mit verschiedenen Übungen
zu erstellen, oder vordefinierte Pläne an die Bedürfnisse des Patienten anzupassen.
Darüber hinaus lassen sich die Sätze und Wiederholungen jeder Aufgabe einstellen.
Am Ende generiert die Plattform einen Zugangscode, der zum Beispiel per Mail an
den Patienten gesendet werden kann. Über die Plattform hinaus existiert eine mobile
Anwendung, die sich kostenfrei von den Patienten auf ihren Smartphones und Tabletts
installieren lässt. Nach der Eingabe des individuellen Zugangscodes der Therapie
bekommt der Teilnehmer alle Informationen und Anleitungen auf sein Endgerät und kann
mit seiner Therapie beginnen [Phy17].
Nachfolgend sind die wichtigsten Features dieser Plattform aufgeführt:
•
Möglichkeit die erstellte Therapie auf Smartphone, Tablet oder als Webversion für
den Patienten zugänglich zu machen.
•Übungen können individuell auf den Patienten zugeschnitten werden.
•
Die Möglichkeit von Erinnerungen zum Erledigen der Übungen ist mit der mobilen
Anwendung vom Patienten umsetzbar.
•
Nach dem Absolvieren der Übungen ist eine Kommentar- beziehungsweise Feed-
backfunktion vorhanden.
13
3 Related Work
•
Es kann die Einhaltung der Übungen und auch die Übungsergebnisse des Patien-
ten nachverfolgt werden.
•
Dem Therapeuten stehen die erhobenen Messdaten zu Analysezwecken zur
Verfügung.
Ein Feature dieser Plattform ist die dazugehörige mobile Anwendung, mit der der Patient
Zugriff auf seine Übungen und Hausaufgaben erhält. Abbildung 3.2 stellt die Benut-
zung der Anwendung schematisch dar. Dabei ergibt sich ein einfacher linearer Ablauf.
Zunächst stehen alle für den Patienten relevanten Übungen zur Auswahl. Darauf hin
kann eine einzelne Aufgabe gewählt werden, die im Anschluss durchgeführt wird. Dabei
stehen hier wiederum Videos als Anleitung zur Verfügung. Nach der Trainingseinheit
kann man die erreichten Leistungen protokollieren und seine Fortschritte betrachten.
Darüber hinaus existiert die Möglichkeit, Kontakt mit seinem Therapeuten aufzunehmen
und diverse Einstellungen vorzunehmen.
Der "Programm" Bereich zeigt
Ihnen die Übungen auf, die für
Sie ausgewählt wurden. Hier
können Sie die Durchführung
auswählen, indem Sie einfach
die entsprechende Übung
antippen.
Über die Schaltfläche
!"Zusätzliche Information" sind
weitere Informationen erreichbar.
Nach der Auswahl der Übung,
die Sie durchführen möchten,
können Sie sich das Video
anschauen. Dies wird Ihnen
helfen, die Übung korrekt
durchzuführen.
In dieser Auswahl wird Ihnen
angezeigt, wie oft Sie die Übung
durchführen sollten.
Wenn Sie die Übung
durchgeführt haben, klicken Sie
auf “Vollständig" oben rechts
auf der Anzeige.
Wählen Sie die Anzahl der
Wiederholungen und die Anzahl
der Durchgänge aus, die Sie
erfolgreich durchführen konnten,
indem Sie die Regler bewegen.
Sie können auch eine Nachricht
an Ihren medizinischen
Ansprechpartner schicken.
Am Ende werden Sie gebeten,
Ihr persönliches
Schmerzempfinden bzw. die
Schwierigkeit der Übung zu
beschreiben.
Die Schaltfläche !"Ergebnisse"
unten in der Anzeige zeigt Ihnen
direkt den Fortschritt und Ihr
Schmerzempfinden in Echtzeit.
Klicken Sie auf das
Balkendiagramm, um sich ihren
täglichen Fortschritt detailliert
anzeigen zu lassen.
Tippen Sie auf "Nachrichten" um
Ihren Ansprechpartner direkt zu
kontaktieren.
Ihr Ansprechpartner wird Ihnen
direkt antworten, um Ihnen zu
helfen, Ihre Übungen
fortzusetzen und dabei zu
bleiben.
Über die Schaltfläche
"Einstellungen" können Sie
Erinnerungsfunktionen aktivieren,
damit Sie Ihre Übungen
regelmäßig durchführen.
Klicken Sie auf "Videos auf
Gerät” um Übungs-Videos
herunterzuladen. Dies
ermöglicht Ihnen, die App offline
zu nutzen - das schont Ihr
Datenvolumen und lässt Sie
auch unterwegs immer gut
informiert sein.
Wie benutzt man PhysiApp?
Abbildung 3.2:
Beispiel - Wie benutzt man
PhysiApp
, die mobile Anwendung der
Phy-
sitrack-Plattform
14
3.3 TheRehablab
Die
Physitrack
-Plattform bietet einen ausführlichen Therapieplaner mit der Möglichkeit
anhand von Patientendaten individuelle Therapien zu realisieren. Durch die geschickte
Kombination von Weboberfläche für den Therapeuten und einer mobilen Anwendung
für den Patienten können alle nötigen Daten und Informationen einfach kommuniziert
werden. Zwar kann nicht mittels bestimmten Gegebenheiten an die Übungen erinnert
werden, jedoch lässt sich zumindest eine Benachrichtigung anhand der Uhrzeit in der
Anwendung bestimmen. Die Möglichkeit, nach erfüllen einer Übungsaufgabe eine Rück-
meldung geben zu können ist sehr gut umgesetzt. Abschließend lässt sich
Physitrack
als sehr gut umgesetzte Plattform beschreiben, die in Kombination mit der mobilen
Anwendung die genannten Vorteile mit sich bringt. Lediglich die prozessorientierte Ge-
staltung von Übungen wird nicht umgesetzt sondern alle Übungen stehen als Block zur
Verfügung der ohne Reihenfolge erledigt werden muss.
3.3 TheRehablab
Das
TheRehablab
bietet eine weitere Plattform zur Erstellung von Übungen und The-
rapieplänen. Der Fokus dieses Systems liegt bei der Erstellung von Plänen, die im
Anschluss an die Erstellung und Konfiguration an die Patienten über E-Mail oder in
ausgedruckter Form zur Verfügung gestellt werden können. Die erstellten Übungen und
Pläne können anhand vieler Vorlagen zusammengestellt und auch für spätere Therapien
innerhalb der Plattform hinterlegt werden [The].
Nachfolgend sind die Features und des TheRehablab zusammengestellt:
•
Bietet alle Vorteile einer Onlineplattform, wie keine Installation, volle Verfügbarkeit
und Plattformunabhängigkeit.
•
Großer Datenbestand an professionell gestalteten Übungen und kompletten Pro-
grammen, die bei Verwendung individuell gestaltet werden können.
•Druck oder Versand der erstellten Übungspläne, die mit eigenen Logos und Infor-
mationen ergänzbar sind.
•
Erstellung von eigenen Übungen und Layouts für optimale Trainingspläne sowie
von Trainingstagebücher.
15
3 Related Work
Die folgende Abbildung 3.3 zeigt einen Ausschnitt der Konfigurationsoberfläche. Dabei
können Übungen, Informationsblätter sowie vorgefertigte Übungsprogramme in der Da-
tenbank gesucht und die Ergebnisse je nach Zweck gefiltert werden. Diese Ergebnisse
lassen sich dann in die rechte Spalte übernehmen, um individuelle Pläne für die Pati-
enten zu erhalten. Wird ein Programm erstellt, gibt es noch die Möglichkeit zusätzliche
Informationen anzugeben, sowie Anpassungen am Berichtslayout vorzunehmen. Abge-
schlossen wird die Konfiguration mit dem Versand des resultierenden Plans oder dessen
Sicherung beziehungsweise Drucks.
Abbildung 3.3: Ausschnitt aus der TheRehablab Oberfläche
Wie bereits eingangs erwähnt, fokussiert diese Plattform das Erstellen von Handouts,
die im Anschluss dem Patienten auf unterschiedliche Arten zugänglich gemacht werden.
Dabei sind jedoch keinerlei interaktive Funktionen berücksichtigt worden, da mit der Zu-
stellung des Plans an den Patienten der Funktionsbereich des
TheRehablab
endet. Des
Weiteren sind nur linear ablaufende Pläne ohne alternative oder parallele Ausführungen
einzelner Übungen umsetzbar. Abschließend betrachtet stellt diese Plattform zwar eine
gute Möglichkeit dar, Therapieplanung in Form von Übungsblättern, Plänen und Trai-
ningstagebüchern umzusetzen. Es können jedoch die Vorteile einer Onlineplattform, wie
zum Beispiel der Austausch von Daten zwischen Patient und Therapeut nicht realisiert
werden. Somit dient diese Plattform nur als Werkzeug um Pläne zu erstellten, die dann
außerhalb dieser Plattform ihre Verwendung finden können.
16
4
Anforderungsanalyse
Dieses Kapitel befasst sich mit der Analyse von funktionalen sowie nicht funktionalen
Anforderungen. Zu Beginn des Projekts wurden alle nötigen Anforderungen in gemeinsa-
men Gesprächen mit den Beteiligten festgelegt. Dabei beschreiben die nicht funktionalen
Anforderungen jene Punkte, die mit der Benutzung der Software einher gehen. Die funk-
tionalen Anforderungen hingegen bilden den Funktionsumfang des Prototypen und sind
als essentiell anzusehen.
4.1 Nicht funktionale Anforderungen
Die nachfolgende Tabelle 4.1 beschreibt die nicht funktionalen Anforderungen für den
Prototypen.
Nr. Anforderung Beschreibung
I Einfachheit
Unter dieser Anforderung ist zu verstehen, dass dem späte-
ren Nutzer nur die nötigsten Informationen dargestellt wer-
den. Details und weiterführende Informationen müssen den-
noch auf Wunsch des Benutzers aufrufbar sein. Somit soll
die Plattform möglichst ohne Schulungsmaßnahmen und
lange Einweisungen vom Anwender nutzbar sein. Jedoch
müssen alle für die Benutzung relevanten Informationen und
Funktionalitäten gegeben sein.
17
4 Anforderungsanalyse
II Bedienbarkeit
Eine einfache Benutzerführung und ein strukturierter Auf-
bau der Anwendung soll für eine gute Bedienbarkeit sorgen.
Darüber hinaus sollen Hinweise zur Handhabung mit an-
geführt sein, um bei Unklarheiten die nötige Unterstützung
zu erhalten. Gerade bei dynamischen Oberflächen an de-
nen Bedienelemente nicht immer an der gleichen Position
zu finden sind, muss eine gute Bedienbarkeit gewährleistet
werden.
III Übersichtlichkeit
Es soll darauf geachtet werden, den Prototyp so zu gestal-
ten, dass die Benutzeroberflächen möglichst übersichtlich
und einfach gestaltet sind. Gerade bei komplexeren Schrit-
ten beziehungsweise Aufgaben sind überladene und unüber-
sichtliche Oberflächen hinderlich. Darüber hinaus sollten für
die grundsätzliche Funktion nicht benötigte Elemente oder
zusätzliche Informationen standardmäßig ausgeblendet und
nur bei Bedarf eingeblendet werden können.
IV Fehlertoleranz
Dieser Aspekt soll auf die Vermeidung von Fehleingaben
beziehungsweise auf die Beschränkung von Eingabemög-
lichkeiten abzielen. Dabei sollen inhaltlich falsche Angaben
oder auch das Fehlen von Angaben erkannt und der Be-
nutzer darauf aufmerksam gemacht werden. Als weitere
Maßnahme ist die Beschränkung von Wahlmöglichkeiten
auf vordefinierte Werte zu nennen, um Fehler zu vermei-
den. Zudem sollen Möglichkeiten in denen Benutzer Freitext
eingegeben kann soweit wie möglich vermieden und zum
Beispiel auf vordefinierte Auswahlfelder reduziert werden.
Tabelle 4.1: Nicht Funktionale Anforderungen
18
4.2 Funktionale Anforderungen
4.2 Funktionale Anforderungen
Diese Tabelle 4.2 gibt Aufschluss über die funktionalen Anforderungen, die als Voraus-
setzung für den Entwurf und die Realisierung zu erfüllen sind.
Nr. Anforderung Beschreibung
I
Erstellung einer
Therapie
Als Grundlage der nachfolgenden Anforderungen muss die
Erstellung einer Therapie möglich sein. Diese muss einen
Namen, einen zugeordneten Patienten und ein Anfangs-
sowie Enddatum beinhalten. Der Patient soll aus einer vor-
definierten Patientenliste wählbar sein. Es ist nicht nötig
eine Patientenverwaltung im Umfang dieses Projekts mit
abzubilden. Eine bestehende Therapie muss bearbeitet und
auch wieder gelöscht werden können.
II
Erstellen von
(Präsenz)-
Terminen
Innerhalb einer zuvor erstellten Therapie soll die Möglichkeit
bestehen Termine zu erstellen. Dabei sind eine Beschrei-
bung, ein Datum und eine Uhrzeit zwingend erforderlich.
Darüber hinaus soll die Möglichkeit bestehen einen Termin
zu wiederholbar zu machen. Folgende Wiederholungsmög-
lichkeiten sollen wählbar sein: täglich, alle zwei Tage, alle
drei Tage und ein wöchentlicher Rhythmus. Termine können
nach dem Erstellen bearbeitet und wieder entfernt werden.
19
4 Anforderungsanalyse
III
Erstellen von
Hausaufgaben
Eine Hausaufgabe soll wie ein Termin innerhalb einer The-
rapie erstellbar sein. Es müssen eine Beschreibung und
ein Datum festgelegt werden. Optional kann wiederum ei-
ne Wiederholung ermöglicht werden. Die Möglichkeiten die
zur Auswahl stehen sind identisch zu denen bei den eben
beschriebenen Terminen. Auch Hausaufgaben sollen nach-
träglich geändert werden können. Zudem muss eine Haus-
aufgabe nach Abschluss der Bearbeitung bestätigt werden
können. Nach diesem Schritt sollen die Bestandteile nicht
mehr durch den Anwender änderbar sein. Es muss jedoch
die Möglichkeit bestehen eine abgeschlossene Hausaufga-
be im Lesemodus zu begutachten.
IV
Erstellen von Be-
nachrichtigungen
Einen Bestandteil von Hausaufgaben stellen Benachrich-
tigungen dar, die ein Patient erhalten könnte. Für diese
Meldungen muss zunächst eine Nachricht an den Patien-
ten eingegeben werden. Im Anschluss daran ist ein Kontext
auszuwählen. Dieser kann zum Beispiel ein Ort oder be-
stimmte Zeit sein. Auf Grund dieser Auswahl ergibt sich der
einzugebende kontextbezogene Wert. Außerdem muss es
möglich sein Beziehungen zwischen den Benachrichtigun-
gen herzustellen. Auch hier soll das nachträgliche abändern
der Nachricht oder des Kontextes möglich sein.
V
Erstellen von
Feedbacks
Ein Feedback ist eine weitere Komponente die zu einer
Hausaufgabe gehört. Dabei soll es möglich sein, verschie-
dene Arten von Fragen zu definieren, die man einem Patien-
ten stellen könnte. Bei Fragen mit vordefinierten Antworten
sollen diese zusätzlich angegeben und bearbeitet werden
können. Dabei soll der Planer bei definierten Antworten die
Anzahl und den Umfang der Fragen selbst wählen können.
Zudem muss wählbar sein, ob nur eine Antwort oder auch
mehrere vom Patienten gewählt werden dürfen.
20
4.2 Funktionale Anforderungen
VI
Erstellen einer
Übung
Die Hauptkomponente einer Hausaufgaben ist die Übung
und der dazugehörige Prozess. Dabei soll zwischen der
Hauptübung und den dazugehörigen Detailübungen unter-
schieden werden. Hierbei soll ein Konfigurationsmechanis-
mus entwickelt werden, um einzelne Aktionen und Messun-
gen miteinander in Beziehung zu setzen und damit verschie-
denste Übungsszenarien erstellen zu können. Der Konfi-
gurator muss das Ändern, nachträgliche Einfügen, sowie
das Entfernen einzelner Aktionen innerhalb einer Übung
ermöglichen.
VII
Ableitung eines
Prozessmodells
Auf Grund der Übung und deren Konfiguration soll es mög-
lich sein ein Prozessmodell erstellen zu lassen. Dieses Mo-
del soll die erstellen Übungen und deren Bestandteile gra-
fisch darstellen. Dieses Prozessmodell soll einer gängigen
Notation folgen und die verschieden Elemente und deren
Beziehung zueinander kenntlich machen.
Tabelle 4.2: Funktionale Anforderungen
21
5
Entwurf
In diesem Kapitel wird näher auf den Entwurf der Anwendung eingegangen. Dabei steht
zum Einen die Ausarbeitung für eine Benutzeroberflächen- und zum Anderen die Erstel-
lung eines Datenbankkonzeptes im Fokus. Beim Entwurf der Oberflächen zur Bedienung
des Prototypen spielen die Überlegungen für den Übungskonfigurator die Hauptrolle, um
den Kern der Anwendung später bestmöglich umsetzten zu können. Bereits in dieser
frühen Phase des Projekts müssen die zuvor in der Anforderungsanalyse (Kapitel 4)
definierten Anforderungen in Betracht gezogen werden.
5.1 Benutzeroberfläche
Der Entwurf der Benutzeroberfläche ist neben dem generellen Aufbau in drei weitere
Bereiche eingeteilt. Dabei wird ein Bedienkonzept für den Prototypen im Allgemeinen
entwickelt und der Entwurf für den Übungskonfigurator näher besprochen. Zudem erfol-
gen noch die Überlegungen zur Entwicklung der Prozessmodelle, die am Ende einer
erstellten Übung durch den Konfigurator stehen sollen. Diese Teilbereiche werden in den
anschließenden Unterabschnitten detailliert beschrieben.
Der nachfolgende Entwurf 5.1 zeigt den generellen Aufbau der Anwendung. Grundsätz-
lich erfolgt die Navigation nicht über das linke Menü sondern diese ergibt sich durch das
aufrufen der inhaltlichen Komponenten. Dieser Bereich auf der linken Seite ist für die
Funktionen, die in den einzelnen Bereichen möglich sind, gedacht. Zum Beispiel lässt
sich eine spezifische Übung zunächst anhand der übergeordneten therapeutischen Inter-
vention und im Anschluss mit der damit verbundenen Hausaufgabe erreichen. Um alle
nötigen Informationen von unterschiedlichen Komponenten grafisch übersichtlich darstel-
23
5 Entwurf
len zu können, kommt eine Tabellenstruktur zum Einsatz. Anhand dieses Aufbaus ist es
möglich beispielsweise alle Termine nacheinander in einer Terminübersichtstabelle dar-
zustellen. Des Weiteren kann mit entsprechenden Verlinkungen jedes Element aus der
Tabellenzeile heraus aufgerufen oder auch bearbeitet werden. Um den Therapieverlauf
grafisch zu veranschaulichen enthält jede Therapieübersicht eine Verlaufsübersicht. In
dieser Übersicht sind alle zugehörigen Termine und Hausaufgaben in einer Art Zeitstrahl
dargestellt. Die Auswahl der entsprechenden Einträge und deren weitere Bearbeitung
ist auch aus dieser Übersicht heraus möglich.
Abbildung 5.1:
Grobentwurf Therapieplaner - Übersicht über eine spezifische Therapie
mit grafischer Übersicht, Terminen und Hausaufgaben
5.1.1 Bedienkonzept
Um eine einfache und einheitliche Bedienung der Plattform zu ermöglichen, soll bereits
in der Entwurfsphase des Projekts ein Bedienkonzept aufgestellt werden. Gerade im
Hinblick auf die nicht funktionalen Anforderungen und auf die komplette Benutzeroberflä-
24
5.1 Benutzeroberfläche
che sind nachfolgend jene Punkte beschrieben, die das Bedienkonzept des Prototypen
beschreiben:
•
Grundsätzlich sollen alle wichtigen Aktionen wie die Erstellung neuer Elemente und
Bearbeitung dieser über eine vertikale Menüleiste auf der linken Seite abgewickelt
werden. Diese Leiste soll je nach Funktionsumfang und -möglichkeiten an die
aktuelle Situation angepasst sein. Das bedeutet, es sollen nur jene Punkte zur
Auswahl stehen, die in der derzeitigen Situation relevant sind.
•
Alle Einträge in Tabellen und Listen sollen direkt aus der entsprechenden Zeile aus
aufrufbar sein. Somit ist in jeder tabellarischen Anordnung eine Aktionsspalte nötig
um zum Beispiel Details einblenden zu können oder in eine andere Ebene der
Anwendung zu gelangen. Es gibt keine Möglichkeiten Elemente zu markieren und
Aktionen auf Basis dieser Auswahl zu tätigen, da dies zusätzliche Bedienelemente
und eine Stapelverarbeitung von Elementen erfordern würde, die keine Anwendung
beziehungsweise Mehrwert brächten.
•
Kritische Schritte, wie zum Beispiel das Löschen von Elementen werden immer von
einer entsprechenden Warnung begleitet, um Bedienfehler zu minimieren. Diese
Warnungen sollen die gerade getätigte Aktion und die möglichen Konsequenzen
bei der Durchführung aufzeigen.
•
Für die elementaren Bereiche der Konfiguration der Hausaufgaben und Übungen
gibt es ein zusätzliches Aktionsmenü. Dieses wird bei allen nötigen Schritten
auf der linken Seite eingeblendet und nach dem Abschließen der Aktion auch
wieder ausgeblendet. Mit dieser Vorgehensweise sollen zu jedem Zeitpunkt nur
die nötigen Bedienelemente zur Verfügung stehen. Dieses Aktionsmenü enthält je
nach Anforderung der jeweiligen Aufgabe, Möglichkeiten zur Dateneingabe und
zur Konfiguration.
•
Schaltflächen oder Menüeinträge sind jeweils mit einem entsprechenden Icon
und einer Beschreibung gekennzeichnet, um die Bedienbarkeit zu erhöhen. Damit
wird die Sichtbarkeit der Schaltflächen erhöht und deutlich gemacht, dass alle so
gekennzeichneten Elemente zur Bedienung des Prototypen gedacht sind.
25
5 Entwurf
5.1.2 Übungskonfigurator
Dieser Teil der Plattform ist mit Abstand die größte Herausforderung im Entwurf und
in der späteren Umsetzung. Die Tatsache, dass die Erstellung von prozessorientierten
Übungen ohne die Kenntnisse von Prozessmodellierung möglich sein soll, führte zu
einer Vielzahl von Entwürfen und Konzepten. Folgende Punkte wurden beim erarbeiten
des finalen Entwurfes berücksichtigt:
•
Aufteilung in Haupt- und Subübungen um zunächst generelle Angaben machen
zu können, die im Anschluss daran konkretisiert darstellbar sind. Diese Bereiche
sollen in der späteren Umsetzung auch räumlich voneinander getrennt sein und
auch separate Prozessmodelle zur Folge haben.
•
Aktivitäten und Messungen werden verschiedenfarbig dargestellt, um dem Anwen-
der den Unterschied nicht nur anhand der Informationen und Funktionsmöglichkei-
ten, sondern auch grafisch deutlich zu machen.
•
Aktivitäten in der Hauptübung werden dann in die jeweiligen Teilaufgaben unter-
gliedert. Somit soll nach Abschluss einer Konfiguration jedes Aktivitätsobjekt aus
der Hauptübung über einen eigens gestalteten Detailübungsablauf verfügen.
•
Zusammenhänge werden immer unterhalb in einer Zeile dargestellt und können
eine UND-Funktion und eine ODER-Funktion ausüben. Durch diesen Aufbau soll
die Konfiguration den jeweiligen Zeilen folgen und eine neue Zeile unterhalb eines
Elements den neu erstellten Pfad darstellen. Dieses Vorgehen ermöglicht zudem
komplexe Gestaltungsmöglichkeiten in die Tiefe, die mit neuen Zeilen umgesetzt
wird.
Die nachfolgende Abbildung 5.2 veranschaulicht die oben beschriebenen Punkte noch-
mal grafisch. Die Hauptübung soll immer zunächst mit aufeinanderfolgenden Aktivitäten
erstellt werden. Dabei ist diesem Abschnitt genau eine Verzweigung möglich. Diese
kann, wie bereits erwähnt, zusammenhängend oder alternativ gestaltet werden. Ab-
schließend ist es dann möglich anhand der zuvor getroffenen Entscheidung, Messungen
zu diesen Hauptaktivitäten hinzuzufügen. Somit entsteht in diesem Abschnitt immer ein
lineares und eindimensionales Vorgehen von Übungsbauteilen, die nur von Messun-
26
5.1 Benutzeroberfläche
gen angereichert werden können. Die Möglichkeit alternative oder zusammengehörige
Aktivitäten zu definieren obliegt den Bereichen für die Detailübungen. Damit sind die
Konfigurationsmöglichkeiten, abgesehen von Bearbeitungsfunktionen, in diesem Bereich
ausgeschöpft.
In den Subübungen soll der Freiheitsgrad der Konfiguration deutlich erweitert sein.
Daher ist es möglich dort Kombinationen von Aktivitäten, Zusammenhänge und Mes-
sungen zu den jeweiligen Übungsvorhaben zu konfigurieren. Dabei lassen sich auch
Verschachtelungen der Zusammenhänge erzeugen und die im Hauptbereich getroffenen
Einschränkungen umsetzen. Eine Übung soll als komplett konfiguriert gelten, sobald zu
jeder Aktivität in einer Hauptübung der entsprechende Detailbereich erstellt ist.
Abbildung 5.2: Entwurf - Übungskonfigurator
27
5 Entwurf
5.1.3 Prozessmodell
Am Ende der Erstellungs- und Konfigurationsprozesses einer Übung innerhalb einer
Hausaufgabe soll die Möglichkeit bestehen, ein Prozessmodell davon zu erhalten. Der
nachfolgende Abschnitt 5.2 legt den Grundstein zur Umsetzung dieser Anforderung.
Dabei sind alle Beziehungen der einzelnen Elemente zu ihren Nachbarn in der Da-
tenbank festzuhalten. Mit diesen Informationen lässt sich ein solches Modell abbilden,
da die Verbindung zu den jeweiligen Elementen auf Grund der Datenbaisis bekannt
ist. Die Prozessmodelle sollen in Anlehnung an BPMN 2.0 erstellt werden [
Gro
]. Für
die Darstellung und Umsetzung der Prozessmodelle ist ein geeignetes Vorgehen zu
implementieren, um die zugrunde liegende Datenstruktur auf die Anforderungen der
nachfolgend definierten Anforderungen an die Modelle, dementsprechend anwenden zu
können.
Dabei sollen folgende Punkte Beachtung finden. Diese sind auch im Rahmen der BPMN-
Spezifikation für solche Modelle vorgegeben [Gro11]:
•
Ein Prozess hat immer ein Start- und Endevent. Dabei hat ein Startelement keine
Vorgänger und ein Endelement keinen Nachfolger mehr.
•
Alle Pfade beginnen am Start und verlaufen so, dass sie im Endevent münden. Es
dürfen keine Pfade existieren, die nicht zum Ende gelangen und somit mehrere
oder nicht vollständige Resultate möglich sind.
•
Gateways ermöglichen die Kontrolle des Prozessablaufes. Für dieses Projekt sind
diese auf
AND
und
OR
Möglichkeiten beschränkt. Ersteres ermöglicht das parallele
Ausführen von mehreren Aktivitäten. Der zweite Typ ermöglicht die Umsetzung
von alternativen Ausführungsmöglichkeiten (exklusives ODER).
•
Gateways treten immer paarweise auf. Das bedeutet es wird zunächst ein öff-
nendes Element gefolgt von mehreren Aktivitäten erstellt, bevor ein Schließendes
den Ablauf beendet. Diese Vorgabe bedeutet jedoch nicht, dass ein Gateway
innerhalb eines bereits Existierenden möglich ist. Abschließend müssen jedoch
alle öffnenden Elemente wieder geschlossen sein.
28
5.2 Datenbankschema
5.2 Datenbankschema
Das Datenbankschema bildet die nötigen Datenstrukturen in einer relationalen Daten-
bank ab. Im Entwurf stehen vor allem die einzelnen Datenfelder sowie Tabellen und
deren Beziehung untereinander im Fokus. In diesem Schritt sind noch keine expliziten
Datentypen für die jeweiligen Felder aufgeführt. Die nachfolgende Abbildung 5.3 stellt
den Entwurf des Schemas dar. Die jeweiligen Tabellen verfügen immer über ein ein-
deutiges Schlüsselattribut. Dies wird in der Darstellung durch die
id
gekennzeichnet.
Die Verbindung unter den Tabellen wird über sogenannte Fremdschlüsselbeziehungen
realisiert [
Sch13
]. Die einzelnen Schlüsselattribute sind unterstrichen markiert, wobei
die primären Schlüssel fett hervorgehoben sind.
Abbildung 5.3: Entwurf - Datenbankkonzept
Den Ausgangspunkt für die Datenbankstruktur bildet die Tabelle
interventions
. Dort befin-
den sich alle notwendigen Attribute um eine therapeutische Intervention zu beschreiben.
Wichtig dabei sind Anfangs- und Enddatum, um einer Therapie einen zeitlich definierten
Rahmen zu geben. Um im weiteren Verlauf eine Intervention einem Therapeuten zuord-
nen zu können, wird dieser noch zusätzlich mit seiner user_id aufgenommen.
29
5 Entwurf
Auf der nächsten Ebene (siehe Abbildung 2.2) stehen die Tabellen
homeworks
und
meetings
. Erstere hält alle Informationen um eine Termin abbilden zu können. Dabei
wird auf die übergeordnete Intervention verwiesen. Die Tabelle
homeworks
ist der Aus-
gangspunkt für alle weiteren Datentabellen und enthält alle Eigenschaften, mit der sich
eine Hausaufgabe beschreiben lässt. Beide eben genannten Entitäten verfügen über
das das Attribut
repetition
, welches einen einfachen Mechanismus darstellt, um spä-
ter Wiederholungen im Planer zu realisieren. Um Feedbacks in eine Hausaufgabe zu
integrieren, sind die beiden Tabellen
feedbacks_q
und
feedback_a
nötig. Dort werden
zum Einen die Fragen und der der Typ der Antwort abgebildet. Zum Anderen finden die
möglichen Antworten in der zweiten Tabelle ihren Platz. Hierbei kommen wie bereits
erwähnt, Fremdschlüssel zur Anwendung, um die Beziehung abbilden zu können..
Ähnlich dazu ist der Bereich der Benachrichtigen konzipiert. In der Entität
notifications
wird die eigentliche Nachricht gehalten. Um die Versandbedingungen zu verwirklichen ist
die Tabelle
notifications_constrains
nötig. Dort sind die Bedingungen und das Verhalten
zum Vorgänger (Feld connection) festgehalten.
Für die Abbildung der komplexen Übungen sind die Tabellen
exercises
,
exercise_elements
und
exercise_element_connections
nötig. In der Haupttabelle wird vorab der Bezug zur
übergeordneten Hausaufgabe hergestellt. Das Attribut
sub_process
gibt an, ob es sich
um eine Hauptübung oder eine Detailübung handelt. Im Falle einer Detailaufgabe,
wird im Feld
main_exercise_id
zur Erkennung der Hauptübung, festgehalten. Zur da-
tentechnischen Beschreibung eines Übungselements sind alle Attribute dazu in der
exercise_elements
-Relation abgebildet. Es wird Benennung und Art des Elements,
sowie dessen Position im Konfigurator gespeichert. Abschließend müssen noch die
Beziehungen der einzelnen Übungsbestandteile realisiert werden. Dazu hält die Ta-
belle
exercise_elements_connections
zu jedem Element den logischen Vorgänger und
Nachfolger im Prozess. Für Anfangs- und Endelemente ist jeweils nur eine Verbindung
nötig.
Dieser Entwurf wird in den nächsten Phasen des Projekts mit den entsprechenden
Datentypen versehen und innerhalb einer konkreten Datenbankinstanz umgesetzt. Dabei
müssen auf die datenbankspezifischen Umsetzungen, gerade im Bereich der Primär-
und Fremdschlüssel, Rücksicht genommen werden.
30
6
Realisierung
In diesem Kapitel wird auf die Umsetzung der Entwürfe unter Beachtung der zuvor
gestellten Anforderungen näher eingegangen. Grundlage für den Realisierungsprozess
ist die Schaffung der nötigen Gegebenheiten anhand der Architektur der Plattform. Im
Anschluss daran erfolgt die Umsetzung der entworfenen Benutzerschnittstelle und die
Realisierung des Konfigurators, der die Hauptrolle dieses Projektes einnimmt. Um die
Darstellung der erstellten Übungen auch als Prozessmodell abbilden zu können, ist die
Entwicklung eines Generators erforderlich.
6.1 Architektur
Die Architektur des kompletten Projektes und weiterführender Möglichkeiten wird in Ab-
bildung 6.1 grafisch dargestellt. Dabei sind die grauen Bereiche nicht mehr Bestandteil
dieser Arbeit. Sie sollen dennoch aufzeigen was darüber hinaus noch möglich wäre,
wenn diese Plattform dem Patienten praktisch zur Verfügung stünde und eine Anwen-
dung für ein mobiles Endgerät auf Basis der Plattform realisiert werden würde. Dafür
könnten die auf der Basis von Übungen genierten Prozessmodelle als Schnittstelle oder
Datenquelle für eine mobile Anwendung für Patienten, dienen.
Generell teilt sich das Projekt in eine Serverseite und in den dazugehörigen Clientbereich,
auf. Die
Albatros
-Plattform wird als Webanwendung realisiert, die auf einem dazugehöri-
gen Webserver ausgerollt wird. Dort werden sowohl die Views und die Anwendunslogik
gehalten, die dem Client auf Abruf zur Vefügung gestellt wird. Zur Datenhaltung kommt
eine relationale Datenbank, auf die von der Anwendung serverseitig zugegriffen wird,
31
6 Realisierung
zum Einsatz. Konkret wird der Prototyp auf einem
Apache
Webserver [
Apa
] in Verbin-
dung mit einer
MySQL
Datenbank [
MyS
], realisiert. Die Umsetzung dieser einzelnen
Teilereiche ist in den nachfolgenden Unterpunkten nochmals näher ausgeführt.
Abbildung 6.1: Architekturkonzept der Albatros-Plattform
6.1.1 Client
Da es sich um eine Webanwendung handelt reicht als Client ein normaler Webbrowser
aus, um die Anwendung nutzen zu können. Alle nötigen Informationen und Daten werden
vom Server zur Verfügung gestellt. Dabei wird das HTTP-Protokoll zur Kommunikation
verwendet [
RF14
]. Mittels dieses Protokolls werden alle nötigen Skripte (HTML und
JavaScript) heruntergeladen und im Browser dargestellt.
32
6.1 Architektur
Die Kommunikation zum Server wird mit zwei verschiedenen Vorgehensweisen umge-
setzt. Zum Einen werden alle Formularinhalte wie zum Beispiel die Angaben zu einer
Therapie mittels der Standardmethoden des HTTP-Protokolls (GET und POST) an den
Server gesendet beziehungsweise vom Server empfangen. Zum Zweiten werden dyna-
mische Inhalte und Prozesse über sogenanntes
AJAX
umgesetzt. Der Vorteil dieses
Konzeptes besteht darin, dass der Client Daten an den Server übermitteln und auch vom
Server zurück erhalten kann, ohne dass komplette Webseiten erneut geladen werden
müssen [
AJA
]. Da gerade das Erstellen von Aktionen und Messungen im Übungsbe-
reich sehr viele Interaktionen mit nur wenig Daten erfordert, ergibt diese Methode eine
verbesserte Performanz gegenüber den HTTP-Methoden.
6.1.2 Server
Auf der Serverseite kommt PHP als Programmiersprache zur Anwendung [
PHP
]. Zur
Unterstützung bei der Umsetzung wird ein schlankes Framework namens
UserSpice
hinzugezogen [
Use
]. Mit dessen Hilfe wird die Entwicklungsarbeit erleichtert und die
Grundstruktur für des Projekt festgelegt. Auf Grund des Umfangs dieses Projektes kann
auf größere und weit aus mächtigere Frameworks verzichtet werden, da diese einen
höheren Einarbeitungsaufwand, komplexere Konfigurationen und einen hohen Anteil an
nicht benötigen Funktionen mit sich brächten. Aus diesen Gründen fiel die Wahl auf das
UserSpice-Framework, welches open source verwendbar ist.
Nachfolgende Übersicht zeigt die Vorteile des
UserSpice
-Frameworks auf, die im An-
schluss nochmals näher ausgeführt werden:
•Benutzerverwaltung mit Rollen- und Zugriffskonzept.
•Benutzeraccounts mit Login- und Sitzungskonzept
•Standardmethoden für den Datenbankzugriff
•Einheitliches Konzept zur Seitengestaltung
•Hoher Freiheitsgrad bei der Entwicklung
Die Benutzerverwaltung ermöglicht es unterschiedliche Benutzer für die Plattform zu
definieren. Dabei wird vor allem ein administrativer Zugang für die Entwicklungsarbeiten
33
6 Realisierung
und Verwaltungsaufgaben eingesetzt. Da keine Patientenverwaltung im Rahmen dieses
Projektes realisiert wird, lassen sich im Zuge der Benutzerverwaltung Patientenbenutzer
mit einer entsprechenden Benutzerrolle hinzufügen. In Hinblick auf die nachfolgende
Studie ist es zudem möglich Zugänge und Rollen für Probanden zu verwirklichen.
Die Tatsache der Benutzerverwaltung führt darüber hinaus zu einem Login- und Sit-
zungskonzept. Da nicht alle Teilnehmer die gleichen Möglichkeiten haben sollen, muss
auf Grund der Rollen und Berechtigungen entsprechend eingeschränkt werden. Die
Differenzierung findet dabei über die angesprochenen Sitzungen statt.
Ein wichtiger und zeitsparender Aspekt sind vorgefertigte Methoden für den Datenbank-
zugriff. Damit existieren global verfügbare und einheitliche Methoden zur Interaktion mit
der Datenbank. Diese Funktionen lassen sich im Realisierungsprozess auf die jeweils
benötigen Anforderungen erweitern oder auch abändern.
Um die Benutzerschnittstelle umsetzten zu können, erleichtert ein einheitliches Kon-
zept für die Seitengestaltung dieses Vorhaben. Dabei sind alle Seiten strukturgleich
aufgebaut und die entsprechenden Codezeilen können an den dafür vorgesehenen
Stellen implementiert werden. Somit ist eine gute Lesbarkeit des Quellcodes während
der Entwicklung und ein einheitlicher Aufbau gegeben.
Das
UserSpice
-Framework bietet neben den vorgestellten Vorteilen und Funktionalitäten
auch einen hohen Freiheitsgrad bei der Entwicklung. Auf Grund der Tatsache, dass
lediglich Hilfsmittel bei der Projektumsetzung zur Verfügung stehen, kann die Anwen-
dungslogik ohne Einschränkungen genau auf die Bedürfnisse für das Projekt angepasst
und auch umgesetzt werden.
Nach der Installation und Konfiguration des Frameworks auf dem Server kann direkt auf
die zuvor genannten Vorteile zurückgegriffen werden. Im Anschluss daran beginnt die
eigentliche Implementierung des Prototypen.
6.1.3 Datenbank
Wie bereits im Abschnitt 6.1 erwähnt, ist für die Umsetzung eine
MySQL
Datenbank
zur Datenhaltung in Verwendung. Dabei wurde das in Kapitel 5 entworfene Datenbank-
konzept wie geplant umgesetzt. Darüber hinaus sind für die nachfolgende Studie noch
34
6.2 UI-Entwicklung
ergänzende Felder zu Auswertungszwecken eingefügt worden. Die Tabelle
homeworks
erhält in diesem Zusammenhang Felder um den Beginn, sowie das Ende der Bearbei-
tung einer Hausaufgabe festzuhalten. Darüber hinaus wird in dieser Tabelle noch die
Anzahl der Aufrufe des generierten Prozessmodells zu Studienzwecken mitprotokolliert.
Um sicher zu stellen, dass die Vergabe der entsprechenden Primärschlüssel ohne
Einfluss durch die Anwendung statt findet werden diese automatisiert vergeben, indem
der nachfolgende Wert jeweils inkrementiert wird. Somit sind Konflikte um mehrfach
vergebene Identifizierungen ausgeschlossen und die Datenbank übernimmt die Vergabe.
Zudem sind die Fremdschlüsselbeziehungen wie im Entwurf realisiert worden. Dadurch
sind die Beziehungen unter den einzelnen Entitäten abgebildet.
Durch das Einführen der Fremdschlüssel ist es möglich seitens der Datenbank noch
kaskadierendes Löschen umzusetzen [
Sch13
]. Sollte zum Beispiel eine komplette Inter-
vention wieder aus dem Planer entfernt werden, wären eine Vielzahl von Löschoperatio-
nen nötig und es müsste sichergestellt sein, dass alle zugehörigen Elemente Beachtung
finden. Dies verringert zum Einen den Aufwand auf der Programmseite deutlich und
stellt zum Anderen sicher, dass keine Datenrückstände in der Datenbank zurück bleiben.
6.2 UI-Entwicklung
Durch die Verwendung des
UserSpice
-Frameworks sind bereits notwendige Seiten-
elemente, wie beispielsweise Navigation oder Administration, sowie ein einheitliches
Design vorhanden. Dadurch gelingt es durch Anpassen der einzelnen Bereiche die im
Entwurf geplante Benutzeroberfläche zu realisieren. Das Bedienkonzept (siehe Abschnitt
5.1.1) aus dem Entwurf ist wie beschrieben realisiert und an das gewählte Grunddesign
angepasst.
Neben der Umsetzung des Übungskonfigurators war die grafische Darstellung des
Therapieverlaufs eine weitere Herausforderung. Die Tatsache, dass jede Therapie unter-
schiedliche Anfangs- sowie Endtermine hat und auch jeweils verschieden in der Dauer
sind, muss beachtet werden. Dies hat zur Folge, dass ein komplett dynamischer Verlauf
generiert wird, bei dem jedes Element mit Termin- oder Hausaufgabendaten ange-
35
6 Realisierung
reichert wird, falls zu diesem Tag ein entsprechendes Ereignis existiert. Wie schon in
anderen Bereichen sind wiederum Icons zur Darstellung verwendet worden, um unnötige
Texte auf Grund des beschränkten Platzes weglassen zu können. Gestalterisch wurde
auf die bereits in anderen Bereichen verwendeten Farben und Icons zurückgegriffen,
um das Erscheinungsbild des Prototypen einheitlich wirken zu lassen.
Ergänzend zur eigentlichen Benutzeroberfläche wurde noch ein Logo für den Prototypen
entworfen, um das Erscheinungsbild abzurunden und die
Albatros
-Plattform grafisch zu
vervollständigen.
6.3 Übungskonfigurator
In diesem Abschnitt soll näher auf das Kernstück des Prototypen, dem Konfigurator
für Übungen, eingegangen werden. Die nachfolgende Abbildung 6.2 zeigt vorab ein
Beispiel des umgesetzten Übungskonfigurators. In den nachfolgenden Teilbereichen wird
zunächst der Aufbau und die Funktionen dieses Tools näher beschrieben. Im Anschluss
daran folgen die Möglichkeiten und auch die Einschränkungen, die dieser Konfigurator
aufweist.
Das Beispiel aus Abbildung 6.2 stellt eine komplett konfigurierte Hauptübung und die da-
zugehörige Detailübung aus dem Punkt
Stärkung
, dar. Die in den einzelnen Elementen
abgebildeten Symbole bieten Einstellungsmöglichkeiten, sowie auch Lösch- und Erstel-
lungsfunktionen für ausgediente beziehungsweise zukünftige Bestandteile. Die erstellten
Pfade sind im Beispiel mit türkisen Balken gekennzeichnet und verbinden jeweils das
darüber liegende Element mit dem direkt Folgenden. Alternativen sind mit einem
X
, wel-
ches für
ODER
steht gekennzeichnet. Den Gegenpart bilden die zusammengehörigen
Pfade, die mit einem +gekennzeichnet sind, und ein UND symbolisieren.
36
6.3 Übungskonfigurator
Abbildung 6.2: Beispiel einer Übung mit dazugehöriger Detailübung
6.3.1 Aufbau
Der Aufbau des Tools ist in zwei Hauptbereiche aufgeteilt. Der Erste Abschnitt stellt den
Arbeitsbereich für die Hauptübung dar. Dort können in der oberen Zeile Aktionen dieser
Übung definiert werden. Die zweite Zeile bietet die Möglichkeit einen weiteren Pfad
einzufügen, der entweder parallel zu den Aktionen oder alternativ dazu gewählt werden
kann. In der dritten und letzten Zeile des Arbeitsbereichs können noch Messungen
definiert werden.
Wie in der Anforderungsanalyse (Abschnitt 4.2) definiert soll zu jeder Hauptübung eine
entsprechende Detailübung erstellbar sein. Dies wird durch den zweiten Hauptbereich
umgesetzt. Dort lässt sich je nach gewählter Aktion aus der Hauptübung eine dazugehö-
rige Detailaufgabe definieren. Anhand des
Ausrufezeichen
oder des
grünen Häkchens
37
6 Realisierung
lässt sich aus der Hauptübung heraus ablesen, ob bereits eine Detailübung konfigu-
riert ist. Eine Übung gilt als vollständig, sobald alle Aktionen aus der Hauptübung mit
jeweiligen Detailübungen ausgestattet sind.
Das Farbkonzept wurde einfach gehalten und die Oberfläche kommt mit nur drei farbli-
chen Komponenten aus. Alle Aktionen, die den Großteil ausmachen, sind im gleichen
blau gehalten wie das umgebende Oberflächendesign. Die Messungen sind gelb dar-
gestellt um sich optisch möglichst gut von den Aktionen abzuheben. Die Verbindungen
von Pfaden sind in einem Türkiston gehalten. Um die Aktionselemente zum hinzufü-
gen neuer Komponenten vom bereits konfigurierten Prozess deutlich abzuheben sind
diese auffallend orange gestaltet. Alle Komponenten verfügen an die entsprechenden
Möglichkeiten angepasste innere Aktionsflächen um beispielsweise eine nachträgliche
Bearbeitung zu ermöglichen, oder den Status des Elements abbilden zu können.
6.3.2 Funktionen
Der Funktionsumfang des Konfigurators wird in der nachfolgenden Auflistung näher
beschrieben. Dabei handelt es sich um die Grundfunktionen, die für den Umgang
unbedingt notwendig sind.
•
Erstellung eines Übungselements mit dazugehörigem Namen. Dabei kann zwi-
schen einer Aktion und einer Messung gewählt werden. Diese Auswahl erfolgt im
entsprechenden Aktionsmenü bei der Erstellung eines Elements.
•
Erstellung von alternativen oder zusammenhängenden Pfaden. Dies kann dazu
verwendet werden, um Abläufe zu modellieren bei denen gleichzeitig mehrere
Aktivitäten möglich sind. Es ist auch möglich Prozesse zu definieren, die eine
alternative Auswahl von Aktionen für einen Patienten ermöglicht.
•
Nachträgliche Konfigurationsmöglichkeiten bei allen Elementen. Damit lassen
sich Änderungen an Beschreibungen oder dem Verhalten einzelner Elemente
nach deren Erstellung im Nachgang anpassen. Darüber hinaus können einzelne
Elemente auch wieder aus dem existierenden Ablauf entfernt werden.
38
6.3 Übungskonfigurator
•
Elemente können sowohl an das Ende eines Pfades oder Zweiges gesetzt werden,
als auch nach existierenden Punkten. Diese Möglichkeit sorgt für eine größere Fle-
xibilität bei der Konfiguration und ermöglicht es vergessene Elemente nachträglich
noch in eine bestehende Konfiguration einzufügen.
Anhand dieser Funktionen ist es möglich einfache und auch komplexe Abläufe zu erstel-
len. Gerade die Änderungs- und Löschfunktionen helfen bei nachträglichen Korrekturen
oder abgewandelten Anforderungen durch den Ersteller.
6.3.3 Möglichkeiten
Der Übungskonfigurator bietet die Möglichkeit, Übungen von geringer Größe, hin bis
zum Teil sehr komplexen Aufgaben zu erstellen. Dabei ist es dem Ersteller frei gestellt, in
welchem Umfang zunächst die Hauptübung erstellt wird. Lediglich die Anforderung, zu
jedem Oberpunkt eine entsprechende Detailaufgabe zu modellieren, wird vorausgesetzt.
Die folgende Aufzählung gibt einen Überblick über Möglichkeiten, die neben den bereits
beschriebenen Funktionen, bei der Verwendung des Konfigurators bestehen:
•Schachtelung von Pfaden um komplexe Prozessmodelle entwickeln zu können.
•
Die Aufteilung der Übung in Haupt- und Detailbereich bieten auch bei größeren
Modellen eine bessere Übersichtlichkeit.
•
Kontrolle der Konfiguration durch die Betrachtung des dynamisch generierten
resultierenden Prozessmodells.
Gerade die Möglichkeit zur Schachtelung von Pfaden eröffnet eine weite Bandbreite an
komplexen Modellen. Da diese Möglichkeit nicht weiter begrenzt ist, können theoretisch
beliebig tiefe und somit auch komplexe Konfigurationen erstellt werden. Prozessmodelle
die jeder Zeit während der Konfiguration einsehbar sind, bieten zusätzliches Potential.
39
6 Realisierung
6.3.4 Einschränkungen
Die nachfolgende Auflistung gibt genauere Aufschlüsse über Einschränkungen des
Konfigurators. Diese Limitationen sind teilweise technisch bedingt, oder in Absprache
mit den Betreuern festgelegt worden.
•
Grundsätzlich ist der Umfang in einem Pfad auf fünf Elemente beschränkt. Die-
se Einschränkung ist auf darstellungstechnische sowie auf Komplexitätsgründe
zurückzuführen.
•
Die Hauptübung lässt nur zwei Pfade zu. Der Erste darf nur Aktionen enthalten
und alle weiteren Teile müssten in diesem Fall dann in die jeweiligen in die Detail-
übungen einfließen. Der Zweite Pfad ist ausschließlich für Messungen vorbehalten,
die sich entweder parallel oder alternativ zum obigen Pfad definieren lassen.
•
Es ist nicht möglich Schleifen zu konfigurieren. Zum Beispiel soll der Patient die
selbe Aktion immer dreimal hintereinander ausführen. Dies kann nur iterativ gelöst
werden, indem die gleiche Aktion dementsprechend oft hintereinander eingefügt
wird.
•
Die Auswahl für einen alternativen Pfad ist stellt ein
exklusives Oder
dar. Somit ist
es nur möglich einen der vorgegebenen Pfade zu wählen und nicht mehrere.
•
Alle Verzweigungen haben immer zwei Pfade. Diese Pfade können wiederum
weitere Verzweigungen enthalten, jedoch bleibt die Anzahl dieser auch bei Zwei.
Abschließend betrachtet erlauben die Beschränkungen dennoch eine sehr komplexe
und auch freie Übungsgestaltung. Durch die Möglichkeit der Unterteilung der Übungen in
Haupt- und Detailübung sowie die Verschachtlung von Pfaden sind für diese Komplexität
verantwortlich. Gerade für Anwender, die kein Fachwissen über Prozessmodellierung
haben, sind die Beschränkungen auch teilweise eine Hilfe um Übungsvorhaben gezielter
umsetzen zu können, wenn nicht alle Freiheiten gegeben sind.
40
6.4 Prozessmodellgenerator
6.4 Prozessmodellgenerator
Um aus den konfigurierten Übungen ein Prozessmodell ableiten zu können, ist neben
einer geeigneten Datenstruktur eine grafische Darstellung wichtig. Diese Darstellung
ist mit dem
Mermaid
-Framework [
Mer
] realisiert, welches eine eigene Eingabesyntax
benötigt, um ein Prozessmodell grafisch darzustellen.
Die nachfolgende Grafik 6.3 zeigt ein Beispiel einer zuvor erstellten Übung anhand des
generierten Prozessmodells. Dabei ist eine Hauptübung (Hauptprozessmodell) und eine
Detailübung (Subprozessmodell) dieser Konfiguration exemplarisch abgebildet. Diese
Modelle entsprechen der bereits zuvor abgebildeten Beispielkonfiguration (Abbildung
6.2).
Abbildung 6.3: Beispiel eines Prozessmodells
Zunächst soll der Aufbau des Prozessmodellgenerators näher betrachtet werden. Im
Anschluss daran wird das Datenkonzept und die generierten Ein- und Ausgaben des
Frameworks beschrieben.
41
6 Realisierung
6.4.1 Aufbau
Grundsätzlich folgt der Generator einem simplen Aufbau, der zunächst immer das Pro-
zessmodell der Hauptübung erstellt. Anhand dieses Modells werden dann Schritt für
Schritt die einzelnen Detailmodelle jeder vorhandenen Detailübung generiert.
Der Aufbau eines einzelnen Modells hält sich an die im Kapitel 5.1.3 definierten Eigen-
schaften, die ein Prozessmodell aufweisen muss. Um diese Vorgaben umzusetzen wird
anhand der Datenstruktur jenes Element ermittelt, welches keine Vorgänger besitzt, um
den Erstellungsprozess zu beginnen. Laut den Voraussetzungen beginnt jedes Modell
mit einem Startknoten, welcher vor das erste Element gesetzt wird. Anhand des Ersten
Aktivitätsknoten werden dann dessen Nachfolger ermittelt und an das bestehende Pro-
zessmodell angefügt. Diese Vorgehensweise wird solange durchgeführt, bis das letzte
Element erreicht wurde. Dieses Element weißt keine weiteren Nachfolger auf, und somit
der iterative Prozess abgeschlossen werden. Laut Vorgabe folgt noch das Endelement,
welches wiederum an den letzten Aktivitätsknoten angehängt wird. Dieser Vorgang wird
sowohl für die Hauptübung, als auch für die Detailaufgaben identisch durchgeführt.
Um Aktivitäten von Gateways besser unterscheiden zu können, wird während der Ge-
nerierung auf die jeweiligen Eigenschaften Rücksicht genommen und anhand dieser
Informationen eine jeweils unterschiedliche Darstellung in Forum und Farbe vorgenom-
men. Diese Darstellung ist in der vorangegangenen Grafik 6.3 bereits ersichtlich.
6.4.2 Datenkonzept und Funktion
Für die Darstellung des Modells wird zunächst auf die datenbankseitige Darstellung der
erstellten Übung zurückgegriffen. Diese Repräsentation wird im Anschluss in die Syntax
des
Mermaid
-Frameworks umgewandelt, um das Prozessmodell generieren zu können.
Die nachfolgende Abbildung 6.4 gibt einen beispielhaften Einblick in die verwendete
Syntax, um mit Hilfe des Frameworks ein Prozessmodell zu erstellen.
42
6.4 Prozessmodellgenerator
0((Start)) →752(Dehnen)
752 →906(Laufen)
906 →X((Ende))
Abbildung 6.4: Beispielsyntax eines einfachen Prozessmodells
Wie bereits eingangs beschrieben, beginnt jedes Modell mit einem Startknoten. Dieser
erhält in obigem Schema die
0
als Identifikator. Im Beispiel folgt die Aktion
Dehnung
, die
wiederum mit der vorangestellten Identifikation im Modell referenziert wird. In der zweiten
Zeile findet sich die Beschreibung des zweiten Elements. Um einen Zusammenhang
herstellen zu können wird vorab der Vorgänger vermerkt und mit Pfeilen auf das nachste-
hende Element verwiesen. Mit diesem Vorgehen lassen sich immer Tupel definieren, die
eine Kante im Prozessmodell darstellen. Die Pfeile geben die Richtung dieser Kanten
im Modell vor. Die Beschreibungen in den Klammern bilden die Knoten des Modells.
Abgeschlossen wird ein Prozess immer mit einem Endknoten der im Beispiel mit
Ende
gekennzeichnet ist und mit einem
X
identifiziert wird. Das die eben erläuterte Notation
ergibt das obere Prozessmodell in der Abbildung 6.3.
In der Abbildung 6.5 wird die Syntax eines komplexeren Prozessmodells dargestellt.
Dieses Beschreibung entspricht dem untersten Beispiel in der Grafik 6.3. Diese Struktur
soll die Umsetzung von Verzweigungen verdeutlichen. Hierbei sind sowohl ein
or
als
auch ein
and
abgebildet. Der öffnende Teil einer Verzweigung enthält immer zwei Kanten
zu seinen Nachfolgern. In der ersten Zeile des Beispiels beginnt bereits eine Aufteilung
des Pfades. Es folgen die Tupel
757,756
und
757, 755
, die die Kanten zu den beiden
Nachfolgern abbilden. Beim Abschluss findet die umgekehrte Vorgehensweise statt,
indem zwei Pfade auf das gleiche Zielelement zeigen. Somit wird die Aufspaltung wieder
zusammengeführt. Die Syntax des im weiteren Verlauf abgebildeten
or
Gateways ist
analog zum eben erläuterten Vorgehen. Alle übrigen Pfade des Modells sind wie im
obigen Beispiel 6.4 codiert.
43
6 Realisierung
0((Start)) →757{and}
757 →756(Zählen)
756 →758{and}
757 →755(Liegestützen)
755 →758{and}
758 →759(Kniebeugen)
759 →834{or}
834 →833(Joggen)
833 →835{or}
834 →763(F ahrradfahren)
763 →835{or}
835 →X((Ende))
Abbildung 6.5: Beispielsyntax eines komplexeren Prozessmodells
44
7
Anforderungsabgleich
In diesem Kapitel werden nach Abschluss der Realiserungsphase, die zuvor festgelegten
Anforderungen an den Prototypen abgeglichen. Mittels dieses Abgleiches lässt sich
feststellen, wie und in welchem Umfang die unterschiedlichen Anforderungen realisiert
sind. Dazu werden zunächst wieder die nicht funktionalen Anforderungen 7.1 vor den
funktionalen Anforderungen 7.2 betrachtet. Es erfolgt eine Untersuchung der einzelnen
Anforderungen in Bezug auf deren Erfüllung. Dazu sind jeweils Bemerkungen zur
Umsetzung jeder Teilanforderung mit angegeben. Den Abschluss dieses Kapitels bildet
eine kurze Zusammenfassung der Ergebnisse.
7.1 Nicht Funktionale Anforderungen
Die nachfolgende Aufstellung beschreibt die nicht funktionalen Anforderungen und deren
Erfüllung in Hinblick auf die zuvor gestellten Kriterien.
Nr. Anforderung Status Beschreibung
I Einfachheit erfüllt
Die Oberflächen sind in einem schlichten Design
gehalten und alle nötigen Informationen sind ge-
ordnet dargestellt. Diese Ordnung lässt sich mit
der Verwendung von Tabellen und Listen, in de-
nen die Daten angeordnet sind, begründen. In
Bezug auf die Einfachheit des Übungskonfigura-
tors, muss die abschließende Studie zeigen, in
wie weit die Anwender diesen Punkt bewerten.
45
7 Anforderungsabgleich
II Bedienbarkeit erfüllt
Diese Anforderung wird mit dem Einsatz einer
einheitlichen Menüführung in der kompletten
Anwendung erfüllt. Alle Bedienelemente enthal-
ten zusätzlich zu einem beschreibenden Text
noch ein Icon, welches die Beschreibung bildlich
verdeutlicht und somit die Funktion der jeweili-
gen Schaltfläche mit einem Blick deutlich wird.
Schaltflächen die in manchen Anwendungssitua-
tionen gerade nicht verwendet werden können
sind zudem inaktiv und ausgegraut. Die Bedien-
barkeit des Konfigurators muss wiederum erst
in der nachfolgenden Studie durch die Benutzer
evaluiert werden.
III Übersichtlichkeit erfüllt
Um die Benutzeroberflächen, Menüs, Tabellen
und Eingabemasken so übersichtlich zu gestal-
ten wie möglich, werden auch hier Icons zur
grafischen Darstellung einzelner Punkte verwen-
det. Darüber hinaus sind weiterführende Infor-
mationen zu Schaltflächen oder anderen wich-
tigen Elemente als Hinweise hinterlegt. Diese
Informationen sind standardmäßig nicht sicht-
bar und werden durch das Zeigen des Cursors
auf das jeweilige Element eingeblendet. Dies
lässt eine übersichtliche Gestaltung der Benut-
zeroberflächen, die mit weiteren Informationen
angereichert und bei Bedarf eingeblendet wer-
den können, zu.
46
7.1 Nicht Funktionale Anforderungen
IV Fehlertoleranz erfüllt
Diese Anforderung wurde dahin gehend erfüllt,
in dem die Eingabemöglichkeiten bei Formu-
laren begrenzt sind beziehungsweise die Ein-
gaben geprüft werden. Als Beispiel kann die
Verwendung von Kalendern zur Datumseinga-
be herangezogen werden. Damit ist es möglich
sowohl Falscheingaben als auch Werte auszu-
grenzen, die rein logisch keinen Sinn ergeben.
Als weiteren Aspekt zur Fehlertoleranz ist die
Möglichkeit zur nachträglichen Bearbeitung oder
auch Veränderung aller Bestandteile zu nennen,
um Fehler nachträglich ausbessern zu können.
Tabelle 7.1: Abgleich der nicht funktionalen Anforderungen des Therapieplaners
47
7 Anforderungsabgleich
7.2 Funktionale Anforderungen
In diesem Bereich sind nachfolgend jene Punkte aufgelistet, die für die Funktion des
Prototypen zuvor als essentiell eingestuft worden sind. Dabei wird jede Teilanforderung
einzeln mit Blick auf deren Erfüllungsgrad hin betrachtet.
Nr. Anforderung Status Beschreibung
I
Erstellung einer
Therapie
erfüllt
Die Erstellung einer Therapie ist mittels einer
formularbasierten Oberfläche realisiert. Dabei
kann, wie gefordert ein Namen vergeben wer-
den, ein Patient zu dieser Therapie hinzuge-
fügt, sowie Beginn und Ende festgelegt werden.
Darüber hinaus ist es optional möglich eine Be-
schreibung anzugeben um weiterführende Infor-
mationen oder Details zur Therapie angeben zu
können. Die Lösch- und Änderungsfunktionen
sind ebenfalls erfüllt.
II
Erstellen von
(Präsenz)-
Terminen
erfüllt
Auch diese Anforderung wird durch ein Formular
realisiert, in dem alle geforderten Informationen
angegeben werden. Die zusätzliche Bedingung
für die Wiederholbarkeit dieser Termine ist durch
eine entsprechenden Auswahlliste im Formular
erfüllt. Zusätzlich lassen hier, wie auch schon
bei der Therapieerstellung, zusätzliche Informa-
tionen mit zu einem Termin hinzufügen. Die Mög-
lichkeit nachträgliche Änderungen durchzufüh-
ren oder einen Termin wieder zu entfernen sind
ebenfalls umgesetzt.
48
7.2 Funktionale Anforderungen
III
Erstellen von
Hausaufgaben
erfüllt
Die Basis zum Erstellen von Hausaufgaben ist
nach dem gleichen Vorgehen wie die Erstellung
von Terminen umgesetzt. Hierbei werden wie-
derum alle nötigen Angaben mittels Formularein-
gaben realisiert. Die zusätzliche Funktion des
Festschreibens und die damit einhergehende
Unveränderlichkeit der Inhalte ist ebenfalls um-
gesetzt und somit erfüllt.
IV
Erstellen von Be-
nachrichtigungen
erfüllt
Die erste Komponente einer bestehenden Haus-
aufgabe stellt die Benachrichtigung dar. Diese
können mittels eines Aktionsmenüs jederzeit ein-
gefügt, geändert oder entfernt werden. Darüber
hinaus können verschiedene Bedingungen, die
für das Auslösen einer solchen Benachrichti-
gung zuständig sind, definiert werden. Zusätz-
lich können diese Bedingungen mit der voran-
gehenden in Zusammenhang gesetzt werden,
um eine komplexe Benachrichtigungsstruktur zu
ermöglichen.
V
Erstellen von
Feedbacks
erfüllt
Feedbacks verhalten sich umgekehrt zu Benach-
richtigungen und sind folglich ähnlich in der Um-
setzung. Hierbei ist es möglich innerhalb einer
Hausaufgabe Feedbackfragen zu erstellen. Die-
se Fragen können offen, das heißt ohne vorde-
finierte Antwort, gestellt werden. Aber es kön-
nen auch Antworten vorgegeben werden, wo-
bei festgelegt wird, ob nur eine oder mehrere
schlussendlich vom Benutzer wählbar sind. Die-
se Feedbacks können wiederum jederzeit geän-
dert oder wieder entfernt werden.
49
7 Anforderungsabgleich
VI
Erstellen einer
Übung
erfüllt
Diese Anforderung bildet den zentralen Bestand-
teil des Prototypen. Dabei sind das Erstellen von
Hauptübungen und der dazugehörigen Teilübun-
gen, sowie deren einzelnen Messungen und Ak-
tionen realisiert. Diese Elemente lassen sich
nachträglich ändern und wieder aus der kom-
plexen Übungsstruktur entfernen, insofern die
Übung dadurch in sich logisch erhalten bleibt.
Zum Beispiel lassen sich keine leeren Übungen
erzeugen, indem das letzte verbleibende Ele-
ment gelöscht wird.
VII
Ableitung eines
Prozessmodells
erfüllt
Durch das Festlegen einer entsprechenden Da-
tenstruktur der Übungsinhalte lässt sich jedes
Element mit seinem Vorgänger und zu seinem
Nachfolger verknüpfen. Nach Auswertung dieser
Daten und die Umwandlung in eine vordefinierte
Syntax lässt sich mittels eines Frameworks ei-
ne grafische Repräsentation erzeugen. Dieses
Modell ist im Anschluss dem Benutzer in einer
separaten Oberfläche zugänglich.
Tabelle 7.2: Abgleich der funktionalen Anforderungen des Therapieplaners
7.3 Ergebnis
In diesem abschließenden Abschnitt wird die Umsetzung der geforderten Punkte noch
einmal kurz zusammengefasst.
Generell konnten alle geforderten Anforderungen sowohl im funktionalen als auch im
nicht funktionalen Bereich umgesetzt werden. Jedoch gerade im Bereich der Einfachheit
und Bedienbarkeit der Anwendung muss die nachfolgende Studie Aufschluss darüber
geben, ob und wie weit diese Anforderungen durch die Benutzer bewertet werden. Dabei
50
7.3 Ergebnis
stellt die Konfiguration der Übungen und die dazugehörigen Elemente die größte Heraus-
forderung dar. Die Tatsache, dass der Konfigurator eine Eigenentwicklung darstellt, lässt
die Fragen der Bedienbarkeit und Einfachheit des Prototypen bis zu einer Evaluierung
offen.
Abschließend lässt sich feststellen, dass die Umsetzung eines Projektes mit klar defi-
nierten Anforderungen wesentlich einfacher ist, als ohne einen konkreten Rahmen an
Funktionen. Im Laufe des Entwicklungsprozesses sind die ein oder andere Anforderung
noch etwas präzisiert oder abgeändert worden. Diese Änderungen hielten sich jedoch in
Grenzen und führten somit zu keinen grundlegenden Änderungen am Prototypen zur
Entwicklungszeit.
51
8
Studie
Das nachfolgende Kapitel befasst sich mit einer Benutzerstudie, um die Handhabung
und Benutzbarkeit des Konfigurators zu evaluieren. Zunächst wird der Aufbau der Studie
näher betrachtet. Im Anschluss daran erfolgt die Durchführung und die Darstellung der
Ergebnisse der Studie.
8.1 Aufbau
Für die Benutzerstudie werden Testpersonen in zwei unterschiedliche Testgruppen
eingeteilt. Die erste Gruppe bekommt vier vorgegebene Prozessmodelle präsentiert,
anhand derer sie den Prozess textuell beschreiben sollen. Dabei können die Tester den
abgebildeten Ablauf frei auf einem dafür vorgesehen Formular festhalten. Die zweite
Gruppe erhält im Anschluss die erstellten textuellen Beschreibungen der Prozesse
ohne die Abbildungen zu kennen. Anhand dieser Beschreibungen sollen sie mittels
der
Albatros
Plattform, insbesondere mit dem Übungskonfigurator, den beschriebenen
Prozess als Übung umsetzen. Die damit erstellte Übung kann dann im Anschluss als
Prozessmodell betrachtet werden. Die Komplexität und der Umfang der Modelle nimmt
im Verlauf jeweils zu.
An der Studie nehmen insgesamt 56 Teilnehmer teil. Die eine Hälfte davon erhält die
Aufgabe gegebene Modelle zu beschreiben und der andere Teil wird mit der Konfigura-
tion der Modelle anhand der Beschreibungen betraut. Die Probanden sind Studenten
aus verschiedenen Studienrichtungen mit unterschiedlichem Vorwissen im Bereich der
Prozessmodellierung.
53
8 Studie
Um Aussagen über die Benutzbarkeit des Konfigurationstools treffen zu können werden
die ursprünglichen Prozessmodelle, die der ersten Testgruppe als Beschreibungsgrund-
lage dienen, mit den Resultaten der erstellten Modelle der zweiten Gruppe verglichen.
Dabei kommen zwei unterschiedliche Betrachtungen zur Anwendung. Zunächst erfolgt
eine Fehlerbewertung anhand der tatsächlichen Abweichung der jeweiligen Modelle.
Mit dieser Betrachtungsweise wird keinerlei Rücksicht auf die logische Korrektheit ge-
nommen, sondern jede Abweichung als fehlerhaft bewertet. Dabei werden fehlerhafte
Verzweigungen und Aktionen unabhängig voneinander festgehalten. Die zweite Be-
trachtungsweise beinhaltet eben diese logische Betrachtungsweise und es werden nur
Fehler notiert, die auch den Sinn des Modells verändern. Mit diesem Ansatz werden
Prozessmodelle, die zwar im Aussehen, in der Anzahl an Aktivitäten oder Verknüpfungen
abweichen, jedoch logisch stimmig sind, nicht als fehlerhaft angesehen.
Darüber hinaus soll noch erhoben werden, in wie weit die Teilnehmer das Konzept der
übergeordneten Hauptübung umsetzten können. Dazu werden die Abweichungen zu
den in der Hauptübung definierten Aktivitäten mit den tatsächlich dazu definierten Detail-
übungen, verglichen. Besteht die Hauptaufgabe beispielsweise aus drei Teilaktionen, so
sollten auch drei Detailbereiche definiert sein. Sind davon nur zwei im Detail ausgeführt,
wird eine Abweichung von Eins festgehalten.
8.2 Durchführung
Zunächst erhalten alle Teilnehmer einen Fragebogen mit demografischen Angaben
bei dem sie neben Angaben zur ihrer Person und zur bisherigen Ausbildung auch die
Erfahrungen im Umgang mit Prozessmodellierung angeben sollen. Im Anschluss daran
erhalten die Testpersonen der ersten Gruppe vier Prozessmodelle vorgelegt. Anhand
dieser Modelle sollen sie den erkannten Prozess beziehungsweise die als Modell abgebil-
dete Übung beschreiben. Diese Beschreibung soll die für den Patienten zu erledigenden
Aufgaben widerspiegeln. Die zweite Testgruppe erhält nach dem Fragebogen Zugang
zum Prototypen. Dort ist bereits eine Therapie samt zugehöriger Hausaufgabe vorde-
finiert. Der Teilnehmer erhält dazu die Beschreibungen, die vorab von einem anderen
Probanden zu den jeweiligen Modellen angefertigt wurden, vorgelegt. Anhand dieser
54
8.3 Ergebnisse
Beschreibungen soll mit Hilfe des Übungskonfigurators entsprechende Übungen erstellt
beziehungsweise definiert werden. Dabei besteht die Möglichkeit das resultierende
Prozessmodell während der Konfiguration jeder Zeit zu betrachten.
8.3 Ergebnisse
Nach der Auswertung der erstellten Prozessmodelle werden in diesem Teilabschnitt die
Ergebnisse beschrieben. Zunächst werden die Ergebnisse anhand der ersten Betrach-
tung der Modelle dargestellt. Im Anschluss erfolgt die Auswertung der Betrachtung unter
Einbeziehung der Einhaltung der Logik der Prozessabbildungen.
Abbildung 8.1 stellt jeweils pro Prozessmodell die unterschiedlichen Fehlerquellen dar.
Auffällig dabei ist, dass die zweite Konfiguration am besten abschneidet obwohl sie
komplexer und aufwändiger ist als die erste Darstellung.
Anzahl der Fehler bei der Konfiguration im Vergleich zur Vorlage
0
20
40
60
80
#1
#2
#3
#4
falsche logische Verknüpfungen Anzahl fehlerhafter Aktivitäten Verwechslung von Messung und Aktivität
Abbildung 8.1:
Ergebnis: Anzahl der Fehler bei der Konfiguration im Vergleich zur Vorla-
ge pro Modell
55
8 Studie
Des weiteren ist zu bemerken, dass das dritte Prozessmodell den Fehler
Messungen mit
Aktivitäten
zu vertauschen, beinhaltet. Dabei enthält dieses Beispiel gar keine Aktivitäten
die eine Messung darstellen sollen. Eine mögliche Ursache könnte die vorangegangene
Beschreibung darstellen, bei der der Proband eine zweideutige Aussage über das
Vorgehen getroffen hat. Zuletzt liefert die Abbildung noch das Ergebnis, dass unabhängig
vom bearbeiteten Prozess jeweils mehr Fehler bei den Aktivitäten zu verzeichnen sind
als jene, die Verknüpfungen betreffen.
Um Aussagen über die Gesamtfehlerzahl der einzelnen Prozessmodelle treffen zu
können, müssen die einzelnen Fehlertypen pro Aufgabe aggregiert vorliegen. Diese
Daten liefert das Diagramm 8.2. Analog zum Ergebnis der vorangegangenen Grafik
8.1 wurde das zweite Prozessmodell mit Abstand am besten durch die Teilnehmer
rekonstruiert. Die nachfolgenden Aufgaben wurden im Verhältnis zu ihrer Komplexität
erledigt und entsprechend mehr Fehler beim aufwändigeren Modell gemacht.
Summe der Fehler pro Prozessmodell
0
35
70
105
140
#1
#2
#3
#4
falsche logische Verknüpfungen Anzahl fehlerhafter Aktivitäten Verwechslung von Messung und Aktivität
Abbildung 8.2: Ergebnis: Summe der Fehler pro Prozessmodell
56
8.3 Ergebnisse
Die Ursache für die hohe Fehlerzahl beim vermeintlich einfachsten Prozess könnte eine
andere Auslegung der Beschreibung darstellen. Auffällig war bei diesem Prozessmodell,
das es gar nicht nötig gewesen wäre für diesen Ablauf eine Detailübung zu konfigurieren,
da die komplette Ausführung innerhalb von zwei Aktivitäten innerhalb der Hauptübung
erledigt werden kann. Auf Grund dieser Tatsache haben jedoch viele Teilnehmer versucht
die einfache Abbildung unnötig zu verkomplizieren, was zu Abweichungen und somit zu
Fehlern im Vergleich zum Original führt. Diese Problematik wird in der nachfolgenden
Diskussion nochmals aufgegriffen und betrachtet.
Die nachfolgenden Ergebnisse berücksichtigen diesen Sachverhalt und akzeptieren
Lösungen, die zwar strukturell vom zugrundeliegenden Modell abweichen, jedoch vom
logischen Standpunkt der Betrachtung aus sinnvoll sind.
Um diese Tatsache näher betrachten zu können und die Auswirkung auf die Fehlerzahl
bestimmen zu können, erfolgt eine neue Betrachtung der erstellten Prozessmodelle
unter der Prämisse, dass Abweichungen, die den Sinn beziehungsweise die Logik
des Ausgangsmodell nicht ändern, nicht als Fehler gewertet werden. Somit lässt sich
erkennen in wie weit die Umsetzung der Modelle möglich ist und die Gestaltungsfreiheit
der Probanden gegeben bleibt.
Die nachfolgende Abbildung 8.3 stellt nun die Ergebnisse mit der zuvor beschriebenen
Herangehensweise dar. Jetzt ist ein deutlicher Zusammenhang zwischen der Fehleran-
zahl und der Komplexität der jeweiligen Aufgaben zu erkennen. Außerdem wird deutlich
das das einführende Modell unter Einhaltung der Logik wesentlich besser abschneidet.
Und die bereits beschriebene Ursache nicht mehr zum Tragen kommt, da die logische
Umsetzung fast immer gegeben ist. Wie bei der zuvor angestellten Betrachtung der
Fehler überwiegt auch hier die Anzahl der gemachten Fehler im Bereich der zu modellie-
renden Aktivitäten. Die auf Grund von Verwechslungen von Messungen und Aktionen
basierenden Fehler haben sowohl strukturelle als auch logische Konsequenzen und
bleiben daher in beiden Betrachtungen unverändert.
57
8 Studie
Anzahl logischer Fehler bei der Konfiguration im Vergleich zur Vorlage
0
17,5
35
52,5
70
#1
#2
#3
#4
falsche logische Verknüpfungen Anzahl fehlerhafter Aktivitäten Verwechslung von Messung und Aktivität
Abbildung 8.3:
Ergebnis: Anzahl logischer Fehler bei der Konfiguration im Vergleich zur
Vorlage pro Modell
Abschließend erfolgt wiederum die absolute Betrachtung der Fehler in der nachfolgenden
Abbildung 8.4. Auch hier ist zu erkennen dass sich das oben angedeutete Verhalten
widerspiegelt und die einfachste Aufgabe mit am wenigsten Fehlern absolviert wird und
bei den jeweils schwereren Herausforderungen dementsprechend mehr Fehler zu Buche
schlagen.
58
8.3 Ergebnisse
Summe logischer Fehler pro Prozessmodell
0
30
60
90
120
#1
#2
#3
#4
falsche logische Verknüpfungen Anzahl fehlerhafter Aktivitäten Verwechslung von Messung und Aktivität
Abbildung 8.4: Ergebnis: Summe logischer der Fehler pro Prozessmodell
Zusammenfassend betrachtet nehmen die Fehlerzahlen mit der Komplexität der Aufga-
ben zu. Die durchschnittliche Anzahl der Fehler pro Prozessmodell ist jedoch vergleichs-
weise hoch, wie es in der abschließenden Abbildung 8.5 zu erkennen ist. Beispielsweise
werden beim dritten Modell im Durchschnitt etwa drei Fehler pro Modell gemacht. Dieses
Ergebnis kann bedeuten, dass die Beschreibungen der ersten Testgruppe zu ungenau
gemacht wurden, die Prozessmodelle zu schwierig waren, aber auch dass die Proban-
den Probleme mit dem Konfigurationswerkzeug hatten. Da gerade bei den komplexeren
Modellen die Fehlerhäufigkeit zunimmt besteht auch die Möglichkeit, damit der Übungs-
konfigurator in dieser Hinsicht Verbesserungspotential aufweist.
Im Gegensatz dazu sind die ersten beiden Testkonfigurationen mit relativ wenig Fehlern
behaftet. Vor allem wenn die Betrachtungsweise unter Einbeziehung der logischen Kor-
rektheit gewählt wird, sind diese beiden Modelle sehr gut von den Probanden anhand
der Beschreibungen modelliert worden.
59
8 Studie
Durchschnitte Fehlerzahl pro Prozessmodell
#1
#2
#3
#4
0,00
1,25
2,50
3,75
5,00
Betrachtungsweise 1 Betrachtungsweise 2
Abbildung 8.5:
Ergebnis: Aufstellung der durchschnittlichen Fehlerzahl pro Prozessmo-
dell bei beiden Betrachtungsweisen
60
9
Diskussion
In diesem Abschnitt sollen zunächst einige Aspekte des Projektes, insbesondere je-
ne, die mit der Entwicklung und Umsetzung des Übungskonfigurators einhergehen,
erörtert werden. Im Anschluss daran erfolgt eine Diskussion über die Ergebnisse der
Benutzerstudie aus Kapitel 8.
Zu Beginn dieses Projekts sind die Anforderungen festgehalten worden. Darunter ist
auch die Grundstruktur des Konfigurators festgelegt indem die Einteilung der Übungen
in einen Haupt- und Detailbereich erfolgt. Auf Grund der Studienergebnisse ergeben
sich dort jedoch Probleme. Gerade das erste und einfachste Studienmodell ist mit einer
großen Fehlerzahl behaftet, die größten Teils mit der Aufteilung in die zwei Bereiche
zustande kommt. Um die generelle Auswirkung dieser Aufteilung aufzuschlüsseln, sind
im Nachgang zur Studie noch die Fehler bei der Umsetzung dieser Aufteilung bezie-
hungsweise der Abstraktionsaufgabe ermittelt worden. Die nachfolgende Abbildung 9.1
zeigt das Ergebnis dieser Auswertung. Dabei sind die Fehler prozentual auf das jeweilige
Modell aufgeschlüsselt.
Diese Auswertung verdeutlicht den bereits angesprochenen Sachverhalt, da ein Drittel
der Abstraktionsfehler bereits im ersten Prozessmodell zu finden sind, obwohl dieses
sehr einfach gehalten ist und nur aus zwei Aktivitäten besteht. Die hohe Fehlerzahl
beim letzten Testmodell ist auf die Komplexität zurückzuführen, denn dort war eine
Abstraktion sinnvoll oder sogar zwingend. Folgernd muss für eventuelle Änderungen
oder Weiterentwicklungen des Prototypen dieser Aspekt der Aufteilung nochmals genau
geprüft und verbessert werden, um dort die Fehlerquote und somit die Ergebnisse und
beziehungsweise den Erfolg zu verbessern.
61
9 Diskussion
Fehler bei der Abstraktion der Hauptübung
#4
37!%
#3
18!%
#2
12!%
#1
33!%
#1 #2 #3 #4
Abbildung 9.1:
Fehler bei der Abstraktion innerhalb der einzelnen Beispielmodellen im
Rahmen der Benutzerstudie
Einen weiteren Diskussionspunkt in diesem Zusammenhang stellt die Beschränkung
der Hauptübung auf zwei Pfade dar, wobei ein Pfad mit Aktionen und der andere mit
Messungen versehen werden kann. Dadurch lässt sich die Komplexität reduzieren und
weitere Eingaben auf die Detailübungen verteilen. Auf der anderen Seite beschränkt
diese Tatsache die Gestaltungsmöglichkeiten durch den Anwender. Man könnte hierbei
entweder die Eingabe noch weiter beschränken und nur einen Pfad erlauben und
somit lediglich einen linearen Grundablauf festlegen, oder auch in dieser Stufe schon
komplexere Modelle erstellen lassen. Dies muss letztendlich durch einen weiteren Test
geklärt werden.
Abschließend müssen noch die Fehlerzahlen aus der Benutzerstudie (siehe Kapitel 8)
diskutiert werden, da anhand dieser Zahlen durchaus Verbesserungspotential besteht.
Auf Grund dieser Tatsache sollte das Grundkonzept des Konfigurators in Bezug auf
verschachtelte, oder auch oft verzweigte Modelle, nochmals überdacht und optimiert
werden. Gerade die Modellierung von komplizierten Aufgaben, wie zum Beispiel eine
Aktion bei der wiederum andere Aktionen oder Messungen gleichzeitig stattfinden sollen,
62
jedoch auch eine komplett davon unabhängige Alternative möglich sein soll, erfordern
ein hohes Maß an Unterstützung bei der Umsetzung. Eine Möglichkeit könnte darin
bestehen eine animierte Darstellung des aktuellen Modells und dessen derzeitigen Aus-
führungsmöglichkeiten einzuführen. Damit könnte der Anwender während der Erstellung
des Modells die Konsequenzen aber auch Möglichkeiten sehen und darauf entsprechend
reagieren. Ein weiterer Punkt könnte die Bereitstellung von vordefinierten Modellteilen
sein. Damit könnten komplexe Schritte ausgewählt und in die Konfiguration übernommen
werden. Der Benutzer müsste so nur noch die entsprechenden Bezeichnungen und
Einstellungen an den einzelnen eingefügten Elementen vornehmen. Hierzu könnte das
eben erwähnte Beispiel mit einer parallelen Ausführung und einer Alternative als Vorlage
dienen. Da die Ergebnisse bei den einfachen Modellen weit aus besser ausfallen, könn-
ten sich auch diese beiden andiskutierten Ansätze zur Verbesserung des Werkzeugs
positiv auswirken.
63
10
Zusammenfassung und Ausblick
Nach Umsetzung der
Albatros
-Plattform und der Auswertung der Benutzerstudie existiert
ein Prototyp zur Planung von therapeutischen Interventionen der einen eigens dafür
konzeptionierten Übungskonfigurator beinhaltet.
Eine solche Entwicklung erfordert zunächst eine solide und umfangreiche Planung ohne
die es nicht möglich gewesen wäre ein solches Werkzeug umzusetzen. Dank zahlreicher
Gespräche und einer genauen Definition der Anforderungen konnten dazu Konzepte zur
Umsetzung entstehen, die in realisierbaren Entwürfen mündeten. Diese frühen Phasen
vor der eigentlichen Umsetzung nahmen weit mehr Zeit in Anspruch als gedacht bezie-
hungsweise geplant. Der Mehraufwand ermöglicht jedoch eine bessere Realisierung der
ausgearbeiteten Konzepte, da weit mehr Details und Informationen vorliegen. Dennoch
bereitete die Erstellung des Konfigurationstools, durch das hohe Maß an Komplexität
und der Vielzahl an Konfigurationsmöglichkeiten, Schwierigkeiten bei der Erstellung.
Gerade das Zusammenspiel mit den daraus resultierenden Prozessmodellen führt immer
wieder zu Fehlern, die erst mittels aufwendiger Tests behebbar sind. Die abschließende
Studie, bei der Probanden gegebene Prozessmodelle zunächst textuell beschreiben
und im Anschluss mittels des Konfigurators umsetzten, führte zum Ergebnis, dass noch
Verbesserungspotential bei diesem Werkzeug besteht. Im Bereich von komplexeren
Aufgaben beziehungsweise Prozessen ist die Fehlerzahl durch die Studienteilnehmer
deutlich, wobei diese Tatsache nicht ausschließlich vom Konfigurationstool abhängig ist
sondern auch von weiteren Faktoren abhängen kann.
Zusammenfassend ermöglicht dieser Prototyp einer Therapieplanungsplattform einen
Einblick in ein komplett neues Konzept Übungen im Kontext von Hausaufgaben zu erstel-
len, ohne dass der Anwender eine Modellierungssparche beherrschen, oder sonstige
65
10 Zusammenfassung und Ausblick
Kenntnisse im Bereich der Prozessmodellierung aufweisen muss. Bei einfachen und
übersichtlichen Übungsverläufen sind gute Ergebnisse im Rahmen der Studie erzielt
worden. Für komplexere und aufwändigeren Modellen könnten die diskutierten Maß-
nahmen zu einer Verbesserung führen. Für den Fall, dass dieser Prototyp in Zukunft
nochmals überarbeitet oder weiterentwickelt werden soll, müssen diese oder auch weite-
re Maßnahmen im Bereich von größeren Prozessmodellen auf jeden Fall nochmals in
Betracht gezogen werden.
Der eingangs aufgeführte Trend der zunehmenden Digitalisierung und die zahlreichen
Anwendungsmöglichkeiten der heute verfügbaren mobilen Endgeräte, wie Smartphones
und Tabletts wird in naher Zukunft auch im medizinischen Bereich beziehungsweise
im Gesundheitssektor große Veränderungen mit sich bringen. Dabei spielt auch die
Generation der Digital Natives eine wichtige Rolle, denn diese Personen sind mit den
technischen Möglichkeiten aufgewachsen und somit bestens damit vertraut. Dies könnte
zu einer besseren Aufgeschlossenheit und Akzeptanz gegenüber solcher Plattformen
und auch den damit verbundenen mobilen Anwendungen auf den Endgeräten führen.
Daher ist diese Thematik, gerade auch im Bereich von therapeutischen Interventionen
in Verbindung mit mobilen Geräten, ein zukunftsfähiges Modell mit großem Potential.
66
Abbildungsverzeichnis
1.1 Übersicht - Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1
Schema - Therapeutische Intervention aus informationstechnischer Sicht-
weise [SPS+17b] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Übersicht - Genereller Aufbau eines Therapieplanes . . . . . . . . . . . . 7
2.3 Schema - Aufteilung des Übungsprozesses [SPSR17a] . . . . . . . . . . 9
3.1 Ausschnitt aus dem Übungskonfigurator von SimpleSet . . . . . . . . . . 12
3.2
Beispiel - Wie benutzt man
PhysiApp
, die mobile Anwendung der
Phy-
sitrack-Plattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Ausschnitt aus der TheRehablab Oberfläche . . . . . . . . . . . . . . . . 16
5.1
Grobentwurf Therapieplaner - Übersicht über eine spezifische Therapie
mit grafischer Übersicht, Terminen und Hausaufgaben . . . . . . . . . . . 24
5.2 Entwurf - Übungskonfigurator . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.3 Entwurf - Datenbankkonzept . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1 Architekturkonzept der Albatros-Plattform . . . . . . . . . . . . . . . . . . 32
6.2 Beispiel einer Übung mit dazugehöriger Detailübung . . . . . . . . . . . . 37
6.3 Beispiel eines Prozessmodells . . . . . . . . . . . . . . . . . . . . . . . . 41
6.4 Beispielsyntax eines einfachen Prozessmodells . . . . . . . . . . . . . . . 43
6.5 Beispielsyntax eines komplexeren Prozessmodells . . . . . . . . . . . . . 44
8.1
Ergebnis: Anzahl der Fehler bei der Konfiguration im Vergleich zur Vorlage
pro Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
8.2 Ergebnis: Summe der Fehler pro Prozessmodell . . . . . . . . . . . . . . 56
8.3
Ergebnis: Anzahl logischer Fehler bei der Konfiguration im Vergleich zur
Vorlage pro Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
8.4 Ergebnis: Summe logischer der Fehler pro Prozessmodell . . . . . . . . . 59
8.5
Ergebnis: Aufstellung der durchschnittlichen Fehlerzahl pro Prozessmo-
dell bei beiden Betrachtungsweisen . . . . . . . . . . . . . . . . . . . . . 60
67
Tabellenverzeichnis
4.1 Nicht Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . 18
4.2 Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1 Abgleich der nicht funktionalen Anforderungen des Therapieplaners . . . 47
7.2 Abgleich der funktionalen Anforderungen des Therapieplaners . . . . . . 50
69
Literaturverzeichnis
[AJA] JavaScript/Ajax – SELFHTML-Wiki
.
https://wiki.selfhtml.org/
wiki/JavaScript/Ajax, Abruf: Freitag, 15. September 2017
[Apa] The Apache HTTP Server Project
.
https://httpd.apache.org
, Abruf:
Freitag, 15. September 2017
[BSVV07]
BERG, Marleen H. d. ; SCHOONES, Johannes W. ; VLIET VLIELAND, Theo-
dora P.: Internet-Based Physical Activity Interventions: A Systematic Review
of the Literature. In:
Journal of Medical Internet Research
9 (2007), Jul-
Sep, Nr. 3, e26.
http://dx.doi.org/10.2196/jmir.9.3.e26
. – DOI
10.2196/jmir.9.3.e26. ISBN 1438–8871
[DE07]
DÖRING, Nicola ; EICHENBERG, Christiane: Klinisch-psychologische In-
terventionen mit Mobilmedien. In:
Psychotherapeut
52 (2007), Mar, Nr.
2, 127–135.
http://dx.doi.org/10.1007/s00278-006-0523-9
. –
DOI 10.1007/s00278–006–0523–9. – ISSN 1432–2080
[Gro]
GROUP, Object M.:
Business Process Model and Notation
.
http://www.
bpmn.org, Abruf: 03.09.2017
[Gro11]
GROUP, Object M. ; OBJECT MANAGEMENT GROUP (OMG) (Hrsg.):
Busi-
ness Process Model and Notation (BPMN)
. 2.0. OMG Headquarters 140
Kendrick Street Building A, Suite 300 Needham, MA 02494 USA: Object
Management Group (OMG), January 2011
[Mer] mermaid ·GitBook
.
https://mermaidjs.github.io
, Abruf: Dienstag,
3. Oktober 2017
[Meu16]
MEUSCH, Dorothee: SmartHealth Wie smart ist Deutschland? / Techniker
Krankenkasse. Bramfelder Straße 140, 22305 Hamburg, 2016. – For-
schungsbericht
[MyS] MySQL.https://www.mysql.com, Abruf: Freitag, 15. September 2017
71
Literaturverzeichnis
[PGS+16]
PRYSS, Rüdiger ; GEIGER, Philip ; SCHICKLER, Marc ; SCHOBEL, Johannes
; REICHERT, Manfred: Advanced Algorithms for Location-Based Smart
Mobile Augmented Reality Applications. In:
Procedia Computer Science
94
(2016), August, 97–104. http://dbis.eprints.uni-ulm.de/1405/
[PGS+17]
PRYSS, Rüdiger ; GEIGER, Philip ; SCHICKLER, Marc ; SCHOBEL, Johannes
; REICHERT, Manfred: The AREA Framework for Location-Based Smart
Mobile Augmented Reality Applications. In:
International Journal of Ubi-
quitous Systems and Pervasive Networks (JUSPN)
9 (2017), July, Nr. 1,
13–21. http://dbis.eprints.uni-ulm.de/1522/
[PHP] PHP: Hyptertext Preprocessor
.
http://php.net
, Abruf: Dienstag, 19.
September 2017
[Phy17] Physitrack
.
https://www.physitrack.com
. Version:2017, Abruf:
30.08.2017
[PRSB16]
PRYSS, Rüdiger ; REICHERT, Manfred ; SCHICKLER, Marc ; BAUER, Tho-
mas: Context-Based Assignment and Execution of Human-Centric Mobile
Services. In:
5th IEEE International Conference on Mobile Services (MS
2016), IEEE Computer Society Press, 2016, 119–126
[PSS+17]
PRYSS, Rüdiger ; SCHICKLER, Marc ; SCHOBEL, Johannes ; WEILBACH,
Micha ; GEIGER, Philip ; REICHERT, Manfred: Enabling Tracks in Location-
Based Smart Mobile Augmented Reality Applications. In:
Procedia Com-
puter Science
110 (2017), 207–214.
http://dbis.eprints.uni-ulm.
de/1528/
[RF14]
R. FIELDING, J. R.: Hypertext Transfer Protocol (HTTP/1.1) / Internet Engi-
neering Task Force (IETF). Version: 2014.
http://httpwg.org/specs/
rfc7230.html
, Abruf: Freitag, 15. September 2017. 2014. – Forschungs-
bericht
[Sch13]
SCHUBERT, M.:
Datenbanken: Theorie, Entwurf und Programmierung re-
lationaler Datenbanken
. Vieweg+Teubner Verlag, 2013
https://books.
google.de/books?id=5y33BQAAQBAJ. – ISBN 9783322921130
72
Literaturverzeichnis
[Sim] SimpleSet - Physiotherapy Exercise Prescription Software
.
https://
simpleset.net, Abruf: Montag, 4. September 2017
[SPR+16a]
SCHICKLER, Marc ; PRYSS, Rüdiger ; REICHERT, Manfred ; HEINZELMANN,
Martin ; SCHOBEL, Johannes ; LANGGUTH, Berthold ; PROBST, Thomas ;
SCHLEE, Winfried: Using Wearables in the Context of Chronic Disorders -
Results of a Pre-Study. In:
29th IEEE Int’l Symposium on Computer-Based
Medical Systems, 2016, 68–69
[SPR+16b]
SCHICKLER, Marc ; PRYSS, Rüdiger ; REICHERT, Manfred ; SCHOBEL,
Johannes ; LANGGUTH, Berthold ; SCHLEE, Winfried: Using Mobile Serious
Games in the Context of Chronic Disorders - A Mobile Game Concept for the
Treatment of Tinnitus. In:
29th IEEE Int’l Symposium on Computer-Based
Medical Systems (CBMS 2016), 2016, 343–348
[SPS+17a]
SCHICKLER, Marc ; PRYSS, Rüdiger ; SCHOBEL, Johannes ; SCHLEE, Win-
fried ; PROBST, Thomas ; REICHERT, Manfred: Towards Flexible Remo-
te Therapeutic Interventions. In:
30th IEEE International Symposium on
Computer-Based Medical Systems (CBMS 2017), IEEE Computer Society
Press, June 2017
[SPS+17b]
SCHICKLER, Marc ; PRYSS, Rüdiger ; STACH, Michael ; SCHOBEL, Johannes
; SCHLEE, Winfried ; PROBST, Thomas ; LANGGUTH, Berthold ; REICHERT,
Manfred: An IT Platform Enabling Remote Therapeutic Interventions. In:
30th IEEE International Symposium on Computer-Based Medical Systems
(CBMS 2017), IEEE Computer Society Press, June 2017
[SPS+17c]
SCHOBEL, Johannes ; PRYSS, Rüdiger ; SCHLEE, Winfried ; PROBST, Tho-
mas ; GEBHARDT, Dominic ; SCHICKLER, Marc ; REICHERT, Manfred: Deve-
lopment of Mobile Data Collection Applications by Domain Experts: Experi-
mental Results from a Usability Study. In:
29th International Conference on
Advanced Information Systems Engineering (CAiSE 2017)
, Springer, June
2017 (LNCS 10253), 60–75
[SPSR16]
SCHOBEL, Johannes ; PRYSS, Rüdiger ; SCHICKLER, Marc ; REICHERT,
Manfred: Towards Flexible Mobile Data Collection in Healthcare. In:
29th IE-
73
Literaturverzeichnis
EE International Symposium on Computer-Based Medical Systems (CBMS
2016), 2016, 181–182
[SPSR17a]
SCHICKLER, Marc ; PRYSS, Rüdiger ; SCHOBEL, Johannes ; REICHERT,
Manfred: Supporting Remote Therapeutic Interventions with Mobile Proces-
ses. In:
6th IEEE International Conference on AI & Mobile Services (IEEE
AIMS 2017), IEEE Computer Society Press, June 2017
[SPSR17b]
SCHOBEL, Johannes ; PRYSS, Rüdiger ; SCHICKLER, Marc ; REICHERT,
Manfred: Process-Driven Mobile Data Collection (Extended Abstract). In:
8th
International Workshop on Enterprise Modeling and Information Systems
Architectures (EMISA 2017), 2017
[SPSR17c]
SCHOBEL, Johannes ; PRYSS, Rüdiger ; SCHICKLER, Marc ; REICHERT,
Manfred: Towards Patterns for Defining and Changing Data Collection
Instruments in Mobile Healthcare Scenarios. In:
30th IEEE International
Symposium on Computer-Based Medical Systems (CBMS 2017), 2017
[The] The Rehab Lab : Online Exercise Prescription Software : Your Prescripti-
on For Rehabilitation
.
http://www.therehablab.com/TheRehabLab.
html, Abruf: Donnerstag, 2. November 2017
[Use] UserSpice
.
https://userspice.com
, Abruf: Sonntag, 10. September
2017
[Woh14]
WOHLRAB, J.: Stellenwert der Therapieplanung. In:
Der Hautarzt
65 (2014), Mar, Nr. 3, 218–220.
http://dx.doi.org/10.1007/
s00105-013-2660-8
. – DOI 10.1007/s00105–013–2660–8. – ISSN
1432–1173
[WPH+04]
WANTLAND, Dean J. ; PORTILLO, Carmen J. ; HOLZEMER, William L. ;
SLAUGHTER, Rob ; MCGHEE, Eva M.: The Effectiveness of Web-Based vs.
Non-Web-Based Interventions: A Meta-Analysis of Behavioral Change Out-
comes. In:
Journal of Medical Internet Research
6 (2004), Oct-Dec, Nr. 4,
e40.
http://dx.doi.org/10.2196/jmir.6.4.e40
. – DOI 10.2196/j-
mir.6.4.e40. ISBN 1438–8871
74
Name: Andreas Reiter Matrikelnummer: 690730
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 .............................................................................
Andreas Reiter
