openEHR oder HL7 FHIR? Falsche Frage — Lost in Translation

Innerhalb weniger Monate haben 2026 Gesundheitsbehörden in Wales und Australien, Fachgremien in der Schweiz und in Österreich, ein vom spanischen Gesundheitsministerium beauftragtes Expertengremium sowie ein großer Industriekonzern dieselbe Architekturfrage beantwortet, und zwar unterschiedlich. Der vertraute Wettstreit „openEHR gegen FHIR“ stellt das Problem falsch. Die Entscheidungen, die darüber bestimmen, ob klinische Daten interoperabel werden, liegen woanders. Dieser Beitrag versucht sie zu benennen.

Kaum ein Monat vergeht, in dem nicht irgendwo in Europa eine grundlegende Entscheidung zur Speicherung und zum Austausch klinischer Daten fällt. Ein paar Beispiele aus diesem Jahr.

Im Mai 2026 empfahl die Schweizer Fachgruppe Datenmanagement im Gesundheitswesen HL7® FHIR® als verbindlichen Standard für Schnittstellen und Transaktionen im Swiss Health Data Space, ließ die interne Speicherung aber ausdrücklich offen. Wales hat FHIR bereits 2023 verbindlich gemacht und betreibt sein nationales Datenrepository heute als nativen, dauerhaften FHIR-Speicher. In Österreich fordert die ÖGTelemed eine herstellerneutrale Persistenzschicht und nennt dafür openEHR und FHIR als Kandidaten. Ein Whitepaper von Siemens Healthineers erklärt FHIR zur Pflichtbasis und openEHR zur optionalen Zusatzschicht für forschungsintensive Umgebungen. Außerhalb Europas schließlich erkennt die australische Digital-Health-Agentur beide Standards an, weist ihnen separate Rollen zu und beschreibt die Modernisierung ihrer nationalen Akte im selben Atemzug als „FHIR-native“.

Am weitesten reicht die jüngste dieser Festlegungen, und sie weist in die andere Richtung. Ein im Auftrag des spanischen Gesundheitsministeriums erstellter Delphi-Konsens empfiehlt 2026 openEHR als geeignetsten Standard für die nationale digitale Krankenakte, mit FHIR auf der Austauschschicht und einem Mapping, das gemeinsam mit dem klinischen Wissensmodell zu definieren ist. Das ist die gewichtigste institutionelle Rückendeckung, die die openEHR-Seite bisher hat. Ihre Grenzen reisen mit: Das Papier bezeichnet seine Empfehlungen selbst als nicht evidenzbasiert, seine Autorenschaft überschneidet sich offen mit der Führung von openEHR International, und es ist eine Empfehlung an das Ministerium und keine beschlossene Strategie.

Neben diesen Festlegungen entstehen an mehreren Orten Clinical Data Repositories (CDR) in beiden Formen: FHIR-basiert etwa in der Lombardei, nach Darstellung der Umsetzenden für rund zehn Millionen Patientinnen und Patienten, als openEHR-Repository etwa in Slowenien und Schweden.

Sechs Festlegungen, eine Frage, verschiedene Antworten. Die Debatte, wie sie üblicherweise geführt wird, verstellt den Blick auf die Entscheidungen, die wirklich zählen.

Auf EU-Ebene ist die Richtung für den hier untersuchten Datenaustausch klar: Die laufende EHDS-Umsetzung und MyHealth@EU verwenden FHIR, und in Deutschland verweist § 355 SGB V ebenfalls darauf. Ein vergleichbarer europäischer regulatorischer Anker für openEHR fehlt. Das sagt nichts über die technische Eignung beider Standards aus und schreibt auch kein internes Persistenzmodell vor. Es prägt jedoch das politische und beschaffungspraktische Umfeld.

Das neueste deutsche Instrument zeigt, wie leicht ein solcher Anker überdehnt wird. Das Gesetz für Daten und digitale Innovation im Gesundheitswesen (GeDIG) hat das Bundeskabinett am 15. Juli 2026 beschlossen.

Im Referentenentwurf war in § 386 SGB V ein Absatz vorgesehen gewesen, der von Leistungserbringern verlangte, Gesundheitsdaten im interoperablen Format vorzuhalten und auszutauschen. Im Kabinettsentwurf trägt ihn kein verfügender Teil mehr, und § 386 SGB V wird durch den Entwurf gar nicht geändert. Eine Spur ist allerdings geblieben: Vorblatt und Allgemeiner Teil der Begründung sagen weiterhin, Leistungserbringer müssten Gesundheitsdaten künftig im interoperablen Format vorhalten und Hersteller müssten diese Datenhaltung in den Systemen ermöglichen. Wer die Zusammenfassung zuerst aufschlägt, nimmt also eine Pflicht mit, die der Gesetzestext nicht begründet.

Im verfügenden Teil steht die Interoperabilitätspflicht des § 386a SGB V, die sich an die Hersteller informationstechnischer Systeme richtet, sie zur Herausgabe der Patientendaten und zur Zugriffsgewährung im interoperablen Format verpflichtet und deren Format einer Rechtsverordnung vorbehalten bleibt. Für die Architekturfrage folgt daraus weniger, als gemeinhin hineingelesen wird.

Die Pflicht bindet die Austauschschicht, nicht das Speichermodell. Wer sie in einer Ausschreibung als Grund anführt, die Datenhaltung festzulegen, zieht einen Schluss, den das Gesetz nicht hergibt, und für openEHR gilt dasselbe. So wird der verfügende Teil hier gelesen, und das ist eine Auslegung und keine Rechtsauskunft. Der Entwurf umfasst 265 Seiten und nennt darin keinen einzigen Standard beim Namen.

Ein Wort zum Rahmen. All dies beschreibt Europa. Dort gilt die hier behandelte Regulatorik, und dort ist openEHR zugleich am stärksten vertreten, das Spielfeld ist also kein neutrales. In einer weltweiten Stichprobe sähe das Bild anders aus: Die für diesen Beitrag ausgewerteten Quellen belegen openEHR-Einsätze im Wesentlichen in Europa, Australien ist auf der Ebene der Politik vertreten und nicht auf der laufender Systeme. Die Befunde zu den Transformationsschichten und zu den Kosten, die daraus folgen, tragen über Europa hinaus. Nichts hier sagt etwas darüber, wie sich die beiden Standards in nicht untersuchten Märkten verteilen.

Der Konsens ist größer, als es scheint – und der Dissens kleiner

Wenn man diese Dokumente nebeneinander liest, fällt ein doppeltes Muster auf. Einerseits behandeln sie alle FHIR als den Standard für den Datenaustausch. Darüber gibt es keinen Streit. Andererseits dreht sich der verbleibende Dissens allein um die Frage, ob openEHR die notwendige, die empfohlene oder die optionale Schicht für die interne Speicherung ist oder ob sie gänzlich verzichtbar ist. Die Variante, die früher ernsthaft diskutiert wurde, nämlich openEHR allein für Speicherung und Austausch, ist praktisch vom Tisch.

Damit lautet die zentrale Frage: Wird FHIR genutzt, dann auch als Speicher, oder legt man openEHR als Persistenzschicht darunter? Doch selbst diese Zuspitzung greift zu kurz. Über die Gestalt eines Systems entscheiden zwei Tatsachen, und keine davon ist die Wahl eines Standards. Wo wird der klinische Datensatz geschrieben, und in welchem Modell wird er gehalten? Kreuzt man beides, ergeben sich fünf nützliche architektonische Idealtypen und nicht drei. Sie decken die wesentlichen Kombinationen ab, aber nicht jede denkbare Systemgestaltung.

Was sie trennt, ist die Anzahl der Übersetzungen, die klinische Inhalte auf ihrem Weg von der Erfassung zur Nutzung durchlaufen. Dabei lohnt sich Genauigkeit darüber, was überhaupt zählt. Jedes System bildet eine Eingabemaske auf eine Speicherstruktur ab, und für diese Abbildung steht heute jeder Hersteller ein. Sie ist nicht gemeint. Gezählt wird, in wie vielen getrennt kontrollierten klinischen Modellen derselbe Inhalt zugleich wahr sein muss. Denn dort muss eine Abbildung geschrieben, klinisch validiert und richtig gehalten werden, während sich beide Seiten weiterbewegen. Ein Cache oder ein Index, der aus dem Datensatz wiederhergestellt werden kann, ist kein zweites Modell. Über seine klinische Richtigkeit wacht nichts außerhalb des Systems.

Ausgeschrieben sehen die fünf so aus.

Ein Datensatz, der im herstellereigenen Modell geschrieben und gehalten wird und aus dem FHIR auf Anfrage entsteht, überschreitet eine Grenze und behält davon nichts. Derselbe Datensatz, im Herstellersystem geschrieben, aber zusätzlich in einem FHIR-Speicher gehalten, überschreitet ebenfalls eine, und diesmal bleibt das Ergebnis erhalten, validiert und wiederverwendbar. Das ist die Anordnung, die in Wales und in den deutschen Datenintegrationszentren im nationalen Maßstab läuft, und sie ist inzwischen im deutschen Markt als Produkt zu haben.

Ein nativ in FHIR geschriebener und gehaltener Datensatz benötigt nur dann keine kontrollierte Konversion, wenn seine maßgebliche Repräsentation mit dem geforderten Austauschprofil kompatibel ist. Ein im Herstellersystem geschriebener und in einem openEHR-Speicher gehaltener Datensatz, aus dem FHIR erzeugt wird, überschreitet zwei. Und ein nativ in openEHR geschriebener überschreitet eine, genau wie der erste Fall.

Zwei Punkte in dieser Aufzählung tragen das Argument, und sie ziehen in verschiedene Richtungen. Der erste und der letzte Fall haben dieselbe Mindestzahl an Konversionen und können an der Austauschgrenze nicht unterscheidbare konforme Nutzdaten erzeugen. Wirtschaftlich und architektonisch gleichwertig sind sie deshalb nicht. Der Fall für openEHR ist dort zu machen, wo er tatsächlich liegt: bei Modellierungstiefe, Archetyp-Governance und der Stabilität von Modellen über lange Zeiträume.

Der zweite Punkt läuft in die Gegenrichtung. Wo FHIR als Austauschrepräsentation gefordert ist, muss ein in openEHR gehaltener Datensatz mindestens eine kontrollierte Grenze zwischen Standards überschreiten. Ein in FHIR gehaltener Datensatz kann diese Grenze vermeiden, wenn seine Repräsentation mit dem geforderten Austauschprofil kompatibel ist. Unterschiede zwischen FHIR-Profilen und Abbildungen aus Quellsystemen können trotzdem Transformation und Validierung erfordern. Die Asymmetrie folgt aus dem festgelegten Austauschziel und nicht aus der technischen Güte eines Standards.

Bei der Null lohnt das Innehalten, denn sie klingt nach Phantasie und ist keine. Gemeint ist kein System ohne innere Strukturen, so arbeitet nichts. Gemeint ist, dass der maßgebliche klinische Datensatz FHIR ist und sich die herstellereigenen Strukturen auf Anwendungszustand, Arbeitsabläufe, Bildschirmleistung und abgeleitete Indizes beschränken, die aus ihm wiederherstellbar sind. So formuliert ist das gewöhnliche Ingenieurarbeit, bei der Abnahme prüfbar und im Neubau ausschreibbar.

Kein umfassendes Produkt erfüllt es heute nachweislich. Ein Bundesministerium hat ein Vorhaben gefördert, dessen erklärtes Ziel genau das ist. Und ein Anbieter von Pflegedokumentation erklärt auf Nachfrage, seine Produkte schrieben klinische Inhalte unmittelbar als FHIR-Ressourcen über den FHIR-Client, das Repository sei austauschbar, wo FHIR R4 unterstützt wird, und acht Krankenhäuser liefen auf dieser Grundlage auf einem Fremd-Repository. Das ist die Aussage des Anbieters über die eigene Architektur, sie betrifft ein Dokumentationssystem am Ort der Versorgung und keine vollständige klinische Primärakte, und unabhängig geprüft ist sie nicht.

Das andere Ende der Tabelle ist ebenso begrenzt. Ein nativ in openEHR erfassendes Primärsystem ist für einen Hersteller in einem nationalen Markt dokumentiert, DIPS Arena in Norwegen, untersucht in einer Langzeitstudie einer Regionalgesundheitsbehörde, in der dieser Hersteller 82 % des Marktes hält, und im deutschen, österreichischen und schweizerischen Markt ist im hier ausgewerteten Material kein vergleichbares, allgemein beschaffbares Angebot aufgetaucht.

Neu bauen ist eine engere Kategorie, als es klingt. Gemeint ist eine Persistenzschicht, für die für die fraglichen Daten noch kein Speichermodell im Produktivbetrieb festliegt. Ein Vorhaben, das beschaffungsrechtlich neu ist, aber in ein bestehendes Repository schreibt, gehört nicht dazu, und eine Ablösung zählt nur so lange, wie ihr Speichermodell zum Zeitpunkt der Vergabe wirklich offen ist. Diese Unterscheidung trägt für das ganze Argument Gewicht. Wo Daten repliziert und nicht am Ort der Erfassung geschrieben werden, unterscheidet die Zählung der Transformationsschichten weniger scharf: In einer Sekundärnutzungsplattform und in einem Repository neben einem laufenden Primärsystem steht mindestens eine Transformation fest, bevor überhaupt gewählt wird. Übrig bleibt der kleinere Unterschied in den Schichten danach.

Aus dieser Umdeutung folgen fünf Einsichten, die in Planungen und Ausschreibungen einfließen sollten.

1 Die alte Arbeitsteilung ist nicht mehr die einzige Option

Jahrelang galt die bequeme Formel „openEHR speichert, FHIR tauscht aus“. Sie bleibt eine tragfähige Architektur, ist aber nicht mehr die einzige standardbasierte Möglichkeit, weil dauerhafte FHIR-Repositorien inzwischen auch die Speicherrolle übernehmen können. Was openEHR und FHIR auf der Speicherebene trennt, ist kein Eignungsunterschied, sondern eine Frage des Modellierungsansatzes. FHIR beschreibt klinische Inhalte gezielt für Austausch und Anwendungen. openEHR bildet sie möglichst vollständig und dauerhaft ab. Ungeeignet für die Speicherung ist deshalb keiner von beiden.

Die Machbarkeit des FHIR-nativen Ansatzes ist belegt. Wales betreibt einen nationalen, dauerhaften FHIR-Speicher, und die 41 Datenintegrationszentren der Medizininformatik-Initiative strukturieren ihre Versorgungsdaten nach dem FHIR-basierten Kerndatensatz. Allein an Laborwerten weist das Forschungsdatenportal für Gesundheit dort mehr als drei Milliarden Datensätze aus, dazu mehrere Hundert Millionen Diagnosen, Prozeduren und Medikationsdaten zu über 27 Millionen Personen.

Weitere Fälle sind inzwischen in vergleichbarer Größenordnung dokumentiert. Die Türkei betreibt ein nationales FHIR-Repository, berichtet im Milliarden-Ressourcen-Bereich mit rund 38 Milliarden FHIR-Ressourcen zu etwa 32 Millionen Patientinnen und Patienten. Die italienische Region Lombardei betreibt ein FHIR-basiertes Clinical Data Repository für rund zehn Millionen Einwohnerinnen und Einwohner. Beide Zahlen stammen aus Vorträgen der Umsetzenden selbst, und genau dieses Gewicht haben sie, eine unabhängige Messung ist keine von beiden.

Unabhängige Studien zur Wirksamkeit fehlen weiterhin, und die Machbarkeit ist nur so weit gezeigt, wie die Fälle reichen. In den für die zugrunde liegende Analyse untersuchten Fällen, Wales eingeschlossen, entstehen die Daten in den Primärsystemen und werden von dort extrahiert und nach FHIR transformiert. Die Türkei und die Lombardei gehören nicht dazu. Die zweite Übersetzung zwischen Speicher- und Austauschmodell entfällt damit, die erste zwischen Quellsystem und Zielmodell bleibt bestehen. Belegt ist also der Betrieb großer FHIR-nativer Speicher, nicht ein Primärsystem, in dem die klinische Dokumentation unmittelbar als FHIR-Ressourcen erfasst wird.

2 Die Abbildungsschichten sind der Preis, der zu selten genannt wird

Wer Persistenz und Austausch trennt und etwa einen openEHR-Speicher unter eine FHIR-Brücke legt, zahlt eine dauerhafte Abbildungslast. Sie umfasst es, jeden klinischen Inhalt, der die Grenze überschreitet, auf beiden Seiten angemessen abzubilden und die Beziehung zwischen den beiden Abbildungen zu pflegen, während sich beide Modellwelten weiterentwickeln, dazu Transformationslogik samt Terminologiebindung und Einheitenumrechnung für jeden Anwendungsfall. Hinzu kommen das Risiko von Bedeutungsverlusten beim Hin- und Rückweg, sich ändernde Versionen auf beiden Seiten und ein anhaltender Test- und Validierungsaufwand. Diese Kosten steigen mit der Anzahl der Anwendungsfälle, werden in den hier ausgewerteten Projektberichten als zu niedrig angesetzt beschrieben und verschwinden auch nicht mit besserer Technik, weil sie dem Nebeneinander zweier Modellwelten innewohnen. Mapping ist kein Einmalprojekt, sondern eine dauerhafte Architekturentscheidung.

Mapping ist kein Einmalprojekt, sondern eine dauerhafte Architekturentscheidung.

Es geht jedoch nicht nur um Geld. Jede Übersetzung klinischer Daten zwischen Modellen, Terminologien oder Systemen schafft neue Fehlerquellen, deren Folgen Patientinnen und Patienten unmittelbar treffen können.

So gehören Schnittstellen- und Migrationsfehler zu den häufigsten IT-bedingten Sicherheitsvorfällen, und Terminologie-Mappings verlieren Granularität und Bedeutungsnuancen, besonders gefährlich bei medikations- und allergierelevanten Informationen. Ein Indikator erster Ordnung ist deshalb die Anzahl der getrennt kontrollierten Konversionen zwischen Erfassung und Nutzung: Je mehr Übersetzungen dazwischenliegen, desto mehr Stellen gibt es, an denen Bedeutung verloren geht, verfälscht wird oder ein Warnhinweis fehlt. Ein Indikator ist das und keine Risikokennzahl, denn was ein einzelner Übergang tatsächlich riskiert, hängt außerdem von Inhalt, Richtung, Häufigkeit, Validierung und Überwachung ab.

Der GeDIG-Entwurf greift genau das auf: § 386c verbietet Herstellern ein Format, das die vollständige semantische Rekonstruktion in einem anderen System verhindert, und ebenso, Datenelemente vorzuenthalten, die zwar nicht verbindlich festgelegt sind, die ein Leistungserbringer aber für seine Dokumentations- und Archivierungspflichten braucht. Das Verbot ist modellneutral und bindet einen openEHR-Speicher wie einen FHIR-Speicher.

Das ist ausdrücklich kein Argument gegen einen einzelnen Standard, denn es betrifft jede mehrstufige Architektur, auch das proprietäre Krankenhausinformationssystem mit vorgelagerter FHIR-Schicht. Doch für die Beschaffung hat es klare Konsequenzen: Die Anzahl der Transformationsschichten muss zu den Bewertungskriterien einer Ausschreibung gehören.

Eine Frage macht dieses Kriterium beantwortbar statt rhetorisch: Welche Strukturen halten den klinischen Inhalt maßgeblich, und lässt sich alles Übrige daraus wiederherstellen? Zwei Anbieter können an der Schnittstelle gleich aussehen und darauf sehr verschieden antworten. Jede Abbildung wiederum braucht eine klinische Validierung durch entsprechend ausgebildetes Fachpersonal, und ein technischer Prüflauf auf Hin- und Rückweg genügt dafür nicht.

Für Medikations- und Allergiedaten lässt sich das prüfbar machen: ein versioniertes, klinisch abgestimmtes Testset sicherheitskritischer Fälle, kein ungelöster Verlust festgelegter sicherheitskritischer Bedeutung, ein dokumentierter Umgang mit Konzepten, die sich nicht abbilden lassen oder mehrdeutig bleiben, klinische Abnahmekriterien mit Regressionstests bei jedem Release und eine Überwachung nach der Inbetriebnahme. Eine Fehlerrate von null lässt sich dagegen nicht nachweisen, und eine Ausschreibung, die sie verlangt, fordert etwas, das kein Anbieter belegen kann.

openEHR kann seine semantische Tiefe genau dort ausspielen, wo sie zählt, nämlich in der primären Erfassung. Sobald diese Daten anschließend weitertransformiert werden, bleiben die klinische Validierung und die Verantwortung für ihre Korrektheit jedoch bestehen.

Herstellerneutral ist nicht dasselbe wie modellunabhängig

Ein Versprechen, das openEHR oft begleitet, lautet: Die Daten überleben die Anwendung. Wer seine klinischen Informationen in einer offenen, herstellerneutralen Form ablegt, so das Argument, ist keinem einzelnen Anbieter mehr ausgeliefert. Das Versprechen ist echt, es trägt aber eine Bedingung, die selten mitgesagt wird.

openEHR-Archetypen kennzeichnen jedes Element mit einem internen Code, einem „at-Code“ von der Form at0006. Diese Codes benennen nicht nur Struktur. Sie können auch als gespeicherter Wert dienen. Eine Instanz hält dann schlicht „at0007“ fest, während die Tatsache, dass at0007 etwa „leichte Beeinträchtigung“ bedeutet, nicht in den Daten steht, sondern im Ontologieabschnitt des Archetyps. Außerhalb seines Archetyps ist ein at-Code bedeutungslos. Ein kodierter Wert in FHIR führt dagegen üblicherweise eine global auflösbare Systemkennung mit sich. Die Spezifikation erzwingt das nicht, denn das System ist optional und ein kodiertes Element darf auch nur Freitext tragen. Wo es angegeben ist, zeigt der Verweis auf die Bedeutung nach außen, in einen adressierbaren Raum, und nicht nach innen in ein lokales Modell.

Für die Beschaffung ist die Folge konkret. Wo lokale at-Codes als Werte verwendet werden, ist die maschinenverarbeitbare Bedeutung der gespeicherten Daten nur gegen den Archetyp oder das operative Template auflösbar. Die Daten sind herstellerneutral, aber nicht modellunabhängig. Die Abhängigkeit ist nicht verschwunden. Sie ist vom Softwarehersteller zur Modellgovernance gewandert. Und weil klinische Daten über Jahrzehnte aufzubewahren sind, ist das nicht akademisch: Das operative Template in genau der Version, mit der ein Datensatz geschrieben wurde, muss viele Jahre später noch verfügbar und interpretierbar sein. Eine verantwortliche Ausschreibung regelt deshalb, wer die operativen Templates in welchen Versionen wie lange aufbewahrt und wie ihre Verfügbarkeit nach Vertragsende oder bei Ausfall eines Herstellers gesichert ist.

Zwei Einschränkungen gehören hierher.

Erstens ist der Punkt gradueller Natur und nicht kategorischer. Auch FHIR ist nicht modellfrei, denn Profile und lokal definierte Codesysteme werfen dieselbe Auflösungsfrage auf, der Unterschied liegt in der Reichweite des Verweises.

Zweitens ist er behebbar. Ein Archetyp, der konsequent an eine externe Terminologie wie SNOMED CT oder LOINC gebunden ist, macht die klinische Bedeutung eines kodierten Werts auch ohne das Modell auflösbar, und genau das ist der Mangel, den der at-Code erzeugt. Selbstbeschreibend wird die Instanz dadurch aber nicht als Ganzes: Struktur, Kardinalitäten, zulässige Wertemengen und der Versionskontext bleiben an den Archetyp oder das operative Template gebunden, die Aufbewahrungspflicht für das Template entfällt also nicht. Ob die Bindung überhaupt geschieht, ist eine Governance-Entscheidung der modellierenden Organisation und keine Eigenschaft des Standards.

Eine dritte Einschränkung zielt in Richtung FHIR, und sie ist die schärfere. Auf beiden Seiten ist der Verweis nach außen optional. Entscheidend ist deshalb nicht, welcher Standard gewählt wurde, sondern ob die Bindung festgelegt ist und ob sie jemand prüft.

FHIR macht den Grad der Verpflichtung ausdrücklich, und zwar in vier Abstufungen. Required lässt nur Codes aus dem genannten Value Set zu. Extensible verlangt einen solchen Code, sofern das Set das Konzept angemessen abbildet, und erlaubt einen anderen, wo es das nicht tut. Preferred und example verpflichten zu gar nichts, und ein Element, dessen Bindung auf example steht, ist vollständig konformes FHIR und erzwingt nichts. Strenge ist dabei kein Wert an sich: Wo ein Begriffsraum bewusst offen bleibt, ist extensible die sachgerechte Wahl und required die falsche.

openEHR hat den Mechanismus, einen optionalen Terminologie-Bindungsabschnitt im Archetyp, aber keine zugehörige Stärke, sodass ein Template nicht ausdrücken kann, ob eine Bindung verbindlich ist. Diese Lücke ist innerhalb von openEHR erkannt: 2020 schlug das dortige Spezifikationsgremium vor, dieselben vier Stärken für Archetypen zu übernehmen, und nannte das FHIR-Modell ausdrücklich als Vorlage. Abgeschlossen ist der Vorgang bis heute erkennbar nicht.

Nichts davon macht openEHR zu einem geschlossenen Standard. Es heißt aber, dass „herstellerneutrale Persistenz“ daraufhin zu prüfen ist, was sie garantiert.

3 Die Evidenz ist dünn – auf beiden Seiten

Die Wahl eines Standards garantiert noch keine Interoperabilität, denn Konformität und Interoperabilität sind getrennte Eigenschaften. Zwei Systeme können demselben Basisstandard folgen und dennoch nicht zusammenarbeiten, weil sich Profile, Versionen, Terminologiebindungen oder Prozessannahmen unterscheiden. Entscheidend ist deshalb nicht, welcher Standard allein Interoperabilität liefert, sondern welche Architektur, welches Profilierungsregime und welche Governance einen festgelegten Datenaustausch verlässlich ermöglichen. Für vergleichende Ergebnisse und Lebenszykluskosten ist die Evidenz auf beiden Seiten schwach.

Für openEHR gibt es nur wenige belastbare Studien, und auch der Nachweis der Wirksamkeit von FHIR auf nationaler Ebene ist unzureichend. Diese Symmetrie bleibt bestehen, allerdings mit einer Präzisierung.

Für die Breite der FHIR-Nutzung in der Forschung existieren inzwischen drei systematische Übersichtsarbeiten. Sie dokumentieren FHIR in Bereichen wie Onkologie, Genomik und Infektiologie, und zwar für Standardisierung, primäre Datenerfassung, Analyse und Kohortenrekrutierung ebenso wie für den Austausch. Als pauschale Aussage ist eine in der Debatte häufig vorgebrachte These damit nicht mehr haltbar: dass FHIR für forschungstaugliche klinische Modellierung strukturell zu flach sei.

Auch diese Evidenz hat ihre Grenzen. Die drei Arbeiten unterscheiden sich in der Methode, und nur eine von ihnen war vorab registriert, was sie zur methodisch stärksten macht. Keine dieser drei FHIR-bezogenen Arbeiten bezieht openEHR als Vergleichsgruppe ein, keine misst Wirksamkeit, und die Autorinnen und Autoren der stärksten Übersicht räumen selbst einen Publikationsbias ein.

Eine vierte, 2026 veröffentlichte Übersichtsarbeit betrachtet FHIR, OMOP-CDM und openEHR gemeinsam. Sie umfasst 99 Studien, davon nur acht zu openEHR, und 90 der 99 Arbeiten betreffen Sekundär- statt Primärnutzung. Verglichen werden veröffentlichte Anwendungen, nicht Lebenszykluskosten, klinische Ergebnisse oder installierte Produkte. Weil die Abdeckung der Quelldaten nur selten berichtet wird, erlaubt auch diese Arbeit keinen Vergleich darüber, wie viel Bedeutung bei Transformationen erhalten bleibt.

Eine Auszählung der wissenschaftlichen Literatur weist in dieselbe Richtung. Publikationen, die FHIR nennen, haben jene, die openEHR nennen, um 2016 überholt und erreichten bis 2024 etwa das Zehnfache der Jahreszahl, während die Ausbeute von openEHR auf einem Plateau blieb. Das misst Forschungsaufmerksamkeit und Bewegung, nicht Wirksamkeit, und es spiegelt zum Teil das regulatorische Mandat und keine klinische Überlegenheit. Zusammen mit den Übersichtsarbeiten ergibt es aber einen realen, für Entscheidungen erheblichen Vorsprung von FHIR in Verbreitung, Umsetzungsdichte und Ökosystemreife. Daraus folgt nicht, dass openEHR technisch unterlegen wäre. Die entscheidenden Unterschiede liegen heute weniger in den Fähigkeiten der Standards als in ihrem regulatorischen Umfeld, ihrer Verbreitung und den daraus entstehenden Architekturkosten.

Ein Wort zu Katalonien

Keine Diskussion über openEHR in Europa kommt weit ohne Katalonien, die oft zitierte Regionalplattform auf Basis dieses Standards. Die Beschaffungsgeschichte ist gut dokumentiert und zeigt, dass dieser Weg organisatorisch und rechtlich gangbar ist. Eine mittelgroße europäische Region kann sich strategisch für openEHR entscheiden, die Ausschreibungen führen und das Abgrenzungsprinzip in der Praxis anwenden. Dieses Ergebnis steht, und es sollte nicht beiseitegewischt werden.

Was Katalonien noch nicht zeigt, ist Wirksamkeit. Konkrete Ergebnisdaten dokumentiert keine unabhängig geprüfte oder begutachtete Quelle: aktive Einrichtungen, verarbeitete Datensätze, gemessene Interoperabilitätsgewinne. Die substanzreichste Darstellung ist ein Buchkapitel der Verantwortlichen selbst, und dessen Erstautor ist heute CEO von openEHR International. Das entwertet die berichteten Fakten nicht, verschiebt die Quelle aber von unabhängiger Evidenz in institutionelle Selbstdarstellung, und wer Katalonien als Beleg für Überlegenheit anführt, sollte das mitsagen. Katalonien zeigt, dass der openEHR-Weg begehbar ist. Ob er ankommt, kann die verfügbare Evidenz noch nicht beantworten.

4 Regulierung verändert die architektonische Rechnung

Die vergleichende Evidenz belegt nicht, dass einer der Standards bessere Ergebnisse erzielt. Die Regulierung verändert dennoch die architektonische Rechnung. Für den hier untersuchten Datenaustausch ist FHIR im europäischen Rahmen, in der grenzüberschreitenden Infrastruktur und in § 355 SGB V verankert. Eine openEHR-Persistenzschicht muss deshalb vor diesen FHIR-Austauschen eine zusätzliche Standardgrenze überwinden, während ein kompatibles FHIR-Persistenzmodell sie vermeiden kann. Diese Richtung schafft Skalierung, Marktdruck und Planungssicherheit. Sie ist kein Wirksamkeitsnachweis und schreibt das interne Speichermodell nicht vor.

Diesen Unterschied sollte man in beide Richtungen ernst nehmen. Ein Mandat ist kein Evidenzersatz, aber auch kein Nebenaspekt: Anschlussfähigkeit an EHDS und nationale Vorgaben, Planungssicherheit und eine breite, zunehmend vorgeschriebene Marktdurchdringung sind legitime Gründe, die für FHIR sprechen, unabhängig von der Wirksamkeitsfrage. Eine Beschaffungsentscheidung darf sich darauf stützen, solange sie regulatorische Sicherheit nicht als klinischen Beweis ausgibt.

5 Die eigentliche Bremse ist die Marktträgheit

Selbst der richtige, vorgeschriebene Standard bewirkt allein wenig, denn die eigentliche Arbeit beginnt erst nach der Standardwahl: bei der konsistenten Anwendung von Profilen, bei der Terminologiebindung und der Konformitätsprüfung. Ohne verbindliche Profiltiefe, also ohne genaue Festlegung von Feldern, Terminologien und Wertebereichen in den Profilen, wiederholt sich einfach das Muster der vergangenen vier Jahrzehnte HL7 v2: standardkonform und trotzdem nicht verlässlich interoperabel.

Wie konkret das wird, zeigt ein deutsches Beispiel: Die Kernprofil-Arbeitsgruppe des Interop Councils hielt 2025 fest, dass Patient.gender in den verbindlichen Krankenhaus-Schnittstellenprofilen Pflicht und in den E-Rezept-Profilen aus Datenschutzgründen verboten ist, obwohl beides konformes FHIR ist und beide nominell auf derselben nationalen Basisschicht aufsetzen. Eine Auszählung für die zugrunde liegende Analyse relativiert das Bild allerdings, und zwar zugunsten der deutschen Arbeit.

In 2.996 StructureDefinitions deklarieren die deutschen Profilfamilien 2.399 eigene Bindungen. Davon sind 79,4 % required und 1,9 % example. Wo gebunden wird, geschieht das überwiegend streng.

Die sicherheitsrelevante Teilmenge umfasst 94 Ressourcenprofile zu Medikation und Allergien. Unter den dort unmittelbar deklarierten Bindungen liegt der required-Anteil bei 53,7 %. Das belegt weder eine insgesamt schwächere Einschränkung noch klinische Folgen: 38 der 50 Profile ohne eigene Bindung legen stattdessen Werte fest, 46 verwenden Slicing, und geerbte Bindungen wurden nicht aufgelöst. Eine Aussage zur Sicherheit verlangte eine elementweise klinische Prüfung.

Der deutsche Konflikt ist kein deutsches Einzelphänomen. Eine veröffentlichte Methode, angewandt auf US Core und den International Patient Summary, ergab für die untersuchten Beispiele zu Patient, Condition und Medikation keine uneingeschränkte Kompatibilität, obwohl Sender und Empfänger jeweils ihrem eigenen Implementierungsleitfaden entsprechen können. Dass Constraints einander widersprechen können, gehört zur Profilierung. Sie zu entdecken ist eine Frage der Kompatibilität, und weil FHIR die Einschränkungen formal ablegt, lässt sie sich rechnen statt lesen. Zu entscheiden, ob ein Konflikt verhindert, hingenommen, abgebildet oder aufgelöst wird, ist eine Frage der Governance.

Dasselbe Prinzip gilt auf der openEHR-Seite. Eine begutachtete Erhebung erhielt Antworten zu elf produktionsfähigen Repositorien und fand unterschiedliche Kombinationen bei AQL, REST-API-Unterstützung, Serialisierungsformaten, Referenzmodellversionen und EHR Extract. Die Autoren kommen zu dem Schluss, dass diese Unterschiede eine unmittelbare Interoperabilität zwischen den Repositorien behindern, und fordern ein Konformitätstest-Framework. Die Erhebung dokumentiert Herstellerangaben und keine unabhängig ausgeführten Tests. Sie zeigt dennoch, dass die Implementierung einer offenen Spezifikation allein keine Portabilität zwischen Produkten gewährleistet.

Das tiefere Hindernis ist strukturell. Etablierte KIS-Hersteller haben keinen Anreiz, ihre proprietären Datenmodelle aufzugeben, solange Kunden Datenportabilität nicht vertraglich durchsetzen. Ein Hebel wäre eine profilierte FHIR-Offenlegungspflicht für alle Hersteller, wie sie EHDS und § 355 SGB V bereits anstoßen, allerdings nur, wenn Profiltiefe, Terminologiebindung und Konformitätstests sie stützen. Diese Trägheit ist nicht neutral, sie trifft openEHR sogar härter: Die Einführung von openEHR als internem Speicherkern erfordert tiefere Eingriffe in bestehende Systeme, setzt eine seltene Doppelqualifikation voraus und trifft auf einen kleineren Anbietermarkt.

Die Modelle nähern sich an, die Werkzeuge sollten folgen

Eine leisere Entwicklung verändert den Ton der Debatte. openEHR International und HL7 arbeiten inzwischen zusammen, am sichtbarsten bei ihren gemeinsamen Treffen in Amsterdam 2025 und Dublin 2026. Ein konkretes, überprüfbares Ergebnis liegt bereits vor. In einem aktuellen HL7-FHIR-Implementierungsleitfaden steht ein openEHR-Archetyp neben einem FHIR Logical Model, als informative, zusätzliche Quelle klinischer Orientierung, während das Logical Model den maßgeblichen Status behält. Eine wiederkehrende Befürchtung in der FHIR-Gemeinschaft, Archetypen würden zum offiziellen Weg für Domänenmodelle erklärt und verdrängten damit die eigenen Logical Models, bestätigt dieses Artefakt nicht. Die Annäherung liegt auf der Ebene der Modellveröffentlichung, und nichts in diesem Artefakt deutet auf Verdrängung.

Aus der FHIR-nahen Gemeinschaft kommt eine Folgerung, die in dieselbe Richtung weist. Sie ist eine informelle Position und kein dokumentierter Befund, und so ist sie auch zu lesen.

Ihr zufolge sind FHIR Logical Models für die Domänenanalyse funktional ausreichend, und die Lücke gegenüber openEHR-Archetypen liegt in den Werkzeugen und nicht in der Modellierungstiefe. Die Folgerung nennt zwei Beispiele: keine verbreitete grafische Darstellung von Logical Models und kein diagrammbasiertes Autorenwerkzeug. An den veröffentlichten Artefakten geprüft, übertreiben beide.

Der EHDS-Leitfaden zu den Logical Information Models stellt jedes Modell über die übliche FHIR-Publikationskette als strukturierte Tabelle mit Kardinalitäten, Datentypen und Bindungen dar, eine verbreitete Darstellung gibt es also. Und ART-DECOR liefert klinisch erstellte Datensätze und Use-Case-Transaktionen über seine FHIR-Endpunkte bereits als FHIR Logical Models aus, was genau die Umwandlung ist, nach der die Folgerung verlangt, nur aus einer anderen Ausgangsnotation. Offen bleibt Engeres: das Erstellen durch Zeichnen und ein Rückweg für Modelle, die außerhalb des Werkzeugs entstanden sind. Ein Teil der größeren sichtbaren Anziehungskraft von Archetypen beruht weiterhin auf Darstellung und Werkzeugen und nicht auf Substanz, und die Abhilfe liegt in der Hand des FHIR-Umfelds selbst.

Der nächste Schritt

Die Frage „openEHR oder FHIR?“ greift demnach zu kurz. Weiter führen andere Fragen: Welche Architektur passt zu welchem Zweck, zur Versorgung oder zur forschungsgetriebenen Sekundärnutzung? Kann oder soll man sich eine separate Erfassung für die Sekundärnutzung überhaupt noch erlauben? Und wie kommt man an das, worauf es wirklich ankommt, nämlich an Portabilität, Profiltiefe und geprüfte Konformität? Der Standard ist die notwendige, aber nie die ausreichende Bedingung.

Genau an diesen Stellen ist die Bewegung bereits im Gang. Mit § 355 SGB V, der Telematikinfrastruktur und der Profil- sowie Konformitätsarbeit der gematik hat Deutschland schon viele der wichtigen Bausteine gelegt, und der Gesetzgeber baut sie weiter aus. Die Aufgabe besteht also nicht darin, bei null anzufangen, sondern das Erreichte zu vertiefen: verbindliche Profile, saubere Terminologiebindung und belastbare Prüfregimes.

Diese drei sind keine getrennte Wunschliste. Sie sind der Durchsetzungsmechanismus für das Selbstbeschreibungsproblem von oben. Eine required-Bindung in einem veröffentlichten, versionierten Profil, aufgelöst gegen einen Terminologieserver und bei jedem Release von einem Validator geprüft, macht aus dem Satz „der Verweis zeigt nach außen“ eine Eigenschaft des laufenden Systems statt eine des Standards. Das ist anspruchsvolle Arbeit, und es ist die Arbeit, die aus einem gemeinsamen Standard echte Interoperabilität macht. Wer sie konsequent weiterführt, muss sich um die Wahl eines Akronyms keine Sorgen mehr machen.