Softwarelösungen für Verbraucher und Unternehmen haben in den letzten fünf Jahren eine bedeutende Entwicklung durchlaufen. Viele Branchen haben einen Punkt erreicht, an dem „Software as a Service“ (SaaS) unmerklich zur Norm geworden ist. Die Nutzung von Microsoft Office-Produkten beispielsweise hat sich still und leise in Microsoft 365 verwandelt, das als Service angeboten wird. Zu Hause nutzen wir eine ganze Reihe von Google-, Apple- und anderen Softwareprodukten - alle werden als Service angeboten, die meisten davon als Abonnement.
Auch im Gesundheitswesen sehen wir den Übergang zu SaaS-Lösungen. Neue Anwendungen wie KI (Künstliche Intelligenz) sind oft schon standardmäßig Cloud-nativ. Nativ bedeutet in diesem Kontext, dass sie von vornherein in der Cloud entwickelt werden.
Für EHRs (Electronic Health Records = Elektronische Gesundheitsdatensysteme) und auch PACS (Picture Archiving and Communication Systems), die so kritisch und komplex sind, ist der Übergang in diese (native) Cloud sehr langsam. Diese Trägheit lässt sich im Wesentlichen auf zwei Ursachen zurückführen:
Die etablierten PACS-Anbieter verfügen über funktionsreiche Altsysteme, die auf älteren Technologien basieren, die nie für die Cloud konzipiert wurden.
Das Misstrauen der Endanwender in Bezug auf Sicherheit, Verfügbarkeit und Reaktionszeit der nativen Cloud-Software. In der Tat stellen sich viele Einrichtungen im Gesundheitswesen eine SaaS-Lösung als langsam und unzuverlässig vor. Es besteht die Vorstellung, dass eine Anwendung, die in einer öffentlichen Cloud läuft, das System langsamer und unzuverlässiger machen wird. In Wirklichkeit könnte nichts weiter von der Wahrheit entfernt sein: SaaS erweist sich oft als besser, effizienter und sicherer als privat verwaltete Rechenzentren.
|
Warum die native Cloud die Zukunft ist: Infografik herunterladen 'Die Reise zur wahren Cloud'
|
Da sich die Erwartungen und Erfahrungen mit SaaS ständig weiterentwickeln, ist klar, dass die Tage gezählt sind, in denen Einrichtungen des Gesundheitswesens erhebliche Investitionen in die Anschaffung und Verwaltung lokaler Soft- und Hardware tätigen müssen. Benutzer von Unternehmensanwendungen erwarten, dass sie für die Software auf Grundlage ihrer Nutzung bezahlen. Sie erwarten den sofortigen Zugriff auf die neuesten Funktionen, sobald diese verfügbar sind. Und sie erwarten, dass sich die Softwareleistung automatisch an die sich ständig ändernden Anforderungen anpasst. Um diese Anforderungen zu erfüllen, sind Cloud-native Entwicklungen und "Born-in-the-Cloud"-Softwarelösungen erforderlich, die automatische Skalierbarkeit, kontinuierliche Produktinnovation, einfache Erweiterbarkeit und intuitive Konfigurierbarkeit ermöglichen.
Man könnte annehmen, dass die Entwicklung eines SaaS-basierten PACS so einfach ist wie die Installation eines herkömmlichen PACS in einem Rechenzentrum und die anschließende Einbettung in einige öffentliche Dienste. Aber um die Vorteile eines Cloud-nativen PACS wirklich zu verstehen, müssen wir etwas tiefer blicken, da es eine Menge Unterschiede zwischen den beiden Architekturen gibt. Diese Tabelle zeigt eine Übersicht:
Cloud-native vs. traditionelle Unternehmensapplikationen (in einer Cloud-Umgebung)
|
Traditionelle Unternehmensapplikation |
Cloud-nativ |
Konsequenz für die medizinische Bildgebung mit Cloud-nativem PACS |
|
Betriebssystemabhängig - jedes System hat bestimmte Betriebssystemspezifikationen und zugrunde liegende Hardwareanforderungen. Sie hinken oft hinter den neuesten Technologien, Betriebssystemen usw. hinterher. |
Betriebssystemunabhängig - dies kann in verschiedenen (Cloud-)Umgebungen und Technologien funktionieren, was es leichter erweiterbar und portabel macht und damit die Softwarekomponenten wiederverwendbar und zukunftssicher. |
Das Krankenhaus hat keine Abhängigkeit in Bezug auf ein Betriebssystem oder eine bestimmte (ältere) Technologie sowie die Notwendigkeit von Betriebssystem-Updates, Anti-Virus, Patches usw. |
|
Immer Überkapazitäten - es gibt immer Überzahlungen und Überinvestitionen. |
Immer die richtige Kapazität. |
Echte Software-as-a-Service. Nicht nur auf dem Papier, sondern in der Praxis. Kosteneffektiv. |
|
Silos und "Über-die-Wand"-Transfer: Jeder einzelne User ist quasi isoliert und muss Ressourcen und Daten auf herkömmliche Art und Weise mit anderen Usern teilen; zwei User bedeuten zwei verschiedene Installationen im Rechenzentrum. |
Kollaborativ: Kunden haben ihr eigenes Projektarchiv, können aber mit den richtigen Vereinbarungen Ressourcen und Daten leicht gemeinsam nutzen, ohne (Daten-) Transfers oder komplexe Integrationen. |
Krankenhäuser und Radiologen können einfach zusammenarbeiten, während jeder sein eigenes System und seinen eigenen Workflow behält. Integrationen (mit KI, eHealth) können ebenfalls leicht gemeinsam genutzt werden. |
|
Wasserfall-Entwicklung und große Upgrades. |
Kontinuierliche Verbesserung und Updates ohne Unterbrechung. |
Jedes Krankenhaus ist immer auf der neuesten Version, ohne die bekannten PACS-Upgrades. |
|
Manuelle Skalierung. |
Automatisierte Skalierbarkeit. |
Dies erweitert die Unabhängigkeit von Betriebssystemen, Arbeitsflexibilität, Skalierbarkeit usw. |
|
Oft (teilweise) Fat-Client-Software. |
Vollständig webbasierte Software. |
Dies erweitert die Unabhängigkeit vom Betriebssystem, die Arbeitsflexibilität, die Skalierbarkeit usw. |
|
Vereinbaren Sie einen 15-minütigen Termin mit einem PACSonWEB Applikationsspezialisten, um herauszufinden, wie PACSonWEB helfen kann, Ihre Radiologie-Workflows zu optimieren.
|
