Besonders sensible Daten brauchen ein belastbares Konzept

Medizinische Informationen können Rückschlüsse auf Gesundheit, Identität und persönliche Lebensumstände ermöglichen. Deshalb reicht es nicht, Daten nur technisch zu schützen. Ein Verantwortlicher muss auch verstehen, welche Informationen für den jeweiligen Zweck wirklich benötigt werden und wer sie zu welchem Zeitpunkt sehen darf.

Im Labor treffen mehrere Systeme aufeinander: Arbeitsplatzrechner, Analysegerät, Software, lokale Ablage, Netzwerk, Berichte und gegebenenfalls externe Verarbeitung. Jede Übergabe ist ein eigener Verarbeitungsschritt und muss in die Schutzbetrachtung einbezogen werden.

Grundsatz

Je weniger identifizierende Daten ein Analysesystem benötigt, desto kleiner wird die Angriffs- und Fehlerfläche. Datenschutz beginnt daher bei der Frage, welche Information weggelassen werden kann.

Datensparsamkeit und Pseudonymisierung

Für eine mikroskopische Bildanalyse ist der Name einer Patientin oder eines Patienten in vielen Fällen technisch nicht erforderlich. Eine interne ID kann den Laborprozess unterstützen, ohne dass das Analysesystem eine direkte Identität kennen muss.

Im dokumentierten tensorscope Konzept wurde die vom Nutzer hinterlegte Patienten-ID nicht an den Analyseserver weitergeleitet. Bei Support-Screenshots sollte sie zudem verdeckt werden. Das folgt zwei wichtigen Prinzipien:

  • Zweckbindung: Nur Daten verarbeiten, die für die konkrete Analyse oder den konkreten Supportfall erforderlich sind.
  • Trennung: Identitätsdaten und Analysedaten möglichst in unterschiedlichen Verantwortungsbereichen halten.
  • Pseudonymisierung: Vorgänge über interne Kennungen statt Klarnamen zuordnen.
  • Privacy by Default: Die datensparsame Einstellung ist voreingestellt und verlangt keinen zusätzlichen Klick.

Zugriffe nach Aufgabe vergeben

Nicht jede Person im Unternehmen oder Labor benötigt Zugriff auf alle Daten. Ein rollenbasiertes Berechtigungskonzept verbindet Zugriffe mit Funktionen: Laborpersonal bearbeitet Analysen, Support sieht nur freigegebene technische Informationen, Administration verwaltet Konten und die Entwicklung arbeitet möglichst mit anonymisierten Testdaten.

Dazu gehören starke Authentisierung, Bildschirmsperren, aktuelle Systeme und nachvollziehbare Protokolle. Berechtigungen sollten regelmäßig geprüft und entfernt werden, sobald eine Aufgabe oder Beschäftigung endet.

Ein gutes Berechtigungskonzept beantwortet nicht nur, wer Zugriff hat, sondern auch warum, wie lange und mit welcher Nachvollziehbarkeit.

Support ist Teil des Datenschutzdesigns

Supportfälle sind oft der Moment, in dem sensible Informationen unbeabsichtigt sichtbar werden. Bildschirmaufnahmen, Logdateien und Beispieldaten können Kontext liefern, aber zugleich Kennungen oder Analyseinformationen enthalten.

Eine sichere Supportfunktion sollte daher vor dem Versand anzeigen, welche Daten übertragen werden, identifizierende Inhalte standardmäßig ausblenden und eine bewusste Freigabe verlangen. Für jeden Supportfall gelten außerdem klare Löschfristen und ein begrenzter Empfängerkreis.

Den gesamten Datenlebenszyklus betrachten

Schutzmaßnahmen müssen von der Erhebung bis zur Löschung ineinandergreifen. Ein praktikabler Prüfpfad umfasst:

  1. Rechtsgrundlage und Zweck jeder Verarbeitung dokumentieren.
  2. Datenfelder und Übertragungswege vollständig erfassen.
  3. Speicherorte, Aufbewahrungsdauer und Löschmechanismen definieren.
  4. Auftragsverarbeiter und technische Unterauftragnehmer transparent prüfen.
  5. Vorfälle, Auskunftsersuchen und Korrekturen organisatorisch vorbereiten.
  6. Schutzmaßnahmen regelmäßig testen und an Systemänderungen anpassen.

Das Ergebnis ist kein einmaliges Dokument, sondern ein betreuter Prozess. Änderungen an Software, Infrastruktur oder Laborablauf sollten immer auch eine erneute Datenschutzprüfung auslösen.