夜雨聆风有个刚从研发转注册的同行，第一次做 eCTD 递交前问了一句话："不就是把所有文件转成 PDF，打包上传吗？"
打个比方。传统纸质递交是一摞打印好的文件夹，按编号码在审评员桌上。后来改成 PDF 递交，等于把同一摞文件扫描成电子版，还是一摞，只是不用纸了。文件之间没有关联，没有目录，没有版本追溯。审评员想找 Module 3.2.P.5 里某个 acceptance criterion 的 justification，只能一页页翻。
eCTD 不一样。PDF 是"纸"，eCTD 是带目录、带版本控制、带交叉引用、带全球统一货架编号的数字化档案库。每一份文件放进去的时候，它的位置、层级、与其他文件的关系、在整个审评生命周期里的版本状态，全都被一段 XML 代码定义得清清楚楚。
审评员不需要翻。点一下目录树，直接跳到 3.2.P.5.6 的第 3 段。再点一下交叉引用链接，跳到 3.2.P.8.3 的稳定性数据表。还能看到这份文件是第几版、上一版什么时候替换的、替换发生在哪次递交中。
两种东西。今天拆四个知识点，把 eCTD 从里到外讲透——它是什么、为什么 FDA/EMA 强制要求、怎么搭、怎么递交。
一、XML Backbone：eCTD 的"编目系统"，不是 PDF 的封皮
Concept 辨析
eCTD 的全称是 electronic Common Technical Document。很多人盯住 "Common Technical Document"——CTD 嘛，五个模块，ICH M4 定义的格式，研发出身的都知道。但前面那个 "electronic" 才是重点。
eCTD 的核心不是 PDF 文件本身，是一段叫做 XML backbone（XML 骨干文件）的代码。这段 XML 定义了整个提交的结构：哪个文件放在哪个模块的哪个章节下、文件标题是什么、版本信息是什么、与其他文件有没有交叉引用关系。
类比图书馆。XML backbone 就是编目系统。每本书（PDF）放进去的时候，系统给它分配一个唯一的位置（folder path）、一个索书号（ID），还记录了它和其他书的关联关系（cross-reference）。没有这套编目系统，PDF 就是一堆散在地上的纸——审评员拿到手里不知道从哪开始看。
法规原文引用
"The eCTD backbone is an XML file that defines the structure and metadata of the submission. It provides a standardized interface for the transfer of files and related information across regulatory authorities." — ICH eCTD Specification
"Section 745A(a) of the FD&C Act requires that submissions for human drug applications be submitted in electronic format." — FDA Guidance: Providing Regulatory Submissions in Electronic Format (FDARA 2017, Section 3001)
FDA 从 2017 年 FDARA 法案签署后分阶段强制 eCTD。NDA、ANDA、BLA、IND 的各类 submission type 陆续被纳入强制清单。EMA 也在差不多时间完成了 centralized procedure 和 mutual recognition / decentralised procedures 的 eCTD 强制要求。主要监管机构不再接受纸质或非结构化 PDF 递交。
常见错误对照
❌ "把 Module 1-5 的所有 PDF 放进五个文件夹，压缩上传就行" ✅ eCTD 的目录结构由 XML backbone 定义，不能手动建文件夹。每个 PDF 的存放路径必须与 XML 中的 leaf element 一一对应。
❌ "eCTD 就是 CTD 的电子版" ✅ CTD 是内容格式（五个模块的章节编号），eCTD 是递交格式。CTD 定义"写什么"，eCTD 定义"怎么递、怎么管版本、怎么让审评员检索"。一套内容，两套框架。
二、Leaf / Granularity / Cross-Reference：eCTD 怎么给文件"上架"
Concept 辨析
eCTD 的目录树由一个个 leaf（叶节点）组成。每个 leaf 对应一份实际文件（通常是 PDF）。leaf 在目录树里的位置由它的 element 决定——比如 3.2.P.5.1 就是一个 element，代表 Module 3 Quality 部分关于成品规格的那一节。
三个关键概念：
- Leaf
：目录树的末端节点，对应一份具体文件。一份 NDA 的 Module 3 可能有几百个 leaf。
- Granularity
（颗粒度）：eCTD 允许在某一节放一个完整的 PDF，也允许把它拆成多个更小的 PDF。拆得越细，交叉引用和版本管理的灵活性越大，搭建和验证的复杂度也越高。通常建议拆到 ICH M4 定义的最细章节级别。
- Cross-reference
（交叉引用）：一份文件在多个上下文中被需要时，eCTD 允许同一份 PDF 被多个 leaf 引用，而不是重复上传。比如同一份 HPLC 方法验证报告在 Module 3.2.P.5.3（成品方法验证）和 Module 3.2.S.4.3（原料药方法验证）里都可能被引用，用 cross-reference 链接过去，传一份。
法规原文引用
"The granularity of the eCTD allows the submission of documents at a level appropriate to the submission. The use of the same document in multiple contexts can be achieved through the use of cross-references in the backbone." — ICH eCTD Specification
"Where a document is applicable to multiple sections of the dossier, a single copy of the document should be submitted and referenced by cross-reference." — EU Module 1 Specification
常见错误对照
❌ 把整份 Module 3 写成一个大 PDF 上传 ✅ 按 ICH M4 定义的章节编号，将 Module 3 拆分到 3.2.S.x.x.x 或 3.2.P.x.x.x 的 leaf 级别。每个 leaf 一份 PDF。这样审评员可以直接定位到某一节，后续 amendment 也只需要 replace 那一个 leaf，不用重新传整份 Module 3。
❌ 同一份稳定性数据在 Module 3.2.P.8 和 Module 2.4 各传一份 ✅ 在 Module 2.4 用 cross-reference 指向 3.2.P.8 中的原始数据。减少冗余，也避免审评员看到两份"一模一样"的文件时怀疑有没有不一致。
三、Lifecycle Management：eCTD 怎么做"版本控制"
Concept 辨析
这是 eCTD 相比传统纸质递交最大的优势。传统方式下，NDA 初始递交后需要补充数据，重新寄一摞文件过去，审评员桌上又多一摞。两摞之间的关系是什么？哪些替换了？哪些新增了？哪些删除了？全靠 cover letter 里人肉说明。
eCTD 用 lifecycle（生命周期）机制自动管理这些关系。每个递交被定义为一个 sequence（序列）。第一次递交是 sequence 1（initial submission），后续每次递交（amendment、supplement、annual report、IR response）依次递增。每个 sequence 的 XML backbone 会声明每个 leaf 的 operation type（操作类型）：
Operation | 含义 | 典型场景 |
New | 新增文件到目录树中此前为空的位置 | 初始递交；后续补充章节中原先没有的内容 |
Append | 在某章节下追加文件，原有文件不受影响 | 在 3.2.P.8 下新增一批稳定性数据 |
Replace | 用新版文件替换旧版文件，旧版标记为 archived | 某个 test method 修订后替换 3.2.P.5.2 |
Delete | 从目录树移除某个 leaf（实际文件保留在历史记录中） | 较少见，通常用于移除错误上传的文件 |
审评员打开 eCTD viewer 后看到的是当前有效版本。想看历史，展开 lifecycle tree，每个 leaf 从 sequence 1 到现在经历了哪些操作、哪些版本被替换、替换发生在哪次递交中，一目了然。
法规原文引用
"Each submission sequence builds upon the previous one. The operation type (new, append, replace, delete) indicates how the submitted files relate to the existing dossier." — ICH eCTD Specification
常见错误对照
❌ 第二次递交（IR response）时重新传了整份 Module 3 ✅ 只 replace 被审评员质疑的那几个 leaf（比如 3.2.P.5.6 justification 和 3.2.P.8.3 stability summary），其余 leaf 保持原样。如果 IR 涉及新增内容，用 append operation。大幅减少文件体积和审评负担。
❌ Replace operation 里上传了文件名和旧版一样的 PDF，内容改了但没说明变更理由 ✅ 每次 replace 都应在 cover letter 中说明：which leaf was replaced, why, what changed。XML 里也会记录 operation type 和 sequence number，但 cover letter 里的人读说明是审评员快速定位变更内容的主要途径。
四、Hyperlink 与 Cross-Reference：eCTD 的"货架关联系统"
Concept 辨析
传统纸质递交中，Module 2.5 Clinical Overview 引用 Module 5 的某项临床研究数据，能做的就是在文本里写 "see Study XYZ, Section 5.3.5.2"。审评员得去另一个文件夹里翻。
eCTD 支持真正的 hyperlink（超链接）。XML backbone 里可以定义 cross-reference，从某一个 leaf 直接链接到另一个 leaf。审评员点击后直接跳转。
交叉引用有三种典型用法：
- Module 2 → Module 3/5
：Module 2 是摘要层，引用 Module 3 的质量数据或 Module 5 的临床数据时不重复全文，用 cross-reference 指过去。
- 同一 Module 内不同章节之间
：3.2.P.5.6（justification of specification）引用 3.2.P.8.3（stability summary）——审评员读 justification 时一键跳到稳定性数据，不用退出当前界面。
- 跨递交引用
：sequence 1 传了 3.2.P.5.3 方法验证报告，sequence 5 的 IR response 里如果方法没变，直接 cross-reference 到 sequence 1 的版本，不重新传。
法规原文引用
"Cross-references within the eCTD dossier can be used to link related documents, reducing redundancy and improving navigation for the reviewer." — ICH eCTD Specification
常见错误对照
❌ 在 Module 2.3 的摘要里全文复制 Module 3.2.S.3.2 的杂质数据 ✅ 用 cross-reference："See Module 3.2.S.3.2, Impurities, for the full impurity profile. The summary of specified and unspecified impurities is presented in Table 2.3.S-1." 审评员点链接跳过去看原始数据。
❌ 在 IR response 中重新传了一份已经交过的方法验证报告（"方便审评员查阅"） ✅ 直接 cross-reference 到 original sequence 里那份报告。eCTD viewer 支持跨 sequence 的超链接。重新传的后果：validation 报 "duplicate file" 警告；审评员看到两份内容相同的文件反而困惑"哪份是有效的？"
五、怎么弄这个：搭建、验证、递交的实操路径
讲完原理，说怎么做。
1. 软件
eCTD 的 XML backbone 不建议手写。除非递交量极小（比如一个 IND 的 initial submission），用专业软件。市面上常见的：
- 商用 eCTD publishing 软件
：如 Veeva Vault Submissions、Extedo eCTDmanager、Parexel Perceptive Submission Publishing 等，覆盖从 CTD 结构搭建到 XML 生成、validation、submission 打包。
- 轻量工具
：如 eCTD Generator，适合小团队和低频递交，validation 功能不如商用方案全面。
选工具的核心标准不是价格，是两件事：validation 规则更新是否及时（FDA 和 EMA 会不定期更新 validation criteria）；是否支持多 region（FDA Module 1 和 EMA Module 1 的 regional specification 不同）。
2. 验证
打包完成后，递交前必须过 validation。eCTD validation 分两层：
- Technical validation
（技术验证）：检查 XML 结构是否合规、文件命名规范、目录路径正确、所有 hyperlink 是否有效。硬性的——不过就递交不了。
- Business rules validation
（业务规则验证）：检查是否有重复文件、是否缺关键 leaf、operation type 是否合理、Module 1 的 regional 信息是否完整。产出 warning 和 error。Error 必须修复；Warning 可以豁免但需在 cover letter 说明。
FDA 和 EMA 各有自己的 validation criteria 文档，定期更新。递交前用最新 criteria 跑一遍。
"Submissions that fail technical validation will be rejected at the gateway and will not be received by the reviewing division." — FDA eCTD Validation Criteria
这句话写进了 FDA 的 validation 文档——gateway 层面拦截，审评员都看不到你的文件。
3. 递交渠道
监管机构 | 递交渠道 | 说明 |
FDA | Electronic Submissions Gateway (ESG) | 通过 AS2 协议传输。需申请 ESG 账号并通过测试递交 |
EMA | CESP (Common European Submission Portal) | 欧盟统一递交入口，支持 centralized / DCP / MRP 程序 |
PMDA | eCTD 递交系统 | 日本 PMDA 自 2014 年起接受 eCTD，后续分阶段强制 |
FDA ESG 注册流程不复杂但耗时——从申请到拿到 production 账号通常需要 2-4 周。新公司第一次做 eCTD 递交，提前申请，别等递交前一周才发现没 ESG 账号。
六、Bonus：一个真实的 eCTD Gateway 拒收案例
某仿制药企业递交 ANDA amendment 时被 FDA Gateway 拒收（gatekeeper rejection）。原因列表如下（已脱敏）：
Error 1: Broken cross-reference
"The submission contains a cross-reference to leaf 3.2.P.5.3 in sequence 1, but the referenced leaf was replaced in sequence 3. The cross-reference is no longer valid."
分析：该企业在 sequence 3 中 replace 了 3.2.P.5.3，但 sequence 5 的 IR response 里还在 cross-reference 到 sequence 1 的旧版本。eCTD 的 cross-reference 必须指向当前有效版本。目标 leaf 被 replace 了，所有指向它的 cross-reference 需要更新到最新 sequence。
Error 2: Duplicate file detected
"The file 'stability_summary.pdf' (MD5: [hash]) is submitted as a new leaf in 3.2.P.8.1, but an identical file (same MD5) already exists in sequence 4 at 3.2.P.8.3."
分析：递交人员把同一份稳定性摘要传了两遍——一次在 3.2.P.8.1，一次在 3.2.P.8.3。正确做法是只在其中一处传，另一处用 cross-reference。
Error 3: Missing required leaf
"Module 1.2 (Cover Letter) is required for all submission types. No file was found at the expected path."
分析：Module 1 是 regional specification 定义的。FDA 的 Module 1 必须包含 cover letter（1.2），某些 submission type 还要求 application form（1.1）、delegation signature/authorization（1.5）等。漏了 cover letter 这种基础 leaf，gateway 直接拒收，进不了审评。
三个错误，同一个根源：把 eCTD 当成了"传 PDF"。
写在最后
做了多年药企研发的人转注册，工艺、质量、稳定性这些内容能力都在。卡住的不是专业，是"怎么把已有知识体系放进法规机构规定的数字框架里"。
eCTD 不是 IT 部门的事，是注册部的事。XML backbone 的结构、lifecycle 的 operation type、cross-reference 的逻辑——这些决定了审评员能不能高效审你的 dossier，也决定了后续每次发补、supplement、annual report 的工作量是替换一个 leaf 还是重新传整份 Module。
