Lors de la dernière réunion de l'équipe centrale SEND du CDISC, nous avons discuté des données sur les anticorps anti-médicaments (ADA) et de leur représentation dans SEND. Nous avons débattu de ce que nous recommanderions, et c'est la cause de mon conflit.
Le puriste qui sommeille en moi a envie de crier "Domaine personnalisé". Le pragmatique sait que l'industrie n'est pas prête pour cela. J'ai envie de crier sur tous les toits que chez Instem, nous avons les outils et les services pour soutenir les domaines personnalisés ; mais je ne suis pas censé utiliser le CDISC pour une telle promotion. Je voudrais dire à tous ceux qui nous écoutent que nous disposons des produits et des services nécessaires pour aider l'industrie à créer ces domaines personnalisés, mais ce serait aller trop loin. Ainsi, en tant que membre à part entière de l'équipe CDISC SEND Core Team, je dois admettre que l'industrie n'en est tout simplement pas encore là.
Je suis donc partagé.
Cela s'explique par les travaux de la FDA CBER et leur récent projet pilote sur la norme SEND. Ils ont un réel besoin de voir l'ADA dans SEND. Dans la version actuelle de SEND, il n'y a pas de domaine pour ces résultats, mais SDTMIG (le guide de mise en œuvre de l'équivalent clinique de SEND) dispose d'un tel domaine. Il s'appelle IS - Immunogenicity Specimen Assessment (évaluation des échantillons d'immunogénicité), mais il ne figure pas dans le SENDIG.
PHUSE s'est déjà penché sur cette situation et a proposé deux solutions, qui peuvent être résumées en montrant comment soit intégrer de force les données ADA dans le domaine LB existant, soit emprunter IS à SDTMIG et l'ajouter à un paquet SEND en tant que domaine personnalisé. (Je ne rends probablement pas service à ses auteurs en réduisant un livre blanc entier à une seule phrase).
À ce stade, je reconnais mais j'élude complètement la question de savoir si cela serait considéré comme faisant partie du champ d'application ou non ; et j'esquive totalement les questions relatives à la compatibilité des versions de SDTM et au fait que CDISC ajoute un domaine IS à SEND 3.2. Si vous voulez vous plonger dans cette question, écrivez-moi à instem car je serais ravi d'entamer la discussion sur ce sujet particulier !
Je suis donc en conflit, et une grande partie de ce conflit est due au fait que j'aime être à la pointe de la SEND. La "bonne" réponse est que ces données étant importantes pour l'évaluation de la sécurité, elles devraient être représentées dans SEND. Dans ce cas, le domaine IS est mieux adapté qu'un domaine LB mal utilisé. Cependant, dans l'ensemble, l'industrie n'est pas à la pointe du progrès et, de ce fait, beaucoup ne disposent probablement pas des outils ou de l'expertise nécessaires. Cela n'est pas surprenant, car au CDISC, je pense que nous aurions pu faire un meilleur travail pour rendre les informations disponibles. Nous disposons d'un guide de mise en œuvre qui inclut les domaines personnalisés, mais qui n'agit à aucun moment pour guider la mise en œuvre d'un domaine personnalisé. Cela étant, je lève la main en tant que bénévole du CDISC et j'assume ma part de responsabilité à cet égard.
Être à la pointe signifie avoir déjà développé les outils et les services. Non seulement notre logiciel Submit™ crée et consomme de tels domaines, mais notre logiciel SEND Explorer peut les visualiser, et notre équipe de services peut les créer et les vérifier. Ainsi, nous sommes maintenant bien assis, avec nos canards tous alignés. Mais je sais que cela ne s'applique pas vraiment à beaucoup d'autres.
Je suis donc toujours en conflit.
Il ne s'agit pas de faire de l'autopromotion éhontée, de dire "regardez ce que nous pouvons faire" ; il s'agit de relever le défi personnel qui consiste à prendre mes responsabilités au sein du CDISC au sérieux et à m'assurer que je n'outrepasse pas ma position privilégiée d'avoir un siège à la table de la direction de SEND.
Jusqu'à la prochaine fois
