The objective of this article is to provide validation updates of Health Canada. The Canadian Health Agency will be using the electronic Common Technical Document (eCTD) and non- electronic Common Technical Document (non-eCTD) validation rules version 5.0. The purpose of the updated validation rules is for the successful dispatch of the dossier to the Agency without any errors and warnings. Amendment to the validation rules for Health Canada is to help the sponsors to avoid submission rejection due to errors and warnings in the submissions and to avoid time consuming follow-ups. The errors detected by the Agency will be sent to the sponsors in a Zip format. These amendments will come into effect for all Health Canada submissions from November 01, 2020. This article mainly focuses on file characters, size, type, document properties, naming conversion, metadata and XML elements that help in understanding the Agency requirements for dossier dispatch.
Health Canada is the Agency responsible for the wellbeing of the Canadians by ensuring high-quality health services and minimising the health risks. Regulatory submissions for Health Canada can be done in both electronic Common Technical Document (eCTD) and nonelectronic Common Technical Document (non-eCTD) formats. However, they need to comply with the validation rules provided by the health authority to avoid rejections and follow-ups. Health Canada keeps amending these validation rules to assist the sponsors for the successful dispatch of the submissions. The Agency will be using the recently updated version of validation rules (version 5.0) for eCTD and non-eCTD submissions effective from November 01, 2020. Upon submissions, the Agency will detect and notify the validation failures to the sponsors in a .zip format, which must be reviewed, corrected and resubmitted with the necessary modifications. Recent updates in the validation rules mainly focus on file characters, size, type, document properties, naming conversion, metadata and XML elements.
Health Canada eCTD and non-eCTD format updated validation rules (version 5.0) are broadly classified as:
Validation Criteria for Regulatory Submissions in the eCTD format
This section mainly discusses the files (documents) and folders in the sequence of the submission. In a sequence folder structure, there should not be any empty files and subfolders present. Also, the files should be opened without any security access permission for the viewer. The file size should not exceed 200 MB for PDF and 100 MB for XPT documents, respectively. The sequence of the submission that is validated should be the highest in the application folder. A proper sequence lifecycle should be seen in the application folder. While validating the current sequence, the previous sequence should be made available; otherwise, the validation will throw errors. Word documents should be in the readable format and no password is allowed while submitting the dossier.
PDF documents should be in a readable format and should not be damaged. Bookmarks and hyperlinks should be active, relative and should have a magnification setting of ‘Inherit Zoom.’ There should not be any password-protected documents. Document properties such as PDF version, page layout, magnification, fast web view should match ICH eCTD criteria.
Referring to the other files (Hypertext Reference – HREF) within the application is allowed as per the ICH eCTD specification. The operational attribute of the files for the initial sequence should always be new.
All the files should have only one file extension. The sequence number should be followed by subfolder M1 which in turn followed by subfolder ‘CA’. All the documents and leaf should have appropriate naming fulfilling the ICH eCTD criteria. The leaf title should not be left blank. The application number should start with the letter ‘e’ for all CA submissions. Replaced files should have identical content as referenced files. The cover letter should not exceed more than three (3) pages. Node extensions in module 1 backbone (ca-regional. xml) are not allowed, except in 1.2.6 - Authorization for Sharing Information, 1.2.7 - International Information and 1.6.1 - Comparative Bioavailability Information Also, the node extension title should not be left empty. No ‘append’ operation is allowed in Module 1.
Checksum type attribute should have MD5 value. Index and MD5 checksum files should exist. The utility folder should be present in M1. The number of leaves directly under a single node must not exceed 1000. The rule applies only to module 5 while using node extensions and also to leaves with operation attribute ‘new’. Do not mention strength values in the dosage form attribute in the sections 2.3.P, 3.2.P, 3.2.A.1 or 3.2.A.2. Any numeric value found in these attribute values will be reported as an error. If the strength value was already present in the previous sequence, the rule will not report an error for the current sequence. Leaf elements in 3.2.R Regional Information heading must be provided using node extensions. PDF fi are not allowed as leaf elements directly under 3.2.R Regional Information heading.
The value of the study-identifier/category/study-id/title element must not be empty. STF leaf element must reference another STF leaf upon append. Category information must be provided for certain STFs. Leaf references in the STFs should always target content files, not STFs. The STF study IDs should not be changed in the application life cycle. There should be only one file tag for each doc-content. If Study Tagging Files (STFs) are used in the current validating sequence being validated, the node 5.3.7 must not be used. The Case Report Forms must be referenced from the STFs. The previous sequences present in the same dossier will not be checked. Leaf elements present in module 4 (except those in subsection 4.3), with an operation attribute ‘new,’can use either node extensions, STFs or may be placed directly under the TOC sections. Leaf elements, with an operation attribute ‘new,’ in subsections 5.3.1, 5.3.2, 5.3.3, 5.3.4, 5.3.5 & 5.3.7 must use only node extensions or STFs. Although both node extensions and STFs are acceptable for study reports, only one or the other approach must be used consistently throughout the lifecycle of a leaf. Also, in a specific sequence, all leaf elements must use the same approach.
All empty folders must be deleted before submitting the transaction to Health Canada. Check the size of each file before submitting, to ensure it does not exceed the maximum file size limit (200 MB). File extensions written in uppercase letters are not accepted and no manual change is allowed. The document should not have password protection and should be in a readable format.
Before submitting to Health Canada, ensure PDF documents are not password protected. The acceptable PDF versions are 1.4, 1.5, 1.6, and 1.7 and ensure the PDF documents are created using acceptable PDF versions. All the bookmarks must have only one assigned action that should open the destination page. The settings should be verified in the bookmark properties. Ensure that the PDF document does not include attachments/portfolio documents. PDF documents exceeding 10 pages should have bookmarks except for literature references in sections 3.3, 4.3 & 5.4; and Health Canada application e-forms.
File path length character includes the file name, and the count starts at the application folder. The correct structure path for a non-eCTD transaction is x123456\m1.
Health Canada has updated the validation rules for Regulatory transactions submitted in the eCTD and non-eCTD formats. The purpose of the validation rules is to help sponsors in providing a valid electronic transaction to Health Canada and reduce errors and followups. Sponsors can use a commercially available tool to validate their Regulatory transactions in eCTD and non-eCTD formats, before filing them to Health Canada. Health Canada validates each Regulatory transaction and if the errors are detected, a Validation Report describing the errors will be sent to the sponsor. So, it is very important to file a submission to the Health Authority without any errors and warnings by complying with the ICH specifications and by validating the submissions which in turn results in approval of license to the product for marketing and human use.