Seitenvergleich

...

• 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

...

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