Suffit-il que le fichier XML s’ouvre pour une notification SUSAR ?

Non. L’annexe 2 de KAD-KLVZ-07 distingue le schéma technique, les règles des champs, les règles de contenu ICH et les contrôles TİTCK comme des étapes séparées.

Cet article couvre-t-il aussi les notifications de sécurité des dispositifs médicaux ?

Non. La source examinée porte sur les essais de médicaments à usage humain. Pour les dispositifs, la procédure officielle correspondant à l’investigation et au produit doit être étudiée séparément.

L’affichage du statut d’un fichier dans le portail prouve-t-il que la notification officielle est terminée ?

Pas à lui seul. Il faut distinguer le statut interne de la tâche des enregistrements et résultats de la procédure officielle ; la clôture doit reposer sur la preuve correspondante.

SUSAR TİTCK 2026 : guide XML E2B(R3)

Image de couverture: Notifications SUSAR à la TİTCK en 2026 : XML E2B(R3) et liste de contrôle opérationnelle — Photo: Stephane Lesbats / IFREMER · Licence: CC BY 4.0 · Image recadrée et redimensionnée.

Publication: 27 octobre 2026
Mise à jour: 27 octobre 2026
Sources vérifiées: 27 octobre 2026

Dans le reporting de sécurité, produire le fichier, terminer l’évaluation médicale et suivre la notification sont des tâches différentes. L’achèvement de l’une ne prouve pas celui des autres. Pour organiser les notifications SUSAR en Turquie, il faut traiter ensemble responsabilité d’évaluation, calendrier, qualité des messages électroniques et suivi. Cet article transforme les sources de 2026 relatives aux essais de médicaments à usage humain en un plan d’équipe applicable.

Module national SUSAR et portée de la mise à jour de 2026

L’annonce TİTCK du 20 mai 2026 explique qu’un module national SUSAR a été développé au sein du module des essais cliniques. Elle indique le 15 mai 2026 comme début de publication et d’application des guides concernés. KAD-KLVZ-07 a été examiné dans sa révision 13. Ces dates sont distinctes de la publication de cet article, le 27 octobre 2026.

Ne confiez pas l’évaluation de transition uniquement à l’équipe informatique. Pharmacovigilance, évaluation médicale, affaires réglementaires et opérations cliniques devraient examiner le même cas type selon leurs responsabilités. Il s’agit de démontrer le bon fonctionnement des relais internes, au-delà du simple contrôle d’ouverture d’un écran.

Associer le délai de notification au bon événement et au bon responsable

L’article 6.20 de KAD-KLVZ-07 prévoit au plus sept jours à compter de la réception de l’information par le promoteur pour un SUSAR fatal ou mettant en jeu le pronostic vital ; pour les autres SUSAR, au plus quinze jours après la première connaissance. La règle de vingt-quatre heures concernant le signalement des événements indésirables graves par l’investigateur relève de l’article 6.17, avec l’exception prévue au protocole.

Nous recommandons de distinguer la prise de connaissance, le transfert pour évaluation et l’enregistrement de transmission plutôt que de n’avoir qu’une colonne « échéance ». Prévoyez aussi un suppléant pour chaque tâche. Cette traçabilité n’automatise pas la classification médicale ; elle permet de savoir quelle information est parvenue à qui et quand. Le calcul du délai doit être confirmé selon la disposition applicable à l’essai.

La validation XML E2B(R3) ne se limite pas au format

L’article 6.23.1 de KAD-KLVZ-07 décrit la notification individuelle XML E2B(R3) des SUSAR concernés survenus en Turquie. L’annexe 2 distingue conformité XSD, champs obligatoires et règles de répétition, règles métier ICH et contrôles complémentaires TİTCK. Un fichier XML techniquement lisible n’a donc pas nécessairement satisfait à tous les contrôles de contenu.

Transformez le journal d’erreurs en tâche résoluble : champ concerné, erreur observée, responsable de correction attendu et résultat de la nouvelle vérification. Au lieu de clore des erreurs similaires par des renvois répétés, examinez la correspondance dans le système source. Pour tester les cas types, préférez des données fictives contrôlées aux informations de vrais participants.

Lire la norme internationale avec les règles métier locales

Le module de formation III ICH E2B(R3) de janvier 2026 souligne l’importance des guides régionaux d’implémentation en complément de la norme commune. Envoi, réception, accusés de réception et indisponibilité du système sont des sujets de mise en œuvre distincts. Un message adapté à un pays ne répond pas automatiquement à toutes les attentes locales d’un autre.

Dans un travail d’adaptation pratique, commencez par établir les correspondances des champs dans le système source. Définissez ensuite les contrôles propres à la Turquie, le traitement des champs manquants et les scénarios à retester lors d’un changement de version. Considérer ce travail comme une simple conversion ponctuelle de fichier rend plus difficile l’identification des impacts des mises à jour ultérieures.

Maîtriser l’outil d’envoi et ses modifications

Le guide EMA sur les systèmes informatisés dans les essais cliniques aborde les comptes individuels, les accès adaptés aux fonctions, la traçabilité des modifications et la validation pour l’usage prévu. Il sert ici de référence internationale pour évaluer la conception qualité d’un système multinational de reporting, et non à ajouter une nouvelle règle de soumission en Turquie.

Dans cette perspective, consignez la version du logiciel qui génère ou modifie les messages. Si une correspondance de champ ou une règle de contrôle change, réévaluez les scénarios concernés. Réexaminez les accès lors des mouvements de personnel ; évitez que des notifications ouvertes restent sans responsable à l’occasion d’un transfert de tâches.

Regrouper les suivis autour de l’identifiant du cas

Désigner un même cas différemment selon les équipes complique la recherche du dossier et l’évaluation du statut. L’enregistrement opérationnel proposé réunit l’identifiant interne du cas, l’essai concerné, le responsable et l’action de suivi. Il ne modifie pas l’évaluation clinique ; il structure la communication entre équipes.

Définissez dès le départ la preuve requise pour clore une action. Un problème de transmission, une demande d’information manquante et une évaluation médicale en attente ne devraient pas partager le même statut. Un indicateur vert dans la vue de direction ne masquera alors pas une dépendance non résolue. L’analyse d’un retard pourra montrer à quelle étape le processus s’est bloqué plutôt que de rechercher seulement une faute individuelle.

Liste de contrôle applicable à la préparation de l’équipe

Les responsables et suppléants de l’évaluation, de la production technique du fichier et de la soumission sont-ils identifiés ?
La prise de connaissance et les transferts peuvent-ils être suivis à partir du même événement ?
Les exemples fictifs ont-ils été testés en fonctionnement normal et avec des champs erronés ?
Le responsable de résolution et le résultat de la réévaluation sont-ils consignés pour chaque erreur ?
Les consignes officielles actuelles et le canal d’assistance en cas d’indisponibilité sont-ils accessibles ?
Le nouveau responsable accepte-t-il les suivis ouverts lors du transfert d’équipe ?

Questions fréquentes

Suffit-il que le fichier XML s’ouvre pour une notification SUSAR ?: Non. L’annexe 2 de KAD-KLVZ-07 distingue le schéma technique, les règles des champs, les règles de contenu ICH et les contrôles TİTCK comme des étapes séparées.
Cet article couvre-t-il aussi les notifications de sécurité des dispositifs médicaux ?: Non. La source examinée porte sur les essais de médicaments à usage humain. Pour les dispositifs, la procédure officielle correspondant à l’investigation et au produit doit être étudiée séparément.
L’affichage du statut d’un fichier dans le portail prouve-t-il que la notification officielle est terminée ?: Pas à lui seul. Il faut distinguer le statut interne de la tâche des enregistrements et résultats de la procédure officielle ; la clôture doit reposer sur la preuve correspondante.