Wiki - Chris Seyboth

PV1 und die Fallidentität

4 Min. Lesezeit

PV1 und die Fallidentität

Die Kernaussage

PID beschreibt eine Person. PV1 beschreibt einen Aufenthalt. Das sind zwei Objekte mit unterschiedlicher Lebensdauer, unterschiedlichem Schlüssel und unterschiedlicher Veränderungsfrequenz. Die häufigste Integrationsschuld in Portalanbindungen ist, dass die Fallnummer wie ein Patientenattribut behandelt wird — sie wird einmal beim Anlegen mitgeschrieben und danach nicht mehr angefasst. Ein Patient hat aber im Laufe eines Jahres mehrere Fälle, und ein Fall kann während seiner Laufzeit die Abteilung, die Klasse und die Station wechseln.

Die vier Felder, die zählen

PV1-2 Patient Class (Tabelle 0004: I inpatient, O outpatient, E emergency, P preadmit, R recurring, B obstetrics, N not applicable). Kein Stammdatum, sondern ein Zustand des Besuchs. Ein Notfall wird stationär (E → I), ein vorstationärer Patient wird aufgenommen (P → I). Portale hängen daran häufig ihre gesamte Feature-Logik: Aufnahme-Checkin, Essensbestellung, Entlassmanagement. Wird die Klasse nur bei A01 gelesen und bei A08/A02 ignoriert, zeigt das Portal für einen liegenden Patienten dauerhaft den ambulanten Funktionsumfang. Silent — niemand bekommt einen Fehler, der Patient bekommt nur die falsche Oberfläche.

PV1-3 Assigned Patient Location, Datentyp PL — hierarchisch, nicht flach: PL.1 Point of Care (Station) ^ PL.2 Room ^ PL.3 Bed ^ PL.4 Facility (HD) ^ PL.5 Location Status ^ PL.6 Person Location Type ^ PL.7 Building ^ PL.8 Floor. Ohne PL.4 ist die Station hausübergreifend mehrdeutig — im Verbund mit mehreren Standorten gibt es „Station 2” mehrfach. Wer PV1-3 als Freitext ins Portal durchreicht, verliert genau die Ebene, die für Wegeleitung und Besuchsinformationen gebraucht wird.

PV1-19 Visit Number vs. PID-18 Patient Account Number — der eigentliche Stolperstein. Beide sind CX, beide werden im deutschen Sprachgebrauch „Fallnummer” genannt, beide werden von vielen KIS mit demselben Wert befüllt. Semantisch sind sie verschieden: PV1-19 identifiziert den Besuch, PID-18 die Abrechnungseinheit. Sie fallen auseinander, sobald ein Haus Abrechnungsfälle über mehrere Besuche gruppiert (Serienbehandlung, teilstationär) oder umgekehrt einen Besuch in mehrere Abrechnungsfälle splittet. Ein Portal, das auf PID-18 schlüsselt, weil „da war die Nummer ja auch drin”, produziert genau dann Falschzuordnungen, wenn der Kunde seine Abrechnungslogik ändert — Monate nach Go-live, ohne Schnittstellenänderung.

PV1-44 Admit Date/Time und PV1-45 Discharge Date/Time sind Aussagen über den Fall. EVN-2 ist die Aussage über das Ereignis, das diese Nachricht auslöst. Bei A01 fallen sie oft zusammen, bei A02/A08 fast nie. Wer EVN-2 als Aufnahmezeit ins Portal schreibt, hat nach der ersten Verlegung eine Aufnahmezeit, die später liegt als die Aufnahme.

Beispiel: A01, sauber befüllt

MSH|^~\&|KIS^1.2.276.0.76.3.1.999^ISO|KH-MUSTER|PORTAL^1.2.276.0.76.3.1.998^ISO|KH-MUSTER|20260810073015+0200||ADT^A01^ADT_A01|KIS20260810000042|P|2.5|||AL|NE|||UNICODE UTF-8
EVN|A01|20260810073010+0200|||^Muster^Erika|20260810073005+0200
PID|1||10004711^^^KH-MUSTER-MPI^MR||Grünberg^Anna^^^^^L||19780314|F|||||^PRN^CP^^49^170^1234567~^NET^Internet^anna.gruenberg@example.org|||||2026000815^^^KH-MUSTER-FALL^AN
PV1|1|I|CHI-1^204^02^KH-MUSTER^^N^Haus B^2||||1234^Schmidt^Thomas^^^Dr.^^^KH-MUSTER-ARZT^L^^^DN|||CHI|||||||||2026000815^^^KH-MUSTER-FALL^VN|||||||||||||||||||||||||20260810073000+0200

Lesart: stationär (PV1-2 = I), Station CHI-1, Zimmer 204, Bett 02, Haus B, 2. Etage, Fachabteilung Chirurgie (PV1-10 = CHI), Besuchsnummer 2026000815 unter der Authority KH-MUSTER-FALL mit Typ VN, Aufnahme 07:30 Ortszeit mit Offset. Dass PID-18 hier denselben Wert trägt, ist eine Eigenschaft dieses Hauses, keine Eigenschaft von HL7 — und gehört als solche ins Schnittstellenkonzept, nicht in eine Annahme im Code.

Merksatz

Der Patient hat eine Identität, der Fall hat eine Identität, und die Nachricht hat einen Zeitpunkt. Drei Schlüssel, drei Felder, drei Quellen. Jede Verwechslung erzeugt eine Zuordnung, die syntaktisch korrekt und fachlich falsch ist.

Transfer

Genau diese Verwechslung ist der Grund, warum FHIR das Konstrukt „Fall” aufspaltet: In ISiK trägt nicht der Encounter die Fallnummer, sondern der Account — die Fallnummer gilt dort als „eindeutiger Identifier des Abrechnungsfalls” und wird ausdrücklich nicht zur Identifikation einzelner Encounter verwendet; der Encounter führt sie nur als logische Referenz auf den Account mit. Verpflichtend sind in ISiK der Account und der Abteilungskontakt-Encounter, während Einrichtungs- und Versorgungsstellenkontakt optional bleiben. Wer heute in HL7 v2 PV1-19 und PID-18 als dasselbe behandelt, muss die Unterscheidung spätestens beim FHIR-Mapping nachziehen — dann allerdings rückwirkend über Bestandsdaten. In der Kahn-Systematik ist das kein Conformance-Problem (die Nachricht ist gültig), sondern Plausibility: ein Patient mit zwei parallel laufenden Aufenthalten in derselben Sekunde ist im Zielsystem widerspruchsfrei gespeichert und trotzdem unmöglich.

Quellen (verifiziert am 10.08.2026): ISiK Basis IG 6.0.0-rc1 — Abbildung des Konstrukts „Fall” · ISiKKontaktGesundheitseinrichtung (Simplifier, ISiK Stufe 5)

Fragen an die Kunden-IT

  • Was ist bei euch die stabile Fallnummer — PV1-19, PID-18, oder ein Z-Segment? Bleibt sie über Verlegung, Fachabteilungswechsel und Storno gleich?
  • Wird bei einer Verlegung eine neue PV1-19 vergeben? (Falls ja: der Empfänger sieht zwangsläufig einen zweiten Fall.)
  • Wie ist PV1-3 komponentenweise befüllt — was steht in Point of Care, Room, Bed, Facility? Und ist die Belegung über alle Events gleich?
  • Wird PV1-2 zwischen ambulant und stationär korrekt gewechselt? Was sendet ihr für vorstationäre und nachstationäre Kontakte?
  • Tragen PV1-44/PV1-45 die fachliche Ereigniszeit oder den Erfassungszeitpunkt — und wie verhält sich das zu EVN-2?

Lektüre & Belege

Graphansicht

Backlinks