EU eCTD Validation Criteria: Every Rule, Explained
EU eCTD validation criteria, every rule explained
All 111 criteria the EU regulatory network applies to eCTD sequences, in plain language: what each rule checks, how severe it is, and how to fix it before you submit.
What happens to a sequence before anyone reads it
Before a sequence is assessed, the EU regulatory network checks it automatically against its published eCTD validation criteria: the backbone and regional files, folder and file naming, checksums, lifecycle operations and PDF properties.
EU criteria are either pass/fail or best practice. A sequence that fails any pass/fail criterion is rejected on technical grounds and has to be resubmitted. Best-practice criteria do not cause rejection, but their findings are visible to the assessor and should be corrected.
The same criteria apply across the centralised, decentralised, mutual-recognition and national procedures, so one clean sequence can be submitted to every agency in the procedure.
Search all EU criteria
Open any rule to see what it checks and how to fix it. Filter by severity to see only the rules that stop a submission.
111 criteria · 83 pass-fail · 28 best-practice · source: EU eCTD validation criteria (esubmission.ema.europa.eu)
ICH DTD
1.1The specified filename is usedPass-Fail
What it checks. File is named ich-ectd-3-2.dtd
1.2The file is placed in the correct folderPass-Fail
What it checks. In the folder /XXXX/util/dtd
1.3A currently acceptable version of the DTD is used (checksum matches the published value)Pass-Fail
What it checks. Currently acceptable versions are described in the current ICH eCTD Specification. (The checksum for the DTD in eCTD v3.2 (ich-ectd-3-2.dtd) shall match the published value)
1.4The version number of the DTD/specification used in the sequence being tested is higher than or equal to the version of the DTD used in the sequence numerically preceding the incoming sequence in the eCTD lifecyclePass-Fail
What it checks. With reference to any transition guidance, going back to an earlier version is not allowed when a newer version has already been used for that eCTD. 'The sequence numerically preceding the incoming sequence in 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.5The version number of the DTD/specification used in the sequence being tested is lower than or equal to the version of the DTD used in the sequence numerically succeeding the incoming sequence in the eCTD lifecycle.Pass-Fail
What it checks. This rule specifically tests in situations where sequences have been submitted out of order. 'The sequence numerically succeeding the incoming sequence in the eCTD lifecycle' refers to the lowest numbered sequence that is numerically higher than the incoming sequence. The criterion should only be tested if there are sequences with higher sequence numbers present.
ICH stylesheet
2.1The specified filename is usedPass-Fail
What it checks. File is named ectd-2-0.xsl
2.2The file is placed in the correct folderPass-Fail
What it checks. In the folder /XXXX/util/style
2.3The checksum for the stylesheet used must match the published checksum for the stylesheet associated with the DTD used for the sequencePass-Fail
What it checks. For example, the checksum corresponding to the stylesheet from eCTD specification v3.2 (ectd-2-0.xsl) is 3a07a202455e954a2eb203c5bb443f77
EU M1 DTD
3.1The specified filename is usedPass-Fail
What it checks. File is named eu-regional.dtd
3.2The file is placed in the correct folderPass-Fail
What it checks. In the folder /XXXX/util/dtd
3.3A currently acceptable version of the DTD is used (checksum matches the published value)Pass-Fail
What it checks. Currently acceptable with reference to any transition guidance (Refer to http://esubmission.ema.europa.eu/eumodule1/index.htm). For example, the checksum for the DTD for EU m1 v3.1 is f8e473246d58499f9ffff8e51a32380d
3.4The version number of the DTD/specification used in the sequence being tested is higher than or equal to the version of the DTD used in the sequence numerically preceding the incoming sequence in the eCTD lifecyclePass-Fail
What it checks. With reference to any transition guidance, going back to an earlier version is not allowed when a newer version has already been used for that eCTD. 'The sequence numerically preceding the incoming sequence in 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 sequence numbers present.
3.5The version number of the DTD/specification used in the sequence being tested is lower than or equal to the version of the DTD used in the sequence numerically succeeding the incoming sequence in the eCTD lifecyclePass-Fail
What it checks. This rule specifically tests in situations where sequences have been submitted out of order. 'The sequence numerically succeeding the incoming sequence in the eCTD lifecycle' refers to the lowest numbered 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 sequence numbers present
EU M1 leaf MOD file
4.1The specified filename is usedPass-Fail
What it checks. File is named eu-leaf.mod
4.2The file is placed in the correct folderPass-Fail
What it checks. In the folder /XXXX/util/dtd
4.3The checksum for the eu-leaf.mod file used must match the published checksum for the eu-leaf.mod file associated with the DTD used for the sequencePass-Fail
What it checks. For example, the checksum for eu-leaf.mod from EU eCTD Module 1 v3.1 is 23B854174E61C68044B9F53C0009AF95
EU M1 envelope MOD file
5.1The specified filename is usedPass-Fail
What it checks. File is named eu-envelope.mod
5.2The file is placed in the correct folderPass-Fail
What it checks. In the folder /XXXX/util/dtd
5.3The checksum for the eu-envelope.mod file used must match the published checksum for the eu-envelope.mod file associated with the DTD used for the sequencePass-Fail
What it checks. For example, the checksum for eu-envelope.mod from EU eCTD Module 1 v3.1 is cf059a8f48c68fe4ce9ad2947ab854ca
EU M1 stylesheet
6.1The specified filename is usedPass-Fail
What it checks. File is named eu-regional.xsl
6.2The file is placed in the correct folderPass-Fail
What it checks. In the folder /XXXX/util/style
6.3The checksum for the stylesheet used must match the published checksum for the stylesheet associated with the DTD used for the sequencePass-Fail
What it checks. For example, the checksum for the stylesheet from EU eCTD Module 1 v3.1 is 474f3fe1fdadb31c74477793e060383d
Index XML
7.1The file is placed in the correct folderPass-Fail
What it checks. The root folder /XXXX
7.2The file is named correctlyPass-Fail
What it checks. File is named index.xml
7.3The file is well formedPass-Fail
What it checks. Well formed with respect to the rules of the XML specification
7.4The file is validPass-Fail
What it checks. Valid with respect to the ICH eCTD DTD file included in the util/dtd folder
7.5The reference to the DTD in index.xml is directed to the DTD provided in the util folderPass-Fail
What it checks. This is the ICH DTD in /XXXX/util/dtd, and tested for validity by rules 1.1 - 1.4. 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.6The reference to the stylesheet in index.xml is directed to the stylesheet provided in the util folderPass-Fail
What it checks. This is the ICH stylesheet in /XXXX/util/style and tested for validity by 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)
Index MD5 txt
8.1The file is placed in the correct folderPass-Fail
What it checks. The root folder /XXXX
8.2The file is named correctlyPass-Fail
What it checks. The file is named index-md5.txt
8.3The regenerated checksum for the index.xml matches the value in the file index-md5.txtPass-Fail
EU regional XML
9.1The file is placed in the correct folderPass-Fail
What it checks. The folder /XXXX/m1/eu
9.2The file is named correctlyPass-Fail
What it checks. File is named eu-regional.xml
9.3The file is well formedPass-Fail
What it checks. Well formed with respect to the rules of the XML specification
9.4The file is validPass-Fail
What it checks. Valid with respect to the EU Module 1 DTD file included in the util/dtd folder
9.5The reference to the DTD in eu-regional.xml is directed to the DTD provided in the util folderPass-Fail
What it checks. This is the EU Regional DTD in /XXXX/util/dtd, and tested for validity by rules 3.1-3.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)
9.6The reference to the stylesheet in eu-regional.xml is directed to the stylesheet provided in the util folderPass-Fail
What it checks. This is the stylesheet in /XXXX/util/style, and tested for validity by rules 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)
9.7The UUID is well formed according to ISO/IEC 11578:1996 and ITU-T Rec X.667 | ISO/IEC 9834-8:2005Pass-Fail
What it checks. This criterion will test whether the UUID is well formed
9.8If the sequence already submitted numerically preceding the incoming sequence in the eCTD lifecycle contains a UUID (i.e. was submitted using v3.0 of the EU m1 Specification or higher), then the UUID in this incoming sequence must be identical to the one in the previous sequencePass-Fail
What it checks. This rule checks that the UUID is correct and the sequence is being loaded into the correct eCTD Application
9.9The UUID must be identical in all envelopesPass-Fail
What it checks. The UUID is unique for each Dossier and is identical with the most recent sequence sent.
Submission Structure
10.1All the lowest level heading elements in the XML (including node-extensions) included in the submission contain at least one leafPass-Fail
Leaf Attributes
11.1The leaf attribute 'checksum-type' has a value of md5 or MD5Pass-Fail
What it checks. Note that this value is not case sensitive
11.2The regenerated checksum for each file matches the value in the leaf attribute 'checksum'Pass-Fail
What it checks. Note that if the content file is in an earlier sequence within the same eCTD application then the checksum can only be regenerated if access to this file is available.The MD5 checksum is not case sensitive
11.3For every leaf the 'title' attribute is not emptyPass-Fail
11.4All leaves with an operation attribute value of new, replace or append must have a value for the cross reference (xlink:href)Pass-Fail
What it checks. The value for the cross reference (xlink:href) should be valid, and not 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 http://www.w3.org/TR/xml/ and http://www.ietf.org/rfc/rfc3986.txt (version 2005 page 22, section 3.3).
11.5All leaves with an operation attribute value of delete must have no value for the cross reference (xlink:href)Pass-Fail
What it checks. The attribute does not need to be included, or can be declared but with a null value
11.6The file referenced by the cross reference (xlink:href) must exist in the same or a previously submitted sequence within the same eCTD applicationPass-Fail
What it checks. The link within the XML leaf element is valid, i.e. the target exists
11.7All leaves with an operation attribute value of replace, delete or append must have a value for modified-filePass-Fail
What it checks. Note - it is recommended that the tracking table is always provided with the operation attribute of 'new', due to national sequences in MRP/DCP
11.8All leaves with an operation attribute value of new must have no value for modified-filePass-Fail
What it checks. The attribute does not need to be included, or can be declared but with a null value
11.9The leaf referenced by the modified file must exist in a previously submitted sequence within the same eCTD application. Applies to all leaves except for those with a specific country attribute:m1-0-cover,m1-2-form,m1-3-1-spc-label-pl,m1-3-2-mockup,m1-3-3-specimen ,m1-3-4-consultation ,m1-3-5-approved ,m1-responses,m1-additional-dataPass-Fail
What it checks. This test applies to all procedures.'common', 'ema', or 'edqm' are not considered to be country specific attributes.However, in common MRP/DCP sequences, replacing previously submitted national content also in other modules 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.10For all leaves (except leaves within node extensions and leaves in module 3.2.A) with an operation attribute value of replace, delete or append, the modified file must be present in the same CTD section of the dossier.Note: Using the operation attribute 'delete' to remove content placed in m1-additional-data is exempt from this rulePass-Fail
What it checks. Same CTD section' refers to the position in the table of contents. Sections are defined by the CTD and also by attributes in the eCTD. For example, applicants cannot replace content in the application form section with revised content that is being provided in the cover letter section. eCTD attributes also create applicant defined sections. For example, each 'substance' or 'manufacturer' attribute in m3-2-s-drug-substance, or 'product-name' attribute in m3-2-p-drug-product will create a new CTD section, and lifecycle between these sections is also not allowed. For further details refer to Section 2.9.6 on page 13 of the Harmonised Technical Guidance for eCTD Submissions in the EU.Due to inconsistency between tools how attributes are handled in the past, attributes in module 3.2.A should be allowed to be edited or not automatically copied. To avoid unnecessary errors these modules are exempt as well
11.11Two leaf elements should not have the same leaf IDPass-Fail
What it checks. ID must be unique within each sequence
11.12For all leaves with an operation attribute value of replace, delete or append the modified file must not have been replaced or deleted by any other leaf element in any sequence including the current onePass-Fail
What it checks. Documents can be replaced or deleted just once.The modified file must not have been subject to another replace or delete operation in any of the available sequences
11.BP1The leaf referenced by the modified file must exist in a previously submitted sequence within the same eCTD application. Applies to all leaves with a specific country attribute, i.e.m1-0-cover,m1-2-form,m1-3-1-spc-label-pl,m1-3-2-mockup,m1-3-3-specimen ,m1-3-4-consultation ,m1-3-5-approved ,m1-responses,m1-additional-dataBest-Practice
What it checks. In common MRP/DCP sequences, 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. 'common', 'ema', or 'edqm' are not considered to be country specific attributes
11.BP2For all leaves within node extensions or module 3.2.A with an operation attribute value of replace, delete or append, the modified file should be present in the same node extension or attribute-defined sectionBest-Practice
What it checks. The definition of 'same CTD section' is as in criterion 11.10. If the node extension is not in the same section the criterion 11.10 still applies
ICH attributes
11.BP3ICH attributes must not contain leading or trailing spaces, nor start or end with hyphensBest-Practice
What it checks. The problem is with attributes in the XML that define re-useable sections. Hyphens or spaces at the beginning or end of a attribute name are not allowed
Node extensions
12.1For every node-extension the 'title' attribute is not emptyPass-Fail
Sequence number
13.1The sequence folder name is a 4 digit numberPass-Fail
What it checks. i.e. numbers between 0000 and 9999
13.2The sequence number (folder name) has not already been usedPass-Fail
13.3The sequence folder name matches the sequence number in each envelope in eu-regional.xmlPass-Fail
Envelope Attributes
14.1There is a single envelope with the country attribute value of 'ema' if the procedure type is 'centralised' and the submission type is not 'cep'Pass-Fail
What it checks. This should be 'ema'
14.2There are one or more country specific envelopes if the procedure type is 'mutual-recognition' or 'decentralised'Pass-Fail
What it checks. The country attribute value must not be 'ema' or 'common' or 'edqm'
14.3There is a single country specific envelope if the procedure type is 'national'Pass-Fail
What it checks. The country attribute value must not be 'ema' or 'common' or 'edqm'
14.4There is a single envelope with the country attribute value of edqm if it is the submission type of cepPass-Fail
What it checks. This should be 'edqm'. It is expected to use 'centralised' as the procedure type (see criterion 14.9)
14.5For every country attribute (except 'common') used in country specific leaves with the operation attribute, 'new', 'replace' or 'append' , there is an EU envelope with a matching country attribute valuePass-Fail
What it checks. Even if no content is specific to that country there must still be an EU envelope for each country receiving an MRP/DCP/NP submission. However, note that there is not a test for this scenario. For CP submissions, there must only be 'ema' or 'common' leaf attribute and a 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.6If the submission unit type is 'initial' or 'reformat' then the related-sequence attribute must have a value equal to the current sequencePass-Fail
What it checks. Refer to EU m1 specification. When submitting a first submission initialising a regulatory activity or proving a reformatted application, the related sequence attribute should be populated with the same number of that current sequence.Due to some inconsistencies of implementation the criterion is now be considered as P/F
14.7If the submission unit type is not equal to 'initial' or 'reformat' then the entry for related sequence must not be equal to the value for the current sequencePass-Fail
What it checks. Refer to EU m1 specification. When submitting additional lifecycle sequences within an ongoing regulatory activity, the related sequence attribute should be populated with the number of the sequence that started this regulatory activity.Due to some inconsistencies of implementation the criterion is now be considered as P/F
14.8If the submission type is 'maa' and the submission unit type is 'initial' the INN attribute is requiredPass-Fail
What it checks. It is the intent to assure the INN data field is completed. It is strongly recommended to re-use the active ingredient name as of the application form. Separation of multiple names by colon
14.9The procedure type is 'centralised' if the country attribute value is 'edqm'Pass-Fail
What it checks. The procedure type should be 'centralised' for EDQM
14.BP3For every country attribute (except 'common') used in country specific leaves with the operation attribute, 'delete' , there is an EU envelope with a matching country attribute valueBest-Practice
What it checks. Even if no content is specific to that country there must still be an EU envelope for each country receiving an MRP/DCP/NP submission. If there 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
14.BP4If submission mode is set to either 'grouping' or 'worksharing' and submission type is not 'psusa' there should be a Number elementBest-Practice
What it checks. This is the optional element for a high-level submission number, either a 'worksharing' number, or the high-level submission number to be used when grouping Type IA variations for multiple marketing authorisations. Refer to EU m1 Specification and validation criteria 14BP7 and 14BP8
14.BP5If submission mode is not set to either 'grouping' or 'worksharing' there should not be a Number element in the envelopeBest-Practice
What it checks. This is the optional element for a high-level submission number, either a 'worksharing' number, or the high-level submission number to be used when grouping Type IA variations for multiple marketing authorisations. Therefore, it should not be provided if the mode is not set to 'grouping' or 'worksharing'. Refer to EU m1 Specification
14.BP6The procedure-tracking element of the envelope should be filled in with the procedure number for the regulatory activity if availableBest-Practice
14.BP7When submission mode = grouping, submission type must be one of: 'var-type1a', 'var-type1ain', or 'var-type1b', or 'var-type2'; or 'extension'Best-Practice
14.BP8When submission mode = 'worksharing', submission type must be one of: 'var-type1b', or 'var-type2', or 'psusaBest-Practice
Files/Folders
15.BP1.1The files provided in the folders for Module 1 are in acceptable formatsBest-Practice
What it checks. Refer to the Acceptable file formats for EU Module 1
15.BP2.1The files provided in the folders for Module 2-5 are in acceptable formatsBest-Practice
What it checks. Refer to the Acceptable file formats for EU Module 1
15.3Total file folder path length must not exceed 180 charactersPass-Fail
What it checks. Counting starts from the first digit of the sequence number in the sequence number folder name, and includes the filename
15.4File names, including the extension, must not exceed 64 charactersPass-Fail
15.5Folder names must not exceed 64 charactersPass-Fail
15.6Only valid characters are used in file namesPass-Fail
What it checks. 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.7Only valid characters are used in folder namesPass-Fail
What it checks. 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.8There are no unreferenced files in M1, M2, M3, M4 and M5 foldersPass-Fail
What it checks. Including all subfolders within the m1-m5 folders but excluding 'util' folder and subfolders
15.9The only files in the sequence folder (/XXXX/...) are the index.xml and index-md5.txtPass-Fail
15.10There are no empty foldersPass-Fail
15.11For all procedure types, except for EDQM submissions, the tracking table file is present in the correct locationPass-Fail
What it checks. The folder is: /XXXX/m1/eu/10-cover/ema (for CP) /XXXX/m1/eu/10-cover/common (for MRP/DCP) /XXXX/m1/eu/10-cover/cc ('cc' being the actual country code for NP) There is no tracking table for EDQM submissions
15.12For all relevant procedure types, the tracking table file is correctly namedPass-Fail
What it checks. File is named common-tracking-var.pdf ('common' is the appropriate value for 'cc' in MRP/DCP) File is named ema-tracking-var.pdf ('ema' is the appropriate value for 'cc' in CP) File is named cc-tracking-var.pdf ('cc' being the actual country code for NP) 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. There is no tracking table for EDQM submissions
15.BP1Individual files (except for video files) do not exceed 500 MB in sizeBest-Practice
What it checks. Any deviation should always be reported by the validating tool. Files larger than 500 MB should be avoided due to potential archiving issues and to make the assessment easier.
15.BP2The recommended folder structure and folder names in the ICH and EU specifications are usedBest-Practice
What it checks. Any deviation, including additional subfolders, should always be reported 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 ICH and EU naming guidance
15.BP3The recommended file names from the ICH and EU specifications are used for all filesBest-Practice
What it checks. Any deviation should always be reported by the validating tool.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).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
15.BP4For all leaves in sections m1-0-cover, m1-2-form, m1-3-1-spc, m1-3-2-mockup, m1-3-3-specimen, m1-3-4-consultation, m1-3-5-approved, m1-responses and m1-additional-data, the folder name in the xlink:href matches the specific country attribute in the XML leafBest-Practice
What it checks. This criterion will check whether the country codes are used consistently
15.BP5For all leaves in sections m1-0-cover, m1-2-form, m1-3-1-spc, m1-3-2-mockup, m1-3-3-specimen, m1-3-4-consultation, m1-3-5-approved, m1-responses and m1-additional-data, the file name in the xlink:href matches the specific country attribute in the XML leafBest-Practice
What it checks. This criterion will check whether the country codes are used consistently
15.BP6Individual video files do not exceed 1GB in sizeBest-Practice
What it checks. Any deviation should always be reported by the validating tool. Video files larger than 1GB should be avoided due to potential archiving issues and to make the assessment easier.
PDF Files
16.1No PDF has been created and saved as version 1.3 or earlierPass-Fail
What it checks. 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.2There is no security setting to open any individual filePass-Fail
What it checks. This includes passwords, certificate security, or adobe policy server settings. This test should not be used to test for corrupted files, instead see 16.4
16.3There are no further security settings applied to any individual file (except for files in Modules 1.0, 1.2, 3.3, 4.3 and 5.4)Pass-Fail
What it checks. All 'restrictions' should be 'allowed' when viewing the Document 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.0 and m1.2 are tested in criterion 16.4
16.4Individual files in section 1.0 and 1.2 have no security settings except for the following:Changing the document,Document assembly,Page extraction,Commenting,Creation of template pagesPass-Fail
What it checks. These limited security settings are allowable for the application form, because they are necessary for the functioning of the eAF and similar forms such as e.g the PAM form
16.5The submission does not contain corrupted filesPass-Fail
What it checks. 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.6eAFs generated in the PLM Portal need to have the FHIR XML attached. The interactive pdf eAFs (from eSubmissions website) must not contain any attachments.Pass-Fail
What it checks. For easier identification of the PLM Portal web-based eAFs vs the interactive pdf eAF, the following details may help; For the eAFs generated from the PLM Portal that have not been altered further by any other tool, in the document properties the name of the application is: PDF generator and the author is 'European Medicines Agency'. For the interactive pdf eAF the name is 'Designer 6.5'. The PLM Portal eAF version number starts with 2.x and for the interactive pdf the version number starts with 1.x. The check on FHIR XML attachment is not applicable for the interactive pdf eAFs. The interactive pdf eAF must not contain any additional attachments.
16.7The interactive pdf eAFs (from eSubmissions website) must not contain any attachments.Pass-Fail
What it checks. In the document properties the name of author for the interactive pdf eAF the name is 'Designer 6.5'. The interactive pdf the version number starts with 1.x and for the PLM Portal eAF version number starts with 2.x. The check on FHIR XML attachment is not applicable for the interactive pdf eAFs. The interactive pdf eAF must not contain any additional attachments.
16.BP1Files have been created and saved as PDF 1.4, 1.5, 1.6, or PDF 1.7Best-Practice
What it checks. For PDF files with apparent versions of 1.3 or earlier, the version information should be taken from the first eight characters from the first line of the header in the file. For versions 1.4 and higher, the version should be taken from the document catalogue dictionary, if present. If both the header information and the catalogue information are present, then the document catalogue dictionary 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 opened and read by assessors
16.BP2Hyperlinks and bookmarks within documents, or between documents within the same sequence, have a valid targetBest-Practice
What it checks. Only links that open in the same software application are tested. Other 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.BP3Hyperlinks and bookmarks to destinations in a different sequence in the same eCTD have a valid targetBest-Practice
What it checks. Only links that open in the same software application are tested. Other 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.BP4All hyperlinks and bookmarks are set to 'inherit zoom'Best-Practice
What it checks. 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.BP5PDFs except the files from section 1.0 and 1.2 must have 'Fast Web View' activeBest-Practice
What it checks. The use of 'Fast Web View' helps ensure optimum performance of the review system.However, e.g. PAM form and eAF PDF files are exempt from this rule as they cannot be provided as fast web view version
16.BP6PDF Document Properties for the Initial View are set for 'Page Layout = Default' and 'Magnification = Default'Best-Practice
What it checks. Setting page layout and magnification to default allows the assessor to set his/her own preferences to define how the PDF is displayed, rather than the settings being taken from each individual PDF file
16.BP7All PDF hyperlinks and bookmarks are relativeBest-Practice
What it checks. 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.BP8The bookmarks pane should be visible if bookmarks are included within a PDF documentBest-Practice
What it checks. Fulfilling this BP criterion make it more convenient for the assessor in knowing there are bookmarks without opening the pane
16.BP9The bookmarks pane should not be visible if there are no bookmarks included within a PDF documentBest-Practice
What it checks. Fulfilling this BP criterion makes it more convenient for the assessor in knowing there are no bookmarks without opening the pane to check
16.BP10All hyperlinks and bookmarks between two PDFs must be configured as specified in ISO 32000-1:2008Best-Practice
What it checks. Consult the PDF specifications as in ISO 32000-1:2008 for section 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
16.BP11For SmPC, Labelling and Package Leaflet documents (Module 1.3.1) and for centralised procedures only, the Description of the documents is filled in.Best-Practice
What it checks. This rule will check whether the Document Properties>Description of the PDF for SmPC, Labelling and Package Leaflet documents is completed (Title, Author, Subject, Keywords).
Run the criteria while the sequence is being built
A validation report run the evening before a deadline tells you what is wrong when there is no time left to fix it. The same check run every time the sequence changes turns each finding into a few minutes of work for the person who just made the change.
DnXT Publisher runs the EU regulatory network’s criteria at the EU regulatory network’s own severity, continuously while a sequence is assembled, and on sequences you import from partners or previous vendors. The same engine covers 16 eCTD regions and more than 2,500 criteria.
Frequently asked
What does a failed EU eCTD validation rule mean?
A failed pass/fail criterion means the sequence is technically invalid and will not be processed; a corrected sequence must be submitted. A best-practice finding does not stop the submission but should be fixed.
How do I validate a sequence before sending it to the EU regulatory network?
Run it through a validator that applies the EU regulatory network’s current criteria at the EU regulatory network’s own severity, fix every finding that stops the submission, review the rest, and keep the validation report with the sequence you send.
How current is this list?
It is generated from the criteria DnXT runs in production, which track the EU regulatory network’s published criteria. Always confirm against the EU regulatory network’s current documents before relying on a single rule.
Catch every EU finding before the EU regulatory network does
See DnXT Publisher validate a sequence against the EU regulatory network’s criteria while it is being built.
Criteria are summarised from the EU regulatory network’s published validation criteria for information. the EU regulatory network’s own documents are authoritative.