Status EU Portal/Datenbank

Transkript

1 EU-Verordnung 536/2014 Status EU Portal/Datenbank Dr. Stefan Strasser Abteilung Klinische Prüfung, Institut Überwachung AGES Medizinmarktaufsicht (MEA) AGES Gespräch Austrian Agency for Health and Food Safety GmbH

2 Übersicht Umfang und Ziel des Systemaudits Wichtige Funktionen außerhalb des Audits Use-Case Prinzip mit Beispielen User Acceptance Testing User Management Ein kleiner Blick ins Portal 2

3 Status EU Portal/Datenbank UMFANG UND ZIEL DES SYSTEMAUDITS WICHTIGE FUNKTIONEN AUSSERHALB DES AUDITS 3

4 Zeitplan und Meilensteine der CTR Verordnung im Amtsblatt publiziert Zustimmung zu Audit-Kriterien durch EMA MB Entwicklung & Vorbereitung auf Audit EMA MB nimmt Auditbericht ab Kommission veröffentlicht im Amtsblatt Verordnung ist anzuwenden // 27 Mai Dez 2014 jetzt Q Q Q4 2018! Übergangsphase (3 Jahre) Ende der Übergangsfrist ( Legacy period ): Alle noch unter Direktive 2001/20/EC laufenden Verfahren müssen (!!!) auf die Verordnung umgestellt werden // The endorsed timeframe foresees that the portal and database are planned to be available for an independent audit by August If the system receives a green light from the audit, the Clinical Trial Regulation will come into effect by October 2018 at the latest. This is a maximum timeframe, and every effort will be made to shorten it and bring the Regulation into operation as soon as possible. Siehe auch Delivery time frame for the EU portal and EU database auf der EMA Webseite. 4

5 Vom Gesetz zum System Gesetzliche Grundlage Artikel 80: EU Portal Artikel 81: EU Datenbank Artikel 82: Funktionsfähigkeit 5

6 Vom Gesetz zum System Functional Specifications Gesetzliche Anforderungen (Kapitel 5, Tabelle 1) Zu auditierende Spezifikationen (Kapitel 6, Tabelle 2) Post-audit releases (Annex 1) 6

7 Vom Gesetz zum System Hierarchie der Anforderungen AUDITABLE requirements sind gesetzlich gefordert sind Bedingung für das Inkrafttreten der Verordnung MUST requirements sind essentiell wichtig und nicht verhandelbar ausbleibende Umsetzung würde zum Scheitern des Projekts führen SHOULD requirements sind nicht erfolgskritisch für das Projekt haben hohe Relevanz und sollten berücksichtigt werden COULD requirements haben geringe Relevanz ( Nice to have ) werden erst berücksichtigt, wenn noch Kapazitäten vorhanden sind WON T requirements werden nicht implementiert können zukünftig in Betracht gezogen werden 7

8 Vom Gesetz zum System Und da wird s dann schwierig Für die Umsetzung dieser essentiellen Funktionen gibt es keine gesetzliche Garantie! Alle wirklich essentiellen Funktionen müssen daher auditable functions sein. 8

9 Post Audit-Functionalities Kommunikation zwischen MSC über Studien und studienübergreifende Themen Automatischer Austausch von Dokumenten zwischen der Datenbank und anderen Systemen Erweiterte Berichte und Statistiken mit Verlinkung von Systemen Auslösen von ad-hoc workflows/case management für nicht im Workflow vorgesehene Situationen Kooperation bei Evaluierung und Überwachung von Sicherheitsmeldungen einer Studie (ASR, SUSAR ) Verlinkung zur Eudravigilanz Datenbank für MSC aus dem Workspace. Hochladen von außerhalb des Workspace erstellten CTAs 9

10 Status EU Portal/Datenbank USE CASES PRINZIP USER ACCEPTANCE TESTING 10

11 Übersicht der Vorbereitung Management des EU-CTR Antrages 1. Antragstellung 2. Antragsbearbeitung /Genehmigung 3. Änderungen an CT 24 UC Management der laufenden Studie 4. Issue Notification 5. Überwachung der Studie 24 UC 6. Übermittlung der Ergebnisse 16 UC 25 UC Management des Portals bzw. der Datenbank 5 UC 7. Veröffentlichung 8. Zugangsrechte 9. Management Ergebnisberichte 10. Management User Profile 10 UC 15 UC Detailmanagment der Datenbank-Einträge 11. Business rules 12. Konfiguration Reports 13. User Zugriffsrechte und Aufgaben 28 UC 11

12 Beispiel Use Case Ein Anwendungsfall (use case) ist eine Abfolge von Schritten/ Wechselwirkungen zwischen einem Akteur (User) und dem System, um ein Ziel zu erreichen. Der User kann ein Mensch oder ein externes System sein. Beispiel: Use case Populate Assessment Part II report : 1. The User selects. 2. The system prompts the user to enter 3. The user enters 4. The system displays warnings if any of the following conditions. 5. The user confirms completion of 6. 12

13 Wesentliche Funktionelle Spezifikationen 1. Create Application (L1) 24 UC Ermöglicht dem Sponsor einen gemeinsamen Antrag für eine klinische Studie in einer Reihe von Mitgliedstaaten zu erstellen. Bei der Erstellung erhalten Sponsoren eine einzigartige EU Studiennummer, die mit ihrem Antrag verknüpft ist. Sponsoren sollen in der Lage sein Organisationen und Produkte mit ihrem Antrag zu verknüpfen Referenzen zu bereits bestehenden Anträgen zu setzen einen vorherigen Antrag zu kopieren, um einen Neuantrag zu erleichtern den Antrag zu befüllen und die kooperativen (Part I) und nationalen (Part II) Anteile gemeinsam oder konsekutiv einzureichen 13

14 Wesentliche Funktionelle Spezifikationen 1.1 Initiate Application (L2) Enthält Verknüpfung eines Neuantrages mit einem Sponsor/Registrierung als Sponsor Titel und Referenz einer Resubmission (falls zutreffend) Vergabe der Studiennummer (YYYY-NNNNNN-XX-00) Abbruch des Vorgangs 14

15 Wesentliche Funktionelle Spezifikationen 1.2 Populate Application (L2) 15

16 Ergebnisse UAT 1 und 2 16

17 Plan für UAT 3 (Release 0.3) lineare Funktionalitäten grundsätzlich gegeben Belastungstest des Workflows aufgrund der Testumgebung nur eingeschränkt möglich 17

18 Status EU Portal/Datenbank USER MANAGEMENT 18

19 Registrierung Navigation zur Webseite des CT Portals Aufruf der Registrierungsfunktion Eingabe der persönlichen Daten Auswahl von Benutzername, Passwort und Sicherheitsfrage Abschicken an die EMA Alle Nutzer müssen sich im EMA System registrieren, bevor sie Zugriff auf EU Portal & EU Datenbank erhalten können Persönliche Angaben: Vorname, Nachname, Telefonnummer, Verständigung durch EMA, sobald User angelegt wurde 19

20 User Management Studien-zentriert: Management durch CT Admin User, der CT anlegt, wird Admin CT Administrator erteilt und verwaltet Zugang zur Studie Anlage CT Organisations-zentriert: Sponsor Admin gestattet Verbindung mit der Organisation All CT workstream Rolle gilt für alle CTs CT specific workstreatm CTs werden zugeteilt Auswahl Sponsor Organisation registrieren Organisation vorhanden? Trial-centric Admin registrieren? Admin vorhanden? Admin registrieren Organisationcentric 20

21 User Verwaltung EMA 21

22 User Management Hierarchie Sponsor Admin Sponsor Admin Backup CT Admin CT Admin Backup CT Admin CT Admin Backup CT User CT User CT User CT User CT User CT User 22

23 User dashboard (mock-up) EMA 23

24 Business Roles Sponsor MAH Validator Assessor Part I Assessor Part II Decision Maker Supervisor Inspector Union Controller Viewer 24

25 Work Packages WP1: Part I (without IMPD)/View trial information/fields pulled from IMPD WP2: Part II WP3: IMPD WP4: Responses to RFI, responses to additional info, withdrawal, notifications, 3rd country IR, Lay summmary, CT summary WP5: Express willigness, RMS selection, RFI- Vali, comments on RMS role, comments on RFI response, considerations-val, consolidated considerations- Val WP6: AR (Part I or Part II), RFI- AR, conclusion-ar, considerations-ar, consolidated considerations-ar WP7: Corrective measures, additional info request, evaluation add info WP8: Conclusion- Val, MS decision, disagreement Part I, revert decision WP9: Inspection reports (IR) WP10: Union Control WP11: Clinical Study Report WP12: Protocol and IB 25

26 Role Matrix WP1: Part I (without IMPD)/View trial information/fields pulled from IMPD WP2: Part II WP3: IMPD WP4: Responses to RFI, responses to additional info, withdrawal, notifications, 3rd country IR, Lay summmary, CT summary 26

27 Status EU Portal/Datenbank EIN BLICK INS PORTAL Slides werden nur beim Vortrag gezeigt. 27

28 Danke für die Aufmerksameit! Fragen?