Data Delivery, Usage & Legal Context

Warum diese Ebene existiert

Das oPJD beschreibt klinische Behandlungsverläufe. Aber ein Behandlungsverlauf existiert nicht im luftleeren Raum. Wenn Daten zwischen Institutionen ausgetauscht werden — etwa vom Landeskrebsregister zurück an ein Behandlungszentrum — reicht der klinische Inhalt allein nicht aus.

Der Empfänger muss wissen:

Wer liefert die Daten?
In welcher Rolle und auf welcher Rechtsgrundlage?
Zu welchem Zweck dürfen die Daten verwendet werden?
Wie lange sind sie gültig?
Welche Einschränkungen bestehen?

Diese Informationen gehören weder zum klinischen Modell noch zur Governance. Sie bilden eine eigenständige Schicht: die Liefer- und Nutzungshülle des oPJD-Datenpakets.

Leitgedanke

Ein oPJD-Datenpaket besteht nicht nur aus klinischen Inhalten, sondern auch aus einer definierten Austauschhülle, die Herkunft, Gültigkeit, Rechtsgrundlage und Verwendungszweck transparent macht.

Drei Ebenen des Modells

oPJD unterscheidet klar zwischen drei Ebenen:

Ebene	Inhalt	Beantwortet
A. Klinische Datenebene	Tumoren, Ereignisse, Episoden, Relationen, Provenance	Was ist klinisch passiert?
B. Liefer- und Nutzungsebene	Absender, Empfänger, Rechtsgrundlage, Zweck, Gültigkeit	Unter welchen Bedingungen werden Daten geliefert und genutzt?
C. Governance-Ebene	Versionierung, Change-Management, Rollen	Wie wird das Modell selbst gepflegt?

Dieser Bereich beschreibt Ebene B. Sie ist das Bindeglied zwischen dem klinischen Inhalt und dem institutionellen Rahmen, in dem Daten fließen.

Paketmetadaten

Jedes oPJD-Datenpaket — ob Push-Lieferung oder Pull-Abruf — trägt Metadaten, die die gesamte Übermittlung beschreiben.

Feld	Beschreibung	Pflicht
package_id	Eindeutige Kennung des Datenpakets	ja
package_version	Version dieser Lieferung (Updates, Nachlieferungen, Korrekturen)	ja
package_created_at	Erstellungszeitpunkt des Pakets	ja
sending_organization	Abgebende Institution (z.B. Landeskrebsregister, Klinik)	ja
sending_unit	Konkrete Organisationseinheit (Register, Zentrum, Abteilung)	optional
sending_system	Quellsystem (z.B. ONKOSTAR, Registersystem)	ja
receiving_organization	Empfängerinstitution	ja
delivery_context	Anlass der Übermittlung (Behandlung, QS, Forschung, Registerabgleich)	ja
jurisdiction	Rechtsraum / Bundesland / Land	ja
responsible_contact	Verantwortliche Stelle / Kontakt für Rückfragen	optional

Bezug zum oBDS

Der oBDS kennt bereits Melder-Metadaten. oPJD erweitert dieses Konzept um den Empfänger, den Übermittlungskontext und die rechtliche Einordnung — Informationen, die insbesondere beim Datenrückfluss aus Registern unverzichtbar sind.

Rechtsgrundlage und Berechtigung

Jedes Datenpaket muss die Rechtsgrundlage seiner Übermittlung mitführen. Das ist keine juristische Vollanalyse, sondern eine pragmatische Deklaration, die den Empfänger in die Lage versetzt, die Daten korrekt einzuordnen und zu verwenden.

Feld	Beschreibung	Pflicht
legal_basis_category	Kategorie der Rechtsgrundlage	ja
legal_basis_detail	Genauere Beschreibung (z.B. Landesrecht, Einwilligung, Vertrag)	optional
jurisdiction_specific_rule	Länderspezifische Sonderregel (z.B. Nachsorge nach Strahlentherapie)	optional
permitted_use	Erlaubter Verwendungszweck	ja
prohibited_use	Ausgeschlossene Nutzung	optional
redisclosure_allowed	Weitergabe an Dritte erlaubt (ja/nein)	optional

Kategorien der Rechtsgrundlage

clinical_care — Behandlungsbezogener Datenaustausch
cancer_registry_law — Krebsregistergesetz (Bund/Land)
quality_assurance_regulation — QS-Richtlinien und -Verordnungen
research_consent — Einwilligungsbasierte Forschung
other_research_basis — Andere Forschungsgrundlage (z.B. Ethikvotum)
contractual_data_transfer — Vertragliche Datenübertragung
jurisdiction_specific_exception — Länderspezifische Ausnahme

Praxisbeispiel: länderspezifische Regeln

Bestimmte Bundesländer erlauben den Abruf behandlungsbezogener Daten über die 12 Monate des letzten Kontaktes hinaus — etwa für die Nachsorge nach Strahlentherapie. Solche Sonderfälle werden über jurisdiction_specific_rule deklariert, damit der Empfänger die Berechtigung nachvollziehen kann.

Kategorien des Verwendungszwecks

treatment — Direkte Patientenversorgung
quality_assurance — Qualitätssicherung
follow_up — Nachsorge
registry_completion — Registerabgleich und -vervollständigung
research — Forschung
certification — Zertifizierung
tumor_board_preparation — Tumorboard-Vorbereitung
data_reconciliation — Datenabgleich
internal_reconciliation_only — Nur interner Abgleich, keine Weiterverwendung

Während Rechtsgrundlage und Verwendungszweck auf Paketebene gelten, können Einwilligungs- und Freigabeinformationen auf Patienten- oder Fallebene abweichen. oPJD sieht dafür optionale, aber empfohlene Felder vor.

Feld	Beschreibung	Pflicht
consent_status	Status der Einwilligung/Freigabe	empfohlen
consent_scope	Umfang (Versorgung, Forschung, standortübergreifend)	optional
consent_valid_from	Beginn der Gültigkeit	optional
consent_valid_until	Ende der Gültigkeit	optional
revocation_status	Widerruf (ja/nein)	optional
revocation_date	Datum des Widerrufs	optional
restriction_flag	Besondere Einschränkung vorhanden (Marker)	optional
restriction_note	Details der Einschränkung (z.B. nur QS, keine Forschung)	optional
local_reconciliation_allowed	Darf in lokalen Bestand übernommen/abgeglichen werden?	empfohlen

present — Einwilligung liegt vor
not_present — Keine Einwilligung vorhanden
revoked — Einwilligung widerrufen
unknown — Status unbekannt
not_required — Einwilligung nicht erforderlich (z.B. gesetzliche Grundlage)

Bezug zu FHIR und MII

FHIR kennt eine eigene Consent-Ressource, und die MII führt ein operationalisiertes Consent-Modul. oPJD orientiert sich an diesem Denken, setzt aber bewusst auf eine pragmatische, deklarative Transportebene — keine vollständige juristische Ontologie, sondern eine für den Empfänger handlungsleitende Information.

Gültigkeit und Lebenszyklus

Datenpakete haben eine zeitliche Dimension. Berechtigungen können befristet sein, Informationen veralten, und nachfolgende Lieferungen können vorangegangene ersetzen.

Feld	Beschreibung
valid_from	Ab wann gilt die Berechtigung / Freigabe?
valid_until	Bis wann gilt die Berechtigung? (Verfallslogik)
last_verified_at	Letzte Prüfung der Berechtigung
refresh_required_after	Zeitpunkt, nach dem eine Auffrischung erforderlich ist
supersedes_package_id	Referenz auf ein vorangegangenes, ersetztes Paket

Damit wird sichtbar, ob ein Paket noch aktuell ist, ob es eine vorangegangene Lieferung ersetzt und ob die zugrunde liegende Berechtigung noch Bestand hat.

Sonderkontexte und Teilblöcke

In manchen Fällen stammen Teile eines Datenpakets aus unterschiedlichen Kontexten — etwa wenn Studiendaten, Registerdaten und klinische Primärdokumentation in einem Paket zusammengeführt werden. Für diese Fälle sieht oPJD eine optionale Blockebene vor.

Feld	Beschreibung
data_block_id	Kennung eines Teilblocks
data_block_type	Art des Blocks (Studiendaten, Registerdaten, externe Dokumentation)
block_source	Herkunft dieses Blocks
block_legal_basis	Besondere Rechtsgrundlage (falls abweichend vom Paket)
block_permitted_use	Spezielle Nutzungsregel (z.B. nur Auswertung, keine Rückschreibung)
block_quality_label	Qualitätskennzeichnung des Blocks
block_timeliness	Aktualitätsstatus (bei heterogenen Quellen relevant)

Designprinzip

Rechtsgrundlage und Verwendungszweck gelten primär auf Paketebene. Abweichende Regeln dürfen auf Fall- oder Blockebene spezifiziert werden. So bleibt die Standardlage einfach, während Sonderfälle trotzdem modellierbar sind — ohne jedes Einzelereignis juristisch annotieren zu müssen.

Minimal-Set für Version 1

Nicht alle Felder müssen von Anfang an implementiert werden. Für eine erste lauffähige Version empfiehlt oPJD ein pragmatisches Kernset:

Pflichtfelder V1

package_id
package_version
package_created_at
sending_organization
sending_system
receiving_organization
delivery_context
legal_basis_category
permitted_use
jurisdiction

Stark empfohlene Zusatzfelder V1

legal_basis_detail
valid_until
consent_status
restriction_flag
local_reconciliation_allowed
responsible_contact

Ergebnis

Mit diesen 16 Feldern hat jedes oPJD-Datenpaket eine vollständige, nachvollziehbare Austauschhülle — wer liefert, wer empfängt, auf welcher Grundlage, zu welchem Zweck und mit welcher Gültigkeit.