Prep Ectd Format-Eng PDF

GUIDANCE DOCUMENT
Preparation of Drug Regulatory Activities in the

Electronic Common Technical Document Format
Published by authority of the

Minister of Health
Date Adopted 2015/05/14

Effective Date 2015/05/14
Health Products and Food Branch

Our mission is to help the people of Canada The Health Products and Food Branch's mandate is to take
maintain and improve their health. an integrated approach to the management of the risks and
benefits to health related products and food by:
• minimizing health risk factors to Canadians while
Health Canada maximizing the safety provided by the regulatory
system for health products and food; and
• promoting conditions that enable Canadians to make
healthy choices and providing information so that they
can make informed decisions about their health.
Health Products and Food Branch
© Minister of Public Works and Government Services Canada 2015
Également disponible en français sous le titre : Ligne directrice : Préparation des activités
réglementaires des drogues en format Electronic Common Technical Document
Health Canada Preparation of Drug Regulatory Activities in
Guidance Document Electronic Common Technical Document Format
FOREWORD
Guidance documents are meant to provide assistance to industry and health care professionals on
how to comply with governing statutes and regulations. Guidance documents also provide
assistance to staff on how Health Canada mandates and objectives should be implemented in a
manner that is fair, consistent and effective.
Guidance documents are administrative instruments not having force of law and, as such, allow
for flexibility in approach. Alternate approaches to the principles and practices described in this
document may be acceptable provided they are supported by adequate justification. Alternate
approaches should be discussed in advance with the relevant program area to avoid the possible
finding that applicable statutory or regulatory requirements have not been met.
As a corollary to the above, it is equally important to note that Health Canada reserves the right
to request information or material, or define conditions not specifically described in this
document, in order to allow the Department to adequately assess the safety, efficacy or quality of
a product. Health Canada is committed to ensuring that such requests are justifiable and that
decisions are clearly documented.
This document should be read in conjunction with the accompanying notice and the relevant
sections of other applicable guidance documents.
Date Adopted: 2015/05/14; Effective Date: 2015/05/14 i

Preparation of Drug Regulatory Activities in Health Canada
Electronic Common Technical Document Format Guidance Document
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;
ii Date Adopted: 2015/05/14; Effective Date: 2015/05/14

TABLE OF CONTENTS
1 INTRODUCTION.......................................................................................................................1
1.1 Policy Objectives ............................................................................................................... 1
1.2 Policy Statements ............................................................................................................... 1
1.3 Scope and Application ....................................................................................................... 1
1.4 Background ........................................................................................................................ 4
2 STRUCTURE AND CONTENT OF A REGULATORY ACTIVITY IN ELECTRONIC
COMMON TECHNICAL DOCUMENT FORMAT .................................................................4
2.1 Cover Letter ....................................................................................................................... 7
2.2 Life Cycle Management Table ........................................................................................... 9
2.3 Folder Structure and File Naming Convention ................................................................ 10
2.3.1 Top Level Folder and Dossier Identifier ......................................................... 10
2.3.2 Sequence Number Folder ................................................................................ 10
2.3.3 Module 1 Folder .............................................................................................. 10
2.3.4 Modules 2 to 5 Folders .................................................................................... 11
2.3.5 util and dtd Folders .......................................................................................... 11
2.3.6 Content File Naming Convention .................................................................... 11
2.4 Electronic Common Technical Document Structure and Leaf Title ................................ 11
2.4.1 Module 1: Administrative and Product Information ....................................... 12
2.4.2 Modules 2 to 5 ................................................................................................. 14
2.4.3 Leaf Titles ........................................................................................................ 19
3 TECHNICAL REQUIREMENTS FOR REGULATORY ACTIVITIES IN ELECTRONIC
COMMON TECHNICAL DOCUMENT FORMAT ...............................................................20
3.1 File Formats ..................................................................................................................... 20
3.2 Transmission of Electronic Data in Electronic Common Technical Document Format . 22
3.3 Life Cycle Management ................................................................................................... 23
3.3.1 Life Cycle Management at the Dossier Layer ................................................. 24
3.3.2 Life Cycle Management at the Regulatory Activity Layer ............................. 24
3.3.3 Life Cycle Management at the Document Layer............................................. 25
3.4 Bookmarks in Portable Document Format (PDF) Files ................................................... 30
3.5 Hyperlinks and Cross-References .................................................................................... 30
3.6 Print on Demand .............................................................................................................. 31
4 FILING PROCESS FOR REGULATORY TRANSACTION IN ELECTRONIC COMMON
TECHNICAL DOCUMENT FORMAT ...................................................................................31
4.1 Hold Technical Pre-Submission Consultation ................................................................. 32
4.2 File Electronic Common Technical Document Sample ................................................... 33
4.3 Verify Electronic Common Technical Document Sample............................................... 34
4.4 Correct Errors and File Corrected Sample ....................................................................... 34
4.5 Obtain Dossier Identifier .................................................................................................. 34
Date Adopted: 2015/05/14; Effective Date: 2015/05/14 iii

4.6 File Regulatory Transaction in Electronic Common Technical Document Format ........ 35
4.6.1 Signature .......................................................................................................... 35
4.7 Verify Regulatory Transaction in Electronic Common Technical Document Format .... 35
4.8 Correct Errors and File Corrected Regulatory Transactions in Electronic Common
Technical Document Format ............................................................................................ 36
4.9 Distribute Regulatory Transaction in Electronic Common Technical Document Format36
5 IMPORTANT CONSIDERATIONS WHEN PREPARING REGULATORY ACTIVITIES
IN ELECTRONIC COMMON TECHNICAL DOCUMENT FORMAT ................................37
APPENDICES ...............................................................................................................................39
Appendix A: Reference Documents......................................................................................... 39
Appendix B: Contacts .............................................................................................................. 41
Appendix C: Definitions .......................................................................................................... 42
Appendix D: Print on Demand ................................................................................................. 43
Appendix E: Example of a Life Cycle Management Table ..................................................... 45
Appendix F: Life Cycle Management Scenarios for Operation Attributes.............................. 46
iv Date Adopted: 2015/05/14; Effective Date: 2015/05/14

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

 Extraordinary Use New Drug Submission (EU NDS)
 Abbreviated New Drug Submission (ANDS)2
 Supplement to a New Drug Submission (SNDS)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)2
 Notifiable Change (NC)2
1
See definition in Appendix C
2
Including regulatory activities for administrative changes
Date Adopted: 2015/05/14; Effective Date: 2015/05/14 1

 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)3
 Risk Management Plan (RMP), when provided to MHPD3
 Other Post-market Vigilance data4 (Undefined Data Post-market Vigilance (UDPV))
requested by MHPD3
o 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.
o 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)
o Benefit Risk Assessment
o Response to MHPD Requests for Additional Information5
o Notification of Change in benefit-risk profile (under sections C.01.018(3) and (4) of the
Food and Drug Regulations)
o Meetings regarding post marking issues with MHPD
 Yearly Biologic Product Report (YBPR)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 Information7 (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)
3
Must be filed as a separate regulatory activity even if a single request for multiple Post-market
Vigilance data has been issued by MHPD
4
Also referred to as “Pharmacovigilance Data”
5
Throughout this guidance document, when additional information is generally referred to, solicited
and unsolicited information should be understood (See Appendix C: Definitions)
6
YBPRs should not be filed with Level III change forms, in the same regulatory transaction.
7
Pre-Submission Meeting Information includes the Pre-Submission Meeting Request.
2 Date Adopted: 2015/05/14; Effective Date: 2015/05/14

 Undefined Regulatory Activity (UDRA)8

o Response to Advisement Letter to update the Product Monograph, when an NC (or other
Division 8 regulatory activity) is not filed.
o 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.
8
Do not use this regulatory activity without prior discussion with Health Canada.

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

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 Structure with One Regulatory

Transaction

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:
o Significant change in what is known about the risks and benefits of the health
product
o VOLUNTARY PSUR/PBRER - unsolicited information
o REQUESTED PERIODIC PSUR/PBRER - requested by Health Canada (for
example RMP follow-up or post-authorization commitment)
o 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:
o VOLUNTARY RMP - unsolicited information
o 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:

o Should clearly indicate the name of the requester.
o Should not contain any scientific information. Supporting data should be placed in
the appropriate module.
o 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 >
Calculated as Base?
Ingredient Name Strength Unit Per
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 Regulatory
Date Filed Control Related
Number Activity Sequence Description
(mmm. dd, yyyy) Number Sequence
(most recent last) Type

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:
i) m1-0-correspondence:
o 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.
o The Life Cycle Management Table should be filed as a leaf element under the m1-
0-2-life-cycle-management-table heading.
o 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.
o 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
o 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)
ii) m1-2-administrative-information:
o 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 Attestation9
- Administrative Changes - Certification Form for an administrative submission
- Check list for filing requested Development Safety Update Report (DSUR) in
electronic format.
o 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.
9
This document includes the “Document Compare 1: Summary of differences between proposed
PM and most recent Canadian Reference Product (CRP) PM” and “Document Compare 2:
Summary of Differences between proposed PM and most recently approved PM”

o 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.
o 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
o No scientific information should be included under the m1-2-9-other-
administrative-information heading.
iii) m1-3-product-information:
o 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.
o Risk management plans should be filed as one or multiple leaf(s)s under the m1-
3-8-2-risk-management-plan heading.
o 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.
o 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
iv) m1-5-environmental-assessment-statement:
o 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.
v) m1-6-regional-clinical-information:
o 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.

o 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.
vi) m1-0-7-general-note-to-reviewer:
o 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”.
o 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:
o 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”.
o 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 Part10 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 attributes11 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).
10
Also known as “Sponsor’s Part”
11
Since the data provided (such as sponsors’ specification) applies to the active substance(s) from all
manufacturers the element attribute should be named “All”. This is to consider a situation where a
third manufacturer could be added and the ICH eCTD Specification V 3.2.2 does not allow for the
amendment of the element attribute.

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

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:
o They should be filed under the m5-3-7-case-report-forms-and-individual-patient-

listings heading.
o 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.
o 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:
o m5-3-1-reports-of-biopharmaceutic-studies
o m5-3-2-reports-of-studies-pertinent-to-pharmacokinetics-using-human-biomaterials

o m5-3-3-reports-of-human-pharmacokinetic-studies
o m5-3-4-reports-of-humanpharmacodynamic-studies
o 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:
o m3-3-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):

o The annotated version should be provided in both PDF and Microsoft® Word 2010
formats.
o The non-annotated and the pristine version should only be provided in Microsoft® Word
2010 format.
o The second language version should only be provided in PDF.
 Certified Product Information Document (CPID):

o The annotated version should only be provided in PDF.
o The non-annotated version should only be provided in Microsoft® Word 2010 format.
 Summary Basis of Decision (SBD)

o The clean version should only be provided in PDF.
o 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”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.
12
“Protected” status identifies information the unauthorized disclosure of which could reasonably be
expected to cause injury to private interests. “Protected B” indicates a medium degree of potential
injury. See Government Security Policy (July 2009), Section 10.6, “Identification of Assets.”

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
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:
o For all regulatory activity types (such as NDS, SNDS, including administrative
regulatory activities) when first filed, the related-sequence-number element should be
empty.
o 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
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:
o All content files provided as part of the first regulatory activity to Health Canada that
are given the sequence number 0000, should be “new”.
o 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 MHPD13
- RMP when provided to MHPD
- A copy of the original request and the summary of responses in a Question and
Answer format
o 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.
o 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.
o 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.
13
PSUR and PBRER are provided for a specific period therefore, never replacing the previous
document.

o 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.
o 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.
o 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
o 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.
o The Product Monograph (see Figure 9) should be:

- “New” when a non-annotated or annotated PM14 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
14
Including the annotated PM against most recent Canadian Reference Framework (CRF) PM

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.
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:
i) 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.
ii) When using study tagging files or node extensions, read Section 2.4.2 carefully.
iii) When using operational attributes, read Sections 3.3.3 carefully.
iv) When a regulatory transaction has been filed and accepted by Health Canada it should not
be revised without prior consultation with the agency.
v) Filing of additional information/regulatory transactions:

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

vi) 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).
vii) Element Attributes for Modules 2, 3 and 5:

o 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.
o 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).
viii) Leaf Elements:

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

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
CTD Format: Blood Products
CTD Format: Conventional Biotherapeutic Products
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 Date Regulatory
Control Related
Number Submitted Activity Sequence Description
Number Sequence
(most recent last) (mmm. dd, yyyy) Type
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
Response to Processing Clarification Request dated

0005 Jul. 10, 2004 123456 0004 NDS
Jul. 07, 2004
0006 Nov. 03, 2004 123456 0004 NDS Response to NOD dated Sep. 25, 2004
Response to Clinical Clarification Request dated
0007 Feb. 22, 2005 123456 0004 NDS Feb. 11, 2005
0008 Apr. 11 , 2005 123456 0004 NDS Unsolicited Data, Change in the Name of Sponsor
Response to Labelling Clarification Request dated

0009 Apr. 20, 2005 123456 0004 NDS
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
Response to Quality Clarification Request dated

0014 Sep. 10, 2006 123555 0011 SNDS
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
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
Attributes
Scenario Number
and Description Seq. # Leaf File Operation Mod. Comment
ID Ref. File
1. Append to a New 0000 A0 A0.pdf new Empty Valid new
leaf
(EDMS 10) 0001 B1 B1.pdf A0 Valid append
append
2. Append to a 0000 A0 A0.pdf new Empty Valid new
Replace leaf
(EDMS 21) 0001 A1 A1.pdf replace A0 Valid replace
0002 B2 B2.pdf append A1 Valid append to replace
3. Parallel Appends 0000 A0 A0.pdf new Empty Valid new

to a New leaf
(EDMS 28) 0001 B1 B1.pdf append A0 Valid append
0002 C2 C2.pdf append A0 Valid append

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

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

Figure F-3: Valid Replace Scenarios

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

Figure F-4: Valid Delete Scenarios

Table F-5: Invalid Operations on Non-current Leaves
As a general principle, an operation should not be applied to a leaf that is no longer active, that
is, that has already been replaced or deleted.
Attributes
Scenario Number
# ID Ref. File
13. Attempt to 0000 A0 A0.pdf new Empty Valid new
Replace a New leaf delete
that has been Deleted 0001 A1 Empty A0 Valid delete
(EDMS 31) 0002 A2 A2.pdf replace A0 Cannot undelete leaf
14. Attempt to Delete 0000 A0 A0.pdf new Empty Valid new
a New leaf that has replace
been 0001 A1 A1.pdf A0 Valid replace
Replaced 0002 A2 Empty delete A0 Must act on current leaf
(EDMS 32)
15. Attempt to Delete 0000 A0 A0.pdf new Empty Valid new
a New leaf that has
already been Deleted 0001 A1 Empty delete A0 Valid delete
(EDMS 33) 0002 A2 Empty delete A0 Cannot re-delete leaf
Append to a New leaf
that has already been 0001 A1 A1.pdf replace A0 Valid replace
Replaced 0002 B2 B2.pdf append A0 Must act on current leaf
(EDMS 34)
Append to a New leaf
that has already been 0001 A1 Empty delete A0 Valid delete
Deleted B2 B2.pdf append A0 Cannot undelete leaf
(EDMS 35) 0002

Replace a New leaf
that has already been 0001 A1 A1.pdf replace A0 Valid replace
Replaced A2 A2.pdf replace A0 Undefined replace
(EDMS 36) 0002
*When the original document is deleted, any appended documents must be deleted.

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

Prep Ectd Format-Eng PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Prep Ectd Format-Eng PDF

Загружено:

Авторское право:

Доступные форматы

GUIDANCE DOCUMENT

Preparation of Drug Regulatory Activities in the

Published by authority of the

Date Adopted 2015/05/14

Health Products and Food Branch

© Minister of Public Works and Government Services Canada 2015

Date Adopted: 2015/05/14; Effective Date: 2015/05/14 i

ii Date Adopted: 2015/05/14; Effective Date: 2015/05/14

Date Adopted: 2015/05/14; Effective Date: 2015/05/14 iii

iv Date Adopted: 2015/05/14; Effective Date: 2015/05/14

1.1 Policy Objectives

1.2 Policy Statements

1.3 Scope and Application

 New Drug Submission (NDS)2

Date Adopted: 2015/05/14; Effective Date: 2015/05/14 1

 Post-Notice of Compliance (NOC) Changes: Level III

2 Date Adopted: 2015/05/14; Effective Date: 2015/05/14

 Undefined Regulatory Activity (UDRA)8

 Response to a Clarification Request, Notice of Non-compliance (NON), Notice of Deficiency

Date Adopted: 2015/05/14; Effective Date: 2015/05/14 3

 Clinical Trial Application or Amendment (CTA or CTA-A)

2 STRUCTURE AND CONTENT OF A REGULATORY ACTIVITY IN

4 Date Adopted: 2015/05/14; Effective Date: 2015/05/14

Figure 1: Folder Structure

Date Adopted: 2015/05/14; Effective Date: 2015/05/14 5

Figure 2: Electronic Common Technical Document Structure with One Regulatory

6 Date Adopted: 2015/05/14; Effective Date: 2015/05/14

Figure 3: Electronic Common Technical Document Structure with Multiple Regulatory

2.1 Cover Letter

Date Adopted: 2015/05/14; Effective Date: 2015/05/14 7

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

 DINAs should indicate if there is a labelling reference product.

 Response to a request for clarification:

8 Date Adopted: 2015/05/14; Effective Date: 2015/05/14

Table 1: Information from the HC-SC3011 Form

Regulatory Activity Type < Box 5 >

2.2 Life Cycle Management Table

Table 2: Life Cycle Management Table

Date Adopted: 2015/05/14; Effective Date: 2015/05/14 9

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

2.3.2 Sequence Number Folder

2.3.3 Module 1 Folder

10 Date Adopted: 2015/05/14; Effective Date: 2015/05/14

2.3.4 Modules 2 to 5 Folders

2.3.5 util and dtd Folders

2.3.6 Content File Naming Convention

2.4 Electronic Common Technical Document Structure and Leaf Title

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

Date Adopted: 2015/05/14; Effective Date: 2015/05/14 11

2.4.1 Module 1: Administrative and Product Information

12 Date Adopted: 2015/05/14; Effective Date: 2015/05/14

Date Adopted: 2015/05/14; Effective Date: 2015/05/14 13

Notes to reviewers are not a requirement. However, sponsors occasionally include

If new or updated information is required in response to a clarification request, SDN,

14 Date Adopted: 2015/05/14; Effective Date: 2015/05/14

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

Date Adopted: 2015/05/14; Effective Date: 2015/05/14 15

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

16 Date Adopted: 2015/05/14; Effective Date: 2015/05/14

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

ii) Yearly Biologic Product Reports (YBPR)