Advertisement

Datenmanagement für Medizinproduktestudien

  • Daniel HaakEmail author
  • Verena Deserno
  • Thomas Deserno (geb.Lehmann)
Living reference work entry
Part of the Springer Reference Technik book series (SRT)

Zusammenfassung

In diesem Kapitel werden die gesetzlich vorgeschriebene Vorgehensweise zur klinischen Prüfung von Medizinprodukten sowie einzelne IT-Komponenten zur Unterstützung des Datenmanagements in klinischen Studien beschrieben. Es wird verdeutlicht, dass die IT-Systeme geeignet miteinander zu koppeln sind, um ihrer Aufgabe effizient gerecht zu werden, hierzu aber – im Gegensatz zur Routine der Patientenversorgung – keine geeigneten Schnittstellen etabliert sind. Das Ziel aller Informationssysteme wird über die 5R-Regel definiert: Die richtige Information zur richtigen Zeit am richtigen Ort der richtigen Person in der richtigen Form zur Verfügung zu stellen. Dies ist derzeit in der klinischen Forschung noch nicht erreicht und wird daher auch in Zukunft für Medizinproduktestudien wichtig bleiben.

1 Einführung

1.1 Anforderungen an Medizinprodukte

Als Medizinprodukt bezeichnet man Systeme oder Stoffe, die zu medizinisch therapeutischen oder diagnostischen Zwecken für Menschen verwendet werden. Im universitären Umfeld werden Medizinprodukte in Zusammenarbeit mit An-Instituten oder auch mit industriellen Partnern – insbesondere im Rahmen öffentlicher Förderprogramme oder in sog. Kooperationsforschung – getestet, weiterentwickelt oder in andere Indikationsgebiete übertragen. An technischen Universitäten wie der RWTH Aachen besteht Anspruch und Bedarf, völlig neue, innovative Produkte, die in den ingenieurswissenschaftlichen Instituten entwickelt und hergestellt werden, über schlanke Strukturen eines Translationsforschungszentrums schnell, aber auch sicher und kontrolliert in die Erstanwendung am Menschen zu bringen. Dabei müssen Forscher, Entwickler und Hersteller von Beginn an das Medizinproduktegesetz (MPG; Kap. Vorschriften für Medizinprodukte) berücksichtigen, dessen Zweck es ist „(…) den Verkehr mit Medizinprodukten zu regeln und dadurch für die Sicherheit, Eignung und Leistung der Medizinprodukte sowie die Gesundheit und den erforderlichen Schutz der Patienten, Anwender und Dritter zu sorgen“ (Medizinproduktegesetz 2002). Das MPG verweist auf die grundlegenden Anforderungen, die je nach Art des Produktes in drei verschiedenen EU-Richtlinien und deren Anhängen definiert sind:
  • Aktives implantierbares Medizinprodukt (Anhang 1 der Richtlinie 90/385/EWG, zuletzt geändert durch Artikel 1 der Richtlinie 2007/47/EG)

  • In-Vitro-Diagnostikum (Anhang I der Richtlinie 98/79/EG)

  • Sonstiges Medizinprodukt (Anhang I der Richtlinie 93/42/EWG, zuletzt geändert durch Artikel 2 der Richtlinie 2007/47/EG).

Vom Hersteller muss hierzu die medizinische Zweckbestimmung festgelegt und beschrieben werden. Im Falle der sonstigen Medizinprodukte muss eine Risikoklassifizierung vorgenommen werden. Die Regeln zur Klassifizierung sind detailliert im Anhang IX der EU-Richtlinie 93/42/EWG festgelegt. Im Wesentlichen werden vier Klassen unterschieden (Übersicht).

Risikoklassen

  • Klasse I: geringe Invasivität oder kein methodisches Risiko, z. B. ärztliche Instrumente, Gehhilfen, Verbandsmaterial

  • Klasse IIa: mäßige Invasivität oder Anwendungsrisiko kurzer Applikationsdauer, z. B. Einwegspritzen, Hörgeräte, Bildarchivierungssoftware (engl. Picture Archiving and Communication System, PACS)

  • Klasse IIb: mäßige Invasivität oder erhöhtes methodisches Risiko durch systemische Wirkungen oder Langzeitanwendungen, z. B. Beatmungsgeräte, Blutbeutel, Kondome

  • Klasse III: hohe Invasivität oder hohes Risiko, z. B. Herzschrittmacher, Stents, Brustimplantate.

Außerdem muss die Eignung des Medizinproduktes mittels einer klinischen Bewertung nachgewiesen werden. Diese klinische Bewertung kann einerseits durch Literaturrecherche und dem Nachweis der Vergleichbarkeit des Produktes mit den in der Literatur verfügbaren klinischen Daten erfolgen. Bei innovativen Medizinprodukten wird dieser Weg nicht möglich sein. Dann muss die Eignung anhand neuer klinischer Daten erfolgen, die in klinischer(n) Prüfung(en) erhoben werden.

1.2 Klinische Prüfungen und Studien mit Medizinprodukten

Wendet man die Definitionen für Medizinprodukt und klinische Prüfung aus dem MPG auf typische Forschungsfragen an, so wird schnell deutlich, dass jede Veränderung eines Produktes, einer Software (stand-alone oder integriert) oder jede neue Kombination von bereits CE-zertifizierten Medizinprodukten als neues Medizinprodukt aufzufassen ist. Damit ist auch jede Testung veränderter oder kombinierter Komponenten eine Medizinproduktestudie . Dies bedeutet auch, dass vor jeder Testung am Probanden oder Patienten die gesetzlich erforderlichen Genehmigungen bei den zuständigen Ethik-Kommissionen (EK) und der zuständigen Bundesoberbehörde (BOB), hier dem Bundesinstitut für Arzneimittel und Medizinprodukte, BfArM, einzuholen sind. Beide Stellen genehmigen in voneinander zeitlich und inhaltlich unabhängigen Verfahren die Testung am Menschen, die per Gesetz (§ 20 ff MPG) grundsätzlich erst einmal verboten ist. Eine Testung kann genehmigt werden, wenn die allgemeinen und ggf. besonderen Voraussetzungen dafür gemäß § 20 ff MPG erfüllt sind.

Der Sponsor ist verantwortlich für die Initiierung, Durchführung und Finanzierung der Testung und reicht die Genehmigungsanträge ein, die ausführliche Unterlagen gemäß § 5 ff der Verordnung über klinische Prüfungen von Medizinprodukten (MPKPV) umfassen.

Unter anderem muss der Sponsor nachweisen, dass eine Probanden- bzw. Patientenversicherung gem. § 20 MPG abgeschlossen wurde, die in Ergänzung zu den Berufs- und Betriebshaftpflichten der Beteiligten auch dann eintritt, wenn ein Zwischenfall geschieht, der verschuldensunabhängig ist.

Jeder Prüfer, in der Regel ein entsprechend im Indikationsgebiet und in der Durchführung klinischer Prüfungen ausreichend qualifizierter Arzt, wird vom Sponsor zusammen mit Informationen über die Eignung seiner Prüfstelle bei der jeweils für diesen Prüfer zuständigen EK gemeldet, wobei jede Praxis-, Klinikadresse oder Niederlassung eine eigene zu meldende Prüfstelle darstellt. Von der EK wird u. a. überprüft, ob der Prüfer und sein Studienteam aufgrund ihrer Qualifikationen geeignet und auch personelle und räumliche Ressourcen in geeigneter Form vorhanden sind, um eine Medizinproduktestudie an der Prüfstelle optimal durchzuführen.

Gibt es mehrere Prüfstellen in Deutschland, so ist einer der Prüfer der Hauptprüfer und die für diesen zuständige EK ist die federführende EK. Die für alle anderen beteiligten Prüfstellen zuständigen EKs sind beteiligte EKs und übermitteln ihre Eingaben an die federführende EK, die diese in einer einzigen Bewertung zusammenführt.

Über das Internetportal Medizinprodukteinformationssystem (MP-Informationssystem ) des Deutschen Instituts für Medizinische Dokumentation und Information (DIMDI, www.dimdi.de) findet die gesamte Kommunikation während der Genehmigungsverfahren zwischen Sponsor, EK und BOB online statt. Die Bewertungsverfahren können im DIMDI-Portal parallel oder in beliebiger Reihung nacheinander vom Sponsor angestoßen werden. Beide Stellen kommunizieren dann gegenseitig auch ihre Ergebnisse. Einsicht in dieses Portal haben auch alle für die einzelnen beteiligten Prüfstellen zuständigen Überwachungsbehörden der Länder (www.zlg.de), die ggf. Inspektionen während der Datenerhebungsphase der Studie durchführen.

Aus dem MPG § 20 ff in Verbindung mit der MPKPV wird deutlich, dass es zunächst einmal zwei verschiedene Bewertungsverfahren für eine klinische Prüfung eines Medizinproduktes am Patienten gibt. Während Prüfung und Studie im Arzneimittelbereich synonym verwendet werden, unterscheidet das MPG die Generierung von klinischen Daten für die klinische Bewertung mit dem Ziel, einen Nachweis zu führen, dass 1. das Produkt im technischen Sinne geeignet und sicher ist, also die grundlegenden Anforderungen (vgl. MPG § 7) erfüllt sind (Prüfung), oder dass 2. die Wirksamkeit bzw. der klinische Nutzen für den Patienten existiert (Studie). In der Praxis zeigt sich oft eine dritte Variante, die ganz aus den Anwendungsfällen des MPG herausfällt:
  1. 1.
    Volles Genehmigungsverfahren:
    1. a.

      Klinische Prüfung mit einem Medizinprodukt ohne CE-Kennzeichnung, das nicht als Medizinprodukt mit geringem Sicherheitsrisiko klassifiziert werden kann.

       
    2. b.

      Klinische Prüfung mit einem Medizinprodukt, das nach MPG §§ 6 und 10 die CE-Kennzeichnung tragen darf, jedoch außerhalb seiner Zweckbestimmung angewendet wird und/oder zusätzliche invasive oder belastende Maßnahmen vorsieht.

       
    3. c.

      Klinische Studien mit einem Medizinprodukt gemäß Punkt a. oder b., deren primäres Ziel die Erhebung von Wirksamkeitsdaten sind.

       
     
  2. 2.
    Befreiung von der Genehmigungspflicht:
    1. a.

      Medizinprodukt ohne CE-Kennzeichnung, aber mit geringem Sicherheitsrisiko, also der Klasse I oder nichtinvasives Medizinprodukt der Klasse IIa.

       
    2. b.

      Medizinprodukt, das nach MPG §§ 6 und 10 die CE-Kennzeichnung tragen darf, innerhalb seiner Zweckbestimmung angewendet wird und die klinische Prüfung keine zusätzlichen invasiven oder belastenden Maßnahmen vorsieht.

       
    3. c.

      Klinische Studien mit Medizinprodukten gemäß Punkt a. oder b., deren primäres Ziel die Erhebung von Wirksamkeitsdaten sind.

       
     
  3. 3.

    Beratungspflicht für Ärzte gemäß § 15 der Musterberufsordnung für Ärzte (MBO-Ä): Beobachtungsstudien oder Register, in denen (Wirksamkeits-)Daten über CE-gekennzeichnete Medizinprodukte (mit)erhoben werden, die nicht Daten zur klinischen Bewertung im Sinne des MPG § 19 sind und anhand epidemiologischen Methoden ausgewertet werden, fallen ganz aus der Anwendung des MPG heraus. In diesen Fällen ist vom beteiligten Arzt nur eine Beratung durch seine für ihn zuständige EK vorgesehen (www.ak-med-ethik-komm.de).

     

1.3 Clinical Trial Center Aachen

Damit der forschende Arzt die Übersicht behalten kann, werden große medizinische Forschungseinrichtungen und die medizinischen Fakultäten der Universitäten bei der patientennahen Forschung durch sog. Koordinierungszentren für Klinische Studien (KKS) unterstützt, die typischerweise Teil der Universität sind. Zum Beispiel wurde das Clinical Trial Center Aachen (CTC-A) als eigenständige Funktionseinheit der Medizinischen Fakultät der RWTH Aachen mit dem Ziel konstituiert, die Strukturen zur Planung, Durchführung und Auswertung klinischer Studien an der RWTH Aachen zu verbessern. Hierzu gehört die interdisziplinäre Bündelung methodischer Expertise in der Studiendurchführung mit medizinischem, kliniknahem Management. Im CTC-A sind Study Nurses beschäftigt, die die Studienassistenz innerhalb der Uniklinik RWTH Aachen und bei Bedarf auch in peripheren Krankenhäusern übernehmen. Die Study Nurses sind an der Koordination und Durchführung von interdisziplinären Studien beteiligt, in die klinikübergreifend Patienten eingeschlossen werden. Daneben kann die Studienassistenz für Studien in einzelnen Kliniken übernommen werden. Das CTC-A unterstützt auch die Vernetzung mit den Kliniken und Praxen der Region und hilft bei der Rekrutierung von Probanden/Patienten. Ein ganz wesentlicher Aspekt ist die Bereitstellung von zeitgemäßen elektronischen Techniken und IT-Lösungen für Daten-, Studien-, Projekt-, Kooperations- und Budgetmanagement sowie ein Qualitätsmanagementsystem für klinische Studien. Hierfür besteht die IT-Landschaft des CTC-A aus zwei Kernsystemen: Das Study Management-Tool (SMT) ist ein Clinical Trial Management-System (CTMS) , in dem für das Management wichtige Informationen aller Studien, an denen das CTC-A beteiligt ist, erfasst, verwaltet und ausgewertet werden. Mit OpenClinica wird weiterhin ein Electronic Data Capture-System (EDCS) eingesetzt, welches elektronische Fragebögen (Electronic Case Report Forms, eCRF) für die digitale Erfassung der Patientendaten aus den Studienvisiten bereitstellt.

1.4 Datenmanagement

Datenmanagement umfasst alle technischen und organisatorischen Maßnahmen, um Daten optimal in diverse Geschäftsprozesse einzubringen. Wir betrachten hier vor allem die technischen Maßnahmen zum Datenmanagement der Gesundheitssysteme. In Medizinproduktestudien werden personenbezogene Gesundheitsdaten erhoben, die besonders sorgfältig verarbeitet werden müssen. Dazu gehören
  • Persönliche Daten: Alle Informationen, die einen eindeutigen Bezug zum Individuum herstellen lassen, fallen in diese Kategorie. Name, Geburtsname, Alter und Geschlecht werden auch als Patientenstammdaten bezeichnet. Dies sind Daten, die über einen längeren Zeitraum als konstant angesehen werden.

  • Medizinische Daten: Hierunter fallen alle Informationen zum Individuum, die mit seiner Gesundheit in Verbindung stehen. In Medizinproduktestudien sind dies z. B. Laborwerte des Bluts, aber auch Messwerte, die mit dem zu prüfenden Medizinprodukt erzeugt werden. Hierbei macht es keinen Unterschied, ob diese Daten unstrukturiert (z. B. als Freitext in einem Arztbrief) oder strukturiert (z. B. als maschinell bearbeitbarer Code nach der International Classification of Diseases (IDC)) vorliegen.

  • Bilder und Signale: Bilder und Signale sind medizinische Daten, die jedoch schnell sehr groß (z. B. 30 GB für ein Langzeit-EKG mit hoher Abtastung) werden können und gesonderte Methoden zum Transfer sowie zur Visualisierung und Interpretation benötigen. In heutige EDCS können Bild- und Signaldaten nicht ausreichend integriert werden: Die eCRF können große Binärdaten nicht verwalten; das Rendering von Volumendaten ist ebenso nicht möglich. In multizentrischen Studien werden Bild- und Signaldaten daher auf mobile Datenträger (z. B. USB-Stick, CD) gespeichert und per Post versandt, um dann zentral und einheitlich ausgewertet zu werden. Nicht selten werden die Auswerteergebnisse dann – nach langer Transfer- und Analysezeit – per Telefax an das datenerzeugende Zentrum gemeldet, wo eine Study Nurse schließlich die Daten vom Fax händisch wieder in das eCRF eingibt.

Datenmanagement sollte den gesamten Lebenszyklus aller Daten umfassen, von der Entstehung (create) und Benutzung (use) über die Verteilung (share) bis hin zur Löschung (destroy) (Abb. 1). Wichtig ist also, dass das Datenmanagement nicht bei „Use“ endet. In klinischen Studien nach AMG und MPG sind die Archivierungsintervalle gesetzlich vorgegeben. Der Datenschutz fordert die umgehende Löschung personenbezogener Daten, sobald die Nutzungsindikation entfallen ist (z. B. Abschluss der Studie). Archivierung und Löschung werden in der Praxis aber oft nicht hinreichend berücksichtigt, also nicht als Managementaufgabe wahrgenommen. Der Datenaustausch (share) hingegen stößt oft an technische Probleme hinsichtlich zu geringer Bandbreiten, fehlender Protokolle und Inkompatibilitäten der Systeme. Effektives und effizientes Datenmanagement sollte aller mit den Daten in Bezug stehende Personen in deren diversen Funktionen bzw. Rollen (z. B. Study Nurse, Prüfarzt, Monitor, Statistiker, Datenmanager) in der Studie differenziert unterstützen. Hierbei gilt es, den jeweiligen Arbeitsablauf (workflow) optimal zu unterstützen (Deserno und Becker 2009).
Abb. 1

Lebenszyklus von Daten

2 Softwareanforderungen

2.1 Datenschutz

Datenmanagement in klinischen Studien muss vor allem den vielfältigen Aspekten des Datenschutzes gerecht werden. Der Schutz der Persönlichkeitsrechte des Individuums, dessen Daten verarbeitet werden, steht im Vordergrund aller Anstrengungen und resultiert oft in technischen Schwierigkeiten und komplexen Systemen. Im internationalen Vergleich ist Deutschland für seine eher „harte“ Auslegung des Datenschutzes bekannt. Daher ist Datenmanagement, das den deutschen Anforderungen genügt, immer auch international einsetzbar.

In Deutschland gelten viele und sich zum Teil auch widersprechende Gesetze zum Schutz der Daten:
  • Grundgesetz: Im Grundgesetz der Bundesrepublik Deutschland werden Persönlichkeits- und Menschenrechte festgeschrieben: „Die Würde des Menschen ist unantastbar (…) (Art. 1 GG), die im Widerspruch zu zum „Recht auf die freie Entfaltung seiner Persönlichkeit (…) (Art. 2 GG) und dem Grundsatz: „Kunst und Wissenschaft, Forschung und Lehre sind frei (…) (Art. 5 GG) stehen können.

  • Volkszählungsurteil: Das 1983 erlassene Urteil des Bundesverfassungsgerichtes zur Volkszählung legt fest, dass der Einzelne bestimmt, wann, wo und in welchen Grenzen persönliche Lebenssachverhalte offenbart werden. Schon damals wurde das Gefahrenpotenzial der elektronischen Datenverarbeitung (EDV) hinsichtlich der Speicher-, Übermittlungs- und Verknüpfungsmöglichkeit erkannt, obwohl die Technik bei Weitem nicht mit den heutigen Möglichkeiten vergleichbar war. Zur Abwägung von Individual- vs. Allgemeininteressen wurde Normenklarheit durch weitere Gesetze gefordert.

  • Bundesdatenschutzgesetz: § 3 BDSG legt fest, dass alle Einzelangaben über persönliche oder sachliche Verhältnisse einer bestimmten oder bestimmbaren natürlichen Person schützenswert sind. Neben rassischer und ethnischer Herkunft, politischer Meinung und Religion werden die Gesundheit und das Sexualleben explizit genannt.

  • Landesdatenschutzgesetze: De facto unterliegt der Datenschutz in Deutschland den Bundesländern und daher hat jedes Land hier auch eigene Normen, die zwar in der Regel sehr ähnlich sind, sich zum Teil aber auch erheblich unterscheiden können. In Nordrhein-Westfahlen sind das Landesdatenschutzgesetz (DSG NRW, (Der Innenminister des Landes Nordrhein-Westfalen 2000)), das Gesundheitsdatenschutzgesetz (GDSG NRW, (Der Innenminister des Landes Nordrhein-Westfalen 1999)) sowie die Landeskrankenhausgesetzte zu nennen.

  • Weitere Gesetze und Normen: Viele weitere Gesetze und Normen betreffen das Datenmanagement in klinischen Studien. Als Beispiel sei das „Gesetz zur Verbesserung der Rechte von Patientinnen und Patienten“ (Feb. 2013) genannt, mit dem die rein elektronische Archivierung von Patientendaten in der medizinischen Routineversorgung legalisiert wurde. Im Wesentlichen besteht das Gesetz aus Änderungen folgender Gesetzte:
    • Bürgerliches Gesetzbuch

    • Sozialgesetzbuch V

    • Patientenbeteiligungsverordnung

    • Krankenhausfinanzierungsgesetz

    • Zulassungsverordnung für Vertragsärzte

    • Zulassungsverordnung für Vertragszahnärzte

    • Bundesärzteordnung.

Jeder Datenschutz fordert die Einhaltung gewisser Grundsätze oder Paradigmen, die in der folgenden Liste dem DSG NRW entnommen sind:

  • Sparsamkeit: Daten sollen so wenig wie möglich erhoben werden.

  • Zweckbindung: Jede Datenerfassung muss einen Zweck haben; ist dieser Zweck entfallen oder sind die Fristen abgelaufen, müssen die Daten wieder gelöscht werden.

  • Vertraulichkeit: Nur befugte Personen dürfen Zugriff auf die Daten haben.

  • Integrität: Es muss gewährleistet werden, dass Daten bei der Verarbeitung unversehrt, vollständig und aktuell bleiben.

  • Verfügbarkeit: Alle erfassten Daten sollen zeitgerecht zur Verfügung stehen. Erst dann können sie auch ordnungsgemäß verarbeitet werden.

  • Authentizität: Die Daten können ihrem Ursprung zugeordnet werden, Herkunft und Verarbeitung werden dokumentiert.

  • Revisionsfähigkeit: Die Revisionsfähigkeit fordert eine Protokollierung, die oftmals wieder zu einer datenschutzrechtlichen Betrachtung führt. Insbesondere muss in klinischen Studien festgehalten werden, wer wann welche Daten erfasst bzw. geändert hat (Audit Trail).

  • Transparenz: Die Verfahrensweisen der Datenverarbeitung sind vollständig und aktuell zu dokumentieren. Diese Dokumentation wird dann in sog. Verfahrensverzeichnissen eingetragen, die unter der Hoheit der zuständigen Datenschutzinstanzen stehen und anhand derer der Datenschutzbeauftragte die Systeme hinsichtlich ihrer Gesetzeskonformität bewertet.

Um diesen komplexen Anforderungen gerecht zu werden, muss das Datenmanagement in klinischen Studien sorgfältig geplant werden. Derzeit gibt es keine allgemeingültigen Systeme, die einfach „nur“ eingesetzt werden können (Drepper und Semler 2013). Wesentliche Planungskomponenten im Sinne des Datenschutzes sind ein ausführliches Datenschutz- und Sicherheitskonzept. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat hier umfangreiches Material zusammengestellt, das als Hilfestellung bei der Erstellung eines Sicherheitskonzeptes dienen kann (Bundesamt für Sicherheit in der Informationstechnik (BSI) 2011).

Durch die differenzierte Betrachtung möglicher Schadensszenarien in Bezug auf deren Auswirkungen auf Personen und Unternehmen ergeben sich verschiedene Schutzbedarfsklassen (Tab. 1), denen nach dem BSI ein ganzer Katalog von technischen, strukturellen und organisatorischen Maßnahmen gegenübergestellt wird.
Tab. 1

Matrix der Schadensszenarien und Schutzbedarfsklassen (nach (Wirth 2008))

Schadensszenario

Schutzbedarf

„normal“ (1)

Schutzbedarf

„hoch“ (2)

Schutzbedarf

„sehr hoch“ (3)

1. Verstoß gegen Gesetze/Vorschriften/Verträge

• Verstöße gegen Vorschriften und Gesetze mit geringfügigen Konsequenzen

• Geringfügige Vertragsverletzungen mit maximal geringen Konventionalstrafen

• Verstöße gegen Vorschriften und Gesetze mit erheblichen Konsequenzen

• Vertragsverletzungen mit hohen Konventionalstrafen

• Vertragsverletzungen mit erheblichen Haftungsschäden

• Fundamentaler Verstoß gegen Vorschriften und Gesetze

• Vertragsverletzungen, deren Haftungsschäden ruinös sind

2. Beeinträchtigung des informationellen Selbstbestimmungsrechts

• Eine Beeinträchtigung des informationellen Selbstbestimmungsrechts würde durch den Einzelnen als tolerabel eingeschätzt werden

• Ein möglicher Missbrauch personenbezogener Daten hat nur geringfügige Auswirkungen auf die gesellschaftliche Stellung oder die wirtschaftlichen Verhältnisse des Betroffenen

• Eine erhebliche Beeinträchtigung des informationellen Selbstbestimmungsrechts des Einzelnen erscheint möglich

• Ein möglicher Missbrauch personenbezogener Daten hat erhebliche Auswirkungen auf die gesellschaftliche Stellung oder die wirtschaftlichen Verhältnisse des Betroffenen

• Eine besonders bedeutende Beeinträchtigung des informationellen Selbstbestimmungsrechts des Einzelnen erscheint möglich

• Ein möglicher Missbrauch personenbezogener Daten würde für den Betroffenen den gesellschaftlichen oder wirtschaftlichen Ruin bedeuten

3. Beeinträchtigung der persönlichen Unversehrtheit

• Eine Beeinträchtigung erscheint nicht möglich

• Eine Beeinträchtigung der persönlichen Unversehrtheit kann nicht absolut ausgeschlossen werden

• Gravierende Beeinträchtigungen der persönlichen Unversehrtheit sind möglich

• Gefahr für Leib und Leben

4. Beeinträchtigung der Aufgabenerfüllung

• Die Beeinträchtigung würde von den Betroffenen als tolerabel eingeschätzt werden

• Die maximal tolerierbare Ausfallzeit ist größer als 24 Stunden

• Die Beeinträchtigung würde von einzelnen Betroffenen als nicht tolerabel eingeschätzt

• Die maximal tolerierbare Ausfallzeit liegt zwischen einer und 24 Stunden

• Die Beeinträchtigung würde von allen Betroffenen als nicht tolerabel eingeschätzt werden

• Die maximal tolerierbare Ausfallzeit ist kleiner als eine Stunde

5. Negative Außenwirkung

• Eine geringe bzw. nur interne Ansehens- oder Vertrauensbeeinträchtigung ist zu erwarten

• Eine breite Ansehens- oder Vertrauensbeeinträchtigung ist zu erwarten

• Eine landesweite Ansehens- oder Vertrauensbeeinträchtigung, evtl. sogar existenzgefährdender Art, ist denkbar

6. Finanzielle Auswirkungen

• Der finanzielle Schaden bleibt für die Institution tolerabel

• Der Schaden bewirkt beachtliche finanzielle Verluste, ist jedoch nicht existenzbedrohend

• Der finanzielle Schaden ist für die Institution existenzbedrohend

Grundsätzlich sind die Daten, die eine natürliche Person identifizieren, von den medizinisch-inhaltlichen Daten strikt zu trennen. Dies bedeutet eigene Datenbanken auf eigenen Servern mit eigenen Systemadministratoren (Pommerening et al. 2014; Reng et al. 2006). Das verknüpfende Pseudonym (z. B. die Patientenidentifikationsnummer, PID) wird im besten Fall nur temporär über eine dritte Treuhänderinstanz ausgetauscht (Abb. 2). So ist zu keinem Zeitpunkt eine Person in der Lage, die Daten zusammenzuführen, auch wenn sie sich mit krimineller Energie Zugang zu einem System verschaffen sollte.
Abb. 2

Treuhändermodell für den pseudonymisierten Datenaustaus mit automatisch generierter Patientenidentifikation (PID)

2.2 Technische Datenintegrität

Um den Anforderungen des Datenschutzes Genüge zu leisten, muss damit insbesondere die Integrität der Daten technisch sichergestellt werden. Zum Beispiel kann es in einer klinischen Studie notwendig sein, Informationen über einen Patienten redundant an mehreren Orten (z. B. verschiedenen Datenbanken) zu speichern. Dann muss sichergestellt werden, dass alle Instanzen auch nach Modifikation der Daten immer gleich sind. Winter et al. unterscheiden zwischen Objekt- und referenzieller Integrität (Winter et al. 2005).
  • Objektintegrität : Generell muss jedes Objekt in einer Datenbank eindeutig identifizierbar sein. In Datenbanken werden hierzu Primärschlüssel verwendet, die jedem Element einer Datenbanktabelle eine eindeutige Identifikationsnummer (ID) zuordnen (Abb. 3, id). Zusätzlich können in einem Objekt weitere eindeutige Schlüssel, wie z. B. eine PID, definiert werden (Abb. 3, pid).

  • Referentielle Integrität : Die korrekte Zuordnung von Objekten über Referenzen wird als referentielle Integrität bezeichnet (Abb. 3, patient, studie, visite). Zur Gewährleistung von referentieller Integrität ist Objektintegrität zwingend erforderlich.

Abb. 3

UML-Klassendiagramm mit Zuordnung von einem bis n Patienten in keine bis m Studien. Die Studie besitzt eine bis k Visiten, während eine Visite genau einer Studie zugeordnet ist

Moderne Datenbanken bieten entsprechende Möglichkeiten, Primärschlüssel und Referenzen in Objekten zu definieren. Zusätzlich können einzelne Objektattribute u. a. als eindeutig oder notwendig spezifiziert werden.

Datenintegrität wird durch Transaktionsmanagement gewährleistet. Dieses stellt sicher, dass die Datenbank von einem Zustand, in dem alle Integritätsbedingungen erfüllt sind, nur in einen Zustand überführt werden kann, in dem ebenfalls alle Integritätsbedingungen erfüllt sind. Unter Umständen muss hierfür eine Folge atomarer Operationen vollständig (Commit) oder gar nicht (Rollback) ausgeführt werden.

Darüber hinaus wird von formaler Integrität gesprochen, falls die Integritätsbedingungen formal definiert werden (z. B. in Aussagen- oder Prädikatenlogik). In diesem Fall können auch komplexere Bedingungen durch einen Algorithmus überprüft werden.

Prüfsummen werden zur Gewährleistung von Integrität bei der Datenspeicherung und Datenübermittlung aus den Ausgangsdaten berechnet. Somit können Bitfehler in den Daten erkannt werden (Ryan und Frater 2002).

2.3 Systemintegration

Der Begriff der Systemintegration stammt ursprünglich aus den Ingenieurswissenschaften (Maschinenbau, Elektrotechnik) und bezeichnet das Zusammenfügen verschiedener Komponenten und Subsysteme zu einem funktionstüchtigen Ganzen. In der Informatik wird hiermit analog das Zusammenfügen und Verbinden von Systemen, Applikationen und Algorithmen bezeichnet, unabhängig davon, ob dies auf physischer Werkzeugebene, logischer Werkzeugebene oder auf der Anwendungsebene erfolgt (Winter et al. 2005), also ob technisch oder funktionell operiert wird. Winter et al. identifizieren vier Integrationsebenen (Übersicht).

Integrationsebenen

  • Datenintegration in verteilten Systemen bedeutet, dass jedes einzelne Datum, das im Rahmen einer Aufgabe einmal erfasst wurde, innerhalb des Gesamtkontextes nicht wieder erfasst werden muss, auch wenn es im Rahmen dieser oder einer anderen Aufgabe wieder benötigt wird. Das bedeutet, dass einmal erfasste Daten immer dort verfügbar sind, wo sie gerade benötigt werden. In den eCRF einer klinischen Studie werden jedoch viele Daten erneut und wiederholt händisch in das CTMS eingegeben.

  • Funktionsintegration ist gewährleistet, wenn die Funktionalität jedes Systembausteines immer dann und dort genutzt werden kann, wo sie benötigt wird. Hierzu gehört insbesondere die mangelnde Integration binärer Bild- und Signaldaten in EDCS.

  • Präsentationsintegration ist gegeben, wenn unterschiedliche Anwendungsbausteine ihre Daten und ihre Benutzeroberfläche in einheitlicher Weise präsentieren. Auch dies ist bei CTMS und EDCS typischerweise nicht gegeben.

  • Kontextintegration bedeutet, dass beim Wechsel von einem zum anderen Systembaustein eine bereits durchgeführte Aufgabe nicht erneut durchgeführt werden muss. Das Einloggen via Single-Sign-On (SSO) ist hier nur ein Beispiel, aber viel wichtiger ist es beispielsweise, mehrfaches Suchen eines Patienten aus Listen zu vermeiden.

Ein konkretes Beispiel verschiedener Integrationslevel zeigt Abb. 4. Der blau hinterlegte Kernbereich beinhaltet das CTMS sowie Zusatzfunktionen zur Pseudonymisierung und Randomisierung von Studienpatienten. Alle Funktionen werden dem Nutzer via SSO angeboten, die Präsentationsintegration wird über die einheitliche Implementierung der graphischen Benutzeroberflächen (Graphical User Interface, GUI) sichergestellt. Externe Komponenten müssen über proprietäre Schnittstellen (z. B. Java Runtime zum Aufruf kompilierter C++ − Programme oder das Java-R-Interface, JRI) integriert werden. Das EDCS-OpenClinica wird über Web-Services (WS) integriert, die eine Daten-, Funktions- und Kontextintegration unterstützen.
Abb. 4

Systeme und deren Funktions- und Datenintegration für klinische Studien am CTC-A

2.4 Protokolle und Schnittstellen

2.4.1 Operational Data Model

Das Operational Data Model (ODM) ist ein Standard zur Erfassung, zum Austausch und zur Archivierung von Daten in klinischen Studien, der von dem Clinical Data Interchange Standards Consortium (CDISC) entwickelt wurde (Kuchinke et al. 2009). Die Spezifikation des Standards liegt momentan in der Version 1.3.2 vor und ist frei zugänglich (www.cdisc.org/odm).

Das ODM umfasst neben den klinischen Daten (z. B. systolischer Blutdruck = 110) auch die Metadaten einer Studie. Dadurch können auch Informationen über die Daten (z. B. Einheit: mmHg) oder Normbereiche (z. B. systolischer Blutdruck ≤ 120 mm Hg) ausgetauscht werden. Des Weiteren bildet das ODM auch administrative Daten, Referenz- und Auditdaten ab. Der Standard folgt dabei der hierarchischen Struktur einer klinischen Studie (Abb. 5) und umfasst Informationen zur Studie (Study), zur Visite (StudyEvent), zum eCRF (Form), zur Fragegruppe (ItemGroup) und zur Frage (Item). Die Fragen sind aus primitiven Datentypen (z. B. Integer) oder aus komplexeren Konstrukten (z. B. Auswahllisten, sog. CodeLists) aufgebaut.
Abb. 5

Hierarchische Struktur des ODM-Standards (nach (Harmsen 2015))

Als Austauschformat für das ODM wird die Extensible Markup Language (XML) benutzt, die hierarchisch strukturierte Information als Textdatei darstellt. Informationen werden dabei in XML über Elemente (Tags) und Eigenschaften in Form von Schlüssel-Wert-Paaren (Attributes) definiert (Bray et al. 2008). In der klinischen Forschung gibt es viele Einsatzmöglichkeiten für das ODM. Der Standard wird zum Beispiel genutzt, um klinische Daten aus einem EDCS zur Auswertung in ein statistisches Softwaresystem zu transferieren (Löbe et al. 2011). Darüber hinaus werden eCRF als ODM-Metadaten über öffentliche Datenbanken, wie z. B. das Medical Data Model-Portal (medical-data-models.org), ausgetauscht (Bruland et al. 2011).

CDISC entwickelt neben dem ODM auch andere Standards für die klinische Forschung, wie z. B. die Clinical Data Acquisition Standards Harmonization (CDASH), welche die inhaltliche Struktur von Datenbanken in klinischen Studien standardisiert beschreibt.

2.4.2 Web-Services

Ein Web-Service ist ein eigenständiges Softwaremodul, das einen Dienst über ein Netzwerk anbietet, der von anderen Softwaresystemen in Anspruch genommen werden kann (Papazoglou 2008). Im Datenmanagement von klinischen Studien werden Web-Services häufig verwendet, um Kommunikationskanäle zwischen Systemen und somit integrierte Systeme zu schaffen. Zum Beispiel können EDCS die Anzahl der aktuell in einer klinischen Studie eingeschlossenen Patienten über Web-Services weitergeben.

Web-Services folgen der Client–server-Architektur, womit die Dienste immer von einer Serverkomponente angeboten und von einer Clientkomponente genutzt werden. Ein Web-Service ist eine lose gekoppelte Verbindung zwischen den einzelnen Softwarekomponenten. Daher besitzt der Web-Service-Client keine Informationen über die technische Implementierung des Dienstes auf der Serverseite. Er kennt nur die Spezifikation der Schnittstelle.

Grundsätzlich basieren alle Web-Services auf dem Hypertext Transfer Protocol (HTTP) (Richardson und Ruby 2007). Man unterscheidet zwischen Representational State Transfer (REST) und Simple Object Access Protocol (SOAP) Web-Services:
  • REST-basierte Web-Services nutzen nur die vom HTTP-Protokoll angebotenen Methoden POST, GET, PUT und DELETE, um mit dem Server zu interagieren. Die Nachrichten (Envelopes) werden im HTTP-Body kodiert. Die Serverkomponente wird über eine Adresse im Uniform Resource Identifier (URI)-Format identifiziert (Endpoint).

  • SOAP-basierte Web-Services verwenden auch HTTP als Kommunikationsprotokoll. Allerdings sind SOAP-Envelopes immer in einer XML-Struktur aufgebaut. Bei SOAP wird zu Beginn ein Vertrag zwischen beiden Seiten ausgehandelt, der die verfügbaren Methoden und die Struktur der austauschbaren Datentypen in der Web Service Definition Language (WSDL) definiert.

3 Softwaresysteme

3.1 Clinical Trial Management-Systeme (CTMS)

An jede (Medizinprodukte-)Studie, die nach den genannten Regularien durchgeführt wird, werden hohe Qualitätsansprüche gestellt. Ein CTMS unterstützt das gesamte Studienteam in seinen unterschiedlichen Funktionen bei der Planung, Durchführung und Auswertung einer Studie und kann somit als zentrales Werkzeug des Qualitätsmanagements für klinische Studien angesehen werden.

Capterra listet derzeit 22 Web-basierte CTMS, die den Bestimmungen des Health Insurance Portability and Accountability Acts (HIPAA) sowie der Food and Drug Administration (FDA) (insbesondere 21 CFR Part 11) genügen (Best Clinical Trial Management Software 2015). Derartige Systeme stellen kommerzielle Lösungen für große Pharmaunternehmen dar, sind aber zu komplex oder zu teuer, als dass sie in universitären Investigator-Initiated Trials (IIT) , also klinischen Studien, die von den forschenden Ärzten selbst initiiert werden und bei denen die Universitäten die Rolle des Sponsors einnehmen, eingesetzt werden könnten.

Ein CTMS kann je nach Implementierung bzw. Ausführung eine Reihe von zentralen Funktionen abdecken (Abb. 6). Diese Funktionen unterstützen das Management von:
Abb. 6

Die Managementfunktionen (grün) und Funktionskomponenten (rot) eines CTMS (blau) gruppieren sich um die klinische Studie (gelb)

  • Studien, Personen und Zentren: Klinische Studien werden durch viele Nummern und Akronyme identifiziert und müssen unterschiedlichen Anforderungen, Gesetzen und Vorschriften genügen. Der Verlauf einer Studie reicht von der Planung, Beantragung, Durchführung und Auswertung bis hin zur Archivierung. Diese Informationen sowie alle an den Studien beteiligten Personen mit ihren jeweilig studienbezogenen Rollen in den beteiligten Institutionen, die studienspezifisch zu Zentren zusammen gefasst werden, müssen in einer entsprechenden Datenbank modelliert werden. Das CTMS muss die Kommunikation aller Beteiligten unterstützen.

  • Probanden und Patienten: Die Studienteilnehmer (Probanden) werden im CTMS erfasst und verwaltet. Der Datenschutz erfordert Pseudonymisierungsdienste, um die medizinischen Daten von den Patientendaten zu trennen. In vielen Studien werden zudem Randomisierungsdienste benötigt. Die medizinische Datenerfassung ist aber meist in externen EDCS abgebildet, die dann mit dem CTMS gekoppelt werden müssen.

  • Materialien: Verbrauchsmaterial (z. B. Spritzen für die Blutabnahme) oder Untersuchungsgeräte müssen in klinischen Studien stets verfügbar sein und anhand der Einschlusszahlen in eine Studie entsprechend vorgehalten bzw. geplant werden. Daher bieten manche CTMS auch eine integrierte Warenwirtschaftskomponente.

  • Kosten: Die Bezifferung des personellen oder finanziellen Aufwandes einer klinischen Studie ist schwierig. Erfahrungswerte zum Rekrutierungsaufwand können nur empirisch durch genaue Zeiterfassung ermittelt werden. Kostenkataloge für Untersuchungseinheiten sowie für Pauschalen und Versicherungen müssen ebenso vorgehalten werden wie die Vergütungsgruppen der Mitarbeiter, um die Kosten einer speziellen Prüfung vorab abschätzen sowie im Nachhinein exakt ermitteln zu können. Auch die Abrechnung von in Studien erbrachten Leistungen kann durch ein CTMS unterstützt werden.

  • Dokumente: Zu einer klinischen Studie gehören viele Dokumente, die am besten zentral und versioniert vorgehalten werden. Beispiele hierzu sind der Prüfplan, Standard Operation Procedures (SOPs) für die Studiendurchführung und -dokumentation, Randomisierungslisten, aber auch Entblindungs- oder Notfallprozeduren. Weiterhin müssen die in Studien generierten Daten in Berichten zusammengefasst oder in sog. Dashboards visualisiert werden.

3.1.1 Study Management Tool (SMT)

Das Study Management Tool (SMT) ist ein selbstentwickeltes CTMS des CTC-A (Deserno et al. 2011). Bis auf das Warenmanagement bildet das SMT den dargestellten Funktionsumfang von modernen CTMS vollständig ab. So werden im SMT Metadaten zu klinischen Studien sowie alle an den Studien beteiligten Personen und Zentren in ihrer Rolle erfasst. Mit dem Pseudonymisierungsdienst des SMT, welcher den PID-Generator der Technologie- und Methodenplattform für die vernetzte medizinische Forschung e.V. (TMF) einsetzt, lassen sich zudem persönliche Daten von Patienten der klinischen Studien datenschutzgerecht verwalten. Aus den Patientenzahlen werden Einschlussverläufe der Studien in PDF-basierten Berichten (Reports) oder Dashboards visualisiert (Abb. 7). Mit dem Vollkostentool lassen sich außerdem Kosten von klinischen Studien in der Planungsphase modellieren und während der Laufzeit der Studie automatisch abrechnen (Deserno et al. 2012b). Technisch gesehen wurde das SMT mithilfe des Google Web Toolkits (GWT) entwickelt, welches es erlaubt, Webanwendungen vollständig in der Programmiersprache Java zu entwickeln. Die Daten werden auf Serverseite in einer MySQL-Datenbank gehalten.
Abb. 7

Verlauf der Einschlusszahlen einer klinischen Studie im SMT

3.2 Electronic Data Capture-Systeme (EDCS)

EDCS ersetzen die traditionelle Datenerfassung auf papierbasierten Fragebögen (CRF) durch elektronischen Fragebögen (eCRF) (Ene-Iordache et al. 2009). Bereits während der Eingabe können die Daten durch Regeln auf Korrektheit geprüft werden (z. B. Wertebereichsprüfungen). Nach der Dateneingabe liegen die Daten direkt in maschinenlesbarer Form vor und können ausgewertet werden. Insgesamt hat sich gezeigt, dass die Datenerfassung in eCRF die Datenqualität in klinischen Studien erheblich erhöht und gleichzeitig Zeit und Kosten spart (Shah et al. 2010; Pavlović et al. 2009). Oftmals werden EDCS als Web-Anwendungen realisiert, was eine verteilte Dateneingabe in multi-zentrischen Studien vereinfacht. Zu den bekanntesten EDCS gehören Oracle Clinical, Oracle InForm, Medidata Rave, REDcap, secuTrial und OpenClinica.

Rechte und Rollen

Typischerweise werden innerhalb eines EDCS verschiedene Rechte über Rollen vergeben. Zu den Rechten gehören beispielweise das Recht, ein eCRF nicht nur lesen, sondern auch schreiben zu dürfen. Darüber hinaus sind weitere Funktionen, wie z. B. die Administration von Zugängen, über einzelne Rechte definiert. Rollen gruppieren diese Rechte und werden auf Funktionen des medizinischen Personals abgebildet. So kann die Rolle „Monitor“ die Daten des eCRF nur einsehen, diese aber nicht verändern. In vielen EDCS können einzelnen Benutzern unterschiedliche Rollen in verschiedenen Studien zugeteilt werden.

AuditTrail

Alle Datenmodifikationen werden in modernen EDCS in einem Prüfprotokoll (AuditTrail) erfasst. Dies bedeutet, dass jede Aktion eines Nutzers, der die Daten modifiziert, zusammen mit einer Nutzeridentifikation und einem Zeitstempel (Timestamp) protokolliert wird. Damit kann der Datenstand jederzeit in frühere Revisionen überführt werden, was im deutschen Datenschutzrecht explizit gefordert wird.

Query-Management

Moderne EDCS verfügen über Funktionalität zum Management von Anfragen (Query, auch Discrepancy Notes genannt). Um eine hohe Datenqualität direkt bei der Eingabe zu erzielen, sind in einem eCRF oft viele Regeln hinterlegt. In Sonderfällen kann dies aber bedeuten, dass ein Datum nicht vom System akzeptiert wird, obwohl es am Patienten erfasst wurde. In diesem Fall kann eine Query an einen anderen Nutzer (z. B. Prüfarzt) gestellt werden, der hierdurch über die Ausnahme informiert wird und entscheiden kann, ob die Regel ausnahmeweise ausgesetzt wird.

Auswertung

Zur Auswertung lassen sich die erfassten Daten aus dem EDCS exportieren. Typische Ausgabeformate sind dabei einfache Textdateien (z. B. Comma-Separated Value[CSV]-Files), Tabellen (z. B. im Microsoft Excel[XLS]-Format), XML-Dateien nach ODM-Standard oder proprietäre Dateitypen für Software für statistische Auswertungen (z. B. im Statistical Package for the Social Sciences[SPSS]-Format).

3.2.1 OpenClinica

OpenClinica (www.openclinica.com) ist ein populäres EDCS, da es als Open-Source-Produkt kostenlos in der Community Edition bereitgestellt wird, was besonders für die IIT interessant ist (Leroux et al. 2011; Franklin et al. 2011). Darüber hinaus gibt es auch eine kommerzielle Enterprise-Edition mit weitergehendem Support und Zertifizierungsmöglichkeiten. Beide Editionen decken mit Funktionalität zur Rechte- und Rollenmodellierung, Datenprotokollierung im Audit Trail, Query-Management und Datenexport den beschriebenen notwendigen Funktionsumfang von modernen EDCS ab.

Als EDCS erlaubt OpenClinica die Modellierung von eCRF, die dann über ein Web-Interface zur Datenerfassung bereitgestellt werden. Über das Web-Interface werden auch Metadaten und administrative Daten der Studien verwaltet. Die eCRF werden in OpenClinica über Microsoft Excel-Sheets modelliert. Dafür sieht OpenClinica eine eigene Syntax vor, mit der sich Typen von Datenfeldern (z. B. Ganzzahlfelder) und weitergehende Eigenschaften (z. B. Normbereiche) definieren lassen. Die Excel-Sheets werden von OpenClinica geparst und geprüft. Danach können den Visiten eCRF-Formulare zugeordnet werden (Abb. 8, oben). Die Webmasken zur Dateneingabe werden automatisch gerendert (Abb. 8, unten). Die OpenClinica-Webanwendung basiert auf Java Server Pages (JSP) und ist modular strukturiert. Neben dem Core-Paket, das die Basisfunktionalität des EDCS beinhaltet, gibt es noch ein zusätzliches Web-Service-Paket, das SOAP- und REST-basierte Schnittstellen zur Systemintegration bereitstellt.
Abb. 8

OpenClinica Patientenübersicht mit Status der Dateneingabe (oben, Subject Matrix) und ein OpenClinica eCRF mit Daten (unten)

Zum Austausch mit anderen Systemen lassen sich die Daten in verschiedensten Formaten exportieren, z. B. ODM, CSV oder SPSS. In der aktuellsten Version 3.5 bietet OpenClinica auch die Möglichkeit, elektronische Patient Reported Outcome(ePRO)-Versionen der eCRF zur Dateneingabe außerhalb von OpenClinica (z. B. auf Smartphones oder Tablets) bereitzustellen.

OpenClinica wird durch eine große User-Community unterstützt, die das EDCS durch Add-Ons erweitert. Die Erweiterungen reichen von Skripten (Trial Data 2015), die spezifische Felder in der Visualisierung oder Funktionalität erweitern, zu Tools, die das EDCS um vollfunktionsfähige Module anreichern. Derzeit sind ca. 30 solcher Module gelistet (Extensions/Open Source Clinical Trials Software/OpenClinica 2015).

Auf der Skriptebene lässt sich z. B. die Ausrichtung von Antwortmöglichkeiten von Datenfeldern modifizieren (Abb. 9, oben) oder die Eingabe in ein Zahlenfeld durch einen Schieberegler (Slider Bar) visualisieren (Abb. 9, Mitte). Zudem ist es möglich, Beziehungen zwischen integrierten Bildern und Datenfeldern zu definieren, sodass eine Eingabe in das Feld unmittelbar durch eine Visualisierung unterstützt wird, und umgekehrt, die Eingabe in das Datenfeld durch Interaktion mit dem Bild erfolgen kann (Abb. 9, unten).
Abb. 9

OpenClinica-Erweiterungen auf der Skriptebene

Eine andere Erweiterung ist der OC Unit Calculator, der in ein eCRF integriert werden kann, um automatisch Zahlenwerte von einer Einheit in eine andere Einheit umzurechnen. Darüber hinaus erlaubt das Add-On OC-Big große Datenmengen stabil und sicher in ein eCRF zu integrieren (Haak et al. 2013). OC-Big ist auch als Open Source lizensiert und frei verfügbar (idmteam.github.io/oc-big). Das Add-On ersetzt OpenClinicas native File-Komponente, wodurch das Datenvolumen, das sich in das eCRF integrieren lässt, nur durch den freien Speicherplatz auf dem OpenClinica-Server begrenzt ist. Somit ist es möglich, neben den medizinischen Daten auch große Bild- und Signaldaten direkt im eCRF zu erfassen, z. B. im Digital Imaging and Communications in Medicine(DICOM )-Standard.

Darüber hinaus wurde eine Systemarchitektur vorgestellt, die OpenClinica mit dem PACS DCM4CHEE (Home – dcm4chee-2.x – Confluence 2015) und dem DICOM-Viewer Weasis (Home – Weasis – Confluence 2015) verbindet (Haak et al. 2015). Dadurch können 2D-Bilder (z. B. Röntgenaufnahmen) oder 3D-Bilddaten (z. B. CT, MRT) direkt aus dem eCRF heraus adäquat visualisiert und durch erweiterte Funktionalität (z. B. Annotation, Winkel- oder Distanzmessung) ausgewertet werden.

3.3 Data Warehouse

Ein Data Warehouse fasst Informationen aus verschiedenen Quellen in einer zur Entscheidungsfindung optimierten Datenbank zusammen (Farkisch 2011). Die Datenbanken werden genutzt, um Wissensbasen zur strategischen Steuerung und Koordination von Unternehmen aufzubauen (Navrade 2008). Nach einer Analyse von Gartner aus dem Jahre 2015 gehören Oracle, Teradata, IBM, Microsoft und SAP zu den führenden Herstellern von Data-Warehouse-Systemen und -Komponenten (Beyer und Edjlali 2015). Die Nachfolgende Übersicht führt die wichtigsten Eigenschaften eines Data Warehouse auf:

Eigenschaften eines Data Warehouse

  • Themenorientiertheit: Ausgehend von einer zweckneutralen Darstellung werden die Daten für konkrete Themen logisch und physisch organisiert. In der Regel wird hier eine aufgabenspezifische, multidimensionale Sicht auf die Daten mit einer Unterscheidung von quantifizierbaren Kennzahlen (Daten) und beschreibenden Informationen (Metadaten) erzeugt.

  • Integration: Die Daten können aus vielen heterogenen Quellen und (Fremd-)Systemen stammen, werden aber in einheitliche Formate transformiert und folgen danach den gleichen Regeln und Konventionen.

  • Zeitabhängigkeit: Die Daten eines Data Warehouse werden nicht in Echtzeit verarbeitet, sondern stellen einen „Schnappschuss“ eines festen Zeitpunktes oder -raumes dar. Um eine Vergleichbarkeit über die Zeit zu gewährleisten, müssen die Daten über einen längeren Zeitraum erfasst und gespeichert werden.

  • Nichtflüchtigkeit: Daten, die einmal in das Data Warehouse eingebracht wurden, können weder modifiziert noch entfernt werden.

Besonders im medizinischen Umfeld spielen Date-Warehouse-Lösungen eine wichtige Rolle (Wagner 2003). In Unternehmen der Gesundheitsversorgung und -wissenschaften werden betriebswirtschaftliche und medizinische Daten in Data Warehouses zusammengeführt, um zum Beispiel Behandlungsabläufe von Patienten in der Routine zu analysieren und darauf basierend strategische Maßnahmen zu treffen.

Die technische Infrastruktur eines Data Warehouse wird als Data-Warehouse-System bezeichnet. Data-Warehouse-Systeme bestehen typischerweise aus drei Ebenen (Übersicht).

Ebenen eines Data-Warehouse-Systems

  • Datenbereitstellung: Die Ebene der Datenbereitstellung ist zuständig für die Extraktion der Daten aus den Quellsystemen, die Transformation in homogene Formate und das Laden in das Data Warehouse. Die Komponenten der Datenbereitstellung nennt man daher auch ETL-Werkzeuge (Extraktion, Transformation, Laden).

  • Datenhaltung: Die Datenhaltungsebene stellt die Speicherung der Daten im Data Warehouse und der Metadaten im sogenannten Repositorium oder Data Dictionary sicher.

  • Informationsanalyse und -präsentation: Die Ebene der Informationsanalyse und -präsentation ist für die Analyse und Auswertung der Daten verantwortlich. Zu den Analysewerkzeugen (Business Intelligence Tools) gehören Data Access-, Online Analytical Processing(OLAP)- und Data Mining-Verfahren. Zur flexiblen Präsentation der Daten wird im Data-Warehouse-System ein multidimensionaler Datenraum (Data Cube) aufgebaut, durch den sich mit Roll-Up, Drill-Down, Drill-Across, Pivotierung/Rotation oder Slice/Dice navigieren lässt. So können individuelle Sichten erstellt werden.

3.4 mHealth

Mobile Health (mHealth) umfasst alle medizinischen Verfahren und Maßnahmen der Gesundheitsfürsorge, die durch portable, mobile Geräte wie Smartphones, Tablets oder persönliche digitale Assistenten (PDA) unterstützt werden. Smartphones verfügen heute über eine Vielzahl von Sensoren, die Ton (Audio), Bild (Video), Position (GPS), Bewegung (Beschleunigung) und Temperatur umfassen und über Bluetooth oder Nahfeldkommunikation (NFC) mit vielen anderen Sensoren (z. B. für Blutdruck, Pulsrate, Körpertemperatur, EKG) erweitert werden können. Über das Internet können Programme (Apps) installiert oder per Fremdzugriff aufgerufen werden, um diese Daten zu verarbeiten und zu transferieren. In Kombination mit der WLAN- oder UMTS-basierten Streaming-Technologie und den Retina-Displays, die unterhalb der vom Menschen erkennbaren Auflösungsgrenze mit exzellenter Farbbrillianz arbeiten, können auch rechenzeitintensive Prozesse – wie interaktive 3D-Darstellung von medizinischen Bilddaten in Echtzeit – auf Smart Devices bereitgestellt werden. mHealth ist damit Teil der elektronischen Gesundheitsinitiative (eHealth).

mHealth-Anwendungen können einerseits Produkte der Medizintechnik sein, die in klinischen Studien evaluiert werden sollen, oder andererseits als integrativer Systemteil bei der Evaluierung selbst eingesetzt werden. Derzeit sind über 97.000 Apps mit Gesundheitsbezug verfügbar und monatlich kommen ca. 1000 weitere hinzu (Becker et al. 2014), sodass es müßig ist, hier allgemeingültige Referenz-Apps identifizieren zu wollen. Die folgenden Beispiele sind exemplarisch.

Jonas et al. beschreiben eine Smartphone-App für den Einsatz in Entwicklungsländern, die eine bildbasierte Diagnose durchführt (Jonas et al. 2015). Mit der integrierten Kamera werden dabei Fotos von auf Papier gefärbten Urinproben erstellt, das Papier wird ausgewaschen, und die verbleibende Färbung wird aus einer weiteren Aufnahme bestimmt. Aus dem Vergleich wird ein krankheitsspezifischer Parameter berechnet und die Diagnose wird auf dem Display des Smartphones angezeigt. Die Firma Philips bietet im App-Store eine App zum Verkauf, die aus einem „Selfie“ im Videomodus die zeitlichen Änderungen der Hautrötungen und daraus die Pulsfrequenz zuverlässig ermittelt (Vital Signs Camera – Philips 2015).

In beiden Beispielen erfolgen Aufnahme und Berechnung auf dem Smartphone im Offline-Betreib, also ohne dass eine Internetverbindung bestehen müsste.

Die mobile Verfügbarmachung von eCRF für klinische Studien in der Medizintechnik ist ein Beispiel für die zweite Kategorie. Wenn Patienten Teile von Fragebögen selber ausfüllen (ePRO) ist dies ein weiteres Anwendungsbeispiel solcher Technologien. Hierbei muss erreicht werden, dass Daten in Online- und Offline-Betrieb sicher erfasst und im eCRF auch richtig zugeordnet werden. Das ODM ist jedoch auf die Struktur und Inhalte von eCRF beschränkt und modelliert nicht die nötigen Layout- und Design-Informationen, die zur Portabilität der Anwendungen erforderlich sind. Auch können Regeln und Datenprüfungen im CDISC ODM nicht vollständig abgebildet werden. In jüngsten Forschungsarbeiten wurde eine entsprechende Erweiterung des Standards vorgeschlagen (Harmsen 2015). Abb. 10 zeigt den Ansatz: Aus dem EDCS werden die verfügbaren Informationen extrahiert. Ein domänenspezifischer Konverter erzeugt neben der reinen ODM-Datei eine ebenfalls als XML aufgebaute Datei, die XML Retrieve Data Form (XRDF), aus der dann gerätespezifische Darstellungen der elektronischen Datenerfassungsblätter gerendert werden.
Abb. 10

XML Retrieve Data Forms (XRDF) ermöglichen die gleichartige Darstellung von eCRF auf unterschiedlichen Plattformen (OpenClinica, HTML-basierte Webdarstellung im Browser, LaTeX-basiertes PDF, Android-App)

3.5 Systemintegration

In diesem Abschnitt wird am Beispiel der IT-Landschaft des CTC-A (Abb. 11) illustriert, wie sich die vorgestellten Stand-Alone-Systeme für das Datenmanagement (Abschn. 3) über die vorgestellten Schnittstellen und Protokolle (Abschn. 2.4) integrieren lassen. Ziel ist es, eine möglichst vollständige Integration auf Daten-, Kontext-, Funktions- und Präsentationsebene (Abschn. 2.3) zu erreichen.
Abb. 11

Die IT-Landschaft am CTC-A integriert als CTMS (blau) das Study-Management-Tool (SMT), als EDCS das OpenClinica-System (rot) und verschiedene mHealth-Anwendungen (grün)

3.5.1 CTMS und EDCS

CTMS dienen zum Management von klinischen Studien, während EDCS die eCRF zur Datenerfassung einer konkreten klinischen Studie bereitstellen. Im CTMS sind also Metadaten der klinischen Studie erfasst, die redundant im EDCS gehalten werden müssen, z. B. Name der Studie, sowie Personen, die an der Studie beteiligt sind und deren Rollen. Auf der anderen Seite hält das EDCS auch Informationen bereit, die für das Management von klinischen Studien wichtig sind, wie z. B. die Anzahl aktuell eingeschlossener Patienten in einer Studie bzw. den zeitlichen Rekrutierungsverlauf.

Durch eine Zuordnung der einzelnen Datenfelder zwischen CTMS und EDCS (z. B. Abbildung der Rolle „Research Assistant“ im SMT auf „Data Entry Person“ in OpenClinica) lässt sich eine Schnittmenge definieren, die zwischen beiden Systemen automatisch synchronisiert werden kann (Deserno et al. 2012a). Hierzu bieten sich SOAP-Web-Services an. Viele Endpoints werden bereits von den OpenClinica Web-Services angeboten (SOAP Web Services/OpenClinica Reference Guide 2015). Beispielsweise kann eine Liste aller Patienten und deren Einschlussdaten aus einer OpenClinica-Instanz über die listAll()-Methode im StudySubject-Endpoint abgerufen werden. Diese Informationen werden verwendet, um Verläufe der Patienteneinschlüsse im SMT in Diagrammen zu visualisieren. Zum Austausch der gemeinsamen Daten sind allerdings weitere Schnittstellen erforderlich. Daher wurde ein vollständig neuer Endpoint User mit den Methoden listAll() und create() hinzugefügt und der Study-Endpoint um die Methoden create() und addUserToStudy() erweitert. Auf der Seite des SMT lassen sich entsprechende Interfaces auf Basis der WSDL-Spezifikationen mittels der JAX-WS-Bibliothek (jax-ws.java.net/) für Web-Service-Funktionalität in Java-Anwendungen schnell und einfach implementieren. Die gemeinsame Datenmenge kann zudem auch für einen SSO vom SMT in OpenClinica verwendet werden: Über JavaScript lässt sich der Login in eine OpenClinica-Instanz für eine konkrete Person simulieren. Damit müssen alle gemeinsamen Daten nur einmal definiert werden, und die Nutzer können sich automatisch aus dem SMT in OpenClinica anmelden.

3.5.2 CTMS und mHealth

Sicher ist es nicht sinnvoll, die ganze Datenmächtigkeit und Funktionalität eines CTMS in einer mobilen Anwendung anzubieten. Allerdings lassen sich recht schnell kompakte und anwendungsorientierte Apps entwickeln, die spezifische Daten aus dem CTMS abrufen und für die Touch-Bedienung optimiert auf einem Smartphone oder Tablet darstellen.

Am CTC-A wurde zum Beispiel eine Dashboard-App entwickelt, die es erlaubt, aktuelle Statistiken zu klinischen Studien aus dem CTMS abzurufen und auf Smartphones oder Tablets übersichtlich darzustellen. Die verantwortlichen Personen sind schnell, einfach und überall über den aktuellen Status ihrer Studien informiert, denn an der Tendenz der Einschlusszahlen kann der potenzielle Erfolg oder Misserfolg einer Studie abgeschätzt werden (Abb. 12). Die Einschlusszahlen werden aus unterschiedlichen EDCS-Systemen im CTMS zusammengeführt und dann zentral bereitgestellt. Das CTMS übernimmt also die Funktion eines Kommunikationsservers im Forschungsinformationssystem. Hierfür wurde ein StudyStatistics-Endpoint implementiert, der über die Web-Service-Methode listAll() für eine konkrete Studie alle Patientenzahlen zurückgibt. Die Daten können dabei auch nach spezifischen Kriterien (z. B. Studienarme) stratifiziert werden. Eine Authentifizierung stellt sicher, dass Personen nach Login über die App nur Statistiken zu den für sie sichtbaren Studien abrufen können.
Abb. 12

Mobile Dashboard-App zur Visualisierung von Einschlusszahlen in klinische Studien. Die Daten werden im CTMS aus verschiedenen EDCS zusammengeführt und der App via Web-Services bereitgestellt

3.5.3 EDCS und mHealth

Auch wenn heutige EDCS als Webanwendungen entworfen werden und eine dezentrale Nutzung erlauben, hat die Dateneingabe über mobile Geräte mithilfe von mHealth-Apps weitere Vorteile. So können zum Beispiel Wundverläufe über die im Smartphone integrierte Kamera dokumentiert und die Fotos direkt am Krankenbett dem eCRF hinzugefügt werden. Darüber hinaus können Tablets genutzt werden, um eCRF direkt von Patienten selber während des Aufenthalts im Wartezimmer (ePRO) auszufüllen. Für das CTC-A wurden mit OC ToGo, OC Tab und XML Retrieve Data Forms verschiedene Ansätze entwickelt, um eine mobile Dateneingabe in eCRF zu ermöglichen.

OC ToGo ist eine App, die es erlaubt, Bilddaten direkt vom Smartphone aus in das eCRF zu integrieren (Haak et al. 2014a). Dabei werden die Bilder mit der integrierten Kamera des Smartphones aufgenommen, mit ihrem Kontext (Studie, Visite, Patient) verknüpft, zum OpenClinica-Server transferiert und in das entsprechende eCRF eingebunden. Zur Zwischenspeicherung im Offline-Modus werden die Bilder in einem App-internen Speicherbereich abgelegt, der von keiner anderen Applikation gelesen werden kann, sodass auch der Datenschutz ausreichend gesichert ist. Darüber hinaus kann OC ToGo in Kombination mit Bildanalysealgorithmen (Hadjiiski et al. 2015) den Kontext des Bildes automatisch aus dem Bar-Code einer im Bild positionierten Farbtafel und einer hinterlegten Zuordnungstabelle bestimmen, sodass die Fotos automatisch dem richtigen Probanden zugeordnet werden können.

OC Tab ermöglicht es, in OpenClinica entworfene eCRF zur Dateneingabe auf Smartphones und Tablets darzustellen (Haak et al. 2014b). Die mHealth-App nutzt dabei das ODM-Format zum Transfer der Metadaten auf das mobile Gerät. Nach der, auch offline möglichen, Dateneingabe werden diese ins EDCS zurückgespielt. OC Tab nutzt dafür den ODM Metadata REST-Web-Service von OpenClinica, der die komplette Struktur der eCRF einer klinischen Studie im ODM-Format ausgibt. OC Tab parst die ODM-Datei und visualisiert entsprechende Elemente zur Dateneingabe auf dem Android-Gerät. Nach der Eingabe werden die Daten in ODM eingebettet und an den importData(n SOAP-Endpoint von OpenClinica zurück gesendet. Zur Offline-Dateneingabe werden die ODM-Dateien auf dem mobilen Gerät im privaten Speicherbereich der App abgelegt.

OC Tab ist auf OpenClinica zugeschnitten. Mit XRDF können weitergehende Metadaten von eCRF, wie z. B. Regeln oder Berechnungen zwischen Datenfelder, auf die mobilen Devices übertragen werden (Harmsen 2015). Die XRDF-Metadaten werden zu den ODM-Elementen in Bezug gesetzt. Damit ist die Dateneingabe in einheitlicher Darstellung auch auf verschiedenen Geräten möglich, z. B. als eCRF im Web (HTML), auf mobilen Geräten (Android, iOS) und als PDF-Dokument auf Papier (Abb. 13).
Abb. 13

Ausgehend vom eCRF in OpenClinica (oben links) werden die gleichartigen Darstellungen mit HTML im Web (oben rechts), auf Android (unten rechts) oder als LaTeX-basiertes PDF (unten links) erzeugt

4 Resümee und Ausblick

In diesem Kapitel haben wir die gesetzlich vorgeschriebene Vorgehensweise zur klinischen Prüfung von Medizinprodukten sowie einzelne IT-Komponenten zur Unterstützung des Datenmanagements in klinischen Studien kennengelernt. Es wurde deutlich, dass die IT-Systeme geeignet miteinander zu koppeln sind, um ihrer Aufgabe effizient gerecht zu werden, hierzu aber – im Gegensatz zur Routine der Patientenversorgung – keine geeigneten Schnittstellen etabliert sind. Das Ziel aller Informationssysteme wird über die sog. 5R-Regel definiert: Die richtige Information zur richtigen Zeit am richtigen Ort der richtigen Person in der richtigen Form zur Verfügung zu stellen (Jehle 2015). Dies ist derzeit in der klinischen Forschung noch nicht erreicht und wird daher auch in Zukunft für Medizinproduktestudien wichtig bleiben.

Weiterhin ist deutlich geworden, dass das Volumen der zu verarbeitenden Daten in klinischen Studien weiter zunehmen wird, denn die zu bewertenden Medizinprodukte werden selbst immer mehr Daten erzeugen. Nach McKinsey gehören die in klinischen Studien erfassten Daten zu den vier primären Datenquellen, die den Hauptbeitrag zur „Big Data“-Revolution im Gesundheitswesen leisten werden (Groves et al. 2013). Wikipedia definiert den Begriff Big Data als Datenmengen, die zu groß, zu komplex oder zu flüchtig sind, um sie mit klassischen Methoden der Datenverarbeitung auszuwerten. Bereits heute werden riesige Datenmengen erfasst (Murdoch und Detsky 2013). Das gilt insbesondere für das Gesundheitswesen (Raghupathi und Raghupathi 2014).

Ein weiterer Zukunftsaspekt im Datenmanagement der Medizinprodukte selbst sowie der klinischen Prüfung solcher Produkte ist die Kopplung von Daten, die in den Studien erfasst werden, mit den Daten, die im Rahmen der direkten Gesundheitsversorgung entstehen. Bereits jetzt enthalten digitale Patientenakten (Electronic Health Records, EHRs ) wertvolle medizinische Daten, die mit in klinische Studien einfließen könnten (Murdoch und Detsky 2013). Studiendaten müssen andererseits auch den Ärzten der Gesundheitsversorgung direkt zugänglich gemacht werden.

Mithilfe von mHealth-Apps werden in Zukunft Vitaldaten von Patienten 24 Stunden am Tag und sieben Tage in der Woche erfasst, wodurch weitere große Datenmengen entstehen werden, die der Bezeichnung Big Data gerecht werden. Das Datenmanagement in klinischen Studien muss sich weiterentwickeln, um diesen Änderungen gerecht zu werden. Wir sehen hier vor allem drei Aspekte:
  • Die Systeme zur Erfassung und Verwaltung von Patientendaten (EDCS) und administrativen Daten (CTMS) müssen um Methoden erweitert werden, große Datenmengen zusammenzuführen und zu verarbeiten. Die reine Datenanalyse heutiger Data-Warehouse-Systeme ist nicht ausreichend.

  • Die Integration der IT-Systeme des Datenmanagements benötigt standardisierte Schnittstellen, damit heterogene Datenquellen zu einer großen, einheitlich strukturierten Datenmenge zusammengefasst werden können.

  • Die Techniken für den Datenschutz (z. B. Pseudonymisierung) müssen erweitert werden, damit Gesundheitsdaten für Forschungsfragen besser genutzt werden können und gleichzeitig sichergestellt bleibt, dass die Persönlichkeitsrechte des Patienten unberührt bleiben.

Falls diese Anforderungen erfüllt sind, bietet Big Data besonders für klinische Studien die Chance, gezielt wertvolle Informationen aus bereits existierenden Daten mit in die Wissensfindung aufzunehmen und dieses Wissen, wie durch die 5R gefordert, optimal auszugeben.

Literatur

  1. Becker S, Miron-Shatz T, Schumacher N, Krocza J, Diamantidis C, Albrecht UV (2014) mHealth 2.0: experiences, possibilities, and perspectives. JMIR Mhealth Uhealth 2(2):e24. doi:10.2196/mhealth.3328CrossRefGoogle Scholar
  2. Best Clinical Trial Management Software (2015) Reviews of the most popular systems. http://www.capterra.com/clinical-trial-management-software/. Zugegriffen am 30.07.2015
  3. Beyer MA, Edjlali R (2015) Magic quadrant for data warehouse and data management solutions for analytics. https://www.gartner.com/doc/2983817/magic-quadrant-data-warehouse-data. Zugegriffen am 30.07.2015
  4. Bray T, Paoli J, Sperberg-McQueen CM, Maler E, Yergeau F (2008) Extensible markup language (XML) 1.0, 5. Aufl. W3C recommendationGoogle Scholar
  5. Bruland P, Breil B, Fritz F, Dugas M (2011) Interoperability in clinical research: from metadata registries to semantically annotated CDISC ODM. Stud Health Technol Inform 180:564–568Google Scholar
  6. Bundesamt für Sicherheit in der Informationstechnik (BSI) (Hrsg) (2011) IT-Grundschutz-Kataloge. 12. Ergänzungslieferung, Stand September 2011. www.bsi.bund.de/grundschutz
  7. Der Innenminister des Landes Nordrhein-Westfalen (Hrsg) (1999) Gesetz zum Schutz personenbezogener Daten im Gesundheitswesen (Gesundheitsdatenschutzgesetz – GDSG NRW) in der Fassung vom 22. Februar 1994, § 2 geändert durch Gesetz vom 17. Dezember 1999, DüsseldorfGoogle Scholar
  8. Der Innenminister des Landes Nordrhein-Westfalen (Hrsg) (2000) Gesetz zum Schutz personenbezogener Daten (Datenschutzgesetz Nordrhein-Westfalen – DSG NRW) in der Fassung der Bekanntmachung vom 9. Juni 2000, DüsseldorfGoogle Scholar
  9. Deserno TM, Becker K (2009) Medizinisches Datenmanagement. Begleitheft zum Praxishandbuch. Apollon Hochschule der Gesundheitswirtschaft, BremenGoogle Scholar
  10. Deserno T et al (2011) IT-Unterstützung für translationales Management klinischer Studien auf Basis des Google Web Toolkits. In: 56. Jahrestagung der Deutschen Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie (gmds), 6. Jahrestagung der Deutschen Gesellschaft für Epidemiologie (DGEpi); 2011 Sep 26–29; Mainz, Deutschland. Doc11gmds023. doi: 10.3205/11gmds023Google Scholar
  11. Deserno T, Samsel C, Haak D, Spitzer K (2012a) Daten-, Funktions- und Kontextintegration von OpenClinica mittels Webservices. In: GMDS 2012. 57. Jahrestagung der Deutschen Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie e.V. (GMDS). Braunschweig, 16.–20.09.2012. German Medical Science GMS Publishing House, DüsseldorfGoogle Scholar
  12. Deserno V et al. (2012b) Umsetzung und Programmierung einer IT-basierten Vollkostenkalkulation für klinische Studien. In: 57. Jahrestagung der Deutschen Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie e.V. (GMDS). Braunschweig, 16.–20.09.2012. German Medical Science GMS Publishing House, Düsseldorf. Doc12gmds223Google Scholar
  13. Drepper J, Semler SC (Hrsg) (2013) IT-Infrastrukturen in der patientenorientierten Forschung. Aktueller Stand und Handlungsbedarf – 2012/2013. Akademische Verlagsgesellschaft AKA, BerlinGoogle Scholar
  14. Ene-Iordache B, Carminati S, Antiga L, Rubis N, Ruggenenti P, Remuzzi G et al (2009) Developing regulatory-compliant electronic case report forms for clinical trials: experience with the demand trial. J Am Med Inform Assoc 16(3):404–408CrossRefGoogle Scholar
  15. Extensions/Open Source Clinical Trials Software/OpenClinica. https://community.openclinica.com/extensions. Zugegriffen am 30.07.2015
  16. Farkisch K (2011) Data-Warehouse-Systeme kompakt: Aufbau, Architektur, Grundfunktionen. Springer, BerlinCrossRefGoogle Scholar
  17. Franklin JD, Guidry A, Brinkley JF (2011) A partnership approach for electronic data capture in small-scale clinical trials. J Biomed Inform 44:103–108CrossRefGoogle Scholar
  18. Groves P, Kayyali B, Knott D, Van Kuiken S (2013) The ‚big data‘ revolution in healthcare. McKinsey QGoogle Scholar
  19. Haak D, Gehlen J, Sripad P, Marx N, Deserno T (2013) Erweiterung von OpenClinica zur kontext-bezogenen Integration großer Datenmengen. In: GMDS 2013. 58. Jahrestagung der Deutschen Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie e.V. (GMDS). Lübeck, 01.-05.09.2013. German Medical Science GMS Publishing House, DüsseldorfGoogle Scholar
  20. Haak D, Gehlen J, Jonas S, Deserno TM (2014a) OC ToGo: bed site image integration into OpenClinica with mobile devices. In: SPIE medical imaging: SPIE, p 903909 (SPIE proceedings)Google Scholar
  21. Haak D, Dovermann J, Kramer C, Merkelbach K, Deserno T (2014b) Datenerfassung in klinischen Studien in ODM-unterstützende Systeme mit Tablets und Smartphones. In: GMDS 2014. 59. Jahrestagung der Deutschen Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie e.V. (GMDS). Göttingen, 07.-10.09.2014. German Medical Science GMS Publishing House, DüsseldorfGoogle Scholar
  22. Haak D, Page C, Reinartz S, Krüger T, Deserno TM (2015). DICOM for clinical research: PACS-integrated electronic data capture in multi-center trials. J Digit Imaging (Epub vor Druck)Google Scholar
  23. Hadjiiski LM, Tourassi GD, Jose A, Haak D, Jonas S, Brandenburg V et al (2015) Human wound photogrammetry with low-cost hardware based on automatic calibration of geometry and color. In: SPIE medical imaging: SPIE, p 94143 J (SPIE proceedings)Google Scholar
  24. Harmsen (2015) A presentation semantic for the operational data model (ODM). Masterarbeit, Institut für Medizinische Informatik, Uniklinik RWTH AachenGoogle Scholar
  25. Home – dcm4chee-2.x – Confluence. http://www.dcm4che.org/confluence/display/ee2/Home. Zugegriffen am 30.07.2015
  26. Home – Weasis – Confluence. http://www.dcm4che.org/confluence/display/WEA/Home. Zugegriffen am 30.07.2015
  27. Jehle R (2015) Medizinische Informatik kompakt: Ein Kompendium für Mediziner, Informatiker, Qualitätsmanager und Epidemiologen. De Gruyter, BerlinCrossRefGoogle Scholar
  28. Jonas SM, Deserno TM, Buhimschi CS, Makin J, Choma MA, Buhimschi IA (2015) Smartphone-based diagnostic for preeclampsia: an mHealth solution for administering the Congo Red Dot (CRD) test in settings with limited recources. JAMIA (Epub vor Druck)Google Scholar
  29. Kuchinke W, Aerts J, Semler SC, Ohmann C (2009) CDISC standard-based electronic archiving of clinical trials. Methods Inf Med 48(5):408–413CrossRefGoogle Scholar
  30. Leroux H, McBride S, Gibson S (2011) On selecting a clinical trial managementsystem for large scale, multicenter, multi-modal clinical research study. Stud Health Technol Inform 168:89–95Google Scholar
  31. Löbe M, Aßmann C, Beyer R, Gaebel J, Kiunke S, Lensing E et al (2011) Einsatzmöglichkeiten von CDISC ODM in der klinischen Forschung. In: Tagungsband der 57. Jahrestagung der Deutschen Gesellschaft für Medizinische Informatik. Biometrie und Epidemiologie e.V. (GMDS), Braunschweig, S 1294–1304Google Scholar
  32. Medizinproduktegesetz in der Fassung der Bekanntmachung vom 7. August 2002 (BGBl. I S. 3146), das zuletzt durch Artikel 16 des Gesetzes vom 21. Juli 2014 (BGBl. I S. 1133) geändert worden ist. Neugefasst durch Bek. v. 7.8.2002 I 3146; zuletzt geändert durch Art. 16 G v. 21.7.2014 I 1133Google Scholar
  33. Murdoch TB, Detsky AS (2013) The inevitable application of big data to health care. JAMA 309(13):1351CrossRefGoogle Scholar
  34. Navrade F (2008) Strategische Planung mit Data-Warehouse-Systemen. Betriebswirtschaftlicher Verlag Dr. Th. Gabler/GWV Fachverlage GmbH, Wiesbaden, WiesbadenGoogle Scholar
  35. Neuhaus J, Deiters W, Wiedeler M (2006) Mehrwertdienste im Umfeld der elektronischen Gesundheitskarte. Informatik-Spektrum 29(5):332–340CrossRefGoogle Scholar
  36. Papazoglou M (2008) Web services: principles and technology. Pearson/Prentice Hall, Harlow/New YorkGoogle Scholar
  37. Pavlović I, Kern T, Miklavčič D (2009) Comparison of paper-based and electronic data collection process in clinical trials: Costs simulation study. Contemp Clin Trials 30(4):300–316CrossRefGoogle Scholar
  38. Pommerening K, Drepper J, Helbing K, Ganslandt T (2014) Leitfaden zum Datenschutz in medizinischen Forschungsprojekten. MWV Medizinisch Wissenschaftliche Verlagsgesellschaft, BerlinGoogle Scholar
  39. Raghupathi W, Raghupathi V (2014) Big data analytics in healthcare: promise and potential. Health Inf Sci Syst 2(1):3CrossRefGoogle Scholar
  40. Reng CM, Debold P, Specker C, Pommerening K (2006) Generische Lösungen zum Datenschutz für die Forschungsnetze in der Medizin. MWV Medizinisch Wissenschaftliche Verlagsgesellschaft, BerlinGoogle Scholar
  41. Richardson L, Ruby S (2007) Web-services mit REST, 1. Aufl. O’Reilly Verlag, KölnGoogle Scholar
  42. Ryan M, Frater M (2002) Communications and information systems. Argos Press, CanberraGoogle Scholar
  43. Shah J, Rajgor D, Pradhan S, McCready M, Zaveri A, Pietrobon R (2010) Electronic data capture for registries and clinical trials in orthopaedic surgery: open source versus commercial systems. Clin Orthop Relat Res 468(10):2664–2671CrossRefGoogle Scholar
  44. SOAP Web Services/OpenClinica Reference Guide. https://docs.openclinica.com/3.1/technical-documents/openclinica-web-services-guide. Zugegriffen am 30.07.2015
  45. Trial Data Solutions (2015) TrialDataSolutions: workshop javascript. http://www.trialdatasolutions.com/tds/workshop_javascript/. Zugegriffen am 30.07.2015
  46. „Vital Signs Camera – Philips“ für iPhone, iPod touch und iPad im App Store von iTunes. https://itunes.apple.com/de/app/vital-signs-camera-philips/id474433446. Zugegriffen am 30.07.2015
  47. Wagner C (2003) Vorgehensmodelle für die Einführung von Data Warehouse Systemen im Krankenhaus – Eignung und exemplarische Ausarbeitung für das Universitätsklinikum, LeipzigGoogle Scholar
  48. Winter A, Ammenwerth E, Brigl B, Haux R (2005) Krankenhausinformationssysteme. In: Kapitel 13 in Lehmann (Hrsg) Handbuch der Medizinischen Informatik, 2. Aufl. Carl Hanser Verlag, MünchenGoogle Scholar
  49. Wirth S (2008) Hinweise zur Risikoanalyse und Vorabkontrolle nach dem Hamburgischen Datenschutzgesetz. Der hamburgische Beauftragte für Datenschutz und Informationssicherheit, HamburgGoogle Scholar

Copyright information

© Springer-Verlag Berlin Heidelberg 2015

Authors and Affiliations

  • Daniel Haak
    • 1
    Email author
  • Verena Deserno
    • 2
  • Thomas Deserno (geb.Lehmann)
    • 1
  1. 1.Institut für Medizinische InformatikUniklinik RWTH AachenAachenDeutschland
  2. 2.Clinical Trial Center AachenUniklinik RWTH AachenAachenDeutschland

Personalised recommendations