Health Canada
Symbol of the Government of Canada

Common menu bar links

Drugs and Health Products

Consultation Document - Draft Guidance Document: Preparation of Drug Regulatory Activities in Electronic Common Technical Document (eCTD)

The online consultation is now closed. The content found on this page is a snapshot of the live consultation as it was presented to the public and contains the content that was open for submissions during the consultation period.

Help on accessing alternative formats, such as Portable Document Format (PDF), Microsoft Word and PowerPoint (PPT) files, can be obtained in the alternate format help section.

On this page:

Notice

March 30, 2012

Our file number: 12-104291-460

Re: Draft Guidance Document: Preparation of Drug Regulatory Activities in Electronic Common Technical Document (eCTD)

Health Canada is pleased to announce the release of the Draft Guidance Document: Preparation of Drug Regulatory Activities in Electronic Common Technical Document (eCTD) for a 60-day consultation period. Once final, it will replace the 2009 Guidance for Industry: Preparation of Drug Submissions in Electronic Common Technical Document Format.

The guidance document defines the electronic format requirements and process, as well as provides additional guidance on the structure and content of information to be included in regulatory activities in eCTD format. It provides a few examples of documents and their locations in the new structure define in the revised Canadian Module 1 Backbone. It also includes a complete discussion of the eCTD electronic-only filling format and the regulatory activity types now accepted in this filling format:

  • New Drug Submissions (NDS);
  • Supplement to a New Drug Submission (SNDS);
  • Abbreviated New Drug Submission (ANDS);
  • Supplement to an Abbreviated New Drug Submission (SANDS);
  • Periodic Safety Update Reports - Confirmatory (PSUR-C).

The Draft Guidance Document: Preparation of Drug Regulatory Activities in Electronic Common Technical Document (eCTD) is meant to be read in conjunction with the Electronic Common Technical Document Specification (Version 3.2.2), developed by the ICH M2 Expert Working Group, and the corresponding Questions and Answers document on the Next link will take you to another Web site International Conference on Harmonisation (ICH) website <www.ich.org>. Sponsors should also consult the other Health Canada guidance documents and notices on the Health Canada website, as listed in Appendix A of the guidance document.

It is expected that this document will be further modified based on comments received during the consultation period, and as a result of efforts to further harmonize Canadian practice with international standards.

The measures outlined in this guidance are effective immediately since they do not impose an obligation but rather provide more options for submission sponsors. With the exception of the section 3.4.1 Module 1: Administrative and Product Information which will only be usable when the revised Canadian Module 1 Schema is published and adopted, sponsors are encouraged to compile submissions using the most recent Guidance Documents and Notices.

Any updates to eCTD filing requirements will not be applied retroactively to submissions pending review. Furthermore, sponsors may continue to follow the Health Canada guidance documents in effect prior to the date of release of this notice for submissions currently in preparation. Subsequent submissions, however, should be compiled using the most recent guidance documents.

Health Canada has completed the transition to the acceptance of stand-alone submissions in eCTD Format and now accepts all regulatory activities in eCTD electronic-only filling format that are filed in compliance with the ICH eCTD specification. As of March 31, 2012, Health Canada will no longer be accepting regulatory activities in the eCTD hybrid filing format.

Questions and comments relating to this document should be submitted, preferably in electronic format, no later than April 30, 2012 to:

Submission and Information Policy Division (SIPD)
Therapeutic Products Directorate
Health Canada
Finance Building 2,
Address Locator 0201A1
101 Tunney's Pasture Driveway
Ottawa, Ontario
K1A 0K9

Telephone: 613-941-7281
Fax: 613-941-0825
Email: eReview@hc-sc.gc.ca

Draft Guidance Document: Preparation of Drug Regulatory Activities in the Electronic Common Technical Document Format

Foreword

Guidance documents are meant to provide assistance to industry and health care professionals on how to comply with governing statutes and regulations. Guidance documents also provide assistance to staff on how Health Canada mandates and objectives should be implemented in a manner that is fair, consistent and effective.

Guidance documents are administrative instruments not having force of law and, as such, allow for flexibility in approach. Alternate approaches to the principles and practices described in this document may be acceptable provided they are supported by adequate justification. Alternate approaches should be discussed in advance with the relevant program area to avoid the possible finding that applicable statutory or regulatory requirements have not been met.

As a corollary to the above, it is equally important to note that Health Canada reserves the right to request information or material, or define conditions not specifically described in this document, in order to allow the Department to adequately assess the safety, efficacy or quality of a product. Health Canada is committed to ensuring that such requests are justifiable and that decisions are clearly documented.

This document should be read in conjunction with the accompanying notice and the relevant sections of other applicable guidance documents.

Table of Contents

1 Introduction

1.1 Policy Objectives

To integrate the electronic Common Technical Document (eCTD) format within the Canadian drug registration framework by describing the electronic format requirements for drug regulatory activitiesFootnote1 filed pursuant to the Food and Drug Act and Regulations.

To facilitate the preparation of a drug regulatory activity, pursuant to Part C of the Food and Drug Regulations, in the eCTD format.

1.2 Policy Statements

This guidance document is to be used in the preparation and filing of drug regulatory activities to Health Canada in the eCTD electronic-only filing format as established by the International Conference on Harmonisation of Technical Requirements for Registration of Pharmaceuticals for Human Use (ICH). This guidance document reflects recommendations made by the ICH working groups and steering committee, incorporates suggestions made by stakeholders, and describes both new and revised filing requirements.

1.3 Scope and Application

The following regulatory activity (submission) types are eligible for filing in the eCTD format:

  • New Drug Submission (NDS);
  • Abbreviated New Drug Submission (ANDS);
  • Supplement to a New Drug Submission (SNDS);
  • Supplement to an Abbreviated New Drug Submission (SANDS);
  • Notifiable Change (NC);
  • Post-Notice of Compliance (NOC) Changes: Level III, only when related to a previously filed regulatory activity for a dossier in eCTD format;
  • Periodic Safety Update Report - Confirmatory (PSUR-C);
  • Periodic Safety Update Report (PSUR) when submitted to the Marketed Health Products Directorate (MHPD);
  • Risk Management Plan (RMP), when submitted to the MHPD;
  • Other Pharmacovigilance data requested by MHPD;
    • Risk communication document [for example (e.g.) Health Care Professional Letters, mailing lists].
      Note: The eCTD copy should be sent to the Submission and Information Policy Division (SIPD), with an electronic copy being submitted directly to MHPD via email. The eCTD copy should be sent the same day as the electronic copy is emailed.
    • Post Marketing Surveillance (e.g., Safety or Summary Report, Council For International Organizations Of Medical Sciences (CIOMS), Line Listings, Registry Reports or Clinical Study Reports, Patient Exposure Data);
    • Benefit Risk Assessment;
    • Signal Work Up;
    • Response to MHPD Requests for Additional Information;
    • Notification of Change in benefit-risk profile (under sections C.01.018(3) and (4) of the Food and Drug Regulations;
  • Yearly Biologic Product Report (YBPR);
  • Request for Priority Review Status: NDS and SNDS;
  • Pre-Submission Meeting Information;
  • Drug Identification Number Application (DINA);
  • Drug Identification Number - Biologic (DINB);
  • Post-Authorization Division 1 Change (PDC);
  • Post-Authorization Division 1 Change-Biologics (PDC-B).

Regulatory transactions eligible for filing in the eCTD format if related to a previously filed regulatory activity for a dossier (drug product) in eCTD format:

  • Response to a Clarification Request;
  • Response to Notice of Non-compliance (NON), Notice of Deficiency (NOD), Screening Deficiency Notice (SDN);
  • Periodic Safety Update Report (PSUR) requested during the pre-market review process by Therapeutic Products Directorate (TPD) and Biologics and Genetic Therapies Directorate (BGTD);
  • Comments to the Summary Basis of Decision/ Notice of Decision;
  • Second Language Product Monograph;
  • Drug Notification Form (DNF);
  • Any transaction related to the above regulatory activity types are accepted in eCTD format.

A sponsor may file regulatory activities in the paper-based Common Technical Document (CTD) format, have the information approved, and then file subsequent regulatory activities in the eCTD format. In such cases, the sponsor is not expected to refile the previously approved paper-based regulatory activities in eCTD format.

The eCTD format is encouraged for drug/device combinations where the primary mechanism of action is drug-related. Where the combination product is classified as a device, the use of eCTD format for the drug component is also encouraged.

The regulatory activities currently not accepted in eCTD format include, but are not limited to:

  • Clinical Trial Application or Amendment (CTA or CTA-A);
  • Natural Health Product (NHP) application;
  • Drug Master File (DMF);
  • Site Reference File (SRF);
  • Medical Devices - Licence Application or Amendment (LAp or LAm);
  • Lot Release documentation;
  • Adverse Reaction Reports for MHPD.

Health Canada will inform sponsors when additional regulatory activities types may be filed in eCTD format.

1.4 Background

The preparation and filing of a regulatory activity and additional information in eCTD format is strongly recommended but remains optional. Sponsors who choose to file a regulatory activity in eCTD format must comply with the specifications included in this guidance document, in Health Canada's Guidance for Industry: Creation of the Canadian Module 1 Backbone, as well as the Electronic Common Technical Document Specification (Version 3.2.2, July 16, 2008) and the corresponding Questions and Answers, developed by the ICH M2 Expert Working Group (EWG). Regulatory activities and additional information in eCTD format that do not comply with these requirements will not be accepted.

Sponsors should also consult the following documents:

  • Health Canada's Notice and Questions and Answers for this guidance document for supplementary or interim guidance on regional issues; and
  • Related Health Canada guidance documents and notices on the Health Canada website, as listed in Appendix A.

It is important to note that the implementation and use of eCTD format represents a work in progress. Future refinements to this guidance document will continue to be necessary.

2 Implementation Considerations

2.1 Additional Information and Subsequent Regulatory Activities

Once a sponsor files a regulatory activity in eCTD format, all additional information and subsequent regulatory activities for the same dossier should be filed in eCTD format. Sponsors should not revert to paper-based CTD format. Providing additional information and subsequent regulatory activities in eCTD format will enable life cycle management of the dossier (see Section 4.3, "Life Cycle Management"), and facilitate the review process. The recommendation to continue submitting in eCTD format does not apply to CTAs submitted after the Notice of Compliance (NOC) has been issued.

Throughout this guidance document, when additional information is generally referred to, solicited and unsolicited information should be understood (See Appendix C: Definitions).

Multiple responses to clarification requests can be bundled on a single disk and submitted together in the electronic format. However, each of the electronic responses should be filed using a separate sequence number. Responses to requests for clarification should otherwise conform to procedures described in Health Canada's Guidance for Industry: Management of Drug Submissions, Section 5.2.6, "Responses to Clarification Requests".

In the case of regulatory activities in eCTD format, if the review is completed before the electronic response to a clarification request is filed; the issuance of the NOC may be delayed because the electronic response is required to complete the legal document.

The response to a clarification request in eCTD format should be sent directly to the SIPD. Though not mandatory, it is suggested that a summary of the response in Question and Answer format be faxed directly to the requestor. To ensure compliance with the due date, the electronic response in eCTD format should be sent the same day as the summary is faxed.

2.2 Filing Formats of Regulatory Activities in Electronic Common Technical Document Format

Health Canada's structured approach to the implementation of eCTD format for regulatory activities specified three filing formats, each characterized by whether and to what extent the regulatory activity was accompanied by a paper-based activity in CTD format.

Table 1: Implementation Considerations for the Three Filing Formats
Issue Co-submission Hybrid Submission Electronic-only Submission
Portion of submission in paper-based Common Technical Document (CTD) format Complete submission in Electronic Common Technical Document (eCTD) format with complete submission in paper-based CTD format. Complete submission in eCTD format with partial submission in paper-based CTD format of Modules 1 and 2. Complete submission in eCTD format without any submission in paper-based CTD format.
Legal record The paper-based submission in CTD format remains the legal document. The electronic submission in eCTD format is the legal document. The electronic submission in eCTD format is the legal document.
Signature Wet ink signature is required. Scanned copy of signed document is required. Scanned copy of signed document is required.
Letter of Attestation for submission and additional information Letter of Attestation stating that material in the submission or additional information in eCTD format exactly matches material in CTD format. Letter of Attestation stating that Modules 1 and 2 in partial submission in CTD format exactly match Modules 1 and 2 in eCTD format. Not applicable (N/A).
Technical pre-submission consultation Technical pre-submission consultation recommended. Technical pre-submission consultation required. Technical pre-submission consultation required.
Print on demand Not applicable (N/A). See Appendix D. See Appendix D.
Calendar No longer accepted by Health Canada since January 2010. As of the publication of this draft guideline, sponsors are encouraged to transition to electronic only filing format. Will no longer be accepted by Health Canada as of April 1, 2012. Accepted as of January 2012 for all regulatory activities accepted in eCTD format.

3 Structure and Content of a Regulatory Activity in Electronic Common Technical Document Format

Health Canada's information requirements for regulatory activities in eCTD format are the same as they are for those filed in the paper-based CTD format. Health Canada's Guidance for Industry: Preparation of Drug Submissions and Applications in the CTD Format and corresponding ICH guidance documents on the CTD format outline the modular structure and content of paper-based regulatory activities in CTD format.

It is necessary to understand the distinction between the eCTD structure and the folder structure. A folder is the organizing unit for a computer operating system and the unit in which electronic files are stored and accessed on a computer.

Windows Explorer®, for example, provides the means for storing, saving, viewing, and accessing files in folders on a computer using the Windows operating system. Figure 1 illustrates a portion of the folder structure for storing files in a regulatory activity in eCTD format, as seen using Windows Explorer®.

The eCTD structure is the rendering of the regulatory activity through its organization in an eXtensible Markup Language (XML) backbone. The rendered XML backbone is equivalent to the table of contents of a hard-copy document. The eCTD structure is presented through an XML viewing tool. Figure 2 illustrates a portion of the eCTD structure, as seen using an XML viewing tool. While Figure 2 shows a regulatory activity with one regulatory transaction (sequence), Figure 3 illustrates a portion of the eCTD structure of a regulatory activity with multiple regulatory transactions (sequences).

3.1 Cover Letter

Health Canada strongly recommends that all regulatory activities and subsequent additional information in the eCTD format be accompanied by an administrative cover letter in both paper and portable document format (PDF). In addition to the content recommended by ICH, Health Canada also requires the following:

  • All cover letters should clearly state what is being submitted, including reference to the request letter (if applicable) and a brief description of the package;
  • All cover letters for response to requests for clarification should clearly state the name of the requester (is it requester or requestor see below)
  • If a Periodic Safety Update Report (PSUR) is to be submitted, one of the following types should be indicated in the cover letter:
    • VOLUNTARY PSUR - unsolicited information;
    • REQUESTED PERIODIC PSUR - requested by Health Canada (for example Risk Management Plan (RMP) follow-up or post-authorization commitment);
    • REQUESTED AD HOC PSUR - submitted as a one-time request made by either the pre-market review directorate reviewing the associated regulatory activity or by MHPD (the requestor should be specified in the cover letter);
    • PSUR-C (confirmatory) - submitted to support the fulfillment of a Notice of Compliance with Conditions (NOC/c);
  • For regulatory activities in eCTD electronic-only filing format, please indicate in bold capital letters 'eCTD' in the subject line of the cover letter.
  • The cover letter should not contain any scientific information. The summary response in a question and answer format in response to Health Canada issued correspondence and the Note to Reviewer should not be included in the cover letter, since they have been assigned a specific location (1.0.4 and 1.0.7).
  • Manufacturer / applicant's name;
  • Brand name;
  • eCTD identifier;
  • Central Registry (CR) file number (if known);
  • Regulatory Activity type;
  • Control number (if known);
  • Sequence number;
  • Any cross-referenced regulatory activity should be clearly stated (date the regulatory activity was approved);
  • Contact information for the eCTD publisher, including the email address where the Validation Report should be sent, as needed;
  • For regulatory transactions that contain an HC-SC3011 form, a table structured as below should be inserted at the end of the cover letter:
Type of Submission (Type of Regulatory Activity) Box 5 of HC-SC3011 form
Drug Product Box 64 of HC-SC3011 form
Brand Name Box 8 of HC-SC3011 form
Common Name Box 9 of HC-SC3011 form
Company Name DIN Owner Box 11 of HC-SC3011 form
Legal Address of DIN owner Boxes 12-16 of HC-SC3011 form
Proposed Indication Box 67 of HC-SC3011 form
Dosage Form Box 60 of HC-SC3011 form
Route of Administration Box 63 of HC-SC3011 form
Medicinal (active) Ingredients Box 56 of HC-SC3011 form
Ingredient Name Strength Unit Per Calculated as Base (Yes/No)
         
         

3.2 Life Cycle Management Table

Sponsors should include a Life Cycle Management Table describing all sequence numbers and how they relate to each other. It should contain the information indicated by the column titles in Table 2, "Example Life Cycle Management Table". The most recent entries should be listed last. A completed example of a Life Cycle Management table can be found in Appendix E.

Table 2: Example Life Cycle Management Table

Sponsor Name:
Brand Name:
eCTD Identifier:
Sequence Number Date Submitted
(mmm.dd,yyyy)
Control Number Related Sequence Sequence Description
         

3.3 Folder Structure and File Naming Convention

For an illustration of the folder structure, see Figure 1.

3.3.1 Top Level Folder and eCTD Identifier

The top level folder of a dossier in eCTD format contains all other folders and their content. The name for the top level folder of the dossier in eCTD format is the eCTD Identifier number obtained from Health Canada (e.g., e123456 in Figure 1). This number is the unique identifier for the dossier related to a specific drug product. Regulatory activities and additional information in eCTD format for the same dossier should retain the same identifier. The eCTD Identifier is created by Health Canada (see Section 5.5, "Obtain eCTD Identifier").

3.3.2 Sequence Number Folder

All files and folders in a regulatory transaction are to be placed under the sequence number folder, as described in the ICH Electronic Common Technical Document Specification (Version 3.2.2), "File Names and Directory Structure," p. 6-1 and 6-2. The sequence number folder should be named using a four-digit number.

The sequence number folder includes an m1 subfolder, m2-m5 subfolders (optional), and a util subfolder (see Figure 1). The eCTD backbone file (index.xml) and the checksum file (index-md5.txt) should be in the sequence number folder.

The sequence number for the first regulatory transaction for a dossier should be 0000. Each time a sponsor submits new information for that dossier, the sponsor should provide an incremental number, unique within the same dossier, for the sequence number folder in which the new information is placed.

When building an information package to re-file a sequence that has failed validation, the sequence number should be kept the same as the one that failed. When building a new regulatory transaction, e.g. a response to a clarification request or a SDN, the sequence number should be incremented.

3.3.3 Module 1 Folder

The structure and content of the Module 1 folder (m1) is defined in Health Canada's Guidance for Industry: Creation of the Canadian Module 1 Backbone. Sponsors should use the most recent version of the Canadian Module 1 Schema posted on the Health Canada website. The m1 folder contains a ca folder which contains the Canadian Module 1 Backbone file (ca-regional.xml) and all Module 1 content files. The ca folder should not contain any subfolders.

3.3.4 Modules 2 to 5 Folders

The structure and content of the Modules 2 to 5 folders (m2-m5) are defined in the ICH Electronic Common Technical Document Specification, Health Canada's Guidance for Industry: Common Technical Document (CTD) Format for Drug Products, and other relevant guidance documents listed in Appendix A.

3.3.5 util and dtd Folders

The util folder contains a dtd folder. The dtd folder should contain the Canadian Module 1 Schema file (ca-regional-v2.xsd), used to define the Canadian Module 1 Backbone, and related files (xlink.xsd and xml.xsd). The dtd folder should also contain the ICH eCTD DTD (ich-ectd-3-2.dtd) used to define the eCTD backbone file (index.xml).

3.3.6 Content File Naming Convention

Choice of file naming convention is up to the sponsor. To assist sponsors, this subsection presents an example of a naming convention for content files for Module 1. Health Canada suggests that file names begin with the sequence number, followed by "ca", followed by the module and, if applicable, the section number, and then a phrase describing the contents of the file. All components of the file name can be divided by hyphens.

The following are examples of the file naming convention for Module 1:

  • 0000-ca-m101-cover-letter.pdf
  • 0000-ca-m107-general-note-to-reviewer.pdf
  • 0000-ca-m131-annotated-pm.pdf
  • 0001-ca-m131-pristine-pm.doc
  • 0001-ca-m131-note-to-reviewer-pm.pdf

Exception to the above is the Drug Submission Application Form that must be named according to the convention below:

  • hc-sc-3011-en.pdf OR hc-sc-3011-fr.pdf

ICH requires that the file names be limited to a maximum of 64 characters, including the file extension. See the ICH Electronic Common Technical Document Specification (Version 3.2.2), "Name", p. 2-3. Meaningful abbreviations, such as PM for Product Monograph, can be used to shorten file names.

3.4 Electronic Common Technical Document Structure and Leaf Title

For an illustration of the eCTD structure, see Figure 2.

3.4.1 Module 1: Administrative and Product Information

The following are a subset of documents and their locations in the eCTD structure, when required:

The cover letter should be filed as a leaf element under the m1-0-1-cover-letter heading.

The Life Cycle Management Table should be filed as leaf elements under the m1-0-2-life-cycle-management-table heading.

The copy of the original request issued by Health Canada, such as requests for clarification, SDN, NON, and NOD, should be filed as leaf elements under the m1-0-3-copy-of-health-canada-issued-correspondence heading.

The summary responses in a Question and Answer format should be filed as leaf elements under the m1-0-4-health-canada-solicited-information heading. The responses should not be included in the cover letter.

The Product Monograph (PM) certification form should be filed as a leaf element under the m1-2-3-certification-and-attestation-forms heading.

The Level III Changes forms should be filed as leaf elements under the m1-2-8-post-authorization-information heading.

The "BE data sets" (see Section 4.1, "File Formats", of this guidance document) should be filed as leaf elements under the m1-6-1-comparative-bioavailability-information heading.

Notes to reviewers are not a requirement, but since sponsors occasionally include them, the following guidelines are provided to promote a consistent approach to naming them and placing them within the regulatory activity:

  • A Note to Reviewer that addresses the regulatory activity as a whole should be filed as a leaf element under the m1-0-7-general-note-to-reviewer heading. The title of the leaf should be "Note to Reviewer",
  • A Note to Reviewer that is specific to a section should be filed as the first leaf element in that section. For example, a Note to Reviewer that addresses the PM should be filed as a leaf element under the m1-3-1-product-monograph heading. The title of the leaf should be "Note to Reviewer PM".
3.4.2 Modules 2 to 5

If new or updated information is required in response to a clarification request, SDN, NON, NOD, or other solicited information, then that information should be filed in the same location within Modules 2 to 5 as the information it replaces, and the modified-file attribute used to associate it with the information to which it relates. For further information about the modified-file attribute, see the ICH Electronic Common Technical Document Specification (Version 3.2.2), "Operation Attribute," pp. 6-3.

Drug Master File (DMF)

The "Applicant Part (AP)" of the Drug Master File (DMF) should be included in section m3-2-s of the eCTD for a regulatory activity referencing a DMF. If there is more than one DMF used for the active substance(s), each DMF "Applicant's/Sponsor's Part" should be provided in its own m3-2-s section, distinguished by appropriate eCTD metadata values, leaf titles and file names.

If the sponsor has their own quality documents relating to the active substance, in addition to those provided by the DMF owner, then these should be placed in their own m3-2-s section. This section should be identified by suitable metadata values to distinguish it from the content provided by the DMF owner(s).

When the sponsor incorporates the "Applicant Part" of the DMF into a regulatory activity, there is no need to rename the leaf titles and files that were used in the original DMF. The figures below are an example of an ANDS that refers to two different DMF Owners (CompanyY Ltd and CompanyX Inc.) as well as content from the sponsor. These have been identified in the metadata and the naming of the folders.

Periodic Safety Update Report (PSUR)

The PSUR should be filed as a leaf element under the m5-3-6-report-of-postmarketing-experience heading.

Case Report Forms (CRFs)

Case Report Forms (CRFs) and individual patient data listings should be filed as leaf elements under the m5-3-7-case-report-forms-and-individual-patient-listings heading. According to the ICH Electronic Common Technical Document Specification (Version 3.2.2), "Module 5 Clinical Study Reports", p. 3-13, the filing of CRFs within a regulatory activity should be decided on a regional basis. Health Canada prefers that CRFs be organized according to the following principles:

  • They should be filed under Section 5.3.7;
  • They should be organized by study name within Section 5.3.7 using node extensions; and
  • Any further breakdown in the organization of CRFs should be developed during discussion with reviewers at the regulatory pre-submission meeting.

Study Reports

If the study report is broken into multiple files, the files should be organized using node extensions.

Study Tagging Files (STF)

Files organized with Study Tagging Files (STFs) will be accepted but are not required. However, if STFs are included, they must pass validation. If a United States Food and Drug Administration (FDA) application containing STFs is modified by removing the STFs, the Study files and the Case Report Form (CRF) files must be organized using node extensions. The CRF files must be moved to section 5.3.7.

Literature References

The Literature References related to the PM should be filed as a leaf element under the m5-4-literature-reference heading.

Yearly Biologic Product Reports (YBPR)

When the Yearly Biologic Product Report (YBPR) is provided as a single document, it should be filed as a leaf element under the m3-2-r-4-yearly-biologic-product-reports heading.

When the YBPR is provided as multiple documents, the "YBPR", the "Analysis of Adverse Drug Reaction" and the "Recalls", should be filed as leaf elements under the m3-2-r-4-yearly-biologic-product-reports heading and all other documents listed in section 5.1 of the Guidance for Sponsors: Lot Release Program for Schedule D (Biologic) Drug should be filed as leaf elements under the appropriate headings in module 3.

In both of the cases indicated above, the CPID should be submitted as a separate document, filed as a leaf element under the m1-4-1-certified-product-information-document heading.

3.4.3 Leaf Titles

Health Canada recommends that the leaf title of the cover letter be:

Cover Letter mmm. dd, yyyy (e.g Jul. 05, 2004)

Health Canada recommends that the leaf title of the form for Post NOC Changes: Level III to be:

Level III Changes yyyy (year submitted)

The file extension is an attribute of the file that will appear in the viewing tool. Health Canada's eCTD viewing tool displays icons that differentiate between PDF and Microsoft Word documents, therefore sponsors should not specify the format of a document in the title of the leaf.

Incorrect: Pristine Product Monograph.MS Word
Correct: Pristine Product Monograph

Incorrect: Cover Letter.PDF
Correct: Cover Letter Jul. 05, 2004

Sponsors should not include the numbering of the heading in the title of the leaf, because this is redundant and confusing for the reviewer.

Incorrect: 1.3.1 Product Monograph
1.3.1 Annotated Product Monograph

Correct: 1.3.1 Product Monograph
Annotated Product Monograph

See Figure 2 for an example.

4 Technical Requirements for Regulatory Activities in Electronic Common Technical Document Format

4.1 File Formats

The ICH Electronic Common Technical Document Specification (Version 3.2.2) requires the provision of components of the regulatory activity in eCTD format as PDF files (versions 1.4 to 1.7).

Health Canada recommends that sponsors also provide versions of specific documents in their original word-processed format. The required hyperlinks to related information should be included in the PDF version of files, not the word-processed versions. The following components should be provided in both PDF and word-processed format:

  • Product Monograph (PM);
  • Quality Overall Summary (QOS);
  • Certified Product Information Document (CPID);
  • Responses to a clarification request, SDN, NON, and NOD.

Note: For PMs, the annotated and second language versions should only be submitted in PDF and the non-annotated and pristine versions should only be submitted in word-processed format.Footnote2 For the CPID, the annotated version should only be submitted in PDF. The clean version should only be submitted, once requested, in word-processed format.

Any time that a sponsor provides both PDF and word-processed files, the leaf elements pointing to these files should be included under the same heading. See Figure 2 for an illustration.

The "BE data sets" must be provided in ASCII format. See Health Canada's Guidance for Industry: Preparation of Comparative Bioavailability Information for Drug Submissions in the CTD Format, Appendix B: Computer Format for the Submission of Data for Comparative Bioavailability Studies.

PDF versions of documents should be generated from electronic source documents and not from scanned material, except where the source electronic files are not available or where a signature is required. See the ICH Electronic Common Technical Document Specification (Version 3.2.2), "Source of Electronic Document," and "Methods for Creating PDF Documents and Images," p. 7-3.

4.2 Media for Submitting Electronic Data in Electronic Common Technical Document Format

The media formats acceptable when submitting an eCTD regulatory activity are:

  • Compact Disc-Recordable (CD-R) conforming to the Joliet specification;
  • Digital Versatile Disc-Random Access Memory (DVD-RAM) Universal Disc Format (UDF) standard;
  • Digital Versatile Disc-Recordable (DVD+R/-R) recorded in the Universal Disc Format (UDF) standard;
  • Single and dual layer Blu-ray discs;
  • Universal Serial Bus Version 2.0 [Universal Serial Bus (USB) 2.0] drive;
  • Portable External Hard Drive with USB 2.0 interface.

These are the formats that are currently supported. Contact SIPD for other formats that may be acceptable at the time of filing. See Appendix B for full contact information.

Media should not be password protected.

Please note if USB drives and Portable External Hard Drives are used, they will not be returned to the sponsor.

Sponsors should provide all documents on a single disc/drive. Duplicate copies are not required.

All media should be labelled. The labels on the disc/drive should contain the following information:

  • Sponsor name and brand name;
  • eCTD Identifier and sequence number;
  • Control number, if known;
  • "Protected B"Footnote 3;
  • Virus-free certification, the software used for the virus check, and the date of the virus definition file or files; and
  • Month and year of filing.

Subsequent to burning the CD or DVD or transferring data to a drive, sponsors should ensure that all files can be opened and that no files are corrupt.

4.3 Life Cycle Management

When dealing with a regulatory activity in eCTD format, it is important for Health Canada to be able to establish the location of that activity in relation to the life cycle of its dossier. The following sections outline how Health Canada suggests handling the life cycle at the dossier, regulatory activity and document layer.

For further information on life cycle management, see the ICH Electronic Common Technical Document Specification (Version 3.2.2), "Life Cycle Management", pp. 6-2 and 6-3.

4.3.1 Life Cycle Management at the Dossier Layer

The eCTD Identifier links all regulatory activities to the original regulatory activity of a dossier. See Figure 6 for an illustration of how various types of regulatory activities are linked by the eCTD Identifier.

4.3.2 Life Cycle Management at the Regulatory Activity Layer

The related-sequence-number element describes the relationship of additional information to the original or subsequent regulatory activity. For life cycle management at the regulatory activity layer, the related-sequence-number element should be treated as described:

  • For all regulatory activity types (such as NDS, SNDS, including administrative regulatory activities) when first filed, the related-sequence-number element should be empty.
  • For all additional information, the related-sequence-number element should be the sequence number of the regulatory activity to which the additional information applies. The related-sequence-number element should only be one sequence number.

Figure 7 is an illustration of how the related-sequence-number is used to describe the relationship of additional information to the original and subsequent regulatory activities.

4.3.3 Life Cycle Management at the Document Layer

Granularity of the document goes hand in hand with life cycle management. Adequate life cycle management is difficult without proper granularity at the document layer.

The operation attribute in the leaf element describes the relationship of content files within the dossier. See Figure 9 (page 30) for an illustration.

The operation attributes used to manage the life cycle of Word and WordPerfect documents should be the same as the attributes used to describe their counterparts in PDF.

General Rules for Use of Operation Attributes

In general, how the operation attributes "append" and "replace" should be used is related to how the content of a document is managed. The operation attribute "replace" should be used when the additional information and the previously submitted information are provided as a consolidated document. The operation attribute "append" should be used when the additional information submitted is used to build upon previously submitted information, without resubmitting it.

For example, in Section 3.2.P.8.3, Stability Data, if in sequence 0000, stability data for one year are provided in one document, and then when sequence 0001 is submitted to update the stability data, two options are possible. The first option is to create a new document that includes the first year of data plus the additional year of data. In this instance, the operation attribute should be "replace." The second option is to create a new document that includes only the additional year of data. In this instance, the operation attribute should be "append."

The "append" operation attribute should not be used to link files that are split because they would otherwise exceed the 100 megabyte limit. Instead, proper file management using an adequate level of granularity will ensure that no file exceeds the limit.

Health Canada does not recommend using the operation attribute to modify a document twice in the same sequence. Health Canada instead recommends proper document management, which would be the consolidation or modification of the document itself.

For figures illustrating the general rules, see Appendix H.

4.3.5 Rules for Use of Operation Attributes for Specific Documents

For life cycle management at the document layer, the operation attribute should be treated as described below for specific documents. For further information, see the ICH Electronic Common Technical Document Specification (Version 3.2.2), "Operation Attribute" p. 6-3.

  • For all content files provided as part of the first regulatory activity to Health Canada and given the sequence number 0000, the operation attribute in the leaf element should be "new".
  • For the cover letter and notes to reviewers' leaf elements provided with all sequence numbers, the operation attribute should always be "new".
  • For the Life Cycle Management Table leaf element provided with sequence number 0000, the operation attribute should be "new". For the leaf element provided with all other sequence numbers, the operation attribute should be "replace".
  • For the copy of the original request and the summary of responses in a Question and Answer format leaf elements provided with all sequence numbers, the operation attribute should always be "new".
  • For the Level III Changes form leaf element provided with all sequence numbers, the operation attribute should always be "new".
  • For the Drug Submission Application Form (3011 form) leaf element:
    • When provided with all types of regulatory activities (such as NDS, ANDS), the operation attribute should be "new";
    • When provided as additional information for a correction of an error in the 3011 form in response to Health Canada requests, such as SIPD queries, screening clarification, and SDN, the operation attribute should be "replace".
  • For the inner and outer label leaf elements (see Figure 8 for a graphic representation):
    • For draft inner and outer label leaf elements provided for the first time the operation attribute should be "new". For the leaf element provided with all other sequence numbers, the operation attribute should be "replace".
    • For final inner and outer label leaf elements provided for the first time with the Drug Notification Form (DNF) the operation attribute should be "new". For the leaf element provided with all subsequent DNF, the operation attribute should be "replace".
  • For Pre-Submission Meetings:
    • For all content files provided as part of the Pre-Submission Meeting Package, the operation attribute in the leaf element should be "new", with the possible exception of the Life Cycle Management (LCM) table. When a document is revised in relation to a pre-submission meeting, the operation attribute should be "replace".
    • For all content files provided in an NDS/ANDS submitted subsequent to a pre-submission meeting, the operation attribute in the leaf element should be "new", with the exception of the LCM table. The NDS/ANDS should be a stand-alone regulatory activity. Any information provided in relation to pre-submission meeting, if needed in the NDS/ANDS, should be resubmitted, with the exception of meeting minutes, which may be hyperlinked.
    • For an SNDS/SANDS submitted subsequent to a pre-submission meeting, the operation attribute 'replace' should be used as needed in relation to the previous sequences (with the exception of any sequences related to pre-submission meetings). If the SNDS/SANDS is the first regulatory activity in eCTD format, other than the pre-submission meeting, the operation attribute in the leaf element should be "new" for all content files provided, with the exception of the LCM table. The SNDS/SANDS should be a stand-alone regulatory activity. Any information provided in relation to pre-submission meeting, if needed in the SNDS/SANDS, should be resubmitted, with the exception of meeting minutes, which may be hyperlinked.
  • For the PM leaf element (see Figure 9 for a graphic representation):
    • When a non-annotated or annotated PM is provided as part of the first transaction of a regulatory activity (such as NDS, SNDS) the operation attribute should be "new";
    • When a non-annotated or annotated PM is provided in response to a clarification request, SDN, NOD, or a NON, the operation attribute should be "replace";
    • When a pristine PM is provided for the first time, the operation attribute should be "new" and the last non-annotated and annotated PMs provided as part of that regulatory activity should be assigned the operation attribute of "delete"; and when a pristine PM is provided to replace a previously approved pristine PM, the operation attribute should be "replace" and the last non-annotated and annotated PMs provided as part of that regulatory activity should be assigned the operation attribute of "delete".
  • For the Certified Product Information Document (CPID) leaf element (see Figure 10, for a graphic representation);
    • When an annotated CPID is provided with a regulatory activity (NDS, ANDS) the operation attribute should be "new" (a CPID does not have to be provided at time of filing);
    • When an annotated CPID is provided as part of the first transaction of a regulatory activity (such as SNDS, SANDS) the operation attribute should be "new";
    • When an annotated CPID is provided as additional information in response to a clarification request, SDN, NOD, or a NON, the operation attribute should be "replace";
    • When a clean CPID is provided for the first time, the operation attribute should be "new" and the most recent annotated CPID provided as part of that regulatory activity should be assigned the operation attribute of "delete"; and
    • When a clean CPID is provided to replace a previously approved clean CPID, the operation attribute should be "replace" and the most recent annotated CPID provided as part of that regulatory activity should be assigned the operation attribute of "delete".

4.4 Bookmarks in Portable Document Format (PDF) Files

It is important that PDF files be properly bookmarked. Rules of thumb for good bookmarking include:

  • Documents of ten pages or more should be bookmarked.
  • Bookmarks are equivalent to and should be organized like a document table of contents, and should not include the submission (regulatory activity) level.
  • Sections, subsections, tables, figures, and appendices should all be bookmarked.
  • Too many levels of bookmarks are inefficient; in most instances, four levels of bookmarks should be sufficient:
    • 1 Heading
      • 1.1 Subheading
        • 1.1.1 Sub-subheading
          • 1.1.1.1 Sub-Sub-Subheading

Health Canada recognizes that bookmarks are generated automatically from document headings, but nevertheless recommends they be kept concise.

4.5 Hyperlinks and Cross-References

In a regulatory activity in eCTD format, hyperlinks should be used wherever cross-references were used in the CTD format (e.g., annotations of PMs). The ICH Electronic Common Technical Document Specification requires other hyperlinks which should also be added.

Hyperlinks should be provided throughout a regulatory activity to aid efficient navigation to annotations, related sections, publications, appendices, tables, and figures that are not located on the same page. Overuse of hyperlinks lengthens the processing of the regulatory transaction and may create confusion for the reviewers; therefore their use should be well thought out.

There should also be consistency in the way navigational aids are provided. Within each document, bookmarks and hyperlinks from the table of contents should be provided to all tables, figures, publications, and appendices.

With the exception of tables of contents, hyperlinks should be indicated typographically with blue text or a blue box around the text. Health Canada prefers that hyperlinks be spelled out as cross-references with explicit citations of module, and section, as appropriate.

Hyperlinks are not expected for word-processed documents.

External hyperlinks currently result in a validation error that would normally cause a regulatory transaction to fail validation. However, including some links to a web page "www.*****" (such as sponsors own websites) or e-mail addresses "*****@****" are acceptable in some labelling documents and literature references. Any external links to information pertinent to the review process will result in a validation failure. Information pertinent to the review process should be included within the regulatory activity as a PDF or another appropriate file type.

4.6 Print on Demand

Health Canada may request portions of Modules 3 to 5 be provided in paper CTD format. For the details about print-on-demand requests, see Appendix D.

5 Filing Process for Regulatory Transaction in Electronic Common Technical Document Format

Figure 8 illustrates the process for preparing and filing regulatory transactions in eCTD format. The steps discussed in the following subsections correspond to the process diagram.

Figure 8: Filing Process for Regulatory Transactions in Electronic Common Technical Document (eCTD) Format.

5.1 Hold Technical Pre-Submission Consultation

Sponsors filing a regulatory activity in eCTD format for the first time are recommended to request a technical pre-submission consultation with Health Canada. This consultation is held to clarify needs, responsibilities, and expectations, and to provide Health Canada the opportunity to offer assistance and guidance for the eCTD filing process. The meeting will not necessarily take place at the same time as the regulatory pre-submission meeting. To request a technical pre-submission consultation, contact SIPD.

Sponsors should include the following information in their requests:

  • The purpose of the meeting;
  • A brief description of the product to be discussed at the meeting;
  • Three proposed dates for the meeting, including whether an afternoon or morning meeting is being requested;
  • Type of meeting requested, in person, teleconference or web conference;
  • An agenda for the meeting; and
  • The names of sponsor representatives attending the meeting.

5.2 File Electronic Common Technical Document Sample

Sponsors filing a regulatory transaction using the eCTD format for the first time are recommended to file an eCTD sample at least four weeks in advance of filing their formal regulatory transaction in eCTD format with Health Canada. This period is not part of and will not delay the review process. Analysis of the sample may serve to identify potential issues before the actual transaction is filed. The filing of an eCTD sample as a preliminary step for subsequent regulatory transactions will depend on various factors, including changes in ICH specifications, changes in the Health Canada Module 1 specifications, and changes in technology (e.g., file formats, new tool used by the sponsor to build the eCTD).

The eCTD Identifier for a sample does not have to be obtained from Health Canada since the sample is not considered for review. The Identifier for the sample should be an "s" followed by the date the sample was created, in the format yymmdd (e.g., s080721).

The eCTD sample can be a partial regulatory activity but should contain, at a minimum, the following files:

  • eCTD backbone file (index.xml);
  • eCTD backbone MD5 checksum file (index-md5.txt);
  • Canadian Module 1 Backbone file (ca-regional.xml);
  • Canadian Module 1 Schema Version 2.0 (ca-regional-v2.xsd, xml.xsd, xlink.xsd);
  • ICH eCTD DTD (ich-ectd-3-2.dtd); and
  • Content files containing sample data.

If a sponsor intends to include them in the regulatory transaction, style sheets and Study Tagging Files should be included in the sample.

The package should include the paper cover letter and the disc containing the eCTD sample. Since the content of the eCTD sample is not reviewed, no paper-based CTD documents are required to be submitted. The package should be sent to SIPD.

5.3 Verify Electronic Common Technical Document Sample

Upon receipt, Health Canada tests the eCTD sample to ensure that it conforms to the requirements outlined in this guidance document, Health Canada's Guidance for Industry: Creation of the Canadian Module 1 Backbone, and the ICH Electronic Common Technical Document Specification. The verification process has two stages, the first of which is manual and includes ensuring that the eCTD Identifier is appropriately used. The second stage of the verification process includes tests conducted to validate the DTD and schema against validation rules published by Health Canada.

During the verification process, the content of the eCTD sample is not reviewed according to the Health Canada evaluation process. Within two weeks of receipt of the sample, Health Canada provides the sponsor with a written eCTD Validation Report outlining the degree of compliance with eCTD requirements. Deficiencies identified during the testing will be included in the report.

5.4 Correct Errors and File Corrected Sample

When Health Canada identifies errors in the eCTD sample, the sponsor corrects the errors and files the corrected eCTD sample with SIPD, only when major processing related errors are identified. If the sponsor wishes to discuss the eCTD Validation Report, the sponsor should contact SIPD.

Health Canada verifies the corrected sample and sends a written eCTD Validation Report to notify the sponsor of any required technical changes prior to the sponsor filing the regulatory activity in eCTD format. This process is iterative; Health Canada will work with the sponsor to increase the probability of an error-free regulatory activity in eCTD format.

5.5 Obtain eCTD Identifier

Prior to filing the first regulatory transaction for a dossier in eCTD format, the sponsor should submit a written request to SIPD via email (ereview@hc-sc.gc.ca) to obtain an eCTD Identifier (see Section 3.3.1, "Top Level Folder and eCTD Identifier"). The request should include the control number of the regulatory pre-submission meeting or a draft 3011 form on which the sponsor has completed Part 1, boxes 8 and 9, and all of Part 1, Section A.

Note that the requirement to obtain an eCTD Identifier from Health Canada does not apply to eCTD samples (see Section 5.2, "File eCTD Sample").

5.6 File Regulatory Transaction in Electronic Common Technical Document Format

The regulatory transaction in eCTD format should be sent to SIPD.

5.6.1 Signature

The documents that legally require a signature should be printed, signed, scanned, saved as PDF files and included in the regulatory transaction.

If only one page of a multi-page document contains a signature, the sponsor should scan the page and then include the scanned page at the same location in the PDF file of the document. Each document should have only one PDF file.

5.6.2 How to provide media

Although this is an electronic-only format, it is strongly recommended that the electronic data on the approved media listed in Section 4.2 "Media for Submitting Electronic Data in eCTD Format" be accompanied with a paper cover letter, as this is the only means by which to quickly identify its contents. The paper cover letter will no longer be needed once Health Canada has a secure electronic transmission of data in place. With the exception of the cover letter, no paper should be submitted to Health Canada.

The cover letter and media should be packaged in an envelope marked 'eCTD'.

5.7 Verify Regulatory Transaction in Electronic Common Technical Document Format

Upon receipt, Health Canada tests the regulatory transaction in eCTD format to ensure that it conforms to the requirements outlined in this guidance document, Health Canada's Guidance for Industry: Creation of the Canadian Module 1 Backbone, and the ICH Electronic Common Technical Document Specification.

The verification process has two stages, the first of which is manual and includes ensuring that the eCTD Identifier is correct. The second stage of the verification process includes tests conducted to validate the DTD and schema, to verify file checksums, and to identify missing files. During the verification process, the content of the regulatory transaction is not reviewed according to the Health Canada evaluation process.

Within 7 calendar days of receipt of the regulatory transaction in eCTD format a written eCTD Validation Report, describing the deficiencies, will be issued to the sponsor for regulatory transactions that fail validation or validate with warnings.

The eCTD version of a response to a clarification request will be validated by Health Canada within the same day if received before noon or on the next business day if received after noon.

5.8 Correct Errors and File Corrected Regulatory Transactions in Electronic Common Technical Document Format

When Health Canada identifies errors in the regulatory transaction in eCTD format, the sponsor corrects the errors highlighted in the eCTD Validation Report and files the corrected regulatory activity with SIPD. If the sponsor wishes to discuss the eCTD Validation Report, the sponsor should contact SIPD. Health Canada verifies the corrected regulatory transaction and notifies the sponsor of any required technical changes. This process is iterative.

If a regulatory transaction fails verification due to a technical error, the sequence number does not change when the transaction is re-filed. If the regulatory transaction passes verification, but has screening deficiencies, then responses to a clarification request or SDN require an increment to the sequence number.

5.9 Upload Regulatory Transaction in Electronic Common Technical Document Format to Server

When the regulatory transaction has passed the verification process, it is uploaded to the Health Canada secure server.

Appendices

Appendix A: Reference Documents

Health Canada References:

The latest versions of these and other Health Canada guidance documents, policies, templates and forms can be obtained from the Health Canada website at:

  • http://www.hc-sc.gc.ca/dhp-mps/prodpharma/applic-demande/index-eng.php
  • http://www.hc-sc.gc.ca/dhp-mps/brgtherap/applic-demande/index-eng.php

Electronic Common Technical Document (eCTD)

  • Guidance for Industry: Preparation of Drug Submissions in eCTD Format, "Questions and Answers"
  • Notice - Health Canada posts validation rules for submissions provided in the eCTD format
  • Guidance for Industry: Creation of the Canadian Module 1 Backbone
  • Canadian Module 1 Schema Version 2.0

Common Technical Document (CTD)

  • Guidance for Industry: Preparation of New Drug Submissions in the CTD Format
  • Guidance for Industry: Preparation of Comparative Bioavailability Information for Drug Submissions in the CTD Format
  • Notice: New Draft Quality Guidances on the Implementation of the Common Technical Document for Biological Products"
  • Guidance for Industry: Preparation of the Quality Information for Drug Submissions in the CTD Format: Biotechnological/Biological (Biotech) Products
  • Guidance for Industry: Preparation of the Quality Information for Drug Submissions in the CTD Format: Blood Products
  • Guidance for Industry: Preparation of the Quality Information for Drug Submissions in the CTD Format: Conventional Biotherapeutic Products
  • Guidance for Industry: Preparation of the Quality Information for Drug Submissions in the CTD Format: Vaccines
  • Certified Product Information Document (Schedule D Drugs) (CPID (Schedule D Drugs)) Template in the CTD Format
  • Notice: Common Technical Document - ICH Topic M4

General

  • Guidance for Industry: Management of Drug Submissions
  • Notice: Health Canada would like to remind sponsors not to include credit card, wire, or cheque payment information within electronic submissions.
  • Guidance Document - Post-Notice of Compliance (NOC) Changes
  • Notice - Post-Notice of Compliance (NOC) Changes: Level III Form

International Conference on Harmonization (ICH) References

The ICH guidelines have been adopted by Health Canada and can be obtained from the ICH website at www.ich.org.

  • Electronic Common Technical Document Specification (Version 3.2.2 )
  • Guidance for Industry M4: The CTD-General Questions and Answers
  • Organisation of the Common Technical Document for the Registration of Pharmaceuticals for Human Use
  • eCTD IWG Question and Answer and Specification Change Request Document

Appendix B: Contacts

Submission and Information Policy Division (SIPD)

Finance Building
101 Tunney's Pasture Driveway
Address Locator: 0201A1
Ottawa, Ontario
K1A 0K9
E-mail: ereview@hc-sc.gc.ca

Appendix C: Definitions

Dossier:
A collection of all regulatory activities throughout the life cycle of a product (e.g. human drug, veterinary drug, medical device, food).
Regulatory Activity:
A collection of all regulatory transactions throughout the process of a specific activity which includes, but is not limited to, NDS, ANDS, DIN Application, YBPR, etc.
Regulatory Transaction:
Any information package sent by the sponsor as part of a Regulatory Activity such as Initial data, unsolicited and solicited data (e.g. response to a clarification request, NON, NOD, pristine PM, DNF etc.).
Additional Information:
Both solicited and unsolicited information. Solicited information includes responses to clarification requests, SDN, NOD or NON. Unsolicited information includes safety information and changes in the name of the sponsor. For more details, see Section 5.5, "Evaluation of Submissions," in Health Canada's Guidance for Industry: Management of Drug Submissions.
Request for Clarification:
A fax requesting clarification, also known as a Clarifax.

Appendix D: Print on Demand

It is assumed that regulatory activities in eCTD format will be screened and reviewed electronically. However, Health Canada may want to review portions of Modules 3 to 5 on a transitory paper copy. Print on demand is meant to be a transitional activity and requests are expected to drop in frequency as Health Canada gains experience in working electronically.

The paper copy provided in response to a print on demand request is a review aid and not a permanent record. It is a transient document and will be securely disposed of after use. In case of discrepancy between the transitory paper copy and the regulatory activity in eCTD format, the regulatory activity in eCTD format is the legal record.

Based on the size or complexity of the requested copy, the printing will be completed either by Health Canada or the sponsor, at the expense of the respective party. The sponsor should provide the copy to Health Canada within a negotiated time to ensure that the performance target is met.

Health Canada will contact the sponsor as soon as the need for a transitory paper copy is identified. This may be when the work is scheduled or during the review process. The earlier the need is assessed, the more flexibility there will be in negotiating a time frame for delivery.

The following parameters for print on demand requests are proposed:

Health Canada will print 500 pages or less in total for each regulatory transaction. Health Canada may give the sponsor the option of providing the printed copy.

For requests of 500 pages or more, the sponsor will provide the transitory paper copy within a negotiated time frame.

The format of the transitory paper copy should comply with the CTD specification. The copy should be accompanied by a cover letter that includes the following information: the control number, sequence number, and the name of the requester. The sponsor should send the copy to SIPD at the address provided in Appendix B.

Appendix E: Example of a Life Cycle Management Table

Sponsor Name: pharmacompany
Brand Name: Drug X
eCTD Identifier: e123454
Sequence Number (most recent last) Date Submitted
(mmm dd, yyyy)
Control Number Related Sequence Sequence Number Description
0000 Jan. 15, 2004 123454 ---- Pre-Submission Meeting
0001 Feb. 29, 2004 123454 0000 Meeting Minutes
0002 May 10, 2004 123455 ---- Priority Review Request
Sequence Number (most recent last) Date Submitted
(mmm dd, yyyy)
Control Number Related Sequence Sequence Number Description
0003 Jul. 05, 2004 123456 ---- Initial
0004 Jul. 10, 2004 123456 0003 Response to Processing Clarification dated Jul 08, 2004 (requester)
0005 Nov. 03, 2004 123456 0003 Response to NOD dated Oct. 01, 2004 (requester)
0006 Feb. 22, 2005 123456 0003 Response to Safety & Efficacy Clarification dated Feb. 10, 2005 (requester)
0007 Apr. 11 , 2005 123456 0003 Unsolicited Data - Safety Update
0008 Jun. 22, 2005 123456 0003 Response to labelling clarification dated  Jun. 20, 2005(requester)
0009 Jul. 25, 2005 123456 0003 Pristine PM
0010 Jan. 09, 2006 123555 ---- Post NOC Change
0011 Mar. 15, 2006 123555 0010 Response to NON dated Mar. 03, 2006 (requester)
0012 Jun 27, 2006 123666 ---- Post NOC Change
0013 Jul. 04, 2006 123555 0010 Response to Quality clarification dated Jun. 22, 2006 (requester)
0014 Jul. 15, 2006 123579 ---- PSUR to MHPD
0015 Jul. 23, 2006 123666 0012 Response to Labelling clarification dated Jul. 08, 2006 (requester)
0016 Aug. 20, 2006 123666 0012 Response to telephone request dated Aug. 18, 2006 (requester)
0017 Sep. 30, 2006 123666 0012 Pristine PM
0018 Sept 12, 2006 ---- ---- Level III Changes
Sequence Number (most recent last) Date Submitted
(mmm dd, yyyy)
Control Number Related Sequence Sequence Number Description
0019 Mar. 5, 2007 123721 ---- YBPR

Appendix F: Life Cycle Management Scenarios for Operation Attributes

The scenarios provided in this appendix describe rules applicable to the general use of the operation attribute for life cycle management. They are examples from a broad range of possibilities. They are not intended to be a comprehensive set and merely address some common situations that sponsors are likely to encounter.

Table F-1: Valid Append Scenarios
Scenario Number and Description Seq. # Leaf ID Attributes Comment
File Ref. Operation Mod. File
1. Append to a New leaf
(EDMS 10)
0000 A0 A0.pdf new Empty Valid new
0001 B1 B1.pdf append A0 Valid append
2. Append to a Replace leaf
(EDMS 21)
0000 A0 A0.pdf new Empty Valid new
0001 A1 A1.pdf replace A0 Valid replace
0002 B2 B2.pdf append A1 Valid append to replace
3. Parallel Appends to a New leaf
(EDMS 28)
0000 A0 A0.pdf new Empty Valid new
0001 B1 B1.pdf append A0 Valid append
0002 C2 C2.pdf append A0 Valid append

Figure F-1: Valid Append Scenarios

Table F-2: Invalid Append Scenario

It is not a valid operation to append to a leaf that has already been appended to a new leaf.
Scenario Number and Description Seq. # Leaf ID Attributes Comment
File Ref. Operation Mod. File
4. Append to an Append leaf
(EDMS 29)
0000 A0 A0.pdf new Empty Valid new
0001 B1 B1.pdf append A0 Valid append
0002 C2 C2.pdf append B1 Invalid append

Figure F-2: Invalid Append Scenario

Table F-3: Valid Replace Scenarios
Scenario Number and Description Seq. # Leaf ID Attributes Comment
File Ref. Operation Mod. File
*When replacing the original document, any appended document must be deleted. Therefore the content of A0.pdf and B1.pdf should be consolidated.
5. Replace a New leaf
(EDMS 8)
0000 A0 A0.pdf new Empty Valid new
0001 A1 A1.pdf replace A0 Valid replace
6. Replace a Replace leaf
(EDMS 19)
0000 A0 A0.pdf new Empty Valid new
0001 A1 A1.pdf replace A0 Valid replace
0002 A2 A2.pdf replace A1 Valid chain replace
7. Replace an Append leaf
(ETICS 3, EDMS 27)
0000 A0 A0.pdf new Empty Valid new
0001 B1 B1.pdf append A0 Valid append
0002 C2 C2.pdf replace B1 Valid replace
8. Replace a New leaf that has an Append leaf, with a leaf that consolidates the content of both
(ETICS 2, EDMS 26)*
0000 A0 A0.pdf new Empty Valid new
0001 B1 B1.pdf append A0 Valid append
0002 C2 C2.pdf replace A0 Valid replace
B2 Empty delete B1 Mandatory delete

Figure F-3: Valid Replace Scenarios

Table F-4: Valid Delete Scenarios
Scenario Number and Description Seq. # Leaf ID Attributes Comment
File Ref. Operation Mod. File
*When the original document is deleted, any appended documents must be deleted.
9. Delete a New leaf
(EDMS 9)
0000 A0 A0.pdf new Empty Valid new
0001 A1 Empty delete A0 Valid delete
10. Delete a Replace leaf
(EDMS 20)
0000 A0 A0.pdf new Empty Valid new
0001 A1 A1.pdf replace A0 Valid replace
0002 A2 Empty delete A1 Valid delete replace
11. Delete an Append leaf
(EDMS 30)
0000 A0 A0.pdf new Empty Valid new
0001 B1 B1.pdf append A0 Valid append
0002 A2 Empty delete B1 Valid delete
12 Delete a New leaf that has an Append leaf
(ETICS 1, EDMS 25)*
0000 A0 A0.pdf new Empty Valid new
0001 B1 B1.pdf append A0 Valid append
0002 C2 Empty delete A0 Valid delete
D2 Empty delete B1 Mandatory delete

Figure F-4: Valid Delete Scenarios

Table F-5: Invalid Operations on Non-current Leaves

As a general principle, an operation should not be applied to a leaf that is no longer active, that is, that has already been replaced or deleted.
Scenario Number and Description Seq. # Leaf ID Attributes Comment
File Ref. Operation Mod. File
*When the original document is deleted, any appended documents must be deleted.
13. Attempt to Replace a New leaf that has been Deleted
(EDMS 31)
0000 A0 A0.pdf new Empty Valid new
0001 A1 Empty delete A0 Valid delete
0002 A2 A2.pdf replace A0 Cannot undelete leaf
14. Attempt to Delete a New leaf that has been
Replaced
(EDMS 32)
0000 A0 A0.pdf new Empty Valid new
0001 A1 A1.pdf replace A0 Valid replace
0002 A2 Empty delete A0 Must act on current leaf
15. Attempt to Delete a New leaf that has already been Deleted
(EDMS 33)
0000 A0 A0.pdf new Empty Valid new
0001 A1 Empty delete A0 Valid delete
0002 A2 Empty delete A0 Cannot re-delete leaf
16. Attempt to Append to a New leaf that has already been Replaced
(EDMS 34)
0000 A0 A0.pdf new Empty Valid new
0001 A1 A1.pdf replace A0 Valid replace
0002 B2 B2.pdf append A0 Must act on current leaf
17. Attempt to Append to a New leaf that has already been Deleted
(EDMS 35)
0000 A0 A0.pdf new Empty Valid new
0001 A1 Empty delete A0 Valid delete
0002 B2 B2.pdf append A0 Cannot undelete leaf
18. Attempt to Replace a New leaf that has already been Replaced
(EDMS 36)
0000 A0 A0.pdf new Empty Valid new
0001 A1 A1.pdf replace A0 Valid replace
0002 A2 A2.pdf replace A0 Undefined replace

Figure F-5: Invalid Operations on Non-current Leaves

Footnotes

Footnote 1

See definition in Appendix C

Return to footnote 1 referrer

Footnote 2

Sponsors are requested to submit original files in Microsoft® Word 2003 or in Corel WordPerfect® version 10. Sponsors should use the appropriate template for the original word-processing format of their choice or for Extensible Markup Language (XML), as the templates become available.

Return to first footnote 2 referrer

Footnote 3

"Protected" status identifies information the unauthorized disclosure of which could reasonably be expected to cause injury to private interests. "Protected B" indicates a medium degree of potential injury. See Government Security Policy (July 2009), Section 10.6, "Identification of Assets." The policy is available at < http://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=12322>.

Return to first footnote 3 referrer