Governance in Healthcare

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