Wenn FHIR-Implementierer fragen „Welche FHIR-Version sollte ich verwenden?", nehmen Einsteiger häufig an, dass es naheliegt, die neueste Version zu wählen. Stand Oktober 2025 wäre das FHIR R5, was wie die offensichtliche Wahl erscheint. Die Entscheidung ist jedoch komplexer, da Faktoren wie Kompatibilität, Verbreitung und Stabilität sorgfältig abgewogen werden müssen. Dieser Beitrag bietet einen praxisorientierten Überblick über die wichtigsten Details, Vor- und Nachteile sowie Erkenntnisse aus unserer Erfahrung mit der Unterstützung von FHIR-Implementierungen – einschließlich eines Ausblicks auf das, was R6 bringen könnte.
Was ist neu in FHIR R5
Insgesamt umfasst FHIR R5 gegenüber der Vorgängerversion über 4.000 Änderungen unterschiedlichen Umfangs. Eine Liste der wesentlichen Änderungen in FHIR R5 finden Sie unter folgendem Link.
Zwei davon stechen als besonders bedeutsam heraus: neue Ressourcentypen und die überarbeitete themenbasierte Subscription-Funktion. Werfen wir einen genaueren Blick auf beide.
Neue Ressourcentypen
FHIR R5 führt mehr als 20 neue Ressourcentypen ein, darunter 8 Typen im neuen Modul „Medication Definition". Dieses Modul beschreibt Arzneimittel detailliert – einschließlich Inhaltsstoffen, Verpackung, Darreichungsformen, Zulassungsstatus und klinischen Anwendungsgebieten. Damit wird FHIR für Arzneimittelkataloge, regulatorische Einreichungen und Sicherheitssysteme nützlicher, die vollständige Produktinformationen benötigen.
Obwohl diese neuen Ressourcen die Möglichkeiten von FHIR erweitern, sind sie in puncto Interoperabilität möglicherweise kein „Game-Changer". Die meisten FHIR-Server haben einige der Lücken in der Spezifikation bereits durch benutzerdefinierte Ressourcen geschlossen. Wer diese Ressourcentypen benötigte, hatte bereits Workarounds gefunden. Selbst wenn Sie mit R5 fortfahren und neue Ressourcentypen übernehmen, könnten Integrationspartner Schwierigkeiten haben, diese direkt zu nutzen, da die meisten Systeme – einschließlich großer nationaler und herstellerseitiger Ökosysteme – weiterhin auf R4 basieren. Dies macht den Vorteil der Verwendung standardmäßiger R5-Ressourcentypen zunichte.
Subscriptions
FHIR R5 hat das Subscription-Framework vollständig überarbeitet und die themenbasierte Subscription-Funktion eingeführt, um ereignisgesteuerte Benachrichtigungen zu standardisieren. Dies erleichtert die Definition von und das Abonnieren von Ereignistypen (z. B. „neues Laberergebnis für Patient X") und ermöglicht es Implementierern, bessere Echtzeit-Workflows zu realisieren – was für EHR-Benachrichtigungen, den öffentlichen Gesundheitsbereich und CDS wichtig ist. Das ist ein Gewinn für Systeme, die Echtzeit-Benachrichtigungen benötigen. Diese Funktionalität setzt jedoch kein FHIR R5 voraus: HL7 hat eine Zwischenversion eingeführt – R4B –, die im Wesentlichen R4 mit dem rückportierten SubscriptionTopic-Framework ist. Darüber hinaus sind auch FHIR-Server hierbei nicht eingeschränkt: Es ist möglich, benutzerdefinierte Ressourcen zu nutzen, um Subscriptions in jeder FHIR-Version zu ermöglichen (wie wir es in Aidbox getan haben).
Nachdem wir nun gesehen haben, was in R5 neu ist, wollen wir diese Verbesserungen den Herausforderungen eines Upgrades gegenüberstellen.
Warum Kunden gegenüber FHIR R5 zögerlich sind
FHIR R5 ist die aktuellste offizielle Version von FHIR, dennoch bleibt die Adoptionsrate in der Branche – einschließlich unserer Kunden – gering. FHIR R5 enthält Breaking Changes und ist nicht abwärtskompatibel, was es für Organisationen schwierig macht, ohne erheblichen Aufwand von FHIR R4 zu wechseln. Die Gründe lassen sich in zwei Kategorien einteilen.
Probleme mit der Abwärtskompatibilität
Einer der größten Kritikpunkte an R5 ist die fehlende Abwärtskompatibilität. Viele Organisationen haben ihre Systeme auf FHIR R4 aufgebaut, das derzeit die stabilste und am weitesten verbreitete Version ist. Während einige Ressourcen wie Patient und Observation zwischen R4 und R5 nur minimale Änderungen erfahren haben, wurden andere gezielt refaktoriert. Sehen wir uns einige Beispiele an.
Eine der am häufigsten verwendeten Ressourcen – AllergyIntolerance – hat 3 neue Eigenschaften erhalten (darunter eine obligatorische), 2 Eigenschaften verloren und den Datentyp des Elements type von code zu CodeableConcept geändert.
Dieses FHIR R4 AllergyIntolerance-Ressourcen-Snippet:
{
...
"type": "allergy",
"recorder": {
"reference": "Practitioner/example"
},
"asserter": {
"reference": "Patient/example"
}
...
}
würde in FHIR R5 so aussehen:
{
...
"type" : {
"coding" : [{
"system" : "http://hl7.org/fhir/allergy-intolerance-type",
"code" : "allergy",
"display" : "Allergy"
}]
},
"participant" : [{
"actor" : {
"reference" : "Practitioner/example"
}
},
"actor" : {
"reference" : "Patient/example"
}
}]
}
Sie können selbst beurteilen, wie groß der Unterschied ist – und das ist nur eine von Dutzenden solcher Anpassungen. Die vollständige Liste finden Sie hier: https://hl7.org/fhir/R5/diff.html
Große EHR-Anbieter wie Epic und Oracle Health (ehemals Cerner) haben stark in R4-basierte APIs und Integrationen investiert – Epic mit seiner „Epic on FHIR"-Plattform und Oracle mit den FHIR R4-APIs der Millennium-Plattform, einschließlich des Bulk Data-Zugriffs. Beide Unternehmen unterstützen FHIR R5 offiziell nicht. Das bedeutet, dass alle, die in diese Ökosysteme integrieren, am besten damit beraten sind, nativ mit R4 zu arbeiten, um Interoperabilität sicherzustellen. Gleichzeitig erfordert ein Upgrade auf R5 die Neugestaltung von Datenmodellen, APIs und Integrationen sowie komplexe Datenmigationen – was einen solchen Wechsel für Organisationen, die stark auf nahtlose FHIR-Interoperabilität angewiesen sind, sowohl kostspielig als auch risikoreich macht.
Der Industriestandard: FHIR R4
Da der Großteil der Welt derzeit auf FHIR R4 arbeitet, wird es voraussichtlich noch jahrelang dominant bleiben. In den USA wird die Position von R4 durch Regulierung gestärkt – durch den US Core Implementation Guide und seine Verbindung zum USCDI-Standard, den ONC für zertifizierte Gesundheits-IT vorschreibt. Ähnliche staatlich getriebene Programme in anderen Ländern haben ebenfalls auf R4 standardisiert und treiben Anbieter und Leistungserbringer zur Compliance. Selbst der International Patient Summary IG, der von der WHO unterstützt und in mehreren Regionen für den grenzüberschreitenden Gesundheitsdatenaustausch eingesetzt wird, basiert auf FHIR R4.
Unser öffentliches FHIR-Paketregister, das alle öffentlichen IGs enthält, liefert ebenfalls Analysedaten, die diese Aussagen unterstützen.
Aufgrund dieser tiefen Integration erhöht die Verwendung von FHIR R4 die Kompatibilität mit der überwiegenden Mehrheit der bestehenden FHIR-basierten APIs und Ökosysteme. Diese weit verbreitete Nutzung erleichtert die Anbindung an andere Gesundheitssysteme und fördert einen reibungsloseren Datenaustausch und eine bessere Interoperabilität innerhalb nationaler und grenzüberschreitender Gesundheitsnetzwerke.
Diese Faktoren erklären, warum in der FHIR-Community diskutiert wird, ob der Wechsel zu R5 jetzt erfolgen oder direkt zu R6 übergegangen werden soll.
Die Zukunft: R5 überspringen und direkt zu R6?
Einige in der FHIR-Community schlagen vor, R5 gänzlich zu überspringen und direkt von R4 zu R6 zu wechseln – dies ist jedoch keine offizielle Position von HL7. Da FHIR R5 ein Trial-Use-Release mit Breaking Changes und begrenzter Verbreitung bei Anbietern und nationalen Implementierungen ist, sind viele Implementierer nicht bereit, in eine Version zu investieren, die bald obsolet werden könnte.
Es wird erwartet, dass R6 die Abwärtskompatibilität teilweise wiederherstellt und die in R5 eingeführten Änderungen festschreibt, indem die am häufigsten verwendeten Ressourcen normativ gemacht werden – das heißt: stabil, produktionsreif und gegen Breaking Changes gesichert. Die FHIR-Community strebt nun außerdem danach, weitere disruptive Änderungen zu vermeiden und auf Stabilität hinzuarbeiten.
Infolgedessen könnte es für Organisationen, die langfristige Stabilität und Ökosystem-Ausrichtung priorisieren, strategisch sinnvoller sein, vorerst bei R4 zu bleiben und eine direkte Migration zu R6 zu planen, sobald diese Version breitere Verbreitung und Tool-Unterstützung erreicht hat. Bei Health Samurai planen wir, Werkzeuge bereitzustellen, die eine reibungslosere direkte Migration zu FHIR R6 in Aidbox ermöglichen.
Der R6-Zeitplan ist bewusst gewählt: Der erste „Normative"-Ballot ist für Januar 2026 geplant, mit zwei weiteren bereits vorgesehenen Ballots. Weitere Runden werden vor einer endgültigen Veröffentlichung erwartet, sodass der Standard vor 2027 nicht fertiggestellt sein dürfte. In der Zwischenzeit werden die kommenden FHIR Cross-Version Extensions es ermöglichen, ausgewählte R5- oder R6-Funktionen zu übernehmen, während der Betrieb weiterhin auf R4 basiert. Dieser Ansatz ermöglicht es Organisationen, einige der Vorteile neuerer Versionen zu nutzen, ohne die Risiken und Kosten einer frühzeitigen vollständigen Migration einzugehen.
Welche FHIR-Version sollten Sie wählen?
Obwohl Aidbox FHIR R5 unterstützt, zeigen unsere Metriken, dass lediglich ~5 % der Nutzer es einsetzen. Sofern es keine zwingenden, spezifischen Anforderungen gibt, die nur FHIR R5 erfüllen kann, empfehlen wir ernsthaft, die Einführung vorerst zurückzustellen. Die Beibehaltung von FHIR R4 bietet Stabilität, breite Branchen- und Ökosystemunterstützung sowie einen klaren Integrationspfad mit bestehenden FHIR-APIs und Implementation Guides.
FHIR R4 bleibt die sicherste und praktischste Wahl. Wir werden die Entwicklung des Übergangs zu R6 weiter beobachten, aber für diejenigen, die ein Upgrade in Betracht ziehen, lohnt es sich wahrscheinlich, abzuwarten, anstatt R5 verfrüht zu übernehmen – insbesondere mit R6 am Horizont.
Siehe auch: Der FHIR-Leitfaden für CTOs.
