Patientendaten semantisch abfragen

Wir begleiten eine Ärztin, die eine Arbeitshypothese überprüfen möchte und deswegen die Häufigkeit von viralen Lungeninfektionen eines Patienten in den letzten drei Jahren abfragen möchte. Wie ist es möglich, diese Information mit einer gezielten Abfrage zu erhalten, ohne digitale Dokumente oder andere Daten durchsehen zu müssen, und was braucht es dafür? Anders gefragt: Wie könnten und müssten FHIR und da­rin genutzte Terminologien, insbesondere SNOMED CT¹, dafür kombiniert werden?

Die interoperable Repräsentation medizinischer Daten ist die Basisstufe der Kombination von FHIR und SNOMED als zentrale Säulen der Interoperabilität im Gesundheitswesen. Damit die Daten von unterschiedlichen IT-Systemen einheitlich interpretiert werden können, muss ihr Aufbau (die Syntax) und ihr Inhalt (die Semantik) strukturiert und standardisiert abgebildet sein. Dafür hat sich die Kombination von HL7 FHIR und SNOMED etabliert, auch wenn in vielen Bereichen weitere Codesysteme verwendet werden. Dementsprechend werden FHIR-Profile spezifiziert, inklusive der dafür gültigen SNOMED-Codes.

Die SNOMED-Codes werden als einheitliche Repräsentation klinischer Konzepte bzw. Begriffe (z. B. für Diagnosen) verwendet, sodass bei unterschiedlicher Ausprägung (Synonyme, Sprachen) desselben Konzepts (z. B. eine Lungeninfektion) trotzdem derselbe Code (SCTID  128601007)² verwendet werden kann. In der Datenrepräsentation wird SNOMED also als Terminologie (eine Auflistung von Konzepten) verwendet, auch wenn seine Stärken – wie wir sehen werden – noch weiter gehend als Ontologie (eine maschinenverständliche Beschreibung von Konzepten) im Datenabruf nutzbar sind. So gibt es SNOMED-Codes jeweils für Infektionen und für Lungeninfektionen, aber keinen expliziten Einzel-Code für eine virale Lungen­infektion.

Wie verstehen Computer medizinische Daten?
In Deutschland erfolgt bisher die FHIR- und SNOMED-basierte Standardisierung häufig mittels der Spezifikation digitaler Dokumente, u. a. aus Gründen organisatorischer Interoperabilität, sodass etablierte Formate wie das Kinderuntersuchungsheft oder der KH-Entlassbrief digital nachgenutzt werden können. Dadurch werden die Syntax und die Semantik medizinischer Daten für IT-Systeme erwartbar. Denn Interoperabilität bedeutet nicht vorrangig, dass Daten 1:1 übernommen werden können, sondern dass vor dem Erhalt der Daten klar ist, wie diese übernommen werden können (um IT-Systeme für eine automatisierte Datenintegration vorzubereiten).

Das ist jedoch umso aufwendiger, je umfangreicher diese Dokumente als Transportvehikel sind. Sie können zwar gut als Basis für die Erstbefüllung mit zusammenhängenden, interoperablen Daten dienen; eine integrierte Verwendung in die jeweiligen Arbeitsabläufe unterstützen sie jedoch nicht. Vielmehr müssen dafür die einzelnen Daten digitaler Dokumente auch in unterschiedlichen Granularitäten abrufbar sein. Nehmen wir also an, dass die interoperable Datenbasis für unsere Ärztin vorhanden ist, insbesondere auf Granularitätsebene der gewünschten Dia­gnosen zu viralen Lungeninfektionen des Patienten (also FHIR-Ressourcen des Typs condition). Nun gilt es, die benötigte Information gezielt abzufragen.

Denn die Stärke von FHIR liegt nicht nur in der einheitlichen Datenrepräsentation, sondern auch in den Abfragemöglichkeiten dieser Daten mittels standardisierter FHIR-Schnittstellen. Hierfür werden, wie im Internet etabliert, RESTful APIs (als Datenschnittstellen unter Verwendung des HTTP-Standards) spezifiziert, sodass das Internet als Kommunikationsmedium verwendet werden kann. So können Daten als FHIR-Ressourcen, in unterschiedlichen Granularitäten – einzeln oder kombiniert – abgerufen werden, so wie sie dem jeweiligen Arbeitsschritt angepasst benötigt werden. Denn unsere Ärztin hat keine Zeit, Dokumente zu durchforsten, um an die eigentlich benötigte Information zu kommen. Ihr IT-System soll die benötigten Daten, z.B. die Diagnosen zu viralen Lungeninfektionen eines Patienten, gezielt abrufen.

Semantische Abfragen am Beispiel der viralen Lungenentzündung
Durch die Verwendung von FHIR-Suchparametern, wie dem Diagnose-Code, könnten gezielt Diagnosen unter Angabe eines oder mehrerer Codes abgerufen werden.³ Wenn ein standardisierter FHIR-Suchparameter also von einem FHIR-Server implementiert ist, können die codierten Daten des Patienten damit gezielt abgerufen werden. Dafür muss das IT-System der Ärztin aber die infrage stehenden SNOMED-Codes im Suchparameter der FHIR-Abfrage angeben. Wir wollen der Ärztin aber weder abverlangen, dass sie alle relevanten klinischen Konzepte auswendig kennt, noch die dazugehörigen SNOMED-Codes einzeln zu suchen. Vielleicht bietet ihr IT-System eine Funktion an, um typische Fragestellungen zusammenzustellen, z. B. indem die entsprechenden Codes aller viralen Lungeninfektionen in einer Wertemenge (ein explizites Valueset) zusammengestellt sind. Aber woher ist gewährleistet, dass diese Liste vollständig und aktuell ist sowie von den datenhaltenden Einrichtungen einheitlich verwendet wird? Außerdem möchte unsere Ärztin die Flexibilität erhalten, Codes angepasst an ihre aktuelle Arbeitshypothese von ihrem IT-System zusammenstellen zu lassen.

Hier kommen SNOMED-Terminologieserver bzw. -Terminologieservices ins Spiel. Sie bieten nicht nur eine konsolidierte Fassung der Terminologie, sondern – und das macht SNOMED CT aus – auch eine Logik, um diese maschineninterpretierbar zu beschreiben und abzufragen. Denn SNOMED ist als Ontologie aufgebaut, deren klinische Konzepte durch die Beziehung untereinander nach dem Muster Domain – Attribut – Range⁴ beschrieben werden. Hierbei können hierarchische Is-a-Beziehungen, z. B. [infectious disease of lung] - [is a] - [infectious disease], von Attributbeziehungen⁵, z. B. [infectious disease of lung] - [causative agent] - [virus], unterschieden werden.

Mittels SNOMED ECL (Expression Constraint ­Language), die auf der SNOMED compositional grammar basiert, können Konzepte abgefragt werden, die alle geforderten Beziehungen aufweisen; in unserem Beispiel sind das hierarchische Beziehungen jeweils von Lungeninfektionen und von Viren sowie Attribut-Beziehungen zu Viren. Erst diese Angabe der Beziehungen bei der Suche ermöglicht semantische Abfragen. Insbesondere kann der Server dadurch die Frage beantworten, welche SNOMED-Konzepte die abgefragten Hierarchie- und / oder Attribut-Beziehungen erfüllen.

In der aktuellen SNOMED-Version können so die 42 vorhandenen Konzepte viraler Lungeninfektionen abgerufen werden. Eine passende GUI vorausgesetzt, kann das IT-System auf Basis der Nutzereingaben unserer Ärztin nun einen Terminologieserver mittels ECL abfragen⁶ und erhält eine maßgeschneiderte Codeliste (Valueset), die als Code-Suchparameter in einer FHIR-Abfrage der Patientendaten inte­griert werden kann. Unsere Ärztin kann nun also beim FHIR-Server alle Diagnosedaten abfragen, die mit einem der 42 expliziten Codes des vom Terminologieserver abgerufenen Valuesets codiert sind. Für eine zuverlässige semantische Abfrage reicht das jedoch nicht aus, wie wir gleich sehen werden.

Und was ist mit der COVID-Lungenentzündung?
Denken wir kurz an den Februar 2020. Denn die Ärztin möchte heute selbstverständlich auch über eine gegebenenfalls beim Patienten zu dieser Zeit aufgetretene SARS-CoV-2-Infektion informiert werden. Welche Möglichkeit hatten ihre Kolleg:innen damals, eine solche Diagnose zu codieren, ohne dass zu dieser Anfangszeit ein expliziter SNOMED-­Code für COVID-19 oder SARS-CoV-2 verfügbar war? Auch hier kommt die Beschreibung von klinischen Konzepten durch Formulierung ihrer Beziehungen ins Spiel. In diesem Fall wird die SNOMED compositional grammar zur Repräsentation eines zusammengesetzten SNOMED-Ausdrucks (Expression) verwendet, womit FHIR-Ressourcen implizit codiert ⁷ werden können. Da es keinen expliziten Begriff für eine SARS-CoV-2-Infektion gab, muss der Begriff somit quasi mittels seiner Beziehungen (also mit den nächst passenden Hierarchien und Attributen), bspw. als Lungeninfektion mit einem unspezifischen menschlichen Coronavirus, umschrieben werden. Diese Art der impliziten Codierung ist auch überall dort nützlich, wo SNOMED für – oft sehr spezifische – Sachverhalte keine explizit codierten Konzepte anbietet.

Denn generell beansprucht SNOMED nicht eine Codierung aller möglichen klinischen Sachverhalte in all ihren Feinheiten. Dafür bietet SNOMED quasi ein Baukastensystem für implizite Codierungen an. Dieses Vorgehen entspricht dem Ansatz, allgemeine Probleme gemeinsam explizit zu lösen, gleichzeitig aber einen interoperablen Rahmen zu bieten, um spezifische Probleme dort zu lösen, wo sie anfallen. Das unbekannte Konzept, für das (noch) kein standardisierter Code verfügbar ist, wird also implizit über die Codierung seiner Beziehungen zu bestehenden SNOMED-Konzepten beschrieben, ohne dass es einen expliziten eigenen SNOMED-Code erhält.⁸

Welche und wie viele Beziehungen dabei angegeben werden, um die Diagnose implizit zu beschreiben, ist u. a. abhängig von den Eingabemöglichkeiten des IT-Systems und der Angabe der eintragenden Ärzt:innen. Die Berücksichtigung einer Normalform im SNOMED-Ausdruck⁹ kann bei der korrekten impliziten Codierung unterstützen, schränkt jedoch die Detaillierungstiefe impliziter Codes nicht ein. Nehmen wir nun an, dass ein Arzt im Februar 2020 eine Lungeninfektion unseres Patienten mit einem menschlichen Coronavirus (z. B. human coronavirus) angegeben hat. Ärzt:innen hätten also im Februar 2020 eine indirekte Möglichkeit, die unbekannte Diagnose durch einen impliziten SNOMED-Code anzugeben. Aber wie können diese Daten ohne einen Einzel-Code, der von einem Terminologieserver abgerufen werden kann, in der aktuellen Abfrage unserer Ärztin berücksichtigt werden?

Wie können implizierte Codes gefunden werden?
Rekapitulieren wir kurz: Bisher erhält das IT-System der Ärztin von einem SNOMED-Terminologieserver ein Valueset mit expliziten Codes aller durch einen ECL-Ausdruck abgebildeten klinischen Konzepte, die das System dann als Suchparameter in einer FHIR-Abfrage einbettet, um von FHIR-Servern alle Diagnosen zu viralen Lungeninfektionen eines Patienten abzurufen. Die Logik der FHIR-Suche betrachtet die als Suchparameter mitgegebenen Diagnose-Codes einfach als ein Token (eine Zeichenabfolge), das mit dem Code-Attribut der Diagnosedaten (der FHIR-Ressource condition) syntaktisch verglichen wird. Die FHIR-Spezifikation sieht also nicht vor, einerseits den im Suchparameter angegebenen Code als ECL-Ausdruck und andererseits den Inhalt des Code-Attributs als zusammengesetzten SNOMED-Ausdruck semantisch interpretieren zu können. Die implizit codierten Diagnosen des Februars 2020 können so nicht gefunden werden, da ja die 42 expliziten Codes des vom Terminologieserver erhaltenen Valuesets diese nicht kennen.
Wie kann unsere Ärztin ihre Frage mit der aktuellen FHIR-Spezifikation trotzdem zuverlässig beantworten? Im einfachsten Fall kann das Valueset des Terminologieservers mit Ableitungen des ECL-Ausdrucks für virale Lungeninfektionen (der somit als zusammengesetzter SNOMED-Ausdruck bzw. Code verwendet wird) ergänzt werden. In der anschließenden FHIR-Suche werden die ergänzten impliziten Codes – so wie die anderen Codes des Valuesets – somit als Token verwendet, die mit den Codes der FHIR-Ressourcen, die ja auch mittels eines zusammengesetzten SNOMED-Ausdrucks implizit codiert sein könnten, als Zeichenfolge abgeglichen werden.

Aber auch diese Variante würde die im Februar 2020 als Lungeninfektion mit unspezifischem menschlichem Coronavirus codierte Diagnose^{10, 11} nicht finden, solange der vom ECL-Ausdruck abgeleitete SNOMED-Ausdruck dem in der FHIR-Ressource angegebenen Code nicht 1:1 entspricht. Unsere Ärztin (bzw. ihr IT-System) kann aber nicht wissen, welche Zusammensetzung im SNOMED-Ausdruck ein Arzt und sein IT-System im Februar 2020 verwendet hat, um eine virale Lungeninfektion implizit zu codieren. Muss nun der Terminologieserver oder das IT-System der Ärztin versuchen, alle Möglichkeiten der impliziten Codierung zu berücksichtigen, um – ohne Gewähr auf Vollständigkeit – quasi jenen zusammengesetzten SNOMED-Ausdruck zu „erraten“, der im Februar 2020 verwendet wurde?

Expression Repositories als Komponenten einer Terminologie-Infrastruktur?
Falls der Terminologieserver den im Februar 2020 vom Arzt gewählten impliziten Code für die COVID-19-Diagnose bereits kennen würde, kann er diesen bei der Abfrage aller Codes für virale Lungeninfektionen berücksichtigen. Eine solche von SNOMED International diskutierte Möglichkeit wäre die Verwendung eines (national) abgestimmten Expression Repository als Komponente einer Terminologie-Infrastruktur, bei der implizite Codes geprüft und registriert werden. Falls bei der Eintragung codierter FHIR-Daten der angefragte Terminologieserver keine passenden expliziten Codes bieten kann (z. B. für COVID-19 im Februar 2020), sucht ein Terminologieservice in einem Expression Repository nach passenden impliziten Codes, die andere Ärzte bereits angelegt haben könnten.

Falls keiner vorhanden ist, kann der Arzt beim Terminologieserver einen neuen impliziten Code registrieren. Die Eintragung könnte mittels standardisierter Templates (z.B. für Diagnose-Codes) durchgeführt und validiert werden, und im Repository unter einer Expression-ID als SCTID abgelegt werden. Diese ID würde nun wie ein expliziter Code in der FHIR-Ressource verwendet und wie bisher im Zuge der Suche verglichen werden können. Damit diese Variante zuverlässige semantische Suchen ermöglicht, müsste sichergestellt werden, dass in den FHIR-Ressourcen aller Gesundheitseinrichtungen statt impliziter Codes ausschließlich Expression-IDs verwendet werden. Das brächte hohe Regulierungsanforderungen, eine hohe Abhängigkeit zur Terminologie-Infrastruktur mit sich und ist vor allem rückwirkend schwer durchsetzbar.

Weitere Integration von FHIR- und SNOMED-Abfragen wäre hilfreich
Da die Verwendung impliziter Codes in FHIR-Ressourcen trotzdem wohl nicht ausgeschlossen werden kann, ist davon auszugehen, dass die semantische Suche mit einem regulierten Expression Repository zwar deutlich zuverlässiger, aber für eine exakte Suche trotzdem nicht hinreichend sein wird. Dafür wäre eine weitere Integration der FHIR- und SNOMED-Abfragen hilfreich, sodass der implizite Code bei der FHIR-Suche nicht nur als Einzel-Code syntaktisch abgeglichen wird, sondern entsprechend seiner Logik semantisch interpretiert wird. Wie könnte die FHIR-API erweitert werden, um die durch den ECL-Ausdruck abgebildeten Beziehungen (Hierarchie, Attribute) in die FHIR-Abfragesyntax einzubetten?
Eine Variante der Verknüpfung beider Abfragen wäre die Angabe des ECL-Ausdrucks als FHIR-Suchparameter, damit dieser im Zuge der FHIR-Suche als solcher interpretiert wird und codierte FHIR-Ressourcen semantisch interpretieren kann. Eine andere Variante würde Möglichkeiten bieten, ECL-Operatoren – insbesondere jene, die Beziehungstypen abbilden – in FHIR-Suchoperatoren abzubilden. Für die besonders wichtige Beziehungsart der Hierarchie ist das aktuell mit den FHIR-Suchoperatoren (sogenannten modifiers) below und above möglich.

Derzeit wird jedoch in FHIR kein generischer Suchoperator spezifiziert, mit dem Attribut-Beziehungen angegeben werden können. Auch gibt es keine Möglichkeit, einen ECL-Ausdruck als Suchparameter anzugeben, der im Zuge der FHIR-Suche aufgelöst werden soll (s. o.). Eine Alternative ist die indirekte Angabe der semantischen Suchparameter (Hierarchie- bzw. Attribut-Beziehungen) in einem terminologiespezifischen impliziten Valueset (unter Verwendung des :in-modifiers). Eine Umsetzung all dieser Varianten würde zwar die Zuverlässigkeit semantischer Suchen ­erhöhen, jedoch nur um den Preis eines terminologiespezifischen Implementierungsaufwands. Außerdem benötigt der FHIR-Server für das semantische Matching zusätzlich terminologiespezifische Informationen, die er zwischenspeichern muss oder für jeden Code von einem Terminologieserver abrufen muss.¹²

Ein kleiner Umweg kann vielleicht helfen
Die Frage unserer Ärztin kann somit derzeit mit einer gezielten Abfrage nicht exakt beantwortet werden. Die eingeschränkte Verknüpfung der SNOMED- und FHIR-Abfragesprachen und -logik reduziert somit die Zuverlässigkeit semantischer Abfragen. Muss unsere Ärztin nun also alle Diagnosen des Patienten einzeln durchsehen, um ihre Arbeitshypothese zu testen? Erinnern wir uns, dass sie zur Prüfung ihrer Arbeitshypothese eigentlich erst mal nur die Häufigkeit der Diagnosen benötigt. Welche Diagnosen das im Detail sind, ist (noch) nicht Teil ihrer Fragestellung.¹³ Oft kann bereits die ungefähre Anzahl vergangener Diagnosen für eine aktuelle Indikation ausschlaggebend sein, wobei es dann eher um Richtwerte als um präzise Häufigkeiten geht.

Eine solche Frage benötigt auch nicht den Abruf der einzelnen FHIR-Ressourcen, sondern nur die Rückgabe ihrer Anzahl in der jeweiligen Gesundheitseinrichtung. Das würde auch der Datensparsamkeit und Effizienz zugutekommen. Immerhin wäre eine solche Beantwortung der ärztlichen Frage schon deutlich mehr, als die Ärztin in der Regel heute von ihren IT-Systemen gewohnt ist. Und wie beim Thema Interoperabilität üblich, findet die Entwicklung und Abstimmung in mal kleineren, mal größeren Schritten statt. Auch bei der semantischen Suche gilt somit, dass die perfekte interoperable Lösung nicht auf Anhieb, sondern schrittweise zu erreichen sein wird. Das soll uns aber nicht hindern, damit anzufangen bzw. die Arbeit schrittweise fortzuführen.

Welche semantischen Abfragen sind jetzt schon möglich?
Fassen wir abschließend zusammen, was es dafür braucht und was davon bereits vorhanden ist. Seit dem 01.01.2021 ist Deutschland Mitglied von SNOMED International. Somit können die SNOMED-Release-Files über das BfArM (Bundesinstitut für Arzneimittel und Medizinprodukte) als National Release Center bezogen und genutzt werden. Unter Verwendung eines frei erhältlichen oder proprietären Terminologieservers (wie Ontoserver, Snow Owl oder Snowstorm) kann das SNOMED-Codesystem, in der Regel mittels FHIR-basierten Terminologieservices, in die IT-Systemlandschaft einer Einrichtung eingebunden werden. Falls der IT-Dienstleister der Ärztin diese Leistung anbietet und alle benötigten Daten des Patienten in der Gesundheitseinrichtung FHIR-strukturiert und SNOMED-codiert vorliegen, sind die grundlegenden Voraussetzungen erfüllt, um ihre Frage nach der Häufigkeit von viralen Lungeninfektionen des Patienten innerhalb ihrer Einrichtung zu beantworten.

Dafür sucht sie mittels einer nutzerfreundlichen GUI die entsprechenden drei Codes für [infectious disease of lung], [causative agent], [virus] für ihre Fragestellung (die vielleicht schon vorbereitet sind) und schickt ihre Anfrage ab. Nachdem ihr IT-System diese Codes in eine ECL-Abfrage einbindet, um ein maßgeschneidertes Valueset mit Codes zu allen viralen Lungeninfektionen zu erhalten (das ggf. mit impliziten Codes ergänzt wird, s. o.), fragt es die Anzahl der FHIR-Ressourcen des Typs condition ab, die mit einem der Codes belegt sind. Mit der vom IT-System direkt zurückerhaltenen Zahl kann unsere Ärztin nun ihre Arbeitshypothese falsifizieren oder erhärten. Auch eine tiefer gehende Verknüpfung der SNOMED- und FHIR-Abfragen kann durch den IT-Anbieter im Zuge seiner Serverimplementierung angeboten werden. Das alles ist heute bereits möglich.

Nun wollen und müssen wir jedoch davon ausgehen, dass die Daten des Patienten von unterschiedlichen Gesundheitseinrichtungen gehalten werden. Hier kommt der eigentliche Zweck von Standards im heterogenen Gesundheitswesen ins Spiel: Unterschiedliche Einrichtungen sollen ihre Daten möglichst nahtlos abrufen und verwenden können. In Deutschland gibt es einige Standardisierungsmaßnahmen (allen voran die ePA mit den MIOs, die MII und ISiK¹⁴), die dieses Ziel verfolgen, sowohl im ambulanten als auch im stationären Bereich, in der Versorgung, der Forschung, der Pflege, im öffentlichen Gesundheitsdienst und im besten Fall auch zwischen ihnen. Der aktuelle Schwerpunkt dieser Maßnahmen liegt in der interoperablen Repräsentation der Daten. In unserem Szenario würde das den FHIR-Ressourcentyp condition betreffen, insbesondere seine Codierung mittels SNOMED, inklusive einer Regelung für eine etwaige Verwendung impliziter Codes.

Für einen einheitlichen Abruf von FHIR-Ressourcen (das IT-System der Ärztin soll ja denselben Abruf bei allen Einrichtungen absetzen können) ist sowohl der Aufbau des Abrufs zu standardisieren als auch der dafür verwendete Kanal bzw. die Infrastruktur dafür. Ähnlich wie bei der Repräsentation der FHIR-Ressourcen und ihrer Profilierung bietet der FHIR-Standard einen Rahmen, der für einen interoperablen Abruf weiter eingeschränkt werden muss. Das beinhaltet die Spezifikation umzusetzender einheitlicher Suchparameter und die Verwendung von Suchoperatoren (FHIR-modifiers). Neben ihrer Spezifikation müssen dabei auch Bedingungen ihrer Umsetzbarkeit mitberücksichtigt werden. Damit FHIR-Server bspw. die FHIR-modifier above und below mit vergleichbaren Rückgabewerten umsetzen können, um hierarchische Beziehungen zwischen Codes aufzulösen, ist ein einheitlicher Zugriff auf Terminologieserver hilfreich. Es werden somit auch Fragen der Infrastruktur aufgeworfen. Das betrifft nicht nur jene nach abgestimmten Terminologieservices und Vertrauensbeziehungen zwischen den FHIR- und Terminologieservern, sondern grundlegende Fragen eines verteilten Gesundheitsdatenraums.

Semantische Abfragen in einer Interoperabilitätsstrategie
Je einheitlicher die Integration von SNOMED- und FHIR-Abfragen ist, desto zuverlässiger sind also die Ergebnisse semantischer Abfragen von Patientendaten. Eine Integration könnte die Verwendung von ECL-Ausdrücken in FHIR-Suchparametern (Variante 1) oder die Abbildung von ECL-Operatoren in FHIR-modifiers (Variante 2) spezifizieren. Ohne geeignete FHIR-Spezifikation könnte mittels Terminologieservices ein abgestimmtes Expression Repository für die Erzeugung, Verwaltung und den Abruf impliziter Codes verwendet werden (Variante 3). Variante 3 zeigt im Vergleich zu den anderen Varianten zwar geringere Abhängigkeiten zu Spezifikationen der FHIR-API, dafür aber hohen Regulierungsbedarf. Es bleibt zu diskutieren und abzuwägen, welcher Weg geeignet ist, um in eine Interoperabilitätsstrategie für Deutschland eingebettet zu werden.

Insgesamt bietet die lose Kopplung von FHIR und SNOMED auf der Ebene der Datenrepräsentation zwar eine wichtige Grundlage, für zuverlässige semantische Abfragen ist jedoch eine tiefer gehende Integration in der Datenabfrage und die Verwendung einheitlicher Schnittstellen zu bevorzugen. Dafür ist ein (national) standardisierter Rahmen nötig. Die derzeitigen Möglichkeiten zur Verknüpfung der Abfragen bieten jedoch eine für viele Anwendungsfälle ausreichende Annäherung an zuverlässige semantische Abfragen. Eine abgestimmte Terminologie-Infrastruktur mit einem Expression Repository kann die Zuverlässigkeit deutlich erhöhen, erfordert jedoch ein hohes Maß an (nationaler) Regulierung. Eine Repräsentation des FHIR-Modells und der SNOMED-Terminologie in einem gemeinsamen Format (RDF bzw. OWL) würde zwar eine gemeinsame und somit integrierte Abfragesprache ermöglichen (SPARQL bzw. DL-Reasoner). Die Praktikabilität dieser Variante bleibt aber noch zu erkunden. Neben weiteren Herausforderungen gilt es erst mal weiterhin, die Grundlagen für semantische Abfragen zu schaffen und den Blick auf das Gesamtbild dabei so beizubehalten, dass der Nutzen semantischer Abfragen für Ärzt:innen und Patient:innen schrittweise gesteigert werden kann.

Referenzen

1. Zwecks Einfachheit wird im Text SNOMED synonym zu SNOMED CT verwendet.
2. SCTID = SNOMED-CT-ID
3. Der Abruf von als Lungeninfektion codierte Diagnosen lautet: {{FHIRbaseUrl}}/Condition?code=128601007
4.  Oder allgemeiner: Subjekt - Prädikat - Objekt
5.  SNOMED bildet aktuell über 100 Konzepte für Attributbeziehungen ab.
6. Ein möglicher ECL-Ausdruck für alle viralen Lungeninfektionen lautet <<128601007:<<246075003=<<49872002, wobei der „<<“- Operator hierarchische Beziehungen berücksichtigt, und nach dem „:“ Operator die Angabe von Bedingungen – wie Attributbeziehungen – folgt. Alternative Abfragen (z. B. nach Infektionen mit der zusätzlichen Attributbeziehung [finding site] = [lung structure]) sind möglich.
7. Ein expliziter Code wird auch als prekoordiniert, ein impliziter Code als postkoordiniert bezeichnet.
8. Eine virale Lungeninfektion kann – neben anderen Möglichkeiten – durch den zusammengesetzten SNOMED-Ausdruck 128601007:246075003=49872002 implizit codiert werden. Ein Alternative ist die Codierung als Infektion mit den Attribut-Beziehungen „finding Site“ in der Lunge und Viren als „causative agent“: 40733004:246075003=49872002,363698007=39607008. Die Angabe weitere Attributbeziehungen ist möglich.
9. Dadurch wird versucht, die in der Postkoordination verwendeten Konzepte durch definierende Beziehungen abzubilden.
10. Ein zusammengesetzter SNOMED-Ausdruck dafür lautet: 128601007:246075003=84101006.
11. Gerade bei der Postkoordinierung ist die Berücksichtigung des Kontexts der FHIR-Ressource zentral, z. B. bietet die  Condition-Ressource das Attribut bodySite an (um z. B. die Lunge anzugeben). Jedoch sollte gerade ein Diagnose-Code für sich stehen können. Die Aufteilung der Datenrepräsentation zwischen Informationsmodell (FHIR) und Terminologie (SNOMED) ist eine fortwährende Frage, die im Zuge von (nationalen) Standardisierungsmaßnahmen zu klären ist.
12. Z. B. um die Hierarchie- bzw. Attributbeziehungen eines impliziten Codes abzufragen, die Äquivalenz von Ausdrücken zu prüfen oder einen Code gegen ein (intensionales) Valueset zu validieren. Alternativ kann der FHIR-Server all von ihm gehaltenen impliziten Codes bei einem Terminologieserver mit dem impliziten Valueset der aktuellen Anfrage klassifizieren.
13. Das ist erst mal eine Vereinfachung, da Doppelung von Diagnosen – z. B. über ihre Datierung – geprüft werden müssen.
14. elektronische Patientenakte nach § 341, Medizinische Informationsobjekte, Medizininformatik-Initiative, Informationstechnische Systeme im Krankenhaus

Dr. Samer Schaat
ist medizinischer Informatiker und war an der MedUni Wien im Bereich der Interoperabilität von Forschungsdaten tätig. Nach Grundlagenforschung und angewandter Forschungen im Bereich der Künstlichen Intelligenz an der TU Wien entwickelte er am DZNE Rostock sensorbasierte Assistenzsysteme für Menschen mit Demenz. Nach Tätigkeiten in der mio42 GmbH ist er seit März 2022 in der gematik GmbH als IT-Architekt Forschung & Entwicklung tätig.
Kontakt: samer.schaat(at)gematik.de