|
12 Min. Lesezeit
|

Navigation der FHIR-Terminology-Daten: Erkenntnisse und Herausforderungen

Diesen Artikel zusammenfassen mit:
ChatGPTPerplexityClaudeGrok

Einleitung

Als wir begannen, eine Terminology-Lösung für Aidbox zu entwickeln und die Arbeit am Babylon-Projekt aufnahmen, entschlossen wir uns, den Stand der Terminology-Daten innerhalb der FHIR-Community genauer zu untersuchen. Wir konzentrierten uns auf die FHIR IG Registry, da sie einen umfassenden Datensatz bietet. Auf diese Weise wollten wir die dringendsten Probleme, Herausforderungen und Anwendungsfälle identifizieren, denen wir voraussichtlich begegnen würden. Dieser Artikel stellt unsere Ergebnisse vor, einschließlich allgemeiner Erkenntnisse, Probleme bei der Datenqualität, spezifischer Muster im Datensatz sowie Herausforderungen bei der Implementierung.

Als Datenquelle verwendeten wir den FHIR-Paketserver [1]. Wir luden alle verfügbaren Pakete herunter, extrahierten die Terminology-bezogenen Ressourcen [2] und luden sie in eine Postgres-Datenbank. Zur Visualisierung erstellten wir Grafana-Dashboards, die im Anhang enthalten sind. Diese Analyse wurde am 14. Juni 2024 durchgeführt.

Erkenntnisse

Einige Zahlen

Wir luden 2.357 verschiedene Pakete aus der Registry herunter, die 468 eindeutige Paketnamen und deren Versionen repräsentieren. Wie in Abb. 1 dargestellt (beachten Sie, dass wir eine logarithmische Skala verwenden), war das Paket mit der größten Anzahl an Terminology-Ressourcen mit Abstand us.nlm.vsac, das hauptsächlich aus ValueSets besteht; gefolgt von hl7.terminology.* und hl7.fhir.**. Abb. 1. Top 20 Pakete nach Ressource (log. Skala) * Nach dem Laden der Ressourcen fanden wir 75,8 K CodeSystem-Ressourcen, die 6,36 K eindeutige kanonische URLs umfassen. Daraus konnten wir 15 Millionen individuelle Konzepte extrahieren, von denen 3,89 Millionen eindeutig sind [3]. Darüber hinaus luden wir 454 K ValueSet-Ressourcen, von denen 33,7 K eindeutig sind.

Die meisten Ressourcen haben keinen Herausgebernamen; unter denen, die einen haben, ist HL7 der führende Herausgeber, obwohl die Benennung nicht immer einheitlich ist (siehe Abb. 2). Abb. 2. Top 20 Herausgeber Bei der Analyse der Veröffentlichung neuer Ressourcen im Laufe der Jahre [4] (Abb. 3) fällt auf, dass es im Jahr 2014 einen Anstieg neuer Ressourcen gab, der mit DSTU 1 zusammenfällt. Abb. 3. Ressourcen im Zeitverlauf Ein Blick auf die führenden Herausgeber im Zeitverlauf (Abb. 4) Abb. 4. Anteil der führenden Herausgeber im Zeitverlauf

Probleme bei der Datenqualität

Unsere Analyse der FHIR-Terminology-Daten hat mehrere Probleme bei der Datenqualität aufgedeckt, die die Nutzbarkeit und Zuverlässigkeit dieser Ressourcen beeinträchtigen könnten. Diese Probleme erschweren es Implementierern, Operationen wie Validierung, Lookup, Expansion usw. zuverlässig zu unterstützen. Im Folgenden skizzieren wir einige der wichtigsten Probleme, auf die wir gestoßen sind.

Ungültige Ressourcen

Eine Herausforderung beim Laden der Ressourcen bestand darin, dass die Ressourcen manchmal nicht der FHIR-Basisspezifikation entsprachen, z. B. fehlende Pflichtfelder, ungültige Datentypen und Verletzungen von Einschränkungen. Einige dieser Probleme werden in nachfolgenden Versionen der Pakete behoben, andere sind jedoch auch in den neuesten Versionen noch ungültig. In manchen Fällen machen diese Probleme das vollständige Laden der Daten nahezu unmöglich, da es keine offensichtliche Strategie oder Lösung für den Umgang mit diesen Ressourcen zu geben scheint. In einigen extremen Fällen erhalten wir lediglich eine Liste von Konzepten und nichts weiter; in anderen Fällen, wie z. B. bei den Null-Codes, gibt es einfach keinen Fallback-Wert [5].

Wir haben auch eine weitere Kategorie von Problemen bemerkt. Obwohl diese eine Ressource nicht ungültig machen oder gegen Einschränkungen verstoßen würden, stellen sie aus Implementierungssicht dennoch ein Problem dar. Konkret fanden wir Code-Systeme mit fehlerhaften URLs. Glücklicherweise verbleibt in der neuesten Version der Pakete nur noch eines davon [6].

Duplikate und Konflikte

Manchmal wird exakt dieselbe Ressource in verschiedenen Versionen desselben Pakets veröffentlicht. In anderen Fällen wird die Ressource in ein anderes Paket übertragen, die Version bleibt jedoch dieselbe. Diese Szenarien sollten unproblematisch sein, solange die Ressource unverändert bleibt, was jedoch nicht immer der Fall ist. Insbesondere wenn die Änderungen widersprüchlich sind [7].

Die folgenreichsten Arten von Konflikten treten bei den Konzepten auf, da diese den eigentlichen Inhalt des Code-Systems repräsentieren. Häufig laden wir zwei Konzepte aus demselben logischen Code-System (gleiche url und version), die einen übereinstimmenden code haben, bei denen aber entweder display, definition oder property nicht übereinstimmen.

Eine mögliche Strategie ist es, den neueren Änderungen stets zu vertrauen, was jedoch nicht immer erfolgreich ist. Als Beispiel betrachten wir eng.fhir.profile.dev: Von Version 0.0.4-beta bis 0.0.7-beta wurde eine der Anzeigen wie folgt geändert:

  • Oscuramento del oscuramento
  • Oscuramento del documento

Offensichtlich eine Regression einer Tippfehlerkorrektur.

Es ist häufig anzutreffen, dass in widersprüchlichen Code-Systemen die Konzepte mit abweichenden Eigenschaften keine inhaltlichen Konflikte darstellen, sondern Darstellungskonflikte (d. h., die Semantik bleibt erhalten, die Syntax ändert sich). Einige der häufigsten Fälle sind:

  • Datentypänderung, z. B. valueString zu valueCode.
  • Änderung von Locale/Konfiguration, z. B. valueDateTime: "2009-08-20" zu valueDateTime: "2009-08-20T00:00:00-04:00" Manchmal kann ein CodeSystem zwei Konzepte mit demselben Code haben, was gegen csd-1 verstößt. Dies wäre ein einfacher Datenfehler, wenn es sich lediglich um einen Duplikationsfehler handelte, aber diese Codes könnten semantisch unterschiedliche Konzepte repräsentieren, was das Problem erheblich verschlimmert.

Semantische Konflikte: ISO-3166 (Ländercodes)

Ein Code-System kann Konzepte enthalten, die einen Code teilen, aber im Wesentlichen unterschiedliche Konzepte repräsentieren. Dies ist besonders herausfordernd für die Implementierung, da die semantische Eindeutigkeit der Konzepte eines der Kernaxiome der FHIR-Terminology ist.

Betrachten wir ISO-3166 (urn:iso:std:iso:3166|57): Das CodeSystem, das aus fhir.tx.support.r4 bis Version 0.18.0 geladen wurde, enthielt eine Liste von Konzepten aus ISO-3166, die Alpha-2-, Alpha-3- und numerische Codes als code der Konzepte mischten und eine Eigenschaft canonical mit dem Alpha-2-Code hinzufügten.

Nun gilt: Für einige Länder, die ihren Namen geändert haben (z. B. Burma zu Myanmar, Zaire zur DRK, Jugoslawien zu Serbien und Montenegro usw.), wird der numerische Code beibehalten, nur die Alpha-Codes ändern sich. Somit repräsentieren sie zwei verschiedene Konzepte in ISO-3166, haben aber denselben Code in der FHIR-Ressource.

Noch mehr Zahlen

In diesem Abschnitt untersuchen wir die quantitativen Aspekte des FHIR-Terminology-Datensatzes und betrachten Gesamtzahlen, Verteilungen und Muster.

Code-Systeme

In Abb. 5 ist zu erkennen, dass von den Code-Systemen, die ihre Konzepte explizit auflisten, die meisten der größten Sammlungen geografischer Daten sind. Das größte ist das Postleitzahlverzeichnis von Quebec mit über 200 K Konzepten, gefolgt von einigen Versionen von ICD-10. Abb. 5. Top 20 der größten Code-Systeme In Bezug auf die Popularität ist das am häufigsten referenzierte Code-System wenig überraschend SNOMED. Nach SNOMED folgen andere häufig referenzierte Systeme wie LOINC, ICD-10, ICD-9, RxNorm, DICOM und CPT (siehe Abb. 6). Abb. 6. Meistverwendete Code-Systeme Aus Abb. 7 ist ersichtlich, dass die Mehrheit der Code-Systeme alle ihre Konzepte explizit in der Ressource enthält [8]. Nur 41 sind Ergänzungen; obwohl dies eine sehr nützliche Möglichkeit zur Erweiterung bestehender Konzepte zu sein scheint, wird es nicht sehr weit verbreitet genutzt – die meisten davon sind Übersetzungen [9]. Abb. 7. Aufschlüsselung des Code-System-Inhalts

Value Sets

Bei der Analyse von Value Sets ist deren interessantester Aspekt wohl die compose-Regeln. Wir haben die Value Sets in 5 Hauptkategorien klassifiziert [10]:

  • Extensional: Explizite Aufzählung von Konzepten
  • Intensional (Kopie): Kopie aus einem bestehenden Code-System oder Value Set
  • Intensional (Filter): Algorithmisch definiert auf Basis von Auswahlregeln in einem bestehenden Code-System
  • Gemischt: Mischung der vorherigen Techniken
  • Kein Compose: Das Feld compose ist nicht vorhanden

Interessanterweise werden über 60 % als extensional klassifiziert und nur 10 % nutzen die ValueSet-Filterfunktionen (siehe Abb. 8). Abb. 8. ValueSet-Klassifizierung nach Compose Während die Mehrheit der Value Sets nicht expandiert ist (siehe Abb. 9), erscheinen fast 40 % in ihren Paketen bereits vorexpandiert. Abb. 9. Aufschlüsselung der ValueSet-Expansion

Filteranalyse

FHIR bietet einen leistungsfähigen und erweiterbaren Mechanismus, um Auswahlkriterien zur algorithmischen Definition von Value Sets auf der Grundlage bestehender Code-Systeme zu definieren. Das wichtigste Werkzeug zur Formulierung dieser Regeln sind Filter.

Zu valueset-rules-text und valueset-expression

Obwohl Value Sets auf zwei weitere Arten definiert werden können, wird abseits von Beispielressourcen nur eine davon tatsächlich genutzt.

  • valueset-expression [...] Ein Ausdruck, der eine alternative Definition des Inhalts des Value Sets liefert [11]

  • valueset-rules-text [...] Anweisungen, die nur von einem Menschen befolgt werden könnten. [12]

Dies ist möglicherweise eine gute Nachricht für Implementierer, da die anderen beiden Optionen für die Interoperabilität als herausfordernd erscheinen.

Value Sets können die Menge der Basisfilter verwenden, die für alle Code-Systeme definiert sind, sowie alle zusätzlichen Filter, die in CodeSystem.filter definiert sind. In Abb. 10 ist zu sehen, dass die am häufigsten verwendete Kombination aus filter + op wenig überraschend concept is-a ist, da dies eine einfache Möglichkeit ist, die hierarchische Natur vieler Terminologien zu nutzen. Abb. 10. Property + op nach Verwendung

Populäre Code-Systeme

Wir analysierten auch einige der beliebtesten Code-Systeme, um Erkenntnisse zu Mustern und Anwendungsfällen zu gewinnen. In Abb. 11 ist ein Vergleich der Gesamtzahlen zu sehen; beachten Sie bitte, dass wir eine logarithmische Skala verwenden [13]. Abb. 11. Vergleich der Gesamtzahlen populärer Code-Systeme Für viele dieser Code-Systeme ist es unpraktisch, ihre Konzepte in der Ressourcendefinition explizit aufzulisten, weshalb die meisten einfach not-present angeben und es dem Implementierer überlassen bleibt, eine indizierte Quelle für die Bearbeitung von Anfragen bereitzustellen. In Abb. 12 ist zu sehen, dass die einzigen complete-Code-Systeme ICD-10 und DICOM sind (SNOMED erscheint im Diagramm als complete, ist es aber tatsächlich nicht – es handelt sich um einen Fehler in einigen der CodeSystem-Ressourcen). Abb. 12. Aufschlüsselung des Inhalts populärer Code-Systeme

Filter

Abb. 13 zeigt einen Vergleich der Verwendung benutzerdefinierter Filter gegenüber den vordefinierten FHIR-Basisfiltern, z. B. SNOMEDs ECL. Wir zeigen auch einen Vergleich der Ausdrücke, wobei Orange für die benutzerdefinierten Filter verwendet wird. Es ist festzustellen, dass die große Mehrheit der Ausdrücke die FHIR-Basisfilter nutzt, obwohl einige dieser Systeme eine echte Ontologie mit leistungsfähiger Semantik und – im Fall von SNOMED – eine ausgereifte Abfragesprache bereitstellen. Abb. 13. Filteranalyse populärer Code-Systeme

Tippfehler

Bei der Analyse dieser Code-Systeme stellten wir fest, dass einige Value Sets Tippfehler oder geringfügige Fehler in der Definition der kanonischen URL aufwiesen. Dies kann zu unerwarteten Fehlern bei der Verwendung dieser Value Sets führen. Einige dieser Fehler sind auch in den neuesten Versionen einiger Pakete noch vorhanden.

Einige Beispiele

SNOMED srt

Ursprünglich waren DICOM-Codes im Paket fhir.tx.support aufgeführt. Die dabei verwendete kanonische SNOMED-URL war http://snomed.info/srt (srt statt sct). Als sie in das Paket fhir.dicom verschoben wurden, wurde die URL korrigiert.

Um tiefer in die FHIR-Terminology einzutauchen und deren Möglichkeiten zu testen, können Sie die kostenlose Version von Aidbox installieren. Sie ermöglicht es Ihnen, diese Weiterentwicklungen in einer voll funktionsfähigen Umgebung zu erkunden und damit zu experimentieren – ideal für Entwicklung und Tests.

Anhang

  1. Packages2 und Simplifier sind synchronisiert; gelegentlich verwenden wir Simplifier-URLs, um auf ein Paket zu verlinken, da es eine Oberfläche zur Visualisierung des Paketinhalts bietet.
  2. CodeSystem, ValueSet und ConceptMap
  3. Wir betrachten die Eindeutigkeit eines Konzepts als durch sein System, seinen Code und seine Version gegeben.
  4. Es gibt eine Ressource, die im Jahr 2161 veröffentlicht wurde, was wahrscheinlich ein Tippfehler ist oder vielleicht ein zukünftiges ValueSet darstellt; sie wird von der United Federation of Planets veröffentlicht und enthält die Quadranten der Milchstraße.
  5. In einigen dieser Fälle scheint es, dass Autoren Platzhalterkonzepte zur Gruppierung verwenden und keinen geeigneten Wert als Code für den Gruppenindikator haben.
  6. ValueSet HealthCareProviderTaxonomy aus dem Paket hl7.fhir.us.directory-attestation
  7. Änderungen, die Informationen verlieren, anstatt sie hinzuzufügen.
  8. Dies ist nicht immer der Fall; einige Code-Systeme haben content = complete, enthalten aber keine Konzepte. Siehe Tabelle 1.
  9. Aus den von uns analysierten Fällen scheint es, dass alle davon Übersetzungen in verschiedene Sprachen sind.
  10. Intensional und Extensional stammen aus der regulären FHIR-Definition
  11. https://build.fhir.org/ig/HL7/fhir-extensions/StructureDefinition-valueset-expression.html
  12. https://build.fhir.org/ig/HL7/fhir-extensions/StructureDefinition-valueset-rules-text.html
  13. Um sehr unterschiedliche Zählwerte in einem Diagramm darzustellen, verwenden wir eine log₁₀-Skala. Dies kann Erwartungen in die Irre führen, da die Unterschiede zwischen hohen Werten visuell nicht so ausgeprägt sind wie im Datensatz, insbesondere im Vergleich zu kleineren Gesamtwerten.
Diesen Artikel teilen
Comments
Comments
Sign in
Loading comments...
Subscribe to our blog

Get the latest articles on FHIR, interoperability, and healthcare IT.