# oPJD — oncological Patient Journey Dataset · Vollreferenz Generiert aus Schema, Dictionary und Versionsregister der Version 0.2.0 (Status: draft). Quelle: https://opjd.kerscher-lab.org · Manifest: /schema/manifest.json · Lizenzen: Apache-2.0 (Schemas/Code), CC BY 4.0 (Texte/Dictionary). Nicht von Hand editieren — erzeugt von scripts/build-llms.mjs. ## Überblick Offener Standard für konsolidierte onkologische Patient Journeys: unveränderte oBDS-Ereignisse plus Episoden (klinische Klammern), typisierte Relationen, Metadaten-Layer und Austauschhülle. Drei Ebenen: (A) klinische Datenebene — Tumoren, Ereignisse, Episoden, Relationen, Metadaten; (B) Liefer- und Nutzungsebene — Absender, Empfänger, Rechtsgrundlage, Zweck, Gültigkeit; (C) Governance-Ebene — Versionierung, Prozesse, Rollen. Nicht verhandelbar: - oBDS-Nutzlasten (obds-Felder) niemals verändern oder neu kodieren — der oPJD ist Schicht, nicht Ersatz. - Enums sind abschließend; neue Werte nur über den Governance-Prozess vorschlagen, nie erfinden. - Interpretationsschicht unterscheiden: meta.quality = derived ist ein algorithmischer Vorschlag, curated eine fachliche Bestätigung. - Nichts wird gelöscht: Terme werden deprecated und superseded, IDs bleiben stabil. - Relationen lesen sich als Grammatik, nicht als Zeit: from ist das Element, das den Bezug ausspricht. - Alle Beispiele sind synthetisch; keine echten Patientendaten in Vorschläge, Issues oder Beispiele einspeisen. ## Versionen | Version | Status | Freigegeben | Gültig ab | Sunset | Hinweis | |---|---|---|---|---|---| | 0.2.0 | draft | — | — | — | Entwurfsstand für die Konsensphase (OncoFlow AP1) und die technische Machbarkeit (AP2). Additiv gegenüber 0.1.0. | | 0.1.0 | retired | — | — | — | Initialer Paketkontrakt als interner Arbeitsstand; nie als Datei publiziert. Inhalt im Changelog dokumentiert. | SemVer mit Domänensemantik: MAJOR = Bedeutungsänderung oder Strukturbruch (Migration erforderlich), MINOR = additive Erweiterung oder Präzisierung ohne Bruch, PATCH = redaktionell (Beschreibungen, Beispiele, Tippfehler). Sonderregel 0.x (Entwurfsphase): auch Minor darf brechen, wird dann im Changelog als BREAKING markiert. ## Objektmodell ### 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. | Feld | Typ | Pflicht | Bedeutung | |---|---|---|---| | `schema_version` | string | required | 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 | required | Die Austauschhülle des Pakets: Absender, Empfänger, Rechtsgrundlage, Verwendungszweck, Gültigkeit und Einschränkungen — siehe Objekt delivery. | | `patient` | patient | required | Die zentrale Bezugsperson des Pakets — pseudonymisiert oder identifiziert, je nach Einsatzkontext. | | `tumors` | array (minItems 1) | required | Alle Tumorentitäten des Patienten, auf die sich Ereignisse, Episoden und der Journey-Status per tumor_ref beziehen (mindestens eine). | | `events` | array (minItems 1) | required | Die atomaren, dokumentierten Tatsachen der Journey (mindestens eine). Die oBDS-Nutzlast bleibt unverändert — Prinzip: Schicht, nicht Ersatz. | | `episodes` | array | required | 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 | required | Typisierte, gerichtete Bezüge zwischen Ereignissen bzw. von Ereignissen zu Episoden. Ein leeres Array ist zulässig. | | `journey_status` | array | optional | 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. | Feld | Typ | Pflicht | Bedeutung | |---|---|---|---| | `package_id` | id | required | Eindeutige Kennung des Datenpakets (Konvention: PKG-…) — Bezugspunkt für supersedes_package_id nachfolgender Lieferungen. | | `package_version` | integer | required | Version dieser Lieferung (ganzzahlig, ≥ 1). Zählt Updates, Nachlieferungen und Korrekturen desselben Pakets. | | `package_created_at` | string | required | Erstellungszeitpunkt des Pakets als Zeitstempel (date-time, mit Zeitzone). | | `sending_organization` | string | required | Abgebende Institution der Lieferung, z. B. Landeskrebsregister oder Klinik. | | `sending_unit` | string | optional | Konkrete Organisationseinheit des Absenders (Register, Zentrum, Abteilung). | | `sending_system` | string | required | Quellsystem der Lieferung, z. B. ONKOSTAR oder ein Registersystem. | | `receiving_organization` | string | required | Institution, die das Paket empfängt und an die Zweckbindung der Hülle gebunden ist. | | `delivery_context` | use_purpose | required | Anlass der Übermittlung, kodiert im use_purpose-Vokabular (z. B. treatment, research, registry_completion). | | `jurisdiction` | string | required | Rechtsraum der Übermittlung (Land/Bundesland), z. B. DE-BY — Bezugsrahmen für legal_basis_category und jurisdiction_specific_rule. | | `responsible_contact` | string | optional | Verantwortliche Stelle bzw. Kontakt für Rückfragen zur Lieferung. | | `legal_basis_category` | enum (7 Werte) | required | 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 | optional | Genauere Beschreibung der Rechtsgrundlage in Freitext, z. B. konkrete Landesrechtsnorm, Einwilligungsversion oder Vertrag. | | `jurisdiction_specific_rule` | string | optional | 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 (minItems 1) | required | 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 | optional | 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 | optional | Darf der Empfänger die Daten an Dritte weitergeben? Ohne Angabe ist keine Weitergabe zugesichert. | | `valid_from` | string | optional | Beginn der Gültigkeit der Berechtigung bzw. Freigabe, auf der diese Lieferung beruht. | | `valid_until` | string | optional | Ende der Gültigkeit der Berechtigung (Verfallslogik): Nach diesem Datum ist die Nutzung nicht mehr gedeckt bzw. eine Auffrischung erforderlich. | | `last_verified_at` | string | optional | Datum der letzten Prüfung der Berechtigung durch den Absender. | | `refresh_required_after` | string | optional | Zeitpunkt, nach dem eine Auffrischung der Lieferung bzw. der Berechtigungsprüfung erforderlich ist. | | `supersedes_package_id` | id | optional | Referenz auf ein vorangegangenes Paket, das durch diese Lieferung ersetzt wird — macht Korrektur- und Nachlieferungsketten nachvollziehbar. | | `restriction_flag` | boolean | optional | Marker: Für dieses Paket besteht eine besondere Einschränkung. Details stehen in restriction_note. | | `restriction_note` | string | optional | Freitext-Details einer besonderen Einschränkung, z. B. „nur QS, keine Forschung". | | `local_reconciliation_allowed` | boolean | optional | 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. | Feld | Typ | Pflicht | Bedeutung | |---|---|---|---| | `status` | enum (5 Werte) | required | Status der Einwilligung bzw. Freigabe des Patienten für diese Lieferung: present, not_present, revoked, unknown oder not_required. | | `scope` | string | optional | Umfang der Einwilligung in Freitext, z. B. Versorgung, Forschung, standortübergreifend. | | `valid_from` | string | optional | Beginn der Gültigkeit der Einwilligung. | | `valid_until` | string | optional | Ende der Gültigkeit der Einwilligung. | | `revocation_date` | string | optional | 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. | Feld | Typ | Pflicht | Bedeutung | |---|---|---|---| | `patient_id` | id | required | Stabile Kennung des Patienten innerhalb des Pakets — Pseudonym oder identifizierende ID gemäß id_kind. | | `id_kind` | enum (2 Werte) | required | Art der Patientenkennung: pseudonym (pseudonymisiert) oder identified (identifiziert) — je nach Einsatzkontext und Rechtsgrundlage der Lieferung. | | `birth_date` | string | optional | Geburtsdatum des Patienten; bei pseudonymisierten Lieferungen ggf. bewusst weggelassen oder vergröbert. | | `sex` | enum (4 Werte) | optional | Geschlecht nach oBDS-Vokabular: M (männlich), W (weiblich), D (divers), U (unbekannt). | | `obds` | object | optional | 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. | Feld | Typ | Pflicht | Bedeutung | |---|---|---|---| | `tumor_id` | id | required | Stabile Kennung der Tumorentität innerhalb des Pakets (Konvention: TU-…) — Ziel aller tumor_ref-Verweise. | | `icd_o_morphology` | string | optional | ICD-O-3-Morphologie des Tumors, z. B. 8140/3. | | `diagnosis_date` | string | required | Datum der Diagnosestellung des Tumors; die Genauigkeit kann über diagnosis_date_precision angegeben werden. | | `diagnosis_date_precision` | date_precision | optional | Genauigkeit des Diagnosedatums nach oBDS-Konvention (E/T/M/J). | | `laterality` | string | optional | Seitenlokalisation des Tumors nach oBDS-Vokabular (z. B. L, R, B, M, U). | | `obds` | object | optional | 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. | Feld | Typ | Pflicht | Bedeutung | |---|---|---|---| | `code` | string | required | ICD-10-GM-Code der Tumordiagnose, z. B. C34.1. | | `version` | string | optional | 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. | Feld | Typ | Pflicht | Bedeutung | |---|---|---|---| | `event_id` | id | required | Stabile Kennung des Ereignisses (Konvention: EVT-…) — Adresse für Episoden (events[], start_event/end_event) und Relationen (from/to). | | `type` | enum (10 Werte) | required | 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 | required | Datum des Ereignisses (ISO-8601-Datum); die Genauigkeit kann über date_precision angegeben werden. | | `date_precision` | date_precision | optional | Genauigkeit des Ereignisdatums nach oBDS-Konvention (E/T/M/J). | | `tumor_ref` | id | required | 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 | optional | Markiert ein Ereignis mit strukturierender Funktion für den Verlauf: Wendepunkte, Strategieentscheidungen, Übergänge zwischen Behandlungsphasen — typisch Erstdiagnose, Tumorboard-Beschluss, Progressionsnachweis. | | `obds` | object | optional | 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. | | `note` | string | optional | Freitext-Anmerkung zum Ereignis, z. B. eine Kurzbeschreibung des Befunds. | ### 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. | Feld | Typ | Pflicht | Bedeutung | |---|---|---|---| | `provenance` | enum (6 Werte) | required | 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) | required | 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) | required | 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 | optional | Name des Quellsystems, aus dem das Ereignis stammt (z. B. ONKOSTAR, KIS, Registersystem). | | `source_category` | enum (2 Werte) | optional | Grobklassifikation der Quelle: primary (originär dokumentiert) oder secondary (aus zweiter Hand übernommen). | | `recorded_at` | string | optional | Datum der Erfassung bzw. Dokumentation des Ereignisses — nicht zu verwechseln mit dem klinischen Ereignisdatum (event.date). | | `last_confirmed_at` | string | optional | Datum der letzten Bestätigung oder Aktualisierung der Information — ergänzt currency um einen prüfbaren Zeitpunkt. | ### 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. | Feld | Typ | Pflicht | Bedeutung | |---|---|---|---| | `episode_id` | id | required | 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) | required | 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 | required | Pflicht-Bezug auf die Tumorentität (tumor_id), deren Verlauf die Episode strukturiert. | | `intent` | enum (4 Werte) | optional | Intention bzw. Therapieziel auf Episodenebene: curative, palliative, mixed oder unknown. Die Klammer trägt die Strategie — nicht mehr nur die Einzeltherapie. | | `organization` | string | conditional | 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 | optional | 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 | optional | 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 | optional | 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 (minItems 1) | required | 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) | optional | Bearbeitungsstand der Episode: active (läuft), completed (abgeschlossen) oder unknown. | | `meta` | interpretation_meta | required | 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. | Feld | Typ | Pflicht | Bedeutung | |---|---|---|---| | `registry` | enum (5 Werte) | required | Das Studienregister, in dem die Studie geführt wird: NCT, DRKS, EudraCT, ISRCTN oder other. | | `code` | string | required | Registernummer der Studie im angegebenen Register, z. B. die NCT-Nummer. | | `name` | string | optional | Studienname bzw. Akronym, z. B. SYNTH-NEO-01. | | `arm` | string | optional | 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. | Feld | Typ | Pflicht | Bedeutung | |---|---|---|---| | `relation_id` | id | required | Stabile Kennung der Relation (Konvention: REL-…). | | `type` | enum (4 Werte) | required | 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 | required | 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 | required | 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 | optional | Freitext-Anmerkung zur Relation, z. B. die Begründung des Bezugs. | | `meta` | interpretation_meta | required | 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. | Feld | Typ | Pflicht | Bedeutung | |---|---|---|---| | `tumor_ref` | id | required | Die Tumorentität (tumor_id), deren aktueller Zustand beschrieben wird. | | `active_episode` | id | optional | episode_id der aktuell laufenden Episode dieses Tumors — Gegenstück zu episode.status = active. | | `current_line` | integer | optional | 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. | Feld | Typ | Pflicht | Bedeutung | |---|---|---|---| | `event_ref` | id | required | event_id des Verlaufsereignisses, das die letzte Gesamtbeurteilung trägt. | | `overall_assessment` | string | optional | Gesamtbeurteilung nach oBDS-Vokabular, z. B. V = Vollremission, T = Teilremission, K = keine Änderung, P = Progression, U = unbekannt. | ### ID (stabile Kennung) (`id`) Stabile, innerhalb des Pakets eindeutige Kennung (nicht-leerer String). Präfix-Konventionen — EVT- (Ereignis), EP- (Episode), REL- (Relation), TU- (Tumor), PKG- (Paket) — sind empfohlen, nicht erzwungen. Wird von allen ID- und Referenzfeldern referenziert. *Rationale:* Zutat 1 der Secret Sauce: Man kann nur auf das zeigen, was eine Adresse hat. Der oBDS kennt Selbst-IDs (OP_ID, ST_ID, SYST_ID) nur optional — und die Praxis ignoriert sie so vollständig, dass reale Systeme sie nicht einmal einlesen; Zusammenhang entsteht dort allein durch Schachtelung innerhalb einer Meldung oder eine gemeinsame Tumor-ID. Verpflichtende Adressen sind die Voraussetzung für Klammern, Bezüge und Prüfbarkeit. *Regeln:* Das Schema erzwingt nur minLength 1; Eindeutigkeit und Auflösbarkeit der Referenzen werden auf Validator-Ebene geprüft. ### Datumsgenauigkeit (`date_precision`) Genauigkeit einer Datumsangabe nach oBDS-Konvention: E = exakt, T = Tag geschätzt, M = Monat geschätzt, J = Jahr geschätzt. Gilt für Ereignisdaten und das Diagnosedatum. *Rationale:* Geschätzte Daten sind in der Tumordokumentation Alltag (Altdaten, externe Angaben). Die explizite Genauigkeit hält Chronologie-Prüfungen ehrlich: Ein auf den Monat geschätztes Datum darf keine Tagesdifferenz-Kennzahl füttern. ### Verwendungszweck (`use_purpose`) Abschließendes Vokabular der Verwendungszwecke — von der direkten Patientenversorgung bis zum rein internen Abgleich. Verwendet in delivery_context (Anlass der Übermittlung), permitted_use (erlaubt) und prohibited_use (ausgeschlossen). *Rationale:* Ein gemeinsames Zweck-Vokabular für Anlass, Erlaubnis und Verbot macht Zweckbindung maschinell prüfbar: Der Anlass einer Lieferung und die erlaubte Nutzung sprechen dieselbe Sprache. ### 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. | Feld | Typ | Pflicht | Bedeutung | |---|---|---|---| | `quality` | enum (2 Werte) | required | 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 | optional | Die Indizien, aus denen die Interpretation abgeleitet wurde — als Liste kurzer Kennzeichen, z. B. „Stellung_OP=N", „ycTNM", „Datumsfenster", „Tumorkonferenz-Empfehlung AS". | | `annotated_at` | string | optional | Datum der Annotation bzw. der letzten Bestätigung der Interpretation. | | `annotated_by_role` | enum (3 Werte) | optional | 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` | 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` | 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` | 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` | 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.type` | Wert | Label | Bedeutung | |---|---|---| | `diagnosis` | Diagnose | Diagnosestellung der Tumorerkrankung — typischerweise das Ereignis der histologischen Sicherung bzw. Erstdiagnose mit Staging-Information (cTNM). Häufig Schlüsselereignis und Kern der Erstdiagnose-Episode. | | `pathology_report` | Pathologiebefund | 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. | | `surgery` | Operation | 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. | | `radiation_therapy` | Strahlentherapie | Strahlentherapeutische Behandlung (oBDS-Dokumentzweig ST). Stellung zur OP und Intention bleiben in der Nutzlast; die Verlaufseinordnung übernimmt die Episode. | | `systemic_therapy` | Systemtherapie | 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. | | `progress_report` | Verlaufsbefund | 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. | | `tumor_board` | Tumorkonferenz | Tumorkonferenz mit Therapieempfehlung — der dokumentierte Behandlungsplan. Typisches Schlüsselereignis; durchgeführte Maßnahmen zeigen per implements auf den Beschluss zurück. | | `death` | Tod | Tod des Patienten (oBDS-Dokumentzweig Tod) — das terminale Ereignis der Journey; Todesursache und Tumorbezug stehen in der Nutzlast. | | `study_enrollment` | Studieneinschluss | 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). | | `other` | Sonstiges Ereignis | 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. | ### `event.meta.provenance` | 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` | 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` | 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` | 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` | 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` | 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` | 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` | 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` | 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` | 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` | 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. | ## Relationstypen im Detail ### `result_of` — ist Ergebnis von 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. *Macht prüfbar / 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. *Nicht verwechseln:* 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. ### `implements` — setzt um 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?" *Macht prüfbar / 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. *Nicht verwechseln:* 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. ### `assesses` — beurteilt 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?" *Macht prüfbar / 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. *Nicht verwechseln:* 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. ### `triggers` — löst aus 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?" *Macht prüfbar / 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. *Nicht verwechseln:* 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. ## Episodentypen im Detail ### `first_diagnosis` — Erstdiagnose-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. *Macht prüfbar / 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. *oBDS-Bezug:* `Meldung/Diagnose (Meldeanlass diagnose)` — Nur Indiz für die Ableitung; die Phase als Klammer existiert im oBDS nicht. ### `neoadjuvant` — Neoadjuvante 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. *Macht prüfbar / 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. *Nicht verwechseln:* 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. ### `surgical` — Operative Episode Verlaufsphase: der operative Eingriff mit perioperativer Diagnostik, Pathologiebefund und Komplikationsmanagement. *Macht prüfbar / 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. *oBDS-Bezug:* `Meldung/OP` — Der Eingriff ist meldbar, die Phase als Klammer nicht. ### `adjuvant` — Adjuvante Episode Verlaufsphase: postoperative Therapie zur Konsolidierung des Behandlungserfolgs — Systemtherapie oder Bestrahlung nach dem Eingriff. *Macht prüfbar / Rationale:* Analog zur Neoadjuvanz: Stellung_OP=A wird von der lokalen Behauptung zur prüfbaren Phasenzugehörigkeit nach der operativen Episode. *oBDS-Bezug:* `ST/SYST: Stellung_OP=A` — Nur Ableitungsindiz (derived_from); keine Episodenentsprechung im oBDS. ### `follow_up` — Nachsorgephase Verlaufsphase: strukturierte Nachsorge nach Abschluss der Primärbehandlung — regelmäßige Verlaufsbefunde ohne aktive Tumortherapie. *Macht prüfbar / 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. *oBDS-Bezug:* `Meldung/Verlauf` — Verlaufsmeldungen liefern die Ereignisse; die Nachsorge als Phase existiert im oBDS nicht. ### `progression` — Progressions-Episode Verlaufsphase: Nachweis einer Krankheitsprogression als Trigger einer neuen Therapielinie oder Strategieentscheidung — vom Progressionsbefund bis zum neuen Beschluss. *Macht prüfbar / 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. *Nicht verwechseln:* 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_line` — Palliative Therapielinie Verlaufsphase: Systemtherapie im palliativen Kontext, als zählbare Therapielinie geführt (line_number, ESMO-Zählung anschlussfähig). Konvention: intent = palliative. *Macht prüfbar / 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. *oBDS-Bezug:* keine Entsprechung — Dokumentierte Lücke: keine Therapielinien-Nummer im oBDS; Ableitung nur aus der Sequenz von SYST-Meldungen mit Intention=P. ### `active_surveillance` — Active Surveillance (aktive Überwachung) 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. *Macht prüfbar / 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. *Nicht verwechseln:* 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_waiting` — Watchful Waiting (abwartendes Vorgehen) Verlaufsphase: symptomorientiertes Abwarten ohne kurativen Anspruch — Intervention erst bei Beschwerden, typisch bei begrenzter Lebenserwartung oder relevanter Komorbidität. Konvention: intent = palliative. *Macht prüfbar / 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. *Nicht verwechseln:* 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. ### `study_participation` — Studienphase 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. *Macht prüfbar / 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). *oBDS-Bezug:* keine Entsprechung — Dokumentierte Lücke: kein Studieneinschluss und keine Studienteilnahme im oBDS. ### `primary_case` — Primärfall 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). *Macht prüfbar / 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). *Nicht verwechseln:* 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_case` — Zentrumsfall 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). *Macht prüfbar / Rationale:* Dieselbe Journey kann bei zwei Zentren unterschiedlich zählen. Die transportierte Deklaration (statt einer Nachberechnung) macht beim Austausch transparent, wessen Fallzählung gilt. *Nicht verwechseln:* 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). ### `other` — Sonstige Episode Auffangwert für Klammern ohne eigenen Typ. Sparsam verwenden; neue Episodentypen entstehen über den Governance-Prozess, nicht ad hoc. *Macht prüfbar / 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. ## Referenzbeispiele (synthetisch) ### opjd-example-nsclc.json ```json { "schema_version": "0.2.0", "delivery": { "package_id": "PKG-2025-0001", "package_version": 1, "package_created_at": "2025-10-01T09:30:00+02:00", "sending_organization": "Universitätsklinikum Erlangen", "sending_system": "ONKOSTAR", "receiving_organization": "Universitätsklinikum Würzburg", "delivery_context": "research", "jurisdiction": "DE-BY", "legal_basis_category": "research_consent", "permitted_use": ["research", "quality_assurance"], "consent": { "status": "present", "scope": "standortübergreifende Forschung" }, "local_reconciliation_allowed": true }, "patient": { "patient_id": "PAT-7f3a9c", "id_kind": "pseudonym", "sex": "M" }, "tumors": [ { "tumor_id": "TU-2025-001", "icd10": { "code": "C34.1", "version": "2025" }, "icd_o_morphology": "8140/3", "diagnosis_date": "2024-11-20", "diagnosis_date_precision": "E" } ], "events": [ { "event_id": "EVT-2025-010", "type": "study_enrollment", "date": "2024-12-20", "tumor_ref": "TU-2025-001", "key_event": true, "note": "Einwilligung und Randomisierung (synthetische Studie)", "meta": { "provenance": "study", "currency": "current", "quality": "curated" } }, { "event_id": "EVT-2025-012", "type": "tumor_board", "date": "2024-12-05", "tumor_ref": "TU-2025-001", "key_event": true, "meta": { "provenance": "primary_clinical", "currency": "current", "quality": "curated" } }, { "event_id": "EVT-2025-013", "type": "systemic_therapy", "date": "2025-01-10", "tumor_ref": "TU-2025-001", "obds": { "SYST": { "Intention": "K", "Stellung_OP": "N" } }, "meta": { "provenance": "tumor_documentation", "currency": "current", "quality": "curated" } }, { "event_id": "EVT-2025-014", "type": "systemic_therapy", "date": "2025-02-01", "tumor_ref": "TU-2025-001", "meta": { "provenance": "tumor_documentation", "currency": "current", "quality": "curated" } }, { "event_id": "EVT-2025-015", "type": "systemic_therapy", "date": "2025-02-22", "tumor_ref": "TU-2025-001", "meta": { "provenance": "tumor_documentation", "currency": "current", "quality": "curated" } }, { "event_id": "EVT-2025-018", "type": "progress_report", "date": "2025-03-12", "tumor_ref": "TU-2025-001", "obds": { "Verlauf": { "Gesamtbeurteilung": "T" } }, "meta": { "provenance": "primary_clinical", "currency": "current", "quality": "curated" } }, { "event_id": "EVT-2025-019", "type": "tumor_board", "date": "2025-03-18", "tumor_ref": "TU-2025-001", "key_event": true, "meta": { "provenance": "primary_clinical", "currency": "current", "quality": "curated" } }, { "event_id": "EVT-2025-020", "type": "surgery", "date": "2025-04-03", "tumor_ref": "TU-2025-001", "obds": { "OP": { "Intention": "K", "OPS": "5-324.42" } }, "meta": { "provenance": "primary_clinical", "currency": "current", "quality": "curated" } }, { "event_id": "EVT-2025-021", "type": "pathology_report", "date": "2025-04-08", "tumor_ref": "TU-2025-001", "obds": { "Pathologie": { "TNM": "ypT1b ypN0", "Residualstatus": "R0" } }, "meta": { "provenance": "primary_clinical", "currency": "current", "quality": "curated" } } ], "episodes": [ { "episode_id": "EP-2025-002", "type": "neoadjuvant", "tumor_ref": "TU-2025-001", "intent": "curative", "start_event": "EVT-2025-012", "end_event": "EVT-2025-019", "events": ["EVT-2025-013", "EVT-2025-014", "EVT-2025-015", "EVT-2025-018"], "status": "completed", "meta": { "quality": "curated", "derived_from": ["Stellung_OP=N", "ycTNM"], "annotated_by_role": "tumor_documentation" } }, { "episode_id": "EP-2025-003", "type": "surgical", "tumor_ref": "TU-2025-001", "intent": "curative", "events": ["EVT-2025-020", "EVT-2025-021"], "status": "completed", "meta": { "quality": "curated" } }, { "episode_id": "EP-2025-010", "type": "study_participation", "tumor_ref": "TU-2025-001", "study": { "registry": "NCT", "code": "NCT99999999", "name": "SYNTH-NEO-01 (synthetisches Beispiel)", "arm": "Neoadjuvante Chemo-Immuntherapie" }, "start_event": "EVT-2025-010", "end_event": "EVT-2025-018", "events": ["EVT-2025-010", "EVT-2025-013", "EVT-2025-014", "EVT-2025-015", "EVT-2025-018"], "status": "completed", "meta": { "quality": "curated", "annotated_by_role": "tumor_documentation" } }, { "episode_id": "EP-2025-001", "type": "primary_case", "tumor_ref": "TU-2025-001", "organization": "Universitätsklinikum Erlangen", "start_event": "EVT-2025-012", "events": ["EVT-2025-012", "EVT-2025-013", "EVT-2025-019", "EVT-2025-020"], "status": "active", "meta": { "quality": "curated", "annotated_by_role": "tumor_documentation" } } ], "relations": [ { "relation_id": "REL-001", "type": "implements", "from": "EVT-2025-013", "to": "EVT-2025-012", "meta": { "quality": "curated" } }, { "relation_id": "REL-002", "type": "assesses", "from": "EVT-2025-018", "to": "EP-2025-002", "meta": { "quality": "curated" } }, { "relation_id": "REL-003", "type": "result_of", "from": "EVT-2025-021", "to": "EVT-2025-020", "meta": { "quality": "derived", "derived_from": ["Datumsfenster", "einziger Eingriff am Tumor"] } } ], "journey_status": [ { "tumor_ref": "TU-2025-001", "active_episode": "EP-2025-003", "last_assessment": { "event_ref": "EVT-2025-018", "overall_assessment": "T" } } ] } ``` ### opjd-example-prostate-as.json ```json { "schema_version": "0.2.0", "delivery": { "package_id": "PKG-2025-0002", "package_version": 1, "package_created_at": "2025-10-01T10:15:00+02:00", "sending_organization": "Universitätsklinikum Erlangen", "sending_system": "ONKOSTAR", "receiving_organization": "Universitätsklinikum Würzburg", "delivery_context": "research", "jurisdiction": "DE-BY", "legal_basis_category": "research_consent", "permitted_use": ["research", "quality_assurance"], "consent": { "status": "present", "scope": "standortübergreifende Forschung" }, "local_reconciliation_allowed": true }, "patient": { "patient_id": "PAT-3e8b21", "id_kind": "pseudonym", "sex": "M" }, "tumors": [ { "tumor_id": "TU-P-001", "icd10": { "code": "C61", "version": "2023" }, "icd_o_morphology": "8140/3", "diagnosis_date": "2023-05-12", "diagnosis_date_precision": "E" } ], "events": [ { "event_id": "EVT-P-001", "type": "surgery", "date": "2023-05-08", "tumor_ref": "TU-P-001", "note": "Stanzbiopsie der Prostata", "obds": { "OP": { "Intention": "D" } }, "meta": { "provenance": "primary_clinical", "currency": "current", "quality": "curated" } }, { "event_id": "EVT-P-002", "type": "pathology_report", "date": "2023-05-12", "tumor_ref": "TU-P-001", "note": "Adenokarzinom, Gleason 3+3=6 (ISUP 1)", "meta": { "provenance": "primary_clinical", "currency": "current", "quality": "curated" } }, { "event_id": "EVT-P-003", "type": "diagnosis", "date": "2023-05-12", "tumor_ref": "TU-P-001", "key_event": true, "obds": { "Diagnose": { "cTNM": "cT1c cN0 cM0" } }, "meta": { "provenance": "tumor_documentation", "currency": "current", "quality": "curated" } }, { "event_id": "EVT-P-004", "type": "tumor_board", "date": "2023-06-01", "tumor_ref": "TU-P-001", "key_event": true, "note": "Empfehlung Active Surveillance", "obds": { "Tumorkonferenz": { "Therapieempfehlung": "AS" } }, "meta": { "provenance": "primary_clinical", "currency": "current", "quality": "curated" } }, { "event_id": "EVT-P-005", "type": "progress_report", "date": "2023-09-15", "tumor_ref": "TU-P-001", "note": "PSA-Kontrolle, stabil", "obds": { "Verlauf": { "Gesamtbeurteilung": "K" } }, "meta": { "provenance": "primary_clinical", "currency": "current", "quality": "curated" } }, { "event_id": "EVT-P-006", "type": "progress_report", "date": "2024-03-20", "tumor_ref": "TU-P-001", "note": "PSA-Anstieg", "meta": { "provenance": "primary_clinical", "currency": "current", "quality": "curated" } }, { "event_id": "EVT-P-007", "type": "surgery", "date": "2024-04-10", "tumor_ref": "TU-P-001", "note": "Re-Stanzbiopsie", "obds": { "OP": { "Intention": "D" } }, "meta": { "provenance": "primary_clinical", "currency": "current", "quality": "curated" } }, { "event_id": "EVT-P-008", "type": "pathology_report", "date": "2024-04-15", "tumor_ref": "TU-P-001", "key_event": true, "note": "Upgrading: Gleason 4+3=7 (ISUP 3)", "meta": { "provenance": "primary_clinical", "currency": "current", "quality": "curated" } }, { "event_id": "EVT-P-009", "type": "tumor_board", "date": "2024-04-24", "tumor_ref": "TU-P-001", "key_event": true, "note": "Empfehlung radikale Prostatektomie", "obds": { "Tumorkonferenz": { "Therapieempfehlung": "OP" } }, "meta": { "provenance": "primary_clinical", "currency": "current", "quality": "curated" } }, { "event_id": "EVT-P-010", "type": "surgery", "date": "2024-05-21", "tumor_ref": "TU-P-001", "note": "Radikale Prostatektomie", "obds": { "OP": { "Intention": "K", "OPS": "5-604" } }, "meta": { "provenance": "primary_clinical", "currency": "current", "quality": "curated" } }, { "event_id": "EVT-P-011", "type": "pathology_report", "date": "2024-05-27", "tumor_ref": "TU-P-001", "obds": { "Pathologie": { "TNM": "pT2c pN0", "Residualstatus": "R0" } }, "meta": { "provenance": "primary_clinical", "currency": "current", "quality": "curated" } }, { "event_id": "EVT-P-012", "type": "progress_report", "date": "2024-09-10", "tumor_ref": "TU-P-001", "note": "PSA < 0,01 ng/ml", "obds": { "Verlauf": { "Gesamtbeurteilung": "V" } }, "meta": { "provenance": "primary_clinical", "currency": "current", "quality": "curated" } } ], "episodes": [ { "episode_id": "EP-P-1", "type": "first_diagnosis", "tumor_ref": "TU-P-001", "start_event": "EVT-P-001", "end_event": "EVT-P-004", "events": ["EVT-P-001", "EVT-P-002", "EVT-P-003", "EVT-P-004"], "status": "completed", "meta": { "quality": "curated", "annotated_by_role": "tumor_documentation" } }, { "episode_id": "EP-P-2", "type": "active_surveillance", "tumor_ref": "TU-P-001", "intent": "curative", "start_event": "EVT-P-004", "end_event": "EVT-P-009", "events": ["EVT-P-005", "EVT-P-006", "EVT-P-007", "EVT-P-008"], "status": "completed", "meta": { "quality": "curated", "derived_from": ["Tumorkonferenz-Empfehlung AS"], "annotated_by_role": "tumor_documentation" } }, { "episode_id": "EP-P-3", "type": "surgical", "tumor_ref": "TU-P-001", "intent": "curative", "start_event": "EVT-P-010", "end_event": "EVT-P-011", "events": ["EVT-P-010", "EVT-P-011"], "status": "completed", "meta": { "quality": "curated" } }, { "episode_id": "EP-P-4", "type": "follow_up", "tumor_ref": "TU-P-001", "events": ["EVT-P-012"], "status": "active", "meta": { "quality": "curated" } }, { "episode_id": "EP-P-5", "type": "primary_case", "tumor_ref": "TU-P-001", "organization": "Universitätsklinikum Erlangen", "start_event": "EVT-P-001", "events": ["EVT-P-001", "EVT-P-004", "EVT-P-010"], "status": "active", "meta": { "quality": "curated", "annotated_by_role": "tumor_documentation" } } ], "relations": [ { "relation_id": "REL-P-01", "type": "result_of", "from": "EVT-P-002", "to": "EVT-P-001", "meta": { "quality": "curated" } }, { "relation_id": "REL-P-02", "type": "assesses", "from": "EVT-P-005", "to": "EP-P-2", "meta": { "quality": "curated" } }, { "relation_id": "REL-P-03", "type": "result_of", "from": "EVT-P-008", "to": "EVT-P-007", "meta": { "quality": "curated" } }, { "relation_id": "REL-P-04", "type": "triggers", "from": "EVT-P-008", "to": "EP-P-3", "note": "Histologisches Upgrading beendet die Überwachung und löst die operative Episode aus", "meta": { "quality": "curated" } }, { "relation_id": "REL-P-05", "type": "implements", "from": "EVT-P-010", "to": "EVT-P-009", "meta": { "quality": "curated" } }, { "relation_id": "REL-P-06", "type": "result_of", "from": "EVT-P-011", "to": "EVT-P-010", "meta": { "quality": "curated" } }, { "relation_id": "REL-P-07", "type": "assesses", "from": "EVT-P-012", "to": "EP-P-3", "meta": { "quality": "curated" } } ], "journey_status": [ { "tumor_ref": "TU-P-001", "active_episode": "EP-P-4", "last_assessment": { "event_ref": "EVT-P-012", "overall_assessment": "V" } } ] } ``` ## Governance & Feedback ### docs/governance/PROZESS.md # Der oPJD-Änderungsprozess **Grundsatz:** Normativ ist das Repository — die Markdown-Dokumente unter `docs/` und die maschinenlesbaren Artefakte unter `public/schema/`. Die Website ist die lesbare Projektion. Jede inhaltliche Änderung an Schema, Dictionary oder Spezifikationstext durchläuft diesen Prozess. ## Der Weg eines Vorschlags Der Prozess bildet die fünf Schritte der Governance ab (Vorschlag → fachliche Bewertung → technische Prüfung → Entscheidung → Kommunikation). Der öffentliche Kanal ist die Website samt E-Mail-Eingang; die interne Verarbeitung läuft im (derzeit privaten) Repository: ### 1. Idee Eine **strukturierte E-Mail** an alexander.kerscher@kerscher-lab.org nach dem Feedback-Kontrakt des Manifests — formlos ist ebenso willkommen. Offen für alle: Kliniker:innen, Tumordokumentar:innen, Implementierer:innen, KI-Agenten (das MCP-Werkzeug `opjd_propose_change` erzeugt einen vorbefüllten E-Mail-Entwurf). ### 2. Proposal Der Vorschlag wird als `docs/proposals/NNNN-kebab-titel.md` ausgearbeitet (Vorlage: [`0000-template.md`](../proposals/0000-template.md), nächste freie vierstellige Nummer) und mit Status `entwurf` geführt; die Bearbeitung läuft intern als Pull Request. Der Proposal-Text beantwortet: Problem und klinische Begründung, konkreter Vorschlag, oBDS-Bezug, Kompatibilität (SemVer-Einstufung), Auswirkung auf Implementierer, Datenschutz, erwogene Alternativen. ### 3. Review Status `in-review`. Zwei Prüfpfade müssen **dokumentiert** bestanden sein: - **Fachlich**: klinische Relevanz, oBDS-Bezug, Versorgungsnutzen, Passung zu den Evolutionsprinzipien (Kernmodell klein, Erweiterungen modular). - **Technisch**: Schema-Konsistenz, SemVer-Einstufung, Migrationsaufwand, Dictionary-/Beispiel-Folgeänderungen. **Mindestkommentierungsfristen:** Patch/redaktionell: keine (normaler PR-Review). Minor (additiv): **14 Tage**. Major (Bedeutungsänderung/Bruch): **30 Tage** plus aktive Information der Implementierungspartner (siehe [ROLLEN.md](ROLLEN.md)). > Bis zur Erweiterung des Maintainer-Kreises erfolgen beide Prüfungen durch den > Maintainer und werden getrennt als Review-Kommentare dokumentiert. ### 4. Entscheidung Der Proposal-Status wird auf `angenommen`, `abgelehnt` oder `zurückgestellt` gesetzt (Dokumentkopf). Bei Architektur-Tragweite entsteht zusätzlich eine ADR in [`docs/decisions/`](../decisions/) (Format siehe dort; Updates in place). Angenommene Proposals und alle Entscheidungen werden auf der Website unter `/docs/` veröffentlicht. ### 5. Aufnahme & Kommunikation Der Umsetzungs-PR ändert zusammenhängend: Schema + Beispiele + Dictionary + CHANGELOG + `versions.json` (inkl. `sha256`) und führt `npm run sync:latest` aus. Release gemäß Release-Train; Kommunikation über Changelog und Website sowie direkte Information der Implementierungspartner. ## Proposal-Status `entwurf` | `in-review` | `angenommen` | `abgelehnt` | `zurückgestellt` — im Dokumentkopf. ## Versionierung & Release-Train - **SemVer mit Domänensemantik**: MAJOR = Bedeutungsänderung oder Strukturbruch (Migration erforderlich), MINOR = additive Erweiterung oder Präzisierung ohne Bruch, PATCH = redaktionell. Sonderregel 0.x: auch Minor darf brechen (BREAKING-markiert). - **0.x-Phase**: Sammel-Releases nach Bedarf. **Ab 1.0**: gebündelte Minor-Releases maximal zweimal pro Jahr; Patches jederzeit. - **Lebenszyklus** je Version: `draft → review → released → deprecated → retired` (Definitionen in [`versions.json`](../../public/schema/versions.json) und [KONFORMITAET.md](KONFORMITAET.md)). `released` ist eine Einbahnstraße; die Schemadatei ist ab dann byte-eingefroren (SHA-256 CI-erzwungen) — Korrekturen erzeugen eine neue Version. - **Release-Notes**: `docs/releases/.md` entsteht spätestens beim Statuswechsel nach `review`, Pflicht ab `released`; bei Breaking Changes zeigt `migration_url` darauf. - **Git-Tags** `spec/vX.Y.Z` erst ab Status `released`. ## Verzahnung mit OncoFlow / BZKF Der öffentliche Prozess bereitet Entscheidungen vor und dokumentiert sie. Beschlüsse der OncoFlow-Gremien (AP1-Konsensgremium, AG Krebsregister) werden als Proposals bzw. ADRs in das Repository gespiegelt. **Die Freigabe der Version 1.0 erfolgt durch den nationalen Konsensworkshop (AP1); der Maintainer setzt sie um.** Der Community-Prozess ersetzt die Gremien nicht — er macht ihre Arbeit öffentlich anschlussfähig. ### docs/governance/KONFORMITAET.md # oPJD-Konformität Was „oPJD-konform" bedeutet, in drei aufeinander aufbauenden Stufen — und welche Versionen für den Austausch gültig sind. ## Konformitätsstufen ### Stufe 1 — schema-valide > Das Paket validiert ohne Fehler gegen das JSON Schema der deklarierten > `schema_version` (Draft 2020-12, strikte Validierung inkl. Formatprüfung). ### Stufe 2 — referenziell integer > Zusätzlich: alle IDs paketweit eindeutig; jede Referenz (`tumor_ref`, `events[]`, > `start_event`/`end_event`, `relation.from`/`to`, `journey_status.*`) löst auf ein > existierendes Objekt auf; Relationsziele entsprechen dem erwarteten Zieltyp > (z. B. `triggers` → Episode, `result_of` → Ereignis). ### Stufe 3 — grammatik-geprüft > Zusätzlich: die Episodengrammatik ist maschinell ausgewertet — Verlaufsphasen je Tumor > überlappungsfrei, Kontextklammern parallel zulässig, Erwartungsregeln je Episodentyp > (z. B. neoadjuvant erwartet eine assesses-Beurteilung, Überwachungsepisoden erwarten > Kontrollereignisse); die Befunde liegen dem Paket bei oder sind abrufbar. **Deklarationsregel:** Ein Absender darf „oPJD-konform (Stufe n)" nur deklarieren, wenn die Prüfungen der Stufe automatisiert bestanden sind. **Prüfwerkzeuge:** Stufe 1 heute via `npm run validate` (Referenzbeispiele) bzw. ajv; Stufe 1–2 plus Grammatik-Hinweise via MCP-Werkzeug `opjd_validate`; Stufe 3 vollumfänglich auf Validator-Ebene (ValiQon-Anschluss, in Arbeit). ## Versionsgültigkeit für Austauschpartner > Neue Pakete deklarieren in `schema_version` eine Version mit Status `released` > (bevorzugt `latest_released`); während der 0.x-Phase ersatzweise die aktuelle > draft-/review-Version nach bilateraler Absprache. Empfänger müssen alle Versionen mit > Status `released` sowie `deprecated` (bis `sunset_at`) annehmen. Lebenszyklus-Definitionen: siehe [`versions.json`](../../public/schema/versions.json) (`lifecycle`) — draft (Entwurf), review (Konsultation), released (Freigegeben), deprecated (Abgekündigt), retired (Zurückgezogen). Zulässige Übergänge: `draft→review`, `review→draft` (Rückläufer), `review→released`, `released→deprecated`, `deprecated→retired`, `draft→retired` (verworfen). `released` ist eine Einbahnstraße. **Einfrier-Regel:** Ab Status `released` ist die Schemadatei byte-eingefroren; `versions.json` führt ihre SHA-256-Prüfsumme, die CI erzwingt sie. Korrekturen — auch Tippfehler — erzeugen eine neue Patch-Version. ## Kompatibilitätszusagen > Innerhalb einer Major-Linie ab 1.0 gilt: Ein Empfänger, der 1.x liest, liest jede 1.y > (y ≥ x); neue optionale Felder darf er ignorieren. Enum-Werte werden nie entfernt oder > umbenannt, sondern als deprecated markiert und frühestens in der nächsten Major-Version > entfernt. Pflichtfelder werden innerhalb einer Major-Linie nie hinzugefügt. Term-Identitäten (`opjd://…`) sind versionsübergreifend stabil; Lebenszyklus je Term über `deprecated_in`/`superseded_by` im Dictionary. ### Feedback-Kontrakt (aus dem Manifest) ```json { "channel": "email", "url": "mailto:alexander.kerscher@kerscher-lab.org?subject=%5BoPJD-Vorschlag%5D", "note": "Vorschläge per strukturierter E-Mail nach dem contract-Format (das MCP-Werkzeug opjd_propose_change erzeugt einen vorbefüllten Entwurf). Eine Web-Einreichung direkt auf der Website folgt. Angenommene Vorschläge und Entscheidungen werden unter /docs/ veröffentlicht.", "contract": { "use_case": "string (de) — welcher reale Anwendungsfall ist nicht abbildbar?", "affected_terms": "string[] — betroffene opjd://-IDs (leer bei neuem Konzept)", "missing_facts": [ { "path": "string — vorgeschlagener Pfad", "reason": "string — warum wird er gebraucht?" } ], "proposal": "string — konkreter Vorschlag inkl. Vokabular", "backward_compatible": "boolean — additiv (minor) oder Bedeutungsänderung (major)?", "process": "Vorschlag → fachliche Bewertung → technische Prüfung → Entscheidung → Kommunikation (siehe /governance und /docs/governance/PROZESS.md)" } } ``` ## MCP-Server Paket: `@kerscher-lab/opjd-mcp` (stdio) — Installation: `npx -y @kerscher-lab/opjd-mcp` Werkzeuge: opjd_overview, opjd_list_versions, opjd_get_schema, opjd_explain, opjd_validate, opjd_get_example, opjd_map_obds, opjd_propose_change.