Profil Vertragskopien

Ziel

Der Patient unterschreibt im Krankenhaus eine Vielzahl von Vereinbarungen, z.B. Behandlungsvertrag, Wahlleistungsvereinbarungen. Diese Vereinbarungen sollen im einfachen Fall als graphische Repräsentation im Sinne einer Vertragskopie verfügbar sein, damit der Patient diese papierlos erhalten kann. Andererseits sollte im fortgeschrittenen Fall auch der Inhalt des Vertrages maschinenlesbar abbildbar sein.

Veröffentlichung
Datum 30.07.2025
Version 1.0.0
Status Active
Nutzungsraum DE

Verwendetes FHIR-Profil

Es ist kein Profil von MII oder ISIK zu FHIR Ressource Contract (Vertrag) verfügbar, daher wird die Standard R4 Spezifikation als Grundlage verwendet.

ZIV-Profil Vertragskopien

idΣ0..1string
metaΣ0..1Meta
implicitRulesΣ ?!0..1uri
language0..1codeBinding
text0..1Narrative
contained0..*Resource
extensionC0..*Extension
modifierExtension?! C0..*Extension
identifierS Σ0..*Identifier
urlS0..1uri
versionS Σ1..1string
statusS Σ ?!0..1codeBinding
legalStateS0..1CodeableConceptBinding
instantiatesCanonical0..1Reference(Contract)
instantiatesUri0..1uri
contentDerivative0..1CodeableConcept
issuedS Σ0..1dateTime
id0..1string
extensionC0..*Extension
startS Σ C0..1dateTime
endΣ C0..1dateTime
expirationType0..1CodeableConcept
subjectS Σ0..*Reference(Resource)
authorityS0..*Reference(Organization)
domain0..*Reference(Location)
siteS0..*Reference(Location)
nameΣ0..1string
titleS Σ0..1string
subtitle0..1string
alias0..*string
authorS0..1Reference(Patient | Practitioner | PractitionerRole | Organization)
scope0..1CodeableConcept
topicCodeableConceptCodeableConcept
topicReferenceReference(Resource)
typeΣ0..1CodeableConcept
subTypeΣ0..*CodeableConcept
id0..1string
extensionC0..*Extension
modifierExtensionΣ ?! C0..*Extension
type1..1CodeableConcept
subType0..1CodeableConcept
publisher0..1Reference(Practitioner | PractitionerRole | Organization)
publicationDate0..1dateTime
publicationStatus1..1codeBinding
copyright0..1markdown
id0..1string
extensionC0..*Extension
modifierExtensionΣ ?! C0..*Extension
identifierΣ0..1Identifier
issuedΣ0..1dateTime
appliesΣ0..1Period
topicCodeableConceptCodeableConcept
topicReferenceReference(Resource)
type0..1CodeableConcept
subType0..1CodeableConcept
textΣ0..1string
id0..1string
extensionC0..*Extension
modifierExtensionΣ ?! C0..*Extension
number0..*unsignedInt
classification1..1Coding
category0..*Coding
control0..*Coding
id0..1string
extensionC0..*Extension
modifierExtensionΣ ?! C0..*Extension
identifier0..*Identifier
id0..1string
extensionC0..*Extension
modifierExtensionΣ ?! C0..*Extension
reference1..*Reference(Patient | RelatedPerson | Practitioner | PractitionerRole | Device | Group | Organization)
role1..1CodeableConcept
topicΣ0..1Reference(Resource)
type0..1CodeableConcept
decision0..1CodeableConceptBinding
decisionMode0..*CodeableConcept
id0..1string
extensionC0..*Extension
modifierExtensionΣ ?! C0..*Extension
valueBooleanboolean
valueDecimaldecimal
valueIntegerinteger
valueDatedate
valueDateTimedateTime
valueTimetime
valueStringstring
valueUriuri
valueAttachmentAttachment
valueCodingCoding
valueQuantityQuantity
valueReferenceReference(Resource)
text0..1string
linkId0..*string
securityLabelNumber0..*unsignedInt
id0..1string
extensionC0..*Extension
modifierExtensionΣ ?! C0..*Extension
scope0..1CodeableConcept
type0..*CodeableConcept
typeReference0..*Reference(Resource)
subtype0..*CodeableConcept
relationship0..1CodingBinding
id0..1string
extensionC0..*Extension
modifierExtensionΣ ?! C0..*Extension
reference0..1Reference(Resource)
code0..*CodeableConcept
text0..1string
condition0..1string
periodType0..*CodeableConcept
period0..*Period
usePeriod0..*Period
text0..1string
linkId0..*string
answer0..*see (answer)
securityLabelNumber0..*unsignedInt
id0..1string
extensionC0..*Extension
modifierExtensionΣ ?! C0..*Extension
entityCodeableConceptCodeableConcept
entityReferenceReference(Resource)
identifier0..1Identifier
effectiveTime0..1dateTime
quantity0..1SimpleQuantity
unitPrice0..1Money
factor0..1decimal
points0..1decimal
net0..1Money
payment0..1string
paymentDate0..1dateTime
responsible0..1Reference(Organization | Patient | Practitioner | PractitionerRole | RelatedPerson)
recipient0..1Reference(Organization | Patient | Practitioner | PractitionerRole | RelatedPerson)
linkId0..*string
securityLabelNumber0..*unsignedInt
id0..1string
extensionC0..*Extension
modifierExtensionΣ ?! C0..*Extension
doNotPerform?!0..1boolean
type1..1CodeableConcept
id0..1string
extensionC0..*Extension
modifierExtensionΣ ?! C0..*Extension
reference1..*Reference(Patient | RelatedPerson | Practitioner | PractitionerRole | Device | Group | Organization)
role0..1CodeableConcept
intent1..1CodeableConcept
linkId0..*string
status1..1CodeableConcept
context0..1Reference(Encounter | EpisodeOfCare)
contextLinkId0..*string
occurrenceDateTimedateTime
occurrencePeriodPeriod
occurrenceTimingTiming
requester0..*Reference(Patient | RelatedPerson | Practitioner | PractitionerRole | Device | Group | Organization)
requesterLinkId0..*string
performerType0..*CodeableConcept
performerRole0..1CodeableConcept
performer0..1Reference(RelatedPerson | Patient | Practitioner | PractitionerRole | CareTeam | Device | Substance | Organization | Location)
performerLinkId0..*string
reasonCode0..*CodeableConcept
reasonReference0..*Reference(Condition | Observation | DiagnosticReport | DocumentReference | Questionnaire | QuestionnaireResponse)
reason0..*string
reasonLinkId0..*string
note0..*Annotation
securityLabelNumber0..*unsignedInt
group0..*see (term)
supportingInfoS0..*Reference(Resource)
relevantHistory0..*Reference(Provenance)
id0..1string
extensionC0..*Extension
modifierExtensionΣ ?! C0..*Extension
type1..1CodingBinding
party1..1Reference(Organization | Patient | Practitioner | PractitionerRole | RelatedPerson)
signature1..*Signature
id0..1string
extensionC0..*Extension
modifierExtensionΣ ?! C0..*Extension
contentAttachmentAttachment
contentReferenceReference(Composition | DocumentReference | QuestionnaireResponse)
id0..1string
extensionC0..*Extension
modifierExtensionΣ ?! C0..*Extension
contentAttachmentAttachment
contentReferenceReference(Composition | DocumentReference | QuestionnaireResponse)
id0..1string
extensionC0..*Extension
modifierExtensionΣ ?! C0..*Extension
contentAttachmentAttachment
contentReferenceReference(DocumentReference)
legallyBindingAttachmentAttachment
legallyBindingReferenceReference(Composition | DocumentReference | QuestionnaireResponse | Contract)

Name Flags Card. Type Description & Constraints Klinik Patient
Contract TU DomainResource Legal Agreement Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
1. id S Σ 0..1 string 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
2.1. source S Σ 0..1 uri nicht relevant
2.2. profile S Σ 0..* canonical(StructureDefinition) nicht relevant
3. identifier S Σ 0..* Identifier Contract number nicht relevant
4. url S 0..1 uri Basal definition nicht relevant
5. version S ?! Σ 1..1 string Business editionVerpflichtend gesetzt wegen Medizinprodukt und falls Patienten sich vergleichen wollen und Unterschiede finden einsehbar
6. status S ?! Σ 0..1 code amended / appended / cancelled / disputed / entered-in-error / executable / executed / negotiable / offered / policy / rejected / renewed / revoked / resolved / terminated Contract Resource Status Codes (Required) änderbar einsehbar
6. legalState S ?! 0..1 CodeableConcept Negotiation status Contract Resource Legal State codes (Extensible) änderbar einsehbar
6.1 coding Σ 0..* Coding
6.1 text 0..1 string
7. instantiatesCanonical I 0..1 Reference(Contract) Source Contract Definition nicht relevant
8. instantiatesUri 0..1 uri External Contract Definition nicht relevant
9. contentDerivative 0..1 CodeableConcept Content derived from the basal information Contract Content Derivation Codes (Example) nicht relevant
10. issued S Σ 0..1 dateTime When this Contract was issued einsehbar
11. applies S Σ 0..1 Period Effective time einsehbar
11.1 start S Σ I 0..1 dateTime einsehbar
11.2 end Σ I 0..1 dateTime einsehbar wenn zutreffend
12. expirationType ?! 0..1 CodeableConcept Contract cessation cause Contract Resource Expiration Type codes (Example) nicht relevant
13. subject S Σ | ?! 1..* Reference(Any) Contract Target Entity → Verweis auf einen Patienten einsehbar
14. authority S | 0..* Reference(Organization) Authority under which this Contract has standing → für Patienten wichtig mit wem der Vertrag abgeschlossen ist einsehbar
15. domain | 0..* Reference(Location) A sphere of control governed by an authoritative jurisdiction, organization, or person → Klären ob man es wegnehmen kann
16. site S | 0..* Reference(Location) Specific Location einsehbar
17. title S 0..1 string Human Friendly name einsehbar
18. subtitle 0..1 string Subordinate Friendly name einsehbar
19. alias 0..* string Acronym or short name nicht relevant
20. author S | 0..1 Reference(Patient / Practitioner / PractitionerRole / Organization) Source of Contract nicht relevant
21. scope 0..1 CodeableConcept Range of Legal Concerns Contract Resource Scope codes (Example) nicht relevant
22. topic[x] 0..1 CodeableConcept Focus of contract interest nicht relevant
23. type Σ 0..1 CodeableConcept Legal instrument category Contract Type Codes (Example) nicht relevant
24. contentDefinition 0..1 BackboneElement Contract precursor content nicht relevant
25. term S ?! 0..* BackboneElement Contract Term List einsehbar
26. supportingInfo S| 0..* Reference(Any) Extra Information nicht relevant
27. relevantHistory | 0..* Reference(Provenance) Key event in Contract History nicht relevant
28. signer S 0..* BackboneElement Contract Signatory einsehbar
29. friendly S 0..* BackboneElement Contract Friendly Language einsehbar, und hoch relevant
30. legal 0..* BackboneElement Contract Legal Language nicht relevant
31. rule 0..* BackboneElement Computable Contract Language nicht relevant
32. legallyBinding[x] 0..1 Binding Contract nicht relevant

Beispiel-FHIR-Ressource (General Contract Example)

https://build.fhir.org/contract-example.json.html

{
  "resourceType" : "Contract",
  "id" : "C-123",
  "text" : {
    "status" : "generated",
    "div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">A human-readable rendering of the contract</div>"
  },
  "identifier" : [{
    "system" : "http://happyvalley.com/contract",
    "value" : "12347"
  }],
  "term" : [{
    "offer" : {
      "text" : "Can't refuse"
    },
    "asset" : [{
      "type" : [{
        "coding" : [{
          "system" : "urn:ietf:rfc:3986",
          "code" : "urn:uuid:3a48c68c-318d-4c68-8471-4a3c10fcb41b",
          "display" : "RicardianContract"
        }]
      }],
      "subtype" : [{
        "text" : "sample"
      }],
      "period" : [{
        "start" : "2017-06-01"
      }],
      "valuedItem" : [{
        "entityCodeableConcept" : {
          "text" : "Ford Bobcat"
        },
        "identifier" : {
          "system" : "http://somewhere.motor-vehicle.com/vin",
          "value" : "XXSVT34-7665t952236"
        },
        "effectiveTime" : "1995",
        "quantity" : {
          "value" : 1
        },
        "unitPrice" : {
          "value" : 200.00,
          "currency" : "CAD"
        },
        "factor" : 1.0,
        "points" : 1.0,
        "net" : {
          "value" : 200.00,
          "currency" : "CAD"
        }
      }]
    }]
  }],
  "rule" : [{
    "contentAttachment" : {
      "contentType" : "application/txt",
      "url" : "http://www.rfc-editor.org/bcp/bcp13.txt"
    }
  }],
  "legallyBindingAttachment" : {
    "contentType" : "application/pdf",
    "url" : "http://www.aws3.com/storage/doc.pdf"
  }
}

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

Herausforderungen

  1. An den meisten Krankenhäusern werden Verträge vollständig analog verwaltet, sodass ein digitaler Umstieg zumindest mit einem Scanvorgang verbunden ist. Zunehmend werden jedoch vermehrt solche Verträge digital eingescannt im Rahmen z. B. des Scannens der Akte am Behandlungsende. Eine digitale Repräsentation der Inhalte ist deutlich komplexer, da hierfür neue, bisher nicht vorhandene Software spezifiziert oder zumindest angeschafft werden muss.

  2. Klinisch Organisatorisch können hier auch Änderungen bzw. Stornierungen abgebildet werden.

  3. Die Ressource "Contract" beinhaltet viele Referenzen, diese müssen klar zugewiesen werden und bei einer Änderung oder Löschung einer Referenz muss die sinnvolle Referenzierung erhalten bleiben. Die Integrität und Konsistenz muss jeder Zeit gewährleistet sein.

    1. ggf. muss ein Fallbezug hergestellt werden
    2. ggf. muss ein Bezug zu einer Aufklärung hergestellt werden. (z.B. häufig Datenschutz-Consents oder weniger häufig (bzw. schwierig zu verknüpfen) Einwilligungen bei Selbstzahler-Operationen)
    3. ggf. gibt es eine Laufzeit oder eine Stornierung des Vertrages ( https://www.hl7.org/fhir/R4/valueset-contract-status.html )
  4. Ein unterschriebener Vertrag (legallyBinding) muss aufgrund von gesetzlichen Vorgaben gesichert werden, um Archivierungsfristen einzuhalten.

  5. Bei Behandlungsverträgen, wie auch einigen anderen, würde eine Referenz auf einen Behandlungsfall Sinn ergeben, allerdings ist die aktuellen Auslegung dieses Profils auf eine große Bandbreite von Verträgen ausgelegt, daher aktuell nicht integriert.

Lösungen

  1. Ein Zukauf einer Vertrags-Software zur Digitalisierung der analogen Dokumente als Komponenten des Aufnahmeprozesses erscheint notwendig. Dies kann aber im Rahmen einer klinikübergreifenden Beschaffung Synergieeffekte bringen. Da es sich hier nicht um ein Medizinprodukt handelt, kann eine Beschaffung im Rahmen z. B.: einer Einkaufsgemeinschaft auch eine Beauftragung einer Drittfirma erleichtern.

  2. Es sollte ein Workflow im User-Interface des z. B. KIS verfügbar sein, um Änderungen/Stornierungen/etc. korrekt abbzubilden. Dies sollte auch an den Patienten zurückgespielt werden z. B. via Patienten-App.

  3. In Spezifikation Referenzierungen sicherstellen, bspw. dass immer auf einen Patienten verwiesen werden muss durch die Kardinalität. Validierung der Konformität. \nDatenhaltende Server müssen tägliche Backups fahren und sollten gespiegelt sein, dies soll eine hohe Sicherheit der Daten gewährleisten.

  4. Vertragsdaten müssen archiviert werden und gesichert sein auf Servern, welche eine hohe Ausfallsicherheit bieten. Es sollte redundante Datenhaltung und Backups eingesetzt werden.

  5. Referenz auf Fall (Case) in Profil ergänzen.

Validierungsregeln

Technische FHIR-Validierung

Die Validierung einer gesendeten FHIR-Ressource erfolgt gegenüber dem ZIV-Profil, indem die Ressourcen-Struktur auf ZIV-Konformität überprüft wird. Konkret muss überprüft werden, ob alle Datenelemente mit Pflichtfeld oder mustSupport-Flag in der Ressource vorhanden sind oder ob nicht zugelassene Datenelemente existieren.
Die Validierung erfolgt via Simplifier, da darüber das Profil spezifiziert ist.

Organisatorische Validierung

Solange die o.g. SOPs eingehalten werden, ist keine organisatorische Validierung notwendig.
Die Klinik muss dafür Sorge tragen, dass die in diesen Feldern eingetragenen Daten korrekt sind. Dies ist insbesondere von Bedeutung, wenn die Daten maschinell von einem gescannten Dokument übernommen wurden.
Kliniken können sich in Abhängigkeit vom Durchsetzungsgrad der SOPs einigen, stichprobenhafte Kontrollen der Korrektheit der ausgefüllten Elemente im KIS durchzuführen.

Beschreibung von Anwendungsszenarios

Datenspende

Die Datenspende, insbesondere von Gesundheitsdaten gewinnt immer mehr an Bedeutung für die Forschung. Auch im Rahmen von ZIV wurde während der Corona-Pandemie eine App zur Datenspende von Impfnebenwirkungen entwickelt (CoCoV), deren Daten in anonymisierter Form über ein Dashboard zur allgemeinen Ansicht zur Verfügung gestellt wurden. Zusätzlich diente die App den Teilnehmern als Symptom-Tagebuch. Neben ZIV entwickelte aber auch das Robert Koch-Institut (RKI) eine Coronadatenspende-App deren Daten für wissenschaftliche Zwecke genutzt werden.
Im Anwendungsszenarium der Datenspende zur Impfnebenwirkung über die CoCoV App wurden die Probanden nach einer COVID-19 Impfung zur Teilnahme an der Studie eingeladen. Über eine mobile Anwendung prüften und unterschrieben die Probanden eine Einverständniserklärung (dargestellt als FHIR-Vertrag), um die Weitergabe der von ihnen selbst zur Verfügung gestellten Daten an die Forschungseinrichtung zu gestatten. Dabei können die Probanden ihre Einwilligung jederzeit überprüfen und ggf. widerrufen.
Dieses Anwendungsszenarium setzt voraus, dass die Studie von einer lokalen Ethikkommission genehmigt wurde und die mHealth Applikation mit dem FHIR-Backend der Forschungseinrichtung (Krankenhaus) verbunden ist.
Der beschriebene Anwendungsfall konzentriert sich auf die mobile Einholung von Einwilligungen. Im Mittelpunkt steht also eine direkte Probandeninteraktion über eine App. Dieser Anwendungsfall kann für klinische Fernstudien oder telemedizinische Projekte erweitert werden.

Unterschriebene Papier-basierte Verträge

Ein Patient unterschreibt im Krankenhaus eine Papier-basierte Einverständniserklärung z.B. zur Teilnahme an einer Studie. Der eingescannte Vertrag wird im System digitalisiert und der Patient kann die Einwilligung später über eine mobile App des Krankenhauses (z.B. die Meine Uniklinik App des Universitätsklinikums Freiburg) einsehen oder widerrufen.

FHIR-Profil Contract

  • Beispiel Datenspende über App Einwilligung

    {
      "resourceType": "Contract",
      "id": "covid-vax-sideeffects-consent-001",
      "meta": {
        "versionId": "1",
        "lastUpdated": "2025-06-02T10:00:00Z"
      },
      "identifier": [
        {
          "system": "https://hospital.example.org/consents",
          "value": "consent-20250602-001"
        }
      ],
      "url": "https://hospital.example.org/fhir/Contract/covid-vax-sideeffects-consent-001",
      "version": "1.0",
      "status": "executed",
      "legalState": {
        "coding": [
          {
            "system": "http://terminology.hl7.org/CodeSystem/contract-legalstate",
            "code": "executed",
            "display": "Executed"
          }
        ]
      },
      "issued": "2025-06-02T09:55:00Z",
      "applies": {
        "start": "2025-06-02T10:00:00Z",
        "end": "2025-12-31T23:59:59Z"
      },
      "subject": [
        {
          "reference": "Patient/123",
          "display": "Max Mustermann"
        }
      ],
      "authority": [
        {
          "reference": "Organization/hospital_XYZ",
          "display": "University Hospital XYZ"
        }
      ],
      "site": [
        {
          "reference": "Location/vaccine-clinic-01",
          "display": "COVID Vaccination Center - XYZ"
        }
      ],
      "term": [
        {
          "identifier": {
            "system": "https://hospital.example.org/terms",
            "value": "term-covid-vax-effects-001"
          },
          "issued": "2025-06-02T09:55:00Z",
          "applies": {
            "start": "2025-06-02T10:00:00Z"
          },
          "offer": {
            "text": "Consent to participate in a study on side effects following COVID-19 vaccination. Data will be pseudonymized and used exclusively for public health research."
          },
          "extension": [
            {
              "url": "https://hospital.example.org/fhir/StructureDefinition/contract-term-securityLabel",
              "valueCoding": {
                "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
                "code": "REDACTED",
                "display": "Redacted"
              }
            }
          ]
        }
      ],
      "supportingInfo": [
        {
          "reference": "Questionnaire/covid-sideeffects-questionnaire"
        },
        {
          "reference": "ResearchStudy/covid-vax-effects-study-2025"
        },
        {
          "reference": "DocumentReference/consent-doc-001",
          "display": "Scanned consent document"
        }
      ],
      "friendly": [
        {
          "contentAttachment": {
            "title": "Einwilligungserklärung zur Teilnahme an der Impfnebenwirkungsstudie",
            "url": "https://hospital.example.org/docs/consent-form-de.pdf",
            "creation": "2025-06-01T08:00:00Z"
          }
        }
      ],
      "signer": [
        {
          "type": {
            "system": "urn:iso-astm:E1762-95:2013",
            "code": "1.2.840.10065.1.12.1.1",
            "display": "Consent Signature"
          },
          "party": {
            "reference": "Patient/123"
          },
          "signature": [
            {
              "type": [
                {
                  "system": "urn:iso-astm:E1762-95:2013",
                  "code": "1.2.840.10065.1.12.1.1"
                }
              ],
              "when": "2025-06-02T10:00:00Z",
              "who": {
                "reference": "Patient/123"
              },
              "data": "U2lnbmF0dXJlU2FtcGxl"  
            }
          ]
        }
      ]
    }
    
    
  • Beispiel unterschriebener Papier-basierter Vertrag

    {
      "resourceType": "Contract",
      "id": "covid-study-consent-001",
      "meta": {
        "versionId": "1",
        "lastUpdated": "2025-06-02T15:00:00Z"
      },
      "identifier": [
        {
          "use": "official",
          "type": {
            "coding": [
              {
                "system": "http://terminology.hl7.org/CodeSystem/v2-0203",
                "code": "CN",
                "display": "Contract Number"
              }
            ]
          },
          "system": "https://research.hospital.org/study-consents",
          "value": "study-consent-20250602-789",
          "assigner": {
            "reference": "Organization/hospitalXYZ",
            "display": "Universitätsklinikum XYZ"
          }
        }
      ],
      "url": "https://research.hospital.org/fhir/Contract/covid-study-consent-001",
      "version": "1.0",
      "status": "executed",
      "legalState": {
        "coding": [
          {
            "system": "http://terminology.hl7.org/CodeSystem/contract-legalstate",
            "code": "executed",
            "display": "Executed"
          }
        ],
        "text": "This contract has been executed after written consent was provided by the participant."
      },
      "issued": "2025-06-02T12:45:00Z",
      "applies": {
        "start": "2025-06-02T13:00:00Z",
        "end": "2028-06-02T23:59:59Z"
      },
      "subject": [
        {
          "reference": "Patient/789",
          "display": "Max Mustermann"
        }
      ],
      "authority": [
        {
          "reference": "Organization/research-center-hospital",
          "display": "Research Department, University Hospital"
        }
      ],
      "site": [
        {
          "reference": "Location/research-unit-1",
          "display": "Research Unit, Building B, Floor 2"
        }
      ],
      "term": [
        {
          "identifier": {
            "system": "https://research.hospital.org/terms",
            "value": "term-covid-study-001"
          },
          "issued": "2025-06-02T12:45:00Z",
          "applies": {
            "start": "2025-06-02T13:00:00Z"
          },
          "offer": {
            "text": "Consent to participate in the 'Post-COVID Long-Term Study', including the use of health data and periodic follow-up via questionnaires.",
            "type": {
              "coding": [
                {
                  "system": "http://hl7.org/fhir/consent-decision-mode",
                  "code": "research",
                  "display": "Research Consent"
                }
              ]
            },
            "decision": {
              "coding": [
                {
                  "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
                  "code": "OPTIN",
                  "display": "Accepted"
                }
              ]
            },
            "decisionMode": [
              {
                "coding": [
                  {
                    "system": "http://hl7.org/fhir/consent-decision-mode",
                    "code": "electronic",
                    "display": "Electronically"
                  }
                ]
              }
            ],
            "party": [
              {
                "reference": [
                    {
                        "reference": "Patient/789"
                    }
                ],
                "role": {
                  "coding": [
                    {
                      "system": "http://terminology.hl7.org/CodeSystem/participant-role",
                      "code": "CONSENTER",
                      "display": "Consenter"
                    }
                  ]
                }
              }
            ],
            "extension": [
              {
                "url": "https://research.hospital.org/fhir/StructureDefinition/contract-term-securityLabel",
                "extension": [
                  {
                    "url": "classification",
                    "valueCoding": {
                      "system": "http://terminology.hl7.org/CodeSystem/v3-Confidentiality",
                      "code": "R",
                      "display": "Restricted"
                    }
                  },
                  {
                    "url": "category",
                    "valueCoding": {
                      "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
                      "code": "RESD",
                      "display": "Research subject data"
                    }
                  },
                  {
                    "url": "category",
                    "valueCoding": {
                      "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
                      "code": "GEN",
                      "display": "Genetic data"
                    }
                  },
                  {
                    "url": "control",
                    "valueCoding": {
                      "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
                      "code": "RESD",
                      "display": "Research Subject Data"
                    }
                  }
                ]
              }
            ]
          }
        }
      ],
      "supportingInfo": [
        {
          "reference": "ResearchStudy/post-covid-study-2025",
          "display": "Post-COVID Long-Term Follow-Up Study"
        },
        {
          "reference": "Immunization/covid-shot-001",
          "display": "Vaccination status"
        },
        {
          "reference": "Observation/covid-side-effects-log",
          "display": "Reported side effects"
        }
      ],
      "friendly": [
        {
          "contentAttachment": {
            "title": "Study Participation Consent Form",
            "url": "https://research.hospital.org/docs/study-consent-postcovid-de.pdf",
            "creation": "2025-06-02T12:30:00Z"
          }
        }
      ],
      "signer": [
        {
          "type": {
            "system": "urn:iso-astm:E1762-95:2013",
            "code": "1.2.840.10065.1.12.1.1",
            "display": "Consent Signature"
          },
          "party": {
            "reference": "Patient/789"
          },
          "signature": [
            {
              "type": [
                {
                  "system": "urn:iso-astm:E1762-95:2013",
                  "code": "1.2.840.10065.1.12.1.1"
                }
              ],
              "when": "2025-06-02T12:45:00Z",
              "who": {
                "reference": "Patient/789"
              },
              "data": "VGhpcyBpcyBhIHRlc3Qgc2lnbmF0dXJlLg=="
            }
          ]
        }
      ]
    }
    
    
    

Beschreibung der Elemente und Implementierungshilfen

Wir empfehlen allgemein in Ihren FHIR Profilen die Verwendung von display oder text als hilfreiche Zusammenfassungen für Ihre Elemente, insbesondere für User Interfaces, Dashboards, oder FHIR viewers.
Contract.meta: Standard Block, der technischen Details über die Ressource und nicht deren klinische oder geschäftliche Inhalte erfasst.

  • versionId: Versionszähler, der sich jedes Mal ändert, wenn die Ressource aktualisiert wurde
  • lastUpdated: ISO 8601 Zeitstempel der die letzte Änderung deer Ressource angibt
  • profile: gibt an, dass die Validieren oder Struktur bestimmten Regeln folgt (z.B. MII-Studieneinwilligung)

Contract.identifier: Kennung, die diesen Vertrag in einem bestimmten Kontext (z.B. Organisation, Gerichtsbarkeit oder System) eindeutig identifiziert

  • FHIR Identifier Datentyp wird verwendet mit seinen Unterelementen
    • use: gibt den Zweck der Kennung an. FHIR definiert Standardwerte z.B.
Code Beschreibung
official offizieller oder extern validierter Bezeichner
usual standardmäßiger systemweiter Bezeichnet (z.B. interne Vertragskennung)
temp vorläufiger Platzhalter vor der endgültigen Genehmigung
  • type: CodeableConcept für die Art der Kennung (z.B. Vertragsnummer, Fall-ID)
  • system: ausstellendes System (z.B. das Vertragsregister des Krankenhauses).
    • Verwenden Sie stabile, dokumentierte System URIs um Mehrdeutigkeit oder Kollisionen zu verhindern
  • assigner: Verweis auf die FHIR Organization Ressource, die den Identifikation vergeben hat z.B. Organization/HospitalXYZ oder Organization/StudySponsor
  • period: Zeitraum in dem der Identifier gültig ist

Contract.url: eine dauerhafte, eindeutige URL, die diesen Vertrag identifiziert und in Referenzen oder Profilen verwendet wird.

  • Vermeiden Sie die Verwendung von temporären oder rein lokalen URLs (z.B. „localhost:8080/contract") in Produktionssystemen
  • Für Umgebungen, die zertifizierte Ressourcenvertrauen erfordern (z.B. klinische Forschung, oder Patienteneinwilligungen) ist es unerlässlich, stabile HTTPS-basierte, kanonische URLs zu verwenden, die sowohl die FHIR Beste Praxis als auch die Anforderungen an Sicherheit und Auditierbarkeit erfüllen.

Contract.version: ein von Menschen lesbarer oder vom System verwalteter Versionsbezeichner, der zur Unterscheidung zwischen verschiedenen Versionen desselben Vertrags verwendet wird

Contract.status: gibt den Workflow-Status des Vertrags aus der Prozesspespektive an, z.B. ob er ein Entwurf ist oder aktiv bzw. archiviert

Code Display Beschreibung
offered Offered Der Vertrag wurde angeboten, aber noch nicht angenommen
accepted Accepted Der Vertrag wurde angenommen
executed Executed Vollständig unterzeichneter und rechtsverbindlicher Vertrag
amended Amended Von der ursprünglichen Form abweichender Vertrag
renewed Renewed Vertrag wird auf eine neue Laufzeit ausgedehnt
revoked Revoked Rechtmäßig vor Abschluss gekündigt
terminated Terminated Formell beendet (erfüllt oder gekündigt)

Contract.legalState: beschreibt die Rechtsgültigkeit oder Verbindlichkeit des Vertrags nach geltendem Recht

Code Display Beschreibung
offered Offered Der Vertrag wurde angeboten, aber noch nicht angenommen
accepted Accepted Der Vertrag wurde angenommen
executed Executed Vollständig unterzeichneter und rechtsverbindlicher Vertrag
amended Amended Von der ursprünglichen Form abweichender Vertrag
renewed Renewed Vertrag wird auf eine neue Laufzeit ausgedehnt
revoked Revoked Rechtmäßig vor Abschluss gekündigt
terminated Terminated Formell beendet (erfüllt oder gekündigt)

Contract.issued: Das Datum und die Uhrzeit, zu der der Vertrag formell ausgestellt wurde (z.B. wenn er unterzeichnet, erstellt oder rechtsgültig gemacht wurde

  • Die Zeitangabe sollte vor oder gleich dem Contract.applies.start liegen
  • Verwenden Sie ein vollständiges ISO 8601 Zeitstempelformat inklusive Zeitzone

Contract.applies: gibt den Zeitraum an, in dem der Vertrag gültig oder einklagbar sein soll

  • Verwenden Sie ein UTC-konfromes Datums-/Zeitformat
  • Das Subelment end ist optional und kann z.B. bei unbefristeten Einwilligungen weggelassen werden, start is hingegen verpflichtend

Contract.subject: identifiziert die Person(en) oder Einheit(en), auf die sich der Vertrag direkt bezieht. In der Regel die Person, die ihre Zustimmung gibt, Dienstleistungen erhält oder unter den Bedingungen des Vertrags geschützt wird.

  • Referenziert meistens auf die FHIR Ressource Patient, kann aber auch je nach Kontext auf andere FHIR Ressourcentypen wie Practitioner, Group oder RelatedPerson verweisen
  • Gilt der Vertrag für mehrere Personen (z.B. Zwillinge in einer pädiatrischen Studie), kann eine Group Referenz als FHIR Ressource verwendet werden

Contract.authority: gibt die Organisation an, die für die Durchführung oder Überwachung des Vertrags zuständig oder rechtlich verantwortlich ist.

  • Referenziert auf die Ressource Organization

Contract.site: bezieht sich auf den/die physischen oder virtuellen Ort(e), an dem/denen die Vertragsbedingungen in Kraft treten oder ausgeführt werden.

  • Referenziert auf die Ressource Location

Contract.term: beschreibt was vereinbart wird, inklusive Angebote, Verpflichtungen und Rechte, die mit dem Vertrag einhergehen sowie dessen Gültigkeitsdauer

  • Es können mehrere term Einträge verwendet werden, wenn der Vertrag mehrere Bereiche abdeckt (z.B. Einwilligung in die Behandlung und Datennutzung) oder unterschiedliche Zeiträume für unterschiedliche Verpflichtungen vorliegen.
  • identifier: eindeutige Kennung für die Rückverfolgbarkeit
  • issued: Zeitstempel (dateTime) wann dem Vertrag zugestimmt wurde
  • applies: Zeitfenster in dem der Vertrag gültig ist. Kann start und end beinhalten. Wenn nur der Beginn angegeben wird, gilt die Klausel ab diesem Zeitpunkt auf unbestimmte Zeit. Der Zeitstempel muss ein valides FHIR dateTime Format aufweisen. Zusätzlich muss darauf geachtet werden, dass die Werte in Contract.term.applies die Zeitspanne in Contract.applies (top-Level) nicht überschreiten oder mit diesem in Konflikt stehen.
  • offer: das offer-Element erfasst die tatsächlichen Absichten, einschließlich was angeboten wird, von wem, und ob es angenommen oder abgelehnt wird.
    • text: Menschen lesbare Beschreibung des Angebots
    • type: Art des Angebots, das im Rahmen des Vertrags abgegeben wird. Dieses Element verwendet ein CodeableConcept. Die Werte können aus verschiedenen standardisierten oder lokalen Codystemen entnommen werden, z.B.:
Code Display System Beschreibung
consent Consent http://hl7.org/fhir/consent-action oder http://hl7.org/fhir/contracttermtypecodes Einwilligung in die Behandlung, Teilnahme oder Datennutzung
disclosure Disclosure http://hl7.org/fhir/contracttermtypecodes Weitergabe von Informationen an Dritte
research Research Participation Benutzer definiert oder SNOMED/HL7 abgeleitet Teilnahme an einer Forschungsstudie
treatment Treatment Consent http://terminology.hl7.org/CodeSystem/v3-ActCode Zustimmung zu einem medizinischen Eingriff/Verfahren
dataUse Data Use Agreement http://hl7.org/fhir/contracttermtypecodes Nutzung von personenbezogenen Gesundheitsdaten gestatten
* Empfohlene Kodierungssysteme:
  * Für allgemeine FHIR-Vertragsangebotstypen: <http://hl7.org/fhir/contracttermtypecodes>
  * Wenn auf Consent ausgerichtet: <http://hl7.org/fhir/consent-action>
  * Für Verfahrens- oder Krankheitsbezogene Vereinbarungen: SNOMED CT
  * Wenn Angebote an Fragebögen gebunden sind: LOINC
  • decision und decisionMode: Dokumentation welche Entscheidung (decision) das subject (in der Regel der Patient) getroffen hat und wie die Entscheidung getroffen wurde (elektronisch, mündlich, auf Papier unterschrieben). Sie sind entscheidend für die Überprüfbarkeit und Rechtsgültigkeit von Verträgen.
    • decision: FHIR definiert keine spezifischen Wertesätze für das CodeableConcept, sodass Sie Ihre eigenen definieren oder etablierte Codes aus v3-ActCode oder einem lokal gepflegten System verwenden können. Typische Kodierungen als Beispiel:
Code Display System Beschreibung
OPTIN Accept http://terminology.hl7.org/CodeSystem/v3-ActCode Einwilligung in den Vertrag
OPTOUT Decline http://terminology.hl7.org/CodeSystem/v3-ActCode Ablehnung des Vertrags
WITHDRAWN Withdrawn lokal Dem zunächst zugestimmt Vertrag wird widersprochen
* *decisionMode*: FHIR R5 schreibt zwar keine festen Wertesätze für das *CodeableConcept* vor, empfiehlt aber die Verwendung der HL7 Codes 
Code Display System Beschreibung
written Written http://hl7.org/fhir/consent-decision-mode Die Entscheidung wurde in Form eines Papierdokuments übermittelt
verbal Verbal http://hl7.org/fhir/consent-decision-mode Die Entscheidung wurde mündlich getroffen
electronic Electronic http://hl7.org/fhir/consent-decision-mode Die Entscheidung wurde auf digitalem Wege getroffen (z.B. in einer App)
  • party: Identifiziert Personen, Organisationen oder Geräte, die an dem Vertrag beteiligt sind, d.h. diejenigen, die den Vertrag machen oder ihm zustimmen
    • reference: Link zu einer anderen FHIR Ressource wie Patient, Practioner, Organization oder Device
    • role: ein CodeableConcept, das die Rolle der Person/Organisation im Rahmen des Vertrags beschreibt. Typische Rollen können sein:
Code Display Beschreibung
subject Subject Der Vertragsgegenstand, z.B. der an der Studie beteiligte Patient
consenter Consenter Die Person, die dem Angebot zustimmt, oder es ablehnt
recipient Recipient Die Partei, die Daten, Dienstleistungen oder Verpflichtungen erhält
sponsor Sponsor Einrichtung, die die Vereinbarung finanziert oder initiiert hat
  * Verwenden Sie Standartrollen von <http://hl7.org/fhir/contract-party-role> um die Interoperabilität zu gewährleisten
  * Stimmen sie das *party* Element mit dem *signer* Element ab wenn für diese Rolle Unterschriften erforderlich sind
  • securityLabel: ermöglicht die Kennzeichnung einer Vertragsbedingung mit Klassifizierungskennzeichen für Vertraulichkeit, Zugangskontrolle und Sensibilität. Es basiert auf dem HL7 Helthcare Privacy and Security Classification System (HCS) und unterstützt Datenkennzeichnungne, die kompatibel mit ISO/IEC 27001, NIST 800-53 oder EU GDPR sind. Das securityLabel ist nochmals untergliedert in:
Code Display Beschreibung
U Unrestricted öffentliche oder nicht empfindlich
L Low geringfügig sensibel
M Moderate mäßig sensibel (typische medizinische Daten)
R Restricted hochsensibel
V Very Restricted sehr restriktiv, hoch sensible
N Normal allgemeine Vertraulichkeit
* category: um welche Art von sensiblen Daten es sich handelt. Ein Kondierungssystem hierfür ist: <http://terminology.hl7.org/CodeSystem/v3-ActCode> 
Code Display Beschreibung
RESD Research subject data Daten aus der klinischen Forschung
GEN Genetic data Genetische Tests oder Marker
PSY Psychiatric information Daten zur psychischen Gesundheit
* control: Zugriffskontrolle, welche Regeln gelten für die Nutzung oder Weitergabe: Ein Kodierungssystem hierfür ist: <http://terminology.hl7.org/CodeSystem/v3-ActCode> 
Code Display Beschreibung
NORDSCLCD No redisclosure without consent erfordert erneute Zustimmung zur Weitergabe
INFAO Information for authorized use only Beschränkungen auf autorisiertes Personal
REDACTED Redacted unkenntlich gemacht oder zensiert
ENCRYPT Encrypted muss sicher übertragen werden
TBOO To be opened only under order Zugang nur durch Gericht oder Behörde
  *  Kombinieren Sie die Subelemente classification, category und control für eine präzise Kennzeichnung
  * Verwenden Sie einheitliche *securityLabel* für alle FHIR Ressourcen (z.B. *Contract*, *Observation*)

Contract.supportingInfo: Array an Referenz zu anderen FHIR Ressourcen, die Kontext- oder Hintergrundinformationen für den Vertrag liefern. Diese Ressourcen können z.B. Observation, Consent, Encounter oder Condition sein.

  • Sollte verwendet werden, wenn der Vertrag von früheren Daten abhängt (Fallbezug), z.B. Labor oder klinischen Daten, die den Vertrag rechtfertigen

Contract.friendly: ist eine für Menschen lesbare Version des Vertrags und spielt daher eine entscheidende Rolle für den Patienten.

  • Für das Element friendly kann entweder das Sub-Element contentAttachment oder contentReference verwendet werden. Normalerweise werden, jedoch nicht beide verwendet, da sie leicht unterschiedlichen technischen und praktischen Zwecken unterliegen. Für Patienten-Apps empfehlen wir das Sub-Element contentAttachment, da eine einfache Datei oder Dokument direkt als Attachment in die FHIR Ressource eingebunden werden kann. Für ein klinisches Backend oder ein Forschungsregister verwenden Sie hingegen ehr contentReference to DocumentReference für vollständige Rückverfolgbarkeit und ein strukturiertes Dokumentenmanagement.
  • contentAttachment: ist ein Subelement und Array von Objekten. Achten Sie darauf dass die Elemente title, contentType und creation immer ausgefüllt sind um die Rückverfolgbarkeit zu gewährleisten
    • title: Menschen lesbarer Titel des Anhangs
    • contentType: code für den Datentyp des Inhalts nach MIME Typ nach IANA Standard
    • url: URL oder lokale Referenz zum Inhalt. Dieses Element ist besonders für große Inhalte wichtig, da es ein Aufblähen der FHIR Ressource vermeidet.
    • creation: ein Zeitstempel (dateTime) nach ISO 8601 an dem der Anhang erstellt wurde

Contract.signer: erfasst, wer den Vertrag in welcher Rolle unterschrieben hat.

Das Element signer ist in die folgenden Sub-Elemente gegliedert:

  • type: ist ein CodeableConcept, das die Rolle des Unterzeichners, z.B. Patient, Zeuge, gesetzlicher Vertreter darstellt.
    • Häufig wird nach der Norm ASTM E1762-95 (Standard Guide for Electronic Authentification of Health Care Information) kodiert. Diese Norm wird über die System-URI (system: "urn:iso-astm:E1762-95:2013") referenziert.
    • Wenn ein Unterzeichner mehrere Rollen einnimmt, können auch mehrere Codes in das type[]-Array aufgenommen werden
      • Beispiel für häufige Rollen:
Rolle Code Beschreibung
Patient 1.2.840.10065.1.12.1.1 Unterschrift des Patienten selbst
Arzt/Studienleiter 1.2.840.10065.1.12.1.5 Arzt oder Studienleiter unterzeichnet ebenfalls
Zeuge 1.2.840.10065.1.12.1.2 (optional) wenn ein Zeuge ebenfalls unterschreibt
Gesetzlicher Vertreter (Vormund) 1.2.840.10065.1.12.1.3 Wenn eine Person im Namen des Patienten unterschreibt
  • party: ist eine Reference auf wer den Vertrag unterzeichnet hat.
    • In der Regel verweist die Referenz auf die Ressource Patient, Practionier, PractionerRole, oder Organization
  • signature: die eigentlichen Signaturdaten, einschließlich der Uhrzeit und optional eines kryptografischen Hashes oder eines gescannten Bildes
    • Subelemente sind:
      • type: erneut die Rolle des Unterzeichners nach ASTM E1762-95 Kodierung
      • when: Zeitstempel des Unterschrift, ein dateTime wofür FHIR das ISO 8601 Format verwendet. Der Wert muss ein vollständiges Datum und eine Uhrzeit enthalten, sowie eine Zeitzone oder ein "Z" für UTC.
      • who: referenziert auf eine Ressource, wer unterschreibt
      • data: der eigentliche Inhalt der Signatur base64Binary (z.B. ein gescanntes Signaturbild)
      • sigFormat: code für das Format der Signatur, normalerweise ein MIME-Typ (IETF Standard)
sigFormat (MIME Typ) Beschreibung
image/png für eingescannte handschriftliche Unterschriften
application/pdf wenn die Unterschrift in ein PDF-Datei eingebettet ist
application/pkcs7-signature Kryptographische Nachritchensyntax (CMS)

targetFormat: code für das Format der signierten Ressource (z.B. PDF-Dokument, JSON-Datei oder XML)

targetFormat (MIME Typ) Beschreibung
application/fhir+json Die signierte Ressource ist ein FHIR JSON-Dokument
application/fhir+xml Bei der signierten Ressource handelt es sich um ein FHIR-XML-Dokument
application/pdf Ein PDF-Dokument wurde signiert (z.B. Einverständniserklärung oder Studienvertrag)
  • Es können mehrere Unterschriftseinträge eingefügt werden
  • Für fortgeschrittene digitale Signatur-Worflows (z.B. eID-Karten (elektronische Identitätskarten, Chipkarten) verwenden Sie das optionale sigFormat Element
  • Verwenden Sie immer einen gültigen Internet Assigned Numbers Authority (IANA)-Medientyp
  • sigFormat und targetFormat sind optional, werden aber aus Gründen der Klarheit empfohlen, insbesondere in digitalen Zustimmungsworkflows
  • Für die Interoperabilität digitaler Signaturen sollten Sie application/pkcs7-signature oder application/xml-signature verwenden