Draft guidance document profile: Canadian Module 1 Technical Implementation Guide for the Electronic Common Technical Document (eCTD) v4.0 Format
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
- Document content
- XML Snippets
- Location in XML
- XML Elements Tables
- 1. Purpose
- 2. Scope
- 3. Components of the Health Canada eCTD v4.0 specification
- 4. Submission contents, folder and file structure
- 5. Controlled vocabularies
- 6. eCTD v4.0 XML message for Health Canada
- 6.1 Message header for Health Canada
- 6.2 Payload message for Health Canada
- 6.3 Creating the message
- 6.4 Grouped submissions
- 6.5 Withdrawing submission contents
- 6.6 Health Canada Messages - Two-way communication
- 7. Transition Mapping Message from eCTD v3.2.2
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.
eCTD v4.0 Term | Health Canada Term | Description |
---|---|---|
Submission Unit | Regulatory Transaction | The base message produced in eCTD v4.0. Each eCTD v4.0 message or Regulatory Transaction is considered a Submission Unit. |
Submission | Regulatory Activity | A collection of Submission Units or Regulatory Transactions make up the content for a Submission or Regulatory Activity. |
Application | Dossier | A collection of Submissions or Regulatory Activities through the life cycle of a Product. |
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:
Notation | Description | Instruction for use |
---|---|---|
> | Single arrow | The element follows the previous without indentation in the XML. |
>> | Double arrow | The element follows the previous with an indentation in the XML. |
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>
- <component>
- <submissionUnit>
- <subject typeCode="SUBJ">
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.
Element | Attribute | Cardinality | Value(s) Allowed Examples | Description Instructions |
---|---|---|---|---|
[insert element] | [insert attribute] | [insert cardinality] | [insert value allowed examples] | [insert description instructions] |
[insert attribute] | [insert cardinality] | [insert value allowed examples] | [insert description instructions] | |
[insert attribute] | [insert cardinality] | [insert value allowed examples] | [insert description instructions] | |
Conformance | [insert conformance] | |||
Excluded Elements and/or Attributes | [insert excluded elements and/or attributes] |
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.
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.
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.
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:
eCTD v4.0 term | Health Canada term | OID |
---|---|---|
Application Type | Dossier Type | 2.16.840.1.113883.2.20.6.11 |
Context of Use | Context of Use | 2.16.840.1.113883.2.20.6.43 |
Media Type | Media Type | 2.16.840.1.113883.2.20.6.10 |
Submission Contact Status | Regulatory Activity Contact Status | 2.16.840.1.113883.2.20.6.44 |
Submission Contact Type | Regulatory Activity Contact Type | 2.16.840.1.113883.2.20.6.45 |
Submission Type | Regulatory Activity Type | 2.16.840.1.113883.2.20.6.46 |
Submission Unit Type | Regulatory Transaction Description | 2.16.840.1.113883.2.20.6.47 |
telecom.item@capabilities | Telecommunications Capability | 2.16.840.1.113883.2.20.6.19 |
telecom.item@use | Telecommunications Use | 2.16.840.1.113883.2.20.6.4 |
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>
- <id>
- </device>
- <device classCode="DEV" determinerCode="INSTANCE">
- </receiver>
- <sender typeCode="SND">
- <device classCode="DEV" determinerCode="INSTANCE">
- <id/>
- </device>
- <device classCode="DEV" determinerCode="INSTANCE">
- </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>
- <governingAuthority>
- </territorialAuthority>
- <territorialAuthority>
- </primaryInformationRecipient>
- <replacementOf typeCode="RPLC">
- <relatedContextOfUse>
- <id/>
- </documentReference>
- <relatedContextOfUse>
- </derivedFrom>
- <subjectOf negationInd="">
- <submissionReference>
- <id> <item/> </id>
- </submissionReference>
- <submissionReference>
- </subjectOf>
- <referencedBy typeCode="REFR">
- <keyword>
- <code/>
- </keyword>
- <keyword>
- </referencedBy>
- </contextOfUse>
- </component>
- title
- Excluded from Health Canada eCTD v4.0 implementation
- statusCode
- Excluded from Health Canada eCTD v4.0 implementation
- primaryInformationRecipient
- Excluded from Health Canada eCTD v4.0 implementation
- negationInd
- Excluded from Health Canada eCTD v4.0 Implementation
- submissionReference
- Excluded from Health Canada eCTD v4.0 Implementation
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>
- <representedOrganization>
- </asAgent>
- </contactPerson>
- </contactParty>
- <id/>
- </callBackContact>
- <subject1>
- <regulatoryStatus>
- <code/>
- </regulatoryStatus>
- <regulatoryStatus>
- </subject1>
- <subject2>
- <review>
- <id/>
- <statusCode/>
- <effectiveTime/>
- <subject1>
- <manufacturedProduct>
- <manufacturedProduct>
- <name/>
- </manufacturedProduct>
- <manufacturedProduct>
- </manufacturedProduct>
- <manufacturedProduct>
- </subject1>
- <holder>
- <applicant/>
- </holder>
- <author>
- <territorialAuthority/>
- </author>
- <subject2>
- <productCategory>
- <code/>
- </productCategory>
- <productCategory>
- </subject2>
- <subject3>
- <regulatoryStatus>
- <code/>
- </regulatoryStatus>
- <regulatoryStatus>
- </subject3>
- </review>
- <review>
- </subject2>
- </subject3>
- <mode>
- <code/>
- </mode>
- <mode>
- </subject3>
- <subject4>
- <regulatoryReviewTime>
- <code/>
- </regulatoryReviewTime>
- <regulatoryReviewTime>
- </subject4>
- <subject5>
- <submissionGroup>
- <id/>
- </submissionGroup>
- <submissionGroup>
- </subject5>
- <contactParty>
- <componentOf1>
- callBackContact
- Excluded from eCTD v4.0 messages sent to Health Canada - Will be included in Health Canada Two-Way Communication (see section 6.6) - See ICH eCTD v4.0 Implementation Guide for use during Transition Mapping.
- regulatoryStatus
- Excluded from ICH eCTD v4.0 Implementation.
- review (and all child elements)
- Excluded from Health Canada eCTD v4.0 Implementation
- review (and all child elements)
- Excluded from Health Canada eCTD v4.0 Implementation
- mode
- Excluded from Health Canada eCTD v4.0 Implementation
- regulatoryReviewTime
- Excluded from Health Canada eCTD v4.0 Implementation
- submissionGroup
- Excluded from Health Canada eCTD v4.0 Implementation
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>
- <sponsorOrganization>
- </applicant>
- <applicant>
- </holder>
- <id>
- <informationRecipient>
- <territorialAuthority>
- <governingAuthority>
- <id/>
- <name/>
- </governingAuthority>
- <governingAuthority>
- </territorialAuthority>
- <territorialAuthority>
- </informationRecipient>
- <subject>
- <reviewProcedure>
- <code/>
- </reviewProcedure>
- <reviewProcedure>
- </subject>
- <reference>
- <applicationReference>
- <id/>
- </applicationReference>
- <applicationReference>
- </reference>
- <component>
- <document>
- <id/>
- <title/>
- <text integrityCheckAlgorithm="" mediaType="" language="">
- <reference/>
- <integrityCheck/>
- </text>
- <referencedBy typeCode="REFR">
- <keyword>
- <code/>
- </keyword>
- <keyword>
- </referencedBy>
- </document>
- <document>
- </component>
- <referencedBy>
- <keywordDefinition>
- <code/>
- <statusCode/>
- <value>
- <item code="" codeSystem="">
- <displayName/>
- </item>
- <item code="" codeSystem="">
- </value>
- </keywordDefinition>
- <keywordDefinition>
- </referencedBy>
- <referencedBy>
- </application>
- <application>
- </componentOf>
- <componentOf>
- </submission>
-
- </componentOf1>
- holder
- Excluded from HPFB eCTD v4.0 Implementation
- informationRecipient.territorialAuthority
- Excluded from HPFB eCTD v4.0 Implementation
- reviewProcedure
- Excluded from HPFB eCTD v4.0 Implementation
- applicationReference
- Excluded from HPFB eCTD v4.0 Implementation
- keyword under document
- Excluded from ICH eCTD v4.0 Implementation
These are the closing element tags for the key elements in the eCTD v4.0 message.
-
-
-
- <componentOf2>
- <categoryEvent>
- <code/>
- <component>
- <categoryEvent>
- <code/>
- </categoryEvent>
- <categoryEvent>
- </component>
- </categoryEvent>
- <categoryEvent>
- </componentOf2>
- <componentOf2>
- </submissionUnit>
-
- </subject>
-
- </controlActProcess>
- subject.categoryEvent
- Excluded from HPFB eCTD v4.0 Implementation
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.
Element | Attribute | Cardinality | Value(s) Allowed Examples | Description Instructions |
---|---|---|---|---|
id | [--] | [1..1] | [--] | This is the container element of the following elements and attributes by which it uniquely identifies the submission. |
id.item | root | [1..1] | Valid GUID | The root attribute of the id.item element provides a unique identifier (GUID) for the submission. |
Conformance | The id.item@root attribute is required for the submission element. | |||
Excluded Elements and/or Attributes | The following datatype attributes are excluded:
|
[--] = no information is required in this cell
Element | Attribute | Cardinality | Value(s) Allowed Examples | Description Instructions |
---|---|---|---|---|
code | [--] | [1..1] | [--] | This is the container element that organizes the coded value for the submission. |
code | [1..1] | Alpha | The code attribute indicates a coded value for the type of submission being sent. | |
codeSystem | [1..1] | Valid OID | The codeSystem attribute is a unique identifier that indicates the controlled vocabulary system. | |
Excluded Elements and/or Attributes | The following datatype elements and attributes are excluded:
|
[--] = 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.
Element | Attribute | Cardinality | Value(s) AllowedExamples | Description Instructions |
---|---|---|---|---|
id | [--] | [1..1] | [--] | This is the container element of the following elements and attributes by which it uniquely identifies the application / dossier. |
id.item | [--] | [1..1] | [--] | This is the container element of the following attributes by which it uniquely identifies the application / dossier. |
root | [1..1] | GUID | The root attribute of the id.item element provides a GUID. | |
extension | [1..1] | Text e.g., e123456 |
The extension attribute of the id.item element provides a location to specify the top-level folder name portion of the dossier identifier. | |
Excluded Elements and/or Attributes | The following datatype attributes are excluded:
|
[--] = no information is required in this cell
Element | Attribute | Cardinality | Value(s) Allowed Examples | Description Instructions |
---|---|---|---|---|
code | [--] | [1..1] | [--] | This is the container element that organizes the coded value for the application / dossier. |
code | [1..1] | Alpha | The code attribute is a unique value that indicates the type of application / dossier based on the Health Canada controlled vocabulary. | |
codeSystem | [1..1] | Valid OID | The codeSystem attribute is a unique identifier that indicates the controlled vocabulary system. This should be the OID registered for the code system. | |
Excluded Elements and/or Attributes | The following datatype elements and attributes are excluded:
|
[--] = 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>
- <id>
- <code code="ca_application_type_1" codeSystem="2.16.840.1.113883.2.20.6.11"/>
- <application>
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>
- <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
Element | Attribute | Cardinality | Value(s) Allowed Examples | Description Instructions |
---|---|---|---|---|
id | [--] | [1..1] | [--] | This is a container element that organizes the contact party's identifier. |
root | [1..1] | Valid GUID | The root attribute is for a global unique identifier for the contact party. | |
Excluded Elements and/or Attributes | The following datatype elements and attributes are excluded:
|
[--] = no information is required in this cell
Element | Attribute | Cardinality | Value(s) Allowed Examples | Description Instructions |
---|---|---|---|---|
code | [--] | [1..1] | [--] | This is a container element that organizes the coded value for the Contact Party. |
code | [1..1] | Alpha | The code attribute is a unique value that indicates the type of Contact Party based on Regional controlled vocabulary. | |
codeSystem | [1..1] | Valid OID | The codeSystem attribute is a unique identifier that indicates the controlled vocabulary system. | |
Excluded Elements and/or Attributes | The following datatype elements and attributes are excluded:
|
[--] = no information is required in this cell
Element | Attribute | Cardinality | Value(s) Allowed | Description Instructions |
---|---|---|---|---|
statusCode | [--] | [1..1] | [--] | This is a container element that organizes the status code value for the Contact Party. |
code | [1..1] | Alpha | The code attribute is a unique value that indicates the status of the Contact Party, and is based on HL7 controlled vocabulary constrained by the region. | |
updateMode | [0..1] | Alpha | The updateMode attribute provides the coded value to indicate if the statusCode has been changed for the Contact Party. | |
Excluded Elements and/or Attributes | The following datatype elements and attributes are excluded:
|
[--] = no information is required in this cell
6.6.2.2.2 Contact person
Element | Attribute | Cardinality | Value(s) AllowedExamples | Description Instructions |
---|---|---|---|---|
name.part | [--] | [1..n] | [--] | This is a container element that organizes the value of contact person's name. |
value | [1..1] | String e.g., Jane |
The value attribute is for the value of the name part of the Contact Party. | |
type | [1..1] | Alpha e.g., GIV *note this is a controlled list from HL7 and included in the schema |
The type attribute is for the type of the name part - e.g., family name, given name (including first name and middle name or initial). | |
qualifier | [0..1] | Alpha e.g., MID, IN *note this is a controlled list from HL7 and included in the schema |
The qualifier attribute is a subtype of the name part - e.g., middle name or initial. | |
Conformance | At least given and family name must be provided in name.part elements. | |||
Excluded Elements and/or Attributes | The following datatype elements and attributes are excluded:
|
[--] = no information is required in this cell
Element | Attribute | Cardinality | Value(s) Allowed Examples | Description Instructions |
---|---|---|---|---|
item | [--] | [1..1] | [--] | This is a container element that organizes the Contact Party's contact information (e.g., telephone and email). |
value | [1..1] | String e.g., tel:+1(111)999-9999 |
The value attribute provides the Contact Party's contact information (e.g., telephone and email). | |
use | [1..1] | Alpha | The use attribute value indicates the telecom connection (e.g., work, private) and is based on Health Canada controlled vocabulary - 2.16.840.1.113883.2.20.6.4. | |
capabilities | [1..1] | Alpha | The capabilities attribute value indicates the telecom service and is based on Health Canada controlled vocabulary - 2.16.840.1.113883.2.20.6.19. | |
Excluded Elements and/or Attributes | The following datatype elements and attributes are excluded:
|
[--] = no information is required in this cell
Element | Attribute | Cardinality | Value(s) Allowed Examples | Description Instructions |
---|---|---|---|---|
name.part | [--] | [1..1] | [--] | This is a container element that organizes the value for the represented Organization's name. |
value | [1..1] | String e.g., Acme Pharmaceuticals |
The value attribute provides the organization's name. | |
Excluded Elements and/or Attributes | The following datatype elements and attributes are excluded:
|
[--] = 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>
- <id>
- </device>
- <device classCode="DEV" determinerCode="INSTANCE">
- </receiver>
- <sender>
- <device classCode="DEV" determinerCode="INSTANCE">
- <id/>
- </device>
- <device classCode="DEV" determinerCode="INSTANCE">
- </sender>
- From <id/> to <receiver>
- These elements should be represented with self-closing tags as shown here. If so state these are to be empty elements.
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>
- <id>
- </device>
- <device classCode="DEV" determinerCode="INSTANCE">
- </receiver>
- <sender typeCode="SND">
- <device classCode="DEV" determinerCode="INSTANCE">
- <id/>
- </device>
- <device classCode="DEV" determinerCode="INSTANCE">
- </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.
Page details
- Date modified: