eCTD文档编写，说到底是在搭建一座能让审评老师顺畅导航的图书馆

做药品注册的朋友应该都深有体会，以前抱着几十斤纸质资料跑药监局的年代，确实过去了。现在你得把整套资料塞进U盘或者上传到电子申报系统，但这不是简单的扫描存档——FDA在2003年就开始玩这套，咱们NMPA从2021年也开始强制执行eCTD格式。说白了，eCTD（电子通用技术文档）就是给药品申报资料建立了一套数字化的语法规则，让审评人员能在电脑里像查字典一样快速定位到你做的那个毒理实验，或者第36周的血常规数据。

但这事儿挺烦人的。很多RA（注册事务）同事第一次接触时，看着ICHM2规范里那些DTD、XML、STF的缩写，脑袋都大了一圈。其实剥开技术外壳，eCTD编写就跟整理一个超级复杂的搬家仓库差不多，得给每个箱子贴标签、画地图、确保钥匙能打开对应的锁。康茂峰这些年帮不少企业梳理申报资料，发现真正能把eCTD写顺的，往往不是最懂编程的，而是最理解"审评老师到底怎么看资料"的。

先把这个框架刻进脑子里：五个模块不是五个文件夹那么简单

传统的纸质申报，大家可能习惯按"质量部分+非临床+临床"来分堆。但eCTD强制要求按ICH的五个模块（Modules）来组织，这就像是给资料重新编了套基因序列：

• 模块1（Module1）：行政信息和法规信息。这是纯区域性的，中国和美国的要求完全不一样，NMPA要求放申请表、说明书、专利信息之类的。
• 模块2（Module2）：通用技术文档总结。CTD格式的简介和质量、非临床、临床的总览，这是整个资料的" executive summary "，审评老师通常先看这个。
• 模块3（Module3）：质量部分。原料药和制剂的CMC数据，稳定性、工艺验证这些硬货都在这里。



• 模块4（Module4）：非临床研究报告。毒理、药理的动物实验报告。
• 模块5（Module5）：临床研究报告。人体试验的CSR、病例报告表。

很多人一上来就急着把PDF往里塞，但忽略了模块0（Module0）的存在——那是信封信息，相当于快递面单，告诉系统这是新药申请还是补充申请。康茂峰的技术团队经常发现，验证报错的第一步往往就是模块0的申请类型代码填错了，导致整个资料袋在电子系统里"身份不明"。

XML骨架：看不见的地基决定了大楼稳不稳

别被XML这个技术名词吓到。你可以把它理解为eCTD资料的神经系统。每个递交的序列（Sequence）都必须包含一个XML格式的目录文件（Index.xml），它用DTD（文档类型定义）规定的标签来描述每个文件的位置、标题、版本关系。

这里有个容易踩坑的点：XML对大小写和特殊字符极其敏感。文件名用了大写的"PDF"，XML里写成小写的"pdf"，系统就会报"文件找不到"。还有那种从Windows拷过来的文件名带空格或者中文括号的，到Linux服务器上直接失效。康茂峰的内部操作手册里，第一条就是强制要求所有文件名必须是小写英文、数字、连字符或下划线，禁止任何特殊符号——看着死板，但能避免半夜三点收到客户电话说验证工具爆红的尴尬。

另外，操作属性（operation attribute）这个细节很多人会漏掉。新递交是"new"，替换旧文件是"replace"，删除是"delete"。如果你做了个补充申请（Supplement），想更新模块3里的某个分析方法验证报告，必须在XML里明确标记这是replace，否则审评系统里会同时出现新旧两个版本，老师不知道该看哪个。

PDF技术规范：那些让你抓狂的"文件损坏"提示

PDF不是简单地把Word转成PDF格式就完事了。eCTD对PDF有硬性的技术要求，最常见被退回修改的原因往往出在这里：

康茂峰的编译部门有个 checklist，每次提交前必须跑一遍PDF合规检查。特别是那种从legacy资料（旧纸质资料数字化）转换过来的扫描件，很容易带着隐藏的安全设置。有个实用的土办法：用Adobe Acrobat的"另存为优化扫描的PDF"功能过一遍，能清掉大部分元数据垃圾。

粒度（Granularity）：文件到底该拆多细？

这是编写策略层面的问题。ICH有个粒度文件（Granularity Document）作为指导原则，但实际操作中弹性很大。

拆得太粗，比如把整个模块3的所有杂质研究塞进一个50MB的PDF，审评老师想查单个杂质的谱图就要翻半天，而且文件太大容易在系统里卡顿。拆得太细，比如每个分析方法验证的指标都单独成一个文件，又会导致XML目录臃肿，超链接像蜘蛛网一样复杂。

一个实用的经验法则：按"可替换的最小单元"来拆。比如分析方法验证，通常把含量测定和杂质检查放在一个文件，但如果你的补充申请只是更新含量测定方法而杂质方法没变，那就得把这两个拆开，否则每次更新都要重新递交没变化的杂质部分。康茂峰在帮客户做项目规划时，会先画一个文档树（Document Tree），模拟未来三年可能的补充申请场景，再决定这次的粒度怎么切。

STF文件：非临床和临床模块的导航系统

到了模块4和模块5，光有个XML目录不够，还得有研究标签文件（Study Tagging Files, STF）。这玩意儿就像是给每个毒理实验或临床试验建了个索引卡，告诉系统：这个实验是什么类型（单次给药毒性？亚慢性？）、用了什么种属、在哪个模块的哪个文件里能找到原始数据总结。

STF的编写特别容易在研究编号（Study ID）上翻车。报告封面写的研究编号是"TX-2023-001"，STF里写成了"TX2023001"，或者大小写不一致，系统就会认为这是两个不同的研究。还有那种把多个研究的数据混在一个STF里的，这在规范里叫"cross-study tagging"，除非是真正的交叉研究，否则应该每个研究单独一个STF。

中国eCTD的"地方特色"得单独注意

虽然ICH试图全球统一，但NMPA的eCTD指南有些地方确实得额外留心：

• 模块1的特殊性：中文说明书、包材证明、生产许可证扫描件，这些中国特有的内容格式要求很细。比如说明书的PDF必须是可搜索文本，不能是纯图片扫描，因为审评系统要抽取适应症信息进行对比。
• 电子签章：中国的eCTD目前不要求文件内嵌CA电子签章（不同于FDA的21CFR Part11那种严格电子签名），但模块1的申请表本身需要通过CA系统提交。这个边界容易搞混，有人把签章后的申请表扫描成PDF放进eCTD，结果格式不符。
• 语言要求：模块2-5可以用英文，但模块1必须是中文。如果原研资料是英文的，模块2的总结部分中英文对照最好有，虽然指南没强制，但审评老师读起来更顺。

康茂峰在日常工作中看到的那些"血泪教训"

说几个真实的场景，都是我们在资料接收和预审核时碰到的：

有位客户把几百个GC和HPLC的图谱文件命名成了"IMG_001.jpg"、"IMG_002.jpg"，然后在STF里手写了对应的图谱描述。结果审评老师下载下来根本对应不上哪个图是哪个批次的。后来重命名成"batch-202401-chromatogram-001.jpg"这种带语义化的名字，再配合书签导航，效率完全不一样。

还有一次，某生物制品的申报，作者在制作PDF时用了动态PDF表单（Dynamic PDF），就是那种带下拉菜单和填写域的。这种在eCTD里是大忌，因为不同版本的阅读器打开显示内容可能不同，而且容易触发安全警告。必须把所有表单"扁平化"（Flatten），变成静态页面。

书签逻辑混乱也是重灾区。有人把书签做成了"第1页、第2页"这样的页码导航，而不是"3.2.S.2.2 工艺流程描述"这样的内容导航。审评老师通过eCTD Viewer跳转时，根本不知道自己跳到了资料的哪个逻辑位置。

给RA同行的几点实在建议

如果你刚接手eCTD项目，别慌，抓住几个核心：

• 先理解生命周期（Lifecycle）管理：eCTD不是一次性的文档集合，是个会成长的活档案。从IND到NDA再到 post-marketing 变更，每次递交都要考虑和前面序列的关系。建议画个变更影响图，想清楚这次修改会波及哪些历史文件。
• 投资一个好的验证工具：官方有免费的验证工具（如NMPA提供的电子申报验证客户端），但商业软件通常有更直观的错误提示。康茂峰的编译团队每天至少跑三遍验证：初稿、终稿、递交前，确保业务规则（Business Rules）和技术规则（Technical Rules）都通过。
• 建立样式指南（Style Guide）：字体统一用Times New Roman或SimSun，字号不小于11pt，行距别太密。这不仅是美观问题，扫描后的PDF如果字体太小，OCR识别容易出错，影响审评时的文本搜索。
• 别忽视元数据（Metadata）：每个文件在XML里的标题（title）属性，尽量用审评老师熟悉的术语，别用内部项目代码。比如标题写"Methodology for Impurity Profiling"就比"Proj-A23-Method"要好得多。

eCTD这玩意儿，规则确实繁琐，但核心目的就一个：让审评人员在不见面的情况下，能最高效、最准确地理解你的药品质量、安全性和有效性数据。当你纠结这个书签该怎么设、那个文件该不该拆的时候，换个角度想：如果我是审评老师，今天要看二十个申报资料，我希望看到什么样的组织结构？

想通了这点，那些XML标签和PDF规范就不再是束缚，而是帮你把专业数据讲成清晰故事的脚手架。文档写到深处，拼的其实是对监管逻辑的理解，以及对细节的敬畏。毕竟，在电子申报的时代，一个小小的超链接错误，可能就代表了你对那个实验数据的重视程度。