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 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“. 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.

Fünf 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 bereits festgelegt: Die EHDS-Verordnung und MyHealth@EU beziehen sich regulatorisch wie praktisch auf FHIR, und in Deutschland verweist § 355 SGB V ebenfalls darauf. Ein vergleichbarer Anker für openEHR fehlt auf europäischer Ebene. Das sagt zwar nichts über die technische Eignung des Standards aus, wohl aber über die politische Realität.

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, entstehen fünf Anordnungen und nicht drei.

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 regierten 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 Datensatz überschreitet gar keine. 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 kosten dasselbe. Ein proprietäres System mit vorgelagerter FHIR-Schnittstelle und ein openEHR-System mit vorgelagerter FHIR-Schnittstelle sind an der Grenze nicht zu unterscheiden. Gleiche Form, gleiche Konversion, gleicher Pflegeaufwand. Der Fall für openEHR ist deshalb auf der Austauschseite überhaupt nicht zu machen. Er ist dort zu machen, wo er wirklich liegt, bei der Modellierungstiefe, bei der Archetyp-Governance, bei der Stabilität der Modelle über Jahrzehnte. Der zweite Punkt läuft in die Gegenrichtung. Weil der Austausch FHIR ist, muss ein in openEHR gehaltener Datensatz immer mindestens einmal konvertiert werden, so gut alles andere auch gemacht sein mag, während ein in FHIR gehaltener gar nicht konvertiert werden muss. Nur eine Seite hat Luft unter einer einzigen Konversion. Diese Asymmetrie folgt aus der Regulierung und nicht aus technischer Güte, und änderte sich die Austauschanforderung, tauschten die Böden.

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 mindestens ein Anbieter von Pflegedokumentation ist ein Kandidat, dessen veröffentlichtes Material die Frage in keine Richtung klärt. 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 Prozent 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 überholt

Jahrelang galt die bequeme Formel „openEHR speichert, FHIR tauscht aus“. Sie ist konzeptionell klar, hat aber an Relevanz verloren, seit native FHIR-Repositorien genau die Lücke geschlossen haben, aus der diese Arbeitsteilung ursprünglich entstand. 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 Bedeutungsverluste 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 regierten Modellübergänge 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 – 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. Und es gibt eine dritte Einschränkung, die in Richtung FHIR zielt und die schärfere ist. 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 zwei verschiedene Dinge. Zwei Systeme können demselben Standard folgen und dennoch nicht zusammenarbeiten. Entscheidend ist deshalb nicht, welcher Standard zertifiziert ist, sondern welcher im großen Maßstab tatsächlich Interoperabilität liefert. Und in Bezug auf diese Frage ist die Beweislage 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 bezieht openEHR als Vergleichsgruppe ein, keine misst Wirksamkeit, und die Autorinnen und Autoren der stärksten Übersicht räumen selbst einen Publikationsbias ein. Vergleichbare systematische Übersichtsarbeiten für openEHR fehlen ganz.

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 Entscheidend ist die Regulatorik – nicht die Evidenz

Wenn die Evidenz die beiden Standards nicht trennt, was dann? Die Antwort ist unangenehm für alle, die auf einen besseren Beleg warten: das regulatorische Mandat. FHIR ist im EHDS, in der grenzüberschreitenden Infrastruktur und in § 355 SGB V verankert, während openEHR-Infrastrukturen zusätzliche Transformationsschichten benötigen, die weder zertifiziert noch europaweit standardisiert sind. Dieses Mandat schafft Skalierung, Marktdruck und Planungssicherheit, ist aber kein Beweis für die Wirksamkeit. Architekturentscheidungen werden heute also nicht nur technisch getroffen, sie werden regulatorisch vorentschieden.

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: Von 2.159 Terminologiebindungen, welche die deutschen Profilfamilien selbst setzen, tragen 78,5 Prozent die Stärke required und knapp 2 Prozent example. Wo hier gebunden wird, wird streng gebunden. Schwächer steht ausgerechnet die Gruppe da, die es am nötigsten hätte, denn bei den Profilen für Medikations- und Allergiedaten liegt der required-Anteil bei 53,6 Prozent. Ein Teil dieser Gruppe legt die Codes allerdings unmittelbar fest, statt sie zu binden: Zweiundzwanzig der siebenunddreißig Profile, die gar keine Bindung deklarieren, legen stattdessen Werte fest, und nur vier tragen weder Bindung noch Festlegung noch Slice. Wo eine solche Festlegung auf einem codierten Element sitzt, ist sie strenger als eine Bindung, weil sie einen Code zulässt statt einer Menge, und wie viele es sind, zeigt diese Zählung nicht. Was die Zählung nicht zeigt, ist, ob die schwächere Verteilung in einem einzelnen Profil klinisch folgenreich ist. Das verlangte eine elementweise Prüfung der Bindungen und der aus den Basisprofilen ererbten Einschränkungen, und die ist nicht erfolgt.

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.