Governance in der Healthcare-Landschaft

Begriffe vor dem Lesen

• Governance — Gemeinsame Regeln, Rollen und Nachweise, damit Daten verantwortbar genutzt werden.
• verantwortliche Person — Fachlich verantwortliche Person oder Rolle, die Zweck, Bedeutung und Freigabe klärt.
• technischer Betreiber — Technische Rolle, die Plattform, Zugriff, Betrieb oder Umsetzung betreut.
• Nachweis — Nachvollziehbarer Nachweis zu Entscheidung, Prüfung, Umsetzung oder Ausnahme.

Sizing: Kleine Einrichtung — ein Care-Produkt mit Zweckbindung, Encounter-Grain und Care Owner, häufig ärztliche oder fachliche Leitung. Größere Organisation — Care, Research, Billing und Secondary Use getrennt steuern. Verbund/Enterprise — föderierte Identity Authority, FHIR-Contracts, Audit Packs je Standort und kontrollierte Plattformwahl, oft On-Prem, eigene Cloud oder streng geprüfte Cloud-Services statt frei nutzbarer SaaS-Tools.

Healthcare-Governance beginnt nicht mit einem FHIR-Server oder einem Forschungskatalog. Sie beginnt mit der Entscheidung, welcher Zweck welchen Patientenidentifier bindet — Versorgung oder Forschung. Die Anforderungen sind meistens schärfer als in normalen Reporting-Landschaften: Patientendaten sind hochsensibel, Zugriffe müssen begründet und nachvollziehbar sein, Forschung braucht andere Freigaben als Versorgung, und technische Plattformen müssen Datenschutz, Informationssicherheit, Verfügbarkeit und Auditierbarkeit gemeinsam tragen.

Typische Fragen sind:

• Welcher Patient gilt in HIS, Bildarchiv und Abrechnung als dieselbe Person?; Welcher Zweck legitimiert den aktuellen Zugriff — Care, Research, Billing oder Secondary Use?; Welche Encounter- oder Episode-ID trägt Diagnose, Medikation und Befund?; Welche FHIR-Ressource darf ein Nutzer ohne Breaking Change erwarten?; Wann darf ein Research-Export Klartext verlassen, und welcher Pseudonympfad gilt?; Wer darf Care-Daten weitergeben — und wer darf ablehnen?

Wenn Care-Identifier, Research-Kohorte und FHIR-Export Zweck und Grain nicht teilen, behandelt die Station den Patienten, die Studie exportiert denselben Schlüssel, und die Abrechnung bucht denselben Kontakt unter einem anderen Fall. Das Problem ist nicht das Dashboard. Es ist der fehlende Vertrag zwischen Identität, Zweck, Encounter und Nachweis.

Gute Healthcare-Governance macht Care vs Research ausführbar — Identität, Zweck und Pseudonym am selben Patienten- und Encounter-Identifier, nicht am neuesten Forschungsantrag.

Die Serie Governance in der Healthcare-Landschaft gibt dir den Einstieg und den roten Faden für die folgenden Teile.

Ausgangslage

Die Klinik gibt Labordaten für die Versorgung frei. Später stehen dieselben Felder in einem Forschungsexport: Patientennamen im Klartext, kein neuer Zweck, kein Pseudonympfad, kein prüfbarer Ablehnungs- oder Freigabeweg. Der Research-Antrag liegt in einem separaten Ordner, das FHIR-Bundle läuft technisch weiter, und ein BI-Team sieht nur einen weiteren Datensatz.

Das Problem ist nicht „zu wenig Tooling“. Das Problem ist, dass Versorgung, Forschung, Abrechnung und Secondary Use dieselben Daten berühren, aber unterschiedliche Zwecke, Identitäten, Schutzstufen und Nachweise brauchen. Ein frei aktivierter SaaS-Export kann hier fachlich falsch sein, selbst wenn er technisch funktioniert.

Was diese Serie klärt

• Orientierung: Care vs Research, Patientenidentität, Encounter, FHIR, Billing/Secondary Use (diese Seite)
• Vertiefung: Patientenidentität und Zweckbindung steuern
• Vertiefung: Forschung und Pseudonymisierung betreiben
• Vertiefung: FHIR-Schnittstellen als Verträge führen
• Abschluss: Healthcare Nachweis und Audit Packs
• Plattformwahl: On-Prem, eigene Cloud, kontrollierte Cloud oder Spezialplattformen nach Schutzbedarf, Betrieb und Auditierbarkeit bewerten

Begriffe und Kürzel vor dem Lesen

• Purpose Binding — bindet einen Identifier-Kreis an genau einen legitimierten Zweck (Care, Research, Billing, Secondary Use); ein technisch korrekter Match ohne Zweck ist keine Freigabe.
• Care vs Research — zwei Betriebsgrenzen. Versorgung braucht Klaridentität am Bett; Forschung braucht Kohorte und Pseudonym. Dieselben Felder dürfen die Grenze nicht still überschreiten.
• Encounter / Episode — zeitlich begrenzter Versorgungskontakt bzw. Behandlungszusammenhang; fachliche Ebene für Diagnose, Medikation und Befund — nicht dasselbe wie Patient oder Abrechnungsfall.
• FHIR — Schnittstellenvertrag (Ressource, Profil, Version, Nutzer); kein selbst-erklärendes Exportformat und kein Ersatz für Zweck.
• Pseudonym — ersetzbarer Identifier für Research; Re-Identifikation nur über einen getrennten, owner-geführten Pfad — nicht die Patientennummer im Lake.
• Identity Authority — welche Quelle entscheidet, wer der Patient ist (MPI/HIS); Matching-Regel und Survivorship sind Entscheidungen, kein stiller Batch-Job.
• HIS — Hospital Information System: führendes operatives System für Aufnahme, Akte und oft Identity Authority — nicht der Research-Lake.
• Bildarchiv — Picture Archiving and Communication System: Bildarchiv; Accession und Studie, nicht die Patientenakte.
• MPI — Master Patient Index: Matching über Systeme; ein Match ohne Purpose Binding ist keine Freigabe.
• RIS — Radiology Information System: Worklist und Termin; oft Quelle stiller Excel- und BI-Feeds.
• MTRA — Medizinisch-technische Radiologieassistenz: Betrieb der Modalität; setzt Worklists um, entscheidet den Zweck nicht.
• Accession — Anforderungs- bzw. Studiennummer im Imaging; fachliche Ebene für Ops-Kennzahlen, nicht für Klaridentität.
• fachliche Ebene — Ebene, auf der eine Aussage wahr ist (Patient, Encounter, Accession, Claim) — ohne sie sind zwei Zahlen nicht dieselbe Sache.
• QVD — Qlik-Dateiextrakt; ein Feed mit Zweck, nicht „die App“.
• On-Prem / kontrollierte Cloud — Betriebsform für besonders schützenswerte Daten. Entscheidend sind Nachweis, Zugriff, Monitoring, Löschung, Verfügbarkeit und Ausstieg, nicht nur der Hosting-Ort.

Lesepfad

1. Governance in Healthcare
2. Patientenidentität und Zweckbindung steuern
3. Forschung und Pseudonymisierung betreiben
4. FHIR-Schnittstellen als Verträge führen
5. Healthcare Evidence und Audit Packs

Die Beispiele sind Lehrfälle (keine Patientendaten). Ersetzt Fall-, System- und Toolnamen durch eure HIS-, PACS-, Catalog- und Prozessquellen.

Konzept halten — Last-Säulen: PII, Verantwortung und DSDR tragen diese Kette; Access ist Nachbar (Influence, kein Parallel-Rollout). These: Konzept · Haltung: gemeinsamer Standard · Tiefe: 8 Säulen.

Orientierung — Care vs Research ohne den Klinik-Stack

Download: PDF dieser Seite · Vertriebshub: Governance als Dienstleistung · Wen rufen: Delegation

Produkte und Entscheidungen

Healthcare braucht nicht „eine klinische Datenplattform“, sondern geschnittene Produkte.

Patientenidentität und Purpose Binding

Dieses Produkt beschreibt:

• Patienten-ID und Identity Authority (MPI/HIS); Matching-Regel; Survivorship; erlaubter Zweck; Zugriffspfad; Ablehnungshoheit; Review-Datum.

Entscheidungen:

• Welche Quelle ist führend, wenn HIS und Bildarchiv widersprechen?; Welcher Zweck gilt für diesen Identifier-Kreis?; Wer darf einen Match zusammenführen oder einen Research-Zugriff ablehnen?

Encounter- und Episode-Produkt

Encounter und Episode sind nicht der Patient. Sie sind der zeitliche und fachliche Rahmen der Versorgung.

Es benötigt:

• Encounter-ID; Episode-ID; Patient-Bindung; Fachabteilung; Beginn und Ende; tragende Ereignisse (Diagnose, Medikation, Befund); Abgrenzungsregel zum Abrechnungsfall.

Entscheidungen:

• Welches fachliche Ebene trägt die klinische Aussage?; Wann endet ein Encounter, wann eine Episode?; Darf Billing denselben Kontakt unter einer anderen Fallnummer führen, ohne das Care-fachliche Ebene zu überschreiben?

FHIR-Schnittstellenvertrag

FHIR ist kein Exportknopf. Es ist ein Contract zwischen Produzent und Consumer.

Er benötigt:

• Ressource und Profil; FHIR-Version; Purpose-Umfang; Nutzer; Breaking-Change-Regel; wirksame Konfiguration; Review-Cadence.

Entscheidungen:

• Welche Felder darf dieser Nutzer zu diesem Zweck lesen?; Welche Versionsänderung ist ein Breaking Change?; Wer nimmt Nutzer-Änderungen an, und welcher Negativtest muss vorher bestehen?

Research-Export und Pseudonympfad

Research erbt nicht die Care-Identität. Der Export braucht einen eigenen Pfad.

Entscheidungen:

• Welche Kohorte und welches Ethik- oder Consent-Umfang gelten?; Welcher Pseudonymdienst ersetzt die Klaridentität?; Wer darf re-identifizieren, und wie wird der Rückweg getrennt vom Lake gehalten?; Welche bestehenden Klartext-Exports müssen inventarisiert werden?

Billing und Secondary Use

Abrechnung und Register sind keine stillen Care-Kopien. Secondary Use braucht einen eigenen Zweck.

Entscheidungen:

• Welche Encounter-Attribute dürfen in den Claim?; Wann endet der Billing-Zweck, und was darf danach nicht in Analytics bleiben?; Wer entscheidet Konflikte zwischen Care-fachliche Ebene und Abrechnungsfall?

Wo Governance hängt

Zwischen Care-Identifier und Research-Kohorte

Dieselben Labordaten sind in der Versorgung Klaridentität und in der Studie Kohortenmerkmal. Ohne Gate und Pseudonym ist der Export eine stille Zweckänderung.

Zwischen Encounter und Patient

Diagnose und Medikation hängen am Kontakt, nicht an der Lebensakte. Ein Patient-Export ohne Encounter-Grain vermischt Episoden und macht Care- und Research-Aussagen unwiederholbar.

Zwischen FHIR-Payload und Zweck

Ein gültiges Patient- oder Observation-Bundle sagt nichts über den erlaubten Consumer. Ohne Purpose-Scope im Contract ist Interoperabilität eine Weitergabefalle.

Zwischen HIS/PACS-Admin und Care Owner

Wer die FHIR-Subscription oder die Exportgruppe setzen kann, entscheidet damit nicht, ob Forschung den Klartext erhalten darf.

Zwischen Modalitäts-Export / Excel-Liste / Catalog-Asset und der BI-App

Dieselbe RIS-Worklist, MTRA-Liste oder QVD darf nicht still Betrieb, QM und Research speisen. Der Zweck hängt am Feed, nicht am Dashboard. Qlik-Assoziation und Tableau-Join sind Influence — siehe Bildgebung, Abteilungs-Excel und BI.

Zwischen Billing/Secondary Use und Care

Der Abrechnungsfall und das Register dürfen Care-Felder nicht als freie Analytics-Quelle behandeln. Secondary Use braucht eigenen Zweck, eigenen Owner und ein Ende.

Zwischen DPO-Beratung und Research-Freigabe

Der DPO bewertet Rechtsgrund und Re-Identifikationsrisiko. Die fachliche Freigabe oder Ablehnung bleibt beim Care Owner oder Research Owner — Beratung ersetzt die Entscheidung nicht.

Rollen-Mapping

Data Owner (Care)

Care Owner ist die ärztliche Leitung — Medical Director / CMO oder benannter klinischer Process Owner. Accountable für Zweck der Versorgungsprodukte, Identity Authority im Behandlungspfad, Konflikte Care vs Research vs Billing und die Ablehnung einer Weitergabe. Der Owner entscheidet nicht die Warehouse-Modellierung.

Data Owner (Research)

Research Owner ist Studienleitung, Forschungsbüro oder benannter Research-Process-Owner. Accountable für Kohorte, Ethik- oder Consent-Scope, Pseudonympfad und Re-Identifikationsfreigabe. Research erbt nicht die Care-Identität.

DPO berät

Der DPO berät zu Rechtsgrund, Zweckbindung und Re-Identifikationsrisiko. Er ist nicht Care Owner und nicht Research Owner. Genau ein fachliches Accountable entscheidet den Konflikt; der DPO dokumentiert die Beratung.

Data Steward

Klinische Dokumentation, Medizincontrolling oder Research Operations triagiert Identity-Konflikte, Purpose-Anfragen und FHIR-Consumer-Wünsche, pflegt Identifier-Listen und eskaliert widersprüchliche Systemstände.

Data Product Owner

Priorisiert Identitätsprodukt, FHIR-Contract und Research-Export. Nutzen und Lieferbarkeit — nicht die Indikation und nicht die Ethik-Auslegung.

Data Architect

Schützt Grain (Patient ≠ Encounter ≠ Episode ≠ Claim), Lineage zum Pseudonym, FHIR-Versionierung und Breaking Changes an Care- und Research-Schnittstellen.

Data Custodian

HIS/PACS-Admin, Integration und IAM setzen Purpose Binding, FHIR-Scopes, Exportjobs und Job-Pausen um. Konfigurationsmacht ist keine klinische und keine Forschungs-Autorität.

Data Consumer

Station, Radiologie, Abrechnung, Studiengruppe, Register, Analytics (nur mit Zweck). Abweichungen laufen über denselben Intake — keine stillen Spreadsheet-Kohorten und keine inoffiziellen FHIR-Feeds.

Hilfskarte — wen zuerst fragen

Das Rollen-Mapping sagt, wer entscheidet. Die Hilfskarte sagt, wen man zuerst fragt, damit die Entscheidung nicht leer ist. Hüte: Wer hilft wem an der Quelle.

Zum Owner nur bei Definitions- oder Risiko-Streit. Schema- und Join-Fragen bleiben bei Expert oder Custodian. Achtundvierzig Stunden Antwort — nicht stilles Slack.

Mini-Fall

Symptom: Eine Station gibt Laborwerte für die Behandlung frei. Zwei Wochen später stehen dieselben Felder mit Patientennamen in einem Export für eine Forschungskohorte. Der Ethik-Antrag liegt zwar im Ordner, aber niemand hat die konkrete Datennutzung daran gebunden. Der Administrator des Krankenhausinformationssystems hat lediglich eine Gruppe „Forschung“ geöffnet.

Typischer Fehlstart: Research-Portal kaufen und Katalog-Tag setzen, ohne Purpose-Entscheidung, ohne Pseudonympfad und ohne Ablehnungsweg der ärztlichen Leitung.

Vereinbarung: Purpose Binding auf Patienten- und Encounter-ID, Care-vs-Research-Prüfpunkt, Pseudonympfad, Freigabe durch Research verantwortliche Person, FHIR-Vereinbarung-Version und Inventar bestehender Klartext-Exports. Care Owner kann denselben Ask ablehnen.

Kritische Übergaben

Anti-Patterns

• Research-Export mit Klaridentität, weil der FHIR-Server es hergibt
• Encounter und Patient in einem fachliche Ebene vermischen
• HIS/Bildarchiv-Admin entscheidet Zweck, weil die Exportgruppe in der UI liegt
• Billing-Fall als stillen Secondary-Use-Pfad für Analytics nutzen
• Ethik-Ordner oder Consent-PDF ohne wirksamen Pseudonympfad als Freigabe behandeln
• FHIR-Nutzer ohne Versions- und Purpose-Stempel anbinden

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.

• Arbeitsplan — Healthcare Landscape
• Lernpfad — Healthcare Landscape
• Functions Hub — Healthcare

Lege Tag 1–20 als ersten Slice in den Plan. Spätere Wochen bleiben in derselben Instanz. Erster Kontakt für Hüte: Wer hilft wem an der Quelle.

Schritt 1: Rahmen und Entscheidung klären

Einen jüngsten Care-zu-Research-Share oder eine Billing-Wiederverwendung wählen. Patienten-IDs, Encounter/Episode, FHIR-Consumer und bestehende Exports aufnehmen. Purpose-Register mit fünf Einträgen schneiden. Care Owner und Research Owner benennen.

Schritt 2: Control und Nachweis umsetzen

Purpose Binding für ein Care-Produkt produktiv schalten. Research-Export mit Pseudonympfad einführen. Negativtest: Care-Identifier darf den Research-Pfad nicht als Klartext verlassen. FHIR-Contract für einen Consumer versionieren.

Schritt 3: Testen und Ausnahmen sichtbar machen

Eine Ablehnung durch den Care Owner gegen einen Research-Ask durchspielen. Purpose und FHIR-Version am Exporttag rekonstruieren. Einen Konflikt Billing/Secondary Use vs Care mit Owner-Entscheidung dokumentieren.

Schritt 4: Messen und begrenzt ausrollen

Aufwand und Lücken messen. Nur bestandene Muster (Care/Research-Gate, FHIR-Contract, Evidence Pack) auf eine zweite Fachabteilung oder einen zweiten Standort übertragen.

Exit-Kriterien

• Purpose Binding nennt Patient, Encounter und genau einen Zweck.
• Care Owner und Research verantwortliche Person sind getrennt; Datenschutzbeauftragte berät, entscheidet nicht.
• Research-Export hat Pseudonympfad und Inventar bestehender Klartext-Kopien.
• FHIR-Vereinbarung trägt Profil, Version, Nutzer und Zweck.
• Billing/Secondary Use ist ein eigener Zweck, kein stiller Care-Export.
• technischer Betreiber liefert Konfigurationsnachweis und bestandenen Negativtest Care→Research.

Weiterlesen

• Functions Hub — Healthcare
• Patientenidentität und Zweckbindung steuern
• Bildgebung, Abteilungs-Excel und BI
• BI-Fit und Catalog-Sichtbarkeit
• Löschung, die hält
• Audit-Nachweis betreiben

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:

1. eine Patienten-ID mit verbindlichem Grain (Person, nicht Encounter, nicht Abrechnungsfall);
2. eine Identity Authority (MPI/HIS) mit Matching-Regel und Survivorship;
3. ein Purpose Binding — genau ein legitimierter Zweck je Identifier-Kreis (Care, Research, Billing, Secondary Use);
4. einen Care Owner (ärztliche Leitung / CMO) für Semantik und Ablehnung und einen Steward für Identity-Konflikte;
5. 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

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.

• Arbeitsplan — Healthcare Landscape
• Lernpfad — Healthcare Landscape

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.

1. Identity Authority schriftlich festlegen: welche Quelle führt bei HIS- vs. PACS-Konflikt.
2. Purpose-Register mit fünf Identifier-Kreisen schneiden (Care, ein Billing-Pfad, ein ausgeschlossener Secondary Use).
3. Einen offenen Identity-Konflikt durch Steward-Triage jagen und die Owner-Entscheidung datieren.
4. 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

Ein Ethik-Ordner ist noch kein Exportvertrag. Research-Governance scheitert, wenn dieselbe Laborzeile mit Namen die Care-Grenze verlässt, weil die Studiengruppe „die Felder schon kennt“. Rekeying, Nebenjoins und ein neuer Forschungszweck ändern das Risiko — ohne dass jemand den Klartext-Pfad schließt.

Dieser Teil definiert den Mindestvertrag für Kohorte, Pseudonym und Re-Identifikation — auf dem Purpose Binding aus Teil 2.

Vorher: Patientenidentität und Zweckbindung. Weiter: FHIR-Schnittstellenverträge.

Ansatz

Jeder materielle Research-Export erhält, bevor Daten die Versorgungszone verlassen:

1. eine Kohorten-ID mit verbindlichem Grain (Studie/Protokoll, nicht Patient, nicht Encounter);
2. einen Research-Zweck plus Ethik- oder Consent-Scope — Care-Wiederverwendung und Billing sind ausgeschlossen;
3. einen Pseudonympfad (Ersetzungsdienst, Transform-Version, getrennte Key-Custody);
4. einen Research Owner für Kohorte und Re-Identifikationsfreigabe und einen Steward für Export-Triage; der DPO berät, entscheidet nicht;
5. einen Re-Identifikationsweg mit eigenem Zweck, Freigeber und Ablauf — getrennt vom Lake.

Kein Extract ohne bestandenen Negativtest gegen Klartext und Join-back.

Pseudonym-Export-Workflow

1. Kohorte und Rechtsgrund schneiden

Der Research Owner benennt Protokoll, Einschlusskriterien und Consent- oder Ethik-Scope. Care Owner kann denselben Ask ablehnen. Ein bestehender Klartext-Export wird inventarisiert, nicht still weitergedreht.

2. Trust Grenze trennen

Identität, Pseudonym und Forschungsdaten liegen in drei Kreisen. Der Schlüssel zum Klartext verlässt die Custodian-Zone nicht mit dem Extract. Survivorship aus Teil 2 gilt nicht als Research-ID.

3. Pseudonymisieren vor dem Verlassen

Transform und Feldliste sind versioniert. Namen, Adressen, Versichertennummern und Care-IDs werden ersetzt, bevor der Job die sichere Zone verlässt — nicht „im Ziel-Lake nachziehen“.

4. Control am Gate

Blockierend: Export ohne Pseudonympfad; Join auf Care-ID; Key und Extract in derselben Ablage; Zweckwechsel ohne neuen Contract. Warnend: seltene Diagnosen mit Re-Identifikationsrisiko. HIS-Admin öffnet keine Gruppe „Forschung“ als Freigabe.

5. Negativtest Join-back

Ein unabhängiger Lauf muss beweisen: Research-Tabelle plus frei verfügbare Care- oder Billing-Felder ergeben keine Klaridentität. Re-Identifikation nur über den owner-geführten Pfad. Besteht der Test nicht, bleibt der Export zu.

6. Projektende und Keys

Extracts und Keys überdauern den freigegebenen Zweck nicht. Review-Datum, Lösch- oder Rekey-Auftrag und Consumer-Bestätigung gehören zum Contract — siehe Evidence und Audit Pack.

Anwendungsbeispiel — Worklist ist keine Kohorte

Die RIS-Worklist der letzten Quartale steht in Excel und speist QM. Research kopiert dieselbe Liste als „Kohorte Lunge“, ohne neuen Zweck und ohne Pseudonym. Join-back über Accession und seltene Diagnose ist dann ein Klick.

Stop: Ops-Liste bleibt Care- oder QM-Zweck. Eine Studie braucht Kohorten-ID, Research-Zweck und getrennte Keys — nicht den MTRA-Export unter neuem Dateinamen.

Handoffs

Anti-Patterns

• Ethik-PDF oder Consent-Scan als Exportfreigabe behandeln
• Care-ID als „stabilen Research-Key“ im Lake behalten
• Re-Identifikation über Nebenjoin auf Encounter, PLZ und seltenes Labor
• HIS-Admin öffnet eine Gruppe „Forschung“, weil der Job dort liegt
• Keys und Exportdatei in derselben Freigabe ablegen

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.

• Arbeitsplan — Healthcare Landscape
• Lernpfad — Healthcare Landscape

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.

1. Einen laufenden oder letzten Care-zu-Research-Share wählen und Klartext-Kopien inventarisieren — inklusive Qlik-, Tableau- und Excel-Feeds auf dem Chaos-Pfad.
2. Kohorten-ID, Ethik-/Consent-Scope und ausgeschlossene Zwecke auf eine Seite schreiben.
3. Pseudonymdienst und Key-Custody benennen; Keys vom Extract-Pfad trennen.
4. Join-back-Negativtest einmal ausführen und das Ergebnis an den Research Owner hängen.

Weiterlesen

• Patientenidentität und Zweckbindung
• Bildgebung, Abteilungs-Excel und BI
• Healthcare Nachweis und Audit Packs

Ein gültiges FHIR-Bundle ist noch kein Vertrag. Schnittstellen-Governance scheitert, wenn „Patient“ für die Station ein Care-Profil mit Purpose Binding ist und für einen Analytics-Consumer dasselbe JSON ohne Version, ohne Consumer-Name und ohne Zweck. Profile, Terminologien und optionale Felder ändern sich unabhängig — der nächste Client bricht still.

Dieser Teil definiert den Mindestvertrag für FHIR-Ressource, Profil, Consumer und Breaking Change — nach Identität (Teil 2) und Pseudonym (Teil 3).

Vorher: Forschung und Pseudonymisierung. Weiter: Evidence und Audit Pack.

Ansatz

Jede materielle FHIR-Schnittstelle erhält vor produktivem Read oder Subscription:

1. Ressource und Profil mit verbindlichem Grain (dieses Profil, nicht „die Patient-Ressource“);
2. einen Purpose-Scope und einen benannten Consumer (Station, Abrechnung, Studie, Register);
3. FHIR-Version, Terminologie-Stand und eine Breaking-Change-Regel;
4. einen Interface Owner (Care oder Research, je Zweck) für Semantik und einen Steward für Consumer-Triage; Integration/HIS-Admin ist Custodian, nicht Owner;
5. einen Ausnahmeweg für temporäre Clients mit Freigeber und Ablaufdatum.

Kein Consumer ohne Versions- und Purpose-Stempel.

FHIR-Contract-Workflow

1. Ressource, Profil und Consumer benennen

Steward und Owner legen fest, welche Ressource welches Profil welcher Consumer zu welchem Zweck lesen darf. Observation für Care ist nicht Observation für die Kohorte. Identity aus Teil 2 und Pseudonym aus Teil 3 hängen am Contract, nicht am Server-Default.

2. Zweck in die Schnittstelle schreiben

Purpose-Scope sitzt im Contract, nicht nur in der App-Dokumentation. Ein Research-Client erbt nicht den Care-Scope, nur weil das Bundle gültig ist.

3. Version und Breaking Change

Kardinalität, Pflichtfelder und Codesystem-Wechsel sind Breaking, wenn ein bestehender Consumer ohne Migration bricht. Der Owner nimmt die Änderung an; der Custodian veröffentlicht sie nicht still.

4. Control am Durchsetzung-Punkt

Blockierend: Payload außerhalb Profil; Client ohne Consumer-ID; Zweck nicht im Scope; Subscription ohne Contract-Version. Warnend: ungenutzte optionale Felder. Validierung läuft an der Schnittstelle, nicht im Ziel-Warehouse.

5. Negativtest Out-of-Contract

Ein unabhängiger Lauf muss beweisen: ein Bundle mit falschem Zweck, fremdem Consumer oder Breaking-Feld wird abgewiesen. Ein Research-Client darf das Care-Patient-Profil nicht ungekürzt ziehen. Besteht der Test nicht, bleibt die Subscription zu.

6. Consumer-Kommunikation

Jede materielle Versionsänderung braucht Impact, Frist und Bestätigung. Ohne Notice gibt es keinen Go-Live — der Evidence-Pack in Teil 5 hängt Contract-Version und Testergebnis zusammen.

Anwendungsbeispiel — valides Bundle, falscher Consumer

Ein Research-Client ruft Patient ungekürzt, weil das Care-Profil technisch valide ist. Integration sieht HTTP 200 und schliesst das Ticket.

Stop: Consumer-ID und Purpose-Scope stehen im Contract. Out-of-Contract bleibt geschlossen — Gültigkeit des Bundles ist kein Zweck.

Handoffs

Anti-Patterns

• „Was der FHIR-Server heute zurückgibt“ als Semantik behandeln
• Nutzer ohne Versions- und Purpose-Stempel anbinden
• Breaking Change nachts deployen und Tickets als Notice zählen
• Care-Profil an einen Research-Client durchreichen, weil das Bundle valide ist
• Integration-Admin entscheidet Feldbedeutung, weil die Subscription bei ihm liegt
• FHIR-Profil als Ersatz für den MRT-CSV- oder RIS-Exportpfad behandeln — fachliche Ebene sitzt in Exportdatei-fachliche Ebene und Abteilungs-Listen; Engine-Fit und Catalog-Sichtbarkeit in BI-Fit und Catalog

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.

• Arbeitsplan — Healthcare Landscape
• Lernpfad — Healthcare Landscape

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.

1. Einen produktiven Consumer wählen und Profil, FHIR-Version, Zweck und Kontakt auf eine Contract-Seite schreiben.
2. Breaking-Change-Regel in zwei Sätzen festlegen (was bricht, wer annimmt, welche Frist).
3. Validation am Durchsetzung-Punkt scharf stellen: Client ohne Consumer-ID wird abgewiesen.
4. Out-of-Contract-Negativtest einmal fahren (falscher Zweck oder fremdes Feld) und das Ergebnis datieren.

Weiterlesen

• Forschung und Pseudonymisierung
• BI-Fit und Catalog-Sichtbarkeit
• Healthcare Nachweis und Audit Packs

Ein Screenshot aus HIS, IAM oder dem Ethik-Ordner ist noch kein Nachweis. Audit-Governance scheitert, wenn Aufsicht am Stichtag fragt und Teams Policies, Tickets und Labor-Exports zusammensuchen — ohne Purpose, ohne wirksame Konfiguration, ohne den Negativtest, der Care vom Research-Pfad trennt.

Dieser Teil schließt die Serie: Evidence Packs machen Identität, Pseudonym und FHIR zum Stichtag rekonstruierbar.

Vorher: FHIR-Schnittstellenverträge.

Ansatz

Jedes materielle Healthcare-Control erhält vor Audit- oder Aufsichtsfrage:

1. eine Pack-ID mit Grain (benanntes Produkt: Identity, Research-Export oder FHIR-Consumer) und Gültigkeitsfenster;
2. den Zweck der Entscheidung, der bewiesen werden soll — nicht „Healthcare allgemein“;
3. eine Nachweiskette Entscheidung → wirksame Konfiguration → Test → Ausnahme, über stabile Identifier (Patient/Encounter, Kohorte, Contract-Version);
4. einen Control Owner für Vollständigkeit und einen Custodian für Sammlung; Care Owner und Research Owner bleiben fachlich accountable;
5. einen Ausnahmeweg für fehlende Artefakte mit Remediation Owner und Ablaufdatum.

Kein Pack ohne bestandene Rekonstruktion durch jemanden, der den Job nicht gebaut hat.

Audit-Pack-Workflow

1. Einen regulierten Vorgang wählen

Zugriff, Research-Export oder FHIR-Consumer — nicht „die Plattform“. Der Owner nennt die Entscheidung, die am Stichtag gelten soll (Purpose Binding, Pseudonym-Gate oder Interface-Version).

2. Identifier der Serie binden

Pack-Zeilen tragen Patienten- oder Encounter-ID (Teil 2), Kohorten- und Transform-Version (Teil 3) oder FHIR-Contract-Version (Teil 4). Betriebslogs ohne diese IDs gehören nicht ins Pack. Encounter und Claim dürfen nicht als eine Zeile erscheinen — Secondary Use braucht den eigenen Identifier aus Teil 2.

3. Am Gate zusammenstellen, nicht nachträglich

Pack-Zusammenstellung hängt an Review- und Export-Gates. Last-Minute-PDFs aus Screenshots sind kein Nachweis. Der Custodian exportiert die wirksame Konfiguration am Tag der Entscheidung.

4. Control: Frische und Fenster

Blockierend: Pack ohne Zweck, ohne Config-Export, ohne Testdatum oder mit abgelaufenem Fenster. Warnend: offene Ausnahmen nahe am Ablauf. Quartalsweise Frischeprüfung, bevor ein zweiter Standort dasselbe Muster übernimmt.

5. Negativtest Rekonstruktion

Ein unabhängiger Reviewer (nicht der Job-Owner) muss Entscheidung → Config → Negativtest Care→Research oder Out-of-Contract ohne mündliche Hilfe finden. Scheitert die Kette, ist das Pack unvollständig — unabhängig davon, wie viele Screenshots im Ordner liegen.

6. Ausnahme schließen oder befristen

Fehlende Artefakte tragen Remediation Owner und Datum. Eine dauerhaft „mündlich erklärte“ Lücke ist kein Control. Standortvergleich nur auf bestandenen Packs.

Handoffs

Anti-Patterns

• Screenshots und Ethik-Ordner als Stichtagsnachweis sammeln
• Pack erst bauen, wenn die Aufsicht den Termin nennt
• Betriebslogs ohne Purpose-, Kohorten- oder Vereinbarung-ID ins Pack legen
• Job-verantwortliche Person erklärt die Kette mündlich, statt dass ein Dritter sie findet
• HIS-Admin gilt als kontrollverantwortliche Person, weil er die Exports drücken kann

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.

• Arbeitsplan — Healthcare Landscape
• Lernpfad — Healthcare Landscape

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.

1. Einen Vorgang wählen (ein Research-Export oder ein FHIR-Consumer) und Pack-ID plus Stichtag vergeben.
2. Die Kette auf eine Seite legen: Owner-Entscheidung, Config-Export, letzter Negativtest, offene Ausnahme.
3. Einen unabhängigen Reviewer die Seite ohne Gespräch rekonstruieren lassen und die Lücken datieren.
4. Ein abgelaufenes oder mündliches Artefakt befristen oder schließen, bevor ein zweiter Standort das Muster kopiert.

Weiterlesen

• Audit-Nachweis betreiben
• Löschung, die hält
• Bildgebung, Abteilungs-Excel und BI
• BI-Fit und Catalog-Sichtbarkeit