Profil Consent

Ziel

Im Krankenhaus werden verschiedene Arten von Einwilligungen eingeholt.

  • Datenverarbeitungsvereinbarung: Durch die Einholung des Consent (Einwilligung) des Patienten, erfolgt eine rechtliche Absicherung darüber, dass der Patient über die Nutzung seiner Daten nach EU-DSGVO aufgeklärt wurde und sich mit den Nutzungsbedingungen einverstanden erklärt. Somit wird der Datenverarbeitung für den ausgegebene Verwendungszweck zugestimmt.
  • Behandlungseinwilligung, d.h. z.B.: Aufklärung einer Operation, dies schließt eine Ablehnung einer Behandlung mit ein.
  • Forschungseinwilligungen, z.B. MII-Broad Consent
Veröffentlichung
Datum 30.07.2025
Version 1.0.0
Status Active
Nutzungsraum DE

Verwendetes FHIR-Profil

MII Consent:

https://www.medizininformatik-initiative.de/Kerndatensatz/Modul_Consent/IGMIIKDSModulConsent-TechnischeImplementierung-FHIRProfile-Consent.html

PDF-Anhänge (besonders wichtig bei Medizinischen Aufklärungen):

Scans von Aufklärungen werden an die Consent-Ressource über eine Provenance Resource angehängt. Diese ist über eine DocumentReference mit der base64 encodierten PDF-Datei verknüpft. Auf diese Weise ist sichergestellt, dass die PDFs nur einmal referenziert werden.

Name Flags Card. Type Description & Constraints Klinik Patient
1. id S Σ 0..1 string The metadata about the resource. This is content that is maintained by the infrastructure. Changes to the content might not always be associated with version changes to the resource. Initiale Erzeugung Nicht relevant
2. meta S Σ 0..1 Meta The metadata about the resource. This is content that is maintained by the infrastructure. Changes to the content might not always be associated with version changes to the resource. Nicht relevant Nicht relevant
3. extension I 0..* Extension Nicht relevant Nicht relevant
4. identifier Σ 0..* Identifier Nicht relevant Nicht relevant
5. status S Σ ?! 1..1 codeBinding The Consent Directive that is pointed to might be in various lifecycle states, e.g., a revoked Consent Directive. änderbar einsehbar
6. scope Σ ?! 1..1 CodeableConceptBinding A selector of the type of consent being presented: ADR, Privacy, Treatment, Research. This list is now extensible. änderbar einsehbar
7. category S Σ 2..2 CodeableConceptBinding A classification of the type of consents found in the statement. This element supports indexing and retrieval of consent statements. nicht relevant
8. patient S Σ I 1..1 Reference(ConsentManagementPatient) The patient/healthcare consumer to whom this consent applies. einsehbar
9. dateTime S Σ 1..1 dateTime Dieser Zeitpunkt sollte in der Praxis, zumindest bei vollelektronischer Verarbeitung, identisch mit dem Unterschriftsdatum des Fragebogens sein (Provenance.signature.when des Patienten) änderbar einsehbar
10. performer Σ I 0..* Reference(Organization | Patient | Practitioner | RelatedPerson | PractitionerRole) nicht relevant
11. organization S Σ I 0..* Reference(Organization) Dies ist die Organisation, die den Consent erfasst hat. einsehbar
12. source[x] S Σ 0..1 Reference The source on which this consent statement is based. The source might be a scanned original paper form, or a reference to a consent that links back to such a source, a reference to a document repository (e.g. XDS) that stores the original consent document. änderbar einsehbar
13. policy S 1..* BackboneElement The references to the policies that are included in this consent scope. Policies may be organizational, but are often defined jurisdictionally, or in law. nicht relevant
14. policyRule S Σ I 0..1 CodeableConceptBinding A reference to the specific base computable regulation or policy. nicht relevant
15. verification Σ 0..* BackboneElement Whether a treatment instruction (e.g. artificial respiration yes or no) was verified with the patient, his/her family or another authorized person. nicht relevant
16. provision S Σ 0..1 BackboneElement An exception to the base policy of this consent. An exception can be an addition or removal of access permissions. nicht relevant

Provenance Resource

Name Flags Card. Type Description & Constraints Klinik Patient
1. target S Σ I 1..* Reference(ConsentManagementQuestionnaireResponse | ConsentManagementConsent) The Reference(s) that were generated or updated by the activity described in this resource. A provenance can point to more than one target if multiple resources were created/updated by the same activity. einsehbar
2. occurred[x] 0..1 The period during which the activity occurred. nicht relevant
3. recorded S Σ 1..1 instant The instant of time at which the activity was recorded. einsehbar
4. policy 0..* uri Policy or plan the activity was defined by. Typically, a single activity may have multiple applicable policy documents, such as patient consent, guarantor funding, etc. nicht relevant
5. location I 0..1 Reference(Location) Where the activity occurred, if relevant. nicht relevant
6. reason 0..* CodeableConceptBinding The reason that the activity was taking place. nicht relevant
7. activity 0..1 CodeableConceptBinding An activity is something that occurs over a period of time and acts upon or with entities; it may include consuming, processing, transforming, modifying, relocating, using, or generating entities. nicht relevant
8. agent S 1..* BackboneElement An dieser Stelle soll die verwendete Software dokumentiert werden. Über die Form der Dokumentation wird hier keine Aussage getroffen, d.h. auch eine freitextliche Angabe (agent.who.display) ist möglich.Optional können die an der Erstellung der Einwilligung beteiligten Personen und/oder Organisationen hier referenziert werden, sofern im konkreten Anwendungsfall die Referenzierung mittels signature.who nicht ausreicht. nicht relevant
9. entity S 0..* BackboneElement An entity used in this activity. nicht relevant
10. signature S 0..* Signature A digital signature on the target Reference(s). The signer should match a Provenance.agent. The purpose of the signature is indicated. nicht relevant

DocumentReference Resource

Name Flags Card. Type Description & Constraints Klinik Patient
masterIdentifier Σ 0..1 Identifier Document identifier as assigned by the source of the document. This identifier is specific to this version of the document. This unique identifier may be used elsewhere to identify this version of the document. nicht relevant
identifier Σ 0..* Identifier Other identifiers associated with the document, including version independent identifiers. nicht relevant
status S Σ ?! 1..1 code Binding The status of the underlying document. (preliminary | final | amended | entered-in-error) einsehbar
docStatus Σ 0..1 code Binding The status of the underlying document. einsehbar
type Σ 0..1 CodeableConceptBinding Specifies the particular kind of document referenced (e.g. History and Physical, Discharge Summary, Progress Note). This usually equates to the purpose of making the document referenced. einsehbar
category Σ 0..* CodeableConcept A categorization for the type of document referenced - helps for indexing and searching. This may be implied by or derived from the code specified in the DocumentReference.type. einsehbar
subject S Σ I 1..1 Reference(ConsentManagementPatient) Who or what the document is about. The document can be about a person, (patient or healthcare practitioner), a device (e.g. a machine) or even a group of subjects (such as a document about a herd of farm animals, or a set of patients that share a common exposure). einsehbar
date Σ 0..1 instant When the document reference was created. einsehbar
author Σ I 0..* Reference(Practitioner | PractitionerRole | Organization | Device | Patient | RelatedPerson) Identifies who is responsible for adding the information to the document. nicht relevant
authenticator I 0..1 Reference(Practitioner | PractitionerRole | Organization) Which person or organization authenticates that this document is valid. nicht relevant
custodian I 0..1 Reference(Organization) Identifies the organization or group who is responsible for ongoing maintenance of and access to the document. nicht relevant
relatesTo Σ 0..* BackboneElement Relationships that this document has with other document references that already exist. nicht relevant
description Σ 0..1 string Human-readable description of the source document. einsehbar
securityLabel Σ 0..* CodeableConceptBinding A set of Security-Tag codes specifying the level of privacy/security of the Document. Note that DocumentReference.meta.security contains the security labels of the "reference" to the document, while DocumentReference.securityLabel contains a snapshot of the security labels on the document the reference refers to. nicht relevant
content S Σ 1..* BackboneElement The document and format referenced. There may be multiple content element repetitions, each with a different format. einsehbar
context Σ 0..1 BackboneElement The clinical context in which the document was prepared. einsehbar

UML

Source: https://simplifier.net/guide/MedizininformatikInitiative-ModulConsent-ImplementationGuide/IGMIIKDSModulConsent/AnwendungsflleInformationsmodell/UML.guide.md?version=current

Beispiele: https://build.fhir.org/consent-examples.html

General Consent Example:

{
  "resourceType" : "Consent",
  "id" : "consent-example-basic",
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n      <p>\n\t      Authorize Normal access for Treatment\n\t\t\t</p>\n      <p>\n      Patient &quot;Peter James Chalmers (&quot;Jim&quot;)&quot; wishes to have all of the PHI collected at the Burgers University Medical Center available for normal treatment use.\n\t\t\t</p>\n    </div>"
  },
  "status" : "active",
  "category" : [{
    "coding" : [{
      "system" : "http://loinc.org",
      "code" : "59284-0"
    }]
  }],
  "subject" : {
    "reference" : "Patient/example",
    "display" : "Peter James Chalmers"
  },
  "date" : "2018-12-28",
  "controller" : [{
    "reference" : "Organization/f001"
  }],
  "sourceAttachment" : [{
    "title" : "The terms of the consent in lawyer speak."
  }],
  "regulatoryBasis" : [{
    "coding" : [{
      "system" : "http://terminology.hl7.org/CodeSystem/v3-ActCode",
      "code" : "INFA"
    }]
  }],
  "decision" : "deny",
  "provision" : [{
    "period" : {
      "start" : "1964-01-01",
      "end" : "2019-01-01"
    }
  }]
}

Beispiel-FHIR-Ressource (Contract)

ConsentDirective Example: https://build.fhir.org/contract-examples.html

{
  "resourceType" : "Contract",
  "id" : "pcd-example-notThis",
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">The following scenario is based on existing\n      jurisdictional policy and are realized in existing systems in Canada. The default policy is\n      one of implied consent for the provision of care, so these scenarios all deal with withdrawal\n      or withholding consent for that purpose. In other jurisdictions, where an express consent\n      model is used (Opt-In), these would examples would contain the phrase &quot;consent to&quot; rather than\n      &quot;withhold&quot; or &quot;withdraw&quot; consent for. <p> specific to use-case 2. Withhold or withdraw consent\n        for disclosure of a specific record (e.g. Lab Order/Result) </p><p> Patient &quot;P. van de\n        Heuvel&quot; Primary Care Provider, Dr. Philip Primary, has ordered a set of lab test which Adam\n        wishes to keep as private as possible. At the sample collection facility, he indicates that\n        he would like withhold consent to disclose the order and all results associated with that\n        specific order from all other providers </p>\n    </div>"
  },
  "issued" : "2015-11-18",
  "subject" : [{
    "reference" : "Patient/f001",
    "display" : "P. van de Heuvel"
  }],
  "authority" : [{
    "reference" : "Organization/3",
    "display" : "Michigan Health"
  }],
  "domain" : [{
    "reference" : "Location/ukp",
    "display" : "UK Pharmacies"
  }],
  "type" : {
    "coding" : [{
      "system" : "http://loinc.org",
      "code" : "57016-8"
    }]
  },
  "subType" : [{
    "coding" : [{
      "system" : "http://www.infoway-inforoute.ca.org/Consent-subtype-codes",
      "code" : "Opt-In",
      "display" : "Default Authorization with exceptions."
    }]
  }],
  "term" : [{
    "identifier" : {
      "system" : "http://example.org/fhir/term-items",
      "value" : "3347689"
    },
    "issued" : "2015-11-01",
    "applies" : {
      "start" : "2015-11-18"
    },
    "type" : {
      "coding" : [{
        "system" : "http://example.org/fhir/consent-term-type-codes",
        "code" : "withhold-identified-object-and-related",
        "display" : "Withhold the identified object and any other resources that are related to this object."
      }]
    },
    "offer" : {
      "topic" : {
        "reference" : "ServiceRequest/lipid"
      },
      "text" : "Withhold this order and any results or related objects from any provider."
    }
  }],
  "friendly" : [{
    "contentAttachment" : {
      "title" : "The terms of the consent in friendly consumer speak."
    }
  }],
  "legal" : [{
    "contentAttachment" : {
      "title" : "The terms of the consent in lawyer speak."
    }
  }]
}

Organisatorische Regelungen für die Befüllung des FHIR-Profils

Herausforderungen

  • Eindeutige Zuordnung zu Patienten mittels ID.

  • Übersichtliche Darstellung ermöglichen, welchen Datenverarbeitungszwecken zugestimmt wurden und welchen nicht.

    • Bsp. #1: Nur behandelnder Arzt darf Daten einsehen
    • Bsp. #2: Dürfen Daten nur für eine bestimmte Studie verwendet werden, oder dürfen sie auch für andere (Folge-) Studien verwendet werden
  • Die Interaktion des Profils mit den Patienten ist eine implizite Information, die möglicherweise auf andere Weise vermittelt werden soll. Z.B. könnte eine Befund zur Notwendigkeit einer OP führen und der Consent für die OP den Patienten darüber erst informieren. Die Prozesse sind deswegen so zu gestalten, dass erst nach expliziter oder ggf. impliziter Freigabe der Consent abgefragt wird.

  • Die ggf. auch teilweise Rücknahme der Einwilligung des Consent muss in Prozessen abgebildet werden.

  • Medizinische Einwilligungen sind im Inhalt häufig komplex und sehr individuell, es wird deshalb kein Anspruch erhoben, den Inhalt der medizinischen Einwilligungen zu modellieren. Es wird sich deshalb auf eine Beigabe der Aufklärung als PDF (auch im Sinne des Patientenrechtegesetzes) fokussiert. Eine detailliertere Spezifikation nach Inhalten kann ggf. in der Zukunft erfolgen.

  • In manchen Fällen kann eine Notwendigkeit entstehen, Verträge mit Aufklärungen zu koppeln (z.B.: bei kombinierten Dokumenten - Behandlungsvertrag/Datenschutzfreigabe)

  • Freigabemanagement: Es könnte vorkommen, dass vom Patienten nicht unterschriebene Aufklärungen versehentlich (z.B. im Rahmen einer OP-Vorbereitung) digitalisiert und an den Patienten verschickt werden.

Lösungen

  • Broad Consent Modell nach MII-Schema?
  • Einwilligungen können an Verträge gebunden werden über ‘legallyBindingReference’ auf die DocumentReference eines gescanten Aufklärungsbogens.
  • An einem Krankenhaus muss im Rahmen der Definition des Aufklärungsprozesses definiert werden, in welchem Status ein Dokument an den Patienten geschickt werden darf.

Validierungsregeln

Technische FHIR-Validierung

Die Resourcen müssen auf Korrektheit validiert werden (Überprüfung der Syntax).

Ein Consent benötigt eine Provenance Resource für die Validierung. In der Provenance Resource ist die digitale Unterschrift oder der Scan des Papierdokumentes referenziert, eines von beidem muss vorhanden sein.

Organisatorische Validierung

Der Consent.Status darf nur nach rechtsgültiger Unterschrift auf active gesetzt werden.

Beschreibung eines Anwendungsszenarios

Ein Use Case ist die Erfassung der Einwilligung zur Datennutzung zur Forschung und das Management von Status und Widerruf.