Datenschutzerklärung

Letzte Anpassung am 03.09.2020

Der Datenschutz spielt beim Einsatz von NIDA eine besondere Rolle, da Daten des Rettungsdienstes an unterschiedliche Empfänger, beispielsweise Kliniken und Abrechnungsstellen,  versendet werden, welche bislang nur telefonisch oder überhaupt nicht kommuniziert wurden. Daher ist sicherzustellen, dass die Daten korrekt und vollständig übermittelt (Datensicherheit) und die Daten nur von autorisierten Personen eingesehen und nur für den angedachten Bestimmungszweck (Datenschutz) eingesetzt werden. Es wird empfohlen mit jedem Datenempfänger einen Vertrag über die Nutzung der Daten abzuschließen.

1.     Grund für die Dokumentation

Die Durchführung des Rettungsdienstes ist eine öffentliche Aufgabe der Gefahrenabwehr und der Gesundheitsvorsorge, welche in den meisten Fällen von den Trägern (Landkreise, kreisfreie Städte) an Leistungserbringer delegiert wird. Die Leistungserbringer sind Hilfsorganisationen, Feuerwehren als auch private Rettungsdienste.

Das Rettungsdienstpersonal ist zur Dokumentation im Rahmen des jeweiligen Rettungsdienstgesetzes verpflichtet.

Die Durchführenden des Rettungsdienstes müssen die Dokumentationsverpflichtung durchsetzen, die erhobenen Daten auswerten und die Ergebnisse als Grundlage der Qualitätssicherung verwenden.

Das primäre Ziel der Erfassung und Speicherung der erhobenen Daten dient daher dem Qualitätsmanagement.

2.    Funktionsweise

2.1.   Disposition

Der Leitstellendisponent nimmt den Notruf entgegen und erfasst dabei die Einsatzstelle, den Namen des Patienten, den Namen des Anrufers inkl. Telefonnummer und stellt eine erste Verdachtsdiagnose. Durch das Anlegen eines neuen Datensatzes im Einsatzleitrechner entstehen weitere Daten wie Einsatznummer und Einsatzdatum. Im weiteren Verlauf werden dem Einsatz Fahrzeug(e), also Funkrufnamen zugeordnet und die Zeiten (Alarmierung, Ausrücken, Eintreffen, Abfahrt, Klinik, Klinik frei und Ende) protokolliert.

2.2.   Datenerfassung

Die Datenerfassung erfolgt auf dem mit Touchscreen ausgerüsteten und medizinischen Vorgaben entsprechenden Tablet PC (z.B. NIDApad) mittels Fingerdruck auf aktive Flächen (Buttons). Auf diesem Tablet PC ist als Betriebssystem Windows 10 IoT Enterprise LTSB installiert. Auf diesem aufgesetzt die medDV-eigene Software (Applikation) zur Datenerfassung (NIDAmobile). Diese Software läuft unter einem lokalen Benutzeraccount, der keine Administratorenrechte besitzt. Zudem wird statt der Windows- eigenen Shell eine medDV-eigene eingesetzt, die Zugriffe des Benutzers auf das System verhindert. Ein weiterer Benutzeraccount, der zur Administration des Geräts dient, ist durch ein sicheres Passwort geschützt. In diesen Benutzer kann nur durch den Zugang über den Administratorbereich der medDV-Software gewechselt werden. D.h. dass beide Passwörter bekannt sein müssen (Admin Passwort für die medDV Software und das Admin Passwort des Betriebssystems). Für die Systempartition wird der Windows Schreibfilter (Unified Write Filter, UWF) verwendet, um persistente Änderungen am System zu verhindern. D.h. dass das System nach einem Neustart auf den Ursprungszustand zurückgesetzt wird. Gegebenenfalls notwendige und dauerhafte Systemänderungen können nur über das Einspielen von Bereitstellungspaketen mittels eines eigenen Systemdienstes vorgenommen werden. Diese Pakete sind mit einem medDV-Zertifikat signiert; andere nicht-signierte Pakete können daher nicht eingespielt werden. Die Installation der Bereitstellungspakete ist zudem nur über die Nutzung der medDV-Software für den Standard-Benutzeraccount möglich und wird automatisiert durchgeführt.

Über die Anwendung von Gruppenrichtlinien wird sichergestellt, dass OneDrive, Cortana und der Windows Store nicht genutzt werden können. Zudem wird die Übertragung von Telemetrie-Daten an Microsoft weitgehend unterbunden. Generell richten wir uns nach der aktuellen Security Baseline von Microsoft, um unsichere Funktionen des Betriebssystems abzuschalten und zu beschränken. Beispielsweise sind das veraltete SMB1-Protokoll, SSL3 und der Dienst zur Windows-Suche abgeschaltet.

Die Windows Firewall ist so konfiguriert, dass eingehende Verbindungen, für die es keine Regel gibt, blockiert werden. Weiterhin ist das System derart konfiguriert, dass der Zugriff auf Kamera, Mikrofon, Position sowie Diagnose- und Nutzungsdaten unterbunden wird.

Um beispielsweise das Beenden unserer Anwendung über Tastaturkürzel zu verhindern, verwenden wir einen Tastaturfilter. Über diesen Filter werden alle Tastatureingaben geblockt, die einen Zugriff auf das Betriebssystem oder ungewollte Aktionen ermöglichen.

Die Applikation bietet dabei ausreichend große Tasten um eine zügige und problemlose Erfassung zu ermöglichen. Zum Schichtbeginn melden sich die Benutzer mit Name und Nummer an. Wenn vorhanden kann die Versichertenkarte / elektronische Gesundheitskarte über einen integrierten Smartcard Reader eingelesen werden. Zur Laufzeit des Programms sind alle erfassten Daten in einem stromabhängigen Speicher (RAM). Der Datenverlust durch Stromausfall oder durch Fehler in der Applikation ist durch automatisierte Datensicherung abgesichert. Dies geschieht zum Beispiel nach dem Ausfüllen von Formularen, dem Einlesen der Versichertenkarte, Protokollausdrucken, etc. Die Daten zur Wiederherstellung werden in einem stromunabhängigen Speicher (z. B. Festplatte) abgelegt. Wird die Software- gleich aus welchem Grund- unerwartet beendet, werden die Daten beim Neustart der Software automatisch wiederhergestellt. Grundsätzlich startet die Software immer mit einem PIN-Dialog bzw. Bildschirmsperre.

Die Datensicherung erfolgt mit einer symmetrischen AES Verschlüsselung (siehe 5.2).

Bei vielen Rettungseinsätzen sind zwei Rettungsmittel- zum Beispiel Notarzteinsatzfahrzeug und Rettungswagen- im Einsatz. Häufig kommt es dabei vor, dass der Patient nicht vom Notarzt in die Klinik begleitet werden muss. Der Notarzt steht dadurch schneller neuen Einsätzen zur Verfügung. Die erforderliche Zusammenführung der Dokumentation der rettungsdienstlichen- und der ärztlichen Tätigkeiten sowie der Patientenmesswerte erfolgt über Bluetooth®. Dabei wird die Übertragung durch den Benutzer auf dem empfangenden Pad initiiert. Die Übertragung MUSS auf dem sendenden Pad innerhalb von 10 Sekunden durch den Benutzer bestätigt werden.

Eine automatisierte Bildschirmsperrung erfolgt nach einem einstellbaren Intervall (Standard sind 15 Minuten) Inaktivität, so dass bei einem möglichen Verlust des Handheld PC ein Finder zunächst die Bildschirmsperre überwinden muss. Diese kann nur, konfigurations- und kundenspezifisch, durch einen PIN-Abfrage oder RFID-Karte überwunden werden. Fehlversuche führen zum Löschen der vorhandenen Protokolle. Darüber hinaus kann auf Kundenwunsch ebenfalls eine Remotelock - and - wipe Möglichkeit einkonfiguriert werden. Grundsätzlich ist aber davon auszugehen, dass ein möglicher Finder eines Gerätes weder Zugang zu sensiblen Daten noch zu gerätespezifischen Informationen erhalten kann.

2.3.   Übergabe im Krankenhaus

Für die Übergabe der Daten in die Klinik stehen drei Varianten zur Verfügung. Die Klinik kann dabei die für sie geeignetste Variante wählen. Angestrebt wird grundsätzlich der papierlose Weg.

2.3.1.  Drucken

Im Krankenhaus wird das erfasste Notfallprotokoll entweder auf dem mitgeführten mobilen Drucker oder auf einem Krankenhausdrucker ausgedruckt und vom Rettungsdienstpersonal unterschrieben.

2.3.2.  NIDAarrivalboard / elektronische Protokollübergabe

Auf dem NIDAgateway werden Postfächer für jede Klinik zur Verfügung gestellt. Das in der Klinik installierte NIDAarrivalboard ist ein Derivat des NIDAclients und folgt denselben Kommunikations- und Verschlüsselungsstandards. Der Client zum Abrufen des Protokolls NIDAprotokoll verhält sich identisch.

Über die zentrale Administration kann der Klinik eine Station bzw. ein Postfach freigeschaltet werden. Die Voranmeldedatensätze werden der Klinik auf dem NIDAarrivalboard drei Stunden angezeigt. Mittels des Protokollclients NIDAprotokoll ist es der Klinik möglich, das Protokoll als PDF herunterzuladen und weiterzuverarbeiten. Das Protokoll steht der Klinik 24 Stunden zum Download zur Verfügung. Details zu der verwendeten Verschlüsselung sind unter 6. Technische Verfahren beschrieben.

2.3.3.  Klinik Server

Der Klinikserver entspricht technisch dem NIDAserver und nutz die gleichen Kommunikationsstrukturen.

2.3.4.  Faxen

Zusätzlich zu den oben aufgeführten Möglichkeiten der Übergabe von Daten an die Klinik kann das Protokoll bereits im Vorfeld via Telefax an die Klinik gesendet werden. Hierfür verschickt NIDAmobile im proprietären verschlüsseltem Protokoll das Notfallprotokoll mit der angegebenen Faxnummer an den NIDAgateway. Dieser leitet es an den NIDAserver (proprietäres verschlüsseltes Protokoll) weiter. Auf dem NIDAserver wird nun aus dem pdf-Dokument (Notfallprotokoll) und der Faxnummer eine Email generiert welche der ekom SMTP-Server annimmt und an die mitgesendete Faxnummer übermittelt.

2.4.   Datenübertragung nach Einsatzende

Die Datenübertragung erfolgt über Mobilfunknetzwerke. Es kommt dabei ein vom Provider zur Verfügung gestelltes VPN zum Einsatz. Das VPN endet im Rechenzentrum. Dieses VPN bietet keine Sicherheit gegenüber dem Provider, da es durch diesen bereitgestellt wird. Der Sicherheitsgewinn ist, das es nicht möglich ist andere Zieladressen als das Rechenzentrum aufzurufen.

Als Protokoll selbst wird eine SSL Verbindung bzw. https Requests verwendet.

Die zu übertragenden Daten (Dateien) selbst sind wie in 2.2 beschrieben ebenfalls verschlüsselt.

In Summe ist die Datenübertragung somit mindestens doppelt verschlüsselt. Die Dateien selbst und die SSL Verbindung. Das VPN des Providers gilt bei der Verschlüsselung nur eingeschränkt.

Als Fallbacklösung bei schlechtem Empfang werden die Daten auf der Rettungswache via Dockingstation per LAN übertragen. Je nach Durchführenden wird hier ebenfalls ein VPN verwendet. Hierbei handelt es sich um ein Software VPN von der Wache bis zum Rechenzentrum. Sonst bleibt bei der Datenübertragung die zweifache Verschlüsselung.

Nach erfolgreicher Übertragung an den Server werden die Daten auf den mobilen Endgeräten automatisch ohne Benutzereingriff gelöscht.

2.5.   Statistik und Nachbearbeitung

Die zur Qualitätssicherung notwendigen Statistiken und das Anzeigen von Notfallprotokollen werden durch einen Client realisiert. Voraussetzung für die Kommunikation zwischen Client und Server ist eine TCP/IP Verbindung. Es besteht die Möglichkeit die Clients in einem VPN Netzwerk zu betreiben. Die Kommunikation wird in jedem Fall über eine TLS-Verbindung verschlüsselt. Die Authentifizierung der Benutzer erfolgt durch Eingabe von Benutzername und Passwort.

2.6.     Passwortvergabe

Zum erstmaligen Anmelden eines Benutzers am Client wird ein Transportpasswort verwendet. Dieses muss bei der ersten Anmeldung geändert werden. Die Passwortvergabe wird mit regulären Ausdrücken geprüft. Das Passwort muss mehr als 8 Stellen beinhalten. Mindestens ein Sonderzeichen sowie einen Groß- und einen Kleinbuchstaben muss enthalten sein. Gleiche Zeichen dürfen nicht mehrfach folgen.

Das Passwort läuft nach einer zentral administrierbaren Zeitspanne ab. Derzeit sind 90 Tage eingestellt.

Fehleingaben werden geloggt und nach 5 Fehlversuchen wird das Konto gesperrt.

Benutzer die sich 180 Tage lang nicht angemeldet haben, werden gesperrt.

2.7.   Rechte

In jedem Rettungsdienstbereich gibt es unterschiedliche Funktionen und die entsprechenden Schreib- und Leserechte. Diese Zugriffsrechte stellt der Datenbankserver sicher, der alle mobil eingegebenen Protokolldaten in einer Datenbank speichert. Er besteht aus einem Systemprozess und einer Datenbank. Der Systemprozess erlaubt den kontrollierten Zugriff auf die Datenbank durch Clients oder mobile Geräte.

Schutzmechanismen im Systemdienst überprüfen jede Anfrage an die Datenbank (lesend oder schreibend) auf Zulässigkeit, gebunden an die Rechte des Anfragestellers. Direkte Anfragen an die Datenbank unter Umgehung des Systemdienstes finden nicht statt.

2.7.1.  Rettungsdienstpersonal

Das Rettungsdienstpersonal kann die Notfallprotokolle der eigenen Einsätze einsehen. Mit Ausnahme weniger rettungstechnischer Daten und einem persönlichen Bemerkungsfeld hat der Benutzer nur Leserecht. Die medizinische Dokumentation ist nach dem Abschluss nicht mehr veränderbar.

2.7.2.  Wachleiter

Wachleiter haben die Aufgabe qualitätssichernde Maßnahmen zu ergreifen und können daher die Notfallprotokolle der Rettungswachen ihrer jeweiligen Zuständigkeit einsehen. Die Patientendaten sind dabei nicht einsehbar. Die Patientendaten dürfen dabei nur nach Eingabe einer Begründung eingesehen werden. Hierbei erstrecken sich die qualitätssichernden Maßnahmen nur auf die Einsichtnahme in Rettungsdienstprotokoll, d.h. getätigte, unveränderbare Dokumentation, welche zur Überprüfung der Eingabequalität und sich über die Vollständigkeit der Eingaben erstreckt. Eine Veränderung der Daten ist aber ausgeschlossen. Diese Qualitätssicherungsmaßnahmen dienen zur Ermittlung des Aus-, Fort- und Weiterbildungsbedarfs für das Rettungsfachpersonal.

2.7.3.  Leiter Rettungsdienst

Der Leiter Rettungsdienst ist der Abteilungsleiter Rettungsdienst einer Organisation. Er darf nur die Notfallprotokolle der eigenen Organisation einsehen. Die Patientendaten dürfen dabei nur nach Eingabe einer Begründung eingesehen werden.

Zusätzlich hat er das Recht Stammdaten zu pflegen, Benutzer seiner Organisation zu administrieren sowie Auswertungen durchzuführen.

Auswertungen werden hierbei anhand von pseudonymisierten, teilweise sogar anonymisierte Daten getätigt. Hierfür wird aus der Originaldatenbank ein Datenbankauszug für die Auswertungsmöglichkeiten erstellt. Auf Grundlage dieser Daten können unterschiedliche Auswertungen erfolgen, z.B. rettungstechnische Informationen über die Anzahl der Einsätze, Ausrückzeiten von Rettungsmitteln, prozentuale Verteilung von Einsätzen in Relation zur Tageszeit.

2.7.4.  Ärztlicher Leiter Rettungsdienst

Mit der Aufgabe der Qualitätssicherung im Rettungsdienstbereich beauftragt kann der ÄLRD sämtliche Notfallprotokolle seines Zuständigkeitsbereiches einsehen. In den meisten Fällen entspricht dies einem Landkreis.

Bestandteil seiner Aufgaben ist auch der Abgleich mit den im Krankenhaus entstandenen Daten um die Versorgung des Patienten ganzheitlich beurteilen zu können. Der Abgleich mit den Daten im Krankenhaus geschieht manuell durch Vergleich des Patientennamens / Geburtsdatums.

Die Patientendaten dürfen dabei nur nach Eingabe einer Begründung eingesehen werden. Sonst stehen nur medizinische und statistische Daten zur Verfügung.

Weitere Auswertungsmöglichkeiten stehen dem ÄLRD analog dem Leiter Rettungsdienst (vgl. 2.7.4) zur Verfügung. Für den Bereich der medizinischen Qualitätssicherung stehen dem ÄLRD ausschließlich anonymisierte Daten zur Verfügung. Diese Auswertungen beziehen sich z. B. auf die Anzahl bestimmter Krankheitsbilder (Diagnosen), getätigter Maßnahmen (Anzahl von Venenpunktionen und Intubationen), Patientenalter usw..

2.7.5.  Administration

Der Administration angehörende Personen sollen Benutzer hinzufügen und löschen können. Dies als eigenes Recht bzw. Rolle zu definieren ergibt sich aus der Tatsache, dass mehrere Organisationen beteiligt sein können. Bei den Rettungsdienstmitarbeitern gibt es zwangsläufig Veränderungen im Personalbestand, die am besten von der jeweiligen Administration gepflegt werden können. Des Weiteren besteht die Notwendigkeit, dass jede Organisation nur ihr eigenes Personal pflegen und einsehen kann. Änderungen an den Personallisten wie hinzufügen oder Löschen eines Mitarbeiters werden in einer Log-Tabelle protokolliert.

2.7.6.  Rechte- und Rollenmatrix

Die Rechte- und Rollenmatrix entnehmen Sie bitte dem entsprechendem Datenschutzkonzept, das Sie von uns erhalten haben.

2.8  Datenexport

Auf Wunsch der Leistungserbringer können die Daten in einem standardisierten und dokumentierten Datenformat selbigen zur Verfügung gestellt werden.

3.  Datensicherheit

Die Datensicherheit wird durch die gängigen Maßnahmen, u.a. Backups, Handshake-Verfahren und Verschlüsselungstechnologien, sichergestellt:

• Bei der Übertragung der Daten von der Medizintechnik werden die von den Herstellern der Defibrillatoren bereitgestellten Protokolle angesteuert. Nach Übertragung der Daten wird die Korrektheit der übertragenen Daten (Checksum-Test) überprüft, bevor sie weiterverarbeitet werden. Die Übertragung erfolgt in der Regel via Bluetooth®. Die hierfür notwendigen PINs zur Authentifizierung sind in der Konfiguration bzw. den Stammdaten der Pads hinterlegt.
• Bei der Übertragung der Daten vom medDV.pad auf den NIDAserver kommt die bereits beschriebene zweifache Verschlüsselung zum Tragen. Die Datenpakete werden bei Empfang auf Korrektheit (Checksum-Test) geprüft, bevor eine Quittierung des erfolgreichen Empfangs erfolgt.
• Die Darstellung der Daten im NIDAclient erfolgt über einen Zugriff auf die Datenbank des NIDAservers. Dabei wird ein Datenbankmanagementsystem (z.B. mySQL) verwendet, das eine Überprüfung des korrekten Ein- und Auslesens der Daten sicherstellt.
• Eine externe Manipulierung der Daten ist durch die durchgängige verschlüsselte Datenübertragung auszuschließen. Das Monitoring der Server und die Handshake-Verfahren dienen zur zeitnahen Erkennung von Manipulationen.
• Die Datenhaltung erfolgt in getrennten Tabellen. Dabei sind vor allem Freitextfelder, Patientendaten, Protokolle und statistische Daten in unterschiedlichen Tabellen gespeichert.

4.   Systemvoraussetzungen

Der Betreiber des Datenbankservers stellt sicher, dass kein unbefugter Zugriff auf die Hardware möglich ist. Hierzu sind geeignete Maßnahmen wie zum Beispiel Zutrittskontrollen vorzusehen. Jedes Softwarekonzept findet seine Grenzen bei direktem Zugriff und Manipulation der Hardware.

4.1.   Wartung

Wartungsaufgaben teilen sich in Wartung der Plattform durch den Betreiber und Softwarepflege per Fernwartung durch den Hersteller. Dabei werden Zugriffe und Veränderungen nach Maßgabe der Sicherheitsrichtlinien des Betreibers durchgeführt.

5.    Risikobetrachtung

5.1.   Risiko aktuell bearbeitete / angezeigte Einsätze

Befindet sich das Gerät im eingeschalteten und dokumentationsbereiten Zustand, sind die Daten des aktuellen Patienten einsehbar. Sind bei einem Einsatz mehrere Patienten beteiligt oder aber werden mehrere Einsätze hintereinander gefahren ohne dass eine Datenübertragung stattgefunden hat, können mehrere Protokolle einsehbar sein.

In der Regel ist die Zahl der Protokolle gleich eins und sollte die Zahl fünf nicht übersteigen. Um auch hier so wenig Daten wie möglich anzuzeigen, werden Einsätze auch mobil abgeschlossen. Bei dieser Aktion wird das Protokoll aus der Anzeige entfernt, nach beschriebenem Verfahren verschlüsselt abgelegt und steht anschließend dem Versand an den Server zur Verfügung.

5.2.   Risiko keine Passworteingabe

Aufgrund der Praktikabilität und Forderungen der möglichst zeitnahen Dokumentation soll der Benutzer nicht durch Passworteingaben in seiner vordringlichen Aufgabe, sprich der Notfallversorgung, behindert werden. Zudem wäre es nach einer Sperrung notwendig, dass beide Personen der Besatzung des Rettungsmittels Ihr jeweiliges Passwort eingeben.

Es wird daher auf eine Passworteingabe verzichtet. Stattdessen gibt es einen Sperrbildschirm, der manuell oder nach einem einstellbarem Intervall (Standard sind 15min) nicht Bedienung eingeblendet wird. Dieser Sperrbildschirm ist nur mit einer mindestens vierstelligen PIN wieder freizuschalten. Die PIN wird vom Kunden festgelegt und ist auf allen Geräten einheitlich hinterlegt. Nach einer einstellbaren Zahl von Fehlversuchen wird das Tablet gelöscht.

Auf dem Pad selbst ist in der Regel nur der aktuell laufende Einsatz einzusehen. Abgeschlossene Einsätze werden aus dem GUI entfernt, übertragene Einsätze sofort gelöscht. In Ausnahmefällen bei Folgeeinsätzen oder Einsätzen mit mehreren Patienten können auch entsprechend mehrere Protokolle auf dem Pad geführt werden. Durch die mobile Übertragung ist die Verweildauer der Daten auf dem Pad auf ein Minimum reduziert (siehe 5.1.1).

Sämtliche Einsätze und Wiederherstellungspunkte werden auf dem mobilen Gerät mit dem AES- -Algorithmus und einer Schlüssellänge von mindestens 256 Bit verschlüsselt gespeichert. Der Schlüssel ist dabei in die Applikation selbst eingebettet.

Nach dem Übertragen auf den Server werden diese Daten gelöscht.

5.3.   Risiko Veränderungen / Manipulation des Protokolls

An einigen Stellen muss ein Abbild des Zustands des Protokolls festgehalten werden. Diese sind im Einzelnen

• Übergabe im Krankenhaus
• Abschluss des Einsatzes

Bei der Übergabe des Patienten in der Klinik wird das  Protokoll ausgedruckt oder elektronisch übertragen. Ab diesem Zeitpunkt werden alle Veränderungen (löschen, korrigieren, erstellen) der Dokumentation registriert und gespeichert. Diese Einträge sind im Nachhinein über den Client einsehbar.

Beim Abschluss wird zudem ein Notfallprotokoll im PDF-Format erstellt. Auf Basis dieser Datei wird ein Hashwert generiert und gespeichert. Die Speicherung erfolgt auf dem NIDAserver. Veränderungen am Protokoll sind somit nachweisbar.

5.4.   Risiko Datenübertragung von NIDAmobile zu
NIDAmobile

Wie im Ablauf der Dokumentation beschrieben ist es erforderlich Daten von NIDAmobile zu NIDAmobile zu übertragen. Aufgrund der Praktikabilität soll die Datenübertragung kabellos stattfinden. Als Technologie kommt Bluetooth® zum Einsatz.

Um dem Risiko unbefugten Zugriffs auf das Protokoll via Bluetooth® entgegenzuwirken, wird eine Datenübertragung vom empfangenen Gerät angefordert. Bei dem sendenden Gerät muss der Benutzer manuell der Übertragung des Protokolls zustimmen (siehe 2.2).

5.5.   Authentifizierung am Server

Der Server horcht auf zwei Ports auf Anfragen bzw. Daten von den mobilen Endgeräten und Clients. Der Zugriff fremder Handheld PCs und die Übertragung bzw. Manipulation wird durch die Installation von Zertifikaten auf den Clients und auf den mobilen Geräten verhindert. Es können sich daher nur Endgeräte mit gültigem Zertifikat anmelden. Bei der Anmeldung der mobilen Geräte am Server wird zusätzlich die hardwaremäßig integrierte und nur über eine System API zu lesende Seriennummer des Gerätes zur Authentifizierung genutzt.

5.6.   Bluetooth^®

Einige der Daten werden per Bluetooth^® übertragen. Hierzu zählt beispielsweise die Übertragung der Daten zum Drucker, Pad zu Pad, Pad von und zu Medizintechnik.

Grundsätzlich findet bei allen Übertragungen ein Pairing mit einer mindestens 4 stelligen PIN statt. Bei den meisten Medizintechnikherstellern kann die Anzahl der Stellen der PIN nicht beeinflusst werden. Bei manchen nicht einmal die PIN selbst.

Im schlechtesten Fall wird daher ein Pairing mit einer vierstelligen, für alle Geräte einheitlichen PIN durchgeführt. Die PIN muss jedoch nicht vom Benutzer eingeben werden und ist diesem auch nicht bekannt. Vielmehr ist die PIN in einer Konfiguration abgelegt.

Im besten Fall der Medizintechnik Anbindung wird die Bluetooth Adresse und die PIN in einem geschützten Bereich einer Mifare RFID Karte abgelegt. Dort wird sie vom Pad ausgelesen und mit diesen Informationen die Verbindung zur Medizintechnik aufgebaut.

Für die Anbindung und den Datenaustausch zwischen Pad und der Medizintechnik gilt jedoch, dass nur proprietäre Daten ausgetauscht werden. Hierzu zählen hauptsächlich Vitalparameter, Ereignisse und EKG Daten im Rohformat.

Bei der Übertragung der Daten zu einem Drucker werden die Daten in einem Druckformat wie PCL5 oder ESC-Sequenzen übertragen.

Bei der Datenübertragung von Pad zu Pad werden die Daten verschlüsselt übertragen.

Mit Ausnahme eines Serial Port Profiles sind keine Bluetoothdienste aktiv. Das SPP wird zum einen bei der Datenübertragung von Pad zu Pad und zum anderen bei der Datenübertragung von manchen medizintechnischen Geräten genutzt.

5.7.   PIN Eingabe nach Sperrung

Die einheitliche PIN, die nach einer Sperrung eines Gerätes eingegeben werden muss, kann in regelmäßigen Abständen geändert werden. Die Änderung dieser PIN erfolgt zentral auf dem NIDAserver und verteilt sich entsprechend auf die mobilen Geräte. In welchen Abständen die PIN geändert wird und wie die jeweils gültige PIN an die Mitarbeiter des Rettungsdienstes kommuniziert wird ist organisatorisch zu regeln.

Das Pad kann nach einstellbarer Anzahl von Falscheingaben der PIN die auf dem Pad vorhandenen Daten löschen.

5.8.   AES Schlüssel in Applikation gespeichert

Der 256 Bit AES Schlüssel zum lokalem verschlüsseln und entschlüsseln der Daten auf den mobilen Systemen ist in der Applikation eingebettet. Das hat den Nachteil, dass dieser Schlüssel für alle Kunden der medDV GmbH gleich ist. Alternative Speicherplätze stellen entweder ein erhöhtes Risiko dar oder sind im praktischen zu umständlich. Das Rettungsdienstpersonal muss in seiner oft zeitkritischen Arbeit so wenig wie möglich durch zusätzliche Sicherheitsmechanismen behindert werden. Daher erscheint es am Sinnvollsten, unter Abwägung des Risikos und des Nutzens, den Schlüssel innerhalb der Applikation (Source Code) zu lassen.

5.9.   Verschlüsselung der Datenbank

Als Datenbank kommt mySQL zum Einsatz. Die Daten werden von mySQL verschlüsselt auf der Festplatte abgelegt. Um einen Zugang zu den Daten zu erhalten ist die Eingabe eines Benutzernamens und Passwortes notwendig. Zusätzlich werden von der Datenbank keinerlei Verbindungen die nicht von demselben Server stammen akzeptiert.

Siehe hierzu auch http://www.mysql.de/why-mysql/topreasons.html Punkt 6 „Zuverlässiger Datenschutz“

6. Technische Verfahren

6.1.   Datenübertragung / Kommunikation

Beim Einsatz von NIDA werden identifizierende und medizinische Daten übertragen. Bei der Dokumentation werden Daten von „fremden“ Datenträgern gesammelt. Dazu gehören Gesundheitskarte und Krankenversichertenkarte, Medizinische Geräte wie EKG Monitore und Beatmung und ggf. weitere Datenlieferanten. Im Verlauf können Daten an Kliniken zur Vorankündigung übertragen werden. Nach dem Ereignis werden die Daten für die Abrechnung und für das Qualitätsmanagement verwendet.

Im Folgenden werden die einzelnen Übertragungswege beschrieben:

6.1.1.  Einsatzleitsystem ↔ NIDAserver

Der Einsatzleitrechner und der NIDAserver befinden sich entweder im selben Netzwerk und kommunizieren via LAN oder befinden sich in einem VPN Netzwerk.

Die Kommunikation selbst läuft über eine SOAP Schnittstelle mit definierten Funktionen über eine SSL Verbindung. Diese sind aus Sicht des Einsatzleitrechners der Insert (Alarmierung) und das Update (Aktualisierung der Daten). Aus Sicht des NIDAservers gibt es das Update. Hierbei werden die Daten des Einsatzleitrechners nach Abschluss der Dokumentation ergänzt bzw. überschrieben. Ein SELECT ist implementiert um einerseits mit NIDA erfasste Daten einem Einsatz im Leitrechner zuzuordnen als auch einen vollständigen Datensatz, nämlich um die Daten des ELR ergänzt, im NIDAserver zusammenzufassen und darzustellen.

6.1.2.  NIDAserver ↔ NIDA

Die mobilen Datenerfassungsgeräte sind permanent mit dem NIDAserver via Mobilfunk auf einem bestimmten Port verbunden. Bei Verbindungsabbrüchen wird diese automatisch wieder hergestellt. Die Authentifizierung und die Identifizierung der Geräte läuft via Login mit dem eingestellten Funkrufnamen. Die Funkrufnamen sind im Server bekannt- fremde Funkrufnamen können sich nicht anmelden. Die GPRS Verbindung ist via VPN abgesichert. Hier werden durch die Provider entsprechende Produkte bereitgestellt. Zum Beispiel Corporate Data Access der Firma Vodafone.

6.1.3.  NIDA ↔ Medizintechnik

Die Daten der Medizintechnik werden via Bluetooth ausgetauscht. Ein Pairing wird dabei bei jedem Verbindungsaufbau durchgeführt. Die PINs sind auf MiFare RFID Chips in einem geschützten Speicherbereich hinterlegt. Bei Medizinprodukteherstellern, die als Server fungieren wird die Bluetooth Adresse und die PIN auf einer MiFARE 1K Karte abgelegt. Diese RFID Karte ist mit dem Medizinprodukt fest verbunden. Über den RFID Leser des Pads wird der Gerätetyp, die Bluetooth Adresse und die PIN ausgelesen und dann automatisch die Verbindung entsprechend aufgebaut. Praktisch bedeutet dies, dass das Pad an das Medizinprodukt gehalten wird. Der Abstand beträgt dabei nur wenige Zentimeter. Bei diesem Prozess geht es weniger um einen Gewinn an Datensicherheit sondern vielmehr um einen großen Gewinn an Prozesssicherheit. Es ist praktisch ausgeschlossen, dass aus Versehen das falsche Medizinprodukt ausgewählt wird.

Steht die Verbindung, werden Vitalparameter, Ruhe-EKGs und Patientendaten entsprechend dem Inhalt der Krankenversichertenkarte ausgetauscht. Letztere Daten werden AES (Rijndael) verschlüsselt übertragen.

Bei Medizinprodukteherstellern, bei denen der Verbindungsaufbau vom Gerät zu NIDA erfolgt, ist die PIN in den Stammdaten bzw. Konfiguration von NIDA hinterlegt

6.1.4.  NIDA ← Krankenversichertenkarte / eGK

Die Daten der Karten werden mittels integriertem Kartenleser ausgelesen.

6.1.5.  NIDA → NIDAserver

Die AES (Rijndael) verschlüsselten Datenpakete werden durch eine Secure Socket Layer (SSL) Verbindung an den Server übertragen (doppelte Verschlüsselung). Der Verbindungsaufbau erfolgt dabei auf einem frei definierbaren Port. Physikalisch kommen Mobilfunkverbindungen sowie DSL-Verbindungen zum Einsatz. 

6.1.6.  NIDAserver ↔ NIDAclient

Auf einem definierten Port wird eine SSL Verbindung mit dem Server aufgebaut. Die Authentifizierung des Personals erfolgt via Benutzername und Passwort[1]. Die Authentifizierung am NIDAtracker (Client) in der Klinik ist in drei Varianten möglich:

• Eingabe Benutzername / Passwort
• Auswahl Benutzername (über drop down)
• Autologin

Die Entscheidung hinsichtlich des login-Prozesses obliegt der Klinik. Die Passwörter liegen in gehashter[2] Form auf dem Server bereit.  Hierüber ergeben sich auch die Rechte und Rollen eines jeden Benutzers (siehe 2.5 und 2.6).

6.1.7.  NIDA ↔ Fakturierung

Bei der Übertragung der Daten an die Fakturierung des Leistungserbringers fungiert der NIDAserver als Gateway. Die Übertragung gliedert sich dabei in zwei Abschnitte. Im ersten Abschnitt werden die Daten analog der Übertragung NIDA <-> NIDAserver an den NIDAserver (Gateway) übermittelt. Im zweiten Abschnitt wird ein zweiter https Request an die jeweilige Fakturierung gesendet. Die Antwort dieses Requests wird wieder zu NIDA gesendet. Inhaltlich werden nur abrechnungsrelevante Daten gemäß §302 SGB V übertragen.

6.1.8.  NIDA ↔ Klinik

Die Datenübertragung in die Klinik erfolgt nach einem doppelten Umschlag Prinzip. In den Postparametern des Webrequests ist die Zielklinik enthalten. Dieser Teil kann und muss vom NIDAgateway ausgepackt werden, damit das Ziel der Daten bekannt ist. Durch das providerseitige VPN, können die mobilen Geräte nur Daten an den NIDAserver bzw. NIDAgateway senden. Die Übermittlung der Daten in die Klink erfolgt dann vom NIDAgateway aus. Die eigentlichen Nutzdaten für die Klinik sind für den Gateway nicht entschlüsselbar als Datei im Request enthalten. Diese Datei wird mit dem öffentlichen Schlüssel des Zielkrankenhauses auf dem Pad verschlüsselt. Die öffentlichen Schlüssel aller angebundenen Kliniken sind lokal auf den mobilen Geräten verfügbar.

6.2.   Datenhaltung

Die Datenhaltung erfolgt in getrennten Tabellen. Dabei sind vor allem Freitextfelder, Patientendaten, Protokolle und statistische Daten in unterschiedlichen Tabellen gespeichert. Medizinische Daten liegen somit bereits auf Datenbankebene in komplett anonymisierter Form vor.

6.3.   NIDA

Sämtliche Daten in NIDA befinden sich entweder im RAM oder werden AES verschlüsselt auf einem integriertem, fest verbautem Flashspeicher abgelegt. Ist die Dokumentation eines Einsatzes abgeschlossen wird dieser durch den Abschluss aus dem GUI entfernt und zum Versenden auf dem Flashspeicher abgelegt.

6.4.   NIDAserver

Die Datenhaltung im NIDAserver erfolgt in einer SQL Datenbank. Der physikalische Ort ist im Rechenzentrum angesiedelt. Der Server wird in einem Rechenzentrum auf einer virtuellen Maschine betrieben. Dieser wird täglich komplett gesichert. Die Sicherungen werden 4 Wochen vorgehalten. Auf Softwareebene werden die Daten nicht nur in die Datenbank geschrieben sondern alle empfangenen Pakete in verschlüsselter Form lokal als „Originalpaket“ abgelegt. Diese werden für einen Zeitraum von 3 Monaten aufbewahrt.

[1] Ab Q1 2017 wird bei der Authentifizierung des Benutzers auch der Client als solcher überprüft. Damit ist ein zweiter Faktor der Authentifizierung geschaffen.

[2] Ab Q4 2016 werden die gehashten Passwörter zusätzlich gesalzen