Datenschutzkonzept

<< Klicken Sie, um das Inhaltsverzeichnis anzuzeigen >>

Navigation:  »Kein übergeordnetes Thema«

Datenschutzkonzept

Das EMIL Datenschutzkonzept umfasst die Bereiche

•Schutz personenbezogener Daten

•Datenintegrität

•Datensicherheit

Die folgenden Maßnahmen beschreiben eine Client-Server-Installation mit einem geschützt aufgestellten Server. Diese Installationsweise wird für den vollen Datenschutz immer empfohlen. Das System kann in Ausnahmefällen und zu Testzwecken auch als Einzelplatz- oder Peer-to-Peer-Installation betrieben werden; dann greifen nicht alle genannten Maßnahmen.

Schutz personenbezogener Daten

•Alle EMIL-Daten liegen nur auf dem EMIL-Server in der Einrichtung. Es werden keine Daten außer Haus gespeichert.

•Der Server stellt keine Dienste im Internet bereit und benötigt selbst keine Internetverbindung. Für den Fragebogenversand an Patienten, das Remote-Ausfüllen mit RITA und die Patientenapp baut er eine ausgehende Verbindung auf, und zwar ausschließlich zum Gateway EGON. In der Firewall der Einrichtung wird dafür kein Port nach innen geöffnet (siehe Sicherheitskonzept - RITA/App).

•Online-Aktualisierungen lädt ein Client herunter und überträgt sie an den Server. Nur wenn die optionale Systemeinstellung „Automatische Aktualisierung“ eingeschaltet ist, lädt der Server Aktualisierungen selbst per HTTPS von ITC; dafür braucht er dann einen Internetzugang.

•Sind SMS-Terminerinnerungen eingerichtet, sendet der Server die Nachrichten selbst per HTTPS an den gewählten SMS-Anbieter; dafür braucht er eine ausgehende Verbindung zu diesem Anbieter.

•Weitere Downloads laufen nicht über EGON, sondern direkt vom Arbeitsplatz per HTTPS von ITC (files.itc-ms.de): das Fernservice-Modul.

•Der Server wird in der Einrichtung selbst gehostet und ist dort durch technische und organisatorische Maßnahmen des Betreibers abzusichern (nicht Gegenstand dieses Konzepts).

•Auf EMIL-Clients werden keine personenbezogenen Daten abgelegt, nur lokale Arbeitsplatzeinstellungen.

•Die Weitergabe von Daten an Datenstellen (z. B. im Rahmen von DMP, Studien oder Versorgungsverträgen) erfolgt ausschließlich von Clients aus und mit Public-Key-Verschlüsselung. Dabei kommen nur Standardmethoden wie GPG bzw. das Kryptomodul der Kassenärztlichen Bundesvereinigung zum Einsatz.

•Die Datenübertragung zwischen Clients und Server ist HTTPS-verschlüsselt und läuft über einen frei wählbaren TCP-Port. Clients benötigen keinen weiteren Zugriff auf den Server (keine Fileshares).

•Zugriffe über den FHIR-Server sind ebenfalls HTTPS-verschlüsselt und nur für Clients möglich, die der EMIL-Administrator angelegt und freigegeben hat. Der Administrator kann diese Freigabe jederzeit wieder entziehen. Wird der FHIR-Server über einen Reverse Proxy nach außen freigegeben, ist das eine eingehende Verbindung über den Proxy der Einrichtung, die der Betreiber selbst einrichtet und verantwortet (siehe Anmelde-Drosselung und Reverse Proxy).

•Dokumente, Scans und Bilder (mit EMMA) werden ebenfalls über HTTPS vom Server geladen und im Programm nur im Hauptspeicher verarbeitet. So bleiben keine Spuren personenbezogener Daten in Form temporärer Dateien zurück.

Datenintegrität und Datensicherheit

•Berechnete Werte (Scores) werden bei jeder Änderung einer Eingangsgröße automatisch neu berechnet, egal ob die Daten manuell oder per Schnittstelle erfasst wurden.

•Alle Daten außer Dokumenten und Bildern liegen in einer Firebird-SQL-Datenbank. Sie läuft als eigener Dienst unabhängig vom Applikationsserver, bleibt also bei dessen Neustarts (z. B. bei Aktualisierungen) in Betrieb, und ist durch generierte Primärschlüssel, Fremdschlüssel und weitere Constraints gegen Inkonsistenzen abgesichert. Weder der Applikationsserver noch die Clients haben im Betrieb Dateizugriff auf die Datenbank.

•Zu nahezu allen Tabellen schreiben Datenbanktrigger einen Audit-Trail mit Zeitstempel, Herkunft (Schnittstelle, Client …), vorherigem Wert, Benutzer, Arbeitsplatzname und IP-Adresse. Jede Änderung ist so auf Feldebene nachvollziehbar. Patientendaten werden nicht gelöscht, sondern archiviert.

•Für die Sicherung ist der Betreiber verantwortlich. Die Datenbank lässt sich einfach in vorhandene Sicherungskonzepte einbeziehen, z. B. Imaging oder Sicherung über gbak im laufenden Betrieb (siehe Datensicherung).

Details zum Datenbankaufbau finden Sie unter Architektur und Datenbank.