Datenexport und -import zwischen zwei GTDS-Systemen

Um Daten zwischen zwei GTDS-Systemen auszutauschen, wurde eine Datenexport und -importschnittstelle eingerichtet. Das Anwendungsfeld bezieht sich gemäß den Anforderungen im ersten Einsatzgebiet zunächst auf folgende Daten:

Patientenstammdaten
Diagnosedaten
Verlaufsdaten
Therapiedaten

Vorgesehene Maßnahmen und Abschlußdaten sind derzeit nicht enthalten, können aber in späteren Ausbaustufen durchaus hinzukommen. Befunde werden zwar übertragen, im Zielsystem jedoch einem einheitlichen Befund zugeordnet, wobei die Information letztendlich ausschließlich als Klartext in das Bemerkungsfeld übertragen wird. Betreuende Ärzte und Informationen über Studienteilnahme werden ebenfalls als Klartext übertragen und bei Neuanlage eines Patientendatensatzes im Notizfeld hinterlegt. Für die erfolgreiche Kommunikation muß folgendes bedacht werden:

Die Semantik der ausgetauschten Inhalte muß in Sender und Empfänger gleich oder zumindest kompatibel sein, d.h., überall dort, wo verborgen oder offen Codes in der Dokumentation eingesetzt werden, müssen diese übereinstimmen, damit der Empfänger weiß, was der Sender mit einem Code meint.
Dies bedeutet, daß überall, wo eigene Anpassungen an Auswahllisten durchgeführt wurden, diese zwischen allen an der Kommunikation beteiligten Partnern bekannt sein müssen. Im Grunde muß für jedes Feld eine Vereinigungsmenge aller Codes (und natürlich der Bedeutungen) gebildet und in allen Zentren eingerichtet werden.
Das Bilden dieser Vereinigungsmengen ist nicht Bestandteil dieser Schnittstelle - es kann nicht automatisiert durchgeführt werden. In jedem Fall muß es vor Einsatz der Schnittstelle durchgeführt werden.
Wenn dies nicht oder nur schwer möglich ist, müssen Konvertierungen durchgeführt werden, die eventuell noch in die Schnittstelle eingearbeitet werden müssen.
In erweitertem Sinn trifft die Notwendigkeit des Abgleichens von Codes auch für Beziehungen zwischen Objekten (Patienten, Tumoren, Verläufe, aber auch Ärzte und Abteilungen usw.) zu. Alle diese Verknüpfungen erfolgen ja bekanntlich über ID-Nummern. Hierfür gibt es aber in der Schnittstelle Mechanismen - in Tabellen (FREMD_ID, SONSTIGE_FREMD_ID) merkt sich das empfangende System, welche Identifikation ein Datensatz in einem anderen System hat. Dadurch ist es in der Lage, nachfolgende Informationen, z.B. den Tumor zum Patienten und den Verlauf zum Tumor, korrekt zuzuordnen.
Da einige "Objekte", z.B. Abteilungen, nicht Bestandteil des Austausches sind, müssen Zuordnungen zu diesen Objekten auf eigene Entsprechungen umgeschaltet werden. Dazu ist es zunächst erforderlich, diese Objekte selbst anzulegen und anschließend die Zuordnungsvorschrift (in der Tabelle ID_MATCH) abzulegen.
Beispiel: Derzeit werden alle exportierten Datensätze einer Abteilung zugeordnet (z.B. Leitstellen_ID des Registers "Rostock") zugeordnet. Das empfangende System, z.B. GTDS in Schwerin, muß dann in den Abteilungsstamm eine Abteilung "Krebsregister Rostock" eintragen. In ID_MATCH wird dann abgelegt, daß die Leitstellen_ID von Rostock auf die ID der Abteilung "Krebsregister Rostock" abgebildet wird, so daß die Datensätze im Schweriner GTDS dann der Abteilung "Krebsregister Rostock" zugeordnet wird.
Dieser Mechanismus kann in weiteren Ausbaustufen dann auch genutzt werden, um z.B. Befunde und Chemotherapie-Protokolle oder Abteilungen in detaillierterer Weise zuzuordnen.
In allen Tabellen, die diese Zuordnungen erlauben, muß natürlich auch festgelegt werden, für welchen Sender diese Zuordnungen gelten. Diese Sender werden in der Tabelle ANDERE_EINRICHTUNG festgelegt.

Nach diesen grundsätzlichen erklärenden Vorbemerkungen kann nun die Schnittstelle auf Seiten des GTDS eingerichtet werden. Grundlage ist das Einspielen eines Patches mindestens vom Stand 5. November 2001 oder ein späteres Update sowie eines getrennt herunterladbaren Zusatzmoduls (webgtds.zip), welches auch die notwendigen Dateien für den Datenimport enthält.

Einrichtung der sendenden Einrichtungen

Maske "andere Einrichtungen" unter "Stammdaten, Schlüssel, ..."

Tragen Sie hier alle Sender von Nachrichten ein. Die Bezeichnungen müssen unter den Kommunikationspartnern abgesprochen sein, da die Schnittstelle aus den Bezeichnungen die eigenen Einrichtungs-IDs ermitteln. Außerdem müssen Bezeichnungen und insbesondere Einrichtung_IDs über die Zeit konstant bleiben.

Einrichtung der Nachrichten-Empfänger

Maske "Nachrichten/Schnittstellen" unter "Benutzer, Rechte, ..."

Im Punkt Definition/Versand werden die Nachrichtentypen und Empfänger definiert. Die Nachrichtentypen (Tabelle NACHRICHT_AUFRUF) werden grundsätzlich durch die Entwickler bestimmt und im Datenbank-Update eingespielt. Die Empfänger (Tabelle NACHRICHT_ZIEL) werden nach dem dargestellten Muster selbst festgelegt. Für den Datenaustausch zwischen Registern ist die LfdNr "100" vorgesehen. Empfänger können grundsätzlich auf einen bestimmten Nachrichtentyp oder eine bestimmte Nachricht eingeschränkt werden. Mit angekreuztem "Filter auf Nachricht" werden nur die für die Nachricht gültigen Empfänger angezeigt. Für den Registeraustausch müssen die Empfänger wegen der zu übergebenden Parameter nachrichtenspezifisch angegeben werden.

Dieser Teil der Maske dient auch dem Start des Exportprogramms. "Verschicken" startet das Exportprogramm für einen bestimmten Empfänger. In diesem Fall entsteht eine nicht kryptografierte Datei im sogenannten XML-Format. Diese wird dann z.B. mit dem frei verfügbaren DES-Programm kryptografiert (Unterverzeichnis admin\tool) und verschickt (auf Diskette). Mit "Anzeigen" werden alle für diesen Typ vorgesehenen und verschickten Nachrichten angezeigt, die dann weiter auf vorgesehene gefiltert werden können.

Der komplette Eintrag unter Kommando lautet:

$javaexe xmlrw ~benutzer ~passwort jdbc:oracle:thin:@141.50.42.214:1521:~datenbank mvp.xml

Dieser Eintrag muß folgendermaßen angepaßt werden: 141.50.42.214 durch die IP-Adresse des Datenbankservers. Darüberhinaus muß ein Eintrag in der gtds.ini erfolgen, der die Ersetzung für "$javaexe" bildet, z.B.

javaexe I:\webgtds\jre\bin\java.exe -classpath I:\webgtds\lib\xalan.jar;I:\webgtds\lib\xerces.jar; I:\webgtds\lib\classes102.zip;I:\webgtds\lib\classes111.zip; I:\webgtds\tomcat\lib\servlet.jar;I:\webgtds\tomcat\lib\webserver.jar; I:\webgtds\tomcat\webapps\gtds\WEB-INF\classes

Dieser Eintrag muß natürlich in einer Zeile stehen (siehe auch "gtdsbsp.ini"). "I:" muß ersetzt werden durch das Laufwerk und evtl. den Pfad zum Verzeichnis, in dem Sie webgtds ausgepackt haben.
Hinweis: Ältere ORACLE-Datenbankversionen benötigen evtl. andere Einträge und evtl. die Installation weiterer Client-Software.

Der komplette Eintrag unter Parameter lautet:

i:\webgtds\ausgang\hro_sn.xml "ABSENDER=Krebsregister Rostock" ZIEL=1 "ZIELORT=Krebsregister  Schwerin" ABTEILUNG_ID=77 QUALITATIVE_ID=1 QUANTITATIVE_ID=1

Hierbei gibt "i:\webgtds\ausgang\hro_sn.xml" den Pfad zur nicht kryptografierten Datei an. Der Eintrag "Krebsregister Rostock" kennzeichnet das sendende System und wird beim Einlesen verwendet um den Einsender zu bestimmen.
"ZIEL=1" bestimmt, daß für diesen Export Datensätze mit dem Ziel 1 (also der LfdNr des aktuellen Nachricht_Ziel Satzes) ausgewählt werden sollen.
Als ZIELORT muß die gleiche Bezeichnung eingetragen werden, wie sie in der Tabelle "ANDERE_EINRICHTUNG" verwendet wird. Bei der Analyse des Datensatzes beim Empfänger kann hierdurch bei dem Rückexport eine Zuordnung der Identifikationsnummern erfolgen.
Die ABTEILUNG_ID gibt eine Kennung an, die dem empfangenden System ermöglicht, die eingehenden Datensätze rechtemäßig einer bestimmten Abteilung zuzuordnen. Diese Zuordnung geschieht, natürlich im empfangenden System, auch in der Maske der Nachrichtendefinitionen unter dem Punkt "ID-Match":

Das bedeutet, daß das empfangende System den Sender als eigene Abteilung einträgt, der er auch nur privilegierte Benutzer zuordnen kann. Der Wert "77" ist hier vollkommen willkürlich wählbar. Sinnvollerweise sollte man da evtl. die ID der eigenen Leitstelle eintragen. Entsprechendes gilt für die Zuordnung von qualitativen und quantitativen Befunden. Auch hier ist der Eintrag von "1" willkürlich.
Da im empfangenden System alle Datensätze einer bestimmten Abteilung zugeordnet werden, erscheint zunächst auschließlich diese in der Datenübersicht der vorhandenen Daten. Falls erwünscht, kann zusätzlich die Information aus dem jeweiligen Feld "DURCHGEFUEHRT_VON" angezeigt werden. Mit Eintrag des Parameters VHD_P.DURCHFUEHRENDE_HOLEN in den GTDS-Parametern kann durch eine mit Leerzeichen getrennten Liste von ABTEILUNG_IDs angegeben werden, für welche Abteilungen dies geschehen soll.

Mit

e:\gtds\admin\tool\des -e -k geheimesblabla hro_sn.xml hro_sn.crypt

wird dann diese Datei kryptografiert. "E:\gtds" wird durch den Pfad zum GTDS-Verzeichnis ersetzt. "hro_sncrypt.xml" kann dann auf Diskette geschrieben und versandt werden. Beim Empfänger wird mit

e:\gtds\admin\tool\des -d -k geheimesblabla hro_sn.crypt hro_sn.xml

der ins Eingangsverzeichnis gespielten Datei wieder die lesbare Version erzeugt.

Vormerken von Patienten für den Versand

Zunächst muß in der Maske "Dynamische Module" unter "Benutzer, Rechte, ..." das Modul mit der Kennung "NACHRPAT" aktiviert werden. Daraufhin ist unter den zusätzlichen Dokumenten eines mit der Bezeichnung Nachrichten sichtbar. Durch Eintrag der Nachricht 100 mit dem gewünschten Ziel wird eine Nachricht vorgesehen. Gleichzeitig kann der Patient für weitere Eingaben gesperrt werden. Dies erfordert entsprechende Einträge unter "GTDS Parameter (weitere)":

GLOBAL.PRUEFE_PATIENTENSPERRE legt fest, welcher Eintrag in Patient.Zusatzmerkmal eine Sperrung der Patientendaten bewirkt.
GLOBAL.SPERRNACHRICHTEN enthält eine durch Leerzeichen getrennte Liste von Nachrichtennummern, deren Neueintrag zur Bearbeitungssperre von Patientendaten führt

Diese Maske ist dann als "Nachrichten" unter "zusätzliche Dokumente" erreichbar.

Wenn Patientendaten an ein anderes Register übermittelt werden soll, wird eine Nachricht mit der Nummer 100 und dem entsprechenden Zielort eingetragen.

Importieren von Patienten

Das Importieren von Patienten erfolgt über eine Webanwendung die von einer Art Webserver bedient wird. Lesen Sie hierzu die Datei readme.html im "webgtds" Verzeichnis.

Nach dem Import kann automatisch eine Warnung erfolgen, wenn der Tumorakte neue Datensätze hinzugefügt werden. Damit soll der Benutzer daran erinnert werden, die Daten wieder erneut an den Sender zurück zu übermitteln. Zum Einrichten der Warnung ist ein Eintrag in den GTDS-Parametern erforderlich: GLOBAL.DOKUMENT.PRE-INSERT muß den Eintrag "gpn" enthalten. Daraufhin erfolgt in allen Dokumenten eine Warnung, sobald ein Datensatz existiert, der einer der Abteilungen in VHD_P.DURCHFUEHRENDE_HOLEN zugeordnet ist.