Patientenidentität und Zweckbindung steuern
Patienten-ID, Identity Authority und Purpose Binding als Vertrag: Grain, erlaubter Zweck, Owner und wer Merges sowie Research-Asks ablehnt.
Eine zusammengeführte Patientennummer ist noch kein Vertrag. Identitäts-Governance scheitert, wenn HIS und PACS dieselbe Person unter zwei Schlüsseln führen — oder denselben Schlüssel still für Versorgung, Billing und Research teilen. Spätere Encounter-, Export- und Audit-Fragen haben nichts Verbindliches.
Dieser Teil definiert den Mindestvertrag für Patientenidentität und Purpose Binding — bevor Research-Export und FHIR darauf aufsetzen.
Vorher: Governance in Healthcare. Weiter: Forschung und Pseudonymisierung.
Ansatz
Jeder materielle Patientensatz erhält vor Aufnahme, Merge und jedem Zugriff außerhalb der Versorgung:
- eine Patienten-ID mit verbindlichem Grain (Person, nicht Encounter, nicht Abrechnungsfall);
- eine Identity Authority (MPI/HIS) mit Matching-Regel und Survivorship;
- ein Purpose Binding — genau ein legitimierter Zweck je Identifier-Kreis (Care, Research, Billing, Secondary Use);
- einen Care Owner (ärztliche Leitung / CMO) für Semantik und Ablehnung und einen Steward für Identity-Konflikte;
- einen Ausnahmeweg mit benanntem Freigeber, Grund und Ablaufdatum.
Kein Match und kein Zugriff ohne den im Contract benannten Zweck.
Identity-Purpose-Workflow
1. Grain und Authority festlegen
Der Care Owner beschließt, wer der Patient ist und welche Quelle führt, wenn HIS und PACS widersprechen. Encounter, Episode und Claim bekommen eigene IDs — keine improvisierte Zusammenführung in der Aufnahme. Wenn Excel, RIS und HIS denselben Identifier unterschiedlich führen, gilt dieselbe Authority — das Extract-Grain schneidet Extract-Grain und Abteilungs-Listen.
2. Zweck an den Identifier-Kreis binden
Purpose Binding hängt am Schlüssel, nicht am Ticket. Care darf Klaridentität am Bett; Billing, Register und Analytics erben denselben Schlüssel nicht. Ein Match ohne Zweck bleibt blockiert.
3. Encounter vom Patienten trennen
Diagnose, Medikation und Befund hängen am Kontakt. Ein Patient-Export ohne Encounter-Grain vermischt Episoden und macht Care- und Research-Aussagen unwiederholbar.
4. Control am Zugriff
Blockierend: Zugriff oder Merge ohne Purpose Binding; Care-ID in einem Secondary-Use-Extract; Merge ohne Owner-Entscheidung. Warnend: unsichere Matches. Der HIS/PACS-Admin setzt die Regel um — er entscheidet den Zweck nicht.
5. Negativtest Care→Secondary
Ein unabhängiger Lauf muss beweisen: dieselbe Laborzeile darf den Care-Pfad nicht als Klartext für Research oder Analytics verlassen. Besteht der Test nicht, bleibt der Pfad zu.
6. Ausnahme und Review
Jede befristete Zwecküberschreitung trägt Freigeber, Kompensation und Ablauf. Matching-Regeländerungen brauchen Impact und Consumer-Hinweis, bevor ein zweites System denselben Kreis nutzt.
Anwendungsbeispiel — Encounter ist nicht der Claim
Station behandelt Encounter E-8841 (Diagnose, Medikation). Billing bucht denselben Kontakt unter Fallnummer F-22019. Analytics merged beide IDs „für eine Patientensicht“. Der Close und die Research-Kohorte ziehen dann Care-Felder über den Claim.
Stop: Encounter-Grain bleibt Care; Claim-Grain bleibt Billing. Secondary Use braucht einen eigenen Zweck — nicht die Fallnummer als heimliche Patienten-ID. Derselbe Lehrfall gilt im Evidence Pack: Rekonstruktion muss beide Identifier getrennt finden.
Handoffs
| Von | An | Artefakt |
|---|---|---|
| Care Owner (CMO / ärztliche Leitung) | Steward / Identity | Purpose-Entscheidung Care mit Patienten- und Encounter-ID |
| Steward | HIS/PACS-Admin (Custodian) | Matching-Regel, Survivorship, Purpose Binding |
| Aufnahme / Station | Steward | Identity-Konflikt HIS ≠ PACS |
| Steward | Architect | Patienten-Grain plus Abgrenzung Encounter/Claim |
| Care Owner | Research Owner | Ablehnung oder Freigabegrenze vor jeder Kohortenanfrage |
Anti-Patterns
- MPI-Merge ohne Owner und ohne Zweck als „Datenqualität“ verkaufen
- Care-Identifier im Billing- oder Analytics-Exportdatei als Klartext weitergeben
- Encounter und Patient in einem fachliche Ebene vermischen
- HIS-Admin entscheidet den Zweck, weil die Merge-UI bei ihm liegt
- Purpose Binding nur im Wiki, nicht am Durchsetzung-Punkt
Erster Umsetzungsschnitt
Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.
Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.
Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.
- Identity Authority schriftlich festlegen: welche Quelle führt bei HIS- vs. PACS-Konflikt.
- Purpose-Register mit fünf Identifier-Kreisen schneiden (Care, ein Billing-Pfad, ein ausgeschlossener Secondary Use).
- Einen offenen Identity-Konflikt durch Steward-Triage jagen und die Owner-Entscheidung datieren.
- Negativtest dokumentieren: Care-ID darf einen Analytics- oder Research-Ask nicht als Klartext verlassen.
Weiterlesen
- Bildgebung, Abteilungs-Excel und BI
- Exportdatei-fachliche Ebene und Abteilungs-Listen
- Healthcare Nachweis und Audit Packs
Governance in the healthcare landscape
Part 2 of 5
View series