Der Namensraum im Wert

Konzept: Wenn der Schlüssel etwas erzählt

Ein Identifier hat genau eine Aufgabe: unterscheiden. Sobald sein Wert darüber hinaus etwas erzählt — welches Haus, welcher Mandant, welches Vorsystem, welcher Migrationsstand —, trägt er Information, die kein Empfänger prüfen und kein Standard auflösen kann. Das ist die Zweckentfremdung aus Das Z-Kürzel ist kein Namensraum, eine Ebene tiefer: nicht ein Feld wird umgewidmet, sondern der Wert selbst.

Der Kernsatz:

Ein Präfix im Identifier ist ein Namensraum, der die Feldgrenze nicht respektiert.

Was der Standard über den Wert sagt — und was nicht

CX.1 – ID Number ist in v2.5.1 vom Typ ST, Länge 15, Optionalität R. Die Definition besteht aus einem Satz: „A unique code for distinguishing persons or things.”

Mehr steht dort nicht. Kein Format, keine Struktur, keine Vergaberegel. Der Wert ist eine opake Zeichenkette, und „unique” bedeutet: eindeutig innerhalb des Namensraums aus CX.4 — nicht global.

Eine Spur gibt der Standard trotzdem, und sie wird selten gelesen: Er sieht eine Prüfziffer in CX.2 (ein Zeichen) und ihr Verfahren in CX.3 vor, Tabelle 0061 mit M10, M11, ISO (7064), NPI und BCV. Prüfziffernverfahren rechnen mit Zählern. Der Standard erwartet also fortlaufende Nummern, ohne sie vorzuschreiben. Wichtig dabei: Die Prüfziffer gehört in CX.2, nicht an den Wert. Wer sie anhängt, hat einen anderen Identifier.

Komponente	Länge	Typ	Trägt
CX.1	15	ST	den Wert — opak
CX.2	1	ST	Prüfziffer
CX.3	3	ID (Tab. 0061)	Prüfziffernverfahren
CX.4	227	HD	Herkunft — der Namensraum
CX.5	5	ID (Tab. 0203)	Sorte — Art des Identifiers
CX.7/CX.8	8	DT	Gültigkeit — ab wann, bis wann

In v2.5.1 hat CX zehn Komponenten; die refaktorierte v2+-Fassung führt zwölf (zusätzlich Security Check und Security Check Scheme). Wer eine Nachricht gegen ein Profil einer anderen Version prüft, prüft eine andere Komponentenliste.

Das Fehlerbild

Typische Ausprägungen, alle in der Praxis anzutreffen:

Form	Beispiel	Was das Präfix eigentlich sagt
Standort- oder Mandantenpräfix	N-100045, 2100045	„Namensraum Nord”
Systemkürzel nach Migration	ALT100045	„aus dem abgelösten Vorsystem”
Suffix aus der Dublettenbereinigung	100045-A	„zweite Akte derselben Person”
Typ- oder Jahrespräfix	F-2026-00815	„Fallnummer, Jahrgang 2026”

Die letzte Form ist nicht per se falsch: Solange ein Nummernkreis nur einem Namensraum und einer Sorte gehört, ist ein sprechendes Präfix bloß Kosmetik. Zum Fehlerbild wird es, sobald das Präfix die Unterscheidung trägt, die eigentlich in CX.4 oder CX.5 gehört.

Und genau so entsteht es fast immer: Das Präfix ist der Ersatz für ein CX.4, das nicht gesendet oder nicht gespeichert wird. Jemand musste zwei Nummernkreise auseinanderhalten und hatte kein Feld dafür — also hat er den Wert verlängert.

Warum das anders bricht als ein leeres CX.4

Ein leeres CX.4 ist eine fehlende Angabe: sichtbar, benennbar, nachforderbar. Ein Präfix ist eine verborgene Angabe — vorhanden, aber an einer Stelle, an der niemand sie sucht.

Eigenschaft	Namensraum in CX.4	Namensraum im Wert
gegen eine Liste prüfbar	ja	nein
maschinell abtrennbar	ja (Feldgrenze)	nur mit einer Hausregel
wechselbar ohne Identitätsbruch	ja	nein — der Schlüssel ändert sich mit
für ein Fremdsystem erkennbar	ja	nein
global verankerbar (OID)	ja, über HD.2/HD.3	nein

Die vier Folgeschäden

1. Der Schlüssel ist nicht stabil. Ändert sich die Präfixregel — Fusion, Mandantenumbau, Migration —, ändert sich der Wert. Dieselbe Person, neue Identität. Kein Event meldet das: Es ist kein Merge, kein Update, nur ein anderer String. Ein Namensraum in CX.4 hätte gewechselt werden können, ohne den Schlüssel anzufassen.

2. Zwei Aussagen über dieselbe Sache. Sind CX.4 und ein Präfix gefüllt, steht die Herkunft zweimal in der Nachricht. Solange beide dasselbe sagen, fällt nichts auf. Sobald sie auseinanderlaufen, gibt es kein Feld, das entscheidet, welche gilt — die Nachricht bleibt dabei wohlgeformt und wird mit AA quittiert.

3. Stille Normalisierung. Zielsysteme trimmen, strippen Nicht-Ziffern, casten nach Integer. N-100045 wird zu 100045; führende Nullen verschwinden nach demselben Muster (0012345 → 12345). Aus zwei Namensräumen wird einer, ohne Fehlermeldung und ohne Logeintrag. Das ist der Moment, in dem zwei Personen einen Datensatz teilen.

4. Längenüberlauf. CX.1 endet bei 15 Zeichen. Präfix plus Zähler plus Suffix reißt die Grenze schneller als erwartet. Empfänger kürzen dann gelegentlich rechts — und schneiden damit den unterscheidenden Teil weg, weil das Präfix links steht und stehen bleibt.

Erkennen, bevor man fragt

Vier Indizien, ablesbar aus einem Tagesabzug der Strecke, ohne die Kunden-IT zu bemühen:

• Verteilung der ersten Zeichen. Ein echter Zähler streut über den vorderen Stellen. Ein Präfix erzeugt wenige, scharfe Klumpen.
• Längenverteilung. Ein reiner Zähler hat ein bis zwei Längen. Präfigierte Werte haben mehr, und die Häufungen liegen an den Präfixgrenzen.
• Zeichenvorrat. CX.3 leer, aber nichtnumerische Zeichen im Wert — entweder ein alphanumerischer Zähler oder ein Präfix.
• Die Gegenprobe. Existieren zwei Werte, die sich ausschließlich im Präfix unterscheiden? Dann trägt das Präfix Bedeutung, und die Sache ist entschieden.

Diese vier sind Indizien, keine Belege. Der Beleg ist die Vergabespezifikation des sendenden Systems oder eine schriftliche Auskunft der Kunden-IT. Eine Häufung in einer Stichprobe ist ein Anlass zu fragen, kein Befund.

Portalbezug

Ein Patientenportal legt den Identifier-Wert als Kontoschlüssel ab — daran hängen Login, Termine, Dokumente, Formulare. Ein Präfix macht diesen Schlüssel abhängig von einer Hausregel, die niemand versioniert und die in keinem Vertrag steht.

Der teuerste Einzelfehler an dieser Stelle ist nicht das Präfix selbst, sondern die gut gemeinte Reaktion darauf: „Das Präfix ist eh immer gleich, wir schneiden es beim Import ab.” Damit baut das Zielsystem die Kollision selbst ein — und zwar für den Tag, an dem das Präfix eben nicht mehr immer gleich ist. Wird CX.4 zusätzlich nicht gespeichert, ist der entstandene Schaden nicht rückwirkend auflösbar: Zwei Datensätze lassen sich nicht mehr trennen, wenn nirgends steht, aus welchem Namensraum ihre Nummern stammen.

Beispielnachricht (synthetisch)

Sauber kodiert — Herkunft im Feld, Wert opak:

PID|1||100045^^^HAUS-NORD&1.2.276.0.76.3.1.999.1&ISO^MR||Sommer^Nadine^^^^^L||19780312|F

Herkunft in den Wert gewandert, CX.4 leer — formal konform, inhaltlich blind:

PID|1||N-100045^^^^MR||Sommer^Nadine^^^^^L||19780312|F

Der bösartige Fall — beide Angaben gefüllt und widersprüchlich:

PID|1||S-100045^^^HAUS-NORD^MR||Sommer^Nadine^^^^^L||19780312|F

Das Präfix sagt Süd, CX.4 sagt Nord. Die Nachricht ist wohlgeformt, jeder Validator lässt sie durch, der Empfänger quittiert mit AA — und kein Feld des Standards entscheidet, welche der beiden Aussagen gilt. Ein Empfänger, der auf CX.4 hört, und einer, der das Präfix auswertet, ordnen dieselbe Nachricht zwei verschiedenen Personen zu.

---

Einordnung

Die Kategorie hängt nicht am Präfix, sondern daran, ob eine Vereinbarung existiert und was sie abdeckt:

Ausprägung	Kategorie
Der Empfänger entfernt das Präfix nach einer vereinbarten Regel, die einen Fall nicht abdeckt	4 — Mapping-Fehler
Es existiert keine Regel; der Empfänger entscheidet selbst, was er mit dem Präfix tut	3 — der Empfänger rät
CX.4 und Präfix widersprechen sich, beide Seiten sind konform, der Empfänger folgt korrekt dem, was dasteht	5 — ungewollte Aussage

Raster und Abgrenzungen: Die sechs Fehlerkategorien.

Im Kahn-Framework ist die unmittelbare Abweichung Value Conformance, sofern ein Wertformat vereinbart ist und verletzt wird. Ist keins vereinbart, ist der Befund als Conformance-Verstoß gar nicht darstellbar — Conformance misst gegen eine prespecified Architektur. Sichtbar wird der Schaden dann erst im Zielbestand, und dort als Uniqueness Plausibility: eine Person, zwei Datensätze.

Regel fürs Schnittstellenkonzept

Der Identifier-Wert ist opak. Kein Empfänger leitet aus ihm Herkunft, Sortierung, Alter oder Gültigkeit ab — Herkunft steht in CX.4, Sorte in CX.5, Gültigkeit in CX.7/CX.8.

Und kein Empfänger verändert ihn beim Import. Kein Trimmen, kein Casten nach Integer, kein Abschneiden von Präfixen, keine Normalisierung der Groß-/Kleinschreibung. Wo ein Präfix im Bestand existiert, wird es dokumentiert und beibehalten — es zu entfernen ist ein Identitätswechsel, kein Aufräumen.

Transfer

Dieses Fehlerbild ist der Musterfall dafür, dass ein Datenbestand fehlerfrei aussehen kann und trotzdem eine falsche Anzahl Personen enthält. Nichts daran meldet sich: kein NACK, keine Warnung, keine Lücke — nur zwei Zeilen, wo eine sein sollte, oder eine, wo zwei sein sollten. Für jede nachgelagerte Auswertung ist das schlicht der Bestand.

Für die Inventur einer Schnittstellenlandschaft folgt daraus eine Zeile, die selten jemand aufschreibt: Nach welchem Muster wird der Identifier-Wert vergeben, trägt er Bedeutung — und verändert ihn irgendein System auf dem Weg?

Fragen an die Kunden-IT

• Nach welchem Verfahren wird die Patientennummer vergeben — fortlaufender Zähler, Zähler mit Prüfziffer, oder mit Präfix? Gibt es dazu eine schriftliche Vergabespezifikation?
• Trägt der Wert ein Präfix oder Suffix, und wofür steht es? Kann es sich ändern (Fusion, Mandantenwechsel, Migration)?
• Wenn es ein Präfix gibt: Ist CX.4 zusätzlich gefüllt? Was gilt, wenn beide etwas Verschiedenes sagen?
• Werden Nummern nach Löschung oder Storno wiederverwendet? (Wenn ja, ist das Paar aus Wert und Namensraum ohne CX.7/CX.8 kein dauerhafter Schlüssel.)
• Kann der Wert führende Nullen enthalten — und verarbeitet ihn irgendein System auf der Strecke als Zahl statt als Zeichenkette?
• Wird der Wert im Zielsystem unverändert gespeichert, oder greift beim Import eine Normalisierung? Welche genau, und wo ist sie dokumentiert?

Lektüre & Belege

• HL7 v2.5.1, Kapitel 2.A — Datentypen — CX mit Komponentenlängen und Tabellenverweisen
• Datentyp CX · Datentyp HD
• Tabelle 0061 — Check Digit Scheme — M10, M11, ISO, NPI, BCV
• Tabelle 0203 — Identifier Type (THO)
• IHE ITI TF Volume 2, Appendix E — Patient Identifiers in HL7-based IHE Profiles — „The assigning authority unambiguously provides the context for the identifier.”
• ISiK Basismodul 4.0.1 — Datenobjekt Patient — identifier.system verpflichtend, kein Wertformat vorgegeben; die Frage „nach welchem Muster” bleibt auch in FHIR eine Hausfrage
• Sammlung aller Referenzen: Quellen & Lektüre

Verwandt: Wiederholung ≠ Komponente · Das Z-Kürzel ist kein Namensraum · Der Merge paart, er benennt nicht

Alle Beispieldaten synthetisch; die OID unter 1.2.276.0.76.3.1.999.x ist erfunden und nicht registriert.