Zum Hauptinhalt springen
4 Min. Lesezeit

Offene Standards genügen nicht: Warum das Ökosystem entscheidet

Ein Viewpoint im Journal of Medical Internet Research stellt die Debatte FHIR gegen OMOP gegen openEHR neu: Wichtiger als die Spezifikation ist die Open-Source-Gemeinschaft dahinter. Das Argument trägt — doch es ist Meinung, keine Evidenz, und die Autor:innen sind Partei.

Dr. Sven Jungmann

Dr. Sven Jungmann

CEO

Editorial-Collage: drei flache geometrische Blöcke unterschiedlicher Größe mit angedeuteten Code-Beitragsrastern, davor zwei Hände, die eine Akte über die Naht reichen, dazu ein einzelner Amber-Akzent auf dem größten Block.

Wenn ein Krankenhaus einen Gesundheitsdatenstandard wählt, vergleicht es meist die Spezifikationen: Welches Datenmodell ist reicher, welche Abfragesprache schneller, welches deckt mehr von der Versorgung ab. Die Wahl gilt als technische Entscheidung. Ein Viewpoint im Journal of Medical Internet Research argumentiert, dass das die falsche Stelle ist, um hinzusehen — und der Beitrag lohnt eine sorgfältige Lektüre, gerade weil er ein Argument ist und kein Ergebnis.

Die drei Standards lösen einander überschneidende Probleme. FHIR (Fast Healthcare Interoperability Resources) dient dem Datenaustausch zwischen Systemen. OMOP (Observational Medical Outcomes Partnership, gepflegt von der OHDSI-Gemeinschaft) ist ein gemeinsames Datenmodell, um Beobachtungsdaten über Standorte hinweg auszuwerten. openEHR ist eine Architektur für die längsschnittliche Krankenakte. Die These der Autor:innen lautet: Entscheidend ist nicht, welche Spezifikation am saubersten ist, sondern welche das lebendige Open-Source-Ökosystem besitzt, um eine Implementierung über ein Jahrzehnt am Leben zu halten.

Das Argument

Die Autor:innen machen drei Schritte. Erstens: Offene Standards seien notwendig, aber nicht hinreichend. Eine offene Spezifikation trage erst dann, wenn eine große Gemeinschaft die Software darum herum baut und pflegt — und diese Gemeinschaft brauche einen äußeren Anreiz, in der Regel Regulierung, um sich zu halten. FHIR sei der einzige der drei Standards, der in mehreren Rechtsräumen regulatorisch verankert ist, was seinem Ökosystem einen Grund zum Wachsen gibt.

Zweitens übertragen sie den Gedanken der „Spanning Layer“ aus der Internetarchitektur — die schmale Taille einer Sanduhr, durch die alles hindurchläuft — und schlagen vor, dass FHIR diese Rolle zwischen Datenerfassung, Austausch und Analyse einnehmen kann, obwohl es ursprünglich nicht für die Analytik entworfen wurde. Drittens greifen sie zu einem Anhaltspunkt, dem eine Softwareentwicklerin mehr traut als einer Marketingaussage: der Open-Source-Aktivität auf GitHub.

Die GitHub-Zahlen vom 28. Januar 2025 sind ungleich verteilt. Zählt man alle Beitragenden über die gesamte Laufzeit der Projekte, zeigt FHIR rund 8.500, OMOP/OHDSI etwa 1.000 und openEHR rund 430. Beschränkt man das Fenster auf die vorangegangenen drei Monate, bleibt der Abstand bestehen: etwa 1.650 aktive Beitragende bei FHIR gegenüber rund 450 bei OMOP und 80 bei openEHR. Die Autor:innen nennen diese Werte ausdrücklich grobe Anhaltspunkte — FHIR habe mehr Anwendungsbereiche, also sei mehr Aktivität zu erwarten —, doch die Größenordnung lässt sich schwer wegwischen.

Was ein Viewpoint belegen kann und was nicht

Hier zählt die Disziplin des Journal Clubs. Es handelt sich um einen Viewpoint: eine strukturierte Meinung, keine Studie. Es gibt kein Protokoll, keinen Vergleichsarm, kein gemessenes Ergebnis. Die GitHub-Aktivität ist ein vernünftiger Anhaltspunkt für die Lebendigkeit einer Gemeinschaft, aber ein Anhaltspunkt — kein Maß für die Eignung zu einem klinischen Zweck; eine kleinere Gemeinschaft kann einen disziplinierteren Standard für eine eng umrissene Aufgabe hervorbringen. Der Beitrag sagt, welches Ökosystem am betriebsamsten ist. Er sagt nicht, welcher Standard Ihre Daten am besten trägt — und er gibt auch nicht vor, das zu tun.

Auch die Darstellung neigt sich. Das Argument ist so gebaut, dass es FHIR als Spanning Layer begünstigt, und drei der sechs Autor:innen legen kommerzielle Interessen offen: an Unternehmen, die Infrastruktur für föderiertes Lernen, klinische Algorithmen oder den Austausch von Gesundheitsdaten bauen. Nichts davon ist verschleiert — die Offenlegungen stehen klar im Text —, und ein Interessenkonflikt ist keine Widerlegung. Doch eine Meinung, die zu einem für ihre Verfasser:innen günstigen Schluss kommt, gewinnt ihr Gewicht erst, wenn die Begründung überzeugt und nicht der Name. Das tut sie hier weitgehend; es bleibt eine Begründung, keine Datenlage.

Eine offene Spezifikation ist notwendig, aber nicht hinreichend. Was eine Implementierung über ein Jahrzehnt am Leben hält, ist die Gemeinschaft dahinter.

Warum das hier zählt

Für ein deutsches oder europäisches Krankenhaus lässt sich das konkret übersetzen. FHIR trägt bereits die von den gematik-Spezifikationen vorgeschriebene nationale Infrastruktur, und die Autor:innen verweisen unmittelbar auf deutsche Arbeiten: Die KETOS-Plattform betreibt eine FHIR/OMOP-Hybridlösung, und ein Verbund von zehn deutschen Universitätskliniken berichtete von rund 99 Prozent Konformität bei der Überführung von FHIR-Daten in das OMOP-Modell — ein Beleg dafür, dass sich beide Standards kombinieren statt gegeneinander wählen lassen. Genau das untergräbt leise die Rahmung der ganzen Debatte. Die realistische Frage für die meisten Häuser lautet nicht FHIR oder OMOP oder openEHR, sondern: welcher Standard für den Austausch, welcher für die Analyse, und ob die Umwandlung zwischen beiden reif genug ist, um sich darauf zu verlassen.

Lesen Sie diesen Beitrag also für das Richtige. Nicht als Beweis, dass FHIR gewinnt, sondern als gut begründete Erinnerung daran, dass ein Standard nur so gut ist wie die Software und die Menschen, die ihn pflegen — und dass die Größe und Beständigkeit dieser Gemeinschaft auf die Bewertungsliste gehört, neben die Spezifikation selbst.

Quelle: Kapitan D, Heddema F, Dekker A, Sieswerda M, Verhoeff BJ, Berg M. Data Interoperability in Context: The Importance of Open-Source Implementations When Choosing Open Standards. J Med Internet Res 2025;27:e66616. Ein Viewpoint — ein strukturiertes Argument ohne eigene Primärdaten —, in dem mehrere Autor:innen kommerzielle Interessen an Interoperabilitätsinfrastruktur offenlegen; zu lesen als informierte Meinung, nicht als Evidenz.

#Journal Club#Interoperabilität#Gesundheitsdatenstandards#FHIR#Open Source

Weiterlesen

Entlassmanagement-Software: der Entlassbrief entsteht aus den geprüften Daten der Aufnahme, nicht erst am Entlasstag.
Aufnahmemanagement

Entlassmanagement-Software: warum der Entlassbrief am Aufnahmetag entschieden wird

Gutes Entlassmanagement entscheidet sich am Aufnahmetag, nicht am Entlasstag — der Entlassbrief ist nur so vollständig wie die Daten, die bei der Aufnahme erfasst wurden. aiomics verifiziert diese Daten am Eingang und erzeugt daraus den Entlassbrief im Briefkopf des Hauses.

Dr. Sven JungmannCEO

Diese Analyse stammt von den Leuten hinter Visite.

Unser wöchentlicher Newsletter zu KI in der Medizin. Jeden Freitag, gründlich geprüft.

Mit der Anmeldung stimmen Sie dem Erhalt von Visite per E-Mail zu. Abmeldung jederzeit. Mehr in unserer Datenschutzerklärung.

Sie möchten das in Ihrer Klinik sehen?

30 Minuten. Ihre Fragen. Unser Arzt-Gründer zeigt Ihnen die Plattform persönlich.

Termin vereinbaren

Unverbindlich. Kein Vertrieb. Arzt zu Arzt.