MII Implementation Guide Consent
2027.0.0-ballot -
Germany
MII Implementation Guide Consent - Downloaded Version 2027.0.0-ballot See the Directory of published versions
Diese Seite bündelt die implementierungsbezogenen Abschnitte des ursprünglichen Leitfadens: die technische Implementierung, den Kontext im Gesamtprojekt, die Referenzen und die Empfehlungen zur praktischen Anwendung.
Dieser Abschnitt beschreibt die syntaktischen und semantischen Vorgaben zur Implementierung des Consent-Moduls.
Weiterhin sind auch Suchparameter definiert, die bei Verwendung der FHIR RESTful API durch die jeweiligen Systeme implementiert werden müssen. Grundsätzlich werden logische AND- und OR-Verknüpfungen der FHIR-Search unterstützt, vgl. https://www.hl7.org/fhir/search.html .
Grundlagen und weitere Details zur Suche und zur FHIR RESTful API werden zum Zeitpunkt der Erstellung dieses Implementierungsleitfadens im Rahmen der Basismodule erarbeitet und können zu einem späteren Zeitpunkt die hier gemachten Vorgaben ergänzen. Ggf. wird dann auch eine neue Version dieses Leitfadens veröffentlicht.
Das Modul Consent dient der Unterstützung von standortübergreifenden Datennutzunganfragen basierend auf dem jeweils aktuellen Einwilligungsstatus des Patienten am Standort.
Um den Bezug zwischen Person und Einwilligung herzustellen, wird die Einwilligung mit mindestens einem eindeutigen Personenidentifikator versehen (Basismodul: Person). Dies ist im Regelfall ein pseudonymer Identifikator.
In der Handreichung zur Patienteninformation & Teilnahmeerklärung zum „Modellvorhaben Genomsequenzierung bei seltenen und bei onkologischen Erkrankungen“ nach § 64e SGB in der Version V1 wird unter Kapitel 2.1.4 Forschungseinwilligung die Nutzung des MII-Broad Consent ab der Version 1.6d empfohlen und im gesetzlichen Sinn mindestens der Basisversion ohne Zusatzmodule entspricht.
Die Modellierung des Datensatzes zum Modul Consent enthält Referenzen zu folgenden Projekten:
Es wurden außerdem die Kernspezifikation von HL7 FHIR, hierunter die entsprechende Ressource Consent, und die bisherigen Arbeiten zu den Deutschen Basisprofilen in STU3 und R4 berücksichtigt.
Die vorliegende Spezifikation wurde gestaltet auf Basis der Beschreibung des MII-Kerndatensatzes in der Version vom 10.3.2017 (PDF), sowie der Datensatzbeschreibung in ART-DECOR.
Im IG der HL7-D AG Einwilligungsmanagement und der korrespondierenden Publikation wird die Bedeutung des Parameters ResultType umfassend erläutert.
Besonderes Augenmerk sei an dieser Stelle auf die Codes consent-status und document gelegt. Weitere Details und Zusammenhänge sind hier beschrieben.
Konkrete verpflichtende Projektvorgaben zur Verwendung des Suchparameters ResultType sind in der Praxis aufgrund heterogener technischer Gegebenheiten an den MII-Standorten nur bedingt zielführend. Die technische Umsetzung der Vorgaben ist abhängig von der konkreten Implementierung.
Das Einwilligungsmanagement gICS stellt die aktuelle Referenzimplementierung des HL7-D FHIR Standards für Einwilligungsmanagement (Version 2.0) dar.
Alle Implementierungen sollten mindestens folgende Varianten unterstützen. Die Kardinalität von Consent.category ist mit 2..* definiert und ermöglicht die notwendige Abwärtskompatibilität.
| ResultType | Bedeutung für die Consent-Ressource | Aggregation von Informationen |
|---|---|---|
document |
Die Consent-Ressource bezieht sich auf ein (!) ausgefülltes Dokument (QuestionnaireResponse). Dies sollte der Default in einem (MII) FHIR-Server sein. | nein |
consent-status |
Die Consent-Ressource berücksichtigt alle relevanten Einwilligungs- und Widerrufsdokumente im Kontext der MII für einen (!) Patienten . Die Consent Ressource mit ResultType consent-status bezieht sich immer auf einen Patienten und enthält den aktuellen Einwilligungsstand. Dies sollte idealerweise durch den (MII) FHIR-Server unterstützt werden. |
Ja, berechnet durch entsprechende Business-Logik zum Zeitpunkt der Abfrage oder für einen bestimmten Zeitraum. |
Idealerweise sollte der FHIR-Server je Patient stets nur eine Consent-Ressource mit den aktuellen aggregierten Einwilligungsinformationen (ResultType consent-status) vorhalten.
Ist dies aus dritten Gründen nicht möglich, sollte mindestens je ausgefülltem Dokument (Einwilligung, aktualisierte Einwilligung,Teil-Widerruf, Vollständiger Widerruf) eine Dokument-spezifische Ausleitung ermöglicht werden (ResultType document). Es bleibt in diesem Fall in der Verantwortung des Standortes, diese Informationen in der vom FDPG geforderten Form bereitzustellen.
Die Datenintegrationzentren stellen die erforderlichen Informationen zur Ermittlung von Kerndatensatzspezifischen Kennzahlen für das DIZ-Dashboard bereit. Die Ermittlung der Kennzahlen wird auf Seiten des DIZ-Dashboard durch entsprechende Aufrufe an die Standorte auch für das MII KDS Consent Modul getriggert.
Standorte, die das Einwilligungsmanagement gICS verwenden, sollten bei der Kennzahlen-Ermittlung sowie bei der Bereitstellung der Consent-Ressourcen für das FDPG den präzisen Hersteller-Empfehlungen folgen.