Ébauche de la ligne directrice...Ébauche de la ligne directrice guide de mise en œuvre technique...

É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 La présente ligne directrice est publiée dans le seul but de recueillir des commentaires.

Date de l’ébauche : 2019/06/26

Guide de mise en œuvre technique du module 1 canadien pour le format Electronic Common Technical

Document (eCTD) v4.0 | 2

Santé Canada a pour mandat d'aider les Canadiens à conserver et à améliorer leur santé. Il s'assure d'offrir des services de santé de grande qualité, et cherche à réduire les risques pour la santé.

Également disponible en français sous le titre : Draft Guidance Document: Canadian Module 1 Technical Implementation Guide for the Electronic Common Technical Document (eCTD) v4.0 Format

© Sa Majesté la Reine du chef du Canada, représentée par la ministre de la Santé, 2019 Date de publication : juin 2019

La présente publication peut être reproduite sans autorisation pour usage personnel ou interne seulement, dans la mesure où la source est indiquée en entier.



Avant‐propos

Les lignes directrices sont destinées à guider l’industrie et les professionnels de la santé de la façon de se conformer aux lois et aux règlements en vigueur. Les lignes directrices 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 pourraient ê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.

Corollairement à 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 la ligne directrice 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.

Le présent document devrait être lu en parallèle avec l’avis d’accompagnement et les sections pertinentes des autres lignes directrices qui s’appliquent.



Table des matières

Avis aux lecteurs ............................................................................................................................. 6 1

Instructions aux lecteurs ................................................................................................................. 6 2

Mise en correspondance de la terminologie réglementaire de Santé Canada .......................... 6 3 Tableau 1 : Correspondance avec la terminologie réglementaire de Santé Canada ............. 6 4

Contenu du document ................................................................................................................ 7 5 XML Snippets ............................................................................................................................... 7 6 Emplacement dans XML .............................................................................................................. 7 7

Tableau 2 : Emplacement de XML Notation ........................................................................... 7 8 Tableaux de XML Elements ......................................................................................................... 8 9

Tableau 3 ‐ Modèle de tableau de XML Element .................................................................... 8 10

1. Objet ............................................................................................................................................ 9 11

2. Portée .......................................................................................................................................... 9 12

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

3.1 Ressources citées en référence ........................................................................................... 10 14 3.2 Le message eCTD v4.0 XML schema .................................................................................... 11 15

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

4.1 Contenu d’une unité de présentation ................................................................................. 11 17 4.1.1 Contenu de la Submission unit des messages de promoteurs .................................... 11 18 4.1.2 Contenu de l’unité de présentation des messages de Santé Canada ......................... 12 19 4.1.3 Structure détaillée de dossier ...................................................................................... 12 20

4.2 Formats de fichier et conventions d’appellation ................................................................ 13 21 4.3 Hiérarchie des dossiers ....................................................................................................... 13 22

5. Vocabulaires normalisés ........................................................................................................... 13 23

5.1 Vocabulaires normalisés spécifiés par région ..................................................................... 14 24 Tableau 4 : Vocabulaires normalisés régionaux de Santé Canada ....................................... 14 25

5.2 Vocabulaires régionaux exclus ............................................................................................ 14 26

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

6.1 En‐tête de message de Santé Canada ................................................................................. 14 28 6.2 Payload message de Santé Canada ..................................................................................... 15 29

Tableau 5 : eCTD v4.0 XML Message Payload de Santé Canada .......................................... 16 30 6.2.1 Unité de présentation .................................................................................................. 22 31 6.2.2 Présentation ................................................................................................................. 22 32 6.2.2.1 XML elements ........................................................................................................... 22 33 6.2.2.1.1 Tableau 6 ‐ Submission.id ...................................................................................... 23 34 6.2.2.1.2 Tableau 7 ‐ Submission.code ................................................................................. 24 35 6.2.3 Application ................................................................................................................... 24 36 6.2.3.1. XML elements .......................................................................................................... 25 37



6.2.3.1.1 Tableau 8 ‐ application.id ....................................................................................... 26 38 6.2.3.1.2 Tableau 9 ‐ application.code .................................................................................. 27 39 6.2.3.2 Exemples de XML ...................................................................................................... 28 40

6.3 Élaboration du message ...................................................................................................... 28 41 6.3.1 Réutilisation d’un fichier .............................................................................................. 28 42 6.3.2 Utilisation d’un type de média ..................................................................................... 29 43

6.4 Présentations groupées....................................................................................................... 29 44 6.5 Retrait de contenu relatif à la présentation ........................................................................ 29 45 6.6 Messages de Santé Canada : une communication bidirectionnelle ................................... 29 46

6.6.1 Contenu des messages ................................................................................................. 29 47 6.6.2 Contact party ............................................................................................................... 30 48 6.6.2.1 Emplacement dans XML ........................................................................................... 30 49 6.6.2.2 XML elements ........................................................................................................... 30 50 6.6.2.2.1 Contact party ......................................................................................................... 30 51 6.6.2.2.1.1 Tableau 10 ‐ callBackContact.contactParty.id .................................................... 30 52 6.6.2.2.1.2 Tableau 11 ‐ callBackContact.contactParty.code ............................................... 31 53 6.6.2.2.1.3 Tableau 12 ‐ callBackContact.contactParty.statusCode ..................................... 32 54 6.6.2.2.2 Personne‐ressource ............................................................................................... 33 55 6.6.2.2.2.1 Tableau 13 ‐ callBackContact.contactParty.contactPerson.name ...................... 33 56 6.6.2.2.2.2 Tableau 14 ‐ callBackContact.contactParty.contactPerson.telecom .................. 34 57 6.6.2.2.2.3 Tableau 15 ‐ 58 callBackContact.contactParty.asAgent.representedOrganization.name ............................. 35 59 6.6.2.3 Éléments exclus ......................................................................................................... 35 60 6.6.3 Sequence number ........................................................................................................ 35 61

7. Transition Mapping Message de eCTD v3.2.2 .......................................................................... 35 62

7.1 Message Header .................................................................................................................. 36 63 Tableau 16 ‐ Le XML suivant indique les elements/attributes requis pour valider le message 64 par rapport au schema .......................................................................................................... 36 65

7.2 Payload message ................................................................................................................. 37 66 7.2.1 Payload elements ......................................................................................................... 37 67 7.2.1.1 Keywords in TMM ..................................................................................................... 37 68 7.2.1.2 Post‐transition ........................................................................................................... 38 69



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 70

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

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

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 82 messages eCTD v4.0 diffèrent du vocabulaire réglementaire généralement utilisé à Santé 83 Canada. Pour éviter toute confusion et établir une compréhension commune en matière de 84 communication réglementaire, le tableau de correspondance terminologique suivant a été 85 produit. 86

Tableau 1 : Correspondance avec la terminologie réglementaire de Santé Canada 87 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 88

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

Composants XML 93 o Le texte narratif du document est soit en gras, soit en italique, soit en langage caml, 94

p. ex. contextOfUse. 95 o Les exemples XML sont indiqués dans la section XML Snippets ci‐dessous. 96

Concepts qui ne font pas référence à la norme et/ou au message. 97 o Un concept défini, p. ex., Context of Use, est noté en texte simple avec la première 98

lettre des mots débutant par une majuscule. 99

XML Snippets 100

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

La notation de <!‐‐....notes….‐‐ > a été utilisée pour décrire les conditions d’un élément qui 102

doivent être observées. 103

La notation … [Description] … a été utilisée pour indiquer lorsqu’il y avait des éléments 104

additionnels qui n’étaient pas représentés dans la notation XML, mais qui pouvaient être 105

présents dans le message XML. 106

Emplacement dans XML 107

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

Tableau 2 : Emplacement de XML Notation 110

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 111 exemple XML. 112

controlActProcess>>subject>>submissionUnit>>component>>priorityNumber> contextOfUse 113

Emplacement d’Element’s dans la description XML 114

<controlActProcess classCode="ACTN" moodCode="EVN"> 115 <subject typeCode="SUBJ"> 116 <submissionUnit> 117 <component> 118 <priorityNumber value="1000"/> 119 <contextOfUse> 120



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

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

Tableaux de XML Elements 128

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

Tableau 3 ‐ Modèle de tableau de XML Element 133

Nom du tableau : <element>.<element 2> 134

Élément Attribut Cardinalité Exemples de

valeurs 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 l’attribut]




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 135 format XML (soit <element>.<element 2>). Par exemple, si l’Application element possède un 136 element pour l’identifiant, celui‐ci serait représenté par : application.id. 137



Element: Identifie le XML element. 138

Attribute: Identifie le XML attribute. 139

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

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

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

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

1. Objet 149

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

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

2. Portée 162

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

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



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

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

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

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

1. Les documents cités en référence (des renseignements détaillés se trouvent à la Section 3.1) 183 2. Le XML Schema et message (des renseignements détaillés se trouvent à la Section 3.2) 184 3. Contenu relatif à la présentation, structure des répertoires et fichiers (des renseignements 185

détaillés se trouvent à la Section 4) 186 4. Des vocabulaires normalisés (des renseignements détaillés se trouvent à la Section 3.1) 187 5. Message eCTD V4.0 XML pour Santé Canada y compris les éléments spécifiques à Santé 188

Canada (des renseignements détaillés se trouvent à la Section 6. 189 6. Compatibilité avec la v3.2.2 et référence à celle‐ci (des renseignements détaillés se trouvent 190

à la Section 7) 191 7. Règles en matière de validation (les renseignements relatifs aux documents cités en 192

référence se trouvent à la Section 3.1) 193

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

Remarque : Citez en référence le site Web de l’ICH (http://www.ich.org/products/electronic‐197 standards.html) pour obtenir une liste complète des documents de la trousse de mise en œuvre 198 de l’ICH eCTD v4.0 et le site Web de Santé Canada pour obtenir une liste complète des 199 composants du message eCTD v4.0 du module 1 de Santé Canada. 200

3.1 Ressources citées en référence 201

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

ICH eCTD v4.0 Implementation Package 204

ICH Specification for Submission Format for eCTD 205

Préparation des activités de réglementation en format eCTD pour Santé Canada 206

Registre du vocabulaire normalisé 207

Règles de validation des transactions réglementaires envoyées à Santé Canada en format 208 electronic Common Technical Document (eCTD v4.0) 209



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

3.2 Le message eCTD v4.0 XML schema 214

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

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

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

4.1 Contenu d’une unité de présentation 223

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

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

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

4.1.1 Contenu de la Submission unit des messages de promoteurs 235

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



Figure 1 : Unité de présentation du promoteur 239

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

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

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

Figure 2 : Unité des présentations de Santé Canada 249

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

4.1.3 Structure détaillée de dossier 254

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

Dossier de tête

Dossier du numéro de



Figure 3 : Structure détaillée de répertoire 259

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

4.2 Formats de fichier et conventions d’appellation 265

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

4.3 Hiérarchie des dossiers 268

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

5. Vocabulaires normalisés 273

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



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

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

Tableau 4 : Vocabulaires normalisés régionaux de Santé Canada 280

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 281

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

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

6.1 En‐tête de message de Santé Canada 287

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



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

<id/> 294 <creationTime/> 295 <interactionId/> 296 <processingCode/> 297 <processingModeCode/> 298 <acceptAckCode/> 299 <receiver typeCode="RCV"> 300 <device classCode="DEV" determinerCode="INSTANCE"> 301 <id> 302

<item root="2.16.840.1.113883.3.989.2.2.1.11.1" identifierName="ICH eCTD 303 v4.0 IG v1.2"/> 304

</id> 305 </device> 306 </receiver> 307 <sender typeCode="SND"> 308 <device classCode="DEV" determinerCode="INSTANCE"> 309 <id/> 310 </device> 311 </sender> 312

6.2 Payload message de Santé Canada 313

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



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

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 o primaryInformationRecipient.TerritorialAuthority o replacementOf.relatedContextOfUse o derivedFrom.documentReference o subjectOf.submissionReference o 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/> </relatedContextOfUse> </replacementOf> <derivedFrom> <documentReference> <id/> </documentReference> </derivedFrom> <subjectOf negationInd=""> <submissionReference> <id><item/></id> </submissionReference> </subjectOf> <referencedBy typeCode="REFR"> <keyword> <code/> </keyword> </referencedBy> </contextOfUse> </component>

submissionReference – Exclus de la mise en œuvre de Santé Canada eCTDv4.0

statusCode – Exclus de la mise en œuvre de Santé Canada eCTDv4.0

title – Exclus de la mise en œuvre de Santé Canada eCTDv4.0

primaryInformationRecipient – Exclus de la mise en œuvre de Santé Canada eCTDv4.0

negationInd – Exclus de la mise en œuvre de Santé Canada eCTDv4.0



regulatoryStatus – Exclus de la mise en œuvre de Santé Canada eCTDv4.0

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 o subject1.manufacturedProduct o holder.applicant o author.territorialAuthority o subject2.productCategory o 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>

callBackContact – Messages exclus de eCTD v4.0 envoyés à Santé Canada ‐ Sera inclus dans la communication bidirectionnelle de Santé Canada (voir la section 6.6) ‐ Consultez le Guide de mise en œuvre de ICH eCTD v4.0 pour la cartographie de la transition.



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

mode – Exclus de la mise en œuvre de Santé Canada eCTDv4.0

regulatoryReviewTime – Exclus de la mise en œuvre de Santé Canada eCTDv4.0

submissionGroup Exclus de la mise en œuvre de Santé Canada eCTDv4.0

review (and all child elements) – Exclus de la mise en œuvre de Santé Canada eCTDv4.0

review (and all child elements) – Exclus de la mise en œuvre de Santé Canada eCTDv4.0



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>

holder – Exclus de la mise en œuvre de Santé Canada eCTDv4.0

informationRecipient.territorialAuthority – Exclus de la mise en œuvre de Santé Canada eCTDv4.0

reviewProcedure – Exclus de la mise en œuvre de Santé Canada eCTDv4.0

applicationReference – Exclus de la mise en œuvre de Santé Canada eCTDv4.0



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

subject.categoryEvent ‐ Exclus de la mise en œuvre de Santé Canada eCTDv4.0

keyword under document – Exclus de la mise en œuvre de Santé Canada eCTDv4.0



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

6.2.1 Unité de présentation 325

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

Les conditions suivantes s’appliquent à la submissionUnit : 330

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

6.2.2 Présentation 332

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

6.2.2.1 XML elements 336

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



6.2.2.1.1 Tableau 6 ‐ Submission.id

Élément Attribut Cardinalité Exemples de valeurs

autorisées


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)


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



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


6.2.3 Application 339

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

Remarque : Le concept d’application se trouve également dans les Modules 2 à 5, qui 345 sera d’ailleurs traité dans le Guide de mise en œuvre de l’ICH eCTD v4.0. De plus amples 346



renseignements sur les caractéristiques régionales sont fournis dans le présent 347 document. 348

6.2.3.1. XML elements 349

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

Un application element est nécessaire pour obtenir un seul et unique id.item@root. 351



6.2.3.1.1 Tableau 8 ‐ application.id 352

Élément Attribut Cardinalité Exemples de

valeur(s) autorisée(s)


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.



id.item@identifierName

id.item@scope

id.item@reliability

id.item@displayable

id@validTimeLow

id@validTimeHigh



id@nullFlavor

id@flavorId

id@updateMode




6.2.3.1.2 Tableau 9 ‐ application.code 353


autorisée(s)


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.



code.displayName

code.originalText

code.translation

code.source

code@codeSystemName





code@flavorId

code@id

code@nullFlavor

code@updateMode

code@validTimeHigh

code@validTimeLow

code@valueSet


code@xsiType

[‐‐] = aucune information n’est requise dans cette cellule. 354



6.2.3.2 Exemples de XML 355

Voici un exemple de XML pour les détails relatifs à l’application. L’application est saisie comme 356 un componentOf element entre submission et application. 357

<componentOf> 358 <application> 359 <id> 360

<item root="7227d769‐6ac4‐460c‐bb1d‐387a37ac9d2e" 361 extension="e123456"/> 362

</id> 363 <code code="ca_application_type_1" 364 codeSystem="2.16.840.1.113883.2.20.6.11"/> 365

6.3 Élaboration du message 366

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

6.3.1 Réutilisation d’un fichier 371

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

<component> 377 <document> 378 <id root="1f44364a‐2575‐4d4e‐b4ab‐dfdf7c0d124b"/> 379 <title value="File Reused from Dossier#e123456"/> 380 <text integrityCheckAlgorithm="SHA256"> 381 <reference value="../../e123456/9999/m1/content.pdf"/> 382

<integrityCheck>026C76D4E3AD972DD01A6A4090D1F61A213BD26383 DF648173A75AE451430C0FB39</integrityCheck> 384

</text> 385 </document> 386 </component> 387

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

Le text.reference@value du fichier doit comprendre : 391

Chemin d’accès relatif 392

La partie du nom du répertoire de tête de l’identifiant de répertoire nommé. 393



Sequence Number pour l’unité de présentation dans laquelle le fichier a été soumis à 394 l’origine. 395

Le reste du chemin d’accès devra être inclus et repris intégralement au moment de la 396 transmission de l’unité de présentation à Santé Canada (soit “m1/content.pdf”). 397

<reference value="../../e123456/1/m1/content.pdf"/> 398

En ce qui concerne la réutilisation d’un fichier, le text element devrait comprendre les valeurs 399 reference@value, text@IntegrityCheckAlgorithm et text.integrityCheck des document element 400 envoyés auparavant. 401

6.3.2 Utilisation d’un type de média 402

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

<text integrityCheckAlgorithm="SHA256" mediaType="ca_media_type_1"> 408

6.4 Présentations groupées 409

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

6.5 Retrait de contenu relatif à la présentation 413

Si une unité de présentation doit être retirée, une nouvelle submission unit doit être soumise et 414 l’ensemble des the Context of Use elements doivent être soit interrompus (c.‐à‐d., ils paraîtront 415 comme étant inactifs), soit une fonction de remplacement doit être fournie pour restituer le 416 document antérieur comme étant le contenu de la current submission / regulatory activity. 417

Remarque : Reportez‐vous à l’ICH eCTD v4.0 Implementation Guide pour obtenir plus de 418 détails relatifs aux opérations d’interruption et de remplacement au sujet du Context of 419 Use. 420

6.6 Messages de Santé Canada : une communication bidirectionnelle 421

6.6.1 Contenu des messages 422

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



6.6.2 Contact party 430

6.6.2.1 Emplacement dans XML 431

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

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

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

6.6.2.2 XML elements 436

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

6.6.2.2.1 Contact party 439

6.6.2.2.1.1 Tableau 10 ‐ callBackContact.contactParty.id


autorisée(s)


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.



id@extension

id@identifierName

id@scope

id@reliability

id@displayable

id@validTimeLow

id@validTimeHigh



id@nullFlavor

id@flavorId id@updateMode




6.6.2.2.1.2 Tableau 11 ‐ callBackContact.contactParty.code 441


autorisée(s)


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



code.displayName

code.originalText

code.translation

code.source

code@codeSystemName





code@flavorId

code@id

code@nullFlavor

code@updateMode

code@validTimeHigh

code@validTimeLow

code@valueSet


code@xsiType




6.6.2.2.1.3 Tableau 12 ‐ callBackContact.contactParty.statusCode 442


autorisée(s)


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


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




6.6.2.2.2 Personne‐ressource 444

6.6.2.2.2.1 Tableau 13 ‐ callBackContact.contactParty.contactPerson.name 445


autorisée(s)


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


name.part@code

name.part@codeSystem

name.part@codeSystemVersion

name.part@language

name.part@nullFlavor name.part@xsi:type




6.6.2.2.2.2 Tableau 14 ‐ callBackContact.contactParty.contactPerson.telecom 447

Remarque : Le xsi:type pour le telecom attribute doit être énuméré dans une liste non 448 ordonnée ou « BAG_TEL ». 449


autorisée(s)


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

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



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




6.6.2.2.2.3 Tableau 15 ‐ callBackContact.contactParty.asAgent.representedOrganization.name 451


autorisée(s)


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.



name.part@code

name.part@codeSystem

name.part@codeSystemVersion

name.part@language

name.part@nullFlavor

name.part@qualifier name.part@xsi:type


6.6.2.3 Éléments exclus 453

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

contactPerson.id – Veuillez noter qu’il s’agit d’un identifiant additionnel de la personne 455 désignée au lieu de son contactParty.id. Seul le contactParty.id est utilisé. 456

6.6.3 Sequence number 457

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

7. Transition Mapping Message de eCTD v3.2.2 462

La présente section fournit l’ensemble des détails spécifiques à Santé Canada relatifs au 463 Transition Mapping Message (TMM). 464

Santé Canada n’autorise que la transition du contenu régional du module 1 régional actuel du 465 schema ‐ v2.2. 466



7.1 Message Header 467

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

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

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>

Ces éléments doivent être représentés avec des balises à fermeture



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

<id/> 476 <creationTime/> 477 <interactionId/> 478 <processingCode/> 479 <processingModeCode/> 480 <acceptAckCode/> 481 <receiver typeCode="RCV"> 482 <device classCode="DEV" determinerCode="INSTANCE"> 483 <id> 484

<item root="2.16.840.1.113883.3.989.2.2.1.11.1" identifierName="ICH eCTD 485 v4.0 IG v1.2"/> 486

</id> 487 </device> 488 </receiver> 489 <sender typeCode="SND"> 490 <device classCode="DEV" determinerCode="INSTANCE"> 491 <id/> 492 </device> 493 </sender> 494

7.2 Payload message 495

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

7.2.1 Payload elements 499

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

7.2.1.1 Keywords in TMM 504

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

Les Keywords peuvent être transférés à partir des sources suivantes : 509 o ICH Attributes 510 o Le fichier STF comprend également les eCTD v4.0 keywords suivants. 511

Document Types (précisés auparavant comme l’élément file‐tag) 512 Study‐title (précisés auparavant comme l’élément du titre) 513 Study‐id 514



Duration, Species, Route of Administration, and Type of Control (précisés 515 auparavant comme le Category element) 516

Site‐id (précisés auparavant comme l’élément de propriété) 517 o Les ICH v3.2.2 Node Extensions devraient être transférées à eCTD v4.0 à l’aide 518

d’une group title keyword definition 519

La consolidation des Keywords à partir des attributs suivants : 520 o Study Id et Study Title ‐ suivez les directives contenues dans l’ICH eCTD v4.0 521

Implementation Guide pour fusionner les valeurs de ces deux attributes lorsqu’il 522 faut effectuer une transition de la v3.2.2 à la v4.0. 523

7.2.1.2 Post‐transition 524

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

Sequence number : il observe les mêmes directives fournies par l’ICH eCTD v4.0 527 Implementation Guide à moins que le cas de figure suivant se produise : 528

o Après la réception du Transition Mapping Message, le sequence number doit 529 continuer à être attribué séquentiellement sous forme de nombres entiers au 530 lieu d’observer les directives de la v3.2.2 pour les valeurs à 4 chiffres précédées 531 de zéros. 532

Ébauche de la ligne directrice...Ébauche de la ligne directrice guide de mise en œuvre technique...

Documents