Systemdienste für die Interaktion mit Tumordokumentationssystemen
aus anderen Systemen mit beispielhafter Erprobung im Gießener Tumordokumentationssystem
(GTDS) - WebGTDS
(gefördert durch das Bundesministerium für Gesundheit)
Einführung
Die Integration der Tumordokumentation in Routineabläufe ist derzeit
die wichtigste Anforde-rung, um auch in Zukunft qualitativ hochwertige
Daten für die bessere Versorgung von Krebspatienten zur Verfügung
zu haben.
In der Vergangenheit wurden daher Anstrengungen im Bereich von Datenschnittstellen
unter-nommen, um Daten aus bestehenden Systemen übernehmen zu können.
Diese haben zum einen zur Definition der BDT-Schnittstelle geführt.
Zum anderen wurden in mehreren Klini-ken Schnittstellen von Tumordokumentationssystemen,
z.B. dem Gießener Tumordokumentationssystem (GTDS) zu Verwaltungssystemen
realisiert, um vor allem Stammdaten, aber auch operative Daten aus Kliniksystemen
zu übernehmen. Dies ist ein Ansatz, der auch weiterhin schrittweise
weiterverfolgt und ausgebaut werden wird.
Ein weiteres grundlegendes Integrationsproblem ist durch das Vorhandensein
von Schnitt-stellen noch nicht gelöst. Eine Integration mit anderen
Systemen erfordert, daß Daten auch in anderen Systemen bereitgestellt,
verarbeitet und eingegeben werden können. Auf diese Weise wird aus
Sicht des Anwenders ein Bruch in der Benutzerführung durch den Aufruf
eines ande-ren als seines gewohnten Systems (Abteilungssystem, Praxissystem)
vermieden. Ein entspre-chender Ansatz wurde in einem Projekt des GTDS mit
der Firma Softcon 1995 / 1996 testweise verwirklicht. Allerdings beschränkte
sich dieser seinerzeit auf die Darstellung von Informationen in unstrukturierter
Form, so daß eine weitergehende Verarbeitung der Information (Korrektur,
Ergänzungen von Daten) damit nicht möglich war.
Für eine Koppelung mit Systemen, bei denen eine direkte Benutzerinteraktion
in dem Sinne erfolgt, daß zum Beispiel bestimmte Tumorinformationen
abgerufen oder auch eingegeben werden sollen, ist ein weitergehender Ansatz
erforderlich. In diesem Konzept bietet das GTDS Dienste an, wie zum Beispiel
-
"Patienten auswählen",
-
"Patienten neu eingeben",
-
"Tumordaten eingeben",
-
"Übersichtsinformationen holen",
-
"Verlaufsdaten einge-ben",
-
"Nachsorgedaten einge-ben" u.s.w.,
die dann von einem anderen System angesprochen werden können. Bis
vor weni-gen Jahren gab es jedoch in diesem Bereich noch keine standardisierte
Methodenumgebung, mit der sol-che Dienste verwirklicht werden konnten,
so daß Dienste nur über proprietäre Schnittstellen mit
entsprechend hohem Aufwand auf beiden Seiten verwirklicht werden konn-ten.
In den vergangenen Jahren sind, unter anderem im Zusammenhang mit der
Weiterentwicklung objektorientierter Programmierung und des Internet, eine
Reihe standardisierter Techniken wie CORBA (Common Object Request Broker
Architecture mit der systemunabhängigen IDL (Interface Definition
Language) zur Beschreibung der Dienstaufrufe), dem defacto-Standard URL
mit seinen universellen Möglichkeiten, Ressourcen (Dokumente, Methoden)
zu nutzen, und XML (Extensible Markup Language) entstanden, die es erlauben,
Entwicklungen für die Integration von Anwendungen effektiver auf einer
höheren Ebene ohne Festlegung auf eine konkrete Syste-mumgebung durchzuführen.
Damit können unterschiedliche Systeme leichter miteinander gekoppelt
werden. Entsprechende Werkzeuge sind zum Teil frei verfügbar.
Auf der inhaltlichen Seite muß den Programmierern von Systemen,
die die Tumordokumen-tation integrieren wollen, eine Beschreibung zur Verfügung
gestellt werden, die es ihnen ermöglicht, mit einem Minimum an weiteren
Absprachen Integrationslösungen zu entwickeln.
Sowohl die Beschreibungen als auch die technische Umsetzung in Form
eines APIs (Applica-tion Programming Interface) müssen dabei folgende
Anforderungen berücksichtigen:
-
Standards für die Tumordokumentation (Basisdokumentation)
-
Aspekte des Datenschutzes und der Datensicherheit
Bezüglich der Patientenrechte (Datenschutz und Datensicherheit) wird
davon ausgegangen, daß das derzeitig im GTDS umgesetzte und langjährig
im Einsatz befindliche Konzept (alle Behandler eines Patienten dürfen
alle Daten des Patienten sehen, aber nur die selbst einge-brachten Daten
ändern) eine tragfähige Basis für diese Entwicklung ist.
Allerdings müssen dabei, wie auch die Benutzerevaluation gezeigt hat,
verstärkt Rollenkonzepte zum Einsatz kommen, die benutzerabhängig
die zulässigen Funktionen (Dienste) begrenzen. Dies hat über
den Datenschutz hinaus den Vorteil, durch Reduktion der verfügbaren
Dienste das System für ungeschulte Benutzer zu vereinfachen.
Realisation
Die Servicefunktionen werden über die HTTP-Post-Methode aufgerufen.
Übergabeparameter und Rückgabewerte werden dabei in XML encodiert.
Das entgegennehmende Servlet ist in Java realisiert und übergibt die
Daten, gegebenfalls nach Vorverarbeitung, an Datenbankprozeduren.
Für die Demonstration des Zugriff auf die Dienste wurde ein Serverdienst
implementiert, der über CGI mit HTML-Clients (WWW-Browsern) kommuniziert.
Die grundsätzliche Funktionsweise besteht darin, das durch die
Dienste übergebenen XML in CGI-Forms zu übersetzen und die CGI-Variablen
wieder in XML zu transferieren. Die Beschreibung der "HTML-Masken" erfolgt
dabei ebenfalls in XML. Darüber hinaus wird für die Beschreibung
von Auswahllisten auf Dokumentationsstandards und eigene Erweiterungen
zugegriffen, die ebenfalls in XML-Dateien hinterlegt sind.
Die Extensible Markup Language (XML) hat also drei Funktionen
-
Kommunikation mit den GTDS-Diensten
-
Beschreibung der HTML-Masken
-
Hinterlegen von Datenstandards
Die Beschreibung der HTML-Masken in XML stellt im wesentlichen ein Gerüst
dar, welches das gleiche Schema aufweist, wie die Daten, die durch die
Dienste geliefert werden. In dieses Gerüst sind zur Formatierung als
Namespace HTML-Tags eingebunden. Attribute steuern die Verarbeitung durch
den HTML-Server, der aus PERL-Skripten aufgebaut ist.
Die Funktionsweise soll anhand der folgende Dienste näher erläutert
werden.
Hinweise:
Die hier angezeigten Masken sind nicht funktionsfähig (aber original
abgespeicherte Versionen aus dem Betrieb). Das Ausprobiern von Knöpfen
führt zu Fehlern. Es ist geplant, zumindest auf Anforderung auch die
Dienste zum Austesten bereitzustellen.
Ihr WWW-Browser kann Schwierigkeiten mit der Darstellung von XML haben.
Erprobt ist es für den MS Internet Explorer 5. Bei anderen Browsern
/ Versionen muß die Datei evtl. heruntergeladen und mit einem ASCII-Editor
dargestellt werden.