Als Schnittstelle haben wir auf die bewährte Form des ASCII-Formates zurückgegriffen, da das eben ein Format ist, was viele Datenbanken ein- und ausgeben können; Die GKR-Exportschnittstelle funktioniert ja schon seit Jahren auf diese Weise. Schon deshalb haben wir die Form der GKR2-Schnittstelle bzgl. der personenidentifizierenden Daten übernommen. Die Auswahl der Felder folgte aber im wesentlichen den Erfordernissen der Datensicherheit beim GKR in Berlin (Trennung in Register- und Vertrauensstelle, Abgleich über Schlüssel, sogenannte Kontrollnummern)

Siehe 1.2 Zeilen der Tabelle von Lfdnr. 1 bis 14

Die notwendigen Programme liegen als tgz-Archiv vor und sind über Gießen beziehbar. Der Systemübersicht wegen, bietet es sich an, für diese Paket ein eigenes Verzeichnis zu definieren, welches sich günstigerweise in dem Schnittstellenverzeichnis auf dem Datenbankserver befinden sollte.

In Cottbus ist das daher: $home/tusys/GKRANFRAGE.

Vorausetzungen:

Alsdann braucht das Archiv nur noch ausgepackt werden. Diese 3 Teilschritte sind mit einem eigentlichen Installationsprogramm in der Zukunft sicher lösbar.

Auf dem PC muß man dann nur noch eine Stelle ausfindig machen, wo der Datentransfer an das GKR stattfindet. Dazu verwendet das GKR das Packprogramm bzip2.exe (ein freies, sehr effektives Packprogramm, wofür es auch für alle möglichen UX’e binaries gibt) und das Chiffrierprogramm GKRCHIFF.EXE. Dieses Chiffrierprogramm verwendet einen externen Schlüssel, der nur telefonisch beim GKR zu erfragen ist. (siehe auch Rundschreiben des GKR zur Information über die Totenscheinschnittstelle)

Das primäre Exportfile wird analog des Verfahrens des ZTDB-Exportes erstellt:

oder

Die Laufzeit des Programms kann bei ungünstiger (älterer) Hardwarebasis erheblich sein, sodaß sich, wie wir das vom GKREXPORT oder ZTDB-EXPORT gewohnt sind, eine Verlagerung auf verkehrsarme Zeiten (in Cottbus nutzen wir Feiertage bzw. das Wochenende) sicher empfiehlt.

Diese Programme basieren auf einem SQL-Skript, was nur die Patienten in die GKRANFRAGE-Schnittstelle schreibt, die:

1. noch nicht erfolgreich mit dem GKR abgeglichen wurden; Das heißt ein Patient, über den bereits Informationen in einem früheren Totenscheinabgleich im Register vom GKR gelandet sind, werden nicht ein zweites Mal nach Berlin geschickt

2. Patienten, die nicht sicher im GKR-Register identifiziert werden konnten.

Diese Datensätze sind in der Tabelle GKRANFRAGE gekennzeichnet mit:

• Feld FEHLERKENNZEICHEN=T (nicht eindeutig true)
• Feld BEARBEITUNGSSTATUS=v (=verworfen)
  

Anschließend entsteht eine Datei gkranfrage.dat bzw. cb93anfrage.dat usw., die dann günstigerweise mit cat zusammengefügt werden. Das GKR erwartet, egal wie man das macht, eine ASCII-Exportdatei.

Nach dem Vorbild der Exportprogramme ztdbjahr.bat und ZTDBqjahr.bat kann das Exportprogramm gkrjahr.bat auch genutzt werden, welches nur parametrisiert werden muß und anschließend das bzip2-comprimierte File gkranfrage.dat.bz2 ausgibt. Dieses ist dann wiederum Cron-Prozeß-fähig.

Diese Exportdatei wird nun auf den PC per FTP transferiert und dort für die Versendung mit dem Programm GKRCHIFF.EXE vorbereitet.

Damit ist alles wesentliche erledigt, die Datei braucht nur noch auf einen Datenträger gespielt und der Post gegeben zu werden.

Benötigt werden hierfür:

• Die Tabelle GKRANFRAGE (die während der Installation created wurde)
• Die 3 Dateien gkrimport* (enthalten im gkranfrage-Archiv)

Der Benutzer muß zunächst seine Datei auf dem PC mit GKRCHIFF.exe dechiffrieren und anschließend mit bzip2.exe gleich auf dem PC decomprimieren. Dies hat den Vorteil: Geht irgend etwas schief bei der Entschlüsselung, hat man alle Chancen, das das dekomprimieren der Datei fehlschlägt, ein zwar nicht vordergründig gewollter, aber doch sehr nützlicher Breakpoint im Importablauf.

Diese Datei braucht nur noch auf den Server transferiert werden. Hier ist nun Vorsicht geboten, daß man sich mit Namensgleichheiten keinen Ärger einhandelt.

Nun kann das Programm gkrimport.bat gestartet werden, welches den Import ins GTDS steuert. Diese arbeitet im Moment noch mit dem SQL-LOADER. Diese Variante hat hin und wieder so ihre Tücken, so daß in Gießen über eine bessere, robustere Lösung nachgedacht wird. Über eine Klausel haben wir den Import von nicht verstorbenen Patienten bereits an dieser Stelle verhindert.

Das mit angestartete SQL-Skript korrigiert Unsauberkeiten in der Tabelle GKRANFRAGE. Bspw. kommen alle Zeichenketten als Großbuchstaben-Zeichenketten zurück, was umgewandelt wird. Damit das Sterbedatum keinen Verdruß macht, wir bekommen ja "nur" den Monat, wird der Tag des Datums auf den 15. gesetzt, was intern im GTDS der Monatskennung entspricht. Weitere Korrekturen sind im Zeichensatz notwendig.

Damit stehen alle Importdaten, gekennzeichnet mit einer eigenen ID und einem Datum für die Weiterbearbeitung zur Verfügung.

Die Weiterbearbeitung passiert in 3 Stufen:

1. Nur neue Patienten (Widerspruch zwischen gkranfrage.GKR_Sterbedatum und Patient.Sterbedatum)
2. Erweiterung von 1. auf Patienten, bei denen Widersprüche zwischen den Feldern gkranfrage.todesursache_1A bis...2B und den Einträgen in der Tabelle todesursache festgestellt wurden
3. alle Patienten

Für die Patienten, die über den Totenscheinabgleich eine möglicherweise neuere Information haben, wird an allen im System wichtigen Stellen eine Meldung generiert. Diese sind:

• Patientenauswahl
• Nachsorgeplanung/Mahnung
• Stammdatenpflege

Zur Steuerung dieser Meldung wird das Tabellenfeld STATUS in der Tabelle GKRANFRAGE benutzt, wobei die Information in Patientenauswahl und Stammdatenpflege nur einmalig stattfindet. Will ich eine neue Nachsorge planen/mahnen kommt diese Meldung immer. Zur besseren Software-Wartung empfielt es sich, daraus eine IP im Arden-Programm zu machen.

Vorstellbar ist, Beispiele sind im GTDS genug vorhanden, im GTDS unter Leitstelle eine Maske anzustarten, welche die Sicht auf die Tabelle GKRANFRAGE gestattet. Diese sollte eine reine Anzeigemaske mit einer Ausnahme sein. Diese Ausnahme stellt das Feld Status dar. So habe ich als Benutzer die Möglichkeit, den Status des Exportdatensatzes gezielt zu verändern, um einen erneuten Totenscheinabgleich manuell zu verhindern oder zu ermöglichen.

Denkbar ist auch, direkt aus dieser Maske in die betreffenden Masken zu verzweigen und die notwendigen Daten zu modifizieren.

Dieses Feld soll die Funktion eines Mailing-Status haben, wie wir es vom UX-mail bzw. Internetmail kennen. Folgende Werte sind vorstellbar:

Denkbar sind sicher weitere Fälle, wobei man sich primär erst einmal entscheiden muß, lasse ich Kombinationen dieser Zeichen zu und selectiere diese mit instring () oder wird das Feld mit varchar2(1) definiert.

Damit man den Benutzer, der das selten sieht nicht überfordert, bietet sich an, ein Merkmal zu definieren, welches genutzt werden kann, um freitextliche und halt auch durch den einfachen GTDS-Administrator wartbare Einträge zu erstellen.

Nach unseren Erfahrungen sollte man generell nicht zu euphorisch bei der Automatisierung des Abgleiches sein. Es gibt immer wieder Einzelfälle, wo Automatismen versagen, trotz intensivsten Bemühens beim Abgleich in Berlin, Daten der Totenscheine bzgl. unserer eigenen Informationen unplausibel erscheinen. Eine primäre Rolle spielen hier Patientenverwechselungen. Als GTDS- Nutzer kann man diese Risiko verringern, indem ich, wie in verschiedenen Registern teilweise heute noch üblich, auf eine Mehrfachverwendung von Pat_id´s verzichte. Patienten sollten generell daher nur mit den Skripten lpatien2 und lpatien3 gelöscht werden.

Die Mahnung zur Vorsicht bedeutet allerdings nicht, daß man für zu definierende Fälle ein automatisches Einlesen gestaltet. Es sollte nur Patienten in Frage kommen, bei denen eine eindeutige Zuordnung erfolgte: d.h:

• Das Feld nicht_eindeutig enthält ein F.
• Im Feld Personenzuordnung sind keine zusätzliche Eintragungen vorgenommen worden.
• Eine Prüfung auf Namensgleichheit mit mäßig standardisierten Namen und Geburtsdatum zum Geburtsdatum im GTDS ergab keine Differenzen.

Diese generelle Patientenauswahl als Voraussetzung sind folgende Möglichkeiten im Moment denkbar:

1. Ist das Sterbedatum im GTDS leer, kann sofort das Datum vom Totenschein eingefügt werden
2. Existiert kein Abschluß, kann man einen Abschluß automatisch anlegen, als Quelle den Totenscheinabgleich (Quelle der Angaben wird R, durchgefuehrt_von wird Gemeinsamens Krebsregister) nennen und anschließend mit den ICD´s die Tabelle Todesursache füllen;
3. Existiert ein Abschluß, könnte man, auch die Todesursache direkt eintragen. Voraussetzung ist hier die Gleichheit des Sterbedatums; Datenquelle wird E oder R

In allen Fällen einer automatischen Eintragung von Daten ist die eindeutige Information des Benutzers in bereits geschilderter Weise mittels des Feldes STATUS notwendig.

Der Export läuft ja ohne größere Notwendigkeiten des manuellen Eingriffs. De facto benötige ich nur ein Programm und dessen Parameter. Was liegt da nicht näher mittels eines Cron-Prozesses regelmäßig eine Anfragedatei zu erstellen, die dann im Bedarfsfall nach Berlin geschickt wird. Denkbar wäre ein Tag im Monat dafür. Der Aktualisierungsstand von im schlechtesten Falle einem Monat ist völlig ausreichend, da ja von der Erstellung des Totenscheins, dessen Eintreffens im GKR, der Dokumentation und der Übergabe an die Registerstelle ohnehin ein paar Tage (geschätzt 2 bis 4 Wochen) vergehen.

Günstigerweise packt man diese Datei dann mit zum "normalen" GKR-Export dazu, womit automatisch das Quartal als vorläufiger Rhythmus festgelegt ist, und andererseits kein Export "vergessen" werden kann. Somit haben sicher beide Seiten was davon.

In der Tabelle GKRANFRAGE kommen ja pro Abgleich alle verstorbenen Patienten rein. Es erscheint als sehr wahrscheinlich, vor allem bei älteren Jahrgängen, daß Datensätze immer wieder nach Berlin geschickt werden. Mit dem jetzigen Auswahlverfahren wird ein Patient, der einmal in die Tabelle GKRANFRAGE gekommen ist, mit Fehlerkennzeichen=T oder als verworfen gekennzeichnet wurde, immer wieder in das Exportfile geschrieben, unabhängig davon, ob mittlerweile ein besseres Ergebnis beim Abgleich in Berlin erzielt wurde.

Eine Möglichkeit wäre, die Duplikate in ein log-File zu schreiben, bzw. eine Möglichkeit zu schaffen diese Fälle gesondert in der tabellarischen Maske anzeigen zu lassen. Anschließend könnte man diese Datensätze, so man das will, meinethalben Dialogorientiert auf den vermeintlich richtigsten und wichtigsten reduzieren.

Mit dem Fall verworfen ist es dabei noch am leichtesten, den könnte ich über die Pflegemaske modifizieren. Beim Feld Fehlerkennzeichen ist das nicht so einfach.