Stabile Term-IDs
opjd://<version>/<pfad>[/<wert>]. Terme werden nie gelöscht, sondern als deprecated markiert. Rohdaten: dictionary.json · MetaschemaKernobjekte 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.
| Feld | Typ | Pflicht | Bedeutung |
|---|---|---|---|
| schema_version | string | ja | Version des oPJD-Schemas, gegen das dieses Paket validiert (SemVer; major = 0 während der Entwurfsphase). Jede Instanz trägt ihre Version explizit. |
| delivery | delivery | ja | Die Austauschhülle des Pakets: Absender, Empfänger, Rechtsgrundlage, Verwendungszweck, Gültigkeit und Einschränkungen — siehe Objekt delivery. |
| patient | patient | ja | Die zentrale Bezugsperson des Pakets — pseudonymisiert oder identifiziert, je nach Einsatzkontext. |
| tumors | array<tumor> (minItems 1) | ja | Alle Tumorentitäten des Patienten, auf die sich Ereignisse, Episoden und der Journey-Status per tumor_ref beziehen (mindestens eine). |
| events | array<event> (minItems 1) | ja | Die atomaren, dokumentierten Tatsachen der Journey (mindestens eine). Die oBDS-Nutzlast bleibt unverändert — Prinzip: Schicht, nicht Ersatz. |
| episodes | array<episode> | ja | Die 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. |
| relations | array<relation> | ja | Typisierte, gerichtete Bezüge zwischen Ereignissen bzw. von Ereignissen zu Episoden. Ein leeres Array ist zulässig. |
| journey_status | array<journeyStatus> | nein | Optional: 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.
| Feld | Typ | Pflicht | Bedeutung |
|---|---|---|---|
| package_id | id | ja | Eindeutige Kennung des Datenpakets (Konvention: PKG-…) — Bezugspunkt für supersedes_package_id nachfolgender Lieferungen. |
| package_version | integer | ja | Version dieser Lieferung (ganzzahlig, ≥ 1). Zählt Updates, Nachlieferungen und Korrekturen desselben Pakets. |
| package_created_at | string | ja | Erstellungszeitpunkt des Pakets als Zeitstempel (date-time, mit Zeitzone). |
| sending_organization | string | ja | Abgebende Institution der Lieferung, z. B. Landeskrebsregister oder Klinik. |
| sending_unit | string | nein | Konkrete Organisationseinheit des Absenders (Register, Zentrum, Abteilung). |
| sending_system | string | ja | Quellsystem der Lieferung, z. B. ONKOSTAR oder ein Registersystem. |
| receiving_organization | string | ja | Institution, die das Paket empfängt und an die Zweckbindung der Hülle gebunden ist. |
| delivery_context | use_purpose | ja | Anlass der Übermittlung, kodiert im use_purpose-Vokabular (z. B. treatment, research, registry_completion). |
| jurisdiction | string | ja | Rechtsraum der Übermittlung (Land/Bundesland), z. B. DE-BY — Bezugsrahmen für legal_basis_category und jurisdiction_specific_rule. |
| responsible_contact | string | nein | Verantwortliche Stelle bzw. Kontakt für Rückfragen zur Lieferung. |
| legal_basis_category | enum (7 Werte) | ja | Kategorie 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_detail | string | nein | Genauere Beschreibung der Rechtsgrundlage in Freitext, z. B. konkrete Landesrechtsnorm, Einwilligungsversion oder Vertrag. |
| jurisdiction_specific_rule | string | nein | Benennung 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_use | array<use_purpose> (minItems 1) | ja | Abschließ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_use | array<use_purpose> | nein | Explizit 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_allowed | boolean | nein | Darf der Empfänger die Daten an Dritte weitergeben? Ohne Angabe ist keine Weitergabe zugesichert. |
| valid_from | string | nein | Beginn der Gültigkeit der Berechtigung bzw. Freigabe, auf der diese Lieferung beruht. |
| valid_until | string | nein | Ende der Gültigkeit der Berechtigung (Verfallslogik): Nach diesem Datum ist die Nutzung nicht mehr gedeckt bzw. eine Auffrischung erforderlich. |
| last_verified_at | string | nein | Datum der letzten Prüfung der Berechtigung durch den Absender. |
| refresh_required_after | string | nein | Zeitpunkt, nach dem eine Auffrischung der Lieferung bzw. der Berechtigungsprüfung erforderlich ist. |
| supersedes_package_id | id | nein | Referenz auf ein vorangegangenes Paket, das durch diese Lieferung ersetzt wird — macht Korrektur- und Nachlieferungsketten nachvollziehbar. |
| restriction_flag | boolean | nein | Marker: Für dieses Paket besteht eine besondere Einschränkung. Details stehen in restriction_note. |
| restriction_note | string | nein | Freitext-Details einer besonderen Einschränkung, z. B. „nur QS, keine Forschung". |
| local_reconciliation_allowed | boolean | nein | Darf 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.
| Feld | Typ | Pflicht | Bedeutung |
|---|---|---|---|
| status | enum (5 Werte) | ja | Status der Einwilligung bzw. Freigabe des Patienten für diese Lieferung: present, not_present, revoked, unknown oder not_required. |
| scope | string | nein | Umfang der Einwilligung in Freitext, z. B. Versorgung, Forschung, standortübergreifend. |
| valid_from | string | nein | Beginn der Gültigkeit der Einwilligung. |
| valid_until | string | nein | Ende der Gültigkeit der Einwilligung. |
| revocation_date | string | nein | Datum 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.
| Feld | Typ | Pflicht | Bedeutung |
|---|---|---|---|
| patient_id | id | ja | Stabile Kennung des Patienten innerhalb des Pakets — Pseudonym oder identifizierende ID gemäß id_kind. |
| id_kind | enum (2 Werte) | ja | Art der Patientenkennung: pseudonym (pseudonymisiert) oder identified (identifiziert) — je nach Einsatzkontext und Rechtsgrundlage der Lieferung. |
| birth_date | string | nein | Geburtsdatum des Patienten; bei pseudonymisierten Lieferungen ggf. bewusst weggelassen oder vergröbert. |
| sex | enum (4 Werte) | nein | Geschlecht nach oBDS-Vokabular: M (männlich), W (weiblich), D (divers), U (unbekannt). |
| obds | object | nein | Optionale 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.
| Feld | Typ | Pflicht | Bedeutung |
|---|---|---|---|
| tumor_id | id | ja | Stabile Kennung der Tumorentität innerhalb des Pakets (Konvention: TU-…) — Ziel aller tumor_ref-Verweise. |
| icd_o_morphology | string | nein | ICD-O-3-Morphologie des Tumors, z. B. 8140/3. |
| diagnosis_date | string | ja | Datum der Diagnosestellung des Tumors; die Genauigkeit kann über diagnosis_date_precision angegeben werden. |
| diagnosis_date_precision | date_precision | nein | Genauigkeit des Diagnosedatums nach oBDS-Konvention (E/T/M/J). |
| laterality | string | nein | Seitenlokalisation des Tumors nach oBDS-Vokabular (z. B. L, R, B, M, U). |
| obds | object | nein | Optionale 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).
| Feld | Typ | Pflicht | Bedeutung |
|---|---|---|---|
| code | string | ja | ICD-10-GM-Code der Tumordiagnose, z. B. C34.1. |
| version | string | nein | Version 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.
| Feld | Typ | Pflicht | Bedeutung |
|---|---|---|---|
| event_id | id | ja | Stabile Kennung des Ereignisses (Konvention: EVT-…) — Adresse für Episoden (events[], start_event/end_event) und Relationen (from/to). |
| type | enum (10 Werte) | ja | 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. |
| date | string | ja | Datum des Ereignisses (ISO-8601-Datum); die Genauigkeit kann über date_precision angegeben werden. |
| date_precision | date_precision | nein | Genauigkeit des Ereignisdatums nach oBDS-Konvention (E/T/M/J). |
| tumor_ref | id | ja | Pflicht-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_event | boolean | nein | Markiert ein Ereignis mit strukturierender Funktion für den Verlauf: Wendepunkte, Strategieentscheidungen, Übergänge zwischen Behandlungsphasen — typisch Erstdiagnose, Tumorboard-Beschluss, Progressionsnachweis. |
| obds | object | nein | Die 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) |
| note | string | nein | Freitext-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).
| Feld | Typ | Pflicht | Bedeutung |
|---|---|---|---|
| episode_id | id | ja | Stabile Kennung der Episode (Konvention: EP-…) — Adresse für Relationen auf Episoden (assesses, triggers) und für journey_status.active_episode. |
| type | enum (13 Werte) | ja | Typ 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_ref | id | ja | Pflicht-Bezug auf die Tumorentität (tumor_id), deren Verlauf die Episode strukturiert. |
| intent | enum (4 Werte) | nein | Intention 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 |
| organization | string | bedingt | Die deklarierende bzw. behandelnde Einrichtung einer Fallklassifikations-Klammer — beantwortet: Wessen Fallzählung gilt hier? Pflicht bei type = primary_case oder center_case. |
| line_number | integer | nein | Nummer 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_event | id | nein | Das 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_event | id | nein | Das 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. |
| events | array<id> (minItems 1) | ja | Alle 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. |
| status | enum (3 Werte) | nein | Bearbeitungsstand der Episode: active (läuft), completed (abgeschlossen) oder unknown. |
| meta | interpretation_meta | ja | Metadaten 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.
| Feld | Typ | Pflicht | Bedeutung |
|---|---|---|---|
| registry | enum (5 Werte) | ja | Das Studienregister, in dem die Studie geführt wird: NCT, DRKS, EudraCT, ISRCTN oder other. |
| code | string | ja | Registernummer der Studie im angegebenen Register, z. B. die NCT-Nummer. |
| name | string | nein | Studienname bzw. Akronym, z. B. SYNTH-NEO-01. |
| arm | string | nein | Studienarm 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.
| Feld | Typ | Pflicht | Bedeutung |
|---|---|---|---|
| relation_id | id | ja | Stabile Kennung der Relation (Konvention: REL-…). |
| type | enum (4 Werte) | ja | 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. |
| from | id | ja | Die 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. |
| to | id | ja | Die 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). |
| note | string | nein | Freitext-Anmerkung zur Relation, z. B. die Begründung des Bezugs. |
| meta | interpretation_meta | ja | Metadaten 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.
| Feld | Typ | Pflicht | Bedeutung |
|---|---|---|---|
| tumor_ref | id | ja | Die Tumorentität (tumor_id), deren aktueller Zustand beschrieben wird. |
| active_episode | id | nein | episode_id der aktuell laufenden Episode dieses Tumors — Gegenstück zu episode.status = active. |
| current_line | integer | nein | Aktuelle 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.
| Feld | Typ | Pflicht | Bedeutung |
|---|---|---|---|
| event_ref | id | ja | event_id des Verlaufsereignisses, das die letzte Gesamtbeurteilung trägt. |
| overall_assessment | string | nein | Gesamtbeurteilung 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.
diagnosisDiagnoseDiagnosisDiagnosestellung 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 reportHistologischer 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.
surgeryOperationSurgeryOperativer 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 therapyStrahlentherapeutische 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 therapySystemische 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 reportVerlaufs- 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 boardTumorkonferenz 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.
deathTodDeathTod 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.0Einschluss 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 eventAuffangwert 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 episodeVerlaufsphase: 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 episodeVerlaufsphase: 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 episodeVerlaufsphase: 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 episodeVerlaufsphase: 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 episodeVerlaufsphase: 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 episodeVerlaufsphase: 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 lineVerlaufsphase: 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.0Verlaufsphase: 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.0Verlaufsphase: 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.0Kontextklammer: 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.0Kontextklammer: 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.0Kontextklammer: 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 episodeAuffangwert 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 ofEin 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 umImplementsEine 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.
assessesbeurteiltAssessesEin 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 ausTriggersEin 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.
| Feld | Typ | Pflicht | Bedeutung |
|---|---|---|---|
| provenance | enum (6 Werte) | ja | Woher stammt die Information? Sechs Herkunftsklassen — von der klinischen Primärdokumentation über Tumordokumentation, Register, Studien- und Zertifizierungskontext bis zur externen Meldung. |
| currency | enum (3 Werte) | ja | Wie synchron ist die Information mit dem klinischen Geschehen? Dreistufig: current, delayed, historical. Ergänzend dokumentiert last_confirmed_at die letzte Bestätigung. |
| quality | enum (4 Werte) | ja | Wie belastbar ist die Information? Vierstufig: curated, derived, limited, unconfirmed. Keine wissenschaftliche Evidenzbewertung, sondern eine praktikable, aus Quelle und Prozess ableitbare Einschätzung. |
| source_system | string | nein | Name des Quellsystems, aus dem das Ereignis stammt (z. B. ONKOSTAR, KIS, Registersystem). |
| source_category | enum (2 Werte) | nein | Grobklassifikation der Quelle: primary (originär dokumentiert) oder secondary (aus zweiter Hand übernommen). |
| recorded_at | string | nein | Datum der Erfassung bzw. Dokumentation des Ereignisses — nicht zu verwechseln mit dem klinischen Ereignisdatum (event.date). |
| last_confirmed_at | string | nein | Datum 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.
| Feld | Typ | Pflicht | Bedeutung |
|---|---|---|---|
| quality | enum (2 Werte) | ja | Belastbarkeit der Klammer bzw. Relation selbst: derived (algorithmisch vorgeschlagen) oder curated (fachlich bestätigt). Bewertet die Interpretation, nicht die zugrunde liegenden Ereignisse. |
| derived_from | array<string> | nein | Die 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_at | string | nein | Datum der Annotation bzw. der letzten Bestätigung der Interpretation. |
| annotated_by_role | enum (3 Werte) | nein | Die 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
| Wert | Label | Bedeutung |
|---|---|---|
| clinical_care | Behandlungskontext | Behandlungsbezogener Datenaustausch: Die Übermittlung erfolgt im Rahmen der direkten Patientenversorgung, etwa bei Mit- oder Weiterbehandlung. |
| cancer_registry_law | Krebsregistergesetz | Ü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_regulation | QS-Richtlinie/-Verordnung | Übermittlung auf Grundlage von Qualitätssicherungs-Richtlinien und -Verordnungen, z. B. gesetzlicher QS-Verfahren. |
| research_consent | Einwilligungsbasierte Forschung | Übermittlung zu Forschungszwecken auf Grundlage einer informierten Einwilligung des Patienten (z. B. Broad Consent). Der Einwilligungsstatus selbst wird in delivery.consent geführt. |
| other_research_basis | Andere Forschungsgrundlage | Forschungsübermittlung ohne individuelle Einwilligung, z. B. auf Grundlage eines Ethikvotums oder einer gesetzlichen Forschungsklausel. |
| contractual_data_transfer | Vertragliche Datenübertragung | Übermittlung auf vertraglicher Grundlage, z. B. Kooperations- oder Auftragsverarbeitungsverträge zwischen Einrichtungen. |
| jurisdiction_specific_exception | Lä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
| Wert | Label | Bedeutung |
|---|---|---|
| present | liegt vor | Eine wirksame Einwilligung bzw. Freigabe des Patienten liegt vor; Umfang und Gültigkeit stehen in scope, valid_from und valid_until. |
| not_present | liegt nicht vor | Es liegt keine Einwilligung vor. Die Lieferung stützt sich dann auf eine andere Rechtsgrundlage (z. B. Krebsregistergesetz) — oder ihre Nutzung ist entsprechend eingeschränkt. |
| revoked | widerrufen | Eine zuvor erteilte Einwilligung wurde widerrufen. Das Widerrufsdatum steht in revocation_date; die weitere Nutzung richtet sich nach Rechtsgrundlage und Widerrufsumfang. |
| unknown | unbekannt | Der Einwilligungsstatus ist dem Absender nicht bekannt — eine ehrliche Lücke statt einer stillschweigenden Annahme. |
| not_required | nicht erforderlich | Fü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
| Wert | Label | Bedeutung |
|---|---|---|
| pseudonym | pseudonymisiert | Die Patientenkennung ist ein Pseudonym; eine Re-Identifikation ist nur über die pseudonymisierende Stelle möglich. Typisch für Forschungs- und QS-Lieferungen. |
| identified | identifiziert | Die Patientenkennung identifiziert den Patienten direkt — nur in Versorgungskontexten mit entsprechender Rechtsgrundlage. |
patient.sex — Geschlecht
| Wert | Label | Bedeutung |
|---|---|---|
| M | männlich | Geschlecht männlich (oBDS-Vokabular). |
| W | weiblich | Geschlecht weiblich (oBDS-Vokabular). |
| D | divers | Geschlecht divers (oBDS-Vokabular). |
| U | unbekannt | Geschlecht unbekannt (oBDS-Vokabular). |
event.meta.provenance — Provenance (Herkunft)
| Wert | Label | Bedeutung |
|---|---|---|
| primary_clinical | Primärdokumentation Klinik | Die Information stammt aus der klinischen Primärdokumentation der behandelnden Einrichtung (KIS, Befundsysteme). |
| tumor_documentation | Tumordokumentation | Die Information stammt aus der spezialisierten Tumordokumentation (z. B. ONKOSTAR-Erfassung durch Dokumentarinnen und Dokumentare). |
| registry | Registerdaten | Die Information stammt aus einem Krebsregister (z. B. Landeskrebsregister) — typisch beim Datenrückfluss an Melder. |
| study | Studienkontext | Die Information stammt aus Studiendokumentation bzw. Studiensystemen — typisch für study_enrollment und studienbezogene Ereignisse. |
| certification | Zertifizierungsdokumentation | Die Information stammt aus der Zertifizierungswelt (z. B. DKG/OnkoZert-Kennzahlenprozesse) — typisch für die Fallklassifikations-Klammern primary_case und center_case. |
| external | Externe Meldung | Die Information stammt von einer externen Stelle außerhalb der eigenen Dokumentationskette, z. B. einer auswärtigen Einrichtung. |
event.meta.currency — Aktualität
| Wert | Label | Bedeutung |
|---|---|---|
| current | aktuell | Zeitnah zum Geschehen dokumentiert; gilt als aktueller Stand. |
| delayed | verzögert | Mit relevantem Zeitversatz eingegangen oder dokumentiert — z. B. Registerrückfluss oder Nachmeldung. Der Inhalt kann korrekt, aber nicht mehr der neueste Stand sein. |
| historical | historisch | Aus Altdatenübernahme oder Archivbeständen — dokumentiert den damaligen Stand, ohne Anspruch auf Aktualität. |
event.meta.quality — Qualitätsniveau
| Wert | Label | Bedeutung |
|---|---|---|
| curated | kuratiert | Direkt dokumentiert bzw. fachlich kuratiert — durch den behandelnden Arzt oder die Tumordokumentation. |
| derived | abgeleitet | Abgeleitet oder sekundär übernommen — die Information wurde nicht primär an der Quelle dokumentiert, sondern aus anderen Angaben gewonnen. |
| limited | eingeschränkt | Bekannte Einschränkungen in der Datenqualität — z. B. unvollständige oder widersprüchliche Quellangaben. Verwendbar, aber mit Vorsicht. |
| unconfirmed | unbestätigt | Noch nicht validiert oder freigegeben — z. B. vor Abschluss der Dokumentations- oder Freigabeprozesse. |
event.meta.source_category — Quellkategorie
| Wert | Label | Bedeutung |
|---|---|---|
| primary | Primärquelle | Die Information wurde an dieser Quelle originär dokumentiert. |
| secondary | Sekundärquelle | Die Information wurde aus einer anderen Quelle übernommen oder abgeleitet. |
episode.intent — Intention (Therapieziel)
| Wert | Label | Bedeutung |
|---|---|---|
| curative | kurativ | Die Episode verfolgt Heilung als Ziel — einschließlich aufgeschoben-kurativer Strategien wie Active Surveillance. |
| palliative | palliativ | Die Episode zielt auf Krankheitskontrolle, Symptomlinderung und Lebensqualität, nicht auf Heilung — typisch für palliative_line und watchful_waiting. |
| mixed | gemischt | Innerhalb der Episode wechselt oder mischt sich die Intention, ohne dass eine Aufteilung in getrennte Episoden klinisch sinnvoll wäre. |
| unknown | unbekannt | Die Intention ist nicht bekannt oder nicht ableitbar — eine ehrliche Lücke statt einer geratenen Strategie. |
episode.status — Episodenstatus
| Wert | Label | Bedeutung |
|---|---|---|
| active | laufend | Die Episode ist zum Stand der Lieferung noch nicht abgeschlossen. |
| completed | abgeschlossen | Die Episode ist abgeschlossen; end_event bzw. das letzte zugeordnete Ereignis markiert das Ende. |
| unknown | unbekannt | Der Stand der Episode ist nicht bekannt — z. B. bei abgeleiteten Altdaten. |
episode.study.registry — Studienregister
| Wert | Label | Bedeutung |
|---|---|---|
| NCT | ClinicalTrials.gov (NCT) | US-Register ClinicalTrials.gov; code trägt die NCT-Nummer (z. B. NCT99999999). |
| DRKS | Deutsches Register Klinischer Studien (DRKS) | Deutsches Register Klinischer Studien; code trägt die DRKS-ID. |
| EudraCT | EudraCT | EU-Register für klinische Arzneimittelprüfungen (EudraCT/CTIS); code trägt die EudraCT-Nummer. |
| ISRCTN | ISRCTN-Register | Internationales ISRCTN-Register; code trägt die ISRCTN-Nummer. |
| other | anderes Register | Ein nicht aufgeführtes Studienregister; das konkrete Register sollte aus name bzw. code hervorgehen. |
date_precision — Datumsgenauigkeit
| Wert | Label | Bedeutung |
|---|---|---|
| E | exakt | Das Datum ist exakt dokumentiert. |
| T | Tag geschätzt | Der Tag ist geschätzt; Monat und Jahr sind belastbar. |
| M | Monat geschätzt | Monat (und Tag) sind geschätzt; das Jahr ist belastbar. |
| J | Jahr geschätzt | Auch das Jahr ist geschätzt — die Angabe ist nur grob einzuordnen. |
use_purpose — Verwendungszweck
| Wert | Label | Bedeutung |
|---|---|---|
| treatment | Behandlung | Direkte Patientenversorgung — die Daten dürfen für Behandlungsentscheidungen zum konkreten Patienten genutzt werden. |
| quality_assurance | Qualitätssicherung | Nutzung für die Qualitätssicherung — interne QS, Kennzahlen, Audits. |
| follow_up | Nachsorge | Nutzung für die Nachsorge — etwa der Registerabruf zur Unterstützung strukturierter Nachsorge, einschließlich länderspezifischer Sonderregeln wie der Nachsorge nach Strahlentherapie. |
| registry_completion | Registervervollständigung | Registerabgleich und -vervollständigung: Die Daten dienen dazu, den Registerbestand zu ergänzen oder zu korrigieren. |
| research | Forschung | Forschungsnutzung; Rechtsgrundlage (z. B. research_consent) und gegebenenfalls der Consent-Umfang begrenzen sie näher. |
| certification | Zertifizierung | Nutzung für Zertifizierungsverfahren, z. B. DKG/OnkoZert-Kennzahlen. |
| tumor_board_preparation | Tumorboard-Vorbereitung | Nutzung zur Vorbereitung einer Tumorkonferenz — die konsolidierte Journey als Fallgrundlage. |
| data_reconciliation | Datenabgleich | Abgleich zwischen Datenbeständen (z. B. Klinik ↔ Register), einschließlich Übernahme in den lokalen Bestand, sofern local_reconciliation_allowed dies deckt. |
| internal_reconciliation_only | Nur interner Abgleich | Engster 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
| Wert | Label | Bedeutung |
|---|---|---|
| curated | kuratiert (fachlich bestätigt) | Die Episode bzw. Relation wurde fachlich geprüft und bestätigt — typischerweise durch die Tumordokumentation oder ärztlich (annotated_by_role). |
| derived | abgeleitet (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
| Wert | Label | Bedeutung |
|---|---|---|
| algorithm | Algorithmus | Die Interpretation wurde maschinell erzeugt — typisch bei quality = derived aus der automatischen Ausleitung. |
| tumor_documentation | Tumordokumentation | Die Interpretation wurde durch die spezialisierte Tumordokumentation annotiert bzw. bestätigt. |
| physician | Ärztin/Arzt | Die Interpretation wurde ärztlich annotiert bzw. bestätigt. |
Dictionary ist normativ