FHIR & openEHR, zwei Standards – eine Mission

Im sich rasant entwickelnden Bereich der elektronischen Gesundheitsversorgung sind der interoperable Austausch von Gesundheitsdaten, deren Aggregation zu verwertbaren Informationen und schließlich die intelligente Nutzung dieser Informationen zum Wohle der Patientinnen und Patienten entscheidende Schritte, die beim Aufbau einer langfristig nachhaltigen IT-Plattform berücksichtigt werden müssen.

Mit der zunehmenden Vernetzung im Internetzeitalter haben sich Informationswissenschaftlerinnen und -wissenschaftler mit Kernfragen beschäftigt, die – in einem allgemeineren Kontext – den grundlegenden logistischen Herausforderungen eines Einzelhandelsunternehmens ähneln: Wie bringe ich meine Waren schnell und sicher vom Hersteller in meine Filialen? Wie setze ich eine Lagerhaltung um, die mein Geschäft optimal unterstützt?

Für einen IT-Laien scheint es offensichtlich, dass Container, Paletten und Kisten für Ordnung und Schutz beim Versand sorgen, während die Kundinnen und Kunden letztlich schätzen, wenn die Produkte ansprechend präsentiert, beschriftet und leicht zugänglich an festen, logisch angeordneten Positionen im Laden platziert sind. Dieses Bild lässt sich übertragen auf die HL7/FHIR- und openEHR-Arbeitsgruppen, die Anfang der 2000er- bis 2010er-Jahre unabhängig voneinander begannen, ihre jeweiligen Entwicklungen in der klinischen IT hin zu Standards voranzutreiben – mit einem Schwerpunkt auf Datentransfer (FHIR) beziehungsweise Datenhaltung (openEHR).

Was haben Versand- und Lagerhaltungsszenarien – und ebenso FHIR und openEHR – gemeinsam? Beide nutzen interne Strukturen, physische Repräsentationen und Kontrollmechanismen, um Vollständigkeit und korrekte Beladung der „Artikel“ sicherzustellen. In der IT-Welt entspricht diese Struktur einem sogenannten Datenmodell und seiner Beschreibung in einer formalen, maschinenlesbaren Protokollsprache. Die physische Repräsentation ergibt sich aus der verwendeten Speicherart, und die Kontrollmechanismen beziehen sich auf die Datenvalidierung – also den Abgleich der Eigenschaften der Daten selbst mit den (ebenso detaillierten) Vorgaben des Datenmodells.

Das FHIR-Datenmodell bietet die grundlegenden Voraussetzungen und eine einfache Erweiterbarkeit, um praktisch alle Aspekte klinischer Informationen abzudecken und so eine sichere Übertragung klinischer Daten zu gewährleisten. Es enthält ausreichende Validierungsmechanismen, um die korrekte Beladung der Datenelemente sicherzustellen. FHIR-Informationen werden als eigenständige elektronische Ressourcendokumente gespeichert und übertragen, wobei jede Ressource einen spezifischen (klinischen) Aspekt der Information repräsentiert. FHIR eignet sich ideal für die Umsetzung der Vernetzung klinischer Datensysteme mit geringen Entwicklungskosten.

openEHR hingegen bietet ein äußerst detailliertes und strenges Datenmodell, das auf der Vollständigkeit und Stabilität wiederverwendbarer Archetypen basiert. Diese Archetypen werden sorgfältig geprüft und zielen darauf ab, die Realität klinischer Informationen so umfassend wie möglich abzubilden – einschließlich sehr detaillierter Regeln zur Datenvalidierung. Das openEHR-Datenmodell implementiert per Definition eine patientenzentrierte elektronische Gesundheitsakte (EHR). Informationen werden nativ in openEHR als Tabellen in einer echten relationalen Datenbank gespeichert. Zusätzlich unterstützt openEHR den Datenaustausch über elektronische Dokumentnachrichten.

Der entscheidende Schritt erfolgt, wenn die gesammelten Daten analysiert oder anderweitig genutzt werden sollen – etwa zum Trainieren von KI-Systemen. Dafür benötigt man:

1. große Mengen vielfältiger und konsistent fehlerfreier Daten,

2. die Fähigkeit, den Datenausschnitt exakt aus dem gesamten Datenbestand zu extrahieren, der für die Analyse erforderlich ist.

Die Datenkonsistenz in großen Datensätzen steht in engem Zusammenhang mit strengen und detaillierten Datenvalidierungsmechanismen, die wiederum von der Qualität des Datenmodells abhängen. Die Extraktion relevanter Daten für Analysen erfordert die technische Fähigkeit, Gruppen- oder Join-Operationen (ähnlich wie Pivot- oder Lookup-Funktionen in Excel) auf Daten durchzuführen, die über mehrere Ressourcen oder Tabellen verteilt sind. Diese technische Funktionalität ist relationalen Datenbanken inhärent und auf Leistung optimiert, jedoch in dokumentbasierten Datenbanken (die über Indexsysteme zugreifen) deutlich schwieriger zu implementieren.

Auf Grundlage der bisherigen Ausführungen wird deutlich, dass FHIR und openEHR jeweils ideal für ihre spezifischen Stärken – nämlich Datentransport und Datenspeicherung – geeignet sind und daher sorgfältig aufeinander abgestimmt werden sollten, um ihre jeweiligen Aufgaben optimal zu erfüllen und letztlich das gemeinsame Ziel einer interoperablen Gesundheitsdatenlogistik zu unterstützen.

Zum Schluss noch einmal zurück in die Welt des Einzelhandels: Wie geht man mit Eiern beim Kochen um?

Sie werden auf Paletten geliefert, die Eierkartons enthalten. In einem Privathaushalt wird man wahrscheinlich kaum auf die Abmessungen der Verpackung, die Eiergrößenklassifikation oder Chargen- und Haltbarkeitscodes achten. Man greift einfach zu dem Produkt, das einen guten Preis und ein akzeptables Mindesthaltbarkeitsdatum aufweist. Als industrieller Eierverarbeiter hingegen müssen Sie sich sehr wohl um Verpackung und Parameter Ihres Rohmaterials kümmern. Die Verpackung ist eng an Ihre automatisierte Verarbeitungsstraße gekoppelt, und die Qualitätsparameter der Eier beeinflussen die Gesamtqualität Ihres Endprodukts. Unerwartete (und nicht rückverfolgbare) Abweichungen können schnell zu einer ernsthaften, unter Umständen existenzbedrohenden Situation für Ihr Unternehmen führen!

Um den größtmöglichen Nutzen und die höchste Datensicherheit für Ihre Patientinnen und Patienten sowie andere klinische Stakeholder innerhalb Ihrer Organisation zu erzielen, sollten Sie sicherstellen, dass Ihre Datenpipeline solide ist – mit den richtigen Werkzeugen und erfahrenen Partnern.