Einführung in FHIR Terminology: Die Grundlagen

Dies ist der zweite Beitrag der Einführung in FHIR Terminology-Reihe. Wir gehen auf die Kernkonzepte ein, aus denen das FHIR Terminology Module besteht. Wir sehen konkrete Beispiele dafür, welche Probleme es lösen kann, und geben einen Überblick darüber, wie die verschiedenen Teile zusammenpassen.

Anwendungsfälle

Wie wir bereits erwähnt haben, beobachten wir, dass FHIR-Einsteiger die Terminology-Lösungen häufig zu wenig nutzen. Wir glauben, dass dies zum Teil auf mangelndes Bewusstsein dafür zurückzuführen ist, welche Probleme damit gelöst werden können. Manche Menschen verbinden Terminology mit Themen wie Standards, Konformität, Compliance und Regulierung. Deshalb ist ein guter Ausgangspunkt, einige konkrete Anwendungsfälle zu zeigen, die sich mit einem Terminology-Server leicht umsetzen lassen. Tatsächlich laufen alle diese Beispiele live gegen unsere Sandbox-Instanz.

Jeder Tab zeigt ein Live-Beispiel – von Suchfeldern und Dropdowns bis hin zu Mapping und Übersetzung. Öffnen Sie den Bereich am unteren Rand des Felds, um die tatsächlichen Anfragen und Antworten einzusehen¹.

Hintergrund

Wenn ein Arzt „Herzinfarkt" schreibt und ein anderer „Myokardinfarkt", meinen beide dasselbe. Für ein Softwaresystem oder jeden skalierbaren Arbeitsablauf sind dies jedoch nur zwei verschiedene Zeichenketten. Die Fähigkeit, Bedeutung zwischen Parteien auszutauschen, ist für die Interoperabilität von zentraler Bedeutung. Dafür sind medizinische Terminologien da. Eines der frühesten Beispiele für eine medizinische Terminologie ist die Internationale Klassifikation der Krankheiten (ICD), die 1893 zur Kodierung von Todesursachen eingeführt wurde. Sie ist älter als Software und wird noch heute verwendet.

Wir arbeiten mit einer Reihe von Konstrukten, die unter die Definition von Terminologie fallen: Taxonomien, Ontologien, Nomenklaturen, Code-Mengen, Vokabulare, Klassifikationen. Für praktische Zwecke nennen wir sie Terminologien und definieren sie als eine Menge von Begriffen mit einem stabilen, maschinenlesbaren Bezeichner. Sie können unendlich sein, Synonyme, Eigenschaften, Beziehungen und Strukturen besitzen usw. Die wichtigste Eigenschaft, die wir benötigen, ist jedoch, dass jedes Element einen stabilen Bezeichner (Code) und eine textuelle Bezeichnung (Begriff/Anzeigename) hat.

In der „normalen" Webentwicklung verwenden Entwickler ständig Terminologien (auch wenn sie nicht so genannt werden). Sie werden häufig als Enums oder als Tabellen von Einträgen mit einer CRUD-Administrationsansicht implementiert (es ist sehr üblich, dass Enums ihre eigenen Codes sind und dass Eintrags-Tabellen die Datenbank-ID als Bezeichner verwenden). Die obigen Beispiele hätten sehr gut mit diesen Mustern implementiert werden können.

FHIR bietet ein Terminology Module, das zur Lösung dieser und anderer Probleme entwickelt wurde. Ein interessanter Aspekt ist, dass dieselben Abstraktionen in der Lage sind, sowohl standardisierte, konforme und autoritative große Ontologien als auch enum-ähnliche, kurze, lokale Code-Listen auszudrücken.

Codierte Werte

Viele FHIR-Ressourcen haben Felder, deren mögliche Werte aus einer Liste (einer Terminologie) stammen. Ihre Werte sind Codes, die anderswo vergeben wurden und ein definiertes Konzept identifizieren. Zum Beispiel:

resourceType: Patient
name:
  - given: [Jane]
    family: Doe
gender: female

Beachten Sie, dass name in diesem Fall eine ungebundene Eigenschaft ist: Sie kann jeden beliebigen menschlichen Namen annehmen, während gender nur einen von vier Werten annehmen kann: male, female, other, unknown. In diesem Fall ist female ein codierter Wert.

Ein codierter Wert besteht hauptsächlich aus einem Paar von „system" und „code", wobei system eine URL² ist, die das Code-System (die Terminologie) identifiziert, das die Codes definiert. Diese Entscheidung hat erhebliche Auswirkungen darauf, wie auffindbar codierte Werte sind: Anstatt eine Zeichenkette zu finden, die zufällig wie ein LOINC-Code aussieht, werden codierte Werte zusammen mit ihrem Code-System-Bezeichner geliefert. Im obigen Fall des Geschlechts ist das System implizit (Administrative Gender, http://hl7.org/fhir/administrative-gender); warum, werden wir gleich erläutern.

FHIR definiert 3 Haupt-Datentypen zur Darstellung dieser Codes³: code, Coding und CodeableConcept.

• code: Die Instanz repräsentiert nur den Code. Das System ist implizit.
• Coding: Der Datentyp enthält einen Code und ein System, das angibt, woher die Definition des Codes stammt.
• CodeableConcept: Ein Typ, der ein Konzept durch Freitext und/oder ein oder mehrere coding-Elemente repräsentiert.

Die meisten codierten Elemente in FHIR verwenden CodeableConcept, da es die größte Flexibilität bietet. Es erlaubt mehrere Codierungen und ermöglicht Freitext, um beispielsweise darzustellen, was ein Dateneingeber tatsächlich eingegeben hat, oder Fälle, in denen kein Code verfügbar ist. Es erleichtert auch Übergänge, da man alte und neue Codes in derselben Struktur einschließen kann (siehe Observation-Beispiel unten).

Der Coding-Datentyp wird verwendet, wenn die Absicht darin besteht, auf einen bestimmten Code zu verweisen, nicht ein Konzept allgemein auszudrücken. Die Verwendung von Coding ist selten, da es weniger flexibel als CodeableConcept ist und keinen Freitext oder Übersetzungen erlaubt.

Der code-Datentyp erscheint in der Regel in enum-ähnlichen Szenarien. Typischerweise haben diese Elemente eine Bindungsstärke von required, d. h.: Dieser Code muss aus dem angegebenen Value Set stammen, und es besteht keine Notwendigkeit, einen alternativen Code anzugeben. Solche Elemente sind häufig in Geschäftslogik involviert, wie z. B. das Verzweigen anhand eines Werts, exakte Vergleiche usw. Zum Beispiel: ein Ressourcenstatus – Client-Code könnte retired-Ressourcen ignorieren oder nur auf active-Ressourcen reagieren.

Bindung

Bei den zuvor genannten Datentypen sind die Codes vom Typ string. Die Möglichkeit, den Wertebereich einzuschränken, bieten Bindungen. Die Spezifikation bindet das Element an ein Value Set, d. h. es kann nur Werte aus dieser Liste annehmen.

Bindungen haben zwei Haupteigenschaften: valueSet und strength. valueSet definiert, welche Codes für dieses Element gültig sind. strength gibt an, wie die Bindung zu verstehen ist: required, extensible, preferred, example.

Im obigen Beispiel ist Patient.gender an das Value Set Administrative Gender mit der Stärke required gebunden; daher kann gender nur sein: male, female, other, unknown. Und maritalStatus ist an Marital Status Codes mit der Stärke extensible gebunden, was bedeutet: Die Codes sollten aus diesem Value Set stammen, es sei denn, der erwartete Code ist dort nicht enthalten.

Beispiele für codierte Werte

resourceType: Patient
name:
  - given: [Jane]
    family: Doe
gender: female # code / AdministrativeGender (implicit)
maritalStatus: # CodeableConcept
  text: Married
  coding:
    - system: http://terminology.hl7.org/CodeSystem/v3-MaritalStatus
      code: M
      display: Married

resourceType: Location
name : South Wing Neuro OR 1
status: suspended # code / LocationStatus (implicit)
operationalStatus: # Coding
  system: http://terminology.hl7.org/CodeSystem/v2-0116
  code: H
  display: Housekeeping
type: # CodeableConcept
  coding:
    - system: http://terminology.hl7.org/CodeSystem/v3-RoleCode
      code: RNEU
      display: Neuroradiology unit
form: # CodeableConcept without codings
  text: Room

resourceType: Observation
status: final # code / ObservationStatus (implicit)
code: # CodeableConcept with local and standard codings
 coding:
   - system: http://acmelabs.org
     code: 104177
     display: "Blood culture"
   - system: http://loinc.org
     code: 600-7
     display: Bacteria identified in Blood by Culture
valueCodeableConcept: # CodeableConcept
  coding:
    - system: http://snomed.info/sct
      code: 3092008
      display: Staphylococcus aureus
interpretation:
  text: Positive
  coding:
    - system: http://terminology.hl7.org/CodeSystem/v3-ObservationInterpretation
      code: POS

Ressourcen

Wir werfen nun einen kurzen Blick auf die FHIR-Ressourcen, die zum Terminology Module gehören. In der Praxis erstellt man diese selten direkt. Sie werden in der Regel an anderer Stelle gepflegt und in einen Terminology-Server geladen⁴ (oder aus einem solchen exportiert).

Das Terminology Module definiert vier Haupt-Terminology-Ressourcen: CodeSystem, ValueSet, ConceptMap und NamingSystem. Jeder dieser Ressourcen werden wir einen eigenen Beitrag widmen. Für jetzt geben wir einen kurzen Überblick über CodeSystem und ValueSet.

CodeSystem

CodeSystem ist wohl die wichtigste Ressource in FHIR Terminology. Sie wird verwendet, um ein Code-System, seine Attribute und Inhalte zu beschreiben. In seiner häufigsten Form enthält es eine Liste von Konzepten, wobei jedes Konzept seinen Code, Bezeichnungen und Eigenschaften hat.

Beispiele

resourceType: CodeSystem
url: http://hl7.org/fhir/administrative-gender
version: 5.0.0
content: complete
status: active
concept:
  - code: male
    display: Male
  - code: female
    display: Female
  - code: other
    display: Other
  - code: unknown
    display: Unknown

resourceType: CodeSystem
content: supplement
supplements: http://hl7.org/fhir/administrative-gender
concept:
- code: male
  designation:
  - language: es
    value: Masculino
- code: female
  designation:
  - language: es
    value: Femenino
- code: other
  designation:
  - language: es
    value: Otro
- code: unknown
  designation:
  - language: es
    value: Desconocido

resourceType: CodeSystem
url: http://www.nlm.nih.gov/research/umls/rxnorm
version: '03022026'
publisher: National Library of Medicine
content: complete
filter:
- code: concept
  operator: [is-a, generalizes, descendent-of]
  value: comma-separated list of concept codes for direct equality testing
- code: NDC
  operator: [=,in, exists]
  value: NDC code
property:
- {code: TTY, type: string}
- {code: NDC, type: string}
- {code: RXN_STRENGTH, type: string}
- {code: dose_form_of, type: code}
- {code: has_ingredient, type: code}
- {code: has_tradename, type: code}
# ...
concept:
- code: '5640'
  display: ibuprofen
  property:
  - code: TTY
    valueString: IN
  - code: has_tradename
    valueCode: '1100067'
  - code: ingredient_of
    valueCode: '1152223'
  - code: part_of
    valueCode: '821036'
  # ...
# ...

resourceType: CodeSystem
url: http://hl7.org/fhir/sid/icd-10-cm
version: '2025'
content: complete
property:
- description: Indicator [...] transactions ("billable code")
  type: integer
  code: valid
filter:
- description: Identify valid billable codes.
  value: 0 = "header" – not valid [...]
  code: valid
  operator: ["="]
valueSet: http://hl7.org/fhir/sid/icd-10-cm/vs
concept:
- code: Chapter-1
  display: Certain infectious and parasitic diseases (A00-B99)
  concept:
  - code: Section-A00-A09
    display: Intestinal infectious diseases (A00-A09)
    concept:
    - code: A00
      display: Cholera
      concept:
      - code: A00.0
        display: Cholera due to Vibrio cholerae 01, biovar cholerae
        property:
        - code: valid
          valueInteger: 1
# ...

ValueSet

Eine ValueSet-Ressource gibt eine Menge von Codes an, die aus einem oder mehreren Code-Systemen entnommen wurden.

Unserer Erfahrung nach ist dies eine der am häufigsten missverstandenen Ressourcen in FHIR Terminology. Ein möglicher Grund ist, dass der Unterschied zwischen Code-Systemen und Value Sets für Entwickler nicht immer klar ist. Es hilft nicht, dass im FHIR-Kern die meisten CodeSystem-Ressourcen ein äquivalentes ValueSet haben, das alle ihre Codes enthält. Zum Beispiel: http://hl7.org/fhir/administrative-gender und http://hl7.org/fhir/ValueSet/administrative-gender.

Der wesentliche Unterschied besteht darin, dass Code-Systeme die Definition der Konzepte und deren Herkunft enthalten, während Value Sets Codes aus den Code-Systemen auswählen. Ein Value Set kann daher eine Teilmenge eines Code-Systems enthalten oder sogar mehrere mischen.

RxNorm beispielsweise ist eine Medikamenten-Terminologie, die Konzepte für Markennamen, Wirkstoffe, Darreichungsformen usw. enthält. Wir können ein Value Set der Wirkstoffe in RxNorm definieren. Die enthaltenen Konzepte wären weiterhin RxNorm-Konzepte, aber wir würden nur Wirkstoffe einschließen.

Ein weiterer häufiger Anwendungsfall für Value Sets ist das Hinzufügen einer Null-Option. Angenommen, wir verwenden ISO 3166 (Ländercodes) in einem Formular. Es zeigt korrekt jedes Land und seine Codes an, aber es gibt keinen „Unbekannt"-Ländercode. Wir können ein Value Set definieren, das alle Codes aus ISO 3166 einschließt sowie das Konzept UNK aus NullFlavor.

Beispiele

resourceType: ValueSet
url: http://example.org/rxnorm-ingredients
title: RxNorm Ingredients
compose:
  include:
  - system: http://www.nlm.nih.gov/research/umls/rxnorm
    filter:
    - property: TTY
      op: =
      value: IN

resourceType: ValueSet
url: http://hl7.org/fhir/ValueSet/example
title: LOINC Codes for Cholesterol in Serum/Plasma
compose:
  include:
  - system: http://loinc.org
    concept:
    - code: 14647-2
      display: Cholesterol [Moles/Volume]
    - code: 2093-3
      display: Cholesterol [Mass/Volume]
    - code: 35200-5
      display: Cholesterol [Mass Or Moles/Volume]
    - code: 9342-7
      display: Cholesterol [Percentile]

resourceType: ValueSet
url: http://hl7.org/fhir/ValueSet/administrative-gender
status: active
compose:
  include:
  - system: http://hl7.org/fhir/administrative-gender

resourceType: ValueSet
url: http://hl7.org/fhir/ValueSet/yesnodontknow
name: YesNoDontKnow
compose:
  include:
  - valueSet: ["http://terminology.hl7.org/ValueSet/v2-0136"]
  - system: http://terminology.hl7.org/CodeSystem/data-absent-reason
    concept:
    - code: asked-unknown
      display: Don't know

Operationen

Der Hauptweg zur Interaktion mit dem Terminology Module und seinen Ressourcen sind Operationen. Die R6-Spezifikation definiert 8 terminology-spezifische Operationen. Im Verlauf dieser Reihe werden wir die meisten davon im Detail betrachten. In diesem Beitrag stellen wir $expand vor, die Operation, die die meisten unserer obigen Beispiele antreibt.

ValueSet/$expand

Gibt bei einem Value Set die Liste der darin definierten Codes zurück. Diese Operation eignet sich ideal zur Befüllung von UI-Elementen: Dropdowns, Suchfelder, Code-Auswahlelemente usw. Neben dem Value Set können Sie einen Textsuchfilter, Paginierung, zurückzugebende Eigenschaften und Bezeichnungen, die zurückzugebende Sprache und weitere Parameter angeben.

Nehmen wir unser erstes Beispiel: ein Typeahead-Suchfeld für klinische Befunde aus SNOMED. Angenommen, wir möchten nach „diabetes mellitus" suchen und 10 Ergebnisse erhalten. So könnte eine Anfrage aussehen:

GET https://tx-sandbox.health-samurai.io/fhir/ValueSet/$expand
[Query]
url: http://snomed.info/sct?fhir_vs=isa/404684003
count: 10
filter: diabetes mellitus

curl -G 'https://tx-sandbox.health-samurai.io/fhir/ValueSet/$expand' \
  --data-urlencode 'url=http://snomed.info/sct?fhir_vs=isa/404684003' \
  --data-urlencode 'count=10' \
  --data-urlencode 'filter=diabetes mellitus'

Wir können auch ein Value Set direkt in der Anfrage angeben. Dies erlaubt uns, Abfragen auf ein Code-System über Eigenschaften zu formulieren. Angenommen, wir möchten alle Markenmedikamente abrufen, die sowohl Koffein als auch Paracetamol als Wirkstoffe enthalten.

POST https://tx-sandbox.health-samurai.io/fhir/ValueSet/$expand
Content-Type: application/json
{
  "resourceType": "Parameters",
  "parameter": [
    {
      "name": "valueSet",
      "resource": {
        "resourceType": "ValueSet",
        "status": "active",
        "compose": {
          "include": [
            {
              "system": "http://www.nlm.nih.gov/research/umls/rxnorm",
              "filter": [
                { "property": "TTY", "op": "=", "value": "BN" },
                { "property": "tradename_of", "op": "=", "value": "CUI:161" },
                { "property": "tradename_of", "op": "=", "value": "CUI:1886" }
              ]
            }
          ]
        }
      }
    }
  ]
}

curl -X POST 'https://tx-sandbox.health-samurai.io/fhir/ValueSet/$expand' \
  -H 'Content-Type: application/json' \
  -d '{
    "resourceType": "Parameters",
    "parameter": [
      {
        "name": "valueSet",
        "resource": {
          "resourceType": "ValueSet",
          "status": "active",
          "compose": {
            "include": [
              {
                "system": "http://www.nlm.nih.gov/research/umls/rxnorm",
                "filter": [
                  { "property": "TTY", "op": "=", "value": "BN" },
                  { "property": "tradename_of", "op": "=", "value": "CUI:161" },
                  { "property": "tradename_of", "op": "=", "value": "CUI:1886" }
                ]
              }
            ]
          }
        }
      }
    ]
  }'

Weiter

In unserem nächsten Beitrag befassen wir uns mit Canonicals: Wie Terminology-Ressourcen identifiziert werden, welche Konventionen verwendet werden und wie Versionierung und Auflösung funktionieren.

• Vorheriger Beitrag: Einführung in FHIR Terminology
• Nächster Beitrag: Canonicals – demnächst verfügbar