+150 XP

Ein Operating Model für Data Governance in Pharma aufbauen

# Ein Operating Model für Data Governance in Pharma aufbauen

Der Aufhänger: zwei Datensätze, zwei sehr unterschiedliche Owner

Stellen Sie sich die Sitzung eines Data Governance Council in einem mittelgroßen Pharmaunternehmen im Jahr 2026 vor. Punkt eins: Wer besitzt die HCP-Engagement-Daten (Health Care Professional), die entstehen, wenn ein Vertriebsmitarbeiter ein Gespräch mit einem Kardiologen im CRM (Customer Relationship Management System) dokumentiert? Punkt zwei: Wer besitzt die Biomarker-Daten aus den Blutproben einer Phase-II-Studie, die jetzt in einem Laborinformationssystem liegen?

Das klingt nach ähnlichen „Wem gehören die Daten“-Fragen. Sie sind es nicht. Die HCP-Engagement-Daten werden gemeinsam von Commercial (das sie für Targeting braucht) und Medical Affairs (das sie für die Compliance-Prüfung werblicher Interaktionen braucht) beansprucht. Die Biomarker-Daten werden von R&D beansprucht (für die Analyse des primären Endpunkts) und zunehmend von Commercial (das frühe Biomarker-Signale für die Launch-Planung will).

Aufgabe des Council ist es nicht, einen einzigen „Owner“ im IT-Sinne zu bestimmen. Es geht darum, Data Stewardship (die operative Verantwortung für Datenqualität, Zugriffsregeln und Lifecycle) getrennt von Data Ownership (die Accountability für die Nutzung der Daten) zuzuweisen und beides in einer Policy zu dokumentieren, gegen die das ganze Unternehmen auditiert werden kann.

Warum Pharma ein formales Operating Model braucht und nicht nur ein Policy-PDF

Pharma liegt im Schnittpunkt der strengsten Datenschutzregime und der strengsten Produktregulierung. Ein Data Governance Operating Model ist die konkrete Struktur (Rollen, Gremien, Tools, Review-Zyklen), die eine Policy im Alltag durchsetzbar macht.

Drei regulatorische Kräfte machen das nicht optional:

  • GDPR (General Data Protection Regulation, EU, gültig ab 2018) regelt alle personenbezogenen Daten von EU-Patienten oder HCPs, nach vielen Auslegungen auch pseudonymisierte Studiendaten.
  • HIPAA (Health Insurance Portability and Accountability Act, USA, 1996) regelt Protected Health Information (PHI) bei Covered Entities und ihren Business Associates, relevant, wenn Pharmaunternehmen Real-World-Daten von Gesundheitssystemen erhalten.
  • 21 CFR Part 11 (US-FDA-Regulierung zu elektronischen Aufzeichnungen und Signaturen) regelt die Integrität der Daten, die regulatorische Einreichungen stützen. Governance-Fehler bei Studiendaten können also eine Zulassung gefährden, nicht nur ein Datenschutzbußgeld auslösen.

Nehmen Sie die Clinical Trials Regulation (536/2014) der EU und die Data-Integrity-Guidance der FDA dazu, und Sie sehen, warum „Wer darf diesen Datensatz anfassen, und wie belegen wir das“ eine Frage für den Vorstand ist und nicht nur ein IT-Ticket.

Die Kernrollen: wer tatsächlich was macht

Ein funktionierendes Operating Model braucht benannte Rollen, nicht nur ein Policy-Statement. Die übliche Pharma-Struktur sieht so aus:

Data Owner: Eine leitende Führungskraft aus dem Business (z. B. VP Clinical Operations, VP Commercial Analytics), die für die Daten einer Domäne accountable ist. Owner genehmigen Zugriffsregeln und geben neue Nutzungen frei.

Data Steward: Eine operative Rolle (oft in der Fachfunktion verankert, nicht in der IT), die Datenqualität, Metadaten und Zugriffsanfragen im Tagesgeschäft steuert. Ein Clinical Data Steward stellt sicher, dass Studiendatensätze vor dem Database Lock sauber sind; ein Commercial Data Steward stellt sicher, dass HCP-Datensätze dedupliziert sind und Consent-Flags aktuell.

Data Governance Council: Ein funktionsübergreifendes Gremium, typischerweise mit R&D, Medical, Commercial, Legal, Privacy/Compliance und IT, das monatlich oder quartalsweise tagt, um Konflikte zu klären (wie im HCP-vs-Biomarker-Beispiel oben) und neue Data-Sharing-Agreements zu genehmigen.

Data Protection Officer (DPO): Für viele Pharmaunternehmen eine gesetzlich vorgeschriebene Rolle unter der GDPR, unabhängig von den operativen Data Ownern, verantwortlich für die Aufsicht über die Datenschutz-Compliance.

Qualified Person / Data Integrity Lead: In GxP-Kontexten (Good Practice, z. B. Good Clinical Practice, Good Manufacturing Practice) eine Rolle, die dafür verantwortlich ist, dass Daten für regulatorische Einreichungen den ALCOA+-Prinzipien entsprechen (Attributable, Legible, Contemporaneous, Original, Accurate, plus Complete, Consistent, Enduring, Available).

Zugriffsstufen: nicht jeder bekommt die gleiche Sicht

Ein praxistaugliches Governance-Modell definiert Zugriffsstufen nach Rolle und Zweck, nicht nach Hierarchieebene. Eine verbreitete Struktur:

| Stufe | Wer | Beispiel für Zugriff |

|---|---|---|

| Tier 1: Identifiziert | Studienpersonal am Standort, behandelnde Ärzte | Vollständige Patientenidentifikatoren, nötig für Safety-Follow-up |

| Tier 2: Pseudonymisiert | Biostatistiker, Data Manager | Subject-IDs ersetzen Namen; Re-Identifikation nur über einen separaten Schlüssel möglich |

| Tier 3: Aggregiert/De-identifiziert | Commercial Analytics, Market Access | Auswertungen auf Kohortenebene, kein Re-Identifikationsrisiko auf Individualebene |

| Tier 4: Öffentlich/Synthetisch | Externe Partner, akademische Kooperationspartner | Synthetische oder vollständig anonymisierte Datensätze |

Diese Abstufung macht ein Data-Sharing-Agreement (DSA) durchsetzbar. Ein DSA ist ein Vertrag, der festlegt, welche Daten zwischen zwei Parteien fließen (etwa einem Pharmaunternehmen und einer Universitätsklinik, die eine Real-World-Evidence-Studie durchführt), in welcher Stufe, zu welchem Zweck und für wie lange. Jedes DSA sollte explizit auf eine dieser Stufen verweisen, statt vage von „de-identifizierten Daten“ zu sprechen, ohne den verwendeten Standard zu definieren (HIPAA Safe Harbor und die Anonymisierungs-Guidance der EMA unterscheiden sich im Detail).

Ein konkretes Beispiel: eine Datenanfrage routen

Angenommen, ein Market-Access-Team fragt HCP-Verordnungsmuster verknüpft mit Real-World-Outcome-Daten an, um ein Value Dossier für Kostenträger zu bauen. Der Governance-Workflow:

1. Anfrage geht an den zuständigen Data Steward (Commercial Analytics).

2. Der Steward prüft: Braucht das Tier 2 (pseudonymisiert, DPO-Freigabe nötig) oder reicht Tier 3 (aggregiert) für den Business-Bedarf?

3. Wird Tier 2 tatsächlich benötigt, eskaliert die Anfrage an das Data Governance Council mit dokumentierter Zweckbindung (GDPR-Grundsatz aus Artikel 5: Daten, die für einen Zweck erhoben wurden, dürfen nicht frei umgenutzt werden).

4. Legal prüft gegen bestehende DSAs mit der Datenquelle (z. B. einem Claims-Data-Anbieter wie IQVIA oder einem Gesundheitssystem).

5. Zugriff wird mit Ablaufdatum gewährt und in einem Access Registry protokolliert, später auditierbar.

Ein einfaches Access-Control-Snippet, das die Logik illustriert, die ein Governance-Team in einem Access-Request-System kodifizieren könnte:

python
def evaluate_request(purpose, data_tier_requested, requester_role):
    if data_tier_requested == "Tier1_Identified" and requester_role not in ["trial_site_staff", "treating_physician"]:
        return "DENY: identified data restricted to clinical care roles"
    if purpose not in APPROVED_PURPOSES[data_tier_requested]:
        return "ESCALATE: purpose not pre-approved, route to Governance Council"
    return "APPROVE: log access, set 12-month expiry"

Das ist illustrative Logik, keine echte Compliance-Engine, aber es zeigt, wie Governance-Entscheidungen in Systemregeln überführt werden, statt nur in einem Policy-Dokument zu existieren.

Audits und Kontrollen: belegen, dass das Modell funktioniert

Ein Governance-Modell ist nur so gut wie sein Audit Trail. Praktische Kontrollen, die Pharma-Teams durchführen:

  • Consent-Audits: Quartalsweise Stichproben von HCP- und Patientendatensätzen, um zu bestätigen, dass Consent-Flags zur tatsächlichen Datennutzung passen (zentral unter dem Accountability-Grundsatz der GDPR).
  • Reviews der Access Logs: Wer hat im letzten Quartal auf Tier-1/2-Daten zugegriffen, und war jeder Zugriff einem genehmigten Zweck zuzuordnen?
  • Data-Lineage-Checks: Lässt sich jede Zahl in einer regulatorischen Einreichung bis zum Rohdatensatz zurückverfolgen (eine Kernanforderung aus Part 11 / ALCOA+)?
  • DSA-Ablaufprüfungen: Laufen Data-Sharing-Agreements über ihr vertragliches Enddatum hinaus weiter?

Die ICO-Guidance zu Data Protection by Design aus Großbritannien ist eine gute kostenlose Referenz, um diese Audits auch außerhalb Großbritanniens zu strukturieren, da viele Pharmaunternehmen einen globalen Standard anwenden.

Wissenscheck

1. Was ist im beschriebenen Pharma-Operating-Model für Data Governance der zentrale Unterschied zwischen Data Stewardship und Data Ownership?

2. Warum kann das Governance Council einem Datensatz wie HCP-Engagement-Daten nicht einfach einen einzigen „Owner“ zuweisen, so wie IT-Systeme üblicherweise einen System-Owner benennen?

3. Warum ist in Pharma ein formales Operating Model (Rollen, Gremien, Tools, Review-Zyklen) über eine schriftliche Data-Governance-Policy hinaus notwendig?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE zutreffenden Antworten dazu, warum Biomarker-Daten aus einer Phase-II-Studie eine Governance-Komplexität erzeugen, die den HCP-Engagement-Daten ähnelt, aber von ihnen abweicht.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE zutreffenden Antworten zu den regulatorischen Kräften, die ein formales Data Governance Operating Model für Pharmaunternehmen nicht optional machen.

Wählen Sie alle richtigen Antworten aus.

Wo das in der Praxis auseinanderfällt

Der häufigste Fehlermodus ist nicht böse Absicht, sondern Ambiguität. Commercial-Teams nutzen Biomarker-Signale aus Studien für Launch-Targeting wieder, ohne erneut zu prüfen, ob der ursprüngliche Patienten-Consent eine sekundäre kommerzielle Nutzung abdeckte. R&D-Teams sitzen auf Real-World-Daten, die Medical Affairs für ein Safety-Signal-Review braucht, weil beim Onboarding der Datenquelle niemand formal die Stewardship zugewiesen hat.

Gute Governance Councils lösen das, indem sie beim Intake ein Data Use Case Register verlangen: Jede neue Datenquelle erhält einen dokumentierten Owner, Steward, zulässige Zwecke und eine Stufe, bevor der erste Analyst sie anfasst, nicht erst, wenn ein Problem auftaucht.

Wichtigste Erkenntnisse

  • Trennen Sie Data Ownership (Accountability für die Nutzung) von Data Stewardship (operative Qualität und Zugriffsmanagement); Konflikte in Pharma entstehen meist daraus, dass beides vermischt wird.
  • Bauen Sie Zugriff über definierte Stufen (identifiziert, pseudonymisiert, aggregiert, synthetisch) und verlangen Sie, dass jedes Data-Sharing-Agreement explizit auf eine Stufe verweist, nicht auf vage Begriffe wie „de-identifiziert“.
  • Verankern Sie das Operating Model in benannten Regularien: GDPR und HIPAA für Datenschutz, 21 CFR Part 11 und ALCOA+ für Datenintegrität bei regulatorischen Einreichungen.
  • Führen Sie wiederkehrende Audits durch (Consent-Checks, Reviews der Access Logs, Data-Lineage-Nachverfolgung, DSA-Ablaufprüfungen), statt Governance als einmalige Policy-Freigabe zu behandeln.
  • Nutzen Sie ein funktionsübergreifendes Data Governance Council, um Ownership-Konflikte (R&D vs. Commercial vs. Medical) zu klären, bevor sie zu Compliance-Vorfällen werden.

Verwandte Artikel

Aktuelle Blogartikel, die auf dieser Lektion aufbauen.