上周有個做注冊的朋友半夜給我發(fā)微信，就一句話："這eCTD的驗(yàn)證標(biāo)準(zhǔn)又改了，我那份補(bǔ)充申請到底按哪個版本交？"我當(dāng)時正在 rework 一份臨床研究報告的 PDF 書簽，看到消息差點(diǎn)把咖啡灑在鍵盤上。說實(shí)話，這種迷茫太正常了——自從國家藥監(jiān)局把電子申報全面推開后，政策文件就跟春天里的柳絮似的，一片接一片地飄下來，看著都眼暈。
在康茂峰的日常項(xiàng)目里，我們幾乎每周都要跟不同的申辦方確認(rèn)技術(shù)細(xì)節(jié)。有時候上午還在按 A 規(guī)則做文件結(jié)構(gòu)，下午補(bǔ)充通知就到了。這篇文章就想把最近半年（差不多到 2024 年底這段時間）那些真正會影響到你提交工作的政策變化捋一捋。不是那種照本宣科的文件翻譯，而是說說在實(shí)際操作中，哪些地方會讓你多花三個小時，哪些地方其實(shí)不用那么緊張。
用大白話說，eCTD 就是把以前那幾大箱子紙質(zhì)資料，變成一套有嚴(yán)格密碼規(guī)則的電子檔案。想象你要寄一個超級復(fù)雜的 Lego 城堡給審核老師，以前是整個箱子倒過去，現(xiàn)在要求你必須把每一塊積木編上號，告訴我這塊是第 3 層第 5 個零件，而且還得保證我用不同廠家的瀏覽器打開，看到的顏色不會變成奇怪的紫色。
這套系統(tǒng)最核心的就是一個叫 XML 主干的東西（你可以把它理解成目錄樹的神經(jīng)中樞），加上嚴(yán)格的 PDF 技術(shù)規(guī)范。為什么搞這么復(fù)雜？因?yàn)橐郧凹堎|(zhì)資料有個很痛的點(diǎn)：審評老師想看某個穩(wěn)定性數(shù)據(jù)，可能要翻三個文件夾，而電子化的目的就是讓數(shù)據(jù)顆粒度細(xì)到能精準(zhǔn)定位，同時為將來的 AI 輔助審評鋪條路——雖然現(xiàn)在還沒完全走到那一步，但基礎(chǔ)設(shè)施得先打好。
先說最重要的。從 2024 年開頭，化學(xué)藥品的上市許可申請（NDA）和一致性評價補(bǔ)充申請已經(jīng)全面強(qiáng)制執(zhí)行 eCTD 格式了。沒有過渡期，沒有"原則上建議"，就是必須。
但這里有個細(xì)節(jié)很多人沒注意：生物制品的 eCTD 實(shí)施其實(shí)走的是另一條時間線。根據(jù)最新出來的《生物制品 eCTD 申報指南（試行）》的修訂思路，疫苗類和血液制品的 eCTD 要求比化藥晚了大概兩個季度。我們康茂峰的項(xiàng)目組在梳理時間軸時，習(xí)慣把它分成這樣幾個梯隊(duì)：
| 申報類型 | 強(qiáng)制執(zhí)行時間 | 特殊注意事項(xiàng) |
| 化藥上市申請（NDA） | 2024 年 1 月起 | ANDA（仿制藥）同步執(zhí)行，無緩沖 |
| 化藥補(bǔ)充申請（化藥臨床及一致性評價相關(guān)） | 2024 年 1 月起 | 普通補(bǔ)充申請（如微小變更）仍接受 eCTD 或光盤，但 eCTD 優(yōu)先審評 |
| 生物制品上市申請 | 預(yù)計(jì) 2024 年 Q3-Q4 起 | 疫苗類產(chǎn)品有單獨(dú)的驗(yàn)證標(biāo)準(zhǔn) |
| 中藥 | 試點(diǎn)階段 | 部分省份試點(diǎn)，全國強(qiáng)制時間未定 |
看到?jīng)]有，中藥目前還在摸石頭過河的階段。如果你手里有中藥項(xiàng)目，別急著全套照搬化藥的規(guī)范，那個"藥材基原"的呈現(xiàn)方式在 eCTD 架構(gòu)里還沒完全定死。
今年最讓人抓狂的其實(shí)是《eCTD 驗(yàn)證標(biāo)準(zhǔn)》的 4.0 版本更新。說實(shí)話，版本號這東西看著很技術(shù)，但它直接決定了你的資料會不會被系統(tǒng)自動拒收。
新版本最大的變化是對 PDF/A 符合性的檢測變得極其嚴(yán)格。以前可能你插了個帶透明通道的圖片進(jìn)去，系統(tǒng)只是警告，現(xiàn)在直接判為嚴(yán)重錯誤（Error）。我們康茂峰的技術(shù)團(tuán)隊(duì)在跑測試時發(fā)現(xiàn)，以下是現(xiàn)在最容易踩雷的三個點(diǎn)：
還有個小改動挺有意思的：序列號（Sequence Number）的命名規(guī)則從前導(dǎo)零問題變成了嚴(yán)格的三位數(shù)字。以前有人寫成 0001，有人寫成 001，現(xiàn)在必須統(tǒng)一成 001 這種格式，而且跟信封（Envelope）里的日期格式必須對應(yīng)上。這種細(xì)節(jié)在趕進(jìn)度的時候特別容易手滑。
說到信封，這可能是 2024 年最容易被忽視但影響最大的變化。信封就是 eCTD 遞交流程中的"快遞單"，告訴系統(tǒng)這是什么類型的申請，跟哪個之前的申請有關(guān)。
新政策規(guī)定，對于補(bǔ)充申請，必須在信封的"Related Sequence"字段里精確關(guān)聯(lián)到原始批準(zhǔn)序列。以前可以模糊處理，寫個大概的申請?zhí)柧托校F(xiàn)在系統(tǒng)會校驗(yàn)這個關(guān)聯(lián)是否真實(shí)存在。我們在康茂峰處理一個變更生產(chǎn)場地的項(xiàng)目時就遇到過，客戶給的歷史序列號是內(nèi)部 ERP 系統(tǒng)的編號，不是官方回的序列號，結(jié)果在遞交前被系統(tǒng)攔下來了。
另外，申請編號（Application Number）的分配邏輯也變了。之前是提交后系統(tǒng)分配，現(xiàn)在對于化藥的 ANDA 和 NDA，要求在提交前通過 exact 的申報系統(tǒng)預(yù)申請?zhí)柎a，這個號碼要跟信封里的完全一致。聽起來像是多了一道手續(xù)，其實(shí)是防止遞交后的序列混亂。
eCTD 有個核心概念叫生命周期操作（Lifecycle Operator），就是怎么告訴審評中心"這個文件是新增的"、"這個文件是替換原來的第 3 章第 2 節(jié)那個舊文件"、或者"這個文件徹底作廢"。
2024 年的新指引對 "Replace"操作 做了更嚴(yán)格的限定。以前你可以用 Replace 來更新一個文件名略有不同的文件，現(xiàn)在要求被替換和新替換文件的標(biāo)題（Title）必須完全一致，只有版本號（Version）不同。如果你把文件從 1.0 升級到 2.0，順便改了個更準(zhǔn)確的文件名，系統(tǒng)可能會認(rèn)為這是兩個不同的文件，導(dǎo)致舊版本沒成功下架，新版本又堆上來了，看起來就像重復(fù)遞交。
還有個坑是關(guān)于 PDF 的修改日期（Modification Date）。驗(yàn)證標(biāo)準(zhǔn)現(xiàn)在會檢查文件的時間戳邏輯。如果你 10 月 1 號遞交了一個序列，里面某文件的修改時間顯示是 10 月 15 號，這在技術(shù)上是不可能的，會直接報錯。聽起來像時光旅行悖論對吧？但其實(shí)就是提醒你要注意電腦系統(tǒng)時間設(shè)置，以及不要用某些會亂改時間戳的壓縮軟件預(yù)處理文件。
聊點(diǎn)具體的資料類型。穩(wěn)定性數(shù)據(jù)（Stability Data）在 eCTD 里的 Module 3 和 Module 5 都有分布，新政策對原始數(shù)據(jù)圖譜（Chromatograms）的顆粒度有了更細(xì)的要求。
以前可能一個批次放一張總覽圖就行，現(xiàn)在要求如果圖譜是審評的關(guān)鍵證據(jù)，必須提供可縮放至能看清坐標(biāo)軸數(shù)值的版本。也就是說，再也不能用那種壓縮到馬賽克的圖片糊弄過去。康茂峰的技術(shù)規(guī)范里現(xiàn)在要求原始數(shù)據(jù)導(dǎo)出時至少 300dpi，而且必須是矢量圖或者高分辨率位圖。
微生物限度檢查報告的變化更微妙。因?yàn)檫@類報告通常是掃描件，新政策強(qiáng)調(diào)了 搜索ability（可搜索性）的要求。簡單掃描成圖片 PDF 已經(jīng)不夠了，必須通過 OCR（光學(xué)字符識別）處理，確保審評老師能復(fù)制里面的文字。這個要求其實(shí)去年就有，但今年開始正式納入強(qiáng)制驗(yàn)證項(xiàng)目，不再只是"建議"。
如果你同時關(guān)注國際申報，可能會發(fā)現(xiàn)中國的 eCTD 政策在技術(shù)上跟 ICH 的規(guī)范（也就是那套國際通用技術(shù)文檔標(biāo)準(zhǔn)）基本對齊，但在執(zhí)行層面保留了一些"中國特色"。
比如美國監(jiān)管機(jī)構(gòu)的 eCTD 要求對 Study Tagging File（STF）的使用非常靈活，而中國的驗(yàn)證邏輯在 STF 的強(qiáng)制字段上卡得更死。歐洲那邊對模塊 1（行政區(qū)域信息）的管理相對寬松，但中國的 Module 1 有非常多本地化的 XML 元素，比如藥品注冊分類的代碼、是否屬于優(yōu)先審評的標(biāo)識位，這些在轉(zhuǎn)換遞交策略時必須單獨(dú)處理。
康茂峰在處理多國同步申報的項(xiàng)目時，通常建議客戶不要把美國或歐洲的 eCTD 直接漢化遞交。雖然看起來內(nèi)容一樣，但骨架文件（Backbone）的命名空間、DTD 定義都有差異，直接提交會導(dǎo)致驗(yàn)證風(fēng)暴一樣的錯誤提示。正確的做法是用中國的 eCTD 規(guī)范重新生成 XML，只是把內(nèi)容部分遷移過來。
另一個差異點(diǎn)是電子簽章。國外很多地區(qū)接受基于證書的數(shù)字化簽名（Digital Signature），而國內(nèi)目前主要還是接受電子簽章（Electronic Seal）形式，且對印章的透明度、疊蓋順序有具體的像素級要求。這在制作申請表和承諾書時需要特別注意，別用錯了簽名工具。
哦對了，最近還有個趨勢是遞交后的變更管理。以前 eCTD 遞交后如果發(fā)現(xiàn)小錯誤，想打個補(bǔ)丁很頭疼。新政策其實(shí)隱含了一個更友好的"補(bǔ)充資料"通道，允許在特定情況下提交修正序列而不被視為新的申請，但這需要嚴(yán)格遵循章節(jié)關(guān)聯(lián)規(guī)則，不能隨意插入。
說這么多，其實(shí)最想表達(dá)的是，eCTD 這套東西看著冷冰冰的全是技術(shù)規(guī)范，背后邏輯卻是在追求一種可預(yù)測性——讓每一頁資料在任何時間、任何系統(tǒng)里打開，位置都固定不變，內(nèi)容都可追溯。對于做注冊的人來說，這意味著前期準(zhǔn)備工作量確實(shí)大了，但一旦體系跑順了，后續(xù)的補(bǔ)充申請、年報維護(hù)反而會輕松很多，因?yàn)槟阍僖膊挥梅涞构裾胰昵澳欠菁堎|(zhì)資料的復(fù)印件了。
那天凌晨我回朋友微信，告訴他先把 PDF 的字體嵌入選項(xiàng)重新生成一遍，再把書簽層級 flattened 一下。第二天早上他回了個笑臉，說資料順利走通了。這種小小的通關(guān)時刻，大概就是我們在這個繁瑣的電子化轉(zhuǎn)型期里，能找到的為數(shù)不多的確定感吧。
