Kernobjekte
Das oPJD arbeitet mit einer begrenzten Zahl klar definierter Objekte. Jedes Objekt hat eine feste Semantik und steht in definierten Beziehungen zu anderen Objekten.
| Objekt | Beschreibung |
|---|---|
| Paket / Delivery | Die Austauschhülle: Absender, Empfänger, Rechtsgrundlage, Zweck, Gültigkeit (siehe Data Delivery). |
| Patient | Die zentrale Bezugsperson. Pseudonymisiert oder identifiziert, je nach Einsatzkontext. |
| Tumor / Entität | Eine konkrete Tumorerkrankung. Mehrere Tumoren pro Patient möglich. |
| Ereignis | Die atomare, dokumentierte Tatsache — mit unveränderter oBDS-Nutzlast und eigenem Metadaten-Layer. |
| Episode | Klinische Behandlungsklammer, die Ereignisse gruppiert — als Verlaufsphase (inkl. Active Surveillance / Watchful Waiting) oder als Kontextklammer (Studienphase, Primär-/Zentrumsfall). |
| Relation | Gerichteter, typisierter Bezug: result_of, implements, assesses, triggers (siehe Clinical Model). |
| Journey-Status | Optional: konsolidierter aktueller Zustand je Tumor (aktive Episode, letzte Bewertung, Linie). |
Pflichtfelder je Objekt
Die Pflichtfelder folgen dem formalen Kontrakt (siehe unten). Für die drei Kernobjekte der klinischen Ebene:
Ereignis
| Feld | Typ | Beschreibung |
|---|---|---|
| event_id | String | Stabile, eindeutige Kennung (Zutat 1: Adressen) |
| type | Enum | Gemappt auf die oBDS-Dokumentzweige: diagnosis, pathology_report, surgery, radiation_therapy, systemic_therapy, progress_report, tumor_board, death — plus der oPJD-Zusatztyp study_enrollment (Studieneinschluss; im oBDS nicht abbildbar) |
| date | Date | Datum des Ereignisses (optional mit Genauigkeit E/T/M/J nach oBDS) |
| tumor_ref | String | Bezug auf die konkrete Tumorentität |
| meta | Objekt | Metadaten-Layer: provenance, currency, quality (siehe unten) |
Optional trägt jedes Ereignis die unveränderte oBDS-Nutzlast (obds), eine Markierung als Schlüsselereignis (key_event) und eine Datumsgenauigkeit (date_precision).
Episode
| Feld | Typ | Beschreibung |
|---|---|---|
| episode_id | String | Stabile, eindeutige Kennung |
| type | Enum | Verlaufsphasen: first_diagnosis, neoadjuvant, surgical, adjuvant, follow_up, progression, palliative_line, active_surveillance, watchful_waiting · Kontextklammern: study_participation, primary_case, center_case |
| tumor_ref | String | Bezug auf die konkrete Tumorentität |
| events | String[] | Alle Ereignisse dieser Episode (event_ids) |
| meta | Objekt | Qualität der Interpretation: curated oder derived, inkl. Indizien (derived_from) |
Optional: intent (Intention auf Episodenebene), line_number (Therapielinie), start_event / end_event (Grenzereignisse) und status. Zwei Felder sind bedingt verpflichtend: Eine Studienphase (study_participation) muss den Studienbezug study tragen (Register NCT/DRKS/EudraCT, Nummer, optional Name und Arm); eine Fallklammer (primary_case / center_case) muss die deklarierende Einrichtung organization nennen. Beides erzwingt das JSON Schema über Bedingungsregeln.
Die Zuordnung wohnt in der Episode
events[]) — denn die Klammer ist die kuratierbare Interpretationsschicht, während die Ereignisse mit ihrer oBDS-Nutzlast unangetastet bleiben. Ändert sich die Kuratierung, ändern sich die Episoden, nie die Ereignisse.Relation
| Feld | Typ | Beschreibung |
|---|---|---|
| relation_id | String | Stabile, eindeutige Kennung |
| type | Enum | result_of, implements, assesses, triggers |
| from | String | event_id des aussprechenden Ereignisses |
| to | String | event_id oder episode_id des Bezugsziels (typabhängig) |
| meta | Objekt | Qualität der Interpretation: curated oder derived |
Metadaten-Layer
Der Metadaten-Layer ist eine der zentralen Ergänzungen des oPJD gegenüber bestehenden Datensätzen. Er macht Herkunft, Frische und Belastbarkeit von Informationen transparent — und zwar auf zwei Ebenen: für die dokumentierten Tatsachen (Ereignisse) und für die Interpretationsschicht selbst (Episoden, Relationen).
Provenance — Woher stammt die Information?
primary_clinical— Primärdokumentation Kliniktumor_documentation— Spezialisierte Tumordokumentationregistry— Registerdaten (z.B. Landeskrebsregister)study— Studienkontextcertification— Zertifizierungsdokumentationexternal— Externe Meldung
Aktualität — Wie synchron ist die Information?
current— zeitnah dokumentiert, gilt als aktueller Standdelayed— mit Zeitversatz eingegangenhistorical— aus Altdatenübernahme oder Archiv
Ergänzend: Datum der letzten Bestätigung oder Aktualisierung (last_confirmed_at).
Qualitätsniveau — Wie belastbar ist sie?
Keine hochwissenschaftliche Evidenzbewertung, sondern eine praktikable Einschätzung. Für Ereignisse:
curated— direkt dokumentiert bzw. kuratiert (behandelnder Arzt, Tumordokumentation)derived— abgeleitet oder sekundär übernommenlimited— bekannte Einschränkungen in der Datenqualitätunconfirmed— noch nicht validiert oder freigegeben
Für die Interpretationsschicht (Episoden, Relationen) ist die Skala bewusst zweistufig — derived (algorithmisch aus oBDS-Indizien vorgeschlagen) oder curated (fachlich bestätigt) — ergänzt um die Indizien selbst (derived_from, z.B. "Stellung_OP=N", "ycTNM").
Regelbasiert, nicht personenabhängig
annotated_by_role eine Rolle (algorithm, tumor_documentation, physician), keine Person.Beispiele
Die folgenden Ausschnitte sind konform zum formalen Kontrakt (siehe unten) und zeigen dieselben drei oBDS-Meldungen eines NSCLC-Verlaufs — einmal als Ereignisse mit unveränderter Nutzlast, einmal die Klammer-Schicht darüber.
Ereignis mit oBDS-Nutzlast
{
"event_id": "EVT-2025-021",
"type": "pathology_report",
"date": "2025-04-08",
"tumor_ref": "TU-2025-001",
"obds": { "Pathologie": "… unveränderte oBDS-Nutzlast (ypT1b ypN0, R0) …" },
"meta": {
"provenance": "primary_clinical",
"currency": "current",
"quality": "curated"
}
}Neoadjuvante Episode
{
"episode_id": "EP-2025-002",
"type": "neoadjuvant",
"tumor_ref": "TU-2025-001",
"intent": "curative",
"start_event": "EVT-2025-012", // Tumorboard-Beschluss
"end_event": "EVT-2025-019", // OP-Freigabe nach Restaging
"events": ["EVT-2025-013", "EVT-2025-014", "EVT-2025-015", "EVT-2025-018"],
"meta": {
"quality": "curated",
"derived_from": ["Stellung_OP=N", "ycTNM"]
}
}Relationen
[
{ "relation_id": "REL-001", "type": "implements",
"from": "EVT-2025-013", "to": "EVT-2025-012", // Chemo setzt Board-Beschluss um
"meta": { "quality": "curated" } },
{ "relation_id": "REL-002", "type": "assesses",
"from": "EVT-2025-018", "to": "EP-2025-002", // Restaging beurteilt Neoadjuvanz
"meta": { "quality": "curated" } },
{ "relation_id": "REL-003", "type": "result_of",
"from": "EVT-2025-021", "to": "EVT-2025-020", // Pathobefund gehört zur Lobektomie
"meta": { "quality": "derived",
"derived_from": ["Datumsfenster", "einziger Eingriff am Tumor"] } }
]Formaler Kontrakt (JSON Schema)
Die Struktur des oPJD-Pakets ist als maschinenlesbarer Kontrakt formalisiert — ein JSON Schema (Draft 2020-12), gegen das Exporte und Importe automatisiert validiert werden können:
- Versionierung: SemVer. Breaking Changes erhöhen die Major-, additive Felder die Minor-Version. Jede Instanz trägt ihre
schema_version. - Geltungsbereich: Das Schema erzwingt Struktur, Typen und Vokabulare. Referenzielle Integrität (existieren alle referenzierten IDs?) und die klinische Grammatik (fehlt der neoadjuvanten Episode die Response-Beurteilung?) sind bewusst Validator-Ebene — dort setzt die Prüflogik an, wie sie im Schwesterprojekt ValiQon etabliert ist.
- Würdevolles Degradieren: Ein Paket mit leerer Episoden- und Relationsliste ist schema-konform — es ist dann ein reines Ereignis-Paket auf oBDS-Niveau. Der Mehrwert entsteht mit der Klammer-Schicht.
Status