Wiederholung ≠ Komponente
An Tag 1 stand die Trennzeichenhierarchie: | Feld, ^ Komponente, & Subkomponente, ~ Wiederholung. Drei davon sind Struktur innerhalb eines Wertes. Die vierte — ~ — ist etwas kategorial anderes: sie bedeutet mehrere gleichrangige Werte desselben fachlichen Typs, die nur zusammen mit ihrem Qualifier interpretierbar sind.
Genau hier zerbrechen Portal-Anbindungen, und zwar leise. Ein Mapping, das „nimm die erste Wiederholung” implementiert, produziert nie einen Fehler. Es produziert einen falschen Patienten.
PID-3 - Patient Identifier List (CX, wiederholend)
Der Datentyp CX hat in v2.5.1 zehn Komponenten (die refaktorierte v2+-Fassung führt zwölf, zusätzlich Security Check und Security Check Scheme); für die Praxis zählen vier:
| Komponente | Inhalt | Tabelle |
|---|---|---|
| CX.1 | ID Number — der Wert selbst | — |
| CX.4 | Assigning Authority (HD: Namespace ID & Universal ID & Universal ID Type) | — |
| CX.5 | Identifier Type Code (MR, PI, PN, NII, VN, AN …) | 0203 |
| CX.6 | Assigning Facility (HD) | — |
Die Kernaussage: Ein Identifier ist ohne CX.4 und CX.5 bedeutungslos. 10004711 allein ist keine Identität, sondern eine Zahl. Erst das Tripel (ID-Nummer, Assigning Authority, Identifier Type) ist ein Schlüssel. Ein Portal, das auf CX.1 allein matcht, koppelt zwei Häuser eines Verbunds an derselben Nummer zusammen — ein Patient sieht die Akte eines anderen.
Der Standard schreibt für CX.1 kein Format vor: ST, Länge 15, „A unique code for distinguishing persons or things.” Der Wert ist opak, und „unique” gilt nur innerhalb des Namensraums aus CX.4. Wandert die Herkunft stattdessen als Präfix in den Wert (N-100045), entsteht ein eigenes Fehlerbild: Der Namensraum im Wert.
PID-5 - Patient Name (XPN, wiederholend)
XPN hat 15 Komponenten; entscheidend sind:
| Komponente | Inhalt |
|---|---|
| XPN.1 | Family Name (Datentyp FN, selbst zusammengesetzt: Surname & Own Surname Prefix & Own Surname & Surname Prefix From Partner & Surname From Partner) |
| XPN.2 | Given Name |
| XPN.3 | Second and Further Given Names |
| XPN.5 | Prefix (z. B. Dr.) |
| XPN.7 | Name Type Code (Tabelle 0200): L = Legal, M = Maiden, A = Alias, D = Display, B = Birth name |
Auch hier: die Wiederholung ist nur über XPN.7 auflösbar. „Erste Wiederholung gewinnt” ist eine Wette darauf, dass das KIS zufällig den Legal Name zuerst sendet.
PID-13 — Phone Number Home (XTN, wiederholend)
Für ein Patientenportal ist PID-13 kein Nebenfeld, sondern der Onboarding-Kanal. XTN:
| Komponente | Inhalt | Tabelle |
|---|---|---|
| XTN.1 | Telephone Number als Freitext — seit v2.3 deprecated | — |
| XTN.2 | Use Code: PRN privat, WPN dienstlich, NET Netzwerk/E-Mail | 0201 |
| XTN.3 | Equipment Type: PH Festnetz, CP Mobil, FX Fax, Internet | 0202 |
| XTN.4 | E-Mail-Adresse | — |
| XTN.5–7 | Country Code, Area Code, Local Number | — |
Ohne XTN.3 kann kein System entscheiden, ob eine TAN per SMS zustellbar ist. Der Versand scheitert dann nicht — er geht an ein Festnetz.
Referenzbeispiel (synthetisch, sauber kodiert)
MSH|^~\&|KIS^1.2.276.0.76.3.1.999.1^ISO|KH-MUSTER|PORTAL|KH-MUSTER|20260809081500+0200||ADT^A08^ADT_A01|KIS-20260809-000814|P|2.5|||AL|NE|DEU|UNICODE UTF-8
EVN|A08|20260809081500+0200
PID|1||10004711^^^KH-MUSTER-MPI&1.2.276.0.76.3.1.999.2&ISO^MR~A123456789^^^AOK-MUSTER^NII||Gruenberg^Anna^Maria^^Dr.^^L~Weber^Anna^^^^^M||19780314|F|||Meyer \T\ Sohn-Weg 12^^Musterstadt^^12345^DEU^H||^PRN^CP^^49^170^1234567~^NET^Internet^anna.gruenberg@example.org|||||||||||||||||
Lesehilfe zu PID-3, Wiederholung 1: ID 10004711, Assigning Authority = HD mit Namespace KH-MUSTER-MPI, Universal ID 1.2.276.0.76.3.1.999.2, Type ISO (die & sind hier Subkomponenten innerhalb der Komponente CX.4 — genau der Fall aus Tag 1, nur diesmal legitim), Identifier Type MR. Wiederholung 2 ist die Krankenversichertennummer unter fremder Authority mit Type NII.
Transfer
Alle vier Befunde sind Kahn-Conformance-Verstöße (Wert verletzt die Struktur- bzw. Wertebereichsvorgabe des Feldes) — und drei davon werden vom Empfänger mit AA quittiert. Das ist die Datenstrecke, an der KI im Krankenhaus scheitert, bevor irgendein Modell startet: nicht fehlende Daten, sondern Daten ohne den Qualifier, der sie interpretierbar macht. Für die Inventur-Checkliste Schnittstellenlandschaft ergibt sich eine konkrete Zeile: Welche wiederholenden Felder wertet unser Mapping aus, und nach welchem Qualifier — oder nach Position?
Fragen an die Kunden-IT
- Welche Identifier-Typen (
CX.5) sendet ihr inPID-3, und ist ihre Reihenfolge zugesichert? (Wenn nicht, darf der Empfänger nicht positionell auswählen.) - Ist
CX.4(Assigning Authority) immer gefüllt? Mit welchem Namensraum — und ist der im Verbund eindeutig? - Können zwei Häuser oder zwei Vorsysteme dieselbe Ziffernfolge vergeben? Woran unterscheidet der Empfänger sie dann?
- Welche
PID-5-Wiederholung ist der rechtlich gültige Name, und trägt sieXPN.7 = L? - Wie unterscheidet ihr Mobil- von Festnetznummern in
PID-13— überXTN.3, über die Position, oder gar nicht? - Was soll der Empfänger tun, wenn der erwartete Qualifier fehlt? (Empfehlung: protokollieren und nicht ersetzen.)
Lektüre & Belege
- HL7 v2.5.1, Kapitel 3 — Patient Administration — PID mit allen 39 Feldern
- Tabelle 0203 — Identifier Type (THO 6.0.1) —
MR,PI,NI,PNund die übrigen Typcodes - Datentyp CX — zwölf Komponenten inkl. Assigning Authority und Assigning Facility
- Sammlung aller Referenzen: Quellen & Lektüre