Integrated Data Repository Toolkit (IDRT)

Transkript

1 Integrated Data Repository Toolkit (IDRT) TMF-Projekt V091-MI_03 Deliverable D1.1: Aktualisierung und Formalisierung der bestehenden Anforderungsanalyse Report Matthias Löbe Sebastian Stäubert Prof. Dr. Alfred Winter

2 1. Autoren Autor 1: Matthias Löbe Institut für Medizinische Informatik, Statistik und Epidemiologie (IMISE) Universität Leipzig Härtelstraße Leipzig Tel.: Fax: sowie Center for Sepsis Control and Care (CSCC) Universitätsklinikum Jena Autor 2: Sebastian Stäubert Institut für Medizinische Informatik, Statistik und Epidemiologie (IMISE) Universität Leipzig Härtelstraße Leipzig Tel.: Fax: sowie IFB AdipositasErkrankungen Universitätsklinikum Leipzig Autor 3: Prof. Dr. Alfred Winter Institut für Medizinische Informatik, Statistik und Epidemiologie (IMISE) Universität Leipzig Härtelstraße Leipzig Tel.: Fax: Deliverable D1.1: Anforderungsanalyse, Integrated Data Repository Toolkit (IDRT), März / 44

3 2. Inhaltsverzeichnis 1. Autoren Inhaltsverzeichnis Zusammenfassung Einleitung Methode Ergebnisse der Evaluation in Referenzprojekten Literaturanalyse Interviews bei potenziellen Anwendern Anforderungen aus der Community Ergebnisse Erläuterungen der Ergebnistabelle Liste der Anforderungen Diskussion Ausblick Literatur Ressourcen zum Projekt Referenzen im vorliegenden Dokument Liste der betrachteten wissenschaftlichen Arbeiten Abbildungen & Tabellen Glossar/Abkürzungsverzeichnis Anhänge Deliverable D1.1: Anforderungsanalyse, Integrated Data Repository Toolkit (IDRT), März / 44

4 3. Zusammenfassung Das hier vorliegende Deliverable fasst die Ergebnisse des Arbeitspakets 1.1 "Aktualisierung und Formalisierung der bestehenden Anforderungsanalyse" mit der Laufzeit von Februar - März 2012 zusammen. Gegenstand dieses Arbeitspakets war es, die im TMF-Workshop "Anwendungsszenarien und Plattformen für Datenintegration und -abfrage" vom identifizierten Anwendungsszenarien für i2b2 (Klinisches Data Warehouse eines Standorts, Forschungsdatenbank eines oder auch mehrerer Forschungsverbünde sowie Klinische Annotationsdatenbank für Forschergruppen mit Biobanken) zu analysieren, zu vervollständigen und zu präzisieren. In einem ersten Schritt wurden Anwender aus Referenzinstallationen befragt, die über tiefgehende Kenntnisse im Aufbau und Betrieb der Plattform verfügen. Parallel dazu wurde die zu i2b2 verfügbare wissenschaftliche Literatur gesammelt und im Hinblick auf Einsatzgebiete und -erfahrungen ausgewertet. Weiterhin wurden Interviews mit potenziellen Nutzern an Institutionen durchgeführt, die aus ihrem Arbeitskontext heraus ähnliche Anforderungen haben. Zuletzt wurden die Anforderungen der Community eruiert, indem Besucher der Treffen der i2b2 User Group nach ihren Erwartungen und Einsatzszenarien befragt wurden. Im Ergebnis konnten sehr viele und oft heterogene Anforderungen identifiziert werden. Dabei ist wenig überraschend zu beobachten, dass die Anforderungen umso klarer formuliert wurden, je mehr Vorkenntnisse die Befragten hatten. Daher musste, auch mit Rücksicht auf die beschränkten Ressourcen des Projekts, eine Priorisierung vorgenommen werden in Anforderungen, die gleichzeitig bedeutend und dringlich sind und damit im aktuellen Projekt bearbeitet werden, solchen, die von einer Mehrheit der Befragten als wichtig angesehen wird, aus Ressourcengründen aber aktuell bearbeitet werden können und Anforderungen, die noch prägnanter und detaillierter gefasst werden müssen bzw. die spezielle Probleme einer einzelnen Forschungsinstitution widerspiegeln. Das Haupteinsatzgebiet von i2b2 ist jedoch in praktisch allen untersuchten Szenarien gleich: Die Exploration medizinischer Daten mit Hilfe einer trainingsarmen grafischen Benutzerschnittstelle, die es klinischen Forschern ohne Kenntnisse in Datenbanktechnologien ermöglicht, Abfragen über spezifische Merkmale von Patientenkollektiven zu stellen und abhängig von der Ergebnismenge zu verfeinern oder zu reformulieren. Mit den in diesem Arbeitspaket gewonnenen Erkenntnissen ist eine zielgerichtete Umsetzung der weiteren geplanten Arbeitspakete möglich. Deliverable D1.1: Anforderungsanalyse, Integrated Data Repository Toolkit (IDRT), März / 44

5 4. Einleitung Anforderungsanalyse wird als Begriff in der Literatur uneinheitlich verwendet, umfasst jedoch mindestens die Analyse der Bedürfnisse, Kriterien und Bedingungen, die von den verschiedenen beteiligten Parteien an neue oder verbesserte Produkte, Prozesse oder Systeme gestellt werden. Während die Anforderungsanalyse als Teil des Requirements Engineerings üblicherweise vor der Produktauswahl oder Implementierungsentscheidung steht, ist im vorliegenden Fall von dieser Reihenfolge abgewichen worden. Der Grund hierfür liegt in den Ergebnissen des TMF-Projekts "IT-Strategie" (V054-01), Teilprojekt 2a Analyse in den USA im Rahmen von vernetzten Forschungsprojekten entwickelter und als Open Source verfügbarer IT-Komponenten auf ihre Verwendbarkeit in der deutschen Forschungslandschaft [1], welches bereits in einer konkreten Produktempfehlung resultierte. Eine Kernaufgabe dieses Projekts war die Etablierung und Evaluation einer lizenzfreien und von Wissenschaftlern ohne zentrale Unterstützung nutzbaren Auswertungsplattform auf Basis von i2b2 ( Integrating Biology and Bedside ) 1. Die Evaluierung der i2b2-werkzeuge hinsichtlich ihrer Verwendbarkeit in der deutschen Forschungslandschaft wurde in vollem Umfang als sehr positiv und erfolgreich bezeichnet. Während die prinzipielle Eignung von i2b2 als Data Mart für klinische Forschungsdatenbanken damit feststand, war offen, ob damit auch alle oder zumindest eine hinreichend große Zahl von Anforderungen einer weiter gefassten Community als jene des Evaluierungsinstallationsteams abgedeckt würden und ob überlegene Alternativen zu der verwendeten Werkzeugsuite i2b2 existierten. Daher wurden mit Zustimmung des TMF- Vorstands zwei weitergehende Maßnahmen beschlossen, 1. die Gründung einer Deutschen i2b2 User Group und 2. die Ausrichtung eines thematisch weiter gefassten Workshops Anwendungsszenarien und Plattformen für Datenintegration und -abfrage, zu dem explizit eingeladen wurden, die praktische Erfahrungen mit alternativen Werkzeugen z.b. aus dem cabig-projekt gesammelt hatten. Der Workshop fand am am Universitätsklinikum Erlangen statt. Besondere Schwerpunkte waren die Analyse von Anwendungsszenarien und die Erhebung der technischen Anforderungen aus den teilnehmenden Verbünden. Die Ergebnisse bilden zusammen mit den Schlussfolgerungen aus dem TMF-Projekt "IT-Strategie" die Basis für die hier vorliegende Aktualisierung. Des Weiteren wurden alternative Softwaresysteme untersucht, welche die bekannten Anforderungen möglicherweise ebenso gut oder besser 1 Deliverable D1.1: Anforderungsanalyse, Integrated Data Repository Toolkit (IDRT), März / 44

6 bedienen könnten. Dazu wurde eine systematische Übersicht der verfügbaren Werkzeuge aus dem cabig-programm 2 sowie aus dem CTSA-Programm (Clinical and Translational Science Awards) 3 erstellt, welchen einen Bezug zum Workshop-Thema aufwiesen und eine kurze Einschätzung ihrer Leistungsfähigkeit getätigt [2]. Daraus, wie auch aus den Anwenderberichten, ergaben sich keine Hinweise auf eine notwendige Änderung der Fokussierung auf i2b2. Aufgabe dieses Arbeitspakets ist die Aktualisierung und Formalisierung der aus dem Workshop Datenintegration sowie den Treffen der i2b2-anwendergruppe entstandenen informellen Anforderungsanalyse. Damit umfasst dieses Arbeitspaket auch die Anforderungserhebung als vorgeschalteten Teilprozess. Zielgruppen des Arbeitspakets sind alle medizinischen Forschungsverbünde, die im Rahmen ihrer Vorhaben Datenbestände für Auswertungszwecke aufgebaut haben bzw. diese zurzeit erarbeiten, sowie Einrichtungen der medizinischen Versorgung, die mit Hilfe von Daten der Routineversorgung Forschungsprojekte durchführen wollen (z.b. Universitätsklinika). Mehrwerte ergeben sich zukünftig durch die teilautomatisierte und datenschutzkonforme Aufbereitung bereits vorhandener Datenbestände für forschungsbezogene Abfragen. Typische Anwendungsszenarien, für die eine Zusammenführung bisher isolierter Datenbestände von Bedeutung ist, sind beispielsweise: Multizentrische, dezentrale Forschungsnetze (z.b. Kompetenznetze in der Medizin oder Netzwerke seltener Erkrankungen): Integration verschiedener Studiendatenbanken; Metaanalysen; Langzeitverfügbarkeit nach Auslaufen der Förderung Klinische Studienzentren / Site Management Organisationen: Unterstützung der Patientenrekrutierung, Abschätzung von Feasibility-Anfragen aus der Pharmaforschung; Durchführung von Follow-Up-Studien Register und Kohorten: Verknüpfung mit externen Partnern, die erweiterte, z.b. soziodemografische, lebensstil-assoziierte, genomische oder umweltbezogene Daten erfassen; Observationsstudien Klinische Forschergruppen: Zusammenführung der verteilten lokalen Datenbestände aus der patientennahen Forschung bzw. der jeweiligen Routineversorgung an den Studienpatienten Integrierte Forschungs- und Behandlungszentren: Verwendung von Daten und Diensten der Patientenversorgung für die Forschung (Secondary Use); Patientenmarkierung Deliverable D1.1: Anforderungsanalyse, Integrated Data Repository Toolkit (IDRT), März / 44

7 5. Methode Für die vorliegende Anforderungsanalyse wurden verschiedene Methoden zur Gewinnung von Anforderungen kombiniert, um sowohl Fachexperten mit i2b2-erfahrungen als auch Fachexperten in ähnlichen Problemgebieten, aber ohne Erfahrungen mit i2b2 zu involvieren: 1. Ergebnisse der Evaluation in Referenzprojekten 2. Literaturanalyse 3. Interviews bei potenziellen Anwendern 4. Anforderungen aus der Community Den Autoren ist bekannt, dass vielfältige formale Modelle für das Requirements Engineering besonders im Hinblick auf die Entwicklung von Softwaresystemen existieren und dass sich mit der Fachgruppe Requirements Engineering der Gesellschaft für Informatik 4 eine dedizierte deutschsprachige gruppe mit wissenschaftlichen Methoden zur Ermittlung, Beschreibung, Prüfung und das Management von Anforderungen beschäftigt. Aufgrund der speziellen Voraussetzungen der Evaluierung nur eines einzigen Softwaresystems, welches nur mit mittlerem Aufwand anpassbar bzw. erweiterbar ist wurde in diesem Arbeitspaket kein formales Modell verwendet Ergebnisse der Evaluation in Referenzprojekten Zum Zeitpunkt des Workshops im Oktober 2010 existierten, soweit bekannt, in sechs deutschen Universitätskliniken i2b2-installationen (Erlangen, Göttingen, Ulm, Hannover, Gießen und Leipzig). Dabei handelte es sich aber nur bei den ersten beiden Fällen um produktive Systeme. Die anderen Teilnehmer hatten zwar teils komplexe Datenbestände aufgebaut und verschiedene interessante Erweiterungen implementiert, die aber aus Sicht des Routinebetriebs (keine aktuellen Daten, keine externen Nutzer) nur prototypischen Charakter hatten. Aus Gesprächen mit den verantwortlichen Personen ergab sich eine Übersicht der realisierten und intendierten Einsatzszenarien: 1. Controlling: Unterstützung der administrativen Leitung des Krankenhauses oder einer Abteilung durch Berechnung von Kennzahlen, z.b. der Liegedauer nach einer Diagnose oder der Zahl von Komplikationen bei bestimmten Prozeduren. 4 Deliverable D1.1: Anforderungsanalyse, Integrated Data Repository Toolkit (IDRT), März / 44

8 2. Kohortenschätzung: Unterstützung bei der Kalkulation von Fallzahlen für neue Forschungsfragestellungen auf Basis retrospektiver Analysen unter der Annahme einer ähnlichen Patientenverteilung im Verlauf der Jahre. 3. Patientenrekrutierung: Unterstützung bei der Auswahl von Patientenkollektiven für klinische oder epidemiologische Studien durch Recherche geeigneter Kandidaten, die sich gerade noch im Behandlungskontext befinden. 4. Meta-Analysen bzw. Case Control Studies: Unterstützung bei der Verifikation von Studienergebnissen oder Finden von Patienten ähnlicher Exposition gegenüber potentiellen Risikofaktoren mit und ohne erfolgte Erkrankung 5. Aggregation klinischer und genomischer Daten: Unterstützung bei Observationsstudien genetischer Varianten 5.2. Literaturanalyse Eine weitere wichtige Quelle für Anforderungen an klinische Data Warehouses im Allgemeinen und i2b2 im Speziellen stellt die publizierte wissenschaftliche Literatur dar. Es wurden neben einer Webrecherche in den einschlägigen Datenbanken wie Pubmed 5, DBLP 6 und Google Scholar 7 auch projektspezifische Seiten wie die i2b2-homepage 8 und soziale Netze wie CiteULike 9 und BibSonomy 10 nach Publikationen durchsucht. Eine Liste der relevanten Paper und Abstracts findet sich in Abschnitt 9.3, sowie in fortwährend aktualisierter Form im Internet als CiteULike Special Interest Group "i2b2" Interviews bei potenziellen Anwendern Eine detaillierte Anforderungsanalyse in Forschungsverbünden auch außerhalb des Befürworterkreises von i2b2 fand bisher oder nur sehr eingeschränkt statt. Im Rahmen des Arbeitspakets 1 wurden daher exemplarisch Forschungsverbünde, die von Werkzeugen zur Datenintegration und -abfrage profitieren, i2b2 aber einsetzen, interviewt. Dabei wurde versucht, möglichst viele Typen von Forschungsnetzwerkstrukturen abzudecken. Das Arbeitspaket profitierte hierbei von der Konzentration solcher Verbünde am Standort Leipzig: Kompetenznetze in der Medizin: Kompetenznetz Maligne Lymphome (KML), Kompetenznetz Herzinsuffizienz (KNHI), Kompetenznetz Sepsis (SepNet) Deliverable D1.1: Anforderungsanalyse, Integrated Data Repository Toolkit (IDRT), März / 44

9 Integrierte Forschungs- und Behandlungszentren (IFB): IFB Adipositas Erkrankungen (Leipzig), IFB Sepsis und Sepsisfolgen (Jena) Zentrum für Klinische Studien: ZKS-Leipzig (bestehend aus Koordinierungszentrum für Klinische Studien KKS und Site Management Organisation SMO) Epidemiologisches Forschungsprojekt mit Langzeitkohorten: Leipziger Forschungszentrum für Zivilisationskrankheiten (LIFE) In den Gesprächen wurde deutlich, dass der Begriff Data Warehouse sehr weit gefasst ist und noch weiter verstanden wird. Eine weitere Erkenntnis ist, dass i2b2 bei ehrlicher Betrachtung die divergierenden Erwartungen erfüllen kann und in absehbarer Zeit auch erfüllen wird. Dies ist jedoch alleinig mit Limitationen der i2b2-sofware oder des gewählten Ansatzes zu begründen. Es ist vielmehr dadurch bedingt, dass eine universelle Plattform für Datenintegration und -abfrage eine Flut von Funktionen bieten müsste. Diese kann jedoch realistischerweise in einem monolithischen System, sondern nur von verschiedenen modularen, speziell konfigurierten Komponenten bereitgestellt werden. Der Funktionsumfang beinhaltet beispielsweise ein (ambulanzspezifisches) Reporting, Datenqualitätsanalysen nach lokal definierten Parametern, Bereitstellung von annotierten Datensätzen in bestimmten Dateiformaten für statistische Auswerteprogramme oder Unterstützung des lokalen Berechtigungskonzepts. Daraus folgt, dass bei einer Vorstellung von i2b2 vor interessierten potenziellen Nutzern neben der Betonung der vorhandenen Funktionen auch eine faire Abgrenzung zu ergänzenden Systemen stehen sollte. Soweit sich die im Gespräch benannten Anforderungen im engeren Sinn auf i2b2 Data Warehousing bezogen, wurden sie jedoch erfasst und sind in die Analyse eingeflossen Anforderungen aus der Community Forschungsprojekte im Rahmen des TMF e.v. erheben schon aus der Vereinssatzung heraus den Anspruch, universell einsetzbare Instrumente und Methoden entwickeln zu wollen. Der Aufbau einer Community aus interessierten Wissenschaftlern war daher eine logische Konsequenz, um einerseits breit über die erreichten Ergebnisse zu informieren und andererseits externe Forscher zu Kommentaren und Beiträgen anzuregen Workshops der i2b2 User Group Im Vorfeld des aktuellen Projekts entschied der Vorstand der TMF, die Dissemination der Empfehlungen der Projektgruppe IT-Strategie im Hinblick auf i2b2 durch die Einrichtung einer User Group zu unterstützen, die nur TMF-Mitgliedern, sondern alle Interessierten Deliverable D1.1: Anforderungsanalyse, Integrated Data Repository Toolkit (IDRT), März / 44

10 offen steht. Dadurch ergaben sich wertvolle Erkenntnisse für die breite Anwendbarkeit der i2b2 Software in Deutschland. Die i2b2 User Group hat vor dem bereits erwähnten Workshop am in Erlangen zwei weitere Treffen durchgeführt, aus denen Anregungen zum Einsatz von i2b2 gewonnen wurden, am ebenfalls in Erlangen und am in Berlin Diskussion in der TMF AG IT & Qualitätsmanagement Eine weitere Quelle für Anwenderberichte und fachlichen Diskurs stellen die Treffen der TMF Arbeitsgruppen, in diesem Fall speziell der AG IT & Qualitätsmanagement, dar. Das i2b2- Projekt wurde hier mehrfach detailliert besprochen: bei seiner Vorstellung als Teil der generischen Komponenten der IT-Strategie, während der Erstellung des Communityvotums für einen Antrag in der BMBF-Ausschreibung Instrumente und Methoden [3] sowie im Rahmen der aktuellen Antragstellung. Die Mitarbeiter in den TMF-Arbeitsgruppen fungieren mit ihrem Stimmrecht bei der Einreichung neuer interner TMF-Projekte auch als fachliche Gutachter. Daher zeichnet sich die Diskussion häufig durch ein gesundes Maß an Kritik aus oder resultiert in alternativen Handlungsempfehlungen. Einige Bedenken konnten durch die detaillierte Vorstellung des Gesamtkonzepts ausgeräumt werden, bestehende Kritikpunkte wurden als Anforderung an i2b2 reformuliert Diskussion während i2b2 User Group am Als Auftaktveranstaltung des IDRT-Projekts fand am 27. Februar 2012 ein weiteres Treffen der i2b2 User Group in Berlin statt. Der Fokus lag dabei neben einer Vorstellung des IDRT- Projekts auf einer breiten Auswahl an Anwenderberichten, zum Beispiel zu SHRINE als Ansatz zum Aufbau einer Föderation aus i2b2 Data Warehouses und zur Abfrage auf verteilten Datenbeständen, der Entwicklung einer i2b2-hl7-etl-zelle zur Echtzeit-Befüllung des Data Warehouse oder der Implementierung einer Integrationsplattform für die Norddeutsche Tumorbank Darmkrebs (ColoNet) auf der Basis von i2b2. Daneben nahm die Diskussion mit Anwendern großen Raum ein. Während der Registrierung zur User Group waren die Teilnehmer bereits zu ihren Anforderungen an i2b2 bzw. klinische Data Warehouses befragt worden. Die dabei genannten Kriterien wurden aufbereitet und während der User Group umfänglich diskutiert. Deliverable D1.1: Anforderungsanalyse, Integrated Data Repository Toolkit (IDRT), März / 44

11 6. Ergebnisse Die Ergebnisse der Anforderungsanalyse sind Voraussetzung für eine hohe Zufriedenheit der zukünftigen Nutzer und eine breite Verwendung der im Rahmen dieses Antrags entwickelten Lösungen. Im folgenden Kapitel werden die recherchierten Anforderungen tabellarisch aufbereitet. Jede Anforderung wird dabei als ein Kriterium dargestellt, welches von den Befragten an ein Werkzeug für die Datenintegration und -abfrage im klinischen Kontext angelegt wurde. Wie im vorigen Kapitel detailliert dargelegt, handelt es sich zum Teil um Meinungsäußerungen aus der Community, welche nach bestem Wissen genauso wiedergegeben werden, wie sie getätigt wurden. Sie spiegeln daher unbedingt die Meinung der Autoren wieder, dass es sich dabei überhaupt um ein legitimes Kriterium an ein solches Werkzeug handelt. Obwohl versucht wurde, sehr ähnliche Kriterien zusammenzufassen, lassen sich Überlappungen naturgemäß vermeiden. Des Weiteren haben die Autoren darauf verzichtet, selbst Kriterien zu konstruieren, die als Anforderung formuliert wurden, auch wenn die vorliegende Tabelle alle Aspekte erschöpfend behandelt Erläuterungen der Ergebnistabelle Aus Gründen der Übersichtlichkeit wurden in der Tabelle kurze Spaltentitel gewählt, deren Bedeutung zum besseren Verständnis hier kurz erläutert werden soll: Nr. Laufende Nummer des Kriteriums, wird zur Identifikation und Referenzierung in anderen Kriterienbeschreibungen genutzt. Kriterium Kurzbezeichnung des Kriteriums durch prägnante Schlagwörter. Beschreibung Nähere Beschreibung des Kriteriums bzw. den benötigten Funktionalität, so wie sie in der Literatur, in den interviews, den Workshops und den Treffen der User Group geäußert wurde. Die Kriterien an dieser Stelle sind allgemeine Anforderungen an ein Werkzeug zur Datenintegration und -abfrage und i2b2-spezifisch. Kategorie Kategoriale thematische Einordnung des Kriteriums in einen höheren Kontext. Deliverable D1.1: Anforderungsanalyse, Integrated Data Repository Toolkit (IDRT), März / 44

12 Anwendung: geforderte Anwendungsmöglichkeiten und Anwendungsgebiete des Werkzeugs Datenintegration (ETL): Kriterien, die das Extrahieren, Transformieren und Laden von Quelldaten betreffen, des Weiteren Quelldatenformate und ETL-Systeme Datenqualität: Kriterien zur "Reinhaltung" von Daten (Cleansing), zur Erkennung von Dubletten und zur Verwaltung von Metadaten zu klinischen Fakten Datenschutz: Fragen speziell zu identifizierenden Daten, zu Pseudonymisierung und zu Patienteneinwilligungserklärungen Dokumentation: gewünschte Tutorials oder Leitfäden zu spezifischen Themen Funktionalität: einzelne Fähigkeiten des Werkzeugs, bestimmte Teilaufgaben erfüllen zu können Installation: Kriterien die Installation des Werkzeugs betreffend Lizenz: Fragen zur Verfügbarkeit des Quellcodes und zu den Nutzungsbedingungen Lokalisierung: Kriterien für eine deutschsprachige Benutzerführung und Dokumentation Rechte und Rollen: Anforderungen an ein feingranulares Benutzerkonzept System: Fragen zur technischen Architektur des Werkzeugs und seiner abhängigen Komponenten Terminologien und CDEs: benötigte Terminologien und Datenelemente zum Ontologieaufbau und -management (Common Data Element CDE) Erfülltheit Beschreibt in einer fünfstufigen Skala, inwieweit i2b2 das jeweilige Kriterium erfüllt. 1 - Gar 2 - Minimal 3 - Teilweise 4 - Größtenteils 5 - Vollständig Erklärung/ Kommentar Enthält eine detaillierte Erläuterung, auf Basis welcher Fakten die Einschätzung zur Erfülltheit getroffen wurde und skizziert ferner eine Begründung für den Aufwand, der nötig wäre, das Kriterium vollständig umzusetzen. Häufigkeit Deliverable D1.1: Anforderungsanalyse, Integrated Data Repository Toolkit (IDRT), März / 44

13 Gibt die ungefähre Häufigkeit der Nennung des Kriteriums in der Anforderungsanalyse an und hilft, den echten Bedarf in der Community zu quantifizieren. 1 - Einzel 2 - Einzel 3 - Mehrfach 4 - Mehrfach 5 - Mehrheits Priorität Die Priorität eines Kriteriums im Hinblick auf seine Umsetzung im aktuellen IDRT-Projekt ergibt sich aus der Häufigkeit der Nennung, den vorhandenen Vorarbeiten in i2b2, dem Aufwand für seine Umsetzung, der Qualifikation der Projektpartner, das Kriterium umzusetzen, sowie aus Abhängigkeiten im Arbeitsworkflow (Daten können exportiert werden bevor sie importiert wurden). Zur eigentlichen Priorisierung wurden Klassen nach der MoSCoW-Methode 12 gebildet, allerdings erweitert um eine fünfte Stufe NONE für Requirements, die zwar genannt wurden, aber deren Umsetzung prinzipiell für sinnvoll gehalten wird. 1 - Keine (NONE) 2 - Gering (WONT) 3 - Wichtig (COULD) 4 - Dringend (SHOULD) 5 - Unerlässlich (MUST) Resultierende Anforderung Aus den priorisierten Kriterien leiten sich Arbeitspunkte für ein Integrated Data Repository ab. Inhaltlich ähnliche Kriterien werden in einer Anforderung zusammengefasst. Nicht jedes Kriterium mit einer hohen Priorität resultiert zwangsläufig in einer Anforderung, z.b. wenn die Anforderung von i2b2 bereits erfüllt ist oder falls der Aufwand als zu hoch eingeschätzt wird. Die Liste resultierender Anforderungen wird in Kapitel 7 diskutiert. Aufgrund begrenzter Ressourcen können alle die Aufgabenpakete innerhalb der aktuellen Förderung des Projekts umgesetzt werden. Aufwand 12 Deliverable D1.1: Anforderungsanalyse, Integrated Data Repository Toolkit (IDRT), März / 44

14 Geschätzter Aufwand für die Umsetzung eines Kriteriums als Differenz des notwendigen Funktionsumfangs minus der bereits vorhandenen Funktionalitäten. 1 - Keiner 2 - Gering 3 - Mittel 4 - Hoch 5 - Extrem R -Referenzprojekte Beschreibt, ob ein Kriterium seinen Ursprung in der Evaluation der Referenzprojekte (siehe 5.1) hat. Ein Kriterium kann von verschiedenen Quellen genannt worden sein. L - Literaturanalyse Beschreibt, ob ein Kriterium seinen Ursprung in der Literaturanalyse (siehe 5.2) hat. I - Interviews Beschreibt, ob ein Kriterium seinen Ursprung in den Interviews bei potenziellen Anwendern (siehe 5.2) hat. C - Community Beschreibt, ob ein Kriterium seinen Ursprung in den Anforderungen aus der Community (siehe 5.4) hat. Bezug zu Enthält Querverweise zu inhaltlich relevanten anderen Kriterien. Deliverable D1.1: Anforderungsanalyse, Integrated Data Repository Toolkit (IDRT), März / 44

15 6.2. Liste der Anforderungen Nr Kriterium Beschreibung Kategorie Erfülltheit Erklärung/ Kommentar Häufigkeit Priorität Resultierende Anforderung Aufwan d R L I C Bezu g zu Quellcode verfügbar Der Quellcode des Produkts soll Lizenz 5 - Der Quellcode von i2b2 ist ohne 2 - Einzel 3 - Wichtig 1 - Keiner x 02 nachhaltig frei verfügbar sein, Vollständig Einschränkungen herunterladbar. um Erweiterungen und Eine Registrierung ist Korrekturen selbst vernehmen erforderlich. zu können (Open-Source). Kostenarme Lizenz Moderne Architektur Schnittstellen Das Produkt soll nur geringe Lizenzkosten für Inbetriebnahme, Routinebetrieb, Updates oder Erweiterungen erfordern. Idealerweise handelt es sich um freie Software mit einer anerkannten Lizenz (z.b. LGPL, Apache, MIT, Eclipse) Das System soll über eine moderne Architektur verfügen, d.h. in einer gängigen Programmiersprache geschrieben sein und auf reifen, aber veralteten Komponenten (z.b. Frameworks für Datenbankzugriff, Logging, GUI) aufbauen, damit es später leichter und ohne Spezialkenntnisse gepflegt werden kann. Das System soll über Schnittstellen zum Zugriff auf Teilmodule oder -funktionen verfügen. Die Schnittstellen sollen dokumentiert sein und auf Standards (z.b. WebServices, REST) basieren. Lizenz 4 - Größtenteils System 4 - Größtenteils System 5 - Vollständig i2b2 ist für alle Szenarien kostenfrei verfügbar. Es wird jedoch keine Standardlizenz verwendet. Änderungen am Produkt müssen dem Brigham and Women s Hospital zurückgemeldet und diesem eine kostenfreie Verwendung gestattet werden. i2b2 ist in Java geschrieben. Es verwendet typische Bibliotheken (JAXB, Axis2, Commons) und verschiedene Enterprise-Features des Applikationsservers. Der Client ("Workbench") basiert auf der populären Eclipse-IDE. i2b2 verwendet den Begriff des Hive, der aus Waben bzw. Zellen zusammengesetzt ist. Alle Zellen kommunizieren direkt miteinander, sondern über WebService. So ist es nur möglich, zusätzliche Zellen (auch eigene) anzubinden, Zellen können auch ausgetauscht oder auf verschiedene Systeme verteilt werden. 2 - Einzel 1 - Einzel 3 - Mehrfach 3 - Wichtig 1 - Keiner x x Gering 1 - Keiner x 06, 07, Wichtig 1 - Keiner x x 05 Deliverable D1.1: Anforderungsanalyse, Integrated Data Repository Toolkit (IDRT), Juli / 44

16 Nr Kriterium Beschreibung Kategorie Erfülltheit Erklärung/ Kommentar Häufigkeit Priorität Resultierende Anforderung Aufwan d R L I C Bezu g zu Plugin-Konzept Es soll möglich sein, zusätzliche System 5 - Plugins können über das i2b2-3 - Mehrfach 3 - Wichtig 1 - Keiner x x 04 Funktionalitäten mit eigenen Vollständig Zellenkonzept realisiert werden. Erweiterungen nachzurüsten, ohne dass ein Neukompilieren/ Neuinstallieren nötig wird. Dies kann durch ein generisches Plugin-Konzept erreicht werden, mit welchem es möglich ist, Module, die bestimmten Anforderung genügen, in einen dedizierten Bereich einzuspielen. Freie Komponenten Infrastrukturintegra tion Pseudonymisierung / Anonymisierung Der Softwarestack abhängiger Programmbibliotheken soll auf freien Komponenten aufbauen, um die Kosten für den Einsatz gering zu halten und Problemen bei der Weiterentwicklung zuvorzukommen. Das System soll sich gut in bestehende Infrastrukturen einordnen. Dies bedeutet im Besonderen, dass abhängige Serversysteme wie Datenbanken, Applikationsserver, Webserver, Verzeichnisdienste oder Mailserver a) über Standardschnittstellen angesprochen werden oder b) abhängige Systeme frei zur Verfügung stehen oder c) bei ausschließlich kommerziellen abhängigen Systemen mehrere verbreitete Alternativen genutzt werden können Es soll möglich sein, für Patienten beim Hochladen in i2b2 pseudonyme Identifier (PIDs) zu generieren, um einerseits einen eindeutigen Schlüssel für die Arbeit mit dem Patienten zu besitzen, andererseits jedoch keine System 5 - Vollständig System 3 - Teilweise Datenschutz 1 - Gar Für i2b2 sind keine lizenz- oder kostenpflichtigen Komponenten notwendig, es wird auf Open- Source-Software zurückgegriffen. i2b2 setzt im Wesentlichen auf zwei Systemen auf: einem freien Java- Applikationsserver (JBoss+Tomcat), welcher bereits mitgeliefert wird, sowie einer Datenbank, wobei aktuell nur Oracle und MS SQL Server unterstützt werden. i2b2 führt keine Pseudonymisierung durch, daher müssen keine Zuordnungslisten gespeichert werden. Die Anonymisierung stellt eine besondere Form der Pseudonymisierung dar und ist daher ebenfalls vorhanden. 2 - Einzel 4 - Mehrfach 4 - Mehrfach 2 - Gering 1 - Keiner x 03, 07, Gering 3 - Mittel x 03, 06, Unerlässlich Integration TMF PID-Generator 3 - Mittel x x x 09, 10, 13 Deliverable D1.1: Anforderungsanalyse, Integrated Data Repository Toolkit (IDRT), Juli / 44

17 Nr Kriterium Beschreibung Kategorie Erfülltheit Erklärung/ Kommentar Häufigkeit Priorität Resultierende Anforderung solchen Daten abfragbar zu speichern, welche für Dritte die Identifikation des Patienten ermöglichen würden (IDATs). Verhinderung der Datenschutz Mehrfach Re-Identifikation Teilweise von Patienten Pseudonymisierung 2. Stufe Für große Forschungsverbünde, welche Daten auch Dritten zur Verfügung stellen, ist es wichtig, dass Patienten mit Hilfe des Datenbestandes oder in Kombination mit anderen Daten durch komplexe Abfragen identifiziert werden. Diese Gefahr besteht im Besonderen bei Patienten mit seltenen Merkmalen (z.b. Sterbeort und Sterbejahr bei kleinen Gemeinden). Im Falle einer einfachen Pseudonymisierung besteht das Risiko, dass Personen mit Zugriff auf die PID- Zuordnungsliste Patienten eindeutig identifizieren können, wenn sie beispielsweise weitere klinische Systeme einsehen können. Ein Pseudonymisierungsdiensts zweiter Stufe führt beim Export von Daten aus dem Data Warehouse eine weitere Pseudonymisierung durch, wobei die Zuordnungsliste PID1 zu PID2 bei einem unabhängigen Treuhänder verbleibt. Datenschutz 1 - Gar i2b2 verfügt aber über einige Mechanismen zur Sicherstellung der Nichtidentifikation von Datensätzen über eine geeignete Abfolge von Queries. Abfragen mit geringen Ergebnismengen werden leicht verzerrt: die Ergebnismenge wird um einige Werte korrigiert, wie es der Gaußschen Normalverteilung entsprechen würde. Des Weiteren können beliebig detaillierte und beliebig häufig Anfragen gestellt werden. i2b2 führt ein Auditlog und bemerkt derartige Versuche. Fortgeschrittene Algorithmen zur k-anonymisierung oder L-Diversität sind jedoch implementiert. i2b2 führt keine Pseudonymisierung 2. Stufe durch, daher müssen keine Zuordnungslisten gespeichert werden. 4 - Mehrfach 3 - Wichtig Integrierung eines Anonymisierung sdienstes 4 - Dringend Integration TMF Pseudonymisier ungsdienst Aufwan d R L I C Bezu g zu 4 - Hoch x x 08, 10, Mittel x x 08, 09, 13 Deliverable D1.1: Anforderungsanalyse, Integrated Data Repository Toolkit (IDRT), Juli / 44

18 Nr Kriterium Beschreibung Kategorie Erfülltheit Erklärung/ Kommentar Häufigkeit Priorität Resultierende Anforderung Consent Datenschutz 1 - Gar 4 - Management Dringend TMF Datenschutzkonzept Record Linkage Die Plattform soll eine Steuerung und Beschränkung der Datenabfrage auf Basis strukturierter Einwilligungsdaten unterstützen und die Anonymisierung/Löschung von Patientendaten bei Widerruf der Einwilligung sicherstellen. Es sollen die überarbeiteten Datenschutzkonzepte der TMF auf den Einsatz eines Data Warehouse angewendet werden. Werden Daten über verschiedene Datensammlungen zusammengeführt, z.b. für epidemiologische Fragestellungen, kann es je nach Anwendungsfall gewünscht sein, Dubletten zu erkennen und Patientendatensätze zu vereinigen, ohne dass dabei auf identifizierende Daten oder Identifier zurückgegriffen Datenschutz 5 - Vollständig Datenqualität 1 - Gar Aktuell gibt es keine Unterstützung für Consent Management. I2b2 wird entweder in einem Kontext eingesetzt, wo eine explizite Einverständniserklärung nötig ist (Behandlungszusammenhang) oder geht davon aus, dass eine Einwilligung vorliegt. i2b2 wird primär als Komponente in einem Forschungsverbund betrieben. Der Datenschutz sollte daher im Gesamtkontext des Forschungsverbundes betrachtet werden. Keines der 4 Module in der aktuellen Revision der Datenschutzkonzepte der TMF erfordert den Einsatz eines Data Warehouse, in keinem ist er ausgeschlossen. Tatsächlich lassen sich viele Mischszenarien vorstellen, in denen mehrere i2b2-instanzen mit unterschiedlich harten Datenschutzanforderungen betrieben werden. Da i2b2 die Problematik des Datenschutzes in der medizinischen Forschung im Datenmodell adressiert und in jedem der Module eingesetzt werden könnte, wird die Anforderung als erfüllt angesehen. i2b2 enthält weder mathematische Modelle zur Wahrscheinlichkeitsabschätzung von Ähnlichkeiten noch Funktionen zum "Mergen" von Patientendaten im Falle einer erkannten Dublette. 4 - Mehrfach 2 - Einzel 2 - Einzel Integration von Funktionen zur Verwaltung von Patient- Consent-Daten Aufwan d R L I C Bezu g zu 3 - Mittel x x 2 - Gering 3 - Mittel x 2 - Gering 4 - Hoch x 08, 09, 10 Deliverable D1.1: Anforderungsanalyse, Integrated Data Repository Toolkit (IDRT), Juli / 44

19 Nr Kriterium Beschreibung Kategorie Erfülltheit Erklärung/ Kommentar Häufigkeit Priorität Resultierende Anforderung werden kann. Provenance Das System soll Annotationen Datenqualität 2 - Minimal i2b2 kennt verschiedene Metadaten 4 - Mehrfach 3 - Wichtig Integration von der gespeicherten zu klinischen Fakten wie erste/ Metadaten zur Informationen mit Metadaten letzte Aktualisierung, Provider der Herkunft und zu Herkunft, Status, Qualität, Information, Visiten oder Qualität der Eigentums- und Quellsystem. Diese sind aber Faktendaten Verwertungsrichtlinien statisch und geeignet, z.b. verwalten können, um z.b. bei Kalibrierungen von Medizingeräten Abfragen auf Quelldaten mit zu verwalten. bestimmten Qualitätsanforderungen (z.b. Monitoring) einschränken zu können. Leichte Installation Leichte Administration Das System soll mit überschaubarem Aufwand von normalqualifiziertem technischen Personal vollfunktionsfähig installiert werden können. Das System soll mit überschaubarem Aufwand von normalqualifiziertem Personal administriert werden können, vorzugsweise über eine grafische Oberfläche. Installation 2 - Minimal i2b2 kann in zwei Varianten heruntergeladen werden: als virtuelle Maschine (VM) und im Quellcode. Ersteres ermöglicht den leichten Einstieg, da es sich um ein vollkonfiguriertes und sofort einsetzbares System handelt. Für den produktiven Einsatz muss das System jedoch in den meisten Fällen in einer anderen Umgebung laufen (Betriebssystem, Netzwerkkonfiguration,...). Zusätzlich werden einige Komponenten mit Standardpasswörtern ausgeliefert. Daher sollte das System besser aus den Quellen gebaut werden. Dies ist aber bei einem komplexen System mit vielen abhängigen Komponenten trivial. System 2 - Minimal i2b2 verfügt über eine rudimentäre Administrationskonsole, bei der sich verschiedene Konfigurationsparameter eingeben bzw. Nutzer erzeugen und Projekten zuordnen lassen. Funktionen z.b. zum Erzeugen neuer Projekte oder zum Laden von Beispieldaten fehlen. 5 - Mehrheits 4 - Mehrfach 5 - Unerlässlich 5 - Unerlässlich Aufwan d 5 - Extrem R L I C Bezu g zu x x x 41 i2b2 Wizard 3 - Mittel x x x i2b2 Wizard 3 - Mittel x Deliverable D1.1: Anforderungsanalyse, Integrated Data Repository Toolkit (IDRT), Juli / 44

20 Nr Kriterium Beschreibung Kategorie Erfülltheit Erklärung/ Kommentar Häufigkeit Priorität Resultierende Anforderung Benutzerfreundliche System Mehrfach grafische Teilweise Schnittstelle für Endanwender Loader für ODM- Daten Loader für SQL- Daten Loader für CSV- Daten Nutzerfreundliches, selbsterklärendes Interface mit geringer Anlernzeit bzw. Betreuungsaufwand. Als Zielgruppe werden klinische Forscher und Dokumentare erwartet, die nur einen geringen Teil ihrer Arbeitszeit mit dem System verbringen. Der Import von Daten im CDISC ODM-Format soll unterstützt werden, da dieses Format von vielen Studiendatenmanagementsyste men für den Export klinischer Probandendaten und Studienmetadaten verwendet wird. Der Import von Daten aus typischen relationalen Datenbanken über SQL soll unterstützt werden. Der Import von zeichengetrennten tabellarischen Textdateien soll unterstützt werden, weil es sich dabei um das häufigste Austauschformat von Daten aus Informationssystemen der Versorgung handelt. Datenintegratio n (ETL) Datenintegratio n (ETL) Datenintegratio n (ETL) 1 - Gar 1 - Gar i2b2 besitzt zwei unterstützte Clients: eine Workbench, die lokal installiert werden muss und den etwas größeren Funktionsumfang hat und einen AJAX-Client für Webbrowser. Beide Varianten versuchen, sämtliche Funktionalität direkt in der Nutzermaske unterzubringen, aufgabenorientierte Assistenten existieren nur minimal, ebenso Hilfstexte. Abhängig von der Zahl installierter Plugins kann die Oberfläche komplex werden. Eine Benutzung ohne vorhergehende Schulung ist ratsam. Die Entwicklung eigener Clients ist aufgrund des modularen Aufbaus und der Interzellkommunikation über WebServices möglich, aber sehr aufwendig. Keine Unterstützung für den Import von ODM-Dateien in i2b2 vorhanden. Unterstützung für das XML Based Clinical Experiment Data Exchange Schema (XCEDE) in Überlegung, wobei die Relevanz des Letzterem strittig ist. Keine Unterstützung im System selbst, Plugins verfügbar (ungetestet). 2 - Minimal Es existiert eine i2b2-zelle mit dem Namen 5 - Mehrheits 4 - Mehrfach 5 - Mehrheits Aufwan d 3 - Wichtig 5 - Extrem 4 - Dringend 5 - Unerlässlich 5 - Unerlässlich R L I C Bezu g zu x x 27, 63 ODM-Extraktor 4 - Hoch x x x 26 SQL-Extraktor 3 - Mittel x x x 26 CSV-Extraktor 3 - Mittel x x x 26 Deliverable D1.1: Anforderungsanalyse, Integrated Data Repository Toolkit (IDRT), Juli / 44

21 Nr Kriterium Beschreibung Kategorie Erfülltheit Erklärung/ Kommentar Häufigkeit Priorität Resultierende Anforderung Aufwan d R L I C Bezu g zu Loader für 21- Datenintegratio 1 - Gar 4-21-Extraktor 3 - Mittel x x 26 Daten n (ETL) Dringend Loader für DICOM- Daten Der Import des Paragraph 21 Benchmarkingdatensatzes aus der DRG-Abrechnung soll unterstützt werden. Der Import von Metadaten zu bildgebenden Verfahren soll unterstützt werden. Datenintegratio n (ETL) 1 - Gar Keine Unterstützung. 5 - Mehrheits Keine Unterstützung im System selbst, Plugins verfügbar (ungetestet). 2 - Einzel 3 - Wichtig Extraktor für DICOM- Metadaten 3 - Mittel x Loader für Biomaterialien Loader für genomische Daten KAS-Anbindung Generisches ETL- Tool Der Import von Metadaten zu Biomaterialproben und Verwaltungsinformationen soll unterstützt werden. Der Import von genomischen Daten (nur Ergebnisdaten, Sequenzen) soll unterstützt werden, z.b. zur Aggregation klinischer und genomischer Daten oder Observationsstudien genetischer Varianten. Der Import von Daten aus dem klinischen Arbeitsplatzsystem (Patientenakten, Aufnahmevorgänge) soll unterstützt werden (ggf. über HL7-Nachrichten). Es soll ein universell parametrisierbares Verfahren zum Datentransfer bzw. zur Unterstützung der Datenintegration (Preprocessing) bereitgestellt werden, welches existierende Daten in verschiedenen Formaten auf das Datenbankschema des Systems abbilden kann. Datenintegratio n (ETL) Datenintegratio n (ETL) Datenintegratio n (ETL) Datenintegratio n (ETL) 1 - Gar 1 - Gar 1 - Gar 1 - Gar Keine Unterstützung im System selbst, Plugins verfügbar (ungetestet). Keine Unterstützung im System selbst, Plugins verfügbar (ungetestet). Keine Unterstützung im System selbst, Plugins verfügbar (ungetestet). Üblicherweise erlauben KAS den Export ihrer Daten in einem Format, welches mit den zuvor genannten generischen Extraktoren importiert werden kann. Der Import von HL7- Nachrichten wäre dann sinnvoll, wenn die Daten minutengenau benötigt werden, z.b. zur zeitnahen Rekrutierung von Probanden für Studien im Bereich Notfallchirurgie. Es ist zweifelhaft, ob eine so komplexe Aufgabe innerhalb von i2b2 erfolgen kann oder sollte. Es sind viele freie und mächtige ETL- Tools oder Dienste verfügbar, eine Integration in i2b2 (speziell die Nutzeroberfläche) wäre zwar reizvoll, realistischerweise werden Datenimporte aber ad hoc von klinischen Forschern durchgeführt. 4 - Mehrfach 2 - Einzel 2 - Einzel 5 - Mehrheits 4 - Dringend 4 - Dringend Extraktor für Biomaterialdate n 3 - Mittel x x Mittel x x Gering 4 - Hoch x x Dringend Anpassung einer etablierten ETL- Plattform für i2b2 2 - Gering x x x x 18, 19, 20, 21, 22, 23, 24, 25 Deliverable D1.1: Anforderungsanalyse, Integrated Data Repository Toolkit (IDRT), Juli / 44

22 Nr Kriterium Beschreibung Kategorie Erfülltheit Erklärung/ Kommentar Häufigkeit Priorität Resultierende Anforderung Deutsche Lokalisierung 1 - Gar 3 - Mehrfach Benutzeroberfläche Deutschsprachige Dokumentation Berechtigungskonze pt Die Benutzeroberfläche der Clients soll in deutscher Sprache zur Verfügung stehen, damit die Einstiegshürde für klinische Forscher niedriger ist. Es soll eine Dokumentation in Deutsch vorhanden sein, um die Sprachbarriere zu überwinden. Ein differenziertes Berechtigungskonzept soll die Beschränkung des Zugriffs auf berechtigte Nutzer sicherstellen. Das Werkzeug soll mandantenfähig sein, aber auch projektübergreifende Abfragen zulassen. Rechtemanagement Für komplexe Forschungsprojekte mit mehreren Datenquellen ist es wünschenswert, verschiedenen Nutzergruppen Abfragen nur auf einer Teilmenge der Daten zu erlauben, z.b. nur auf Daten aus ihrem Studienzentrum oder auf identifizierende Daten. Lokalisierung Rechte und Rollen Rechte und Rollen 1 - Gar 3 - Teilweise 3 - Teilweise Aktuell stehen keine Sprachvarianten außer englisch zur Verfügung. Die i2b2-dokumentation in vielen Fällen sehr detailliert. Eine Übersetzung ist im Hinblick auf die stetige Fortentwicklung der Plattform schnell veraltet und daher als sinnvoll zu betrachten. Die bestehende Dokumentation kann mit moderaten Englischkenntnissen verstehend gelesen werden. Mandantenfähigkeit bedeutet, dass die Daten mehrerer Nutzergruppen vollständig getrennt voneinander auf einem System verwaltet werden können. Dies ist durch das Konzepts des i2b2-"projekts" gegeben, von denen jede i2b2- Instanz eine beliebige Zahl aufnehmen kann. Übergreifende Abfragen sind möglich (auch, wenn ein Nutzer Rechte in mehreren Projekten besitzt). Dies kann nur durch speziell geschaffene Meta-Projekte realisiert werden, die jeweils den duplizierten Datenbestand aller Teilprojekte enthalten. Das Rechtemanagement in i2b2 unterliegt der PM-Zelle. Für jedes Projekt existieren fest vorgegebene Nutzerrechte, welche bestimmten Rollen zugewiesen sind. Jeder Nutzer hat 2 Rollen, eine mit administrativen Rechten für das Projekt (Anlegen neuer Nutzer etc.) und eine für die Sicht auf Daten. Letztere kennt 5 Granularitätsstufen absteigenden Schutzniveaus (Obfuscated, Aggregated, Limited, De-identified, Protected), wobei 3 - Mehrfach 5 - Mehrheits 5 - Mehrheits Aufwan d R L I C Bezu g zu 2 - Gering 4 - Hoch x x 17, Gering 5 - Extrem 4 - Dringend 4 - Dringend Feingranulares Rechte- und Rollenkonzept Feingranulares Rechte- und Rollenkonzept x 3 - Mittel x x x x Extrem x x x x 29 Deliverable D1.1: Anforderungsanalyse, Integrated Data Repository Toolkit (IDRT), Juli / 44

23 Nr Kriterium Beschreibung Kategorie Erfülltheit Erklärung/ Kommentar Häufigkeit Priorität Resultierende Anforderung "obfuscated" nur aggregierte und gegebenenfalls vorsätzlich leicht ungenaue Ergebnisse liefert und "protected" auch identifizierende Daten aus dem Identity- Management-Zelle zurückgibt. Rechte auf der Ebene einzelner Fakten (-typen, -pfade) sind abbildbar. Eine eigene Implementierung einer fortgeschrittenen Rechteverwaltung z.b. als Bit-Vektor in einer dedizierten Spalte der Faktentabelle und einer eigenen Proxyzelle zur Modifikation der Ergebnisse wäre denkbar, aber aufwendig. Bereitstellung ICD- Terminologien 1 - Gar 5-10-GM und CDE Unerlässlich Bereitstellung OPS Bereitstellung LOINC Bereitstellung TNM Die Terminologie ICD-10 zur Kodierung von Krankheiten und Diagnosen soll im System verfügbar sein. Die Terminologie OPS zur Kodierung von Operationen und Prozeduren soll im System verfügbar sein. Die Terminologie LOINC zur Kodierung von Laborwerten soll im System verfügbar sein. Die Terminologie TNM zur Kodierung von Tumorerkrankungen soll im System verfügbar sein. Terminologien und CDE Terminologien und CDE Terminologien und CDE 1 - Gar 3 - Teilweise 1 - Gar Eine aktuelle deutschsprachige Version der Internationalen Statistischen Klassifikation der Krankheiten und verwandter Gesundheitsprobleme (ICD-10) ist bislang für i2b2 verfügbar. Eine aktuelle deutschsprachige Version der Operationen- und Prozedurenschlüssel (OPS), der deutschen Modifikation der Internationalen Klassifikation der Prozeduren in der Medizin (ICPM), ist bislang für i2b2 verfügbar. i2b2 verfügt über ein Demoprojekt, welches neben ICD9-CM und National Drug Classification (NDC) auch Logical Observation Identifiers Names and Codes (LOINC) enthält. Wie aktuell und vollständig die Variante ist, konnte noch getestet werden. Eine aktuelle Version von TNM ist bislang verfügbar. 5 - Mehrheits 5 - Mehrheits 4 - Mehrfach 4 - Mehrfach 5 - Unerlässlich 4 - Dringend 4 - Dringend Bereitstellung Standardterminologien Bereitstellung Standardterminologien Bereitstellung Standardterminologien Bereitstellung Standardterminologien Aufwan d R L I C Bezu g zu 2 - Gering x x 2 - Gering x x 3 - Mittel x x 3 - Mittel x Deliverable D1.1: Anforderungsanalyse, Integrated Data Repository Toolkit (IDRT), Juli / 44

24 Nr Kriterium Beschreibung Kategorie Erfülltheit Erklärung/ Kommentar Häufigkeit Priorität Resultierende Anforderung Bereitstellung ICD- Terminologien 1 - Gar Eine aktuelle Version von ICD-O ist 4 - O und CDE bislang für i2b2 verfügbar. Dringend Bereitstellung molekulare Marker Bereitstellung Rote Liste Bereitstellung Common Domains Die Terminologie ICD-O zur Kodierung von Tumorerkrankungen soll im System verfügbar sein. Molekulare Marker sind Gensequenzen, die aufgrund bestimmter phänotypischer Ausprägungen leicht identifiziert werden können. Eine konkrete Terminologie von Daten zu molekularen Markern wurde genannt. Eine kurze Recherche ergab keine aussichtsreichen Kandidaten. Die Terminologie Rote Liste zur Kodierung von Medikamenten bzw. Wirkstoffen soll im System verfügbar sein. Es soll eine universell anwendbare Navigationsontologie mit typischen Domänen für Datenelemente entworfen werden. Terminologien und CDE Terminologien und CDE Terminologien und CDE 1 - Gar 1 - Gar 1 - Gar Eine Terminologie zu molekularen Markern ist bislang verfügbar. Es ist zu erwarten, dass Terminologien zu molekularen Markern technisch ähnlich aufgebaut sind wie andere Domänenterminologien (siehe bspw. National Drug File) und keine komplexe Zusatzentwicklung notwendig wird. Eine aktuelle Version der Roten Liste ist bislang für i2b2 verfügbar. Eine solche Ontologie existiert bislang. Es werden entweder Standardterminologien verwendet oder lokale Ontologien, die sich aus der Struktur einzelner Forschungsprojekte ergeben. Ausgehend von den SDTM- Domänen soll eine solche intuitive i2b2-ontologie entworfen werden, die die am häufigsten vorkommenden Datenelemente aus klinischen Studien und epidemiologischen Registern beinhaltet und in logischen, intuitiv benannten Kategorien gruppiert. Diese Ontologie richtet sich im Besonderen an klinische Forscher, die Auswertungen auf Daten von Dritten vornehmen wollen und den genauen Aufbau der Projekte kennen. 4 - Mehrfach 1 - Einzel 2 - Einzel 3 - Mehrfach Bereitstellung Standardterminologien Aufwan R L I C Bezu d g zu 3 - Mittel x 1 - Keine 2 - Gering x 2 - Gering 2 - Gering x 3 - Wichtig Bereitstellung Standardterminologien 3 - Mittel x x Deliverable D1.1: Anforderungsanalyse, Integrated Data Repository Toolkit (IDRT), Juli / 44

25 Nr Kriterium Beschreibung Kategorie Erfülltheit Erklärung/ Kommentar Häufigkeit Priorität Resultierende Anforderung Ontologieaufbau Terminologien Metadatenedito und -verwaltung und CDE Teilweise Unerlässlich r Mapping auf/ zwischen Standardterminolog ien Es soll ein Werkzeug zum Aufbau und der Verwaltung von Navigationsontologien inklusive Zusammenführung von Kodierungen verfügbar sein. Es soll ein Mapping von Datensätzen auf Terminologien bzw. zwischen Terminologien verfügbar sein. Terminologien und CDE i2b2 verfügt über rudimentäre Funktionen für den Ontologieaufbau. Mit Hilfe von "Edit Terms" lassen sich Ordner und Blätter von Ontologien erstellen inklusive der Modellierung komplexer Konzepte wie Fakten über Fakten (i2b2 Modifier). Des Weiteren lassen sich auch Synonyme für bestehende Konzepte anlegen. Die eigentlichen Fakten bzw. deren Kodierungen können aber verändert werden. Auch ist die Modellierung in i2b2 sehr aufwendig und für größere Ontologien praktikabel. 2 - Minimal Dieses Kriterium bleibt bis zu einem gewissen Maße unklar/ unterspezifiziert. Über das NCBO Bioportal liegen eine Reihe von Terminologien in Standardformaten vor (OWL, OBO, RRF) und es wurde bereits ein Web-Service entwickelt, der daraus i2b2-ontologien formen kann. Liegen jedoch keine mit einer bestimmten Terminologie kodierten Quelldaten vor, ergibt sich zunächst kein Grund, die Terminologie in i2b2 zu integrieren. Sollen lokal kodierte Daten konzeptuell auf eine Terminologie abgebildet werden, so handelt es sich um eine Funktionalität, die mit spezieller Kodierungssoftware unter menschlicher Supervision durchgeführt werden sollte (z.b. MedDRA-Kodierung von Unerwünschten Ereignissen). Das Gleiche gilt für konzeptuelle Abbildungen von einer Standardterminologie in eine andere (ähnlich dem Ansatz von UMLS). Dieses Szenario ist deutlich außerhalb des angestrebten 4 - Mehrfach 4 - Mehrfach 3 - Wichtig 5 - Extrem Aufwan R L I C Bezu d g zu 4 - Hoch x x x x Deliverable D1.1: Anforderungsanalyse, Integrated Data Repository Toolkit (IDRT), Juli / 44