Stand: 26. Juli 2007
Für die Berechnung von Überlebenszeiten ist die kontinuierliche Überwachung des Vitalstatus der Patienten eines klinischen Registers erforderlich, da nicht gewartet werden kann, bis evtl. eine Todesmeldung über Leichenschauscheine im Register eintrifft.
Für diese Überwachung bietet sich eine regelmäßige Anfrage bei Einwohnermeldeämtern an. Diese kann bei wenigen Fällen brieflich erfolgen (Meldeamtsabfrage in den Leitstellenfunktionen) oder, sofern möglich, elektronisch. Letzteres Verfahren ist besonders bei größeren Mengen abzufragender Datensätze zu empfehlen. Diese sind entweder in großen Städten oder bei Zusammenschluß mehrerer Gemeinden in Rechenzentren aussichtsreich.
Leider sind die elektronischen Verfahren bundesweit nicht einheitlich, sowohl was das Format der Datensätze betrifft als auch die potentiell zu ermittelnden Informationen. Daher existieren im GTDS mittlerweile mehrere Verfahren, die aber soweit wie möglich einheitlich gehandhabt werden. Diese Verfahren sind (Stand 25. Juli 2007)
Eine Anfrage setzt sich grundsätzlich aus folgenden Schritten zusammen
Schritt 1 ist nicht unbedingt erforderlich, aber sinnvoll, da er die Verarbeitung durch die Mit-Übermittlung interner Verarbeitungsmerkmale (z.B. Pat_ID) die Verarbeitung der Rückmeldung erleichtert.
Im Falle Vital-BW wird die Anfrage vollständig in der Maske Vital-BW erzeugt. Bei den anderen werden die abzufragenden Patienten zunächst in der Auswertungsmaske ausgewählt und dann über die Anwahl des entsprechenden Moduls (AKDB-Anfrage, EMA-N-Anfrage, MESO-Anfrage, EWW-Anfrage) in die Anfragemaske übertragen. Dazu muß natürlich das entsprechende "dynamische Modul" (akdb_aus_patids, ema_n_aus_patids, meso_aus_patids, eww_aus_patids) eingelesen und aktiviert sein. Das Erzeugen der Anfragedatei mit ggf. Ergänzung von Anfrageinformationen erfolgt dann in der Anfragemaske.
Sofern die Anfrage mit GTDS erstellt wurde, ist der entsprechende Rückmeldesatz bereits nicht gefüllt vorhanden. Ansonsten muß er mit der Taste "neuer Datensatz" (F6) erzeugt werden. Hierbei muß vor allen das "R-Datum" als Datum des Abgleichs eingetragen werden, da dies später zum Teil das Datum des "Patient lebt"-Verlaufs wird. Außerdem muß das korrekte Verfahren eingestellt werden. Danach muß nur noch das Einleseverzeichnis und der Name der einzulesenden Datei eingegeben werden. GTDS verzweigt nach Eingabe von "Daten einlesen" ein oder zwei Mal in die Import-Maske (zwei Mal, falls der Rückmeldesatz Verwaltungsinformationen enthält). In der Importmaske muß nur "Starten" betätigt werden. Dabei wird - bei korrekter Konfiguration (GTDS-Parameter GLOBAL.JDBC_DATENBANK)- ein Java-Programm zum Einlesen der Daten gestartet. Es empfiehlt sich die Kontrolle der Logdatei und Fehlerdatei, um etwaige Probleme mit der Verarbeitung zu erkennen. Danach wird die Import-Maske wieder verlassen.
Die Verarbeitungsmaske zeigt jetzt die eingelesenen Datensätze in "Doppelzeilen" an. Der obere Teil der Doppelzeile enthält die Anfragedaten, der untere die Antwortdaten. Bedingt durch die unterschiedlichen Formate dr Schnittstellen sind einige Felder leer. Die Knöpfe zeigen die möglichen Aktionen.
Voraussetzung ist immer, daß bei den GTDS Statusangaben der Identifikationsstatus für den entsprechenden Datensatz bestätigt wurde. Damit dies nicht Datensatz für Datensatz gemacht werden muß, können über "Status umsetzen" zunächst unproblematische Fälle (Vornamen gleich) gefiltert werden und dann über einen zweiten Aufruf von "Status umsetzen" der Status "OK" für alle angezeigten Datensätze umgesetzt werden. Danach können die verbleibenden fraglichen Datensätze mit Vornamen ungleich von Hand kontrolliert werden. Da große Mengen von Datensätzen unübersichtlich sind und evtl. nicht in einem Zug bearbeitet werden können, empfiehlt es sich mit den Filteroptionen ein wenig zu spielen, um die passende Arbeitsweise herauszufinden.
Zum Beispiel beim "EWW"-Verfahren gibt es mehrere Möglichkeiten, die Pat-ID bei der (manuell) erstellten Abfrage einzutragen. Dementsprechend muß auch das Einleseskript lade_ewwctl.xml angepaßt werden.
<column> <name>Pat_Id</name> <index>1</index> </column>
<column> <name>Pat_Id</name> <index>2</index> </column>
<!--column> <name>Pat_Id</name> <index>1</index> </column-->
Falls die Datei nicht geändert werden kann, weil sie auf einem zentralen, schreibgeschützten Laufwerk liegt, kann sie in ein lokales Verzeichnis kopiert und dort geändert werden. Dann muß natürlich das Skriptverzeichnis beim Import auf dieses Verzeichnis geändert werden.
Enthielt der Anfragesatz keine GTDS-Ordnungskriterien (PAT-ID), so muß vor einer Verarbeitung ein Patientenmatch durchgeführt werden, damit das PAT-ID-Feld gefüllt wird. Dazu wird zunächst das SQL*Plus Skript eww_nachbearbeiten1.sql ausgeführt. Danach wird der neue Eintrag in Patienten-Match-Maske aufgesucht und das Matchen durchgeführt. Ist die Pat-ID dann bei allen Patienten eingetragen, wird sie mit eiunem zweiten SQL*Plus-Skript eww_nachbearbeiten2.sql in den Anfragesatz rückübertragen.
GTDS.INI-Parameter (Beispiele)
vitalbwimp_pfad c:\gtds\ema_akdb mesoimp_pfad c:\gtds\ema_akdb akdbimp_pfad c:\gtds\ema_akdb ema_nimp_pfad c:\gtds\ema_akdb ewwimp_pfad c:\gtds\ema_akdb
Bei einigen Verfahren (EWW, MESO) wird zwar eine neue Adresse außerhalb des jeweiligen Einzugsbereiches mitgeteilt, aber kein Wegzugdatum. Solche Fälle werden bei über einen Einzugsbereich geprüft und vom Eintrag von Verläufen ausgeschlossen, da das Wegzugdatum notwendige Voraussetzung für den Eintrag einer "lebt"-Information ist. Der Einzugsbereich wird beim MESO-Verfahren über den GTDS-Parameter EINZUGSBEREICH_ID bestimmt; beim EWW-Verfahren ist es der Einzugsbereich mit der Bezeichnung LAND_11_KGS_BRD (11=Berlin). Das Setzen des Parameters bzw. das Prüfen des Vorhandenseins des Einzugsbereichs ist daher notwendige Voraussetzung vor der Verarbeitung.