Seitenvergleich

...

• das RKI schlägt vor, die epidemiologischen Daten in 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

...

• 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 Übermittlung erfolgt in nur einem Exportformat

• Ein Gesamtdatenbestand beim ZfKD, allerdings vor 2020 viele Merkmale fehlend.beim RKI ist der Gesamtdatenbestand verfügbar (vor 2020 allerdings auf die epi Merkmale beschränkt)

Nachteile

• Frühere frühere Therapieangaben mit Ausprägungen J/N würden im XML-Schema nicht mehr übermittelt. Aus Sicht des ZfKD RKI 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 einige Ausprägungen bzw. Konfigurationen im neuen Lieferdatensatz entsprechen nicht genau den Epi-epi Daten (z.B. Diagnosesicherung DCO, Vitalstatus, DCN, evtl. TNM). Hier müssten Vereinbarungen getroffen werden

Mapping der epi Daten

Syntax der Überleitungen

• 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 Merkmale an das RKI übermittelt werden, siehe Liste:

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

• ein Teil dieses Variablensets Merkmalsets wird aus verschiedenen Gründen im RKI nicht verarbeitet, und ist im vorliegenden Mapping nicht weiter berücksichtigtentsprechend gekennzeichnet

• die Übersicht mit Bewertung zum Mapping ist in folgender Liste dargelegt:

Mögliche semantische Konflikte

• auch wenn die Syntax des Schemas die Integration der epi Daten zulässt, sind an einigen Stellen Konflikte beim Inhalt der Variablen denkbar, insbesondere hier:

  • DCN: wenn für die epi Daten die (verpflichtende) DCN Angabe nicht möglich ist, kann als fallback die Ausprägung N verwendet werden, was für die RKI Auswertungen unschädlich ist

  • Diagnosesicherung = 3: Mit diesem Wert sind in den epi Daten DCO Fälle kodiert. Die Ausprägung existiert nicht in oBDS-RKI. Aushilfsweise soll dann Diagnosesicherung auf den Wert 0 (DCO) umgesetzt werden. In den epi Daten ist Diagnosesicherung 0 als “Obduktion” deklariert, diese Bedeutung wird dann aufgegeben. Zur Relation: Im aktuellen epi Gesamtdatensatz sind von 12,6 Mio gültigen Fällen etwa 1.400 mit Diagnosesicherung 0 attribuiert

  • TOD J/N: Die Überführung dieser Variable zusammen mit Sterbedatum und Todesursachen in das komplexere Element Vitalstatus sollte verlustfrei und eindeutig möglich sein

  • TNM: die vorliegenden Angaben in den epi Daten werden je nach Präfix Variable in ein c oder p Element in oBDS-RKI überführt. Liegt kein Präfix vor, wird c als default angenommen. Die Elemente innerhalb des TNM-Typ sind alle optional, bieten also viel Freiraum für Kombinationen

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 XML-Schema eindeutig kodiert werden können

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

• xls Liste der Lieferung hier:

...

• 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 abschließend geklärt