Christian-Albrechts-Universität zu Kiel. Institut für Informatik. Masterarbeit. Datenqualität in Pharmakovigilanzdaten. Verfasser: Christian Eggeling

Transkript

1 Christian-Albrechts-Universität zu Kiel Institut für Informatik Masterarbeit Datenqualität in Pharmakovigilanzdaten Verfasser: Christian Eggeling geb. am in Hildesheim Betreuer: Prof. Dr. Hans-Joachim Klein, Dipl.-Inf. Tsvetelin Polomski Christian-Albrechts-Universität zu Kiel Institut für Informatik Arbeitsgruppe Technologie der Informationssysteme Olshausenstr. 40, Kiel Germany September 2013

2

3 Kurzfassung Die vorliegende Arbeit mit dem Thema Datenqualität in Pharmakovigilanzdaten beschäftigt sich mit der Qualität der durch die FDA im Rahmen ihres Spontanmeldesystems zur Verfügung gestellten Daten. Mit Hilfe von Spontanmeldesystemen können mögliche Zusammenhänge zwischen unerwünschten Ereignissen und eingenommenen Medikamenten aufgedeckt werden, welches als Teil der Pharmakovigilanz zur Sicherheit von Medikamenten beitragen soll. Im Rahmen dieser Arbeit werden die Daten bzgl. ihrer Qualität analysiert und dabei entdeckte Schwächen aufgezeigt. Weiterhin werden Möglichkeiten zur Verbesserung jener Daten vorgestellt. Zum Teil wurden diese im Rahmen einer Neuentwicklung des Programms OpenVigil, welches es ermöglicht, die von der FDA zur Verfügung gestellten Daten zu analysieren, umgesetzt. Neben den allgemeinen Ansätzen zur Vervollständigung und Korrektur der Daten konnte, speziell durch den neuen Ansatz der eindeutigen Zuordnung von Einträgen aus dem Spontanmeldesystem zu einzelnen Arzneimitteln und -stoffen, nicht nur ein Qualitäts-, sondern auch ein Informationsgewinn erreicht werden. Durch die beschriebenen Möglichkeiten zur Entfernung von Duplikaten kann die Qualität der mit Hilfe von OpenVigil erstellten Statistiken verbessert und damit deren Verlässlichkeit gesteigert werden. iii

4

5 Inhaltsverzeichnis 1. Einleitung Pharmakovigilanz Der Zulassungsprozess Methoden zur Datensammlung Data Mining Grundbausteine des Data Mining Der Prozess des Data Mining Motivation Struktur der Arbeit Datenqualität Daten Definition Dimensionen von Datenqualität Fehlerfreiheit Vollständigkeit Zeitabhängigkeit von Daten Konsistenz und Integrität Weitere Dimensionen Abhängigkeiten zwischen einzelnen Datenqualitätsdimensionen Relevanz Qualität der FDA-Daten FDA AERS Anzahl Meldungen Meldungen nach Quelle Meldungen nach Art der Übermittlung Meldungen nach Herkunftsland Aufbau der Dateien Bereitgestellte Datensätze Analyse Allgemein Demo Drug Indi Outc v

6 Inhaltsverzeichnis Reac Rpsr Ther Zusammenfassung OpenVigil Technische Produktumgebung Entwicklungsumgebung Datenbank Benutzergruppen Architektur Import von Daten Methoden zur Verbesserung der Datenqualität Vervollständigung von Daten Vervollständigung durch Daten des gleichen Falls Vervollständigung auf Basis von Annahmen Konsistenz und Integrität Korrektur von fehlerhaften Datumsangaben Dosenermittlung Einnahme einmal am Tag Einnahme zweimal am Tag Einnahme dreimal am Tag Einnahme viermal am Tag Nicht verwertbare Angaben Drugnamezuordnung Zusammenfassung Manuelle Zuordnung von Drugnames Duplikate Korrigierte Meldungen Doppelte Übermittlung Fazit Ausblick 83 A. Anhang 87 A.1. Allgemein A.1.1. Anzahl Meldungen A.1.2. Meldungen nach Quelle A.1.3. Meldungen nach Art der Übermittlung A.1.4. Meldungen nach Herkunftsland A.1.5. Bereitgestellte Datensätze vi

7 Inhaltsverzeichnis A.2. Demo A.2.1. Anfangs- und Folgemeldungen A.2.2. Altersangaben A.2.3. Angaben zum Geschlecht A.2.4. Gewichtsangaben A.2.5. Beruf des Meldenden A.2.6. Todesdatum A.3. Drug A.3.1. Rolle des Medikaments A.3.2. Validierte und wortwörtliche Drugnames A.4. Outc A.5. Rpsr A.6. Ther A.6.1. Unvollständige Angaben zur Dauer der Medikamenteneinnahme B. Inhalt der CD 107 Literatur 113 Abbildungsverzeichnis 116 Tabellenverzeichnis 117 Abkürzungsverzeichnis 119 Selbstständigkeitserklärung 121 1

8

9 1. Einleitung Diese Einleitung soll zunächst einen Überblick über die Hauptthemengebiete geben, in denen diese Arbeit angesiedelt ist. Dies ist sowohl der Bereich der Pharmakovigilanz als auch der Bereich des Data Mining. Anschließend folgt eine Einordnung dieser Arbeit in diese beiden Bereiche Pharmakovigilanz Pharmakovigilanz beschäftigt sich mit der Untersuchung von Risiken, die durch die Einnahme von Medikamenten auftreten können. Neben der gewünschten, heilenden Wirkung eines Medikaments kann es vorkommen, dass auch weitere Effekte, die i. d. R. unerwünscht sind, auftreten. Ein Medikament, auch Arzneimittel genannt, kann durch Patienten eingenommen werden. Es besteht aus einem oder mehreren Wirkstoffen, auch Arzneistoffe genannt, und möglichen weiteren Hilfsstoffen. Pharmakovigilanz ist die Disziplin, unerwünschte Effekte aufzuspüren, zu untersuchen und bei Bedarf präventive Maßnahmen zu ergreifen [Eva00]. Die Weltgesundheitsorganisation (WHO) definiert Pharmakovigilanz daher als die Wissenschaft und die Aktivitäten zur Entdeckung und Bewertung, zum Verständnis und zur Vermeidung unerwünschter Ereignisse und anderen medikamentenbezogenen Problemen [HG08]. Ein unerwünschtes Ereignis ist dabei ein auftretendes Ereignis, das möglicherweise im Zusammenhang mit der Einnahme eines Medikaments steht und daher möglicherweise eine Nebenwirkung dieses Medikaments darstellt. Unterschieden werden muss hierbei, ob es sich um eine spezifische Nebenwirkung des Medikaments oder allgemein des Wirkstoffs handelt [PRPP12]. Ziel der Pharmakovigilanz ist es, Gefahren für Patienten durch auftretende Nebenwirkungen abzuwenden und damit das Risiko bei der Einnahme von Medikamenten zu verringern [Eva00]. An den einzelnen Schritten der Pharmakovigilanz sind viele Akteure beteiligt. Hierzu zählen u. a. Behörden, die Arzneimittelindustrie und Forschungsinstitutionen, sowie Ärzte und Apotheker [HG08] Der Zulassungsprozess Vor der Zulassung Die für die Zulassung von Medikamenten zuständigen Behörden sind u. a. die Food and Drug Administration (FDA) in den USA, die European Medicines Agency (EMA) für Europa und das Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM) in Deutschland. Vor der Zulassung eines Arzneimittels durch die jeweils zuständige Behörde muss ein Unternehmen 3

10 1. Einleitung der Behörde Materialien vorlegen, die die Unbedenklichkeit des Medikaments bestätigen. Insbesondere müssen hier die Kriterien Sicherheit, Qualität und Wirksamkeit betrachtet und nachgewiesen werden [Eva00]. Um dies umzusetzen, werden vor der Zulassung klinische Studien durch das verantwortliche Pharmaunternehmen durchgeführt. Diese sollen Daten liefern, die die Wirksamkeit und Unbedenklichkeit des Arzneimittels bestätigen. Allerdings werden für die klinischen Studien Testpopulationen ausgewählt, die nicht unbedingt der späteren Zielgruppe entsprechen müssen. Die ausgewählten Personen haben beispielsweise nur die durch das Medikament zu behandelnde Krankheit, aber keine anderen Krankheiten, und sind jünger als die typischen, nach der Zulassung zu behandelnden Patienten. Auch haben diese klinischen Studien Nachteile auf Grund der geringen Größe der Testpopulation. Diese ist i. d. R. nicht größer als 2000 Personen. Die Dauer dieser Studien ist ebenfalls begrenzt. Nur ein geringer Anteil der Probanden wird ein Jahr oder länger mit dem zu testenden Medikament behandelt [Eva00]. Vor der Zulassung können nicht alle durch das Medikament verursachten Nebenwirkungen identifiziert werden. Dies liegt zum einen daran, dass manche Nebenwirkungen nur sehr selten, d. h. einmal bei mehr als 1000 Behandlungen oder seltener, auftreten. Diese können während der Studien keine statistische Relevanz erreichen. Zum anderen liegt dies an den oben beschriebenen methodischen Nachteilen der Studien. Nebenwirkungen, die erst durch die Interaktion von mehreren Arzneimitteln auftreten, können deshalb ebenso wenig identifiziert werden wie Nebenwirkungen, die nur bei einer bestimmten Gruppe von Patienten auftreten [Eva00] Die Zulassung Die Zulassung für ein Medikament erfolgt nach der Prüfung der vorgelegten Unterlagen. Innerhalb der EU wird die Zulassung zunächst für eine Dauer von 5 Jahren erteilt und kann anschließend für unbegrenzte Zeit verlängert werden (Verordnung (EG) Nr. 726/2004). In den USA erfolgt die Zulassung ohne zeitliche Beschränkung. Die Zulassung kann nach ihrer Erteilung nachträglich verändert werden, z. B. um neue Befunde zu ergänzen, zu deren Behandlung das Medikament eingesetzt werden kann. Die Zulassung kann unter der Voraussetzung erfolgen, dass das produzierende Pharmaunternehmen unerwünschte Ereignisse zeitnah an die zuständige Behörde meldet und regelmäßige Berichte über die Sicherheit des Medikaments erstellt [Eva00] Nach der Zulassung Da vor der Zulassung nicht alle Nebenwirkungen entdeckt werden können, müssen die Medikamente auch nach ihrer Zulassung beobachtet werden. Hierzu sind u. a. die Hersteller gesetzlich verpflichtet. Ziel dieser Beobachtung ist es, Hinweise auf potenzielle Abhängigkeiten zwischen Arzneimitteln und unerwünschten Ereignissen zu identifizieren, sog. Signale [PRPP12]. Die WHO definiert ein Signal wie folgt: Reported information on a possible causal relationship between an adverse event and a drug, the relationship being unknown or incompletely documented previously. [Wor11] 4

11 1.1. Pharmakovigilanz Meldungen zu neuen Signalen treten regelmäßig auf. Nach einer Untersuchung muss dann jeweils entschieden werden, ob das Medikament zurückgezogen werden muss, ob das Risiko- Nutzen-Verhältnis trotz des nun höheren Risikos nach wie vor positiv ist und damit die möglicherweise auftretende Nebenwirkung hingenommen werden kann, oder ob das Signal unbegründet war [HG08]. Unterstützt werden diese Untersuchungen durch die Sammlung von Daten für jedes einzelne Medikament. Je nach Art der Untersuchung und Anforderungen an die Einsatzmöglichkeiten kommen unterschiedliche Methoden zur Datensammlung zum Einsatz. Diese sollen im Folgenden kurz vorgestellt werden Methoden zur Datensammlung Klinische Studien Klinische Studien dienen der systematischen Erprobung und Überprüfung neuer Arzneimittel, um deren Wirksamkeit und Verträglichkeit zu belegen. Durchgeführt wird eine klinische Studie mit zwei Gruppen. Dabei erhält eine Gruppe das zu testende Medikament und eine Kontrollgruppe erhält ein Placebo oder ein alternatives Medikament. Um den Einfluss äußerer Faktoren, wie z. B. dem allgemeinen Gesundheitsbewusstsein der Teilnehmer, zu begrenzen, werden die Probanden der Studie per Zufall einer der beiden Gruppen zugeordnet [SS09]. Klinische Studien haben den Vorteil, dass die Daten der Teilnehmer sehr detailliert erfasst werden und damit eine spätere ausführliche Auswertung möglich ist [PRPP12]. Sie unterliegen aber auch den bereits weiter oben beschriebenen methodischen Nachteilen. Neben dem Einsatz klinischer Studien vor der Zulassung eines Arzneimittels können diese auch nach der Zulassung genutzt werden, um Hypothesen über mögliche Nebenwirkungen zu beweisen oder zu widerlegen. Hierbei kann bspw. die Wirkung des Medikaments auf eine bestimmte Gruppe von Patienten geprüft werden, indem nur diese an der Studie teilnehmen [HG08] Spontanmeldesysteme Spontanmeldesysteme wurden entwickelt und eingeführt, nachdem Anfang der 1960er Jahre das Beruhigungsmittel Contergan mit dem Wirkstoff Thalidomid als Ursache für viele Missbildungen bei Neugeborenen ausgemacht wurde [Mai01]. Sie sollten helfen, das Auftreten von unbekannten, schwerwiegenden Nebenwirkungen frühzeitig erkennen zu können, um notwendige Maßnahmen einzuleiten [HG08]. Sie sind das für diesen Zweck am häufigsten eingesetzte Mittel [PRPP12]. Mit Hilfe von Spontanmeldesystemen werden Informationen über unerwünschte Ereignisse und mit ihnen im Zusammenhang stehende Arzneimittel gesammelt. Neben Herstellern, die zur Meldung verpflichtet sind, können je nach bereitstellender Institution auch Ärzte, Apotheker und sonstige im Gesundheitswesen tätige Personen, sowie Patienten Meldungen über Verdachtsfälle abgeben [PRPP12]. Meldungen über schwerwiegende Verdachtsfälle werden auch zwischen den einzelnen Behörden, speziell zwischen den USA und Europa, sowie innerhalb Europas zwischen den einzelnen nationalen Behörden, ausgetauscht [Eva00]. 5

12 1. Einleitung Beispiele für eingerichtete Spontanmeldesysteme sind u. a. das in den USA von der FDA eingeführte Adverse Event Reporting System (AERS), die von der EMA entwickelte Eudravigilance Datenbank (European Union Drug Regulating Authorities Pharmacovigilance) [PRPP12], die vom BfArM geführte UAW-Datenbank (Unerwünschte Arzneimittelwirkung) [Arz13] und die von der WHO am Uppsala Monitoring Centre (UMC) geführte Vigibase [PRPP12]. Neben der FDA stellt auch Health Canada die Daten ihrer Canada Vigilance Adverse Reaction Online Database frei zum Download zur Verfügung [PRPP12]. Weitere Datenbanken, deren Inhalte online durchsucht werden können, sind neben der UAW-Datenbank der BfArM die Datenbanken der niederländischen Lareb und der englischen Medicines and Healthcare products Regulatory Agency (MHRA) [HG08]. Hauptkritikpunkt an der Sammlung von Daten mit Hilfe von Spontanmeldesystemen ist die schwankende Wahrscheinlichkeit, dass eine mögliche Nebenwirkung eines Medikaments als solche erkannt und gemeldet wird. So werden unkritische Nebenwirkungen möglicherweise auf Grund dessen, dass sie kein Risiko für den Patienten darstellen, nicht gemeldet. Andererseits werden mögliche Nebenwirkungen mit schwerwiegenden Auswirkungen sehr zeitnah gemeldet. Es findet also eine Vorauswahl statt [HG08]. Diese Vorauswahl führt dazu, dass die wirklichen Auswirkungen einer Nebenwirkung nicht erkannt werden können [PRPP12]. Andererseits kann diese Vorauswahl aber auch helfen, die schwerwiegenden Nebenwirkungen eines Medikaments schneller zu erkennen, um dann notwendige Maßnahmen einleiten zu können [HG08]. Diese Vorauswahl durch den behandelnden Arzt unterliegt zusätzlichen externen Einflüssen. Beispielsweise werden direkt nach der Markteinführung mögliche Nebenwirkungen eher gemeldet, als wenn das Arzneimittel schon längere Zeit auf dem Markt ist. Der Einsatz eines schon länger erhältlichen Medikaments zur Behandlung weiterer Symptome, die vorher nicht mit diesem Medikament behandelt wurden, oder neue Dosierungen können ebenfalls zu einer Erhöhung der Meldewahrscheinlichkeit führen. Weitere Einflussfaktoren sind die Aufmerksamkeit der Medien und damit eine verstärkte Aufmerksamkeit durch die Öffentlichkeit, sowie mögliche regulatorische Aktivitäten, wie Warnungen, von Behörden. All diese Faktoren können zusätzlichen Einfluss auf die Meldungen anderer Medikamente haben. Beispielsweise kann die Warnung vor einem Medikament dazu führen, dass andere Arzneimittel zur Behandlung desselben Symptoms verstärkt eingesetzt werden und damit die Aufmerksamkeit diesen gegenüber ansteigt [PRPP12]. Trotz der genannten Nachteile sind Spontanmeldesysteme ein gutes Mittel, um Sicherheitsrisiken frühzeitig erkennen zu können, da sie sehr zeitnah Informationen über die Anwendung von Arzneimitteln liefern können [PRPP12] Prescription Event Monitoring (PEM) Das Prescription Event Monitoring hat das Ziel, ein konkretes Medikament genau zu beobachten und dabei möglichst alle auftretenden unerwünschten Ereignisse zu erfassen. Dazu werden die Ärzte, die das Medikament verordnet haben, angeschrieben und um Meldung eventuell aufgetretener, unerwünschter Ereignisse gebeten. Dabei wird eine große Datenmenge zu diesem einen Medikament gesammelt. Das wesentliche Problem des PEM ist, dass es keine Kontrollgruppe gibt, die mögliche Assoziationen zwischen Medikament und einem unerwünschten Ereignis widerlegen kann [Eva00]. 6

13 1.2. Data Mining Eingesetzt wird PEM besonders in England. Dort werden bei neuen Medikamenten regelmäßig die Ärzte, welche die ersten Verschreibungen durchgeführt haben, angeschrieben [MWP + 97] Data Mining Data Mining beschäftigt sich mit der Analyse von und Informationsgewinnung aus Datenmengen, die auf Grund ihrer Größe bzw. ihres Umfangs nicht mit Hilfe klassischer, von Menschen durchgeführten Methoden ausgewertet werden können [Gor11]. Zum einen, da eine manuelle Auswertung zu langsam, zu teuer und ggf. zu subjektiv wäre, aber auch da sie ab einer gewissen Datenmenge für Menschen in nicht automatisierten Verfahren nicht mehr handhabbar ist [FPsS96]. Data Mining im engeren Sinne bezieht sich nur auf die Analyse eines Datenbestands, und damit den Gewinn von Informationen aus Daten, wie z. B. komplexe Muster, die Abhängigkeiten beschreiben [Gor11]. Im allgemeineren Sinne wird Data Mining auch als Bezeichnung für einen ganzen Prozess, der auch als Knowledge Discovery bezeichnet wird, verwendet. Dieser Prozess beinhaltet nicht nur die Analyse selbst sondern auch die Vor- und Nachbereitungen [FPsS96]. Dieser Prozess wird in Abschnitt noch genauer beleuchtet. Data Mining im engeren Sinne lässt sich definieren als: Applying data analysis and discovery algorithms that, under acceptable computational efficiency limitations, produce a particular enumeration of patterns (or models) over the data. [FPsS96] Wohingegen Data Mining im weiteren Sinne, und damit im Sinne des Knowledge Discovery, sich wie folgt definieren lässt: The nontrivial process of identifying valid, novel, potentially useful, and ultimately understandable patterns in data. [FPsS96] Im Folgenden sollen nun zunächst die Grundbausteine und anschließend der gesamte Prozess des Data Mining beschrieben werden Grundbausteine des Data Mining Die Techniken des Data Mining basieren im Wesentlichen auf den folgenden drei Säulen [Gor11]: Statistik Künstliche Intelligenz Datenbanksysteme 7

14 1. Einleitung Artificial Intelligence Machine Learning Statistics Natural Computing DATA MINING Database systems Abbildung 1.1.: Data mining roots [Gor11] Statistik Statistik ist die Grundlage des Data Mining im engeren Sinne. Sie ermöglicht die Auswertung von Daten anhand bekannter und bewährter Berechnungsverfahren [Gor11]. Die deskriptive Statistik beschreibt die vorhandenen Daten sowohl anhand von tabellarischen und grafischen Darstellungen als auch mit Hilfe von aggregierten Werten [Ste07]. Hierzu gehören etwa Mittelwerte und Streuungsmaße [Gor11]. Auch bisher unbekannte Zusammenhänge und Strukturen lassen sich mit Hilfe der deskriptiven Statistik erkennen, die sich anschließend auf ihre Allgemeingültigkeit mit Hilfe von wahrscheinlichkeitstheoretischen Methoden untersuchen lassen [Ste07] Künstliche Intelligenz Künstliche Intelligenz ergänzt Data Mining um Methoden, mit denen Informationen ausgewertet werden können, wobei versucht wird, das menschlichen Denken zu immitieren. Hierzu gehört auch das maschinelle Lernen, bei dem der Computer für einen bestimmten Zweck trainiert wird. Ebenfalls in diesen Bereich fällt das Natural Computing [Gor11] Datenbanksysteme Datenbanksysteme stellen die Daten bereit, in denen nach Informationen gesucht werden soll [Gor11]. Sie stellen Techniken zur Verfügung, mit denen auch große Datenmengen effizient ausgewertet werden können. Hierzu gehören die Verwaltung der Daten und die Optimierung von Zugriffen auf diese Daten, insbesondere wenn diese nicht vollständig in den Hauptspeicher 8

15 1.2. Data Mining geladen werden können. Außerdem stellen sie Methoden zum Gruppieren und Sortieren bereit und optimieren Anfragen, die an sie gestellt werden, damit diese auch beim Zugriff auf große Datenmengen effizient abgearbeitet werden können [FPsS96] Der Prozess des Data Mining Im weiteren Sinne bezeichnet Data Mining den gesamten Prozess des Knowledge Discovery. Dieser besteht neben der Vorbereitung auch aus der Analyse der Daten, dem Data Mining im engeren Sinne, und der Validierung der Ergebnisse [Gor11]. Im Folgenden sollen die einzelnen Schritte des Knowledge Discovery, wie sie in Abbildung 1.2 zu sehen sind, beschrieben werden. Data Mining Interpretation / Evaluation Preprocessing Transformation Knowledge Selection Patterns Preprocessed Data Transformed Data Data Target Data Abbildung 1.2.: Schritte des Knowledge Discovery [FPsS96] Selektion Nachdem ein grundsätzliches Verständnis über die zu untersuchende Domäne entwickelt wurde und das Ziel, das mit Hilfe von Data Mining erreicht werden soll, festgelegt wurde, muss zunächst der Datenbestand, der ausgewertet werden soll, definiert werden. Dies kann ein bereits existierender Datenbestand sein, eine Teilmenge davon [FPsS96] oder eine neu zu erstellende Datenbasis, die z. B. durch Umfragen gewonnen werden kann [ES00] Vorverarbeitung Bevor der im vorherigen Schritt ausgewählte Datenbestand ausgewertet werden kann, müssen zunächst Fehler und Inkonsistenzen bereinigt werden. Hierzu gehören Entscheidungen über den Umgang mit verrauschten oder fehlenden Daten [FPsS96], Duplikaten, falsch aufgenommenen Daten und veralteten Daten [Gor11]. Weiterer Bestandteil ist das Aufbereiten der Daten in ein einheitliches Format, wie z. B. Angaben über Daten, Namen und Adressen, falls der Datenbestand sich aus unterschiedlichen Quellen zusammensetzt. Der Umgang mit fehlerhaften Daten ist ebenfalls Bestandteil dieses Schritts [RD00]. Mehr zu diesen Qualitätsproblemen findet sich in Kapitel 2. 9

16 1. Einleitung Transformation Nach der Vorverarbeitung des Datenbestandes folgt die Transformation. Dieser Schritt beinhaltet die Reduktion und Projektion der Daten, um den Datenbestand für die im nächsten Schritt folgende eigentliche Analyse zu verringern [FPsS96]. Hierzu gehört die Aggregation von Daten, die mehrere Attribute oder mehrere Datensätze zusammenfasst. Dies kann z. B. das Zusammenfassen von täglichen Einkaufszahlen in wöchentliche oder monatliche Summen oder von Städten zu Regionen sein. Weiterer Bestandteil ist die Diskretisierung mit der Umwandlung von kontinuierlichen Daten in diskrete Daten, oder sonstige weitere Zusammenfassungen von Daten in Kategorien [Gor11]. Die Dimensionsreduktion ist ebenfalls Teil der Transformation [FPsS96] Data Mining In diesem Schritt wird das Data Mining im engeren Sinne durchgeführt, und dabei der Datenbestand, welcher das Ergebnis der vorherigen Schritte ist, analysiert. Am Anfang des Data Mining steht die Auswahl einer Methode, die am besten das Erreichen der gewünschten Ziele ermöglicht. Passende Methoden können z. B. Clustering, Klassifizierung und Regression sein. Entsprechend der gewählten Methode folgt dann die Auswahl des am besten passenden Algorithmus und die Festlegung der Parameter, mit denen dieser ausgeführt wird. Im Falle der Regression kann beispielsweise zwischen einer linearen Regression, einer nichtlinearen Regression oder einer Form der Zeitreihenanalyse gewählt werden [FPsS96], wobei hier entsprechend Parameter wie Glättungsfaktoren und Startwerte festzulegen sind [Tho10]. Nach der Festlegung der Methode, des Algorithmus und ggf. der für den Algorithmus notwendigen Parameter folgt dann die Ausführung des Algorithmus, bevor im nächsten Schritt dann die Ergebnisse ausgewertet werden [FPsS96] Interpretation, Evaluierung Nachdem die Ausführung des gewählten Data Mining-Algorithmus ein Ergebnis geliefert hat, muss dieses ausgewertet und interpretiert werden [FPsS96]. Hierzu ist die Anwendung fachlichen Wissens der jeweiligen Domäne notwendig, um Fehlinterpretationen und daraus folgende falsche Schlussfolgerungen zu vermeiden [PRPP12]. Bei Bedarf kann hier auch ein Rücksprung auf die vorherigen Schritte vorgenommen werden. Dies kann u. a. notwendig sein, wenn der im vorherigen Schritt gewählte Algorithmus mit anderen Parametern noch einmal ausgeführt werden muss, oder wenn in den anderen, vorherigen Schritten Korrekturen oder Verbesserungen vorzunehmen sind [FPsS96] Motivation Das im Rahmen dieser Arbeit behandelte Thema der Datenqualität in Pharmakovigilanzdaten ordnet sich in die nach der Zulassung erfolgende Beobachtung von Arzneimitteln im Rahmen der Pharmakovigilanz ein. Bei diesen Beobachtungen fällt speziell im Bereich der Spontanmeldesysteme (siehe ) eine erhebliche Datenmenge durch die Meldungen von möglichen 10

17 1.4. Struktur der Arbeit Nebenwirkungen an. Um mögliche Zusammenhänge zwischen Arzneimitteln und unerwünschten Ereignissen ermitteln zu können, ist die Anwendung entsprechender Algorithmen aus dem Bereich des Data Mining notwendig. Die Anwendung dieser Algorithmen ist nicht Bestandteil dieser Arbeit, jedoch die Aufbereitung jener Daten, um die spätere Analyse zu ermöglichen. Im Bereich des Data Mining ordnet sich diese Arbeit also im Bereich der Vorverarbeitung (siehe ) ein. Diese Arbeit beschäftigt sich mit der Qualität der Daten, die im Rahmen des von der FDA geführten Spontanmeldesystems AERS frei verfügbar sind, und deren Einbindung in das Analysetool OpenVigil, welches im Folgenden noch ausführlich vorgestellt werden wird (siehe Kapitel 4). Im Rahmen dieser Arbeit soll beleuchtet werden, wie es um die Datenqualität in den von der FDA zur Verfügung gestellten Daten bestellt ist und wie diese verbessert werden kann. Ziel ist es, eine möglichst gute Qualität des Datenbestandes als Ausgangsgrundlage für die Ausführung der Algorithmen durch OpenVigil zu ermöglichen und dadurch die Qualität der durch OpenVigil generierten Ergebnisse zu verbessern, wodurch mögliche Nebenwirkungen von Medikamenten besser erkannt und dadurch Risiken durch die Einnahme von Medikamenten gesenkt werden können Struktur der Arbeit Nachdem nun in diesem Kapitel die grundlegende Thematik, innerhalb derer sich diese Arbeit einordnet, vorgestellt wurde, werden im nächsten Kapitel zunächst theoretische Grundlagen zum Thema Datenqualität erläutert. Auf Basis der dort vorgestellten Datenqualitätsdimensionen folgen anschließend die Ergebnisse der Analyse der Daten aus dem Spontanmeldesystem AERS, welches durch die FDA betrieben wird. Anschließend wird das Programm OpenVigil vorgestellt, welches es ermöglicht, die Daten aus AERS zu analysieren. Im letzten Kapitel werden dann Möglichkeiten aufgezeigt, wie die im dritten Kapitel beschriebenen Qualitätsmängel teilweise behoben werden können. 11

18

19 2. Datenqualität Dieses Kapitel soll eine Einführung in das Thema der Datenqualität geben. Zunächst wird der Begriff Daten gegenüber den Begriffen Informationen und Wissen abgegrenzt werden. Nach einer Definition von Datenqualität werden dann einzelne Datenqualitätsdimensionen beleuchtet werden. Zum Abschluss dieses Kapitels soll noch auf die Relevanz von Datenqualität für die Praxis eingegangen werden Daten Daten sind die Abbildung von realen Objekten in ein Format, das gespeichert, abgerufen und verarbeitet werden kann. Die Verarbeitung von Daten findet dabei innerhalb von Softwaresystemen statt [BS06]. Es handelt sich bei Daten zunächst um eine Sammlung von Zeichen, die nach bestimmten Syntaxregeln zusammengesetzt wurden. Sie werden zu Informationen, wenn die Daten um einen Kontext ergänzt werden, in dem sie stehen. Durch die passende Verknüpfung von Informationen, und damit das Einbringen von Wissen über den Zusammenhang der Informationen, entsteht Wissen. Die Abgrenzung von Daten zu Informationen und von Informationen zu Wissen ist dabei nicht immer genau möglich, vielmehr ist der Übergang zwischen den einzelnen Zuständen teilweise fließend. Allgemein nimmt die Strukturiertheit mit der Wandlung von Daten zu Wissen ab und die Kontextabhängigkeit nimmt, ebenso wie der Einfluss auf von Menschen getätigte Handlungen, zu [Bod06]. Daten lassen sich kategorisieren in strukturierte, teil-strukturierte und unstrukturierte Daten. Strukturierte Daten liegen beispielsweise in relationalen Datenbanken vor, deren Tabellen durch die vorhandenen Spalten eine konkrete Struktur aufweisen. Aber auch XML-Dateien, die durch ein Schema eine konkrete definierte Struktur aufweisen, gehören hierzu. Teilstrukturierte Daten hingegen haben eine flexible Struktur, welche nur teilweise definiert ist. Hierzu gehören XML-Dateien, insofern sie nicht über ein Schema verfügen, aber auch einfache CSV-Dateien. Merkmale von unstrukturierten Daten sind, dass ein einzelnes Datum auf unterschiedliche Art und Weise repräsentiert werden kann. Es kann beispielsweise auf mehrere Felder aufgeteilt sein, aber auch in einem einzigen Feld zusammengefasst werden. Ein Beispiel hierfür ist eine Adresse, die aufgeteilt nach Straße, Hausnummer, Postleitzahl und Ort abgespeichert, aber auch in einem Feld zusammengefasst werden kann. Weiterhin ist bei teil-strukturierten Daten die Anzahl der Felder nicht von vornherein festgelegt und kann sich jederzeit ändern. Im Gegensatz zu strukturierten und teil-strukturierten Daten fehlt unstrukturierten Daten jede Art von Struktur. Dies kommt beispielsweise vor, wenn Daten innerhalb eines Textes oder in gesprochener Sprache wiedergegeben werden [BS06]. 13

20 2. Datenqualität Neben ihrer Struktur lassen sich Daten auch nach ihrer Beständigkeit klassifizieren. Dabei kann zwischen beständigen Daten, sich selten ändernden Daten und sich häufig ändernden Daten unterschieden werden [BS06]. Beständige Daten sind Daten, bei denen es sehr unwahrscheinlich ist, dass sie sich ändern [BS06]. Ein Beispiel hierfür ist das Geburtsdatum einer Person. Der einzige Fall, in dem dies sich innerhalb einer Datenbank ändert, ist, dass dieses auf Grund einer Fehleingabe korrigiert werden muss. Daten mit sehr geringer Änderungshäufigkeit sind beispielsweise die Namen von Personen. Zwar können diese sich grundsätzlich ändern, allerdings ist dies ein Vorgang, der eher selten und mit größeren zeitlichen Abständen auftritt. In die letzte Kategorie der sich häufig ändernden Daten lassen sich beispielsweise Aktienkurse einordnen Definition Datenqualität bezieht sich auf die Qualität der einzelnen Daten, die innerhalb einer Datei oder einer Datenbank abgelegt sind. Sie bezieht sich auf den eigentlichen Inhalt und ist damit abzugrenzen von der Schema-Qualität, bei der die Qualität der Struktur einer Datei oder Datenbank im Mittelpunkt steht. Maße für die Qualität eines Schemas sind u. a. die erste, zweite, dritte und Boyce-Codd-Normalform [BS06]. Datenqualität lässt sich definieren als die Tauglichkeit von Daten für den Einsatz durch Datenkonsumenten [SLW97]. Die Qualität von Daten ergibt sich dabei aus unterschiedlichen Dimensionen. Die Qualität eines konkreten Datensatzes lässt sich je nach Dimension mit unterschiedlichem Aufwand ermitteln [BS06]. Mehr dazu im folgenden Abschnitt, in dem einzelne Dimensionen vorgestellt werden Dimensionen von Datenqualität Im Folgenden sollen nun Dimensionen von Datenqualität vorgestellt und deren Auswirkungen beschrieben werden Fehlerfreiheit Fehlerfreiheit bezieht sich auf die Übereinstimmung der in einer Datenbank gespeicherten Daten gegenüber den realen Objekten, die sie abbilden. Auf Attributebene ist Fehlerfreiheit zu unterscheiden in syntaktische und semantische Fehlerfreiheit [BS06]. Syntaktische Fehlerfreiheit bezieht sich auf den Wertebereich, aus dem ein Wert kommen kann. Sie bezieht sich also nicht auf den Vergleich mit dem Wert des realen Objektes der repräsentiert werden soll, sondern allein darauf, ob der Wert innerhalb seiner Domäne Gültigkeit besitzt [BS06]. Die Übereinstimmung des Wertes mit dem real repräsentierten Objekt ist für die syntaktische Korrektheit nicht entscheidend. Insofern es sich bei den erlaubten Werten um Zeichenketten handelt, bietet sich zum Messen der syntaktischen Fehlerfreiheit eine Funktion an, die Abstände zwischen einzelnen Zeichenketten ermittelt [BS06]. Diese Funktionen sind u. a. Edit distance, Affine gap distance, 14

21 2.3. Dimensionen von Datenqualität Smith-Waterman distance, aber auch komplexere Funktionen wie Q-Grams oder Soundex [EIV07]. Syntaktisch falsche Werte entstehen häufig durch Fehler bei der Eingabe von Daten in ein System durch Benutzer [EIV07]. Semantische Fehlerfreiheit bezieht sich auf die Übereinstimmung eines Wertes mit dem Wert des realen Objektes, das repräsentiert werden soll. Für die Stadt Kiel wäre Hamburg zwar ein syntaktisch korrekter Wert da er aus dem gleichen Wertebereich kommt, semantisch wäre er aber falsch. Ausdrücken lässt sich die semantische Fehlerfreiheit nur in richtig oder falsch. Hierfür muss der richtige Wert des Objektes jedoch bekannt sein. Sollte er nicht bekannt sein, lässt er sich bei allgemein bekannten Daten mit anderen Datenquellen vergleichen. Hierfür ist allerdings ein eindeutiger Identifikator notwendig [BS06]. Fehlerfreiheit lässt sich nicht nur in Bezug auf einzelne Attribute bestimmen, sondern auch in Bezug auf Tupel, Tabellen und ganze Datenbanken. Hierzu wird üblicherweise das Verhältnis zwischen korrekten und insgesamt verfügbaren Einheiten gemessen [BS06]. In Bezug auf ganze Tabellen ist auch der Aspekt der Duplikate zu nennen [BS06]. Auf das Problem der Duplikate soll im folgenden Abschnitt eingegangen werden Duplikate Duplikate sind mehrere Tupel, die dasselbe reale Objekt in der gleichen Weise abbilden. Sie können daher in ein einzelnes Tupel zusammengefasst werden [DN09]. DS RW DS RW Þ Abbildung 2.1.: Duplikate Abbildung 2.1 zeigt dies grafisch. Links ein reales Objekt, das von zwei Tupeln repräsentiert wird und rechts, nach der Zusammenführung, ein reales Objekt, das von einem Tupel repräsentiert wird. Duplikate sind ein Qualitätsproblem [NOBE07], das auftritt, wenn eine Datenquelle nicht oder nur unzureichend über Schlüssel verfügt, die Eindeutigkeit gewährleisten [BS06]. Bei der Integration unterschiedlicher Datenquellen wird dieses Problem besonders deutlich, da hier ohne entsprechende Schlüssel die einzelnen Datensätze, die das gleiche reale Objekt repräsentieren, nicht oder nur schwer als identisch erkannt werden können [SB02]. Noch schwieriger wird dies, wenn in den zu integrierenden Datenquellen unterschiedliche Formate und Definitionen genutzt werden [EIV07]. In relationalen Datenbanken können Duplikate eins-zu-eins Joins verhindern, wenn diese über Attribute, die wegen fehlender Duplikatelimination nicht eindeutig sind, durchgeführt werden [EIV07]. Duplikate können nicht nur innerhalb einer Tabelle, sondern auch in Bezug auf eine ganze Datenbank existieren. Hierbei handelt es sich um Kopien eines Datensatzes und 15

22 2. Datenqualität aller seiner zugehörigen Elemente in anderen Tabellen, wobei Identifikatoren neu vergeben wurden und somit die Gleichheit nicht offensichtlich ist Vollständigkeit Vollständigkeit von Daten lässt sich definieren als die ausreichende Breite und Tiefe eines Datenbestands für die Anwendung in einem konkreten Kontext [WS96]. Allgemein lässt sich Vollständigkeit in drei Kategorien aufteilen. Die Vollständigkeit des Schemas gibt an, ob alle für den Anwendungsbereich notwendigen Objekttypen mit ihren Beziehungen vorhanden sind und über die notwendigen Attribute verfügen [PLW02]. Ein Entitätstyp der Personen beschreiben soll, dem aber das Attribut Geburtsdatum fehlt, wäre für die Berechnung des Durchschnittsalters aller Personen unvollständig. Unter der Vollständigkeit einer Spalte versteht man, zu wie vielen Datensätzen der Wert eines Attributs vorhanden ist [PLW02]. In einer Relation zur Beschreibung von Personen wäre die Vollständigkeit für das Attribut Geburtsdatum gegeben, wenn dieses zu jeder Person erfasst wurde. Im Zusammenhang mit der Vollständigkeit einer Spalte steht in relationalen Datenbanken die Bedeutung des NULL-Wertes. Der SQL-Standard legt die Bedeutung des NULL-Wertes als a special value or mark, that is used to indicate the absence of any data value [ISO92] fest. Dies bedeutet, dass der NULL-Wert keine Information über den Wert eines Attributs liefert [Kle03]. Im konkreten Anwendungsbezug hat der NULL-Wert meist eine von drei Bedeutungen. Zunächst kann er bedeuten, dass der Wert für ein Attribut in einem Tupel nicht existiert. Zweitens kann er besagen, dass der Wert existiert, aber zum aktuellen Zeitpunkt nicht bekannt ist. Und zuletzt kann er bedeuten, dass der Wert für ein Attribut möglicherweise existiert, aber unbekannt ist, ob er existiert und falls ja, welchen Wert er hat [BS06]. Auf Grund dieser unterschiedlichen Bedeutungen sollte für eine Datenbank immer festgelegt werden, welche Bedeutung dem NULL-Wert zukommt. Ist die Abbildung aller drei Bedeutungen notwendig, so können auch Werte, die außerhalb des erlaubten Wertebereichs liegen, aber im jeweils gewählten Datentypen abgespeichert werden können, zur Abbildung einer der drei Bedeutungen genutzt werden. Bei der Messung der Vollständigkeit einer Datenbank, bezogen auf die drei oben genannten Dimensionen, sollte die jeweilige Bedeutung des NULL-Wertes beachtet und entsprechend berücksichtigt werden [BS06]. Die Vollständigkeit des Datenbestandes gibt an, ob alle nötigen Tupel im Vergleich zu einer Grundgesamtheit vorhanden sind [PLW02]. Soll eine Datenbank über Beschäftigte einer Firma geführt werden, wären diese Beschäftigten die Grundgesamtheit. Der Datenbestand wäre vollständig, wenn zu jedem Mitarbeiter ein Datensatz vorhanden wäre. Bei der Messung der Vollständigkeit des Datenbestandes kann zwischen einer Messung unter closed world assumption und einer Messung unter open world assumption unterschieden werden. Die Annahme einer geschlossenen Welt besagt, dass nur die Werte, die in einer relationalen Datenbank vorhanden sind, existieren. Alles, was nicht in dieser Datenbank vorkommt, existiert nach dieser Annahme nicht. Wohingegen die Annahme einer offenen Welt davon ausgeht, dass weder belegt werden kann, dass Daten, die nicht in einer relationalen Datenbank gespeichert sind, existieren, noch dass dies widerlegt werden kann. Nur über die Daten, die in 16

23 2.3. Dimensionen von Datenqualität der Datenbank vorkommen, kann eine klare Aussage getroffen werden [BS06]. Ein Datenbestand unter der Annahme einer geschlossenen Welt ist per Definition vollständig. Um die Vollständigkeit eines Datenbestandes unter Annahme einer offenen Welt zu ermitteln, ist es notwendig, die Anzahl an Tupeln in der Referenz-Relation zu kennen. Die Referenz- Relation enthält alle Tupel, die für eine Relation in Frage kommen. Die Vollständigkeit ist dann die Anzahl von Einträgen in der Relation im Verhältnis zur Anzahl von Einträgen in der Referenz-Relation [BS06] Zeitabhängigkeit von Daten Daten lassen sich nach der Häufigkeit ihrer Änderungen klassifizieren in beständige, sich selten ändernde und sich häufig ändernde Daten. Diese Klassifikation von Daten wurde bereits in 2.1 ausführlicher vorgestellt. Die Häufigkeit, wie oft sich Daten ändern, sagt alleine allerdings noch nichts über die aktuelle Qualität eines Datensatzes aus. Diese ergibt sich erst aus dem zeitlichen Kontext der Nutzung. Die bereits beschriebene Klassifizierung drückt die Volatilität der Daten, d. h. die Änderungsfrequenz aus. Beständige Daten haben eine Volatilität von 0. Je häufiger sich Daten ändern, desto höher ist ihre Volatilität. Je höher die Volatilität, desto kürzer ist die Zeit, in der ein Datum gültig ist [BS06]. Umso größer die Zeitnähe von Daten ist, d. h. je schneller sich ändernde Daten aktualisiert und damit aus der realen Welt in den Datenbestand übernommen werden, desto geringer ist das Qualitätsproblem, das die Volatilität verursachen kann. Dieses Qualitätsproblem entsteht dann, wenn ein Datum nicht mehr aktuell ist, weil sich das Objekt der realen Welt, das repräsentiert wird, bereits geändert hat, diese Änderung aber noch nicht übernommen wurde. Sich ändernde Daten lassen sich entsprechend ihrer Aktualität in aktuelle und nicht aktuelle Daten einordnen. Bei sich in regelmäßigen Abständen ändernden Daten kann die Aktualität anhand der letzten Änderung ermittelt werden [BS06]. Sollten Daten benötigt werden, diese aber nicht aktuell sein, so stellt dies ein Qualitätsproblem dar. Hierauf bezieht sich die Rechtzeitigkeit, mit der Daten zur Verfügung stehen. Sie bezieht nicht nur die Aktualität der Daten an sich mit ein, sondern auch, dass diese rechtzeitig, d. h. vor ihrer Nutzung, bereit stehen [BS06] Konsistenz und Integrität Konsistenz ist die Widerspruchsfreiheit einer Menge von Daten gegenüber semantischen Regeln. Diese semantischen Regeln können sich sowohl auf einzelne oder mehrere Attribute einer Relation, aber auch auf einzelne oder mehrere Tupel einer oder mehrerer Relationen gleichzeitig beziehen. Entsprechend lassen sie sich einteilen in intrarelation constraints, d. h. Bedingungen die sich auf einzelne oder mehrere Attribute oder Tupel einer Relation beziehen, und interrelation constraints, die sich auf Beziehungen zwischen Tupeln einzelner Relationen beziehen [BS06]. Intrarelationale Bedingungen können Eingrenzungen des Wertebereichs von einzelnen Attributen sein. Beispielsweise hat eine deutsche Postleitzahl fünf Stellen. Eine vierstellige Zahl wäre also nicht zulässig [BS06]. 17

24 2. Datenqualität Eine weitere Möglichkeit, die Werte eines Attributs einzuschränken, ist, nur bestimmte Werte zuzulassen, die vorher definiert wurden. Dies können auch alphanumerische Werte sein, die sich nicht über eine einfache Bereichsfestlegung definieren lassen, sondern nur über eine Auflistung der zulässigen Werte [Vos08]. Entsprechend kann eine Abhängigkeit zwischen mehreren Attributen bestehen, wenn ein Attribut die Postleitzahl und ein zweites Attribut den dazugehörigen Ort darstellt [RD00]. Hätte die Postleitzahl den Wert und der Ort wäre Kiel, so wäre dies eine Inkonsistenz, da die gegebene Postleitzahl nicht zu Kiel, sondern zu Hildesheim gehört. Auch kann eine Abhängigkeit der Form bestehen, dass zwei Attribute, die ähnliche Daten enthalten, nicht identisch sein dürfen. Dies gilt beispielsweise für Telefon- und Faxnummern [Vos08]. Schlüsselabhängigkeiten innerhalb einer Relation besagen, dass eine Menge von Attributen, die Schlüssel einer Relation ist, eindeutig sein muss. In Datenbanken lassen sich diese Schlüssel in Form von Primärschlüsseln und Unique-Constraints abbilden, wobei je Relation nur ein Primärschlüssel, aber mehrere Unique-Constraints möglich sind [Vos08]. Die sinnvolle Anwendung von Schlüsseln kann helfen, die in beschriebenen Duplikate zu vermeiden. Allgemein lassen sich Abhängigkeiten zwischen Attributen einer Relation mit Hilfe von funktionalen Abhängigkeiten definieren. Funktionale Abhängigkeiten legen fest, dass ein Attribut oder eine Attributmenge über eine Funktion ein oder mehrere Attribute bestimmen. Allgemein werden funktionale Abhängigkeiten in der Form f : X Y geschrieben, wobei Y von X abhängt und X und Y Mengen von Attributen repräsentieren. Daraus folgt, dass wenn die Werte der Attribute in X gleich sind, auch die Werte der Attribute in Y gleich sind [Vos08]. Interrelationale Bedingungen beziehen sich auf Attributmengen aus mehreren Relationen [BS06]. Zu den interrelationalen Bedingungen gehören Inklusionsabhängigkeiten, mit Fremdschlüsselbedingungen als spezielle Form der Inklusionsabhängigkeit, und Exklusionsbedingungen [Vos08]. Inklusionsabhängigkeiten legen fest, dass die Werte einer Teilmenge von Attributen einer Relation auch in den Werten einer Teilmenge von Attributen einer anderen Relation vorkommen müssen. Für Inklusionsabhängigkeiten allgemein gibt es dabei keine Bestimmungen, aus welchen Attributen der Relationen die Attributmenge besteht, auf die sich die definierte Abhängigkeit bezieht. Es gibt jedoch mit Fremdschlüsselbeziehungen auch eine spezielle Form der Inklusionsabhängigkeiten. Fremdschlüsselbeziehungen definieren Teilmengen von Attributen einer Relation, die Schlüssel einer anderen Relation sind [Vos08]. Exklusionsabhängigkeiten sind das Gegenteil zu Inklusionsabhängigkeiten. Sie besagen, dass Werte einer Teilmenge von Attributen einer Relation nicht in den Werten einer Teilmenge von Attributen einer anderen Relation vorkommen dürfen. Sie müssen disjunkt sein. Ein Beispiel hierfür sind Is-A-Beziehungen zwischen einzelnen Relationen, wobei eine Exklusivität zwischen den einzelnen Subtypen besteht [Vos08] Weitere Dimensionen In den letzten Abschnitten wurden die nach [BS06] und [FG12] wichtigsten Dimensionen von Datenqualität vorgestellt. Diese beziehen sich auf die interne Qualität der Daten [Bq07]. Abbildung 2.2 zeigt eine Übersicht über einige Datenqualitäts-Dimensionen. 18

25 2.3. Dimensionen von Datenqualität Data Quality Dimensions Quality of the management of data by the system Quality of the representation of data by the system Intrinsic Data Quality Dimensions Relative Data Quality Dimensions Accessibility Acces Security Adaptability Clarity Accuracy Completeness User-dependent quality dimensions Focus of Interest Preferences Availability Concision Consistency Conformance to business rules Compressibility Ease of Exchange Ease of Maintenance Flexibility Interpretability Suitability Uniqueness Correctness Application-dependent quality dimensions Appropriateness Cost Criticallity Reliability Minimality Relevance Operability Understandability Currency Portability Responsiveness Well-documented Ability to represent null values Time-dependent quality dimensions Lineage Timeliness Reusability Presentation appropriateness Variability Consistency Conformity Conformance to schema Format Appropriateness Knowledge-dependent quality dimensions Credibility Objectivity Source reputation Verifiability Abbildung 2.2.: Übersicht über Datenqualitäts-Dimensionen [Bq07] Sie lassen sich einordnen in die vier Bereiche Qualität des Datenmanagements durch das System, Qualität der Datenrepräsentation im System, interne Qualität der Daten und Qualitätsdimensionen mit Bezug auf den Benutzer, die Anwendung, Zeit oder Wissen [Bq07]. Die Einordnung und Gewichtung der einzelnen Dimensionen ist dabei in der Literatur nicht einheitlich. Die vier wichtigsten Dimensionen Fehlerfreiheit, Vollständigkeit, Zeitabhängigkeit und Konsistenz wurden bereits in den Abschnitten 2.3.1, 2.3.2, und erläutert [Bq07]. Im Folgenden sollen nun weitere Qualitätsdimensionen vorgestellt werden, die zum Teil nur Bezug auf einzelne Domänen haben oder nur unter bestimmten Bedingungen Relevanz haben [BS06] Glaubwürdigkeit Die Glaubwürdigkeit von Daten gibt an, ob die Daten für einen Benutzer verlässliche Informationen bieten können. Dieser Aspekt hängt zusammen mit der in Abschnitt beschriebenen Fehlerfreiheit der Daten. Diese Dimension spiegelt eine Sicht von außen auf die Daten wider, da vom Benutzer abhängt, ob er sich auf die Daten und den aus ihnen ermittelten Information verlassen kann oder nicht [WW96]. Es handelt sich hier also nicht um eine objektive, sondern eine eher subjektiv wahrgenommene Qualität von Daten [PLW02]. 19

26 2. Datenqualität Exaktheit Exaktheit von Daten gibt an, wie detailliert diese aufgenommen wurden [FLR94]. Werden Daten in Kategorien eingeteilt, so kann die Anzahl der Kategorien und Unterkategorien die Detailliertheit der Einteilungen angeben. Gibt ein Attribut ein Datum an, so kann die Genauigkeit dieser Datumsangabe sehr grob sein, wenn nur das Jahr angegeben wird, oder genau, wenn nicht nur das Jahr, sondern auch der Monat und der Tag angegeben werden. In relationalen Datenbanken wird diese erwartete Genauigkeit bereits durch den Typ des Attributs definiert [FLR94] Zugänglichkeit Die Zugänglichkeit von Daten für Benutzer lässt sich in zwei Bereiche aufteilen: erstens der physikalische Zusammenhang mit dem Zugriff auf Daten und zweitens die Fähigkeit des Benutzers, die Daten in ihrer Darstellungsform aufzunehmen. Der physikalische Zusammenhang der Zugänglichkeit für den Benutzer stellt dar, wie lange es dauert, bis der Benutzer angeforderte Daten erhält [PLW02] und wie einfach er diese anfordern kann [BS06]. In diesem Zusammenhang steht auch der Schutz von Daten durch passende Schutzmaßnahmen, die dem Benutzer ggf. den Zugang erschweren [Bq07]. Der zweite Punkt der Zugänglichkeit von Daten für den Benutzer zielt auf die Darstellungsform ab. Dabei ist entscheidend, ob dem Benutzer verständlich ist, was dargestellt wird. Dabei ist auch zu berücksichtigen, dass nicht alle Menschen gut sehen und hören können. Auch für diese sollte im Idealfall eine barrierefreie Möglichkeit bestehen, auf die Daten zuzugreifen [BS06] Interpretierbarkeit Um vorhandene Daten und aus ihnen gewonnene Informationen interpretieren zu können, benötigt der Benutzer Informationen darüber, was dargestellt wird und welche Bedeutung es hat. Dies kann ermöglicht werden, indem dem Benutzer eine Dokumentation zur Verfügung gestellt wird. Diese Dokumentation sollte sowohl die Bedeutung einzelner Attribute, als auch Zusammenhänge zwischen Attributen und Relationen beinhalten, wie sie in beschrieben wurden. Weiterhin kann sie Informationen über die Herkunft und Entwicklung der Daten bereitstellen, so z. B. wann die Daten aufgenommen wurden und durch wen sie erfasst oder importiert und bearbeitet wurden [BS06] Qualität fremder Datenquellen Die Qualität von Datenquellen ist eine Zusammenfassung mehrerer Qualitätsdimensionen. Sie soll dazu dienen, fremde Datenquellen vor der eigenen Nutzung bewerten zu können [BS06]. Zunächst einmal gelten sämtliche bereits genannten Dimensionen wie z. B. Korrektheit, Vollständigkeit und Konsistenz. Zusätzlich ist allerdings noch die Quelle an sich, d. h. der Urheber, und die Art der Datenerfassung zu bewerten [BS06]. Dies ist auch deshalb notwendig, da die interne Qualität der Daten nicht immer abschließend bewertet werden kann. Dies korrespondiert mit der bereits in vorgestellten Dimension der Glaubwürdigkeit. Um die Qualität der Datenaufnahme bewerten zu können, ist eine Abschätzung notwendig, ob 20

27 2.4. Abhängigkeiten zwischen einzelnen Datenqualitätsdimensionen diese Datenaufnahme unter objektiven Gesichtspunkten stattgefunden hat. Sollte dies nicht der Fall sein, so kann die Datenquelle Daten bereit stellen, die zu subjektiv und daher nicht brauchbar sind [BS06]. Allgemein zu bewerten ist auch die Reputation derer, welche die Daten bereitstellen. Haben diese ein hohes Ansehen, ist eher davon auszugehen, dass es sich um brauchbare Daten handelt [BS06]. Sollten die Daten aus einer unbekannten Quelle stammen, so ist entsprechend eine genauere Überprüfung der internen Datenqualität notwendig. Diese sollte allerdings auch bei einer Quelle mit hoher Reputation nicht vernachlässigt werden Abhängigkeiten zwischen einzelnen Datenqualitätsdimensionen Hohe Datenqualität kann selten in allen Dimensionen auf einmal erreicht werden. Dies begründet sich durch die Abhängigkeiten, die zwischen den einzelnen Datenqualitätsdimensionen bestehen [BS06]. Zunächst als wichtigste Abhängigkeit zu nennen ist die Aktualität auf der einen sowie die Dimensionen Fehlerfreiheit, Vollständigkeit und Konsistenz auf der anderen Seite. Das Erfüllen der drei genannten Dimensionen benötigt Zeit, indem zunächst entsprechende Überprüfungen neuer Daten durchgeführt werden. Entsprechend können neue Daten erst mit einer gewissen Zeitverzögerung in den Datenbestand aufgenommen werden [BS06]. Weiterhin besteht ein Zusammenhang zwischen Konsistenz und Fehlerfreiheit. So können Inkonsistenzen, z.b. bei funktionaler Abhängigkeit zwischen zwei Attributen, gleichzeitig bedeuten, dass für ein Tupel fehlerhafte Werte abgelegt wurden [FG12]. Es muss also je nach Anwendung abgewogen werden, welche Datenqualitätsdimension Priorität hat [BS06]. Entsprechend sollte immer die Datenqualität als Gesamtes behandelt werden und nicht nur ein einziger Aspekt [FG12] Relevanz Nachdem in den vorherigen Abschnitten auf Datenqualität an sich eingegangen wurde, sollen zum Abschluss dieses Kapitels kurz die Folgen von schlechter Datenqualität beleuchtet werden. Eine gute Datenqualität ist Voraussetzung, um Analysen mit guten Ergebnissen durchführen zu können [NOBE07], speziell im Bereich des Data Mining. Die hier existierenden Algorithmen sind für Daten von guter Qualität ausgelegt, aber nicht dafür, mit schlechten Daten umzugehen [Bq07]. Fehlende und fehlerhafte Daten, sowie Duplikate können die Ergebnisse dieser Berechnungen verfälschen. Hier kann auch das Vorhandensein einer geringen Anzahl von Duplikaten bereits Auswirkungen auf die Ergebnisse haben [NOBE07]. Dadurch entstehende fehlerhafte oder irreführende Statistiken [RD00] können dazu führen, dass durch daraus folgende fehlerhafte Annahmen hohe Kosten entstehen [BS06]. Aber nicht nur im Bereich des Data Mining, sondern auch in der allgemeinen Verwendung von Daten kann schlechte Datenqualität ein Hindernis darstellen. So können Daten schlechter Qualität den Ablauf von Prozessen innerhalb einer Organisation behindern [WW96] oder 21

28 2. Datenqualität unvollständige Daten ggf. gar nicht genutzt werden [FLR94]. In der Optimierung von Geschäftsprozessen können schlechte Daten eine Hürde zur weiteren Verbesserung dieser Prozesse darstellen [FLR94]. Im Kontext der Pharmakovigilanz kann es vorkommen, dass mit Hilfe statistischer Methoden Abhängigkeiten zwischen Arzneimitteln oder -stoffen und möglichen Nebenwirkungen ermittelt werden, bei denen kein realer Zusammenhang besteht. Es ist hier also besonders wichtig, dass Informationen, die aus einem Datenbestand gesammelt werden, später durch Fachleute untersucht und bewertet werden [PRPP12]. Ansonsten kann es vorkommen, dass fälschlicherweise Warnungen vor Nebenwirkungen von Medikamenten ausgesprochen werden, bei denen das Medikament nicht ursächlich für die Nebenwirkung ist [AB11]. 22

29 3. Qualität der FDA-Daten Nachdem im letzten Kapitel einzelne Datenqualitätsdimensionen vorgestellt wurden, soll in diesem Kapitel nun eine Untersuchung der Daten, welche von der FDA aus ihrem Spontanmeldesystem AERS zur Verfügung gestellt werden, durchgeführt werden FDA AERS AERS ist das Spontanmeldesystem der FDA. Es wird von der FDA eingesetzt, um Informationen über unerwünschte Ereignisse zu sammeln, die auf Grund von gesetzlichen Vorschriften von Herstellern pharmazeutischer Produkte an die FDA gemeldet werden. Weiterhin werden auch freiwillige Meldungen von Privatpersonen und von im Gesundheitswesen tätigen Personen gesammelt [The12c]. Innerhalb der FDA wird AERS genutzt, um die Aktivitäten im Rahmen der Beobachtung von Medikamenten nach ihrer Marktzulassung zu unterstützen [The12c]. Meldungen von unerwünschten Ereignissen an die FDA können sowohl in Schriftform, als auch elektronisch getätigt werden. Der Großteil der an die FDA getätigten Meldungen wird in AERS erfasst. Nicht erfasst werden Meldungen von Herstellern, die in Schriftform getätigt werden und keine gravierenden Ereignisse melden, da mit deren Erfassung ein gewisser Aufwand für die manuelle Eingabe ins System verbunden ist. Grundsätzlich erfasst werden Meldungen, die in elektronischer Form getätigt werden, oder die nicht von Herstellern, d. h. von Privatpersonen oder im Gesundheitswesen tätigen Personen, wie Ärzten und Krankenpflegern, stammen [The12d]. Die Rohdaten des AER-Systems werden quartalsweise [The13], mit einer Verzögerung von sechs Monaten [PRPP12], von der FDA veröffentlicht. Dies geschieht auf Grund des Freedom of Information Act (FOIA), der jeder Person erlaubt, Einsicht in die Daten von amerikanischen Behörden zu nehmen, insofern diese nicht einem speziellen Schutzanspruch unterliegen [Uni11]. Neben den von der FDA gesammelten Meldungen aus den USA enthält AERS auch Meldungen aus anderen Ländern [The12b]. Dies sind allerdings primär Meldungen zu kritischen Ereignissen, die noch nicht innerhalb des Beipackzettels des Medikaments Erwähnung finden [PRPP12]. In den folgenden Unterabschnitten soll nun untersucht werden, wie die Verteilung der Meldungen auf die einzelnen Quellen aussieht, in welcher Art die Meldungen getätigt wurden und ob sie in AERS aufgenommen wurden, und zuletzt wie sich die Meldungen auf die einzelnen Herkunftsländer verteilen. Zuvor soll noch ein kurzer Überblick über die allgemeine Entwicklung bei der Anzahl Meldungen, die in AERS aufgenommen wurden, gegeben werden. 23

30 2004q1 2004q2 2004q3 2004q4 2005q1 2005q2 2005q3 2005q4 2006q1 2006q2 2006q3 2006q4 2007q1 2007q2 2007q3 2007q4 2008q1 2008q2 2008q3 2008q4 2009q1 2009q2 2009q3 2009q4 2010q1 2010q2 2010q3 2010q4 2011q1 2011q2 2011q3 2011q4 2012q1 2012q2 3. Qualität der FDA-Daten Anzahl Meldungen Abbildung 3.1 zeigt je Quartal die Anzahl der in AERS aufgenommenen Meldungen. Es ist ein Verlauf zu erkennen, der zeigt, dass die Anzahl der je Quartal in AERS übernommenen Meldungen seit 2004 ansteigt. Mögliche Gründe dafür sollen im Folgenden noch aufgezeigt werden Abbildung 3.1.: In AERS aufgenommene Meldungen Die genauen Zahlen zur Abbildung 3.1 befinden sich im Anhang in Tabelle A.1, wie auch zu allen folgenden Diagrammen die zu Grunde liegenden Zahlen im Anhang einzusehen sind Meldungen nach Quelle Wie bereits in 3.1 beschrieben, werden nicht alle an die FDA getätigten Meldungen übernommen. In AERS aufgenommen werden die Meldungen, die eine hohe Relevanz haben, da die gemeldete mögliche Nebenwirkung eines Medikaments bisher unbekannt ist. Des Weiteren werden grundsätzlich alle Meldungen aufgenommen, die elektronisch übermittelt werden, und Meldungen, die von Patienten, von im Gesundheitswesen tätigen Personen oder von sonstigen Quellen, außer den Herstellern von Pharmaprodukten, direkt an die FDA getätigt werden. Abbildung 3.2 zeigt für jedes Jahr zum einen die Anzahl der Meldungen, die direkt an die FDA getätigt wurden, aber nicht von Herstellern stammen (blaue Balken), und die Gesamtanzahl der von Herstellern stammenden Meldungen, aufgeteilt in Meldungen mit hoher Relevanz (braune Balken) und Meldungen mit geringerer Relevanz (rote Balken). Zudem zeigt sie, wie viele von diesen Meldungen in AERS aufgenommen wurden (jeweils heller-farbene Balken) [The12d]. Zu erkennen ist zum einen, dass immer mehr Meldungen insgesamt an die FDA getätigt werden, aber andererseits auch, dass der Anteil der Meldungen, die in AERS aufgenommen werden, gemessen an den insgesamt getätigten Meldungen, angestiegen ist. Eine mögliche Ursache 24

31 2004q1 2004q2 2004q3 2004q4 2005q1 2005q2 2005q3 2005q4 2006q1 2006q2 2006q3 2006q4 2007q1 2007q2 2007q3 2007q4 2008q1 2008q2 2008q3 2008q4 2009q1 2009q2 2009q3 2009q4 2010q1 2010q2 2010q3 2010q4 2011q1 2011q2 2011q3 2011q4 2012q1 2012q2 2004q1 2004q2 2004q3 2004q4 2005q1 2005q2 2005q3 2005q4 2006q1 2006q2 2006q3 2006q4 2007q1 2007q2 2007q3 2007q4 2008q1 2008q2 2008q3 2008q4 2009q1 2009q2 2009q3 2009q4 2010q1 2010q2 2010q3 2010q4 2011q1 2011q2 2011q3 2011q4 2012q1 2012q FDA AERS (Q1/Q2) Abbildung 3.2.: Meldungen nach Quelle [The12d] dafür kann die Zunahme an elektronisch getätigten Meldungen sein, wie der folgende Abschnitt zeigt Meldungen nach Art der Übermittlung Wie bereits erwähnt, ist die Art der Übermittlung einer Meldung an die FDA ein Faktor, ob diese in AERS aufgenommen wird oder nicht. Abbildung 3.3 zeigt die Entwicklung der Anzahl der Meldungen die in Schriftform an die FDA getätigt wurden (rote Linien), und der Meldungen, die elektronisch übermittelt und dann in AERS aufgenommen wurden (blaue Linien). Dabei ist im linken Bereich die Entwicklung in absoluten Zahlen dargestellt, während im rechten Bereich der relative Anteil der jeweiligen Meldungsart dargestellt ist % 90% % 70% % 50% % 30% % 10% 0 0% Abbildung 3.3.: Meldungen nach Art der Übermittlung 25

32 2005q3 2005q4 2006q1 2006q2 2006q3 2006q4 2007q1 2007q2 2007q3 2007q4 2008q1 2008q2 2008q3 2008q4 2009q1 2009q2 2009q3 2009q4 2010q1 2010q2 2010q3 2010q4 2011q1 2011q2 2011q3 2011q4 2012q1 2012q2 3. Qualität der FDA-Daten Zu erkennen ist, dass die absolute Zahl der Meldungen in Schriftform im Laufe der Zeit leicht zurückgegangen ist, wohingegen die Anzahl der Meldungen, die elektronisch übermittelt wurden, stark angestiegen ist. Entsprechend wächst der relative Anteil der elektronischen Meldungen beständig an. Dies erklärt dann auch den ständigen Anstieg der Meldungen, die je Quartal in AERS aufgenommen werden, da sämtliche elektronischen Meldungen erfasst werden Meldungen nach Herkunftsland Die folgende Abbildung 3.4 zeigt den Anteil der Meldungen nach ihrer Herkunft je Kontinent, insofern diese nicht aus den USA stammen. 80% 70% 60% 50% 40% 30% 20% Afrika Asien Europa Nordamerika Ozeanien Südamerika USA Unbekannt 10% 0% Abbildung 3.4.: Meldungen nach Herkunftsland Dieses Diagramm beginnt, im Gegensatz zu den anderen bereits gezeigten Diagrammen und den folgenden Diagrammen, erst im dritten Quartal 2005, da die Information, aus welchem Land eine Meldung stammt, erst ab diesem Quartal von der FDA zur Verfügung gestellt wird. Zu erkennen ist, dass trotz der in gezeigten Zunahme der Anzahl an getätigten Meldungen, die Niveaus relativ konstant bleiben. Der Hauptteil der Meldungen stammt aus den USA selbst. Der Großteil an Meldungen, die nicht aus den USA stammen, kommt aus Europa, gefolgt von Asien. Alle anderen Kontinente nehmen eine eher untergeordnete Rolle ein, wobei auch diese sich auf einem relativ konstanten, niedrigen Niveau bewegen. Aus anderen Ländern als den USA nimmt die FDA nur solche Meldungen auf, die kritische Ereignisse melden [PRPP12]. Daraus, dass es in den Anteilen zwischen den Kontinenten keine Verschiebungen gibt, lässt sich schließen, dass der Anteil an kritischen Meldungen im Laufe der Zunahme an insgesamt getätigten Meldungen gleich geblieben ist. 26

33 3.2. Aufbau der Dateien Nachdem in den letzten Abschnitten allgemeine Entwicklungen aufgezeigt wurden, soll nun im Folgenden zunächst der Aufbau der von der FDA zur Verfügung gestellten Daten beschrieben werden. Anschließend folgt eine allgemeine Statistik über die Anzahl der bereit gestellten Datensätze, woran sich die Analyse der Daten bzgl. der in Kapitel 2 beschriebenen Datenqualitätsdimensionen anschließt Aufbau der Dateien Die quartalsweise von der FDA veröffentlichten Rohdaten können auf der Webseite der FDA in Form von ZIP-Dateien heruntergeladen werden. Die FDA stellt die Rohdaten sowohl als ASCII-Dateien, als auch in Form von SGML-Dateien zur Verfügung [The13]. Folgende Dateien sind im Falle der ZIP-Dateien, welche die Rohdaten in Form von ASCII- Dateien beinhalten, enthalten [U.S12b]: eine allgemeine Informationsdatei eine Datei, die Informationen über die Anzahl der Datensätze je Teildatei und deren physischer Größe beinhaltet eine Dokumentationsdatei, in der sämtliche Felder und ihre Bedeutung beschrieben sind die eigentlichen Datendateien Die Rohdaten stammen aus einer relationalen Datenbank [The13]. Diese enthält sieben Tabellen, deren Struktur durch die Datendateien wiedergegeben wird [EZ13b]: DEMO - enthält grundlegende Daten über den Patienten und administrative Informationen und bildet damit die Basis jedes Reports DRUG - enthält die Informationen über eingenommene Medikamente INDI - enthält die Befunde, auf Grund derer Medikamente verordnet wurden OUTC - enthält den Ausgang der jeweiligen Behandlung REAC - enthält die im Zusammenhang mit einer Medikamenteneinnahme aufgetretenen Ereignisse RPSR - enthält Informationen über die Quelle der Daten eines Reports THER - enthält, zusätzlich zu den Daten aus DRUG, Angaben über den Zeitraum und die Dauer der Einnahme eines Medikaments Abbildung 3.5 zeigt die verwendete Datenstruktur noch einmal in Form eines relationalen Datenbankschemas, basierend auf den Informationen aus [U.S12a]. 27

34 3. Qualität der FDA-Daten demo ISR INT(10) CASE INT(10) I_F_COD CHAR(1) reac FOLL_SEQ CHAR(2) ISR INT(10) PT CHAR(100) Indexes outc ISR INT(10) OUTC_CODE CHAR(2) Indexes rpsr ISR INT(10) RPSR_COD CHAR(3) Indexes IMAGE CHAR(12) EVENT_DT INT(8) MFR_DT INT(8) FDA_DT INT(8) REPT_COD CHAR(3) MFR_NUM CHAR(100) MFR_SNDR CHAR(60) AGE DECIMAL(7,2) AGE_COD CHAR(3) GNDR_COD CHAR(3) E_SUB CHAR(1) WT DECIMAL(11,5) WT_COD CHAR(3) REPT_DT INT(8) OCCP_COD CHAR(2) DEATH_DT INT(8) drug ISR INT(10) DRUG_SEQ INT(10) ROLE_COD CHAR(2) DRUGNAME CHAR(70) VAL_VBM INT(1) ROUTE CHAR(28) DOSE_VBM CHAR(100) DECHAL CHAR(1) RECHAL CHAR(1) LOT_NUM CHAR(35) EXP_DT INT(8) NDA_NUM CHAR(7) Indexes ther ISR INT(10) DRUG_SEQ INT(10) START_DT INT(8) END_DT INT(8) DUR INT(5) DUR_COD CHAR(3) Indexes TO_MFR CHAR(1) CONFID CHAR(1) REPORTER_COUNTRY CHAR(50) Indexes indi ISR INT(10) DRUG_SEQ INT(10) INDI_PT CHAR(100) Indexes Abbildung 3.5.: FDA AERS - relationales Datenbankschema 3.3. Bereitgestellte Datensätze Im Folgenden soll die Anzahl der bereitgestellten Datensätze je Datei begutachtet werden. Abbildung 3.6 zeigt in absoluten Zahlen den Verlauf der Anzahl an Datensätzen. Im Wesentlichen korreliert die Anzahl der Datensätze in allen Dateien mit der Anzahl an Meldungen (Anzahl Datensätze in Demo). Ausnahme sind hier die Angaben zur Person oder Firma, die die Meldung getätigt hat. Hier nimmt die Anzahl an Datensätzen, trotz des allgemein gegenläufigen Trends, ab. Dies führt dann auch dazu, dass die durchschnittliche Anzahl an Datensätzen je Meldung, wie sie Abbildung 3.7 zeigt, abnimmt. Im Gegensatz dazu bleibt bei den anderen Typen das Niveau relativ konstant. Dabei liegen zu einer Meldung durchschnittlich knapp vier Datensätze zu aufgetretenen Ereignissen und ebenfalls knapp vier zu eingenommenen Medikamenten vor. Trotz der durchschnittlich vier angegebenen Medikamenten liegen im Schnitt nur zwischen ein und zwei Angaben zu Zeitraum und Dauer der Medikamenteneinnahme vor. Zwischen ein und zwei Einträge liegen je Meldung zum Befund, der zur Medikamenteneinnahme führte, vor. Hier ist eine leicht zunehmende Tendenz zu erkennen. Im Schnitt liegt knapp eine Angabe zum Ausgang der Behandlung vor. Dass diese Angabe nicht zu jeder Meldung gegeben ist, resultiert sicherlich daraus, dass viele Meldungen bereits vor Ende der Behandlung getätigt werden. 28

35 2004q1 2004q2 2004q3 2004q4 2005q1 2005q2 2005q3 2005q4 2006q1 2006q2 2006q3 2006q4 2007q1 2007q2 2007q3 2007q4 2008q1 2008q2 2008q3 2008q4 2009q1 2009q2 2009q3 2009q4 2010q1 2010q2 2010q3 2010q4 2011q1 2011q2 2011q3 2011q4 2012q1 2012q2 2012q Analyse demo drug indi outc reac rpsr ther Abbildung 3.6.: Anzahl bereitgestellter Datensätze drug indi outc reac rpsr ther 1 0 Abbildung 3.7.: Anzahl bereitgestellter Datensätze je Meldung 3.4. Analyse Im Folgenden sollen nun die Ergebnisse der Datenanalyse bzgl. der in 2 vorgestellten Qualitätsdimensionen beschrieben werden. Dabei werden zunächst die Tabellen und ihre Felder isoliert betrachtet, bevor anschließend tabellenübergreifende Qualitätsaspekte beleuchtet werden. 29

36 3. Qualität der FDA-Daten Allgemein Allgemein ist festzuhalten, dass die Aspekte der in vorgestellten Zeitabhängigkeit von Daten bei allen Tabellen identisch sind. Die Daten sind als stabil zu bezeichnen, da einmal getätigte Meldungen nicht ständig verändert werden. Möglich ist lediglich eine Korrektur, insofern eine Meldung fehlerhaft veröffentlicht wurde. Bei Ergänzungen, z. B. Informationen über den Ausgang der Behandlung, folgt eine weitere Meldung als Nachfolge-Meldung. Die vorherige Meldung bleibt dabei allerdings unberührt [U.S12b]. Die Volatilität ist damit also sehr gering. Auf Grund der verzögerten Veröffentlichung ist die Aktualität des Gesamtdatenvolumens nicht sehr hoch. Dadurch kann es dazu kommen, dass mögliche Abhängigkeiten zwischen Arzneimitteln bzw. -stoffen und möglichen Nebenwirkungen erst verspätet ermittelt werden können. Nicht überprüft werden kann, ob die angegebenen Werte in Bezug auf die Abbildung der realen Daten eines Patienten bzw. einer Behandlung, korrekt sind. Es existieren Meldungen, welche von mehreren Quellen eingereicht wurden. Diese erhalten durch die FDA jeweils einen eigenen Identifikator, beschreiben aber den gleichen Fall, d. h. den gleichen Patienten, der sich in einer Behandlung befindet. Mögliche Gründe hierfür sind zum einen, dass Meldungen, die direkt an die FDA getätigt wurden, vom Meldenden auch gleichzeitig beim Hersteller des Produktes eingereicht wurden. Dieser ist wiederum verpflichtet, bei ihm eingehende Meldungen an die FDA weiterzuleiten. Zum zweiten kann es durch den Transfer von Meldungen von Institutionen aus anderen Ländern, welche dort die Aufgaben erfüllen, die in den USA die FDA inne hat, dazu kommen, dass Meldungen mehrfach vorkommen [PRPP12] Demo isr Die individual safety report number (ISR number) ist ein eindeutiger Identifikator für eine bei der FDA eingegangene Meldung. Die ISR ist für alle Einträge in den Datendateien der FDA vorhanden. Innerhalb eines Quartals ist die ISR in der Tabelle Demo jeweils eindeutig. Allerdings folgen im nächsten Quartal nach ihrer ersten Verwendung teilweise Korrekturen. Bei Aufnahme aller veröffentlichten Daten ist die ISR damit nicht eindeutig. Es ist also eine entsprechende Korrekturmaßnahme notwendig, um die von der FDA veröffentlichten Korrekturen zu übernehmen und damit den jeweils aktuellsten Stand einer Meldung aufzunehmen und gleichzeitig Duplikate zu vermeiden. Die Bereinigung der Daten ist Inhalt von Abschnitt im folgenden Kapitel case_no Die Fallnummer (case_no) ordnet eine Meldung einem Fall zu. Es kann vorkommen, dass zu einem Fall mehrere Meldungen vorliegen [U.S12a]. Ein Fall bezeichnet dabei die Behandlung eines Patienten. Folgemeldungen liefern dabei weitere Informationen über den Fortgang einer 30

37 3.4. Analyse Behandlung, die möglicherweise zu Beginn noch nicht vorgelegen haben. Dies ist bspw. beim Ausgang der Behandlung der Fall. Da jeder Meldung eine Fallnummer zugeordnet wird, sollte diese auch zu jeder Meldung vorliegen. Außer bei sieben Meldungen aus dem ersten Quartal 2004 ist dies auch der Fall, und damit sind die Angaben zu Fallnummern weitgehend vollständig i_f_cod Das Feld i_f_cod gibt an, ob es sich bei einer Meldung um eine Anfangsmeldung oder eine Folgemeldung handelt. Diese Angabe basiert auf Angaben des Herstellers und ist unabhängig von der Fallzuordnung der FDA, welche über die Fallnummer erfolgt [U.S12a]. Zu diesem Feld liegen lediglich im Zeitraum vom ersten Quartal 2004 bis einschließlich dem ersten Quartal 2006 eine sehr geringe Anzahl Datensätze vor, zu denen dieser Status unbekannt ist (vergleiche hierzu auch Tabelle A.8) Followup Initial Unknown Abbildung 3.8.: Anfangs- und Folgemeldungen Abbildung 3.8 zeigt die Verteilung der Meldungen auf Anfangs- und Folgemeldungen. Zu erkennen ist, dass die Anzahl der Anfangsmeldungen durchschnittlich mindestens doppelt so groß ist, wie die Anzahl an Folgemeldungen. Die Anzahl der Anfangsmeldungen nimmt dabei mehr zu als die Anzahl der Folgemeldungen. Bis auf die wenigen Einträge mit unbekannt als Angabe am Anfang des Betrachtungszeitraums ist zu allen Meldungen die Angabe, ob es sich um eine Anfangs- oder Folgemeldung handelt, vorhanden. 31

38 3. Qualität der FDA-Daten foll_seq Im Zusammenhang mit dem im vorigen Abschnitt beschriebenen Feld i_f_cod steht das Feld foll_seq". Es handelt sich hierbei um ein Freitextfeld, welches Angaben des Herstellers zu einer nicht näher spezifizierten laufenden Nummer enthält. Eine sehr geringe Anzahl an Meldungen enthält neben numerischen Zeichen auch Buchstaben und Sonderzeichen [U.S12a] image Das Feld image enthält einen eindeutigen Identifikator der für Anfragen an die FDA im Rahmen des FOIA genutzt werden soll. Dieser Identifikator ist für jede Meldung eindeutig und enthält die ISR inklusive eines alphanumerischen Prüfsymbols [U.S12a]. Da das Berechnungsverfahren für die Prüfsumme nicht bekannt ist, konnte dieser Identifikator nur auf den Bestandteil der ISR überprüft werden. Im Rahmen dieser Überprüfung traten keine Fehler auf. Die Angaben für diesen Identifikator sind vollständig event_dt Wann ein unerwünschtes Ereignis aufgetreten ist, gibt das Feld event_dt an [U.S12a]. Abbildung 3.9 zeigt die Verteilung der aufgetretenen Ereignisse im Zeitraum vom bis zum Zwar enthalten die für diesen Zeitraum veröffentlichten Auszüge der Rohdaten aus AERS auch Ereignisse bis zurück ins 20. Jahrhundert, allerdings ist deren Anzahl nicht signifikant Abbildung 3.9.: Datum des unerwünschten Ereignisses Zu erkennen sind die sehr großen Peaks jeweils am 1. Januar eines Jahres und etwas kleinere Peaks jeweils zum 1. eines Monats. Dies ergibt sich daraus, dass die FDA Angaben zum Datum 32

39 3.4. Analyse des Ereignisses, insofern diese nicht auf den Tag genau sind, jeweils auf den ersten eines Monats bei Angabe von Monat und Jahr und auf den 1. Januar datiert, insofern nur das Jahr angegeben wurde [NOBE07]. Dies führt dazu, dass eine Exaktheit (vgl ) suggeriert wird, die nicht gegeben ist. Daher sollte grundsätzlich davon ausgegangen werden, dass Datumsangaben zum 1. Januar nur in Bezug auf das Jahr und Angaben zum ersten eines Monats nur auf Jahr und Monat genau sind. Hierbei ist zu beachten, dass Angaben, die ursprünglich auf Jahr und Monat genau waren, aber im Januar liegen, nur auf das Jahr genau angenommen werden können. Das Datum des Ereignisses ist zu 65,9% aller Meldungen angegeben. In diesen 65,9% sind 73 Einträge mit eindeutig ungültigen Datumsangaben enthalten. Diese ungültigen Datumsangaben liegen entweder sehr weit in der Vergangenheit oder in der Zukunft. Zum Teil lassen sich diese Angaben auf Tippfehler zurückführen. So könnte die Angabe auf den zurückzuführen sein, welches im konkreten Fall auch durch die weiteren Datumsangaben dieser Meldung unterstützt wird. Hier ist allerdings je Eintrag eine Einzelfallbetrachtung notwendig. Allgemein sollte hier eine einfache Validitätsprüfung durchgeführt werden, die solche Fehleingaben von vornherein eliminiert mfr_dt Meldungen, die zunächst beim Hersteller eines Medikaments eingehen und erst von diesem an die FDA weitergeleitet werden, enthalten, als Information wann die Meldung beim Hersteller eingegangen ist, eine Datumsangabe im Feld mfr_dt [U.S12a] Abbildung 3.10.: Datum der Übermittlung an den Hersteller Die Vollständigkeit der Angaben liegt bei 94,7%, wobei die restlichen gut 5% zum Großteil auf Meldungen zurückzuführen sind, die direkt an die FDA übermittelt wurden Meldungen wurden von Herstellern an die FDA getätigt und enthalten keine Angabe, wann die Meldung 33

40 3. Qualität der FDA-Daten beim Hersteller eingegangen ist. Wie auch bei den Daten zum Auftreten der Ereignisse gibt es hier Meldungen, deren Datumsangabe zum Eingang der Meldung beim Hersteller bis ins 20. Jahrhundert zurückreicht. Außerdem gibt es ebenfalls eindeutig fehlerhafte Datumsangaben. Wie in Abbildung 3.10 zu erkennen, gibt es einzelne Peaks. Diese unterliegen allerdings nicht einem strengen Muster, wie dies bei den im vorherigen Abschnitt analysierten Daten der Ereignisse der Fall ist. Eine mögliche Ursache für diese Peaks könnte das Einreichen der Ergebnisse von klinischen Studien sein fda_dt Das Feld fda_dt gibt an, wann eine Meldung bei der FDA eingetroffen ist [U.S12a]. Wie in Abbildung 3.11 zu erkennen, gibt es hier einzelne Peaks. Diese haben allerdings nicht das Ausmaß wie in Die Vollständigkeit dieser Angabe liegt bei 100% und es gibt auch keine Ausreißer. Die Peaks am Monatsanfang haben ein geringes Ausmaß. Am Jahresanfang treten im Vergleich zu den Monatsanfängen keine ungewöhnlich hohen Peaks auf. Der leichte Anstieg an Meldungen jeweils am Monatsanfang ist nicht auf mangelhafte Exaktheit zurück zu führen, sondern auf die periodisch von Herstellern getätigten Meldungen, die unkritische Ereignisse melden, welche nicht einer strengen Auflage zur sofortigen Meldung bei der FDA unterliegen [The12d] Abbildung 3.11.: Datum der Übermittlung an die FDA rept_cod Wie bereits weiter oben beschrieben unterscheidet die FDA zwischen freiwilligen Meldungen, die direkt an sie getätigt werden, und Meldungen von Herstellern, die zum einen dringende 34

41 3.4. Analyse Meldungen und zum anderen weniger dringende Meldungen tätigen [U.S12a]. Zu allen Meldungen liegt diese Einordnung vor. Da auf die Verteilung bereits in eingegangen wurde, soll diese hier nicht weiter untersucht werden mfr_num Die von Herstellern verwendeten Identifikatoren zur internen Identifizierung von Meldungen werden von der FDA im Feld mfr_num gespeichert. Sollte es sich nicht um eine Meldung von einem Hersteller handeln, so wird dieses Feld für eine interne Identifikationsnummer der FDA verwendet [U.S12a]. In 99,999% der Meldungen, welche von Herstellern stammen (rept_cod!= DIR ), ist diese Identifikationsnummer vorhanden, also weitgehend vollständig. Im Falle von direkt an die FDA getätigten Meldungen (rept_cod = DIR ) ist diese Angabe vollständig mfr_sndr Der Name des Herstellers, welcher eine Meldung an die FDA übermittelt hat, wird im Feld mfr_sndr vermerkt. Es handelt sich hierbei um ein Freitextfeld [U.S12a]. Entsprechend variiert die Bandbreite der Schreibweisen zur gleichen Firma. Speziell Kürzel wie Inc und Ltd werden hier in einer Vielzahl von Varianten an den Namen einer Firma angehängt, wobei meist eine Schreibweise dominierend ist. Weiterhin treten, wenn auch nur in einem sehr geringen Ausmaß, wenig sinnstiftende Einträge wie "///////äuf. Der Name des Herstellers ist in ca. 94% der Meldungen angegeben. Lediglich bei 371 Meldungen, welche von Herstellern stammen, ist der Name des sendenden Herstellers nicht angegeben age und age_cod Altersangaben in AERS bestehen aus zwei Feldern. Zunächst aus einem numerischen Wert im Feld age und weiterhin aus einem Feld age_cod, welches die Einheit des in age angegebenen Wertes bestimmt [U.S12a]. Die im Feld age_cod angegebenen Einheiten sind, insofern es sich nicht um NULL-Werte handelt, gültig. Ausnahme ist hier eine Meldung aus dem vierten Quartal 2010, in der das Alter als 1 MIN angegeben ist. Diese Angabe ist in Bezug auf die Spezifikation der FDA syntaktisch falsch, würde allerdings allgemein als gültig angesehen werden. Auf Grund von Umstellungen seitens der FDA bzgl. der Berechnung von Altersangaben aus dem Geburtsdatum, insofern kein Alter in der Meldung angegeben wurde, ist die Anzahl an Vorkommen, bei denen nur age oder nur age_cod einen Wert aufweisen, erheblich gestiegen. Ende 2008 ergänzte die FDA Altersberechnungen auf Basis des Geburtsdatums, insofern das Alter nicht direkt angegeben wurde, auch in ihren Datenexporten. Diese Berechnung nutzte die FDA vorher bereits intern und stellte damit der Öffentlichkeit genauere Informationen zur Verfügung. Auf Grund eines Fehlers in dieser Berechnung wurde zunächst vom vierten Quartal 2008 bis einschließlich zum ersten Quartal 2010 bei automatischen Berechnungen der Wert für age_cod nicht auf YR gesetzt, wie es eigentlich korrekt gewesen wäre. Ab dem zweiten Quartal wurde dies so korrigiert, dass YR nun der Standardwert für age_cod ist, was dazu führt, dass age_cod fast keine NULL-Werte mehr beinhaltet, sondern auch den Wert YR 35

42 3. Qualität der FDA-Daten aufweist, wenn keine Altersberechnung stattgefunden hat [U.S12b]. Negative Altersangaben bedeuten, dass eine Meldung sich auf ein ungeborenes Kind bezieht [U.S12a]. Es liegen aber auch Altersangaben wie z. B. -11 YR oder sogar -933 YR vor. Bei diesen Angaben ist auch ohne Kenntnis des konkreten Falls davon auszugehen, dass sie fehlerhaft sind Jahrzehnte Tage Stunden Monate Wochen Jahre Ungültige Angabe Abbildung 3.12.: Altersangaben Abbildung 3.12 zeigt die Verteilung der gültigen Altersangaben auf die einzelnen Zeiteinheiten und die Anzahl Meldungen ohne gültige Altersangabe. Die zusätzliche Berechnung des Alters auf Basis des Geburtsdatums und die korrigierte Angabe der Zeiteinheit ab dem zweiten Quartal 2010 sind hier deutlich zu erkennen. Weniger deutlich lässt sich jedoch die zuvor erhöhte Häufigkeit von Altersangaben ohne Zeiteinheit ablesen. Des Weiteren ist zu erkennen, dass die meisten Altersangaben in Jahren erfolgen. Alle anderen Zeiteinheiten spielen fast keine Rolle. Ihr Vorkommen liegt regelmäßig jeweils unter 1000, wie auch Tabelle A.10 zeigt gndr_cod Abbildung 3.13 zeigt die Verteilung auf die einzelnen möglichen Angaben zum Geschlecht des Patienten, wie sie das Feld gndr_cod enthält. Neben der Unterscheidung zwischen männlich und weiblich finden sich hier drei weitere Möglichkeiten: Unbekannt, nicht spezifiziert und NULL [U.S12a]. Welche konkrete Bedeutung der NULL-Wert an dieser Stelle hat, bleibt offen. Die Unterscheidung zwischen unbekannt und nicht spezifiziert ist auf Grund der geringen Anzahl Meldungen, bei denen das Geschlecht hiermit angegeben wurde, im Vergleich zu der großen Anzahl Meldungen mit NULL-Wert, wenig informativ (vergleiche hierzu auch Tabelle A.11 im Anhang). Im Schnitt ist bei mehr als 90% der Meldungen angegeben, ob der Patient männlich oder 36

43 3.4. Analyse weiblich männlich nicht spezifiziert unbekannt NULL Abbildung 3.13.: Angaben zum Geschlecht weiblich war. Der Anteil Meldungen zu weiblichen Patienten ist durchgehend höher als der Anteil zu männlichen Patienten. Die Angaben unbekannt und nicht spezifiziert spielen mit weniger als 1% fast gar keine Rolle (vergleiche Tabelle A.12) e_sub Das Feld e_sub ist ein boolesches Feld, in dem angegeben wird, ob eine Meldung auf elektronischem Wege erfolgte oder nicht. Meldungen, die nicht elektronisch erfolgten, wurden in Papierform eingereicht [U.S12a]. Die Verteilung der Meldungen auf elektronische und schriftliche Übermittlung wurde bereits in beleuchtet. Die Angaben zur Art der Übermittlung sind vollständig wt und wt_cod Die Angabe des Gewichts ist, ähnlich wie die Angabe des Alters, aufgeteilt auf zwei Felder. Zum einen ein numerischer Wert im Feld wt und zum anderen im Feld wt_cod die Gewichtseinheit. Mögliche Einheiten sind Gramm, Kilogramm und Pfund [U.S12a]. Abbildung 3.14 zeigt die Verteilung auf die einzelnen Einheiten. Angaben in Gramm spielen fast keine Rolle und kommen in einigen Quartal gar nicht vor. Angaben in Pfund gehen zurück, trotz der insgesamt steigenden Anzahl an Meldungen. Die Anzahl der Angaben in Kilogramm nimmt etwas weniger zu als die Gesamtanzahl an Meldungen. Der Anteil an Meldungen, zu welchen keine Gewichtsangabe des Patienten vorliegt, liegt jeweils über 60% mit einer leicht zunehmenden Tendenz. Anders als bei den Altersangaben, bei welchen zum Teil nur age oder nur age_cod einen Wert enthielten, bzw. zum Teil eindeutig fehlerhafte Angaben vorlagen, sind die Gewichtsanga- 37

44 3. Qualität der FDA-Daten keine Angabe Gramm Kilogramm Pfund Abbildung 3.14.: Einheiten von Gewichtsangaben ben durchweg stimmig. Entweder liegt weder in wt, noch in wt_cod, ein Wert vor, oder in beiden. Inkonsistenzen gibt es hier nicht. Auch fehlerhafte Gewichtsangaben, wie z. B. negative Angaben, liegen nicht vor. Es wurden nur die vorgesehenen Einheiten verwendet rept_dt Das Datum, an welchem eine Meldung abgesendet wurde, enthält das Feld rept_dt [U.S12a]. Diese Angabe ist zu 99,998% vollständig. Der Großteil der Meldungen, zu denen dieses Datum fehlt, sind direkte Meldungen an die FDA. Gehäufte Vorkommen zum Monats- oder Jahresbeginn sind nicht zu erkennen. Die unregelmäßig auftretenden Peaks decken sich zum Großteil mit den unregelmäßigen Peaks, welche auch beim Feld fda_dt auftreten occp_cod Die Information, welcher Berufsgruppe derjenige angehört, welcher eine Meldung direkt an die FDA oder auch zunächst an einen Hersteller getätigt hat, enthält das Feld occp_cod. Hier wird unterschieden zwischen Ärzten, Apothekern, anderen im Gesundheitswesen Tätigen, Rechtsanwälten und Patienten [U.S12a]. Abbildung 3.16 zeigt die Verteilung der Meldenden zu den einzelnen Gruppen. Zunächst gehen die meisten Meldungen von Ärzten aus. Dies ändert sich im Zeitverlauf zugunsten der Meldungen, die direkt von Patienten stammen. Dies liegt möglicherweise an einem erhöhten Bewusstsein der Patienten über die Möglichkeit, dass Arzneimittel Nebenwirkungen haben können. Der Anteil der von Apothekern gemeldeten möglichen Nebenwirkungen liegt auf relativ niedrigem Niveau und steigt nur leicht an, während die Anzahl der Meldungen von 38

45 3.4. Analyse Abbildung 3.15.: Datum des Absendens einer Meldung Ärzten und Patienten entsprechend der allgemeinen Zunahme an Meldungen erheblich stärker zunimmt. Die Anzahl der von Anwälten getätigten Meldungen liegt im Schnitt unter der von Apothekern. Andere im Gesundheitswesen tätige Personen melden ebenfalls zunehmend Verdachtsfälle. Ihre Anzahl liegt aber ständig unter der von Ärzten. Der Anteil der Meldungen, die keine Angabe zur meldenden Person haben, nimmt ab. Ihr Anteil ist von ca. 26% zu Beginn des Betrachtungszeitraums auf unter 5% gefallen Patient Anwalt Arzt Andere Apotheker Unbekannt Abbildung 3.16.: Beruf des Meldenden 39

46 2004q1 2004q2 2004q3 2004q4 2005q1 2005q2 2005q3 2005q4 2006q1 2006q2 2006q3 2006q4 2007q1 2007q2 2007q3 2007q4 2008q1 2008q2 2008q3 2008q4 2009q1 2009q2 2009q3 2009q4 2010q1 2010q2 3. Qualität der FDA-Daten death_dt Das Feld death_dt gibt das Todesdatum des Patienten an, insofern dieser im Laufe der gemeldeten Behandlung verstorben ist. Dieses Feld wurde bis einschließlich des zweiten Quartals 2010 geführt. Anschließend wurde es von der FDA auf Grund von Datenschutzgründen nicht weiter gefüllt, blieb aber aus Kompatibilitätsgründen bestehen [U.S12a]. Die folgende Betrachtung bezieht sich daher nur auf den Zeitraum vom ersten Quartal 2004 bis einschließlich des zweiten Quartals ohne Behandlungsausgang ohne Todesdatum Gesamt Abbildung 3.17.: Angaben zum Todesdatum Ob ein Patient gestorben ist, ergibt sich zum einen aus dem Todesdatum und zum anderen aus dem Ausgang der Behandlung, welche in Outc angegeben wird. Abbildung 3.17 zeigt die Anzahl der Meldungen, welche anhand der zwei genannten Kriterien wiedergeben, dass der Patient gestorben ist. Weiterhin zeigt sie den Anteil der Meldungen, bei welchen das Todesdatum nicht eingetragen wurde, obwohl der Tod als Ausgang der Behandlung angegeben wurde und die Anzahl der Meldungen, bei denen ein Todesdatum, aber nicht der Tod als Behandlungsausgang, angegeben wurde. Der allgemeine Verlauf folgt jeweils dem allgemeinen Trend der Zunahme an Meldungen. Der Anteil der Fälle mit Todesfolge, bei denen das Todesdatum des Patienten nicht angegeben wurde liegt im Schnitt bei knapp 53%. Sie bilden den Großteil der Einträge, die nicht beide Angaben aufweisen. Der Anteil der Meldungen, welche nicht über die Angabe des Behandlungsausgangs verfügen, ist sehr gering to_mfr Das Feld to_mfr gibt an, ob jemand, der direkt an die FDA eine Meldung abgegeben hat, gleichzeitig auch den Hersteller informiert hat. Es hat also nur für direkt an die FDA getätigte 40

47 3.4. Analyse Meldungen Relevanz und ist für Meldungen, die von Herstellern stammen, leer [U.S12a]. Im Schnitt haben ca. 10% der Meldenden angegeben, auch den Hersteller informiert zu haben. Die restlichen ca. 90% haben dies nicht getan confid Ob die Identität desjenigen, der direkt an die FDA eine Meldung abgegeben hat, an den Hersteller weitergegeben werden darf oder nicht, gibt das Feld confid an. Dieses ist, wie das Feld to_mfr, bei von Herstellern getätigten Meldungen leer [U.S12a]. Gut zwei Drittel der Meldenden hat nichts gegen die Weitergabe der persönlichen Daten einzuwenden, das andere Drittel der Meldenden möchte dies nicht. Die beiden Anteile verhalten sich relativ konstant reporter_country Das Feld reporter_country nennt das Land, aus welchem derjenige stammt, der die Meldung abgegeben hat. Dies ist nicht zwingend das Land, in dem das Ereignis auftrat, meistens stimmt es aber überein [U.S12a]. Die Verteilung wurde bereits in aggregiert auf Kontinente betrachtet. Die Vollständigkeit dieser Angabe liegt im Schnitt bei 98,4%, seitdem dieses Feld im dritten Quartal 2005 ergänzt wurde Drug isr Die ISR dient hier als Fremdschlüssel zur Tabelle demo [U.S12a]. Sie ist vollständig angegeben und die Integritätsbedingungen werden erfüllt drug_seq Der Primärschlüssel zur Identifikation eines Eintrags in drug ist nach Angaben der FDA die Kombination aus isr und drug_seq, der drug sequence number [U.S12a]. Berücksichtigt man doppelte Vorkommen auf Grund komplett doppelt vorkommender Meldungen wie sie bereits in beschrieben wurden, so ist bereits die drug sequence number alleine eindeutig. Die isr ist also als Teil des Primärschlüssels nicht notwendig. Das Feld drug_seq ist vollständig role_cod Der Meldende kann bei den von einem Patienten eingenommenen Medikamenten eine Einschätzung abgeben, ob er das Medikament für primär bzw. sekundär verantwortlich hält, ob das Medikament möglicherweise in Wechselwirkung mit einem anderen eingenommenen Medikament steht oder ob es seiner Meinung nach nur begleitend eingenommen wurde, aber nicht Ursache des unerwünschten Ereignisses ist. Diese Einschätzung wird im Feld role_cod gespeichert [U.S12a]. 41

48 3. Qualität der FDA-Daten Begleitend Wechselwirkung Primär Sekundär Abbildung 3.18.: Rolle des Medikaments Abbildung 3.18 zeigt die Verteilung auf die einzelnen Einschätzungen. Alle vier Typen haben eine zunehmende Tendenz, welche sich durch die allgemeine Zunahme an Meldungen erklären lässt. Die Zunahme der interagierenden Medikamente ist hierbei allerdings erheblich geringer als die der anderen Arten. Die Zunahme der primär oder sekundär als verantwortlich eingestuften Medikamente nimmt gleichmäßig zu, während die Anzahl der nur begleitend eingenommenen Medikamente die größte Zunahme aufweist. Die Angaben zur Einstufung eines Medikaments sind vollständig. Insofern ein Medikament als sekundär verantwortlich eingestuft wurde, liegt auch eine Einstufung für ein anderes Medikament als primär verantwortlich vor. Je Meldung gibt es nur ein Medikament, das als primär verantwortlich eingeschätzt wird. Als sekundär verantwortlich eingeschätzte Medikamente liegen pro Meldung zum Teil mehrere vor drugname Welche Medikamente ein Patient während seiner Behandlung eingenommen hat, ergibt sich aus den einzelnen Einträgen in drug und jeweils dem Feld drugname. Das Feld drugname enthält Angaben zum Arzneimittel und/oder Arzneistoff [U.S12a]. Die Angabe, was eingenommen wurde, ist bis auf 59 Einträge vorhanden. Allerdings sind die Angaben teilweise von geringer Qualität. So gibt es Angaben, aus denen eindeutig das eingenommene Medikament hervorgeht, wie bspw. ASPIRIN. Teilweise ist nicht nur das eingenommene Medikament sondern auch dessen Wirkstoff(e) angegeben, wie bspw. ASPIRIN (ACETYLSALICYLIC ACID) oder YASMIN (DROSPIRENONUM, ETHINYLESTRA- DIOLUM), wobei Yasmin zwei Wirkstoffe enthält, welche hier beide angegeben sind [Dru13a]. Weiterhin gibt es Angaben wie ACETYLSALICYLIC ACID, bei denen nicht ein konkretes Medikament, sondern nur ein Wirkstoff angegeben wurde. 42

49 3.4. Analyse Neben diesen klaren Angaben kommt es vor, dass die Angaben zum Teil neben dem Medikament zusätzlich Angaben zur Dosis, zum Einnahmeweg des Medikaments, zum Hersteller und anderen Dingen enthalten oder ungenau sind. Beispielhaft soll hier erst einmal nur eine kleine Anzahl an Beispielen für diese Art von Angaben genannt werden: Drugname UNKNOWN HYPERLIPIDEMIA MEDI- CATIONS MUCINEX (GUAIFENESIN) (GUAIFE- NESIN) FLAGYL (METRONIDAZOLE) TWICE DAILY BUDEPRION XL 300 MG ONCE DAILY POTASSIUM INTRAVENOUS EXCEDRIN MIGRAINE (THOMAPHY- RIN N) (TABLETS) BAYER (ACETYLSALIC ACID) (UN- KNOWN) CARBOCISTEINE (UNKNOWN) UNSPECIFIED Tabelle 3.1.: Angaben im Feld drugname Problem es wird nur die behandelte Krankheit, aber kein Medikament oder Wirkstoff angegeben doppelte Angabe des Wirkstoffs Angabe der Einnahmehäufigkeit enthält zusätzlich zum Medikament eine Dosierungsangabe Angabe der Verabreichungsform zusätzliche Angabe der Verpackungsform Angabe des Herstellers und des Wirkstoffes, aber nicht des Medikaments Angabe etwas Unbekannten Angabe aus der gar keine Information hervorgeht Neben den ordentlichen Angaben gibt es also auch viele unsaubere Angaben. Weiterhin existieren zum Teil Rechtschreibfehler, welche eine genaue Gruppierung von Meldungen nach Medikamenten erschweren [PRPP12]. Da dieses Feld die für die Pharmakovigilanz entscheidende Angabe enthält, welches Arzneimittel bzw. welcher Arzneistoff eingenommen wurde, ist dies besonders problematisch. In Abschnitt 5.5 soll daher darauf eingegangen werden, wie die einzelnen Werte, soweit möglich, korrekt den einzelnen Arzneimitteln und -stoffen zugeordnet werden können val_vbm Ob das Feld drugname eine von der FDA überprüfte und korrekte Angabe enthält oder nicht, beinhaltet das Feld val_vbm. Diese Angabe ermöglicht zwei Werte: 1 bedeutet, dass es sich um eine überprüfte und gültige Angabe handelt, 2 bedeutet, dass die Angabe der Meldung wortwörtlich übernommen wurde [U.S12a]. Abbildung 3.19 zeigt die Verteilung auf überprüfte (blaue Linie) und wortwörtlich (rote Linie) übernommene Angaben. Die Zunahmen folgen zunächst dem allgemeinen Trend. Zum Ende ergibt sich allerdings eine leichte Entwicklung dahingehend, dass vermehrt gültige Angaben 43

50 2004q1 2004q2 2004q3 2004q4 2005q1 2005q2 2005q3 2005q4 2006q1 2006q2 2006q3 2006q4 2007q1 2007q2 2007q3 2007q4 2008q1 2008q2 2008q3 2008q4 2009q1 2009q2 2009q3 2009q4 2010q1 2010q2 2010q3 2010q4 2011q1 2011q2 2011q3 2011q4 2012q1 2012q2 2004q1 2004q2 2004q3 2004q4 2005q1 2005q2 2005q3 2005q4 2006q1 2006q2 2006q3 2006q4 2007q1 2007q2 2007q3 2007q4 2008q1 2008q2 2008q3 2008q4 2009q1 2009q2 2009q3 2009q4 2010q1 2010q2 2010q3 2010q4 2011q1 2011q2 2011q3 2011q4 2012q1 2012q2 3. Qualität der FDA-Daten % 80% 70% 60% 50% 40% 30% 20% 10% 0% Abbildung 3.19.: Validierte und wortwörtliche Drugnames in AERS aufgenommen werden. Zu erklären ist dies möglicherweise durch eine verbesserte Verarbeitung der Angaben bei der FDA. Diese Angabe ist vollständig und NULL-Werte sind nicht vorhanden route Auf welchem Wege ein Arzneimittel eingenommen wurde, enthält das Feld route [U.S12a]. Diese Angabe ist in 48,9% der Einträge vorhanden, wovon 6,4% auf unknown oder other entfallen und damit keine genaue Angabe beinhalten. Die restlichen Angaben beinhalten jeweils die genaue Art der Einnahme bzw. Verabreichung des Medikaments. Insgesamt sind in der Datenbank 65 verschiedene Formen der Aufnahme eines Medikaments vorhanden dose_vbm Die Angabe der Dosierung eines Medikaments enthält das Feld dose_vbm. Es handelt sich hierbei um ein Freitextfeld für Dosis, Einnahmehäufigkeit und Verabreichungsform und wird genau so übernommen, wie es gemeldet wird [U.S12a]. Diese Angabe ist in 34,8% der Einträge vorhanden. Da es sich um ein Freitextfeld handelt und damit kein einheitliches Format vorhanden ist, existiert ist eine Vielzahl von Varianten, in der die Dosis, Einnahmehäufigkeit und Verabreichungsform angegeben werden. Zunächst gibt es Angaben, aus denen eine genaue Dosis und Einnahmehäufigkeit hervorgeht, wie z. B. 10 MG, 2X/DAY [EZ13b] oder 1 G EVERY 48 HOURS. Aus anderen Angaben lässt sich erst im konkreten Kontext eine genaue Dosierung ableiten, wie bspw. bei 3 TABLETS / DAY oder 2-3 DOSAGE FORM. Teilweise liegen zu komplexeren Dosierungen und Einnahmehäufigkeiten sehr genaue Angaben vor, wie z. B. ADMINISTERED ON DAY 2 OVER 1 HOUR IN 2 DOSES AT HOURS ZERO AND 12 DOSE:2 GRAM(S)/SQUARE METER 4 MG -25 MG oder UNK-16OCT:20MG,17OCT- 10NOV:10MG (25D),6-19JAN10:10MG(14D),20JAN10-ONG:20MG. Manche Angaben wie UNKNOWN PRN DOSE oder FOR ABOUT 2 YEARS. sind ungenau und haben keine Aussagekraft über die tatsächliche Dosierung. Angaben, die Informationen zur Verabreichungsform beinhalten, sind u. a. 10 MG;4 TIMES A 44

51 3.4. Analyse DAY; INTRAVENOUS und 7 MG, WEEKLY, SUBCUTANEOUS. Der Anteil der Angaben, welche neben der Dosis Informationen über die Verabreichungsform beinhalten, liegt bei 5,4% 1. Auf Grund der Vielzahl von Angabevarianten ist es schwierig, die in diesem Feld angegebenen Informationen auszuwerten. Ein Ansatz hierzu wird in Abschnitt 5.4 behandelt dechal Ob die unerwünschte Wirkung des Medikaments zurückging, nachdem es abgesetzt wurde, gibt das Feld dechal an. Ja und nein geben hier den entsprechenden Verlauf der Behandlung an. Trifft nicht zu beschreibt Behandlungen, in deren Verlauf das Medikament möglicherweise trotz Nebenwirkung weiterhin eingenommen wurde, bspw. da die Nebenwirkung unkritisch und die weitere Einnahme zur Behandlung der indizierten Krankheit weiter notwendig war. Zuletzt gibt es noch unbekannt welches Unkenntnis des Meldenden über den weiteren Verlauf signalisiert [U.S12a]. Außerdem existieren hier wieder NULL-Werte, welche komplett fehlende Angaben widerspiegeln. Trotz der zunehmenden Gesamtanzahl an Einträgen in drug nimmt die Anzahl der Einträge mit den vier genannten Werten ab. Zunehmen tut lediglich die Anzahl der NULL-Werte. Insgesamt ist diese Angabe nur in 11,7% der Einträge vorhanden rechal Im vorigen Abschnitt wurde ein Feld beschrieben, in dem gespeichert wird, was passierte, als das Medikament vom Patienten nicht mehr eingenommen wurde. Ergänzend hierzu gibt es das Feld rechal. Hier wird gespeichert, ob die Nebenwirkung, nachdem der Patient das Medikament nach einer Pause erneut einnahm, wieder aufgetreten ist. Die Werte sind hier die selben wie zuvor. Vorgesehen sind ja, nein, trifft nicht zu und unbekannt [U.S12a]. Ergänzend kommt ebenfalls wieder der NULL-Wert dazu. Auch wenn die erneute Einnahme eines Medikaments zuvor das Absetzen des Medikaments bedingt, kommt es vor, dass dechal keinen Wert beinhaltet, rechal hingegen schon, wobei in rechal eine klare Aussage getroffen wird, d. h. nicht trifft nicht zu oder unbekannt ist. Die Angaben zu diesem Feld sind, ähnlich wie zuvor auch, größtenteils unvollständig. Nur in 11,1% der Einträge wurde dies angegeben. Ebenfalls rückläufig ist hier das Vorkommen der Angabe im Verhältnis zu den insgesamt vorhandenen Einträgen lot_num Zur genauen Rückverfolgung des eingenommenen Medikaments über den gesamten Herstellungsund Verkaufsprozess hinweg kann die Chargennummer des Medikaments im Feld lot_num angegeben werden [U.S12a]. Die Chargennummer ist nur in 9,5% der Einträge in drug vorhanden. 1 Alle Werte in dose_vbm, die als Bestandteil eine Angabe aus route haben. 45

52 3. Qualität der FDA-Daten exp_dt Insofern angegeben enthält das Feld exp_dt das Haltbarkeitsdatum eines Medikaments [U.S12a]. Da dieses Datum nur in 1% der Einträge vorhanden ist, sollte es nicht für Vergleiche eingesetzt werden nda_num Zur Zulassung von neuen Medikamenten nutzt die FDA Zulassungsanträge, sogenannte New Drug Applications. In diesen gibt der Hersteller eines Medikaments alle für die Zulassung notwendigen Informationen und Dokumente ab. Zur internen Identifikation erhält jeder Zulassungsantrag eine Nummer, wobei jedes Medikament mehrere Nummern haben kann, wenn mehrere Anträge für unterschiedliche Dosierungs- und Darreichungsformen eingereicht wurden [The12a]. Das Feld nda_num enthält, insofern angegeben, die Nummer des zugehörigen Antrags [U.S12a]. Die Angaben hierzu sind zu 22,5% vorhanden Indi In der Tabelle Indi werden die Indikationen angegeben, die zur Einnahme des zugehörigen, in Drug angegebenen Arzneimittels geführt haben. Die Tabelle besteht lediglich aus drei Feldern: isr, drug_seq und indi_pt (Preferred Term), wobei die Kombination aus isr und drug_seq den Fremdschlüssel zur Tabelle Drug darstellt [U.S12a] isr und drug_seq Der Fremdschlüssel, der auf die Tabelle Drug verweist [U.S12a], ist vollständig angegeben und verweist auf Einträge, welche existieren. Die Angaben sind damit konsistent indi_pt Die Angabe der Indikation erfolgt über den Preferred Term [U.S12a], eine Ebene des Medical Dictionary for Regulatory Activities (MedDRA). MedDRA ist ein Wörterbuch, welches standardisierte Begriffe für Krankheiten, Syndrome, Diagnosen, Symptome, Labor- und klinische Untersuchungen beinhaltet. MedDRA stellt dabei fünf Ebenen zur Verfügung, welche unterschiedliche Genauigkeit in der Beschreibung des jeweiligen Begriffs aufweisen. Der hier genutzte Preferred Term ist die zweitgenauste Ebene, wobei in der darunter angeordneten Ebene zum Teil lediglich Synonyme vorkommen und damit nicht zwingend ein weiterer Informationsgewinn vorliegt [PRPP12]. Insgesamt werden im Feld indi_pt verschiedene Begriffe genutzt. Diese reichen von einfachen Angaben wie PAIN oder DEPRESSION zu komplexeren Angaben wie bspw. CEREBRAL AUTOSOMAL DOMINANT ARTERIOPATHY WITH SUBCORTICAL INFARCTS AND LEUKOENCEPHALOPATHY. Am Häufigsten kommen die beiden Begriffe DRUG USE FOR UNKNOWN INDICATION und PRODUCT USED FOR UNKNOWN INDICATION vor. Hierbei handelt es sich lediglich um Platzhalter, welche nicht Teil von MedDRA sind. Einige Angaben enthalten auch Rechtschreibfehler [STKO13] und lassen sich daher nicht korrekt auswerten. 46

53 Anzahl Indikationen 3.4. Analyse Abbildung 3.20.: Häufigkeiten Preferred Terms je eingenommenes Medikament Insgesamt sind zu 45,7% der Einträge in Drug ein oder mehrere Einträge in Indi vorhanden. Wie Abbildung 3.20 zeigt, liegt zu den meisten Einträgen ein Befund vor, der zur Einnahme des zugehörigen Medikaments führte. Zu einer geringen Anzahl liegen auch mehrere Befunde vor, wobei es sich entweder bei den zugehörigen Medikamenten um Kombipräparate handelt oder aber der Befund sehr ausführlich in allen Einzelheiten beschrieben wurde Outc Wie die Behandlung für den Patienten nach Auftreten des unerwünschten Ereignisses ausging, enthält die Tabelle Outc. Diese Tabelle besteht aus zwei Feldern: der ISR als Fremdschlüssel zur Zuordnung zu einer Meldung und outc_cod welches einen Code für den jeweiligen Ausgang enthält [U.S12a] isr Die Meldungen aus der Tabelle Demo, auf die die ISR verweist [U.S12a], existieren. Die ISR ist für jeden Eintrag angegeben und gültig outc_cod Die FDA hat für den Ausgang einer Behandlung die folgenden sieben Codes festgelegt: 47

54 2004q1 2004q2 2004q3 2004q4 2005q1 2005q2 2005q3 2005q4 2006q1 2006q2 2006q3 2006q4 2007q1 2007q2 2007q3 2007q4 2008q1 2008q2 2008q3 2008q4 2009q1 2009q2 2009q3 2009q4 2010q1 2010q2 2010q3 2010q4 2011q1 2011q2 2011q3 2011q4 2012q1 2012q2 3. Qualität der FDA-Daten Tabelle 3.2.: Codes zum Ausgang einer Behandlung [U.S12a] Code Bedeutung DE Tod LT Lebensbedrohend HO Krankenhausaufenthalt - anfänglich oder verlängert DS Invalidität CA Geburtsfehler RI Eingriff notwendig, um dauerhafte Schäden zu vermeiden OT Andere Wie oft die einzelnen Behandlungsausgänge vorliegen zeigt Abbildung CA DE DS HO LT OT RI Abbildung 3.21.: Behandlungsausgänge Die einzelnen Vorkommen steigen im Wesentlichen mit dem Trend der zunehmenden Anzahl an Meldungen. Prozentuale Verschiebungen liegen nicht vor. Abbildung 3.22 zeigt die Anzahl der je Meldung vorliegenden Behandlungsausgänge. Zu den meisten Meldungen liegt ein Ausgang vor. Die Anzahl der Meldungen, welche eine zunehmende Anzahl an Behandlungsausgängen enthalten, nimmt stetig ab. Der Anteil der Meldungen ohne Angabe eines Behandlungsausganges liegt bei 25,5%, wobei es sich bei 84,4% dieser Meldungen um Anfangsmeldungen handelt, zu denen möglicherweise eine Folgemeldung vorliegt, die dann den entsprechenden Ausgang der Behandlung beinhaltet. Nicht von der FDA vorgesehene Codes wurden nicht angegeben. 48

55 Anzahl Behandlungsausgänge 3.4. Analyse Abbildung 3.22.: Häufigkeiten Behandlungsausgänge je Meldung Reac Die Tabelle Reac enthält die aufgetretenen unerwünschten Ereignisse. Sie ist ähnlich aufgebaut wie die zuvor beschriebenen Tabellen Indi und Outc. Zunächst enthält sie die ISR zur Zuordnung zu einer Meldung und weiterhin einen Preferred Term (Feld pt ) aus MedDRA [U.S12a] isr Die ISR als Fremdschlüssel zur Tabelle Demo [U.S12a] ist bei allen Einträgen in Reac angegeben und gültig pt Wie bereits in beschrieben ist MedDRA ein Wörterbuch für medizinische Begriffe. Das unerwünschte Ereignis wird anhand des Preferred Term aus MedDRA klassifiziert [U.S12a]. Zu lediglich 10 Meldungen liegt keine Angabe zu einem unerwünschten Ereignis vor, wobei zu 6 dieser 10 Meldungen eine Meldung im gleichen Fall vorliegt, welche das Ereignis spezifiziert. Die meisten Meldungen haben lediglich eine oder eine sehr geringe Anzahl an unerwünschten Ereignissen. Es existieren aber auch einige Meldungen, zu welchen über 100 Ereignisse angegeben wurden. Wie auch zuvor bei Indi treten hier in den Preferred Terms Rechtschreibfehler auf [STKO13]. 49

56 2004q1 2004q2 2004q3 2004q4 2005q1 2005q2 2005q3 2005q4 2006q1 2006q2 2006q3 2006q4 2007q1 2007q2 2007q3 2007q4 2008q1 2008q2 2008q3 2008q4 2009q1 2009q2 2009q3 2009q4 2010q1 2010q2 2010q3 2010q4 2011q1 2011q2 2011q3 2011q4 2012q1 2012q2 3. Qualität der FDA-Daten Rpsr Die Tabelle Rpsr enthält Informationen über die Quelle einer Meldung. Sie hat den gleichen Aufbau wie Outc [U.S12a] isr Die ISR dient erneut als Fremdschlüssel zur Tabelle Demo [U.S12a]. Zu allen Einträgen ist die ISR vorhanden und existiert in der Tabelle Demo rpsr_cod Für das Feld rpsr_cod hat die FDA die in Tabelle 3.3 angegebenen Codes vorgesehen. Die einzelnen Codes schließen sich dabei nicht gegenseitig aus. Entsprechend zeigt Abbildung 3.23 die Häufigkeiten der einzelnen Quellen, wobei die Summe über der Anzahl Meldungen liegt, welche eine Quelle angegeben haben CR CSM DT FGN HP LIT OTH SDY UF 0 Abbildung 3.23.: Quellen von Meldungen Abbildung 3.24 zeigt, wie oft Meldungen vorliegen, zu denen eine entsprechende Anzahl Quellen angegeben wurde. Zu erkennen ist, dass zum Großteil der Meldungen keine Quellenangabe vorhanden ist. Der Anteil Meldungen, zu denen eine oder mehrere Quellenangaben vorliegen, liegt bei nur 23,3%. Nicht vorgesehene Codes existieren nicht. 50

57 Anzahl Quellen 3.4. Analyse Tabelle 3.3.: Codes zur Quelle einer Meldung [U.S12a] Code Bedeutung FGN Fremder SDY Studie LIT Literatur CSM Konsument HP Gesundheitsfachkraft UF Anwender CR Unternehmensvertreter DT Händler OTH Andere Abbildung 3.24.: Häufigkeiten Quellen je Meldung Ther Diese Tabelle enthält Informationen über Start- und Enddatum bzw. die Dauer der Einnahme eines Medikaments durch einen Patienten [U.S12a] isr und drug_seq Der Fremdschlüssel, welcher auf die Tabelle Drug verweist, besteht aus den Feldern isr und drug_seq [U.S12a]. Zu allen Einträgen in Ther ist dieser Fremdschlüssel vollständig angegeben und die zugehörigen Einträge in Drug existieren. 51

58 3. Qualität der FDA-Daten start_dt und end_dt Die Felder start_dt und end_dt geben den Zeitraum an, in dem der Patient das zugehörige Medikament eingenommen hat. Zu einem in Drug angegebenen Medikament können mehrere Einträge in Ther existieren, insofern ein Arzneimittel wiederholt eingenommen wurde [U.S12a] Abbildung 3.25.: Startdatum der Medikamenteneinnahme Wie in Abbildung 3.25 und 3.26 zu erkennen, häufen sich die Datumsangaben jeweils zum Ersten eines Monats und erheblich zum Ersten eines Jahres. Ähnlich wie im Feld event_dt in der Tabelle Demo liegt dies an nur monats- bzw. jahresgenauen Angaben. Sowohl Start- als auch Enddatum sind in 46,6% der Einträge vorhanden. Weitere 46% weisen nur das Startdatum auf. Nur das Enddatum ist in 5,2% der Einträge angegeben, die restlichen Einträge weisen weder Start- noch Enddatum auf, wobei im Großteil der Fälle hier die Dauer angegeben ist. Insgesamt relativiert sich dies allerdings auf Grund der großen Anzahl an Einträgen in Drug, zu denen keine Angabe in Ther vorliegt dur und dur_cod Wie bereits bei den Alters- und Gewichtsangaben zu einem Patienten teilt sich die Angabe der Dauer einer Medikamenteneinnahme in einen numerischen Wert und eine dazugehörige Einheit auf [U.S12a]. Zu einem Großteil der Einträge, bei denen Start- und Enddatum eingetragen wurden, existiert die Angabe der Dauer nicht. Zum Teil liegt dies an ungenauen Datumsangaben, zu denen keine genaue Einnahmedauer angegeben werden konnte. Ein Teil der Angaben zur Dauer liegt unvollständig vor. Entweder wurde nur in dur der numerische Wert eingetragen, aber nicht die zugehörige Einheit in dur_cod, oder in dur_cod 52

59 3.4. Analyse wurde eine Einheit eingetragen, aber kein dazugehöriger Wert in dur. Die Anzahl dieser unvollständigen Einträge geht allerdings zurück (vergleiche Tabelle A.20). Wie oben bereits angedeutet, existieren nicht zu allen Einträgen in Drug auch Einträge in Ther. Zu 60,8% der Einträge in Drug existiert kein Eintrag in Ther. Zu 38,5% existiert ein Eintrag in Ther. Zwei Einträge in Ther können 0,5% der Einträge in Drug aufweisen. In Einzelfällen existieren bis zu 77 Einträge Abbildung 3.26.: Enddatum der Medikamenteneinnahme Zusammenfassung Die wesentlichen Probleme in den von der FDA zur Verfügung gestellten Daten bestehen in mal mehr und mal weniger unvollständigen Daten und in den Freitextfeldern. Inwieweit die Felder der einzelnen Tabellen unvollständig sind wurde im jeweiligen Abschnitt betrachtet. In diesem Zusammenhang ist die Bedeutung des NULL-Wertes nicht immer erkennbar, da meist eine spezielle Angabe wie unbekannt oder nicht spezifiziert existiert. Freitextfelder, wie drugname, dose_vbm oder mfr_sndr haben kein einheitliches Format da keine Konvention zur Angabe des jeweiligen Datums vorhanden ist bzw. im Falle des Feldes dose_vbm dieses Feld für mehrere Angaben verwendet werden kann. Datumsangaben sind zum Teil ungenau. Die Felder event_dt der Tabelle Demo und die Felder start_dt und end_dt wurden teilweise um Tages- und Monatsangaben ergänzt, um Angaben, die nur monats- oder jahresgenau waren, abspeichern zu können. Zuletzt zu nennen sind Duplikate, welche zum einen durch das Nachreichen von Korrekturen zu einzelnen Meldungen entstehen, zum anderen durch Meldungen die an unterschiedliche Stellen gleichzeitig getätigt und von dort an die FDA weitergeleitet werden. 53

60 3. Qualität der FDA-Daten Im Folgenden soll nun zunächst das Programm OpenVigil vorgestellt werden, bevor im darauf folgenden Kapitel beschrieben wird, wie einige der aufgezeigten Qualitätsmängel behoben werden können. 54

61 4. OpenVigil OpenVigil ist ein Programm zur Analyse der von der FDA im Rahmen ihres Spontanmeldesystems AERS zur Verfügung gestellten Daten. Version 1 wurde von Böhm et. al. [BHCH12] entwickelt und über die Server der Christian-Albrechts-Universität zu Kiel zur freien Benutzung zur Verfügung gestellt. Zusätzlich wurde der Quellcode unter der GNU General Public License (GPL) freigegeben [BHCH12]. Innerhalb von OpenVigil 1 wurde die Datenstruktur der von der FDA veröffentlichten Daten verwendet. Anpassungen oder ähnliches wurden nicht vorgenommen. Hauptproblem in OpenVigil 1 war die Laufzeit, welche bei komplexeren Anfragen mehrere Stunden betrug. Dies lag zum Teil auch daran, dass keine Optimierungen der Daten vorgenommen wurden, sondern direkt in den Rohdaten gesucht wurde. Weiterhin fehlten in Version 1 Möglichkeiten zur weitergehenden Analyse ausgehend von einem unerwünschten Ereignis, da OpenVigil 1 nur Auswertungen ausgehend von Arzneimitteln- bzw. -stoffen ermöglichte. Weiterhin wurde nicht zwischen Arzneimitteln und Arzneistoffen unterschieden und durch die unterschiedlichen Angaben, wie bereits in gezeigt, wurden nicht immer alle zutreffenden Meldungen in die Auswertungen mit einbezogen, da die Analyse eines Wirkstoffes nicht die Medikamente mit einbezog, die diesen enthalten [EZ13b]. Um diesen Problemen Herr zu werden, wurde eine Neuentwicklung notwendig. Hierbei wurde auf eine Trennung zwischen Medikamenten und Wirkstoffen gesetzt, welche es ermöglicht, sowohl explizit nach einem Medikament zu suchen, als auch nach einem Wirkstoff, wobei hier auch berücksichtigt wird, wenn in den Daten der FDA nur der Name des Medikaments genannt wird, aber bekannt ist, dass das Medikament den entsprechenden Wirkstoff beinhaltet. Um dies zu ermöglichen, ist eine Verarbeitung des Feldes drugname aus der Tabelle Drug notwendig, welche Inhalt von Abschnitt 5.5 ist. Weiterhin ist in der neuen Version die Suche nach ATC-Codes oder chemischen Teilstrukturen möglich. Abbildung 4.1 zeigt die neu entwickelte Oberfläche. Neben der dargestellten Analysemöglichkeit kann der Benutzer sich die Daten einer Meldung anzeigen lassen, eigene lesende SQL-Abfragen ausführen, eine Liste der bekannten unerwünschten Ereignisse und das Verzeichnis zu bekannten Arzneimitteln und -stoffen, inklusive Detailinformationen, anzeigen lassen. Durch die Vorverarbeitung konnten Freitextsuchen bei der Auswertung vermieden und Indizes dadurch effizient eingesetzt werden [EZ13b] Technische Produktumgebung OpenVigil 2.0 wird als Webanwendung entwickelt und stellt daher keine speziellen Anforderungen an den Client. Lediglich ein Webbrowser mit Anbindung zum Server ist notwendig. Auf Serverseite ist neben den konkreten Programmen wie Web-Applikations-Server und Da- 55

62 4. OpenVigil Abbildung 4.1.: OpenVigil 2.0 tenbankmanagementsystem vor allem zu erwähnen, dass genug Speicherplatz notwendig ist, um alle Daten speichern zu können, und genug Rechenleistung zur Bearbeitung der Anfragen benötigt wird. Im Folgenden eine kurze Auflistung der technischen Produktumgebung [EZ13a]: Software Client Betriebssystem: beliebig aktueller Internet-Browser (Referenzbrowser: Mozilla Firefox 17) Laufzeitumgebung: Web-Applikations-Server Betriebssystem: Beliebig JRE 7 Tomcat 7 56

63 4.2. Entwicklungsumgebung Datenbank PostgreSQL 9.2 Hardware Client Internetfähiger Rechner Server Internetfähiger Rechner Ausreichend Festplattenspeicher für Software und Datenbank Rechnerleistung zur Bearbeitung der Anfragen Organisation von Datensicherungen Orgware Internetanbindung Produkt-Schnittstellen Datenimport der Daten von FDA, Drugbank und 4.2. Entwicklungsumgebung Entwickelt wurde OpenVigil 2.0 mit Eclipse, welches für die Entwicklung von Java-Anwendungen eine sehr gute Umgebung bietet. Für die Verwaltung und den Austausch des Quellcodes wurde die Versionsverwaltung SVN genutzt. Die folgende Auflistung enthält alle zur Entwicklung genutzten Programme [EZ13a]: Software beliebiges Betriebssystem Eclipse 4.2 SVN Mantis Bug Tracker Tomcat 7 57

64 4. OpenVigil Tomcat Plug-In für Eclipse PostgreSQL 9.2 JDK / JavaEE Hardware PC Orgware Keine Entwicklungs-Schnittstellen Keine 4.3. Datenbank Entsprechend der neuen Anforderungen wurde eine neue Datenbankstruktur entwickelt, die sowohl die Daten der FDA, als auch ein Verzeichnis zu Arzneimitteln und -stoffen aufnimmt. Die Abbildungen 4.2 und 4.3 zeigen die neu entwickelte Struktur einmal in Form eines Entity- Relationship-Diagramms und einmal in Form eines relationalen Datenbankschemas wie es später innerhalb der Datenbank umgesetzt wurde. Zu erkennen sind in der unteren Hälfte die Daten aus AERS, welche sich primär um den Report als Abbildung einer Meldung anordnen, und im oberen Bereich das Verzeichnis zu Medikamenten und Wirkstoffen. Dieses Verzeichnis enthält neben den einzelnen Namen der Arzneimittel und -stoffe auch deren Zuordnung zueinander, d. h. die Information, welche Wirkstoffe in einem Medikament enthalten sind, und weiterhin Informationen zu Arzneistoffen, wie Synonyme, zugeordnete ATC-Codes oder chemische Teilstrukturen. Die Synonyme werden dabei bei der Zuordnung einzelner Einträge in Drug zu den zugehörigen Wirkstoffen verwendet. ATC-Codes und chemische Teilstrukturen hingegeben können zur Analyse der Daten durch den Benutzer verwendet werden [EZ13b] Benutzergruppen Innerhalb von OpenVigil 2.0 gibt es zwei Benutzergruppen. Zum einen die Benutzergruppe openvigil_sql, die den Zugriff auf die generische SQL-Schnittstelle erlaubt, und zum anderen die Gruppe openvigil_admin für Administratoren. Administratoren allein sind für den Import neuer Daten und die Verwaltung bestehender Daten zuständig. 58

65 4.4. Benutzergruppen SUBSTRUCTURES PK Name SYNONYMS PK Name PHARMAPRODUCT PK BrandName Form Salt Enantiomer_dl Type Biologic Enantiomer_rs Enantiomer-plusminus ATC-CODE PK Code THERAPY PK T_id Start_dt End_dt Durability Code dur_years dur_days dur_seconds INDICATION PK indi_pt Anatomgrp OUTCOME PK OUTC_COD Meaning DRUG PK Drugname Lastupdate Drugbank_ID DDD PP_APPL PRODUCT IDENTIFIER CLASSIFICATION COMPONENT PRODUCER PK name MANUFACTURE USED DRUGUSAGE PK Drug-Seq ROLE_CODE VAL_VBM ROUTE DOSE_VBM DECHAL RECHAL LOT_NUM EXP_DT NDA_NUM Daily_Dosis Drugname_Orig RESULT CASE PK CASE_ID EVENT PK PT Sysorgclass RPSR PK RPSR_COD Meaning INCLUDES REPORT PK ISR FOLL_SEQ Event_DT MFR_DT FDA_DT REPT_CODE MFR_NUM MFR_SNDR GNDr_Code E_SUB OCCP_COD DEATH_DT TO_MFR CONFID REPORTER_COUNTRY Age Age_Code Age_Years Age_Days Age_Hours I_F_CODE Image WT WT_Code REPT_DT (0,*) (0,1) (0,1) (0,*) (0,*) (1,1) (0,*) (1,1) (1,*) (0,*) (0,*) (0,*) (0,*) D_APPL (0,*) (0,*) (1,*) (1,*) (0,1) (0,*) (0,*) UNCLASSIFIED INCOMPLETE PK name (0,*) (1,*) REP_RPSR (0,*) (0,*) REP_OUTCOME (0,*) (0,*) REP_EVENT (0,*) (0,*) xor CODES PK name PK code meaning Abbildung 4.2.: ER-Schema zu OpenVigil 2 [EZ13b] 59

66 4. OpenVigil Abbildung 4.3.: Relationales Datenbankschema von OpenVigil 2 60

67 4.5. Architektur Zum Schutz vor ungewollten Zugriffen von außen wurde in der Entwicklungsphase das gesamte Programm zusätzlich durch einen Gastaccount geschützt. Die Definition der Benutzergruppen erfolgt über die Datei web.xml, welche Teil der Anwendung ist. Die Verwaltung der Benutzeraccounts und die Authentifizierung erfolgt über die vom Tomcat bereitgestellten Funktionen. Verwendet wird hier der BASIC-Login mit der in den Tomcat integrierten Benutzerverwaltung Architektur Im Folgenden soll nun die interne Architektur der Anwendung beschrieben werden. Wie bereits beschrieben ist OpenVigil 2.0 eine javabasierte Webanwendung. Einstiegspunkt für alle Anfragen des Benutzers ist jeweils die für die gewünschte Aktion zuständige jsp-datei. Diese leitet zunächst die Anfrage an die zuständige Controller-Klasse weiter, die die eigentliche Verarbeitung der Anfrage vornimmt und das Ergebnis bereitstellt. Insofern durch den Controller nicht eine Weiterleitung an eine andere Adresse stattfindet wird anschließend innerhalb der jsp-datei die Ausgabe generiert. Abbildung 4.4.: Paketdiagramm zu OpenVigil 2 Abbildung 4.4 zeigt die einzelnen Pakete die innerhalb von OpenVigil 2.0 existieren. Innerhalb des Hauptpakets befinden sich die Controller-Klassen, die für die Funktionen zuständig sind, die für normale Benutzer zur Verfügung stehen. Dies sind alle Funktionen von OpenVigil, die sich auf die Auswertung der Daten oder die Auflistung einzelner Daten beziehen. Die models-pakete enthalten jeweils zu den in der Hierarchie über ihnen stehenden Paketen die entsprechenden Model-Klassen zur Abbildung der Datenbank. Das Paket interfaces enthält abstrakte Klassen, die damit sowohl zu implementierende Methoden vorgeben und gleichzeitig bereits Funktionalität bereitstellen. Reine Interfaces finden in OpenVigil 2.0 keine Anwendung. Neben zwei abstrakten Models, eine allgemeine Form 61