Universität Ulm | 89069 Ulm | Germany Fakultät für
Ingenieurwissenschaften
und Informatik
Institut für Datenbanken und
Informationssysteme
MEDo: Mobile Technik und Prozessmanagement zur Optimierung des Aufgaben-
managements im Kontext der klinischen Visite
Diplomarbeit an der Universität Ulm
Vorgelegt von
David Langer
mail@davidlanger.de
Gutachter
Prof. Dr. Manfred Reichert
Dr. Alena Hallerbach
Betreuer
Dipl. Inf. Rüdiger Pryss
2012
Fassung . März
© David Langer
Dieses Werk bzw. Inhalt steht unter einer Creative Commons Namensnennung-
Nicht-kommerziell-Weitergabe unter gleichen Bedingungen . Lizenz. Um eine Kopie
dieser Lizenz anzusehen, besuchen Sie
http://creativecommons.org/licenses/by-nc-sa/3.0/de/ oder senden Sie einen Brief
an Creative Commons, Howard Street, th Floor, San Francisco, California, ,
USA.
Satz: X
E
T
EX
MEDo: Mobile Technik und Prozessmanagement zur Optimierung des
Aufgabenmanagements im Kontext der klinischen Visite
MEDo: Combining process-supported, mobile task management with patient data
to use on ward rounds
Z. Die Visite im Krankenhaus ist maßgebend für die Ent-
scheidungsndung an vielen Stationen. Während der Visite werden Aufga-
ben ermittelt und koordiniert. Diese werden allerdings nicht formal organi-
siert und sind durch Medienbrüche fehleranfällig. Ärzt/innen/e wissen nicht
in welchem Status sich Behandlungen und Untersuchungen benden.
In dieser Arbeit wurden Prozessmodelle für vier Visiten in unterschiedli-
chen Stationen erstellt und verglichen. Basierend auf den Gemeinsamkeiten
wurde der Prototyp einer iPad-Applikation entwickelt und eine prozessunter-
stützte, mobile Aufgabenverwaltung mit Anschluss an Patientendaten reali-
siert. In Nutzerevaluationen und Usability-Tests hat sich gezeigt, dass alle Be-
fragten das System einsetzen würden und sie die Geschwindigkeit der Aufga-
benerstellung mit der von Sti und Papier gleichsetzen.
A. Medical rounds are highly inuential in the decision-making-
process at most wards. In the course of a round, tasks are determined and
distributed. But they are not formally organised – instead they are jotted down
and thus are prone to errors. Physicians are not notied about new results of
tests they requested.
In this work I present and analyze process models for four medical rounds
in different wards. Based on common features, I developed an iPad applicati-
on which combines process-supported, mobile task mangement with patient
data and information. User evaluation and usability tests then showed that all
physicians would introduce such a system on their wards. Findings also show
that they put the input speed on a level with that of pen and paper.
In conclusion, I could show that physicians can create, monitor and share
tasks by using a mobile, user friendly platform.
Inhaltsverzeichnis
1 Einleitung 1
. Ziel ...................................
. Entwicklungsschritte . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Grundlagen 5
. Visite im Krankenhaus . . . . . . . . . . . . . . . . . . . . . . . . .
. Prozessmanagement..........................
.. IT-Unterstützung im Krankenhaus . . . . . . . . . . . . . .
. Laufzettel als Pivot-Element der Visite . . . . . . . . . . . . . . . .
.. Probleme des Papier-Laufzettels . . . . . . . . . . . . . . .
.. Vorteile eines digitalen Laufzettels . . . . . . . . . . . . . .
. Tablets .................................
3 Visite unter Prozessaspekten 17
. InnereMedizin.............................
. Notaufnahme..............................
. Orthopädie...............................
. Chirurgie................................
. Zusammenfassung...........................
4 Anforderungsanalyse 29
. Anforderungen an den Laufzettel . . . . . . . . . . . . . . . . . . .
. Anforderungen an die Hardware . . . . . . . . . . . . . . . . . . .
. Daten..................................
.. Zugriffe ............................
. Szenarien................................
. Zusammenfassung...........................
5 Entwurf 37
. Informationsarchitektur . . . . . . . . . . . . . . . . . . . . . . . .
. Navigationskonzept . . . . . . . . . . . . . . . . . . . . . . . . . .
. Screens .................................
.. Stationsschirm.........................
.. Aufgaben erstellen und anzeigen . . . . . . . . . . . . . . .
.. Navigationsleiste . . . . . . . . . . . . . . . . . . . . . . . .
i
Inhaltsverzeichnis
.. Patientenschirm . . . . . . . . . . . . . . . . . . . . . . . .
. Styleguide: Piktogramme, Farben und visueller Stil . . . . . . . . . .
.. Typographie & Raster . . . . . . . . . . . . . . . . . . . . .
.. Farben.............................
.. Piktogramme .........................
. Zusammenfassung...........................
6 Implementierung 53
. Model..................................
.. ER-Modell...........................
. View...................................
.. MDTextModuleListControl . . . . . . . . . . . . . . . . . .
. Controller................................
.. LoginViewController . . . . . . . . . . . . . . . . . . . . .
.. OverViewController . . . . . . . . . . . . . . . . . . . . . .
.. PatientViewController . . . . . . . . . . . . . . . . . . . . .
.. NewTaskViewController . . . . . . . . . . . . . . . . . . .
.. TaskViewController . . . . . . . . . . . . . . . . . . . . . .
.. MDPortraitSplitViewController . . . . . . . . . . . . . . . .
. Workowunterstützung im System . . . . . . . . . . . . . . . . . .
.. XML-Datei...........................
.. MDProcessManager . . . . . . . . . . . . . . . . . . . . . .
. Zusammenfassung...........................
7 Evaluierung 83
. Ablauf..................................
.. Erster Teil des Interviews . . . . . . . . . . . . . . . . . . .
.. Usability-Test . . . . . . . . . . . . . . . . . . . . . . . . .
.. Zweiter Teil des Interview . . . . . . . . . . . . . . . . . . .
. Ergebnisse ...............................
.. Erkenntnisse aus dem Usability-Test . . . . . . . . . . . . .
.. Ergebnisse aus den geschlossenen Fragen . . . . . . . . . .
.. Ergebnisse des freien Teils des Interviews . . . . . . . . . .
. Diskussion ...............................
8 Fazit 91
. Ausblick ................................
. Schlusswort...............................
ii
1
Einleitung
Ein Aufenthalt im Krankenhaus ist für Patienten anfangs ein Schock. Darauf folgt
das Gefühl von Kontrollverlust: Der Patient als Laie versteht vieles von dem nicht,
was um ihn herum passiert. Um dem entgegenzuwirken, braucht der Patient einen
kompetenten Gesprächspartner.
Patientengespräche dienen damit nicht nur der Diagnostik, sondern fungieren –
wenn sie mit entsprechender Sorgfalt als Arbeitsethos im Krankenhaus gepegt wer-
den – auch als erapeutikum. Denn die „Wiederherstellung von Verstehbarkeit,
Bewältigung, Bedeutsamkeit ist ein zentraler gesundheitsfördernder Faktor.“ [,
S. ]. Ein Patient, der seine Leiden, deren Ursachen und erapiemöglichkeiten
kennt, ist das Idealbild des selbstständigen und mündigen Patienten []. Es obliegt
den Ärzt/inn/en und ihren Kommunikationsfähigkeiten, den Patienten so zu infor-
mieren, dass dieser kompetent beraten wird. Ein informierter Patient kann besser
mit der ungewohnten Situation des Krankenhausaufenthaltes umgehen.
Um diese Patientenkommunikation zu gewährleisten, werden in den meisten Sta-
tionen zweimal am Tag Visiten durchgeführt. Dabei gehen Ärzt/innen/e zusammen
mit dem Pegepersonal von Patient zu Patient und besprechen mit ihnen den aktu-
ellen Stand, eventuelle Untersuchungsergebnisse und das weitere Vorgehen.
Bereits im . Jahrhundert wurden Visiten dieser Art populär []. Zur dama-
ligen Zeit gab es keine Untersuchungsergebnisse, die zur Visite mitgeführt werden
konnten. Mit dem Voranschreiten der Wissenscha und Technik standen allerdings
immer mehr Daten und Informationen über Patienten zur Verfügung. Diese Daten
sollten natürlich während der Visite ebenfalls zur Verfügung stehen. Dazu wurde
früher ein mit Patientenakten bestückter Visitenwagen eingesetzt.
Heutzutage wird verstärkt versucht, Patientendaten digital zu halten. So sollen
Kosten und Zeit gespart werden. Kosten können durch Ausschluß von Doppelun-
tersuchungen und Fehlbefundungen, aufgrund von fehlenden Informationen, ein-
gespart werden []. Dadurch, dass Daten sofort digital verfügbar sind, spielen Ver-
sandzeiten von Dokumenten in der Hauspost keine Rolle mehr. Die Kommunikation
via E-Mail ist beispielsweise in vielen Krankenhäusern mittlerweile üblich.
Patientenakten setzen sich aus Informationen aus verschiedenen Quellen, wie
Röntgenstationen und externen Ärzt/inn/en, zusammen. Meist sind nicht alle Ein-
1
Kapitel 1 Einleitung
zelkomponenten umgestellt sind, weswegen o trotzdem noch Papierakten existie-
ren. Viele Stationen und Kliniken benden sich in einem Stadium zwischen analoger
und digitaler Patientenakte.
Aus diesem Grund muss auch bei der Visite umgedacht werden. Beispielsweise
werden relevante Elemente der Akte ausgedruckt und mitgenommen. Eine ande-
re Lösung besteht darin, den Visitenwagen mit einem Laptop auszurüsten oder ei-
nen Tablet-Computer mit auf Visite zu nehmen. Diese Techniken gehören zu den
Inhalten der mobilen Visite: Im einfachsten Fall wird es dem Arzt oder der Ärztin er-
möglicht, mithilfe eines mobilen Endgeräts auf das Krankenhausinformationssystem
(KIS) zuzugreifen. In der Realität ist die Umsetzung allerdings aufgrund verschiede-
ner Altsysteme, inkompatiblen Schnittstellen und Kostenbedenken kompliziert und
in wenigen Krankenhäusern anzutreffen.
Aus der Visite ergeben sich viele Aufgaben, wie Untersuchungsanforderungen und
erapiemaßnahmen. Da diese Aufgaben allerdings o verlangen, dass Formula-
re ausgefüllt werden, können sie meist nicht direkt am Patientenbett erledigt wer-
den. Stattdessen notieren entweder die anordnenden Ärzt/innen/e oder Assistenz-
ärzt/innen/e die Aufgaben auf einem Papierblatt.
Zwischen dem papierbasierten Aufgabenmanagement auf der einen und der Di-
gitalisierung der desktopgebundenen Patientenakte auf der anderen Seite entwickelt
sich ein Bruch: Aufgaben werden durch Medienwechsel fehleranfällig und sind nicht
nachverfolgbar.
Prozesse in der Klinikumgebung sind o nicht formal erfasst, und damit weder
überprüar, noch können sie optimiert werden. So sind Workow-Management-
System (WfMS) ebenfalls nicht weit verbreitet. Insbesondere sind Prozesse, die bei
der Diagnose und erapie des Patienten eine Rolle spielen, dynamisch [] und
stellen somit eine Herausforderung an die technische Prozessunterstützung (Work-
ows) dar.
MEDo (MedicalDo), das einerseits Aufgaben digital verwaltet und andererseits Pa-
tientendaten anzeigt, kann diesen Bruch überwinden. Gleichzeitig werden durch die
Einbindung von Prozessen in die digitale Arbeitsverwaltung potenziell Fehlerquellen
ausgeschlossen, Prozesszeiten verbessert und Statusabfragen ermöglicht. Der Schlüs-
sel dabei liegt darin, dass die Applikation auf einem Tablet entwickelt wird und somit
mobil während der Visite mitgenommen werden kann.
1.1 Ziel
Das Ziel dieser Diplomarbeit ist herauszuarbeiten, wie während der Visite durch mo-
bile Prozessunterstützung Arbeit und Zeit gespart werden können. Es soll ein Proto-
typ enwickelt und von Ärzt/inn/en evaluiert werden.
Um entscheiden zu können, wo die Unterstützung anzusetzen ist, sollen mehre-
re Visiten beobachtet und aus Sicht des Prozessmanagements analysiert werden. Im
2
1.2 Entwicklungsschritte
Anschluß daran soll ausgewertet werden, ob und wie Prozesse bei der Visite unter-
stützt werden können. Es ist außerdem zu überprüfen, an welchen Punkten dort eine
mobile Unterstützung einen Gewinn bieten kann.
Das bisher rein papierbasierte und informelle Aufgabenmangement soll durch ein
mobiles System unterstützt werden. Dabei sollen die Peripherieprozesse, die im ers-
ten Teilziel identiziert wurden, durch Workows nachverfolgbar unterstützt wer-
den. Patienteninformationen müssen ebenfalls erreichbar sein. Dabei sollen die Ar-
beitsweisen der Ärzte auf dem mobilen Gerät weiterhin unterstützt werden. Das Sys-
tem ist als Prototyp auf einem iPad zu entwickeln.
Großes Augenmerk soll dabei auf die Gestaltung der Benutzerschnittstelle gelegt
werden, da diese entscheidend für die Akzeptanz der Benutzer ist. Der Prototyp soll
schließlich evaluiert werden, um zu überprüfen, ob und wie eine solche Hilfe von
den Ärzten angenommen wird.
1.2 Entwicklungsschritte
Durch die Ungewissheit, wie das System letztendlich eingesetzt wird und die Fokus-
sierung auf das Benutzerinterface, habe ich mich für einen Ansatz nach dem explo-
ratory prototyping [] entschieden. Auf die Anwendung eines kompletten Soware-
Entwicklungsmodells wurde in Anbetracht des Prototypcharakters verzichtet. Statt-
dessen sind Techniken aus dem Gebiet des Agile Modelling zum Einsatz gekommen.
Dementsprechend habe ich die Entwicklung entlang des UI prototyping process []
geplant, der in Abbildung . auf der nächsten Seite zu sehen ist.
Im Folgenden soll nun der Verlauf der Arbeit, der in Abbildung . grasch dar-
gestellt ist, erklärt werden.
Problemfelder spezi sche Probleme
& Lösungsideen
Anforderungen Entwurf
& Styleguide
Prototyp Anregungen
& Kritik
Papiermockups
Benutzerfeedback
Detailentwürfe
Entwicklung eines
Konzepts
Anforderungen
ausarbeiten
Beobachtung
Erstellung von
Prozessmodellen
Analyse der
Prozesse
Recherche
Literatur
Interviews
Frameworkvor-
gaben
Programmierung
der Applikation
Interviews
Usability-Tests
Grundlagen
Visite unter
Prozess-
aspekten
Anforderungs-
analyse Entwurf Implemen-
tierung Evaluierung Fazit
Abbildung .: Übersicht über den Auau der Arbeit
Um mit dem Prototypen auch die aktuellen und eingespielten Vorgehensweisen
der Ärzte zu unterstützen, führte ich zu Beginn intensive Beobachtungen der Ar-
Peripherieprozesse: Prozesse, die an den Ablauf der Visite angeschlossen sind.
3
Kapitel 1 Einleitung
beitsweise bei der Visite durch. Die entstandenen Erkenntnisse wurden in darauffol-
genden Interviews hinterfragt und veriziert. Um die Gemeinsamkeiten herauszu-
arbeiten, wurden Prozessmodelle aller beobachteten Visiten angefertigt. Die Analyse
ergab, dass wegen der Komplexität und Dynamik nicht die gesamte Visite durch ein
Modell abgedeckt und unterstützt werden kann.
Abbildung .: UI prototyping
process
Wohl aber ließen sich Teilprozesse erkennen, die durch die richtige Un-
terstützung den Arbeitsuss erleichtern. Aus den Beobachtungen und
Prozessen wurden schließlich Anforderungen an das System abgeleitet
und durch Gespräche mit Ärzt/inn/en abgesichert.
Die Entwurfsphase begann mit der Entscheidung für die Entwick-
lung auf einem iPad. Dadurch wurde zum einen die verfügbare Größe
für die Benutzerschnittstelle festgelegt, zum anderen gibt die Entschei-
dung für eine Plattform auch Designguidelines wie die iOS Human In-
terface Guidelines [] vor. Nach der Festlegung der benötigten Daten
habe ich mithilfe von vielen, möglichst verschiedenen Papierprototy-
pen ein nales Konzept erstellt. Dies wurde anschließend in Objective-
C programmiert.
Den entstandenen Prototyp habe ich schließlich zusammen mit
Ärzt/innen/e evaluiert. Die im Verlauf dieser Auswertung herausgear-
beiteten Anregungen und Kritikpunkte werden im Ausblick vorgestellt.
4
2
Grundlagen
Dieses Kapitel soll die Grundlagen zum Verstehen des Kerns dieser Arbeit schaffen.
Dazu werden die Begriffe „Visite“ und „Laufzettel“ deniert, sowie das Aufgabenma-
nagement in diesem Kontext. Es wird außerdem das Prozessmanagement und dessen
Anwendung im Klinikumfeld besprochen und eine Einführung in die ematik der
Tablets gegeben.
2.1 Visite im Krankenhaus
Visiten sind „in der Regel die einzigen Zeitpunkte, an denen ein Team mit den Pa-
tienten zusammenkommt, und sich über den aktuellen Stand der Versorgung und
Genesung des Patienten und damit über den Stand der ‚primary task‘ Patientenver-
sorgung informiert und austauscht“ []. Sie werden ausserdem durchgeführt, da-
mit bei der Schichtübergabe Informationen weitergeben werden können und so das
nächste Team nahtlos weiterarbeiten kann. Weiterhin besteht auch von Seiten der
Chefärzte/innen und Stationsleit/er/innen einen Überblick über die Stationen, für
die sie verantwortlich sind, zu bekommen. Sie führen meistens einmal pro Woche
eine eigene Visite durch. Es gibt also im Verlauf der Woche Visiten mit unterschied-
lichen Zielsetzungen.
Ebenso gibt es von Seiten der Patienten Motive für die Visite. Sie bekommen durch
den direkten Kontakt regelmäßig die neuesten Informationen über ihren Genesungs-
verlauf. Außerdem werden sie über Abläufe, die geplanten Untersuchungen und e-
rapiemaßnahmen aufgeklärt und haben die Möglichkeit Fragen zu stellen.
Obwohl die Motive hinter den Visiten ähnlich sind, führt sie doch jede Station
anders durch. Der Ablaufist abhängig vonderArtderStation,denAnforderungenan
die Visite (Schichtübergabe, tägliches Bild), der Liegezeit und Anzahl der Patienten
und den Präferenzen der Oberärzt/innen/e.
Während der Visite machen sich die Ärzt/innen/e ein Bild vom Krankheits- und
Genesungsverlauf des Patienten. Daraus entstehen nach Absprache Entscheidun-
gen über den Behandlungsplan []. Dazu ziehen die beteiligten Ärzt/innen/e ver-
schiedene Informationsquellen zu Rate: Neben der physischen Untersuchung bei-
spielsweise von Wunden und Verletzungen, werden Untersuchungsergebnisse aus
5
Kapitel 2 Grundlagen
der bildgebenden Diagnostik und Laborbefunde hinzugezogen. Genauso wichtig
sind die Gespräche mit den Patienten sowie die Eindrücke und die Beobachtungen
des Pegepersonals. Aus diesen Informationen ergeben sich die nächsten erapie-
schritte und Untersuchungen.
Abbildung .: Mappen für die Pegedoku-
mentation []
Bei der Visite wird meist die Pegedokumentation mitge-
nommen (siehe Abbildung .). Dabei handelt es sich um ei-
ne Sammlung von verschiedenen Dokumenten, die in der Ge-
samtheit alle Informationen über den Pegeprozess ergeben.
Sie enthält die Patientenkurve, in der verschiedene Vitaldaten
des Patienten wie Herzfrequenz, Blutdruck und Körpertem-
peratur dokumentiert werden. Ebenso wird in der Pegedo-
kumentation die Medikation protokolliert und geplant. Ärzt/
innen/e setzen diese fest und zeichnen dies und Änderungen
ab. Ziel ist, dass Änderungen an der Medikation nachvollzieh-
bar sind.
In der Regel lassen sich Visiten in die folgenden vier Phasen
einteilen []:
Vorbereitung Im Vorfeld der Visite stellen alle Ärzte die relevanten Informationen
über ihre Patienten zusammen. Beispielsweise drucken sie Röntgenbilder aus
oder legen die Pegedokumentation bereit.
Visite Ante Portas Vor Betreten eines jeden Patientenzimmers stellt einer der Ärzte
den Patienten den anderen Teilnehmern der Visite vor. Gegebenenfalls werden
bereits erste Anordnungen gegeben.
Visite im Patientenzimmer Nach einer eventuellen physischen Untersuchung des Pa-
tienten werden ihm nun die Befunde und der weitere Behandlungsplan erläu-
tert; Untersuchungen und erapiemaßnahmen werden geplant.
Nachbereitung Nach dem die beiden vorangegangenen Punkte für jeden Patienten
wiederholt wurden, werden Pläne für den weiteren Verlauf abgearbeitet, also
beispielsweise Untersuchungsanordungen ausgearbeitet, unterschrieben und
vergeschickt.
Früher wurden bei den Visiten sogenannte Visitenwägen eingesetzt. Diese Wägen
bestückte man vor jeder Visite mit den entsprechenden Patientenakten. Während der
Visite kümmerte sich eine Ärztin/ein Arzt darum, die benötigtn Akte herauszusu-
chen und zu verteilen. Mittlerweile kommt diese Art der Visite immer seltener zum
Einsatz, da die Daten elektronisch gespeichert werden. Die meisten Krankenhäuser
sind schon so weit digital integriert, dass Röntgenbilder und Laborbefunde primär
digital einsehbar sind.
Daraus ergibt sich, dass der vorrangige Zugriff auf diese Daten durch ein desktop-
gebundes Krankenhausinformationssystem (KIS) geschieht. Manche Stationen ver-
wenden einen digitalen Visitenwagen, der, durch einen darauf angebrachten Laptop
6
2.2 Prozessmanagement
oder Desktop-Rechner, auch während der Visite Zugriff auf die Daten erlaubt. Eine
Alternative wäre zum einen, die Visite vorzubereiten und relevante Teile der Pati-
entenakte wie zum Beispiel Röntgenaufnahmen oder Laborbefunde auszudrucken
und mitzunehmen. Zum anderen kann die Visite in „Datensichtung am Desktop-
PC“ und „Patientengespräch am Bett“ geteilt werden. Wenn kein Patientenkontakt
bei der Visite zustande kommt, redet man auch von einer Kurvenvisite.
Nach der Visite müssen die angefallenen Aufgaben bearbeitet werden. Dabei muss
viel Zeit (etwa , bis , [, S. ], bzw. ca. Stunden pro Tag []) für die Do-
kumentation der Maßnahmen, Befunde und Untersuchungen aufgewendet werden.
Ständige Unterbrechungen wie Telefonanrufe machen es den Ärzt/innen/e schwer,
sich durchgängig auf die Visite zu konzentrieren. Abhängig von der Länge der Visite
und der Anzahl der Teilnehmer erhöht sich die Wahrscheinlichkeit einer Unterbre-
chung.
Für eine patientenzentrierte Visite ist die Verfügbarkeit möglichst aller Patienten-
daten am Bett erforderlich. Da dies wegen desktopgebundenen, digitalen Patienten-
akten nicht gegeben ist, gibt es Entwicklungen, die sich unter dem Begriff mobile
Visite zusammenfassen lassen [, , ]. Diese umfasst mobile Clients, wie Visiten-
wägen mit Desktop-PCs oder Notebooks und erste Tablet-Lösungen. Meist ist die
verwendete Soware nicht speziell an die Möglichkeiten und Beschränkungen der
Hardwareplattform angepasst. Gerade bei Tablets, die mittels direkter Manipulation
auf einem berührungsempndlichen Bildschirm gesteuert werden, ist aber die An-
passung sehr wichtig.
Trotz der Entwicklungen in Richtung einer volldigitalen Patientenakte [] grei-
fen Ärzt/innen/e auf einfache Laufzettel zur Aufgabenverwaltung zurück. Ein Lauf-
zettel ist eine Art handschrilich geführte Arbeitsliste, auf der Aufgaben vermerkt
und nach der Durchführung gestrichen werden. Die Aufgaben werden hauptsäch-
lich während der Visite erfasst und im weiteren Verlauf des Tages erledigt. Somit ist
dieses Papier die zentrale Anlaufstelle für alle Ärzte einer Station, um zu erfassen,
was die Aufgaben des Tages sind.
2.2 Prozessmanagement
Der Begriff „Prozess“ beschreibt einen Ablauf von Bearbeitungsschritten [, S. ].
Er grenzt sich von einem Projekt dadurch ab, dass ein Prozess wiederholt wird. Er
ist als ein Plan zu verstehen – erst wenn er ausgeführt wird, spricht man von einer
Prozessinstanz. Prozesse werden von Georgakopoulos u. a. [] in drei Kategorien
eingeteilt:
Materielle Prozesse bezeichnen Vorgänge bei denen am Ende ein Produkt steht. Das
bedeutet auch, dass die meisten Aufgaben von Personen physisch ausgeführt
werden.
7
Kapitel 2 Grundlagen
Informationsprozesse sind teil- sowie komplett automatisierte Abläufe, bei denen
Personen die Aufgaben am Computer ausführen. Basis dafür sind Technolo-
gien wie Datenbanken, Transaktionsabwicklung und verteilte Systeme.
Geschäsprozesse bezeichnen Vertriebsvorgänge in Organisation, die sich meist aus
den oben genannten materiellen und Informationsprozessen zusammenset-
zen.
Workows beschreiben die operativ-technischen Schritte, die für die Ausführung
eines Geschäsprozesses nötig sind. Der Unterschied zu Geschäsprozessen ist da-
mit die Eindeutigkeit der Aufgabenschritte, die zur Ausführung nötig ist. Insbeson-
dere spezizieren Workows die Mensch-Maschine-Interaktion mit dem System. Es
existieren formale Beschreibungssprachen [] für Workows, welche die Ausfüh-
rung durch ein Computersystem, ein sogenanntes Workow-Management-System
(WfMS), unterstützen.
Anstatt Aufgaben einzelnen Personen zuzuweisen, werden Benutzerrollen zur
Abstraktion eingesetzt. Eine Rolle beschreibt dabei gemeinsame Eigenschaen und
Rechte von Benutzern. So kann leichter mit Personalveränderungen umgegangen
werden.
In einer sogenannten Arbeitsliste bekommen Benutzer eines WfMS anstehende
Aufgaben angezeigt. Sie listet alle Aufgaben, die für die Rolle des angemeldeten Be-
nutzers zur Verfügung stehen, auf. Um die Bearbeitung zu beginnen, wählt er eine
aus, markiert sie als „in Bearbeitung“ und beginnt dann den Arbeitsschritt auszu-
führen. Hat er die Aufgabe abgeschlossen, markiert er sie als erledigt.
Zur Darstellung von Geschäsprozessen und Workows gibt es verschiedene For-
malismen, wie beispielsweise die Business Process Modeling Notation (BPMN) [,
], Ereignisgesteuerte Prozessketten (EPK) [, ], Petri-Netze [, , ] oder
Flussdiagramme [, ]. Besonders hervorzuheben ist dabei BPMN: Ein von der
Object Management Group (OMG) verabschiedeter Standard, welcher sowohl für
die Business-Seite (Geschäsprozesse), als auch die IT-Seite (Workows) eine ein-
heitliche Symbolpalette bietet [, ]. Abbildung . zeigt einen einfachen Prozess
in BPMN.
Abbildung .: Ein Prozessbeispiel in BPM-Notation. Nach dem Startereignis (event) am lin-
ken Bildrand folgt eine Aktivität (activity), verbunden durch eine Kante. Danach steht eine
datenabhängige Entscheidung (gateway) an. Durch den kleinen Rhombus an dessen unterer
Kante wird der Standardfall gekennzeichnet. Das Plussymbol kennzeichnet einen Subprozess
und der kräigere Kreis das Endereignis.
8
2.2 Prozessmanagement
Um die Übersichtlichkeit bei der Darstellung zu verbessern, werden o Subpro-
zesse eingesetzt, die Verhalten und Abläufe ausblenden. Auf diese Weise kann ein
Prozess, beispielsweise für das Management, abstrahiert dargestellt werden. Für die
genauere Ausführung müssen die Prozessschritte weiter verfeinert werden.
Die Gründe eines Unternehmens, die eigenen Prozesse zu optimieren, sind vielfäl-
tig: Sei es die Effizienz bei der Produktionerhöhen, Kundenzufriedenheit verbessern,
Qualität von Produkten respektive Services steigern oder Kosten reduzieren.
Sollen in einem Unternehmen Workows eingesetzt werden, müssen zuerst ge-
naue Ziele für die Optimierung deniert werden. Danach werden Prozesse identi-
ziert und modelliert. Aufgrund dieser Beschreibung aus Geschässicht wird nun ein
Workow modelliert, der den Prozess um Details verfeinert. Anschließend wird der
Workow implementiert, also in einem WfMS zur Ausführung gebracht. Schließlich
muss der Prozess beobachtet werden, um die daraus gewonnenen Daten mit den
Zielen vergleichen zu können. Ausgehend von diesen Ergebnissen, sind nun weite-
re Änderungen am Prozessmodell möglich []. Diese Vorgehensweise wird process
management lifecycle genannt (siehe Abbildung .).
Abbildung .: Process mangagement lifecycle
Die Einführung von Prozessen und insbesondere von WfMS in Unternehmen ist
o nicht einfach. Zum einen sind technische Hürden zu überwinden, zum anderen
müssen die Mitarbeiter eingebunden werden. Dies kann schwierig sein, da mögli-
che Konsequenzen von Prozessoptimierungen Verringerung von menschlichen Ak-
tivitäten – und damit Entlassungen – sein können. Es ist deshalb wichtig, dass „die
Bereitscha und das Verständnis der Prozessbeteiligten, die neuenStrukturen zu ver-
stehen, zu akzeptieren und umzusetzen,“ [, S. ] gestärkt wird.
2.2.1 IT-Unterstützung im Krankenhaus
Im Krankenhaus sind zwei Kategorien von Prozessen zu unterscheiden. Zum einen
sind Geschäsprozesse vorzunden, die Vorgänge wie Abrechnungen, Dokumenta-
tion und Urlaubsanträge abdecken. Dies sind Vorgänge, die es auch in jeder anderen
Organisation gibt. Sie können unproblematisch mithilfe von WfMS unterstützt wer-
den.
Zum anderen existieren Prozesse, bei denen der Patient und dessen erapie
im Vordergrund steht. Die prozesstechnische Unterstützung ist hier noch am An-
fang []. Beispielsweise sollen Decision Support Systems (DSS) Ärzt/inn/en bei der
9
Kapitel 2 Grundlagen
Suche nach Entscheidungen unterstützen []. Entscheidungen müssen aufgrund
von Daten, beispielsweise Laborwerten oder CT-Aufnahmen, anhand des spezi-
schen medizinischen Wissens der Ärzt/innen/e und unter Beachtung des aktuellen
Zustands des Patienten getroffen werden. Die Anzahl dieser Faktoren machen es im
Einzelfall schwer, die richtige Entscheidung zu treffen. DSS könnten beispielsweise
den aktuellen Fall automatisch mit anderen, ähnlichen Fällen unter Beachtung der
oben genannten Faktoren vergleichen, um so den Ärzt/inn/en Vorschläge zu unter-
breiten. Dazu müssen existierende medizinische Leitfäden maschineninterpretierbar
auereitet werden und an Patienteninformationen angebunden werden.
Diese werden im Krankenhaus im Patientendatenbankmanagementsystem (PD-
MS) gespeichert. Zusammen mit Kommunikations- und Workow-Funktionen bil-
det es das Krankenhausinformationssystem (KIS) []. Solche Sowareprodukte ver-
sprechen, alle Daten der Patienten einheitlich in einem System zu speichern.
Diese Vision konnte bisher nicht in die Praxis umsetzt werden. Viele Systeme, wie
beispielsweise Röntgenabteilungen oder Labore, sind weiterhin nicht in das Gesamt-
system integriert. Die Daten sind in heterogenen Systemen verteilt, nur die funkti-
onsbezogenene Zugriffe ermöglichen. Sie sind meist für die Organisationseinheiten
ausgerichtet, in denen sie eingesetzt werden (Röntgenabteilung, Labor, Innere Me-
dizin etc.).
So kann keine ausreichende Unterstützung von bereichsübergreifenden Prozess-
abläufen, die den Patienten im Fokus haben, stattnden []. Diese Heterogenität der
Systeme im Krankenhaus zu überwinden, ist eine Hauptaufgabe der medizinischen
IT in der Zukun [].
In den Fokus der Öffentlichkeit rückt die krankenhausübergreifende elektronische
Patientenakten (EPA) in Deutschland in Form der elektronische Gesundheitskarte
(EGK) []. Sie soll die die zentrale Speicherung medizinischer Daten ermöglichen,
bei der die Karte als Schlüssel zu diesen Daten dient. Man verspricht sich durch die
einheitliche Führung einer elektronischen Akte pro Bürger Qualitätsverbesserungen,
Rationalisierungen, bessere Wirtschalichkeit und die Stärkung der Patientenauto-
nomie [].
Nachdem die Einführung jahrelang aufgrund von technischen Problemen und
dem Protest vieler Ärzte verzögert wurde [], wird die EGK seit dem . Okto-
ber als Versichertenkarte anerkannt. Noch sind allerdings keine der geplan-
ten Funktionen, die einen Austausch von Informationen ermöglichen, implemen-
tiert []. Insbesondere der Datensicherheit misstrauen viele Versicherte [].
2.3 Laufzettel als Pivot-Element der Visite
Anstehende Behandlungs- und Untersuchungsschritte müssen zeitversetzt und über
den Rest des Tages verteilt ausgeführt werden. Ein ständiger Begleiter der Ärzt/
innen/e ist somit ein Laufzettel, der während der Visite ausgefüllt und im Laufe des
10
2.3 Laufzettel als Pivot-Element der Visite
Tages abgearbeitet wird. Um sich an anstehende Aufgaben zu erinnern, reicht es
Patientenname und Text aufzuschreiben. Sobald eine Aufgabe durchgeführt wurde,
wird die entsprechende Zeile durchgestrichen.
Im Folgenden ein Auszug der Einträge, die auf Laufzetteln notiert werden:
• Erinnerungen an Rücksprachen mit Ober- oder Chefärzt/inn/en.
• Bei externen Ärzt/inn/en per Telefon nach Konsilen fragen und ob bereits Ergeb-
nisse bzw. Rückmeldung vorhanden sind.
• Überprüfen, ob Ergebnisse von Untersuchungen eingetroffen sind.
• Erinnerungen, den Patienten in Richtung einer vermuteten Krankheit zu untersu-
chen.
• Planung der durchzuführenden Konsile.
• Langzeiterinnerungen (Beispiel: Sobald ein Patient von MRSA geheilt ist, soll er
einer Röntgenuntersuchung unterzogen werden)
Manche Aktivitäten, wie beispielsweise die Anforderung einer Röntgenuntersu-
chung sind schnell erledigt. Teilweise besteht die Möglichkeit, dies während der Visi-
te, mithilfe eines Tablets abzuschließen. Andere Aufgaben, wie die Rücksprache mit
Ober- oder Chefärzt/inn/en oder das Warten auf Ergebnisse eines Konsils können
sich über mehrere Tage erstrecken. Noch langlebiger sind Erinnerungseinträge, wie
eine Untersuchung, die erst möglich ist, nachdem der Patient eine noch bestehende
Krankheit überwunden hat.
Die meisten Eintragungen werden während der Visite, also unter Zeitdruck, er-
stellt. Auf Papier kann der Benutzer jede Möglichkeit nutzen, Zeit zu sparen. Er
kann sehr schnell schreiben, Einträge kennzeichnen, Pfeile und Verbindungsstriche
zwischen Einträgen zeichnen und als wichtigstes Element: Details auslassen. Die-
se Nicht-Spezizierung macht Sti und Papier zu einem hocheffizienten Werkzeug.
Elektronische Werkzeuge fordern vom Benutzer spezisch zu sein und sich festzule-
gen.
Teilweise nutzen Stationsärzt/innen/e auf einer Station eine gemeinsame Arbeits-
liste. In diesem Falle liegt sie im Dienstzimmer aus. Hat einer der Ärzt/innen/e etwas
freie Zeit, kann er ausgehend von den noch offenen Aktivitäten, die nächste Aufgabe
in Angriff nehmen.
2.3.1 Probleme des Papier-Laufzettels
Handschrilich geführte Laufzettel können zwar exibel eingesetzt werden, sind al-
lerdings mit Mängeln hinsichtlich der weiteren Benutzung, wie Wartung und Abar-
beitung, belegt.
So bedeutet die Nutzung eines handschrilichen Laufzettels, dass mindestens
zweimal ein Wechsel zwischen Medien erfolgen muss. Zum einen bei der Erfas-
sung, zum anderen bei der Ausführung. Der erste Wechsel ist besonders dann kri-
tisch, wenn eine andere Person mitschreibt, beispielsweise Assistenzärzt/innen/e
11
Kapitel 2 Grundlagen
für Oberärzt/innen/e. Der zweite Wechsel stellt ein Problem dar, wenn zwischen
Aufgabenerstellung und Ausführung merklich Zeit vergangen ist oder nicht der
Aufgabenersteller selbst die Aufgabe ausführt. Hier können Informationen verloren
gehen.
Ist das Ende einer Schicht oder eines Tages erreicht, wird der Laufzettel von einer
Ärztin/einem Arzt ins Reine geschrieben, also nicht bearbeitete Einträge auf eine
neue Seite übertragen. Dies scha einen sauberen Ausgangspunkt für den nächsten
Tag, ist aber zeitaufwendig.
Weiterhin liegt der Laufzettel meist zentral im Dienstzimmer der Ärzte und ist
damit nicht erreichbar für Ärzte, die beispielsweise in der Notaufnahme Dienst ha-
ben. Diese können dadurch freie Zeiten nicht nutzen, um z.B. Telefonate zu führen.
So müssen die Ärzt/innen/e immer wieder zurück ins Dienstzimmer gehen, um zu
sehen, welche Aufgaben noch offen sind.
Handschriliche Notizen bergen zudem die Gefahr der Unleserlichkeit. Dies stört
besonders dann, wenn mehrere Personen zusammen einen Laufzettel bearbeiten.
Falsch verstandene Informationen oder missverständliche Anweisungen erschweren
die Zusammenarbeit mit anderen an einem Dokument zusätzlich.
Ohne Archivierung der Aufgaben ist keine Rückverfolgung möglich. Interessant
dabei ist, welche Person wann welche Aufgabe ausgeführt hat. Besonders bei Proble-
men oder Unklarheiten ist die Rückverfolgung von Arbeitsschritten sinnvoll. Aber
auch bei der täglichen Arbeit ist es wichtig zu erfahren, ob eine Aufgabe bereits erfüllt
wurde.
2.3.2 Vorteile eines digitalen Laufzettels
Abbildung .: Applikation Erin-
nerungen. Bestandteil von iOS
Durch die Entwicklung der Krankenhausinformationsstruktur lässt sich
ableiten, dass die Entwicklung in Richtung der elektronischen Akten
geht. In absehbarer Zeit wird die gesamte Patientenakte in elektroni-
scher Form geführt. Dazu sind neue Konzepte und Paradigmenwechsel
beim Aufgabenmanagement nötig, wie die vorausgegangene Betrach-
tung zeigt.
Überträgt man das Konzept eines Laufzettels auf ein Smartphone,
erhält man zunächst eine To-Do-Listen-Applikation. Auf dem iPho-
ne ist beispielsweise bereits „Erinnerungen“ vorinstalliert (siehe Abbil-
dung .). Im Krankenhauskontext sind allerdings weitere Verbesserun-
gen denkbar.
Beispielsweise könnte ein WfMS zusätzlich in den Laufzettel integriert
werden. Auf diese Weise wären Einträge der Arbeitsliste des WfMS und
normale Aufgaben gemischt. Die Benutzer könnten auf diese Weise ih-
re bisherige Arbeitsweise mit einem Laufzettel weiternutzen. Gleichzei-
tig können die Vorteile eines Prozesssystems genutzt werden. Es könn-
ten Merkmale und Richtwerte, wie Zeiten oder Fehler erhoben werden.
12
2.4 Tablets
Durch gezielte Änderungen an den Prozessen, sollte dann versucht werden, diese
Werte positiv zu beeinussen.
Durch WfMS sind Ergebnisse und Eingaben eines Anwenders sofort für die nächs-
ten Anwender verfügbar. Ein Beispiel ist der Prozess „Blutuntersuchung“ in Abbil-
dung . auf Seite . Wenn dieser digital unterstützt wird, kann die Pegekra di-
rekt, während sie am Patientenbett steht, darüber informiert werden, dass eine Blut-
untersuchung eines Patienten gewünscht wird. Sobald sie alles vorbereitet hat, be-
stätigt sie den Schritt im System. So wird eine Ärztin/ein Arzt informiert und kann
Blut abnehmen. Sie/Er wird dann wiederum automatisch über den Status der Unter-
suchung informiert, sowie wenn das Ergebnis der Untersuchung verfügbar ist. Auf
diese Weise werden Kommunikationswege verkürzt und die Gefahr, dass Informa-
tionen verloren gehen, wird verringert.
Unerlässlich ist, neben der Prozessunterstützung, auch die Integration in beste-
hende KIS. So hat der Benutzer nicht nur Aufgaben, sondern auch sofort alle Daten,
die er zur Erledigung braucht, mobil verfügbar.
Insgesamt werden Brüche bei der Übertragung vermieden. Die Daten, wie Ar-
beitslisteneinträge und Untersuchungsergebnisse, bleiben im gleichen System. Ver-
teilte Listen könnten zudem Kollaboration erleichtern.
2.4 Tablets
Im Allgemeinen beschreibt der Begriff „Tablet“ ein auf den Bildschirm reduziertes
digitales Endgerät (siehe Abbildung .). Es wird durch direkte Manipulation, also
Fingerberührungen oder mithilfe eines Stylus, bedient.
(a) Dynabook, [] (b) Toshiba Portege M [] (c) Apple iPad,
Abbildung .: Beispiele für Tablet Computer
Tablet-Computer sind von ihrem Ursprung her nicht prinzipiell auf den Form-
faktor und die speziellen Eigenschaen der heutigen, unter dem Begriff „Tablet“ be-
kannten Geräte beschränkt. Man kann aber sagen, dass die spezielle Wahl der Pro-
dukteigenschaen erst die Popularität und den Gedanken des „Post-PC“ – also des
Geräts, welches die Nachfolge des PCs antritt – gangbar gemacht haben.
13
Kapitel 2 Grundlagen
Die Geschichte von Tablet-Computern beginnt im Xerox Parc mit dem
DynaBook [] (siehe Abbildung .a auf der vorherigen Seite). Dieses Konzept hat
zwar eine physische Tastatur, ist aber vom Formfaktor und der Benutzung (inklusive
e-Books) ähnlich.
Nach Weiser [] sind Tablets ein Teil des Konzept des ubiquitous computing, bei
dem Computer allgegenwärtig sind und in den Hintergrund treten:
„Ubiquitous computing names the third wave in computing, just now
beginning. First were mainframes, each shared by lots of people. Now
we are in the personal computing era, person and machine staring un-
easily at each other across the desktop. Next comes ubiquitous compu-
ting, or the age of calm technology, when technology recedes into the
background of our lives.“
Abbildung .: Vision des ubiquititären
Computers. Zu sehen sind im Hintergrund
ein board, in den Händen der zwei Per-
sonen im Vordergrund pads und auf dem
Tisch mehrere pads (weiße, kleine Quadra-
te). Quelle: PARC
Dabei sollten Tablets nur ein Formfaktor unter mehreren
sein: Verschiedene Geräte von Post-It- (tabs) über Magazin-
(pads) bis Pinnwandgröße (boards) sollen jeden Einsatzzweck
abdecken (siehe Abbildung .). Es scheint so, als ob sich die-
se Vision bestätigt. Smartphones können als erster Schritt in
diese Richtung gedeutet werden []. Tablets, die sich mit ih-
rer Magazin-Ähnlichkeit zum Lesen und zum Betrachten von
Multimedia-Inhalten anbieten, sind somit der nächste Schritt.
Durch ihre Größe eignen sie sich auch besser zur Texteingabe.
Noch in den fünfziger Jahren waren Computer, wie ENI-
AC, raumgroße industrielle Maschinen. Durch die Anbin-
dung an Oszilloskope als Ausgabegeräte und Tastaturen an-
stelle von Lochkarten wurden sie nach und nach auch für
Laien zugänglicher. Durch die Vernetzung mehrerer Rechner
wurden schließlich die Anwendungen möglich, die wir heute
täglich nutzen. Während bis vor etwa zehn bis zwanzig Jahren
Fortschritte im Computer durch Entwicklung und das Hinzu-
nehmen von Komponenten gemacht wurden, ist es heutzutage
eher so, dass immer mehr Komponenten ausgeblendet werden
(siehe Abbildung . auf der nächsten Seite). Notebooks lassen
durch Wireless Local Area Network (WLAN) das Netzwerk
unsichtbar werden und bei Smartphones und Tablets entfällt
der wahrnehmbare Teil des Computers, womit nur der Bildschirm und damit die
direkte Manipulation als Benutzerschnittstelle bleiben.
In der Klinik sind Tablets gut geeignet, um Eingaben zu tätigen und beispielswei-
se Röntgenbilder zu betrachten. Durch die Größe können auch mehrere Benutzer
ENIAC: Electronic Numerical Integrator and Computer, von der US-Armee eingesetzter Rech-
ner um ballistische Tabellen zu berechnen.
14
2.4 Tablets
Abbildung .: Wahrnehmbare Teile des Computers und deren Entwicklung in Richtung von
Tablets []
zusammen Inhalte betrachten und diese gemeinsam diskutieren. So werden Tablets
zum Beispiel an der Berliner Charité eingesetzt, um Einblick in die virtuelle Patien-
tenakten von Krebspatienten zu geben [, S. ]. Über spezielle Suchlter lassen sich
schnell Patienten mit ähnlichen Diagnosen nden, um so die erapie zu verbessern.
Es wäre auch ein integriertes Diktiergerät denkbar, so dass die Ärzte ihre Noti-
zen sofort am Krankenbett machen können, ohne sich die Informationen bis zum
Dienstzimmer entweder merken oder aufschreiben zu müssen. Genauso wäre es
sinnvoll für die Dokumentation, mit dem Gerät Fotos von Wunden oder Operati-
onsnarben des Patienten machen zu können. Weiterhin wäre die Identikation der
Patienten mittels Barcode am Bett möglich, so dass keine Verwechslungen vorkom-
men können.
Dadurch, dass die Einträge digital vorliegen, können sie archiviert werden. So ha-
ben Ärzt/innen/e jederzeit die Möglichkeit, in der Vergangenheit liegende Untersu-
chungenund erapiemaßnahmenzurückinsGedächtnis zu holen. Hierhelfen auch
Sprachmemos und Aufnahmen mit der integrierten Kamera.
Damit ein Tablet in der Klinik auf Inhalte zugreifen kann, ist es essentiell, dass
die Geräte Zugriff auf die im Krankenhaus eingesetzten Datenmanagementsysteme
haben (siehe Abschnitt . auf Seite ).
Um die Daten zwischen Gerät und System abzugleichen, kann entweder eine
Offline- oder eine Online-Synchronisierung eingesetzt werden. Bei der Offline-Syn-
chronisierung muss das Tablet zum Synchronisieren an einen Host-Rechner ange-
schlossen werden, hat also nicht immer die aktuellen Informationen. Für die Online-
Synchronisierung wird ein aktives Funknetzwerk benötigt. Durch dieses erhält das
Tablet immer die aktuellsten Daten. WLAN ist noch kein Standard im Krankenhaus
sowohl aus Gründen der Gerätesicherheit, die je nach Station zu klären ist, als auch
der Sicherheit der Patientendaten.
15
3
Visite unter Prozessaspekten
Um konkrete Daten über Visiten im Krankenhaus zu erhalten, wurden vier Visiten
auf vier verschiedenen Stationen beobachtet. Diese sind:
• Eine Visite in der Notaufnahme, die ohne Rechnerunterstützung auskommt,
• eine in der inneren Medizin, die aufgeteilt ist in Bearbeitung am Rechner und der
Visite am Patientenbett,
• eine weitere in der Orthopädie, die mit mobiler Tabletunterstützung durchgeführt
wird und
• eine Chefarztvisite auf der Chirurgie.
Das Ziel der Beobachtung war es, die Visiten hinsichtlich der Prozesse zu untersu-
chen. Zu diesem Zweck beoboachtete und protokollierte ich die Visiten passiv. Da-
bei wurden der Ablauf und Zeiten mitgeschrieben. Dazu nutzte ich das Formular in
Anhang A auf Seite . Für jeden Patienten sollte eines dieser Formulare verwendet
werden. Es wurden die verwendeten und benötigten Daten, die beteiligten Perso-
nen, sowie ein kurzer Gesamteindruck mitgeschrieben. Allgemeine Informationen
zur Station sollten im Formular auf auf Seite notiert werden. Bei der Konzeption
dieser beiden Formulare wurde von der klassischen, in vier Phasen eingeteilte Struk-
tur der Visite ausgegangen. Während der Beobachtung stellte sich jedoch heraus, dass
diese Struktur wenn überhaupt, dann nur sehr lose angewandt werden kann. Aus die-
sem Grund wurde auf die Verwendung der Formulare verzichtet und stattdessen frei
protokolliert.
In den folgenden Abschnitten werden die beobachteten Visiten vorgestellt und auf
ihre jeweiligen Besonderheiten eingegangen. Dabei werden die Stationen charakte-
risiert, die Visite beschrieben, um dann schließlich Probleme aufzuführen, die sich
daraus ergeben. Zusätzlich wurden zu allen Stationen Prozessdiagramme erstellt, die
den Ablauf der Visite skizzieren. Die Prozesse in den folgenden Abschnitten sind
in BPMN . modelliert. Sie sollen keine ausführbaren Prozesse darstellen, sondern
dienen der Vergleichbarkeit der Prozesse.
Tabelle . auf Seite zeigt einen Überblick über die betrachteten Stationen. Die
Liegezeiten der Patienten, die Aufgabe der Visite und teilnehmende Rollen sind als
Hauptunterschiede zu erkennen.
17
Kapitel 3 Visite unter Prozessaspekten
Die Visite in der Orthopädie im Universitäts- und Rehabilitationskliniken Ulm
(RKU) ist als Besonderheit herauszuheben, denn hier wird bereits ein Tablet-Com-
puter eingesetzt, um Patientendaten mobil am Bett verfügbar zu haben.
3.1 Innere Medizin
Station
Die betrachtete Station in der inneren Medizin im Universitätsklinikum Ulm behan-
delt hauptsächlich Diabetespatienten. Aus diesem Grund sind Laborbefunde für die
Visite von besonderer Bedeutung. Nur in seltenen Fällen werden Röntgenbilder ge-
braucht.
Wie in der gesamten Universitätsklinik wird auf der innere Medizin ein angepass-
tes SAP-System zur Patientenverwaltung genutzt. Es kann von mehreren Computern
auf der Station darauf zugegriffen werden. Die Patientenakte wird hauptsächlich di-
gital verwaltet, inklusive Entlassungsbriefen, Anforderungen und Untersuchungser-
gebnissen. Nicht digital vorliegende Teile der Patientenakte werden nach der Entlas-
sung des Patienten eingescannt und in das System eingespeist.
Visite
Auf der internistischen Station ist die Visite zweigeteilt: Im Dienstzimmer werden
am Computer die Patienten besprochen. Anschließend teilen sich die Ärzte auf und
besuchen die Patienten in ihren Zimmern (siehe Abbildung . auf Seite ).
Da der Patient während diesem ersten Teil nicht anwesend ist, wird dies o Kur-
venvisite genannt. Die Besprechung am Computer ndet zwischen den beiden Sta-
tionsärzten und zwei Pegekräen statt. Die Meinungen und Beobachtungen der
Pegekräe sind dabei wichtig, da keine Möglichkeit besteht, den Patienten zu fra-
gen. Etwa – der Aussagen sind vom Pegepersonal. Des Weiteren werden die
Daten aus der Pegedokumentation, sowie Befunde und Untersuchungsergebnisse
aus dem KIS herangezogen.
Da diese Gespräche im Dienstzimmer der Ärzte stattnden, nutzen die Ärztinnen
und Ärzte o die Möglichkeit, Telefongespräche zu führen. Diese sind zum Beispiel
nötig, um andere Krankenhäuser nach der dortigen Medikationen eines Patienten
zu fragen, die Meinung einer Chefärztin/eines Chefarztes einzuholen oder Termine
zu vereinbaren oder zu verschieben. Änderungen am Entlassungsbrief aufgrund von
Befunden werden gleich im System vorgenommen. Medikationsänderungen werden
direkt abgezeichnet. Da der Patient nicht anwesend ist, können Ärzte und Pegeper-
sonal sehr viel offener über den Zustand des Patienten diskutieren.
Aufgaben, die nicht sofort erledigt werden können, notieren sich die Ärztinnen
und Ärzte auf persönlichen Laufzetteln. Zusätzlich wird auf dem Computer ein Do-
kument geführt, welches in Tabellenform den Zustand der Station abbildet. Zu je-
dem belegtem Bett werden hier Patientenname, Diagnose, anstehende Untersuchun-
18
3.1 Innere Medizin
Tabelle .: Allgemeine Informationen über die betrachteten Stationen
Innere
Medizin
Notaufnahme Orthopädie (Querschnitt) Chirurgie (Chefvisite)
Krankenhaus Universitäts-
klinikum
Ulm
Universitätsklinikum Ulm RKU Universitätsklinikum Ulm
Betten >
Liegezeiten Tage, Wochen Stunden Wochen, Monate wenige Tage bis zu einem
Monat
Häugkeit der Visite Zweimal
täglich
Dreimal täglich Einmal täglich Einmal in der Woche
Aufgabe der Visite Tägliches Bild Informationsweitergabe
zwischen den Schichten
Tägliches Bild Übersicht und Kontrolle für
den Chefarzt
Beteiligte Rollen
Stationsärzte,
–
Pegekräe
– Stationsärzte, Oberarzt
und eventuell weitere
Spezialisten
Stationsärzte, –
Pegekräe, Sport-, Ergo- und
Physiotherapeut
Chefarzt, Vertretung sowie
Ärzte der jeweiligen besuchten
Station
Zeit pro Patient + , Min Minuten Minuten Minuten
KIS ERP, SAP ERP, SAP MCC, Meierhofer AG ERP, SAP
Daten, mobil verfügbar
Vitaldaten ✓(Pegedoku-
mentation)
✓(Pegedokumentation) ✓(Pegedokumentation) ✓(Pegedokumentation)
Medikation ✓(Pegedoku-
mentation)
✓(Pegedokumentation) ✓(Pegedokumentation) ✓(Pegedokumentation)
Bildgebende Diagnostik 7 7 ✓(Tablet) ✓(ausgedruckt)
Laborbefunde 7 7 ✓(Tablet) ✓(ausgedruckt)
19
Kapitel 3 Visite unter Prozessaspekten
Abbildung .: Prozessmodell Visite in der Inneren Medizin
gen sowie das geplante Entlassungsdatum festgehalten. Je nach Präferenz der Ärzt/
innen/e füllen entweder der Arzt/die Ärztin selber oder der/die Stationssekretär/in
die Anforderung aus.
Im Anschluss besuchen die Ärzt/innen/e die Patienten am Bett. Um Zeit zu spa-
ren, übernimmt jeder der beiden Stationsärzt/innen/e eine Häle der Station. Die
Patienten werden nach ihrem Benden gefragt und ihnen der Behandlungsplan er-
klärt. Dabei werden keine Notizen geführt oder mitgenommen.
Probleme
Dadurch, dass die meisten Aufgaben sofort erledigt werden können, wird Zeit ge-
spart. Fehler und Fehlentscheidungen aufgrund von Zeitabständen zwischen Auf-
gabenerfassung und -bearbeitung werden so unwahrscheinlicher. Allerdings kann
die Meinung der Patienten nicht genutzt werden. Diese Informationen können nur
indirekt durch die Beobachtungen des Pegepersonals einiessen.
Da der Patient erst später besucht wird, kann es zu Diskrepanzen zwischen den
Entscheidungen im Dienstzimmer und der Entscheidung, die die Ärzt/innen/e dem
Patienten mitteilen, kommen. Wird die neue Entscheidung nicht nachträglich doku-
mentiert, handeln die Pegekräe möglicherweise noch nach der alten Anweisung.
Ein weiteres Problem ist, dass zwei verschiedene Systeme genutzt werden, um den
Zustand der Station abzubilden: Der Laufzettel der einzelnen Ärzt/innen/e und das
gemeinsam geführte Dokument am Computer.
20
3.2 Notaufnahme
Die Zweiteilung der Visite zeigt, dass die Digitalisierung von Teilen der Patienten-
daten Nachteile für die Patientenbetreuung hat. Es musste eine Entscheidung getrof-
fen werden zwischen einer Visite am Patientenbett ohne Patientendaten und einer
Visite am Computer ohne Möglichkeit, den Patienten zu untersuchen. Dies macht
deutlich, dass die mobile Verfügbarkeit von Patientendaten wichtig ist, um eine pa-
tientenzentrierte Visite zu ermöglichen. Die Befragung von Ärzten hat ergeben, dass
die meisten eine Visite am Patientenbett vorziehen würden.
3.2 Notaufnahme
Station
Kurze Stationsaufenthalte und Verlegungen innerhalb einiger Stunden auf andere
Stationen sind charakteristisch für die Notaufnahme. Die Hauptaufgabe dieser Stati-
on ist die schnelle Erstellung einer Diagnose. Aufgrund dieser werden Maßnahmen
ergriffen und entschieden, ob und wann der Patient auf welche Station verlegt wer-
den soll.
Ein großes Whiteboard im Dienstzimmer gibt Auskun darüber, wie die Betten
belegt sind, wer der jeweils betreuende Arzt ist und welche Maßnahmen anstehen.
Die Notaufnahme nutzt wie die gesamte Universitätsklinik SAP zur Patientenver-
waltung. Siehe dazu Abschnitt . auf Seite .
Visite
Die Visite dient rein der Übergabe zwischen den Schichten. Sie ist entsprechend
effektiv darauin ausgerichtet, dass der übernehmende Oberarzt und die Assis-
tenzärzte schnell und zielgerichtet über alle Patienten informiert werden. Da beide
Schichten teilnehmen, sind zwei Oberärzte, sechs bis acht Assistenzärzte, sowie bis
zu sechs Studierende anwesend.
Vor der Visite bereiten die Ärzte, deren Schicht endet, verdichtete Berichte zu ih-
ren Patienten vor (siehe Abbildung . auf der nächsten Seite). Während der Visite
kann so jeder Patient den Ärzten der nächsten Schicht vorgestellt werden. Mithilfe
dieses Berichts kann der Oberarzt schnell einen umfassenden Eindruck gewinnen.
Anweisungen und Patienteninformationen werden von allen Ärzten mitgeschrieben,
deren Schicht gerade beginnt, da erst nach der Visite entschieden wird, wem welcher
Patient zugeteilt wird. Nach der Visite werden die Aufgaben auf das Patientenwhite-
board notiert. So können die Schichtleiter/innen einen Überblick über die Abläufe
und austehende Aufgaben der Station bekommen.
Während der Visite sind nur die Vitaldaten der Patienten schrilich am Bett ver-
fügbar. Die Berichte der Ärzt/innen/e sind allerdings so ausgiebig, dass es nie zu
fehlenden Informationen kommt.
21
Kapitel 3 Visite unter Prozessaspekten
Abbildung .: Prozessmodell Visite in der Notaufnahme
Probleme
Das Hauptproblem in der Notaufnahme sind wie auf den anderen Stationen stän-
dige Ablenkungen. Verstärkt durch die große Anzahl an Teilnehmern, wird fast je-
de Visite durch Telefonanrufe, Notfälle oder andere Unterbrechungen gestört. Diese
Ablenkungen können potenziell dazu führen, dass Aufgaben vergessen werden.
3.3 Orthopädie
Station
Auf der orthopädischen Station der RKU werden hauptsächlich querschnittsgelähm-
te Patienten behandelt. Die Liegezeiten der Patienten betragen meist mehrere Mo-
nate. Bei der Visite sind neben Ärzten und Pegepersonal mehrere erapeuten an-
wesend: Ergo-, Physio- und Sporttherapeuten betreuen die Patienten in der Regel
einmal am Tag und haben einen guten Einblick in den Genesungsverlauf des Pati-
enten. Da die Patienten lange auf der Stationen bleiben, wird das Verhältnis zu den
Mitarbeitern intensiver. Gleichzeitig sind sie durch die Art ihrer Krankheit über ih-
ren Zustand besser informiert als andere Patienten, da die Erkrankung weitreichende
Folgen für ihr weiteres Leben hat.
Auf der Station wird das KIS Meierhofer Clinical Competence (MCC) eingesetzt.
Dieses läu auf einem Citrix-Server und ist dem Tailoring-Ansatz
Citrix entwickelt Application Server Lösungen, d.h. die Anwendungen werden auf einem Server aus-
geführt und auf Client-Computern angezeigt. Diese brauchen entsprechend weniger Rechenleis-
tung (in Clients).
22
3.3 Orthopädie
Abbildung .: Mobile Clinical Assistant
von Motion Computing, Inc.
entsprechend auf die Bedürfnisse und Anforderungen des
RKU angepasst. Die Ärzt/innen/e können von Desktop-
Computern im Dienstzimmer auf die dort gespeichert Da-
ten zugreifen. Der Drucker, über den Röntgenanforderun-
gen und andere Formulare ausgedruckt werden, steht eben-
falls in diesem Zimmer. Neben dem stationären Zugriff be-
steht noch die Möglichkeit, auf Visite einen Visitenwagen mit-
zunehmen, in den unter anderem ein Computer integriert ist.
Außerdem sind auf dieser Station mit dem Mobile Clinical
Assistant von Motion Computing, Inc. (siehe Abbildung .)
Tablet-Computer mit Stibedienung im Einsatz. Diese dienen
als in-Clients für das MCC. Die Benutzerschnittstelle ist da-
bei die gleiche wie am Desktoprechner. Diese Mobilität wird durch ein stationsweites
WLAN ermöglicht.
Visite
Von der Möglichkeit, bei der Visite ein Tablet mitzunehmen, machen nicht alle Ärzt/
innen/e Gebrauch. Während der Visite am Patientenbett können sie mit dem Tablet
Laborbefunde einsehen, Röntgenbilder abrufen und verschiedene Untersuchungen
anordnen. Je nach Untersuchung muss die Anordnung nach der Visite unterschrie-
ben werden.
Ansonsten wird die Visite klassisch durchgeführt, das heißt die Ärztin/der Arzt
übernimmt die Gesprächsführung; Pegekräe und erapeuten berichten gegebe-
nenfalls zusätzlich (siehe Abbildung . auf der nächsten Seite). Die Patienten tra-
gen, verglichen mit anderen Stationen, relativ viel zur Visite bei. Sie berichten über
Körperfunktionen, ihre Fortschritte und Probleme. Auf dem Tablet werden teilweise
Röntgenbilder und Laborbefunde eingesehen.
Abbildung .: Bildschirmtastatur und Sti
des Mobile Clinical Assistant
Sehr o wird die Möglichkeit genutzt, aus dem Programm
heraus Röntgenanforderungen zu erstellen. Dabei wird durch
einen Klick im Patienten-Fenster eine Word-Vorlage geöffnet,
die bereits mit den Patientendaten vorgefüllt ist. Der Benutzer
muss nun noch die Art der Untersuchung, bisherige Befunde
und den Grund der Untersuchung angeben. Diese Daten müs-
sen über eine kleine On-Screen-Tastatur eingegeben werden
(siehe Abbildung .). Schließlich wird das Word-Dokument
gedruckt und geschlossen. Am Ende der Visite ndet die Ärz-
tin/der Arzt die Anforderung im Drucker im Dienstzimmer.
Er unterschreibt sie und gibt sie in die Hauspost. Neben der
Röntgenanforderung kann im Programm auch eine Laborun-
tersuchung des Blutes angefordert werden. Im Dienstzimmer
steht hierzu ein Drucker, welcher Auleber für die Proben druckt. Die Probe muss
23
Kapitel 3 Visite unter Prozessaspekten
Abbildung .: Prozessmodell Visite in der Orthopädie
24
3.4 Chirurgie
dann nur noch genommen, mit dem Auleber versehen und in die Hauspost gege-
ben werden.
Probleme
Die Soware auf dem Tablet ist nicht für mobile Anwendungen angepasst, weshalb
manche Interaktionen (beispielswiese zu Konsilergebnissen navigieren oder Tasta-
tureingaben) den Fluss der Visite bremsen. Das System meldet sich schon nach kur-
zer Zeit aus Sicherheitsgründen ab. Deshalb muss der Benutzer sich sehr o anmel-
den oder daran denken, ab und zu den Bildschirm zu berühren.
Problematisch ist die Verteilung der Daten in mehreren System. Neben dem MCC
werden weitere Systeme für Röntgenbilder und Laborbefunde betrieben, bei denen
sich der Benutzer ebenso anmelden muss.
Durch das Gerät muss der Arzt während der Visite sehr viele Dinge gleichzeitig
tun: Tablet mit Sti halten, ein Diktiergerät benutzen, den Patienten untersuchen
und mit ihm kommunzieren.
3.4 Chirurgie
Station
Es wurde in dieser Betrachtung eine Chefvisite an einer Klinik für Unfall-, Hand-,
Plastischer- und Wiederherstellungschirurgie analysiert. Mit über Betten handelt
es sich um eine große Klinik, die in weitere Stationen eingeteilt ist. Sie ist Teil des
Universitätsklinikums und setzt das gleiche SAP-System ein.
Visite
Die betrachtete Visite auf der Chirurgie ist insofern von den anderen beschriebenen
Visiten zu unterscheiden, als dass es sich hier um eine Chefvisite handelt. Diese n-
det einmal in der Woche statt. Dabei wird nicht nur eine Station besucht, sondern die
Chefärzti/der Chefarzt besucht alle ihm unterstehenden Stationen nacheinander. An
der Visite nehmen die Chefärztin/der Chefarzt, seine Vertretung, ein bis zwei Assis-
tenzärzt/innen/e und, je nach Station, Pegekräe und Physiotherapeuten teil. Beim
Übergang zur nächsten Station wechseln die Assistenzärzt/innen/e und die Pege-
kräe.
Die Dynamik bei der Chefvisite ist hoch, da viele Patienten besucht werden müs-
sen. Pro Patient bleiben nur wenige Minuten, in denen die Chefärzt/innen/e meist
die Röntgenbilder routiniert betrachten und, je nach Zustand des Patienten, Anwei-
sungen für weitere Untersuchungen geben.
Probleme
Das Hauptproblem der Visite in der Chirurgie ist, dass die Visite gut vorbereitet wer-
den muss. Die Ärzt/innen/e suchen vor der Visite relevante Röntgenbilder heraus,
um sie schnell dem Chefarzt vorstellen zu können. Diese Röntgenbilder werden aus-
25
Kapitel 3 Visite unter Prozessaspekten
Abbildung .: Prozessmodell Visite in der Chirurgie
gedruckt und müssen dann während der Visite mitgeführt werden.
Bei der großen Anzahl von Informationen bleibt nicht viel Zeit für den einzelnen
Patienten. Dafür ist diese Visite im Gegensatz zu den anderen Visiten aber auch nicht
ausgelegt.
3.5 Zusammenfassung
Bei der Untersuchung hat sich gezeigt, dass jede der beobachteten Visiten anders or-
ganisiert ist. Diese Unterschiede und die Dynamik innerhalb der einzelnen Visiten
lassen den Schluss zu, dass sich diese Prozesse nicht in einen großen Workow inte-
grieren lassen, der die gesamte Visite umspannt. Stattdessen können bei allen Visiten
um den Hauptprozess „Visite“ weitere Unterprozesse erkannt werden.
Aufgefallen sind außerdem der fehlende Patientenkontakt während der Bespre-
chung auf der inneren Medizin und auf allen Stationen die Nutzung eines Notizzet-
tels, um anstehende Arbeitsschritte zu notieren.
Zu diesen erwähnten „Peripherie“-Workows gehört zum Beispiel die Röntgen-
untersuchung. Bei diesem Prozess sind neben den initiierenden Ärzt/inn/en noch
die beiden Rollen Pegepersonal und Röntgenstation beteiligt (siehe Abbildung .
auf der nächsten Seite). Die Ärztin/der Arzt leitet die Anforderung mit Anamnese
(Beispiel: Hüprothese), Fragestellung (Beispiel: Lockerung der Hüe) und Unter-
suchungsziel (Beispiel: Hüe links, zweischichtig) an die Röntgenstation weiter. Von
der Art der Anforderung hängt ab, ob der Patient sobald wie möglich abgeholt wird,
oder ob ein Termin gewünscht ist. Ist letzteres gewünscht, so kann das Pegepersonal
beispielsweise vor der Untersuchung Kontrastmittel verabreichen. Nach der Unter-
suchung schickt das Labor die Bilder elektronisch und per Hauspost an die Station,
26
3.5 Zusammenfassung
wo die behandelnden Ärzt/innen/e die Ergebnisse analysieren und den Befund do-
kumentieren.
Abbildung .: Prozessmodell Röntgenuntersuchung
Als zweites Beispiel sei an dieser Stelle die Blutuntersuchung erwähnt (siehe Ab-
bildung .). Andere Laboruntersuchungen laufen ähnlich ab. An die Position der
Röntgenstation tritt hier das Labor. Nachdem das Pegepersonal über die Blutun-
tersuchung informiert ist, tri es Vorbereitungen, beispielsweise wenn der Patient
für die Untersuchung nüchtern sein muss. Außerdem wird das Röhrchen vorbereitet,
indem es mit einem Auleber versehen wird, der die Probe eindeutig dem Patien-
ten zuordnet. Nun nimmt eine Ärztin/ein Arzt dem Patienten Blut ab, worauin
das Pegepersonal die Blutprobe verschickt. Das Ergebnis erhält die Ärztin/der Arzt
wieder sowohl auf Papier als auch elektronisch. Er analysiert es, dokumentiert den
Befund und zeichnet es ab.
Abbildung .: Prozessmodell Anforderung einer Blutuntersuchung
27
Kapitel 3 Visite unter Prozessaspekten
Diese Prozesse sind Beispiele dafür, wie Abläufe in der Peripherie der Visite pro-
zesstechnisch, also beispielsweise durch ein WfMS unterstützt werden können. So
könnte Ärztinnen und Ärzte jederzeit den Status der von ihnen angeordneten Un-
tersuchungen überprüfen.
Es ist nun aber nicht zielführend diese Prozesse nur an einem Desktoprechner
den Ärzt/inn/en zugänglich zu machen. Stattdessen sollten die Benutzer mobil un-
terstützt werden, damit sie auch während der Visite auf die Prozesse und ihre Aufga-
ben zugreifen können. Die Entwicklung eines solchen Systems auf Basis eines Tablet-
Computers wird im folgenden Kapitel geschildert.
28
4
Anforderungsanalyse
Nach den Betrachtungen im vorigen Kapitel sind zusammengefasst vier Probleme
der Visite identizierbar:
• Nicht denierte Prozesse,
• Informationsverlust durch Medienbrüche,
• keine Nachverfolgbarkeit der erledigten Aufgaben und
• fehlende Mobilität der Daten.
Diese soll MedicalDo, abgekürzt MEDo, lösen. Dazu wird Aufgabenmanagement,
Prozessmanagement und die Anzeige von Patientendaten in einer Applikation ver-
eint. Diese soll auf einem iPad installiert werden, so dass alle diese Features mobil
verfügbar sind. Das System soll als Prototyp auf Einsetzbarkeit auf drei der im vor-
angegangenen Kapitel vorgestellten Stationen geprü werden.
Durch die Unterstützung von Ärztinnen und Ärzten bei der Bearbeitung von Auf-
gaben können Medienbrüche und Fehlinformationen verhindert werden. Aufgaben,
die einen Prozess auslösen, sollten durch ein WfMS unterstützt werden. Dieses blen-
det automatisch weitere Anweisungen in Arbeitslisten der beteiligten Rollen ein. So
wird eine bessere Kooperation und Koordination der Arbeit ermöglicht. Als logi-
scher Schritt sollten auf einem mobilen Endgerät Patienteninformationen eingese-
hen werden können, wie es bereits auf der Orthopädie mit dem Tablet PC möglich
ist.
In diesem und den folgenden drei Kapiteln werden alle Phasen der Umsetzung
sowie der Evaluation beschrieben. Zunächst werden in diesem Kapitel Anforderun-
gen an das System zusammengetragen. Danach steht die Entwurfsphase, in der Ide-
en zur Architektur, Navigation, zum Layout, Framework und Styleguide gesammelt
und speziziert werden. Die Implementationsphase umfasst die Entwicklung und
Programmierung der nalen Architektur. Die Evaluierung schließt die Entwicklung
des Prototypen ab. Abbildung . auf der nächsten Seite stellt die Zusammenhänge
dieser Kapitel grasch dar.
Die Erfassung der Anforderungen ist unterteilt in solche, die an ein visitenunter-
stützendes System gestellt werden und solche, die sich durch die Wahl des Mediums
29
Kapitel 4 Anforderungsanalyse
Tablet ergeben. Abschliessend werden Szenarien vorgstellt, die mit dem System un-
terstützt werden sollen.
spezi sche Probleme
& Lösungsideen
Anforderungen Entwurf
& Styleguide
Prototyp Anregungen
& Kritik
Papiermockups
Benutzerfeedback
Detailentwürfe
Entwicklung eines
Konzepts
Anforderungen
ausarbeiten
Frameworkvor-
gaben
Programmierung
der Applikation
Interviews
Usability-Tests
Anforderungs-
analyse Entwurf Implemen-
tierung Evaluierung
Fazit
P
r
oblemfel
d
er
Beobac
h
tu
n
g
Erstellu
n
g von
P
r
ozess
m
o
d
ellen
A
n
alyse
d
er
P
r
ozesse
Rec
h
e
r
c
h
e
Lite
r
atur
I
n
terv
i
ews
Gru
n
dla
g
en
Visite u
n
ter
P
r
ozess-
aspekten
Abbildung .: Übersicht über die Phasen bis zur Evaluierung des Prototypes
4.1 Anforderungen an den Laufzettel
Basierend auf der Beobachtung im Kapitel „Visite unter Prozessaspekten“ bestehen
folgende Anforderungen an ein zu implementierendes System:
Abbildung eines papierbasierten Laufzettels Die Hauptaufgabe eines Laufzettels ist
das Auisten und Hinzufügen einfacher Texteinträge. Neben dem Text des
Eintrages wird der Patientenname festgehalten. Dabei soll der Aufgabentext
als Freitext jederzeit erhalten bleiben und als primäre Eingabe anderen Einga-
bemethoden vorgezogen werden.
Einbeziehung von zusätzlichen Daten Es können neben den bereitserwähntenDaten
weitere Informationen für Arbeitslisteneinträge protokolliert werden. Zusam-
mengefasst ergeben sich folgende Daten:
Patientenname
Aktivität Text des Aufgabe
Zeitpunkt aufgenommen Erstellungsdatum der Aufgabe.
Zeitpunkt bearbeitet Datum, an dem die Aufgabe als erledigt markiert wurde.
Benutzer aufgenommen Name des Anwenders, der die Aufgabe erstellt hat.
Benutzer bearbeitet Name des Benutzers, der die Aufgabe abgeschlossen hat.
zugeordnete Daten Beispielsweise Untersuchungsergebnisse und Befunde.
Dabei können Zeiten sowie Benutzerdaten automatisch vom System proto-
kolliert werden. Vom Benutzer müssen also der Patient und der Aufgabentext
explizit eingetragen werden. Letzterer benötigt bei der Eingabe mehr Zeit und
muss dementsprechend vom System in unterschiedlicher Art unterstützt wer-
den. Siehe dazu die Anforderung „Geschwindigkeit der Eingabe.“
30
4.1 Anforderungen an den Laufzettel
Arbeitslistenfunktion Der elektronische Laufzettel sollte, zusätzlich zu den oben be-
reits genannten Texteinträgen, auch automatische, durch Prozesse denierte
Aktivitäten unterstützen.
Ein Beispiel wäre, dass ein Arzt, der eine Aufgabe „Röntgenanforderung“
erstellt hat, diesen Eintrag nach der Visite bearbeitet. Nach dem Ausfüllen und
Abschicken der Röntgenanforderung wird der Eintrag aus der Liste entfernt.
Durch das Abschicken wird der Prozess „Röntgenuntersuchung anfordern“
ausgeführt (siehe hierzu Abbildungen . bis . auf Seite ).
Die jeweiligen Prozesse sollten auf die Stationen angepasst werden, entspre-
chend den dort anzutreffenden Anforderungen. Ein im Hintergrund einge-
setztes WfMS würde eine solche Anpassbarkeit bieten.
Unterbrechbarkeit Dadurch, dass Visiten sehr unterschiedlich durchgeführt wer-
den, muss das System eine Vielzahl von Verwendungen unterstützen. Bei-
spielsweise sollte ein Benutzer jederzeit das Ausfüllen einer Röntgenanforde-
rung abbrechen können, um schnell zu einem anderen Patienten zu wechseln
und dort Daten einzusehen. Es sollte in einem solchen Fall automatisch ein
Arbeitslisten-Eintrag erstellt werden und eine Sicherung der Daten durchge-
führt werden. Zu einem späteren Zeitpunkt kann so der Benutzer die Eintra-
gung weiterbearbeiten.
Flexibilität Nicht vorausgeplante Ausnahmen stellen ein Problem für die meisten
Workowumgebungen dar. Tritt ein solcher Fall ein, muss vom modellierten
Standardablauf abgewichen werden. Die wenigsten heutigen WfMS gestatten
solch einen Eingriff [, ].
Beim Einsatz im Krankenhaus werden viele Sonderfälle eintreten, die nicht
alle im Vorfeld eingeplant werden können. So macht es Sinn, dass auch die
Prozesse, die MEDo unterstützt, exibel sind. Dafür muss eine entsprechende
Benutzerschnittstelle angeboten werden.
Geschwindigkeit der Eingabe Um mit der Geschwindigkeit der Kommunikation
während der Visite mithalten zu können, muss die Eingabe sehr schnell ge-
schehen. Die Art der Texteingabe spielt dabei eine große Rolle. Denkbare
Eingabemöglichkeiten wären:
• Handschrierkennung,
• Textbausteine,
• Hardwaretastatur,
• Spracherkennung,
• virtuelle Tastatur mit Touchscreen und
• virtuelle Tastatur mit Stieingabe.
Allerdings hat nicht nur die Texteingabe Einuss auf die Bedienung. Das
Bedienkonzept muss ebenso entsprechend ausgerichtet sein. Weitere Faktoren
sind außerdem die Geschwindigkeit der Soware bei der Anzeige und Bedie-
31
Kapitel 4 Anforderungsanalyse
nung sowie die Geschwindigkeit der Datenspeicherung und -abfrage.
Rollen-/Mehrbenutzerunterstützung Es sollten mehrere Rollen unterstützt werden,
hauptsächlich zur Unterscheidung der Rollen Arzt und Pegepersonal. Je nach
Rolle ist die Benutzerschnittstelle anzupassen. Abhängig von der Rolle sind
auch die Rechte des angemeldeten Benutzers zu modellieren.
Geteilte Listen Benutzer brauchen eine Möglichkeit, ihre Arbeitslisten mit Anderen
zu teilen. Denkbar wäre auch ein nur lesender Zugriff auf Listen.
Adäquate Anzeige der anstehenden Aufgaben Es sollte jederzeit für einen angemel-
deten Benutzer möglich sein, alle anstehenden Aufgaben einzusehen. Er sollte
so schnell wie möglich die für seine aktuelle Arbeitssituation passende Aufga-
be auswählen können.
Adäquate Bearbeitung der Aufgaben Aufgaben, die ohne Handlung ausserhalb der
elektronischen Umgebung bearbeitet werden können, sollten automatisch ab-
geschlossen werden. Sobald der Arzt das entsprechende Formular ausgefüllt
hat, muss der zugeordnete Arbeitslisteneintrag als abgearbeitet angezeigt wer-
den.
Aufgaben, die manuelle Handlungen verlangen, sollten durch das System
unterstützt werden. Nach Abschluß der Arbeit sollten diese Aufgaben ebenso
als erledigt markierbar sein.
Jederzeit Aufgabenbearbeitung unterbrechen Unterbrechungen sind in der Klinik an
der Tagesordnung. Der Benutzer sollte somit jederzeit die Möglichkeit haben,
mit einer Aufgabe zu pausieren. Auf die Pausierung hin sollte automatisch ein
Arbeitslisteneintrag erstellt werden, sowie ein Zwischenstand der bisher ein-
gegeben Daten. Nach der Unterbrechung kann die Ärztin oder der Arzt so
nahtlos weiterarbeiten.
Unterstützung für Schichtübergabe Laufzettel müssen entweder immer für alle ein-
sehbar sein oder es sollte die Möglichkeit gegeben werden, den Laufzettel an
die nächste Schicht zu übergeben.
Adäquate Anzeige von Untersuchungsergebnissen Der Arzt muss sehr schnellen Zu-
griff auf alle bisherigen Untersuchungsergebnisse haben. Hier sind alle unnö-
tigen Interaktionen zu vermeiden. Negativbeispiel ist hier das MCC der Mey-
erhofer AG: Jeder Untersuchungsbericht ist mit mindestens drei Klicks und
entsprechenden Wartezeiten dazwischen verbunden (siehe Abbildung . auf
der nächsten Seite).
Adäquate Benachrichtigung über Status von Untersuchungen Im Optimalfall sollten
die Ärzt/innen/e automatisch über alle neu eingetroffenen Untersuchungs-
ergebnisse informiert werden. Dies erfolgt idealerweise als Eintrag in der
Arbeitsliste. Eine Berührung oder Klick bringt den Anwender zum Untersu-
chungsergebnis. Hier sollte er die Möglichkeit haben, das Untersuchungser-
gebnis als gelesen zu markieren und damit aus der Arbeitsliste zu entfernen.
Allerdings ist nicht nur das Untersuchungsergebnis an sich wichtig, son-
32
4.2 Anforderungen an die Hardware
Abbildung .: Patientenakte im MCC. Um zum Kumulativbefund zu gelangen, muss der Be-
nutzer den Patienten auswählen, in der rechen Leiste „Arbeitsplatz“ anklicken und in einem
Dropdown „Kumulativbefund“ auswählen.
dern auch der Status der Untersuchungsanordnung. Zu unterscheiden wären
folgende Stati:
• Angeordnet,
• Termin steht fest,
• Untersuchung abgeschlossen und
• Ergebnis der Untersuchung ist bekannt/veröffentlicht.
Komplette Abdeckung der Möglichkeiten der Papier-Handzettel Wichtig für die sinn-
volle Nutzung eines elektronischen Laufzettels ist, dass dieser mindestens die
Möglichkeiten eines papierbasierten Laufzettels komplett abdeckt. Sind diese
Mindestbedingungen nicht erfüllt, führt das dazu, dass die Anwender doch
wieder eine Papierliste führen.
4.2 Anforderungen an die Hardware
Eine im Krankenhaus – speziell während der Visite – einzusetzende Soware stellt
bestimmte Anforderungen an die Hardware. Diese sind im Folgenden aufgeführt.
Größe und Gewicht Ein auf der Visite mitzuführendes Gerät sollte nicht größer als
ein DIN-A-Blatt sein. Größe und Gewicht sind beides Faktoren, die darüber
33
Kapitel 4 Anforderungsanalyse
entscheiden, wie gut ein Tablet verwendet werden kann. Gleichzeitig sollte
es so groß sein, dass zum einen Applikationen übersichtlich darstellbar sind.
Zum anderen benötigen Darstellungen eine Mindestgröße, so dass diese von
mehreren Personen gleichzeitig einsehbar sind.
Blickwinkel Der Bildschirm des Gerätes sollte so blickwinkelstabil sein, dass es von
mehreren Personen zugleich betrachtet werden kann.
Hygiene Die Verwendung im medizinischen Umfeld erfordert es, dass das Gerät ein-
fach zu desinzieren ist.
4.3 Daten
Im Hinblick auf das spätere Design der Oberächen ist es wichtig, bereits im Vorfeld
zu wissen, welche Daten im System benötigt werden und dargestellt werden müssen.
Die Wichtigkeit der verschiedenen Patienteninformationen wird auf jeder Station
anders bewertet. Aus diesen Informationen wurden die in Abbildung . gezeigten
Kategorien ermittelt, in die die Daten fallen.
Abbildung .: Modell der Patientendaten
Zu Vitalparametern werden Blutdruck, Herzfrequenz, Körpertemperatur und
Atemfrequenz gezählt. Zusätzlich ist für manche Stationen der Blutzucker sowie
die Sauerstoffsättigung interessant. Diese Daten werden in der Regel dreimal am Tag
manuell vom Pegepersonal genommen und in die Patientenkurve eingetragen.
Die Anamnese ist die Krankengeschichte aus Sicht des Patienten. Diese wird bei
der Aufnahme des Patienten in das Krankenhaus erfragt. Die Gesamtanamnese setzt
sich aus verschiedenen Teildaten zusammen. Dabei sind die wichtigsten Daten der
34
4.4 Szenarien
Grund des Besuchs der Klinik, eventuelle Vorerkrankungen, frühere sowie die aktu-
elle Medikation und bisherige Behandlungen.
Neben diesen Daten hat der behandelnde Arzt die Möglichkeit, verschiedene
Untersuchungen anzuordnen, um zu einer Diagnose zu kommen. Diese Untersu-
chungen werden unter dem Begriff Diagnostik zusammengefasst und lassen sich in
drei Kategorien einteilen: in-vivo-Diagnostik, bildgebende Diagnostik sowie Kon-
sile. In-Vivo-Diagnostik umfasst Untersuchungen von lebendem Material wie Blut
oder Urin, während bildgebende Diagnostiken beispielsweise Röntgen- oder CT-
Untersuchungen sind. Als Konsil wird die Beratung eines Arztes durch einen Fach-
arzt bezeichnet.
4.3.1 Zugriffe
Wie schon oben ausgeführt, werden zwei verschiedene Rollen Zugriff auf das System
benötigen: Ärztliches Personal und Pegepersonal. Diese beiden Rollen brauchen
bei Ihrer Arbeit verschiedene Daten des Patienten. Neben den Daten ist auch die Art
des Zugriffs zu beachten (siehe hierzu Tabelle .). Da jeder Anwender möglichst
nur die Informationen sehen sollte, die er für seine Arbeit benötigt, muss für das
Pegepersonal eine eigene Sicht geschaffen werden.
Tabelle .: Zugriffe auf Patientendaten (l = lesend, s = schreibend)
Daten Arzt Pege
l s l s
Vitaldaten ✓ ✓ ✓
Medikation ✓ ✓ ✓
Berichte ✓ ✓
Termine ✓ ✓ ✓ (✓)
Aufgaben ✓ ✓ ✓ (✓)
Diagnostik ✓
4.4 Szenarien
Bei der Konzeption von Soware bietet es sich an, Szenarien auszuarbeiten, die für
die Benutzung typische Vorgänge und Umstände beschreiben. Diese müssen mit den
Benutzern veriziert werden. Im Tabelle . auf der nächsten Seite werden die Sze-
narien beschrieben, die das MEDo-System unterstützen sollte.
4.5 Zusammenfassung
In diesem Kapitel wurden die Anforderungen an MEDo vorgestellt. Ausgangspunkt
dafür waren die Arbeitsabläufe, die im vorhergehenden Kapitel beschrieben wurden.
Dabei war es wichtig zu erkennen, dass die Arbeitsweisen der Ärzt/innen/e weiterhin
35
Kapitel 4 Anforderungsanalyse
Tabelle .: Szenarien
Szene Beschreibung
Eine Ärztin/ein Arzt möchte eine Röntgenuntersuchung für einen Patienten machen. Er fängt
mit dem Ausfüllen der Details an, wird dabei aber unterbrochen. Er füllt den Rest aus, sobald
er Zeit ndet.
Während einer Visite soll überprü werden, ob bereits eine Röntgenuntersuchung angeordnet
ist und wie deren Status ist.
Am Anfang einer Schicht möchte eine Ärztin alle neu eingetroffenen Untersuchungsergebnisse
überprüfen, um auf den neuesten Stand zu kommen.
VorderVisitebereitetsich eineÄrztin/einArztauf die Visitevor.Dazubenötigterdie Anamnese,
Labordaten, Röntgenaufnahmen sowie die Medikation.
Nach einer Visite möchte eine Ärztin/ein Arzt alle Aufgaben des heutigen Tages angezeigt be-
kommen. Er arbeitet diese nun nacheinander ab.
Während einer sollen viele Aufgaben nacheinander erstellt werden. Eine Ärztin/ein Arzt gibt
dabei die Anordnungen, ein zweiter schreibt sie mit.
unterstützt werden muss. Ansonsten droht ein Rückfall auf Papierlaufzettel. Weiter-
hin wurden die Patientendaten, die im System unterstützt werden müssen, identi-
ziert. Um diese Anforderungen in der Praxis testen zu können, wurden mehrere
Szenarien erstellt, die der Prototyp unterstützen sollte. Diese Anforderungen dienen
als Ausgangspunkt für den im nächsten Kapitel vorgeestellten Entwurf des MEDo-
Systems.
36
5
Entwurf
Ein Prototyp ist eine „Darstellung der Gesamtheit oder eines Teils eines interaktiven
Systems, die, gegebenenfalls mit Einschränkungen, zur Analyse, Gestaltung und Be-
wertung verwendet werden kann“ []. Prototypen lassen sich in verschiedene De-
tailgrade einteilen. Am Anfang des Entwicklungsprozesses stehen meistens Papier-
prototypen. Diese fallen unter den Begriff low-delity. Auf der anderen Seite stehen
high-delity-Prototypen. Diese ähneln auch funktionell schon stark dem Endprodukt
– beispielsweise durch die Entwicklung im Zielframework. Beide Arten liefern bei
der Evaluation ähnliche Ergebnisse [, ].
Es kann zwar von ersten Erfahrungen mit Smartphones ausgegangen werden, je-
doch werden viele Anwender noch kein Tablet benutzt haben. Durch diese neue
Form der Interaktion sind neue Interaktionskonzepte nötig. Viele erlernte Vorge-
hensweisen an Desktopcomputern sind bei Touch-Geräten nicht mehr möglich. Aus
diesem Grund ist es wichtig, dass der Prototyp direkt auf einem Gerät getestet werden
kann. Ich habe mich deshalb für einen high-delity Screen-Prototyp entschieden.
Wesentlich dabei ist vor allem, einen möglichst kompletten horizontalen Durch-
stich durch das System präsentieren zu können (siehe dazu Abbildung .). Nicht
beachtet wurden die verschiedenen Informationssysteme, in denen sich die Daten
in der Realität benden. Im Gegensatz zur fühlbaren Funktionalität stellen Hinter-
grundfunktionen keinen großen Faktor für einen Usability-Test dar.
Verschiedene Features
Funktionalität
Szenario
Komplettes System
Horizontaler Prototyp
Vertikaler Prototyp
Abbildung .: Unterscheidung zwischen horizontalen und vertikalen Prototypen [, S. ]
Während der Planung wurde bereits klar, dass im System zwei Sichten eine Rol-
le spielen: Auf der einen Seite gibt es die datenzentrierte Sicht, die Patientendaten,
Befunde, Röntgenbilder und so weiter umfasst. Zum anderen hat das System eine
37
Kapitel 5 Entwurf
ablaufzentrierte Sicht, die Handlungen wie Aufgaben anlegen, Anforderungen ver-
folgen, neu eingetroffene Befunde anzeigen etc. einschließt. Obwohl bei dieser Arbeit
letztere Sicht im Vordergrund steht, kann die datenorientierte Sicht nicht außer Acht
gelassen werden. Erst durch die nahtlose Interaktion zwischen beiden Sichten kann
der Benutzer optimal unterstützt werden. Insbesondere da der Prototyp möglichst
realitätsnah die Benutzung eines mobilen Systems widerspiegeln sollte, musste im
Hinblick auf die Evaluationsphase möglichst jeder Bildschirm zumindest dargestellt
werden. So kann der Anwender sich besser vorstellen, wie das Gesamtsystem arbeitet
und wird gedanklich nicht aus seiner Aufgabe gerissen. Es sollten nach Möglichkeit
alle Interaktionen, die in den Szenarien (Abschnitt . auf Seite ) deniert wurden,
unterstützt werden.
Nachdem im vorangegangenen Kapitel alle Anforderungen erfasst wurden, müs-
sen diese in Benutzeroberächen umgesetzt werden. In diesem Fall wurde beson-
ders darauf geachtet, dass das Tablet während der Visite möglichst in nur einer
Hand gehalten werden muss. Dies ist am einfachsten, wenn das Gerät hochkant
gehalten wird. Aufgrund der einfachen Umsetzung wird allerdings auch die Quer-
Orientierung unterstützt. Dies ist sinnvoll, wenn beispielsweise Bilder oder Diagno-
seergebnisse angezeigt werden sollen, die ansonsten nur knapp auf den Bildschirm
passen.
5.1 Informationsarchitektur
Bevor irgendwelche Details zu den verschiedenen Bildschirmen entwickelt werden
konnten, war es wichtig, einen Überblick über die Soware zu bekommen. Es wurde
ein Modell entwickelt (Abbildung . auf der nächsten Seite), das alle Bildschirme
und deren Navigationsmöglichkeiten umfasst. Auf diese Weise konnte, bevor De-
tails überlegt wurden, passende Navigationskonzepte für die verschiedenen Berei-
che ausgewählt werden. Links oben ist der Ärzteschirm (auch Stationsschirm oder
-übersicht) zu sehen. Hier werden Übersichten angezeigt, die alle Patienten betreffen
– zum Beispiel eine Liste aller Aufgaben, Patienten und Untersuchungsergebnissen.
Dies kann als Einstiegspunkt genutzt werden, um beispielsweise zum Schichtanfang
eine Übersicht über die Station zu bekommen. Von hier kann der Benutzer außer-
dem einzelne Patientenakten auswählen.
Wählt er eine Aufgabe, sollte diese in einem Popover oder einem modalen Fens-
ter angezeigt werden. In dieser Aufgabenansicht sollten Details wie Ersteller, Datum,
Status und natürlich der Text angezeigt werden. Zusätzlich sollten Aktionen angebo-
ten werden, wie beispielsweise die Aufgabe als erledigt zu markieren. Andere Aktio-
nen sind abhängig vom Kontext: So sollte bei einer Erinnerung, dass noch eine An-
Popover: Kleines, nicht modales Fenster, das immer einem Steuerelement (bspw. einem Button)
durch einen Pfeil zugeordnet ist und durch Tippen ausserhalb dieses Elements ausgeblendet werden
kann. Dieses Bedienelement wird durch das iOS-SDK auf dem iPad angeboten.
38
5.1 Informationsarchitektur
Abbildung .: Informationsarchitektur für MEDo. Rechtecke stellen Bildschirme dar, Pfeile
zwischen diesen Navigationsmöglichkeiten. Dabei geben die ausgefüllten Pfeile die Haupt-
richtung an, einfache Pfeilspitzen zeigen an, dass hier eine Zurück-Funktionalität eingesetzt
werden soll.
39
Kapitel 5 Entwurf
forderung vervollständigt werden muss, eine Möglichkeit (durch einen Button) ge-
boten werden, um direkt zum entsprechenden Formular zu springen. Der Benutzer
sollte auch die Möglichkeit haben, von der Aufgaben-Ansicht zum Patienten selber
zu wechseln, um dort weitere Details zu erfahren.
Wieder auf dem Ärzteschirm kann der Benutzer ebenso zum Patient selbst sprin-
gen. Hier sollte er neben den allgemeine Informationen Details angezeigt bekom-
men: Bilddaten, Laborbefunde, Vitaldaten, Medikation, Termine, Krankengeschich-
te und Dokumente. Für die meisten dieser Datenkategorien sollte eine eigene Ansicht
eingeplant werden, da sonst der Bildschirm schnell überfüllt ist. Im Diagnostikbe-
reich (Bilddaten und Laborbefunde) sollte es möglich sein, neue Anforderungen zu
erstellen.
Generell sollte der Benutzer möglichst von jedem Bildschirm die Möglichkeit ha-
ben, eine neue Aufgabe zu erstellen. Insbesondere auf dem Stations- und auf dem
Patientenschirm ist dies sehr wichtig, damit er nicht den aktuellen Kontext verlassen
muss. Neue Anforderungen sollten je nachdem, um was für eine Untersuchung es
sich handelt, angepasste Eingabemasken anzeigen. Beispielsweise benötigt eine La-
boranforderung andere Daten als eine Konsilanforderung.
5.2 Navigationskonzept
Bei Systemen mit direkter Manipulation ist die Verteilung der Informationen und die
Bewegung zwischen diesen von besonderer Bedeutung für die Interaktion. So sollte
versucht werden, möglichst das räumliche Verständnis des Benutzers anzusprechen,
indem Bildschirme auf einer zwei- oder dreidimensionalen Ebene angeordnet wer-
den.
Angenommen es handelt sich um zwei aufeinanderfolgende Sichten, wie beispiels-
weise mehrere Seiten eines Suchergebnisses. Wechselt der Benutzer nun zum zwei-
ten, rechten Bildschirm, so wird der linke Bildschirm nach links aus dem Bild ge-
schoben, während der rechte von rechts erscheint (siehe Abbildung .).
Abbildung .: Projektion von Inhalten auf eine zweidimensionale Ebene. Inhalt A wird aus
dem Bild animiert, während Inhalt B eingeschoben wird.
Durch solche Animationen kann das mentale Modell, welches sich der Benut-
zer von der Soware macht, angesprochen werden. Diesem Usermodell gegenüber
40
5.2 Navigationskonzept
steht das Implementierungsmodell, die der Entwicklungsseite inklusive der abstrak-
ten Daten und Klassen entspricht. Der Entwickler versucht nun, über Repräsentie-
rungsmodelle diese Details zu verstecken und gleichzeitig ein Modell anzubieten,
welches eher dem Usermodell entspricht (siehe Abbildung .). Ein Beispiel wurde
oben bereits genannt, ein anderes wäre das animierte Einschieben einer neuen Ta-
bellenzeile, wenn der Benutzer eine weitere Zeile einfügt.
Implementie-
rungsmodell Usermodell
schlechter besser
Repräsentierungsmodelle
Abbildung .: Es existieren qualitativ verschiedene Repräsentierungsmodelle zwischen
Implementierungs- und Usermodell. Umso eher dieses dem mentalen Modell des Users ent-
spricht, desto einfacher fällt ihm die Bedienung der Soware [, S. ]
Im Fall von MEDo wurde besonders die Navigation zwischen Patienten und die
Navigation zwischen den Patientendetails als Problempunkt erkannt, bei dem ein
gutes Repräsentationsmodell wichtig ist. Abbildung . zeigt die drei in Erwägung
gezogenen Modelle. Im ersten Modell sind die Patienten untereinander dargestellt
und der Benutzer wechselt in horizontaler Richtung zwischen den Detailbildschir-
men. Das zweite Modell ist um ° gedreht, das heisst die Patienten sind vertikal un-
tereinander angeordnet und die Patientendetails sind in horizontaler Richtung ver-
teilt. Modell Nummer drei schließlich ist an letzteres angelehnt, wobei die Patienten
hintereinander dargestellt werden, ähnlich der Organisation in einem Karteisystem.
Dieses Konzept wurde schließlich im MEDo-System eingesetzt, abgewandelt durch
den Einsatz von Reitern für die detaillierte Darstellung von Patientendetails. Die Ge-
staltung ähnelt damit der Patientenakte, bei der Seiten umgeblättert werden, wenn
zwischen Patienten navigiert wird.
(a) Vertikal (b) Horizontal (c) Karteisystem
Abbildung .: Repräsentationsmodelle für die Navigation zwischen Patienten und deren Da-
ten
41
Kapitel 5 Entwurf
5.3 Screens
Die nächste Frage ist: Wie sollen die Informationen auf den verschiedenen Ansichten
dargestellt werden? Hier müssen die Anforderungen an die Soware und die Vorga-
ben der Plattform beachtet werden. Diese Entscheidungen werden in den folgenden
Abschnitten vorgestellt.
5.3.1 Stationsschirm
Abbildung . zeigt Skizzen der Stationsübersicht. Hier ndet sich der Anwender
nach dem Start der Anwendung wieder. Abbildung .a zeigt einen ersten Entwurf,
bei dem die Patienten links dargestellt werden. Die rechte Seite kann genutzt werden,
um dort Aufgaben oder, wie in Abbildung .b, eine Karte der Station zu zeigen. Auf
diese Weise kann der Benutzer sehen, welcher Patient in welchem Zimmer liegt. Bei
der Visite kann diese Ansicht auch genutzt werden, um schnell von einem Raum zum
nächsten zu wechseln. Dagegen spricht, dass mit der Auswahl des Zimmers ein Zwi-
schenschritt eingeführt wird. Zusätzlich muss der Benutzer sich selbst den Grundriss
der Station in Erinnerung rufen. Aus diesem Grund sollte alternativ eine Listenan-
sicht verfügbar sein.
Abbildung .c zeigt schließlich wie in dieser Stationsansicht eine einzelne Aufga-
be ausgewählt werden kann. Die Darstellung erfolgt dabei in einem two panel selector.
Die Aufgabenliste wird links, die Details einer ausgewählten Aufgabe rechts ange-
zeigt. Bei der Übertragung dieser Skizzen auf ein iPad ist schnell ersichtlich, dass die
Prototypen die Größe des Bildschirms nicht gut ausnutzen.
(a) (b) (c)
Abbildung .: Verschiedene Aueilungen der Stationsübersicht
5.3.2 Aufgaben erstellen und anzeigen
Das Erstellen von Aufgaben ist eines der wichtigsten Elemente im Prototyp. Die Ein-
gabe sollte so schnell wie möglich geschehen. Deshalb habe ich mich für die Unter-
stützung durch Textbausteine entschieden. Diese können in einen Freitextbereich
42
5.3 Screens
eingefügt werden, der via Bildschirmtastatur editiert werden kann. So hat der Be-
nutzer alle Freiheiten und kann gleichzeitig durch Textbausteine schneller Eingaben
vornehmen.
Sie sollten je nach Station angepasst werden. Die Stationen sind zu unterschied-
lich, als dass hier ein gemeinsamer Wortschatz angeboten werden kann. Es sollten
allgemeine und o gebrauchte Blöcke angeboten werden.
Abbildung .a zeigt die vertikale Abfolge der Eingabefelder der Aufgabenanlege-
Ansicht. Dadurch fällt es dem Auge leicher, dem Verlauf des Formulars zu folgen.
Über der Tastatur schließlich bendet sich das Textfeld. In dieses kann entweder
Freitext eingegeben werden oder komplette Textbausteine über den Bereich rechts
davon eingefügt werden.
Zu beachten bei dieser Skizze ist, dass diese nur einen Ausschnitt aus dem gesam-
ten Bildschirm zeigt. Die Ansicht ist als modales Fenster geplant, das nicht den kom-
pletten Bildschirm bedeckt. Der nicht aktive Teil des Bildschirms sollte abgedunkelt
erscheinen, damit er in den Hintergrund tritt. Wie bei allen iOS-Fenstern kann die
Ansicht durch Buttons in einer Titelleiste gespeichert und abgebrochen werden.
(a) Fenster um eine neue Aufgabe anzulegen – Entwurf (b) Fenster um Aufgaben anzuzeigen – Entwurf
Abbildung .: Entwürfe zu Aufgabenfenstern
43
Kapitel 5 Entwurf
Die Anzeige von Aufgaben sollte in einem der Eingabe ähnlichen Fenster erfolgen.
Abbildung .b auf der vorherigen Seite zeigt einen Entwurf. Der Name des Patient
wird an der gleichen Stelle angezeigt. Patientendetails können durch Antippen ange-
zeigt werden, angedeutet durch einen Pfeil. Darunter nden sich alle Informationen
zur Aufgabe sowie Buttons, um die Aufgabe als erledigt zu markieren und aufgenom-
mene Audio-Aufnahmen abzuspielen.
5.3.3 Navigationsleiste
Ein interaktives System erhält durch ein visuelles Framework eine einheitliche Ge-
stalt und trägt somit zur Wiedererkennung bei. Es umfasst Farben, Abstände, Aus-
richtungen und Typograe. Zusätzlich sollten Navigationsmöglichkeiten und „Sie
benden sich hier“-Wegweiser auf allen Ansichten ähnlich sein [].
Es sollte immer ersichtlich sein, wo sich der Benutzer gerade bendet und wel-
che Möglichkeiten er hat, von hier aus zu navigieren. Beispielsweise sollten diese auf
einem Patientenschirm sein:
• Zurück zur Stationsübersicht,
• zwischen Patienten hin und her wechseln,
• direkt zu einem Patienten springen,
• sowie eine neue Aufgabe anzulegen.
In Abbildung . auf der nächsten Seite werden diese Anforderungen in verschie-
dener Art exploriert. Allen Skizzen gemein ist, dass der Patientenname immer in
der Navigationsleiste angezeigt wird. Das ist das normale Verhalten in allen iOS-
Anwendungen. Genauso verhält es sich mit dem Zurück-Button oben links. Durch
die Pfeilform ist die Richtung erkennbar, die der Benutzer mit der Einblendanimati-
on dieses Bildschirms in Verbindung bringen kann. Der Pfeil zeigt entsprechend in
die entgegengesetzte Richtung.
Die Navigationsleiste besitzt drei logische Unterteilungen. Links, in der Mitte zen-
triert, sowie rechts. Der linke Bereich ist bereits durch den Zurück-Button belegt,
genauso wie mittig der Patientenname angezeigt wird. Abbildung .a fügt dem Pa-
tientennamen durch einen Dropdownpfeil noch weitere Funktionalität hinzu. Über
diesen kann der Benutzer die Patientenliste aufrufen. Außerdem kann der Benutzer
durch Buttons links vom Namen vor und zurück durch die Patienten schalten kann.
Hier ist darauf zu achten, dass die Pfeilrichtungen den Übergangsanimationen zwi-
schen den Patienten entsprechen muss, damit der Benutzer ein durchgängiges Map-
ping für sein mentales Modell auauen kann.
5.3.4 Patientenschirm
Der Patientenschirm ist der Ausgangspunkt zu allen Informationen, die einen be-
stimmten Patienten betreffen. Dazu wird zum einen eine Übersicht, zum anderen
eine Möglichkeit, Detailinformationen abzurufen, benötigt.
44
5.3 Screens
(a)
(b)
(c)
(d)
Abbildung .: Navigationsleisten
45
Kapitel 5 Entwurf
Eine Idee wäre die Darstellung aller Informationen in Spalten, wie in Abbil-
dung .a dargestellt. Das heißt es gibt eine Spalte für Termine, eine Spalte für
Aufgaben und weitere Spalten entsprechend den Datenkategorien. Da nicht alle
diese Spalten auf einen Bildschirm passen, kann diese Ansicht durch horizontales
Wischen bewegt werden. Um mehr Einträge zu einer Kategorie einsehen zu können,
scrollt der Benutzer nach unten.
(a) Darstellung der Patientendaten in scrollbaren Spalten (b) Alternative Anordnung in einem Raster
Abbildung .: Entwürfe zur Darstellung der Patientendaten
Denkbar wäre, die Übersicht nach einem Raster auszurichten (siehe dazu Abbil-
dung .b). So braucht der Benutzer nicht nach den Informationen zu suchen, son-
dern er bekommt die Wichtigsten auf einem Bildschirm angezeigt.
Da bei dieser Anordnung nicht alle Einträge zu allen Kategorien angezeigt werden
können, werden weitere Bildschirme benötigt. Um zwischen diesen umschalten zu
können, gibt es im iOS-Framework eine Tab-Leiste. Diese sind in iOS standardmäßig
am unteren Bildrand angeordnet (wie in Abbildung . auf der nächsten Seite). So
kann der Benutzer auf dem ersten Reiter einen Überblick bekommen, und für mehr
Informationen weitere Seite anwählen.
Abbildung . zeigt aber auch, dass die Tab-Leiste keine visuelle Verbindung zum
Navigationsbereich oben hat. Es ist schwierig zu sagen, welchen Teil der Ansicht die
Tab-Leiste kontrolliert: Ändert sich die Navigationsleiste, wenn auf einen anderen
Reiter umgeschaltet wird? Oder bleibt sie gleich und nur der Inhalt ändert sich?
Gelöst habe ich dieses Problem durch die Positionierung der Tableiste am obe-
ren Bildschirmrand, unter der Navigationsleiste (siehe Abbildung . auf Seite ).
Durch die logische Gruppierung des Namens und den Tabreitern wird eine visuelle
Einheit gebildet, die ähnlich einer Akte mit Karteireitern ist.
5.4 Styleguide: Piktogramme, Farben und visueller Stil
Die Erlernbarkeit eines interaktiven Systems kann durch einen einheitlichen visuel-
len Stil unterstützt werden. Nicht passende, visuelle Elemente werden vom Benutzer
als störend empfunden.
46
5.4 Styleguide: Piktogramme, Farben und visueller Stil
Abbildung .: Patientendaten in Portraitorientierung im Raster, mit Tab-Leiste
47
Kapitel 5 Entwurf
Abbildung .: Tab-Leiste am oberen Rand
Ein minimaler Stil war das Ziel für MEDo. Dabei entsteht hierarchische Ordnung
durch Typograe und Struktur durch Leerräume. Farben werden nur sparsam einge-
setzt. Nur aktive Elemente wie Selektionen oder gedrückte Buttons werden farblich
gekennzeichnet und werden so besonders hervorgehoben. Abbildung . zeigt ei-
nen Entwurf eines Buttons. Die Dreidimensionalität lässt ihn als Button erkennen,
besonders durch die zurückhaltende Gestaltung des restlichen Interfaces. Er soll eine
hellgraue Oberäche haben und aueuchten, wenn er gedrückt wird.
Abbildung .: Entwurf eines Buttons
Abbildung . zeigt verschiedene Pixel-Designs der Buttons. Diese werden be-
sonders in Navigationsleisten sowie Toolbars eingesetzt. Der gleiche Stil wird außer-
dem bei segmentierten Steuerelemente genutzt.
(a) (b) (c) (d) (e) (f)
Abbildung .: Verschiedene Pixeldesigns der Buttons
Steuerelemente benötigen eine bestimmte Mindestgröße, damit der Benutzer sie
zielsicher treffen kann – egal ob Maus- oder Touchbedienung. Da Finger aber signi-
kant größer sind als Mauszeiger, müssen die Zielbereiche bei direkter Manipulation
besonders groß sein. Da intern Pixel verwendet werden, muss eine Umrechung vom
physikalischen Wert stattnden. Maßgebend dafür sind die DPI (Dots per Inch) des
Gerätes. Dieser Wert gibt das Verhältnis von physischen Einheiten (Inch) zur Gerä-
teauösung in Pixeln an. Typische Druckerzeignisse haben Dots per Inch (DPI),
Computer-Bildschirme um die DPI. Teilweise wird auch von PPI (Pixel per Inch)
gesprochen, beides meint aber im Endeffekt das gleiche.
Apple schlägt bei den DPI des iPads eine Mindestgröße von × Pixeln
vor [].
48
5.4 Styleguide: Piktogramme, Farben und visueller Stil
5.4.1 Typographie & Raster
Als Grundtype soll im System „Helvetica Neue“ eingesetzt werden. Text soll im
Schnitt Normal in Punkt gesetzt werden. Für Hauptüberschrien (Navigations-
leiste, Name des Patienten, etc) ist Fein/pt zu verwenden, für Überschrien der
zweiten Ordnung Schmall/Fett/pt. Manchmal wird etwas kleinerer Text für zu-
sätzliche Informationen o.Ä. benötigt, dieser wird dunklgrau in pt gesetzt.
Mithilfe eines Raster – bestehend aus Seitenrändern, Spalten und Zwischenräu-
men – lassen sich einfach Strukturen bilden und so eine visuelle Ordnung herstel-
len. Innerhalb des MEDo-Systems sollte bei der Positionierung von Elementen ein
Raster, bestehend aus zwölf Spalten, verwendet werden (siehe Abbildung .). Der
Vorteil bei einem Raster bestehend aus zwölf Spalten ist, dass sich einfach darauf auf-
bauende Raster bilden lassen. So sind Raster mit sechs, vier, drei und zwei Spalten
möglich. Bei Portraitorientierung des Gerätes sind horizontal Pixel verfügbar.
Hier bietet sich ein sechser-Raster an, wobei sich Pixel breite Spalten bei Pixel
Seitenrändern und Spaltenzwischenräumen ergeben.
Der Patientenname steht hier
lt. Angaben des Pat. besteht seit über 10 Jh. eine
art. Hypertonie, die unter bestehender Therapie
immer gut eingestellt gewesen sei (lt. RR-Pass
Werte zw. 130/80 und 145/90 mmHg). Ansonsten
seien keine weiteren Erkrankungen bekannt.
Risikofaktoren: mäßige Adipositas, Nikotinabusus,
geringer Alkoholkonsum. Laut Angaben des Pat.
besteht seit über 10 Jh. eine art. Hypertonie, die
unter bestehender Therapie immer gut eingestellt
gewesen sei (lt. RR-Pass Werte zw. 130/80 und
Diagnose Ein Bild
114px
Abbildung .: Raster
5.4.2 Farben
Es sollte nur eine primäre Farbe eingesetzt werden: Ein türkis-grün, die Farbe von
Operationskleidung im Krankenhaus. Einige verschiedene Versuche waren notwen-
dig, um die richtige Farbe und Sättigung zu nden. Denn neben dem Farbton soll-
te noch eine Variation durch eine andere Sättigung gefunden werden. Letztendlich
werden in MEDo die Farben (,,) und (, , ) (RGB) eingesetzt (siehe
Abbildungen .c und .d).
(a) (b) (c) (d)
Abbildung .: Farben
49
Kapitel 5 Entwurf
5.4.3 Piktogramme
Das iOS-Soware Development Kit (SDK) bietet einige integrierte Icons an. Diese
sind minimalistisch, zweidimensional und einfarbig. Dem Entwickler steht natürlich
frei andere Icons einzusetzen, aber die meisten Komponenten, die Icons anzeigen
bzw. unterstützen (UITabBar,UIBarButton), konvertieren automatisch den Alpha-
wert in den Weiß-Kanal. Das heißt dass Icons, die diesen Komponenten zugewiesen
werden, nur als Umrisse dargestellt werden. Alle Farbinformationen gehen verloren.
Die Piktogramme im MEDo-System sollten ähnlich einfach sein. Da die Evaluie-
rung an ungeübten Usern geschehen sollte, erschien es am sinnvollsten, möglichst
keine Piktogramme ohne Beschriung einzusetzen. Wiedenbeck [] zeigte, dass
Erstbenutzer erheblich länger brauchen, um die Bedeutung der Symbole zu verste-
hen. Diese Lerneffekte stellen sich nach Lansdale [] vor allem durch die Position
ein, weniger durch das verwendete Symbol selber. Im System sollten somit Symbole
nur eingesetzt werden, wenn zusätzlich eine Beschriung angebracht ist oder wenn
die Funktionalität auch auf anderem Wege zu erreichen ist.
Abbildung . auf der nächsten Seite zeigt mehrere Iconentwürfe. Abbildung
.b zeigt drei Möglichkeiten, wie die Patientenliste symbolha dargestellt werden
kann. Die beiden letzten Icons zeigen durch drei Balken den Listencharakter an. Die-
se Balken stehen zwar in vielen Anwendungen für eine Liste, diese könnte sich aber
auch auf einen einzelnen Patienten beziehen.
Abbildung .d stellt verschiedene Icons dar, mit denen Diagnostika bzw. Medi-
kation dargestellt werden können. Röntgenbilder werden durch eine weiße Kniekno-
chenkontur dargestellt. Charakteristisch ist außerdem, dass die weißen Knochen von
hellem Gewebe umgeben sind. Als Referenz haben hier verschiedene Röntgenbilder
gedient. Eine Kombination von einer Spritze und einer Medikamentenkapsel wurde
als Piktogramm für Medikation entwickelt. Ein Erlenmeyerkolben oder ein Reagenz-
glas in Kombination mit einem Dokument soll einen Laborbericht darstellen.
5.5 Zusammenfassung
ImVerlauf dieses Kapitels wurden alle Screens, die in MEDo dargstellt werden, spezi-
ziert. Dazu wurde eine einheitliche visuelle Sprache gefunden, die Abstände, Typo-
grae, Raster, Farben, Piktogramme und Steuerelemente umfasst. Aufgrund dieser
Spezizierungen konnte nun die Implementierung beginnen. Diese wird im nächs-
ten Kapitel beschrieben.
50
5.5 Zusammenfassung
(a) (b) (c) (d) (e) (f) (g)
Abbildung .: Entwürfe für verschiedene Icons
51
6
Implementierung
Objective-C ist die einzige Programmiersprache, mit der native Anwendungen für
iOS, dem Betriebsystem von Apple iPhone, iPad und (angepasst) auch Apple TV
geschrieben werden können [, ]. Es wäre theoretisch auch die Entwicklung einer
Webanwendung denkbar gewesen. Da dabei o die Geschwindigkeit leidet und das
System nicht offline laufen könnte, wurde diese Idee verworfen.
Objective-C, wie dem Namen bereits zu entnehmen ist, setzt auf die Programmier-
sprache C auf und erweitert diese um objektorientierte Konzepte. Die Geschichte von
Objective-C reicht zurück bis zum NeXTSTEP-Betriebssystem, das veröffent-
licht wurde. Heutzutage wird es neben der Entwicklung für iOS-Geräte auch für Mac
OS X genutzt.
Bei der iOS-Programmierung wird auf das Cocoa Touch API (Application Pro-
gramming Interface) zurückgegriffen. Durch Cocoa Touch werden Hardware- und
Sowarefunktionen abstrahiert. Beispiele von Funktionen, die durch Cocoa Touch
angeboten werden, sind hardwareunterstützte Animationen, Multitasking und Ges-
tenerkennung [, ].
Apple bietet ein SDK an, mit Hilfe dessen Anwendungen geschrieben werden kön-
nen. Darin enthalten ist mit Xcode eine Integrated Development Environment (IDE),
die allerdings nur für OS X verfügbar ist [, ].
Im SDK ist ein Simulator enthalten, der die Ausführung des Codes auch auf i
Geräten ermöglicht. Auf echten Geräten kann Soware nur mit einer kostenpichti-
gen Mitgliedscha im iOS Developer Programm getestet werden. Durch diese Mit-
gliedscha kann man außerdem die entwickelten Applikationen im App Store anbie-
ten, durch den Kunden auf allen iOS-Geräten Applikationen kaufen und installieren
können [].
Cocoa Touch enthält eine Anzahl von Frameworks, die bestimmte Funktionali-
täten anbieten, wie z.B. Karten-Funktionen, Werbeeinblendungen und Spieleunter-
stützung. Das wichtigste Framework neben Foundation Kit, welches Basisklassen
enthält, ist UIKit. Es bietet Klassen, um Benutzeroberfächen in Anwendungen zu
erstellen. Dazu gehören Ereignishandling, Steuerelemente und Verwaltung der Dar-
stellungshierarchie.
Cocoa Touch folgt dem Model View Controller (MVC) Muster. Es handelt sich da-
53
Kapitel 6 Implementierung
bei um ein Sowarearchitekturmuster, bei dem Applikationslogik von Benutzerein-
gabe und -ausgabe getrennt wird. Das Model enthält die Daten der Soware, teilweise
auch die Geschäslogik. Views sind alle Komponenten, die die Daten darstellen und
Eingaben entgegennehmen. Controller übernehmen schließlich die Verarbeitung der
Eingaben und reagieren auf diese, beispielsweise durch Ändern der View.
Je nach Programmiersprache wird das MVC-Muster unterschiedlich angewandt.
Dabei ist das Hauptunterscheidungsmerkmal, ob die View direkt oder nicht direkt
auf die Daten im Model zugrei. Abbildung .b zeigt, das die View bei Cocoa kei-
nen Zugriff hat (im Gegensatz zu Java, Abbildung .a), sondern vom Controller mit
Daten versorgt wird.
Im Folgenden wird die Implementierung eingeteilt in die Komponenten Model,
View und Controller dargestellt.
(a) Java (b) Cocoa Touch
Abbildung .: Model View Controller
6.1 Model
Das Model besteht in vielen Fällen hauptsächlich aus einer Anbindung an eine Da-
tenbank. So verhält es sich auch bei MEDo. Die Anbindung an externe Systeme wie
beispielsweise die jeweiligen KISs wäre sehr zeitintensiv gewesen. Da möglichst viele
Stationen in unterschiedlichen Krankenhäusern angesprochen werden sollten, wur-
de auf die Entwicklung entsprechender Schnittstellen verzichtet. Stattdessen wurde
eine Datenbank aufgesetzt, welche mit Demodaten gefüllt ist. So erhält der Benutzer
den Eindruck, dass es sich um ein aktives System handelt.
Im Hintergrund läu sich eine SQL-Datenbank (sqlite). Diese wird durch das Core
Data Framework angesprochen. Dieses Framework unterstützt den Programmierer
dadurch, dass Persistenz und Funktionalitäten wie Rückgängig automatisch zur Ver-
fügung stehen. Es bildet eine Schicht, so dass Modellbeschreibungen automatisch in
Klassenbeschreibungen umgewandelt werden. Das Framework hält nur die nötigsten
Daten im Speicher (lazy loading).
54
6.1 Model
6.1.1 ER-Modell
Das Datenbankmodell lässt sich logisch in die drei Säulen Patientendaten, Aufgaben-
management und Organisation/Arbeitsmittel einteilen. In den folgenden Abschnit-
ten werden diese beschrieben. Abbildung . zeigt das UML-Datenbankmodell.
Abbildung .: Datenbankauau in UML-Notation. Der Bereich Patientendaten ist grün hin-
terlegt, der Bereich Aufgabenmanagement blau. Organisation/Arbeitsmittel sind nicht hin-
terlegt.
Patientendaten
Zu den Patientendaten zählen die Basisdaten wie Name, Alter, Aufnahmedatum und
Patientenidentikation. Für die medizinische Informationsverarbeitung sind weiter-
hin die Anamnese, die sich weiter in Medikativ-, Sozial- und Familienanamnese un-
terteilen lässt, und die aktuelle Diagnose von Interesse. Darüber hinaus können Pati-
enten Untersuchungsergebnisse zugeordnet haben. Davon sind Labor, bildgebende
Diagnostik und Konsile im System implementiert.
Das Ergebnis einer Laboruntersuchung wird in LabResult gespeichert. Jedes La-
bResult besteht aus mehreren Teiluntersuchungen, die als LabResultSections mo-
delliert sind. Diese haben einen Titel und enthalten mehrere LabResultRows, die den
Test, das Ergebnis, die Einheit und erwartetem Normwert angeben.
55
Kapitel 6 Implementierung
Ein DiagnostImagSet, also beispielsweise ein Ergebnis einer Röntgenuntersu-
chung, enthält mehrere DiagnosticImages, die zum einen jeweils einen Kommentar
haben können, zum anderen die binären Bilddaten enthalten. Im Demo-System sind
dies PNG- sowie JPG-Dateien.
Ein Konsil wird als unformatierter Text im System gespeichert, der optional auch
einen Titel haben kann.
Jedem Patient können auch Formulare (Form) zugordnet werden. Diese bestehen
aus Feldern (FormDataSet), die jeweils als Schlüssel-Wert-Paar gespeichert werden.
Diese Datenstruktur macht es möglich, sehr verschiedene Formulare im System zu
speichern. Je nach Formular-Typ kann das Formular dem Benutzer anders darge-
stellt werden. Der jeweilige Formularcontroller liest die Daten zu den zum Formular
gehörenden Schlüsseln aus und stellt sie auf dem Formular dar, bzw. speichert sie ab.
Aufgabenmanagement
Nachdem mit den Patientendaten die datenzentrierte Sicht abgedeckt ist, müssen die
Strukturen für die prozessorientieren Daten deniert werden. Die wichtigsten Ele-
mente sind hier ProcessInstance und Task.
Aufgaben werden durch Tasks modelliert. Sie haben als Attribute einen Schalter,
ob sie bereits abgeschlossen sind, einen Text, die Rolle, die die Aufgabe ausführen
soll und das Datum an dem sie erstellt und abgeschlossen wurden. Weiterhin ha-
ben sie einen Mitarbeiter, der die Aufgabe abgeschlossen hat. Sie können außerdem
eine Verknüpfung zu einem Formular oder einer Diagnostik haben. Aufgaben kön-
nen eine Audioaufnahme assoziert haben. Diese wird in einer zusätzlichen Tabelle
(AudioRecording) gespeichert, damit die Daten nur geladen werden müssen, wenn
explizit auf sie zugegriffen wird, um die Speicherverwendung gering zu halten.
Eine Prozessinstanz ist einem Patienten zugeordnet und hat einen Arzt oder Ärz-
tin, der sie erstellt hat. Sie kann auf einer Prozessbeschreibung basieren (siehe dazu
Abschnitt . auf Seite ). Dies wird durch das Attribut processID gekennzeichnet.
Ist es nicht gesetzt, so handelt sich um einen einzelnen Arbeitsschritt. Die Attribute
startTask,endTask und activeTask geben an, welcher der Aufgaben, die in tasks
aufgeführt sind, die erste, letzte und aktive Aufgabe ist. Dabei wird logischerweise
endTask erst gesetzt, wenn bei dem Prozess die letzte Aufgabe abgeschlossen ist. Das
Attribut tasks enthält nicht von Anfang an alle Aufgaben, sondern nur die aktuelle
und bereits abgeschlossene. Es wäre also möglich, Flexibilität in den Prozessen zu
unterstützen.
Organisation und Arbeitsmittel
Im System werden Stationen (Ward) mit Räumen und Betten modelliert. Ein Bett
kann einem Patienten zugeordnet sein. Stationen, Räume und Betten haben jeweils
eine Bezeichnung oder Nummer.
56
6.2 View
Bereits erwähnt wurden Mitarbeiter (Employee). Diese haben eine IS-A-Bezie-
hung zu Person und fügen dessen Attributen Vorname, Nachname, Geschlecht und
Geburtstag die Personalnummer und ein Kennwort hinzu. Auch Patient hat eine
IS-A-Beziehung zu Person.Employee hat die Subklassen Physician (Arzt/Ärztin)
und Nurse (KrankenpegerIn), die zur Unterscheidung der Rollen im System die-
nen.
6.2 View
Das iOS SDK bietet seit Version . eine Möglichkeit an, alle Instanzen einer Steue-
relementklasse zu ändern. Dazu steht dem Entwickler das UIAppearance-Protokoll
zur Verfügung. Dieses Protokoll verstehen die meisten UIKit-Klassen. Die Verwen-
dung ist sehr einfach: Anstatt beispielsweise den setTintColor: Befehl an eine In-
stanz zu schicken, muss dieser an den Proxy appearance der Klasse geschickt wer-
den: [[UIBarButtonItem appearance] setTintColor:[UIColor blackColor]].
Um dem Styleguide zu genügen, wurden fast alle Komponenten umgestaltet. Ei-
nige Beispiele sind in Abbildung . dargestellt. Für die beiden Komponenten UI-
SegmentedControl,UIBarButtonItem und UINavigationBar wird jeweils erst das
Aussehen vor und nach der Anwendung der Änderungen gezeigt.
(a) UISegmentedControl (b) UISegmentedControl angepasst
(c) UINavigationBar
(d) UINavigationBar angepasst
Abbildung .: Angepasste Interface-Elemente
Durch diese leichte Anpassbarkeit war es nur sehr selten nötig, eigene Steuerele-
mente zu programmieren. Hervorzuheben ist das Steuerelement, welches es ermög-
licht, Textbausteine in den Text einzufügen. Die Funktionsweise wird im folgenden
Abschnitt erklärt.
6.2.1 MDTextModuleListControl
MDTextModuleListControl erbt von UIControl und stellt eine Liste von Strings
durch Buttons dar (siehe Abbildung . auf der nächsten Seite). Diese Buttons fügen
bei Berührung ihre Beschriung in ein vorher angegebenes UITextView ein, wobei
57
Kapitel 6 Implementierung
diese Bewegung mit einer Animation begleitet wird. UIControl ist die Basisklas-
se für alle Steuerelemente, die nicht nur der Darstellung dienen (UIView), sondern
auch auf Interaktionen des Benutzers reagieren. Es bietet damit eine einheitliche
Schnittstelle für Steuerlemente wie Buttons und Slider. Diese Objekte unterstützen
den target-action-Mechanismus, so dass Methoden für bestimmte Aktionen (wie
Berühren und Wischen) registriert werden können.
Abbildung .: MDTextModuleListControl nach Antippen des Buttons „Medikation“
Das öffentliche Interface der Klasse ist sehr simpel (siehe folgendes Listing). Es
bietet ein Array für die Textbausteine und ein UITextView, in das die Werte eingefügt
werden sollen.
@interface MDTextModuleListControl :UIControl
@property (nonatomic, strong) NSArray *values;
@property (nonatomic, strong) UITextView *textView;
@end
Zusätzlich besitzt die Klasse noch ein verstecktes Interface (siehe folgendes Lis-
ting), das Methoden enthält, die nicht öffentlich sind:
@interface MDTextModuleListControl (hidden)
-(void)updateButtons;
-(CGPoint)carretPositionInTextView:(UITextView *)textView;
-(void)didSelectTextModule:(NSString *)string
inRect:(CGRect)sourceRect;
@end
Die Methode (void)updateButtons wird aufgerufen, wenn sich die values-
Property ändert. Sie instanziiert und platziert die Buttons auf dem Steuerelement.
Wenn ein Button nicht mehr in die aktuelle Zeile passt, rutscht dieser in die nächste
Zeile.
Bei Berührung eines Buttons wird die Beschriung des Buttons in das UITextView
bewegt. Dafür wird ein temporäres UILabel mit gleicher Beschriung erstellt und
über dem Button platziert. Von dieser Position aus wird das Label nun zur Zielkoor-
dinate, der Selektionsmarke im UITextView, bewegt. Nach Abschluß der Animation
wird das Label entfernt und der Textblock im UITextView hinter der Selektionsmar-
ke eingefügt.
58
6.3 Controller
lt. Angaben des Pat. besteht seit über
zehn Jahren eine art. Hypertonie, die
unter best. Therapie.
x
y
Abbildung .: Berechnung der Koordinaten zum
Einfügen des Textes. Der blaue Rahmen stellt die
Begrenzung des Textes bis zur blauen Einfügemar-
ke dar. Wird die Größe des Textes bis zur grünen
Marke berechnet, so entsteht das grüne Rechteck.
Die Positionsbestimmung des aktuellen Textcursors
innerhalb eines UITextView wird nur in der Form
„Zeichen von X bis Y sind selektiert“ unterstützt. Lei-
der ist keine direkte Abfrage der Pixelkoordinaten
möglich. Aus diesem Grund wird die Methode (CG-
Point)carretPositionInTextView: benötigt. Sie ver-
sucht zu schätzen, welche Koordinaten der Textcursor
im angegeben UITextView hat.
Für die Positionsbestimmung wird die Höhe des Text
von Textanfang bis Selektionsindex gespeichert. Ausge-
hend von dem Selektionsindex wird der Index nun je-
weils um die Länge des letzten Wortes verkürzt. Sobald dadurch die Höhe des Textes
verringert wird – der Text also eine Zeile weniger benötigt –, kann die Länge der letz-
ten Zeile aus der Größe der Box um den Text zwischen Selektionsindex und Index
vor der Verringerung berechnet werden (siehe Abbildung .). Aus der Höhe des
Textblocks kann die Y-Koordinate berechnet werden. Diese Methode funktioniert
in den meisten Fällen, ist aber von der Arbeitsweise der Layoutengine abhängig, wie
diese den Text umbricht. Sollte sich daran etwas ändern, funktioniert die Methode
nicht mehr.
6.3 Controller
Controller im iOS-SDK sind in einen bestimmten Darstellungsbereich verantwort-
lich für die Koordination von Interface-Elementen, die Reaktion auf Benutzerinter-
aktionen und das Übersetzen der Informationen vom Model in die Benutzerober-
äche. Alle Controller sind abgeleitet von der Klasse UIViewController und sind
immer einem View zugeordnet.
Sie sind in die sogenannte responder chain (etwa „Antwortsender-Kette“) einge-
bettet. Alle Views, Windows und die Applikation selbst benden sich in dieser Ket-
te. Wenn der Benutzer mit dem Finger den Bildschirm berührt, wird ein Ereignis
erzeugt. Angefangen vom tiefsten Element in der responder chain wird jeweils er-
fragt, ob das View-Objekt das Ereignis verarbeiten möchte. Wenn nicht, wird das
Ereignis weiter die Ereigniskette heraufgereicht. Eine Ausnahme sind Views, welche
einem Controller zugeordnet sind. Diese Views geben stattdessen das Ereignis an ih-
ren Controller weiter. Hier kann der Controller entscheiden, was mit diesem Event
passieren soll. Controller werden außerdem über Orientierungsänderungen infor-
miert.
View Controller können andere modal anzeigen oder sie als Kinderelemente un-
terordnen und verwalten. Es gibt verschiedene Unterklassen von View Controllern,
die spezielle User Interface Patterns unterstützen. Beispielsweise UINavigationCon-
troller: Dieser Controller arbeitet wie ein Stack. Intial liegt ein View Controller
59
Kapitel 6 Implementierung
darauf. Jeweils der oben liegende Controller wird angezeigt. Weitere können auf den
Stack geschoben werden (push). Beim Entfernen eines Controllers (pop) wird der
vorherige angezeigt. Dem Benutzer kann eine Navigationsleiste präsentiert werden,
die automatisch einen „Zurück“-Knopf enthält, sowie den Titel des aktuellen Con-
trollers. Veränderungen werden entsprechend durch Animationen nach links (Hin-
zufügen) und rechts (Entfernen) animiert.
Controller können in Xcode grasch orchestriert werden. Diese Modellierung
wird auf einem sogenannten Storyboard vorgenommen. Durch Verbindungen zwi-
schen Steuerelementen und Controllern kann der Programmierer angeben, dass
durch eine Berührung dieser Controller eingeblendet wird. So kann sehr viel der
Interaktion zwischen Controllern grasch zusammengefasst und übersichtlich an
einem Ort geschehen.
Abbildung . zeigt einen Ausschnitt aus dem Storyboard für MEDo. Zu sehen ist
links der initiale Controller, der nach Applikationsstart angezeigt wird – ein Navi-
gationscontroller (). Dieser zeigt eine Login-Ansicht () an, auf den nach erfolgrei-
cher Anmeldung der Stationsschirm () folgt. Von hier aus kann der Benutzer zum
Patientenbildschirm () navigieren, eine neue Aufgabe erstellen () oder eine beste-
hende Aufgabe in einem modalen Fenstern öffnen (). Alle diese Controller werden
im weiteren Verlauf dieses Abschnittes beschrieben und erklärt.
1 2 3 4
5
6
Abbildung .: Storyboardausschnitt. Zu sehen sind () Navigationscontroller, () Login, ()
Stationsschirm, () Patientenbildschirm, () Neue Aufgabe und () bestehende Aufgabe an-
zeigen.
60
6.3 Controller
6.3.1 LoginViewController
Nach dem Start der Anwendung MEDo muss der Benutzer sich authentizieren. Dies
geschieht durch eine Kombination von Benutzernamen und Kennwort. Beides wird
in zwei Textfelder eingetragen, die automatisch den Fokus bekommen (siehe Ab-
bildung . auf der nächsten Seite). So kann der Benutzer direkt seinen Benutzerna-
men eintippen. Das System blendet automatisch eine Liste von zur aktuellen Eingabe
passenden Benutzernamen ein, so dass der Name nicht komplett ausgetippt werden
muss. Bei Auswahl eines Eintrags aus der Liste springt der Fokus in das Kennwort-
feld. Nach dem dieses eingegeben wurde, tippt der Benutzer auf „Anmelden“ (oder
„Öffnen“ auf der Tastatur).
Visuell ist der Anmeldebildschirm schlicht gehalten. Der Bildschirm wird von dem
MEDo-Logo sowie dem Formular dominiert. Der grüne Hintergrund entspricht den
Systemfarben. Der gleiche Hintergrund wird auch genutzt, um den kurzen Augen-
blick zu überbrücken während die Anwendung nach dem Start geladen wird (siehe
Abbildung .).
Abbildung .: Start-Bildschirm
61
Kapitel 6 Implementierung
Abbildung .: Login-Bildschirm
62
6.3 Controller
6.3.2 OverViewController
Die Stationsübersicht ist die zentrale Anlaufstelle für den Benutzer. Von hier aus kön-
nen sowohl alle Patienten als auch alle Aufgaben aller Patienten eingesehen werden
(siehe Abbildung . auf der nächsten Seite).
Der Stationsbildschirm enthältoben eine große Navigationsleiste, die den Titel des
Bildschirms und zwei Buttons, die den Benutzer abmelden bzw. eine neue Aufga-
be erstellen, enthält. Darunter benden sich zwei Listen. Eine enthält alle Patienten,
sortierbar nach Name oder nach Raum, die andere alle Aufgaben. Sind die Patienten
nach Raum sortiert, werden Unterteilungen eingeblendet.
Die Aufgabenliste ist untergliedert in Bereiche für aktive und abgeschlossene Auf-
gaben und stellt im Normalfall die Aufgaben aller Patienten dar. Der Status wird
zusätzlich über ein Markierungsfeld vor dem Text der Aufgabe angezeigt. Der Na-
me des Patienten wird unter dem Aufgabentext eingeblendet. Neben der Aufgabe
können verschiedene Symbole dargestellt werden: So kann angezeigt werden, dass es
sich um einen Prozess handelt, der gerade bei einer anderen Person liegt (Zahnräder,
graue Schri), dass ein Formular auszufüllen ist (Dokument) oder Untersuchungser-
gebnisse anzuschauen sind (Röntgenbild). Es gibt die Möglichkeit, die Aufgabenliste
nur nach den Aufgaben für einen bestimmten Patienten zu ltern, indem der kleine
Pfeil neben dem Namen des Patienten angetippt wird.
Jede dieser Tabellen ist an eine Datenquelle angeschlossen, die die Daten aus dem
Model in die Benutzeroberäche übertragen. An dem Beispiel der Patientenliste soll
die Funktionsweise dieses Objekts erklärt werden. Eine Datenquelle für eine Tabel-
le muss das Protokoll UITableViewDataSource implementieren. Es deniert End-
punkte, die die Tabelle anfragen kann, um sich selbst darzustellen.
Die wichtigsten Methoden sind tableView:NumberOfRowsInSection: und tab-
leView:cellForRowAtIndexPath:. Die erste Funktion macht der Tabelle bekannt,
wieviele Zellen diese anzeigen muss. Listing auf Seite demonstriert den Ablauf
der zweiten Funktion. Die aufrufende Tabelle erwartet von dieser Methode eine Ta-
bellenzelle (UITableViewCell) zurück, die auf die Tabelle gezeichnet wird.
Diese Tabellenzellen sollten aus Performanzgründen wiederbenutzt werden. Das
heißt, dass Tabellenzellen, die aus dem dargestellten Bild verschwinden, nicht ver-
nichtet, sondern auf einen Stack gelegt werden. Sobald die eine neue Tabellenzel-
le – beispielsweise durch Scrollen – dargestellt werden muss, wird keine neue er-
stellt, sondern stattdessen eine bereits existierende vom Stack genommen. So kann
der durch Löschen und Erstellen von Objekten im Speicher entstehende Overhead
vermieden werden.
Der richtige Patient wird durch den Parameter indexPath ermittelt. Dieser zwei-
teilige Index enthält jeweils einen Wert für die Sektion (Tabellen können in Sektionen
unterteilt werden) und einen für die Tabellenreihe. Anhand dieser Daten und einem
entsprechend aufgebauten, zweidimensionalen Array kann der passende Patient aus-
gewählt werden. Der Name wird anschließend in einem Label der Tabellenzelle darg-
63
Kapitel 6 Implementierung
Abbildung .: Stationsübersicht
64
6.3 Controller
-(UITableViewCell *)tableView:(UITableView *)tableView
cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
// get the correct patient for the index path
Patient *patient =[self patientForIndexPath:indexPath
inTableView:tableView];
// dequeue one cell from the stack of unused cells
static NSString *cellIdentifier =@”PatientCell”;
UITableViewCell *cell =[tableView
dequeueReusableCellWithIdentifier:cellIdentifier];
// […]
// fill the cell with our patients data
cell.textLabel.text =[NSString stringWithFormat:@”%@, %@”,
patient.lastName, patient.firstName];
// […]
return cell;
}
Listing : Befüllen einer Tabellenzelle mit Inhalt
stellt. Auf diese Weise aufgebaute Datenquellen können einfach an anderer Stelle im
Projekt wiederverwendet werden.
6.3.3 PatientViewController
Die Patientenansicht besteht aus mehreren Unterkomponenten. Der Bildschirm ist
unterteilt in den oberen Navigationsbereich, einer Reiterleiste sowie den Inhalten der
Reiter darunter (siehe Abbildung . auf der nächsten Seite).
Der Navigationsbereich am oberen Bildschirmrand ist größer als die normale Na-
vigationsleiste in iOS. Nur so passen alle benötigten Buttons in die begrenzte Fläche.
Zusätzlich können so Geschlecht, Alter und Bett des Patienten angezeigt werden.
Dies sind die wichtigsten Informationen zum Patienten und sind auf den anderen,
den Patienten betreffenden, Bildschirmen auch verfügbar. Wie auf der Stationsüber-
sicht kann auch hier eine neue Aufgabe durch einen Button oben rechts erstellt wer-
den. Diese gleiche Position macht es für den Benutzer leichter die Funktion wie-
derzunden, egal auf welchem Bildschirm er sich bendet. Buttons zum direkten
Vor- und Zurücknavigieren zwischen Patienten in alphabetischer Reihenfolge wer-
den ebenfalls angeboten. Wichtiger ist aber der Button, um direkt die Patientenliste
anzuzeigen. Hier hat der Benutzer die gleichen Sortieroptionen wie auf dem Start-
bildschirm, ohne dass er seinen aktuellen Kontext verlassen muss.
Die Reiter unter dem Navigationsbereich teilen die Patientendaten logisch in
vier Kategorien (exklusive der Übersicht), entsprechend Abschnitt . auf Seite :
Anamnese, Vitaldaten, Diagnostik und Medikation. Diese werden in den folgenden
Abschnitten erläuert.
65
Kapitel 6 Implementierung
Abbildung .: Patientenbildschirm
66
6.3 Controller
Übersicht
Die Übersicht fasst alle Daten, die meist auf den anderen Reitern zu nden sind,
gesammelt in einer Sicht zusammen. So können Anwender sich schnell einen Über-
blick über den Status und den Fortschritt des Patienten machen. Es werden allgemei-
ne Informationen wie das Alter, in welchem Bett der Patient liegt, ob er über eine
Patientenverfügung verfügt, welcher Mediziner ihn aufgenommen hat, Kontaktin-
formationen und Name des Hausarztes sowie eventuelle Allergien angezeigt. Wich-
tig ist, dass Diagnose und Anamnese schnell einsehbar sind []. Der Anwender hat
von hier aus auch Zugriff auf die Aufgaben.
Diagnostika
Bei der Visite sind die verschiedenen Diagnostika die essentiellen Daten. Diese kön-
nen in diesem Reiter eingesehen werden. Alle Untersuchungsergebnisse des Patien-
ten werden in Listenform auf der linken Seite angezeigt, während Details zur aus-
gwählten Untersuchung rechts im größeren Bereich dargestellt werden (siehe Abbil-
dung . auf der nächsten Seite). Abhängig vom Untersuchungstyp wird im rech-
ten Bildschirmbereich einer der drei Controller DiagnosticImageViewController
(Ergebnisse von bildgebenden Untersuchungen), CouncilViewController (Konsi-
le) und TestResultViewController (Laborergebnisse) instanziiert.
Bildgebende Untersuchungen Der DiagnosticImageViewController baut auf
dem Photo Album View Controller des Nimbus Framework auf und stellt eine Da-
tenquelle für diesen Controller bereit. Diese Datenquelle ist ähnlich der von Tabellen
aufgebaut, liefert allerdings Bilder statt Tabellenzellen zurück. Die Komponente aus
dem Nimbus Framework wird von einem Anzeigebereich dominiert, den der Con-
troller mit einem Bild füllt. Durch Wischen nach links und rechts kann zwischen
Bildern horizontal navigiert werden. Zoomen und Verschieben des Bildausschnitts
mittels Gesten werden auch unterstützt. Zur Übersicht wird außerdem eine Werk-
zeugleiste im unteren Bildschirmbereich eingeblendet, die umbnails der Bilder
enthält.
Wichtig bei der Implementierung war in Anbetracht der meist hochaufgelösten
Röntgenbilder, Caching für die umbnails und Nebenläugkeit zu realisieren. An-
sonsten kann es zu Blockierungen der Benutzerschnittstelle kommen.
iOS bietet verschiedene Arten um mit Nebenläugkeit umzugehen. Bei der Wahl
sollte mit der Methode mit der größten Abstraktion begonnen werden. Je nach Be-
darf sollte dann auf kompliziertere Methoden zurückgegriffen werden. Im konkre-
ten Fall wurde Grand Central Dispatch (GCD) eingesetzt. GCD macht es einfach für
mehrere Prozessoren zu programmieren, indem es von diesen abstrahiert. Die Vor-
gehensweise, um mithilfe von GCD Vorschaubilder zu konstruieren, wird in Listing
http://nimbuskit.info/, Abruf am . März
67
Kapitel 6 Implementierung
Abbildung .: Patientenbildschirm – Diagnostika
68
6.3 Controller
vorgestellt.
// obtain queue and add task to it:
// loading all images and storing a thumbnail of them in an array
dispatch_queue_t queue =dispatch_get_global_queue(
DISPATCH_QUEUE_PRIORITY_LOW, 0ul);
dispatch_async(queue, ^{
NSMutableArray *thumbnails =[NSMutableArray
arrayWithCapacity:self.diagnosticImages.count];
for (DiagnosticImage *diagnosticImage in self.diagnosticImages)
{
// generate thumbnail and add to thumbnail array[…]
}
// add thumnails to toolbar (in main/gui thread)
dispatch_sync(dispatch_get_main_queue(), ^{
// […]
});
});
Listing : Einsatz von GCD um Vorschaubilder zu generieren
Wichtig ist dabei, dass alle Operationen, die die GUI betreffen, im Hauptthread
ausgeführt werden. Analog zu diesem Code geschieht auch das Laden der großen
Bilder. Diese werden asynchron aus der Datenbank geladen, da die Animationen
ansonsten nicht üssig angezeigt werden.
Konsile Der CouncilViewController ist sehr einfach aufgebaut, da hier nur der
Text und die Überschri des Konsils dargestellt werden muss.
Laborergebnisse Ergebnisse aus dem Labor werden in einer einfachen Tabellen-
Ansicht dargestellt (siehe Abbildung . auf der nächsten Seite). Diese ist in Sek-
tionen, entsprechend den Teiluntersuchungen geordnet. Die Tabelle bleibt durch ei-
ne feste, nicht mitscrollende Tabellenkopfzeile lesbar, wenn der Benutzer weit nach
unten gescrollt hat. Der Controller ist gleichzeitig auch Datenquelle für die Tabelle.
Wenn neue Testergebnisse gesetzt werden, bringt er diese auch in eine für die Dar-
stellung zweckdienlichere Datenstruktur.
Untersuchungen anfordern Der Benutzer kann direkt aus dem Diagnostikbild-
schirm weitere Untersuchungen anfordern. Anforderungen werden in der Liste der
Diagnostika in einer eigenen Sektion angezeigt. Hier verbleiben diese, bis sie abge-
schickt werden. Die Anforderungen sind als Datentyp Form modelliert. Alle Formu-
lare bieten unten rechts eine Option, um sie abzusenden. Das System kennt drei ver-
schiedene Formulare, die den unterstützten Prozessen entsprechen: Konsil, Röntgen-
und Laboruntersuchung. Dabei sind sich Konsil- und Röntgenanforderung inso-
fern ähnlich, dass bei beiden die Eingabe durch Ausfüllen von Textfeldern geschieht:
69
Kapitel 6 Implementierung
Anamnese, Indikation, Fragestellung und die gewünschte Untersuchung (nur bei
Röntgenuntersuchungen).
Eine andere Darstellung wird bei der Anforderung einer Laboruntersuchung ge-
nutzt (siehe Abbildung .). Hier werden dem Benutzer eine Liste von Schaltern
angeboten, durch die er die gewünschten Untersuchungen aktiviert. Um dies für
den Anwender zu vereinfachen, gibt es zusätzlich Schalter, die häug genutzte Un-
tersuchungen zusammenfassen (wie große und kleine Blutuntersuchungen). Diese
Modellierung ist analog zu den Laboranforderungen gehalten, wie sie in den Kran-
kenhäusern eingesetzt werden.
Abbildung .: Patientenbildschirm – Laborergeb-
nisse
Abbildung .: Patientenbildschirm – Laboruntersu-
chung anfordern
Medikation
Die Medikation ist im Demonstrator statisch. Es werden zwei Tabellenzeilen einge-
blendet, die demonstrieren sollen, wie der Bildschirm aussehen könnte (siehe Abbil-
dung . auf der nächsten Seite).
Vitaldaten
Genauso wie bei der Medikation handelt es sich bei den Vitaldaten um einen stati-
schen Bildschirm, um das System glaubha zu gestalten (siehe Abbildung . auf
der nächsten Seite).
70
6.3 Controller
Abbildung .: Patientenbildschirm – Medikation Abbildung .: Patientenbildschirm – Vitaldaten
6.3.4 NewTaskViewController
Neue Aufgaben können schnell über den immer ereichbaren „Neue Aufgabe“-Button
auf jedem Screen in der oberen rechten Ecke erstellt werden. Der NewTaskViewCon-
troller ist für die Annahme dieser Informationen konzipiert. Er bietet eine Patien-
tenauswahl, ein Texteingabefeld, ein Modul um Textbausteine einzufügen und einen
Button um eine Audioaufnahme zu starten (siehe Abbildung . auf der nächsten
Seite). Dem Controller zugrunde liegt eine Tabelle, bei der die einzelnen Elemente
in den verschiedenen Zellen liegen.
Die Patientenauswahl ist so gestaltet, dass nach Antippen darunter eine Liste von
Patientennamen ausklappt. Anfangs wurde hier ein Popup eingesetzt, welches al-
lerdings eine weitere Ebene einführt, die Interaktionen mit anderen Elementen der
Sicht nicht ermöglicht. In dieser Liste kann der Benutzer durch Wischen schnell zum
gewünschten Patienten scrollen, ohne dass dadurch die Interaktion mit den anderen
Elementen auf der Seite gestört ist. Die Patientenliste wird ausgeblendet, sobald ein
Patient ausgewählt wird.
Eingaben auf der Bildschirmtastatur, die automatisch eingeblendet wird, werden
in das Textfeld zur Eingabe des Aufgabentextes gerichtet. Zusätzlich kann der Benut-
zer durch die Textbausteine darunter schnell häug benutzte Ausdrücke einfügen.
Abschnitt .. auf Seite erklärt die Implementierung der Komponente.
Neben den beiden genannten Optionen gibt es noch die Möglichkeit, weitere In-
71
Kapitel 6 Implementierung
Abbildung .: Bildschirm: Neue Aufgabe erstellen
72
6.3 Controller
formationen per Audioaufnahme der Aufgabe hinzuzufügen. Dafür wird intern eine
Instanz der Klasse AVAudioRecorder aus dem AVFoundation Framework genutzt.
Sie bietet eine Abstraktion, mit der sehr einfach Audio aufgenommen werden kann.
Startet der Benutzer den Aufnahmevorgang, beginnt der Audiorekorder, die Daten
in eine temporäre Datei zu schreiben. Beendet der Benutzer die Aufnahme, lädt der
Controller die Daten in den Speicher. So kann der Benutzer sich direkt die Aufnahme
anhören, wofür wiederum eine Instanz von AVAudioPlayer genutzt wird. Damit der
Benutzer ein visuelles Feedback erhält, dass die Aufnahme funktioniert und er später
auch zu verstehen ist, wird eine kleine Anzeige eingeblendet, die die Aufnahmelaut-
stärke durch die Helligkeit eines Kreises zeigt. Um die Darstellung zu skalieren, wird
die aktuelle Lautstärke durch die Durchschnittslautstärke geteilt.
6.3.5 TaskViewController
Um dem Benutzer die Orientierung zu erleichtern, ähneln sich die Ansichten zum
Anzeigen und zum Erstellen von Aufgaben stark. Ausser dem Patientennamen wer-
den Aufgabentext, Erstellungsdatum und Autor der Aufgabe angezeigt. Durch Be-
rühren des Patientennamens kann der Benutzer schnell zur Detailansicht des Pati-
enten springen. Bei abgeschlossenen Aufgaben wird zusätzlich angezeigt, wer wann
die Aufgabe abgeschlossen hat. Hat der Ersteller der Aufgabe eine Audioaufnahme
erstellt, so wird ein Button angezeigt, um die Aufnahme wiederzugeben und zu stop-
pen.
Ein großer Button unter dieser Anzeige zeigt die zur Aufgabe passenden Aktionen
an. Wenn beispielsweie ein Röntgenbild eingetroffen ist, leitet der Button den Benut-
zer zum entsprechenden Bild. Bei auszufüllenden Formularen wird zum Formular
navigiert. Handelt es sich um eine einfache Aufgabe, ohne angebundenen Prozess,
markiert dieser Button die Aufgabe als erledigt und blendet das Fenster aus.
Der Benutzer hat jederzeit die Möglichkeit, von ihm selbst angelegte Arbeitsschrit-
te zu ändern. Hierzu braucht er nur auf den „Ändern“-Button in der rechten oberen
Ecke des Fensters zu tippen. Es öffnet sich ein von NewTaskViewController erben-
des Fenster, bei dem die Auswahl des Patienten deaktiviert ist. So können bereits
erstellte Aufgaben schnell geändert werden.
6.3.6 MDPortraitSplitViewController
Ein häuges Muster sind Ansichten, die gleichzeitig eine Übersicht anbieten (Mas-
ter), auf Wunsch aber auch Details zu einem Punkt anzeigen (Detail). Als Beispiel
kann eine E-Mail-Anwendung betrachtet werden. Im linken Bereich werden alle E-
Mails im aktuellen Postfach angezeigt. Bei Auswahl einer E-Mail wird diese darauf-
hin im rechten Bereich angezeigt. Eine Variation ist die Anzeige über- beziehungs-
weise untereinander. Dieses Designmuster wird von Tidwell [, S. ] two panel
73
Kapitel 6 Implementierung
Abbildung .: Bildschirm: Aufgabendetails anzeigen
74
6.3 Controller
selector genannt. Auf dem iPad wird es von Apple durch einen speziellen Controller
unterstützt, den sogenannten SplitViewController.
Da ein iPad verschiedene Orientierungen unterstützt und die Portraitorientierung
dabei horizontal weniger breit ist, wird in dieser Orientierung der two panel selec-
tor aufgegeben. Stattdessen wird ein Button in der Navigationsleiste platziert, mit-
hilfe dessen den der Benutzer die Master-Liste angezeigen kann (siehe dazu Abbil-
dung .). So kann horizontal Platz eingespart werden.
(a) Portrait (b) Landscape
Abbildung .: Darstellung des normalen UISplitView in verschiedenen Orientierungen
Für die Übersicht der Diagnostika ist dies nicht erwünscht, da einerseits die Aus-
wahl über den Buttonumständlichist(undnichtsehr einleuchtend für den Benutzer)
und andererseits der Button bedeuten würde, unter der Patientenleiste eine weitere
Toolbar einzusetzen. Es musste also eine eigene Klasse geschrieben werden, die diese
Split-Funktionalität besitzt und auch im Portrait-Modus anzeigt. Zusätzlich war aber
auch eine Anforderung, dass der Benutzer die Master-Ansicht ausblenden kann, falls
er mehr vom Detailinhalt sehen möchte. Die wichtigsten Attribute, die diese Klas-
se also öffentlich machen sollte, sind die Controller für Detail- und Masteransicht.
Entsprechend einfach ist das Interface von MDPortraitSplitViewController:
@interface MDPortraitSplitViewController :UIViewController
@property (strong, nonatomic) UIViewController *masterViewController;
@property (strong, nonatomic) UIViewController *detailViewController;
@end
Jeweils wenn der Master- oder der Detail-Controller gesetzt werden, wird das
entsprechende View auf der controllereigenen View platziert und der Controller
Mehr Informationen zum two-panel selector Pattern nden sich auf der Website der Autorin: http:
//designinginterfaces.com/patterns/two-panel-selector/
75
Kapitel 6 Implementierung
als Child-Controller hinzugefügt. Dem Master-Controller wird zusätzlich noch ein
Swipe Gesture Recognizer hinzugefügt. Gesture Recognizer erkennen Gesten wie
Swipes (Wischgesten), Pinch (Finger zusammenziehen) usw. Dazu stehen verschie-
dene Unterklassen der abstrakten Klasse UIGestureRecognizer zur Verfügung, die
jeweils eine Gestenart erkennen. Der Gesture Recognizer im MDProtraitSplitView-
Controller soll Wischgesten nach links erkennen (UISwipeGestureRecognizer mit
dem Attribut direction = UISwipeGestureRecognizerDirectionLeft). Auf diese
Weise kann der Benutzer die Master-Liste auf der linken Seite durch ein Wischen
nach links animiert verkleinern. Da es sich um eine kleine Bewegung handelt, reicht
eine Dauer von ca. , Sekunden. Zusätzlich zur Bewegung wird auch die Liste ver-
dunkelt, so dass diese inaktiv erscheint.
Um die Master-View wieder anzuzeigen, kann der Benutzer entweder wieder eine
Wischbewegung nach rechts machen oder die Liste berühren.
6.4 Workowunterstützung im System
Um den Arbeitsaufwand im Rahmen zu halten, und weil es keinen Einuss auf
die Wahrnehmung beim Benutzer hat, wurde auf die Unterstützung oder Anbin-
dung eines richtigen WfMS verzichtet. Stattdessen wurde eine sehr einfache, au-
tomatische Unterstützung eingebaut, die von einem Status zum nächsten weiter-
schaltet, dabei aber keine Verzweigungen oder ähnliches bietet. Das System ba-
siert auf einer XML-Datei, die alle unterstützten Prozesse enthält. Diese Prozes-
se besitzen eine ID, einen menschenlesbaren Titel, Stichworte, sowie eine Liste
von Arbeitsschritten, die ausgeführt werden müssen, um den Prozess zu bearbei-
ten.
6.4.1 XML-Datei
Das Listing auf der nächsten Seite zeigt einen Ausschnitt aus der XML-Datei,
die für die Applikation benutzt wird. Wenn eines der Stichworte (Phrase) in einer
neuen Arbeitsaufgabe gefunden wird, so nimmt das System automatisch an, dass der
Benutzer einen solchen Prozess starten möchte. Als Beispiel: Gibt der Benutzer im
Aufgabentext „Blutanalyse“ ein, so wird diese Aufgabe automatisch zum einen mit
dem Prozess BloodAnalysis verknüp, zum anderen wird ein Formular für die La-
boranforderung erstellt.
Beim Absenden des Formulars schaltet das System zur ersten Aufgabe des Pro-
zesses weiter. Im Falle der Blutuntersuchung wäre der nächste Schritt „Patient für
Blutuntersuchung vorbereiten, Proberöhrchen bereitlegen“. Dieser Schritt soll von
der Rolle nurse ausgeführt werden, weswegen der entsprechende Wert im Attribut
role des Arbeitsschritts gesetzt ist. Außerdem besitzen Arbeitsschritte noch ein ID-
Attribut sowie den Text der Aufgabe als Wert. Die Pegekräe muss nun manuell
ihren Arbeitsschritt bestätigen, damit das System zum nächsten Schritt weiterschal-
76
6.4 Workowunterstützung im System
<Processes>
<Process id=”BloodAnalysis” title=”Blutuntersuchung”>
<Phrases>
<Phrase>Laboranalyse</Phrase>
<Phrase>Blutuntersuchung</Phrase>
<Phrase>Blutanalyse</Phrase>
<Phrase>Blutuntersuchung vervollständigen</Phrase>
</Phrases>
<Tasks>
<Task id=”1” role=”nurse”>
Patient für Blutuntersuchung vorbereiten,
Proberöhrchen bereitlegen
</Task>
<Task id=”2” role=”physician”>
Blut abnehmen
</Task>
<Task id=”3” role=”laboratory”>
Blut untersuchen
</Task>
<Task id=”4” role=”physician” action=”labResult”>
Ergebnisse der Blutuntersuchung überprüfen
und gegenzeichnen
</Task>
</Tasks>
</Process>
<Process id=”XrayExamination” title=”Röntgenuntersuchung”>
…
</Process>
<Process id=”Council” title=”Konsil”>
…
</Process>
</Processes>
Listing : Denition der Prozesse in XML
tet. Auf diese Weise wird schließlich der gesamte Ablauf erfasst und kann so vom
System sukzessive abgearbeitet werden.
Eine Besonderheit ist das Attribut action, welches angibt, dass dem Benutzer et-
was präsentiert werden soll. Im Falle der Blutuntersuchung wäre das „labResult“. Das
bedeutet, dass der Benutzer erst das Ergebnis anschauen und als gesehen markieren
muss.
6.4.2 MDProcessManager
Im System ist für die Verwaltung der Prozessinstanzen die Klasse MDProcessManager
verantwortlich. Diese hat folgendes Interface:
77
Kapitel 6 Implementierung
@interface MDProcessManager :NSObject
+(Task *)advanceProcessInstance:(ProcessInstance *)processInstance
advanceAutomatically:(BOOL)automatically
withDelay:(BOOL)withDelay;
+(Task *)advanceProcessInstance:(ProcessInstance *)processInstance;
+(id)processInstanceWithTask:(Task *)task
andPatient:(Patient *)patient;
@end
Neue Prozesse instanziieren
Erstellt ein Benutzer eine neue Aufgabe, so wird im System zuerst ein neuer Task
mit dem entsprechenden Text erstellt. Dieser wird an die Methode processInstan-
ceWithTask:andPatient: weitergegeben, die einen Prozess zu der Aufgabe erstellt.
Durch Abgleich des Textes mit den bereits beschriebenen Ausdrücken (Phrases)
wird entschieden, ob der Aufgabe ein Prozessmodell zugewiesen wird. Als Interface
wird der DOM-Parser TBXML genutzt. Das Listing auf der nächsten Seite zeigt,
wie mithilfe von TBXML alle Ausdrücke durchsucht werden.
Weiterschalten von Prozessen
Wenn ein Arbeitsschritt erledigt wurde, wird advanceProcessInstance: aufgeru-
fen. Aus Demonstrationszwecken existiert auch die Methode advanceProcessIn-
stance:advanceAutomatically:withDelay:. Hier wird der Prozess ebenso weiter-
geschaltet. Fordert die neue Aufgabe allerdings eine andere Rolle als die des aktuell
angemeldetenBenutzers undistdasFlagadvanceAutomatically gesetzt, so wirdder
Prozess automatisch weitergeschaltet. Das Attribut withDelay gibt dabei an, ob dies
mit einer Verzögerung geschehen soll. Im Demonstrationssystem sind es Sekun-
den. Es wird im Demobetrieb immer diese zweite Methode mit beiden Attributen
auf YES ausgeführt. So werden nach und nach alle Prozesschritte durchgespielt und
der Benutzer kann sehen, wie das System den Status anzeigt und aktualisiert.
Im Detail wird zuerst der aktuelle Prozess in der Prozessbeschreibung (XML-
Datei) anhand der Prozess-ID gesucht. Innerhalb dieses wird nun der Prozessschritt
anhand dessen Task-ID gesucht. Eine Ausnahme ist der Fall, wenn die aktuelle Auf-
gabe keine ID besitzt. Dies ist genau dann der Fall, wenn es sich um die erste Aufgabe
in einem Prozess handelt, also die, mit der der Prozess erst angestoßen wird – wie
das Absenden eines Formulars.
6.5 Zusammenfassung
Mithilfe des iOS-SDKs konnte sehr schnell ein lauffähiger Prototyp entwickelt wer-
den, der die Aspekte Prozessmanagment, Arbeitsliste sowie Mobilität in einer Ap-
https://github.com/71squared/TBXML, Abruf am . März
78
6.5 Zusammenfassung
TBXML *tbxml =[TBXML tbxmlWithURL:processesDescriptionURL];
// iterate through all processes
TBXMLElement *processElement =
[TBXML childElementNamed:@”Process”
parentElement:tbxml.rootXMLElement];
do
{
NSString *processID =[TBXML valueOfAttributeNamed:@”id”
forElement:processElement];
TBXMLElement *phrasesElement =[TBXML childElementNamed:@”Phrases”
parentElement:processElement];
TBXMLElement *phraseElement =[TBXML childElementNamed:@”Phrase”
parentElement:phrasesElement];
do
{
// check for phrase in task text
NSString *phrase =[TBXML textForElement:phraseElement];
if ([task.text rangeOfString:phrase
options:NSCaseInsensitiveSearch
].location != NSNotFound)
{
foundPhrase =YES;
break;
}
// iterate phrases
phraseElement =phraseElement->nextSibling;
}while (phraseElement);
// iterate processes
processElement =processElement->nextSibling;
}while (processElement);
// check if process id corresponds to one known to our system
[...]
Listing : Iteration durch die Ausdrücke der XML-Datei zur Erkennung des Prozesses
plikation vereint. Tabelle . auf der nächsten Seite vergleicht die in Abschnitt .
auf Seite erarbeiteten Anforderungen mit dem Prototyp der MEDo-Applikation.
Dabei wurden alle Anforderungen erfüllt – bis auf die Forderungen nach einfacher
Desinzierung und nach Flexibilität der Prozesse. Bei ersterem ist ein iPad nicht zu-
friedenstellend, da es nicht komplett abgedichtet ist und deshalb nicht ausreichend
desinziert werden kann. Flexibilität in Prozessen ist ein komplexes ema und wä-
re eine eigene Arbeit wert. Aus diesem Grund konnte dies leider nicht in das System
miteinießen.
79
Kapitel 6 Implementierung
Tabelle .: Abgleich der Anforderungen mit Implementierung
A I I
S
Abbildung eines papier-
basierten Laufzettels
Primäre Eingabe bei Erstellung einer neuen
Aufgabe ist Freitext; Einfache Aufgaben können
als erledigt markiert werden.
✓
Einbeziehung von
zusätzlichen Daten
Alle geforderten Daten (Aktivität, Zeitpunkt
aufgenommen, Zeitpunkt bearbeitet, Benutzer
aufgenommen, Benutzer bearbeitet, Zugeord-
nete Daten) werden aufgenommen.
✓
Arbeitslistenfunktion Drei Prozesse (Laboruntersuchung, Röntgen-
untersuchung und Konsil) werden vom System
unterstützt.
✓
Unterbrechbarkeit Formulare werden automatisch gespeichert; Es
gibt verschiedene Möglichkeiten, Prozesse zu
starten.
✓
Flexibilität Flexbilität in Prozessen wird nicht unterstützt. 7
Geschwindigkeit der
Eingabe
Durch Textbausteine und die Möglichkeit, Au-
dioaufnahmen an Aufgaben anzuhängen, kön-
nen schnell Eingaben getätigt werden. Eine vir-
tuelle Tastatur ermöglicht die Eingabe von Frei-
text.
✓
Rollen-/Mehrbenutzer-
unterstützung
Im System sind die Rollen Ärztin/Arzt, Pege-
personal und eine Reihe von internen Unter-
suchungsstationen implementiert. Im System
kann man sich nur als Arzt/Ärztin anmelden.
✓
Geteilte Listen Alle Aufgaben sind von allen den Personen ein-
sehbar, die die passende Rolle besitzen.
✓
Adäquate Anzeige der
anstehenden Aufgaben
Dies wird durch die Übersicht auf dem Stations-
schirm und den Patientenschirmen gewährleis-
tet.
✓
Adäquate Bearbeitung
der Aufgaben
Wird ebenso unterstützt, durch entsprechende
Buttons.
✓
Fortgesetzt auf der nächsten Seite
80
6.5 Zusammenfassung
Tabelle . – fortgesetzt von der vorhergehenden Seite
A I I
Jederzeit Aufgabenbear-
beitung abbrechen
Formulare werden automatisch gespeichert,
Diagnostika erst nach aktiver Bestätigung als
gesehen markiert.
✓
Unterstützung für
Schichtübergabe
Indirekt, da jederzeit alle passenden Aufgaben
angezeigt werden.
✓
Adäquate Anzeige von
Untersuchungsergeb-
nissen
Siehe Seite . ✓
Adäquate Benachrichti-
gung über Status von
Untersuchungen
Aktive Untersuchungen werden angezeigt, Be-
nachrichtigung über neue Untersuchungser-
gebnisse in der Aufgabenliste.
✓
Komplette Abdeckung
der Möglichkeiten der
Papier-Handzettel
Sollten mit den vorangegangenen Anforderun-
gen abgedeckt sein.
✓
T
Größe Als eines der größten Tablets mit , cm (,
Zoll) Bildschirmdiagonale ist das iPad gut auf-
gestellt.
✓
Blickwinkel Mit ° absolut ausreichend; Auch in mehrere
Richtungen, da Gerät in mehreren Orientierun-
gen genutzt werden kann.
✓
Hygiene Nicht spritzwassergeschützt, nicht einfach des-
inzierbar.
7
Dieses Kapitel schilderte die Architektur der MEDo-Applikation, aufgeteilt in Mo-
del,View und Controller. Mit der iPad-Applikation konnte schließlich die Evaluation
mit Ärzten durchgeführt werden, die im nächsten Kapitel erläutert wird.
81
7
Evaluierung
Mithilfe des entwicklten Prototypen sollte überprü werden, ob ein System, das die
Ärztinnen und Ärzte bei der Verwaltung ihrer Aufgaben unterstützt, von diesen an-
genommen wird. Weiterhin sollte die Usability der Applikation überprü werden.
Zu diesem Zweck wurde eine qualitative Umfrage sowie ein Usability-Test mit zehn
Ärzten durchgeführt. Da bei dieser Evaluierung die Usability im Vordergrund steht,
wurde eine qualitative Umfrage als hinreichend erachtet [].
Dieses Kapitel stellt die Vorgehensweise und die Ergebnisse vor und schließt mit
der Diskussion der Ergebnisse.
7.1 Ablauf
Für die Evaluation von MEDo wurde das Formblatt auf Seite bis genutzt.
Nach der Begrüßung wurden der/dem Interviewpartner/in der Fokus der Arbeit er-
klärt. Es wurde darauf hingewiesen, dass es sich hier nur um einen Prototypen han-
delt, der nicht an die Daten der Station angeschlossen ist. Der gesamte Ablauf wird
in Abbildung . dargestellt.
Abbildung .: Ablauf des Evaluierungsprozesses
7.1.1 Erster Teil des Interviews
Um die Hintergründe der Ärzte besser verstehen zu können, war es wichtig zu er-
fahren, wie diese die Visite erleben. Dabei waren auch subjektive Mängel und Ver-
besserungsvorschläge von Interesse.
7.1.2 Usability-Test
Mithilfe von Usability-Tests soll die Benutzbarkeit (Usability) von Anwendungen
und Webseiten untersucht werden. Dafür werden Standardaufgaben formuliert, die
83
Kapitel 7 Evaluierung
alle Testpersonen ausführen sollen. Dabei ist zu beachten, dass es sich um ein für
den Benutzer realistisches und relevantes Szenario handelt. Die Aufgabe sollte aus
Sicht des Anwendungsgebietes formuliert sein und einen mittleren Schwierigkeits-
grad haben. Wichtig ist, dass die Aufgabenstellung nicht spezisch auf die Applikati-
on eingeht, sondern allgemeine Begriffe und Bezeichnungen verwendet. Vor jedem
Test muss ein einheitlicher Systemzustand hergestellt werden, so dass alle Testperso-
nen die gleiche Umgebung vornden. Elementar bei der Durchführung ist, dass die
Testperson gebeten wird, laut zu denken.
Es gibt nun zwei Möglichkeiten, den Test durchzuführen. Zum einen kann der Test
formal ablaufen, d.h. der Beobachter grei nicht ein und bleibt möglichst passiv. Zum
anderen kann der Testleiter den Ablauf moderieren, eingreifen und Fragen stellen.
Dies wird als informeller Usability-Test bezeichnet.
MEDo wurde durch einen informellen Usablity-Test evaluiert. Es wurde allerdings
kein Versuchsauau in einem isolierten Usability-Labor gemacht. Stattdessen, um
der Zeitknappheit der Ärzte Rechnung zu tragen, wurde der Test meist im Dienst-
zimmer auf der Station durchgeführt.
Bevor der Benutzer selber das System verwendete, wurde ihm eine kurze Einfüh-
rung gegeben. Dabei wurde jeder Bildschirm kurz gezeigt und die Möglichkeiten
erklärt. Dies dauerte im Schnitt ca. Minuten.
Anhang A auf Seite zeigt die Aufgabenstellungen der Ärzte. Dabei wurden
mehrere Szenarien aus Abschnitt . auf Seite kombiniert, um einen Durchschnitt
durch die Aufgabenverwaltung zu bekommen. Die Aufgaben wurden jeweils nach
Abschluss der vorangegangenen Aufgabe vom Testleiter gestellt, um die hohe Dyna-
mik einer Visite abzubilden. Die Aufgaben sind in die zwei Phasen Aufgabenerfassung
(während der Visite) und Aufgaben bearbeiten (nach der Visite) aufgeteilt. Nach Ab-
schluss der zweiten Phase sollten möglichst alle Aufgaben als erledigt markiert sein.
7.1.3 Zweiter Teil des Interview
Nachdem der Benutzer Erfahrungen mit dem System sammeln konnte, wurde er zu
seinen Eindrücken befragt. Wichtig war der erste Eindruck, der in weiteren Fragen
detaillierter analysiert wurde. Hierzu wurde das Formblatt in Anhang A auf Seite
genutzt. emen sind die Einsetzbarkeit, Eingabegeschwindigkeit, Einuss auf die
Kommunikation mit dem Patienten, Texteingabetyp und die wichtigsten Patienten-
informationen. Am Ende der Umfrage wurden statistische Daten (Alter, Berufser-
fahrung und Geschlecht) aufgenommen und der Interviewpartner verabschiedet.
7.2 Ergebnisse
In den folgenden Abschnitten werden die Ergebnise aus dem Usabilty-Test, den frei-
en und den geschlossenen Fragen vorgestellt.
84
7.2 Ergebnisse
7.2.1 Erkenntnisse aus dem Usability-Test
Im Usability Test hat sich gezeigt, dass das System von allen Probanden sehr gut an-
genommen wurde. Wenn anfängliche Scheu vor dem Touchscreen vorhanden war,
verschwand diese meist schon nach den ersten zwei bis drei Interaktionen.
Trotzdem haben sich bei der Beobachtung einige kleine Stolperfallen ergeben. Am
interessantesten war sicherlich, dass die meisten Benutzer () neue Untersuchun-
gen über den entsprechenden Button im Diagnostikreiter (siehe Abbildung .b) no-
tiert haben. Nur ein Arzt nutzte die implizite Erkennung im „Neue Aufgabe“-Fenster
(siehe Abbildung .a) intuitiv. Zur Navigation zwischen den Patienten wurde im-
mer der Stationsbildschirm genutzt, der Direktwahlbutton wurde genauso wie die
Vor- und Zurückbuttons nicht genutzt.
(a) Button „Neue Aufgabe“ (b) Button „Neue Anforderung“
Abbildung .: Vergleich der Positionen der Buttons um eine neue Anordnungs-Erinnerung
zu erstellen
Es hat sich auch gezeigt, dass die Form des Buttons, der den Benutzer zurück zur
Stationsübersicht bringt, sehr bei der Deutung der Funktion helfen kann: In der ers-
ten Version – bei den ersten drei Interviews – hatte der Button keine Pfeilform (siehe
Abbildung .a). Hier musste den Benutzern Hilfe gegeben werden, um den Patien-
tenbildschirm zu verlassen.
(a) Ohne Anpassung (b) In Pfeilform
Abbildung .: Zurück-Buttons
Sehr gut wurde die Anzeige des Status und die dahinterliegenden Prozesse ange-
nommen. Verständnisprobleme sind hier nicht aufgetreten. Alle Ärzte haben sofort
erkannt, dass das Konsil, nach dem gefragt wurde, noch nicht abgeschlossen ist. In
85
Kapitel 7 Evaluierung
zwei Fällen entstand allerdings Verwirrung aus dem Umstand heraus, dass der Status
im Imperativ („Patient untersuchen“) angezeigt wird.
7.2.2 Ergebnisse aus den geschlossenen Fragen
Im Durchschnitt bewerten die teilnehmenden Ärzte die Visite an ihrer Station als
eher gut bis durchschnittlich, allerdings mit einer hohen Standardabweichung. Die
Ergebnisse der Umfrage sind in Tabelle . aufgeführt.
Allgemein wurde das System als gut bewertet: Alle Ärzt/innen/e würden ein sol-
ches System auf der eigenen Station einsetzen und empfanden die Menüführung
des Systems als logisch. Erstaunlicherweise evaluierte die Mehrheit die Eingabege-
schwindigkeit des Systems als genauso schnell oder schneller als die Dokumentation
mit Sti und Papier.
Tabelle.: Ergebnisse der Befragung. AlsSkalawurdendie Schulnoten–verwendet,wobei
Eins „Sehr gut“ und Sechs „Ungenügend“ entspricht
Frage Mittelwert Standardabw.
Aufgabennotation , ,
Visite , ,
Gesamteindruck , ,
Sinnvoll auf Station , ,
Eingabegeschwindigkeit , ,
Patientenkommunikation , ,
Menüführung , ,
7.2.3 Ergebnisse des freien Teils des Interviews
In den freien Abschnitten des Interviews fanden sich viele weitere Meinungen zum
System. Anwender, die mit dem SAP-System Erfahrung haben, fanden die textuelle
Eingabe der Anforderungen eher umständlich. Von diesem System sind die Benutzer
gewohnt, aus einer Hierarchie von Untersuchungen eine oder mehrere auszuwählen.
Dies hat den Vorteil, dass die untersuchende Abteilung exakt weiss, was zu tun ist.
Ansonsten besteht die Gefahr, dass nachgefragt werden muss, welche Untersuchung
genau gewünscht wird oder es kommt zu fehlenden oder falschen Untersuchungen.
ImVergleich mit Systemen mit Stylus wurde der Touchscreen als besser verwend-
bar empfunden. Als ein Grund wurde angegeben, dass mit dem Stylus ein weiteres
Objekt mitgeführt, bzw. verstaut werden muss, wenn die Hand für etwas anderes
gebraucht wird.
Interessanterweise beobachtete Holzinger u. a. [], dass Benutzer einen Stylus
vorziehen und die Fehlerraten bei der Bedienung mit Fingern höher sind. Zwar wird
dies in der Arbeit nicht erwähnt, aber es ist davon auszugehen, dass ein resistiver (auf
Stylus: Spitzer Sti, der zur Eingabe auf Touchscreens genutzt wird.
86
7.2 Ergebnisse
Druck reagierender) Touchscreen für die Fingererkennung eingesetzt wurde. Der in
dieser Arbeit eingesetzte kapazitive (auf elektrische Leitfähigkeit des Körpers reagie-
rende) Bildschirm könnte die Differenz erklären.
Viele Ärzte vermissten klar sichtbare Farbkodierungen für Statusangaben. Insbe-
sondere war es für die befragten Chefärzte wichtig, nicht nur ein Rollensystem zu
haben, sondern auch individuellen Personen Aufgaben zuzuweisen – so dass bei-
spielsweise Studenten Blut abnehmen.
Gern gesehen wäre auch eine erweiterte Kongurationsmöglichkeit der Textbau-
steine. Im Zusammenhang mit den bereits angesprochenen spezischeren Anforde-
rungen wurde vorgeschlagen, dass Unterkategorien bei Textbausteinen eingeführt
werden. Durch diese könnten exakte Untersuchungen angegeben werden und so die
Formulare ersetzt werden.
Weitere Ergebnisse nden sich im Folgenden:
Allgemein
• Viele Ärzte sind eine große Patientenübersicht oder Stationsliste gewöhnt, in der
alle wichtigen Daten (Zimmernummer, Diagnose, anstehende Aufgaben, gepl.
Entlassungstermin) zu allen Patienten aufgeführt sind (siehe Abbildung . auf
der nächsten Seite).
• Weniger auf einmal anzeigen: Stationsbildschirm in mehrere Teilbildschirme auf-
teilen, jeweils Patienten-, Aufgaben- und bspw. Laborzentriert.
• Mehr Farbkodierungen, so dass dringende Aufgaben hervorgehoben werden.
• Aufgaben sollten lterbar sein: z.B. nur von heute.
• OP-Termine sollten angezeigt werden.
• Weitere, noch fehlende Patienteninformationen: Soziale Versorgung (Heim?),
Kontaktdaten Verwandte, Hausarzt, Dokumente (alte Dokumente einscannen),
Patient seit wann auf der Station und wielang noch, OP Termine, Entlassungster-
min, Prä-OP-Diagnose
Aufgaben/Anforderungen
• Anforderungen sollten schneller zu erreichen sein
• Viele Ärzte würden zwar sehr gerne Aufgaben per Sprache erstellen, aber nur nur,
wenn diese fehlerfrei funktioniert.
• Die Formulare im System sind nicht als solche erkennbar, da die Textfelder keine
Rahmen besitzen.
• Datumsangaben für Aufgaben wären für Benutzer von Interesse. Es wäre hier so-
wohl ein Fälligkeitsdatum als auch ein Start-Datum interessant.
• Prioritäten für Aufgaben
87
Kapitel 7 Evaluierung
Diagnostika
• Im Normalfall wird ein Kumulativbefund eingesehen, keine einzelnen Laborer-
gebnisse. Eine entsprechende Funktion, die alle bisherigen Untersuchungsergeb-
nisse zusammenfasst, wird benötigt.
• Bei langliegenden Patienten kann eine große Menge von Untersuchungsergebnis-
sen entstehen. Es sollten Filter angeboten werden, um nur einen bestimmten Typ
oder nur Ergebnisse bis zu einem bestimmten Datum anzuzeigen.
• Nicht eingesehene Untersuchungsergebnisse sollten mehr hervorgehoben werden
• Auf chirurgischen Stationen (auch postchirurgische) werden bei einer Chefvisite
viele Bilder hintereinander benötigt, die die Assistenzärzt/innen/e vorher aussu-
chen. Es wäre im System denkbar, bei der Anzeige eines Bildes eine Funktion be-
reitzustellen, um dieses einer Präsentation hinzuzufügen. Diese Präsentation kann
dann während der Chefvisite angezeigt werden.
• Röntgenbilder sind o nicht optimal belichtet. Für diesen Fall wäre ein Kontrast-
regler wünschenswert.
Abbildung.: Stationsliste des MCC.Hiersindalle Patienten mitweiterenDetailsaufgeführt.
Medikation
• Medikation, Wechselwirkungen (Rote Liste) anzeigen. Medikation zeitlich begren-
zen (mit entsprechendem Hinweis),
• Bedarfsmedikation mit Kurven korrelieren.
88
7.3 Diskussion
7.3 Diskussion
Die Evaluierung zeigte, dass auf Stationen, die mehrmals in der Woche Visite halten,
eine mobile Unterstützung gerne angenommen wird. Besonders Ärzte, die bisher
keine Möglichkeit haben, Patientendaten am Bett abzurufen, sind mit diesem Um-
stand unzufrieden. Interessanterweise waren gerade diese Ärzte der Meinung, dass
ein System wie MEDo nicht die Kommunikation mit dem Patienten verbessern kann.
Insgesamt führte diese Frage – wie aus der Standardabweichung der Frage in Ta-
belle . auf Seite zu sehen ist – zu sehr unterschiedlichen Antworten. Auf der ei-
nen Seite gab es diejenigen, die keinen Zusammenhang zwischen verwendeten Hilfs-
mitteln und der Kommunikation mit dem Patienten sehen. Die Begründung war hier
o, dass sich die eigentliche Kommunikation nicht ändert, und dass das Tablet nur
die eigene Prozessgeschwindigkeit verbessert. Auf der anderen Seiten gab es die Mei-
nung, dass es sehr wohl auf die Kommunikation Auswirkungen hat – beispielsweise
dadurch, dass dem Patient am Bett Röntgenbilder gezeigt werden können.
Vielen gemein war die Ansicht, dass die Gefahr besteht, sich zu sehr mit dem Ta-
blet bzw. den Informationen darauf zu beschäigen – insbesondere wenn die Ärzt/
innen/e alleine mit dem Tablet auf Visite sind. In diesem Fall würden viele versuchen,
dass System nur während des Wechsels zwischen Patienten zu benutzen. Im Idealfall
wünschen sich allerdings die meisten, dass die Visite mindestens zu zweit durchge-
führt wird. So kann einer der Ärzt/innen/e das Gespräch leiten, während der andere
das Gerät bedient.
89
8
Fazit
Die Arbeit begann mit der Beobachtung und Analyse von vier Visiten. Dazu wur-
den zum einen Prozessdiagramme zu den Visiten erstellt und verwendete Daten
und Zeiten protokolliert. Die Prozessinformationen stellten die Grundlagen dar, um
Gemeinsamkeiten und Unterschiede herauszuarbeiten. Aus den Gemeinsamkeiten
wurde das Aufgabenmanagement als eine Chance herausgegriffen, um Prozessfehler,
Laufzeiten und Unklarheiten bei der Visite zu vermindern.
Auf dieser Grundlage wurden Anforderungen für eine digitale Unterstützung der
Visite mit einem Tablet erarbeitet, worauin ich ein Prototyp entwickelt habe, der
diesen Anforderungen genügt. Mithilfe des Prototypen konnte durch Interviews und
Usability-Tests gezeigt werden, dass eine Aufgabenverwaltung mit Prozessunterstüt-
zung der Arbeitsweise von Ärzten entgegenkommt und durch Verminderung von
Brüchen in der Kommunikation Fehler, Wartezeiten und Wiederholungen verrin-
gern kann.
Insbesondere hat sich bei der Diskussion mit den Ärzten gezeigt, dass ein großes
Interesse an einer besseren Aufgabenverwaltung und komplett integrierten KIS be-
steht. Auch der Vergleich mit den Benutzern des Motion-PC Tablets hat offensicht-
lich gemacht, dass Anwendungen speziell für Tablets entwickelt werden sollten, um
eine bessere Nutzerakzeptanz zu erreichen.
8.1 Ausblick
Im Verlauf der Entwicklung sowie bei den abschliessenden Interviews haben sich ei-
nige Fragestellungen und Ideen ergeben, die in diesem Prototyp nicht weiter verfolgt
werden konnten:
• Es sollte darauf verzichtet werden, mehrere Wege zur Erstellung von Aufgaben an-
zubieten. Dafür muss der „Anforderung erstellen“-Button entfernt und die Maske
um Aufgaben zu erstellen verbessert werden. Beispielsweise könnten die Möglich-
keiten der Textbausteine erweitert werden, so dass der Benutzer exakte Untersu-
chungen durch Untermenüs auswählen kann. Es sollte allerdings dabei darauf ge-
achtet werden, dass schnelle, unspezische Aufgaben weiterhin möglich sind.
91
Kapitel 8 Fazit
• Bislang fehlt ein ausgearbeitetes Konzept, um Medikation und Vitaldaten anzu-
zeigen. Weiterhin sollte es möglich sein sein, Medikation und Vitaldaten in Auf-
gaben einzubinden. Beispielsweise könnten Medikamente für einen bestimmten
Zeitraum verordnet werden. Rückt der Tag, an dem die Medikation ausläu, nä-
her, wird dem Benutzer die Aufgabe angezeigt, dass die Medikation zu überprüfen
ist.
• Alle Maßnahmen im Krankenhaus müssen nach § Abs. BMV-Ä (Bundesman-
telverträge für Ärzte und Zahnärzte) dokumentiert werden. Demnach soll die Do-
kumentation „die Anamnese, die Beschwerden des Patienten, die Diagnose und
Behandlung sowie das Ergebnis […] enthalten“ [].
MEDo könnte dies auch unterstützen, in dem der „Als gesehen markieren“-
Button durch einen Button, der dem Benutzer eine Dokumentationsmaske an-
bietet, ersetzt wird. In dieser kann er textuell oder per Diktat die Untersuchung
befunden. Erst danach ist die Aufgabe erledigt.
• Es sollte weiterhin im Auge behalten werden, wie und wo die Daten gespeichert
werden und wie auf diese zugegriffen werden kann. Die Homogenisierung der Sys-
temlandscha in Klinikbereich ist eine der großen Aufgaben der klinischen In-
formatik. Eine Möglichkeit bestünde darin, Adapter in Form von Webservices zu
entwickeln.
• Weitere Probleme ergeben sich bei Stationen, bei denen Bilddaten eine große Rolle
spielen. Besonders Schnittbilder, wie beispielsweise Bilder aus dem Computerto-
mografen, führen dazu, dass bis zu GB Netzwerktraffic pro Woche generiert
werden. Bilddaten werden meist mithilfe von Digital Imaging Communication
(DICOM) gespeichert.
DICOM ist ein nicht proprietäres Protokoll, Bildformat und Dateistruktur,
um digitale Bilddaten im Klinikkontext anzuzeigen, übertragen und auszudru-
cken [] und umfasst damit Geräte wie CT-Scanner und Radiograe, Worksta-
tions, Drucker, Archiv- und Bildverarbeitungssysteme.
Pro Patient können Datenmengen von bis zu MB anfallen. Um Ladezeiten
gering zu halten, sollten entweder aktuelle Daten auf dem Gerät zwischengespei-
chert oder ein Hochgeschwindigkeits-WLAN eingesetzt werden. Die Zwischen-
speicherung hätte den den weiteren Vorteil, dass das Gerät auch genutzt werden
kann, wenn kein WLAN verfügbar ist. Es könnte dann beispielsweise alle Ände-
rungen an Aufgaben zwischenspeichern und erst bei verfügbarer Verbindung Da-
ten synchronisieren.
• Für die Anzeige von medizinischen Bildern existieren drei Klassen: Befundarbeits-
platz (Klasse A), Betrachtungsmonitor (Klasse B) und Sonstige (Klasse C). An ei-
nem Befundarbeitsplatz wird eine störungsfreie Umgebung geschaffen, beispiels-
weise durch einen hohen Maximalkontrast, hohe Leuchtdichte und : Zoom. An
Betrachtungsmonitore werden ähnliche, aber abgeschwächte Anforderungen ge-
stellt. In die letzte Kategorie fallen alle anderen Geräte, wie Kontrollmonitore.
92
8.2 Schlusswort
Die meisten Tablets fallen in Kategorie C, da eine Mindestpixelanzahl von
× vorrausgesetzt wird. Ersten Tests zufolge werden alle anderen Anforde-
rungen erfüllt []. Neue Geräte, die einen ähnlich hohen DPI-Wert aufweisen wie
manche aktuelle Smartphones (diese haben mehr als DPI []), könnten dies
ändern. Das neuste iPad () hat beispielsweise eine Auösung von ×
Pixeln.
8.2 Schlusswort
Im Verlauf dieser Arbeit wurde gezeigt, dass mithilfe von Tablets Daten, die auss-
schließlich digital vorliegen, nun mobil zugänglich sind und die Ärzt/innen/e bei
der Visite unterstützen können. Dabei ist es durch die direkte Manipulation auch für
neue Benutzer sehr einfach, die Soware zu bedienen. Eine direkte, touch-optimierte
Implementierung ist dabei sehr wichtig. Durch eine einfachere Desinzierung und
höhere DPI der Bildschirme würden sich weitere Einsatzzwecke von Tablets er-
schließen.
Es konnte auch gezeigt werden, dass die Kombination von Arbeitslisten und einfa-
cher Aufgabenliste dabei hil, von Komplexität durch Prozessmanagementsysteme
zu abstrahieren. So stehen einfache Aufgaben neben von Prozessen vorgegebenen
Aufgaben. Durch die Kombination von Prozessmagement und mobiler, benutzer-
freundlicher Plattform sind verteilte Aufgaben jederzeit erreichbar.
93
Anhang
95
A
Dokumente für die
Datenerhebung
Im Folgenden die Dokumente, die zur Beobachtung der Visiten und für die Benut-
zerevaluation genutzt wurden.
97
Krankenhaus
Person
Tätigkeit
Sonderfall
Vorbereitung
Beginn:
Ante Portas
Beginn:
Am Krankenbett
Beginn:
Nachbereitung
Beginn:
Phasen
Visite #
Daten Personen
Ende
Notizen Eindruck
Anhang A Dokumente für die Datenerhebung
98
Krankenhaus
Daten
Notizen
Technik
99
Befragung
Vor dem Usability-Test
1. An welcher Station sind Sie tätig?
2. Wie wird die Visite an Ihrer Station ausgeführt?
3. (Wie wird mit dem Problem der digitalen Patientenakte umgegangen?)
4. Wie werden die Aufgaben, die während der Visite anfallen, notiert?
5. Bewerten Sie diese Aufgabennotation an Ihrer Station:
[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ]
6. Bewerten Sie die Visite an Ihrer Station im Allgemeinen:
[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ]
7. Welches sind die Hauptkritikpunkte an der Visite, wie Sie an Ihrer Station praktiziert wird?
Anhang A Dokumente für die Datenerhebung
100
Usability-Test
Spielregeln
•Testperson darf den Test jederzeit unterbrechen bzw. abbrechen
•Testperson sollte darum gebeten werden, laut zu denken
•Falls die Testperson mit einer Aufgabe nicht mehr weiterkommt, kann sie selbständig zur
nächsten Aufgabe weitergehen.
•Der Beobachter sollte sich möglichst passiv verhalten
1. Während der Visite
Situation:
Sie befinden sich auf Visite am Bett von Patientin Crescentia Schmidt. Sie haben das Tablet
mit dem MEDo-System bei sich. Auf diesem werden gerade die Daten von der Patientin, bei
der Sie vorher waren angezeigt.
Aufgaben:
1. Sie wissen, dass für die Patientin Crescentia Schmidt neue Röntgenbilder eingetroffen
sind. Zeigen Sie diese bitte an.
2. In der Diskussion ergibt sich, das eine neue (große) Blutuntersuchung nötig ist. Notieren
Sie sich diese Aufgabe.
3. Es kommen Fragen zur Medikation auf. Zeigen Sie diese an.
4. Es soll das vorherige Krankenhaus des Patienten angerufen werden, um die dortige
Medikation zu erfahren. Erstellen Sie bitte eine neue Aufgabe.
5. Es geht weiter zur nächsten Patientin: Kethe Pakuscher. Für diese Patientin war ein Konsil
angefordert worden. Schauen Sie nach, ob dieses bereits eingetroffen ist.
6. Fordern Sie eine neue Röntgenaufnahme des rechten Knies an. Erstellen Sie dazu eine
neue Aufgabe.
Die Visite sei hiermit nun beendet.
2. Nach der Visite
Aufgaben:
1. Bearbeiten Sie die neu angefallenen Aufgaben entsprechend (drei an der Zahl).
Wenn neue Diagnostik eintrifft, markieren Sie diese als gesehen.
Sie sollten keine unbearbeitete Aufgaben mehr haben zur Abschluß dieser Aufgabe.
101
Befragung
Nach dem Usability-Test
1. Gesamt-Eindruck des vorgestellten Systems
[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ]
2. Ist ein solches System auf Ihrer Station vorstellbar/sinnvoll?
[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ]
3. Kann das System von der Eingabegeschwindigkeit her mit dem Notiz-System auf der
Station mithalten?
[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ]
4. Denken Sie, dass ein solches System die Kommunikation mit den Patienten während der
Visite verbessern kann?
[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ]
5. Empfanden Sie die Menüführung als sinnvoll?
[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ]
6. Was vermissen Sie spontan?
7. Was fanden Sie grafisch ansprechend / Was nicht?
8. Welche Methode der Texteingabe finden Sie/bzw fanden Sie am sinnvollsten: Text per
Tastatur, Textbausteine oder Audioaufnahme?
9. Würden Sie gerne mehr Kontrolle über die Anordnung der Inhaltsblöcke haben?
10. Was sind außerhalb des Aufgabenmanagements die wichtigsten Patienteninformation für
Sie (Medikation, Anamnese, etc)
11. Statistische Daten:
a. Alter
b. Berufserfahrung (Jahre)?
c. Geschlecht
Vielen Dank!
Anhang A Dokumente für die Datenerhebung
102
B
Literaturverzeichnis
[] A, W.M.P. Van d. u. a.: e application of Petri nets to workow manage-
ment. In: Journal of Circuits Systems and Computers (), S. –
[] A, N.R. ; A, V. ; H, W.K.: Modeling and analysis of workows
using Petri nets. In: Journal of Intelligent Information Systems (), Nr. ,
S. –
[] A, Scott W.: Introduction to User Interface (UI) Prototypes. Version: .
http://www.agilemodeling.com/artifacts/uiPrototype.htm, Abruf:
Februar
[] A, E. ; B, A. ; B, B. ; H, R.: Mobile information
and communication tools in the hospital. In: International journal of medical
informatics (), Nr. , S. –
[] A, E. ; M, U. ; M, C. ; K, M. ; E-
, R.: Are quantitative methods sufficient to show why wards react
differently to computer-based nursing documentation? In: Studies in health
technology and informatics (), S. –
[] A I. (Hrsg.): iOS Human Interface Guidelines. Version: . http:
//developer.apple.com/library/ios/#documentation/UserExperience/
Conceptual/MobileHIG/Introduction/Introduction.html, Abruf: .
Februar
[] A D GH (Hrsg.): iPad: aycan führt erfolgreiche Abnah-
meprüfung nach DIN V - durch.http://aycandigital.blogspot.com/
2010/04/ipad-aycan-fuhrt-erfolgreiche.html, Abruf: . Februar
[] B, R. ; B, J. ; R, M. ; S, J.G.: e smart phone: a
ubiquitous input device. In: Pervasive Computing, IEEE (), Nr. , S. –
[] B, Dirk ; B, Walter R. ; L, Horst ; Z,
Heinz: User interface prototyping – concepts, tools, and experience. In: Procee-
dings of the th international conference on Soware engineering. Washington,
103
Anhang B Literaturverzeichnis
DC, USA : IEEE Computer Society, (ICSE ’). – ISBN –––,
–
[] B J, W.D. ; H, S.C. ; P, F.W. ; V S, D.E.: Understan-
ding and using DICOM, the data interchange standard for biomedical imaging.
In: Journal of the American Medical Informatics Association (), Nr. , S.
–
[] B, K. ; M, U.: Dokumentationsaufwand im ärztlichen Dienst der Kran-
kenhäuser. Dt. Krankenhaus-Verl.-Ges.,
[] C, A. ; R, R. ; C, D.: About Face: Interface und Interaction
Design. Hüthig Jehle Rehm,
[] D, Peter ; R, Manfred ; K, Klaus: Clinical Workows - e
Killer Application for Process-oriented Information Systems? In: Proc. th Int’l
Conf. on Business Information Systems (BIS’), Springer, April , S. –
[] D, Hans-Joachim ; E, Sigmar ; G, Linus S. ; H,
Hans-Joachim ; H, Hans-Wolfgang ; R, Konrad: Kommunika-
tion als Erfolgsfaktor im Krankenhaus. Bd. . medhochzwei Verlag,
[] D, Rainer ; W, Werner: Ärztliche Visite im Krankenhaus
- Lernen aus der Vergangenheit? In: Klinikarzt (), Nr. /. http:
//dx.doi.org/10.1055/s-0030-1265815. – DOI ./s––.
ISBN –
[] D, G.T.W.: E-Health für eine bessere Gesundheitsversorgung in
Deutschland. In: Telemedizinführer Deutschland (), S. –
[] Norm DIN September . Sinnbilder für Datenuss- und Programm-
ablaufpläne
[] : Mit dem iPad zur Visite. In: Gesundheit und mehr... (Patientenmagazin des
Universitätsklinikum Leipzig) ()
[] E, Kerstin: healthHistory - Konzeption & Implementierung einer mo-
bilen Patientenakte, Universität Ulm, Diplomarbeit, Mai . http://dbis.
eprints.uni-ulm.de/748/
[] F, Katrin: Evaluation des Nutzenpotentials mobiler Dokumentations-
werkzeuge zur Unterstützung der klinischen Dokumentation im Krankenhaus,
Universität Erlangen-Nürnberg, Dissertation,
[] F, Eugen: Multimedia-Inhalte im Android Framework - eine Erklärung
anhand einer App,UniversitätUlm,Bachelorarbeit,Januar . http://dbis.
eprints.uni-ulm.de/794/
104
Anhang B Literaturverzeichnis
[] F, Jakob ; G, Klaus: Vom Geschäsprozess zum Workow. Carl
Hanser Verlag GmbH & CO. KG,
[] G, A. (Hrsg.) ; N, M. (Hrsg.) ; R, F. J. (Hrsg.) ; GI-
Arbeitskreis „Geschäsprozessmanagement mit Ereignisgesteuerten Prozess-
ketten (WI-EPK)“ der GI-Fachgruppe WI-MobIS (FB-WI) (Veranst.): Ge-
schäsprozessmanagement mit Ereignisgesteuerten Prozessketten. Bonn : Ge-
sellscha für Informatik, November ( )
[] G, D. ; H, M. ; S, A.: An overview of workow
management: From process modeling to workow automation infrastructure.
In: Distributed and parallel Databases (), Nr. , S. –
[] G G (Hrsg.): Die elektronische
Gesundheitskarte. Version: September . http://www.bmg.bund.de/
fileadmin/dateien/Publikationen/Infoblaetter/GP_Infoblatt_10_
2011.pdf, Abruf: . März . GP_Infoblatt
[] G, U.: Nutzerakzeptanz – Herausforderung Telemedizin am Beispiel der
elektronischen Gesundheitskarte. In: Telemedizinführer Deutschland (), S.
–
[] G, R.A.: Clinical decision support: the road ahead. Academic Press,
[] G, M. ; S, H. ; N, O. ; E, M. ; K, K.: M3IS
Online-Zugriff auf multimediale Patientendaten mit mobilen Endgeräten am
Krankenbett / Kuratorium OFFIS eV, Klinikum Oldenburg gGmbH. – For-
schungsbericht
[] H, A. ; H, M. ; S, M. ; U, B.: An in-
vestigation of nger versus stylus input in medical scenarios. In: Information
Technology Interfaces, , th International Conference on, . – ISSN
–, S. –
[] K, Alan C.: A Personal Computer for Children of All Ages. Xerox Palo Alto
Research Center, . – Dra
[] K, Andreas: Erstellung und Einsatz von Prototypen. Version: Dezember
. http://www.ef.eu/wp-content/uploads/2010/12/efeu_usability_
workshop_kohl_101215_handout.pdf, Abruf: . März . Usability Work-
shop
[] K, H.J.: Formale Sprachen: Graphtransformation. In: Universität Bre-
men, Sommersemester ()
105
Anhang B Literaturverzeichnis
[] L, MW: On the memorability of icons in an information retrieval task.
In: Behaviour & Information Technology (), Nr. , S. –
[] L, Richard ; P, Mor ; R, Manfred: Healthcare Process Sup-
port: Achievements, Challenges, Current Research. In: International Journal
of Knowledge-Based Organizations (IJKBO) (). http://dbis.eprints.
uni-ulm.de/784/
[] M, M. D.: Toshiba Portege M. Version: . http://www.flickr.com/
photos/mastermaq/4836376265/, Abruf: . März
[] M: Dokumappen für Pegende im Krankenhaus. Version: November
. http://www.pflegewiki.de/wiki/Datei:Dokumappe.JPG, Abruf: .
März . Vervielfältigung unter Beachtung der GNU Free Documentation
License, Version .
[] M, Wilson: When We Build. Version: November . http://wm4.
wilsonminer.com/build2011/, Abruf: . März
[] N, A. S. ; P, S. ; E, O.: Elektronische oder papierge-
bundene Patientenakte Ein Kosten-Nutzen-Vergleich. In: Der Ophthalmologe
(), -. http://dx.doi.org/10.1007/s003470170030. – ISSN
–X. – ./s
[] N, Jakob: Usability Engineering. Morgan Kaufmann,
[] N, M. ; R, F.J.: Syntax und semantik ereignisgesteuerter prozess-
ketten (epk). In: Promise Bd. , , S. –
[] O, C. ; V D A, W.M.P. ; D, M. ; T H, A.H.M.:
Translating BPMN to BPEL. ()
[] P, C.A.: Communication with automata: Volume Supplement , Techni-
sche Hochschule Darmstadt, Dissertation, November
[] R, J.C. ; I, M. ; R, M. ; G, P.: How good is BPMN
really? Insights from theory and practice. ()
[] R, M.: Prozessmanagement im Krankenhaus: Nutzen, Anforderungen
und Visionen. In: das Krankenhaus (), Nr. , S. –
[] R, Manfred: Dynamische Ablaufänderungen in Workow-
Management-Systemen, Universität Ulm, Dissertation, Juli .
http://dbis.eprints.uni-ulm.de/433/
106
Anhang B Literaturverzeichnis
[] R, Manfred ; R-M, Stefanie ; D, Peter: Flexibility in
Process-aware Information Systems. In: LNCS Transactions on Petri Nets and
OtherModels of Concurrency (ToPNoC), Special Issue on Concurrency in Process-
aware Information Systems. (), März, –. http://dbis.eprints.
uni-ulm.de/481/
[] R, Andreas: Development of an iPhone business application, Universität
Ulm, Diplomarbeit, Februar . http://dbis.eprints.uni-ulm.de/716/
[] S, Horst D. ; H, Marlies: Ärztliche Dokumentationspichten:
Das Ende der Fahnenstange. In: Deutsches Ärzteblatt (), November,
Nr. , S. A–. – Online verfügbar unter http://www.aerzteblatt.de/
archiv/66915
[] S, Maximilian: Mobile Web Service Implementierung am Beispiel des
iPhone OS ., Universität Ulm, Bachelorarbeit, November . http://
dbis.eprints.uni-ulm.de/709/
[] S, D.: Graphische Modellierung von BPEL Prozessen unter Verwendung
der BPMN Notation, Universität Stuttgart, Diplomarbeit,
[] S-C, S.: Die elektronische Fieberkurve zur Mobilen Visite
und Dokumentation im Krankenhaus. Version: . http://www.ssk.
med.uni-erlangen.de/de/vortraege/56-elektronische-fieberkurve/
133-2010-zwickau-die-elektronische-fieberkurve-vmobile, Abruf: .
März . Präsentation
[] S, J. ; U, A. ; S, B.: Die Elektronische Patientenakte in
der Intensivmedizin: Anforderungen-Konzepte-Nutzen. In: Telemedizinführer
Deutschland, Minerva, Darmstadt (), S. –
[] T, AG ; J, K. ; F, J. ; MG, CR: Do post-take ward
round proformas improve communication and inuence quality of patient ca-
re? In: Postgraduate medical journal (), Nr. , S.
[] T, J.: Designing interfaces. O’Reilly Media, Inc.,
[] V, R.A. ; S, J.L. ; K, D.: Usability problem identication using
both low-and high-delity prototypes. In: Proceedings of the SIGCHI confe-
rence on Human factors in computing systems: common ground ACM, , S.
–
[] V, Maren: Visite als Planungs- und Steuerungsinstrument in der Pege und
erapie im Krankenhaus: arbeitspsychologische Studie auf zwei Stationen der
Inneren Medizin. Verlag Dr. Kovac, Hamburg, . – S. , S. , S. –, S.
–, S. –
107
Anhang B Literaturverzeichnis
[] W, M. ; T, L. ; L, J.A.: High-delity or low-delity, paper
or computer? Choosing attributes when testing web prototypes. In: Proceedings
of the Human Factors and Ergonomics Society Annual Meeting Bd. SAGE
Publications, , S. –
[] W, M. ; P, H. ; E, A.: meditrace: Zeitersparnis und Qua-
litätsverbesserung durch standardisierte, mobile Befunddokumentation. In:
„Mobiles Computing in der Medizin”, Proceedings zum (), S. –
[] W, H. ; S, M. ; N, M. ; L, W. A.: Com-
munication during ward rounds in Internal Medicine: An analysis of pati-
ent–nurse–physician interactions using RIAS. In: Patient education and coun-
seling (), , Nr. , –. http://linkinghub.elsevier.com/
retrieve/pii/S0738399107001553?showall=true. ISBN –
[] W, M.: e computer for the st century. In: Scientic American
(), Nr. , S. –. – Online verfügbar unter http://sandbox.xerox.
com/want/papers/ubi-sciam-sep91.pdf
[] W, S.A.: Introduction to BPMN / IBM Cooperation. . – Forschungs-
bericht
[] W, S.: e use of icons and labels in an end user application pro-
gram: an empirical study of learning and retention. In: Behaviour & Information
Technology (), Nr. , S. –
[] W (Hrsg.): List of displays by pixel density. Version: März .
http://en.wikipedia.org/wiki/List_of_displays_by_pixel_density,
Abruf: . März
108
C
Akronyme
API Application Programming Interface.
BPMN Business Process Modeling Notation.
DICOM Digital Imaging Communication.
DPI Dots per Inch.
DSS Decision Support System.
EGK elektronische Gesundheitskarte.
EPA elektronische Patientenakte.
EPK Ereignisgesteuerte Prozessketten.
GCD Grand Central Dispatch.
IDE Integrated Development Environment.
KIS Krankenhausinformationssystem.
MCC Meierhofer Clinical Competence.
MVC Model View Controller.
OMG Object Management Group.
PDMS Patientendatenbankmanagementsystem.
PPI Pixel per Inch.
RKU Universitäts- und Rehabilitationskliniken Ulm.
SDK Soware Development Kit.
WfMS Workow-Management-System.
WLAN Wireless Local Area Network.
109
D
Abbildungsverzeichnis
. Übersicht über den Auau der Arbeit . . . . . . . . . . . . . . . .
. UI prototyping process . . . . . . . . . . . . . . . . . . . . . . . . .
. Mappen für die Pegedokumentation . . . . . . . . . . . . . . . . .
. Ein Prozessbeispiel in BPM-Notation . . . . . . . . . . . . . . . . .
. Process mangagement lifecycle .....................
. Applikation Erinnerungen . . . . . . . . . . . . . . . . . . . . . . .
. Beispiele für Tablet Computer . . . . . . . . . . . . . . . . . . . . .
. Vision des ubiquititären Computers . . . . . . . . . . . . . . . . . .
. Wahrnehmbare Teile des Computers und deren Entwicklung in
RichtungvonTablets..........................
. Prozessmodell Visite in der Inneren Medizin . . . . . . . . . . . . .
. Prozessmodell Visite in der Notaufnahme . . . . . . . . . . . . . . .
. Mobile Clinical Assistant von Motion Computing, Inc. . . . . . . .
. Bildschirmtastatur und Sti des Mobile Clinical Assistant . . . . . .
. Prozessmodell Visite in der Orthopädie . . . . . . . . . . . . . . . .
. Prozessmodell Visite in der Chirurgie . . . . . . . . . . . . . . . . .
. Prozessmodell Röntgenuntersuchung . . . . . . . . . . . . . . . . .
. Prozessmodell Anforderung einer Blutuntersuchung . . . . . . . . .
. Übersicht über die Phasen bis zur Evaluierung des Prototypes . . . .
. Patientenakte im MCC. Um zum Kumulativbefund zu gelangen,
muss der Benutzer den Patienten auswählen, in der rechen Leiste
„Arbeitsplatz“ anklicken und in einem Dropdown „Kumulativbe-
fund“auswählen.............................
. Modell der Patientendaten . . . . . . . . . . . . . . . . . . . . . . .
. Unterscheidung zwischen horizontalen und vertikalen Prototypen .
. Informationsarchitektur . . . . . . . . . . . . . . . . . . . . . . . .
. Projektion von Inhalten auf eine zweidimensionale Ebene . . . . . .
. Implementierungs-, Repreäsentations- und Usermodell . . . . . . .
. Repräsentationsmodelle für die Navigation zwischen Patienten und
derenDaten ..............................
111
Abbildungsverzeichnis
. Verschiedene Aueilungen der Stationsübersicht . . . . . . . . . . .
. Entwürfe zu Aufgabenfenstern . . . . . . . . . . . . . . . . . . . .
. Navigationsleisten . . . . . . . . . . . . . . . . . . . . . . . . . . .
. Entwürfe zur Darstellung der Patientendaten . . . . . . . . . . . . .
. Patientendaten in Portraitorientierung im Raster, mit Tab-Leiste . .
. Tab-Leiste am oberen Rand . . . . . . . . . . . . . . . . . . . . . .
. Entwurf eines Buttons . . . . . . . . . . . . . . . . . . . . . . . . .
. Verschiedene Pixeldesigns der Buttons . . . . . . . . . . . . . . . .
.Raster..................................
.Farben .................................
. Entwürfe für verschiedene Icons . . . . . . . . . . . . . . . . . . . .
. Model View Controller . . . . . . . . . . . . . . . . . . . . . . . . .
. Datenbankauau............................
. Angepasste Interface-Elemente . . . . . . . . . . . . . . . . . . . .
. MDTextModuleListControl nach Antippen des Buttons „Medikation“
. Berechnung der Koordinaten zum Einfügen des Textes . . . . . . .
. Storyboardausschnitt . . . . . . . . . . . . . . . . . . . . . . . . . .
. Start-Bildschirm ............................
. Login-Bildschirm ...........................
. Stationsübersicht............................
. Patientenbildschirm . . . . . . . . . . . . . . . . . . . . . . . . . .
. Patientenbildschirm – Diagnostika . . . . . . . . . . . . . . . . . .
. Patientenbildschirm – Laborergebnisse . . . . . . . . . . . . . . . .
. Patientenbildschirm – Laboruntersuchung anfordern . . . . . . . .
. Patientenbildschirm – Medikation . . . . . . . . . . . . . . . . . .
. Patientenbildschirm – Vitaldaten . . . . . . . . . . . . . . . . . . .
. Bildschirm: Neue Aufgabe erstellen . . . . . . . . . . . . . . . . . .
. Bildschirm: Aufgabendetails anzeigen . . . . . . . . . . . . . . . . .
. Darstellung des normalen UISplitView in verschiedenen Orientie-
rungen .................................
. Ablauf des Evaluierungsprozesses . . . . . . . . . . . . . . . . . . .
. Vergleich der Positionen der Buttons um eine neue Anordnungs-
Erinnerung zu erstellen . . . . . . . . . . . . . . . . . . . . . . . .
. Zurück-Buttons ............................
. Stationsliste des MCC . . . . . . . . . . . . . . . . . . . . . . . . .
112
E
Tabellenverzeichnis
. Allgemeine Informationen über die betrachteten Stationen . . . . .
. Zugriffe auf Patientendaten . . . . . . . . . . . . . . . . . . . . . .
. Szenarien................................
. Abgleich der Anforderungen mit Implementierung . . . . . . . . .
. Ergebnisse der Befragung . . . . . . . . . . . . . . . . . . . . . . .
113
Name: David Langer Matrikelnummer:
Erklärung
Ich erkläre, dass ich die Arbeit selbständig verfasst und keine anderen als die ange-
gebenen Quellen und Hilfsmittel verwendet habe.
Ulm,den ..................................................................
David Langer
