|
Type
|
Reference
|
Content
|
|
web
|
www.netzwerk-universitaetsmedizin.de
|
|
|
web
|
github.com
|
Konformität
|
|
web
|
github.com
|
Konformität
|
|
web
|
github.com
|
Allgemeine Anforderungen
|
|
web
|
github.com
|
Must-Support
|
|
web
|
github.com
|
Umgang mit fehlenden Daten
|
|
web
|
www.netzwerk-universitaetsmedizin.de
|
IG © 2019+ NUM-DIZ
.
Package de.medizininformatikinitiative.kerndatensatz.consent#2027.0.0-ballot basiert auf FHIR 4.0.1
.
Erstellt 2026-09-14
Links: Inhaltsverzeichnis |
QA-Bericht
| netzwerk-universitaetsmedizin.de
| medizininformatik-initiative.de
| Impressum
HL7®, FHIR® and the FHIR flame design are registered trademarks of Health Level Seven International. Their use does not constitute endorsement by HL7.
|
|
web
|
www.netzwerk-universitaetsmedizin.de
|
Links: Inhaltsverzeichnis
|
QA-Bericht
| netzwerk-universitaetsmedizin.de
| medizininformatik-initiative.de
| Impressum
HL7®, FHIR® and the FHIR flame design are registered trademarks of Health Level Seven International. Their use does not constitute endorsement by HL7.
|
|
web
|
www.medizininformatik-initiative.de
|
Links: Inhaltsverzeichnis
|
QA-Bericht
| netzwerk-universitaetsmedizin.de
| medizininformatik-initiative.de
| Impressum
HL7®, FHIR® and the FHIR flame design are registered trademarks of Health Level Seven International. Their use does not constitute endorsement by HL7.
|
|
web
|
www.netzwerk-universitaetsmedizin.de
|
Links: Inhaltsverzeichnis
|
QA-Bericht
| netzwerk-universitaetsmedizin.de
| medizininformatik-initiative.de
| Impressum
HL7®, FHIR® and the FHIR flame design are registered trademarks of Health Level Seven International. Their use does not constitute endorsement by HL7.
|
|
web
|
creativecommons.org
|
Diese Arbeit ist lizensiert unter der Creative Commons Attribution 4.0 International License
.
Zu den Nutzungsrechten der zugrunde liegenden FHIR-Technologie siehe die FHIR-Basis-Spezifikation.
Einige verwendete Codesysteme werden von anderen Organisationen herausgegeben und gepflegt. Es gilt das Copyright der dort jeweils aufgeführten Herausgeber (Publisher).
|
|
web
|
github.com
|
Woher die Versionen kommen.
Jedes Paket der Tabelle ist direkt in
sushi-config.yaml
( dependencies:
) gepinnt — auch hl7.terminology.r4
(THO) und
hl7.fhir.uv.extensions.r4
, und diese beiden mit Bedacht: Die
Automatik des IG Publishers
liest ausschließlich die eigene
Abhängigkeitsliste dieses Leitfadens;
ohne direkten Pin würde jeder Build stillschweigend das jeweils aktuellste
THO-/Extensions-Release injizieren — eine allein im MII-Meta-Paket gepinnte
Version kann den Build nicht steuern (verifiziert im Publisher-Quellcode des
gepinnten Release). Eine wöchentliche Prüfung warnt, wenn diese beiden Pins
von den Vorgaben des gepinnten Meta-Pakets abweichen; die von einem
konkreten Build verwendeten Versionen stehen in dessen qa-versions.json
.
|
|
web
|
creativecommons.org
|
© 2019+ TMF e. V., Charlottenstraße 42, 10117 BerlinCC BY 4.0Diese Arbeit ist lizensiert unter der Creative Commons Attribution 4.0 International License
.
Zu den Nutzungsrechten der zugrunde liegenden FHIR-Technologie siehe die FHIR-Basis-Spezifikation.
Einige verwendete Codesysteme werden von anderen Organisationen herausgegeben und gepflegt. Es gilt das Copyright der dort jeweils aufgeführten Herausgeber (Publisher).
Show Usage
|
|
web
|
github.com
|
Expansionsparameter sind Query-Parameter, die an eine ValueSet
-
$expand
-Operation übergeben werden können, um zu steuern, wie das ValueSet
expandiert wird — also wie die vollständige Liste der Codes aus der
ValueSet-Definition erzeugt wird. Die für diesen IG verwendeten
IG-Parameter
sind in
sushi-config.yaml
( parameters:
) deklariert. Ein Modul, das seine Expansionsparameter über ein
CRMI-Manifest pinnt, verlinkt hier zusätzlich die generierte
Parameters
-Ressource (siehe die auskommentierten Manifest-Blöcke in
sushi-config.yaml
und die Seite Metadata Overview, sofern das Modul sie
behält).
|
|
web
|
ihe.net
|
XDS metadata equivalent
|
|
web
|
ig.fhir.de
|
Basierend auf den Empfehlungen
der AG Einwilligungsmanagement, zielt das Profile MIIConsentDocumentReference
auf ein real existierendes Dokument mit Bezug zum Einwilligungsdokument ab.
|
|
web
|
ig.fhir.de
|
Nachfolgend werden nur die Unterschiede zum Basis-Profil
erläutert.
|
|
web
|
www.medizininformatik-initiative.de
|
Beim Einschluss einer Person in eine Studie (auch in einen MII-Use Case) wird eine Einwilligung für diese Person auf Basis der MII Broad Consent Mustertexte
erhoben und entsprechende Einwilligungsdokument am jeweiligen Standort strukturiert dokumentiert gemäß den Vorgaben der MII Task Force Consent Umsetzung
.
|
|
web
|
art-decor.org
|
Beim Einschluss einer Person in eine Studie (auch in einen MII-Use Case) wird eine Einwilligung für diese Person auf Basis der MII Broad Consent Mustertexte
erhoben und entsprechende Einwilligungsdokument am jeweiligen Standort strukturiert dokumentiert gemäß den Vorgaben der MII Task Force Consent Umsetzung
.
|
|
web
|
ig.fhir.de
|
Auf Grundlage dieser Einwilligungsdokumente wird die FHIR Consent Ressource automatisiert erzeugt. Der Projektkontext
bleibt erhalten.
|
|
web
|
art-decor.org
|
Um die Austauschbarkeit der operationalisierten Einwilligungsinhalte auch über FHIR hinaus sicherzustellen, wurde mit der MII AG Consent
ein einheitliches PolicyValueSet zur semantischen Abbildung
der im MII Broad Consent enthaltenen Aussagen im Dezember 2021 abgestimmt und im ART-DECOR
(Policy-OIDs) dokumentiert.
|
|
web
|
ig.fhir.de
|
Must-support gemäß Vorgaben AG Einwilligungsmanagement
, jedoch optional
|
|
web
|
ig.fhir.de
|
ResultType gemäß ResultType
. Es sollten mindestens document
und consent-status
unterstützt werden. Wenn als ResultType document
angegeben ist, muss die Art des (Quell-)Dokuments im Slice templateType ebenfalls angegeben werden.
|
|
web
|
ig.fhir.de
|
Kategorisierung gemäß TemplateType
. Dient als informelles Element der Differenzierung zwischen Einwilligung, Widerruf, Widerspruch und Ablehnung.
|
|
web
|
art-decor.org
|
Eindeutige OID gemäß Vorgabe der TFCU
|
|
web
|
www.ths-greifswald.de
|
Die Einwilligung des Patienten endet nach Vorgaben der MII AG Consent grundsätzlich nach 30 Jahren. Einen Sonderfall stellen die Einwilligungen von Minderjährigen (von der Einwilligung betroffene Person) dar. Im Fall von Einwilligungen für Minderjährige
, die ggf. durch entsprechende Sorgeberechtigte stellvertretend ausgefüllt wurden, endet die Einwilligung mit Erreichung der Volljährigkeit
der betroffenen Person. Dies ist entsprechend technisch umzusetzen. Referenzimplementierungen
existieren.
|
|
web
|
www.medizininformatik-initiative.de
|
Die Widerrufsvorlage (kompatibel mit MII BC 1.7.2)
ist ebenfalls für den Widerruf von Einwilligungen Minderjähriger gedacht, da diese in der Regel ebenfalls durch die Sorgeberechtigten ausgefüllt werden.
|
|
web
|
ig.fhir.de
|
Basierend auf den Empfehlungen
der AG Einwilligungsmanagement, beschreibt das Profile MIIConsentProvenance
die Herkunfsinformationen eines Einwilligungsdokuments.
|
|
web
|
ig.fhir.de
|
Nachfolgend werden nur die Unterschiede zum Basis-Profil
erläutert.
|
|
web
|
ig.fhir.de
|
Hinweis 1 - Verwendung in FHIR:
Siehe Implementation Guide
.
|
|
web
|
keepachangelog.com
|
Diese Seite hält die Änderungen zwischen den veröffentlichten Versionen des
Moduls Consent
fest, die neueste Version zuerst. Sie folgt
Keep a Changelog
und dem
KDS-CalVer-Schema, das die Seite Versionierung
beschreibt.
|
|
web
|
github.com
|
Erstes Release des Moduls aus der IG-Publisher-Toolchain. Es baut auf dem
Release-Paket 2027.0.0-ballot.rc1 auf und ergänzt die QA-Korrekturen aus den
Pull-Requests #135
bis #141
sowie die Anhebung des
Eltern-Pakets.
|
|
web
|
github.com
|
Erstes Release des Moduls aus der IG-Publisher-Toolchain. Es baut auf dem
Release-Paket 2027.0.0-ballot.rc1 auf und ergänzt die QA-Korrekturen aus den
Pull-Requests #135
bis #141
sowie die Anhebung des
Eltern-Pakets.
|
|
web
|
github.com
|
Hinzugefügt
— vier synthetische Referenzziel-Instanzen (zwei Patient
,
zwei ResearchStudy
), damit die Referenzen der Beispiele auflösen
( #137
).
|
|
web
|
github.com
|
Geändert
— die category
-Slices resultType
und templateType
erhalten entscheidbare pattern
-Discriminatoren ( #140
).
|
|
web
|
github.com
|
Behoben
— Policy-Displays der Beispiele an das CodeSystem angeglichen
( #136
); CodeSystem.count
auf die tatsächliche Konzeptzahl
korrigiert ( #139
); das Answer-ValueSet auf ein nacktes
All-System- include
reduziert ( #138
); das Beispiel 89f494a3
auf das definierte Version-Modul-CodeSystem umgestellt ( #135
).
|
|
web
|
github.com
|
Behoben
— Policy-Displays der Beispiele an das CodeSystem angeglichen
( #136
); CodeSystem.count
auf die tatsächliche Konzeptzahl
korrigiert ( #139
); das Answer-ValueSet auf ein nacktes
All-System- include
reduziert ( #138
); das Beispiel 89f494a3
auf das definierte Version-Modul-CodeSystem umgestellt ( #135
).
|
|
web
|
github.com
|
Behoben
— Policy-Displays der Beispiele an das CodeSystem angeglichen
( #136
); CodeSystem.count
auf die tatsächliche Konzeptzahl
korrigiert ( #139
); das Answer-ValueSet auf ein nacktes
All-System- include
reduziert ( #138
); das Beispiel 89f494a3
auf das definierte Version-Modul-CodeSystem umgestellt ( #135
).
|
|
web
|
github.com
|
Behoben
— Policy-Displays der Beispiele an das CodeSystem angeglichen
( #136
); CodeSystem.count
auf die tatsächliche Konzeptzahl
korrigiert ( #139
); das Answer-ValueSet auf ein nacktes
All-System- include
reduziert ( #138
); das Beispiel 89f494a3
auf das definierte Version-Modul-CodeSystem umgestellt ( #135
).
|
|
web
|
github.com
|
BREAKING: Geändert
— die Ressourcen-IDs sind auf die kanonischen Tails
modernisiert ( #141
).
-
Was genau sich geändert hat:
14 Artefakte tragen neue
id
-Werte — die
drei Profile ( 56375452-…
→ mii-pr-consent-documentreference
,
e0e166b4-…
→ mii-pr-consent-einwilligung
, f675b1e8-…
→
mii-pr-consent-provenance
), die drei ValueSets
( 2.16.840.…11.30--20210323234509
→ mii-vs-consent-answer
,
2.16.840.…11.36--20230331232804
→ mii-vs-consent-policy
, 88464c5b-…
→
mii-vs-consent-signaturetypes
) und die sechs SearchParameter, die im
Vorgänger-Paket
gar keine id
trugen (jetzt mii-sp-consent-…
). Die
kanonischen URLs bleiben unverändert
; die IDs folgen jetzt der
MII-Namenskonvention (kebab-case des name
).
-
Was das für bestehende Daten bedeutet:
Instanzdaten sind nicht
betroffen. Beispiele und Produktivdaten referenzieren die Profile über die
kanonische URL in
meta.profile
, und diese ändert sich nicht — Daten, die
gegen 2027.0.0-ballot.rc1 valide waren, validieren unverändert weiter.
-
Was Implementierende tun sollten:
Jede Referenz, die ein Artefakt über
seine ID
statt über die kanonische URL adressiert, muss angepasst
werden — insbesondere REST-Zugriffe der Form
[base]/StructureDefinition/e0e166b4-…
, in Registries gespeicherte
Artefakt-IDs und Deep-Links auf die Artefaktseiten des Leitfadens (deren
Dateinamen der ID folgen). Ein automatischer Migrationspfad wird nicht
bereitgestellt; die Zuordnung alt → neu ist die obige Liste.
|
|
web
|
github.com
|
offizielle Release
2027.0.0-ballot.rc1
|
|
web
|
github.com
|
Geändert
— Migration des Leitfadens auf das
MII-KDS-Modul-Template
v0.13.2 (IG-Publisher-Toolchain, DE-first-Sprachmodell, Template-Seitenstruktur);
inhaltlich identisch mit Release 2026.0.0
(Profile, Terminologien und
Beispiele unverändert; Nachweis: migration-log/
auf diesem Branch). Alle
Artefakt-Versionen auf die Paketversion 2027.0.0-ballot.rc1 harmonisiert
(zuvor je Artefakt abweichend, z. B. 1.0.9/1.6.0/1.1.0).
|
|
web
|
github.com
|
Full Changelog
: https://github.com/medizininformatik-initiative/kerndatensatzmodul-consent/compare/2026.0.0…2027.0.0-ballot.rc1
|
|
web
|
github.com
|
Full Changelog: https://github.com/medizininformatik-initiative/kerndatensatzmodul-consent/compare/2025.0.3…2026.0.0
|
|
web
|
github.com
|
Full Changelog: https://github.com/medizininformatik-initiative/kerndatensatzmodul-consent/compare/2025.0.0…2025.0.3
|
|
web
|
github.com
|
Full Changelog: https://github.com/medizininformatik-initiative/kerndatensatzmodul-consent/compare/1.0.7…2025.0.0
|
|
web
|
mii-termserv.de
|
Wichtig:
CodeSystem-Ressourcen externer Terminologien (z. B. ICD-10-GM, OPS,
SNOMED CT) werden in diesem Modul nicht
publiziert, sondern über den
zentralen KDS-Terminologieserver (SU-TermServ) bezogen:
https://mii-termserv.de/
.
|
|
web
|
ig.fhir.de
|
Die AG Einwilligungsmanagement
hat sich umfassend mit der Modellierung von Einwilligungen und Einwilligungsvorlagen befasst.
|
|
web
|
ig.fhir.de
|
Die Profile Questionnaire Composed
, Template Frame
und Template Module
basieren auf der FHIR Ressource Questionnaire und dienen der Abbildung des Einwilligungsformulars (hier: MII Broad Consent).
|
|
web
|
ig.fhir.de
|
Die Profile Questionnaire Composed
, Template Frame
und Template Module
basieren auf der FHIR Ressource Questionnaire und dienen der Abbildung des Einwilligungsformulars (hier: MII Broad Consent).
|
|
web
|
ig.fhir.de
|
Die Profile Questionnaire Composed
, Template Frame
und Template Module
basieren auf der FHIR Ressource Questionnaire und dienen der Abbildung des Einwilligungsformulars (hier: MII Broad Consent).
|
|
web
|
ig.fhir.de
|
Das Profil QuestionnaireResponse
bildet den vom Patienten ausgefüllten Fragebogen elektronisch ab. Hier werden die Antworten des Patienten auf den referenzierten Fragebogen (QuestionnaireComposed) des MII Broad Consent dokumentiert.
|
|
web
|
art-decor.org
|
Zur Abbildung der Antworten sollte das Value Set “ MII Consent: Answer ValueSet
” verwendet werden:
|
|
web
|
art-decor.org
|
Die Datenelemente des MII Broad Consent Formulars in Version 1.6d
und 1.6f
sind als Dataset in ART-DECOR modelliert, siehe Abschnitt Datensätze inkl. Beschreibungen
.
|
|
web
|
art-decor.org
|
Die Datenelemente des MII Broad Consent Formulars in Version 1.6d
und 1.6f
sind als Dataset in ART-DECOR modelliert, siehe Abschnitt Datensätze inkl. Beschreibungen
.
|
|
web
|
www.ihe.net
|
Die benötigten Value Sets sind ebenfalls in ART-DECOR modelliert) und mit den entspr. Datenelementen assoziert. Die Kompatibilität zu IHE BPPC (Integrating the Healthcare Enterprise, Profil „Basic Patient Privacy Consent“
) wird über Policies adressiert.
|
|
web
|
art-decor.org
|
Die Operationalisierung bzw. Durchsetzung (Enforcement) der Consent Informationen
wird durch ein einheitliches Policy-Valueset
unterstützt. Dies kann interoperabel in IHE BPPC verwendet werden.
|
|
web
|
github.com
|
Für die KDS-weiten Konformitätsanforderungen siehe die
Konformitätsregeln des Meta-Moduls
;
für die technischen Artefakte siehe Profile
.
|
|
web
|
www.medizininformatik-initiative.de
|
Das Erweiterungsmodul Consent stellt die elektronische Abbildung des MII Consent
bereit, kann darüber hinaus aber auch für die Abbildung weiterer Einwilligungen ermöglichen. Dies ist eine Voraussetzung für die Berücksichtigung des Patientenwillens bei der Verwendung der im Rahmen der Versorgung erfassten medizinischen Daten des Patienten für Forschungszwecke. Die Einwilligung ist vor allem dann erforderlich, wenn der Nutzungszweck über die Forschungsklauseln der jeweiligen anwendbaren Gesetze hinausgeht.
|
|
web
|
www.medizininformatik-initiative.de
|
Eine wichtige Maßzahl für die medizinische Forschung ist u.a., wie viele Patienten bestimmten Kriterien genügen (Fallzahl) und ob diese Patienten der Verwendung ihrer Daten für Forschungszwecke zugestimmt haben. Entsprechende Anfragen können nur effizient elektronisch verarbeitet bzw. beantwortet werden, wenn der Einwilligungsstatus elektronisch geprüft werden kann. Derartige Fallzahlabfragen unter Berücksichtigung des Einwilligungsstatus sind essentiell für Anwendungsfälle, wie ‘Fallzahl-Schätzung’, ‘Feasibility-Abfragen’ und ‘Data Sharing’, für die MII übergreifenden Use Cases CORD und POLAR, sowie für die Use Cases
der MII-Konsortien
.
|
|
web
|
www.medizininformatik-initiative.de
|
Eine wichtige Maßzahl für die medizinische Forschung ist u.a., wie viele Patienten bestimmten Kriterien genügen (Fallzahl) und ob diese Patienten der Verwendung ihrer Daten für Forschungszwecke zugestimmt haben. Entsprechende Anfragen können nur effizient elektronisch verarbeitet bzw. beantwortet werden, wenn der Einwilligungsstatus elektronisch geprüft werden kann. Derartige Fallzahlabfragen unter Berücksichtigung des Einwilligungsstatus sind essentiell für Anwendungsfälle, wie ‘Fallzahl-Schätzung’, ‘Feasibility-Abfragen’ und ‘Data Sharing’, für die MII übergreifenden Use Cases CORD und POLAR, sowie für die Use Cases
der MII-Konsortien
.
|
|
web
|
ig.fhir.de
|
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
.
|
|
web
|
www.bfarm.de
|
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.
|
|
web
|
ig.fhir.de
|
Implementation Guide der Arbeitsgruppe Einwilligungsmanagement des Interop-Forum, Version 1.0
|
|
web
|
art-decor.org
|
Kerndatensatzbeschreibung im ART-DECOR
|
|
web
|
www.medizininformatik-initiative.de
|
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
.
|
|
web
|
art-decor.org
|
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
.
|
|
web
|
ebooks.iospress.nl
|
Im IG der HL7-D AG Einwilligungsmanagement
und der korrespondierenden Publikation
wird die Bedeutung des Parameters ResultType
umfassend erläutert.
|
|
web
|
ths-greifswald.de
|
Das Einwilligungsmanagement gICS
stellt die aktuelle Referenzimplementierung
des HL7-D FHIR Standards für Einwilligungsmanagement (Version 2.0) dar.
|
|
web
|
ebooks.iospress.nl
|
Das Einwilligungsmanagement gICS
stellt die aktuelle Referenzimplementierung
des HL7-D FHIR Standards für Einwilligungsmanagement (Version 2.0) dar.
|
|
web
|
ths-greifswald.de
|
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.
|
|
web
|
www.ths-greifswald.de
|
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.
|
|
web
|
bmcmedinformdecismak.biomedcentral.com
|
Das MII KDS Modul Consent ist ein Basismodul des Kerndatensatzes (KDS) der Medizininformatik-Initiative (MII). Es setzt auf den publizierten Vorarbeiten der MII Taskforce Consent Umsetzung
auf.
|
|
web
|
www.medizininformatik-initiative.de
|
Dabei orientiert sich das Modul Consent für die Abbildung des MII Broad Consent
an den
FHIR R4 Profilen der AG Einwilligungsmanagement des Interop-Forums
zur Repräsentation von Formulardaten (Questionnaire, QuestionnaireResponse) und Einwilligungen (Consent).
|
|
web
|
ig.fhir.de
|
FHIR R4 Profilen
der AG Einwilligungsmanagement
des Interop-Forums
|
|
web
|
wiki.hl7.de
|
FHIR R4 Profilen
der AG Einwilligungsmanagement
des Interop-Forums
|
|
web
|
wiki.hl7.de
|
FHIR R4 Profilen
der AG Einwilligungsmanagement
des Interop-Forums
|
|
web
|
github.com
|
GitHub: https://github.com/medizininformatik-initiative/kerndatensatzmodul-consent/issues
|
|
web
|
creativecommons.org
|
|
|
img
|
licensebuttons.net
|
|
|
web
|
creativecommons.org
|
Diese Arbeit ist lizensiert unter der Creative Commons Attribution 4.0 International License
.
|
|
web
|
art-decor.org
|
formularbasierte Beschreibung MII Dataset, Concept 'Consent'
|
|
web
|
art-decor.org
|
tabellarische Beschreibung MII Dataset, Concept 'Consent'
|
|
web
|
ig.fhir.de
|
Die Arbeiten der Kerndatensatzspezifikationen basieren, wo möglich, auf internationalen Standards und Terminologien. Insbesondere auf den Profilierungs-Vorarbeiten der AG Einwilligungsmanagement zum FHIR Consent
.
|
|
web
|
ig.fhir.de
|
Neben Consent
, Provenance
und DocumentReference
sind weitere Profile für den Umgang mit Einwilligungen und Einwilligungsvorlagen relevant, die unverändert aus dem Implementierungsleitfaden Einwilligungsmanagement
übernommen werden.
|
|
web
|
ig.fhir.de
|
Organization
|
|
web
|
ig.fhir.de
|
ResearchStudy
|
|
web
|
ig.fhir.de
|
Patient
|
|
web
|
ig.fhir.de
|
QuestionnaireResponse
|
|
web
|
ig.fhir.de
|
QuestionnaireComposed
|
|
web
|
ig.fhir.de
|
TemplateFrame
|
|
web
|
ig.fhir.de
|
TemplateModule
|
|
web
|
ig.fhir.de
|
Im Kontext der Suche nach Consent-Ressourcen sind nach HL7-D Standard für Einwilligungsmanagement
(Version 2.0) folgende Suchparameter zur Filterung von Consent-Ressourcen definiert. Diese werden ebenfalls durch den MII KDS Consent unterstützt. Konkrete Beispiele sind im IG der HL7-D Arbeitsgruppe dokumentiert.
|
|
web
|
www.medizininformatik-initiative.de
|
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.
|
|
web
|
medizininformatik-initiative.github.io
|
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.
|
|
web
|
ig.fhir.de
|
Da auch die FHIR Consent Ressource keine personenidentifizierende Informationen
der einwilligenden Person enthält, sollte der
pseudonyme Personenbezug
über entsprechende
pseudonyme Identifier
hergestellt werden. Etwaige personenidentifizierende Informationen (z.B. Geburtsdatum, Geschlecht,Anschrift) sowie Referenzen, z.B. auf (Klartext-) Patienten-Profile, sollten vor Ausleitung geeignet ersetzt werden.
|
|
web
|
ig.fhir.de
|
Da auch die FHIR Consent Ressource keine personenidentifizierende Informationen
der einwilligenden Person enthält, sollte der
pseudonyme Personenbezug
über entsprechende
pseudonyme Identifier
hergestellt werden. Etwaige personenidentifizierende Informationen (z.B. Geburtsdatum, Geschlecht,Anschrift) sowie Referenzen, z.B. auf (Klartext-) Patienten-Profile, sollten vor Ausleitung geeignet ersetzt werden.
|
|
web
|
ig.fhir.de
|
Technisch gesehen können Patienten-Ressourcen und abgeleitete Profile, wie z.B. die Profile der AG Einwilligungsmanagement
oder der MII
verwendet werden.
|
|
web
|
ig.fhir.de
|
Technisch gesehen können Patienten-Ressourcen und abgeleitete Profile, wie z.B. die Profile der AG Einwilligungsmanagement oder der MII verwendet werden.
Um Pseudonyme, Fallnummern, etc. unterscheiden zu können, ist es unabhängig davon erforderlich eine Kategorisierung des verwendeten Identifiers mittels patient.identifier.type
vorzunehmen.
|
|
web
|
ig.fhir.de
|
Die FHIR Consent Ressource enthält keine Dokumenten-Scans und/oder Unterschriften
. Ist eine Übermittlung je nach Anwendungsfall erforderlich, sind separate Ressourcen gemäß den Vorgaben der AG Einwilligungsmanagement
zu erstellen (Consent Bundles).
|
|
web
|
github.com
|
Übersetzte Seiten liegen unter input/translations/en/pagecontent/
(gleicher
Dateiname wie die deutsche Seite); Ressourcen-Übersetzungen als .po
-Dateien
unter input/translations/en/
. Details:
docs/recipes/add-translation.md
in diesem Repository.
|
|
web
|
ig.fhir.de
|
Die Einwilligung wird in einem konkreten Kontext (z.B. MII) erhoben, was in FHIR in Form einer Referenz auf die verantwortliche Organisation ( Organization
) und/oder zu einem Forschungsprojekt ( ResearchStudy
) modelliert wird.
|
|
web
|
ig.fhir.de
|
Die Einwilligung wird in einem konkreten Kontext (z.B. MII) erhoben, was in FHIR in Form einer Referenz auf die verantwortliche Organisation ( Organization
) und/oder zu einem Forschungsprojekt ( ResearchStudy
) modelliert wird.
|
|
web
|
ig.fhir.de
|
Die Provenance-Resource beschreibt die Herkunft der Einwilligungsinhalte (u.a. Unterschriften) und verknüpft diese mit den beteiligten Personen ( Patient
, Consent Witness) und eventuell vorhandenen Dokumenten-Scans ( DocumentReference
). Ebenso können die für die Erhebung genutzten Anwendungssysteme genannt (display) bzw. referenziert werden, sowie im Anwendungssystem geltende Patienten-Identifier.
|
|
web
|
github.com
|
Releases folgen dem
Module Release Workflow
:
Die Version wird im Release-Branch angehoben, der Changelog-Eintrag geschrieben,
die Validierungs-Workflows laufen auf dem Release-Pull-Request, und nach dem
Merge wird das Release getaggt.
|
|
web
|
www.netzwerk-universitaetsmedizin.de
|
|
|
web
|
github.com
|
Conformance
|
|
web
|
github.com
|
Conformance
|
|
web
|
github.com
|
General Requirements
|
|
web
|
github.com
|
Must Support
|
|
web
|
github.com
|
Handling Missing Data
|
|
web
|
www.netzwerk-universitaetsmedizin.de
|
IG © 2019+ NUM-DIZ
.
Package de.medizininformatikinitiative.kerndatensatz.consent#2027.0.0-ballot based on FHIR 4.0.1
.
Generated 2026-09-14
Links: Table of Contents |
QA Report
| netzwerk-universitaetsmedizin.de
| medizininformatik-initiative.de
| Legal notice
HL7®, FHIR® and the FHIR flame design are registered trademarks of Health Level Seven International. Their use does not constitute endorsement by HL7.
|
|
web
|
www.netzwerk-universitaetsmedizin.de
|
Links: Table of Contents
|
QA Report
| netzwerk-universitaetsmedizin.de
| medizininformatik-initiative.de
| Legal notice
HL7®, FHIR® and the FHIR flame design are registered trademarks of Health Level Seven International. Their use does not constitute endorsement by HL7.
|
|
web
|
www.medizininformatik-initiative.de
|
Links: Table of Contents
|
QA Report
| netzwerk-universitaetsmedizin.de
| medizininformatik-initiative.de
| Legal notice
HL7®, FHIR® and the FHIR flame design are registered trademarks of Health Level Seven International. Their use does not constitute endorsement by HL7.
|
|
web
|
www.netzwerk-universitaetsmedizin.de
|
Links: Table of Contents
|
QA Report
| netzwerk-universitaetsmedizin.de
| medizininformatik-initiative.de
| Legal notice
HL7®, FHIR® and the FHIR flame design are registered trademarks of Health Level Seven International. Their use does not constitute endorsement by HL7.
|
|
web
|
github.com
|
Where the versions come from.
Every package in the table is pinned
directly in
sushi-config.yaml
( dependencies:
) — including hl7.terminology.r4
(THO) and
hl7.fhir.uv.extensions.r4
, and those two deliberately so: the IG
Publisher's
automatic-packages rule
consults only this guide's own
dependency list, so without a direct pin
every build would silently inject the latest THO/extensions release — a
version pinned by the MII meta package alone cannot control the build
(verified in the publisher source at the pinned release). A weekly check
warns when these two pins drift from what the pinned meta package ships,
and the exact versions a concrete build used are recorded in its
qa-versions.json
output.
|
|
web
|
github.com
|
Expansion parameters are query parameters that can be passed to a ValueSet
$expand
operation to control how the ValueSet is expanded — that is, how the
full list of codes is generated from the ValueSet definition. The
IG Parameters
used for this IG are declared in
sushi-config.yaml
( parameters:
). A module that pins its expansion parameters through a CRMI
manifest additionally links the generated Parameters
resource from here (see
the commented manifest blocks in sushi-config.yaml
and the Metadata Overview
page, if the module keeps it).
|
|
web
|
ig.fhir.de
|
Based on the recommendations
of the AG Einwilligungsmanagement, the profile MIIConsentDocumentReference
targets a real, existing document related to the consent document.
|
|
web
|
ig.fhir.de
|
Only the differences to the base profile
are explained below.
|
|
web
|
www.medizininformatik-initiative.de
|
When a person is enrolled in a study (including an MII use case), a consent is collected for that person on the basis of the MII Broad Consent model texts
, and the corresponding consent documents are documented in a structured way at the respective site according to the specifications of the MII Task Force Consent Umsetzung
.
|
|
web
|
art-decor.org
|
When a person is enrolled in a study (including an MII use case), a consent is collected for that person on the basis of the MII Broad Consent model texts
, and the corresponding consent documents are documented in a structured way at the respective site according to the specifications of the MII Task Force Consent Umsetzung
.
|
|
web
|
ig.fhir.de
|
On the basis of these consent documents, the FHIR Consent resource is generated automatically. The project context
is preserved.
|
|
web
|
art-decor.org
|
To ensure the exchangeability of the operationalized consent contents beyond FHIR as well, a uniform PolicyValueSet for the semantic representation
of the statements contained in the MII Broad Consent was agreed with the MII AG Consent
in December 2021 and documented in ART-DECOR
(policy OIDs).
|
|
web
|
ig.fhir.de
|
Must-support per the specifications of the AG Einwilligungsmanagement
, but optional
|
|
web
|
ig.fhir.de
|
ResultType per ResultType
. At least document
and consent-status
should be supported. If document
is given as the ResultType, the kind of (source) document must also be given in the templateType slice.
|
|
web
|
ig.fhir.de
|
Categorization per TemplateType
. Serves as an informal element for differentiating between consent, withdrawal, objection and refusal.
|
|
web
|
art-decor.org
|
Unique OID per the TFCU specification
|
|
web
|
www.ths-greifswald.de
|
Per the specifications of the MII AG Consent, the patient's consent generally ends after 30 years. Consents of minors (the person affected by the consent) are a special case. In the case of consents for minors
, which may have been filled in on their behalf by the respective legal guardians, the consent ends when the affected person reaches the age of majority
. This must be implemented accordingly in the technical systems. Reference implementations
exist.
|
|
web
|
www.medizininformatik-initiative.de
|
The withdrawal template (compatible with MII BC 1.7.2)
is also intended for withdrawing consents of minors, since these are usually likewise filled in by the legal guardians.
|
|
web
|
ig.fhir.de
|
Based on the recommendations
of the AG Einwilligungsmanagement, the profile MIIConsentProvenance
describes the provenance information of a consent document.
|
|
web
|
ig.fhir.de
|
Only the differences to the base profile
are explained below.
|
|
web
|
keepachangelog.com
|
This page records the changes between the published versions of the
Consent
module, most recent version first. It follows
Keep a Changelog
and the
KDS CalVer scheme described on the
Versioning
page.
|
|
web
|
github.com
|
The module's first release from the IG Publisher toolchain. It builds on the
release package 2027.0.0-ballot.rc1 and adds the QA corrections from pull
requests #135
to #141
plus the parent-package bump.
|
|
web
|
github.com
|
The module's first release from the IG Publisher toolchain. It builds on the
release package 2027.0.0-ballot.rc1 and adds the QA corrections from pull
requests #135
to #141
plus the parent-package bump.
|
|
web
|
github.com
|
Added
— four synthetic reference-target instances (two Patient
, two
ResearchStudy
) so the examples' references resolve ( #137
).
|
|
web
|
github.com
|
Changed
— the category
slices resultType
and templateType
get
decidable pattern
discriminators ( #140
).
|
|
web
|
github.com
|
Fixed
— example policy displays aligned with the CodeSystem
( #136
); CodeSystem.count
corrected to the actual concept count
( #139
); the Answer ValueSet reduced to a bare all-system
include
( #138
); example 89f494a3
switched to the defined
version-modules CodeSystem ( #135
).
|
|
web
|
github.com
|
Fixed
— example policy displays aligned with the CodeSystem
( #136
); CodeSystem.count
corrected to the actual concept count
( #139
); the Answer ValueSet reduced to a bare all-system
include
( #138
); example 89f494a3
switched to the defined
version-modules CodeSystem ( #135
).
|
|
web
|
github.com
|
Fixed
— example policy displays aligned with the CodeSystem
( #136
); CodeSystem.count
corrected to the actual concept count
( #139
); the Answer ValueSet reduced to a bare all-system
include
( #138
); example 89f494a3
switched to the defined
version-modules CodeSystem ( #135
).
|
|
web
|
github.com
|
Fixed
— example policy displays aligned with the CodeSystem
( #136
); CodeSystem.count
corrected to the actual concept count
( #139
); the Answer ValueSet reduced to a bare all-system
include
( #138
); example 89f494a3
switched to the defined
version-modules CodeSystem ( #135
).
|
|
web
|
github.com
|
BREAKING: Changed
— resource ids modernised to the canonical tails
( #141
).
-
What exactly changed:
14 artifacts carry new
id
values — the three
profiles ( 56375452-…
→ mii-pr-consent-documentreference
, e0e166b4-…
→
mii-pr-consent-einwilligung
, f675b1e8-…
→ mii-pr-consent-provenance
),
the three value sets ( 2.16.840.…11.30--20210323234509
→
mii-vs-consent-answer
, 2.16.840.…11.36--20230331232804
→
mii-vs-consent-policy
, 88464c5b-…
→ mii-vs-consent-signaturetypes
)
and the six search parameters, which carried
no id at all
in the
previous package (now mii-sp-consent-…
). The canonical URLs are
unchanged
; the ids now follow the MII naming convention (kebab-case of
name
).
-
What this means for existing data:
instance data is not
affected.
Examples and production data reference the profiles through the canonical
URL in
meta.profile
, and that does not change — data that validated
against 2027.0.0-ballot.rc1 still validates unchanged.
-
What implementers should do:
every reference that addresses an artifact
by its id
rather than by its canonical URL must be updated — in
particular REST reads of the form
[base]/StructureDefinition/e0e166b4-…
,
artifact ids stored in registries, and deep links into the guide's artifact
pages (whose file names follow the id). No automated migration path is
provided; the old → new mapping is the list above.
|
|
web
|
github.com
|
official release
2027.0.0-ballot.rc1
|
|
web
|
github.com
|
Changed
— migration of the guide onto the
MII KDS module template
v0.13.2 (IG Publisher toolchain, DE-first language model, template page
structure); content-identical to release 2026.0.0
(profiles, terminology
and examples unchanged; evidence: migration-log/
on this branch). All
artefact versions harmonized to the package version 2027.0.0-ballot.rc1
(previously divergent per artefact, e.g. 1.0.9/1.6.0/1.1.0).
|
|
web
|
mii-termserv.de
|
Important:
CodeSystem resources of external terminologies (e.g. ICD-10-GM, OPS,
SNOMED CT) are not
published in this module; they are obtained from the
central KDS terminology server (SU-TermServ):
https://mii-termserv.de/
.
|
|
web
|
ig.fhir.de
|
The AG Einwilligungsmanagement
has dealt comprehensively with the modeling of consents and consent templates.
|
|
web
|
ig.fhir.de
|
The profiles Questionnaire Composed
, Template Frame
and Template Module
are based on the FHIR resource Questionnaire and serve to represent the consent form (here: MII Broad Consent).
|
|
web
|
ig.fhir.de
|
The profiles Questionnaire Composed
, Template Frame
and Template Module
are based on the FHIR resource Questionnaire and serve to represent the consent form (here: MII Broad Consent).
|
|
web
|
ig.fhir.de
|
The profiles Questionnaire Composed
, Template Frame
and Template Module
are based on the FHIR resource Questionnaire and serve to represent the consent form (here: MII Broad Consent).
|
|
web
|
ig.fhir.de
|
The profile QuestionnaireResponse
electronically represents the questionnaire completed by the patient. Here the patient's answers to the referenced questionnaire (QuestionnaireComposed) of the MII Broad Consent are documented.
|
|
web
|
art-decor.org
|
To represent the answers, the value set " MII Consent: Answer ValueSet
" should be used:
|
|
web
|
art-decor.org
|
The data elements of the MII Broad Consent form in versions 1.6d
and 1.6f
are modeled as a dataset in ART-DECOR; see the section Datasets incl. descriptions
.
|
|
web
|
art-decor.org
|
The data elements of the MII Broad Consent form in versions 1.6d
and 1.6f
are modeled as a dataset in ART-DECOR; see the section Datasets incl. descriptions
.
|
|
web
|
www.ihe.net
|
The required value sets are likewise modeled in ART-DECOR) and associated with the corresponding data elements. Compatibility with IHE BPPC (Integrating the Healthcare Enterprise, "Basic Patient Privacy Consent" profile
) is addressed via policies.
|
|
web
|
art-decor.org
|
The operationalization and enforcement of the consent information
is supported by a uniform policy value set
. This can be used interoperably in IHE BPPC.
|
|
web
|
github.com
|
For the KDS-wide conformance requirements, see the
conformance rules of the Meta module
;
for the technical artifacts, see Profiles
.
|
|
web
|
www.medizininformatik-initiative.de
|
The Consent extension module provides the electronic representation of the MII Consent
and, beyond that, can also enable the representation of further consents. This is a prerequisite for taking the patient's will into account when the patient's medical data collected in the course of care is used for research purposes. Consent is required above all when the purpose of use goes beyond the research clauses of the respective applicable laws.
|
|
web
|
www.medizininformatik-initiative.de
|
An important measure for medical research is, among other things, how many patients meet certain criteria (case count) and whether these patients have consented to the use of their data for research purposes. Such queries can only be processed and answered efficiently by electronic means if the consent status can be checked electronically. Case-count queries of this kind that take the consent status into account are essential for use cases such as 'case-count estimation', 'feasibility queries', and 'data sharing', for the MII cross-consortium use cases CORD and POLAR, as well as for the use cases
of the MII consortia
.
|
|
web
|
www.medizininformatik-initiative.de
|
An important measure for medical research is, among other things, how many patients meet certain criteria (case count) and whether these patients have consented to the use of their data for research purposes. Such queries can only be processed and answered efficiently by electronic means if the consent status can be checked electronically. Case-count queries of this kind that take the consent status into account are essential for use cases such as 'case-count estimation', 'feasibility queries', and 'data sharing', for the MII cross-consortium use cases CORD and POLAR, as well as for the use cases
of the MII consortia
.
|
|
web
|
ig.fhir.de
|
To establish the relation between person and consent, the consent is assigned at least one unique person identifier (base module: Person). As a rule, this is a pseudonymous identifier
.
|
|
web
|
www.bfarm.de
|
In version V1 of the guidance document
on the patient information & declaration of participation for the "Modellvorhaben Genomsequenzierung bei seltenen und bei onkologischen Erkrankungen"
pursuant to § 64e SGB, chapter 2.1.4 Research Consent recommends using the MII Broad Consent from version 1.6d onwards, which in the legal sense corresponds at least to the base version without additional modules.
|
|
web
|
ig.fhir.de
|
Implementation Guide of the Consent Management working group of the Interop-Forum, Version 1.0
|
|
web
|
art-decor.org
|
Core data set description in ART-DECOR
|
|
web
|
www.medizininformatik-initiative.de
|
The present specification was designed on the basis of the description of the MII core data set in the version dated 10.3.2017 ( PDF
), as well as the data set description in ART-DECOR
.
|
|
web
|
art-decor.org
|
The present specification was designed on the basis of the description of the MII core data set in the version dated 10.3.2017 ( PDF
), as well as the data set description in ART-DECOR
.
|
|
web
|
ebooks.iospress.nl
|
The significance of the ResultType
parameter is explained comprehensively in the IG of the HL7-D AG Einwilligungsmanagement
and the corresponding publication
.
|
|
web
|
ths-greifswald.de
|
The consent management system gICS
constitutes the current reference implementation
of the HL7-D FHIR standard for consent management (version 2.0).
|
|
web
|
ebooks.iospress.nl
|
The consent management system gICS
constitutes the current reference implementation
of the HL7-D FHIR standard for consent management (version 2.0).
|
|
web
|
ths-greifswald.de
|
Sites using the gICS consent management system
should follow the precise
vendor recommendations
for metrics determination
as well as when providing the Consent resources for the FDPG
.
|
|
web
|
www.ths-greifswald.de
|
Sites using the gICS consent management system
should follow the precise
vendor recommendations
for metrics determination
as well as when providing the Consent resources for the FDPG
.
|
|
web
|
bmcmedinformdecismak.biomedcentral.com
|
The MII KDS module Consent is a base module of the Core Data Set (KDS) of the Medical Informatics Initiative (MII). It builds on the published preliminary work of the MII Taskforce Consent Umsetzung
.
|
|
web
|
www.medizininformatik-initiative.de
|
For the representation of the MII Broad Consent
, the Consent module follows the
FHIR R4 profiles of the AG Einwilligungsmanagement of the Interop Forum
for representing form data (Questionnaire, QuestionnaireResponse) and consents (Consent).
|
|
web
|
ig.fhir.de
|
FHIR R4 profiles
of the AG Einwilligungsmanagement
of the Interop Forum
|
|
web
|
wiki.hl7.de
|
FHIR R4 profiles
of the AG Einwilligungsmanagement
of the Interop Forum
|
|
web
|
wiki.hl7.de
|
FHIR R4 profiles
of the AG Einwilligungsmanagement
of the Interop Forum
|
|
web
|
creativecommons.org
|
This work is licensed under the Creative Commons Attribution 4.0 International License
.
|
|
web
|
art-decor.org
|
form-based description MII Dataset, Concept 'Consent'
|
|
web
|
art-decor.org
|
tabular description MII Dataset, Concept 'Consent'
|
|
web
|
ig.fhir.de
|
The work on the core data set specifications is based, wherever possible, on international standards and terminologies — in particular on the preparatory profiling work of the AG Einwilligungsmanagement on FHIR Consent
.
|
|
web
|
ig.fhir.de
|
In addition to Consent
, Provenance
, and DocumentReference
, further profiles are relevant for handling consents and consent templates; they are adopted unchanged from the Einwilligungsmanagement implementation guide
.
|
|
web
|
ig.fhir.de
|
In the context of searching for Consent resources, the following search parameters for filtering Consent resources are defined by the HL7-D Standard for Consent Management
(version 2.0). These are likewise supported by the MII KDS Consent. Concrete examples are documented in the IG of the HL7-D working group.
|
|
web
|
www.medizininformatik-initiative.de
|
The
overarching data protection concept of the Medical Informatics Initiative
governs how patient data may be processed for research
across the network of Data Integration Centers:
the legal basis (the MII Broad Consent), the roles of the
Data Integration Centers and the Use & Access Committees, as well as the
cross-site application scenarios (feasibility queries, distributed
analyses, provision of data and biosamples). Everything this module
specifies stays within this framework — this guide adds
no processing purpose of its own.
|
|
web
|
medizininformatik-initiative.github.io
|
How data leaving a Data Integration Center is de-identified
in practice is specified by
DIMP (De-Identification — Minimisation — Pseudonymisation)
in the Data Portal documentation: direct identifiers are
removed, data elements not needed by the approved project are dropped, and
identifying values are replaced with project-specific pseudonyms
(FHIR Pseudonymizer configuration). The profiles of this module describe the
data before
DIMP is applied; which elements reach a concrete
data delivery is decided per project by the DIMP configuration,
not by this guide.
|
|
web
|
ig.fhir.de
|
Since the FHIR Consent resource likewise contains no person-identifying information
about the consenting person, the
pseudonymous person reference
should be established via appropriate
pseudonymous identifiers
. Any person-identifying information (e.g. date of birth, gender, address) as well as references, e.g. to (clear-text) patient profiles, should be suitably replaced before data are exported.
|
|
web
|
ig.fhir.de
|
Since the FHIR Consent resource likewise contains no person-identifying information
about the consenting person, the
pseudonymous person reference
should be established via appropriate
pseudonymous identifiers
. Any person-identifying information (e.g. date of birth, gender, address) as well as references, e.g. to (clear-text) patient profiles, should be suitably replaced before data are exported.
|
|
web
|
ig.fhir.de
|
Technically, Patient resources and derived profiles can be used, such as the profiles of the AG Einwilligungsmanagement
or the MII
.
|
|
web
|
ig.fhir.de
|
Technically, Patient resources and derived profiles can be used, such as the profiles of the AG Einwilligungsmanagement or the MII.
Independently of this, in order to be able to distinguish pseudonyms, case numbers, etc., a categorisation of the identifier used is required via patient.identifier.type
.
|
|
web
|
ig.fhir.de
|
The FHIR Consent resource contains no document scans and/or signatures
. If transmission is required for a given use case, separate resources must be created in accordance with the specifications of the AG Einwilligungsmanagement
(Consent Bundles).
|
|
web
|
github.com
|
Translated pages live under input/translations/en/pagecontent/
(same file name
as the German page); resource translations are .po
files under
input/translations/en/
. Details:
docs/recipes/add-translation.md
in this repository.
|
|
web
|
ig.fhir.de
|
The consent is obtained in a concrete context (e.g. MII), which is modeled in FHIR in the form of a reference to the responsible organization ( Organization
) and/or to a research project ( ResearchStudy
).
|
|
web
|
ig.fhir.de
|
The consent is obtained in a concrete context (e.g. MII), which is modeled in FHIR in the form of a reference to the responsible organization ( Organization
) and/or to a research project ( ResearchStudy
).
|
|
web
|
ig.fhir.de
|
The Provenance resource describes the origin of the consent contents (including signatures) and links them to the persons involved ( Patient
, Consent Witness) and to any existing document scans ( DocumentReference
). Likewise, the application systems used for capturing the consent can be named (display) or referenced, as well as the patient identifiers valid in the application system.
|
|
web
|
github.com
|
Releases follow the
Module Release Workflow
:
the version is raised in the release branch, the changelog entry is written, the
validation workflows run on the release pull request, and the release is tagged
after the merge.
|
