Page 1 of 56
Guidance for Industry on Providing Regulatory Information in Electronic Format
Harmonised Technical Guidance for
eCTD Submissions in the EU
Version 5.0
Prepared by the Human Harmonisation Group as new version 5.0
Until November 2021
Adoption (version 5.0) by the eSubmission Expert Group
17 December 2021
Date for coming into effect (version 5.0)
1 February 2022
Page 2 of 56
Table of Contents
Contents
Table of Contents ..........................................................................................................................2
List of Tables ................................................................................................................................5
1. INTRODUCTION...................................................................................................................6
1.1 GLOSSARY .............................................................................................................................. 7
2. GENERAL CONSIDERATIONS .............................................................................................8
2.1 SCOPE .................................................................................................................................... 8
2.1.1 Types of Product ............................................................................................................8
2.1.2 Types of Submission.......................................................................................................8
2.1.3 Types of Submission Units ..............................................................................................8
2.1.4 Types of Procedures .......................................................................................................8
2.1.5 Exceptions ....................................................................................................................8
2.2 STRUCTURE OF SUBMISSIONS.................................................................................................... 8
2.3 TRANSITIONAL ARRANGEMENTS............................................................................................... 9
2.4 CHANGE TO ECTD FORMAT ..................................................................................................... 9
2.5 GENERAL SUBMISSION CONSIDERATIONS ................................................................................ 10
2.5.1 Document Granularity................................................................................................... 10
2.5.2 File Naming ................................................................................................................ 10
2.5.3 Placement of Documents ............................................................................................... 10
2.6 CORRESPONDENCE ................................................................................................................ 10
2.7 PAPER REQUIREMENTS .......................................................................................................... 11
2.8 HARDWARE........................................................................................................................... 11
2.9 GENERAL TECHNICAL ECTD INFORMATION ............................................................................ 11
2.9.1 Identifier for Applications.............................................................................................. 11
2.9.2 File Formats ................................................................................................................ 11
2.9.3 Portable Document Format (PDF)................................................................................... 11
2.9.4 Sequence Numbers ....................................................................................................... 12
2.9.5 Related Sequence ......................................................................................................... 12
2.9.6 Leaf Lifecycle Operation Attributes ................................................................................ 13
2.9.7 Bookmarks and Hypertext Links..................................................................................... 15
2.9.8 Node Extensions .......................................................................................................... 15
2.9.9 Extensible Mark-up Language (XML) ............................................................................. 15
2.9.10 Other File Formats ....................................................................................................... 15
2.9.11 Technical Validation of eCTD Submissions ..................................................................... 16
2.10 OTHER TECHNICAL INFORMATION ...................................................................................... 17
2.10.1 Protection against Malware ............................................................................................ 17
2.10.2 Security Settings .......................................................................................................... 17
2.10.3 Signatures ................................................................................................................... 17
2.11 TECHNICAL BASELINE APPLICATIONS ................................................................................. 18
2.11.1 Baselines Starting as Sequence 0000 ............................................................................... 18
2.11.2 Baselines Starting Later in Lifecycle ............................................................................... 18
2.11.3 Re-Baselining a Broken eCTD Lifecycle ......................................................................... 19
2.12 PROCEDURE FOR SENDING ELECTRONIC INFORMATION ........................................................ 21
2.12.1 Portals/Gateways.......................................................................................................... 21
Page 3 of 56
2.12.2 CD / DVD................................................................................................................... 22
2.12.4 EudraLink / e-Mail (where applicable)............................................................................. 22
3. MODULE SPECIFIC INFORMATION ................................................................................. 23
3.1 GENERAL INFORMATION ........................................................................................................ 23
3.2 MODULE 1 ECTD ENVELOPE, ADMINISTRATIVE INFORMATION AND PRESCRIBING INFORMATION
FOLDER ...................................................................................................................................... 23
3.2.1 General Considerations ................................................................................................. 23
3.2.2 Creation and Management of Envelope Information .......................................................... 23
3.2.3 Module 1.0 Containing Cover Letter and Tracking Table.................................................... 24
3.2.4 Application Forms........................................................................................................ 25
3.2.5 Product information ...................................................................................................... 25
3.2.6 Use of Response Documents Section ............................................................................... 25
3.2.7 Use of the Additional Data Section ................................................................................. 26
3.3 MODULE 2 OVERVIEWS AND SUMMARIES FOLDER.................................................................... 26
3.3.1 General Considerations ................................................................................................. 26
3.3.2 Structure of Module 2 Documents................................................................................... 26
3.4 MODULE 3 QUALITY FOLDER ................................................................................................. 27
3.4.1 Module 32S drug substance ........................................................................................... 27
3.4.2 Module 32p drug product .............................................................................................. 28
3.5 MODULE 4 NONCLINICAL STUDY REPORTS FOLDER ................................................................. 29
3.5.1 Guidance on the Handling of Granular Study Reports ........................................................ 29
3.6 MODULE 5 CLINICAL STUDY REPORTS FOLDER ....................................................................... 30
3.6.1 Management and Handling of Multiple Indications............................................................ 30
3.6.2 Management and Handling of Granular Clinical Study Reports ........................................... 30
3.6.3 Provision of CRFs and Data when Requested ................................................................... 30
3.6.4 Provision of Synopses of Individual Studies ..................................................................... 30
3.6.5 Company Core Data Sheet ............................................................................................. 30
4. ADVICE ON SPECIFIC APPLICATION TYPES ................................................................... 31
4.1 NEW MA APPLICATIONS ........................................................................................................ 31
4.2 VARIATION APPLICATIONS ..................................................................................................... 32
4.3 EXTENSION SUBMISSIONS ....................................................................................................... 34
4.4 RENEWAL SUBMISSIONS ......................................................................................................... 34
4.5 PSURS.................................................................................................................................. 35
4.6 REFERRALS........................................................................................................................... 37
4.6.1 CMDh referrals related to MRP/DCP/RUP....................................................................... 37
4.6.2 EMA-led referral procedures.......................................................................................... 37
4.7 ACTIVE SUBSTANCE MASTER FILES ........................................................................................ 37
4.8 VACCINE ANTIGEN MASTER FILES.......................................................................................... 38
4.9 PLASMA MASTER FILES (PMFS) AND MEDICINAL PRODUCTS CONTAINING PMFS ........................ 38
4.9.1 Plasma Master Files...................................................................................................... 38
4.9.2 Medicinal products containing PMFs............................................................................... 38
4.10 APPLICANT INITIATED WITHDRAWALS OF THE MA OR CERTAIN STRENGTHS OR DOSAGE FORMS
38
4.11 APPLICANT WITHDRAWAL OR AGENCY REJECTIONS OF POST-AUTHORISATION REGULATORY
ACTIVITIES ................................................................................................................................. 39
4.12 PUBLICATION OF CLINICAL DATA FOR MEDICINAL PRODUCTS .............................................. 39
4.13 DUPLICATE APPLICATIONS ................................................................................................. 39
4.14 INFORMED CONSENT APPLICATIONS.................................................................................... 40
ANNEX 1: ECTD REFERENCE DOCUMENTS ........................................................................ 41
Page 4 of 56
ANNEX 2: TRACKING TABLE EXAMPLE ............................................................................. 42
A2-1 INTRODUCTION .................................................................................................................. 42
A2-2 TRACKING TABLE EXAMPLE FOR CP AND NP........................................................................ 42
ANNEX 3: GUIDANCE AND BEST PRACTICE ON THE STRUCTURE OF MODULE 3 .......... 44
A3-1 INTRODUCTION .................................................................................................................. 44
A3-1.1 Terminology in the eCTD modul 3 XML ......................................................................... 44
A3-2 GENERAL PRINCIPLES ........................................................................................................ 44
A3-2.1 Document Granularity................................................................................................... 44
A3-2.2 Identifying to an Agency what the Application covers........................................................ 44
A3-3 MODULE 3 XML ATTRIBUTES IN THE ECTD......................................................................... 45
A3-3.1 Choosing Module 3 XML Attributes ............................................................................... 45
A3-3.2 Drug Substance (32s) Attributes ..................................................................................... 45
A3-3.3 Drug Product (32p) Product/Dosage Form/Manufacturer ................................................. 46
A3-3.4 Excipients ................................................................................................................... 47
ANNEX 4 MANAGEMENT OF PARALLEL VARIATIONS IN THE ECTD................................ 48
A4-1 BACKGROUND.................................................................................................................... 48
A4-2 BUSINESS CHALLENGE ....................................................................................................... 48
A4-3 BEST PRACTICE ................................................................................................................. 48
A4-4 DESCRIPTION OF FIGURES .................................................................................................. 49
A4-4.1 Use of one Lifecycle (Option 1)...................................................................................... 49
A4-4.2 Creation of separate Approved and Proposed Document Lifecycles (Option 2) ...................... 50
Page 5 of 56
List of Tables
Table 1 : Example of a PSUSA .............................................................................................. 12
Table 2 : Example of a Referral for CAPs ............................................................................. 13
Table 3 : Example of a Referral for NAPs ............................................................................. 13
Table 4 : Repeatable Elements and Attributes that Define Different Sections.................... 14
Table 5 : Example for starting an eCTD with a baseline sequence ..................................... 18
Table 6 : Example for starting an eCTD with regulatory activity sequence ......................... 18
Table 7 : Examples of Filenames and Leaf Titles for Response Documents...................... 26
Table 8 : MAA Centralised Procedure ................................................................................ 31
Table 9 : Centralised Procedure - Outside eCTD via EudraLink ......................................... 32
Table 10 : New MAA Decentralised Procedure ................................................................. 32
Table 11 : Type II Variations Centralised Procedure......................................................... 33
Table 12 : Type IA & IB Variations Centralised Procedure ............................................... 33
Table 13 : Type IB Variations with linguistic review - Centralised Procedure ..................... 33
Table 14 : Renewals ............................................................................................................... 35
Table 15 : Centralised Procedure Outside eCTD via EudraLink ...................................... 35
Page 6 of 56
1. Introduction
This guidance document is intended to assist pharmaceutical companies with the submission of regulatory
information in electronic Common Technical Document format (eCTD) to the National Competent Authorities
(NCAs) and the European Medicines Agency (EMA). Also, the guidance aims to be used by the NCAs to
harmonise the requirements on eCTD submissions in EU/EEA.
The eCTD format is mandatory to use for all regulatory submissions within all procedure types within EU/EEA,
i.e. centralised, decentralised, mutual recognition and national procedures. The eCTD format is also
mandatory for any related ASMF, both the Applicant’s and the Restricted part,
This document is an important guidance to harmonise the use of eCTD within EU/EEA and is regularly updated
in the light of changes in national and/or EU legislation and agreements in the network. If needed, there are
also Q&A documents published in between versions of this guidance as a response on change requests or
new requirements to be addressed. In addition, there are some procedure specific guidance documents
published. These documents and other relevant information about eCTD and electronic submissions can be
found at the EMA eSubmission website).
Page 7 of 56
1.1 Glossary
A brief glossary of terms (for the purpose of this document only) is indicated below:
Term
Definition
Applicant
The company requesting a Marketing Authorisation for a medicinal
product.
Applicant’s Information
Regulatory information submitted by an applicant to obtain or maintain
a marketing authorisation that falls within the scope of this guidance
document.
Active Substance Master
File holder
The company who is the legal owner of an Active Substance Master
File as documentation of the manufacturing of an active substance.
eCTD application, also
known as a dossier
A collection of electronic documents compiled by a pharmaceutical
company or its agent in compliance with European legislation and
guidelines in order to seek a marketing authorisation or any
amendments thereof. An eCTD application may comprise a number of
regulatory activities. In the EU an eCTD application may comprise
several dosage forms and/or strengths, all under one invented product
name. This is understood to be equivalent to a Global Marketing
Authorisation according to Art. 6 para 2 Dir. 2001/83/EC as amended.
Procedure
A registration procedure for the authorisation of medicinal products
within the EU. There are four different types of procedures within the
EU Centralised, Decentralised, Mutual Recognition and National.
Regulatory Activity
A single sequence or a collection of sequences covering the start to
the end of a specific business process, e.g. an MA application or Type
II variation. To allow a more precise handling, the regulatory activity will
be classified using a controlled vocabulary (submission type or
regulatory activity type) and a free text field for a short narrative
description.
Sequence
A single set of information and / or electronic documents submitted at
one particular time by the applicant either as a part of or as the
complete application. Any collection of content assembled in
accordance with the eCTD specification (ICH and EU) is described
using metadata as defined by the EU envelope. Sequences may be
related to one another within one regulatory activity. The related
sequence number should always be stated. In case of activities with
only one sequence the same sequence number is used.
Submission Type
The submission type describes the regulatory activity to which the
content is submitted.
Submission Unit Type
The submission unit type element of the envelope metadata set
describes the content at a lower level (a “sub-activity) which is
submitted in relation to a defined regulatory activity such as the initial
submission, the applicant response to validation issues or list of
questions or any other additional information.
Page 8 of 56
2. General Considerations
2.1 Scope
2.1.1 Types of Product
This guidance covers the submission of electronic regulatory information for all human medicinal products
falling within the competence of NCAs in the EU/EEA as well as the EMA. This includes, but is not limited to,
both prescription and over the counter medicinal product submissions, as innovative, generic and biosimilar
product submissions. The product types include for example small molecules, biotech products, herbals,
vaccines, homeopathic products or blood products.
2.1.2 Types of Submission
This guidance applies to all submissions related to the authorisation and maintenance of medicinal products,
including new marketing authorisations, extensions, variations, renewals, PSURs (including PSUR Single
Assessment PSUSA), Active Substance Master Files (ASMF), Plasma Master Files (PMF) and withdrawals,
submission of redacted clinical trial reports as well as any kind of paediatric submissions and referral related
or post authorisation measures related submissions (e.g. PASS, PSUFU, Referrals, Signals). For variations,
PSUSAs, ASMF and PMF there are also specific guidance documents (see references in Annex 1).
2.1.3 Types of Submission Units
The submission units allow sequences that make up a Regulatory Activity to be grouped together. It describes
the submission steps within a Regulatory Activity, such as initial, validation-response, response and closing in
case of a new MAA.
The submission unit additional-info’ should be used f or additional information (which could include, for
example, missing files), and should only be used when validation-response or response is not suitable.
Submission unit ‘consolidation’ should be used for applicant’s withdrawals and authorities’ rejections of a
specific regulatory activity to bring the dossier back to the previous state. The submission type corrigendum
should only be used in exceptional circumstances in the CP to correct information, typically for product
information, after the Regulatory Activity has concluded.
2.1.4 Types of Procedures
This guidance covers applications made in any of the applicable procedures, i.e. National Procedures (NP),
Mutual Recognition Procedures (MRP), Decentralised Procedures (DCP) and Centralised Procedures (CP))
within EU/EEA. For submissions within MRP and DCP, please also refer to the specific CMDh guidance CMDh
Best Practice Guide on the use of eCTD in the MRP/DCP’.
2.1.5 Exceptions
This guidance does not apply to the electronic submission of pre-marketing authorisation (MA) information
such as scientific advice, clinical trial applications, orphan drug designations, PIP submissions and related
submission correspondence as well as dossier content explicitly excluded from the commonly maintained
electronic dossier. These exceptions may be subject to change in the future. (Please, refer to the EMA
eSubmission website and to CMDh website on eSubmission for any future updates.)
2.2 Structure of Submissions
This document provides guidance on how to organise application information for electronic submission using
the eCTD specifications. Guidance on the detailed information to be included is described in the Common
Technical Document (CTD), and relevant ICH and EU Q&A documents.
The structure and organisation of an eCTD submission is defined by the following standards:
ICH M2 eCTD Specification
EU Module 1 Specification
Relevant ICH and EU Q&A and guidelines
Annex 1 contains links to the currently approved version of these documents and other useful references.
Page 9 of 56
Typically, an eCTD application will cover all dosage forms and strengths of a product. In the Centralised
Procedure, this will be equivalent to all dosage forms and strengths covered by an EMA application number
(e.g. EMEA/H/C/000123). In MRP/DCP, a single eCTD should preferably be used for the full procedure
covered by a procedure number (e.g. SE/H/0014/001-003). However, if an applicant decides not to apply for
all strengths and dosage forms in every member state in the procedure, the possibility of having one eCTD
application per strength/dosage form could be considered but is normally not recommended. Applicants should
carefully consider what an eCTD application should cover before submitting the first sequence, as the choice
could have implications for the workload for the entire lifespan of the product. For example, if the applicant
decides to have one eCTD per strength or dosage form, it is expected that each of these eCTD applications
will be maintained individually, such that submission of a single sequence that covers more than one strength
or dosage form will not be possible. In rare cases where a change is needed, please contact the
NCA/RMS/EMA concerned at an early planning stage.
Note that choosing separate eCTD lifecycles for each strength or form of a national (MRP/DCP/NP) product
will mean in practice that all submissions, including EU PSUR Single Assessment submissions, must be
provided for each eCTD separately in accordance with the chosen dossier structure (for details see Section
4.5).
Also note that a single eCTD cannot cover a product authorised/applied for within an MRP/DCP in some MSs
and within a NP in other MSs. Also, a single eCTD lifecycle cannot cover a product that is nationally authorised
in different MS. I.e, you can never mix an MRP/DCP and an NP product in the same eCTD application nor
different NP products.
2.3 Transitional Arrangements
The specifications mentioned in Section 2.2 above are likely subject to changes and are likely to affect both
eCTD building tools and the applicant’s internal business processes as well as the agencies review tools and
processes. Once a new eCTD specification and/or the related validation criteria has been approved, eCTD
building tools will need to be updated accordingly and specific transitional guidance will be provided on each
occasion. However, minor changes that do not change the Document Type Definition (DTD) of the eCTD
specification, but only the text may also be published and would then not affect any tools, but rather the
handling or business process of the eCTD lifecycle.
Please note that it should not be necessary to reformat and resubmit previously submitted applications to
reflect such changes.
2.4 Change to eCTD Format
eCTD is the mandatory format for all electronic submissions referred to in 2.1. If the product dossier was earlier
handled in paper or NeeS format, the next upcoming submission needs to be submitted in eCTD format. This
also includes submissions concerning other ongoing regulatory activities related to that eCTD application (e.g.
responses to questions to ongoing variations), in which case, it will obviously not be possible to use the related
sequence attribute (see section 2.9.5.) correctly since the start of the regulatory activity is not present as an
eCTD sequence to refer to and therefore the validation criterion 14 BP2 will not be met. This should be reflected
in the cover letter.
If the dossier has already been provided in NeeS format, the applicant should submit the new data in eCTD
format starting the lifecycle in accordance with eCTD specifications. The first submission in eCTD format will
normally be sequence 0000, even if sequential numbers were used for the NeeS format. For clarity, the cover
letter should always explicitly state that the submission involves a switch to eCTD format. As the documents
already exist in an electronic format, it would be preferable to first re-send the currently valid documents,
especially module 3, as a baseline eCTD dossier in sequence number 0000 and then the first new regulatory
activity as 0001. Please see Section 2.12 for further information on the content of baseline applications and
the acceptability of scanned documents.
Any historical sequences (e.g. sent to new CMSs within an RUP) should not be technically validated by the
agencies receiving them for the first time, for further details see the CMDh Best Practice Guide on the use of
eCTD in the MRP/DCP’. However, if there are problems with loading or reading the old” files, the applicant
should assist in solving the technical problems on the sequences to facilitate their use in the “newNCA , for
example due to mistakes in transmission or creating the submission or problems with the XML, which can be
resolved without affecting future lifecycle.
Page 10 of 56
In any case, a tracking table is essential to understand the sequencing of your eCTD submission and should
be included in all submissions in all procedure types (please refer to Section 3.2.3).
A baseline submission is recommended at the time of changing to eCTD to give the agencies access to all or
at least part of the previously submitted documentation within the eCTD lifecycle even if this is not mandatory
(see Section 2.12.).
2.5 General Submission Considerations
2.5.1 Document Granularity
Submissions are a collection of documents and each document should be provided as a separate file. The
detailed structure of the eCTD should conform to the ICH Granularity Document and EU M1 specification.
Careful consideration is needed when deciding the level of Module 3 granularity (please refer to Annex 3,
Section 3.1)
2.5.2 File Naming
The eCTD file naming conventions described in the ICH M2 eCTD Specification and EU Module 1 eCTD
Specification are highly recommended, as best practice. If an applicant wishes to submit multiple files in one
section, where only one highly recommended name is available, this can be achieved by using a suffix to the
filename, such as using the file name-var.pdf convention as described in the EU Module 1 eCTD Specification
(e.g. pharmaceutical-development-container.pdf). The variable part of the name must not contain “illegal
characters (e.g. %, /, <).
File names, including the extension, must not exceed 64 characters. Also, the folder names must not exceed
64 characters and the total file folder path length must not exceed 180 characters. Counting starts from the
first digit of the sequence number in the sequence number folder name.
For further guidance on file naming, please refer to the “File-Folder Structure & Nameswork sheet included
in the current validation criteria
2.5.3 Placement of Documents
Guidance on the placement of documents within the eCTD structure can be found in Notice to Applicants
Volume 2B and/or in the EMA post-authorisation guidance for centralised applications.
In the submission structure, leaves should typically be placed at the lowest level of the CTD structure, although
there are some exceptions to this guidance, for example, in 32p4-contr-excip, where the files excipients.pdf,
excipients-human-animal-var.pdf or novel-excipients-var.pdf can be placed alongside folders containing
details of other excipients. The lowest levels of the CTD structure (including node-extensions) must contain at
least one leaf, although this should normally be managed automatically by the eCTD building tool.
Every leaf must have a value for the ‘title’ attribute.
2.6 Correspondence
The eCTD is designed to ensure that users have a current view of the information submitted in the appropriate
place of the dossier at all times. Therefore, formal responses to questions should always be submitted in eCTD
format, as well as any correspondence that relates directly to the content of the dossier. However, there might
be some correspondence that are requested to take part outside the eCTD and if so, this is clearly stated in
other guidance documents (e.g. in the CMDh BPG on the use of eCTD in MRP and DCP at the CMDh
website).
Page 11 of 56
2.7 Paper Requirements
Some NCAs may still require paper copies of some documents in addition to the eCTD; refer to the CMDh
guidance Requirements on submissions for New Applications within MRP, DCP or National procedures
Requirements on submissions for Variations and Renewals within MRP and National proceduresfor further
details.
2.8 Hardware
NCAs and the EMA will not accept any hardware (laptops, desktops, external hard drives etc.) from applicants
in connection with the submission of information in electronic format. The electronic information should be
directly readable and usable on NCAs and EMA’s hardware and software.
2.9 General Technical eCTD Information
2.9.1 Identifier for Applications
To help enable archiving the sequence with the correct dossier (eCTD lifecycle), applicants must state a
unique identification of the dossier in the form of a UUID. The identifier must be defined with the first
sequence of a new dossier (or the first sequence using EU M1 version 3.0 or later), and it must be consistent
throughout the eCTD lifecycle. The identifier must not be changed except in certain scenarios, see
Section 2.11.3.
The UUID is a 32 digit (8+4+4+4+12) hexadecimal string, for example: “123e4567-e89b-12d3-a456-
426655440000”. When def ining a UUID the string should be decided at random. The string should contain no
information referring to any other metadata. This is to ensure consistency even if the relevant metadata should
change. The chance of two different dossiers having the same UUID is next to none if the UUIDs are truly
defined at random.
2.9.2 File Formats
According to the EU eCTD validation criteria only pdf documents can be provided within the eCTD sequences.
In general terms most documents included in electronic submissions should be provided in PDF format (see
next section on the use of PDF file versions). Files that might be requested by NCAs or the EMA in MS Word
format should not be included in the eCTD structure (refer to Section 2.9.10) but be provided in the
workingdocuments folder.
Further detailed guidance on file formats can be found in the ICH eCTD specification document and EU Module
1 specification.
2.9.3 Portable Document Format (PDF)
Portable Document Format (PDF) is an ISO standard (ISO 19005-1:2005 Document management Electronic
document file format for long-term preservation Part 1: Use of PDF 1.4 (PDF/A-1) and ISO 32000-1:2008
Document management Portable document format Part 1: PDF 1.7). Although created by Adobe Systems
Incorporated, there are several alternative suppliers of PDF software. Applicants need to check that their PDF
documents meet the following key requirements:
PDF version 1.4, 1.5, 1.6 or 1.7 should normally be used, except where there is an EU or agency specific
requirement for another version.
PDF/A format is recommended where possible.
PDF 1.3 or earlier versions are not acceptable for technical reasons. No exceptions will be made. For
example, if a literature reference is received in PDF 1.3 or earlier, then the applicant must convert it to
PDF 1.4, 1.5, 1.6 or 1.7, either electronically or by scanning.
Applicants are requested to ensure that all submissions contain the maximum amount of text searchable
content to facilitate the assessment of the eCTD content. PDF documents should therefore, wherever
possible, be produced from a text source such as MS Word. If scanning is unavoidable, it should normally
include OCR. However, there are some documents where the scanned document would not be expected
to include OCR, i.e.:
- Any GMP certificate
- Any certificate of analysis
- Any manufacturer’s licences
- Any certificate of suitability
- Any Manufacturing Authorisation
Page 12 of 56
- Any document written in a foreign language where a translation is provided in English (however,
the translation should be text searchable)
- Any literature references sourced from journals, periodicals and books (except when these are
used in a bibliographic application to support the main claims of the application).
- The blank CRF in a Clinical Study Report
- Patient data listings (when supplied)
- CRFs (when supplied)
- Any page with a signature that does not contain other information key to the understanding of
the submission (However, applicants should consider providing signatures on pages separated
from key text pages in reports, overviews, etc.)
Additionally, the following requirements should be taken into consideration:
Different requirements apply in the EU to NCAs and the EMA for signatures on application forms and
cover letters. For details refer to Section 2.10.4. Make sure that scanned cover letters are text
searchable.
The fonts used in the PDF should be embedded in the PDF where possible.
Rendition to PDF should preferably create documents which are ”tagged.
Use 'Fast Web View' where possible to ensure optimum performance of the review system.
PDFs should not be included in the eCTD as a PDF Portfolio.
.
Additional details on PDF, including those relating to the good presentation of tables, can be found in the ICH
eCTD Specification, Appendix 7. Refer also to the ICH M2 recommendations.
2.9.4 Sequence Numbers
Sequence numbers are used to differentiate between different submissions of the same application over the
lifecycle of the product. The review tools being used by most NCAs and the EMA can handle sequences
submitted out of numerical order, i.e. 0003 submitted after 0004. This can occur when the preparation of a
sequence is delayed. However, it is recommended that sequence numbers follow the order of submission of
the sequences, as sometimes a higher sequence is technically related to the previous not yet submitted
sequence which will result in technical invalidation. A Sequence Tracking Table should always be included in
section 1.0 in every submission for all procedures. For details see Section 3.2.3.2.
The initial eCTD lifecycle submission should normally have the sequence number of 0000, even if sequential
numbers were already used for a NeeS format of the same product. If applicants consider that there are good
reasons to use another number, they should explain this in the cover letter.
When additional information is submitted in response to questions or when information in a previously
submitted sequence is modified in any way, the sequence number of the submission will advance accordingly,
e.g. 0001, 0002, etc. Only in the case of a technically invalid submission, at request from or agreement with
the EMA (CP) or an NCA (MRP/DCP/NP), a sequence can be replaced with another using the same number
(e.g. the initial sequence “0000 will be replaced by another “0000”). The new sequence should be sent to all
concerned authorities. No new documents may be included in these cases, but only technical problems should
be fixed. The reason for resending the same sequence must be clearly stated in a comment in the delivery file
(CESP, working documents or separate note in case of CD/DVD submissions). For submissions to the EMA it
is mandatory to use the eSubmission Gateway / Web Client and no additional comment is required. If the
eCTD needs to be updated due to content/regulatory validation, any revised content should be provided with
a new sequence number and the changes clarified in the cover letter.
2.9.5 Related Sequence
All submissions need to contain a value for related sequence”. If the submission unit type is ‘initial’ or reformat'
then the related-sequence attribute must have a value equal to the current sequence.
If the submission unit type is not ‘initial’ or ‘reformat' then the entry for related sequence should be populated
with the number of the sequence that started the regulatory activity.
Table 1 : Example of a PSUSA
Sequence
number
Submission Description
Related
Sequence
Submission
Unit
0008
PSUR single assessment
procedure
0008
initial
Page 13 of 56
0009
Validation update
0008
validation-
response
0010
Comments on Assessment
Report
0008
response
Table 2 : Example of a Referral for CAPs
Sequence
number
Submission Description
Related
Sequence
Submission
Unit
0008
Responses to LoQ
none
initial
0009
Comments on Assessment
Report
0008
validation-
response
0010
Responses to LoOI
0008
response
Table 3 : Example of a Referral for NAPs
Sequence
number
Submission Description
Related
Sequence
Submission
Unit
0008
Responses to LoQ
none
initial
0009
Comments on Assessment
Report
0008
validation-
response
0010
Responses to LoOI
0008
response
It is expected that there is just one Related Sequence, but there are occasions where more than one Related
Sequence should be provided as for example:
1) When there are two PAM related sequences (sequence 0005 and sequence 0006) and a single
response (sequence 0007) is produced that relates to both PAM related sequences.
2) When there are two parallel variations (sequence 0002 and sequence 0003) and there is a
sequence (0004) that brings the label up to date by including the changes made in both variations.
On these occasions multiple related sequences are used, but if a subsequent sequence relates to only one of
the original regulatory activities, then only the related sequence for that particular regulatory activity should be
used.
If the related sequences refer to both a single and grouped variation, the metadata should state ‘groupedas
being the highest level of regulatory activity.
Further examples are provided in the EU eCTD M1 Specification document.
2.9.6 Leaf Lifecycle Operation Attributes
The leaf lifecycle operation attributes, as stated in the eCTD Specifications, are ‘new’, append’, ‘replace and
‘delete’. However, in the EU, it is recommended that applicants avoid the use of ‘append’ due to the potential
for increased lifecycle complexity.
Lifecycle operations where the leaf targeted by the modified file is in a different CTD section are not allowed.
This applies across all the modules of the CTD and is not specific to either the regional or ICH Modules.
Where elements are repeatable, both the element itself and the attributes that define a different position in the
table of contents must be identical when modifying a leaf element in a previous sequence. Where node
extensions are allowed, the node extension title element should be identical when modifying a leaf element in
a previous sequence. However, it is acceptable occasionally if inconsistencies have been introduced in the
past. In those cases, it is recommended to use the most recent version of the title attribute.
Page 14 of 56
Table 4 : Repeatable Elements and Attributes that Define Different Sections
Element
Attributes also identifying a section
Module 1
m1-0-cover
country
m1-2-form
country
m1-3-1-spc-label-pl
country
xml:lang
type
m1-3-2-mockup
country
m1-3-3-specimen
country
m1-3-4-consultation
country
m1-3-5-approved
country
m1-responses
country
m1-additional-data
country
Module 2
m2-3-s-drug-substance
substance
manufacturer
m2-3-p-drug-product
product-name
dosageform
manufacturer
m2-7-3-summary-of-clinical-efficacy
indication
Module 3
m3-2-s-drug-substance
substance
manufacturer
m3-2-p-drug-product
product-name
dosageform
manufacturer
Module 5
m5-3-5-reports-of-efficacy-and-safety-studies
indication
The only exception to this is the change in agency name at the EMA; leaves with the specific country
attribute ‘ema’ or ‘emea should be considered equivalent and lifecycle must be allowed between them.
Note, in the eCTD XML, sections, leaves and node extensions may have other attributes, such as xml:lang,
font-library, version, keywords, ID etc. These attributes, if supplied, do not result in a new logical section in
the eCTD table of contents and therefore lifecycle between leaves where these attributes are not identical is
allowed; only the attributes in the table above define different eCTD sections.
Examples:
Pass/Fail
A leaf to be submitted in m4-2-2-5 in Sequence 0012 cannot replace/delete a leaf submitted in m4-
2-2-2 of Sequence 0010.
A leaf in m1-responses cannot modify content in m1-0-cover (different section)
A leaf in m3-2-s-drug-substance [manufacturer: abcd] [substance: xyz] cannot modify content in m3-
2-s-drug-substance [manufacturer: other] [substance: xyz], or any section other than the specific
manufacturer ‘abcdand substance ‘xyzsection.
A leaf in m1-0-cover with the specific attribute dk cannot modify a leaf in m1-0-cover with a specific
attribute of anything other than dk’.
A leaf in m1-3-pi with the specific attributes <pi-doc xml:lang="en" type="combined" country="ema">
cannot modify a leaf with different attributes, such as <pi-doc xml:lang="fr" type="other"
country="ema">.
Best Practice Criteria
A leaf in a node extension should only be modified by a leaf in the same equivalent node extension
in a subsequent sequence. For example, a leaf in a node extension in m5-3-5-1 of sequence 0000
with a <title> attribute ‘Study 1234should not be modified by a leaf in a different node extension with
a <title> attribute ‘Study 1234 update’ in sequence 0001 the append/replace/delete leaf ideally
needs to be in an identical node extension in 0001 (‘Study 1234in the same location, m5-3-5-1).
Page 15 of 56
If the applicant places content in the wrong CTD section and needs to correct this (either upon request from
the agency receiving the eCTD or because they wish to correct the mistake) then the way to do this is to create
two leaf elements in a subsequent sequence. The first leaf will use the “delete“ leaf operation to remove from
view the incorrectly placed content. The second leaf will usually use the “newleaf operation to locate the
content in the correct CTD section. The file does not need to be resubmitted, the “new leaf can use the
xlink:href attribute to point to the originally submitted content in the earlier sequence.
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.
Note: Lifecycle operations across eCTD applications are not allowed.
2.9.7 Bookmarks and Hypertext Links
Navigation through an electronic submission is greatly enhanced by the appropriate use of bookmarks and
hypertext links. ICH Q&A number 53 states, It is expected that any document that has a Table of Contents
(TOC) will have bookmarks (see the eCTD specification for details). Documents without TOCs should have
bookmarks included where it aids in the navigation around the document content. For example, a 4 pages long
document that is summarising findings could require bookmarks to aid navigation. However, a 300 pages long
file containing a single data listing might not require bookmarks as there is no further internal structure. Please
consult regional guidance documents for further details.
In general terms, bookmarks and hyperlinks should be used to aid navigation. The overuse of hyperlinks may
confuse rather than help assessors and may cause problems later in lifecycle management. However,
hyperlinks back to previously submitted documents are welcome if pointing to the correct location.
Additional details on creating bookmarks and hypertext links in PDF documents can be found in the ICH
eCTD Specification, Appendix 7.
With the current version of the eCTD specification, it is not possible to cross refer from one eCTD application
to another.
2.9.8 Node Extensions
Node extensions may be used where additional navigation in the XML backbone is required. The primary place
where they are used is in Module 5 where a node extension for each study is useful to group together the
multiple leaves that make up the study and its modular appendices, in a study specific folder. Also, it could be
useful to differentiate reports associated with a different dosing regimen for the same indication. For Module 4
when submitting reports consisting of multiple pdf files, node extensions can also be useful with an associated
subfolder. In Module 1, node extensions should be included to differentiate the responses at different stages
of the lifecycle. For further details on responses, see Section 3.2.6. Currently, additional folders in m1-
responses are not allowed and therefore, the use of an additional folder in combination with a node extension
is not possible.
Please note, 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.
When node-extensions are used the ‘title’ attribute in the XML backbone must have a value.
2.9.9 Extensible Mark-up Language (XML)
XML is the format for the backbone files for the eCTD. Details on XML can be found in the ICH eCTD
Specification Document, Appendix 7. Initiatives on the use of XML structured information are supported by
NCAs and the EMA for electronic application forms (eAFs). Please refer to EMA eSubmission website for
further details.
2.9.10 Other File Formats
Other file formats such as MS Word formats may be required by some NCAs or the EMA in addition to the
PDF requirement of the eCTD, especially for the provision of product information documents or the Module 2
documents. Please refer to the CMDh website for further details on NCAs requirements.
Page 16 of 56
The files referred to above should not be added as leaf elements within the eCTD structure. When submitted
with an eCTD, they should always be provided in a separate folder called xxxx-workingdocumentson the
same submission zip package or on the same CD/DVD containing the eCTD, where the number (xxxx)
matches the number of the eCTD sequence being submitted.
For PMF certification submissions the ePMF should be provided within the working documents folder. The
folder should be called “xxxx-workingdocuments” as for all other documents. For more information please refer
to the guidance on PMF eCTD Guidance document.
If working documents for more than one NCA are submitted on the same submission, sub folders with the
country code should be used.
Figure 1 : Sample of folder structure
For information on translations being provided outside the eCTD, refer to Section 3.2.5
If, at any stage in a procedure, an email or EudraLink message is used to send information, this does not
change the format requirement. The subject line of the message should always include as a minimum the
product name and procedure number for identification purposes.
The EMA does not accept submissions sent via email or EudraLink.
2.9.11 Technical Validation of eCTD Submissions
The technical validation of an eCTD is a separate activity compared to the content validation of a submission
and takes place irrespective of the type of the submission. NCAs and the EMA have adopted a common set
of technical validation criteria against which all eCTDs can be checked using eCTD review and validation tools.
It is strongly recommended that all sequences are checked and found technically valid according to the
published validation criteria.
Two categories of validation rules apply: “Pass/Fail”, and Best Practice”:
Pass/Fail Criteria
This is a set of technical validation criteria that can either be passed or failed. eCTDs that fail to meet one
or more of these criteria will be rejected and a resubmission of the same sequence number will be
required. All Centralised Procedure (CP) eCTD submissions via the eSubmission Gateway / Web Client
to the EMA are automatically run through a full technical eCTD validation and an automated ‘successor
‘failureacknowledgement is sent to the applicant/MAH. eCTD submissions for PSURs authorised via
MRP/DCP/NP are checked using a ‘tolerant’ eCTD validation checking only the structure of the eCTD
submission. This means that even if your submission has been successfully submitted via the
eSubmission Gateway/Web Client, a technical validation issue can be found by an NCA at a later stage
but will be coordinated by the EMA in that case.
Best Practice Criteria
These are validation criteria that are considered good practice to facilitate the review of an eCTD.
The applicant should make every effort to address these areas before the eCTD is submitted. eCTDs that
fail to meet one or more of these criteria will still be accepted by the receiving agency/agencies during
technical validation and it is possible that agencies may not even check these criteria during technical
validation.
Page 17 of 56
Note: These criteria cannot test the correctness of the metadata. Therefore, applicants need to make
sure that all metadata are filled in correctly.
Errors found during the content validation e.g. mistakes in an application form to be corrected, should be
resolved through the submission of a new eCTD sequence using the next sequence number. These errors,
which are content errors, must never be resolved by resubmitting an existing sequence by re-using the same
sequence number.
An exception to this would be if the envelope is incorrect and it is requested by an agency to be corrected and
resubmitted with the same sequence number. In such scenarios, the updated sequence (same sequence
number) should only be submitted to the requesting agency. Nothing else should be changed in the sequence
and it should be clear from the delivery information that this is a re-submission of the same sequence number
with just an envelope correction and that the former submitted sequence number should be exchanged to this
update (i.e. as the handling of a technically invalid sequence).
If historical sequences that have already been submitted in another MS in the EU are supplied to a new NCA,
the receiving NCA should not technically validate these sequences, as they have already been accepted when
originally submitted. This could be the case where, for example, in repeat use, switching from parallel national
to comprehensive model, supply of eCTD sequences to an NCA where this same submission had been
formerly submitted in NeeS or paper format but in eCTD format to other NCAs. However, if there are problems
with loading or reading the newly submitted files, the applicant should assist in solving the technical problems
on the sequences to facilitate their use in the new NCA.
2.10 Other Technical Information
2.10.1 Protection against Malware
The applicant is responsible for checking the submission for malware such as viruses. Checking should be
performed with an up-to-date virus checker. After receipt at NCAs and the EMA, a similar internal virus check
will be performed. If a virus is detected it will constitute grounds for technical invalidation of the submission.
2.10.2 Security Settings
Submission or file level security is not permitted. If one-time security settings or password protection of
electronic submissions are used this could constitute grounds for the rejection of the submission.
There must be no security setting to open any individual file. This includes passwords, certificate security,
adobe policy server settings, etc.
Furthermore, there must be no security settings applied to any individual file, except for files in Modules 1.0,
1.2, 3.3, 4.3 and 5.4. This means that security settings in for example Adobe Acrobat, all "restrictions" should
normally be "allowed" when viewing the Document Preferences > Security settings. If for some reasons this is
not possible for some documents, e.g. for digitally signed documents, as a minimum printing and content
copying need to be allowed.
2.10.3 Signatures
Electronic signatures are regulated in EU by Regulation (EU) No 910/2014 of the European Parliament and of
the council of 23 July 2014 on electronic identification and trust services for electronic transactions in the
internal market and repealing Directive 1999/93/EC. For applications of Marketing Authorisations including
post-authorisation submissions, most NCAs and EMA do not require wet or digitally signed cover letters or
application forms if submitted through a portal (e.g. CESP and EMA Gateway) with logon credentials. However,
some NCAs still require additional signatures and might accept wet signatures, scanned signatures and/or
electronic signatures as specified in the CMDh document Requirements on submissions for New Applications
within MRP, DCP or National procedures and Requirements on submissions for Variations and Renewals
within MRP and National procedures.
For EMA submissions, in general qualified and advanced electronic signatures as per the European
Commission eIDAS regulation (Regulation (EU) No 910/2014) are accepted.
Page 18 of 56
2.11 Technical Baseline Applications
A baseline submission is a compiled submission of the current status of the dossier, i.e. resubmission of
currently valid documents that have already been provided to an agency but in another format. The sections
provided to make up a baseline can be defined by the applicant, but any omissions should not render the
submitted content misleading. A baseline would typically consist of the Module 3 documents that tend to
change over time during the lifecycle of the product.
It is highly recommended, but not mandatory, to use a baseline as a start of an eCTD when changing from
paper or NeeS and to provide as much content as possible in the eCTD. The baseline would preferably consist
of high-quality electronic source documents, but good quality scanned images would also be acceptable in
these cases, preferably with Optical Character Recognition (OCR) to facilitate text searching.
It should be clearly stated in the cover letter of the “baseline eCTD sequence” that the content of the previously
submitted dossier has not been changed, only the format. There is no need for the NCAs or EMA to assess
baseline submissions and hyperlinks between documents are therefore not needed. The submission type
reformat should be used in the envelope for the baseline sequence.
2.11.1 Baselines Starting as Sequence 0000
The baseline should normally be submitted as sequence 0000 but could in some justified situations also be
submitted at a later stage (see Section 2.12.2 below). The baseline should always be a separate submission
and should never include new applications. The first new regulatory activity, e.g. the next variation, in eCTD
format should then be submitted as sequence 0001, see table below.
Table 5 : Example for starting an eCTD with a baseline sequence
Sequence
number
Submission Description
Submission Type
Related
Sequence
Submission
Unit
0000
Baseline of Module 3
none
0000
reformat
0001
Variation for new indication of
COPD
var-type2
0001
initial
0002
Response to Questions
var-type2
0001
response
0003
Variation to shelf life
var-type1b
0003
initial
0004
Extension for 8mg tablet
extension
0004
initial
2.11.2 Baselines Starting Later in Lifecycle
A baseline can also be submitted later in the lifecycle. If documents have already been provided in previous
submissions in the sections now covered by the baseline, these should not be re-submitted. Instead, the
remaining incomplete sections should be filled up with earlier dossier content (paper or NeeS), now provided
in eCTD format for the first time.
It is possible to use multiple sequences to submit a baseline, e.g. one sequence for the baseline for Modules
4 and 5 followed later by one sequence for the baseline for Module 3. The submission type reformat should
be used in each case. An example is given below.
Table 6 : Example for starting an eCTD with regulatory activity sequence
Sequence
number
Submission Description
Submission Type
Related
Sequence
Submission
Unit
0000
Variation concerning Modules 4
& 5
var-type2
0000
initial
0001
Variation for new indication of
COPD
var-type2
0001
initial
0002
Response to Questions
var-type2
0000
response
0003
Baseline of Module 3
none
0003
reformat
0004
Extension for 8mg tablet
extension
0004
initial
Page 19 of 56
In cases where a product, nationally approved in more than one EU country, becomes an MRP product through
a referral, it is quite likely that the eCTD dossiers submitted nationally are incompatible and thus cannot be
used to continue the MRP dossier. The dossier might then have to start anew, from sequence 0000 and be
compiled in line with the CMDh Best Practice Guide on the use of eCTD in the MRP/DCP. In such cases, a
baseline submission might be justified in order to give all the CMSs access to the previously submitted
documentation. For details on how to transfer existing eCTD lifecycle from one procedure to another (e.g. at
the end of an Article 30), see Section 2.12.3 below.
For eCTD dossiers created with old tools and/or in accordance with technical criteria which are now outdated,
a baseline can be submitted in order to clean up” the dossier f rom any technical issues that would cause
problems. However, the applicant should first ensure that there are no other ways of rectifying these technical
issues so that this option is not used unless absolutely necessary.
The technical baseline application can also be used by applicants to switch from one eCTD sequence per
strength to one eCTD sequence covering multiple strengths (see Section 2.12.3 below). The switch from one
approach to another should normally only be allowed once during the lifecycle and must be agreed by the
relevant authority.
2.11.3 Re-Baselining a Broken eCTD Lifecycle
One of the principles of eCTD is that with the use of the operation attributes, it is possible to manage the
lifecycle of a product and generate a view of the “current dossier”.
However, in certain cases, the lifecycle at the side of the applicant may be broken.
This situation can occur in cases such as:
An MA is transferred to another MAH who is unable to import any existing eCTD sequences into its
building tool
An applicant switches to a new publishing tool and is unable to import their submitted sequences
An applicant is working with a lifecycle where previously submitted sequences are actually technically
invalid, but were not technically validated at the time by the receiving agency
The problem with all of these situations is that the applicant cannot continue with the existing lifecycle of the
product. Any subsequent submission (sequence) for the product where previously submitted content is
changed and needs to be referred to (using the operation attributes replace, or delete) cannot be built in the
tool, or, if built, would be invalid. This is because it is impossible to create the link back to the original submitted
documentation, because it no longer resides in the eCTD building tool.
In these first three examples, the preferred situation would be that the previously submitted sequences are
imported in the new tool and the lifecycle of the product will continue. However, this might not be possible, due
to technical issues in uploading previous sequences into a different tool, or particularly when the previous
sequences were invalid. If the lifecycle re-starts a new UUID for the application is required.
In addition, in exceptional cases, there may be a benefit to both the applicant and to the agency if the current
lifecycle is archived in some way and re-started. For example:
An applicant has chosen in the past to submit more eCTD applications than needed under current
guidelines, for example, one for each strength of a product
An applicant has used the parallel national model in MRP/DCP and needs to switch to the
comprehensive model
At the end of an Article 30 procedure, the applicant is switching from national eCTD in one or more
MS to a comprehensive eCTD for the new MRP
To ensure that the lifecycle of the product is correctly maintained going forward, it is proposed that in these
exceptional circumstances, and with prior agreement between the MA holder and the receiving NCA
(national procedures), the RMS (MRP/DCP) or EMA (centralised procedures), applicants are allowed to
resubmit the current registered dossier as a baseline consisting of all valid documents as seen in “current
view, leaving the existing sequences in place, but essentially resubmitting the content in a new eCTD
application. Also, in these cases a new UUID for the application is required. It is strongly recommended to
finalize ongoing regulatory activities before submitting the baseline.
Page 20 of 56
In the cover letter the applicant must provide details of why the lifecycle is broken and state that a baseline
eCTD sequence is being submitted in order to restart the lifecycle.
A new UUID needs to be assigned to the application.
The submission type would be “none”
The submission unit type would be “reformat”.
The operation attributes of the leaves would be all “new”.
The sequence number of the submission would normally be restarted at 0000 and not continued from
the previous lifecycle, since continuation of existing numbering could lead to complex lifecycle issues.
However, when compiling (merging) several eCTDs built per strength and/or dosage form of a product into
only one combined eCTD for that product, normally one of the existing eCTD lifecycles would be kept and be
completed with the missing documents from the current view of the other strengths and/or dosage form eCTDs
to give the complete current dossier. In those cases, the assigned UUID of the maintained eCTD (the chosen
strength or dosage form built upon) will also serve as UUID for the future (merged) lifecycle. The strategy for
merging of eCTDs should be agreed with the relevant authorities in advance.
Re-baselining where the previously submitted sequences cannot be used in the new
lifecycle and must be archived
For the agency, the former submitted sequences have to be handled as “history”, and the new set of sequences
would need another identifier to be set by the authority to differentiate them from this previous lifecycle. The
lifecycle will begin from scratch again from the time of the baseline submission with a new UUID in each
sequence built with EU eCTD m1 v3.0 or later. In an MRP, there is no need to mention the previous (archived)
sequences in the tracking table, so the new tracking table should only refer to the re-established lifecycle.
Scenario 1 previously submitted sequences archived, new eCTD lifecycle started
Applicant X has submitted sequences:
0000 Initial application
0001 Validation update
0002 Day xx response
0003 Day yy response
0004 Variation 001
** Problem occurs in continuing lifecycle, see examples below
0005 0000 - Next submission
0005 is not submitted. Instead, 0000 - 0004 are archived, and a new eCTD is started at 0000.
Examples for this scenario:
** MA is transferred, previous sequences 0000-0004 cannot be imported into a tool by the new holder.
** Applicant changes their eCTD Building tool, previous sequences will not import into the new tool
** Previous sequences 0000-0004 were technically invalid according to the specification at the time, but were
accepted by the agency because eCTD checking was not yet established
** Sequences 0000-0004 were “not mutual” (parallel national) not all countries in the procedure may have
received all of them with the same sequence number
Re-baselining where the previously submitted sequences in at least one MS can be
used as existing lifecycle
In the case that previous lifecycle can be continued, but submitted in additional member states, then there
would be no need to change the identifier or UUID. In an MRP, the tracking table should indicate which
member states originally had the sequences, and which member states are now getting them as lifecycle
history.
Scenario 2 previously submitted sequences valid, lifecycle continued
Applicant X has submitted sequences:
0000 Initial application
0001 Validation update
0002 Day xx response
0003 Day yy response
Page 21 of 56
0004 Variation 001
** Problem occurs in continuing lifecycle without making changes to the scope of the eCTD application,
examples below
0005 = Next submission
The original sequences are maintained, but a new eCTD lifecycle is started at 0005, where more countries
receive the lifecycle.
Examples for this scenario:
** Sequences 0000-0004 were “not mutual” (parallel national) all countries in the procedure have received
all of the sequences as individual national sequences with the same sequence number
** Earlier sequences 0000-0004 referred to only one strength or dosage form, but the new lifecycle will cover
more multiple strengths/forms. Note there is no need to alter the metadata from the previously submitted
sequences, the additional strengths / dosage forms can be added in subsequent sequences.
** Earlier sequences 0000-0004 were used in national procedure prior to an Article 30 procedure, but can be
re-purposed for the new MRP
2.12 Procedure for Sending Electronic Information
2.12.1 Portals/Gateways
Common European Submission Portal - CESP
Submission via CESP, is mandatory for MRP/DCP. For details on NCA requirements on submissions, please
refer to the Requirements on submissions for New Applications within MRP, DCP or National procedures at
the CMDh website. Any required paper documentation should be dispatched in parallel at the same time as
the CESP submission.
When using CESP, the delivery file XML details should be based on the eCTD envelope metadata.
For worksharing procedure or grouped variation covering multiple MAs submitted via CESP, all eCTD
submissions for the products concerned should be provided in separate folders within one submitted zip file.
If there are MAs not approved in all countries concerned by the procedure, this could be clarified in the CESP
delivery file (in Comments).
If the procedure is MRP, tick the RMS for the Grouping/Worksharing procedure. Tick the dummy RMS ZZif
you intend to submit something only to one or more CMS agency (e.g. when a correction or a nationally
required document is sent to a CMS only).
If, for whatever reason, multiple submissions are required for the same procedure (e.g. for duplicate dossiers
having different MAHs), this should be clarified in the same way as above, in each CESP delivery file.
EMA eSubmission Gateway
Submission via the EMA Gateway is mandatory for Centralised Procedure and for a number of other EMA
coordinated procedures containing Nationally Authorised Products, for example, but not limited to EMA led
worksharing variations, Signal Detection (EPITT) procedures, PASS107, and EU PSUR Single Assessment
Procedure. For such procedures, the submissions for NAPs should only be made to the EMA via eSubmission
Gateway (see the eSubmission Gateway website for details) and there should be no duplicate submissions
sent directly to the NCAs. Information identifying the submission should be included in the XML delivery file.
All PSUR submissions within all procedure types, including non-EU single assessment PSURs for Member
States, should be submitted to the PSUR Repository via the EMA eSubmission Gateway. Please refer to the
eSubmission PSUR Repository website.
Referral procedures, other than CMDh referrals Dir 2001/83/EC art 29(1) and Reg 1234/2008 art 13, should
also be submitted via the EMA Submission Gateway with details in the delivery file.
Page 22 of 56
National Gateways
There are also national portals in some countries, mandatory or optional, see the Requirements on
submissions for New Applications within MRP, DCP or National procedures and Requirements on
submissions for Variations and Renewals within MRP and National procedures and individual NCA websites
for further details.
2.12.2 CD / DVD
By exception, CD/DVD submissions might still be accepted by some national competent authorities for pure
National Medicinal Products. Refer to the documents Requirements on submissions for New Applications
within MRP, DCP or National procedures and Requirements on submissions for Variations and Renewals
within MRP and National procedures’..
Zipped files should not be used when sending CDs or DVDs.
Each CD/DVD submitted should include the applicant’s name, the product name, the procedure
number (if known), the sequence number, the number of the media unit (e.g. 1(5), 2(5) etc.) and the
submission type (as stated in the envelope) clearly printed on the media.
The details of the number of copies of CD/DVD to be submitted (if accepted at all) are published in the
documents New Applications within MRP and National proceduresand Requirements on submissions for
Variations and Renewals within MRP and National procedures at the CMDh website.
The EMA does not accept CDs / DVDs or any other external media.
2.12.4 EudraLink / e-Mail (where applicable)
EudraLink and e-mail should not be used for eCTD submissions.
However, it may be used as a submission channel to share eCTD sequences with prior agreement from or at
the request of the receiving agency. Sequences shared via Eudralink/e-mail should in these specific cases
subsequent be submitted via the relevant formal process, e.g. CESP.
If EudraLink is used for sending an eCTD sequence, the entire sequence has to be provided as a zip file (.zip).
Please also note there is a size limit, refer to the EudraLink User Guide for further details.
When using EudraLink, it is strongly recommended that the expiry date is set to the maximum (90 days) to
ensure that it can be opened during the process at the receiving authority.
Page 23 of 56
3. Module Specific Information
3.1 General Information
The following subfolders should be used to organise the files for each module in a submission: m1, m2, m3,
m4, and m5 following the principles set out for the CTD in Notice to Applicants, Volume 2B. There is also a
subfolder util to organise eCTD technical files in the submission. If a module is not appropriate for a particular
submission it should be omitted. Empty subfolders should not be included.
Each document should be provided as an individual PDF file, except those specifically requested in a different
format.
A single eCTD application can cover multiple drug substances (e.g. in case of fixed combination products),
multiple manufacturing sites, multiple medicinal products based on one invented name (different dosage forms
or strengths). Careful planning is required to ensure that the dossier can be expanded as the product range is
expanded or reduced by the submission of later sequences. Please see Annex 3 for further details.
3.2 Module 1 eCTD Envelope, Administrative Information and
Prescribing Information Folder
3.2.1 General Considerations
In the case of country specific files or folders the country code should appear in the file and folder name as
the differentiating marking.
Not Applicable Module 1 documents should not be included in the eCTD. However, when a justification for
the absence of a certain document in Module 1 is required, such justification should be provided in its
corresponding section in the eCTD structure. In any case, all section titles should always appear in the
Module 1 eCTD backbone, displayed by the style sheet, even if these sections are not populated.
3.2.2 Creation and Management of Envelope Information
The eCTD envelope should be used to describe the eCTD sequence:
Country In the centralised procedure, there should only be one envelope, and this should
have the entry ‘ema’. For MRP/DCP, each country in the procedure needs to have
a separate envelope entry. Common must not be used as a country identifier in
the envelope. In case of submissions to EDQM the envelope needs to display the
entry edqm.
Identifier A UUID as specified by ISO/IEC 11578:1996 and ITU-T Rec X.667 | ISO/IEC 9834-
8:2005. The same UUID will be used for all sequences of an eCTD application.
Submission Type This value represents the regulatory activity which will be started and the type of
material sent to the agency. The entry is chosen from a picklist based on the EMA
SPOR RMS on Applicant Submission Type, see EU M1 Specification for further
details.
Submission Unit Submission unit type describes the content at a lower level (a “sub-activity”) which
is submitted in relation to a defined regulatory activity. The entry is chosen from a
pick list, see EU M1 Specification for further details.
Submission Mode This element should only contain a value in variation, PSUSA or line extension
regulatory activities and must be included in every sequence of that activity. The
value can be set to ‘single’, ‘groupingor ‘worksharing’.
Submission Number This number represents the high-level procedure number related to the regulatory
activity in case of worksharing submissions and for submissions of grouped Type
IA variations and PSUSA if multiple products are concerned. Samples are
provided in the EU M1 Specification. Note: not required in case only one product
is concerned.
If submission mode is set to either 'grouping' or 'worksharing' there should be a
Submission Number (Number element in the DTD). This Number element should
be identical with the variation procedure number included in a Variation eAF.
Procedure tracking
number Always to be completed. In case of using the submission number, the Procedure
Tracking Number (PTN) refers to the product involved in the worksharing, grouped
Page 24 of 56
or PSUSA procedure. Any value used by an agency or applicant to track the
submission, in any procedure, in relation to a particular product, e.g.
EMEA/H/C/000123 for a CP submission (after allocation of the specified procedure
number by EMA) and DE/H/0126/001/MR for an MRP submission (depending from
the national business rules which might allocate procedure tracking numbers at
receiving time point only. In those cases the field remains empty until submission).
If the PTN is not known in advance, it is recommended to use the product number
instead. For a full list of expected number types per agency refer to EU M1
Specification. Note: When a submission is not relevant for all products covered by
the dossier or new products are added to the dossier, please clearly state this in
the cover letter.
This number should be congruent with the variation procedure number included in
a Variation eAF or with the procedure number included in a MAA eAF or in a
Renewal eAF.
Applicant Entries for ‘applicantshould be consistent for all eCTDs from any single applicant
(legal entity), as they define where eCTDs are stored in internal systems.
Consistency of spelling is also relevant over time to allocate the eCTD correctly.
In case of ‘worksharing’ procedures, only the name of the applicant designated for
the worksharing submission should be used.
Agency Code Select from picklist in the most recent EU M1 Specification. Ensure that Country
and Agency name is consistent.
Procedure type The entry is chosen from a picklist, see EU M1 Specification for further details.
Invented-name The trade name/invented name for the medicinal product covered by the
application. If the eCTD covers multiple strengths or dosage forms, this entry does
not need to describe the complete name, a simple entry, for example, ‘Wonderdrug
will suffice.
INN The International non-Proprietary name for the drug substance.
Sequence The sequence number here must match the sequence number in the folder
structure, on the Cover letter and on the XML delivery file for CESP submissions,
the file naming conventions for eSubmission Gateway/Web Client submissions and
the XML delivery file for PSUR submissions via the eSubmission Gateway/Web
Client. If the submission is provided on CD/DVD this should match the label of the
CD/DVD.
Related-sequence For a description and example of how to use the ‘related sequence’ entry, see
Section 2.9.4 and the EU M1 Specification.
Submission-description This element is used to describe this particular eCTD sequence.
3.2.3 Module 1.0 Containing Cover Letter and Tracking Table
3.2.3.1 Cover Letter
The cover letter should always be submitted with the document operation attribute “new”. As eCTD viewing
tools will display all "new" leaf elements in a current or cumulative view, it is recommended that additional
descriptive text is included in the leaf title to help identify specific cover letters. This will help identify each
cover letter leaf and the submission it is in, rather than having the cover letters named the same in each
sequence. Some examples for the leaf titles could be:
Cover Letter for Sequence 0000
Cover Letter for Germany for Sequence 0000
Cover Letter for France for Type II Variation 028 (0042)
Please see also the CMDh website for requirements of signed paper copies of the cover letter and application
form to each NCA. Please note, when resubmitting content due to technical validation issues or sequences
missing at NCA side, a note (a comment in the delivery file (CESP, working documents or separate note in
case of CD/DVD submissions) may be provided to clarify the reason for resubmitting and the original cover
letter in the eCTD should not be changed, see Section 2.9.4. For submissions to the EMA it is mandatory to
use the eSubmission Gateway / Web Client and no additional comment is required.
For MRP / DCP guidance a cover letter template is provided at the CMDh webpage.
Page 25 of 56
3.2.3.2 Tracking Table
A tracking table should always be included as an annex to the cover letter for submissions within all
procedures. The file should be named cc-tracking-var.pdf and be placed in /XXXX/m1/eu/10-cover/cc (e.g.
ema-tracking-var.pdf for a CP, common-tracking-var.pdf in an MRP/DCP, or be-tracking-var.pdf in a NP.)
Examples of Tracking tables to be used within the MRP/DCP are found in the CMDh guidance CMDh Best
Practice Guide on the use of eCTD in the MRP/DCP. An example of a Tracking table that would be suitable
for a centralised or a national procedure can be found in Annex 2 below.
3.2.4 Application Forms
The application form should always be submitted with the document operation attribute “new (as for the cover
letter, see above), unless an error has been made in the form and an updated application form is being
provided in a new sequence, in which case the operation attribute should be replace.
Some NCAs do require the application form to be submitted as a signed paper original together with the eCTD
submission. Please refer to the CMDh website for submission requirements or the individual NCAs web sites
for further details.
The file named cc-form-eaf.pdf (without using any variable part of the file name) should be used if only one
eAF is provided. However, if more than one eAF is included in the m1.2, they should be differentiated by the
use of the variable part (e.g. cc-form-eaf-10mg and cc-form-eaf-20mg).
Supportive documents, which are not part of any M2-5 section or Response to Questions, should be placed in
the application form section 1.2. of the eCTD as separate files, and not appended to the form itself. Each
annex to the eAF should be provided as a separate attachment in m1/eu/12-form/cc, using the variable part of
the file name and the leaf title to clearly describe the content of the document. E.g. file name: fr-form-annex-
proofpayment.pdf, Leaf Title: France, Proof of Payment“.
3.2.5 Product information
Product information should be supplied as PDF files within the eCTD. In addition, MS Word files (with or without
tracked changes as relevant) should be provided in the separate folder XXXX-workingdocuments (see section
2.9.10) within the same submission. Alternatively, certain procedures require word working files to be sent via
Eudralink. Details can be found in Section 2.9.9 and from Section 4. Advice on specific application types.
In MRP/DCP national translations should be managed outside of the eCTD (see CMDh guidance CMDh Best
Practice Guide on the use of eCTD in the MRP/DCP).
In MRP/DCP, ensure that common product information is always placed under m1/eu/13-pi/131-
spclabelpl/common/en. If these documents are placed under country specific folders, e.g. the country folder
of the RMS, the agencies will not be able to use the country filtering options of their eCTD viewer tools as
intended.
In the Centralised Procedure, national translations are only required in the eCTD for the commission decision
documents in a closing sequence. However, for variations Type IA, the national translations should always be
provided with the first submission, if relevant. Please refer to Section 4.1. More information on requirements
for Centralised Procedure post-authorisation procedures can be found from here.
3.2.6 Use of Response Documents Section
The submission of electronic information in response to a list of questions from NCAs and EMA should follow
the same basic principles as the first submission. The written response should be submitted following the EU
recommended response folder and file structure. Please ensure that all documents are aligned with the CTD
structure (refer to Notice to Applicants Volume 2B) using the operation attributes of “new”, replace, or “delete
as appropriate. (Append” should be avoided, see Section 2.9.6.)
To help in the management of responses over the lifecycle of the eCTD, the responses relating to a particular
regulatory activity should be grouped under a node-extension in the eu-regional.xml file. The title of the node-
extension should identify the regulatory activity (e.g. Responses to Questions for the Initial Application,
Responses to Questions for Type II Variation 028, etc.). It is recommended that the applicant provides a full
copy of the list of questions received from the agencies as the first leaf in this section.
Page 26 of 56
It is recommended that the responses be split up into separate files for each major section of the submission
(e.g. Quality, Non-clinical and Clinical). Leaf titles should be used to identify the particular set of responses
(e.g. Response to Major Objections - Quality). If responses to more than one question are submitted in a single
file bookmarks should be used within the PDF file to clearly identify each response. It is possible to submit the
response to each question in a separate file but in that case node-extensions must be used and leaf titles to
group and identify the responses under the top-level node-extension.
In MRP/DCP, all files for the response documents should be placed in the folder m1/eu/responses/common,
regardless which member state raised the question.
In m1-responses/cc, it is recommended to use the variable component of the filename and 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.
Table 7 : Examples of Filenames and Leaf Titles for Response Documents
Suggested Filename
Suggested Leaf Title
common-responses-maa-d106-clin.pdf
Day 106 Clinical Responses, MAA
common-responses-maa-d120-clin.pdf
Day 120 Clinical Responses, MAA
common-responses-maa-d145-clin.pdf
Day 145 Clinical Responses, MAA
common-responses-maa-d120-clinq4.pdf
Day 120, Clinical Response Question 4, MAA
common-responses-maa-d120-clinq7.pdf
Day 120, Clinical Response Question 7, MAA
common-responses-var03-d45-clin.pdf
Day 45 Clinical Responses, Var03
common-responses-var03-d59-clin.pdf
Day 59 Clinical Responses, Var03
common-responses-maa-d106-qual.pdf
Day 106 Quality Responses, MAA
common-responses-maa-d120-qual.pdf
Day 120 Quality Responses, MAA
common-responses-maa-d145-qual.pdf
Day 145 Quality Responses, MAA
common-responses-var05-d44-qual.pdf
Day 44 Quality Responses, Var 05
common-responses-var05-d59-qual.pdf
Day 59 Quality Responses, Var 05
common-responses-var12-d33-qual.pdf
Day 33 Quality Responses, Var 12
3.2.7 Use of the Additional Data Section
The section 'Additional Data’ should only be used for nationally required information in National, Mutual
Recognition and Decentralised Procedures. An exemption to this is the use of this section for justifications for
active substances or justification of eligibility of the product for the Centralised Procedure.
In addition, this section can be used for all procedures when an old version of a DTD is being used during an
agreed transition period, to support inclusion of a newly defined section of Notice to Applicants (refer to
transition guidance issued with specification updates).
3.3 Module 2 Overviews and Summaries Folder
3.3.1 General Considerations
Each document should be provided as an individual PDF.
3.3.2 Structure of Module 2 Documents
In module 2.3 Quality Overall Summary (QOS) either one file (qos-var.pdf) or separate files per QOS section
can be submitted named as: introduction-var.pdf, drug-substance-var.pdf, drug-product-var.pdf, appendices-
var.pdf and regional-information-var.pdf. For details refer to the ‘File-Folder Structure & Names tab in the EU
Validation criteria spread sheet.
Where the application includes an active substance covered by an Active Substance Master File (ASMF), the
Applicant should submit the QOS on the applicant’s part of the ASMF as a separate file in module 2.3 of the
Page 27 of 56
MAA. If there are more than one ASMF, there should be a separate file for each QOS. The Applicant should
ensure that each QOS has a front page clearly stating the version number and date.
If an existing document is revised, the lifecycle operator ‘replace’ should be used. However, if changes of
content only affect one section of that document then updates should normally be submitted as a separate
summary with the document operation attribute new as it would help clarifying what to assess within the
specific submission.
For submissions covering multiple indications, refer to Section 3.6.1.
3.4 Module 3 Quality Folder
3.4.1 Module 32S drug substance
This section will give guidance on how to structure the documentation related to the drug substance. Also,
please find an example in Annex 3.
In relation to the active substance manufacturer’s documentation, the documentation can be part of the
complete dossier, be presented as an Active Substance Master File (ASMF) or be covered by a Certificate of
Suitability (CEP). The Applicant should provide the documentation on the active substance as relevant in
these different situations.
For biological/biotechnological and Advanced Therapeutic Medicinal products, where the whole active
substance documentation would be presented as part of the complete dossier, it is recommended that only
one drug substance module (m32s section) should be created even if several active substance
manufacturers are used. If there are several different active substances in one finished product (combination
product), the documentation should be presented as one drug substance module (m32s section) per active
substance.
For all chemical products and products covered by an ASMF, please see the following sections for different
scenarios.
3.4.1.1 Active substance documentation for chemical products and products covered by
an ASMF
For the documentation on the active substance for chemical products and products covered by an ASMF, it
is important to differentiate between:
o The active substance manufacturer´s documentation on the active substance
o The Applicant’s documentation on the control of the active substance
The active substance manufacturer’s documentation covers how the active substance is manufactured and
controlled by the active substance manufacturer to ensure the quality of the active substance (see 3.4.1.1.1).
The Applicant’s documentation covers how the active substance is controlled by the finished product
manufacturer(s) to ensure the quality of the active substance (see 3.4.1.1.2). This would only be applicable
when the active substance and the finished product are manufactured at different sites.
Both the active substance manufacturers documentation and the Applicant’s documentation on the active
substance should be provided in the eCTD dossier, as relevant.
Where the application includes an active substance covered by an Active Substance Master File (ASMF), the
Applicant should submit the applicant’s part of the ASMF in module 3.2.S. The Applicant should ensure that
the front page of the applicant’s part, clearly stating the version number and date, is also included in the product
eCTD dossier either as the first page of the first document (i.e. in the nomenclature document) or as a separate
file placed in Module 3,2.S.1.1, called nomenclature-cover page applicant’s part.pdf.
3.4.1.1.1 Active substance manufacturer’s documentation on the active substance
The documentation can be part of the complete dossier, be presented as an Active Substance Master File
(ASMF) or be covered by a Certificate of Suitability (CEP). The Applicant should accordingly provide the
complete documentation on the active substance, the applicant’s part of the ASMF or the CEP, as relevant.
Page 28 of 56
a) If more than one active substance manufacturer for the same active substance
When the active substance manufacturer’s documentation is presented as an Active Substance Master File
(ASMF), one drug substance module (m32s section) should be created per ASMF i.e. each applicant’s part
should be presented in its own drug substance module.
When the active substance manufacturers documentation is part of the complete dossier (i.e. not provided
as an ASMF), one drug substance module (m32s section) can be created per active substance manufacturer
or one drug substance module (m32s section) can be created covering all active substance manufacturers,
depending on whether the documentation is largely similar or not (and same route of synthesis applies).
When the active substance is covered by a CEP, each CEP should be placed in module 3.2. Regional
Information (and in Module 1.2 as annex 5.10). If needed, a separate m32s should be created for each
active substance manufacturer, where relevant sections of 3.2.S.1 to 3.2.S.7 folders should be used for any
additional documents (e.g., for information not covered by the CEP).
b) If multiple active substances in one finished product
Where there are multiple active substances in one finished product (combination product), one drug
substance module (m32s section) should be created per active substance and the above guidance for
several active substance manufacturers should be followed.
3.4.1.1.2.Applicants documentation on control of the active substance
The Applicant is responsible for ensuring the quality of the active substance. The applicant should therefore
have their own drug substance module (m32s) covering the control of the active substance performed by the
finished product manufacturer(s) when the active substance and the finished product are manufactured at
different sites.
a) If more than one active substance manufacturer for the same active substance
The Applicant’s documentation on the active substance should be compiled as stated in the guideline
Guideline on Active Substance Master File Procedure. This requirement is the same whether the
documentation on the active substance is part of the complete dossier, presented as an ASMF or is covered
by a CEP.
As the Applicant’s documentation on the active substance should always be compiled, there should only be
one drug substance module (m32s) per active substance. It is not acceptable to submit the Applicants
documentation divided into different drug substance modules, even if there are several different active
substance manufacturers. It is also not acceptable to provide the Applicant’s documentation as separate drug
substance modules even if there are several different finished product manufacturers.
b) If multiple active substances in one finished product
Where there are several different active substances in one finished product (combination product), the
Applicant’s documentation should be presented as one drug substance module (m32s section) per active
substance.
If an existing eCTD is not structured in line with the above guidance, the dossier should be restructured with
the next submission of a quality variation that affects the relevant content.
See also section 4.7 for information on Active Substance Master Files.
3.4.2 Module 32p drug product
This module can be repeated and each dosage form (for example film-coated tablets and capsules) covered
by an eCTD dossier should always be described in its own m32p section.
If an application includes multiple strengths of one dosage form, the documentation covering all strengths is
recommended to be provided in the same m32p section whether or not the documents are strengths specific
or combined. If there are some strength specific documents, it would still be recommended to include these in
Page 29 of 56
the same m.3.2.p section. However, if there are substantial differences between the manufacturing or quality
control of a strength, it might be justified to have a separate module 3.2.p section. The approach should
preferable be described in the cover letter.
There should only be one m32p section even if there are multiple finished product manufacturers. It is not
acceptable to provide one m32p section per finished product manufacturer for the same dosage form of the
finished product. The description of the manufacturing process should be provided as one document within
the m32p section (in module 3.2.P.3.3). Please see Guideline on manufacture of the finished dosage form
for further guidance. §
If an existing eCTD is not structured in line with the above guidance, the dossier should be restructured with
the next submission of a quality variation that affects the relevant content.
3.5 Module 4 Nonclinical Study Reports Folder
3.5.1 Guidance on the Handling of Granular Study Reports
Submissions created in eCTD format for the use within the FDA may provide more granular study reports
using study tagging files. There is no need to re-organise the reports for submission to the EMA or NCAs. See
Section 3.6.2. below for further information.
Page 30 of 56
3.6 Module 5 Clinical Study Reports Folder
3.6.1 Management and Handling of Multiple Indications
In cases where the application includes multiple therapeutic indications, the reports should be organized in a
separate Section m535 for each indication. In such cases, if a clinical efficacy study is relevant to only one of
the indications included in the application, it should be included in the appropriate section in m5 (e.g. m5/53-
clin-stud-rep/535-rep-effic-safety-stud/anxiety/5351-stud-rep-contr). If a clinical efficacy study is relevant to
multiple indications, the study report should be included in the most appropriate subsection of m535 and
referenced as necessary in the equivalent section under the different indication. In Module 2, a separate
Summary of Clinical Efficacymodule should be submitted f or each indication, although closely related
indications can be within a single document.
Regardless of which way is chosen, it is important to provide clear written guidance to the assessor when the
supportive data/study report documents are applicable to more than one indication.
3.6.2 Management and Handling of Granular Clinical Study Reports
ICH Q&A 22 recommends use of E3 granularity for clinical study reports. In Europe, node extensions should
be used to group together individual files. If a US NDA is repurposed for submission in the EU, the study
content (the study report and any relevant appendices) should be placed under a node extension. The STF
xml file itself and any content not required for the EU submission (e.g. datasets) should be removed, but
submissions still containing STF files will not be rejected. In order to maintain a consistent looking eCTD
lifecycle and table of contents (via index.xml), applicants are advised to use node extensions for all clinical
study reports, regardless of the granularity of the content (i.e. even reports that consist of only one document
should also be presented in node extensions). See also Section 2.9.8 Node-extensions.
3.6.3 Provision of CRFs and Data when Requested
If case report forms and individual patient data listings are submitted in m537 (as appendices 16.3 and 16.4
in the ICH clinical study report guideline E3) they should be placed in the same order as the clinical study
reports appearing in m535 and should be indexed by study. Please note that bookmarks will not be required
as there will be no further internal structure.
3.6.4 Provision of Synopses of Individual Studies
It is acceptable either to include copies of the synopses for each study in eCTD 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.
3.6.5 Company Core Data Sheet
If companies submit their Company Core Data Sheet, this is recommended to be provided in eCTD section
5.3.6, Post Marketing Experience.
Page 31 of 56
4. Advice on Specific Application Types
4.1 New MA Applications
The recommended start for an eCTD lifecycle is the initial MA application. It should normally be provided as
sequence 0000. To start with another number should be justified in the cover letter. All documents included
should have the operation attribute newand be placed in the relevant sections in line with the different eCTD
specifications.
The submission type should be maa.
See Section 2.9.5 for an example on the use of the submission units.
For responses to questions documents, see Section 3.2.6.
The following milestones of the procedures are proposed as appropriate sequences to be submitted during
the assessment of a new application.
Table 8 : MAA Centralised Procedure
Day Number/
Milestone
eCTD milestone sequence
Notes
Submission
deadline
Initial submission
As per published submission calendars
-5 or as
requested
before date of
start
Response to business validation issues
If required
121
Response to List of Questions (LoQ)
If applicable
181
Response to List of Outstanding Issues
(LoOI)
If applicable
Any time
between
D181-220
Redaction Proposal Document Package
For details see Section 4.12
Commission
Decision + 15
days or prior
to the next
regulatory
activity
whichever is
first.
Decision / Closing sequence including
final translations
Updates to the dossier which have not yet
been submitted in eCTD but which have
been agreed by the CHMP at the time of
the opinion; e.g.
Final RMP
Minor updates to Module 2 or 3
Final Product Information (Annex I,
II, IIIA, IIIB and Annex A) in all
languages
Final mock-ups reviewed during
the procedure.
I.e. final amended documentation if any
changes occur during the Standing
Committee phase (SCP)
Except from changes during the SCP,
the documentation submitted within this
eCTD sequence should be identical to
the documents submitted to the EMA at
the time of the CHMP opinion via
EudraLink.
20 calendar
days post
consultation
notification
Final Redacted Document Package
For details see Section 4.12
Page 32 of 56
Table 9 : Centralised Procedure - Outside eCTD via EudraLink
211 (opinion
+ 1)
Final English PI
Opinion + 5
Provision of translations
Opinion + 25
Provision of final agreed translations
following linguistic review
Table 10 : New MAA Decentralised Procedure
Day Number/
Milestone
eCTD milestone sequence
Notes
- 10
New MAA
Procedure
start
Validation update
If required
106
Day 106 Responses to questions
210
Final agreed EN product information
Or at any day when the procedure can
be closed after agreement is reached.
For further details on MRP and DCP, please refer to the CMDh Best Practice Guide on the use of eCTD in
the MRP/DCP.
4.2 Variation Applications
All types of variations should be submitted within the eCTD as new sequences.
Documents related to the variation should be included in relevant sections or be deleted or replaced by use of
the appropriate document operation attribute. Where documents cannot be assigned to specific CTD defined
locations, then they should be provided as annexes to the m1.2 Application Form.
The submission type should reflect the type of variation. (See Q&A for Variations in eCTD). Submissions for
workshare/grouping variations (containing MRP/DCP/National products only) concerning several eCTD
submissions are recommended to be supplied together in a single zip file, refer to section 2.12. The zip file
should contain clearly marked subfolders for each product eCTD dossier (each specific UUID) that takes part
in a worksharing or grouping procedure.
For worksharing procedures containing only CAPs or worksharing procedures containing CAPs and
MRP/NAPs a separate submission for each eCTD via the eSubmission Gateway/Web Client only is required.
In case of worksharing procedures containing CAPs, the submissions for nationally authorised products
(MRP/DCP/NP) should be sent to EMA only via the eSubmission Gateway/Web Client. There should be no
additional submissions directly to NCAs.
See Section 2.9.5 for an example on the use of the submission units.
For details on how to handle parallel variations, please refer to Annex 4 of this guidance.
Although Type IA variations usually should not be revised if they are invalid from regulatory point of view, it is
necessary to correct technical invalid submissions in the same way as required for any other eCTD sequence.
The following milestones of the procedures are proposed as appropriate sequences to be submitted during
the assessment of variations. Although the example relates to the Centralised Procedure the principal could
be applied to other procedures (except for final translations).
Page 33 of 56
Table 11 : Type II Variations Centralised Procedure
Day Number /
Milestone
eCTD milestone sequence
Notes
Submission
deadline
Initial submission
Please observe the published
submission timetables, e.g. “Start of
the procedure, new indication
-5 or as
requested
before date of
start
Response to business validation issues
If required
RSI
Submission
deadlines
Response to Request for Supplementary
Information (RSI)
If applicable
Opinion + 30
For Type II variations which are not followed
by an immediate Commission Decision:
Decision / Closing sequence including final
translations if applicable
Updates to the dossier which have not yet
been submitted in eCTD but which have
been agreed by the CHMP at the time of the
opinion; e.g.
Final RMP
Minor updates to Module 2 or 3
Final Product Information (Annex I, II, IIIA IIIB
and Annex A) in all languages
For Type II variations which are not
followed by an immediate
Commission Decision
Commission
Decision + 15
days or prior
to the next
regulatory
activity
whichever is
first.
For Type II variations following worksharing
or with immediate Commission Decision:
Decision / Closing sequence including final
translations if applicable
Updates to the dossier which have not yet
been submitted in eCTD, but which have
been agreed by the CHMP at the time of the
opinion, e.g.
Final RMP
Minor updates to Module 2 or 3
Final Product Information (Annex I, II,
IIIA IIIB and Annex A) in all
languages
Final mock-ups reviewed during the
procedure.
For Type II variations following
worksharing or with immediate
Commission Decision
Table 12 : Type IA & IB Variations Centralised Procedure
Day Number
eCTD milestone sequence
Notes
Submission
Start of the procedure <description>
e.g. Start of the procedure, phone
number changes
RSI
Submission
deadlines
Response to Request for Supplementary
Information (RSI)
If applicable
Table 13 : Type IB Variations with linguistic review - Centralised Procedure
Day Number
eCTD milestone sequence
Notes
Page 34 of 56
Submission
deadline
Start of the procedure <description>
English PI, clean (pdf) inside the eCTD
English PI, tracked changes + translations
(MS Word) (Outside eCTD but within the
same submission package in the
working_documents folder)
e.g. Start of the procedure, phone
number changes
Start + 5
Provision of translations (Eudralink)
Start + 25
Provision of final agreed translations
following linguistic review (Eudralink)
RSI
Submission
deadlines
Response to Request for Supplementary
Information (RSI)
If applicable
Notification +
15
Closing sequence including final
translations, clean (pdf) inside the eCTD
For MRP and DCP, please refer to the CMDh guidance Requirements on submissions for New Applications
within MRP, DCP or National procedures.
4.3 Extension Submissions
Several dosage forms can be managed within a single eCTD application, and this helps to avoid submission
of data multiple times (e.g. active substance changes). Submissions for an extension can either be submitted
within an existing eCTD application, as a new sequence (continuous sequence numbering), or as a new eCTD
application (sequence 0000), if a separate lifecycle management is preferred (not applicable in the Centralised
Procedure, see below).
In MRP/DCP, an extension will be submitted within the same procedure, but with a different product number,
and as such, the recommendation is to submit the extension as a new sequence within the original eCTD
application, submitting a new Module 1, an updated Module 2 and new or updated 32P section. If m32p is
combined for all previous existing strengths/dosage form(s), an updated section should be provided, replacing
existing documents where necessary. If a separate m32p is being provided for the additional strength/dosage
form to describe the extension, then all documents should have the operation attribute of new.
For extension applications, only new data should be submitted as a new sequence in the already submitted
eCTD. The submission type should be “extension”.
If single eCTDs are used for each strength or form of a product, full data concerning the extension applied for
has to be included in the submitted eCTD and therefore clear information should be given to the assessor on
what is new compared to earlier submitted data for the product to avoid unnecessary assessment.
In the Centralised Procedure, extensions are typically managed under the same procedure number as the
original dosage form, and again the recommendation is to submit the extension as a new sequence within the
original eCTD application, using a new m32p to describe the different dosage form.
For national applications, the applicant should discuss with the relevant NCA.
4.4 Renewal Submissions
Please note that a renewal application can be used as the first eCTD in a product lifecycle in a similar manner
to variations. The recommendation given in the section above applies likewise.
The submission type should be “renewal”.
See Section 2.9.5 on examples on the use of the submission units.
Page 35 of 56
The following milestones of the procedures are proposed as appropriate sequences to be submitted during
the assessment of renewals: Although the example relates to the Centralised Procedure the principal could
be applied to other procedures (except for final translations).
Table 14 : Renewals
5 year Renewal Centralised Procedure
Day Number
eCTD milestone sequence
Notes
Submission
deadline
Initial submission
As per published submission calendar
91
Response to Request for Supplementary
Information (RSI)
If applicable
Commission
Decision + 15
Decision / Closing sequence including
final translations if applicable
Updates to the dossier which have not yet
been submitted in eCTD but which have
been agreed by the CHMP at the time of
the opinion; e.g.
Final RMP
Minor updates to Module 2 or 3
Final Product Information (Annex I,
II, IIIA, IIIB and Annex A) in all
languages
Annual Renewal of conditional marketing authorisation Centralised Procedure
Day Number
eCTD milestone sequence
Notes
Submission
deadline
Initial submission
As per published submission calendar
Table 15 : Centralised Procedure Outside eCTD via EudraLink
Opinion + 1
Final English PI
Opinion + 5
Provision of translations
Opinion + 25
Provision of final agreed translations
following linguistic review
For renewals in MRP and DCP, the general principles in the CMDh guidance CMDh Best Practice Guide on
the use of eCTD in the MRP/DCPcan be applied.
4.5 PSURs
As per the Article 107b paragraph 1 and Article 28(2) Regulation 726/2004) all Periodic Safety Update
Reports (PSUR) shall be submitted electronically. The use of the PSUR Repository is mandatory for all
human products authorised in the EU (CP, MRP, DCP and NP). The use of the PSUR Repository is
mandatory for all products regardless if the product is included in an EU PSUR Single Assessment
Procedure or if the assessment is part of a national procedure. The submission to the PSUR Repository is
always required and it is important to indicate the PSUSA procedure number for all submissions included in
a PSUSA procedure.
As per the HMA eSubmission Roadmap the use of eCTD format is now mandatory for all procedure types
within EU, including purely nationally authorised products. Since the PSUR is a part of the product lifecycle it
should be provided as the next relevant sequence in the products eCTD lifecycle. This applies to all products
within all authorisation procedure (CP, MRP, DCP and NP), also for those for which the PSUR is part of an
Page 36 of 56
EU PSUR Worksharing procedure for NAPs or the EU PSUR Single Assessment (PSUSA) procedure for CAPs
and NAPs.
A separate PSUR eCTD sequence must be submitted for each respective eCTD lifecycle, even if the PSUR
document covers multiple products.
If a single PSUR has been prepared covering multiple products a separate submission (of that same PSUR
document) must be made for each respective product.
However, to facilitate the assessment, it should be clarified in the cover letter that the submitted documentation
in each separate eCTD sequence is identical in relevant parts. For PSUR submissions under PSUSA
procedures, the grouped submission feature in the PSUR repository should be used. Separate standalone
eCTD sequences grouping multiple products must not be created.
The submission of a PSUR should be included in the eCTD as a new document in m536 as well as a new or
replace document in m25 as necessary. Any literature should be included in m533 or m54 as appropriate.
The naming of the leaf element in m536 shall indicate the number of the PSUR or the period covered.
According to the guidance set out in GVP module VII on PSURs, proposed changes to the EU labels as a
result of the PSUR data should be provided under Section VII.C.5.1. PSUR EU regional appendix, sub-
section “Proposed product information of the PSUR.
For CAPs, the proposed product information should also be submitted to Module 1.3.1 of the eCTD.
It should be presented as a tracked change version of each EU SmPCs and package leaflet of the products
concerned and each product information should be translated into English language including the tracked
changes proposed, in order to enable the EU single assessment.
This can result in having to submit a large number of sets of tracked change product information with the
additional burden of providing translations. Hence MAHs can consider the option to focus on the proposed
amendments to SmPC and package leaflet. In such case, only the amended parts of the SmPC and package
leaflet should be provided in track changes and in English language under the EU regional appendix.
Where the proposed changes are not based on the data submitted within the PSUR, these will not be
considered, and a variation will have to be submitted as appropriate to the relevant national competent
authority.
In case no changes to the product information are being proposed as part of the PSUR, the MAH should not
include any product information within the EU regional appendix.
Amendments to the SmPC, package leaflet and labelling, as a result of the PSUR assessment, should be
implemented without subsequent variation submission for CAPs and through the appropriate variation for
NAPs, including those authorised through MRP or DCP.
When multiple products from the same MAH are covered by the PSUR, all products must be listed in the cover
letter.
The submission type should be “psurfor ‘pure, single PSURs’, i.e. those products for which the active
substance is not included in the EURD list.
For PSURs included in the EU PSUR Single Assessment (PSUSA), the submission type is “psusa”
See Section 2.9.5 for an example on the use of submission unit.
More information on the submission of PSUR submissions can be found from the EMA Post-Authorisation
Guidance. Please also refer to the PSUR Repository website for the most recent information.
Note: MAHs should not submit full study reports as part of a PSUR. Final study reports should always be
submitted as a C.1.13 variation. In the case of interim PASS study results, these can be summarized in the
PSUR under the section Findings from non-interventional studies or alternatively if the reporting to EMA
does not coincide with the PSUR submission, the full interim report should be submitted as a separate,
stand-alone submission (post-authorisation measure (PAM)) relevant to CAPs only.
Additionally, submission of RMP updates cannot be accepted with PSURs subject to a PSUSA of:
a mixture of CAPs pertaining to different GMAs;
a mixture of centrally and nationally authorised medicinal products;
a mixture of NAPs.
Page 37 of 56
The submission of an imposed, non-interventional Post Authorisation Study protocol or study report should
not be combined with a PSUR or PSUSA sequence. Please, use the submission type pass107n in case of
the protocol and pass107q’ in case of the study report.
For follow-up (MAA-LEG) procedures within the Centralised Procedure, please refer to the EMA Q&A on
post-authorisation measures.
Regarding PSUFU submission, i.e. follow-up submissions for NAPs, please see technical details in the
CMDh guidance for PSUFU.
4.6 Referrals
The eCTD format is mandatory for all referral submissions. There are, however, some difference in the
handling depending on the type of referral, as described below. Regardless these different handlings during
the referral procedure, any variation application required after a referral outcome should always be submitted
in eCTD format per concerned product eCTD dossier.
4.6.1 CMDh referrals related to MRP/DCP/RUP
CMDh referrals would be product specific as a result of different positions within a MRP/DCP procedure and
should be included in the product eCTD as a next sequence in the lifecycle. The response from the applicant
to the referral list of questions should be sent as an eCTD sequence to all CMD(h) members, according the
timelines as defined, even if all NCAs would not have the starting sequences for that product (i.e. are not
involved in the MRP/DCP procedure).
The type of submission of this sequence should be referral” with the relevant submission unit (see section
2.9.5).
4.6.2 EMA-led referral procedures
Referral submissions concerning CAPs only and all EMA-led referrals where also National products are
included (NP, MRP, DCP products) should be sent via EMA eSubmission Gateway or eSubmission Web Client
only. They are available via the Common Repository and considered delivered to all National Competent
Authorities (NCAs) and scientific group experts. No additional copies of the submissions should be sent directly
to the NCAs as this might lead to validation issues and cause delays.
For CAPs, referral submissions should always be submitted as the next sequence in the product lifecycle for
each CAP. Standalone eCTD submissions for the referral (on active substance basis) are not allowed for any
CAPs included in referral procedures. However, for EMA led referral procedures where only MRP, DCP and
NP products are included, a stand-alone eCTD lifecycle is recommended to cover all the concerned nationally
authorised products.
New documentation/information/responses should be included as a new eCTD sequence. The type of
submission of the new sequence should be referral with the relevant submission unit (see section 2.9.5).
In case of a newly created/submitted sequence, the cover letter contains background information for the
reason of the referral. Any other document, which concerns the referral, should be included according to the
eCTD structure. Any additional documentation that does not have a relevant placeholder in the dossier, for
example an overview of the registrations/applications involved in the referral, should be placed in m10-cover.
Please refer to Dossier requirements for referral procedures for more details.
4.7 Active Substance Master Files
For Marketing Authorisation Applications (MAAs) in eCTD format, where the documentation on the active
substance is presented as an Active Substance Master file (ASMF), the applicant should incorporate the
applicant’s part (AP) documents of the ASMF and the Quality Overall Summary (QOS) on the applicant’s part
of the ASMF into the eCTD structure as per the relevant guidelines. It is recommended to use a suffix of -ap’
on the filename of these documents.
Page 38 of 56
The ASMF Holder should provide the full ASMF, i.e. both the Applicants and the Rest ricted part in eCTD
format to the relevant authorities. The Applicant’s part and the Restricted part should each have a front page
clearly stating the version number and date.
The ASMF should include a QOS on the Applicant’s part and a separate QOS on the Restricted part. Each
QOS should have a front page clearly stating the version number and date.
For further information, please refer to the EU Harmonised Technical Guidance for ASMF Submissions in
eCTD format at the eASMF page on the eSubmission website.
A copy of the "Letter of Access" addressed to the relevant regulatory authority included as Annex 5.10 of the
application form should be placed in m12/cc (i.e. in the respective folder for each concerned authority).
4.8 Vaccine Antigen Master Files
The VAMF consists of the scientific data according to Part III of Annex I of Commission Directive 2001/83/EC
as amended. To support the lifecycle, keep the documents manageable and to assure the correct alignment
of the complete VAMF it is required that the manufacturer submits the VAMF (including versioning), preferably
in an electronic format following the principles of eCTD. The complete VAMF can be processed with its own
submission / case / procedure number separately.
The application of a medicinal product will contain the same data package including the certificate of
compliance with Community legislation, together with the evaluation report attached.
4.9 Plasma Master Files (PMFs) and medicinal products containing
PMFs
4.9.1 Plasma Master Files
The Plasma Master File documentation for certification is submitted to the EMA as a stand-alone eCTD
dossier of a medicinal product. This documentation contains all the information related to the starting
material for the manufacture of the medicinal product but submitted separately from MAA dossier (EC
Regulation Commission Decision 2003/83/EC, part III of Annex I) when follows the PMF certification
evaluation procedure.
ePMF should be provided within the ‘workingdocuments’ folder for PMF certification submissions.
For practical on PMF eCTD guidance, the reader is referred to the see the PMF eCTD Guidance document
found via this link. More information on PMF submission can be found here.
4.9.2 Medicinal products containing PMFs
All concerned medicinal products that include one or more plasma supplier in their dossier (i.e. one or more
PMF(s)) are required to have their dossier updated and implement any updates by submitting the relevant
variations to the MA (see point 4.2above).
4.10 Applicant Initiated Withdrawals of the MA or certain strengths or
dosage forms
Applicants may decide to withdraw their marketing authorisation during any stage of the product lifecycle and
this section explains the general principles that should be followed in terms of managing the eCTD lifecycle.
If the application for withdrawal does not include all strengths and/or dosage forms covered by the same eCTD,
the application should be submitted as a new sequence, with the operation attribute “delete” for documents
that are no longer relevant. Furthermore, if relevant, it should also include updated documents with the
operation attribute replace” for documents that covered several other strengths and/or dosage forms and that
now need to be revised to exclude the withdrawn strengths and/or dosage forms from the document.
Page 39 of 56
Withdrawal of the whole product (all dosage forms and strengths) covered by an eCTD should preferably be
submitted as a new sequence only including a cover letter with the request of withdrawal. The operation
attribute “delete” is not required to be used for the documents.
The submission type ‘withdrawal or the relevant variation category for the change, depending on the regulatory
procedure being followed should be used.
4.11 Applicant Withdrawal or Agency Rejections of Post-
Authorisation Regulatory Activities
If a regulatory activity is withdrawn, fully or partially or rejected fully or partially, then the documentation has to
be updated accordingly with a consolidation sequence. Documents that are no longer relevant should be
deleted, and documents where the content needs to be adjusted to reflect the withdrawal or rejection be
replaced. The application form and cover letter should always be retained to keep the history. A consolidation
sequence should be submitted to restore the current view of the dossier to what it was before the rejected
activity was submitted. This would also apply where documentation needs to be adjusted as a result of a
commitment or a partially rejected variation. The submission type should be consolidating.
Note, it is not possible to delete a sequence from the life cycle to accommodate the withdrawal or rejection.
Scenario on consolidation sequence
Applicant X has submitted sequences:
0027 Variation 011
0028 Day xx response
Letter of rejection of variation 011
**0029 consolidating sequence to restore the previous status of dossier
0030 Variation 012
0031 = Next submission
The variation 011 has been rejected and those parts affected by the proposed variation need to be restored to
present the previous status in the current view of the eCTD.
Examples for this scenario:
** After full or partial rejection of sequence 0027, (variation 011), a following sequence 0031 may change the
same technical content. If the change previously applied for in variation 011 has not been fully restored, the
new variation may not be displayed correctly, for example, the next submission cannot refer to content which
was proposed in variation 011 but subsequently removed. Therefore, the consolidating sequence, 0029, must
remove any new and now rejected content from the rejected variation, and also reinstate any documents that
were deleted or replaced in sequence 0027/0028, such that sequence 0030 can itself replace or delete the
content as required. i.e. Sequence 0029 must restore the current view, (in terms of what is current, not deleted
or replaced), to what it was before sequences 0027 and 0028 were submitted.
4.12 Publication of Clinical Data for Medicinal Products
Clinical reports will be published, under Policy 0070 (The European Medicines Agency policy on the publication
of clinical data for medicinal products for human use) following conclusion of the regulatory decision-making
in the frame of centralised marketing authorisation procedures.
Key components of the process from the point of submission by an applicant/MAH to the point of publication
are following:
Redaction Proposal Document” package (eCTD sequence to be included in the eCTD lifecycle with the
attribute « new »)
Final Redacted Document package (eCTD sequence to be included in the eCTD lifecycle with the attribute
« new »)
For further details please refer to the Guidance for the publication of clinical data:
4.13 Duplicate Applications
Page 40 of 56
One eCTD per so called duplicate application has to be submitted and maintained separately in the post-
authorisation lifecycle phase (with the possibility of including several strengths, dosage forms etc. if relevant).
It should however be clearly written in the cover letter that it is exactly the same content (with the only
exemption of different tradename and maybe different MAH), so that redundant review work is avoided.
Duplicates are independent marketing authorisations and therefore the eCTD lifecycle will need its own UUID.
The term is used for practical reasons and understood as a MA application which is a copy’ of another
application. Duplicates can be submitted under the same legal basis as the initial application (e.g. Art. 8(3) of
Dir 2001/83/EC). The legal basis of the dossier will trigger the dossier requirements. There is no definition of
a duplicate” in the pharmaceutical legislation. However, f or practical purposes, a duplicate application is
defined for MRP/DCP by reference to the first application or marketing authorisation as follows based on
CMD(h) recommendations on multiple / duplicate applications:
same dossier (copy of modules 1, 2, 3, 4 and 5);
same legal basis according to Directive 2001/83/EC, as amended;
different trade name;
same or different applicant/marketing authorisation holder.
For CP specific requirements on multiple applications see the document Handling of Duplicate Marketing
Authorisation Applications of Pharmaceutical products’.
Duplicate applications should always be submitted as independent stand-alone eCTD dossiers with their own
life cycles and is following eCTD life cycle maintenance rules.
4.14 Informed Consent Applications
An Informed consent application is an application according to Article 10c of Directive 2001/83/EC as
amended. The marketing holder for the reference product has consented that the applicant could refer to all
three modules containing the pharmaceutical, preclinical and clinical data for the reference product. It is not
possible to use Article 10c for an application with the applicants own data for module 3 and for which consent
has been given only for module 4 and 5. In case other modules than module 1 are submitted according to the
requirements of the relevant national competent authorities, these other modules have to be identical with the
reference product dossier.
Based on CMDh INFORMED CONSENT APPLICATIONS IN MUTUAL RECOGNITION AND
DECENTRALISED PROCEDURES RECOMMENDATIONS:
- module 1 should always be submitted by the applicant including a letter of consent to module 3-5 as
applicable.
- module 2- 5, if provided due to national requirements, must be identical with the reference product
dossier.
- is not legally obliged to cover all pharmaceutical form(s)/strength(s) of the reference medicinal product,
- must have different trade name,
- same or different applicant/marketing authorisation holder,
- if an Active Substance Master File has been used for the reference product a new letter of access
should be included in the application for the second product.
Within the centralised procedure, only module 1 should be submitted by the applicant including a letter of
consent to module 3-5, as applicable.
Page 41 of 56
Annex 1: eCTD Reference Documents
It is recommended to regularly follow the information on the following websites:
The EMA eSubmission website, with for example the EU Module1 Specification and other eCTD
v.3.2.2 EU specific information like guidance documents and the EU Validation Criteria.
ICH Electronic Standards (e.g. eCTD 3.2): https://www.ich.org/page/electronic-standards-estri
EC Legal framework: http://ec.europa.eu/health/documents/eudralex/index_en.htm
CMDh eSubmission website: http://www.hma.eu/277.html
Thera are also other relevant information to be considered:
http://estri.ich.org/eCTD/eCTD_Specification_v3_2_2.pdf
https://admin.ich.org/sites/default/files/inline-files/eCTDQAV1_31_xlsx.zip
https://admin.ich.org/sites/default/files/inline-
files/Specification_for_Submission_Formats_for_eCTD_v1_3.pdf
EMA Pre authorisation guidance Q&As
Pre-authorisation guidance | European Medicines Agency (europa.eu)
EMA Post-authorisation Q&As
http://www.ema.europa.eu/ema/index.jsp?curl=pages/regulation/general/general_content_000166.js
p&mid=WC0b01ac0580023399
ICH M4, CTD information
ICH Official web site: ICH
EU CTD information including Q&As:
EudraLex - Volume 2 - Pharmaceutical legislation on notice to applicants and regulatory guidelines for
medicinal products for human use | Public Health (europa.eu)
EMA Gateway:
http://esubmission.ema.europa.eu/esubmission.html
Common European Submission Platform (CESP)
http://cespportal.hma.eu
Electronic Application Form (eAF)
http://esubmission.ema.europa.eu/eaf/index.html
EMA Quality guidelines
https://www.ema.europa.eu/en/documents/scientific-guideline/guideline-manufacture-finished-dosage-
form-revision-1_en.pdf
https://www.ema.europa.eu/en/documents/report/final-guideline-active-substance-master-file-procedure-
revision-4_en.pdf
Annex 2: Tracking Table Example
A2-1 Introduction
A Tracking table is required for all eCTD submissions within all procedure types. This is an example of a Tracking table in a suitable format for submissions within
the centralised or national procedures. For submissions within DCP/MRP, please refer to the CMDh guidance Requirements on submissions for New Applications
within MRP, DCP or National procedures.
A2-2 Tracking table example for CP and NP
Product Name/Number
Sequence
Number
Submission Description
Submission Date
0052
Change of ANX II PAM due date (31 Oct14 to 28Feb15) - RSI (EU RMP)
Aug-2021
0051
Change of ANX II PAM due date (31 Oct14 to 28Feb15)
Jul-2021
0050
7th Annual Re-Assessment
Jul-2021
0049
CMC Store below 25C (Grouped Variation II, 2xIB)
Jul-2021
0048
Change of ANX II PAM due date (31 Oct14 to 31Jan15)
Jun-2021
0047
Contain closure system change
Jan-2021
0046
Article 61(3) (disposal warning) - Annex IIIA Labelling
Jul-2020
0045
6th - Annual Reassessment
Jul-2020
0044
Article 61(3) (disposal warning)
Jun-2020
0043
Type IAIN (Black triangle)
Jun-2020
0042
PV Supergrouping
Mar-2020
0041
MAH Address change - supergrouping
Mar-2020
0040
PV Supergrouping
Feb-2020
0039
Paediatric Article 46 application for Japanese study PGA123456
Jan-2020
0038
Commission decision
Aug-2019
0037
5th Annual Re-assessment (validation)
Jul-2019
0036
5th - Annual Re-assessment
Jul-2019
0035
Product change in retest period to 60 months
Mar-2019
0034
Type IA Super Grouped Variation to Update DDPS EMEA/H/xxxx/IG
Feb-2019
0033
5 year renewal applictaion updated during validation
Jan-2019
0032
5-year renewal for Product (EMEA/H/C/xxx)
Jan-2019
0031
Periodic Safety Update Report # 7 (EMEA//H/C/xxx)
Dec-2018
0030
Type II Variation to add xxxx as a new adverse event (incl. validation comments)
Dec-2018
0029
Type II Variation to add xxx to the prescribing information
Nov-2018
0028
Fourth Annual Re-Assessment
Jul-2018
0027
Fourth Annual Re-Assessment
Jul-2018
0026
Response to CHMP request upon review of PSUR 6
Jun-2018
0025
Grouped Variation - Change in the specification for Immobilised PNP and Immobilised URDP
Apr-2018
0024
Grouped Variation - Registration of xxxxx as a site of manufacture
Apr-2018
0023
6th PSUR (PSU-010) for product [Period between 28-Oct-2009 to 27-Oct-2010)
Dec-2017
0022
Type IA Grouping
Nov-2017
0021
Annual Reassessment Report
Aug-2017
0020
Annual Reassessment Report
Jul-2017
0019
Annual Reassessment Report
Jul-2017
0018
Specific obligation: clarification on protocol patient inclusion criteria (PMS Study PGA111081)
Apr-2017
0017
9th PSUR for product
Dec-2016
0016
Type II Variation to update the DDPS (EMEA//H/C/xxx) - Updated during validation
Dec-2016
0015
Type II Variation to update the DDPS (EMEA//H/C/xxx) - Updated during validation
Oct-2016
0014
Type II Variation (Updated DDPS)
Oct-2016
0013
CMC VAR IB product - change in the retest period
Sep-2016
0012
Second Annual Reassessment and 4th PSUR for product
Jun-2016
0011
PSUR
Dec-2015
0010
Type II Variation (Updated DDPS)
Dec-2015
0009
Type IB Notification
Jul-2015
0008
Annual Reassessment
Jun-2015
0007
PSUR
Dec-2014
0006
Response to Specific Obligations
Sep-2014
0005
Pre-Opinion documentation - Letter of Commitment - Responses
Jun-2014
0004
Consolidated Responses
Jun-2014
0003
Responses to List of Outstanding Issues
May-2014
0002
Follow-up Measures
Mar-2014
0001
Responses to List of Outstanding Issues
Feb-2014
0000
MAA
May-2014
Annex 3: Guidance and Best Practice on the
Structure of Module 3
CTD-Quality Considerations for eCTD Submissions in Europe
A3-1 Introduction
This Annex is based on the use of the ICH eCTD specification v3.2. Refer to the Glossary for an
explanation of terms.
The ICH eCTD Specification allows the applicant to manage eCTDs at different levels in Module 3
(please, refer to section 2.2. above). The preference should be one single eCTD application that
covers all strengths of a drug product (invented name). If the applicant needs to have one eCTD
application per strength or dosage form, this should be explained in the cover letter and guidance
should be given there about which documentation that are duplicated in the different eCTDs to
prevent duplicate of work during assessment.
A3-1.1 Terminology in the eCTD modul 3 XML
In addition to documents, eCTD applications provide information in the XML as follows:
Attribute: Defines new sections within the CTD table of contents (e.g. substance,
manufacturer)
Element: The CTD table of content location (e.g. m3-2-s-1-1)
Leaf: eCTD document
Module 3 attributes examples
o m3-2-s-drug-substance: substance, manufacturer
o m3-2-pdrug-product: product-name, dosage form, manufacturer
o m3-2-p-4control-of-excipients: excipient
A3-2 General Principles
These XML attributes describe the quality sections of the eCTD and should be chosen carefully to
present the information provided to the assessor in a clear and unambiguous way. See section
3.4.1 and 3.4.2 in relation to the structure of the drug substance and drug product modules.
A3-2.1 Document Granularity
eCTD applications can handle different authoring strategies for CTD-Q information. For any given
CTD-Q topic (e.g., P.1 Description and Composition of the Drug Product), either a single document
can be provided that covers multiple strengths, or multiple documents can be provided, e.g. per
strength. Regardless of the XML attributes, when there are significant differences in content it is
best practice to provide multiple documents, to realise the lifecycle benefit that eCTD offers. When
deciding on the strategy for the single- or multiple-document approach applicants should also take
into consideration the ability of the assessor to review the content. If there are multiple files in the
same element, the title of each leaf should be used to distinguish the scope of each documents
content, and the var part of the filename used to differentiate each PDF document.
A3-2.2 Identifying to an Agency what the Application covers
Generally speaking, a single eCTD application is submitted for all strengths and forms under one
tradename. In Europe, the applicant cannot cross-refer from one eCTD to another (e.g., for drug
substance).
A3-2.2.1 Centralised Procedures
For the Centralised Procedure, a single eCTD application should always cover all strengths and
dosage forms within the procedure. A duplicate must always be submitted and maintained as a
separate individual eCTD application.
A3-2.2.2 MR and DC Procedures
In MRP/DCP, a single eCTD is needed per procedure that covers all involved MSs, regardless of
differences in the invented name in the different countries. However, different dosage forms or
strengths can be managed in separate eCTDs at the applicant’s discretion, even if one combined
eCTD is preferred. Applicants should carefully consider what an eCTD application will cover before
submitting the first sequence.
A3-2.2.3 EU Envelope
The Module 1 EU envelope provides the trade name (invented name) of the drug product. The
tracking number element, which is repeatable, may list all of the product licences or application
numbers covered by the eCTD. Applicants should ensure that the values for invented name, INN
Applicant and Application Number in the EU envelope are complete and consistent. Note: The
Application Number and INN may not be known at the time of the first submission and may have
to be substituted in later sequences.
A3-3 Module 3 XML Attributes in the eCTD
A3-3.1 Choosing Module 3 XML Attributes
The XML attributes reflect the document granularity used in Module 3. The actual words for the
attributes need not be an exact match of the words used in the content of Module 3 documents,
but should clearly describe the content in that specific section of the dossier. More than one entry
for any attribute generally results in the replication of the relevant portion of both the XML and the
folder architecture, (e.g., 3.2.S Drug Substance, 3.2.P Drug Product, 3.2.P.4 Control of Excipients,
3.2.A.1 Facilities and Equipment, 3.2.A.2 Adventitious Agents Safety Evaluation, 3.2.A.3
Excipients).
Module 3 XML attributes cannot be changed with later submissions within the same application
without losing the lifecycle benefit that eCTD offers. For example, if an applicant builds an eCTD
with ABC Chemical as the manufacturer of the drug substance, and subsequently changes drug
substance manufacturer to XYZ Chemical, they would normally provide a new eCTD sequence
with XYZ Chemical as an additional module 3 XML attribute. It will not be possible to have content
in the XYZ Chemical section that replaces or appends to content in the ABC Chemical section.
This is because in the eCTD it is not possible to apply lifecycle across different sections. However,
it will be possible to delete some or all of the content within the ABC Chemical section, if required.
A3-3.2 Drug Substance (32s) Attributes
The use of these attributes is mandatory. Refer to ICH eCTD Q&As #65-70 for guidance.(Change
control section at bottom of page).
A3-3.2.1 Example One Drug Substance, two Drug Substance Manufacturers, two
Finished Product Manufacturers, one Dosage Form
In this example, there are two drug substance manufacturers, which each hold an ASMF on the
drug substance. The MAH/Applicant should create three drug substance modules in their eCTD
dossier:
- The Applicant’s part of ASMF 1 in one drug substance module (m32S section).
- The Applicant’s part of ASMF 2 in one drug substance module (m32S section).
- The Applicant’s control of the active substance in one drug substance module (m32S section),
which covers both sources of the drug substance.
The drug product module should be compiled covering both finished product manufacturers i.e.
there should only be one drug product module:
- Drug product (m32P section)
Drug substance:
INN
Finished product:
INVENTED NAME 400 mg film-coated tablets
Drug substance
manufacturers:
Y (ASMF holder 1)
X (ASMF holder 2)
Finished product
manufacturer:
Z and A
m3-quality
m3-2-body-of-data
m3-2-s-drug-substance [manufacturer: X] [substance: INN]
m3-2-s-drug-substance [manufacturer: Y] [substance: INN]
m3-2-s-drug-substance [manufacturer: Applicant] [substance: INN]
m3-2-p-drug-product [manufacturer: All] [product name: INN] [dosage
form: 400-mg-FCT]
The manufacturer of the drug product is stated as “all” as the documentation is compiled and
covers all drug product manufacturers of this specific dosage form.
A3-3.3 Drug Product (32p) Product/Dosage Form/Manufacturer
The use of these attributes is optional. Refer to IICH eCTD Q&As #68, 69 and 70 for guidance.
A3-3.3.1 Drug Product Name
Since the M1 EU envelope contains the invented name, it is not necessary to use this name in the
product name XML attribute that is used in Module 3. Applicants should take into consideration that
trade names can occasionally change over time. If the trade name is not well established,
applicants should consider alternatives such as ‘active’, or ‘product. Alternatively, the internal
company code of the drug product name may be used. If applicable, additional attributes can be
used as needed (e.g. ‘diluent’ or placebo’).
This attribute then results in a full set of 3.2.P.1 to 3.2.P.8 XML elements and folders.
A3-3.3.2 Dosage Form
In conjunction with the above product name, each additional dosage form entry results in an
additional full set of 3.2.P.1 to 3.2.P.8 XML elements and folders. When deciding on the degree of
detail (e.g., ‘tablet’ vs. film-coated tablet’, 'f rozen" vs. "refrigerated" f ormulation for vaccines),
consider the potential for future line extensions and the proportion of drug product documents that
could be re-used. If that proportion is small, then consider an initial specific dosage form entry, e.g.
‘film-coated tabletrather than ‘tablet.
Strength(s) need not be mentioned in the attribute. Not all 3.2.P documents are, nor need to be,
strength dependent. For example, for a common granulation for six strengths, many documents
would have nearly identical content; little benefit would be derived from having strength-specific
documentation. However, if there is a chance that some strength(s) may not be approved or may
be later handled in another eCTD application, then some CTD topics might benefit in having
separate leaves per strength (e.g.3.2.P.5.1 Specification).
A3-3.3.3 Drug Product Manufacturer
Normally, there should only be one drug product manufacturer section in an eCTD dossier. A
general term f or the attribute such as ‘all’ or ‘applicant’ is acceptable.
However, for some product types, e.g. biotechnological products, there might be relevant to have
multiple drug product manufacturer sections. If used and in conjunction with the above product
name and dosage form, each manufacturer entry results in a set of 3.2.P.1 to 3.2.P.8, 3.2.A.1 or
3.2.A.2 XML elements with appropriate directory folders.
A3-3.4 Excipients
The use of these attributes is optional. Detailed guidance is provided in the ICH eCTD IWG
Question and Answer and Specification Change Request Document, Q&A #72-75 (link in previous
section)
A3-3.4.1 Excipients of Human or Animal Origin and Novel Excipients
Content under sections 3.2.P.4.5 & 3.2.P.4.6 should be provided under an additional attribute such
as ‘animal-human-novel’, refer to ICH eCTD Q&A #73. Note, the files provided under this section
should not be in a subfolder to the 32p4-contr-excip folder in the directory structure. Refer to the
‘File and Folder Structure Names worksheet in the eCTD validation rules.
Annex 4 Management of Parallel Variations in the eCTD
A4-1 Background
Parallel variations are variations on-going 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 annex presents the recommended approach for managing parallel variations in accordance
with the ICH and EU eCTD Specifications.
A4-2 Business Challenge
Parallel variations occur when more than one variation is submitted modifying the same approved
content, the first of which has not been approved before the next is submitted. Upon approval of
one of the variations, the approved content has changed. The remaining pending variations contain
proposed content that may be based upon the originally approved content or on the newly approved
content. The applicant must track each separate approval and update the content for each pending
variation.
The specific challenges associated with this sequence of events are as follows:
(i) Tracking the approved content
(ii) Tracking separate on-going variations
(iii) Tracking individual or combined approvals for each variation
A4-3 Best Practice
Two options are described in this Q&A. Option 1 is the classic approach to eCTD lifecycle
management, where a single document is replaced by a different, updated version, at the initial
submission. Option 2 involves leaving the ‘approvedcontent in the eCTD, but introducing
‘proposed’ documents into the lifecycle, until the outcome of the assessment is clear, and only then
replacing the original approvedcontent. This Q&A can provide no guidance on when to use the
technique described in option 2, and when to assume that a variation is not happening in parallel,
and therefore to use option 1, submitting the proposed content as a leaf with the replace’ operation
attribute. Applicants need to consider whether or not it would be appropriate to use the one or the
other option outlined in this guidance on a case-by-case basis.
A4-4 Description of Figures
MAA
0000 (related
sequence none)
Leaf Title (Operation Attribute)
0001(related
sequence none)
Leaf Title (Operation Attribute)
eCTD Viewer Current View
0000
Document 1 (New) (0000)
Figure 2 (A4): Description of elements
A4-4.1 Use of one Lifecycle (Option 1)
This option describes the classic eCTD lifecycle management approach, where existing content is
replaced with revised content. When there is only one change and variations do not occur in
parallel, and the change is approved, the advantage of this approach is that applicants do not have
to follow up with another ‘consolidation’ sequence after approval, because they have already
replaced the content and the current view of the eCTD will be correct.
Figure 3 (A4) : Use of one document lifecycle
MAA & Variations
0000 (MAA) (related
sequence none)
Document 1 (New)
0001 (Variation 1)
(related sequence none)
Document 1 Proposal 1 (replace)
0002 (Variation 2)
(related sequence none)
Document 1 Proposal 2 (replace)
eCTD Viewer Current View
0000
Document 1 (New) (0000)
0000 - 0001
Document 1 Proposal 1 (replace) (0001)
0000 - 0002
Document 1 Proposal 2 (replace) (0002)
A4-4.1.1 Drawbacks of Option 1
Approval Status and Clarity on the Basis for Further Changes
If option 1 is used, and the most recently submitted document is replaced, regardless of its
regulatory status, then it becomes unclear what has been approved, and therefore what the
How the sequences would
appear in an eCTD Viewer in
current view’
Note other views may be available,
for example, a regulatory activity view
Sequence numbers, with
related sequence in
brackets
eCTD Leaf Title Attribute and
Operation Attribute in brackets
The red cross indicates the
target of the modified file
changes in the incoming new submission are based upon. In this example, it is unclear whether
Proposal 2 is based on the content from Proposal 1 or the content from the original Document 1 in
sequence 0000. Therefore, when using this approach, if a second variation is submitted before the
first is finalised, applicants should specify which document the changes in the second variation are
based on.
Impact of Regulatory Outcome
If the operation attribute ‘replace’ is used in each variation as described in Figure 1, then depending
on the progress of the review/approval/rejection of each variation, the eCTD lifecycle may not
correctly represent the current or most appropriate lifecycle. For example, if variation 2 were to be
approved first, the documentation of variation 1 where changes were based on the content in
sequence 0001 may no longer be displayed appropriately. If variation 1 is rejected, and variation 2
was based on changes versus the content in variation 1, the content of variation 2 might be difficult
to evaluate.
If either variation 1 or 2 (or both) is rejected, a new sequence has to be submitted reflecting only
the approved content.
One advantage of this approach is that if both variations are approved, no additional sequence has
to be submitted.
A4-4.2 Creation of separate Approved and Proposed Document Lifecycles
(Option 2)
This option can be used in any situation where parallel variations are expected, but this is
specifically recommended when submitting labelling changes in the Centralised Procedure, and
the terminology used here is therefore specific to the SmPC in Centralised applications. When an
applicant expects parallel variations to be submitted, the proposed document for the variation is not
submitted as a replacement of the original (approved) content. Instead of using operation attribute
"replace", a new document lifecycle is created for each proposed document by submitting it with a
title identifying its proposed status and a very brief description of the change being proposed, and
an operation attribute of new. Proposed content submitted in this way can only be submitted as a
new document or replace other proposed content in the same location. The approved content in
this CTD section has a separate lifecycle, and has a title indicating it is the approved document.
This means that eCTD viewing tools will allow viewing of both the approved and proposed content
alongside each other in the eCTD “current view. Specifically, for the m1.3.1 section of the dossier
in the Centralised Procedure ‘approveddocuments are labelled with either ‘Final Opinionor
‘Commission Decision’ in the leaf title, depending on the stage of the review that resulted in the
final agreed labelling. Variations are then submitted as new documents, not replacing this
approved content, with appropriately descriptive leaf titles, for example, Type II Variation Section
4.4 Update June 2020 - Proposed.
A4-4.2.1 Addition of further proposed Document Lifecycles (parallel variations)
If, during the review of the first variation, there is a subsequent variation that also proposes changes
to the same content, this is also submitted with an operation attribute of “new”, and a title indicating
that the document being provided is another proposal. The document submitted in the second
proposal should reflect changes made versus the current approved document (in this example, the
current decision); the document does not contain the changes from Variation 1. The leaf title should
differentiate it from the former proposed document from the previous variation. Assigning
descriptive title attributes will allow the proposed document in each variation to be identified by
viewing tools displaying the “current” view.
Figure 3 illustrates how the currentview is able to display each of two parallel variations, when
the title attribute is specific to the variation and the operation attribute “newis used as described.
Figure 4 (A4) : Use of separate document lifecycles with different title attributes
Original MAA
Final Opinion or
Decision Only
Variation 1
Variation 2
0000
(rel sequence
none)
Proposed SmPC
(New)
0001
(rel sequence
0000)
RTQ 120 changes
to SmPC
(Replace)
0002
(rel sequence
0000)
RTQ 180 changes
to SmPC
(Replace)
0003
(rel sequence
0000)
SmPC (English)
Decision Jan
2020 (Replace)
0004
(rel sequence
none)
Type II Variation
Section 4.4
Update June 2020
- Proposed (New)
0005
(rel sequence
none)
Type II Variation
Section 4.6
Update July 2020
- Proposed (New)
eCTD Viewer Current View
0000
Proposed SmPC (New) (0000)
0000 - 0001
RTQ 120 changes to SmPC (Replace) (0001)
0000 - 0002
RTQ 180 changes to SmPC (Replace) (0002)
0000 - 0003
SmPC (English) Decision Jan 2020 (Replace) (0003)
0000 - 0004
SmPC (English) Decision Jan 2020 (Replace) (0003)
Type II Variation Section 4.4 Update June 2020 Proposed (New) (0004)
0000-0005
SmPC (English) Decision Jan 2020 (Replace) (0003)
Type II Variation Section 4.4 Update June 2020 Proposed (New) (0004)
Type II Variation Section 4.6 Update July 2020 - Proposed (New) (0005)
A4-4.2.2 Upon Approval of a Single Variation Deletion and Replacement
Upon approval of any variation, the proposed content is deleted, and the original (approved) content
is replaced with a document containing the revised content. Current view will then show the newly
approved content, but also any outstanding proposals, as shown in Figure 4and Figure 5. This
additional sequence should be considered part of the same regulatory activity as the proposal that
has been approved.
Figure 5 (A4) : Replacement of approved content by newly approved content, and deletion
of proposed content
In this example, commission decision received in December 2020 incorporates the changes from
the Type II variation submitted in sequence 0004 only. The changes from the Type II variation in
sequence 0005 are still under review. In sequence 0006, the ‘proposedlabel from the first variation
is deleted and the new commission decision is provided, replacing the original commission decision
from sequence 0003. The content of the second variation is also amended in sequence 0006, to
reflect the newly approved content in section 4.4, alongside the still unapproved change in section
4.6, and left in the lifecycle as an outstanding proposal.
MAA
Final Opinion or
Decision Only
Variation 1
Variation 2
0003
(rel sequence
0000)
SmPC (English)
Decision Jan 2020
(Replace)
0004
(rel sequence
none)
Type II Variation
Section 4.4 Update
June 2020 -
Proposed (New)
0005
(related sequence
none)
Type II Variation
Section 4.6 Update
July 2020 -
Proposed (New)
0006
(rel sequence
0004, 0005)
SmPC (English)
Decision Dec
2020 (Replace)
Type II Variation
Section 4.4 Update
June 2020 -
Proposed (Delete)
Type II Variation
Section 4.6
+ inclusion of
approved Type II
Variation Section
4.4
Update Dec 2020
Proposed (Replace)
eCTD Viewer Current View
0000 - 0005
SmPC (English) Decision Jan 2020 (Replace) (0003)
Type II Variation Section 4.4 Update June 2020 - Proposed (New) (0004)
Type II Variation Section 4.6 Update July 2020 - Proposed (New) (0005)
0000 - 0006
SmPC (English) Decision Dec 2020 (Replace) (0006)
Type II Variation Section 4.6 Update Dec 2020 - Proposed (Replace)
(0006)
Figure 6 (A4): Progression on the 2nd Parallel Proposal
In this example, as the procedure progresses, the proposed change to section 4.6 needs to be
further amended as a result of the regulatory review (e.g. updated wording as suggested by the
assessor), and this amendment is done with a replacement document in sequence 0007. Once a
decision is reached, another sequence, 0008, is submitted, including the new decision replacing
the one submitted in sequence 0006, and a deletion of the section 4.6 proposal, as amended by
sequence 0007.
MAA
Final Opinion or
Decision Only
Variation 1
Variation 2
0003
(rel sequence
0000)
SmPC (English)
Decision Jan 2020
(Replace)
0004
(relsequence
none)
Type II Variation
Section 4.4 Update
June 2020 -
Proposed (New)
0005
(rel sequence
none)
Type II Variation
Section 4.6 Update
July 2020 - Proposed
(New)
0006
(rel sequence
0004, 0005)
SmPC (English)
Decision Dec 2020
(Replace)
Type II Variation
Section 4.4 Update
June 2020 -
Proposed (Delete)
Type II Variation
Section 4.6
+ inclusion of
approved Type II
Variation Section 4.4
Update Dec 2020
Proposed (Replace)
0007
(rel sequence
0005)
Type II Variation
Section 4.6 +
inclusion of
approved Type II
Variation Section 4.4
Update January
2021 Proposed
(Replace)
0008
(rel sequence
0005)
SmPC (English)
Decision
Mar 2021
(Replace)
Type II Variation
Section 4.6 +
inclusion of
approved Type II
Variation Section 4.4
Update January
2021 Proposed
(Delete)
eCTD Viewer Current View
0000 - 0006
SmPC (English) Decision Dec 2020 (Replace) (0006)
Type II Variation Section 4.6 Update Dec 2020 - Proposed (Replace) (0006)
0000 - 0007
SmPC (English) Decision Dec 2020 (Replace) (0006)
Type II Variation Section 4.6 Update Jan 2021 - Proposed (Replace) (0007)
0000-0008
SmPC (English) Decision Mar 2021 (Replace) (0008)
A4-4.2.3 Approval of Multiple Variations at the Same Time
There will be occasions where multiple changes are approved at the same time, or within a very
short time period. In these instances, it would not be appropriate to submit separate ‘approved’
content for each variation; instead, a consolidated document representing all the approved changes
should be submitted. This would replace the existing ‘approved content. The eCTD sequence
containing the new approved content would also contain leaves deleting the relevant ‘proposed’
documents, as illustrated in Figure 5.
Figure 7 (A4): Replacement of approved content by newly approved content, and deletion
of multiple proposed documents
In this example, commission decision received in December 2020 incorporates the changes from
the Type II variation submitted in sequence 0004, and also the changes from the Type II variation
in sequence 0005. In sequence 0006, both proposeddocuments from the variations are deleted
and the new commission decision is provided, replacing the original commission decision from
sequence 0003. This leaves only the latest commission decision from sequence 0006 in the current
view. While creating a combined closing sequence covering multiple commission decisions is
allowed, adding other regulatory activities into this closing sequence, e.g. to include a consolidation,
is not acceptable.
MAA
Final Opinion
or Decision
Only
Variation 1
Variation 2
0003
(related sequence
0000)
SmPC (English)
Decision Jan
2020 (Replace)
0004
(related sequence
none)
Type II Variation
Section 4.4
Update June 2020
- Proposed (New)
0005
(related sequence
none)
Type II Variation
Section 4.6 Update
July 2020 - Proposed
(New)
0006
(related sequence
0004 & 0005)
SmPC (English)
Decision Dec
2020 (Replace)
Type II Variation
Section 4.4
Update June 2020
- Proposed
(Delete)
Type II Variation
Section 4.6 Update
July 2020 - Proposed
(Delete)
eCTD Viewer Current View
0000 - 0005
SmPC (English) Decision Jan 2020 (Replace) (0003)
Type II Variation Section 4.4 Update June 2020 - Proposed (New)
Type II Variation Section 4.6 Update July 2020 - Proposed (New)
0000 - 0006
SmPC (English) Decision Dec 2020 (Replace)
A4-4.2.4 Rejections or Withdrawals
If any proposed changes are rejected or withdrawn by the applicant, then the applicant can provide
a sequence deleting the “proposed content document, but not providing any replacement for the
original approved document.
A4-4.2.5 Typical Applications
An applicant is most likely to need to submit parallel variations on dossier content that changes
more often, such as the SmPC or the Risk Management Plan (RMP
i
). However, this guidance is
not limited to use in these parts of the dossier. Applicants should also note that many variations
affecting the SmPC and RMP will not occur in parallel with another variation, and at times, when a
variation is initially expected to be completed in isolation, a second parallel variation may become
necessary at a later stage.
Document Control
Change Record
Version
Author(s)
Comments
1.0
TIGes eCTD guidance
topic group
This document has been prepared by the eCTD Guidance Topic Group of the
TIGes. It is largely based on the NeeS guidance document 1.4.
1.1
TIGes Harmonisation
Group/ GW, AN, KG,
KM
First draft for revision, made the document in line with agreed text in the
NeeS guidance and with the New validation criteria, TIGes Harmonisation
group 110309
1.2-1.93
AN, KG, MC, KM, BT,
KP
Further revisions by TIGes Harmonisation group TC meetings in April-July
2011
1.94
KG
Further revision after TIGes comments and minor update in accordance with
EU M1 eCTD specification draft v.1.4.1.
2.0
KG, AN
Following review of TIGes comments and final updates at subgroup TC
meeting in August. Final document for TIGes adoption and publication.
2.1-
TIGes Harmonisation
Group// KG, AN
Draft for Second revision, made the document in line with agreed text on
Q&A, EU M1 Spec v2.0, and in the NeeS guidance and with the updated
validation criteria, TIGes Harmonisation group 12/2012-07/2013
2.7
AN, KM
Following review comments edits have been included.
3.0
3.1
AN, KM, KG, KP
Preparing the revision to accommodate regulatory changes, improvements and
clarifications, editions due to inconsistencies caused by revisions of the EU
M1 spec. v3.0, eCTD validation criteria 6.0, eAF usage and further
modifications
3.2
KM
Consolidating all changes and formatting modifications
3.3
HHMG
Reviewing modified sections and tiding up comments
3.4
KM
Preparation for publication
4.1-4.14
HHG members//KG
Preparing for update to a more current version and to reflect new EU M1
eCTD specification and Q&As that have been published since the latest
update 2016.
4.15
KG and HHG members
Final draft after CMDh comments. Sent for final review by the eSubmission
Expert Group before adoption.
5.0
KG
Cleaned final version for adoption. No content changes from 4.15.
Reviewers
Version
Name
Organisation / action
1.0
TIGes
TIGes eCTD Topic Group
1.1-1.92
Members of the subgroup
TIGes Harmonisation group
1.93
Members of TIGes
TIGes
1.94
Members of the subgroup
TIGes Harmonisation group
2.0
Members of subgroup And the TIGes
TIGes for adoption
2.6
Members of the TIGes
TIGes for adoption as v.3.0
3.1
Members of HHMG
Human Harmonisation Maintenance Group
3.2
EMA
EMA
3.3
The members of the HHMG and the
eSubmission CMB
Human Harmonisation Maintenance Group
eSubmission Change Management Board
4.0
The members of the eSubmission
CMB
eSub CMB for adoption
4.1-4.14
Drafted and reviewed by members of
the HHG
Human Harmonisation Group for drafting and seek input from
their organisations
4.09
The members of the eSubmission
Expert group
eSubmission Expert group for review/comments
4.14
The delegates in CMDh
CMDh for review/comments
4.15
The members of the HHG
Human Harmonisation Maintenance Group updates due to
received CMDh comments. Finalising the draft.
4.15
The members of the eSubmission
Expert group
eSubmission Expert group for final review before adoption.
4.15 / 5.0
All members of the eSubmission
Expert group
eSubmission Expert Group for adoption (4.15 as cleaned, final
version)
Distribution
Version
Distributed to
Way of distribution
1.0
General public
Published on the EMA eSubmission website
1.1-1.92
Members of the Subgroup
E-mail April-July 2011
1.93
Members of the Subgroup and
Members of TIGes
E-mail July 2011
1.94
Members of the Subgroup
E-mail August 2011
2.0
Members of the Subgroup and
Members of TIGes
E-mail August 2011
3.0
Members of TIGes
E-mail August 2013
3.1
eSubmission CMB
E-mail December 2015
3.4
eSubmission CMB
E-mail March 2016
4.0
eSubmission CMB
E-mail April 2016
4.1-4.14
HHG
Continuous email conversations 2021
4.9
eSubmission Expert Group
E-mail August 2021
4.14
CMDh
E-mail October 2021
4.15
HHG
E-mail November 2021 (final including comments)
4.15
eSubmission Expert Group
E-mail December 2021
5.0
eSubmission Expert Group
E-mail December 2021 (final version for adoption)
Coming into Operation
Version
Date in operation
Comment
1.0
May 2009
This document is specifically called a “Draft for Testing”. The Topic Group
fully anticipate comments from NCAs and applicants which will enable future
versions to reflect practical experience of users. In this way the document will
evolve to become an essential work of reference in this area.
2.0
1 September 2011
Published at the EMA eSubmission website for use
3.0
2 September 2013
Published at the EMA eSubmission website for use
4.0
1 July 2016
Published at the EMA eSubmission website for use
5.0
1 February 2022
Published at the EMA eSubmission website end of December