Healthcare goes mobile: Konzept mobiler Patientendokumentation
Aus Winfwiki
| 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 |
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
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
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
- 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]:
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
- Bild-Aufnahme vom 2D-Barcode
- b alternativ: direkte Zahleneingabe des Barcodes ermöglichen (falls das Foto nicht den erwünschten Effekt bringt)
- Auslesen der Patienten-ID aus dem 2D-Barcode (Matrix) auf dem Handy
- 1 bis n Aufnahmen von Wunden des Patienten mit Speicherung Dateiname PATNR-XXX.JPG
- Taggen der Wundbilder (EXIF) mit Datum, Uhrzeit und wenn verfügbar GPS Koordinaten
- 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
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
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
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 | |
| 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
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
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
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
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:
- Die Überprüfung der Machbarkeit.
- Die Abschätzung des Aufwandes, des Zeitbedarfs und dementsprechend der Kosten der Realisierung.
- Ein Vergleich der technischen Plattformen iPhone, Windows Phone und Android.
- 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:
- Beim Einloggen, wo benutzerrelevante Daten geladen werden.
- Das Öffnen des Krankenblatts durch das Scannen eines Barcodes. Getestet soll ihr werden, wie das Scannen eines Barcodes auf den verschiedenen Systemen funktioniert.
- 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
"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. | |
| 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ü. | |
| 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". | |
| 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". | |
| 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". | |
| 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ü. | |
| 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
| |
| 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. | |
| 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. | |
| 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". | |
| 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ü. | |
| 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. | |
| 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. | |
| 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.:
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. | |
| 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. | |
| 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". | |
| 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. |
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
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
Nach dem Klick Ereignis des Login Buttons (siehe 5.1.1.3 Login Bildschirm) wird die Authentifizierung des Benutzers durch die Funktion
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
| |
| Krankenblatt öffnen
Diese Klasse beinhaltet die Funktionen der Klickereignisse des Auswahlmenüs "Krankenblatt öffnen" und die Funktion zum Ausloggen.
Rückgabe Bool: liefert true bei erfolgreicher Aktualisierung und false bei Problemen. | |
| 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. | |
| Hauptmenü
Diese Klasse beinhaltet die Funktionen der Klickereignisse des Auswahlmenüs "HaupMenue" | |
| Behandlung starten
Diese Klasse beinhaltet die Funktionen der Klickereignisse des Auswahlmenüs "BehandlungStarten" | |
| 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. | |
| Ansichten Menü
Diese Klasse beinhaltet die Funktionen der Klickereignisse des Auswahlmenüs "Ansichten Menü" | |
| Krankenblatt ansehen
|
Tabelle 4: Spezifikationen ViewController
5.1.2.2 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 |
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 |
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 |
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,0 1,1 1,2 1,3 1,4 1,5 Vgl. http://office.microsoft.com/de-de/visio/ Microsoft Visio
- ↑ Vgl. http://www.ibsweb.de/cms/index.php?option=com_content&view=article&id=97&Itemid=126
- ↑ Vgl. http://www.telemedizin-loebau-zittau.de/tele-glossar.php Definition KIS laut Telemedizin
- ↑ Vgl. http://www.medi-informatik.de/kis.php
- ↑ Vgl. http://www.slaek.de/40mfa/40rechtsgrundlagen/400ausbildung/240ausb_rahmenplanmfa/index.html
- ↑ Vgl. http://www.bvmi.de/medinf,historie
- ↑ Vgl. http://www.ser-solutions.net/ww/de/pub/healthcare/loesungen/elektronische_patientenakte.htm
- ↑ Vgl. http://www.dmi.de/fileadmin/user_upload/pdf/ArchivAktiv/Koeln/0611_Koeln_Satz_fuer_PDF_news.pdf
- ↑ Vgl. http://www.documanager.de/magazin/news_h35105_die_digitale_papierakte_-_akten_bearbeiten_wie.html
- ↑ Vgl. http://www.tagesspiegel.de/wissen/kabelschnur-zur-klinik-hilft-herzkranken/3157136.html
- ↑ 11,0 11,1 Vgl. http://www.ishmed.com/ Offizielle Homepage
- ↑ 12,0 12,1 Vgl. http://www.tieto.de/branchen/healthcare/KIS iMedOne
- ↑ 13,0 13,1 Vgl. http://www.orbis.de/ Offizielle Homepage Orbis
- ↑ Vgl. http://www.aerzteblatt.de/blogs/44614/iPhone_iPad_Erstes_App_mit_FDA-Segen.htm Ärzteblatt
- ↑ Vgl. http://blog.management-krankenhaus.de/tag/elektronische-patientenakte/
- ↑ Vgl. http://www.datenschutz-bayern.de/technik/orient/anb-ext-partner.html
- ↑ Vgl. http://www.private-gesundheitskarte.de/funktionen/freiwillige_funktionen/elektronische_patientenkarte/
- ↑ Vgl. http://www.management-krankenhaus.de/topstories/it-kommunikation/elektronische-patientenakte-ueberzeugte
- ↑ Vgl. https://www.medline-online.com/die-gesundheitskarte/vorteile-praxis.html
- ↑ Vgl. http://www.egovernment-computing.de/fachanwendungen/articles/190056/
- ↑ Vgl. http://www.fallakte.de/
- ↑ Vgl. http://www.macnews.de/ipad/stanfords-medizin-studenten-lernen-mit-dem-ipad-49522
- ↑ Vgl. http://www.datenschutz-bayern.de/technik/orient/anb-ext-partner.html
- ↑ Vgl. http://www.telemedizinfuehrer.de/index2.php?option=com_content&do_pdf=1&id=106
- ↑ Vgl. http://www.docexpert.de
- ↑ Vgl. http://www.docexpert.de/index.php?id=35
- ↑ Siehe http://www.isofthealth.com
- ↑ Siehe http://www.isofthealth.com/de-DE/About%20Us.aspx
- ↑ Vgl. http://www.ibahealth.com/en/Solutions/ClinicalCollaboration/HealthInformationExchange.aspx
- ↑ Siehe http://www.isofthealth.com/de-DE/Solutions/DE%20iSOFT%20Enterprise%20Scheduling/iSOFT%20Enterprise%20Scheduling.aspx
- ↑ Vgl. http://www.healthcare.philips.com/de_de/
- ↑ Vgl. http://www.healthcare.philips.com/main/about/Company/factsandfigures.wpd
- ↑ Vgl. http://www.healthcare.philips.com/de_de/products/index.wpd?link_origin=de_de_HC%3Amain%3Aheader-healthcare%3Ahome_main
- ↑ Vgl. http://www.healthcare.philips.com/de_de/products/patient_monitoring/index.wpd
- ↑ http://www.healthcare.philips.com/de_de/products/patient_monitoring/products/patient_monitors/index.wpd
- ↑ http://www.healthcare.philips.com/de_de/products/patient_monitoring/products/surveillance_and_networking/index.wpd
- ↑ 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
- ↑ Vgl. http://windows.microsoft.com/de-de/windows/products/windows-xp
- ↑ Vgl. http://www.mobiles-internet-vergleich.info/inhalt/67/UMTS-oder-WLAN.html
- ↑ Vgl. http://www.it-techblog.de/unterschiede-zwischen-umts-und-wireless-lan/11/2006/
- ↑ Vgl. http://www.openhandsetalliance.com/oha_faq.html
- ↑ 42,0 42,1 Vgl. http://www.androider.de/was-ist-android-eine-android-einfuhrung/92598/
- ↑ Vgl. http://derstandard.at/1287099847480/Vergleich-Windows-Phone-7-gegen-iPhone-und-Android
- ↑ Vgl. http://www.focus.de/digital/handy/handy-betriebssystem-das-android-update-problem_aid_524502.html
- ↑ Vgl. http://neuerdings.com/2011/02/03/google-android-honeycomb-bringt-datenverschluesselung/
- ↑ Vgl. http://mannaz.cc/p/android-verschluesselung-und-kryptographie/
- ↑ Vgl. http://www.androidpit.de/de/android/blog/393407/Usability-in-Android-Apps-oft-vernachlaessigt
- ↑ vgl. http://www.apple.com/
- ↑ Vgl. http://www.apple.com/ios/
- ↑ Vgl. http://luxsci.com/blog/256-bit-aes-encryption-for-ssl-and-tls-maximal-security.html
- ↑ Vgl. http://www.spiegel.de/netzwelt/mobil/0,1518,638038,00.html
- ↑ Vgl. ttp://www.macnews.de/iphone/zugriff-auf-iphone-trotz-verschlusselung-23168
- ↑ Vgl. http://derstandard.at/1287099847480/Vergleich-Windows-Phone-7-gegen-iPhone-und-Android
- ↑ Vgl. https://www.bsi.bund.de/ContentBSI/Presse/Pressemitteilungen/Sicherheitsupdate_fuer_Apple_Betriebssystem_iOS_verfuegbar_120810.html
- ↑ Vgl. http://www.microsoft.com/germany/msdn/webcasts/library.aspx?id=1032462227 WP7
- ↑ Siehe http://msdn.microsoft.com/de-de/windowsphone/gg455977.aspx
- ↑ Vgl. http://msdn.microsoft.com/de-de/windowsphone/gg455977.aspx
- ↑ Vgl. http://www.brighthub.com/mobile/windows-mobile-platform/articles/103334.aspx
- ↑ Vgl. http://www.infoworld.com/d/mobilize/windows-phone-7-lacks-device-encryption-585
- ↑ Vgl. http://www.microsoft.com/germany/msdn/webcasts/library.aspx?id=1032454108 WP7
- ↑ http://www.itwissen.info/definition/lexikon/Drei-Schichten-Architektur-three-tier-architecture.html
- ↑ 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
- ↑ Vgl. http://www8.informatik.uni-erlangen.de/IMMD8/Lectures/SS03/algo2/AlgII.FAU.SS03.Kap21_1.pdf
- ↑ Vgl. https://www.fbi.h-da.de/fileadmin/personal/r.hahn/2007WS/SWT2/13_RH_SWT2.pdf
- ↑ Vgl. http://www.microsoft.com/expression/products/blend_overview.aspx
- ↑ Vgl. http://www.microsoft.com/expression/products/Sketchflow_Overview.aspx
- ↑ Vgl. http://bsp05.anygo-server.de/TestPage.html
- ↑ Vgl. http://www.microsoft.com/expression/products/Sketchflow_Overview.aspx
- ↑ http://msdn.microsoft.com/de-de/library/ee341405%28v=expression.40%29.aspx
- ↑ Vgl. http://www.microsoft.com/germany/visualstudio/
- ↑ Vgl. http://www.microsoft.com/express/Phone/
- ↑ Vgl. http://www.microsoft.com/germany/expression/products/StudioUltimate_Overview.aspx?WT.mc_id=SEARCH&WT.srch=1
- ↑ Vgl. http://msdn.microsoft.com/de-de/windowsphone/default
- ↑ Vgl. http://www.heise.de/ct/artikel/Microsoft-mischt-auf-961967.html abgerufen am 15. Oktober 2010 (aus c't 8/10)
- ↑ Vgl. http://msdn.microsoft.com/de-de/windowsphone/ff380145, abgerufen am 15. Oktober 2010
- ↑ Vgl. http://www.microsoft.com/express/Phone/, abgerufen am 15. Oktober 2010
- ↑ Vgl. http://www.microsoft.com/germany/visualstudio/products/, abgerufen am 15. Oktober 2010.
- ↑ Vgl. http://www.microsoft.com/downloads/de-de/details.aspx?FamilyID=04704acf-a63a-4f97-952c-8b51b34b00ce, abgerufen am 25. Oktober 2010
- ↑ 79,0 79,1 79,2 http://www.extracta-orthopaedica.de/gips.jpg
- ↑ Vgl. http://arstechnica.com/open-source/reviews/2009/02/an-introduction-to-google-android-for-developers.ars
- ↑ Vgl. http://zbar.sourceforge.net/iphone/
- ↑ Vgl. http://www.mobile-dev.de/einfuerhung-in-die-iphone-entwicklung.html
- ↑ Vgl. http://www.mactechnews.de/news/index.html?id=140491
- ↑ http://www.w3.org/TR/ws-arch/#whatis
- ↑ http://dspace.icsy.de:12000/dspace/bitstream/123456789/47/2/DPArchiv.0136.pdf
- ↑ http://www.aerzteblatt.de/v4/archiv/artikel.asp?id=59362
- ↑ http://www.aok.de/bundesweit/gesundheit/behandlung-arzt-und-krankenhaus-17211.php
Weiterführende Links in diesem WinfWiki:
8 Abbildungsverzeichnis
| Abb.-Nr. | Abbildung |
|---|---|
| 1 | Ist-Analyse, eigene Darstellung mit Hilfe von Microsoft Visio(MS Visio) |
| 2 | Soll-Konzept, eigene Darstellung mit Hilfe von MS Visio |
| 3 | Technologien, eigene Darstellung Hilfe von MS Visio |
| 4 | Smartphones als Alternative, eigene Darstellung Hilfe von MS Visio |
| 5 | Programmablauf, eigene Darstellung mit Hilfe von MS Visio |
| 6 | Prototyp |
| 7 | Explorativer Prototyp |
| 8 | Technischer Prototyp |
| 9 | Login |
| 10 | Ansichten Menue |
| 11 | Aufnahmediagnostik |
| 12 | Barcode scannen |
| 13 | Befund |
| 14 | Behandlung starten |
| 15 | Bericht ansehen |
| 16 | Berichteliste ansehen |
| 17 | Fotos machen |
| 18 | Hauptmenue |
| 19 | Krankenblatt ansehen |
| 20 | Krankenblatt manuell öffnen |
| 21 | Krankenblatt öffnen |
| 22 | Medikamentierung |
| 23 | Notizen hinzufuegen |
| 24 | Pflege |
| 25 | Stammdaten ansehen |
| 27 | Klassendiagramm |
| 28 | Login |
| 29 | Krankenblatt öffnen |
| 30 | Barcode Scannen |
| 31 | Hauptmenü |
| 32 | Behandlung starten |
| 33 | Fotos hinzufügen |
| 34 | Ansichten Menü |
| 35 | Krankenblatt ansehen |
| 36 | Datenbankmodell |
9 Tabellenverzeichnis
| Tabelle Nr. | Beschreibung |
|---|---|
| 1 | Übertragungsmöglichkeiten |
| 2 | Vergleich der Technologien |
| 3 | Benutzeroberflächen des Prototypen |
| 4 | Spezifikationen View-Controller |
| 5 | Windows Phone Oberfläche |
| 6 | Android Oberfläche |
| 7 | iOS Oberfläche |
10 Abkürzungsverzeichnis
| Abkürzung | Bedeutung |
|---|---|
| .NET | Framework unterschiedlicher Programmiersprachen von Microsoft |
| 2D, 3D | zwei- bzw. dreidimensional |
| C# | C Sharp, objektorientierte Programmiersprache aus dem .NET Bereich |
| EXIF | Dateierweiterung von z. B. JPG Dateien |
| GPS | Global Position System, Lokalisierungssystem anhand von 3 Satelliten |
| ID | Identifikationsnummer |
| iOS | iPhone OS |
| Java | Objektorientierte Programmiersprache der Firma Sun |
| LED | Lumineszenz-Diode; Leuchtdiode |
| MB | Mega Byte, 1024 Bytes |
| Objective C | Programmiersprache, die auf C aufbaut und um die Objektorientierung erweiter ist |
| OS | engl.Operating System, Betriebssystem |
| PHP | Skriptsprache |
| SOAP | Netzwerkprotokol (Simple Object Access Protocol) |
| UMTS | Universal Mobile Telecommunications System; Mobilfunkstandard |
| WLAN | Wireless Local Area Network; drahtloses lokales Netzwerk |

