openEHR und HL7 FHIR: von der Grundsatzfrage zur Umsetzung

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

Auch im Referentenentwurf des Gesetzes für Daten und digitale Innovation im Gesundheitswesen (GeDIG) kam die Datenspeicherung zur Sprache: In § 386 SGB V war ein Absatz vorgesehen gewesen, der von Leistungserbringern verlangte, Gesundheitsdaten im interoperablen Format vorzuhalten und auszutauschen. Im Kabinettsentwurf, den das Bundeskabinett am 15. Juli 2026 beschlossen hat, tauchte das dann im verfügenden Teil nicht mehr auf, wohl aber in der Zusammenfassung des Entwurfs, in der weiterhin von einem Vorhalten im interoperablen Format gesprochen wird. 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. Das genaue Format bleibt demnach einer Rechtsverordnung vorbehalten. Für die Architekturfrage heißt das: Die Interoperabilitätspflicht 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, das gilt für FHIR wie für openEHR gleichermaßen. All diese Beispiele zeigen: Die Architekturfrage ist hoch aktuell, und sie braucht dringender denn je eine Antwort.

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.

Der Konsens ist größer, als es scheint – und der Dissens kleiner
Die untersuchten Strategien zeigen einen weitgehenden Konsens: Für den externen Datenaustausch führt an FHIR kaum ein Weg vorbei. Offen bleibt, ob FHIR auch das maßgebliche Speichermodell bildet oder ob openEHR die notwendige, die empfohlene oder die optionale Schicht für die interne Speicherung ist oder ob sie gänzlich verzichtbar ist. Eine Architektur, die openEHR ohne standardisierte FHIR-Austauschschicht für Speicherung und externen Austausch vorsieht, spielt in den untersuchten Strategien kaum noch eine Rolle.

Wer neu baut, entscheidet allerdings nicht nur zwischen zwei Standards. Entscheidend ist, wo klinische Daten erfasst werden, in welchem Modell sie dauerhaft gehalten werden und wie viele Modellgrenzen sie bis zur Nutzung überschreiten. Daraus lassen sich fünf Erkenntnisse für Planung und Beschaffung ableiten.

Erstens: 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 (CDR) die Lücke geschlossen haben, aus der diese Arbeitsteilung ursprünglich entstand. Über die Gestalt eines Systems entscheiden zwei Tatsachen, und keine davon ist die Wahl eines Standards: wo der klinische Datensatz geschrieben wird und in welchem Modell er gehalten wird. Daraus ergeben sich fünf Anordnungen. Im herstellereigenen Modell erfasst und gehalten, FHIR auf Anfrage erzeugt, ergibt eine Übersetzung, die nichts hinterlässt. Im Herstellersystem erfasst und zusätzlich in einem FHIR-Speicher gehalten, ergibt ebenfalls eine, diesmal dauerhaft. Nativ in FHIR erfasst, ergibt keine. Im Herstellersystem erfasst, in einem openEHR-Speicher gehalten und daraus nach FHIR umgesetzt, ergibt zwei. Nativ in openEHR erfasst, ergibt eine. Gezählt werden dabei keine Softwareschichten, sondern getrennt regierte klinische Modelle, in denen derselbe Inhalt zugleich wahr sein muss.

Zwei Befunde sind entscheidend. An der FHIR-Austauschgrenze benötigen ein proprietäres und ein nativ in openEHR arbeitendes Primärsystem jeweils eine Übersetzung. Der mögliche Vorteil von openEHR muss daher in Modellierungstiefe und Governance liegen, nicht in einem geringeren Aufwand für den Austausch.
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. open-EHR bildet sie möglichst vollständig und dauerhaft ab. Auch die Machbarkeit des FHIR-nativen Ansatzes ist belegt: Wales betreibt einen nationalen, dauerhaften FHIR-Speicher, und die 41 Datenintegrationszentren der Medizininformatik-Initiative (MII) strukturieren ihre Versorgungsdaten nach dem FHIR-basierten MII-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.

Die Aussage hat eine klare Grenze: In den untersuchten Fällen entstehen die Daten weiterhin in Primärsystemen und werden nach FHIR transformiert. Es entfällt also die zusätzliche Übersetzung zwischen Speicher- und Austauschmodell, nicht aber jene zwischen Quell- und Zielmodell. Belegt sind große FHIR-native Repositorien, nicht die unmittelbare klinische Dokumentation in FHIR. Ein vom Bundesministerium für Gesundheit gefördertes Vorhaben verfolgt dieses Ziel, ein Ergebnisbericht liegt bislang nicht vor. Unabhängige Studien zur Wirksamkeit fehlen ebenfalls.

Zweitens: Die Abbildungsschichten sind der Preis, der zu selten genannt wird
Damit rückt ein oft übergangenes Argument in den Mittelpunkt: Wer Persistenz und Austausch trennt und etwa einen openEHR-Speicher unter eine FHIR-Brücke legt, zahlt eine dauerhafte Abbildungslast. Sie umfasst die doppelte Modellierung jedes klinischen Inhalts sowie 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.
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.

Schnittstellen-, Migrations- und Terminologiefehler können klinisch relevante Informationen verändern oder unvollständig übertragen. Bei Medikations- und Allergiedaten sind deshalb besonders belastbare Validierungsverfahren erforderlich. Entscheidend ist deshalb die Anzahl der Transformationsschichten 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. Der GeDIG-Entwurf greift genau das auf: § 386c verbietet Herstellern ein Format, das die vollständige semantische Rekonstruktion in einem anderen System verhindert. 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, und jede Abbildung 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 allergierelevante Inhalte müssen hier besonders strenge Maßstäbe gelten. open­EHR 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.

Drittens: Die Evidenz ist dünn – auf beiden Seiten
Die Wahl eines Standards garantiert noch keine Interoperabilität. Zwei Systeme können demselben Standard entsprechen und dennoch nicht zuverlässig zusammenarbeiten. Entscheidend wären deshalb unabhängige Nachweise, dass eine Architektur im großen Maßstab bessere klinische, organisatorische oder wirtschaftliche Ergebnisse erzielt. Solche Nachweise fehlen für openEHR ebenso wie für FHIR.

Für FHIR ist allerdings eine breitere Nutzung dokumentiert. Systematische Übersichtsarbeiten beschreiben Anwendungen unter anderem in Onkologie, Genomik, Infektiologie, klinischer Forschung und Leitlinienumsetzung. Sie zeigen, dass FHIR nicht nur für den Austausch, sondern auch für Datenerfassung, Standardisierung, Analyse und Kohortenbildung eingesetzt wird. Vergleichbare Übersichtsarbeiten liegen für openEHR bislang kaum vor.

Das belegt weder eine höhere Wirksamkeit noch eine technische Überlegenheit. Es spricht aber für eine größere dokumentierte Verbreitung, ein breiteres verfügbares Ökosystem und eine größere Community. Auch nationale openEHR-Projekte zeigen zunächst Machbarkeit, nicht Überlegenheit. Unabhängige Vergleiche der Ergebnisse fehlen auf beiden Seiten.

Viertens: Entscheidend ist die Regulatorik – nicht die Evidenz
Die unzureichende Evidenz macht regulatorische Vorgaben nicht unwichtig. Der EHDS verlangt gemeinsame Austauschformate und interoperable EHR-Komponenten. In Deutschland geben insbesondere die Regelungen zur elektronischen Patientenakte und die Arbeit der gematik FHIR eine starke Stellung. openEHR besitzt keinen vergleichbaren europäischen oder nationalen Anker.

Das schafft für FHIR-Anschlussfähigkeit, Marktdruck und Planungssicherheit. Es ist jedoch kein klinischer Wirksamkeitsnachweis. Beschaffungsentscheidungen dürfen regulatorische Sicherheit berücksichtigen, sollten sie aber nicht als Beleg für technische oder klinische Überlegenheit darstellen.

Für openEHR folgt daraus keine generelle Absage. Eine zusätzliche openEHR-Schicht muss jedoch einen konkreten fachlichen Vorteil bieten, der den dauerhaften Aufwand für Modellabgleich, Transformation, Validierung und Pflege rechtfertigt.

Fünftens: 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.

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 Pflicht zur Herausgabe der Daten in verbindlich profilierten FHIR-Formaten für alle Hersteller, allerdings nur, wenn Profiltiefe, Terminologiebindung und Konformitätstests sie stützen. Diese Trägheit ist nicht neutral, sie trifft open-EHR 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.

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.

Die ermutigende Nachricht: 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. Das ist anspruchsvoll, aber machbar, und genau diese Arbeit macht aus einem gemeinsamen Standard echte Interoperabilität. Wer diese Arbeit konsequent weiterführt, entscheidet nicht mehr zwischen Akronymen, sondern anhand nachgewiesener Architektur- und Governanceanforderungen. 

-----------------------------------------------------------------------------------------------------------------------------------------

Was bei Beschaffungsentscheidungen zählt
Diese Fragen gelten unabhängig vom gewählten Standard. Sie richten den Blick auf das, was über Interoperabilität in der Praxis entscheidet.

•    Anzahl der Transformationsschichten. Wie viele Übersetzungsschritte liegen zwischen der Erfassung eines klinischen Werts und seiner Nutzung? Jede zusätzliche Schicht ist eine dauerhafte Kostenstelle und eine mögliche Fehlerquelle. Wo Daten repliziert und nicht am Ort der Erfassung geschrieben werden, steht mindestens eine Transformation ohnehin fest, was den Vergleich relativiert. Das gilt für alle fünf Anordnungen, vom proprietären Krankenhausinformationssystem mit vorgelagerter FHIR-Schnittstelle über den openEHR-Speicher mit FHIR-Brücke bis zum nativen FHIR-Speicher.

•    Klinische Validierung jeder Abbildung. Jede Übersetzung klinischer Daten braucht eine klinische Validierung durch entsprechend ausgebildetes Fachpersonal, nicht bloß einen technischen Prüflauf auf Hin- und Rückweg. Neben den Kosten müssen Fragen der Verlässlichkeit, der Verantwortlichkeit und der Haftung beantwortet sein.

•    Prüf- und Konformitätswerkzeuge. Welche Test- und Validierungswerkzeuge unterstützt die Lösung, und wie ausgereift und breit akzeptiert ist dieses Ökosystem? Konformität auf dem Papier ersetzt keine geprüfte Interoperabilität in der Praxis.

•    Terminologiebindung. Wie werden Fachbegriffe und Codes gebunden, und über welche Schnittstelle? Eine standardisierte Terminologie-Schnittstelle senkt Aufwand und Fehlerrisiko, eine implementierungsspezifische Anbindung erhöht beides.

•    Profiltiefe. Wie wird sichergestellt, dass Felder, Terminologien und Wertebereiche in den Profilen genau festgelegt sind? Ohne diese Festlegung bleibt ein Standard formal erfüllt, ohne verlässlich interoperabel zu sein.

•    Vertragliche Datenportabilität. Ist die Herausgabe der Daten in einem profilierten, standardkonformen Format vertraglich zugesichert? Ohne diesen Hebel bleibt Portabilität eine Absichtserklärung, und nicht standardisierte, herstellerabhängige Abbildungsschichten erschweren einen späteren Anbieterwechsel.

-------------------------------------------------------------------------------------------------------------------------------------------

AUTOR

Dr. Kai U. Heitmann
CEO von HL7 Deutschland; Senior-Experte und Community Event Manager bei HL7 Europe
Kontakt: info(at)kheitmann.de