eCTD Guidance Document

DRAFT FOR TESTING

Guidance for Industry on Providing Regulatory

Information in Electronic Format:

eCTD electronic Submissions

This document is published under the auspices of the

EU Telematic Implementation Group - electronic submissions (TIGes)

Please note that this document is being published on the EMEA eSubmission

website so that both agencies and applicants can gain practical experience of

building, submitting and receiving eCTDs.

The Topic Group consider that through this process we will gain valuable

experience of what works and what additional information is required to ensure

that eCTDs become the de facto submission standard across the EU.

Version 1.0

May 2009

Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD Applications

Version: 1.0 May 2009

Page 1 of 41

Document Control

Change Record

Version Author(s) Comments

1.0 eCTD 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.

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.

Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD Applications

Version: 1.0 May 2009

Page 2 of 41

Table of Contents

1. INTRODUCTION ..................................................................................................................4

2. GENERAL CONSIDERATIONS...........................................................................................6

2.1 Scope..................................................................................................................................6

2.2 Structure of submissions ....................................................................................................6

2.3 Transitional arrangements..................................................................................................7

2.4 Moving to eCTD format from paper or NeeS type applications ..........................................7

2.5 General Submission Considerations ..................................................................................7

2.6 Correspondence .................................................................................................................7

2.7 Paper requirements ............................................................................................................8

2.8 Hardware............................................................................................................................8

2.9 General Technical eCTD Information .................................................................................8

2.10 Other Technical Information ...........................................................................................10

2.11 Archiving and working copies .........................................................................................12

2.12 Technical baseline applications......................................................................................12

3. MODULE SPECIFIC INFORMATION ................................................................................13

3.1 General information ..........................................................................................................13

3.2 Module 1 eCTD envelope, administrative information and prescribing information folder13

3.3 Module 2 overviews and summaries folder ......................................................................15

3.4 Module 3 quality folder......................................................................................................15

3.5 Module 4 Nonclinical study reports folder.........................................................................16

3.6 Module 5 clinical study reports folder ...............................................................................16

4. ADVICE ON SPECIFIC APPLICATION TYPES ................................................................18

4.1 Initial MA Applications.......................................................................................................18

4.2 Variation Applications.......................................................................................................18

4.3 Extension Submissions.....................................................................................................20

4.4 Renewal Submissions ......................................................................................................20

4.5 PSURs..............................................................................................................................21

4.6 MR and DCP Applications ................................................................................................21

4.7 Referrals...........................................................................................................................21

4.8 Active Substance Master Files .........................................................................................22

4.9 Vaccine Antigen Master Files ...........................................................................................22

4.10 Plasma Master Files .......................................................................................................22

4.11 Applicant Initiated Action ................................................................................................23

4.12 Duplicate Applications ....................................................................................................23

ANNEX 1 ECTD REFERENCE DOCUMENTS ................................................................................24

ANNEX 2 GUIDANCE ON TEXT SEARCHABLE DOCUMENTS .........................................................25

1. General...............................................................................................................................25

2. Documents that must always be text searchable ...............................................................25

3. Documents that do not need to be text searchable ............................................................26

4. Further Information .............................................................................................................26

ANNEX 3 GUIDANCE AND BEST PRACTICE ON THE STRUCTURE OF MODULE 3 - CTD-QUALITY

CONSIDERATIONS FOR ECTD SUBMISSIONS IN EUROPE ............................................................27

1. Introduction.........................................................................................................................27

2. General Principles ..............................................................................................................27

3. Module 3 XML Attributes in the eCTD ................................................................................30

Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD Applications

Version: 1.0 May 2009

Page 3 of 41

1. INTRODUCTION

In 2005 the Heads of Medicines Agencies agreed that all Member States would be able to accept

eCTD (electronic Common Technical Document) applications, without accompanying paper copies, by

the end of 2009. The benefits of moving to e-working are considered to be:

• Reduction in administrative overheads from less paper movement,

• Reduction of physical archiving space,

• Facilitation of the review process.

This Guidance Document is intended to assist pharmaceutical companies with the submission of

regulatory information in electronic format to the National Competent Authorities (hereinafter referred

to as NCAs) and the European Medicines Agency (hereinafter referred to as EMEA). This document

details the requirements for the submission of eCTD electronic submissions. A separate document,

covering NeeS (Non-eCTD electronic Submissions), has already been published on the EMEA’s

eSubmission website and is available via this

link.

This document has been created by the eGuidance Topic Group, a sub-group of the Telematics

Implementation Group – Electronic Submissions (TIGes), consisting of agency representatives from

Belgium, Denmark, EMEA, France, Germany, Hungary, The Netherlands, Portugal, Sweden and the

United Kingdom, together with industry representatives from EFPIA and EGA. It has also been

endorsed by the TIGes. National Competent Authorities have been strongly recommended to adopt

this guidance as the basis for their dealings with applicants.

It should be stressed that this Guidance Document reflects the current situation and will be regularly

updated in the light of changes in national and/or European legislation together with further experience

gained within NCAs and the EMEA of using information submitted in electronic format. It should be

emphasised that eCTD applications should now be regarded as the principal submission format in the

EU.

This document assumes a certain basic understanding of eCTD applications. A list of background

publications can be found in

Annex 1. Applicants should pay special attention to the recommendations

of the ICH M2 Expert Working Group on the eCTD and the TIGes in the EU. Consolidated

specifications can also be found on the Commission Eudralex

website. International standards

development through ICH, ISO and HL7 will eventually lead to the eCTD becoming part of a wider

group of regulated product submissions, covering medical devices, veterinary products and food

additives as well as medicinal products.

This Guidance Document consists of four parts: Introduction, General Considerations, Module Specific

Information and Advice on Specific Application Types together with associated annexes. In addition

please refer to Chapter 7 of the

Notice to Applicants, Volume 2A for specific NCA requirements.

Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD Applications

Version: 1.0 May 2009

Page 4 of 41

A brief glossary of terms (for the purpose of this document only) is indicated below

Term

Definition

Applicant A pharmaceutical company or its agent that is submitting

information in support of an application.

Applicant’s information Regulatory information submitted by an applicant for, or

to maintain, a marketing authorisation that falls within the

scope of this guidance document.

eCTD application 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

sequences. In the EU an eCTD application may comprise

several dosage

forms and 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. Some

review tools describe such a collection as a dossier.

Procedure A Community registration procedure for the authorisation

of medicinal products in the European Community. There

are 4 types of procedure that operate within the EC –

Centralised, Decentralised, Mutual Recognition and

National.

Submission or Sequence A single set of information and/or electronic documents

supplied at one particular time by the applicant as a part

of, or the complete, eCTD Application. In the context of

eCTD, this is equivalent to a sequence.

Regulatory activity A collection of sequences covering the start to the end of

a specific business process, e.g. an initial MA application

or Type II variation. It is a concept used in some review

tools to group together several business related

sequences.

Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD Applications

Version: 1.0 May 2009

Page 5 of 41

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 and the EMEA. This includes prescription, over the

counter medicines, innovative and generic product submissions. The product types include small

molecules, biotech products, herbals, vaccines, homeopathics and 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, variations, renewals, PSURs, active substance

master files.

2.1.3 Types of procedures

This guidance covers applications made in any of the applicable Community procedures (National,

Mutual Recognition, Decentralised and Centralised).

2.1.4 Exceptions

This guidance does not apply to the electronic submission of pre-MA information such as scientific

advice, clinical trial applications and related submission correspondence.

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 docs

Annex 1 contains links to the currently approved version of these documents.

Typically, an eCTD application will cover all dosage forms and strengths of a product with any one

invented name. In the centralised procedure, this will be equivalent to all dosage forms and strengths

covered by an EMEA application number (e.g. EMEA/H/123). In MRP/DCP, a single eCTD application

should preferably be used for the procedure. 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 should be considered. Applicants should carefully consider what an

eCTD application should cover before submitting the first sequence, as the choice could have

implications for workload for the 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 no longer be possible if very good reasons are not presented for a change over. In

these rare cases, please contact the NCA/RMS/EMEA concerned at an early planning stage.

For further details on the pros and cons of the different approaches to dossier structure, see Annex 3,

Table 1.

Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD Applications

Version: 1.0 May 2009

Page 6 of 41

Please check for specific NCA guidance when preparing national eCTDs. .

2.3 Transitional arrangements

The specifications mentioned in section 2.2 above will change over time 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 specification has been agreed and endorsed by the appropriate EU

body, eCTD building tools will need to be updated. Specific transitional guidance will be provided on

each occasion that the ICH and/or EU specifications are updated.

Please note that it should not be necessary to reformat and resubmit previously submitted applications

to reflect such changes.

2.4 Moving to eCTD format from paper or NeeS type applications

An eCTD product life cycle can be started with an initial, variation or renewal MA application. However,

changing to eCTD format should not be performed in the middle of an on-going regulatory activity (i.e.

do not submit responses to questions as an eCTD if the corresponding application to which they relate

has not been submitted as an eCTD).

Where a repeat use procedure in eCTD format is planned, the change of format should be made

before the start of the process.

Where an eCTD application is being used for the first time for a variation or renewal application,

applicants are encouraged to submit a technical baseline for the product as this will greatly aid the

review process. Please see

section 2.12 for further information on the content of baseline applications.

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

specifications.

2.5.2 File Naming

The eCTD file naming conventions described in the ICH M2 eCTD Specification and EU Module 1

Specification are highly recommended. If an applicant wishes to submit multiple files in one section,

where only one highly recommended name is available, this can be achieved using a suffix to the

filename, using the file name-var.pdf convention as described in the EU Module 1 Specification, where

the -var component has no dashes or illegal characters (e.g. pharmaceutical-development-

container.pdf).

2.5.3 Placement of Documents

Guidance on the placement of documents within the eCTD structure for particular submission types

can be found in the

EU-CTD Notice to Applicants and/or in the EMEA post-authorisation guidance for

centralised applications.

2.6 Correspondence

In addition to the eCTD application information may need to be exchanged to assist the processing or

handling of the application. Not all that correspondence should be included in the eCTD. This is

because the eCTD exchange is currently one way only, from applicant to Agency, and not all

correspondence is directly relevant to the application dossier.

Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD Applications

Version: 1.0 May 2009

Page 7 of 41

Accordingly, only the minimum amount of correspondence that relates directly to the content of the

dossier should be included in eCTD submissions to NCAs and the EMEA. All other correspondence

should be exchanged outside the eCTD via the usual electronic means (email, Eudralink etc). Such

documentation is likely to be handled in different ways within the authorities and normally not within the

eCTD review system.

Where correspondence acknowledges the final change to details submitted in the body of the dossier,

the agreement cannot be documented by that correspondence alone. The revised information should

be provided in an accompanying replacement document situated in the appropriate place in the body

of the dossier, with the relevant information contained in a covering letter. See further detailed

information in

section 3.2.3

The eCTD is designed to ensure that users have a current view of the information submitted in the

appropriate place in the dossier at all times.

2.7 Paper requirements

An overview of the requirements for paper and electronic copies is specified for each NCA and EMEA

in the

Notice to Applicants, Volume 2A, Chapter 7.

Guidance on the minimum requirements to produce a paper submission from an eCTD has also been

published in the

Notice to Applicants, Volume 2B

2.8 Hardware

NCAs and the EMEA will not accept any hardware (laptops, desktops, zip 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 EMEA hardware and software.

2.9 General Technical eCTD Information

2.9.1 File formats

In general terms the majority of documents included in electronic submissions should be in PDF

format, file version 1.4 (see next section on the use of later PDF file versions).

The use of XML for applications forms in particular is likely to increase as agency systems develop the

functionality to handle it in their own business processes. See

Section 3.2.4 for further information.

Further detailed guidance on file formats can be found in the ICH eCTD specification document and EU

Module 1 specifications.

2.9.2 Portable Document Format (PDF)

Portable Document Format (PDF) is an open, de facto, electronic publishing standard. 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:

• Files should be legible with Acrobat Reader, version 5.0 or higher.

• Only PDF file version 1.4 should be used, except where there is an agency specific requirement

for a later version for application forms.

• Documents should be generated from electronic source documents and not from scanned

material, except where access to the source electronic file is unavailable or where a signature is

required. See Annex 2 for further guidance on text searchable documents.

Additional details on PDF, including those relating to the good presentation of tables, can be found in

the

ICH eCTD Specification, Appendix 7.

Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD Applications

Version: 1.0 May 2009

Page 8 of 41

2.9.3 Sequence Numbers

Sequence numbers are used to differentiate between different submissions of the same application

over the life cycle of the product. The review tools being used by most NCAs and the EMEA are able

to 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

should normally follow the order of submission of the sequences. A Sequence Tracking Table should

always be included as an annex to the cover letter in every submission within MRP/DCP (see

CMD(h)

recommendations on the cover letter). Specific recommendations for MR and DC Procedures are

given in the CMD(h)

guidance on e-submission. A similar tracking table is recommended for national

applications.

The initial eCTD life cycle submission should normally have a sequence number of 0000. If applicants

consider that there are good reasons to use another number they should explain this in the cover

letter.

As additional data is submitted in response to questions, the sequence number of the submission will

advance, 0001, 0002, etc. Only in the case of a technically invalid submission can a sequence be

replaced with one using the same number, e.g. the initial sequence “0000” will be replaced by another

“0000”.

When starting an eCTD product life cycle at a point other than with an initial MA application, such as a

variation or renewal, the initial eCTD sequence serving as the baseline, should preferably be

numbered as “0000”.

The relationship of one sequence to another is managed using the related sequence number. This

allows sequences to be grouped together that make up an application or a regulatory activity.

2.9.4 Bookmarks and hypertext links

Navigation through an electronic submission is greatly enhanced by the intelligent use of bookmarks

and hypertext links. ICH guidance 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 page document summarising findings could require bookmarks to aid navigation.

However, a 300 page 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 life cycle

management.

Additional details on creating bookmarks and hypertext links in PDF documents can be found in the

ICH eCTD Specification, Appendix 7.

2.9.5 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 EMEA for the Product Information Management (PIM) system and e-

application forms. Please refer to EMEA e-submission website for further details.

Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD Applications

Version: 1.0 May 2009

Page 9 of 41

2.9.6 Other File Formats

Other file formats such as rich text (RTF) or MS Word formats may be required in addition to the PDF

requirement of the eCTD, by specific NCAs or the EMEA, especially for the provision of product

information documents or the Module 2 documents. Please refer to the

Notice to Applicants, Volume

2A, Chapter 7 for further details.

These files should not be added as leaf elements within the eCTD

structure. They should be provided in a separate folder called,

e.g.“<sequence>-workingdocuments” on the CD/DVD containing

the eCTD.

2.9.7 Technical validation of eCTD submissions

The technical validation of an eCTD is a separate activity to the content validation of a submission and

takes place irrespective of the type of the submission. NCAs and the EMEA have adopted a

common

set of technical criteria against which all eCTDs can be checked using eCTD review and validation

tools.

The general process for the validation of eCTD submissions is divided into two parts: technical and

content validation. An eCTD must pass technical validation before it undergoes content validation.

Technical validation errors of category A will result in the applicant being asked to resubmit the eCTD

sequence with the same sequence number, category B errors will normally not require resubmission

but may require fixing in a subsequent sequence, category C do not require resubmission but may be

fixed in subsequent sequences at the applicant’s discretion.

Errors found during the content validation should be resolved through the submission of a new eCTD

sequence. These errors must never be resolved by resubmitting an existing sequence.

2.10 Other Technical Information

2.10.1 Security issues

The physical security of the submission during transportation is the responsibility of the applicant.

Once received by NCAs and the EMEA, security and submission integrity is the sole responsibility of

NCAs and the EMEA.

2.10.2 Password protection

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.

2.10.3 Virus protection

The applicant is responsible for checking the submission for viruses. Checking should be performed

with an up-to-date virus checker and be confirmed in the cover letter. After receipt at NCAs and the

Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD Applications

Version: 1.0 May 2009

Page 10 of 41

EMEA, a similar internal virus check will be performed. If a virus is detected it will constitute grounds

for rejection of the electronic submission.

2.10.4 Electronic signatures

Although electronic signatures are currently accepted in the EU as being legally equivalent to

handwritten signatures (Directive 1999/93/EC), the majority of NCAs and EMEA do not have a system

for that yet and therefore require that certain specific documents (covering letters, Application Forms)

are authenticated by separate signed paper copies. Please refer to each NCA for detailed guidance on

this matter or the

Notice to Applicants, Volume 2A, Chapter 7.

2.10.5 Transmission Media

Currently CD-ROM, CD-R, DVD-R are considered acceptable media standards. Applicants should

provide the electronic information on the smallest number of discs possible, taking into consideration

the size of the submission.

If an individual eCTD submission is of such a size as to span several CDs, the provision of a DVD is

recommended. However, if CD-R must be used, when large applications are submitted it is inevitable

that the application will necessarily span multiple CDs. Where possible, individual modules should not

be split over multiple CDs (e.g. if possible, a single CD should contain Module 1, Module 2, if too large

to fit on the same CD should then go onto the next CD even if this requires CD 1 not to be filled to

capacity and so on). If, in the case of larger modules, where a split over multiple CDs is inevitably

necessary, subfolders should be distributed in sequence, and these subfolders should not be split

between CDs, even if this requires a CD to be sent not full to capacity.

It is the choice of the applicant if a separate CD/DVD is provided for each new sequence or if several

sequences (e.g. concerning several variations) for the same medicinal product (same eCTD) is

provided on the same CD/DVD. This should be clearly described in the cover letter and indicated on

the disc (see 2.10.6).

2.10.6 Labelling of Media:

Each CD or DVD submitted with an eCTD should include the following label information, clearly

presented and printed on the media:

¾ Format: eCTD

¾ The applicant’s name

¾ The product (invented) name(s)

¾ The International Non-proprietary Name (INN) of the active substance(s)

¾ The full application number(s) (if known)

¾ The sequence number(s) of the eCTD submissions contained on the CD/DVD

¾ Number of media units per full set and an indication of the place of the individual CD/DVD

within this set (e.g. 1(5), 2(5), etc.

¾ The submission type(s) of each eCTD submission(s) contained on the CD/DVD (e.g. Initial

Application, Variation Type II), as per the eCTD envelope information

2.10.7 Procedure for sending electronic information

Some NCAs are able to accept eCTDs submitted via their portals. Generally only small (<100MB)

applications can be handled this way. Applicants should check with individual NCAs for details of this

process. If submissions are uploaded via a portal no data corruption should occur as a result of the

process.

In all other cases the eCTD submission should be sent to the address referred to in the

Notice to

Applicants, Volume 2A, Chapter 7.

Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD Applications

Version: 1.0 May 2009

Page 11 of 41

Electronic media sets should be submitted at the same time as any required paper documentation.

The electronic media should be packed adequately to prevent damage and the package should

include a cover letter. Please see

section 3.2.3 for details on the format of cover letters.

2.11 Archiving and working copies

Please refer to the Notice to Applicants, Volume 2A, Chapter 7 for details of the number of copies of

electronic submissions required for archiving and review purposes. Many NCAs destroy discs after

data has been uploaded into their systems. Where an NCA requires the disc to be archived they may

have additional requirements.. Note: The current standard to burn CDs / DVDs is

UDF, which has

replaced the former

ISO standard 9660.

2.12 Technical baseline applications

These should normally be submitted as sequence 0000. It should be clearly stated in the cover letter of

the “baseline eCTD” that the content of the current dossier has not been changed, only its format.

Consequently the first variation in eCTD format should then be submitted as sequence 0001. It is not

necessary for the baseline eCTD to contain document hyperlinks as it would not normally be

assessed.

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. For the switch the pros and cons of

the different approaches to dossier structure, as described in Annex 3, Table 1, should be taken into

consideration.

The switch from one approach to another should only be allowed once during the life

cycle.

Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD Applications

Version: 1.0 May 2009

Page 12 of 41

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, e.g. e-Application Form or PIM data.

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 pharmaceutical 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.

Currently it is outside the scope of current eCTD specifications to allow cross references to

documents, sections or modules in other eCTD dossiers.

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.

Module 1 “Not Applicable (N/A)” 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 with the

entry ‘emea’. 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.

Application number The application number should be the centralised procedure/application

number (EMEA/H/C/...), MRP/DCP procedure number (e.g. SE/H/1234...)

or other national application or licence number as required by NCAs.

Multiple entries are possible. The full application number including the

regulatory activity identifier should be used if known.

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.

Agency-name Self explanatory, from picklist in the most recent EU m1 eCTD

specification. Assure that Country and Agency name will be consistent.

Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD Applications

Version: 1.0 May 2009

Page 13 of 41

ATC If unknown at the time of submission, the entry can say ‘to be confirmed’.

Submission type From picklist, see m1 specification for further details.

Procedure type From picklist, see 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.

Related-sequence For a description and example of how to use the ‘related sequence’ entry,

see the EU m1 specification, p14.

Submission-description This element is used to describe this particular eCTD sequence

3.2.3 Cover letter

The cover letter should, at least for MRP and DCP applications, include as a minimum, the information

specified in the

CMDh Guidance document. There is also a template that can be used. Please see the

Notice to Applicants, Volume 2A Chapter 7, for details on the provision of signed paper copies of the

cover letter and application form. The omission of submitted data from certain sections can also be

explained here.

The cover letter should also mention if the product information is being provided as PIM data..

The cover letter should be submitted with the document operation attribute “new” which is in line with

EU M1 specifications. As eCTD viewing tools will display all "new" leaf elements in a current or

cumulative view, it is recommended that you place additional descriptive text in the leaf title to help you

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 (0023)

3.2.4 XML application forms

Some NCAs request that applicants create an application form on their portals which assist in their

internal case creation process. Specific NCA advice should be obtained on where to locate them in the

eCTD structure.

The majority of NCAs and EMEA require the application form to be provided as a PDF file together

with separate signed paper copies. Please refer to Chapter 7 of the

Notice to Applicants volume 2A for

further details.

3.2.5 Product information

Product information should normally be supplied as PDF files but some NCAs require an RTF or Word

file in addition to facilitate assessment. Details can be found in section 2.9.6. If the Product Information

Management (PIM) system is being used files are required in XML format. Please refer to the

Notice to

Applicants, Volume 2A, Chapter 7 for details.

3.2.6 Use of response documents section

The submission of electronic information in response to a list of questions from NCAs and EMEA

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 note that all data

Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD Applications

Version: 1.0 May 2009

Page 14 of 41

related documents are aligned with the CTD structure, refer to EU CTD question 4.c. using the

operation attributes of “new”, “replace”, “append” or “delete” as appropriate.

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 you

provide a full copy of the list of questions received from the agencies as the first leaf in this section.

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). You should use the leaf title 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 then you should use bookmarks within the PDF file to

clearly identify each response. It is possible to submit the response to each question in a separate file

but if you choose to do so then you must use node-extensions and leaf titles to group and identify the

responses under the top level node-extension.

All of the files for the response documents should be placed in the folder m1/eu/responses/CC, where

CC is the appropriate country identifier code for use in MRP/DCP.

3.2.7 Use of the additional data section

The 'Additional Data’ section should only be used for nationally required information in National, MR

and Decentralised Procedures.

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

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

Documents in module 2 should normally be submitted with the document operation attribute “new” as it

would help clarifying what to assess with each submission. As eCTD viewing tools will display all

"new" leaf elements in a current or cumulative view, it is recommended that you place additional

descriptive text in the leaf title to help identifying the documents related to each submission.

New information in module 2 could also be integrated into the former document and then replace the

former one with the operation attribute “replace”

The summaries should be used to justify the absence of data in module 3-5 instead of submitting place

holder files stating “No data submitted” or N/A.

3.4 Module 3 quality folder

3.4.1 Module 32S drug substance

If the product contains multiple drug substances, then documentation for each substance should be

provided in its own m32s section. If a drug substance is manufactured at multiple sites or by multiple

different manufacturing companies, documentation can be provided in multiple m32s sections.

Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD Applications

Version: 1.0 May 2009

Page 15 of 41

However, it may be possible to write documentation that covers multiple manufacturers in one CTD

section – the way the information is provided is left up to the applicant. For further details, please see

Annex 3.

3.4.2 Module 32p drug product

Each dosage form covered by an eCTD application should be described in its own m32p section. If an

application describes multiple strengths of any one dosage form, then documentation that covers all

strengths can be provided in a single m32p section, or alternatively each strength can be covered by

its own strength-specific documents in multiple strength-specific CTD sections. For further details, see

Annex 3.

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

EMEA or NCAs. See 3.6.2.below for further information.

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 (eg 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 for each indication, although closely related indications can be within a single document.

Regardless of which way is chosen, it is important to give clear guidance to the assessor when the

supportive data/study report documents are applicable to more then 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. STFs from submissions in the US are not required

but a submission will not be rejected if they are included. 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 usually provided in Europe (eg datasets)

should be removed. In order to keep the cumulative and current dossier views of the eCTD consistent,

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). For further details see

EU eCTD Q&A 10.

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 E 3) 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 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

Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD Applications

Version: 1.0 May 2009

Page 16 of 41

Listing of Clinical Studies should be provided and this should include hyperlinks to the first page of

each synopsis.

Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD Applications

Version: 1.0 May 2009

Page 17 of 41

4. ADVICE ON SPECIFIC APPLICATION TYPES

4.1 Initial MA Applications

The recommended start for an eCTD life cycle is the initial MA application. It should normally be

provided as sequence 0000. Any other 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 initial-maa. The procedure type depends on the application that is

made. Please find below an overview of the different application types:

Procedure Procedure type

Centralised Procedure (CP) centralised

Decentralised Procedure (DCP) decentralised

Mutual Recognition Procedure (MRP) mutual-recognition

National national

Repeat Use Procedure (RUP) mutual-recognition

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 an initial new application. Although the example relates to the centralised

procedure similar principles can be applied to other procedures.

Day Number eCTD milestone sequence Notes

-14 Initial submission

-1 Response to business validation issues

if required

121 Response to List of Questions (LoQ)

181 Response to List of Outstanding Issues

(LoOI)

210 Final English

Application as agreed at opinion

215 Provision of translations

245 Provision of final agreed translations

following linguistic review

It is not also required to send interim

working versions of the product

information before this point as eCTD

270 Decision

I.e. final amended documentation if

any changes occur during the

Standing Committee

phase

4.2 Variation Applications

All types of variations should be submitted within the eCTD as new sequences. The cover letter and

application form should be included in the eCTD but the majority of NCAs also require these items to

be submitted in signed paper format. Please refer to the

Notice to Applicants, Volume 2A, Chapter 7

for details.

In the eCTD, the documents should be included as electronic sourced document and not as

a scanned copy of the signed documents.

Documents related to the variation should be included in relevant sections or be deleted by use of the

appropriate document operation attribute.

Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD Applications

Version: 1.0 May 2009

Page 18 of 41

The submission type for the sequence has to be for:

Variation type Submission type

Type IA variation var-type1a

Type IB variation var-type1b

Type II variation var-type2

The procedure type should be for variation of the procedure:

Procedure Procedure type

Centralised Procedure (CP) centralised

Mutual Recognition Procedure (MRP) mutual-recognition

National national

However, in relation to the first variation in eCTD format, the applicant is strongly encouraged to also

submit a so called “baseline eCTD”, i.e. to submit the current dossier in an eCTD format, at least

Module 1, the cover letter and product information as a minimum, and Module 3. This ”baseline eCTD”

would then be submitted as sequence 0000 and the first variation in eCTD format submitted as

sequence 0001.

It should be clearly stated in the cover letter of the “baseline eCTD” that the content of the current

dossier has not been changed but only the dossier format.

Parallel variations should be submitted as individual sequences. Problems can occur in cases where a

variation is not approved whilst a subsequent variation is approved. In such case a new sequence

could be submitted containing the old section by replacing or deleting the submitted sections

reaffirming the registered status of the modules.

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 it could

be applied to other procedures:

Type IA & IB Variations

Day Number eCTD milestone sequence Notes

1 Start of the procedure <description>

e.g. “Start of the procedure phone

number changes”

Type II Variations

Day Number eCTD milestone sequence Notes

1 Start of the procedure <description>

e.g. “Start of the procedure indication

enlargement”

91 Response to RSI

If applicable

91 Final English

+5 Provision of translations

+30 Provision of final agreed translations

following linguistic review

It is also not required to send interim

working versions of the product

information before this point as eCTD

Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD Applications

Version: 1.0 May 2009

Page 19 of 41

4.3 Extension Submissions

Several dosage forms can be managed within a single eCTD application, and this helps 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), depending on the procedure. 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 line 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 strength/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 has to 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 has to be “renewal”. The procedure type depends on the procedure:

Procedure Procedure type

Centralised Procedure (CP) centralised

Mutual Recognition Procedure (MRP) mutual-recognition

National national

The following milestones of the procedures are proposed as appropriate sequences to be submitted

during the assessment of renewals:

Day Number

eCTD milestone sequence

Notes

1 Start of the procedure <description>

e.g. “Start of the procedure annual

reassessment”

61 Final English

+5 Provision of translations

+30 Provision of final agreed translations

following linguistic review

It is not also required to send interim

working versions of the product

information before this point as eCTD

Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD Applications

Version: 1.0 May 2009

Page 20 of 41

4.5 PSURs

The submission of a Periodic Safety Update Report (PSUR) should consist of a cover letter, eventually

(depending upon national requirements) an application form and the report itself as a new document in

m536 as well as perhaps some amendments on m25 The structure for a PSUR should follow the

respective

guidance documents. The naming of the leaf element shall indicate the number of the

PSUR or the period covered.

The submission type has to be “psur”. The procedure type depends on the procedure:

Procedure Procedure type

Centralised Procedure (CP) centralised

Mutual Recognition Procedure (MRP) mutual-recognition

National national

4.6 MR and DCP Applications

Please refer to the following specific CMDh guidance document on the use of eCTDs in MRP and DCP

procedures. In general, it is expected that the application covers the full dossier without cross-

referencing to other applications using the same dossier.

4.7 Referrals

4.7.1 CMD referral:

The response that the applicant has to prepare to the list of questions prepared by the CMD(h) will be

sent as an eCTD sequence to all CMD(h) members, according the timelines as defined. The applicant

will create this new sequence in which the documentation is stored according to the recommended

CTD format.

The type of submission of the new sequence should be “referral”. The procedure type depends on the

procedure:

Procedure Procedure type

Centralised Procedure (CP) centralised

Mutual Recognition Procedure (MRP) mutual-recognition

National national

4.7.2

CHMP referral:

In case of a CHMP referral and the applicant wants to submit documentation/information, a new eCTD

sequence will be created and submitted. The applicant doesn’t submit the entire history of all

sequences, but a new sequence with only the information/documentation that concerns the referral.

This sequence will be sent out to all involved parties (as defined in CMD(h) Standard Operation

Procedure).

Only in case the authority/EMEA request the documentation of previous submitted sequences, the

applicant will send a copy of the relevant sequence(s).

The type of submission of the new sequence should be “referral”. The procedure type depends on the

procedure:

Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD Applications

Version: 1.0 May 2009

Page 21 of 41

Procedure Procedure type

Centralised Procedure (CP) centralised

Mutual Recognition Procedure (MRP) mutual-recognition

National national

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, has to be included

according to the CTD structure. Any additional documentation that doesn’t have a place in the dossier,

for example overview of the registrations/applications involved in the referral, should be placed in m10-

cover.

4.8 Active Substance Master Files

The ASMF consists of two parts, applicant’s (“open”) and restricted (“closed”) part, and both should be

submitted by the ASMF holder. The ASMF can be submitted as an eCTD regardless if an application

for Marketing Authorisation for a medicinal product referring to the ASMF is submitted in eCTD format

or not. It should follow the structure of Module 3.2.S of the CTD. All “not applicable” place holders of

the eCTD should be left empty in accordance with the eCTD specifications. The ASMF will be a stand-

alone eCTD with possibilities for LCM.

The applicant's "open" part of the ASMF should be included in section m3/32S of the eCTD for the

medicinal product application. If there are more than one ASMF used for the active substance(s), each

ASMF “open” part should be provided in its own m32S section, clearly distinguished by appropriate file

names.

A copy of the "Letter of Access" addressed to the regulatory authority shall be included in Annex 6.10

of the application form and be placed in m12/cc (i.e. in the respective folder for each concerned NCA).

Even if an application for Marketing Authorisation for a medicinal product is submitted in eCTD format

and there is a reference to an ASMF, the ASMF submitted by the ASMF holder does not have to be

provided in eCTD format. Documents from the “open” part ASMF may be included in the eCTD for the

medicinal product.

The submission type has to be “asmf”. The procedure type normally depends on the procedure.

However as one ASMF application can be used for different types of procedure (national, CP, MRP,

DCP and RUP), the procedure type “national”/”centralised”: should be used.

4.9 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 life cycle on the one hand side, to keep the documents

manageable and to assure the correct alignment of the complete VAMF on the other hand side 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.10 Plasma Master Files

The PMF consists of the scientific data according to Part III of Annex I of Commission Directive

2001/83/EC as amended. To support the life cycle on the one hand side, to keep the documents

manageable and to assure the correct alignment of the complete PMF on the other hand side it is

required that the manufacturer submits the PMF (including versioning), preferably in [eCTD] format,

The complete PMF can be processed with its own submission / case / procedure number separately.

Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD Applications

Version: 1.0 May 2009

Page 22 of 41

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.11 Applicant Initiated Action

Applicants may decide to withdraw their application during any stage of the product life cycle and this

section explains the general principles that should be followed.

Withdrawal of the whole product covered by an eCTD should preferably be submitted as a new

sequence only including a cover letter. The operation attribute “delete” is not required to be used for

the documents.

However, if the application for withdrawal only concerns for example one strength or dosage form out

of several covered by the same eCTD, the application should be submitted as a new sequence, but

normally include the operation attribute “delete” for documents only relevant for this strength.

Furthermore, if relevant it should also include updated documents with the operation attribute “replace”

for documents that covered several other strengths and that now need to be revised to exclude from

the document the strength or dosage form to be withdrawn.

The submission type has to be “withdrawal”. The procedure type is depending on the procedure:

Procedure Procedure type

Centralised Procedure (CP) centralised

Mutual Recognition Procedure (MRP) mutual-recognition

National national

4.12 Duplicate Applications

As a duplicate is an independently authorised medicinal product, there is no definition of a “duplicate”

in the pharmaceutical legislation. However, for practical purpose, a duplicate application is defined 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 tradename;

- same or different applicant/marketing authorisation holder.

Since this is the case only at the time of submission and can later on lead to different, independent

dossiers, one eCTD per duplicate application has to be submitted (with the possibility of including

several strengths, pharmaceutical 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.

Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD Applications

Version: 1.0 May 2009

Page 23 of 41

Annex 1 eCTD Reference Documents

A number of relevant documents can be found on the Documentation tab on the

e-Submission website

at the EMEA. It is recommended that owing to the speed that information changes the following

websites should be consulted regularly:

http://estri.ich.org or http://estri.ich.org/eCTD/index.htm

http://ec.europa.eu/enterprise/pharmaceuticals/eudralex/eudralex_en.htm

http://esubmission.emea.europa.eu/

http://www.hma.eu/27.html

Most important documents to be considered are the following (as of October 1

, 2008):

•

http://estri.ich.org/eCTD/eCTD_Specification_v3_2_2.pdf

•

http://estri.ich.org/eCTD/eCTDQAV1_16.xls

•

http://ec.europa.eu/enterprise/pharmaceuticals/eudralex/homev2.htm

EMEA Q&As

• http://www.emea.europa.eu/htms/human/genguidance/genreg.htm

ICH M4

•

http://www.ich.org/LOB/media/MEDIA554.pdf

ICH M4 Q&As:

•

http://www.ich.org/LOB/media/MEDIA1189.pdf

EU CTD Q&As:

•

http://ec.europa.eu/enterprise/pharmaceuticals/eudralex/vol-2/b/ctd_qa_05_2006.pdf

Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD Applications

Version: 1.0 May 2009

Page 24 of 41

Annex 2 Guidance on Text Searchable Documents

1. General

Applicants are requested to ensure that all submissions contain the maximum amount of text

searchable content. Documents with searchable text will aid the assessor, or any other user, in

searching for specific terms and also in copying and pasting information into another document, such

as an assessment report.

We recognize that not all documents need to be text searchable. This short document provides some

guidance about what must be text searchable and the ways to ensure that files are created

appropriately.

1.1 Creating Text Searchable Files

PDF files with searchable text can be created by all PDF tools from a source file in a text format (e.g.

MS Word, SAS, MS Powerpoint, Rich Text Files, etc.). When created in this way, the file will usually be

the smallest in size (measured in kilobytes or megabytes) that they can be.

If the only version of a document available is in paper, then scanning to PDF and using an Optical

Character Recognition (OCR) routine is the only way to create searchable text. PDF files created in

this way tend to be much larger in size, for the same number of pages (from 10 to 100 times as large),

and the quality of the text that is created will almost certainly not be a 100% match to the original text.

It is noted that tools for checking and correcting this text tend to be somewhat cumbersome. For these

reasons, applicants are recommended to use scanning/OCR only as a last resort.

Applicants are reminded that the text produced by the OCR routine should be “hidden” behind the

image of the original page so that the user can refer to the picture of the page and the text on it as final

verification of the data. As a result, the applicant should ensure that, as a minimum, the text on the

scanned image is legible to the user. Poor quality images should not be provided and you should note

that these can only inevitably lead to poor quality OCR text.

2. Documents that must always be text searchable

(i.e. the PDF should be produced wherever possible from a text source, such as MS Word, but if

sourced from a scanned original then they must be OCR’d.)

• Key administrative documents in Module 1 including, the cover letter, application form, product

information documents

o Applicants are reminded that some NCAs regard logging in through a portal as

sufficient to establish a users identity and do not require handwritten signatures on

Cover Letters and Application Forms submitted this way.

o This also covers similar documents provided in non-MAA submissions.

• Any document in Module 2 of the MAA (QOS, Preclinical Overview and Summaries, Clinical

Overview and Summaries).

o This also covers similar documents provided in non-MAA submissions.

• The main body of text and main tables in any preclinical or clinical report required to support the

main claim of the application.

o This also covers similar documents provided in non-MAA submissions.

• The main body of text in any reports, methods, analytical procedures, etc. supplied in Module 3 of

the MAA

o This also covers similar documents provided in non-MAA submissions.

• The main body of text of Periodic Safety Update Reports (PSURs)

• The main body of text of Risk Management Plans

• The main body of text of Environmental Risk Assessment

• Any English translation of a document originally written in a foreign language (see also below)

Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD Applications

Version: 1.0 May 2009

Page 25 of 41

3. Documents that do not need to be text searchable

(i.e. the PDF should be produced wherever possible from a text source, such as MS Word, but if

sourced from a scanned original then there is no need for OCR.)

• Any original GMP certificate

• Any original certificate of analysis

• Any manufacturer’s licences

• Any certificate’s of suitability

• Any Manufacturing Authorisation

• Any document written in a foreign language where a translation is provided in English (however,

the translation should be text searchable, see above)

• 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

• Applicants should consider providing signatures on separate pages from key text in reports,

overviews, etc.

4. Further Information

If applicants are uncertain whether or not a particular document should be text searchable, they should

contact their NCA for guidance.

Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD Applications

Version: 1.0 May 2009

Page 26 of 41

Annex 3 Guidance and Best Practice on the Structure of Module 3 -

CTD-Quality Considerations for eCTD Submissions in Europe

1. Introduction

The ICH eCTD Specification allows the applicant to manage eCTDs at different levels in Module 3.

The normal choice should be one single eCTD application that covers multiple drug substances,

multiple manufacturers, multiple drug products (components), multiple dosage forms, presentations,

invented names and strengths. If the applicant for some reason needs to have one eCTD per strength

or dosage form, this should be explained and guidance should be given in the cover letter about which

documentation differs to prevent duplicate of work during assessment.

This Annex is based on the use of the ICH eCTD specification v3.2. Refer to the Glossary for an

explanation of terms.

1.1 Electronic information in the eCTD

In addition to CTD-Q documents, eCTD applications provide quality information in various locations:

• Module 1 XML attributes: Envelope – INN, Invented Name (Trade Name)

• Leaf XML attribute: eCTD Title

• Module 3 XML Attributes

o m3-2-s-drug-substance: substance

o m3-2-s-drug-substance: manufacturer

o m3-2-p–drug-product: product-name

o m3-2-p–drug-product: dosage form

o m3-2-p–drug-product: manufacturer

o m3-2-p-4–control-of-excipients: excipient

More than 1 entry for each of the XML Attributes above 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)

2. General Principles

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 and manufacturers, or multiple documents can be

provided, e.g. per strength and/or per manufacturer. 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. 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.

2.2 Identifying to an agency what the application covers

The regulatory procedure drives what options are available for how many eCTD applications to provide

per product range. Generally speaking, multiple eCTD applications can be provided for different

strengths and dosage forms. However, a single eCTD is preferred, see Section

1. Introduction. A key

factor in making this decision is that in Europe the applicant cannot cross-refer from one eCTD to

another (e.g., for drug substance).

Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD Applications

Version: 1.0 May 2009

Page 27 of 41

See ‘Manufacturer of Drug Product’ as an exception.

For the Centralised Procedure, a single eCTD application should cover all strengths and dosage forms

within the procedure, as illustrated in Figure 1.

In MRP/DCP, a single eCTD is needed per procedure that covers all countries regardless of the

invented names. 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. Refer to Section 2.2

Structure of Submissions, and

Table 1 – Advantages and disadvantages of eCTD application

structures

Figure 1 – Illustration of what an eCTD covers for a product with the invented name

‘Wonderdrug’, Centralised Procedure

Duplicate/2nd brand injection

Duplicate/2nd brand tablets

Wonderdrug

Wonderdrug injection

Wonderdrug tablets

100mg

400mg

300mg

200mg

diluent

iv powder

Duplicate/2

brand

100mg

400mg 300mg

diluent

iv powder

eCTD Application 1 (0000, 0001, 0002 etc)

eCTD Application 2 (0000, 0001, 0002 etc)

200mg

Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD Applications

Version: 1.0 May 2009

Page 28 of 41

Table 1 – Advantages and disadvantages of eCTD application structures

One Combined eCTD For Multiple Strengths And Dosage Forms

Advantages Disadvantages

Clinical and non-clinical documentation is

provided only once

Any change to any strength/dosage form will add another

sequence to the application, and therefore the application

in general will eventually contain a larger number of

sequences. Some of these would cover all products

covered by the eCTD application, others may affect only

one strength or dosage form. Applicants need to use the

submission description to describe what each sequence

covers.

Any changes to drug substance, or safety

related changes that affect the product,

will require only one sequence

Adding a new strength (line extension) could involve

replacing all ‘common’ documents with documents

covering existing strengths plus the new strength, and

also adding new additional strength-specific documents

Common documents can be included only

once (e.g., Pharmaceutical Development

for multiple tablet strengths)

Life cycle management becomes more complex in the

following situations:

• In MRP, an applicant applies for only certain

strengths, in certain countries (e.g. strength 1 and 3

in CMS X and strength 2 and 4 in CMS Y, etc)

• An applicant wants to transfer a certain marketing

authorisation (certain strength) within one eCTD

application to another MAH.

• An applicant wishes to withdraw one strength

• Variations may be only applicable for one specific

strength, and result in the creation of strength

specific documents. These would have to be added

to the lifecycle and managed alongside the existing

documentation, which, if originally ‘common’, would

then only cover the existing (non-affected) strengths

All lifecycle is in one place Could get complex (e.g., multiple SmPCs)

Documents that are common are

presented only once and therefore read

only once by the assessor

Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD Applications

Version: 1.0 May 2009

Page 29 of 41

One eCTD Application Per Strength Or Dosage Form

Advantages Disadvantages

A new strength (line extension) could be

handled in a new eCTD and would not

affect existing lifecycle

All clinical and non-clinical reports are provided for each

strength or dosage form (cannot cross reference across

different eCTDs in the EU)

Life cycle management can be

maintained per strength so fewer issues

when applying for only certain strengths in

certain countries within MRP/DCP, or MA-

transfer or withdrawals, line extensions,

variations, etc.

Any changes to the drug substance or changes that

affect all strengths/dosage forms of the product (eg

safety related changes to the labelling) would mean

building and submitting multiple eCTD sequences, one

within each eCTD application.

Lifecycle is maintained separately, and would need to be

managed across multiple potentially identical eCTD

applications

If all strengths/dosage forms are not Common documents must be included in each eCTD

marketed in every country in an MRP

Procedure, then a unique application per

strength will avoid the possibility that one

CMS will not accept the dossier because

it contains data on a product which is not

being marketed in that country.

application, (cannot cross reference from one eCTD to

another in the EU)

Difficult for the assessor to know what to read/what is

unique. This needs therefore to be thoroughly described

in each submission, which will typically consist of multiple

identical sequences in different eCTD application

lifecycles.

This alternative goes against a founding principle for the

management of electronic data insofar as it means :

- loss of storage place : the same information will be

archived several times at different places, sent several

time for long-term filing, and saved several times in the

everyday back-up of servers.

- multiple data entry : data concerning the common part

of the multiple dossiers (i.e. the major part of the

dossiers) will have to be entered several times in the

document management systems, reviewing systems and

workflows, both in NCAs and in Pharmaceutical

companies

At NCAs, uncertainty on whether a MA for a dosage form

is granted on the basis of assessment of data pertaining

to the dossier of another dosage form

2.2.1 EU Envelope

The Module 1 EU envelope provides the trade name (invented name) of the drug product. The

application number element, which is repeatable, lists all of the product licences or application

numbers covered by the eCTD. Applicants should ensure that entries for invented name, INN,

Applicant and Application Number in the EU envelope are complete and consistent. NB 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.

3. Module 3 XML Attributes in the eCTD

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. Many

eCTD building tool vendors have based their tools on the ICH style sheet, and this means that the

original Module 3 XML attributes cannot be changed with later submissions within the same application

without losing the lifecycle benefit that eCTD offers. (i.e. if a Module 3 XML attribute is altered mid

lifecycle, it will no longer be possible to replace, append to or delete content provided with the previous

attribute value.)

More than 1 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).

Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD Applications

Version: 1.0 May 2009

Page 30 of 41

3.2 Drug Substance (32s) Attributes – Substance-1, Manufacturer-1

3.2.1 Drug substance

The entry for the drug substance name attribute can be an abbreviation of the INN, or the company’s

code for the drug substance.

If there is more than 1 drug substance in the product, there is a separate set of 3.2.S.1 to 3.2.S.7

folders and corresponding XML for each drug substance. This also applies for the open (applicant’s)

parts of Active Substance Master Files (ASMFs).

If a drug substance is covered by a Certificate of Suitability (CEP), the certificate is to be provided in

3.2.Regional Information (and in Module 1.2 for annex 5.10). Only relevant sections of its 3.2.S.1 to

3.2.S.7 folders are used, if needed (e.g., for information not covered by the CEP). See EU CTD Q&As

Question 12 (

http://ec.europa.eu/enterprise/pharmaceuticals/eudralex/vol-2/b/ctd-qa-updatev3_2008-

02.pdf).

3.2.2 Manufacturer of drug substance

In conjunction with the drug substance attribute, each additional manufacturer entry results in

additional 3.2.S.1 to 3.2.S.7 XML elements and folders, where there is content provided.

Various approaches are possible depending on the number of manufacturing

companies/manufacturing sites and the quantity of documentation that is manufacturer-specific. The

general principle is that the resulting XML is a reflection of the document granularity (rather than the

eCTD specification driving the attributes).

3.2.2.1 Approach 1 – Single XML section covering all Manufacturers of the Drug Substance

Where drug substance documentation is identical or very similar for all manufacturers (and hence

there are a minimal number of manufacturer-dependent documents), then a non-specific manufacturer

attribute can be used (such as the parent name of a group of companies, or ‘applicant’ or ‘all’). For

CTD topics that are manufacturer-specific, having separate documents enables the applicant to

manage lifecycles as-needed. In such cases, the title and file name of each leaf is to be customised to

differentiate the files, e.g., leaf title of “Batch Analysis – [manufacturer 1]” where the entry is either the

[current company name] or [current manufacturing town] and file name of batch-analyses-

manufacturer1.pdf. Using leaf titles and filenames to distinguish manufacturers does not involve

adding any extra XML attributes for drug substance manufacturer. As an illustration, see

Figure 2,

where the specification is manufacturer-independent but stability data documentation has been

separated by manufacturer.

This approach does not prevent a future scenario when a new manufacturer may have its own XML

attribute (due to a significant volume of manufacturer-specific documentation). Note that a known

limitation of ICH eCTD specification v3.2 is that the original, non-specific XML attribute cannot then be

modified in the application.

Guidance for Industry on Providing Regulatory Information in Electronic Format: eCTD Applications

Version: 1.0 May 2009

Page 31 of 41

When any XML attributes are no longer accurate nor in accordance with this guidance, it is

acceptable to retain original entries. It is not desirable to correct the XML attributes (i.e., applicants

need not apply an operation attribute of DELETE to previously-submitted files and re-submit the latest

versions with new XML attributes).

Figure 2 - Single Drug Substance, 2 Manufacturers with similar documentation, the few site/manufacturer-

specific documents identified by the XML title (not by adding an additional XML section):

XML Files and folders (directory

Arrows indicate destination of xlink:hrefs

32 of 41

3.2.2.2 Approach 2 – New XML sections for each Manufacturer of the Drug Substance

When there are many manufacturer-specific documents, it is helpful to have additional XML attributes

and equivalent folders for each manufacturer, see

Figure 3. Since these files are located in separate

elements, the leaf titles and filenames do not need to be customised per manufacturer. In this

illustration, since the ‘specification’ document is manufacturer-independent, it appears only once in the

folder structure. Additional XML attribute entries are not expected for each intermediate manufacturing

site or packaging site, but can be used.

As an alternative to Approach 1 and Approach 2 (but not illustrated here), an additional entry of

‘common’ may be used for manufacturer-independent documents (e.g., those in 3.2.S.1 General

Information), such that both the XML and the folder structure contain a ‘common’ entry. If this

approach is used, files do not need to be linked from ‘common’ folders to the named manufacturer

folder(s), i.e., these files appear once in the XML and once in the folder directory.

For example, a drug substance section could contain three 32s:

32s-aspirin-manufacturer-1 (containing information specific to the manufacturer e.g. 3.2.S.2)

32s-aspirin-manufacturer-2 (containing information specific to the manufacturer e.g. 3.2.S.2)

32s-aspirin-common (containing manufacturer-independent information)

33 of 41

Figure 3 Single Drug Substance, 2 Manufacturers with significant volume of different documentation (one

section for Acme Chemicals, another for Pharmasupply).

XML Files and Folders (directory)

34 of 41

3.3 Drug Product (32p) – Product/Dosage Form/Manufacturer

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. Avoiding the trade name in Module 3 could

prove beneficial for original MAAs, since the proposed name is not always accepted and/or is not

always applicable to all EU member states.

The entry can be a general term such as ‘active’, or ‘product’ that then produces a full set of 3.2.P.1 to

3.2.P.8 XML elements and folders. Alternatively, the internal company code of the drug product name

may be used. If applicable, another full set of XML elements and folders can be used as needed, e.g.,

for ‘diluent’.

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’, 'frozen" vs. "refrigerated" formulation 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.

3.3.3 Strength

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.

3.3.3.1 Approach 1 – Single General XML Section Covering All Strengths

If there is a limited number of documents in the submission that are strength-specific, there can be a

single 3.2.P, with a non-specific XML attribute such as ‘tablet’. Where there are multiple files under the

same element, the XML title and file name of each leaf is used to differentiate any documents where

the content is strength-specific, e.g. ‘Stability Data – 100 mg’ and ‘Stability Data – 200 mg’ and

‘stability-data-100mg.pdf’ and ‘stability-data-200mg.pdf’, respectively. In this case, the term ‘all

strengths’ can be used to concatenate with the dosage form entry for the XML attribute for the single

3.2.P. This approach does not prevent a future scenario where a new strength has its own XML

attribute. However, a known limitation of the ICH eCTD specification v3.2 is that the original, non-

specific XML attribute (eg ‘all strengths’) cannot then be modified - see note below under

Figure 4

below.

Figure 4 illustrates this approach, where the Pharmaceutical Development document is strength-

independent but Stability Data documentation has been split by strength.

35 of 41

Figure 4 - Approach 1 - One 32p for all Strengths, any strength specific documents identified by the XML title,

not by adding an additional XML section

XML Files and Folders (directory)

Note: The use of the term ‘all-strengths’ will mean that if the applicant subsequently submits a line extension for an additional strength (e.g.

1000mg) where the documentation is significantly different, and approach 2 is preferred for the new strength, then the attribute ‘all-strengths’

will not include the documentation for the 1000mg tablet.

36 of 41

3.3.3.2 Approach 2 – Separate XML section covering one Strength or Dosage Form

If a strength or dosage form is manufactured in a significantly different way from other

strength(s)/dosage forms and has a large volume of its own 3.2.P documentation, then a separate

3.2.P branch with appropriate subsections applicable to that manufacturer can be justified. In this

case, the dosage form XML attribute and folder includes the strength (e.g., Tablet 5 mg and tablet-

5mg, respectively). Documentation that pertains to all strengths should only be included once.

Previously-submitted documents or documents that are applicable to more than one strength can be

referred to in new XML leaves under each strength specific XML branch, without re-providing the

content files themselves, see

Figure 5.

37 of 41

Figure 5 – Approach 2- Separate XML and documents for Strengths – significant content differences, but

Pharmaceutical Development only provided once in the folder structure and referred to from the XML twice

XML Files and Folders (directory)

38 of 41

3.3.3.3 Approach 3 – Different XML sections covering each Strength

Some applicants may find it beneficial to have different XML sections for each strength. Even though

many of the leaves in these XML sections may point to the same document, there is no need to

provide a document more than once. See

Figure 6 where the Pharmaceutical Development and

Stability Data documents are provided one time in the folders, but referenced multiple times from the

XML.

However, it should be noted that many eCTD building tools do not include functionality to allow an

applicant to use multiple XML leaves to repeatedly reference to a single document in the folder

directory, and therefore this approach is not therefore recommended unless the user has significant

eCTD experience.

39 of 41

Figure 6 - Approach 3 - Multiple XML leaves per Strength, one document per Strength – this uses the XML to

differentiate between strengths, without requiring the applicant to write multiple similar documents – all

xlink:href entries point to shared documents in ‘all-strengths’ folder

XML Files and Folders (directory

40 of 41

3.3.4 Manufacturer of drug product

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 and 3.2.A.1 and 3.2.A.2 XML elements. However, in many eCTD

building tools, entries for drug product manufacturer do not result in additional directory folders.

Hence it is practical to use high-level descriptors such as ‘common’, ‘applicant’, or ‘not required’.

If specific manufacturer entries are provided, then the guidance is similar to that for the

‘

Manufacturer of Drug Substance’. If the building tool did not generate a set of directory folders

per manufacturer of drug product, then corresponding filenames should be customised per

manufacturer. Alternatively, experienced applicants may wish to manually produce a second set

of 3.2.P.1 to 3.2.P.8 folders, which will involve either adding ‘manufacturer’ to the name of the

directory folder, (e.g. tablet-5mg-site1), and editing all xlink:hrefs in the corresponding XML, or

editing xlink:hrefs before publishing the eCTD. Applicants should consult their eCTD tool vendor

for further details

3.4 Excipients

Each excipient entry generally produces a full set of 3.2.P.4.1 to 3.2.P.4.6 XML elements and

folders. This XML attribute need not be used at all (it is not required per ICH M4Q). The

description below reflects current industry practice.

3.4.1 Compendial excipients

There is generally little to register for pharmacopoeial excipients. In this case, an XML attribute

entry of ‘compendial’ is acceptable. A single file that addresses CTD topics 3.2.P.4.1 to 3.2.P.4.4

for all excipients can be provided e.g., in 3.2.P.4.1 with a title for the leaf that accurately describes

its content. Alternatively, an entry of ‘compendial – [named excipient]’ is acceptable, e.g.,

‘compendial - purified water’. In this case a single file addresses CTD topics 3.2.P.4.1 to

3.2.P.4.4 for each pharmacopoeial excipient. In most cases, these documents will simply consist

of statements referring to the relevant pharmacopoeia.

In either case, if additional tests are performed on the pharmacopoeial excipient, these can be

located alongside the above file in the relevant folder (e.g., 3.2.P.4.2, 3.2.P.4.3) and with an

appropriate title.

3.4.2 Non-compendial excipients

For non-pharmacopoeial excipients, the excipient XML attribute entry can be a general term, e.g.,

‘coating agent’, ‘flavouring agent’, ‘sweetening agent’. In this case, the title and filename of the

leaf provides details and differentiates files, e.g., title ‘Validation of Assay – Opadry Yellow’.

Alternatively, a more specific attribute entry such as ‘non-compendial opadry yellow’ can be used.

41 of 41