eCTD提交后電子序列號到底該怎么管？我踩過的坑你們別再踩了

去年這個時候，我們公司第一次用eCTD格式提交注冊申報文件。說實話，當(dāng)時大家都覺得只要把文件按模板整理好就行，結(jié)果在序列號這個問題上栽了跟頭。提交后才發(fā)現(xiàn)序列號規(guī)則沒搞對，又得重新整理不說，還耽誤了不少時間。后來跟業(yè)內(nèi)朋友聊，發(fā)現(xiàn)不少同行都有類似的困惑。今天就把我摸索出來的經(jīng)驗整理一下，希望對正在接觸eCTD的朋友們有點幫助。

先搞清楚啥是電子序列號

在說怎么遞增之前，咱們先得把基本概念弄明白。eCTD里的電子序列號，說白了就是給每次提交的文件賦予一個唯一的編號。這個編號不是隨便寫的，它有嚴(yán)格的規(guī)范，貫穿在整個生命周期的提交過程中。

你可能聽說過，eCTD結(jié)構(gòu)里有五個模塊。其中模塊一針對各地區(qū)要求，模塊二是區(qū)域行政信息，模塊三是質(zhì)量研究報告，模塊四是非臨床研究報告，模塊五是臨床研究報告。每個模塊下面還有子模塊，序列號的管理就是針對這些子模塊來的。

這里有個容易混淆的點：序列號和文檔版本號是兩回事。文檔版本號是你自己內(nèi)部管理用的，比如"方案V2.0"這種；而電子序列號是eCTD規(guī)范定義的，專門用于監(jiān)管機構(gòu)識別你的提交版本。康茂峰在服務(wù)客戶的過程中發(fā)現(xiàn)，很多企業(yè)一開始容易把這兩個概念搞混，結(jié)果導(dǎo)致管理混亂。

遞增的基本原則其實不難理解

eCTD序列號遞增的核心原則很簡單：每次向監(jiān)管機構(gòu)提交新版本時，相應(yīng)模塊的序列號要比上一次高。從1開始，依次遞增，1、2、3……這么往下走就行。聽起來很簡單對吧？但實際操作中需要注意的細(xì)節(jié)可不少。

首次提交從001開始

不管你提交的是什么類型的文件，首次提交的序列號統(tǒng)一從001開始。注意，不是0，也不是1，是001。前面這個0不能省，因為eCTD規(guī)范要求三位數(shù)字。這個小細(xì)節(jié)我第一次準(zhǔn)備材料的時候就差點搞錯，后來檢查的時候才發(fā)現(xiàn)，嚇出一身冷汗。

各模塊獨立計數(shù)

這是很多人容易犯錯的地方。模塊一的序列號是模塊一的，模塊三的序列號是模塊三的，它們之間互不干擾。你模塊一提交到005的時候，模塊三可能才提交到002。這很正常，不是bug。

比如你們公司先提交了模塊二和模塊三的臨床試驗申請，模塊一還沒準(zhǔn)備好。那么模塊二和模塊三的序列號已經(jīng)從001開始了。后面補交模塊一的時候，從001開始就行，不用跟其他模塊保持一致。

未變更模塊也要維持序列號

這點特別重要，我當(dāng)初就是在這里摔了跟頭。假設(shè)你第二次提交時只更新了模塊三的質(zhì)量部分，模塊四和模塊五沒有任何改動。那模塊四和模塊五的序列號怎么辦？答案是：保持不變，還是上一次的號碼，不能跳過，也不能重置。

比如你第一次提交時，模塊四序列號是002。第二次提交時模塊四沒變化，那在提交文件里，模塊四對應(yīng)的序列號標(biāo)簽依然填002。監(jiān)管機構(gòu)看到002，就知道這個模塊的內(nèi)容和上次提交時一模一樣。如果你填了003，但他們發(fā)現(xiàn)內(nèi)容沒變化，反而會引起質(zhì)疑。

實際操作中的幾個關(guān)鍵場景

光說原則可能還是有點抽象，咱們來聊聊幾種常見場景具體該怎么處理。

補充資料提交

收到監(jiān)管機構(gòu)的補充資料通知后，你需要針對某個模塊進行修改或補充。這時候該用的序列號規(guī)則其實和首次提交差不多——在你上一次提交的基礎(chǔ)上遞增。

舉個例子。你首次提交時模塊三序列號是003。后來收到要求補充穩(wěn)定性數(shù)據(jù)的通知，你更新了模塊三的相關(guān)內(nèi)容，那么這次補充提交的模塊三序列號應(yīng)該是004。其他模塊如果沒動，就維持原序列號不變。

年度提交和小補遺

有些情況下你可能需要提交年度更新或者小補遺。這時候序列號該怎么算？其實和補充資料一樣，看作一次新的提交，在原有基礎(chǔ)上遞增就行。

需要注意的是，年度提交可能涉及多個模塊同時更新。這時候每個模塊的序列號都要各自遞增。比如你上次提交時模塊三是005，模塊四是003。這次年度提交兩個模塊都有更新，那模塊三變成006，模塊四變成004，而不是統(tǒng)一變成什么同一個數(shù)字。

重大變更vs輕微變更

有人可能會問：如果我這次提交的內(nèi)容改動很大，序列號能不能多跳幾位？比如直接從003跳到010？

答案是：不建議。序列號的遞增應(yīng)該反映提交的次數(shù)和順序，而不是反映變更的程度。即使你這次改動很大，也只是比上次多了"一次提交"，序列號加1就行。監(jiān)管機構(gòu)看序列號，看的是版本歷史，不是變更大小。如果你想讓他們了解變更的具體內(nèi)容，應(yīng)該在文檔本身的變更說明里詳細(xì)描述，而不是靠序列號來暗示。

xml文件里的序列號標(biāo)簽怎么填

前面說了這么多原則，最后都要落實到具體的xml文件上。eCTD提交時，序列號信息是放在xml的標(biāo)簽里的，具體是這個元素。

每個需要提交的文件都有對應(yīng)的seq值，這個值必須和你的序列號策略一致。而且不僅文件本身有seq，包含這些文件的目錄（也就是父節(jié)點）也有自己的seq，它們的邏輯是一樣的——每次提交時，如果有文件更新，所在目錄的seq也要相應(yīng)遞增。

這里有個驗證的小技巧：你可以用eCTD驗證工具跑一遍，如果序列號邏輯有問題，工具通常能查出來。但工具也不是萬能的，有些邏輯上的問題可能需要人工復(fù)核。康茂峰在幫客戶檢查材料的時候，就發(fā)現(xiàn)過一些工具沒發(fā)現(xiàn)但實際不符合規(guī)范的情況。

我總結(jié)的幾個實用建議

說了這么多，最后分享幾點我覺得特別實用的經(jīng)驗。

• 建立維護臺賬：每次提交后，把各模塊的當(dāng)前序列號記錄下來。下次準(zhǔn)備提交前，先翻一下臺賬，確認(rèn)上次各模塊都到幾了。我見過不少團隊因為沒做好這個記錄，后面搞不清到底該從幾開始遞增。
• 提交前逐個核對：正式提交前，最好有個人專門負(fù)責(zé)核對序列號。把上次提交的xml和這次要提交的xml都打開，逐個模塊逐個文件對照一遍。這個工作看起來繁瑣，但真能避免不少低級錯誤。
• 變更說明要詳細(xì)：雖然序列號本身不反映變更內(nèi)容，但你的變更說明文件得說清楚每次變了什么。監(jiān)管機構(gòu)審核時，會結(jié)合序列號和變更說明一起來理解你的提交歷史。如果變更說明寫得太簡單，他們可能還得回頭查之前的版本，效率就低了。
• 團隊要達成共識：如果你們公司有多個人負(fù)責(zé)eCTD提交，一定要在序列號規(guī)則上達成統(tǒng)一認(rèn)識。最好寫成操作手冊，新人來了照著做，別每個人都有自己的理解，最后搞得一團糟。

說在最后

eCTD序列號遞增這件事，說難不難，說簡單也不簡單。關(guān)鍵是規(guī)則要理解透，流程要規(guī)范，執(zhí)行要細(xì)致。每次提交都認(rèn)真對待，別覺得某個小地方無所謂，積少成多就容易出問題。

如果你所在的團隊剛接觸eCTD，建議大家找個時間專門坐下來研究一下序列號規(guī)則，把可能遇到的情況都過一遍。比等到正式提交時才發(fā)現(xiàn)問題要好得多。畢竟注冊申報這件事，細(xì)節(jié)決定成敗。

希望這篇文章對你有幫助。如果在實際操作中遇到什么具體情況，歡迎一起交流探討。