SORMAS-X Datenschutz: einzelne Themen (5)

Der fünfte Teil der Reihe zum Thema SORMAS-X Datenschutz und Sicherheit nimmt heute die Zusammenarbeit mit den Datenschutzaufsichtsbehörden in den Blick.

Holperiger Start

Die Zusammenarbeit zwischen dem Projekt SORMAS@DEMIS und den Datenschutzaufsichtsbehörden zum Thema SORMAS-X gestaltete sich anfangs holperig und wurde aber im Verlauf immer besser. Der mühselige Start war insofern nicht verwunderlich, als Behörden und mittelständische Unternehmen sehr grundsätzlich andere Arbeitsweisen haben. Behörden erwarten einen Sachverhalt, der ihnen vollständig vorgelegt wird, und dann nehmen sie sich Zeit diesen zu prüfen, dann geben sie Rückmeldung und dann kann weiterdiskutiert werden. Auf diese Weise können Wochen, wenn nicht Monate ins Land gehen – Zeit, in denen in Unternehmen die Entwicklung weitergeht. Dies galt umso mehr in einem Projekt, das unter so hohem Zeitdruck arbeitete, wie SORMAS@DEMIS. Nach Wochen diskutierten wir mit den Vertretungen der Behörden immer einen alten Stand.

Paralleles Vorgehen nötig

Es gibt in Digitalisierungsprojekten aber auch keine Alternative zum parallelen Vorgehen. Wartet man mit der Umsetzung bis eine 100%ige Planung steht, bei allen beteiligten Stellen alle Informationen vorliegen und alle eine finale Stellungnahme abgegeben haben, erhält man am Ende des Projekts eine Software, die schon bei der Kiel-Legung der Arche Noah veraltet war (wie mein Kollege einmal sagte). Das heißt nicht, dass ohne Plan und Konzept einfach irgendwas gemacht werden sollte. Es heißt aber, dass auch eine parallele Entwicklung von Anforderungen und deren Umsetzung stattfinden kann und muss. Diesbezüglich müssen nicht nur Datenschutzbehörden umdenken, wenn wir Digitalisierung beschleunigen wollen, meine ich. Wir sahen uns allerdings in dem SORMAS@DEMIS Projekt anfangs beständig dem Vorwurf ausgesetzt, dass die Dokumentation unvollständig sei und man auf diese Weise auf Behördenseite viel Mühe mit der Beurteilung habe. Die Behörden erwarteten einen Sachverhalt, den sie prüfen könnten, wir erwarteten die Begleitung eines Projekts mit einem sehr hohen Arbeitstempo.

Klare Vorgaben vermisst

Davon abgesehen vermissten wir an mehreren Stellen eine gut begründete, klare Vorgabe der Anforderungen, die von der Datenschutzaufsicht als Maßstab für das Urteil „datenschutzkonform“ oder „nicht datenschutzkonform“ zugrunde gelegt wurde. Das Vorgehen der Landesdatenschutzbeauftragten wirkte mitunter wie aus dem Gefühl heraus entschieden, anstatt auf der Grundlage nachvollziehbarer, strukturierter Vorgaben. Die Zusammenarbeit mit den Mitarbeitenden der Landesdatenschutzbeauftragten wurde in dem Augenblick besser, als diese unser Vorgehen der parallelen Entwicklung und Prüfung akzeptierten. Vielleicht hatte die Macht des Faktischen gesiegt, aber jedenfalls riefen wir kleinere Arbeitskreise zu speziellen technischen und rechtlichen Themen ins Leben und fortan gab es einen zielführenden Austausch.

SORMAS-X Datenschutz: Einzelne Themen (4)

Im vierten Teil der Reihe zu SORMAS-X Datenschutzthemen geht es heute um die Schnittstellen. Anhand der Thematik der Anbindung externer Applikationen an SORMAS über eine offene Schnittstelle erörtere ich grundsätzliche Fragen der Organisation eines Digitalisierungsprojekts.

Erlösung durch Technik?

Im Verlauf der Pandemie kamen immer mehr technische Lösungen auf den Markt, die versprachen, uns mit technischen Mitteln aus der Pandemie zu erlösen. In der Regel waren es eher Lösungsversuche als tatsächlich funktionierende und überzeugend ausgearbeitete Lösungen. Die Luca App ist nur das bekannteste Beispiel dafür.

Im SORMAS@DEMIS Projekt standen wir vor dem Problem, dass viele Gesundheitsämter diese Lösungen einsetzen und in SORMAS integrieren wollten. Die Anfragen landeten auf den Schreibtischen des Datenschutzteams mit der Aufforderung, mal schnell zu den Datenschutzthemen Stellung zu nehmen. Mangels einer anderen Möglichkeit sollten alle externen Applikationen über die offene Schnittstelle, die sog. Rest API mit SORMAS verbunden werden.

Das Spiel verderben

Ich habe in diesem Zusammenhang viele gruselige Tatsachen über die Verbindung von Systemen über offene Schnittstellen gelernt. Im Ergebnis waren wir in Bezug auf die Anbindung von externen Applikationen an SORMAS immer, was ich ungerne bin. Spielverderberin aus Sicherheitsgründen. Die bessere Alternative, eine sichere Lösung zu entwickeln, blieb unter den Anforderungen des Projekts auf der Strecke.

Produktentwicklung

Dieses Problem legte den Finger in eine Reihe von grundsätzlichen Schwierigkeiten im Projekt. Vieles davon wäre besser zu lösen gewesen, wenn das SORMAS@DEMIS Projekt nicht länger als ein Forschungs- und Entwicklungsprojekt betrachtet worden wäre, sondern als eine Produktentwicklung. Die Entwicklung des Produktes Software SORMAS mit all seinen Facetten und Möglichkeiten sowie eingebauten Sicherheiten für Datenschutz und Informationssicherheit.

Zunächst ging es ja tatsächlich nur um die Vernetzung der Gesundheitsämter, um deren Ausstattung mit SORMAS-X, und die Schaffung einer Möglichkeit des automatisierten Datenaustausches zwischen den Gesundheitsämtern. Wäre es dabei geblieben, wäre die Frage der datenschutzfreundlichen Softwaregestaltung relativ überschaubar gewesen. Dann hätte man sich ein paar Gedanken machen müssen über die Verbindung der unterschiedlichen SORMAS-Instanzen zum Zwecke des Datenaustausches zwischen Gesundheitsämtern und das wäre dann auch schon fast alles gewesen. Durch die Dynamik der Entwicklung kamen dann aber hinzu: die Anbindung der anderen IfSG Fachanwendungen, die in den Ländern eingesetzt wurden, und auf deren Erhalt die Länder pochten. Zahlreiche Apps, die mit einer Art Heilsversprechen der technischen Lösung der Pandemieprobleme antraten (und politisch entgegen aller Vernunft gepusht wurden). Um nur ein paar zu benennen.

Anforderungen an Digitalisierungsprojekte

Dies hatte zur Folge, dass die zu lösenden Fragestellungen und datenschutzrechtlichen Anforderungen im Verlauf der Arbeiten sehr viel komplexer und sehr viel umfangreicher wurden. Insofern war es in Bezug auf die Schnittstellen auch nicht sehr verwunderlich, dass die Absicherung noch nicht so mitgedacht und umgesetzt war, wie sie es sein müsste. Der Ausgangspunkt des Projektes war ursprünglich ein ganz anderer.

Was wird in so einer Situation gebraucht?

Im ersten Schritt eine klare und zwischen allen Beteiligten abgesprochene Konzeption der verschiedenen Ausbaustufen der Software (hier SORMAS-X, aber auch jeder anderer Anwendung in der Entwicklung). Welche Zwecke soll eine Schnittstelle genau erfüllen? Welche Aufgaben sollen damit erledigt werden und durch wen?

Wenn diese Konzeption steht, kann im zweiten Schritt dazu übergangen werden, die Anforderungen an Datenschutz und Informationssicherheit definieren.

Klar beschriebene Schritte

Die Umsetzung kann und darf dann nur auf der Grundlage der zuvor beschriebenen Schritte eins und zwei erfolgen. Klar ist, dass diese Schritte nicht immer perfekt zu trennen sind. Es muss aber auf jeden Fall gewährleistet sein, dass alle Beteiligten darauf hinwirken, nicht einfach auf Zuruf zu entwickeln und zu programmieren, sondern die Konzeption im Auge zu behalten und gegebenenfalls einzufordern.

Klar zugewiesene Verantwortlichkeit

Klare und transparente Verteilung von Verantwortlichkeiten zwischen den beteiligten Stellen. Festhalten derselben in einer internen Vereinbarung: wer ist für die Generierung von Testdaten zuständig? Wer verantwortet die Migration von Daten? Wer verantwortet die Umsetzung der Anforderungen an ein datenschutzfreundliches Technikdesign? (Um nur ein paar zu nennen).

Die Umsetzung dieser Vorgehensweise würde zu erheblichen Effizienzgewinnen führen, da in einem Projekt mit vielen Beteiligten nicht ständig diskutiert werden müsste wer gerade für Sicherheitsfragen zuständig ist, generell zuständig ist, oder zuständig sein sollte. Abgesehen von den Effizienzgewinnen wäre so auch eine Einhaltung der Vorgaben des Privacy by Design besser möglich. Die Frage, wer am Ende die Verantwortung für die Umsetzung des Privacy by Design und der Anforderungen des Art. 32 DSGVO im Rahmen der Softwareentwicklung hat, soll einem weiteren Artikel vorbehalten sein.

Weitere Artikel zum Datenschutz für die SORMAS-Software finden Sie u.a. hier und hier.

Wir unterstützen Sie gerne bei Digitalisierungsprojekten. Sprechen Sie uns an.

SORMAS-X Datenschutz: Einzelne Themen (3)

Wie in den vorangegangenen Beiträgen bereits erwähnt, besteht die Datenschutz-Dokumentation aus über 50 einzelnen Dokumenten. Nachfolgend stellen wir die Wichtigsten kurz vor. Dies ist die letzte Folge zum Thema Datenfelder und Zwecke. Heute geht es um das Löschkonzept für die SORMAS-X Software.

Löschkonzept

Zu Beginn des SORMAS@DEMIS Projektes konnten Daten aus der Software nur manuell gelöscht werden. Unklar war zunächst auch, ob sie tatsächlich gelöscht wurden, oder ob sie nur aus dem Sichtfeld der Anwenderin in einen verborgenen Teil der Datenbank verschoben wurden. So oder so war klar, dass dies nicht so bleiben konnte. Wir brauchten eine Idee für die Umsetzung des automatisierten Löschens von Daten aus der SORMAS-X Software.

Wir setzen für unsere Auftraggeber schon länger eine Vorlage für ein Löschkonzept ein, die mein technischer Sachverständiger entwickelt hat. Sie basiert auf der Grundlage der DIN 66398 "Leitlinie zur Entwicklung eines Löschkonzepts mit Ableitung von Löschfristen für personenbezogene Daten". Die Vorlage ermöglicht eine Schritt-für-Schritt Erstellung eines Löschkonzepts.

Eine Vorlage für die Gesundheitsämter

Wir passten diese Vorlage an die SORMAS-X Anforderungen an und füllten sie mit Vorschlägen zu Löschfristen. Die Löschfristen sollten, so der Plan, den Gesundheitsämtern als Leitlinie für die Entwicklung und Ergänzung eigener Löschfristen dienen. Die endgültige Festlegung der Löschfristen stand anfangs noch unter dem Vorbehalt der Abstimmung mit den Landesdatenschutzbeauftragten. Die Löschfristen zu definieren war nicht ganz einfach, aber verglichen mit der anschließenden Entwicklung eines Plans für die tatsächliche Umsetzung dieser Anforderungen in der Software war dieser Teil ein kleiner Spaziergang. Die Datenbank-Logik der SORMAS-X Software arbeitet nicht personenzentriert, sondern ereignisbasiert. Würde man für das Löschen bei den Informationen über die Person ansetzen, liefe man Gefahr Informationen entweder zu kurz oder viel zu lange aufzubewahren.

Die Softwareentwickler sahen uns ratlos an, als wir ihnen die datenschutzrechtlichen Anforderungen vorstellten. „Was glaubt ihr, wie das gehen soll? Wie sollen wir das denn machen?“ Ich war versucht zu antworten, dass sie das doch wissen müssten? Seid ihr die Programmierer oder wir? Damit wären wir aber keinen Millimeter weiter gewesen. Entweder, wir würden mit ihnen einen Weg finden, oder wir würden keine Umsetzung unseres Konzepts bekommen.

Vorteil Schwarmintelligenz

An dieser Stelle zeigte sich wieder einmal der Vorteil der „Schwarmintelligenz“, die im SORMAS Datenschutzteam zusammengefunden hatte. Zwei der technischen Sachverständigen aus dem Team überführten in teils langwierigen Verhandlungen mit den Entwicklern unser formal-theoretisches Konzept in die Beschreibung der praktischen Umsetzung. Sie wählten einen innovativen Ansatz. Die Aufbewahrungsfristen sollen nicht „übergreifend“ an den (Personen-) Datensatz gebunden sein, sondern an jedes einzelne Datenfeld.

Feldweises Löschen

Auf diese Weise ist es möglich, dass jeder Datensatz automatisiert feldweise „von hinten nach vorne“ gelöscht werden kann, beginnend mit dem Feld mit der kürzesten Aufbewahrungsfrist. Erst, wenn auch das letzte Feld mit der längsten Aufbewahrungsfrist gelöscht ist, wird der Datensatz einer Person gelöscht. Die Aufbewahrungsfristen werden dementsprechend für jedes einzelne Datenfeld hinterlegt. Auf diese Weise wird jede Information automatisch zu exakt dem Zeitpunkt gelöscht, zu dem die Löschung rechtlich vorgegeben ist. Die Löschfristen werden direkt in der Software hinterlegt. Sie können von den Stellen, die SORMAS-X einsetzen, ergänzt und verändert werden.

Umsetzung folgt

Wie bei anderen Themen auch, verhinderte die Fülle der Aufgaben und die Knappheit der Zeit die tatsächliche Umsetzung des Plans, aber aufgeschoben ist nicht aufgehoben. Netzlink hat es sich zur Aufgabe gemacht, die Implementierung des automatisierten Löschens in der SORMAS-X Software gleich im ersten Quartal 2023 auf den Weg zu bringen.

SORMAS-X Datenschutz: Einzelne Themen (2)

Wie in den vorangegangenen Beiträgen bereits erwähnt, besteht die Datenschutz-Dokumentation aus über 50 einzelnen Dokumenten. Nachfolgend werden die wichtigsten kurz vorgestellt. Nach der Datenschutz-Folgenabschätzung geht es hier um Datenfelder und Zwecke in der SORMAS-X Software.

Datenfelder und Zwecke

Ich erinnere den Anfang und den Grund nicht mehr genau, aber jedenfalls erhielten wir von der Projektleitung eine Excel-Tabelle mit allen Datenfeldern, die in der SORMAS-X Software enthalten waren. Zu diesem Zeitpunkt waren es rund 500 Datenfelder, später wuchs die Zahl auf fast 800.

Fast 800 Datenfelder

Die Tabelle war unübersichtlich und mit Anmerkungen versehen, deren Sinn sich uns in Teilen nicht erschloss. Wir bauten die Tabelle so um, dass wir sie nutzen konnten. Wir fügten Rechtsgrundlagen, Zwecke und später auch Löschfristen ein. Die Idee war, auf diese Weise eine umfassende Übersicht und Überprüfbarkeit der Zulässigkeit der Datenerhebung mittels der SORMAS-X Software zu erhalten.

Ich habe diese Datenfeldertabelle mehr als einmal verflucht. So sehr ich von dem Sinn und Nutzen überzeugt war, so schwierig war die praktische Handhabung.

Dadurch, dass nicht nur das Datenschutzteam damit arbeitete, sondern auch die Projektleitung und die Programmierer Rückmeldung und Informationen einfügen mussten, war die Tabelle bald ein Fall von „viele Köche können schnell den Brei verderben“. Wir hätten sie in eine Datenbank überführen müssen, aber das war aus verschiedenen Gründen nicht möglich. Als weitere Herausforderung erwies sich die Tatsache, dass mitunter nicht sicher war, ob das, was in der Tabelle abgebildet, auch wirklich in der Software vorhanden war. Der Prozess des Hinzufügens und der Herausnahme von Feldern lief ja parallel weiter.

Die Datenfeldertabelle diente als Grundlage für die Diskussion mit den Landesdatenschutzbeauftragten über die Zulässigkeit des Betriebs der Software aus datenschutzrechtlicher Sicht. Und sie diente als interne Kontrolle der Rechtmäßigkeit der Datenverarbeitung (Art. 5 DSGVO).

Rechtsgrundlagen bis zum letzten Halbsatz zitiert

„Wir fügten Rechtsgrundlagen ein“, schreibt sich jetzt im Nachhinein einfach hin, aber es war eine wahre Sisyphusarbeit. Auf Wunsch der Landesdatenschutzbeauftragte zitierten wir nicht nur die Vorschriften des IfSG bis in den letzten Halbsatz, sondern auch die Landesdatenschutzgesetze und die Gesetze über den öffentlichen Gesundheitsdienst (so vorhanden). Rückblickend betrachtet meine ich, dieses Vorgehen war im Prinzip gut, hätte aber besser koordiniert umgesetzt und technisch abgebildet werden müssen.

Es sind noch Fragen offen

Ebenfalls rückblickend stelle ich fest, dass uns einige Fragen der Zulässigkeit der Datenerhebung von der Agenda gefallen sind. So haben wir beispielsweise die Frage der Zulässigkeit des Erfragens von Symptomen von Fallpersonen und Kontaktpersonen über ein sog. online Symptomtagebuch überhaupt nicht thematisiert. (Auch die Aufsichtsbehörden fragten nicht danach). Wie problematisch das sein konnte, zeigte eine Beanstandung des bayerischen Landesdatenschutzbeauftragten gegen Ende des Projekts. Die Einzelheiten werden noch Gegenstand eines weiteren Blogartikels.

Stand jetzt muss auch dieses Dokument grundlegend überarbeitet werden, um für den Datenschutz in der SORMAS-X Software eine belastbare Grundlage zu sein. Dies schon deshalb, weil sich derzeit am Übergang von der Pandemie zur endemischen Phase viele rechtliche Grundlagen erneut verändert werden.

SORMAS-X Datenschutz: Einzelne Themen (1)

Wie in den vorangegangenen Beiträgen bereits erwähnt, besteht die Datenschutz-Dokumentation aus über 50 einzelnen Dokumenten. Nachfolgend werden die wichtigsten kurz vorgestellt.

Datenschutz-Folgenabschätzung (DSFA)

Eigentlich hatten es sich die Gesetzgebenden in Europa gut überlegt.

„Hat eine Form der Verarbeitung … voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen zur Folge, so führt der Verantwortliche vorab eine Abschätzung der Folgen der vorgesehenen Verarbeitungsvorgänge für den Schutz personenbezogener Daten durch“. (Art. 35 Abs. 1 DSGVO).

Das heißt, bevor eine Stelle mit einem möglicherweise riskanten Verfahren hantiert, soll sie die Risiken prüfen und minimieren.

„Der Verantwortliche“ soll, so die Vorschrift weiter, „bei der Durchführung einer Datenschutz-Folgenabschätzung den Rat des Datenschutzbeauftragten einholen“. (Art. 35 Abs. 2 DSGVO).

Die Datenschutzaufsichtsbehörden hatten schon zu einem sehr frühen Zeitpunkt die Erstellung einer solchen Datenschutz-Folgenabschätzung (DSFA) für die SORMAS-X Software gefordert. (Zu Recht. Was sonst, wenn nicht die millionenfache Verarbeitung von Gesundheitsdaten sollte ein risikoreiches Verfahren sein).

Art. 35 DSGVO

Nun waren wir als Datenschutzteam des SORMAS@DEMIS Projektes nicht „der Verantwortliche“ (Art. 4 Nr. 7 DSGVO) für die Software, aber wir waren noch die Fachkundigsten von allen beteiligten Stellen. Allerdings fehlten uns zu diesem frühen Zeitpunkt – Herbst 2020 – grundlegende Informationen, die eine wirklich fundierte Erstellung einer DSFA möglich gemacht hätten. Dies lag wiederum darin begründet, dass die Software in der Anpassung und Weiterentwicklung befindlich war. Wir konnten daher nicht eine DSFA erstellen, die den von Art. 35 DSGVO vorgesehenen Ablauf einhält: eine Vorab-Beschreibung der Funktionalitäten der Software, Beschreibung der Zwecke, Rechtsgrundlagen und technischen und organisatorischen Sicherheitsmaßnahmen, Beschreibung der Risiken, Bewertung der Risiken.

Somit entstand eine DSFA, die eher ein fundierter Entwurf einer DSFA war, der im Verlauf des weiteren Verfahrens zu ergänzen war.

Von Seiten der Landesdatenschutzbeauftragten brachte uns das viel Kritik ein, aber was sollten wir tun. Immerhin hatten wir mit dem Entwurf der DSFA eine geschlossene Beschreibung aller möglichen Risiken, an der wir uns im Verlauf bei der weiteren Definition der Sicherheitsanforderungen orientieren konnten.

Da einige Vorhaben der Weiterentwicklung der Software innerhalb der Projektlaufzeit nicht zu Ende gebracht werden konnten, blieb der Entwurf der DSFA ein Entwurf.

Stand jetzt, Anfang 2023, nehmen wir die Arbeiten für die Erstellung einer vollständigen DSFA für die SORMAS-X Software wieder auf. Sie soll dann auch den Gesundheitsämtern, die SORMAS-X weiterhin einsetzen, zur Verfügung gestellt werden.

Im nächsten Artikel geht es weiter mit einzelnen Themen und hier geht es zum Anfang der Serie.

SORMAS-X Datenschutz: Die Dokumentation

Die SORMAS-X Datenschutz-Dokumentation besteht aus über 50 Dokumenten, die alle Datenschutz/Informationssicherheit Themen abdecken, die aus rechtlicher und technischer Sicht zu regeln waren. Diese Themen reichten von einer Datenschutz-Folgenabschätzung, einem umfassenden Sicherheitskonzept über eine Tabelle mit allen Datenfeldern, die in der Software vorhanden sind, bis zu einer Darstellung des Datenmodells und der Anforderungen an die sichere Gestaltung von Schnittstellen.

Unser Ziel war es dabei von Anfang an, die Dokumentation auch für die Gesundheitsämter nutzbar zu machen, die die SORMAS-X Software einsetzen.

Viele der Dokumente sind daher so gestaltet, dass sie von den Gesundheitsämtern als Vorlage genutzt und mit eigenen Inhalten ergänzt werden können, so zum Beispiel die Datenschutz-Folgenabschätzung und das Verzeichnis Verarbeitungstätigkeiten. Dies war insbesondere vor dem Hintergrund bestehender länderspezifischer Vorgaben in den einzelnen Bundesländern erforderlich.

Privacy by Design umsetzen

Ein weiteres Ziel, das wir im Verlauf der Arbeiten entwickelt haben, war die möglichst weitgehende Berücksichtigung und Umsetzung des Grundsatzes von Privacy by Design in der Software.

Aus unserer Sicht hat sich nicht nur dafür, aber generell ein dreistufiges Vorgehen als das Beste erwiesen. Pro Thema haben wir zunächst ein formales Konzept erstellt, das die formalen datenschutzrechtlichen Anforderungen (beispielsweise an das automatisierte Löschen von personenbezogenen Daten) beschreibt. Daneben haben wir dann ein technisches Umsetzungskonzept entwickelt, das die technischen Möglichkeiten der Umsetzung beschreibt, wie sie im formalen Konzept definiert sind. Um im obigen Beispiel des automatisierten Löschens von personenbezogenen Daten zu bleiben heißt das: im technischen Umsetzungskonzept ist beschrieben, wie das automatisierte Löschen von Daten aus der Software konzipiert und ermöglicht werden soll und kann. Als dritter Schritt war geplant, die Beschreibung der technischen Umsetzung zu dokumentieren, um den Nachweis führen zu können, dass die in den Konzepten niedergelegten Anforderungen eingehalten sind. Dieser dritte Schritt ist in Bezug auf einige Themen der SORMAS Software bis Projektende noch offengeblieben, was den begrenzten zeitlichen, personellen und auch finanziellen Ressourcen des Projektes geschuldet ist.

Im Ergebnis ist SORMAS-X am Ende des Projekts die Software, die von allen IfSG-Fachanwendungen am sorgfältigsten und gründlichsten im Hinblick auf Datenschutzfragen geprüft und dokumentiert ist.

Sie kann damit Vorbild für alle anderen IfSG-Fachanwendungen sein. Dies gilt unabhängig von der Tatsache, dass es weiterhin Bedarf für die Weiterentwicklung gibt. Der ist identifiziert, benannt und die nötigen Arbeiten für die Umsetzung von weiteren Privacy by Design Merkmalen durch Netzlink haben bereits begonnen.

Ausblick

In den nächsten Artikeln werden einzelne Dokumente zu Datenschutz- und Sicherheitsthemen, die im Verlauf des Projektes besonders wichtig waren, etwas weiter im Detail erläutert.

Den ersten Artikel aus der Reihe "SORMAS-X Datenschutz" finden Sie hier.

Sie brauchen Unterstützung bei der Umsetzung von Datenschutz im Gesundheitswesen? Sprechen Sie uns gerne an und wir finden in einem kostenlosen Erstgespräch heraus, was wir für Sie tun können.

SORMAS@DEMIS. Datenschutz

SORMAS@DEMIS. Das Projekt

Die letzten zweieinhalb Jahre meiner Beratungstätigkeit waren von meiner Arbeit im SORMAS@DEMIS Projekt geprägt. Ich habe das Datenschutzteam geleitet, das im Rahmen des Projektes bei meinem langjährigen Kooperationspartner, der Firma Netzlink, angesiedelt war. Zusammen mit dem Team habe ich die Dokumentation zu Datenschutz und Informationssicherheit für die SORMAS-X Software entwickelt. Das Datenschutzteam SORMAS@DEMIS bestand aus insgesamt acht erfahrenen Sachverständigen mit juristischem und technischem Wissen.

Das Projekt endete mit dem Jahr 2022 und ich habe mich entschlossen, hier in einer Reihe von mehreren Artikeln von dieser Arbeit zu berichten. Das Projekt ist beendet, aber die Arbeiten zur Verbesserung des Datenschutzes und der Sicherheit an der SORMAS-X Software gehen weiter. Netzlink betreibt auch in Zukunft die Software als Dienstleister für zahlreiche Gesundheitsämter bundesweit und europaweit, und das Datenschutzteam führt seine Arbeit unter veränderten Vorzeichen fort.

Zu Beginn der COVID-19 Pandemie Anfang des Jahres 2020 wurde sehr schnell klar, dass Deutschland über keine digitale Ausstattung verfügte, die die Gesundheitsämter bei der Kontrolle der Infektionen hätte unterstützen können. Eine Zuordnung von infizierten Personen zu Kontaktpersonen war nicht möglich und damit auch nicht die Auswertung von Infektionsketten. Auch konnten mit den bestehenden Instrumenten die Infektionszahlen nur mit tagelanger Verzögerung an das Robert-Koch-Institut gemeldet werden, um nur zwei Beispiele zu nennen.

SORMAS@DEMIS: Der Beginn

Vor diesem Hintergrund setzte das Bundesgesundheitsministerium ein Forschungsprojekt mit dem Ziel auf, die SORMAS-Software für alle Gesundheitsämter in Deutschland anwendbar zu machen. SORMAS ist die Abkürzung für

„Surveillance Outbreak Response Management and Analysis System“

und der Name beschreibt die Funktion. Das „X“ steht für Exchange und bezeichnet die Möglichkeit des automatisierten Datenaustausches zwischen den Stellen, die die Software einsetzen. Die Software ist ursprünglich ein Open Source Projekt des Helmholtz Instituts in Braunschweig. Sie war bereits seit vielen Jahren in Westafrika als Teil der Bekämpfung von Epidemien erfolgreich im Einsatz und sollte nunmehr für Deutschland weiterentwickelt und an die hiesigen Prozesse des öffentlichen Gesundheitsdienstes angepasst werden. Dabei stand zunächst die Verbesserung des Managements von Kontaktpersonen im Vordergrund, sowie die Möglichkeit des automatisierten Datenaustausches zwischen den einzelnen Gesundheitsämtern. Im weiteren Verlauf des Projektes ging die Entwicklung jedoch immer weiter in Richtung einer IfSG-Fachanwendung, die aber auf die für die Covid-Pandemie erforderlichen Abläufe beschränkt blieb.

SORMAS-X Datenschutz: Die Herausforderung

Als ich im Herbst 2020 die Leitung des Datenschutzteams übernahm, befand sich die Software einerseits in der Weiterentwicklung und Anpassung an deutsche Erfordernisse, gleichzeitig aber war sie in zahlreichen Gesundheitsämtern bundesweit schon im laufenden Betrieb eingesetzt. Wir hatten daher keine Zeit, erst Konzepte zu erstellen, die im zweiten Schritt umgesetzt würden.

Die Definition der Anforderungen, die Ausarbeitung der Konzepte, die Umsetzung im laufenden Betrieb, die Änderungen aufgrund von Datenschutz- oder Sicherheitsanforderungen … alles das erfolgte in weiten Teilen parallel.

Es bestand eine Datenschutz-Dokumentation, die aber aus Sicht des Dienstleisters Netzlink im Rahmen der Auftragsverarbeitung für die Gesundheitsämter geschrieben war. Es galt, diese in eine Dokumentation zu erweitern, die die Software als Ganzes und alle beteiligten Stellen in den Blick nahm. Konkrete Vorgaben von Seiten der Urheber des Projekts gab es nicht, außer, dass das ganze Vorhaben „datenschutzkonform“ sein sollte.

Wir trafen auf massiven zeitlichen Druck, der sich Anfang 2021 noch verstärkte, als die Konferenz der Kanzlerin und der Ministerpräsidentinnen und -präsidenten der Länder beschloss, dass SORMAS-X bis Ende Februar 2021 in allen Gesundheitsämtern bundesweit laufen sollte. Die Informationsflüsse zwischen uns Datenschutzverantwortlichen und den übrigen Projektbeteiligten mussten innerhalb des Projekts erst organisiert werden. Hinzu kam die weitverbreitete „ja, aber“ Haltung gegenüber den Anforderungen an Datenschutz und Informationssicherheit.

Ja, Datenschutz ist wichtig. Aber müsst ihr uns wirklich damit Arbeit machen?

Das gegenseitige Verständnis und die Informationsflüsse wurden im weiteren Verlauf des Projekts immer besser, der zeitliche Druck blieb. Parallel dazu wurden wir immer mehr zu einer Art allgemeinem Datenschutzkummerkasten. Wenn bei einer der projektbeteiligten Stellen etwas schief lief oder schief zu laufen drohte, wurde nicht der/die Datenschutzbeauftragte der jeweiligen Stelle gefragt, sondern wir. Ebenso landeten alle Anfragen aus Gesundheitsämtern zu Datenschutzthemen bei uns.

Alles in allem kam die Arbeit in diesem Projekt meiner Liebe für die Ordnung komplexer Probleme entgegen, und auch wenn ich manchmal der Verzweiflung nahe war, konnten wir viel gestalten. Wie bereits erwähnt, nutzen wir heute die Erfahrungen aus dem Projekt weiter. Zusammen mit Netzlink in Braunschweig und Vossel Solutions in Soest unterstützen wir nicht nur die Weiterentwicklung von SORMAS, sondern bieten auch speziell auf den öffentlichen Gesundheitsdienst und den privaten Gesundheitssektor zugeschnittene Beratungsangebote an.

Fortsetzung folg: Im nächsten Artikel beschreibe ich die Einzelheiten der Datenschutz-Dokumentation für SORMAS-X.