Pflichtenheft - Universitätsklinikum Freiburg
Pflichtenheft - Universitätsklinikum Freiburg
Pflichtenheft - Universitätsklinikum Freiburg
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
<strong>Pflichtenheft</strong><br />
Software zum Betrieb des<br />
Deutschen Registers Klinischer Studien<br />
(DRKS)<br />
Gabriele Dreier<br />
Zentrum Klinische Studien<br />
<strong>Universitätsklinikum</strong> <strong>Freiburg</strong><br />
Elsässer Str. 2<br />
D-79110 <strong>Freiburg</strong><br />
gabriele.dreier@uniklinik-freiburg.de<br />
Autor: Rainer Peters<br />
Version: 1.2<br />
Datum: 10.03.2008<br />
Projektleiter<br />
Technischer Ansprechpartner:<br />
Rainer Peters<br />
Zentrum Klinische Studien<br />
<strong>Universitätsklinikum</strong> <strong>Freiburg</strong><br />
Elsässer Str. 2<br />
79110 <strong>Freiburg</strong><br />
rainer.peters@uniklinik-freiburg.de<br />
Dr. Gerd Antes<br />
Deutsches Cochrane Zentrum<br />
Institut für Medizinische Biometrie<br />
und Medizinische Informatik<br />
Universität <strong>Freiburg</strong><br />
Stefan-Meier-Str. 26<br />
D-79104 <strong>Freiburg</strong><br />
antes@cochrane.de<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 1/39
Inhaltsverzeichnis<br />
1. Zielbestimmung ........................................................................................................... 3<br />
1.1. Beschreibung der Register-Software............................................................................ 3<br />
1.2. Abgrenzungskriterien................................................................................................... 5<br />
1.3. Lieferungen an den Auftraggeber ................................................................................ 5<br />
1.4. Weitere Referenzen...................................................................................................... 6<br />
1.5. Ablauf der Registrierung.............................................................................................. 6<br />
1.6. Verbindung zum ICTRP-Portal der WHO................................................................... 7<br />
2. Einsatz.......................................................................................................................... 8<br />
2.1. Zielgruppen .................................................................................................................. 8<br />
2.2. Betriebsbedingungen.................................................................................................... 8<br />
3. Umgebung.................................................................................................................... 9<br />
3.1. Software ....................................................................................................................... 9<br />
3.1.1. Server.................................................................................................................. 9<br />
3.1.2. Client................................................................................................................... 9<br />
3.2. Hardware...................................................................................................................... 9<br />
4. Funktionalität ............................................................................................................. 10<br />
4.1. Use-Cases:.................................................................................................................. 10<br />
4.1.1. Sponsor beantragt Account............................................................................... 10<br />
4.1.2. Sponsor legt Studie an / bearbeitet Studie ........................................................ 11<br />
4.1.3. Datenmanagement im DRKS ........................................................................... 13<br />
4.1.4. Ein Besucher der Webseite sucht nach Studien................................................ 13<br />
5. Requirements.............................................................................................................. 15<br />
6. Datenmenge................................................................................................................ 33<br />
7. Qualitätsziele.............................................................................................................. 33<br />
8. Begriffserklärungen.................................................................................................... 33<br />
9. Anhang 1: WHO Registration Data Set (Version 1.0)............................................... 35<br />
10. Anhang 2: Beschreibung des Deutschen Registers Klinischer Studien (Auszug aus<br />
dem Förderantrag) .................................................................................................................... 38<br />
10.1. Specification of the German register of clinical trials........................................... 38<br />
10.1.1. 1. Background Statement.................................................................................. 38<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 2/39
1. Zielbestimmung<br />
Die zu entwickelnde Anwendung stellt die technische Basis des Deutschen Registers<br />
Klinischer Studien dar. Sie lässt sich inhaltlich in drei Bereiche aufteilen:<br />
1.) Dateneingabe/Datenimport:<br />
a. Die beschreibenden Daten einer oder mehrerer Studien werden vom<br />
entsprechenden Sponsor oder den beauftragten Personen eingegeben oder über<br />
b. eine Import-Schnittstelle importiert oder<br />
c. von Register-Mitarbeitern eingegeben.<br />
2.) Datenmanagement: Die eingegebenen Daten werden überprüft und durchlaufen dabei<br />
automatisierte und manuelle Tests. Bei Unvollständigkeit oder Unstimmigkeiten sollen<br />
manuelle oder automatische Queries ausgegeben werden. Genügen die Daten den<br />
Qualitätskriterien werden sie von einem Datenmanager veröffentlicht.<br />
3.) Öffentliche Datenbank: Veröffentlichte Daten liegen in einer öffentlich zugänglichen<br />
Datenbank und können über das Internet eingesehen werden. Über benutzerfreundliche<br />
Recherchehilfen, Suchdialoge und Aggregationen kann auf die Daten zugegriffen werden.<br />
Auf der öffentlichen Webseite können die Datenmanager des Registers die Öffentlichkeit<br />
auch über aktuelle Gegebenheiten informieren.<br />
Die zu erstellende Software (im Weiteren Register-Software genannt) muss alle diese<br />
Bereiche abdecken.<br />
1.1. Beschreibung der Register-Software<br />
1.) Dateneingabe/Datenimport:<br />
Die Registrierung einer neuen Studie und die Bearbeitung bereits eingegebener<br />
Studien durch einen Sponsor werden über ein Webinterface durchgeführt. Bei der<br />
Gestaltung der Eingabe- und Bearbeitungsmasken für die Dateneingabe muss<br />
besonders auf eine einfache Bedienung und eine gute Dokumentation Wert gelegt<br />
werden. Die abgefragten Parameter müssen sowohl in englischer wie auch in<br />
deutscher Sprache eingegeben werden. Die Anwender dieses Bereichs der Software<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 3/39
sind meist Personen, die die Software nur selten benutzen werden. Es ist also mehr<br />
Wert auf eine verständliche Oberfläche zu legen als auf eine sehr schnelle und direkte<br />
Bedienbarkeit (z.B. Tastatur-Shortcuts), welche mehr Einarbeitungsaufwand erfordern<br />
würde. Die Sponsoren sollen mit möglichst wenig Aufwand ihre Daten eingeben<br />
können, da nur so eine hohe Akzeptanz der Studienregistrierung sichergestellt werden<br />
kann.<br />
2.) Datenmanagement:<br />
Die Mitarbeiter des Datenmanagements haben einen anderen Zugang zur Software.<br />
Sie benutzen die Anwendung sehr oft. Somit ist in diesem Bereich mehr Wert auf<br />
schnelle, direkte Bedienung zu legen, als auf ausführliche Online-Hilfestellungen. Das<br />
Datenmanagement wird sich im Laufe der Projektzeit verändern und an äußere<br />
Gegebenheiten anpassen müssen. In diesem Bereich werden wahrscheinlich stärkere<br />
Veränderungen an der Software notwendig sein als im Bereich der Dateneingabe (z.B.<br />
neue Parameter). Diesem Umstand muss schon während der Entwicklung Rechnung<br />
getragen werden. Auch das Datenmanagement sollte die Software über ein<br />
Webinterface bedienen können. Eine Desktop-Client-Version ist aus Gründen der<br />
Betriebsystem-Unabhängigkeit nicht vorgesehen.<br />
3.) Öffentliche Datenbank:<br />
Die öffentliche Datenbank Klinischer Studien wird vom Internet aus zugänglich sein. Sie<br />
ist der zentrale Punkt an dem das Register der Öffentlichkeit zur Verfügung gestellt wird.<br />
Hier steht als Benutzer die Öffentlichkeit im Focus. Diese kann man grob in drei<br />
Personenkreise einteilen:<br />
α.) Personen, die medizinisch nicht sehr bewandert sind (Laien) und sich über eine<br />
Krankheit informieren wollen und nach Studien oder Kontaktpersonen suchen<br />
β.) Medizinisch versierte Personen, die nach Studien oder Kontakten zu einer<br />
bestimmten Fragestellung suchen<br />
χ.) Allgemeine Öffentlichkeit, Journalisten die Übersichten brauchen und gezielt<br />
recherchieren.<br />
Hauptaufgabe der öffentlichen Website des Registers wird es sein, Studien einfach<br />
auffindbar zu machen und Informationen zu den Studien in übersichtlicher Form<br />
anzuzeigen.<br />
Allen Personenkreisen muss auf den öffentlichen Webseiten Rechnung getragen werden,<br />
indem ihre speziellen Bedürfnisse bedacht werden. So kann ein medizinisch bewanderter<br />
Besucher auch eine komplexe Suchmaske bedienen, in der einzelne Parameter wie<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 4/39
Endpunkte der Studie oder Indikationen eingegrenzt werden können. Der „medizinische<br />
Laie“ dagegen benötigt eine einfach Suchfunktion, die nach der Eingabe eines<br />
Suchbegriffes alle möglicherweise relevanten Studien findet, und ihm die Möglichkeit<br />
gibt, diese weiter einzugrenzen.<br />
1.2. Abgrenzungskriterien<br />
Die Software soll ausschließlich als Webanwendung implementiert werden. Es geht nur um<br />
die Eingabe, Verwaltung und Ausgabe von Daten zu Klinischen Studien.<br />
Es geht nur um die Entwicklung bzw. Nutzung von Softwarelösungen.<br />
Hardwarekomponenten sind nur in sofern betroffen, als dass spezifiziert werden muss, auf<br />
welcher Hardware die Systeme lauffähig sein werden.<br />
1.3. Lieferungen an den Auftraggeber<br />
Alle zu liefernden Teilpakete müssen versionskontrolliert sein, und in einer konsistenten und<br />
zueinander passenden Version abgeliefert werden. Der Auftragnehmer wird verpflichtet<br />
entsprechende Integrationstests durchzuführen und die entsprechende Dokumentation mit<br />
jeweils neuen Versionen zu übergeben:<br />
• Die Software als installierbare Pakete (als Datenträger oder Download)<br />
• Benutzerhandbuch zur Software in deutscher und englischer Sprache<br />
• Installationsbeschreibung der Software (inkl. Anforderungen an Hard- und Software)<br />
in deutscher Sprache<br />
• Der Sourcecode der Software (im Falle einer Erweiterung einer existierenden<br />
Software der Sourcecode der Erweiterung) und aller verwendeter Bibliotheken.<br />
• Alle entwickelten Testprozeduren und Testprotokolle in deutscher oder englischer<br />
Sprache<br />
• Komplette Dokumentation des Sourcecodes in deutscher oder englischer Sprache<br />
• Aus den gelieferten Komponenten muss sich die Anwendung vom Auftraggeber<br />
erstellen lassen und den vollen Funktionsumfang bieten.<br />
• Der Auftraggeber muss das Recht haben, den entwickelten Sourcecode weiter zu<br />
verändern, zu erweitern, zu veräußern und Dritten zur Verfügung zu stellen<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 5/39
• Wird eine schon existierende Software verwendet, so kann es möglich sein, dass der<br />
Sourcecode und die Dokumentation des Sourcecodes nicht ausgeliefert werden kann.<br />
Es ist dann anzugeben, ob der Sourcecode evtl. bei einem Notar hinterlegt werden<br />
muss und wie mit den zu Entwickelnden Erweiterungen umgegangen werden soll.<br />
• Es soll weiterhin ein Wartungsvertrag abgeschlossen werden, indem die<br />
Instandhaltung der Software, wie auch die Reaktionen bei gefundenen Fehlern<br />
festgelegt werden<br />
1.4. Weitere Referenzen<br />
Um weitere Informationen zur Studienregistrierung zu erhalten, sind folgende Referenzen<br />
hilfreich:<br />
• Auszug aus dem Förderantrag (siehe<br />
• Anhang 2: Beschreibung des Deutschen Registers Klinischer Studien (Auszug aus<br />
dem Förderantrag)<br />
• Website der WHO-ICTRP Workgroup (http://www.who.int/ictrp/)<br />
• http://www.clinicaltrials.gov/<br />
• Das Deutsche Register für Somatische Gentherapie (www.dereg.de)<br />
1.5. Ablauf der Registrierung<br />
Derzeit ist der Ablauf der Registrierung noch nicht abschließend festgeschrieben. Es gibt<br />
verschiedene Modelle, die mit der Registersoftware realisierbar sein müssen.<br />
1.) Daten werden direkt über die Registersoftware in die Datenbank eingegeben. Dabei<br />
soll es auch möglich sein, die Daten einer Studie über ein korrekt formatiertes XML-<br />
File einzuspielen. Dies soll eine Anbindung an ein im Aufbau befindliches Portal<br />
einiger Ethikkommissionen ermöglichen.<br />
2.) Daten werden aus anderen Registern (beispielsweise Krankheitsspezifischen- oder<br />
Sponsor-Registern) importiert.<br />
3.) Daten werden direkt von elektronischen Anträgen der Ethik-Kommissionen in das<br />
Register importiert.<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 6/39
Die Punkte 2. und 3. sind nicht alleine von der Registersoftware zu erfüllen und sind auf<br />
Anpassungen der Datenlieferanten angewiesen. Dennoch sollte die Möglichkeit einer<br />
einfachen Import-Schnittstelle geschaffen werden (siehe XI). Diese Schnittstelle kann dann<br />
von Registern oder anderen Organisationen, wie z.B. Ethikkommissionen, genutzt werden.<br />
1.6. Verbindung zum ICTRP-Portal der WHO<br />
Das Deutsche Register Klinischer Studien strebt eine enge Verbindung zum ICTRP-Portal der<br />
WHO an (siehe http://www.who.int/ictrp).<br />
Dazu wird es notwendig sein einen Datenaustausch mit dem Portal zu implementieren. Da<br />
zum jetzigen Zeitpunkt eine genaue Spezifikation der Schnittstelle zu diesem Portal noch<br />
nicht erfolgt ist, muss dieser Punkt zu einem späteren Zeitpunkt konkretisiert werden.<br />
Sicher scheint im Moment jedoch folgendes:<br />
• Die WHO will eine UTRN (Universal Trial Registration Number) vergeben, mit der<br />
Studien identifiziert werden können. Diese muss importiert werden können.<br />
• Die WHO will eine Studie in eine eigene Datenbank importieren. Dazu muss ein<br />
entsprechender automatischer Export aus der Registersoftware implementiert werden.<br />
Die zu liefernden Daten sind in Anhang 1 definiert.<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 7/39
2. Einsatz<br />
2.1. Zielgruppen<br />
Es können drei verschiedene Zielgruppen identifiziert werden, die die Software benutzen<br />
werden:<br />
1.) Sponsoren: Sie bearbeiten Studien, die veröffentlicht werden sollen.<br />
2.) Register-Mitarbeiter: Sie führen Qualitätssicherung, Administration und<br />
Veröffentlichungen am Register durch.<br />
3.) Öffentlichkeit: Jeder kann über die Homepage auf die freigegebenen Inhalte des Registers<br />
zugreifen und Recherchen durchführen.<br />
2.2. Betriebsbedingungen<br />
Die Registersoftware soll möglichst unterbrechungsfrei verfügbar sein. Dazu ist sie auf einem<br />
geeigneten Webserver zu installieren. Die Ausfallsicherheit des Servers muss vom<br />
Hostprovider sichergestellt werden. Die Software soll auf einfache Weise aktualisierbar und<br />
erweiterbar sein.<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 8/39
3. Umgebung<br />
3.1. Software<br />
3.1.1. Server<br />
Die zu entwickelnde Software darf serverseitig Linux oder Windows als Betriebssystem<br />
voraussetzen.<br />
3.1.2. Client<br />
Auf Seite der Clients muss die Software Betriebssystem-unabhängig sein. Es muss der Zugriff<br />
mit Windows, Linux und MacOS Clients über das Internet möglich sein. Dies bedingt, dass<br />
die Nutzung verschiedener Webbrowser möglich sein muss. Hierbei sind mindestens MS-<br />
Internet Explorer (V5.0++), Mozilla Firefox (1.0++), Opera (7++) und Safari zu unterstützen.<br />
Eine Nutzung des Registers muss auch ohne Java-Script oder Plugins wie z.B. Flash möglich<br />
sein. Bei abgeschaltetem Java-Script und bei alten Browser-Versionen muss die Anwendung<br />
weiter mit vollem Funktionsumfang nutzbar sein, darf aber Schwächen im Layout, der<br />
Darstellung und der Handhabung zeigen.<br />
Die Funktionen des Datenmanagements und der Sponsoren können aktuellere Versionen der<br />
Browser voraussetzen, müssen aber auch Betriebsystem-unabhängig sein. Hier können<br />
aktuelle Versionen von Firefox (2.x) und Internet-Explorer (7.x) vorausgesetzt werden.<br />
Es soll keine Clientsoftware existieren. Die Software soll sich komplett per Webbrowser<br />
bedienen lassen.<br />
3.2. Hardware<br />
Als eingesetzte Hardware soll ein Standard-Server verwendet werden (beispielsweise<br />
vergleichbar mit Siemens Primergy RX300 S2, 2GB RAM).<br />
Die Anforderung an die Client-Hardware für die externen Nutzer des Systems muss sehr<br />
niedrig sein. Auch ein altes PC-System (z.B. 1 GHz x86-Prozessor) muss per Webbrowser<br />
das Register abfragen können.<br />
Für die Funktionen des Datenmanagements und der Registermitarbeiter können aktuelle<br />
Desktopsysteme vorausgesetzt werden (vergleichbar mit aktuellen 2GHz x86 Prozessor).<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 9/39
4. Funktionalität<br />
4.1. Use-Cases:<br />
Nachfolgend sind beispielhaft einige wichtige Use-Cases aufgeführt und grafisch dargestellt.<br />
Sie sollen die Arbeit mit der Registersoftware veranschaulichen und müssen implementiert<br />
werden.<br />
1.) Sponsor beantragt Account<br />
2.) Sponsor legt Studie an / bearbeitet Studie<br />
3.) Datenmanagement veröffentlicht Studie<br />
4.) Ein Besucher der Webseite sucht nach Studien<br />
4.1.1. Sponsor beantragt Account<br />
Einem neuen Sponsor soll es möglichst einfach gemacht werden, einen Account anzulegen,<br />
unter dem er eine Studie registrieren kann. Dies ist besonders wichtig, da so eine<br />
Abschreckung der Sponsoren zu Beginn der Registrierungsprozedur vermieden werden soll.<br />
Die Erstellung eines Accounts soll automatisiert, ohne Mitwirken des Register-Personals<br />
erfolgen. Nach der Eingabe der Emailadresse (als Sponsorname) und eines Passworts soll<br />
noch, um Missbrauch vorzubeugen, ein auf der Seite angegebener Textcode eingegeben<br />
werden. Durch diesen Code, der auf der Seite als Bild dargestellt wird, soll verhindert werden,<br />
dass programmgesteuert große Mengen an Accounts angelegt werden können, die die<br />
Stabilität des Systems gefährden.<br />
Nach diesen Eingaben soll eine Bestätigungsmail an die eingegebene Emailadresse versendet<br />
werden, die einen Bestätigungs-Link enthält. Erst nach dem Aufrufen dieses Links ist der<br />
angelegte Account freigeschaltet und kann benutzt werden. Nach erfolgter Freischaltung soll<br />
das Datenmanagement des Registers über den neu angelegten Account per Email informiert<br />
werden und kann die Authentifizierung des Sponsors anstoßen.<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 10/39
Sponsor beantragt Account<br />
Sponsor beantragt<br />
Account zur<br />
Studieneingabe<br />
über Webseite<br />
Sponsor erhält<br />
Bestätigungs-Email<br />
mit Freischaltungs-<br />
Link<br />
Sponsor schaltet<br />
Account über<br />
angegebenen Link frei<br />
Sponsor kann sich<br />
nun anmelden und<br />
Studien eingeben<br />
Datenmanagement<br />
wird über neuen<br />
Account informiert<br />
Abbildung 1: Sponsor beantragt Account<br />
4.1.2. Sponsor legt Studie an / bearbeitet Studie<br />
Nachdem sich ein Sponsor angemeldet hat kann er aus der Liste seiner Studien eine Studie<br />
auswählen und bearbeiten, oder er erstellt eine neue Studie. In eine neue Studie kann er bei<br />
Bedarf Daten im CDISC-Format aus einer Datei einfügen. Hat der Sponsor die Studie<br />
bearbeitet, fragt er um Veröffentlichung beim Datenmanagement nach. Danach kann er eine<br />
andere Studie bearbeiteten oder sich abmelden.<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 11/39
Sponsor legt Studie an / bearbeitet Studie<br />
Sponsor<br />
beantragt<br />
Account<br />
Sponsor beantragt<br />
Veröffentlichung<br />
Datenmanagement<br />
prüft<br />
Veröffentlichung<br />
Nein<br />
Sponsor will eine<br />
Studie eingeben<br />
oder bearbeiten<br />
Sponsor hat schon<br />
einen Account<br />
Ja<br />
Sponsor meldet<br />
sich an<br />
Sponsor sieht seine<br />
Studien und anstehende<br />
Queries<br />
Sponsor wählt zu<br />
bearbeitende<br />
Studie oder legt<br />
neue Studie an<br />
Sponsor<br />
bearbeitet Studie<br />
Eingabe ist beendet,<br />
und die Studie soll<br />
veröffentlicht werden<br />
Anfrage nach<br />
Veröffentlichung wird ans<br />
Datenmanagement des<br />
Registers geschickt<br />
Sponsor meldet<br />
sich ab<br />
Sponsor kann Studiendaten im<br />
CDISC-Format in eine neue Studie<br />
importieren<br />
Änderungen der Studiendaten<br />
werden im Audittrail festgehalten und<br />
bei Änderungen Versionsnummer der<br />
Studie erhöht<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 12/39
Abbildung 2: Sponsor legt Studie an / bearbeitet Studie<br />
4.1.3. Datenmanagement im DRKS<br />
Das Datenmanagement im Register besteht aus vielen Aufgaben. Die wichtigsten davon sind<br />
im Folgenden kurz beschrieben.<br />
Datenmanagement im DRKS<br />
DM erstellt Query<br />
zur Bearbeitung<br />
durch den<br />
Studienleiter<br />
Nach definierter<br />
Zeit wird vom<br />
Studienleiter eine<br />
Aktualisierung der<br />
Studie gefordert<br />
DM bearbeitet zur<br />
Veröffentlichung<br />
anstehende Studie<br />
DM prüft Studie mittels<br />
automatisierter<br />
Plausibilitätschecks<br />
DM prüft Studie mittels<br />
manueller<br />
Plausibilitätschecks<br />
DM veröffentlicht<br />
Studie<br />
Studie ist in der<br />
aktuellen Version über<br />
öffentliche<br />
Internetseite<br />
einsehbar<br />
Datenmanager<br />
(DM) meldet sich<br />
an<br />
DM sieht eine Übersicht:<br />
zur Veröffentlichung anstehende Studien,<br />
zu aktualisierende Studien...<br />
DM archiviert Studie<br />
(Studie wird auch<br />
veröffentlicht)<br />
Studie ist in der<br />
aktuellen Version über<br />
öffentliche<br />
Internetseite<br />
einsehbar<br />
Abbildung 3: Datenmanagement im DRKS<br />
DM prüft bei welchen<br />
Studien die Aktualisierung<br />
aussteht<br />
DM schickt Einzelnen oder<br />
Gruppen von<br />
Studienleitern<br />
automatisiert eine<br />
Erinnerungs-Email<br />
DM aktualisiert die<br />
Öffentliche<br />
Homepage<br />
4.1.4. Ein Besucher der Webseite sucht nach Studien<br />
DM prüft<br />
Diagramme und<br />
Statistiken um<br />
Aussagen zum<br />
Verlauf der<br />
Registrierung<br />
insgesamt treffen<br />
zu können<br />
Ein sehr wichtiger Bereich der Registersoftware ist die Recherche in den Studien innerhalb<br />
der öffentlichen Webseite. Hier sollen sowohl Laien, wie auch medizinisch bewanderte<br />
Personen einfach und effektiv nach relevanten Studien suchen können.<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 13/39
Besucher nutzt die öffentliche Webseite<br />
Besucher kann<br />
jederzeit zwischen<br />
Deutscher und<br />
Englischer Sprache<br />
wählen<br />
Besucher kann über<br />
einfache Stichworte nach<br />
Studien suchen<br />
Besucher sieht<br />
ausgewählte Variablen der<br />
Studien in der<br />
Ergebnisliste seiner Suche<br />
Besucher wählt Studie aus<br />
Besucher sieht alle<br />
Informationen zur Studie<br />
Besucher kann Studie<br />
drucken, exportieren<br />
(XML) oder als PDF-Datei<br />
speichern.<br />
Besucher öffnet Webseite<br />
des Registers<br />
Besucher sieht allgemeine<br />
und aktuelle Informationen<br />
zum Register<br />
Besucher kann über<br />
komplexe Suchmaske<br />
nach Studien suchen<br />
Abbildung 4: Benutzer nutzt die öffentliche Webseite<br />
Besucher kann<br />
Ergebnisliste weiter<br />
einschränken<br />
Besucher kann über eine<br />
bekannte Studien-ID direkt<br />
auf eine Studie zugreifen<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 14/39
5. Requirements<br />
I. Allgemeines<br />
1.Die gesamte Kommunikation zwischen Auftraggeber und Auftragnehmer muss in<br />
deutscher Sprache erfolgen.<br />
2.Die Applikation muss eine Webanwendung sein<br />
3.Zugriff auf den öffentlichen Teil des Registers (siehe 1.1 Punkt 3.) erfolgt für alle<br />
Benutzer unverschlüsselt<br />
4.Personalisierter Zugriff auf das Register nur über Verschlüsselung (https)<br />
5.Der Sourcecode der Anwendung soll für die Auftraggeber zur Verfügung gestellt<br />
werden (siehe Lieferungen an den Auftraggeber).<br />
a.Dabei sind dem Auftraggeber die Rechte zur uneingeschränkten Nutzung,<br />
Weitergabe und Änderung am Sourcecode zu gewähren.<br />
6.Die Anwendung muss in einigen Bereichen durch das Personal des Auftraggebers<br />
selbst erweiterbar sein:<br />
a.Plausibilitätschecks (siehe X) müssen anpassbar und erweiterbar sein<br />
b.Statistiken (siehe j) müssen anpassbar und erweiterbar sein<br />
c.Charts und Grafiken (siehe 6) müssen anpassbar und erweiterbar sein<br />
7.Layout und Design der Webseiten muss per CSS (Cascading Style Sheet) anpassbar<br />
und änderbar sein<br />
8.Als Datenbank soll wenn möglich eine Datenbank verwendet werden (z.B.<br />
PostgreSQL), für die keine Lizenzkosten anfallen<br />
9.Die Anwendung kann logisch in zwei Teile geteilt werden:<br />
a.Dateneingabe/Datenimport, Qualitätssicherung, Administration,<br />
Veröffentlichung<br />
b.Ausgabe der Daten auf öffentlich zugänglicher Webseite<br />
10.Beide Teile der Anwendung (siehe 9) können, wenn es sinnvoll erscheint in<br />
unterschiedlichen Systemen implementiert sein. Die Schnittstelle (evtl. die Datenbank)<br />
muss aber in jedem Fall spezifiziert sein.<br />
11.Für beide Teile der Anwendung (siehe 9) kommt sowohl eine Neuentwicklung, als<br />
auch eine Erweiterung einer bestehenden Anwendung prinzipiell in Frage.<br />
12.Für a ist ein Account mit Passwort erforderlich.<br />
13.Es gibt 2 verschiedene Arten von Accounts für die Applikation in a<br />
a.Account für Sponsor (meist Studienverantwortliche)<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 15/39
.Account für Mitarbeiter des Deutschen Registers Klinischer Studien<br />
14.Mehrsprachigkeit<br />
Die Anwendung muss mehrsprachig sein, und mindestens für die Bereiche der<br />
Dateneingabe durch den Sponsor und der öffentlichen Seite Deutsche und Englische<br />
Sprache unterstützen. Somit müssen manche Parameter (Freitext-Parameter) in<br />
mehreren Sprachen eingegeben werden. Bei Kodierten Parametern kann die<br />
Übersetzung in verschiedene Sprachen zentral erfolgen. Weitere Sprachen sollen mit<br />
geringem Aufwand hinzugefügt werden können (z.B. durch Template-Mechanismen).<br />
II. Studienstatus<br />
Eine Studie kann sich in verschiedenen Status befinden. Abbildung 5: Studienstatus<br />
veranschaulicht die Übergänge zwischen den einzelnen Status.<br />
1.In Bearbeitung: In diesem Status kann die Studie von dem Sponsor (und DM)<br />
bearbeitet und verändert werden. Eine neu angelegte Studie befindet sich automatisch<br />
in diesem Status. Ebenso wird eine veröffentlichte Studie in diesen Status versetzt,<br />
wenn sie aktualisiert werden soll. Wurde für eine Studie die Veröffentlichung<br />
beantragt und gibt es eine Rückfrage von DM, so wird auch diese Studie wieder in den<br />
Status „in Bearbeitung“ versetzt.<br />
Die Studie verlässt diesen Status, indem der Sponsor die Veröffentlichung beantragt<br />
oder die Studie löscht. Dabei ist zu beachten, dass nur bisher unveröffentlichte Studien<br />
vom Sponsor gelöscht werden können.<br />
Auch das Datenmanagement kann für Studien in diesem Status die Veröffentlichung<br />
beantragen.<br />
2.Veröffentlichung beantragt: Eine Studie kommt in diesen Status, wenn der Sponsor<br />
die Veröffentlichung beantragt. Dies kann nach dem initialen Anlegen der Studie oder<br />
nach einer erfolgten Aktualisierung erfolgen. Nur DM kann Studien in diesem Status<br />
verändern. DM kann entweder die Veröffentlichung durchführen, oder eine Rückfrage<br />
an den Sponsor stellen. Falls die Dateneingabe für diese Studie abgeschlossen ist,<br />
kann DM die Studie archivieren. In diesem Fall wird sie auch erneut veröffentlicht,<br />
allerdings fallen für archivierte Studien keine Aktualisierungen mehr an.<br />
3.Veröffentlicht: Eine Studie die durch DM veröffentlicht wird, erhält diesen Status.<br />
Im Zuge der regelmäßig anstehenden Aktualisierungen (siehe 8) wird die Studie<br />
wieder in den Status „in Bearbeitung“ versetzt und der entsprechende Sponsor<br />
kontaktiert. Die öffentlich zugängliche Version der Studie soll dabei nicht verändert<br />
werden.<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 16/39
4.Archiviert: Ist die Bearbeitung einer Studie abgeschlossen, und sind keine weiteren<br />
Eingaben und Aktualisierungen mehr nötig, so wird die Studie in diesen Status<br />
versetzt. Sie ist veröffentlicht wie in 3, es werden aber keine Aktualisierungen mehr<br />
automatisch angefordert.<br />
5.Gelöscht: Eine Studie kann vor der Veröffentlichung vom Sponsor gelöscht werden.<br />
Ist sie einmal veröffentlicht, kann dies nur in bestimmten schwerwiegenden Fällen<br />
(z.B. Duplikat, Betrug...) durch das DM rückgängig gemacht werden. Studien sollen<br />
nicht wirklich gelöscht werden, sondern nur als gelöscht markiert werden und in der<br />
Datenbank verbleiben.<br />
von Sponsor<br />
oder DM gelöscht<br />
Abbildung 5: Studienstatus<br />
Veröffentlichung und<br />
Archivierung durch DM<br />
III. Dateneingabe/Datenimport durch den Sponsor (meist Studienverantwortlichen)<br />
1.Dateneingabe ist nur für angemeldete Sponsoren möglich<br />
Um Daten in die Datenbank eingeben zu können, muss sich ein Sponsor anmelden.<br />
Dazu muss er mindestens seine Emailadresse (als Accountname), seinen Namen und<br />
Kontaktdaten wie Adresse und Telefonnummer hinterlegen.<br />
2.Der Zugang zu einem Bereich der Applikation, der eine Anmeldung erfordert<br />
(Bereich 1, siehe 9) darf nur verschlüsselt erfolgen (siehe 4)<br />
3.Schnelle und unkomplizierte Account-Erstellung:<br />
Es muss für den Sponsor möglich sein, schnell und unkompliziert einen Account zur<br />
Eingabe einer Studie anzulegen. Dazu sollten etablierte Verfahren genutzt werden, die<br />
ein Mindestmass an Sicherheit bieten, wie beispielsweise:<br />
a.Eingabe von Emailadresse und Passwort durch den Sponsor.<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 17/39
.Darauf erhält dieser eine Bestätigungsmail mit einem Link,<br />
c.durch den er seinen Account freischalten kann.<br />
d.Es wird dann eine Informations-Email über den angelegten Account an das<br />
DM versandt.<br />
4.Gute Übersicht über eigene Studien<br />
Der Sponsor muss, nachdem er sich zur Dateneingabe angemeldet hat, eine Übersicht<br />
seiner Studien erhalten. Dazu soll er sehen, welche Studien in welchem Status (siehe<br />
II) sind.<br />
5.Neue Studien anlegen<br />
Der Sponsor muss die Möglichkeit haben neue Studien anzulegen, die registriert<br />
werden sollen.<br />
a.Der Sponsor soll die Möglichkeit haben, bestimmte Parameter aus bereits<br />
eingegebenen Studien zu kopieren, um gleiche Parameter nicht immer wieder<br />
eingeben zu müssen. Dieses Verfahren ist für Adressen und Kontaktdaten wie<br />
z.B. Sponsors, und Contacts (siehe 9 Punkt 5-8) wichtig.<br />
6.Bereits eingegebene Studien editieren.<br />
Der Sponsor muss die Möglichkeit haben bereits eingegebene Studien zu editieren.<br />
7.Import aus CDISC-XML-File<br />
Der Sponsor muss die Möglichkeit haben Daten aus einem CDISC-XML-File (siehe<br />
c) in eine neue Studie zu importieren.<br />
8.Studien zur Veröffentlichung/Aktualisierung an QS weiterleiten.<br />
Hat ein Sponsor die Eingabe oder Aktualisierung seiner Studie beendet, so soll er<br />
diese möglichst einfach (1-2 Klicks) an DM zur Prüfung weiterleiten können. Dies<br />
soll einen Statuswechsel der Studie bewirken (siehe II). Ein Sponsor kann eine Studie<br />
nicht ohne Freigabe durch DM direkt veröffentlichen.<br />
9.Die Eingabe der Studien soll über eine webbasierte Eingabemaske (siehe VIII) oder<br />
Daten-Import (siehe 1.5, 7, XI) erfolgen<br />
10.Ein Sponsor darf nur Zugriff auf seine eigenen Studien haben.<br />
11.Automatisches Logout nach 30 Minuten Untätigkeit.<br />
Nach max. 30 min. ohne Eingabe soll der Sponsor abgemeldet werden. Bis dahin nicht<br />
gespeicherte Eingaben sollen nicht verloren sein. Sie sollen entweder Serverseitig<br />
gespeichert werden, oder per Email an den Sponsor und das Datenmanagement<br />
geschickt werden.<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 18/39
12.Audittrail für eigene Studien soll einsehbar sein (siehe 7).<br />
Der Sponsor kann den Audittrail für seine eigenen Studien einsehen und durchsuchen.<br />
13.Versionierung der Studien<br />
Jede Änderung in einer Studie soll die Versionsnummer einer Studie ändern. Dabei<br />
können mehrere gleichzeitige Änderungen an Parametern zusammengenommen<br />
werden und in nur einen Versionswechsel resultieren (Transaktionsorientiert). Nicht<br />
jede alte Version einer Studie muss gespeichert werden, da sie sich aus dem Audittrail<br />
rekonstruieren lassen, aber jede veröffentlichte Version einer Studie soll versioniert<br />
gespeichert werden.<br />
14. Rechteweitergabe für andere Benutzer<br />
Der Sponsor soll die Möglichkeit haben einem anderen Benutzer das Recht zu geben<br />
eine seiner Studien zu bearbeiten<br />
a. Dabei gibt der Sponsor die Studie und den Benutzer an, der von nun an für<br />
die Studie verantwortlich sein soll<br />
b. Es muss sichergestellt sein, dass der andere Benutzer im System bekannt ist<br />
c. Der Sponsor, der neue Benutzer und das Datenmanagement werden per<br />
Email über die Aktion informiert<br />
d. Ab jetzt ist der neue Benutzer für die Studie verantwortlich<br />
IV. Qualitätssicherung im Register (durch das Datenmanagement (DM))<br />
1.Mitarbeiter des Deutschen Registers Klinischer Studien (DRKS) können<br />
Qualitätssicherung (QS) in der Registeranwendung betreiben.<br />
2.Jeder Mitarbeiter muss einen eigenen Account mit Passwort erhalten um sich an der<br />
Applikation anzumelden.<br />
Dieser Account wird vom Administrator angelegt (siehe 1)<br />
3.Mitarbeiter erhalten im Vergleich zu Sponsoren (siehe III) weitere Möglichkeiten:<br />
a.Mitarbeiter sehen alle eingegebenen Studien<br />
b.Mitarbeiter können alle eingegebenen Studien bearbeiten<br />
c.Mitarbeiter können den kompletten Audittrail (siehe 7) einsehen und<br />
durchsuchen<br />
d.Mitarbeiter können den Status einer Studie (siehe II) ändern<br />
e.Mitarbeiter können Queries erstellen (siehe V)<br />
f.Mitarbeiter können Studien authentifizieren<br />
Ein Mitarbeiter stellt sicher (telefonisch oder über andere Wege), dass die<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 19/39
angegebene Studie wirklich existiert und vom angegebenen Sponsor initiiert<br />
wurde<br />
a)Der Mitarbeiter kann einer Studie das Attribut authentifiziert<br />
zuordnen.<br />
g.Mitarbeiter können Sponsoren authentifizieren<br />
Ein Mitarbeiter stellt sicher (telefonisch oder über andere Wege), dass der<br />
Sponsor wirklich existiert.<br />
a)Der Mitarbeiter kann einem Sponsor das Attribut authentifiziert<br />
zuordnen.<br />
h.Mitarbeiter können Studien veröffentlichen:<br />
Die Studie ist dann im öffentlichen Teil der Applikation (b) zu sehen<br />
a)Nur authentifizierte Studien von authentifizierten Sponsoren sollten<br />
veröffentlicht werden. Trifft dies nicht zu, so soll der Datenmanager<br />
vor der Veröffentlichung gewarnt werden.<br />
b)Wird eine Studie veröffentlicht, die nicht vollständig ist, so soll sie<br />
eine deutlich unterscheidbare Studien-ID erhalten: (z.B. DRKS-TMP-<br />
xxxxxx).<br />
c)Nachdem eine Studie veröffentlich wurde soll automatisch eine<br />
Email an den entsprechenden Sponsor versendet werden, in der der<br />
Sponsor über die Veröffentlichung informiert wird. In dieser Email<br />
müssen folgende Informationen enthalten sein:<br />
(1)Datum der Veröffentlichung<br />
(2)Link zur veröffentlichten Studie<br />
(3)Name des Datenmanagers der die Veröffentlichung<br />
durchgeführt hat.<br />
i.Mitarbeiter können Sponsoren Nachrichten (Emails) senden<br />
j.Mitarbeiter können Statistiken (interaktiv und statisch) der eingegebenen<br />
Daten sehen (siehe 6)<br />
k.Mitarbeiter sehen bei welchen Studien eine Veröffentlichung oder eine<br />
Aktualisierung ansteht<br />
l.Schutz vor gleichzeitigem Zugriff (siehe IX)<br />
m.Sie können die Ergebnisse der Plausbilitätschecks (siehe X) sehen<br />
n.Mitarbeiter sehen, bei welchen Studien die Aktualisierung (siehe 8)<br />
ausstehen<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 20/39
o.Mitarbeiter können mehreren Sponsoren automatisiert Erinnerungsemails<br />
schicken<br />
p.Mitarbeiter können Plausibilitätschecks (siehe X) für Einzelne oder Gruppen<br />
von Studien auswerten<br />
4.Daten müssen aus der Anwendung exportiert werden können:<br />
a.Spezielle Exporte sollen vorbereitet sein wie z.B. ein Export, der Adressen<br />
zum Erstellen von Serienbriefen exportiert<br />
b.Es soll die Möglichkeit haben generische Exports (z.B. als SQL-Statement)<br />
zu erstellen.<br />
a)Dabei muss es auch möglich sein alle Daten, Studiendaten wie auch<br />
organisatorische Daten, zu exportieren.<br />
c.Studien müssen im CDISC-XML Format exportiert werden können. Hierzu<br />
ist das von CDISC vorgesehene Schema zur Studienregistrierung zu<br />
verwenden (siehe www.cdisc.org: BRIDG-Modell).<br />
d.Studiendaten müssen sich mit ansprechendem Layout als PDF-Datei<br />
exportieren lassen.<br />
5.Interaktion mit Homepage/Internet Plattform<br />
Mitarbeiter müssen den Inhalt der Homepage bearbeiten können um beispielsweise<br />
News oder aktuelle Berichte zu veröffentlichen.<br />
6.Statistiken und Grafiken<br />
Sie sind ein wichtiges Hilfsmittel um Übersichten und Performance-Daten des<br />
Registers darzustellen.<br />
a.wichtige administrative Statistiken müssen von Beginn an verfügbar sein:<br />
a)Eingegebene Studien/Zeiteinheit (Jahr/Monat/Woche/insgesamt)<br />
b)Veröffentlichte Studien/Zeiteinheit (Jahr/Monat/Woche/insgesamt)<br />
c)Anzahl der Studien die aktualisiert werden müssen<br />
b.wichtige inhaltliche Statistiken sollten verfügbar sein (über die<br />
veröffentlichten Studien) z.B.:<br />
a)Phasen der Studien<br />
b)Beteiligte Länder<br />
c)Verteilung der Indikationen<br />
c.weitere Statistiken und Charts müssen von den Registermitarbeitern nach<br />
entsprechender Einweisung ohne weitere Beauftragung des AN erstellt werden<br />
können.<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 21/39
7.Audittrail<br />
Ein Audittrail erfasst alle Datenänderungen im Register und speichert sie in einer<br />
Datenbank. Es dient dazu nachweisen zu können, wer welche Daten wann geändert<br />
hat.<br />
a.Ein Audittrail muss alle Daten- und Zustandsänderungen im Register<br />
erfassen<br />
a)Datenänderungen: z.B. das Ändern einer Adresse<br />
b)Statusänderung (siehe II): z.B. das Veröffentlichen einer Studie<br />
b.Der Audittrail muss erfassen:<br />
a)wer die Daten geändert hat<br />
b)wann die Daten geändert wurden<br />
c)welche Daten genau geändert wurden<br />
d)welches der alte Wert der Daten war<br />
e)welches der neue Wert der Daten ist<br />
f)bei Zustandsänderungen muss der alte und der neue Zustand erfasst<br />
werden<br />
c.Der Audittrail ist nur für das Datenmanagement vollständig einsehbar<br />
d.Sponsoren können nur den Audittrail ihrer Studien sehen<br />
e.Im Audittrail muss gezielt gesucht werden können (evtl. durch Filter<br />
Mechanismen implementierbar):<br />
a)nach allen Änderungen an einer Studie<br />
b)nach allen Änderungen in einem Zeitintervall (pro Studie und bei<br />
allen Studien/Studienteilmenge)<br />
c)nach allen Änderungen durch eine Person (pro Studie und bei allen<br />
Studien/Studienteilmenge)<br />
d)nach einem alten/neuen Wert (pro Studie und bei allen<br />
Studie/Studienteilmenge)<br />
e)nach einem alten/neuen Zustand (pro Studie und bei allen<br />
Studien/Studienteilmenge)<br />
8.Aktualisierung von Studien<br />
f)nach Kombinationen der oberen Bedingungen (pro Studie und bei<br />
allen Studien/Studienteilmenge)<br />
Studien müssen nach einer wählbaren Zeit (Anzahl von Tagen) aktualisiert werden<br />
(siehe a). Dies soll von der Register-Software unterstützt werden.<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 22/39
a.Eine Studie, die in der entsprechenden Zeit nicht mehr aktualisiert wurde,<br />
soll automatisch dem Sponsor zur Aktualisierung vorgelegt werden<br />
9.Kommentar-Log<br />
a)der Sponsor wird per Email benachrichtigt<br />
b)die Studie wird in den Zustand „in Bearbeitung“ versetzt (siehe 1)<br />
c)das Datenmanagement wird per Email benachrichtigt<br />
Die Kommentarfunktion ist dazu gedacht, Mitarbeitern die Möglichkeit zu geben<br />
Informationen zu einer Studie, z.B. telefonische Absprachen, festzuhalten.<br />
a.Mitarbeiter sollen zu jeder Studie Kommentare anzeigen und verfassen<br />
können.<br />
b.Diese Kommentare sollen den Namen der Verfassers, das Erstellungsdatum<br />
und den Kommentar enthalten<br />
c.Kommentare müssen durchsuchbar sein<br />
d.Kommentare sind nur für Mitarbeiter zu lesen. Sponsoren haben keinen<br />
Zugriff darauf<br />
V. Query-Management<br />
Unter Query-Management versteht man ein Verfahren, dass es dem Datenmanagement<br />
ermöglicht Rückfragen an Sponsoren zu stellen und Sponsoren auf solche Anfragen zu<br />
antworten.<br />
1.Ein Mitarbeiter soll zu einer Studie ein Query erstellen können.<br />
a.Der Sponsor dieser Studie sieht, dass ein Query zu bearbeiten ist, nachdem er<br />
sich angemeldet hat<br />
b.zusätzlich wird dem Sponsor der Studie das Query per Email zugeschickt<br />
c.Der Mitarbeiter soll Betreff und Text des Queries selber wählen können.<br />
2.Jedes Query erhält vom System eine eindeutige Nummer, mit der es fortan<br />
referenziert werden kann.<br />
3.Query-Lifecycle<br />
a.Ein Query wird erstellt<br />
b.Das Query wird dem Sponsor zugestellt (per Email und in der<br />
Registersoftware)<br />
c.Der Sponsor beantwortet das Query<br />
d.Das Query wird samt Antwort dem Datenmanagement zugestellt.<br />
e.Falls das Query gelöst ist wird es abgeschlossen und archiviert<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 23/39
f.Falls es nicht gelöst ist, wird es an den Sponsor zurück geschickt (weiter bei<br />
b)<br />
4.Wird ein Query beantwortet, so wird die Antwort zusammen mit dem Datum in<br />
Namen des Benutzers an das Query angehängt. So für alle Beteiligte immer der<br />
gesamte Ablauf des Queries sichtbar sein.<br />
5.Sponsoren dürfen nur die Queries sehen, die zu ihren Studien gehören.<br />
a.Sponsoren sehen nach dem Anmelden an das System alle durch sie zu<br />
bearbeitenden Queries<br />
b.Sponsoren können alle Queries (offene und archivierte) zu jeder ihrer<br />
Studien anzeigen lassen.<br />
6.Mitarbeiter können alle Queries sehen.<br />
a.Mitarbeiter müssen zu jeder Studie die aktuell offenen Queries sehen können<br />
(möglichst direkt auf der Übersichtsseite zu einer Studie).<br />
b.Mitarbeiter müssen sich zu jeder Studie alle (auch archivierte) Queries<br />
anzeigen lassen können<br />
c.Mitarbeiter müssen in allen Queries aller Studien suchen können.<br />
VI. Recherche im Register über Internet Plattform<br />
1.Freier Zugang für Alle (kein Login nötig)<br />
2.Alle Seiten müssen in Englischer und Deutscher Sprache verfügbar sein.<br />
3.barrierefreier Internetauftritt (wichtig, da potentielle Patienten auch Zielpublikum<br />
sind, siehe http://de.wikipedia.org/wiki/Barrierefreies_Internet )<br />
4.geringe Browseranforderungen<br />
Die Seiten sollen auch mit alten Browsern (auch ohne Java-Script) lesbar und<br />
benutzbar sein. Allgemeiner und leichter Zugang ist wichtiger als Optik und Features.<br />
Siehe auch 3.1.2.<br />
5.Die Webseiten sollen von Suchmaschinen (Google, Yahoo, ...) durchsuchbar und<br />
indizierbar sein.<br />
6.Einfache URLs für einzelne Studien<br />
a.Jede Studie soll über eine Einfache URL (z.B.<br />
http://drks.de/studie/) erreichbar sein<br />
b.Es soll möglich sein, die Studien auch über externe IDs mit einfachen URLs<br />
zu erreichen (z.B. http://drks.de/studie/ und<br />
http://drks.de/trial/)<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 24/39
7.Suchmasken sollen es möglich machen nach bestimmten Studien zu suchen<br />
a.Eine einfach Suche, bei der durch Eingabe eines Suchbegriffes (Google-<br />
Style) alle passenden Studien gefunden werden<br />
b.Eine komplexere Suche, bei der nach Ausprägungen bestimmter Parameter<br />
gesucht werden kann<br />
c.Die Suche sollte Reguläre Ausdrücke auflösen können<br />
d.Es soll bei kodierten Parametern (z.B. Indikation, kodiert nach ICD10)<br />
möglich sein, im Kodierungsbaum zu „browsen“: Der gesamte Kodierungs-<br />
Baum soll durchsucht und die zu den Kodierungen passenden Studien<br />
angezeigt werden können. Mögliche Kodierungen die hierzu benutzt werden<br />
könnten wären<br />
a)ICD10 (http://www.dimdi.de/static/de/klassi/diagnosen/icd10/ls-<br />
icdhtml.htm)<br />
8.Druckfunktionalität<br />
b)MeSH (http://www.ncbi.nlm.nih.gov/sites/entrez?db=mesh)<br />
c)MedDRA.(http://www.meddramsso.com/MSSOWeb/index.htm),<br />
wobei hier aufgrund der Lizenz-Problematik eine genaue Abstimmung<br />
zwischen Auftragnehmer und Auftraggeber notwendig ist.<br />
a.Es muss möglich sein, einzelne Studien und Suchergebnisse mit<br />
ansprechendem Design (nahe dem Bildschirm-Design) auszudrucken. (z.B.<br />
durch ein spezielles Stylesheet)<br />
9.Export in PDF<br />
VII. Administration<br />
a.Einzelne Studien sollen als PDF-Datei heruntergeladen werden können. Das<br />
Layout soll dem der Webseite ähnlich sein.<br />
1.Das Administrationsinterface steht nur bestimmten Registermitarbeitern zur<br />
Verfügung.<br />
2.Ein Administrator kann Mitarbeiter-Accounts einrichten.<br />
3.Ein Administrator kann Mitarbeitern Administrationsrechte geben<br />
4.Ein Administrator kann Accounts von Mitarbeitern und Sponsoren deaktivieren<br />
5.Ein Administrator kann Emailadressen und Kontaktdaten aller Mitarbeiter und<br />
Sponsoren einsehen und ändern.<br />
6.Ein Administrator kann Passwörter von Sponsoren und Mitarbeitern zurücksetzen<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 25/39
a.Dabei soll ein zufälliges Passwort generiert werden, dass an den<br />
entsprechenden Mitarbeiter oder Sponsor per Email versandt wird.<br />
7.Ein Administrator kann globale Parameter einstellen wie beispielsweise:<br />
a.Zeit nach der eine Studie aktualisiert werden soll und eine Erinnerung an die<br />
Sponsoren verschickt wird<br />
b.Mailserver Konfiguration<br />
c.Konfiguration der Suchindizierung, anstoßen einer Neuindizierung<br />
d.Bearbeiten der Email-Vorlagen, die das System automatisch verschickt<br />
e.Passwortregeln<br />
a) Nach welcher Zeit müssen Passwörter geändert werden<br />
b) Wie muss ein Passwort aussehen (z.B. min. 8 Zeichen, davon eine<br />
Zahl und ein Sonderzeichen)<br />
8.Ein Administrator kann die Auswahllisten der Eingabeseiten (siehe f)<br />
verändern/erweitern<br />
9.Ein Administrator kann die Übersetzung der Auswahllisten (siehe f)<br />
bearbeiten/verändern.<br />
10.Ein Administrator kann die Zieladressen von Benachrichtigungen (beispielsweise<br />
d) bearbeiten.<br />
11.Ein Administrator kann Import-Benutzer (siehe 2) anlegen, verändern und löschen.<br />
12.Ein Administrator kann manuelle Plausibilitätschecks (siehe 7) anlegen und<br />
bearbeiten<br />
13.Ein Administrator kann die Zuordnung von Studie zu Sponsoren verändern (Siehe<br />
III.14)<br />
14.Ein Administrator muss die Ein- und Ausgabeseiten der Studien anpassen können<br />
a. es muss möglich sein neue Parameter anzulegen, die erfasst werden sollen.<br />
Diese Parameter müssen dann auch auf allen Ausgabeseiten erscheinen<br />
a) Für diese Parameter müssen alle Notwendigen Beschriftungen<br />
mehrsprachig erfasst werden<br />
b)Für diese Parameter muss ein Typ festgelegt werden (Freitext,<br />
Kodiert, Zahl, Datum...)<br />
c)Für kodierte Parameter müssen die Kodierungen in mehreren<br />
Sprachen angegeben werden<br />
b.es muss möglich sein alte Parameter, die nicht mehr erfasst werden sollen, zu<br />
löschen, sodass sie nicht mehr auf den Ein-/Ausgabeseiten erscheinen<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 26/39
c.es soll möglich sein alte Parameter zu deaktivieren, sodass sie noch auf den<br />
Ein-/Ausgabeseiten erscheinen, aber keine Werte mehr für sie eingegeben oder<br />
geändert werden können<br />
d.es muss möglich sein deaktivierte Parameter wieder zu aktivieren.<br />
e.Es muss möglich sein die Reihenfolge der Parameter auf den Ein- und<br />
Ausgabeseiten zu ändern<br />
f.Es muss möglich sein, die Beschriftungen der Parameter auf Ein- und<br />
Ausgabeseiten zu ändern.<br />
VIII. Eingabeseite für Studien<br />
1.Steht nur angemeldeten Sponsoren/Mitarbeitern zur Verfügung.<br />
2.Es müssen alle von der WHO vorgegebenen Parameter eingegeben werden können<br />
(siehe Anhang 1: WHO Registration Data Set (Version 1.0)).<br />
a.Das genaue Format der einzugebenden Daten ist mit dem Auftraggeber noch<br />
abzuklären.<br />
b.Alle Parameter müssen in Englischer und Deutscher Sprache erfasst werden.<br />
c.Es kann Parameter geben die das System ausfüllt, und die nicht durch den<br />
Sponsor geändert werden können (z.B. Parameter 1 und 2)<br />
d.Bestimmte Administrative Parameter (z.B. Datum der Erstellung der Studie)<br />
sollen für den Sponsor unsichtbar erfasst werden.<br />
e.Die in der Liste aufgeführten Parameter werden teilweise noch in weitere<br />
Parameter unterteilt (Beispiel: Contact Information wird als Adresse mit Titel,<br />
Vorname, Name, ... eingegeben)<br />
f.Wo es möglich ist, sollen Auswahllisten statt Freitext die Eingabe und<br />
Recherche erleichtern.<br />
Diese Auswahllisten erleichtern auch die Übersetzung, da sie nur einmal<br />
übersetzt und hinterlegt werden müssen.<br />
3. „Bestätigtes Missing“<br />
a.Für jedes Feld muss es möglich sein es als „Bestätigtes Missing“ zu<br />
kennzeichnen.<br />
b.Nur QS kann ein Feld als bestätigtes Missing markieren.<br />
c.Solche Felder sollen in den Plausibilitätschecks entsprechend behandelt<br />
werden und werden nicht mehr nachgefragt.<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 27/39
4.1:n Beziehungen, wie beispielsweise bei Countries of Recruitment, müssen als<br />
solche eingegeben werden können.<br />
Bei solchen Konstrukten kann es zu einer Studie mehrere (bei diesem Beispiel) Länder<br />
geben, in denen die Studie stattfindet. Es muss möglich sein, beliebig viele<br />
(Obergrenze ist durch Speicherplatz gegeben) dieser Länder einzugeben.<br />
5.Für Mitarbeiter werden zusätzliche Administrative Parameter angezeigt (z.B. Datum<br />
der Veröffentlichung, Erstellungsdatum, Authentisierte Studie...)<br />
a.Welche administrativen Parameter genau benötigt werden, muss der<br />
Auftragnehmer zusammen mit dem Datenmanagement absprechen.<br />
IX. Gleichzeitiges Bearbeiten von Studien und Locking<br />
Es soll ausgeschlossen werden, dass durch gleichzeitiges Bearbeiten von Studien Daten<br />
verloren gehen oder eine Studie inkonsistente Daten enthält.<br />
1.Öffnet ein Sponsor oder Mitarbeiter eine Studie um Daten zu verändern, muss dies<br />
auf dem Server vermerkt werden.<br />
2.Die Studie gilt solange als geöffnet, bis der bearbeitende Sponsor/Mitarbeiter sie<br />
speichert oder die Eingabe abbricht (die Eingabeseiten verlässt).<br />
3.Falls ein Sponsor/Mitarbeiter versucht eine Studie zu bearbeiten, die von einem<br />
anderen Sponsor/Mitarbeiter gesperrt ist, so soll ihm mitgeteilt werden, wer die Studie<br />
bearbeitet und damit sperrt.<br />
a.Ist er selbst der sperrende Sponsor/Mitarbeiter, so siehe 4<br />
b.Stammt die Sperre von einem anderen Mitarbeiter/Sponsor, so soll er die<br />
Möglichkeit haben sich mit diesem in Verbindung zu setzen. Dazu sollen die<br />
verfügbaren Informationen (Name, Email, Telefon...) angezeigt werden.<br />
4.Falls ein Sponsor, beispielsweise durch schließen des Browser-Fensters, die Studie<br />
nicht ordnungsgemäß wieder freigegeben hat, soll ein weiteres Bearbeiten dieser<br />
Studie dennoch möglich sein<br />
a.Erfolgt ein erneuter Versuch des Bearbeitens der Studie erst nach dem Ende<br />
seiner Session (siehe 11), so kann er sich wieder anmelden, sollte aber die<br />
Daten nicht gespeicherten seiner alten Session in irgendeiner Form (z.B. aus an<br />
ihn versandten einer Email) wieder rekonstruieren können.<br />
b.Erfolgt ein erneuter Versuch des Bearbeitens der Studie vor dem<br />
automatischen Ende seiner Session (siehe 11), so soll der Sponsor einen<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 28/39
Hinweis erhalten, dass er laut System die Studie noch bearbeitet. Er soll nun<br />
wählen können:<br />
a)Eingabe fortsetzen und die alten Daten verwerfen<br />
b)Eingage fortsetzen und die alten Daten übernehmen<br />
c)Eingabe jetzt abbrechen und alte Session belassen (z.B. wenn er an<br />
einem anderen Rechner diese Studie im Moment geöffnet hat)<br />
5.Wird eine Studie in den Status „Veröffentlichung beantragt“ (siehe 2) überführt,<br />
dann ist sie für den Sponsor zur Eingabe gesperrt. Nur die Mitarbeiter des<br />
Datenmanagement können nun die Studie bearbeiten.<br />
6.Folgende Probleme müssen bedacht werden<br />
X. Plausibilitätschecks<br />
a)Sicherheit (kann eine Session gekapert werden)<br />
b)Vergesslichkeit (evtl. läuft eine Session noch in einem anderen<br />
Browser-Fenster/einem anderen Rechner des Sponsors)<br />
c)Abstürze (evtl. wurde die Session wirklich abgebrochen)<br />
d)Komfort: Der Sponsor muss mit möglichst wenig Aufwand (auch<br />
nach einem Absturz) schnell weiterarbeiten können und soll möglicht<br />
keine eingegebenen Daten verlieren!<br />
Plausibilitätschecks sind Tests, die auf Studien angewandt werden, um Unstimmigkeiten<br />
und Fehler zu erkennen. Die Plausibilitätschecks werden vom Datenmanagement für die<br />
einzelnen Registerparameter erstellt.<br />
1.Ein Mitarbeiter kann die Ergebnisse aller Plausibilitätschecks für eine Studien<br />
ansehen. Dabei sind vor allem die durch die Tests erkannten Fehler interessant<br />
2.Ein Mitarbeiter kann sich die aggregierten Ergebnisse der Plausibilitsätchecks für<br />
alle Studien ansehen. Hier soll er sehen können wie viele und welche Studien bei<br />
welchem Test Fehler erzeugt haben.<br />
3.Plausibilitätschecks müssen einfach anpassbar sein, da sie im Laufe der Zeit<br />
verbessert und verfeinert werden.<br />
4.Die Ergebnisse von Plausibilitätschecks sollen druckbar sein. Dabei ist darauf zu<br />
achten, dass evtl. viele Daten dargestellt werden müssen, und sie trotzdem noch lesbar<br />
auf Papier gebracht werden sollen<br />
5.Studien sollen markiert werden können, so dass sie in den Fehlerlisten der<br />
Plausibilitätschecks gesondert auftauchen. Damit soll erreicht werden, dass Studien,<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 29/39
ei denen ein Check immer fehlschlägt im Bedarffall aus der Liste gestrichen werden<br />
können, um wiederholte Queries zu vermeiden.<br />
6.Die Ergebnisse der Plausibilitätschecks sollen als CSV-Daten exportiert werden<br />
können, um eine anschließende Weiterverarbeitung in anderen Programmen (z.B.<br />
Excel) zu ermöglichen.<br />
7.Es müssen auch manuelle Plausibilitätschecks vom System unterstützt werden.<br />
a.Dazu soll es möglich sein, eine Liste von manuellen Checks zu pflegen<br />
b.Das Datenmanagement soll jedem Check in jeder Studie einen der Werte<br />
Erfolg, Misserfolg, nicht zutreffend und nicht durchgeführt zuordnen können.<br />
c.Die Ergebnisse der manuellen Plausibilitätschecks sollen in die Übersichten<br />
mit einfließen.<br />
d.Manuelle Plausibilitätschecks die einmal in Studien benutzt wurden dürfen<br />
nicht gelöscht werden, da sonst die Zuordnung zu diesen alten Studien verloren<br />
geht.<br />
8.Plausibilitätschecks können deaktiviert werden, sodass sie bei neuen Studien nicht<br />
mehr benutzt werden.<br />
XI. Datenimport<br />
Zusätzlich zu der Möglichkeit, dass einzelne Sponsoren einzelne Studien importieren,<br />
muss es möglich sein mit geringem Aufwand Daten anderer Register zu importieren.<br />
1.Der Import von Daten anderer Register soll über einen Webservice möglich sein.<br />
2.Der Import soll nur durch authentifizierte Import-Benutzer erfolgen<br />
a.Ein Import-Benutzer wird von einem Administrator verwaltet (siehe 11)<br />
b.Ein Import-Benutzer ist im Normalfall ein Mitarbeiter eines anderen<br />
Registers, der sich technisch um den Import kümmert. Er ist typischerweise<br />
nicht zuständig für die Studiendaten.<br />
c.Ein Import-Benutzer wird durch folgende Daten charakterisiert<br />
a)Email<br />
b)Name<br />
c)Adresse<br />
d)Passwort<br />
e)Organisation der der Import-Benutzer angehört<br />
3.Beim Import von Studien sollte ein ähnliches Format genutzt werden, wie beim<br />
Import aus einem File (siehe 7)<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 30/39
a.Diese Daten müssen aber noch mit Informationen zum Ansprechpartner für<br />
diese Studie angereichert werden<br />
4.Es muss möglich sein, Studien über einen weiteren Import zu aktualisieren, so dass<br />
die manuelle Aktualisierung durch den Sponsor entfallen kann.<br />
5.Import und Aktualisierungen müssen dem Datenmanagement durch eine Email<br />
mitgeteilt werden.<br />
XII. Datenexport<br />
Es soll auch möglich sein, andere Register mit Daten aus dem DRKS zu beliefern. Dazu<br />
soll eine Export-Schnittstelle implementiert werden. Da es zum jetzigen Zeitpunkt noch<br />
keinen definierten Nutzer der Exportschnittstelle gibt, ist sie entsprechend offen zu<br />
gestalten.<br />
1.Der Export soll als Webservice implementiert sein<br />
2.Der Export soll es gestatten einzelne Studien (definiert durch die Studiennummer)<br />
zu exportieren<br />
3.Der Export mehrerer Studien soll möglich sein<br />
a.Dazu soll der Webservice er ermöglichen alle Studien zu exportieren, die<br />
bestimmten Kriterien entsprechen. Diese Kriterien könnten analog zur<br />
Suchmaske der Website (siehe 7) implementiert sein<br />
4.Die Such- und Exportfunktion darf die Stabilität und Geschwindigkeit des Registers<br />
nicht gefährden.<br />
XIII. Qualitätsanforderungen der Softwareentwicklung<br />
1.Vom Auftragnehmer ist ein geeignetes Softwareentwicklungsmodell (z.B. das<br />
VModell XT für Auftragnehmer) anzuwenden<br />
a.Auftraggeber und Auftragnehmer definieren gemeinsam Meilensteine<br />
a)zu bestimmten Meilensteinen sind Prototypen vorzulegen.<br />
b)Zu bestimmten Terminen werden Code Reviews durchgeführt. Dabei<br />
werden sowohl der Applikationscode, wie auch der Code der<br />
Testprozeduren untersucht.<br />
2.Vom Auftragnehmer sind geeignete Versionierungsmechanismen zu benutzen<br />
3.Vom Auftragnehmer wird erwartet ein funktionierendes System zur Sicherstellung<br />
der Qualität in der Softwareentwicklung zu benutzen<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 31/39
4.Der Auftragnehmer hat durch (automatisierte) Tests sicherzustellen, dass die<br />
Software den Anforderungen genügt. Diese Tests sind Teil der Softwareentwicklung<br />
und müssen mit dem Sourcecode ausgeliefert werden.<br />
5.Eine klare Trennung der Schichten (Frontend, Middleware, Business, Database) soll,<br />
z.B. durch den Einsatz von Design-Patterns, gewährleistet sein.<br />
6.Ergonomie im Webdesign ist für gute Benutzbarkeit der Software essentiell. Daher<br />
sollten beim Auftragnehmer entsprechende Kenntnisse nachweisbar sein (z.B. ein/e<br />
ausgebildeter Mediendesigner/in verfügbar sein).<br />
XIV. Wartungsvertrag<br />
Zwischen Auftragnehmer und Auftraggeber soll ein Wartungsvertrag abgeschlossen<br />
werden, der festlegt zu welchen Konditionen und mit welcher Reaktionsgeschwindigkeit<br />
der Auftragnehmer bei Problemen mit der Software reagieren muss.<br />
1.Auftragnehmer und Auftraggeber müssen definieren, was kritische und nicht<br />
kritische Fehler sind.<br />
a.Es muss festgelegt sein, wie der Auftragnehmer auf kritische und nicht<br />
kritische Fehler reagieren muss<br />
2.Die generelle Verfügbarkeit und Erreichbarkeit des Auftragnehmers muss festgelegt<br />
sein.<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 32/39
6. Datenmenge<br />
Die zu erwartenden Datenmengen werden mit ca. 5000 Studien/Jahr geschätzt. Die Software<br />
muss für mindestens 10 Jahre performant arbeiten und somit 50.000 Studien und 50.000<br />
Sponsoren/Benutzer verwalten können.<br />
Testweise sollte ein Versuch mit 100.000 Studien und Benutzern zeigen, dass die Software<br />
auch dann noch benutzbar ist, auch wenn die Antwortzeiten sich in diesem Fall verdoppeln<br />
dürfen. Hierzu sollten automatische Testscripte erzeugt werden.<br />
Es sollten keine Probleme im Bezug auf Speicherplatz auftreten, da die erwarteten<br />
Datenmengen für aktuelle Festplatten kein Problem darstellen.<br />
7. Qualitätsziele<br />
Die entwickelte Software soll eine hohe Qualität aufweisen. Daher sind dem Stand der<br />
Technik entsprechende Software-Engineering und Qualitätssicherungsmethoden anzuwenden.<br />
Diese sollten mindestens eine Versionsverwaltung der Software umfassen, die nicht nur die<br />
Release-Versionen einschließt, sondern alle Entwicklungsschritte. Weiterhin werden Unit-<br />
Tests als sehr wichtig erachtet, da sie das Funktionieren essentieller Bestandteile der Software<br />
auch nach Änderungen sicherstellen können. Es sollten Arbeitsanweisungen durch den<br />
Auftraggeber einsehbar sein, die den Umgang mit den entsprechenden qualitätssichernden<br />
Maßnahmen beschreiben.<br />
8. Begriffserklärungen<br />
Auftraggeber: Die Universität <strong>Freiburg</strong>, Institut für medizinische Biometrie und<br />
medizinische Informatik, Abteilung DRKS<br />
Auftragnehmer: Die vom Auftraggeber mit der Softwareentwicklung beauftragt Firma.<br />
Besucher: Ein Besucher der externen öffentlichen Webseite des Registers<br />
Deutsches Register Klinischer Studien (DRKS): Das vom BMBF geförderte Projekt zur<br />
Erstellung eines Register Klinischer Studien in Deutschland.<br />
DM: Datenmanagement. Meist auch die zum Datenmanagement und zur<br />
Qualitätssicherung angestellten Mitarbeiter des DRKS.<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 33/39
Import-Benutzer: Eine Person, die stellvertretend für eine andere Organisation (EK,<br />
LKP: Siehe Sponsor.<br />
anderes Register...) Daten mehrerer Studien in das Register importiert.<br />
Mitarbeiter: Ein Mitarbeiter ist eine beim Deutschen Register Klinischer Studien<br />
angestellte Person, die mit der Datenerfassung, dem Datenmanagement oder<br />
der Qualitätssicherung befasst ist. Sie hat Zugang zu allen Studien und im<br />
Vergleich zum Sponsor erweiterte Rechte, wie beispielsweise die<br />
Veröffentlichung von Studien.<br />
QS: Qualitätssicherung. Meist auch ein Mitglied der Qualitätssicherung des<br />
Registers.<br />
Sponsor: Die Person, die für eine Studien verantwortlich ist. In Deutschland<br />
zusätzlich LKP (Leiter der klinischen Prüfung) genannt.<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 34/39
9. Anhang 1: WHO Registration Data Set (Version 1.0)<br />
Aus http://www.who.int/ictrp/data_set/en/index.html (Stand: 15.10.2007)<br />
Item Field Value Definition/Explanation<br />
1<br />
2<br />
Primary<br />
Register and<br />
Trial ID #<br />
Date of<br />
Registration in<br />
Primary<br />
Register<br />
3 Secondary<br />
ID#s<br />
4<br />
Source(s) of<br />
Monetary or<br />
Material<br />
Support<br />
5 Primary<br />
Sponsor<br />
6 Secondary<br />
Sponsor(s)<br />
Trial ID #<br />
Issuing Authority<br />
ID Number<br />
Click to add more …<br />
Name<br />
Click to add more…<br />
Name<br />
Name<br />
Click to add more...<br />
Name of Primary Register, and the<br />
unique ID number assigned by the<br />
Primary Register to this trial.<br />
Date when trial was officially registered in<br />
the Primary Register.<br />
Other identifying numbers and issuing<br />
authorities besides the Primary Register,<br />
if any. Include the sponsor name and<br />
sponsor-issued trial number (e.g.,<br />
protocol number) if available. Also<br />
include other trial registers that have<br />
issued an ID number to this trial. There is<br />
no limit on the number of Secondary ID<br />
numbers that can be provided.<br />
Major source(s) of monetary or material<br />
support for the trial (e.g., funding agency,<br />
foundation, company).<br />
The individual, organization, group or<br />
other legal entity which takes<br />
responsibility for initiating, managing<br />
and/or financing a study.<br />
The Primary Sponsor is responsible for<br />
ensuring that the trial is properly<br />
registered. The Primary Sponsor may or<br />
may not be the main funder<br />
Additional individuals, organizations or<br />
other legal persons, if any, that have<br />
agreed with the primary sponsor to take<br />
on responsibilities of sponsorship.<br />
A secondary sponsor may have agreed<br />
• to take on all the responsibilities<br />
of sponsorship jointly with the<br />
primary sponsor; or<br />
• to form a group with the primary<br />
sponsor in which the<br />
responsibilities of sponsorship<br />
are allocated among the<br />
members of the group; or<br />
• to act as the sponsor’s legal<br />
representative in relation to<br />
some or all of the trial sites; or<br />
• to take responsibility for the<br />
accuracy of trial registration<br />
information submitted.<br />
7 Contact for Email, telephone number, or address Email address, telephone number, or<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 35/39
8<br />
Public Queries<br />
Contact for<br />
Scientific<br />
Queries<br />
9 Public Title<br />
10 Scientific Title<br />
11<br />
12<br />
Countries of<br />
Recruitment<br />
Health<br />
Condition(s) or<br />
Problem(s)<br />
Studied<br />
13 Intervention(s)<br />
Email, telephone number, or address<br />
Affiliation<br />
Acronym<br />
Intervention name(s)<br />
Other details (e.g., dose, duration, etc.)<br />
Click to add more experimental<br />
interventions…<br />
Control Intervention name<br />
Other details of control (e.g., dose, duration,<br />
etc.)<br />
Click to add more control interventions…<br />
postal address of the contact who will<br />
respond to general queries, including<br />
information about current recruitment<br />
status<br />
Email address, telephone number, or<br />
postal address, and affiliation of the<br />
person to contact for scientific queries<br />
about the trial (e.g., principal investigator,<br />
medical director employed by the<br />
sponsor). For a multi-center study, enter<br />
the contact information for the lead<br />
Principal Investigator or overall scientific<br />
director.<br />
Title intended for the lay public in easily<br />
understood language.<br />
Scientific title of the study as it appears in<br />
the protocol submitted for funding and<br />
ethical review. Include trial acronym if<br />
available.<br />
The countries from which participants will<br />
be, are intended to be, or have been<br />
recruited.<br />
Primary health condition(s) or problem(s)<br />
studied (e.g., depression, breast cancer,<br />
medication error). If the study is<br />
conducted in healthy human volunteers<br />
belonging to the target population of the<br />
intervention (e.g., preventative or<br />
screening interventions), enter the<br />
particular health condition(s) or<br />
problem(s) being prevented. If the study<br />
is conducted in healthy human<br />
volunteers not belonging to the target<br />
population (e.g., a preliminary safety<br />
study), an appropriate keyword will be<br />
defined for users to select.<br />
Enter the specific name of the<br />
intervention(s) and the<br />
comparator/control(s) being studied.<br />
Use the International Non-Proprietary<br />
Name if possible (not brand/trade<br />
names). For an unregistered drug, the<br />
generic name, chemical name, or<br />
company serial number is acceptable. If<br />
the intervention consists of several<br />
separate treatments, list them all in one<br />
line separated by commas (e.g., "low-fat<br />
diet, exercise").<br />
The control intervention(s) is/are the<br />
interventions against which the study<br />
intervention is evaluated (e.g., placebo,<br />
no treatment, active control). If an active<br />
control is used, be sure to enter in the<br />
name(s) of that intervention, or enter<br />
"placebo" or "no treatment" as<br />
applicable.<br />
For each intervention, describe other<br />
intervention details as applicable (dose,<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 36/39
14<br />
Key Inclusion<br />
and<br />
Exclusion<br />
Criteria<br />
15 Study Type<br />
16<br />
17<br />
Date of First<br />
Enrollment<br />
Target Sample<br />
Size<br />
18 Recruitment<br />
Status<br />
19 Primary<br />
Outcome(s)<br />
20<br />
Key Secondary<br />
Outcomes<br />
Inclusion Criteria<br />
Exclusion Criteria<br />
Outcome Name<br />
Timepoints<br />
Click to add more outcomes…<br />
duration, mode of administration, etc)<br />
Inclusion and exclusion criteria for<br />
participant selection, including age and<br />
sex.<br />
A single arm study is one in which all<br />
participants are given the same<br />
intervention. Trials in which participants<br />
are assigned to receive one of two or<br />
more interventions are NOT single arm<br />
studies. Crossover trials are NOT single<br />
arm studies.<br />
A trial is "randomized" if participants are<br />
assigned to intervention groups using a<br />
method based on chance (e.g., random<br />
number table, random computergenerated<br />
sequence, minimization,<br />
adaptive randomization).<br />
If the trial is being registered after<br />
recruitment of the first participant record<br />
actual date of Anticipated date of<br />
enrollment of the first participant.<br />
Number of participants that this trial<br />
plans to enroll.<br />
Recruitment status of this trial.<br />
• Pending: participants are not yet<br />
being recruited or enrolled at any<br />
site<br />
• Active: participants are currently<br />
being recruited and enrolled<br />
• Temporary halt: there is a temporary<br />
halt in recruitment and enrollment<br />
• Closed: participants are no longer<br />
being recruited or enrolled<br />
Outcomes are events, variables, or<br />
experiences that are measured because<br />
it is believed that they may be influenced<br />
by the intervention. The Primary<br />
Outcome should be the outcome used in<br />
sample size calculations, or the main<br />
outcome(s) used to determine the effects<br />
of the intervention(s).<br />
Enter the names of all primary outcomes<br />
in the trial as well as the pre-specified<br />
timepoint(s) of primary interest. Be as<br />
specific as possible with the metric used<br />
(e.g., “% with Beck Depression Score ><br />
10 ”rather than just “depression”).<br />
Examples:<br />
Outcome Name: all-cause mortality,<br />
Timepoints: 5 years; or Outcome Name:<br />
Mean Beck Depression Score,<br />
Timepoint: 18 weeks<br />
Outcome Name Secondary outcomes are events,<br />
variables, or experiences that are of<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 37/39
Timepoints<br />
Click to add more outcomes…<br />
secondary interest or that are measured<br />
at timepoints of secondary interest. A<br />
secondary outcome may involve the<br />
same event, variable, or experience as<br />
the primary outcome, but measured at<br />
timepoints other than those of primary<br />
interest (e.g., Primary outcome: all-cause<br />
mortality at 5 years; Secondary outcome:<br />
all-cause mortality at 1 year, 3 years), or<br />
may involve a different event, variable, or<br />
experience altogether (e.g., Primary<br />
outcome: all-cause mortality at 5 years;<br />
Secondary outcome: hospitalization rate<br />
at 5 years).<br />
Enter the name and timepoint(s) for all<br />
secondary outcomes of clinical and/or<br />
scientific importance. Be as specific as<br />
possible with the metric used (e.g., “%<br />
with Beck Depression Score > 10” rather<br />
than just “depression”). Examples:<br />
Outcome Name: all-cause mortality,<br />
Timepoint: 6 months, 1 year; or Outcome<br />
Name: Mean glycosylated hemoglobin<br />
A1C, Timepoint: 4 and 8 weeks<br />
Last update: 19 June 2007<br />
10. Anhang 2: Beschreibung des Deutschen Registers<br />
Klinischer Studien (Auszug aus dem Förderantrag)<br />
10.1. Specification of the German register of clinical trials<br />
10.1.1. 1. Background Statement<br />
It is now generally accepted that the evidence from all well conducted controlled (and<br />
randomised, if existing) trials should be the base for decisions in healthcare and for the<br />
planning of further medical research i,ii,iii . Identifying all relevant trials is a difficult task and is<br />
almost entirely dependent on the published literature. A significant proportion of clinical trials<br />
research is, however, never published. This can lead to a significantly distorted assessment of<br />
an intervention due to publication bias, defined as “the tendency on the parts of investigators,<br />
reviewers, and editors to submit or accept manuscripts for publication, based on the direction<br />
or strength of the study findings” iv . It has been demonstrated that trials with a statistically<br />
significant result take less time to being published, and are more likely to actually be<br />
published, than those with null or negative results v,vi .<br />
Comprehensive, publicly accessible clinical trial registries are now widely accepted as an<br />
essential tool to fill this gap vii,viii,ix,x,xi,xii . They would not only inform about all conducted but<br />
also about ongoing trials, if registration happens at inception.<br />
Such registries serve healthcare and medical research by<br />
• reducing the negative impact of publication bias by presenting a complete picture of<br />
all clinical trials investigating a specific healthcare problem.<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 38/39
• allowing researchers to learn valuable lessons from the experience of those who have<br />
previously tested and found no benefit (or even harm) of a related intervention.<br />
• supporting organisations (funders, ethics committees etc.) with complete information<br />
about ongoing and completed trials for the planning and assessment of new trials,<br />
thus helping to avoid unnecessary duplication of research activities and improve the<br />
processes associated with clinical trials.<br />
• ensuring the ethical request on behalf of participating subjects that the results of all<br />
studies contribute to medical knowledge xiii,xiv,xv,xvi .<br />
• informing the public, the medical profession and potential participants about ongoing<br />
trials to improve the recruitment for trials and to help patients to find trials.<br />
Prospective registration of clinical trials has the support of numerous organisations<br />
internationally and nationally (for Germany described in chapter 5). However, this support<br />
has not led to a global system that would enable easy identification of trials worldwide so far.<br />
International and national registration and registers<br />
The need and the benefit of prospective clinical trial registration has been discussed since<br />
more than 40 yearsvii and has led to an increasing number of clinical trials registries, disease<br />
or method-specific and all-inclusive, throughout the world and also in Germany (see below).<br />
During the last three years a few events had a massive impact on this issue and intensified the<br />
demand for registration xvii . The existence of ongoing serious publication bias was<br />
demonstrated by several studies xviii and in one case even led to the prosecution of a<br />
pharmaceutical company by the general attorney of New York. GlaxoSmithKline (GSK) was<br />
accused of only publishing two positive out of six trials on the antidepressant Paxil for<br />
children xix and not reporting the increased suicide rate.<br />
The largest impact came from the remarkable move of the International Committee of<br />
Medical Journal Editors (ICMJE). They announced a new policy and declared that their<br />
member journals would publish reports of trials after 1 July 2005 (resp. 13 Sept. 2005 for<br />
already running trials) only if the trial was registered with a register which meets certain<br />
criteria xx,xxi,xxii .<br />
Two registers can be considered global because they accept the registration of trials from any<br />
country: ClinicalTrials.gov (www.clinicaltrials.gov) is funded by the US National Institutes of<br />
Health (NIH) and operated by the National Library of Medicine (NLM). After the<br />
establishment as US register it was opened to worldwide registration in October 2004, in<br />
response to the new ICMJE policy xxiii . The second global player is Current Controlled Trials<br />
(CCT; www.controlled-trials.com), a subgroup of the publisher BioMed Central.<br />
There is no systematic list of existing national registers. However, several are known from<br />
their activities in international workgroups and publications (see Appendix 1; received<br />
informally from WHO). In some countries a certain proportion of trials is registered<br />
systematically (e.g. trials funded by the Canadian Institute of Health Research, CIHR, are<br />
registered with CCT) while some countries set up registers to achieve complete coverage (e.g.<br />
Australia, Netherlands). In spite of differences due to specific conditions of healthcare and<br />
research systems, these activities are facing very similar challenges and difficulties xxiv . The<br />
dominant issues are the achievable degree of completeness and how to ensure it, which details<br />
to register, when to register, if and how to update the information and how to set up a working<br />
quality assurance mechanism.<br />
Non-comprehensive registers, covering only selected diseases or limited areas, may make<br />
sense but are prohibitive to an efficient global search for trials and increase the complexity of<br />
the existing register structure. To allow a user-friendly search, if possible through one global<br />
search portal, the World Health Organisation (WHO) decided to take the leadership and the<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 39/39
coordination of the development of a globally working network of registers xxv . With the<br />
approval of the World Health Assembly in May 2005, the International Clinical Trials<br />
Registry Platform (ICTRP) was established to take the lead in setting international norms and<br />
standards for trial registration and reporting. The Registry Platform consults with relevant<br />
stakeholders worldwide to produce consensus-based policies which uphold scientific and<br />
ethical principles on clinical trials but which are also practical and feasible.<br />
Trial Registration in Germany<br />
The discussion of trial registration has a shorter history in Germany (see Appendix 2) than in<br />
some of the countries leading this field xxvi . More than 30 disease-specific or otherwise<br />
focussed registers of very variable structure and quality are currently in operation in various<br />
environments (see Appendix 3) but there is no comprehensive national German register and<br />
no national coordination and structuring of the registration of trials conducted in<br />
Germany xxvii,xxviii,xxix . In spite of the well promoted request from the ICMJE and the selfcommitment<br />
to full transparency xxx,xxxi only a small proportion of the (unknown) number of<br />
trials is registered in one of the two international registers ClinicalTrials.gov and CCT which<br />
fulfil the conditions of ICMJE. 748 and 163 (ascertained at different time points) of the<br />
estimated 5000 eligible trials in Germany per year can with some difficulties be identified in<br />
the two registers (see Appendix 4). Figures are only approximations but clearly show that the<br />
registration rate is not anywhere close to a satisfactory proportion.<br />
i NHMRC. A guide to the development, implementation and evaluation of clinical<br />
practice guidelines. ©Commonwealth of Australia. 1999. ISBN 1864960485<br />
ii Goodman KW. Problems with biomedical research data and reports. In: Ethics and<br />
Evidence-Based Medicine. Cambridge University Press, 2003. p. 52<br />
iii European Federation of Pharmaceutical Industries and Associations. Joint position on<br />
the disclosure of clinical trial information via clinical trial registries and databases.<br />
January 2005<br />
iv Dickersin K. Why register clinical trials? Control Clin. Trials. 1992;13:170-177<br />
v Stern JM, Simes RF. Publication bias: Evidence of delayed publication in a cohort<br />
study of clinical research projects. BMJ. 1997;315:640-645<br />
vi Simes RJ. Confronting publication bias: a cohort design for meta-analysis. Statistics<br />
in Medicine. 1987;6:11-29<br />
vii Dickersin K, Rennie D. Registering clinical trials. JAMA. 2003;290:516-523<br />
viii Simes RJ. Publication bias: the case for an international registry of clinical trials.<br />
Journal of Clinical Oncology. 1986,4(10):1529-41<br />
ix Easterbrook Easterbook P. Reducing publication bias. [Letter] British Medical Journal<br />
Clinical Research Ed. 1987,295(6609):1347<br />
x Chalmers I, Dickersin K, Chalmers TC. Getting to grips with Archie Cochrane’s agenda.<br />
[Editorial] BMJ. 1992,305(6857):786-8<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien 40/39
xi International Collaborative Group on Clinical Trial Registries. Position paper and<br />
consensus statement on clinical trial registries. Clinical Trials and Meta-Analyses.<br />
1993;28:199-201<br />
xii Abbasi K. Compulsory registration of clinical trials. BMJ. 2004;329;637-638<br />
xiii Pearn J. Publication: an ethical imperative. BMJ. 1995;310:1313-1315<br />
xiv Raspe H, Hüppe A, Steinmann M. Identifizierung, Studienregistrierung und Meldung.<br />
In: Empfehlungen zur Begutachtung klinischer Studien durch Ethik-Kommissionen.<br />
Deutscher Ärzte-Verlag, Köln, 2006. S.13-16<br />
xv Antes G. Registering clinical trials is necessary for ethical, scientific and economic<br />
reasons. Bulletin of the World Health Organization. 2004;82(5):321<br />
xvi Victor N. Klinische Studien: Notwendigkeit der Registrierung aus Sicht der<br />
Ethikkommissionen. Deutsches Ärzteblatt. 2004;101(30):A2111-2116,A1<br />
xvii Haug C, Gøtzsche PC, Schroeder TV. Registries and Registration of Clinical Trials.<br />
New England Journal of Medicine. 2005;353(26):2811-2812<br />
xviii Gibbs TG, Wager E. Realities of trial registration: the Glaxo Wellcome experience.<br />
International Journal of Pharmaceutical Medicine. 2000;14:203-205<br />
xix http://www.oag.state.ny.us/press/2004/jun/jun2b_04.html<br />
xx De Angelis CD, Drazen JM, Firzelle FA, Haug C, Hoey J, Horton R, Kotzin S, Laine<br />
C, Marusic A, Overbeke A J, Schroeder TV, Sox HC, Van der Weyden MB. Is this clinical<br />
trial fully registered? Annals of Internal Medicine. 2005;143(2):146-148<br />
xxi http://www.icmje.org/<br />
xxii Drazen JM, Wood AJJ. Trial Registration Report Card. New England Journal of<br />
Medicine. 2005; 353(26):2809-2811<br />
xxiii Zarin AD, Tse T, Ide CN. Trial Registration at ClinicalTrials.gov between May and<br />
October 2005. New England Journal of Medicine. 2005; 353(26):2779-2787<br />
xxiv Fisher BC. Clinical Trials Results Databases: Unanswered Questions. Science. 2006;<br />
311:180-181<br />
xxv http://www.who.int/ictrp/en/<br />
xxvi Schumacher M, Beck M, Roßner R. European Cancer Clinical Trial Register<br />
(ECCTR) – eine aktuelle, europaweite Informationsquelle über Therapiestudien in der<br />
Onkologie. Forum DKG. 1996;11:220-223<br />
xxvii Feurle GE. BfArM-Register ausbauen. Zu dem Beitrag: Klinische Studien:<br />
Registrierung aus Sicht der Ethikkommissionen von Prof. Victor N. in Heft 30/2004.<br />
Deutsches Ärzteblatt. 2005;102(10):A681<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien<br />
41/39
xxviii Victor N. Schlusswort zu dem Beitrag: BfArM-Register ausbauen von Prof.<br />
Feurle in Heft 10/2005. Deutsches Ärzteblatt. 2005;102(10):A681<br />
xxix Bestehorn K, Hönig R, Clemens N, Kirch W. Register für klinische Studien – eine<br />
kritische Bestandsaufnahme. Medizinische Klinik. 2006;101(2):120-126<br />
xxx IFPMA, Efpia, PhRMA, JPMA. Joint Position on the Disclosure of Clinical Trial<br />
Information via Clinical Trial Registries and Databases. Announced on January 6, 2005<br />
xxxi IFPMA. IFPMA improves Biomedical Data Transparency with Launch of First<br />
Worldwide Clinical Trials Portal. Announced on September 21, 2005<br />
<strong>Pflichtenheft</strong>: Software zum Betrieb des Deutschen Registers Klinischer Studien<br />
42/39