Konzeption und Realisierung eines
Terminplaners für ein
radiologisches Informationssystem
(RIS) unter Berücksichtigung
softwareergonomischer Aspekte

Diplomarbeit im Studiengang Informatik an der
Universität Ulm

Vorgelegt von
Hariolf Häfele

28. Mai 2002

Inhaltsverzeichnis

1 Einführung ... 1

2 Bisherige und geforderte Funktionalität ... 3
    2.1 Funktionalität des bisherigen Terminplaners ... 3
    2.2 Anforderungen an den neuen Terminplaner ... 3
        2.2.1 Mehrfachtermine ... 4
        2.2.2 Geschwindigkeit ... 4

3 Theorie der Ablaufplanung ... 7
    3.1 Planungsprobleme ... 7
        3.1.1 Auftragsmodelle ... 8
        3.1.2 Prozessormodelle ... 9
        3.1.3 Optimierungskriterien ... 11
        3.1.4 Beispiele ... 12
        3.1.5 Erweiterungen ... 13
    3.2 Lösung von Planungsproblemen ... 13
    3.3 Mehrere Prozessoren pro Operation ... 13
    3.4 Terminplanung in der Radiologie ... 14
        3.4.1 Das Modell für Serientermine ... 16
        3.4.2 Das Modell für Profiltermine ... 16

4 Algorithmen zur Terminvergabe ... 19
    4.1 Der Algorithmus zur Profilterminvergabe ... 19
        4.1.1 Komplexität ... 22
    4.2 Der Algorithmus zur Serienterminvergabe ... 23

5 Implementierung ... 25
    5.1 Schichten bei Anwendungsarchitekturen ... 25
        5.1.1 2-Schicht-Modell ... 25
        5.1.2 3-Schicht-Modell ... 26
    5.2 Verwendete Softwareprodukte ... 27
        5.2.1 Java ... 27
        5.2.2 J2EE und EJB ... 28
        5.2.3 Orion ... 30
        5.2.4 Forte ... 30
        5.2.5 SourceSafe ... 30
        5.2.6 Oracle 8.06 ... 30
        5.2.7 JFCSuite ... 31
    5.3 Benutzeroberfläche ... 31
        5.3.1 Steuerungsleiste ... 32
        5.3.2 Monatsübersicht ... 32
        5.3.3 Multifunktionsleiste ... 32
        5.3.4 Weitere Termine / Abwesenheitsliste ... 33
        5.3.5 Terminübersicht ... 33
        5.3.6 Termindialog ... 34
    5.4 Architektur der Benutzerschicht ... 34
    5.5 Architektur der Vorgangsbearbeitung ... 36
        5.5.1 Session-Beans ... 38
        5.5.2 Entity-Beans ... 46
    5.6 Stand des Projektes ... 48

6 Fazit und Ausblick ... 49

Stichwortverzeichnis ... 51

Kapitel 1
Einführung
Die Firma GE Medical Systems Information Technologies1 in Dornstadt bei Ulm ist einer der führenden Hersteller von Radiologie-Informationssystemen (RIS) in Europa. Das Hauptprodukt der Firma ist das Programmpaket Medora, welches eine vollständige RIS-Lösung für radiologische Kliniken und Praxen darstellt.

Ein RIS dient dazu, Radiologiepatienten und Patientenakten, Materiallager, Befundungen sowie Belegungen von Geräten, Arbeitsplätzen und Mitarbeitern zu verwalten.

Eng verwandt mit dem Begriff des RIS ist der des Krankenhaus-Informationssystems (KIS). Ein KIS ist eine Software, die zentral alle Patienten des Krankenhauses erfaßt und verwaltet. RIS und KIS kommunizieren über den sogenannten HL7-Standard2, welcher ein Protokoll zur elektronischen Kommunikation im Gesundheitswesen darstellt. Die Kommunikation zwi

!! Abbildung in dieser Vorschau nicht verfügbar !!

Abbildung 1.1: KIS und RIS

schen KIS und RIS verläuft dabei in beiden Richtungen. Eine typische HL7-Nachricht vom KIS an das RIS wäre etwa die Anforderung einer CT-Aufnahme für einen Patienten an einem bestimmten Tag. Das RIS sendet daraufhin z. B. eine Terminbestätigung an das KIS zurück. HL7-Nachrichten können auch von anderen Krankenhausabteilungen an das RIS gesandt werden.

Das Radiologie-Informationssystem Medora wurde bisher vollständig mit der Programmierumgebung Oracle Forms entwickelt34, welches auf die Erstellung von Datenbankanwendungen mit graphischer Oberfläche zugeschnitten ist. Forms ermöglicht es auf relativ einfache Weise, dialogbasierte Anwendungen zu erstellen, die an eine Datenbank gekoppelt sind. Ein großes Manko von Forms ist allerdings, daß der Entwickler die Oberfläche nur aus einem sehr beschränkten Satz von Komponenten zusammenbauen kann. Daher lassen die damit erzeugten Applikationen in puncto Benutzerfreundlichkeit eher zu wünschen übrig und sind bezüglich Benutzeroberfläche nicht auf dem aktuellen Stand der Technik. So ist es in einer Forms-Applikation für den Benutzer nicht möglich, die Größe von Fenstern oder von Unterkomponenten wie Tabellenspalten zu verändern oder Objekte zu verschieben (”Drag and Drop“ ). Auch gibt es für viele der Elemente einer modernen Benutzeroberfläche wie Kontextmenüs, Baumansichten usw. in Forms keine Entsprechung.

Eine weitere Problematik resultiert aus der Tatsache, daß, um in Forms eine bestimmte Reaktion auf ein semantisches Ereignis (Mausklick, Tastatureingabe, Nachricht über Änderung eines Datensatzes, usw.) zu programmieren, im Regelfall eine ganze Reihe von Behandlungsroutinen für sog. Trigger bemüht werden müssen. Die Mengen von Triggern, die für semantische Ereignisse benötigt werden, überschneiden sich untereinander, so daß mit steigender Größe des Projekts die Abhängigkeiten zwischen Behandlungsroutinen untereinander zunehmen und es immer schwieriger wird, Änderungen am Code vorzunehmen und dabei unbeabsichtigte Seiteneffekte im Griff zu behalten.

Zu der genannten Unübersichtlichkeit steuert auch die fehlende Objektorientierung von Forms bei, die ebenfalls mit zunehmender Projektgroße immer stärker ins Gewicht fällt.
Aus diesen Gründen beschloß man Mitte 2001, als Technologiestudie – mit Option auf Fortführung als Produkt – ein einzelnes Modul von Medora auf eine Plattform umzustellen, die die erwähnten Mängel nicht aufweisen, aber gleichzeitig eine effektive Datenbankanbindung erlauben würde. Die Plattformwahl fiel auf Java5, da es zum einen auf einfache, aber dennoch flexible Weise gestattet, graphische Benutzeroberflächen zu implementieren und zum anderen durch die J2EE-Erweiterung 3-Schicht-Architekturen unterstützt werden, somit also eine Anbindung der objektorientierten Programmiersprache an eine relationale Datenbank gegeben ist.

Als Objekt der Technologiestudie war das Terminplanungsmodul am geeignetsten, da bei ihm erstens die geringste Abhängigkeit zu anderen Medora-Komponenten besteht, es also das am einfachsten austauschbare Modul ist, und zweitens bei der Terminplanung der Bedarf nach einer verbesserten Version am größten war. Außerdem hätte bei einer Forms-Implementierung die erwähnte Zunahme der Unübersichtlichkeit und der Seiteneffekte bei den für die neue Version geplanten Funktionen ”Serientermine“ und ”Profiltermine“ entsprechenden Mehraufwand bereitet.

Die vorliegende Diplomarbeit beschäftigt sich mit der Konzeption und Realisierung der Technologiestudie ”Neue Terminplanung“.

Kapitel 2
Bisherige und geforderte Funktionalität
2.1 Funktionalität des bisherigen Terminplaners
Der bisherige Terminplaner verwaltet Termine auf der Basis von Terminbüchern. Ein Terminbuch ist eine Übersicht über die Termine einer Ressource (Mitarbeiter oder Gerät). Jeder Ressource ist ein Terminraster zugeordnet, welches je nach Tag verschieden sein kann. Es gibt drei Hauptdialoge, von denen mehrere gleichzeitig geöffnet werden können:

• 
  Tagesübersicht (Stellt ein Terminbuch für eine Ressource an einem Tag dar; siehe Abb. 2.1)
  
• 
  Jahresübersicht (Stellt einen Jahreskalender für eine Ressource dar; Mausklick auf einen Tag öffnet die Tagesübersicht für diese Ressource; siehe Abb. 2.1)
  
• 
  Terminauskunft (Suche nach existierenden Terminen)
  

Zur Anzeige einer Tages- und Jahresübersicht einer Ressource muß der Benutzer diese erst im Ressourcenauswahl-Dialog auswählen (siehe Abb. 2.2). Um einen neuen Termin anzulegen, klickt man in der Tagesübersicht auf eine freie Rasterzeile, worauf sich ein Patientenauswahl- Dialog öffnet (siehe Abb. 2.3). Nachdem der Patient, für den der Termin reserviert werden soll, ausgewählt ist, öffnet sich der eigentliche Terminvergabe-Dialog (Siehe Abb. 2.4).

[...]

1 http://www.gemedical.de/
2 http://www.hl7.org/
3 http://otn.oracle.com/products/forms/content.html
4 Zum Zeitpunkt der Drucklegung wurde die Version 4.5 verwendet; es wird im Folgenden, soweit nicht anders angegeben, auf diese Version Bezug genommen