大家可能都知道，Instem 最近收购了 PDS 生命科学公司，因此我一直在与我的新同事 Mike Wasko 密切合作。Mike 是我们行业内的知名人士，本周我们在叙旧时开始讨论一个问题：eCTD 研究标签文件 (STF) 和 SEND 数据集之间的关系以及对技术拒绝标准 (TRC) 的影响是什么？由于这个问题会引起一些混淆，并可能导致自动技术拒绝提交，因此我请 Mike 写下他的想法，以便在本博客中与大家分享。以下是他的看法：
如《技术一致性指南》（TCG）、TRC 和《eCTD 指南》所述，STF 中使用的研究标识必须与 TS 域中的 STUDYID 或申办者参考标识（SPREFID）值相匹配。此外，该研究标识必须出现在 define.xml 文件的研究名称（StudyName）元素中。这种联系是显而易见的，但要知道申办者将在 STF 中使用哪个研究标识则另当别论。
通常情况下，研究的进行以及随后的 SEND 数据集创建都由研究总监和 SEND 团队管理。无论 SEND 团队是 CRO 的内部团队还是外部团队，SEND 团队通常与创建 STF 的申报团队几乎没有任何联系。
现在，FDA 的 TRC 已经生效（2021 年 9 月 15 日），SEND 数据集和 STF 之间的连接变得至关重要，有关 STF 中研究标识的交流必须进行调整。在理想情况下，创建 SEND 数据集和相关 define.xml 文件的团队将被告知 STF 中使用的研究标识。
人们会认为研究标识符应该是显而易见的，但事实并非总是如此。再加上 STF 通常是在 SEND 数据集完成后创建的，这就产生了一个独特的问题。对于由 CRO 开展的研究，一项研究可能有多个不同的标识符，包括申办者研究标识符、CRO 研究标识符、报告编号或其他标识符。在这种情况下，SEND 团队很难确定 STF 将使用哪个标识符，而且要记住，错误的假设将导致技术拒绝。
即使在报告和 SEND 数据集包中使用了单一的研究编号，另一种使用情况也会带来挑战。由于文件夹结构的原因，eCTD 和 STF 限制了可使用的字符类型。不应使用"/"、"\"、". "等特殊字符。如果研究报告和规程在研究编号中使用了此类字符，那么在 STF 中将如何表示？是否只是删除了该字符？该字符是否被替换为"_"或"-"等可接受的字符？
对于接近 SEND 数据集生成时间的提交，提交团队的主动沟通可以解决问题。但是，考虑到 SEND 数据集在提交前可能会放置数年，例如 NDA。工作人员可能已经更换，或者协议没有得到很好的记录。现在，申办者需要确保 STF 和 STUDYID 或 SPREFID 一致。 如果不一致，则必须相应更新 ts.xpt 和 define.xml 文件。 目前，我们还不知道有任何验证器能自动进行这种检查，因此赞助商还需要知道在 define.xml 和 ts.xpt 中的哪个位置查找，以确保 STF 中指定的研究 ID 与数据集和 define.xml 文件相匹配。随着时间的推移，似乎越来越多的人需要具备 SEND 意识，因为这不再是 SEND 团队和研究总监的严格职责。
我认为迈克的分享是一个很好的解释，你们可以期待，在我们继续驾驭 SEND 所带来的挑战和机遇时，我还会请迈克为我们做贡献。
如果您想继续交流，请给我留言：instem
下次再见
马克
