Pour le billet de blog de cette semaine, j'ai pensé qu'il serait bon de discuter de l'utilisation actuelle du fichier define.xml dans l'industrie non clinique. J'ai donc demandé à Charuta Bapat d'en discuter avec nous, car son enthousiasme pour le Define-XML est à la limite de la contagion. Charuta travaille à mes côtés et est responsable de nos outils define. Elle est également membre de l'équipe CDISC nonclinical define. Voici son point de vue sur le sujet :
Certaines personnes sont passionnées par la musique, d'autres par l'art, d'autres encore par la nature, et dans notre monde préclinique, il y a beaucoup d'accros à SEND. J'aime travailler avec SEND, mais depuis que je suis entré dans l'industrie réglementaire, mon cœur s'est fixé sur Define-XML. Oui, vous avez bien lu ! Je fais partie de ces rares spécimens qui sont enthousiasmés par le define.xml et qui croient fermement en la valeur de la création de bons fichiers de définition.
Imaginez que vous êtes dans un restaurant et que vous regardez le menu - le menu a une belle couverture avec des couleurs attrayantes. En l'ouvrant, vous vous attendez à voir la liste de vos plats préférés et leur prix. Mais en y regardant de plus près, vous constatez que le menu n'a aucun sens. Il y a des fautes d'orthographe, la description n'est pas lisible, les entrées sont mélangées avec les desserts et vous ne pouvez pas comprendre la liste des prix. Comment vous sentez-vous ? Commenceriez-vous à douter de la qualité de la nourriture ? Préféreriez-vous aller dans un autre restaurant ? Seriez-vous frustré de devoir poser une série de questions au serveur ? Je suppose que les évaluateurs de la réglementation ressentent la même chose lorsqu'ils reçoivent un fichier define mal structuré. define.xml - tout comme mon analogie avec le menu, la façon dont le fichier est présenté a un impact sur la première impression de l'évaluateur. Il s'agit en fait d'une table des matières pour votre étude, très utile pour décrire la structure et le contenu des données soumises.
Bien que Define-XML fasse partie du paysage de la soumission de données depuis plus de dix ans, il est évident que l'industrie non clinique a encore du mal à s'y retrouver. Il s'agit d'un élément de soumission négligé ou inquiétant sur lequel les autorités réglementaires n'ont pas été transparentes en ce qui concerne leurs attentes. Malheureusement, de nombreuses organisations traitent define.xml comme une tâche ménagère.
En conséquence, beaucoup choisissent d'adopter une approche qui leur convient, certains n'y accordent pas beaucoup d'importance, d'autres submit fichiers par défaut générés par le système, et d'autres encore ne comprennent pas la spécification. Mais j'ai aussi vu des personnes qui se donnent beaucoup de mal pour créer de très bons fichiers de définition. Bien entendu, ce sont eux qui en retirent les avantages qu'ils méritent : leur examen réglementaire se déroule beaucoup plus facilement que celui des autres.
Tout le monde pense que la spécification Define-XML est assez technique par nature et c'est vrai, mais je pense qu'elle offre aussi un avantage - elle apporte discipline et homogénéité. Elle peut non seulement être consommée par le logiciel, mais aussi être lue manuellement. Elle crée un cadre dans l'esprit du réviseur ainsi que dans le logiciel pour recevoir les données réelles.
À mon avis, le define.xml a un potentiel énorme et nous devons tous collaborer avec le CDISC et les autorités réglementaires pour l'utiliser au mieux et dévoiler ses véritables capacités. Tout ce dont nous avons besoin, c'est d'un bon état d'esprit et d'outils efficaces. Nous pourrions transformer cette tâche ménagère autrefois laborieuse en un élément clé de données précieuses pour les paquets SEND. Je sais que je ne cesserai jamais de parler de la définition. Si vous souhaitez en savoir plus sur l'amélioration des fichiers define ou discuter des réactions de la FDA à ce sujet, contactez-moi - j'en serais ravie !
Charuta
