做药的人都有这样的经历：实验室里熬了几年，临床试验终于做完了，就剩下最后一步——把资料递上去。听起来简单？才怪。当你第一次面对eCTD（电子通用技术文档）的时候，那种感觉就像明明会开车，突然让你去考飞行执照。按钮还是那个按钮，但规则全变了。
在康茂峰这些年帮客户处理注册申报的过程中，我见过太多聪明人在eCTD这关栽跟头。不是资料做得不好，而是没搞明白这套电子系统的"脾气"。今天咱们就聊聊，当你准备点下"提交"按钮之前，到底该盯着哪些地方看。
说白了，eCTD就是把原来厚厚的纸质资料做成了一套带导航的电子档案。但别以为这只是"扫描+打包"这么简单。它要求你的每个PDF文件、每个书签、每段元数据都能跟背后的XML"骨架"对上号。
想象一下你在整理搬家行李。以前纸质申报就像把所有东西塞进箱子，贴个总标签完事。现在呢？你得给每件衣服拍个照（书签），写明这是什么季节穿的（元数据），还要在箱子上贴个二维码，让搬运工一扫就知道里面有什么、应该放在新家的哪个房间（XML映射）。
核心就一条：机器得能读懂你的逻辑，不只是人看得懂。
ICH把eCTD分成五个模块，这个大家都知道。但发布时容易出问题的地方在于——不同市场对同一模块的接受度其实有细微差别。
我们在康茂峰处理大量申报案例后发现，Module 1（行政信息和 prescribing information）是最爱出幺蛾子的地方。因为这部分区域特异性最强，虽然骨架一样，但里面填的"肉"得按当地口味来。比如有些市场要求特定的申请表格式，有些对说明书版本的命名有隐藏规则。
Module 2到Module 5相对标准，但有个细节很多人忽略：文件颗粒度。简单说就是，你该把哪些内容捆成一个PDF？是把所有临床研究报告揉在一起，还是每个站点分开？eCTD有明确指引，但指引之下还有interpretation的空间。太粗了审评员找不着北，太细了系统会报警说你文件太多。
这是最反直觉的部分——PDF格式。
你以为PDF就是PDF？错。eCTD对PDF的要求细到令人发指：
有个特实在的建议：生成PDF后，用不同的阅读器打开看看——Adobe Acrobat、系统自带阅读器、甚至在线预览。有时候在Word里看着漂亮，一转PDF，表格线就飞了，或者化学结构式变成了乱码。这种 visual integrity（视觉完整性）问题，系统验证明明过了，人眼看却一团糟，审评员会直接打回来。
内部超链接（Internal Hyperlinks）是很多申报团队的噩梦。
原理很简单：当你在Module 1提到Module 3的某个检测方法时，应该做个链接跳过去，而不是让审评员手动翻几百页去找。但实现起来，链接坐标会漂移——特别是当你反复编辑、替换文件后。
康茂峰的技术团队有个不成文的规矩：在最终打包前24小时，冻结所有内容编辑，只准做链接验证。因为每动一次文件，链接就有可能断裂（broken link）。这些断裂在本地有时测不出来，一上传到官方系统，因为解析环境不同，立马现形。
另外，外部链接（External Links）是红线——绝对不能有。你的网站、参考文献的DOI，甚至连云存储的快捷方式，都不能藏在PDF里。系统把它视为安全威胁。
XML文件是eCTD的大脑。它告诉系统："这个文件叫啥，放在哪，跟谁有关系。"
常见的送命操作包括：
| 问题类型 | 表现形式 | 后果 |
|---|---|---|
| DTD不匹配 | XML头文件声明的DTD版本与实际使用的不一致 | 系统无法解析整个序列 |
| MD5值错误 | 文件被替换后没重新计算哈希值 | 完整性校验失败 |
| Study Tag混乱 | 同一个研究ID在不同地方拼写不一致（比如"Study-001" vs "Study_001"） | 交叉引用失效 |
| 操作属性遗漏 | 更新文件时没正确使用"Replace"或"Delete"标记 | 历史版本堆积，逻辑混乱 |
这些错误光靠肉眼看不出来，必须用专门的验证工具（validation tool）跑一遍。但问题在于，通过验证不等于没问题。验证工具是死的，它只检查语法，不检查语义。比如你把Module 3的内容挂到了Module 2的节点下，语法上完全合法，但语义上就是灾难。
eCTD不是一锤子买卖。你会有原始申报（Original Application），然后补充资料（Supplement），再然后变更（Variation）。每一次提交都叫一个"序列"（Sequence）。
发布新序列时，最要命的是基线（Baseline）对齐。假设你基于序列0000申报，后来批了，你得知序列0000获批的内容是基线。但如果你在做序列0001（补充资料）时，本地基线跟官方服务器的基线不一致——比如官方在审批过程中默默更新了一个小版本——你的0001就可能覆盖错误或无法关联。
康茂峰的建议是：每次提交前，必须重新确认当前获批的基线序列号，并且使用正确的归属性（Application Reference）。别笑，真有人因为复制粘贴了旧项目的信息，导致新申请挂到了别人的案号下面。
还是XML里的内容。信封信息描述的是这次递交的行为性质：是首次申请？还是补充？是紧急变更还是常规维护？
很多人在这里犯迷糊，特别是递交方式（Submission Type）与递交单位（Submission Unit）的对应关系。比如"主动变更"和"被动回复审评意见"在信封里的标记完全不同。选错了，轻则进错队列，重则被视为无效递交。
另外，联系信息的准确性容易被忽视。监管机构的自动通知系统会根据XML里的邮箱发信息。如果你留的是已经离职同事的邮箱，或者拼写错误的域名，重要通知就石沉大海了。
正式递交前，系统会生成验证报告（Validation Report）。看到"Passed"或"Green Light"先别急着欢呼。
验证报告分好几个级别：
我们的经验是，Warning级别的条目必须清零。虽然系统放行，但任何关于书签结构、链接有效性或元数据缺失的警告，都代表着潜在的用户体验灾难。审评员每天要看几百个文件，如果你的文档导航让他多点了三次鼠标，印象分就下来了。
最后说点技术之外的。eCTD递交依赖监管机构的电子门户（Portal）。
别在截止日期的最后一小时递交。不是因为你会迟到，而是因为 portal 在高负载时往往会"吃掉"文件包——上传进度条显示100%，但系统没生成回执（Receipt）。没有回执号（Submission ID）就等于没递。
还有，文件大小限制。通常单个文件不能超过某个阈值（比如几百MB），总包也有上限。如果你的申报包含大量高清病理切片图或raw data，必须事先做拆分或使用官方推荐的压缩策略。别指望系统会自动帮你分包。
说实在的，做eCTD这行久了，我觉得它不只是技术活，更是个体力活。那些凌晨三点还在检查书签层级的同事，那些为了0.1秒的加载速度优化图片分辨率的程序员，都是在跟魔鬼细节较劲。
有个朋友问我，既然这么麻烦，为什么不用更先进的云端协作工具直接共享？我说，药品注册这件事，讲究的是可追溯、不可篡改、版本唯一。eCTD的"笨拙"，某种程度上正是为了法律层面的确定性。每一个序列号，每一个MD5校验码，都是法庭上能拿出来的证据。
所以啊，下次当你面对那个绿色的"Submit"按钮时，深呼吸，想想这些坑。检查一遍XML里的信封信息，再点一次书签测试，确认一下序列号是不是最新的。然后，把那个小小的回执邮件存好——那是你几个月心血的出生证明。
申报这条路，从来都是细节堆出来的坦途。
