Draft guidance document profile: Canadian Module 1 Technical Implementation Guide for the Electronic Common Technical Document (eCTD) v4.0 Format (2024)

(PDF Version - 421 KB)

This guidance document is being distributed for comment purposes only.

Draft Date: 2019/06/26

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 therapeutic product. Health Canada is committed to ensuring that such requests are justifiable and that decisions are clearly documented.

Table of Contents

• Notice to readers
• Instructions to reader
• Health Canada regulatory terminology mapping
  • Table 1 - Health Canada Regulatory Terminology Mapping
• Document content
• XML Snippets
• Location in XML
  • Table 2 - Location in XML Notation
• XML Elements Tables
  • Table 3 - Sample XML Element Table
• 1. Purpose
• 2. Scope
• 3. Components of the Health Canada eCTD v4.0 specification
  • 3.1 Referenced resources
  • 3.2 The eCTD v4.0 XML schema and message
• 4. Submission contents, folder and file structure
  • 4.1 Submission unit contents
    • 4.1.1 Submission unit contents of messages from sponsor
    • 4.1.2 Submission unit contents of messages from Health Canada
    • 4.1.3 Comprehensive folder structure
  • 4.2 File formats and naming conventions
  • 4.3 Folder hierarchy
• 5. Controlled vocabularies
  • 5.1 Controlled vocabularies specified regionally
    • Table 4 - Health Canada regional controlled vocabularies
  • 5.2 Excluded regional vocabularies
• 6. eCTD v4.0 XML message for Health Canada
  • 6.1 Message header for Health Canada
  • 6.2 Payload message for Health Canada
    • Table 5 - Health Canada eCTD v4.0 XML Message Payload
    • 6.2.1 Submission Unit
    • 6.2.2 Submission
      • 6.2.2.1 XML elements
        • 6.2.2.1.1 Table 6 - Submission.id
        • 6.2.2.1.2 Table 7 - Submission.code
    • 6.2.3 Application
      • 6.2.3.1. XML elements
        • 6.2.3.1.1 Table 8 - application.id
        • 6.2.3.1.2 Table 9 - application.code
      • 6.2.3.2 XML samples
  • 6.3 Creating the message
    • 6.3.1 File Reuse
    • 6.3.2 Use of media type
  • 6.4 Grouped submissions
  • 6.5 Withdrawing submission contents
  • 6.6 Health Canada Messages - Two-way communication
    • 6.6.1 Content of messages
    • 6.6.2 Contact party
      • 6.6.2.1 Location in XML
      • 6.6.2.2 XML elements
        • 6.6.2.2.1 Contact party
          • 6.6.2.2.1.1 Table 10 - callBackContact.contactParty.id
          • 6.6.2.2.1.2 Table 11 - callBackContact.contactParty.code
          • 6.6.2.2.1.3 Table 12 - callBackContact.contactParty.statusCode
        • 6.6.2.2.2 Contact person
          • 6.6.2.2.2.1 Table 13- callBackContact.contactParty.contactPerson.name
          • 6.6.2.2.2.2 Table 14 - callBackContact.contactParty.contactPerson.telecom
          • 6.6.2.2.2.3 Table 15 - callBackContact.contactParty.asAgent.representedOrganization.name
      • 6.6.2.3 Excluded elements
    • 6.6.3 Sequence number
• 7. Transition Mapping Message from eCTD v3.2.2
  • 7.1 Message Header
    • Table 16 - The following XML shows the required elements/attributes to validate the message against the schema
  • 7.2 Payload message
    • 7.2.1 Payload elements
      • 7.2.1.1 Keywords in TMM
      • 7.2.1.2 Post transition

Notice to readers

Sections of this document referencing the HL7 (Version 3) Standard, Regulatory Product Submission Release 2 Normative are used with the publisher's permission. The HL7 Standard (Version 3) Regulatory Product Submission Release 2 Normative is copyrighted by Health Level Seven International^®ALL RIGHTS RESERVED.

Instructions to reader

This is a technical document that provides instructions on how to implement the ICH Electronic Common Technical Document v4.0 (eCTD v4.0) specification for Health Canada Module 1 submission content. The information in this document is provided in a consistent manner with the ICH eCTD v4.0 Implementation Guide. In addition, the reader may be prompted by visual cues about the context or referenced information being presented in the document.
This document should be used in conjunction with the latest eCTD v4.0 Implementation Guide. Aspects of the Health Canada message that do not differ from the ICH Implementation Guide are excluded from this document to avoid duplication.

Health Canada regulatory terminology mapping

Several terms used in the context of creation of eCTD v4.0 messages in this document differ from the regulatory vocabulary regularly used at Health Canada. In order to avoid confusion and create a common understanding for regulatory communication, a terminology mapping is provided here.

Document content

In the document there are several notations that are used to provide clarity to the subject matter. The first is the use of eXtensible Markup Language (XML) components (i.e., elements and attributes) versus the concept that it represents. The document text follows the notations described below:

• XML components
  • The document's narrative text is in bold, italicized text in camel case, e.g., contextOfUse
  • The XML samples are as notated below in the XML Snippets section.
• Concepts without attribution to the standard and/or message
  • A defined concept, e.g., Context of Use is noted in plain text with first letter capitalized.

XML Snippets

The following rules were used in the development of the XML samples:

• The notation of <!--....notes….-- > was used to describe conditions that should be met for an element.
• The notation … [Description] … was used to indicate when there were additional elements not represented in the XML, but may be present in the actual XML message.

Location in XML

Each of the elements in this document includes a section named, "Location in XML". The notation included uses the following convention:

For example, the following location shows both notations and is followed by the XML sample.

• controlActProcess>>subject>>submissionUnit>>component>>priorityNumber> contextOfUse

Element's location in XML

• <controlActProcess classCode="ACTN" moodCode="EVN">
  • <subject typeCode="SUBJ">
    • <submissionUnit>
      • <component>
        • <priorityNumber value="1000"/>
        • <contextOfUse>

The priority number is represented in the path as it is a required element. In some cases, optional elements will not appear in this notation. The schema is used to enforce any element sequencing requirements, but not the inclusion or exclusion of optional elements based on regional business rules.
Note: For Health Canada elements in the message payload, refer to Table 5 Health Canada eCTD v4.0 XML Message Payload.

XML Elements Tables

A table has been provided for each element in the XML message. When elements have multiple element parts or attributes, they are provided in one table. When there are no attributes or values for an element, the cell is grayed out to indicate that an attribute value is not required in the XML message.

Table Name: Each table is named for the elements it is representing in the XML - i.e., <element>.<element 2>. For example, the Application element has an element for the identifier, it would be represented as: application.id.

Element: Identifies the XML element.

Attribute: Identifies the XML attribute.

Value(s) Allowed/Examples: Identifies the values allowed using simple data types and any associated examples. References to controlled vocabulary are also provided.

Description/Instructions: Provides a description of the element or attribute.

Conformance: Identifies the validation requirements (e.g., XML Elements or attributes) and/or conditions that need to be met by the element.

Excluded Elements and/or Attributes: Identifies datatype elements and/or attributes that are part of the HL7 Regulated Product Submission standard and not included in the Module 1 portion of the eCTD v4.0 Implementation.

1. Purpose

This document serves as the Technical Implementation Guide (IG) and a technical specification for the Health Canada eCTD v4.0 message using the Health Level 7 (HL7) Regulated Product Submission (RPS) Release 2, Normative standard. Health Canada is the regional authority for Canada and thus sets the Canadian standard. The audience for this document is mainly the individuals or organizations creating or implementing eCTD v4.0 publishing and/or review systems and its use should enable eCTD tool vendors to build a tool that publishes or displays eCTD v4.0 messages (i.e., utilizing the HL7 RPS standard) for Health Canada.

This implementation guide must be used in conjunction with the ICH eCTD v4.0 Implementation Guide, as the eCTD v4.0 message may be incomplete without following instructions in both implementation guides.

2. Scope

The RPS standard defines the message for exchanging information electronically between Regulators and Industry. The message provides the ability to describe the contents of the regulatory exchange and all information needed to process the exchange between parties. The RPS message is designed to be flexible enough to be used to support regulatory exchanges for any regulated product.

Each regulated product type will have a unique implementation guide describing how the RPS standard should be used in that context. For example, eCTD v4.0 is the instance of RPS meant for human drugs and biologics.

This document only includes eCTD v4.0 Module 1 instructions for the Health Canada regional content of eCTD v4.0. The instructions for eCTD v4.0 Modules 2 - 5, which are shared across all ICH regions, are not included in this implementation guide. In addition, sections in this document may also be included in the ICH eCTD v4.0 Implementation Guide and may include a reference back to that document.

In addition, relevant rules and examples are provided to enable transition from eCTD v3.2.2 to v4.0 within an application / dossier.

3. Components of the Health Canada eCTD v4.0 specification

This section provides a brief overview of the essential components of the Health Canada eCTD v4.0 specification. The essential components include:

• Referenced Documents (detailed information provided in Section 3.1)
• The XML Schema and Message (detailed information provided in Section 3.2)
• Submission Contents, Folder and File Structure (detailed information provided in Section 4)
• Controlled Vocabularies (detailed information provided in Section 3.1)
• eCTD V4.0 XML Message for Health Canada including Health Canada-specific Elements (detailed information provided in Section 6)
• Compatibility and Reference to v3.2.2 (detailed information provided in Section 7)
• Validation Rules (Referenced Document information provided in Section 3.1)

Each of these components is detailed in the subsequent sections and include specific information about the component's role in the implementation of the specification.

Note: Reference the ICH Website for a complete list of documents in the ICH eCTD v4.0 Implementation Package and the Health Canada Website for a complete list of documents for the Health Canada Module 1 components of the eCTD v4.0 message.

3.1 Referenced resources

The following documents should be referenced for complete regulatory and technical content:

• ICH eCTD v4.0 Implementation Package
• ICH Specification for Submission Format for eCTD
• Preparation of Regulatory Activities in eCTD Format for Health Canada
• Controlled Vocabulary Registry
• Validation rules for regulatory transactions submitted to Health Canada in the electronic Common Technical Document (eCTD v4.0) format

Note to Implementers: The Health Canada Module 1 Controlled Vocabularies are provided in the Controlled Vocabulary Registry. They are intended for implementers to use as a computable version of the content.

3.2 The eCTD v4.0 XML schema and message

The eCTD v4.0 message is based on the HL7 RPS schema and the ICH eCTD v4.0 specification. Health Canada specific use is included in this Implementation Guide in section 6.2. There may only be a single submissionunit.xml message contained in eCTD v4.0 message exchange.

4. Submission contents, folder and file structure

The folder and file structure specified for the document contents being transmitted along with the XML message should follow various specifications and rules as presented in this section.

4.1 Submission unit contents

When submitting the contents of a Submission Unit, the following structure should be used:

The top-level folder contains all other folders and their content. The top-level folder name is a portion of the dossier identifier (e.g., e123456 illustrated in figure 1) obtained from Health Canada. This number is the unique identifier for the dossier. All subsequent regulatory activities and additional information in eCTD format for the same dossier must retain the same identifier.

The sequence number folder must be named with the "sequence number" of the submission unit (i.e., the actual value of the sequence number (e.g., 1)). Note that for correspondence from Health Canada, the sequence number folder is contained within a folder named "_hc" (Refer to Section 4.1.2).

4.1.1 Submission unit contents of messages from sponsor

The sponsor will be sending submission contents as one submissionunit.xml message within each message transmission. Figure 1: Sponsor submission unit depicts the folder structure for a submission unit sent to Health Canada.

Figure 1 - Text Equivalent

Figure 1 displays an example of a sponsor submission unit. For example, the Top-level folder could be e123456 and the subfolder would be the sequence number folder, named "1". The sub-sub folders in the sequence number folder would be m1, m2, m3, m4, and m5 with documents "sha256.txt" and "submissionunit.xml".

4.1.2 Submission unit contents of messages from Health Canada

Health Canada correspondence is sent as one submission unit in each message transmission. Figure 2: Health Canada submission unit depicts the folder structure for a submission unit sent by Health Canada.

Figure 2 - Text Equivalent

Figure 2 displays an example of a Health Canada generated submission unit. The top-level folder should be the dossier ID, e123456. The folders under the top-level folder should be "_hc", with additional sub-folders below for each sequence number then organised in individual sub-sub-folders for each module.

4.1.3 Comprehensive folder structure

The complete directory for the application / dossier may combine both the submission contents from the sponsor and Health Canada in one location. Figure 3: Comprehensive folder structure depicts the combination of submission unit contents from both the sponsor and Health Canada.

Figure 3 - Text Equivalent

Figure 3 displays an example of a comprehensive folder structure combining both the sponsor generated submission unit and the Health Canada generated submission unit. The top-level folder again would be the dossier ID, e123456. The folders under the top-level folder should start with the Health Canada subfolders as in figure 2, followed by the subfolders in figure 1.

4.2 File formats and naming conventions

Refer to Health Canada regional specification Preparation of Regulatory Activities in eCTD Format.

4.3 Folder hierarchy

Module 1 has one folder, m1. Only use subfolders when complying with Health Canada technical specifications or guidance for submission content.Refer to the ICH eCTD v4.0 Implementation Guide for the folder hierarchy for modules 2 - 5.

5. Controlled vocabularies

As described, there is extensive use of controlled vocabularies in an eCTD v4.0 message. The information in the following sub-sections outline the controlled vocabulary used in the Health Canada eCTD v4.0 message.

5.1 Controlled vocabularies specified regionally

The following vocabularies used in the eCTD v4.0 implementation are managed and maintained by Health Canada:

5.2 Excluded regional vocabularies

Health Canada controlled vocabularies are only provided for code elements that are allowed. There are elements and their code attributes which are excluded from the Health Canada eCTD v4.0 implementation. Refer to Section 6.2 for both ICH and Health Canada-excluded elements.

6. eCTD v4.0 XML message for Health Canada

6.1 Message header for Health Canada

The message header information provides a set of elements that are needed to specify the sender and receiver as well as the version of the ICH and Health Canada Implementation Guides used to generate the message.

The following XML sample shows the content of the message header id element. The receiver.device.id element contains the IG versioning information required for the eCTD v4.0 Message XML header:

• <id/>
• <creationTime/>
• <interactionId/>
• <processingCode/>
• <processingModeCode/>
• <acceptAckCode/>
• <receiver typeCode="RCV">
  • <device classCode="DEV" determinerCode="INSTANCE">
    • <id>
      • <item root="2.16.840.1.113883.3.989.2.2.1.11.1" identifierName="ICH eCTD v4.0 IG v1.2"/>
    • </id>
  • </device>
• </receiver>
• <sender typeCode="SND">
  • <device classCode="DEV" determinerCode="INSTANCE">
    • <id/>
  • </device>
• </sender>

6.2 Payload message for Health Canada

The following table provides a breakdown of the eCTD v4.0 XML structure noting the placement of each element in the XML Schema. The table is organized with the following three elements in the structure: submissionUnit, submission, and application. Where they have been extended or excluded by Health Canada they are annotated with balloon text boxes that provide references. Elements and attributes in the payload without annotations are implemented exactly as described in the ICH eCTD v4.0 Implementation Guide.

Table 5 - Health Canada eCTD v4.0 XML Message Payload

XML Structure

The eCTD v4.0 message begins at the controlActProcess of the XML payload message related to Module 1 content.

• <controlActProcess classCode="ACTN" moodCode="EVN">
  • <subject typeCode="SUBJ">

The submissionUnit element contains the following elements and attributes:

• component.contextOfUse
  • primaryInformationRecipient.TerritorialAuthority
  • replacementOf.relatedContextOfUse
  • derivedFrom.documentReference
  • subjectOf.submissionReference
  • referencedBy.keyword

Note: All of these elements are not included in this implementation guide. Refer to the ICH eCTD v4.0 Implementation Guide for additional information.

• <submissionUnit>
  • <id/>
  • <code/>
  • <title/>
  • <statusCode/>
  • <component>
    • <priorityNumber value=""/>
    • <contextOfUse>
      • <id/>
      • <code/>
      • <statusCode/>
      • <primaryInformationRecipient>
        • <territorialAuthority>
          • <governingAuthority>
            • <id/>
            • <name/>
          • </governingAuthority>
        • </territorialAuthority>
      • </primaryInformationRecipient>
      • <replacementOf typeCode="RPLC">
        • <relatedContextOfUse>
          • <id/>
        • </documentReference>
      • </derivedFrom>
      • <subjectOf negationInd="">
        • <submissionReference>
          • <id> <item/> </id>
        • </submissionReference>
      • </subjectOf>
      • <referencedBy typeCode="REFR">
        • <keyword>
          • <code/>
        • </keyword>
      • </referencedBy>
    • </contextOfUse>
  • </component>

This section of the XML relates to specifying the submission element. The following elements may follow the componentOf1.submisision element:

• sequenceNumber (included as an element of the relationship between submissionUnit and submission)
• callBackContact.contactParty
• subject1.regulatoryStatus
• subject2.review
  • subject1.manufacturedProduct
  • holder.applicant
  • author.territorialAuthority
  • subject2.productCategory
  • subject3.regulatoryStatus
• subject3.mode
• subject4.regulatoryReviewTime
• subject5.submissionGroup
  • <componentOf1>
    • <sequenceNumber/>
    • <submission>
      • <id/>
      • <code/>
      • <callBackContact>
        • <contactParty>
          • <id/>
            • <code/>
            • <statusCode/>
            • <contactPerson>
              • <name/>
              • <asAgent>
                • <representedOrganization>
                  • <id/>
                  • <name/>
                • </representedOrganization>
              • </asAgent>
            • </contactPerson>
          • </contactParty>
        • </callBackContact>
        • <subject1>
          • <regulatoryStatus>
            • <code/>
          • </regulatoryStatus>
        • </subject1>
        • <subject2>
          • <review>
            • <id/>
            • <statusCode/>
            • <effectiveTime/>
            • <subject1>
              • <manufacturedProduct>
                • <manufacturedProduct>
                  • <name/>
                • </manufacturedProduct>
              • </manufacturedProduct>
            • </subject1>
            • <holder>
              • <applicant/>
            • </holder>
            • <author>
              • <territorialAuthority/>
            • </author>
            • <subject2>
              • <productCategory>
                • <code/>
              • </productCategory>
            • </subject2>
            • <subject3>
              • <regulatoryStatus>
                • <code/>
              • </regulatoryStatus>
            • </subject3>
          • </review>
        • </subject2>
        • </subject3>
          • <mode>
            • <code/>
          • </mode>
        • </subject3>
        • <subject4>
          • <regulatoryReviewTime>
            • <code/>
          • </regulatoryReviewTime>
        • </subject4>
        • <subject5>
          • <submissionGroup>
            • <id/>
          • </submissionGroup>
        • </subject5>

This section of the XML relates to the application element. The application section contains the following elements and their attributes:

• holder
• informationRecipient.territorialAuthority
• subject.reviewProcedure
• reference.applicationReference
• component.document
  • referencedBy.keyword
• referencedBy.keywordDefinition
  • • <componentOf>
      • <application>
        • <id>
          • <item/>
        • </id>
        • <code/>
        • <holder>
          • <applicant>
            • <sponsorOrganization>
              • <id> </id>
              • <name> </name>
            • </sponsorOrganization>
          • </applicant>
        • </holder>
      • <informationRecipient>
        • <territorialAuthority>
          • <governingAuthority>
            • <id/>
            • <name/>
          • </governingAuthority>
        • </territorialAuthority>
      • </informationRecipient>
      • <subject>
        • <reviewProcedure>
          • <code/>
        • </reviewProcedure>
      • </subject>
      • <reference>
        • <applicationReference>
          • <id/>
        • </applicationReference>
      • </reference>
      • <component>
        • <document>
          • <id/>
          • <title/>
          • <text integrityCheckAlgorithm="" mediaType="" language="">
            • <reference/>
            • <integrityCheck/>
          • </text>
          • <referencedBy typeCode="REFR">
            • <keyword>
              • <code/>
            • </keyword>
          • </referencedBy>
        • </document>
      • </component>
        • <referencedBy>
          • <keywordDefinition>
            • <code/>
            • <statusCode/>
            • <value>
              • <item code="" codeSystem="">
                • <displayName/>
              • </item>
            • </value>
          • </keywordDefinition>
        • </referencedBy>
      • </application>
    • </componentOf>
  • </submission>
• </componentOf1>

These are the closing element tags for the key elements in the eCTD v4.0 message.

• • • • <componentOf2>
        • <categoryEvent>
          • <code/>
          • <component>
            • <categoryEvent>
              • <code/>
            • </categoryEvent>
          • </component>
        • </categoryEvent>
      • </componentOf2>
    • </submissionUnit>
  • </subject>
• </controlActProcess>

All information in this section is organized in order that the eCTD v4.0 XML components appear within the schema with the exception of special types of submissions (e.g., regulator messages).

6.2.1 Submission Unit

The submissionUnit element was outlined in the ICH eCTD v4.0 Implementation Guide and only Health Canada-specific information is provided in this document. Health Canada exclusions of optional elements under submissionUnit are provided in section 6.2 Payload Message.

Conditions that apply to the submissionUnit element:

• Only one submissionUnit element can exist for a message.

6.2.2 Submission

The submission element describes the regulatory activity within an application / dossier. Health Canada exclusions of optional elements under submission are provided in section 6.2 Payload Message.

6.2.2.1 XML elements

The following tables provide a complete set of XML elements and attributes required for the submission element, and any special instructions.

[--] = no information is required in this cell

[--] = no information is required in this cell

6.2.3 Application

The application element is presented in this section of the Implementation Guide as it is the connection point for the document and keywordDefinition elements in the XML message. The concept of application / dossier differs across regions. Health Canada exclusions of optional elements under application are provided in section 6.2 Payload Message.

Note: Application is also a Module 2-5 concept that will also be provided in the ICH eCTD v4.0 Implementation Guide (IG). Additional Regional information is provided in this document.

6.2.3.1. XML elements

The following tables provide a complete set of XML elements and attributes required for the application element, and any special instructions.

Conditions that apply to the application element:

• Only one application element can be provided for each submission element.
• An application element is required to have one and only one id.item@root.

[--] = no information is required in this cell

[--] = no information is required in this cell

6.2.3.2 XML samples

The following is an example of the XML for the application information. The application enters as a componentOf element between submission and application.

• <componentOf>
  • <application>
    • <id>
      • <item root="7227d769-6ac4-460c-bb1d-387a37ac9d2e" extension="e123456"/>
    • </id>
  • <code code="ca_application_type_1" codeSystem="2.16.840.1.113883.2.20.6.11"/>

6.3 Creating the message

With the individual components of the XML message described above, each of those components are used to demonstrate how to compose multiple components to address a specific scenario. This section describes the scenarios that explain how to address the creation and modifications to content transmitted during the lifecycle of a submission.

6.3.1 File Reuse

For file reuse, the text element should indicate the exact location of the submitted file (i.e., including the region specified folder and sequence number folder location). The following snippet provides an example of how to send a new document element for an existing file located in a different top-level folder in the Health Canada repository.

• <component>
  • <document>
    • <id root="1f44364a-2575-4d4e-b4ab-dfdf7c0d124b"/>
    • <title value="File Reused from Dossier#e123456"/>
    • <text integrityCheckAlgorithm="SHA256">
    • <reference value="../../e123456/9999/m1/content.pdf"/>
      • <integrityCheck>026C76D4E3AD972DD01A6A4090D1F61A213BD26DF648173A75AE451430C0FB39</integrityCheck>
    • </text>
  • </document>
• </component>

The document element should follow the ICH eCTD v4.0 Implementation Guide - with the exception of file reuse. The text.reference@value attribute should include the exact location of the file, which may exist in the same or different dossier.
The text.reference@value of the file must include:

• Relative path
• The top-level folder name portion of the dossier identifier.
• Sequence Number for the submission unit in which the file was originally submitted.
• The remainder of the path should be included as it existed when the submission unit was submitted to the Health Canada (i.e., "m1/content.pdf").

<reference value="../../e123456/1/m1/content.pdf"/>
For file reuse, the text element should contain the reference@value, text@IntegrityCheckAlgorithm and text.integrityCheck values of the previously submitted document element.

6.3.2 Use of media type

There are specific document object types as per OID 2.16.840.1.113883.2.20.6.10 that require the use of the text@mediaType attribute to identify that there will be additional processing. Only the relevant code from the controlled vocabulary list should be included in the payload message. Below is a snippet of labeling document that includes the text@mediaType attribute:
<text integrityCheckAlgorithm="SHA256" mediaType="ca_media_type_1">

6.4 Grouped submissions

Grouped submissions will not be used by Health Canada. The submissionunit.xml can only reference a single submission / regulatory activity and a single application / dossier.

6.5 Withdrawing submission contents

If a submission unit is to be withdrawn, a new submission unit should be submitted and all of the Context of Use elements need to either be suspended - i.e., they will be shown as inactive or a replace function needs to be provided to reinstate the previous document as the current submission / regulatory activity content

Note: Refer to the ICH eCTD v4.0 Implementation Guide for more details for suspend and replace operations on Context of Use.

6.6 Health Canada Messages - Two-way communication

6.6.1 Content of messages

Health Canada messages will use the appropriate application.id GUID and extension and submission.id GUIDs to identify the destination application / dossier and submission / regulatory activity in the receiver's system with a unique submissionUnit.id generated by the Health Canada compilation system. Health Canada will assign the appropriate two-way communication application.code, submission.code, and submissionUnit.code from the Health Canada CVs to identify the purpose of the message.

6.6.2 Contact party

6.6.2.1 Location in XML

The contactParty element in the XML message can only be sent in a communication from Health Canada.

The contactParty element in the XML message is in the following location for contacts:

submissionUnit>>componentOf1>>submission>>callBackContact>>contactParty>contactPerson

6.6.2.2 XML elements

The following tables provide a complete set of XML elements and attributes required for the contactParty element, and any special instructions.

6.6.2.2.1 Contact party

[--] = no information is required in this cell

[--] = no information is required in this cell

[--] = no information is required in this cell

6.6.2.2.2 Contact person

[--] = no information is required in this cell

[--] = no information is required in this cell

[--] = no information is required in this cell

6.6.2.3 Excluded elements

The following class attributes are excluded from the Health Canada implementation:

• contactPerson.id - note this is an additional identifier for the named individual instead of their contactParty.id. Only the contactParty.id is used.

6.6.3 Sequence number

The sequence number assigned by Health Canada will have its own series separate from that received by the sponsor (i.e., the values are not consecutive between the two parties). The series will start with 1 and increment by one each time a Health Canada message is sent to the sponsor.

7. Transition Mapping Message from eCTD v3.2.2

Detailed in this section are all Health Canada specific details relating to the Transition Mapping Message (TMM).

Health Canada will only allow transition of regional content from the current regional module 1 schema - v2.2.

7.1 Message Header

The message header information provides a set of elements that are needed to specify the sender and receiver as well as the version of the ICH and Regional/Module 1 Implementation Guides used to generate the message.

Table 16 - The following XML shows the required elements/attributes to validate the message against the schema

XML Structure

<PORP_IN000001UV ITSVersion="XML_1.0"xmlns="urn:hl7-org:v3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:hl7-org:v3 PORP_IN000001UV.xsd">

• <id/>
• <creationTime/>
• <interactionId/>
• <processingCode/>
• <processingModeCode/>
• <acceptAckCode/>
• <receiver>
  • <device classCode="DEV" determinerCode="INSTANCE">
    • <id>
      • <item root="" identifierName=""/>
    • </id>
  • </device>
• </receiver>
• <sender>
  • <device classCode="DEV" determinerCode="INSTANCE">
    • <id/>
  • </device>
• </sender>

The following XML sample shows the content of the message header element. The receiver.device.id element contains the IG versioning information required for the Transition Mapping Message XML header:

• <id/>
• <creationTime/>
• <interactionId/>
• <processingCode/>
• <processingModeCode/>
• <acceptAckCode/>
• <receiver typeCode="RCV">
  • <device classCode="DEV" determinerCode="INSTANCE">
    • <id>
      • <item root="2.16.840.1.113883.3.989.2.2.1.11.1" identifierName="ICH eCTD v4.0 IG v1.2"/>
    • </id>
  • </device>
• </receiver>
• <sender typeCode="SND">
  • <device classCode="DEV" determinerCode="INSTANCE">
    • <id/>
  • </device>
• </sender>

7.2 Payload message

The relevant elements and attributes in the v3.2.2 Transition Mapping Message are outlined in the ICH eCTD v4.0 Implementation Guide and only Health Canada-specific information is provided in this document.

7.2.1 Payload elements

Transition relies on the transition of the current view of the application / dossier - to include the same CTD heading placement and keywords. Refer to the ICH eCTD v4.0 Implementation Guide for additional information on the transition mapping message requirements.

7.2.1.1 Keywords in TMM

It is important to note that all keywords may not have existed as attributes in the ICH or Health Canada eCTD backbone (i.e., DTD files). Keywords therefore may need to be transitioned from multiple locations from eCTD v3.2.2 messages.

• Keywords may be transitioned from the following sources:
  • ICH Attributes
  • The STF file also includes the following eCTD v4.0 keywords
    • Document Types (previously specified as the file-tag element)
    • Study-title (previously specified as the title element)
    • Study-id
    • Duration, Species, Route of Administration, and Type of Control (previously specified as the Category element)
    • Site-id (previously specified as the property element)
  • ICH v3.2.2 Node Extensions should be transitioned to eCTD v4.0 using a group title keyword definition
• Consolidation of Keywords from the following attributes:
  • Study Id and Study Title - follow the instructions in the ICH eCTD v4.0 Implementation Guide to merge the values of these two attributes when transitioning from v3.2.2 to v4.0.

7.2.1.2 Post transition

The following special instructions should be followed for messages created after the Transition Mapping Message is submitted.

• Sequence number - follows the same instructions in the ICH eCTD v4.0 Implementation Guide unless the following scenario exists:
  • After receipt of the Transition Mapping Message, the sequence number must continue to be assigned sequentially and issued as whole numbers instead of following the v3.2.2 instructions for 4-digit values with leading zeros.