說到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申報的朋友們有點幫助。
如果你在實際操作中遇到什么具體問題，歡迎一起交流。 ??事務這條路本來就是邊走邊學的，誰都是從新手過來的。希望大家的申報之路都順順利利的。
