GTDS-Betrieb aus technischer Sicht

Architektur - Überblick

GTDS ist eine Client-Server-Anwendung bestehend aus folgenden Komponenten

Anforderungen an Datenbankserver

Als Serverrechner kommen im Grunde alle Rechner und Betriebssysteme in Frage, auf denen die ORACLE Datenbank ab Version 8 laufen kann (u.a. UNIX/LINUX, Novell, Windows NT ff.). Die Systemanforderungen werden im wesentlichen durch die Anforderungen des Datenbankherstellers bestimmt.

Allerdings liegen im Entwicklerteam nicht zu allen Betriebssystemvarianten Erfahrungen vor, so daß eine Absprache erforderlich ist. Wir empfehlen derzeit PC-basierte UNIX-Versionen (z.B. LINUX) oder Windows NT (oder folgende) als in der Regel preisgünstigste Lösungen (Systemanforderung mindestens 1 GB Hauptspeicher, mindestens 1-2 * 40 GB freien Festplattenspeicher, Datensicherungsgerät, ggf. CDROM). Das Betriebssystem kann auch in einer virtuellen Maschine laufen (Erfahrungen liegen vor für Windows Server).

Die initiale Größe der Datenbank liegt bei knapp 2 GB.

Anforderungen an Client PC

Für die GTDS-Clients werden derzeit handelsübliche WindowsNT/2000/XP PC benötigt (erfüllen in aller Regel die Mindestausstattung von mind. 64 MB Hauptspeicher) mit einer Bildschirmauflösung von mindestens 800*600 Bildpunkten.

Die Clients können vollständig von einem Netzwerklaufwerk geladen werden. Es ist dann keine lokale Installation erforderlich. Im allgemeinen empfiehlt sich ein Laufwerksmapping.

Der notwendige ORACLE-Client wird von einer BAT/CMD-Datei gekapselt, in der über das (lokale) Setzen von Umgebungsvariablen eine lokale Installation eines Clients vermieden wird.

Nur bei geringer Bandbreite des Netzwerks kann es vorteilhaft sein, Teile der Anwendung auf den Clients zu verlagern.

Der Betrieb innerhalb eines Terminalservers (z.B. Citrix) ist möglich.

Anforderungen an Plattform für optionalen Web-Server

Der Web-Server basiert auf Java-Servlets innerhalb des Apache Tomcat (Version 4 oder 5) und kann grundsätzlich auf jeder Plattform betrieben werden, für die eine entsprechende Tomcat-Version verfügbar ist. Tomcat selbst läuft unter Java, welches ebenfalls installiert werden muß. Unterstützung für die Installation seitens der Entwickler gibt es für Windows- und Linux- Betriebssysteme sowie unter Umständen (nach vorheriger Absprache) weiteren UNIX-Plattformen.

Netzwerk

Der Zugriff der Clients erfolgt über das ORACLE Protokoll SQL*Net, welches seinerseits meist auf der Basis von TCP/IP läuft.

Datensicherung

Die jeweils zur Version verfügbaren ORACLE-Mechanismen zur Sicherung der Daten können genutzt werden.

Die Einrichtung und Kontrolle liegt in der Verantwortung des Nutzers. Das Entwicklerteam gibt allenfalls Hilfestellung.

Das Entwicklerteam empfiehlt grundsätzlich unabhängig von weiteren Sicherungsmaßnahmen den täglichen Datenbankexport. Dieser kann zu Niedriglast-Zeiten bei geöffneter Datenbank erfolgen.

Bei Einrichtung des Archivlog-Modus sind ausreichende Plattenkapazitäten vorzuhalten, da insbesondere im Rahmen von Auswertungen und Datenbank-Updates große Mengen an Log-Dateien anfallen können. Ggf. ist eine zeitweise Deaktivierung sinnvoll. Die Handhabung von Archivlog-Dateien wird von Entwicklerseite nicht aktiv unterstützt.

Installation der ORACLE-Datenbank

Bei Vorliegen entsprechenden Kenntnisse der Betriebssystemumgebung kann die ORACLE-Grundinstallation durch die Entwickler selbst vorgenommen werden. Ansonsten wird die Grundinstallation vorausgesetzt. Auch wenn ein gleichzeitiger Betrieb mit anderen Anwendungen theoretisch denkbar wäre, wird prinzipiell empfohlen, eine eigene Instanz mit einem eigenen Listener-Prozess bereitzustellen.

Installation der GTDS-Datenbank

Die eigentliche GTDS-Datenbank wird in der Regel über einen GTDS-Clienten installiert und bezüglich Datenbankobjekten auch gewartet.

Update der Anwendung

Updates und Patches sowie sonstige Erweiterungen werden paßwort geschützt im Internet unter http://www.med.uni-giessen.de/akkk/gtds/benutzer/download/ bereitgestellt. Die Information über die Verfügbarkeit von Updates erfolgt über e-Mail. Die Häufigkeit eines Updates liegt bei ein- bis zweimal pro Jahr.

Die entsprechenden Dateien, in der Regel ZIP-Archive, werden in das sogenannte GTDS-Verzeichnis eingespielt und dort ausgepackt. Dazu dürfen die zu überschreibenden Dateien nicht geöffnet sein, d.h. es darf zu diesem Zeitpunkt kein Benutzer die Anwendung geöffnet haben.

Unmittelbar danach ist das Datenbankupdate aus einem GTDS-Client heraus zu starten. Die dabei entstehende Log-Datei sollte auf Fehlermeldungen und Warnhinweise kontrolliert werden. Ggf. haben weitere Aktionen unmittelbar oder zeitlich unabhängig zu erfolgen. Das Datenbankupdate läuft unter dem Benutzer OPS$TUMSYS und muß, falls Beispieldaten ebenfalls aktuell verfügbar sein sollen, auch als Benutzer BEISPIEL wiederholt werden.

Sofern lokale Clients eingerichtet sind, müssen diese ebenfalls zeitnah aktualisiert werden. Anschließend kann die Anwendung wieder freigegeben werden.

Sofern Schnittstellen zu Krankenhausinformationssystemen oder Subsystemen vorhanden sind, müssen diese evtl. ebenfalls neu gestartet werden.

Falls vorhanden, muß in der Regel der Tomcat Web-Server neu gestartet werden.

Weitere Details finden sich in einer gesonderten Dokumentation. Bei Vorhandensein eines Fernwartungszugangs kann das Update auch durch die Benutzerunterstützung des GTDS erfolgen. Es empfiehlt sich in jedem Fall eine kurze Kontaktaufnahme, damit sicher gestellt ist, daß Log-Dateien im Zweifelsfall kurzfristig kontrolliert werden können.

Schnittstellen

Für Patientenstammdaten, Diagnosen-, Prozeduren und ggf. Befunde sind Standardschnittstellen entsprechend HL7 verfügbar. Weiterhin ist es ggf. sinnvoll Pathologiesysteme anzubinden (keine Standardschnittstelle vorhanden).

Für Einrichtung und Betrieb von Schnittstellen zu Krankenhausinformationssystemen oder Subsystemen sind gesonderte Dokumentationen verfügbar.

Organisatorisch / inhaltliche Pflege

Die Rechtevergabe einschließlich Anlegen neuer Benutzer ist an den Benutzer OPS$TUMSYS gebunden. Es ist sinnvoll dessen Paßwort auch einem Benutzer bekannt zu geben, der die fachliche Aufsicht über das System hat und der Ansprechpartner für inhaltliche Fragen ist.