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

(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

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.

Table 1 - Health Canada Regulatory Terminology Mapping
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 Snippets

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

Location in XML

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

Table 2 - Location in XML Notation
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.

Element's location in XML

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 3 - Sample XML Element Table
Table Name: <element>.<element 2>
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:

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:

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: Sponsor submission unit
fig1
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: Health Canada submission unit
fig2
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: Comprehensive folder structure
fig3
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:

Table 4 - Health Canada regional controlled vocabularies
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:

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.

The submissionUnit element contains the following elements and attributes:

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

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:

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

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:

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.

6.2.2.1.1 Table 6 - Submission.id
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:
  • id.item@extension
  • id.item@identifierName
  • id.item@scope
  • id.item@reliability
  • id.item@displayable
  • id@validTimeLow
  • id@validTimeHigh
  • id@controlInformationRoot
  • id@controlInformationExtension
  • id@nullFlavor
  • id@flavorId
  • id@updateMode

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

6.2.2.1.2 Table 7 - Submission.code
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:
  • code.displayName
  • code.originalText
  • code.translation
  • code.source
  • code@codeSystemName
  • code@codeSystemVersion
  • code@codingRationale
  • code@controlInformationExtension
  • code@controlInformationRoot
  • code@flavorId
  • code@id
  • code@nullFlavor
  • code@updateMode
  • code@validTimeHigh
  • code@validTimeLow
  • code@valueSet
  • code@valueSetVersion
  • code@xsiType

[--] = 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:

6.2.3.1.1 Table 8 - application.id
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:
  • id.item@identifierName
  • id.item@scope
  • id.item@reliability
  • id.item@displayable
  • id@validTimeLow
  • id@validTimeHigh
  • id@controlInformationRoot
  • id@controlInformationExtension
  • id@nullFlavor
  • id@flavorId
  • id@updateMode

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

6.2.3.1.2 Table 9 - application.code
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:
  • code.displayName
  • code.originalText
  • code.translation
  • code.source
  • code@codeSystemName
  • code@codeSystemVersion
  • code@codingRationale
  • code@controlInformationExtension
  • code@controlInformationRoot
  • code@flavorId
  • code@id
  • code@nullFlavor
  • code@updateMode
  • code@validTimeHigh
  • code@validTimeLow
  • code@valueSet
  • code@valueSetVersion
  • code@xsiType

[--] = 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.

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.

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:

<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
6.6.2.2.1.1 Table 10 - callBackContact.contactParty.id
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:
  • id@extension
  • id@identifierName
  • id@scope
  • id@reliability
  • id@displayable
  • id@validTimeLow
  • id@validTimeHigh
  • id@controlInformationRoot
  • id@controlInformationExtension
  • id@nullFlavor
  • id@flavorId
  • id@updateMode

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

6.6.2.2.1.2 Table 11 - callBackContact.contactParty.code
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:
  • code.displayName
  • code.originalText
  • code.translation
  • code.source
  • code@codeSystemName
  • code@codeSystemVersion
  • code@codingRationale
  • code@controlInformationExtension
  • code@controlInformationRoot
  • code@flavorId
  • code@id
  • code@nullFlavor
  • code@updateMode
  • code@validTimeHigh
  • code@validTimeLow
  • code@valueSet
  • code@valueSetVersion
  • code@xsiType

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

6.6.2.2.1.3 Table 12 - callBackContact.contactParty.statusCode
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:
  • statusCode.part
  • statusCode@validTimeLow
  • statusCode@validTimeHigh
  • statusCode@controlInformationRoot
  • statusCode@controlInformationExtension
  • statusCode@nullFlavor
  • statusCode@flavorId
  • statusCode@updateMode

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

6.6.2.2.2 Contact person
6.6.2.2.2.1 Table 13- callBackContact.contactParty.contactPerson.name
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:
  • name.part@code
  • name.part@codeSystem
  • name.part@codeSystemVersion
  • name.part@language
  • name.part@nullFlavor
  • name.part@xsi:type

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

6.6.2.2.2.2 Table 14 - callBackContact.contactParty.contactPerson.telecom
Note: The xsi:type for the telecom attribute should be listed as an unordered list or "BAG_TEL".
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:
  • telecom.item@controlInformationRoot
  • telecom.item@controlInformationExtension
  • telecom.item@nullFlavor
  • telecom.item@flavorId
  • telecom.item@validTimeLow
  • telecom.item@validTimeHigh
  • telecom.item@updateMode
  • telecom.item@xsi:type

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

6.6.2.2.2.3 Table 15 - callBackContact.contactParty.asAgent.representedOrganization.name
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:
  • name.part@code
  • name.part@codeSystem
  • name.part@codeSystemVersion
  • name.part@language
  • name.part@nullFlavor
  • name.part@qualifier
  • name.part@xsi:type

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

6.6.2.3 Excluded elements

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

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">

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:

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.

7.2.1.2 Post transition

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

Page details

Date modified: