Seitenvergleich

...

• das RKI schlägt vor, die epidemiologischen Daten in das xml Schema zu integrieren https://plattform65c.atlassian.net/wiki/spaces/P6/pages/7143545/Allgemeine+Vereinbarungen#Integration-der-epi-Daten

• im Folgenden ist das dazu notwendige Mapping der epidemiologischen auf die klinischen Variablen dargelegt

...

• oBDS-RKI zu integrieren

• sollte diese Variante nicht in allen Lieferregistern zu realisieren sein, wäre eine Übermittlung im alten Format vorstellbar, dies ist hier dargelegt XXX

• eine Mischform der beiden Varianten (Lieferregister verwenden wahlweise eine der Übermittlungen) ist aus Datenkonsistenzgründen nicht abbildbar

Lieferung der Daten als Bestandteil des oBDS-RKI

Modus der Übermittlung

• alle Daten (auch Diagnosen bis 2019) werden nach oBDS-RKI übermittelt

  • vor Diagnosejahr 2020 nur Angaben zur Person und Primärdiagnose und nur soweit nach altem Gesetz zulässig

  • auf Therapieangaben nach früherem Format wird verzichtet (z.B. OP ja/nein)

Vorteile

• Nur ein Exportformat

• Ein Gesamtdatenbestand beim ZfKD, allerdings vor 2020 viele Merkmale fehlend.

Nachteile

• Frühere Therapieangaben mit Ausprägungen J/N würden im XML-Schema nicht mehr übermittelt. Aus Sicht des ZfKD verschmerzbar, tendenziell sogar sinnvoll: klinische Auswertungen sollten erst ab Diagnosejahr 2020 erfolgen, da Datenlage bzgl. Therapien für Vorjahre in vielen Bundesländern nicht vergleichbar ist und bundesweite Auswertungen so in die Irre führen können

• Einige Ausprägungen bzw. Konfigurationen im neuen Lieferdatensatz entsprechen nicht genau den Epi-Daten (z.B. Diagnosesicherung DCO, Vitalstatus, DCN, evtl. TNM). Hier müssten Vereinbarungen getroffen werden

Mapping der epi Daten

• grundsätzlich werden alle Fälle mit mit Diagnosejahr <= 2019 im epi Format geliefert

• die für die Lieferung der epi Daten getroffene Vereinbarung sieht vor, dass 55 Variablen an das RKI übermittelt werden, siehe Liste:

• zur Integration dieser Variablen in das bestehende oBDS-RKI Schema ist eine Überführung nötig (“Mapping”)

• ein Teil dieses Variablensets wird nicht verarbeitet, und ist im vorliegenden Mapping nicht weiter berücksichtigtebenfalls angenommen wird, dass

• die Therapieangaben der epi Daten nicht überführt werdendie Übersicht mit Bewertung zum Mapping ist in folgender Liste dargelegt:

Simulation anhand eines vereinfachten samples

• gegeben ist eine fiktive Lieferung von epi Daten an das RKI, mit 2 Patienten

  • Patient 1: möglichst viele Angaben sind bekannt, alle verwendeten Informationen sollen im xml Schema eindeutig kodiert werden können

  • Patient 2: möglichst wenige Angaben sind bekannt, xml Schema soll dennoch valide sein (Pflichtfelder müssen angegeben sein)

• xls Liste der Lieferung hier:

...

Schlussfolgerungen für das Mapping

• die entstehende xml Datei ist valide gegen das xml Schema (die übermittelten Werte müssen natürlich erlaubt sein)

• alle laut Mapping Liste aktiv verwendeten Variablen lassen sich also grundsätzlich im Schema transportieren

• derzeit verlangt das Schema folgende Pflichtangaben

  • Datum / Ursprungsregister der Lieferdatei

  • Patient_ID, Tumor_ID

  • Patienten-Stammdaten

    • Geschlecht

    • GebDatum

    • Vitalstatus (kann aus den epi Angaben hinreichend konstruiert werden, sofern Follow-up-Datum verfügbar)

  • Tumor

    • Primärdiagnose

      • Datum

      • Inzidenzort (fehlende Werte wurden in den epi Daten auf das liefernde Bundesland imputiert. Ein “00000“ wäre im Schema als fehlender Wert zu interpretieren)

      • ICD Code Primärtumor (Version optional)

      • Seitenlokalisation (U = Unbekannt)

      • DCN (hier wäre eine Vereinbarung zu treffen)

        • Vorschlag: da die Variable im alten Gesetz noch nicht erwähnt, können alle Fälle bis Diagnosejahr 2019 auf ‘kein DCN’ gesetzt werden

      • Anzahl_Tage_Diagnose_Tod (kann mit N kodiert werden als “unzutreffend”)

• eine Unterscheidung von epi. und klin. Datenbestandteilen im Schema ist nicht notwendig

Alternative: Fortführung der Lieferung nach altem Epi-Format als separate Übermittlung

Vorteile

• Lieferung ist für bisherige epi-Register ohne Zusatzaufwand machbar

Nachteile

• Lieferung ist für GKR-Länder ein neu zu implementierendes Exportformat

• es entstehen zwei separate Datenbestände beim ZfKD, welche über passende ID in der klinischen und epidemiologischen Lieferung verknüpfbar sein müssen, um einen konsistenten Datensatz pro Person herstellen zu können

• diese Verknüpfbarkeit ist bislang rechtlich / organisatorisch / technisch nicht abschliessend geklärt