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

Contact: eReview

Date Adopted 2015/05/14
Effective Date 2015/05/14

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.

Revision History

Date Description
May 17, 2004 Draft Guidance for Industry: Preparation of Drug Submissions in eCTD Format (co-submission filing format only)
May 16, 2005 Guidance for Industry: Preparation of Drug Submissions in eCTD Format (co-submission filing format only)
January 20, 2006 Draft Guidance for Industry: Preparation of Drug Submissions in eCTD Format (co-submission and hybrid filing formats)
September 17, 2008 Guidance for Industry: Preparation of Drug Submissions in eCTD Format (co-submission and hybrid filing formats);
March 30, 2012 Draft Guidance Document: Preparation of Drug Regulatory Activities in eCTD
May 14, 2015 Guidance Document: Preparation of Drug Regulatory Activities in eCTD;

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 activitiesFootnote 1  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 defines the eCTD electronic-only format requirements and process, as well as provides additional guidance on the structure and content of information to be included in regulatory activities filed to Health Canada. It includes examples of documents and their placement in the structure as defined in the Canadian Module 1 Backbone.

This guidance document is to be used in the preparation and filing of drug regulatory activities to Health Canada in the eCTD electronic-only 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 types are eligible for filing in the eCTD format:

  • New Drug Submission (NDS)Footnote 2 
  • Extraordinary Use New Drug Submission (EU NDS)
  • Abbreviated New Drug Submission (ANDS)Footnote 2
  • Supplement to a New Drug Submission (SNDS)Footnote 2
  • Extraordinary Use Supplement to a New Drug Submission (EU SNDS)
  • Supplement to a New Drug Submission-Confirmatory (SNDS-C)
  • Periodic Safety Update Report - Confirmatory (PSUR-C) or Periodic Benefit Risk Evaluation Report - Confirmatory (PBRER-C)
  • Supplement to an Abbreviated New Drug Submission (SANDS)Footnote 2
  • Notifiable Change (NC)Footnote 2
  • Post-Notice of Compliance (NOC) Changes: Level III
  • Periodic Safety Update Report (PSUR) or Periodic Benefit Risk Evaluation Report (PBRER) when provided to the Marketed Health Products Directorate (MHPD)Footnote 3 
  • Risk Management Plan (RMP), when provided to MHPD)Footnote 3
  • Other Post-market Vigilance dataFootnote 4  (Undefined Data Post-market Vigilance (UDPV)) requested by MHPDFootnote 3
    • Risk communication document [for example (e.g.), Dear Health Care Professional Letter, dissemination lists, Proposed Dissemination Strategy]
      Note:
      • When filing via the Common Electronic Submission Gateway (CESG), there is no need to provide an electronic copy directly to MHPD via email.
      • When not filing via the CESG, the eCTD copy should be sent to the Office of Submissions and Intellectual Property (OSIP) with an electronic convenience copy being provided directly to MHPD via email.  The eCTD copy should be sent the same day as the electronic copy is emailed.
    • Post-market Surveillance (e.g., Issue-related Summary Reports, Council For International Organizations Of Medical Sciences (CIOMS), Line Listings, Registry Reports, Clinical Study Reports, or Patient Exposure Data)
    • Benefit Risk Assessment
    • Response to MHPD Requests for Additional InformationFootnote 5 
    • Notification of Change in benefit-risk profile (under sections C.01.018(3) and (4) of the Food and Drug Regulations)
    • Meetings regarding post marking issues with MHPD
  • Yearly Biologic Product Report (YBPR)Footnote 6 
  • Request for Priority Review Status for NDS or SNDS
  • Development Safety Update Report (DSUR) when provided as standalone regulatory activity to Therapeutic Products Directorate (TPD), Biologics and Genetic Therapies Directorate (BGTD) or Natural and Non-prescription Health Products Directorate (NNHPD).
  • Pre-Submission Meeting InformationFootnote 7  (MPNDS, MPSNDS, MPDIN, or MPNC)
  • Application for Drug Identification Number (DINA)
  • Application for Drug Identification Number - Biologic (DINB)
  • Application for Drug Identification Number - Disinfectant Product (DIND) 
  • Application for Drug Identification Number - Category IV Product (DINF)
  • Post-Authorization Division 1 Change (PDC)
  • Post-Authorization Division 1 Change - Biologics (PDC-B)
  • Undefined Regulatory Activity (UDRA)Footnote 8 
    • Response to Advisement Letter to update the Product Monograph, when an NC (or other Division 8 regulatory activity) is not filed.
    • Notification of Discontinued Sale (DIN Cancellation)

Any transaction related to the above regulatory activity types are accepted in eCTD format. These transactions include, however are not limited to, the following:

  • Response to a Clarification Request, Notice of Non-compliance (NON), Notice of Deficiency (NOD), Screening Deficiency Notice (SDN), Notice of Compliance with Conditions Qualifying Notice (NOC/c-QN), or Update Notice
  • PSUR or PBRER requested during the pre-market review process by TPD, BGTD or NNHPD
  • RMP requested during the pre-market review process by TPD, BGTD or NNHPD
  • DSUR requested during the pre-market review process by TPD, BGTD or NNHPD
  • Comments to the Summary Basis of Decision/ Notice of Decision
  • Second Language Product Monograph (PM)
  • Market Notification Form (Drug Notification Form)
  • Form IV, including updates, filed in accordance with the Patented Medicines (Notice of Compliance) Regulations
  • Form V, including updates, filed in accordance with the Patented Medicines (Notice of Compliance) Regulations
  • Documents related to data protection under section C.08.004.1 of the Food and Drug Regulations
  • Authorization for Sharing Information (Consent Letter)
  • Reconsideration of Decisions and Other Related Information
  • Consistency Lot Testing Activities (Sample Requests) requested during the pre-market review process by BGTD

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 (e.g., SNDS, SANDS, NC, Level III, etc.) 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 strongly 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 information currently not accepted in eCTD format includes, however is not limited to:

  • Clinical Trial Application or Amendment (CTA or CTA-A)
  • Products regulated under the Natural Health Products Regulations
  • Drug Master File (DMF)
  • Site Reference File (SRF)
  • Medical Devices - Licence Application or Amendment (LAp or LAm)
  • Lot Release documentation
  • Adverse Reaction Reports provided to MHPD
  • The response to a request issued under the Access to Information Act
  • The Annual Drug Notification Form (ADNF) completed by the sponsor
  • Private Label
  • Written representations related to the Patented Medicines (Notice of Compliance) Regulations
  • Notice of Allegation under the Patented Medicines (Notice of Compliance) Regulations

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. Sponsors who choose to file a regulatory activity in eCTD format must comply with the specifications included in this guidance document, the Guidance Document: Creation of the Canadian Module 1 Backbone developed by Health Canada, 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 related Health Canada guidance documents and notices 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 Structure and Content of a Regulatory Activity in Electronic Common Technical Document Format

Health Canada's content 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 Document: Preparation of Drug Regulatory Activities in the Common Technical Document (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®.

Figure 1: Folder Structure

Disclaimer for the eCTD guidance: The eCTD standard is an international standard developed by International Conference on Harmonization (ICH).It was developed using Extensible Markup Language (XML) that defines a set of rules for encoding documents in eCTD format. The English language is used to develop this standard and therefore, the folder names must be named in English even if the submission is prepared in French.

Figure 1 illustrates a portion of the folder structure for storing files in a regulatory activity in eCTD format, as seen using Windows Explorer®.
e122456 is the Top Level Folder.
0000 is the Sequence Number Folder.
m1 is the Module 1 Folder.
ca is the Regional Folder.
0000-ca-m101-cover-letter.pdf, 0000-ca-m102-lcm-table.pdf, 0000-ca-m121-3011-form.pdf , 0000-ca-m131-annotated-pm.pdf, 0000-ca-m131-annotated-pm.docx, and 0000-ca-m131-non-annotated-pm.docx are the Content Files.
ca-regional.xml is the Canadian Module 1 Backbone File.
m2, m3, m4, m5 are the Modules 2-5 Folders.
util is the Utilities Folder.
ca-regional-2-2.xsd, xlink, xsd, xml.xsd are the schema files and ich-ectd-3-2.dtd are ICH ectd dtd files.
index-md5.tx is the Checksum File.
index.xml is the eCTD Backbone File.

Figure 1: Folder Structure

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. Figures 2 and 3 illustrate a portion of the eCTD structure, as seen using an XML viewing tool. While Figure 2 illustrates a regulatory activity with one regulatory transaction, Figure 3 illustrates regulatory activities with multiple regulatory transactions

Figure 2: Electronic Common Technical Document with One Regulatory Transaction

Disclaimer for the eCTD guidance: The eCTD standard is an international standard developed by International Conference on Harmonization (ICH). It was developed using Extensible Markup Language (XML) that defines a set of rules for encoding documents in eCTD format. The English language is used to develop this standard and therefore, the folder names must be named in English even if the submission is prepared in French.

Figure 2 illustrates a portion of the eCTD structure, as seen using an XML viewing tool.
e123456 is the Dossier Identifier.
0000 is the Sequence Number.
1 Administrative and Product Information is a Heading Element.
1.0 correspondence is a Subheading Element.
1.0.1 Cover Letter is a Subheading Element.
Cover letter July 05, 2004 is a Leaf Element.
1.0.2 Life Cycle Management Table is a Subheading Element.
LCM Table is a Leaf Element.
1.0.7 General Note to Reviewer is a Subheading Element.
Note to reviewer is a Leaf Element.
1.2 Administrative Information is a Subheading Element.
1.2.1 Application Forms is a Subheading Element.
Drug Submission Application Form (HC/SC 3011) is a Leaf Element.
1.2.2 Fee Forms is a Subheading Element.
Fee form is a Leaf Element.
1.2.3 Certification and Attestation Forms is a Subheading Element.
Submission Certification Form is a Leaf Element.
1.2.4 Intellectual Property Information, 1.2.6 Authorization for Sharing Information, 1.2.7 International Information, 1.2.8 Post-Authorized Information, 1.2.9 Other Administrative Information, 1.3 Product Information, and 1.3.1 Product Monograph are Subheading Elements.
Annotated Product Monograph, Annotated Product Monograph and Non-Annotated Product are Leaf Elements.
1.3.2 Inner and Outer Labels, 1.3.3 Non-Canadian Labelling, 1.3.6 Certified Product Information Document, 1.3.7 Look-alike/Sound-alike Assessment, 1.3.8 Pharmacovigilance Information, 1.4 Health Canada Summaries and 1.6 Regional Clinical Information are Subheading Elements.
2 Common Technical Document Summaries is a Heading Element
2.3 Qualify Overall Summary is a Subheading Element.
Quality overall summary is a Leaf Element.
3 Quality, 4 Nonclinical Study Report, 5 Clinical Study Reports are Heading Elements.

Figure 2: Electronic Common Technical Document Structure with One Regulatory  Transaction

Figure 3: Electronic Common Technical Document Structure with Multiple Regulatory Transactions

Disclaimer for the eCTD guidance: The eCTD standard is an international standard developed by International Conference on Harmonization (ICH). It was developed using Extensible Markup Language (XML) that defines a set of rules for encoding documents in eCTD format. The English language is used to develop this standard and therefore, the folder names must be named in English even if the submission is prepared in French.

Figure 3 illustrates a portion of the eCTD structure of a regulatory activity with multiple regulatory transactions (sequences).
e123456
0000 is the Pre-Submission Meeting Request
0001 is the Pre-submission meeting
1 is the administrative and product information
1.0 is the correspondence
1.0.1 is the cover letter
Cover letter Jan. 14, 2004 (new)
1.0.2 is the life cycle management table
LCM table (new)
1.0.5 is the meeting information
0002 is the meeting minutes
0003 is the priority review request
0004 is the new drug submission (NDS)
1 is the administrative and product information
1.0 is the correspondence
1.0.1 is the cover letter
Cover letter Jul. 04, 2004 (new)
1.0.2 is the life cycle management table
LCM table (replace)
1.0.3 is the Copy of Health Canada Issued Correspondence
Priority Review Acceptance Letter (new)
1.0.7 is the General Note to Reviewer
Note to Reviewer (new)
1.2 is the administrative information
1.3 is the product information
1.4 are the Health Canada summaries
1.6 is the regional clinical information
Module 2 to 5
Are the required subheading elements
0005 is the response to processing clarification
0006 is the response to notice of deficiency (NOD)
1 is the administrative and product information
1.0 is the correspondence
1.0.1 is the cover letter
Cover letter Jul. 04, 2005 (new)
1.0.2 is the Life cycle management table
LCM table (replace)
1.0.3 is the copy of Health Canada issued correspondence
Copy of NOD (new)
1.0.4 is the Health Canada solicited information
Response to NOD (new)
Section 1.2 to 1.6
Modules 2 to 5

Figure 3: Electronic Common Technical Document  Structure with Multiple  Regulatory Transactions

2.1 Cover Letter

Health Canada strongly recommends that all regulatory activities and subsequent regulatory transactions in eCTD format are accompanied by an administrative cover letter. When regulatory transactions are provided via the CESG, the cover letter is required to be in portable document format (PDF) only. When transactions are provided on media (as listed in Section 3.2) the cover letter should be provided in both paper format and PDF.

Further to the content recommended by ICH, Health Canada requires the following for all cover letters:

  • Clearly state what is being provided and the reason for filing
  • Include a reference to correspondence with Health Canada, prior to filing
  • Include reference to a request letter (including an Advisement Letter), if applicable
  • Manufacturer/Applicant's name
  • Brand name
  • Control number
  • Dossier Identifier
  • Regulatory activity type
  • Sequence number
  • Any cross-referenced regulatory activity should be clearly stated (date the regulatory activity was approved).
  • Contact name and email address for the eCTD publisher where the Validation Report (if required) should be sent.

In addition to the above general requirements, the cover letters for:

  • PSUR or PBRER (when provided to MHPD) should also indicate the reason for filing:
    • Significant change in what is known about the risks and benefits of the health product
    • VOLUNTARY PSUR/PBRER - unsolicited information
    • REQUESTED PERIODIC PSUR/PBRER - requested by Health Canada (for example RMP follow-up or post-authorization commitment)
    • REQUESTED AD HOC PSUR/PBRER - provided as a one-time request made by either the pre-market review directorate reviewing the associated regulatory activity or by MHPD (the requester should be specified)
  • RMP (when provided to MHPD) should also indicate the reason for filing:
    • VOLUNTARY RMP - unsolicited information
    • REQUESTED AD HOC RMP - provided as a one-time request made by MHPD (the requester should be specified)
  • DINAs should indicate if there is a labelling reference product.
  • Response to a request for clarification:
    • Should clearly indicate the name of the requester.
    • Should not contain any scientific information. Supporting data should be placed in the appropriate module.
    • Should not include the summary response in a Question and Answer format and the Note to Reviewer. These should be placed in 1.0.4 and 1.0.7 respectively.
  • Regulatory transactions that contain an HC-SC3011 form should include a table, structured as below, placed at the end of the cover letter. The information required to fill the table should be taken from the indicated box numbers of the completed HC-SC3011 form.
Table 1: Information from the HC-SC3011 Form
Regulatory Activity Type < Box 5 >
Brand Name  < Box 8 >
Common Name < Box 9 >
Company Name of DIN Owner < Box 11 >
Legal Address of DIN owner < Boxes 12-16 >
Dosage Form < Box 60 >
Route(s) of Administration < Box 63 >
Drug Product < Box 64 >
Proposed Indication/Use  < Box 67 >
Medicinal (Active) Ingredient(s) < Box 56 >
Ingredient Name Strength Unit Per Calculated as Base?
Yes/No)

2.2 Life Cycle Management Table

Sponsors should include a Life Cycle Management (LCM) Table describing all regulatory transactions and how they relate to each other. The LCM table should be completed using the example provided in Appendix E. When filing a corrected regulatory transaction, due to failure of validation there is no need to update the LCM table.

Table 2: Life Cycle Management Table

Sponsor Name: 

Brand Name:   

Dossier Identifier: 

Sequence Number
(most recent last)
Date Filed
(mmm. dd, yyyy)
Control Number Related Sequence Regulatory Activity Type Sequence Description

2.3  Folder Structure and File Naming Convention

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

2.3.1 Top Level Folder and Dossier Identifier

The top level folder of a dossier in eCTD format contains all other folders and their content. The name of the top level folder is the Dossier Identifier number (e.g., e123456 in Figure 1) obtained from Health Canada (refer to Section 4.5, “Obtain Dossier Identifier”). This number is the unique identifier for the dossier related to a specific drug product. All subsequent regulatory activities and additional information in eCTD format for the same dossier should retain the same identifier. The top level folder should be included every time a regulatory transaction is provided to Health Canada.

2.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 (see Figure 1) includes an m1 subfolder, m2-m5 subfolders (as required), an util subfolder, the eCTD backbone file (index.xml), and the checksum file (index-md5.txt).

The sequence number for the first regulatory transaction for a dossier should be 0000. Each time a sponsor provides 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 modifying a regulatory transaction (sequence) that has failed validation, the sequence number should be kept the same as the one that failed.

2.3.3 Module 1 Folder

The structure and content of the Module 1 folder (m1) is defined in Health Canada's Guidance Document: 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 all Module 1 content files and the Canadian Module 1 Backbone file (ca-regional.xml). The ca folder should not contain any subfolders.

2.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 Document: Preparation of Drug Regulatory Activities in the Common Technical Document (CTD) Format, and other relevant guidance documents listed in Appendix A.

2.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-2-2.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).

2.3.6 Content File Naming Convention

Choice of file naming convention is up to the sponsor. To assist sponsors, this section presents examples of a naming convention for Module 1 content files. Health Canada suggests that file names begin with the sequence number, followed by “ca”, followed by the module and the section number, and then a phrase describing the content of the file. All components of the file name should be separated by hyphens.

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

  • 0000-ca-m101-cover-letter.pdf
  • 0000-ca-m107-general-note-to-reviewer.pdf
  • 0000-ca-m121-3011-form.pdf
  • 0000-ca-m131-annotated-pm.pdf
  • 0001-ca-m131-pristine-pm.doc
  • 0001-ca-m131-note-to-reviewer-pm.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.

2.4 Electronic Common Technical Document Structure and Leaf Title

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

2.4.1 Module 1: Administrative and Product Information

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

  1. m1-0-correspondence:
    • The cover letter should be filed as a leaf element under m1-0-1-cover-letter heading, including the cover letter for the purpose of requesting review reports or Pre-Submission Meeting.
    • The Life Cycle Management Table should be filed as a leaf element under the m1-0-2-life-cycle-management-table heading.
    • The copy of an original request issued by Health Canada, such as a request for clarification, SDN, NON, and NOD, should be filed as a leaf element under the m1-0-3-copy-of-health-canada-issued-correspondence heading.
    • The following documents should be filed as leaf elements under the m1-0-4-health-canada-solicited-information heading, and should not be included in the cover letter (no supporting data is to be provided in m1-0-4):
      • Summary response in a Question and Answer format
      • Response to MHPD request for additional information
    • The following documents should be filed as leafs element under the m1-0-6-request-for-reconsideration-documentation heading:
      • Letter of Intent
      • Request for Reconsideration
      • Other Information (such as presentations, background documents, draft questions)
  2. m1-2-administrative-information:
    • The following documents should be filed as leaf elements under the m1-2-3-certification-and-attestation-forms heading:
      • Sponsor Attestation Checklist for an ANDS
      • Product Monograph (PM) Translation Certification form
      • Label Safety Assessment Update - Sponsor AttestationFootnote 9 
      • Administrative Changes - Certification Form for an administrative submission
      • Check list for filing requested Development Safety Update Report (DSUR) in electronic format.
    • Letters Authorizing sharing of information regarding the regulatory activity, should be filed as a leaf element under the m1-2-6-authorization-for-sharing-information heading.
    • A copy of the information received from other regulatory agencies should be filed as a leaf element under the m1-2-7-international-information heading. This information can be organized using node extensions.
    • The following documents should be filed as leaf elements under the m1-2-8-post-authorization-information heading:
      • Post-Notice of Compliance (NOC) Changes: Level III Form
      • Market Notification Form
    • No scientific information should be included under the m1-2-9-other-administrative-information heading.
  3. m1-3-product-information:
    • Literature references related to the PM should not be in m1-3-1-product-monograph heading. For proper placement, refer to Section 2.4.2 vii.
    • Risk management plans should be filed as one or multiple leaf(s)s under the m1-3-8-2-risk-management-plan heading.
    • Risk communication documents (e.g., Dear Health Care Professional Letter, dissemination lists, proposed dissemination strategy, etc.) should be filed as leaf elements under the m1-3-8-3-risk-communications heading.
    • The following documents, should be filed as leaf elements under the m-1-3-8-4-other-pharmacovigilance-information heading:
      • Development Safety Update Report (DSUR)
      • Line listings
      • Registry reports or clinical study reports
      • Patient exposure data
      • Benefit-risk assessment
      • Notification of change in benefit-risk profile
      • Issue-related summary report
  4. m1-5-environmental-assessment-statement:
    • An Environmental Assessment Statement is required for new substances in products regulated under the Food and Drug Act as per the New Substances Notification Regulations (NSN) of the Canadian Environmental Protection Act (CEPA). As per the New Substances Program Advisory Note 2006-04, New Substance Notification (NSN) packages for substances used in products regulated by the Food and Drugs Act must be provided directly to the New Substances Division at Environment Canada.
  5. m1-6-regional-clinical-information:
    • The “BE data sets” (see Section 3.1, “File Formats”, of this guidance document for more information) should be filed as leaf elements under the m1-6-1-comparative-bioavailability-information heading.
    • The Dear Health Care Professional Letter (DHCPL) for a Notice of Compliance with Condition (NOC/c) should be filed as a leaf element under the m1-6-4-notice-of-compliance-with-conditions heading.
  6. m1-0-7-general-note-to-reviewer:
    • A Post NOC Quality Changes Chart (summary document) should be filed as a leaf element under the m1-0-7-general-note-to-reviewer heading. The title of the leaf should be “Post NOC Quality Changes Chart”.
    • An Expert Statement or Expert Opinion document should be filed as a leaf element under the m1-0-7-general-note-to-reviewer heading. The title of the leaf should be “Expert Statements” or “Expert Opinions”.

Notes to reviewers are not a requirement. However, sponsors occasionally include them; therefore the following guidelines are provided to promote a consistent approach to their naming and placement 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”.

For further information about documents and their placement, refer to Health Canada's Guidance Document: Preparation of Drug Regulatory Activities in the Common Technical Document (CTD) Format.

2.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 to which it relates.

For further information about the modified-file attribute used to associate this new or updated information with the information to which it relates, see the ICH Electronic Common Technical Document Specification (Version 3.2.2), “Operation Attribute,” pp. 6-3.

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

i) Applicant's Part (AP) of the Drug Master File (DMF)

The Applicant's PartFootnote 10 of the DMF should be included in section m3-2-s of the eCTD format for a regulatory activity referencing a DMF. When there is more than one DMF used for the active substance(s), each DMF “Applicant's Part” should be provided in its own m3-2-s section, distinguished by appropriate element attributes.

If the sponsor has their own quality documents which apply to each manufacturer of an active substance(s), in addition to those documents provided by the DMF owner, then this information should be placed in a separate m3-2-s section. This section should be identified by appropriate element attributesFootnote 11 to distinguish it from the content provided by the DMF owner(s).

The figures below are an example of an ANDS that refers to data from two different DMF Owners (Company Y Ltd. and Company X Inc.) as well as the data from the sponsor that apply to all manufacturers. When the sponsor incorporates the “Applicant's Part” of the DMF into a regulatory activity, there is no need to rename the files that were used in the original DMF. These repeating m3-2-s sections have been identified by the naming of the folder structure (figure 4) and the element attributes of the eCTD structure (figure 5).

Figure 4: Folder Structure for a Drug Master File (DMF)

Disclaimer for the eCTD guidance: The eCTD standard is an international standard developed by International Conference on Harmonization (ICH).It was developed using Extensible Markup Language (XML) that defines a set of rules for encoding documents in eCTD format. The English language is used to develop this standard and therefore, the folder names must be named in English even if the submission is prepared in French.

Figure 4: 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” 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).
e123456
0000
m1
m2
m3
32-body-data
32s-drug-sub
humandrug-all-manufacturers
humandrug-compx
humandrug-compy
util

Figure 4: Folder  Structure for a Drug Master File (DMF)

Figure 5: Electronic Common Technical Document (eCTD) Structure for a Drug Master File (DMF)

Disclaimer for the eCTD guidance: The eCTD standard is an international standard developed by International Conference on Harmonization (ICH).It was developed using Extensible Markup Language (XML) that defines a set of rules for encoding documents in eCTD format. The English language is used to develop this standard and therefore, the folder names must be named in English even if the submission is prepared in French.

Figure 5 is an example of an ANDS that refers to two different DMF Owners (Company Y Ltd and Company X Inc.) as well as content from the sponsor. These have been identified in the metadata and the naming of the folders.
m3-quality
m3-2-body-of-data
m3-2-s-drug-substance [manufacturer: Company Y Ltd.] [substance: Drug Z]
m3-2-s-1-general-information
m3-2-s-1-1-nomenclature
AP nomenclature (new)
M3-2-s-1-2-structure
Structure (new)
M3-2-s-7-3-stability-data
Stability data (new)
M3-2-s-drug-substance [manufacturer: Company X Inc.] [substance: Drug Z]
M3-2-s-1-general-information
M3-2-s-1-1-nomenclature
Nomenclature (new)
M3-2-s-1-2-structure
Structure (new)
M3-2-s-7-3-stability-data
Stability data (new)
M3-2-s-drug-substance [manufacturer: All] [substance: Drug Z]
M3-2-s-4-control-of-drug-substance
M3-2-s-4-1-specification
Specification (new)

Figure 5: Electronic Common Technical Document (eCTD) Structure for a Drug Master File (DMF)

ii) 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 (YBPR, Analysis of Adverse Drug Reaction, and Recalls) they 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 provided as a separate document, filed as a leaf element under the m1-3-6-certified-product-information-document heading.

iii) Periodic Safety Update Report (PSUR) or Periodic Benefit Risk Evaluation Report (PBRER)

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

iv) 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 the m5-3-7-case-report-forms-and-individual-patient-listings heading.
  • They should be organized first by study name then by site under the m5-3-7-case-report-forms-and-individual-patient-listings heading, using node extensions.
  • Any further breakdown in the organization of CRFs should be developed during discussion with reviewers at the regulatory pre-submission meeting.

Files organized with Study Tagging Files (STFs) will be accepted. If STFs are used in Module 4 and 5, then the CRFs should be built into the STF according to the ICH eCTD STF Specification v2.6.1 and not filed separately under the m5-3-7-case-report-forms-and-individual-patient-listings heading.

Although both node extensions and STFs are acceptable for CRFs, only one or the other approach should be used consistently throughout the lifecycle of the dossier in eCTD format.

v) Study Reports

Study reports should be filed as leaf elements using a node extension under the following headings as applicable:

  • m5-3-1-reports-of-biopharmaceutic-studies
  • m5-3-2-reports-of-studies-pertinent-to-pharmacokinetics-using-human-biomaterials
  • m5-3-3-reports-of-human-pharmacokinetic-studies
  • m5-3-4-reports-of-humanpharmacodynamic-studies
  • m5-3-5-reports-of-efficicacy-and-safety-studies

The files should be organized using node extensions, regardless of whether the study report is broken into multiple files or not, in order to avoid an inconsistent approach. Node extensions should be created to support additional files to be added with subsequent regulatory transactions (sequences).

Files organized with Study Tagging Files (STFs) instead of node extensions will be accepted.  If STFs are used, they should be built according to the ICH eCTD STF Specification v2.6.1.

Although both node extensions and STFs are acceptable for study reports, only one or the other approach should be used consistently throughout the lifecycle of the dossier in eCTD format.

vi) Reports of Post-Marketing Experience

Documents relating to the Council for International Organizations of Medical Sciences (CIOMS) should be placed as leaf elements under the m5-3-6-reports of postmarketing-experience heading.

vii) Literature References

The literature references (including those related to the PM) should be filed as leaf elements under the following, as appropriate:

  • m3-3-literature-references
  • m4-3-literature-references
  • m5-4-literature-references

For further information about documents and their placement, refer to Health Canada's Guidance Document: Preparation of Drug Regulatory Activities in the Common Technical Document (CTD) Format.

2.4.3 Leaf Titles

Leaf titles should describe the content in a meaningful way and should not be too lengthy to ensure proper display of the Table of Contents.

The leaf title of the cover letter should be:

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

The format for the date is as outlined in Health Canada's Guidance Document: Creation of the Canadian Module 1 Backbone.

The leaf title of the Post NOC Changes: Level III Form should be:

Level III Changes yyyy (year filed)

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 (See Figure 2 for an example).

Incorrect:  1.3.1 Product Monograph
1.3.1 Annotated Product Monograph

Correct:  1.3.1 Product Monograph
Annotated Product Monograph

3. Technical Requirements for Regulatory Activities in Electronic Common Technical Document Format

3.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, PDF/A-1 and PDF/A-2).

PDF versions of documents should be generated from electronic source documents and not from scanned material, except when the source electronic files are not available or when 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.

Health Canada recommends that sponsors also provide versions of specific documents in their original Microsoft® Word 2010 (.docx) format. Note that the required hyperlinks to related information should be included only in the PDF version of files.

The following documents should be provided in PDF and/or Microsoft® Word 2010 format(s):

  • Product Monograph (PM):
    • The annotated version should be provided in both PDF and Microsoft® Word 2010 formats.
    • The non-annotated and the pristine version should only be provided in Microsoft® Word 2010 format.
    • The second language version should only be provided in PDF.
  • Certified Product Information Document (CPID):
    • The annotated version should only be provided in PDF.
    • The non-annotated version should only be provided in Microsoft® Word 2010 format.
  • Summary Basis of Decision (SBD)
    • The clean version should only be provided in PDF.
    • The annotated (redlined) version should only be provided in Microsoft® Word 2010 format.

The following documents should be provided in both PDF and Microsoft® Word 2010 formats.

  • Quality Overall Summary (QOS)
  • Sponsor Attestation Checklist for ANDS
  • Label Safety Assessment Update - Sponsor Attestation
  • Dear Healthcare Professional Letter
  • Public Communication
  • Responses to: clarification request, SDN, NON, and NOD.

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

When providing presentations for meetings with Health Canada (e.g., pre-submission meetings), Microsoft® PowerPoint 2010 (.pptx) is an acceptable file format.

The “BE data sets” must be provided in ASCII format. For more information 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”.

For any other file formats, contact OSIP.

3.2 Transmission of Electronic Data in Electronic Common Technical Document Format

i) Common Electronic Submissions Gateway

It is strongly recommended that, when possible, electronic data in eCTD format be provided via the CESG. For more information see Health Canada's guide on How to use the Common Electronic Submissions Gateway (CESG) to send regulatory transactions to Health Canada and Frequently Asked Questions.

ii) Media

When a regulatory activity or transaction in eCTD format is not accepted via CESG, the following media formats are acceptable:

  • Compact Disc-Recordable (CD-R) conforming to the Joliet specification
  • Digital Versatile Disc-Random Access Memory (DVD-RAM) Universal Disc Format (UDF) standard
  • Single and dual layer Recordable Digital Versatile Discs
  • Single and dual layer Blu-ray discs
  • Universal Serial Bus (USB) 2.0 or 3.0 drive
  • Portable External Hard Drive with USB 2.0 or 3.0 interface

These are the media formats that are currently supported. Contact OSIP for other formats that may be acceptable at the time of filing. For contact information see Appendix B.

Media should not be password protected.

When a USB drive or a Portable External Hard Drive is used, it will not be returned to the sponsor unless a pre-paid envelope is provided to Health Canada.

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
  • Dossier Identifier and sequence number
  • Control number, if known
  • “Protected B”Footnote 12 
  • “This media has been virus-scanned and we certify that it is virus free.”
  • Month and year of filing

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

iii) Email

If the Market Notification Form in eCTD format is not provided via the CESG, then it should be sent to Health Canada via email (SIPD-DINREQUEST@hc-sc.gc.ca). The regulatory transaction in eCTD format should be zipped, named, and sent according to the following requirements:

  • The subject line of the email should include the statement: "Division 1 - DNF <Brand Name>” or “Division 8 - DNF <Brand Name>".
  • The body of the email should only contain the zipped regulatory transaction. No other documents or related information should be included.
  • The zipped file should be named: “DNF-<Dossier Id>-<Sequence Number>” (e.g., DNF-e123456-0025).

3.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.

3.3.1 Life Cycle Management at the Dossier Layer

The Dossier Identifier links all regulatory activities to the original regulatory activity of a dossier. Figure 6 illustrates how various types of regulatory activities are linked by the Dossier Identifier.

Figure 6: Regulatory Activities Linked by Dossier Identifier

Disclaimer for the eCTD guidance: The eCTD standard is an international standard developed by International Conference on Harmonization (ICH). It was developed using Extensible Markup Language (XML) that defines a set of rules for encoding documents in eCTD format. The English language is used to develop this standard and therefore, the folder names must be named in English even if the submission is prepared in French.

Figure 6 illustrates how the Dossier Identifier links all regulatory transactions to the original regulatory activity for a dossier. The figure shows how eCTD identifier e123456 links sequence number 0004, a subsequent regulatory activity (for example a Supplement to a New Drug Submission); sequence number 0013 a subsequent regulatory activity (for example a Notifiable Change) and sequence number 0019 a subsequent regulatory activity (for example the forms summarizing Changes to Marketed Human New Drug Products: Notices of Change (Level III)) to sequence number 0000, the original regulatory activity (New Drug Submission or Abbreviated New Drug Submission for example).

Figure 6: Regulatory  Activities Linked by Dossier Identifier

3.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 below:

  • 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 must only be one sequence number.

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

Figure 7: Additional information Linked to Regulatory Activities by Related Sequence Number

Disclaimer for the eCTD guidance: The eCTD standard is an international standard developed by International Conference on Harmonization (ICH). It was developed using Extensible Markup Language (XML) that defines a set of rules for encoding documents in eCTD format. The English language is used to develop this standard and therefore, the folder names must be named in English even if the submission is prepared in French.

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.

e123454

Sequence number is 0000, related sequence number is ----, control number is 123454, example of information is original regulatory activity, Pre-Submission Meeting Request;

Sequence number is 0001, related sequence number is 0000, control number is 123454, example of information is original regulatory activity, Pre-Submission Meeting Package;

Sequence number is 0002, related sequence number is 0000, control number 123454, example of information is solicited information, meeting minutes;

Sequence number is 0003, related sequence number is ----, control number 123455, example of information is subsequent regulatory activity, priority review request;

Sequence number is 0004, related sequence number is ----, control number 123456, example of information is subsequent regulatory activity, new drug submission;

Sequence number is 0005, related sequence number is 0004, control number 123456, example of information is solicited information, response to request for clarification;

Sequence number is 0006, related sequence number is 0004, control number 123456, example of information is solicited information, response to notice of deficiency;

Sequence number is 0007, related sequence number is 0004, control number 123456, example of information is solicited information, response to request for clarification;

Sequence number is 0008, related sequence number is 0004, control number 123456, example of information is solicited information, Safety update;

Sequence number is 0009, related sequence number is 0004, control number 123456, example of information is solicited information, response to request for clarification;

Sequence number is 0010, related sequence number is 0004, control number 123456, example of information is solicited information, pristine product monograph;

Sequence number is 0011, related sequence number is ----, control number 123555, example of information is subsequent regulatory activity, supplemental to a new drug submission;

Sequence number is 0012, related sequence number is 0011, control number 123555, example of information is solicited information, response to Notice of Non-Compliance;

Sequence number is 0013, related sequence number is ----, control number 123666, information type is subsequent regulatory activity, notifiable change;

Sequence number is 0014, related sequence number is 0011, control number 123555, information type is solicited information, response to request for clarification;

Sequence number is 0015, related sequence number is ----, control number 123579, example of information is subsequent regulatory activity, subsequent regulatory activity;

Sequence number is 0016, related sequence number is 0013, control number 123666, example of information is solicited information, response to request for clarification;

Sequence number is 0017, related sequence number is 0013, control number 123666, example of information is solicited information, response to request for clarification;

Sequence number is 0018, related sequence number is 0013, control number 123666, example of information is solicited information, pristine product monograph;

Sequence number is 0019, related sequence number is ----, control number ------, example of information is subsequent regulatory activity, Level III changes;

Sequence number is 0020, related sequence number is ----, control number 123721-, example of information is subsequent regulatory activity, Yearly Biologic Product Reports;

Figure 7: Additional information Linked to Regulatory Activities by Related Sequence Number

3.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 of the leaf element describes the relationship of content files within the dossier. See Figures 8 and 9 for an illustration.

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

i) General Rules for Use of “Append” and “Replace” 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 filed information are provided as a consolidated document. The operation attribute “append” should be used when the additional information provided is used to build upon previously filed information, without providing it again.

For example, in Section 3.2.P.8.3, Stability Data, if in regulatory transaction 0000, stability data for one year are provided in one document, and then when regulatory transaction (sequence) 0001 is filed 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.

The “append” operation attribute to modify a document twice in the same regulatory transaction should not be used. Instead, proper document management, consolidating or modifying the document itself should be used.

For an illustration of the general rules, see figures in Appendix H.

ii) Rules for Use of Operation Attributes for Specific Documents:

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

The operation attribute for the leaf element(s) of:

  • All content files provided as part of the first regulatory activity to Health Canada that are given the sequence number 0000, should be “new”.
  • The following documents, when provided as part of any transaction, should be “new”:
    • Cover letter
    • Notes to Reviewer
    • Level III Changes Form
    • Submission Certification Form
    • PSUR or PBRER when provided to MHPDFootnote 13 
    • RMP when provided to MHPD
    • A copy of the original request and the summary of responses in a Question and Answer format
  • The Life Cycle Management (LCM) Table should be:
    • New” when provided as part of sequence number 0000.
    • Replace” when provided as part of all subsequent transactions.
  • The completed forms (such as the HC-SC3011 form, fee form, submission certification) should be:
    • New” when provided with all types of regulatory activities (such as NDS, ANDS).
    • Replace” when provided as additional information for a correction of an error in the form in response to Health Canada requests (i.e. OSIP queries, screening clarification, and SDN) or for a change in brand name or contact information.
  • The Pre-Submission Meeting should be:
    • New” for all content files provided as part of the Pre-Submission Meeting Package, with the exception of the LCM table. When a document is revised in relation to a pre-submission meeting, the operation attribute should be “replace”.
    • New” for all content files provided in an NDS/ANDS filed subsequent to a pre-submission meeting, 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.
    • Replace” for an SNDS/SANDS submitted subsequent to a pre-submission meeting, as needed in relation to the previous regulatory transactions (with the exception of any regulatory transactions 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.
  • The Certified Product Information Document (CPID) should be:
    • New” when an annotated or non-annotated CPID is provided for the first time.
    • Replace” when an annotated or non-annotated CPID is provided as part of all subsequent transactions.
  • The Draft (text or mock-up) inner and outer label (see Figure 8) should be:
    • New” when provided for the first time.
    • Replace” when provided as part of all subsequent transactions.
  • The Final inner and outer label (see Figure 8) should be:
    • New” when provided for the first time with the Market Notification Form.
    • Replace” when provided with all subsequent Market Notification Form.

Figure 8: Life Cycle Management Label Scenario

Disclaimer for the eCTD guidance: The eCTD standard is an international standard developed by International Conference on Harmonization (ICH). It was developed using Extensible Markup Language (XML) that defines a set of rules for encoding documents in eCTD format. The English language is used to develop this standard and therefore, the folder names must be named in English even if the submission is prepared in French.

Figure 8 illustrates how the operation attribute is used to describe the relationship between content files in regulatory activities subsequent to the original regulatory activity and in additional information related to those regulatory activities. The figure includes: Documents (Operation Attributes); Regulatory Activity A (New Drug Submission); Sequence 0000; Sequence 0001; Sequence 0002; Regulatory Activity B (Supplement to a New Drug Submission) Sequence 0003; Sequence 0006; Sequence 0007; Regulatory Activity C (Notifiable Change); Sequence 0004; Sequence 0005 and Current View.

Figure 8: Filing Life  Cycle Management Label Scenario
  • The Product Monograph (PM) for an administrative regulatory activity as a result of a licensing agreement should be:
    • New” when a non-annotated or annotated PM is provided as part of the first transaction.
    • Replace” when a non-annotated or annotated PM is provided as part of all subsequent transactions.
  • The Product Monograph (see Figure 9) should be:
    • New” when a non-annotated or annotated PMFootnote 14 is provided as part of the first transaction of a regulatory activity (such as NDS, SNDS).
    • Replace” when a non-annotated or annotated PM is provided in response to clarification request, SDN, NOD, or NON.
    • New” when a pristine PM is provided for the first time. The last non-annotated and annotated PMs provided as part of that regulatory activity should be assigned the operation attribute “delete”.
    • Replace” when a pristine PM is provided to replace a previously approved pristine PM. The last non-annotated and annotated PMs provided as part of that regulatory activity should be assigned the operation attribute “delete”.

Figure 9: Life Cycle Management Product Monograph

Disclaimer for the eCTD guidance: The eCTD standard is an international standard developed by International Conference on Harmonization (ICH). It was developed using Extensible Markup Language (XML) that defines a set of rules for encoding documents in eCTD format. The English language is used to develop this standard and therefore, the folder names must be named in English even if the submission is prepared in French.

Figure 9 illustrates how the operation attribute is used to describe the relationship between content files in regulatory activities subsequent to the original regulatory activity and in additional information related to those regulatory activities. The figure includes: Documents (Operation Attributes); Regulatory Activity A;  Sequence 0000; Sequence 0001; Sequence 0002; Regulatory Activity B (Supplement to a New Drug Submission) Sequence 0003; Sequence 0005; Sequence 0007; Regulatory Activity C (Notifiable Change); Sequence 0004; Sequence 0006; Sequence 0008 and Current View.

Figure 9: Life Cycle Management Product Monograph

3.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 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.

3.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.

3.6 Print on Demand

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

4. Filing Process for Regulatory Transaction in Electronic Common Technical Document Format

The process for preparing and filing regulatory transactions in eCTD format is illustrated in figure 10. The steps discussed in the following subsections correspond to the process diagram.

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

Disclaimer for the eCTD guidance: The eCTD standard is an international standard developed by International Conference on Harmonization (ICH).It was developed using Extensible Markup Language (XML) that defines a set of rules for encoding documents in eCTD format. The English language is used to develop this standard and therefore, the folder names must be named in English even if the submission is prepared in French.

Figure 10 illustrates the process followed when filing regulatory transactions to Health Canada in the eCTD format. In the first step, Sponsors filing a regulatory transaction in eCTD format for the first time or for a major change in the eCTD environment are recommended to hold a technical pre-submission consultation meeting with Health Canada. This is followed by the Sponsor filing an eCTD sample to Health Canada. The sample is reviewed by Health Canada, in the third step, to identify any errors. If errors have been identified, the sample is returned to and corrected by the Sponsor and the corrected sample re-filed to Health Canada for verification (this process will continue until no errors have been identified). The filing of the sample eCTD should occur at least two months in advance of the filing of the formal regulatory transaction. If no errors have been identified, the Sponsor obtains an eCTD Identifier and files the regulatory transaction in eCTD format. Health Canada verifies the regulatory transaction in eCTD format to identify any errors. If errors have been identified, the eCTD regulatory transaction is returned to and corrected by the Sponsor and the corrected regulatory transaction re-filed to Health Canada (this process will continue until no errors have been identified). If no errors have been identified, the regulatory transaction in eCTD format is distributed to initiate or continue the evaluation process.

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

4.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, as well as to provide Health Canada the opportunity to offer assistance and guidance for the filing process in eCTD format. This consultation does not necessarily need to take place at the same time as the regulatory pre-submission meeting. To request a technical pre-submission consultation, contact OSIP.

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
  • The names of sponsor representatives attending the meeting

4.2 File Electronic Common Technical Document Sample

Sponsors filing a regulatory transaction using the eCTD format for the first time with Health Canada are recommended to file a sample, in eCTD format, at least two months in advance of filing their formal regulatory transaction in eCTD format. 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 a sample in eCTD format 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 Dossier 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., s150621).

The sample in eCTD format 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.2 (ca-regional-2-2.xsd, xml.xsd, xlink.xsd)
  • ICH eCTD DTD (ich-ectd-3-2.dtd)
  • Content files with some data

If a sponsor intends to include Study Tagging Files in the regulatory transaction, they should be included in the sample.

If a sponsor does not intend to include Study Tagging Files, then the sample should include node extensions.

It is strongly recommended that the sample in eCTD format be provided via the CESG. If not using CESG, the package should be sent to OSIP and include a paper cover letter and the disc containing the sample.

4.3 Verify Electronic Common Technical Document Sample

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

The verification process has two stages; the first stage includes validation of the sample according to the published validation rules. The second stage is manual and includes, however is not limited to, the verification of the placement of documents as well as the correct use of operation attributes, element attributes, node extensions, and Study Tagging Files to ensure compliance with this guidance. During this verification process, the content of the sample is not reviewed according to the Health Canada evaluation process.

Within a month of receiving the sample in eCTD format, a written eCTD Validation Report, will be issued to the sponsor.

4.4 Correct Errors and File Corrected Sample

When Health Canada has identified major errors in the eCTD sample, the sponsor corrects the errors and files the corrected eCTD sample with OSIP. If the sponsor wishes to discuss the eCTD Validation Report, they should contact OSIP.

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.

4.5 Obtain Dossier Identifier

Prior to filing the first regulatory transaction for a dossier in eCTD format, the sponsor should provide a written request to OSIP via email (ereview@hc-sc.gc.ca) to obtain a Dossier Identifier (see Section 2.3.1, “Top Level Folder and Dossier Identifier”).

The request should include the draft HC-SC3011 form with the boxes 5, 8, 9, 10 to 22 (section A), and 62 completed or if applicable, the control number of the regulatory pre-submission meeting in the situation that it was filed in paper format.

In addition, when a Canadian Reference Product is used the following information should be provided:

  • Brand Name
  • Medicinal (Active) Ingredient(s)
  • Company Name
  • Dosage Form(s)
  • Strength(s)

Note that the requirement to obtain a Dossier Identifier from Health Canada does not apply to samples in eCTD format (see Section 4.2, “File eCTD Sample”).

4.6 File Regulatory Transaction in Electronic Common Technical Document Format

Regulatory transactions in eCTD format should be sent via CESG, when possible. For further information refer to Section 3.2 i).

Transactions provided on approved media formats (see Section 3.2 ii)) should be sent to OSIP regardless of the review Directorate and must be accompanied with a paper cover letter, as this is the only means by which to quickly identify its contents.

4.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, unless instructed otherwise, when using one of the electronic PDF fillable forms available on the Health Canada website.

If only one page of a multi-page document contains a signature, the sponsor should scan that 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.
 

4.7 Verify Regulatory Transaction in Electronic Common Technical Document Format

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

The verification process has two stages:

The first stage includes validation of the regulatory transaction according to the published validation rules. A written eCTD Validation Report describing the deficiencies will be issued to the sponsor for regulatory transactions that fail validation or validate with warnings.

For regulatory transactions received on approved media, a Validation Report will be issued within 7 calendar days. This timeline will decrease to 24 business hours for regulatory transactions received via CESG.

The second stage is manual and includes, however is not limited to, the verification of the placement of documents as well as the correct use of operation attributes, element attributes, node extensions, and Study Tagging Files to ensure compliance with this guidance. During this verification process, the content of the regulatory transaction is not reviewed according to the Health Canada evaluation process. Feedback will be provided according to the timelines for processing as per the Guidance for Industry: Management of Drug Submissions.

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

When Health Canada identifies errors and/or deficiencies in the regulatory transaction in eCTD format, the sponsor corrects the errors highlighted in the eCTD Validation Report and/or deficiencies outlined in the email communication from OSIP. The sponsor may contact OSIP if they wish to discuss the feedback received. The sponsor files the corrected regulatory transaction with OSIP which is then verified. This process is iterative.

If a regulatory transaction fails verification due to errors and/or deficiencies, 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.

4.9 Distribute Regulatory Transaction in Electronic Common Technical Document Format

When the regulatory transaction has passed the verification process, it is distributed to initiate or continue the evaluation process.

5. Important Considerations When Preparing Regulatory Activities in Electronic Common Technical Document Format

Sponsors are reminded to pay particular attention to the items listed below as during the processing of regulatory activities, errors have been encountered with issues related to:

  1. The electronic regulatory activity in eCTD format is the legal document; therefore emails provided directly to reviewers have no legal value and are considered a convenience copy. The information provided via email to reviewers should always be followed by a regulatory transaction in eCTD format.
  2. When using study tagging files or node extensions, read Section 2.4.2 carefully.
  3. When using operational attributes, read Sections 3.3.3 carefully.
  4. When a regulatory transaction has been filed and accepted by Health Canada it should not be revised without prior consultation with the agency.
  5. Filing of additional information/regulatory transactions:
    • Once a sponsor files a regulatory activity in eCTD format, all additional information and subsequent regulatory activities for the same dossier must 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 3.3, “Life Cycle Management”), and facilitate the review process. The recommendation to continue filing in eCTD format does not apply to CTAs provided after the Notice of Compliance (NOC) has been issued.
    • A response to solicited information in eCTD format is required to complete the legal document (with the exception of the pristine Product Monograph); the absence of this information may delay the issuance of the NOC.
    • Responses to solicited information should be provided individually for each request and should not be bundled in one transaction with a response to another separate request.
    • It is strongly recommended that every transaction in eCTD format be provided to OSIP via the CESG. This is particularly important for Response to Requests for Clarification in order to ensure compliance with the due date (only when requested, the summary of the response may be provided directly to the requester in addition to the official copy being provided to OSIP).
    • Regulatory activities provided to MHPD (PSUR, PBRER, RMP, Other Post-market Vigilance data requested) must be filed as separate regulatory activities even if a single request for multiple Post-market Vigilance data has been issued by MHPD.
  6. Pre-Submission Meeting Request should be filed in eCTD format as the initial transaction for pre-submission meetings (see Section 3.3, Figures 6 and 7).
  7. Element Attributes for Modules 2, 3 and 5:
    • There is currently no standard terminology for element attributes. However, sponsors should choose these attributes carefully as they cannot be easily changed during the life cycle of the dossier.
    • A slight modification to an element attribute will create a duplicate heading element (node), therefore:
      • Attributes should be left as they have been written in the first regulatory transaction where they were defined. Keep in mind that attributes are case-sensitive (e.g., [Nausea] [nausea]).
      • Attributes should not be changed when the company has undergone a company name change.
      • Typographical mistakes should not be corrected.
    For further information regarding element attributes refer to Table 6-9, 6-10 and 6-11 of section “eCTD Element/Attribute Instructions” in Appendix 6 of the ICH Electronic Common Technical Document Specification (Version 3.2.2).
  8. Leaf Elements:
    • A leaf element should not be used to indicate that a section (heading or subheading element) is not applicable. The heading elements that have no content should not be included.
    • A leaf element should not be used at the beginning of a section (heading or subheading element) to introduce the document(s) provided in the section. 

Figure 11: Unnecessary Leaf Elements

Disclaimer for the eCTD guidance: The eCTD standard is an international standard developed by International Conference on Harmonization (ICH). It was developed using Extensible Markup Language (XML) that defines a set of rules for encoding documents in eCTD format. The English language is used to develop this standard and therefore, the folder names must be named in English even if the submission is prepared in French.

e123456 is the Dossier Identifier
0000 is the sequence number
1 Administrative and Product Information is the Heading Element
1.3 Product Information and 1.3.1 Product Monograph are the sub-heading elements.
PDF Product Monograph is an unacceptable left element to introduce the documents provided in section 1.3.1.
PDF Annotated Product Monoraph, Word Annotated Product Monograph and Word Non-Annotated Product Monograph are the accepted Leaf Elements.

Figure 11:  Unnecessary Leaf Elements

Appendices

Appendix A: Reference Documents

Health Canada References

The latest versions of the documents below as well as other guidance documents, policies, templates, and forms can be obtained from the Health Canada website by copying and pasting one of the following web addresses into your browser.

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

A specific guidance document or a notice may be found by entering the document title in the search engine of the Health Canada website.

Electronic Common Technical Document (eCTD)

  • Questions and Answers for the Guidance for Industry: Preparation of Drug Submissions in the Electronic Common Technical Document (eCTD) Format
  • Notice: Validation rules for regulatory transactions submitted to Health Canada in the electronic Common Technical Document (eCTD) format
  • Guidance Document: Creation of the Canadian Module 1 Backbone
  • Canadian Module 1 Schema

Common Technical Document (CTD)

  • Guidance Document: Preparation of Drug Regulatory Activities in the Common Technical Document (CTD) Format
  • Draft Guidance for Industry: Preparation of Comparative Bioavailability Information for Drug Submissions in the CTD Format
  • 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
  • Frequently Asked Questions – Common Electronic Submissions Gateway
  • How to Pay Fees to Health Products and Food Branch (HPFB)
  • Guidance Document: Post-Notice of Compliance (NOC) Changes: Framework Document
  • Guidance Document: Post-Notice of Compliance (NOC) Changes: Quality Document
  • Guidance Document: Post-Notice of Compliance (NOC) Changes: Safety and Efficacy Document
  • Notice - Post-Notice of Compliance (NOC) Changes: Notices of Change (Level III)  Form
  • Notice - New requirements for submitting administrative drug submissions to Health Canada
  • Changes in Manufacturer's Name and/or Product Name

International Conference on Harmonisation (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

Office of Submissions and Intellectual Property (OSIP)
Health Canada
Finance Building
101 Tunney's Pasture Driveway
Address Locator: 0201A1
Ottawa, Ontario
K1A 0K9
E-mail: ereview@hc-sc.gc.ca

Appendix C: Definitions

Additional Information: both solicited and unsolicited information.

  • Solicited information such as: responses to SDN, NOD, NON, or Clarification Request (telephone request, email request, screening Acceptance Letter).
  • Unsolicited information such as safety information and changes in the name of the sponsor or product during review.

Note: For more details about solicited and unsolicited information, see Section 5.4, “Screening of Information and Material” and Section 5.5, "Evaluation of Submissions" in Health Canada's Guidance for Industry: Management of Drug Submissions.

Administrative change submission: a regulatory activity pertaining to a change in manufacturer's name and/or product name following a merger, buy-out or other corporate restructuring or as a result of a licensing agreement, that does not require scientific review.

Dossier: a collection of all regulatory activities throughout the life cycle of a product.

Dossier Identifier: a number created by Health Canada to uniquely identify the dossier related to a specific drug product. The dossier identifier must be in the format of a lower case letter followed by six digits (e.g., e123456).

Labelling submission: a regulatory activity that requires a scientific review to support a name change for the drug product.

Market Notification Form (also known as Drug Notification Form): as per section C.01.014.3 of the Food and Drug Regulations, companies are required to notify Health Canada of a drug being sold.

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.

Regulatory Transaction (Sequence): any information package sent by the sponsor as part of a regulatory activity such as initial data, unsolicited and solicited information (see definition for additional information).

Appendix D: Print on Demand

It is assumed that regulatory activities in eCTD format will be screened and reviewed electronically. However, Health Canada may, in a rare instance, request portions of a regulatory activity in eCTD format on a paper copy.

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. No information related to this transaction should be provided in eCTD format. The paper copy should be accompanied by:

  • A copy of the original request issued by Health Canada.
  • A paper Letter of Attestation for Print on Demand (this letter does not need to be provided as a transaction in eCTD format).
  • A cover letter that includes the following information: the control number, dossier identifier, sequence number(s) of the material being printed, as well as the name of the requester. The sponsor should send the copy to OSIP at the address provided in Appendix B.

Sample Letter of Attestation for Print on Demand

We certify that, to the best of our knowledge and belief, with reference to the regulatory activity pertaining to .....

Provided by .....

All information and material included in response to a Print on Demand request exactly matches the information and material in eCTD format. No information has been added, removed, or changed.

Signed .....

Appendix E: Example of a Life Cycle Management Table

Sponsor Name: Pharmacompany

Brand Name: Drug X

Dossier Identifier: e123454

Sequence Number
(most recent last)
Date Submitted
(mmm. dd, yyyy)
Control Number Related Sequence Regulatory Activity Type Sequence Description
0000 Dec. 17, 2003 123454 ---- MPNDS Pre-Submission Meeting Request
0001 Jan. 15, 2004 123454 0000 MPNDS Pre-Submission Meeting Package
0002 Feb. 29, 2004 123454 0000 MPNDS Minutes of Meeting, Feb. 15, 2004
0003 May 10, 2004 123455 ---- PRNDS Priority Review Request
0004 Jul. 05, 2004 123456 ---- NDS INITIAL
0005 Jul. 10, 2004 123456 0004 NDS Response to Processing Clarification Request dated Jul. 07, 2004
0006 Nov. 03, 2004 123456 0004 NDS Response to NOD dated Sep. 25, 2004
0007 Feb. 22, 2005 123456 0004 NDS Response to Clinical Clarification Request dated  Feb. 11, 2005
0008 Apr. 11 , 2005 123456 0004 NDS Unsolicited Data, Change in the Name of Sponsor
0009 Apr. 20, 2005 123456 0004 NDS Response to Labelling Clarification Request dated Apr. 15, 2005
0010 May. 25, 2005 123456 0004 NDS Pristine PM
0011 Jan. 09, 2006 123555 ---- SNDS Post NOC Change
0012 Jul. 5, 2006 123555 0011 SNDS Response to NON dated Jun. 8, 2006
0013 Jul 27, 2006 123666 ---- NC Post NOC Change
0014 Sep. 10, 2006 123555 0011 SNDS Response to Quality Clarification Request dated  Sep. 01, 2006
0015 Oct. 15, 2006 123679 ---- PSUR-PV For Period of Sep. 15, 2005 to Sep. 14, 2006
0016 Oct. 17, 2006 123666 0013 NC Response to Labelling Clarification Request dated Oct. 12, 2006
0017 Oct. 20, 2006 123666 0013 NC Response to Telephone Request dated Oct. 18, 2006
0018 Oct. 26, 2006 123666 0013 NC Pristine PM
0019 Dec. 12, 2006 ---- ---- Level III 2006, 15, 19a.
0020 Mar. 5, 2007 123721 ---- YBPR For Period of Jan. 25, 2006 to Jan. 24, 2007

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

Disclaimer for the eCTD guidance: The eCTD standard is an international standard developed by International Conference on Harmonization (ICH). It was developed using Extensible Markup Language (XML) that defines a set of rules for encoding documents in eCTD format. The English language is used to develop this standard and therefore, the folder names must be named in English even if the submission is prepared in French.

The scenarios provided in this figure describe rules applicable to the general use of the operation attribute for valid append scenarios.

Figure F-1: Valid Append Scenarios

It is not a valid operation to append to a leaf that has already been appended to a leaf.

Table F-2: Invalid Append Scenario
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

Disclaimer for the eCTD guidance: The eCTD standard is an international standard developed by International Conference on Harmonization (ICH). It was developed using Extensible Markup Language (XML) that defines a set of rules for encoding documents in eCTD format. The English language is used to develop this standard and therefore, the folder names must be named in English even if the submission is prepared in French.

The scenarios provided in this figure describe rules applicable to the general use of the operation attribute for valid append scenarios. It is not a valid operation to append to a leaf that has already been appended to a new leaf.

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)When replacing the original document, any appended document must be deleted. Therefore the content of A0.pdf and B1.pdf should be consolidated.
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

Disclaimer for the eCTD guidance: The eCTD standard is an international standard developed by International Conference on Harmonization (ICH). It was developed using Extensible Markup Language (XML) that defines a set of rules for encoding documents in eCTD format. The English language is used to develop this standard and therefore, the folder names must be named in English even if the submission is prepared in French.

The scenarios provided in this figure describe rules applicable to the general use of the operation attribute for valid replace scenarios.

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)When the original document is deleted, any appended documents must be deleted.
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

Disclaimer for the eCTD guidance: The eCTD standard is an international standard developed by International Conference on Harmonization (ICH). It was developed using Extensible Markup Language (XML) that defines a set of rules for encoding documents in eCTD format. The English language is used to develop this standard and therefore, the folder names must be named in English even if the submission is prepared in French.

The scenarios provided in this figure describe rules applicable to the general use of the operation attribute for valid delete scenarios.

Figure F-4: Valid Delete Scenarios

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.

Table F-5: Invalid Operations on Non-current Leaves
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

Disclaimer for the eCTD guidance: The eCTD standard is an international standard developed by International Conference on Harmonization (ICH). It was developed using Extensible Markup Language (XML) that defines a set of rules for encoding documents in eCTD format. The English language is used to develop this standard and therefore, the folder names must be named in English even if the submission is prepared in French.

The scenarios provided in this figure describe rules applicable to the general use of the operation attribute for Invalid Operations on Non-current Leaves.

Figure F-5: Invalid Operations on Non-current Leaves
Report a problem or mistake on this page
Please select all that apply:

Thank you for your help!

You will not receive a reply. For enquiries, contact us.

Date modified: