Glossar

Fachbegriffe des Interviewleitfadens „Etablierung und Betrieb von Secure Processing Environments (SPE/TRE)". Im Fragebogen sind diese Begriffe hervorgehoben und zeigen die Erläuterung als Tooltip.

Five-Safes-Operationalisierung: Überführung des Five-Safes-Modells – Safe Projects, Safe People, Safe Data, Safe Settings und Safe Outputs – in konkrete Prozesse und Kontrollen. Im Interview geht es darum, wie diese Prinzipien praktisch umgesetzt und nachgewiesen werden, etwa durch Projektprüfung, Nutzerakkreditierung, geschützte Arbeitsumgebungen und Output-Kontrollen.
DSFA: Die Datenschutz-Folgenabschätzung bewertet gemäß Art. 35 DSGVO vorab die Risiken einer Verarbeitung mit voraussichtlich hohem Risiko und legt geeignete Schutzmaßnahmen fest. Im Interview ist insbesondere relevant, ob eine übergreifende DSFA für die SPE/TRE oder einzelne projektbezogene DSFAs verwendet werden und wie diese aktualisiert werden.
Referenz: Europäische Kommission – Datenschutz-Folgenabschätzung
Verfahrensverzeichnis: Gemeint ist in der Regel das Verzeichnis von Verarbeitungstätigkeiten nach Art. 30 DSGVO, das unter anderem Zweck, Datenkategorien, Empfänger, Löschfristen und Sicherheitsmaßnahmen dokumentiert. Im Interview soll geklärt werden, wie der SPE-/TRE-Betrieb und die einzelnen Forschungsprojekte darin abgebildet und voneinander abgegrenzt werden.
DAA-Vorlagen: DAA steht hier üblicherweise für Data Access Agreement, also eine standardisierte Vereinbarung über den Datenzugang. Sie regelt beispielsweise Nutzungszweck, zugelassene Personen und Daten, Sicherheitsauflagen, erlaubte Outputs, Publikationspflichten, Löschung und Sanktionen; im Interview interessieren vor allem Standardisierungsgrad und praktische Wiederverwendbarkeit.
Public Register-URLs: Das sind Webadressen öffentlich zugänglicher Projekt- oder Datennutzungsregister, in denen etwa bewilligte Forschungsvorhaben, Ziele, verwendete Daten, Status und Ergebnisse veröffentlicht werden. Im Interview dienen sie als konkrete Belege dafür, wie der Betreiber Transparenz über Datenzugänge und deren gesellschaftlichen Nutzen herstellt.
Referenz: HDR UK – Data Use Registers
Five Safes RO-Crate: Ein maschinenlesbares Metadatenpaket, das einen Forschungsworkflow in einer TRE zusammen mit Projektinformationen, Freigaben, Ausführung und Output-Prüfung dokumentiert. Im Interview geht es darum, ob damit Five-Safes-Prüfungen nachvollziehbar, automatisierbar und zwischen mehreren TREs austauschbar gemacht werden.
Referenz: RO-Crate – Five Safes Crate
SATRE: Die Standard Architecture for Trusted Research Environments ist eine offene, gemeinschaftlich entwickelte Referenzarchitektur für Aufbau, Betrieb und Bewertung von TREs. Sie beschreibt Anforderungen unter anderem für Governance, IT, Datenmanagement und unterstützende Betriebsprozesse; im Interview ist wichtig, ob SATRE als Architektur-Checkliste oder Reifegradmaßstab verwendet wurde.
Referenz: SATRE-Dokumentation
ISO/IEC 27001: Ein internationaler Standard mit Anforderungen an ein Informationssicherheitsmanagementsystem, das Sicherheitsrisiken systematisch identifiziert, behandelt und kontinuierlich überwacht. Im Interview sollte unterschieden werden, ob der Betreiber lediglich daran orientiert arbeitet oder tatsächlich einen definierten Geltungsbereich der SPE/TRE zertifizieren ließ.
Referenz: ISO – ISO/IEC 27001
BSI-IT-Grundschutz: Eine vom Bundesamt für Sicherheit in der Informationstechnik entwickelte Methodik zum Aufbau eines ISMS und zur Erstellung konkreter Sicherheitskonzepte mithilfe von Standards und Bausteinen. Für das Interview ist relevant, wie die SPE/TRE modelliert, ihr Schutzbedarf bestimmt und die Erfüllung der jeweiligen Sicherheitsanforderungen dokumentiert wurde.
Referenz: BSI-Standard 200-1
EHDS: Der European Health Data Space ist der europäische Rechtsrahmen für den grenzüberschreitenden Austausch elektronischer Gesundheitsdaten sowie deren sichere Sekundärnutzung, etwa für Forschung und Innovation. Im Interview geht es darum, ob Architektur, Zugangsverfahren, Interoperabilität und sichere Verarbeitung bereits auf die schrittweise anwendbaren Anforderungen vorbereitet werden.
Referenz: Europäische Kommission – EHDS
ISMS: Ein Information Security Management System ist das organisatorische Gesamtsystem aus Richtlinien, Verantwortlichkeiten, Risikobewertungen, Sicherheitsmaßnahmen, Audits und kontinuierlicher Verbesserung. Im Interview ist relevant, welchen Geltungsbereich das ISMS abdeckt, wer Risiken verantwortet und ob es nur intern betrieben oder nach ISO/IEC 27001 zertifiziert wird.
Referenz: ISO – Informationssicherheitsmanagement
HDR UK Transparency: Gemeint ist vor allem der von der UK Health Data Research Alliance vorangetriebene Transparenzstandard für öffentliche Data Use Registers. Diese sollen verständlich und möglichst einheitlich zeigen, wer Gesundheitsdaten zu welchem Zweck nutzt und welche Ergebnisse daraus entstehen; im Interview wird geprüft, ob ein vergleichbares, aktuelles Projektregister geführt wird.
Referenz: HDR UK – Data Use Registers
PPI: Patient and Public Involvement bedeutet, dass Patientinnen, Patienten und Öffentlichkeit Forschung und Governance aktiv mitgestalten – Forschung wird also mit oder durch sie durchgeführt, nicht lediglich über sie. Im SPE-/TRE-Kontext kann PPI beispielsweise die Mitarbeit in Beiräten, die Bewertung von Datenzugangskriterien oder Rückmeldungen zu Transparenz, gesellschaftlichem Nutzen und akzeptablen Datennutzungen umfassen.
Referenz: NIHR – What is public involvement?
DataSHIELD-Ansätze: DataSHIELD ist eine Open-Source-Infrastruktur für föderierte Analysen, bei der Einzeldaten an den jeweiligen Standorten verbleiben und nur kontrollierte, nicht-offenlegende Statistiken zurückgegeben werden. Im Interview geht es um die Abwägung gegenüber einer zentralen TRE: weniger Datentransfer, aber gegebenenfalls Einschränkungen bei Analyseverfahren, Harmonisierung und Fehlersuche.
Referenz: DataSHIELD
Azure TRE: Azure TRE ist ein quelloffener Microsoft-Beschleuniger zum Aufbau projektbezogener Trusted Research Environments auf Azure – kein vollständig fertig betriebener oder automatisch zertifizierter Dienst. Er stellt unter anderem isolierte Workspaces, Identitätsintegration, kontrollierte Ein- und Ausgabekanäle sowie erweiterbare Analysewerkzeuge bereit; im Interview interessieren Cloud-Abhängigkeit, Anpassungsaufwand, Betrieb und Vendor-Lock-in.
Referenz: Azure-TRE-Dokumentation
Daten-Ingest: Bezeichnet den kontrollierten Prozess, mit dem Daten aus Quellsystemen in die SPE/TRE übernommen werden. Dazu gehören typischerweise sichere Übertragung, Prüfung auf Schadsoftware und Datenqualität, Pseudonymisierung, Transformation in ein Zielschema sowie die Dokumentation von Herkunft und Freigabe.
TTP: Eine Trusted Third Party, häufig als Treuhandstelle bezeichnet, übernimmt besonders sensible Aufgaben wie Identitätsmanagement, Pseudonymisierung und die Verwaltung der Zuordnungsschlüssel. Im Interview ist relevant, ob sie organisatorisch und technisch vom Datenhalter und vom SPE-Betreiber getrennt ist und wie Re-Identifizierungen kontrolliert werden.
Schema-Standards: Sie definieren Struktur, Datentypen, Terminologien und Beziehungen eines Datensatzes, damit Daten verschiedener Quellen einheitlich interpretiert und verarbeitet werden können. Im Interview geht es beispielsweise um HL7 FHIR, OMOP CDM oder den MII-Kerndatensatz sowie darum, wann und durch wen die Transformation und Validierung erfolgt.
Linkage: Linkage ist die Verknüpfung zusammengehöriger Datensätze – etwa Behandlungs-, Register- und Genomdaten derselben Person – über Quellen oder Einrichtungen hinweg. Dies kann deterministisch, probabilistisch oder datenschutzwahrend als Privacy-Preserving Record Linkage erfolgen; im Interview zählen Verfahren, Zuständigkeit, Fehlverknüpfungsrate und Umgang mit Identitätsmerkmalen.
Egress-Schutz: Darunter fallen alle technischen und organisatorischen Kontrollen, die einen unkontrollierten Informationsabfluss aus der SPE verhindern, beispielsweise Internetsperren, blockierte Downloads, Copy-and-paste-Beschränkungen und geprüfte Exportkanäle. Im Interview sollte geklärt werden, welche Ausgaben automatisch oder manuell geprüft, protokolliert und im Ausnahmefall freigegeben werden.
Referenz: Azure TRE – Systemarchitektur
PrivateAIM: PrivateAIM steht für Privacy-Preserving Analytics in Medicine und entwickelt mit FLAME eine Plattform für standortübergreifende medizinische Analysen nach dem Prinzip Code to Data. Daten bleiben in den Kliniken, während Analysecode lokal ausgeführt und nur kontrollierte Ergebnisse zusammengeführt werden; im Interview geht es um praktische Erfahrungen mit dieser föderierten Alternative beziehungsweise Ergänzung zu einer zentralen TRE.
Referenz: PrivateAIM
GDNG: Das Gesundheitsdatennutzungsgesetz regelt in Deutschland die Nutzung von Gesundheitsdaten für gemeinwohlorientierte Forschung, Versorgungsverbesserung und weitere öffentliche Zwecke. Es erleichtert unter anderem Datenzugang und -verknüpfung, ersetzt aber nicht automatisch die Prüfung von DSGVO, Krankenhausrecht und konkreter Rechtsgrundlage; im Interview geht es um deren praktisches Zusammenspiel.
Referenz: Gesundheitsdatennutzungsgesetz
AI Act: Der EU AI Act ist ein risikobasierter Rechtsrahmen für KI-Systeme und unterscheidet unter anderem verbotene, hochriskante sowie transparenzpflichtige Anwendungen. Im Interview muss geklärt werden, wer als Anbieter oder Betreiber beziehungsweise Deployer handelt, ob das System hochriskant ist und welche Pflichten für Risikomanagement, Datenqualität, Dokumentation, Logging, menschliche Aufsicht und Cybersicherheit entstehen.
Referenz: Europäische Kommission – AI Act
MDR: Die Medical Device Regulation, Verordnung (EU) 2017/745, regelt das Inverkehrbringen und den Betrieb von Medizinprodukten einschließlich bestimmter medizinischer Software. Ein KI-Modell fällt nicht allein wegen seines medizinischen Umfelds darunter, sondern insbesondere dann, wenn ihm der Hersteller einen konkreten medizinischen Verwendungszweck gibt; im Interview zählen daher Zweckbestimmung, Risikoklasse, Herstellerrolle und Entwicklungsphase.
Referenz: EU – Ist Ihre Software ein Medizinprodukt?
CE-Kennzeichnung: Die CE-Kennzeichnung zeigt an, dass der Hersteller die Konformität eines Produkts mit den einschlägigen EU-Vorschriften erklärt und die vorgeschriebenen Verfahren abgeschlossen hat. Sie ist kein allgemeines Qualitätssiegel und bei Medizinprodukten höherer Risikoklassen regelmäßig mit der Prüfung durch eine Benannte Stelle verbunden; im Interview ist relevant, ob ein Modell die SPE nur als Forschungsartefakt verlässt oder für den klinischen Einsatz bereitgestellt wird.
Referenz: EU – Einführung in die MDR
Konformitätsbewertung: Das ist das formale Verfahren, mit dem vor dem Inverkehrbringen oder der Inbetriebnahme nachgewiesen wird, dass ein Produkt alle anwendbaren gesetzlichen Anforderungen erfüllt. Je nach Risikoklasse umfasst es unter anderem Qualitätsmanagement, Risikomanagement, technische Dokumentation, klinische Bewertung, Tests und gegebenenfalls die Einbindung einer Benannten Stelle; bei medizinischer Hochrisiko-KI müssen MDR- und AI-Act-Anforderungen zusammengedacht werden.
Referenz: EU – Konformitätsbewertung und CE-Kennzeichnung
Output-Disclosure-Reviews: Ein formales Prüfverfahren, bei dem Analyseergebnisse vor dem Verlassen der SPE auf Reidentifikations- und Offenlegungsrisiken untersucht werden. Im Interview geht es um automatische Prüfungen, manuelle Fachprüfung, Vier-Augen-Prinzip, Dokumentation und darum, ob auch trainierte Modelle als prüfpflichtige Outputs gelten.
Referenz: UK Data Service – Output Release Checklist
Mindestbesetzung: Eine Mindestbesetzungsregel verlangt, dass eine Tabellenzelle oder analysierte Gruppe eine festgelegte Mindestzahl von Fällen enthält. Kleine Fallzahlen werden nicht freigegeben, weil Einzelpersonen leichter identifizierbar sein können; die konkrete Schwelle hängt von Datenart und Betreiberregelwerk ab.
Referenz: UK Data Service – SecureLab FAQs
Suppressionsregeln: Suppression bedeutet, besonders kleine oder anderweitig riskante Tabellenwerte zu unterdrücken beziehungsweise nicht auszugeben. Neben der primären Unterdrückung kann eine sekundäre Suppression weiterer Zellen notwendig sein, damit sich der verborgene Wert nicht aus Summen und Nachbarzellen zurückrechnen lässt.
Referenz: UK Data Service – Statistical Disclosure Control
Membership Inference: Bei diesem Angriff wird aus den Antworten eines Modells abgeleitet, ob ein bestimmter Datensatz zum Training gehörte. Im medizinischen Kontext kann bereits diese Information sensibel sein, etwa wenn die Teilnahme am Trainingsdatensatz auf eine Diagnose oder Behandlung schließen lässt.
Referenz: Shokri et al. – Membership Inference Attacks
Model Extraction: Dabei versucht ein Angreifer, durch systematische Abfragen die Funktionsweise, Entscheidungsgrenzen oder Parameter eines Modells nachzubilden. Das gefährdet geistiges Eigentum und kann weitere Angriffe erleichtern, ist aber von der direkten Extraktion einzelner Trainingsdaten zu unterscheiden.
Referenz: Tramèr et al. – Stealing Machine Learning Models
Memorisierung sensibler Trainingsdaten: Ein Modell kann seltene oder charakteristische Trainingsbeispiele nahezu wörtlich beziehungsweise detailgetreu speichern, statt nur allgemeine Muster zu lernen. Lassen sich solche Inhalte durch geeignete Eingaben wieder hervorrufen, können beispielsweise Namen, Befunde oder Textpassagen aus Trainingsdaten offengelegt werden.
Referenz: Carlini et al. – Extracting Training Data
Privacy-Preserving Machine Learning: Ein Oberbegriff für Verfahren, die ML-Analysen ermöglichen und dabei die Offenlegung von Trainingsdaten, Eingaben, Modellen oder Ergebnissen begrenzen. Dazu zählen unter anderem Differential Privacy, föderiertes Lernen, sichere Mehrparteienberechnung sowie homomorphe und funktionale Verschlüsselung; im Interview interessieren konkrete Schutzziele und Wirksamkeitsnachweise.
Referenz: ENISA – Securing Machine Learning Algorithms
Differential Privacy: Ein mathematisches Datenschutzkonzept, bei dem das Ergebnis einer Analyse nur begrenzt davon abhängen soll, ob der Datensatz einer einzelnen Person enthalten ist. Meist wird dazu kontrolliertes Rauschen eingesetzt; Parameter wie das Privacy-Budget ε dokumentieren die Abwägung zwischen Datenschutz und Ergebnisgenauigkeit.
Referenz: NIST – Differential Privacy
Homomorphe Verschlüsselung: Sie ermöglicht Berechnungen unmittelbar auf verschlüsselten Daten, ohne diese während der Verarbeitung im Klartext offenzulegen. Das Resultat bleibt zunächst verschlüsselt und wird erst vom berechtigten Schlüsselinhaber entschlüsselt; praktische Grenzen sind häufig Rechenaufwand und eingeschränkte Operationen.
Referenz: NIST – Privacy-Enhancing Cryptography
Funktionale Verschlüsselung: Hier berechtigt ein spezieller Schlüssel nur dazu, eine festgelegte Funktion über verschlüsselte Daten zu berechnen und deren Ergebnis zu erfahren – nicht dazu, die vollständigen Daten zu entschlüsseln. Im SPE-Kontext könnte dadurch beispielsweise nur eine freigegebene Statistik zugänglich werden; das Verfahren ist derzeit stärker spezialisiert als klassische Verschlüsselung.
Referenz: IACR – Functional Encryption
Modellkarten (Model Cards): Strukturierte Begleitdokumente für trainierte Modelle, die unter anderem Zweck, vorgesehene und ungeeignete Anwendungen, Leistungswerte, getestete Gruppen, Grenzen und Risiken beschreiben. Im Interview ist relevant, ob sie vor Import oder Export verpflichtend sind, wer die Angaben validiert und wie Änderungen versioniert werden.
Referenz: Google Research – Model Cards
Datenkarten (Data Cards): Strukturierte Dokumentationen eines Datensatzes mit Angaben etwa zu Herkunft, Erhebung, Zusammensetzung, Aufbereitung, Qualität, Sensibilität, Einschränkungen und zulässigen Nutzungen. Sie sollen nachvollziehbar machen, unter welchen Bedingungen ein Modell trainiert oder bewertet wurde und welche Verzerrungen daraus entstehen können.
Referenz: Google Research – Data Cards
Kostendegression: Die durchschnittlichen Kosten pro Projekt, Nutzer oder Analyse sinken, wenn fixe Aufwände auf mehr Nutzungen verteilt werden. Im Interview geht es um reale Skaleneffekte und darum, welche Kosten – etwa Support, Datenschutzprüfung und Output-Review – weiterhin proportional wachsen.
Container-Stack: Anwendungen und Abhängigkeiten werden als Container paketiert und beispielsweise über Kubernetes orchestriert. Das ermöglicht reproduzierbare, automatisierte Analyseumgebungen; im Interview zählen auch Betriebsaufwand, Sicherheitsupdates und benötigtes Spezialwissen.
Multi-Tenant: Mehrere Projekte oder Organisationen nutzen eine gemeinsame Plattform, bleiben aber hinsichtlich Daten, Identitäten, Berechtigungen und Abrechnung logisch getrennt. Das verbessert die Auslastung, verlangt jedoch nachweisbar sichere Isolation zwischen den Mandanten.
Federation: Mehrere eigenständige SPEs/TREs kooperieren über gemeinsame Schnittstellen sowie Identitäts-, Governance- und Analyseverfahren, ohne ihre Daten vollständig zu zentralisieren. Wiederverwendbare Standards und Komponenten können Kosten senken, während Koordination, Interoperabilität und verteilte Verantwortung zusätzlichen Aufwand erzeugen.