Versionen im Vergleich

Alte Version 38

changes.mady.by.user MeisegeierS (Unlicensed)

Gespeichert am

verglichen mit

Neue Version 39

changes.mady.by.user Kraywinkelk (Unlicensed)

Gespeichert am

Schlüssel

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

...

Hinweis: Zur besseren Orientierung ist die Struktur auf dieser Seite dem xml Schema nachempfunden

Patienten-Stammdaten

Vitalstatus (aktualisiert am 30.8.22)

Es wurde das neu geschaffene Element Vitalstatus eingefügt. Das Element ist ein Pflichtfeld, bei der Übermittlung kann das Element aus einem der drei folgenden Unterelemente bestehen. Jedes Element enthält eine Datumsangabe (mit verschiedenen, jeweils zulässigen Genauigkeiten), welches im Kontext eindeutig interpretierbar ist. Genau eines der drei folgenden Unterelemente muss übermittelt werden:

Element Lebend

  • Datum_follow_up

  • Diese Datumsangabe entspricht dem Datum des letzten Mortalitätsabgleichs, dieses wird tagesgenau übermittelt (in der Regel zum Monats- oder Jahresende).

Element Verstorben

  • Angabe Datum_verstorben (Sterbedatum, monatsgenau)

  • optional: Angabe eines Grundleidens (etwa der amtliche Todesursache, aus Todesbescheinigung oder Abgleich mit dem statistischen Landesamt)

  • optional: Weitere Todesursachen https://plattform65c.atlassian.net/wiki/spaces/P6/pages/2228431 (aus anderen Quellen, mit Mehrfachangaben )

Element Lost-to-follow-up

  • Angabe Datum_Wegzug, dieses wird tagesgenau übermittelt.

Erläuterung: Hier besteht neben der Übermittlung des Sterbedatums die Möglichkeit, für die Zensierung von Überlebenszeiten relevante Informationen zu übermitteln. Es ist derzeit noch davon auszugehen, dass der Verlauf und das Überleben nach Umzügen zwischen Bundesländern (über den RÜD) nicht sicher erfasst wird (vor allem wenn nach Umzug keine Behandlung mehr erfolgt).

Beispiel 1: Pat. A zieht am 15.03.2021 aus dem Registergebiet weg:

Element Lost-to Follow-up: 15/03/2021, Anzahl Tage Erstdiagnose bis Tod: leer

Beispiel 2:  Bei Datenstand Ende 2021 (Datenlieferung bis Ende 2022) ist der Abgleich mit Melderegistern für alle (oder einen Teil der) Patienten nur bis zum Stichtag 31.10.2021 erfolgt. Pat. B war zu diesem Zeitpunkt nicht verstorben oder weggezogen

Element ‘Lebend’: 31/10/2021, Anzahl Tage Erstdiagnose bis Tod: leer. Anmerkung: da ein Mortalitätsabgleich in der Regel zum Monatsende erfolgt, erscheint eine tagesgenaue Angabe sinnvoll, da sonst für Auswertungen evtl. die Monatsmitte imputiert wird. Da es sich um eine registerinterne Information handelt, sollte kein Datenschutzproblem bestehen.

Beispiel 3: Pat. C (Erstdiagnose 18.05.2020) ist am 17.06.2020 verstorben

Element ‘verstorben’: 06/2020, Anzahl Tage Erstdiagnose bis Tod: 30

...

es erlaubt keine missings: Die Person ist zu einem angegebenem Datum entweder verstorben oder lebend. Das dazugehörige Datumselement gibt an, aus welches (letzte verfügbare) Datum sich der Vitalstatus bezieht. In der Praxis speist sich das Datum aus drei Angaben: Bei verstorbenem Personen wird das Sterbedatum angegeben, bei außerhalb des Registereinzugsgebiets verzogenen Personen wird das Wegszugsdatum angeben (und der Vitalstatus auf lebend gesetzt). In allen anderen Fällen wird das Datum des letzten Mortalitätsabgleichs angeben. Dies gilt ausdrücklich auch, wenn nach diesem Abgleich zu dieser Person noch eine Meldung im Register eingegangen ist, da es sonst bei Überlebenszeitanalysen zu systematischen Verzerrungen kommen kann. Da das Sterbedatum nur monatsgenau übermittelt werden darf, wird das das zum Vitalstatus gehörige Datumsfeld insgesamt nur monatsgenau übermittelt.

Todesursachen

  • Da Meldungen zu Todesursachen aus verschiedenen Quellen kommen und derzeit in einigen Registern nicht immer entschieden werden kann, welche der Angaben der 'amtlichen Todesursache entspricht, sind hier zwei Datenfelder konfiguriert worden:

  • Eines für die amtliche Todesursache (Grundleiden): entweder vom statistischen Landesamt übermittelt oder lt. Todesbescheinigung, wenn diese in Kopie oder elektronisch im Register vorliegt.

  • Ein weiteres Feld ist konfiguriert für alle weiteren, im Register vorliegenden Todesursachen (Mehrfachangaben möglich). Wenn nicht klar ist, ob eine im Register vorliegende Todesursache der amtlichen entspricht, können entsprechende Angaben (z.B. aus klinischen Meldungen) hier übermittelt werden.

  • Für Auswertungen ist jedoch primär die amtliche Todesursache (Grundleiden) vorgesehen.

...

Erläuterung: Für Fälle mit Diagnosesicherung=0 (DCO) ist hier die Ausprägung: 0 (kein DCN) unplausibel

Alle anderen Kombinationen von Diagnosesicherung/DCO sind möglich. Erfolgreich nachrecherchierte (DCN-) Fälle sind durch DCN=1 und Diagnosesicherung≠0 gekennzeichnet.

DCN=1 und Diagnosesicherung=unbekannt bedeutet, dass weitere relevante Informationen über eine Meldung erhoben werden konnten (z.B. Diagnosedatum, Bestätigung der Diagnose), aber z.B. unklar bleibt, ob die Diagnose histologisch gesichert wurde. 

Wenn die Nachrecherche zum Zeitpunkt der Datenlieferung noch nicht abgeschlossen ist, ist DCN=1 und Diagnosesicherung=0 anzugeben (DCO-Fall zum Zeitpunkt der Übermittlung)

  • Alternative: Informationen zu DCN und DCO werden in einem Datenfeld verknüpft (DCN, DCO, weder DCN noch DCO). Ein erfolgreich nachrecherchierter Fall wird somit mit DCN gekennzeichnet. Die Ausprägung 0 (DCO) bei der Diagnosesicherung würde entfallen, bei DCO-Fällen wäre die Diagnosesicherung auf „unbekannt“ zu setzenDie im Register gängige Unterscheidung zwischen DCI (erfolgreich nachrechierte DCI-Fälle) und DCN ist für Auswertungen in aller Regel weniger relevant, daher wurde auf eine eigene Ausprägung “DCI” verzichtet, zumal sie im Gesetz auch nicht vorgesehen ist. Auch lässt sie sich im Zweifel über die Variable Diagnosesicherung nachvollziehen: DCI-Fälle sind DCN-Fälle, bei denen die Diagnosesicherung nicht DCO ist. Das bedeutet allerdings, dass Informationen auf der Todesbescheinigung, die Rückschlüsse auf eine Diagnosesicherung zulassen (“histologisch gesichertes Adenokarzinom”) bei DCO-Fällen im Lieferdatensatz nicht berücksichtigt werden können.

Diagnosesicherung

  • Zu verstehen als höchste im Register bekannte Diagnosesicherheit (Best-of)

  • Es werden die Ausprägungen des oBDS übernommen (1,2,4,6,7). Zusätzlich wird die Ausprägung „0“ für DCO-Fälle vergeben. Die Im Gesetz vorgesehene Information „durch Obduktion“ ist über den oBDS nicht abbildbar (gehört zu 2: klinische Diagnostik). Die Ausprägung „unbekannt“ ist erlaubt.

...

  • Verwendete Variablen

    • Gleason-Score 

    • Anlass GS: (Stanze oder OP oder unbekannt) 

    • PSA-Wert

  • Der Gleason-Score sollte dem Grading entsprechen, der Befund aus der Biopsie ist dem OP-Befund vorzuziehen (?).

  • PSA-Wert: Es soll ein einzelner prätherapeutischer PSA-Wert übermittelt werden, liegen im Register mehrere vor, ist der letzte Wert vor Beginn einer Therapie (bzw. dem OP-Datum) anzugeben

  • PSA-Wert: nur eine Angabe ohne Datumsangabe (Best-of Regeln existieren noch nicht, Vorschlag: höchster Wert, wenn präoperativ und innerhalb von 92 Tagen (?) Abstand zur Diagnose (oder chronologisch erster Wert?)

...