Ein Operating Model für Data Governance in Pharma aufbauen
# Ein Operating Model für Data GovernanceData GovernanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.Vollständige Definition ansehen → in Pharma aufbauen
Der Aufhänger: zwei Datensätze, zwei sehr unterschiedliche Owner
Stellen Sie sich die Sitzung eines Data GovernanceData GovernanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.Vollständige Definition ansehen → 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 CRMCRMCustomer Relationship Management: software and strategy to manage and analyse customer interactions throughout their lifecycle.Vollständige Definition ansehen → (Customer Relationship ManagementCustomer Relationship ManagementCustomer Relationship Management: software and strategy to manage and analyse customer interactions throughout their lifecycle.Vollständige Definition ansehen → 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 StewardshipData StewardshipA business-side owner responsible for the quality, consistency and appropriate use of data in their domain.Vollständige Definition ansehen → (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 GovernanceData GovernanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.Vollständige Definition ansehen → 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 kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →ö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. VPVPA clear statement of the benefits your product delivers, the problems it solves and why customers should choose you over alternatives.Vollständige Definition ansehen → Clinical Operations, VPVPA clear statement of the benefits your product delivers, the problems it solves and why customers should choose you over alternatives.Vollständige Definition ansehen → Commercial Analytics), die für die Daten einer Domäne accountable ist. Owner genehmigen Zugriffsregeln und geben neue Nutzungen frei.
Data StewardData StewardA business-side owner responsible for the quality, consistency and appropriate use of data in their domain.Vollständige Definition ansehen →: 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 StewardData StewardA business-side owner responsible for the quality, consistency and appropriate use of data in their domain.Vollständige Definition ansehen → stellt sicher, dass Studiendatensätze vor dem Database Lock sauber sind; ein Commercial Data StewardData StewardA business-side owner responsible for the quality, consistency and appropriate use of data in their domain.Vollständige Definition ansehen → 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 StewardData StewardA business-side owner responsible for the quality, consistency and appropriate use of data in their domain.Vollständige Definition ansehen → (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 GovernanceData GovernanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.Vollständige Definition ansehen → 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 kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnte:
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?
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.
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 StewardshipData StewardshipA business-side owner responsible for the quality, consistency and appropriate use of data in their domain.Vollständige Definition ansehen → (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 GovernanceData GovernanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.Vollständige Definition ansehen → 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.