Umsetzung_KFRG_GTDS

Umsetzung des KFRG im GTDS
Stand: Mittwoch, 21. Oktober 2015
Vorbemerkung zu diesem Dokument
Dieses Dokument stellt eine frühe Skizze des Umsetzungskonzeptes dar, das noch an
wesentlichen Stellen geändert werden kann. Eine Rückmeldung ist daher ausdrücklich
gewünscht.
Einleitung
Auf der Basis des Krebsfrüherkennungs- und -registergesetzes (KFRG) vom April 2013
werden derzeit auf Landesebene die gesetzlichen Grundlagen für die flächendeckende
Einrichtung von Krebsregistern geschaffen. Mit diesem Dokument soll dargestellt werden,
welche Arbeiten erforderlich sind, damit GTDS sowohl als System eines regionalen
Krebsregisters als auch einrichtungsbezogenes System für die Dokumentation in einem
Krankenhaus oder Krankenhausverbund den Anforderungen des KFRG und den "Kriterien
zur Förderung klinischer Krebsregister des GKV-Spitzenverbandes" vom 20.12.2013 gerecht
werden kann.
Aus Sicht eines klinischen regionalen / Landeskrebsregisters betrifft dies die Bereiche:

Umsetzung des ADT-GEKID-Datensatzes
veröffentlichten Form
in
der
im
Bundesgesetzblatt

Fähigkeit zur elektronischen Datenannahme und Weitergabe an andere Register
(einschließlich Melderportal und Optimierung der Verarbeitung von elektronisch
angenommenen Daten)

Verarbeitung von Leichenschauschein und Melderegisterinformation

Rückmeldung (Einzelfalldaten und Statistiken)

Abrechnung von Fallpauschalen und Meldervergütung
Aus Sicht eines einrichtungsbezogenen Systems ist betroffen

Umsetzung des ADT-GEKID-Datensatzes
veröffentlichten Form
in
der
im
Bundesgesetzblatt

Fähigkeit zur elektronischen Meldung (vergleichbar den bereits jetzt vorhandenen
Exporten an epidemiologische oder klinische Register, nur wesentlich umfangreicher)
Für das Auslesen und Einlesen wird es voraussichtlich ein bundesweit einheitliches XMLFormat geben, das es erlaubt, auch unterschiedliche Dokumentationssysteme zu verbinden.
Bezüglich der Inhalte wird die Dokumentation wesentlich fokussierter auf die ADT-GEKIDInhalte (Basisdatensatz und organspezifische Erweiterungen) erfolgen müssen, damit das Ziel,
alle Krebspatienten zu erfassen, ressourcenmäßig leistbar ist. Dabei gilt es gleichzeitig, auch
den aktuellen Anforderungen der Organkebszentren weiterhin gerecht zu werden.
In diesem Konzept werden zunächst die Pläne bezüglich der Änderung
Dokumentationsinhalte erläutert. Dazu wird auch das Import-System berücksichtigt.
der
Des Weiteren sollen die Umsetzungsrichtlinien für die Erfassungsmasken skizziert werden.
Nicht berücksichtigt sind derzeit die Felder der organspezifischen Module. Diese werden
demnächst durch entsprechende Konsensusverfahren revidiert und danach veröffentlicht.
Diese beiden Punkte betreffen alle GTDS-Anwender. Die spezifischen Punkte hinsichtlich
regionaler / Landesregister werden in späteren Fortführungen des Dokuments bzw. in anderen
Dokumenten erläutert.
Abbildung des ADT-GEKID-Datensatzes und Änderungen
des Datenmodells
Die Variablen des ADT-Datensatzes und deren Zuordnung zum Import-Modell werden in
einer separaten EXCEL-Datei dargestellt. Folgende Arten von Änderungen sind zu
unterscheiden:

Zusätzliche Felder

Änderungen der Auswahllisten bestehender Felder
Wegfallende Felder und Ausprägungen werden in dieser Datei nicht behandelt. Sofern sie
nicht für andere Zwecke benötigt werden (z.B. Zertifizierung oder eigene Erfordernisse)
sollen sie vorgabemäßig wegfallen, aber für historisch gefüllte Fälle sichtbar oder über
Konfigurationsparameter aktivierbar sein.
Der Aufbau der Tabelle ist wie folgt:

Feldbezeichnung - Ausprägungen: enthalten die Felder des ADT-GEKIDBasisdatensatzes aus den veröffentlichten Dokumenten

GTDS-Tabelle und GTDS-Spalte geben die korrespondierenden Felder des GTDS an.
Sofern neue Felder erforderlich sind, wird dies durch "neu" gekennzeichnet

IMPORT-Tabelle und IMPORT-Spalte machen das gleiche für das Import-System, in
das die Meldungen aus anderen Systemen oder dem Melderportal fließen.

In "Bemerkung Umsetzung" stehen Erläuterungen einschließlich der Änderungen an
Auswahllisten. Die meisten Felder des Import-Modells korrespondieren 1:1 mit denen
des GTDS-Kerns. Da aber ein Import-Modell den Anforderungen von Meldungen
gerecht werden muss, im GTDS-Kern jedoch die Informationen aus unterschiedlichen
Quellen zusammengeführt werden (Best-of), lässt sich das nicht immer durchhalten.
Umsetzung in Erfassungsmasken
Neue/wegfallende Felder
Sofern sich Änderungen in den Auswahllisten ergeben, werden sie in allen Erfassungsmasken
umgesetzt (Kompakt/erweitert/WebGTDS). Alle anderen Änderungen, also z.B. wegfallende
Felder, werden jedoch nur noch in den Kompaktversionen der Masken durchgeführt. D.h. die
Kompaktversionen sind der zukünftige Standard für die Erfassung. Für die systemische
Therapie wird eine neue Kompakt-Maske, bei der die Anzeige der Zyklen zugunsten der
Medikamentenerfassung wegfällt, eingerichtet. Wegfallende Felder sollen nach Möglichkeit
auch über Konfiguration darstellbar sein, ohne dafür die erweiterte Maske aufrufen zu
müssen.
Änderungen in Auswahllisten

Zukünftig müssen die "Standard Auswahllisten" (Tabelle MERKMAL) streng
beachtet werden. Mittels Skripten sollen eigene Erweiterungen gekennzeichnet
werden,
voraussichtlich
über
die
Überprüfung
auf
Gleichheit
in
MERKMAL+CODE+BESCHREIBUNG (Textkonserve und Text30 werden nicht
geprüft). In WebGTDS sind technisch bedingt bereits jetzt nur Standardausprägungen
vorgesehen.

Wegfallende Ausprägungen sollen nur noch in historischen Datensätzen dargestellt
werden. Dazu wird eine "Aktiv"-Kennzeichnung der neuen Standardcodes in den
"Standard-Auswahllisten" erfolgen.

Dies betrifft auch selbst eingeführte Codes. Diese sind von den Anwendern zu prüfen
ob sie nicht in Konflikt mit neuen Codes stehen. Beim Einfügen neuer Codes sollen
bereits bestehende nicht überschrieben werden. Sollten solche Konflikte entdeckt
werden, müssen sie unbedingt aufgelöst werden.

Wo GTDS-Ausprägungen codemäßig nicht mit denen des ADT-GEKID-Satzes
übereinstimmen (aber von der Bedeutung her identisch sind), wird die GTDSAusprägung weitergeführt. Bei Import- und Export-Vorgängen finden entsprechende
Konvertierungen statt.
Umstellungsprozeß der Auswahllisten
a) Konsolidierung
0. Änderung der Tabellenstruktur der Tabelle Merkmal (Skript al_merk.sql)
1. Eine Referenzliste von Einträgen wird mit den bestehenden Einträgen in Merkmal vor Ort
verglichen. Bei Übereinstimmung in Code und Beschreibung wird der "Status_Abgleich" auf
OK (bzw. bei Abweichungen von Code und Textkonserve OKDIFFx) gesetzt. Alle
Abweichungen in Beschreibung, Textkonserve und Text30 werden in "Bemerkung_Abgleich"
protokolliert. Bei Abweichung in Beschreibung wird "Status_Abgleich" auf BEZDIFF
gesetzt. Bei allen Einträge mit OK oder beginnend mit OK werden auch die Felder Aktiv,
Quelle, Bemerkung und ZuADTGEKID2014/ VonADTGEKID2014 sowie zentral_erstellt/geaendert eingetragen. Erstellungsdatum bekommt den Wert 31.12.2014, Erstellbenutzer
"VOR2015".
2. Die in Schritt 1 nicht geänderten Einträge werden in "Status_Abgleich" mit CODEDIFF
gekennzeichnet. "aktiv" wird nicht verändert. Es werden auch keine anderen Einträge außer
Aenderungsdatum/-benutzer vorgenommen.
3. Dokumentierte Inhalte, die nicht in der entsprechenden Auswahlliste enthalten sind, werden
in der Tabelle Merkmal mit den verwendeten Codes protokolliert und als "aktiv" = N
gekennzeichnet. Sie erhalten "Status_Abgleich" = CODEUNBEK. Beschreibung,
Textkonserve und Text30 erhalten den Text "(Code nicht verwenden)"
Es erfolgt keine Ergänzung von fehlenden Einträgen!
Einträge mit OK sind danach im Normalfall nicht mehr änderbar und unterliegen der vollen
Kontrolle der Entwickler.
Einträge mit OKDIFFx sollten kontrolliert werden. Nach Änderung auf die Standardtexte
kann das Skript erneut aufgerufen werden.
Das vorgehen bei Einträgen mit CODEDIFF sollten mit den Entwicklern abgesprochen
werden, insbesondere wenn es sich um solche aus dem ADT-GEKID-Datensatz handelt.
CODEUNBEK-Einträge bedürfen evtl. der manuellen Korrektur betroffener Datensätze.
b) Anpassung
Bei der Anpassung werden die Auswahllisten einzeln den aktuellen Erfordernissen angepasst.
Nicht vorhandene Codes werden eingefügt. Bei vorhandenen Codes werden die
Beschreibungen angepasst, sofern sie im Status OK tragen. Bei OKDIFF3 wird ggf. nur die
Textkonserve geändert, bei OKDIFFK nur Text30. Bei OK wird alles geändert.
Abweichungen werden wieder im "Bemerkung_Abgleich" vermerkt".
Hier werden vorrangig die ADT-GEKID-Datensatz-relevanten Auswahllisten betrachtet.
c) Überprüfung
Nach dem Einspielen des Updates sollte die Maske "Benutzer, Rechte" => Auswahllisten
aufgerufen werden.
Die Maske bietet über den generischen F7/F8 Mechanismus folgende Filtermöglichkeiten, um
gezielt Inhalt bearbeiten zu können.
1. Merkmale mit Codedubletten
Das hat mit der KFRG-Umstellung im engeren Sinn nichts zu tun, sondern weist auf
möglicherweise vorhanden Dubletten in Codes hin, die prinzipiell problematisch sind. Im
Idealfall werden keine solchen Inhalte angezeigt. Ansonsten wäre die entsprechende
Installation zu analysieren.
2. ADT-GEKID
Hier werden die Codes aller Merkmale angezeigt, die im Rahmen des ADT-GEKIDBasisdatensatzes relevant sind.
3. Abweichung Standard
Hier werden die Codes alle Merkmale angezeigt, bei denen eine Abweichung mindestens
eines Codes von den zentralen Einstellungen besteht. Das können minimale textliche
Abweichungen sein, die unproblematisch sind, oder inhaltliche, sowie zentral unbekannte
Codes.
4. Kombination aus 2 und 3
d) Korrektur von Abweichungen
Das Vorgehen hängt ab vom Inhalt des Felds Status Abgleich
Die ggf. vom Entwicklerteam vorgesehenen (zentralen) Standardbezeichnungen sind in
hinterlegt.
OK
keine Aktion erforderlich
BEZDIFF
Beschreibung weicht von zentraler Beschreibung ab: Prüfung, ob
textliche Abweichung bedeutungsmäßig relevant
wenn relevante Abweichung: Rücksprache mit Entwicklern
wenn nicht: Korrektur über "Standard herstellen"
OKDIFFxx
Abweichung in Textkonserve und Text30. Im Regelfall sollte hier nichts
bedeutungsmäßig abweichendes stehen, Korrektur wie in BEZDIFF über
"Standard herstellen"
CODEDIFF
Hier ist vor Ort ein Code eingetragen, der zentral nicht bekannt ist und
dementsprechend durch Anwendung oder Auswertung nicht interpretiert
kann: Rücksprache mit Entwicklern
CODEUNBEK
Hier ist vor Ort in Datensätzen ein Code eingetragen, der auch in den
Auswahllisten vor Ort nicht bekannt ist und der dementsprechend durch
Anwendung oder Auswertung nicht interpretiert kann. Es kann sich um
manuelle / historische (Fehl-)Eingaben außerhalb von Auswahllisten
handeln. Die Bedeutung ist erst intern zu eruieren. Falls eine Konversion
sinnvoll ist (z.B. eine 0 statt eines O oder umgekehrt), kann die über
SQL*Plus-Skripte vorgenommen oder manuell über die Masken bei den
betroffenen Datensätzen werden, ggf. Rücksprache mit Entwicklern.
Optische Änderungen
Die Farbgestaltung soll, soweit es sich anbietet, dezenter werden, etwa vergleichbar mit der
Übersicht über vorhandene Daten. Nicht änderbare Felder werden im Allgemeinen rahmenlos
dargestellt.