Get documents about "Cover Letter Example - Excel
Description
Cover Letter Example document sample
Document Sample
EU Region Question and Answer and Specification Change Request Document
Version 1.17
March 2009
Document Change History
Version Number Date Description
Version 1.0 Jul-04 Initial baseline after reviewing existing questions
Version 1.1 Sep-04 Change Request added (EFPIA)
Version 1.2 Jun-05 New Change Requests and Q&A added, plus ICH Q&A referred for regional advice
Version 1.3 Sep-05 New Change Requests 09, 10, 11, 12, 13 added
Version 1.4 Nov-05 New Change Request 14 added
Version 1.5 Dec-05 Q&A 14 added
Version 1.6 Dec-05 Updated after release of eCTD v1.1
Version 1.7 Mar-06 CRs 15-16-17-18 Added for TIGes-J-24
Version 1.8 Jun-06 Review of document carried out for TIGes
Version 1.9 Nov-07 Comprehensive addition of accrued change requests and review of summaries
Version 1.10 Jan-08 Further updates for publishing on EMEA e-subs website
Version 1.11 Jan-08 More updates for publishing on EMEA e-subs website (whilst review of CRs/Q&A
is ongoing)
Version 1.12 Mar-08 Q&As 9, 12, 15-21 added confirmed after TIGes-J-32
Version 1.13 Jun-08 CRs and QA 22 added for TIGes 33, general update after publication of EU M1
specification v1.3
Version 1.14 Dec-08 Comments from Interlinking Group on all CRs assigned to this group, and comments
from Dec. TIGes. Addition of CR-2008-12-10
Version 1.15 Mar-09 CRs added for TIGes 35. Full review of outstanding change requests and
assignments. Introduction of colour coding for open/closed CRs
Version 1.16 Mar-09 Updated after Interlinking meeting review of all assigned CRs
Version 1.17 May-09 Updated after Interlinking meeting of April 2009 and publication of updated
validation criteria May 2009, update of CP dossier requirements April 2009,
publication of Harmonisaed Guidance May 2009
Introduction
This document is a summary of questions and change control requests reviewed by the Telematics Implementation Group electronic submissions
(TIGes) on the eCTD Specification, PIM and electronic Application Forms (eAF). Questions are listed with with an approved answer. Change
control requests are listed with details of the person, company or organisation who submitted the request, along with details of the actions taken
and status of the request.
The change control requests and Q&As here relate to EU specific aspects of the eCTD and EU regional electronic submission formats. Reference
should be made to the ICH Q&A and Change Requests tracking document for matters that affect all regions (http://estri.ich.org/ectd/).
This document will be updated as the specification undergoes change control or as new questions are submitted to the TIGes.
Key to Q&A Worksheet
Each question is numbered. The question is written out in full and a reference to the change control procedure item that caused the question to be
asked is listed. An official answer is given. The approval date for the answer is listed.
Key to Change Requests Worksheet
Each change request or question received is numbered. A subset of the change request or question information is copied from the "European
eCTD Standards Q&A and Change Request Form", including the name and organisation of the person raising the request and the description of
the change or the question in full. Any comments arising during the analysis of the issue by TIGes are recorded as well as the Status and
Action(s) resulting.
CR closed : Either action progressed to completion in EU, Referred to ICH M2 and completed, Rejected and not progressed
CR open : On-going within EU or Referred to ICH M2 still on-going
# Question Answer Approval
Date
1 What is the EU's position on the use of XML for the content of the In line with the general principles of the ICH eCTD Specification Document, it is Mar-2007
submission instead of PDF and/or RTF? intended that XML will become the submission format for administrative forms
and product information documents as they contain structured data. The long
This question was generated by EU Change Request A001 term goal of this development is the normalisation of data in Module 1. As the
XML documents become available for practical implementation, they will be
introduced into Module 1 and the current file formats may be replaced after a
transition period.
2 Can further guidance be given on the acceptable formats for With respect to product information (PI) documents, the currently acceptable file Mar-2007
product information in the eCTD? formats are indicated in the EU Module 1 specification. When generating
product information files for the Centralised, Mutual recognition and
This question was generated by EU Change Request A002 Decentralised Procedures, QRD templates as issued by the EMEA should be
used. For National Procedures, refer to national guidance. The EU will be
moving into the direction of an XML approach for the exchange of product
information as part of the Product Information Management (PIM) project which
is currently being implemntated in the Centralised Procedure. For additional
details on the PIM project, see: http://pim.emea.europa.eu
3 Is the submission of application forms as XML documents It is the intention of the EU to provide XML standards for application forms. The Mar-2007
acceptable? specifications for new and variations forms have been issued and can be
accessed at
This question was generated by EU Change Request A003 http://ec.europa.eu/enterprise/pharmaceuticals/eudralex/homev2.htm. An
electronic version of the renewals form is currently under development. Refer to
national guidance regarding the applicability of the XML Application Forms.
4 What is EU's position on the use of e-signatures in the eCTD? A crucial part of pure electronic communications between the pharmaceutical Mar-2007
industry and regulatory agencies and authentication of electronic submissions
This question was generated by EU Change Request A004 or documents contained in electronic submissions will be the use of digital
signatures. Currently the EU is developing a (long-term) strategy to implement
digital signatures. As yet, digital signatures cannot be used or supported in
electronic submissions in the EU.
# Question Answer Approval
Date
5 How should an applicant handle a Type I variation within an eCTD? The Notice to Applicants group has issued a CTD Q&A regarding the placement Mar-2007
of documents within the CTD structure for Type I variations. The eCTD should
This question was generated by EU Change Request 0003 also be constructed using these principles. The Q&A (4c) can be accessed at
http://ec.europa.eu/enterprise/pharmaceuticals/eudralex/vol-
2/b/ctd_qa_05_2006.pdf
6 The EU Module 1 Specification allows 3 procedures (National, The EU Module 1 specification defines the submission types that are part of the Mar-2007
Centralised and Mutual recognition procedure). How should eCTD (V1.2.1, p10). The submission type to be used in this instance is
“Community referrals” be handled, which type of procedure should 'arbitration'. [Note, since this question was originally received, the EU has
be used respectively? added the Decentralised Procedure as an acceptable submission procedure
type.]
This question was generated by EU Change Request 0004
7 I am trying to understand the complete scope of what submissions The EU Module 1 specification defines the submission types that are part of the Mar-2007
are to be eCTD (V1.2.1, p10). All of these submission types are covered, including
required as CTD/e-CTD submissions in the EU. Follow-up Measures and PSUR submissions.
From reading some background on the topic, I think the scope may
include:
- all new applications
- all variations
- all response documents (MRP and CP response documents)
- all renewals
but does not include
- submissions of data as part of a FUM but which is not a variation
- PSUR submissions
Can you please confirm/correct this understanding.
This question was generated by EU Change Request A007
# Question Answer Approval
Date
8 I am seeking information on the structure of the eCTD response to The May 2006 version of the Notice to Applicants Mar-2007
list of questions dossier. In the eCTD EU module 1 specifications (http://ec.europa.eu/enterprise/pharmaceuticals/eudralex/vol-2/b/ctd_05-
v1.0, it is stated that responses to questions can be included in 2006.pdf) now defines a specific section in Module 1 for Responses to
Module 1. At the Annex 2 level, it is stated that response Questions, what to include in Module 1 and what to include in Modules 2-5. The
documents should be attached to the Cover Letter (1.0). However, EU Module 1 specification Version 1.2.1 now includes the section for
no recommendation is given with regard to the organisation of the Responses to Questions. The CTD guidance and eCTD specification together
table of contents, nor to the names and organisation of the files etc. should give adequate direction for applicants to construct a Responses to
Do these recommendations exist? Questions dossier in eCTD format. The filenaming recommendation is also
included in the EU specification v1.2.1.
This question was generated by EU Change Request A008
9 M3 requires each substance-manufacturer and drug product to be The ICH CTD guidance recommends that the applicant repeat the complete Feb-2008
added in a separate subfolder. How should a product be added to Module 3.2.S for each drug substance that makes up the drug product. The
the structure if it has multiple substances? ICH eCTD specification allows the repeat of the Module 3.2.S within the XML
backbone. Therefore, the applicant should create the eCTD in this way.
This question was generated by EU Change Request A009
10 Where can node extensions be used in a EU eCTD submission? Node extensions may be used where additional navigation in the XML backbone Mar-2007
is required. The primary place where they may be used is in Module 5 where a
The question was generated by ICH change request 00560 and the node extension for each study may be useful so as to allow multiple files for a
response to ICH eCTD Question 28. This is recorded as EU single study to be grouped together and separated distinctly from other studies.
Change Request A010. For Module 4 where there are multi-file reports this can also be useful. Other
places where they can be useful is in Module 1 to differentiate between PI
documents provided in PDF and those provided in RTF/Word and in Module 5
to differentiate reports associated with a different dosing regimen for the same
indication.
However, the use of node extensions should be limited to those areas where it
is critical and consideration should be given regarding the impact of the view for
the reviewer since the inconsistent use of node extensions can lead to
unanticipated effects in the cumulative view of a submission.
See separate Q&A #10 worksheet for more details
# Question Answer Approval
Date
11 In the eCTD for the EU, are applicant provided style sheets Little advantage is to be gained by the use of custom stylesheets. The XML Mar-2007
allowed? instance can only point to one stylesheet and the inclusion of a reference to a
stylesheet that is not the regional one would prevent the agency using the
The question was generated by ICH change request 00710 and the official EU stylesheet. It is therefore recommended not to submit customised
response to ICH eCTD Question 30. This is recorded as EU stylesheets.
Change Request A011.
12 Can clearer guidance be provided regarding how to use the A 'regulatory activity' is a logical unit of submission activity (eg, a Type II Feb-2008
Related Sequence attribute during the lifecycle of the eCTD? Variation) with a defined start and end point (eg initial submission to final
approval). In the eCTD world, this will consist of all the sequences that together
This question was generated by EU Change Requests A012 and make up the lifecycle of that particular 'regulatory activity‟.
QA-20070628-01
The related sequence attribute should always be left blank for new applications
or new regulatory activities (eg variations, PSURs). When submitting lifecycle
sequences within an existing activity, the related sequence attribute should be
populated with the sequence number of the first sequence in the activity,
regardless of how many sequences make up the activity. The related sequence
attribute should be considered independent of any modified file attributes in a
submission. For example, if a sequence 0010 modifies files (leaves) in
sequence 0008 and 0009, the entry for related sequence in sequence 0010
should be the sequence number that started the regulatory activity that 0010
falls within, which will not necessarily be sequence 0008 or 0009.
For examples, see the table in Worksheet QA 19.
13 ICH has issued a list of items to be checked by the applicant before A list of validation criteria specific to the EU has been prepared by the EURS Jan-2008
a submission is sent to the agency (Q&A 36). Could a list also be Implementation Group and is to be published separately on the esubmission
produced for EU regionally specific items that should also be website http://www.esubmission.europa.eu
checked?
This question was generated by EU Change Request A013
14 What is the EU regional guidance relating to the ability to cross- In the EU it is possible to refer to a file located in the same sequence or any Mar-2007
reference from one sequence to files in another sequence? previous sequence of the same eCTD. It is not possible to refer to other eCTDs.
The question was generated by ICH change request 01080 and the
response to ICH eCTD Question 37. This is recorded as EU
Change Request A014.
# Question Answer Approval
Date
15 How is the applicant advised to handle technical (eCTD If an eCTD fails technical validation, then a replacement sequence must be Feb-2008
specification) and business (content) validation changes in the provided, since an invalid sequence cannot be loaded into an agency‟s review
eCTD tool. If, once technical validation has been completed, content validation
identifies missing sections or administrative errors, then an additional new
This question was generated from EU Change Request QA- eCTD sequence should be provided (a lifecycle sequence) correcting these
20061120-01 errors, with replacement or additional new documents as required. The
applicant should not send a replacement of the original sequence.
16 The EU eCTD Specification v1.2.1 states that the variable No it is not acceptable to use a hyphen. In cases where differentiation is Mar-2008
component of filenames should be a “meaningful concatenation of needed it is suggested that the word 'point' is used in the filename eg.
words without separation and should be kept as brief and 1point5mg
descriptive as possible” but also specifies that hyphens (“-“) should
not be used within these variable components. There are
occassions where there needs to be differentiation between
documents, for example, strength (1.5mg or 15mg). Is it
acceptable that under such circumstances to use a hyphen to
differentiate between documents.
This question was generated by EU Change Request CR-
20061221-01
17 The EU eCTD Specification v1.2.1 states that the envelope element The envelope should be repeated for each member state and 'common' should Feb-2008
of MRP or DCP submissions could be assigned a country attribute not be used. The specification will be updated at the next version to correct this.
value "common" when the same sequence is being submitted to
multiple countries. Isn't it more appropriate to utilise a separate
envelope for each Member State?
This question was generated by EU Change Request CR-
20070309-01
# Question Answer Approval
Date
18 Is it necessary to include statements in the CTD/eCTD justifying the For new applications, detailed statements justifying absence of data or specific Mar-2008
absence of data? If so, where should these statements be placed in CTD sections should be provided in the relevant Quality overall summary and/or
the CTD structure? non-clinical/clinical overviews (Module 2.3, 2.4, 2.5). Note that placeholder
documents highlighting 'no relevant content' should not be placed in the eCTD
This question was generated by EU Change Request QA- structure, as these would create a document lifecycle for non-existent
20070627-01 documents and unnecessary complication and maintenance of the eCTD.
19 In Europe does the applicant need to update attributes in the eCTD Reference is made to ICH Q&A #3. It is not possible to update the attributes Mar-2008
backbone during the life an application, for example, if the nor is it necessary to attempt workarounds such as deleting existing documents
manufacturers name changes, the proposed name of the dosage and resubmitting with new attributes. The recommendation is to retain the
form is not accepted or an excipient is granted a pharmacoepial obsolete entry and to rely on the document content to explain the current details.
name.
This question was generated by EU Change Request QA-
20070816-01
20 Should eCTD Module 1 section "additional data" be empty for Yes. The Notice to Applicants CTD Q&A #4C states that the 'Additional Data" Mar-2008
EMEA centralised procedures? should only be used for information required for National, MRP and
This question was generated by EU Change Request CR- Decentralised Procedures and is therefore not applicable for the Centralised
20071002-01 Procedure except during a transition period when an old version of a DTD is
being used to support inclusion of a newly defined section of Notice to
Applicants ie. paediatric data which will be included in EU specification Module
1 v1.3 as a new section 1.10 Information relating to Paediatrics.
# Question Answer Approval
Date
21 Can content files that are included in the index.xml (ICH Modules 2- Yes. For appendices to the application form which may also be located in Mar-2008
5) also be referred to in the eu-regional.xml? module 3, it is recommended to create a leaf in the eu-regional.xml that points
This question was generated by EU Change Requests CR- to the content located in module 3 e.g. Flow Chart of the Manufacturing Sites,
20070906-01 & CR-20070927-01 and Ph.Eur Certificate. Other scenarios where this approach should be used
include type Ia and Ib variations, where content is requested in module 1 which
is available in pre-existing locations in module 3, e.g. copy of the approved
specification.
22 In the NtA Section 2.7.6 Synopses of Individual Studies requires It is acceptable either to include copies of the synopses for each study in Apr-2009
that the synopses are included in this section but the ICH eCTD Section 2.7.6 or to provide hyperlinks to synopses located in Module 5 without
Specification suggests that it would be satisfactory to provide providing copies in section 2.7.6. In either case a Listing of Clinical Studies
hyperlinks to the synopses located in Module 5. Could clarification should be provided and this should include hyperlinks to the first page of each
be provided regarding what is acceptable for the eCTD in the EU? synopsis.
This question was generated by EU Change Request CR-20090126
Node Extensions
As noted in the ICH Q&A 28, the use of node extensions is to be clarified in regional guidance. This short document
proposes how node extensions may be used in EU eCTDs.
Assumption: The applicant is not planning to create a single eCTD for Modules 2-5 that can be used in all regions. As
noted, the FDA expressly forbids the use of node extensions, therefore, if the these are inserted anywhere in Modules 2-5
the eCTD will be invalid in the US.
Node extensions are a way of providing extra organisational information to the eCTD. The node extension should be
visualised as an extra heading in the CTD structure and should be displayed as such when the XML backbone is viewed.
The following are the proposed rule for the use of node extension in the EU:
1. Node extensions must not be used where there is an ICH specified node extension
e.g. indication, manufacturer, drug substance, drug product are all ICH specified node extensions
2. Node extensions must only be used at the lowest level of the eCTD structure e.g. a node extension can be used at the
level 5.3.5.1 but must not be used at the level 5.3
It was noted that the eCTD DTD currently allows node extensions to be placed at any level, eventually, this may need to be
amended in the ICH specification.
3. Node extensions are mainly to be used to group together documents made up of multiple leaf elements
e.g. a clinical study made up of separate files for the synopsis, main body and individual appendices could be grouped
together under a node extension with the Study Identifier as its Title attribute
4. Once added, node extensions must be maintained over the entire life of the eCTD lifecycle
e.g. if a node extension is used in sequence 0000 to group files for a study report in Module 5.3.5.1, then any files
submitted in a later sequence must also be placed under a node extension, even if only one file is submitted
5. Node extensions may be nested as this is allowed by the eCTD DTD. However, as noted in point 2, the first node
extension must be at the lowest level in the eCTD structure.
e.g. in Module 5.3.7 a node extension may be added to group together files with the Study Identifier as Title attribute.
Further node extensions may be added as children of the Study Identifier node, separating CRFs from individual patient
listings.
Note : This description has been included in EU Specification v1.3
Example of how the Related Sequence should be used
Sequence Submission Description Related Comment
Sequence
0000 Original MAA application <none>
0001 Day 121 Responses to questions on the original application 0000 This is a continuation of the regulatory activity initiated in
0000 and so the related sequence points to the beginning of
that activity
0002 Day 181 Responses to further questions on the original 0000 This is a continuation of the regulatory activity initiated in
application 0000 and so the related sequence points to the beginning of
that activity
0003 Type II variation for treatment of pain indication <none> This is the beginning of a new regulatory activity and so no
related sequence is included
0004 Type II variation for a change in manufacturing site (Westferry) <none> This is the beginning of a new regulatory activity and so no
related sequence is included
0005 Responses to questions on Type II variation for the pain 0003 This is a continuation of the regulatory activity initiated in
indication 0003 and so the related sequence points to the beginning of
that activity
0006 Responses to questions on Type II variation for change in 0004 This is a continuation of the regulatory activity initiated in
manufacturing site (Westferry) 0004 and so the related sequence points to the beginning of
that activity
0007 Line extension to introduce a new dosage form (iv solution) <none> This is the beginning of a new regulatory activity and so no
that amends information provided in the original application related sequence is included
and the manufacturing change variation
0008 Updated, agreed, product information taking into account new 0003 This is the completion of the new indication (pain) activity
indication (pain)
0009 Updated, agreed product information for the iv formulation 0007 This is the completion of the new dosage form (iv
solution) activity
Note : This description has been included in EU Specification v1.3
EU eCTD Specification Change Requests
# Requestor Specification Description Comments Status Action Group Where Action
Component is Sitting
A001 eCTD EU Module 1 What is the EU's position on the use of XML for the content of the Change request added retrospectively to allow Implemented in EU Implement in v1.3:
Specification submission instead of PDF and/or RTF? tracking of the Q&A process M1 v1.3 Answered as Question #1.
Clarify in Appendix 2 row 6
(comments section)
A002 eCTD EU Module 1 Can further guidance be given on the acceptable formats for product Change request added retrospectively to allow Answered in Q&A Answered as Question #2
Specification information in the eCTD? tracking of the Q&A process
A003 eCTD EU Module 1 Is the submission of application forms as XML documents acceptable? Change request added retrospectively to allow Answered in Q&A Answered as Question #3
Specification tracking of the Q&A process
A004 eCTD EU Module 1 What is EU's position on the use of e-signatures in the eCTD? Change request added retrospectively to allow Implemented in EU Implement in v1.3:
Specification tracking of the Q&A process M1 v1.3 Answered as QAA #4.
Include a new section
alongside 'acceptable
formats' p.6 stating that
reference should be made
to national guidance on the
use of e-signatures.
A007 eCTD EU Module 1 I am trying to understand the complete scope of what submissions are to be Change request added retrospectively to allow Answered in Q&A Answered as Question #7
Specification required as CTD/e-CTD submissions in the EU. tracking of the Q&A process
From reading some background on the topic, I think the scope may include:
- all new applications
- all variations
- all response documents (MRP and CP response documents)
- all renewals
but does not include
- submissions of data as part of a FUM but which is not a variation
- PSUR submissions
Can you please confirm/correct this understanding.
A008 eCTD EU Module 1 I am seeking information on the structure of the eCTD response to list of Change request added retrospectively to allow Answered in Q&A Answered as Question #8
Specification questions dossier. In the eCTD EU module 1 specifications v1.0, it is stated tracking of the Q&A process
that responses to questions can be included in Module 1. At the Annex 2
level, it is stated that response documents should be attached to the Cover
Letter (1.0). However, no recommendation is given with regard to the
organisation of the table of contents, nor to the names and organisation of
the files etc. Do these recommendations exist?
A009 M3 requires each substance-manufacturer and drug product to be added in Change request added retrospectively to allow Answered in Q&A Answered as Question #9
a separate subfolder. How should a product be added to the structure if it tracking of the Q&A process
has multiple substances?
EU eCTD Specification Change Requests
# Requestor Specification Description Comments Status Action Group Where Action
Component is Sitting
A010 The question was eCTD EU Module 1 Clarification should be provided by all ICH regions as to whether node November 2004: The use of node extensions Implemented in EU Implement in v1.3:
generated by ICH Specification extensions can be used in Modules 2-5 should be discussed with FDA on a case by M1 v1.3 Answered as Q&A #10.
change request The ICH spec allows node extensions to be used in Modules 2-5 and their case basis. Other regions are able to accept Include on p.7 an additional
00560 use in Module 1 is a regional matter. FDA states that node extensions are appropriate use of node extensions in section with agreed text
not supported in any part of the submission and this therefore invalidates compliance with the eCTD specification (i.e.
the ICH spec. Experience on production of submissions for Europe their use is discouraged unless there is no
demonstrates that node extensions are required to deliver a navigable other feasible means to submit the
structure for Modules 4 and 5. At present this means that eCTDs are not re- information).
usable across regions and thus will create significant amounts of rework for
industry. FDA should accept node extensions in Modules 2-5. May 2005: Referred to EU and MHLW
regional guidance for specific instances where
it can be used.
June 2005: Proposal to come from EFPIA as
to how node extensions may be accepted in
the EU. Clarification: FDA strongly
discourages node extensions. ACTION: EFPIA
to circulate the proposal to TIGes-J.
A011 The question was eCTD EU Module 1 Are applicant provided style sheets allowed? May 2005 - referred to EU and MHLW for Implemented in EU Implement in v1.3:
generated by ICH Specification regional guidance M1 v1.3 Answered as Question 11.
change request Put a comment in appendix
00710 June 2005: Applicant stylesheets are 2,row 72.
accepted in the EU. However, there are
improvements to be documented and made to
the EU stylesheet to ensure that its features
meet requirements. If necessary changes are
made, the use of company stylesheets should
be strongly discouraged.
A012 The question was eCTD EU Module 1 Can further clarification be provided on the related sequence element? May 2005 - referred to EU and MHLW for Answered in Q&A Answered as Question #12
generated by Specification regional guidance
change request
00890 June 2005: To be covered by the EFPIA White
Paper on eCTD LCM.
Feb 2008 : Answered as Question #12
A013 eCTD EU Module 1 From the eCTD experience of the IWG, what parts of the Specification are Based on experience, there have been Answered in Q&A Answered as Question #13
Specification commonly misinterpreted that would prevent my eCTD message from being different interpretations of the eCTD and covered by EU
viewed by another applicant/regulator? Specification that have prevented timely Validation criteria.
exchange of eCTD submissions. Those
creating and viewing eCTD messages should
adhere to the eCTD Specifications (ICH and
regional) and consult with regional authorities
to avoid these problems. The items in the
following list already exist in the Specification
3.2, but have been summarized here to
alleviate these problems. Adherence to these
items is technically necessary to exchange
eCTD messages. Extra controls might hinder
the exchange of eCTD messages. The IWG
will continue to monitor eCTD implementation
to provide additional clarity.
May 2005 - referred to EU and MHLW for
regional guidance
June 2005: Need EU validation criteria.
EU eCTD Specification Change Requests
# Requestor Specification Description Comments Status Action Group Where Action
Component is Sitting
A014 Generated by ICH What is the EU regional guidance relating to the ability to cross-reference Answered in Q&A Answered as Question #14.
Q&A # 37. from one sequence to files in another sequence?
0001 Andrew Marr EU DTD v1.0, Experience is showing that when a number of lifecycle documents have It may be possible to have an additional Implemented in EU Opened 19-09-2004
(EFPIA) Specification v1.0 been created it is not possible to know what each sequence is about with attribute assigned to the submission type M1 v1.1 Agreed 24-09-04
physically opening the sequence documents and reading the Cover Letter. „submission description‟. This could be either
Industry is already considering requesting the vendors to provide some optional or mandatory dependent upon Dec 05: Implemented in
additional description to assist in creation of the applications and we submission type. eCTD Spec v1.1 - new
understand that at least the EMEA is adding a description to this Docubridge element 'submission-
records. It would be logical to standardise on an additional attribute that the description' added to
applicant can complete for there own records and that the agencies can envelope.
make use of in their reviews.For example an applicant could use a simple
description of „Excipient change‟ – against a Type II variation submission
type. It this way a set of simple descriptions will be built up over time that
will assist differentiation between sequence content without the necessity of
opening a cover letter.
0002 Sandoz (Ron de Application Form The EAF does not allow for the form to be combined for all member states Deferred Referred to NtA with MRFG eAF
Boer) during MRP subm. For a paper based subm this combined AF has been representatives.
requested by some and has been accepted by all EU member state R. de Boer to split the CR
agencies. This change request is made to enable the AF to be used during into those points that are
MRP submissions. Some of the requests made below are suitable for none nice to have and those
MRP subm as well. which are essential
Generic apps - It should be possible to include reference medicinal requirements
products for multiple MSs. In case of an MRP this needs to be filled in for
each MS, because the reference product marketed in each MS is different.
This change is relevant for MRP only.
It should be possible to include multiple medicinal products used in the BE
study.
All submission types. Proposed dispensing/classification - It should be
possible to select both “subject to medical prescription” and “not subject to
medical prescription”.
It should be possible to include multiple marketing authorisation holders.
CP&MRP It should be possible to include multiple persons authorised for
communication after authorisation.
It should be possible to include multiple qualified persons for
pharmacovigilance .
It should be possible to include multiple persons responsible for
scientific services.
0003 EFPIA (A. P. Marr) How should an applicant handle a Type I variation within and eCTD? Referred as Q&A to Notice to Applicants Group Answered in Q&A Answered as Question #5
Guidance provided in the Notice to Applicants for Type II variations states and in CTD Q&A.
that they should be organised according to CTD but for Type IA/IB variations
it simply states that they should be organised according to CTD, where
applicable. This suggests that there will be occasions when it is not
applicable to utilise a CTD structure and under those circumstances it will
not be possible to use the eCTD. Clarification should be provided on how to
minimise incompatibilities with the eCTD since it is impossible to construct
an eCTD that is not CTD compliant
EU eCTD Specification Change Requests
# Requestor Specification Description Comments Status Action Group Where Action
Component is Sitting
0004 Fujisawa GmbH EU Module 1 envelope Notice to applicants “Volume 2A/ Procedures for marketing More understanding of eCTD LCM required for Answered in Q&A Answered as Question #6.
(M. Hamzakadi) authorisationChapter 1/ Marketing Authorisation/February 2004” describes 4 resolution Refers to list of submission
types of Marketing authorisation procedures (p.3-6) as follows: - Centralised types (already responded
procedure - Mutual recognition procedure- Independent National procedures- Referred to Notice to Applicants Group to in CR-20070926-01).
Community referrals. In comparison with this, the appendix 1: Envelope
Element Description” of the EU Module 1 Specification v1.0 document do
not include the “Community referrals” for the element “procedure” as valid
value. The list of valid values for the “type” of procedure for the submission
should be adapted i.e. a new value “community referrals” should be added if
possible?
0005 EMEA (T. Buxton) eCTD EU Module 1 In the same way as the electronic application form permits information to be In fact, the acceptance of 'Other file formats Implemented in EU Dec 05: Implemented in
Specification submitted using XML, so the PIM DES does the same for product in accordance with the PIM DES' should be M1 v1.2.1 eCTD Spec v1.1 - accepted
information. The current EU Module 1 specification permits PDF and RTF as detailed, as this standard includes more than file formats amended.
formats for product information, but not XML. For administrative information, XML (additional documents that can be Oct 06: Updated in eCTD
however, XML is permitted. Suggestion : Include XML as an accepted format attached with the XML) Spec v1.2.1 - accepted file
for the “labelling text” item Furthermore the specification has been formats amended
updated to recognise that PIM files are
submitted in archive format as ZIP or TGZ files
that contain XML and other file formats.
0006 Datafarm (S. eCTD EU Module 1 The specifications do not provide folder structure requirements for UTIL Retain separate util folder for components that Implemented in EU Oct 06:
Kumar) Specification folder that includes STYLE and DTD folders. The screen shots are good can be submitted outside eCTD e.g. e-AF and M1 v1.2.1 Implemented in eCTD Spec
and include a STYLE folder under UTIL folder under m1/eu. See page 25 to PIM. For those regional components that are v1.2.1, cell 72, p.28
29.Please note that the STYLE folder is already present under submission always submitted as part of eCTD, use global
folder under UTIL folder e.g. eu12345/0000/util/style. In the same location util folder to obviate need for regional util
we have a DTD folder.This structure is clear and consistent across all folder. More testing required of PIM container
regions as well as ICH folder structure specifications.EMEA should consider
removing the additional util folder from eu folder under m1. All necessary
files (DTD and style sheet) should be placed in their respective folders under
one UTIL folder.Also, note that the relative path in the XML file should be
updated for both DTD and style sheet. See Page 30 onwards.Correct path
is:../../util/dtd/eu-regional.dtd../../util/style/eu-regional.xsl.
Suggestion: Keep one global (for both ICH and Regional) Util folder under
submission (sequence) folder. Util dtd - dtd files for ICH and regional style
– stylesheet for ICH and Regional
0007 IABG (T. eCTD EU Module 1 eCTD should take into consideration the ISO standard ISO/PRF 19005-1 ( This was referred to ICH where it was Rejected None
Bergsteiner) Specification PDF/A) for long-term readibility of PDF documents. concluded that PDF/A does not support the
review process for eCTDs. Response issued
as ICH eCTD Q&A 47.
0008 Spanish Agency eCTD EU Module 1 EU Module 1 Specification: Implemented in EU Dec 05: Implemented in
of Medicines Specification Element : m1-6-1-non-gmo M1 v1.1 eCTD Spec v1.1, cell 43
(José Manuel Directory : m1/eu/16-environrisk/161-nongmo p.21
Vidal Morales) eCTD EU Backbone DTD - 1.0:
Element : m1-6-1-non-gmo
Directory : m1/eu/16-environrisk/161-non-gmo (without last hyphen)
In the file eCTD EU Backbone DTD - 1.0 the directory must be named:
m1/eu/16-environrisk/161-nongmo
EU eCTD Specification Change Requests
# Requestor Specification Description Comments Status Action Group Where Action
Component is Sitting
0009 GSK (Andrew EU DTD v1.0, The New Medicines Legislation defines a new procedure for regulatory Update the attribute values in the DTDs. Implemented in EU Dec 05: Implemented in
Marr) Specification v1.0, approval in Europe, that of the Decentralised Procedure. In the current M1 v1.1 eCTD Spec v1.1 new
EAF v1.0 eCTD envelope a picklist provides for the option of Centralised, Mutual attribute in envelope.
Recognition or National. Decentralised needs to be added as an option.
Likewise for the Electronic Application Form. These need to be in place for
adoption of the new procedure in November 2005.
0010 EMEA (J. Rueda) eCTD EU Module 1 The inclusion of the PIM DES into EU Module 1 of the eCTD is planned, as An additional element “m1-3-1-pim-xxxx-y” Implemented in EU Dec 05: Implemented in
Specification per the road map (DES 2.1), for December 2005. will need to be created in EU M1 for M1 v1.1 eCTD Spec v1.1 - new
This means that the current DES container will need to be re-design in order accommodating the new PIM container when element in 1.3.1
to have a unique container for submitting PIM in/outside eCTD and to submitted within the eCTD
minimise as much as possible changes in the current eCTD EU Module 1
specifications.
To achieve this, the DES group has proposal for implementation.Currently,
when PIM is submitted inside eCTD, EU M1 has two util folders, one in EU
M1 level and another one at the root level.
The PIM DES container has an util folder as well. The new PIM container,
scheduled for DES 2.1 DEC 05 will align with EU m1 structure (in/outside
eCTD). With this new container there will be a unique "util" folder in EU M1,
the one already in there.
Note that the eCTD specifications define the location for DTDs and style-
sheets.
EU M1 specifications only contain screenshots with “util\dtd” and “util\style”.
Full proposal in Change Request proposal
0011 EMEA (J. Rueda) eCTD Specification eCTD requires a two way communication mechanism to allow flexibility and Referred to ICH - Out of Scope for EU. ICH Deferred Referred to ICH for next ICH M2
v3.2 system interoperability (EURS/PIM RS) for regulators for them to make PIM will consider for the scope of the next major major version of the eCTD.
submissions to applicants either with or without eCTD. release (ICH Change Request #1110)
To be carried forward into
eCTD Next Major Version
0012 EMEA (J. Rueda) eCTD EU Module 1 The list of submission types accepted in eCTD format listed in the eCTD EMEA to prepare a list to be confirmed at the Duplicated None
Specification specification should be in line with the list of submission types listed as eCTD interlinking.
accepted in NtA Volume 2. Currently, the 2 lists are not consistent with one Nov 2007 - still under consideration and now
another. linked to additional CRs - QA-20070906-01 &
CR-20070926-01
0013 EFPIA (A. P. Marr) eCTD EU Module 1 The structure of folders given in the EU Module 1 have „Centralised‟, „Mutual‟ The folder structures should be clarified and Implemented in EU Dec 05: Implemented in
Specification and „national‟ as folders between the root folder and the sequence number. the „procedure‟ folders deleted. This should M1 v1.1 eCTD Spec v1.1
This was not intended as part of the structure submitted in the eCTD. improve the clarity of the specification and
Three representative folder structures are provided in the specification to hence valid submissions.
represent how folders and files should be placed for each of the centralised,
mutual and national procedures. The folder structure includes „centralised‟,
„mutual‟ or „national‟. I do not believe that it was the intent that this folder,
placed between the root directory and the sequence number was intended
to be used in the submission itself. Recently, Belgium has issued guidance
for e-submission and refers to the EU specification but they have been
receiving examples where the applicants have interpreted that the folder
should be included. This will cause problems later when eCTD are received
(rather than just e-subs in folder structures‟
EU eCTD Specification Change Requests
# Requestor Specification Description Comments Status Action Group Where Action
Component is Sitting
0014 EFPIA (A. P. Marr) eCTD EU Module 1 The newly agreed ICH Q&A #38 on referring to files submitted in previous ICH Answer :At this stage of the Answered in Q&A Answered as Question #14
Specification sequences indicates that we should refer to regional guidance with respect implementation of the eCTD, the four
to allowance of cross-referral. This guidance needs to be established. Operation Attributes (new, append, replace Referred to ICH for next
ICH Question: The eCTD specification supports the ability to refer to a and delete) will remain and not be added to. major version of the eCTD.
previously submitted file, for example, by including in sequence 0005 a leaf With the existing specification it is technically
with Operation Attribute of 'new' that refers to a file submitted in 0000. Is it possible to determine that a file is not in the
possible to indicate to the reviewer that they have already received and current sequence, but is from a previous
reviewed the file before? Could an additional Operation Attribute be sequence.Suppliers of eCTD viewing tools are
considered for this type of cross-referenceing or re-use? encouraged to develop a visual way of
displaying the difference between a leaf
referring to a file in the current sequence and
a leaf referring to a file in a previous
sequence.In this circumstance note that the
list of items to be checked under Q&A No. 36
should allow for the xlink:href to refer to files in
another sequence and not prevent viewing of
the eCTD by another applicant/regulator.Refer
to regional guidance with respect to the
allowance of reference to previously submitted
files.
NB. For Europe, this Guidance has been
agreed and issued as Q&A #14.
Recommendation to update the attribute
values in the DTD at a future point
0015 PIM Core Team eCTD EU Module 1 In December 2005, a CR was requested to include PIM into the EU Module Recommended solution Implemented in EU Oct 06: Implemented in
Specification 1. This CR requested the following actions: - Add TGZ as allowed file format (this format is M1 v1.2.1 eCTD Spec v1.2.1
- Creation of element “m1-3-1-pim” to link to the PIM XML file- Identify the preferred as it is more open than the ZIP
“util” folder of the EU Module 1 as the appropriate location for PIM utilities format)
(DTD and style-sheets) - Add ZIP as allowed file format
- Amend file formats supported by the EU Module 1 to add XML as well as - Add name specification “131-pim-xxxx-
the image formats (JPEG, GIF, PNG, TIF, SVG, MathML) ar.zip/tgz ” for the PIM file
Today, PIM systems are under elaboration and practical experience - Keep Element “m1-3-1-pim”
provided some feedback about the way PIM has been integrated into the EU - Remove description the use of EU M1 “util”
Module 1. folder for PIM
Following the feedback received, we believe that there is a simpler way to - Remove definition of folder “131-pim-xxxx-ar ”
include PIM in EU Module1.
It is more appropriate to include PIM into the EU Module 1 as a single Refer to PIM DES specifications for
archive file than directly refer to the XML file. Therefore, it is proposed to: compression protocols
- Add ZIP format and TGZ format as valid file formats
- Remove the need to merge “util” folders for PIM and EU Module 1, as the
PIM util folder will be stored within the ZIP / TGZ file
- Folder “131-pim-xxxx-ar” is no longer needed because PIM will be reduced
to a single file. The name of that file will be
“131-pim-xxxx-ar.zip ” or “131-pim-xxxx-ar.tgz ” depending on the
format used
Further information included in the original change request.
EU eCTD Specification Change Requests
# Requestor Specification Description Comments Status Action Group Where Action
Component is Sitting
0016 PIM Core Team eCTD EU Module 1 The link from EU Module 1 to PIM is defined in v1.1 by using the leaf entity Implemented in EU Oct 06: Implemented in
Specification as defined by ICH in the context of eCTD. The leaf entity is defined by: M1 v1.2.1 eCTD Spec v1.2.1
- Leaf elements
- Node extension elements (which may contain other leaf and/or node
extension elements)
In the context of a PIM submission, only one PIM file needs to be attached
to the EU Module 1. Also, no concept of node extension is needed.
Therefore, the EU M1 Specification and DTD need to be updated to define
element “m1-3-1-pim ” so that it can contain only 1 leaf element
Recommended Solution:
Update Specifications and DTD to define element “m1-3-1-pim” containing a
single leaf element
0017 Bernadette Billet eCTD EU Module 1 When providing PIM and/or the XML Electronic application form, the EU They do not have to referece. Implemented in EU Implemented in EU Module
Liquent, Thomson Specification Module 1 eCTD version 1.1 specification indicates that the corresponding Check guidance is clear M1 v1.2.1 1 eCTD v1.2.1
Scientific DTDs and stylesheets should be located in the m1\eu\util directory. Should
the DTDs and stylesheets also be referenced by <leaf> elements within the
eu-regional.xml file, or is this unnecessary as simply serve to support the
XML content of PIM and/or the application form?
0018 Alex Yates eCTD EU Module 1 Please can you inform us as to the date when the updated European Addressed by EU M1 v1.3 specification and Closed None
Kendle Specification and type Module 1 specifications issued in January 2006 become mandatory for use transition plan
definition in all eCTD submissions in the EU. It takes some time to update the system
for generating the EU Module 1 XML and so this information would be
useful. In the future, consideration should be given to adding a date for
coming in to operation to the European Module 1 specifications guideline.
20060524-01 Ron de Boer If I submit sequence number 0001. What will be the operation attribute for Implemented in EU Implement in v1.3:
the eu-regional.xml in the index.xml? M1 v1.3 Include a clarification in the
This can not be replace, because the eu-regional.xml only contains the spec in Appendix row 2 -
updated parts and a replace operation will make all previously submitted operation attribute should
documents obsolete. It is also not new, because the eu-regional.xml has be 'new'. Investigate other
been submitted before. Should it perhaps be append? locations where an update
could be provided.
20060627-01 Geoff Williams, EU Module 1 DTD and Version 1.1 of the EU Module 1 DTD included country and language codes EU M1 is 1st priority – Lang/country codes for Implemented in EU Implemented in EU Module
Roche Specification, v1.2 for the planned accession of Romania and Bulgaria. Version 1.2 of the DTD RO BU in DTD, specifications and style-sheet. M1 v1.2.1 1 eCTD v1.2.1
included several changes, including the removal of these country and Assessment of required changes to align
language codes. Given the planned accession date of 1st Jan 2007, we same requirement in eAF-New eAF-Var.
believe that these codes should be in place now to allow use of the eCTD EMEA Regulatory Affairs to agree to this CR.
specification for submissions beginning on January 1st 2007.
Reinstate the country codes into the DTD. Issue an updated specification
document (or alternate form of guidance) stating that these codes are not to
be used in any submission before the formal accession date of these two
countries to the EU. On the accession date, issue a revision to the
specification (or other guidance note) allowing the use of the country and
language codes.
EU eCTD Specification Change Requests
# Requestor Specification Description Comments Status Action Group Where Action
Component is Sitting
20060627-02 Bernadette Billet, EU Module 1 DTD and When migrating the product information from Word to PIM for a product Updated in guidance - Word not to be Closed None
Liquent Specification, v1.2 managed by an eCTD how should the operations attributes be used? included in the eCTD in any case.
Version 1.2 DTD allows either a PIM submission or the Word documents in
1.3.1, not both. For a product that has previously submitted Word PI
documents these will be located under 131-spc-label-pl but with PIM it will go
under 131-pim. As such it is not appropriate to use „replace‟ since replace
should only be used on documents at the same location in the backbone. If
„new‟ is used for PIM this will still leave the previous Word documents as
being current. It is not possible to use delete either since the specification
does not support entry of leafs in both 131-pim and 131-spc-label-pl in the
same submission. Could guidance please be given for how to manage this
transition so that the PIM information is seen as new and the old Word
information is seen simultaneously as „not current‟ when a current or
cumulative view is used?
20060627-03 Andrew Marr, GSK EU Module 1 DTD and When to submit Module 3 updates as part of responses to questions with an 16-12-2008 eCTD Interlinking: The module 3 Accepted - refer to Produce an NTA CTD Q&A Interlinking
Specification, v1.2 eCTD documents should be handled in the same Interlinking Group detailing the guidance to
way that the SPC is currently handled in eCTD submit only the final agreed
Currently with a paper submission there is the possibility of submitting a - only the final agreed versions of the version of the M3
response to a question which may contain a proposal (e.g. a change to the documents should be submitted at (or just documents in the eCTD.
specification) and when that is found to be acceptable by the regulators the before) the end of the procedure. The interim (This will set a precedent
revised Module 3 content can be submitted. With an eCTD is it always versions should not be exchanged in the for an eCTD Q&A and any
expected that the Module 3 section is updated at the time of submitting the eCTD - they should be exchanged as appropriate guidance
response or can this also be delayed until it is known that the response is communications outside the eCTD. change).
acceptable? March-09 : Options for Q&A have been
drafted and are to be reviewed by the
Interlinking Group.
20060703-01 Geoff Williams, EU Module 1 DTD and Implemented in EU Implemented in EU Module
Roche Specification, v1.2 The European Commission website URL is incorrect M1 v1.2.1 1 eCTD v1.2.1
The Commission website is referenced on pages 2, 4 and 7 of Version 1.2
of the specification. The website URL is incorrect. It should be
http://ec.europa.eu/enterprise/pharmaceuticals/eudralex/homev2.htm
20060703-02 Geoff Williams, EU Module 1 DTD and Implemented in EU Implemented in EU Module
Roche Specification, v1.2 M1 v1.2.1 1 eCTD v1.2.1
The example filenames given for two documents in the specification are
incorrect as they include invalid characters (full stops). On page 26 of the
specification, in the list of the Directory/File Structure for Module 1, the
entries for items 67 and 69 on the list are invalid.
In row 67, the file path and filename is proposed as m1/eu/18-
pharmacovigilance/ 181-phvig-system/phvigsystem.VAR.EXT but it should
include a hyphen rather than a full stop before the VAR variable, e.g.
m1/eu/18-pharmacovigilance/ 181-phvig-system/phvigsystem-VAR.EXT
Likewise, on row 69 the proposed file path and filename is m1/eu/18-
pharmacovigilance/ 182-riskmgt-system/riskmgtsystem.VAR.EXT but it
should include a hyphen rather than a full stop before the VAR variable, e.g.
m1/eu/18-pharmacovigilance/ 182-riskmgt-system/riskmgtsystem-VAR.EXT
20060914-01 Aziz Diop, eAF DTD and style It is mandatory in the DTD to choose an option in the centralised procedure Deferred Refer to eAF project eAF
AFSSAPS sheet between (mandatory scope, optional scope and Generic of a Centrally
Authorised Medicinal Product). Example of a product
“Aluvia film-coated tablets”
200mg of lopinavir/50mg of rotonavir
A CHMP scientific opinion : Article 58 Regulation (EC) N° 726/2004
Date acceptance by WHO : 24-05-2006
QA-20061017-01 Hans van ICH eCTD specs v3.2 Nine Questions on the use of the eCTD in Module 3 of the CTD were This CR/Q&A was submitted to the ICH M2 Closed Discussed at ICH M2, see
Bruggen, Appendix 6 submitted. group for consideration. It has been added ICH tracking sheet for
eCTDConsultancy here for completeness and to record any details of outcome.
discussion and position taken at an EU level.
EU eCTD Specification Change Requests
# Requestor Specification Description Comments Status Action Group Where Action
Component is Sitting
QA-20061120-01 Alastair Nixon, When submitting via the centralised procedure, changes are frequently Nov-07 Part i) Accepted for Q&A Answered in Q&A Answered as Question #15
GSK required to the dossier following validation by the EMEA. At present, the Part ii) was referred to eCTD Interlinking
rapporteur and co-rapporteur have at this stage already received an initial group, they responded "It is required to submit
copy of the eCTD. the application to Rap / Co-Rap at the same
(i) How is the applicant advised to handle validation changes in the eCTD? time as to the EMEA. It is therefore not
Should another eCTD sequence be created, incorporating the suggested possible to submit to Rap / Co-Rap only after
changes, or should the original sequence be corrected? NB If an additional validation of the application."
sequence were to be provided, the assessor would need to view both
sequences in „current‟ view in an eCTD viewer. Further, if the original
submission was not 0000, in some eCTD viewing tools, it is currently not
possible to view the „current‟ content of selected sequences only – the tool
will only allow the user to view the current view of all submitted sequences.
(ii) What is the EMEA‟s view on provision of copies of the electronic dossier
for the rapporteur and co-rapporteur? Could this be delayed until after
validation, to prevent industry having to submit either updated original
sequence or 2 sequences?
CR-20061120-02 Shy Kumar, eCTD EU Module 1 The example submission directory structure for MRP (Appendix 3) may be Mar-07 After discussion, it was agreed that Duplicated None
Datafarm specification v1.2.1 inconsistent with the accompanying statement that „common‟ is the directory the examples are correct and do not require
to hold all files applicable to more than one country changing.
CR-20061221-01 Kevin Wing, eCTD EU Module 1 EU Module 1 Specification v1.2.1 (and predecessors) requests that the Sep-07 Proposed for Q&A Implemented in EU Implement in v1.3:
J&JPRD specification v1.2.1, variable component of filenames should be a “meaningful concatenation of M1 v1.3 Answered as Q&A #16.
page 7 words without separation and should be kept as brief and descriptive as Change p.7 of the
possible” but also specifies that hyphens (“-“) should not be used within specification 'file naming
these variable components. The change request applied for is to allow the convention'
use of hyphens within the variable component of filenames in the EU
Module 1.
CR-20070118-01 Harv Martens, ING eCTD EU Module 1 Examples 2 and 3 of the EU Module 1, in the context of v1.2.1, are incorrect Mar-07 Accepted to update example files Implemented in EU Implement in v1.3:
America specification v1.2.1, regarding the Specifications. M1 v1.3 Change as specified
examples EU M1 Specifications require PI documents (section 1.3.1) to be named as
follows:
CC/LL/CC-SPCDOC-VAR.EXT
For instance, a French SPC in Belgium should be named, e.g.:
be/fr/be-spc.doc
Examples 2 and 3 name such file with the prefix set to the language instead
of the country: be/fr/fr-spc.doc
Examples need to be updated so that the name of the PI documents is inline
with the EU M1 Specifications.
CR-20070122-01 Harv Martens, ING eCTD EU Module 1 Examples 2 to 4 contain a util folder within the m1/eu folder. This folder can Mar-07 Examples to be corrected, and to Implemented in EU Implement in v1.3:
America specification v1.2.1, exist to hold EU-specific files (DTDs and/or style-sheets) but in the provided include index.xml and MD5 checksum to M1 v1.3 Change the 3 examples in
examples examples, this folder contains the EU Module 1 DTD files. This is incorrect reflect valid eCTD submissions. all the locations as detailed
and can be misleading in the change request itself
CR-20070130-01 Shy Kumar, eCTD EU Module 1 The EU Module 1 Specifications, version 1.1, provided a description of the Mar-07 No change to specification. No re- Rejected None
Datafarm specification v1.2.1 field "submission-description" in the envelope, including a size limitation set instatement of max. 50 character field length.
to 50 characters. Gain practical experience with no limitation.
The EU Module 1 Specifications, version 1.2.1, has removed the information
on the field size limitation. There is no indication whether the limitation still
applies or not.
Note: A similar question has been asked in the context of the eCTD on the
length of the "title" element(Change Request 750). The initial answer was to
limit the 1024 bytes. However during one of the last meetings (June 2006), it
has been decided to remove the size limitation, and to request concise titles.
EU eCTD Specification Change Requests
# Requestor Specification Description Comments Status Action Group Where Action
Component is Sitting
CR-20070215-01 Ashley Birch, ICH eCTD Q&A 40 ICH eCTD Question Number 40 asks whether it is acceptable to submit PDF Rejected Discussed at ICH M2, see
AstraZeneca V1.4 files across all regions. Although the answer given is in the affirmative, ICH tracking sheet for
it actually goes much further than mere „acceptability‟ by appearing to make details of outcome.
V1.4 mandatory for eCTDs. Shouldn‟t V1.4 be „acceptable‟ or perhaps
„preferred‟ (if justified) rather than „mandatory‟?
CR-20070309-01 Kevin Wing, eCTD EU Module 1 Page 39 of EU Module 1 Specification v1.2.1 suggests that the envelope Sep-07 “Common” should not be an allowable Implemented in EU Implement in v1.3:
J&JPRD specification v1.2.1 element of MRP or DCP submissions could be assigned a country attribute value for the envelope. M1 v1.3 p.6 section 'Envelope' -
value "common" when the same sequence is being submitted to multiple Change wording to specify the use of multiple propose text for inclusion
countries. The change request applied for is to change the example to country-specific elements. here. Also change example
illustrate the use of multiple repeated country-specific envelopes, instead of Write a Q&A to clarify until new version is text which illustrates this on
a single envelope labeled “common”. produced p.39
See Q&A #17
20080220: See CR-
20080129-02
CR-20070316-01 N. Chandar, Take ICH Specification v3.2 Deferred Discussed at ICH M2, see ICH M2
Solutions ICH tracking sheet for
The query relates to details of the Q&A document (MS Excel spreadsheet)
details of outcome.
under Question 12. This currently states : Q. The eCTD Specification allows
for one novel excipient in 3.2.A.3. What happens if there is more than one?
To be carried forward into
A. The regulatory authority should be consulted for a solution until the
eCTD Next Major Version
change request is resolved.
Change Request 00050 stated : Description :Request 3.2.A.3 to be
changed to a repeating element. Comment : Understood and will address in
Q&A (No. 12) and then next version of DTD. Status : Approved for
specification change. Action : Specification changed to Version 3.2
Specification v3.2 just repeats the same text in dtd ( does not give an
attribute list to be captured similar to m3-2-a-2).
Could an attribute for „excipient‟ be introduced and/or a naming convention
for file naming convention be defined.
CR-20070405-01 Geoff Williams, ICH Q&A, Q&A36, ICH Q&A36, item 12 says “Ensure all the files identified by an xlink:href This CR/Q&A was submitted to the ICH M2 Closed Discussed at ICH M2, see
Roche item 12 reference exist”. This should be clarified to state where the files can exist. group for consideration. It has been added ICH tracking sheet for
here for completeness and to record any details of outcome.
The check for item 12 is ambiguous as to where the file identified in discussion and position taken at an EU level. Addressed in EU Q&A 14
xlink:href should exist. At the time this was written, we probably meant “exist as regional guidance
within the same sequence”. However, current thinking on the use and reuse
of content means that content can exist in another sequence within the
same application or (for the US at least) within a separate application Some
testing of this was carried out in the ETICS study and the results showed
that tools were not necessarily sticking to the strictest interpretation (within
the same sequence). This item description should be amended to describe
the current use and understanding of the xlink:href.
CR-20070405-02 Geoff Williams, ICH Q&A36, Item 20 ICH Q&A36, item 20 states “Ensure that leaf or node extension Title attribute This CR/Q&A was submitted to the ICH M2 Deferred Discussed at ICH M2, see ICH M2
Roche is not empty (except when the operation attribute is delete)”. It is not clear group for consideration. It has been added ICH tracking sheet for
why the parenthetical condition for delete is in place. here for completeness and to record any details of outcome.
discussion and position taken at an EU level.
It is not clear why the ICH response should be so proscriptive about the
content of the title attribute when the leaf is to be deleted. There is value in
having a title attribute even for leaf elements that will be deleted, so that the
view of a single sequence has information to aid the user. I propose that the
condition is removed so that this reads “Ensure that leaf or node extension
Title attribute is not empty”
EU eCTD Specification Change Requests
# Requestor Specification Description Comments Status Action Group Where Action
Component is Sitting
CR-20070405-03 Geoff Williams, ICH DTD, v3.2 This CR/Q&A was submitted to the ICH M2 Deferred Discussed at ICH M2, see ICH M2
Roche The approved Change Request 00050 says that the element for Module group for consideration. It has been added ICH tracking sheet for
3.2.A.3 will be made a repeating attribute in Version 3.2 of the specification. here for completeness and to record any details of outcome.
This does not appear to have been done. discussion and position taken at an EU level.
To be carried forward into
The change request says that the element for Module 3.2.A.3 (Novel eCTD Next Major Version
Excipient) will be made a repeating element. This means to me that it
should be able to appear 0, 1 or more times in the structure. The cardinality
should be denoted with a * in the element description. However, version 3.2
is as follows:
<!ELEMENT m3-2-a-appendices (leaf* , m3-2-a-1-facilities-and-equipment* ,
m3-2-a-2-adventitiousagents-safety-evaluation* , m3-2-a-3-excipients?)>
As you can see, the cardinality is indicated by a ? and this means that the
element can appear 0 or 1 times only. This change needs to be
implemented in v3.3.1 to allow further change requests about this element to
be considered.
CR-20070408-01 Dirk Beth, Mission ICH DTD, v3.2 Mission3 submits this change request with the suggestion of migrating the This CR/Q&A was submitted to the ICH M2 Deferred Discussed at ICH M2, see ICH M2
3 narrative content of submissions from PDF to XML. An XML model that fits group for consideration. It has been added ICH tracking sheet for
the needs of this industry will yield significant benefits to both sponsors and here for completeness and to record any details of outcome.
regulatory reviewers. discussion and position taken at an EU level. Part of Workplan for ICH
M2 SENTRI group to
consider
CR-20070426-01 Joe Cipollina, BMS ich-stf-stylesheet-2- The ICH STF Stylesheet currently posted gives inconsistent display results This CR/Q&A was submitted to the ICH M2 Closed Discussed at ICH M2, see
2.xsl in Internet Explorer. It seems to work in some cases but not in others. STF group for consideration. It has been added ICH tracking sheet for
files which were viewable with the older version of the stylesheet are no here for completeness and to record any details of outcome.
longer always viewable. discussion and position taken at an EU level.
CR-20070426-02 Joe Cipollina, BMS Valid-values.xml There are differences in the values listed in the valid-values file posted on This CR/Q&A was submitted to the ICH M2 Closed Discussed at ICH M2, see
the ESTRI website and the valid-values file posted on the FDA website. group for consideration. It has been added ICH tracking sheet for
here for completeness and to record any details of outcome.
discussion and position taken at an EU level.
QA-20070627-01 Alastair Nixon, One principle of the eCTD is that content that is not required for the dossier Nov-07 Q&A wording proposed Implemented in EU Implement in v1.3:
GSK is not provided, and there is no need for the applicant to provide „not M1 v1.3 Answered asQ&A #18.
applicable‟ pages. However, we have experienced occasions where we Change text on p.6 to
receive questions after EMEA content validation with respect to sections that include text from Q&A 18.
are missing in the eCTD, but where no justification has been provided. Add a statement to indicate
Is it necessary to include statements in the CTD/eCTD justifying the absence that further information
of data? If so, where should these statements be placed in the CTD national guidance should
structure? be referred to.
Further information included in the original change request
CR-20070627-01 Alastair Nixon, eCTD EU Module 1 Error in Appendix 2, suggesting that applicant uses the 10-cover section for Sep-07 Accepted for next release of Implemented in EU Implement in v1.3:
GSK specification v1.2.1 response to questions specification M1 v1.3 Remove reference in row 5,
appendix 2, p.13
QA-20070628-01 Thierry Le Ridant, eCTD EU Module 1 During a sequence 0026, we must modified SPC of the 0020 sequence and Nov-07 Both proposals are considered Answered in Q&A Answered as Q&A #12
Ethypharm specification v1.2.1 leaflet of the 0022 sequence. incorrect. A Q&A has been drafted to clarify
What should be the value of the <related-sequence> in the <envelope>? use of related-sequence attribute
The last sequence modified (0022) or it should be blank? See also CR A012
See Question 12
QA-20070628-02 Thierry Le Ridant, eCTD EU Module 1 Is it possible to have a list of value for the <agency-name> in order to Nov-07 EMEA has referred to EUTCT group Implemented in EU Implement in v1.3 if values
Ethypharm specification v1.2.1 standardised the value of this element. to define list M1 v1.3 list exists:
20080220: List to be
implemented in EUTCT - to
come from ECD
QA-20070628-03 Thierry Le Ridant, For an association of two active substance (eg Paracetamol / Sep-07 Requested to be withdrawn and Withdrawn None
Ethypharm dextroproxifen), what is the best practice : duplicate <atc> and <inn> resubmitted as a CR (subsequently submitted
element ? as CR-20070718-01)
EU eCTD Specification Change Requests
# Requestor Specification Description Comments Status Action Group Where Action
Component is Sitting
QA-20070628-04 Thierry Le Ridant, eCTD EU Module 1 DCP or MRP are followed by a national phase (PIL etc.). What should be Response provided in Best Practice guide for Closed None
Ethypharm specification v1.2.1 the value of the "procedure type" field "national" or "MRP" ? use of eCTD in MRP/DCP published by
CMD(h).
CR-20070628-01 Thierry Le Ridant, EU Module 1 Data from the envelope is displayed in blue but they are not hyperlinks. The Sep-07 Analysis undertaken of all EU Implemented in EU Implement in v1.3:
Ethypharm stylesheet use of blue text should be limited to hyperlinks stylesheets shows inconsistency. Change M1 v1.3 Stylesheet to be updated to
request accepted and will be implemented in include all black text.
next updates of each stylesheet
CR-20070711-01 Alban Dhanani, eAF-New v2.1 The current Application Form for New applications is not well designed in Deferred Refer to eAF project eAF
AFSSAPS terms of reporting of CMS involved in subsequent waves in the case of a
repeat use in the decentralised procedure. The impact on the current eAF-
New is even bigger since it is not possible to identify CMS for different
waves (wave number element missing) and a change to the dtd is needed to
make it possible.
CR-20070714-01 Kevin Wing, eAF New specification The specification for the eAF-new does not specify the use of relative Sep-07 Accepted for next release of eAF- Deferred Refer to eAF project - eAF
eCTDConsultancy filepaths for the xlink:href attribute value New specification Accepted for next minor
update of eAF
CR-20070718-01 Thierry Le Ridant, eCTD EU Module 1 In the Envelope, in the case of an association of 2 active substances, there Nov-07 Was referred to eCTD Interlinking Rejected None
Ethypharm specification v1.2.1 is no link between the <inn> element and the <atc> element. We suggest to Group "No changes required – Because there
regroup them into an <active> element which will permit to identify the link is no one to one relationship between
between atc and inn. substance and atc codes. The codes relate to
the indication of the product."
Subsequent research shows this may not be
correct.
June 2008: eCTD Interlinking: ATC code left in
EU M1 v1.3
Dec 08: Interlinking Group - there is definitely
no link between the substance and the
atc.Consideration of whether to remove the
atc from the eCTD envelope, in anticipation of
the eAF which will enable use of structured
meta-data on the submission (including the atc
if necessary).
March-09 : Close this change request. Open
new change request for deletion of ATC code
from EU Module 1 specification. Ensure that
requirements for ATC code use are defined
and progressed within eAF project.
QA-20070813-01 Phyllis Thomas, In Europe (and with the current ICH M2 eCTD specification), does the Aug-07 Requested to be withdrawn due to an Withdrawn None
AstraZeneca applicant need to update attributes in the eCTD backbone during the life an error. To be resubmitted after correction of
application? error. (Resubmitted as Q&A-20070816-01)
Further detail included in original question.
CR-20070814-01 Ann Verhoye, ICH CR 1550 Request to re-open change request 1550: this change request is closed Sep-07 Examples in two provided annexes Rejected None
FAMHP, Belgium mentioning that all filenames in module 2.3 and 3 will be mentioned in italics: were reviewed. No consensus on proposal
this means that no filename check is possible, and no standard for filenames Rejected
could be introduced. FAMHP, has made a proposal in order to foresee the
possibility for multiple documents to be submitted within module 3, so to
allow granularity, and to keep filename standards as well, therefore, the
FAMHP requests to reopen this CR and to have a look at the FAMHP
granularity proposal in order to foresee variable parts in the filenames and to
maintain fixed components as a standard. First reactions form the national
IT workgroup in Belgium were very positive.
QA-20070816-01 Phyllis Thomas, In Europe (and with the current ICH M2 eCTD specification), does the Sep-07 Question to be referred to ICH M2 Answered in Q&A Answered as Question #19
AstraZeneca applicant need to update attributes in the eCTD backbone during the life an Q&A. Refer to ICH Q&A
application? An EU Q&A to be prepared in the interim
Further detail included in original question. period
EU eCTD Specification Change Requests
# Requestor Specification Description Comments Status Action Group Where Action
Component is Sitting
CR-20070816-01 Kevin Wing, eAF-New v2.1 The specification for the eAF-new does not enable multiple meeting dates to Sep-07 Accepted for next update to the Deferred Refer to eAF project - eAF
eCTDConsultancy be included for provision of CHMP scientific advice (section 3.1) or for specification Accepted for next minor
Member State scientific recommendations (section 3.2) update of eAF
QA-20070906-01 Hans van eCTD EU Module 1 Could the TIGes clarify what <Submission> “type” attribute value should be Nov-07 Review required across other Implemented in EU Implement in v1.3:
Bruggen, specification v1.2.1 selected for the following types of submission: specifications. See also CR-20070926-01 M1 v1.3 Propose revised list. See
eCTDConsultancy 1. Annual Reassessment CR-20070926-0 - ensure
B.V. 2. Duplex registration these values are in the
3. Line Extension revised list. Also include
community referrals.
CR-20070906-01 Reinko Abels, eCTD EU Module 1 The current EU Module 1 specification does not specify that content files in Nov-07 Accepted with proposed change to Implemented in EU Implement in v1.3:
Qdossier B.V. specification v1.2.1 the ICH section can be pointed to by eCTD leaf elements in the eu- wording to page 6 of the specification. M1 v1.3 Include a short additional
regional.xml file See also CR-20070927-01 section on p.6 under
'General Architecture'.
Wording to clarify that
content filesin the ICH
section can be pointed to
from regional leaf elements
(see CR-20070927-01)
See Q&A #21
CR-20070912-01 Jose Manuel eAF-New v2.1 Orphan medicinal product information (section 1.2) applies to all types of Deferred Referred to eAF project for eAF
Simarro, AEMPS, procedures not only for centralised ones. resolution
Spain
CR-20070926-01 Juan Rueda eCTD EU Module 1 Update Specifications re list of procedure types Nov-07 Review required across other Implemented in EU Implement in v1.3:
Montes, EMEA specification v1.2.1 specifications. See also QA-20070906-01 M1 v1.3 List should be finalised:
Propose final list for
agreement by NtA
Interlinking/TIGes
CR-20070927-01 Ulrika Lantz, eCTD EU Module 1 Many post-approval submission types require a copy of an already approved Nov-07 The eCTD specification already Implemented in EU Implement in v1.3:
AstraZeneca specification v1.2.1 specification to be submitted. The basis for eCTD is to submit documents defines how to reference content from more M1 v1.3 Include a short additional
and Guidance on Type only once, but to be able to fulfil the European variation guidelines all than one leaf location. Some clarity might be section on p.6 under
1A and 1B variations required documents would need to be submitted. This change request gives added to specification. 'General Architecture'.
a suggestion on how this could be handled in eCTD. See also CR 20070906-01 Wording to clarify that
Further information included in the original change request. content filesin the ICH
section can be pointed to
from regional leaf elements
(see CR-20070906-01)
See Q&A #21
CR-20070928-01 Leo van de Notice to Applicants The ASMF guidelines state that the manufacturer and the applicant should Nov-07 This issue is referrd to the NtA Q&A Deferred Subgroup of Interlinking Interlinking
Winkel, N.V. vol 2B both submit an identical Applicant‟s Part (AP) of the EDMF. on handling of ASMF group to be established to
Organon Guidelines for eCTD files indicate that the AP should be included in Section March-09 : Subgroup of Interlinking group to produce guidance for ASMF
3.2.S of the eCTD. be established to produce guidance for ASMF
Section 3.2.S does not allow the AP to be included as one document; the
AP should be separated in parts reflecting the CTD structure and the
general parts of the AP can not be included in 3.2.S.
Conclusion: if the AP of the EDMF is included in part 3.2.S than it is not
identical anymore to the AP submitted by the ASMF.
Further information included in the original change request
CR-20071001-01 Deanna Murden, How should sponsors manage summary documents in Module 2 over the Nov-07 Referred to ad hoc group for Deferred Referred to Harmonisation Harmonisation
i3Logic lifecycle of an application? discussion and position Tasforce
EU eCTD Specification Change Requests
# Requestor Specification Description Comments Status Action Group Where Action
Component is Sitting
CR-20071002-01 Juan Rueda eCTD EU Module 1 Should eCTD Module 1 section "additional data" be empty for EMEA Feb 08: Specify in EU M1 v1.3 that this Implemented in EU Answered as Question 20
Montes, EMEA specification v1.2.1 centralised procedures? section can be used for CP in a transition M1 v1.3 Refer to CTD Guidance #4
period for submitting documents as part of a on use of the additional
new M1 structure before the latest DTD data section (i.e. it should
version is implemented (e.g. paediatrics data). not be used for CP) -
amend therefore line 68 of
the table in appendix 2
CR-20071003-01 Alastair Nixon, eCTD EU Module 1 Supporting data for variations that is not provided in m3 is currently either Nov-07 An EU CTD Q&A (4c) already exists Implemented in EU Implemented Appendix 2
GSK specification v1.2.1 provided with the cover letter (p13 of EU M1 Specification v121), or as an about the placement of additional documents M1 v1.3 row 72.
annex to the form (p14). It is proposed that all supporting data is provided in in Variations. Accepted to update EU M1
the same location, as an annex to the form. In addition, it is proposed that a eCTD specification in line with CTD Q&A
table of suggested names is added to the specification, such that these response.
documents are provided in a consistent manner.
Further information included in the original change request
CR-20071009-01 Hans van eCTD EU Module 1 Guidance is needed on how to maintain the lifecycle of Section 1.6 Nov-07 Referred to ad hoc group for Deferred Referred to Harmonisation Harmonisation
Bruggen, specification v1.2.1 Environmental risk Assessments, using the operations new, append replace discussion and position Tasforce
eCTDConsultancy and/or delete.
B.V. Further information included in the original change request
QA-20071022-01 Alastair Nixon, In the eCTD, how should an applicant handle multiple variations that occur Nov-07 Best Practice guide written for review Accepted - refer to Present guidance for Interlinking
GSK in parallel and affect the same document? and approval Interlinking Group consideration by Interlinking
March-09 : Subgroup to be established to
address all issues of variation, in the context
of the new Variations Regulations. This CR will
be addressed within this group.
CR-20080129-01 Geoff Williams, EU M1 stylesheet The current stylesheet displays the full structure of the Module 1, whether Rejected None
Roche the displayed sections have content or not. This is a little confusing as it
gives the impression of much more information than is really present. In
addition, some sections are mutually exclusive and others only apply for
particular procedure types.
The display of the complete structure is not consistent with the behaviour of
the ICH stylesheet, which only displays sections that have content.
Proposal: Change the stylesheet so that it only displays sections that have
content.
EU eCTD Specification Change Requests
# Requestor Specification Description Comments Status Action Group Where Action
Component is Sitting
CR-20080129-02 Geoff Williams, EU Module 1 DTD, eu- A previously submitted CR (20070309-01) proposed the prohibition against Feb 08: New change request to be submitted Withdrawn None
Roche envelope.mod and the use of “common” as an acceptable country identifier in the EU Module 1 by EFPIA proposing a 'softened' approach
Specification, v1.2.1 envelope. This CR seeks to clarify the use, or otherwise, of the country where the country identifier 'common' can be
identifier “ common” for content files in the EU Module 1. used in certain circumstances.
Currently, no clear guidance exists about the correct use of the country
identifier “common” when creating an EU Module 1 eCTD, particularly in
relation to the application of this country identifier to content files. This has
led to an inconsistency in usage of the value for the country attribute.
A country identifier is used for content included in sections of Module 1 that
can contain country specific content. The original intent of the “common”
country value was to provide some means of identifying content that was
used submitted in a section that can contain country specific information but,
in this particular submission, is reused by several countries.
Propsal:The submitter of this CR proposes completely removing the country
identifier “common” from the list of acceptable country identifier values.
Specific guidance should be included about to how to manage content that
is used in more than one country.
CR-20080129-03 Geoff Williams, eCTD Specification ICH eCTD Q&A 46 states “all regions have agreed to accept PDF 1.4. Feb 08: New proposal with simpler wording to Implemented in EU Implemented on Page 5
Roche v1.2.1 Please consult regional guidance to submit other versions of PDF.”. come from EFPIA, clarifying further the use of M1 v1.3
Clarification is required about the acceptability of versions of PDF other than PDF versions.
PDF 1.4 in the EU region. N.B. EU Validation Criteria specify v1.4 (but
warning only).
It is noted that the planned EU eCTD Validation Criteria will include a
statement that all files should be PDF 1.4. All PDF files included in the eCTD should be
v1.4 except where there is an agency specific
However, it is also noted that some specific EU NCAs require the use of requirement for a later version eg. for an
Acrobat Forms and other documents created in later versions of PDF and application form.
that do not function as needed if created in a lower version of PDF. Specific
attention is drawn to the MHRA Application Forms that require Acrobat 7.1
(PDF 1.6) and the EMEA Paediatric Implementation Plan Application Forms
that require Acrobat 8 (PDF 1.7).
Proposal: Adoption of the following statement in the EU Module 1
Specification document.
PDF files submitted as part of an eCTD must be at least version PDF 1.4.
Earlier versions of PDF must be converted to at least PDF 1.4. Files created
with later versions of PDF may be submitted as part of a European eCTD.
CR-20080218 Andrew Marr, GSK The Best Practice for eCTD in MRP/DCP (draft v0.4) includes as To be included in eCTD v1.3 2008 Implemented in EU Implemented in Appendix 2
requirement to provide a table as a file under 1.0 Cover Letter that keeps M1 v1.3 Line 4
track of the sequences, when and when they have been submitted. This will Format and layout of the table to be defined
allow each NCA to know that any „missing‟ sequences are not relevant to by eCTD Interlinking Group.
them and hence have not been submitted. The example tables in the
guidance have been developed in Word and would be expected to be
submitted as a PDF. However, when an earlier version of the guidance was
provided to vendors for comment, several made a request that this table is
able to be supplied as an xml file as this would allow it to be generated
automatically by the building tools. Production of a word-processed file
would be inefficient.
CR-20080303 Claire Holmes, EU M1 Specification The proposed new EU M1 CTD Guidance from NtA includes a new section Implemented in EU Included in DTD and
EMEA v1.2.1 1.10 Information relating to Paediatrics. The eCTD specification should be M1 v1.3 througout the document
updated in line with the new CTD structure.
EU eCTD Specification Change Requests
# Requestor Specification Description Comments Status Action Group Where Action
Component is Sitting
CR-20080415 Ms Nadine EU Module 1 As a manufacturer for plasma products, CSL have a centrally authorised Refer to eCTD Interlinking Group to write Accepted - refer to EMEA to draft guidance Interlinking
Schwarz specification, Plasma Master File (PMF). Following the centralised authorisation of the interim guidance on which submission type to eCTD Interlinking
CSL Behring AG Appendix 1 "Envelope PMF the PMF 2nd Step Procedure must be performed. In this 2nd Step use. Group
Element Description", Procedure, the PMF certificate must be submitted for each product in order March-09 : Draft guidance is under
therein element = to make the link between PMF and the product's marketing authorisation. development by EMEA, taking into account
submission and According to the "Guideline on Plasma Master File (PMF) And Vaccine the new regulations, and will be circulated to
attribute = type (p. 10) Antigen Master File (VAMF) “Second Step”" this is NOT a variation the Interlinking group for endorsement
submission.
If this is done for an existing eCTD, there is no adequate submission type
defined in the Module 1 Specification to describe this submission.
Recommendation: Define an additional valid submission type for a PMF 2nd
Step Submission, such as "pmf-2nd-step".
CR-20080514 Kevin Wing, EU Module 1 The example provided for the application number element description on Refer to eCTD Interlinking Group for Open Complete the survey for TIGes
eCTDConsultancy Specification v1.2.1 page 9 of the guidance is in the format of an EMEA Marketing Authorisation discussion and drafting of Q&A on what is MS on requirements for
Number i.e. EU/1/00/150/001 and not an EMEA Procedure Number such as expected in that field. Draft survey for MS on application/procedure
EMEA/H/C/XXX/X/XX. requirements for application/procedure number, and use of this
number, and use of this element. element. Once results have
The accompanying description that this is the “number assigned to the been gathered, produce a
application by the receiving agency” suggests that what is meant here is the new change request as
procedure number, and not the marketing authorization number (which appropriate requesting a
would only be assigned upon approval and would also be strength-specific). change to the way
This is supported by the explanation provided on page 14 of the EMEA‟s application numbers are
recently released Q&A on eCTD Implementation (7th February 2008). captured in the envelope.
Change the example for the application number element from: Based on the technical
EU/1/00/150/001 guidance given in the new
to eCTD specification,
EMEA/H/C/XXX/X/XX. produce associated
And add a clarification to the description that the number required for this business guidance on how
value is the procedure number. each application number
element is to be used. (KM
to complete survey and
submit CR as appropriate
in collaboration with
industry)
Produce interim guidance
relating to current EU M1
specification and the use of
application numbers,
before such time as a new
EU M! version is available.
EU eCTD Specification Change Requests
# Requestor Specification Description Comments Status Action Group Where Action
Component is Sitting
CR-20080514-01 Anne Mieke EU Module 1 Since this information is mandatory in the cover letter, variation and renewal Refer to eCTD Interlinking Group for Open Complete the survey for TIGes
Reijnders, Specification v1.2.1 application form and is useful for retrieving information from the eCTD discussion and drafting of Q&A on what is MS on requirements for
eCTDConsultancy lifecycle it would be beneficial to add the Marketing Authorization Numbers expected in that field. Draft survey for MS on application/procedure
to the EU M1 envelope information requirements for application/procedure number, and use of this
number, and use of this element. element. Once results have
been gathered, produce a
new change request as
appropriate requesting a
change to the way
application numbers are
captured in the envelope.
Based on the technical
guidance given in the new
eCTD specification,
produce associated
business guidance on how
each application number
element is to be used. (KM
to complete survey and
submit CR as appropriate
in collaboration with
industry)
Produce interim guidance
relating to current EU M1
specification and the use of
application numbers,
before such time as a new
EU M! version is available.
CR-20080514-02 Kevin Wing, EU Module 1 The EU Module 1.2.1 specification only includes instructions relating to 1.3.1 TIGes 6 March 09 : Progress revised Q&A that Open CR originator to draft a TIGes
eCTDConsultancy Specification v1.2.1 SPC, Labelling and Package Leaflet identifiers and Language/Country incorporates 'refer to regional guidance' for proposal for the
Codes in the context of document filenames/folder paths. This information is ICH Q&A 57 relating to the use of xml:lang information, to be included
also required as XML metadata and this change request is to update the in the next version of the
specification to clarify this requirement. specification.
CR-20080514-03 Anne Mieke EU Module 1 Since sequence numbers do not have to be used in sequential order it The Cover Letter and tracking table if Rejected None
Reijnders, Specification v1.2.1 would be beneficial to add the submission date back into the EU M1 appropriate should be used to track the date -
eCTDConsultancy envelope information. it is not useful ot have it in the envelope.
CR-20080610 Andrew Marr, GSK EU eCTD Validation EU validation criterion #37 defines that no file should have been scanned at Implemented in EU Implemented in EU
Criteria a dpi of more than 300. The ETICS testing demonstrated that it does not validation criteria v2.0 validation criteria v2.0
appear possible to assess a pdf file and determine what the scan resolution
used to produce the file actually was. It is proposed that this criterion is
deleted.
CR-20080610-01 Andrew Marr, GSK EU eCTD Validation EU validation criterion #45 refers to EU Q&A as its reference. This is Check all references Implemented in EU Implemented in EU
Criteria incorrect as it is ICH Q&A 36 - change reference. validation criteria v2.0 validation criteria v2.0
CR-20080610-02 Andrew Marr, GSK EU eCTD Validation There is an inconsistency between EU validation Criterion #11 and #18 Change criterion #18 to indicate that the title Implemented in EU Implemented in EU
Criteria relating to the title field when the delete operation is used. #11 states „Every should be included when delete is used, but validation criteria v2.0 validation criteria v2.0
leaf or node extension 'title' attribute is not empty‟. #18 states „If the value of included a statement to indicate that this is not
the operation attribute is delete,……title is not required…..Consistency consistent with the ICH criterion #20.
should be introduced. Create an ICH CR to indicate that ICH criterion
Additionally the wording of #11 could be improved to state “No leaf or node #20 should refer to regional guidance.
extension 'title' attribute is empty”
Even if this is changed then there is still inconsistency.
Either – agree that the title should be included when delete is used –
change #18 but this would require a change to ICH Q&A36 #20
Or – agree that title remains optional and therefore modify #11 to provide an
exception when the delete is used.
EU eCTD Specification Change Requests
# Requestor Specification Description Comments Status Action Group Where Action
Component is Sitting
CR-20080514-04 Kevin Wing, EU Module 1 The concept of the Regulatory Activity was introduced within the EU 3 years Refer to guidance on use of related sequence, Accepted - refer to Refer to Q&A Interlinking
eCTDConsultancy Specification v1.2.1 ago and has been presented/discussed at conferences, implemented by which has been improved and is robust with Q&A
some vendors and is included as a term in the EMEA‟s Q&A Relating to EU M1 v1.3.
Practical and Technical Aspects eCTD Submission (7th February 2008). EMEA Q&A guidance should be amended to
refer to EU guidance on use ofrelated
The “Example of the use of the Related Sequence” section on page 11 of sequence, but to indicate that application
the EU M1 eCTD guidance describes use of the related sequence element number is used in addition. Dependency on
to groups eCTD sequences into 3 Regulatory Activities (an MAA, a technical CR-20080514 and the drafting of guidance for
variation and a labelling change variation). use of and requirements for application
numbers by all agencies.
In the afore-mentioned EMEA Q&A document, it is the Application Number March-09 : Confirmed as pending, awaiting
(procedure number) that is described as the “envelope element which is TIGes action on use of Application/Procedure
used to group together submissions relating to a particular regulatory Numbers
activity”.
Could the TIGes provide feedback/guidance on whether the Application
Number or Related Sequence is the element used to group sequences
together within a Regulatory Activity. If the Related Sequence is not used for
grouping together Regulatory Activities, could the TIGes comment on what
value this element is adding to the EU specification?
CR-20080514-05 Anne Mieke EU Module 1 The application number element description on page 9 of the guidance See CR-20080514-04 -guidance to be Open Complete the survey for TIGes
Reijnders, Specification v1.2.1 states that this is the “number assigned to the application by the receiving produced. MS on requirements for
eCTDConsultancy agency”. Given the explanation provided on page 14 of the EMEA‟s recently application/procedure
released Q&A on eCTD Implementation (7th February 2008) we presume number, and use of this
that for Centralised Submissions, the EMEA procedure number is meant element. Once results have
here (see accompanying change request). been gathered, produce a
new change request as
In DCP, MRP and especially National Procedures already several numbers appropriate requesting a
are used to identify a submission. To avoid misunderstanding clear change to the way
definitions and guidance of what number to use where is needed. application numbers are
captured in the envelope.
For instance in The Netherlands for a MRP submission the MRP procedure Based on the technical
number and a case number has to be used (and of course the MA number). guidance given in the new
eCTD specification,
Could the TIGes provide feedback/guidance on the definition of the produce associated
Application Number element for MRP, DCP and National Procedures. business guidance on how
each application number
element is to be used. (KM
to complete survey and
submit CR as appropriate
in collaboration with
industry)
Produce interim guidance
relating to current EU M1
specification and the use of
application numbers,
before such time as a new
EU M! version is available.
CR-20080627 NMs Nadine EU M1 Specification As a manufacturer for plasma products, CSL have eCTDs for products Article 61(3) exists as a submission type in the Rejected
Schwarz, CSL v1.3 which are registered under the Central Procedure and the Mutual EU M1 specification v1.3
Behring AG Recognition Procedure. For either procedure, the CMD(h) STANDARD
OPERATING PROCEDURE PROCEDURE FOR ARTICLE 61(3) CHANGES
TO PATIENT INFORMATION (Rev. 1, July 2007) is applicable. By this
procedure, administrative changes to the product information, such as
corrections of typographical errors, may be notified to EMEA or RMS instead
of submitting a variation.
If this is done for an existing eCTD, there is no adequate submission type
defined in the Module 1 Specification to describe this submission.
EU eCTD Specification Change Requests
# Requestor Specification Description Comments Status Action Group Where Action
Component is Sitting
CR-20080703 Andrew Marr EU M1 Specification The list of submission types included in the eCTD Module 1specification As part of the creation of EU Module 1, v1.3 Accepted - refer to Produce Q&A and update Interlinking
(EFPIA) v1.3 v1.3 does not include Repeat Use Procedure. What submission type should and in conjunction with the development of the Q&A and include in Best Practice Guidance
be used for this submission? eCTD in MRP/DCP Best Practice document updated Best
consideration was given to the creation of Practice Guidance
„Repeat Use Procedure‟ as a specific
submission type. After deliberation, this was
not accepted. However, the Best Practice
Guide did not include any recommendation for
which submission type should be used. In
discussion at the eCTD Interlinking Group it
was proposed that „Initial MAA‟ should be used
and that a Q&A should be prepared to this
effect.
The submission type that should be used is
„initial-maa‟ since this is the initiation for the
new Concerned Member States. The
submission description should be „Repeat Use
Procedure‟.
March-09 : Interlinking agreed that as an
interim, a Q&A would be produced and in the
CR-20080703-01 Andrew Marr EU M1 Specification The list of submission types included in the eCTD Module 1specification As part the development of the eCTD in Accepted - refer to Produce Q&A Interlinking
(EFPIA) v1.3 v1.3 does not include a specific submission type for a change of the MRP/DCP Best Practice document it was Q&A
Reference Member State in MRP. What submission type should be used for agreed that „Change of RMS‟ would utilise an
this submission? existing submission type and that a Q&A
should be prepared to this effect.
The submission type that should be used is
„supplemental-information‟ and the submission
description should be „Change of Reference
Member State‟
March-09 : CMD(h) reviewing guidance on
change of RMS. Q&A to be produced to
explain how change should relate to eCTD.
CR-20080806 Remco Munnick, EU M1 Specification In the text of page 16, under nr 4 it mentions: 'Note that the tracking table Include the common folder in the examples for Accepted Implement in next version Interlinking
Sandoz v1.3 required with MPR/DCP submissions should be located within a 'common' MRP on page 37 of EU M1 specification.
directory, with the filename 'tracking.pdf' or 'tracking.xml‟. Include the tracking table in the example for Also update the example
However when you look to the examples for MRP and DCP, the tracking MRP and DCP on page 45. XML on p.45
table is not included in the folder m1/eu/10-cover/common. March-09 : Confirmed by Interlinking
Also in the screenshot on page 37, there should be a common folder under
m1/eu/10-cover, which is missing.
CR-20080903 Alastair Nixon, EU M1 Specification Copy requirements for eCTDs should be different from other electronic Electronic copy requirements for Type IA and Implemented in new Dossier requirements
GSK v1.3 dossiers – all CHMP members should get an electronic copy of everything, IB variations are split by NeeS and eCTD. For dossier requirements updated April 2009
including Type IA/IB variations – otherwise future lifecycle operators will be NeeS, they stay as they are. For eCTD, the
invalid. requirements for Type IA and IB variations
The current copy requirements do not differentiate between eCTD and mirror those for Type II – i.e. “Other CHMP
NeeS. For Type IA and IB variations, only the Rapporteur requires 2 members: 1 electronic copy”.
electronic copies,
other CHMP members get nothing. However, a Type IA variation can
amend a significant piece of content in the dossier. For example, a
Category 12a variation to tighten a specification will modify S4.1. A future
Type II variation could result in a replacement active specification being
submitted, but the if the original change had not been uploaded by an
agency, the modified file in the second change will be invalid. In addition,
any countries not uploading all sequences will get an incorrect „current view‟
for the application.
EU eCTD Specification Change Requests
# Requestor Specification Description Comments Status Action Group Where Action
Component is Sitting
CR-20080903-01 Alastair Nixon, MRP/DCP Best The requirement for a cover letter in local language means that applicants For submissions not requiring an application Implemented March 2009 CMD(h) press
GSK Practice Guidance preferring to centralise electronic dossier production, or following the form, a single „common‟ English language release included statement
preferred „Comprehensive model‟ for eCTD in MRP/DCP must get a cover cover letter is acceptable in all MS.
letter translated into all European languages before building the dossier. Identified as a hurdle for eCTD
For submissions requiring an application form, this is unavoidable, since the implementation. Cover letter is not covered by
form contains details of the MAH, and local contacts etc. However, for follow legislation, but nevertheless some MS have
up measures, or simple administrative submissions, the requirement to get a requirements for local laguage versions. HMA
cover letter translated up to 23 times is onerous and does not add value to to try to persuade individual agencies to relax
the dossier (NB the rest of the content is likely to be in English). Could a requirements for a cover letter in the local
„common‟ English language cover letter be used for such submissions? language. This should not be a requirement -
one cover letter in EN should be accepted by
all MS. ACTION: Applicants to inform
Interlinknig group of any MS asking for local
language cover letters, and the group will try
to dissuade these MS. Also indicate if these
MS have local letter templates or are asking
for the general cover letter to be translated.
Also include information as to whether the MS
ask for this cover letter to be in the eCTD.
March-09 : Updated national requirements
table should address but press release will
indicate that there should be no additional
national requirements. Consideration to be
given to identification of point of contact is
NCAs request/require additional national
specifics.
CR-20080909 Leigh Sandwell, eCTD Guidance Current guidance requires that statements justifying absence of data in the Recommend that empty Module 1 Sections do Implemented in Agreed wording include in
Pfizer eCTD should be provided in the QOS, non-clinical and clinical overviews, as not require a justification statement to be Harmonised Guidance Harmonised eCTD
applicable, and that no placeholder documents are required in the eCTD included in each section and the Q&A Guidance v1.0
structure. The guidance should be updated to clarify how to deal with empty document is updated to reflect Module 1.
sections of Module 1 and any potential justification that may be required.
Approach to M1 is different than for other
modules, as M1 should always be populated
(even with 'not applicable' statements) as a
legal requirement. Another proposal is that
only justifications should be required - simple
statements of not applicable should be
included in the cover letter. Revisit this
discussion as currently no agreement.
March-09 : Principle that empty sections
where no justification for absence is required
should be listed in the Cover Letter. Proposal
to provide statement in Harmonised eCTD
Guidance. Wording to be confirmed by
Interlinking Group.
April -09 : decision modified and agreed
statement included in Harmonised guidance -
Section 3.2.1
EU eCTD Specification Change Requests
# Requestor Specification Description Comments Status Action Group Where Action
Component is Sitting
CR-20080909-01 Dietmar Boecker, eCTD Guidance Guidelines on the submission of the EU-RMP require a stand-alone format Accepted Refer to EMEA eCTD EMEA
Bayer Schering of the document including all annexes to be located in eCTD Module 1.8.2. Business Team for
This is in contradiction to the ICH eCTD requirements, that mandates a discussion and
different location for most of the annexes. confirmation, and amend
In section 4.4 of the EU-RMP guideline EMEA/CHMP/96268/2005 it is all guidance documents as
outlined that the EU-RMP "should be provided (...) in a stand-alone format appropriate.
allowing circulation to, and evaluation by pharmacovigilance and risk
management experts". The same requirement is defined by the Pre-
Submission guide in response to question 36. The template for the EU-RMP
(EMEA/192632/2006) lists 8 Annexes, which should be provided in eCTD
Module 1.8.2 together with the main body of the RMP. However, some of the
annexes like the current SPC have already well defined locations in other
Modules of the eCTD.
For the location of the EU-RMP annexes it is proposed to update the
guidelines mentioned above, so that applicants should cross refer from the
EU-RMP to other locations of the eCTD where appropriate. With the
exception of the annex 1, all annexes would be affected:
CR-20081023 Remco Munnik, EU Module 1 Discrepancy in guidance on where to store additional documentation for The CTD Q&A 4c is correct and should be Accepted - refer to Review content of Renewal Interlinking
Sandoz (EGA) Specification v1.3 variations that do not have a place in CTD structure. No guidance for observed - Where documents cannot be Q&A Guidance
renewals is available. assigned to specific CTD-defined locations
then they should be included in 1.2 Application
Form. These might include declarations,
certificates, justifications etc. Where possible,
they should be organised according to the
Annexes for the Application Form for new
products (Annexes 1 to 22). Where
documents cannot be assigned to one of the
annexes then it is appropriate to place them
after the annexes. The „Additional Data‟
section of Module 1 should not be used except
for country-specific information.
The EU M1 specification should therefore be
amended in the next version to reflect this,
and a Q&A is required to confirm this, and also
to confirm that the same approach should be
taken for renewals.
March-09 : Interlinking to confirm that referral
to Renewal Guidance is sufficient
CR-20081008 Andrew Marr, eCTD specification The guidance just issued by QRD regarding production by the applicant of Dec 08: EMEA meeting held to discuss issue - Accepted File naming convention EMEA
GSK (EFPIA) v3.2 the PDF for final labelling is incompatible with the eCTD and will lead to conclusion that requirements for EMEA PDFs agreed. Publication in User
duplication of effort. arise from the EMEA EPAR publication guide on how to generate
In the longer term EMEA must align their requirements and if there is process, and eCTD filenaming requirements PDF versions of Product
business logic for the filename as per the EPAR proposed name then an EU have a different purpose and support a Information' and 'Questions
specification change may be justified with the inclusion an appropriate different proess (review) and therefore and answers relating to
filename that meets ICH general filename requirements. requirements cannot be aligned until Q3 2009 practical and technical
when the EMEA publication process is re- aspects of the
In the short-term there is an urgent need for clarification as to how an designed. This conclusion was not redily implementation' to be
applicant can submit product information inside and outside the eCTD, for all accepted by industry - either alignment must updated
submission types without duplication of effort or risk of failure to validate or be sought, or at least clear guidance should
accept be provided as to how to manage in the
meantime, and a clear plan for resolution
should be presented by EMEA
March 2009 : EMEA updated PDF naming
convention within 'User guide on how to
generate PDF versions of Product Information'
to be consistent with eCTD. Practical Q&A
needs to be updated to also reflect this
change.
EU eCTD Specification Change Requests
# Requestor Specification Description Comments Status Action Group Where Action
Component is Sitting
CR-20081210 Gerhardt EU Validation Criteria So far, the EU Validation Criteria do not verify the correctness of the overall Introduce to the EU Validation Criteria an Implemented in v2.1 Validation criteria v2.1
Neurauter, Extedo checksum in the provided index-md5.txt. Guidance is given by the EMEA to additional issue: “The checksum of the of validation criteria published
provide this checksum in the cover letter, however, the possibility to verify index.xml should be calculated by a validation
the MD5 with the EURSvalidator is not given. tool and compared with the checksum
Authorities not using the EURSvalidator perform checks with tools verifying provided in the index-md5.txt.” In case of
the overall checksum. We received responses from clients that submissions invalidity the recommended severity should be
are rejected due to invalid values in the index-md5.txt. However this issue is A.
not part of the EU Validation Crieria. TIGes 6 March 09 : Agreed to progress as an
In case of MRP/DCP we encounter troubles that submissions are accepted urgent change and actioned to the EURS
only in regions the EURSvalidator is used. group
CR-20090126 NtA Volume 2B The ICH M2 eCTD specification and Notice to Applicants Volume 2B provide TIGes 6 March 09 : Principle supported. Action Answered in Q&A Answered as Question #22
Section 2.7.6 different information concerning how to deal with the Synopses of Individual to Interlinking Group to progress. Suggested
Studies in Section 2.7.6. The guidance should be harmonised to provide a that option of either hyperlinking to or inclusion
similar message in both the CTD and eCTD and avoid confusion. of synopses.
The NtA guidance states: Recommend that the NtA guidance is updated
2.7.6 Synopses of Individual Studies to reflect the Section 2.7.6 guidance in the
The ICH E3 guideline (Structure and Content of Clinical Study Reports) ICH M2 eCTD or clearly reference this
suggests inclusion of a study synopsis with each clinical study report, and difference between the paper and electronic
provides one example of a format for such synopses. outputs.
This section should include the table entitled Listing of Clinical Studies, March-09 : Interlinking agreed that
described in guidance for Module 5, followed by all individual study hyperlinking should be an option for
synopses organised in the same sequence as the study reports in Module 5. applicants. Q&A to be produced.
It is expected that one synopsis will be prepared per study for use in all April-09 : Interlinking group endorsed a Q&A
regions, and that the same synopsis will be included in this section and as for publication
part of the clinical study report in Module 5. The length of a synopsis will
usually be up to 3 pages, but a synopsis for a more complex and important
study may be longer, e.g. 10 pages. Within the individual synopsis, tables
and figures should be used as
appropriate to aid clarity.
But the ICH M2 eCTD guidance states:
These synopses should already be located in the Clinical Study Reports in
Module 5 and should not, therefore, be repeated in
Module 2. It is considered sufficient to provide hyperlinks from the listing
of the studies, located here, to the locations of the synopses in Module 5.
Related docs
