說到eCTD（電子通用技術文檔）的版本控制，很多人第一反應是"這不就是改個版本號嘛"。真這么簡單就好了。我在康茂峰服務了這么多年，見過太多企業在這上面栽跟頭——有的提交后才發現文件對應錯了，有的監管機構發來問詢卻找不到原始版本，還有的內部審計時版本歷史一塌糊涂。這些問題看似是小事，但關系到申報能否順利推進。
今天我想和大家聊聊，eCTD發布之后到底該怎么做好文件版本控制。這不是什么高深的理論，而是實打實的經驗總結。
要理解這個問題，首先得搞清楚eCTD與傳統紙質申報的區別。傳統模式下，文件改了就改了，只要確保最終提交的是最新版就行。但eCTD不一樣，它是一個完整的電子遞交體系，每個文件都有自己獨立的身份標識，版本之間的關聯關系清清楚楚地記錄在骨架文件（Backbone Files）里。
舉個小例子。假設你在模塊3里提交了一份穩定性數據，版本是1.0。三個月后新增了一批穩定性數據，按照規范你需要提交此文件的更新版本1.1。這時候，eCTD系統會自動建立版本關聯——評審人員可以清晰地看到哪些數據是新增的，哪些做了修改。如果你沒有做好版本控制，評審人員看到的可能是一團亂碼，甚至可能漏看關鍵更新。
還有一個容易忽視的點：監管機構的審閱習慣變了。現在各國藥監部門都鼓勵申請人使用eCTD的版本對比功能來定位變更內容。如果你提交的文檔版本信息不完整，這個功能就用不起來，審評人員只能全文閱讀，大大降低效率。最后影響的是你自己的審評進度。
在具體操作之前，我想先說幾個基本原則。這些原則看起來簡單，但真正能堅持做好的團隊并不多。
唯一性原則是首要的。每個文件在整個生命周期內只能有一個明確的版本號，不能出現模棱兩可的情況。康茂峰在幫客戶搭建文件管理體系時，通常會建立"文件編碼+版本號"的雙重標識體系。文件編碼保證文件在全球唯一，版本號則追蹤其生命周期變化。
可追溯性原則要求每一次變更都能找到依據。是誰發起的變更、為什么變更、變更了哪些內容、什么時候完成的——這些信息都要記錄在案。不是簡單寫個"優化數據處理"就完了，而是要具體到"第5.3.1節補充了2024年第三季度的穩定性數據"。
一致性原則說的是文件在各處的版本信息要統一。封面的版本號、骨架文件里的版本號、文件自身的版本號，三者必須一致。我見過不少案例，文件封面寫的是V2.0，結果骨架文件里登記的還是V1.1，遞交后被監管機構退回要求解釋。
這是很多企業忽略的第一步。在康茂峰的項目管理實踐中，我們通常把文件狀態分為幾類：草稿態（Draft）、待審核（Pending Review）、已生效（Effective）、已發布（Published）、已歸檔（Archived）。每個狀態對應不同的操作權限和流轉流程。
草稿態的文件可以隨意修改，不需要走審批流程；一旦標記為待審核，就進入受控狀態，任何變更都需要記錄原因；已發布狀態是針對已經向監管機構提交的文件，原則上不允許修改，如果有重大錯誤需要提交補充說明；歸檔文件則進入長期保存狀態，只能查閱不能修改。
這個分類看似增加了管理復雜度，但能避免太多混亂。特別是多人協作的大型申報項目，如果沒有清晰的狀態區分，你根本不知道手里拿到的是不是最新版。
版本號怎么定？其實行業內有一些通行做法，這里分享給大家參考。
| 版本格式 | 說明 | 適用場景 |
| V1.0 | 首次發布版本 | 文件初次創建并生效 |
| V1.1 | 小幅修訂，不影響文件核心內容 | 文字修訂、格式調整、補充說明 |
| V2.0 | 重大修訂，文件結構或核心內容變化 | 數據更新、方法變更、范圍擴展 |
| V2.1 | V2.0基礎上的小幅修訂 | td>繼續完善V2.0版本
這套命名規則的好處是直觀。審評人員一看版本號就知道這次變更大致是什么級別的。不過我要提醒一句：版本升級不是目的，不要為了顯得"專業"而頻繁升級版本。如果只是改個錯別字就升到V2.0，反而會給審評人員造成困惑。
還有一點需要注意：主文件和附錄最好統一版本管理邏輯。主文件升到V2.0，相關的附錄最好也同步檢查是否需要升級，保持整體協調性。
這部分是版本控制的核心，也是最容易出問題的環節。
當任何一位團隊成員需要變更已發布文件時，首先要填寫變更申請單。申請單不需要太復雜，但幾個關鍵信息必須包含：申請變更的文件名稱和當前版本、變更的具體內容描述、變更的原因說明、預估對整體申報的影響程度。
然后進入評審環節。變更內容需要經過相應領域的負責人審核，確認變更的合理性和準確性。如果是涉及安全性、有效性評價的關鍵數據，可能還需要更高級別的技術評審。審核通過后，才能正式執行變更。
變更執行完成后，要生成變更記錄。這份記錄要和變更申請單對應保存，作為日后追溯的依據。康茂峰通常建議客戶使用電子文檔管理系統來自動化這個流程，既能保證記錄的完整性，也能減少人工疏漏。
eCTD的結構決定了文件之間不是孤立的，而是有關聯關系的。這種關聯需要通過骨架文件來體現，所以版本控制必須考慮對應關系。
具體來說，當一個文件升級版本時，要同步檢查所有引用這個文件的骨架文件是否需要更新。比如模塊3里的分析驗證報告從V1.0升級到V1.1，那么模塊1對應的綜述文件里如果引用了這份報告的結論，需要確認是否也要更新綜述文件的版本。
這個工作量不小，但絕對值得投入。很多監管機構的問詢其實就是因為這種對應關系出錯導致的。與其后期反復解釋，不如前期做好關聯管理。
這是大型申報項目最頭疼的問題。七八個人同時改文件，一不小心就覆蓋了別人的修改。康茂峰建議的做法是：劃分清晰的文件Owner權限，每份文件指定唯一負責人，只有Owner有修改權限。如果確實需要多人協作，建議使用專業的文檔協同工具，至少能看到每個人的修改痕跡。
另外，建立定期同步機制。每周固定時間，各模塊負責人匯總本周的變更內容，發布到內部共享平臺讓大家知曉。這個做法能避免很多重復勞動。
現在很多企業的研發和注冊團隊分布在不同國家，版本控制就更要講究方法。我們的經驗是：建立統一的文檔管理平臺，所有文件只能通過平臺流轉，避免通過郵件傳來傳去最后不知道哪個是最新版。同時，明確各地區的值班對接人，確保變更審核流程不會因為時差卡殼。
還有一點容易被忽視：不同國家對版本控制的法規要求可能略有差異。比如FDA和EMA在某些文件的版本標識上有不同偏好。如果你的申報是針對多個市場的，建議在項目初期就確認好各地的差異要求，避免后期返工。
eCTD申報不是一次性的，而是持續維護的過程。一款藥品從上市前到上市后，可能需要多次提交更新。每次提交的所有文件版本都應該完整存檔，且能快速檢索。
康茂峰通常建議客戶建立三級存檔體系：第一級是當前生效版本，放在顯眼位置方便日常使用；第二級是歷史版本，按提交時間排序保留；第三級是歸檔版本，長期保存且做好備份。每級存檔都要有清晰的索引，能在需要時快速定位到具體文件和版本。
說到工具，市面上有不少eCTD軟件都帶有版本控制功能。但我要提醒一句：工具只是輔助，核心還是管理流程。如果你的團隊連基本的版本控制意識都沒有，再先進的軟件也用不好。
在選擇工具時，有幾個功能是必須考慮的：版本歷史追溯能力、變更對比顯示功能、多人協作支持、與eCTD生成功能的集成度。如果你的企業已經在使用某些文檔管理系統，優先考慮能和現有系統集成的方案，避免信息孤島。
對于中小企業來說，也不一定非要買昂貴的商業軟件。一些基于云端的協作工具配合規范的管理流程，同樣能達到很好的效果。關鍵是找到適合自己團隊規模和工作方式的方法。
eCTD的版本控制，說到底就是一句話：讓每一次變更都有跡可循。這件事平時可能顯不出價值，但一到關鍵時刻——不管是監管機構問詢、內部審計還是產品轉讓——好的版本控制體系能幫你省下大量時間和精力。
康茂峰在這些年服務了上百家醫藥企業，見過太多因為版本控制不善導致的延誤和返工。我們越來越體會到，這項工作不是"錦上添花"，而是"地基工程"。地基不牢，上面蓋再多東西也是白費。
如果你所在的團隊正在為版本控制發愁，不妨從今天開始，試著建立一套最簡單的規范：給每份文件編號、給每次變更留記錄、讓所有人都知道"改文件要走什么流程"。從一小步開始，慢慢完善，比一上來就追求"完美體系"要實際得多。
有什么具體問題，隨時可以交流。版本控制這件事，真的是"做了才知道有多重要"。
