Aufbau von Healthcare-Microservices: ein FHIR-nativer Ansatz

Healthcare-Microservices-Architektur

Microservices ist ein weit verbreitetes Architekturmuster, das Anwendungen als eine Sammlung lose gekoppelter, unabhängig deployoarer Services strukturiert. Dieser Ansatz ermöglicht es mehreren Teams, Komponenten parallel mit unterschiedlichen Programmiersprachen zu entwickeln. Jedes Team kann die beste Technologie für seinen spezifischen Service wählen und diesen entsprechend seinen individuellen Anforderungen skalieren, ohne andere Services zu beeinflussen.

In einem Healthcare-System zum Beispiel:

• Der Patient-Registration-Service könnte in Java geschrieben sein und 1.000 Anfragen/Minute verarbeiten
• Der Appointment-Scheduling-Service könnte in Node.js implementiert sein und 500 Anfragen/Minute verarbeiten
• Der Clinical-Decision-Support-Service könnte Python mit TensorFlow nutzen, um 2.000 Patientenfälle/Minute zu verarbeiten, Laborbefunde zu analysieren und Diagnosen vorzuschlagen

Eine zentrale Herausforderung in der Microservices-Architektur besteht in der Verwaltung der Kommunikation zwischen Services. APIs müssen klar definiert und stabil sein, um eine reibungslose Interaktion zu gewährleisten und gleichzeitig die Service-Unabhängigkeit aufrechtzuerhalten.

Genau hier kommt HL7 FHIR (Fast Healthcare Interoperability Resources) ins Spiel.

Warum FHIR für Microservices-Architekturen geeignet ist

Ursprünglich als Interoperabilitätsstandard entwickelt, bietet FHIR mehrere entscheidende Vorteile, die es besonders gut für Microservices-Architekturen geeignet machen:

1. Vorgefertigtes Domänenmodell

Ein klar definiertes Domänenmodell ist für Microservices-Architekturen von entscheidender Bedeutung. Änderungen am Modell können die exponierten APIs beeinflussen, was eine Koordination zwischen den Teams erfordert.

Das Hinzufügen eines neuen Feldes „preferredPharmacy" zur Patient-Ressource würde beispielsweise Aktualisierungen des Patient-Management-Services, des Medication-Services, der Patient-Portal-Benutzeroberfläche und aller zugehörigen APIs erfordern – und damit eine sorgfältige Koordination zwischen mehreren Teams.

FHIR bietet:

• Healthcare-spezifische Ressourcen: Einen umfassenden Satz von 145 einsatzbereiten Ressourcen (Patient, Encounter, Observation usw.), die von Healthcare-Domänenexperten in Tausenden von Stunden kollaborativer Arbeit entwickelt wurden. Jeder Ressourcentyp ist ein Aggregate Root im Sinne des DDD (Domain Driven Design).
• Erweiterbarkeits-Framework: Die Möglichkeit, Basisressourcen für spezifische Anwendungsfälle mittels Profiling zu erweitern und einzuschränken. So können Sie beispielsweise Erweiterungen zur Patient-Ressource hinzufügen, um Informationen zu speichern, die nicht in der FHIR-Spezifikation enthalten sind, oder bestimmte Elemente in der Patient-Ressource als Pflichtfeld definieren, ohne die Interoperabilitätsregeln zu verletzen. Das US Core Patient Profile dient als Beispiel.
• Implementation Guides: Einsatzbereite Blaupausen für die Implementierung spezifischer Healthcare-Domänen in FHIR. Diese Guides stellen Extensions, Profile und Operations für bestimmte Teildomänen bereit (wie z. B. Scheduling, Onkologie usw.).

2. Standardisiertes Terminology-Management

Im Healthcare-Bereich gibt es einige weit verbreitete, umfangreiche Code-Systeme:

• SNOMED CT (über 350.000 medizinische Konzepte)
• LOINC (nahezu 100.000 Labortest-Codes)
• ICD-10 (rund 70.000 Diagnosecodes)
• RxNorm (über 100.000 Medikamentencodes)
• usw.

Es ist eine Herausforderung, eine geeignete Methode zu entwickeln, um Konzepte aus diesen Code-Systemen in Ihren Microservices zu speichern und zu verwenden. Zum Beispiel bei der Erfassung einer Patientendiagnose:

• Der Code „I21.3" in ICD-10 bedeutet „ST-Hebungsmyokardinfarkt an nicht näher bezeichneter Stelle"
• Dieselbe Erkrankung ist in SNOMED CT unter „401303003" zu finden
• Verschiedene Services könnten unterschiedliche Code-Systeme verwenden
• Codes müssen validiert und zwischen Systemen gemappt werden
• Code-Systeme werden regelmäßig mit neuen Versionen aktualisiert

FHIR bietet:

• Eingebaute Coding-Systeme: Unterstützung für medizinische Standardterminologien (SNOMED CT, LOINC, ICD-10, RxNorm usw.)
• Vocabulary-Services: Standard-APIs für die Terminologievalidierung und -abfrage. Beispiel: Wenn ein Arzt eine Patientendiagnose in einem EHR-System eingibt, tippt er die Diagnose nicht manuell ein, sondern wählt aus einem FHIR-Terminology-Service aus, der SNOMED-CT-Codes in Echtzeit bereitstellt. Nach der Eingabe können die Daten vom FHIR-Server vor der Speicherung als Condition-Ressource validiert werden.
• ValueSet-Management: Ein definierter Ansatz zur Verwaltung von Code-Sets. Beispiel: Sie können eine wiederverwendbare Teilmenge von SNOMED-CT-Codes als ValueSet-Ressource definieren, um Klinikern eine fokussierte Liste von Diagnosecodes bereitzustellen, die für ihr Fachgebiet relevant sind.
• Versions-übergreifendes Mapping: Unterstützung für Terminologie-Versionierung und -Mapping. Beispiel: Wenn ICD-10 aktualisiert wird, kann das System alte Diagnosecodes auf neue abbilden.

3. Vorgefertigtes API-Modell

Das API-Management ist ein wesentlicher Bestandteil der Microservices-Architektur. Sie müssen die Kommunikationsmuster für synchrone und asynchrone Interaktionen zwischen Services gestalten.

Betrachten Sie beispielsweise einen Patientenentlassungs-Workflow:

• Der Clinical-Service muss synchron prüfen, ob Medikamente verfügbar sind
• Der Pharmacy-Service muss asynchron benachrichtigt werden, um Medikamente vorzubereiten
• Der Scheduling-Service muss benachrichtigt werden, um Nachsorgetermine zu buchen
• Der Billing-Service muss die abschließende Entlassungszusammenfassung erhalten

Ohne standardisierte Muster würde jede dieser Interaktionen ein individuelles API-Design und eine individuelle Implementierung erfordern.

FHIR übernimmt das für Sie.

• RESTful-Interface: Standard-CRUD-Operationen, die mit HTTP-Methoden ausgerichtet sind.
• Transaktionsunterstützung: Integrierte Unterstützung für atomare Multi-Ressourcen-Operationen, die gefährliche partielle Aktualisierungen verhindern. Beispiel: Beim Verschreiben eines Medikaments für eine neue Diagnose werden entweder sowohl die Diagnose als auch die Medikamentenverordnung gemeinsam gespeichert oder keines von beidem. Dies verhindert gefährliche Situationen, in denen ein Medikament ohne die zugehörige Diagnose existiert oder umgekehrt, was zu medizinischen Fehlern führen könnte. Schlägt ein Teil der Transaktion fehl (z. B. die Überprüfung auf Wechselwirkungen), wird die gesamte Operation automatisch zurückgerollt.
• Such-Framework: Umfassende Suchfunktionen mit Standardparametern. Beispiel: Sie können eine einzelne FHIR-Suchabfrage erstellen, die alle Patienten zurückgibt, die ihre Einwilligung zur Datenweitergabe an einen bestimmten Arzt gegeben haben, und den zugehörigen Encounter in den Suchergebnissen einschließen:

GET /fhir/Patient?_has:Consent:patient:actor=<practitioner-id>&_has:Consent:patient:scope=Encounter&_revinclude=Encounter:subject

• Subscriptions-Framework: Integrierte Unterstützung für ereignisbasierte Kommunikation – Anwendungen können auf Ressourcenänderungen reagieren. Beispiel: Wenn ein Laborbefund aktualisiert wird, erhält das System des Arztes automatisch eine Benachrichtigung.

Zielarchitektur einer FHIR-nativen Microservices-Lösung

Der erste Schritt beim Aufbau einer FHIR-nativen Microservices-Lösung besteht darin, sich für die Datenspeicherung zu entscheiden.

Zwei gängige Muster sind:

• Database (FHIR-Server) pro Service – jeder Service verfügt über seinen eigenen isolierten FHIR-Speicher
• Shared Database (FHIR-Server) – alle Services nutzen den gemeinsamen FHIR-Server zur Speicherung aller FHIR-Ressourcen

Die Database-per-Service-Architektur trägt dazu bei, dass die Services lose gekoppelt bleiben. Änderungen an der Datenbank eines Services haben keine Auswirkungen auf andere Services. Die Nachteile sind:

• Verwaltung/Implementierung mehrerer FHIR-Server
• Zusätzlicher Aufwand für die Implementierung von Transaktionen, die mehrere Services umfassen
• Die Implementierung einer dienstübergreifenden Suche ist komplexer

Shared Database erscheint für eine FHIR-native Microservices-Lösung natürlicher, da sie folgende Vorteile bietet:

• Reduzierter Implementierungsaufwand: Vorgefertigte CRUD-Operationen und Suchfunktionen für alle Ressourcen

• Integrierte Transaktionsunterstützung für alle Ressourcen

• Vereinfachtes Datenkonsistenzmanagement

• Datenkonsistenz: Einzige Quelle der Wahrheit für alle FHIR-Ressourcen

• Atomare Transaktionen über mehrere Ressourcen hinweg

• Einfacheres Management der referenziellen Integrität

• Geringeres Kopplungsrisiko: Obwohl gemeinsame Datenbanken häufig zu enger Kopplung führen, wird dieses Risiko in FHIR-nativen Architekturen gemindert. Das FHIR-Modell ist von Natur aus stabil und erweiterbar, sodass koordinierte Schema-Änderungen entfallen.

Das folgende Diagramm veranschaulicht die Zielarchitektur einer FHIR-nativen Microservices-Lösung:

Hauptkomponenten der Architektur

• Healthcare-Services

Domänenspezifische Microservices, die die Geschäftslogik für verschiedene Healthcare-Workflows implementieren (z. B. Patientenverwaltung, Scheduling, klinische Dokumentation). Sie interagieren über Standard-FHIR-REST-APIs mit dem FHIR-Server und konsumieren Ereignisse über Subscriptions.

• FHIR-Server Gemeinsamer Datenspeicher, der: FHIR-APIs für die Speicherung, den Abruf und die Suche von Ressourcen bereitstellt

• Konsumenten über Subscriptions über ressourcenbezogene Ereignisse informiert

• Die Datenvalidierung übernimmt.

• Terminology-Server

Verwaltet Healthcare-Vokabulare und Code-Systeme (SNOMED CT, LOINC, ICD-10 usw.). Stellt Terminology-Validierungs-, Abfrage- und Mapping-Operationen bereit, um die semantische Interoperabilität auf der gesamten Plattform sicherzustellen.

• Infrastruktur- und Sicherheits-Services Querschnittsbelange, darunter: Authentifizierung und Autorisierung
• API-Gateway und Routing
• Audit-Logging und Monitoring
• PACS (Picture Archiving and Communication System)

Schritte zum Aufbau eines FHIR-nativen Systems mit Microservices-Architektur

Der Implementierungsansatz unterscheidet sich erheblich zwischen Greenfield-Projekten und der Modernisierung von Legacy-Systemen. Während neue Systeme von Grund auf mit FHIR-nativen Prinzipien konzipiert werden können, erfordern bestehende Healthcare-Systeme eine sorgfältige Migrationsstrategie.

Greenfield-Projekt

Für neue Healthcare-Systeme können Sie FHIR-native Prinzipien von Anfang an mit folgenden Schritten umsetzen:

• Ressourcengetriebene Domänenzerlegung: Geschäftsdomänen auf FHIR-Ressourcen abbilden Beispiel-Mapping: Patientenverwaltung → Patient, Person, RelatedPerson

• Scheduling → Appointment, Schedule, Slot

• Klinische Dokumentation → Observation, DiagnosticReport, Condition

• Grenzen zwischen Microservices definieren Obwohl die optimalen Service-Grenzen stark von Ihrem spezifischen Anwendungsfall und Systemkontext abhängen, finden Sie hier einige Leitlinien zur Entscheidungsfindung:- FHIR bietet einige Hinweise zur Organisation von Ressourcen in logische Gruppen: https://hl7.org/fhir/overview-arch.html#organizing

• Relevante FHIR Implementation Guides (IGs) für domänenspezifische Hinweise prüfen, z. B. für Scheduling: https://build.fhir.org/ig/IHE/ITI.Scheduling/volume-1.html

• Die Ressourcendefinitionen in der FHIR-Spezifikation sind ebenfalls eine gute Inspirationsquelle, da sie häufig Informationen zu verwandten Ressourcen und deren beabsichtigter Verwendung enthalten. Zum Beispiel: https://hl7.org/fhir/appointment.html#scope

• Infrastruktur-Setup: Einen produktionsreifen FHIR-Server deployen

• Sicherheits- und Authentifizierungs-Services implementieren

• Monitoring- und Logging-Infrastruktur aufsetzen

• Terminology-Services konfigurieren

• Service-Implementierung Mit den Kern-Services beginnen (Patientenverwaltung, Scheduling)

• FHIR-CRUD- und Such-APIs des FHIR-Servers für die Arbeit mit FHIR-Ressourcen aus den Microservices verwenden

• Geschäftslogik in den Microservices durch Entwurf und Implementierung von Operationen auf FHIR-Ressourcen umsetzen. Inspiration aus der FHIR-Spezifikation oder Implementation Guides schöpfen. Zum Beispiel hat der FHIR Scheduling IG einen Satz von Operationen für das Terminmanagement definiert.

Beispielarchitektur

Weitere Services implementieren

Zusätzliche Services implementieren (z. B. Feedback-Sammlung)

• Features hinzufügen (z. B. Benachrichtigungen)

• FHIR Subscriptions für ereignisgesteuerte Kommunikation nutzen

Modernisierung von Legacy-Systemen

• Strategische Service-Auswahl: Einen klar abgegrenzten initialen Service für einen Proof-of-Concept (POC) auswählen

• Kandidaten mit hohem Nutzen und geringerem Risiko in Betracht ziehen, wie Patient Portal oder Master Patient Index

• Integrationsarchitektur

Eine bidirektionale Integration zwischen Legacy-Systemen und den neuen FHIR-nativen Microservices etablieren.

FHIR-nativen Footprint schrittweise ausbauen

Weitere Services inkrementell migrieren:

Den POC-Service in der Produktionsumgebung validieren

• Nachfolgende Services für die Migration identifizieren und priorisieren

• Den FHIR-nativen Footprint schrittweise ausbauen, indem neue Microservices hinzugefügt und bestehende migriert werden

Beispiel: Patient Portal, das Patienten die Planung und Verwaltung ihrer Termine ermöglicht

Schritt 1: Mit einem POC beginnen – ein Patient Portal, das Patienten ermöglicht, ihre Patientendaten und Termine einzusehen. Schritt 2: Einen neuen Service für die Terminplanung hinzufügen. Schritt 3: Einen weiteren Service für die Erfassung von Patientenfeedback zu den Besuchen hinzufügen.

Fazit

Die Einführung eines FHIR-nativen Ansatzes erfordert zwar eine anfängliche Investition in das Erlernen des FHIR-Standards und seiner Implementierungsmuster, doch die langfristigen Vorteile überwiegen die anfängliche Lernkurve bei weitem.

Eine FHIR-native Plattform ist:

• Zukunftssicher – Langfristige Interoperabilität mit anderen Healthcare-Systemen wird gewährleistet
• Effektiv – Reduzierung der Entwicklungszeit durch standardisierte Muster
• Robust – Nutzung eines ausgereiften, Healthcare-spezifischen Standards
• Compliant – Vereinfachung der Einhaltung von Vorschriften wie US Core-Profilen für den 21st Century Cures Act
• Ökosystemreich – Profitiert vom wachsenden FHIR-Ökosystem an Tools und Implementierungen

Sind Sie bereit, FHIR-native Microservices in Ihrer Healthcare-Organisation zu implementieren? Bei Health Samurai haben wir Dutzende von Healthcare-Organisationen erfolgreich beim Übergang zu FHIR-nativen Plattformen begleitet. Ob Sie ein neues Projekt starten oder Legacy-Systeme modernisieren möchten – unser Team steht Ihnen zur Seite.

Vernetzen Sie sich mit mir, Aleksandr Kislitsyn, auf LinkedIn, um Ihren spezifischen Anwendungsfall zu besprechen und zu erfahren, wie wir Ihnen helfen können, Ihre Ziele im Bereich Healthcare-Interoperabilität zu erreichen.

Siehe auch: Warum Sie einen unabhängigen FHIR-Server benötigen.