先打破一個(gè)誤區(qū)。很多人一聽(tīng)到eCTD時(shí)間節(jié)點(diǎn)，就覺(jué)得這是個(gè)特別高精尖的技術(shù)活，得像發(fā)射火箭那樣掐著秒表算。其實(shí)吧，真沒(méi)這么復(fù)雜。
說(shuō)白了，eCTD（電子通用技術(shù)文檔）就是個(gè)標(biāo)準(zhǔn)化的電子文件夾，你什么時(shí)候往里面塞東西，塞多少，怎么告訴監(jiān)管方這是第幾次塞，這些就是時(shí)間節(jié)點(diǎn)要安排的事。
在康茂峰的日常項(xiàng)目里，我們見(jiàn)過(guò)太多客戶因?yàn)闀r(shí)間節(jié)點(diǎn)沒(méi)plan好，導(dǎo)致序列號(hào)亂成一鍋粥，最后不得不花大力氣返工。今天就用大白話，把這事兒掰開(kāi)了揉碎了講。
你可能在不少資料里看到過(guò)"Sequence"這個(gè)詞。別被它嚇到，這個(gè)序列號(hào)其實(shí)就跟你寫(xiě)日記標(biāo)注"第幾天"差不多。只不過(guò)eCTD要求，每次你往藥監(jiān)那邊遞材料，都得清楚地標(biāo)明：這是第幾次遞（序列號(hào)），這次遞的是新東西還是改舊東西（操作類型），以及這次遞的東西里，哪些是覆蓋上一次的。
這里有個(gè)容易搞混的點(diǎn)。很多人以為時(shí)間節(jié)點(diǎn)就是"我哪天點(diǎn)擊提交按鈕"。不對(duì)。真正的起點(diǎn)是你決定開(kāi)始準(zhǔn)備這個(gè)序列的那一刻。
舉個(gè)例子。假設(shè)你在做新藥申請(qǐng)，計(jì)劃12月1號(hào)正式提交。那你的時(shí)間節(jié)點(diǎn)至少得往前倒推兩個(gè)月：10月初就得確定這次序列的granularity（粒度），也就是這次提交要細(xì)化到什么程度。是要整卷替換，還是只替換某幾個(gè)文件？這個(gè)決定直接決定了后面兩周的工作量。
康茂峰的項(xiàng)目經(jīng)理通常會(huì)建議客戶畫(huà)一個(gè)倒推日歷。不是從提交日往后排，而是從提交日往前畫(huà)。比如：
你看，表面上是個(gè)12月1號(hào)的動(dòng)作，實(shí)際上11月1號(hào)就得開(kāi)始動(dòng)了。
這里得說(shuō)句實(shí)話，eCTD沒(méi)有萬(wàn)能時(shí)間表。你在做什么類型的申報(bào)，直接決定了你的時(shí)間節(jié)點(diǎn)密度。
這個(gè)階段特別像搭積木的初期。你第一次遞IND（序列號(hào)0000），可能就是個(gè)簡(jiǎn)單的申請(qǐng)報(bào)告，時(shí)間相對(duì)寬松。但一旦進(jìn)入臨床期間，每次遞交安全性更新報(bào)告（SUR）或者方案修正案，時(shí)間就很緊。
比如說(shuō)，你做了一個(gè)臨床試驗(yàn)方案變更，這個(gè)變更需要倫理委員會(huì)批準(zhǔn)，同時(shí)需要向CDE備案。eCTD的提交時(shí)間必須卡在倫理批件拿到之后，但在實(shí)際操作中，很多公司會(huì)陷入一個(gè)尷尬：倫理那邊還沒(méi)完全定稿，但eCTD序列已經(jīng)做到一半了。
康茂峰的經(jīng)驗(yàn)是，IND階段的時(shí)間節(jié)點(diǎn)要留雙通道。也就是說(shuō)，準(zhǔn)備eCTD電子文檔的思路要并行，但心里得清楚，eCTD要求的是"文件一旦入庫(kù)就不能動(dòng)"的嚴(yán)謹(jǐn)性。所以你在T-7日f(shuō)reeze的那個(gè)點(diǎn)，必須卡在你獲得最后一份簽字文件的同一天。
到了這個(gè)階段，時(shí)間節(jié)點(diǎn)就變成了交響樂(lè)指揮的角色。因?yàn)镹DA的eCTD通常不是一次遞完的，而是分模塊滾動(dòng)提交，或者在規(guī)定時(shí)間內(nèi)補(bǔ)交。
比如現(xiàn)在的Pre-NDA溝通機(jī)制。很多申請(qǐng)人會(huì)在正式提交NDA前，先遞一個(gè)Pre-NDA meeting request。這時(shí)候的時(shí)間節(jié)點(diǎn)要注意：如果你計(jì)劃在正式NDA里引用Pre-NDA會(huì)議上達(dá)成的共識(shí)，那你Pre-NDA的序列號(hào)（比如0010）和正式NDA的序列號(hào)（比如0020）之間，必須留有足夠的時(shí)間讓審評(píng)員閱讀，通常建議至少間隔一個(gè)月。
而且，NDA的模塊3（質(zhì)量部分）、模塊4（非臨床）、模塊5（臨床）往往是由不同團(tuán)隊(duì)準(zhǔn)備的。康茂峰見(jiàn)過(guò)太多案例：模塊5的團(tuán)隊(duì)覺(jué)得"反正還有兩周"，模塊3的團(tuán)隊(duì)卻已經(jīng)把文件封包了。結(jié)果一合并，時(shí)間戳對(duì)不上，整個(gè)序列得重做。
所以在這個(gè)階段，時(shí)間節(jié)點(diǎn)要細(xì)化到子模塊級(jí)別。你得有個(gè)總表：
| 子模塊 | 負(fù)責(zé)團(tuán)隊(duì) | 初稿截止 | eCTD轉(zhuǎn)化完成 | 交叉檢查 | 最終入庫(kù) |
| 3.2.S | CMC組 | 10月1日 | 10月5日 | 10月8日 | 10月10日 |
| 5.3.5 | 醫(yī)學(xué)組 | 10月3日 | 10月6日 | 10月9日 | 10月10日 |
| 1.0 | 注冊(cè)組 | 9月28日 | 10月4日 | 10月8日 | 10月10日 |
看著有點(diǎn)死板？但這是唯一能避免最后三天集體加班的方法。
這兩種最讓人頭疼的是基準(zhǔn)日（Reference Date）的確定。
比如你要變更生產(chǎn)工藝，這個(gè)變更的生效日期怎么定？eCTD要求你在序列里明確說(shuō)明這個(gè)lifecycle操作類型是"替換"（replace）還是"追加"（append）。如果是替換，時(shí)間節(jié)點(diǎn)就必須考慮：你替換進(jìn)去的文件，生效日期是哪天？是遞交流程的當(dāng)天，還是你實(shí)際開(kāi)始執(zhí)行新工藝的日期？
這里有個(gè)細(xì)節(jié)。康茂峰的技術(shù)團(tuán)隊(duì)發(fā)現(xiàn)，很多客戶會(huì)把"內(nèi)部生效日期"和"遞交日期"混在一起。比如說(shuō)，公司決定在2024年3月1日啟用新工藝，但eCTD拖到3月15日才遞。那你在序列的XML技術(shù)文件里，到底該寫(xiě)3月1日還是3月15日？
正確的做法是：看文件內(nèi)容。如果3月1日的已經(jīng)代表了當(dāng)前狀況，時(shí)間就是3月1日，但要在cover letter里說(shuō)明遞交延遲的原因。時(shí)間節(jié)點(diǎn)安排上，必須保證內(nèi)部執(zhí)行日期不早于遞交日期，除非經(jīng)過(guò)特別的批準(zhǔn)后執(zhí)行（implementation）安排。
說(shuō)完了業(yè)務(wù)邏輯，說(shuō)說(shuō)技術(shù)操作層面的時(shí)間節(jié)點(diǎn)。這部分最容易被低估，但往往決定成敗。
eCTD不是做好就能交的，得先過(guò)驗(yàn)證工具。中國(guó)的《eCTD技術(shù)規(guī)范》有一套完整的校驗(yàn)要求，包括PDF屬性、書(shū)簽、超鏈接、XML結(jié)構(gòu)等等。
很多團(tuán)隊(duì)把驗(yàn)證安排在最后一步，比如提交前一天。這是個(gè)大坑。
驗(yàn)證應(yīng)該分兩個(gè)階段。第一階段是中間驗(yàn)證，在你每完成一個(gè)模塊的時(shí)候就跑一遍，看看基本的PDF書(shū)簽、超鏈接有沒(méi)有斷。第二階段是最終驗(yàn)證，在T-3日跑全套。
為什么？因?yàn)轵?yàn)證報(bào)告里經(jīng)常會(huì)出現(xiàn)一些"灰色錯(cuò)誤"（比如某些hyperlinks指向的是外部網(wǎng)站，被標(biāo)記為warning）。你得留出T-2日來(lái)解釋這些warning，而不是在T-1日手忙腳亂地改。
如果你遞的是臨床數(shù)據(jù)，模塊5需要STF文件。這個(gè)東西就像給每個(gè)臨床試驗(yàn)貼標(biāo)簽，說(shuō)這是什么研究，什么階段。
做STF特別耗時(shí)間，因?yàn)槟愕煤藢?duì)每個(gè)study report的編號(hào)、版本、日期，確保跟登記的信息一致。
康茂峰建議把STF的準(zhǔn)備放在臨床試驗(yàn)報(bào)告定稿后一周內(nèi)就開(kāi)始，而不是等到模塊5整體編譯的時(shí)候。因?yàn)镾TF錯(cuò)了，整個(gè)模塊5的結(jié)構(gòu)就錯(cuò)了，返工成本極高。
審評(píng)過(guò)程中，如果收到補(bǔ)充資料通知，要求補(bǔ)充資料。這時(shí)候的時(shí)間節(jié)點(diǎn)是強(qiáng)制性的，比如要求80個(gè)工作日內(nèi)回復(fù)。
但eCTD的回復(fù)不是簡(jiǎn)單地把PDF郵件發(fā)過(guò)去，而是要編一個(gè)新的序列。這個(gè)序列號(hào)得接著之前的（比如上次是0025，這次就是0030），而且要在cover letter里明確引用IR的編號(hào)。
這里的時(shí)間陷阱是：很多人拿到補(bǔ)充通知后，急著寫(xiě)回復(fù)，卻忘了eCTD格式化的流程也需要時(shí)間。比如說(shuō)，你第60天的時(shí)候才把回復(fù)內(nèi)容寫(xiě)完，剩20天做eCTD轉(zhuǎn)化和驗(yàn)證，如果內(nèi)容復(fù)雜，很可能來(lái)不及。
康茂峰的標(biāo)準(zhǔn)操作是：收到通知當(dāng)天就建立序列文件夾，哪怕回復(fù)內(nèi)容還是空白。先把框架搭好，把引用編號(hào)填進(jìn)去，這樣后續(xù)工作就是填空，而不是從零開(kāi)始。
說(shuō)到底，eCTD的時(shí)間安排沒(méi)有標(biāo)準(zhǔn)答案，但有標(biāo)準(zhǔn)思路。
你可能會(huì)想，那我能不能把幾個(gè)變更打包在一個(gè)序列里遞交？技術(shù)上可以，但時(shí)間上你得想清楚：如果這些變更的生效日期不同，或者審批路徑不同（比如一個(gè)需要專家會(huì)，一個(gè)不需要），打包可能會(huì)導(dǎo)致部分進(jìn)度被拖累。這時(shí)候，拆分序列反而是更聰明的時(shí)間策略。
還有個(gè)小細(xì)節(jié)，很多人不知道。eCTD的遞交時(shí)間最好避開(kāi)周五下午。為什么？因?yàn)榧夹g(shù)支持團(tuán)隊(duì)在，萬(wàn)一系統(tǒng)報(bào)錯(cuò)、上傳失敗，你還有一個(gè)下午的時(shí)間處理。如果周五晚上提交，出了問(wèn)題就得panic整個(gè)周末。
另外，節(jié)假日前后也要小心。比如春節(jié)前最后一個(gè)工作日提交，審評(píng)系統(tǒng)可能不會(huì)立即給你回執(zhí)，而你心里會(huì)一直懸著。康茂峰一般會(huì)建議客戶在長(zhǎng)假前至少留三個(gè)工作日做提交確認(rèn)，確保收到MD5校驗(yàn)成功的回執(zhí)，心里才踏實(shí)。
關(guān)于版本控制的時(shí)間點(diǎn)也值得提一嘴。eCTD要求每個(gè)文件都有版本歷史。很多時(shí)候，我們是在寫(xiě)文件的過(guò)程中不知不覺(jué)就改了七八版，但什么時(shí)候算正式版1.0？這個(gè)節(jié)點(diǎn)必須在項(xiàng)目初期就定死，通常是獲得QA放行簽字的那個(gè)時(shí)刻。如果你在eCTD包里還放著v0.8的草稿文件，后面想替換成v1.0，就得再走一次lifecycle，平白無(wú)故多一個(gè)序列號(hào)，時(shí)間線就亂了。
其實(shí)吧，做eCTD時(shí)間久了，你會(huì)產(chǎn)生一種直覺(jué)。就像老廚師不用看表就知道火候到了沒(méi)有。看到某個(gè)模塊的文件清單，你就知道大概需要兩周還是三周；看到某個(gè)變更的復(fù)雜程度，你就知道該不該單獨(dú)開(kāi)一個(gè)新序列。
這種直覺(jué)從哪來(lái)？就是從一次次時(shí)間節(jié)點(diǎn)沒(méi)卡好、通宵加班改XML文件里練出來(lái)的。康茂峰帶新人時(shí)，第一句話通常是：寧可前期多花兩天在計(jì)劃上，也不要后期花兩周在改錯(cuò)上。eCTD這東西，錯(cuò)了就是錯(cuò)了，沒(méi)有"差不多"的說(shuō)法，因?yàn)槟切┬ｒ?yàn)工具可不懂什么叫"差不多"。
所以回到最開(kāi)始的問(wèn)題，eCTD發(fā)布的時(shí)間節(jié)點(diǎn)怎么安排？我的建議是，先別急著打開(kāi)軟件，找張紙，把剛才說(shuō)的這些理工科思維暫時(shí)放一放，問(wèn)問(wèn)自己：這次遞交的本質(zhì)是什么？是開(kāi)一個(gè)新篇章，還是修補(bǔ)舊城墻？答案出來(lái)了，時(shí)間點(diǎn)自然就找到了。
