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 17 Nächste Version anzeigen »

Welche Daten werden geliefert

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.

Diagnosen: Übermittelt werden alle Diagnosen aus dem ICD-10-Kapitel: Neubildungen (C00-D48), soweit sie im jeweiligen Register systematisch erfasst werden. Übermittelt wird ein “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:

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

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

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

  • die Personen-ID werden in jeder jährlichen Lieferung von den Registern neu generiert und lassen keinen Bezug auf die Person zu über das Lieferjahr hinaus

Wohnort / Behandlungsort

Zuordnung Wohnort

Bisher wird der Wohnort einer Person zugeordnet, nach Umzug und anschließender neuer Tumorerkrankung würden allerdings Fehler entstehen

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

Fragen von Ben Barnes:
Datenübermittlung nach dem Wohnortsprinzip bei Umzügen:
§5 BKRG "(1) Die Krebsregister übermitteln jährlich an das Zentrum für Krebsregisterdaten zur Erfüllung seiner Aufgaben nach § 2 zu allen bis zum Ende eines Kalenderjahres erfassten Erkrankungsfällen von Personen, die ihren Wohnort in dem Erfassungsgebiet des Krebsregisters haben, folgende Daten:"
Frage : Welcher Zeitpunkt gilt nach Umzug für die Bestimmung des Wohnortes einer Person für die Zuteilung der Person zum Erfassungsgebiet eines Registers?
Wohnort zum Zeitpunkt der Datenlieferung (31.12. eines Jahres) ← wegen benötigter Aktualität eher problematisch
Wohnort zum Ende des Kalenderjahres , auf das sich die Lieferung bezieht (31.12. des Vorjahres) ← machbar: das neue Krebsregister muss den Fall melden und das alte Krebsregister darf den Fall nicht mehr melden
Wohnort zum Zeitpunkt der Diagnose ← eventuell machbar, solange der RÜD funktioniert und das alte Register Therapie-, Verlaufs- und Sterbeinfos erhält und ans ZfKD weitergibt. Des Weiteren muss sichergestellt werden, dass mehrere Krebsdiagnosen, die in unterschiedlichen Erfassungsgebieten gestellt wurden, registerübergreifend zu einer Person zusammengefasst werden können (s. §5 BKRG Abs. 1 Nr. 1 d).
In jedem Fall, auch um unterschiedliche Wohnorte bei Umzügen innerhalb eines Erfassungsgebiets nachzuvollziehen, muss der Wohnort zum Diagnosezeitpunkt als Eigenschaft eines Falles und nicht einer Person im Datensatz-Schema für das ZfKD berücksichtigt werden, obwohl im Gesetz der Wohnort unter den "Angaben zur Person" steht. Als Angabe mit Bezug zur Tumordiagnose wird sichergestellt, dass bei Umzügen der Wohnort "zum Zeitpunkt der Erstdiagnose" nachvollziehbar bleibt.

Datumsbasierte Angaben

Angaben mit Datum

Angaben mit einer Anzahl Tagen zwischen Ereignissen

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

  • eine genaue Rekonstruktion einzelner geschützter Angaben (z.B. Sterbedatum) ist ausgeschlossen, da zu keinem 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

Alternativvorschlag: Die entsprechenden Angaben („Dauer in Tagen“) bleiben letztlich optional, die Register sollten diese in der Regel jedoch berechnen bzw. angeben können, fehlende Angaben sollten also die Ausnahme sein.


Konventionen zu fehlenden Werten

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

  • 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.

Bei Variablen wie etwa den Angaben zu Abstand / Dauer in Tagen haben wir bereits vorgeschlagen, fehlende Werte zu kodieren, da sich hier ein Kontextgewinn darstellt Sicher liesse sich das Prinzip auch auf andere Datenfelder ausweiten, damit steigt allerdings die Komplexität des Datensatzes (es muss z.B. ein neuer Datentyp erfunden werden um sowohl ein Datum als auch "N" oder "U" zu speichern). Hier halte ich Absprachen für wertvoll in wie weit wir formalisieren wollen.

Pflichtfelder

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

  • inzwischen ist deutlich geworden, dass die fallbasierte Übermittlung mehr Freiheiten für die optionale Angabe von Werten erfordert

  • viele Pflichtfelder 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

    • via regex-patterns

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

  • in einigen Elementen sind “fallback optionen” eingebaut, um alternative, weniger strukturierte Übermittlungen 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

Konflikte oBDS 2014 / 2021

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

  • Annahme: zum Zeitpunkt der Inbetriebnahme des ZfKD-Lieferdatensatzes ist gemäß Planung oBDS 2021 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 definiert

  • Keine Stichwörter