Die Mathematik der Fragmentierung
Eine Gesundheitsorganisation mit 15 Quellsystemen verfügt technisch gesehen über bis zu 105 mögliche Point-Integrationen. Diese Zahl ergibt sich aus einer einfachen Formel: Bei n Systemen gibt es n*(n-1)/2 mögliche direkte Verbindungen. Fügen Sie ein System hinzu, wächst diese Zahl quadratisch — nicht linear.
Selbst wenn nur 10 % dieser möglichen Verbindungen tatsächlich benötigt werden, sind das schnell 10 separate Integrationen. Jede davon verfügt über eigenes Versionsmanagement, eigenes Monitoring, eigene Sicherheitsattribute, eigene Testpipeline und eigene Dokumentation. Die kognitive Belastung des IT-Teams wächst entsprechend.
Und die Anzahl der benötigten Verbindungen steigt weiter. Ein neues HR-System, das mit Abrechnung, Planung und HR-Reporting kommunizieren muss? Das sind bereits drei neue Integrationen — obwohl es sich nur um ein einziges System handelt. Wegiz, EHDS und die fortschreitende Digitalisierung verringern diese Zahl nicht; im Gegenteil.
“Die Rechnung der Fragmentierung wird jeden Monat bezahlt — nur erscheint sie nie auf einer einzigen Rechnung.”
Versteckte Kosten, die nicht auf der Rechnung erscheinen
Die direkten Entwicklungskosten einer Integration wirken überschaubar — einige Wochen Arbeit, einige Tausend Euro je Verbindung. So wird das Thema in einer Management-Entscheidung häufig dargestellt. Es ist jedoch nicht das vollständige Bild.
Die indirekten Kosten sind der eigentliche Schmerzpunkt. Ausfallzeiten: Wenn System A ausfällt, brechen auch die Integrationen mit B, C und D zusammen. Doppelte Erfassung: Wenn eine Verbindung versagt, geben Gesundheitsfachkräfte dieselben Daten in mehrere Systeme ein. Compliance-Nachweis je Verbindung: Für jede einzelne Integration müssen DSGVO-Folgenabschätzung, Risikoanalyse, Penetrationstest und Audit-Trail gepflegt werden.
Bei jedem Versions-Update eines Endpunkts muss die Gegenstelle getestet und gegebenenfalls angepasst werden. Bei 10 Verbindungen, die jeweils zweimal jährlich ein Update erhalten, sind das 20 Regressionstest-Zyklen pro Jahr, die strukturell schlicht niemand durchführt. Das Ergebnis: fragile Integrationen, die zum denkbar ungünstigsten Zeitpunkt versagen.
Warum eine FHIR-Schicht die Kurve durchbricht
FHIR ist kein Softwareprodukt; es ist eine semantische Vereinbarung. HL7 veröffentlicht FHIR (Fast Healthcare Interoperability Resources) als offenen Standard, mit dem Gesundheitskonzepte strukturiert über RESTful APIs ausgetauscht werden. Die Ressourcen sind vertraut: Patient, Observation, MedicationRequest, Encounter und so weiter.
Indem alle Quellen auf FHIR normalisiert werden — indem jedes System seine Daten auf die gemeinsamen FHIR-Ressourcen projiziert — wird jede Erweiterung linear statt exponentiell. Für 15 Systeme bedeutet das 15 Verbindungen statt 105. Noch wichtiger: Jedes weitere System erfordert denselben Aufwand wie das vorherige.
Dies ist nicht nur ein technischer Vorteil. Es verschiebt das Verkehrssystem Ihrer Organisation von einem Geflecht direkter Verbindungen hin zu einem standardisierten Austauschraum. Wer neu angebunden wird, muss lediglich das FHIR-Mapping erstellen — keine 14 separaten Integrationen mit bestehenden Systemen.
Was dies für den Business Case bedeutet
Der Gewinn liegt nicht nur in weniger Entwicklungsaufwand, sondern in der Skalierbarkeit: Neue Anwendungsfälle hinzuzufügen wird eine Frage von Wochen statt Quartalen. Ein KI-Agent, der Intake-Daten aus drei Systemen nutzen möchte? Das ist eine einzige FHIR-Abfrage, keine drei neuen Integrationen.
Und vielleicht noch wichtiger: Die Prüfung wird einfacher. Eine einzige Quelle der Wahrheit je Datenklasse, ein zentraler Ort für Zugriffsrichtlinien, ein gemeinsames Audit-Log. Compliance wird zu etwas, das Sie nachweisen, nicht zu etwas, das Sie rekonstruieren. Wegiz fordert einen standardisierten elektronischen Austausch — eine FHIR-Schicht ist genau das.
Die Total Cost of Ownership über einen Zeitraum von fünf Jahren zeigt in der Regel, dass eine gemeinsame Integrationsschicht irgendwo zwischen dem zweiten und dritten Jahr den Break-even erreicht. Danach wird jede neue Verbindung kumulativ günstiger, während der Point-to-Point-Weg jedes Mal neu zum vollen Preis beginnt.
Häufig gehörte Einwände — und warum sie nicht zutreffen
"Eine zentrale Schicht ist ein Single Point of Failure." Das stimmt nicht, wenn sie sorgfältig aufgebaut wird. Ein FHIR-Server kann redundant und verteilt betrieben werden, mit Failover und getrennten Lese-/Schreibpfaden. Der Single Point of Failure entsteht gerade bei Point-to-Point-Verbindungen, bei denen ein Endpunkt für zwanzig Systeme kritisch wird.
"Unsere Anbieter unterstützen kein FHIR." Das galt bis vor einigen Jahren. Inzwischen veröffentlichen große ECD- und EPD-Anbieter FHIR-Endpunkte, und FHIR-Mapping für spezifische Unterstützungssysteme ist über Gateways und Adapter möglich. Die Wegiz-Frist beschleunigt diese Unterstützung schneller, als viele Anbieter geplant hatten.
"FHIR ist zu generisch für unseren Anwendungsfall." Das trifft selten zu. FHIR-Erweiterungen und -Profile — wie die niederländischen Nictiz-Profile — lassen genau Raum für sektorspezifische Felder, ohne den gemeinsamen Kern aufzugeben. Was lokal bleiben muss, bleibt lokal; was übertragbar sein muss, bleibt übertragbar.
Wie migrieren Sie von Point-to-Point zu FHIR?
Der pragmatischste Ansatz: Tun Sie es nicht auf einmal. Eine Big-Bang-Migration von 10 Verbindungen gleichzeitig ist ein Rezept für Unterbrechungen. Arbeiten Sie stattdessen mit einem Strangler-Pattern — bauen Sie die FHIR-Schicht neben den bestehenden Integrationen auf, schalten Sie diese eine nach der anderen um, und ziehen Sie die alten Verbindungen zurück, sobald die neuen stabil sind.
Beginnen Sie mit der schmerzhaftesten Verbindung. Welche Integration kostet die meiste Zeit, fällt am häufigsten aus oder wird am stärksten durch Compliance-Fragen blockiert? Dort liegt der Business Case. Die erste FHIR-Verbindung ist eine Investition; die zweite und dritte liefern bereits messbare Zeitgewinne.
Reservieren Sie schließlich ein Team, das Eigentümer der Integrationsplattform ist — nicht eine Einzelperson, nicht eine rotierende Besetzung durch Zeitarbeitskräfte. Eine gemeinsame FHIR-Schicht erfordert Kontinuität der Expertise, andernfalls entsteht das alte Problem in neuer Form: eine zentrale Infrastruktur, für die sich niemand verantwortlich fühlt.
