Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

Schlechte Beratung und fehlende Produkte waren die Auslöser


16.11.1990 - 

Das Rhön-Klinikum gründete ein eigenes DV-Unternehmen

Auf der Suche nach einer maßgeschneiderten DV-Lösung für Kliniken entschloß sich die Rhön-Klinikum AG zur Selbsthilfe: Sie gründete ein Tochterunternehmen für die eigenständige Entwicklung eines integrierten Krankenhaus-Informationssystems (KIS). Helgi Todtenhaupt* beschreibt, wie das Klinikum auf der Basis eines - 4GL-Systems den gesamten DV-Betrieb umstellte.

Die Rhön-Klinikum AG ist ein privater Krankenhausträger. Am Unternehmenssitz in Bad Neustadt/Saale werden eine Reihe von Kliniken mit unterschiedlichen Aufgabenstellungen betrieben. So gehört die Herz- und Gefäßklinik Bad Neustadt zu den größten Spezialeinrichtungen dieser Art in der Bundesrepublik.

Eine weitere Einrichtung ist die Psychosomatische Klinik mit 320 Betten. Hinzu kommen Rehabilitationseinrichtungen mit zum Teil dedizierten Aufgabenstellungen. Die gesamte Kapazität des Klinikums in Bad Neustadt liegt im Akut- und Rehabilitationsbereich bei etwa 1500 Betten.

Programm muß hohen Anforderungen genügen

Aufgrund der vielfältigen Aufgaben, die von den einzelnen Kliniken zu leisten sind, muß eine DV-Lösung zur Unterstützung des Krankenhausbetriebs sehr hohe Anforderungen an Qualität und Zuverlässigkeit erfüllen, sofern der Anspruch gestellt wird, daß es sich nicht nur um eine Speziallösung für eine Klinik handelt. Aus einer Reihe von Gründen wäre diese Alternative die denkbar schlechteste aller Möglichkeiten.

Unterschiedliche DV-Systeme in den einzelnen Kliniken können bedeuten: Verschiedenartige Hardware, Software und Netzwerke kommen zum Einsatz. Damit würden vertragliche Regelungen für Wartung, Pflege und Dienstleistungen mit diversen untereinander konkurrierenden Unternehmen nötig. Die Schnittstellenproblematik würde sich multiplizieren, und die Begriffswelten und Ausbildungsstände der Mitarbeiter wären unterschiedlich. Kurz gesagt, ein Alptraum sowohl auf der Kosten- als auch auf der DV-technischen und der Management-Seite.

Eine andere Lösung mußte also gefunden werden. Diese konnte nur ein DV-System sein, das sowohl funktional umfassend als auch in hohem Maße durch Laufzeitparameter, also ohne Veränderung des Programmcodes, an unterschiedliche Einsatzumgebungen anpaßbar war. Analysen der Standardsoftware verschiedener Anbieter führten zu dem Ergebnis, daß die geforderten Systemeigenschaften unterentwickelt waren oder teilweise erst gar nicht existierten.

Beispielsweise leiden die auf dem deutschen Markt angebotenen Krankenhaus-Anwendungen in der Regel unter einer "funktionalen Unterversorgung" des Ambulanzbereichs. Da ein - umfassend geeignetes Produkt nicht verfügbar war, entschied sich das Rhön-Klinikum zur Selbsthilfe. Für das Rechnungswesen wurde Standardsoftware und für die Kurkliniken ein speziell für Einrichtungen dieser Art entwickeltes Anwendungspaket eingesetzt.

Für den zentralen Bereich der Patientenverwaltung vergab die Klinik Entwicklungsaufträge mit enttäuschendem Ausgang: Zwei Software- beziehungsweise Beratungsunternehmen scheiterten in den Jahren 1985 und 1986 an der komplizierten und zeitkritischen Aufgabenstellung.

Daraufhin unternahm das Rhön-Klinikum einen mutigen Schritt und gründete ein Tochterunternehmen für die eigenständige Entwicklung von Software - die Wolfgang Schaffer GmbH (WSG) mit einem Entwicklungszentrum in Dietzenbach nahe Frankfurt am Main. Die Aufgabe der WSG bestand in der Entwicklung eines integrierten Kranker Waus-Informationssystems (KIS), das einheitlich in allen Kliniken der Unternehmensgruppe dem Management und den Mitarbeitern die notwendige DV-Unterstützung liefern sollte.

Der verfügbare Entwicklungszeitraum war eng begrenzt. Innerhalb eines Jahres mußten die Verfahren zur Patientenbeibestellung, die in Krankenhäusern mit einem Spezialleistungsspektrum von besonderer Bedeutung sind, zur Patientenverwaltung und Leistungsabrechnung für den Echtbetrieb bereitete. Nach dem Aufbau der Entwicklungs-Infrastruktur im Jahr 1987 lief Anfang 1988 die Entwicklungstätigkeit an.

Uns war klar, daß die gesteckten Ziele, bezogen auf den Zeitrahmen, nicht zu erreichen gewesen wären, solange der gesamte Zyklus der Anwendungsentwicklung von der Analyse über Grob- und Feindesign, Programmierung, Test, Dokumentation und Installation ausschließlich auf der Grundlage einer herkömmlichen Entwicklungstechnologie erfolgen würde. Dazu hätte das Programmieren in einer "klassischen" Programmiersprache wie zum Beispiel Cobol oder das im Gesundheitswesen zum Teil recht beliebte "Mumps" gehört.

Eine der ersten Entscheidungen vor Beginn der eigentlichen Arbeiten war daher, eine Entwicklungsumgebung der 4. Generation so umfassend wie möglich einzusetzen. Ein zentrales Data Dictionary sollte ebenso vorhanden sein wie die Möglichkeit eines "rapid prototyping".

Die Entscheidung der WSG fiel auf die Entwicklungsumgebung "Powerhouse CASE/ADE" des kanadischen Softwarehauses Cognos. Der wichtigste Grund für diese Entscheidung war die funktionale Tiefe, die das Produkt dem Entwickler bietet: Auch schwierige Aufgabenstellungen im Rahmen der Dialogprogrammierung können in der 4GL-Sprache abgewickelt werden, ohne daß auf Code-Teile in einer 3GL-Sprache ausgewichen werden muß - ein nicht zu unterschätzender Vorteil.

Diese Aussage betrifft zum Beispiel folgende Problemstellungen:

- Das Zusammenfügen diverser einzelner Bildschirmmasken zu funktionalen Abläufen (Funktionen) mit der Möglichkeit für den Benutzer, den Dialog an einem beliebigen Punkt abzubrechen, war gefordert. Hierbei ist in der Logik der Anwendung selbst festgelegt, ob Daten in die Datenhaltung des Systems zu überführen sind.

- Darüber hinaus wollte man den Dialogverlauf von jedem Eingabefeld aus unterbrechen können, um mittels spezieller Funktionen in Suchverzeichnissen zu blättern. Dazu gehört auch die Übergabe qualifizierender Argumente an die Suchhilfefunktion und die automatische Rückübertragung selektierter Daten in die Ausgangsfunktion.

- Der Aufbau von Screen-Stacks sollte möglich sein, um die Sprünge von Funktion zu Funktion in beliebiger Tiefe schachteln zu können. Unterstützung beim Aufbau von Bildschirmfenstern wurden genauso gefordert wie automatisches "Repaint bei der Rückkehr auf die vorherige Ebene.

- Das System sollte mehrstufige Help-Aufrufe von jedem Eingabefeld aus automatisch unterstützen.

- Conditional-Compile-Möglichkeiten waren notwendig, um Dialogfunktionen parametergesteuert an eine Installationsumgebung anpassen zu können.

- Einrichtungen zur zeilenweisen Datenpräsentation und -erfassung in feldorientierte Bildschirmmasken sollten beliebig einsteuerbar sein, mit der Chance zum Vorwärts- und Rückwärts-Scrolling.

- Dynamische Dialogsteuerung durch Feldinhalte erschien als sinnvoll.

Unsere 4GL-Sprache erlaubte die Lösung sogenannten Aufgaben im Rahmen der standard mäßig vorhandenen Funktionalität und bot so die Voraussetzung, um die zwei wichtigsten Ziele der Entwicklung von Anwendungssoftware zu erreichen: die zügige Fertigstellung sowie die Schaffung einer einheitlichen Benutzeroberfläche und Bedienerführung, bezogen auf das gesamte entstehende Produkt.

Nach einem Jahr intensiver Entwicklungstätigkeit wurde im Januar 1989 in der Herz- und Gefäß-Klinik und in der Psychosomatischen Klinik in Bad Neustadt der Hauptanwendungsbereich "Patientenverwaltung" zum Echtbetrieb freigegeben. Zuvor, also noch während der Entwicklungsarbeiten, war bereits ein Prototyp installiert worden, der schon in vielen Punkten der Endversion entsprach. Die Akzeptanz bei den Anwendern sollte geprüft und die Gelegenheit, Änderungswünsche und Verbesserungsvorschläge einzubringen, gegeben werden.

Die schnelle Umsetzung aller Vorschläge konnte nur erfolgen, weil durch die Verwendung der 4GL-Umgebung eine relativ hohe Standardisierung und Strukturierung des Codes erreicht wurde. Mit nur zehn Mitarbeitern, die an der eigentlichen Software-Entwicklung beteiligt waren, wäre dies unter Einsatz herkömmlicher Techniken innerhalb des gesteckten Zeitrahmens nicht zu realisieren gewesen.

3GL-Umgebung hatte den Start verzögert

Sprachen wie beispielsweise Cobol lassen dem einzelnen Programmierer nur unzureichende Prototyping-Möglichkeiten.

Dazu hätte mit einer 3GL-Umgebung die Entwicklung allgemeinverbindlicher Standards als Voraussetzung für homogene Programmstrukturen zusätzlich einen erheblichen zeitlichen Vorlauf bedingt. Damit aber wäre der Start für die Anwendungsentwicklung im engeren Sinn frühestens sechs Monate später erfolgt.

Letztendlich wären - wie in so vielen DV-Projekten - bei der Fertigstellung einer Applikation innerhalb eines vorgegebenen Zeitrahmens die Qualitätsansprüche auf der Strecke geblieben. Und in einer 3GL-Umgebung lassen sich solche Fehler bekanntlich kaum wiedergutmachen.

Im Laufe des Jahres 1988 haben wir mit unserer Entwicklungsumgebung mehr als 1000 Programme erstellt - ein, Programm ist dabei ein selbständig kompilierbarer Codeblock. Die gesamte Benutzeroberfläche, also alle Dialogprogramme, die Hunderte von Anwendungsfunktionen repräsentieren, wurden mit unserer Anwendungsentwicklung-Umgebung implementiert.

Ein weiterer Vorteil lag darin, ein neu zusammengestelltes Team von Entwicklern, die zuvor mit unterschiedlichen Techniken gearbeitet hatten, auf eine einheitliche Ebene zu bringen. Unsere Entwicklungsumgebung war für alle Beteiligten neu. Erfahrungen mit 4GL-Werkzeugen hatten nur wenige Mitarbeiter. Die gemeinsame Erarbeitung der neuen Technologie erwies sich daher durchaus als ein Produktivfaktor.

Damit soll jedoch nicht ausgedrückt werden, daß 4GL-Sprachen "einfach" sind. Solange leichte Probleme zu lösen sind, können diese Sprachen schnell erlernt und angewendet werden. Die Lösung schwieriger Probleme ist mit 4GL-Tools jedoch sicherlich nicht einfacher als mit den herkömmlichen Methoden. Im Gegenteil: Der Lösungsweg gestaltet sich oft schwieriger, da die Einhaltung der strukturierten Vorgehensweisen in höherem Maße durch die Syntax der Sprache erzwungen wird als in 3GL-Umgebungen.

Umfangreiches Anwendungssystem

Heute sind drei Jahre vergangen, seitdem der Startschuß zur Entwicklung des integrierten Krankenhaus-Informationssystems WSG-KIS fiel.

1988 wurde das Kernsystem für die stationäre Patientenverwaltung und Leistungsabrechnung (WSG-PAT) geschaffen, Anfang 1989 der Echtbetrieb in der Herz- und Gefäß-Klinik und der Psychosomatischen Klinik in Bad Neustadt aufgenommen. Anwendungen für den Bereich Materialwirtschaft/Apotheke und medizinische Geräteverwaltung (WSG-MGV) kamen hinzu.

Aus dem WSG-PAT-Kernsystem entstand in den folgenden zwei Jahren in enger Zusammenarbeit von Klinikmitarbeitern und der Software-Entwicklung ein umfangreiches Anwendungssystem, das heute unter anderem folgende Applikationen umfaßt:

- Einbestellwesen für ambulante und stationäre Patienten,

- integrierte Patientenverwaltung für ambulante und stationäre Behandlungsfälle,

- patientenorientierte Leistungs- und Diagnoseerfassung,

- automatische Leistungsprüfung und -bewertung,

- Leistungsabrechnung für den ambulanten Bereich auf der Grundlage aller denkbaren Abrechnungsarten und Gebührenordnungen mit Regelwerksprüfungen,

- Info-Dialoge, Berichtswesen und Statistik zur Unterstützung der leitenden Mitarbeiter aller Ebenen,

- automatisierte Korrespondenz mit Patienten, Ärzten und Kostenträgern,

- Generierung von Daten auf der Grundlage des Leistungsgeschehens und der Abrechnungsvorgänge zur automatischen Überführung in die DV-Anwendungen des Rechnungswesens.

Auch die infrastrukturelle Software wurde erweitert. WSG-PAT ist mandantenfähig, das heißt, im Rahmen einer Installation können mehrere Krankenhäuser bedient werden. Eine parametrisierbare Schnittstellensoftware erlaubt die Kommunikation mit Abteilungssystemen (medizinischen Subsystemen) unterschiedlichster Art.

Dabei kann eine große Zahl vielgestaltiger Schnittstellen parallel zueinander bedient werden. Die zu übertragenden Daten werden durch - von der eigentlichen Anwendung abgesetzte Serverprogramme in das vom jeweiligen Fremdsystem erwartete Format umgesetzt und auf der Grundlage des vom Fremdsystem vorgegebenen Protokolls übertragen.

Im Herbst 1989 erfolgte die nächste Installation in Bad Neustadt, die einen Komplex von fünf Kliniken des Kur- und Rehabilitationsbereichs bedient. Damit wird WSG-PAT in insgesamt sieben Kliniken in Bad Neustadt eingesetzt.

Die Bandbreite reicht von der Herz- und Gefß-Klinik, in die Notfälle auch mit dem Hubschrauber eingeflogen werden, bis zur Therapieeinrichtung für Suchtkranke mit Langzeitaufenthalt.

Follpauschale als Bewährungsprobe

Eine wichtige Bewährungsprobe für WSG-PAT stellte im April 1990 die Umstellung der Abrechnungsprozedur vom allgemein üblichen Pflegesatzverfahren auf Fallpauschalen dar: Die jeweils korrekte Fallpauschale mußte durch die Abrechnungssoftware unter Auswertung des Leistungsaufkommens automatisch generiert werden. Diese, Aufgabe ließ sich aufgrund der bereits auf eine Vielzahl von Abrechnungsverfahren vorbereiteten Programmstruktur lösen. Auch das entscheidungsorientierte Berichtswesen wurde kurzfristig auf die völlig unterschiedliche Kennzahlenstruktur umgestellt.

Während des gesamten Entwicklungsprozesses der WSG-KIS-Anwendungen stand der Gedanke im Vordergrund, nicht nur die Kliniken der eigenen Unternehmensgruppe mit der bestmöglichen DV-Lösung zu versorgen, sondern zugleich ein marktorientiertes Produkt zu entwickeln. Die Voraussetzungen dafür waren günstig. Die Verschiedenheit der zur Rhön-Klinikum AG gehörenden Kliniken stellte sicher, daß keine hausspezifischen Speziallösungen erzeugt wurden.

Die funktionale Reife und die bewiesene Stabilität des Produktes ermöglicht heute eine Marktoffensive. WSG-KIS steht am Anfang des Lebenszyklus, der für jedes Produkt gilt. Das umfassend angelegte Design zusammen mit einer modernen Softwaretechnologie auf 4GL-Basis bilden die Voraussetzung für eine kontinuierliche Weiterentwicklung in der Zukunft. Unter dem Stichwort "leistungsorientierte Kommunikation" befinden sich neue Applikationen in der Entwicklung, die hauptsächlich den ärztlichen und pflegerischen Bereich unterstützen.

Ein Problem stellte sich jedoch unabhängig von den funktionalen Aspekten. Die Entwicklungstätigkeit in den Jahren 1988 bis 1990 war auf Rechnern der MV-Eclipse-Familie von Data General erfolgt.

Der Markt verlangt noch Unix-Anwendungen

Neben den VAX-Rechnern von DEC und den Midrange-Systemen von Hewlett-Packard gehörten die MV-Eclipse-Rechner zu den Standard-Plattformen, für die das 4GL-System zur Verfügung stand.

Auch die Installationen in den Kliniken der Rhön-Klinikum AG erfolgten auf Rechnern dieser Familie. Derzeit sind die Modelle MV/10000, MV/20000 und MV/40000 im Einsatz und haben sich als leistungsstarke und zuverlässige Plattformen erwiesen.

Der Markt verlangt jedoch in zunehmendem Maße Anwendungen, die unter Unix ablauffähig sind. Die Schaffer GmbH entschloß sich zu einem Portierungstest. Cognos hatte in der Zwischenzeit Powerhouse auf der RISC-Rechnerfamilie HP9000 unter HP/UX implementiert.

Im Herbst 1990 konnte ein Team von Mitarbeitern der WSG, der Cognos GmbH und von Hewlett-Packard die Applikation "Medizinische Geräteverwaltung" auf Unix umstellen und auf einem HP-9000-Rechner installieren.

Portierungstests dauern zwei Tage

Die Anwendung besteht aus 275 Powerhouse-Programmen. Der Portierungstest dauerte zwei Tage. Am Abend des zweiten Tages war die Anwendung von funktionsfähig. Das auf einem Data-General-Rechner erstellte Data Dictionary, in dem alle Felddefinitionen und Datenstrukturen der Anwendung dargestellt sind, hatte sich ohne große Schwierigkeiten in unser neues relationales Datenbanksystem laden lassen.

Auf dem Data-General-Rechner war die Applikation zuvor unter Verwendung des Standard-Dateiverwaltungssystems Infos II von Data General abgelaufen. Die 4GL-Programme konnten nach Re-Compilierung auf die neue Datenbank zugreifen. Als Konsequenz dieser Studie beschloß die WSG, das Gesamtsystem WSG-KIS auf Unix umzustellen und somit der Forderung des Marktes nach offenen Systemen Rechnung zu tragen.