--- { "title": "Healthcare-Microservices entwickeln: ein FHIR-nativer Ansatz", "description": "Erfahren Sie, wie ein FHIR-nativer Microservices-Ansatz die Entwicklung von Gesundheitssystemen vereinfacht. Lernen Sie, skalierbare, interoperable Services mit den vorgefertigten APIs, Domänenmodellen und Terminology-Werkzeugen von FHIR zu erstellen – ideal für Greenfield-Projekte und die Modernisierung von Legacy-Systemen.", "date": "2025-03-27", "author": "Aleksandr Kislitsyn", "reading-time": "15 minutes", "tags": [ "System Design", "FHIR Standard" ] } --- ## Microservices-Architektur im Gesundheitswesen [Microservices](/blog/thoughts-about-microservices) ist ein weit verbreitetes Architekturmuster, das Anwendungen als eine Sammlung lose gekoppelter, unabhängig deployierbarer Services strukturiert. Dieser Ansatz ermöglicht es mehreren Teams, Komponenten parallel in 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 beeinträchtigen. In einem Gesundheitssystem beispielsweise: - Der Patientenregistrierungs-Service könnte in Java geschrieben sein und 1.000 Anfragen/Minute verarbeiten - Der Terminplanungs-Service könnte in Node.js implementiert sein und 500 Anfragen/Minute verarbeiten - Der klinische Entscheidungsunterstützungs-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 liegt in der Verwaltung der Kommunikation zwischen den Services. APIs müssen klar definiert und stabil sein, um eine reibungslose Interaktion bei gleichzeitiger Wahrung der Service-Unabhängigkeit zu gewährleisten. Genau hier kommt HL7 FHIR (Fast Healthcare Interoperability Resources) ins Spiel. ## Warum FHIR für Microservices-Architekturen geeignet ist FHIR wurde ursprünglich als Interoperabilitätsstandard entwickelt und bietet mehrere wesentliche 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 unverzichtbar. Ä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 Patientenverwaltungs-Services, des Medikations-Services, des Patientenportal-UI und aller zugehörigen APIs erfordern – und damit eine sorgfältige Koordination über mehrere Teams hinweg. FHIR bietet: - [**Gesundheitsspezifische Ressourcen**](https://hl7.org/fhir/resourcelist.html): Einen umfassenden Satz von 145 einsatzbereiten Ressourcen (Patient, Encounter, Observation usw.), die von Experten der Gesundheitsdomäne in tausenden von Stunden kollaborativer Arbeit entwickelt wurden. Jeder Ressourcentyp ist ein [Aggregate Root](https://martinfowler.com/bliki/DDD_Aggregate.html) im Sinne von DDD (Domain Driven Design). - [**Erweiterbarkeits-Framework**](https://hl7.org/fhir/extensibility.html): Die Möglichkeit, Basisressourcen für spezifische Anwendungsfälle mithilfe von [Profiling](https://build.fhir.org/profiling.html) zu erweitern und einzuschränken. Sie können z. B. 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 Pflichtfelder festlegen, ohne die Interoperabilitätsregeln zu verletzen. Das [US Core Patient Profile](https://build.fhir.org/ig/HL7/US-Core/StructureDefinition-us-core-patient.html) dient als Beispiel. - [**Implementation Guides**](https://build.fhir.org/implementationguide.html): Einsatzbereite Blaupausen für die Implementierung spezifischer Gesundheitsdomänen in FHIR. Diese Guides stellen Erweiterungen, Profile und Operationen für bestimmte Teilbereiche bereit (z. B. für [Terminplanung](https://fhir.org/guides/argonaut/scheduling/), [Onkologie](https://build.fhir.org/ig/HL7/fhir-mCODE-ig/index.html) usw.). **2. Standardisiertes Terminology-Management** Im Gesundheitswesen gibt es einige weit verbreitete, umfangreiche Code-Systeme: - SNOMED CT (über 350.000 medizinische Konzepte) - LOINC (nahezu 100.000 Labortest-Codes) - ICD-10 (ca. 70.000 Diagnosecodes) - RxNorm (über 100.000 Medikamentencodes) - usw. Es ist eine Herausforderung, einen geeigneten Ansatz zur Speicherung und Verwendung von Konzepten aus diesen Code-Systemen in Microservices zu entwerfen. Bei der Erfassung einer Patientendiagnose beispielsweise: - bedeutet der Code „I21.3" in ICD-10 „ST-Hebungsmyokardinfarkt an nicht näher bezeichneter Stelle" - ist dieselbe Erkrankung in SNOMED CT unter „401303003" erfasst - können verschiedene Services unterschiedliche Code-Systeme verwenden - müssen Codes zwischen Systemen validiert und gemappt werden - werden Code-Systeme regelmäßig mit neuen Versionen aktualisiert FHIR bietet: - [**Integrierte Codiersysteme**](https://hl7.org/fhir/terminologies.html): Unterstützung für standardisierte medizinische Terminologien (SNOMED CT, LOINC, ICD-10, RxNorm usw.) - [**Vocabulary-Services**](https://hl7.org/fhir/terminology-service.html): Standard-APIs für die Terminology-Validierung und -Suche. Beispiel: Wenn ein Kliniker in einem KIS-System eine Patientendiagnose eingibt, wählt er anstelle einer manuellen Eingabe aus einem [FHIR-Terminology](/articles/two-phase-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](https://www.hl7.org/fhir/condition.html)-Ressource validiert werden. - [**ValueSet-Management**](https://hl7.org/fhir/valueset.html): Definierter Ansatz zur Verwaltung von Code-Mengen. 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 ihre Fachrichtung relevant sind. - [**Versions-übergreifendes Mapping**](https://hl7.org/fhir/conceptmap.html): Unterstützung für Terminology-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 entwerfen. Betrachten Sie beispielsweise einen Patientenentlassungs-Workflow: - Der klinische Service muss synchron prüfen, ob Medikamente verfügbar sind - Der Apotheken-Service muss asynchron benachrichtigt werden, um Medikamente vorzubereiten - Der Terminplanungs-Service muss benachrichtigt werden, um Nachsorgetermine zu buchen - Der Abrechnungs-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 hat das bereits für Sie erledigt. - [**RESTful-Schnittstelle**](https://hl7.org/fhir/http.html): Standard-CRUD-Operationen in Übereinstimmung mit HTTP-Methoden. - [**Transaktionsunterstützung**](https://hl7.org/fhir/http.html#transaction): Integrierte Unterstützung für atomare Multi-Ressourcen-Operationen, die gefährliche partielle Aktualisierungen verhindern. Beispiel: Bei der Verschreibung eines Medikaments für eine neue Diagnose werden entweder sowohl die Diagnose als auch die Medikationsanordnung 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. eine Überprüfung auf Wechselwirkungen), wird die gesamte Operation automatisch zurückgerollt. - [**Such-Framework**](https://hl7.org/fhir/search.html): Umfassende Suchfunktionen mit Standardparametern. Beispiel: Sie können eine einzige FHIR-Suchanfrage erstellen, die alle Patienten zurückgibt, die der Weitergabe ihrer Daten an einen bestimmten Behandler zugestimmt haben, und dabei die zugehörigen Encounter in die Suchergebnisse einschließen: ```javascript GET /fhir/Patient?_has:Consent:patient:actor=&_has:Consent:patient:scope=Encounter&_revinclude=Encounter:subject ``` - [**Subscriptions-Framework**](https://hl7.org/fhir/subscriptions.html): 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 in der Entscheidung über die Datenspeicherung. Zwei verbreitete Muster sind: - [**Datenbank (FHIR-Server) pro Service**](https://microservices.io/patterns/data/database-per-service.html) – wobei jeder Service seinen eigenen isolierten FHIR-Speicher hat - [**Gemeinsame Datenbank (FHIR-Server)**](https://microservices.io/patterns/data/shared-database.html) – alle Services nutzen den gemeinsamen FHIR-Server zur Speicherung aller FHIR-Ressourcen Die **Datenbank-pro-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](https://www.health-samurai.io/fhir-server) - Zusätzlicher Aufwand für die Implementierung von Transaktionen, die mehrere Services umfassen - Komplexere Implementierung von Service-übergreifenden Suchen Die **gemeinsame Datenbank** 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 über Ressourcen hinweg - Vereinfachte Verwaltung der Datenkonsistenz - **Datenkonsistenz**: Einzige Quelle der Wahrheit für alle FHIR-Ressourcen - Atomare Transaktionen über mehrere Ressourcen hinweg - Einfachere Verwaltung 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 nicht erforderlich sind Das folgende Diagramm veranschaulicht die Zielarchitektur einer FHIR-nativen Microservices-Lösung: ![](image-1.avif) ### Hauptkomponenten der Architektur - **Healthcare-Services** Domänenspezifische Microservices, die Geschäftslogik für unterschiedliche Gesundheits-Workflows implementieren (z. B. Patientenverwaltung, Terminplanung, klinische Dokumentation). Sie interagieren mit dem FHIR-Server über Standard-FHIR-REST-APIs und empfangen Ereignisse über Subscriptions. - **FHIR-Server** Gemeinsamer Datenspeicher, der: FHIR-APIs für Ressourcenspeicherung, -abruf und -suche bereitstellt - Verbraucher über ressourcenbezogene Ereignisse via Subscriptions benachrichtigt - Datenvalidierung durchführt. - **Terminology-Server** Verwaltet medizinische Vokabularien und Code-Systeme (SNOMED CT, LOINC, ICD-10 usw.). Stellt Terminology-Validierung, -Suche und -Mapping-Operationen bereit, um semantische Interoperabilität auf der gesamten Plattform zu gewährleisten. - **Infrastruktur- und Sicherheits-Services** Querschnittliche Belange, darunter: Authentifizierung und Autorisierung - [API-Gateway](/articles/using-api-gateway-with-fhir-api) 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 nach FHIR-nativen Prinzipien entworfen werden können, erfordern bestehende Gesundheitssysteme eine sorgfältige Migrationsstrategie. ### Greenfield-Projekt Für neue Gesundheitssysteme können Sie FHIR-native Prinzipien von Beginn an mit folgenden Schritten umsetzen: - **Ressourcengetriebene Domänendekomposition**: Ordnen Sie Geschäftsdomänen FHIR-Ressourcen zu Beispiel-Zuordnung: Patientenverwaltung → Patient, Person, RelatedPerson - Terminplanung → Appointment, Schedule, Slot - Klinische Dokumentation → Observation, DiagnosticReport, Condition - Definieren Sie die Grenzen zwischen Microservices Die optimalen Service-Grenzen hängen stark von Ihrem spezifischen Anwendungsfall und Systemkontext ab. Die folgenden Leitlinien können jedoch bei der Entscheidung helfen:- FHIR bietet einige Hinweise zur Organisation von Ressourcen in logische Gruppen: [https://hl7.org/fhir/overview-arch.html#organizing](https://hl7.org/fhir/overview-arch.html#organizing) - Prüfen Sie relevante [FHIR Implementation Guides](/articles/how-to-create-a-fhir-implementation-guide) (IGs) für domänenspezifische Orientierung, z. B. für die Terminplanung: [https://build.fhir.org/ig/IHE/ITI.Scheduling/volume-1.html](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 Nutzung enthalten. Beispiel: [https://hl7.org/fhir/appointment.html#scope](https://hl7.org/fhir/appointment.html#scope) - **Infrastruktur-Einrichtung**: Deployen Sie einen produktionstauglichen [FHIR-Server](https://www.health-samurai.io/fhir-server) - Implementieren Sie Sicherheits- und Authentifizierungs-Services - Richten Sie Monitoring- und Logging-Infrastruktur ein - Konfigurieren Sie Terminology-Services - **Service-Implementierung** Beginnen Sie mit den Kern-Services (Patientenverwaltung, Terminplanung) - Nutzen Sie die FHIR-CRUD- und Such-APIs des FHIR-Servers für die Arbeit mit FHIR-Ressourcen aus den Microservices heraus - Implementieren Sie Geschäftslogik in den Microservices durch das Entwerfen und Implementieren von Operationen auf FHIR-Ressourcen. Lassen Sie sich von der FHIR-Spezifikation oder Implementation Guides inspirieren. Der [FHIR Scheduling IG](https://build.fhir.org/ig/IHE/ITI.Scheduling/artifacts.html#behavior-operation-definitions) hat beispielsweise einen Satz von Operationen zur Verwaltung von Terminen definiert **Beispielarchitektur** ![](image-2.avif) - **Implementierung weiterer Services** Implementieren Sie zusätzliche Services (z. B. Feedback-Erfassung) - Fügen Sie Funktionen hinzu (z. B. Benachrichtigungen) - Nutzen Sie FHIR Subscriptions für ereignisgesteuerte Kommunikation ### Modernisierung von Legacy-Systemen - **Strategische Service-Auswahl**: Wählen Sie einen klar abgegrenzten initialen Service für einen Proof-of-Concept (POC) - Ziehen Sie Kandidaten mit hohem Mehrwert und geringem Risiko in Betracht, wie das Patientenportal oder den [Master Patient](/articles/master-patient-index-and-record-linkage) Index - **Integrationsarchitektur** Etablieren Sie eine bidirektionale Integration zwischen Legacy-Systemen und den neuen FHIR-nativen Microservices. ![](image-3.avif) - **Schrittweise Erweiterung des FHIR-nativen Fußabdrucks** Migrieren Sie weitere Services inkrementell: Validieren Sie den POC-Service in der Produktionsumgebung - Identifizieren und priorisieren Sie nachfolgende Services für die Migration - Erweitern Sie den FHIR-nativen Fußabdruck schrittweise durch Hinzufügen neuer Microservices und Migration bestehender Services ![](image-4.avif) - **Beispiel: Patientenportal, das Patienten die Planung und Verwaltung ihrer Besuche ermöglicht** Schritt 1: Beginnen Sie mit einem POC – einem Patientenportal, das Patienten ermöglicht, ihre Patienteninformationen und Termine einzusehen. ![](image-5.avif) Schritt 2: Fügen Sie einen neuen Service für die Terminbuchung hinzu. ![](image-6.avif) Schritt 3: Fügen Sie einen weiteren Service für die Erfassung von Patientenfeedback zu den Besuchen hinzu. ![](image-7.avif) ## 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** – Gewährleistung langfristiger Interoperabilität mit anderen Gesundheitssystemen - **Effektiv** – Reduzierung der Entwicklungszeit durch standardisierte Muster - **Robust** – Nutzung eines ausgereiften, gesundheitsspezifischen Standards - **Konform** – Vereinfachung der Einhaltung von Vorschriften wie US Core-Profilen für den 21st Century Cures Act - **Ökosystem-reich** – Profitiert vom wachsenden FHIR-Ökosystem aus Tools und Implementierungen Sind Sie bereit, FHIR-native Microservices in Ihrer Gesundheitsorganisation einzuführen? Bei Health Samurai haben wir Dutzende von Gesundheitsorganisationen erfolgreich beim Übergang zu FHIR-nativen Plattformen begleitet. Ob Sie ein neues Projekt starten oder Legacy-Systeme modernisieren – unser Team unterstützt Sie gerne. Nehmen Sie Kontakt mit mir, [Aleksandr Kislitsyn](https://www.linkedin.com/in/aleksandr-kislitsyn-297854112/), auf LinkedIn auf, um Ihren spezifischen Anwendungsfall zu besprechen und zu erfahren, wie wir Ihnen helfen können, Ihre Ziele zur Interoperabilität im Gesundheitswesen zu erreichen. Siehe auch: [Warum Sie einen unabhängigen FHIR-Server benötigen](/blog/why-you-need-independent-fhir-server-side-by-side-with-your-ehr-system).