Der Identifier ist ein Paar

Konzept: Wert und Namensraum

Eine Patientennummer für sich genommen bedeutet nichts. Bedeutung entsteht erst aus dem Paar Wert + Namensraum — aus der Frage, wer diese Nummer vergeben hat. Alles, was HL7 v2 an dieser Stelle vorsieht, setzt diesen einen Satz um; alle typischen Fehler bestehen darin, dass ein System nur eine Hälfte des Paares auswertet oder speichert.

Ein Identifier ist kein Wert. Er ist ein Paar — und der Namensraum ist im Normalfall selbst nur ein lokal vergebener Name.

Das ist dieselbe Bewegung wie bei Z-Segmenten, nur an einer Stelle, an der man Ordnung erwartet.

Zwei Achsen, die verwechselt werden

PID-3 – Patient Identifier List ist vom Typ CX. Zwei Komponenten tragen die Last, und sie beantworten verschiedene Fragen:

Komponente	Typ	Beantwortet
CX.1 ID Number	ST (15)	Welche Zahl? — für sich bedeutungslos
CX.4 Assigning Authority	HD	Wessen Nummer ist das?
CX.5 Identifier Type Code	ID (Tab. 0203)	Was für eine Nummer ist das?
CX.7/CX.8	DT	Ab wann, bis wann gültig

CX.5 sagt dir, dass es eine Aktennummer ist. Es sagt dir nicht, aus wessen Haus. Wer über CX.5 identifiziert, identifiziert über die Sorte statt über die Herkunft — und trifft im Verbund die falsche.

Das IHE IT Infrastructure Technical Framework, Volume 2, Appendix E formuliert die Rollenverteilung normativ:

„The assigning authority unambiguously provides the context for the identifier.”

„Each occurrence of PID-3-Patient Identifier List contains, at a minimum, an identifier value in Component 1 and an assigning authority in Component 4.”

Der Typcode ist dort ausdrücklich nicht gefordert:

„It is also common practice to provide an identifier type code in Component 5, but this is not required by IHE in the context of the PIX transactions [ITI-8], [ITI-9], and [ITI-10].”

Nebenbei zeigt die Codetabelle selbst, wie eng Wert und Namensraum zusammengehören: PI – Patient internal identifier ist definiert als „A number that is unique to a patient within an Assigning Authority”. Die Eindeutigkeit ist dort ausdrücklich an die Authority gebunden — der Kernsatz dieser Seite, versteckt in einer Tabelle.

Der Namensraum ist selbst nur ein Name

CX.4 ist vom Typ HD:

Komponente	Typ	Geltungsbereich
HD.1 Namespace ID	IS (Tab. 0300)	lokal — „The local coded item for the entity.”
HD.2 Universal ID	ST	global, im Format von HD.3
HD.3 Universal ID Type	ID (Tab. 0301)	„governs the interpretation of the second component of the HD”

Belegungsregeln: „If the first component for the HD data type is present, the second and third components are optional” — und „The second and third components must either both be valued (both non-null), or both be not valued (both null).”

Daraus der Befund:

HD.1 allein ist konform — und HD.1 ist nur ein Name. Tabelle 0300 ist user-defined: Der Standard liefert keine Werte, sondern die Erlaubnis, eigene zu vergeben. Kein Register, keine Kollisionsprüfung, keine Instanz, die zwei Einrichtungen verbietet, ihren Namensraum gleich zu nennen.

Global verankert wird er erst über HD.2/HD.3 — in Deutschland über den OID-Ast 1.2.276.0.76, dessen Zweig …76.3 die „Instanzen — Identifikatoren des deutschen Gesundheitswesens” trägt. Konstruktionsprinzip: „Die Kombination aus der eigentlichen Identifikation (extension) und der ausgegebenen Instanz (Root-OID) zusammen genommen weltweit eindeutig.”

100045^^^HAUS-NORD^MR                                ← lokal, kollidierbar
100045^^^HAUS-NORD&1.2.276.0.76.3.1.999.1&ISO^MR     ← global eindeutig

Beide Formen sind konform. Die erste ist der Regelfall.

PID-3 ist eine Liste ohne Rangordnung

PID-3 ist wiederholbar ([1..*]):

„This field contains the list of identifiers (one or more) used by the healthcare facility to uniquely identify a patient …”

Eine Liste. Kein Feld, keine Komponente und keine Regel benennt darin einen führenden Identifier: kein primary-Flag, keine Rangkomponente, keine Sortiervorschrift. IHE weist der Reihenfolge der Wiederholungen ebenfalls keine Bedeutung zu.

Das ist eine Modellaussage, keine Nachlässigkeit: Aus Sicht des Standards existiert „der führende Identifier” nicht. Es existiert eine Person mit mehreren Nummern in mehreren Namensräumen. Welche für ein Zielsystem der Schlüssel ist, ist eine Vereinbarung.

Wo der Standard schweigt, füllt der Empfänger die Lücke — meist still und meist mit der Reihenfolge. „Wir nehmen die erste Wiederholung” ist die häufigste und zugleich schlechteste Implementierung, weil sie eine Eigenschaft auswertet, die keine Bedeutung trägt. Ändert der Sender seine Sortierung — was ihm freisteht —, wechselt der Schlüssel lautlos.

Zählweise

Wiederholung 1 ist der Wert vor dem ersten ~. Das Trennzeichen steht zwischen den Werten, nicht vor ihnen — wie | zwischen Feldern. Der Standard zählt occurrences ab dem ersten Vorkommen. Das deutsche Wort „Wiederholung” legt die falsche Lesart nahe; in Schnittstellenkonzepten deshalb besser „Vorkommen 1” schreiben oder die Position ausformulieren.

Der Kontrast zur Merge-Nachricht ist das eigentlich Lehrreiche: Dort trägt die Anordnung Semantik (welches Segment einen Wert führt, entscheidet die Richtung). In PID-3 trägt sie keine. Dieselbe Ebene, umgekehrtes Ergebnis.

Die Ebene Anordnung ist pro Fall zu bestimmen. Sie ist keine Eigenschaft von HL7 v2 im Ganzen.

Die sechste Antwort: nirgends

Die Ebenenleiter aus Seite 12 lautet Wert → Feld → Segment → Anordnung → Bezugsdokument. Auf die Frage „Wo steht die Aussage: dieser Identifier ist der führende?” liefert sie ein Ergebnis, das auf der Leiter nicht steht:

Sprosse	Prüfung	Ergebnis
Wert	Beide Werte sind korrekt; keiner sagt etwas über Rang	scheidet aus
Feld	PID-3 ist richtig und richtig typisiert; es sagt „das sind Identifier”, nicht „dieser führt”	scheidet aus
Segment	PID ist richtig, gleiche Begründung	scheidet aus
Anordnung	Eine Reihenfolge existiert, aber niemand hat ihr Bedeutung zugewiesen. Eine Reihenfolge ohne zugewiesene Bedeutung ist ein Artefakt der Datenbeschaffung im Sender, kein Träger einer Aussage	scheidet aus
Bezugsdokument	Ein Schnittstellenkonzept kann sagen „nimm, was vorne steht” — das ist ein Stellvertreter für die Tatsache, nicht die Tatsache	scheidet aus

Die Aussage existiert im Datenmodell nicht. Solange man sie irgendwo verortet, sucht man den Defekt dort und will ihn dort reparieren — Reihenfolge drehen, Typcode umbiegen. Erst wenn klar ist, dass sie nirgends steht, ist auch klar: Die einzige Reparatur besteht darin, sie zu erzeugen.

Prüfregel: Wer eine Ebene benennt, muss die Stelle zeigen können, die dieser Ebene Bedeutung zuweist. Fehlt diese Zuweisung, beschreibt man das Verhalten eines Systems, nicht den Inhalt einer Nachricht.

Ein Vertrag kann eine Aussage regeln, aber nicht erzeugen

Damit die Abgrenzung im Sechserraster:

	Der Mangel liegt …
3 — Empfänger rät	in der Nachricht: gegen ihr eigenes Bezugsdokument gelesen bleibt eine Frage offen	die Aussage existiert nicht
4 — Mapping-Fehler	in der Abbildung: die Nachricht ist eindeutig, der Empfänger deckt sie nicht ab	die Aussage existiert und wird falsch übersetzt

Kurzform, die im Alltag trägt:

Eine Abbildung kann nur falsch sein, wenn es etwas abzubilden gibt.

Und der Zusatz, der oft übersehen wird: Ein Vertrag, der die fehlende Aussage durch einen Stellvertreter ersetzt, macht aus 3 keine 4. Er dokumentiert nur, wie geraten wird. Eine solche Regel ist dabei nicht unpräzise — sie kann maximal explizit und deterministisch ausführbar sein. Ihr fehlt nicht Deutlichkeit, sondern Anbindung: Sie wählt nach einer Eigenschaft ohne Bedeutung (Position) statt nach einer mit Bedeutung (Namensraum).

Wer der Kunden-IT sagt „Ihr Konzept ist nicht explizit genug”, bekommt die Regel vorgelesen.

Ebenfalls kein Ausschlussgrund für 4: „Es wird abgebildet, was vereinbart wurde.” Sonst wäre jede Strecke mit dokumentiertem Mapping automatisch keine Kategorie 4 mehr.

Portalbezug

Ein Patientenportal braucht genau eines: einen stabilen Kontoschlüssel, an dem Login, Termine, Dokumente und Formulare hängen. Es ist damit empfindlicher als das sendende System, das mehrere Nummern problemlos nebeneinander führt. Drei Entwurfsvarianten:

1. Schlüssel = CX.1. Funktioniert, solange es einen Namensraum gibt. Bricht beim ersten Verbund — und bricht still.
2. Schlüssel = CX.1 + CX.4. Korrekt, beantwortet aber noch nicht, welches Paar von mehreren.
3. Schlüssel = das Paar aus einem im Schnittstellenkonzept festgelegten Namensraum. Erst das ist tragfähig — und es kommt nicht aus der Nachricht.

Wird CX.4 nicht gespeichert, ist ein Identitätsschaden nicht rückwirkend auflösbar: Zwei Datensätze lassen sich nicht mehr zusammenführen, wenn nirgends steht, aus welchem Namensraum ihre Nummern stammen.

Beispielnachricht (synthetisch)

Dieselbe Person, dieselben zwei Nummern, zwei Nachrichten. Einziger Unterschied: die Reihenfolge der Vorkommen.

MSH|^~\&|SENDER|EINRICHTUNG|EMPFAENGER|EINRICHTUNG|20260814081500+0200||ADT^A08^ADT_A01|MSG00417|P|2.5.1
EVN||20260814081500+0200
PID|1||100045^^^HAUS-NORD^MR~778123^^^HAUS-SUED^MR||Sommer^Nadine^^^^^L||19780312|F

PID|1||778123^^^HAUS-SUED^MR~100045^^^HAUS-NORD^MR||Sommer^Nadine^^^^^L||19780312|F

Ein Empfänger mit der Regel „erstes Vorkommen mit MR” wechselt zwischen beiden Nachrichten lautlos den Kontoschlüssel und legt einen zweiten Datensatz an — quittiert mit AA, ohne Logeintrag. Beide Nachrichten sind konform und sagen dasselbe. Keine sagt, welche Nummer zählt.

Entscheidend für die Diagnose: Beide Nummern stehen in jeder Nachricht.

Es fehlen keine Daten. Es fehlt eine Regel.

Prüffrage zu jedem Identitätsschaden: Ist die Zusammengehörigkeit aus dem Nachrichtenverkehr überhaupt belegbar? Sendet das Quellsystem beide Nummern dauerhaft nebeneinander, ist sie es — dann liegt der Mangel ausschließlich beim Empfänger, und der Schaden bleibt reparabel, solange ihn jemand bemerkt. Sendet es je Zeitraum nur eine, ist die Verbindung nirgends belegt und der Schaden endgültig.

Was eine Reparatur ist — und was nicht

Die Gegenprobe rechnet vorwärts. Ein Befund kann kausal sein und den bereits erzeugten Zustand trotzdem nicht rückgängig machen. Wer die Auswahlregel repariert, verhindert weitere Dubletten; die bestehende bleibt.

Es kommt kein Merge-Ereignis. Der naheliegende Reflex — „dann verarbeiten wir eben A40 korrekt” — geht ins Leere: Aus Sicht des Quellsystems ist nichts zusammengeführt worden, es hat nichts zu melden. Merge-Verarbeitung hilft gegen Dubletten, die der Sender meldet, nie gegen Dubletten, die der Empfänger erzeugt.

Der Typcode ist kein Ersatz für „nicht führend”. Eine Wiederholung von MR auf PI umzustellen, damit die eigene Auswahlregel wieder greift, wirkt — und ist trotzdem falsch: Der Typcode bedeutet dann zweierlei, und die Aussage über die Art der Nummer wird unwahr. Aus fehlenden Daten werden falsche Daten (vgl. Werteangleichung als Zweckentfremdung). Dazu der Kollateralschaden: Jedes andere System, das nach CX.5 filtert, findet die Nummer nicht mehr.

Der Test für jeden Vorschlag:

Wird die auslösende Eigenschaft danach irrelevant?

Nach „Auswahl über den Namensraum” ist die Sortierung des Senders gleichgültig — die Reparatur sitzt an der Ursache. Bleibt sie relevant, wurde ein Zufall wiederhergestellt, keine Regel.

Wegvereinbart ≠ unvereinbart

Ein Feld, für das ein Vertrag ausdrücklich „wird nicht ausgewertet” sagt, ist etwas anderes als ein Feld ohne Vertrag. Im ersten Fall ist die Blindheit dokumentiert und damit prüfbar, im zweiten ist sie zufällig. Beides führt zum selben Ergebnis — aber nur das erste lässt sich in einem Review finden.

Kahn: der Fall ohne Kategorie im Quellbestand

Im Kahn-Framework ist dieser Defekt lehrreich, weil er im Quellbestand in keine Kategorie fällt: Die Nachricht verletzt weder Value- noch Relational- noch Computational Conformance. Wer im Quellsystem misst, findet nichts.

Messbar wird er erst im Zielbestand, und dort als Plausibility, Untertyp Uniqueness Plausibility — eine Person, zwei Datensätze. Nichts daran ist eine verletzte Beziehung; verletzt ist eine erwartete Anzahl.

Das ist die Grenze des Rahmens in Reinform: Kahn misst Bestände, nicht Strecken, und kennt keine Kategorie für einen Verarbeitungsfehler, der aus konformen Daten entsteht. Pointe obendrauf: Gegen das eigene Schnittstellenkonzept gemessen ist der Empfänger sogar konform — Conformance gegen die falsche Spezifikation.

Nachweisweg bleibt der Abgleich Quelle ↔ Ziel. Der ist allerdings der Nachweis, nicht die Bedingung — er kann nie zwischen Kategorie 3 und 4 entscheiden, weil beide ihn sich teilen.

Betriebsregel für Strecken dieser Art

Wo ein Vertrag eine fehlende Aussage durch einen Stellvertreter ersetzt, hängt die Zuordnung an einer nicht zugesicherten Eigenschaft. Genau dort gehört ein Wächter hin:

Wenn ein Vertrag eine Aussage regelt, aber nicht erzeugt, muss ein Nachweismechanismus unerwartete Änderungen im Datenstrom erkennen.

Konkret: die Reihenfolge und die Menge der Identifier je Person mitschreiben und Änderungen melden. Das schließt die Lücke nicht — es macht sie sichtbar. Beides ist nötig, in dieser Reihenfolge: erst die Aussage beschaffen, dann den Wächter setzen.

Fragen an die Kunden-IT

• Welcher Patientennummern-Namensraum ist gegenüber dem Zielsystem der führende — und gilt er für alle Patienten des Verbunds? (Nach dem Namensraum fragen, nicht nach einer Nummer: CX.1 ist ein Wert für einen Patienten, CX.4 eine Regel für alle. Und ohne „aus eurer Sicht” — es ist eine Tatsachenfrage, keine Meinungsfrage.)
• Wie viele Namensräume sind im Haus aktiv, und wer vergibt sie? In Häusern mit Fusions- oder Migrationshistorie ist die Antwort selten „einer”.
• Wird CX.4 gesendet — nur HD.1, oder mit registriertem OID in HD.2/HD.3?
• Nach welcher Regel sortiert das sendende System die Vorkommen in PID-3, und ist diese Regel zugesichert oder ein Implementierungsdetail?
• Wird CX.4 im Zielsystem gespeichert — oder beim Import ausgewertet und verworfen?
• Was passiert, wenn eine bisher unbekannte Assigning Authority auftaucht: Fehler oder stille Neuanlage?

Und je nach Antwort:

Antwort	Zielsystem	Vertrag	Adressat
„Namensraum X, für alle”	Auswahl über CX.4 statt über die Position; Schlüssel = Paar; CX.4 speichern	Namensraum namentlich festhalten, OID optional	Empfänger — der Sender ändert nichts
„Hängt vom aufnehmenden Haus ab”	Kein einzelner Schlüssel möglich → Identitätsverfahren (mehrere Identifier je Konto, PIX/PDQ oder vereinbarter Merge)	Merge-Verfahren aufnehmen	gemeinsame Architekturentscheidung
„Nicht festgelegt”	zunächst nichts	zuerst einen Satz schreiben	beide — und die Einordnung bleibt 3, bis er existiert

Abgrenzung zu FHIR und ISiK

FHIR erzwingt das Paar auf Modellebene: Identifier.system ist ein URI, Identifier.value die Zeichenkette darin. Deutsche Profile machen das verbindlich — im ISiK-Basismodul ist identifier.system für den Slice der organisationsinternen Patientennummer mit 1..1 gefordert; anzugeben ist „stets der eindeutige Name (URL) des Namensraums”.

Was damit nicht gelöst ist:

• Ein system kann frei erfunden werden. Ein URI ist syntaktisch global, aber nicht automatisch registriert.
• Auch in FHIR legt nichts fest, welcher von mehreren Identifiern der führende ist. Statt „erstes Vorkommen” heißt die Lücke dort „Slicing nach system” — man muss den Namensraum vorher kennen.

Die Vereinbarung verschwindet nicht. Sie wandert aus dem Schnittstellenkonzept ins Profil.

---

Transfer

Ein Datenbestand, in dem eine Person zweimal existiert, ist für jede nachgelagerte Auswertung schlicht ein Bestand mit einem Fall mehr. Kein NACK, keine Warnung, keine Lücke — nur zwei Zeilen, wo eine sein sollte. Und unumkehrbar genau dann, wenn die Information, die ihn auflösen würde, beim Import verworfen wurde.

Für die Inventur einer Schnittstellenlandschaft folgt daraus eine Zeile, die selten jemand aufschreibt: Welche Patientennummern-Namensräume existieren, wer vergibt sie, welcher ist gegenüber dem Zielsystem der führende — und steht das irgendwo?

Lektüre & Belege

• HL7 v2.5.1, Kapitel 2 (Control/Datentypen) · Kapitel 2.A (Datentypen im Detail) · Kapitel 3 (Patientenverwaltung)
• Datentyp CX · Datentyp HD · PID-Segment
• Tabelle 0203 — Identifier Type (THO) — MR und PI bezeichnen beide den Patienten; fallbezogen sind AN und VN
• IHE ITI TF Volume 2, Appendix E — Patient Identifiers in HL7-based IHE Profiles
• ISiK Basismodul 4.0.1 — Datenobjekt Patient
• HL7 Deutschland — Object Identifier (OID) · BfArM OID-Register
• Sammlung aller Referenzen: Quellen & Lektüre

Belegvorbehalt: Die Aussage „die Reihenfolge der Vorkommen trägt keine Bedeutung” ist negativ belegt — kein Feld, keine Regel und kein Satz in v2.5.1 oder IHE App. E weist ihr eine zu. Ein positives Zitat „die Reihenfolge ist bedeutungslos” existiert nicht. Ein nationales Profil könnte ihr Bedeutung geben; dann gilt das Profil.

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

Alle Beispieldaten synthetisch; die OIDs unter 1.2.276.0.76.3.1.999.x sind erfunden und nicht registriert.