Krankenversicherung reduziert Zahl der nationalen Rechenzentren

Heterogene Umgebung der AOK integriert FTAM-UEbertragung

16.02.1996

Die AOK betreut mit etwa 70000 Mitarbeitern rund 30 Millionen Versicherte. Die DV-Unterstuetzung der Mitarbeiter basierte in der Vergangenheit auf BS2000-, MVS- und VSE-Umgebungen, die auf ueber 60 Rechenzentren verteilt waren. Mit der Verpflichtung, die DV-Strukturen den akutellen Anforderungen anzupasssen, hat die AOK damit begonnen, Client-Server-orientierte Struktur zu entwickeln. Damit einher geht die Reduzierung von ehemals 270 rechtlich selbstaendigen AOK-Niederlassungen auf jeweils eine AOK pro Bundesland. In den letzten drei Jahren hat die AOK die Anzahl ihrer Rechenzentren auf rund 25 reduziert, letztlich soll nur noch eine IT-Zentrale pro Bundesland betrieben werden.

Die Konzentration von Rechenzentren und der Aufbau von Client-Server-Strukturen unter Beibehaltung proprietaerer Welten erstreckt sich nicht nur auf die Kopplung interner LANs, Unix- und Mainframe-Systeme (MVS, BS2000, AIX, Sinix, Novell Netware 3.11 und 4.1, Windows NT sowie SAP R/3). Sie umfasst auch den elektronischen Datenaustausch mit Partnern und den Aufbau eines Corporate Network.

Ein derartig komplexes Vorhaben laesst sich nur realisieren, indem zunaechst Teilprojekte behandelt werden. Dabei haben sich folgende Planungsschritte herauskristallisiert:

1. Standardisierter Datenaustausch zwischen den Rechenzentren der AOK und den Partnern. Dies wird bereits praktiziert und ist Gegenstand der weiteren Ausfuehrungen.

2. Ausdehnung der E-Mail-Anwendungen in den einzelnen Organisationseinheiten auf die gesamte AOK mit X.400 und X.500.

3. Parallel zu diesen Aktivitaeten wird die AOK ein Corporate Network aufbauen, um alle Netzfunktionen ueber ein einheitliches physikalisches Netzsystem abwickeln zu koennen.

4. Die OEffnung der AOK-Netze gegenueber oeffentlichen Netzen wird derzeit diskutiert. Neben Sicherheitsaspekten sind dabei Fragen der strategischen Ausrichtung zu beruecksichtigen: Inwieweit ist etwa die Vernetzung mit Versicherten sinnvoll?

Die AOK unterhaelt schon seit geraumer Zeit vernetzte Systeme fuer die Datenfernuebertragung. Diese Installationen waren jedoch nicht nur teuer und komplex. Sie hatten zudem den entscheidenden Nachteil, dass sie - von Ausnahmen abgesehen - nur innerhalb proprietaerer Herstellerwelten funktionierten. Die flexible Vernetzung mit anderen Partnersystemen war haeufig unmoeglich beziehungsweise unwirtschaftlich.

1992 etablierte sich aber eine Arbeitsgruppe aus Vertretern der Spitzenverbaende der gesetzlichen Krankenversicherungen und der Arbeitsgruppe fuer wirtschaftliche Verwaltung e.V. (AWV). Gegenstand der Diskussion war es, den Datentraegeraustausch zwischen Arbeitgebern und Krankenkassen mittels eines standardisierten DFUE-Verfahrens mit hoher funktionaler Sicherheit sowie maximalem Datenschutz zu etablieren.

Die Frage des einzusetzenden Standards eruebrigte sich mit der Veroeffentlichung des European Procurement Handbook for Open Systems (Ephos) der EU. Dieses europaeische Beschaffungshandbuch fuer offene Systeme verpflichtete die DV-Anwender in oeffentlichen Verwaltungen zur Verwendung von Produkten, die den Standards X.400 und FTAM entsprechen (siehe Tabelle).

Die Arbeitsgruppe entschied sich rasch fuer File Transfer Access and Management (FTAM), weil die Anforderungen der Spitzenverbaende weniger dem Dokumentenaustausch als dem klassischen File-Transfer entsprachen. Zudem lassen sich Security-Komponenten, Verschluesselungsmechanismen und elektronische Unterschriften in FTAM besser als in X.400 integrieren.

In einem weiteren Schritt verstaendigte sich die Arbeitsgruppe auch auf eine DFUE-Anwendung, um jedem Anwender einheitliche, korrespondierende Funktionen zur Verfuegung zu stellen. Die Arbeitgeber sollten also problemlos Daten mit der AOK und anderen Krankenkassen austauschen koennen. Weil FTAM allerdings nicht die Automatisierung der Verfahren und der Security-Komponenten regelt, schuf die Gruppe einen Quasistandard mit folgenden Funktionen: Auftragssaetze (auch Lieferscheine genannt) sollten den Datentransport unabhaengig von Format, Satzaufbau, Verschluesselung, Codierung oder Komprimierung automatisieren. Die DFUE-Anwendung erhaelt also immer ein Dateienpaar (Auftragssatz- und Nutzdatendatei). Namenskonventionen bezeichnen die Auftragssaetze, so dass die Anwendung die Daten dementsprechend selbsttaetig bearbeiten kann. Sicherheitsverfahren und Komprimierung werden automatisch beruecksichtigt.

Die Arbeitsgruppe entwickelte ein offenes DFUE-System mit der Bezeichnung Krankenkassen-Kommunikations-System (KKS), in das auch zukuenftige Anforderungen integriert werden koennen. Erstellt wurde die Anwendung von der Duesseldorfer Firma Coconet.

Bei der Ausgestaltung der Detailfunktionen achtete die Arbeitsgruppe darauf, keine FTAM-Add-ons der am Projekt beteiligten Firmen, sondern nur Standards zu verwenden. Ein erster Einsatz des KKS erfolgte in einem Pilotprojekt bei der Lufthansa und wurde bereits erfolgreich abgeschlossen. Mittlerweile nutzen weitere Arbeitgeber das KKS fuer den Datenaustausch mit Herstellern der AOK-Chipkarten. Das Verfahren bildet auch die Basis fuer den Datenaustausch mit dem Verband der Rentenversicherungstraeger (VDR), eine Versuchsinstallation mit der Bundesversicherungsanstalt fuer Angestellte wird derzeit vorbereitet.

Waehrend der Entwicklung des KKS fuer die Arbeitgebervernetzung ergab sich eine weitere Anforderung an die gesetzlichen Krankenkassen: Der Gesetzgeber verlangte einen maschinell lesbaren Datenaustausch zwischen Leistungserbringern wie AErzten, Krankenhaeusern oder Optikern und den Krankenkassen. Daraufhin wurde beschlosen, die Funktionalitaet des KKS auf den Datenaustausch mit Leistungserbringern auszuweiten.

Hier erwartet die AOK aufgrund der Vielzahl der Partner ein Datenaufkommen von etwa 9000 MB und ungefaehr 4000 Transaktionen pro Monat. Diese Schaetzwerte koennen allerdings nicht beruecksichtigen, in welchem Ausmass die Daten ueber herkoemmliche Datentraeger oder via DFUE uebermittelt werden. Vermutlich wird das Gros der Partner wegen der funktionalen und wirtschaftlichen Vorteile auf die DFUE zurueckgreifen.

Grundsaetzlich gibt es in der AOK die Forderung, alle praktikablen Sicherheits-Komponenten auch zu verwenden. Zur Zeit praktiziert die AOK unter anderem die Verschluesselung und die elektronische Unterschrift. Der Einfachheit halber wird auch die Komprimierung im Security-Block abgehandelt. Diese Verfahren kommen sowohl bei der Arbeitgebervernetzung, als auch bei der Vernetzung mit Leistungserbringer zum Tragen (siehe Abbildung 1).

Obwohl die Security-Komponenten nicht standardisiert sind, ergab sich fuer die Leistungserbringer-Vernetzung die Forderung nach einer Kommunikationsmoeglichkeit zwischen den Loesungen der unterschiedlichen Hersteller. Mit diesem Problem ist die AOK an die Softwarelieferanten herangetreten. Diese definierten in der Folge eine offene Standard-Schnittstelle.

Dennoch sind noch nicht alle Probleme im Sicherheitsbereich geloest. Neben der Handhabung der Partnerdaten ist die Verwaltung der Partnerschluessel noch zu klaeren. Im Normalfall wird mit der KKS-Anwendung einmal das Schluesselpaar erstellt. Der private Code wird im Computersystem abgelegt, wogegen die frei zugaengliche Version bei jeder AEnderung an alle angebundenen Partner uebertragen wird. Um dennoch das Verfahren der Schluesselversendung an alle Partner zu vermeiden und die eindeutige Zuordnung von Partner und Schluessel (Zertifizierung und Authentifizierung) moeglichst einfach zu gestalten, hat die AOK-Gemeinschaft ein Trust-Center bei Coconet eingerichtet. Dorthin wird der oeffentliche Schluessel nur einmal per FTAM uebertragen. Angeschlossene Partner koennen die Codes dort abrufen. Ziel ist es, diese Trust-Center-Funktionalitaet auf der Basis von X.500 (Directory-Services) und X.509 (Key-Management) aufzubauen.

Bereits bei der Planung des Arbeitgeber-KKS beruecksichtigte die AOK die elektronische Softwareverteilung. Neben Funktionen zur Programmauslieferung sollte das System auch im Fehlerfall schnellstmoeglichst Bereinigungen in die Rechenzentren einspielen koennen. Ein weiterer Vorteil dieser Pilotierung bestand darin, bestehende Verfahren des Programmversands parallel weiterbetreiben zu koennen. Probleme bei der Abwicklung des Pilotbetriebs sollten sich zudem nur AOK-intern auswirken.

Fuer die KKS-Nutzung durch Leistungserbringer und Arbeitgeber wurde der Programmversand mit einer Benutzeroberflaeche und einem Auftrags-Manager ausgestattet. In einer ersten Stufe wurden diese Komponenten mit der Vorgabe auf einem dedizierten Windows-System (ISDN-S0-Anschluss) installiert, um bei steigendem Bedarf mehrere Windows-Systeme und Unix-Systeme (mit ISDN-S2M-Anschluss) einsetzen zu koennen(siehe Abbildung 2).

Da mit FTAM nicht nur Daten versendet, sondern auch zum Abholen bereitgestellt werden, hat der AOK-Bundesverband die auszuliefernden Programme auf einen Server uebertragen, wo sie bereitliegen. Mittlerweile ist das Projekt soweit gediehen, dass erwogen wird, die traditionellen Versendungsformen aufzugeben.

Die Erfahrungen der AOK verdeutlichen, dass ein vollstaendig beschriebenes Verfahren wie das KKS problemlos in Betrieb zu nehmen ist. Alle anderen Implementationen muessen hingegen durch Definition einer Prozesskette spezifiziert werden. Einer Organisation wie der AOK eroeffnen sich durch schnellen Datentransfer enorme Verbesserungen bei der Markt- und Kundenorientierung. In einem zweiten Schritt gilt es nun, die interpersonelle Kommunikation durch ein E-Mail-System auf die gesamte AOK auszuweiten.

*Gerd Wolter ist Produkt-Manager beim AOK-Bundesverband in Koeln.

Erfahrungen der AOK mit FTAM

1.In grossen Organisationen existieren immer unterschiedliche Ziel- und Wertvorstellungen, die ein einheitliches Vorgehen erschweren. Die funktionale Sicherheit von DFUE-Verfahren steigt jedoch mit ihrer Einheitlichkeit.

2.Das gesamte in der AOK-Gemeinschaft vorhandene DFUE-Know-how laesst sich buendeln. Die muendliche Kommunikation in Fehlerfaellen wird dadurch wesentlich vereinfacht; Verbesserungen koennen leichter auf das Gesamtsystem uebertragen werden.

3.Aufgrund der preislichen Gestaltung von Client-Server-Loesungen scheiden Mainframe-Alternativen aus.

4.Die ersten Schritte mit FTAM sind meist sehr einfach und erfolgreich. Probleme treten haeufig bei der Umsetzung von Kleinigkeiten auf. Wichtig ist es, zu etablierende Verfahren vom Quell- bis zum Zielsystem inklusive der Anwendungen vollstaendig zu beschreiben und zu testen.

5.Viele Schwierigkeiten entstehen durch die Orientierung an Client-Server-Strukturen. Die Zusammenfuehrung von heterogenen Welten sorgte bei der AOK fuer interdisziplinaer zu loesende Probleme.

6.Vor diesem Hintergrund wurde ein Prozesskettenfragebogen entworfen, der fuer jeden Datenuebertragungstyp beantwortet werden muss. Dort werden beispielsweise Partner mit ihren Durchwahlnummern, Ansprechpartner in den Fachabteilungen, Quell- und Zielsysteme, Konvertierungen, Security-Komponenten sowie UEbertragungszeiten aufgelistet.

7.Fuer Mitarbeiter, die sich mit diesen Verfahren nicht auskennen, sollte eine Anlaufstelle eingerichtet werden.

8.Die UEbertragung zwischen den FTAM-Systemen sollte grundsaetzlich binaer erfolgen, Konvertierungen sind moeglichst erst in Zielsystemen vorzunehmen.

9.Die Datenmengen sollten nicht nur wegen der ISDN-Kosten, sondern auch wegen der Dauer der Anschlussbelegung beobachtet werden.

Kurz & buendig

Nach anfaenglichen UEberlegungen, fuer die DFUE-Vernetzung mit Partnern X.400-Dienste einzusetzen, entschied sich die AOK letztlich fuer FTAM, da die Ansprueche mehr dem reinen File-Transfer als dem Dokumententransfer entsprachen. FTAM beinhaltet allerdings keine Sicherheitsverfahren, so dass die AOK mit Partnern entsprechende Erweiterungen kreierte. Ergebnis ist ein offenes DFUE-System, in das sich weitere Anforderungen integrieren lassen.