This page is part of the MII IG Dokument (v2027.0.0-ballot.2: 2027 Ballot 3) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. For a full list of available versions, see the Directory of published versions

Sicherheit und Datenschutz

Dieser Abschnitt richtet sich an Sicherheits- und Datenschutz-Fachleute. Allgemeine Anforderungen stehen in der FHIR-Kernspezifikation — Security & Privacy Module und die Security-Checkliste. Diese Seite wiederholt sie nicht; sie verlinkt den übergreifenden Datenschutzrahmen und nennt, was für dieses Modul spezifisch ist.

Das übergreifende Datenschutzkonzept

Das übergreifende Datenschutzkonzept der Medizininformatik-Initiative regelt, wie Patientendaten über das Netz der Datenintegrationszentren hinweg für die Forschung verarbeitet werden dürfen: die Rechtsgrundlage (der Broad Consent der MII), die Rollen der Datenintegrationszentren und der Use-&-Access-Committees sowie die standortübergreifenden Anwendungsszenarien (Machbarkeitsanfragen, verteilte Analysen, Daten- und Bioproben-Bereitstellung). Alles, was dieses Modul spezifiziert, bewegt sich innerhalb dieses Rahmens — dieser Leitfaden fügt keinen eigenen Verarbeitungszweck hinzu.

De-Identifikation, Minimierung und Pseudonymisierung (DIMP)

Wie Daten, die ein Datenintegrationszentrum verlassen, praktisch de-identifiziert werden, spezifiziert DIMP (De-Identification — Minimisation — Pseudonymisation) in der Dokumentation des Datenportals: direkte Identifikatoren werden entfernt, vom genehmigten Projekt nicht benötigte Datenelemente entfallen, und identifizierende Werte werden durch projektspezifische Pseudonyme ersetzt (FHIR-Pseudonymizer-Konfiguration). Die Profile dieses Moduls beschreiben die Daten vor Anwendung von DIMP; welche Elemente eine konkrete Datenbereitstellung erreicht, entscheidet je Projekt die DIMP-Konfiguration, nicht dieser Leitfaden.

Modul-spezifische Aspekte

Dies ist der eigene Beitrag des Moduls: die Sicherheits- und Datenschutz-Eigenschaften, die aus der Art der Daten dieses Moduls folgen.

Die folgenden modulspezifischen Aspekte wurden aus dem Profil und den Modulbeschreibungen abgeleitet (Slices Binaerdaten/Verweis, NLP-Processing-Status, relatesTo-Verarbeitungsketten).

Dieses Modul transportiert — anders als rein strukturierte KDS-Module — über content.attachment auch den Dokumentkörper selbst. Daraus folgen eigene Aspekte:

Freitext ist die sensibelste Datenkategorie dieses Moduls. Der Textkörper eines Dokuments kann vielfältige identifizierende Daten und/oder Metadaten (z.B. Namen, Patienten-ID) enthalten, die eine strukturierte Pseudonymisierung nicht erfasst. Werkzeuge der DIMP-Kette arbeiten auf strukturierten Elementen; der Inhalt eines Anhangs bleibt davon unberührt.

Einbettung vs. Verweis. Das Profil erlaubt beide Transportwege für den Dokumentkörper: eingebettet als Base64 (content.attachment.data, Slice Binaerdaten) oder als lokal aufzulösender Verweis (content.attachment.url, Slice Verweis). Soweit das Dokument medizinische oder identifizierende Daten zu Patient:innen oder Behandlung enthält, SOLLTE der Dokumentkörper bei einer Datenbereitstellung über das Forschungsdatenportal für Gesundheit (FDPG) bzw. in UAC-geprüften Projekten NICHT eingebettet werden: eingebettete Inhalte durchlaufen jede Verarbeitungs- und Weitergabestufe mit und entziehen sich der Zugriffskontrolle des Dokumentenspeichers. Der Verweis (Verweis) belässt die Auflösung dagegen unter der Kontrolle der datenhaltenden Stelle (DIZ) und kann dort DIMP-konform gefiltert und protokolliert werden. Für Dokumente ohne solche Inhalte — etwa vollständig surrogierte Fassungen — gilt diese Einschränkung nicht.

De-Identifikationsstatus explizit kennzeichnen. Eine erfolgte De-Identifizierung wird über geeignete securityLabel und/oder die NLP-Processing-Status-Extension (die vier übergeordneten Codes unprocessed, preprocessed, annotated, surrogated — preprocessed und annotated jeweils mit den Lvl-2-Codes format-change/content-change bzw. preanno/deid/semantic) ausgedrückt. Die datenhaltende Stelle ist verantwortlich, für Forschungszwecke ausschließlich auf anonymisierte bzw. pseudonymisierte Varianten zu verweisen (subject → das pseudonymisierte Patient-Profil des Basismoduls; für context.encounter existiert keine pseudonymisierte Variante im Basismodul).

Verarbeitungsketten können Re-Identifizierungspfade öffnen. Die NLP-Pipeline verknüpft Original-, Klartext-, de-identifizierte und annotierte Fassungen über relatesTo (transforms/appends). Bei einer Datenbereitstellung dürfen de-identifizierte bzw. surrogierte Dokumente nicht zusammen mit auflösbaren Verweisen auf ihre Originalfassungen ausgeliefert werden — die Kette hebt die De-Identifizierung sonst auf.

Auch Metadaten können quasi-identifizierend sein. Einrichtungsart, Fachgebiet, Zeitstempel und Kontaktbezüge erlauben in Kombination Rückschlüsse; welche Metadatenelemente eine konkrete Datenbereitstellung erreicht, entscheidet die projektspezifische DIMP-Konfiguration.