---
{
"title": "Einführung in FHIR Terminology: Die Grundlagen",
"description": "Der zweite Beitrag einer Reihe über FHIR Terminology: kodierte Werte, Code-Systeme, Value Sets und Concept Maps",
"date": "2026-08-17",
"author": "Orlando Osorio",
"tags": ["Terminology", "FHIR", "Tutorial"],
"extra-scripts": [
"/assets/js/demo/termbox/base.js",
"/assets/js/demo/termbox/basics.js"
]
}
---
> For the complete documentation index, see [llms.txt](https://www.health-samurai.io/llms.txt).
> Use it to discover all available pages before guessing URLs.
---
Dies ist der zweite Beitrag der [Einführungsreihe zu FHIR Terminology](/blog/introduction-to-fhir-terminology). Wir behandeln die Kernkonzepte des FHIR Terminology-Moduls, zeigen konkrete Beispiele der lösbaren Probleme und geben einen Überblick darüber, wie die einzelnen Bestandteile zusammenwirken.
## Anwendungsfälle
Wie [bereits erwähnt](/blog/introduction-to-fhir-terminology#why), beobachten wir, dass FHIR-Einsteiger die Terminology-Lösungen oft zu wenig nutzen. Wir glauben, dass dies zum Teil auf mangelndes Bewusstsein für die lösbaren Probleme zurückzuführen ist – manche Personen verbinden _Terminology_ mit Themen wie Standards, Konformität, Compliance und Regulierung. Daher beginnen wir am besten mit einigen konkreten Anwendungsfällen, die sich mithilfe eines Terminology-Servers einfach umsetzen lassen. Alle folgenden Beispiele laufen live gegen unsere Sandbox-Instanz.
Jede Registerkarte zeigt ein Live-Beispiel – von Suchfeldern und Dropdown-Menüs bis hin zu Mapping und Übersetzung. Öffnen Sie die Schublade am unteren Rand des Feldes, um die tatsächlichen Anfragen und Antworten einzusehen[^1].
## Hintergrund
Wenn eine Ärztin „Herzinfarkt" schreibt und ein anderer Arzt „Myokardinfarkt", meinen beide dasselbe. Für ein Softwaresystem oder jeden Arbeitsablauf in größerem Maßstab sind dies jedoch lediglich zwei verschiedene Zeichenketten. Die Fähigkeit, Bedeutung zwischen verschiedenen Parteien auszutauschen, ist für die Interoperabilität unerlässlich. Genau dafür sind medizinische Terminologien da. Eines der frühesten Beispiele ist die Internationale Klassifikation der Krankheiten (ICD), die 1893 zur Kodierung von Todesursachen eingeführt wurde. Sie entstand vor der Softwareentwicklung und wird bis heute verwendet.
Wir arbeiten mit einer Reihe von Konstrukten, die unter die Definition von _Terminologie_ fallen: Taxonomien, Ontologien, Nomenklaturen, Code-Sets, Vokabulare, Klassifikationen. Der Einfachheit halber nennen wir sie _Terminologien_ und definieren sie als eine Menge von Begriffen mit einem stabilen, maschinenlesbaren Bezeichner. Sie können unendlich groß sein, Synonyme, Eigenschaften, Beziehungen und Strukturen aufweisen. Die entscheidende Eigenschaft ist jedoch, dass jedes Element einen stabilen Bezeichner (_Code_) und eine textuelle Bezeichnung (_Begriff_/_Display_) besitzt.
In der „normalen" Webentwicklung verwenden Entwickler ständig Terminologien – auch wenn sie nicht so genannt werden. Sie werden häufig als Enumerationen oder als Tabellen mit Einträgen und einer CRUD-Adminansicht umgesetzt (wobei es üblich ist, dass die Enumerationswerte gleichzeitig die Codes sind und die Eintrags-Tabellen die Datenbank-ID als Bezeichner verwenden). Die obigen Beispiele hätten durchaus mit diesen Mustern umgesetzt werden können.
FHIR stellt ein [Terminology-Modul](https://build.fhir.org/terminology-module.html) bereit, das dafür ausgelegt ist, diese und weitere Probleme zu lösen. Ein interessanter Aspekt ist, dass dieselben Abstraktionen sowohl standardisierte, konforme, autoritative und umfangreiche Ontologien als auch enumerationsartige, kurze, lokale Code-Listen abbilden können.
## Kodierte Werte
Viele FHIR-Ressourcen besitzen Felder, deren Wertebereich einer Liste (einer Terminologie) entnommen ist. Ihre Werte sind _Codes_, die andernorts vergeben wurden und ein definiertes _Konzept_ bezeichnen. Zum Beispiel:
```yaml
resourceType: Patient
name:
- given: [Jane]
family: Doe
gender: female
```
Beachten Sie, dass `name` in diesem Fall eine ungebundene Eigenschaft ist: Sie kann jeden menschlichen Namen annehmen, während `gender` nur einen von vier Werten annehmen kann: `male`, `female`, `other`, `unknown`. In diesem Fall ist `female` ein _kodierter Wert_.
Ein kodierter Wert besteht im Wesentlichen aus einem Paar aus „system" und „code", wobei `system` eine URL[^2] ist, die das Code-System (die Terminologie) identifiziert, das die Codes definiert. Diese Entscheidung hat erhebliche Auswirkungen darauf, wie auffindbar kodierte Werte sind: Anstatt eine Zeichenkette vorzufinden, die zufällig wie ein LOINC-Code aussieht, sind kodierte Werte stets mit ihrem Code-System-Bezeichner versehen. Im obigen Gender-Beispiel ist das System implizit (Administrative Gender, `http://hl7.org/fhir/administrative-gender`); warum das so ist, klären wir in Kürze.
FHIR [definiert](https://build.fhir.org/terminologies.html) 3 wesentliche Datentypen zur Darstellung dieser Codes[^3]: `code`, `Coding` und `CodeableConcept`.
- [`code`](https://build.fhir.org/datatypes.html#code): Die Instanz repräsentiert ausschließlich den Code. Das System ist implizit.
- [`Coding`](https://build.fhir.org/datatypes.html#Coding): Der Datentyp enthält einen Code sowie ein System, das angibt, woher die Definition des Codes stammt.
- [`CodeableConcept`](https://build.fhir.org/datatypes.html#CodeableConcept): Ein Typ, der ein Konzept durch Freitext und/oder ein oder mehrere `coding`-Elemente darstellt.
Die meisten kodierten Elemente in FHIR verwenden `CodeableConcept`, da dieser Typ die größte Flexibilität bietet. Er erlaubt mehrere Codierungen und ermöglicht Freitext, um beispielsweise das tatsächlich Eingegebene oder Fälle ohne verfügbaren Code zu übermitteln. Er erleichtert auch Übergangsphasen, da alte und neue Codes in derselben Struktur enthalten sein können (siehe Observation-Beispiel unten).
Der Datentyp `Coding` wird verwendet, wenn die Absicht darin besteht, auf einen spezifischen Code zu verweisen und kein Konzept allgemein auszudrücken. Der Einsatz von `Coding` ist selten, da er weniger flexibel als `CodeableConcept` ist und weder Freitext noch Übersetzungen erlaubt.
Der Datentyp `code` taucht typischerweise in enumerationsartigen Szenarien auf. Derartige Elemente haben in der Regel eine Bindungsstärke von `required`, das heißt: Der Code muss aus dem angegebenen Value Set stammen, und es besteht keine Notwendigkeit, einen alternativen Code anzugeben. In der Regel sind solche Elemente an Geschäftslogik beteiligt, wie etwa das Verzweigen anhand eines Werts oder exakte Vergleiche. Beispielsweise könnte Client-Code `retired`-Ressourcen ignorieren oder nur auf `active`-Ressourcen reagieren.
### Bindung
Bei den vorherigen Datentypen sind die Codes vom Typ `string`. Die Einschränkung der möglichen Werte erfolgt über [Bindungen](https://build.fhir.org/terminologies.html#binding). Die Spezifikation _bindet_ das Element an ein _Value Set_, das heißt, es darf nur Werte aus dieser Liste annehmen.
Bindungen haben zwei Haupteigenschaften: `valueSet` und `strength`. `valueSet` legt fest, 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 die Werte `male`, `female`, `other` oder `unknown` annehmen. `maritalStatus` ist an `Marital Status Codes` mit der Stärke `extensible` gebunden, das bedeutet: Die Codes sollten aus diesem Value Set stammen, es sei denn, der benötigte Code ist dort nicht vorhanden.
### Beispiele für kodierte Werte
{% tabs %}
{% tab title="Patient" %}
```yaml
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
```
{% endtab %}
{% tab title="Location" %}
```yaml
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
```
{% endtab %}
{% tab title="Observation" %}
```yaml
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
```
{% endtab %}
{% endtabs %}
## Ressourcen
Wir betrachten nun kurz die FHIR-Ressourcen des Terminology-Moduls. In der Praxis erstellt man diese selten direkt. Sie werden in der Regel andernorts gepflegt und in einen Terminology-Server geladen[^4] (oder aus diesem exportiert).
Das Terminology-Modul definiert vier wesentliche Terminology-Ressourcen: [CodeSystem](https://build.fhir.org/codesystem.html), [ValueSet](https://build.fhir.org/valueset.html), [ConceptMap](https://build.fhir.org/conceptmap.html) und [NamingSystem](https://build.fhir.org/namingsystem.html). Jeder dieser Ressourcen widmen wir einen eigenen Beitrag. Hier geben wir zunächst einen kurzen Überblick über `CodeSystem` und `ValueSet`.
### CodeSystem
CodeSystem ist wohl die wichtigste Ressource in FHIR Terminology. Sie dient dazu, ein Code-System, seine Attribute und seinen Inhalt zu beschreiben. In der häufigsten Form enthält sie eine Liste von Konzepten, wobei jedes Konzept seinen Code, Bezeichnungen und Eigenschaften umfasst.
#### Beispiele
{% tabs %}
{% tab title="AdministrativeGender" %}
```yaml
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
```
{% endtab %}
{% tab title="ES Translation" %}
```yaml
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
```
{% endtab %}
{% tab title="RxNorm fragment" %}
```yaml
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'
# ...
# ...
```
{% endtab %}
{% tab title="ICD-10-CM fragment" %}
```yaml
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
# ...
```
{% endtab %}
{% endtabs %}
### ValueSet
Eine ValueSet-Ressource legt eine Menge von Codes fest, die aus einem oder mehreren Code-Systemen entnommen werden.
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 Implementierende nicht immer klar ist. Erschwerend kommt hinzu, dass im FHIR-Kern die meisten CodeSystem-Ressourcen ein äquivalentes ValueSet besitzen, das alle ihre Codes einschließt. Beispielsweise: `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_. Daher kann ein Value Set eine Teilmenge eines Code-Systems umfassen oder sogar aus mehreren Systemen zusammengestellt sein.
RxNorm beispielsweise ist eine Medikamenten-Terminologie, die Konzepte für Handelsnamen, Wirkstoffe, Darreichungsformen und weiteres enthält. Wir können ein Value Set der Wirkstoffe in RxNorm definieren. Die enthaltenen Konzepte wären weiterhin RxNorm-Konzepte, jedoch würden wir nur Wirkstoffe einschließen.
Ein weiterer häufiger Anwendungsfall für Value Sets ist das Hinzufügen einer „Keine Angabe"-Option. Angenommen, wir verwenden ISO 3166 (Ländercodes) in einem Formular. Die Liste zeigt korrekt alle Länder mit ihren Codes an, enthält jedoch keinen Code für „Unbekannt". Wir können ein Value Set definieren, das _alle_ Codes aus ISO 3166 sowie das Konzept `UNK` aus [NullFlavor](http://terminology.hl7.org/CodeSystem/v3-NullFlavor) einschließt.
#### Beispiele
{% tabs %}
{% tab title="RxNorm Ingredients" %}
```yaml
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
```
{% endtab %}
{% tab title="LOINC Cholesterol" %}
```yaml
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]
```
{% endtab %}
{% tab title="AdministrativeGender" %}
```yaml
resourceType: ValueSet
url: http://hl7.org/fhir/ValueSet/administrative-gender
status: active
compose:
include:
- system: http://hl7.org/fhir/administrative-gender
```
{% endtab %}
{% tab title="Yes / No / Dont Know" %}
```yaml
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
```
{% endtab %}
{% endtabs %}
## Operationen
Die wichtigste Art, mit dem Terminology-Modul und seinen Ressourcen zu interagieren, sind Operationen. Die R6-Spezifikation definiert 8 terminologiespezifische Operationen. Im Verlauf dieser Reihe werden wir die meisten davon im Detail betrachten. In diesem Beitrag stellen wir `$expand` vor, die Operation, die den Großteil unserer obigen Beispiele antreibt.
### ValueSet/$expand
Gibt für ein Value Set die Liste der darin definierten Codes zurück. Diese Operation eignet sich ideal für die Befüllung von UI-Elementen: Dropdown-Menüs, Suchfelder, Code-Auswahlen und dergleichen. Neben dem Value Set können weitere Parameter angegeben werden: ein Textsuchfilter, Paginierung, welche Eigenschaften und Bezeichnungen zurückgegeben werden sollen, in welcher Sprache die Antwort erfolgen soll und mehr.
Nehmen wir unser erstes Beispiel: ein Typeahead-Suchfeld für klinische Befunde in SNOMED. Angenommen, wir möchten nach „diabetes mellitus" suchen und 10 Ergebnisse erhalten. Eine Anfrage könnte folgendermaßen aussehen:
{% tabs %}
{% tab title="hurl" %}
```hurl
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
```
{% endtab %}
{% tab title="curl" %}
```bash
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'
```
{% endtab %}
{% endtabs %}
| Parameter | Wert | Erläuterung |
| --- | --- | --- |
| `url` | `http://snomed.info/sct?fhir_vs=isa/404684003` | Implizite URL für klinische Befundskonzepte in SNOMED[^5] |
| `count` | `10` | Anzahl der zurückzugebenden Konzepte |
| `filter` | `diabetes mellitus` | Zu suchender Text |
Es ist auch möglich, ein Value Set direkt in der Anfrage mitzugeben. Dies erlaubt es, Abfragen an ein Code-System über dessen Eigenschaften zu formulieren. Nehmen wir zum Beispiel an, wir möchten alle Markenpräparate ermitteln, die sowohl Koffein als auch Acetaminophen als Wirkstoffe enthalten.
{% tabs %}
{% tab title="hurl" %}
```hurl
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" }
]
}
]
}
}
}
]
}
```
{% endtab %}
{% tab title="curl" %}
```bash
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" }
]
}
]
}
}
}
]
}'
```
{% endtab %}
{% endtabs %}
| Filter | Wert | Erläuterung |
| --- | --- | --- |
| `TTY` | `BN` | Nur Handelsnamen |
| `tradename_of` | `CUI:161` | Enthält Acetaminophen |
| `tradename_of` | `CUI:1886` | Enthält Koffein |
## Ausblick
Im nächsten Beitrag befassen wir uns mit Kanonischen URLs (Canonicals): Wie werden Terminology-Ressourcen identifiziert, welche Konventionen gelten, und wie funktionieren Versionierung und Auflösung?
- Zurück: [Einführung in FHIR Terminology](/articles/introduction-to-fhir-terminology)
- Weiter: Canonicals — _demnächst verfügbar_
[^1]: Die effizienteste Methode zur Umsetzung einiger dieser Beispiele ist die Verwendung von [Batching](https://build.fhir.org/http.html#transaction). Wir halten die Anfragen hier jedoch isoliert, um die Inspektion zu erleichtern.
[^2]: Wie diese URLs funktionieren, vertiefen wir in einem künftigen Beitrag über Canonicals.
[^3]: Die Spezifikation definiert tatsächlich 4 Datentypen (sowie 3 weitere). `CodeableReference` ist jedoch in Bezug auf `CodeableConcept` definiert, und die weiteren sind Sonderfälle. Deshalb konzentrieren wir uns auf die ersten drei. Siehe https://build.fhir.org/terminologies.html.
[^4]: In einem künftigen Beitrag werden wir ein Tutorial zur Einrichtung eines Terminology-Servers für eine Healthcare-Applikation von Grund auf vorstellen.
[^5]: Siehe https://terminology.hl7.org/en/SNOMEDCT.html für die Verwendung von SNOMED mit FHIR Terminology. Einem künftigen Beitrag werden wir SNOMED CT widmen.