ECTD Validation Criteria v5 0 - For Publication 130320

EU Region eCTD Validation Criteria
Version 5.0
March 2013
Version Number Date Description

1.0 Jan-2008 First approved version
2.0 Jul-2008 Update
2.1 Apr-2009 Minor update
3.0 Jan-2011 Major revision by TIGes Harmonisation Group adopted
by TIGes
3.1 Feb-2011 Comment on check 10.1 deleted and filenaming for
QOS section updated
3.2-3.3 Jan-2012 New draft major version used by TIGes Harmonisation
group in drafting period
3.4 Feb-2012 Major revision by TIGes Harmonisation Group, sent to
TIGes and for a short open consultation at
eSubmission website February 2012
3.5-3.6 Feb-2012 Minor changes by TIGes Harmonisation Group,
following feedback. Draft working document used
within the group.
3.7 Feb-2012 Further changes by TIGes Harmonisation Group,
following discussion. For distribution to TIGes for
adoption later in 2012 (sent as 3.8 after some furthewr
changes after the TIGes meeting
3.8 Mar-2012 TIGes Harmonisation Group outstanding ssues fixed

(changes to 16.1, 16.BP2 and 16.BP3. and changed
comment in cell L4 in 'File-Folder Structure & Names'
worksheet). Sent to TIGes for comments.
3.9-3.93 Apr-May 2012 TIGes Harmonisation Group updating due to

comments through TIGes.
3.94 May-2012 Final draft version sent to TIGes for discussion and
adoption
4.0 May-2012 Final version adopted for publication by TIGes with
implementation date 1 December 2012
4.1 Jul-2012 Typo corrections in criteria 3.3 and 3.5 Also, the
description of the * ("Y"-criteria) is further clarified.
File&Folder sheet updated for section 3.5.3.
4.2 Feb-2013 Updates following EU m1 v2.0 changes, TIGes
Harmonisation Group
4.3 Mar-2013 Further updates at TIGes Harmonisation Group, 6
March 2013.
4.4 Mar-2013 Minor updates at TIGes Harmonisation Group, 13
March 2013 (changed advice for 11.9, added optional
folders for 3.3 & 4.3).
4.5 Mar-2013 Minor updates after TIGes comments (clarification in
11.9 and 11.10)
5.0 Mar-2013 Final new major version adopted for publication by
TIGes to be used from July 2013 for eCTD built in
accordance with EU eCTD m1 v2.0. Mandatory for all
eCTD submissions from 1 September 2013.
Number
Lifecycle needed?
Category Validation Criterion Type of check "YES" (Y) * Comments
1.1 ICH DTD The specified filename is used P/F File is named ich-ectd-3-2.dtd
1.2 ICH DTD The file is placed in the correct folder P/F In the folder /XXXX/util/dtd
1.3 ICH DTD A currently acceptable version of the DTD is used (checksum P/F Currently acceptable versions are described in the current ICH eCTD
matches the published value) Specification. (The checksum for the DTD in eCTD v3.2 (ich-ectd-3-2.dtd)
is 1d6f631cc6b6357f0f4fe378e5f79a27)
1.4 ICH DTD The version number of the DTD/specification used in the sequence P/F Y With reference to any transition guidance, going back to an earlier version
being tested is higher than or equal to the version of the DTD used is not allowed when a newer version has already been used for that
in the sequence numerically preceding the incoming sequence in eCTD. The sequence numerically preceding the incoming sequence in
the eCTD lifecycle. the eCTD lifecycle refers to the highest numbered sequence that is
numerically lower than the incoming sequence.
The criterion should only be tested if there are sequences with lower
sequence numbers present.
1.5 ICH DTD The version number of the DTD/specification used in the sequence P/F Y This rule specifically tests in situations where sequences have been
being tested is lower than or equal to the version of the DTD used submitted out of order. The sequence numerically succeeding the
in the sequence numerically succeeding the incoming sequence in incoming sequence in the eCTD lifecycle refers to the lowest numbered
the eCTD lifecycle. sequence that is numerically higher than the incoming sequence.
The criterion should only be tested if there are sequences with higher
2.1 ICH stylesheet The specified filename is used P/F File is named ectd-2-0.xsl
2.2 ICH stylesheet The file is placed in the correct folder P/F In the folder /XXXX/util/style
2.3 ICH stylesheet The checksum for the stylesheet used must match the published P/F For example, the checksum corresponding to the stylesheet from eCTD
checksum for the stylesheet associated with the DTD used for the specification v3.2 (ectd-2-0.xsl) is 3a07a202455e954a2eb203c5bb443f77
sequence
3.1 EU M1 DTD The specified filename is used P/F File is named eu-regional.dtd
3.2 EU M1 DTD The file is placed in the correct folder P/F In the folder /XXXX/util/dtd
3.3 EU M1 DTD A currently acceptable version of the DTD is used (checksum P/F Currently acceptable with reference to any transition guidance (Refer to
matches the published value) http://esubmission.emea.europa.eu/eumodule1/index.htm). The
checksum for the DTD for EU m1 v2.0 is
9dc9debb051a9e5762fc19a1f55132da
3.4 EU M1 DTD The version number of the DTD/specification used in the sequence P/F Y With reference to any transition guidance, going back to an earlier version
being tested is higher than or equal to the version of the DTD used is not allowed when a newer version has already been used for that
in the sequence numerically preceding the incoming sequence in eCTD. The sequence numerically preceding the incoming sequence in
the eCTD lifecycle. the eCTD lifecycle refers to the highest numbered sequence that is
numerically lower than the incoming sequence. For example if 0109 used
DTD 1.4, 0110 was DTD 2.0, and 0111 is not present, then 0112 must be
built in either DTD 2.0 or higher.
The criterion should only be tested if there are sequences with lower
3.5 EU M1 DTD The version number of the DTD/specification used in the sequence P/F Y This rule specifically tests in situations where sequences have been
being tested is lower than or equal to the version of the DTD used submitted out of order. The sequence numerically succeeding the
in the sequence numerically succeeding the incoming sequence in incoming sequence in the eCTD lifecycle refers to the lowest numbered
the eCTD lifecycle. sequence that is numerically higher than the incoming sequence. For
example if 0010 used DTD 1.4, and 0012 was DTD 2.0, then 0011 must
be built in either DTD 2.0 or 1.4.
The criterion should only be tested if there are sequences with higher
4.1 EU M1 leaf MOD file The specified filename is used P/F File is named eu-leaf.mod
4.2 EU M1 leaf MOD file The file is placed in the correct folder P/F In the folder /XXXX/util/dtd
4.3 EU M1 leaf MOD file The checksum for the eu-leaf.mod file used must match the P/F For example, the checksum for eu-leaf.mod from EU eCTD Module 1
published checksum for the eu-leaf.mod file associated with the v2.0 is 23b854174e61c68044b9f53c0009af95
DTD used for the sequence
5.1 EU M1 envelope MOD The specified filename is used P/F File is named eu-envelope.mod
file
5.2 EU M1 envelope MOD The file is placed in the correct folder P/F In the folder /XXXX/util/dtd
file
5.3 EU M1 envelope MOD The checksum for the eu-envelope.mod file used must match the P/F For example, the checksum for eu-envelope.mod from EU eCTD Module
file published checksum for the eu-envelope.mod file associated with 1 v2.0 is 0ebe02fcdff7e40eff94a88074ca217a
the DTD used for the sequence
.
6.1 EU M1 stylesheet The specified filename is used P/F File is named eu-regional.xsl
6.2 EU M1 stylesheet The file is placed in the correct folder P/F In the folder /XXXX/util/style
6.3 EU M1 stylesheet The checksum for the stylesheet used must match the published P/F For example, the checksum for the stylesheet from EU eCTD Module 1
checksum for the stylesheet associated with the DTD used for the v2.0 is bf40b657579356c7b4d6c866625d8171.
sequence
7.1 Index XML The file is placed in the correct folder P/F The root folder /XXXX
7.2 Index XML The file is named correctly P/F File is named index.xml
7.3 Index XML The file is well formed P/F Well formed with respect to the rules of the XML specification
7.4 Index XML The file is valid P/F Valid with respect to the ICH eCTD DTD file included in the util/dtd folder
7.5 Index XML The reference to the DTD in index.xml is directed to the DTD P/F This is the ICH DTD in /XXXX/util/dtd, and tested for validity by rules 1.1 -
provided in the util folder. 1.5. A valid reference means a URI - see http://www.w3.org/TR/xml/ and
http://www.ietf.org/rfc/rfc3986.txt (version 2005 page 22, section 3.3)
7.6 Index XML The reference to the stylesheet in index.xml is directed to the P/F This is the ICH stylesheet in /XXXX/util/style and tested for validity by
stylesheet provided in the util folder. rules 2.1 - 2.3. A valid reference means a URI - see
http://www.w3.org/TR/xml/ and http://www.ietf.org/rfc/rfc3986.txt (version
2005 page 22, section 3.3)
8.1 Index MD5 txt The file is placed in the correct folder P/F The root folder /XXXX
8.2 Index MD5 txt The file is named correctly P/F The file is named index-md5.txt
8.3 Index MD5 txt The regenerated checksum for the index.xml matches the value in P/F
the file index-md5.txt.
9.1 EU regional XML The file is placed in the correct folder P/F The folder /XXXX/m1/eu
9.2 EU regional XML The file is named correctly P/F File is named eu-regional.xml
9.3 EU regional XML The file is well formed P/F Well formed with respect to the rules of the XML specification
9.4 EU regional XML The file is valid P/F Valid with respect to the EU Module 1 DTD file included in the util/dtd
folder
9.5 EU regional XML The reference to the DTD in eu-regional.xml is directed to the DTD P/F This is the EU Regional DTD in /XXXX/util/dtd, and tested for validity by
provided in the util folder. rules 3.1-3.5. A valid reference means a URI - see
9.6 EU regional XML The reference to the stylesheet in eu-regional.xml is directed to the P/F This is the stylesheet in /XXXX/util/style, and tested for validity by rules
stylesheet provided in the util folder. 6.1-6.3. A valid reference means a URI - see http://www.w3.org/TR/xml/
and http://www.ietf.org/rfc/rfc3986.txt (version 2005 page 22, section 3.3)
10.1 Submission Structure All the lowest level heading elements in the XML (including node- P/F
extensions) included in the submission contain at least one leaf
11.1 leaf attributes The leaf attribute "checksum-type" has a value of md5 or MD5 P/F Note that this value is not case sensitive
11.2 leaf attributes The regenerated checksum for each file matches the value in the P/F Y Note that if the content file is in an earlier sequence within the same
leaf attribute "checksum" eCTD application then the checksum can only be regenerated if access to
this file is available.
The MD5 checksum is not case sensitive.
11.3 leaf attributes For every leaf the "title" attribute is not empty P/F
11.4 leaf attributes All leaves with an operation attribute value of new, replace or P/F The value for the cross reference (xlink:href) should be valid, and not
append must have a value for the cross reference (xlink:href) contain any illegal characters. (Legal characters are lower case
characters a-z, digits 0-9 and hyphens, as documented in the ICH eCTD
specification). A valid reference means a URI - see
11.5 leaf attributes All leaves with an operation attribute value of delete must have no P/F The attribute does not need to be included, or can be declared but with a
value for the cross reference (xlink:href) null value
11.6 leaf attributes The file referenced by the cross reference (xlink:href) must exist in P/F Y The link within the XML leaf element is valid, i.e the target exists
the same or a previously submitted sequence within the same
eCTD application
11.7 leaf attributes All leaves with an operation attribute value of replace, delete or P/F Note - it is recommended that the tracking table is always provided with
append must have a value for modified-file the operation attribute of 'new', due to national sequences in MRP/DCP.
11.8 leaf attributes All leaves with an operation attribute value of new must have no P/F The attribute does not need to be included, or can be declared but with a
value for modified-file null value
11.9 leaf attributes The leaf referenced by the modified file must exist in a previously P/F Y This test applies to all procedures. In common MRP/DCP sequences,
submitted sequence within the same eCTD application replacing previously submitted national content can result in a fail
according to this criterion in other member states. Therefore, unless a
technical solution to prevent this from occurring is available in the eCTD
Building tool, applicants should avoid replacing, deleting or appending to
content submitted in national sequences (other than the first national
phase before MRP), and vice versa.
11.10 leaf attributes For all leaves with an operation attribute value of replace, delete or P/F 'Same CTD section' refers to the position in the table of contents.
append, the modified file must be present in the same CTD section Sections are defined by the CTD and also by attributes in the eCTD. For
of the dossier. example, applicants cannot replace content in the application form section
Using the operation attribute 'delete' to remove content in sections with revised content that is being provided in the cover letter section.
in EU m1 which are no longer used, due to updates of the CTD, eCTD attributes also create applicant defined sections. For example,
should be exempt from this rule. each 'substance' or 'manufacturer' attribute in m3-2-s-drug-substance, or
'product-name' attribute in m3-2-pdrug-product will create a new CTD
section, and lifecycle between these sections is also not allowed.
12.1 Node extensions For every node-extension the "title" attribute is not empty P/F
13.1 Sequence number The sequence folder name is a 4 digit number P/F i.e. numbers between 0000 and 9999
13.2 Sequence number The sequence number (folder name) has not already been used P/F Y
13.3 Sequence number The sequence folder name matches the sequence number in each P/F
envelope in eu-regional.xml
14.1 Envelope Attributes There is a single envelope with the country attribute value of ema P/F This should be "ema"
if the procedure type is 'centralised'.
14.2 Envelope Attributes There are one or more country specific envelopes if the procedure The country attribute value must not be "ema"
type is 'mutual-recognition' or 'decentralised'. P/F
14.3 Envelope Attributes There is a single country specific envelope if the procedure type is The country attribute value must not be "ema"
'national' . P/F
14.4 Envelope Attributes For every country attribute (except "common") used in country Even if no content is specific to that country there must still be an EU
specific leaves with the operation attribute, 'new', 'replace' or envelope for each country receiving an MRP/DCP/NP submission.
'append' , there is an EU envelope with a matching country However, note that there is not a test for this scenario. For CP
attribute value. submissions, there must only be ema or "common" leaf attribute and a
P/F corresponding ema envelope (see 14.1).
This rule should not apply to documents in country specific leaves with
"delete" operation attributes. Refer to 14BP3.
14.BP1 Envelope Attributes If the submission type is supplemental-info or corrigendum then BP Refer to EU m1 speciifcation. For ASMF, the guidance (v1.0, January
the related-sequence attribute must have a value 2010) contradicts this best practice criterion, but it is recommended to use
related sequence for all supplemental-info or corrigendum, even in ASMF
submissions. The ASMF guidance will be updated in due course.
14.BP2 Envelope Attributes If the submission type is not supplemental-info or corrigendum BP Refer to EU m1 speciifcation.
then there must not be related sequence attribute
14.BP3 Envelope Attributes For every country attribute (except "common") used in country BP Even if no content is specific to that country there must still be an EU
specific leaves with the operation attribute, delete' , there is an EU envelope for each country receiving an MRP/DCP/NP submission. If there
envelope with a matching country attribute value. is a need for removal of earlier content that has erroneously been
attributed to a particular country in the leaf metadata without provision of
a corresponding envelope entry, then this BP error should be ignored.
15.1 Files/Folders The files provided in the folders for Module 1 are in acceptable P/F Refer to table in EU Module 1 specification. : this is XML (where a
formats specification exists), PDF, JPEG/JPG, PNG, SVG and GIF.
15.2 Files/Folders The files provided in the folders for Module 2-5 are in acceptable P/F Refer to ICH eCTD specification. This is XML, PDF, JPEG/JPG, PNG,
formats SVG and GIF.
15.3 Files/Folders Total file folder path length must not exceed 180 characters P/F Counting starts from the first digit of the sequence number in the
sequence number folder name, and includes the filename.
15.4 Files/Folders File names, including the extension, must not exceed 64 P/F
characters
15.5 Files/Folders Folder names must not exceed 64 characters P/F

15.6 Files/Folders Only valid characters are used in file names P/F Lower case characters a-z, digits 0-9 and hyphens are allowed (as
documented in the ICH eCTD specification). This test should only be
applied to the file names in the file system, for checks on the XML see
test 11.4.
15.7 Files/Folders Only valid characters are used in folder names P/F Lower case characters a-z, digits 0-9 and hyphens are allowed (as
documented in the ICH eCTD specification). This test should only be
applied to the folder names in the file system, for checks on the XML see
test 11.4.
15.8 Files/Folders There are no unreferenced files in M1, M2, M3, M4 and M5 folders P/F Including all subfolders within the m1-m5 folders but excluding util folder
and subfolders
15.9 Files/Folders The only files in the sequence folder (/XXXX/) are the index.xml P/F
and index-md5.txt
15.10 Files/Folders There are no empty folders P/F
15.11 Files/Folders If the procedure type in the envelope is "decentralised" or "mutual- P/F The folder /XXXX/m1/eu/10-cover/common
recognition", the tracking table file is present in the correct location
15.12 Files/Folders If the procedure type in the envelope is "decentralised" or "mutual- P/F File is named common-tracking-var.pdf ('common' is the appropriate value
recognition", the tracking table file is correctly named for 'cc' in MRP/DCP)
Note that the use of XML format for the Tracking table is not acceptable,
since there is no longer a valid EU standard to use for this format.
15.BP1 Files/Folders Individual files do not exceed 100 MB in size BP Any deviation should always be reported by the validating tool.
Files larger than 100 MB should be avoided due to potential archiving

issues and to make the assessment easier.
15.BP2 Files/Folders The recommended folder structure and folder names in the ICH BP Any deviation, including additional subfolders, should always be reported
and EU specifications are used by the validating tool.
Although navigation of an eCTD is typically carried out via the XML

backbone, it is also helpful if the underlying files and folders follow the
ICHand EU naming guidance.
15.BP3 Files/Folders The recommended file names from the ICH and EU specifications BP Any deviation should always be reported by the validating tool.
are used for all files
Note that the components of the file names in italics in Appendix 4 of the
ICH eCTD specification are to be specified by the applicant (i.e. this is
variable text).
For ASMFs or MAA using an ASMF, it is recommended that the RP and

AP are used in the same way for NeeS and eCTD and therefore it is now
recommended to use RP and AP as suffix also for eCTD, even if this
contradicts the current version of the "Practical guidelines on the use of
the eCTD format for ASMFs for active substance master file holders and
marketing authorisation holders". A Q&A on this is published and the
guidance document itself will be updated in due course. However, for
now, any BP error due to the use of "rp" or "ap" as a prefix should be
ignored.
The CC code of the filename should not be checked against the CC of the
leaf attribute or the folder name.
The potential presence of STF files in m4 or m5 should not be tested.
Although navigation of an eCTD is typically carried out via the XML

backbone, it is also helpful if the underlying files and folders follow the
ICH and EU naming guidance.
16.1 PDF Files No PDF has been created and saved as version 1.3 or earlier P/F PDF 1.3 or earlier is not acceptable for technical reasons. No exceptions
will be made. For example, if a literature reference is received in PDF 1.3
or earlier, then the applicant must provide it in PDF 1.4, 1.5, 1.6 or 1.7,
even if this means copying the full text into a new document or even
getting a paper copy and scanning it.
Further guidance is provided about the best ways to check the PDF
version in the comment to rule 16.BP1.
16.2 PDF Files There is no security setting to open any individual file P/F This includes passwords, certificate security, or adobe policy server
settings. This test should not be used to test for corrupted files, instead
see 16.5.
16.3 PDF Files There are no further security settings applied to any individual file P/F All "restrictions" should be "allowed" when viewing the Document
(except for files in Modules 1.2, 3.3, 4.3 and 5.4) Preferences > Security settings. This includes any of the following
document restrictions: printing, changing the document, document
assembly, content copying, content copying for accessibility, page
extraction, filling of form fields, signing, creation of template pages.
Specific security settings of files in m1.2 are tested in criterion 16.4.
16.4 PDF Files Individual files in section 1.2 have no security settings except for P/F These limiited security settings are allowable for the application form,
the following, which are allowed: because they are necessary for the functioning of the eAF.
Changing the document
Document assembly
Page extraction
Creation of template pages.
16.5 PDF Files The submission does not contain corrupted files P/F This can be achieved by opening a PDF file in software which is
compliant to ISO 32000-1; if the file opens without error, the PDF file is
considered to be conformant. Absence of detection of conformance
means corrupted PDF.
16.BP1 PDF Files Files have been created and saved as PDF 1.4, 1.5, 1.6, or PDF BP For PDF files with apparent versions of 1.3 or earlier, the version
1.7 information should be taken from the first eight characters from the first
line of the header in the file. For versions 1.4 and higher, the version
should be taken from the document catalogue dictionary, if present. If
both the header information and the catalogue information are present,
then the document catalogue dictionary information takes precedent, see
PDF 32000-1:2008 specification, chapter 7.5.2 for further details.
Only the PDF versions specified are recommended by ICH.
This test is important due to archiving and also that PDF files can be
correctly open and read by assessors.
16.BP2 PDF Files Hyperlinks and bookmarks within documents, or between BP Only links that open in the same software application are tested. Other
documents within the same sequence, have a valid target. links (e.g. web links and e-mail addresses) are not considered to link to
essential content and should not be tested.
If this BP criterion is not met, the assessor might not be able to

conveniently find the relevant documents and read the submission as
intended by the applicant.
16.BP3 PDF Files Hyperlinks and bookmarks to destinations in a different sequence BP Y Only links that open in the same software application are tested. Other
in the same eCTD have a valid target. links (e.g. web links and e-mail addresses) are not considered to link to
essential content and should not be tested.
If this BP criterion is not met, the assessor might not be able to

conveniently find the relevant documents and read the submission as
intended by the applicant.
16.BP4 PDF Files All hyperlinks and bookmarks are set to "inherit zoom" BP Using 'inherit zoom' ensures that assessors do not need to spend time
repeatedly setting the view when using the links for navigation to new
documents.
16.BP5 PDF Files PDFs must have "Fast Web View" active BP The use of 'Fast Web View' helps ensure optimum performance of the
review system.
16.BP6 PDF Files PDF Document Properties for the Initial View are set for "Page BP Setting page layout and magnification to default allows the assessor to
Layout = Default" and "Magnification = Default" set his/her own preferences to define how the PDF is displayed, rather
than the settings being taken from each individual PDF file.
16.BP7 PDF Files All PDF hyperlinks and bookmarks are relative BP Relative links and bookmarks will continue to work when the submission
is copied and loaded into new a environment at the agency side. Absolute
(rooted) links and bookmarks will not.
16.BP8 PDF Files The bookmarks pane should be visible if bookmarks are included BP Fulfilling this BP criterion make it more convenient for the assessor in
within a PDF document knowing there are bookmarks without opening the pane.
16.BP9 PDF Files The bookmarks pane should not be visible if there are no BP Fulfilling this BP criterion makes it more convenient for the assessor in
bookmarks included within a PDF document knowing there are no bookmarks without opening the pane to check.
16.BP10 PDF Files All hyperlinks and bookmarks between two PDFs must be BP Consult the PDF specifications as in ISO 32000-1:2008 for section
configured as specified in ISO 32000-1:2008 7.11.2.3 on how the paths need to be written in PDF. The paths cannot
contain back slashes, only forward slashes. See also 12.6.4.3 for the
remote goto action. The link to another PDF cannot be made with
javascript code in the PDF.
Please note, not all PDF tools display the path for the link with forward
slashes. However, the presence of a backslash in a link as displayed in a
PDF viewer or editor does not necessarily mean that the link is NOT
according to the ISO specifications. Therefore, tests for backslashes
must be performed in eCTD validation software.
This BP criterion is important because links who are not according to

section 7.11.2.3 may not work on certain devices, such as non-Windows
operating systems or tablets.
Description of Type of check

P/F Pass/Fail These are validation criteria that can either be passed or failed. eCTDs that fail to meet one or more of these criteria will be returned to the applicant for fixing and resubmission as
the same sequence number.
The pass/fail category has been introduced for the possibility of future automation of eCTD validation.
BP Best Practice Any deviation from the criterion should always be reported by the validating tool.
These are validation criteria that it is considered good practice to ensure are correct in the submitted eCTD. The applicant should make every effort to address these areas before
the eCTD is submitted to the agency.
eCTDs that fail to meet one or more of these criteria will still be accepted by the agency during technical validation and it is possible that agencies may not even check these
criteria during technical validation.
These criteria assess factors that affect the overall ease of use of the eCTD. All tool vendors should include these criteria in their validation tools so that applicants can produce
eCTDs that are easier to use. Users of the validation tool should also be able to check the eCTD without checking for the Best Practice criteria.
* "Y"-criteria Test marked with Y needs the relevant former sequences for the specific criterion to be present for the result to be fully reliable.
If these sequences are not present when testing, any FAIL results for these criteria should be interpreted carefully.
When reporting a 'Fail' for these 'Y' criteria, validation tools should also report the specific missing sequences that are related to the 'Fail'.
LEGEND
Black These entries are fixed text for folder and file names according to the EU and ICH s
Red These entries are variable text for folder and file names according to the EU and IC
Green These entries are picklist values according to the EU specification, refer to separat
Blue (NeeS) These entries for filenames are only applicable for a NeeS format submission.
Pink (eCTD) These entries for folders and filenames are only applicable for an eCTD format sub
Brown (compendial) If the folder name starts with this text, then component filenames below are entirely
Bold, no file extension These entries indicate folder names, and are coloured in accordance with the legen
Regular, with file extension (.pdf) These entries indicate file names, and are coloured in accordance with the legend
Use of Additional Folders

multiple branches possible At these locations, a complete branch of the table of contents can be added
optional folder At these locations, one or more optional subfolders may be used, (also as nested f
folder required and At these locations, there must be a subfolder if content is provided. Optional additi
additional folders optional
In all other locations, additional folders are not allowed. For further details, se
product-name
0000
ctd-toc.pdf
index.xml
index-md5.txt
m1
m1-toc.pdf
eu
eu-regional.xml
10-cover
cc
cc-cover-var.pdf
cc-tracking-var.pdf
12-form
cc
cc-form-var.pdf
13-pi
131-spclabelpl
cc
ll
cc-pidoc-var.pdf
132-mockup
cc
cc-mockup-var.pdf
cc-mockup-var.jpg
cc-mockup-var.jpeg
cc-mockup-var.gif
cc-mockup-var.png
cc-mockup-var.svg
133-specimen
cc
cc-specimen-var.pdf
134-consultation
cc
cc-consultation-var.pdf
135-approved
cc
cc-approved-var.pdf
136-braille
braille-var.pdf
14-expert
141-quality
quality-var.pdf
142-nonclinical
nonclinical-var.pdf
143-clinical
clinical-var.pdf
15-specific
151-bibliographic
bibliographic-var.pdf
152-generic-hybrid-bio-similar
biosimilar-var.pdf
generic-var.pdf
hybrid-var.pdf
153-data-market-exclusivity
datamarketexclusivity-var.pdf
154-exceptional
exceptional-var.pdf
155-conditional-ma
conditionalma-var.pdf
16-environrisk
161-nongmo
nongmo-var.pdf
162-gmo
gmo-var.pdf
17-orphan
171-similarity
similarity-var.pdf
172-market-exclusivity
marketexclusivity-var.pdf
18-pharmacovigilance
181-phvig-system
phvigsystem-var.pdf
182-riskmgt-system
riskmgtsystem-var.pdf
19-clinical-trials
clinicaltrials-var.pdf
110-paediatrics
paediatrics-var.pdf
additional-data
cc
cc-additionaldata-var.pdf
responses
cc
cc-responses-var.pdf
util
dtd
var.dtd
var.xsl
m2
m2-toc.pdf
22-intro
introduction-var.pdf
23-qos
qos-var.pdf
OR
drug-substance-var.pdf
drug-product-var.pdf
appendices-var.pdf
regional-information-var.pdf
24-nonclin-over
nonclinical-overview-var.pdf
25-clin-over
clinical-overview-var.pdf
26-nonclin-sum
pharmacol-written-summary-var.pdf
pharmacol-tabulated-summary-var.pdf
pharmkin-written-summary-var.pdf
pharmkin-tabulated-summary-var.pdf
toxicology-written-summary-var.pdf
toxicology-tabulated-summary-var.pdf
27-clin-sum
summary-biopharm-var.pdf
summary-clin-pharm-var.pdf
summary-clin-efficacy-var.pdf
summary-clin-safety-var.pdf
literature-references-var.pdf
synopses-indiv-studies-var.pdf
m3
m3-toc.pdf
32-body-data
32s-drug-sub
drug-substance multiple branches possible
32s1-gen-info
nomenclature-var.pdf
structure-var.pdf
general-properties-var.pdf
32s2-manuf
manufacturer-var.pdf
manuf-process-and-controls-var.pdf
control-of-materials-var.pdf
control-critical-steps-var.pdf
process-validation-var.pdf
manuf-process-development-var.pdf
32s3-charac
elucidation-of-structure-var.pdf
impurities-var.pdf
32s4-contr-drug-sub
32s41-spec
specification-var.pdf
32s42-analyt-proc
analytical-procedure.pdf
32s43-val-analyt-proc
validation-analyt-procedure.pdf
32s44-batch-analys
batch-analyses-var.pdf
32s45-justif-spec
justification-of-specification-var.pdf
32s5-ref-stand
reference-standards-var.pdf
32s6-cont-closure-sys
container-closure-system-var.pdf
32s7-stab
stability-summary-var.pdf
postapproval-stability-var.pdf
stability-data-var.pdf
32p-drug-prod
drug-product multiple branches possible
32p1-desc-comp
description-and-composition-var.pdf
32p2-pharm-dev
pharmaceutical-development-var.pdf
32p3-manuf
manufacturers-var.pdf
batch-formula-var.pdf
manuf-process-and-controls-var.pdf
control-critical-steps-var.pdf
process-validation-var.pdf
32p4-contr-excip
excipients.pdf
excipient multiple branches possible
specifications-var.pdf
analytical-procedures-var.pdf
validation-analyt-procedures-var.pdf
justification-of-specifications-var.pdf
compendial-excipients
multiple branches possible
specifications.pdf
analytical-procedures.pdf
validation-analyt-procedures.pdf
justification-of-specifications.pdf
excipients-human-animal-var.pdf
novel-excipients-var.pdf
32p5-contr-drug-prod
32p51-spec
specifications-var.pdf
32p52-analyt-proc
analytical-procedure.pdf
32p53-val-analyt-proc
validation-analytical-procedures.pdf
32p54-batch-analys
batch-analyses-var.pdf
32p55-charac-imp
characterisation-impurities-var.pdf
32p56-justif-spec
justification-of-specifications-var.pdf
32p6-ref-stand
reference-standards-var.pdf
32p7-cont-closure-sys
container-closure-system-var.pdf
32p8-stab
stability-summary-var.pdf
postapproval-stability-var.pdf
stability-data-var.pdf
32a-app
32a1-fac-equip
manufacturer optional folder
facilities-and-equipment-report.pdf
32a2-advent-agent
substance optional folder
adventitious-agents-report.pdf
32a3-excip-substance multiple branches possible
folder optional folder
substance.pdf
32r-reg-info
process-val-scheme.pdf
medical-device.pdf
certificate-suitability.pdf
materials-animal-human-origin.pdf
33-lit-ref
reference.pdf
m4
m4-toc.pdf
42-stud-rep
421-pharmacol
4211-prim-pd
study-report optional folder
study-report.pdf
4212-sec-pd
study-report.pdf
4213-safety-pharmacol
study-report.pdf
4214-pd-drug-interact
study-report.pdf
422-pk
4221-analyt-met-val
study-report.pdf
4222-absorp
study-report.pdf
4223-distrib
study-report.pdf
4224-metab
study-report.pdf
4225-excr
study-report.pdf
4226-pk-drug-interact
study-report.pdf
4227-other-pk-stud
study-report.pdf
423-tox
4231-single-dose-tox
study-report.pdf
4232-repeat-dose-tox
study-report.pdf
4233-genotox
42331-in-vitro
study-report.pdf
42332-in-vivo
study-report.pdf
4234-carcigen
42341-lt-stud
study-report.pdf
42342-smt-stud
study-report.pdf
42343-other-stud
study-report.pdf
4235-repro-dev-tox
42351-fert-embryo-dev
study-report.pdf
42352-embryo-fetal-dev
study-report.pdf
42353-pre-postnatal-dev
study-report.pdf
42354-juv
study-report.pdf
4236-loc-tol
study-report.pdf
4237-other-tox-stud
42371-antigen
study-report.pdf
42372-immunotox
study-report.pdf
42373-mechan-stud
study-report.pdf
42374-dep
study-report.pdf
42375-metab
study-report.pdf
42376-imp
study-report.pdf
42377-other
study-report.pdf
43-lit-ref
reference.pdf
m5
m5-toc.pdf
52-tab-list
tabular-listing-var.pdf
53-clin-stud-rep
531-rep-biopharm-stud
5311-ba-stud-rep
study-report folder required and additional folders optional
study-report.pdf
5312-compar-ba-be-stud-rep
study-report.pdf
5313-in-vitro-in-vivo-corr-stud-rep
study-report.pdf
5314-bioanalyt-analyt-met
study-report.pdf
532-rep-stud-pk-human-biomat
5321-plasma-prot-bind-stud-rep
study-report.pdf
5322-rep-hep-metab-interact-stud
study-report.pdf
5323-stud-other-human-biomat
study-report.pdf
533-rep-human-pk-stud
5331-healthy-subj-pk-init-tol-stud-rep
study-report.pdf
5332-patient-pk-init-tol-stud-rep
study-report.pdf
5333-intrin-factor-pk-stud-rep
study-report.pdf
5334-extrin-factor-pk-stud-rep
study-report.pdf
5335-popul-pk-stud-rep
study-report.pdf
534-rep-human-pd-stud
5341-healthy-subj-pd-stud-rep
study-report.pdf
5342-patient-pd-stud-rep
study-report.pdf
535-rep-effic-safety-stud
indication multiple branches possible
5351-stud-rep-contr
study-report.pdf
5352-stud-rep-uncontr
study-report.pdf
5353-rep-analys-data-more-one-stud
study-report.pdf
5354-other-stud-rep
study-report.pdf
536-postmark-exp
study-report.pdf
537-crf-ipl
study optional folder
filename.pdf
54-lit-ref
reference.pdf
util
dtd
eu-regional.dtd
eu-envelope.mod
eu-leaf.mod
ich-ectd-3-2.dtd
style
ectd-2-0.xsl
eu-regional.xsl
according to the EU and ICH specifications. The level of adherance to these names is specified in the eCTD or NeeS validation criteria
mes according to the EU and ICH specifications. In all folder locations containing file names entirely in red text or files with
specification, refer to separate worksheet or the current EU m1 specification.
NeeS format submission.
icable for an eCTD format submission.
nt filenames below are entirely variable. If the foldername does not start with this word, then the fixed filenames should be followed.
d in accordance with the legend above

n accordance with the legend above
contents can be added

may be used, (also as nested folders, i.e. folders within folders) but files can also be placed directly at this location. The subfolders and
nt is provided. Optional additional subfolders are also allowed.
lowed. For further details, see the next worksheet (Files and Folders Q&A)
Refer to ICH eCTD Q&A 73, options 1 & 2, file name entirely variable, multiple files allowed.
In line with ICH eCTD specification, "The directory/file structure would typically follow that of the drug substance section in
or NeeS validation criteria.
or files with -var components, multiple files are accepted.
es should be followed.
ation. The subfolders and single files can also be used beside each other at the same level.
drug substance section in Module 3.2.S."
Q&A - Use of Additional Folders in eCTD and NeeS in the EU
Question:
Can additional folders be used in NeeS or eCTD submissions, to add structure at a deeper folder level than specified in eith
eCTD specification? For example, if an applicant uses node extensions in eCTD, can extra folders also be used?
Answer:
Since publication of the new validation criteria, further discussion has taken place about the interpretation of the eCTD spec
convention with regards to the use of additional folders in the structure. The Harmonisation Subgroup of TIGes hereby anno
reflected in a change of the file and folder naming convention described in the validation rules:
In EU module 1, additional folders are not allowed. In all cases, the use of additional folders in EU m1 should result in a wa
15.BP2 and an error according to NeeS criterion number 2.10.
In module 2 and 3 no additional folders are expected except those already described in the naming convention, e.g. drug-s
branches in case of multiple substances or products. Any additional folder in modules 2 and 3 should result in a warning ac
error according to NeeS criterion number 2.10. An exception is sections m3.2.A and m3.2.R, where additional folders are re
and are therefore optional, and 3.3, where optional additional folders are allowed, for consistency with 4.3 and 5.4.
In module 4 additional folders are optional. Therefore, content can be provided directly into the specified structure (eg direc
warnings being reported. However, additional folders one level below the specified structure (e.g. 4221-analyt-met-val) are
a warning or an error.
In module 5 additional folders are required for all sections apart from m5.2, where they are not allowed, and m5.3.6 and m5
studyreport.pdf file directly into the pre-defined structure, (e.g. directly in the 5331-healthy-subj-pk-init-tol-stud-rep folder), s
number 15.BP2 and an error according to NeeS criterion number 2.10. Optionally, additional folders below the specified stru
rep/study-report) are also allowed on the same level, e.g. per one study, anywhere in module 5, and should not be reported
Pick Lists from EU m1 Specification v 2.0
Country cc at Austria
be Belgium
bg Bulgaria
common All countries
cy Cyprus
cz Czech Republic
de Germany
dk Denmark
ee Estonia
el Greece
ema EMA
es Spain
fi Finland
fr France
hr Croatia
hu Hungary
ie Ireland
is Iceland
it Italy
li Liechtenstein
lt Lithuania
lu Luxembourg
lv Latvia
mt Malta
nl Netherlands
no Norway
pl Poland
pt Portugal
ro Romania
se Sweden
si Slovenia
sk Slovakia
uk United Kingdom
Language ll bg Bulgarian
cs Czech
da Danish
de German
el Greek
en English
es Spanish
et Estonian
fi Finnish
fr French
hr Croatian
hu Hungarian
is Icelandic
it Italian
lt Lithuanian
lv Latvian
mt Maltese
nl Dutch
no Norwegian
pl Polish
pt Portuguese
ro Romanian
sk Slovakian
sl Slovenian
sv Swedish
PI pidoc spc Summary of Product Characteristics

annex2 Annex II
outer Outer Packaging
interpack Intermediate Packaging*
impack Immediate Packaging
other Other product information
pl Package Leaflet
combined
Single text file incorporating the following documents:
spc + annex2 + outer + interpack + impack + other + pl, in this
sequence as applicable for the Centralised Procedure. Only one
file per language is required.
Combined means presented as one document.
* = When labelling documents are submitted as a single file, the

type interpack should be used

ECTD Validation Criteria v5 0 - For Publication 130320

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ECTD Validation Criteria v5 0 - For Publication 130320

Uploaded by

Copyright:

Available Formats

EU Region eCTD Validation Criteria

Version Number Date Description

3.8 Mar-2012 TIGes Harmonisation Group outstanding ssues fixed

3.9-3.93 Apr-May 2012 TIGes Harmonisation Group updating due to

The MD5 checksum is not case sensitive.

15.5 Files/Folders Folder names must not exceed 64 characters P/F

15.10 Files/Folders There are no empty folders P/F

Files larger than 100 MB should be avoided due to potential archiving

Although navigation of an eCTD is typically carried out via the XML

For ASMFs or MAA using an ASMF, it is recommended that the RP and

The potential presence of STF files in m4 or m5 should not be tested.

Although navigation of an eCTD is typically carried out via the XML

Specific security settings of files in m1.2 are tested in criterion 16.4.

Only the PDF versions specified are recommended by ICH.

If this BP criterion is not met, the assessor might not be able to

If this BP criterion is not met, the assessor might not be able to

This BP criterion is important because links who are not according to

Description of Type of check

Use of Additional Folders

d in accordance with the legend above

contents can be added

PI pidoc spc Summary of Product Characteristics

* = When labelling documents are submitted as a single file, the

You might also like