---
{
"title": "Einführung in FHIR Terminology: Die Grundlagen",
"description": "Der zweite Beitrag einer Reihe über FHIR Terminology: codierte Werte, Code-Systeme, Value Sets und Concept Maps",
"date": "2026-08-20",
"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ührung in FHIR Terminology-Reihe](/blog/introduction-to-fhir-terminology). 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](/blog/introduction-to-fhir-terminology#why), 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[^1].
## 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](https://build.fhir.org/terminology-module.html), 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:
```yaml
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[^2] 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](https://build.fhir.org/terminologies.html) 3 Haupt-Datentypen zur Darstellung dieser Codes[^3]: `code`, `Coding` und `CodeableConcept`.
- [`code`](https://build.fhir.org/datatypes.html#code): Die Instanz repräsentiert nur den Code. Das System ist implizit.
- [`Coding`](https://build.fhir.org/datatypes.html#Coding): Der Datentyp enthält einen Code und 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 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](https://build.fhir.org/terminologies.html#binding). 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
{% 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 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[^4] (oder aus einem solchen exportiert).
Das Terminology Module definiert vier Haupt-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 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
{% 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 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](http://terminology.hl7.org/CodeSystem/v3-NullFlavor).
#### 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
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:
{% 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 aus SNOMED[^5] |
| `count` | `10` | Anzahl der zu matchenden Konzepte |
| `filter` | `diabetes mellitus` | Zu matchender Text |
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.
{% 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 Markennamen |
| `tradename_of` | `CUI:161` | Enthält Paracetamol |
| `tradename_of` | `CUI:1886` | Enthält Koffein |
## 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](/articles/introduction-to-fhir-terminology)
- Nächster Beitrag: Canonicals – _demnächst verfügbar_
[^1]: Die effizienteste Methode zur Implementierung einiger dieser Beispiele ist die Verwendung von [Batching](https://build.fhir.org/http.html#transaction). Wir halten die Anfragen zur einfacheren Inspektion isoliert.
[^2]: In einem zukünftigen Beitrag über Canonicals werden wir genauer darauf eingehen, wie diese URLs funktionieren.
[^3]: Die Spezifikation definiert tatsächlich 4 Datentypen (und 3 weitere). Da `CodeableReference` jedoch in Bezug auf `CodeableConcept` definiert ist und die weiteren Typen Sonderfälle darstellen, konzentrieren wir uns auf die ersten drei. Siehe https://build.fhir.org/terminologies.html.
[^4]: In einem zukünftigen Beitrag werden wir uns ein Tutorial zur Einrichtung eines Terminology-Servers ansehen, um damit von Grund auf eine Healthcare-Anwendung zu betreiben.
[^5]: Siehe https://terminology.hl7.org/en/SNOMEDCT.html für die Verwendung von SNOMED mit FHIR Terminology. Wir werden SNOMED CT einem eigenen zukünftigen Beitrag widmen.