Patientenübergreifende, multiple Verwendung von Patientendaten für die klinische Forschung unter Nutzung von Archetypen

Transkript

1 Aus dem Institut für Medizinische Biometrie und Informatik Direktor: Prof. Dr. sc. hum. Meinhard Kieser Sektion Medizinische Informatik Leiter: Prof. Dr.-Ing. Hartmut Dickhaus Patientenübergreifende, multiple Verwendung von Patientendaten für die klinische Forschung unter Nutzung von Archetypen Inauguraldissertation zur Erlangung des Doctor scientiarum humanarum an der Medizinischen Fakultät Heidelberg der Ruprecht-Karls-Universität vorgelegt von Christian Dominik Kohl geboren in Heilbronn-Neckargartach 2012

2 II

3 III Dekan: Doktormutter: Herr Prof. Dr. med. Claus R. Bartram Frau Prof. Dr. sc. hum. Petra Knaup-Gregori

4 IV

5 für Tina V

6 VI

7 VII IN SCIENTIA SALUS Heilung durch Wissenschaft Vincenz Czerny ( )

8 VIII Inhaltsverzeichnis Abbildungsverzeichnis... X Tabellenverzeichnis... XIII Abkürzungsverzeichnis und Glossar... XV 1 Einleitung Gegenstand und Motivation Problemstellung Zielsetzung Grundlagen Begriffsdefinitionen Klinische Studien Klassifikation von Daten Semantische und syntaktische Interoperabilität Zwei-Ebenen-Modell zur Repräsentation von Gesundheitsdaten openehr Bestehende Ansätze zur multiplen Nutzung von Daten aus der Routineversorgung Vorgehen und Methodik Generisches Vorgehensmodell für die multiple Nutzung von Daten in Forschung und Versorgung Fallstudie Prototyp Archetypen zur Dokumentation von und in klinischen Studien Abbildung auf Standards Zusammenfassung des Vorgehens Ergebnisse Fallstudie Prototyp Referenzarchitektur Anforderungen an die Referenzarchitektur Spezifikation der Referenzarchitektur Vorgehen gemäß Referenzarchitektur Archetypen zur Dokumentation von und in klinischen Studien Entwicklung von Archetypen für Studiendaten Entwicklung von Archetypen für Studien-Metadaten Abbildung auf bestehende Standards Zusammenfassung der Ergebnisse... 62

9 IX 5 Diskussion Diskussion von Vorgehen und Methodik Diskussion der Ergebnisse Fallstudie Prototyp Referenzarchitektur Archetypen für Studiendaten Archetypen für Studien-Metadaten Abbildung auf Standards Fazit und Ausblick Zusammenfassung Literaturverzeichnis Eigene Veröffentlichungen Anhang Abbildung CDASH auf openehr-archetypen Abbildung DRKS und WHO/ICTRP Merkmalsarten zu Beschreibung einer Studie auf openehr-archetypen Abbildung openehr-archetypen auf BRIDG-Modell Beispiel: Semantische Annotation von ODM-Elementen mittels Archetypen opensdms: Prozessabläufe Lebenslauf Danksagungen

10 X Abbildungsverzeichnis Abb. 2-1: Merkmalsarten, welche das Konzept Blutdruck beschreiben - dargestellt als Mindmap des openehr-archetyps Blood Pressure Abb. 2-2: Beziehungen zwischen openehr-templates, -Archetypen und - Referenzmodell sowie weiteren Elementen Abb. 2-3: Abb. 3-1: Abb. 3-2: AQL-Abfrage zur Ermittlung der aktuellen Medikation eines Patienten Generisches Vorgehensmodell für die multiple Nutzung von Daten in Forschung und Versorgung Darstellung der für Präsentation, Geschäftslogik und Persistenz in Opereffa genutzten Technologien Abb. 4-1: Ablauf der Datenerhebung in der analysierten Studie Abb. 4-2: Abb. 4-3: Abb. 4-4: Abb. 4-5: Abb. 4-6: Verteilung der Ausprägungstypen der 1452 im KIS dokumentierbaren Merkmalsarten Verteilung der Ausprägungstypen der 200 Merkmalsarten der ctag-studie Ergebnis der Analyse, welcher Anteil der 200 in der ctag-studie benötigten Merkmalsarten im KIS dokumentiert werden kann Verteilung der notwendigen Transformationen, falls alle 70 der im KIS vorhandenen und für die ctag Studie relevanten Merkmalsarten im KIS elektronisch vorlägen Verteilung der 70 Merkmalsarten, die für die ctag-studie multipel genutzt werden könnten, auf die elektronischen und konventionellen Subsysteme des KIS Abb. 4-7: Ansicht Patientenakte von opensdms Abb. 4-8: Ansicht Studie / CRF von opensdms Abb. 4-9: Ansicht Studie / Metadaten von opensdms Abb. 4-10: Abb. 4-11: Abb. 4-12: Abb. 4-13: Abb. 4-14: Abb. 4-15: Abb. 4-16: Datenflüsse bei der Nutzung von opensdms als Integrationssystem Auf Archetypen basierende Referenzarchitektur für die multiple Nutzung von KIS-Daten in klinischen Studien Beispiel für die Nutzung des ODM-Alias-Mechanismus zur semantischen Annotation mit Hilfe eines Archetypen Archetypen mit Relevanz bei der Dokumentation von Medikationsangaben AQL-Abfrage zur Ermittlung der ersten Gabe einer bestimmten Medikation Definition des CDASH CM-Templates im Ocean Template Designer HTML-Eingabemaske generiert aus dem openehr CDASH CM- Template

11 XI Abb. 4-17: Generische Struktur einer klinischen Studie Abb. 4-18: Neu erstellte Archetypen für Studien-Metadaten Abb. 4-19: Verzeichnisstruktur für Studiendaten und Studienmetadaten Abb. 4-20: Abb. 4-21: Abb. 4-22: Abb. 5-1: Abbildung von Studien-Metadaten mittels COMPOSITION und ADMIN_ENTRY-Archetypen in die generische Verzeichnisstruktur AQL-Abfrage zur Ermittlung, ob ein Patient die Einschlusskriterien einer Studie erfüllt Beispiel für die multiple Nutzung des Alias-Mechanismus zur semantischen Annotation eines ODM-Elements Mögliche Varianten bei der Abbildung von Studien-Metadaten mittels Archetypen

12 XII

13 XIII Tabellenverzeichnis Tab. 4-1: Tab. 4-2: Tab. 4-3: Übersicht der in der ctag-studie verwendeten ecrf und der vorgesehenen Visiten Mögliche Abbildungen von CDASH CM-Datenelementen auf openehr-archetypen Gegenüberstellung und Zuordnung der Definition der Merkmalsart primärer Endpunkt einer Studie in den Spezifikationen von DRKS, WHO, openehr und BRIDG-Modell

14 XIV

15 XV Abkürzungsverzeichnis und Glossar ADL AJaX AOM AQL BMBF BRIDG cabig CDASH CDISC CM CIMI CRF ctag DRKS Archetype Definition Language Die ADL ermöglicht es, Archetypen in Textform zu definieren und mit Hilfe von Parsern maschinell zu verarbeiten (siehe Kapitel 2.6). Asynchronous JavaScript and XML AJaX ist eine Möglichkeit, um asynchrone Daten zwischen einem Web- Browser und Server zu übertragen. Archetype Object Model Das AOM ist ein Meta-Modell, um Archetypen zu beschreiben. Das AOM ist das objektorientierte Äquivalent zur ADL (siehe Kapitel 2.6). Archetype Query Language (früher EQL EHR Query Language) Abfragesprache für Daten, die in auf den openehr-spezifikationen basierenden Gesundheitsakten gespeicherte sind (siehe Kapitel 2.6). Bundesministerium für Bildung und Forschung Das BMBF ist unter anderem zuständig für die Förderung der Forschung in allen wissenschaftlichen Bereichen ( Biomedical Research Integrated Domain Group Model - siehe Kapitel cancer Biomedical Informatics Grid - siehe Kapitel Clinical Data Acquisition Standards Harmonization - siehe Kapitel Clinical Data Interchange Standards Consortium Das CDISC entwickelt offene Standards für den Austausch von Daten im Bereich der klinischen Forschung ( Prior and Concomitant Medications (dt.: Erfassung von früherer und Begleitmedikationen) Mit CM wird in dieser Arbeit die CDASH Domänentabelle Prior and Concomitant Medications referenziert. Clinical Information Modeling Initiative Im Rahmen der CIMI arbeiten verschiedene Organisationen (unter anderem CDISC, HL7 und die openehr-foundation) auf internationaler Ebene zusammen, um die Interoperabilität im Gesundheitswesen zu verbessern. Case Report Form (dt.: Datenerhebungsbogen) Papierbasiertes Formular zur Dokumentation von Beobachtungen in klinischen Studien. conformable Thoracic Stent Grafts Studienname: Details siehe Kapitel 3.2. Deutsches Register Klinischer Studien Das DRKS ermöglicht die Registrierung und Recherche von in Deutschland durchgeführten klinischen Studien (

16 XVI EAV ecrf EGA EMA EPA FDA GCP HIMSS Entity-Value-Attribute Das EAV-Modell ist ein Datenmodell, bei welchem aus Datenbanksicht alle Merkmale in einer einzigen Tabelle abgelegt werden. Dabei werden in jeder Zeile dieser Tabelle die Bezeichnung der Merkmalsart und die zugehörige Merkmalsausprägung gespeichert. electronic Case Report Form Elektronischer CRF siehe CRF. Elektronische Gesundheitsakte Eine EGA soll verteilt bei Leistungserbringern und Patienten anfallende klinische und gesundheitsbezogene Daten eines Menschen zusammenfassen und diese omnipräsent, lebenslang, unabhängig von Ort und Zeit allen am Behandlungsprozess Beteiligten (inkl. der Patienten!) bedarfsgerecht präsentieren. ([WARDA 2006], S. 374). European Medicines Agency (dt.: Europäische Arzneimittelagentur) Die EMA ist zuständig für die Zulassung und Überwachung von Arzneimitteln in der Europäischen Union ( Elektronische Patientenakte Eine EPA ist die computerbasierte Variante einer Patientenakte. Food and Drug Administration Die FDA ist die für die Überwachung von Lebensmitteln und die Zulassung von Arzneimitteln zuständige Behörde in den Vereinigten Staaten von Amerika ( Good Clinical Practice GCP bezeichnet international anerkannte, nach ethischen und wissenschaftlichen Gesichtspunkten aufgestellte Regeln für die Durchführung klinischer Studien. Healthcare Information and Management Systems Society (dt.: Gesellschaft für Gesundheitsinformations- und Managementsysteme) Die HIMSS ist eine gemeinnützige Organisation, die darauf ausgerichtet ist, die Gesundheitsversorgung durch den sinnvollen Einsatz von Informationstechnologie- und Managementsystemen zu verbessern ( HL7 Health Level 7 Der speziell für das Gesundheitswesen entwickelte internationale Kommunikationsstandard HL7 ermöglicht die Kommunikation und Kooperation zwischen nahezu allen Institutionen und Bereichen des Gesundheitswesens ([NORGALL 2009]) ( HL7 RCRIM TC HL7 RIM HL7 Regulated Clinical Research Information Management Technical Committee Ziel des Komitees ist die Entwicklung von Standards, um das Informationsmanagement in der klinischen Forschung zu verbessern. HL7 Reference Information Model Das HL7 RIM ist ein Referenz-Informationsmodell, welches das Gesundheitswesen in seiner gesamten Breite abzudecken versucht und den Grundstein des HL7 Ansatzes in der Version 3 bildet.

17 XVII HTML i2b2 ICD ICH ICTRP IHE ISO KIS KKS Hypertext Markup Language (dt.: Hypertext-Auszeichnungssprache) Die HTML ist eine Auszeichnungssprache zur Definition von Dokumenten, welche von Web-Browsern dargestellt werden können. Informatics for Integrating Biology and Bedside - siehe Kapitel International Statistical Classification of Diseases and Related Health Problems (dt.: Internationale statistische Klassifikation der Krankheiten und verwandter Gesundheitsprobleme) Die ICD ist ein von der Weltgesundheitsorganisation herausgegebenes Klassifikationssystem für Diagnosen. In Deutschland wird aktuell die Version ICD-10-GM Version 2010 eingesetzt. International Conference on Harmonisation of Technical Requirements for Registration of Pharmaceuticals for Human Use Die ICH strebt die Harmonisierung von Kriterien zur Beurteilung von Arzneimitteln im Rahmen von Arzneimittelzulassungen in Europa, den USA und Japan an. International Clinical Trials Registry Platform Die ICTRP ermöglicht die Registrierung und Recherche von klinischen Studien auf internationaler Ebene ( Integrating the Healthcare Enterprise Im Rahmen von IHE arbeiten Anwender und Hersteller gemeinsam an der Harmonisierung des Datenaustauschs zwischen computergestützten Systemen im Gesundheitswesen ( International Organization for Standardization (dt.: Internationale Organisation für Normung) Die ISO erarbeitet als internationale Vereinigung von Normungsorganisationen Normen in zahlreichen Bereichen, mit dem Ziel dass diese von den einzelnen Mitgliedsorganisationen unverändert übernommen werden ( Krankenhausinformationssystem Ein Krankenhausinformationssystem ist das Informationssystem der Einrichtung Krankenhaus ([AMMENWERTH und HAUX 2005], S. 8). Ein Informationssystem kann sich sowohl aus rechnerunterstützten als auch aus konventionellen Subinformationssystemen zusammensetzen. Ein typisches rechnerunterstütztes Subsystem eines KIS ist die EPA. Koordinierungszentrum für Klinische Studien Die KKS sind Einrichtungen, deren Aufbau vom Bundesministerium für Bildung und Forschung (BMBF) gefördert wurden. Ziel war es, an Universitätsklinika die personellen und logistischen Ressourcen zur Verfügung zu stellen, um Planung, Durchführung und Auswertung von klinischen Studien nach international anerkannten Qualitätsstandards zu unterstützen.

18 XVIII NCI ODM openehr Opereffa opensdms RDE RFD SAE SDMS SDTM SOA TMF National Cancer Institute Das NCI ist das Krebsforschungszentrum in den Vereinigten Staaten von Amerika, welches zu den staatlichen National Institutes of Health gehört ( Operational Data Model - siehe Kapitel open Electronic Health Record - siehe Kapitel openehr Reference Framework and Application - siehe Kapitel open Study Data Management System Im Rahmen dieser Arbeit entwickeltes integriertes System, das die Nutzung von Einträgen in Patientenakten in klinischen Studien erlaubt (siehe Kapitel 4.2). Remote Date Entry RDE bezeichnet die Erfassung von Daten mit elektronischen Formularen an verschiedenen Orten bei gleichzeitig zentraler Speicherung. Retrieve Form for Data-capture - siehe Kapitel Serious Adverse Event (dt.: Schwerwiegendes unerwünschtes Ereignis SUE) Ein SAE ist ein schwerwiegendes Ereignis (wie Tod oder Hospitalisation), das im Rahmen einer klinischen Studie mit Arzneimitteln bei einem Probanden auftritt. Studiendatenmanagementsystem Ein SDMS dient dazu, medizinische und demographische Daten im Rahmen klinischer Studien zu erfassen und zu speichern. Aktuelle Systeme sind häufig als RDE-Systeme realisiert. Study Data Tabulation Model Das SDTM ist ein CDISC Standard, welcher die Struktur von Tabellen, zur Repräsentation von Studiendaten beschreibt. Das SDTM ist gedacht zur Auswertung und Einreichung von Studiendaten bei Zulassungsbehörden. Serviceorientierte Architektur SOA ist eine Architektur zur Nutzung von Funktionalitäten in verteilten Systemen. TMF Technologie- und Methodenplattform für die vernetzte medizinische Forschung e. V. Als Dachorganisation medizinischer Forschungsverbünde versucht die TMF durch gezielte Projekte und Dienstleistungen, die organisatorische, rechtliche und technologische Infrastruktur der medizinischen Forschung in Deutschland zu verbessern ( Hinweis: Im Kontext klinischer Studien steht die Abkürzung auch für Trial Master File.

19 XIX UML VPN WHO XML XSLT Unified Modeling Language Die UML ist eine graphische Modellierungssprache zur Spezifikation und Dokumentation von (Anwendungs)systemen und Prozessen. Virtuelles Privates Netzwerk VPN erlauben die (geschützte) Verknüpfung von mehreren privaten Netzen bzw. Arbeitsstationen über öffentliche Netze. World Health Organization (dt.: Weltgesundheitsorganisation) Die WHO ist eine Sonderorganisation der Vereinten Nationen, deren verfassungsmäßiger Zweck es ist, allen Völkern zur Erreichung des bestmöglichen Gesundheitszustandes zu verhelfen ( Extensible Markup Language XML ist eine Auszeichnungssprache, welche es erlaubt, Textdaten hierarchisch strukturierter darzustellen. Extensible Stylesheet Language Transformation XSLT ist eine Sprache zur Beschreibung von Transformationsregeln für XML-Dokumente.

20 XX

21 Einleitung 1 1 Einleitung 1.1 Gegenstand und Motivation Hintergrund In scientia salus Heilung durch Wissenschaft. Diesen Wahlspruch ließ der bedeutende Chirurg, Strahlentherapeut und Krebsforscher Vincenz Czerny vor über 100 Jahren am Samariterhaus in Heidelberg anbringen (nach [TUFFS und PIETZSCH 2008]). Bis heute hat dieser Spruch nichts an Aktualität verloren. Im Gegenteil: Mit neuen Methoden in den Naturwissenschaften eröffnen sich auch der medizinischen Forschung und Versorgung immer neue Möglichkeiten. Klinische Studien sind dabei ein zentrales Element, um die Wirksamkeit oder Überlegenheit von Medikamenten und anderen therapeutischen Interventionen zu erforschen und zu evaluieren (vgl. [GAWLIK, ABHOLZ et al. 1998]). Hierzu werden Daten unter definierten Bedingungen erhoben und ausgewertet. Ebenso wie in anderen Bereichen werden im Gesundheitswesen immer mehr Daten elektronisch übermittelt, verarbeitet und gespeichert (vgl. [DORDA, GALL et al. 2002]) auch über Einrichtungsgrenzen hinweg (vgl. [HAAS 2006], S. 2 und [KRÜGER-BRAND 2007]). Dabei entsteht eine heterogene Menge von Datensammlungen an unterschiedlichen Orten. Diese verstärkte Verfügbarkeit von Informations- und Kommunikationstechnologien im Gesundheitswesen führt zu Schlagworten wie E-Health und Gesundheitstelematik (siehe Kapitel 2.1). Problematik In klinischen Studien ist es jedoch nach wie vor aufwändig und teuer, größere Mengen phänotypischer Daten in ausreichend guter Qualität zu erheben (vgl. [KOHANE und ALTMAN 2005] und [SAX 2008]). Eine hohe Qualität in der Forschung erfordert qualitativ hochwertige Daten und Prozesse zur Datenerhebung gemäß den Good Clinical Practices (GCP siehe [ICH 2002]). Obwohl in Routineversorgung wie auch in klinischen Studien vielfach Daten elektronisch verarbeitet werden, ist eine wechselseitige Nutzung bereits vorhandener Daten häufig nicht möglich. In beiden Welten haben sich unterschiedliche Standards etabliert. Meist stehen die HL7- und DICOM-Standards in der Versorgung den CDISC-Standards im Studienumfeld gegenüber (vgl. [OHMANN und KUCHINKE 2009]) und selbst die Interoperabilität zwischen verschiedenen Systemen eines Bereichs erweist sich häufig als schwierig. So muss ein Prüfarzt mitunter eine Medikamentenverordnung, welche er bereits im Rahmen der Routineversorgung in der elektronischen Patientenakte (EPA) eines Studienteilnehmers dokumentiert hat, in einem electronischen Case Report Forms (ecrf) für die jeweilige Studie erneut erfassen. Aber nicht nur zwischen Versorgung und Forschung, sondern auch innerhalb der Forschung sind Systeme oft noch nicht interoperabel. Tritt bei dem Studienteilnehmer etwa ein schwerwiegendes unerwünschtes Ereignis (SAE) auf, müssen die verordneten Medikamente gegebenenfalls im eingesetzten SAE-Managementsystem ein drittes Mal erfasst werden. Verschiedene Bemühungen, um Routinedaten aus Krankenhausinformationssystemen (KIS) und Studiendaten aus Studiendatenmanagementsystemen (SDMS) zu verknüpfen, konzentrieren sich meist auf ein konkretes KIS/SDMS-Szenario (so zum Beispiel [KATZER, RÖHRIG et al. 2006]). Gerade für multizentrische Studien, welche eine Datenerhebung in verschiedenen Häusern mit oft unterschiedlichen KIS erfordern, wäre jedoch eine weiterreichende Interoperabilität wünschenswert. Aufwand Mangelnde Interoperabilität

22 2 Multiple Verwendung von Patientendaten unter Nutzung von Archetypen Datenschutz Datenqualität Problem 1 Problem 2 Um den einzelnen Bürger zu schützen, schränken in Deutschland Gesetze und Vorschriften die multiple Verwendung von Gesundheitsdaten zum Teil ein (vgl. etwa SGB V, 291a Nr. 8). Wenn ein Datenaustausch zwischen Forschung und Versorgung ermöglicht werden soll, muss sorgfältig geprüft werden, ob der jeweils gewählte Ansatz mit dem Datenschutz vereinbar ist. Um bei der multiplen Nutzung von Patientendaten die Anforderungen des Datenschutzes zu erfüllen, müssen gegebenenfalls zusätzliche technische und organisatorische Maßnahmen getroffen werden. Darüber hinaus ist eine multiple Verwendung von Daten aus der Versorgung in der Forschung nur möglich, wenn sichergestellt ist, dass die Qualität der Daten für die Sekundärnutzung ausreichend hoch ist. Gerade klinische Studien stellen häufig hohe regulatorische Anforderungen an die Qualität und Nachvollziehbarkeit der erhobenen Daten. Motivation Die in Forschung und Versorgung vorhandenen Datensammlungen können auch für den jeweils anderen Bereich einen wichtigen Informationsschatz darstellen. Wären vorhandene Daten multipel und damit effizient nutzbar, könnten Prozesse in Forschung und Versorgung vereinfacht und Kosten eingespart werden. So kann beispielsweise bereits die Rekrutierung von Studienteilnehmern mit Hilfe der Daten aus Krankenhausinformationssystemen unterstützt werden (vgl. [DUGAS, LANGE et al. 2010]). Indem dieselben Daten nicht mehrfach erfasst werden müssen, können ferner Übertragungsfehler vermieden werden. In diesem Sinne muss angestrebt werden, Routinedaten aus der Versorgung und Studiendaten gemeinsam zu erheben bzw. soweit möglich wechselseitig zu nutzen (vgl. [WINTER, FUNKAT et al. 2007], [EMBI und PAYNE 2009], [PROKOSCH und GANSLANDT 2009], [OHMANN und KUCHINKE 2009] sowie [BREIL, SEMJONOW et al. 2011]). Dies ist besonders interessant vor dem Hintergrund einer Offenheit für persönliche, elektronische Gesundheitsakten in der Bevölkerung (vgl. [HOERBST, KOHL et al. 2009]) auch wenn entsprechende Akten aktuell noch nicht verbreitet genutzt werden (siehe [ÄRZTE ZEITUNG 2011] und [INTERCOMPONENTWARE AG (ICW) 2011]). Auf Archetypen basierende klinische Informationssysteme (siehe Kapitel 2.5) versprechen eine nachhaltige Interoperabilität, weil diese Systeme große Flexibilität bieten und einfach an geänderte Rahmenbedingungen angepasst werden können. Da diese Informationssysteme gleichzeitig semantische Interoperabilität (siehe Kapitel 2.4) ermöglichen, könnte sich dieser Ansatz gut für die Verknüpfung von Systemen aus Forschung und Versorgung eignen. 1.2 Problemstellung Archetypen wurden bisher fast ausschließlich zur Dokumentation in der Versorgung eingesetzt (zum Beispiel [HAGGLUND, CHEN et al. 2010], [AUSTIN, LIM et al. 2011] oder [XIAO, COUSINs et al. 2011]). Auch wenn bereits in [GARDE, KNAUP et al. 2005] vorgeschlagen wurde, Archetypen zur Dokumentation von Forschungsdaten zu nutzen, wurde noch nicht systematisch und detailliert untersucht, ob sich Archetypen zur Repräsentation von Forschungsdaten eigenen. Daher ist zurzeit noch unklar, ob auf Archetypen basierende Systeme geeignet sind, Daten für Forschung und Versorgung zu integrieren. Entsprechend gibt es bisher auch keine Referenzarchitektur für auf Archetypen basierende Systeme, die eine Übernahme von Daten aus Krankenhausinformationssystemen in Studiendatenmanagementsysteme unterstützen.

23 Einleitung Zielsetzung Übergeordnetes Ziel dieser Arbeit ist es, basierend auf den openehr-spezifikationen und -Archetypen (siehe Kapitel 2.6) Ansätze zu erarbeiten und zu bewerten, die einen Übergang von der multiplen Erfassung zur multiplen Verwendung von Daten in Forschung und Versorgung ermöglichen. Konkret soll eine auf Archetypen basierende Referenzarchitektur entworfen werden als generische Lösung zur Integration von Forschungs- und Versorgungsdaten. Im Gegensatz zu bestehenden Ansätzen, soll diese Architektur speziell die Integration verschiedener, heterogener KIS unterstützen. Dies ist besonders im Kontext von multizentrischen Studien von großer Bedeutung. In einem evolutionären Ansatz sollen Anforderungen an diese Referenzarchitektur (bottom-up) erhoben und eine entsprechende Architektur entworfen werden. In einem zweiten Schritt soll die Realisierbarkeit der relevanten Bausteine dieser Referenzarchitektur (top down) geprüft werden. Mit Hilfe der Referenzarchitektur soll aus informationsverarbeitender Sicht eine Brücke zwischen Versorgungs- und Studienwelt geschlagen werden. Auf Archetypen basierende Referenzarchitektur zur Integration von Forschung und Versorgung: Anforderungen Ermitteln von Anforderungen an eine auf Archetypen basierende Referenzarchitektur zur Integration von Krankenhausinformations- und Studiendatenmanagementsystemen im Rahmen eines evolutionären Analyseprozesses. Hierbei sollen vor allem folgende Fragen geklärt bzw. Aufgaben bearbeitet werden: 1. Ermitteln von generellen Anforderungen an eine Referenzarchitektur zur Integration von Forschung und Versorgung durch eine Fallstudie. 2. Ermitteln weiterer Anforderungen durch eine prototypische Implementierung eines auf Archetypen basierenden Systems zur Integration von Forschungs- und Versorgungsdaten. Ziel 1 Auf Archetypen basierende Referenzarchitektur zur Integration von Forschung und Versorgung: Spezifikation Ausgehend von den zu Ziel 1 gesammelten Anforderungen und Erfahrungen soll eine auf Archetypen basierende Referenzarchitektur zur Integration von Forschung und Versorgung spezifiziert werden. Dazu werden vor allem folgende Fragen beantwortet: 3. Wie müsste eine auf Archetypen basierende Referenzarchitektur beschaffen sein, die es ermöglicht, Daten aus Krankenhausinformations- und Studiendatenmanagementsystemen multipel zu nutzen? 4. Wie müsste vorgegangen werden, um entsprechend dieser Architektur Daten aus Forschung und Versorgung multipel nutzen zu können? (Vorgehensmodell) Ziel 2 Auf Archetypen basierende Referenzarchitektur zur Integration von Forschung und Versorgung: Realisierbarkeit Überprüfen der Realisierbarkeit der zentralen Komponenten der vorgeschlagenen, auf Archetypen basierenden Referenzarchitektur. Dabei soll insbesondere geprüft werden, ob sich Archetypen nicht nur zur Repräsentation von Daten aus der Versorgung sondern auch für Studiendaten eignen. Hierzu sollen für die Referenzarchitektur benötigte Archetypen spezifiziert bzw. falls notwendig neu entwickelt werden. Darüber hinaus soll geprüft werden, ob die entsprechenden Archetypen mit etablierten Standards und Modellen aus der Ziel 3

24 4 Multiple Verwendung von Patientendaten unter Nutzung von Archetypen klinischen Forschung harmonieren bzw. sich gemäß dieser entwickeln lassen. Es werden vor allem folgende Fragen beantwortet und Aufgaben gelöst: 5. Identifizieren und Entwickeln von benötigten Archetypen, um die vorgeschlagene Referenzarchitektur umsetzen zu können. 6. Prüfen, ob sich die auf Archetypen basierenden Repräsentationen der einzelnen Datenarten auf etablierte klinische Daten- und Informationsmodelle im Forschungsumfeld abbilden bzw. (falls entsprechende Archetypen noch nicht vorhanden sind) aus diesen ableiten lassen: Studien-Metadaten: BRIDG-Modell (siehe Kapitel 2.7). Studiendaten (medizinische Daten): Clinical Data Acquisition Standards Harmonization (siehe Kapitel 2.7). Verknüpfung der auf Archetypen basierenden Repräsentation von Studiendaten und Studien-Metadaten mit dem Operational Data Model (siehe Kapitel 2.7).

25 Grundlagen 5 2 Grundlagen 2.1 Begriffsdefinitionen Im Folgenden werden für diese Arbeit wesentliche Begriffe und die hierfür verwendeten Bezeichnungen erläutert. Gesundheitstelematik Gesundheitstelematik als Kunstwort aus Gesundheitswesen, Telekommunikation und Informatik umfasst alle einrichtungsübergreifenden und ortsunabhängigen Anwendungen der Informations- und Kommunikationstechnologie im Gesundheitswesen zur Überbrückung von Raum und Zeit ([HAAS 2006], S. 6). Der Begriff Telemedizin wurde früher synonym verwendet, bezeichnet jedoch mittlerweile nur noch bestimmte Teilaspekte der Gesundheitstelematik beispielsweise Teleradiologie, Telepathologie, Telechirurgie oder Telemonitoring (vgl. [HAAS 2006], S. 6). E-Health E-Health ist ein modernes Schlagwort, welches schwer zu definieren ist, da es unterschiedlich verwendet wird (vgl. [EYSENBACH 2001]). Die HIMSS (Healthcare Information and Management Systems Society) beschreibt E-Health als The application of Internet and other related technologies... to improve the access, efficiency, effectiveness, and quality of clinical and business processes utilized by healthcare organizations, practitioners, patients, and consumers to improve the health status of patients ([HIMSS 2003], S 1). In dieser Arbeit wird E-Health als Synonym zum Begriff Gesundheitstelematik verstanden. Konzept Konzept wird in dieser Arbeit als Synonym zu Objekttyp, Begriff, Idee, und Klasse (im Sinne der objektorientierten Programmierung) verwendet. E. Ammenwerth definiert in ([AMMENWERTH und HAUX 2005], S. 10) Objekttyp wie folgt: Ein Objekt stellt einen Ausschnitt aus der wahrnehmbaren oder vorstellbaren Welt dar. Jedes einzelne Objekt weist eine Menge von Eigenschaften (Attribute) auf. Durch die Ermittlung gemeinsamer Eigenschaften lässt sich mittels Abstraktion eine Menge gleichartiger Objekte zu einer Denkeinheit zusammenfassen, die als Objekttyp (oder Klasse) bezeichnet wird.... Zu einem (gedachten) Konzept bzw. Objekttyp können (reale) Instanzen bzw. Objekte existieren. Sowohl ein Konzept selbst als auch seine Instanzen verfügen dabei über dieselben kennzeichnenden Eigenschaften. Zusätzlich verfügt ein Konzept über spezifische Merkmalsarten, welche bei verschiedenen Instanzen unterschiedlich ausgeprägt sein können. So können verschiedene Instanzen desselben Konzepts unterschieden werden. Die folgenden Beispiele sollen dies veranschaulichen. Jemand, der das Konzept Auto kennt, hat eine allgemeine Vorstellung davon, was ein Auto ist, bzw. welche Eigenschaften ein Auto kennzeichnen (hat vier Räder, fährt auf der Straße, dient der Beförderung von Menschen oder Gütern). Somit kann dieser Mensch auch ein Auto, welches er noch nie zuvor gesehen hat, als Auto erkennen und benennen. Dabei sind der Sportwagen, welcher vor dem Haus gegenüber steht und der Geländewagen, welcher gerade vorbeifährt, verschiedene reale Instanzen des gedachten Konzepts Auto. Merkmalsarten, über die alle Autos verfügen sind zum Beispiel Farbe, Höchstgeschwindigkeit oder Motorleistung. Je nach konkreter Instanz können diese unterschiedlich ausgeprägt sein der Sportwagen gegenüber ist blau, der Geländewagen rot. Ein Konzept aus dem Bereich der Medizin ist der Blutdruck. Konkrete Instanzen wären der Blutdruck von Liz Miller oder Erika Gabler. Definition Konzept und Instanz

26 6 Multiple Verwendung von Patientendaten unter Nutzung von Archetypen 2.2 Klinische Studien In klinischen Studien soll die Unbedenklichkeit, Wirksamkeit oder Überlegenheit von Medikamenten, medizinischen Geräten oder anderen Interventionen nachgewiesen werden. Klinische Studien sind eine wichtige Voraussetzung, um für einen Patienten die optimale Therapie auszuwählen und die Gabe unwirksamer oder schädlicher Substanzen zu vermeiden. So verbessern Studien nicht nur die Behandlung des einzelnen Patienten, sondern können auch Kosten im Gesundheitswesen senken. Aufgrund ihrer großen Bedeutung insbesondere bei der Zulassung neuer Medikamente gibt es umfangreiche und strenge Regularien für die Durchführung solcher Studien, zum Beispiel. die Verordnung über die Anwendung der Guten Klinischen Praxis bei der Durchführung von klinischen Prüfungen mit Arzneimitteln zur Anwendung am Menschen (GCP-Verordnung). Diese Regularien stellen hohe Ansprüche an Datenqualität und Nachvollziehbarkeit der gewonnenen Ergebnisse. Durch entsprechendes Datenmanagement und Monitoring (siehe unten) wird versucht, diese Datenqualität zu gewährleisten. Darüber hinaus muss eine klinische Studie systematisch geplant werden. Der Studienablauf muss detailliert im Prüfplan a priori festgelegt werden. Auch die Ein- und Ausschlusskriterien für potenzielle Probanden werden im Prüfplan definiert. An der Erstellung und Umsetzung eines Prüfplans sind verschiedene Fachbereiche beteiligt, welche im Rahmen von klinischen Studien interdisziplinär zusammenarbeiten. Im Folgenden werden einzelne Bereiche kurz beschrieben. Biometrie Bereits bei der Planung ist die Biometrie von großer Bedeutung für die Qualität einer Studie. Typischerweise plant die Biometrie Studiendesign, Fallzahl, Randomisierungsverfahren, primäre und sekundäre Endpunkte und Auswertungsstrategie. Nachdem die benötigten Daten erhoben wurden, übernimmt die Biometrie die statistische Analyse und Auswertung (nach [LUNTZ, GORBAUCH et al. 2009]). Datenmanagement Die Integrität der Daten ist ein weiterer wichtiger Aspekt. Vor Beginn der Datenerhebung erstellt das Datenmanagement eine Studiendatenbank gemäß Datenmanagementplan. Sobald die Erhebung abgeschlossen ist, wird die Datenbank geschlossen und auf Inkonsistenzen sowie fehlende Werte geprüft. Werden Fehler erkannt, versucht das Datenmanagement diese durch Rückfragen (sogenannte Queries ) an die datenerhebenden Stellen zu klären und zu beseitigen (nach [LUNTZ, GORBAUCH et al. 2009]). Monitoring Das Monitoring ist ein wichtiges Instrument, um die (Daten)qualität in klinischen Studien zu gewährleisten. Das Monitoring überwacht, dass Prüfpläne, Gesetze und Standards wie etwa die Good Clinical Practice in den Prüfzentren eingehalten werden. Hierzu weisen Monitore die Mitarbeiter vor Ort in die Prüfpläne ein, zeigen strukturelle und organisatorische Fehler auf und vergleichen die für eine Studie erfassten Daten mit den sogenannten Quelldaten in den Patientenakten. Entdecken die Monitore beim Überprüfen der Studiendaten Lücken oder Inkonsistenzen stellen auch sie entsprechende Queries (nach [LUNTZ, GORBAUCH et al. 2009]). Studienassistenz Studienassistenten unterstützen die Prüfärzte vor Ort im Studienzentrum bei der Durchführung der Studien. Sie helfen, geeignete Patienten zu finden, unterstützen bei der Organisation und Durchführung der Studienvisiten (=Treffen zwischen Studienpersonal und Proband) oder dokumentieren Studiendaten. Oft sind sie nicht nur Ansprechpartner für Patienten und Ärzte, sondern insbesondere auch für die Monitore (nach [LUNTZ, GORBAUCH et al. 2009]).

27 Grundlagen 7 Pharmakovigilanz Die Pharmakovigilanz trägt dafür Sorge, dass die Anforderungen und Gesetze zur Arzneimittelsicherheit in klinischen Prüfungen beachtet werden. Die Pharmakovigilanz umfasst neben der kontinuierlichen Sicherheitsüberwachung einer klinischen Prüfung hauptsächlich Bewertungs- und Meldeprozesse für sogenannte Serious Adverse Events und jährliche Sicherheitsberichte (nach [LUNTZ, GORBAUCH et al. 2009]). Projektmanagement, Qualitätsmanagement und IT Neben den genannten Bereichen gibt es noch weitere Fachbereiche, die im Rahmen von klinischen Prüfungen zusammenarbeiten. So zum Beispiel das Projektmanagement (logistische Planung und Koordination), das Qualitätsmanagement (Review und Verwaltung der Standard Operating Procedures einer Einrichtung) oder die Informationstechnologie (Bereitstellen validierter Systeme zur Verarbeitung von Studiendaten) (nach [LUNTZ, GORBAUCH et al. 2009]). 2.3 Klassifikation von Daten Wenn in dieser Arbeit von der multiplen Verwendung von Daten in Forschung und Versorgung gesprochen wird, werden unter der allgemeinen Bezeichnung Daten in der Regel verschiedene Arten von Daten zusammengefasst, die primär unterschiedlichen Zwecken dienen. Nachfolgend werden unterschiedliche Datenarten benannt und voneinander abgegrenzt. Routinedaten Unter Routinedaten werden in dieser Arbeit alle Daten verstanden, die im Rahmen der regulären ambulanten und stationären Patientenversorgung erhoben und typischerweise in einer Patientenakte dokumentiert werden. Diese Daten beschreiben den Gesundheitszustand eines Patienten sowie durchgeführte Interventionen. Hinzu kommen administrative Daten (=Patientenstammdaten) wie der, Geburtsdatum oder Versicherungsnummer des Patienten. Versorgungsdaten Unter Versorgungsdaten wird in der Regel die Teilmenge der Routinedaten verstanden, welche die Häufigkeit und Wirksamkeit bzw. Qualität der durchgeführten Maßnahmen beschreibt. So gehören beispielsweise die Liegedauer eines stationären Patienten oder die Dokumentation der durchgeführten Maßnahmen zu den Versorgungsdaten. Studiendaten Unter Studiendaten werden in dieser Arbeit alle Daten verstanden, die im Rahmen von klinischen Studien erhoben und dokumentiert werden, um den Gesundheitszustand eines Patienten, durchgeführte Interventionen bzw. die Wirkung einer Intervention (beispielsweise eines verabreichten Medikaments) zu beschreiben. An Studiendaten werden meist hohe Qualitätsanforderungen gestellt. Durch adäquates Datenmanagement und Monitoring (siehe Kapitel 2.2) wird versucht diesen Anforderungen gerecht zu werden. Studien-Metadaten Unter Metadaten ( Daten über Daten ) versteht man strukturierte Daten, mit deren Hilfe eine Informationsressource beschrieben und dadurch besser auffindbar gemacht wird ([STAATS- UND UNIVERSITÄTSBIBLIOTHEK GÖTTINGEN 2001]). Studien-Metadaten beschreiben neben den zu erhebenden Merkmalen auch Rahmen, Design und involvierte Forscher einer klinischen Prüfung. Dies ist erforderlich, um die erhobenen Daten nachhaltig nutzen zu können (vgl. [ZPID 2010]). Studien-Metadaten sind beispielsweise notwendig, um studienübergreifende Auswertungen durchführen zu können. So kann etwa aus den Ein- und Ausschlusskriterien verschiedener Studien abgeleitet werden, ob die eingeschlossenen Patientenkollektive im Sinne einer bestimmten Fragestellung vergleichbar sind. Teilweise

28 8 Multiple Verwendung von Patientendaten unter Nutzung von Archetypen wird unter Studien-Metadaten im engeren Sinne auch nur die Definition der in der Studie zu erhebenden Merkmalsarten und deren Formate verstanden. Primärdaten Primärdaten sind Daten, die im Rahmen ihres originär vorgesehenen Verwendungszwecks aufbereitet und analysiert werden ([Arbeitsgruppe Erhebung und Nutzung von Sekundärdaten der DGSMP und Arbeitsgruppe Epidemiologische Methoden der DGEpi der GMDS und der DGSMP 2008], S. 12). Sekundärdaten Sekundärdaten sind Daten, die einer Auswertung über ihren originären, vorrangigen Verwendungszweck hinaus zugeführt werden. Maßgeblich für die Einstufung als Sekundärdaten sind Unterschiede zwischen dem primären Erhebungsanlass und der nachfolgenden Nutzung. Für die Einstufung ist es unerheblich, ob die weitergehende Nutzung durch den Dateneigner selbst oder durch Dritte erfolgt ([Arbeitsgruppe Erhebung und Nutzung von Sekundärdaten der DGSMP und Arbeitsgruppe Epidemiologische Methoden der DGEpi der GMDS und der DGSMP 2008], S. 12). Syntaktische Interoperabilität 2.4 Semantische und syntaktische Interoperabilität Damit Daten multipel für Forschung und Versorgung genutzt werden können, müssen die jeweils eingesetzten Systeme interoperabel sein. Dabei können verschiedene Ebenen von Interoperabilität unterschieden werden. Zwei oder mehr Computersysteme sind syntaktisch interoperabel, wenn sie die Fähigkeit besitzen, Nachrichten auszutauschen: Alle beteiligten Systeme müssen über kompatible Schnittstellen und Protokolle bzw. Standards zum Datenaustausch verfügen. Syntaktische Interoperabilität impliziert jedoch nicht, dass Sender und Empfänger einer Nachricht die ausgetauschten Daten in jedem Fall gleich interpretieren. Syntaktische Interoperabilität ist dennoch die Grundlage für jede weitere Form von Interoperabilität. Das folgende Beispiel verdeutlicht die Grenzen von syntaktischer Interoperabilität. Im Rahmen einer Studie sollte unter anderem der Blutzuckerwert der Probanden ermittelt werden. Die ermittelten Werte sollten dabei zunächst auf einem Server in Europa gespeichert werden. Zur Auswertung sollten die Werte in einer verschlüsselten Textdatei an einen Server in den USA geschickt werden. Beim Testen des Systems zeigte sich, dass die Werte auf dem Server in Europa in mmol/l gespeichert wurden, der Server in den USA jedoch die Werte in der Einheit mg/dl erwartete. Im Studienprotokoll war nicht angegeben worden, welche Einheit verwendet worden war (nach [IBERSON-HURST 2004]). Haben Sender und Empfänger einer Nachricht ein unterschiedliches Verständnis einer Größe bzw. allgemeiner eines Konzepts, birgt dies die Gefahr, dass beide alle Nachrichten, welche dieses Konzept nutzen, unterschiedlich interpretieren insbesondere wenn es sich um einen automatisierten Austausch von Daten zwischen zwei Computersystemen handelt. Nach [WALKER, PAN et al. 2005] sind ab einer bestimmten Stufe von Interoperabilität Schnittstellen erforderlich, welche in der Lage sind, empfangene Nachrichten aus dem Vokabular der sendenden ins Vokabular der empfangenden Organisation zu übersetzen. Im Allgemeinen führt dies häufig zu unvollständigen Übersetzungen, da die genutzten Vokabulare aufgrund unterschiedlicher Detaillierungsgrade oft nicht kompatibel sind. Ein Beispiel aus dem menschlichen Sprachgebrauch soll verdeutlichen, dass selbst identische Bezeichnungen in verschiedenen Vokabularen zur Bezeichnung unterschiedlicher Begriffe benutzt werden können. Während im allgemeinen deutschen Sprachgebrauch der Fuß den untersten Teil des Beins eines Menschen bezeichnet, wird im süddeutschen Raum die Bezeichnung Fuß als Synonym und anstelle von Bein gebraucht. Wenn ein Patient aus Süddeutschland also seinem Orthopäden berichtet, er habe Schmerzen im Fuß, muss der Arzt diese Information in das übliche medizinische Vokabular übertragen (= Fuß als

29 Grundlagen 9 Bein interpretieren). Der Orthopäde muss sich im Klaren sein, dass die Schmerzen also von den Zehen bis zur Hüfte lokalisiert sein können. Semantische Interoperabilität bedeutet, dass zwischen verschiedenen Systemen Daten ausgetauscht und unmittelbar verarbeitet werden können ohne diese Nachrichten übersetzen oder anpassen zu müssen. Es ist sichergestellt, dass Sender und Empfänger einer Nachricht die ausgetauschten Daten in gleicher Weise interpretieren. Dies kann beispielsweise dadurch erreicht werden, dass zwei oder mehr Systeme generell dieselbe Definition für verwendete Konzepte benutzen. Von der technischen semantischen Interoperabilität, die sich auf die Interoperabilität zwischen Computersystemen bezieht, kann die menschliche semantische Interoperabilität unterschieden werden. Ist letztere im Dialog zwischen verschiedenen Menschen nicht gegeben, reden die Betroffenen sprichwörtlich aneinander vorbei. Dieser Arbeit beschäftigt sich hauptsächlich mit der technischen semantischen Interoperabilität. Semantische Interoperabilität 2.5 Zwei-Ebenen-Modell zur Repräsentation von Gesundheitsdaten In dieser Arbeit werden die Einsatzmöglichkeiten und möglichen Vorteile von Archetypen bei der multiplen Verwendung von Daten in Forschung und Versorgung untersucht. Nachfolgend wird daher das Konzept des Zwei-Ebenen-Modells ([BEALE, HEARD et al. 2006], [MICHELSEN, PEDERSEN et al. 2005]) zur Repräsentation von Gesundheitsdaten vorgestellt. Archetypen bilden eine Ebene dieses Modells. Dabei wird ein Schwerpunkt auf die openehr-spezifikationen gelegt, die ein solches Zwei-Ebenen-Modell sehr detailliert vorgeben. Ebene 1: Archetypen Die Bezeichnung Archetyp setzt sich zusammen aus den griechischen Wörtern ἀρχή (Beginn, Anfang) und τύπος (Vorbild, Skizze). Allgemein bedeutet dies so viel wie Urtyp, Prototyp oder Muster (nach [WEBSTER 1971]). Dabei variiert die konkrete Bedeutung je nach Disziplin wie beispielsweise Philosophie, Psychoanalyse oder Biologie. Im Kontext von Informationssystemen im Gesundheitswesen beschreiben Archetypen medizinische Konzepte. Konkret definiert ein Archetyp hier, welche Informationen zu einem bestimmten Konzept dokumentiert werden können. Abb. 2-1 zeigt, welche Merkmalsarten sinnvollerweise zu dem Konzept Blutdruck mit Hilfe des openehr-archetyps Blood Pressure dokumentiert werden können. Die Elemente unter State geben dabei als zusätzlichen Kontext zur Interpretation der Daten an, in welchem Zustand sich der Patient befand, als die unter Data erfassten Informationen erhoben wurden. Protocol gibt ferner darüber Auskunft wie, mit welchen Methoden und Instrumenten die Informationen erhoben wurden (vgl. [LESLIE UND HEARD 2006]). Abstrakt gesehen, sind Archetypen wieder verwendbare, formale (und damit auch maschinenlesbare) Informationsmodelle der abgebildeten Konzepte: Ein Archetyp definiert, mit welchen Merkmalsarten konkrete Objekte des jeweiligen Konzepts beschrieben werden können. Darüber hinaus wird die Semantik der einzelnen Merkmalsarten sowie des modellierten Konzepts selbst beschrieben. Ziel ist es, so viele Merkmalsarten zu kombinieren, dass eine bestimmte Instanz eines Konzepts möglichst umfassend beschrieben werden kann. Aufgrund dieser Modellierungsvorgabe werden Archetypen im Englischen als maximal data sets bezeichnet (vgl. [LESLIE UND HEARD 2006] und Abb. 2-1). Auf diese Weise soll ein Archetyp für beliebige Anwendungsfälle geeignet sein. In einem konkreten Szenario werden jedoch nur die tatsächlich benötigten Merkmalsarten erhoben.

30 10 Multiple Verwendung von Patientendaten unter Nutzung von Archetypen Abb. 2-1: Merkmalsarten, welche das Konzept Blutdruck beschreiben - dargestellt als Mindmap des openehr-archetyps Blood Pressure [Quelle: letzter Zugriff: ]. Archetypen und Terminologien Archetypen und Ontologien Ein Archetyp definiert also lediglich, mit welchen Merkmalsarten undgegebenenfalls erlaubten Ausprägungen ein bestimmtes Konzept beschrieben werden kann. Der Archetyp beschreibt nicht umfassend, die Eigenschaften, die bestimmtes Konzept kennzeichnen. Um das Beispiel aus Kapitel 2.1 erneut aufzugreifen: Ein Archetyp zur Beschreibung des Konzepts Auto würde keine erschöpfenden Informationen darüber enthalten, was allen Autos gemeinsam ist (hat vier Räder, fährt auf der Straße, ), sondern lediglich die Merkmalsarten aufzählen, mit welchen man ein konkretes Auto von einem anderen unterscheiden kann (also zum Beispiel Farbe, Höchstgeschwindigkeit oder Motorleistung ). Eine Terminologie beschreibt ein Konzept an sich also die Eigenschaften, die auf alle Instanzen eines Konzepts zutreffen. Eine Terminologie könnte das Konzept systolischer Blutdruck beispielsweise beschreiben als den Druck des Blutes in einer Arterie während der systolischen Herzphase. Ein Archetyp hingegen definiert die Strukturen bzw. Merkmale, welche zu dokumentieren sind, um konkrete Instanzen der jeweiligen Konzepte zu charakterisieren und voneinander zu unterscheiden. Um einen systolischen Blutdruck zu beschreiben, wäre gemäß dem Archetyp Blutdruck (vgl. Abb. 2-1) eine Größe zu dokumentieren, deren Maßzahl zwischen 0 und 1000 liegt und in der Maßeinheit mm[hg] gemessen wird. Archetypen sind terminologieneutral. Dennoch können Terminologien an Archetypen oder einzelne Elemente eines Archetyps angebunden werden. Im Element systolischer Blutdruck des Archetyps Blutdruck könnte zur Beschreibung dieses Elements beispielsweise der vorgenannte Eintrag einer Terminologie referenziert werden. Darüber hinaus sind Archetypen unabhängig von menschlichen Sprachen. Ein englischer Archetyp könnte beispielsweise ins Deutsche übersetzt werden, ohne seine Bedeutung zu verlieren (nach [LESLIE UND HEARD 2006]). Archetypen erheben nicht den Anspruch, die Realität exakt abzubilden, sondern beschreiben, was pragmatischer Weise zu einem klinischen Konzept zu dokumentieren ist. Eine Menge von Archetypen bildet daher auch keine Ontologie des Bereichs, aus welchem die beschriebenen Konzepte stammen (vgl. [openehr 2007]). Ebene 2: Referenzmodell Archetypen zur Dokumentation medizinischer Konzepte basieren immer auf einem bestimmten Referenzmodell beispielsweise dem openehr-referenzmodell oder dem Referenzmodell nach ISO Dieses Referenzmodell definiert eine kleine Menge elementarer Informationseinheiten wie zum Beispiel Text, Größe bestehend aus Maßzahl

31 Grundlagen 11 und Maßeinheit, Uhrzeit oder Datum sowie Möglichkeiten diese zu kombinieren, beispielsweise als Liste oder in einer Baumstruktur. So existieren theoretisch unendlich viele erlaubte Kombinationen dieser elementaren Informationseinheiten. Ein Archetyp definiert die Merkmalsarten und gegebenenfalls erlaubte Ausprägungen, mit welchen konkrete Instanzen eines Konzepts beschrieben werden können, indem er Einschränkungen auf diesem Referenzmodell spezifiziert. Er legt fest, welche der möglichen Kombinationen der elementaren Informationseinheiten sinnvollerweise erlaubt sind, um ein bestimmtes Konzept zu beschreiben. Abb. 2-1 zeigt mit welchen Informationseinheiten beispielsweise das Konzept Blutdruck beschrieben werden kann. Im Kern werden hierzu die vier Größen Systolisch, Diastolisch, mittlerer arterieller Druck sowie Pulsdruck und ein Textfeld für Kommentare in einer Baumstruktur kombiniert. Auf Archetypen basierende Informationssysteme Informationssysteme, die Archetypen nutzen, müssen einerseits das zugrundeliegende Referenzmodell implementieren und andererseits in der Lage sein, Archetypen zu interpretieren. Während die technische Implementierung des Referenzmodells (Informationsebene) von System zu System beliebig variieren kann, sind die verwendeten Archetypen (Wissensebene) hiervon entkoppelt und systemübergreifend. Durch die Trennung von logischer Wissensebene (Was soll gespeichert werden? Archetypen) und physischer Informationsebene (Wie soll es gespeichert werden? Referenzmodell) wird es leichter, ein System an sich änderndes Wissen anzupassen: Eine Änderung der Implementierung ist nicht erforderlich das Referenzmodell ist statisch und ändert sich nicht; lediglich die entsprechenden Archetypen müssen adaptiert oder ergänzt werden. Benutzen zwei oder mehr Informationssysteme dieselben Archetypen, ermöglicht dies prinzipiell nicht nur syntaktische, sondern auch semantische Interoperabilität zwischen diesen Systemen. In Archetypen gekapselte Daten haben an jedem Ort bzw. in jedem System die gleiche Bedeutung. Darüber hinaus können Archetypen genutzt werden, um erfasste Daten auf Gültigkeit zu prüfen und um Abfragen auf einem Datenbestand zu spezifizieren. Verschiedene auf Archetypen basierende Informationssysteme können nur dann vollständig semantisch interoperabel sein, wenn alle beteiligten Systeme dieselben Archetypen nutzen. Dies setzt voraus, dass die verwendeten Archetypen an einem zentralen Ort verwaltet werden. Dies impliziert wiederum, dass alle Beteiligten die Modellierung der verwendeten Konzepte so akzeptieren, wie dies durch die gemeinsam genutzten Archetypen vorgegeben wird (vgl. [KOHL, GARDE et al. 2008]). Das Paradigma, Archetypen als Basis von Informationssystemen im Gesundheitswesen zu verwenden, hat sich auf europäischer und mittlerweile auch auf internationaler Ebene in der Norm ISO manifestiert. ISO regelt die standardisierte Kommunikation innerhalb und zwischen elektronischen Gesundheitsakten. Dazu spezifiziert die Norm, wie Auszüge aus elektronischen Gesundheitsakten (EGA) mittels eines Informationsmodells und zugehörigen Archetypen ausgetauscht werden sollen. Eine vollständige EGA wird im Gegensatz zu den openehr-spezifikationen nicht definiert (vgl. [SCHLOEFFEL, BEALE et al. 2006]). ISO basiert jedoch auf denselben Grundlagen wie die openehr- Spezifikationen, weswegen sich die openehr-spezifikationen auf ISO abbilden lassen. Daher werden im Folgenden primär Archetypen und Informationssysteme gemäß den openehr-spezifikationen betrachtet. 2.6 openehr Hinter openehr verbirgt sich eine Sammlung frei verfügbarer Spezifikationen zur Architektur von elektronischen Gesundheitsakten openehr ist also keine Anwendungssoftware. Dennoch wird anhand von Referenzimplementierungen geprüft, ob

32 12 Multiple Verwendung von Patientendaten unter Nutzung von Archetypen COMPOSITIONs Folders AOM / ADL Templates die erarbeiteten Spezifikationen praktikabel sind und die Grundlage für weitere Implementierungen geschaffen. Ziel ist es, semantische Interoperabilität innerhalb und zwischen elektronischen Systemen im Gesundheitswesen zu schaffen, ohne ein proprietäres, herstellerspezifisches Datenformat zu verwenden. So soll eine nahtlose und qualitativ hochwertige Gesundheitsversorgung möglich werden. Hierzu werden alle klinischen Konzepte unabhängig von konkreten Softwaresystemen, in Form von openehr-archetypen modelliert und strukturiert gespeichert. Die verschiedenen Spezifikationen resultieren aus über 15 Jahren Forschung und internationalen Entwicklungen einschließlich des Good European Health Record. OpenEHR-Architektur und -Spezifikationen sind geistiges Eigentum der openehr-foundation. Die openehr-foundation ist eine not-for-profit Gesellschaft, welche vom University College London (CHIME) und der australischen Firma Ocean Informatics gegründet wurde. Eine beständig wachsende Online-Community mit über 1000 Mitgliedern aus 75 Ländern (Stand 2007) diskutiert und unterstützt die Weiterentwicklung von openehr (nach [LESLIE 2007]). openehr-archetypen Jeder openehr-archetyp bezieht sich auf eine Klasse innerhalb des openehr- Referenzmodells. Entsprechend dieser Klassen lassen sich openehr-archetypen einteilen und benennen (etwa als COMPOSITIONSs, OBSERVATIONs oder INSTRUCTIONs). In elektronischen Gesundheitsakten, die auf den openehr-spezifikationen basieren, repräsentieren COMPOSITIONs die elementaren Informationseinheiten, welche beim Bearbeiten einer Akte hinzugefügt, geändert oder gelöscht werden. Eine COMPOSITION wird ausgehend von der entsprechenden Klasse des Referenzmodells mit Hilfe eines COMPOSITION-Archetyps definiert. Hierzu wird in der Regel auf weitere Strukturarchetypen (beispielsweise SECTION-Archetypen) und Inhaltsarchetypen (so etwa OBSERVATION-Archetypen) zurückgegriffen. So nutzt die COMPOSITION COMPOSITION.medication_list.v1 beispielsweise die Archetypen ACTION.medication.v1 und INSTRUCTION.medication.v1. Die jeweils vorangestellte Bezeichnung openehr-ehr[ ] zeigt dabei an, dass es sich um Archetypen handelt, die auf dem openehr Referenzmodell basieren. Auf Ebene der COMPOSITIONs ist in openehr-basierten Akten ferner ein Versionierungsmechanismus vorgesehen: Immer wenn ein Datenelement in einer Akte geändert wird, wird eine neue Version der COMPOSTION erzeugt, zu welcher das geänderte Element gehört. Die openehr-spezifikationen legen fest, dass COMPOSITIONs in Verzeichnissen (engl. Folders) logisch organisiert werden können. Verzeichnisse könnten beispielsweise genutzt werden, um getrennt alle COMPOSITIONs eines Patienten zusammenzufassen, welche die demographischen Daten des Patienten repräsentieren, zum Beispiel das Alter des Patienten, die Informationen enthalten, die von längerfristiger Dauer sind, zum Beispiel Dauermedikationen und die Informationen enthalten, die nur eine kurze Zeit nach ihrer Erfassung von einiger Relevanz sind, zum Beispiel die Dokumentation eines vorübergehenden grippalen Infekts. Dabei kann eine COMPOSITION auch in mehreren Verzeichnissen gleichzeitig referenziert werden (nach [BEALE, HEARD et al. 2008], S. 24f). Das Archetype Object Model (AOM) ist das openehr-meta-modell zur Beschreibung von Archetypen. Die Archetype Definition Language (ADL) ermöglicht es, einen Archetyp in Textform zu beschreiben. ADL und AOM sind zueinander äquivalent und lassen sich daher ineinander überführen. Mit einem Parser können eine ADL-Datei eingelesen und Objekte entsprechend dem AOM im Speicher erzeugt werden. Um einen oder mehrere Archetypen lokalen Anforderungen, wie etwa in einem bestimmten Krankenhaus, anzupassen, werden sogenannte Templates benutzt. Ein Template kann

33 Grundlagen 13 mehrere Archetypen zusammenfassen und die referenzierten Archetypen weiter einschränken. Zum Beispiel können dadurch optionale Elemente ausgeblendet oder Standardwerte vorgegeben werden. Ein Template entspricht häufig einem Bildschirmformular. So könnte ein Template Vitalzeichen die Archetypen Blutdruck und Atmung zusammenfassen. Abb. 2-2 zeigt wie Templates, Archetypen und Referenzmodell aufeinander aufbauen. Abb. 2-2: Beziehungen zwischen openehr-templates, -Archetypen und -Referenzmodell sowie weiteren Elementen [nach - letzter Zugriff: ]. Zur Abfrage von in elektronischen Gesundheitsakten gespeicherten Daten wird die Archetype Query Language (AQL früher EHR Query Languae EQL ) entwickelt. Die AQL ist unabhängig von bestimmten EHR-Systemen oder Programmiersprachen und basiert lediglich auf der Semantik des openehr AOM. Die AQL könnte prinzipiell auch für andere auf Archetypen basierende EHR-Systeme genutzt werden. Die Syntax von AQL ist eine Verschmelzung von SQL-Syntax und openehr ADL Pfad-Syntax (nach [MA, FRANKEL et al. 2007; SACHDEVA und BHALLA 2009]; siehe auch display/spec/archetype+query+language+description). Nach [MA, FRANKEL et al. 2007] könnte beispielsweise mit folgender Abfrage (Abb. 2-3) die aktuelle Medikation eines Patienten ermittelt werden: AQL SELECT c FROM EHR e [ehr_id=$ehrid] CONTAINS COMPOSITION c [COMPOSITION.medication_list.v1] WHERE c/name/value = current medication list Abb. 2-3: AQL-Abfrage zur Ermittlung der aktuellen Medikation eines Patienten (nach [MA, FRANKEL et al. 2007]).

34 14 Multiple Verwendung von Patientendaten unter Nutzung von Archetypen Vorteile Nachteil Beispiele 2.7 Bestehende Ansätze zur multiplen Nutzung von Daten aus der Routineversorgung Klinische Studien verursachen durch hohe Anforderungen an die Datenqualität häufig nicht unerhebliche Kosten bei der Sammlung der benötigten Daten (vgl. [KOHANE und ALTMAN 2005] und [SAX 2008]). Daher besteht ein breites Interesse, bereits elektronisch vorhandene Daten für Studien zu nutzen (vgl. [WINTER, FUNKAT et al. 2007], [PROKOSCH und GANSLANDT 2009] und [OHMANN und KUCHINKE 2009]). Nachfolgend werden verschiedene lokale und überregionale Ansätze hierzu vorgestellt. Ferner werden in diesem Zusammenhang verfügbare Werkzeuge und Austauschformate betrachtet. Single-Source-Ansatz Die Idee des Single-Source-Ansatzes besteht darin, Daten für die klinische Forschung nicht in einem vom KIS unabhängigen System, sondern im KIS selbst zu dokumentieren. Hierzu werden im KIS notwendige Formulare ergänzt, welche die Dokumentation der für die jeweilige Studienfragestellung benötigten Merkmalsarten erlauben. Zur weiteren Verarbeitung und Auswertung werden die Daten nach dem Erfassen im KIS in der Regel in eine eigenständige Forschungsdatenbank oder ein Studiendatenmanagementsystem exportiert. Hierdurch entfällt die manuelle Übernahme der Daten aus dem KIS in die Forschungsdatenbank bzw. das SDMS. Dies spart nicht nur Zeit, sondern vermeidet auch mögliche Übertragungsfehler. Darüber hinaus, können Ärzte und Pflegekräfte alle Daten in dem ihnen vertrauten System dokumentieren und müssen sich nicht in ein weiteres System einfinden. Wenn Studiendaten primär im KIS erfasst werden, können ferner keine Inkonsistenzen zwsichen den Quelldaten im KIS und den Studiendaten im SDMS entstehen. Dieser Ansatz ist nicht ohne weiteres auf eine multizentrische Studie übertragbar, da Forschungsdatenbasis und KIS oft proprietär beispielsweise auf Datenbankebene verknüpft wurden. Kämen durch andere Studienzentren verschiedene weitere KIS hinzu, müsste die Interoperabilität der Forschungsdatenbank mit jedem dieser Systeme einzeln geschaffen werden (vgl. etwa [KATZER, RÖHRIG et al. 2006]). Single-Source-Ansätze wurden und werden aktuell in verschiedenen Häusern, vornehmlich Universitätsklinika, etabliert so beispielsweise in Gießen, Erlangen, Münster oder Wien. So wird am Gießen Research Center in Infectious Diseases des Universitätsklinikums Gießen versucht, aus Genomdaten und klinischen Daten prognostische Modelle für Entwicklung bzw. Verlauf einer Sepsis bei verschiedenen Krankheitsbildern zu entwickeln. Die hierzu benötigten klinischen Studiendaten werden automatisch aus dem dort etablierten elektronischen Intensivdokumentationssystem in eine Forschungsdatenbank übernommen (siehe [KATZER, RÖHRIG et al. 2006]). Am Comprehensive Cancer Center des Universitätsklinikums Erlangen wird die Tumordokumentation in verschiedenen Bereichen vollständig im KIS durchgeführt. Von dort werden die Daten zur wissenschaftlichen Auswertung in ein i2b2-basiertes Data-Ware- House (siehe Kapitel 2.7) bzw. ein kommerzielles Studiendatenmanagementsystem überführt. Wenn i2b2 zur Auswertung genutzt wird, können in Erlangen erhobene Daten sogar mit Daten anderer Zentren zusammengeführt werden (siehe [PROKOSCH, RIES et al. 2011]). Retrieve Form for Data-capture Der Retrieve Form for Data-capture -Leitfaden (RFD) wurde gemeinsam entwickelt von CDISC und Integrating the Healthcare Enterprise (IHE). RFD ermöglicht es, in Formulare einer Applikation Daten aus einer externen Quelle einzufügen, diese Daten zu ergänzen und wieder zurückzuspielen. Die Integration geschieht dabei nahtlos und für den Anwender unsichtbar (vgl. [INTEGRATING THE HEALTHCARE ENTERPRISE 2008] und [BAIN 2009]).

35 Grundlagen 15 Der RFD-Leitfaden, in der IHE Terminologie als Profil bezeichnet, beschreibt die betrachtete Problematik in Form von Anwendungsfällen, Aktoren und Transaktionen und definiert einen auf bestehenden Standards und Techniken basierenden Lösungsansatz. So ist eine zentrale, im RFD-Profil genutzte Technologie der W3C Standard für elektronische Formulare XForms ( Der RFD Leitfaden beschreibt zwar, wie Daten in Formulare aus einer externen Quelle eingefügt werden können, Voraussetzung hierfür ist die manuelle, teilweise aufwändige Zuordnung geeigneter Datenquellen zu den einzelnen Feldern eines Formulars. Informatics for Integrating Biology and Bedside Ein Ansatz zur Vernetzung von Versorgung und Forschung aus den USA ist das Informatics for Integrating Biology and Bedside Projekt (i2b2 i2b2 unterstützt die translationale Medizin, indem Werkzeuge bereitgestellt werden, um große, heterogene Bestände von phänotypischen Daten aus der Patientenversorgung sowie die zugehörigen Genomdaten für Forschungszwecke zu vernetzen. Der Fokus der vorliegenden Arbeit ist im Gegensatz dazu stärker ausgerichtet auf die multiple Nutzung phänotypischer Daten aus der Patientenversorgung, die in unterschiedlichen Systemen und in unterschiedlichen Einrichtungen entstehen. Diese Notwendigkeit entsteht insbesondere in multizentrischen Studien. cancer Biomedical Informatics Grid Speziell für die Krebsforschung wurde in den USA das cancer Biomedical Informatics Grid (cabig etabliert. Das cabig soll es ermöglichen, Daten aus verschiedenen Quellen zu integrieren und zu analysieren. Grundlage hierfür bilden eine Grid-Infrastruktur, entsprechende Applikationen sowie Leitlinien und Standards, um weitere Anwendungen zu entwickeln und integrieren (nach [OSTER, LANGELLA et al. 2008]). Das Ökosystem der verfügbaren cabig Anwendungen und Dienste ist inzwischen relativ komplex. Der initialen Intention folgend, wurden die verfügbaren Werkzeuge primär für die Krebsforschung entwickelt. Der in dieser Arbeit untersuchte, auf Archetypen basierende Ansatz hat einen allgemeineren, breiteren Fokus. Biomedical Research Integrated Domain Group Model Das Biomedical Research Integrated Domain Group (BRIDG Model will Brücken schlagen zwischen Organisationen, technischen und fachlichen Experten sowie zwischen unterschiedlichen klinischen Informationsmodellen. Die folgenden Einrichtungen und Organisationen arbeiten gemeinsam an der Entwicklung des BRIDG- Modells (vgl. [BRIDG 2008], S. 4): Das Clinical Data Interchange Standards Consortium (CDISC), das HL7 Regulated Clinical Research Information Management Technical Committee (HL7 RCRIM TC), das amerikanische National Cancer Institute (NCI) und die amerikanische Food and Drug Administration (FDA). Im Gegensatz zu den vorhergehend genannten Modellen handelt es sich beim BRIDG- Modell um ein Domänen Analyse Modell. Übergeordnetes Ziel des BRIDG-Modells ist die semantische Interoperabilität insbesondere zwischen klinischer Forschung und Gesundheitsversorgung, aber auch mit anderen Bereichen wie etwa Public Health. Die verschiedenen Standards in Forschung und Versorgung sowie innerhalb dieser Bereiche sollen harmonisiert und verschiedene Standardisierungsbemühungen integriert werden. Hierzu versucht das BRIDG-Modell eine gemeinsame Sicht auf Datenstrukturen (statische Semantik), Geschäftsprozesse (dynamische Semantik) sowie Beziehungen zu schaffen. Der Fokus liegt dabei auf der protokollgetriebenen Forschung und den zugehörigen regulatorischen Artefakten ([ANGELES, EVANS et al. 2010], S. 8).

36 16 Multiple Verwendung von Patientendaten unter Nutzung von Archetypen Protokollgetriebene Forschung bezieht sich hier vornehmlich auf klinische Studien und bedeutet Forschung gemäß den exakten Vorgaben eines Studienprotokolls, wie es in klinischen Studien üblich ist. Elemente bzw. Konzepte aus dem Bereich der protokollgetriebenen Forschung sind beispielsweise Menschen, Tiere, Organisationen, Studiendesigns, Beobachtungen in klinischen Studien etc. Um diese Konzepte zu modellieren, nutzt das BRIDG-Modell die Unified Modeling Language (UML). Konzepte, Attribute und Beziehungen werden mit Hilfe von UML- Klassen- und Instanz-Diagrammen dargestellt. Für Prozesse werden UML-Aktivitäts-, Status- und Sequenz-Diagramme eingesetzt. Die UML bietet den Vorteil, dass sie auch von nicht technischen Fachexperten relativ leicht erlernt werden kann. Die Überarbeitung und weitere Ausgestaltung des BRIDG-Modells wird von einem Bord of Directors und einem Technical Harmonization Committee systematisch gesteuert und unterstützt (siehe [ANGELES, EVANS et al. 2010], S. 18ff). Die Semantik des BRIDG-Modells kann prinzipiell abgebildet werden auf die CDISC Spezifikationen und das HL7 RIM. Obwohl es eine RIM-basierte Abbildung des BRIDG- Modells gibt, basiert das Modell selbst nicht auf dem HL7 RIM. Dies führt dazu, dass eine 1:1 Abbildung beispielsweise von Attributen zwischen BRIDG-Modell und HL7 RIM oft nicht möglich ist. Häufig wird ein BRIDG Attribut auf eine Kombination von RIM Attributen abgebildet. Die auf dem HL7 RIM basierende Abbildung des BRIDG-Modells ist darüber hinaus auch nicht als unmittelbare Grundlage für den auf HL7 basierenden Nachrichtenaustausch, sondern als Diskussionsgrundlage mit HL7 Nutzern gedacht (vgl. [ANGELES, EVANS et al. 2010], S. 42ff). Praktisch kann das BRIDG-Modell genutzt werden bei der Entwicklung von Applikationen, um eine gemeinsame Semantik zwischen verschiedenen Anwendungen zu gewährleisten, etwa zwischen einem Studiendatenmanagementsystem und einem SAE-Reporting Werkzeug. So wird das BRIDG-Modell beispielsweise im cabig Clinical Trial Management System ( genutzt. Die BRIDG-Spezifikationen sind frei verfügbar ( 9082/BRIDG_Release_3.0.3_Package.zip). Für die Entwicklung von Software, welche das BRIDG-Modell nutzt, wird jedoch eine HL7-Lizenz benötigt, da die Attribute des statischen BRIDG-Modell auf HL7 Version 3 Datentypen basieren (vgl. [BRIDG 2008], S. 10f). Clinical Data Acquisition Standards Harmonization Der CDISC Clinical Data Acquisition Standards Harmonization Standard (CDASH definiert Bezeichnungen, Beschreibungen und Ausfüllhinweise zu Datenelementen, die häufig in klinischen Studien erhoben werden. In sogenannten Domänentabellen werden logisch zusammengehörige Datenfelder als Basisdatensätze für die jeweiligen Anwendungen zusammengefasst, zum Beispiel für unerwünschte Ereignisse. Der CDASH Standard Version 1.1 beschreibt insgesamt 18 solcher Domänentabellen (vgl. [CDISC 2011]). Ziel von CDASH ist es, eine einheitliche und dadurch effiziente Datensammlung und -auswertung in klinischen Studien zu ermöglichen. Standardisierte Basisdatensätze vereinfachen jedoch nicht nur den Entwurf von papierbasierten und elektronischen CRF, sondern können darüber hinaus auch Metaanalysen unterstützen. Abgesehen von Empfehlungen zu Vorgehensweisen beim Erstellen von Datenerhebungswerkzeugen (siehe [CDISC 2010a]), nimmt CDASH jedoch keinen Einfluss auf das Erscheinungsbild oder Layout von CRF. Die definierten Basisdatensätze können auch genutzt werden, um die Schnittstellen zwischen Systemen in der Forschung und elektronischen Patientenakten zu verbessern. Eine der 18 CDASH Domänen ist die Domäne Prior and Concomitant Medications (CM), welche dazu dient, die Medikationen eines Studienteilnehmers zu erfassen. Die eigentliche Prüfmedikation einer Arzneimittelstudie wird hierbei jedoch nicht berücksichtigt und

37 Grundlagen 17 gesondert behandelt. Es wird unterschieden zwischen Medikationen, die bereits vor Studienbeginn beendet wurden (prior), solchen, die erst im Laufe der Studie abgesetzt wurden (concomitant) und solchen, die über das Studienende hinaus bestanden (ongoing). Für die Domäne CM sind insgesamt 20 Felder definiert. Dabei kann unterschieden werden zwischen Feldern, welche eine Medikation qualitativ beschreiben (zum Beispiel die Angabe des Wirkstoffs), quantitativ beschreiben (zum Beispiel die verabreichte Dosis) sowie Datums- und Zeitangaben und organisierenden Feldern. Ein Beispiel dafür ist die Frage: Ist überhaupt eine Medikationsangabe vorhanden? Abhängig von der Beantwortung dieser Frage werden weitere Daten erhoben oder nicht. Darüber hinaus existieren Feldern zur Strukturierung des Datenerhebungsbogens bzw. Referenzfelder (zum Beispiel zur Referenz auf andere CRF so etwa im Kontext von unerwünschten Ereignissen) (nach [KRUEL 2010]. S17ff). Ein enger Zusammenhang besteht zwischen CDASH und dem CDISC Study Data Tabulation Model (SDTM): CDASH bildet eine Erweiterung des SDTM, indem CDASH Anforderungen des SDTM und den Inhalt von Datenerhebungsbogen integriert. Zahlreiche CDASH-Datenelemente können daher auf das SDTM abgebildet werden. Ferner ist die CDASH-Terminologie eine Untermenge der SDTM-Terminologie (CDISC Controlled Terminology). Die CDASH-Terminologie stellt für eine Reihe von Datenfeldern Code- Listen mit häufig benutzten Fachtermen sowie deren Abkürzungen bereit. In CDASH Version 1.1 wurden die definierten Datenelemente außerdem um ein Attribut erweitert, welches den Bezug zum BRIDG-Modell herstellt, sofern dies sinnvoll und möglich war (vgl. [CDISC 2010a]). Operational Data Model Das Operational Data Model (ODM) ist ein vom Clinical Data Interchange Standards Consortium (CDISC) entwickelter, auf XML basierender, offener Standard für den Austausch, die Einreichung und Archivierung von Studiendaten. Das ODM bildet hierzu drei informationelle Aspekte klinischer Studien ab: 1. Die Studien-Metadaten (Definition von Merkmalsarten und Studienprotokoll), 2. administrative Daten (die beteiligten Nutzer und deren Zugriffsrechte), 3. die eigentlichen Studiendaten (vollständige Patientendatensätze samt Audit-Trail). Bei ODM handelt es sich jedoch lediglich um einen Transportstandard die Semantik der transportierten Daten ist primär nicht standardisiert (vgl. [IBERSON-HURST 2004]). Basierend auf dem ODM abgelegte Studiendaten lassen sich mit geeigneten Werkzeugen in andere Darstellungsformen wie etwa das CDISC Study Data Tabulation Model (SDTM) überführen (vgl. Werkzeuge der TMF e. V. Im Rahmen von Projekten generiert die TMF als Dachorganisation medizinischer Forschungsverbünde Methoden und Werkzeuge, um die vernetzte medizinische Forschung in Deutschland zu unterstützen. So soll es das TMF Meta-Data-Repository beispielsweise ermöglichen, Strukturen, Merkmalsarten und Vokabulare zu definieren und einheitlich darzustellen. Hierdurch sollen, ähnlich wie auch durch CDASH, der Aufwand bei der Planung und Durchführung der Datenerhebung in der medizinischen Forschung reduziert und übergreifende Auswertungen erleichtert werden (nach [TMF 2009]). Hierzu implementiert das TMF Meta-Data- Repository ein Metamodell gemäß ISO/IEC Meta-Data- Repository

38 18 Multiple Verwendung von Patientendaten unter Nutzung von Archetypen Datenschutzkonzepte Um Verbundforschung gerade auch im Kontext der strengen, in Deutschland geltenden Datenschutzregularien zu ermöglichen, wurden von der TMF verschiedene, generische Datenschutzkonzepte entwickelt. Ergänzend wurden Werkzeuge implementiert, um die Konzepte einfach in der Praxis realisieren zu können (so beispielsweise Werkzeuge zur Pseudonymisierung und zum Identitätsmanagement wie den TMF PID-Generator). Die beiden genannten TMF Projekte Meta-Data-Repository und Datenschutzkonzept können im Kontext der multiplen Verwendung von Gesundheitsdaten wertvolle Bausteine darstellen. Ferner engagiert sich die TMF direkt in der Projektgruppe Nutzung von elektronischen Patientenakten für die klinische Forschung der Deutschen Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie e. V. (GMDS).

39 Vorgehen und Methodik 19 3 Vorgehen und Methodik Im Folgenden werden das Vorgehen und die Untersuchungsmethoden beschrieben, die angewendet wurden, um die Ziele dieser Arbeit zu erreichen. 3.1 Generisches Vorgehensmodell für die multiple Nutzung von Daten in Forschung und Versorgung An Daten, die in klinischen Studien ausgewertet werden, werden meist höhere Qualitätsanforderungen gestellt als an Daten, die im Rahmen der medizinischen Versorgung erhoben werden. Daten für klinische Studien müssen in der Regel in definierten Formaten und nach einem exakt definierten Vorgehen erhoben werden. Darüber hinaus kann es vorkommen, dass in klinischen Studien Daten benötigt werden, die nicht zum Spektrum der Routinedokumentation eines Krankenhauses gehören. Daher muss vor einer multiplen Verwendung von KIS-Daten systematisch geprüft werden, welcher Anteil der in einer Studie geforderten Daten aus dem KIS übernommen werden könnte. Dabei müssen alle in der Studie zu erhebenden Merkmalsarten mit allen möglicherweise relevanten, im KIS dokumentierbaren Merkmalsarten vergleichen werden. Die in einer Studie zu erhebenden Daten lassen sich dabei in der Regel aus Studienprotokoll, CRF und Studiendatenbank ableiten. KIS bestehen hingegen oft aus verschiedenen Subsystemen, zu welchen kaum semantische Beschreibungen der darin erfassbaren Merkmalsarten vorliegen. Dazu gehören explizit auch die konventionellen, also nicht rechnerunterstützten Subsysteme eines KIS. Für den notwendigen systematischen Vergleich der Merkmalsarten aus KIS und Studie wurde ein generisches Vorgehensmodell entwickelt, das unabhängig ist von den genutzten Anwendungssystemen und für beliebige Studien genutzt werden kann. Die in Abb. 3-1 dargestellten Teilschritte dieses Vorgehensmodells werden nachfolgend im Detail beschrieben. Wesentlicher Bestandteil dieses Vorgehensmodell ist die Erhebung von Metadaten, welche die Eigenschaften der im KIS dokumentierbarien Merkmalsarten beschreiben. So kann geprüft werden, welche KIS-Daten die Anforderungen einer Studie erfüllen und sich für eine multiple Verwendung eignen. Abb. 3-1: Generisches Vorgehensmodell für die multiple Nutzung von Daten in Forschung und Versorgung.

40 20 Multiple Verwendung von Patientendaten unter Nutzung von Archetypen Schritt 1: Schritt 2: Erfassung der verfügbaren Merkmalsarten Systematisches Erfassen aller Merkmalsarten, die im KIS typischerweise zu einem relevanten Patientenkollektiv dokumentiert werden. Ein solches Patientenkollektiv ergibt sich beispielsweise aus der Menge der Patienten, welche entsprechend den Ein- und Ausschlusskriterien in die jeweilige Studie eingeschlossen werden könnten. Beginnend mit der im KIS vorhandenen Dokumentation zu einem Patienten werden alle Merkmalsarten, die im KIS zu diesem Patienten vorhanden sind, sowie zugehörige Meta- Merkmale erhoben. Diese Erhebung wird solange mit weiteren Patienten fortgeführt, bis die Menge der im KIS gefundenen Merkmalsarten gesättigt ist und nicht weiter wächst. Dabei sind für jede gefundene Merkmalsart folgende Meta-Merkmale zu erheben: System bzw. Dokument, welches genutzt wird, um die jeweilige Merkmalsart zu erfassen, die systeminterne Bezeichnung der Merkmalsart, der Typ der möglichen Merkmalsausprägungen o Ganzzahl o Gleitkommazahl o Datum o Uhrzeit o Code (zum Beispiel ICD 10-Codes) o Auswahlliste (zum Beispiel Liste von Stationen) und o Freitext sowie, falls zutreffend, die Einheit der Merkmals-ausprägungen, zum Beispiel bei Laborwerten und falls vorgesehen auch alternative, erlaubte Einheiten. Ergänzende Bemerkungen werden bei Auffälligkeiten oder Besonderheiten dokumentiert. Dies können zum Beispiel Abhängigkeiten mehrerer Merkmalsarten untereinander oder Listendarstellungen sein. Ebenso wird hier die vollständige Bezeichnung einer Merkmalsart dokumentiert, wenn diese systemintern nur mit einer Abkürzung bezeichnet ist. Als weiteres Meta-Merkmal werden semantische Integritätsbedingungen dokumentiert, die beispielsweise regeln, wann eine Merkmalsart in der Studie zu erheben ist und wann nicht. Der Typ einer Fistel müsste etwa nur dann dokumentiert werden, wenn auch eine Fistel vorliegt. Ebenso werden Plausibilitätsprüfungen erfasst (zum Beispiel Körpergröße muss zwischen 100 cm und 220 cm betragen ). Als zusätzliches Meta-Merkmal wird zu den einzelnen Merkmalsarten im KIS erhoben, ob üblicherweise auch Ausprägungen dokumentiert werden. Diese Meta-Merkmale dienen der Überprüfung der syntaktischen und semantischen Interoperabilität zwischen zwei Merkmalsarten. Ferner kann anhand dieser Meta-Merkmale geprüft werden, ob die in einer Studie geforderte Datenqualität eingehalten wird und ein entsprechendes Datenelement aus dem KIS in die Studie übernommen werden könnte. Wurden alle Merkmalsarten, die in einem KIS dokumentiert werden können, vollständig analysiert, muss dieser Schritt nur einmal pro Studienzentrum durchgeführt werden. Der dabei entstandene Katalog von Merkmalsarten und zugehörigen Meta-Merkmalen kann bei der multiplen Nutzung der jeweiligen KIS-Daten für künftige Studien wiederverwendet werden. Erfassung der benötigten Merkmalsarten Analog zu Schritt 1 werden in Schritt 2 alle Merkmalsarten sowie deren Meta-Merkmale systematisch erfasst, die in der Studie bzw. für die jeweilige Auswertungsfrage benötigt werden. Im Falle klinischer Studien ergeben sich diese Merkmalsarten in der Regel aus den CRF- bzw. Datenbankdefinitionen. Dieser Schritt muss einmal pro Studie durchgeführt werden.

41 Vorgehen und Methodik 21 Zuordnung geeigneter Merkmalsarten Für jede in der Studie benötigte Merkmalsart wird geprüft, ob eine entsprechende Merkmalsart im KIS vorhanden ist, welche die jeweils benötigte Information liefern kann. Falls eine oder mehrere solcher Merkmalsarten im KIS erfasst werden, werden die entsprechenden Abbildungen dokumentiert. Bei diesen Abbildungen muss nicht nur die inhaltliche Konsistenz der Merkmalsarten geprüft werden, sondern auch ob Erhebungszeitpunkt, Typ und gegebenenfalls Format bzw. Einheit passend sind. Sind zwei Merkmalsarten in KIS und SDMS nicht identisch, kann es dennoch möglich sein, die für die Studie benötigten Informationen aus den KIS-Daten anzuleiten. Dazu müssen geeignete Transformations-vorschriften definiert werden. Ein Beispiel wäre die Berechnung des in einer Studie benötigten Body-Mass-Index aus den Merkmalsarten Körpergröße und Gewicht im KIS. Folgende Klassen von Transformationen können unterschieden werden: 1:1 direkte Übernahme möglich / keine Transformation notwendig; M:N eine Menge von m möglichen Merkmalsausprägungen im KIS muss eindeutig auf n mögliche Ausprägungen in der Studie abgebildet werden; Umrechnung der für die Studie benötigte Wert muss aus einem anderen Wert im KIS errechnet werden (beispielsweise die Umrechnung eines Laborwerts in eine andere Einheit); Logik der für die Studie benötigte Wert muss aus mehreren Werten im KIS errechnet werden (so etwa die Berechnung des Body-Mass-Index). Darüber hinaus können die in einer Studie benötigten Informationen zwar im KIS erfasst sein, dort jedoch in wenig strukturierter Form, als Freitext vorliegen. Je nach Grad der Strukturierung kann es möglich sein, die benötigte Information mit einer speziellen Art der Transformation, dem Textmining, aus dem unstrukturierten Text zu extrahieren. Ist eine in der Studie benötigte Merkmalsart in mehreren Subsystemen des KIS verfügbar, wird primär die Merkmalsart vorgeschlagen, welches im engsten zeitlichen Kontext zur Erhebung der jeweiligen Studiendaten steht. Zusätzlich sollte berücksichtigt werden, welches Datenelement im KIS subjektiv die größte Validität aufweist oder am stärksten strukturiert vorliegt. Implementierung In Schritt 4 werden geeignete Schnittstellen zwischen KIS und SDMS basierend auf den vorhergehend identifizierten Abbildungen und Transformationen implementiert, um KIS- Daten in das SDMS übernehmen und beispielsweise CRF-Felder vorbelegen zu können. Alternativ, falls ein Single-Source-Ansatz angestrebt wird, werden Merkmalsarten im KIS ergänzt, welche in der Studie zusätzlich benötigt werden. Nur wenn diese vier Schritte vollständig durchgeführt werden, kann gewährleistet werden, dass Daten, die aus dem KIS in eine Studie übernommen werden, die in der Studie geforderte Qualität aufweisen. Schritt 3: Schritt 4: 3.2 Fallstudie Um zu ermitteln, welche Anforderungen an Daten in Forschung und Versorgung gestellt werden und in welchem Umfang eine multiple Verwendung realisierbar ist, wurde eine Fallstudie durchgeführt (vgl. [MAYRING 2007], S. 28ff und [AMMENWERTH, ILLER et al. 2003]). Die zentralen Auswertungsfragen dieser Fallstudie lauteten: Wie hoch wäre der Anteil der Daten, der heute schon aus dem KIS für eine konkrete Studie übernommen werden könnte? Wie hoch wäre dieser Anteil, wenn das KIS vollständig rechnerunterstützt wäre? In welchen Formaten werden die Merkmalsarten im KIS bzw. in der Studie dokumentiert? Aufbauend auf den Antworten zu diesen Fragen wurden allgemeine Anforderungen an eine Systemarchitektur zur Integration von KIS und SDMS abgeleitet. In der Fallstudie wurde das

42 22 Multiple Verwendung von Patientendaten unter Nutzung von Archetypen ctag-studie Prozessanalyse Datenbestandsanalyse Krankenhausinformationssystem im vorhergehenden Kapitel eingeführte Vorgehensmodell angewendet. Als konkreter Fall wurden das Heidelberger KIS und die ctag-studie (conformable Thoracic Stent Grafts) ausgewählt. Das Heidelberger KIS, die ctag-studie sowie die daran durchgeführte Fallstudie werden im Folgenden im Detail dargestellt. Die ctag-studie ist eine gefäßchirurgische Studie, in welcher die Anwendung von verformbaren Stents in der Aorta untersucht wurde. Diese Stents können sich dem Gefäßverlauf anpassen und so bei der Überdeckung von Aneurysmen im Aortenbogen Vorteile bieten gegenüber herkömmlichen Stents. Die ctag Studie ist eine einarmige, multizentrische, industriegesponserte Studie, die in Heidelberg und in vier weiteren europäischen Zentren durchgeführt wird. Dabei wird vom Sponsor angestrebt, insgesamt ca. 100 Patienten in die Studie einzuschließen. Die im Rahmen dieser Arbeit durchgeführte Fallstudie wurde an einer Stichprobe der in Heidelberg rekrutierten Patienten durchgeführt. In semistandardisierten Gesprächen mit dem Prüfarzt und der Study Nurse am Studienzentrum Heidelberg wurden der Ablauf der Datenerhebung für die ctag-studie und dabei auftretende, typische Probleme erfasst. Hierbei wurden auch die bei der Datenbestandsanalyse zu berücksichtigenden Dokumentationssysteme ermittelt. Gemäß Vorgehensmodell (siehe Kapitel 3.1) wurden mit Hilfe von Datenbestandsanalysen zunächst alle Merkmalsarten, die im KIS konventionell wie auch elektronisch dokumentiert werden können, erfasst und mit dem Satz von Meta-Merkmalen charakterisiert. Anhand der ecrf der ctag-studie und der zugehörigen Studiendatenbank wurden dann die für die Studie zu erhebenden Merkmalsarten analysiert, dokumentiert und den im KIS erfassbaren Merkmalsarten systematisch gegenübergestellt. Als Werkzeug zur Dokumentation der einzelnen Merkmalsarten, der zugehörigen Merkmalsausprägungen, der identifizierten Abbildungen und der notwendigen Transformationen wurden Microsoft Excel-Tabellen entwickelt. Waren zu einer für die Studie benötigte Merkmalsart in mehreren Subsystemen des KIS geeignete Datenelemente verfügbar, wurden neben der primär vorgeschlagenen Abbildung auch die weiteren möglichen Abbildungen dokumentiert. Die identifizierten Abbildungen wurden gemeinsam mit der für die ctag-studie zuständigen Study Nurse validiert. Am Universitätsklinikum Heidelberg wird eine weitgehend papierlose Dokumentation und Archivierung angestrebt. Während des stationären Aufenthalts eines Patienten werden alle vorhandenen und anfallenden papierbasierten Dokumente in der sogenannten Präsenzakte (klassische, papierbasierte Patientenakte) gesammelt. Sobald der Patient entlassen wird, werden alle Dokumente aus der Präsenzakte gescannt und anschließend vernichtet (vgl. [KNAUP, PILZ et al. 2006]). Auf die gescannten Dokumente kann dann, wie auch auf die übrigen, direkt elektronisch erzeugten Dokumente, über das klinische Arbeitsplatzsystem i.s.h.med bzw. ein darin eingebundenes digitales Archiv zugegriffen werden. Eine Texterkennung beim Scannen von ursprünglich papierbasierten Dokumenten findet zurzeit nicht statt. Konkret wurden am Studienzentrum Heidelberg folgende Dokumentationssysteme in die Untersuchung eingeschlossen: Elektronische Subsysteme: SIEMENS i.s.h.med: Klinisches Arbeitsplatzsystem inklusive der Daten aus den Laborinformationssystemen. PHILIPS CareVue: Patientendatenmanagementsystem in Heidelberg für die Chirurgie adaptiert und auch nur dort eingesetzt. GE Centricity PACS: Bildarchivierungs- und Kommunikationssystem.

43 Vorgehen und Methodik 23 Konventionelle Subsysteme: Präsenzakte: Papierbasierte Patientenakte, die für die Dauer des stationären bzw. ambulanten Aufenthalts, alle konventionellen Dokumente aufnimmt (wird in Form von digitalen Kopien archiviert). Ambulanzakte: Papierbasierte Patientenakte (zur nachstationären Nutzung). Bei der Untersuchung wurden nur Dokumente bzw. Merkmalsarten im KIS von Patienten berücksichtigt, die in die ctag-studie eingeschlossenen worden waren. Um ein möglichst umfassendes Bild zu erhalten, wurden alle Merkmalsarten berücksichtigt, die im KIS vorhanden waren, nachdem der ctag implantiert, der Patient aus der Klinik entlassen und mindestens zum ersten Follow-Up-Termin wieder vorstellig geworden war. Dabei wurde angenommen, dass einmal erfasste Daten nicht mehr aus dem KIS gelöscht werden und dementsprechend die Menge der verfügbaren Informationen zu einem Patienten monoton wächst. Nicht berücksichtigt wurden Dokumente externen Ursprungs (beispielsweise Arztbriefe oder Laborbefunde der zuweisenden Ärzte), da diese von Patient zu Patient stark variieren. Auch am Universitätsklinikum Heidelberg selbst erzeugte, behandlungsspezifische Formulare bzw. Datenelemente im KIS wurden nicht berücksichtigt, wenn diese aus vorhergehenden oder nachfolgenden, von der ctag-implantation vollkommen unabhängigen Behandlungsfällen stammten. Ferner blieben Formulare ohne medizinischen Fallbezug unberücksichtigt (so etwa die Dokumentation des Sozialdienstes), da sie in diesem Fall keine studienrelevanten Merkmalsarten enthalten. In der geplanten Untersuchung sollte nicht nur eine Stichprobe der im klinischen Informationssystem dokumentierbaren Merkmalsarten eingeschlossen werden, sondern die Grundgesamtheit aller dort erfassbaren Datenelemente. Daher wurde die komplette elektronische und papierbasierte Dokumentation mehrerer Studienpatienten analysiert. Die Gruppe von Studienpatienten wurde dabei gemäß Vorgehensmodell solange erweitert, bis die Menge der papierbasierten und elektronischen Dokumente, die im Krankenhausinformationssystem zu den einzelnen Patienten vorgefunden wurde, saturiert war und nicht weiter wuchs. Die Patienten wurden dabei zufällig ausgewählt. Zufallsmoment war die Reihenfolge ihres Einschlusses in die ctag-studie. War dasselbe Dokument mehrfach vorhanden, wurden die darin enthaltenen Merkmalsarten nur einmal berücksichtigt und gezählt. So etwa im Fall von Arztbriefen, die sowohl konventionell in der Ambulanzakte als auch eingescannt als elektronisches Dokument vorlagen. Auch mehrfach vorhandene Dokumente desselben Typs wie mehrere Erhebungen derselben Laborparameter wurden nur einmal berücksichtigt Opereffa ( ist eine auf den openehr-spezifikationen basierende elektronische Gesundheitsakte, welche am University College London entwickelt wird. Opereffa selbst basiert auf der openehr Java Referenz Implementierung (vgl. [CHEN und KLEIN 2007]) und präsentiert sich dem Nutzer als Web-Anwendung, die Java Server Faces in der Präsentationsschicht nutzt. Zusätzlich wird das Dojo-Toolkit ( verwendet, um Asynchronous JavaScript and XML (AJaX) sowie erweiterte Funktionalitäten für die grafische Benutzeroberfläche nutzen zu können ([ARIKAN und INGRAM 2009]). Zur physikalischen Datenspeicherung nutzt Opereffa eine PostgreSQL- Einschlusskriterien Ausschlusskriterien Stichprobe 3.3 Prototyp Zum Identifizieren weiterer (technischer) Anforderungen an eine auf Archetypen basierende Systemarchitektur zur Integration von Forschung und Versorgung wurde prototypisch das open Study Data Management System (opensdms) entwickelt. Als Basis für opensdms wurde das openehr Reference Framework and Application (Opereffa) System genutzt. Darüber hinaus wurden die Abläufe bei der Benutzung von opensdms beschrieben.

44 24 Multiple Verwendung von Patientendaten unter Nutzung von Archetypen Datenbank ( welche über Hibernate ( angebunden ist ([ARIKAN und INGRAM 2009]). Dabei werden alle Datenelemente, die von den genutzten Archetypen spezifiziert werden, in einem Entity-Attribute-Value- Ansatz (EAV) in einer einzigen, generischen Tabelle gespeichert. Das bedeutet, dass Opereffa eine einzige Tabelle nutzt, um die medizinischen Daten aller im System vorhandenen Patienten zu speichern. Jede Zeile dieser Tabelle enthält genau ein Datenelement, welches für einen bestimmten Patienten zu einer bestimmten Zeit dokumentiert wurde und durch einen bestimmten Archetypen exakt beschrieben ist. Einfach ausgedrückt besteht ein Datensatz bzw. eine Zeile dieser Tabelle aus folgenden Elementen: Patienten-ID (identifiziert eindeutig einen bestimmten Patienten), Sitzungs-ID (identifiziert eindeutig einen bestimmten Dokumentationszusammenhang), des Archetyps, welcher das jeweilige Datenelement repräsentiert und Pfad des Datenelements innerhalb des Archetypen, durch Archetyp- und Archetyp Pfad wird ein Datenelement eindeutig identifiziert, dem eigentlichen Wert des Datenelements (=Merkmalsausprägung). Für die Implementierung von opensdms wurde Opereffa um eine spezielle Studiensicht samt zugehöriger Programmlogik erweitert. Hierzu wurden alle Ebenen des Opereffa Systems (Datenbank, Anwendungslogik und Präsentationsschicht) adaptiert siehe Abb Als Plattform für die Entwicklung wurde Eclipse der Eclipse Foundation genutzt (Version 3.5 / Galileo). Abb. 3-2: Darstellung der für Präsentation, Geschäftslogik und Persistenz in Opereffa genutzten Technologien. Den Kern von Opereffa bildet die openehr Java Reference Implementation. Für opensdms wurden alle Ebenen des Opereffa Systems erweitert. Ferner wurde eine XML-basierte Studiendefinition integriert. 3.4 Archetypen zur Dokumentation von und in klinischen Studien Eine auf Archetypen basierende, multiple Verwendung von Patientendaten für die klinische Forschung kann nur realisiert werden, wenn geeignete Archetypen zur Dokumentation von Studiendaten und Studien-Metadaten verfügbar sind. Analog der Unterscheidung von Studiendaten und Studien-Metadaten (vgl. Kapitel 2.3) können auch Archetypen für diese Klassen von Daten unterschieden werden. Unter Studien-Metadaten werden nachfolgend explizit die die studienbeschreibenden Daten verstanden und nicht die Definition der in einer Studie zu erhebenden Merkmalsarten und deren Formate. In einem ersten Schritt wurde daher geprüft, ob bereits spezielle Archetypen für Studiendaten oder Studien-Metadaten existieren. Hierzu wurde systematisch mit Hilfe des Ocean Clinical Knowledge Managers ( nach geeigneten

45 Vorgehen und Methodik 25 Archetypen gesucht. Als Suchbegriffe wurden clinical trial, clinical study trial, und study verwendet. Archetypen für Studiendaten In der Regel variieren die meisten in klinischen Studien erhobenen Merkmalsarten stark von Studie zu Studie. Bestimmte Merkmalsarten werden jedoch, zumindest in ähnlicher Weise, regelmäßig in Studien erhoben. Die CDASH Spezifikation (siehe Kapitel 2.7) will genau solche Merkmalsarten standardisieren. Daher wurde systematisch untersucht, in wie weit sich die in CDASH (Version 1.1) definierte Datenelemente mit Hilfe von openehr- Archetypen abbilden lassen. Hierzu wurden exemplarisch die in den vier CDASH-Domänen Common Identifier Variables (CI) Common Timing Variables (CT) Adverse Events (AE) und Prior and Concomitant Medications (CM) definierten Datenelemente (=Merkmalsarten) mit openehr-archetypen modelliert. Werden in einer elektronischen Patientenakte (EPA), welche auf openehr-archetypen basiert, Merkmalsarten mit denselben Archetypen repräsentiert, die zur Modellierung der CDASH- Domänen genutzt wurden, handelt es sich um die gleichen Merkmalsarten. Entsprechende EPA-Daten wären daher prinzipiell für die Übernahme in den jeweiligen, CDASHkonformen Datenerhebungsbogen einer Studie geeignet. Hierzu wurden zunächst mit Hilfe des Ocean Clinical Knowledge Managers ( systematisch alle Archetypen zusammengestellt, welche zum Zeitpunkt der Untersuchung vorhanden waren und einen Bezug zu den Konzepten der jeweiligen CDASH-Domäne erkennen ließen (im Falle der Domäne Prior and Concomitant Medications beispielsweise den Bezug zum Konzept Medikation ). Anschließend wurde für jedes CDASH-Datenelement geprüft, ob hierzu einer der identifizierten Archetypen ein korrespondierendes Datenelement enthält. Zusätzlich wurde für jede mögliche Abbildung geprüft, ob die von CDASH bzw. openehr vorgegebenen Datentypen und Wertebereiche in Übereinstimmung gebracht werden können. Alle korrespondierenden Felder wurden mittels entsprechender Abbildungen CDASH- Element Archetyp- und -interne Pfadangabe / Feldname dokumentiert. Diese Abbildungen sollen es ermöglichen, auf Archetypen basierende CDASH-konforme CRF für die betrachteten Domänen zu implementieren. Für jedes CDASH Feld, für welches sich eine Abbildung als schwierig erwies bzw. keine auf Archetypen basierende Abbildung gefunden wurde, wurden die Abbildungsprobleme analysiert und mögliche Lösungsansätze aufgezeigt. Wo sinnvoll und notwendig wurden bestehende Archetypen in Form von Spezialisierungen erweitert bzw. neue Archetypen entwickelt. Darüber hinaus wurden die Abbildungen so definiert, dass sie auch genutzt werden können, um Daten aus KIS, die auf den openehr- Spezifikationen basieren, zu extrahieren und damit CDASH-basierte Felder in ecrf vorzubelegen. In Fällen, in welchen sich Abbildungen als schwierig erwiesen, etwa weil mehrere unterschiedliche Archetypen gleichzeitig berücksichtigt werden mussten, wurde die AQL (sieh Kapitel 2.6) genutzt. Das Feld CMYN der Domäne Prior and Concomitant Medications ist ein Beispiel für einen solchen Fall: Feld CMYN (CM-Feldnummer 1) Feldinformation: Wurden irgendwelche Medikamente eingenommen? ( Ja / Nein ) Das Feld zeigt an, ob eine Medikation eingenommen wurde. Ist dies nicht der Fall, wird lediglich diese Information dokumentiert alle weiteren CM-Domänenfelder entfallen. Zur Dokumentation, dass von einem Patienten eine Medikation bzw. Substanz eingenommen wurde, könnten in einer auf openehr-archetypen basierenden Patientenakte unterschiedliche Archetypen genutzt werden. Um das CDASH-Feld CMYN in einem CRF

46 26 Multiple Verwendung von Patientendaten unter Nutzung von Archetypen basierend auf einer Patientenakte vorbelegen zu können, müsste diese Akte nach unterschiedlichen medikationsbezogenen Archetypen durchsucht werden. OpenEHR-Templates ermöglichen es, Bildschirmformulare ähnlich einem ecrf zu definieren, um Daten basierend auf Archetypen erfassen zu können. Für jede der betrachteten CDASH Domänen wurde ein solches Template erstellt, ausgehend von den identifizierten sowie den für CDASH neu entwickelten und angepassten Archetypen. Diese Templates können als Vorlage für ecrf in auf Archetypen basierenden SDMS genutzt werden. Zum Entwickeln der Templates wurde der Ocean Template Designers in der Version 2.6 eingesetzt. Archetypen für Studien-Metadaten Bei der Dokumentation klinischer Studien werden neben klinischen Daten auch Informationen erfasst, welche eine Studie und die dort erhobenen Daten an sich beschreiben wie etwa die Bezeichnung oder die Fragestellung einer Studie (Studien-Metadaten). Die papierbasierte Dokumentation einer Studie kann nur dann sinnvoll in einem elektronischen System abgebildet werden, wenn auch die entsprechenden Studien-Metadaten dort strukturiert dokumentierbar sind. Nur so können die erhobenen Daten nachhaltig, beispielsweise im Rahmen von Metastudien, genutzt werden. Ziel des weiteren Vorgehens war es daher, ergänzend zur Repräsentation von Studiendaten, auch die auf Archetypen basierende Repräsentation von Studien-Metadaten zu ermöglichen. Grundlage des Entwurfs von Archetypen für Studien-Metadaten war die Definition einer generischen Struktur, mit welcher sich nahezu alle klinischen Studien abbilden lassen. Hierzu wurde zunächst analysiert, welche Objekttypen im Rahmen einer klinischen Prüfung relevant sind, wie diese zueinander in Beziehung stehen und durch welche Merkmalsarten (=Studien-Metadaten) diese Objekttypen charakterisiert werden können. Um relevante Objekttypen und kennzeichnende Merkmalsarten zu identifizieren, wurde ein systematischer Vergleich aller Merkmalsarten durchgeführt, welche für das Deutsche Register Klinischer Studien (DRKS register.germanctr.de/drks) und für die International Clinical Trials Registry Platform (ICTRP apps.who.int/trialsearch) der Weltgesundheitsorganisation (WHO) erhoben werden. Zusätzlich wurden Merkmalsarten berücksichtigt, die im Koordinierungszentrum für Klinische Studien (KKS) Heidelberg ( zur Dokumentation der dort betreuten Studien erhoben werden. Die Liste der im KKS erhobenen Merkmalsarten war in einem iterativen Prozess über einen längeren Zeitraum hinweg etabliert worden. Alle Merkmalsarten und die jeweils vorgesehenen Ausprägungen aus diesen Quellen wurden in einer Tabelle zusammengefasst und gegenübergestellt. Basierend auf dieser tabellarischen Zusammenfassung von Merkmalsarten, wurden Gruppen von logisch zusammengehörigen Merkmalsarten identifiziert und eine generische Studienstruktur definiert. Darauf aufbauend wurden openehr-archetypen modelliert, mit denen konkrete Studien beschrieben werden können. Die zuvor erstellte, tabellarische Gegenüberstellung der studienbeschreibenden Merkmalsarten von WHO, DRKS und KKS wurde erweitert um Referenzen auf die entsprechenden Datenpunkte in den neu entwickelten Archetypen. Zur Modellierung der Archetypen wurde der Archetype Editor der Firma Ocean Informatics in der Version 2.1 eingesetzt. 3.5 Abbildung auf Standards Um zu prüfen, ob sich die gemäß Kapitel 3.4 entwickelten Archetypen tatsächlich zur Dokumentation von und in klinischen Studien eignen, wurde untersucht, inwieweit diese Archetypen mit in der klinischen Forschung etablierten Modellen und Standards harmonieren und sich auf diese abbilden lassen.

47 Vorgehen und Methodik 27 Studiendaten Als Ausgangspunkt für die Identifikation und Entwicklung von Archetypen zur Repräsentation von (medizinischen) Studiendaten waren die CDASH-Spezifikationen genutzt worden (vgl. Kapitel 3.4.1). Somit ist eine Abbildbarkeit auf CDASH gegeben und es waren keine weiteren Untersuchungen notwendig. Ergänzend wurde geprüft, wie die auf Archetypen basierende Repräsentation von Studiendaten und Studien-Metadaten im Operational Data Model (siehe Kapitel 2.7) abgebildet werden kann. Durch die Abbildung auf das ODM wird zumindest eine syntaktische Interoperabilität zwischen auf Archetypen basierenden SDMS und konventionellen Systemen im Umfeld klinischer Studien ermöglicht. Studien-Metadaten Ausgehend von den Archetypen für Studien-Metadaten wurde geprüft, an welchen Stellen im BRIDG-Modell (siehe Kapitel 2.7) sich die in den Archetypen definierten Merkmalsarten wiederfinden. Alle identifizierten Abbildungsmöglichkeiten wurden dabei in der tabellarischen Zusammenstellung der Studien-Metamerkmale ergänzt, welche in Vorbereitung der Entwicklung der Archetypen für Studien-Metadaten erstellt worden war (vgl. Kapitel 3.4). Zur Analyse und Darstellung der Archetypen sowie des BRIDG-Modells wurden die openehr ADL-Workbench (Version 1.4) bzw. der SPARX Enterprise Architect Light (Version 8.0) genutzt. Eine Einführung in das BRIDG-Modell lieferte der zugehörige User s Guide ([ANGELES, EVANS et al. 2010]). CDASH ODM BRIDG 3.6 Zusammenfassung des Vorgehens Um zu ermitteln, welche Anforderungen an Daten in Forschung und Versorgung gestellt werden und in wie weit eine wechselseitige, multiple Verwendung realisierbar ist, wurde eine Fallstudie durchgeführt. Hierbei wurden, einem zuvor definierten generischen Vorgehensmodell folgend, die im Heidelberger KIS dokumentierbaren und die in der ctag- Studie benötigten Merkmalsarten vollständig erfasst und beschrieben. In Vorbereitung einer multiplen Nutzung der KIS-Daten wurde geprüft, welche in der ctag-studie benötigten Informationen aus dem KIS extrahiert werden können. Das Opereffa-System, eine auf Archetypen basierende EPA, wurde dem Single-Source- Ansatz folgend zu einem rudimentären Studiendatenmanagementsystem (opensdms) erweitert. Hierbei wurden die prinzipielle Realisierbarkeit eines auf Archetypen basierenden SDMS sowie die damit verbundenen technischen Anforderungen geprüft. Aufbauend auf den Erkenntnissen aus Fallstudie und der Implementierung von opensdms wurde in einem iterativen Prozess eine Referenzarchitektur zur Anbindung verschiedener KIS an ein SDMS entwickelt und beschrieben. Um die entwickelte Referenzarchitektur realisieren zu können, werden geeignete Archetypen benötigt. Daher wurden Archetypen sowohl zur Dokumentation von Studiendaten als auch von Studien-Metadaten bereitgestellt. Hierzu wurden sowohl bestehende Archetypen genutzt und erweitert, als auch neue Archetypen speziell für das Studienumfeld entwickelt. In einem weiteren Schritt, wurden alle von den bereitgestellten Archetypen definierten Merkmalsarten auf die im Bereich der klinischen Forschung etablierten Modelle BRIDG, CDASH und ODM abgebildet. So wurde sowohl die Eignung der bereitgestellten Archetypen für den Einsatz im Studienumfeld geprüft, als auch deren Kompatibilität zu etablierten Modellen hergestellt.

48 28 Multiple Verwendung von Patientendaten unter Nutzung von Archetypen

49 Ergebnisse 29 4 Ergebnisse Im Folgenden werden die Ergebnisse beschrieben, welche sich aus den verschiedenen Untersuchungen und methodischen Ansätzen ergaben. Diese umfassen eine Fallstudie zur multiplen Verwendbarkeit von KIS-Daten, den Prototyp eines auf Archetypen basierenden SDMS, eine auf Archetypen basierende Referenzarchitektur zur Integration von Forschung und Versorgung sowie die Entwicklung von Archetypen für Studiendaten und Studien-Metadaten und die Verknüpfung dieser Archetypen mit etablierten Modellen im Bereich der klinischen Forschung. 4.1 Fallstudie Ziel der Fallstudie anhand der ctag-studie und des Heidelberger KIS (siehe Kapitel 3.2) war es, den Anteil der für die Studie multipel nutzbaren KIS-Daten zu ermitteln. Weiteres Ziel war es, Anforderungen an eine Referenzarchitektur zur Integration von Forschung und Versorgung abzuleiten. Dazu wurden insbesondere, die Anforderungen bezüglich Datenqualität und -formaten in Studie und KIS analysiert und verglichen. Die Datenerhebung für Forschung und Versorgung im Studienzentrum läuft wie folgt ab: Wenn ein Patient in die ctag-studie eingeschlossen wird, erhebt ein (Prüf-)Arzt die benötigten Daten im Rahmen der Aufnahme sowie direkt nach der Operation (OP). Weitere Daten werden während der Follow-Up-Visiten erhoben. Alle Daten werden in der Patientenakte bzw. wenn das Erfassen der jeweiligen Daten in der Patientenakte nicht oder nicht in der benötigten Form vorgesehen ist auf studienspezifischen Quelldatenbögen dokumentiert. Die Study Nurse überträgt die Daten dann in das ecrf-system und kontrolliert gleichzeitig die Vollständigkeit und Qualität der erfassten Daten. Gegebenenfalls recherchiert sie fehlende Daten in der elektronischen und papierbasierten Patientenakte oder erhebt diese, falls möglich, beim Patienten selbst. Anschließend kontrolliert der Prüfarzt die Eintragungen im ecrf und signiert diese (vgl. Abb. 4-1). Datenerhebung ctag-studie Abb. 4-1: Ablauf der Datenerhebung in der analysierten Studie (ohne eine multiple Nutzung von Datenelementen aus dem KIS).

50 30 Multiple Verwendung von Patientendaten unter Nutzung von Archetypen Teilweise werden dieselben Merkmalsarten redundant in verschiedenen Subsystemen des KIS dokumentiert. So finden sich beispielsweise die Haupt- und Nebendiagnosen eines Patienten sowohl im OP-Bericht, wie auch im Bericht des Aufwachraums, im Bericht der Intermediate-Care-Station und im Entlassbrief. Dabei treten mitunter Inkonsistenzen zwischen den einzelnen Dokumenten auf. Dies erschwert die Arbeit der Study Nurse bei der Recherche nach den Studienmerkmalen. Abb. 4-2: Verteilung der Ausprägungstypen der 1452 im KIS dokumentierbaren Merkmalsarten (elektronisch und konventionell). Abb. 4-3: Verteilung der Ausprägungstypen der 200 Merkmalsarten der ctag-studie.

51 Ergebnisse 31 Im Anschluss an die Analyse der Abläufe bei der Datenerhebung im Studienzentrum wurden gemäß des generischen Vorgehensmodells für die multiple Nutzung von Daten in Forschung und Versorgung (siehe Kapitel 3.1) die im KIS erfassbaren sowie die in der ctag-studie benötigten Merkmalsarten systematisch analysiert und einander gegenübergestellt. Zur Identifikation und Beschreibung der im KIS dokumentierbaren Merkmalsarten musste die Dokumentation von insgesamt vier in die ctag-studie eingeschlossenen Patienten analysiert werden. Bei der Analyse der Dokumentation des vierten Patienten zeigte sich, dass die Menge der identifizierten Merkmalsarten saturiert war. Die Gruppe der zufällig ausgewählten Patienten setzten sich zusammen aus einer Frau und einem Mann zwischen 40 und 50 Jahren sowie einer Frau und einem Mann zwischen 70 und 80 Jahren. In welchen Formaten werden die Merkmalsarten im KIS dokumentiert? Im Heidelberger KIS wurden 1452 Merkmalsarten identifiziert, zu welchen in 1138 Fällen (78,4 %) auch Ausprägungen dokumentiert worden waren. Mehr als die Hälfte der Merkmalsausprägungen (762 / 52,5 %) lagen elektronisch vor. Bei den KIS-Datenelementen werden die Ausprägungen bei 306 Merkmalsarten (21,1 %) durch die Selektion eines Wertes aus einer Auswahlliste erfasst; bei ähnlich vielen Merkmalsarten (300 / 20,7 %) werden die Ausprägungen in Form von Freitexten erfasst, in 253 Fällen (17,4 %) als Ganzzahl, in 248 Fällen (17,1 %) als Ja/Nein -Felder. Die restlichen Merkmalsarten teilen sich wie folgt auf: Gleitkommazahlen 116 Merkmalsarten (8,0 %), Datumsangaben 107 Merkmalsarten (7,4 %), Angaben von Uhrzeiten 49 Merkmalsarten (3,4 %) sowie codierte Merkmalsausprägungen bei 44 Merkmalsarten (3,0 %). In 29 Fällen (2,0 %) konnte der Typ der Ausprägung mittels der Aktenanalyse nicht eindeutig bestimmt werden. Dabei handelte es sich ausschließlich um Merkmalsarten, zu welchen keine Ausprägungen in den Subsystemen des KIS dokumentiert worden waren vgl. Abb Anhand der ecrf der ctag-studie und der zugehörigen Studiendatenbank wurden die für die Studie zu erhebenden Merkmalsarten analysiert. Tab. 4-1 gibt eine Übersicht der in der ctag-studie vorgesehenen Visiten, der jeweils ausgefüllten ecrf sowie der Zahl der mit den einzelnen ecrf erhobenen Merkmalsarten. Das ecrf zur Dokumentation von unerwünschten Ereignissen (Adverse Event) wird nur bei Bedarf eingesetzt. Zu jedem unerwünschten Ereignis werden mit diesem ecrf 30 Merkmalsarten erhoben. Bei der ctag-studie werden in der Regel acht ecrf je Patient ausgefüllt. Dies geschieht im Rahmen von sechs Visiten. Bei der registration visit wird neben einem Registrierungsbogen und einem allgemeinen ecrf ein spezielles ecrf ausgefüllt, je nachdem, welche Indikation eine ctag-implantation notwendig machte ( Aneurysm, Traumatic Transaction, Dissection bzw. Other Aortic Pathologies vgl. Tab. 4-1). Samt des ecrf für unerwünschte Ereignisse besteht die Studie somit aus insgesamt 10 verschiedenen Datenerhebungsbogen. In welchen Formaten werden die Merkmalsarten in der Studie dokumentiert? Bei der Datenbestandsanalyse wurden 200 Merkmalsarten identifiziert, die im Rahmen der ctag-studie erhoben werden. Von den identifizierten Merkmalsarten in der Studie werden in 79 Fällen (39,5 %) die Ausprägungen als Ja/Nein -Felder erfasst, in 49 Fällen (24,5 %) als Ganzzahl-Werte und in 38 Fällen (19,0 %) durch die Selektion eines Wertes aus einer Auswahlliste. Die verbleibenden 34 Merkmalsarten (17,0 %) verteilen sich auf Datumsangaben (18 Merkmalsarten / 9,0 %), Freitextangaben (13 Merkmalsarten / 6,5 %) sowie Uhrzeitangaben, codierte Merkmalsausprägungen und Gleitkommazahlen (je 1 Merkmalsart / 0,5 %) vgl. Abb KIS Heidelberg ctag-studie

52 32 Multiple Verwendung von Patientendaten unter Nutzung von Archetypen Tab. 4-1: Übersicht der in der ctag-studie verwendeten ecrf und der vorgesehenen Visiten. Wird ein ecrf bei einer Visite ausgefüllt, ist angegeben, wie viele Merkmalsarten bei dieser Visite mit dem jeweiligen ecrf erhoben werden. ecrf: Visite: Registration visit Intervention visit Follow-Up 1 Follow-Up 2 Follow-Up 3 Close-out visit Subject Registration 3 Pre- Treatment 38 Aneurysm 14 Traumatic Transaction 14 Dissection 17 Other Aortic Pathologies 17 Treatment 50 Follow-Up End of Trial 12 Adverse Event Wie hoch wäre der Anteil der Daten, der heute schon aus dem KIS für eine konkrete Studie übernommen werden könnte? Von den 200 Merkmalsarten, die für die ctag-studie erhobenen werden, könnten die vier Merkmalsarten Alter, Geschlecht, Gewicht und Operation als Notfall (2,0 %) direkt aus den elektronischen Subsystemen des KIS übernommen werden. Indem geeignete Transformationen zwischengeschaltet werden, würde es möglich 12 weitere Datenelemente pro Proband (6,0 %) aus dem KIS zu übernehmen. Weitere 23 (11,5 %) der für die Studie benötigten Merkmalsarten liegen im KIS als wenig strukturierte Informationen in Freitextelementen vor. Diese könnten gegebenenfalls mit Hilfe von Textmining-Algorithmen extrahiert werden (vgl. Abb. 4-4). Wie hoch wäre dieser Anteil, wenn das KIS vollständig rechnerunterstützt wäre? Darüber hinaus stünden 29 Merkmalsarten (14,5 %) zur Verfügung, wenn diese nicht konventionell, sondern elektronisch im KIS dokumentiert würden. Von diesen 29 Merkmalsarten wären wiederum nur 4 (2,0 % der in der ctag-studie zu erhebenden Merkmalsarten) direkt nutzbar. Ausgehend von der aktuellen papierbasierten Dokumentation müssten 16 dieser 29 Merkmalsarten vor einer multiplen Verwendung ebenfalls transformiert werden. Bei 9 dieser 29 Merkmalsarten wäre ein Textmining notwendig. Zwei Datenelemente (1,0 %) ein konventionelles und ein elektronisches könnten nach einer entsprechenden Transformation zusätzlich genutzt werden, wenn zu diesen tatsächlich Ausprägungen im KIS dokumentiert worden wären.

53 Ergebnisse 33 Abb. 4-4: Ergebnis der Analyse, welcher Anteil der 200 in der ctag-studie benötigten Merkmalsarten im KIS dokumentiert werden kann und unter welchen Voraussetzungen eine multiple Nutzung möglich bzw. nicht möglich ist. Lägen alle Datenelemente im KIS elektronisch vor und würde zu allen vorgesehenen und für die Studie relevanten Merkmalsarten eine Ausprägung dokumentiert werden, könnten insgesamt 70 Datenelemente (35,0 %) für die ctag-studie multipel genutzt werden. Abb. 4-5 stellt dar, welche Anteile dieser 70 Merkmalsarten im KIS vor einer Übernahme in ein ecrf der ctag-studie wie transformiert werden müssten. So könnten 8 der 70 Datenelemente (11,4 %) direkt 1:1 übernommen werden. Bei 30 Merkmalsarten (42,9 %) müsste eine geeignete Transformation zwischengeschaltet werden. Bei weiteren 32 Merkmalsarten (45,7 %) wäre ein Textmining notwendig. In der ctag-studie werden 21 dieser 32 Merkmalsarten mit Hilfe von Ja/Nein -Feldern erfasst, 3 Merkmalsarten als Ganzzahl -Werte und 7 Merkmalsarten als Auswahl: 1 aus n. Eine dieser Merkmalsarten wird zwar in der Studie ebenfalls als Freitext erhoben, dennoch wäre auch in diesem Fall eine Transformation in Form eines Textminings notwendig, um unnötige Textelemente zu entfernen. Abb. 4-5: Verteilung der notwendigen Transformationen, falls alle 70 der im KIS vorhandenen und für die ctag Studie relevanten Merkmalsarten im KIS elektronisch vorlägen.

54 34 Multiple Verwendung von Patientendaten unter Nutzung von Archetypen Über drei Viertel der 70 potenziell wiederverwendbaren Datenelemente im KIS könnten der papierbasierten Präsenzakte (53 Merkmalsarten / 75,7 %) entnommen werden. Dabei könnten mindestens 30 dieser 53 Datenelemente aus dem in der Präsenzakte abgelegten, papierbasierten OP-Bericht extrahiert werden. Darüber hinaus werden bestimmte Merkmalsarten wie zum Beispiel Diagnosen im OP-Bericht und in allen Arztbriefen aufgeführt. Aus dem i.s.h.med könnten 14 Datenelemente (20,0 %) und aus dem Radiologieinformationssystem 3 Datenelemente (4,3 %) multipel genutzt werden vgl. Abb Einige Merkmalsarten sind mehrfach in verschiedenen Subsystemen verfügbar (beispielsweise Diagnosen oder Laborbefunde). Daher könnten in bestimmten Fällen auch CareVue oder die Ambulanzakte potenziell als Datenquellen genutzt werden. Abb. 4-6: Verteilung der 70 Merkmalsarten, die für die ctag- Studie multipel genutzt werden könnten, auf die elektronischen und konventionellen Subsysteme des KIS. Schritt 1 Weitere 12 der in der Studie benötigten Merkmalsarten (6,0 %) könnten ebenfalls automatisch ermittelt werden. Einerseits könnten hierzu Systeminformationen genutzt werden (beispielsweise das aktuelle Datum oder der des angemeldeten Benutzers). Andererseits könnten die benötigten Informationen auch aus zuvor erfassten Studiendaten abgeleitet werden (so zum Beispiel die Gesamtzahl der eingesetzten Stents als Summe der Anzahlen der eingesetzten Stents unterschiedlichen Typs). Insgesamt könnten auf diese Weise 82 Datenelemente (41,0 %) multipel verwendet werden. In der Fallstudie wurden, dem generischen Vorgehensmodell gemäß Kapitel 3.1 folgend, 1452 Merkmalsarten des Heidelberger KIS und 200 in der ctag-studie zu erhebenden Merkmalsarten erfasst und analysiert. Dabei zeigte sich, dass dieses Vorgehen sehr arbeitsintensiv werden kann. Daher sind rechnerbasierte Werkzeuge wünschenswert, die helfen, die einzelnen Arbeitsschritte zu vereinfachen und zu beschleunigen. Im Folgenden werden die Anforderungen an entsprechende Werkzeuge bezogen auf die einzelnen Arbeitsschritte (vgl. Kapitel 3.1) aufgelistet: Erfassung der verfügbaren Merkmalsarten (KIS) Systematisches Erfassen aller Merkmalsarten, die im KIS typischerweise zu einem bestimmten Patientenkollektiv dokumentiert werden können: Ein unterstützendes System sollte dabei in der Lage sein, die einzelnen KIS-Merkmalsarten jeweils samt beschreibender Meta-Merkmale, zum Beispiel Datentyp und mögliche Ausprägungen, strukturiert in einer Datenbank zu erfassen. Neben einrichtungs- bzw. systeminterner Benennung sollte jeweils auch eine Bezeichnung gemäß einer standardisierten Terminologie erfassbar sein. Dies kann die Suche nach geeigneten Zuordnungen vereinfachen Schritt 3 des Vorgehensmodells. Zusätzlich wäre es sinnvoll, Informationen darüber zu erfassen, mit welchem Verfahren ein

55 Ergebnisse 35 Datenelement im KIS erhoben wird. So kann abgeschätzt werden, wie verlässlich eine dokumentierte Ausprägung ist. Ferner sollte auch der zeitliche Kontext der Erfassung eines Datenelements innerhalb des Behandlungsprozesses geeignet dokumentiert werden (vgl. [DORDA, GALL et al. 2002]). Erfassung der benötigten Merkmalsarten (Studie) Systematisches Erfassen aller Merkmalsarten sowie deren Meta-Merkmale, die in der Studie bzw. für die jeweilige Auswertungsfrage benötigt werden: Dies erfolgt analog zur Erfassung der im KIS dokumentierten Merkmalsarten im vorhergehenden Schritt. Zuordnung geeigneter Merkmale Ermitteln geeigneter Zuordnungen von Merkmalsarten im KIS zu den für die Studie bzw. Auswertungsfrage benötigten Merkmalsarten: Das System soll hierbei die Suche nach geeigneten Abbildungen unterstützen. So könnten beispielsweise basierend auf den erfassten Meta-Merkmalen geeignete Zuordnungen automatisch vorgeschlagen werden. Ein angeschlossenes medizinisches Terminologiemanagementsystem könnte dabei unterstützen, korrespondierende Merkmalsarten auch dann anhand deren Bezeichnungen zu identifizierend, wenn synonyme Bezeichnungen verwendet wurden. Über die Unterstützung bei der Identifikation der Merkmalsarten hinaus sollte das System in der Lage sein, die ermittelten Zuordnungen strukturiert abzuspeichern. Trotz Unterstützung beim Finden geeigneter Abbildungen, wird der Aufwand für diesen Schritt je nach Umfang der jeweiligen Studie nicht unerheblich sein. Indem Zuordnungen abgespeichert werden, können diese selbst multipel genutzt und so Aufwand eingespart werden beispielsweise dann, wenn in Studien in einem medizinischen Fachgebiet immer wieder dieselben Merkmalssätze erhoben werden. Direkte Zuordnungen der Merkmalsarten im KIS zu für die Studie bzw. Auswertungsfrage benötigten Merkmalsarten sind nicht immer möglich. Im untersuchten Fall waren direkte Abbildungen nur in 8 Fällen (11,4 % der 70 nutzbaren Merkmalsarten im KIS) der identifizierten Zuordnungen möglich. Sehr häufig müssen daher geeignete Transformationen zwischengeschaltet werden, um die im Rahmen einer Zuordnung vorgesehene multiple Nutzung erst zu ermöglichen. Wünschenswert wäre hier ein System, welches es erlaubt, entsprechende Transformationen zu definieren und ergänzend zu den erfassten Zuordnungen ebenfalls strukturiert abzuspeichern. Auf diese Weise könnten neben den Daten nicht nur die Zuordnungen multipel genutzt werden, sondern auch die hierzu benötigten Transformationen. Implementierung Implementierung der identifizierten Zuordnungen und Transformationen: Falls ein Single- Source-Ansatz oder eine durch pre-population unterstützte Datensammlung in einem eigenständigen SDMS vorgesehen ist, müssen gegebenenfalls das KIS erweitert oder entsprechende Schnittstellen zwischen den beteiligten Systemen geschaffen werden. Das unterstützende Werkzeug sollte die Implementierung entsprechender Schnittstellen samt gegebenenfalls notwendigen Transformationen basierend auf den zuvor erfassten Zuordnungen und Transformationsvorschriften automatisieren oder zumindest vereinfachen. Schritt 2 Schritt 3 Schritt Prototyp Mit dem open Study Data Management System (opensdms) wurde exemplarisch ein auf Archetypen basierendes System zur Integration von Forschung und Versorgung entwickelt. Diese Entwicklung bildete die Grundlage für die Ableitung weiterer (technischer) Anforderungen an eine auf Archetypen basierende Systemarchitektur zur Integration von Forschung und Versorgung.

56 36 Multiple Verwendung von Patientendaten unter Nutzung von Archetypen OpenSDMS basiert auf dem openehr Reference Framework and Application (Opereffa) System (siehe Kapitel 3.3). OpenSDMS wurde so implementiert, dass zusätzlich zu der von Opereffa bereitgestellten Funktionalität einer EPA (siehe Abb. 4-7) die Möglichkeit besteht, basierend auf Archetypen Studien abzubilden (Erfassen von Studien-Metadaten) und Studiendaten zu den vorhandenen Patienten zu erheben. Hierzu wurden zwei neue Sichten generiert: Studie / CRF (siehe Abb. 4-8) und Studie / Metadaten (siehe Abb. 4-9). In der Ansicht Studie / CRF können nicht nur Studiendaten zu einem Patienten erfasst werden, sondern auch geeignete Daten, die zuvor in der Patientenakte von opensdms erfasst wurden, per Klick in das CRF übernommen werden. Somit müssen nur noch die Studiendaten manuell erfasst werden, die nicht aus der EPA übernommen werden können. Die einzelnen Abläufe bei der Nutzung von opensdms werden in Anhang 5 detailliert beschrieben. In der Ansicht Studie / Metadaten können alle Daten erfasst werden, welche Studie, Studienarme und Visiten beschreiben also beispielsweise der oder das Akronym einer Studie. Da auch die Studien-Metadaten durch hierfür entwickelten Archetypen (vgl. Kapitel 4.4.2) repräsentiert werden, können systemintern zum Speichern der Studien- Metadaten dieselben Mechanismen genutzt werden wie zum Speichern der Studiendaten. Anstelle der Patienten-Identifikationsnummern wird für Studien-Metadaten in der EAV- Tabelle eine Studien-Identifikationsnummern gekennzeichnet. Patienten-Identifikationsnummern und Studien-Identifikationsnummern werden in getrennten Listen verwaltet, um diese unterscheiden zu können. Da in der EAV-Tabelle jedoch technisch nicht zwischen Daten von Patienten und Studien unterschieden wird, muss jedes Element der Vereinigungsmenge aus Patienten-Identifikationsnummern und Studien-Identifikationsnummern von den übrigen Elementen verschieden sein. Jedes Element muss eindeutig einen Patienten oder eine Studie identifizieren. Abb. 4-7: In der Ansicht Patientenakte von opensdms können Daten aus der Routineversorgung eines Patienten erfasst, eingesehen und falls notwendig verändert werden.

57 Ergebnisse 37 Abb. 4-8: In der Ansicht Studie / CRF von opensdms können Studiendaten zu einem Patienten erfasst, eingesehen und korrigiert werden. Ferner ist es möglich, Daten aus der EPA des Patienten in eine Studie zu übernehmen. Abb. 4-9: In der Ansicht Studie / Metadaten von opensdms können Studien-Metadaten erfasst, eingesehen und verändert werden.

58 38 Multiple Verwendung von Patientendaten unter Nutzung von Archetypen Die systeminterne Datenhaltung ist als Single-Source-Lösung realisiert. Studiendaten werden physisch auf dieselbe Art und Weise gespeichert wie Einträge in der EPA. Dementsprechend werden studienbezogene Einträge zu einem Patienten automatisch auch in dessen EPA angezeigt. Daten aus der EPA werden durch eine logische Verknüpfung einer bestimmten Studie, einem Studienarm und einer darin vorgesehenen Visite zugeordnet und so als Studiendaten gekennzeichnet. Zur Implementierung dieser Funktionalität wurde die originale EAV-Tabelle von Opereffa um drei zusätzliche Spalten erweitert. Entsprechend der generischen Studienstruktur (vgl. Kapitel 4.4.2) können in opensdms zu einem Element zusätzlich zu Patienten-ID, Archetypen-Bezeichner und Pfad sowie eigentlichem Wert auch Eine Studien-ID, die ID eines Studienarms und die ID einer Visite gespeichert werden. So kann ein Element eindeutig einem bestimmten Erhebungszeitpunkt innerhalb einer Studie zugeordnet werden. Bei Daten, die lediglich im Rahmen der Funktionalität des Systems als Patientenakte dokumentiert wurden, bleiben die zusätzlichen Spalten leer. Da sowohl EPA- als auch Studiendaten von denselben Archetypen beschrieben werden, kann direkt ermittelt werden, welche der in der EPA vorhandenen Daten in einer Studie multipel nutzbar sind. In der EPA von opensdms muss lediglich nach Daten gesucht werden, die auf demselben Archetyp basieren wie das jeweilige Feld im CRF. Zur Strukturierung der Daten nutzt opensdms das Konzept der openehr-folders (siehe Kapitel 2.6). Die Struktur einer Studie (Anzahl der Arme, Anzahl der Visiten je Arm, zu erfassende Daten innerhalb der Visite) werden innerhalb von opensdms über eine spezielle XML-Datei (structure.xml) konfiguriert. Im Gegensatz zum statisch konfigurierten Opereffa ist es in opensdms auch möglich, über diese XML-Datei die Struktur der EPA-Komponente zu konfigurieren (vgl. Abb. 3-2). Bei jedem Start von opensdms wird die Datei structure.xml gegen die korrespondierende Schema-Datei structure.xsd validiert. Um die Zuordnung von Patienten zu einer Studie im System speichern zu können (M:N- Relation), wurde für opensdms in der Opereffa Datenbank eine zusätzliche Tabelle angelegt (patient_trial), welche diese M:N-Relation abbildet. Anwendungsszenarien von opensdms OpenSDMS kombiniert die Funktionalität einer EPA und eines SDMS und ermöglicht so die multiple Verwendung von Daten aus der EPA in Studien. Neben der Nutzung von opensdms als eigenständiges System (Stand-Alone-System) ist es auch denkbar, Daten aus anderen KIS, mit Hilfe geeigneter Mechanismen in die EPA von opensdms zu importieren (Integrationssystem). Das Szenario Integrationssystem wäre in multizentrischen Studien hilfreich, um die in den KIS der beteiligten Zentren vorhandenen Daten für eine multiple Nutzung zusammenzuführen (siehe Abb. 4-10). Die EPA von opensdms würde dabei nur noch als Zwischenspeicher für die KIS-Daten der angeschlossenen Studienzentren genutzt, um diese Daten für eine multiple Nutzung anbieten zu können. Die manuelle Datenerfassung in der EPA von opensdms entfiele. Der Anwender würde nur noch die SDMS Funktionalität nutzen, um importierte Daten in die Studie zu übernehmen oder um Studiendaten manuell zu ergänzen. Ein echter Single-Source-Ansatz wäre dabei aber nicht realisierbar, da die Quelldaten in ihren Quellsystemen in den einzelnen Studienzentren und die Studiendaten hiervon getrennt in opensdms erfasst würden.

59 Ergebnisse 39 Abb. 4-10: Datenflüsse bei der Nutzung von opensdms als Integrationssystem, welches die multiple Nutzung von Daten aus verschiedenen KIS für Studienzwecke erlaubt (hierzu müsste opensdms um geeignete Import-Schnittstellen erweitert werden). 4.3 Referenzarchitektur Anforderungen an die Referenzarchitektur Basierend auf den Erkenntnissen aus der Fallstudie und der Entwicklung von opensdms ergeben sich folgende Anforderungen an eine Referenzarchitektur zur Integration von KIS und SDMS. Dabei werden besonders auch multizentrische Studien berücksichtigt. Zu den in einem KIS dokumentierbaren Merkmalsarten müssen semantische Beschreibungen vorliegen. Ist dies nicht gegeben, sollten Werkzeuge verfügbar sein, die das Erstellen eines Katalogs von semantischen Beschreibungen der in einem KIS dokumentierbaren Merkmalsarten unterstützen. In verschiedenen KIS vorhandene Daten müssen strukturiert und über eine einheitliche Schnittstelle zugreifbar sein. Nur so ist es möglich, die für eine multiple Nutzung potenziell geeigneten KIS-Daten aufzulisten. Diese Schnittstelle muss auch sehr feingranulare und komplexe Abfragen zulassen, wie zum Beispiel liefere alle systolischen Blutdruckwerte des aktuellen Patienten, welche innerhalb der letzten 3 Stunden durch invasive arterielle Messung ermittelt wurden. Je exakter Daten im KIS ausgewählt werden können, desto besser. Die Menge der gefundenen Daten wird so in der Regel kleiner. Die Wahrscheinlichkeit, dass ein im KIS gefundenes Datenelement tatsächlich in der jeweiligen Studie nutzbar ist, wächst. Der Aufwand des Prüfarztes oder der Study Nurse beim Prüfen und Auswählen der für die Studie geeigneten Datenelemente sinkt. Während in KIS Patienten meist über Ihren und Geburtsdatum identifiziert werden, werden die Probanden in SDMS üblicherweise über ein Pseudonym identifiziert. Wenn eine Schnittstelle genutzt werden soll, um Daten aus einem KIS in ein SDMS zu übernehmen, muss diese Schnittstelle in der Lage sein, das Pseudonym eines Patienten im SDMS in die korrekte Patienten-ID des KIS zu überführen und umgekehrt. Soweit möglich sollten zu den einzelnen KIS-Daten Kontextinformationen (beispielsweise zum Vorgehen oder den eingesetzten Geräten bei der Datenerhebung) abrufbar sein. Diese sind notwendig, um entscheiden zu können, ob ein Datenelement aus dem KIS tatsächlich für die multiple Nutzung in einer Studie geeignet ist.

60 40 Multiple Verwendung von Patientendaten unter Nutzung von Archetypen Im SDMS müssen Studiendaten hoch strukturiert dokumentiert werden, um für exakt definierte Auswertungsfragen bzw. Analyseverfahren nutzbar zu sein. Neben Studiendaten sollte das SDMS auch in der Lage sein, Studien-Metadaten wie Studientitel, Indikation oder Ein-/Ausschlusskriterien strukturiert zu erfassen. Ferner wäre es wünschenswert auch den Satz der Studien-Metadaten bei Bedarf ähnlich flexibel wie ein ecrf erweitern zu können. Die Definition der ecrf im SDMS (= Definition der zu erhebenden Studiendaten) muss so gestaltet sein, dass einzelne Datenelemente und ganze ecrf in verschiedenen Studien wiederverwendet werden können. Wenn in zwei Studien die gleiche Merkmalsart erhoben werden soll, muss gewährleistet werden, dass hierfür dieselbe, eindeutige Elementdefinition verwendet wird. Die Definition der zu erhebenden Studiendaten im SDMS und die Schnittstelle zum Zugriff auf im KIS gespeicherte Daten, müssen derselben Systematik folgen. So können teilweise aufwändige Transformationen bei der Übernahme von KIS-Daten in das SDMS vermieden werden. Werden KIS-Daten in ein SDMS übernommen, müssen neben den eigentlichen Daten auch Kontextinformationen wie Quellsystem und Erhebungsmethode in das SDMS übernommen werden können. Indem das Quellsystem (KIS) eines ins SDMS importierten Datenelements bis auf Subsystemebene eindeutig identifizierbar bleibt, werden regulatorische Anforderungen erfüllt (siehe folgenden Abschnitt). Ebenso wird ein späterer Quelldatenabgleich erleichtert. Wurden KIS-Daten in ein SDMS übernommen, können nachfolgende Änderungen der Daten in KIS oder SDMS zu Inkonsistenzen mit dem jeweils anderen System führen. Daher sind technische und organisatorische Maßnahmen notwendig, die dafür sorgen, dass solche Inkonsistenzen vermieden bzw. erkannt und beseitigt werden. Unabhängig von der technischen Realisierung eines SDMS sollte es möglich sein, Studiendaten von jedem Rechner mit Internetzugang mittels Webschnittstelle und ohne die Installation zusätzlicher Softwarekomponenten zu erfassen. Ferner sollte es auf diese Art auch möglich sein, Daten aus KIS, welche an das SDMS angeschlossen sind, in eine Studie zu übernehmen. Auf diese Weise lassen sich Kollisionen zwischen den Voraussetzungen zur Nutzung des SDMS und den Sicherheits- und Firewall-Richtlinien in den einzelnen Studienzentren vermeiden. Ist beispielsweise die Installation einer speziellen Zugangssoftware oder der Aufbau eines virtuellen privaten Netzwerks (VPN) notwendig, um das SDMS nutzen zu können, kann dies den Einsatz des Systems in manchen Studienzentren erschweren. Trotz der zu Recht meist sehr restriktiven Firewall-Konfigurationen und Sicherheitsrichtlinien in Gesundheitsversorgungseinrichtungen, ist ein Zugriff auf Web-Seiten in der Regel jedoch problemlos möglich. Eine Referenzarchitektur zur Verknüpfung von KIS und SDMS sollte etablierte Modelle wie CDASH, BRIDG und ODM soweit möglich integrieren. So wird eine Kompatibilität zu bestehenden Systemen, welche diese Modelle implementieren, ermöglicht. Regulatorische Anforderungen Ergänzend zur durchgeführten Fallstudie und der Entwicklung von opensdms wurde geprüft, welche regulatorischen Anforderungen an Systeme zur Integration von Forschung und Versorgung gestellt werden. Hierbei wurde von den Anforderungen ausgegangen, die generell an Systeme gestellt werden, mit welchen studienbezogene Daten verarbeitet werden. Solche Anforderungen ergeben sich aus den Richtlinien 2001/20/EG und 2005/28/EG der Europäischen Union, welche wiederum die Good Clinical Practices (Note for Guidance on Good Clinical Practices CPMP/ICH/135/95 [ICH 2002]) referenzieren und konkretisieren. In Deutschland setzen das Arzneimittelgesetz und die GCP-Verordnung diese Richtlinien in nationales Recht um. Die Einhaltung der GCP wird darüber hinaus immer öfter auch bei öffentlichen Ausschreibungen als Voraussetzung für eine Förderung gefordert. Eine gute Zusammenfassung der technischen Anforderung an studiendatenverarbeitende elektronische

61 Ergebnisse 41 Systeme, die sich aus den europäischen Richtlinien ergeben, liefert ([EMA 2010]). In den Vereinigten Staaten von Amerika hat die dort zuständige Food and Drug Administration ihre Erwartungen auf ähnliche Weise zusammengefasst ([FDA 2010]). Die von EMA und FDA genannten Anforderungen sind dabei im Wesentlichen deckungsgleich. Aus [ICH 2002] als Grundlage und [EMA 2010] ergeben sich für computerbasierte SDMS und KIS vor allem folgende Anforderungen: Die eingesetzten Systeme und ihre Schnittstellen müssen validiert sein. Es muss ein Audit-Trail geführt werden, der es erlaubt jede Änderung und somit die gesamte Historie der Datenerfassung in ihrer originalen Chronologie nachzuvollziehen. Jederzeit muss eindeutig und verlässlich nachvollziehbar sein, wer wann welche Daten eingetragen bzw. wie und warum geändert hat. Darüber hinaus müssen in allen KIS, in denen Daten von Patienten verarbeitet werden, die an entsprechenden klinischen Studien teilnehmen, die folgenden Eigenschaften nach [EMA 2010] in Bezug auf Quelldaten (englisch: source data) gewährleistet sein. Die Daten müssen o o o o genau bzw. fehlerfrei sein, mindestens in gleichen Maß wie bei der papierbasierten Erhebung unmittelbar lesbar und für einen Menschen zum Zeitpunkt der Ein- und Ausgabe verständlich sein gleichzeitig mit der Beobachtung erfasst werden original in dem Sinn sein, dass es sich um den ursprünglich erzeugten Datensatz handelt o zuordenbar sein. Das bedeutet, dass eine Aktion etwa eine Dateneingabe eindeutig der ausführenden Person, zum Beispiel einem Arzt oder einer Pflegekraft, zuordenbar sein muss. Gleichzeitig muss durch geeignete Maßnahmen wie beispielsweise der Eingabe von Benutzername und Passwort sichergestellt sein, dass diese Aktion tatsächlich von der angegebenen Person durchgeführt wurde. o o o o vollständig sein einheitlich und widerspruchsfrei sein dauerhaft und sicher gespeichert sein sowie bei Bedarf verfügbar sein Spezifikation der Referenzarchitektur Ausgehend von den in Kapitel genannten Anforderungen und basierend auf den Erkenntnissen aus der Fallstudie sowie der Planung und Entwicklung von opensdms konnte eine auf Archetypen basierende Referenzarchitektur zur Integration von Forschung und Versorgung spezifiziert werden. Systeme, die gemäß dieser Architektur implementiert werden, ermöglichen es, Daten aus Krankenhausinformations- und Studiendatenmanagementsystemen multipel zu nutzen. Die einzelnen Komponenten der spezifizierten Referenzarchitektur sowie das Zusammen-wirken dieser Komponenten werden im Folgenden detailliert beschrieben. Als Beispiel wird dazu ein Szenario gewählt, in welchem die KIS-Daten aus zwei Studienzentren (KIS A und KIS B) für eine multiple Nutzung in das SDMS der Studienzentrale importiert werden. Um die Unterschiede beim Import aus auf Archetypen basierenden und aus nicht auf Archetypen basierenden KIS darzustellen, wird angenommen, dass nur KIS B auf Archetypen basiert (vgl. Abb. 4-11).

62 42 Multiple Verwendung von Patientendaten unter Nutzung von Archetypen Abb. 4-11: Auf Archetypen basierende Referenzarchitektur für die multiple Nutzung von KIS-Daten in klinischen Studien. ODM mit Referenzen auf Archetypen Der spezifizierten Architektur folgend können prinzipiell beliebig viele KIS an ein SDMS angebunden werden. Ebenso wäre es möglich die Daten der angeschlossenen KIS für eine multiple Nutzung in verschiedene SDMS in unterschiedlichen Studienzentralen zu importieren. Die vorgeschlagene Referenzarchitektur ist so aufgebaut, dass je nach Situation und je nachdem ob bereits vorhandene Systeme auf Archetypen basieren oder nicht, die benötigten Komponenten ausgewählt werden können. Die zentralen Komponenten der Architektur bilden das SDMS und das Archetypen-Repository. Nachfolgend wird zunächst der Aufbau des SDMS näher betrachtet. Ein wesentlicher Bestandteil der vorgeschlagenen Referenzarchitektur ist die Erweiterung des Operational Data Model (vgl. Kapitel 2.7) um semantische Beschreibungen der einzelnen Datenelemente mit Hilfe von Referenzen auf Archetypen. Dazu wird der im ODM enthaltene Alias-Mechanismus genutzt, der es erlaubt, die Beschreibung von sämtlichen ODM-Elementen (vor ODM-Version nur von ItemDefs und ItemGroupDefs) um zusätzliche Bezeichnungen zu ergänzen. Ein Alias setzt sich dabei zusammen aus einer Kontextangabe (Context), welche den Anwendungsbereich für den jeweiligen Alias spezifiziert und dem eigentlichen Aliasname () vgl. [CDISC 2010b] Kapitel Der Referenzarchitektur folgend, wird eine mit Archetypen annotierte ODM- Datei genutzt, um die Struktur der Studie und die ecrf samt den zu erhebenden Datenelementen im SDMS zu definieren.

63 Ergebnisse 43 [ ] <ItemDef OID="ID.ANYCONMED" ="Any Concomitant Medications" DataType="text" Length="1"> <Description> <TranslatedText xml:lang="en"> Any Concomitant Medications </TranslatedText> </Description> <Question> <TranslatedText xml:lang="en"> Is the Subject taking any Concomitant Medications? </TranslatedText> </Question> <Alias Context="Archetype" ="COMPOSITION.cdash_cm.v1/ context/other_context/items[at0010]/ value/value"/> <CodeListRef CodeListOID="CL.YESNO"/> </ItemDef> [ ] Abb. 4-12: Beispiel für die Nutzung des ODM-Alias-Mechanismus zur semantischen Annotation mit Hilfe eines Archetypen. Abb veranschaulicht die Nutzung des ODM-Alias-Mechanismus zur semantischen Annotation mit Hilfe eines Archetypen am Beispiel der in klinischen Studien typischen Frage nach Begleitmedikationen (eine umfangreichere ODM-Datei mit weiteren semantischen Annotationen findet sich in Anhang 4). Der Kontext des Alias wurde mit Archetype benannt und als der Verweis auf die entsprechende Merkmalsart im Archetyp COMPOSITION.cdash_cm.v1 angegeben. Dieser Verweis setzt sich zusammen aus Archetyp- und Pfadangabe innerhalb des Archetypen. Gemäß den openehr-spezifikationen kann aus dem n des Archetypen auf das zugrundeliegende Referenzmodell (hier openehr-ehr ) geschlossen werden. Somit ist das dargestellte ODM-Element mit Hilfe des Archetyps COMPOSITION.cdash_cm.v1 durch den Alias eindeutig semantisch beschrieben. Der Archetyp definiert das ODM-Element als Indikator, welcher anzeigt, ob der jeweilige Studienpatient parallel zur Studie eine gemäß Studienprotokoll relevante Medikation bzw. Therapie erhalten hat. Alternativ zur direkt ODM-basierten Definition der einzelnen ecrf-seiten könnte ferner das openehr-template-model genutzt werden. Unter Hinzunahme weiterer Strukturinformationen (Anzahl von Studienarmen sowie den jeweils vorgesehenen Visiten) könnte ein Anwendungsbaustein implementiert werden, der aus auf openehr-templates basierenden Bildschirmformularen automatisch mit Archetypen-Referenzen annotierte ODM-basierte Studiendefinition generiert. Ein weiterer Baustein der Referenzarchitektur ist der Export der erfassten Studiendaten aus dem SDMS in das ODM-Format. Indem eine mit Archetypen annotierte ODM-Datei zur Definition von Studien- und ecrf-struktur im SDMS genutzt wurde, bildet sich diese Semantik auch auf den ODM-basierten Export der erfassten Studiendaten ab. Beispiel openehr- Templates ODM-Export

64 44 Multiple Verwendung von Patientendaten unter Nutzung von Archetypen Pre-population AQL Datenübertragung Auf Archetypen basierende KIS Ein zentrales Element der Referenzarchitektur, ist die Implementierung eines Mechanismus im SDMS, welcher beim Ausfüllen der ecrf zu jedem Eingabefeld geeignete Daten aus den KIS vorschlägt, die dann direkt (per Mausklick) bestätigt und übernommen werden können. Voraussetzung ist, dass die zum jeweiligen Probanden benötigten Informationen bereits in einem angebundenen KIS erfasst wurden. Damit ein Prüfarzt entscheiden kann, ob ein vorhandener Wert tatsächlich in einer Studie nutzbar ist, sollten Kontextinformationen zu diesem Wert angezeigt werden. So beispielsweise Informationen zur Untersuchungsmethode bzw. dem Messgerät, mit welchem das Merkmal erhoben wurde oder zum Zustand des Patienten während der Beobachtung soweit diese im jeweiligen KIS dokumentiert wurden zumindest der Erhebungszeitpunkt sollte angezeigt werden. Alle in einer Studie benötigten Informationen, die nicht aus einem KIS abgeleitet werden können, müssen manuell im SDMS erfasst werden. Das SDMS muss alle Funktionen zum Übernehmen der in den KIS vorhandenen Daten sowie zum Erfassen der in einer Studie zusätzlich benötigten Informationen mit Hilfe einer Web-basierte Benutzerschnittstelle ermöglichen. Um Daten aus KIS übernehmen zu können, benötigt das SDMS eine auf Archetypen basierende Importschnittstelle. Diese Schnittstelle muss es ermöglichen, mittels Archetype Query Language (vgl. Kapitel 2.6) für eine Studie und einen Patienten geeignete, exakt definierte Datensätze aus den angeschlossenen KIS abzurufen die KIS müssen hierzu einheitliche Exportschnittstellen bereitstellen. Für jedes CRF-Feld, das eine Übernahme von KIS-Daten erlauben soll, muss eine dedizierte auf AQL basierende KIS-Abfrage hinterlegt werden. Auf diese Weise kann die Liste der angebotenen Werte, auf diejenigen beschränkt werden, die alle Anforderungen einer Studie erfüllen und somit für eine multiple Nutzung geeignet sind. Muss in einer Studie etwa der Blutdruck der Probanden invasiv in definierten Zeitabständen gemessen werden, kann mittels AQL die Menge der zu einem Patienten aus dem KIS ins SDMS importierten Blutdruckmessungen auf die invasiv durchgeführten Messungen und das entsprechende Zeitintervall eingeschränkt werden. Mit der AQL ist es ferner möglich, komplexe Anfragen zu formulieren, die es erlauben, Ausprägungen von Studienmerkmalen aus den Datenbeständen der KIS abzuleiten, die dort nur implizit vorliegen. So könnte bei entsprechender Datenlage aus den KIS-Daten beispielsweise abgeleitet werden, ob ein Patient eine bestimmte Kombination von Medikamenten einnimmt. Pro Studie müssen zusätzlich zur Studiendefinition für alle Studienmerkmale, für welche multipel nutzbare KIS-Daten ermittelt werden sollen, geeignete AQL-Abfragen in einer eigenen Datei oder Datenbank hinterlegt werden. KIS-spezifische Anpassungen sind dabei nicht notwendig, da auf alle KIS über eine einheitliche Schnittstelle zugegriffen wird. Im einfachsten Fall können die AQL-Abfragen in einer strukturierten Textdatei oder in einer weiteren XML-Datei hinterlegt werden. Die Zuordnung einer AQL-Abfrage zu einem Datenelement in der Studie erfolgt mit Hilfe der OID, mit welcher das jeweilige Element in der ODM-basierten Studiendefinition eindeutig bezeichnet ist. Das Erstellen der benötigten AQL-Abfragen sollte unbedingt durch Generatorwerkzeuge unterstützt werden. Für den physikalischen Datenaustausch zwischen KIS und SDMS erlaubt die Referenzarchitektur verschiedene Ansätze: Angefangen von einer direkten Netzwerkverbindung, über den in s gekapselten Austausch von AQL-Abfragen und Ergebnisdatensätzen bis hin zur manuellen Übertragung von Abfragen und Ergebnisdatensätzen mittels USB-Stick. Die gewählte Realisierung muss sich dabei an den jeweiligen Gegebenheiten wie Firewall- und Sicherheitsrichtlinien orientieren. Erfolgt eine Datenübertragung über das Internet muss eine geeignete Methode zur Verschlüsselung der ausgetauschten Daten (beispielsweise ein Virtual Private Network) implementiert werden. Jedes auf Archetypen basierende KIS, welches an das SDMS angebunden werden soll, muss eine entsprechende AQL-basierte Abfrage- und Exportschnittstelle bereitstellen. Darüber hinaus sollte mit dieser Abfrageschnittstelle ein Pseudonymisierungsdienst verknüpft sein.

65 Ergebnisse 45 Während in KIS in der Regel die realen identifizierenden Daten eines Patienten angezeigt werden, werden in Studien Probanden über ein Pseudonym identifiziert. Die Zuordnungsliste von Patienten und Pseudonymen befindet sich dabei im Studienzentrum. Dementsprechend muss der Pseudonymisierungsdienst in der Lage sein, das in einer AQL-Anfrage enthaltene, studienbezogene Pseudonym in die Patienten-ID des jeweiligen KIS umzuwandeln und entsprechende Zuordnungslisten zu verwalten. Bei der Umsetzung der openehr-spezifikationen muss hierbei berücksichtigt werden, dass die in den Systemen genutzten versionierten COMPOSITIONs über einen Unique Identifier verfügen. Wenn Daten aus einem auf Archetypen basierenden KIS in ein ebenfalls auf Archetypen basierendes SDMS exportiert würden, bestünde die Gefahr, dass zusätzlich zur Vergabe einer pseudonymisierten Kennung für die Studienteilnehmer, der Unique Identifier der übertragenen COMPOSITIONs als weiteres Pseudonym die Rückidentifizierung eines Patienten theoretisch ermöglicht. Um dies zu verhindern, müssen beim Datenexport alle Unique Identifier eineindeutig durch ein kryptographisch geschütztes weiteres Pseudonym ersetzt werden. Jedes nicht auf Archetypen basierende KIS muss prinzipiell über eine beliebige Export- Schnittstelle verfügen, um Daten extrahieren zu können. In Abb wird für das nicht auf Archetypen basierende KIS beispielsweise die Möglichkeit des Datenexports über eine SOA-Schnittstelle (serviceorientierte Architektur) angenommen und dargestellt; ebenso ist auch ein direkter SQL-basierter Zugriff möglich, falls die KIS-Daten in einer relationalen Datenbank gespeichert werden oder eine proprietäre Exportschnittstelle. Zusätzlich muss ein dediziertes Integrationsmodul bereitgestellt werden. Dieses Modul kapselt die KISspezifischen Export-Schnittstellen und erlaubt den AQL-basierten Zugriff wie auf ein Archetypen-basiertes KIS. Hierzu transformiert das Integrationsmodul die KIS-spezifische Repräsentation der dort gespeicherten Daten in eine auf Archetypen basierende Repräsentation. Für jedes nicht auf Archetypen basierende KIS muss ein eigenes Integrationsmodul bereitgestellt werden, welches auf die KIS-Daten zugreifen und diese entsprechend der AQL-Abfragen des SDMS exportieren kann. Hierzu müssen innerhalb des Integrationsmoduls Abbildungs- und Transformationsvorschriften definiert werden, welche den im KIS erfassten Datenelementen die entsprechenden, auf Archetypen basierenden Repräsentationen zuordnen. Zur Implementierung dieser Transformationen können im Fall von openehr-archetypen sogenannte Integration Archetypes und das openehr Integration Information Model ([BEALE 2006]) genutzt werden. Das openehr Integration Information Model sieht vor, dass Daten aus Systemen, die nicht auf Archetypen basieren, zunächst mit Hilfe von Integrations-Archetypen repräsentiert werden. Darin soll die ursprüngliche Datenstruktur so gut wie möglich mit generischen Elementen abgebildet werden. Ausgehend von den Integration-Archetypen kann dann eine Abbildung der Daten auf die tatsächlich genutzten openehr-archetypen erfolgen. Dieses zweistufige Vorgehen hat den Vorteil, dass Abbildungen, die gegebenenfalls eine Datentransformation erfordern, nur zwischen openehr-archetypen definiert werden müssen nämlich zwischen den Integration- Archetypen und den tatsächlich genutzten Archetypen (vgl. [BEALE 2006], S. 11f). Die Definition und konkrete Realisierung der Abbildungsvorschriften zwischen KIS und Integrations Archetypen muss sich an den technischen Rahmenbedingungen des jeweiligen KIS orientieren. Dabei ist sowohl eine dynamische Transformation denkbar definiert beispielsweise in einer XSLT-Datei (Extensible Stylesheet Language Transformation) als auch eine statische Implementierung. In diesem Fall ist, ebenso wie bei einem vollständig auf Archetypen basierenden KIS, ein Pseudonymisierungsdienst zu integrieren. Besteht ein KIS sowohl aus Subsystemen, die auf Archetypen basieren, als auch aus klassischen, nicht Archetyp-basierten Subsystemen, ist eine Kombination der beiden geschilderten Szenarien denkbar. Nicht auf Archetypen basierende KIS

66 46 Multiple Verwendung von Patientendaten unter Nutzung von Archetypen Archetypen- Repository Schritt 1 Schritt 2 Schritt 3 Ein zentrales Element der hier vorgestellten Systemarchitektur ist das Archetypen- Repository, welches von allen beteiligten, auf Archetypen basierenden Komponenten genutzt werden muss. Nur wenn alle involvierten Komponenten dieselben Archetypen nutzen, ist semantische Interoperabilität auf einfache Art möglich. Werden nicht dieselben Archetypen genutzt, ist auch hier eine Abbildung erforderlich. Dabei kann angenommen werden, dass die Abbildung der Datenelement eines KIS ohne semantische Beschreibung auf eine auf Archetypen basierende Repräsentation schwieriger zu generieren ist, als die Abbildung des Archetypen-Sets eines Systems auf das Archetypen-Set eines anderen Systems. Speziell für die Abbildung von openehr-archetypen auf ISO Archetypen zeigten [MARTINEZ- COSTA, MENARGUEZ-TORTOSA et al. 2010], dass es möglich ist, aus openehr-archetypen automatisiert ISO Archetypen zu generieren und umgekehrt (siehe hierzu auch [MARTINEZ-COSTA, MENARGUEZ-TORTOSA et al. 2011]). Die Referenzarchitektur wurde so umfassend und generisch gestaltet, dass es je nach Situation und Gegebenheiten möglich ist, die benötigten Komponenten zu kombinieren. Beispielsweise könnte es sinnvoll sein, über die ODM-Import-Schnittstelle eines bereits vorhandenen, jedoch nicht auf Archetypen basierenden SDMS im KIS gespeicherte Daten zu importieren. Die gemäß der Referenzarchitektur neu zu implementierende Komponente müsste in der Lage sein, entsprechende Daten per AQL aus dem KIS zu extrahieren (AQL- Import) und im ODM-Format für das vorhandene SDMS bereitzustellen (ODM-Export). Ein vollständiges, auf Archetypen basierendes SDMS müsste in diesem Fall nicht realisiert werden Vorgehen gemäß Referenzarchitektur Um in einer Studie die im KIS vorhandenen Daten gemäß der hier vorgestellten Referenzarchitektur nutzen zu können, sind folgende Schritte notwendig: Anbindung der zu integrierenden KIS Im Falle eines auf Archetypen basierenden KIS muss eine AQL-basierte Abfrageschnittstelle bereitgestellt werden. Im Falle eines nicht auf Archetypen basierenden KIS muss ein entsprechendes Integrationsmodul bereitgestellt werden. Hierbei ist es denkbar, das Integrationsmodul iterativ jeweils um die in der aktuellen Studie benötigten Archetypen zu erweitern (dabei kann gemäß dem generischen Vorgehensmodell vgl. Kapitel 3.1 verfahren werden). Dieser Schritt muss einmal pro KIS durchgeführt werden. Bereitstellen der Studiendefinition Definition von Studienstruktur und zu erhebenden Daten mit Hilfe des ODM. Die einzelnen, zu erhebenden Datenelemente werden dabei durch Referenzen auf Archetypen mit dem ODM-Alias-Mechanismus eindeutig semantisch beschrieben. Der auf Archetypen basierende Entwurf von ecrf-seiten kann in einem vollständig auf Archetypen basierenden SDMS mit Hilfe von openehr-templates erfolgen. Aus Templates und Studienstruktur kann dann die ODM-Datei automatisch generiert werden. Dieser Schritt muss einmal pro Studie durchgeführt werden. Dabei können einmal definierte ecrf/merkmalsgruppen (zum Beispiel Basisdatensätze) leicht in unterschiedlichen Studien wiederverwendet werden. Bereitstellen von entsprechenden AQL-Abfragen Definition einer AQL-Abfrage zu jedem für die Studie definierten ODM-Datenelement, um die jeweils benötigte Information aus den einzelnen KIS extrahieren zu können. Die Zuordnung einer AQL-Abfrage zu einem ODM-Datenelement erfolgt über die jeweilige OID. Dieser Schritt muss einmal pro Studie durchgeführt werden. Wird ein ODM-Datenelement wiederverwendet, welches bereits für eine andere Studie definiert wurde, kann in der Regel auch die entsprechende AQL-Abfrage wiederverwendet werden. Allerdings muss geprüft werden, ob für eine Beobachtung in der aktuellen Studie dieselben Untersuchungsmethoden vorgesehen sind wie in der Studie, für welche die AQL-Abfrage ursprünglich erstellt wurde. Gegebenenfalls muss die Abfrage entsprechend angepasst werden.

67 Ergebnisse 47 Darüber hinaus müssen verschiedene technische und organisatorische Rahmenbedingungen definiert werden. Ausgehend von den Gegebenheiten in den einzelnen Studienzentralen muss beispielsweise geregelt werden, wann bzw. wie häufig Daten aus den KIS in das SDMS überführt werden: Nur manuell, automatisch in definierten Zeitintervallen oder automatisch und in Echtzeit, wenn ein CRF ausgefüllt wird. Dementsprechend muss weiter festgelegt werden, wann, wie und wie oft die im SDMS erfassten Daten mit den Quelldaten in den KIS abgeglichen werden und wie im Falle von Inkonsistenzen verfahren wird. Diese Rahmenbedingungen müssen in der Regel einmal pro Studienzentrum definiert werden. Sobald diese Schritte abgearbeitet sind, können mit dem SDMS Studiendaten erfasst und geeignete vorhandene Daten aus den angeschlossenen KIS übernommen werden. 4.4 Archetypen zur Dokumentation von und in klinischen Studien Die zentralen Komponenten der im vorhergehenden Kapitel vorgeschlagenen Referenzarchitektur basieren auf Archetypen. Um diese Architektur implementieren und einsetzen zu können, müssen entsprechende Archetypen zur Dokumentation im Kontext klinischer Studien verfügbar sein. Dies setzt voraus, dass sich Archetypen nicht nur zur Repräsentation von Daten aus der Versorgung sondern auch für Studiendaten und Studien- Metadaten eignen. Eine systematisch Suche mit den Suchbegriffen clinical trial, clinical study trial, und study ergab, das bisher keine speziellen Archetypen zur Dokumentation im Kontext klinischer Studien existieren Entwicklung von Archetypen für Studiendaten Eine Aussage, ob sich Archetypen generell auch zur Dokumentation von Studiendaten eignen ist nicht möglich, da die in klinischen Studien erhobenen Merkmalsarten meist von Studie zu Studie variieren. Bestimmte Merkmalsarten werden, zumindest in ähnlicher Weise, regelmäßig in Studien erhoben. Die CDASH Spezifikation (siehe Kapitel 2.7) standardisiert genau solche Merkmalsarten. Wenn Archetypen identifiziert werden, welche sich zur Repräsentation der einzelnen CDASH Felder eignen, lässt sich daraus schließen, an welchen Stellen in openehr-basierten Patientenakten entsprechende Daten gefunden werden können. Diese Daten sind damit potenziell geeignet für eine multiple Verwendung in korrespondierenden, CDASH-basierten ecrf-datenfeldern. Gemäß der vorgeschlagenen Referenzarchitektur können diese Daten dann durch AQL-Abfragen aus den KIS extrahiert werden. Ausgehend von den CDASH Domänen Common Identifier Variables (CI) Common Timing Variables (CT) Adverse Events (AE) und Prior and Concomitant Medications (CM) wurde daher untersucht, ob und gegebenenfalls welche verfügbaren openehr-archetypen sich eignen, um die dort definierten Merkmalsarten zu dokumentieren. Für CDASH- Datenelemente, zu welchen keine passenden Archetypen identifiziert werden konnten, wurden bestehende Archetypen erweitert bzw. neue Archetypen entworfen. Nachfolgend werden die hierbei erzielten Ergebnisse und gewonnenen Erkenntnisse beispielhaft anhand der CDASH Domäne Prior and Concomitant Medications dargestellt. Die Ergebnisse für die anderen Domänen finden sich in Anhang 1. In einem ersten Schritt wurden alle verfügbaren openehr-archetypen ermittelt, die beim Dokumentieren von Medikationsangaben relevant sein können. Das Ergebnis dieser Recherche ist in Abb dargestellt.

68 48 Multiple Verwendung von Patientendaten unter Nutzung von Archetypen OBSERVATION. o substance_use.v1 (SU) EVALUATION. o check_list.v1 Spezialisierung von check_list.v1: o check_list-medication.v1 (CL) o excluded-adverse.v1 (EA) o exclusion-medication.v1 (EM) INSTRUCTION. o medication.v1 (IM) ACTION. o medication.v1 (AM) COMPOSITION. o medication_list.v1 (ML) o prescription.v1 (PR) ITEM_TREE. o medication.v1 (TM) o medication-formulation.v1 (MF) o medication-vaccine.v1 (MV) Abb. 4-13: Archetypen mit Relevanz bei der Dokumentation von Medikationsangaben (die in Klammern angegebenen Abkürzungen korrespondieren mit den Angaben in Tab. 4 2). Tab. 4-2 stellt, basierend auf den vorhergehend aufgelisteten Archetypen, die identifizierten Abbildungsmöglichkeiten dar. Der für CDASH-Elemente teilweise angegebene Datentyp Text (kodiert) zeigt an, dass es sich um ein Textfeld handelt, für welches nur vordefinierte Codes gemäß der CDISC Controlled Terminology zugelassen sind. Weitere Details finden sich in Anhang 1. Die CDASH-Domäne CM besteht aus 20 Datenelementen. Für 12 dieser Elemente konnten direkte Abbildungen (CDASH CM-Element auf Archetypen basierendes Attribut/Merkmalsart) identifiziert werden. Um auch die übrigen 8 CDASH CM-Elemente basierend auf Archetypen dokumentieren zu können, wurden vorhandene Archetypen spezialisiert und um fehlende Felder erweitert so beispielsweise für das Element CMDOSTOT zur Dokumentation der täglichen Gesamtdosis eines Medikaments. Zusätzlich wurde für die Domäne CM ein eigener CDASH-bezogener COMPOSITION-Archetyp neu entworfen. In 3 der 8 Fälle ohne direkte Abbildung (CMSPID, CMAENO und CMMHNO) waren keine geeigneten Archetypen vorhanden, da diese Elemente für studienbezogene Referenzen und Strukturinformationen vorgesehen und daher in klassischen Patientenakten nicht vorhanden sind. Ebenso war für das CDASH-Feld CMINGRD nur im Archetyp OBSERVATION.substance_use.v1 eine Entsprechung vorhanden, nicht jedoch im Archetyp ITEM_TREE.medication.v1. Das Element CMDOSTOT (Tagesdosis einer Medikation) fand sich nicht als eigenständiges Feld in den vorhandenen Archetypen. Es ist jedoch möglich, diese Information unter Nutzung mehrerer Felder ( Dose und Dose duration ) des Archetyps ITEM_TREE.medication.v1 abzubilden. Auch die übrigen 3 Elemente CMOCCUR, CMPRIOR und CMONGO wurden von keinem bereits vorhandenen Archetypen beschrieben, da sich diese aus anderen Einträgen einer Patientenakte implizit ergeben. So kann etwa das Element CMPRIOR, welches anzeigt, ob eine Medikation bereits vor Studienbeginn begonnen wurde, abgeleitet werden aus dem Beginn einer Medikation und dem Datum des Einschlusses des jeweiligen Studienteilnehmers in die Studie.

69 Ergebnisse 49 Tab. 4-2: Mögliche Abbildungen von CDASH CM-Datenelementen auf openehr-archetypen (aufbauend auf [KRUEL 2010] S. 57). Die Bezeichnungen der Archetypen entsprechen den in Abb eingeführten Kürzeln. Typ der Abbildung: direkt es gibt einen Archetypen, welcher eine dem CDASH-Element entsprechende Merkmalsart definiert; n. a. bedeutet nicht anwendbar die Information, die für das jeweilige CDASH-Feld benötigt wird, findet sich in der Regel nicht in einer Patientenakte es gibt keinen entsprechenden Archetypen; AQL es gibt keinen Archetypen für das jeweilige CDASH-Feld, die benötigte Information könnte aber mit einer AQL-Abfrage aus der Patientenakte abgeleitet werden. CDASH CM Datenelement openehr-archetyp Nr. Datentyp Archetyp Attribute Typ der Abbildung 1 CMYN Text (kodiert) EM global statements direkt 2 CMSPID - - n. a. 3 CMTRT Text TM name of medication direkt 4 CMOCCUR Text (kodiert) AM - AQL 5 CMINGRD Text (Liste) MF name of formulation direkt 6 CMINDC Text (Liste) TM indication direkt 7 CMAENO - - n. a 8 CMMHNO - - n. a. 9 CMDSTXT Text TM dose direkt 10 CMDOSTOT Text TM - AQL 11 CMDOSU Text (kodiert) TM dose unit direkt 12 CMDOSFRM Text (kodiert) TM Form direkt 13 CMDOSFRQ Text (kodiert) TM maximum dose unit frequency direkt 14 CMROUTE Text (kodiert) TM route direkt 15 CMSTDAT Datum TM date (time) of first administration direkt 16 CMPRIOR Text (kodiert) AM, TM - AQL 17 CMSTTIM Uhrzeit TM 18 CMENDAT Datum TM date (time) of first administration date (time) of last administration direkt direkt 19 CMONGO Text (kodiert) AM, TM - AQL 20 CMENTIM Uhrzeit TM date (time) of last administration direkt AQL-Abfragen Zum Entwurf von CRF-Seiten zur Dokumentation der CDASH CM-Datenelemente CMOCCUR, CMPRIOR und CMONGO in einem auf Archetypen basierenden SDMS können die eigens hierfür entworfenen bzw. erweiterten Archetypen genutzt werden. Diese Archetypen sind CDASH-spezifisch und werden üblicherweise nicht zur Dokumentation in Patientenakten verwendet. Daher können diese Archetypen nicht genutzt werden, um in

70 50 Multiple Verwendung von Patientendaten unter Nutzung von Archetypen openehr-basierten Patientenakten nach Einträgen zu suchen, die sich für eine multiple Verwendung im Studienkontext eignen. Da sich die genannten CDASH-Elemente jedoch implizit aus Archetypen ergeben, die in openehr-basierten Patientenakten genutzt werden, können auch die Informationen für diese CDASH-Elemente mit AQL aus Patientenakten extrahiert werden (Vermerk AQL in Tab. 4-2). Da in der Regel mehrere Archetypen berücksichtigt werden müssen, sind diese AQL-Abfragen jedoch meist komplexer als direkte Abbildungen. Zu allen Datenelementen der untersuchten CDASH-Domänen, die sich nur implizit aus openehr-basierten Patientenakten ableiten lassen, wurden nicht nur CDASHspezifische Archetypen entwickelt, sondern auch entsprechende AQL-Abfragen definiert (siehe Anhang 1). Das folgende Beispiel (Abb. 4-14) zeigt die Abfrage für das Feld CMPRIOR: Bei den mit $ beginnenden Bezeichnern handelt es sich um Variablen, die vor der Abfrage mit Werten belegt werden müssen. Im Fall von $ehrid_of_current_patient ist dies die systeminterne Identifikation des aktuellen Patienten; $medication_of_interest muss die Bezeichnung der aktuell betrachteten Medikation zugewiesen werden. Als Ergebnis liefert die Abfrage das Datum der ersten Gabe der betrachteten Medikation dieses kann dann in Beziehung zum Datum des Studieneinschlusses des betrachteten Patienten gesetzt werden. SELECT itemtreemedication/data/items[at0018]/items[0019]/value AS Date_Time_of_First_Administration FROM EHR e [ehr_id/value=$ehrid_of_current_patient] CONTAINS (COMPOSITION composition CONTAINS (ACTION actionmedication [ACTION.medication.v1] CONTAINS (ITEM_TREE itemtreemedication [ITEM_TREE.medication (-[a-za-z0-9_]+)*.v1]))) WHERE itemtreemedication/items[at0001]/value= $medication_of_interest Abb. 4-14: AQL-Abfrage zur Ermittlung der ersten Gabe einer bestimmten Medikation. Beispiel CMDSTXT Die CDASH Domäne CM konnte unter Hinzunahme der vorgeschlagenen Spezialisierungen und Ergänzungen vollständig mit vorhandenen openehr-archetypen abgebildet werden. Bei der Abbildung von Daten aus Patientenakten, die auf Archetypen basieren, auf CDASHkonforme ecrf müssen in Einzelfällen jedoch spezifische Hürden gemeistert werden. Das folgende Beispiel soll dies verdeutlichen: Für das Feld CMDSTXT (Einzeldosis einer Medikation) ist die Abbildung auf das Feld Dosis im Archetypen ITEM_TREE.medication.v1 nicht eindeutig: Je nachdem, ob eine Dosisangabe dokumentiert wird als eine Masseneinheit samt Maßzahl oder Intervall, als eine Volumeneinheit samt Maßzahl oder Intervall oder als Anzahl, Bruchteil oder Intervall einer Dosiseinheit (beispielsweise 6 Beutel ) wird die entsprechende Angabe in einem anderen Attribut des Archetyps abgelegt. Um in einer openehr-basierten Akte einen Wert zu finden, welcher für das Feld CMDSTXT in

71 Ergebnisse 51 einen ecrf übernommen werden könnte, müssen immer alle relevanten Attribute berücksichtigt werden. Wurde mit dem Archetyp ein Dosisintervall dokumentiert, müsste darüber hinaus eine individuelle Abbildungsvorschrift (zum Beispiel Berechnung des Mittelwerts) festgelegt werden, um aus dem Intervall den Absolutwert einer Einzeldosis für das CDASH-Feld berechnen zu können. Umgekehrt müsste bei der Repräsentation von CDASH-Feldern mit Archetypen berücksichtigt werden, dass das CDASH-Feld CMDSTXT eine reine Zahlenangabe verlangt (für die Dosiseinheit ist ein eigenes Feld CMDOSU vorgesehen), der Archetyp hier jedoch nur ein kombiniertes Attribut aus Maßzahl und Maßeinheit vorsieht. Zur Erleichterung der Abbildung von CDASH-Elementen mit openehr-archetypen wäre es teilweise sinnvoll, die bestehenden Archetypen für Patientenakten noch weiter zu ergänzen bzw. neue Archetypen zu entwickeln. Nachfolgend wird beispielhaft die Abbildung für das Element CMINGRD betrachtet. In Bezug auf das Element CMINGRD (Aufzählung aller Wirkstoffe eines Arzneimittels) wäre es hilfreich, die beiden Archetypen ITEM_TREE.medication.v1 und ITEM_TREE.medication-vaccine.v1 jeweils um eine direkt mit diesem CDASH-Element korrespondierende optionale Merkmalsart Inhaltsstoffe (analog zum Archetyp ITEM_TREE.medicationformulation.v1) zu erweitern. So könnten auch diese Archetypen einfach zur Dokumentation des CDASH-Feldes genutzt werden. In einer Patientenakte, die nicht auf Archetypen basiert, ist eine solche Erweiterung nicht unbedingt notwendig, da hier die Wirkstoffe eines Fertigarzneimittels bei Bedarf in entsprechenden Datenbanken recherchiert werden können. In diesem Zusammenhang sollte außerdem beachtet werden, dass die Bezeichnungen Wirkstoff und Inhaltsstoff oft synonym gebraucht werden, obwohl nicht jeder Inhaltsstoff auch notwendiger Weise ein Wirkstoff sein muss. Sowohl der CDASH-Standard als auch die Definition dieses Archetyp-Feldes sollten daher semantisch präziser gefasst werden (nach [KRUEL 2010] S. 64). Basierend auf den vorhergehend identifizierten Archetypen wurde ein openehr-template zur Dokumentation des CDASH CM-Datensatzes entworfen. OpenEHR-Templates können in einem auf openehr-archetypen basierenden SDMS zur Definition von CRF-Seiten genutzt werden. Abb zeigt einen Ausschnitt der Definition dieses Templates im Ocean Template Designer Abb eine hieraus automatisch generierte HTML-basierte Eingabemaske. Beispiel CMINGRD CDASH CM Template

72 52 Multiple Verwendung von Patientendaten unter Nutzung von Archetypen Abb. 4-15: Definition des CDASH CM-Templates im Ocean Template Designer. Abb veranschaulicht, wie der openehr-template-mechanismus genutzt wurde, um basierend auf verfügbaren und adaptierten bzw. neue generierten Archetypen CRF gemäß der CDASH-Spezifikation zu generieren: Von den Archetypen definierte, optionale Felder, die gemäß CDASH-Vorgabe nicht benötigt werden, wurden ausgeblendet (graue Schrift). Für die Darstellung am Bildschirm wurden die in den Archetypen hinterlegten Feldnamen durch die von CDASH vorgegebenen Fragen ersetzt (zum Beispiel What was the individual dose of the medication/therapy? NAME (from Dose ) ) Falls in einem verwendeten Archetypen ein Feld als optional, in CDASH jedoch als verpflichtend gekennzeichnet ist, wurde dieses auch im entsprechenden Template als verpflichtend deklariert ( [0..1] to [1..1] ). Für Elemente, für welche CDASH bestimmte CDISC Code-Listen als mögliche Ausprägungen vorsieht, wurden diese Code-Listen mit Hilfe des Templates referenziert ( VALUE (CDISC Controlled Terminology: C12345) ). Darüber hinaus (in Abb nur durch die -Symbole ersichtlich) wurden alle im Template definierten Felder mit dem entsprechenden, durch CDASH vorgegebenen Feldcode annotiert (zum Beispiel CMPRIOR ). Wo sinnvoll wurden Bedingungen definiert, um Inkonsistenzen bei der Eingabe zu vermeiden: Die CDASH Felder CMENDAT und CMENTIM beispielsweise geben Datum bzw. Uhrzeit des Endes der jeweiligen Medikation an (für beide Felder sieht der

73 Ergebnisse 53 Archetyp ITEM_TREE.medication.v1 ein kombiniertes Datums- und Zeitfeld vor). Falls eine Medikation auch nach Studienende noch fortbesteht, darf kein Endzeitpunkt erfasst werden. Stattdessen muss im Feld CMONGO (ongoing medication) der Wert true gesetzt werden. Daher wurde im Template für das Eingabefeld zur Erfassung des Enddatums einer Medikation die Bedingung hinterlegt, dass dort nur dann ein Wert eingetragen werden darf, wenn CMONGO den Wert false enthält und umgekehrt. Abb. 4-16: HTML-Eingabemaske generiert aus dem openehr CDASH CM-Template. Zur Definition des CDASH CM-Templates wurden einerseits die zu Anfang dieses Abschnitts aufgezählten, allgemein verfügbaren und für Patientenakten entworfenen Archetypen genutzt.

74 54 Multiple Verwendung von Patientendaten unter Nutzung von Archetypen Darüber hinaus wurden der entwickelte CDASH-Archetyp COMPOSITION.cdash_cm.v1 sowie die CDASH-Spezialisierungen der Archetypen ACTION.medication.v1 und ITEM_TREE.medication.v1 verwendet. Vergleichbare Ergebnisse wurden auch für die anderen Domänen (Common Identifier Variables, Common Timing Variables und Adverse Events) erarbeitet. Insgesamt wurden somit vier Templates entworfen, für welche insgesamt zwei COMPOSITION-Archetypen neu entwickelt und drei bestehenden Archetypen (je ein ACTION-, ein EVALUATION- und ein ITEM_TREE-Archetyp) spezialisiert werden mussten. Im Rahmen der neu entwickelten und spezialisierten Archetypen mussten insgesamt 23 Merkmalsarten basierend auf Archetypen neu definiert werden Entwicklung von Archetypen für Studien-Metadaten Zur Umsetzung der Referenzarchitektur werden ferner Archetypen benötigt, die Studien- Metadaten repräsentieren. Aus der Synopse von Merkmalsarten, welche von der International Clinical Trials Registry Platform (apps.who.int/trialsearch), vom Deutschen Register Klinischer Studien (register.germanctr.de/drks) sowie KKS-intern ( erhoben werden, wurden 82 Merkmalsarten identifiziert, die Studien und zugehörige Objekttypen umfassend beschreiben. So ist eine Studie beispielsweise gekennzeichnet durch ein Studienakronym, ihren primären Endpunkt oder ihre Ein- und Ausschlusskriterien. Als Grundlage für die Abgrenzung der einzelnen Archetypen wurde folgende generische Studienstruktur (Abb. 4-17) erarbeitet: Eine Studie hat mindestens einen Studienarm. Ein Studienarm besteht aus mindestens einer Visite. Im Rahmen einer Visite werden studienrelevante Daten erhoben und/oder Interventionen (Medikamentengaben, Operationen etc.) durchgeführt. Während eine Beobachtungsstudie in der Regel nur einen Studienarm hat, verfügt eine randomisierte, kontrollierte Studie über mindestens zwei Studienarme. Abb. 4-17: Generische Struktur einer klinischen Studie.

75 Ergebnisse 55 Ausgehend von den identifizierenden Objekttypen und den zugehörigen Merkmalsarten wurden openehr-archetypen für Studien-Metadaten modelliert. Insgesamt wurden die 16 in Abb dargestellten openehr-archetypen entworfen und in englischer und deutscher Sprache beschrieben. Diese Archetypen ermöglichen es, Studien-Metadaten in openehrbasierten Systemen analog zu Patientendaten zu speichern und zu verarbeiten. Die Zuordnung der einzelnen DRKS-, ICTRP- und KKS-Studien-Metamerkmale zu den entworfenen openehr-archetypen kann Anhang 2 entnommen werden. COMPOSITION. o clinical_trial.v1 (Klinische Studie) o trial_arm.v1 (Studienarm) o trial_visit.v1 (Studienvisite) o study_site.v1 (Studienzentrum) o study_contact_data.v1 (Studienbezogene Kontaktdaten) o study_content.v1 (Studieninhalt) o study_design.v1 (Studiendesign) o study_ethics_committee_vote.v1 (Ethikvotum) o study_identification.v1 (Studienidentifikation) o study_length.v1 (Studienumfang) o study_site_description.v1 (Studienzentrum -Beschreibung-) o study_sponsor.v1 (Sponsor) o study_state.v1 (Studienstatus) o study_type.v1 (Studientyp) o trial_arm_description.v1 (Studienarm -Beschreibung-) o trial_visit_description.v1 (Studienvisite -Beschreibung-) Abb. 4-18: Neu erstellte Archetypen für Studien-Metadaten. Die openehr-architektur bietet die Möglichkeit COMPOSITIONs in openehr-folders (siehe Kapitel 2.6) zu organisieren. Diese Verzeichnisse können beim Entwurf eines auf Archetypen basierenden SDMS genutzt werden, um alle zu einer bestimmten Studie gehörenden Metadaten und die Studiendaten zusammenzuführen und gemäß der dargestellten generischen Studienstruktur zu ordnen. Abb stellt dies schematisch dar. Für jede Studie wird basierend auf der generischen Studienstruktur eine eigene Verzeichnishierarchie angelegt. Dabei enthält das Wurzelverzeichnis dieser Hierarchie genau ein COMPOSITION-Objekt clinical_trial, welches die jeweilige Studie identifiziert und beschreibt. Weiter enthält das Wurzelverzeichnis jeweils ein COMPOSITION-Objekt study_site zur Beschreibung der Studienzentren sowie ein Unterverzeichnis pro Studienarm. In den die Studienarme repräsentierenden Verzeichnissen befindet sich analog zum Studienverzeichnis ein COMPOSITION-Objekt trial_arm, welches den jeweiligen Studienarm identifiziert und beschreibt. Weiter enthalten die Verzeichnisse der einzelnen Studienarme ein Unterverzeichnis für jede geplante Studienvisite. Auch in den die Studienvisiten repräsentierenden Verzeichnissen befindet sich analog zum Studienverzeichnis ein COMPOSITION-Objekt trial_visit, welches die jeweilige Visite identifiziert und beschreibt. Darüber hinaus enthalten die Visiten-Verzeichnisse COMPOSITION-Objekte, welche die medizinischen Daten aller Patienten repräsentieren, die bei der jeweiligen Visite erhoben wurden. So führt ein Visitenverzeichnis, die Studiendaten aller Studienteilnehmer zusammen, die zu einer bestimmten Visite (in einem bestimmten Studienarm in einer bestimmten Studie) erhoben wurden, inklusive der Metadaten, welche die Visite selbst beschreiben. Folders Studie Arm Visite

76 56 Multiple Verwendung von Patientendaten unter Nutzung von Archetypen Ergänzt um die Beschreibung der Studienstruktur und die einzelnen Studien-Metadaten ergeben die medizinischen Inhalte aller Visiten aller Arme der Studie den vollständigen Datensatz der jeweiligen Studie (vgl. Abb. 4-19). Abb. 4-19: Verzeichnisstruktur für Studiendaten und Studienmetadaten (blau: Verzeichnisstruktur; orange/blau: Studien-Metadaten; grün: eigentliche Studiendaten). Für die Objekttypen Studie, Studienarm und Visite wurde dabei jeweils ein COMPOSITION-Archetyp und ein oder mehrere zugehörige ADMIN_ENTRY-Archetypen definiert. Die COMPOSITION-Archetypen enthalten als CONTEXT eine Merkmalsart ID, welche es erlaubt, das jeweilige Objekt eindeutig zu referenzieren. Darüber hinaus sind SECTIONS vorhanden, um die zugehörigen ADMIN_ENTRY-Archetypen einzubinden. Die eigentlichen Meta-Merkmale sind von den jeweiligen IDs abgesehen in den ADMIN_ENTRY-Archetypen enthalten. Abb veranschaulicht dies schematisch. Um die Übersichtlichkeit zu verbessern, werden nicht alle modellierten Merkmalsarten abgebildet. Der Archetyp study_identification.v1 definiert Felder für Studienname, Studienakronym und Versionsnummer des Studienprotokolls.