Informationsmanagement in der klinischen Forschung - Studiendatenmanagementsysteme am Beispiel von OpenClinica I Matthias Löbe - IMISE Leipzig

Informationsmanagement in der klinischen
Forschung
Studiendatenmanagementsysteme am Beispiel von
OpenClinica I

Matthias Löbe
11.04.2019

Institut für Medizinische Informatik, Statistik und Epidemiologie

Übersicht Teil 1

1.   Grundlagen der Datenerfassung in klinischen Studien
2.   OpenClinica als CDMS am IMISE
3.   Umsetzung einer Studie

                                                           2

GRUNDLAGEN

             3

Wiederholung

Welches Ziel hat eine klinische Therapiestudie?
• Nachweis der Wirksamkeit und der Unbedenklichkeit einer
  neuartigen Therapie (Medikament, Operation, ...) für eine
  definierte Indikation bei einer Versuchsgruppe im Vergleich zu
  einer Kontrollgruppe

Wie kann die Intervention in der Kontrollgruppe aussehen?
• Bisheriger Standard
• Placebo
• Keine Intervention

                                                                   4

Klinische Studien sind „Experimente an/mit
Menschen“
Am IMISE:
1. Akademische klinische Prüfungen (Onkologie, Kardiologie,
   Infektiologie, Adipositas) in Kooperation mit ZKS Leipzig
   –   Erfassung einer Mindestzahl von Probanden mit gewünschten
       Eigenschaften, statistischer Analyseplan liegt vor
   –   Therapieoptimierung/Dosisfindung, Verträglichkeitsvergleiche,
       Nebenwirkungen, Lebensqualität, Zufriedenheit
2. Epidemiologische Studien (LIFE-Kohorte, Nationale Kohorte)
   –   Beobachtung von Bevölkerungsgruppen, Analyseplan liegt vor
3. Klinische Register
   –   Erfassung aller Individuen einer bestimmten Population
   –   Analysen werden später spezifiziert
                                                                       5

Einteilung verschiedener Studientypen

                                        6

Einleitung

• Klinische Studien gelten als derzeit beste Methode zum Nachweis
  der Überlegenheit neuer Wirkstoffe oder Therapien
• Register und Kohorten sind meist weniger interventionell
• Klinische Studien sind streng reguliert
   – Good Clinical Practice (GCP), Good Automated Manufacturing
     Practice, FDA 21 Part 11, Datenschutz/HIPAA
   – Besonders streng: Zulassungsstudien
   – An Studien(-ergebnissen) hängen Milliarden von Euro jährlich
• Die observierten phänotypischen Daten der Probanden müssen für
  die statistische Aufbereitung erfasst, gespeichert und aufbereitet
  werden

                                                                       7

Voraussetzungen für die
Vergleichbarkeit von Studienarmen
• Strukturgleichheit: Gleichheit bzgl. wichtiger Merkmale
   – Balanciert nach Störgrößen: Alter, Geschlecht, Vorerkrankungen
• Behandlungsgleichheit: Gleichheit bzgl. der Behandlung neben
  der unterschiedlichen Therapie
   – Klinische Pfade, Medikamente gegen Nebenwirkungen
• Beobachtungsgleichheit: Behandlungspersonal soll neutral
  berichten
   – Gleich detaillierte Dokumentation im CRF
• Auswertungsgleichheit: Biometriker ohne Erwartungshaltung
   – Analyseplan im Voraus

Prozessablaufkette einer Studie

                                  9

Datenerfassung in klinischen Studien

Alternativen:
1. Erfassung auf Papier (ausgedruckte Formulare)
2. Erfassung in elektronischen Masken (z.B. Excel/Access)
3. Erfassung in spezialisierten Systemen: Clinical Data
   Management Systems (CDMS)
4. Übernahme aus Drittsystemen
5. Direkteingabe durch Probanden

                                                            10

1. Erfassung auf Papier

• Beliebt bei Ausfüllenden (passt
  in die Mappe zur Visite)
• Unbeliebt beim Studienzentrum
   – Daten müssen abgetippt werden
   – Schrift schlecht lesbar
   – „Vergewaltigung“ von Listen,
     Pflichtfeldern, … möglich
   – Keine Prüfung der Eingaben ad
     hoc möglich
   – CRFs können verloren gehen
     oder zu spät ausgefüllt werden

                                      11

2. Erfassung in elektronischen Masken

• Einfach aufzusetzen und
  durchzuführen
• Für Einzeleingaben
• Aber leicht Fehlbedienung
  möglich => Sortierung nicht
  über alle Spalten …,
  „Intelligenz“ von Excel bei der
  Erkennung von Eingaben
• Keine komplexen Möglichkeiten
  zur Durchsetzung der
  Datenqualität

                                        12

3. Erfassung in Clinical Data Management
Systems
• Spezialsoftware für regulierte
  klinische Studien
   – Wer hat was wann eingegeben,
     geändert oder exportiert?
   – FDA 21 Part 11 regulations on
     electronic records and electronic
     signatures

 CDMS sind inzwischen der
  Goldstandard!

                                           13

4. Übernahme aus Drittsystemen

• Üblicherweise aus Informationssystemen der Versorgung
   – Patientendatenverwaltungssysteme im Krankenhaus
   – Aber auch von niedergelassenen Ärzten, Krankenkassen, Registern
     oder Gensequenzierern denkbar
• Nicht so problemlos wie man denkt!
   – Validierung der Quelldaten
   – Validierung der Übertragung und Umformung
   – Aktualität der überspielten Daten (z.B. bei Laborwerten), redundante
     Datenhaltung im KIS

                                                                            14

5. Direkteingabe durch Probanden

• Über Web-Browser, Handys, Tablets oder Telefon
   – Noch relativ neu, wenige Erfahrungen
• Chancen:
   – Aktuellere und damit eventuell genauere
     Dokumentation (z.B. Schmerztagebuch), größere
     Mitmachbereitschaft
• Risiken:
   – Sicherheit (offener Browser zu Hause)
   – Validierung der Übertragung und Umformung
   – Dateneingabe durch Nichtexperten (Fehleingaben,
     Spaßeingaben, Vermischung mit subjektiven
     Interessen (z.B. erhöhte Schmerzmittelgabe),
     Erkennen von schwerwiegenden Problemen wie
     Schlaganfall)
                                                       15

OPENCLINICA ALS CDMS AM
IMISE

                          16

Exkurs: ein neues Großprojekt

• IFB = Integriertes Forschungs- und Behandlungszentrum
• BMBF-Ausschreibung, 8 IFBs in Deutschland, ortsgebunden zu
  einem Krankheitsbild
• CSCC: IFB Sepsis und Sepsisfolgen Jena (2010 – 2015 – 2020)
   – IT-Strukturen und ZKS Jena gerade im Aufbau
   – Unterauftrag (3 Jahre): Aufbau IT-Unit durch IMISE Leipzig
   – Forschungsprogramm umfasst viele klinische Studien

 Elektronisches Datenmanagementsystem erforderlich!
 Nachhaltigkeit von IT-Lösungen statt Feature-Jagd!

                                                                  17

Wie findet man das beste Clinical Data
Management System?

Eigentlich recht einfach:

1. Definiere Anforderungen und gewichte diese
2. Prüfe verfügbare Systeme auf der Grad der Erfülltheit der
   Anforderungen

                                                               18

CDMS-Evaluation des KKS Netzwerks

• Ziel: Anforderungskatalog für die Re-Evaluierung aller im
  Netzwerk eingesetzten CDMS
• 385 sehr detaillierte Anforderungen (Stand Februar 2012)

                                                              19

Anbieter von CDMS (Auswahl)

                              http://edcmarket.appspot.com/

                                                              20

Anforderungen des CSCC

• GCP-konformes                 • Arbeitsplan Leipzig
  Qualitätsmanagement              – 6 Monate Systemevaluation
• Schnell einsatzbereit            – Danach Produkteinführung,
• Minimale Investitionskosten        Tests, Dokumentation und
                                     Abnahme
• Geringe Folgekosten
                                   – Jahr 2: Umsetzung der
• Integrierbar in geplante           produktiven Studien
  Forschungsinfrastruktur
                                • Arbeitsplan Jena
• Transferierbar von Leipzig
                                   – 10 Studien beginnen sofort
  nach Jena                          oder demnächst
• Zukunftssicher

                                                                  21

Blitzevaluation Aug. - Okt. 2010

Im Einsatz in Leipzig:
• eResearchNet für KN Herzinsuffizienz und Sepsis, IFB Adipositas
   – Viel Erfahrung, Zukunft unklar, keine Hostinglizenz
• Oracle Forms für KN Maligne Lymphome
   – Viel Erfahrung, Zukunft unklar, recht aufwendig
• Webobjects für PROGRESS
• LIME Survey/ Teleform für LIFE

                   Oder doch ein weiteres System?

                                      OpenClinica? RedCAP? Phosco?

                                                                    22

OpenClinica!

Risiken:
• Keine Produktiv-Erfahrungen mit dem System
• Keine Kompetenz im Aufbau

Chancen:
• Geringe Kosten
• Innovative Ansätze möglich
• Moderne Schnittstellen

 Die Entscheidung für OpenClinica war 2010 situationsgetrieben
   Aber: DVMD-Challenge 2015 (Ulm): Unterschiede zwischen CDMS
   sind marginal
                                                                  23

OpenClinica Facts

• Gleichnamige Firma: OpenClinica, LLC
   – Gründung 2005, ca. 25 Mitarbeiter
• “popular among academic institutions and small CROs”
   – Aber kaum konkrete Kundenstories verfügbar
   – Viele Installationen weltweit
   – Große Community, jährliche Konferenz
   – Firmensupport auf durch Dritte verfügbar

                                                         24

Architektur & Technisches

• Open-Source-Stack: alle zwingend abhängigen Komponenten
  sind offene und freie Software
• Programmiersprache: Java
• APIs: Servlets & JSP, Spring, Hibernate, SOAP, Sitemesh,
  LiquiBase, LDAP
• Datenmodell: CDISC ODM
• Webserver: Apache und Tomcat
• Datenbank: PostgreSQL
• Browser: alle aktuellen Browser*
 Für IMISE: Ausschließlich bestehende Infrastruktur!

            OpenClinica im IFB Sepsis (CSCC) – Matthias Löbe – 02.09.2013   25

ODM in Beziehung zu anderen CDISC-
Standards (kommt später genauer)

                                     26

Systembetriebsvoraussetzungen

• Hardware: einfache Dual-Core CPU, 2 GB RAM, 30 GB HD
• Hosting: lokal, OpenClinica Cloud oder externe Firma
• Design: selbst oder durch Firma
   – Jeder CRF-Bogen wird durch eine normative Exceldatei spezifiziert
   – Dadurch einfache Kommunikation mit klinischen Forschern

                                                                         27

Development Roadmap

• Kontinuierliche Weiterentwicklung: neue Versionen mehrfach
  jährlich, Updates möglich
          Version     Release Date    Version      Release Date
           1.0         12/2005          3.4         10/2014
           1.1         06/2006          3.5         04/2015
           2.0         03/2007          3.6         07/2015
           2.2         03/2008          3.7         09/2015
           2.5         09/2008          3.8         11/2015
           3.0         10/2009          3.9         01/2016
           3.1         09/2011         3.10         03/2016
          3.1.2        01/2012         3.11         05/2016
          3.1.4        08/2013         3.12         09/2016
           3.2         04/2014         3.13         02/2017
           3.3         07/2014         3.14        01/2018

                                                                  28

Regulatory Compliance (Eigenaussagen)

• Designed to support the use of Good Clinical Practice (GCP)
• FDA-compliant Quality System
• Compliance with 21 CFR Part 11
• HIPAA Regulatory Compliance

• Validation Package customers may audit Systems
  Development Lifecycle (SDLC) documentation including Standard
  Operating Procedures (SOPs)

                                                                  29

OpenClinica ist Open-Source-Software

Nachteile                        Vorteile
• Keine Gewährleistung bei       • Quelltext vorhanden
  Mängeln
                                 • Keine Lizenzkosten
• Kein Anspruch auf
                                  • Fehlerbehebung eigenständig
  Sonderentwicklungen (auch nicht
                                    möglich
  gegen Entgelt)
• Schnelle Releasewechsel ohne   • Eigene Erweiterungen
  Migrationsgarantie               programmierbar
• Geringere Unterstützung
  (Validierung, Qualifikation)

                                                                  30

Community Edition

• Support über Online-Ressourcen (Wiki, Mailingliste,
  Produktdokumentation usw.)
   – „Community Support“
   – Im Fall von OpenClinica starke Unterstützung durch den Hersteller
   – Technisch identisch (einige Plugins nur für Enterprise)
• Open Source: Lesser GNU Public License (LGPL)
   – ursprünglich für Programmbibliotheken
   – darf zusammen mit proprietärem Code gelinkt werden (Code bleibt
     aber getrennt)
   – kann für kommerzielle Zwecke verwendet werden
   – Beispiele: Open Office

                                                                         31

Enterprise Edition

                     32

Typische Funktionen von
Studiendatenmanagementsystemen
• Audit Trail und Electronic Signatures
• Rangechecks und Rules
• Conditional Items, Partial Dates
• Double Data Entry / Source Data Verification
• Cross Field Edit Checks, komplexe Validierungen
• Query Management and Filtering Discrepancy Note Types
• Study Case Book
• CRF-Versions, CRF Mapping
• Rechte- und Rollenkonzept, Unterstützung für Zentren
• Exporte CDISC, XLS, SPSS, SAS, …
• Web-Services zur Anbindung externer Applikationen
                                                          33

Nicht dazu gehören Funktionen wie …

• Studienregister
• Visitenplaner
• Vertragsverwalter
• Budgetplaner
• Randomisierungstool
• Dokumentenverwalter
• CRF-Tracker und -Mahner
• SAE-Manager und -Melder
• Auswerteplattform, Laborinformationssystem, Barcodeleser, KIS-Ersatz,
  Formularscanner, Screening-Datenbank, DRG-Grouper, Biomaterialverwalter,
  Gen-Mapper, Tumorboard, Datenintegrator, OCR-Modul, Therapiemanager…

                                                                             34

Wir beschäftigen uns mit Datenmanagement!

• Studienmanagement: Welche Studien werden an der
  Universitätsmedizin Leipzig durchgeführt? Sponsorhaftung?
  Verträge? Abrechnung studienbedingter Mehraufwand?
• Patientenmanagement: Wann muss der Patient wiederkommen?
  Wie kann man ihn kontaktieren? Stehen noch CRFs aus?
• Site Management: Sind die lokalen Prüfer qualifiziert? Arbeitet
  das Zentrum protokollkonform? Gibt es Audits?

                                                        IT-Report der TMF 2015

                                                                                 35

Integration in die IT-Infrastruktur des CSCC
                           1. Screeningdatenbank

                                     2. Pseudonymisierung

                                                            3. OpenClinica

   4. Datenintegration

  5. Forschungsdatenbank
  und Data Warehouse

                                                                       36

Realisierte Studienprojekte (Auswahl)

• INSEP
   – Schätzung der Inzidenz der schweren Sepsis und des septischen
     Schocks auf Intensivstationen in Deutschland
   – 1 Monat Laufzeit
   – 150 Zentren, 450 Dateneingabekräfte, keine Schulung
   – 12.300 Probanden
   – Kein Geld, kein Anwendertraining
 Webfähigkeit Bedingung, Dateneingabe durch einzelnes Zentrum
  nicht zu leisten
 Unterstützung für Zentren, Rechte & Rollen
 Keine größeren Probleme bei ungeschulten Dateneingebenden (!)

                                                                     37

Realisierte Studienprojekte (Auswahl)

• LIBRE
   – Untersuchung der Machbarkeit eines strukturierten körperlichen
     Bewegungsprogramms und einer mediterranen Ernährung bei Frauen
     mit BRCA1/2-Mutationen
   – 14 Events, 51 unterschiedliche CRFs
 Übersicht über den Stand der Dokumentation ohne CDMS schwer

                                                                  38

Realisierte Studienprojekte (Auswahl)

• MEDUSA
   – Multizentrische Studie (n=45) mit 250 Anwendern und 5.000 Pat.
   – Import von Daten aus externen
     Dokumentationssystemen gewünscht
   – Häufige Änderungen am CRF während Laufzeit
 Audit Trail nützlich bei vielen externen Anwendern
 Secondary Use über API (Web-Services-Schnittstelle) und ODM-
  Import realisiert (extern)
 OpenClinica unterstützt Versionen von CRF

                                                                      39

Realisierte Studienprojekte (Auswahl)

• REGISTRY
   – Zentrales Register aller Patienten mit septischem Schock
   – Langzeitprojekt (> 10 Jahre)
   – Viele komplexe Qualitätschecks
   – Zusammenführung mit KIS-Daten
 Terminplanung möglich, aber kein Patientenkalender, kein
  Mahnwesen
 Sehr komplexe Regeln möglich, aber aufwändig zu erstellen
 Datenzusammenführung geschieht in Forschungsdatenbank

                                                                40

Realisierte Studienprojekte (Auswahl)

• ALERTS
  – Monitoringprojekt zum frühzeitigen Erkennen nosokomialer
    Infektionen
  – Alle stationären Patienten des Uniklinikums werden
    untersucht
  – Multiple, optionale CRF je Visite, Wiederverwendung von CRF
  – Pseudonymisierung und studienübergreifender Master-Patient-Index
   Screeningmodul extern angebunden
   OpenClinica unterstützt multiple Subject-IDs
   PID-Erzeugung mit TMF-PID-Generator

                                                                       41

Ergebnisse

• 16 Studien durchgeführt, mehrere in Vorbereitung
   – 50 aktive Nutzer mit und ohne Schulung
   – 25.000 Probanden eingeschlossen

                                                     42

Erfahrungen nach 9 Jahren
Was wir mögen

• Stabiler Betrieb, keinerlei Abstürze
• Gute Community-Unterstützung über Mailingliste
• Kontinuierliche Weiterentwicklung des Produkts
• CRF-Erstellung in Excel erleichtert Absprache mit Medizinern
• Nutzung von CDISC ODM als Datenmodell erleichtert Import und
  Weiterverwertung
• WebService-API ermöglicht Anbindung externer Applikationen
• Moderne technische Architektur, Code gut lesbar
• Geringe Kosten, Möglichkeit zum Update
• Beliebige Anwendbarkeit: Hosting für Dritte, Lehre, Industrie

Schlussfolgerung: Eignung von OpenClinica
für translationale Forschungsprojekte
Kosten         Werkzeug          Charakterisierung
  >– 1.000
      c    € Office              Für kleine, multizentrische Studien mit
                                 Dateneingabe durch den 33% Investigator und ohne
                                 Nachnutzungsabsicht der erhobenen Daten
 > 10.000 € SQL, Forms           Für einzelne Studien oder Studien mit sehr
            (Access, Oracle,     speziellen Datentypen75%
                                                        (z.B. Stammbäume,
            Sharepoint)          Tumorboard, Bild-, Bio- und Genomdaten)
> 100.000 € Kommerzielle         Für große, generös finanzierte Zentren mit
            EDC-Systeme                               90%
                                 vielen Studienprojekten (Industrie, AMG, FDA)
                                 und gesicherter Langzeitfinanzierung
> 300.000 € Eigen-               Notwendigkeit der Anbindung an spezifische
            entwicklungen        In-House-Workflows, z.B. einer Ambulanz oder
                                                      75% mit verschiedenen
                                 einer longitudinalen Kohorte,
                                 Messapparaturen und speziellen QM-Checks
Ein gewisser Einarbeitungs- und Betriebsaufwand ist nötig, ansonsten kann
OpenClinica bedenkenlos empfohlen werden.
                                                                                    44

UMSETZUNG EINER STUDIE

                         45

Workflow beim Umsetzen einer Studie

• Spezifikation => Implementierung => Test => Produktivschaltung

Dementsprechend gibt es drei CDMS-Instanzen:
• Entwicklungs-Instanz: Instanz, auf der die Studie vom Entwickler
  erstellt wird
• Test-Instanz: Instanz, auf der die Studie vom Nutzer getestet wird
• Produktiv-Instanz: Instanz, auf der die Studie produktiv läuft

• Ggfs. gibt es eine vierte Instanz für Schulungszwecke
• Test-Instanz und Produktiv-Instanz auf gleichem Server

                                                                       46

Vorbereitung der Umsetzung

• Vor Beginn der Umsetzung muss Spezifikation vorliegen
   – Umfang und Komplexität der Studie
   – Abschätzung des Aufwandes und der Zeitpunkte (First Patient In, …)
   – Erarbeitung durch klinische Forscher, Projektmanagement,
     Biometriker und IT/Datenmanagement
• IT-Spezifikation besteht aus:
   1. Studienprotokoll
   2. Flowchart
   3. Case Report Forms
   4. Datenqualitätsprüfungen
   5. Sonstige Vereinbarungen

                                                                          47

Studienspezifikation: Studienprotokoll (1)

• Strukturiertes Dokument, welches Ziele und Ablauf der Studie
  beschreibt
• Muss i.A. einer Ethikkommission zur Genehmigung vorgelegt
  werden
Harte Anforderungen an den Inhalt:
• Titel, Rollen, IDs, Unterschriften
• Aktueller Stand der Forschung
• Fragestellungen und Hypothesen
• Studiendesign (prospektiv/retrospektiv, Querschnitt/Längsschnitt,
  Intervention/Diagnostik/Beobachtung, Arme,
  Randomisierung, Verblindung)

                                                                      48

Studienspezifikation: Studienprotokoll (2)

• Auswertungsplan mit Analysemethoden
• Klinische Endpunkte: Maßzahlen, welche das Ergebnis einer
  Studie verdeutlichen
   – Endpunkt: beim Erreichen eines Endpunkts wird die Beobachtung des
     Probanden beendet
   – Primäre (Studienziel) und sekundäre Endpunkte
   – Überlebensdauer, Remissionsrate, Eintreten eines Myokardinfarkts
• Fallzahlplanung und Rekrutierungswege
   – Aufgabe des Biometrikers
   – Wie viele Probanden brauche ich für eine statistisch signifikante
     Aussage?
• Einschluss- und Ausschlusskriterien (klarer Ja-Nein-Entscheid!)
                                                                         49

Studienspezifikation: Studienprotokoll (3)

• Studienablauf und Zeitplanung (Flowchart)
• Beschreibung der Intervention, unerwünschte Ereignisse und
  Maßnahmen
• Probandeninformation, Einwilligungserklärung, Versicherung
• Datenmanagement
   – Datenerhebungen
   – Quelldatensysteme
   – Datenerfassung und –speicherung
   – Pseudonymisierung/Anonymisierung
   – Transfer und Archivierung

                                                               50

Studienspezifikation: Flowchart mit
Erhebungszeitpunkten

                                      LIBRE-Studie

                                                     51

Studienspezifikation: Annotierter Case
Report Form

                                         RAS-AZIC-Studie

                                                           52

Studienspezifikation: Vereinbarungen zur
Sicherstellung der Datenqualität
• Pflichtfelder
• Auswahllisten
• Formatprüfungen (TT.MM.JJJJ)
• Datentypprüfungen (Gewicht als Fließzahl, keine Buchstaben)
• Plausibilitätsprüfungen (Alter < 140 Jahre)
• Normbereiche für Laborwerte (Körpertemperatur 26 – 43 °C)
• Logische Abhängigkeiten (Datum KH-Aufnahme vor Datum ITS-
  Aufnahme)
• Inhaltliche Abhängigkeiten (keine Schwangerschaft bei Männern)
• Komplexe Kriterien (2 von 4 Merkmalen sollen erfüllt sein)

                                                                   53

Sonstige Vereinbarungen („Pflichtenheft“)

• Beteiligte Zentren, Nutzer und Rechte
• Gewünschte Zusatz-Tools (Generierung von Probanden-Ids,
  Versand von Prüfmedikamenten, Reports zur Projektkontrolle …)
• Umsetzung der gesamten Applikation zum Studienstart oder
  Teilimplementierung (Studienphasen)
• Gewünschte Exportdatensätze und –formate
• Verfügbarkeit des Systems, Nutzersupport

                                                                  54

Implementierung

• Der gesamte Prozess ist durch Arbeitsanweisungen (SOPs)
  strukturiert vorgegeben und wird für jede Studie dokumentiert

• Case Report Form:
   – Ermöglicht standardisierte Erfassung aller notwendigen Informationen
   – Voraussetzung für Beobachtungsgleichheit!
   – Merkmalsarten
       • Eingabefelder für Texte, Zahlen, Datumsangaben (Formate angeben)
       • Auswahloptionen einfach und mehrfach (Skalenbereich sinnvoll wählen)
   – Mehr Details in Vorlesung zu Standards!

                                                                                55

Warum nicht einfach so?

Patientennummer:         __________________________________
Adresse Hausarzt: __________________________________
                         __________________________________
Vorerkankungen:          __________________________________
                         __________________________________
Schweregrad:             __________________________________
• Man bekommt jede denkbare Schreibweise:
   – Härtelstraße, Härtelstrasse, Härtelstr., Härtel Strasse, haertelstrase
   – Herzinfarkt, Myokardinfarkt, Herzmuskelinfarkt, Herzschlag,
     Herzanfall, Herzattacke
   – Leicht, mittel, moderat, leicht-mittel, Typ 3, Atomnot

                                                                              56

Hierarchischer Aufbau der Dokumentation

• Hierarchie:
   – Studie
   – (Zentren)
   – Events (Visits)
   – Formulare (CRF)
   – Itemgruppen (Module, Pages)
   – Items (Datenelemente)
   – Codelists
• Zwischen zwei Elementen dieser Liste besteht jeweils eine n:m-
  Beziehung
• Idee: Wiederverwendbarkeit (auch studienübergreifend)

                                                                   57

Protected Health Information (PHI)

• Die Erfassung identifizierender Daten in CRFs wird von
  Ethikkommissionen ungern gesehen
• US Health Insurance Portability and Accountability Act (HIPAA)
  definiert, was identifizierende Daten sind:
   1.    Names                             11.   Certificate/license numbers
   2.    Geographic data                   12.   Vehicle identifiers and serial numbers
   3.    All elements of dates                   including license plates

   4.    Telephone numbers                 13.   Device identifiers and serial numbers

   5.    FAX numbers                       14.   Web URLs

   6.    Email addresses                   15.   Internet protocol addresses

   7.    Social Security numbers           16.   Biometric identifiers (i.e. retinal scan,
                                                 fingerprints)
   8.    Medical record numbers
                                           17.   Full face photos and comparable images
   9.    Health plan beneficiary numbers
                                           18.   Any unique identifying number,
   10.   Account numbers                         characteristic or code

                                                                                             58

Ausgangsbasis Papier-CRF

                           Formular
     Studie

   Itemgruppe

      Item                  Codelist

                                       59

Formale Implementierung der CRFs

• In OpenClinica mittels Excel-Vorlage
• Best-Practices und Konventionen sind dokumentiert
• Vertiefung in der Übung

                                                      60

e-CRF

• Aus der Excel-Vorlage wird der
  e-CRF (Webmaske) und die
  Datenpersistenz generiert

                                   61

Beziehung zu Visits

• Typische Erhebungszeitpunkte
   – Screening
   – Randomisation
   – Baseline
   – Intervention
   – Follow-Up
• Visiten können auch optional sein (Tod) oder mehrfach
  vorkommen (Lebensqualität, Unerwünschte Ereignisse)

                                                          62

Test und Validierung (1)

• Kontrolle der Implementierung
   – Keine formale Verifikation!
• Studienmanagementsoftware
   – Nur Test der Prüfregeln und der Masken
   – Alles Andere ist automatisch validiert
• Eigenentwicklung
   – Umfangreiche Validierung notwendig (Spezifikation)
   – Test Eingabe gegen Datenbank
   – Kodierungen
   – Prüfregeln

                                                          63

Test und Validierung (2)

• Strukturiertes Testen anhand sogenannter Validierungsprotokolle
• Art und Umfang von Testung/Validierung sind in SOPs festgelegt
• Nutzer (nicht der Entwickler) testet die Anwendung auf der Test-
  DB gegen die Spezifikation
   – Bestenfalls 3-5 Anwender aus verschiedenen Zentren!
• Iterationsprozess:
   – Meldung bestehender Fehler (Nutzer)
   – Korrektur (Entwickler)
   – erneute Testung (Nutzer)
• Bewährt hat sich das Testen mit Echtdaten!

                                                                     64

Produktivschaltung der Studie

• Nach erfolgreichem Durchlauf aller Tests erfolgt Abnahme der
  Studie
   – Sinnvoll: Dokumentation durch Übergabeprotokoll
• Änderungen oder Erweiterungen sind häufig nötig
   – „Vergessene“ oder missverständliche Datenelemente
   – Im Test nicht gefundene Fehler
   – Dokumentation kann in der Realität nicht wie umgesetzt durchgeführt
     werden (Daten fehlen oder Patient ist schon weg)
   – Offizielle Änderungen an Dokumentationskonzept (Studien-
     Amendments)
• Wichtig: Jeden Änderungswunsch schriftlich dokumentieren!

                                                                           65