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

• 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

• Übermittlung erfolgt in nur einem Exportformat

• beim RKI ist der Gesamtdatenbestand verfügbar (vor 2020 allerdings auf die epi Merkmale beschränkt)

Nachteile

• frühere Therapieangaben mit Ausprägungen J/N würden im XML-Schema nicht mehr übermittelt. Aus Sicht des 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 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

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

• zur Integration dieser 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ücksichtigt

• ebenfalls angenommen wird, dass die Therapieangaben der epi Daten nicht überführt werden

• entsprechend 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:

...

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