Patientendaten sicher speichern
Patientendaten sicher speichern. Das ZSP (Zentrum für soziale Psychiatrie) Bergstraße musste dringend seine Speicherprobleme lösen. Im Vordergrund standen dabei Hochverfügbarkeit, Flexibilität und ein gutes Preis-Leistungsverhältnis.

- Patientendaten sicher speichern
- Patientendaten sicher speichern (Fortsetzung)
Patientendaten sicher speichern
Krankenhäuser haben wegen der Digitalisierung von Patientendaten mit immer größeren Datenmengen zu kämpfen. Zur Verwaltung der Daten aus Patientenpflege, Monitoring, Fort- und Weiterbildung sowie dem Informationsmanagement reichen die vorhandenen Kapazitäten oft nicht mehr aus. Spezialapplikationen wie das Krankenhausinformationssystem (KIS) machen das Datenmanagement immer aufwändiger und benötigen sehr viel Speicherplatz. Zudem müssen Patientendaten, das Kapital einer jeden Klinik, hochverfügbar und entsprechend der geltenden Schutzbestimmungen sicher gespeichert werden. Angesichts des wachsenden Kostendrucks wird deshalb eine effiziente und kosteneffektive Speicherverwaltung immer wichtiger.
Die Klinik für Psychiatrie und Psychotherapie, Zentrum für soziale Psychiatrie Bergstrasse entschied sich deshalb für einen grundsätzlichen Umbau der Speicherarchitektur. Eine schlichte Erweiterung des Speichers erschien auf Dauer angesichts der bei Einführung der Gesundheitskarte nötigen Kapazitäten nicht sinnvoll. Man suchte nach einem Weg, den administrativen Aufwand und die Kosten für Speicher so gering wie möglich zu halten.
Engpässe bei Verfügbarkeit und Performance
In den Jahren 2002 bis 2004 beschäftigten die IT-Abteilung des ZSP Bergstrasse auch kontinuierliche Kapazitätsengpässe. In der Direct Attached Storage- (DAS-) Speicherarchitektur stießen einzelne Server, beispielsweise Exchange-Anwendungen, permanent an Auslastungsgrenzen, während anderswo freie Kapazitäten ungenutzt blieben. Zudem waren die Ausfallzeiten hoch: So dauerte das Nachrüsten von Plattenkapazitäten in den Servern inklusive der Aus- und Einlagerung der Daten und dem Wiederanlauf des Systems bis zu neun Stunden. Ein planmäßiger Ausbau mehrerer Server legte die Klinik damit für ein ganzes Wochenende lahm. Solche Ausfallzeiten sollten zukünftig vermieden werden.
Mit einer dezentralen Speicherverwaltung war dies allerdings nicht möglich. Denn Datensicherung, Erweiterungen des Speichers und die alltägliche Datenverwaltung waren kompliziert, fehleranfällig und teuer. Deswegen galt es, bezahlbare Wege zu einer Konsolidierung der Speicherarchitektur zu finden.
Sie sollte hochverfügbar und ausfallsicher sein, die Kontinuität der Geschäftsprozesse garantieren, den administrativen Aufwand verringern und natürlich möglichst geringe Kosten verursachen. Die Kostenfrage stellt sich dabei nicht bezüglich der Anschaffung. Ausfallzeiten für die Implementierung und Wartung, Schulung des IT-Personals und viele anderen Faktoren fließen in die Berechnung der Gesamtkosten ein. Dabei entpuppt sich manches vermeintliche Schnäppchen als teuer: So wurde dem ZSP die günstige Übernahme einer »gebrauchten« SAN-Anlage angeboten, allerdings im Verbund mit einem Wartungsvertrag, der den Neupreis der Komplettanlage bei einem Lebenszyklus von 5 Jahren um Etliches überschritt. Für das ZSP war das inakzeptabel.
An der Ausschreibung beteiligten sich mehrere Anbieter mit SAN- und NAS-Lösungen. So wurde HP Compaq-Hardware in Kombination mit dem Veritas Volume Manager als Komplettlösung offeriert. Diese Lösung befand die IT-Abteilung allerdings als zu kompliziert und im Preis-/Leistungsverhältnis unangemessen. Hardwarebasierte Lösungen von EMC und HP Compaq schieden aufgrund der hohen Kosten und der unerwünschten Herstellerbindung aus.
Entscheidungskriterium Herstellerunabhängigkeit
Der Integrator Cema, der bereits mehrere Projekte in der Fachklinik erfolgreich betreut hatte, legte ein Angebot vor, das die Virtualiserungsplattform Sanmelody und Dell-Hardware kombinierte. Die gewünschte Hardware-Unabhängigkeit war für das ZSP Bergstrasse letzten Endes das ausschlaggebende Argument, sich für diese Offerte zu entscheiden.
Die Virtualisierungssoftware wird auf einen Windows-Server aufgespielt. Sie verteilt als zentraler Disk Server die Speicherkapazität dynamisch und automatisch über iSCSI oder Fibre Channel an alle ans Netz angeschlossenen Systeme. Da die Disk Server in der Regel redundant ausgelegt werden, können Speichererweiterungen bei laufendem Betrieb vorgenommen werden. Ein Bündel von Hochverfügbarkeitsfunktionen rundet die Lösung ab. Sie ist in mehreren Leistungsvarianten für unterschiedliche Unternehmensgrößen erhältlich.
Auf Empfehlung von Cema wählte ZSP Sanmelody in der Kategorie C für maximal 32 Speicherplatten oder 12 TByte Kapazität, iSCSI- und FC-Targets sowie acht Netzwerkverbindungen pro Sanmelody-Maschine. Dazu kamen die Optionen Snapshot, High Availability (Spiegelung) und Autoprovisioning. Die Software wurde auf zwei Dell-Standardservern unter Windows Server 2003 auf zwei internen Platten mit jeweils 36 GB im RAID-1-Verbund installiert. Dazu kommen 2 TByte Netto-Festplattenkapazität in einem Dell-Speichersystem. Die beiden Sanmelody-Diskserver sind über Fibre Channel-Switches (Qlogic SAN Box 5200) mit je 16 Ports über Kreuz verbunden, um Ausfallsicherheit zu gewährleisten.
Gleichzeitig modernisierte die Klinik auch auf Dell Poweredge 1750 mit 2 GByte Hauptspeicher als Applikationsserver um. Auf den Servern laufen neben File, Mail- und Print-Services vor allem Datenbanken, darunter Exchange 2003 und MS SQL 2000 unter Windows-Betriebssystemen. 14 dieser Maschinen werden heute zentral mit Storage versorgt. Als Anwendungen nutzt das ZSP Bergstrasse. Das KIS (Krankenhausinformationssystem), das sämtliche Patientendaten verwaltet, läuft unter Sun Solaris 9 auf einem Fujitsu-Siemens Prime Power-Rechner.
Bei der Integration der Solaris-Maschine in das Sanmelody-SAN traten kleine Probleme auf. Grund war eine fehlerhaft konfigurierte FC-Karte. Mit der korrekten Konfiguration der Karte waren sie behoben. Eine bei dieser Gelegenheit durchgeführte Performance-Messung ergab, dass der über die Software angebundene Speicher etwa doppelt so schnell war wie die integrierten Speicherplatten des Servers.