SAHPRA eCTD Validation Criteria: Every Rule, Explained
SAHPRA eCTD validation criteria, every rule explained
All 197 criteria SAHPRA 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, SAHPRA checks it automatically against its published eCTD validation criteria: the backbone and regional files, folder and file naming, checksums, lifecycle operations and PDF properties.
Each SAHPRA rule is graded Error, Warning or Info. An Error must be corrected before the sequence is accepted. A Warning should be corrected, and Info findings are reported for awareness.
Search all SAHPRA 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.
197 criteria · 99 error · 83 warning · 15 info · source: SAHPRA eCTD validation criteria (ectd.sahpra.org.za)
1 - eCTD XML Identification
1.1XML Backbones IdentificationError
What it checks. ICH 3.2 and SAHPRA 3.1 backbone files must be present in the Sequence folder structure. All identified backbones will be listed alongside with their MD5 checksums. The transition status is also checked: Compares schema versions between previous and current Sequence. The current Sequence must use a schema (or DTD) version not lower than the ones in the previous Sequences.
1.2STF IdentificationError
What it checks. Lists all STF index files found in the Sequence (error will be reported if the files are not correct). Note that using STF is optional but if used, they must conform to requirements and be valid.
2 - Files/Folders
2.1.1Folder name syntax must be correctError
What it checks. Checks the syntax of all referenced folder names: - Folder length maximum 64; - Only valid characters used, as listed in the ICH 3.2.2 specification.
2.1.2Folders must not be emptyError
What it checks. Checks the Sequence folder structure for any empty folders (folders without any files or subfolders).
2.1.3Sequence Root folder does not contain unspecified filesError
What it checks. The root folder (the application Sequence folder) must not have any other files in addition to the files explicitly allowed by the specifications. (for eSubmissions this means no additional undefined files)
2.1.4Folder m1 exists and no files are placed there.Error
What it checks. The m1 folder must be present and all content should be provided in a subfolder 'za'. There is no particular folder structure expected beyond this and no file naming conventions are required as long as content is correctly referenced in the za-regional.xml file provided.
2.1.5Only folders m2, m3, m4 m5 and util existError
What it checks. The m2, m3, m4 and m5 folders exist if any corresponding content is provided for those modules. Beyond the required folders (m1 and util), the only other folders which may exist in the sequence folder are m2, m3, m4, m5.
2.1.6Folder util exists and contained files are correctError
What it checks. The util folder must be present. The following files in the folder util/dtd will be checked: - za-regional.xsd (checksum must match the value published by SAHPRA) - ich-ectd-3-2.dtd (checksum must match the value published by ICH) - xml.xsd (checksum must match the value published by SAHPRA) - xlink.xsd (checksum must match the value published by SAHPRA) If STFs are used in the sequence: - ich-stf-v2-2.dtd (checksum must match the value published by ICH) The following files are allowed in the util/styles folder: - ich-stf-stylesheet-2-2a.xsl or ich-stf-stylesheet-2-3.xsl (checksum must match the value published by ICH) - za-regional.xsl - valid-values.xml - ectd-2-0.xsl No other files are allowed in the util folder or its subfolders dtd and style. No further subfolders are allowed in the util folder.
2.1.7Sequence folder should be four digitsError
What it checks. Checks the Sequence folder name (must be four digits).
2.1.8Applications should start with sequence folder 0001Error
What it checks. For a new eCTD application, if the submission type is not Baseline or Transfer, the first sequence should be 0001.
2.2.1File name syntax must be correctError
What it checks. Checks the syntax of all referenced file names: - Path length maximum 180 (counting starts with the application folder); - File name length maximum 64; - Only valid characters used, as listed in the ICH 3.2.2 specification.
2.2.2Unreferenced files are not allowedError
What it checks. Searches for files not referenced in an index file (ICH or Regional).
2.2.3File size limits should not be exceededWarning
What it checks. Files should not exceed the configured maximum size. (max. size 200MB).
2.2.4File types (file extensions) checkWarning
What it checks. All referenced files must have exactly one file extension and the extension must match one of the accepted file types. The use of other file types must be approved by the SAHPRA prior to submitting and should be addressed in the Cover Letter if used.
3 - ICH Backbone
3.1.1File index.xml must existError
What it checks. The index.xml file must be present in the Sequence root folder
3.1.2The index.xml file must be validError
What it checks. Performs XML validation for ICH Backbone. Uses the DTD given in the application folder (util/dtd).
3.2.1Attribute checksum-typeError
What it checks. The checksum-type attribute must have the value md5 or MD5.
3.2.2MD5 ChecksumError
What it checks. The MD5 checksums for all referenced files must match the checksums to the values provided in the backbone file.
3.2.3MD5 for Index fileError
What it checks. MD5 checksum for the index file must match the MD5 checksum provided in the MD5 text file.
3.3.1The reference to the DTD in index.xml is directed to the DTD provided in the util folder.Error
What it checks. 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)
3.3.2The files referenced by the cross reference (xlink:href) must existError
What it checks. The link within the XML leaf element is valid, i.e., the target exists.
3.3.3Only relative references are being usedError
What it checks. Only relative references (for xlink:href and modified file) are allowed. Also, only forward slashes '/' are allowed (no backslashes). Ensure that the file references in the ICH index file use relative paths. Absolute (i.e., rooted) paths are not allowed.
3.3.4References to targets outside ApplicationInfo
What it checks. References (xlink:href) to files outside the Application will be identified. Information is collected because content reuse is encouraged, and this information assists the evaluation process.
3.3.5References to targets outside SequenceInfo
What it checks. References (xlink:href) to files outside Sequence will be identified. Information is collected because content reuse is encouraged, and this information assists the evaluation process.
3.4.1m1-administrative element must existError
What it checks. The element m1-administrative-information-and-prescribing information must be present.
3.4.2Element must have leafError
What it checks. All the lowest level heading elements included in the submission (including node-extensions) contain at least one leaf.
3.4.3Required Attribute value checksError
What it checks. Checks required attribute values of heading elements, ensuring required values are not empty. 2.3.S - Substance and Manufacturer 2.7.3 - Indication 3.2.S - Substance and Manufacturer 5.3.5 - Indication
3.4.4Optional Attribute value checksWarning
What it checks. Checks attribute values of heading elements, checking that values are not empty. 2.3.P - Manufacturer, Dosage Form and Product Name 3.2.P - Manufacturer, Dosage Form and Product Name 3.2.P.4 - Excipient 3.2.A.1 - Manufacturer (Substance/Dosage Form/Product Name when appropriate, enter "NA" when not applicable) 3.2.A.2 - Manufacturer (Substance/Dosage Form/Product Name when appropriate, enter "NA" when not applicable)
3.4.5Leaf title must not be emptyError
What it checks. For operations other than 'delete', all leaves must have a 'title' child. The title must be present.
3.4.6Node Extensions are appropriately placedWarning
What it checks. Checks to make sure node extensions are not used where ICH subheadings already exist or at a level that is not the lowest level of a defined structure.
3.4.7Node Extension title must not be emptyError
What it checks. For node extensions, the title child must be present (value must be present).
3.4.8Node Extension exists for all Clinical StudiesWarning
What it checks. Checks for node extensions for all clinical studies.
3.4.9Node Extension naming convention for content provided in 5.3.6Warning
What it checks. All content provided in 5.3.6 shall be organised as node extensions and the titles for the node extensions shall begin with 'PBRER', 'PSUR' or 'RMP Report' followed by a description of the document and/or date/data lock period of the report (where applicable) (see Best Practice Leaf Title appendix in the eCTD Specifications).
3.4.10Node Extension elements in 3.2.RWarning
What it checks. Leaf elements in 3.2.R must be provided using node extensions; PDF files are not directly allowed as leaf elements directly under 3.2.R
3.4.11Node Extension naming convention for content provided in 3.2.RWarning
What it checks. Acceptable titles include the structure numbers and should be complete. Acceptable titles of the node extensions are shown below: 3.2.R.1 Pharmaceutical and Biological availability 3.2.R.1.1 Overview 3.2.R.1.2 Reference product/s (local and foreign) 3.2.R.1.3 Certificates of Analysis 3.2.R.1.4 Pharmaceutical availability studies 3.2.R.2 Parent API Manufacturer with various sites 3.2.R.3 Certificates of suitability with respect to the Ph.Eur. (CEPs) 3.2.R.4 Multiple API manufacturers 3.2.R.5 Medical device 3.2.R.6 Materials of animal and-or human origin 3.2.R.7 Batch records of samples 3.2.R.8 Other Please Note: the Titles of Node Extensions cannot be changed during the life cycle. If a different title was used in a earlier sequences of a legacy application, continue to use that title and accept this validation warning, otherwise it will cause an Error under Criteria 3.5.4.
3.4.12CEP/CPQ Naming ConventionWarning
What it checks. All content provided in 3.2.R.3 must have a leaf title that begins with "CEP" or "CPQ" or "SAHPRA APIMF Approval Letter".
3.5.1Multiple operations on the same document in the same Sequence are not allowedError
What it checks. Checks for documents in the ICH backbone, which are used as modified-file more than once.
3.5.2Leaf operation attributeError
What it checks. With this criterion the following checks are performed: All leaves with an operation attribute value of new, replace or append must have a value for the cross reference (xlink:href) All leaves with an operation attribute value of delete must have no value for the cross reference (xlink:href) All leaves with an operation attribute value of replace, delete or append must have a value for modified-file Only new operations are being used in the initial Sequence No modified-file can be provided where the new operation is used
3.5.3Modified file existenceError
What it checks. The modified-file link within the XML leaf element is valid, i.e., the target exists.
3.5.4Do not relocate ContentError
What it checks. When revisions are sent to a regulatory authority, the new leaf element should be submitted in the same location in the backbone as the leaf element being appended, replaced or deleted. This also applies for content referenced within node extensions.
3.5.5Use of AppendError
What it checks. Any use of 'append' outside the defined usage in Study Tagging Files should be cleared with the authority before submission and explained in the cover letter.
3.5.6Detect invalid lifecycle pattern: Append operations causing branchesError
What it checks. This refers to scenarios where an append operation is being applied on a leaf, which has already been replaced by another leaf.
3.5.7Detect invalid lifecycle pattern: Delete operations causing branchesError
What it checks. This refers to scenarios where a delete operation is being applied on a leaf, which has already been replaced by another leaf.
3.5.8Detect invalid lifecycle pattern: Replace operations causing branchesError
What it checks. This refers to scenarios where a replace operation is being applied on a leaf, which has already been replaced by another leaf.
3.5.9Detect invalid lifecycle pattern: Operation on deleted leaf contentError
What it checks. This refers to scenarios where an operation is being applied on a leaf, which has been deleted already. From a technical perspective, the 'Multiple Delete' pattern is a sub-pattern of this pattern.
3.5.10Detect invalid lifecycle pattern: Append operations not appending to most recent STF leafError
What it checks. For STF leaf elements the append operation should not reference the leaf where the STF has been added initially but the most recent update to this file. So in contrast to the other leaf elements, for STF nodes the "append on append" is what is expected.
3.5.11Replace should not provide content identical to the previous fileWarning
What it checks. When replacing content, the new content should be different from the previous content.
3.5.12ICH File reuseInfo
What it checks. Identifies file reuse scenarios (same values for xlink:href used multiple times in the regional backbone for this Sequence). Information is collected because content reuse is encouraged, and this information assists the evaluation process. .
3.6.1Missing Content in section 3.2.SInfo
What it checks. A summary of all sections missing content in 3.2.S will be provided for all "New" Submission Types with sequence type 'Initial'.
3.6.2Missing Content in section 3.2.PInfo
What it checks. A summary of all sections missing content in 3.2.P will be provided for all "New" Submission Types with sequence type 'Initial'.
4 - South African Regional
4.1.1Module 1 (regional xml file) existsError
What it checks. The regional backbone za-regional.xml file must exist in folder m1/za.
4.1.2The regional backbone file must be valid.Error
What it checks. Performs XML validation for regional backbone. Uses the Schema given in the application folder (util/dtd).
4.2.1MD5 ChecksumError
What it checks. The MD5 checksums for all referenced files must match the checksums to the values provided in the backbone file.
4.2.2Attribute checksum-typeError
What it checks. The checksum-type attribute must have the value md5 or MD5.
4.2.3HTML Rendition of Regional BackboneInfo
What it checks. If the za-regional.html is present, the checksum of the za-regional.xml should match the checksum listed in the za-regional.html file.
4.3.1The reference to the Schema in za-regional.xml is directed to the Schema provided in the util folder.Error
What it checks. Refer to Root Element provided in the SAHPRA eCTD Module 1 and Regional Information Specification and Guidance for Use
4.3.2The files referenced by the cross reference must existError
What it checks. The files referenced by the cross reference (xlink:href) must exist
4.3.3Only relative references are being usedError
What it checks. Only relative references (href and modified-file) are allowed. Also, only forward slashes '/' are allowed (no backslashes). Ensure that the file references in the regional index file use relative paths. Absolute (i.e., rooted) paths are not allowed.
4.3.4References to targets outside ApplicationInfo
What it checks. References (xlink:href) to files outside the Application will be identified. Information is collected because content reuse is encouraged, and this information assists the evaluation process.
4.3.5References to targets outside SequenceInfo
What it checks. References (xlink:href) to files outside Sequence will be identified. Information is collected because content reuse is encouraged, and this information assists the evaluation process.
4.4.1Element must have leafError
What it checks. All the lowest level heading elements included in the submission (including node-extensions) contain at least one leaf.
4.4.2Leaf title must not be emptyError
What it checks. For operations other than 'delete', all leaves must have a 'title' child. The title must be present.
4.4.3Node Extensions are appropriately placedWarning
What it checks. Checks to make sure node extensions are not used where SAHPRA-Regional subheadings already exist or at a level that is not the lowest level of a defined structure.
4.4.4Node Extension title must not be emptyError
What it checks. For node extensions, the title child must be present (value must be present).
4.5.1Multiple operations on same document in same Sequence are not allowedError
What it checks. Checks for documents in the regional backbone, which are used as modified-file more than once.
4.5.2Leaf operationsError
What it checks. With this criterion the following checks are performed: All leaves with an operation attribute value of new, replace or append must have a value for the cross reference (xlink:href) All leaves with an operation attribute value of delete must have no value for the cross reference (xlink:href) All leaves with an operation attribute value of replace, delete or append must have a value for modified-file Only new operations are being used in the initial Sequence No modified-file can be provided where the new operation is used
4.5.3Modified file existenceError
What it checks. The modified-file link within the XML leaf element is valid, i.e., the target exists.
4.5.4Do not relocate ContentError
What it checks. When revisions are sent to a regulatory authority, the new leaf element should be submitted in the same location in the backbone as the leaf element being appended, replaced or deleted. This also applies for content referenced within node extensions. Using the operation attribute 'delete' to remove content from sections in ZA m1 which are no longer used due to updates of the CTD, should be exempt from this rule.
4.5.5Use of AppendError
What it checks. Any use of 'append' outside the defined usage in Study Tagging Files is not allowed.
4.5.6Detect invalid lifecycle pattern: Append operations causing branchesError
What it checks. This refers to scenarios where an append operation is being applied on a leaf, which has already been replaced by another leaf.
4.5.7Detect invalid lifecycle pattern: Delete operations causing branchesError
What it checks. This refers to scenarios where a delete operation is being applied on a leaf, which has already been replaced by another leaf.
4.5.8Detect invalid lifecycle pattern: Replace operations causing branchesError
What it checks. This refers to scenarios where a replace operation is being applied on a leaf, which has already been replaced by another leaf.
4.5.9Detect invalid lifecycle pattern: Operation on deleted leaf contentError
What it checks. This refers to scenarios where an operation is being applied on a leaf, which has been deleted already. From a technical perspective, the "Multiple Delete" pattern is a sub-pattern of this pattern.
4.5.10Replace should not provide content identical to the previous fileWarning
What it checks. When replacing content, the new content should be different from the previous content if a physical file is being provided.
4.5.11Regional File ReuseInfo
What it checks. Identifies file reuse scenarios (same values for xlink:href used multiple times in the regional backbone for this Sequence). Information is collected because content reuse is encouraged, and this information assists the evaluation process.
4.5.12Letter of Application operation attributeError
What it checks. Letter of Application (1.0.1) must have 'new' operation attribute.
4.5.13Note to Evaluator operation attributeWarning
What it checks. Note to Evaluator (1.0.2) must have 'new' operation attribute.
4.5.14Correspondence from SAHPRA operation AttributeWarning
What it checks. Correspondence from SAHPRA (1.0.3) must have 'new' operation attribute.
4.5.15Response to SAHPRA Request operation AttributeWarning
What it checks. Response to SAHPRA Request (1.0.4) must have 'new' operation attribute.
4.5.16Application Form operation attributeWarning
What it checks. Application Form (1.2.1) must have 'new' operation attribute. Not for submission types Withdrawal and Cancellation. For more information please refer to the Guidance for the Submission of Regulatory Information in eCTD format.
4.5.17Proof of Payment operation attributeWarning
What it checks. Proof of Payment (1.2.2.1) must have 'new' operation attribute. Not for submission types Withdrawal and Cancellation. For more information please refer to the Guidance for the Submission of Regulatory Information in eCTD format.
4.5.18Electronic Copy Declaration operation attributeWarning
What it checks. Electronic Copy Declaration (1.2.2.4) must have 'new' operation attribute. Not for submission types Withdrawal and Cancellation. For more information please refer to the Guidance for the Submission of Regulatory Information in eCTD format.
4.5.19Validation Templates (Checklists) operation attributeWarning
What it checks. Validation Templates (Checklists) (1.2.5) must have 'new' operation attribute. Not for submission types Withdrawal and Cancellation, as here a validation template is not required. For more information please refer to the Guidance for the Submission of Regulatory Information in eCTD format.
4.5.20Tabular Schedule of Amendments operation attributeWarning
What it checks. Tabular Schedule of Amendments (1.5.2.1) must have 'new' operation attribute. For more information please refer to the Guidance for the Submission of Regulatory Information in eCTD format.
4.5.21Professional Information (PI) operation attribute (including all subnodes)Warning
What it checks. Any subsequent leaf for all content provided in the Professional Information (PI) (1.3.1.1) element must have 'replace' operation attribute once it has been added initially with 'new'.
4.5.22Reference Product - Local operation attribute (including all subnodes)Warning
What it checks. Any subsequent leaf for all content provided in the Reference Product - Local (1.3.1.2.1) element must have 'replace' operation attribute once it has been added initially with 'new'.
4.5.23Patient Information Leaflet operation attribute (including all subnodes)Warning
What it checks. Any subsequent leaf for all content provided in the Patient Information Leaflet (PIL) (1.3.2) element must have 'replace' operation attribute once it has been added initially with 'new'.
4.5.24Labels operation attribute (including all subnodes)Warning
What it checks. Any subsequent leaf for all content provided in the Labels (1.3.3) element must have 'replace' operation attribute once it has been added initially with 'new'.
4.5.25Foreign Prescribing and Patient Information operation attributeWarning
What it checks. Any subsequent leaf for all content provided in the Foreign Prescribing and Patient Information (1.3.5) element must have 'replace' operation attribute once it has been added initially with 'new'.
4.5.26Artwork and Pictures of Samples operation attributeWarning
What it checks. Any subsequent leaf for all content provided in the Artwork and Pictures of Samples (1.3.6.2) element must have 'replace' operation attribute once it has been added initially with 'new'.
4.5.27Batch Manufacturing Record of the Sample operation attributeWarning
What it checks. Any subsequent leaf for all content provided in the Batch Manufacturing Record of the Sample (1.3.6.3) element must have 'replace' operation attribute once it has been added initially with 'new'.
4.5.28CoA of the Sample operation attributeWarning
What it checks. Any subsequent leaf for all content provided in the CoA of the Sample (1.3.6.4) element must have 'replace' operation attribute once it has been added initially with 'new'.
4.5.29Date of Last Inspection of each Site operation attributeWarning
What it checks. Any subsequent leaf for all content provided in the Date of Last Inspection of each Site (1.7.1) element must have 'replace' operation attribute once it has been added initially with 'new'.
4.5.30Latest GMP Certificate or a Copy of the Appropriate Licence operation attributeWarning
What it checks. Any subsequent leaf for all content provided in the Latest GMP Certificate or a Copy of the Appropriate Licence (1.7.3) element must have 'replace' operation attribute once it has been added initially with 'new'.
4.5.31Confirmation of Contract operation attributeWarning
What it checks. Any subsequent leaf for all content provided in the Confirmation of Contract (1.7.5) element must have 'replace' operation attribute once it has been added initially with 'new'.
4.5.32SAPC Registration operation attributeWarning
What it checks. Any subsequent leaf for all content provided in the SAPC Registration (1.7.7) element must have 'replace' operation attribute once it has been added initially with 'new'.
4.5.33Inspection Flow Diagram operation attributeWarning
What it checks. Any subsequent leaf for all content provided in the Inspection Flow Diagram (1.7.12) element must have 'replace' operation attribute once it has been added initially with 'new'.
4.5.34Organogram operation attributeWarning
What it checks. Any subsequent leaf for all content provided in the Organogram (1.7.13) element must have 'replace' operation attribute once it has been added initially with 'new'.
4.5.35Risk Management Plan operation attributeWarning
What it checks. The Risk Management Plan (1.8.2) should have 'replace' operation attribute once it has been added initially with 'new'.
4.5.36Tabulated List of Foreign Regulatory Status operation attributeWarning
What it checks. Any subsequent leaf for all content provided in the Tabulated List of Foreign Regulatory Status (1.10.1) element must have 'replace' operation attribute once it has been added initially with 'new'.
4.6.11.0.1 Letter of Application must existError
What it checks. Checks to make sure a Letter of Application has been provided for every sequence.
4.6.21.0.4 Response to Input Request must exist if the Sequence Type is 'Response'Error
What it checks. Checks to make sure the response document has been provided in every "response" Sequence.
4.6.7Provide New Source FilesWarning
What it checks. For all files with operation "new" in the following sections, both PDF and source files (.docx or .rtf) must be provided (for eSubmissions the check is for all files provided): 1.2.1 Application Form(s) 1.2.5 Checklist - Validation Template 1.3.1.1 Professional Information (PI) 1.3.2 Patient Information Leaflet (PIL) 1.3.3 Labels 1.5.6 Generic Applications (BTIF) 1.5.7 Abridged Applications 3.2.R.8 QOS 3.2.R.8 QIS 3.2.R.8 SCORE
4.6.8Provide Replaced Source FilesWarning
What it checks. For all files with operation "replace" in the following sections, both PDF and source files (.docx or .rtf) must be provided: 1.2.1 Application Form(s) 1.2.5 Checklist - Validation Template 1.3.1.1 Professional Information (PI) 1.3.2 Patient Information Leaflet (PIL) 1.3.3 Labels 1.5.6 Generic Applications (BTIF) 1.5.7 Abridged Applications 3.2.R.8 QOS 3.2.R.8 QIS 3.2.R.8 SCORE
4.6.9Delete File where Source Files are requiredWarning
What it checks. The 'delete' Operations in sections... 1.2.1 Application Form(s) 1.2.5 Checklist - Validation Template 1.3.1.1 Professional Information (PI) 1.3.2 Patient Information Leaflet (PIL) 1.3.3 Labels 1.5.6 Generic Applications (BTIF) 1.5.7 Abridged Applications 3.2.R.8 QOS 3.2.R.8 QIS 3.2.R.8 SCORE ...have to be applied to both the PDF and corresponding source file (.docx or .rtf)
4.6.10Provide at most ONE document per sequence per the SAHPRA M1 Granularity AnnexWarning
What it checks. At most ONE file is provided in the following sections per sequence: 1.0.1 Letter of application 1.0.2 Note to Evaluator 1.2.2.2 Letter of authorisation of pharmacist signing the dossier 1.2.2.4 Electronic Copy Declaration 1.2.2.5 Curriculum Vitae of the Person Responsible for Pharmacovigilance 1.2.2.9 Declaration of Sameness for Replicas and Clones 1.2.2.10 Letter of Permission from HCR for Replica 1.2.3.1 Letter of Authorisation from Product Owner to New Registrant 1.2.3.2 Written Confirmation of Hand-over of Dossier 1.2.4 Patent Declaration 1.3.4 Braille 1.4.1 Quality 1.4.2 Nonclinical 1.4.3 Clinical 1.5.2.1 Tabulated Schedule of Amendments 1.5.2.2.1 Medicines Register Details 1.5.2.3 Affidavit by Responsible Pharmacist 1.6.1 Non-GMO (Genetically Modified Organisms) 1.6.2 GMO (Genetically Modified Organisms) 1.7.1 Date of Last Inspection of each Site 1.7.5 Confirmation of Contract 1.7.8 Registration with Registrar of Companies 1.7.12 Inspection Flow Diagram 1.7.13 Organogram 1.8.2 Risk Management Plan 1.9 Individual Patient Data - Statement of Availability 1.10.1 Tabulated List of Foreign Regulatory Status
4.7.1aEnvelope: applicationError
What it checks. See specification and guidance documentation regarding Constraint and Occurrence.
4.7.1bEnvelope: application (Attribute Code Validity)Error
What it checks. The attribute code value must be valid and active (e.g., not expired) at the time of the sequence-date indicated in the sequence section of the envelope.
4.7.2aEnvelope: application-idError
What it checks. For legacy applications, the Application Folder should be used as Application ID. For new eCTD applications, the Application ID issued by the SAHPRA Application Portal should be used. See specification and guidance documentation regarding Constraint and Occurrence.
4.7.2bEnvelope: application-id is the same as the Application folderError
What it checks. The Application ID and the Application Folder (Root Folder) must be the same.
4.7.3Envelope: application-numberError
What it checks. See specification and guidance documentation regarding Constraint and Occurrence.
4.7.4Envelope: proprietary-nameError
What it checks. See specification and guidance documentation regarding Constraint and Occurrence.
4.7.5Envelope: dosage-formError
What it checks. See specification and guidance documentation regarding Constraint and Occurrence.
4.7.6Envelope: innError
What it checks. See specification and guidance documentation regarding Constraint and Occurrence.
4.7.7aEnvelope: apimf-numberInfo
What it checks. Provide a report that lists the APIMF Number(s) provided AND the content provided under 3.2.R.3.
4.7.8aEnvelope: pmf-numberWarning
What it checks. See specification and guidance documentation regarding Constraint and Occurrence.
4.7.8bEnvelope: pmf-number provided when PMF content includedWarning
What it checks. If content is provided in section... 1.2.2.8 EMA Certificate for a Plasma Master File (PMF) a PMF Number is provided in the Envelope
4.7.9aEnvelope: vamf-numberWarning
What it checks. See specification and guidance documentation regarding Constraint and Occurrence.
4.7.9bEnvelope: vamf-number provided when VAMF content includedWarning
What it checks. If content is provided in section... 1.2.2.7 EMA Certificate for a Vaccine Antigen Master File (VAMF) a VAMF Number is provided in the Envelope
4.7.10Envelope: smf-numberError
What it checks. See specification and guidance documentation regarding Constraint and Occurrence.
4.7.11aEnvelope: submissionError
What it checks. See specification and guidance documentation regarding Constraint and Occurrence.
4.7.11bEnvelope: submission (Attribute Code Validity)Error
What it checks. The attribute code value must be valid and active (e.g., not expired) at the time of the sequence-date indicated in the sequence section of the envelope.
4.7.11cEnvelope: submission (Multiple Submissions in eCTD)Info
What it checks. Information is provided if multiple submissions are listed in a single sequence.
4.7.11dEnvelope: submission (Submission Combination Validity)Error
What it checks. See SAHPRA Submission Type Matrix. This rule checks if the combination of multiple submission types is allowed.
4.7.11eEnvelope: submission (Application Withdrawal not allowed as only sequence of an Application)Error
What it checks. It is not allowed to submit a sequence with the Submission Type 'Application Withdrawal/Cancellation' if no other sequences exist.
4.7.12aEnvelope: evaluation-pathError
What it checks. See specification and guidance documentation regarding Constraint and Occurrence.
4.7.12bEnvelope: evaluation-path (Attribute Code Validity)Error
What it checks. The attribute code value must be valid and active (e.g., not expired) at the time of the sequence-date indicated in the sequence section of the envelope.
4.7.12cEnvelope: evaluation-pathway (Multiple Submissions)Error
What it checks. If a sequence contains multiple submissions, each of the submissions must have the same evaluation pathway.
4.7.13aEnvelope: submission-leadError
What it checks. See specification and guidance documentation regarding Constraint and Occurrence.
4.7.13bEnvelope: submission-lead (Attribute Code Validity)Error
What it checks. The attribute code value must be valid and active (e.g., not expired) at the time of the sequence-date indicated in the sequence section of the envelope.
4.7.14Envelope: submission-numberError
What it checks. See specification and guidance documentation regarding Constraint and Occurrence.
4.7.15aEnvelope: sequenceError
What it checks. See specification and guidance documentation regarding Constraint and Occurrence.
4.7.15bEnvelope: sequence (Attribute Code Validity)Error
What it checks. The attribute code value must be valid and active (e.g., not expired) at the time of the sequence-date indicated in the sequence section of the envelope.
4.7.16Envelope: sequence-descriptionError
What it checks. See specification and guidance documentation regarding Constraint and Occurrence.
4.7.17aEnvelope: sequence-dateError
What it checks. See specification and guidance documentation regarding Constraint and Occurrence. Date should be provided in YYYY-MM-DD.
4.7.17bEnvelope: sequence-date (Not outdated)Warning
What it checks. Checks to see if the sequence date is no more than 30 days away from the current date.
4.7.18aEnvelope: sequence-numberError
What it checks. See specification and guidance documentation regarding Constraint and Occurrence.
4.7.18bEnvelope: sequence-number (Must match Sequence Folder name)Error
What it checks. Sequence folder name must match sequence-number from envelope
4.7.19aEnvelope: related-sequence-numberError
What it checks. See specification and guidance documentation regarding Constraint and Occurrence.
4.7.19bEnvelope: related-sequence-number (Number value)Error
What it checks. The numeric value of the related-sequence-number element must be the same or lower than the Sequence Number being validated.
4.7.19cEnvelope: related-sequence-number (Sequence Type 'Initial' references itself)Error
What it checks. All Sequences with the sequence-type 'Initial' should reference themselves in the related-sequence-number attribute.
4.7.20aEnvelope: multiple-applicationsError
What it checks. See specification and guidance documentation regarding Constraint and Occurrence.
4.7.20bEnvelope: multiple-applications (Attribute Values)Error
What it checks. The attribute values for "proprietary-names" and "application-numbers" should be provided. The values must be unique if more that one multiple-applications Envelope Element is provided.
4.7.21aEnvelope: contactError
What it checks. See specification and guidance documentation regarding Constraint and Occurrence.
4.7.21bEnvelope: contact (Attribute Code Validity)Error
What it checks. The attribute code value must be valid and active (e.g., not expired) at the time of the sequence-date indicated in the sequence section of the envelope.
4.7.22Envelope: contact-nameError
What it checks. See specification and guidance documentation regarding Constraint and Occurrence.
4.7.23Envelope: contact-emailError
What it checks. See specification and guidance documentation regarding Constraint and Occurrence.
4.8.1Required documents and prohibited documentsError
What it checks. See SAHPRA Document Matrix. This rule checks for missing documents, which are required in the Submission Type being submitted AND for documents present which are prohibited for the Submission Type being submitted. If one or more of these required documents are not present, or one or more of the prohibited documents are present, it will lead to a validation error and the Sequence being rejected.
4.8.2Expected documents and documents that should not be providedWarning
What it checks. See SAHPRA Document Matrix. This rule checks for missing documents, which are expected in the Submission Type being submitted AND for documents present which should not be submitted for the Submission Type being submitted. If one or more of the expected documents are not present, or if one or more of the undesired documents are present, it will lead to a validation warning and can possibly lead to the Sequence being rejected during screening or evaluation.
4.8.3Possible DocumentsInfo
What it checks. See SAHPRA Document Matrix. This rule checks for documents marked as possibly required in certain circumstances for a particular Submission Type. A list of the sections where content has been provided will be created by the validator for review purposes in content screening. The absence of a required document could lead to the Sequence being rejected.
4.8.4Content ChecklistInfo
What it checks. See SAHPRA Document Matrix. This rule checks for all expected documents of a particular Submission Type. A list of all the sections marked 'E', 'W', or 'P' should be provided including Section, Heading Element Title, Rule Severity (E, W, or P), and Status (whether the document is present or not). This will be used for review purposes in content screening by SAHPRA and should be used by the Applicant as a confirmation checklist. The eventual goal is to simplify, improve, and automate sections of the the Validation Templates in the future. Note: Items marked NV or Not Yet Defined should not be included in the Checklist.
5 - STF
5.1.1Check index referenceError
What it checks. The files from the xlink:href references must exist.
5.1.2Check index reference (title match)Warning
What it checks. The titles from the doc-content elements must match the corresponding leaf title values from the ICH backbone.
5.1.3No backslash in xlink:href referenceError
What it checks. The xlink:href values must not contain backslashes
5.1.4STF leaf elements must reference other STF leaf upon appendError
What it checks. STF leaf elements must reference other STF leaf upon append. Such leaf elements must not reference PDF files as modified files.
5.1.5STF cannot reference another STFWarning
What it checks. Leaf references in STFs must always target content files, not STFs.
5.1.6STF files must reference at least one leafWarning
What it checks. Any STF that does not relate to any leaf elements will be reported here
5.1.7Cumulative STF files are not allowedError
What it checks. STFs must reference files in the same sequence
5.2.1Content Blocks are not acceptedWarning
What it checks. Using content-block elements must be avoided.
5.2.2Study Identifier category must not be emptyWarning
What it checks. The value of the study-identifier/category element must not be empty.
5.2.3Study Identifier study-id must not be emptyWarning
What it checks. The value of the study-identifier/study-id element must not be empty.
5.2.4Study Identifier title must not be emptyWarning
What it checks. The value of the study-identifier/title element must not be empty.
5.2.5Categories and file tagsWarning
What it checks. Checks file tag values and category values against definitions in valid-values.xml file
5.2.6Category information must be provided for certain STFsWarning
What it checks. ICH eCTD STF Specification V 2.6.1 3-June-2008: The category element provides an additional level of study organization not currently provided by the eCTD DTD. This element is only relevant for studies provided in the specific CTD sections cited below: - 4.2.3.1 Single dose toxicity (grouped by species and route of administration) - 4.2.3.2 Repeat dose toxicity (grouped by species, route of administration, and duration if applicable) - 4.2.3.4.1 Long term [carcinogenicity] studies (grouped by species) - 5.3.5.1 Study reports of controlled clinical studies pertinent to the claimed indication (grouped by type of control)
5.2.7Invalid STF TOC locationWarning
What it checks. STFs should only be associated with certain headings under Modules 4 or 5.
5.2.8STF doc-content file tag countWarning
What it checks. There should be one and only one file tag for each doc-content.
5.3.1Study ID for STF must remain constantWarning
What it checks. The STF study IDs must not change in the application lifecycle.
5.4.1Informational output about the number and total size of non E3 documents.Info
What it checks. Sample: Non E3 study files Total size (KB): 133.76 Number of 16.3 files: 3 Number of US files: 4 Number of JP files: 1
6 - PDF Analysis
6.1.1PDF documents must be readableError
What it checks. Checks for any corrupted/unreadable PDF documents, including documents which cannot be opened because the content is invalid or the page count is 0.
6.2.1Bookmarks must be relativeWarning
What it checks. Retrieves all non-relative bookmarks in PDF documents and prints the total count.
6.2.2Bookmarks with web or email destinationsWarning
What it checks. Retrieves all web link bookmarks and e-mail bookmarks in PDF documents and prints the total count.
6.2.3Bookmarks with destinations outside repository root folder are not allowedWarning
What it checks. Retrieves all bookmarks other than web links and e-mail links from PDF documents to destination outside the repository root folder (the folder above the application folder) and prints the total count.
6.2.4Bookmarks must not have multiple actionsWarning
What it checks. Bookmarks with multiple actions assigned (e.g., opening two different pages) must be avoided.
6.2.5Bookmarks must not be inactiveWarning
What it checks. Retrieves all inactive bookmarks (bookmarks without any action assigned) in PDF documents and prints the total count.
6.2.6Bookmarks must not be brokenWarning
What it checks. Retrieves all broken bookmarks in PDF documents and prints the total count.
6.2.7Bookmarks must be 'Inherit Zoom'Warning
What it checks. All bookmarks should have a magnification setting of "Inherit Zoom". This rule performs the corresponding checks for bookmarks.
6.2.8Bookmarks should exist in all larger documentsWarning
What it checks. Bookmarks should exist in all documents with more than 5 pages except for... Batch Records of Samples (1.3.6.3, 3.2.R.7) Literature References (2.7.5, 3.3, 4.3, 5.4) Process Validation and/or Evaluation (3.2.P.3.5)
6.2.9Bookmarks meet ISO 32000-1:2008 requirementsWarning
What it checks. All bookmarks between two PDFs must be configured as specified in ISO 32000-1:2008
6.3.1Hyperlinks must be relativeWarning
What it checks. Retrieves all non-relative hyperlinks from PDF documents and prints the total count, including the broken ones.
6.3.2Hyperlinks with destinations outside repository root folder are not allowedWarning
What it checks. Retrieves all hyperlinks other than web links and e-mail links from PDF documents to destination outside the repository root folder (the folder above the application folder) and prints the total count.
6.3.3Hyperlinks must not have multiple actionsWarning
What it checks. Hyperlinks with multiple actions assigned (e.g., opening two different pages) must be avoided.
6.3.4Hyperlinks must not be inactiveWarning
What it checks. Retrieves all inactive hyperlinks (hyperlinks without any action assigned) in PDF documents and prints the total count.
6.3.5Hyperlinks must not be brokenWarning
What it checks. Retrieves all broken hyperlinks from PDF documents and prints the total count.
6.3.6Hyperlinks must 'Inherit Zoom'Warning
What it checks. All hyperlinks should have a magnification setting of "Inherit Zoom". This rule performs the corresponding checks for hyperlinks.
6.3.7Hyperlinks must exist in the Validation TemplatesWarning
What it checks. For all "New Applications", the references in Sections B to D of the Validation Template in section 1.2.5 should be hyperlinked to the respective documents in the eCTD.
6.3.8Hyperlinks must exist in Patient Information Leaflet to the Professional InformationWarning
What it checks. For all "New Applications", the Patient Information Leaflet placed in 1.3.2 must contain hyperlinks to the Professional Information in 1.3.1.1.
6.3.9Hyperlinks must exist in the Professional InformationWarning
What it checks. For all "New Applications", the Professional Information in 1.3.1.1 must contain hyperlinks to the sections of the application referenced.
6.3.10Hyperlinks must exist in the Tabulated Schedule of AmendmentsWarning
What it checks. The references in the Tabulated Schedule of Amendments 1.5.2.1 should be hyperlinked to the relevant documents dealing with the recommendations and responses. See 'Amendments' guideline and Guidance for the Submission of Regulatory Information in eCTD format
6.3.11Hyperlinks meet ISO 32000-1:2008 requirementsWarning
What it checks. All hyperlinks between two PDFs must be configured as specified in ISO 32000-1:2008
6.3.12Hyperlinks with web or email destinationsInfo
What it checks. Retrieves all web links and e-mail links from PDF documents and prints the total count.
6.4.1PDF documents should not have any security settingsError
What it checks. Do not submit PDF files with security settings that limit the ability to select text or graphics, or make other changes. This prevents agencies from copying text and taking other actions with submitted documents. Files in the sections 33-lit-ref, 43-lit-ref, 54-lit-ref are excluded from this check.
6.4.2PDF documents must not be password protectedError
What it checks. Do not submit documents that use password protection and cannot be opened.
6.4.3PDF version must be correctWarning
What it checks. Checks all PDF document versions against the list of allowed versions (1.4-1.7).
6.4.4PDF documents with attachments are not allowedWarning
What it checks. This check examines PDF documents and reports all documents having any attachments.
6.4.5PDF initial view must be correctWarning
What it checks. Checks for PDF documents with an incorrect initial view. ICH eCTD Specification: Documents with bookmarks must show the bookmarks pane in their initial view. Documents without bookmarks should not show the bookmarks pane in their initial view. The Magnification and Page Layout should be set as "default".
6.4.6PDF should have 'Fast Web Access' activeWarning
What it checks. Do not submit PDF documents that have been created without 'Fast Web Access' active.
6.4.7PDF documents with annotationsWarning
What it checks. Finds all documents, which contain annotations (other than links and bookmarks)
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 SAHPRA’s criteria at SAHPRA’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 SAHPRA eCTD validation rule mean?
An Error must be corrected before SAHPRA accepts the sequence. Warnings should be corrected; Info findings are for awareness.
How do I validate a sequence before sending it to SAHPRA?
Run it through a validator that applies SAHPRA’s current criteria at SAHPRA’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 SAHPRA’s published criteria. Always confirm against SAHPRA’s current documents before relying on a single rule.
Catch every SAHPRA finding before SAHPRA does
See DnXT Publisher validate a sequence against SAHPRA’s criteria while it is being built.
Criteria are summarised from SAHPRA’s published validation criteria for information. SAHPRA’s own documents are authoritative.
