É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

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 :

XML Snippets

Les règles suivantes ont été observées pour l'élaboration des exemples 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.

Emplacement d'Element's dans la description XML

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 :

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 :

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 : Unité de présentation du promoteur
fig1
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.

2 : Unité des présentations de Santé Canada
fig2
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.

Figure 3 : Structure détaillée de répertoire
fig3
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.

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 :

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.

title
Exclus de la mise en œuvre de Santé Canada eCTDv4.0
statusCode
Exclus de la mise en œuvre de Santé Canada
primaryInformationRecipient
Exclus de la mise en œuvre de Santé Canada eCTDv4.0
negationInd
Exclus de la mise en œuvre de Santé Canada eCTDv4.0
submissionReference
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 :

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

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 :

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
keyword under document
Exclus de la mise en œuvre de Santé Canada eCTDv4.0

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

subject.categoryEvent
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 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 :

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 :

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.

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.

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 :

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

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/> et <receiver>
Ces éléments doivent être représentés avec des balises à fermeture automatique, comme illustré ici. Si oui, indiquez que ces éléments doivent être vides

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 :

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.

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

Signaler un problème ou une erreur sur cette page
Veuillez sélectionner toutes les cases qui s'appliquent :

Merci de votre aide!

Vous ne recevrez pas de réponse. Pour toute question, contactez-nous.

Date de modification :