Harmonised Technical Guidance for eCTD Submissions in the EU

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 
 INTRODUCTION...................................................................................................................6 
1  GLOSSARY .............................................................................................................................. 7 
 GENERAL CONSIDERATIONS .............................................................................................8 
1  SCOPE .................................................................................................................................... 8 
1.1  Types of Product ............................................................................................................8 
1.2  Types of Submission.......................................................................................................8 
1.3  Types of Submission Units ..............................................................................................8 
1.4  Types of Procedures .......................................................................................................8 
1.5  Exceptions ....................................................................................................................8 
2  STRUCTURE OF SUBMISSIONS.................................................................................................... 8 
3  TRANSITIONAL ARRANGEMENTS............................................................................................... 9 
4  CHANGE TO ECTD FORMAT ..................................................................................................... 9 
5  GENERAL SUBMISSION CONSIDERATIONS ................................................................................ 10 
5.1  Document Granularity................................................................................................... 10 
5.2  File Naming ................................................................................................................ 10 
5.3  Placement of Documents ............................................................................................... 10 
6  CORRESPONDENCE ................................................................................................................ 10 
7  PAPER REQUIREMENTS .......................................................................................................... 11 
8  HARDWARE........................................................................................................................... 11 
9  GENERAL TECHNICAL ECTD INFORMATION ............................................................................ 11 
9.1  Identifier for Applications.............................................................................................. 11 
9.2  File Formats ................................................................................................................ 11 
9.3  Portable Document Format (PDF)................................................................................... 11 
9.4  Sequence Numbers ....................................................................................................... 12 
9.5  Related Sequence ......................................................................................................... 12 
9.6  Leaf Lifecycle Operation Attributes ................................................................................ 13 
9.7  Bookmarks and Hypertext Links..................................................................................... 15 
9.8  Node Extensions .......................................................................................................... 15 
9.9  Extensible Mark-up Language (XML) ............................................................................. 15 
9.10  Other File Formats ....................................................................................................... 15 
9.11  Technical Validation of eCTD Submissions ..................................................................... 16 
10  OTHER TECHNICAL INFORMATION ...................................................................................... 17 
10.1  Protection against Malware ............................................................................................ 17 
10.2  Security Settings .......................................................................................................... 17 
10.3  Signatures ................................................................................................................... 17 
11  TECHNICAL BASELINE APPLICATIONS ................................................................................. 18 
11.1  Baselines Starting as Sequence 0000 ............................................................................... 18 
11.2  Baselines Starting Later in Lifecycle ............................................................................... 18 
11.3  Re-Baselining a Broken eCTD Lifecycle ......................................................................... 19 
12  PROCEDURE FOR SENDING ELECTRONIC INFORMATION ........................................................ 21 
12.1  Portals/Gateways.......................................................................................................... 21 

Page 3 of 56 
 
 
12.2  CD / DVD................................................................................................................... 22 
12.4  EudraLink / e-Mail (where applicable)............................................................................. 22 
 MODULE SPECIFIC INFORMATION ................................................................................. 23 
1  GENERAL INFORMATION ........................................................................................................ 23 
2  MODULE 1 ECTD ENVELOPE, ADMINISTRATIVE  INFORMATION AND PRESCRIBING  INFORMATION 
FOLDER ...................................................................................................................................... 23 
2.1  General Considerations ................................................................................................. 23 
2.2  Creation and Management of Envelope Information .......................................................... 23 
2.3  Module 1.0 Containing Cover Letter and Tracking Table.................................................... 24 
2.4  Application Forms........................................................................................................ 25 
2.5  Product information ...................................................................................................... 25 
2.6  Use of Response Documents Section ............................................................................... 25 
2.7  Use of the Additional Data Section ................................................................................. 26 
3  MODULE 2 OVERVIEWS AND SUMMARIES FOLDER.................................................................... 26 
3.1  General Considerations ................................................................................................. 26 
3.2  Structure of Module 2 Documents................................................................................... 26 
4  MODULE 3 QUALITY FOLDER ................................................................................................. 27 
4.1  Module 32S drug substance ........................................................................................... 27 
4.2  Module 32p drug product .............................................................................................. 28 
5  MODULE 4 NONCLINICAL STUDY REPORTS FOLDER ................................................................. 29 
5.1  Guidance on the Handling of Granular Study Reports ........................................................ 29 
6  MODULE 5 CLINICAL STUDY REPORTS FOLDER ....................................................................... 30 
6.1  Management and Handling of Multiple Indications............................................................ 30 
6.2  Management and Handling of Granular Clinical Study Reports ........................................... 30 
6.3  Provision of CRFs and Data when Requested ................................................................... 30 
6.4  Provision of Synopses of Individual Studies ..................................................................... 30 
6.5   Company Core Data Sheet ............................................................................................. 30 
 ADVICE ON SPECIFIC APPLICATION TYPES ................................................................... 31 
1  NEW MA APPLICATIONS ........................................................................................................ 31 
2  VARIATION APPLICATIONS ..................................................................................................... 32 
3  EXTENSION SUBMISSIONS ....................................................................................................... 34 
4  RENEWAL SUBMISSIONS ......................................................................................................... 34 
5  PSURS.................................................................................................................................. 35 
6  REFERRALS........................................................................................................................... 37 
6.1  CMDh referrals related to MRP/DCP/RUP....................................................................... 37 
6.2  EMA-led referral procedures.......................................................................................... 37 
7  ACTIVE SUBSTANCE MASTER FILES ........................................................................................ 37 
8  VACCINE ANTIGEN MASTER FILES.......................................................................................... 38 
9  PLASMA MASTER FILES (PMFS) AND MEDICINAL PRODUCTS CONTAINING PMFS ........................ 38 
9.1  Plasma Master Files...................................................................................................... 38 
9.2  Medicinal products containing PMFs............................................................................... 38 
10  APPLICANT INITIATED  WITHDRAWALS  OF THE MA OR CERTAIN  STRENGTHS OR DOSAGE FORMS

11  APPLICANT WITHDRAWAL  OR AGENCY REJECTIONS OF POST-AUTHORISATION REGULATORY 
ACTIVITIES ................................................................................................................................. 39 
12  PUBLICATION OF CLINICAL DATA FOR MEDICINAL PRODUCTS .............................................. 39 
13  DUPLICATE APPLICATIONS ................................................................................................. 39 
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 “new” NCA , 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 & Names” work 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 procedures’ for 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

Submission Type

Sequence

Submission

Unit

0008

PSUR single assessment

procedure

psusa

0008

initial

Page 13 of 56

0009

Validation update

psusa

0008

validation-

response

0010

Comments on Assessment

Report

psusa

0008

response

Table 2 : Example of a Referral for CAPs

Sequence

number

Submission Description

Submission Type

Sequence

Submission

Unit

0008

Responses to LoQ

referral

none

initial

0009

Comments on Assessment

Report

referral

0008

validation-

response

0010

Responses to LoOI

referral

0008

response

Table 3 : Example of a Referral for NAPs

Sequence

number

Submission Description

Submission Type

Sequence

Submission

Unit

0008

Responses to LoQ

referral

none

initial

0009

Comments on Assessment

Report

referral

0008

validation-

response

0010

Responses to LoOI

referral

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 ‘grouped’ as

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 ‘abcd’ and substance ‘xyz’ section.

• 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 1234’ should 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 1234’ in 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 “new” leaf 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-workingdocuments” on 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 ‘success’ or

‘failure’ acknowledgement 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

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

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 “ZZ” if

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 procedures’ and ‘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’, ‘grouping’ or ‘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 ‘applicant’ should 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 NCA’s 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 manufacturer’s 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 manufacturer’s 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.Applicant’s 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 Applicant’s

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 Efficacy” module 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 “new” and 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 +

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

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/DCP’ can 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 “psur” for ‘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 Applicant’s 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-p–drug-product: product-name, dosage form, manufacturer

o m3-2-p-4–control-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 document’s

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 tablet’ rather 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 ‘approved’ content in the eCTD, but introducing

‘proposed’ documents into the lifecycle, until the outcome of the assessment is clear, and only then

replacing the original ‘approved’ content. 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 ‘approved’ documents are labelled with either ‘Final Opinion’ or

‘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 “current” view is able to display each of two parallel variations, when

the title attribute is specific to the variation and the operation attribute “new” is 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 ‘proposed’ label 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 ‘proposed’ documents 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

). 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,

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,

Further revisions by TIGes Harmonisation group TC meetings in April-July

2011

1.94

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

Consolidating all changes and formatting modifications

3.3

HHMG

Reviewing modified sections and tiding up comments

3.4

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

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

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