Terminologien und Codes — wer lizenziert was, und wogegen ist ein Code wahr

Ein Feld zu mappen ist die halbe Arbeit; die andere Hälfte ist, den Wert in ein Kodiersystem zu bringen, das der Empfänger kennt. Dieser Eintrag sortiert die Systeme, die im ISiK-Umfeld vorkommen, und ihre Lizenzlage.

Die Systeme im Überblick

System	Wofür	Herausgeber / Pflege	Lizenz
SNOMED CT	klinische Begriffe, sehr breit	SNOMED International; DE: BfArM als nationales Kompetenzzentrum, NRC im Aufbau	in DE kostenfrei, siehe unten
LOINC	Laborwerte, Messungen, Dokumenttypen	Regenstrief Institute	kostenfrei nach Registrierung
ICD-10-GM	Diagnosen (Abrechnung)	BfArM, Jahresversionen	kostenfrei
OPS	Prozeduren/Operationen	BfArM, Jahresversionen	kostenfrei
Alpha-ID	Verschlüsselung freier Diagnosetexte auf ICD	BfArM	kostenfrei
UCUM	Maßeinheiten	Regenstrief	kostenfrei
KDL	klinische Dokumentenklassen (in ISiK-Dokumentenaustausch)	DVMD	im ISiK-Paketbaum enthalten (FHIR-Paket dvmd.kdl.r4, Jahresfassung)
§ 301-Schlüssel	Fachabteilungen, Entlassgründe u. a.	Vereinbarung nach § 301 SGB V	kostenfrei

Die deutschen Basisprofile (de.basisprofil.r4) und hl7.terminology bringen die FHIR-seitigen CodeSystem-/ValueSet-Definitionen mit; ohne sie im Paketbaum kennt ein Validator die deutschen ValueSets nicht. [Fakt]

SNOMED CT: lizenzpflichtig, aber in Deutschland kostenfrei

Das ist die Präzisierung, die dieser Eintrag vor allem trägt — die beiden Wörter werden oft verwechselt.

• Deutschland ist Mitglied bei SNOMED International und trägt die Mitgliedsgebühr. Eine Affiliate-Lizenz ist deshalb im Inland kostenfrei zu beziehen. [Fakt, BfArM, 28.07.2026]
• Beantragung über das MLDS-Portal (mlds.ihtsdotools.org) — es dient zugleich als Download-Center. Erforderlich sind Kontakt-/Organisationsdaten und eine jährliche Nutzungserklärung.
• Unterschieden werden Affiliates (Organisationen, die Software dauerhaft betreiben — auch Softwarehersteller) und Endnutzer (Kliniken, Praxen, Apotheken, Forschung, Einzelpersonen). Affiliates verwalten Sublizenzen für ihre Endnutzer; diese brauchen dann keine eigene Lizenz.
• Innerhalb Deutschlands keine kommerzielle Einschränkung. Nutzung in Nicht-Mitgliedsländern braucht eine gesonderte Freigabe über MLDS, und dort werden Gebühren fällig.
• Die erste deutsche Übersetzung erschien am 17.11.2023, Aktualisierung halbjährlich.

Was das für SNOMED-Warnungen im Validator heißt

Es kursiert die Faustregel „SNOMED-Warnungen ignorieren, die Terminologie ist lizenzpflichtig”. Nach dem oben Gesagten ist diese Begründung falsch — in Deutschland ist sie es nicht. Die Praxis kann trotzdem vertretbar sein, nur aus einem anderen Grund:

• Belegt: SNOMED steht nicht im ISiK-Paketbaum. Eine typische Validierungsumgebung lädt de.basisprofil.r4, hl7.terminology.r4, ihe.formatcode.fhir, ihe.iti.balp, ihe.iti.mhd, de.ihe-d.terminology, dvmd.kdl.r4 und die ISiK-Module — kein SNOMED. Wo eine Terminologie gar nicht geladen ist, entstehen aus ihr auch keine Warnungen. [Fakt]
• Nicht belegt: dass eine künftige SNOMED-Warnung dieselbe Ursache hätte wie die bekannten Expansionsprobleme bei KDL, IHE-formatCode und practiceSetting. Die Analogie liegt nahe, ist aber eine andere Fehlerklasse. [Hypothese]

Die praktische Konsequenz: Sobald SNOMED-Codings auftreten (z. B. bei Encounter-/ServiceType-Kodierungen), ist das Nachladen der Terminologie ein eigener Aufwand. Aber die Ursache wäre dann erst zu diagnostizieren, nicht vorauszusetzen — mit der Gegenprobe aus Konformität und Validatoren: die offizielle Beispielinstanz durch denselben Validator schicken.

Warum das hier so ausführlich steht: Die verbreitete Begründung klingt zwingend und ist falsch. Sie durch eine zweite Erzählung zu ersetzen, die ebenso plausibel klingt und ebenso wenig geprüft ist, wäre derselbe Fehler eine Runde später — siehe Default-Deny-Grenze: „Ein Mechanismus, den man sich überzeugend erzählen kann, ist damit noch nicht ausgeführt worden.”

Bindungsstärken — warum manche Codes wehtun und andere nicht

FHIR bindet ein Element an ein ValueSet mit einer Stärke, und die entscheidet, ob ein fremder Code ein Fehler ist:

Stärke	Bedeutung	Fremder Code
required	genau aus diesem VS	Fehler
extensible	aus dem VS, außer es passt nachweislich nichts	erlaubt, wenn begründet
preferred	empfohlen	Hinweis
example	nur Illustration	egal

Wer eine Validator-Meldung liest, ohne die Bindungsstärke zu prüfen, hält Hinweise für Blocker — und Blocker für Geschmacksfragen. [Fakt]

Die Lehre, die in keinem Standard steht

Ein Code ist nur gegen eine konkrete Paketversion wahr.

Belegt an einem eigenen Testfall: Der Identifier-Typcode für die KVNR wurde in der aktuellen ISiK-Doku auf KVZ10 geändert — $validate gegen eine Instanz mit de.basisprofil.r4 1.4.0 weist ihn trotzdem zurück, weil diese Paketversion KVZ10 nicht kennt. Wer gegen sie prüft, bleibt bei GKV. [Fakt]

Praktische Regel: In eine Mapping-Spezifikation gehört nie nur der Code, sondern immer das Tripel System-URL + Code + Paketversion, gegen die geprüft wurde. Ohne die dritte Angabe ist die Aussage nicht nachvollziehbar und beim nächsten Paket-Update still falsch.

Zweiter Fall derselben Klasse: Ein Code kann korrekt und die Validierung trotzdem rot sein, wenn das ValueSet nicht expandierbar ist. Siehe Konformität und Validatoren.

Zwei KVNR — der Klassiker

Es gibt zwei Versichertennummern, und sie gehören an verschiedene Ressourcen:

• 10-stellig (OID 1.2.276.0.76.4.8, Form: 1 Buchstabe + 9 Ziffern) — die Personen-Kennung, gehört an Patient.identifier.
• 30-stellig (OID 1.2.276.0.76.4.1) — enthält das Kassen-IK, ändert sich beim Kassenwechsel, gehört an Coverage.identifier.

Und: die deutsche HL7-Tabelle 0203 kennt kein NI — die KVNR gehört nach IN1-49, nicht nach PID-3. Reale Sender liefern sie trotzdem dort. Ein Mapper sollte das tolerieren — aber mit Warnung, nie stillschweigend. [Fakt]

Ausblick: Terminologieserver

FHIR-basierte Terminologieserver ($expand, $validate-code, $translate als Dienst statt als lokale Paketdatei) gewinnen an Bedeutung; die gematik/INA hat dazu ein Positionspapier veröffentlicht. Für eine lokale Testinstallation nicht relevant — für den produktiven Betrieb die Antwort auf genau diese Expansionsprobleme. [Hypothese — Richtung belegt, Zeitpunkt und Verbindlichkeit nicht]

• Quelle / Datum: BfArM: SNOMED-CT-Lizenz und BfArM: Terminologien, abgerufen 28.07.2026; INA: Positionspapier Terminologieservices
• Sicherheit der Aussage: [x] Fakt (Lizenzlage, Bindungsstärken, KVNR-Aufteilung, Paketversions-Befund) [x] Hypothese (Ursache künftiger SNOMED-Warnungen, Terminologieserver-Ausblick) [ ] Spekulation