This page is part of the MII Implementation Guide Seltene Erkrankungen (v2027.0.0-ballot: 2027 Ballot 1) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions

Sicherheit und Datenschutz

Diese Seite enthält Übersetzungen aus der Originalsprache, in der der Leitfaden verfasst wurde. Informationen zu diesen Übersetzungen und Anweisungen zum Abgeben von Feedback zu den Übersetzungen finden Sie hier.

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.

1. 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.

2. 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.

3. Modul-spezifische Aspekte

Dies ist der eigene Beitrag des Moduls: die Sicherheits- und Datenschutz-Eigenschaften, die aus der Art der Daten dieses Moduls folgen. Der Inhalt dieses Abschnitts ist optional — nicht jedes Modul hat eigene Aspekte. Hat Ihres keine, besteht der gesamte Abschnitt aus dem folgenden Standardtext (löschen Sie die Beispiel- und TODO-Boxen unten und übernehmen Sie ihn wörtlich):

Über den oben verlinkten übergreifenden Rahmen hinaus — das übergreifende Datenschutzkonzept, den ihm zugrunde liegenden Broad Consent und DIMP — führt dieses Modul keine Datenkategorie, die eigene Sicherheits- oder Datenschutzaspekte aufwirft, und stellt keine modulspezifischen Sicherheits- oder Datenschutzanforderungen an Implementierende.

Written during migration - review before release. Die folgenden modulspezifischen Aspekte wurden aus den Artefakten des Moduls abgeleitet: Dieses Modul führt Datenkategorien erhöhter Sensibilität. ORPHAcode-kodierte Diagnosen Seltener Erkrankungen sind per Definition selten — kleine Fallzahlen erhöhen das Re-Identifikationsrisiko pseudonymisierter Datensätze erheblich, insbesondere in Kombination mit Region, Alter oder den detaillierten HPO-Phänotyp-Profilen dieses Moduls. Die genetischen Diagnosen und die strukturierte Familienanamnese tragen zusätzlich Informationen über Dritte (biologische Verwandte), die selbst nicht in den MII Broad Consent eingewilligt haben. Implementierende SOLLTEN Kombinationen aus ORPHA-Diagnose, Phänotyp-Profil und Familienanamnese daher als quasi-identifizierend behandeln, die Output-Kontrollen der Use-&-Access-Prozesse auf kleine Zellbesetzungen anwenden und beachten, dass die Übermittlung an externe Register (NARSE, ERN/ERDRI) die separate, ausdrückliche Einwilligung der betroffenen Person voraussetzt, wie auf den Modulseiten beschrieben.