最近有不少同行问我，eCTD申报提交之后，当初那些文件到底该怎么查看版本历史。说实话，这个问题我刚入行那会儿也折腾了好久，看目录结构看得云里雾里，后来慢慢摸索出来了些门道。今天就把我这些年积累的经验分享出来，希望能帮到正在摸索的朋友们。
eCTD这玩意儿，说白了就是一套电子申报的规范，里面的文件组织方式有它自己的逻辑。刚接触的人可能会觉得目录结构复杂得要命，但其实只要掌握了几个关键文件，查看版本历史这件事就会变得清晰很多。
在聊具体怎么查看之前，我想先说说为什么这个问题值得专门拿出来讲。药品申报不是一次性的事情，从最开始的临床试验申请，到后面的上市申请，再到上市后的补充申请，同一个产品可能会提交几十次eCTD申报。每次提交都会涉及文件的增删改，如果你不能清楚地了解每个文件的历史变更，那到了审核阶段就很被动了。
我见过有些公司因为文件版本管理混乱，最后找不到某个文件当初为什么被修改过，导致在回复审评意见的时候浪费了大量时间核对。所以养成查看版本历史的习惯，不只是为了应付监管机构的审查，更是为了自己的工作能够追溯、可控。
另外从监管的角度来说，药品电子申报技术规范里对文件管理是有明确要求的。每一个提交的文件都需要能够追溯其变更历史，这也是eCTD格式设计的初衷之一。理解了这一点，你就不会觉得查看版本历史是件可有可无的事了。
好了，言归正传。查看eCTD文件版本历史，最核心的途径就是通过XML属性文档。这个文件通常叫做m1-regions.xml或者类似的命名方式，里面记录了整个申报结构中每个文件的状态信息。
你可能已经注意到了，在eCTD目录的根目录下有一个region文件夹，里面就藏着这个关键文件。用文本编辑器打开它，你会看到类似这样的结构：
| 标签名称 | 含义说明 |
| modified-file | 本次提交新增或修改的文件 |
| new-file | 首次提交的新文件 |
| deleted-file | 本次提交删除的文件 |
| replaced-by | 文件被哪个文件替代 |
这个XML文件的价值在于，它把整个申报的生命周期都记录下来了。你打开看看就能知道，哪些文件是这次新加的，哪些文件是上次就存在但这次被修改过的，哪些文件已经被彻底删掉了。对于每个被修改的文件，XML里还会标注修改的类型和对应的序列号。
举个实际的例子，假设你正在准备一个补充申请，打开m1-regions.xml之后，如果看到某个临床研究报告被标记为modified-file，那你就能立刻知道这个文件不是第一次提交了，之前已经存在过一个版本。这时候如果你想看它之前长什么样，就需要找到上一次包含这个文件的序列来对比。
这里有个小技巧，XML文件里的序列号对应的是eCTD的序列号。康茂峰在协助客户进行eCTD申报的时候，通常会建议在项目初期就建立好序列归档的习惯，这样后期追溯起来会方便很多。
除了region文件夹里的XML文档，index.xml和index-md5.txt这两个文件也是查看版本历史的重要依据。它们位于eCTD目录结构的不同层级，索引了整个申报包里的文件清单和校验和信息。
index-md5.txt这个文件特别有意思，它记录了每个文件的MD5哈希值。你可能会问，这跟版本历史有什么关系呢？关系大了去了。同一个文件在不同序列里可能看起来内容差不多，但通过对比MD5值，你就能精确地判断文件是否真的被修改过还是只是位置变了。
我之前遇到过一种情况，某个文件在序列001里存在，序列002里也声称存在，但仔细对比MD5值之后发现，两个序列里的文件内容其实不一样。这就是版本差异的精确认证方式，光看文件名是看不出来的。
有时候，光看XML文件可能会觉得不够直观。那你可以直接看目录结构本身，eCTD的目录设计其实也暗含了版本信息。
标准的eCTD目录结构中，每个序列都有自己独立的文件夹。打开sequences文件夹，里面按照序列号依次排列着每次提交的内容。每次提交的文件夹里会有一个m1-regions.xml，同时在每个模块文件夹比如m1、m2、m3里面，也会有对应的index.xml文件。
这种层级结构的设计，让版本对比变得有章可循。假设你要看某个文件在序列003和序列005之间发生了什么变化，你可以分别打开这两个序列里的index.xml，搜索这个文件的路径，对比它的状态标识和校验和信息。
有经验的eCTD操作人员通常会建立一个Excel对比表，把关键文件在各个序列中的状态列出来。这样做的好处是可视化程度高，一眼就能看出变化趋势。特别是在处理大型申报项目的时候，几十个文件分散在十几个序列里，没有这样一个汇总表格，查找效率会很低。
说了这么多理论的东西，我来说几个实际工作中经常遇到的场景，你可能更有代入感。
审评期间，监管机构发来问讯，要求解释某份研究报告为什么在补充申请中做了修改。这时候你需要快速定位到这份文件在历次提交中的变化。首先在m1-regions.xml中搜索这个文件，看看它从哪个序列开始出现，在哪些序列被标记为修改。
找到对应序列之后，打开index-md5.txt对比该文件在各序列中的校验和值，确认修改是否真实发生。然后调取修改前的文件版本，对比两个版本的差异，准备解释说明。整个过程环环相扣，每一步都需要依赖版本历史信息。
在递交新序列之前，你需要确保本次提交的文件与之前的序列保持正确的继承关系。这时候就要核对m1-regions.xml中的文件状态设置是否正确，有没有漏掉的modified-file标识，有没有错误地标记了new-file。
康茂峰的技术团队在协助客户进行序列递交时，通常会制作一份变更说明文档，里面详细列出本次提交涉及的所有文件变更。这份文档的原始数据就来自于对index.xml和m1-regions.xml的分析。
这种情况也很常见，一个项目做到一半换了负责人，新接手的人需要快速了解项目历史。这时候历次提交的m1-regions.xml就是最好的入门资料。按时间顺序浏览这些XML文件，配合index-md5.txt的校验和比对，很快就能建立起对整个申报历史的认知。
我建议每个eCTD项目都维护一份项目说明文档，记录每次递交的主要内容和变更要点。虽然这个文档是额外的维护成本，但在大规模申报项目中，这个投资绝对值得。
聊完了技术层面的操作方法，我想分享几点这些年工作下来对版本管理的理解。
第一，版本管理要从申报之前就开始。很多问题其实是出在申报前的文件管理上，如果文件系统本身混乱不堪，转换成eCTD格式之后只会更乱。所以在准备申报文件的时候，就要建立好版本命名的规范，比如在文件名中加入版本号或者日期标识。
第二，保留好每一次递交的完整存档。eCTD序列一旦提交，后续是不能再修改的。这意味着每一次递交都是项目历史的一个快照，务必完整保存。我见过有些公司为了节省存储空间，定期清理旧的序列文件夹，结果后来需要追溯历史时后悔莫及。
第三，善用工具辅助对比。手工对比大量文件既耗时又容易出错，市面上有一些专门用于eCTD文件对比的工具，可以自动识别两个序列之间的差异并生成报告。如果你的项目经常涉及eCTD申报，这类工具是值得投资的。
第四，定期回顾和总结。每次递交完成之后，花点时间回顾一下这次递交的版本变化，思考有没有什么可以优化的地方。这样积累下来，对eCTD整个体系的理解会越来越深，操作也会越来越熟练。
eCTD文件版本历史的查看，说难不难，说简单也不简单。关键在于理解背后的逻辑，知道该看哪些文件、怎么看。XML属性文档是核心，index.xml和index-md5.txt是重要补充，再加上对目录结构的熟悉，基本就能应付大多数场景了。
如果你正在为eCTD申报的版本管理发愁，不妨先从手头的项目开始，试着打开那些XML文件看看里面的内容。看得多了，自然就会形成自己的理解。eCTD这东西，实践出真知。
希望这篇文章对你有帮助。如果在实际操作中遇到什么问题，欢迎交流讨论。
