ooPJD

Governance & Evolution

Wie das oPJD kontrolliert, konsistent und weiterentwickelbar bleibt — mit realer Infrastruktur: Versionsregister, öffentlichem Änderungsprozess, definierten Rollen und maschinell erzwungener Konsistenz. Alles hier auf der Website.

Diese Website ist die Publikation

Normativ sind die hier veröffentlichten Dokumente unter /docs/governance/ und die Maschinenartefakte unter /schema/ — diese Seite ist ihre lesbare Zusammenfassung. Entscheidungen, Prozesse und Versionen sind vollständig auf dieser Website einsehbar.

Versionierung

Das oPJD wird über ein maschinenlesbares Versionsregister geführt: jede Version mit Status, Gültigkeitsfenstern, SHA-256-Prüfsumme und Links auf Schema, Dictionary, Beispiele und Changelog. Die Übersicht mit Lebenszyklus und Gültigkeitsregeln: Versionen & Gültigkeit.

SemVer mit Fachsemantik

MAJOR = Bedeutungsänderung oder Strukturbruch (Migration erforderlich). MINOR = additive Erweiterung oder Präzisierung ohne Bruch. PATCH = redaktionell. Sonderregel 0.x: auch Minor darf brechen und wird dann im Changelog als BREAKING markiert.
  • Quelle der Wahrheit — versionierte Ablage unter /schema/<version>/; die unversionierten Pfade sind synchronisierte Bequemlichkeits-Aliase.
  • Eingefrorene Releases — ab Status released ist die Schemadatei byte-eingefroren (SHA-256, maschinell erzwungen); Korrekturen erzeugen neue Versionen.
  • Stabile Terme — Dictionary-IDs (opjd://…) werden nie gelöscht, sondern deprecated und ggf. superseded.
  • Changelog — öffentlich unter /changelog, von versions.json referenziert.

Änderungsprozess

Jede inhaltliche Änderung durchläuft fünf Schritte. Der Einstieg ist bewusst niedrigschwellig — eine E-Mail genügt:

  1. Vorschlag — offen für alle: strukturierte E-Mail an alexander.kerscher@kerscher-lab.org (KI-Agenten nutzen das MCP-Werkzeug opjd_propose_change, das den Entwurf nach dem Feedback-Kontrakt vorbefüllt).
  2. Proposal — der Vorschlag wird als Dokument nach der Vorlage ausgearbeitet: klinische Begründung, konkreter Vorschlag, oBDS-Bezug, Kompatibilität.
  3. Review — fachlich und technisch, getrennt dokumentiert. Kommentierungsfristen: Minor 14 Tage, Major 30 Tage + aktive Information der Implementierungspartner.
  4. Entscheidung — angenommen, abgelehnt oder zurückgestellt; bei Architektur-Tragweite als dokumentierte Entscheidung (ADR). Angenommene Proposals und alle Entscheidungen werden unter /docs/decisions/ veröffentlicht.
  5. Aufnahme & Kommunikation — Schema, Dictionary, Beispiele, Changelog und Register ändern sich zusammenhängend; maschinelle Prüfungen erzwingen die Konsistenz; Veröffentlichung hier, Information der Partner direkt.

Der vollständige, normative Prozess: Änderungsprozess (PROZESS.md).

Rollen

  • Maintainer — heute Alexander Kerscher (Kerscher-Lab); ab Projektstart OncoFlow (10/2026) erweitert um die OncoFlow-Projektmitarbeiter:in am CCC Erlangen.
  • Fachliche Kuratierung — klinische Korrektheit, Episodengrammatik, oBDS-Bezug. Heute in Personalunion beim Maintainer, getrennt dokumentiert.
  • Technische Kuratierung — Schema-/Dictionary-Konsistenz, SemVer-Einstufung, Prüfketten und Register.
  • Implementierungspartner — öffentlich gelistet in ROLLEN.md; Aufnahme per Implementierungsfeedback (E-Mail). Zusagen: aktive Information bei Major-Änderungen, Einladung zu Review-Phasen.
  • Klinische Rückkopplung — offen per E-Mail, strukturiert über die AG-Termine.
  • Advisory (extern) — AP1-Konsensgremium und AG Krebsregister (BZKF).

Verzahnung mit OncoFlow/BZKF

Der öffentliche Prozess bereitet Entscheidungen vor und dokumentiert sie. Beschlüsse der OncoFlow-Gremien werden als veröffentlichte Proposals bzw. Entscheidungen gespiegelt. Die Freigabe der Version 1.0 erfolgt durch den nationalen Konsensworkshop (AP1); der Maintainer setzt sie um. Der öffentliche Prozess ersetzt die Gremien nicht — er macht ihre Arbeit anschlussfähig.

Konformität

Drei aufeinander aufbauende Stufen — deklarierbar nur bei automatisiert bestandener Prüfung:

  • Stufe 1 — schema-valide: fehlerfreie Validierung gegen das JSON Schema der deklarierten Version.
  • Stufe 2 — referenziell integer: zusätzlich eindeutige IDs und auflösbare Referenzen mit korrekten Zieltypen.
  • Stufe 3 — grammatik-geprüft: zusätzlich maschinell ausgewertete Episodengrammatik.

Vollständige Definitionen, Versionsgültigkeit und Kompatibilitätszusagen: KONFORMITAET.md bzw. die Kurzfassung unter Versionen & Gültigkeit.

Prinzipien der Weiterentwicklung

  1. Kernmodell klein halten — Nur klinisch belegte und breit relevante Elemente gehören in den Kern.
  2. Erweiterungen modular — Neue Felder und Strukturen werden als optionale Module ergänzt, nicht in den Kern gezwungen.
  3. Nur klinisch relevante Komplexität — Jedes neue Element muss einen konkreten klinischen Mehrwert nachweisen.
  4. Anschlussfähigkeit vor Perfektion — Pragmatische Lösungen, die in der aktuellen Infrastruktur funktionieren, haben Vorrang.
  5. Transparenz — Alle Entscheidungen, Änderungen und Prozesse sind auf dieser Website öffentlich nachvollziehbar.

Leitgedanke

Das oPJD wächst durch Praxis, nicht durch Theorie. Erweiterungen entstehen aus realen Implementierungserfahrungen und klinischen Anforderungen — nicht aus Vollständigkeitsanspruch.

Öffentliche Verfügbarkeit

Diese Website ist die lebende Spezifikation des oPJD. Kein verstecktes PDF, kein interner Wiki-Artikel, sondern eine öffentlich zugängliche, versionierte und nachvollziehbare Dokumentation:

Open Specification

oPJD versteht sich als offene Spezifikation (Apache-2.0 / CC BY 4.0). Transparenz ist kein Nebenprodukt, sondern ein Kernprinzip. Wer das Modell nutzt, soll es auch vollständig verstehen und mitgestalten können — Mitmachen.