Comme vous le savez probablement, Instem a récemment acquis PDS Life Sciences et j'ai donc travaillé en étroite collaboration avec mon nouveau collègue, Mike Wasko. Mike est une figure éminente de notre industrie et cette semaine, alors que nous rattrapions le temps perdu, nous avons commencé à discuter de la question : Quelle est la relation entre le fichier d'étiquetage des études eCTD (STF) et les ensembles de données SEND et l'impact sur les critères techniques de rejet (CTR) ? Comme il s'agit d'un domaine qui prête à confusion et peut conduire à un rejet technique automatisé de la soumission, j'ai demandé à Mike de rédiger ses réflexions afin de les partager sur ce blog. Voici ce qu'il avait à dire :
Comme indiqué dans le guide de conformité technique (TCG), le CRT et le guide eCTD, l'identifiant de l'étude utilisé dans le STF doit correspondre à la valeur STUDYID ou SPREFID (Sponsor's Reference ID) dans le domaine TS. En outre, cet identifiant d'étude doit être présent dans le fichier define.xml dans l'élément StudyName. Ce lien est clairement compris ; cependant, savoir quel identifiant d'étude le sponsor utilisera dans le STF est une autre histoire.
En général, la conduite de l'étude et la création ultérieure de l'ensemble de données SEND sont gérées par le directeur de l'étude et une équipe SEND. Que l'équipe SEND soit interne à l'ORC ou externe, elle n'a généralement que peu ou pas de contact avec l'équipe chargée de la soumission qui crée le STF.
Maintenant que le CRT de la FDA est en vigueur (15 septembre 2021), la connexion entre les ensembles de données SEND et le STF est devenue essentielle et la communication concernant l'identifiant de l'étude dans le STF doit s'adapter. Dans l'idéal, l'équipe qui crée l'ensemble de données SEND et le fichier define.xml associé sera informée de l'identifiant d'étude à utiliser dans le STF.
On pourrait penser que l'identifiant de l'étude est évident, mais ce n'est pas toujours le cas. Cette situation, associée au fait que le STF est généralement créé après que les ensembles de données SEND ont été complétés, crée un problème unique. Pour les études menées par des CRO, une étude peut avoir plusieurs identifiants différents, l'identifiant de l'étude du promoteur, l'identifiant de l'étude du CRO, un numéro de rapport ou même quelque chose d'autre. Dans cette situation, il est difficile pour l'équipe SEND de déterminer quel identifiant sera utilisé dans le STF, et il ne faut pas oublier que des hypothèses erronées entraîneront un rejet technique.
Même si un seul numéro d'étude est utilisé dans le rapport et l'ensemble de données SEND, un autre cas d'utilisation peut poser problème. L'eCTD et le STF limitent le type de caractères pouvant être utilisés en raison de la structure des dossiers. Les caractères spéciaux tels que "/", "\", "." et autres ne doivent pas être utilisés. Si le rapport d'étude et le protocole utilisent de tels caractères pour le numéro de l'étude, comment cela sera-t-il représenté dans le STF ? Le caractère a-t-il été simplement supprimé ? Le caractère a-t-il été remplacé par un caractère acceptable tel que "_" ou "-" ?
Pour les soumissions qui ont lieu peu de temps avant la création d'un ensemble de données SEND, une communication proactive de la part de l'équipe chargée de la soumission peut permettre de résoudre le problème. Cependant, il faut tenir compte du fait que les ensembles de données SEND peuvent rester en suspens pendant des années avant d'être soumis, par exemple dans le cadre d'un accord de confidentialité. Le personnel peut avoir changé ou l'accord n'a peut-être pas été bien documenté. Le promoteur doit maintenant s'assurer que le STF et le STUDYID ou le SPREFID sont alignés. Si ce n'est pas le cas, les fichiers ts.xpt et define.xml devront être mis à jour en conséquence. Actuellement, nous n'avons pas connaissance de validateurs qui effectuent cette vérification automatiquement. Les commanditaires devront donc également savoir où regarder dans les fichiers define.xml et ts.xpt pour s'assurer que l'identifiant de l'étude spécifié dans le STF correspond à l'ensemble de données et au fichier define.xml. Au fil du temps, il semble que de plus en plus de personnes devront être sensibilisées à la SEND, car il ne s'agit plus d'une responsabilité strictement réservée à l'équipe SEND et au directeur de l'étude.
J'ai trouvé que c'était une excellente explication de la part de Mike, et vous pouvez vous attendre à ce que je lui demande d'autres contributions à mesure que nous continuerons à relever les défis et à saisir les opportunités que présente SEND.
Si vous souhaitez poursuivre cette conversation, écrivez-moi à l'adresse instem
Jusqu'à la prochaine fois,
Marc
