Wie die SAN-Entscheidung ablief

Sich zur Decke strecken zu müssen ist das Los vieler IT-Abteilungen. Die Anforderungen sind noch höher, wenn es wie in Krankenhäusern um einen Betrieb rund um die Uhr geht: 24x7 Stunden müssen medizinisches Personal und sämtliche IT-gestützte Apparaturen für jede mögliche Situation bereit stehen. Ausfälle und zeitliche Verzögerungen kann man sich bei Diagnose, Therapie und in den Notfallstationen nicht leisten.

Auch bei der Stiftung Juliusspital Würzburg, die zu den traditionsreichsten Sozialeinrichtungen Deutschlands zählt, steht die IT-Infrastruktur in dieser Verantwortung. Doch IT-Leiter Joachim Fuchs und seine fünf Mitarbeiter müssen neben dem Krankenhausbetrieb mit über 340 Betten und rund 150 Pflegeplätzen noch weitere Geschäftsbereiche betreuen. Dazu gehören 22 Einheiten für betreutes Wohnen, diverse Immobilien sowie landwirtschaftliche Güter, Waldbesitz im Spessart und nicht zuletzt Deutschlands zweitgrößtes Weingut. Die 1576 gegründete Stiftung Juliusspital profitiert von den so erzielten Einkünften, wird aber dennoch als privatwirtschaftlich organisierte Einrichtung wie andere Krankenhäuser geführt.

Während für einige Geschäftsbereiche Hochverfügbarkeit nur bedingt eine Rolle spielt, muss sie im Krankenhaus auf jeden Fall gewährleistet sein. Man verfiel zunächst auf eine Cluster-Lösung mit Novell Netware 6.5. Sie funktionierte zufriedenstellend, entsprach aber bald nicht mehr der langfristigen strategischen Ausrichtung auf Filer-Produkte von NetApp. Außerdem wollte man die enge Kopplung zwischen Server und Speichergerät beenden und stattdessen einen Ressourcen-Pool in einem unabhängigen Speichernetz aufbauen.

Problem der Anbieterabhängikeit

Spiegelung der Daten als Vorkehrung für den Disaster-Recovery-Fall sollte ebenfalls eine der zukünftigen Funktionen sein. Die Entscheidung für den Aufbau eines SANs mit NetApp-Produkten kam nur bedingt durch technische Überlegungen zustande: Ausschlaggebend war letztlich, dass man im Rahmen von Server-Virtualisierung mit VMware ESX bereits NetApp-Speicher verwendete. Befürchtungen, sich zu sehr an einen einzigen Hersteller zu binden, gibt es bei Fuchs nicht. Er glaubt, NetApp habe gute Produkte und werde deshalb auch noch in einigen Jahren existieren. Gebe es doch irgendwann größere wirtschaftliche Schwierigkeiten des Herstellers, werde man sich eben nach einer Alternative umsehen müssen.

Auf technischer Seite erwähnt Fuchs im Gespräch mit CIO.de Healthcare-IT als weiteres Entscheidungskriterium, dass man im SAN block- und file-basierte Daten zusammen ablegen und verwalten wolle. Nur noch ein System für beide Datenarten soll auch das IT-Team entlasten, da man sich nicht mehr um zwei Geräte und Protokolle kümmern müsse.

SAN, Spiegelung und Virtualisierung

Im Mittelpunkt der geplanten Investition stand der Ausbau des Storage Area Networks (SAN). Fuchs wollte SAN-Lösungen verschiedener Hersteller, die dediziert Applikationen wie dem PACS oder der VMware-Umgebung dienten, auf eine Plattform konsolidieren, um eine skalierbare Basis für den 24/7-Betrieb des Krankenhauses zu schaffen. Um Business Continuity zu gewährleisten, ist das Rechenzentrum auf zwei Standorte verteilt, so dass ein übergreifendes Storage-System ausgeschrieben wurde. Die Spiegelung der Daten zwischen den beiden Standorten sollte autark arbeiten und sich proaktiv selbst überwachen. Mögliche Störungen sollte das System frühzeitig selbst erkennen und lösen, ohne die Anwendungen oder den Server-Betrieb zu beeinträchtigen.

Bevor NetApp als Lieferant für den NetApp SAN Storage mit Metro-Cluster gesetzt war, erwog man noch die Virtualisierungs-Software von DataCore als Alternative. Tests und Gespräche mit anderen Institutionen, die DataCore verwenden, ergaben, dass Implementierung und Bedienung zu komplex und kompliziert für das kleine IT-Team waren. Man hätte einen eigenen Mitarbeiter nur für die Überwachung und Pflege der SAN-Infrastruktur einsetzen müssen.

Schnittstellen fehlen oder sind fehleranfällig

Bei Software für medizinische Anwendungen wie KIS, PACS und anderen klagt der IT-Leiter über die mangelnden Standards in diesem Bereich. Oft sei es wegen der fehlenden Schnittstellen nicht möglich, verschiedene Applikationen mit einander zu verbinden. Wenn es Schnittstellen gibt, sind sie anfällig für Fehler und erfordern viel Nacharbeit.

Laut Fuchs breitet sich der (IT-)Industrialisierungsprozess auch in den Krankenhäusern immer mehr aus: Daten werden direkt nach ihrer Entstehung – zum Beispiel bei der Bilderfassung – in digitale Systeme für Patientendateien oder für Archivierungszwecke überführt. Dafür sind funktionierende Schnittstellen notwendig. Oft seien die Hersteller von Healthcare-Software daran aber nicht besonders interessiert, weil sie ihre eigenen Territorien schützen wollen.

Zudem würden einige von ihnen mehrfach ihre Strategie ändern, ohne Rücksicht auf die Anwender zu nehmen. Als Beispiel nennt er Agfa Healthcare, wo man zunächst ein großes monolithisches Software-System ansteuerte und keinen Wert mehr auf die Integration anderer Systeme legte. Vor ein paar Jahren hat Agfa dann diese Ausrichtung geändert, Firmen hinzugekauft und intern alles neu organisiert. Plötzlich sollte sehr viel mit Partnern gemacht werden.

Strategiewechsel von Agfa Healthcare zu Lasten der Anwender

Die neueste Entwicklung sei, dass Agfa Healthcare jetzt diese Partner kauft und wieder alles intern umbaut. Mit Konsequenzen für die Kunden: Denn der erneute Strategiewechsel führte auch zu radikalen Einschnitten und Umbesetzungen bei den Ansprechpartnern für die Krankenhäuser. Die Leidtragenden sind die Kunden.

Bei den Schnittstellen auf Software-Seite habe sich übrigens nichts zum Positiven geändert, berichtet der IT-Leiter. Nichts passe so richtig zu dem anderen.