Healthcare goes mobile: Konzept mobiler Patientendokumentation

Aus Winfwiki

Wechseln zu: Navigation, Suche
Name der Autoren: Andreas Geisler, Melanie Höft, Tolgay Özcetin
Titel der Arbeit: "Healthcare goes mobile - aktuelle Plattformen im Vergleich"
Betreuer: Prof. Dr. Ralf Hötling
Hochschule und Studienort: FOM Berlin


Inhaltsverzeichnis


1 Einleitung

Es sollen medizinische Patientenakten zur Wunddokumentation mobil, zum Beispiel am Krankenbett im Krankenhaus, ausgelesen, bearbeitet und mit anderen Endgeräten synchronisiert werden können.

1.1 Aufgabenstellung

Nach einer Analyse der Gegebenheiten und Anforderungen sollen Prototypen zur mobilen Patientendokumentation auf verschiedenen mobilen Plattformen entwickelt werden, um die jeweiligen Vor- und Nachteile der Plattformen und Endgeräte in den Bereichen der Kamerasteuerung, Bildaufnahme, Barcodeerkennung und Webserviceanbindung kennen zu lernen und zu demonstrieren.

1.2 Ziel dieser Fallstudie

Innerhalb dieser Fallstudie soll untersucht werden, welches mobile (Betriebs-) System die Anforderungen der Problemstellung am Besten erfüllt. Dafür werden Prototypen erstellt, um durch Tests weitere Erkenntnisse zu den Technologien zu gewinnen.

1.3 Vorgehensweise

Im Folgenden wird die Vorgehensweise bei der Fallstudie vorgestellt.

Um herauszufinden, was alles umgesetzt werden muss, wird ein Vergleich der bisher genutzten Technologien und der möglichen erstellt. Hierbei wird analysiert, wie bisher die Patientenakten in Krankenhäusern behandelt werden und wie man eine mobile Akte daraus gestalten kann. Dies wird in Abschnitt Problemstellung unter Ist-Analyse und Soll Konzept behandelt. Welche Technologien bereits genutzt werden und können, wird durch eine Marktanalyse erarbeitet, diese ist dem Abschnitt Marktanalyse zu entnehmen. Hierbei wird das Angebot des Marktes betrachtet und die sich daraus ergebenen Anforderungen an ein Produkt, welches eine hohe Nachfrage erfüllt. Anhand der Marktanalyse werden Technologien aufgestellt, die zur Umsetzung genutzt werden können. Diese werden durch verschiedenen Kriterien bewertet und befinden sich in Abschnitt Auswahl der Technologie.

Anhand eines Prototyps in den unterschiedlichen Technologien können die Vor- und Nachteile besser getestet werden. Dies wird im Abschnitt Realisierungskonzept genauer erläutert. Die Prototypen werden dafür umgesetzt.

2 Problemstellung

In der Problemstellung werden die in der Vorgehensweise beschriebenen Vergleiche und Analysen genauer ausgeführt. Es wird die Tragbarkeit und Verfügbarkeit analysiert und geprüft, wie man es umsetzt und ob es dafür bereits Lösungen gibt, dafür wird der Markt analysiert.

2.1 Ist-Analyse

In der Ist-Analyse soll beschrieben werden, wie bisher Patientenakten genutzt werden. Es wird aufgezeigt, ob die Daten elektronisch oder per Papier oder beides behandelt werden.

2.1.1 Produktumfeld

Im Folgenden wird das Produktumfeld sowohl betrieblich als auch technisch betrachtet.

2.1.1.1 betriebliches Produktumfeld

Ist-Analyse, eigene Darstellung mit Hilfe von Microsoft Visio (MS Visio)
Ist-Analyse, eigene Darstellung mit Hilfe von Microsoft Visio (MS Visio)[1]

Bisher nutzen das Pflegepersonal und die Ärzte in Krankenhäusern Patientenakten aus Papier.[2] Diese werden direkt am Krankenbett des Patienten ausgefüllt und anschließend (meist am Ende des Arbeitstages) im Büro per Hand in das Krankenhausinformationssystem (KIS)[3] [4] eingegeben bzw. im Laufe des Tages durch eine Schreibkraft. Die Papierakten werden dem behandelnden Arzt von der Schwester vorgelegt und er geht mit diesen Akten zum Patienten und hat so alle Informationen bei sich. Hierbei müssen die Krankenschwestern darauf achten, dass der Arzt alle für ihn relevanten Akten erhält.

Dies verdeutlicht die nebenstehende, mit Microsoft Visio [1] erstellte Abbildung. Während des Patienten Arzt Gespräches kommt es zur Datenerfassung auf Papier. Diese angesammelten Daten müssen durch die Krankenschwestern verwaltet werden. [5] Wenn der Patient bereits eine Krankenakte besitzt muss die Krankenschwester dem Arzt diese vor der Behandlung vorlegen. So ist eine Behandlung des Patienten immer mit der Suche nach der Papierakte und dem anschließenden zurück sortieren derselben verbunden. Neue Daten, die per Hand erfasst wurden müssen wie auf dem Bild gezeigt von einer Schreibkraft (oder Stationsschwester) anschließend elektronisch erfasst werden.

Das Arzt-Patientengespräch steht hierbei jedoch nicht im Vordergrund, da dies vom Papier her die geringste Dokumentation darstellt. Im Vordergrund dieser Fallstudie soll stattdessen die Arbeit der Krankenschwestern und des Pflegepersonals stehen, da diese mehr mit dem Patienten zu tun haben und ihn über eine längere Zeit versorgen und begleiten und mehr dokumentieren müssen wie tägliche Messungen. Die Wunddokumentation soll sich speziell an die Pflegekräfte richten, da diese so ihre Arbeit dokumentieren können und es ihnen eine Erleichterung bei der täglichen Arbeit sein soll. Bezogen auf die nebenstehende Abbildung kann das Arzt Patientengespräch auch jede Pflegeleistung des Pflegepersonals darstellen, welches dokumentiert wird und später über die Krankenschwester oder das Pflegepersonal selbst in die Systeme eingegeben werden muss.

2.1.1.2 technisches Produktumfeld

In den meisten Arztpraxen wird ebenso verfahren, dass der Arzt alle Patientendaten schriftlich auf Papier festhält und die Arzthelferin diese Akten per Hand in einen Aktenschrank sortiert und dort beim erneuten Besuch des Patienten wieder herausnimmt und dem Arzt vorlegt. Dies bedeutet hohe Lagerkosten und auch einen erhöhten Aufwand für die Arzthelferin, da sie die Akten immer per Hand suchen, dem Arzt rechtzeitig vorlegen und später wieder einsortieren muss. Bei einigen niedergelassenen Ärzten gibt es bereits technische Lösungen, so kann der Arzt im Behandlungszimmer die Krankenakte direkt am Computer einsehen und bearbeiten und seiner Arzthelferin elektronisch beispielsweise Überweisungsformulare, Rezepte und die Krankschreibung zum Ausdrucken schicken. Dies wird jedoch nicht in dieser Fallstudie behandelt, da die Zielgruppe die Krankenhäuser darstellen soll.

Die Erfassung auf Papier ist historisch gewachsen[6] und hat sich bewährt, jedoch gibt es nun genügend technische Möglichkeiten, die Erfassung digital vorzunehmen. Die Papierakte hat außerdem den Vorteil der Unterschrift unter den Orginal Dokumenten. [7]

Bisher gibt es bereits vereinzelt technische Lösungen, [8] [9] jedoch noch nicht in allen Krankenhäusern.[10] In einigen kann der Arzt direkt in ein Computer Interface die Patientendaten eingeben und bei einem erneuten Besuch direkt aufrufen. Diese Systeme werden jedoch nicht in allen Krankenhäusern eingesetzt und die Daten werden auch nur in diesem einen Krankenhaus genutzt, bei einer Überweisung zu einem weiteren Arzt werden die Daten in schriftlicher Form weitergegeben und müssen bei diesem Arzt dann wieder eingegeben werden. In den Krankenhäusern, in denen KIS System genutzt werden gibt es keinen Standard, sondern es handelt sich hierbei um unterschiedliche Hersteller wie SAP&Siemens (i.s.h. med) [11], Tieto (iMedOne)[12] und Orbis[13].

Nach neuesten Erkenntnissen können elektronische Geräte wie Mobilfunktelefone im Krankenhaus gefahrenlos genutzt werden und es wurde durch eine amerikanische Behörde eine App für das Krankenhaus zur Nutzung im Krankenhaus freigegeben. [14]

Es gibt bereits einige Lösungen zur elektronischen Verarbeitung von Patientendaten. Zum Einen die Elektronische Patientenakte, [15] [16] die auf der elektronischen Gesundheitskarte basiert.[17] [18] Diese nutzt spezielle Kartenlesegeräte. [19] Die Gesundheitskarte ist bisher noch nicht ausgereift und wird bisher nur testweise eingesetzt. [20] Und zum Anderen die Elektronische Fallakte, die das Konzept vertritt, dass Patientendaten nur zu einem bestimmten Krankheitsfall gespeichert werden.[21] Für mobile Geräte gibt es bereits einige Entwicklungen, zum Beispiel für Medizinstudenten. [22] Diese Konzepte als Ausgangslage für die Fallstudie sind sinnvoll, da hier bereits Patientendaten vorliegen. Es muss außerdem festgestellt werden, welche Übertragungsmöglichkeiten in diesem Krankenhaus bereits vorhanden sind oder welche möglich sind, wie WLAN oder bereits bestehende Kommunikationsstrukturen.[23]

2.2 Soll-Konzept

Aus dieser Situation heraus, dass Ärzte, Pflegepersonal und Krankenschwestern einen hohen Aufwand im suchen und sortieren von Patientenakten und dem Eingeben von Daten per Hand haben, muss eine Lösung gefunden werden, in der die Daten gleich elektronisch eingegeben, verarbeitet und allen Mitarbeitern zugänglich gemacht werden können. Des Weiteren müssen die Krankenhäuser miteinander kommunizieren können. Es wird in dieser Fallstudie davon ausgegangen, dass die zu betrachtenden Krankenhäuser das gleiche KIS nutzen. Außerdem muss eine IT-Infrastruktur bereits voranden sein. [24]

2.2.1 Anwendungsfall

Soll-Konzept, eigene Darstellung mit Hilfe von MS Visio
Soll-Konzept, eigene Darstellung mit Hilfe von MS Visio[1]

Eine Pflegekraft leistet im Krankenhaus ihren Regeldienst und besucht dabei mehrere Patienten auf einer Station. Zu den Aufgaben gehört unter anderem die Versorgung, Reinigung und das Verbinden von Wunden der Patienten. Die Pflegekraft ist verpflichtet ihre Arbeit und den Zustand der Patienten zu dokumentieren. Diese Dokumentation wird später von Ärzten und anderem Pflegepersonal genutzt um den Fall des Patienten nachverfolgen zu können.

Am Bett jedes Patienten ist ein Patientenblatt mit einem Barcode angebracht, der die Patientennummer aus dem KIS abbildet. Die Pflegekraft benutzt zur besseren Dokumentation der Wunde ein Handy mit einer Kamera. Zuerst wird dazu der Barcode auf dem Patientenblatt gescannt. Danach werden beliebig viele ausschnittfüllende Photos von der/den Wunde(n) erstellt. Jedes Bild kann mit einem Kommentartext zum Inhalt versehen werden.

Am Ende des Rundgangs geht die Pflegkraft in das Stationszimmer in dem die PC's stehen. Hier überprüft die Pflegekraft die gemachten Bilder, löscht überflüssige Aufnahmen oder schreibt nachträglich Kommentare. Die übrigen Bilder werden an den Server des KIS übertragen und anhand der Patienten-ID der Fallakte des jeweiligen Patienten zugeordnet. Die können nun von dort abgerufen werden. Die Bilder auf dem Handy werden restlos vom Gerätespeicher gelöscht.

2.3 Marktanalyse

Um herauszufinden welche Anbieter bereits auf dem Markt tätig sind, wurden zwei verschiedene Suchphasen durchlaufen: in der ersten Phase wurden Anbieter gesucht, die allgemein eine digitale Erfassung von Patientendaten anbieten. Hier stellt man fest, dass es viele Anbieter gibt, die Möglichkeiten zur Verfügung stellen, Patientendokumentation in digitaler Form durchzuführen. Jedoch endet diese meist am PC, d.h. direkt am Arbeitsplatz. Zur Eingabe der Daten muss also jedesmal ein Browser oder ein eigene Anwendung verwendet werden. Ein direktes Ab-/Einlesen der Daten wird bisher kaum angeboten. Als Beispiel hierfür dient DOCexpert Computer GmbH. [25] DOCexpert bietet Möglichkeiten [26], z. B. aktuelle Patientendaten oder den bisherigen Behandlungsverlauf einzusehen.

Im weiteren Verlauf der Suche wurde gezielt nach Anbietern geschaut, die für diese Daten auch mobile Lösungen anbieten. Nach Abschluss dieser Suche lässt sich feststellen, dass allgemein wenige kleine Anbieter gibt, die diesen Markt bedienen. Dafür dominieren jedoch die "BigPlayer", d.h. Anbieter, die gleich Komplettlösungen im Bereich Healthcare anbieten. Im Folgenden werden drei dieser Anbieter etwas genauer vorgestellt.

iSoft Health GmbH: [27]
"iSOFT Health ist einer der weltweit führenden Anbieter von IT-Lösungen für das Gesundheitswesen."[28] iSoft bietet eine komplette Plattform rund um das Arbeiten mit Patientendaten an:

  • Health Information Exchange [29]
    • Zur Teilung und Verwaltung der Patientendaten über vernetzte Systeme hinweg
  • Enterprise Management [30]
    • Automatisierung Administrativer Prozesse
    • Bietet Schnittstelle für externe Lösungen (z.B. elektronische Fallakte)

Neben der eigentlichen Integration ans Krankenhaus-Informationensystem bietet iSoft auch ein Device in Form eines Tablet-PC um Patientendaten direkt vor Ort abzurufen oder aufzunehmen.
Philips Healthcare: [31]
Im Healthcare-Bereich von Philipps arbeiten weltweit rund 33.000 Mitarbeiter [32]. Ebenso wie die iSoft Healthcare GmbH, bietet der Healthcare-Bereich von Philips alles an, was ein Krankenhaus benötigt: Computertomographie, Diagnostisches EKG, Heimtherapie, Ultraschall u.v.m..[33] Für den in dieser Fallstudie interessanten Bereich der Patientenüberwachung bietet Philips verschiedene Gerätschaften, die auf verschiedenen Stationen des Krankenhauses eingesetzt werden [34]:

  • Monitore direkt am Patientenbett [35]
  • Zentrale Überwachung von Patienten [36]
  • u.v.m.

Universitätsklinikum Ulm: [37]
Das Universitätsklinikum Ulm hat in Zusammenarbeit mit Fujitsu Siemens ein Gerät entwickelt um Verwaltungsabläufe und Dokumentation in Einklang zu bringen:
Dieses Gerät dient der "(...) Verbesserung von Behandlung und Dokumentation durch Online-Zugriff auf Patientendaten und Leistungserfassung am Patientenbett".[37]
Bei dem Gerät handelt es sich um einen STYLISTIC Tablet PC, sowie ein Convertible LIFEBOOK, die an das KIS über WLAN angebunden sind. [37]

3 Auswahl der Technologie

Betrachtet man nun die Ausgangssituation (=> weg von Papierform), stellt man fest, dass die bisherigen Anbieter zwar gute Ansätze bieten, im Endeffekt aber noch zu stationär agieren (stationäre Monitore am Patientenbett etc.). Außerdem sind die vorgestellten Lösungen zu "oversized": Einzelne Devices aus den Paketen auszugliedern wird schwierig (bzw. wird auch nicht explizit angeboten). Ein weiterer Grund, der gegen die aktuellen Lösungen spricht sind die Abhängigkeiten und die damit verbundenen Kosten, die die Bindung an einen der genannten Anbieter mit sich bringt. Ein Lösungsansatz der bereits positiv hervorsticht, ist die genannte Zusammenarbeit zwischen dem Universitätsklinikum Ulm und Fujitsu Siemens. Hier wurde ein mobiles Gerät entwickelt, welches auch ohne "Komplettpaket" funktioniert und der Aufnahme von Patientendaten dient. Dieser Umstand führt jedoch dazu, dass dieses Gerät ebenfalls nicht als Lösung in Betracht gezogen werden kann: Diese Lösung ist zu individuell auf das Uniklinikum zugeschnitten. [37] Zudem wurde mit Windows XP ein nicht mehr aktuelles Betriebssystem [38] verwendet.

3.1 Technische Anforderungen

Die Anforderungen werden vom Kunden vorgegeben. Hierbei werden zwischen funktionalen und nicht- funktionalen Anforderungen unterschieden. Erstere beschreiben, wie der Kunde es umgesetzt haben möchte, letztere beschreiben die technischen Details und können mit den zur Verfügung stehenden Mitteln behandelt werden.

3.2 Funktionale Anforderungen

Die funktionalen Anforderungen werden sowohl an den Handy Client als auch den Web Service gestellt.

3.2.1 Handy Client

  • Start einer Dokumentationssitzung
    o	Start einer Patientendokumentation
  1. Bild-Aufnahme vom 2D-Barcode
    1. b alternativ: direkte Zahleneingabe des Barcodes ermöglichen (falls das Foto nicht den erwünschten Effekt bringt)
  2. Auslesen der Patienten-ID aus dem 2D-Barcode (Matrix) auf dem Handy
  3. 1 bis n Aufnahmen von Wunden des Patienten mit Speicherung Dateiname PATNR-XXX.JPG
  4. Taggen der Wundbilder (EXIF) mit Datum, Uhrzeit und wenn verfügbar GPS Koordinaten
  5. Bearbeiten eines Kommentartextfeldes für jedes Wundbild (optional)
   o	Beenden einer Patientendokumentation
   o	Es sind beliebig viele Patientendokumentationen möglich
   o	Browsen durch während der Sitzung erstellte Dokumentationen mit Bearbeitung der 

Kommentartexte sowie Löschfunktion für alle bzw. einzelne Bilder

   o	Übertragung der Sitzung an einen Web-Service/ KIS-Server mit Username- und Passwortabfrage, alle bereits übertragenen Dokumentationen werden gelöscht
   o	Beenden der Dokumentationssitzung, alle Daten werden vom Gerät gelöscht

3.2.2 Web Service

  • Sicherung des Zugriffs mit Username und Passwort
  • Speicherung der Wundbilder und der dazugehörigen Kommentardateien unter Patienten-ID und
  Sitzungskennung (fortlaufend)

3.3 Nicht-Funktionale Anforderungen

Die nicht funktionalen Anforderungen sind technische Anforderungen, diese können innerhalb der Fallstudie ggf. an neuere bzw. zur Verfügung stehende Technologien angepasst werden.

3.3.1 Handy Client

  • Je eine native Anwendung für die Plattformen
   o	iPhone (Objective C)
   o	Android (JAVA)
   o	Windows Phone (C#)
  • Handyausstattung
   o	hochauflösenden Kamera (min. 3 MP) mit einem LED Blitz und Autofokus
   o	min. 100 MB Speicher für Bilder
   o	WLAN
   o	UMTS

3.3.2 Web Service

  • Freie Wahl der WS-Plattform (.NET, Java, PHP etc.)
  • Freie Wahl der WS-Art (SOAP oder REST)

3.4 Technologien

3.4.1 Übertragungsmöglichkeiten

Technologien, eigene Darstellung Hilfe von MS Visio
Technologien, eigene Darstellung Hilfe von MS Visio[1]

Die folgende Unterteilung an Übertragungsmöglichkeiten wird voraus gesetzt. Andere Technologien werden bei der Betrachtung ausgelassen. Es muss entschieden werden, ob die Übertragung per Kabel oder kabellos geschehen soll. Bei der kabellosen Übertragung steht für diese Fallstudie die Wahl zwischen WLAN und UMTS. Im Folgenden sind einige Betrachtungspunkte dieser beiden Übertragungsarten gegenübersgestellt.

WLAN UMTS
Reichweite ~100 Meter (nach 802.11g-Standard) von überall erreichbar (sofern Empfang nicht gestört)
Nutzbarkeit WLAN-Adapter in vielen gängigen Geräten vorhanden UMTS-Modul nicht in allen Geräten standardmässig verfügbar
Sicherheit Verschlüsselung standardmässig nicht aktiv
Es muss sichergestellt sein, dass sowohl WLAN-Hotspot, als auch der Client die gleichen Verschlüsselungen nutzen;
Verschlüsselungen standardmaessig aktiv
Datenübertragung ~ 20MBit/s (bei gutem Empfang) aktuell sind maximal ~3,6MBit/s moeglich

Tabelle 1: Übertragungsmöglichkeiten

Quelle: [39] und [40]

3.4.2 Smartphones als Alternative?

Alternativen

PC:
pro:

  • keine Beschränkung auf ein Betriebssystem

contra:

  • erleichtert die Arbeit nur bedingt
  • deckt nicht alle geforderten (nicht technischen) Punkte ab
  • erüllt nicht alle technischen Anforderungen (z. B. CodeScanner)

Laptop:
pro:

  • keine Beschränkung auf ein Betriebssystem
  • schon besser als PC

contra:

  • noch nicht "mobil" genug:
    • einen Laptop trägt niemand von Patient zu Patient
    • erfüllt nicht alle technischen Anforderungen (z.B. CodeScanner)

Lösung:
Mobile Endgeräte:
pro:

  • bieten technische Voraussetzung (Kamera zum Scannen)
  • Hardware (Speicher etc.) ist ausreichend für unsere Zwecke
  • sie sind "mobil"! Pfleger/Arzt kann von Patient zu Patient eilen und Daten abfragen / Wunden dokumentieren etc.
  • je nachdem für welches Betriebssystem man sich endscheidet, stehen einem sogar verschiedene Geräte zur Verfügung

contra:

  • Vielfalt an Geräten/mobilen Betriebssystemen ist sehr groß
    • die Gefahr dass ein Gerät/OS mittelfristig nicht mehr unterstützt wird, ist höher als in anderen Bereichen

Smartphones sind für diesen Anwendungsfall eine gute Technologie, da sie sehr aktuell und auch erweiterbar sind. Sie haben den Vorteil, dass sowohl Daten eingegeben, als auch ausgegeben werden können, die Patientenakte kann auch durch Fotos oder ähnliches ergänzt werden. Die Daten können auf dem Gerät auch im Flugmodus gespeichert werden und sobald eine Internetverbindung besteht, übertragen werden.

Da noch nicht absehbar ist, welche der drei gewählten Technologien sich am Ende durchsetzt, werden in dieser Fallstudie drei aktuelle Technologien betrachtet. Die Wahl fiel hierbei auf ein Open Source System von der Firma Google (Android), das mobile Betriebssystem von Apple (iOS) und auf das von Mircrosoft neu entwickelte Windows Phone, welches nicht mit Windows Mobile zu verwechseln ist.

Es muss gewährleistet sein, dass alle Smartphones über einen Webservice gleichermaßen auf einen Server zugreifen können, er muss also von allen drei Betriebssystemen angesprochen werden können.

3.4.3 Kurzvorstellung der einzelnen Technologien

Smartphones als Alternative, eigene Darstellung Hilfe von MS Visio
Smartphones als Alternative, eigene Darstellung Hilfe von MS Visio[1]

Im Folgenden werden die technische Umgebung der mobilen Geräte und deren Betriebssysteme analysiert und verglichen. Das ist wichtig, da die technischen Prototypen für alle drei konkurrierenden Systeme (iPhone, WindowsPhone7 und Android) entwickelt werden sollen. Dies soll einen allgemeinen Überblick über die Thematik geben, vor allem über die Entwicklungsumgebungen der verschiedenen Systeme. In diesem Abschnitt versuchen wir nicht die Umsetzbarkeit der Anforderungen bezüglich der unterschiedlichen Systeme zu klären. Darauf wird in einem späteren Abschnitt Realisierungskonzept eingegangen.

3.4.3.1 Android

Android ist ein auf Linux basierendes Betriebsystem für mobile Geräte. Es ist dabei nicht auf Handys, bzw. Smartphones reduziert, sondern wird z. B. auch auf Tablet PCs oder Netbooks eingesetzt. Die Entwicklung wurde maßgeblich von Google gestartet und zusammen mit 33 weiteren Mitglieder der Open Handset Alliance vorangetrieben[41]. Android ist eine freie Software und steht unter der Apache-Lizenz 2.0. Der Programmcode ist so für jeden einsehbar[42]. Gerätehersteller müssen für Android keine Lizenzgebühren bezahlen und sind z. B. selber dafür verantwortlich, die aktuellste Version ihren Kunden zur Verfügung zu stellen. Jeder Entwickler kann für Android-Geräte Anwendungen (=Apps) programmieren und im Android Market kostenlos oder für einen geringen Aufpreis zur Verfügung stellen. Das erste auf Android basierende mobile Gerät, dass HTC Dream (bzw. T-Mobile G1) kam am 22. Oktober 2008 auf dem Markt[42]. Das Android-Betriebssystem wird permanent weiterentwickelt. Aktuell steht die Version 2.3 zur Verfügung (Stand: Februar 2011). Neue Versionen können auch von bereits ausgelieferten mobilen Geräten verwendet werden, wobei man in diesem Fall stark vom Provider abhängig ist. Für die Aktualisierung von Android-Geräten reicht es, wenn diese mobil mit dem Internet verbunden sind. Da im Gegensatz zu z.B. iOS Android aber auf Geräten von verschiedenen Herstellern ausgeliefert wird [43], obliegt es den Herstellern die offiziellen Updates freizugeben. Dies geht sogar so weit, dass neu ausgelieferte mobile Geräte nicht mal mehr mit der aktuellsten Version verkauft, geschweige denn aktualisiert werden [44]. Beim Thema Verschlüsselung hingt Android aktuell noch hinterher. Erst mit dem Update 3.0 wird es eine "hauseigene" Verschlüsselung geben - leider ist Android 3.0 nur für Tablets gedacht, nicht aber für die Smartphone [45]. Allerdings gibt es seit Mitte 2010 bereits Bewegung in der Entwicklergemeinde, die dieses Manko durch eigene Entwicklungen wettmachen wollen [46]. Auch gibt es für Android keine wirkliche Vorgaben, was die Bedienung der Apps etc. angeht. Dadurch kommt es vor, dass die gleichen Elemente unterschiedlich angegangen werden: Mal wird gescrollt, mal wird geblättert; der User muss sich pro App immer wieder neu eingewöhnen [47].

3.4.3.2 iOS

iOS ist das mobile Betriebssystem der Firma Apple und läuft aktuell u.a. auf der iPhone-Serie, der iPod-Serie und der iPad-Serie [48]. Die Hardware, also das iPhone, der iPod Touch und das iPad gibt es nur vom Hersteller Apple und die Preise liegen bei 500 Euro und aufwärts. Aktuell (Stand: 25.02.2011) liegt die Version 4.2 des iOS vor [49] Das aktuelle Standard-Verschlüsselung ist 256-bit AES [50]. Doch trotz dieser Maßnahme gibt es bereits seit einigen Monaten Berichte darüber, dass auch diese Sicherheitsmaßnahme nicht ausreicht, um die Datensicherheit des Apple-Gerätes zu gewährleisten [51] [52]. Das iOS läuft als einzige der drei betrachteten Betriebssysteme auf einem Gerät von einem einzigen Anbieter. Die Bedienelemente sind vorgegeben, was zu einem hohen Wiedererkennungswert innerhalb der verschiedenen Apps führt.

Unterstützte Geräte

Beim iPhone muss man mit dem jeweils aktuellen Modell vorlieb nehmen, welches in etwa jährlich aktualisiert wird, Geräte mit Tastatur etwa gibt es nicht. [53] Die Variationen beschränken sich nur, zu Einem auf die Speicherkapazitäten (8G oder 16G) und zum Anderen auf die Farboptionen (Schwarz oder weiss). Das iOS ist das Standard-Betriebssystem der Apple-Produkte iPhone, iPod touch, iPad und der zweiten Generation des Apple TV. [54].

3.4.3.3 Windows Phone 7

Windows Phone 7 ist das aktuellste Betriebssystem aus dem Hause Microsoft, das für mobile Geräte konzipiert wurde . Aktuell (Stand: 21.02.2011) läuft Windows Phone 7 (WP7) [55] parallel zu seinem Vorgänger Windows Mobile, welches "(...) primär für den Enterprise- und Businessbereich entwickelt wurde (...)" [56]. Für die Entwicklung von Anwendungen stehen u.a. die .NET-basierenden Plattformen Silverlight und XNA zur Verfügung. Laut Microsoft müssen alle WP7-Geräte über Touchscreen-Eigenschaften verfügen, sowie mindestens über 256MB Ram und 8GB Flash-Festplatte verfügen. Weitere technische Anforderungen sind das Vorhandensein einer Kamera (mind. 5 Megapixel), "Beschleunigungs- und Näherungssensor sowie einen digitalen Kompass. Zwecks Navigation sind drei Buttons auf der Vorderseite (Back, Home, Suche) sowie Power- und Kamera-Button" [57]. Für Windows Phone 7 gab es bisher noch kein größeres Update (das erste große Update ist für das erste Quartal 2011 angesetzt). Genau wie bei Android-Geräten können diese dann aber direkt über das mobile Gerät geladen werden (bestehende Internet-Verbindung vorausgesetzt) [58]. Genau wie bei Android gibt es bei Windows Mobile 7 keine eigene Verschlüsselung (im Gegensatz zu z.B. seinem Vorgänger, Windows Mobile). Laut Microsoft selbst wird es in naher Zukunft aber ein Update geben, was dieses Defizit ausgleichen soll [59][60].

Unterstützte Geräte

Zwar produziert Microsoft die Hardware nicht selbst, die vorgegebenen Spezifikationen für ein WP7-Gerät sind aber strenger als z.B. bei Android. Entsprechende Hardware stellen Samsung, HTC und LG zur Verfügung.

3.4.4 Vergleich der Technologien

Funktionalität iOS Windows Phone Android
Hersteller Apple Microsoft Google
Preise Hardware 600 – 850 Euro 450 – 550 Euro 100 – 600 Euro
aktuelle Version 4.2.1 7.0 2.3
Programmier-sprache(n) Objective C C# oder VB .NET Java
Entwicklungs werkzeuge X Code, Interface Builder, iPhone SDK Visual Studio, Expression Blend, Silverlight, XNA beliebige Java Entwicklungsumgebung, Java-, Android-SDK
unterstützte Geräte iPhone, iPod Touch, iPad Touchscreen-Mobiltelefone mit Mindestanforderungen alle Formfaktoren möglich, minimale Mindestanforderungen
Updates Update-Zwang Update-Zwang Hersteller-, Modelabhängig
Sicherheit Datenverschlüsselung, Ortung und Sperrung bei Verlust (80 Euro) Datenverschlüsselung, Ortung und Sperrung bei Verlust (0 Euro) Ortung und Sperrung nur von Drittanbietern oder Herstellern
closed/ open System closed closed open
Dateisystem Zugriff bedingt nein ja
Ordner Unterstützung ja nein ja
Speicher erweiterbar nein nein ja
Synchronization und Daten Backup nur über iTunes, mit System- und App Backup Mediadateien nur über Zune, kein System- und App Backup PC Abgleich, kein System- und App Backup
Benutzeroberflächen einheitlich, Icons einheitlich, Tiles Startbildschirm variiert, Icons
Multitouch ja ja ja
Application Market App Store > 300.000, Zensur Market Place > 15.000, Zensur (weniger streng) Android Market > 218.000, teilweise Zensur
Side loading nein nein ja
Multitasking begrenzt auf 4 eigene Anwendungen echtes Multitasking
cut / copy / paste ja nein ja
Tethering Ja (USB / Bluetooth) nein Ja (WiFi / USB )
Navigation Google Maps Routen Bing Maps Standpunkt Live-Navigation
Office Lösung variiert Standart Office 2010 Mobile Office-Suite variiert
Web-Browser Safari (Webkit), HTML 5-Standards Internet Explorer (LE7 / 8) Chrome (Webkit), HTML 5-Standards
Flash nein folgt Flash light
Push Email Ja, Threaded-E-Mail gute Exchange-Integration Ja, Threaded-E-Mail
Cloud Mobile Me Skydrive Google Apps
Customization eingeschränkt eingeschränkt Sehr individuell
Aggregation Icons Tiles Widgets

Tabelle 2: Vergleich der Technologien

3.4.5 Fazit

Da Apple mit dem iOS länger auf dem Markt ist als Android oder Windows Phone 7, können sie auch auf die meiste Erfahrung zurückgreifen. Das spiegelt sich in den bereits veröffentlichten Versionen wieder. Android holt allerdings mit riesigen Schritten auf und hat zudem den Vorteil, dass es eben auf eine breitere Hardwarebasis zurückgreifen kann. Windows Phone 7 hinkt, als jüngstes OS im mobilen Boot, der Konkurrenz bisher noch etwas hinterher. Der entscheidende Faktor wird hier sein, ob, bzw. wie sehr Microsoft es schafft sich vom Rest abzuheben und den Markt entsprechend für sich zu gewinnen.

3.5 Funktionsumfang Demonstrator

Der Demonstrator muss nicht vollständig den hier skizzierten Funktionsumgang besitzen. Dies gilt im Besonderen für die Anbindung/Übertragung der Daten auf ein KIS System. Mindestumfang sollte die Aufnahme und Erkennung der Barcodes, sowie die weitere Aufnahme von Bildern und deren korrektes Tagging sein. Die Serveranbindung kann als Proof of Concept über einen rudimentären Webservice (nur Speicherung der Bilder) erfolgen. Alternativ zu 2D Barcodes (Matrix) können auch herkömmliche 1D Barcodes (Strichcodes) genutzt werden.

3.6 Erwartungen Ergebnis

Neben den nativen Anwendungen für die drei Zielplattformen und einem lauffähigen Webservice im Backend, sollen vor allem die technischen Vor- und Nachteile der Plattformen im Zuge der Realisierung in einer technischen Dokumentation (Architekturkonzept bzw. Programmierhandbuch) dargestellt werden. Diese Darstellung ist im Bezug auf das Handling von Kameras, Bilder, Geotagging und Barcoderkennung von besonderem Interesse.

4 Realisierungskonzept

In diesem Abschnitt werden Annahmen zum Vorgehen in der Realisierung getroffen. Die eigentliche Umsetzung wird in dem Kapitel 5 Umsetzung behandelt.

4.1 UML Diagramme

Um die zeitgleiche Entwicklung zu gewährleisten, werden zuvor und auch während der Programmierung Absprachen getroffen, um die Entwicklungen in die gleiche Richtung gehen zu lassen. Dafür werden unter anderem UML Diagramme erstellt. Diese werden im einzelnen hier nicht veröffentlicht. So werden zuvor gemeinsam Überlegungen getroffen, wie beispielsweise die Benutzerführung ablaufen soll, diese wird im Folgenden genauer erläutert.

4.2 Herangehensweise Client

Für die Herangehensweise bei der Entwicklung des Client wird ein Ablaufdiagramm erstellt, um die Benutzerführung innerhalb der Applikation abzubilden.

4.2.1 Ablauf Benutzerführung Client

Programmablauf, eigene Darstellung mit MS Visio
Programmablauf, eigene Darstellung mit MS Visio[1]

Der nebenstehenden Abbildung ist die Benutzerführung des Client zu entnehmen. Nach dem Öffnen des Programmes wird der Benutzer aufgefordert, auszuwählen ob er einen neuen Patienten anlegen oder einen bestehenden öffnen möchte. Bei einem neu anzulegenden Patienten wird ein Barcode erzeugt und der Nutzer gibt die entsprechenden Daten zum Patienten in die neu erzeugte Patientenakte ein. Falls der Benutzer die Daten eines bereits bestehenden Patienten einsehen möchte, kann er den auf dem Krankenblatt befindlichen Barcode abfotografieren und es öffnet sich die Krankenakte (bzw. Patientenakte). Ob nun ein bestehender oder neu angelegter Patient, anschließend werden die Patientendaten (Name, Vorname, Geburtsdatum, Diagnose, bestehende Fotos und andere) angezeigt. Der Nutzer kann beliebig viele Diagnosen und Daten eingeben und speichern. Anschließend werden die Daten in das Dateisystem geschrieben und wenn der Benutzer fertig ist mit seinen Eingaben kann das Programm verlassen werden.

Der Prototyp wird nach der Drei-Schichten-Architektur [61] entwickelt. Hier wird die Programmierung in drei Programmteile aufgeteilt. So kann die grafische Oberfläche je nach mobilem Betriebssystem beliebig geändert, die Datenhaltung jedoch von allen dreien gleichermaßen verwendet werden. Die Logik muss jeweils zum Teil angepasst werden, jedoch wird dies über Webservices realisiert und diese können für alle verwendet werden. Die Drei-Schichten-Architektur eignet sich für das Vorgehen, drei unterschiedliche GUI's sehr gut abzubilden. So können dem Kunden unterschiedliche Prototypen je Betriebssystem gezeigt werden, ohne dass die Datenhaltung und Logik für jeden Prototypen einzeln erstellt werden muss.

4.3 Herangehensweise Server

Auf dem Server muss eine Datenbank liegen, die für allen drei Protoypen zugängig gemacht wird. Dies wird innerhalb der Fallstudie nicht genauer betrachtet, da kein Server zur Verfügung steht und das Virtualisieren nicht Teil dieser Fallstudie sein soll. Im Vordergrund steht der Client, da es sich nur um einen Prototypen für den Kunden handelt und keine echte Serveranbindung erforderlich ist. Bei einer späteren Umsetzung dieses Programmes würde der Client mit dem bestehenden Server des Kunden kommunizieren und es müssten dementsprechende Webservices entwickelt werden, um genau auf diesem Server und die dort liegenden Daten und die vorhandenen Strukturen zuzugreifen.

4.3.1 Anforderungen an Webservice und Server

Der Webservice muss für alle drei Betriebssysteme einsetzbar sein. Da die Daten über den Webservice abgerufen werden gibt es keine direkte Kommunikation zwischen Client und Server, sondern zwischen Client und Webservice und Webservice und Server, d.h. der Webservice muss kompatibel zu dem Server sein. Nur der Webservice greift direkt auf die Daten des Servers zu.

4.4 Vorgehensmodell

In diesem Abschnitt wird das verwendete Vorgehensmodell vorgestellt. Hier wird das Prototypen-Modell erläutert, das für die Realisierung der mobilen Anwendungen genutzt wird. Angelehnt an dem Vorgehensmodell der Darstellung.

4.4.1 Das Prototypen-Modell

Prototyp, Quelle
Prototyp, Quelle [62]

Das Prototypenmodell dient zu frühzeitigen Erstellung von lauffähigen Prototypen zur Klärung von Problemen. [63] Prototypen sind Experimentiersysteme, mit dessen Hilfe Fragestellungen zu den Eigenschaften des endgültigen Produktes oder seiner Einsatzumgebung geklärt werden sollen. [64] Klärungsbedürftige Probleme könnten hier zum Beispiel die Auswahl alternativer Lösungsmöglichkeiten sein, die Sicherstellung der Realisierbarkeit oder die Vervollständigung von Anforderungen. Auch das Einbeziehen von Anwendern in die Entwicklung und eine frühe Produktversion mit inkrementeller Weiterentwicklung ist von Bedeutung. In der nebenstehenden Abbildung wird dies sichtbar. Nachdem der Prototyp erst einmal spezifiziert wurde, wird er hergestellt und nach experimentieren wird dieser dem Kunden gezeigt. Dies wird so lange wiederholt, bis der Kunde zufrieden ist mit dem Prototypen. Hierzu wurden zwei verschiedene Prototypen entwickelt, die im Folgenden erklärt werden, der explorative und der technische.

4.4.1.1 Explorativer Prototyp
Explorativer Prototyp
Explorativer Prototyp [62]

Zum Einen wird ein explorativer Prototyp entwickelt, der als Kommunikationsgrundlage zwischen dem Kunden und den Systementwicklern dienen soll. Hier werden spätere Arbeitsweisen durchgespielt, um Schwächen und Fehler der Spezifikation vor der Weiterarbeit zu erkennen und dementsprechend zu beseitigen. Dies wird durch die Anwendung von Expression Blend [65] und SketchFlow [66] realisiert. Um diese Anforderungen zu erfüllen, wurde ein SketchFlow Prototyp [67] entwickelt, der unter dem folgenden Link http://bsp05.anygo-server.de/TestPage.html getestet werden kann.

Als Kommunikationsgrundlage mit dem Kunden dient hier der SketchFlow Player. Durch die Anwendung des SketchFlow Player kann der Kunde Feedback zu den aktuellen Entwürfen geben. Auf diese Feedbacks kann dann augenblicklich eingegangen werden. Dieser Prototyp ist ein horizontaler Prototyp, was der nebenstehenden Abbildung grafisch zu entnehmen ist. So wird die Benutzer Schnittstelle einzeln betrachtet und anschließend die Verarbeitungslogik und wiederum einzeln die Dateizugriffe.

Hier werden nur die Schnittstellen zum Benutzer implementiert. Diese Benutzerschnittstellen sollen möglichst einfach dargestellt werden und grafische Einflüsse wie Farbe und Design vermieden werden. Mit Hilfe dieses Prototypen kann der Umgang mit dem System gezeigt werden. Da die tieferen Ebenen fehlen, muss das System keine korrekten Werte liefern und nicht an jeder Stelle einwandfrei funktionieren. Er soll lediglich einen Überblick über die Möglichkeiten und Ideen geben und dem Kunden einen ersten Eindruck zur Diskussionsgrundlage verschaffen.

4.4.1.2 Technischer Prototyp
Technischer Prototyp
Technischer Prototyp [62]

Zum Anderen wird ein technischer Prototyp entwickelt, der als experimenteller Prototyp oder als Labormodell dient. Als Grundlage wird hier der zuvor entwickelte explorative Prototyp verwendet. Der technische Prototyp soll den Entwicklern als interner Bewertungsgegenstand der Fragen der technischen Umsetzung und Realisierbarkeit dienen. Hierzu sollen vor allem folgende Punkte geklärt werden:

  1. Die Überprüfung der Machbarkeit.
  2. Die Abschätzung des Aufwandes, des Zeitbedarfs und dementsprechend der Kosten der Realisierung.
  3. Ein Vergleich der technischen Plattformen iPhone, Windows Phone und Android.
  4. Fragen zu Kommunikation mit externen Systemen die dem KIS.

Dieser Prototyp ist ein vertikaler Prototyp, dies ist in der Abbildung zu sehen. Er umfasst also sowohl die Benutzerschnittstellen Entwicklung, als auch die Verarbeitungslogik und die Dateizugriffe gleichermaßen. Exemplarisch ausgewählte Teilfunktionen des zukünftigen Systems werden hier realisiert. Der Fokus liegt hier vor allem bei folgenden Funktionen:

  1. Beim Einloggen, wo benutzerrelevante Daten geladen werden.
  2. Das Öffnen des Krankenblatts durch das Scannen eines Barcodes. Getestet soll ihr werden, wie das Scannen eines Barcodes auf den verschiedenen Systemen funktioniert.
  3. Das Erstellen von Fotos. Auf den verschiedenen Systemen soll hier getestet werden, wie Geotags(GPS Daten) den Fotos hinzugefügt werden, wie diese Fotos intern verwaltet werden können und zu externen Systemen weitergeleitet werden können.

5 Umsetzung des Prototypen

5.1 Umsetzung der Client Anwendung

Da die Umsetzung für drei unterschiedliche Betriebssysteme zeitgleich erfolgen soll, wird anhand von Microsoft Sketch Flow [68] ein Vorgehen der Benutzerführung entwickelt, an dem alle drei Entwicklungen sich orientieren sollen.

5.1.1 Entwurf des explorativen Prototypen

5.1.1.1 SketchFlow-Diagramm
Sketchflowdiagramm
Sketchflowdiagramm

"Das SketchFlow-Diagramm ist ein Editor, in dem die Struktur, der Fluss, die Navigation und der eigentliche Aufbau einer Anwendung dargestellt werden können. Jeder Knoten im Diagramm repräsentiert einen Bildschirm des Prototypen"[69].

Die roten oder grünen Bildschirme in der nebenstehenden Abbildung des abgebildeten SketchFlow Diagramms stellen die Bereiche dar, die später bei den technischen Prototypen programmiert werden sollen. Bei diesen Bildschirmen sind die Verarbeitungslogik, als auch die Dateizugriffe implementiert. Die grünen Bildschirme sind notwendig, um die Funktionalität der roten Bildschirme durch den technischen Prototypen testen zu können. Die blauen Bildschirme werden nur bei den explorativen Prototypen implementiert. Diese sind für den technischen Prototyp nicht von Bedeutung.

5.1.1.2 SketchFlow Prototyp

Das gemeinsame Ziel mit den Kunden ist vor allem ist die GUI, die auf dem Bildschirm erscheint. Es wurde mit dem Kunden über seine Anforderungen gesprochen. Anschließend konnten diese Wünsche anhand einer Zeichnung in einem Sketch festgehalten werden, um die Anforderungen deutlich abzugrenzen. Solche Sketches werden mit Expression Blend und SketchFlow erstellt. Nach der Fertigstellung dieser Sketches, werden diese zu einem Prototypen zusammengestellt und dadurch klickbar. Diesen optischen Prototypen kann der Kunde testen und so entscheiden, ob es genau dem entspricht was er sich vorstellt und das ohne eine Zeile Programmcode geschrieben zu haben. So wird vermieden, dass an den Kundenwünschen vorbei entwickelt wird. Hervorzuheben ist, dass das Design hier in den Hintergrund rückt, weshalb alles in schwarz und weiß gehalten ist und wie "von Hand" gezeichnet wirkt.

5.1.1.3 Benutzeroberflächen des explorativen Prototypen

In diesem Abschnitt werden die Benutzeroberflächen und deren Funktionalitäten beschrieben. Die korrekte Funktionalität muss bei den Prototypen nicht gegeben sein, dennoch werden diese im Abschnitt ausführlich beschrieben, um einen Überblick der gesamten Funktionalität des eventuellen Endproduktes zu bekommen. Die Zusammenhänge sind wichtig um den Prototypen zu verstehen. Dies wird für alle drei Prototypen zeitgleich anhand des Sketch Flow Prototypen erläutert.

Während der Umsetzung haben sich noch weitere Funktionalitäten ergeben, die nicht in der Anforderung des Kunden erwähnt waren. Sie überschreiten die Anforderung der Wunddokumentation, können jedoch das Pflegepersonal unterstützen, da dadurch die Benutzerfreundlichkeit und Usability gesteigert werden kann. Diese werden in der folgenden Tabelle extra ausgewiesen, damit der Kunde entscheiden kann, ob er diese zusätzlichen Funktionalitäten für sinnvoll erachtet oder nicht.

Funktionalität Bild
Login

Der erste Bildschirm zeigt ein Login-Formular. Hier muss der Mitarbeiter sich authentifizieren. Das Programm prüft die eingegebenen Benutzerdaten. Wenn diese korrekt sind, werden alle dem Mitarbeiter zugeordneten Daten auf das System geladen. Dies beinhaltet alle Patientendaten die der Mitarbeiter im Laufe der Sitzung benötigt. Die Daten werden über einen Webservice abgerufen, weshalb eine Verbindung zum Netwerk notwendig ist. Danach kann diese allerdings wieder getrennt werden.
Auch wenn dies so in der Anforderung nicht definiert ist, kann so Angriffen von außerhalb vorgebeugt werden, da die Geräte nicht permanent im Netzwerk zur Verfügung stehen.

Login
Login
AnsichtenMenue

Auf das Ansichtsmenü kommt der Benutzer über das Hauptmenü, durch einen Klick auf den Punkt "Patientendaten ansehen". Dort gibt es die Möglichkeit, sich Patientendaten anzusehen. Das können u.a. Patientenstammdaten, Berichte von externen Praxen oder das Patienten-Krankenblatt sein. Über den Button „zurück zum Hauptmenü“ gelangt man wieder auf das Hauptmenü.

Ansichten Menue
Ansichten Menue
Aufnahmediagnostik

Nachdem eine Behandlung gestartet wurde, gibt es die Möglichkeit eine Aufnahmediagnostik durchzuführen. Die Aufnahmediagnostik ist der erste Befund eines Patienten der die Praxis besucht. Das System stellt hierzu einen Katalog an vordefinierten Befunden zu Verfügung. Es gibt nun die Möglichkeit einen dieser Befunde auszuwählen. Diese Auswahl wird dann dem Krankenblatt des Patienten hinzugefügt. Nach der Auswahl gelangt der Mitarbeiter wieder zurück in das Menü "Behandlung starten". Über den Button "abbrechen" wird der Vorgang abgebrochen und man gelangt wieder zurück in das Menü "Behandlung starten".

Aufnahmediagnostik
Aufnahmediagnostik
BarcodeScannen

Wenn das Krankenblatt eines Patienten geöffnen werden soll, gibt es die Möglichkeit dies per Barcodescann zu tun. Dieser Barcode muss eindeutig einem Patienten zugeordnet sein, damit das System das Krankenblatt des Patienten korrekt zuordnen kann. Wird dieser Barcode erkannt, wird der Name des Patienten angezeigt. Durch klicken des Buttons "Patient öffnen" wird der erkannte Patient bestätigt und die Patientendaten werden zur Verfügung gestellt. Misslingt das Scannen des Barcodes, kann der Vorgang durch anklicken des "abbrechen"-Buttons gestoppt werden. So gelangt man wieder zurück in das Menü "Krankenblatt öffnen".

Barcode scannen
Barcode scannen
Befund

Nachdem eine Behandlung gestartet wurde, gibt es die Möglichkeit einen Befund aufzunehmen. Ein Befund ist die durch einen Arzt erhobene körperliche oder psychische Erscheinung eines Patienten. Das System stellt hierzu einen Katalog an Befunden zu Verfügung. Die Auswahl des Befundes wird dann dem Krankenblatt des Patienten hinzugefügt. Nach der Auswahl gelangt der Mitarbeiter wieder zurück in das Menü "Behandlung starten". Über den Button "abbrechen" wird der Vorgang abgebrochen und man gelangt wieder zurück in das Menü "Behandlung starten".

Befund
Befund
BehandlungStarten

Eine Behandlung stellt jegliche Tätigkeit am Patienten dar, die dokumentiert werden kann und soll. Durch die Auswahl von „Behandlung Starten“ gelangt man in das Optionsmenü, in dem man aussuchen kann, welche Art von Informationen dem System hinzugefügt werden soll. Zur Auswahl stehen die Aufnahmediagnostik, Befund / Pflegeleistungen / Medikament / Dokumentations-Fotos hinzufügen. Über den "zurück"-Button gelangt man wieder auf das Hauptmenü.
Dies ist nicht Teil der Kundenanforderung und nur eine Empfehlung zur Benutzerführung.

Behandlung starten
Behandlung starten
BerichtAnsehen

Ein Bericht besteht z. B. aus Informationen über den Patienten, die durch z.B. Bluttests zustandegekommen sind, die in externen Praxen durchgeführt wurden. Ein Beispiel wären Natriumwerte im Blut

  • ID: NA
  • Testbezeichnung: Natrium
  • Ergebnis: 141
  • Grenzwert: Normal
  • Einheit:mmol/l
  • Normalwert: 136 - 157
Über den Button "zurück" gelangt der Benutzer wieder zurück zu "BerichteListe Ansehen"

Bericht ansehen
Bericht ansehen
BerichtelisteAnsehen

Im Auswahlmenü "Bericht öffnen" werden alle zur Verfügung stehenden Berichte des Patienten in Listenform angezeigt. Ein beliebiger Bericht aus dieser Liste kann ausgewählt und durch Klicken des Buttons "Bericht öffnen" geöffnet werden, um den Inhalt des ausgewählten Berichts anzuzeigen.

Berichteliste ansehen
Berichteliste ansehen
FotosMachen

Fotos dienen der Dokumentation der (Wund-)Behandlung des Patienten und werden dem Krankenblatt hinzugefügt. Durch das Bestätigen des "Foto schießen"-Buttons wird ein Foto erzeugt. Durch den Button "Foto speichern" kann dieses Foto bestätigt werden. Im Anschluss wird dieses Foto im System gespeichert und man gelangt wieder zurück in das Menü "Behandlung starten". Durch den Button „abbrechen“ wird der Vorgang abgebrochen. Es werden keine Fotos gespeichert und man gelangt ebenfalls wieder zurück in das Menü Behandlung starten.

Fotos machen
Fotos machen
HauptMenue

Nach einem erfolgreichen Scann oder nach der Auswahl eines Patienten gelangt man in das Hauptmenü. Hier gibt es die Möglichkeit Patientendaten anzusehen, Notizen hinzuzufügen oder eine Behandlung zu starten. Durch den Button "Krankenblatt schließen" gelangt man wieder zurück in das Auswahlmenü "Krankenblatt öffnen".

Hauptmenue
Hauptmenue
KrankenblattAnsehen

Im Ansichtsmenü "Krankenblatt ansehen" wird das Krankenblatt angezeigt. Das Krankenblatt beinhaltet alle getätigten Behandlungen an dem Patienten. Diese Informationen werden chronologisch aufgelistet. Durch das Betätigen des "Zurück"-Buttons gelangt man wieder in das Ansichtsmenü.
In der Anforderung des Kunden wird das Krankenblatt als Patientendokumentation beschrieben. In diesem Fall ist das gleiche gemeint.

Krankenblatt ansehen
Krankenblatt ansehen
KrankenblattManuellOeffnen

Wenn man im Menü "Krankenblatt öffnen" die Auswahl "manuell öffnen" auswählt, gelangt man auf diesen Bildschirm. Hier werden alle Patienten, die dem Mitarbeiter zur Verfügung stehen, in Listenform dargestellt. Einer dieser Patienten kann ausgewählt und durch das betätigen des "Patient öffnen"-Buttons geöffnet werden. Hier ist die Betrachtung aller Patienteninformationen des Patienten und das Hinzufügen weiterer Informationen zu diesem Patienten möglich.

Krankenblatt manuell öffnen
Krankenblatt manuell öffnen
KrankenblattOeffnen

Um Informationen über einen Patienten anzeigen zu können muss das System wissen, um welchen Patienten es sich handelt. Hierzu muss das Krankenblatt des Patienten geöffnet werden. Auf diesem Bildschirm kann eine Auswahl getroffen werden, auf welche Art das Krankenblatt des Patienten geöffnet werden soll. Dies ist entweder durch das Scannen eines Barcodes möglich oder, wenn dies nicht funktionieren sollte, durch das manuelle Öffnen des Krankenblattes. Durch das Betätigen des "Logout"-Buttons kann sich der Benutzer wieder vom System abmelden.

Krankenblatt öffnen
Krankenblatt öffnen
Medikamentierung

Nachdem eine Behandlung gestartet wurde, gibt es die Möglichkeit eine Medikamentierung aufzunehmen. Medikamentierungen umfassen die Informationen darüber, ab wann ein Patient welche Medikamente einnimmt. Des Weiteren die Art der Medikamentierung wie z.B.:

  • Medikation bei Aufnahme
  • Dauer-Medikation
  • Bedarfs-Medikation (wann, bis zu welcher Tagesdosis)
  • Lieferung der verordneten Medikamente durch Apotheken und vor allem welche Präparate.
Das System stellt hierzu einen Katalog mit vordefinierten Medikamenten zur Verfügung. Die Auswahl des Medikaments wird dann dem Krankenblatt des Patienten hinzugefügt. Nach der Auswahl gelangt der Benutzer wieder zurück in das Menü "Behandlung starten". Über den Button "abbrechen" wird der Vorgang abgebrochen und man gelangt wieder zurück in das Menü "Behandlung starten".
Die Medikamentierung ist in der Kundenanforderung nicht vorgesehen, kann sich jedoch als sinnvoll erweisen, wenn beispielsweise ein Patient krankheitsbedingt bestimmte Medikamente oder Salben benötigt. So kann das Pflegepersonal sehen, welches Medikament oder welche Salbe der Patient bereits bekommen hat oder bekommen soll. Anhand des Wundfotos kann der Arzt den Heilungsprozess nachvollziehen.

Medikamentierung
Medikamentierung
NotizenHinzufuegen

Durch die Funktion "Notizen hinzufügen" ist es möglich, schnell und unkompliziert freie Texte dem Krankenblatt hinzuzufügen. Dies ist ebenfalls nicht in der Kundenanforderung beschrieben, kann aber sinnvoll sein, wenn das Pflegepersonal sich nebenbei Notizen zu dem Patienten machen möchte. Beispielsweise wenn dieser ein Anliegen hat oder wenn Messwerte genommen werden, die nicht vorgesehen sind, jedoch in dem stationären Programm am Computer eingegeben werden sollen.

Notizen hinzufuegen
Notizen hinzufuegen
Pflege

Nachdem eine Behandlung gestartet wurde, gibt es die Möglichkeit eine Pflegeleistung aufzunehmen. Pflegeleistungen sind Leistungen die am Patienten getätigt werden. Dies kann z. B. ein Verbandswechsel, eine Blutabnahme oder ähnliches sein. Das System stellt hierzu einen Katalog an vordefinierten Pflegeleistungen zur Verfügung. Diese Auswahl wird dann dem Krankenblatt des Patienten hinzugefügt. Nach der Auswahl gelangt der Mitarbeiter wieder zurück in das Menü "Behandlung starten". Über den Button "abbrechen" wird der Vorgang abgebrochen und man gelangt wieder zurück in das Menü "Behandlung starten".
Dies ist ebenfalls nicht in der Kundenanforderung enthalten, kann aber sinnvoll zur Wunddokumentation sein, da das Pflegepersonal nicht nur den Zustand der Wunden dokumentieren kann, sondern auch die Pflegemaßnahmen erfasst werden.

Pflege
Pflege
StammdatenAnsehen

Über das Ansichtsmenü gelangt man auf den Bildschirm "Stammdaten ansehen". Hier werden alle Stammdaten des Patienten angezeigt. Dazu gehören Name, Vorname, Straße, Hausnummer, Postleitzahl, Ort, Telefon, Geburtstag, Geschlecht, Krankenversicherungs-Nummer, sowie Körpergröße, Gewicht und Blutgruppe. Diese Vielzahl an Stammdaten ist bei der Kundenanforderung ebenfalls nicht gegeben, kann aber zur eindeutigen Identifikation bei mehrfach vorkommenen Namen hilfreich sein.

Stammdaten ansehen
Stammdaten ansehen

Tabelle 3: Benutzeroberflächen des Prototypen

5.1.2 Entwurf des technischen Prototypen

Hier wird ein technisches Modell der mobilen Anwendung entwickelt, das die definierten Anforderungen erfüllt, wenn es korrekt implementiert ist.

5.1.2.1 Klassendiagram: View-Controller
Klassendiagram
Klassendiagram

In diesem Klassendiagramm wird dargestellt, wie die einzelnen GUI-Elemente miteinander verbunden werden sollen und welche Daten sie beinhalten.

Es soll in allen drei Betriebssystemen einzeln umgesetzt werden und stellt somit den Teil der Drei-Schichten-Architektur dar, der nicht für alle Betriebssysteme gleich behandelt wird.

Für Windows Phone steht zur Unterstützung der Oberflächengestaltung Expression Blend und bei iOS der Interface Builder zur Verfügung. Die Tools zur GUI-Gestaltung in Android sind nicht ganz so ausgereift, weshalb in der Regel die GUI direkt im Code zusammengestellt wird.

Im weiteren Verlauf werden die einzelnen Elemente genauer erläutert.

Spezifikation: View-Controller

Funktionalität Bild
Funktionen der Login Klasse

KlickLogin()

Nach dem Klick Ereignis des Login Buttons (siehe 5.1.1.3 Login Bildschirm) wird die Authentifizierung des Benutzers durch die Funktion GetDatenpacketObjekt geprüft. Bei erfolgreicher Authentifizierung wird das Datenpaketobjekt geholt, welches alle Daten beinhaltet die der Benutzer im Laufe der Sitzung benötigt. Im Anschluss wird der Bildschirm „KrankenblattOeffnen“ geöffnet. Ist die Authentifizierung nicht erfolgreich wird eine Fehlermeldung auf dem Bildschirm Login angezeigt.

GetDatenpacketObjekt(String Benutzername, String Passwort): DatenpacketObjekt

Diese Funktion nutzt einen Webservice. Die vom Mitarbeiter eingegebener Benutzerdaten werden als Authentifizierungsattribute dem Webservice geschickt. Nach erfolgreicher Authentifizierung durch den WebService schickt dieser das DatenpaketObjekt zurück, welches alle Daten beinhaltet die der Mitarbeiter im Laufe der Sitzung benötigt.

  • Parameter String Benutzername: Ist der Benutzername des Mitarbeiters mit dem sich der Mitarbeiter in den System Authentifizierung kann. Durch dieses Attribut kann das System prüfen, ob der Benutzername existiert.
  • Parameter String Passwort: Ist das Passwort welches zu dem Benutzernamen gehört. Das System kann durch dieses Attribut prüfen, ob das Passwort, welches vom Mitarbeiter eingegeben wurde auch wirklich zum Benutzernamen passt.
  • Rückgabe DatenpacketObjekt: Das Objekt Datenpaket beinhaltet alle Krankenblattdaten die dem Mitarbeiter zugeordnet sind. Diese Daten sind kompatibel mit dem XML Datenbankschema des Systems, können als XML Datei abgespeichert und weiter verwendet werden.

Login
Login
Krankenblatt öffnen

Diese Klasse beinhaltet die Funktionen der Klickereignisse des Auswahlmenüs "Krankenblatt öffnen" und die Funktion zum Ausloggen.
KlickBarcodeScannen()
öffnet den Bildschirm“Barcode Scannen“.
KlickKrankenblattManuellOeffnen()'
öffnet den Bildschirm “Krankenblatt manuell öffnen“.
KlickLogout()
Loggt den aktuellen Benutzer aus dem System. Dazu werden zuerst alle Aktualisierungen durch die Funktion SetDatenpacketObjekt mit dem Server geupdatet. Bei erfolgreichem Update werden alle Daten vom System gelöscht. Im Anschluss wird der Login Bildschirm aufgerufen.
SetDatenpacketObjekt(DatenpacketObjekt Datenpacket, String Benutzername, String Passwort):bool
Bei dieser Funktion wird zuerst die XML Datei, mit allen Aktualisierungen, d.h. alle zusätzlich aufgenommenen Daten per Datenobjekt durch einen Webservice zum Server geschickt, um die Datenbank auf dem Server zu aktualisieren.

  • Parameter String Benutzername: Der Benutzername des Mitarbeiters, der gerade eingeloggt ist. Dieses Attribut wird gebraucht um sich beim Webservice zu authentifizieren, außerdem speichert der Webservice hierdurch, von welchem Mitarbeiter die Aktualisierungen vorgenommen wurden.
  • Parameter String Passwort: Ist das Passwort welches zu dem aktuell eingeloggten Benutzernamen / Mitarbeiter gehört. Dieses Attribut wird gebraucht um sich beim Webservice zu authentifizieren, dies schützt die Datenbank vor unbefugten Veränderungen.
  • Parameter DatenpacketObjekt: Das (Daten)Objekt DatenpaketObjekt beinhaltet alle Krankenblattdaten die vom Mitarbeiter im Laufe der Sitzung verändert wurden. Dieses Objekt ist kompatibel mit dem XML Datenbankschema des Webservice, hierdurch können die Daten auf dem Server aktualisiert werden.
Rückgabe Bool: liefert true bei erfolgreicher Aktualisierung und false bei Problemen.

Krankenblatt öffnen
Krankenblatt öffnen
Barcode Scannen

Diese Funktion nutzt Drittanbieter Klassen für das Scannen von Barcodes. Nachdem aufrufen des "Barcode Scannen" Bildschirms, wird sofort die Funktion aufgerufen. Das Video Stream der Kamera des Smartphones wird nach Barcodes untersucht. Wird ein Barcode erkannt, wird die XML Datenbank nach einem passenden Krankenblatt durchsucht. Wird ein Krankenblatt gefunden, wird zu einem das KrankenblattID im System abgespeichert und zu anderem der zu dem Krankenblatt gehörende Patientenname auf dem Bildschirm angezeigt, damit der Benutzer den erkannten Patienten bestätigen kann. Wird kein Krankenblatt gefunden welches zum Barcode passt, wird eine Fehlermeldung angezeigt und der Vorgang kann abgebrochen werden.
KlickPatientOeffnen()
Ist der Barcode Scanvorgang erfolgreich abgeschlossen, kann der Patient, der erkannt wurde, mit dem "Patient öffnen" Button bestätigt werden. (siehe 5.1.1.3 „BarcodeScann“ Bildschirm) Die erkannte KrankenblattID wird im System zur weiteren Verwendung gespeichert und im Anschluss wird der Hauptmenü-Bildschirm geöffnet.
KlickAbbrechen()
Bricht den Barcode Scan Vorgang ab und ruft den Bildschirm "Krankenblatt öffnen"-Menü auf und das KrankenblattID wird auf null gesetzt.

Barcode Scannen
Barcode Scannen
Hauptmenü

Diese Klasse beinhaltet die Funktionen der Klickereignisse des Auswahlmenüs "HaupMenue"
KlickPatientenDatenAnsehen() Öffnet den Bildschirm “PatientenDatenAnsehen“.
KlickNotizenHinzufuegen() Öffnet den Bildschirm “NotizenHinzufuegen“.
KlickBehandlungStarten()> Öffnet den Bildschirm “BehandlungStarten“.
KlickKrankenblattSchliessen() Öffnet den Bildschirm “KrankenblattSchliessen“.

Hauptmenü
Hauptmenü
Behandlung starten

Diese Klasse beinhaltet die Funktionen der Klickereignisse des Auswahlmenüs "BehandlungStarten"
KlickAufnahmediagnosik() Öffnet den Bildschirm “Aufnahmediagnosik“.
KlickBefund() Öffnet den Bildschirm “Befund“.
KlickPflege() Öffnet den Bildschirm “Pflege“.
KlickMedikamentierung() Öffnet den Bildschirm “Medikamentierung“.
KlickFotosmachen() Öffnet den Bildschirm “Fotosmachen“.
KlickZurück()> Öffnet den Bildschirm “HaupMenue“.

Behandlung starten
Behandlung starten
Fotos hinzufügen

Nach dem Aufrufen des "FotosHinzufuegen" Bildschirmes, wird sofort die Funktion aufgerufen. Das Video Stream der Kamera des Smartphones wird auf dem Bildschirm dargestellt, damit der Benutzer das gewünschte Motiv anvisieren kann.
KlickFotosMachen()
Durch das klicken des Foto machen Buttons wird ein Bild von der Kamera des Smartphones erzeugt. Dieses Foto ersetzt das angezeigte Video Stream.
KlickFotoSpeichern()'
Durch das Klicken des "Foto speichern" Buttons, wird das aktuelle erzeugte Foto in Base64 kodiert und dann mit allen dazugehörigen Attributen wie Datum, Zeit, Geo Daten, usw. in der XML Datenbank gespeichert. Durch die Base64 Kodierung ist die spätere Kommunikation mit dem Server über Webservices gewährleistet.
KlickAbbrechen()
Durch das Klicken des "abbrechen" Buttons wird der Vorgang abgebrochen ohne Daten zu speichern und der Bildschirm "Behandlung starten" wird aufgerufen.
SetFotosDaten(FotosDatenObjekt FotosDaten)
Alle Fotodaten die im Objekt FotoDaten enthalten sind werden in der XML Datenbank gespeichert.
Parameter FotosDatenObjekt: Das (Daten)Objekt FotosDatenObjekt beinhaltet alle Fotodaten. Die erzeugten Fotos werden in Base64 kodiert und dann mit allen dazugehörigen Attributen (s.o.) in diesem Objekt gespeichert.

Fotos hinzufügen
Fotos hinzufügen
Ansichten Menü

Diese Klasse beinhaltet die Funktionen der Klickereignisse des Auswahlmenüs "Ansichten Menü"
KlickStammdatenAnsehen()
Öffnet den Bildschirm “StammdatenAnsehen“. (siehe 5.1.1.3 Abbildung StammdatenAnsehen)
KlickBerichteListeAnsehen()
Öffnet den Bildschirm “BerichteListeAnsehen“. (siehe 5.1.1.3 Abbildung BerichteListeAnsehen)
KlickKrankenblattAnsehen()
Öffnet den Bildschirm “KrankenblattAnsehen“. (siehe 5.1.1.3 Abbildung KrankenblattAnsehen)
KlickZurück()
Öffnet den Bildschirm “Hauptmenue“. (siehe 5.1.1.3 Abbildung Hauptmenue)

Ansichten Menü
Ansichten Menü
Krankenblatt ansehen

KrankenblattDatenAnzeigen()
Diese Funktion wird gleich aufgerufen. Sie holt die zur Anzeige benötigten Krankenblattdaten durch die Funktion GetKrankenblattDaten und stellt sie auf dem Bildschirm dar.
GetKrankenblattDaten(int KrankenblattID): KrankenblattDatenObjekt Diese Funktion trägt durch verschiedene Abfragen alle Informationen zu einem Krankenblatt zusammen. Diese sind Notizen und alle zum Krankenblatt gehörenden Behandlungsdaten wie Aufnahmediagnostik, Behandlungen, Pflegeleistungen, Medikamentierung und Bilder. Diese Daten werden chronologisch sortiert und zur Anzeige vorbereitet.
Parameter int KrankenblattID: durch das KrankenblattID können alle benötigten Behandlungen zu einem bestimmten Krankenblatt bzw. Patienten abgefragt werden.
Rückgabe KrankenblattDatenObjekt: Das Objekt KrankenblattDaten beinhaltet alle notwendigen Informationen die zur Darstellung des Krankenblattes benötigt werden. Dies sind alle Behandlungs Informationen welche chronologisch aufzulisten sind.
KlickZurück() Öffnet den Bildschirm "Ansichten Menü". (siehe 5.1.1.3 Abbildung Ansichten Menü)

Krankenblatt ansehen
Krankenblatt ansehen

Tabelle 4: Spezifikationen ViewController

5.1.2.2 Datenbankmodell
Datenbankmodell
Datenbankmodell

Im Folgenden wird eine Übersicht über das Datenbankmodell gegeben. Dieses Datenbankmodell wurde entworfen um anschließend eine gemeinsame Datenhaltung zu entwickeln, auf die alle drei Prototypen per SOAP Webservice zugreifen sollen. Dies basiert wieder auf der drei Schichten Architektur, also der Trennung von Layout, Logik und Datenhaltung.

Bei dem vorliegenden Datenbankmodell handelt es sich um einen vorläufigen Entwurf, der nur für den Prototypen gedacht ist. Wenn der Kunde bereits eine bestehende Datenbank mit Patientendaten hat, wird auf diese zugegriffen. Der Übersichtlichkeit halber wurden hierbei einige Daten weg gelassen, da sonst der Rahmen dieser Fallstudie überschritten werden würde.

5.1.3 Besonderheiten der Betriebssysteme

5.1.3.1 Windows Phone

Für das Windows Phone kann mit der kostenpflichtigen Entwicklungsumgebung Microsoft Visual Studio [70] oder mit der kostenfreien Express Version [71], die extra zur Entwicklung mobiler Applikationen gedacht ist, entwickelt werden. Zusätzlich gibt es für die Oberflächengestaltung noch das Tool Expression Blend. [72] Die Entwicklung kann in den verschiedenen Programmiersprachen der .NET Technologie vorgenommen werden (z.B. C# oder ASP. [73])

Software für Windows Phone 7 wird mit C# und VB.net in den Technologien Silverlight und XNA entwickelt, native Software werden nicht unterstützt. [74] Für die Entwicklung für das Windows Phone-System stellt Microsoft das kostenlose Paket „Windows Phone Developer Tools“[75] zur Verfügung. Es beinhaltet Visual Studio 2010 Express for Windows Phone [76], einen Emulator, die Silverlight- und XNA-Ressourcen und Expression Blend zur Gestaltung der Oberflächen. Die Entwickler-Tools sind mit Visual Studio 2010 kompatibel[77] und ausschließlich für Windows Vista und Windows 7 verfügbar. [78] Bisher sind noch wenig APIs verfügbar.

Anwendung starten Patient vorhanden? Patient anlegen Patient öffnen Foto hinzufügen
Anwendung starten
Anwendung starten
Patient vorhanden?
Patient vorhanden?
Patient anlegen
Patient anlegen
Patient öffnen
Patient öffnen
Foto hinzufügen, Quelle Wundbild
Foto hinzufügen, Quelle Wundbild [79]

Tabelle 5: Windows Phone Oberfläche

5.1.3.2 Android

Programmiersprache und Entwicklerwerkzeuge

für die Entwicklung für Android wird mit Java gearbeitet. Google hat zu diesem Zweck extra eine eigene Virtuelle Maschine names DalvikVM entwickelt. Sämtliche Element die nicht zum eigentlichen Programmcode passen (GUI / GUI-Elemente etc.) werden innerhalb von XML definiert und bei Bedarf in die Klassen reingeladen. Alternativ können diese Definition auch direkt "on-the-fly" im Java-Code erstellt werden[80].

Anwendung starten Patient vorhanden? Patient anlegen Patient öffnen Foto hinzufügen
Anwendung starten
Anwendung starten
Patient vorhanden?
Patient vorhanden?
Patient anlegen
Patient anlegen
Patient öffnen
Patient öffnen
Foto hinzufügen, Wundbild
Foto hinzufügen, Wundbild [79]

Tabelle 6: Android Oberfläche

5.1.3.3 iOS

Für die Umsetzung der iPhone Programmierung werden ein Apple Rechner und die Entwicklungsumgebung XCode benötigt. Innerhalb dieser Entwicklungsumgebung gibt es den iPhone-Simulator, mit dem die Programme getestet werden können. [81] Des Weiteren wird der Interface Builder benötigt, um die grafische Oberfläche durch fertige Komponenten zu erstellen, da es sich hierbei nur um einen Prototypen handeln soll. So wird automatisch Code erzeugt, der die einzelnen Elemente darstellt. Der iPhone Simulator kann nicht alle Funktionalitäten eines echten iPhone abbilden, so können beispielsweise keine Fotos gemacht werden oder der Ortungsdienst genutzt werden.

Programmiersprache und Entwicklerwerkzeuge

Für das iPhone wird in Objectiv C enwickelt[82]. Apple entwickelte für das iPhone eine mobile Variante seines Cocoa-Frameworks namens Cocoa touch. Das SDK wird zusammen mit einer neuen Version von Apples integrierter Entwicklungsumgebung Xcode ausgeliefert. Darin enthalten ist auch ein iPhone-Simulator, der es weitestgehend ermöglicht, die Anwendungen während der Entwicklungsphase auf dem Mac zu testen.[83] Der Interface Builder ist der GUI-Designer für Mac OS X und iPhone. Alternativ kann der Code auch direkt durch eigenen Code erstellt werden.

Anwendung starten Patient vorhanden? Patient anlegen Patient öffnen Foto hinzufügen
Patient vorhanden?
Patient vorhanden?
Anwendung starten
Anwendung starten
Patient anlegen
Patient anlegen
Patient öffnen
Patient öffnen
Foto hinzufügen, Wundbild
Foto hinzufügen, Wundbild[79]

Tabelle 7: iOS Oberfläche

5.2 Umsetzung Webservice

Ein Webservice ist ein Dienst, der den Austausch von Daten zwischen Systemen unterstützen soll.[84]

Im Rahmen der Fallstudie ist es notwendig die Kommunikation des Prototypen mit Web-Services zu untersuchen. Hierzu wurden Web-Services entwickelt, die den Anforderungen dieser Fallstudie entsprechen. Daher wurde zur Demonstration der Potototypen ein Anschauungsbeispiel entwickelt.

Die Schnittstelle eines Webservice wird durch die Web Service Description Language (WSDL) beschrieben. In dieser Schnittstelle sind alle Funktion, Datentypen, etc. definiert, die von den Systemen angesprochen und genutzt werden können [85]. Der folgende Link zeigt die WSDL–Dienstbeschreibung des Webservices der für die Veranschaulichung genutzt werden soll:
http://bsp11.anygo-server.de/WebServices/Prototyp.asmx?WSDL

Dieses Beispiel bietet zwei Funktionen an. Die "GetDatenpacketObjekt"-Funktion und die "SetDatenpacketObjekt"-Funktion. Der folgende Link zeigt eine Übersicht aller Funktionen: http://bsp11.anygo-server.de/WebServices/Prototyp.asmx

Beispiel Anfrage/Antworte für "GetDatenpacketObjekt":

POST /WebServices/Prototyp.asmx HTTP/1.1
Host: bsp11.anygo-server.de
Content-Type: text/xml; charset=utf-8
Content-Length: <font class=value>length</font>
SOAPAction: "http://bsp11.anygo-server.de/GetDatenpacketObjekt"

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <GetDatenpacketObjekt xmlns="http://bsp11.anygo-server.de/">
      <Benutzername>string</Benutzername>

      <Passwort>string</Passwort>
    </GetDatenpacketObjekt>
  </soap:Body>
</soap:Envelope>
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: <font class=value>length</font>

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <GetDatenpacketObjektResponse xmlns="http://bsp11.anygo-server.de/">
      <GetDatenpacketObjektResult>string</GetDatenpacketObjektResult>
    </GetDatenpacketObjektResponse>

  </soap:Body>
</soap:Envelope>


Beispiel Anfrage/Antworte für "SetDatenpacketObjekt":

POST /WebServices/Prototyp.asmx HTTP/1.1
Host: bsp11.anygo-server.de
Content-Type: text/xml; charset=utf-8
Content-Length: <font class=value>length</font>
SOAPAction: "http://bsp11.anygo-server.de/SetDatenpacketObjekt"

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <SetDatenpacketObjekt xmlns="http://bsp11.anygo-server.de/">
      <NeuesDatenpacketObjekt>string</NeuesDatenpacketObjekt>

      <Benutzername>string</Benutzername>
      <Passwort>string</Passwort>
    </SetDatenpacketObjekt>
  </soap:Body>
</soap:Envelope>
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: <font class=value>length</font>

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <SetDatenpacketObjektResponse xmlns="http://bsp11.anygo-server.de/">
      <SetDatenpacketObjektResult>boolean</SetDatenpacketObjektResult>

    </SetDatenpacketObjektResponse>
  </soap:Body>
</soap:Envelope>

Bei beiden Funktionen wird zuerst die Authentifizierung des Benutzers durch die beiden übergebenen Parameter "Benutzernamen" und "Passwort" geprüft.
Die "SetDatenpacketObjekt"-Funktion übernimmt das Ergebnis des ersten Aufrufs und übergibt die geänderten Daten des Clients. Bei Erfolg wird "true" zurückgeliefert, ansonsten "false" zurück.

6 Fazit

In dieser Fallstudie wurde erarbeitet, dass es bereits konkurrierende Produkte gibt, jedoch keines, was sich ausschließlich mit der Wunddokumentation des Pflegepersonals befasst. Die Umsetzung ist möglich und es ist auch sinnvoll, für drei unterschiedliche Betriebsyssteme zu entwickeln, da noch nicht absehbar ist, welches sich durchsetzen wird. Durch die Drei-Schichten-Architektur ist nur die Entwicklung einer Datenbank und eines Webservice Paketes von Nutzen, lediglich die GUI's müssen angepasst werden. So können drei Prototypen nebeneinander mit wenigen Anpassungen weiter entwickelt werden.

6.1 Einschätzung

Dieses Wunddokumentationsskenario wäre in Krankenhäusern denkbar und würde dem Pflegepersonal die Arbeit erleichtern. Ärzten wird die Behandlung ebenfalls erleichtert, da ein Fortschritt zu erkennen ist und so Behandlungen besser auf den einzelnen Patienten zugeschnitten werden können. Des Weiteren kann so eine breitere Kundenschicht angesprochen werden, denn der Einsatz wäre außerdem in Praxen niedergelassener Ärzte denkbar oder im Notfallbereich der Feuerwehr.

6.2 Rückblick

Die Fallstudie verlief erfolgreich. Das Ziel, dem Kunden drei unterschiedliche (Mock Up) Prototypen zu zeigen hat funktioniert. Die Einarbeitung in die unterschiedlichen mobilen Betriebssysteme war ebenfalls erfolgreich. Dadurch, dass keine Hardware in Form von iPhone, Android und Windows Phone vorhanden war, konnten nicht alle Funktionalitäten getestet werden. Dies war im Rahmen dieser Fallstudie auch nicht direkt gefordert. Jedes Betriebssystem hat seine Vor- und Nachteile erwiesen. So kann man zusammenfassend sagen, dass iOS das am ausgereifteste ist, Android das umfangreichste und Windows Phone noch nicht vollständig ist, aber hohes Potential hat.

6.3 Ausblick

Diese Anwendung der Wunddokumentation könnte noch erweitert werden durch weitere Funktionalitäten oder durch Partnerschaften mit bereits bestehenden Systemen.

Weitere denkbare Szenarien:

  • Rettungsdienst mobil
  • Notarzt
  • uvm.

Partnerschaften wären wünschenswert mit:

  • Elektronischer Gesundheitskarte, auf Grund der Sicherheit[86]
  • KIS Systemherstellern,[11] [12] [13] um bestehende Daten zu nutzen
  • Krankenkassen, [87]
  • uvm.

7 Literaturverzeichnis

Verwendete Bücher und Links:

  1. 1,0 1,1 1,2 1,3 1,4 1,5 Vgl. http://office.microsoft.com/de-de/visio/ Microsoft Visio
  2. Vgl. http://www.ibsweb.de/cms/index.php?option=com_content&view=article&id=97&Itemid=126
  3. Vgl. http://www.telemedizin-loebau-zittau.de/tele-glossar.php Definition KIS laut Telemedizin
  4. Vgl. http://www.medi-informatik.de/kis.php
  5. Vgl. http://www.slaek.de/40mfa/40rechtsgrundlagen/400ausbildung/240ausb_rahmenplanmfa/index.html
  6. Vgl. http://www.bvmi.de/medinf,historie
  7. Vgl. http://www.ser-solutions.net/ww/de/pub/healthcare/loesungen/elektronische_patientenakte.htm
  8. Vgl. http://www.dmi.de/fileadmin/user_upload/pdf/ArchivAktiv/Koeln/0611_Koeln_Satz_fuer_PDF_news.pdf
  9. Vgl. http://www.documanager.de/magazin/news_h35105_die_digitale_papierakte_-_akten_bearbeiten_wie.html
  10. Vgl. http://www.tagesspiegel.de/wissen/kabelschnur-zur-klinik-hilft-herzkranken/3157136.html
  11. 11,0 11,1 Vgl. http://www.ishmed.com/ Offizielle Homepage
  12. 12,0 12,1 Vgl. http://www.tieto.de/branchen/healthcare/KIS iMedOne
  13. 13,0 13,1 Vgl. http://www.orbis.de/ Offizielle Homepage Orbis
  14. Vgl. http://www.aerzteblatt.de/blogs/44614/iPhone_iPad_Erstes_App_mit_FDA-Segen.htm Ärzteblatt
  15. Vgl. http://blog.management-krankenhaus.de/tag/elektronische-patientenakte/
  16. Vgl. http://www.datenschutz-bayern.de/technik/orient/anb-ext-partner.html
  17. Vgl. http://www.private-gesundheitskarte.de/funktionen/freiwillige_funktionen/elektronische_patientenkarte/
  18. Vgl. http://www.management-krankenhaus.de/topstories/it-kommunikation/elektronische-patientenakte-ueberzeugte
  19. Vgl. https://www.medline-online.com/die-gesundheitskarte/vorteile-praxis.html
  20. Vgl. http://www.egovernment-computing.de/fachanwendungen/articles/190056/
  21. Vgl. http://www.fallakte.de/
  22. Vgl. http://www.macnews.de/ipad/stanfords-medizin-studenten-lernen-mit-dem-ipad-49522
  23. Vgl. http://www.datenschutz-bayern.de/technik/orient/anb-ext-partner.html
  24. Vgl. http://www.telemedizinfuehrer.de/index2.php?option=com_content&do_pdf=1&id=106
  25. Vgl. http://www.docexpert.de
  26. Vgl. http://www.docexpert.de/index.php?id=35
  27. Siehe http://www.isofthealth.com
  28. Siehe http://www.isofthealth.com/de-DE/About%20Us.aspx
  29. Vgl. http://www.ibahealth.com/en/Solutions/ClinicalCollaboration/HealthInformationExchange.aspx
  30. Siehe http://www.isofthealth.com/de-DE/Solutions/DE%20iSOFT%20Enterprise%20Scheduling/iSOFT%20Enterprise%20Scheduling.aspx
  31. Vgl. http://www.healthcare.philips.com/de_de/
  32. Vgl. http://www.healthcare.philips.com/main/about/Company/factsandfigures.wpd
  33. Vgl. http://www.healthcare.philips.com/de_de/products/index.wpd?link_origin=de_de_HC%3Amain%3Aheader-healthcare%3Ahome_main
  34. Vgl. http://www.healthcare.philips.com/de_de/products/patient_monitoring/index.wpd
  35. http://www.healthcare.philips.com/de_de/products/patient_monitoring/products/patient_monitors/index.wpd
  36. http://www.healthcare.philips.com/de_de/products/patient_monitoring/products/surveillance_and_networking/index.wpd
  37. 37,0 37,1 37,2 37,3 Vgl. http://www.gsk-sh.de/filebase/Presse/2_Workshop_PPP_Krankenhaussektor/SIEMENS-Mobile_elektronische_Patientenakte.pdf
  38. Vgl. http://windows.microsoft.com/de-de/windows/products/windows-xp
  39. Vgl. http://www.mobiles-internet-vergleich.info/inhalt/67/UMTS-oder-WLAN.html
  40. Vgl. http://www.it-techblog.de/unterschiede-zwischen-umts-und-wireless-lan/11/2006/
  41. Vgl. http://www.openhandsetalliance.com/oha_faq.html
  42. 42,0 42,1 Vgl. http://www.androider.de/was-ist-android-eine-android-einfuhrung/92598/
  43. Vgl. http://derstandard.at/1287099847480/Vergleich-Windows-Phone-7-gegen-iPhone-und-Android
  44. Vgl. http://www.focus.de/digital/handy/handy-betriebssystem-das-android-update-problem_aid_524502.html
  45. Vgl. http://neuerdings.com/2011/02/03/google-android-honeycomb-bringt-datenverschluesselung/
  46. Vgl. http://mannaz.cc/p/android-verschluesselung-und-kryptographie/
  47. Vgl. http://www.androidpit.de/de/android/blog/393407/Usability-in-Android-Apps-oft-vernachlaessigt
  48. vgl. http://www.apple.com/
  49. Vgl. http://www.apple.com/ios/
  50. Vgl. http://luxsci.com/blog/256-bit-aes-encryption-for-ssl-and-tls-maximal-security.html
  51. Vgl. http://www.spiegel.de/netzwelt/mobil/0,1518,638038,00.html
  52. Vgl. ttp://www.macnews.de/iphone/zugriff-auf-iphone-trotz-verschlusselung-23168
  53. Vgl. http://derstandard.at/1287099847480/Vergleich-Windows-Phone-7-gegen-iPhone-und-Android
  54. Vgl. https://www.bsi.bund.de/ContentBSI/Presse/Pressemitteilungen/Sicherheitsupdate_fuer_Apple_Betriebssystem_iOS_verfuegbar_120810.html
  55. Vgl. http://www.microsoft.com/germany/msdn/webcasts/library.aspx?id=1032462227 WP7
  56. Siehe http://msdn.microsoft.com/de-de/windowsphone/gg455977.aspx
  57. Vgl. http://msdn.microsoft.com/de-de/windowsphone/gg455977.aspx
  58. Vgl. http://www.brighthub.com/mobile/windows-mobile-platform/articles/103334.aspx
  59. Vgl. http://www.infoworld.com/d/mobilize/windows-phone-7-lacks-device-encryption-585
  60. Vgl. http://www.microsoft.com/germany/msdn/webcasts/library.aspx?id=1032454108 WP7
  61. http://www.itwissen.info/definition/lexikon/Drei-Schichten-Architektur-three-tier-architecture.html
  62. 62,0 62,1 62,2 Bild übernommen von https://www.fbi.h-da.de/fileadmin/personal/r.hahn/2007WS/SWT2/13_RH_SWT2.pdf
  63. Vgl. http://www8.informatik.uni-erlangen.de/IMMD8/Lectures/SS03/algo2/AlgII.FAU.SS03.Kap21_1.pdf
  64. Vgl. https://www.fbi.h-da.de/fileadmin/personal/r.hahn/2007WS/SWT2/13_RH_SWT2.pdf
  65. Vgl. http://www.microsoft.com/expression/products/blend_overview.aspx
  66. Vgl. http://www.microsoft.com/expression/products/Sketchflow_Overview.aspx
  67. Vgl. http://bsp05.anygo-server.de/TestPage.html
  68. Vgl. http://www.microsoft.com/expression/products/Sketchflow_Overview.aspx
  69. http://msdn.microsoft.com/de-de/library/ee341405%28v=expression.40%29.aspx
  70. Vgl. http://www.microsoft.com/germany/visualstudio/
  71. Vgl. http://www.microsoft.com/express/Phone/
  72. Vgl. http://www.microsoft.com/germany/expression/products/StudioUltimate_Overview.aspx?WT.mc_id=SEARCH&WT.srch=1
  73. Vgl. http://msdn.microsoft.com/de-de/windowsphone/default
  74. Vgl. http://www.heise.de/ct/artikel/Microsoft-mischt-auf-961967.html abgerufen am 15. Oktober 2010 (aus c't 8/10)
  75. Vgl. http://msdn.microsoft.com/de-de/windowsphone/ff380145, abgerufen am 15. Oktober 2010
  76. Vgl. http://www.microsoft.com/express/Phone/, abgerufen am 15. Oktober 2010
  77. Vgl. http://www.microsoft.com/germany/visualstudio/products/, abgerufen am 15. Oktober 2010.
  78. Vgl. http://www.microsoft.com/downloads/de-de/details.aspx?FamilyID=04704acf-a63a-4f97-952c-8b51b34b00ce, abgerufen am 25. Oktober 2010
  79. 79,0 79,1 79,2 http://www.extracta-orthopaedica.de/gips.jpg
  80. Vgl. http://arstechnica.com/open-source/reviews/2009/02/an-introduction-to-google-android-for-developers.ars
  81. Vgl. http://zbar.sourceforge.net/iphone/
  82. Vgl. http://www.mobile-dev.de/einfuerhung-in-die-iphone-entwicklung.html
  83. Vgl. http://www.mactechnews.de/news/index.html?id=140491
  84. http://www.w3.org/TR/ws-arch/#whatis
  85. http://dspace.icsy.de:12000/dspace/bitstream/123456789/47/2/DPArchiv.0136.pdf
  86. http://www.aerzteblatt.de/v4/archiv/artikel.asp?id=59362
  87. http://www.aok.de/bundesweit/gesundheit/behandlung-arzt-und-krankenhaus-17211.php

Weiterführende Links in diesem WinfWiki:

8 Abbildungsverzeichnis

Abb.-Nr.Abbildung
1Ist-Analyse, eigene Darstellung mit Hilfe von Microsoft Visio(MS Visio)
2Soll-Konzept, eigene Darstellung mit Hilfe von MS Visio
3Technologien, eigene Darstellung Hilfe von MS Visio
4Smartphones als Alternative, eigene Darstellung Hilfe von MS Visio
5Programmablauf, eigene Darstellung mit Hilfe von MS Visio
6Prototyp
7Explorativer Prototyp
8Technischer Prototyp
9Login
10Ansichten Menue
11Aufnahmediagnostik
12Barcode scannen
13Befund
14Behandlung starten
15Bericht ansehen
16Berichteliste ansehen
17Fotos machen
18Hauptmenue
19Krankenblatt ansehen
20Krankenblatt manuell öffnen
21Krankenblatt öffnen
22Medikamentierung
23Notizen hinzufuegen
24Pflege
25Stammdaten ansehen
27Klassendiagramm
28Login
29Krankenblatt öffnen
30Barcode Scannen
31Hauptmenü
32Behandlung starten
33Fotos hinzufügen
34Ansichten Menü
35Krankenblatt ansehen
36Datenbankmodell

9 Tabellenverzeichnis

Tabelle Nr.Beschreibung
1Übertragungsmöglichkeiten
2Vergleich der Technologien
3Benutzeroberflächen des Prototypen
4Spezifikationen View-Controller
5Windows Phone Oberfläche
6Android Oberfläche
7iOS Oberfläche

10 Abkürzungsverzeichnis

AbkürzungBedeutung
.NETFramework unterschiedlicher Programmiersprachen von Microsoft
2D, 3Dzwei- bzw. dreidimensional
C#C Sharp, objektorientierte Programmiersprache aus dem .NET Bereich
EXIFDateierweiterung von z. B. JPG Dateien
GPSGlobal Position System, Lokalisierungssystem anhand von 3 Satelliten
IDIdentifikationsnummer
iOSiPhone OS
JavaObjektorientierte Programmiersprache der Firma Sun
LEDLumineszenz-Diode; Leuchtdiode
MBMega Byte, 1024 Bytes
Objective CProgrammiersprache, die auf C aufbaut und um die Objektorientierung erweiter ist
OSengl.Operating System, Betriebssystem
PHPSkriptsprache
SOAPNetzwerkprotokol (Simple Object Access Protocol)
UMTSUniversal Mobile Telecommunications System; Mobilfunkstandard
WLANWireless Local Area Network; drahtloses lokales Netzwerk
Persönliche Werkzeuge