esubmission.ema.europa.euesubmission.ema.europa.eu/tracking tables/copy of eu_… · xls file ·...

Version Number Date DescriptionVersion 1.33.5 10/1/2013 Reversioned for publication

Version 1.33.5 9/9/2013 CCB: disposition noted for new CRs

Version 1.33.4 9/8/2013

Version 1.33.3 7/11/2013

Version 1.33.2 7/8/2013 pre-CCB mtg: CR updates for Harmonisation Group, new CRs added

Version 1.33.1 6/11/2013

Version 1.33 5/31/2013

Version 1.32.1 5/22/2013 pre-TIGes mtg (post-CCB): New CRs added

Version 1.32 4/9/2013

Version 1.31.7 2/14/2013

Version 1.31.6 2/13/2013

Version 1.31.5 12/10/2012 pre-CCB mtg: New CRs added (no revision post-CCB)

Version 1.31.4 11/27/2012 CCB mtg: Status updated for new CRsVersion 1.31.3 rev 11/26/2012 pre-CCB mtg: New CRs addedVersion 1.31.2 10/11/2012 CCB mtg: Status updated for new CRsVersion 1.31.1 10/10/2012 pre-CCB mtg: New CRs added

Version 1.31 10/10/2012 post-TIGes meeting: for publicationVersion 1.30.4 10/4/2012 pre-TIGes meeting: new CR received in last quarterVersion 1.30.3 9/24/2012 CCB mtg: Status updated for some in process CRs

Version 1.30.2 7/19/2012 CCB mtg: Status updated for new CRVersion 1.30.1 7/18/2012 pre-CCB mtg: New CR addedVersion 1.30 7/2/2012 Updates made, new Q&A to publish .Version 1.30 draft 6/8/2012

Version 1.29.5 5/16/2012 pre-TIGes meeting: new CRs received in last quarterVersion 1.29.4 5/7/2012 pre-CCB mtg: New CR added, updates from InterlinkingVersion 1.29.3 12-Apr-12 CCB mtg: Status updated for new CRs

Version 1.29.2 12-Apr-12 Revisions for consolidated CRs; new CRs addedVersion 1.29.1 8-Mar-12 pre-CCB mtg: New CRs addedVersion 1.29 26-Apr-12 Updates from TIGes, new Q&As & approval to publish

Version 1.29 draft 28-Feb-12

Version 1.28.3 9-Feb-12

Version 1.28.2 9-Feb-12

Version 1.28.1 10-Jan-12 CCB mtg: Q&A received from Harmonisation Group accepted and added.

Version 1.28 18-Nov-11

Version 1.27.4 9-Nov-11 CCB mtg: comments made on CR sheetVersion 1.27.3 9-Nov-11 pre-CCB mtg: New CRs added; updates made from Harmonisation Group

Version 1.27.2 6-Oct-11

Version 1.27.1 3-Oct-11 Pre-CCB mtg: New CRs added, Updates from Interlinking, 2 closedVersion 1.27 16-Sep-11 Updates from TIGes & approval to publish

Version 1.27 draft 9-Sep-11

Version 1.26.4 1-Sep-11

Version 1.26.3 23-Aug-11

Version 1.26.2 14-Jul-11

Version 1.26.1 7-Jul-11 Pre-CCB mtg: Revisions incorporated to move closed items, added newVersion 1.26 8-Jun-11 Updates from TIGes & approval to publishVersion 1.25.7 30-May-11 Updates from Harmonisation and Interlinking Groups incorporatedVersion 1.25.6 12-May-11 Updates from CCB mtg: Revisions incorporated

Version 1.25.5 11-May-11 Pre-CCB mtg: Revisions incorporated

Version 1.25.4 11-Mar-11 Updates from CCB mtg: Revisions incorporated

Version 1.25.3 10-Mar-11 Pre-CCB mtg: Revisions incorporatedVersion 1.25.2 9-Mar-11 Pre-CCB mtg: New change requests added Version 1.25.1 7-Mar-11 Pre-CCB mtg: New change requests added; dates addedVersion 1.25 3-Mar-11

Version 1.24.7 25-Feb-11 Post CCB mtg: updates received from Harmonisation GroupVersion 1.24.6 25-Feb-11 Post CCB mtg: changes discussed at meeting

Version 1.24.5 24-Feb-11 CCB mtg pre TIGes: New change requests addedVersion 1.24.4 10-Feb-11

Version 1.24.3 3-Feb-11 Pre-CCB mtg: New change requests added

Version 1.24.2 12-Jan-11

Version 1.24.1 11-Jan-11

Version 1.24 10-Dec-10

Version 1.23.5 10-Nov-10 Pre-CCB mtg: New CR added, answers for Q&As formatted/inserted (25 & 26)

Version 1.23.4 2-Nov-10

Version 1.23.3 4-Oct-10



Version 1.23 3-Sep-10

Version 1.22.2 1-Aug-10

Version 1.22.1 7-Jul-10

Version 1.22 4-Jun-10 Update following approval by TIGes 3 June 2010Version 1.21.2 10-May-10 Pre-assessment by trial CCB team

Version 1.21.1 1-Jan-10 Inclusion of statement of clarification on EU M1 v1.4.1Version 1.21 1-Dec-09

Version 1.20 1-Nov-09

Version 1.19 1-Sep-09 Inclusion of new CRs/QAs for consideration at September TIGesVersion 1.18 1-Jun-09

Version 1.17 1-May-09

Version 1.16 1-Mar-09 Updated after Interlinking meeting review of all assigned CRsVersion 1.15 1-Mar-09

Version 1.14 1-Dec-08

Version 1.13 1-Jun-08

Version 1.12 1-Mar-08 Q&As 9, 12, 15-21 added confirmed after TIGes-J-32

Version 1.11 1-Jan-08

Version 1.10 1-Jan-08 Further updates for publishing on EMEA e-subs websiteVersion 1.9 1-Nov-07 Comprehensive addition of accrued change requests and review of summaries

Version 1.8 1-Jun-06 Review of document carried out for TIGesVersion 1.7 1-Mar-06 CRs 15-16-17-18 Added for TIGes-J-24Version 1.6 1-Dec-05 Updated after release of eCTD v1.1

Version 1.5 Dec-05 Q&A 14 addedVersion 1.4 1-Nov-05 New Change Request 14 addedVersion 1.3 1-Sep-05 New Change Requests 09, 10, 11, 12, 13 added

Version 1.2 1-Jun-05 New Change Requests and Q&A added, plus ICH Q&A referred for regional advice

Version 1.1 1-Sep-04 Change Request added (EFPIA)Version 1.0 1-Jul-04 Initial baseline after reviewing existing questions

EU Region Question & Answer and Electronic Submission Specifications & Guidances Change Request Document

Version 1.34October 2013

Document Revision History presented with most recent first; only versions approved by TIGes (Version 1.XX) are published

pre-CCB: CR updates for Harmonisation Group, new CRs added, EMA closed CRs moved

CCB mtg: Multiple Status updates made including EMA & disposition of CRs open under Interlinking, 2 new CRs added post-meeting

pre-CCB mtg: CCB membership updated under Intro tab

Post-TIGes mtg, finalised for publication, correction made to move CR to closed as Q&A issued; updated CCB membership under Intro tab

New CRs added; moved closed CRs to 'Closed CRs' tab from 'Change Requests' and 'Accepted CRs - Pending Update' tab, added new Q&A's, moved Q&A's addressed

in M1 revisions to Retired Q&A's tab

pre-TIGes mtg (post-CCB): New CRs added; CRs to be closed and Q&As to be retired with M1 specification publication have been highlighted

pre-CCB mtg: New CRs added; CRs to be closed and Q&As to be retired with M1 specification publication have been highlighted

Post-TIGes meeting: All completed CRs moved to closed CRs; other updates from Harmonisation Group incorporated

Post TIGes Joint mtg: All closed CR tabs consolidated. Color coding removed. Circulated for TIGes-J review prior to website publication for comments - due 3/7

CCB mtg: CR added & format changes; "Accepted CRs - Pending Update" tab created

pre-CCB mtg: Q&As 33 & 34 received from Harmonisation Group accepted and added.

Post TIGes Joint mtg: closed CRs moved to Closed tab, Interlinking Group changes made (includes classification of CRs deferred to next major released of the M1

specification), new Q&As added (30,31,32), Q&As retired (28 & 29)

CCB mtg: new status of 'on hold' added for pending M1 spec & DTD major revisions, updates made on refferal of new CRs

Post TIGes Joint Meeting, new tab created for retired Q&As and closed Q&As moved; circulated prior to website publication for comments - due 9/16

CCB mtg: Added new & identified those to close from revised M1 eCTD specification (v 1.4.1)

Pre-CCB mtg: Added new & identified those to close from revised M1 eCTD specification

CCB mtg: Revisions incorporated to move closed items, accepted new, updated membership

Updates from TIGes mtg approval & post meeting Interlinking updates: CR's 'Rejected' and 'Completed' moved to respective spreadsheets

CCB mtg: Feedback from CCB members on CR-20110127-01 and EMA Business Group added.

CCB mtg: Updates to new and closed change requests; feedback from Harmonisation Group added

Pre-CCB mtg: New change requests added, Interlinking Dec mtg feedback added for 2 CRs, Q&A 23 added

Updates from TIGes mtg approval: CRs 'rejected' moved to respective spreadsheets per TIGes Joint Meeting approval on 10-Dec-2010. Q&As 24-27 approved &

officially incorporated.

CCB mtg: Calendar of Meetings updated; New CRs added, updates from Interlinking Group added in CR status and new Q&As added (28 & 29)

Pre-CCB mtg: New CR added, status updates from Harmonisation & Interlinking Groups added, Q&As from Interlinking added

Post-CCB mtg: new CRs disposition; revisions to Q&A and 'Deferred' tabs proposed by CCB

Pre-CCB mtg: Additional CRs added, Q&A tab revised [Q&As addressed in issued guidances moved to respective worksheets and removed from active Q&A tab],

updates to 'Deferred' CRs from eAF project

Updates from TIGes mtg approval: move CRs noted as 'closed', 'duplicate' or 'rejected' to respective spreadsheets per TIGes Joint Meeting approval on 3-Sep-

2010.

Revised to add new change requests; will be discussed at next CCB meeting in September [post TIGes Joint meeting]

Revisions by CCB to follow-up on Open Change Requests; retired Q&A #10&12 [removed from table], changed order of sheet tabs, updated Introduction in

alignment with creation of CCB and added their Terms of Reference

Update following discussion of open CRs by TIGes subgroup, and general review of status and presentation of all CRs. All closed/withdrawn/rejected/duplicated CRs moved to new worksheets; all CRs implemented in EU M1 v1.4 moved to the appropriate 'Implemented in EU M1 v1.4' worksheet. All CRs for a potential EU M1 v1.4.1 (spec update only) identified and marked.

Update following discussion of some CRs at October Interlinking meeting. Addition of new November CRs. Preparation for discussion November TIGes. Preparation for sub-group review 10/12.

Updated after TIGes of May 2009 to identify potential changes for EU M1 v1.4. Version not published, but produced purely for distribution to TIGes and EU M1 drafting group to agree on scope.

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

CRs added for TIGes 35. Full review of outstanding change requests and assignments. Introduction of colour coding for open/closed CRs

Comments from Interlinking Group on all CRs assigned to this group, and comments from Dec. TIGes. Addition of CR-2008-12-10

CRs and QA 22 added for TIGes 33, general update after publication of EU M1 specification v1.3

More updates for publishing on EMEA e-subs website (whilst review of CRs/Q&A is ongoing)

Introduction

Key to Change Requests Worksheet

Key to Q&A Worksheet

CCB MembershipJune 2013Olivier Simone, Programme Manager, EMAJosé Manuel Simarro , SpainKlaus Menges, BfArm, GermanyMiguel Bley, ANSM, FranceCynthia Piccirillo, EFPIA eCTD Focus Group (Bristol-Myers Squibb)Helle Ainsworth, EFPIA eCTD Focus Group (Novo-Nordisk)Katja Pecjak, EGA (Billev Pharma)Anjana Pinadora, EGA (Gold Shield Group) Andreas Franken, AESGP/Bundesverband der ArzneimittelHersteller

CMDh Harmonization GroupKarin Grondahl, Sweden

This document is managed by the EMA eSubmission Change Control Board [CCB] which is authorized under the EMA mandate dated 20/06/2010, v 0.4. Current membership is listed below.

CCB Terms of Reference: The purpose of the eSubmission CCB is to accelerate decisions and resutls, improve the organisation and traceability of change requests, ensure follow-up of open items and improve performance of change request at the Telematics Implementation Group electronic submissions [TIGes] meetings. The scope is all change requests for electronic submissions requirements and related guidances.

Purpose: This document is a summary of change requests which have been reviewed by the CCB on a monthly basis and by TIGes on a quarterly basis for the eCTD Specifications & guidances, PIM and electronic Application Forms (eAF).

This document will be updated aafter the monthly CCB meetings and published after the TIGes quarterly meetings. 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. Point people for the groups CRs are referred to are listed below.

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 resulting Status and Action(s).

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, where applicable An official answer is given. The approval date for the answer is listed.

2013 4-Jan14-Feb14-Mar11-Apr16-May cancelled, no new CRs13-Jun11-JulN/A9-Sep10-Oct14-Nov12-Dec

CCB Meetings

A B C D E

1

23456789

10111213

EU eSub Change Requests

# Requestor Description Comments Status Action Implement in EU M1 Revision

CR 20100805 Alastair Nixon GSK Interlinking Group No

CR 20110309-02 Interlinking Group No

White = OpenPink = Rejected Green = Closed Blue = New/OpenGray = Withdrawn or DuplicatedBOLD = updated info

SpecificationComponent

Due Date[where applicable]

Group Where Action is Sitting

EU eCTD validation process, SOP/H/3009 [WIN/H/3251 AND WIN/PDM/1702 (eCTD technical validation)] Effective date 21 JUN 10

There appears to be no documentation describing the technical validation process for eCTD dossiers, in particular what happens in the event of validation failure. If dossier contents are incorrect, then the applicant is given time to fix the issue with a subsequent sequence. However, if the original sequence is technically incorrect, there are no written provisions for the applicant to provide a replacement. If the regulator does not process the validation and upload promptly following receipt then time for correction of any technical error is lost which could result in a procedure being significantly delayed. Many category A errors in the eCTD can be caused by relatively minor problems – for example, an extra file on the CD (unreferenced content, check 45, cat A), one file name longer than 64 char, (check 31, Cat A), missing title in delete leaf, (check 12, Cat A). In addition, whilst industry is still using hard media to provide the eCTD to the agencies, and since the EMA only requires one copy of the media, any damage to the CD in transit could also delay a procedure. These kinds of errors can be fixed very quickly, but at present there is no documented mechanism for provision of time to the applicant to fix and provide a corrected sequence. Clearly, all applicants aim to submit 100% valid eCTDs 100% of the time, but errors can occur, and the lack of any process to fix errors could result in unnecessary delays in registering new medicines.

CCB fully agreed with the need to address this. There is benefit to both the Agency to not have to reinitiate the validation process and for the applicant to avoid encountering a delay in review clock initiation.

2013/07: Under the new governance should go to CAB for eSubmission

CCB 9/2010 - Referred to Harmonisation Group1/2011 - Harmonisation Group asked to pass this to the Interlinking Group1/2011 - Interlinking accepted09/2011: Technical validation process being discussed at CMD(h) EMA's draft description of the process for CAP has been circulated. Ongoing.10/2011 - open

While addressing the update to the validation criteria, it would be beneficial to give a window of time to submit a corrected sequence.

Leigh SandwellPfizer

‘CMDh Best Practice Guide on the use of eCTD in the MRP/DCP’ Rev2, June 2010 and TIGes ‘Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD electronic Submissions’ Version 1.0 May 2009

One of our products moved from separate National applications to the MRP after an Article 30 referral. The National submissions were all in NeeS format except for two countries who had been receiving eCTD. These two countries are CMSs in the new MRP. Due to complications of moving this product to eCTD (particularly within the required timelines), it was proposed that the MRP be submitted in NeeS format. As the MRP has a new procedure number after the Article 30 alignment, it had been expected that there would be no issue with the proposal to move to NeeS and the Article 30 referral itself was submitted in NeeS format.

The proposal was agreed as acceptable to the RMS and one of the CMS that had previously received eCTD, but the other CMS stated that an eCTD must be provided. After further discussion the other CMS agreed that this could (on this occasion only) be submitted in NeeS format, but it was stated that products in eCTD format will not be allowed to change to NeeS format in the future. Whilst we generally agree that applicants should never change from eCTD to NeeS within a procedure, in the case outlined it seems acceptable to be able to do this as a new procedure number is assigned and there is no technical relationship between the National submissions and MRP.

Clarification is required on whether it is acceptable to be able to provide NeeS for the eCTD or whether one CMS can enforce the use of the eCTD for the whole procedure.

Harmonisation group - This CR has been taken care of in the latest version of the TIGes harmonised eCTD guidance. However, some issues might still need further clarification and the requestor will be asked to identify what still remains to work on.2012/09: Addtional clarification received from requestor, "If there are a mix of eCTD and NeeS National submissions what should happen at the referral stage when it’s handled through the Centralised Procedure?If the Centralised Procedure referral is an eCTD then there is then the question about how to manage the MRP? Does submitting eCTD in one or two countries then mandate us having to use eCTD for everyone in the MRP? I would strongly suggest that having the option to submit the MRP as eCTD starting at 0000 or providing NeeS makes more sense.”2013/07: Under the new governance should go to CAB for eSubmission

Accepted by Harmonisation group to give further guidance if needed.

2012/05: Open.

2012/09: HG referred back to Interlinking

04/28/11 Harm. group: The group will include some guidance in the updated eCTD guidance document which mainly clarify a recommendation that the eCTD format be used for the new common submission, but that as a step to come there, it might be acceptable to use the NeeS format, since the procedure is quite complex.14/10/2011 Harm.group: See TIGes Harmonised eCTD guidance published 1 September 2011. Further clarification to be written when Leigh has specified the continous need.16/05/2012: More information to be gathered, Harmonisation Group will investigate further and draft more detailed guidance (beginning with a Q&A)

J3

EMEA User: Following the review of EU eCTD Change Request and Questions carried in December 2009, a number of approved changes were identified that do not alter the technical specification (the DTD) but provide additional clarification on the use of the specification. Usually, such changes would be saved until a technical specification change becomes necessary. However, in light of the number of such changes and the importance of the topics that they address, a proposal has been made to issue an interim update to the EU Module 1 eCTD Specification and Annex documents that will incorporate these amendments and additions. The proposed version number for these documents will be v1.4.1. This update will probably be released towards the end 1Q10 or early 2Q10. Vendors of eCTD building and reviewing tools should note that there is no plan to update the technical specification/DTD at this time and the v1.4.1 changes will only be clarifications and additions to the wording of the Specification and Annex documents to improve their usefulness to applicants. Applicants wishing to submit eCTD submissions should continue to use the v1.4 DTD in accordance with previously published guidance from the TIGes and EU NCAs. The full transition to the use of the v1.4 DTD from 1st July 2010 is unaffected by this proposal. In a minor oversight, information identifying the likely changes to be incorporated in the v1.4.1 documentation was included in the published version 1.21 of the EU CR and Q&A Spreadsheet before this statement had been published. We apologise for any confusion this may have caused.

EU eSub Change Requests

# Requestor Description Comments Status Action Implement in EU M1 RevisionSpecificationComponent

Due Date[where applicable]

Group Where Action is Sitting

J2


# Requestor Description Comments Final Disposition Status Action Notes

A001 eCTD EU Module 1 Specification Completed Implemented in EU M1 v1.3

A002 eCTD EU Module 1 Specification Completed Implemented in EU M1 v1.3 closed N/A

A003 eCTD EU Module 1 Specification Is the submission of application forms as XML documents acceptable? Completed Implemented in EU M1 v1.3 closed N/A




A009 eCTD EU Module 1 Specification Completed Implemented in EU M1 v1.3 Text Included in EU M1 v1.4



A012 eCTD EU Module 1 Specification Can further clarification be provided on the related sequence element? Completed Implemented in EU M1 v1.4 closed N/A



Group Where Action was Taken

generated by EU Change Request A001

What is the EU's position on the use of XML for the content of the submission instead of PDF and/or RTF?

This question was generated by EU Change Request A001

Change request added retrospectively to allow tracking of the Q&A processIn line with the general principles of the ICH eCTD Specification Document, it is intended that XML will become the submission format for administrative forms and product information documents as they contain structured data. The long 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.

Implement in v1.3:Answered as Question #1. Clarify in Appendix 2 row 6 (comments section)closed


Can further guidance be given on the acceptable formats for product information in the eCTD?

With respect to product information (PI) documents, the currently acceptable file formats are indicated in the EU Module 1 specification. When generating product information files for the Centralised, Mutual recognition and 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

Already addressed in EU M1 specification - no need to make any change.


It is the intention of the EU to provide XML standards for application forms. The specifications for new and variations forms have been issued and can be accessed at 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.

Update wording of Q&A #3 to reflect current situation regarding development of application form standard.

LD: Need to pay attention to the lack of synchronisation between eAF and paper versions. The last version of eAF XML is Feb 2007 while PDF/Word forms are:- New has changed (May'08)- Var has changed (May'08)- Renewal is ok (Feb'07)


What is EU's position on the use of e-signatures in the eCTD?


Change request added retrospectively to allow tracking of the Q&A processA crucial part of pure electronic communications between the pharmaceutical industry and regulatory agencies and authentication of electronic submissions 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.

Text Included in EU M1 v1.4Implement in 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.


I am trying to understand the complete scope of what submissions are to berequired as CTD/e-CTD submissions in the EU.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 submissionsCan you please confirm/correct this understanding.

The EU Module 1 specification defines the submission types that are part of the eCTD (V1.2.1, p10). All of these submission types are covered, including Follow-up Measures and PSUR submissions.

Update wording of Q&A #7 to refer to current version of EU M1 spec (the Q&A currently references v1.2.1).

I am seeking information on the structure of the eCTD response to list of questions dossier. In the eCTD EU module 1 specifications v1.0, it is stated 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?

The May 2006 version of the Notice to Applicants (http://ec.europa.eu/enterprise/pharmaceuticals/eudralex/vol-2/b/ctd_05-2006.pdf) now defines a specific section in Module 1 for Responses to Questions, what to include in Module 1 and what to include in Modules 2-5. The EU Module 1 specification Version 1.2.1 now includes the section for Responses to Questions. The CTD guidance and eCTD specification together should give adequate direction for applicants to construct a Responses to Questions dossier in eCTD format. The filenaming recommendation is also included in the EU specification v1.2.1.

Update wording of Q&A #8 to refer to current version of EU M1 spec (the Q&A currently references v1.2.1).

LD: Need for guidance when upgrading from v1.0 to v1.3 or v1.4 as response to questions will have to move from element m1-additional to element m1-response (added in v1.2)


M3 requires each substance-manufacturer and drug product to be added in a separate subfolder. How should a product be added to the structure if it has multiple substances?


The ICH CTD guidance recommends that the applicant repeat the complete Module 3.2.S for each drug substance that makes up the drug product. The 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.

The question was generated by ICH change request 00560

Clarification should be provided by all ICH regions as to whether node extensions can be used in Modules 2-5The ICH spec allows node extensions to be used in Modules 2-5 and their use in Module 1 is a regional matter. FDA states that node extensions are not supported in any part of the submission and this therefore invalidates the ICH spec. Experience on production of submissions for Europe demonstrates that node extensions are required to deliver a navigable structure for Modules 4 and 5. At present this means that eCTDs are not re-usable across regions and thus will create significant amounts of rework for industry. FDA should accept node extensions in Modules 2-5.

November 2004: The use of node extensions should be discussed with FDA on a case by case basis. Other regions are able to accept appropriate use of node extensions in compliance with the eCTD specification (i.e. their use is discouraged unless there is no other feasible means to submit the information).

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.

Implement in v1.3:Answered as Q&A #10. Include on p.7 an additional section with agreed text

generated by ICH change request 00710 and the response to ICH eCTD Question 30. This is recorded as EU Change Request A011.

In the eCTD for the EU, are applicant provided style sheets allowed?

The question was generated by ICH change request 00710 and the response to ICH eCTD Question 30. This is recorded as EU Change Request A011.

Little advantage is to be gained by the use of custom stylesheets. The XML 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 official EU stylesheet. It is therefore recommended not to submit customised stylesheets. May 2005 - referred to EU and MHLW for regional guidance

June 2005: Applicant stylesheets are 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.

Implement in v1.3:Answered as Question 11.Put a comment in appendix 2,row 72.

The question was generated by change request 00890 / generated by EU Change Requests A012 and QA-20070628-01

May 2005 - referred to EU and MHLW for regional guidance

June 2005: To be covered by the EFPIA White Paper on eCTD LCM.

Feb 2008 : Answered as Question #12 Answer: A 'regulatory activity' is a logical unit of submission activity (eg, a Type II 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 make up the lifecycle of that particular 'regulatory activity’.

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.

No further action required by EU with regard to EU M1 v1.4





A013 eCTD EU Module 1 Specification Completed Implemented in EU M1 v1.4 closed and covered by EU Validation criteria. N/A

A014 Completed Implemented in EU M1 v1.3 Text Included in EU M1 v1.4 N/A

0001 Andrew Marr (EFPIA) EU DTD v1.0, Specification v1.0 Completed Implemented in EU M1 v1.1

0002 Sandoz (Ron de Boer) Application Form Deferred eAF

0003 Completed Implemented in EU M1 v1.3 Answered also in CTD Q&A /closed N/A

0004 EU Module 1 envelope Completed Implemented in EU M1 v1.3 N/A

0005 EMEA (T. Buxton) eCTD EU Module 1 Specification Completed

0006 Datafarm (S. Kumar) eCTD EU Module 1 Specification Completed

0007 IABG (T. Bergsteiner) eCTD EU Module 1 Specification Rejected Rejected None N/A

0008 eCTD EU Module 1 Specification Completed Implemented in EU M1 v1.1 Dec 05: Implemented in eCTD Spec v1.1, cell 43 p.21

0009 GSK (Andrew Marr) EU DTD v1.0, Specification v1.0, EAF v1.0 Update the attribute values in the DTDs. Completed Implemented in EU M1 v1.1

From the eCTD experience of the IWG, what parts of the Specification are commonly misinterpreted that would prevent my eCTD message from being viewed by another applicant/regulator?

Based on experience, there have been different interpretations of the eCTD Specification that have prevented timely 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. Answer: A list of validation criteria specific to the EU has been prepared by the EURS Implementation Group and is to be published separately on the esubmission website http://www.esubmission.europa.eu


generated by ICH change request 01080 and the response to ICH eCTD Question 37. This is recorded as EU Change Request A014.

What is the EU regional guidance relating to the ability to cross-reference from one sequence to files in another sequence?

In the EU it is possible to refer to a file located in the same sequence or any previous sequence of the same eCTD. It is not possible to refer to other eCTDs.

Include text from Q&A 14 in the spec. v1.4 indicating that references can be made to files located in another sequence.

LD: Need to express how sequences are assumed to be stored (e.g. 0000 next to 0001) so as to allow relative reference (e.g. ../../0000

Suggest inclusion at the end of 'General Architecture of Module 1 ()

Experience is showing that when a number of lifecycle documents have been created it is not possible to know what each sequence is about with physically opening the sequence documents and reading the Cover Letter. Industry is already considering requesting the vendors to provide some additional description to assist in creation of the applications and we understand that at least the EMEA is adding a description to this Docubridge records. It would be logical to standardise on an additional attribute that the applicant can complete for there own records and that the agencies can 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.

It may be possible to have an additional attribute assigned to the submission type ‘submission description’. This could be either optional or mandatory dependent upon submission type.

Opened 19-09-2004Agreed 24-09-04

Dec 05: Implemented in eCTD Spec v1.1 - new element 'submission-description' added to envelope.

The EAF does not allow for the form to be combined for all member states during MRP subm. For a paper based subm this combined AF has been requested by some and has been accepted by all EU member state agencies. This change request is made to enable the AF to be used during MRP submissions. Some of the requests made below are suitable for none MRP subm as well.Generic apps - It should be possible to include reference medicinal 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.

Referred to NtA with MRFG representatives.R. de Boer to split the CR into those points that are nice to have and those which are essential requirements

No further action required - questions should be addressed as part of the electronic application form development.

EFPIA (A. P. Marr) / generated by EU Change Request 0003

How should an applicant handle a Type I variation within and eCTD? Guidance provided in the Notice to Applicants for Type II variations states 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

Referred as Q&A to Notice to Applicants Group Answer: The Notice to Applicants group has issued a CTD Q&A regarding the placement of documents within the CTD structure for Type I variations. The eCTD should 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


Fujisawa GmbH (M. Hamzakadi) / generated by EU Change Request 0004

Notice to applicants “Volume 2A/ Procedures for marketing authorisationChapter 1/ Marketing Authorisation/February 2004” describes 4 types of Marketing authorisation procedures (p.3-6) as follows: - Centralised procedure - Mutual recognition procedure- Independent National procedures- 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?

More understanding of eCTD LCM required for resolution

Referred to Notice to Applicants Group Answer: The EU Module 1 specification defines the submission types that are part of the eCTD (V1.2.1, p10). The submission type to be used in this instance is 'arbitration'. [Note, since this question was originally received, the EU has added the Decentralised Procedure as an acceptable submission procedure type.]

closed. Refers to list of submission types (already responded to in CR-20070926-01).


In the same way as the electronic application form permits information to be submitted using XML, so the PIM DES does the same for product information. The current EU Module 1 specification permits PDF and RTF as formats for product information, but not XML. For administrative information, however, XML is permitted. Suggestion: Include XML as an accepted format for the “labelling text” item

In fact, the acceptance of 'Other file formats in accordance with the PIM DES' should be detailed, as this standard includes more than XML (additional documents that can be attached with the XML)Furthermore the specification has been updated to recognise that PIM files are submitted in archive format as ZIP or TGZ files that contain XML and other file formats.

Implemented in EU M1 v1.2.1 Dec 05: Implemented in eCTD Spec v1.1 - accepted file formats amended.Oct 06: Updated in eCTD Spec v1.2.1 - accepted file formats amended

The specifications do not provide folder structure requirements for UTIL folder that includes STYLE and DTD folders. The screen shots are good and include a STYLE folder under UTIL folder under m1/eu. See page 25 to 29.Please note that the STYLE folder is already present under submission folder under UTIL folder e.g. eu12345/0000/util/style. In the same location we have a DTD folder.This structure is clear and consistent across all 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

Retain separate util folder for components that can be submitted outside eCTD e.g. e-AF and PIM. For those regional components that are always submitted as part of eCTD, use global util folder to obviate need for regional util folder. More testing required of PIM container

Implemented in EU M1 v1.2.1 Oct 06:Implemented in eCTD Spec v1.2.1, cell 72, p.28

eCTD should take into consideration the ISO standard ISO/PRF 19005-1 ( PDF/A) for long-term readibility of PDF documents.

This was referred to ICH where it was concluded that PDF/A does not support the review process for eCTDs. Response issued as ICH eCTD Q&A 47.


Spanish Agency of Medicines (José Manuel Vidal Morales)

EU Module 1 Specification:Element : m1-6-1-non-gmoDirectory : m1/eu/16-environrisk/161-nongmoeCTD EU Backbone DTD - 1.0:Element : m1-6-1-non-gmoDirectory : 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

The New Medicines Legislation defines a new procedure for regulatory approval in Europe, that of the Decentralised Procedure. In the current eCTD envelope a picklist provides for the option of Centralised, Mutual 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.

Dec 05: Implemented in eCTD Spec v1.1 new attribute in envelope.





0010 EMEA (J. Rueda) eCTD EU Module 1 Specification Completed Implemented in EU M1 v1.1

0012 EMEA (J. Rueda) eCTD EU Module 1 Specification Duplicated Duplicated None N/A No further action required by EU

0013 EFPIA (A. P. Marr) eCTD EU Module 1 Specification Completed Implemented in EU M1 v1.1 Dec 05: Implemented in eCTD Spec v1.1

0014 EFPIA (A. P. Marr) eCTD EU Module 1 Specification Completed Answered in Q&A N/A

0015 PIM Core Team eCTD EU Module 1 Specification Completed Oct 06: Implemented in eCTD Spec v1.2.1

0016 PIM Core Team eCTD EU Module 1 Specification Completed Oct 06: Implemented in eCTD Spec v1.2.1

0017 eCTD EU Module 1 Specification Completed Implemented in EU Module 1 eCTD v1.2.1

0018 eCTD EU Module 1 Specification and type definition Addressed by EU M1 v1.3 specification and transition plan Completed Closed None

20060524-01 Ron de Boer Completed Implemented in EU M1 v1.3

20060627-01 Geoff Williams, Roche EU Module 1 DTD and Specification, v1.2 Completed Implemented in EU Module 1 eCTD v1.2.1

The inclusion of the PIM DES into EU Module 1 of the eCTD is planned, as per the road map (DES 2.1), for December 2005.This means that the current DES container will need to be re-design in order to have a unique container for submitting PIM in/outside eCTD and to 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

An additional element “m1-3-1-pim-xxxx-y” will need to be created in EU M1 for accommodating the new PIM container when submitted within the eCTD

Dec 05: Implemented in eCTD Spec v1.1 - new element in 1.3.1

The list of submission types accepted in eCTD format listed in the eCTD specification should be in line with the list of submission types listed as accepted in NtA Volume 2. Currently, the 2 lists are not consistent with one another.

EMEA to prepare a list to be confirmed at the eCTD interlinking.Nov 2007 - still under consideration and now linked to additional CRs - QA-20070906-01 & CR-20070926-01

The structure of folders given in the EU Module 1 have ‘Centralised’, ‘Mutual’ and ‘national’ as folders between the root folder and the sequence number. This was not intended as part of the structure submitted in the eCTD.Three representative folder structures are provided in the specification to 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’

The folder structures should be clarified and the ‘procedure’ folders deleted. This should improve the clarity of the specification and hence valid submissions.

The newly agreed ICH Q&A #38 on referring to files submitted in previous sequences indicates that we should refer to regional guidance with respect to allowance of cross-referral. This guidance needs to be established.

ICH Answer :At this stage of the implementation of the eCTD, the four Operation Attributes (new, append, replace and delete) will remain and not be added to. With the existing specification it is technically possible to determine that a file is not in the current eCTD. Referred to ICH for next major version of the eCTD.

Include text from Q&A 14 in the spec. v1.4 indicating that references can be made to files located in another sequence.

Suggest inclusion at the end of 'General Architecture of Module 1 (Page 7)

See A014.

Priority: High

In December 2005, a CR was requested to include PIM into the EU Module 1. This CR requested the following actions:- Creation of element “m1-3-1-pim” to link to the PIM XML file- Identify the “util” folder of the EU Module 1 as the appropriate location for PIM utilities (DTD and style-sheets)- Amend file formats supported by the EU Module 1 to add XML as well as the image formats (JPEG, GIF, PNG, TIF, SVG, MathML) Today, PIM systems are under elaboration and practical experience provided some feedback about the way PIM has been integrated into the EU Module 1.Following the feedback received, we believe that there is a simpler way to include PIM in EU Module1.It is more appropriate to include PIM into the EU Module 1 as a single archive file than directly refer to the XML file. Therefore, it is proposed to:- 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 usedFurther information included in the original change request.

Recommended solution- Add TGZ as allowed file format (this format is preferred as it is more open than the ZIP format)- Add ZIP as allowed file format- Add name specification “131-pim-xxxx-ar.zip/tgz ” for the PIM file- Keep Element “m1-3-1-pim”- Remove description the use of EU M1 “util” folder for PIM- Remove definition of folder “131-pim-xxxx-ar ”

Refer to PIM DES specifications for compression protocols

Implemented in EU M1 v1.2.1

The link from EU Module 1 to PIM is defined in v1.1 by using the leaf entity as defined by ICH in the context of eCTD. The leaf entity is defined by:- 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


Bernadette BilletLiquent, Thomson Scientific

When providing PIM and/or the XML Electronic application form, the EU Module 1 eCTD version 1.1 specification indicates that the corresponding 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?

They do not have to referece.Check guidance is clear


Alex YatesKendle

Please can you inform us as to the date when the updated European Module 1 specifications issued in January 2006 become mandatory for use 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.

If I submit sequence number 0001. What will be the operation attribute for the eu-regional.xml in the index.xml?This can not be replace, because the eu-regional.xml only contains the updated parts and a replace operation will make all previously submitted documents obsolete. It is also not new, because the eu-regional.xml has been submitted before. Should it perhaps be append?

Implement in v1.3:Include a clarification in the spec in Appendix row 2 - operation attribute should be 'new'. Investigate other locations where an update could be provided.

Version 1.1 of the EU Module 1 DTD included country and language codes for the planned accession of Romania and Bulgaria. Version 1.2 of the DTD included several changes, including the removal of these country and language codes. Given the planned accession date of 1st Jan 2007, we believe that these codes should be in place now to allow use of the eCTD 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 M1 is 1st priority – Lang/country codes for RO BU in DTD, specifications and style-sheet. Assessment of required changes to align same requirement in eAF-New eAF-Var. EMEA Regulatory Affairs to agree to this CR.






20060627-02 Bernadette Billet, Liquent EU Module 1 DTD and Specification, v1.2 Updated in guidance - Word not to be included in the eCTD in any case. Completed Closed None

20060627-03 Andrew Marr, GSK EU Module 1 DTD and Specification, v1.2 Rejected Interlinking Group



20060914-01 Aziz Diop, AFSSAPS eAF DTD and style sheet Deferred Refer to eAF project eAF

QA-20061017-01 ICH eCTD specs v3.2 Appendix 6 Nine Questions on the use of the eCTD in Module 3 of the CTD were submitted. Completed Closed

QA-20061120-01 Alastair Nixon GSK Completed Implemented in EU M1 v1.3 closed N/A

CR-20061120-02 Shy Kumar, Datafarm eCTD EU Module 1 specification v1.2.1 Mar-07 After discussion, it was agreed that the examples are correct and do not require changing. Duplicated Duplicated None N/A

CR-20061221-01 Kevin Wing, J&JPRD eCTD EU Module 1 specification v1.2.1, page 7 Completed Implemented in EU M1 v1.3

When migrating the product information from Word to PIM for a product managed by an eCTD how should the operations attributes be used?

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?

When to submit Module 3 updates as part of responses to questions with an eCTD

Currently with a paper submission there is the possibility of submitting a response to a question which may contain a proposal (e.g. a change to the specification) and when that is found to be acceptable by the regulators the revised Module 3 content can be submitted. With an eCTD is it always expected that the Module 3 section is updated at the time of submitting the response or can this also be delayed until it is known that the response is acceptable?

Draft response: At key stages of procedures there is need for rapid turnaround of submissions and in order to meet deadlines then documents may be sent to reviewers via Eudralink, outside of the eCTD, but must be followed up with submission to the eCTD.Only the responses to questions in Module 1 documents need be provided outside of the eCTD. It is acceptable to delay submission of Module 3 documents until the responses have been agreed but the final versions must be submitted to the eCTD before the completion of the procedure, with a new sequence number.

EFPIA eCTD TG Comment: Not sure the answer is quite right, talks about tight timelines in MRP, whereas the question does not. What if it's not rapid turnaround, but you’re unsure if your proposal for an m3 document is going to be agreed? Do you put the doc in m3, or keep in M1 until agreed? Answer suggests you would Eudralink it, but this might not be appropriate. Also don’t understand, “Only the responses to questions in Module 1 documents need be provided outside of the eCTD.” NEED to be provided outside of the eCTD???? And “. It is acceptable to delay submission of Module 3 documents until the responses have been agreed….”Do they mean delay submission in eCTD, but still doesn’t answer the question. Do we submit proposed changes directly into M3 or not?

Andrew Marr following up on status of Q&A 'approval'

CCB Comment: Should this be restricted to m1.3.1 (SmPC, Labeling, PL) according to CMDh BPG and EMA Q&A. Documents in regard of the RMP or the DDPS need to be followed up with the eCTD and therefore, such documents should not be excluded from LCM.

16-12-2008 eCTD Interlinking: The module 3 documents should be handled in the same way that the SPC is currently handled in eCTD - only the final agreed versions of the documents should be submitted at (or just before) the end of the procedure. The interim versions should not be exchanged in the eCTD - they should be exchanged as communications outside the eCTD.March-09: Options for Q&A have been drafted and are to be reviewed by the Interlinking Group.9/2010 - Reviewed options previously developed by A. Marr; he is actioned to draft a more detailed Q&A with some examplesInterlinking agreed on following :10/2010 - At key stages of procedures there is need for rapid turnaround of submissions and in order to meet deadlines then documents may be sent to reviewers via Eudralink, outside of the eCTD, but must be followed up with submission to the eCTD. Only the responses to questions in Module 1 documents need be provided outside of the eCTD. It is acceptable to delay submission of Module 3 documents until the responses have been agreed but the final versions must be submitted to the eCTD before the completion of the procedure, with a new sequence number. Draft response: At key stages of procedures there is need for rapid turnaround of submissions and in order to meet deadlines then documents may be sent to reviewers via Eudralink, outside of the eCTD, but must be followed up with submission to the eCTD.Only the responses to questions in Module 1 documents need be provided outside of the eCTD. It is acceptable to delay submission of Module 3 documents until the responses have been agreed but the final versions must be submitted to the eCTD before the completion of the procedure, with a new sequence number.EFPIA eCTD TG Comment: Not sure the answer is quite right, talks about tight timelines in MRP, whereas the question does not. What if it's not rapid turnaround, but you’re unsure if your proposal for an m3 document is going to be agreed? Do you put the doc in m3, or keep in M1 until agreed? Answer suggests you would Eudralink it, but this might not be appropriate. Also don’t understand, “Only the responses to questions in Module 1 documents need be provided outside of the eCTD.” NEED to be provided outside of the eCTD???? And “. It is acceptable to delay submission of Module 3 documents until the responses have been agreed….” REALLY? They mean delay submission in eCTD, but still doesn’t answer the question. Do we submit proposed changes directly into M3 or not? Andrew Marr following up on status of Q&A 'approval'CCB Comment: Should this be restricted to m1.3.1 (SmPC, Labeling, PL) according to CMDh BPG and EMA Q&A. Documents in regard of the RMP or the DDPS need to be followed up with the eCTD and therefore, such documents should not be excluded from LCM.

Accepted - refer to Interlinking Group; 7/2010 A. Marr to follow-up if Q&As address this and raise at Interlinking the potential to closed9/2010 - discussed at Interlinking; A. Marr actioned10/2010 - Interlinking Group - Proposal agreed. Q&A to be finalised.CCB 11/2010 - It seems that there is overlap between this CR and proposed Q&A and the CR 20100707 that was actually rejected. Will ask requesters to work together. Potentially withdraw the 2 CRs and combine them into a new CRCCB 12/2010 - see actions12/2010 - Interlinking said to move to closed [rejected] as this is addressed in the Best Practice Guide which states not to use the eCTD backbone for draft documents.

Produce an NTA CTD Q&A detailing the guidance to submit only the final agreed version of the M3 documents in the eCTD. (This will set a precedent for an eCTD Q&A and any appropriate guidance change).9/2010 - A. Marr to draft a more detailed Q&A with some examples10/2010 - Proposed Q&A added to tracking table.CCB 12/2010- Collaboration between A. Marr and K. Menges to address Interlinking comments and identify a suitable path forward.CCB 2/2011 - Move to closed [rejected].

The European Commission website URL is incorrect

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


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


It is mandatory in the DTD to choose an option in the centralised procedure 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


Hans van Bruggen, eCTDConsultancy

This CR/Q&A was submitted to the ICH M2 group for consideration. It has been added here for completeness and to record any discussion and position taken at an EU level.

Discussed at ICH M2, see ICH tracking sheet for details of outcome.

When submitting via the centralised procedure, changes are frequently required to the dossier following validation by the EMEA. At present, the rapporteur and co-rapporteur have at this stage already received an initial copy of the eCTD. (i) How is the applicant advised to handle validation changes in the eCTD? Should another eCTD sequence be created, incorporating the suggested changes, or should the original sequence be corrected? NB If an additional 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?

Nov-07 Part i) Accepted for Q&APart ii) was referred to eCTD Interlinking group, they responded "It is required to submit the application to Rap / Co-Rap at the same time as to the EMEA. It is therefore not possible to submit to Rap / Co-Rap only after validation of the application." Answer: If an eCTD fails technical validation, then a replacement sequence must be provided, since an invalid sequence cannot be loaded into an agency’s review tool. If, once technical validation has been completed, content validation identifies missing sections or administrative errors, then an additional new eCTD sequence should be provided (a lifecycle sequence) correcting these errors, with replacement or additional new documents as required. The applicant should not send a replacement of the original sequence.


The example submission directory structure for MRP (Appendix 3) may be inconsistent with the accompanying statement that ‘common’ is the directory to hold all files applicable to more than one country


Covered by CR-20090506

EU Module 1 Specification v1.2.1 (and predecessors) requests that the variable component of filenames should be a “meaningful concatenation of words without separation and should be kept as brief and descriptive as possible” but also specifies that hyphens (“-“) should not be used within these variable components. The change request applied for is to allow the use of hyphens within the variable component of filenames in the EU Module 1.

Sep-07 Proposed for Q&ANo it is not acceptable to use a hyphen. In cases where differentiation is needed it is suggested that the word 'point' is used in the filename eg. 1point5mg

Implement in v1.3:Answered as Q&A #16. Change p.7 of the specification 'file naming convention'





CR-20070118-01 Harv Martens, ING America eCTD EU Module 1 specification v1.2.1, examples Mar-07 Accepted to update example files Completed Implemented in EU M1 v1.3

CR-20070122-01 Harv Martens, ING America eCTD EU Module 1 specification v1.2.1, examples Completed Implemented in EU M1 v1.3

CR-20070130-01 Shy Kumar, Datafarm eCTD EU Module 1 specification v1.2.1 Rejected Rejected None N/A

CR-20070215-01 Ashley Birch, AstraZeneca ICH eCTD Q&A 40 Rejected Rejected N/A

CR-20070309-01 Kevin Wing, J&JPRD eCTD EU Module 1 specification v1.2.1 Completed Implemented in EU M1 v1.3

CR-20070316-01 N. Chandar, Take Solutions ICH Specification v3.2 Deferred Deferred; moved to Closed for EU ICH M2

CR-20070405-01 Geoff Williams, Roche ICH Q&A, Q&A36, item 12 Completed Closed

CR-20070405-02 Geoff Williams, Roche ICH Q&A36, Item 20 Deferred Deferred; moved to Closed for EU ICH M2

CR-20070405-03 Geoff Williams, Roche ICH DTD, v3.2 Deferred Deferred ICH M2

CR-20070408-01 Dirk Beth, Mission 3 ICH DTD, v3.2 Deferred Deferred ICH M2

CR-20070426-01 Joe Cipollina, BMS ich-stf-stylesheet-2-2.xsl Completed Closed

CR-20070426-02 Joe Cipollina, BMS Valid-values.xml Completed Closed

QA-20070627-01 Alastair Nixon, GSK eCTD EU Module 1 specification v1.2.1 Nov-07 Q&A wording proposed Completed Implemented in EU M1 v1.3

CR-20070627-01 Alastair Nixon, GSK eCTD EU Module 1 specification v1.2.1 Sep-07 Accepted for next release of specification Completed Implemented in EU M1 v1.3

QA-20070628-01 Thierry Le Ridant, Ethypharm eCTD EU Module 1 specification v1.2.1 Completed see A012 closed N/A

Examples 2 and 3 of the EU Module 1, in the context of v1.2.1, are incorrect regarding the Specifications.EU M1 Specifications require PI documents (section 1.3.1) to be named as follows: CC/LL/CC-SPCDOC-VAR.EXTFor instance, a French SPC in Belgium should be named, e.g.:be/fr/be-spc.docExamples 2 and 3 name such file with the prefix set to the language instead of the country: be/fr/fr-spc.docExamples need to be updated so that the name of the PI documents is inline with the EU M1 Specifications.

Implement in v1.3:Change as specified

Examples 2 to 4 contain a util folder within the m1/eu folder. This folder can exist to hold EU-specific files (DTDs and/or style-sheets) but in the provided examples, this folder contains the EU Module 1 DTD files. This is incorrect and can be misleading

Mar-07 Examples to be corrected, and to include index.xml and MD5 checksum to reflect valid eCTD submissions.

Implement in v1.3:Change the 3 examples in all the locations as detailed in the change request itself

The EU Module 1 Specifications, version 1.1, provided a description of the field "submission-description" in the envelope, including a size limitation set to 50 characters.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.

Mar-07 No change to specification. No re-instatement of max. 50 character field length. Gain practical experience with no limitation.


ICH eCTD Question Number 40 asks whether it is acceptable to submit PDF V1.4 files across all regions. Although the answer given is in the affirmative, it actually goes much further than mere ‘acceptability’ by appearing to make V1.4 mandatory for eCTDs. Shouldn’t V1.4 be ‘acceptable’ or perhaps ‘preferred’ (if justified) rather than ‘mandatory’?


Clarify in EU M1 v1.4 the use of PDF v1.4, if any decision has been reached at ICH level.

Page 39 of EU Module 1 Specification v1.2.1 suggests that the envelope element of MRP or DCP submissions could be assigned a country attribute value "common" when the same sequence is being submitted to multiple countries. The change request applied for is to change the example to illustrate the use of multiple repeated country-specific envelopes, instead of a single envelope labeled “common”.

Sep-07 “Common” should not be an allowable value for the envelope. Change wording to specify the use of multiple country-specific elements.Write a Q&A to clarify until new version is producedThe envelope should be repeated for each member state and 'common' should not be used. The specification will be updated at the next version to correct this.

Implement in v1.3:p.6 section 'Envelope' -propose text for inclusion here. Also change example text which illustrates this on p.39See Q&A #17

20080220: See CR-20080129-02

The query relates to details of the Q&A document (MS Excel spreadsheet) 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? A. The regulatory authority should be consulted for a solution until the 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.


To be carried forward into eCTD Next Major Version


ICH Q&A36, item 12 says “Ensure all the files identified by an xlink:href reference exist”. This should be clarified to state where the files can exist.

The check for item 12 is ambiguous as to where the file identified in xlink:href should exist. At the time this was written, we probably meant “exist 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.


Discussed at ICH M2, see ICH tracking sheet for details of outcome. Addressed in EU Q&A 14 as regional guidance

ICH Q&A36, item 20 states “Ensure that leaf or node extension Title attribute is not empty (except when the operation attribute is delete)”. It is not clear why the parenthetical condition for delete is in place.

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”




The approved Change Request 00050 says that the element for Module 3.2.A.3 will be made a repeating attribute in Version 3.2 of the specification. This does not appear to have been done.

The change request says that the element for Module 3.2.A.3 (Novel 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.



To be carried forward into eCTD Next Major Version


Mission3 submits this change request with the suggestion of migrating the narrative content of submissions from PDF to XML. An XML model that fits the needs of this industry will yield significant benefits to both sponsors and regulatory reviewers.


Discussed at ICH M2, see ICH tracking sheet for details of outcome. Part of Workplan for ICH M2 SENTRI group to consider


The ICH STF Stylesheet currently posted gives inconsistent display results in Internet Explorer. It seems to work in some cases but not in others. STF files which were viewable with the older version of the stylesheet are no longer always viewable.



There are differences in the values listed in the valid-values file posted on the ESTRI website and the valid-values file posted on the FDA website.



One principle of the eCTD is that content that is not required for the dossier is not provided, and there is no need for the applicant to provide ‘not applicable’ pages. However, we have experienced occasions where we receive questions after EMEA content validation with respect to sections that are missing in the eCTD, but where no justification has been provided.Is it necessary to include statements in the CTD/eCTD justifying the absence of data? If so, where should these statements be placed in the CTD structure?Further information included in the original change request

Implement in v1.3:Answered asQ&A #18.Change text on p.6 to include text from Q&A 18. Add a statement to indicate that further information national guidance should be referred to.

Error in Appendix 2, suggesting that applicant uses the 10-cover section for response to questions

Implement in v1.3:Remove reference in row 5, appendix 2, p.13

During a sequence 0026, we must modified SPC of the 0020 sequence and leaflet of the 0022 sequence.What should be the value of the <related-sequence> in the <envelope>? The last sequence modified (0022) or it should be blank?

Nov-07 Both proposals are considered incorrect. A Q&A has been drafted to clarify use of related-sequence attributeSee also CR A012See Question 12





CR-20070628-01 Thierry Le Ridant, Ethypharm eCTD EU M1 stylesheet Completed Implemented in EU M1 v1.3

QA-20070628-02 Thierry Le Ridant, Ethypharm eCTD EU Module 1 specification v1.2.1 Nov-07 EMEA has referred to EUTCT group to define list Completed Implemented in EU M1 v1.3

QA-20070628-03 Thierry Le Ridant, Ethypharm Withdrawn Withdrawn None N/A

QA-20070628-04 Thierry Le Ridant, Ethypharm eCTD EU Module 1 specification v1.2.1 Response provided in Best Practice guide for use of eCTD in MRP/DCP published by CMD(h). Completed Closed None

CR-20070711-01 Alban Dhanani, AFSSAPS eAF-New v2.1 Deferred Refer to eAF project eAF

CR-20070714-01 Kevin Wing, eCTDConsultancy eAF New specification Sep-07 Accepted for next release of eAF-New specification Deferred Refer to eAF project eAF

CR-20070718-01 Thierry Le Ridant, Ethypharm eCTD EU Module 1 specification v1.2.1 Rejected Rejected None N/A

QA-20070813-01 Phyllis Thomas, AstraZeneca Withdrawn Withdrawn None N/A

CR-20070814-01 Ann Verhoye, FAMHP, Belgium ICH CR 1550 Rejected Rejected None N/A

QA-20070816-01 Phyllis Thomas, AstraZeneca eCTD EU Module 1 specification Completed Approval date: 1.3.2008 TIGes

CR-20070816-02 Kevin Wing, eCTDConsultancy eAF-New v2.1 Sep-07 Accepted for next update to the specification Deferred Refer to eAF project eAF

QA-20070906-01 eCTD EU Module 1 specification v1.2.1 Nov-07 Review required across other specifications. See also CR-20070926-01 Completed Implemented in EU M1 v1.3

CR-20070906-01 Reinko Abels, Qdossier B.V. eCTD EU Module 1 specification v1.2.1 Completed Implemented in EU M1 v1.3

Completed Approval date: 1.3.2008 Text Included in EU M1 v1.4

CR-20070912-01 Jose Manuel Simarro, AEMPS, Spain eAF-New v2.1 Deferred Referred to eAF project eAF

CR-20070926-01 Juan Rueda Montes, EMEA eCTD EU Module 1 specification v1.2.1 Update Specifications re list of procedure types Nov-07 Review required across other specifications. See also QA-20070906-01 Completed Implemented in EU M1 v1.3

CR-20070927-01 Ulrika Lantz, AstraZeneca Completed Implemented in EU M1 v1.3

CR-20070928-01 Leo van de Winkel, N.V. Organon Notice to Applicants vol 2B Completed eCTD Interlinking Group

CR-20071001-01 Deanna Murden, i3Logic Nov-07 Referred to ad hoc group for discussion and position Rejected N/A

CR-20071002-01 Juan Rueda Montes, EMEA eCTD EU Module 1 specification v1.2.1 Completed Implemented in EU M1 v1.3

Data from the envelope is displayed in blue but they are not hyperlinks. The use of blue text should be limited to hyperlinks

Sep-07 Analysis undertaken of all EU stylesheets shows inconsistency. Change request accepted and will be implemented in next updates of each stylesheet

Implement in v1.3:Stylesheet to be updated to include all black text.

Is it possible to have a list of value for the <agency-name> in order to standardised the value of this element.

Implement in v1.3 if values list exists:

20080220: List to be implemented in EUTCT - to come from ECD

For an association of two active substance (eg Paracetamol / dextroproxifen), what is the best practice : duplicate <atc> and <inn> element ?

Sep-07 Requested to be withdrawn and resubmitted as a CR (subsequently submitted as CR-20070718-01)


DCP or MRP are followed by a national phase (PIL etc.). What should be the value of the "procedure type" field "national" or "MRP" ?The current Application Form for New applications is not well designed in 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.


The specification for the eAF-new does not specify the use of relative filepaths for the xlink:href attribute value


In the Envelope, in the case of an association of 2 active substances, there is no link between the <inn> element and the <atc> element. We suggest to regroup them into an <active> element which will permit to identify the link between atc and inn.

Nov-07 Was referred to eCTD Interlinking Group "No changes required – Because there is no one to one relationship between 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.3Dec 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.


In Europe (and with the current ICH M2 eCTD specification), does the applicant need to update attributes in the eCTD backbone during the life an application?Further detail included in original question.

Aug-07 Requested to be withdrawn due to an error. To be resubmitted after correction of error. (Resubmitted as Q&A-20070816-01)


Request to re-open change request 1550: this change request is closed mentioning that all filenames in module 2.3 and 3 will be mentioned in italics: this means that no filename check is possible, and no standard for filenames 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.

Sep-07 Examples in two provided annexes were reviewed. No consensus on proposalRejected


In Europe (and with the current ICH M2 eCTD specification), does the applicant need to update attributes in the eCTD backbone during the life an application, for example, if the manufacturers name changes, the proposed name of the dosage form is not accepted or an excipient is granted a pharmacoepial name?Further detail included in original question.

Sep-07 Question to be referred to ICH M2 Q&A.An EU Q&A to be prepared in the interim period Answer: Reference is made to ICH Q&A #3. It is not possible to update the attributes nor is it necessary to attempt workarounds such as deleting existing documents and resubmitting with new attributes. The recommendation is to retain the obsolete entry and to rely on the document content to explain the current details.

Refer to ICH Q&A Text Included in EU M1 v1.4

Possibly update the text of EU M1 v1.4 to clarify that metadata cannot be amended during the lifecycle of an application.

LD: Need to further define the set of metadata that needs to remain throughout the life cycle of the product

AB: Also include in eCTD guidance

The specification for the eAF-new does not enable multiple meeting dates to be included for provision of CHMP scientific advice (section 3.1) or for Member State scientific recommendations (section 3.2)


Hans van Bruggen, eCTDConsultancy B.V.

Could the TIGes clarify what <Submission> “type” attribute value should be selected for the following types of submission:1. Annual Reassessment2. Duplex registration3. Line Extension

Implement in v1.3:Propose revised list. See CR-20070926-0 - ensure these values are in the revised list. Also include community referrals.

The current EU Module 1 specification does not specify that content files in the ICH section can be pointed to by eCTD leaf elements in the eu-regional.xml file

Nov-07 Accepted with proposed change to wording to page 6 of the specification.See also CR-20070927-01

Implement in v1.3:Include a short additional 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-20070906-01 & CR-20070927-01

generated by EU Change Requests CR-20070906-01 & CR-20070927-01

Can content files that are included in the index.xml (ICH Modules 2-5) also be referred to in the eu-regional.xml?This question was generated by EU Change Requests CR-20070906-01 & CR-20070927-01

Yes. For appendices to the application form which may also be located in module 3, it is recommended to create a leaf in the eu-regional.xml that points to the content located in module 3 e.g. Flow Chart of the Manufacturing Sites, 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.

Orphan medicinal product information (section 1.2) applies to all types of procedures not only for centralised ones.


Implement in v1.3:List should be finalised:Propose final list for agreement by NtA Interlinking/TIGes

eCTD EU Module 1 specification v1.2.1 and Guidance on Type 1A and 1B variations

Many post-approval submission types require a copy of an already approved specification to be submitted. The basis for eCTD is to submit documents only once, but to be able to fulfil the European variation guidelines all required documents would need to be submitted. This change request gives a suggestion on how this could be handled in eCTD.Further information included in the original change request.

Nov-07 The eCTD specification already defines how to reference content from more than one leaf location. Some clarity might be added to specification.See also CR 20070906-01

Implement in v1.3:Include a short additional 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-20070906-01)See Q&A #21

The ASMF guidelines state that the manufacturer and the applicant should both submit an identical Applicant’s Part (AP) of the EDMF. Guidelines for eCTD files indicate that the AP should be included in Section 3.2.S of the eCTD. 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

Nov-07 This issue is referred to the NtA Q&A on handling of ASMFMarch-09 : Subgroup of Interlinking group to be established to produce guidance for ASMF7/2010 - in ASMF guide published

Accepted - refer to eCTD Interlinking Group7/2010 - move to closedCompleted

Subgroup of Interlinking group to be established to produce guidance for ASMF - draft practical/technical guidance to be published by end 2009 (following a meeting scheduled 14th December).

How should sponsors manage summary documents in Module 2 over the lifecycle of an application?

Accepted - refer to Harmonisation Taskforce;7/2010 CCB recommends rejecting, not needed

No further action required. Already covered in the EU harmonised eCTD guidance

Should eCTD Module 1 section "additional data" be empty for EMEA centralised procedures?

Feb 08: Specify in EU M1 v1.3 that this section can be used for CP in a transition period for submitting documents as part of a new M1 structure before the latest DTD version is implemented (e.g. paediatrics data).Yes. The Notice to Applicants CTD Q&A #4C states that the 'Additional Data" should only be used for information required for National, MRP and Decentralised Procedures and is therefore not applicable for the Centralised 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.

Answered as Question 20Refer to CTD Guidance #4 on use of the additional data section (i.e. it should not be used for CP) - amend therefore line 68 of the table in appendix 2





CR-20071003-01 Alastair Nixon, GSK eCTD EU Module 1 specification v1.2.1 Completed Implemented in EU M1 v1.3 Implemented Appendix 2 row 72.

CR-20071009-01 eCTD EU Module 1 specification v1.2.1 Nov-07 Referred to ad hoc group for discussion and position Rejected N/A

QA-20071022-01 Alastair Nixon GSK Q&A variations document Completed Q&A 42 issued Q&A 42 issued Harmonisation Group

CR-20080129-01 Geoff Williams, Roche EU M1 stylesheet Rejected Rejected None N/A

CR-20080129-02 Geoff Williams, Roche EU Module 1 DTD, eu-envelope.mod and Specification, v1.2.1 Withdrawn Withdrawn None N/A

CR-20080129-03 Geoff Williams, Roche eCTD Specification v1.2.1 Completed Implemented in EU M1 v1.3 Implemented on Page 5

CR-20080218 Andrew Marr, GSK Completed Implemented in EU M1 v1.3 Implemented in Appendix 2 Line 4

CR-20080303 Claire Holmes, EMEA EU M1 Specification v1.2.1 Completed Implemented in EU M1 v1.3 Included in DTD and througout the document

CR-20080415 Completed Accepted - refer to eCTD Interlinking Group Draft guidance on the use of eCTD for PMF. eCTD Interlinking Group

Supporting data for variations that is not provided in m3 is currently either provided with the cover letter (p13 of EU M1 Specification v121), or as an annex to the form (p14). It is proposed that all supporting data is provided in the same location, as an annex to the form. In addition, it is proposed that a table of suggested names is added to the specification, such that these documents are provided in a consistent manner. Further information included in the original change request

Nov-07 An EU CTD Q&A (4c) already exists about the placement of additional documents in Variations. Accepted to update EU M1 eCTD specification in line with CTD Q&A response.


Guidance is needed on how to maintain the lifecycle of Section 1.6 Environmental risk Assessments, using the operations new, append replace and/or delete.Further information included in the original change request

Accepted - refer to Harmonisation Taskforce; 7/2010 CCB recommends rejecting, not needed

No further action requried. Enough covered by general guidance in the EU harmonised eCTD guidance.

In the eCTD, how should an applicant handle multiple variations that occur in parallel and affect the same document?

Nov-07 Best Practice guide written for review and approvalMarch-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.7/2010 - EFPIA eCTD TG recommends to progress as a priority10/2010: Interlinking agreed on following :CR is accepted. The Q&A document on eCTD Variations already refers to the issue of submitting a consolidated sequence. Additional clarification should be provided on the technical issues (i.e. use of operation attributes).The proposal of the Interlinking group is that the Q&A variation is updated to contain information of parallel variations handling. Interlinking to refer CR back to CCB and propose that responsibility is taken by Harmonisation sub-group.10/2011: Harmonisation group agreed to take over the responsibility for the variation Q&A. EFPIA will look at an earlier draft document concerning this issue, update this and see how it can be used as base for a Q&A and maybe later included in the Harmonised guidance document.

The current stylesheet displays the full structure of the Module 1, whether 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.


(Include a note in the Spec about the approach of the style-sheet, i.e. to display all the entries in the ToC even if there is no content attached to some sections).

A previously submitted CR (20070309-01) proposed the prohibition against the use of “common” as an acceptable country identifier in the EU Module 1 envelope. This CR seeks to clarify the use, or otherwise, of the country identifier “ common” for content files in the EU Module 1.

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.

Feb 08: New change request to be submitted by EFPIA proposing a 'softened' approach where the country identifier 'common' can be used in certain circumstances.

May 2009: related to CR-20090506 from Bil Ali of Shire.

Related to CR 20090506 which will be implemented in EU M1 v1.4 (clarificaiton of the use of 'common').

ICH eCTD Q&A 46 states “all regions have agreed to accept PDF 1.4. Please consult regional guidance to submit other versions of PDF.”. Clarification is required about the acceptability of versions of PDF other than PDF 1.4 in the EU region.

It is noted that the planned EU eCTD Validation Criteria will include a statement that all files should be PDF 1.4.

However, it is also noted that some specific EU NCAs require the use of Acrobat Forms and other documents created in later versions of PDF and 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.

Feb 08: New proposal with simpler wording to come from EFPIA, clarifying further the use of PDF versions.N.B. EU Validation Criteria specify v1.4 (but warning only).

All PDF files included in the eCTD should be v1.4 except where there is an agency specific requirement for a later version eg. for an application form.

The Best Practice for eCTD in MRP/DCP (draft v0.4) includes as requirement to provide a table as a file under 1.0 Cover Letter that keeps track of the sequences, when and when they have been submitted. This will allow each NCA to know that any ‘missing’ sequences are not relevant to 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.

To be included in eCTD v1.3 2008

Format and layout of the table to be defined by eCTD Interlinking Group.

The proposed new EU M1 CTD Guidance from NtA includes a new section 1.10 Information relating to Paediatrics. The eCTD specification should be updated in line with the new CTD structure.

Ms Nadine SchwarzCSL Behring AG

EU Module 1 specification, Appendix 1 "Envelope Element Description", therein element = submission and attribute = type (p. 10)

As a manufacturer for plasma products, CSL have a centrally authorised Plasma Master File (PMF). Following the centralised authorisation of the PMF the PMF 2nd Step Procedure must be performed. In this 2nd Step Procedure, the PMF certificate must be submitted for each product in order to make the link between PMF and the product's marketing authorisation. According to the "Guideline on Plasma Master File (PMF) And Vaccine Antigen Master File (VAMF) “Second Step”" this is NOT a variation 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".

Refer to eCTD Interlinking Group to write interim guidance on which submission type to use.March-09 : Draft guidance is under development by EMEA, taking into account the new regulations, and will be circulated to the Interlinking group for endorsement

eCTD PMF Guidance published June 2009. In addition, the inclusion of a submission type 'PMF' should be included in the EU M1 specification v1.4, list of envelope 'submission type' values.





CR-20080514 Kevin Wing, eCTDConsultancy EU Module 1 Specification v1.2.1 Completed Completed TIGes

CR-20080514-01 EU Module 1 Specification v1.2.1 Completed Completed TIGes

CR-20080514-02 Kevin Wing, eCTDConsultancy EU Module 1 Specification v1.2.1 Completed Accepted Implement in next version of EU M1 specification v1.4. TIGes

CR-20080514-03 EU Module 1 Specification v1.2.1 Rejected Rejected None N/A

CR-20080514-04 Kevin Wing, eCTDConsultancy EU Module 1 Specification v1.2.1 Completed Accepted - refer to Q&A TIGes

CR-20080514-05 EU Module 1 Specification v1.2.1 See CR-20080514-04 -guidance to be produced. Completed Open TIGes

CR-20080610 Andrew Marr, GSK EU eCTD Validation Criteria Completed Implemented in EU validation criteria v2.0 Implemented in EU validation criteria v2.0

CR-20080610-01 Andrew Marr, GSK EU eCTD Validation Criteria Check all references Completed Implemented in EU validation criteria v2.0 Implemented in EU validation criteria v2.0

CR-20080610-02 Andrew Marr, GSK EU eCTD Validation Criteria Completed Implemented in EU validation criteria v2.0 Implemented in EU validation criteria v2.0

CR-20080627 EU M1 Specification v1.3 Article 61(3) exists as a submission type in the EU M1 specification v1.3 Rejected Rejected None N/A

CR-20080703 Andrew Marr (EFPIA) EU M1 Specification v1.3 Completed Produce Q&A and update Best Practice Guidance eCTD Interlinking Group

The example provided for the application number element description on page 9 of the guidance is in the format of an EMEA Marketing Authorisation Number i.e. EU/1/00/150/001 and not an EMEA Procedure Number such as EMEA/H/C/XXX/X/XX.

The accompanying description that this is the “number assigned to the application by the receiving agency” suggests that what is meant here is the procedure number, and not the marketing authorization number (which would only be assigned upon approval and would also be strength-specific). This is supported by the explanation provided on page 14 of the EMEA’s recently released Q&A on eCTD Implementation (7th February 2008). Change the example for the application number element from:EU/1/00/150/001toEMEA/H/C/XXX/X/XX.And add a clarification to the description that the number required for this value is the procedure number.

Refer to eCTD Interlinking Group for discussion and drafting of Q&A on what is expected in that field. Draft survey for MS on requirements for application/procedure number, and use of this element.

Complete the survey for MS on requirements for application/procedure number, and use of this 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.

Clarification of the use of the application number provided in the envelope will most likely be needed in EU M1 v1.4, as well as a change to the provided example in the spec. Exact instructions for clarification/change still need to be provided by the TIG

Anne Mieke Reijnders, eCTDConsultancy

Since this information is mandatory in the cover letter, variation and renewal application form and is useful for retrieving information from the eCTD lifecycle it would be beneficial to add the Marketing Authorization Numbers to the EU M1 envelope information.

Refer to eCTD Interlinking Group for discussion and drafting of Q&A on what is expected in that field. Draft survey for MS on requirements for application/procedure number, and use of this element.

Complete the survey for MS on requirements for application/procedure number, and use of this 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 envel


Same as 20080514

The EU Module 1.2.1 specification only includes instructions relating to 1.3.1 SPC, Labelling and Package Leaflet identifiers and Language/Country Codes in the context of document filenames/folder paths. This information is also required as XML metadata and this change request is to update the specification to clarify this requirement.

TIGes 6 March 09 : Progress revised Q&A that incorporates 'refer to regional guidance' for ICH Q&A 57 relating to the use of xml:lang

May 2009: Proposal for text received by Kevin Wing for inclusion in the next specification version.

Implement revised text as provided by Kevin Wing in EU M1 v1.4

Text may need to be amended in light of new variation regulation.


Since sequence numbers do not have to be used in sequential order it would be beneficial to add the submission date back into the EU M1 envelope information.

The Cover Letter and tracking table if appropriate should be used to track the date - it is not useful ot have it in the envelope.


The concept of the Regulatory Activity was introduced within the EU 3 years ago and has been presented/discussed at conferences, implemented by some vendors and is included as a term in the EMEA’s Q&A Relating to Practical and Technical Aspects eCTD Submission (7th February 2008).

The “Example of the use of the Related Sequence” section on page 11 of the EU M1 eCTD guidance describes use of the related sequence element to groups eCTD sequences into 3 Regulatory Activities (an MAA, a technical variation and a labelling change variation).

In the afore-mentioned EMEA Q&A document, it is the Application Number (procedure number) that is described as the “envelope element which is used to group together submissions relating to a particular regulatory 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?

Refer to guidance on use of related sequence, which has been improved and is robust with EU M1 v1.3.EMEA Q&A guidance should be amended to refer to EU guidance on use of related sequence, but to indicate that application number is used in addition. Depend

Following completion of the EU survey, produce Q&A on use of application/procedure numbers and include this clarification in EU M1 v1.4

Related to CR 20080514, and the use of the application number. Clarification of the use of the application number particularly with regard to the grouping of submissions into reglatory activities should probably be provided in EU M1 v1.4.

Unlikely that this can be implemented due to time needed to finalise requirements - see CR-20080514


The application number element description on page 9 of the guidance states that this is the “number assigned to the application by the receiving agency”. Given the explanation provided on page 14 of the EMEA’s recently released Q&A on eCTD Implementation (7th February 2008) we presume that for Centralised Submissions, the EMEA procedure number is meant here (see accompanying change request).

In DCP, MRP and especially National Procedures already several numbers are used to identify a submission. To avoid misunderstanding clear definitions and guidance of what number to use where is needed.

For instance in The Netherlands for a MRP submission the MRP procedure number and a case number has to be used (and of course the MA number).

Could the TIGes provide feedback/guidance on the definition of the Application Number element for MRP, DCP and National Procedures.

Complete the survey for MS on requirements for application/procedure number, and use of this 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 envel


EU validation criterion #37 defines that no file should have been scanned at a dpi of more than 300. The ETICS testing demonstrated that it does not 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.

EU validation criterion #45 refers to EU Q&A as its reference. This is incorrect as it is ICH Q&A 36 - change reference.There is an inconsistency between EU validation Criterion #11 and #18 relating to the title field when the delete operation is used. #11 states ‘Every leaf or node extension 'title' attribute is not empty’. #18 states ‘If the value of the operation attribute is delete,……title is not required…..Consistency should be introduced.Additionally the wording of #11 could be improved to state “No leaf or node 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 #20Or – agree that title remains optional and therefore modify #11 to provide an exception when the delete is used.

Change criterion #18 to indicate that the title should be included when delete is used, but included a statement to indicate that this is not consistent with the ICH criterion #20.Create an ICH CR to indicate that ICH criterion #20 should refer to regional guidance.

NMs Nadine Schwarz, CSL Behring AG

As a manufacturer for plasma products, CSL have eCTDs for products which are registered under the Central Procedure and the Mutual 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.


The list of submission types included in the eCTD Module 1 specification v1.3 does not include Repeat Use Procedure. What submission type should be used for this submission?

As part of the creation of EU Module 1, v1.3 and in conjunction with the development of the eCTD in MRP/DCP Best Practice document consideration was given to the creation of ‘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 longer-term update the Best Practice guide.7/2010 - Included in Best Practices Guide

Accepted - refer to Q&A and include in updated Best Practice Guidance7/2010 - move to closedCompleted





CR-20080703-01 Andrew Marr (EFPIA) EU M1 Specification v1.3 Completed Produce Q&A eCTD Interlinking Group

CR-20080806 Remco Munnik, Sandoz EU M1 Specification v1.3 Completed Accepted Implement in next version of EU M1 specification v1.4. TIGes

CR-20080903 Alastair Nixon, GSK EU M1 Specification v1.3 Completed Implemented in new dossier requirements Dossier requirements updated April 2009

CR-20080903-01 Alastair Nixon, GSK MRP/DCP Best Practice Guidance Completed Implemented March 2009 CMD(h) press release included statement

CR-20080909 Leigh Sandwell, Pfizer eCTD Guidance Completed Implemented in Harmonised Guidance Agreed wording include in Harmonised eCTD Guidance v1.0

CR 20080909-01 Dietmar Boecker, Bayer Schering eCTD Guidance Withdrawn Not implemented None taken EMA No

CR 20081008 Andrew Marr, GSK (EFPIA) eCTD Specification v 3.2 Completed EMA

CR-20081210 Gerhardt Neurauter, Extedo EU Validation Criteria Completed Implemented in v2.1 of validation criteria Validation criteria v2.1 published

The list of submission types included in the eCTD Module 1specification v1.3 does not include a specific submission type for a change of the Reference Member State in MRP. What submission type should be used for this submission?

As part the development of the eCTD in MRP/DCP Best Practice document it was agreed that ‘Change of RMS’ would utilise an 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.7/2010 - In Best Practices Guide

Accepted - refer to eCTD Interlinking Group; 7/2010 - move to closedCompleted

Include notes from the Q&A #22 in the EU M1 v1.4.

In the text of page 16, under nr 4 it mentions: 'Note that the tracking table required with MPR/DCP submissions should be located within a 'common' directory, with the filename 'tracking.pdf' or 'tracking.xml’. However when you look to the examples for MRP and DCP, the tracking table is not included in the folder m1/eu/10-cover/common. Also in the screenshot on page 37, there should be a common folder under m1/eu/10-cover, which is missing.

Include the common folder in the examples for MRP on page 37 Include the tracking table in the example for MRP and DCP on page 45.March-09 : Confirmed by Interlinking

Clarify the use of 'common', and include examples of correct use for all procedures in EU M1 v1.4. Extract all screenshots and examples from the specification into a separate document (as agreed in TIGes 29th May 2009)

Copy requirements for eCTDs should be different from other electronic dossiers – all CHMP members should get an electronic copy of everything, including Type IA/IB variations – otherwise future lifecycle operators will be invalid.The current copy requirements do not differentiate between eCTD and NeeS. For Type IA and IB variations, only the Rapporteur requires 2 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.

Electronic copy requirements for Type IA and IB variations are split by NeeS and eCTD. For NeeS, they stay as they are. For eCTD, the requirements for Type IA and IB variations mirror those for Type II – i.e. “Other CHMP members: 1 electronic copy”.

The requirement for a cover letter in local language means that applicants preferring to centralise electronic dossier production, or following the preferred ‘Comprehensive model’ for eCTD in MRP/DCP must get a cover letter translated into all European languages before building the dossier. For submissions requiring an application form, this is unavoidable, since the form contains details of the MAH, and local contacts etc. However, for follow up measures, or simple administrative submissions, the requirement to get a cover letter translated up to 23 times is onerous and does not add value to the dossier (NB the rest of the content is likely to be in English). Could a ‘common’ English language cover letter be used for such submissions?

For submissions not requiring an application form, a single ‘common’ English language cover letter is acceptable in all MS. Identified as a hurdle for eCTD implementation. Cover letter is not covered by legislation, but nevertheless some MS have requirements for local laguage versions. HMA to try to persuade individual agencies to relax requirements for a cover letter in the local 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.

Current guidance requires that statements justifying absence of data in the eCTD should be provided in the QOS, non-clinical and clinical overviews, as applicable, and that no placeholder documents are required in the eCTD structure. The guidance should be updated to clarify how to deal with empty sections of Module 1 and any potential justification that may be required.

Recommend that empty Module 1 Sections do not require a justification statement to be included in each section and the Q&A document is updated to reflect Module 1.

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

Guidelines on the submission of the EU-RMP require a stand-alone format of the document including all annexes to be located in eCTD Module 1.8.2. This is in contradiction to the ICH eCTD requirements, that mandates a different location for most of the annexes.In section 4.4 of the EU-RMP guideline EMEA/CHMP/96268/2005 it is outlined that the EU-RMP "should be provided (...) in a stand-alone format 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:

2013/07: EMA has determined that this guidance is no longer in use and thus this CR can be closed.

The guidance just issued by QRD regarding production by the applicant of the PDF for final labeling is incompatible with the eCTD and will lead to duplication of effort.In the longer term EMEA must align their requirements and if there is business logic for the filename as per the EPAR proposed name then an EU specification change may be justified with the inclusion an appropriate filename that meets ICH general filename requirements.

In the short-term there is an urgent need for clarification as to how an applicant can submit product information inside and outside the eCTD, for all submission types without duplication of effort or risk of failure to validate or accept

Dec 08: EMEA meeting held to discuss issue - conclusion that requirements for EMEA PDFs arise from the EMEA EPAR publication process, and eCTD filenaming requirements have a different purpose and support a different process (review) and therefore requirements cannot be aligned until Q3 2009 when the EMEA publication process is re-designed. This conclusion was not readily accepted by industry - either alignment must be sought, or at least clear guidance should be provided as to how to manage in the meantime, and a clear plan for resolution should be presented by EMEAMarch 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.7/2010 - New version of naming guidance came out; practical Q&A also needed updating to be aligned, belief that Claire Holmes had drafted

Accepted - refer to EMEA7/2010 - Follow-up with EMA Business Group [G. Isakkson]10/2010 - transitioned to T. Mauer2/2011 - on hold9/2011 - EMA internal discussions ongoing2/2013: no further action needed per EMA

Amend 'Questions and answers' relating to practical and technical aspects of the implementation' to be updated

So far, the EU Validation Criteria do not verify the correctness of the overall checksum in the provided index-md5.txt. Guidance is given by the EMEA to provide this checksum in the cover letter, however, the possibility to verify the MD5 with the EURSvalidator is not given.Authorities not using the EURSvalidator perform checks with tools verifying the overall checksum. We received responses from clients that submissions are rejected due to invalid values in the index-md5.txt. However this issue is not part of the EU Validation Crieria. In case of MRP/DCP we encounter troubles that submissions are accepted only in regions the EURSvalidator is used.

Introduce to the EU Validation Criteria an additional issue: “The checksum of the index.xml should be calculated by a validation tool and compared with the checksum provided in the index-md5.txt.” In case of invalidity the recommended severity should be A.TIGes 6 March 09 : Agreed to progress as an urgent change and actioned to the EURS group





CR-20090126 NtA Volume 2B Section 2.7.6 Completed closed TIGes

CR-20090310 Andrew Marr, GSK EU Module 1 Specification v1.3 Completed Implemented in EU M1 v 1.4 TIGes

CR-20090310-II Andrew Marr, GSK EU Module 1 Specification v1.3 Develop regional guidance and include this in the next specification version (v1.4). Completed Implemented in EU M1 v 1.4 Develop Q&A on the use of stylesheets. TIGes

CR-20090506 Bil Ali, Shire Pharmceticals EU Module 1 Specification v1.3 Completed Implemented in EU M1 v 1.4 Implement in next version of EU M1 specification v1.4. TIGes

CR-20090506-II Bil Ali, Shire Pharmceticals EU Module 1 Specification v1.3 Completed Implemented in EU M1 v 1.4 Implement in next version of EU M1 specification v1.4. TIGes

CR 20090512-01 Kevin Wing, eCTDConsultancy Completed Implemented in 2011 guidance Implemented EMA None

CR-20090517 Andrew Marr, GSK EU Module 1 Specification v1.3 Remove ATC code from envelope. Completed Implemented in EU M1 v 1.4 Implement in next version of EU M1 specification v1.4. TIGes

CR-20090527 Donald Palmer, MedImmune EU eCTD Validation Criteria v 2.1 Completed Harmonisation Group

CR-20090603 Claire Holmes, EMEA EU M1 specification v1.3 Completed Implemented in EU M1 v 1.4 TIGes

The ICH M2 eCTD specification and Notice to Applicants Volume 2B provide different information concerning how to deal with the Synopses of Individual Studies in Section 2.7.6. The guidance should be harmonised to provide a similar message in both the CTD and eCTD and avoid confusion.The NtA guidance states: 2.7.6 Synopses of Individual StudiesThe ICH E3 guideline (Structure and Content of Clinical Study Reports) suggests inclusion of a study synopsis with each clinical study report, and provides one example of a format for such synopses.This section should include the table entitled Listing of Clinical Studies, described in guidance for Module 5, followed by all individual study synopses organised in the same sequence as the study reports in Module 5.It is expected that one synopsis will be prepared per study for use in all regions, and that the same synopsis will be included in this section and as 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.

TIGes 6 March 09 : Principle supported. Action to Interlinking Group to progress. Suggested that option of either hyperlinking to or inclusion of synopses.Recommend that the NtA guidance is updated to reflect the Section 2.7.6 guidance in the ICH M2 eCTD or clearly reference this difference between the paper and electronic outputs.March-09 : Interlinking agreed that hyperlinking should be an option for applicants. Q&A to be produced.April-09 : Interlinking group endorsed a Q&A for publication

Answer: It is acceptable either to include copies of the synopses for each study in Section 2.7.6 or to provide hyperlinks to synopses located in Module 5 without providing copies in section 2.7.6. In either case a Listing of Clinical Studies should be provided and this should include hyperlinks to the first page of each synopsis.

Approval date: 1.4.2009Answered and Implemented in EU M1 v1.4Completed

Include notes from the Q&A #22 in the EU M1 v1.4.

Or should this go in guidance instead?

At FDA there had been problems with processing some sequences provided by applicants because the filepath has been too long and has been truncated, either in production of hard media or in manipulation across servers within the agency. They proposed that

Propose to reduce the maximum fle path length from 230 characters to 180. However, a survey amongst regulators is required to assess acceptability of this maximum length. Consider whether a max. path of 180 should also be implemented in the NeeS design.

Carry out survey amongst regulators to assess whether 180 is a suitable maximum file path length for eCTD/NeeS, and if not, what the maximum reserve required is. If no objection received by 15th june 2009, reduce length to 180 characters and implement

If tacitly agreed by TIGes, change guidance on max. path length to 180 in EU M1 v1.4

ICH Q&A #50 addresses the inclusion of regional stylesheets It states that reference should be made to regional guidance on which version of the regional style sheets should be used. This is not explicitly stated in the EU Module 1 spec v1.3. The download package included a new version of the style sheet v1.3 but the text does not state that it should be included when Spec 1.3 is used. No regional guidance currently exists and should be developedIt should be clearly stated that the version of the style sheet published in the context of each specification version should be used. A Q&A should be produced that states this for v1.3. In future the specification and any transition guidance should also state this.

Include text from Q&A on stylesheets (once developed) in EU M1 v1.4

The description of the use of ‘COMMON’ in the specification and release notes documents are not clear, and sometimes contradictory. E.g., see page 8, 37 and 40 of the specification document, and section 2.23 of the release notes.

Propose to clarify the description of the use of the 'common' folder in the specification. Also remove screenshots from the specification and produce a stand alone document of examples, or incorporate these in the eCTD guidance document.

Decide on text for clarification of 'Common' and include in EU M1 v1.4 spec and examples.

The current guidance in the V1.3 M1 specification outlines the use of ‘COMMON’ folders with languages, but does not show how specific countries and language combinations should be associated with the use of the ‘COMMON’ folder.

Whilst this is not a problem when using common folders with the English ‘en’ language, which can apply to all countries, some non English languages only apply to specific countries, eg, ‘de’ for Belgium, Germany, and Austria, and ‘fr’ for Belgium and France etc.

Therefore, there may be cases where a ‘COMMON’ folder might be useful to apply to some languages, such as ‘de’, but only for the relevant countries.

Other cases exist for other country / language combinations.

Is it possible to give clear unambiguous guidance on the combination of country, ‘COMMON’ folder and language, such that the ‘COMMON’ folders are effectively identified by common languages across multiple countries, whilst still maintaining the current use of a ‘COMMON’ folder with the English language combination across all countries?

In our view it might be possible to associate specific countries in the M1 envelope, with a ‘COMMON’ folder and language metadata field to give a language related scenario. This should not entail any significant change to the specification or to add any additional metadata fields, but may need a change to the DTD to accommodate it.

If the use of the term ‘COMMON’ were perceived to complicate the eCTD view in lifecycle where multiple ‘COMMON’s’ might already exist, could the use of the language and its association with multiple countries alone be sufficient to highlight the relationship?

Propose to clarify the description of the use of the 'common' folder in the specification. Also remove screenshots from the specification and produce a stand alone document of examples, or incorporate these in the eCTD guidance document.

Decide on text for clarification of 'Common' and include in EU M1 v1.4 spec and examples.

User guide on how to generate PDF versions of the Product Information Guidance (with consideration of eCTD EU M1)

Question related to the filenaming of combined Product Information documents that are granulated per strength/pharmaceutical form, following the recent update to the EMA’s User guide on how to generate PDF versions of the Product Information.The recently released version of the EMA’s User guide on how to generate PDF versions of the Product Information includes updates to bring the filenaming specification in line with the EU M1 eCTD guidance (http://www.emea.europa.eu/htms/human/qrd/docs/52402007en.pdf).

An applicant may decide to granulate the combined Product Information per strength or per pharmaceutical form and for the eCTD this will need to be reflected in the filename. Would the TIGes be able to provide feedback on where the necessary text to provide this level of detail should be placed so that the filenames are still inline with linguistic review requirements?

Discussed at TIGes, Sep-09.Referred to EMA to answer as this is a specific issue for CP.

A change request had been received (CR-20070718-01) and considered by the Interlinking Group. Although this CR was eventually rejected it did raise the value of including the ATC code in the Module 1 envelope. It was concluded that the appropriate place for the ATC information was the Application Form and therefore the ATC code in the Envelope was redundant.

The ATC code should be deleted from the next version of the EU Module 1 specification

Remove ATC from envelope in EU m1 v1.4

Minor DTD change.

In looking through the EU eCTD Validation Criteria, it would appear that #29 and #45 are in conflict, if MS Word documents are included with the PDF formats in the same folder.Criteria #29 explicitly states that the MS Word files should not be in the eCTD backbone and be in the same folder (as the PDF). This would conflict with #45, which states that there are no unreferenced files in M1-M5 folders.

Change validation criterion #29 to clarify that "MS Word files, if requested, should not be included in the eCTD backbone but providedseparately" (i.e. remove reference to "in the same directory").

Discussed in CR subgroup 20091210. Proposal agreed, but implement with slightly different wording (take wording from EMEA practical/technical guidance).

Accepted; 7/2010 - Follow-up with EURS group [G. Isakkson]9/2010 - Redirected to Harmonisation Group2/2011 - Completed

Amend EU eCTD validation criteria with new wording. Publish as v2.2. Discuss in relation to the update of the Validation Criteria.Harmonisation Group: The issue was addressed and clarified when updating the validation criteria for eCTD version 3.0 published in January 2011 and coming into force by 1 September 2011.

Include notes from the Q&A #23 in the next EU M1 revision.

Analysis is currently underway to ascertain the impact of the new variation regulation coming into force 1st January 2010 on the eCTD. If any changes are needed to the eCTD to support the variation regulation, these should be implemented and a new v1.4 pu

Changes not known as yet - to be determined in a meeting of a dedicated subgroup to be held 18th June, and another early July.

Assess impact of new variation regulation on the eCTD EU M1 in a dedicated subgroup (already established) and produce changes as necessary to spec. and DTD.

Changes no identified as yet - sub-group to inform EU M1 drafting group as appropriate.





CR 20090605 Alastair Nixon GSK EMEA Post Approval Copy Requirements (EMEA/300339/2008) Withdrawn Not implemented Amend EMA post-submission guidance EMA No

CR 20090605-II Alastair Nixon GSK Completed Next major release Amend EMA pre-submission guidance EMA

CR 20090605-III Alastair Nixon GSK Completed Next major release Amend PSUR guidance EMA

CR-20090615 Alastair Nixon GSK Completed

CR-20090620 Claire Holmes, EMEA EU M1 specification v1.3 Agreed by EMEA Completed Implemented in EU M1 v 1.4 Implement in EU M1 v1.4 TIGes

CR-20090630 Karin Grondahl, MPA, Sweden EU eCTD Validation Criteria v 2.1 Completed Harmonisation Group

CR-20090701 Remco Munnik, Sandoz EU eCTD Validation Criteria v 2.0 Completed Harmonisation Group

CR-20090701-01 Thierry Le Ridant, Ethypharm Discussed by CR sub group 20091210 Rejected Rejected None N/A

CR-20090820 Bernadette Billet EU M1 v1.4 Completed Answered as Q&A #24 N/A

CR-20090903 Alastair Nixon GSK EU eCTD Validation Criteria v 2.1 Completed Harmonisation Group

CR-20090909 EU M1 v1.4 - Page 8 and 14 of the written specification Rejected Rejected None N/A

The CP guidance was recently changed to ensure that CHMP members always get copies of all sequences so that they maintain a full lifecycle for the eCTD. However, the guidance says that the electronic copy must be DVD or CD Rom (in the header of the table).

Eudralink can be used for communications less than 40MB, and although the general guidance for eCTD states that Eudralink messages containing eCTD sequences should be followed up with a copy of the submission on hard media (CD/DVD), an exception should be made for copies of sequences for Type 1A and 1B variations to CHMP members. EFPIA members would all like to be able to use Eudralink only for these submissions to CHMP members. Individual countries can then decide whether to process them into an eCTD lifecycle locally, therefore keeping an up to date set of all sequences, or ignore them.

Text in parentheses in first line in table is changed to “(unless in eCTD format, then 1 electronic copy via Eudralink (no CD/DVD required))”7/2010 - Completed in post-submission guidance, may need to update technical guidance 10/2010 - Not accurate, needs to be revisited2013/07: EMA has determined that this guidance is no longer in use and thus this CR can be closed.

EMEA Pre Submission Copy Requirements (http://www.emea.europa.eu/htms/human/presub/dossierrequirements.pdf)

Document has 2 missing footnotes, and requirements for individual modules for some countries which is not possible when using eCTDThe footnotes have gone (* in table header, ** for Czech Republic), and Austria, Bulgaria, Greece and Slovakia need a CD Rom of just m1 and m2, which you would not and cannot do in eCTD format.

Footnotes should be added back if necessary and a comment “(full sequence if eCTD)” is added to the entries identified.

Distribution Requirements and Address Lists for Periodic Safety Update Reports (PSURs)(Annex 6.2 of Volume 9A of the Rules Governing Medicinal Products in the EU)EMEA/129976/2008

Statement requires PSUR in both MS Word and PDF. This is not common practice (EFPIA eCTD Topic Group surveyed May 2009), applicants tend to provide PDF only and have had no feedback from agencies to the contrary.

Statement at top of document: “CD-ROM means PDF + WORD format (i.e. two formats should be submitted).” This is not common practice, nor should it be necessary as, with the right tools, it is possible to cut and paste content from PDF documents.

Sentence should be removed.7/2010 - In the absence of PV having access to the eCTD this needs to be addressed in business process

Currently no guidance, reference made in EURS meeting notes, October 2008.

Replacing documents across sections (eCTD elements - should be allowed or not? This is particularly relevant in the EU, where, for submissions containing content not yet in the DTD, applicants are encouraged to use m1-additional-data, then revert to the new section once available. Should the new document in the new location ‘replace’ the original in m1-additional-data, or should the document have the operation attribute of ‘new’, and the version in m1-additional deleted? In general, can some guidance be provided on the validity of using replace or delete operation attribute on a document which is no longer in the same location as the document that is being replaced or deleted?

Discussed at TIGes, Sep-09.Accepted as not good practice to carry out lifecycle across sections, though there are specific occurrences when this might happen (transition guidance and changes to section names).Q&A to be createdInclude statement in next version of specification/guidance7/2010 - only needed when next minor version required because of M1 section additions, not urgent 9/2010 - Agree that it should be a delete in the current section and a replace in the new.10/2010 - Interlinking agreed on following :CR is accepted.Agreement that the solution should be to 1) delete the original document in the m1-additional data and 2) add a new document in the correct place holder.Geoff Williams to write a Q&A. The Q&A will be ready for discussion/agreement in November.Q&A will consist of two sections.1) The answer will explain that the cross-linking is only allowed for specific transition periods, in which additional data is used and later the DTD defines the correct place2) That this practise should not be used normally across sections in eCTD1/2011 - Since all Q&As will be incorporated into the revised M1 guidance, this CR will be closed.

Accepted - refer to Q&A7/2010 - Follow-up with Interlinking Group9/2010 - Interlinking updated - G. Williams actioned10/2010 - Interlinking Group - Proposal agreed. Q&A to be drafted for Interlinking in November1/2011 - Q&A finalised; CR Completed; moved to Closed CRs

11/16/2010 for Q&AAlso when M1 is updated

10/2010 - Write Q&A #23 - G. Williams1/2011 - Move to Closed as Q&A #23 finalised

Paediatric studies in the context of Article 46 of Regulation (EC) No 1901/2006 (The Paediatric Regulation) must be submitted, and these afall within the scope of eCTD. A submission type 'Art 46' should therefore be included in the EU M1 specification.

Add new submission type to envelope - 'Art 46'.

Due to national archive requirements for ISO standard for PDF/A that is based on PDF 1.4, it is needed as an “A” criterion.Recommended solution to change categorisation from 'B' to 'A'.

Discussed at TIGes, Sep-09.No decision as parties could not agree

Discussed in CR Subgroup 20091210. More feedback on this needed from MPA. As this CR relates to SE national archive requirements, then national arrangements should be made but the specification should not change. Proposal to reject the CR, pending further feedback. 7/2010 - could be progressed as part of consideration for use of ISO 32000 (PDF 1.7) being discussed at ICH 10/2010 - Interlinking agreed on following:Issue should be referred to the Harmonisation group, which is responsible for the review of the validation criteria.

Accepted - refer to Interlinking Group7/2010 - Follow-up with Interlinking Group9/2010 - Transitioned to Harmonisation Group2/2011 - Completed

9/2010 - Refer to Harmonisation Group for consideration with validation criteria updateHarmonisation Group: The issue was addressed and clarified when updating the validation criteria for eCTD version 3.0 and NeeS version 2.0 published January 2011 and coming into force by 1 September 2011. PDF 1.4 should normally be used and earlier versions are not accepte (Pass/Fail criteria). The need for including PDFs of later versions should be explained, but is not a Pass/Fail criteria.

For the NeeS validation criteria it was added that for file security modules 4.3 and 5.4 should be excluded from a check: “Security Settings:There is no security setting on any file in the submission, (does not apply to files located in 4.3 and 5.4)”

In order to align the eCTD validation criteria with the NeeS validation criteria, this CR is submitted to add the exception for the eCTD validation criteria, nr 41:“There is no security setting or password protection on any individual file”.

Discussed at TIGes, Sep-09.Referred to Harmionisation Task Force to identify suitable wording for the next version of the guidance document.7/2010 Should be progressed together with CR 20090903.

Accepted - refer to Harmonisation Group7/2010 Follow-up with Harmonisation Group9/2010 - Harmonisation Group updated2/2011 - Completed

9/2010 - Discussed in relation to the update of the Validation Criteria.Harmonisation Group: The issue was addressed and clarified when updating the validation criteria for eCTD version 3.0 and NeeS version 2.0 published January 2011 and coming into force by 1 September 2011.

EU M1 specifciation 1.3&Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD Applications Version: 1.0 May 2009

In eCTD the sequence folder (0000) is included in the "top level folder" (ICH eCTD 3.2.2 page 6-1) The ICH guideline recommends to consult regional guideline but currently there is not any naming recommendation.In case of MRP/DCP should we use the MR/DCP number or national case number ?Should we use only the procedure number or a combination of inn+strength+procedure number ?In a national procedure, what is the wish of each member states?How to manage multiple strength eCTD applications?

Guidance on this already exists in Annex II of the EU M1 v1.4 Annex.

The <related-sequence> element is declared in the EU v1.4 envelope.mod file with an optional country attribute. This attribute was removed in the v1.3 revision of the specification and is not mentioned in the text of the v1.4 specification. Should this attribute ever be used?

Discussed at TIGes, Sep-09.This was acknowledged as an error, there should be no country identifier on the related sequence.An immediate Q&A should be drafted to prevent software vendors from building this into tools for v1.4Correct in next version of specification.

Answered in Q&ACompleted

In the EU validation rules, there are 6 modified file checks. The first (rule 15) checks that no modified file references an invalid document, but has the proviso that submissions may be received out of order, and the sequence containing the leaf with the ID in the modified file attribute might not yet be loaded into the system. Therefore, if the system cannot find the ID in previous lifecycle, only a warning should be given (Cat C).

Discussed by CR subgroup 20091210. Proposal accepted for implementation in the validation criteria. The revised EU M1 validation criteria v2.2 should be issued with a note indicating that implementation/compliance from tool vendors is expected within 6 months of publication. Publication of v2.2 should also include guidance to regulators, indicating that if errors/warnings on the modified file are received during the transition period, then they should contact the applicant before rejecting the submission on those grounds.7/2010 Highest priority, content of CR superseded by more recent version submitted June 14th (same number); eCTD TG recommended bringing together all the validation CRs.

Accepted 7/2010 CCB recommends moving to Harmonization Taskforce9/2010 - Harmonisation Group updated2/2011 - Completed; moved to Closed CRs

Update EU eCTD validation criteria v2.1 based on proposal from AN.Harmonisation Group: The issue was addressed and clarified when updating the validation criteria for eCTD version 3.0 and NeeS version 2.0 published January 2011 and coming into force by 1 September 2011.

Anne Mieke Reijnders, eCTD Consultancy

Page 8 of the written specification, second bullet point, refers to “group number/ periodic report number” . Does periodic report here mean annual report?The annual report, type IA notifications for one product, is not considered “grouping” in the EU Procedural Guideline Annex of February 2009.Moreover, for annual report (or for any other grouping per product) no additional numbers are needed, the submission could use the regular variation and sequence number. Page 14, table, specifies that the mode grouping should be used for periodic reports, this seems superfluous as explained above.

Recommendation in CR form: Keep the annual report which is submitted for one product separate and simple: no additional mode’s or grouping numbers are necessary. It is a regular regulatory activity that can be handled by the eCTD.

Proposal rejected as the Annual Report should be defined as a grouped variation submission.Term 'Periodic Report' should be removed from the EU M1 v1.4 specification. This action is captuured in CR 20091210.





CR-20090909-04 EU M1 v1.4 Rejected Rejected None N/A

CR-20090909-06 Rejected Interlinking Group

CR-20090909-07 Kevin Wing, eCTDConsultancy See details in CR form Rejected Rejected None N/A

CR-20090909-09 EU M1 v1,4, Page 7 of the specification Rejected Rejected None N/A

CR-20090909-11 EU M1 v1.4, Page 9; Section on Node Extensions Rejected Rejected None N/A

CR-20090909-12 Rejected Rejected None N/A

CR-20091015 Katrin Spaepen, Comply Services Rejected Interlinking Group

CR-20091016 Karin Grondahl, MPA, Sweden Completed eCTD Interlinking Group

CR-20091116 Caroline Keller, Novartis Pharma EU eCTD Validation Criteria v 2.1 Harmonisation Taskforce are responsible for NeeS Guidance and validation criteria. Completed Harmonisation Group


According to the draft EU Procedural Guideline Annex of February 2009 the variation regulation is set up to reduce the number of variations and administrative burden for Agencies and Industry. This to enable competent authorities to focus on those variations that have a genuine impact on quality, safety or efficacy. Looking at the “translation” of EC 1234-2008 into eCTD the administrative burden seems only to increase.An example is the consolidation sequence, mentioned on page 17 of EU M1 Annex v1.4: A consolidation sequence should always be sent at the end of the procedure, reflecting the approved scope of the variation.

The table on page 17 of EU M1 Specifications v1.4 describes a final sequence in the regulatory activity with updated agreed product information. This is already common practise if labelling is involved in the variation. However the requirement of an additional sequence submission at the end of all variations (per MRP/DCP and per country)seems to increase the administrative work (and costs) at both sides. As long as eCTD is based on one-way communication the approval or any other information from the authorities is not part of the eCTD.

Recommended in CR form: Delete the requirement for a consolidation sequence from the M1 annex v1.4

Discussed by CR subgroup 20091210. Regulators strongly advise consolidation sequences and industry agree. Already done for parallel variations. Consolidation sequences are a valid part of the lifecycle. Reject CR.


EU M1 v1.4, Annex p17 and 18. For both grouping and worksharing of variations page 17 and 18 of EU M1 Annex v1.4 state that: “ Note that for each affected marketing authorisation, a separate eCTD submission must be provided”.In addition page 19, 2nd paragraph states “The ICH eCTD v3.x specificationonly allows the submissions of information relating to a single marketing authorization” However, EC 1234-2008 article 7(2) (b) refers to a single notification or a single application in case of grouping. According to the draft EU Procedural Guideline Annex of February 2009 one cover letter and application form should be used.

Could you clarify and confirm the use of identical cover letters and application forms for the separate eCTD’s?

Discussed in CR subgroup 20091210. A template for a cover letter exists, and this indicates that it is country-specific. EMA however seems to be of the opinion that the cover letter should be identical for all countries. Guidance does exist for both AF and cover letter. Take to Interlinking for clarification. 7/2010 - This would be resource saving10/2010 - Interlinking agreed on following :CR is rejected.This CR was submitted before the final documentation on the new variation regulation was published.According to the published (guidance) documentation, it is clear that for a grouped or Worksharing variation, one common Application Form, which lists all affected MA's is submitted.For the cover letter the CMD(h) Best Practise Guide on Variations refers to the use of a common cover letter for grouping of multiple MA's.

Accepted - refer to eCTD Interlinking Group7/2010 - Follow-up with Interlinking Group9/2010 - Interlinking discussed; remains open. Owner of Module 1 specification is TIGes with EMA as rapporteur10/2010 - Interlinking - CR rejected.

When M1 specification is updated9/2010 - Need to resolve concerns from France and Spain re national application forms

EU M1 v1.4, Page 14 - 15 of the written specification. Page 44 of the DTD.Pages 16 – 20 of the specification annex.

Changes to (1) DTD and (2) specification in relation to the <submission> “mode” attribute, the <submission><number> element and its value and the <tracking><number> element and its value.

Misunderstanding of the specification - reject CR.


Missing Files - The CTD guidance addresses how to justify missing data that should be available for a proper evaluation of the quality, safety and efficacy of the drug. The eCTD guidance should only add guidance to the nodes in a ToC that do not have leafs, because these are irrelevant to for the proper evaluation of the quality, safety and efficacy of the drug.

Recommendation on CR form: The correct wording should be:“Handling of Empty or Missing eCTD SectionsNote that placeholder documents highlighting 'no relevant content' should not be placed in the eCTD structure, as these would create a document lifecycle for non-existent documents, and unnecessary complication and maintenance of the eCTD.The justification of absence of scientific data, is irrespective of the dossier format (paper CTD or eCTD) and should be provided in the relevant Quality Overall Summary and/or Non-Clinical/Clinical Overviews (Module 2.3, 2.4, 2.5).

Discussed in subgroup 20091210. Guidance is considered already clear.


The use of the terms node extensions and subfolders is often confusing for users of the eCTD. It should be made clear what the differences are, before mentioning these two items together in a bullet in Section Node Extensions on Page 9.Furthermore, the use of node extension is not sufficiently investigated in interoperability tests across multiple software tools. From the FDA it is clear that not all tools show the node extensions as intended and switching from one tool to the other might even result in an inability to maintain lifecycle on leafs located in a node extension.Finally, the main reason for encouraging the use of node extensions is eliminated by adopting the STF, developed up to Step 4 by the ICH.This change request is either to clearly address the particulars related to subfolders and node extension, or to prohibit the use of node extensions and encourage the STF

Recommended on CR form: Either clearly address the particulars related to subfolders and node extension as described above, or prohibit the use of node extensions and encourage the STF. Note that not all items listed in an STF are to be included.

Reject. The specification should not be changed based on differing interpretations from vendors. Node extensions meet important business needs. The STF is built to meet US regional requirements and submissions cannot and should not be fully re-used across regions in any case.


EU M1 v1.4, Examples on Page 10 of the written specification concerning Directory/File structure and Page 21 Row 8 of Appendix 2

The written specification as well as Appendix 2 provide examples of file names. However, the examples of the variable text are confusing. As a general rule, the variable parts should be meaningful. common-form-pheurcertificate.pdf and pt-form-proofpayment.pdf do, but it-form-annex1.pdf and common-form-annex12.pdf do not. The annex numbering is related to the application form for an initial MAA and line extension only. Hence, proof of payments, certificates of suitability related to variations can never be considered a numbered annex. Therefore, a consistent use of descriptive terms is considered to contribute to a consistent and unambiguous guidance.

Recommended on CR form: Remove the examples it-form-annex1.pdf and common-form-annex12.pdf from respectively Pages 10 and 21.

Discussed in CR subgroup 20091210. Reject. The leaf title should be used to identify the file, rather than the file name, if the eCTD is beng used properly. The file naming convention and folder structure should not be relied upon. The examples given in the specification are considered adequate and should not be changed.

Best Practice Guideline “Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD electronic Submissions

Can the eCTD sequence serving as the baseline be used as a sequence to harmonise formats (e.g. paper to eCTD format) but also as a sequence to harmonise procedures (e.g. DCP to MRP)?

Proposed solution: To use the baseline submission not only to harmonize to the eCTD format but also to harmonize the procedures and move from the DCP to the MRP procedures for Member States MS1 to MS5 and to number the baseline sequence 000X (in this example 0010). In practise, this means that the Module 1 information as used for an MRP will be applied for MS1 to MS5 in the baseline submission and that the so called baseline submission equals the “sequence 0005” including the country specific information as per Chapter 7 of the NTA as in the example on page 10 of the CMDh Best Practise Guide on the use of the eCTD in the MPR and DCP dd. April 2008.

Discussed at TIGes/NtA Interlinking Meeting 20/10:Agreement in principle to use the baseline to harmonise the procedures using the baseline. Guidance is needed on this, on how to use eCTD metadata in repeat use. The Procedure Type element at least should change from DCP to MRP.7/2010 - Discussed at Interlinking 15 Dec; conclusion that guidance was clear enough on this matter

Accepted - refer to eCTD Interlinking Group7/2010 - Interlinking Group concluded in 15 Dec 09 to reject and close

Produce additional guidance on the use of eCTD metadata in an eCTD 'baseline' submission for changing in repeat use from MRP to DCP. Guidance to go into the eCTD Best Practice Guide for MRP/DCP. (KG)

Check existing baseline guidance in eCTD harmonised guidance to ascertain if it is sufficient. (CWH)If necessary, clarify in eCTD harmonised guidance that old NTA format Parts 3 and 4 should also be converted to eCTD if they are submitted electronically. (KG)

Assigned to GW and KG (Interlinking Group).

Best Practice Guideline “Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD electronic Submissions

If an applicant has an old dossier in mixed format, Module 1-3 in CTD format and Module 4-5 in the old NtA format (Part 4-5), how should it be submitted when changing over to eCTD format?

If the dossier is not totally changed into CTD format, the eCTD could only contain Modules 1-3 and the old parts have to be kept in NtA format outside the eCTD , but in what format?

Discussed at TIGes/NtA Interlinking Meeting 20/10:The CTD guidance allows applicants to send modules 4&5 in old NtA format (in repeat use MRP only). For submission in electronic format, 2 options were proposed: submission of modules 4&5 in paper with the remainder electronic, or convert into CTD and submit all modules electronically.If full electronic format is produced, this should follow the CTD structure as normally required. Additional guidance/clarification of these options are needed in the eCTD Best Practice Guide for MRP/DCP.7/2010 - Included in Rev 1 of Best Practices Guide as section 4.10

Accepted - refer to eCTD Interlinking Group7/2010 - move to closedCompleted

Produce first draft of guidance to go in the BPG

Assigned to KG (MPA)

The NeeS validation criteria 0005 for EU M1 filenaming convention is stricter for 1 of the items listed: “the variable part, if used, does not include hyphens”. This criteria is listed as an A Category. In the eCTD validation criteria, the number 35 for following EU filenaming convention is classified as a B.This difference makes it somewhat confusing for the applicant and also more difficult to implement if too rigid.

Since the use of hyphens is no showstopper for the use of the NeeS submission, the proposal is to have the NeeS criteria 0005 changed to match the eCTD criteria 33 and 35, including the prioritization.

Accepted - refer to Harmonisation Group7/2010 Follow up with Harmonisation Group9/2010 - Harmonisation Group update2/2011 - Completed

Discuss in relation to the update of the Validation Criteria.Harmonisation Group: The issue was addressed and clarified when updating the validation criteria for eCTD version 3.0 and NeeS version 2.0 published in January 2011 and coming into force by 1 September 2011.The naming convension is a Pass/Fail criteria for NeeS module 1-3 as this is the main navigation aid. For eCTD it is only a BP test since the XML is the main navigation tool. Hyphens is accepted.





CR-20091116-01 Caroline Keller, Novartis Pharma EU eCTD Validation Criteria v 2.1 Harmonisation Group are responsible for NeeS Guidance and validation criteria. Completed Harmonisation Group

CR-20091116-02 Caroline Keller, Novartis Pharma EU eCTD Validation Criteria v 2.1 Harmonisation Taskforce are responsible for NeeS Guidance and validation criteria. Completed Harmonisation Group

CR-20091116-03 Caroline Keller, Novartis Pharma NtA Volume 2B Section 2.7.6 Duplicated Duplicated None N/A Refer to 20090126 and Q&A #22

CR-20091116-04 Caroline Keller, Novartis Pharma NtA Volume 2B Duplicated Duplicated None N/A Refer to CR-20080909-01.

CR 20090909-01 EU M1 eCTD Specification v 1.4 Completed




The NeeS validation criteria 0011 for the pdf version is listed as an A issue, while this is only a B issue in the eCTD validation criteria (#37). Moreover, the comment of the NeeS criteria indicates that there are some national exceptions, which makes it somewhat confusing.

Recommendation: Turn the NeeS validation criteria 0011 to a B category.


Discuss in relation to the update of the Validation Criteria.Harmonisation Group: The issue was addressed and clarified when updating the validation criteria for version 3.0 published in January 2011 and coming into force by 1 September 2011. (see CR-20090630)

The NeeS validation criteria 0012 for the pdf quality (no broken hyperlinks and bookmarks) is listed as an A issue, while this is only a B issue in the eCTD validation criteria (#38 and 41).

Recommendation: Turn the NeeS validation criteria 0012 to a B category.


Discuss in relation to the update of the Validation Criteria.Harmonisation Group: The issue was addressed and clarified when updating the validation criteria for eCTD version 3.0 and NeeS version 2.0 published in January 2011 and coming into force by 1 September 2011.Hyperlinks should be 100% functional from TOCs in NeeS (Pass/Fail) but otherwise it is a BP test.

Could you clarify how the section 2.7.6 should be handled? The Notice to Applicant for section 2.7.6 states “This section should include the table entitled Listing of Clinical Studies, described in guidance for Module 5, followed by all individual study synopses organised in the same sequence as the study reports in Module 5.” This seems to be not in line with the eCTD rules as this leads to duplication of the document.

The eCTD rules state that documentation should reside in the most appropriate section and duplication of documents should be avoided. However, the Notice to Applicants mentions for section 2.7.6 “This section should include the table entitled Listing of Clinical Studies, described in guidance for Module 5, followed by all individual study synopses organised in the same sequence as the study reports in Module 5.” This seems to be not in line with the eCTD rules as this leads to duplication of the document.

Could EMEA clarify how the supportive documentation of RMPs should be handled? The Notice to Applicant for section 1.8.2 states that the section should be stand-alone, which seems to be not in line with the eCTD rules this may lead to duplication of supportive documents (e.g. literature references in 1.8.2 and 5.4 or study protocols in 1.8.2 and 5.3).

The eCTD rules state that documentation should reside in the most appropriate section (e.g. literature references in 3.3, 4.3 or 5.4 as appropriate) and duplication of documents should be avoided. However, the Notice to Applicants mentions that “The RMP should be presented in a stand-alone format (separate volumes in paper) allowing circulation to, and evaluation by pharmacovigilance and risk management experts. It should be accompanied by other relevant documents such as study protocols, where applicable.”This seems to me conflicting as this can lead to duplication of documents and therefore increased life-cycle maintenance issues.


The EU m1 specification document uses the term “application” in ambivalent ways, namely to identify (1) a full history of an eCTD, including all sequences pertaining the electronic common technical dossier and (2) a single sequence/submission as part of an electronic common technical dossier. The specification document should use unambiguous terms and use “application” consistently [Page 7 of the written specification]

Recommendation in CR form: The correct wording should be: “Files can be referred to across modules (e.g. from Module 1 to Module 2) or across sequences within the same eCTD; note however that it is not possible to refer to files in other eCTDs.”It might be wise to add a glossary to the written specifications, the make the difference between CTD/eCTD and submission/sequence. In addition the word application can be explained, being an act of applying for something. It is also suggested to align with existing glossaries, such as the one for RPS.

Accepted7/2010 - Follow-up with EMA Business Group [G. Isakkson]9/2010 - Owner of Module 1 specification is TIGes with EMA as rapporteur2/2011 - On hold per EMA8/2011 - Completed; moved to Closed CRs

Include the Glossary from the EU harmonised eCTD guidance, and include in the EU M1 specification. Review the use of all terms in EU M1 v1.4 according to this glossary, and update as necessary on next minor version.

TIGes/EMA rapporteur / Interlinking Group


The EU Module 1 specifications suggest that response documents are written per country in multi-country submissions. This is incorrect.1. For CPs, the country code is always “emea” and does therefore not bring any added value.2. For bilateral phases during the MRPs and DCPs, the responses correspond to consolidated lists of questions and the country code is therefore always “common”.3. For national phases following the MRP and DCP, the exchange of information on a faithful translation of the common harmonised product information might be outside of the eCTD (i.e. eMail and telephone calls). The eCTD will not be relevant at all.4. For national procedures, the country code is not relevant at all.Hence, the country code should be removed from the written specifications as well as from the DTD.[Page 33 and 34 of the written specification concerning Rows 67 and 68 of the Appendix 2Page 43; eu-regional.DTD]

Discussed by CR subgroup 20091210. Agree in principle with the proposal; however this approach must be agreed by regulators. Decide whether responses are country-specific. There are places where emea' is synonymous with 'common' but these must be defined.9/2010 - Agreed to keep DTD as is and amend the text in the M1 specification to indicate that responses are 'common', not country specific.10/2010 - Interlinking agreed on following :CR is accepted.Agreement is that responses are common documentation. However, the Interlinking doesn't recommend an update of the specification to remove the variable components in the response section.Due to the fact that national translations can still be handled within the eCTD, the variable part will not be removed from the specification.

Remco Munnik will draft a Q&A document in which it is clarified that responses are common documents and therefore common folder and variable part should be used.

Accepted - refer to Interlinking Group7/2010 - Follow-up with Interlinking Group9/2010 - Interlinking discussed; remains open until next edit. Owner of Module 1 specification is TIGes with EMA as rapporteur10/2010 - Interlinking Group - Q&A to be drafted.12/2010 - Remco Munnik actioned to draft2/2011 - M1 spec update on hold per EMA05/2011 - Draft available. Open for discussion.8/2011 - Completed; moved to Closed CRs

Updated Module 1.4 specification TIGes/EMA rapporteur & Interlinking Group


As for the envelope of an eCTD for the CP, the EU M1 specifications do not allow to use “common” in the ToC of an eCTD for the CP. However, this are two distinctly different topics. The omission of a common envelope for attribute information is OK, whereas there are documents used in eCTDs which are considered common, irrespective of the procedure (CP, MRP/DCP or NP), such as many annexes to the application form, such as:1. Certificate of Suitability on active substance2. Curriculum vitae of the qualified person for pharmacovigilance3. Declaration from the qualified person 4. Manufacturing authorisation5. Justification of multiple manufacturers for batch release6. Flow-chart indicating all sites involved in the manufacturing process of the medicinal product or active substance 7. GMP certificate8. Ph. Eur Certificate of Suitability for TSE9. Written consent on GMO release in the environment10. Scientific advice given by -<agency name> <YYYYMMDD>11. Copy of marketing authorizations12. Correspondence on multiple applications13. Orphan designation decision14. List of product names and marketing authorization holders in CMSs15. Conditions and documents to support the Type I variation16. Supportive data package17. Comparison documentThis becomes particularly important to facilitate grouping of variations and work sharing across multiple procedures without rework of the locations of these documents in cloned eCTD sequences.[ Page 9 of the written specification concerning Directory/File structureSentence: “For the Centralised Procedure, the country subdirectory is always named "emea" and………..”]

Recommended: The correct wording should be: “For the Centralised Procedure, the country subdirectory is always named "emea" with or without “common” and……….”

Discussed by CR subgroup 20091210. it is believed that 'common' can be used for all parts of the dossier in CP, apart from in the envelope. Implement based on review of change of EMEA to EMA (CR 20091203).

Accepted referred to EMA business team7/2010 - Follow-up with EMA business group [G. Isakkson]10/2010 - transitioned to T. Mauer2/2011 - On hold per EMA8/2011 - Completed; moved to Closed CRs



For both grouping and worksharing of variations page 19, 2nd paragraph, of EU Annex v1.4 states that: “The ICH eCTD v3.x specification only allows the submissions of information relating to a single marketing authorisation. Therefore, when submitting a grouping or worksharing of variations, the eCTD submissions must be copied per marketing authorisation.”

Could you rephrase “copied” because depending on the individual product lifecycle different operation attributes, sequence numbers may be used.

Recommended on CR form: Text should be 'When submitting a grouping or worksharing of variations, eCTD submissions must be provided per marketing authorisation'.

Accepted referred to EMA business team7/2010 - Follow-up with EMA business group [G. Isakkson]9/2010 - Owner of Module 1 specification is TIGes with EMA as rapporteur2/2011 - On hold per EMA8/2011 - Completed; moved to Closed CRs

Updated Module 1.4 specificationRemoved word 'copied' and include wording as proposed in EU M1 specification

TIGes/EMA rapporteur & Interlinking Group







CR 20090922 Remco Munnik, Sandoz EU M1 eCTD Specification v 1.4 Completed

CR 20091203 Claire Holmes, EMEA EU M1 eCTD Specification v 1.4 Completed Implemented in EU M1 v 2.0 EU M1 Rapporteur

CR 20091204 Alastair Nixon GSK eCTD BPG Completed CMD(h) to announce this in a press release in November. Interlinking Group

CR 20091210 Geoff Williams, Roche EU M1 eCTD Specification v 1.4 Completed Q&A 27

CR 20091211 Claire Holmes, EMEA EU M1 eCTD Specification v 1.4 Completed Implemented in EU M1 v 2.0 EU M1 Rapporteur

CR 20091217 Danilo Steblaj, Slovenia EU M1 eCTD Specification v 1.4 Completed

CR-20091217-01 Alastair Nixon GSK EU eCTD Validation Criteria Completed Harmonisation Group

CR-20100107 Andrew Marr, GSK eCTD MRP/DCP Tracking Table specification Completed move to Closed CRs page after TIGes 3 June 2010

CR-20100128 eCTD MRP/DCP Tracking Table specification Rejected Interlinking Group

CR 20100128-01 Completed Interlinking Group


Page 10 of the written specification concerning File naming conventionParagraph: File names in Module 1 have the general structure CC-FIXED-VAR.EXT, where CC is a country code used in some CTD modules, FIXED is a defined component of the filename based on the CTD section and VAR is an additional optional variable component. EXT represents the file extension. Components are separated by a hyphen (except the dot for the file extension). No hyphens or spaces should be used within each component.The naming convention is to be split for those documents pertaining to country-specific items (Sections 1.0; 1.2; 1.3 and 1.additional) and those not (1.4; 1.5; 1.6; 1.7; 1.8; 1.9; 1.10 and 1.responses). Note that for 1.responses a separate Change request has been written and submitted.[Page 10 of the written specification concerning File naming convention]

Recommended on CR form: The naming convention is to be split for those documents pertaining to country-specific items and those not.

Discussed in subgroup 20091210. Agreed. For implementation in next minor version (specification only), for clarification.

Accepted 7/2010 - Follow-up with EMA business group [G. Isakkson] 9/2010 - Owner of Module 1 specification is TIGes with EMA as rapporteur2/2011 - On hold per EMA8/2011 - Completed; moved to Closed CRs



The comment describes a different instruction for MRP and DCP. What is the reason for this? Both MRP and DCP have a common and a national phase.. [page 21 comment # 8]

Recommended on CR form: Depending on the reason, update the text by an unambiguous description.

Discussed in subgroup 20091210. It is accepted that there is a need for clarification in the EU M1 v1.4 specification. The guidance on the use of the common directory should not include references to specific procedures.

Accepted7/2010 - Follow-up with EMA business group [G. Isakkson]11/2010 - transitioned to T. Mauer2/2011 - On hold per EMA8/2011 - Completed; moved to Closed CRs

Updated Module 1.4 specificationRevise EU M1 spec to remove references to procedures in the use of the common directory. Also review the wording alongside the pictures on p.8 under heading 'Decentralised Procedure Directory Structure.'


In version 1.4 of the Module 1 specifications, for the element “applicant” the following sentence has been included for worksharing:For ‘worksharing’ procedures, this should correspond to the applicant designated for the worksharing submission (and not all individual marketing authorisation holders for each product concerned).

The inclusion of this “requirement” would lead to the fact that for a worksharing procedure, the company that submits the eCTD application, must change the country specific envelope information every time.

Proposal of this CR is to remove this sentence from the specification.

Discussed at TIGes/NtA Interlinking Meeting 20/10:Agreement to remove the sentence from the specification.

Accepted 7/2010 - Follow-up with EMA business group [G. Isakkson] 9/2010 - Owner of Module 1 specification is TIGes with EMA as rapporteur2/2011 - On hold per EMA8/2011 - Completed; moved to Closed CRs


New visual identity (new logo etc.) from 8 Dec on. Still the European Medicines Agency, but no longer ‘the EMEA’ – and not ‘the EMA’ either. In future the fullname or 'the Agency' will be used. New ‘ema.europa.eu’ address for website and e-mails from 8 December 2009: all Agency website and e-mail addresses will change from ‘emea.europa.eu’ to ‘ema.europa.eu’. From that date onwards, the address of the public website will be www.ema.europa.eu and e-mail addresses will take the form [email protected].

Should this change be reflected in the EU M1 specification? Or is there no need as it seems the acronym ‘EMA’ will not be used?

Content from a specific folder 'emea' also still needs to relate to new folder 'ema' - could be a tool change. What is the expected time frame for these changes? Need to look at all standards and systems.8/2011 - A clarifying statement was added on the continued use of the EMEA acronym (page 5); changed to new acronum when actually referring to the agency

Strategy for standards and specifications to be defined by EMEA. Specification changes only could be implemented in a next minor version of the EU M1 specification. 9/2010 - Also needs DTD revision

The current eCTD BPG for MRP/DCP describes 2 different approaches for eCTD: the parallel national model and the comprehensive model. In the section describing the parallel national model, it states, “Applicants should transition to the use of the ‘comprehensive’ model at the earliest opportunity”. However, the document does not describe how to do this. In reality, this will not be straightforward, and it is suggested that, in addition to providing guidance, the parallel national model is removed as an option from now on.

Ashley Birch: I do wonder whether anyone has actually used the PN Model - if not, there could in fact be no need for transition guidance, simply the removal of the PN option. If guidance is however necessary, then I think we would definitely need more detail on how to create a 'consolidated baseline'. It's not clear to me how this would be done across many countries, unless it were preceded by individual NCA sequences that deleted all previous content. If this were not done, and all the content effectively baselined (resubmitted) in the subsequent consolidation sequence, then it would be impossible to use an operator on an older document as it would potentially appear in different sequences in different countries.7/2010 - eCTD TG recommends low priority10/2010 - Interlinking agreed on following:CR is accepted. Interlinking group is of the opinion that the national parallel model should not be used in future and proposes that in the next update of the Best Practise Guide the model will be removed.Proposal is that CMD(h) will publish a press-release in which it will be announced that the national parallel model is to be withdrawn. Any applicant that used this model is requested to switch to the comprehensive model within a period of 3 months.NCA's will not accept any eCTD's that comply with the

Accepted - refer to Interlinking Group7/2010 - Follow-up with Interlinking Group10/2010 - Interlinking Group - Agreed to withdraw the option of the parallel national model. Interlinking 2/2011: Agreed Announcement expected this week. If done close the CR at the next CCB meeting. 3/2011 - TIGes Report from the Chair indicated the press release was done; Completed; moved to Closed CRs

The submission type “Withdrawal” in the EU Module 1 envelope is defined in the specification with two different meanings. We believe the usage may be unclear and propose some changes

Discussed in CR subgroup 20091210. Agreed to clarify in spec.10/2010 - Interlinking agreed on following :CR is accepted.The submission type “Withdrawal” is only to be used for the withdrawal of a Marketing Authorisation.Geoff Williams to draft a Q&A on this topic. Q&A draft for discussion in November Interlinking.

Accepted - refer to Interlinking Group7/2010 - Follow-up with Interlinking Group10/2010 - Q&A 27 to be discussed at Interlinking in November2/2011 - M1 spec revision on hold per EMA05/2011 - Completed


Term 'Periodic Report' should be removed from the EU M1 v1.4 specification as it can be confused with the Annual Report. CR arises from discussions on rejected CR 20090909.

Discussed by Subgroup 200912107/2010 - Changes need to go beyond EU M1 v 1.4.1; needs to be next minor version, i.e. v 1.5

Remove term 'Periodic Report' from EU M1 specification - update in next minor version

The name of the Agency for Medicinal Products and Medical Devices of the Republic of Slovenia changed from Agency for Medicinal Products and Medical Devices to current name in 2007. The document " EU eCTD module 1 specification v1.4" has still the old name "Agencija za zdravila in medicinske pripmocke" on page 39. The name should be changed to current name "Agency for Medicinal Products and Medical Devices of the Republic of Slovenia".

Discussed by trial CCB 201005177/2010 - Wider change assessment required. EUTCT, eAF? eCTD. Would need to be next minor version. However we need a way in which the agency names can be updated without major impact. ICH NMV?10/2010 - Interlinking agreed on following :CR is accepted and issue should be solved in next update of the specification.However this CR should be referred to owner of the M1 specification (EMA).Interlinking to inform Change Control Board (CCB) about this.

Accepted - referred to Interlinking Group 17 May 2010 for implementation7/2010 - Follow-up with Interlinking Group9/2010 - Owner of Module 1 specification is TIGes with EMA as rapporteur10/2010 - CR should be sent to owner of M1 specification.2/2011 - On hold per EMA8/2011 - Completed; moved to Closed CRs


The current eCTD validation criteria (v2.1) contain tests specific to version 1.3 of the European Module 1 specification. Specifically, test 35 requires that, “EU M1.3 file name convention is followed”. This test should refer to the current EU m1 specification, or, ideally, refer to all currently allowable versions of EU Module 1. Test 2 states that “A valid EU M1 DTD exists”, but this does not disallow earlier DTDs which should no longer be used.

Discussed by trial CCB 20100517; We recommend refining the text so the revised text does not go out of date as well [cited link]10/2010 - Interlinking agreed on following:Issue should be referred to the Harmonisation group, which is responsible for the review of the validation criteria.Follow-up: Already being addressed by Harmonisation Group in validation criteria work

Accepted - referred to Harmonisation Group for implementation9/2010 - Update by Harmonisation Group10/2010 - Interlinking agreed to refer back to Harmonisation Group.2/2011 - Completed; moved to Closed CRs

Discuss in relation to the update of the Validation Criteria.Harmonisation Group: The issue was addressed and clarified when updating the validation criteria for eCTD version 3.0 published in January 2011 and coming into force by 1 September 2011.

The eCTD in MRP/DCP best practice guide has been revised and now includes a description for the change to the RMS. The current specification for the xml table does not support a change of RMS. Only one is allowed. The specification should be amended.

Discussed by trial CCB 20100517; follow-up with author indicated that the Interlinking group has already Accepted and a paper for adoption is being drafted

AcceptedCompleted

Interlinking adoption paper, trial CCB for tracking

Anita Anand Phadnis, Educe Solutions

The Harmonised eCTD guidance (v1.0) Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD electronic Submissions, section 2.9.3 recommends the use of the tracking table for national submissions. However, there is only an XML specification for the table for MRP/DCP and it cannot be used for national submissions, for example a CMS is required.

Discussed by trial CCB 201005177/2010 - XML table will only support MRP/DCP NEED date discussed

Accepted - referred to eCTD Interlinking Group 17 May 20107/2010 - Rejected by Interlinking Group

Incorporate change in release plan for next version of tracking table; it is deferred to the Interlinking group whether the Requestor needs to provide additional specifics in order to adopt the changes requested

Anita Anand Phadnis, Educe Solutions

eCTD MRP/DCP Tracking Table specification v1.0, May 2008MRP/DCP eCTD Best Practice v1.0

On occasions a CMS is withdrawn during MRP or RUP. In a Word-based version of the tracking table it is feasible to identity within the table that an CMS has been withdrawn. However, in an XML-based table the specification does not easily support the withdrawal of a CMS.

Discussed by trial CCB 201005177/2010 - Agreed by Interlinking - awaiting EMA allocation of resource to redevelop the spec for the XML table.10/2010 - Interlinking agreed on following: CR is accepted.Further discussion in Interlinking is required on this topic. Especially on the situation of withdrawing a MS and later on re-entering of the same MS in the procedure.

Accepted - referred to Interlinking Group 17 May 20107/2010 - Follow-up with EMA Business Group [G. Isakkson]9/2010 - Needs follow up by Interlinking10/2010 - Discussion in Interlinking requiredInterlinking 2/2011: Work in Progress. Expect to finalise at 3/2011 meeting05/2011 Interlinking: Open. Awaiting finalisation09/2011 The table in XML format is no longer required. However the tracking table in the BPG needs to be updated. 10/2011 Completed; moved to Completed CRs

Update the table to deal with withdrawal of a CMS in release plan and update BPG. Assign priority to the development of a standard XML table for automated handling. The update of the standard XML table was given low priority and it was decided to drop the inititative.The eCTD MRP/DCP Tracking Table specification v1.0 of May 2008 will be removed from the eSubmission website.The eCTD MRP/DCP Tracking Table should be provided in PDF format.





CR 20100408 Leigh Sandwell, Pfizer EU M1 eCTD Specification v 1.4 Completed Implemented in EU M1 v 2.0 EU M1 Rapporteur

CR-20100504 Sibulle Teuchmann, Exalon GmbH EU Module 1 (version 1.4) style sheet Duplicate to CR-20010408 Duplicated Duplicated None N/A Refer to CR-20080909-01.

CR-20100517 Cynthia Piccirillo, BMS Discussed by trial CCB 20100517 Completed Move to Duplicated CRs after TIGes 3 June 2010 Joint TIGes

CR-20100607-01 Sandra Taylor, J&J EU eCTD Validation Criteria v2.1 April 2009 not advanced Duplicated CCB 9/2010 - Duplicate to CR-20091217-01 None

CR 20100607-02 Sandra Taylor, J&J EURS is Yours software used at agencies Feb 2010 (2.8.1 SP1?) Request copies of validation reports from requestor for more clarity. Rejected Interlinking Group

CR-20100707 Klaus Menges, BfArM CMDh BPG, TIGes eCTD submission Guidance Rejected Interlinking Group

CR-20100930 Remco Munnik, Sandoz EU NeeS guidance Completed Harmonisation Group

CR 20101022-01 Leigh Sandwell, Pfizer EU M1 eCTD Specification v 1.4 and HMA website 11/2010 - CCB accepted; include in M1 specification update Completed Implemented in EU M1 v 2.0 EU M1 Rapporteur

CR 20101022-02 Leigh Sandwell, Pfizer EU M1 eCTD Specification v 1.4 11/2010 - CCB accepted; include in M1 specification update Withdrawn No action taken None taken Interlinking Group

The two entries for Hungary in the EU eCTD Module 1 v1.4 stylesheet have mistakenly been swapped around so that the incorrect agency information is displayed in the stylesheet view; Institute also is misspelled in this chain

Discussed by trial CCB 2010 May10/2010 - Interlinking agreed on following :CR is accepted and issue should be solved in next update of the specification.However, this CR should be referred to owner of the M1 specification (EMA).Interlinking to inform Change Control Board (CCB) about this.

Correct the stylesheet to reference the correct agency names and fix the spelling mistake

The Style Sheet for EU M1 (version 1.4) displays the wrong information in the envelope for the Hungarian authorities (veterinary is associated with OGYI).

Change Control Process for European eCTD Standards V1.1Document J03-CR Processing Steps-20070907, version date 2007-09-07

Stakeholders reported that TIGes meetings frequently have its performance badly affected by long discussions taking place regarding change requests. Also, given TIGes meetings occur quarterly, decisions might take up to 3 months or longer to be closed. An improved Change Request process would achieve many benefits.

AcceptedCompleted

Criterion No. 35 states “EU M1.3 file name convention is followed”. “EU M1.3” is ambiguous as this could mean the EU Module 1 Specification version 1.3 or Module 1.3. Product Information. We assume this relates to the EU Module 1 Specification, if so by including the version number, the criterion quickly becomes outdated.

ask Harmonisation Group if they agree

An MRP eCTD was submitted to 28 EU countries. 9 countries were provided with country-specific application forms. For the remaining countries, a single form was provided that applied to all 19. For the 19 countries, a single content file “uk-form.pdf” was provided in 0000\m1\eu\12-form\uk and this was referenced by 19 XML leaves each associated with a different <specific> country attribute. This approach is in line with the ICH eCTD Specification where it states that “Users of the eCTD Specification are encouraged to provide files once in a sequence and provide as many leaf elements referencing that file as necessary. The location of the file is not critical and should only be included once in an appropriate place in the folder structure”.

Note that the 0000\m1\eu\12-form\common folder or “common-form.pdf” filename was not used because “common” identifies content potentially applicable to all EU countries, which was not the case in this situation.

Agencies provided feedback that EURS is Yours gave a validation warning category B No. 35 (EURS is Yours Validation Report, “Some file and folder names do not match the EU M1.4 naming convention”, Validation Criteria v2.1: “EU M1.3 file name convention is followed”).

This is an incorrect validation result because the EU filenaming convention “CC-FIXED-VAR.EXT” was followed. There are no checks defined in the EU eCTD Validation Criteria that require leaf elements associated with a <specific> country code to reference a file with the same country code in the filename.

9/2010 - Accepted, referred to Harmonisation Group2/2011 - Harmonisation Group asked to pass this to Interlinking05/2011: Closed. Interpretation issue related to Extedo's validation tool. It does not require any specification change.

Harmonisation Group to assess specifics of situation against the specification and validation criteria in order to determine whether software revisions are needed or these documents need to be more clear (or both).

BPG on DCP allows to submit draft versions of the applicant response document (ARD). This can be in case of eCTD a formal sequence but not entirely finalised. For finalisation a second sequence may be necessary. Two options to deal with are possible:1. It will not be counted as a formal sequence and not loaded to the NCA eCTD reviewing tool (but full support for assessors is not available) 2. It is counted as a formal sequence and the finalising sequence will be submitted thereafter. Both sequences need to be submitted to CMSs or the draft need to be overwritten by the final version of the same sequence. A further outline is attached.

Guidance needed on how to best deal with drafts, as up to now nothing is said to this type of submission in the TIGes eCTD submission guidance. 10/2010 - Interlinking agreed on following: CR is rejected.The CMD(h) BPG for the use of eCTD in MRP/DCP defines that draft responses are outside the scope of eCTD. Follow-up: EFPIA eCTD TG suggests handling in the NCA business process

CCB 9/2010 - Referred to Interlinking group10/2010 - Interlinking agreed on following:CR is rejected.CCB 11/2010 - It seems that there is overlap between this CR and the CR 20060627-03 and associated proposed Q&A. Will ask requesters to work together. Potentially withdraw the 2 CRs and combine them into a new CR12/2010 - see CR-20060627-03 ActionCCB 2/2011 per Interlinking, move to closed [rejected]

Need feedback on whether this goes to Interlinking or CMDh; consider if software vendors should be consulted for feasibility of the two options suggested.12/2010 - Interlinking said to move to closed [rejected] as this is addressed in the Best Practice Guide which states not to use the eCTD backbone for draft documents.1/2011 - Move to closed [rejected].

Applicants receive comments from Health Authorities about missing ToC’s (m1.1, 2.1, 3.1, 4.1 and 5.1) for NeeS applications.According to the ICH granularity document, there is no need for ToC for eCTD submissions. The XML files function as a ToC and therefore modules 1.1, 2.1, 3.1, 4.1 and 5.1 are not applicable. It states therein, “The TOC is only called for in the paper version of the CTD; there is no entry needed for the eCTD.”For a NeeS application, PDF ToC’s are provided that replace the xml files and that link to all available files in the dossier. From an applicant’s perspective, we assumed that there is no need for modules 1.1, 2.1, 3.1, 4.1 and 5.1 for a NeeS application.

Clarify in the NeeS guidance document that there is no need for a paper ToC in sections 1.1, 2.1, 3.1, 4.1 and 5.1CCB 10/2010 - We agree with the proposal and add that the PDF ToC actually provides better navigation capability due to the hyperlinks. The guidance to amend is not the NeeS guidance but the "Practical Guidance For the Paper Submission of Regulatory Information in Support of a Marketing Authorisation Application When Using an eCTD or a NeeS as the Source Submission" v2.0, March 2010. Suggested is only to print ToCs for modules that are actually printed.

CCB 9/2010 - Accepted, referred to Harmonisation GroupCompleted

Harmonisation Group: The issue was addressed and clarified when updating the validation criteria for NeeS version 2.0 published January 2011 and coming into force by 1 September 2011. The TOCs is not needed in 1.1, 2.1, 3.1, 4.1, 5.1 for the electronic submissions as the hyperlinked TOCs serve the purpose for navigation.

The EU eCTD Module 1 v1.4 Specification document identifies the Czech Republic agency as:Czech Rep - State Institute for Drug ControlThe stylesheet file (eu-regional.xsl) for EU eCTD Module 1 v1.4 identifies it as:Czech Rep - State Institut für Drug ControlFeedback from our Czech Republic affiliate is that the agency name should be State Institute for Drug Control.This is confirmed by the SUKL website which uses the following Czech and English versions of the agency name respectively:Státní ústav pro kontrolu léčivState Institute for Drug ControlThese names are listed correctly on the EMA website, but the name of the agency also appears to be the incorrect version on the HMA website:http://www.hma.eu/index.php?id=11&showctr=16

Correct the stylesheet and HMA website to reference the correct agency name.

In the September minutes from the CHMP meeting there was a Procedural Announcement on the requirement to submit the Letter of Undertakings (LoU) as an eCTD sequence: The European Medicines Agency is repeatedly receiving the Letter of Undertakings (LoU) in paper format, however: “Any submissions made in the context of a Centralised Application Procedure and the subsequent maintenance of the lifecycle of the application (e.g. initial applications (including ASMF, PMF), supplementary information, variations, renewals, Follow-Up Measures (FUMs), Periodic Safety Update Reports (PSURs), Notifications etc) are covered by eCTD requirement “Applicants are advised that if due to short procedural timelines the LoU is submitted within a Eudralink message, they are obliged to follow this up with an eCTD sequence.From 15 October 2010 any paper submission of Letter of Undertaking (as normal correspondence) will therefore not be considered as valid submission. There is currently no specific Submission Type for a Letter of Undertaking eCTD sequence in the EU eCTD Module 1 v1.4 Specification. Also, a Letter of Undertaking may have a relationship to previously submitted information. Clarification is required in the eCTD guidance to define what Submission Type should be selected for a Letter of Undertaking eCTD sequence and whether a related sequence is required if there is a relationship to a previously provided eCTD sequence. The location of the LoU in an eCTD sequence should also be clearly defined.

There is no longer a need for a specific submission type LoU.





CR-20101025 Completed Harmonisation Group

CR 20101214 EU M1 eCTD Specification v 1.4 Completed Implemented in EU M1 v 2.0 Change Agency name EU M1 Rapporteur

CR 20100920 Completed EMA

CR 20101020 Geoff Williams, Roche EU M1 eCTD Specification v 1.4 Completed

CR 20101122 Completed

CR 20101129 EU M1 eCTD Specification v 1.4 Completed

CR 20101203 Cynthia Piccirillo, BMS, for EMA CCB EU M1 eCTD Specification v 1.4 Completed

CR 20110120 Remco Munnik, Sandoz Completed Interlinking Group

Danilo Šteblaj, Agency for Medicinal Products and Medical Devices of the Republic of Slovenia

Guidance for Industry on Providing Regulatory Information in Electronic Format:Non-eCTD electronic Submissions (NeeS) for human medicinal products

Chapter 2.2 says that NeeS submissions have the same folder structure as eCTD, which is not correct (no sequence folder in NeeS, the top level folder is the same with each submission in eCTD, in NeeS it changes, index.xml, eu-regional.xml files and util folder are not present in NeeS submissions). There is no system described for creating the name of the top level folder (in practice this leads to constant changing of the top level folder and subsequently to inability to identify the documentation/correlation between different submissions or supplement documentation).

Also in NeeS there is no tracking table (no life cycle), so it is much harder to figure out, which submissions are the parts of the same regulatory activity. There should be an appropriate substitute for tracking table (information at the end of the cover letter).

Because it happened several times in practice, that the ToC was present in module 1.1, the following sentence should be added in the chapter 2.2.1:

The module 1.1 should not be present in NeeS submission, as it is replaced by general ToC (located in top level folder for the submission) and module specific ToCs (located in the corresponding top level module folder).

The text from the chapter 2.3 should be included in chapter 2.2, the chapter 2.3 should therefore be deleted.

Solution proposal to the above mentioned problems is attached in file JAZMP_CR_NeeS.docx.

Need to send to Harmonisation Group

11/2010 - Accepted, referred to Harmonisation Group2/2011 - Completed

While the change request has been accepted, the CCB recommends revision to the proposed solution as follows: It is true, that no index.xml and util folder are present. But the re-worded validation criteria will clarify a number of part addressed, e.g. “4 digit number folder”, top level folder and naming convention for it, the placement of ctd-toc.pdf and module TOC files. The request can be partly accepted, but should be perhaps re-worded according to the new validation criteria before the CR is forwarded to the harmonisation group.By the way, folder similar to eCTD sequence folder can be provided as well and doing so, a tracking table is valuable to keep track of received submissions. In the past we have tried a keep NeeS as close as possible to eCTD. This approach will clearly skipped if the CR will be accepted without changes. But it was also common sense that NeeS is not the format we want to promote. Therefore, we should avoid anything which differentiates NeeS from eCTD more than necessary. From practical point of view: several companies produce eCTD submission and skip the util-folder etc. and added the TOC files for those NCAs accepting or requiring Jaakko Hartikka, Finnish Medicines

AgencyThe Agency name of Finland changed 1.11.2009 to “Finnish Medicines Agency”. In EU Module 1 Specification Appendix 2.4 page 38 there is obsolete Agency name “National Agency for Medicines” and Agency code “FI-NAM”. The new proposed agency code is “FI-FIMEA”. They should be updated to the documentation and to the related XML backbone files in eCTD EU M1.

CCB 1/2011 - The name of the Agency can be changed in the forthcoming M1 specification revision, but the Agency code will have to wait until the next revision of the DTD.CCB agreed.

Geoff Williams, EFPIA eCTD Topic Group

EMA Implementation of Electronic-Only Submission and eCTD Submission: Questions and Answers Relating to Practical and Technical Aspects of the Implementation & Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD electronic Submissions

Information is currently requested to be provided at up to 8 different milestones during an MAA regulatory activity as an eCTD submission sequence in the Centralised Procedure. This includes the provision of labeling information, as appropriate to the milestone, within the procedure. The labeling information is already sent via Eudralink to ensure that applicants meet the tight procedure timelines that would currently be difficult to achieve with the creation and dispatch of an eCTD sequence. The additional requirement to then follow up with an eCTD sequence creates additional unnecessary work for applicants and is not necessary to enable the review of the dossier.

10/2010 - CCB fully agreed with this recommendation CCB 9/2010 - Accepted, referred to EMA2/2011 - on hold9/2011 - Completed. The new TIGes Technical Validation Guidance document lays out the new requirements for the provision of eCTD/Eudralink sequences

The EU Module 1 eCTD specification identifies the acceptable file formats for inclusion within Module 1 of a European eCTD. This information is in the section Regional File Formats (beginning the bottom of page 5) and summarised in Table 1.

“Acceptable for inclusion in the eCTD” has generally meant that the file formats are acceptable for a leaf within the eCTD to reference using the xlink:href attribute. Since the original publication of this table in version 1.0, best practice has turned into guidance and the EU now only accepts RTF and MS Word files in a separate “working documents” folder. This fact is acknowledged in passing in the EU Module 1 eCTD specification, v1.4, which says:

“Although RTF is an accepted eCTD file format, it is also generally accepted that RTF files should also only be provided in addition to PDF versions, and that they should also not be referenced in the eCTD backbone.”

Furthermore, the information about acceptable file formats for the eCTD is also used by the NeeS specification and is the basis for validation criteria about the acceptable file formats for both eCTD and NeeS.

The inclusion of RTF is one difference between the ICH eCTD and the EU Module 1 eCTD. Given that the RTF files should not be referenced from the XML backbone we feel it is now time to amend the specification and remove RTF as an acceptable format.

This issue was discussed by the TIGes Harmonisation Group while drafting the new eCTD and NeeS validation criteria and has their endorsement.

We recommend removing any reference to RTF as an acceptable file format in the EU Module 1 eCTD specification at the next update to the specification document.

If an update to the eCTD specification is some time away, we recommend issuing a Q&A in the short term to announce this change.

11/2010 - Accepted, referred to rapporteur of M1 specification2/2011 - On hold per EMA 05/2011: Ready for eEU-M1 Revision. 8/2011 - Completed; moved to Closed CRs

Remove any reference to RTF as an acceptable file format in the EU Module 1 eCTD specification at the next update to the specification document. If an update to the specification is some time away then a Q&A to meet the interim need should be written.Updated Module 1.4 specification


Stephen W Cook, GlaxoSmithKline Biologicals s.a.

Volume 2B Notice to Applicants, Medicinal products for human use, Presentation and format of the dossier, Common Technical Document (CTD), Module 1, 1.2 Application Form

The lack of more detailed guidance on handling variations (irrespective of thenew variation regulation) causes divergent interpretation within the EMA and toa lesser extent across agencies. Though it is limited in this case to a singledocument, it has led to unnecessary validation rejections followed byadministrative burdens. The document concerns supportive document, not to besubmitted in Module 2-5 and therefore annexed to the application form. Thehandling of variation documentation needs to be further explained in the Notice to

12/2010 - pre-CCB EFPIA eCTD TG - can be addressed with M1 specification revision [specifically Appendix 2, Row 8 plus reference from Row 71 back to Row 8]; change could state to see ICH CTD guidance and Q&A [without specific version reference so easier to maintain].CCB - new guidance needs to clearly define what is 'supportive' vs. what will have lifecycle and needs to be readily available in the current view for critical review of the application

12/2010 - Accepted, referred to rapporteur of M1 specification; request consultation from Interlinking group8/2011 - Completed; moved to Closed CRs


Geoff Williams, Roche, for Harmonisation Group

The EU Module 1 specification specifically states that hyphens are not allowed in the variable (VAR) part of file names on page 10 (File Naming Convention, last sentence of the first paragraph) and on page 21 (item 8 of Appendix 2, comments section).No one on the TIGes Harmonisation Group can recall why this prohibition was introduced. Nor can we find any good reason to continue to to prohibit the use of hyphens.On the contrary, hyphens are the only way of helping provide meaning to the variable part because spaces are not allowed.The TIGes Harmonisation Group have discussed this thoroughly and feel that allowing hyphens in the variable part of the file name is beneficial. In the proposed new eCTD criteria (published for public consultation in November 2010) this change was proposed and has not met any resistance from tool vendors, applicants or agencies.

1/2011 - Update the specification document in the two sections identified to remove the prohibition and specifically allow the use of hyphens in the variable portion of the file name. Harmonisation Group suggests that this should be stated so as to make the change clear to readers of the specification.CCB: Suggest that when the M1 spec is revised that mention of path length considerations should be made when deciding whether hyphens are needed or not. The CR mentions M2-5 in the Summary. This is outside of the regional M1 specification and already addressed in the ICH eCTD specification.

1/2011 - Accepted, referred to rapporteur of M1 specification2/2011 - On hold per EMA8/2011 - Completed; moved to Closed CRs

Revise wording in the 2 sections identified to remove the prohibition and allow the use of hyphens in the variable portion of the file name.Updated Module 1.4 specification


There are currently at least 17 change requests, and possibly 20 change requests, that could be completed through a minor level revision of the EU Module 1 specification and stylesheet. The next major revision is not anticipated until 2013. In addition, all existing or drafted/planned Q&As could be retired as a result of undertaking this activity. Therefore, the CCB believes a sufficient number of CRs have accumulated and it is justified to assign an author(s) to undertake the M1 specification and stylesheet revisions.

12/2010 - In alignment with the CR process, a CR has been prepared to recommend a minor level revision of the M1 specification & stylesheet to address all related active CRs and work toward retirement of all Q&As

12/2010 - Accepted, referred to rapporteur of M1 specification2/2011 - On hold per EMA8/2011 - Completed; moved to Closed CRs


• Guidance for Industry on Providing Regulatory Information in Electronic Format: Non-eCTD electronic Submissions (NeeS) for human medicinal products. Version 2.0, March 2010• Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD electronic Submissions. Version 1.0, May 2009.• Existing Q&A “How to deal with National Translations of the Product Information?”

Currently it is not clear how to handle translations of SmPC, PL and label for variations. It is defined that for national finalisation phase of MRP/DCP national translations can be handled outside eCTD.However for some variations, updated SmPC, PL and label should be attached. It is currently not clear if the national translations of the English core SmPC, PL and label to be included in eCTD for variations.

Clarify in the guidance document that there is no need to include national translations in the eCTD folder structure.In case national translations are provided, these should be attached in the “working-documents” folder and not in the eCTD folder.In order to provide clarity a Q&A document should be created and published until the guidance document is updated.pre-CCB seems to be missing text. Also, the NeeS guidance seems to have the needed text under paragraph 3.2; this text could be brought to the eCTD guidance

CCB 3/2011- Accepted05/2011 Interlinking - Closed. Q&A agreed. Completed

Ask Karin Grondahl who should receive the CR for CMD(h) to consider; Karin's response was Interlinking05/2011 - Publish Q&A on eSubmission website

Created retrospective of changes made to ensure traceability for those revisions that were not the result of an existing CR. Thus accepted as 'completed'.





CR 20110127-01 EU NeeS Guidance v 2.0, March 2010 Completed Harmonisation Group Interlinking Group

CR-20110127-02 Completed 2/2011 - Accepted as Completed Harmonisation Group

CR 20110214-01 Completed Harmonisation Group

CR 20110214-02 eCTD Validation Criteria, Item 10.1, eCTD: v3.0, Jan 2011 Completed Harmonisation Group

CR 20110228 Remco Munnik, Sandoz Rejected Interlinking Group

CR 20110309-01 EU eCTD Module 1 Specification Completed

CR 20110506 NeeS Validation Criteria, v 2.1 (or later) Completed Next version of NeeS validation criteria Harmonisation Group

Cynthia Piccirillo, BMS for EFPIA eCTD TG

A member company was requested to file a submission containing a PSUR document in NeeS format for Finland. It is unclear where to place the PSUR document. In an eCTD submission this information would be placed in section 5.3.6. In the NeeS guidance documents, section 5.3.6 is listed as Not Applicable. The guidance does not provide direction as to where this type of report should be placed. This scenario is also applicable to the following documents:Information for Generic, `Hybrid` or Bio-similar Applications(Extended) Data/Market ExclusivityExceptional CircumstancesConditional Marketing AuthorisationMarket ExclusivityResponses to QuestionsAdditional Data

CCB 2/2011 - The CCB agrees in concept that some revision is needed, the actual revision should consider the following:The TOC included in the NeeS guidance is only an illustration how the TOC should be prepared. There are some “Not applicable” entries in the example of the TOC due to the fact that this probably only displays what would be included in a new MAA, i.e. a PSUR would not be included. But under section 2.2 Structure of Submissions it is clearly stated how the regulatory information must be structured and which rules should be followed. This also applies to the other items listed in the CR. Thus the guidance needs to be explicit that this is only an example and the CTD granularity/structure identifies where to include these other items, as applicable to a particular submission type.It may help to include additional examples for other types of submissions to further illustrate scenarios.Some of the items listed in the change request are not applicable since NeeS is no longer accepted for the CP.

CCB 2/2011 - Accepted, referred to the Harmonisation Group Completed; moved to Closed CRs

Requestor: Revise the guidance to remove the text, “In these examples there are some “Not applicable” documents shown. “Not applicable” documents should not appear in the dossier and nor should they be included in the TOCs.”, and replace the various ‘Not Applicable’ entries that are there with a sample of a link. CCB: See Comments2/2011 Harmonisation Group: The group agreed that the example in the NeeS guidance could be clarified to avoid any confusion. It will be reflected as the guidance is updated (planned during Q1-2 2011).


EU eCTD Validation Criteria v 2.1 and EU NeeS Validation Criteria v 1.0

Several areas have been updated as a result of the review carried out by the TIGes Harmonisation Group. These are:Principles for Validation CriteriaThe following principles have been applied during the review:1. Each identified criterion must be a check for a single item.2. Each criterion must be defined in an unambiguous way that leaves no room for interpretation3. The criteria must be defined in a way that is tool and vendor independentChanges to PriorityThe eCTD priority rankings of A, B and C were not felt to be completely understood. In addition, the A ranking of all NeeS criteria was not felt to address some areas that made the NeeS easier to use.

This is a high level Change Request to capture the major changes made to the eCTD and NeeS validation criteria by the TIGes Harmonisation Group that are not captured in other individual change requests. The list is not exhaustive and detailed to the finest degree as this would not be possible given the degree of change undertaken. However, key changes and principles for the changes are noted.

The changes identified have been applied during the TIGes Harmonisation Group review of the validation criteria that took place between September, 2010 and January 2011.


eCTD Validation Criteria, worksheet on file/folder naming - eCTD: v3.0, Jan 2011NeeS validation Criteria, worksheet on file/folder naming - eCTD: v3.0, Jan 2011

The ICH M4 document on Granularity allows for three options for the granularity in Module 2.3 (the Quality Overall Summary). The eCTD file naming provided in v3.2.2 of the ICH specification sets out the filenames for the middle level of granularity. The finer level of granularity can be accommodated by using the “-var” variable element on the end of the ICH filenames. However, there is no published filename to use for the coarser level of granularity (a single file for the whole of the QOS).

The new NeeS validation criteria make the file names in Modules 1-3 mandatory (they are P/F tests). Therefore, if the applicant chooses to submit a single file, there is no suitable filename value.

The ICH M4 document on Granularity allows for three options for the granularity in Module 2.3 (the Quality Overall Summary). The eCTD file naming provided in v3.2.2 of the ICH specification sets out the filenames for the middle level of granularity. The finer level of granularity can be accommodated by using the “-var” variable element on the end of the ICH filenames. However, there is no published filename to use for the coarser level of granularity (a single file for the whole of the QOS).

The new NeeS validation criteria make the file names in Modules 1-3 mandatory (they are P/F tests). Therefore, if the applicant chooses to submit a single file, there is no suitable filename value.

CCB 2/2011- Accepted - referred to Harmonisation GroupCompleted

In the next minor update to the eCTD validation criteria spreadsheet. The TIGes Harmonisation Group discussed this matter on 11th Feb 2011 and proposed adding the filename qos-var.pdf as an option OR to use the filenames already shown. The screenshot shows the proposed layout


The comment that has been made alongside the eCTD validation check 10.1 is not a logical result of the check.

CCB 2/2011- Accepted - referred to Harmonisation GroupCompleted

In the next minor update to the eCTD validation criteria spreadsheet.

Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD electronic Submissions. Version 1.0, May 2009.

In paper and NeeS format an applicant can built the submission at the headquarters for the common documentation and send this out to the Country Organisations (CO). The CO’s s attach local documentation (translations of cover letters, application forms, declarations, statements, proof of payments, etc).For eCTD it is required that all documentation is included in the eCTD.This means that for an eCTD the CO’s have to send all national documentation to the headquarters where the eCTD is created.This is an additional and time-consuming step, which delays the submissions of eCTD’s compared to paper and NeeS.In order to remove this additional step it should be allowed to submit all national documentation in the “workingdocuments” folder.

Harmonisation group should clarify how to handle national documentation.In order to facilitate companies to incorporate eCTD fully, it would be proposed to store any national declaration, statement, translation, etc in the “workingdocuments” folder.CCB - Agree that there is difficulty in preparation, however this approach would create a loss of functionality of the eCTD structure with putting required documents in the "workingdocuments" folder and potentially a greater burden on NCAs.

CCB 3/2011- Rejected4/2011 - Requestor asked reconsideration. Referred to Harmonisation Group.6/2011 - TIGes sent back to Interlinking; they have officially rejectedClosed


The Module 1 Specification allows for more than one Related Sequence, but only shows examples of one Related Sequence being provided. It is generally expected that there is usually just one Related Sequence, but, from experience, there appears to be occasions where more than one Related Sequence should be provided:e.g. 1: There are two FUMs (sequence 0050 and sequence 0060) and a single response (sequence 0070) is produced that relates to both FUMs.e.g. 2: There are two parallel variations (sequence 0020 and sequence 0030) and there is a sequence (0040) that brings the label up to date by including the changes made in both variations.Clarification should also be given on the implications on the Envelope Metadata (for example if a labeling consolidation sequence involved both a single and grouped variation, what would the metadata state) and subsequent lifecycle sequences (for example what if there was a further sequence referring to just one of the original sequences).

CCB 3/2011 - Accepted - referred to Harmonisation Group

04/28/11 Harm.group: Accepted8/2011 - Completed; moved to Closed CRs

04/28/11 Harm.group: The group agrees. The comment in 14 BP 1 of the validation criteria on having only one related sequence value will be removed in the next version.Also, a new comment should be included for this validation criterion, that if more than one different category of activities are referred to (related), then the “highest category” should be used as related sequence, and if any of the related variations were grouped, then ‘grouping’ should be used.

The update is not regarded as urgent. For now, it will be included in the update of the eCTD guidance document.


Mickel HedemandDanish Medicines AgencyTIGes Harmonisation Group

Names of NeeS submission folders (e.g. “0000”) can be reused. To store the submissions together (next to each other) on a file share, submissions has to be renamed by agency. To provide a consistent structure, submissions without a 4 digit submission name could also be renamed.

If a relative hyperlink has been made to point outside the submission and back in (e.g. from ctd-toc.pdf to m1-toc.pdf with a link to “../0000/m1/m1-toc.pdf” or even “../../mydrug/0000/m1/m1-toc.pdf”) this will point to the correct document for the applicant (even when checking the submission on the CD) but fail or point to a document in the wrong submission for agency.

If the submission has been renamed due to reused folder name it is very likely that this type of hyperlink points to an existing document other than intended by applicant.

Since hyperlinks to a previous submission could be meaningful in non-TOC documents this check should only be performed on hyperlinks in TOC files.

This type of error has been seen in more than one occation. Others may have slipped through validation.

With version 2.1 of the validation criteria this type of error will typically result in invalidation by agency due to No. 1.7 (since documents are rarely referenced more than once from a TOC file), but applicants should be able to perform technical validation themselves.

Add validation criterion to the set of NeeS validation criteria:Number: 3.XCategory: PDF FilesValidation Criterion: No hyperlinks in TOC files link outside the submission.Type of check: P/FReferencing outside the submission (with “..”) and then back into the submission folder using the submission folder name (e.g. “../XXXX/m1/m1-toc.pdf” from ctd-toc.pdf) is regarded as a link outside the submission.

Added as extra rule 3.5, wording altered slightly from proposal - no mention of sequence number, just ".." - see rules v 2.25/2011 CCB: CCB recommends adding to the NeeS guidance in the interim.

05/04/11 Harm. group: This error, if present, will break any of the TOC hypertext links where a path via the NeeS root folder is used, but the submission passes all the rules as currently written.It can however wait to be included in the validation criteria. This problem is already not tested, so the situation with respect to NeeS submissions exhibiting this problem will get no worse than it is today. 14/10/2011 Harm.group: A Q&A will be drafted to give some guidance for avoiding the problem. Later on it should go into the TIGes harmonised NeeS guidance and maybe into the validation criteria.

16/05/2012: Added as new NeeS criterion 1.8, and Q&A 37.





CR 20110513-01 Completed Harmonisation Group

CR 20110513-02 EU eCTD Validation Criteria v3.1 Completed Harmonisation Group

CR 20110513-03 EU eCTD Validation Criteria v3.1 Completed Harmonisation Group

CR 20110601 Completed

CR 20110614 EU eCTD Module 1 Specification Completed Implemented in EU M1 v 2.0 Interlinking Group

CR 20110627 Completed Interlinking Group No

CR 20110721 Miguel Bley, Afssaps Completed Interlinking

Karin GröndahlTIGes Harmonisation Group

EU eCTD Validation Criteria v 3.1 and EU Guidance for ASMF in eCTD format

The comment for eCTD validation criteria no 15.BP3 is now written as:“Applicants using the eCTD for ASMF or for MAAs including an ASMF are reminded that the EU guidance recommends the use of "ap" and "rp" prefixes for content in the applicants part and restricted part, respectively. eCTD validation tools should accept these prefixes in Modules 1, 2 and 3.”

This is in line with what is written in the “Guidance document for ASMF in eCTD format”.

However, there is a problem for validation tools to test for file names when “ap” and “rp” are used as prefixes, and therefore it would be preferable to instead have them as suffixes, in the variable part that should anyway always be accepted whatever is included.

Also, it is now recommended in the comments to the NeeS validation criteria to have the “ap” and “rp” to be put as a suffix instead, for just that reason that will then be part of the variable part and therefore accepted. It would be better to have the same guidance for NeeS and eCTD for consistency.

The comment to Validation criteria 15.BP3 should be updated to:Applicants using the eCTD for ASMF or for MAAs including an ASMF are recommended to use "-ap" and "-rp" as suffixes included in the variable part of the relevant folder and filenames for content in the applicants part and restricted part, respectively.”

The ASMF eCTD guidance should be updated in section 1.1. to:The prefix suffix ‘AP or ‘RP’ should be added to the <substance> meta-data value, and in addition the prefix ‘-AP’ or ‘RP’ suffix ‘-rp’ or ‘-ap’ should be added to every leaf title in the respective section.

It is recommended that the prefix suffix ‘ap’/‘rp’ is also applied to the file names.

In some cases in where the ASMF is used to support applications in a number of different procedures or where the API is used in different formulations, the requirements for one MAA may require additional documentation to be included. These documents can be included within the ASMF eCTD by adding an extension to the file name to identify the procedure or MAA application and by including some specific information about this as a prefix suffix in the leaf title.

5/2011 CCB - Accepted - referred to Harmonisation Group

05/04/11 Harm. group: AcceptedCompleted

The ASMF/eCTD guidance should be updated in due time before the new criteria come into effect on 1 Sept 2011Update ASMF and eCTD guidances; 5/2011 CCB - Assignment for guidance revisions needs to be made

05/04/11 Harm. group: Changing the eCTD criteria to require suffixes will make the eCTD and NeeS criteria consistent, but will require a change to the ASMF guidance to ensure consistency between the authoring guidance and the eCTD file name checks.

The change is not crucial since file and folder naming criteria for eCTD are only best practice, whereas for NeeS they are P/F. Therefore, any changes to the eCTD rules will not have a big impact on applicants, changes will only alter the advice given by the tools if a BP check is failed. The NeeS criteria are P/F, but the ap or rp information is already requested as a suffix i.e. in the variable part.

Karin GröndahlTIGes Harmonisation Group

The new validation criteria that come into force 1 September 2011 are supposed to have only one unique check per item. For the tests 1.4, 2.4, 3.4, 4.4, 5.4, 6.4 the tests have been found to actually be a combination of two tests; to test that correct version are used of the - ICH DTD - ICH Stylesheet - EU M1 DTD - EU M1 leaf MOD file - EU M1 envelope MOD file - EU M1 Stylesheetand that you do not go back to an earlier version when a newer version has already been used for the eCTD

These criteria are proposed to be separated into different tests and therefore 1.4, 2.4, 3.4, 4.4, 5.4 and 6.4 are proposed to only include the tests for not going back to earlier versions and new tests (1.5, 2.5, 3.5, 4.5, 5.5, and 6.5) are proposed to be introduced to test for the use of correct versions.


05/04/11 Harm.group: Accepted. Completed

5/2011 CCB - CR proposal: to update the criteria immediately, adding the new rules as additional numbers without altering the numbers for the existing published criteria.

05/04/11 Harm.group: The rule itself has already been published but the tests are combined into one rule. The test on sequences submitted out of order will ensure that applicants cannot revert to a previous DTD once a newer version has been used, simply by submitting an earlier (unused) sequence number.The change would be made in the validation criteria by next update , but is not urgent so it can wait. Could have life cycle issues in tools in rare instances where out of sequence submissions could revert back to a previous DTD. DTD changes are not expected between now and the end of the year.

Jan Wermusch, LORENZ(by TIGes Harmonisation Group)

The eCTD criteria 1.1, 1.2, 2.1, 2.2, 3.1, 3.2, 4.1, 4.2, 5.1, 5.2, 6.1, 6.2, 7.1, 7.2, 9.1, 9.2 do not ensure that the correct DTDs, mod files and style sheets are actually being used. Only the physical existence of several files in specific folders is ensured by these criteria. However the backbone index files (both regional and ICH) have fully qualified references to the files actually in use. So it would be more appropriate to check those references.

Add dedicated criteria:

Index XML: The file contains a valid reference to the ICH DTD in the correct location (util/dtd/ich-ectd-3-2.dtd)

Index XML: The file contains a valid reference to the ICH stylesheet in the correct location (util/style/ectd-2-0.xsl)

EU regional XML: The file contains a valid reference to the EU regional DTD in the correct location (../../util/dtd/eu-regional.dtd)

EU regional XML: The file contains a valid reference to the EU regional style sheet in the correct location (../../util/style/eu-regional.xsl)

Note that these new rules would make the existing criteria 1.1, 1.2, 2.1, 2.2, 3.1, 3.2, 4.1, 4.2, 5.1, 5.2, 6.1, 6.2, 7.1, 7.2, 9.1, 9.2 obsolete because (a) the name and the path of the files is already checked through the reference and (b) in case the files do not exist, the criteria 7.3 and 9.3 would automatically be violated.

Note that the criteria 4.1, 4.2 and 5.2, 5.2 are obsolete because they are already covered by number 9.3. The reason is that when you use the correct EU M1 DTD, the EU regional XML is only well formed when those files are provided exactly as required in the EU M1 DTD.

We generally think that the criteria set should be canonical (avoiding any redundancies). Providing additional obsolete criteria only because of a better sponsor guidance is error prone. The appropriate guidance can be achieved through comments as well.


05/04/11 Harm.group: AcceptedCompleted

5/2011 CCB - Per CR: Accepted but rules 1.2, 2.1, 2.2, etc will remain, to ensure that all tests only have one potential outcome - pass/fail. Add as separate additional tests 7.5, 7.6, and 9.5, 9.6, such that numbering on rules v 3.0 stays as is

05/04/11 Harm.group: The change would be made in the validation criteria by next update, but is not urgent so it can wait. The problems with missing or incorrect DTD/MOD/STYLE Sheet files are rare. A missing DTD is usually an indication of more fundamental problems with an eCTD, which would be picked up by other checks.

Klaus Menges, BfArM

EU M1 Specification version 1.4 eCTD validation criteria version 3.1

In the EU M1 specification the file extensions ZIP/TGZ are mentioned to be usable. As this was only introduced to support PIM – which will not become productive in the near future – maintaining this file extensions may lead to submissions using ZIP/TGZ in an inappropriate way. Moreover, the eCTD technical validation criteria should be adjusted accordingly.

Deletion of ZIP/TGZ from the list of allowed file extensions in EU M1 specification and change the comment inline 55 to “RTF, ZIP, TGZ will be removed from the list of acceptable formats to be referenced by leafs in the eu-regional.xml”

7/11 CCB - Accepted, referred to Interlinking8/2011 - Completed; moved to Closed CRs



The accession of Croatia is now expected in July 2013. There is currently no country or language code for Croatia/Croatian in the EU eCTD specification. Feedback from EMA PreSubmission meetings has suggested that applicants will need to include the Croatian label documents in the submission before Commission Decision once Croatian has joined the EU.

Recommended Solution: Include codes for Croatia in the next update to the EU eCTD Module 1 Specification.

7/11 - CCB recommendation: Add 'HR' as country code (ISO compliant); 'hr' as language code

Remco Munnik,RPN Regulatory Pharma Net

One of the below documents would be changed:CMDh Best Practice Guide on the use of eCTD in the MRP/DCP, Doc. Ref.:CMDh/084/2008/Rev2, June 2010OR EU Region eCTD Validation Criteria, version 3.1, step 11.6

As the CR (2011-02-28) to handle pure national documentation outside of the eCTD was rejected, there is an inconsistency in the current guidance and validation criteria, which could lead to automatic invalidation of valid eCTD applications.The current BPG for eCTD in the MRP/DCP leaves the possibility to create country specific sequences for country specific documentation.In case an applicant uses this possibility, it means that the applicant creates and submits a sequence with documentation that only applies to one country (i.e. AT).However, the new eCTD validation criteria, step 11.6 defines that "The file referenced by the xlink:href must exist in the same or a previously submitted sequence within the same eCTD application" is a P/F criteria.This means that if that same (country specific) document is updated during the Life Cycle of the product (i.e. a variation), this "replace" document would be submitted to all Member States involved in the procedure (i.e. AT and BE).At the moment of receipt of the application, AT would validate the application correctly, as the original document was received and uploaded.However for BE, that didn´t receive the original document from the country specific sequence of AT, the P/F validation will fail.For the applicant there is no way to test this before submission, as at the applicants´ side all sequences will be available and therefore the validation would be correct.

Three options are suggested:1. Accept that pure national documentation can be handled outside of eCTD (as proposed in CR 2011-02-28)2. Amend the eCTD validation criteria, that step 11.6 "The file referenced by the xlink:href must exist in the same or a previously submitted sequence within the same eCTD application" is not a P/F check. Or at least make a comment that the NCA´s that invalidates, checks the HREF to the sequence of the missing document and checks in the tracking table if that sequence should have been received. If tracking table provides information that the sequence was country specific, the NCA has to validate the application. 3. Amend the eCTD BPG that country specific sequences are not to be used in the MRP/DCP. In case a sequence only contains a document applicable for one country, all Member States still have to receive and upload this sequence in order to have the same LC in all countries.7/11 CCB - Another option to consider is to allow the submission of national documentation and if the document needs to be sent to all countries subsequently, the document is given the operator 'delete' in the national sequence and then submitted in the common folder as 'new' .

2013/07: Under the new governance should go to CAB for eSubmission

7/11 CCB - Referred to Interlinking09/11 - Ongoing10/2011 - Open2013/09 - move to Closed

02/2013: Interlinking prepared a proposal for agreement by CMDh.2013/09: Q&A published on CMDh website http://www.hma.eu/277.html

eCTD EU Module 1 Specification, (Appendix 2.1: Destination Codes, page 36)

ISO 3166-1 alpha-2 codes are two-letter country codes defined in ISO 3166-1, part of the ISO 3166 standard published by the International Organization for Standardization (ISO), to represent countries, dependent territories, and special areas of geographical interest. They are the most widely used of the country codes published by ISO (the others being alpha-3 and numeric), and are used most prominently for the Internet's country code top-level domains. The European Commission uses ISO 3166-1 alpha-2 codes with two exceptions: EL (not GR) is used to represent Greece, and UK (not GB) is used to represent the United Kingdom. EU was extended for any application needing to represent the name European Union in August 1999.ISO 3166-1 has a broader scope and is therefore misleading.

ISO 3166-1 should be replaced with ISO 3166-1 alpha-2 10/2011 CCB - Accepted, referred to Interlinking10/2011 - Completed; moved to Closed CRs





CR 20110725 Jan Wermusch, LORENZ Completed Harmonisation Group

CR 20110831-01 EU Module 1 Specification; draft version 1.4.1, September 2011 Completed Implemented in EU M1 v 2.0 Interlinking Group

CR 20110912-01 Bernadette Billet, Liquent EU Module 1 Specification; draft version 1.4.1, September 2011 Withdrawn No action taken None taken Interlinking Group

CR 20110912-02 Bernadette Billet, Liquent EU Module 1 Specification; draft version 1.4.1, September 2011 Completed Implemented in EU M1 v 2.0

CR 20111010 Timothy McCloskey, BMS CHMP Scientific Advice Briefing Document Template Rejected Next revision of the guidance None taken EMA

CR 20120209 Bernadette Billet, Liquent EU Module 1 Specification; draft version 1.4.1, September 2011 Completed Implemented in EU M1 v 2.0 Interlinking Group Yes - Next revision

CR 20120210-01 Jaspreet Singh, EMA eCTD validation criteria version 3.1 Completed Harmonisation Group

CR 20120210-02 Wolfgang Rieckert, Helm AG eCTD validation criteria version 3.1 Completed Harmonisation Group

CR 20120301 Completed Harmonisation Group

CR 20120302 Completed Q&A 39 issued TIGes

CR 20120326 eCTD and NeeS validation criteria. N/A N/A CCB

CR 20120413 eCTD and NeeS validation criteria. Completed Harmonisation Group

CR 20120615 Alastair Nixon GSK Completed EMA

eCTD validation criteria version 3.1; NeeS validation criteria version 2.1

In the eCTD criteria set, there is number 16.BP11 requiring that the bookmarks pane should be visible (initial view setting) if bookmarks are included. In the NeeS criteria set there is no pendant for this. We do not see the point having different best practices regulations for PDF documents in NeeS and eCTD.

Add a similar best practice check to the NeeS criteria set.In our customer’s interest and for obvious harmonization reasons the LORENZ eValidator will always check this when analysing the initial view settings (i.e. for both eCTD and NeeS). So a note in a press release would be appreciated that this is actually best practice for NeeS and eCTD.Otherwise different validation results by different tools will be very likely.14/10/2011 Harm.group: This is a misstake and will be included in the next update of the NeeS validation criteria.

9/11 CCB: Accepted, referred to Harmonisation Group

05/2012: Completed

14/10/2011 Harm.group: To take into the next version of the validation criteria.

16/05/2012: Appropriate rules added for NeeS and eCTD to test view properties in the absence of bookmarks.

Michael Braun,Exalon

See Summary. The addition of a new value for the attribute “type” within the envelope element “submission” needs to be aligned technically with an update of the corresponding ATTLIST values in the eu-envelope.mod file. Otherwise, validation against the DTD will not be possible for the new proposed value “lou”

The eu-evelope.mod file needs to be updated to include the proposed value “lou” in the “!ATTLIST submission type”; alternatively, the new value needs to be removed from the written specification document and an interim procedure for Letter of Undertakings should be established as a workaround until the next DTD update

Appendix 1 of the draft specification includes a new value for submission type (lou), however, the envelope.mod in Appendix 3 does not include this value, nor is there a separate envelope.mod file on the website. Similarly, the 1.3.1 PIM section has been removed in Appendix 2, but is still present in the eu-envelope.dtd example in Appendix 3

The DTD and envelope.mod file must be updated and made available before the new value can be used.CCB - In the interim, it is recommended to include clarifying text in the specification.

There is no longer a need for a specific submission type LoU.

The file naming conventions section calls out the Module 1 sections specifically, but does not list the M1 Responses to Questions section. For completeness, this should be listed with the country-specific sections. Additionally, the non-country-specific items are listed as having “fixed filenames as defined in Appendix 2,” however, Appendix 2 shows these as still having the –VAR component.

To eliminate possible misinterpretation, the M1 Responses to Questions section should be explicitly listed with the other country-specific sections in the Naming Conventions sections. Additionally, an update to the non-country specific file naming should be made either in the Naming Conventions section to indicate they have fixed filenames and the optional VAR component, or Appendix 2 should be updated to remove the –VAR from the filenames for these sections. CCB - It was noted that this also appears in the validation criteria and revisions are needed in these documents as well.

14/10/2011 Harm.group: Propose to the Interlinking group to add "m1-responses" where it is missing in the EU M1 eCTD specification and thereby solve the problem.

Interlinking Group & Harmonisation Group

The CHMP Scientific Advice Briefing Document Template, Formatting Convention requires the use of Verdana 9 pt. The ICH eCTD Specification does not include Verdana 9 pt as an approved font and font size.

Please update the font and font size in the CHMP Scientific Advice Briefing Document Template to one consistent with the ICH eCTD Specification (Times New Roman, Arial or Courier, 12 pt for narrative text).

EMA indicated that Verdana 9 is carried through other documents outside of eCTD. May propose to make it an accepted font type to ICH.

In the v1.4.1 specification release notes, the update from CR200090909-03 is described as “..confirmation that common and/or country folders are acceptable within the “emea” subdirectories of an eCTD submitted in the Centralised procedure”. In the specification text, this is describe as, “For the Centralised Procedure, the country subdirectory is always named “emea”, irrespective of whether it contains “common” or country folders;…” This implies that the XML specific element will always be “emea” and the first subfolder in the subsection will be “emea”, but within that, there can be additional subfolders to differentiate common/country-specific information (e.g., 10-cover/emea/common or 10-cover/emea/be. However, this would seem to contradict the best practice 15.BP3 validation criteria folder naming requirement and doesn’t provide clear direction on whether the filename itself should then use the emea- prefix or the lower-level common/country prefix.

In Q&A and/or the next update to the specification, explicitly indicate which values are appropriate for the country-specific elements and folder structure in the Centralised Procedure

16/05/2012 - In criterion 14.4, 'common' has been added as an allowable specific country attribute for eCTD submissions in the centralised procedure. EMA will include when updating their 'Guidance for Industry' document.

PDF files which are generated with the electronic application form have automatically a number of security settings applied to them (e.g. changing the pdf generated by the eAF is not allowed). Therefore all the eCTDs which would contain an electronic application form in module 1.2 would fail validation criterium 16.3 . As a consequence companies are unlikely to use the eAFs at all.For this reason it is requested to add Section 1.2 to the exceptions of rule 16.3 Validation rule 16.3 should read:

16.3 PDF Files There are no further security settings applied to any individual file (except for files in Modules 1.2, 3.3, 4.3 and 5.4)

3/2012 - Accepted; HG are already aware and will incorporate before criteria are published

05/2012 - Completed

16/05/2012 - Change validation criteria. Added rule 16.4, specifically accepting certain security settings in section 1.2.

The files common-cover-tracking.pdf are comming originally from the file system and if several procedures are done in parallel (or several variations) which is often the case then all tracking tables would currently have the same name. It is difficult to handle them, especially as tracking tables have no life-cycle. There is no added value to not allow a variable part of the file name but it would make things much easier for the application of parallel procedures. Therefore, the file name common-cover-tracking-var.pdf is proposed.

Change in line 25 in File-Folder Structure & Names to cc-cover-tracking-var.pdf 3/2012 - Accepted; HG are already aware and will incorporate before criteria are published

05/2012 - Completed

16/05/2012 - Change validation criteria. Added variable component to name of tracking table (cc-tracking-var.pdf)

Pieter Vankeerberghen, FAGG – AFMPS - FAHMP

eCTD pass/fail validation criterion 16.4 regarding PDF file corruption

NeeS pass/fail criterion 3.5 regarding PDF file corruption

This CR proposes a new criterion criteria (Pass/fail) to be checked in both eCTD and NeeS validation for the automated detection of corrupted PDF files.

Proposed text: Each unprotected PDF file is tested for conformance to all requirements* of the ISO 32000-1 specification. This means that when a PDF file opens without errors by a PDF library which is compliant to ISO 32000-1, the PDF file is considered to be conformant. Absence of detection of conformance means corrupted PDF. The applicant is requested to re-submit the sequence with a conformant version of that PDF file."

*Note that ICH M2 PDF Recommendations do not allow to use extensions of the specification and PDF files must not contain JavaScript, dynamic content (which can include audio, video or special effects and animations), attachments or 3D content.

3/2012 - Accepted; referred to Harmonisation Group. Need to determine if known by Harmonisation Group for implementation with the validation criteria currently under review or needs to be tracked for a future revision.

05/2012: Completed

16/05/2012: Change validation criteria. New criterion added to test for corrupted files (eCTD 16.5, NeeS 3.6).

Sandra Hyde, Janssen (formerly J&J)

TIGes Harmonised Guidance for eCTD Submissions in the EU (Version 2.0), August 2011.

Including the tracked changes version of the RMP in addition to the clean version in the eCTD, duplicates the number of documents in the eCTD lifecycle with no benefit to the current view of the dossier. For the purpose of assessment and reviewability, we propose to only include the tracked changes version of 1.8.2 Risk-Management System outside of the eCTD in the working documents folder. The clean version of the PDF would continue to be managed within the eCTD lifecycle.

Update the TIGes Harmonised Guidance for eCTD Submissions in the EU to recommend including the tracked changes version of 1.8.2 Risk-Management System outside of the eCTD in the working documents folder.Proposed update to the TIGes Harmonised Guidance for eCTD Submissions in the EU (to be inserted after Section 3.2.5):“The Risk-Management Plan should be supplied as PDF but some NCAs require a track changes version in addition to facilitate assessment. Those additional files should be provided in the separate folder XXXX-workingdocuments on the same CD / DVD. Details can be found in section 2.9.9. Only the clean version of the Risk-Management Plan should be managed within the eCTD lifecycle”.2012/09: Interlinking agreed that both clean and tracked changes documents should be provided in PDF format inside the eCTD. Q&A to be finalised before TIGes. Agreed to limit to product information and risk mgmt plans, no documents for M3

16/05/2012: Not yet actioned, refer back to Interlinking for discussion before writing a Q&A.2012/09: EFPIA (AN) drafted, Interlinking mtg decided to do some rewording.


This CR proposes a new technical definition how the PDF version is read from a PDF file, according to the ISO 32000-1: 2008 specs.

Proposed text: for eCTD 16.BP1 and NeeS 3.BP.1:

Files have been created and saved as PDF 1.4, 1.5, 1.6, or PDF 1.7

For PDF files with apparent versions of 1.3 or earlier, the version information should be taken from the first eight characters from the first line of the header in the file. For versions 1.4 and higher, the version should be taken from the document catalogue dictionary, if present. If both the header information and the catalogue information are present, then the document catalogue dictionary

Withdrawn; replaced by CR 20120413


This CR proposes a change in the rules for the PDF versions, in line with ICH Q&A 71: PDF 1.4 and 1.7 (with restrictions as identified in the ESTRI recommendation) can now be used in all ICH regions. All ICH regulators now accept PDF 1.4, 1.5, 1.6, and 1.7 with restrictions as described in M2 Recommendation.

Adapt the eCTD and NeeS specifications to allow only PDF 1.4, 1.5, 1.6, and 1.7 with restrictions as described in M2 Recommendation

Similarly, for the EU validation rules: Proposed text for eCTD P/F 16.1 and NeeS P/F 3.1 validation criteria:

5/2012 - Accepted; HG are already aware and will address

16/05/2012: Validation criteria updated, but a Q&A is still needed2012/06 - Q&A added

16/05/2012: validation criteria updated (eCTD: 16.1 and 16.BP1, NeeS: 3.1 and 3.BP1). A Q&A is to be written by the group on m2 PDF recommended restrictions.

Dossier Requirements 20 February 2012, EMA/284601/2011http://www.emea.europa.eu/docs/en_GB/document_library/Other/2009/10/WC500004409.pdf

Distribution Requirements and Address Lists for Periodic Safety Update Reports (PSURs)06 April 2011, EMA/129976/2008, Rev. 6http://www.ema.europa.eu/docs/en_GB/document_library/Regulatory_and_procedural_guideline/2009/11/WC500011223.pdf

eCTD sequences are provided to CHMP members, and the list includes both the member for the BfArM (Harald Enzmann) and the PEI (Jan Mueller-Berghaus, a co-opted member). However, for PSURs, sequences are sent to either the BfArM or, for vaccines and blood and plasma-derived medicinal products, recombinant coagulation factors and monoclonal antibodies, the PEI. If applicants follow this guidance, this means that the BfArM miss all PSUR sequences for biological products, and PEI miss all PSUR sequences for non-biological products. (see CR for breakdown)If non PSUR sequences modify content in PSUR sequences or vice versa, this will generate a fail under eCTD validation criterion 11.9 (The leaf referenced by the modified file must exist in a previously submitted sequence within the same eCTD application).

Amend PSUR distribution list so that the PEI and the BfArM addresses appear as separate entities. Remove the comment about vaccines and blood and plasma-derived medicinal products, recombinant coagulation factors and monoclonal antibodies, so that both PEI and BfArM receive copies of all PSURS.

EMA indicated this was implemented in recently published guidance

If it is anticipated that this could take some time to make the revisions to the documents, the CCB recommends the addition of a Q&A to the tracking table in the interim.





CR 20120924 rev Ágnes Gabriella Kelemen eu-regional.xsl file of eCTD module 1 Completed Implemented in EU M1 v 2.0 Revise Module 1-related documents Interlinking Group

CR 20121004 Manuela Copier, Janssen Biologics eCTD Validaiton Criteria, v 4.1, effective 01 December 2012 Completed TBD Implemented in Q&A 40 Harmonisation Group

CR 20121017 Gerhard Neurauter, Extedo eCTD Validation Criteria 3.x Completed Included in rule 11.10 in Validation Criteria version 5.0 Harmonisation Group No

CR 20121023 Phyllis Thomas, AZ Completed Implemented in Q&A 41 Implemented in Q&A 41 Harmonisation Group

CR 20121119 Completed Implemented in EU M1 v 2.0 Revise Module 1-related documents Interlinking Group

CR 20121126 Miguel Bley, ANSM Replace FR-AFSSAPS with FR-ANSM code in the agency attribute list Completed Implemented in EU M1 v 2.0 Revise Module 1-related documents Interlinking Group

CR 20121207 Christina Grønlund Jensen, DHMA Completed Implemented in EU M1 v 2.0 Revise Module 1-related documents Interlinking Group

CR 20121221 Miguel Bley, ANSM eCTD EU Module 1 Specification, v 1.4.1 Completed Implemented in EU M1 v 2.0 Revise Module 1-related documents Interlinking Group

CR 20130110 Alastair Nixon GSK TIGes Harmonised Guidance for eCTD Submissions in the EU Completed Included in revised eCTD guidance Harmonisation Group No

CR 20130204 Completed Implemented in EU M1 v 2.0 Revise Module 1-related documents Interlinking Group

CR 20130220 Thomas Mauer, EMA eCTD EU Module 1 Specification, v 1.4.1 Completed Implemented in EU M1 v 2.0 Revise Module 1-related documents Interlinking Group

<xsl:when test="@code='HU-IVMP'">Hungary - National Institute of Pharmacy</xsl:when> <xsl:when test="@code='HU-OGYI'">Hungary - Institute for Veterinary Medicinal Products</xsl:when> It is the opposite: the OGYI is for human medicines and the IVMP is for the veterinary medicines. The OGYI has got a new name: National Institute for Quality- and Organizational Development in Healthcare and Medicines, National Institute of Pharmacy

2012/11/27: The CCB would like to propose that where possible a general code is applied rather than capturing specific information about Agency names in the DTD and specification. A separate document would be mamintained to map what Agency is assigned a general code. Furthermore, when setting up the DTD, addition general code values would be included in this revision to allow for additional member states to employ the DTD without having to revise the specification and DTD, only the mapping document. To be discussed further with the group preparing document revisions.2/2013: This recommendation was tabled and will be revisited with the implementation of eCTD v 4.0; a new CR will be generated for tracking

In general, leaf lifecycle operations cannot take place between leaf elements in different CTD sections, e.g. a leaf to be submitted in Module 4.2.2.5 in Sequence 0012 cannot replace/delete a leaf submitted in Module 4.2.2.2 of Sequence 0010.The validation criteria do not check for this requirement.

Follow-up from requester: Applicants should be instructed to never use leaf lifecycle operations between different CTD sections. In those cases where there is a need to execute an update across a CTD section (e.g. due to a M1 specification change) applicants should delete the leaf from the previous location and provide the file as ‘new’ at the new location.

In eCTD, the change of an attribute value (e.g. manufacturer, dosage form etc.) in a follow up submission is not allowed because attribute values do not have a lifecycle.According to the eCTD specification 3.2.2 p100, second paragraph: “When revisions are sent to a regulatory authority, the new leaf element should be submitted in the same location in the backbone as the leaf element being appended, replaced or deleted.”

In case of a technical eCTD validation the following issue is not named as an error (Example):An applicant provides e.g. a replace operation in 3.2.P.4.1 in a follow up submission and additionally changes the manufacturer attribute.As a consequence two 3.2.P sections are displayed in a viewing tool.Note: The location of the file in the folder system is not relevant.

Option 1 ) Introduce a lifecycle validation rule detecting an XML movement of documents inside an eCTD.Option 2) Select an already existing rule to assign this requirementCCB: May need to have the ICH consulted as it goes ; how do other vendors feel about this?

012/11/27: referred to Harmonisation Group

2013/4/16: Address in revised validation criteria, 11.102013/07: Move to closed

EU eCTD validation rulesv4.1, for implementation 1 December 2012

ICH CTD-Q published ICH eCTD Q&A #73 in Nov 2011 on excipient granularity options for Module 3.2.P.4 (refer to Appendix A). EU eCTD validation rules had been based on both the ICH M4 granularity document and Appendix 4 of the ICH eCTD Specification, both of which do not allow files directly in 3.2.P.4. However the published ICH eCTD Q&A now supersedes the previous information.

Have options #1 and #2 from ICH eCTD Q&A #73’s answer (see Appendix A) reflected in European eCTD validation rules, by allowing either an entirely variable file or partly variable file directly in 3.2.P.4.

Luis F. Rodríguez de Robles, AEMPS

EU Module 1 Specification Version 1.3 (DTD and pages 36, 45 and 52)Version 1.3

“ In EU Module 1 Specification Appendix 2.4 page 38 the Agency name “Agencia Española de Medicamentos y Productos Sanitarios” remains the same but the agency code changes to “AEMPS”. The documentation should be updated and the related XML backbone files in eCTD EU M1.

eCTD DTD, eu-envelope of EU Module 1 EU Module 1 v1.4.1

As from May 1, 2012 Afssaps has been replaced by the « Agence national de sécurité du médicament et des produits de santé » (ANSM). The eu-envelope of the EU Module 1 DTD should be updated in the next major release of the specification (involving DTD changes)

eCTD DTD, eu-envelope of EU Module 1 and the corresponding stylesheet.EU Module 1 v1.4.1

As from Marts 1, 2012 the name of the Danish agency has been Danish Health and Medicines Authority (DHMA)This should be reflected when the eu-envelope of the EU Module 1 DTD is updated

Replace DK-DKMA with DK-DHMA in the agency attribute list.(eu-envelope.mod).Replace DK-DKMA with DK-DHMA and Danish Medicines Agency with Danish Health and Medicines Authority in the style sheet (eu-regional.xsl).

The original eAF in XML format has been replaced with a “PDF Form” format that enables extraction of structured data in XML format as a by-product. The change in approach does not change the original principle of introducing structured data in Module 1 for reuse and upload into systems. The same applies to the PIM approach. Even if PIM is terminated the need for structure data remains. Another project could structure product information in the future.Currently no standard EU format in XML format is in use, but the possibility should be left open, since it reflects the underlying philosophy for EU Module 1

Either we remove XML ref on the table and make a general statement or we keep XML for the identified specific locations with a note in the lines of “XML format could replace PDF format whenever a structured EU exchange standard exists for the content in the specific CTD location”.

According to the TIGes guidance, a Decision / Closing sequence – including final translations is submitted at Commission Decision + 5. However, according to Transitional provisions for implementation of Commission Regulation (EU) No 712/2012 amending Variations Regulation (EC) No 1234/2008, and specifically the amendment to article 23 (b) 1a, (b), amendments to the decision will be made, “within 12 months following receipt of the information”. How does an applicant then handle the Decision / Closing sequence?

Applicant submits the Final Opinion in the eCTD with a suitable leaf title, such as “Final Opinion, Subject to Commission Decision”, and does not have to follow up with another sequence for Commission Decision once it is received.

2013/02: Referred to Harmonisation Group2013/4/16: Accepted, will be addressed in the next update of the Harmonised eCTD Guidance Document.2013/08: Has been included in the new version of the eCTD guidance2013/09: Move to closed

Mickel HedemandDanish Health and Medicines AuthorityTIGes Harmonisation Group

EU M1 specifications App. 2 “Directory / File Structure for Module 1”, TIGeS Harmonised eCTD Guidance, section 3.2.3.2 “Tracking Table”, eCTD validation criterion 15.12 and “File-Folder Structure & Names”, NeeS validation criteria, “File-Folder Structure & Names”, CMDh BPG on eCTD in MRP/DCP section 2.2 “Tracking Table”

The naming convention for the tracking table stands out as a special instance of another naming convention, that of the cover letter.

The tracking table is not a cover letter. And to avoid confusion with the cover letter naming convention (“CC-cover-VAR.pdf”), these two naming conventions should be clearly separated.

In the above mentioned documents the naming convention for the tracking table should be changed to “CC-tracking-VAR.pdf”.

Current version of specification does not have a specific submission type that allows Risk Management Plans to be submitted as a stand-alone submission.

Addition of RMP to the existing submission types in EU M1 Specification. Note this change has already been made to the stylesheet by the EMA, this is a retrospective CR for change control purposes.





CR 20130222 Alastair Nixon GSK eCTD EU Module 1 Specification, v 1.4.1 Completed Revise Module 1-related documents & eCTD validation criteria

CR 20130307 EU validation criteria for NeeS and eCTD Withdrawn N/A Harmonisation Group

CR 20130614 Completed ASAP Addressed in Release Notes EMA No

CR 20130703 EU Region eCTD Validation Criteria version 5.0, criterion 11.10 Aug-13 Harmonisation Group No

The agency listing says:<xsl:when test="@code='UK-MHRA'">Medicines and Healthcare products Regulatory Agency, Market Towers</xsl:when>

It should be simplified to: <xsl:when test="@code='UK-MHRA'">Medicines and Healthcare products Regulatory Agency</xsl:when>

As above. Note this change has already been made to the stylesheet by the EMA, this is a retrospective CR for change control purposes.

Implemented in EU M1 v 2.0 & Validation criteria updated v 5.0

Interlinking GroupHarmonisation Group

Melanie Ruppel, Boehringer-Ingelheim The next update of the validation criteria will allow documents to be placed directly into

3.2.P.4. Two additional documents have been identified that need similar granularity options in 3.2.P.5 and 3.2.S.4 in order to cope with ICH Q8 and Q10. Both documents, i.e. “control strategy for drug substance” and “control strategy for drug product” are regarded as key information on drug substance and drug product quality, linking critical quality attributes with the actual controls, and therefore, should be placed directly under 3.2.S.4 and 3.2.P.5.

EU validation criteria for NeeS and eCTD should include granularity in order to allow for files to be placed directly into 3.2.S.4 and 3.2.P.5.Only one document should be allowed in 3.2.S.4 and 3.2.P.5 with the proposed filename “ctrlstrat-VAR.pdf”

Notify requester to submit a CR to ICH M8 per their change request process

Cynthia PiccirilloBMS

Implementation Guide for EU Module 1 Specification, version 2.0 and EU eCTD Validation Criteria, version 5.0, EU NeeS Validation Criteria, version 4.0

The Implementation Guide was released to describe how to manage preparation of submissions during the transition period from when Croatia accession to the EU goes into effect (1 July 2013) until the mandatory use of the used M1 eCTD specification, v 2.0, and eCTD validation criteria, v5.0, (1 Sept 2013). However, it does not indicate whether or not to provide copies of previously submitted sequences for CAP MAAs to Croatia. It is believed it would be beneficial to the HALMED reviewers to have copies of the previous sequences in order to successfully view and manage the life cycle of the eCTD XML backbone.

The MAH sending sequences in after Croatia’s accession need the correct contact information for HALMED.

Revise the Implementation Guide immediately to ensure it states whether or not an MAH has to provide Croatia with copies of previous sequences for MAAs in the Centralised Procedure before making a new lifecycle submission. It would also be helpful to be clear in the Implementation Guide that HALMED will not validate the previously submitted sequence copies regardless of whether they are provided by EMA or the MAH.

Furthermore, in general terms, the information where to send the copies to HALMED needs to be added to the spreadsheet posted on the EMA eSubmission website under “Contact Points”. In addition, the eSubmission website only has a link for the Implementation Guide on the “What’s New” page; it is missing on the “EU Module 1” page where the rest of the Module 1 documents reside, but there is a place for it in the table therein. http://esubmission.emea.europa.eu/eumodule1/index.htm

If the MAH is to provide the copies, other points need to be addressed in the Implementation Guide:• When should the previously submitted sequences be sent? Would it be acceptable to send it at the same time as submission of the new sequence or should it be provided ahead of time?• Is it acceptable to have multiple sequences on media, i.e. a single DVD?

Michael BraunExalon

As part of the EU M1 eCTD specification update to version 2.0 the country subdirectory in the Centralized Procedure has been changed from “emea” to “ema” in accordance to the name change of the Agency.

In combination to eCTD validation criterion 11.10 this leads currently to invalid eCTD sequences during life-cycle submissions of existing eCTDs in case of replace, delete or append operations within the country subdirectory “ema”. For example: if a previously submitted document provided in a country subdirectory “emea” (e.g. Annex to Application form or Product Information) is to be replaced by a new version in an new eCTD sequence that is compliant to EU M1 eCTD v.2.0 the new document version will be placed in the newly introduced country subdirectory “ema”. Correspondingly the value of the “country” element attribute will change from country=”emea” to country=”ema” in the eu-regional.xml. In the current versions of the eCTD validators (EURS, eValidator) this is interpreted as a violation against Pass/Fail criterion 11.10 which states that “For all leaves with an operation attribute value of replace, delete or append, the modified file must be present in the same CTD section of the dossier. Using the operation attribute 'delete' to remove content in sections in EU m1 which are no longer used, due to updates of the CTD, should be exempt from this rule”.

Operation attributes replace, delete and append should be allowed between different country subdirectories of the same Module 1 section and should be exempted accordingly from criterion 11.10. At least an exemption must be implemented for the “emea to ema change” as it is unlikely that other country codes will change in the near future.

Alternatively criterion 11.10 should be changed from Pass/Fail to Best Practice only.

2013/07: Accepted, referred to Harmonisation Group2013/08: A Q&A has been published on the eSubmission website and also the new version of the EU Harmonisied eCTD guidance includes clarification.2013/09: Move to closed

Q&A published. New version of the EU Harmonised eCTD guidance to be published end of August 2013.

# Question Answer Text Included in EU M1 v1.4? Include Text in EU M1 Revision?

30 Nov-11 NO NO

31 Nov-11 NO NO

33 12-Jan NO NO

34 12-Jan NO NO

35 Mar-12 NO NO

Approval Date

Clarification Concerning the New Validation Criteria for eCTD:The revised criteria for technical validation of eCTD sequences (v3.1) should be treated as a single complete set of tests and not be divided in any way.

This question was generated by discussion in the TIGes Harmonisation Group in June 2011.

The revised criteria for technical validation of eCTD sequences (v3.1) contain some checks that can only be reliably performed in context of other eCTD sequences in the life cycle, indicated with a ‘Y’ in the published list.

Due to a request for clarification on this issue, the TIGes would like to confirm that when testing eCTD submissions using the new validation criteria (v3.1), all checks are expected to be done in entirety. This includes those criteria for which preceding sequences need to be present when testing. The classification of criteria with a “Y” was intended to indicate that the result will be unreliable if the sequence is tested in isolation. When testing individual sequences without the rest of the eCTD life cycle present, the results of tests on these criteria should be interpreted carefully and the tools should preferably indicate this in the test report. The classification “Y” should not be interpreted as defining a second set of criteria to be used in certain cases only.

A submission is technically valid only if all Pass/Fail criteria are passed, whether the criterion is marked with a “Y” or not.

All tests, including BP criteria, with or without the “Y”, should be tested and fulfilled by applicants before submitting the eCTD to the authority. Ideally, reports from validation tools should indicate if life cycle was present or not when the checks were done, and clearly indicate that the results from checks marked with a “Y” may be unreliable if life cycle was not present.In addition, it would be preferred if the report stated specifically which sequences were present when the test was carried out, such that errors relating to missing sequences can be interpreted correctly.

The new eCTD validation rules require a binary identical copy of the ICH and the EU M1 style sheets to fulfill the eCTD validation criteria 02.04 and 06.04. This is verified by means of the MD5 checksum.

This question was generated by discussion in the TIGes Harmonisation Group in July 2011.

Several agencies noticed that for some eCTD submissions the style sheets provided by the eCTD building tools do not produce the correct MD5 checksum. After 1st Sep 2011, this would result in technically invalid submissions. Therefore, we would like to advice vendors to double-check their eCTD building tools and assure that the correct files will be used. Applicants that discover this problem should contact the vendor or adapt the style sheets themselves and always validate submissions prior to sending to agencies. ‘

Are there any security settings that can make a literature reference fail technical eCTD or NeeS validation, if the reference is placed in one of the exempt locations (Modules 3.3, 4.3 and 5.4, rule 16.3 (eCTD) and rule 3.3 (NeeS))? This question was generated by discussion in the TIGes Harmonisation Group in November 2011, following informal testing of two of the current European eCTD/NeeS validation tools.

All security settings except file open security should be exempt in the sections listed, since applicants may not have the ability or permission to edit PDF documents supplied for literature references. It is essential that all submission content can be opened, but this is tested in different rule (rule 16.2 eCTD, rule 3.2 NeeS). If any eCTD or NeeS validation tool returns an error for a file in section 3.3, 4.3 or 5.4 and the file can be opened, and then this error should be ignored.

The EU eCTD validation criterion number 15.6 specifies that only valid characters are used in file names. Is this rule intended to be used only on the file names themselves in the file system, or does it also apply to the paths to the files in the eCTD XML i.e. the xlink:hrefs?

The validation criterion number 15.6 as currently written applies only to the file names in the file system, not to the file path in the xlink:href (cross reference) in the XML. This will, however, be changed in the next version of the eCTD Validation Criteria, to clarify that rule 15.6 refers only to the file names in the file system. In addition, to have a check also on the paths to the files in the eCTD XML, the following text will be added to the comment for criterion number 11.4 (where the XML cross reference is checked): “The value for the cross reference (xlink:href) should be valid, and not contain any illegal characters.”

The “Practical guidelines on the use of the eCTD format for ASMFs for active substance master file holders and marketing authorisation holders” recommends RP and AP to be used as prefixes to clarify different documents belonging to the applicant’s part or the restricted part. However, for NeeS, file names in module 1-3 are obliged to follow the given convention to pass a technical validation (P/F criterion) and it was therefore recommended to use RP and AP as suffixes to the file names. It would then be part of the variable part (-var) of the file name and therefore would pass the technical validation.Should RP and AP now be used as prefix or suffix for eCTDs?

Even if the naming convention is not binding for eCTDs (BP criterion), it would be recommended that the RP and AP are used in the same way for NeeS and eCTD. It is therefore recommended to use RP and AP as suffix also for eCTD, even if this contradicts the current version of the above mentioned guidance document. The guidance document itself will be updated in due course.

F1


# Question Answer Text Included in EU M1 v1.4? Include Text in EU M1 Revision?Approval Date

36 Mar-12 NO Summary text only

Examples:m1/responses/common/

37 Mar-12 NO NO

39 2/21/2013 NO NO

How should an applicant name the files in the responses to questions section of an eCTD or a NeeS?This question was generated by discussion in the TIGes Harmonisation Group in .

In m1-responses/cc, it is recommended to use the variable component of the filename and, in eCTD submissions, the leaf title, to present the information clearly to the assessor.

The response files should preferably be named as:

cc-responses-<regulatory activity type identifier>-<timeline identifier>-<content identifier>.pdf, using the -var component of the filename to define the content.

Suggested Filename (NeeS and eCTD) Suggested Leaf Titlecommon-responses-maa-d106-clin.pdf Day 106 Clinical Responses, MAAcommon-responses-maa-d120-clin.pdf Day 120 Clinical Responses, MAAcommon-responses-maa-d145-clin.pdf Day 145 Clinical Responses, MAAcommon-responses-maa-d120-clinq4.pdf Day 120, Clinical Response Question 4, MAAcommon-responses-maa-d120-clinq7.pdf Day 120, Clinical Response Question 7, MAAcommon-responses-var03-d45-clin.pdf Day 45 Clinical Responses, Var03common-responses-var03-d59-clin.pdf Day 59 Clinical Responses, Var03common-responses-maa-d106-qual.pdf Day 106 Quality Responses, MAAcommon-responses-maa-d120-qual.pdf Day 120 Quality Responses, MAAcommon-responses-maa-d145-qual.pdf Day 145 Quality Responses, MAAcommon-responses-var05-d44-qual.pdf Day 44 Quality Responses, Var 05common-responses-var05-d59-qual.pdf Day 59 Quality Responses, Var 05common-responses-var12-d33-qual.pdf Day 33 Quality Responses, Var 12

Links in a NeeS are relative and fully functional at applicant’s side, but fail at the NCA. How can that be?

This is often caused by hyperlinks containing “../” (one folder level up). Both the root folder and the four digit NeeS folder may be renamed by the NCA before archiving. If so, links pointing out of and back into the submission will be broken or even pointing to the wrong document. For that reason, and because a module ToC should never link to files in other modules, hyperlinks in a TOC file should never contain “../”, except for in the return link to the ctd-toc.pdf file.For example:../0000/m1/eu/eu-regional.xml../../mydrug/0000/m1/eu/eu-regional.xml

These linked are routed though the folders ‘0000’ and ‘mydrug/0000’ respectively, and these folders may not exist once the submission is processed into the agency’s system.

How should applicants provide documents with tracked changes highlighted to facilitate review?

This question addresses CR 20120302.

Only clean versions of documents in PDF format should be managed within the eCTD lifecycle. If additional formats are required by an authority to facilitate the assessment (e.g. tracked changes versions for SmPCs, Risk Management Plans or other documents as specified by the agency), these should be provided in the separate folder ‘XXXX-workingdocuments’ alongside the eCTD on the same CD / DVD or in the same zip file for electronic gateway submissions.. Further details can be found in section 2.9.9 of the TIGes Harmonised Guidance for eCTD Submissions in the EU.

An exception to this rule is in the provision of either product labelling or risk management plan documentation in the Centralised Procedure, where the tracked changes version of the document in PDF format should be placed inside the eCTD, alongside the clean, non-tracked version.

F1


# Question Answer Text Included in EU M1 v1.4? Include Text in EU M1 Revision?Approval Date

40 2/21/2013 NO NO

41 2/21/2013 NO NO

42 May-13 NO NO

The ICH specification v3.2.2 says not to replace across sections (page 6-3). However, the EU eCTD guidance v2.0 allows this in certain circumstances (section 2.9.5). Why is the guidance different?


In general, leaf lifecycle operations cannot take place between leaf elements in different CTD sections.

Section 2.9.5 in the EU eCTD guidance v.2.0 allows for specific exceptions in cases in which leaf lifecycle operations across sections cannot be avoided.

E.g. in case a CTD section doesn’t exist anymore in the current DTD, but contains content in an old sequence. If this old content needs to be replaced, leaf lifecycle operations between different CTD sections are the only way of doing this.

However, as of now only the operation ‘delete’ is allowed in these cases, i.e. the operations ‘replace’ and ‘append’ should not be used for this purpose.

For the exceptions mentioned in section 2.9.5, applicants should ‘delete’ the content in the old section and provide the replacement content in the new section with the operation attribute of ‘new’.

However, applicants cannot submit a dossier using the old specification and DTD. Therefore, deleting the content in the old section will involve lifecycle from the changed section (for example, m1-additional-data) deleting content in the equivalent section with the original name (in this example, m1-additional). This may not be possible in all eCTD building tools, and if so, applicants are advised to leave the original content as it is, but to start providing new or replacement content in the revised section.

A new Pass/Fail validation criterion to test for the use of lifecycle operations ‘replace’, ‘append’ and ‘delete’ across CTD sections will be added to the EU Validation Criteria at the next update. In the situation ‘delete’ operations are used for the specified exceptions in section 2.9.5, validation tools should not flag these as a fail.

ICH CTD-Q published ICH eCTD Q&A #73 in Nov 2011 on excipient granularity options for Module 3.2.P.4 (refer to Appendix A). EU eCTD validation rules had been based on both the ICH M4 granularity document and Appendix 4 of the ICH eCTD Specification, both of which do not allow files directly in 3.2.P.4. However the published ICH eCTD Q&A now supersedes the previous information. Can applicants follow the advice in ICH Q&A 73 for submissions in the EU?


It is recognised that the current versions of the EU validation criteria for NeeS and eCTD do not allow for files to be placed directly into 3.2.P.4. This will be changed the next time the criteria are updated. In the meantime, applicants should note that the criterion governing file names for eCTD, 15.BP3, is a Best Practice criterion only, and, as such, applicants are able to use the structures recommended by ICH in Q&A 73. However, for NeeS, the equivalent criterion (2.11) is a Pass/Fail criterion, and, until the validation criteria are updated, applicants submitting NeeS will have to adhere to the current EU file naming rules, which do not allow a single file in 3.2.P.4.

Parallel variations are variations ongoing within a single product lifecycle at the same point in time that are modifying the same content. Tracking these variations and modification of the content representing the current-approved baseline represents a particular business challenge within eCTD.

This Q&A presents the recommended approach for managing parallel variations in accordance with the ICH and EU eCTD Specifications.

This addresses QA-20071022-01.

Best Practice Guide for Parallel Variatio

F1


# Question Answer

10

23 Click on icon for Answer

24

Where can node extensions be used in a EU eCTD submission?

The question was generated by ICH change request 00560 and the response to ICH eCTD Question 28. This is recorded as EU Change Request A010.

Node extensions may be used where additional navigation in the XML backbone is required. The primary place where they may be used is in Module 5 where a node extension for each study may be useful so as to allow multiple files for a single study to be grouped together and separated distinctly from other studies. 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.

Lifecycle across sectionsThis question was generated by EU Change Request CR-20090615

In the EU Module v1.4 the related-sequence element in the envelope can be declared with an optional country attribute. Should this be used?This question was generated by EU Change Request CR-20090820

The inclusion of the optional country attribute was an error. This attribute had been removed from the previous version of the specification.

There is no requirement for the applicants to use this attribute. Furthermore, tool vendors should not include this in their tools for creating EU Module 1 v1.4 as this was included in error.

Q&A 23.doc



27

The new EU M1 specification and eCTD validation rules place more emphasis on using the related sequence element in the eCTD correctly. However, although there are already some general guidelines available (Q&A #12 in the EU Change Request/Q&A Tracking Table), there is a need to provide more guidance, particularly related to different regulatory activities. Can additional guidance be provided?This question was generated by discussion at Feb 2010 Interlinking Group Meeting

Typically a baseline submission is filed as a single sequence for which the submission type ‘reformat’ will be used. However, it is possible that a baseline can be submitted as multiple sequences, e.g one sequence for the baseline for Modules 4 and 5 followed later by one sequence for the baseline for Module 3. In such a circumstance what should the submission type of the second baseline be and should a Related Sequence be used for the second baseline?This question was generated by discussion at Feb 2010 Interlinking Group Meeting

The EU Module 1 Specification, v1.4 currently defines two uses for the submission type “withdrawal”. Should the submission type ‘withdrawal’ be used for both the notification of a withdrawal of a marketing authorisation and for the withdrawal of a variation submission during assessment?This question was generated by discussion at Feb 2010 Interlinking Group Meeting

The submission type ‘withdrawal’ should only be used for the notification by the applicant to the regulator of the withdrawal of a marketing authorisation. It should not be used for the withdrawal of a variation, or parts of a grouped variation, during the assessment. In this circumstance the submission type to use is ‘supplemental-info’.

Q&A 25.doc

Q&A 26.doc

28 Refer to the eCTD Guidance section 3.2.6

29

The EU Module 1 specifications refers to the fact that “Filename for responses to questions composed by a fixed component “CC”, a fixed component “responses” and an optional variable component to be used if needed (e.g. be-responses.pdf)”This suggests that response documents are written per country in multi-country submissions. However in practise responses for a multi-country submission are regarded as common. Can clarification be provided as to how the country specific folders and file-naming should be used?

This question was generated by EU Change Request CR-20090909-02.

With a paper submission there is the possibility of submitting a response to a question which may contain a proposal (e.g. a change to the specification) and at a later moment in time, when the answer is found to be acceptable by the regulators, the revised Module 3 content can be submitted.Is it with a submission in eCTD-format always expected that the Module 3 section is updated at the time of submitting the response or can this also be delayed until it is known that the response is acceptable?This question was generated by EU Change Request CR-20060627-03.

Refer to CMDh Best Practice Guide on the use of eCTD in MRP/DCP for how to handle draft responses

32

38

PDF version 1.7 is now fully accepted for both eCTD and NeeS and the validation criteria will later be updated to reflect this.

This question was generated by discussion in the TIGes in September and November 2011.

PDF version 1.7 is now accepted by ICH for eCTD submissions and is also included as an acceptable format in the latest update of the EU M1 eCTD specification. It has therefore been included as an acceptable format in the TIGes Harmonised eCTD guidance as well as the TIGes Harmonised guidance for NeeS. CRs will be submitted for the validation criteria to be updated accordingly. Until new versions of these criteria are published, BP warnings given for PDF format 1.7 (eCTD criterion 16.BP1 and NeeS criterion 3.BP1) by any validation tool can be ignored by applicants.(http://estri.ich.org/recommendations/PDF_V2_0.pdf)

Which version for PDF files is acceptable in the context of submissions by sponsors for regulatory approval of medicinal products using eCTD or NeeS format?CR 20120413 (replaced CR 20120326)

Q&A 38.doc

Approval Date Retired Date

Mar-2007 Sep-11 Partially YES

Sep-11 N/A N/A

Oct-2009 Mar-13 N/A YES

Text Included in EU M1 v1.4?

Text Included in other EU M1

Revision?

G1


Feb-10 N/A N/A YES

Feb-10 N/A N/A YES

Feb-10 N/A N/A Major Revision

Nov-11 Nov-11 YES

Nov-11 Nov-11

Nov-11 Mar-13 N/A YES

May-12 Mar-13 N/A YES