Zum Ende der Metadaten springen
Zum Anfang der Metadaten

Sie zeigen eine alte Version dieser Seite an. Zeigen Sie die aktuelle Version an.

Unterschiede anzeigen Seitenhistorie anzeigen

« Vorherige Version anzeigen Version 6 Nächste Version anzeigen »

Hintergrund

  • 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

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 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ücksichtigt

  • die Ü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:

  • im nächsten Schritt werden diese Angaben in das xml Schema (Version 6) überführt

  • hier die entstehende xml dieser Lieferung:

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

  • Keine Stichwörter