Beste Dateninteroperabilitätsstandards vs. FHIR: Top-Picks im Vergleich (2026)

Dateninteroperabilitätsstandards vs. FHIR ist ein Vergleich, den Architekten sorgfältig angehen sollten, da es sich bei FHIR eher um eine gesundheitsspezifische Spezifikation als um ein allgemeines Unternehmensdatenmodell handelt. FHIR definiert mehr als 150 „Ressourcen“ (Patient, Observation, Encounter, MedicationRequest usw.) für den klinischen Austausch, modelliert jedoch keine Einheiten aus den Bereichen Fertigung, Finanzen, Einzelhandel oder Lieferkette; es als universelle Interoperabilitätsschicht zu behandeln, ist daher ein häufiger Architekturfehler.

Wichtige Erkenntnisse

• FHIR ist ein Interoperabilitätsstandard für das Gesundheitswesen, kein Unternehmensdatenmodell. Es zeichnet sich durch den Austausch klinischer Daten über RESTful-APIs und Ressourcen aus, modelliert jedoch keine Einheiten aus den Bereichen Fertigung, Finanzen, Einzelhandel oder Lieferkette.
• „Standards vs. FHIR“ ist normalerweise die falsche Fragestellung. Die meisten Unternehmen benötigen einen geschichteten Ansatz: ein domänenagnostisches kanonisches Modell darunter sowie Domänenstandards (FHIR, ISO 20022, X12) an den Schnittstellen.
• Die Stärken von FHIR sind real: granulare Ressourcen, REST + JSON/XML, eine veröffentlichte Konformitätsschicht (CapabilityStatement, Profile, Implementation Guides) und ein großes Anbieter-Ökosystem.
• Die Grenzen von FHIR sind ebenfalls real: Versionswechsel (DSTU2 → STU3 → R4 → R5), Profilproliferation, schwache native Unterstützung für Analytics/OLAP und keine Abdeckung nicht-klinischer Domänen.
• Das Cloud Information Model (CIM) verfolgt einen anderen Ansatz: ein offenes, anwendungsagnostisches, JSON-LD-basiertes Modell, das zwischen Systemen angesiedelt sein soll, anstatt Domänenstandards zu ersetzen.
• Wählen Sie nach Workload, nicht nach Mode. Transaktionsaustausch, Analytics und Stammdatenverwaltung bevorzugen jeweils unterschiedliche Standards.

Warum „Standards vs. FHIR“ die falsche Frage ist

FHIR (Fast Healthcare Interoperability Resources) wird von HL7 International verwaltet und ist für den Informationsaustausch im Gesundheitswesen konzipiert. Es definiert mehr als 150 „Ressourcen“ (Patient, Observation, Encounter, MedicationRequest usw.), jeweils mit einem RESTful-Interaktionsmuster und einer JSON/XML-Darstellung.

Das ist ein Domänen-Standard. Er beantwortet die Frage: „Wie übertrage ich ein Laborergebnis zwischen einer Krankenhaus-EHR und einem Kostenträger?“ Er beantwortet nicht: „Was ist ein Kunde, eine Bestellung oder ein Produkt über mein CRM, ERP und Data Warehouse hinweg?“

Wenn Architekten die Entscheidung als „FHIR oder etwas anderes“ formulieren, vermischen sie normalerweise drei verschiedene Ebenen:

1. Transport/Syntax – wie Bytes übertragen werden (REST, SOAP, Message Queues, File Drops).
2. Domänensemantik – was die Daten in einer bestimmten Branche bedeuten (FHIR, ISO 20022, X12, GS1).
3. Kanonisches/Unternehmensmodell – das gemeinsame Vokabular, das es Domänen ermöglicht, miteinander zu kommunizieren (CIM, benutzerdefinierte kanonische Modelle, Branchenontologien).

FHIR ist in Ebene 2 angesiedelt. Die meisten Interoperabilitätsausfälle in Unternehmen treten in Ebene 3 auf, die FHIR nie lösen sollte.

Die Vergleichstabelle: Wichtige Interoperabilitätsstandards

Standard	Primäre Domäne	Datenmodellstil	Transport	Bestens geeignet für	Hauptbeschränkung
FHIR (R4/R5)	Klinische & administrative Gesundheitsdaten	Ressourcenorientiert, RESTful	REST/HTTP, JSON, XML	Echtzeit-klinische APIs, Patientenzugriff, SMART on FHIR Apps	Keine nicht-klinische Abdeckung; Versionswechsel; Profil-Wildwuchs
HL7 v2	Messaging im Gesundheitswesen	Segment/Feld (Pipe-getrennt)	MLLP, Dateien	Legacy-Labor-/ADT-Feeds, immer noch dominant in Krankenhäusern	Vorkoordiniert, spröde, schlechte Semantik
HL7 CDA	Klinische Dokumente	XML-Dokument	Dateien, XDS	Dokumentenzentrierter Austausch (Entlassungsberichte)	Ausführlich, schwer abfragbar
openEHR	Klinische EHR	Archetyp/Vorlage (Zwei-Ebenen-Modellierung)	REST, herstellerspezifisch	Klinisch reichhaltige, langlebige Aufzeichnungen	Steile Lernkurve; kleinere Anbieterbasis
OMOP CDM	Gesundheitsanalytik	Relational, beobachtend	Datenbank	Bevölkerungsgesundheit, Forschung, OHDSI-Netzwerk	Nicht für Transaktionsaustausch
X12 (EDI)	US-Gesundheitsverwaltung, Lieferkette	Transaktionssätze (837, 835, 850)	Batch-Dateien, AS2	Ansprüche, Berechtigungen, Bestellungen	Starr, Batch-orientiert, US-zentriert
ISO 20022	Finanzdienstleistungen	Nachrichtendefinitionen (XML)	MX/MT-Messaging	Zahlungen, Wertpapiere, Handel	Komplex; globale Migration im Gange
GS1 / EPCIS	Einzelhandel, Lieferkette	Identifier + Ereignisstandards	Verschiedene	Produktrückverfolgbarkeit, Barcodes	Enger Umfang (Identität + Ereignisse)
schema.org	Web / SEO	Vokabular (JSON-LD)	HTTP	Öffentliches Web-Markup, Discovery	Kein Unternehmensvertrag
Cloud Information Model (CIM)	Branchenübergreifendes Unternehmen	JSON-LD-Ontologie	Modellartefakte	Kanonische Ebene über Cloud-/On-Prem-Apps hinweg	Jüngeres Ökosystem; Adoption wächst noch

Das Muster ist klar: FHIR ist eine starke Option in einem überfüllten Feld, ist aber domänengebunden. Wenn Ihr Problem klinische Daten sind, ist FHIR oft die richtige Antwort. Wenn Ihr Problem unternehmensweit ist, ist FHIR bestenfalls eine Quelle und im schlimmsten Fall eine Ablenkung.

Verwandte: Fivetran — Die vollständig verwaltete ELT-Pipeline, die einfach weiterläuft.

Wo FHIR wirklich gewinnt

Es ist wichtig, die Vorteile von FHIR präzise zu benennen, denn es pauschal abzulehnen ist ebenso nachlässig wie es übermäßig zu adoptieren.

• Vertrautheit mit REST + JSON. Integrationsingenieure, die HTTP und JSON beherrschen, können schnell produktiv werden, im Gegensatz zu den Pipe-getrennten Segmenten von HL7 v2 oder dem tiefen XML von CDA.
• Granulare Ressourcen. Man kann eine einzelne Observation anfordern, anstatt ein gesamtes Dokument zu parsen, was ideal für Microservices und mobile Apps ist.
• Konformitätsmechanismen. CapabilityStatement, StructureDefinition und veröffentlichte Implementation Guides (z. B. US Core, IPS) bieten maschinenlesbare Verträge – eine Seltenheit bei älteren Standards.
• Regulatorischer Rückenwind. In den USA treiben der ONC Cures Act Final Rule und die CMS Interoperability Rules FHIR-basierte APIs voran (insbesondere die Patient Access API). Diese regulatorische Dynamik ist ein echter Grund für die Einführung von FHIR im Gesundheitswesen.
• Ökosystem. SMART on FHIR App Launching, Unterstützung durch große EHR-Anbieter und Open-Source-Server (HAPI FHIR, Microsoft FHIR Server) reduzieren die Entwicklungskosten.

Wenn Sie eine patientenorientierte App, einen Austausch zwischen Kostenträger und Anbieter oder ein Tool zur klinischen Entscheidungsunterstützung entwickeln, ist FHIR normalerweise der korrekte Standard.

Wo FHIR für Unternehmensarchitekten scheitert

Die Probleme treten auf, sobald FHIR seine Heimatdomäne verlässt.

Wenn Sie einkaufen: Boomi AtomSphere — Enterprise iPaaS für die Hybrid-Cloud-to-On-Premise-Integration.

1. Keine Abdeckung nicht-klinischer Entitäten. Es gibt keine FHIR-Ressource für „Rechnungsposten“, „Lagerplatz“ oder „Abonnementstufe“. Teams, die versuchen, klinische Ressourcen gewaltsam auf kommerzielle Konzepte zu biegen, produzieren Modelle, die gleichzeitig nicht standardisiert und nicht nützlich sind.

2. Versionswechsel sind ein realer Kostenfaktor. DSTU2, STU3, R4 und R5 unterscheiden sich in den Ressourcenformen und Terminologiebindungen. In Multi-Vendor-Umgebungen laufen häufig zwei oder drei Versionen gleichzeitig, was Übersetzungsschichten erfordert. Planen Sie hierfür Budget ein.

3. Profilproliferation. Da FHIR erweiterbar ist, fügt jeder Implementation Guide, jede Region und jeder Anbieter Profile hinzu. Zwei Systeme können beide „FHIR R4-Konformität“ beanspruchen und dennoch nicht interoperabel sein, wenn kein gemeinsames Profil vorliegt. Dies ist das FHIR-Äquivalent zum Problem „Jeder spricht seinen eigenen Dialekt“.

4. Analytics ist ein nachträglicher Gedanke. FHIR ist für den Transaktionsaustausch optimiert, nicht für spaltenorientierte Analysen. Für Bevölkerungsgesundheit und Forschung ist OMOP CDM oder ein flaches Warehouse-Modell normalerweise das bessere Ziel. Die FHIR-zu-OMOP-Übersetzung ist eine bekannte, nicht triviale Aufgabe.

5. Es ist kein Stammdatenmodell. FHIR sagt Ihnen nicht, wie Sie eine einzelne „goldene“ Patienten- oder Anbieteridentität über Systeme hinweg auflösen. Das ist MDM (Master Data Management), und es steht über jedem Austauschstandard.

Die kanonische Ebene: Wo CIM und ähnliche Modelle ansetzen

Dies ist die Ebene, die die meisten „FHIR vs. X“-Vergleiche überspringen, und genau hier ist das Cloud Information Model (CIM) positioniert.

Verwandte: Matillion — Push-Down-ELT für Cloud-Data-Warehouses.

CIM ist ein Open-Source, anwendungsagnostisches Datenmodell, ausgedrückt in JSON-LD, das ein gemeinsames Vokabular über Cloud- und On-Premises-Systeme hinweg bereitstellen soll. Seine Designabsicht unterscheidet sich von der von FHIR:

• Domänenagnostisch. Es modelliert allgemeine Unternehmenskonzepte (Parteien, Konten, Produkte, Bestellungen, Interaktionen) anstatt klinischer Ressourcen.
• Ontologiebasiert. JSON-LD und Linked-Data-Prinzipien ermöglichen Erweiterungen und Mappings anstatt Forks.
• Anbieterneutral. Es gehört keinem einzelnen EHR- oder Cloud-Anbieter, was entscheidend ist, wenn Sie Salesforce, SAP, Workday und einen Data Lake integrieren.

Die praktische Architektur sieht so aus:

[EHR] --FHIR--> [Integration layer] --map--> [Canonical model (CIM)] --map--> [CRM/ERP/warehouse]
[Bank] --ISO 20022--> [Integration layer] --map--> [Canonical model (CIM)] --map--> [...]

FHIR übernimmt die klinische Schnittstelle. ISO 20022 übernimmt die Zahlungsschnittstelle. Das kanonische Modell übernimmt die Bedeutung in der Mitte. Dies ist das Muster, das über Branchen hinweg skaliert; der Versuch, FHIR alle drei Aufgaben übertragen, tut dies nicht.

Leserfavorit: Airbyte — Open-Source-ELT mit einer Managed-Cloud-Option.

Entscheidungshilfe: Eine Kriterien-Checkliste

Bewerten Sie jeden Kandidatenstandard anhand dieser Kriterien für Ihr spezifisches Programm:

1. Domänenpassung – Modelliert der Standard Ihre Entitäten nativ, oder müssen Sie ihn ständig erweitern?
2. Regulatorische Anforderungen – Ist die Einführung vorgeschrieben (z. B. FHIR unter US-Interoperabilitätsregeln, ISO 20022 für Zahlungen)?
3. Ökosystem-Reife – Gibt es produktionsreife Open-Source-Implementierungen und Anbieter?
4. Versionsstabilität – Wie oft ändert sich die Spezifikation und wie hoch sind die Migrationskosten?
5. Analytics-Unterstützung – Können Sie es direkt abfragen oder benötigen Sie eine Transformationspipeline?
6. Erweiterbarkeitsmodell – Profile, Archetypen oder Ontologie-Erweiterungen – was passt zu Ihrer Governance?
7. Governance und Lizenzierung – Wer kontrolliert die Spezifikation und können Sie sie beeinflussen?
8. Gesamtkosten (TCO) – Beziehen Sie die Wartung der Mappings mit ein, nicht nur die Erstintegration.

Eine nützliche Faustregel: Wenn mehr als eine Branche beteiligt ist, benötigen Sie eine kanonische Ebene; wenn nur eine beteiligt ist, adoptieren Sie direkt den Standard dieser Branche.

Gängige Architekturmuster (und Anti-Pattern)

Muster: Hub-and-Spoke mit einem kanonischen Modell. Jedes Quellsystem wird einmal auf das kanonische Modell gemappt. Ein neues System bedeutet nur ein neues Mapping, nicht N. Dies ist die klassische Rechtfertigung für CIM-ähnliche Modelle.

Muster: FHIR-Fassade über Legacy. FHIR-APIs vor HL7 v2- oder CDA-Systemen schalten. Weit verbreitet und pragmatisch; die Fassade absorbiert Versionsunterschiede.

Anti-Pattern: FHIR als Unternehmensbus. Verwendung von FHIR-Ressourcen als interner Vertrag für nicht-klinische Systeme. Führt zu semantischem Missbrauch und nicht wartbaren Erweiterungen.

Anti-Pattern: Ein Standard, um sie alle zu beherrschen. Die Annahme, dass ein einzelner Standard – FHIR, CIM oder sonst welcher – die Mapping-Arbeit eliminiert. Er reduziert sie, aber er entfernt sie nie.

Anti-Pattern: Terminologie ignorieren. Die Stärke von FHIR hängt von codierten Werten ab (LOINC, SNOMED CT, ICD-10). Ohne Terminologie-Governance erzeugt der FHIR-Austausch strukturell gültige, aber semantisch nutzlose Daten.

Governance und die menschliche Seite

Standards scheitern häufiger aus organisatorischen als aus technischen Gründen. Drei Praktiken unterscheiden erfolgreiche Programme:

• Modell-Ownership zuweisen. Jemand muss das kanonische Modell besitzen und Erweiterungen genehmigen. Unkontrollierte Erweiterungen führen dazu, dass Profile und Ontologien verrotten.
• Versionierung und Deprecation bewusst steuern. Veröffentlichen Sie eine Deprecation-Richtlinie für Mappings und Profile, bevor Sie diese benötigen.
• Interoperabilität testen, nicht voraussetzen. Führen Sie Konformitätstests (z. B. FHIR’s Touchstone oder Inferno Tooling) und Vertragstests für Ihre kanonischen Mappings durch.

Maßgebliche, lesenswerte Quellen

• HL7 FHIR Spezifikation und Implementation Guides: hl7.org/fhir
• HL7 International (Mutterorganisation für FHIR, v2, CDA): hl7.org
• OMOP Common Data Model (OHDSI): ohdsi.org
• ISO 20022 Finanznachrichtenstandard: iso20022.org
• Cloud Information Model Projekt: cloudinformationmodel.org

Quellen & Weiterführende Literatur

• Interoperabilität — Wikipedia: Interoperabilität ist die Eigenschaft eines Produkts oder Systems, mit anderen Produkten oder Systemen zusammenzuarbeiten. Während der Begriff ursprünglich für Informationstechnologie definiert wurde…
• Fast Healthcare Interoperability Resources — Wikipedia: Die Fast Healthcare Interoperability Resources (FHIR, ausgesprochen wie „fire“) ist ein technischer Standard von HL7 International für den Austausch von Gesundheitsinformationen. Er ist konzipiert für…
• Klinische Datenstandards — Wikipedia: Klinische Datenstandards werden verwendet, um Informationen im Zusammenhang mit der Gesundheitsversorgung so zu speichern und zu kommunizieren, dass ihre Bedeutung eindeutig ist. Sie werden in der klinischen Praxis eingesetzt…

Welche Rolle spielt FHIR bei der Erreichung semantischer Interoperabilität?

FHIR bietet eine Möglichkeit, Informationen zwischen Klinikern und Organisationen auf standardisierte Weise darzustellen und zu teilen, unabhängig davon, wie lokale EHRs die Daten darstellen oder speichern. FHIR kombiniert die besten Funktionen der HL7 v2, HL7 v3 und CDA Produktlinien, nutzt dabei die neuesten Webstandards und legt einen starken Fokus auf die Implementierbarkeit. FHIR-Lösungen werden aus einem Satz modularer Komponenten namens Ressourcen aufgebaut, die leicht zu funktionierenden Systemen zusammengesetzt werden können, um reale klinische und administrative Probleme zu lösen.

Quelle: ecqi.healthit.gov

Welcher Interoperabilitätsstandard wird von EHR-Anbietern am häufigsten übernommen?

HL7 v2 ist der am weitesten verbreitete Interoperabilitätsstandard unter EHR-Anbietern. Die durch Pipes getrennten HL7 v2-Nachrichten fließen auch heute noch durch fast jedes Krankenhaus in den USA, und HL7-Standards bilden die Grundlage für den Austausch klinischer Daten.

Die HL7-Familie umfasst HL7 v2, HL7 v3, die Clinical Document Architecture (CDA) und FHIR, wobei HL7 v2 als Arbeitspferd der Gesundheits-IT dient. HL7-Schnittstellen werden in Epic, Cerner und anderen großen EHRs verwendet und spiegeln die breite Branchenakzeptanz in Krankenhäusern, Laboren, Apotheken und Gesundheits-IT-Anbietern wider.

Quelle: medblocks.com

Wie schneiden Interoperabilitätsstandards wie FHIR im Vergleich zu proprietären Lösungen ab?

Bei FHIR handelt es sich eher um eine gesundheitsspezifische Spezifikation als um ein allgemeines Unternehmensdatenmodell, sodass es keine Produktions-, Finanz-, Einzelhandels- oder Lieferketteneinheiten modelliert. Es als universelle Interoperabilitätsschicht zu behandeln, ist ein häufiger Architekturfehler.

Die meisten Unternehmen benötigen einen mehrschichtigen Ansatz: ein domänenunabhängiges kanonisches Modell darunter sowie Domänenstandards wie FHIR, ISO 20022 und X12 an den Rändern. FHIR zeichnet sich durch den Austausch klinischer Daten über RESTful-APIs und -Ressourcen aus. Zu den Einschränkungen zählen jedoch Versionsfluktuation, Profilproliferation, schwache native Analyseunterstützung und keine Abdeckung nichtklinischer Domänen.

Häufig gestellte Fragen

Ist FHIR ein Dateninteroperabilitätsstandard oder ein Datenmodell?

Es ist beides, aber mit einer Domänengrenze. FHIR ist ein Interoperabilitätsstandard für das Gesundheitswesen, der ein ressourcenbasiertes Datenmodell, eine RESTful-API-Spezifikation und ein Konformitätsframework umfasst. Da es sich nicht um ein allgemeines Unternehmensdatenmodell handelt, sollte es nicht zur Darstellung nichtklinischer Einheiten wie Produkte, Rechnungen oder Abonnements verwendet werden.

Was ist der Hauptunterschied zwischen FHIR und anderen Interoperabilitätsstandards?

FHIR ist gesundheitsspezifisch und API-orientiert und verwendet granulare Ressourcen über REST mit JSON oder XML. Ältere Standards im Gesundheitswesen wie HL7 v2 und CDA sind nachrichten- und dokumentzentriert. Nicht-gesundheitsbezogene Standards wie ISO 20022 und X12 zielen auf Finanzen und Lieferkette ab. Der Hauptunterschied liegt im Umfang: FHIR löst den klinischen Austausch, nicht die branchenübergreifende Integration.

Kann FHIR ein kanonisches Unternehmensdatenmodell ersetzen?

Nein. FHIR modelliert klinische Konzepte, nicht die gemeinsamen kommerziellen und betrieblichen Einheiten, die CRM-, ERP- und Finanzsysteme umfassen. Ein kanonisches Modell wie das Cloud Information Model liegt zwischen Domänen und stellt ein gemeinsames Vokabular bereit. FHIR speist diese kanonische Ebene typischerweise als Quelle oder Ziel ein, anstatt sie zu ersetzen.

Sollte ich FHIR R4 oder R5 verwenden?

R4 ist nach wie vor die am weitesten verbreitete Version und bildet die Grundlage für viele Regulierungsprogramme und Implementierungsleitfäden. Daher ist es heute in der Regel die sicherere Standardeinstellung für die Produktionsinteroperabilität.

R5 fügt neuere Funktionen und Verbesserungen hinzu, aber der Anbieter- und Tool-Support ist schleppend. Viele Unternehmen führen R4 in der Produktion aus, während sie gleichzeitig R5 testen, und nutzen dabei eine Übersetzungsschicht zur Überbrückung der Versionen.

Wie schneidet FHIR im Vergleich zu HL7 v2 und CDA ab?

HL7 v2 ist ein vorkoordinierter Messaging-Standard, der in Krankenhausschnittstellen immer noch vorherrschend ist. Er wird wegen seiner Allgegenwärtigkeit geschätzt, wird aber wegen seiner spröden, schwer zu analysierenden Semantik kritisiert.

CDA ist ein dokumentenzentrierter XML-Standard, der sich für klinische Zusammenfassungen eignet. FHIR ist detaillierter, API-freundlicher und einfacher zu erweitern, weshalb neue Entwicklungen im Allgemeinen FHIR bevorzugen, während v2 und CDA in Altsystemen fortbestehen.

Was sollte ein branchenübergreifendes Unternehmen standardisieren?

Die meisten branchenübergreifenden Unternehmen sollten einen mehrschichtigen Ansatz verfolgen: Domänenstandards an den Rändern (FHIR für klinische Daten, ISO 20022 für Zahlungen, X12 für Abrechnungen und Bestellungen) und ein domänenunabhängiges kanonisches Modell in der Mitte. Dies minimiert Punkt-zu-Punkt-Zuordnungen und sorgt dafür, dass jeder Domänenstandard das tut, wofür er entwickelt wurde.