Digithurst

Stimmt ein Patient der unverschlüsselten Weitergabe seiner digitalen Krankheitsdaten, zwecks Weiterverarbeitung, zu (was bleibt ihm im Krankenhaus manchmal anderes übrig?), ist Stand heute eine Speicherung dieser Daten unverschlüsselt auch außerhalb der Gesundheitseinrichtung erlaubt. Dabei muss gar nicht dem die Daten weiterverarbeitenden Unternehmen unlautere Absicht bei der Datenbehandlung unterstellt werden. Vielmehr besteht das (unnötige) Risiko, dass das Unternehmen selbst Gegenstand krimineller Angriffe wird (Diebstahl der Hardware, Hackerattacken) wird. Selbst bei juristisch einwandfreien Vorgängen, wie bspw. der Beschlagnahme der Hardware des Dienstleisters wg. eines seinerseits möglichen Zahlungsverzugs, gelangen unverschlüsselte Daten, mit hoch sensiblen Inhalten, in „falsche“ Hände. Muss das sein?

Setzt gerade in der heutigen Zeit hier nicht auch die Verantwortung der Industrie ein? Sind dort nicht die Spezialisten, denen durchaus Technologien zur Verfügung stehen, die eine nachhaltige Verschlüsselung der Daten ermöglichen? Sollte sie nicht zumindest auf solche Möglichkeiten hinweisen? –oder sogar freiwillig solche Lösungen entwickeln und anbieten?

Der Schutz sensibler Daten, gerade von kranken Menschen, ist nicht nur Aufgabe der Politik, er geht alle an – besonders die, die in diesem Bereich Geld verdienen.

Management und Krankenhaus und eHealthCom berichten im Februar über die Cloud in der Medizin. Was ist eigentlich Cloud Storage?

Begriff
Cloud Computing und in diesem Zusammenhang auch Cloud Storage beschreiben zunächst erst einmal integrierte Hard- und Software Technologien, die zusammen eine generell verfügbare Storagelösung versprechen, welche überall dort erreichbar ist, wo es Internet gibt. Der Zugang zu unbegrenztem Speicherplatz via Inter- oder Intranet macht den Hauptunterschied zu traditionellen Storagelösungen (NAS, SAN) aus.

Merkmale
Verteilte Datenhaltung ist ein wesentlicher Bestandteil des Cloud Storage. Dabei geht dieses Datenhaltungsmodell idR. jedoch über die bekannte Replikation von traditionellen Speicherlösungen für den Fall des Disaster Recoverys hinaus, da auch Zugriffe auf die Datenbestände verteilt werden können und somit eine Bandbreitenoptimierung möglich wird.

Skalierung bedeutet in der Storage Cloud nicht nur die theoretische Möglichkeit Speicher unbegrenzt auszubauen. – Speicher ist in der Cloud unbegrenzt!
Skalierung beinhaltet jedoch auch die Möglichkeit, nur den Speicher gerade zu nutzen und damit auch zu bezahlen, der gegenwärtig benötigt wird. D.h., man muss heute kein 20 TB Raid kaufen, nur weil man diese Datenmenge vielleicht in 4 Jahren benötigt.

Traditionelle Storageerweiterungen sind gut und sorgfältig zu planen. Bei der Storage Cloud sind technologische Erwägungen einer Storageaufrüstung überflüssig; Fragen der Kompatibilität bedeutungslos. Egal, ob 10 TB oder 1000 TB gemanagt werden müssen, für den Anwender macht es keinen Unterschied. Storage kommt aus der Steckdose.

Aus Anwendersicht wächst die Speicherkapazität selbständig. Technologiesprünge kennt er nicht, die Leiden der Migration bleiben ihm erspart.

Modelle des Cloud Storage
In der Praxis sind vorrangig 3 Modelle der Storage Cloud anzutreffen.

Das reine Dienstmodell (Storage as a Service):
In diesem Fall bekommt der Anwender von einem Dienstanbieter (Betreiber) Software (ggf. auch Hardware und Dienstleistung) zur Verfügung gestellt, um via Internet oder Intranet seine Daten, idR. gegen eine monatliche Gebühr, abzugeben zu können. ( Null-Investmodell). Betriebsbereitschaft kann innerhalb eines Tages hergestellt werden. Beispielhaft für dieses Dienstmodell ist in Deutschland die Firma Telepaxx Medical Archiving.

Das Software Modell:
In diesem Fall haben sich Firmen darauf spezialisiert, Software zu entwickeln, die es dem Anwender ermöglicht, bei Verwendung eigener Hardware, eine eigene Cloud Infrastruktur aufzubauen (privat cloud). Die Softwarehersteller sind nicht die Betreiber der Speicherlösung.

Das Bundle Modell:
Dieses wird häufig von den großen Herstellern von Storagehardware angeboten. Zusammen mit ihrer Hardware bieten sie dem Anwender Speichermanagement Software und auch Dienstleistungen als Turn-key-ready privat cloud Lösung an. Solche Lösungen sind bei IBM, HP, EMC und Fujitsu zu finden.

Privat oder Öffentlich
Hinter diesen beiden Begriffen findet man die Unterscheidung hinsichtlich der Lokalisation der Storage Cloud.

Public wird die Cloud genannt, bei der die Anwender ihre Daten außer Haus geben. Die Public Cloud ist das klassische Modell der Speicherdienstanbieter. Der Public Cloud haftet der Mythos der Datenschutz-Unsicherheit an. Nicht immer berechtigt, wie die Firma Telepaxx mit ihrem Datenschutzgütesiegel geprüften Medizinischen Archiv beweist. Verlässlicher Datenschutz ist möglich – aber sehr aufwändig!

Unter Private Cloud versteht man Cloud Storage, der sich beim Anwender selbst , also innerhalb seiner Firewall-Hoheit, befindet. Hier ist der Datenschutz wesentlich einfacher, jedoch ist eine komplette Cloudlösung mit nicht zu unterschätzenden Investitions- und Betriebskosten (Sicherheit, Strom, Klima, etc.) verbunden.

Fazit
Cloud Storage ist bereits Realität. Besonders in der Medizin mit seiner ungeheuren Bildflut haben sich Cloudlösungen bewährt. Dieses zeigen Firmen wir Insite One und Bycast in den USA oder Telepaxx in Deutschland und Europa.

Jahrelang war PACS ein Synonym für die Anzeige und Archivierung von digitalen Bilddaten in der Radiologie. Mit der Bezeichnung „Beyond PACS“ will man sich dem erweiterten Speicherbedarf anderer bilderzeugender Modalitäten zumindest begrifflich nähern. Fachgebiete, wie die Kardiologie, Endoskopie, Sonographie, OP-Dokumentation, Strahlentherapie, Partikeltherapie oder Pathologie erzeugen ebenfalls medizinisch relevante Bilder – uns zwar zum Teil deutlich mehr als die Radiologie. Krankenhäuser sprechen in diesem Zusammenhang häufig von Enterprise Imaging. Die verlässliche Archivierung all dieser Bilddaten stellt eine große Herausforderung für die Zukunft dar.

Ist das PACS der richtige Ort, um all diese (Bild-)Informationen zu archivieren? Oder kommt es in Zukunft mehr und mehr zur Abspaltung der Archivfunktion vom PACS?

Sollte das PACS der Zukunft sich nicht eher zu einem benutzerfreundlichen, hoch spezialisierten „Werkzeugkasten“, fein abgestimmt auf die exakten Bedürfnisse seiner Anwenderfachrichtung, entwickeln und somit in erster Linie ein Viewing- und Bildmanagementwerkzeug sein? Klingt mir plausibel. PACS – Hersteller sind nun mal (bis auf ganz wenige Ausnahmen) keine Archivspezialisten.

Aufgrund nicht abreißender Nachfrage, nochmals eine Kurzabhandlung zu dem Dauerbrenner: Grundlagen und Voraussetzungen für den Einsatz einer Teleradiologie nach RöV.
Definition Teleradiologie:
Unter Teleradiologie verstehen wir den Vorgang, bei dem das von einer Einrichtung digitalisierte Röntgenbild zu einem Spezialisten übertragen wird, der unverzüglich seine Diagnose erstellt und an die betreffende Einrichtung zurücksendet, damit ohne Verzögerung der Patient sachgerecht behandelt werden kann.
Voraussetzungen für die Genehmigung:
1. Vor Ort muss ein Arzt anwesend sein (mit entsp. Kenntnissen im Strahlenschutz)
2. MTA/Arzt vor Ort müssen gemäß §24 berechtigt sein, die Untersuchung
auszuführen
3. Befundender Arzt, Arzt vor Ort und MTA müssen in telefonischen Kontakt treten können
4. Der befundende Arzt und der Arzt vor Ort müssen sich beraten können, die Übernahme der Verantwortung für Untersuchung und Befund hat der befundende Arzt
5. Die verwendete teleradiologische Technik und deren Komponenten muss zeitgemäß sein und die übermittelten Bilder müssen diagnostische Aussagekraft besitzen
6. Der befundende Arzt muss innerhalb eines bestimmten Zeitraums (für die Notfallversorgung erforderlich) am Ort der Untersuchung eintreffen können (ca. 45 Min)
Qualitätssicherung (Konkret: Forderungen des Gewerbeaufsichtsamts)
1. Messung der Konstanz der Übertragungsgeschwindigkeit (1xMonat), bestehend aus:
Übertragung eines Demo Bilddatensatzes (Konstanz der Übertragungsge-schwindigkeit)
und Prüfung auf Vollständigkeit und Korrektheit des Demo Bilddatensatzes
2. Konstanz der Bildqualität (1xMonat)
SMPTE Testbild, 0%, 100%, 5% und 95% Grauwerterkennung Medizinische Teststudie (Konstanz des Bildeindrucks)
3. Anpassung der Darstellung der Befundungseinheiten am Untersuchungsort und den Befundungsorten zur Gewährleistung eines möglichst gleichen Bildeindrucks, Vgl. der verschiedenen BWG und ev. auch  mit Laser BDS (1xJahr und bei System-Inbetriebnahme)

Letzte Woche habe ich im Rahmen meiner Tätigkeit als IHK Ausbilder für Fachinformatiker gesehen, dass sich manche Betriebe im Rahmen der Facharbeitsvergabe ein IT-Notfallhandbuch erstellen lassen – gar nicht dumm, dachte ich. Nächster Gedanke:  wie viel Radiologische Praxen oder Radiologische Abteilungen haben denn auch so ein Büchlein?
Laut einer aktuellen Studie aus dem Jahre 2009 haben nicht einmal ein Drittel aller klein- und mittelständischen Unternehmen ein IT-Notfallhandbuch oder besitzen ein IT-Notfallmanagementsystem. Ich behaupte in der privaten Radiologie sind es noch deutlich weniger (wenn ich unsere Kundenbasis als Stichprobe heranziehe).
Diese Tatsache ist durchaus bedenklich, gerade im Gesundheitsbereich, in dem ein besonderes Risikomanagement fester Bestandteil der endlich verbindlich geforderten Qualitätssicherung ist. Das Fehlen eines IT-Notfallhandbuch oder eines IT-Notfallmanagementsystems ist also genauso genommen ein Versäumnis, das zur persönlichen Haftung der Geschäftsleitung, Abteilungsleitung oder Inhabern (Arztpraxen) führen kann.
Warum hat dann nicht jeder ein IT-Notfallhandbuch, wo es doch an der Nützlichkeit wahrscheinlich keinen Zweifel gibt?
Wie die abstrakte Version von IT Notfallmanagement auszusehen hat, ist im BSI Grundschutz Handbuch beschrieben. (BSI-Standard 100-4 Notfallmanagement).
Wer sich jedoch einmal das Kapitel IT-Notfallmanagement genauer angeschaut hat, begräbt meist von der Fülle des Inhalts erschlagen und dem Abstraktionsgrad frustriert, das ehrende Ansinnen, solch ein Handbuch zu verfassen.

Das ist zwar verständlich, löst aber das Problem nicht.
Darum ist es dringend zu empfehlen, sich mit den Lieferanten der Hardware und der eingesetzten Applikationen über eine Notfallstrategie zur Schadensbegrenzung zu verständigen. Dieses sollte um so einfacher sein, je weniger verschiedene Ansprechpartner benötigt werden und um so weniger brisant, desto redundanter die zentralen Komponenten ausgelegt sind.

Medizinische Informationssysteme, wie KIS und RIS, mutieren nicht selten zu Individualentwicklungen, je länger sie eingesetzt werden.
Merkmale solcher Systeme sind lückenhafte oder gar komplett fehlende Dokumentationen, veralterte Betriebssysteme und fossile Entwicklungstools, eine Vielzahl individueller Schnittstellen für zum Teil nicht mehr am Markt verfügbarer Hard- und Software. – Das alles hat in der Vergangenheit dem Kunden (viel) Geld gekostet und wird im Hinblick auf die notwendige Erweiterbarkeit (HL7, Dicom, IHE, Heilberufeausweis, eGK, Verschlüsselungen, etc.) zukünftig unbezahlbar oder es muss auf o.a. Erweiterungen verzichtet werden, was nicht möglich sein wird.

Das grundlegende Problem bei der Ablösung von Software-Altsystemen ist der über Jahre gewachsene, individualisierte Leistungsumfang. Je individueller man in der Vergangenheit Kundenwünschen nachgekommen ist und damit auch den Kundenzufriedenheitsgrad merklich gesteigert hat, desto albtraumähnlicher stellt sich das Ansinnen eines kompletten, grundlegenden  Redesigns für jeden Software-Entwicklungsleiter. IdR. erwartet der Kunde beim Kauf eines neuen Produkts alle möglichen technologischen Vorteile und Neuerungen (Webzugriff, Plattformunabhängigkeit, vereinfachte Wartung, gesteigerte Performance, etc.) und selbstverständlich erwartet er auch alle Features, die das Altsystem hatte (oft auch nicht zuletzt wegen der Bediengewohnheit). Eine alle Seiten sofort glücklich machende Lösung gibt es kaum.

Für die Software-Neuentwicklung bieten sog. „service-orientierte Architekturen“ (SOA) brauchbare Lösungsansätze. Bei diesen Lösungen werden Funktionseinheiten aus den alten monolithischen Softwarestrukturen herausgelöst und als einzelne Services abgekapselt. Gemeinsam benötigte Schnittstellen werden in der sog. Middleware, auf die die unterschiedlichen Services zugreifen können, zur Verfügung gestellt.

Dennoch erfordert die Ablösung von Altsystemen Abstriche auf beiden Seiten.
Der Anbieter neuer Softwarelösungen wird nicht drum herum kommen, für einzelne Kunden elementare Schnittstellen und Funktionen auch in der neuen Software zu realisieren.

Auf der anderen Seite muss der Kunde auch offen für gewisse „Workarounds“ sein und auf das ein oder andere gewohnte Feature seines Altsystems verzichten und ggf. hier und da seine eingefahrenen Arbeitsweisen überdenken.

Oftmals ist für eine radiologische Abteilung oder Praxis eine seriöse Bestandsaufnahme, über das, was in der Zukunft benötigt wird und was vielleicht nicht (mehr) gebraucht wird, sehr hilfreich. Damit ergibt sich auch die Gelegenheit, sich von gewohnten, jedoch nicht mehr wirklich benötigten Features zu trennen. Letzteres erfordert Entscheidungen und Entscheidungsträger. Die sind leider rar.

Applikationssoftware wie RIS und PACS werden nicht an einem Tag entwickelt. In der Regel entstehen so hoch spezialisierte Softwarepakete über Jahre hinweg. Über diesen Zeitraum entwickeln sich die Inhalte der Software stetig weiter und sind gerade im Gesundheitswesen in einem hohen Masse auf die spezifischen Bedürfnisse und Situationen der Kunden abgestimmt. Dementsprechend lange werden diese Lösungen in der Praxis eingesetzt. Ris-Lösungen einer Produktlinie sind nicht selten 10 Jahre und noch deutlich länger im Einsatz (noch heute existieren etliche Mumps-Lösungen – unvorstellbar!). Das hat durchaus seinen Preis. Softwarearchitekturen veraltern, Entwicklungswerkzeuge oder Tools verschwinden oder können mit den notwendigen Anpassungen nicht mehr Schritthalten (Stichwort: Borland C ++ und 64 Bit Unterstützung).

Während in der Industrie die Modernisierung von IT Infrastrukturen, insbesonders von Applikationssoftware, ein großes Thema ist, welches durchschnittliche Einsparpotentiale von mehr als 30% bietet, scheinen in der Medizin veraltete Softwaretechnologien bei den Informationssystemen kein so richtiges Problem zu sein. Noch heute werden Softwarepakete angeboten, die ihr Design und ihre Struktur aus den 90er Jahren des letzten Jahrhunderts beziehen.

Stört es die potentiellen Kunden nicht? –Oder merken sie es nicht? –Oder interessiert es sie am Ende gar nicht (wenn der Preis niedrig genug ist)?

Willkommen zum Digithurst Blog. Mit diesem Meinungsmedium möchten wir in Zunkunft in regelmäßigen Abständen über Themen im Umfeld von RIS und PACS informieren, die uns in irgendeiner Art tangieren. Die Auswahl der Themen ist subjektiv, die geäußerte Meinung auch – dafür jedoch garantiert werbefrei.
Kommentare und Meinungen sind herzlich willkommen. Viel Spaß beim Lesen.
Rainer Kasan