Umsetzung des KFRG im GTDS

Transkript

1 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 gerecht werden kann. Aus Sicht eines klinischen regionalen / Landeskrebsregisters betrifft dies die Bereiche: Umsetzung des ADT-GEKID-Datensatzes in der im Bundesgesetzblatt veröffentlichten Form 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 in der im Bundesgesetzblatt veröffentlichten Form 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 XML- Format geben, das es erlaubt, auch unterschiedliche Dokumentationssysteme zu verbinden. Bezüglich der Inhalte wird die Dokumentation wesentlich fokussierter auf die ADT-GEKID- Inhalte (Basisdatensatz und organspezifische Erweiterungen) erfolgen müssen, damit das Ziel,

2 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 der Dokumentationsinhalte erläutert. Dazu wird auch das Import-System berücksichtigt. 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-GEKID- Basisdatensatzes 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

3 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 GTDS- Ausprä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 , 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!

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

5 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-GEKID- Basisdatensatzes 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 BEZDIFF OKDIFFxx CODEDIFF CODEUNBEK keine Aktion erforderlich 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" Abweichung in Textkonserve und Text30. Im Regelfall sollte hier nichts bedeutungsmäßig abweichendes stehen, Korrektur wie in BEZDIFF über "Standard herstellen" 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 Hier ist vor Ort in Datensätzen ein Code eingetragen, der auch in den

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