記得我第一次接觸eCTD電子遞交的時候，面對那個看起來平平無奇的序列號字段，心里其實有點懵。這不就是一串數字嗎？有什么大不了的？后來真正上手操作了，才發現自己當初有多天真。序列號這件事，看起來簡單，里面的講究可真不少。今天就把我這些年踩過的坑、積累的經驗分享給大家，希望能幫正在這條路上摸索的朋友們少走些彎路。
在正式開始之前，我想先說明一下本文的定位。這篇文章不會去翻來覆去講eCTD的基本概念，那些內容官方文檔里寫得清清楚楚。我要聊的是實操層面的東西——當你拿到一個序列號為0000的原始遞交包之后，接下來每一次更新、每一個補件，序列號到底該怎么遞增。這事兒聽起來簡單，但真正做起來的時候，各種邊界情況能把人逼瘋。
eCTD里的序列號（Sequence Number），說白了就是給每一次遞交版本貼的標簽。它不是隨便編的，藥品監管機構對此有明確的規范要求。在中國，國家藥品監督管理局藥品審評中心（CDE）有詳細的技術規范；在美國，FDA的eCTD技術規范和行業指南也對序列號的使用提出了具體要求。歐洲那邊EMA同樣有自己的規定。
最核心的規則其實就一條：每一次向監管機構提交的新版本文檔，都必須使用一個新的、遞增的序列號。這個遞增是相對于你之前提交的所有版本而言的，而不是相對于每次獨立的提交動作。聽起來有點繞，我舉個例子你就明白了。
假設你的原始遞交使用了0000這個序列號。之后你提交了一個補件，這個補件的序列號應該是0001。再之后你又提交了另一個獨立的更新，這時候要用0002。簡單來說，序列號就像一個只會往上走的臺階，每登高一步，數字就要加一，永遠不能回頭，也不能跳級。
很多朋友問過我，首次遞交應該從哪個序列號開始？是0還是1？關于這個問題，不同地區的要求還不太一樣。
在國內，根據CDE的規定，原始遞交建議使用0000作為起始序列號。這個0看起來不起眼，但它是個信號，告訴審評人員這是你的基準版本。后面的每一次更新和補正，都建立在這個基礎之上。
而在美國，FDA對首次遞交的序列號沒有強制要求從0開始，你完全可以從0001甚至更高的數字起步。但這里有個隱藏的注意點：如果你的產品在FDA那邊已經有歷史遞交記錄了，新一輪的eCTD遞交需要延續之前的序列號體系，不能自己另起爐灶重新計數。這一點特別容易被忽略，我見過不少企業因為這個原因被打回來重做。
在國際多中心研究中，如果你同時向多個監管機構遞交，要注意各地區的序列號起始規則可能不同步。建議在項目啟動之初就建立一個全局的序列號管理表格，把每個地區的序列號狀態都記錄清楚，不然到后期對賬的時候會發現各種混亂。
序列號的遞增不是憑空發生的，它總是伴隨著具體的遞交行為。讓我來拆解一下幾種最常見的場景，看看每種情況下序列號該怎么處理。
補正是最常見的遞增場景。當你收到監管機構的補充資料通知后，在規定時間內提交補正文件，這時候需要使用下一個遞增的序列號。比如你原始遞交是0000，補正一次就用0001，再補正就用0002，以此類推。
這里有個細節需要特別注意：每一次補正，不管內容多少、文件多少，都必須使用一個全新的序列號。不能因為這次補正只改了一個文件，就想著和上次共用一個序列號。監管系統是按序列號來識別版本迭代的，序列號不變就意味著版本沒更新，審評人員不會去仔細看你到底改了什么的。
當你的藥品獲批之后，如果需要增加新適應癥、修改說明書、增加規格等等，這些補充申請雖然是一個新的審批流程，但在eCTD結構上，它仍然會建立在前一次成功遞交的基礎之上嗎？答案是不一定。
補充申請是否需要延續原序列號，取決于監管機構的具體要求。在國內，CDE對于補充申請通常是要求重新開始序列號計數。也就是說，你的補充申請會作為一個全新的eCTD遞交包，序列號從0000重新開始。但在美國，FDA的情況可能不同，補充申請可能會延續之前的序列號體系。
我的建議是，每次提交補充申請之前，先查看一下對應監管機構最新的eCTD遞交指南，或者直接發郵件咨詢確認。這個確認動作花不了多少時間，但能避免后續很多麻煩。
eCTD的結構中，模塊一是地區行政信息，包括申請表、證明函、授權委托書等等。這部分內容的更新相對頻繁，比如公司地址變了、法人代表換了、授權簽字人換了，這些都需要在模塊一中體現。
模塊一的更新要不要遞增序列號？答案很明確：要。只要你對eCTD文檔包做了任何修改，包括模塊一中看似很小的變動，都需要使用新的序列號重新生成并提交整個文檔包。監管系統不會因為你只改了模塊一就網開一面，它認定的是整個eCTD版本的更迭。
實際操作中，我見過有些企業為了省事，把模塊一的更新和模塊三的技術資料更新放在同一次遞交中一起提交。這樣沒問題，但如果你只需要更新模塊一，那也必須單獨提交一次新的序列號版本。不要因為覺得"只改了個地址就提交一次"太麻煩而心存僥幸，審評系統可不會幫你判斷修改內容的重要性。
講了這么多規則，我們來聊點實操層面的東西。序列號管理看起來是小事，但在實際項目中，要管的事情可比想象中多得多。
一個好的序列號追蹤表應該包含哪些信息？我整理了一個表格框架，大家可以根據自己的實際需求調整使用：
| 序列號 | 提交日期 | 提交類型 | 主要變更內容 | 監管機構反饋 |
| 0000 | 2024-01-15 | 原始遞交 | 新藥臨床試驗申請全套資料 | 待審評 |
| 0001 | 2024-03-20 | 補正 | 回復CDE第1次發補通知，補充穩定性數據 | 審評中 |
| 0002 | 2024-05-10 | 補正 | 回復CDE第2次發補通知，更新研究者手冊 | 補充資料已接收 |
這個表格看起來簡單，但它能幫你把每一次序列號變更的前因后果都記錄得清清楚楚。到了項目后期，當你想查某個歷史版本的細節時，不用翻郵箱翻文件夾，在這個表里一目了然。
如果你同時向多個地區的監管機構遞交，可能會遇到一個有趣的問題：序列號的遞增到底以哪個地區的提交時間為準？
舉個例子，你在國內早上提交了序列號0001的補正，同一天晚上美國那邊也需要提交一個更新。這時候美國的序列號應該是繼續用0001呢，還是需要用0002？
理論上，不同監管體系之間的序列號是相互獨立的。但為了內部管理方便，建議你在項目初期就確定一個統一的序列號遞增規則，比如統一以北京時間為準，或者統一以格林尼治時間為準。這樣團隊里的所有人都知道下一個序列號應該用哪個，不會出現各自為政的情況。
序列號跳號這種事，說起來有點可笑，但真的不少見。常見于什么情況呢？比如某個序列號的文件已經生成了，但因為各種原因最終沒有提交，時間久了大家就忘了，繼續用下一個數字。等后來查歷史記錄的時候才發現中間空了一個號。
重復的問題更麻煩。有時候因為系統故障或者操作失誤，同一個序列號被提交了兩次。雖然大多數監管系統會拒絕重復的序列號提交，但這并不意味著你可以不當回事。誰知道系統什么時候抽風呢？
我的建議是，序列號的使用狀態要實時更新，最好有一個centralized的系統來管理，不要依賴每個人自己記自己的。康茂峰在eCTD遞交服務中就會幫客戶建立嚴格的序列號管控機制，從根源上杜絕這些問題。
規則是死的，人是活的。實際工作中，總會遇到一些不按常理出牌的情況，這里我分享幾個特殊情況的處理經驗。
如果你的遞交被監管機構拒絕了，序列號該怎么處理？這個要分情況看。
如果是因為技術問題被拒絕，需要重新補充資料后再次提交，這時候應該使用新的序列號。因為你的這份申請在本質上已經"死"了，新提交的是一份全新的申請。如果是因為行政問題被拒絕（比如文件簽章不符合要求），有時候可以在修正后使用原序列號重新提交，但這需要事先得到監管機構的確認。
最穩妥的做法是：被拒絕后，先別急著重新準備材料，第一時間和監管機構溝通，確認后續提交的具體要求，包括序列號的使用規則。
主動撤回的情況在研發過程中其實不算少見。有時候是數據不夠充分，主動撤回總比被拒強；有時候是戰略調整，需要暫緩某個項目的推進。
撤回后如果重新提交，序列號通常需要重新計數。也就是說，你之前用到的序列號作廢，新的申請從0000或0001開始。當然，具體的規則還是要以監管機構的要求為準。
這里我想特別提醒一點：撤回記錄是會被保留的。如果你多次撤回同一個產品，可能會影響審評人員對你的印象。所以在決定撤回之前，還是要慎重考慮，盡可能把問題解決在提交之前。
從臨床試驗申請（IND）到新藥上市申請（NDA），中間的序列號怎么銜接？這是個挺常見的問題。
簡單來說，這是兩個獨立的申報流程，序列號體系通常也是獨立的。臨床試驗期間的所有遞交，包括補充試驗方案、年度報告、安全報告等，用的都是臨床階段的序列號。而一旦進入上市申請階段，序列號會重新開始計數。
但也有例外情況。有些監管機構會要求把臨床階段的部分資料以附件形式納入上市申請，這時候如果兩邊序列號體系不統一，可能需要做一些映射工作。建議在啟動上市申請之前，提前和監管機構溝通確認具體要求。
聊了這么多關于序列號遞增的細節，我有點擔心會不會把大家搞得更暈了。其實核心思想就一條：每一次有實質內容的更新，都需要一個新的序列號。把這條原則記住，再遇到拿不準的情況，你就不會慌。
序列號管理這件事，看起來是eCTD遞交里最不起眼的小環節，但它串聯的是你整個研發歷程的文檔脈絡。管好了這個看似簡單的東西，后面的工作會順暢很多。
如果你在實際操作中遇到了什么棘手的問題，或者有什么獨特的經驗想分享，歡迎一起交流。研發這條路，大家一起走，才能走得更遠。
