Pflichtenheft - Universitätsklinikum Freiburg

Pflichtenheft 

Software zum Betrieb des 

Deutschen Registers Klinischer Studien 

(DRKS) 

Gabriele Dreier 

Zentrum Klinische Studien 

Universitätsklinikum Freiburg 

Elsässer Str. 2 

D-79110 Freiburg 

gabriele.dreier@uniklinik-freiburg.de 

Autor: Rainer Peters 

Version: 1.2 

Datum: 10.03.2008 

Projektleiter 

Technischer Ansprechpartner: 

Rainer Peters 

Zentrum Klinische Studien 

Universitätsklinikum Freiburg 

Elsässer Str. 2 

79110 Freiburg 

rainer.peters@uniklinik-freiburg.de 

Dr. Gerd Antes 

Deutsches Cochrane Zentrum 

Institut für Medizinische Biometrie 

und Medizinische Informatik 

Universität Freiburg 

Stefan-Meier-Str. 26 

D-79104 Freiburg 

antes@cochrane.de 

Pflichtenheft: Software zum Betrieb des Deutschen Registers Klinischer Studien 1/39

Inhaltsverzeichnis 

1. Zielbestimmung ........................................................................................................... 3 

1.1. Beschreibung der Register-Software............................................................................ 3 

1.2. Abgrenzungskriterien................................................................................................... 5 

1.3. Lieferungen an den Auftraggeber ................................................................................ 5 

1.4. Weitere Referenzen...................................................................................................... 6 

1.5. Ablauf der Registrierung.............................................................................................. 6 

1.6. Verbindung zum ICTRP-Portal der WHO................................................................... 7 

2. Einsatz.......................................................................................................................... 8 

2.1. Zielgruppen .................................................................................................................. 8 

2.2. Betriebsbedingungen.................................................................................................... 8 

3. Umgebung.................................................................................................................... 9 

3.1. Software ....................................................................................................................... 9 

3.1.1. Server.................................................................................................................. 9 

3.1.2. Client................................................................................................................... 9 

3.2. Hardware...................................................................................................................... 9 

4. Funktionalität ............................................................................................................. 10 

4.1. Use-Cases:.................................................................................................................. 10 

4.1.1. Sponsor beantragt Account............................................................................... 10 

4.1.2. Sponsor legt Studie an / bearbeitet Studie ........................................................ 11 

4.1.3. Datenmanagement im DRKS ........................................................................... 13 

4.1.4. Ein Besucher der Webseite sucht nach Studien................................................ 13 

5. Requirements.............................................................................................................. 15 

6. Datenmenge................................................................................................................ 33 

7. Qualitätsziele.............................................................................................................. 33 

8. Begriffserklärungen.................................................................................................... 33 

9. Anhang 1: WHO Registration Data Set (Version 1.0)............................................... 35 

10. Anhang 2: Beschreibung des Deutschen Registers Klinischer Studien (Auszug aus 

dem Förderantrag) .................................................................................................................... 38 

10.1. Specification of the German register of clinical trials........................................... 38 

10.1.1. 1. Background Statement.................................................................................. 38 


1. Zielbestimmung 

Die zu entwickelnde Anwendung stellt die technische Basis des Deutschen Registers 

Klinischer Studien dar. Sie lässt sich inhaltlich in drei Bereiche aufteilen: 

1.) Dateneingabe/Datenimport: 

a. Die beschreibenden Daten einer oder mehrerer Studien werden vom 

entsprechenden Sponsor oder den beauftragten Personen eingegeben oder über 

b. eine Import-Schnittstelle importiert oder 

c. von Register-Mitarbeitern eingegeben. 

2.) Datenmanagement: Die eingegebenen Daten werden überprüft und durchlaufen dabei 

automatisierte und manuelle Tests. Bei Unvollständigkeit oder Unstimmigkeiten sollen 

manuelle oder automatische Queries ausgegeben werden. Genügen die Daten den 

Qualitätskriterien werden sie von einem Datenmanager veröffentlicht. 

3.) Öffentliche Datenbank: Veröffentlichte Daten liegen in einer öffentlich zugänglichen 

Datenbank und können über das Internet eingesehen werden. Über benutzerfreundliche 

Recherchehilfen, Suchdialoge und Aggregationen kann auf die Daten zugegriffen werden. 

Auf der öffentlichen Webseite können die Datenmanager des Registers die Öffentlichkeit 

auch über aktuelle Gegebenheiten informieren. 

Die zu erstellende Software (im Weiteren Register-Software genannt) muss alle diese 

Bereiche abdecken. 

1.1. Beschreibung der Register-Software 

1.) Dateneingabe/Datenimport: 

Die Registrierung einer neuen Studie und die Bearbeitung bereits eingegebener 

Studien durch einen Sponsor werden über ein Webinterface durchgeführt. Bei der 

Gestaltung der Eingabe- und Bearbeitungsmasken für die Dateneingabe muss 

besonders auf eine einfache Bedienung und eine gute Dokumentation Wert gelegt 

werden. Die abgefragten Parameter müssen sowohl in englischer wie auch in 

deutscher Sprache eingegeben werden. Die Anwender dieses Bereichs der Software 


sind meist Personen, die die Software nur selten benutzen werden. Es ist also mehr 

Wert auf eine verständliche Oberfläche zu legen als auf eine sehr schnelle und direkte 

Bedienbarkeit (z.B. Tastatur-Shortcuts), welche mehr Einarbeitungsaufwand erfordern 

würde. Die Sponsoren sollen mit möglichst wenig Aufwand ihre Daten eingeben 

können, da nur so eine hohe Akzeptanz der Studienregistrierung sichergestellt werden 

kann. 

2.) Datenmanagement: 

Die Mitarbeiter des Datenmanagements haben einen anderen Zugang zur Software. 

Sie benutzen die Anwendung sehr oft. Somit ist in diesem Bereich mehr Wert auf 

schnelle, direkte Bedienung zu legen, als auf ausführliche Online-Hilfestellungen. Das 

Datenmanagement wird sich im Laufe der Projektzeit verändern und an äußere 

Gegebenheiten anpassen müssen. In diesem Bereich werden wahrscheinlich stärkere 

Veränderungen an der Software notwendig sein als im Bereich der Dateneingabe (z.B. 

neue Parameter). Diesem Umstand muss schon während der Entwicklung Rechnung 

getragen werden. Auch das Datenmanagement sollte die Software über ein 

Webinterface bedienen können. Eine Desktop-Client-Version ist aus Gründen der 

Betriebsystem-Unabhängigkeit nicht vorgesehen. 

3.) Öffentliche Datenbank: 

Die öffentliche Datenbank Klinischer Studien wird vom Internet aus zugänglich sein. Sie 

ist der zentrale Punkt an dem das Register der Öffentlichkeit zur Verfügung gestellt wird. 

Hier steht als Benutzer die Öffentlichkeit im Focus. Diese kann man grob in drei 

Personenkreise einteilen: 

α.) Personen, die medizinisch nicht sehr bewandert sind (Laien) und sich über eine 

Krankheit informieren wollen und nach Studien oder Kontaktpersonen suchen 

β.) Medizinisch versierte Personen, die nach Studien oder Kontakten zu einer 

bestimmten Fragestellung suchen 

χ.) Allgemeine Öffentlichkeit, Journalisten die Übersichten brauchen und gezielt 

recherchieren. 

Hauptaufgabe der öffentlichen Website des Registers wird es sein, Studien einfach 

auffindbar zu machen und Informationen zu den Studien in übersichtlicher Form 

anzuzeigen. 

Allen Personenkreisen muss auf den öffentlichen Webseiten Rechnung getragen werden, 

indem ihre speziellen Bedürfnisse bedacht werden. So kann ein medizinisch bewanderter 

Besucher auch eine komplexe Suchmaske bedienen, in der einzelne Parameter wie 


Endpunkte der Studie oder Indikationen eingegrenzt werden können. Der „medizinische 

Laie“ dagegen benötigt eine einfach Suchfunktion, die nach der Eingabe eines 

Suchbegriffes alle möglicherweise relevanten Studien findet, und ihm die Möglichkeit 

gibt, diese weiter einzugrenzen. 

1.2. Abgrenzungskriterien 

Die Software soll ausschließlich als Webanwendung implementiert werden. Es geht nur um 

die Eingabe, Verwaltung und Ausgabe von Daten zu Klinischen Studien. 

Es geht nur um die Entwicklung bzw. Nutzung von Softwarelösungen. 

Hardwarekomponenten sind nur in sofern betroffen, als dass spezifiziert werden muss, auf 

welcher Hardware die Systeme lauffähig sein werden. 

1.3. Lieferungen an den Auftraggeber 

Alle zu liefernden Teilpakete müssen versionskontrolliert sein, und in einer konsistenten und 

zueinander passenden Version abgeliefert werden. Der Auftragnehmer wird verpflichtet 

entsprechende Integrationstests durchzuführen und die entsprechende Dokumentation mit 

jeweils neuen Versionen zu übergeben: 

• Die Software als installierbare Pakete (als Datenträger oder Download) 

• Benutzerhandbuch zur Software in deutscher und englischer Sprache 

• Installationsbeschreibung der Software (inkl. Anforderungen an Hard- und Software) 

in deutscher Sprache 

• Der Sourcecode der Software (im Falle einer Erweiterung einer existierenden 

Software der Sourcecode der Erweiterung) und aller verwendeter Bibliotheken. 

• Alle entwickelten Testprozeduren und Testprotokolle in deutscher oder englischer 

Sprache 

• Komplette Dokumentation des Sourcecodes in deutscher oder englischer Sprache 

• Aus den gelieferten Komponenten muss sich die Anwendung vom Auftraggeber 

erstellen lassen und den vollen Funktionsumfang bieten. 

• Der Auftraggeber muss das Recht haben, den entwickelten Sourcecode weiter zu 

verändern, zu erweitern, zu veräußern und Dritten zur Verfügung zu stellen 


• Wird eine schon existierende Software verwendet, so kann es möglich sein, dass der 

Sourcecode und die Dokumentation des Sourcecodes nicht ausgeliefert werden kann. 

Es ist dann anzugeben, ob der Sourcecode evtl. bei einem Notar hinterlegt werden 

muss und wie mit den zu Entwickelnden Erweiterungen umgegangen werden soll. 

• Es soll weiterhin ein Wartungsvertrag abgeschlossen werden, indem die 

Instandhaltung der Software, wie auch die Reaktionen bei gefundenen Fehlern 

festgelegt werden 

1.4. Weitere Referenzen 

Um weitere Informationen zur Studienregistrierung zu erhalten, sind folgende Referenzen 

hilfreich: 

• Auszug aus dem Förderantrag (siehe 

• Anhang 2: Beschreibung des Deutschen Registers Klinischer Studien (Auszug aus 

dem Förderantrag) 

• Website der WHO-ICTRP Workgroup (http://www.who.int/ictrp/) 

• http://www.clinicaltrials.gov/ 

• Das Deutsche Register für Somatische Gentherapie (www.dereg.de) 

1.5. Ablauf der Registrierung 

Derzeit ist der Ablauf der Registrierung noch nicht abschließend festgeschrieben. Es gibt 

verschiedene Modelle, die mit der Registersoftware realisierbar sein müssen. 

1.) Daten werden direkt über die Registersoftware in die Datenbank eingegeben. Dabei 

soll es auch möglich sein, die Daten einer Studie über ein korrekt formatiertes XML- 

File einzuspielen. Dies soll eine Anbindung an ein im Aufbau befindliches Portal 

einiger Ethikkommissionen ermöglichen. 

2.) Daten werden aus anderen Registern (beispielsweise Krankheitsspezifischen- oder 

Sponsor-Registern) importiert. 

3.) Daten werden direkt von elektronischen Anträgen der Ethik-Kommissionen in das 

Register importiert. 


Die Punkte 2. und 3. sind nicht alleine von der Registersoftware zu erfüllen und sind auf 

Anpassungen der Datenlieferanten angewiesen. Dennoch sollte die Möglichkeit einer 

einfachen Import-Schnittstelle geschaffen werden (siehe XI). Diese Schnittstelle kann dann 

von Registern oder anderen Organisationen, wie z.B. Ethikkommissionen, genutzt werden. 

1.6. Verbindung zum ICTRP-Portal der WHO 

Das Deutsche Register Klinischer Studien strebt eine enge Verbindung zum ICTRP-Portal der 

WHO an (siehe http://www.who.int/ictrp). 

Dazu wird es notwendig sein einen Datenaustausch mit dem Portal zu implementieren. Da 

zum jetzigen Zeitpunkt eine genaue Spezifikation der Schnittstelle zu diesem Portal noch 

nicht erfolgt ist, muss dieser Punkt zu einem späteren Zeitpunkt konkretisiert werden. 

Sicher scheint im Moment jedoch folgendes: 

• Die WHO will eine UTRN (Universal Trial Registration Number) vergeben, mit der 

Studien identifiziert werden können. Diese muss importiert werden können. 

• Die WHO will eine Studie in eine eigene Datenbank importieren. Dazu muss ein 

entsprechender automatischer Export aus der Registersoftware implementiert werden. 

Die zu liefernden Daten sind in Anhang 1 definiert. 


2. Einsatz 

2.1. Zielgruppen 

Es können drei verschiedene Zielgruppen identifiziert werden, die die Software benutzen 

werden: 

1.) Sponsoren: Sie bearbeiten Studien, die veröffentlicht werden sollen. 

2.) Register-Mitarbeiter: Sie führen Qualitätssicherung, Administration und 

Veröffentlichungen am Register durch. 

3.) Öffentlichkeit: Jeder kann über die Homepage auf die freigegebenen Inhalte des Registers 

zugreifen und Recherchen durchführen. 

2.2. Betriebsbedingungen 

Die Registersoftware soll möglichst unterbrechungsfrei verfügbar sein. Dazu ist sie auf einem 

geeigneten Webserver zu installieren. Die Ausfallsicherheit des Servers muss vom 

Hostprovider sichergestellt werden. Die Software soll auf einfache Weise aktualisierbar und 

erweiterbar sein. 


3. Umgebung 

3.1. Software 

3.1.1. Server 

Die zu entwickelnde Software darf serverseitig Linux oder Windows als Betriebssystem 

voraussetzen. 

3.1.2. Client 

Auf Seite der Clients muss die Software Betriebssystem-unabhängig sein. Es muss der Zugriff 

mit Windows, Linux und MacOS Clients über das Internet möglich sein. Dies bedingt, dass 

die Nutzung verschiedener Webbrowser möglich sein muss. Hierbei sind mindestens MS- 

Internet Explorer (V5.0++), Mozilla Firefox (1.0++), Opera (7++) und Safari zu unterstützen. 

Eine Nutzung des Registers muss auch ohne Java-Script oder Plugins wie z.B. Flash möglich 

sein. Bei abgeschaltetem Java-Script und bei alten Browser-Versionen muss die Anwendung 

weiter mit vollem Funktionsumfang nutzbar sein, darf aber Schwächen im Layout, der 

Darstellung und der Handhabung zeigen. 

Die Funktionen des Datenmanagements und der Sponsoren können aktuellere Versionen der 

Browser voraussetzen, müssen aber auch Betriebsystem-unabhängig sein. Hier können 

aktuelle Versionen von Firefox (2.x) und Internet-Explorer (7.x) vorausgesetzt werden. 

Es soll keine Clientsoftware existieren. Die Software soll sich komplett per Webbrowser 

bedienen lassen. 

3.2. Hardware 

Als eingesetzte Hardware soll ein Standard-Server verwendet werden (beispielsweise 

vergleichbar mit Siemens Primergy RX300 S2, 2GB RAM). 

Die Anforderung an die Client-Hardware für die externen Nutzer des Systems muss sehr 

niedrig sein. Auch ein altes PC-System (z.B. 1 GHz x86-Prozessor) muss per Webbrowser 

das Register abfragen können. 

Für die Funktionen des Datenmanagements und der Registermitarbeiter können aktuelle 

Desktopsysteme vorausgesetzt werden (vergleichbar mit aktuellen 2GHz x86 Prozessor). 


4. Funktionalität 

4.1. Use-Cases: 

Nachfolgend sind beispielhaft einige wichtige Use-Cases aufgeführt und grafisch dargestellt. 

Sie sollen die Arbeit mit der Registersoftware veranschaulichen und müssen implementiert 

werden. 

1.) Sponsor beantragt Account 

2.) Sponsor legt Studie an / bearbeitet Studie 

3.) Datenmanagement veröffentlicht Studie 

4.) Ein Besucher der Webseite sucht nach Studien 

4.1.1. Sponsor beantragt Account 

Einem neuen Sponsor soll es möglichst einfach gemacht werden, einen Account anzulegen, 

unter dem er eine Studie registrieren kann. Dies ist besonders wichtig, da so eine 

Abschreckung der Sponsoren zu Beginn der Registrierungsprozedur vermieden werden soll. 

Die Erstellung eines Accounts soll automatisiert, ohne Mitwirken des Register-Personals 

erfolgen. Nach der Eingabe der Emailadresse (als Sponsorname) und eines Passworts soll 

noch, um Missbrauch vorzubeugen, ein auf der Seite angegebener Textcode eingegeben 

werden. Durch diesen Code, der auf der Seite als Bild dargestellt wird, soll verhindert werden, 

dass programmgesteuert große Mengen an Accounts angelegt werden können, die die 

Stabilität des Systems gefährden. 

Nach diesen Eingaben soll eine Bestätigungsmail an die eingegebene Emailadresse versendet 

werden, die einen Bestätigungs-Link enthält. Erst nach dem Aufrufen dieses Links ist der 

angelegte Account freigeschaltet und kann benutzt werden. Nach erfolgter Freischaltung soll 

das Datenmanagement des Registers über den neu angelegten Account per Email informiert 

werden und kann die Authentifizierung des Sponsors anstoßen. 


Sponsor beantragt Account 

Sponsor beantragt 

Account zur 

Studieneingabe 

über Webseite 

Sponsor erhält 

Bestätigungs-Email 

mit Freischaltungs- 

Link 

Sponsor schaltet 

Account über 

angegebenen Link frei 

Sponsor kann sich 

nun anmelden und 

Studien eingeben 

Datenmanagement 

wird über neuen 

Account informiert 

Abbildung 1: Sponsor beantragt Account 

4.1.2. Sponsor legt Studie an / bearbeitet Studie 

Nachdem sich ein Sponsor angemeldet hat kann er aus der Liste seiner Studien eine Studie 

auswählen und bearbeiten, oder er erstellt eine neue Studie. In eine neue Studie kann er bei 

Bedarf Daten im CDISC-Format aus einer Datei einfügen. Hat der Sponsor die Studie 

bearbeitet, fragt er um Veröffentlichung beim Datenmanagement nach. Danach kann er eine 

andere Studie bearbeiteten oder sich abmelden. 


Sponsor legt Studie an / bearbeitet Studie 

Sponsor 

beantragt 

Account 

Sponsor beantragt 

Veröffentlichung 

Datenmanagement 

prüft 


Nein 

Sponsor will eine 

Studie eingeben 

oder bearbeiten 

Sponsor hat schon 

einen Account 

Ja 

Sponsor meldet 

sich an 

Sponsor sieht seine 

Studien und anstehende 

Queries 

Sponsor wählt zu 

bearbeitende 

Studie oder legt 

neue Studie an 

Sponsor 

bearbeitet Studie 

Eingabe ist beendet, 

und die Studie soll 

veröffentlicht werden 

Anfrage nach 

Veröffentlichung wird ans 

Datenmanagement des 

Registers geschickt 

Sponsor meldet 

sich ab 

Sponsor kann Studiendaten im 

CDISC-Format in eine neue Studie 

importieren 

Änderungen der Studiendaten 

werden im Audittrail festgehalten und 

bei Änderungen Versionsnummer der 

Studie erhöht 


Abbildung 2: Sponsor legt Studie an / bearbeitet Studie 

4.1.3. Datenmanagement im DRKS 

Das Datenmanagement im Register besteht aus vielen Aufgaben. Die wichtigsten davon sind 

im Folgenden kurz beschrieben. 

Datenmanagement im DRKS 

DM erstellt Query 

zur Bearbeitung 

durch den 

Studienleiter 

Nach definierter 

Zeit wird vom 

Studienleiter eine 

Aktualisierung der 

Studie gefordert 

DM bearbeitet zur 


anstehende Studie 

DM prüft Studie mittels 

automatisierter 

Plausibilitätschecks 

DM prüft Studie mittels 

manueller 

Plausibilitätschecks 

DM veröffentlicht 

Studie 

Studie ist in der 

aktuellen Version über 

öffentliche 

Internetseite 

einsehbar 

Datenmanager 

(DM) meldet sich 

an 

DM sieht eine Übersicht: 

zur Veröffentlichung anstehende Studien, 

zu aktualisierende Studien... 

DM archiviert Studie 

(Studie wird auch 

veröffentlicht) 

Studie ist in der 

aktuellen Version über 

öffentliche 

Internetseite 

einsehbar 

Abbildung 3: Datenmanagement im DRKS 

DM prüft bei welchen 

Studien die Aktualisierung 

aussteht 

DM schickt Einzelnen oder 

Gruppen von 

Studienleitern 

automatisiert eine 

Erinnerungs-Email 

DM aktualisiert die 

Öffentliche 

Homepage 

4.1.4. Ein Besucher der Webseite sucht nach Studien 

DM prüft 

Diagramme und 

Statistiken um 

Aussagen zum 

Verlauf der 

Registrierung 

insgesamt treffen 

zu können 

Ein sehr wichtiger Bereich der Registersoftware ist die Recherche in den Studien innerhalb 

der öffentlichen Webseite. Hier sollen sowohl Laien, wie auch medizinisch bewanderte 

Personen einfach und effektiv nach relevanten Studien suchen können. 


Besucher nutzt die öffentliche Webseite 

Besucher kann 

jederzeit zwischen 

Deutscher und 

Englischer Sprache 

wählen 

Besucher kann über 

einfache Stichworte nach 

Studien suchen 

Besucher sieht 

ausgewählte Variablen der 

Studien in der 

Ergebnisliste seiner Suche 

Besucher wählt Studie aus 

Besucher sieht alle 

Informationen zur Studie 

Besucher kann Studie 

drucken, exportieren 

(XML) oder als PDF-Datei 

speichern. 

Besucher öffnet Webseite 

des Registers 

Besucher sieht allgemeine 

und aktuelle Informationen 

zum Register 

Besucher kann über 

komplexe Suchmaske 

nach Studien suchen 

Abbildung 4: Benutzer nutzt die öffentliche Webseite 

Besucher kann 

Ergebnisliste weiter 

einschränken 

Besucher kann über eine 

bekannte Studien-ID direkt 

auf eine Studie zugreifen 


5. Requirements 

I. Allgemeines 

1.Die gesamte Kommunikation zwischen Auftraggeber und Auftragnehmer muss in 

deutscher Sprache erfolgen. 

2.Die Applikation muss eine Webanwendung sein 

3.Zugriff auf den öffentlichen Teil des Registers (siehe 1.1 Punkt 3.) erfolgt für alle 

Benutzer unverschlüsselt 

4.Personalisierter Zugriff auf das Register nur über Verschlüsselung (https) 

5.Der Sourcecode der Anwendung soll für die Auftraggeber zur Verfügung gestellt 

werden (siehe Lieferungen an den Auftraggeber). 

a.Dabei sind dem Auftraggeber die Rechte zur uneingeschränkten Nutzung, 

Weitergabe und Änderung am Sourcecode zu gewähren. 

6.Die Anwendung muss in einigen Bereichen durch das Personal des Auftraggebers 

selbst erweiterbar sein: 

a.Plausibilitätschecks (siehe X) müssen anpassbar und erweiterbar sein 

b.Statistiken (siehe j) müssen anpassbar und erweiterbar sein 

c.Charts und Grafiken (siehe 6) müssen anpassbar und erweiterbar sein 

7.Layout und Design der Webseiten muss per CSS (Cascading Style Sheet) anpassbar 

und änderbar sein 

8.Als Datenbank soll wenn möglich eine Datenbank verwendet werden (z.B. 

PostgreSQL), für die keine Lizenzkosten anfallen 

9.Die Anwendung kann logisch in zwei Teile geteilt werden: 

a.Dateneingabe/Datenimport, Qualitätssicherung, Administration, 


b.Ausgabe der Daten auf öffentlich zugänglicher Webseite 

10.Beide Teile der Anwendung (siehe 9) können, wenn es sinnvoll erscheint in 

unterschiedlichen Systemen implementiert sein. Die Schnittstelle (evtl. die Datenbank) 

muss aber in jedem Fall spezifiziert sein. 

11.Für beide Teile der Anwendung (siehe 9) kommt sowohl eine Neuentwicklung, als 

auch eine Erweiterung einer bestehenden Anwendung prinzipiell in Frage. 

12.Für a ist ein Account mit Passwort erforderlich. 

13.Es gibt 2 verschiedene Arten von Accounts für die Applikation in a 

a.Account für Sponsor (meist Studienverantwortliche) 


.Account für Mitarbeiter des Deutschen Registers Klinischer Studien 

14.Mehrsprachigkeit 

Die Anwendung muss mehrsprachig sein, und mindestens für die Bereiche der 

Dateneingabe durch den Sponsor und der öffentlichen Seite Deutsche und Englische 

Sprache unterstützen. Somit müssen manche Parameter (Freitext-Parameter) in 

mehreren Sprachen eingegeben werden. Bei Kodierten Parametern kann die 

Übersetzung in verschiedene Sprachen zentral erfolgen. Weitere Sprachen sollen mit 

geringem Aufwand hinzugefügt werden können (z.B. durch Template-Mechanismen). 

II. Studienstatus 

Eine Studie kann sich in verschiedenen Status befinden. Abbildung 5: Studienstatus 

veranschaulicht die Übergänge zwischen den einzelnen Status. 

1.In Bearbeitung: In diesem Status kann die Studie von dem Sponsor (und DM) 

bearbeitet und verändert werden. Eine neu angelegte Studie befindet sich automatisch 

in diesem Status. Ebenso wird eine veröffentlichte Studie in diesen Status versetzt, 

wenn sie aktualisiert werden soll. Wurde für eine Studie die Veröffentlichung 

beantragt und gibt es eine Rückfrage von DM, so wird auch diese Studie wieder in den 

Status „in Bearbeitung“ versetzt. 

Die Studie verlässt diesen Status, indem der Sponsor die Veröffentlichung beantragt 

oder die Studie löscht. Dabei ist zu beachten, dass nur bisher unveröffentlichte Studien 

vom Sponsor gelöscht werden können. 

Auch das Datenmanagement kann für Studien in diesem Status die Veröffentlichung 

beantragen. 

2.Veröffentlichung beantragt: Eine Studie kommt in diesen Status, wenn der Sponsor 

die Veröffentlichung beantragt. Dies kann nach dem initialen Anlegen der Studie oder 

nach einer erfolgten Aktualisierung erfolgen. Nur DM kann Studien in diesem Status 

verändern. DM kann entweder die Veröffentlichung durchführen, oder eine Rückfrage 

an den Sponsor stellen. Falls die Dateneingabe für diese Studie abgeschlossen ist, 

kann DM die Studie archivieren. In diesem Fall wird sie auch erneut veröffentlicht, 

allerdings fallen für archivierte Studien keine Aktualisierungen mehr an. 

3.Veröffentlicht: Eine Studie die durch DM veröffentlicht wird, erhält diesen Status. 

Im Zuge der regelmäßig anstehenden Aktualisierungen (siehe 8) wird die Studie 

wieder in den Status „in Bearbeitung“ versetzt und der entsprechende Sponsor 

kontaktiert. Die öffentlich zugängliche Version der Studie soll dabei nicht verändert 

werden. 


4.Archiviert: Ist die Bearbeitung einer Studie abgeschlossen, und sind keine weiteren 

Eingaben und Aktualisierungen mehr nötig, so wird die Studie in diesen Status 

versetzt. Sie ist veröffentlicht wie in 3, es werden aber keine Aktualisierungen mehr 

automatisch angefordert. 

5.Gelöscht: Eine Studie kann vor der Veröffentlichung vom Sponsor gelöscht werden. 

Ist sie einmal veröffentlicht, kann dies nur in bestimmten schwerwiegenden Fällen 

(z.B. Duplikat, Betrug...) durch das DM rückgängig gemacht werden. Studien sollen 

nicht wirklich gelöscht werden, sondern nur als gelöscht markiert werden und in der 

Datenbank verbleiben. 

von Sponsor 

oder DM gelöscht 

Abbildung 5: Studienstatus 

Veröffentlichung und 

Archivierung durch DM 

III. Dateneingabe/Datenimport durch den Sponsor (meist Studienverantwortlichen) 

1.Dateneingabe ist nur für angemeldete Sponsoren möglich 

Um Daten in die Datenbank eingeben zu können, muss sich ein Sponsor anmelden. 

Dazu muss er mindestens seine Emailadresse (als Accountname), seinen Namen und 

Kontaktdaten wie Adresse und Telefonnummer hinterlegen. 

2.Der Zugang zu einem Bereich der Applikation, der eine Anmeldung erfordert 

(Bereich 1, siehe 9) darf nur verschlüsselt erfolgen (siehe 4) 

3.Schnelle und unkomplizierte Account-Erstellung: 

Es muss für den Sponsor möglich sein, schnell und unkompliziert einen Account zur 

Eingabe einer Studie anzulegen. Dazu sollten etablierte Verfahren genutzt werden, die 

ein Mindestmass an Sicherheit bieten, wie beispielsweise: 

a.Eingabe von Emailadresse und Passwort durch den Sponsor. 


.Darauf erhält dieser eine Bestätigungsmail mit einem Link, 

c.durch den er seinen Account freischalten kann. 

d.Es wird dann eine Informations-Email über den angelegten Account an das 

DM versandt. 

4.Gute Übersicht über eigene Studien 

Der Sponsor muss, nachdem er sich zur Dateneingabe angemeldet hat, eine Übersicht 

seiner Studien erhalten. Dazu soll er sehen, welche Studien in welchem Status (siehe 

II) sind. 

5.Neue Studien anlegen 

Der Sponsor muss die Möglichkeit haben neue Studien anzulegen, die registriert 

werden sollen. 

a.Der Sponsor soll die Möglichkeit haben, bestimmte Parameter aus bereits 

eingegebenen Studien zu kopieren, um gleiche Parameter nicht immer wieder 

eingeben zu müssen. Dieses Verfahren ist für Adressen und Kontaktdaten wie 

z.B. Sponsors, und Contacts (siehe 9 Punkt 5-8) wichtig. 

6.Bereits eingegebene Studien editieren. 

Der Sponsor muss die Möglichkeit haben bereits eingegebene Studien zu editieren. 

7.Import aus CDISC-XML-File 

Der Sponsor muss die Möglichkeit haben Daten aus einem CDISC-XML-File (siehe 

c) in eine neue Studie zu importieren. 

8.Studien zur Veröffentlichung/Aktualisierung an QS weiterleiten. 

Hat ein Sponsor die Eingabe oder Aktualisierung seiner Studie beendet, so soll er 

diese möglichst einfach (1-2 Klicks) an DM zur Prüfung weiterleiten können. Dies 

soll einen Statuswechsel der Studie bewirken (siehe II). Ein Sponsor kann eine Studie 

nicht ohne Freigabe durch DM direkt veröffentlichen. 

9.Die Eingabe der Studien soll über eine webbasierte Eingabemaske (siehe VIII) oder 

Daten-Import (siehe 1.5, 7, XI) erfolgen 

10.Ein Sponsor darf nur Zugriff auf seine eigenen Studien haben. 

11.Automatisches Logout nach 30 Minuten Untätigkeit. 

Nach max. 30 min. ohne Eingabe soll der Sponsor abgemeldet werden. Bis dahin nicht 

gespeicherte Eingaben sollen nicht verloren sein. Sie sollen entweder Serverseitig 

gespeichert werden, oder per Email an den Sponsor und das Datenmanagement 

geschickt werden. 


12.Audittrail für eigene Studien soll einsehbar sein (siehe 7). 

Der Sponsor kann den Audittrail für seine eigenen Studien einsehen und durchsuchen. 

13.Versionierung der Studien 

Jede Änderung in einer Studie soll die Versionsnummer einer Studie ändern. Dabei 

können mehrere gleichzeitige Änderungen an Parametern zusammengenommen 

werden und in nur einen Versionswechsel resultieren (Transaktionsorientiert). Nicht 

jede alte Version einer Studie muss gespeichert werden, da sie sich aus dem Audittrail 

rekonstruieren lassen, aber jede veröffentlichte Version einer Studie soll versioniert 

gespeichert werden. 

14. Rechteweitergabe für andere Benutzer 

Der Sponsor soll die Möglichkeit haben einem anderen Benutzer das Recht zu geben 

eine seiner Studien zu bearbeiten 

a. Dabei gibt der Sponsor die Studie und den Benutzer an, der von nun an für 

die Studie verantwortlich sein soll 

b. Es muss sichergestellt sein, dass der andere Benutzer im System bekannt ist 

c. Der Sponsor, der neue Benutzer und das Datenmanagement werden per 

Email über die Aktion informiert 

d. Ab jetzt ist der neue Benutzer für die Studie verantwortlich 

IV. Qualitätssicherung im Register (durch das Datenmanagement (DM)) 

1.Mitarbeiter des Deutschen Registers Klinischer Studien (DRKS) können 

Qualitätssicherung (QS) in der Registeranwendung betreiben. 

2.Jeder Mitarbeiter muss einen eigenen Account mit Passwort erhalten um sich an der 

Applikation anzumelden. 

Dieser Account wird vom Administrator angelegt (siehe 1) 

3.Mitarbeiter erhalten im Vergleich zu Sponsoren (siehe III) weitere Möglichkeiten: 

a.Mitarbeiter sehen alle eingegebenen Studien 

b.Mitarbeiter können alle eingegebenen Studien bearbeiten 

c.Mitarbeiter können den kompletten Audittrail (siehe 7) einsehen und 

durchsuchen 

d.Mitarbeiter können den Status einer Studie (siehe II) ändern 

e.Mitarbeiter können Queries erstellen (siehe V) 

f.Mitarbeiter können Studien authentifizieren 

Ein Mitarbeiter stellt sicher (telefonisch oder über andere Wege), dass die 


angegebene Studie wirklich existiert und vom angegebenen Sponsor initiiert 

wurde 

a)Der Mitarbeiter kann einer Studie das Attribut authentifiziert 

zuordnen. 

g.Mitarbeiter können Sponsoren authentifizieren 

Ein Mitarbeiter stellt sicher (telefonisch oder über andere Wege), dass der 

Sponsor wirklich existiert. 

a)Der Mitarbeiter kann einem Sponsor das Attribut authentifiziert 

zuordnen. 

h.Mitarbeiter können Studien veröffentlichen: 

Die Studie ist dann im öffentlichen Teil der Applikation (b) zu sehen 

a)Nur authentifizierte Studien von authentifizierten Sponsoren sollten 

veröffentlicht werden. Trifft dies nicht zu, so soll der Datenmanager 

vor der Veröffentlichung gewarnt werden. 

b)Wird eine Studie veröffentlicht, die nicht vollständig ist, so soll sie 

eine deutlich unterscheidbare Studien-ID erhalten: (z.B. DRKS-TMP- 

xxxxxx). 

c)Nachdem eine Studie veröffentlich wurde soll automatisch eine 

Email an den entsprechenden Sponsor versendet werden, in der der 

Sponsor über die Veröffentlichung informiert wird. In dieser Email 

müssen folgende Informationen enthalten sein: 

(1)Datum der Veröffentlichung 

(2)Link zur veröffentlichten Studie 

(3)Name des Datenmanagers der die Veröffentlichung 

durchgeführt hat. 

i.Mitarbeiter können Sponsoren Nachrichten (Emails) senden 

j.Mitarbeiter können Statistiken (interaktiv und statisch) der eingegebenen 

Daten sehen (siehe 6) 

k.Mitarbeiter sehen bei welchen Studien eine Veröffentlichung oder eine 

Aktualisierung ansteht 

l.Schutz vor gleichzeitigem Zugriff (siehe IX) 

m.Sie können die Ergebnisse der Plausbilitätschecks (siehe X) sehen 

n.Mitarbeiter sehen, bei welchen Studien die Aktualisierung (siehe 8) 

ausstehen 


o.Mitarbeiter können mehreren Sponsoren automatisiert Erinnerungsemails 

schicken 

p.Mitarbeiter können Plausibilitätschecks (siehe X) für Einzelne oder Gruppen 

von Studien auswerten 

4.Daten müssen aus der Anwendung exportiert werden können: 

a.Spezielle Exporte sollen vorbereitet sein wie z.B. ein Export, der Adressen 

zum Erstellen von Serienbriefen exportiert 

b.Es soll die Möglichkeit haben generische Exports (z.B. als SQL-Statement) 

zu erstellen. 

a)Dabei muss es auch möglich sein alle Daten, Studiendaten wie auch 

organisatorische Daten, zu exportieren. 

c.Studien müssen im CDISC-XML Format exportiert werden können. Hierzu 

ist das von CDISC vorgesehene Schema zur Studienregistrierung zu 

verwenden (siehe www.cdisc.org: BRIDG-Modell). 

d.Studiendaten müssen sich mit ansprechendem Layout als PDF-Datei 

exportieren lassen. 

5.Interaktion mit Homepage/Internet Plattform 

Mitarbeiter müssen den Inhalt der Homepage bearbeiten können um beispielsweise 

News oder aktuelle Berichte zu veröffentlichen. 

6.Statistiken und Grafiken 

Sie sind ein wichtiges Hilfsmittel um Übersichten und Performance-Daten des 

Registers darzustellen. 

a.wichtige administrative Statistiken müssen von Beginn an verfügbar sein: 

a)Eingegebene Studien/Zeiteinheit (Jahr/Monat/Woche/insgesamt) 

b)Veröffentlichte Studien/Zeiteinheit (Jahr/Monat/Woche/insgesamt) 

c)Anzahl der Studien die aktualisiert werden müssen 

b.wichtige inhaltliche Statistiken sollten verfügbar sein (über die 

veröffentlichten Studien) z.B.: 

a)Phasen der Studien 

b)Beteiligte Länder 

c)Verteilung der Indikationen 

c.weitere Statistiken und Charts müssen von den Registermitarbeitern nach 

entsprechender Einweisung ohne weitere Beauftragung des AN erstellt werden 

können. 


7.Audittrail 

Ein Audittrail erfasst alle Datenänderungen im Register und speichert sie in einer 

Datenbank. Es dient dazu nachweisen zu können, wer welche Daten wann geändert 

hat. 

a.Ein Audittrail muss alle Daten- und Zustandsänderungen im Register 

erfassen 

a)Datenänderungen: z.B. das Ändern einer Adresse 

b)Statusänderung (siehe II): z.B. das Veröffentlichen einer Studie 

b.Der Audittrail muss erfassen: 

a)wer die Daten geändert hat 

b)wann die Daten geändert wurden 

c)welche Daten genau geändert wurden 

d)welches der alte Wert der Daten war 

e)welches der neue Wert der Daten ist 

f)bei Zustandsänderungen muss der alte und der neue Zustand erfasst 

werden 

c.Der Audittrail ist nur für das Datenmanagement vollständig einsehbar 

d.Sponsoren können nur den Audittrail ihrer Studien sehen 

e.Im Audittrail muss gezielt gesucht werden können (evtl. durch Filter 

Mechanismen implementierbar): 

a)nach allen Änderungen an einer Studie 

b)nach allen Änderungen in einem Zeitintervall (pro Studie und bei 

allen Studien/Studienteilmenge) 

c)nach allen Änderungen durch eine Person (pro Studie und bei allen 

Studien/Studienteilmenge) 

d)nach einem alten/neuen Wert (pro Studie und bei allen 

Studie/Studienteilmenge) 

e)nach einem alten/neuen Zustand (pro Studie und bei allen 

Studien/Studienteilmenge) 

8.Aktualisierung von Studien 

f)nach Kombinationen der oberen Bedingungen (pro Studie und bei 

allen Studien/Studienteilmenge) 

Studien müssen nach einer wählbaren Zeit (Anzahl von Tagen) aktualisiert werden 

(siehe a). Dies soll von der Register-Software unterstützt werden. 


a.Eine Studie, die in der entsprechenden Zeit nicht mehr aktualisiert wurde, 

soll automatisch dem Sponsor zur Aktualisierung vorgelegt werden 

9.Kommentar-Log 

a)der Sponsor wird per Email benachrichtigt 

b)die Studie wird in den Zustand „in Bearbeitung“ versetzt (siehe 1) 

c)das Datenmanagement wird per Email benachrichtigt 

Die Kommentarfunktion ist dazu gedacht, Mitarbeitern die Möglichkeit zu geben 

Informationen zu einer Studie, z.B. telefonische Absprachen, festzuhalten. 

a.Mitarbeiter sollen zu jeder Studie Kommentare anzeigen und verfassen 

können. 

b.Diese Kommentare sollen den Namen der Verfassers, das Erstellungsdatum 

und den Kommentar enthalten 

c.Kommentare müssen durchsuchbar sein 

d.Kommentare sind nur für Mitarbeiter zu lesen. Sponsoren haben keinen 

Zugriff darauf 

V. Query-Management 

Unter Query-Management versteht man ein Verfahren, dass es dem Datenmanagement 

ermöglicht Rückfragen an Sponsoren zu stellen und Sponsoren auf solche Anfragen zu 

antworten. 

1.Ein Mitarbeiter soll zu einer Studie ein Query erstellen können. 

a.Der Sponsor dieser Studie sieht, dass ein Query zu bearbeiten ist, nachdem er 

sich angemeldet hat 

b.zusätzlich wird dem Sponsor der Studie das Query per Email zugeschickt 

c.Der Mitarbeiter soll Betreff und Text des Queries selber wählen können. 

2.Jedes Query erhält vom System eine eindeutige Nummer, mit der es fortan 

referenziert werden kann. 

3.Query-Lifecycle 

a.Ein Query wird erstellt 

b.Das Query wird dem Sponsor zugestellt (per Email und in der 

Registersoftware) 

c.Der Sponsor beantwortet das Query 

d.Das Query wird samt Antwort dem Datenmanagement zugestellt. 

e.Falls das Query gelöst ist wird es abgeschlossen und archiviert 


f.Falls es nicht gelöst ist, wird es an den Sponsor zurück geschickt (weiter bei 

b) 

4.Wird ein Query beantwortet, so wird die Antwort zusammen mit dem Datum in 

Namen des Benutzers an das Query angehängt. So für alle Beteiligte immer der 

gesamte Ablauf des Queries sichtbar sein. 

5.Sponsoren dürfen nur die Queries sehen, die zu ihren Studien gehören. 

a.Sponsoren sehen nach dem Anmelden an das System alle durch sie zu 

bearbeitenden Queries 

b.Sponsoren können alle Queries (offene und archivierte) zu jeder ihrer 

Studien anzeigen lassen. 

6.Mitarbeiter können alle Queries sehen. 

a.Mitarbeiter müssen zu jeder Studie die aktuell offenen Queries sehen können 

(möglichst direkt auf der Übersichtsseite zu einer Studie). 

b.Mitarbeiter müssen sich zu jeder Studie alle (auch archivierte) Queries 

anzeigen lassen können 

c.Mitarbeiter müssen in allen Queries aller Studien suchen können. 

VI. Recherche im Register über Internet Plattform 

1.Freier Zugang für Alle (kein Login nötig) 

2.Alle Seiten müssen in Englischer und Deutscher Sprache verfügbar sein. 

3.barrierefreier Internetauftritt (wichtig, da potentielle Patienten auch Zielpublikum 

sind, siehe http://de.wikipedia.org/wiki/Barrierefreies_Internet ) 

4.geringe Browseranforderungen 

Die Seiten sollen auch mit alten Browsern (auch ohne Java-Script) lesbar und 

benutzbar sein. Allgemeiner und leichter Zugang ist wichtiger als Optik und Features. 

Siehe auch 3.1.2. 

5.Die Webseiten sollen von Suchmaschinen (Google, Yahoo, ...) durchsuchbar und 

indizierbar sein. 

6.Einfache URLs für einzelne Studien 

a.Jede Studie soll über eine Einfache URL (z.B. 

http://drks.de/studie/) erreichbar sein 

b.Es soll möglich sein, die Studien auch über externe IDs mit einfachen URLs 

zu erreichen (z.B. http://drks.de/studie/ und 

http://drks.de/trial/) 


7.Suchmasken sollen es möglich machen nach bestimmten Studien zu suchen 

a.Eine einfach Suche, bei der durch Eingabe eines Suchbegriffes (Google- 

Style) alle passenden Studien gefunden werden 

b.Eine komplexere Suche, bei der nach Ausprägungen bestimmter Parameter 

gesucht werden kann 

c.Die Suche sollte Reguläre Ausdrücke auflösen können 

d.Es soll bei kodierten Parametern (z.B. Indikation, kodiert nach ICD10) 

möglich sein, im Kodierungsbaum zu „browsen“: Der gesamte Kodierungs- 

Baum soll durchsucht und die zu den Kodierungen passenden Studien 

angezeigt werden können. Mögliche Kodierungen die hierzu benutzt werden 

könnten wären 

a)ICD10 (http://www.dimdi.de/static/de/klassi/diagnosen/icd10/ls- 

icdhtml.htm) 

8.Druckfunktionalität 

b)MeSH (http://www.ncbi.nlm.nih.gov/sites/entrez?db=mesh) 

c)MedDRA.(http://www.meddramsso.com/MSSOWeb/index.htm), 

wobei hier aufgrund der Lizenz-Problematik eine genaue Abstimmung 

zwischen Auftragnehmer und Auftraggeber notwendig ist. 

a.Es muss möglich sein, einzelne Studien und Suchergebnisse mit 

ansprechendem Design (nahe dem Bildschirm-Design) auszudrucken. (z.B. 

durch ein spezielles Stylesheet) 

9.Export in PDF 

VII. Administration 

a.Einzelne Studien sollen als PDF-Datei heruntergeladen werden können. Das 

Layout soll dem der Webseite ähnlich sein. 

1.Das Administrationsinterface steht nur bestimmten Registermitarbeitern zur 

Verfügung. 

2.Ein Administrator kann Mitarbeiter-Accounts einrichten. 

3.Ein Administrator kann Mitarbeitern Administrationsrechte geben 

4.Ein Administrator kann Accounts von Mitarbeitern und Sponsoren deaktivieren 

5.Ein Administrator kann Emailadressen und Kontaktdaten aller Mitarbeiter und 

Sponsoren einsehen und ändern. 

6.Ein Administrator kann Passwörter von Sponsoren und Mitarbeitern zurücksetzen 


a.Dabei soll ein zufälliges Passwort generiert werden, dass an den 

entsprechenden Mitarbeiter oder Sponsor per Email versandt wird. 

7.Ein Administrator kann globale Parameter einstellen wie beispielsweise: 

a.Zeit nach der eine Studie aktualisiert werden soll und eine Erinnerung an die 

Sponsoren verschickt wird 

b.Mailserver Konfiguration 

c.Konfiguration der Suchindizierung, anstoßen einer Neuindizierung 

d.Bearbeiten der Email-Vorlagen, die das System automatisch verschickt 

e.Passwortregeln 

a) Nach welcher Zeit müssen Passwörter geändert werden 

b) Wie muss ein Passwort aussehen (z.B. min. 8 Zeichen, davon eine 

Zahl und ein Sonderzeichen) 

8.Ein Administrator kann die Auswahllisten der Eingabeseiten (siehe f) 

verändern/erweitern 

9.Ein Administrator kann die Übersetzung der Auswahllisten (siehe f) 

bearbeiten/verändern. 

10.Ein Administrator kann die Zieladressen von Benachrichtigungen (beispielsweise 

d) bearbeiten. 

11.Ein Administrator kann Import-Benutzer (siehe 2) anlegen, verändern und löschen. 

12.Ein Administrator kann manuelle Plausibilitätschecks (siehe 7) anlegen und 

bearbeiten 

13.Ein Administrator kann die Zuordnung von Studie zu Sponsoren verändern (Siehe 

III.14) 

14.Ein Administrator muss die Ein- und Ausgabeseiten der Studien anpassen können 

a. es muss möglich sein neue Parameter anzulegen, die erfasst werden sollen. 

Diese Parameter müssen dann auch auf allen Ausgabeseiten erscheinen 

a) Für diese Parameter müssen alle Notwendigen Beschriftungen 

mehrsprachig erfasst werden 

b)Für diese Parameter muss ein Typ festgelegt werden (Freitext, 

Kodiert, Zahl, Datum...) 

c)Für kodierte Parameter müssen die Kodierungen in mehreren 

Sprachen angegeben werden 

b.es muss möglich sein alte Parameter, die nicht mehr erfasst werden sollen, zu 

löschen, sodass sie nicht mehr auf den Ein-/Ausgabeseiten erscheinen 


c.es soll möglich sein alte Parameter zu deaktivieren, sodass sie noch auf den 

Ein-/Ausgabeseiten erscheinen, aber keine Werte mehr für sie eingegeben oder 

geändert werden können 

d.es muss möglich sein deaktivierte Parameter wieder zu aktivieren. 

e.Es muss möglich sein die Reihenfolge der Parameter auf den Ein- und 

Ausgabeseiten zu ändern 

f.Es muss möglich sein, die Beschriftungen der Parameter auf Ein- und 

Ausgabeseiten zu ändern. 

VIII. Eingabeseite für Studien 

1.Steht nur angemeldeten Sponsoren/Mitarbeitern zur Verfügung. 

2.Es müssen alle von der WHO vorgegebenen Parameter eingegeben werden können 

(siehe Anhang 1: WHO Registration Data Set (Version 1.0)). 

a.Das genaue Format der einzugebenden Daten ist mit dem Auftraggeber noch 

abzuklären. 

b.Alle Parameter müssen in Englischer und Deutscher Sprache erfasst werden. 

c.Es kann Parameter geben die das System ausfüllt, und die nicht durch den 

Sponsor geändert werden können (z.B. Parameter 1 und 2) 

d.Bestimmte Administrative Parameter (z.B. Datum der Erstellung der Studie) 

sollen für den Sponsor unsichtbar erfasst werden. 

e.Die in der Liste aufgeführten Parameter werden teilweise noch in weitere 

Parameter unterteilt (Beispiel: Contact Information wird als Adresse mit Titel, 

Vorname, Name, ... eingegeben) 

f.Wo es möglich ist, sollen Auswahllisten statt Freitext die Eingabe und 

Recherche erleichtern. 

Diese Auswahllisten erleichtern auch die Übersetzung, da sie nur einmal 

übersetzt und hinterlegt werden müssen. 

3. „Bestätigtes Missing“ 

a.Für jedes Feld muss es möglich sein es als „Bestätigtes Missing“ zu 

kennzeichnen. 

b.Nur QS kann ein Feld als bestätigtes Missing markieren. 

c.Solche Felder sollen in den Plausibilitätschecks entsprechend behandelt 

werden und werden nicht mehr nachgefragt. 


4.1:n Beziehungen, wie beispielsweise bei Countries of Recruitment, müssen als 

solche eingegeben werden können. 

Bei solchen Konstrukten kann es zu einer Studie mehrere (bei diesem Beispiel) Länder 

geben, in denen die Studie stattfindet. Es muss möglich sein, beliebig viele 

(Obergrenze ist durch Speicherplatz gegeben) dieser Länder einzugeben. 

5.Für Mitarbeiter werden zusätzliche Administrative Parameter angezeigt (z.B. Datum 

der Veröffentlichung, Erstellungsdatum, Authentisierte Studie...) 

a.Welche administrativen Parameter genau benötigt werden, muss der 

Auftragnehmer zusammen mit dem Datenmanagement absprechen. 

IX. Gleichzeitiges Bearbeiten von Studien und Locking 

Es soll ausgeschlossen werden, dass durch gleichzeitiges Bearbeiten von Studien Daten 

verloren gehen oder eine Studie inkonsistente Daten enthält. 

1.Öffnet ein Sponsor oder Mitarbeiter eine Studie um Daten zu verändern, muss dies 

auf dem Server vermerkt werden. 

2.Die Studie gilt solange als geöffnet, bis der bearbeitende Sponsor/Mitarbeiter sie 

speichert oder die Eingabe abbricht (die Eingabeseiten verlässt). 

3.Falls ein Sponsor/Mitarbeiter versucht eine Studie zu bearbeiten, die von einem 

anderen Sponsor/Mitarbeiter gesperrt ist, so soll ihm mitgeteilt werden, wer die Studie 

bearbeitet und damit sperrt. 

a.Ist er selbst der sperrende Sponsor/Mitarbeiter, so siehe 4 

b.Stammt die Sperre von einem anderen Mitarbeiter/Sponsor, so soll er die 

Möglichkeit haben sich mit diesem in Verbindung zu setzen. Dazu sollen die 

verfügbaren Informationen (Name, Email, Telefon...) angezeigt werden. 

4.Falls ein Sponsor, beispielsweise durch schließen des Browser-Fensters, die Studie 

nicht ordnungsgemäß wieder freigegeben hat, soll ein weiteres Bearbeiten dieser 

Studie dennoch möglich sein 

a.Erfolgt ein erneuter Versuch des Bearbeitens der Studie erst nach dem Ende 

seiner Session (siehe 11), so kann er sich wieder anmelden, sollte aber die 

Daten nicht gespeicherten seiner alten Session in irgendeiner Form (z.B. aus an 

ihn versandten einer Email) wieder rekonstruieren können. 

b.Erfolgt ein erneuter Versuch des Bearbeitens der Studie vor dem 

automatischen Ende seiner Session (siehe 11), so soll der Sponsor einen 


Hinweis erhalten, dass er laut System die Studie noch bearbeitet. Er soll nun 

wählen können: 

a)Eingabe fortsetzen und die alten Daten verwerfen 

b)Eingage fortsetzen und die alten Daten übernehmen 

c)Eingabe jetzt abbrechen und alte Session belassen (z.B. wenn er an 

einem anderen Rechner diese Studie im Moment geöffnet hat) 

5.Wird eine Studie in den Status „Veröffentlichung beantragt“ (siehe 2) überführt, 

dann ist sie für den Sponsor zur Eingabe gesperrt. Nur die Mitarbeiter des 

Datenmanagement können nun die Studie bearbeiten. 

6.Folgende Probleme müssen bedacht werden 

X. Plausibilitätschecks 

a)Sicherheit (kann eine Session gekapert werden) 

b)Vergesslichkeit (evtl. läuft eine Session noch in einem anderen 

Browser-Fenster/einem anderen Rechner des Sponsors) 

c)Abstürze (evtl. wurde die Session wirklich abgebrochen) 

d)Komfort: Der Sponsor muss mit möglichst wenig Aufwand (auch 

nach einem Absturz) schnell weiterarbeiten können und soll möglicht 

keine eingegebenen Daten verlieren! 

Plausibilitätschecks sind Tests, die auf Studien angewandt werden, um Unstimmigkeiten 

und Fehler zu erkennen. Die Plausibilitätschecks werden vom Datenmanagement für die 

einzelnen Registerparameter erstellt. 

1.Ein Mitarbeiter kann die Ergebnisse aller Plausibilitätschecks für eine Studien 

ansehen. Dabei sind vor allem die durch die Tests erkannten Fehler interessant 

2.Ein Mitarbeiter kann sich die aggregierten Ergebnisse der Plausibilitsätchecks für 

alle Studien ansehen. Hier soll er sehen können wie viele und welche Studien bei 

welchem Test Fehler erzeugt haben. 

3.Plausibilitätschecks müssen einfach anpassbar sein, da sie im Laufe der Zeit 

verbessert und verfeinert werden. 

4.Die Ergebnisse von Plausibilitätschecks sollen druckbar sein. Dabei ist darauf zu 

achten, dass evtl. viele Daten dargestellt werden müssen, und sie trotzdem noch lesbar 

auf Papier gebracht werden sollen 

5.Studien sollen markiert werden können, so dass sie in den Fehlerlisten der 

Plausibilitätschecks gesondert auftauchen. Damit soll erreicht werden, dass Studien, 


ei denen ein Check immer fehlschlägt im Bedarffall aus der Liste gestrichen werden 

können, um wiederholte Queries zu vermeiden. 

6.Die Ergebnisse der Plausibilitätschecks sollen als CSV-Daten exportiert werden 

können, um eine anschließende Weiterverarbeitung in anderen Programmen (z.B. 

Excel) zu ermöglichen. 

7.Es müssen auch manuelle Plausibilitätschecks vom System unterstützt werden. 

a.Dazu soll es möglich sein, eine Liste von manuellen Checks zu pflegen 

b.Das Datenmanagement soll jedem Check in jeder Studie einen der Werte 

Erfolg, Misserfolg, nicht zutreffend und nicht durchgeführt zuordnen können. 

c.Die Ergebnisse der manuellen Plausibilitätschecks sollen in die Übersichten 

mit einfließen. 

d.Manuelle Plausibilitätschecks die einmal in Studien benutzt wurden dürfen 

nicht gelöscht werden, da sonst die Zuordnung zu diesen alten Studien verloren 

geht. 

8.Plausibilitätschecks können deaktiviert werden, sodass sie bei neuen Studien nicht 

mehr benutzt werden. 

XI. Datenimport 

Zusätzlich zu der Möglichkeit, dass einzelne Sponsoren einzelne Studien importieren, 

muss es möglich sein mit geringem Aufwand Daten anderer Register zu importieren. 

1.Der Import von Daten anderer Register soll über einen Webservice möglich sein. 

2.Der Import soll nur durch authentifizierte Import-Benutzer erfolgen 

a.Ein Import-Benutzer wird von einem Administrator verwaltet (siehe 11) 

b.Ein Import-Benutzer ist im Normalfall ein Mitarbeiter eines anderen 

Registers, der sich technisch um den Import kümmert. Er ist typischerweise 

nicht zuständig für die Studiendaten. 

c.Ein Import-Benutzer wird durch folgende Daten charakterisiert 

a)Email 

b)Name 

c)Adresse 

d)Passwort 

e)Organisation der der Import-Benutzer angehört 

3.Beim Import von Studien sollte ein ähnliches Format genutzt werden, wie beim 

Import aus einem File (siehe 7) 


a.Diese Daten müssen aber noch mit Informationen zum Ansprechpartner für 

diese Studie angereichert werden 

4.Es muss möglich sein, Studien über einen weiteren Import zu aktualisieren, so dass 

die manuelle Aktualisierung durch den Sponsor entfallen kann. 

5.Import und Aktualisierungen müssen dem Datenmanagement durch eine Email 

mitgeteilt werden. 

XII. Datenexport 

Es soll auch möglich sein, andere Register mit Daten aus dem DRKS zu beliefern. Dazu 

soll eine Export-Schnittstelle implementiert werden. Da es zum jetzigen Zeitpunkt noch 

keinen definierten Nutzer der Exportschnittstelle gibt, ist sie entsprechend offen zu 

gestalten. 

1.Der Export soll als Webservice implementiert sein 

2.Der Export soll es gestatten einzelne Studien (definiert durch die Studiennummer) 

zu exportieren 

3.Der Export mehrerer Studien soll möglich sein 

a.Dazu soll der Webservice er ermöglichen alle Studien zu exportieren, die 

bestimmten Kriterien entsprechen. Diese Kriterien könnten analog zur 

Suchmaske der Website (siehe 7) implementiert sein 

4.Die Such- und Exportfunktion darf die Stabilität und Geschwindigkeit des Registers 

nicht gefährden. 

XIII. Qualitätsanforderungen der Softwareentwicklung 

1.Vom Auftragnehmer ist ein geeignetes Softwareentwicklungsmodell (z.B. das 

VModell XT für Auftragnehmer) anzuwenden 

a.Auftraggeber und Auftragnehmer definieren gemeinsam Meilensteine 

a)zu bestimmten Meilensteinen sind Prototypen vorzulegen. 

b)Zu bestimmten Terminen werden Code Reviews durchgeführt. Dabei 

werden sowohl der Applikationscode, wie auch der Code der 

Testprozeduren untersucht. 

2.Vom Auftragnehmer sind geeignete Versionierungsmechanismen zu benutzen 

3.Vom Auftragnehmer wird erwartet ein funktionierendes System zur Sicherstellung 

der Qualität in der Softwareentwicklung zu benutzen 


4.Der Auftragnehmer hat durch (automatisierte) Tests sicherzustellen, dass die 

Software den Anforderungen genügt. Diese Tests sind Teil der Softwareentwicklung 

und müssen mit dem Sourcecode ausgeliefert werden. 

5.Eine klare Trennung der Schichten (Frontend, Middleware, Business, Database) soll, 

z.B. durch den Einsatz von Design-Patterns, gewährleistet sein. 

6.Ergonomie im Webdesign ist für gute Benutzbarkeit der Software essentiell. Daher 

sollten beim Auftragnehmer entsprechende Kenntnisse nachweisbar sein (z.B. ein/e 

ausgebildeter Mediendesigner/in verfügbar sein). 

XIV. Wartungsvertrag 

Zwischen Auftragnehmer und Auftraggeber soll ein Wartungsvertrag abgeschlossen 

werden, der festlegt zu welchen Konditionen und mit welcher Reaktionsgeschwindigkeit 

der Auftragnehmer bei Problemen mit der Software reagieren muss. 

1.Auftragnehmer und Auftraggeber müssen definieren, was kritische und nicht 

kritische Fehler sind. 

a.Es muss festgelegt sein, wie der Auftragnehmer auf kritische und nicht 

kritische Fehler reagieren muss 

2.Die generelle Verfügbarkeit und Erreichbarkeit des Auftragnehmers muss festgelegt 

sein. 


6. Datenmenge 

Die zu erwartenden Datenmengen werden mit ca. 5000 Studien/Jahr geschätzt. Die Software 

muss für mindestens 10 Jahre performant arbeiten und somit 50.000 Studien und 50.000 

Sponsoren/Benutzer verwalten können. 

Testweise sollte ein Versuch mit 100.000 Studien und Benutzern zeigen, dass die Software 

auch dann noch benutzbar ist, auch wenn die Antwortzeiten sich in diesem Fall verdoppeln 

dürfen. Hierzu sollten automatische Testscripte erzeugt werden. 

Es sollten keine Probleme im Bezug auf Speicherplatz auftreten, da die erwarteten 

Datenmengen für aktuelle Festplatten kein Problem darstellen. 

7. Qualitätsziele 

Die entwickelte Software soll eine hohe Qualität aufweisen. Daher sind dem Stand der 

Technik entsprechende Software-Engineering und Qualitätssicherungsmethoden anzuwenden. 

Diese sollten mindestens eine Versionsverwaltung der Software umfassen, die nicht nur die 

Release-Versionen einschließt, sondern alle Entwicklungsschritte. Weiterhin werden Unit- 

Tests als sehr wichtig erachtet, da sie das Funktionieren essentieller Bestandteile der Software 

auch nach Änderungen sicherstellen können. Es sollten Arbeitsanweisungen durch den 

Auftraggeber einsehbar sein, die den Umgang mit den entsprechenden qualitätssichernden 

Maßnahmen beschreiben. 

8. Begriffserklärungen 

Auftraggeber: Die Universität Freiburg, Institut für medizinische Biometrie und 

medizinische Informatik, Abteilung DRKS 

Auftragnehmer: Die vom Auftraggeber mit der Softwareentwicklung beauftragt Firma. 

Besucher: Ein Besucher der externen öffentlichen Webseite des Registers 

Deutsches Register Klinischer Studien (DRKS): Das vom BMBF geförderte Projekt zur 

Erstellung eines Register Klinischer Studien in Deutschland. 

DM: Datenmanagement. Meist auch die zum Datenmanagement und zur 

Qualitätssicherung angestellten Mitarbeiter des DRKS. 


Import-Benutzer: Eine Person, die stellvertretend für eine andere Organisation (EK, 

LKP: Siehe Sponsor. 

anderes Register...) Daten mehrerer Studien in das Register importiert. 

Mitarbeiter: Ein Mitarbeiter ist eine beim Deutschen Register Klinischer Studien 

angestellte Person, die mit der Datenerfassung, dem Datenmanagement oder 

der Qualitätssicherung befasst ist. Sie hat Zugang zu allen Studien und im 

Vergleich zum Sponsor erweiterte Rechte, wie beispielsweise die 

Veröffentlichung von Studien. 

QS: Qualitätssicherung. Meist auch ein Mitglied der Qualitätssicherung des 

Registers. 

Sponsor: Die Person, die für eine Studien verantwortlich ist. In Deutschland 

zusätzlich LKP (Leiter der klinischen Prüfung) genannt. 


9. Anhang 1: WHO Registration Data Set (Version 1.0) 

Aus http://www.who.int/ictrp/data_set/en/index.html (Stand: 15.10.2007) 

Item Field Value Definition/Explanation 

1 

2 

Primary 

Register and 

Trial ID # 

Date of 

Registration in 

Primary 

Register 

3 Secondary 

ID#s 

4 

Source(s) of 

Monetary or 

Material 

Support 

5 Primary 

Sponsor 

6 Secondary 

Sponsor(s) 

Trial ID # 

Issuing Authority 

ID Number 

Click to add more … 

Name 

Click to add more… 

Name 

Name 

Click to add more... 

Name of Primary Register, and the 

unique ID number assigned by the 

Primary Register to this trial. 

Date when trial was officially registered in 

the Primary Register. 

Other identifying numbers and issuing 

authorities besides the Primary Register, 

if any. Include the sponsor name and 

sponsor-issued trial number (e.g., 

protocol number) if available. Also 

include other trial registers that have 

issued an ID number to this trial. There is 

no limit on the number of Secondary ID 

numbers that can be provided. 

Major source(s) of monetary or material 

support for the trial (e.g., funding agency, 

foundation, company). 

The individual, organization, group or 

other legal entity which takes 

responsibility for initiating, managing 

and/or financing a study. 

The Primary Sponsor is responsible for 

ensuring that the trial is properly 

registered. The Primary Sponsor may or 

may not be the main funder 

Additional individuals, organizations or 

other legal persons, if any, that have 

agreed with the primary sponsor to take 

on responsibilities of sponsorship. 

A secondary sponsor may have agreed 

• to take on all the responsibilities 

of sponsorship jointly with the 

primary sponsor; or 

• to form a group with the primary 

sponsor in which the 

responsibilities of sponsorship 

are allocated among the 

members of the group; or 

• to act as the sponsor’s legal 

representative in relation to 

some or all of the trial sites; or 

• to take responsibility for the 

accuracy of trial registration 

information submitted. 

7 Contact for Email, telephone number, or address Email address, telephone number, or 


8 

Public Queries 

Contact for 

Scientific 

Queries 

9 Public Title 

10 Scientific Title 

11 

12 

Countries of 

Recruitment 

Health 

Condition(s) or 

Problem(s) 

Studied 

13 Intervention(s) 

Email, telephone number, or address 

Affiliation 

Acronym 

Intervention name(s) 

Other details (e.g., dose, duration, etc.) 

Click to add more experimental 

interventions… 

Control Intervention name 

Other details of control (e.g., dose, duration, 

etc.) 

Click to add more control interventions… 

postal address of the contact who will 

respond to general queries, including 

information about current recruitment 

status 

Email address, telephone number, or 

postal address, and affiliation of the 

person to contact for scientific queries 

about the trial (e.g., principal investigator, 

medical director employed by the 

sponsor). For a multi-center study, enter 

the contact information for the lead 

Principal Investigator or overall scientific 

director. 

Title intended for the lay public in easily 

understood language. 

Scientific title of the study as it appears in 

the protocol submitted for funding and 

ethical review. Include trial acronym if 

available. 

The countries from which participants will 

be, are intended to be, or have been 

recruited. 

Primary health condition(s) or problem(s) 

studied (e.g., depression, breast cancer, 

medication error). If the study is 

conducted in healthy human volunteers 

belonging to the target population of the 

intervention (e.g., preventative or 

screening interventions), enter the 

particular health condition(s) or 

problem(s) being prevented. If the study 

is conducted in healthy human 

volunteers not belonging to the target 

population (e.g., a preliminary safety 

study), an appropriate keyword will be 

defined for users to select. 

Enter the specific name of the 

intervention(s) and the 

comparator/control(s) being studied. 

Use the International Non-Proprietary 

Name if possible (not brand/trade 

names). For an unregistered drug, the 

generic name, chemical name, or 

company serial number is acceptable. If 

the intervention consists of several 

separate treatments, list them all in one 

line separated by commas (e.g., "low-fat 

diet, exercise"). 

The control intervention(s) is/are the 

interventions against which the study 

intervention is evaluated (e.g., placebo, 

no treatment, active control). If an active 

control is used, be sure to enter in the 

name(s) of that intervention, or enter 

"placebo" or "no treatment" as 

applicable. 

For each intervention, describe other 

intervention details as applicable (dose, 


14 

Key Inclusion 

and 

Exclusion 

Criteria 

15 Study Type 

16 

17 

Date of First 

Enrollment 

Target Sample 

Size 

18 Recruitment 

Status 

19 Primary 

Outcome(s) 

20 

Key Secondary 

Outcomes 

Inclusion Criteria 

Exclusion Criteria 

Outcome Name 

Timepoints 

Click to add more outcomes… 

duration, mode of administration, etc) 

Inclusion and exclusion criteria for 

participant selection, including age and 

sex. 

A single arm study is one in which all 

participants are given the same 

intervention. Trials in which participants 

are assigned to receive one of two or 

more interventions are NOT single arm 

studies. Crossover trials are NOT single 

arm studies. 

A trial is "randomized" if participants are 

assigned to intervention groups using a 

method based on chance (e.g., random 

number table, random computergenerated 

sequence, minimization, 

adaptive randomization). 

If the trial is being registered after 

recruitment of the first participant record 

actual date of Anticipated date of 

enrollment of the first participant. 

Number of participants that this trial 

plans to enroll. 

Recruitment status of this trial. 

• Pending: participants are not yet 

being recruited or enrolled at any 

site 

• Active: participants are currently 

being recruited and enrolled 

• Temporary halt: there is a temporary 

halt in recruitment and enrollment 

• Closed: participants are no longer 

being recruited or enrolled 

Outcomes are events, variables, or 

experiences that are measured because 

it is believed that they may be influenced 

by the intervention. The Primary 

Outcome should be the outcome used in 

sample size calculations, or the main 

outcome(s) used to determine the effects 

of the intervention(s). 

Enter the names of all primary outcomes 

in the trial as well as the pre-specified 

timepoint(s) of primary interest. Be as 

specific as possible with the metric used 

(e.g., “% with Beck Depression Score > 

10 ”rather than just “depression”). 

Examples: 

Outcome Name: all-cause mortality, 

Timepoints: 5 years; or Outcome Name: 

Mean Beck Depression Score, 

Timepoint: 18 weeks 

Outcome Name Secondary outcomes are events, 

variables, or experiences that are of 


Timepoints 

Click to add more outcomes… 

secondary interest or that are measured 

at timepoints of secondary interest. A 

secondary outcome may involve the 

same event, variable, or experience as 

the primary outcome, but measured at 

timepoints other than those of primary 

interest (e.g., Primary outcome: all-cause 

mortality at 5 years; Secondary outcome: 

all-cause mortality at 1 year, 3 years), or 

may involve a different event, variable, or 

experience altogether (e.g., Primary 

outcome: all-cause mortality at 5 years; 

Secondary outcome: hospitalization rate 

at 5 years). 

Enter the name and timepoint(s) for all 

secondary outcomes of clinical and/or 

scientific importance. Be as specific as 

possible with the metric used (e.g., “% 

with Beck Depression Score > 10” rather 

than just “depression”). Examples: 

Outcome Name: all-cause mortality, 

Timepoint: 6 months, 1 year; or Outcome 

Name: Mean glycosylated hemoglobin 

A1C, Timepoint: 4 and 8 weeks 

Last update: 19 June 2007 

10. Anhang 2: Beschreibung des Deutschen Registers 

Klinischer Studien (Auszug aus dem Förderantrag) 

10.1. Specification of the German register of clinical trials 

10.1.1. 1. Background Statement 

It is now generally accepted that the evidence from all well conducted controlled (and 

randomised, if existing) trials should be the base for decisions in healthcare and for the 

planning of further medical research i,ii,iii . Identifying all relevant trials is a difficult task and is 

almost entirely dependent on the published literature. A significant proportion of clinical trials 

research is, however, never published. This can lead to a significantly distorted assessment of 

an intervention due to publication bias, defined as “the tendency on the parts of investigators, 

reviewers, and editors to submit or accept manuscripts for publication, based on the direction 

or strength of the study findings” iv . It has been demonstrated that trials with a statistically 

significant result take less time to being published, and are more likely to actually be 

published, than those with null or negative results v,vi . 

Comprehensive, publicly accessible clinical trial registries are now widely accepted as an 

essential tool to fill this gap vii,viii,ix,x,xi,xii . They would not only inform about all conducted but 

also about ongoing trials, if registration happens at inception. 

Such registries serve healthcare and medical research by 

• reducing the negative impact of publication bias by presenting a complete picture of 

all clinical trials investigating a specific healthcare problem. 


• allowing researchers to learn valuable lessons from the experience of those who have 

previously tested and found no benefit (or even harm) of a related intervention. 

• supporting organisations (funders, ethics committees etc.) with complete information 

about ongoing and completed trials for the planning and assessment of new trials, 

thus helping to avoid unnecessary duplication of research activities and improve the 

processes associated with clinical trials. 

• ensuring the ethical request on behalf of participating subjects that the results of all 

studies contribute to medical knowledge xiii,xiv,xv,xvi . 

• informing the public, the medical profession and potential participants about ongoing 

trials to improve the recruitment for trials and to help patients to find trials. 

Prospective registration of clinical trials has the support of numerous organisations 

internationally and nationally (for Germany described in chapter 5). However, this support 

has not led to a global system that would enable easy identification of trials worldwide so far. 

International and national registration and registers 

The need and the benefit of prospective clinical trial registration has been discussed since 

more than 40 yearsvii and has led to an increasing number of clinical trials registries, disease 

or method-specific and all-inclusive, throughout the world and also in Germany (see below). 

During the last three years a few events had a massive impact on this issue and intensified the 

demand for registration xvii . The existence of ongoing serious publication bias was 

demonstrated by several studies xviii and in one case even led to the prosecution of a 

pharmaceutical company by the general attorney of New York. GlaxoSmithKline (GSK) was 

accused of only publishing two positive out of six trials on the antidepressant Paxil for 

children xix and not reporting the increased suicide rate. 

The largest impact came from the remarkable move of the International Committee of 

Medical Journal Editors (ICMJE). They announced a new policy and declared that their 

member journals would publish reports of trials after 1 July 2005 (resp. 13 Sept. 2005 for 

already running trials) only if the trial was registered with a register which meets certain 

criteria xx,xxi,xxii . 

Two registers can be considered global because they accept the registration of trials from any 

country: ClinicalTrials.gov (www.clinicaltrials.gov) is funded by the US National Institutes of 

Health (NIH) and operated by the National Library of Medicine (NLM). After the 

establishment as US register it was opened to worldwide registration in October 2004, in 

response to the new ICMJE policy xxiii . The second global player is Current Controlled Trials 

(CCT; www.controlled-trials.com), a subgroup of the publisher BioMed Central. 

There is no systematic list of existing national registers. However, several are known from 

their activities in international workgroups and publications (see Appendix 1; received 

informally from WHO). In some countries a certain proportion of trials is registered 

systematically (e.g. trials funded by the Canadian Institute of Health Research, CIHR, are 

registered with CCT) while some countries set up registers to achieve complete coverage (e.g. 

Australia, Netherlands). In spite of differences due to specific conditions of healthcare and 

research systems, these activities are facing very similar challenges and difficulties xxiv . The 

dominant issues are the achievable degree of completeness and how to ensure it, which details 

to register, when to register, if and how to update the information and how to set up a working 

quality assurance mechanism. 

Non-comprehensive registers, covering only selected diseases or limited areas, may make 

sense but are prohibitive to an efficient global search for trials and increase the complexity of 

the existing register structure. To allow a user-friendly search, if possible through one global 

search portal, the World Health Organisation (WHO) decided to take the leadership and the 


coordination of the development of a globally working network of registers xxv . With the 

approval of the World Health Assembly in May 2005, the International Clinical Trials 

Registry Platform (ICTRP) was established to take the lead in setting international norms and 

standards for trial registration and reporting. The Registry Platform consults with relevant 

stakeholders worldwide to produce consensus-based policies which uphold scientific and 

ethical principles on clinical trials but which are also practical and feasible. 

Trial Registration in Germany 

The discussion of trial registration has a shorter history in Germany (see Appendix 2) than in 

some of the countries leading this field xxvi . More than 30 disease-specific or otherwise 

focussed registers of very variable structure and quality are currently in operation in various 

environments (see Appendix 3) but there is no comprehensive national German register and 

no national coordination and structuring of the registration of trials conducted in 

Germany xxvii,xxviii,xxix . In spite of the well promoted request from the ICMJE and the selfcommitment 

to full transparency xxx,xxxi only a small proportion of the (unknown) number of 

trials is registered in one of the two international registers ClinicalTrials.gov and CCT which 

fulfil the conditions of ICMJE. 748 and 163 (ascertained at different time points) of the 

estimated 5000 eligible trials in Germany per year can with some difficulties be identified in 

the two registers (see Appendix 4). Figures are only approximations but clearly show that the 

registration rate is not anywhere close to a satisfactory proportion. 

i NHMRC. A guide to the development, implementation and evaluation of clinical 

practice guidelines. ©Commonwealth of Australia. 1999. ISBN 1864960485 

ii Goodman KW. Problems with biomedical research data and reports. In: Ethics and 

Evidence-Based Medicine. Cambridge University Press, 2003. p. 52 

iii European Federation of Pharmaceutical Industries and Associations. Joint position on 

the disclosure of clinical trial information via clinical trial registries and databases. 

January 2005 

iv Dickersin K. Why register clinical trials? Control Clin. Trials. 1992;13:170-177 

v Stern JM, Simes RF. Publication bias: Evidence of delayed publication in a cohort 

study of clinical research projects. BMJ. 1997;315:640-645 

vi Simes RJ. Confronting publication bias: a cohort design for meta-analysis. Statistics 

in Medicine. 1987;6:11-29 

vii Dickersin K, Rennie D. Registering clinical trials. JAMA. 2003;290:516-523 

viii Simes RJ. Publication bias: the case for an international registry of clinical trials. 

Journal of Clinical Oncology. 1986,4(10):1529-41 

ix Easterbrook Easterbook P. Reducing publication bias. [Letter] British Medical Journal 

Clinical Research Ed. 1987,295(6609):1347 

x Chalmers I, Dickersin K, Chalmers TC. Getting to grips with Archie Cochrane’s agenda. 

[Editorial] BMJ. 1992,305(6857):786-8 


xi International Collaborative Group on Clinical Trial Registries. Position paper and 

consensus statement on clinical trial registries. Clinical Trials and Meta-Analyses. 

1993;28:199-201 

xii Abbasi K. Compulsory registration of clinical trials. BMJ. 2004;329;637-638 

xiii Pearn J. Publication: an ethical imperative. BMJ. 1995;310:1313-1315 

xiv Raspe H, Hüppe A, Steinmann M. Identifizierung, Studienregistrierung und Meldung. 

In: Empfehlungen zur Begutachtung klinischer Studien durch Ethik-Kommissionen. 

Deutscher Ärzte-Verlag, Köln, 2006. S.13-16 

xv Antes G. Registering clinical trials is necessary for ethical, scientific and economic 

reasons. Bulletin of the World Health Organization. 2004;82(5):321 

xvi Victor N. Klinische Studien: Notwendigkeit der Registrierung aus Sicht der 

Ethikkommissionen. Deutsches Ärzteblatt. 2004;101(30):A2111-2116,A1 

xvii Haug C, Gøtzsche PC, Schroeder TV. Registries and Registration of Clinical Trials. 

New England Journal of Medicine. 2005;353(26):2811-2812 

xviii Gibbs TG, Wager E. Realities of trial registration: the Glaxo Wellcome experience. 

International Journal of Pharmaceutical Medicine. 2000;14:203-205 

xix http://www.oag.state.ny.us/press/2004/jun/jun2b_04.html 

xx De Angelis CD, Drazen JM, Firzelle FA, Haug C, Hoey J, Horton R, Kotzin S, Laine 

C, Marusic A, Overbeke A J, Schroeder TV, Sox HC, Van der Weyden MB. Is this clinical 

trial fully registered? Annals of Internal Medicine. 2005;143(2):146-148 

xxi http://www.icmje.org/ 

xxii Drazen JM, Wood AJJ. Trial Registration Report Card. New England Journal of 

Medicine. 2005; 353(26):2809-2811 

xxiii Zarin AD, Tse T, Ide CN. Trial Registration at ClinicalTrials.gov between May and 

October 2005. New England Journal of Medicine. 2005; 353(26):2779-2787 

xxiv Fisher BC. Clinical Trials Results Databases: Unanswered Questions. Science. 2006; 

311:180-181 

xxv http://www.who.int/ictrp/en/ 

xxvi Schumacher M, Beck M, Roßner R. European Cancer Clinical Trial Register 

(ECCTR) – eine aktuelle, europaweite Informationsquelle über Therapiestudien in der 

Onkologie. Forum DKG. 1996;11:220-223 

xxvii Feurle GE. BfArM-Register ausbauen. Zu dem Beitrag: Klinische Studien: 

Registrierung aus Sicht der Ethikkommissionen von Prof. Victor N. in Heft 30/2004. 

Deutsches Ärzteblatt. 2005;102(10):A681 

Pflichtenheft: Software zum Betrieb des Deutschen Registers Klinischer Studien 

41/39

xxviii Victor N. Schlusswort zu dem Beitrag: BfArM-Register ausbauen von Prof. 

Feurle in Heft 10/2005. Deutsches Ärzteblatt. 2005;102(10):A681 

xxix Bestehorn K, Hönig R, Clemens N, Kirch W. Register für klinische Studien – eine 

kritische Bestandsaufnahme. Medizinische Klinik. 2006;101(2):120-126 

xxx IFPMA, Efpia, PhRMA, JPMA. Joint Position on the Disclosure of Clinical Trial 

Information via Clinical Trial Registries and Databases. Announced on January 6, 2005 

xxxi IFPMA. IFPMA improves Biomedical Data Transparency with Launch of First 

Worldwide Clinical Trials Portal. Announced on September 21, 2005 

Pflichtenheft: Software zum Betrieb des Deutschen Registers Klinischer Studien 

42/39

Pflichtenheft - Universitätsklinikum Freiburg

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?