Versionen im Vergleich

Alte Version 16

changes.mady.by.user MeisegeierS (Unlicensed)

Gespeichert am

verglichen mit

Neue Version Aktuell

changes.mady.by.user MeisegeierS (Unlicensed)

Gespeichert am

Schlüssel

  • Diese Zeile wurde hinzugefügt.
  • Diese Zeile wurde entfernt.
  • Formatierung wurde geändert.

...

Der erweiterte Lieferdatensatz nach Gesetz zur Zusammenführung von Krebsregisterdaten gilt ab dem Diagnosejahr 2020, die erste Datenlieferung zum 31.12.2022 betrifft somit aufgrund der Verkürzung der Lieferfrist die Diagnosejahre 2020 und 2021. In den kommenden Jahren werden Ergänzungen zu den bereits übermittelten Fällen bis einschl. Diagnosejahr 2019 (z.B. Sterbefälle, Nachmeldungen, Änderungen der Diagnose, Diagnosesicherung) übermittelt, in welcher Form dies geschieht, wird noch geklärt.. Nach aktuellem Stand wird vereinbart, dass auch die aktualisierten Bestandsdaten (Diagnosejahre bis 2019) nach dem neuen Schema übermittelt werden. Angaben zur Therapie nach altem Schema (z.B. Operation ja/nein) für Diagnosen bis 2019 müssen nicht mehr übermittelt werden, da eine Auswertung über den Gesamtzeitraum (bis 2019/ab 2020) nicht sinnvoll erscheint. Einige Ausprägungen bzw. Konfigurationen im neuen Lieferdatensatz entsprechen nicht genau dem Schema der früheren Epi-Daten (z.B. Diagnosesicherung, Vitalstatus, DCN, evtl. TNM). Hier müssen noch Vereinbarungen getroffen werden

Diagnosen: Übermittelt werden alle Diagnosen aus dem ICD-10-Kapitel: Neubildungen (C00-D48), soweit sie im jeweiligen Register zumindest für eine bestimmte Region systematisch erfasst werden. Übermittelt wird ein “Best“best-of” Datensatz. Ein Fall, der im Register separat angelegt wurde, wird als solcher an das ZfKD übermittelt werden, unabhängig von der epidemiologischen Zählweise.

Integration der epi Daten

Inhalt der epi Daten

·       Alle Fälle mit Diagnosejahr <= 2019

·       Angaben zu Diagnose, Therapie (J/N) und ggf. Tod

·       Merkmalsliste:

View file
nameFormat_f_Datenlieferung_nach_BKRG_2011.xls

Mögliche Varianten der Übermittlung

Variante 1: Lieferung nach altem Epi-Format

Alle Daten nach neuem Schema (vor DJ 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). Dies wäre die komfortabelste Lösung für das ZfKD

Vorteile

  • Für bisherige Epi-Register ohne Zusatzaufwand machbar

Nachteile

  • Für GKR-Länder neu zu implementierendes Exportformat

  • Zwei separate und nicht zu verknüpfende Datenbestände beim ZfKD

Variante 2: Lieferung nach neuem ZfKD-XML-Schema

Vorteile

  • Nur ein Exportformat

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

Nachteile

  • Therapieangaben mit Ausprägungen J/N im XML-Schema nicht vorgesehen. Da vermutlich in einigen Epi-Registern die Therapieangaben nicht genauer vorliegen und somit nicht ersatzweise z.B. das Datum eingetragen werden kann, müssten solche Felder noch ergänzt werden.

  • Manche Ausprägungen der Epi-Daten entsprechen nicht dem Basisdatensatz (z.B. Diagnosesicherung DCO).

Variante 3: Jedes Register liefert entweder altes Epi-Format oder Daten im neuen Schema

Vorteile

  • Kein Zusatzaufwand für alle Register, GKR-Länder dürften über detaillierte Therapieangaben auch für Altfälle verfügen und damit das neue Schema gut füllen können.

Nachteile

  • Erstellung eines Konverters EPI -> ZfKD-XML notwendig.

  • Therapieangaben liegen im ZfKD in unterschiedlicher Qualität vor (Reduzierung auf J/N notwendig?).

  • Datenbestände in unterschiedlichen Varianten beim ZfKD

Für die Datenlieferung gilt der Wohnortbezug, d.h. es werden Daten für Fälle übermittelt, bei denen der Wohnort des Patienten/der Patientin zum Zeitpunkt der Erstdiagnose  im Einzugsgebiet des jeweiligen Registers lag.

Übermittlung der epi Daten zum RKI

  • die Festlegungen zur Übermittlung sind hier dargelegt

Personen-ID

  • jeder Teildatensatz zu einer Person (Element https://plattform65c.atlassian.net/wiki/spaces/P6/pages/2097195/Patient#%C3%9Cberblick ) erhält in jeder Lieferung eine pro Register eindeutige Kennung (Personen-ID)

  • diese ID wird an das RKI als Pseudonym versandt

  • die Harmonisierung zu bundesweit eindeutigen Personen-ID im Gesamtdatensatz nimmt das ZfKD RKI vor

  • die Personen-ID Pseudonyme werden in jeder jährlichen Lieferung von den Registern neu generiert (unabhängig von der letzten Jahreslieferung) und lassen keinen Bezug auf die Person zu über das Lieferjahr hinaus

  • es wird jedes Jahr der Gesamtbestand übermittelt. Damit sind alle Ergänzungen und Korrekturen automatisch inbegriffen und es erspart den Registern und dem RKI ein aufwändiges Korrekturmanagment

Wohnort / Behandlungsort

Zuordnung Wohnort

...

Festlegung: Wohnort zum Zeitpunkt der Primärdiagnose wird auf Tumorebene erfasst

...

(Variable Inzidenzort)

Eine wünschenswerte Erfassung und korrekte Zuordnung von mehreren Tumoren zur gleichen Person, wenn diese (nach Umzug der Person) in verschiedenen Bundesländern als Fälle aufgetreten sind, kann mit der neuen Datenübermittlung (ohne Kontrollnummern) nicht gelingen. Es erscheint noch offen, ob dies langfristig über den RD gewährleistet werden kann.

ICD Versionen sind optional

  • ICD Versionen sind im Schema umgesetzt als https://plattform65c.atlassian.net/wiki/spaces/P6/pages/2228479

  • entgegen der Festlegung im oBDS 3.0.0 sind durchgängig alle Elemente zur Version von ICD Kodierungen optional

  • Hintergrund ist, dass die Übermittlung von Kodierungen bei unbekannter Versionsangabe ermöglicht werden soll

  • die Elementtypen zu den jeweiligen Versionsangaben (ICD, Morphologie, Topographie) enthalten die Ausprägung Unbekannt nicht

  • somit entsprechen die Werteausprägungen denen in oBDS

Datumsbasierte Angaben

Angaben mit Datum

...

  • auch wenn Datumsangaben überwiegend geschätzt/gerundet übermittelt werden mussmüssen, soll der Abstand zwischen Ereignissen tagesgenau verfügbar sein

  • eine Dauer in Tagen soll nur berechnet werden, wenn die beiden relevanten Datumsangaben im Register tagesgenau vorliegen

  • wenn das zweite Ereignis (Ende der Therapie, Tod) noch nicht eingetreten ist, wird keine Dauer berechnet (also auch keine Dauer bis Ende des Follow-ups bei dann noch lebenden Personen)

  • eine genaue Rekonstruktion einzelner geschützter Angaben (z.B. Sterbedatum) ist somit ausgeschlossen, da zu keinem keiner tagesgenauen Datumsdifferenz ein angrenzendes präzises Datum übermittelt wird

  • zur Realisierung aller möglichen Ausprägungen für Dauer eines Ereignisses und Abstand zwischen Ereignisse ist der JNU_Typ aus oBDS übernommen und kann hier wie folgt interpretiert werden https://plattform65c.atlassian.net/wiki/spaces/P6/pages/2818349

    • J: Ja, Gültiger Wert ist enthalten: Anzahl Tage > 0

    • N: Nein, nicht anwendbar; etwa wenn Ereignis noch nicht beendet (z.B. Therapie dauert an)

    • U: Unbekannt

...

  • der Wert für den Tagesabstand muss >0 sein, die Angabe selbst ist optional

Konventionen zu fehlenden Werten

  • der Umgang mit fehlenden Werten ist offenbar nicht durchgängig gelöst im oBDS, und somit auch nicht im ZfKDin oBDS-LieferdatensatzRKI

  • generell soll erreicht werden, dass fehlende / unbekannte Werte kodiert werde können (ausgenommen “essentielle Kernvariablen”)

Fehlende Werte nicht umsetzen auf U oder X

Darauf gibt es bislang noch keine klare Antwort. Vorrangig wurden die Elemente aus oBDS 2021 verwendet um bekannte Prinzipien möglichst weiter zu nutzen.

Für verschachtelte Elemente sehe ich bislang keine andere Lösung. Fehlt bspw. das optionale Element <Tod> gehen wir davon aus, dass die Person nicht verstorben ist.

...

  • , allerdings ist der Unterschied zwischen “kein Wert verfügbar” und “Wert verfügbar, aber unbekannt” nicht durchgängig abbildbar

  • dieser Kontextgewinn könnte theoretisch im oBDS-RKI durch Änderungen im Aufbau der Schemaelemente erreicht werden (durch zusätzliche Ausprägungen wie Unbekannt), dann weichen die Schemakonzepte aber immer weiter voneinander ab und die Elemente sind nicht mehr ohne weiteres kompatibel

  • ebenfalls soll vermieden werden, dass einzelne fehlende Werte bei Pflichtangaben dazu führen, dass das komplette Element dann nicht mehr valide ist

  • daher wird im Zweifelsfall das Element als optional deklariert

Pflichtfelder

  • sind in erster Näherung von der meldebasierten Übermittlung in oBDS 2021 übernommeninzwischen im oBDS 3.0.0 übernommen

  • während der Entwicklung des Schemas ist deutlich geworden, dass die fallbasierte Übermittlung mehr Freiheiten für die optionale Angabe von Werten erfordert

  • viele Pflichtfelder aus oBDS 3.0.0 wurden so bereits zu optionalen Feldern

  • die Vermutung besteht, das Pflichtfelder bis auf die “essentiellen Kernvariablen” aufgelöst werden sollten, um die Übermittlung der Elemente nicht zu blockieren

Wertebereiche

  • Wertebereiche sind auf zwei Arten im Schema kodiert:

    • erlaubte Ausprägungen sind direkt im Element aufgeführt (als Enumerations)

    • via regex-patterns in einem Element ermöglichen die Validierung von dort abgelegten Werten

  • Verweise auf externe Kataloge (z.B. DIMDI) sind nicht verarbeitet

  • in einigen Elementen sind “fallback optionen” eingebaut, um alternative, weniger strukturierte Übermittlungen als Freitext zu ermöglichen (Bsp. Substanz/Protokolle bei https://plattform65c.atlassian.net/wiki/spaces/P6/pages/2654511 )

Priorisierung von Variablen

  • P1 - epi Daten / hard check

  • P2 - epi Daten Rest

  • P3

Lieferregister

  • im Schema sind alle Lieferregister gemäß der Systematik bei den epi Lieferungen aufgeführt (01 - 16)

  • zusätzlich aufgenommen wurde das die gemeinsam liefernde Institution Berlin + Brandenburg als item 17

...

Überleitung oBDS 2014

...

zu 2021

  • derzeit besteht eine Übergangsphase zwischen oBDS 2014 und oBDS 2021 (Implementierung noch nicht abgeschlossen)

  • Annahme: zum Zeitpunkt der Inbetriebnahme des ZfKDoBDS-Lieferdatensatzes RKI ist gemäß Planung oBDS 2021 (mindestens v 3.0.0) verpflichtend für den Austausch der Länder

  • das Schema berücksichtigt daher ausschließlich den neuen Standard oBDS 2021 (Stand Ende 2022-Q1)analog dem oBDS sind im Schema für Applikationsarten beim Zielgebiet (https://plattform65c.atlassian.net/wiki/spaces/P6/pages/2621565) sowohl die Version 2014 als auch 2021 definiert3.0.0 und höher

  • im Rahmen des Registerübergreifenden Datenaustausches werden in aller Regel aktuelle Meldungen ausgetauscht, somit stellt sich das Problem der Überleitung zwischen den oBDS Versionen hier nur in Randfällen dar (z.B. bei Korrekturnachrichten zu alten Meldungen)

  • an das RKI wird hingegen der komplette Datenbestand übermittelt, somit müssen alle Altfälle in das gültige Schema “passen”