Integration

Kreise Eschwege und Fulda haben sich für ein Produkt der Firma unisoft mit Namen "Äskulab 21" entschieden. Dagegen wird beim Landkreis Kassel das Verfahren ISGA der Firma Computer Zentrum Binder & Karl GmbH eingesetzt.

14.5.2

Aufbau der Programme

Ich habe im Rahmen einer Prüfserie die Gesundheitsämter in Fulda, Eschwege, Wetzlar, Kassel und Dietzenbach aufgesucht, um mir einen Überblick über den derzeitigen Stand der Automatisierung zu verschaffen und bereits im Vorfeld Hinweise auf datenschutzkonforme Lösungen im Zusammenhang mit der Verarbeitung personenbezogener medizinischer Daten zu geben.

Alle Programme sind in ihrer Grundstruktur einander ähnlich, da sie in Form einzelner Module aufgebaut sind. So gibt es für die unterschiedlichen Aufgabenstellungen eines Gesundheitsamtes spezifische Module bzw. Arbeitsbereiche, welche die erforderlichen Verfahrensschritte, die gesetzliche Vorgaben zum Inhalt haben, abdecken. Beispielsweise werden die Verfahrensabläufe für die Meldungen nach den §§ 6 ff. Infektionsschutzgesetz an das Robert-Koch-Institut in Berlin von den Programmen so dargestellt, dass die zuständigen Sachbearbeiter die nach dem Gesetz meldepflichtigen Krankheiten innerhalb des Moduls abschließend bearbeiten können. Eine ähnliche Bearbeitung findet von der Ablauforganisation her in den anderen Fachbereichen des Gesundheitsamtes statt, sofern dort über die entsprechenden fachbezogenen Module verfügt wird.

14.5.3

Schwerpunkte der Prüfung bei den Gesundheitsämtern Drei wesentliche datenschutzrechtliche Aspekte sind im Rahmen meiner Prüfungen der Programme OCTOWARE, ISGA, Äskulab 21 und Mikropro health mit den Amts- und Verwaltungsleitern und Sachbearbeitern diskutiert worden:

­ Einrichtung der Zentraldatei

­ Ausgestaltung der Zugriffsrechte und Administration

­ Einbindung der Sozialpsychiatrischen Dienste 14.5.3.1

Zentraldatei

Bei der Zentraldatei handelt es sich im Einzelnen um einen Personenstammdatensatz, der dann angelegt wird, wenn ein Betroffener Kontakt mit dem Gesundheitsamt aufnimmt. Eine Ausnahme von dieser Verfahrensweise muss es allerdings beim sozialpsychiatrischen Dienst geben. In der Zentraldatei dürfen keine inhaltlichen Hinweise auf bestimmte Erkrankungen oder persönliche Lebensumstände eines Betroffenen enthalten sein. Die Aufgabe der Datei als Suchinstrumentarium ist dann erfüllt, wenn sich hieraus ausschließlich formale Informationen ergeben, ob z. B. eine Person bereits mit dem Gesundheitsamt zu tun hatte. Andererseits darf es keine inhaltlichen Hinweise auf z. B. bestimmte Krankheiten oder Beratungshinweise im Zusammenhang mit einer psychischen Erkrankung geben.

Bereits bei der in vielen Gesundheitsämtern manuell geführten Personenkartei gab es immer wieder Streitfragen im Hinblick auf deren Inhalt und den Zugriff durch Mitarbeiterinnen und Mitarbeiter. Vor allem kam es immer wieder vor, dass auf den Karteikarten Informationen zu einzelnen Besuchen bzw. Vorladungen vermerkt waren. Diese Diskussionen können mit der Einführung eines einheitlichen Personenstammdatensatzes ad acta gelegt werden. Jedes der Softwareprogramme sieht in seiner Grundstruktur das Anlegen eines Personenstammdatensatzes vor. Neben den Merkmalen Name, Vorname, Anschrift, Geburtsdatum und Staatsangehörigkeit ist es sinnvoll, den Fachbereich/Abteilung mit aufzuführen, in welcher der Betroffene ggf. bereits war. Damit wird es möglich, externe Anfragen gezielt an die Organisationseinheit weiterzuleiten, die mit dem Betroffenen befasst war. Dies schließt selbstverständlich jedoch zunächst aus, dass über die Fachabteilung hinaus Informationen ausgetauscht bzw. weitergeleitet werden. Vorstellbar ist im Rahmen der internen Organisation des Gesundheitsamtes eine Verknüpfung z. B. des amtsärztlichen und jugendärztlichen Dienstes mittels der Zentraldatei. Allerdings nicht dergestalt, dass extern anfragenden Personen oder Institutionen Inhaltsdaten zur Verfügung gestellt werden sollten.

Vielmehr könnte über ein in der Zentralkartei gesetztes Merkmal die für eine bestimmte Person zuständige Sachbearbeiterin oder der Sachbearbeiter ermittelt und Anfrager auf diese Weise gezielt an die richtige Stelle geführt werden, um die klärungsbedürftigen Fragen zu stellen. Über allem steht dabei, keine Befunde, Gutachten oder sonstigen medizinischen Daten allgemein durch das System für das Personal des Gesundheitsamtes zugänglich zu machen.

Alle medizinischen Daten unterliegen nämlich der ärztlichen Schweigepflicht i. S. d. § 203 Strafgesetzbuch. Eine informationelle Einheit im Gesundheitsamt kann deshalb ebenso wenig wie bei den Krankenhäusern angenommen werden.

14.5.3.2

Technisches Umfeld, Zugriffsberechtigungen und Administration

Bei der vergleichenden Betrachtung der verschiedenen zum Einsatz kommenden Verfahren spielt die unterschiedliche Größe der einzelnen Gesundheitsämter sowie deren technische und organisatorische Einbettung in die jeweilige Verwaltung eine nicht unerhebliche Rolle. Die Ausgangssituation eines räumlich und technisch entkoppelten Gesundheitsamts ist eben nicht eins zu eins mit der eines vollständig in die Kreisverwaltung eingebetteten Gesundheitsamts zu vergleichen. Dabei kommt es im Wesentlichen darauf an, dass sich insgesamt ein angemessenes Datenschutzniveau ergibt. So müssen z. B. Schwächen der einzelnen Anwendung ggf. durch zusätzliche Maßnahmen auf der Betriebssystemebene kompensiert werden und bei einer Integration in das Netz der Kreisverwaltung steigen dementsprechend die Anforderungen an die Sicherheit dieses Netzes.

Insbesondere die folgenden Punkte wurden bei allen geprüften Verwaltungen bzw. Verfahren vergleichend betrachtet:

- Art der Datenbank

Alle eingesetzten Anwendungen lassen sich hinsichtlich der verwendeten Datenbank in zwei Gruppen unterscheiden.

Entweder wird die Datenbank, z. B. auf Access basierend, auf einem Dateiserver abgelegt oder das Verfahren setzt den Einsatz eines passenden Datenbankservers voraus. Insbesondere im ersten Fall ergeben sich für die Vertraulichkeit und Integrität der Daten höhere Risiken, denn alle Anwender des Verfahrens brauchen umfassenden Schreib-/LeseZugriff auf die Server-Verzeichnisse, auf denen die Datenbank abgelegt ist. Wenn dann ein Zugriff auf der Betriebssystemebene nicht durch geeignete Maßnahmen verhindert wird, kann die Datenbank unbefugt kopiert oder aber ganz gelöscht werden.

Ein Teil der geprüften Stellen hat dieses Risiko durch entsprechende Einschränkungen der Benutzeroberflächen aufgefangen. Ein Zugriff auf die Datenbank außerhalb der Anwendung war damit wirkungsvoll ausgeschlossen. In den anderen Fällen können die Daten ­ eine ordnungsgemäße Administration vorausgesetzt ­ nur mit der Anwendung auf dem Datenbankserver gelesen werden. Hier greifen je nach Verfahren noch zusätzliche Verschlüsselungsmechanismen, die nicht nur die Daten, sondern auch die Passwörter der Anwender schützen.

- Zugang zum Verfahren

In allen Fällen hatten nur berechtigte Anwender die Möglichkeit sich an den Verfahren anzumelden. Anderen Benutzern war der Zugang durch eine ordnungsgemäße Administration unmöglich. Die stichprobenhafte Überprüfung der dazu gehörenden Dokumentationen gab nur im Einzelfall Anlass zur Kritik. Die Einrichtung oder Änderung des Zugangs zum Verfahren wurde im Allgemeinen umfassend und in einem der Sensitivität der Daten entsprechenden Umfang schriftlich dokumentiert.

Da es aber grundsätzlich berechtigten Nutzern in den meisten Fällen möglich ist, unabhängig von der Anmeldung am Betriebssystem, eine Anmeldung mit beliebiger Benutzerkennung am Verfahren durchzuführen, besteht hier die Gefahr, dass ein Anwender die Rolle im Verfahren wechselt bzw. Zugang zu anderen Modulen erhält. Der Schutz der Daten vor unbefugten Zugriffen ist somit von der Qualität der Verfahrensanmeldung bzw. des Passwortes abhängig.

Daher sollten die Verfahren dazu in der Lage sein, eine Passwortlänge von mindestens acht Zeichen zu erzwingen und die Lebensdauer der Passworte ist auf längstens 60 Tage zu begrenzen, wie es auch bei Betriebssystemen üblich ist.

Wenn diese Forderungen nicht durch die Verfahren sichergestellt werden können, ist die Umsetzung durch entsprechende Dienstanweisungen an Anwender und Administratoren zu erwirken.

- Initialpasswort

Wird ein Benutzer in einem der Verfahren erstmals eingerichtet oder hat ein Benutzter sein zuletzt benutztes Passwort vergessen, ist durch den Anwendungsadministrator ein Initialpasswort einzurichten. Dabei sollte im Idealfall das Passwort frei zu wählen sein, und bei der ersten Anmeldung wird der Anwender gezwungen dieses zu wechseln, bevor er mit dem Programm arbeiten kann.

Leider zeigen die Verfahren in diesem Zusammenhang ihre Schwächen. Programme die den sofortigen Passwortwechsel nicht erzwingen, erlauben es dem Anwender das Initialpasswort bis zum Fristablauf zu verwenden. Selbst wenn die Benutzer durch eine entsprechende Dienstanweisung zum sofortigen Wechsel des Passwortes aufgefordert werden, ist der Anwendungsadministrator in diesen Fällen gehalten, das Initialpasswort besonders aufwändig zu gestalten.

Noch kritischer sind Verfahren, in denen das Initialpasswort fest vorgegeben ist, denn es ist allen Anwendern, gleich welche Rolle sie im Verfahren einnehmen, bekannt. Hier kommt der Forderung zum sofortigen Ändern des Passworts durch den Anwender besondere Bedeutung zu. Zur Durchsetzung dieser Forderung könnte ein Quittungsvermerk eingeführt werden, in dem der Anwender mit Datum und Uhrzeit die Änderung des Initialpasswortes bestätigt. Um ein verbleibendes Restrisiko technisch zu minimieren, sollte das Standardpasswort eine eng gefasste Gültigkeitsdauer z. B. 48 Stunden haben.

- Risiken durch die Einbindung in E-Mail-Systeme bzw. Internet-Anbindung

Alle eingesetzten Systeme wurden, soweit eine Anbindung einzelner Arbeitsplätze an das Internet eingerichtet war, durch Firewalls abgesichert. Dabei reichte das Spektrum der eingesetzten Komponenten vom einfachen ISDN-Router mit Firewall-Funktionalität bis zum ausfallsicheren Firewall-Cluster mit integrierter Lastverteilung. Die eingesetzten Systeme entsprachen im Wesentlichen dem Schutzbedarf des jeweils nachfolgenden Netzes. Die Dienststellen wurden darauf hingewiesen, dass bestimmte Risiken nur durch sehr restriktive Browsereinstellungen, die den Zugriff auf aktive Elemente auf Internetseiten allerdings stark einschränken, ausgeschlossen werden (s. auch www.bsi-bund.de). Bei den E-Mail-Anbindungen wurden im Idealfall durch gestaffelte Virenscanner, die sowohl zentral auf dem Server als auch lokal bei Empfänger greifen, die notwendigen Schutzmechanismen eingerichtet.

- Protokollierung und Revisionssicherheit

Die in den Anwendungen programmierten Protokollierungsoptionen werden, soweit vorhanden, wegen der entstehenden Speichervolumen nicht voll ausgeschöpft. Funktionen, die den letzten ändernden Zugriff zu einem Datensatz anzeigen, sind weitgehend in die Programme implementiert. Fehler bei der Administration der Module oder Fehlfunktionen des Programms werden u. U. so für berechtigte Anwender offensichtlich. Eine echte Revisionsfähigkeit, die die Historie aller Zugriffe leicht auswertbar, z. B. für einen behördlichen Datenschutzbeauftragten, ermöglicht, ist bei keinem Programm gegeben. Bei den datenbankbasierten Systemen entstehen allerdings die typischen protokollähnlichen

Datensätze, die für das Rekonstruieren der Datenbank nach einer Störung benötigt werden. Diese können im Einzelfall

- bei besonderen Vorkommnissen - von Spezialisten durchsucht werden.

- Fazit aus technischer Sicht

Wie bei vielen Anwendungsprogrammen, die in den hessischen Kommunalverwaltungen eingesetzt werden, gibt es mehr oder weniger ausgeprägte Probleme, weil die datenschutzrechtlichen Erfordernisse zunächst nicht im Vordergrund der Entwicklung stehen. Das führt angesichts des höheren Schutzbedarfs der hier verarbeiteten Daten dazu, dass Mängel mit zum Teil erheblichem zusätzlichem Aufwand auf der Ebene der Betriebssysteme und durch aufwändige organisatorische Regelungen kompensiert werden müssen.

14.5.3.3

Einbindung des sozialpsychiatrischen Dienstes

Der Sozialpsychiatrische Dienst (SpD) ist in vielen Gesundheitsämtern eine eigenständige Organisationseinheit. Rechtsgrundlagen für die Tätigkeit des Dienstes ist u. a. das Hessische Freiheits-Entziehungsgesetz. So werden beim SpD Stellungnahmen zu Unterbringungen gefertigt, die vom Ordnungsamt in Auftrag gegeben werden. Auch die Suchtberatung und Prävention sowie Beratungs- und Betreuungsplanung sind Aufgaben, die dem SpD obliegen.

Zu unterscheiden ist daher die freiwillige Kontaktaufnahme des Betroffenen mit dem SpD im Gesundheitsamt, die in der Regel mit einer Beratungsleistung verbunden ist. Andererseits wird der SpD auf Anfrage bzw. im Auftrag "von Amts wegen" tätig, um über Betroffene z. B. Gutachten zu fertigen, die ihre Wirkung durch konkretes Verwaltungshandeln der anfordernden Stelle erzielen.

Im Zusammenhang mit einer freiwilligen Beratung ist ohnehin die Frage zu stellen, ob deren Inhalte bzw. Ergebnisse im dafür vorgesehenen Modul hinterlegt werden müssen. Bei einer derartigen Konstellation mangelt es bereits an der notwendigen Erforderlichkeit i. S. v. § 11 Abs. 1 HDSG. Deshalb wäre es allenfalls akzeptabel, Inhaltsdaten ohne Personenbezug in das System einzustellen.

Auch wenn der SpD beauftragt wird und in diesem Zusammenhang Vorgänge zu einem Betroffenen entstehen, ist zweifelhaft, ob diese Personen im allgemeinen Personenstammdatensatz einer Zentraldatei abgespeichert werden können. Jeder „allgemein zugängliche" Hinweis würde nämlich implizieren, dass der Betroffene im Zusammenhang mit einer Sucht- oder Drogenabhängigkeit bzw. auf Grund psychischer Probleme beim SpD bekannt wurde. Die Folge wäre im Zusammenhang mit einer amtsärztlichen Untersuchung, dass diese Organisationseinheit gezielt beim SpD nach aktenmäßigen Erkenntnissen nachsuchen würde. Um eine solche „Regelanfrage" von vorneherein auszuschließen, darf die Information darüber, dass es im SpD Vorgänge gibt, nicht allgemein zugänglich sein. Zudem sollte vor jeder Datenübermittlung aus diesem Fachbereich eine Einwilligungserklärung des Betroffenen vorliegen.

Die organisatorische Konsequenz dessen, dass der SpD besonders sensitive Gesundheitsdaten verwaltet, muss demnach sein, dessen Einbindung in das automatisierte Verfahren auszuschließen. Bereits der Hinweis auf existente Akten dort, die allgemein zugänglich sind, könnte zu einer Stigmatisierung der Betroffenen und als weitere Folge dazu führen, dass man im konkreten Einzelfall in anderen Fachbereichen des Gesundheitsamtes nicht mehr vorurteilsfrei begutachtet bzw. handelt.

Das Problembewusstsein hierzu war in allen Häusern, die ich aufgesucht habe, vorhanden. Es hat auch ohne meine Mitwirkung dazu geführt, dass der SpD in der Regel nicht in den allgemeinen organisatorischen Betrieb eines Gesundheitsamtes eingebunden ist. Vielmehr wird, unabhängig von Fragen der Dienst- und Fachaufsicht, entsprechend der Sensibilität der Daten eine Abschottung der Datenbestände angestrebt.

14.5.4

Weiteres Verfahren

Ich habe die bislang aufgesuchten Gesundheitsämter angeschrieben und ihnen meine Vorstellungen erläutert, wie der Datensatz der Zentraldatei inhaltlich gestaltet sein könnte. Dabei kommt es darauf an, unabhängig von den einzelnen Anwendungen zu einer einheitlichen und klaren Definition dessen zu kommen, was als erforderlich anzusehen ist. Die Vorgabe eines von seinem Umfang her abschließenden Datensatzes, der Inhalt der Zentraldatei ist, ist datenschutzrechtlich erforderlich und für die Gleichbehandlung aller öffentlichen Stellen im Gesundheitsdienst notwendig. Nach der Auswertung der Rückmeldungen könnte es dann zu einem standardisierten Datensatz der Zentraldatei kommen, der für alle Gesundheitsämter gilt.

Was den SpD anbelangt, so werde ich - soweit das von den Gesundheitsämtern bislang nicht ohnehin bereits praktiziert worden ist - darauf hinwirken, dass eine vollständige Abschottung der Datenbestände auch im Hinblick auf Informationen in der Zentraldatei gewährleistet ist. Eine Datenübermittlung vom SpD zu einer anderen Stelle innerhalb des Gesundheitsamtes bedürfte ohnehin der schriftlichen Einwilligung des Betroffenen.