Ébauche de la ligne directrice : Guide de mise en œuvre technique du module 1 canadien pour le format Electronic Common Technical Document (eCTD) v4.0

(PDF Version - 438 Ko)

Date de l'Ébauche : 2019/06/26

La présente ligne directrice est publiée dans le seul but de recueillir des commentaires.

Also available in English under the title: Draft Guidance Document: Canadian Module 1 Technical Implementation Guide for the Electronic Common Technical Document (eCTD) v4.0 Format

Avant-propos

Les lignes directrices sont des documents destinés à guider l'industrie et les professionnels de la santé sur la façon de se conformer aux lois et aux règlements en vigueur. Elles fournissent également aux membres du personnel des renseignements concernant la façon de mettre en œuvre le mandat et les objectifs de Santé Canada de manière juste, uniforme et efficace.

Les lignes directrices sont des outils administratifs n'ayant pas force de loi, ce qui permet une certaine souplesse d'approche. Les principes et les pratiques énoncés dans le présent document peuvent être remplacés par d'autres approches, à condition que celles-ci s'appuient sur une justification adéquate. Il faut tout d'abord discuter d'autres approches avec le programme concerné pour s'assurer qu'elles respectent les exigences des lois et des règlements applicables.

Dans la foulée de ce qui précède, il importe également de mentionner que Santé Canada se réserve le droit de demander des renseignements ou du matériel supplémentaire, ou de définir des conditions dont il n'est pas explicitement question dans le présent document, afin que le Ministère puisse être en mesure d'évaluer adéquatement l'innocuité, l'efficacité ou la qualité d'un produit thérapeutique donné. Santé Canada s'engage à justifier de telles demandes et à documenter clairement ses décisions.

Table des matières

• Avis aux lecteurs
• Instructions aux lecteurs
• Mise en correspondance de la terminologie réglementaire de Santé Canada
  • Tableau 1 : Correspondance avec la terminologie réglementaire de Santé Canada
• Contenu du document
• XML Snippets
• Emplacement dans XML
  • Tableau 2 : Emplacement de XML Notation
• Tableaux de XML Elements
  • Tableau 3 - Modèle de tableau de XML Element
• 1. Objet
• 2. Portée
• 3. Éléments de la spécification eCTD v4.0 de Santé Canada.
  • 3.1 Ressources citées en référence
  • 3.2 Le message eCTD v4.0 XML schema
• 4. Contenu, dossier et structure de fichier des présentations
  • 4.1 Contenu d'une unité de présentation
    • 4.1.1 Contenu de la Submission unit des messages de promoteurs
    • 4.1.2 Contenu de l'unité de présentation des messages de Santé Canada
    • 4.1.3 Structure détaillée de dossier
  • 4.2 Formats de fichier et conventions d'appellation
  • 4.3 Hiérarchie des dossiers
• 5. Vocabulaires normalisés
  • 5.1 Vocabulaires normalisés spécifiés par région
    • Tableau 4 : Vocabulaires normalisés régionaux de Santé Canada
  • 5.2 Vocabulaires régionaux exclus
• 6. Message de eCTD v4.0 XML de Santé Canada
  • 6.1 En-tête de message de Santé Canada
  • 6.2 Payload message de Santé Canada
    • Tableau 5 : eCTD v4.0 XML Message Payload de Santé Canada
    • 6.2.1 Unité de présentation
    • 6.2.2 Présentation
      • 6.2.2.1 XML elements
        • 6.2.2.1.1 Tableau 6 - Submission.id
        • 6.2.2.1.2 Tableau 7 - Submission.code
    • 6.2.3 Application
      • 6.2.3.1. XML elements
        • 6.2.3.1.1 Tableau 8 - application.id
        • 6.2.3.1.2 Tableau 9 - application.code
      • 6.2.3.2 Exemples de XML
  • 6.3 Élaboration du message
    • 6.3.1 Réutilisation d'un fichier
    • 6.3.2 Utilisation d'un type de média
  • 6.4 Présentations groupées
  • 6.5 Retrait de contenu relatif à la présentation
  • 6.6 Messages de Santé Canada : une communication bidirectionnelle
    • 6.6.1 Contenu des messages
    • 6.6.2 Contact party
      • 6.6.2.1 Emplacement dans XML
      • 6.6.2.2 XML elements
        • 6.6.2.2.1.1 Tableau 10 - callBackContact.contactParty.id
        • 6.6.2.2.1.2 Tableau 11 - callBackContact.contactParty.code
        • 6.6.2.2.1.3 Tableau 12 - callBackContact.contactParty.statusCode
        • 6.6.2.2.2.1 Tableau 13 - callBackContact.contactParty.contactPerson.name
        • 6.6.2.2.2.2 Tableau 14 - callBackContact.contactParty.contactPerson.telecom
        • 6.6.2.2.2.3 Tableau 15 - callBackContact.contactParty.asAgent.representedOrganization.name
      • 6.6.2.3 Éléments exclus
    • 6.6.3 Sequence number
• 7. Transition Mapping Message de eCTD v3.2.2
  • 7.1 Message Header
    • Tableau 16 - Le XML suivant indique les elements/attributes requis pour valider le message par rapport au schema
  • 7.2 Payload message
    • 7.2.1 Payload elements
      • 7.2.1.1 Keywords in TMM
      • 7.2.1.2 Post-transition

Avis aux lecteurs

Certaines sections du présent document faisant référence à la norme HL7 (Version 3), Regulatory Product Submission Release 2 Normative, sont utilisées avec la permission de l'éditeur. La norme HL7 (Version 3), Regulatory Product Submission Release 2 Normative, est protégée par les droits d'auteur de Health Level Seven International^®. TOUS DROITS RÉSERVÉS.

Instructions aux lecteurs

Ce document technique fournit des directives sur la façon de mettre en œuvre les spécifications du format électronique Common Technical Document v4.0 (eCTD v4.0) établi par l'International Conference on Harmonisation (ICH) pour le contenu de présentation du module 1 de Santé Canada. L'information du présent document est présentée de manière uniforme avec l'ICH eCTD v4.0 Implementation Guide. En outre, des repères visuels permettent d'enrichir la lecture en fournissant davantage de contexte ou de l'information de référence présentée dans le document.

Ce document doit être utilisé conjointement avec la dernière version de l'ICH eCTD v4.0 Implementation Guide. Sont exclus du présent document les éléments du message de Santé Canada qui sont identiques à ceux du Guide de mise en œuvre de l'ICH afin d'éviter toute duplication.

Mise en correspondance de la terminologie réglementaire de Santé Canada

Dans le présent document, plusieurs termes utilisés dans le contexte de la création de messages eCTD v4.0 diffèrent du vocabulaire réglementaire généralement utilisé à Santé Canada. Pour éviter toute confusion et établir une compréhension commune en matière de communication réglementaire, le tableau de correspondance terminologique suivant a été produit.

Tableau 1 : Correspondance avec la terminologie réglementaire de Santé Canada

Terme de l'eCTD v4.0	Terme de Santé Canada	Description
Unité de présentation	Transaction réglementaire	Le message de base produit dans eCTD v4.0. Chaque message eCTD v4.0 ou transaction réglementaire est considéré comme une unité de présentation.
Présentation	Activité réglementaire	Un ensemble d'unités de présentation ou de transactions réglementaires qui constitue le contenu en vue d'une présentation ou d'une activité réglementaire.
Application	Dossier	Une série de présentations ou d'activités de réglementation qui ont lieu au cours du cycle de vie d'un produit.

Contenu du document

Plusieurs notations sont employées dans ce document pour fournir plus de clarté sur le sujet traité. La première consiste en l'utilisation de composants XML (eXtensible Markup Language) (soit, elements et attributes) par opposition au concept qu'ils représentent. Le texte suivant du document accompagne les notations décrites ci-dessous :

• Composants XML
  • Le texte narratif du document est soit en gras, soit en italique, soit en langage caml, p. ex. contextOfUse.
  • Les exemples XML sont indiqués dans la section XML Snippets ci-dessous.
• Concepts qui ne font pas référence à la norme et/ou au message.
  • Un concept défini, p. ex., Context of Use, est noté en texte simple avec la première lettre des mots débutant par une majuscule.

XML Snippets

Les règles suivantes ont été observées pour l'élaboration des exemples XML :

• La notation de <!--....notes….-- > a été utilisée pour décrire les conditions d'un élément qui doivent être observées.
• La notation … [Description] … a été utilisée pour indiquer lorsqu'il y avait des éléments additionnels qui n'étaient pas représentés dans la notation XML, mais qui pouvaient être présents dans le message XML.

Emplacement dans XML

Chacun des éléments du présent document comprend une section intitulée « Location in XML ». La notation incluse a recours à la convention suivante :

Tableau 2 : Emplacement de XML Notation

Notation	Description	Directive d'utilisation
>	Flèche unique	L'élément suit le précédent sans retrait dans la description XML.
>>	Double flèche	L'élément suit le précédent avec un retrait dans la description XML.

Par exemple, les emplacements suivants indiquent les deux notations et sont suivis par un exemple XML.

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

Emplacement d'Element's dans la description XML

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

Le numéro prioritaire est représenté dans le chemin d'accès puisqu'il s'agit d'un élément requis. Dans certains cas, les éléments facultatifs ne figureront pas dans cette notation. Le schéma est utilisé pour exécuter les exigences de séquencement d'éléments, sans toutefois traiter les inclusions ou les exclusions d'éléments facultatifs en fonction de règles opérationnelles régionales.

Remarque : Pour les éléments relatifs à Santé Canada contenu dans les données utiles du message, veuillez vous reporter à Tableau 5 eCTD v4.0 XML Message Payload de Santé Canada.

Tableaux de XML Elements

Un tableau a été produit pour chacun des éléments du message XML. Lorsque des éléments comportent des parties ou des attributs multiples d'éléments, ceux-ci sont présentés dans un même tableau. Lorsqu'un élément ne présente aucun attribut ni valeur, la cellule est grisée pour indiquer qu'une valeur d'attribut n'est pas requise dans le message XML.

Tableau 3 - Modèle de tableau de XML Element
Nom du tableau : <element>.<element 2>

Élément	Attribut	Cardinalité	Exemples devaleurs autorisées	Directives de Description
[insérer l'élément]	[insérer l'attribut]	[insérer la cardinalité]	[insérer des exemples de valeur autorisée]	[insérer des directives relatives à la description]
	[insérer l'attribut]	[insérer la cardinalité]	[insérer des exemples de valeur autorisée]	[insérer des directives relatives à la description]
	[insérer l'attribut]	[insérer la cardinalité]	[insérer des exemples de valeur autorisée]	[insérer des directives relatives à la description]
Conformité	[insérer la conformité]
Éléments et/ou Attributs exclus	[insérer des éléments et/ou des attributs exclus]

Nom du tableau : Chaque tableau est nommé en fonction des elements qu'il représente dans le format XML (soit <element>.<element 2>). Par exemple, si l'Application element possède un element pour l'identifiant, celui-ci serait représenté par : application.id.

Element: Identifie le XML element.

Attribute: Identifie le XML attribute.

Exemples de valeur(s) autorisée(s) : Identifie les valeurs allouées en utilisant des types de données simples et des exemples connexes. Des références à un vocabulaire normalisé sont également fournies.

Description/directives : Fournir une description du (de la) element ou du (de la) attribute.

Conformité : Identifie les exigences en matière de validation (p. ex. XML Elements ou attributes) et/ou les conditions qui doivent être remplies par l'élément.

Éléments et/ou attributs exclus : Identifie les éléments relatifs au type de données et/ou les attributs qui font partie de la norme HL7 Regulated Product Submission et qui ne sont pas inclus dans la partie du Module 1 de la mise en œuvre de eCTD v4.0

1. Objet

Le présent document sert de Guide de mise en œuvre technique et de spécification technique pour le message eCTD v4.0 de Santé Canada utilisant la norme Health Level 7 (HL7) Regulated Product Submission (RPS) Release 2, Normative. Santé Canada est l'administration régionale du Canada et, par conséquent, établit les normes canadiennes. Les lecteurs visés par le présent document sont principalement des personnes ou organismes responsables de créer ou de mettre en œuvre des systèmes de publication ou d'examen au format eCTD v4.0, dont l'utilisation devrait donner aux fournisseurs de l'outil eCTD la possibilité d'élaborer un outil qui permet de publier ou d'afficher des messages eCTD v4.0 (soit en recourant à la norme HL7 RPS) pour Santé Canada.

Ce guide de mise en œuvre doit être utilisé parallèlement avec l'ICH eCTD v4.0 Implementation Guide, étant donné que le message eCTD v4.0 peut s'avérer incomplet si les directives des deux guides de mise en œuvre ne sont pas suivies.

2. Portée

La norme RPS définit le message pour l'échange d'information électronique entre les organismes de réglementation et l'industrie. Le message procure la capacité de décrire le contenu de l'échange de nature réglementaire et toute l'information nécessaire pour traiter l'échange entre les parties. Le message RPS est conçu de manière à être suffisamment modulable pour appuyer les échanges en matière de réglementation pour un produit réglementé.

Chaque type de produit réglementé disposera d'un guide de mise en œuvre unique qui décrira de quelle manière il faudrait utiliser la norme RPS dans ce contexte. Par exemple, eCTD v4 est l'exemple de la norme RPS destinée aux médicaments à usage humain et aux produits biologiques.

Ce document ne comprend que les directives du eCTD v4.0 Module 1 pour le contenu régional de Santé Canada de l'eCTD v4.0. Les directives des eCTD v4.0 Modules 2 - 5, qui sont transmises à l'ensemble des régions de l'ICH, n'ont pas été intégrées au présent guide de mise en œuvre. D'ailleurs, certaines sections du présent document peuvent également être incluses dans l'ICH eCTD v4.0 Implementation Guide et faire allusion à cet ouvrage.

En outre, des règles et exemples pertinents sont fournis pour permettre d'effectuer une transition de la version eCTD v3.2.2 à la v4.0 dans une application / dossier.

3. Éléments de la spécification eCTD v4.0 de Santé Canada.

La présente section offre un aperçu des éléments essentiels relatifs à la spécification eCTD v4.0 de Santé Canada. Les éléments essentiels comprennent :

• Les documents cités en référence (des renseignements détaillés se trouvent à la Section 3.1)
• Le XML Schema et message (des renseignements détaillés se trouvent à la Section 3.2)
• Contenu relatif à la présentation, structure des répertoires et fichiers (des renseignements détaillés se trouvent à la Section 4)
• Des vocabulaires normalisés (des renseignements détaillés se trouvent à la Section 3.1)
• Message eCTD V4.0 XML pour Santé Canada y compris les éléments spécifiques à Santé Canada (des renseignements détaillés se trouvent à la Section 6.
• Compatibilité avec la v3.2.2 et référence à celle-ci (des renseignements détaillés se trouvent à la Section 7)
• Règles en matière de validation (les renseignements relatifs aux documents cités en référence se trouvent à la Section 3.1)

Chacun de ces éléments est détaillé dans les sections ultérieures et comprend des renseignements spécifiques au sujet du rôle joué par l'élément dans la mise en œuvre de la spécification.

Remarque : Citez en référence le site Web de l'ICH pour obtenir une liste complète des documents de la trousse de mise en œuvre de l'ICH eCTD v4.0 et le site Web de Santé Canada pour obtenir une liste complète des composants du message eCTD v4.0 du module 1 de Santé Canada.

3.1 Ressources citées en référence

Les documents suivants devraient être cités en référence pour disposer d'un contenu réglementaire et technique complet :

• ICH eCTD v4.0 Implementation Package
• ICH Specification for Submission Format for eCTD
• Préparation des activités de réglementation en format eCTD pour Santé Canada
• Registre du vocabulaire normalisé
• Règles de validation des transactions réglementaires envoyées à Santé Canada en format electronic Common Technical Document (eCTD v4.0)

Note aux responsables de la mise en œuvre : Les vocabulaires normalisés du Module 1 de Santé Canada sont fournis dans le registre du vocabulaire normalisé. Ils sont destinés aux responsables de la mise en œuvre pour être utilisés comme une version programmable du contenu.

3.2 Le message eCTD v4.0 XML schema

Le message eCTD v4.0 est basé sur le HL7 RPS schema et la spécification de l'ICH eCTD v4.0. L'utilisation spécifique de Santé Canada est comprise dans le présent Guide de mise en œuvre de section 6.2. Il se peut qu'il n'y ait qu'un seul message de submissionunit.xml contenu dans l'échange de message eCTD v4.0.

4. Contenu, dossier et structure de fichier des présentations

La structure du dossier et du fichier précisée pour le contenu du document transmis avec le message XML doit être conforme aux diverses spécifications et règles présentées dans cette section.

4.1 Contenu d'une unité de présentation

Au moment de présenter le contenu d'une Submission Unit, la structure suivante devrait être utilisée :

Le dossier de tête contient l'ensemble des autres dossiers ainsi que leur contenu. Le nom du dossier de tête constitue une partie de l'identifiant du dossier (p. ex. e123456 comme l'illustre la figure 1) obtenu de Santé Canada. Ce numéro représente l'identifiant unique du dossier. Toutes les activités réglementaires et renseignements supplémentaires ultérieurs au format eCTD pour le même dossier doivent conserver le même identifiant.

Le dossier du sequence number doit être nommé en reprenant le "sequence number"de l'unité de présentation (soit la valeur réelle du numéro de séquence (p. ex. 1)).Veuillez noter que pour la correspondance provenant de Santé Canada, le dossier du sequence number se trouve dans un dossier intitulé "_hc" (Reportez-vous à la Section 0).

4.1.1 Contenu de la Submission unit des messages de promoteurs

Le promoteur transmettra du contenu de présentation en un seul message submissionunit.xml pour chaque transmission de message. Figure 1 : Unité de présentation du promoteur décrit la structure de dossier pour une submission unit envoyée à Santé Canada.

Figure 1 - Équivalent du texte

La figure 1 montre un exemple d'unité de soumission de sponsor. Par exemple, le dossier de niveau supérieur doit être e123456 et le sous-dossier, le dossier du numéro de séquence, nommé « 1 ». Les sous-sous-dossiers du sous-dossier du numéro de séquence doivent être m1, m2, m3, m4 et m5, avec les documents « sha256.txt » et « submissionunit.xml ».

4.1.2 Contenu de l'unité de présentation des messages de Santé Canada

La correspondance de Santé Canada est envoyée sous forme d'une unité de présentation unique dans chaque transmission de message. La Figure 2 : Unité des présentations de Santé Canada illustre la structure d'un dossier pour une unité de présentation transmise par Santé Canada.

Title - Équivalent du texte

La figure 2 montre un exemple d'unité de soumission générée par Santé Canada. Le dossier de niveau supérieur doit être l'ID de dossier, e123456. Les dossiers situés sous le dossier de niveau supérieur doivent être « _hc », avec des sous-dossiers supplémentaires ci-dessous pour chaque numéro de séquence, puis organisés en sous-sous-dossiers individuels pour chaque module.

4.1.3 Structure détaillée de dossier

Le répertoire complet de l'application / dossier peut réunir le contenu de la submission du promoteur et de Santé Canada au même emplacement. La Figure 3 : Structure détaillée de répertoire illustre la combinaison du contenu de submission unit du promoteur et de Santé Canada.

Title - Équivalent du texte

La figure 3 montre un exemple de structure de dossier complète combinant à la fois l'unité de soumission générée par le sponsor et l'unité de soumission générée par Santé Canada. Le dossier de niveau supérieur serait à nouveau l'ID de dossier, e123456. Les dossiers situés sous le dossier de niveau supérieur doivent commencer par les sous-dossiers de Santé Canada comme dans la figure 2, suivis des sous-dossiers de la figure 1.

4.2 Formats de fichier et conventions d'appellation

Reportez-vous à la Préparation des activités de réglementation en format eCTD de la spécification régionale de Santé Canada.

4.3 Hiérarchie des dossiers

Le Module 1 possède un dossier, soit m1. Utilisez des sous-dossiers seulement lorsqu'il y a conformité avec les spécifications techniques ou les directives relatives au contenu de présentation de Santé Canada. Reportez-vous à l'ICH eCTD v4.0 Implementation Guide pour connaître la hiérarchie du dossier pour les modules 2 à 5.

5. Vocabulaires normalisés

Comme indiqué, un message eCTD v4.0 fait l'objet d'une utilisation considérable de vocabulaires normalisés. Les sous-sections suivantes donnent un aperçu du vocabulaire normalisé utilisé dans le message eCTD v4.0 de Santé Canada.

5.1 Vocabulaires normalisés spécifiés par région

Les vocabulaires suivants utilisés pour la mise en œuvre de l'eCTD v4.0 sont gérés et entretenus par Santé Canada :

Tableau 4 : Vocabulaires normalisés régionaux de Santé 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 Vocabulaires régionaux exclus

Les vocabulaires normalisés de Santé Canada sont seulement fournis pour les éléments de code autorisés. Il existe certains éléments et leurs attributs de code qui sont exclus de la mise en œuvre de l'eCTD v4.0 de Santé Canada. Reportez-vous à la Section 6.2 pour connaître les elements exclus de l'ICH et de Santé Canada.

6. Message de eCTD v4.0 XML de Santé Canada

6.1 En-tête de message de Santé Canada

Les renseignements relatifs à l'en-tête de message fournissent un ensemble d'elements qui sont nécessaires pour mentionner l'expéditeur et le destinataire, ainsi que la version des guides de mise en œuvre de l'ICH et de Santé Canada utilisés pour générer le message.

Les exemples XML suivants indiquent le contenu relatif à l'élément d'ID de l'en-tête de message. Le receiver.device.id element renferme l'information relative aux versions du IG requise pour l'en-tête XML du message eCTD v4.0.

• <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 de Santé Canada

Le tableau suivant présente de façon détaillée la structure eCTD v4.0 XML indiquant le positionnement de chaque élément dans le XML Schema. L'organisation du tableau présente les trois elements suivants dans la structure : submissionUnit, submission et application. Lorsqu'ils ont fait l'objet d'une prolongation ou d'une exclusion par Santé Canada, ils sont annotés à l'aide d'encadrés sous forme de bulles indiquant les sources. Les éléments et attributs des données utiles qui ne sont pas annotés doivent être mis en œuvre exactement comme ils apparaissent dans le Guide de mise en œuvre de l'ICH eCTD v4.0.

Tableau 5 : eCTD v4.0 XML Message Payload de Santé Canada

Structure XML

Le eCTD v4.0 message débute au controlActProcess du XML payload message correspondant au contenu du Module 1.

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

Le submissionUnit element comprend les elements et attributes suivants :

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

Remarque : Tous ces elements ne sont pas inclus dans le guide de mise en œuvre. Reportez-vous à l'ICH eCTD v4.0 Implementation Guide pour obtenir de plus amples renseignements.

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

La présente section de XML porte sur la mention de l’élément de présentation. Les éléments suivants peuvent suivre le componentOf1.submisision element :

• sequenceNumber ((inclus en tant qu'élément de la relation entre submissionUnit et 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>

La présente section de la structure XML porte sur l'application element. La section relative à l'application comprend les elements suivants et leurs attributes :

• Titulaire
• 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>

Il s'agit des element tags de fermeture pour les key elements du message eCTD v4.0.

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

Toute l'information de la présente section est organisée de manière à ce que les composants the eCTD v4.0 XML apparaissent dans le schéma à l'exception des types de présentation spéciaux (p. ex. messages de l'organisme de réglementation).

6.2.1 Unité de présentation

L'élément submissionUnit a été exposé dans le ICH eCTD v4.0 Implementation Guide et seulement de l'information exclusive à Santé Canada est présentée dans ce document. Les exclusions relatives à Santé Canada des elements facultatifs concernant submissionUnit se trouvent à la Section 6.2 intitulée Données utiles du message.

Les conditions suivantes s'appliquent à la submissionUnit :

• Il ne peut y avoir qu'un seul élément de submissionUnit pour un message.

6.2.2 Présentation

Le submission element décrit l'activité réglementaire dans le cadre d'un(e) application / dossier. Les exclusions de Santé Canada relatives aux éléments facultatifs dans le cadre d'une présentation se trouvent à la Section 6.2 intitulée Payload Message.

6.2.2.1 XML elements

Les tableaux suivants fournissent un ensemble complet des XML elements et attributes requis pour le submissionelement, ainsi que les directives spéciales.

6.2.2.1.1 Tableau 6 - Submission.id

Élément	Attribut	Cardinalité	Exemples de valeurs autorisées	Directives de Description
id	[--]	[1..1]	[--]	Il s'agit de l'élément de conteneur des éléments et attributs suivants permettant d'identifier la présentation de façon unique.
id.item	racine	[1..1]	GUID valide	L'attribut racine de l'élément id.item fournit un identifiant unique (GUID) pour la présentation.
Conformité	L'id.item@root attribute est requis pour l'élément de présentation.
Éléments et/ou Attributs exclus	Les éléments et attributs de type de données suivants sont exclus : 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

[--] = aucune information n'est requise dans cette cellule.

6.2.2.1.2 Tableau 7 - Submission.code

Élément	Attribut	Cardinalité	Exemples de valeur(s) autorisée(s)	Directives de Description
code	[--]	[1..1]	[--]	Il s'agit de l'élément de conteneur qui permet d'organiser la valeur codée en vue de la présentation.
	code	[1..1]	Alpha	L'attribut de code indique une valeur codée pour le type de présentation transmise.
	codeSystem	[1..1]	OID valide	L'attribut codeSystem est un identifiant unique qui indique le système du vocabulaire normalisé.
Éléments et/ou Attributs exclus	Les éléments et attributs de type de données suivants sont exclus : 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

[--] = aucune information n'est requise dans cette cellule.

6.2.3 Application

La présente section présente l'application element du Implementation Guide étant donné que celui-ci représente le point de connexion du document et des éléments de la keywordDefinition du message XML. Le concept d'application / dossier est différent d'une région à l'autre. Les exclusions de Santé Canada relatives aux elements facultatifs concernés par l'application se trouvent à la Section 6.2 intitulée Données utiles du message.

Remarque : Le concept d'application se trouve également dans les Modules 2 à 5, qui sera d'ailleurs traité dans le Guide de mise en œuvre de l'ICH eCTD v4.0. De plus amples renseignements sur les caractéristiques régionales sont fournis dans le présent document.

6.2.3.1. XML elements

Les tableaux suivants fournissent un ensemble complet des XML elements et attributes requis pour l'élément relatif à l'application, ainsi que les directives spéciales.

Les conditions suivantes s'appliquent à l'élément relatif à l'application :

• Un seul application element peut être fourni pour chaque submission element.
• Un application element est nécessaire pour obtenir un seul et unique id.item@root.

6.2.3.1.1 Tableau 8 - application.id

Élément	Attribut	Cardinalité	Exemples de valeur(s) autorisée(s)	Directives de Description
id	[--]	[1..1]	[--]	Il s'agit de l'element de conteneur des elements et attributes suivants qui permettent d'identifier l'application / dossier unique.
id.item	[--]	[1..1]	[--]	Il s'agit du container element des attributes suivants qui permettent d'identifier l'application / dossier unique.
	root	[1..1]	GUID	L'attribut racine de l'élément id.item fournit un GUID.
	extension	[1..1]	Texte p. ex. e123456	L'attribute extension de l'element id.item prévoit un emplacement pour indiquer la partie réservée au nom dans le répertoire de tête de l'identifiant du dossier.
Éléments et/ou Attributs exclus	Les éléments et attributs de type de données suivants sont exclus : 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

[--] = aucune information n'est requise dans cette cellule.

6.2.3.1.2 Tableau 9 - application.code

Élément	Attribut	Cardinalité	Exemples de valeur(s) autorisée(s)	Directives de Description
code	[--]	[1..1]	[--]	Il s'agit de l'element de conteneur qui permet d'organiser la valeur codée de l'application / dossier.
	code	[1..1]	Alpha	L'attribute du code est une valeur unique qui indique le type of application / dossier en fonction du vocabulaire normalisé de Santé Canada.
	codeSystem	[1..1]	OID valide	L'attribut codeSystem est un identifiant unique qui indique le système du vocabulaire normalisé. Celui-ci devrait être l'OID enregistré pour le système de code.
Éléments et/ou Attributs exclus	Les éléments et attributs de type de données suivants sont exclus : 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

[--] = aucune information n'est requise dans cette cellule.

6.2.3.2 Exemples de XML

Voici un exemple de XML pour les détails relatifs à l'application. L'application est saisie comme un componentOf element entre submission et 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 Élaboration du message

Grâce aux composants individuels du message XML décrit ci-dessus, chacun de ces composants est utilisé pour indiquer comment créer des composants multiples pour traiter un cas de figure spécifique. La présente section décrit les cas de figure qui expliquent comment aborder la création et la modification de contenu transmis au cours du cycle de vie d’une présentation.

6.3.1 Réutilisation d’un fichier

En vue de la réutilisation d’un fichier, l’élément de texte devrait indiquer l’emplacement précis du fichier soumis (soit y compris le répertoire spécifique à la région et l’emplacement du répertoire du numéro de séquence). L’extrait suivant donne un exemple de la manière d’envoyer un nouvel élément de document pour un fichier existant situé dans un répertoire de tête différent du répertoire de Santé Canada.

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

L'élément de document doit se conformer au ICH eCTD v4.0 Implementation Guide; à l'exception de la réutilisation d'un fichier. L'attribut text.reference@value devrait comprendre l'emplacement précis du fichier, qui peut exister dans le même dossier ou un dossier différent.

Le text.reference@value du fichier doit comprendre :

• Chemin d'accès relatif
• La partie du nom du répertoire de tête de l'identifiant de répertoire nommé.
• Sequence Number pour l'unité de présentation dans laquelle le fichier a été soumis à l'origine.
• Le reste du chemin d'accès devra être inclus et repris intégralement au moment de la transmission de l'unité de présentation à Santé Canada (soit "m1/content.pdf").

<reference value="../../e123456/1/m1/content.pdf"/>
En ce qui concerne la réutilisation d'un fichier, le text element devrait comprendre les valeurs reference@value, text@IntegrityCheckAlgorithm et text.integrityCheck des document element envoyés auparavant.

6.3.2 Utilisation d'un type de média

Il existe des types d'objet de document spécifiques conformément à OID 2.16.840.1.113883.2.20.6.10 qui requièrent l'utilisation de l'attribut text@mediaType pour déterminer qu'il y aura un traitement supplémentaire. Seul le code approprié de la liste du vocabulaire normalisé devrait être inclus dans le message des données utiles. Voici un extrait d'étiquette de document qui comprend l'attribut text@mediaType :
<text integrityCheckAlgorithm="SHA256" mediaType="ca_media_type_1">

6.4 Présentations groupées

Santé Canada n'aura pas recours aux présentations groupées. La submissionunit.xml ne peut faire référence qu'à une seule submission / regulatory activity et à un(e) seul(e) application / dossier.

6.5 Retrait de contenu relatif à la présentation

Si une unité de présentation doit être retirée, une nouvelle submission unit doit être soumise et l'ensemble des the Context of Use elements doivent être soit interrompus (c.-à-d., ils paraîtront comme étant inactifs), soit une fonction de remplacement doit être fournie pour restituer le document antérieur comme étant le contenu de la current submission / regulatory activity.
Remarque : Reportez-vous à l'ICH eCTD v4.0 Implementation Guide pour obtenir plus de détails relatifs aux opérations d'interruption et de remplacement au sujet du Context of Use.

6.6 Messages de Santé Canada : une communication bidirectionnelle

6.6.1 Contenu des messages

Les messages de Santé Canada auront recours aux application.id GUID, prolongation et submission.id GUIDs appropriés pour identifier la destination application / dossier et submission / regulatory activity dans le système du destinataire grâce à un submissionUnit.id unique généré par le système de compilation de Santé Canada. Santé Canada attribuera les application.code, submission.code et submissionUnit.code de la communication bidirectionnelle appropriée pour les vocabulaires normalisés de Santé Canada pour déterminer le but du message.

Contact party

6.6.2.1 Emplacement dans XML

L'élément contactParty du message XML peut seulement être envoyé dans une communication de Santé Canada.

L'élément contactParty du message XML se trouve à l'emplacement suivant :

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

6.6.2.2 XML elements

Les tableaux suivants fournissent un ensemble complet des XML elements et attributes requis pour l'élément contactParty, ainsi que les directives spéciales.

6.6.2.2.1 Contact party

6.6.2.2.1.1 Tableau 10 - callBackContact.contactParty.id

Élément	Attribut	Cardinalité	Exemples de valeur(s) autorisée(s)	Directives de Description
id	[--]	[1..1]	[--]	Il s'agit d'un container element qui permet d'organiser l'identifiant du contact party.
	racine	[1..1]	GUID valide	L'attribut root sert à obtenir un identifiant global unique pour le contact party.
Éléments et/ou Attributs exclus	Les éléments et attributs de type de données suivants sont exclus : id@extension id@identifierName id@scope id@reliability id@displayable id@validTimeLow id@validTimeHigh id@controlInformationRoot id@controlInformationExtension id@nullFlavor id@flavorId id@updateMode

[--] = aucune information n'est requise dans cette cellule.

6.6.2.2.1.2 Tableau 11 - callBackContact.contactParty.code

Élément	Attribut	Cardinalité	Exemples de valeur(s) autorisée(s)	Directives de Description
code	[--]	[1..1]	[--]	Il s'agit d'un container element qui permet d'organiser la valeur codée pour le contact party.
	code	[1..1]	Alpha	Le code attribute est une valeur unique qui indique le type de contact party en fonction du vocabulaire normalisé de la région.
	codeSystem	[1..1]	OID valide	L'attribut codeSystem est un identifiant unique qui indique le système du vocabulaire normalisé.
Éléments et/ou Attributs exclus	Les éléments et attributs de type de données suivants sont exclus : 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

[--] = aucune information n'est requise dans cette cellule.

6.6.2.2.1.3 Tableau 12 - callBackContact.contactParty.statusCode

Élément	Attribut	Cardinalité	Exemples de valeur (s) autorisée (s)	Directives de Description
statusCode	[--]	[1..1]	[--]	Il s'agit du container element qui permet d'organiser l'état de la valeur codée pour le contact party.
	code	[1..1]	Alpha	Le code attribute est une valeur unique qui indique l'état du contact party en fonction du vocabulaire normalisé de la norme HL7 imposé par la région.
	updateMode	[0..1]	Alpha	L'attribut updateMode fournit la valeur codée pour indiquer si le statusCode du contact party a été changé.
Éléments et/ou Attributs exclus	Les éléments et attributs de type de données suivants sont exclus : statusCode.part statusCode@validTimeLow statusCode@validTimeHigh statusCode@controlInformationRoot statusCode@controlInformationExtension statusCode@nullFlavor statusCode@flavorId statusCode@updateMode

[--] = aucune information n'est requise dans cette cellule.

6.6.2.2.2 Personne-ressource

6.6.2.2.2.1 Tableau 13 - callBackContact.contactParty.contactPerson.name

Élément	Attribut	Cardinalité	Exemples de valeur(s) autorisée(s)	Directives de Description
name.part	[--]	[1..n]	[--]	Il s'agit d'un container element qui permet d'organiser la valeur du contact person's name.
	value	[1..1]	String p. ex. Jane	La value attribute sert à attribuer une valeur à l'élément du nom de Contact Party.
	type	[1..1]	Alpha p. ex. GIV *Veuillez noter qu'il s'agit d'une liste contrôlée par HL7 et comprise dans le schema.	Le type attribute sert à indiquer le type de la partie du nom - p. ex. nom de famille, prénom (y compris le prénom et le second prénom ou de son initiale).
	qualifier	[0..1]	Alpha p. ex. MID, IN *Veuillez noter qu'il s'agit d'une liste contrôlée par HL7 et comprise dans le schéma.	Le qualifier attribute est un sous-type de la name part - p. ex. second prénom ou initiale.
Conformité	Au moins le nom et le nom de famille doivent être fournis dans les éléments name.part.
Éléments et / ou attributs exclus	Les éléments et attributs de type de données suivants sont exclus : name.part@code name.part@codeSystem name.part@codeSystemVersion name.part@language name.part@nullFlavor name.part@xsi:type

[--] = aucune information n'est requise dans cette cellule.

6.6.2.2.2.2 Tableau 14 -callBackContact.contactParty.contactPerson.telecom
Remarque : Le xsi:type pour le telecom attribute doit être énuméré dans une liste non ordonnée ou « BAG_TEL ».

Élément	Attribut	Cardinalité	Exemples de valeur(s) autorisée(s)	Directives de Description
item	[--]	[1..1]	[--]	Il s'agit d'un value attribute qui permet d'organiser les coordonnées du contact party (p. ex. téléphone et adresse de courriel).
	value	[1..1]	String p. ex. tel:+1(111)999-9999	La value attribute fournit les coordonnées de la Contact Party's (p. ex. téléphone et adresse de courriel).
	use	[1..1]	Alpha	La valeur use attribute indique la connexion de télécommunication (p. ex. travail, privée) et est établie en fonction du vocabulaire normalisé de Santé Canada - 2.16.840.1.113883.2.20.6.4.
	capabilities	[1..1]	Alpha	La valeur capabilities attribute indique le service de télécommunication et est établie en fonction du vocabulaire normalisé de Santé Canada - 2.16.840.1.113883.2.20.6.19.
Éléments et/ou Attributs exclus	Les éléments et attributs de type de données suivants sont exclus : 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

[--] = aucune information n'est requise dans cette cellule.

6.6.2.2.2.3 Tableau 15 -callBackContact.contactParty.asAgent.representedOrganization.name

Élement	Attribut	Cardinalité	Exemples de valeur(s) autorisée(s)	Directives de Description
name.part	[--]	[1..1]	[--]	Il s'agit d'un container element qui permet d'organiser la valeur pour le represented Organization's name.
	value	[1..1]	String p. ex. Acme Pharmaceuticals	La value attribute fournit le nom de l'organisation.
Éléments et/ou Attributs exclus	Les éléments et attributs de type de données suivants sont exclus : name.part@code name.part@codeSystem name.part@codeSystemVersion name.part@language name.part@nullFlavor name.part@qualifier name.part@xsi:type

[--] = aucune information n'est requise dans cette cellule.

6.6.2.3 Éléments exclus

Les class attributes suivants sont exclus de la mise en œuvre de Santé Canada :

• contactPerson.id - Veuillez noter qu'il s'agit d'un identifiant additionnel de la personne désignée au lieu de son contactParty.id. Seul le contactParty.id est utilisé.

6.6.3 Sequence number

Le sequence number attribué par Santé Canada aura sa propre série, distincte de celle reçue par le promoteur (c'est-à-dire que les valeurs ne sont pas consécutives entre les deux parties). La série débutera par 1 et augmentera d'une unité chaque fois qu'un message de Santé Canada est envoyé au promoteur.

7.Transition Mapping Message de eCTD v3.2.2

La présente section fournit l'ensemble des détails spécifiques à Santé Canada relatifs au Transition Mapping Message (TMM).
Santé Canada n'autorise que la transition du contenu régional du module 1 régional actuel du schema - v2.2.

Message Header

Les renseignements relatifs au message header fournissent un ensemble d'éléments qui sont nécessaires pour mentionner l'expéditeur et le destinataire, ainsi que la version de l'ICH et des Regional/Module 1 Implementation Guides utilisés pour générer le message.

Tableau 16 - Le XML suivant indique les elements/attributes requis pour valider le message par rapport au schema

Structure XML

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

L'exemple XML suivant indique le contenu relatif à l'element de l'en-tête du message. Le receiver.device.id element renferme l'information relative aux versions du IG requise pour l'en-tête Transition Mapping Message XML :

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

Les éléments et attributs pertinents du v3.2.2 Transition Mapping Message ont été exposés dans le ICH eCTD v4.0 Implementation Guide et seulement de l’information exclusive à Santé Canada est présentée dans ce document.

7.2.1 Payload elements

La transition dépend de celle de l’aperçu actuel de l’application / dossier pour inclure le même positionnement d’en-tête et de mots-clés dans le format CTD. Reportez-vous au ICH eCTD v4.0 Implementation Guide pour obtenir de plus amples renseignements sur les exigences relatives au message de mise en correspondance transitoire.

7.2.1.1 Keywords in TMM

Il est important de noter que tous les keywords peuvent ne pas avoir existé en tant qu’attributs de l’ICH ou du fichier de base eCTD (soit les fichiers DTD). Par conséquent, il peut être nécessaire de devoir transférer les Keywords à partir d’emplacements multiples des messages eCTD v3.2.2.

• Les Keywords peuvent être transférés à partir des sources suivantes :
  • ICH Attributes
  • Le fichier STF comprend également les eCTD v4.0 keywords suivants.
    • Document Types (précisés auparavant comme l’élément file-tag)
    • Study-title (précisés auparavant comme l’élément du titre)
    • Study-id
    • Duration, Species, Route of Administration, and Type of Control (précisés auparavant comme le Category element)
    • Site-id (précisés auparavant comme l’élément de propriété)
  • Les ICH v3.2.2 Node Extensions devraient être transférées à eCTD v4.0 à l’aide d’une group title keyword definition
• La consolidation des Keywords à partir des attributs suivants :
  • Study Id et Study Title - suivez les directives contenues dans l’ICH eCTD v4.0 Implementation Guide pour fusionner les valeurs de ces deux attributes lorsqu’il faut effectuer une transition de la v3.2.2 à la v4.0.

7.2.1.2 Post-transition

Il faut observer les directives spéciales suivantes concernant les messages créés une fois que le Transition Mapping Message a été envoyé.

• Sequence number : il observe les mêmes directives fournies par l’ICH eCTD v4.0 Implementation Guide à moins que le cas de figure suivant se produise :
  • Après la réception du Transition Mapping Message, le sequence number doit continuer à être attribué séquentiellement sous forme de nombres entiers au lieu d’observer les directives de la v3.2.2 pour les valeurs à 4 chiffres précédées de zéros.