ooPJD

Data Dictionary

Alle 202 Datenelemente der Version 0.2.0 — normative Bedeutung, Herkunft und oBDS-Bezug je Term. Maschinenlesbar unter /schema/0.2.0/dictionary.json.

Stabile Term-IDs

Jeder Term trägt eine versionsübergreifend stabile ID nach dem Schema opjd://<version>/<pfad>[/<wert>]. Terme werden nie gelöscht, sondern als deprecated markiert. Rohdaten: dictionary.json · Metaschema

Kernobjekte und ihre Felder

oPJD-Paket (package)

Formaler Kontrakt für ein oPJD-Datenpaket: die konsolidierte onkologische Patient Journey eines Patienten — Austauschhülle (delivery), Patient, Tumorentitäten, Ereignisse mit unveränderter oBDS-Nutzlast, Episoden (Klammern), typisierte Relationen (Bezüge) und optionaler Journey-Status. Transporteinheit ist die konsolidierte Journey, nicht der Meldungsstapel.

Rationale: Der oBDS transportiert Meldungsstapel — eine Meldung ist eine Transaktion eines Melders zu einem Anlass, und der Empfänger muss konsolidieren. Das oPJD-Paket dreht das um: Es transportiert die konsolidierte Journey; die Meldungs-Herkunft wandert in die Provenance der Ereignisse. Ein Paket mit leerer Episoden- und Relationsliste bleibt schema-konform — es degradiert würdevoll zum reinen Ereignis-Paket auf oBDS-Niveau.

Regeln: SemVer: Breaking Changes erhöhen major, additive Felder minor; 0.x = Entwurfsphase im Rahmen von BZKF OncoFlow. Referenzielle Integrität (existieren alle referenzierten IDs?) und die klinische Grammatik sind bewusst Validator-Ebene, nicht JSON-Schema-Ebene.

oBDS-Bezug: keine Entsprechung — Keine Paket-Entsprechung: Der oBDS transportiert Meldungsstapel je Melder und Anlass, keine konsolidierte Patient Journey.

FeldTypPflichtBedeutung
schema_versionstringjaVersion des oPJD-Schemas, gegen das dieses Paket validiert (SemVer; major = 0 während der Entwurfsphase). Jede Instanz trägt ihre Version explizit.
deliverydeliveryjaDie Austauschhülle des Pakets: Absender, Empfänger, Rechtsgrundlage, Verwendungszweck, Gültigkeit und Einschränkungen — siehe Objekt delivery.
patientpatientjaDie zentrale Bezugsperson des Pakets — pseudonymisiert oder identifiziert, je nach Einsatzkontext.
tumorsarray<tumor> (minItems 1)jaAlle Tumorentitäten des Patienten, auf die sich Ereignisse, Episoden und der Journey-Status per tumor_ref beziehen (mindestens eine).
eventsarray<event> (minItems 1)jaDie atomaren, dokumentierten Tatsachen der Journey (mindestens eine). Die oBDS-Nutzlast bleibt unverändert — Prinzip: Schicht, nicht Ersatz.
episodesarray<episode>jaDie klinischen Klammern über den Ereignissen. Ein leeres Array ist zulässig (reines Ereignis-Paket, würdevoll zu oBDS degradiert), mindert aber den Nutzwert des Pakets.
relationsarray<relation>jaTypisierte, gerichtete Bezüge zwischen Ereignissen bzw. von Ereignissen zu Episoden. Ein leeres Array ist zulässig.
journey_statusarray<journeyStatus>neinOptional: konsolidierter aktueller Zustand je Tumor — aktive Episode, letzte Gesamtbeurteilung, aktuelle Linie.

Austauschhülle (Delivery) (delivery)

Die Liefer- und Nutzungshülle des oPJD-Pakets: Wer liefert an wen, in welcher Rolle, auf welcher Rechtsgrundlage, zu welchem Zweck, mit welcher Gültigkeit und welchen Einschränkungen. Das Pflichtset entspricht dem Minimal-Set V1 der Spezifikation (zehn Pflichtfelder).

Rationale: Ein Behandlungsverlauf existiert nicht im luftleeren Raum: Beim Austausch zwischen Institutionen — etwa vom Landeskrebsregister zurück an ein Behandlungszentrum — reicht der klinische Inhalt allein nicht aus. Nicht nur der Datensatz, auch seine Berechtigung und sein Nutzungskontext müssen interoperabel sein; die Hülle macht beides maschinenlesbar.

oBDS-Bezug: Absender / Melder (oBDS-Meldungskopf) — Der oBDS kennt nur Absender- und Melder-Metadaten der Meldung. Empfänger, Übermittlungskontext, Rechtsgrundlage, Verwendungszweck und Gültigkeit haben dort keine Entsprechung — beim Datenrückfluss aus Registern ist die Hülle eine oPJD-Ergänzung.

FeldTypPflichtBedeutung
package_ididjaEindeutige Kennung des Datenpakets (Konvention: PKG-…) — Bezugspunkt für supersedes_package_id nachfolgender Lieferungen.
package_versionintegerjaVersion dieser Lieferung (ganzzahlig, ≥ 1). Zählt Updates, Nachlieferungen und Korrekturen desselben Pakets.
package_created_atstringjaErstellungszeitpunkt des Pakets als Zeitstempel (date-time, mit Zeitzone).
sending_organizationstringjaAbgebende Institution der Lieferung, z. B. Landeskrebsregister oder Klinik.
sending_unitstringneinKonkrete Organisationseinheit des Absenders (Register, Zentrum, Abteilung).
sending_systemstringjaQuellsystem der Lieferung, z. B. ONKOSTAR oder ein Registersystem.
receiving_organizationstringjaInstitution, die das Paket empfängt und an die Zweckbindung der Hülle gebunden ist.
delivery_contextuse_purposejaAnlass der Übermittlung, kodiert im use_purpose-Vokabular (z. B. treatment, research, registry_completion).
jurisdictionstringjaRechtsraum der Übermittlung (Land/Bundesland), z. B. DE-BY — Bezugsrahmen für legal_basis_category und jurisdiction_specific_rule.
responsible_contactstringneinVerantwortliche Stelle bzw. Kontakt für Rückfragen zur Lieferung.
legal_basis_categoryenum (7 Werte)jaKategorie der Rechtsgrundlage, auf der dieses Paket übermittelt wird — abschließendes Vokabular mit sieben Werten. Keine juristische Vollanalyse, sondern eine pragmatische Deklaration, die den Empfänger in die Lage versetzt, die Daten korrekt einzuordnen und zu verwenden.
legal_basis_detailstringneinGenauere Beschreibung der Rechtsgrundlage in Freitext, z. B. konkrete Landesrechtsnorm, Einwilligungsversion oder Vertrag.
jurisdiction_specific_rulestringneinBenennung der länderspezifischen Sonderregel, auf die sich die Lieferung stützt (z. B. erweiterter Nachsorge-Abruf nach Strahlentherapie), damit der Empfänger die Berechtigung nachvollziehen kann.
permitted_usearray<use_purpose> (minItems 1)jaAbschließende Liste der Verwendungszwecke, für die der Empfänger die Daten dieses Pakets nutzen darf (use_purpose-Vokabular, mindestens ein Eintrag). Zwecke außerhalb dieser Liste sind durch die Lieferung nicht gedeckt.
prohibited_usearray<use_purpose>neinExplizit ausgeschlossene Verwendungszwecke (use_purpose-Vokabular). Ergänzt permitted_use um die Möglichkeit, einzelne Nutzungen positiv zu verbieten — etwa Forschung bei einer rein versorgungsbezogenen Lieferung.
redisclosure_allowedbooleanneinDarf der Empfänger die Daten an Dritte weitergeben? Ohne Angabe ist keine Weitergabe zugesichert.
valid_fromstringneinBeginn der Gültigkeit der Berechtigung bzw. Freigabe, auf der diese Lieferung beruht.
valid_untilstringneinEnde der Gültigkeit der Berechtigung (Verfallslogik): Nach diesem Datum ist die Nutzung nicht mehr gedeckt bzw. eine Auffrischung erforderlich.
last_verified_atstringneinDatum der letzten Prüfung der Berechtigung durch den Absender.
refresh_required_afterstringneinZeitpunkt, nach dem eine Auffrischung der Lieferung bzw. der Berechtigungsprüfung erforderlich ist.
supersedes_package_ididneinReferenz auf ein vorangegangenes Paket, das durch diese Lieferung ersetzt wird — macht Korrektur- und Nachlieferungsketten nachvollziehbar.
restriction_flagbooleanneinMarker: Für dieses Paket besteht eine besondere Einschränkung. Details stehen in restriction_note.
restriction_notestringneinFreitext-Details einer besonderen Einschränkung, z. B. „nur QS, keine Forschung".
local_reconciliation_allowedbooleanneinDarf der Empfänger die Daten in den lokalen Bestand übernehmen und mit ihm abgleichen? Zentral für Register-Rückflüsse, die nur der Einsicht dienen sollen.

Consent (Einwilligung/Freigabe) (delivery.consent)

Einwilligungs- und Freigabeinformation auf Patientenebene: Status, Umfang, Gültigkeit, Widerruf. Während Rechtsgrundlage und Verwendungszweck auf Paketebene gelten, kann der Consent davon abweichen — er wird deshalb eigenständig geführt.

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

Regeln: Optional, aber empfohlen (das Minimal-Set V1 empfiehlt consent.status). Innerhalb des Objekts ist nur status Pflicht.

oBDS-Bezug: Meldung/Meldebegruendung — Der oBDS begründet nur den Meldeweg an das Register; eine differenzierte Consent-Deklaration (Status, Umfang, Gültigkeit, Widerruf) für den Austausch fehlt dort.

FeldTypPflichtBedeutung
statusenum (5 Werte)jaStatus der Einwilligung bzw. Freigabe des Patienten für diese Lieferung: present, not_present, revoked, unknown oder not_required.
scopestringneinUmfang der Einwilligung in Freitext, z. B. Versorgung, Forschung, standortübergreifend.
valid_fromstringneinBeginn der Gültigkeit der Einwilligung.
valid_untilstringneinEnde der Gültigkeit der Einwilligung.
revocation_datestringneinDatum des Widerrufs der Einwilligung — gehört zu status = revoked.

Patient (patient)

Die zentrale Bezugsperson des Pakets. Bewusst schlank: stabile Kennung samt Kennungsart (pseudonym/identified), optional Geburtsdatum, Geschlecht und unveränderte oBDS-Stammdaten. Die klinische Information hängt an Tumoren, Ereignissen und Episoden — nicht am Patientenobjekt.

Rationale: Ein Paket transportiert genau einen Patienten mit seiner konsolidierten Journey — im Gegensatz zum oBDS-Meldungsstapel, in dem die Patientenidentität über Sender hinweg fragil ist. Ob pseudonymisiert oder identifiziert geliefert wird, entscheiden Einsatzkontext und Rechtsgrundlage; das Modell erzwingt keine Identifikationstiefe.

oBDS-Bezug: Patient/Patienten_Stammdaten — Die Stammdaten können unverändert als obds-Nutzlast mitgeführt werden; das oPJD selbst hält die Identität bewusst minimal.

FeldTypPflichtBedeutung
patient_ididjaStabile Kennung des Patienten innerhalb des Pakets — Pseudonym oder identifizierende ID gemäß id_kind.
id_kindenum (2 Werte)jaArt der Patientenkennung: pseudonym (pseudonymisiert) oder identified (identifiziert) — je nach Einsatzkontext und Rechtsgrundlage der Lieferung.
birth_datestringneinGeburtsdatum des Patienten; bei pseudonymisierten Lieferungen ggf. bewusst weggelassen oder vergröbert.
sexenum (4 Werte)neinGeschlecht nach oBDS-Vokabular: M (männlich), W (weiblich), D (divers), U (unbekannt).
obdsobjectneinOptionale unveränderte oBDS-Stammdaten-Nutzlast des Patienten.

Tumor / Entität (tumor)

Eine konkrete Tumorerkrankung des Patienten — der Anker, auf den sich Ereignisse, Episoden und der Journey-Status per tumor_ref beziehen. Mehrere Tumoren pro Patient sind möglich. Kern ist die ICD-10-Diagnose mit Diagnosedatum, optional ICD-O-Morphologie und Seitenlokalisation.

Rationale: Bei Patienten mit mehreren Tumoren entscheidet erst die explizite Entität, welche Maßnahme zu welcher Erkrankung gehört — genau hier scheitert die oBDS-Behauptung Stellung_OP: Bei zwei Tumoren oder zwei Eingriffen ist sie unauflösbar. Die verpflichtende tumor_id ist Zutat 1 der Secret Sauce: Man kann nur auf das zeigen, was eine Adresse hat.

oBDS-Bezug: Meldung/Tumorzuordnung — Die oBDS-Tumorzuordnung liefert Diagnose und Tumor-ID je Meldung; das oPJD konsolidiert daraus eine paketweite Entität mit stabiler Adresse.

FeldTypPflichtBedeutung
tumor_ididjaStabile Kennung der Tumorentität innerhalb des Pakets (Konvention: TU-…) — Ziel aller tumor_ref-Verweise.
icd_o_morphologystringneinICD-O-3-Morphologie des Tumors, z. B. 8140/3.
diagnosis_datestringjaDatum der Diagnosestellung des Tumors; die Genauigkeit kann über diagnosis_date_precision angegeben werden.
diagnosis_date_precisiondate_precisionneinGenauigkeit des Diagnosedatums nach oBDS-Konvention (E/T/M/J).
lateralitystringneinSeitenlokalisation des Tumors nach oBDS-Vokabular (z. B. L, R, B, M, U).
obdsobjectneinOptionale unveränderte oBDS-Nutzlast der Tumorzuordnung bzw. Diagnosemeldung.

ICD-10-Diagnose (tumor.icd10)

Die ICD-10-GM-Kodierung der Tumordiagnose: code (Pflicht, z. B. C34.1) und optional die Katalogversion. Die semantische Basis bleibt der oBDS — das oPJD führt keine eigenen Diagnosecodes ein.

Rationale: Konstruktionsprinzip „Schicht, nicht Ersatz": Die Diagnose bleibt ICD-10-GM wie im oBDS; die mitgeführte Katalogversion hält Kodierungsstände über Jahre vergleichbar.

oBDS-Bezug: Tumorzuordnung/Primaertumor_ICD — Direkte Übernahme aus der oBDS-Tumorzuordnung (Code samt Katalogversion).

FeldTypPflichtBedeutung
codestringjaICD-10-GM-Code der Tumordiagnose, z. B. C34.1.
versionstringneinVersion des ICD-10-GM-Katalogs, mit dem kodiert wurde, z. B. 2025.

Ereignis (event)

Die atomare Einheit der Journey: eine dokumentierte Tatsache mit Typ, Datum und Tumorbezug — Diagnose, Beschluss, Eingriff, Befund, Therapie, Verlaufsbewertung. Trägt optional die unveränderte oBDS-Nutzlast (obds) und verpflichtend den Metadaten-Layer (meta: provenance, currency, quality). Ereignisse tragen keinen Episoden-Verweis — die Zuordnung wohnt in der Episode.

Rationale: Ereignisse sind die unantastbare Faktenbasis: Die Interpretationsschicht (Episoden, Relationen) zeigt auf sie, verändert sie aber nie — ändert sich die Kuratierung, ändern sich die Klammern, nie die Ereignisse. Die verpflichtende event_id (Zutat 1) macht jedes Ereignis adressierbar; der oBDS kennt Ereignis-Anker (OP_ID, ST_ID, SYST_ID) nur optional, und die Praxis ignoriert sie.

Regeln: Pflichtfelder: event_id, type, date, tumor_ref, meta.

oBDS-Bezug: Meldung (Dokumentzweige Diagnose/Pathologie/OP/ST/SYST/Verlauf/Tumorkonferenz/Tod) — Ein Ereignis entspricht in der Regel einem oBDS-Dokumentzweig einer Meldung; die Nutzlast bleibt byte-genau erhalten, die Meldungs-Herkunft wandert in meta.provenance.

FeldTypPflichtBedeutung
event_ididjaStabile Kennung des Ereignisses (Konvention: EVT-…) — Adresse für Episoden (events[], start_event/end_event) und Relationen (from/to).
typeenum (10 Werte)jaTyp des Ereignisses. Die ersten acht Werte sind auf die oBDS-Dokumentzweige gemappt (Diagnose, Pathologie, OP, ST, SYST, Verlauf, Tumorkonferenz, Tod); study_enrollment ist der oPJD-Zusatztyp für den Studieneinschluss, other der Auffangwert.
datestringjaDatum des Ereignisses (ISO-8601-Datum); die Genauigkeit kann über date_precision angegeben werden.
date_precisiondate_precisionneinGenauigkeit des Ereignisdatums nach oBDS-Konvention (E/T/M/J).
tumor_refidjaPflicht-Bezug auf die Tumorentität (tumor_id), zu der das Ereignis gehört — bei Mehrfachtumoren entscheidend. Bewusst kein Relationstyp: Der Tumorbezug ist Pflichtfeld jedes Ereignisses.
key_eventbooleanneinMarkiert ein Ereignis mit strukturierender Funktion für den Verlauf: Wendepunkte, Strategieentscheidungen, Übergänge zwischen Behandlungsphasen — typisch Erstdiagnose, Tumorboard-Beschluss, Progressionsnachweis.
obdsobjectneinDie unveränderte oBDS-Nutzlast des zugrunde liegenden Dokuments — byte-genau, ohne Umkodierung. Semantische Basis bleibt der oBDS (ICD-10-GM, ICD-O-3, OPS, TNM); das oPJD fügt keine neuen medizinischen Codes ein.oBDS: Meldung/* (jeweiliger Dokumentzweig)
notestringneinFreitext-Anmerkung zum Ereignis, z. B. eine Kurzbeschreibung des Befunds.

Episode (klinische Klammer) (episode)

Die Klammer: ein klinisch definierter Sinnabschnitt, der Ereignisse zu einem zusammenhängenden Behandlungsabschnitt gruppiert — begrenzt durch klinische Ereignisse, nicht durch Kalenderfenster. Zwei Kategorien: Verlaufsphasen strukturieren den Behandlungsverlauf und sollen sich je Tumor nicht überlappen; Kontextklammern (Studienphase, Primär-/Zentrumsfall) laufen parallel dazu. Die Zuordnung wohnt in der Episode (events[]), nicht im Ereignis.

Rationale: Zutat 2 der Secret Sauce: Der oBDS kennt keine Episode — Kontext existiert dort nur als unverankerte lokale Behauptung (Stellung_OP, Intention je Einzeltherapie). Als eigenes Objekt mit Adresse, Grenzereignissen und eigener Qualitätsangabe macht die Klammer aus „Stellung_OP=N" die prüfbare Aussage „gehört zur neoadjuvanten Episode vor der operativen Episode X". Und die Episodengrammatik macht Lücken zu Daten: Jeder Typ definiert, was in ihm erwartbar ist.

Regeln: Pflicht: episode_id, type, tumor_ref, events (minItems 1), meta. Bedingt verpflichtend: study bei study_participation, organization bei primary_case/center_case. Überlappungsregel (Validator, nicht Schema): Verlaufsphasen je Tumor überlappungsfrei; Kontextklammern dürfen sich mit Verlaufsphasen und untereinander beliebig überlappen.

oBDS-Bezug: keine Entsprechung — Keine Entsprechung: Der oBDS modelliert keine Behandlungsepisoden. Indizien (Stellung_OP, y-TNM, Meldeanlass, Datumsfenster) erlauben nur die algorithmische Ableitung (meta.quality = derived).

FeldTypPflichtBedeutung
episode_ididjaStabile Kennung der Episode (Konvention: EP-…) — Adresse für Relationen auf Episoden (assesses, triggers) und für journey_status.active_episode.
typeenum (13 Werte)jaTyp der Klammer: neun Verlaufsphasen (first_diagnosis, neoadjuvant, surgical, adjuvant, follow_up, progression, palliative_line, active_surveillance, watchful_waiting), drei Kontextklammern (study_participation, primary_case, center_case) und other als Auffangwert. Verlaufsphasen strukturieren den Behandlungsverlauf, Kontextklammern den Versorgungs- bzw. Dokumentationskontext.
tumor_refidjaPflicht-Bezug auf die Tumorentität (tumor_id), deren Verlauf die Episode strukturiert.
intentenum (4 Werte)neinIntention bzw. Therapieziel auf Episodenebene: curative, palliative, mixed oder unknown. Die Klammer trägt die Strategie — nicht mehr nur die Einzeltherapie.oBDS: OP/ST/SYST: Intention
organizationstringbedingtDie deklarierende bzw. behandelnde Einrichtung einer Fallklassifikations-Klammer — beantwortet: Wessen Fallzählung gilt hier? Pflicht bei type = primary_case oder center_case.
line_numberintegerneinNummer der Therapielinie (ganzzahlig, ≥ 1), vor allem für palliative_line — anschlussfähig an die ESMO-Zählung. Macht Linien zählbar und Linienwechsel abfragbar.
start_eventidneinDas Ereignis, das die Episode klinisch eröffnet (event_id) — z. B. der Tumorboard-Beschluss für die neoadjuvante Phase oder der Strategiebeschluss für die Überwachung. Die Episode ist durch klinische Ereignisse begrenzt, nicht durch Kalenderdaten.
end_eventidneinDas Ereignis, das die Episode klinisch beendet (event_id) — z. B. die OP-Freigabe nach Restaging für die neoadjuvante Phase oder das Ereignis, das den Strategiewechsel begründet, für die Überwachung.
eventsarray<id> (minItems 1)jaAlle Ereignisse dieser Episode als Liste von event_ids (mindestens eines). Die Zuordnung wohnt in der Episode, nicht im Ereignis: Die Klammer ist die kuratierbare Interpretationsschicht, die Ereignisse bleiben unangetastet.
statusenum (3 Werte)neinBearbeitungsstand der Episode: active (läuft), completed (abgeschlossen) oder unknown.
metainterpretation_metajaMetadaten der Interpretationsschicht für diese Episode: Ist die Klammer algorithmisch vorgeschlagen (derived) oder fachlich bestätigt (curated) — samt Indizien (derived_from) und annotierender Rolle.

Studienbezug (episode.study)

Der Studienbezug einer Studienphase: Register (NCT/DRKS/EudraCT/ISRCTN/other), Registernummer (code), optional Studienname/Akronym und Arm. Pflicht bei type = study_participation.

Rationale: Eine Studienphase ohne identifizierbare Studie wäre eine leere Behauptung. Der Registerbezug macht die Teilnahme extern auflösbar (z. B. über ClinicalTrials.gov) und standortübergreifend zusammenführbar.

Regeln: Bedingt verpflichtend: Das Schema erzwingt study bei study_participation; innerhalb des Objekts sind registry und code Pflicht.

oBDS-Bezug: keine Entsprechung — Keine oBDS-Entsprechung; Studieninformation liegt sonst nur in Studiensystemen.

FeldTypPflichtBedeutung
registryenum (5 Werte)jaDas Studienregister, in dem die Studie geführt wird: NCT, DRKS, EudraCT, ISRCTN oder other.
codestringjaRegisternummer der Studie im angegebenen Register, z. B. die NCT-Nummer.
namestringneinStudienname bzw. Akronym, z. B. SYNTH-NEO-01.
armstringneinStudienarm des Patienten, sofern bekannt und übermittelbar (z. B. bei Verblindung nicht verfügbar).

Relation (Bezug) (relation)

Gerichteter, typisierter Bezug als eigenständiges Datenobjekt mit eigener ID und eigener Qualitätsangabe. Die Leserichtung folgt der Grammatik, nicht der Zeit: from [Subjekt] —type [Verb]→ to [Objekt]; from ist immer das Element, das den Bezug ausspricht. Vier abschließende Typen: result_of, implements, assesses, triggers.

Rationale: Zutat 3 der Secret Sauce: die minimalen Kausalitäten. Bewusst keine umfassende Ontologie, sondern genau die vier Bezüge, die heute niemand aus oBDS-Meldungen ableiten kann — und die jeder braucht, der einen Verlauf verstehen, prüfen oder auswerten will. Als eigenes Objekt trägt die Relation ihre eigene Herkunft (curated/derived): Eine Kante kann Hypothese sein, ohne die Ereignisse anzutasten. Bewusst kein Relationstyp sind der Tumorbezug (Pflichtfeld tumor_ref), der OP-Zweck (Intention in der Nutzlast) und die Episodenzugehörigkeit (events[]) — die Klammer gruppiert, die Relation verbindet.

Regeln: Pflicht: relation_id, type, from, to, meta. Erwartete Ziele je Typ: result_of → Ereignis, implements → Ereignis, assesses → Episode oder Ereignis, triggers → Episode. Neue Typen entstehen nur über den Governance-Prozess.

oBDS-Bezug: keine Entsprechung — Keine Entsprechung: Der oBDS kennt keine expliziten Bezüge zwischen Dokumenten; die optionalen Anker OP_ID/ST_ID/SYST_ID werden in der Praxis nicht einmal eingelesen.

FeldTypPflichtBedeutung
relation_ididjaStabile Kennung der Relation (Konvention: REL-…).
typeenum (4 Werte)jaArt des Bezugs — abschließendes Vokabular: result_of („ist Ergebnis von"), implements („setzt um"), assesses („beurteilt"), triggers („löst aus"). Die Typbezeichner sind englische, maschinenlesbare Schlüssel; die deutsche Lesart ist normativer Bestandteil der Spezifikation, nicht bloße Übersetzung.
fromidjaDie event_id des aussprechenden Ereignisses — des Elements, das den Bezug ausspricht: der Befund (result_of), die Maßnahme (implements), die Bewertung (assesses), der Auslöser (triggers). Grammatisches Subjekt der Relation.
toidjaDie Kennung des Bezugsziels — grammatisches Objekt der Relation. Typabhängig: event_id bei result_of (der Eingriff) und implements (der Beschluss); episode_id oder event_id bei assesses; episode_id bei triggers (die neu beginnende Klammer).
notestringneinFreitext-Anmerkung zur Relation, z. B. die Begründung des Bezugs.
metainterpretation_metajaMetadaten der Interpretationsschicht für diese Relation: curated oder derived, samt Indizien. Eine Kante kann Maschinen-Hypothese sein, ohne dass die verbundenen Ereignisse davon berührt werden.

Journey-Status (journey_status)

Optionaler konsolidierter aktueller Zustand je Tumor: aktive Episode, aktuelle Therapielinie und letzte Gesamtbeurteilung. Eine abgeleitete Momentaufnahme zum Lieferzeitpunkt — keine neue Faktenquelle.

Rationale: Beantwortet die häufigste klinische Frage — „Wo steht dieser Patient gerade?" — ohne dass der Empfänger die gesamte Journey rekonstruieren muss (z. B. für die Tumorboard-Vorbereitung). Die Redundanz ist bewusst: Der Status muss aus Episoden und Ereignissen ableitbar sein; eine Abweichung ist ein Validator-Befund.

Regeln: Optional; je Tumor ist höchstens ein Eintrag sinnvoll. tumor_ref ist Pflicht.

oBDS-Bezug: keine Entsprechung — Keine Entsprechung; im oBDS müsste der aktuelle Stand aus dem Meldungsstapel rekonstruiert werden.

FeldTypPflichtBedeutung
tumor_refidjaDie Tumorentität (tumor_id), deren aktueller Zustand beschrieben wird.
active_episodeidneinepisode_id der aktuell laufenden Episode dieses Tumors — Gegenstück zu episode.status = active.
current_lineintegerneinAktuelle Therapielinie des Tumors (≥ 1) — Spiegel von episode.line_number der laufenden Linie.

Letzte Gesamtbeurteilung (journey_status.last_assessment)

Verweis auf das Ereignis der letzten Verlaufsbeurteilung (event_ref) samt Gesamtbeurteilung nach oBDS-Vokabular (z. B. V, T, K, P, U).

Rationale: Die letzte Bewertung ist der klinisch relevanteste Einzelwert der Momentaufnahme; als Verweis auf ein adressierbares Ereignis bleibt sie belegbar statt frei behauptet.

oBDS-Bezug: Verlauf/Gesamtbeurteilung — Der Wert folgt dem oBDS-Verlaufsvokabular; der Verweis auf das tragende Ereignis ist oPJD-Struktur.

FeldTypPflichtBedeutung
event_refidjaevent_id des Verlaufsereignisses, das die letzte Gesamtbeurteilung trägt.
overall_assessmentstringneinGesamtbeurteilung nach oBDS-Vokabular, z. B. V = Vollremission, T = Teilremission, K = keine Änderung, P = Progression, U = unbekannt.

Ereignistypen

Typ des Ereignisses. Die ersten acht Werte sind auf die oBDS-Dokumentzweige gemappt (Diagnose, Pathologie, OP, ST, SYST, Verlauf, Tumorkonferenz, Tod); study_enrollment ist der oPJD-Zusatztyp für den Studieneinschluss, other der Auffangwert.

diagnosisDiagnoseDiagnosis

Diagnosestellung der Tumorerkrankung — typischerweise das Ereignis der histologischen Sicherung bzw. Erstdiagnose mit Staging-Information (cTNM). Häufig Schlüsselereignis und Kern der Erstdiagnose-Episode.

Rationale: Die Diagnose ist der Ankerpunkt jeder Journey: Von ihr aus zählen Chronologie-Schranken („nichts vor der Diagnose") und beginnt die Erstdiagnose-Episode.

oBDS-Bezug: Meldung/Diagnose — Direkt auf den oBDS-Dokumentzweig Diagnose gemappt.

pathology_reportPathologiebefundPathology report

Histologischer bzw. pathologischer Befund — von der Biopsie-Histologie bis zum postoperativen Staging (pTNM/ypTNM, Residualstatus). Spricht per result_of-Relation aus, aus welchem Eingriff das Material stammt.

Rationale: Kernfall der dokumentierten oBDS-Lücke: Welche Pathologie sich auf welche Tumor-OP bezieht, ist aus der Meldung nicht ableitbar. Erst der als Ereignis adressierbare Befund kann per Relation auf seinen Eingriff zeigen — ausgesprochen statt geraten.

Klinischer Hinweis: Das y-Präfix im TNM beweist neoadjuvante Vorbehandlung; der Abgleich Befund ↔ vorausgehende neoadjuvante Episode wird im oPJD prüfbar. Befunde können auch von Biopsien stammen, die selbst nicht meldepflichtig sind.

oBDS-Bezug: Meldung/Pathologie — Direkt auf den oBDS-Dokumentzweig Pathologie gemappt — dort jedoch ohne Verweis auf den liefernden Eingriff.

surgeryOperationSurgery

Operativer Eingriff am Tumor — von der diagnostischen Biopsie bis zur Resektion (OPS-kodiert in der Nutzlast). Der Zweck des Eingriffs (Diagnosesicherung vs. Therapie) steht als Intention in der oBDS-Nutzlast, nicht in einer Relation.

Rationale: Als adressierbares Ereignis wird der Eingriff zum Bezugsziel: Der Pathobefund zeigt per result_of auf ihn, die Operation selbst per implements auf den Beschluss, den sie umsetzt.

oBDS-Bezug: Meldung/OP — Direkt auf den oBDS-Dokumentzweig OP gemappt; der optionale Anker OP_ID wird in der Praxis nicht genutzt.

radiation_therapyStrahlentherapieRadiation therapy

Strahlentherapeutische Behandlung (oBDS-Dokumentzweig ST). Stellung zur OP und Intention bleiben in der Nutzlast; die Verlaufseinordnung übernimmt die Episode.

Rationale: Aus der unverankerten Behauptung Stellung_OP=N/A (ohne Bezugs-OP) wird die prüfbare Zugehörigkeit zu einer neoadjuvanten oder adjuvanten Episode.

oBDS-Bezug: Meldung/ST — Direkt auf den oBDS-Dokumentzweig ST gemappt.

systemic_therapySystemtherapieSystemic therapy

Systemische Therapie — Chemo-, Immun-, Hormon- oder zielgerichtete Therapie (oBDS-Dokumentzweig SYST). Einzelgaben oder Zyklen können als mehrere Ereignisse geführt werden, die die Episode bündelt.

Rationale: Die Verlaufsbedeutung einer Systemtherapie (neoadjuvant? Linie 2?) ist im oBDS nur lokale Behauptung (Stellung_OP, Intention). Erst die Episode macht daraus prüfbare Zugehörigkeit — und mit palliative_line samt line_number werden Therapielinien überhaupt zählbar.

oBDS-Bezug: Meldung/SYST — Direkt auf den oBDS-Dokumentzweig SYST gemappt.

progress_reportVerlaufsbefundProgress report

Verlaufs- bzw. Statusbeurteilung (oBDS-Dokumentzweig Verlauf) mit Gesamtbeurteilung — vom Nachsorgebefund bis zum Progressionsnachweis. Bezieht sich eine Bewertung erkennbar auf eine Behandlungsphase, spricht sie das per assesses aus; ein Progressionsnachweis kann per triggers die nächste Episode auslösen.

Rationale: Im oBDS trägt der Verlauf Gesamtbeurteilungen ohne Bezugsobjekt — worauf sich die Bewertung bezieht, ist dort nicht ausdrückbar. Als typisiertes Ereignis mit Relationen bekommt die Verlaufsbewertung ihren Gegenstand.

Klinischer Hinweis: Nicht jeder Verlauf braucht eine assesses-Relation — ein allgemeiner Nachsorge-Verlauf bleibt ein einfaches Ereignis in der Nachsorge-Episode.

oBDS-Bezug: Meldung/Verlauf — Direkt auf den oBDS-Dokumentzweig Verlauf gemappt.

tumor_boardTumorkonferenzTumor board

Tumorkonferenz mit Therapieempfehlung — der dokumentierte Behandlungsplan. Typisches Schlüsselereignis; durchgeführte Maßnahmen zeigen per implements auf den Beschluss zurück.

Rationale: Leitlinienadhärenz wird messbar: Eine Empfehlung ohne implements-Relation binnen definierter Frist ist ein QS-Signal, die Zeit von Beschluss bis Therapiebeginn eine Kennzahl. Im oBDS existiert die typisierte Empfehlung, aber kein Rückverweis der ausgeführten Therapie — Plan und Umsetzung bleiben unverbunden.

oBDS-Bezug: Meldung/Tumorkonferenz (Menge_Therapieempfehlung) — Direkt auf den oBDS-Dokumentzweig Tumorkonferenz gemappt; die Empfehlungstypen (z. B. AS/WW/WS, OP, CH) liefern zugleich Ableitungsindizien für Episoden.

deathTodDeath

Tod des Patienten (oBDS-Dokumentzweig Tod) — das terminale Ereignis der Journey; Todesursache und Tumorbezug stehen in der Nutzlast.

Rationale: Das terminale Ereignis ist die harte Chronologie-Schranke („nichts nach dem Tod") und der Endpunkt für Überlebenszeitauswertungen.

oBDS-Bezug: Meldung/Tod — Direkt auf den oBDS-Dokumentzweig Tod gemappt.

study_enrollmentStudieneinschlussStudy enrollmentseit 0.2.0

Einschluss des Patienten in eine klinische Studie: Einwilligung, Registrierung, Randomisierung. Schlüsselereignis der Journey und typischer Startpunkt der Studienphase (study_participation); Herkunft typischerweise Studiendokumentation (meta.provenance = study).

Rationale: Im oBDS nicht abbildbar — der Studieneinschluss liegt sonst nur in Studiensystemen. Als eigener Ereignistyp wird er Teil der austauschbaren Journey, und die Studienteilnahme wird als Kontextklammer prüfbar.

oBDS-Bezug: keine Entsprechung — Dokumentierte oBDS-Lücke: Es existiert kein Dokumentzweig für den Studieneinschluss; das oPJD ergänzt die forschungsrelevante Information.

otherSonstiges EreignisOther event

Auffangwert für Ereignisse ohne eigenen Typ. Sparsam verwenden — die Semantik gehört möglichst in die typisierten Werte; Näheres in note bzw. der Nutzlast.

Rationale: Ein expliziter Auffangwert hält das Vokabular abschließend, ohne reale Dokumentation auszusperren; neue Typen entstehen über den Governance-Prozess, nicht ad hoc.

oBDS-Bezug: keine Entsprechung — Kein festes oBDS-Gegenstück; abhängig vom Inhalt.

Episodentypen

Verlaufsphasen

first_diagnosisErstdiagnose-EpisodeFirst-diagnosis episode

Verlaufsphase: von der Verdachtsdiagnose über Staging und histologische Sicherung bis zum ersten Behandlungsbeschluss. Enthält typischerweise Erst-Biopsie, Diagnose, Ausbreitungsdiagnostik und das erste Tumorboard.

Rationale: Die Episodengrammatik macht die Diagnostikphase prüfbar: Eine Erstdiagnose-Episode ohne Staging-Information ist eine sichtbare Lücke — Vollständigkeits- statt bloßer Schrankenprüfung.

Regeln: Verlaufsphase — soll sich je Tumor nicht mit anderen Verlaufsphasen überlappen (Validator-Regel).

oBDS-Bezug: Meldung/Diagnose (Meldeanlass diagnose) — Nur Indiz für die Ableitung; die Phase als Klammer existiert im oBDS nicht.

neoadjuvantNeoadjuvante EpisodeNeoadjuvant episode

Verlaufsphase: Systemtherapie oder Bestrahlung vor einem geplanten operativen Eingriff, einschließlich Responsebeurteilung. Beginnt typischerweise mit dem Therapiebeschluss und endet mit der Responsebeurteilung bzw. dem Übergang zur Operation.

Rationale: Heilt die tote oBDS-Behauptung Stellung_OP=N, die nicht sagt, zu welcher OP sie gehört — bei zwei Tumoren oder Eingriffen unauflösbar. Als Episode wird die Aussage prüfbar, und die Grammatik greift: Eine neoadjuvante Episode ohne assesses-Response-Beurteilung ist eine sichtbare Lücke.

Regeln: Verlaufsphase — überlappungsfrei je Tumor (Validator-Regel). Typisch: intent = curative, gefolgt von einer operativen Episode.

Klinischer Hinweis: Das ypTNM des postoperativen Befundes beweist die neoadjuvante Vorbehandlung — der oBDS trägt den Beweis (y-Präfix), erst die Episodenstruktur macht ihn prüfbar: ypTNM ohne vorausgehende neoadjuvante Episode am selben Tumor ist ein Widerspruch.

oBDS-Bezug: ST/SYST: Stellung_OP=N (+ ycTNM) — Nur Ableitungsindizien (derived_from); eine Episodenentsprechung existiert im oBDS nicht.

surgicalOperative EpisodeSurgical episode

Verlaufsphase: der operative Eingriff mit perioperativer Diagnostik, Pathologiebefund und Komplikationsmanagement.

Rationale: Grammatik-Erwartung: Eine operative Episode ohne eingehenden result_of-Pathobefund ist eine sichtbare Lücke — genau die Zuordnung Befund ↔ Eingriff, die aus oBDS-Meldungen nachweislich nicht ableitbar ist.

Regeln: Verlaufsphase — überlappungsfrei je Tumor (Validator-Regel).

oBDS-Bezug: Meldung/OP — Der Eingriff ist meldbar, die Phase als Klammer nicht.

adjuvantAdjuvante EpisodeAdjuvant episode

Verlaufsphase: postoperative Therapie zur Konsolidierung des Behandlungserfolgs — Systemtherapie oder Bestrahlung nach dem Eingriff.

Rationale: Analog zur Neoadjuvanz: Stellung_OP=A wird von der lokalen Behauptung zur prüfbaren Phasenzugehörigkeit nach der operativen Episode.

Regeln: Verlaufsphase — überlappungsfrei je Tumor (Validator-Regel). Typisch: folgt der operativen Episode.

oBDS-Bezug: ST/SYST: Stellung_OP=A — Nur Ableitungsindiz (derived_from); keine Episodenentsprechung im oBDS.

follow_upNachsorgephaseFollow-up episode

Verlaufsphase: strukturierte Nachsorge nach Abschluss der Primärbehandlung — regelmäßige Verlaufsbefunde ohne aktive Tumortherapie.

Rationale: Nachsorge wird prüfbar: Fehlende Kontrollen im erwarteten Intervall werden als Lücke sichtbar. Die zugehörige Nutzung hat mit use_purpose/follow_up ihr Gegenstück in der Austauschhülle — bis hin zu länderspezifischen Abrufregeln.

Regeln: Verlaufsphase — überlappungsfrei je Tumor (Validator-Regel).

oBDS-Bezug: Meldung/Verlauf — Verlaufsmeldungen liefern die Ereignisse; die Nachsorge als Phase existiert im oBDS nicht.

progressionProgressions-EpisodeProgression episode

Verlaufsphase: Nachweis einer Krankheitsprogression als Trigger einer neuen Therapielinie oder Strategieentscheidung — vom Progressionsbefund bis zum neuen Beschluss.

Rationale: Der Strategiewechsel wird Datum statt Interpretation: Die Progression löst per triggers die Folge-Episode aus; eine Progression ohne dokumentierte Konsequenz wird als Lücke sichtbar.

Regeln: Verlaufsphase — überlappungsfrei je Tumor (Validator-Regel).

Klinischer Hinweis: Nicht verwechseln: progress_report ist das einzelne Verlaufs-Ereignis; die Progressions-Episode ist die Klammer um Nachweis und Strategieentscheidung.

oBDS-Bezug: Verlauf/Gesamtbeurteilung (P) — Der Progressionsbefund ist meldbar; die Phase und ihre Konsequenz (triggers) sind oPJD-Struktur.

palliative_linePalliative TherapieliniePalliative treatment line

Verlaufsphase: Systemtherapie im palliativen Kontext, als zählbare Therapielinie geführt (line_number, ESMO-Zählung anschlussfähig). Konvention: intent = palliative.

Rationale: Die Therapielinie existiert im oBDS schlicht nicht — Linien zählen ist dort Projektarbeit mit Heuristiken. Als Episode mit line_number werden Linien zählbar, Zeiten von Progression bis Strategiewechsel messbar und Kohorten ohne Heuristik selektierbar.

Regeln: Verlaufsphase — überlappungsfrei je Tumor (Validator-Regel). line_number sollte gepflegt sein; der Linienwechsel wird typischerweise per triggers begründet.

oBDS-Bezug: keine Entsprechung — Dokumentierte Lücke: keine Therapielinien-Nummer im oBDS; Ableitung nur aus der Sequenz von SYST-Meldungen mit Intention=P.

active_surveillanceActive Surveillance (aktive Überwachung)Active surveillanceseit 0.2.0

Verlaufsphase: strukturierte Überwachung mit aufgeschobenem kurativem Therapieanspruch — klassisch beim Niedrigrisiko-Prostatakarzinom. Die Episode enthält die Kontrollereignisse (PSA, Bildgebung, Re-Biopsie) und endet typischerweise mit dem Ereignis, das den Strategiewechsel begründet und per triggers-Relation die aktive Therapie auslöst.

Rationale: „Keine Therapie ist auch eine Strategie": Im oBDS ist AS nur als Empfehlungstyp einer einzelnen Tumorkonferenz sichtbar (AS/WW/WS), nie als gelebte Phase. Als Episode wird die Strategie prüfbar: Eine Überwachungsepisode ohne Kontrollereignisse im erwarteten Intervall ist eine sichtbare Lücke — Lost-to-follow-up wird zum Befund.

Regeln: Verlaufsphase — soll sich je Tumor nicht mit anderen Verlaufsphasen überlappen (Validator-Regel). Konvention: intent = curative (aufgeschoben).

Klinischer Hinweis: Nicht verwechseln mit watchful_waiting: AS = kurativer Anspruch aufgeschoben, regelmäßige Kontrollen erwartet; WW = symptomorientiertes Abwarten ohne kurativen Anspruch (intent = palliative).

oBDS-Bezug: Menge_Tumorkonferenz/Tumorkonferenz/Therapieempfehlung (Typ AS) — Nur Indiz für die Ableitung (derived_from), keine Episodenentsprechung im oBDS.

watchful_waitingWatchful Waiting (abwartendes Vorgehen)Watchful waitingseit 0.2.0

Verlaufsphase: symptomorientiertes Abwarten ohne kurativen Anspruch — Intervention erst bei Beschwerden, typisch bei begrenzter Lebenserwartung oder relevanter Komorbidität. Konvention: intent = palliative.

Rationale: „Keine Therapie ist auch eine Strategie": Im oBDS nur als Empfehlungstyp (WW) einer einzelnen Tumorkonferenz sichtbar, nie als gelebte Phase. Als Episode wird das bewusste Abwarten von der bloßen Dokumentationslücke unterscheidbar.

Regeln: Verlaufsphase — soll sich je Tumor nicht mit anderen Verlaufsphasen überlappen (Validator-Regel). Konvention: intent = palliative.

Klinischer Hinweis: Nicht verwechseln mit active_surveillance: WW = ohne kurativen Anspruch, symptomorientiert; AS = kurativer Anspruch aufgeschoben, mit festem Kontrollprogramm (intent = curative).

oBDS-Bezug: Menge_Tumorkonferenz/Tumorkonferenz/Therapieempfehlung (Typ WW) — Nur Indiz für die Ableitung (derived_from), keine Episodenentsprechung im oBDS.

Kontextklammern

study_participationStudienphaseStudy participationseit 0.2.0

Kontextklammer: vom Studieneinschluss (Ereignistyp study_enrollment) bis zum Ende der Studienteilnahme (EOT/EOS). Trägt verpflichtend den Studienbezug (study: Register, Nummer, optional Name und Arm) und läuft parallel zu den Verlaufsphasen — die Protokoll-Chemotherapie bleibt Teil der neoadjuvanten Phase und der Studienphase.

Rationale: Der oBDS kennt keinen Studieneinschluss; die Studienteilnahme liegt sonst nur in Studiensystemen. Als Kontextklammer wird sie Teil der austauschbaren Journey — und die Parallelität zeigt, welche Versorgung unter Protokoll stattfand (Provenance: study).

Regeln: Kontextklammer — darf sich mit Verlaufsphasen und anderen Kontextklammern beliebig überlappen; dasselbe Ereignis darf in mehreren Klammern referenziert sein. Das Schema erzwingt study bei diesem Typ.

oBDS-Bezug: keine Entsprechung — Dokumentierte Lücke: kein Studieneinschluss und keine Studienteilnahme im oBDS.

primary_casePrimärfallPrimary caseseit 0.2.0

Kontextklammer: Fallklassifikation aus der Zertifizierungswelt (DKG/OnkoZert) — Ersterkrankung, deren Primärtherapie (bzw. wesentliche Teile) in der benannten Einrichtung erfolgt. Die Klammer nennt verpflichtend die deklarierende Einrichtung (organization).

Rationale: „Wessen Fall ist das, wer zählt ihn?" — beim Austausch zwischen Zentren muss der Empfänger wissen, wessen Zählung er vor sich hat. Das oPJD transportiert die Deklaration der Einrichtung samt Herkunft und Qualität; es rechnet die Klassifikation nicht nach (deklariert, nicht berechnet).

Regeln: Kontextklammer — überlappt frei. Das Schema erzwingt organization. Die exakten Definitionen variieren je Zertifizierungssystem und Kennzahlenjahr.

Klinischer Hinweis: Nicht verwechseln mit center_case: Primärfall = Ersterkrankung mit Primärtherapie in der Einrichtung; Zentrumsfall = geführt/mitbehandelt ohne Erfüllung der Primärfall-Kriterien (z. B. Übernahme nach auswärtiger Ersttherapie).

oBDS-Bezug: keine Entsprechung — Keine oBDS-Entsprechung; Herkunft ist die Zertifizierungsdokumentation (provenance: certification).

center_caseZentrumsfallCenter caseseit 0.2.0

Kontextklammer: Der Fall wird vom Zentrum geführt oder mitbehandelt, ohne die Primärfall-Kriterien zu erfüllen — z. B. Übernahme nach auswärtiger Ersttherapie. Nennt verpflichtend die deklarierende Einrichtung (organization).

Rationale: Dieselbe Journey kann bei zwei Zentren unterschiedlich zählen. Die transportierte Deklaration (statt einer Nachberechnung) macht beim Austausch transparent, wessen Fallzählung gilt.

Regeln: Kontextklammer — überlappt frei. Das Schema erzwingt organization.

Klinischer Hinweis: Nicht verwechseln mit primary_case: Der Zentrumsfall erfüllt die Primärfall-Kriterien gerade nicht — etwa weil die Ersttherapie auswärts erfolgte.

oBDS-Bezug: keine Entsprechung — Keine oBDS-Entsprechung; Herkunft ist die Zertifizierungsdokumentation (provenance: certification).

otherSonstige EpisodeOther episode

Auffangwert für Klammern ohne eigenen Typ. Sparsam verwenden; neue Episodentypen entstehen über den Governance-Prozess, nicht ad hoc.

Rationale: Hält das Vokabular abschließend, ohne reale Verläufe auszusperren.

oBDS-Bezug: keine Entsprechung — Kein festes oBDS-Gegenstück; abhängig vom Inhalt.

Relationstypen

Art des Bezugs — abschließendes Vokabular: result_of („ist Ergebnis von"), implements („setzt um"), assesses („beurteilt"), triggers („löst aus"). Die Typbezeichner sind englische, maschinenlesbare Schlüssel; die deutsche Lesart ist normativer Bestandteil der Spezifikation, nicht bloße Übersetzung.

result_ofist Ergebnis vonIs result of

Ein Befund verweist auf die Maßnahme, aus der er hervorgegangen ist: Der Pathologiebefund ist Ergebnis der Lobektomie, die Molekularpathologie Ergebnis der Biopsie. from = der Befund (spricht den Bezug aus), to = der Eingriff, der das Material oder Resultat geliefert hat. Beantwortet: „Woher stammt dieser Befund?" — der Pfeil zeigt zeitlich rückwärts, die Leserichtung folgt der Grammatik, nicht der Zeit.

Rationale: Macht prüfbar: Eine operative Episode ohne eingehenden result_of-Pathobefund ist eine sichtbare Lücke; ein Befunddatum vor dem Eingriffsdatum ein Widerspruch. Genau diese Zuordnung ist aus oBDS-Meldungen nachweislich nicht ableitbar — im oPJD wird sie ausgesprochen statt geraten.

Klinischer Hinweis: Nicht verwechseln: result_of ist echte Herkunft (dieses Präparat, dieser Eingriff) — nicht bloße zeitliche Nähe. Befunde können auch von Biopsien stammen, die selbst nicht meldepflichtig sind.

oBDS-Bezug: keine Entsprechung — Dokumentierte Kernlücke: kein Verweis vom Pathologiebefund auf den liefernden Eingriff; die optionalen Anker (OP_ID) sind praktisch bedeutungslos.

implementssetzt umImplements

Eine durchgeführte Maßnahme erklärt, auf welchen Beschluss oder welche Empfehlung sie antwortet: Die Chemotherapie setzt den Tumorboard-Beschluss um, die Operation die OP-Freigabe. from = die Maßnahme (OP, Systemtherapie, Bestrahlung), to = der Beschluss bzw. die Empfehlung (typisch: Tumorboard). Beantwortet: „Worauf reagiert diese Therapie?"

Rationale: Macht prüfbar: Eine Tumorboard-Empfehlung ohne implements-Relation binnen definierter Frist wird zum messbaren Leitlinienadhärenz-Signal; die Zeit von Beschluss bis Therapiebeginn wird zur Kennzahl. Im oBDS existiert die typisierte Empfehlung, aber kein Rückverweis der ausgeführten Therapie — Plan und Umsetzung bleiben unverbunden.

Klinischer Hinweis: Nicht verwechseln: implements heißt nicht „eins zu eins wie empfohlen". Abweichungen (Patientenwunsch, Toxizität) bleiben in der Nutzlast dokumentiert — die Relation sagt nur, worauf die Maßnahme antwortet.

oBDS-Bezug: Tumorkonferenz/Therapieempfehlung — Die Empfehlung existiert im oBDS (typisiert CH/HO/IM/OP/…), aber ohne Rückverweis der ausgeführten Therapie; die Relation ergänzt die fehlende Kante.

assessesbeurteiltAssesses

Ein Bewertungsereignis benennt, was es bewertet: Das Restaging-CT beurteilt die neoadjuvante Episode (Response), die Verlaufsbeurteilung die palliative Erstlinie (Ansprechen). from = das Bewertungsereignis (Verlauf, Restaging), to = typischerweise eine Episode, ausnahmsweise eine einzelne Maßnahme. Beantwortet: „Was bewertet dieser Verlauf?"

Rationale: Macht prüfbar: Eine neoadjuvante Episode ohne assesses-Relation bedeutet: Response-Beurteilung fehlt. Und ein ypTNM ohne vorausgehende neoadjuvante Episode ist ein Widerspruch — der oBDS trägt den Beweis (y-Präfix), erst die Struktur macht ihn prüfbar. Die Response-Beurteilung bekommt ihren Gegenstand.

Klinischer Hinweis: Nicht verwechseln: Nicht jeder Verlauf braucht assesses — nur wo sich eine Bewertung erkennbar auf eine Behandlungsphase bezieht. Ein allgemeiner Nachsorge-Verlauf bleibt ein einfaches Ereignis in der Nachsorge-Episode.

oBDS-Bezug: keine Entsprechung — Der oBDS-Verlauf trägt Gesamtbeurteilungen ohne Bezugsobjekt — worauf sich die Bewertung bezieht, ist dort nicht ausdrückbar.

triggerslöst ausTriggers

Ein auslösendes Ereignis begründet den Beginn einer neuen Episode oder Therapielinie: Der Progressionsnachweis löst die Progressions-Episode bzw. die neue Linie aus. from = der Auslöser (Progression, Toxizität, Patientenentscheidung), to = die neu beginnende Episode. Als einziger Typ zeigt triggers in die Zukunft. Beantwortet: „Warum beginnt diese Episode?"

Rationale: Macht prüfbar: Eine Progression ohne triggers-Relation ist ein Verlauf ohne dokumentierte Konsequenz; umgekehrt sollte jede Folge-Episode einen Auslöser haben — Übergänge werden erklärbar statt erratbar. Der Strategiewechsel wird Datum statt Interpretation.

Klinischer Hinweis: Nicht verwechseln: triggers begründet den Übergang („warum gibt es die neue Klammer"), implements die Umsetzung („worauf antwortet die Maßnahme"). Typische Kette: Die Progression triggers die neue Episode; deren Therapie implements den neuen Tumorboard-Beschluss.

oBDS-Bezug: keine Entsprechung — Keine Entsprechung: Der oBDS kennt keine Begründungskante zwischen Befund und Folgephase.

Metadaten & Interpretationsschicht

Ereignis-Metadaten (event.meta)

Der Metadaten-Layer eines Ereignisses beantwortet drei Fragen: Woher stammt die Information (provenance)? Wie synchron ist sie mit dem Geschehen (currency)? Wie belastbar ist sie (quality)? Ergänzt um Quellsystem, Quellkategorie und Zeitstempel (recorded_at, last_confirmed_at).

Rationale: Konsolidierte Journeys mischen Quellen — Primärdokumentation, Tumordokumentation, Register, Studien. Ohne Herkunfts- und Frischeangabe je Ereignis wäre die Mischung nicht mehr auseinanderzuhalten; mit ihr kann der Empfänger jede Tatsache gewichten. Die Meldungs-Herkunft des oBDS-Stapels wandert genau hierhin.

Regeln: Pflichtobjekt jedes Ereignisses; provenance, currency und quality sind Pflicht.

oBDS-Bezug: Meldung (Melder, Meldeanlass) — Melder- und Anlassinformation der oBDS-Meldung gehen in provenance/source_system auf; eine Qualitäts- oder Frischeangabe kennt der oBDS nicht.

FeldTypPflichtBedeutung
provenanceenum (6 Werte)jaWoher stammt die Information? Sechs Herkunftsklassen — von der klinischen Primärdokumentation über Tumordokumentation, Register, Studien- und Zertifizierungskontext bis zur externen Meldung.
currencyenum (3 Werte)jaWie synchron ist die Information mit dem klinischen Geschehen? Dreistufig: current, delayed, historical. Ergänzend dokumentiert last_confirmed_at die letzte Bestätigung.
qualityenum (4 Werte)jaWie belastbar ist die Information? Vierstufig: curated, derived, limited, unconfirmed. Keine wissenschaftliche Evidenzbewertung, sondern eine praktikable, aus Quelle und Prozess ableitbare Einschätzung.
source_systemstringneinName des Quellsystems, aus dem das Ereignis stammt (z. B. ONKOSTAR, KIS, Registersystem).
source_categoryenum (2 Werte)neinGrobklassifikation der Quelle: primary (originär dokumentiert) oder secondary (aus zweiter Hand übernommen).
recorded_atstringneinDatum der Erfassung bzw. Dokumentation des Ereignisses — nicht zu verwechseln mit dem klinischen Ereignisdatum (event.date).
last_confirmed_atstringneinDatum der letzten Bestätigung oder Aktualisierung der Information — ergänzt currency um einen prüfbaren Zeitpunkt.

Interpretations-Metadaten (interpretation_meta)

Metadaten der Interpretationsschicht (Episoden, Relationen): Die Klammer selbst hat eine Herkunft. quality unterscheidet zweistufig derived (algorithmisch aus oBDS-Indizien vorgeschlagen) und curated (fachlich bestätigt); derived_from nennt die Indizien, annotated_at und annotated_by_role Zeitpunkt und Rolle der Annotation.

Rationale: Zutat 4 und der entscheidende Dreh für die Machbarkeit: Ohne eigene Qualitätsangabe müsste die Klammer-Schicht von Tag eins an perfekt sein — das wäre ihr Tod. Mit ihr kann der Datensatz unvollkommen starten und transparent besser werden; der Empfänger weiß jederzeit, ob er einer Maschinen-Hypothese oder einem kuratierten Fakt vertraut.

Regeln: Pflichtobjekt an Episoden und Relationen; nur quality ist Pflicht. Bewusst zweistufig — die vierstufige Skala von event.meta.quality gilt für Tatsachen, nicht für Interpretationen.

oBDS-Bezug: keine Entsprechung — Keine Entsprechung: Der oBDS kennt keine Interpretationsschicht — und folglich keine Metadaten über sie.

FeldTypPflichtBedeutung
qualityenum (2 Werte)jaBelastbarkeit der Klammer bzw. Relation selbst: derived (algorithmisch vorgeschlagen) oder curated (fachlich bestätigt). Bewertet die Interpretation, nicht die zugrunde liegenden Ereignisse.
derived_fromarray<string>neinDie Indizien, aus denen die Interpretation abgeleitet wurde — als Liste kurzer Kennzeichen, z. B. „Stellung_OP=N", „ycTNM", „Datumsfenster", „Tumorkonferenz-Empfehlung AS".oBDS: Stellung_OP / TNM (y-Präfix) / Meldeanlass
annotated_atstringneinDatum der Annotation bzw. der letzten Bestätigung der Interpretation.
annotated_by_roleenum (3 Werte)neinDie Rolle, die die Interpretation annotiert bzw. bestätigt hat: algorithm, tumor_documentation oder physician. Bewusst eine Rolle, keine Person.

Vokabulare

delivery.legal_basis_category — Kategorie der Rechtsgrundlage

WertLabelBedeutung
clinical_careBehandlungskontextBehandlungsbezogener Datenaustausch: Die Übermittlung erfolgt im Rahmen der direkten Patientenversorgung, etwa bei Mit- oder Weiterbehandlung.
cancer_registry_lawKrebsregistergesetzÜbermittlung auf Grundlage der Krebsregistergesetzgebung von Bund oder Land — der gesetzliche Meldeweg an das Landeskrebsregister sowie der gesetzlich geregelte Datenrückfluss an Melder.
quality_assurance_regulationQS-Richtlinie/-VerordnungÜbermittlung auf Grundlage von Qualitätssicherungs-Richtlinien und -Verordnungen, z. B. gesetzlicher QS-Verfahren.
other_research_basisAndere ForschungsgrundlageForschungsübermittlung ohne individuelle Einwilligung, z. B. auf Grundlage eines Ethikvotums oder einer gesetzlichen Forschungsklausel.
contractual_data_transferVertragliche DatenübertragungÜbermittlung auf vertraglicher Grundlage, z. B. Kooperations- oder Auftragsverarbeitungsverträge zwischen Einrichtungen.
jurisdiction_specific_exceptionLänderspezifische AusnahmeÜbermittlung auf Grundlage einer länderspezifischen Sonderregel — etwa der Abruf behandlungsbezogener Daten über die 12 Monate seit dem letzten Kontakt hinaus für die Nachsorge nach Strahlentherapie. Die konkrete Regel wird in jurisdiction_specific_rule benannt.

delivery.consent.status — Einwilligungsstatus

WertLabelBedeutung
presentliegt vorEine wirksame Einwilligung bzw. Freigabe des Patienten liegt vor; Umfang und Gültigkeit stehen in scope, valid_from und valid_until.
not_presentliegt nicht vorEs liegt keine Einwilligung vor. Die Lieferung stützt sich dann auf eine andere Rechtsgrundlage (z. B. Krebsregistergesetz) — oder ihre Nutzung ist entsprechend eingeschränkt.
revokedwiderrufenEine zuvor erteilte Einwilligung wurde widerrufen. Das Widerrufsdatum steht in revocation_date; die weitere Nutzung richtet sich nach Rechtsgrundlage und Widerrufsumfang.
unknownunbekanntDer Einwilligungsstatus ist dem Absender nicht bekannt — eine ehrliche Lücke statt einer stillschweigenden Annahme.
not_requirednicht erforderlichFür diese Übermittlung ist keine Einwilligung erforderlich, weil eine gesetzliche Grundlage trägt — z. B. die Meldepflicht nach Krebsregistergesetz.

patient.id_kind — Art der Patientenkennung

WertLabelBedeutung
pseudonympseudonymisiertDie Patientenkennung ist ein Pseudonym; eine Re-Identifikation ist nur über die pseudonymisierende Stelle möglich. Typisch für Forschungs- und QS-Lieferungen.
identifiedidentifiziertDie Patientenkennung identifiziert den Patienten direkt — nur in Versorgungskontexten mit entsprechender Rechtsgrundlage.

patient.sex — Geschlecht

WertLabelBedeutung
MmännlichGeschlecht männlich (oBDS-Vokabular).
WweiblichGeschlecht weiblich (oBDS-Vokabular).
DdiversGeschlecht divers (oBDS-Vokabular).
UunbekanntGeschlecht unbekannt (oBDS-Vokabular).

event.meta.provenance — Provenance (Herkunft)

WertLabelBedeutung
primary_clinicalPrimärdokumentation KlinikDie Information stammt aus der klinischen Primärdokumentation der behandelnden Einrichtung (KIS, Befundsysteme).
tumor_documentationTumordokumentationDie Information stammt aus der spezialisierten Tumordokumentation (z. B. ONKOSTAR-Erfassung durch Dokumentarinnen und Dokumentare).
registryRegisterdatenDie Information stammt aus einem Krebsregister (z. B. Landeskrebsregister) — typisch beim Datenrückfluss an Melder.
studyStudienkontextDie Information stammt aus Studiendokumentation bzw. Studiensystemen — typisch für study_enrollment und studienbezogene Ereignisse.
certificationZertifizierungsdokumentationDie Information stammt aus der Zertifizierungswelt (z. B. DKG/OnkoZert-Kennzahlenprozesse) — typisch für die Fallklassifikations-Klammern primary_case und center_case.
externalExterne MeldungDie Information stammt von einer externen Stelle außerhalb der eigenen Dokumentationskette, z. B. einer auswärtigen Einrichtung.

event.meta.currency — Aktualität

WertLabelBedeutung
currentaktuellZeitnah zum Geschehen dokumentiert; gilt als aktueller Stand.
delayedverzögertMit relevantem Zeitversatz eingegangen oder dokumentiert — z. B. Registerrückfluss oder Nachmeldung. Der Inhalt kann korrekt, aber nicht mehr der neueste Stand sein.
historicalhistorischAus Altdatenübernahme oder Archivbeständen — dokumentiert den damaligen Stand, ohne Anspruch auf Aktualität.

event.meta.quality — Qualitätsniveau

WertLabelBedeutung
curatedkuratiertDirekt dokumentiert bzw. fachlich kuratiert — durch den behandelnden Arzt oder die Tumordokumentation.
derivedabgeleitetAbgeleitet oder sekundär übernommen — die Information wurde nicht primär an der Quelle dokumentiert, sondern aus anderen Angaben gewonnen.
limitedeingeschränktBekannte Einschränkungen in der Datenqualität — z. B. unvollständige oder widersprüchliche Quellangaben. Verwendbar, aber mit Vorsicht.
unconfirmedunbestätigtNoch nicht validiert oder freigegeben — z. B. vor Abschluss der Dokumentations- oder Freigabeprozesse.

event.meta.source_category — Quellkategorie

WertLabelBedeutung
primaryPrimärquelleDie Information wurde an dieser Quelle originär dokumentiert.
secondarySekundärquelleDie Information wurde aus einer anderen Quelle übernommen oder abgeleitet.

episode.intent — Intention (Therapieziel)

WertLabelBedeutung
curativekurativDie Episode verfolgt Heilung als Ziel — einschließlich aufgeschoben-kurativer Strategien wie Active Surveillance.
palliativepalliativDie Episode zielt auf Krankheitskontrolle, Symptomlinderung und Lebensqualität, nicht auf Heilung — typisch für palliative_line und watchful_waiting.
mixedgemischtInnerhalb der Episode wechselt oder mischt sich die Intention, ohne dass eine Aufteilung in getrennte Episoden klinisch sinnvoll wäre.
unknownunbekanntDie Intention ist nicht bekannt oder nicht ableitbar — eine ehrliche Lücke statt einer geratenen Strategie.

episode.status — Episodenstatus

WertLabelBedeutung
activelaufendDie Episode ist zum Stand der Lieferung noch nicht abgeschlossen.
completedabgeschlossenDie Episode ist abgeschlossen; end_event bzw. das letzte zugeordnete Ereignis markiert das Ende.
unknownunbekanntDer Stand der Episode ist nicht bekannt — z. B. bei abgeleiteten Altdaten.

episode.study.registry — Studienregister

WertLabelBedeutung
NCTClinicalTrials.gov (NCT)US-Register ClinicalTrials.gov; code trägt die NCT-Nummer (z. B. NCT99999999).
DRKSDeutsches Register Klinischer Studien (DRKS)Deutsches Register Klinischer Studien; code trägt die DRKS-ID.
EudraCTEudraCTEU-Register für klinische Arzneimittelprüfungen (EudraCT/CTIS); code trägt die EudraCT-Nummer.
ISRCTNISRCTN-RegisterInternationales ISRCTN-Register; code trägt die ISRCTN-Nummer.
otheranderes RegisterEin nicht aufgeführtes Studienregister; das konkrete Register sollte aus name bzw. code hervorgehen.

date_precision — Datumsgenauigkeit

WertLabelBedeutung
EexaktDas Datum ist exakt dokumentiert.
TTag geschätztDer Tag ist geschätzt; Monat und Jahr sind belastbar.
MMonat geschätztMonat (und Tag) sind geschätzt; das Jahr ist belastbar.
JJahr geschätztAuch das Jahr ist geschätzt — die Angabe ist nur grob einzuordnen.

use_purpose — Verwendungszweck

WertLabelBedeutung
treatmentBehandlungDirekte Patientenversorgung — die Daten dürfen für Behandlungsentscheidungen zum konkreten Patienten genutzt werden.
quality_assuranceQualitätssicherungNutzung für die Qualitätssicherung — interne QS, Kennzahlen, Audits.
follow_upNachsorgeNutzung für die Nachsorge — etwa der Registerabruf zur Unterstützung strukturierter Nachsorge, einschließlich länderspezifischer Sonderregeln wie der Nachsorge nach Strahlentherapie.
registry_completionRegistervervollständigungRegisterabgleich und -vervollständigung: Die Daten dienen dazu, den Registerbestand zu ergänzen oder zu korrigieren.
researchForschungForschungsnutzung; Rechtsgrundlage (z. B. research_consent) und gegebenenfalls der Consent-Umfang begrenzen sie näher.
certificationZertifizierungNutzung für Zertifizierungsverfahren, z. B. DKG/OnkoZert-Kennzahlen.
tumor_board_preparationTumorboard-VorbereitungNutzung zur Vorbereitung einer Tumorkonferenz — die konsolidierte Journey als Fallgrundlage.
data_reconciliationDatenabgleichAbgleich zwischen Datenbeständen (z. B. Klinik ↔ Register), einschließlich Übernahme in den lokalen Bestand, sofern local_reconciliation_allowed dies deckt.
internal_reconciliation_onlyNur interner AbgleichEngster Zweck: nur interner Abgleich, keine Weiterverwendung — die Daten dürfen eingesehen und verglichen, aber nicht weiterverwendet oder in den Bestand übernommen werden.

interpretation_meta.quality — Qualität der Interpretation

WertLabelBedeutung
curatedkuratiert (fachlich bestätigt)Die Episode bzw. Relation wurde fachlich geprüft und bestätigt — typischerweise durch die Tumordokumentation oder ärztlich (annotated_by_role).
derivedabgeleitet (algorithmisch vorgeschlagen)Die Episode bzw. Relation wurde algorithmisch aus oBDS-Indizien vorgeschlagen — z. B. Stellung_OP, y-TNM, Datumsfenster, Meldeanlass — und ist noch nicht fachlich bestätigt. Die Indizien stehen in derived_from.

interpretation_meta.annotated_by_role — Annotierende Rolle

WertLabelBedeutung
algorithmAlgorithmusDie Interpretation wurde maschinell erzeugt — typisch bei quality = derived aus der automatischen Ausleitung.
tumor_documentationTumordokumentationDie Interpretation wurde durch die spezialisierte Tumordokumentation annotiert bzw. bestätigt.
physicianÄrztin/ArztDie Interpretation wurde ärztlich annotiert bzw. bestätigt.

Dictionary ist normativ

Das Dictionary ist Teil der Spezifikation — Änderungen folgen dem Governance-Prozess und werden je Version eingefroren. Fehlt ein Begriff oder ist eine Definition unklar: per E-Mail vorschlagen.