Docstoc

CR-requiements-SPECv0-4

Document Sample
CR-requiements-SPECv0-4 Powered By Docstoc
					 Central Repository API
            -
Functional requirements




       Version 0.4

    October 15th, 2008




                          1
Document history




Change Record
Version         Author(s)                   Comments
0.1             Klaus Menges                This draft will detail functional requirements and takes into
                                            account the features of the EiV API as far as known.
0.2             Klaus Menges                Adding missing aspects around dossiers download, document
                                            download, annotations handling and adding the chapter 5. Open
                                            questions
0.3             Klaus Menges                Additional use cases in regard of hyperlinks. Complete revision
                                            of section 3 and 4 based on comments from Akira Yamaguchi,
                                            Lorenz. Changing section 5.
0.4             Klaus Menges                Additional comments from Pieter Vankeerberghen



Reviewers
Version     Name                            Organisation
0.1         Harald Binder                   AGES, Wien, Austria



Distribution
Version     Name                            Organisation
0.1         Harald Binder, Franz Schuler    AGES
            David Obramovic                 JAZMP
            Pieter Vankeerberghen           FAGG
0.3         Ulrich Kunz, Hartmut Waldner,   BfArM
            Hubertus Franzen
            Akira Yamaguchi                 Lorenz ArchivSysteme




Coming into Operation
Version     Date in operation               Comment




                                                                                                              2
Index

Table of Contents
Central Repository API - Functional requirements ............................................................... 1
  Document history ............................................................................................................. 2
     Change Record ........................................................................................................... 2
     Reviewers.................................................................................................................... 2
     Distribution .................................................................................................................. 2
     Coming into Operation ................................................................................................ 2
  Index ................................................................................................................................ 3
  1 Introduction ................................................................................................................... 4
  2 Glossary ........................................................................................................................ 5
  3 Use cases ..................................................................................................................... 7
     3.1 Log-in .................................................................................................................... 7
     3.2 Notification of dossiers and submissions, download of backbones and metadata 7
     3.3 Download of documents ........................................................................................ 7
     3.4 Notification and download of annotations .............................................................. 7
     3.5 Upload of annotations............................................................................................ 7
     3.6 Use of hyperlinks ................................................................................................... 7
  4 Methods for the api........................................................................................................ 9
     4.1 Login...................................................................................................................... 9
     4.2 GetDossiers........................................................................................................... 9
     4.3 GetSubmissions .................................................................................................... 9
     4.4 GetFileUrl ............................................................................................................ 10
     4.5 GetFileUrlByFullName ......................................................................................... 10
     4.6 GetFileInfo ........................................................................................................... 10
     4.7 GetFileInfoByFullName ....................................................................................... 10
     4.8 GetAnnotationsList .............................................................................................. 10
     4.9 SynchronizeAnnotations ...................................................................................... 10
     4.10 OpenHyperlink ................................................................................................... 10
  5. Connection protocols usable ...................................................................................... 11

Annex 1.............................................................................................................................. 12
Change request detailing communication requirements between EMEA Central Repository
and NCA managed with the EURS project......................................................................... 12
Introduction ........................................................................................................................ 15
1. Scope............................................................................................................................. 15
2. Change Request ............................................................................................................ 15
3. Description ..................................................................................................................... 15
   4.1.     Possible architecture ......................................................................................... 15
   4.2 Anticipated Traffic Volumes and Bandwidth Requirements ................................... 17
   4.3 Process Workflow.................................................................................................. 18
   4.3 Involved Network Traffic ........................................................................................ 19
5.    Justification................................................................................................................ 20




                                                                                                                                        3
1 Introduction
The generic API shall provide an open interface for accessing the Central Repository at EMEA by
NCAs involved into the Centralised Procedure regardless of the review tool the NCA is using.
This document describes API functions which are currently intended to be supported by a
standardised open interface and is related to the Change Request to develop an API in parallel to
the functionalities provided by the EiY specific API. Already distributed (Annex 1)
The use of the API may also open up the possibility to access the Central Repository avoiding the
download of the huge amount of data in Centralised Procedures expected over time.
2 Glossary
Term                      Definition

Applicant                 A pharmaceutical company or its agent that is submitting
                          information in relation to a product within the regulated
                          environment according to Dir. 2001/83/EC

Applicant‟s information   Any information in relation to a product within the
                          regulated environment according to Dir. 2001/83/EC
                          submitted by an applicant for, or to maintain a marketing
                          authorisation that falls within the scope of this guidance
                          document.

Regulatory activity       Submission of an application consisting of a collection of
                          sequences concerning a specific business process, e.g.
                          an initial MA application or Type II variation defined as
                          submission type.

Dossier                   Set of documents specified by Eudralex Volume 2B in
                          accordance with CTD requirements to describe and justify
                          an application within a specific type of procedure and
                          regulatory activity. A dossier might be related to several
                          applications depending on the granularity of strength,
                          pharmaceutical form and product names. The most
                          common use is of one dossier per product name.

Procedure                 A community procedure for the authorisation of medicinal
                          products in the European Community. There are 4 types
                          of procedure that operate within the EC – Centralised,
                          Decentralised, Mutual Recognition and National.

Submission or Sequence    A single set of information and/or documents supplied at
                          one time by the applicant as a part of, or the complete,
                          dossier. In the context of eCTD, this is equivalent to a
                          „sequence‟. Depending from the procedure and in
                          accordance with the regulatory activity different types of
                          submission are possible: [reference to EU M1
                          specification or stating explicitly:



                                 initial-maa = Initial Marketing Authorisation
                                  Application
                                 supplemental-info = Supplemental Information
                                  (could include, for example, response to validation
                                  issues or response to questions)
                                 fum = Follow-Up Measure (includes post-approval
                                  commitments for national MAs)
                                 specific-obligation = Specific Obligation
                                 var-type1a = Variation Type IA
                                 var-type1b = Variation Type IB
                                 var-type2 = Variation Type II
                                 extension = Extension
                                 psur = Periodic Safety Update Report (PSUR)
                                 renewal = Renewal (yearly or 5-yearly)
                                 asmf = Active Substance Master File
                                 referral = Referral under Article 29, 30, 31, 35 or 36
                                 annual-reassessment = Annual Reassessment
                                 usr = Urgent Safety Restriction
                                 article-58 = Article 58 (to be used for an initial
                                  application)
                                 notification-61-3 = Notification 61(3)
Term         Definition

                    transfer-ma = Transfer of a marketing
                     authorisation
                    corrigendum = Correction to the published annexes
                     (usually shortly after approval)
                    lifting-suspension = Lifting of a suspension
                    withdrawal = Withdrawal during assessment or
                     withdrawal of a marketing authorisation
                    paed-article-29 = Paediatric submission, Article
                     29
                    var-nat = National variation (e.g. national variation
                     to apply for a pack size that is already registered within
                     an existing MRP/DCP authorisation)
                    reformat = Intended to support the reformatting of
                     an existing submission dossier from any format to
                     eCTD, i.e. a baseline eCTD submission containing no
                     content change and which will not be subject to review]
Annotation   Any comment from regulators on one specific document,
             one specific submission or regarding the entire dossier as
             part of the assessment intended to be addressed to the
             applicant. An annotation can reflect deficits of the contents
             presented and will then adhere to a specific file. A number
             of different annotations from different assessors from
             different agencies may occur. An annotation may also
             address deficits of the structure or request missing
             documents, or parts of the dossier and may then adhere
             to a specific submission, or the entire dossier. The diffent
             types of annotation will not be differentiated in regard of
             this guidance.
3 Use cases
3.1 Log-in
Description:
A dedicated server of the NCA will ask for access. It will be prompted to pass it‟s user-ID and password. A
session will be opened. A new query can be sent. The log-out will occur automatically after a period of
inactivity. The duration needs to be defined. Any new request from NCA user will initiate a new session
automatically after a log-out has happened.


3.2 Notification of dossiers and submissions, download of backbones and metadata
Description:
The query of the NCA server will ask for a list of newly registered or changed dossiers detailing the product
name, the procedure number and the UID of those which have been added to or changed by storing
additional sequences (submissions) in the Central Repository since the last session of the particular Agency.
The first time of use all dossiers will be part of the list. After that only new ones or changed dossiers will be
addressed. In case of identifiable dossiers not registered so far its index.xml files (EU M1; M2-M5) plus
relevant metadata will be downloaded for registration.


3.3 Download of documents
Description:
The consisting documents of dossiers and submissions registered by the NCA review tool can be
downloaded
    Case 1: by predefined rules at pre-defined time schedules
       All document files will be downloaded based on the analysis of the index.xml files already exist. The
       configuration of the analysis and the timing will be possible at NCA side. Depending whether e.g.
       BfArM is Rapporteur or Co-Rapporteur, whether always Module 2 needs to downloaded or whether
       the file size is too big for download by default.

       Case 2: by default.
        Based on the index.xml files each submission and each single document should be available for
        download separately by default. The files size should be provided before confirming start of
        download. A cancellation of the download must be possible.


3.4 Notification and download of annotations
Description:
The NCA server will query a list of newly registered annotations based on the time schedule between last
and current session. In case of identifiable annotations not registered so far they will be downloaded.
Currently, there is no clear understanding how the annotations will be registered and of what type the
annotation will be. From assessors point of view the most relevant annotations will deal with review results
related to a specific page within a report instead of more general comments on Module or dossier level.


3.5 Upload of annotations
Description:
Annotations on a specific page related to reviewed contents [, on a document, on a specific submission, or
on the entire dossier] will be uploaded after confirmation to be a final comment for EU regulator visibility. A
set of metadata will be necessary.


3.6 Use of hyperlinks
Description:
The hyperlinks set by the applicant needs to be maintained as usable hyperlinks after downloading of the
entire dossier, single submission and single document as well. Hyperlinks are provided as relative paths. In
the specific case of assessing a document a hyperlink will be activated. This action will initiate a query for
searching the linked document in the National Cache or the Central Repository and consecutively presented
on the screen (if available locally) or downloaded, cached and then presented on the screen (if available
centrally only).
Note: Use cases 3.4 and 3.5 are based on the Extedo functionality offered as “SynchroniseAnnotations”. To
our knowledge, no standard specification for representing annotations is defined, available or communicated.
Here it is not clear whether the annotations mentioned by EiY are addressed to a page or a document. The
current understanding is that additional examination and further definitions are necessary.
4 Methods for the api
     The API should be implemented as Web Services, preferable using SOAP. Error/fault handling must be supported and provided to the caller. If using REST,
      SOAP <fault> pendant is required. Errors and faults should be reported as codes only to avoid culture dependencies. For resolving the codes, a
      code/description table must be available.
     In case a method completion exceeds n seconds (n is a system-wide configurable parameter), the server must provide a mechanism for the caller to get the
      progress information.

Number Name                       Parameters           Returns                     Description
                                  (Credentials)        bool succeeded              Login to the repository
4.1     Login                                                                      User authorisation for accessing the Central Repository. It will be
                                                                                   always one user-ID (e.g. the download server) used per Agency via
                                                                                   http protocol, but not necessarily a human user. One log-in per
                                                                                   session. The authorisation does not need manual intervention. A time-
                                                                                   out will occur after 5 minutes of inactivity.
                                                                                   As the Eudranet will be used the https protocol will not be necessary.
                                  string criteria      DossierDetails              Returns list of DossierDetails (Criteria is to be defined)
4.2     GetDossiers                                      uuid dossierId            Returns the list of all dossiers detailing the product name, the
                                                         string name               procedure number and the UID based on the EU M1-Envelope
                                                         DateTime createDate       including a time stamp of check-in into Central Repository and any
                                                         DateTime lastModifiedDate further modification since the last session of the particular Agency
                                                                                   based on the time stamp considered. The function checks, if the
                                                                                   dossier with the unique UID was previously registered or is still
                                                                                   registered in the database of the particular Agency. If the answer is
                                                                                   “yes”, the number of available sequences may need to be updated.
                                                                                   Action 4.3 will be initiated automatically.
                                                                                   The envelope and the xml-backbone will be downloaded of the
                                                                                   requested application dossier and will be used to register the dossier
                                                                                   in the national cache / tool. A directory will be created as appropriate.
                                                                                   The settings of the query need to have the option of selecting mode
                                                                                   4.2 or 4.3.
                                  Uuid dossierId       SubmissionDetails           Returns list of SubmissionDetails
4.3     GetSubmissions                                   uuid submissionId         The function checks, if the submission with the unique UID was
                                                         string ectdSequenceNumber previously registered in the database of the particular Agency. If
                                                         DateTime createDate       multiple submissions are available the metadata from the most recent
                                                         DateTime lastModifiedDate submission should be taken to check whether all submissions /
                                                                                   sequences have been registered. [Remark: In case of centralised
                                                                                   procedures all sequences must be available for all NCAs.]. The
                                                                                   existing directory of the dossier will be fed.
Number Name                  Parameters          Returns                      Description
                                                                              According to specification, the nodes in the eCTD don‟t have UID..
                             Uuid submissionId string url                     Returns a URL address for the specified file, which allows web
4.4    GetFileUrl            string scope                                     optimized access to the file. As the leafId is only unique within one
                             string leafId                                    index or regional file the scope must be specified: “backbone”, “eu-
                                                                              regional”.
                             Uuid submissionId string url                     Returns a URL address for the specified file, which allows web
4.5    GetFileUrlByFullNam string name                                        optimized access to the file. The name is relative to the submission
       e                                                                      backbone file location.
                             Uuid submissionId FileDetails                    Returns FileDetails. As the leafId is only unique within one index or
4.6    GetFileInfo           string scope         string filename             regional file the scope must be specified: “backbone”, “eu-regional”.
                             string leafId        long size (in bytes)
                                                  long pageCount (Pdf only,
                                               optional)
                                                  string md5checkSum
                             Uuid submissionId FileDetails                    Returns FileDetails as defined below. The name is relative to the
4.7    GetFileInfoByFullNa   string name          string filename             submission backbone file location.
       me                                         long size (in bytes)
                                                  long pageCount (Pdf only,
                                               optional)
                                                  string md5checkSum
                             Uuid submissionId                                Returns all annotations of a specific documents, a specific submission,
4.8    GetAnnotationsList                                                     or the entire dossier since the last session of the particular Agency
                                                                              based on the time stamp considered. By default the presentation is
                                                                              restricted to 100 annotations. A change of the setting is useful and
                                                                              may offer a selection in regard of all annotations to one document, one
                                                                              submission, or the entire dossier.
                             Uuid submissionId                                Adds new annotations to the submission if they don‟t exist locally.
4.9    SynchronizeAnnotati                                                    Annotations will be registered by metadata such as UID, NCA-ID, and
       ons                                                                    context relates to (a document, a submission, a dossier, an
                                                                              annotation)
                                                                              Returns the requested document based on the query by clicking on
4.10   OpenHyperlink                                                          the hyperlink within a specific document of a submission of a dossier
                                                                              during assessment. Hyperlinks will be registered by metadata such as
                                                                              UID of one submission and the context that relates to (a document, a
                                                                              submission, a dossier). The requested document may already exit in
                                                                              the national cache or needs to be downloaded from the Central
                                                                              Repository.
5. Connection protocols usable
The change request detailed so far is documented in the attached document (Annex 1).

The functional requirements of the generic API will be usable independently from a specific
application. Therefore, a second part with some further considerations in regard of the use of the
webservice shall be added.

In addition to a remote access on docuBridge application running on a server in the neighbourhood
of the Central Repository hosted by the EMEA an access will also be possible defining the Central
Repository as an additional file pool. The NCA-user will then get on screen the available backbone
of a specific dossier. Some of the document may be available directly – they have been
downloaded in advance – or needs to be downloaded from the Central Repository prior to
presenting on the screen.

This access will be performed in the secure environment of Eudranet. This avoids further use of
additional means of secure connections.

The protocol in use must not necessarily be http but ftp should be considered as well. A simple
FTP interface (over Eudranet, with single sign-on from the ECD) will be the easiest solution for
most of the NCA's to have it in operation.
Annex 1




   Change request detailing communication
requirements between EMEA Central Repository
   and NCA managed with the EURS project



                        AGES (AT) and BfArM (DE)

                                  Version 1.2

                                June 2nd, 2008




CR EMEA central repository communication
                                Page 12 of 20
 Version      Date              Autor                                Comment
    0.1      01.02.2008   Klaus Menges       New Document 1st DRAFT
    0.2      06.02.2008   Klaus Menges       Changes in all sections after discussions with H. Franzen, H.
                                             Waldner, U. Kunz (alle DE), H. Binder (AT)
    0.3      07.02.2008   Hubertus Franzen   Deletion of sections 4.1 to 4.4
    1.0      15.02.2008   Klaus Menges       Finalisation of the document due to agreement of AGES, BfArM
                                             and JAZZ
    1.1      14.03.2008   Klaus Menges       Linguistic check by BfArM
    1.2      02.06.2008   Klaus Menges       Addition in regard of technical specifications in section 4.1. to
                                             4.4 (all new) and minor adjustment in section 2. This version
                                             reintegrates the former technical proposal already discussed
                                             between NCAs.




CR EMEA central repository communication
                                Page 13 of 20
Contents
1         Introduction 15
2         Scope 15
3         Change Request 15
4         Description 15
    4.1   Possible architecture      15
    4.2   Anticipated Traffic Volumes and Bandwidth Requirements   17
    4.3   Process Workflow 18
    4.4   Involved Network Traffic 19
5         Justification 20




CR EMEA central repository communication
                                Page 14 of 20
 Introduction

A review and managing tool for eCTDs has been integrated into the local IT network at a number of
NCAs. This tool usually provides specific functions complying with national requirements. Austria
(AGES), Germany (BfArM) and Slovenia (JAZMP) are using docuBridge from Lorenz Life
Science Systems, Frankfurt. Therefore, it seems to be a rational request by those NCAs to use this
already implemented system for all types of submissions and to provide to the NCA staff and
collaborating assessors one system for managing and reviewing electronically submitted
applications. Moreover, there are national obligations to decide on the most economic solution
avoiding unnecessary expenses. For centralised procedures the EMEA offers the use to the review
tool EiY selected by EMEA to get access to the data on the centralised repository. To manage the
access additional tools provided by Extedo will be necessary to install. Additional hardware needs
to be purchased by the NCAs to comply with EMEA requirements.. The above mentioned NCAs
will take the opportunity to require the open interface mentioned in the published EURS
specifications.


 Scope
This document is a formal change request and will provide a detailed description of the change as
well as a possible solution and will justify the requested change.


 Change Request
Client systems at National Competent Authorities that are not using EiY should be able to access
the EMEA Central Repository through standard ports and protocols allowing NCAs to download
metadata and view or download on request single documents, subsections and full modules as well
as full dossiers. This would allow using review tools and systems in place in a more directly way
without affecting the performance of the Central Repository itself, the available bandwith and
possibility to manage the data traffic via EudraNet II and also without downloading huge amounts
of data. The change requires an open and well defined interface to the EMEA Central Repository as
well as a (different) technical solution for accessing the metadata and document files directly.


 Description
The primary aspect is to use an open, well defined interface managing for example. specified web-
services based on standard technology, such as. http or https. The solution should be independent
from any proprietary system or software. The download of metadata and of document files should
feed server which can be accessed by an NCA. An alternative option is to access these servers via
RDP / EudraNet II for review only.


   1.1. Possible architecture
Based on an extensive technical discussion with the provider of our current review tool docuBrige,
Lorenz Life Science Systems Frankfurt , the following detailed description is to illustrate how this
can be solved. This proposal is clearly a matter of further discussion aiming to have a commonly
usable interface to access the EMEA Central Repository:
CR EMEA central repository communication
                                         Page 15 of 20
As an example:
The NCAs need to be put into the position to operate two servers in the same network segment as
the EMEA Central Repository which will replicate metadata from EMEA Central Repository Server
into a Replication System (RepS). This service may also run from outside the bespoke network
segment but might generate then performance concerns. The availability of a submission will be
indicated to the NCA installation of their national review system(NARevS) through replication of
the metadata XML components only. Should a user attempt to open the submission, a terminal
services session will be created transparently that allows the user to view the submission from the
RepS. Annotations will be stored and managed by the RepS, too.




In detail, these are the technical considerations:
1. The network speed between the Replication System and the EMEA Central Repository should
    be 1 Gbit/s.
2. The necessary hardware to operate this solution consists of two identical systems that will be
    provided. The specifications of the hardware for the two systems are as follows:
    2.1. Dimensions: 2U Rack-mounted 19” Systems
    2.2. 16GB RAM
    2.3. Dual Quad-Core Xeon CPUs
    2.4. 512MB Cache SAS RAID Controller
    2.5. 1 TB Storage Capacity in a RAID 5, Operating System in RAID 1 with 72GB, 1 Hot spare
         hard drive retained in array subsystem
    2.6. Redundant Power Supplies, Redundant Fans
    2.7. Windows 2003 Enterprise Server R2
    2.8. Probably: 2 x Hewlett Packard Proliant DL 380 G5
3. The Replication System needs to be able to download the XML files for every checked in
    submission immediately after it has been checked in through a clearly documented HTTP- or
    HTTPS-based protocol. Pending further definition of the specification of the interface offered,
    the Replication System will be polling a list of all checked-in submissions on an hourly basis.
    Should the RepS detect that a new submission has been checked into the EMEA Central
CR EMEA central repository communication
                                Page 16 of 20
     Repository, the submission metadata will be downloaded and process by the RepS.
     Consequently, the metadata will be made available to the local review system installations.
4.   All submission files should be downloadable in their unmodified form the way the applicant has
     submitted them. The checksums should still be valid. Files should be downloadable individually
     in any order.
5.   The checksums of the XML files and all document files should still be valid.
6.   For the interaction between the Replication System and the EMEA Central Repository, the
     download latency should not be considerable. The web service that is operated by EMEA
     Central Repository should be responsive and not incur latencies per file of more than 10ms. On
     average, the response latency should be significantly lower.
7.   Client systems in the National Agencies that are not using EiY should be able to access the
     Replication System through the following standard port and protocol:
     7.1. RDP: Port 3389 TCP
8.   The Replication System should be able to access local review system installations in the
     National Agencies that are not using EiY through the following standard port and protocol:
     8.1. FTP: Port 21 TCP

Some important key points to this concept are:
    The Replication System should reside on the same network segment as the EMEA Central
      Repository. There should not be a router or firewall separating the two systems. Another
      solution (residing outside the same network segment) may raise performance issues. But as
      long as mainly metadata will be downloaded this should not affect the performance
      importantly.
    Submissions will continue to be stored in the EMEA Central Repository. The Replication
      System will only duplicate the metadata. The submission documents will be downloaded
      from the EMEA Central Repository when these are opened temporarily. They will not be
      stored locally permanently.
    It should be possible for the Replication System (or any other system) to temporarily
      download complete submissions and parts thereof intact in their original form and format.
      There should not be a binary difference between any file the way it has been submitted by
      the applicant and the file that is made available by the EMEA Central Repository. The
      Replication System will validate all files against their MD5 checksums and document if they
      have been manipulated.
    Submissions will not be replicated to the NCAs. This will avoid unnecessary replication
      traffic and ensure submissions are available immediately upon check-in to the EMEA
      Central Repository. A prerequisite will be that MS allow that dossiers in the central
      procedure are not obliged to be physically stored within national borders.
    This solution can be adopted by NCAs using other review systems than EiY with minor
      efforts covered by the software maintenance package.



     4.2    Anticipated Traffic Volumes and Bandwidth Requirements

Description           Calculation Basis    Data Volume        Desirable     Comment
                                                              Bandwidth
                                                              and Packet
                                                              Latency
Replication      Per User per hour 30-64 kbit/s               Bandwidth:    Bandwidth
System                              per active                512 kbit/s    requirement
CR EMEA central repository communication
                                  Page 17 of 20
                                           reviewer                           based on 10
                                                               Latency:       concurrent active
                                                               <200ms         reviewers. Real
                                                                              bandwidth
                                                                              consumption is
                                                                              likely to be less.
EiY                  Per requested         100 MB – 4 GB       Bandwidth:     Bandwidth
                     submission                                1,5 mbit/s     required to
                                                                              ensure timely
                                                               Latency:       replication of
                                                               <70ms          submissions
                                                                              within 24 hours
                                                                              regardless of size


      4.3 Process Workflow

The process workflow is detailed below for the different stages of the availability of a new
submission.

Stage                Step Description                       Network                 Network
                                                            Communication
Submission           1      Submission is checked into      None                    None
Check-In                    the EURS application from
                            CD/DVD.
Submission           2      The new submission is made      Published               LAN at
Availability                available through the EURS      somewhere, probably     EMEA
                            application interface.          a HTTP service
                                                            hosted on TCP port
                                                            80.
Submission           3      The Replication System          RepS accesses the       LAN at
Detection                   detects the new submission      EURS application at     EMEA
                            and downloads the metadata.     HTTP TCP port 80
                                                            and downloads the
                                                            submission list.

                                                     If it detects addition
                                                     of new submission, it
                                                     downloads the
                                                     metadata to all new
                                                     submissions from
                                                     HTTP TCP port 80.
Submission       4     The new submission            The metadata is sent EudraNet II
Metadata               metadata is made available to to the review system
Replication            the local review system       installations at the
                       installations at the National NCAs through FTP.
                       Agencies.
Submission       5     The local review system       None                   None
Metadata Check-        installation detects the
in                     existence of the new
CR EMEA central repository communication
                                    Page 18 of 20
Stage                   Step Description                           Network                    Network
                                                                   Communication
                               metadata information and
                               performs a check-in into the
                               local review system
                               repository.
Submission              6      Display the availability of a                                  None
Availability to                new submission and its
NCA review                     metadata.
system.
Submission              7      A reviewer at the NCA clicks        RDP protocol traffic       Eudranet II
Access by                      on new submission to open           from the review
Reviewer                       it. The review system client        system client at the
                               establishes an RDP session to       NCA to the RepS at
                               the RepS to display the             EMEA.
                               submission transparently.
Submission              8      As the reviewer accesses the        RepS accesses the          LAN at
Viewed by                      individual pieces of the            EURS application at        EMEA
Reviewer                       submission, the individual          HTTP TCP port 80
                               pieces are downloaded from          and downloads the
                               the EURS application                individual
                               repository into the                 documents of a
                               Replication System on               submission in their
                               demand.                             unchanged form.

                               The individual documents
                               are not downloaded or
                               replicated to the local review
                               system client installation at
                               the NCA, they are only
                               displayed through a RDP
                               session.


    4.3 Involved Network Traffic

The below table details the data flow between the involved instances. Also, this information
specifies which changes on routers or firewalls may be necessary in order to allow successful
operation of the Replication System.

Client             Client           Server               Client Port     Server             Server Port
Description1       Location         Description2                         Location           and Protocol
Replication        EMEA             EURS                 1024-           EMEA               HTTP: 80
System                              application          65535                              TCP
Replication        EMEA             Local review         1024-           NCA                FTP: 21
System                              system               65535                              TCP
1
  The client system is the system that initiates the session and typically operates with a client source port in
the range of 1024-65535 TCP.
2
  The server system is the system that listens on the specified port waiting for incoming connections.

CR EMEA central repository communication
                                Page 19 of 20
                                 installation
Local review     NCA             Replication        1024-         EMEA             RDP: 3389
system client                    System             65535                          TCP



 5.    Justification
It is of major importance that interoperability can be guaranteed for IT systems running in
cooperation within the European network of Competent Authorities. This requires an open, well-
defined interface of the EMEA Central Repository.
Therefore, the use of standard protocols and non-propriety solutions is substantial to allow future
improvement.
We assume that not all Member States will be able or willing to use the solution proposed by the
EMEA or its contractor Extedo, either because of national financial obligations, local IT
infrastructure restrictions, national legal requirements or simply user requests of a homogeneous
user interface or otherwise specified functional requirements.
In addition, the proposed architecture obliges the NCAs to make substantial investments into
hardware including consequential maintenance activities.

In addition, we acknowledge a number of advantages by establishing a different technical approach:
Submissions will not be replicated to the NCAs. This will avoid unnecessary replication traffic and
ensure that submissions are available immediately upon check-in to the EMEA Central Repository.
The change will avoid potentially significant delays in the availability of new submissions to the
involved agencies since access to the submissions will be independent of replication.

The change will avoid the need for personnel and financial resources that would be necessary to
implement a National Cache Repository. These would involve:

    Storage space allocation – currently 20% of 9TB. Most likely, it would be necessary to
     adopt a fully scalable storage technology in anticipation of further data.
    Inclusion in backup and disaster recovery policies of this additional storage
    Storage maintenance
    Storage expansion upon need

No proprietary solutions will be used. This will encourage most suitable solutions for each NCA.
In addition, the alternatively proposed solution seems to be a more flexible, technically simplified
and less expensive option.




CR EMEA central repository communication
                                Page 20 of 20

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:31
posted:11/20/2011
language:English
pages:20