Wie Microservices die IT-Integration im Gesundheitswesen unterstützen

Microservices unterstützen Entwicklungsteams im Gesundheitswesen und anderen Branchen bei der Erstellung von Anwendungen aus lose gekoppelten Services, wodurch Entwicklung, Test, Bereitstellung und Upgrade vereinfacht werden. Diese Vorteile sorgen dafür, dass Entwicklungsteams im Gesundheitswesen Microservices gegenüber der älteren IT-Integrationstechnologie ESB (Enterprise Service Bus) vorziehen.

Wie in jedem großen Unternehmen ist auch die IT-Umgebung einer Gesundheitsorganisation eine wachsende Sammlung unterschiedlicher Systeme, die geschäftskritische Daten teilen müssen. Das ADT-System (Admission, Discharge, Transfer, zu Deutsch: Aufnahme, Entlassung, Verlegung eines Patienten), die Systeme für Terminplanung, Labor, Radiologie, Abrechnung und so weiter müssen miteinander kommunizieren, denn ihre Daten können bei einem medizinischen Notfall lebensnotwendig sein.

Im digitalen Zeitalter haben viele Gesundheitsversorger elektronische Patientenakten (Electronic Health Record, EHR) eingeführt. EHR bieten allerdings nur einen geringen Nutzen, wenn die Daten nicht zwischen den vielen Anwendungen geteilt werden können. Die Herausforderung einer Systemintegration im Gesundheitswesen geht auf das Jahr 1987 und die Einführung von Health Level Seven (HL7) zurück. Dabei handelt es sich um einen globalen Standard für den Transfer von klinischen und administrativen Daten zwischen Anwendungen im Gesundheitswesen. Nachdem dieser gemeinsame Standard etabliert wurde, benötigte das Gesundheitswesen eine Möglichkeit, Anwendungen so zu verbinden, dass sie via HL7 kommunizieren konnten.

Vor einigen Jahren fanden IT-Fachleute heraus, dass die Einrichtung direkter Point-to-Point-Verbindungen zwischen allen Anwendungen nicht praktikabel ist und mit zunehmender Unternehmensgröße immer schwieriger wird. Hinzu kam, dass HL7 trotz seines universellen Formats keine gängige Methode bot, die Felder zu interpretieren. Das bedeutete, dass eine Datentransformation sowie Konnektivität notwendig waren, um die Kommunikation zwischen verschiedenen Systemen im Gesundheitswesen zu unterstützen.

Die erste Integrationstechnologie, die von Anbietern im Gesundheitswesen eingeführt wurde, war die Interface Engine (IE), ein Server, der als Hub aller Systeme eines Krankenhauses fungierte. Alle Systeme verbanden sich mit der IE, die dann die Daten transformierte und nach Bedarf an die anderen Systeme weiterleitete. Vor 20 Jahren wurde schließlich der ESB (Enterprise Service Bus) entwickelt. Ähnlich wie die IE dient ein ESB als Hub für den Datenaustausch zwischen Anwendungen im Gesundheitswesen, hauptsächlich über HL7. Ein ESB bietet Datentransformation, Protokollkonvertierung, Routing, und Support für Webservices, wie JMS, HTTP und SOAP, sowie einfaches Management und Monitoring. ESB gehörte zwei Jahrzehnte lang zu den beliebtesten Integrationslösungen (im Gesundheitswesen und in anderen Branchen).

Seit der Einführung des ESB hat sich die Entwicklung von Anwendungen erheblich verändert. Eine der wichtigsten Änderungen ist der Wandel hin zur agilen Entwicklung und DevOps, wodurch ESBs verdrängt werden.

Die DevOps-Pipeline ist ein Entwicklungs-Lifecycle, der auf schrittweisen Änderungen und kontinuierlichen automatisierten Tests basiert. Im DevOps-Zeitalter stellen die Eigenschaften, die einst für die Beliebtheit des ESB sorgten, nun ein Hindernis dar. Ein ESB stellt alle Integrationen monolithisch bereit. Obwohl das in der Vergangenheit Vorteile hatte, ist heute genau das der Grund, warum ESB mit DevOps inkompatibel ist.

In einer modernen Entwicklungsumgebung bringen ESBs folgende Einschränkungen mit sich:

• Inkompatibilität mit agilen Entwicklungsteams​ und DevOps-Tools: Viele junge Entwicklerinnen und Entwickler werden heutzutage in einer DevOps-Umgebung ausgebildet. Diese agilen Entwicklungsteams arbeiten am effektivsten, wenn sie ihre bevorzugten Tools, also die neuesten DevOps-Lösungen, benutzen. Aber ESBs sind nicht in der Lage, diese Tools zu unterstützen.
• Änderungen beeinflussen das gesamte System: Wenn Sie bei einem ESB selbst eine kleine Regeländerung durchführen wollen, müssen Sie die gesamte Engine anhalten. Das heißt, dass jede Anwendung, die mit dem ESB interagiert, für eine gewisse Zeit ausfällt. Gleichfalls könnte jeder Fehler, der durch die Änderung entstanden ist, möglicherweise alle Ihre Integrationen beeinträchtigen. Das Ergebnis ist eine kontraproduktive Team-Mentalität, die Upgrades und Fixes negativ gegenübersteht.
• Single Point of Failure: Da alle Integrationen über denselben Hub geleitet werden, stellt ein ESB einen Single Point of Failure für das gesamte Unternehmen dar. Wenn der ESB ausfällt, fallen gleichzeitig auch alle Ihre Integrationen aus.
• Keine Möglichkeit für automatisierte Tests: Automatisierte Tests sind eine Hauptkomponente von DevOps. In der DevOps-Pipeline wird jedes Update unabhängig getestet, damit es den Entwicklungsprozess nicht unterbricht. Dies wird durch Automatisierung erreicht. Bei einem ESB ist Automatisierung jedoch aufgrund der proprietären grafischen Benutzeroberfläche (GUI) und Versionskontrolle nicht möglich.

Das Gesundheitswesen und andere Branchen haben neue Entwicklungspraktiken wie Microservices, DevOps und Agile angenommen. Dies hat sich auch auf die Integration im Gesundheitswesen ausgeweitet: Die neuen Anwendungen und digitalen Kontaktpunkte erfordern eine Integration in HL7, REST und andere Protokolle. Microservice-Entwicklungsteams im Gesundheitswesen sollten ihre Integrationen und anderen entwickelten Code (z. B. Daten, Streaming, GUI, Steuerung und Kontrolle usw.) kontrollieren und alle Änderungen in einsatzfähige Einheiten packen, die durch CICD geleitet werden. Die oben aufgelisteten Einschränkungen verhindern dieses Ziel eines CICD für Integrationscode mit anderem Code.

Microservices sind die Zukunft der Entwicklung. ESB ist damit einfach nicht kompatibel. ESBs sind monolithisch, und Microservices sind das Gegenteil. Sie ermöglichen es den Entwicklungsteams, Anwendungen und Integrationen mit Bausteinen aus lose gekoppelten Services zu erstellen. Indem sie Anwendungen in unabhängige Module aufbrechen, ist es einfacher, sie zu entwickeln, zu testen, Änderungen durchzuführen, sie wieder zu testen, Fehler zu korrigieren, sie bereitzustellen, sie in der Produktivumgebung zu testen, ein Upgrade durchzuführen und so weiter.

Microservices ermöglichen DevOps, weil sie automatisierte Tests erlauben. Microservices sind kleine Komponenten und passen dadurch einfach in Container. So kann der Testprozess automatisiert und CI/CD (Continuous Integration, Continuous Delivery) erleichtert werden. Ein monolithisches ESB ist dagegen zu groß, um in einen Container zu passen, kann auch nicht in Komponenten aufgebrochen und somit nicht auf gleiche Art und Weise getestet werden.

Aber der vielleicht wichtigste Grund, eine microservice-basierte Integration einzuführen, ist die Unterstützung agiler Entwicklungsteams bei der Nutzung ihrer favorisierten DevOps-Tools. Sobald kein ESB mehr vorhanden ist, können Entwicklungsteams in einer agilen Entwicklungsumgebung arbeiten, die sie kennen und bevorzugen. Ohne ESBs müssen Entwicklungsteams nicht für die Arbeit an einem proprietären System geschult werden, sondern können sich stattdessen auf einen produktiveren Entwicklungsansatz konzentrieren.

Zusätzlich demokratisieren Microservices die Integration, indem sie es Entwicklungsteams erlauben, ihre eigenen Integrationsbedürfnisse kennenzulernen, anstatt die Integration einem isolierten Team von ESB-Spezialisten zu überlassen. Denn schließlich versteht niemand die Datenanforderungen der Anwendung besser als die Person, die diese Anwendung entwickelt.

Microservices unterstützen außerdem API-Management und ermöglichen bei Bedarf eine API-basierte Integration.

Eine microservice-basierte Integration bietet Ihnen also dieselben Vorteile wie die Nutzung eines ESB, wie zum Beispiel die grafische Transformation und die Logik, mit der Sie ausgefeilte Regeln für den Datenfluss in Ihrem Unternehmen aufstellen können. Sie mögen vielleicht die grafische Entwicklungsfläche des ESB, aber es gibt ähnliche Arbeitsflächen, die eine microservice-basierte Integration unterstützen.

Eine microservice-basierte Integration bietet einige entscheidende Vorteile, darunter:

Umfassendes Monitoring und Management: Microservices können von erstklassigen, von agilen Entwicklungsteams bevorzugten Tools überwacht werden (z. B. Kibana, Elasticsearch, Grafana, Prometheus usw.), um Points of Failure ausfindig zu machen und Probleme zu lösen, bevor sie das Geschäft beeinträchtigen.

Automatisierte Tests: Einer der größten Vorteile von Microservices und DevOps ist die Möglichkeit für automatisierte Tests. Jede Integration wird im Testprozess als eigenständige Komponente behandelt und kann dadurch andere Komponenten der Anwendung oder andere Anwendungen nicht stören.

Hervorragende Softwarequalität: Effizientere Prozesse und verbesserte Testergebnisse führen letztendlich zu Software von höherer Qualität.

Beschleunigte Entwicklung: Die Optimierung des Integrationsentwicklungsprozesses durch DevOps und Automatisierung sowie die Eliminierung vormals manueller Prozesse führt zu einem beschleunigten Entwicklungs-Lifecycle.

Größere Skalierbarkeit: Aufgrund der eigenständigen Module der Anwendungen kann jeder Service unabhängig skaliert werden, ohne sich dabei auf den Rest der Anwendung auszuwirken.

Fortgeschrittene Innovation: Mithilfe von Microservices und DevOps können Ihre Entwicklungsteams innovative Integrationslösungen entwickeln, die Ihre Organisation bei der Einführung neuer Services und bei der Bereitstellung eines besseren Kundenservice unterstützen.

Geschäftliche Agilität: Agile Entwicklung führt natürlich zu geschäftlicher Agilität. Hierbei handelt es sich um die Fähigkeit, sich Marktveränderungen schnell anzupassen. Das schnelle Onboarding neuer Partner oder Anbieter, die einen Datenaustausch benötigen, wird durch das agile Entwicklungsteam ermöglicht, die Microservices dazu verwenden, die notwendigen Integrationen zu entwickeln, die diese Geschäftsbeziehungen unterstützen.

Verbessertes Kundenerlebnis: Ihr Hauptziel ist es, Ihren Kunden zu dienen, nämlich den Patienten, die sich jeden Tag auf Ihre Dienstleistungen im Gesundheitsbereich verlassen. Indem Sie Prozesse optimieren und Daten nahtlos zwischen System und Abteilungen teilen, können Sie sicherstellen, dass Ihre Patienten zufrieden sind.

Die Aufgabe, Ihre Integration zu Microservices zu migrieren, schreckt Sie möglicherweise ab. Warum sollten Sie etwas ändern? Ihr Team kennt sich schließlich bereits mit den proprietären Aspekten des ESB aus, auf den Sie sich seit vielen Jahren verlassen. Aber genau darin liegt das Problem. Was passiert, wenn einer oder zwei Ihrer ESB-Fachleute die Organisation verlässt? Wie lange würde es dauern, dieses Kompetenzniveau wieder zu erreichen?

Die Tatsache, dass es aufwändig erscheint, sich vom monolithischen ESB loszulösen, ist genau der Grund, warum Sie es machen sollten. Wenn Sie sich von den Einschränkungen des ESB befreien, können Sie die Vorteile genießen, die diese neue Welt der Integration mit sich bringt.

Eine event-gesteuerte Architektur kann zusammen mit einem Event Mesh eine Vielzahl von Use Cases unterstützen, die in komplexen, weit verteilten Topologien mit mehreren Clouds mithilfe unterschiedlicher Anwendungs-Stacks bereitgestellt werden. Nachfolgend finden Sie eine Auswahl der vielen möglichen Use Cases für das Event Mesh.

Microservice-Integration

Ein Event Mesh kann ganz einfach microservice-basierte Anwendungen miteinander und mit Legacy-Technologien verbinden.

E-Commerce

Ein Event Mesh ermöglicht die rasche Verarbeitung von Transaktionen, wodurch schnelle und hochgradig verlässliche Kundeninteraktionen über Websites und Apps sichergestellt werden.

Kundensupport

Ein Event Mesh unterstützt die schnelle Bereitstellung von Kundeninteraktionsdaten, die es Support-Teams ermöglichen, Kunden in Echtzeit zu antworten und ein personalisiertes IT-Erlebnis zu bieten.

Finanzdienstleistungen

Ein Event Mesh ermöglicht Finanzdienstleistern die Synchronisation von Echtzeit-Handelsdaten mit niedrigen Latenzzeiten. Zusätzlich kann ein Event Mesh in Echtzeit Informationen über verdächtige Transaktionen weitergeben, um die Betrugserkennung zu unterstützen.

IoT-Konnektivität

Ein Event Mesh liefert verlässliche und skalierbare IoT-Konnektivität an Backend-Systeme, um Metriken von einer beinahe grenzenlosen Auswahl an Sensoren zu verarbeiten.

Ein Event Mesh bietet Ihrem Unternehmen die folgenden entscheidenden Vorteile:

Reaktionsfähigkeit in Echtzeit

Der Erfolg eines Unternehmens ist abhängig von seiner Fähigkeit, auf Veränderungen zu reagieren. Einer der größten Vorteile eines Event Mesh ist die Echtzeit-Bereitstellung von Daten als Event Streams über eine event-gesteuerte Architektur, die schnelle Reaktionen ermöglicht. Ein Event Mesh ist hochgradig effizient und ermittelt den schnellsten Weg zwischen Event Producer und Event Consumer, wodurch Messaging-Latenz nahezu eliminiert wird. Dadurch erhalten Business-Stakeholder die Agilität, schnell auf bedenkliche Probleme zu reagieren, die zeitkritische Entscheidungen erfordern.

Verbessertes Kundenerlebnis

Ein Event Mesh ermöglicht die Echtzeit-Bereitstellung von Daten, die von kundenorientierten Teams und E-Commerce-Technologien verwendet werden. Dadurch können Unternehmen ihren Kunden einen besseren Service bieten und letztendlich das Kundenerlebnis verbessern.

Verringerte Betriebskosten

Durch die von einem Event Mesh bereitgestellte Echtzeit-Transparenz von Fertigung, Verkauf, Bestand und Versand können Organisationen Abläufe optimieren, die Effizienz verbessern und Kosten reduzieren.

Entwicklerproduktivität

Durch die Unterstützung eines Event Mesh, das unabhängig von verschiedenen Arten von Umgebungen, Messaging-Systemen und Protokollen eingesetzt werden kann, können Anwendungsentwicklerinnen und -entwickler sich darauf konzentrieren, die Geschäftslogik mithilfe der besten verfügbaren Technologien zu implementieren. So können Entwicklungsteams Innovationen schaffen, ohne ein komplexes Datenverteilungsnetzwerk entwickeln zu müssen und ohne Einschränkungen in Bezug auf eine bestimmte Entwicklungsumgebung, Messaging-Plattform oder Cloud.