FHIR, openEHR oder OMOP? Wer eine Plattform für Gesundheitsdaten baut, muss entscheiden, wie die Daten gespeichert werden. Die drei Standards erfüllen unterschiedliche Aufgaben. Welches Modell intern passt, hängt davon ab, was die Plattform leisten soll.
Drei Standards, drei Aufgaben
FHIR beschreibt, wie Systeme Gesundheitsdaten austauschen. Dafür gibt es Ressourcen wie Patient, Observation oder MedicationRequest. Profile legen genauer fest, welche Inhalte eine Schnittstelle erwartet. Beispiele aus Deutschland sind ISiK und die MIOs.
openEHR ist auf die langfristige Speicherung klinischer Informationen ausgerichtet. Es trennt das technische Grundmodell von den medizinischen Inhaltsmodellen, den sogenannten Archetypen. So lassen sich klinische Inhalte weiterentwickeln, ohne jedes Mal die technische Grundlage zu ändern.
OMOP vereinheitlicht Daten für die Forschung. Ein gemeinsames Tabellenschema und einheitliche Vokabulare ermöglichen vergleichbare Analysen über verschiedene Datenquellen hinweg. Bei der Überführung können Details des ursprünglichen Kontexts verloren gehen.
Das Modell folgt der Anwendung
Eine FHIR-Schnittstelle setzt nicht voraus, dass auch intern alles als FHIR-Ressource gespeichert wird. Eine Anwendung kann ein eigenes Modell nutzen und die Daten beim Austausch in FHIR übersetzen. Die direkte Speicherung kann sinnvoll sein, wenn die Plattform vor allem FHIR-Ressourcen empfängt, verwaltet und weitergibt.
Entscheidend sind die Aufgaben der Plattform: Welche Daten gehören zusammen? Welche Abfragen müssen schnell sein? Wie werden Änderungen, Zugriffsrechte und fachliche Regeln abgebildet? Daran sollte sich das Modell messen lassen. Ein eigenes Modell bietet Spielraum, bringt aber auch Verantwortung für Pflege und Übersetzung mit. openEHR kann eine Grundlage für die klinische Datenhaltung sein; OMOP dient vor allem der Auswertung.
Semantik ist wichtiger als Syntax
Für die gemeinsame Nutzung von Daten zählt vor allem, dass Systeme deren Bedeutung gleich verstehen. Die Syntax beschreibt, wie Daten aufgebaut sind; die Semantik beschreibt, was sie bedeuten. Ein gemeinsames Format erleichtert den Austausch, reicht allein aber nicht aus.
Ein Laborwert zeigt den Unterschied: Ob er in einer eigenen Tabelle oder als FHIR Observation gespeichert ist, sagt noch nicht, was gemessen wurde. Dafür braucht es die untersuchte Größe, die Einheit und den Messzeitpunkt sowie die Zuordnung zum Patienten. Codes wie LOINC für die untersuchte Größe und UCUM für die Einheit machen die Bedeutung eindeutig. Fehlen diese Angaben, löst auch die Speicherung als FHIR-Ressource das Problem nicht.
Für die Modellwahl heißt das: Die interne Struktur kann frei gewählt werden, die benötigte Bedeutung muss erhalten bleiben. Prüfen Sie deshalb schon beim Entwurf die vorgesehenen FHIR-Profile und gegebenenfalls die Anforderungen von OMOP. Daraus ergibt sich, welche Angaben und Codes das eigene Modell enthalten muss und wie sie sich zuordnen lassen. So wird die spätere Übersetzung von Anfang an berücksichtigt.
Eine praktische Entscheidung
Ausgangspunkt sind die konkreten Abläufe, Abfragen und Schnittstellen. Prüfen Sie daran, ob FHIR, openEHR oder ein eigenes Modell die interne Datenhaltung am besten unterstützt. Planen Sie die Übersetzung in die benötigten Austauschformate von Anfang an mit. Wird OMOP für Forschung oder Qualitätsauswertungen gebraucht, sollten auch dessen Anforderungen früh berücksichtigt werden.
Für spätere KI-Anwendungen sind dieselben Grundlagen wichtig: verständliche Inhalte, Zeitbezug und nachvollziehbare Quellen. Diese Informationen zu erhalten, ist eine zentrale Aufgabe des Datenmodells.