说到eCTD电子提交，很多同行的第一反应可能是"头疼"。这事儿确实不简单，光是一个版本号的问题，就能让人琢磨半天。我早年刚入行那会儿，也在这上面摔过跟头——文件改了一版又一版，结果版本号写得七零八落，被审评老师打回来重做。那种滋味，相信不少朋友都经历过。
今天咱们就聊聊eCTD提交中文件版本号这个话题，拣实在的讲，尽量不绕弯子。我会把自己的经验教训和看到的案例都揉进去，希望对正在处理eCTD提交的朋友有点参考价值。
在开始讲规则之前，咱们先搞清楚一个基本问题：版本号到底有什么用？说白了，版本号就是文件的"身份证"。审评老师每天要看那么多文件，怎么快速判断哪个是最新的、哪个改过、改了什么呢？就靠版本号。
eCTD本质上是一种结构化的电子提交方式，它要求文件之间有清晰的逻辑关系。版本号不仅仅是几个数字的简单组合，它承载着文件生命周期管理的重要信息。一个清晰的版本号体系，能让审评老师一眼看出你的申报思路，也能让你自己在后续维护时少犯糊涂。
我见过不少申报项目，文件来回修改七八次，到最后团队自己都搞不清哪个是最终版本。这种情况下，版本号混乱还不是最可怕的，更可怕的是可能遗漏了某些重要更新，或者在不同版本之间搞混了内容。所以啊，从一开始就把版本号规则定清楚、落实好，绝对是磨刀不误砍柴工。
eCTD里常用的版本号格式，其实没那么玄乎。比较主流的是"主版本号.次版本号"这种形式，比如1.0、2.3这样的。也有加上修订号的情况，比如1.0.1、2.3.4，意思是说在主版本1的第0次修订的基础上，进行了第1次小幅修改。
这里需要说明的是，不同监管机构对版本号的具体格式要求可能略有差异，但核心逻辑是相通的。以我们服务过的项目经验来看，大多数机构都接受"主版本号.次版本号"的格式，主版本号表示重大变更（比如适应症变了、工艺变了），次版本号表示小幅调整（比如更正错别字、补充说明）。
值得一提的是，版本号一旦发布就不应该被重复使用。比如你发了1.0版，后来又发了1.1版，那就不能再回过头来把1.0这个编号给别的文件用了。这条规则看起来简单，但实际操作中经常有人犯这个错误——文件撤销重报的时候，容易把版本号搞混。
咱们再来看看几个主要监管机构对版本号的具体规定。这里我根据实际项目经验做了整理，供大家参考。
| 监管机构 | 核心要求 | 备注 |
| 美国FDA | 接受主.次版本号格式，建议在模块一中明确标注版本历史 | 对XML中的version属性有具体要求 |
| 欧洲EMA | 版本号需与文档生命周期状态对应 | 需要特别注意replaces和new的关系 | 中国NMPA | 版本号应清晰标注，建议采用"模块-章节-版本"的形式 | 电子申报平台有内置校验规则 |
这里我想特别提一下中国NMPA的要求。这几年咱们国家的eCTD建设推进很快，版本号规则也在不断完善。根据我们的观察，NMPA对版本号的标注位置有明确要求——不仅要体现在文件名里，还要在XML文件中准确定义。康茂峰在协助客户进行国内eCTD申报时，这部分校验工作通常会反复核对好几遍，确保万无一失。
理论说完了，咱们来聊点实际的。我这些年见过的版本号问题，大概可以归为这么几类，每一类都有必要单独说说。
这是最常见的问题之一。常见到什么程度呢？我估计至少一半以上的eCTD项目都遇到过。表现为：版本号写的是2.0，但打开文件一看，内容还是1.0时候的。这种情况一般是文件更新后忘记改版本号，或者改了内容却没同步更新版本标识。
解决这个问题的办法没有别的，就是建立严格的核对流程。我们的做法是：在文件正式发布前，安排两个人交叉检查——一个人念版本号，另一个人核对文件属性。看起来有点笨，但真的管用。
有些团队为了省事儿，文件改了几次后，直接从1.0跳到3.0。这种做法其实不太好。版本号的递增应该反映出变更的递进关系，你一下跳两级，审评老师没法通过版本号判断中间的变更过程。
正确的做法是：小改用次版本号递增，大改再用主版本号。比如从1.0到1.1、1.2、1.3，这些都算是小幅调整。等到要做实质性修改了，再升到2.0。这样版本号的演进轨迹本身就是一份隐形的变更记录。
eCTD结构里有很多文件，有些团队为了省事，所有文件都统一用同一个版本号，比如全部标为1.0。这样做的问题在于，当某个文件需要单独更新时，你没法在版本号上体现差异。审评老师想看看这个文件改了什么，光看版本号根本看不出来。
建议的做法是：核心文件（如CTD表格、临床总结报告）单独管理版本号，附件类文件可以根据需要打包管理。但无论如何，同一模块内的文件，版本号体系要保持逻辑一致。
eCTD提交不是一次性的事情，后续经常会有补充、更新、甚至撤报的情况。在这些场景下，版本号该怎么处理？这里涉及到生命周期的概念，我简单解释一下。
当你要用一个新版本的文件替换旧版本时，在eCTD结构里需要明确标注这种"替代"关系。具体来说，就是在XML中设置合适的属性，让系统知道哪个文件是新的、哪个是被替换的。很多新手会在这里栽跟头——文件是上传了，但因为没设置好替代关系，审评老师看到的还是旧版本。
还有一种情况是"撤报后重报"。这时候版本号怎么处理？其实跟第一次提交的逻辑一样，从1.0开始就好。但要注意把之前申报的编号信息保留好，方便审评老师追溯。
另外就是"局部更新"。有时候你只需要更新某个章节的内容，其他部分保持不变。这时候版本号的更新范围就局限在那个章节对应的文件上，不要为了省事把所有文件的版本号都统一升一遍。一方面这会给审评老师造成困扰，另一方面也会增加后续管理的复杂度。
在我接触过的项目里，那些版本号管理做得好的团队，往往都有一个共同特点：在项目启动之初就把版本号规则写在纸面上，让所有参与文件编写的人都知道该怎么编号。
这个规则可以很简单，比如就几条：主版本号用于重大变更、次版本号用于小幅修订、版本号变更必须同步更新文件属性页、发布前必须经过双人核对。把这些要求形成文档，每次项目启动时过一遍，比出了问题再补救强得多。
还有一点提醒：版本号的命名最好有个"中央数据库"，哪怕是个简单的Excel表格也行。记录下每个版本的发布时间、主要变更内容、负责人的名字。这样一旦有疑问，翻一翻记录就能搞清楚，比凭记忆靠谱多了。
康茂峰在内部管理项目时，这部分工作通常由专门的文档管理专员负责。不是说不信任项目组的同事，而是文档管理确实需要专人专职，交叉管理才能最大程度避免遗漏。
eCTD电子提交这事儿，说难确实难，但把每一个环节拆开来看，也没有那么邪乎。版本号管理就是其中一个看似不起眼、但影响很大的环节。希望今天聊的这些，对正在做eCTD申报的朋友们有点帮助。
如果你在实际操作中遇到什么具体问题，欢迎一起交流。 규제事务这条路本来就是边走边学的，谁都是从新手过来的。希望大家的申报之路都顺顺利利的。
