Zum Inhalt springen

„Nur ein Formular“

Seit mittlerweile 4 Jahren arbeiten wir an einer spannenden, herausfordernden Aufgabe: Wir entwickeln eine mobile Einsatzdokumentations-App. Gemeinsam mit unserem Pilotkunden, dem Roten Kreuz Oberösterreich, entsteht eine moderne Softwarelösung, die zukünftig in allen Rettungs- und Notarztwägen in Oberösterreich (und hoffentlich bald darüber hinaus) die Einsätze begleiten wird. 

Auf den ersten Blick haben wir „nur ein Formular“ gebaut. Was früher am Papier ausgefüllt wurde, wird nun mit Textfeldern, Checkboxen und Auswahlfeldern eben digital dokumentiert. Ein „One-Pager“. Könnte man mit Google Forms in 3-4 Stunden nachbauen. Aber wenn mich Software-Entwicklung eines gelehrt hat: Was einfach aussieht, ist meistens richtig kompliziert. Wir geben in diesem Artikel einige Einblicke in die Entwicklung einer unserer komplexesten Anwendungen. 

Unsere Anwendung ist eigentlich ein Zusammenspiel aus 17 Anwendungen: zwei Apps, mehrere APIs, Schnittstellen, Administrationsoberflächen, etc. Unser größtes Augenmerk liegt dabei auf der App für Sanitäterinnen und Sanitäter: Solange diese Anwendung noch läuft, kann im Hintergrund alles ausfallen – und der Benutzer merkt es nicht einmal. Einsatzformulare können komplett ohne Verbindung zum Server (also auch offline) ausgefüllt und bearbeitet werden, der sichere Login funktioniert weiterhin – und irgendwann, sobald wieder eine Verbindung hergestellt werden kann, synchronisieren wir automatisch alle Daten. 

Wir betreiben die Anwendungen nicht auf irgendeinem Server im Keller. Wir vertrauen auf eine Kombination aus Cloudrechenzentren von Microsoft und lokalen Rechenzentren des Kunden. Mehrere parallele Instanzen und entsprechende Loadbalancer ermöglichen es uns, jederzeit Updates ohne Betriebsunterbrechung einzuspielen – und zwar vollautomatisiert. 
Die Kommunikation zwischen den Systemen ist so aufgebaut, dass einzelne Bereiche vorübergehend ausfallen können – und trotzdem keine Daten verloren gehen. Im schlimmsten Fall landen Einsatzdaten eben erst am nächsten Tag in der Verrechnung – aber die Einsatzdokumentation vor Ort muss davon unbeeindruckt bleiben. 
Ein spannender Tag für 24×7-Anwendungen ist übrigens jedes Jahr der letzte Sonntag im Oktober. Wenn die Uhren von 3 Uhr auf 2 Uhr zurückgestellt werden, können „lustige“ Dinge passieren. 

Medizinische Daten sind höchst sensibel. Ja, manchmal wird zwischen der analogen und der digitalen Welt mit zweierlei Maß gemessen: Während man in manchen Arztordinationen die gesamte Krankheitsgeschichte wildfremder Menschen schon im Wartebereich mithören kann, so würde eine derart geschwätzige Software zurecht durch alle DSGVO-Audits durchfallen. 
Security nimmt daher bei der Entwicklung einen immens großen Stellenwert ein – und fällt im besten Fall nicht auf. Manchmal aber lösen Entscheidungen für die Security große Nachteile für die Usability aus. Es ist beispielsweise mittlerweile Standard, bei kritischen Anwendungen einen 2. Faktor zu benötigen. Nach der Eingabe von Benutzername und Passwort klingelt dann noch das Smartphone und stellt sicher, dass alles mit rechten Dingen zugeht. Die Meinung von Juristen und Datenschutz-Expertinnen ist klar: Software mit dieser Sensibilität muss bei der Authentifizierung extrem hohe Voraussetzungen erfüllen. Nun stellen Sie sich aber kurz eine Notärztin vor, die vor der Dokumentation einer Medikamentengabe zunächst Benutzername und Passwort mit Touchbedienung eintippt und schließlich noch ihr Smartphone zur Bestätigung hervorkramen muss: Dann haben wir eine sichere Software geschaffen, die sicher nicht verwendet wird. Usability vs. Security. 

Unser Ansatz ist, die Software in verschiedene Sicherheitsstufen einzuteilen. Beim aktuell laufenden Einsatz schrauben wir die Sicherheitsansprüche zugunsten der Usability herunter: Eine simple und somit tendenziell unsichere Anmeldung mittels geschützter RFID-Tokens ist dort ausreichend. Der Zugriff auf ältere Protokolle des aktuellen Tages ist hingegen nur mit einem 2. Faktor möglich – die Zeitkritikalität ist hier nicht mehr gegeben, die Security gewinnt in diesem Fall. 

Entscheidend ist auch, wo die Daten liegen und wie sie dort geschützt sind. Unsere Einsatzdaten sind so verschlüsselt, dass auch Entwicklerinnen und Entwickler mit vollen Administrationsrechten standardmäßig keinen Zugriff auf die sensiblen Daten haben. Sobald Einsätze am Ende des Tages abgeschlossen sind, werden zudem sämtliche Daten in ein vom Kunden betriebenes Rechenzentrum verschoben, um dort langjährig aufbewahrt zu werden. Das produktive System vergisst die Daten und reduziert so die Angriffsfläche. Auch am Tablet selbst liegen nur die für die Offlinefähigkeit benötigten Daten, sollte ein Gerät verloren gehen, so kann auch ein potenzieller Angreifer aufgrund der Verschlüsselung nichts damit anfangen.

Stichwort Angreifer: Um auf Nummer sicher zu gehen, wird unser Einsatzprotokoll regelmäßigen „Penetration Tests“ unterzogen. Professionelle Hacker werden von uns vorab mit sämtlichen relevanten Implementierungsdetails gebrieft – und versuchen dann, Lücken und mögliche Angriffspunkte in der Software zu finden. Unangenehm, wenn dabei Schwachstellen zu Tage treten – aber immer noch viel angenehmer, als wenn Angreifer sie finden würden. 

Medizinische Daten sind höchst sensibel. Ja, manchmal wird zwischen der analogen und der digitalen Welt mit zweierlei Maß gemessen: Unsere App ist keine abgeschottete Anwendung, sondern spricht über verschiedenste Schnittstellen mit Systemen von 5 unterschiedlichen Herstellern. Bei Einsatzorganisationen, die weit über 10.000 ehrenamtliche Mitarbeiterinnen und Mitarbeiter haben, muss die gesamte Zugriffsberechtigung vollautomatisiert funktionieren, wir bekommen den aktuellen Mitarbeiterstand daher jede Nacht aus dem zentralen System geliefert. 

Die Reise eines Einsatzes beginnt dann im Einsatzleitsystem der Rettungsleitstelle. Die dort erfragten Daten werden ins Formular übernommen, während des Einsatzes findet ein ständiger Informationsaustausch statt: „Fahrzeug ist eingetroffen“, „der Zielort hat sich geändert“, „der Name des Patienten war falsch geschrieben“.  Um die Eingabe im Formular zu unterstützen, können wir mit Hilfe der Versichertendatenabfrage der Sozialversicherungsträger Informationen zum Patienten erfragen. Notärzte können zudem Patientinnen und Patienten in den Ziel-Krankenhäusern digital voranmelden, damit dort bereits administrative und organisatorische Vorbereitungen getroffen werden können. 

Nach dem Einsatz geht die Reise weiter in Richtung Transportverrechnung, bestimmte Daten werden für Auswertungs- und Analysezwecke ins Datawarehouse übersiedelt. Jede dieser Schnittstellen erfordert neben der Entwicklung zahlreiche juristische, kaufmännische und technologische Abstimmungen – und viele Stunden an Tests, um nicht nur den Standardfall, sondern auch zahlreiche Sonderfälle korrekt abbilden zu können. 

Medizinische Daten sind höchst sensibel. Ja, manchmal wird zwischen der analogen und der digitalen Welt mit zweierlei Maß gemessen: Es fasziniert uns, herausfordernde Softwarelösungen zu bauen – die für den End-User noch immer „einfach“ aussehen. Die sichtbare Benutzeroberfläche ist oft nur die Spitze des Eisbergs, die von zahlreichen Überlegungen hinsichtlich Verfügbarkeit, Security und Datenschutz getragen wird. Es braucht bei der Entwicklung immer wieder Fingerspitzengefühl und kreative Ideen, um die verschiedenen funktionalen und nicht-funktionalen Anforderungen abzuwägen und dabei das eigentliche Ziel nicht aus dem Auge zu verlieren: ein Formular zu bauen. Aber was für eines. 

Sie sind interessiert?

Wir helfen gerne weiter!