说到eCTD文档归档这个话题，我想先讲讲自己的经历。前几年第一次负责一个原料药项目的eCTD申报时天真地以为，只要把PDF文件按要求命名、放进对应的文件夹结构，这事儿就差不多完成了。直到后来药监部门的审评老师提出补正资料的要求，我才发现当初存的那些文档根本没法快速调取——版本混乱、关联关系不清、签署记录缺失，那段时间真的焦头烂额。
后来跟行业里的前辈请教，才慢慢明白eCTD文档的归档保存和最初的申报准备完全是两码事。申报是把文档"交出去"，而归档是把文档"管起来"，管得好不好，直接关系到后面补充资料、变更申报、甚至项目交接时的效率。今天这篇文章，我想把自己踩过的坑和后来学到经验整理一下，说说eCTD发布后电子文档归档保存到底应该怎么做。
在具体操作之前，我觉得有必要先把概念理清楚。很多朋友会把eCTD申报和eCTD归档混为一谈，其实两者侧重点不太一样。
eCTD，全称是Electronic Common Technical Document，也就是电子化通用技术文档。它是一套标准化的文档组织框架，把化学、生产、质量控制、临床研究、非临床研究这些模块的内容用统一的结构和格式来呈现。申报时，我们需要按照这个框架把文档组装成特定的层级结构，然后通过指定的方式提交给监管机构。
而归档呢，简单说就是把这些已经提交的文档以及相关的支持性文件，系统性地保存起来，并且要保证后续能够准确地检索、使用和追溯。这里容易忽略的一点是：归档不仅仅是保存最终提交的PDF文件，还包括底稿、源文件、审批记录、版本变更历史等等一系列"过程痕迹"。这些看似繁琐的东西，在某些时刻可能会成为救命稻草。
我见过不少项目在归档时手忙脚乱，根本原因往往是申报阶段就没有做好文档管理。所以如果时间允许，我建议在eCTD申报的推进过程中就开始为归档做铺垫。
命名规范这件事，看起来简单，但真正能坚持做得好的团队其实不多。我的经验是，命名规则要在项目启动时就确定下来，然后强制执行。好的命名应该包含足够的识别信息，比如模块编号、文档类型、版本号、日期等关键要素。
举个子目录结构：
| 目录层级 | 说明 |
| m1 | 行政性文档 |
| m2 | CTD概要文档 |
| m3 | 质量部分文档 |
| m4 | 非临床研究报告 |
| m5 | 临床研究报告 |
每个模块下面的文件命名可以采用"模块编号-章节编号-文档名称-版本号"的形式，比如"m3-3.2.P-产品质量标准-001"这样的格式。版本号最好采用三位数字，比如V001、V002，这样排序时不会出现V1.2排在V1.10前面的尴尬情况。
这个区分非常重要。在申报过程中，文档会经历无数次修改，如果把每个版本都混在一起保存，最后肯定会乱成一锅粥。我的做法是建立两个独立的文件夹体系：一个叫"Submission"，专门存放最终提交给监管机构的版本；另一个叫"Working"，存放申报过程中产生的所有中间版本、讨论稿、批注稿等等。
这样做的好处是显而易见的：归档时只需要处理"Submission"里的内容，而"Working"可以作为过程记录另行保存，既保证了归档库的干净整洁，又保留了完整的过程痕迹。
eCTD文档中有很多需要签署的文件，比如授权委托书、研究报告的扉页、检验报告单等等。这些原始签署文件一定要单独归档保管，不能只存扫描件。一方面是因为有些监管机构会要求提供原始文件备查；另一方面，签署文件的复印件在法律效力上确实不如原件。
建议用一个专门的文件夹存放所有签署文件的扫描件和对应的原件清单，清单上要注明文件的用途、保存位置、保管责任人这些信息。康茂峰这类专业服务团队在协助项目归档时，通常也会特别强调这一点，因为签署文件的完整性直接关系到整个申报档案的可追溯性。
做好准备工作后，真正进入归档环节时，我给自己定了一个简单的评判标准：归档后的文档，能不能在五分钟内找到任意一份指定的文件？如果能，那归档工作基本合格；如果不能，那就说明还有改进空间。
围绕这个目标，我总结了三个核心原则。
eCTD本身就有严格的目录结构，这个结构其实就是最好的归档骨架。我建议直接沿用申报时的目录结构，最多在根目录下增加几个辅助文件夹，比如"04-ArchiveMetadata"用于存放归档说明和元数据文件，"05-Signatures"用于存放签署记录，"06-ChangeLog"用于存放版本变更日志。
具体来说，一个完整的归档结构可能是这样的：
每个一级文件夹下面再按照申报时的章节结构细分，这样不管过了多久，都能快速定位到目标文件。
这一点是很多团队容易忽略的。一份文档从初稿到终版，可能经历了几十次修改，如果不做记录，后续想要追溯"某个数据是什么时候改的、为什么改的"就完全不可能了。
版本变更记录可以做得简单些，但一定要包含几个关键信息：版本号、修改日期、修改人、修改内容摘要、批准人。我一般会用Excel或Word做个简单的变更日志模板，每次文档更新时顺手填一下，这个动作花不了多少时间，但后续能帮上大忙。
复杂一些的项目，还可以考虑用专业的文档管理系统来自动追踪版本变化。不过对于大多数中小型项目来说，手动维护的变更日志配合规范的命名规则，基本就够用了。
eCTD提交前，通常会用专门的验证工具检查文档结构、链接完整性、书签有效性等等。验证工具生成的报告一定要保存好，这不仅是归档完整性的一部分，在后续遇到问题时也能作为参考依据。
另外，提交成功的回执、监管机构的收文编号、提交时间这些信息也要记录清楚。如果是通过电子提交平台操作的，平台的提交记录截图或者导出文件都可以一并归档。这些信息在后续查询申报状态、跟进审评进度时都会用到。
归档工作做完之后，并不意味着就万事大吉了。电子文档的长期保存其实是个持续性的话题，这里分享几个我自己的做法。
关于存储介质，我的建议是不要把鸡蛋放在一个篮子里。至少要保留两份完全独立的备份，一份放在本地服务器或硬盘上，另一份放在异地或云端存储。重要的项目，我甚至会刻成光盘再保存一份，因为光盘在防病毒和防误删方面有自己的优势。
备份这件事最怕的就是"只备份不检查"。我一般每隔半年会做一次备份完整性的抽查，随机抽取一些文件检查能否正常打开。有一年我就发现某次备份用的硬盘有个别扇区损坏了，幸好转储得及时，没有造成损失。
eCTD规范要求文档采用PDF格式，这个选择是很有道理的，PDF的跨平台性和长期稳定性都经过了时间的验证。但即便是PDF，也要注意几个问题：首先，使用的PDF版本不要太新，以免老版本的阅读器打不开；其次，尽量避免使用特殊的字体嵌套，如果文档中使用了监管机构系统中没有的字体，替换后可能导致内容显示异常；还有，提交前一定要把所有外部链接、动态元素清理干净，这些东西在长期保存过程中最容易出问题。
源文件 тоже 要保存一份。Word、Excel这些源文件虽然不如PDF稳定，但万一后续需要修改或重新排版，有源文件会方便很多。建议源文件和PDF版本分开归档，各自保持独立。
电子存储介质的寿命比想象中短很多。硬盘的寿命通常是三到五年，光盘好一些但也就五到十年。所以对于长期保存的项目，建议每隔三五年就做一次存储介质的更新，把数据迁移到新的介质上。这个过程中顺便做一次完整性和可读性检查，确保数据没有损坏。
康茂峰这类服务提供方在协助客户做项目归档时，通常会提供介质保管的建议和定期检查的服务提醒，这对于人手有限的中小型团队来说还是很有价值的。
在归档实践中，我遇到过几个高频问题，这里顺便说说自己的应对思路。
第一个问题是文档版本对应关系混乱。有时候一个章节可能同时存在多个版本的文件，文件名里也没标注清楚区别，结果归档时搞不清楚哪个是最终提交版。我的解决办法是在归档前做一份"文件清单对照表"，列清每个位置对应的最终文件名，避免混淆。
第二个问题是关联文件丢失。eCTD文档之间有很多交叉引用，如果只保存了最终提交版本，那些被替换下去但可能被引用的旧版本就找不到了。解决方法是在归档说明中明确标注引用关系，并在变更日志里记录每次替换的详细信息。
第三个问题是存储空间管理。有些项目做了好几年，归档文件夹动辄几十G甚至上百G，检索起来很不方便。我的做法是按年份或阶段做子目录划分，并且在每个子目录里放一个索引文件，方便快速浏览内容结构。
回过头来看，eCTD文档归档这项工作，确实不像申报准备那样有明确的截止日期和验收标准，但它对项目长期管理的价值是实实在在的。我自己就曾经受益于规范的归档——某次项目交接时，新接手的同事需要调取三年前的一份研究资料，正是因为归档时做了完整的版本记录和索引清单，整个过程只用了不到半小时就找到了目标文件。
当然，我也不是每次都能做得完美。之前有个项目因为赶进度，归档工作做得比较粗糙，后来需要补充资料时花了整整两天来整理、核对，那次教训让我更加确信归档这件事不能拖、不能省。
如果你所在的公司或团队还没有建立规范的eCTD归档流程，不妨从下一个项目开始试着做起来。不用一步到位，可以先从最基本的文档命名规范和版本记录开始，逐步完善。好的归档习惯一旦建立，后续会越来越轻松。
