Erfahrungsbericht: Testung/Gestaltung der GKR-Totenscheinschnittstelle

 

1. Gestaltung der Schnittstelle *

1.1. Struktur der Export-Tabelle *

1.2. Struktur der GKR-Totenscheinabgleichdatei *

1.3. Struktur der GTDS Tabelle GKRANFRAGE *

2. Ablaufmodell *

3. Installation der Schnittstellen-Programme *

4. Erstellung eines Exportfiles *

5. Import der Totenscheindaten *

6. Weiterbearbeitung im GTDS *

6.1. Generierung von Reportausgaben: *

6.2. Generierung vom Meldungen, *

6.3. Sichtung und Modifizierung der eingegangenen Daten per Maske *

7. Offene Gestaltungsansätze *

7.1. Genauere Spezifizierung des Wertevorrates für das Feld Status *

7.2. Teilweise Automatisierung des Imports *

7.3 Steuerung des Datentransfers *

7.4 Abfangen und Bewerten von Mehrfacheinträgen *

 

  1. Gestaltung der Schnittstelle

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)

1.1. Struktur der Export-Tabelle

Siehe 1.2 Zeilen der Tabelle von Lfdnr. 1 bis 14

1.2. Struktur der GKR-Totenscheinabgleichdatei

Lfd. Nr.

Feldname

Feldlänge

ASCII-Position

in Tabelle GKR-ANFRAGE enthalten

1

Geburtstag

2

1:2

X

2

Geburtsmonat

2

3:4

X

3

Geburtsjahr

4

5:8

X

4

Name

30

9:38

X

5

Vornamen

30

39:68

X

6

Geburtsname

30

69:98

 

7

Früherer Name

30

99:128

 

8

Titel

8

129:136

 

9

Geschlecht

1

137:137

 

10

Straße

30

138:167

 

11

PLZ

5

168:172

 

12

Ort

30

173:202

 

13

Pat.-Identifikation

7

203:209

X

14

TZ-Identifikation

4

210:213

 

15

Sterbemonat

2

214:215

X

16

Sterbejahr

4

216:219

X

17

Todesursache 1a

4

220:223

X

18

Todesursache 1b

4

224:227

X

19

Todesursache 1c

4

228:231

X

20

Todesursache 2a

4

232:235

X

21

Todesursache 2b

4

236:239

X

22

Todesursache Unfall

4

240:243

X

23

Obduktion

1

244:244

X

24

Quelle der Todesmeldung

1

245:245

X

25

Krebs-Tod-Relation

1

246:246

X

26

Merkmal für Personenzuordnung

10

247:256

X

27

GKR-Eingangsnummer

10

257:266

 

28

Fehlerkennzeichen

1

267:267

X

 

1.3. Struktur der GTDS Tabelle GKRANFRAGE

Feldname

Definition

Inhalt

GKR_ID

NUMBER(5)

Eindeutige ID zum Importlauf

DATUM_DES_ABGLEICHES

DATE

Sysdate beim Importvorgang

GEBURTSDATUM

DATE

Geburtsdatum: aus Redundanzgründen mit übernommen, um Widersprüche aufzudecken, s. auch weitere Felder

NAME

VARCHAR2(30)

Patientenname dto. Geburtsdatum

VORNAME

VARCHAR2(30)

Patientenvorname, dto. Geburtsdatum

FK_PATIENTPAT_ID

NUMBER(10)

Pat_id in unserem Register

GKR_STERBEDATUM

DATE

Sterbedatum beim GKR; ACHTUNG dieses hat nur Monatsgenauigkeit

TODESURSACHE_1A

VARCHAR2(4)

Totenscheinschlüssel Ia

TODESURSACHE_1B

VARCHAR2(4)

Totenscheinschlüssel Ib

TODESURSACHE_1C

VARCHAR2(4)

Totenscheinschlüssel Ic

TODESURSACHE_2A

VARCHAR2(4)

Totenscheinschlüssel IIa

TODESURSACHE_2B

VARCHAR2(4)

Totenscheinschlüssel Iib

TODESURSACHE_UNFALL

VARCHAR2(4)

noch leer

OBDUKTION

VARCHAR2(1)

j/n/x

QUELLE_DER_TODESMELDUNG

VARCHAR2(1)

 

KREBS_TOD_RELATION

VARCHAR2(1)

Entspricht im GTDS: Tod tumorbedingt, noch leer

MERKMAL_PERSONENZUORDNUNG

VARCHAR2(10)

Ergebnis des Record linkage

FEHLERKENNZEICHEN

VARCHAR2(1)

T bedeutet Patient konnte nicht eindeutig identifiziert werden

F Suche erfolgreich

BEARBEITUNGSSTATUS

VARCHAR2(2)

Gedacht um mailing-funtionen zu steuern, siehe Punkt 7.1

 

  1. Ablaufmodell
  2. Installation der Schnittstellen-Programme

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 UXe 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)

  1. Erstellung eines Exportfiles

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

Gkranfrage.bat <registerzeichen> <von> <bis>

oder

Gkrjahr.bat <registerzeichen> 1992 1993 1994 1995 1996 1997 ...

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:

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.

  1. Import der Totenscheindaten

Benötigt werden hierfür:

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.

  1. Weiterbearbeitung im GTDS

Die Weiterbearbeitung passiert in 3 Stufen:

6.1. Generierung von Reportausgaben:

  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

6.2. Generierung vom Meldungen,

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:

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.

6.3. Sichtung und Modifizierung der eingegangenen Daten per Maske

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.

  1. Offene Gestaltungsansätze

7.1. Genauere Spezifizierung des Wertevorrates für das Feld Status

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

Zeichen

Name

Erläuterung

B

Bearbeitet

Wird gesetzt, wenn der Datensatz im GTDS eingetragen wurde

G

Gesehen

Damit kann man das einmalige Anzeigen einer Meldung in der Patientenauswahl und Patstammmaske steuern

V

Verworfen

Datensatz erscheint bzgl. eigener Recherchen und Informationen unplausibel

A

Automatische Einträge generiert in allen 3 Fälle

In allen unter 7.2 genannten Fällen wurden Daten ins GTDS einfügt. Löst eine gesonderte Warnung aus

S

AbSchluß wird automatisch generiert

Löst eine gesonderte Warnung aus

D

SterbeDatum automatisch eingefügt

Löst eine gesonderte Warnung aus

T

Tabelle Todesursache automatisch gefüllt

Löst eine gesonderte Warnung aus

NULL

Datensatz total neu

Standardeintrag nach einem neuen Importlauf

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.

7.2. Teilweise Automatisierung des Imports

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_ids 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:

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

7.3 Steuerung des Datentransfers

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.

7.4 Abfangen und Bewerten von Mehrfacheinträgen

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.