.png)
Fragt man einen Vizepräsidenten für Medical Affairs, ob seine Organisation ein „Problem mit der Datenintegration“ habe, antworten die meisten ohne zu zögern mit Ja. Fragt man jedoch, worin dieses Problem konkret bestehe, fallen die Antworten sehr unterschiedlich aus – unübersichtliche HCP-Datensätze, doppelte KOL-Einträge, ein CRM, dem niemand vertraut. Das sind echte Probleme. Sie sind jedoch nicht dasjenige, das dem Bereich Medical Affairs den größten strategischen Wert kostet.
Das größere Problem ist weniger offensichtlich: Ihr Außendienstteam, Ihre Beiräte und Ihre Programme zur Patientenbindung generieren gerade jetzt jeweils echte, evidenzrelevante Erkenntnisse, und in den meisten Organisationen haben diese drei Quellen keinen Einblick in die anderen. Dies ist das Bindeglied, das sie miteinander verbindet – nicht durch den Vorschlag einer neuen Datenbank, sondern indem es benennt, was Integration tatsächlich erfordert, sobald die Erkenntnisse selbst das sind, was es wert ist, miteinander verknüpft zu werden, und nicht nur die Datensätze, die beschreiben, wer sie generiert hat.
Was „Datenintegration“ für den Bereich Medical Affairs bedeutet – und was nicht
Datenintegration im Kontext von Medical Affairs ist die Praxis, Erkenntnisse zu verknüpfen, die über verschiedene Funktionen und Kanäle hinweg generiert werden – Interaktionen vor Ort, Beiräte, Patientenbindung, externe Real-World-Daten –, sodass Muster über die Quellen hinweg sichtbar werden, anstatt in dem Tool gefangen zu bleiben, das sie als Erstes erfasst hat.
Das ist ein anderes Problem als das Stammdatenmanagement (Master Data Management, MDM), das die Entitätsauflösung löst: Es stellt sicher, dass „Dr. Sarah Chen vom Memorial Hospital“ in Ihrem CRM, Ihren Abrechnungsdaten und Ihrer Publikationsdatenbank als dieselbe Person erkannt wird. MDM ist wichtig, und die meisten Organisationen verfügen bereits über einen entsprechenden Arbeitsablauf. Es sagt Ihnen jedoch allein nicht, dass ein Anliegen, das ein KOL im letzten Quartal in einem Beirat vorgebracht hat, und ein Anliegen, das ein anderer KOL im letzten Monat gegenüber einem MSL vor Ort geäußert hat, dieselbe Evidenzlücke beschreiben. Das ist ein semantisches Problem, kein Problem der Identitätsauflösung – und genau darum geht es in diesem Beitrag eigentlich.
Es lohnt sich auch, klar zu sagen, was dies nicht ist: ein Plädoyer dafür, bestehende Systeme zu reißen. Der Großteil der Fragmentierung, mit der sich der Bereich Medical Affairs auseinandersetzen muss, ist kein technologisches Versagen. Es ist das Fehlen eines gemeinsamen Ansatzes zur Klassifizierung von Erkenntnissen, sobald diese erfasst wurden – unabhängig davon, welches System sie erfasst hat.
Die vier Datenebenen, die jede Medical-Affairs-Organisation generiert
Nahezu jede Medical-Affairs-Organisation generiert bereits vier unterschiedliche Ebenen von Erkenntnissen. Das Problem ist nicht eine fehlende Ebene – sondern dass diese Ebenen selten miteinander kommunizieren.
| Ebene | Wer generiert sie | Wo sie typischerweise gespeichert ist | Was geht verloren, wenn sie isoliert sind |
|---|---|---|---|
| Externe RWD | Elektronische Patientenakten, Abrechnungsdaten, Register, Wearables | Von HEOR oder einem Data-Science-Team freigegeben | Wird nie mit den Echtzeit-Erfahrungen aus der Praxis abgeglichen |
| Erkenntnisse aus dem Außendienst / von MSLs | MSLs in Gesprächen mit medizinischen Fachkräften und KOLs | Freitextfelder im CRM, Reiseberichte | In unstrukturierten Notizen verborgen; Muster über Regionen hinweg nicht erkennbar |
| Einblicke aus dem Beirat | Strukturierte, vergütete Expertenmeinungen | Eine speziell auf diesen Zweck zugeschnittene Plattform für Beiräte | Einmal in einem PDF-Bericht gelesen, nie mit Erkenntnissen aus der Praxis zum gleichen Thema verglichen |
| Einblicke von Patienten / PRO | Patientenberater, PRO-Instrumente | Berichte zur Patientenbeteiligung oder kommerzielle Berichte | Werden als Stimmungsbild und nicht als Evidenz behandelt; erreichen selten MSLs oder HEOR |
Jede Ebene erscheint für sich betrachtet recht gut organisiert. Die Kosten zeigen sich in den Lücken zwischen ihnen. Ein Real-World-Evidence-Programm, das sich ausschließlich auf externe RWD stützt, lässt das „Warum“ vermissen, das Erkenntnisse aus der Praxis liefern würden. Ein virtueller Beirat, der scharfsinnige klinische Erkenntnisse liefert, hat keine Möglichkeit zu überprüfen, ob drei MSLs im letzten Monat dasselbe gehört haben. Ein patientenzentriertes Einbindungsprogramm, das echte PRO-Daten sammelt, hat keinen Weg, den MSL zu erreichen, der nächste Woche mit einem HCP einen wissenschaftlichen Austausch über dieselbe Symptombelastung führt.
Keine dieser Lücken wird als Fehlermeldung angezeigt. Sie zeigen sich vielmehr in einer Studie, deren Umfang erst acht Monate später festgelegt wird, als es möglich gewesen wäre, weil das Muster, das eine frühere Festlegung gerechtfertigt hätte, auf drei Systeme verteilt war, die ihre Erkenntnisse nie miteinander verglichen haben.
Was die tatsächliche Integration dieser Ebenen erfordert
Die Behebung dieses Problems beginnt nicht mit einem Data-Warehouse-Projekt. Sie beginnt mit einer gemeinsamen Taxonomie – einer einheitlichen Methode zur Kennzeichnung von Erkenntnissen, unabhängig von der Quelle, sodass eine Feldbeobachtung und eine Erkenntnis eines Beirats zum gleichen Thema in derselben Kategorie landen.
Eine funktionierende Taxonomie benötigt vier Dimensionen, die über alle Ebenen hinweg konsistent angewendet werden:
- Therapeutischer Bereich – der Krankheitszustand oder die Produktlinie, auf die sich die Erkenntnis bezieht.
- Art der Evidenzlücke – um welche Art von Fragestellung es sich handelt (Wirksamkeit, Sicherheit, Therapietreue, Zugang, ungedeckter Bedarf).
- Quelle der Stakeholder – HCP-KOL, Patientenberater, MSL-Feldbeobachtung, externe RWD.
- Vertrauensgrad und Häufigkeit – wie viele unabhängige Quellen dies angesprochen haben und wie direkt.
Dies richtig zu handhaben, ist ebenso sehr eine Frage der Governance wie eine technische. Die Taxonomie benötigt einen funktionsübergreifenden Verantwortlichen – in der Regel gemeinsam Medical Affairs und HEOR, wobei die Compliance-Abteilung festlegt, wie Erkenntnisse aus Patienten- und HCP-Quellen unterschiedlich behandelt werden. Ohne einen benannten Verantwortlichen geraten Taxonomien aus dem Ruder: Eine Region kennzeichnet Bedenken hinsichtlich der „Therapietreue“ anders als eine andere, und der Musterabgleich, der diese gesamte Maßnahme rechtfertigte, bricht still und leise zusammen.
Die Frage nach der Plattform ist wichtig, aber sie ist gegenüber der Frage nach der Taxonomie zweitrangig. Ein CRM für den Bereich Medical Affairs, das eine einheitliche Taxonomie für Außendienst, Beirat und Patientenerkenntnisse anwendet, macht das Muster automatisch sichtbar. Die gleichen vier Datenschichten, die in vier gut geführten, aber voneinander getrennten Tools gespeichert sind, werden das Muster niemals zutage fördern, egal wie gut jedes einzelne Tool auch sein mag. Hier wird auch der wissenschaftliche Austausch zu einer echten Datenquelle und nicht nur zu einer Compliance-Kategorie – jedes regelkonforme Gespräch zwischen MSL und KOL ist eine potenzielle Erkenntnis und sollte mit derselben Sorgfalt erfasst werden wie alles andere.
So sieht es in der Praxis aus
Fiktives zusammengesetztes Beispiel. Ein mittelgroßes, auf Immunologie spezialisiertes Biotech-Unternehmen – nennen wir es Solvane Therapeutics – vereinheitlicht seine Insight-Taxonomie über drei zuvor getrennte Systeme hinweg: seine Beiratplattform, sein MSL-CRM und eine Tabellenkalkulation, die sein Patient-Engagement-Team zur Protokollierung von Beratergesprächen nutzte. Bereits im ersten Quartal bringt eine taxonomiegestützte Abfrage eine Gruppe von vierzehn Erkenntnissen zutage – sechs vor Ort erfasste, fünf aus einem Patientenbeirat, drei aus einem HCP-Beirat –, die alle dasselbe bisher unberücksichtigte Problem im Zusammenhang mit Begleiterkrankungen beschreiben; keine davon war zuvor miteinander in Verbindung gebracht worden, da sie an drei verschiedenen Orten gespeichert waren. Die Abteilung Medical Affairs konzipiert direkt auf der Grundlage dieses Clusters eine Real-World-Evidence-Studie. Die Erkenntnis war die ganze Zeit vorhanden. Was sich geändert hat, war, ob die Organisation sie als ein einziges Signal statt als drei voneinander unabhängige Signale erkennen konnte.
Sehen Sie in der Praxis, wie eine Taxonomie über Felddaten, Beiratsmeinungen und Patientenerkenntnisse hinweg funktioniert – Erfassung, Tagging und die quellenübergreifende Musteransicht auf einer Plattform.
Erleben Sie TikaInsights in einer 20-minütigen PräsentationWichtige Fragen, die Führungskräfte im Bereich Medical Affairs zur Datenintegration stellen
Ist das nicht einfach nur Master Data Management unter einem anderen Namen?
Nein – sie lösen unterschiedliche Probleme, und in der Regel werden beide benötigt. MDM beantwortet die Frage: „Ist dies derselbe HCP-Datensatz in allen unseren Systemen?“ Die Insight-Integration beantwortet die Frage: „Beschreiben diese drei unterschiedlichen Erkenntnisse aus drei verschiedenen Quellen dieselbe zugrunde liegende Evidenzlücke?“ Ein Unternehmen kann über ein hervorragendes MDM verfügen und dennoch keinerlei Einblick in quellenübergreifende Erkenntnismuster haben, da MDM nicht dafür ausgelegt ist.
Wo sollten wir anfangen, wenn wir zum ersten Mal Erkenntnisse integrieren?
Beginnen Sie mit der Taxonomie, nicht mit der Technologie. Definieren Sie Ihre Kategorien für Evidenzlücken, die Struktur der Therapiebereiche und die Tags für Stakeholder und Quellen, bevor Sie eine Plattform evaluieren. Die meisten Integrationsprojekte, die mit dem Kauf eines Tools beginnen, führen letztendlich dazu, dass Daten in eine Struktur gezwängt werden, auf die sich niemand geeinigt hat; wenn Sie mit der Taxonomie beginnen, wird die Tool-Entscheidung viel einfacher, da Sie genau wissen, was das Tool unterstützen muss.
Wer sollte für die gemeinsame Taxonomie verantwortlich sein?
In der Praxis funktioniert eine gemeinsame Verantwortung von Medical Affairs und HEOR am besten, wobei die Compliance-Abteilung speziell in die Frage einbezogen wird, wie Erkenntnisse aus Patienten- und Gesundheitsfachkräftequellen unterschiedlich gekennzeichnet und behandelt werden. Eine Taxonomie, die einer einzelnen Funktion untersteht, neigt dazu, sich an den Prioritäten dieser Funktion auszurichten und verliert für die anderen an Relevanz.
Wirft die Integration von Erkenntnissen aus Beratungsgremien und von Patienten in dasselbe System Compliance-Bedenken auf?
Dies erfordert Sorgfalt, aber keine Vermeidung. Daten von Fachkräfte-Beiräten, Erkenntnisse von MSLs aus dem Außendienst und Erkenntnisse von Patienten unterliegen jeweils unterschiedlichen Anforderungen hinsichtlich Einwilligung, Offenlegung und Handhabung. Die Vereinheitlichung der Taxonomie, die die Erkenntnisse klassifiziert, bedeutet nicht, diese Unterscheidungen zu verwischen – das System muss die quellspezifische Compliance-Behandlung beibehalten und gleichzeitig einen thematischen Vergleich der Inhalte ermöglichen.
Woher wissen wir, ob uns die Fragmentierung tatsächlich messbare Kosten verursacht?
Betrachten Sie die „Time-to-Scope“: Wie lange dauert es vom ersten Hinweis auf eine Evidenzlücke irgendwo in Ihrem Unternehmen bis zu dem Zeitpunkt, an dem eine Studie oder eine wissenschaftliche Darstellung diese Lücke schließt? Unternehmen mit fragmentierten Erkenntnissen können diese Frage in der Regel nicht einmal beantworten, da kein einzelnes System den vollständigen Zeitverlauf erfasst. Diese Unfähigkeit zur Beantwortung ist an sich schon die Diagnose.
Die Organisationen, die im Jahr 2026 echten Nutzen aus ihren Daten ziehen, sind nicht diejenigen mit den meisten Systemen. Es sind diejenigen, in denen eine Erkenntnis als dieselbe Erkenntnis erkannt werden kann, unabhängig davon, aus welcher der vier Ebenen sie stammt.
Erfahren Sie, wie sich Erkenntnisse aus der Praxis, vom Beirat und von Patienten in einer Taxonomie mit TikaMobile Medical Insights miteinander verknüpfen lassen.
Buchen Sie eine 20-minütige Demo
