Konzept für die Umstellung der GKR-Schnittstelle auf Version 3

Überarbeitete Fassung unter Berücksichtigung der Anmerkungen der Benutzer

Dieses Konzept beschreibt in Ergänzung zu der vom Gemeinsamen Krebsregister herausgegebenen Übersicht "GTDS-Schnittstelle altes und neues Übergabeformat" (09/99) die im GTDS erforderlichen Änderungen an Masken und am Schnittstellenprogramm. Darüber hinaus enthält es Bemerkungen zu einzelnen Problemen.

Übersicht

Wegfallende Inhalte

Änderungen

Neue Inhalte

Bemerkungen

Tumorvorerkrankungen

Die Ausschrift in den Masken wird expliziter gefaßt, um klarzustellen, daß hier keine Begleiterkrankungen dokumentiert werden sollen. Außerdem werden, soweit der Platz ausreicht, auch mehrere Vorerkrankungen berücksichtigt.

Anlaß der Behandlung

Es gab in der Vergangenheit Probleme, weil Rezidive bereits im GTDS dokumentierter Tumorerkrankungen als Neuerkrankungen eingetragen wurden. Dieses Vorgehen ist nicht zulässig und verhindert sinnvolle statistische Auswertungen.

Das GTDS-Feld TUMOR.BEHAND_ANL beschreibt, welche Ausprägung des Tumors zum Zeitpunkt der Aufnahme in das Zentrum im Vordergrund des Tumorgeschehens gestanden hat. Der Begriff lokoregionäres Rezidiv wird verwendet, wenn keine Entscheidung zwichen Primärtumorrezidiv und Lymphknotenrezidiv getroffen werden kann. Der Inhalt des Feldes ist nicht bedeutsam für die Entscheidung, ob ein Datensatz exportiert wird.

Die Inhalte dieses Feldes werden wie folgt umgesetzt.

T Primärtumor

P

P Primärtumorrezidiv

R

L Lymphknotenrezidiv

R

B lokoregionäres Rezidiv und Fernmetastasen

R

G generelle Progression des Krankheitsbildes

R

R lokoregionäres Rezidiv

R

M Fernmetastasen

M

Diagnosedatum

Die Erfahrungen zeigen, daß es problematisch ist, das Diagnosedatum nach den international üblichen Vorschriften (Datum der ersten ärztlichen Verdachtsdiagnose) zu erheben. Meistens wird hier das Datum der histologischen Diagnosestellung eingetragen. Dies kann zu Schwierigkeiten bei internationalen Vergleichen epidemiologischer Daten führen, insbesondere, wenn häufig große Verzögerungen zwischen Verdachts- und definitiver Diagnose auftreten (Inzidenzverschiebungen). Andererseits läßt sich das Problem gegenüber den Meldenden nur schwer vermitteln. Die exakteste Lösung wäre, zwei Datumsangaben einzuführen. Dies würde andererseits umfangreiche Änderungen im GTDS und insbesondere in den Druckfunktionen nach sich ziehen. Damit wenigstens im Gemeinsamen Krebsregister klar ist, welches Datum unter Diagnosedatum im jeweiligen Register gemeint ist, sollte diese Information generell für das Register an das Gemeinsame Krebsregister übermittelt werden, d.h. diese Information ist nicht Bestandteil der Schnittstelle. In den Kommentaren zum ersten Vorschlag dieses Konzeptes gab es nur vereinzelt die Anregung, diese Kennzeichnung im GTDS aufzunehmen. Das Problem ist bei künftigen Änderungen der Basisdokumentation zu berücksichtigen.

Grading

Die ursprünglich (lt. Tabarz) vorgesehene Erweiterung k = Natural-Killer-Zelltyp braucht nicht eingeführt zu werden.

Version / Auflage des Histologieschlüssels

Das Feld HISTOLOGIE.FK_HISTOLOGIE_SAUF wird folgendermaßen umgesetzt

2

T1

Tumorhistologieschlüssel 1. Auflage, 1978

3

I2

in Gießen von Praktikanten angefertigte Übersetzung der ICD-O 2 (1990), nur zeitweise im Einsatz

3G

I2

von GKR übernommene Fassung der ICD-O 2(1994)

3D

T2

Tumorhistologieschlüssel 2. Auflage, 1997 (von Buch-CD)

Art der Stadienangabe

Bei der Auslese dieses Feldes gab es in der Vergangenheit zu Probleme, wenn in KLASSIFIKATION.KUERZEL keine korrekten Inhalte (entsprechend der Basisdokumentation) vorhanden waren. Bitte vor Ort in der Maske "Klassifikationen" überprüfen.

Wenn keine Klassifikation aus dem vorgesehenen Wertevorrat vorliegt, wird das Stadium nicht exportiert.

TNM

Es werden jetzt zwei TNM-Befunde übermittelt. Das Schnittstellenprogramm liest jeweils die zeitlich ersten (TUMOR.DIAGNOSEDATUM bzw, VERLAUF.UNTERS_DATUM) TNM-Einträge zum Tumor aus und zwar getrennt nach klinisch (Kein Eintrag von "a" oder "p" bei TNM.P_T) und pathologisch (Eintrag von "p" bei TNM.P_T). Klinische Einträge werden in TNMG, pathologische in TNMB gespeichert. TNM-Klassifikationen mit einem Eintrag in R_SYMBOL werden auch berücksichtigt, dürften aber zeitlich immer hinter den anderen Einträgen liegen. Das R_SYMBOL ist Bestandteil des TNM-Feldes.

Datumsangaben für die Therapien

Der Therapiebeginn kann seit 1997 auf den entsprechenden Behandlungsbögen eingetragen. Diese Information wird hier vereinfachend genutzt, indem das Datum bei Vorliegen entsprechender Einträge in VERLAUF.OPERATION, VERLAUF.BESTRAHLUNG usw. den entsprechenden Datumsangaben der Schnittstelle zugeordnet wird. Für das jeweilige Datum wird das Feld TH_BEGINN aus VERLAUF, wenn nicht gefüllt das UNTERS_DATUM genommen. Alternativ müßte in den den Verläufen zugeordneten Detaildaten, die jedoch unter Umständen nicht immer vorhanden sind, nachgesehen werden.

Vitalstatus

Der Vitalstatus berücksichtigte bisher nur Informationen aus Diagnose,- Verlaufs- und Abschlußmeldungen. Zukünftig wird auch das Sterbedatum berücksichtigt.

Meldetyp

Der Meldetyp k für Korrekturmeldung wird manuell gesetzt falls Daten korrigiert wurden und der Datensatz erneut gemeldet werden soll. Bei "k" erfolgen keine Einträge von Vergütungsdatensätzen. Diese Datensätze werden auch in der beim Export entstehenden Logdatei gesondert ausgewiesen (Vergütung des GKR an die Register).

Unterrichtung über Meldung

Laut Gesetz muß die Information, ob der Patient über die Meldung unterrichtet wurde oder nicht, vorhanden sein. Für Altfälle kann diese Angabe aber nicht mehr eingeholt werden, so daß Folgemeldungen zu diesen Patienten weiterhin keine Einträge in diesem Feld haben werden. Die Angabe von unbekannt ist aber bei neuen Fällen (Meldetyp E, DATUM_DER_INFORMATION nach 1.1.2000) zukünftig nicht mehr zulässig und wird mit einem entsprechenden Hinweis in den Eingabemasken belegt. Das Prüfskript wird ebenfalls entsprechend abgeändert. Für den Fall, daß der Patient verstorben ist, wird v für verstorben eingetragen.

Version der Schnittstelle

Die Version der Schnittstelle (zuletzt PR_2.0) wird durch das Datum des Exportprogramms ersetzt. Dadurch kann gleichzeitig entschieden werden, bis zu welchem Datum Korrekturen von Programmfehlern berücksichtigt sind.

Sonstiges

Therapiecharakter

Abweichend von der Definition in der Schnittstellenbeschreibung (Übersicht altes und neues Format) vom 1. September 1999 sind alle in den Masken angebotenen Werte erlaubt und werden ohne Konversion exportiert. Es erfolgt eine Anpassung des Prüfprogrammes.

Notwendige Masken- und Tabellenänderungen

GKR-Eingabemaske:

GKR-Exportmaske:

 

Diagnosemasken:

Prüfprogramm:

Automatisches Erkennen von Korrekturen

Über die erforderlichen Änderungen an Schnittstelle und Masken hinaus werden Datenbanktrigger zur Verfügung gestellt, die bei bestimmten Datenbankänderungen automatisch Einträge in die GKR-Tabelle vornehmen. Solche Trigger können den Benutzer davon entlasten, daran denken zu müssen, in der GKR-Maske das Datum der Information manuell zu ändern. Da jedoch die Algorithmen zu einem bestimmten Grad unscharf sind, werden diese Trigger nicht automatisch installiert. Sie erfassen folgende Fälle:

  1. Änderung des Eintrags in KORREKTUR der Tabelle TUMOR auf "J"

  2. Änderungen in der Tumorlokalisation: Falls sich der Code der Hauptlokalisation ändert. Nebenbedingung: Der Inhalt des Schlüssels muß einen mindestens zweistelligen Eintrag enthalten.

  3. Änderungen in der Tumorhistologie: Änderung des Histologiecodes einer Histologie, die im Feld DIAGNOSE ein "J" eingetragen hat oder Änderung des Eintrags in DIAGNOSE auf "J". Nebenbedingung: Der Inhalt des Schlüssels muß einen fünfstelligen Eintrag enthalten.

  4. Änderungen im TNM: Hinzufügen eines neuen TNM, das keinen Eintrag im R_SYMBOL enthält. Bedingung: Der Inhalt des Feldes T (T-Kategorie) darf nicht leer und muß verschieden von "X" sein.

  5. Eintrag einer neuen Primärtherapie, d.h eines Verlaufs der im Feld TH_ZIEL_PRIMAERTUMOR ein "J" enthält (oder Änderung eines Eintrags auf "J").

Der Eintrag eines Sterbedatums wird nicht berücksichtigt, da sonst bei Import von Totenscheindaten Meldungen produziert würden, die im GKR schon bekannt sind. Außerdem wird der Tod innerhalb des Meldezeitraums sowieso schon vom Exportauswahl-Algorithmus erfaßt.

Durch die Trigger wird in der Tabelle GKR das DATUM_DER_INFORMATION auf das aktuelle Datum gesetzt. Dabei muß jedoch sicher gestellt sein, daß der Datensatz tatsächlich bereits exportiert wurde. Dies wird angenommen, wenn das bestehende DATUM_DER_INFORMATION kleiner oder gleich dem größten Eintrag in BIS in der Tabelle GKR_EXPORT ist. Da hierin auch Einträge von Probeexporten enthalten sein können, wird die Tabelle GKR_EXPORT um das Feld GUELTIG VARCHAR(1) erweitert und nur solche Einträge berücksichtigt, die dort den Eintrag "J" enthalten. Dieser Eintrag muß manuell in der GKR-Export-Maske gesetzt werden. Ist das DATUM_DER_INFORMATION größer als dieser Eintrag, erfolgt keine Änderung (auch nicht eine der im folgenden beschriebenen).

Im Falle von Änderungen ein Eintrag von "e" in MTYP in den ersten drei Fällen auf "k" (Korrekturmeldung), sonst auf "f" (Folgemeldung) gesetzt. Das verhindert, daß der Datensatz erneut vergütet wird. Andere Einträge werden nicht überschrieben, da sie durch Benutzerinteraktion oder vorherige automatische Einträge zustande gekommen sein können und (außer "t") nicht vergütungsrelevant sind.

Falls im Feld GKR_MITTEILUNG noch Platz vorhanden ist (maximale Länge 254 Zeichen), werden dort außerdem die Änderungen in komprimierter Form durch Anhängen an den bestehenden Inhalt protokolliert, z.B. LOK0400 für Änderung der Lokalisation im April 2000.

Betroffene Dateien / Module

Umstellung der Datenbank

alphanumerisches GTDS

graphisches GTDS