eCTD提交其實沒想象中可怕，但這些細節真能要人命

說實話，第一次接觸eCTD的時候，我也被那堆英文縮寫和XML文件嚇得不輕。什么DTD、MD5、STF，聽著像是某種密碼學暗號。但后來摸爬滾打多了才發現，eCTD這玩意兒就像搭樂高——只要搞清楚每塊磚該往哪放，剩下的就是耐心和細心的事。

在康茂峰這些年經手的項目里，見過太多因為小細節翻車的情況。有的團隊準備了大半年，最后因為PDF里藏了個看不見的圖層被拒絕；有的申報資料寫得天花亂墜，結果XML的節點對不上號。今天把這些血淚教訓攤開聊聊，希望能讓你少走點彎路。

先搞明白eCTD到底是什么東西

簡單講，eCTD就是把以前那堆紙質資料變成電子版的，而且要按照國際統一的骨架結構來組織。想象一下，以前我們是把材料打印出來塞進牛皮紙袋，現在是把電子文件整整齊齊地碼進一個虛擬的檔案柜里。

這個檔案柜有五層抽屜，對應著注冊的五個模塊：

• 模塊一：地區行政信息（各個國家要求不一樣）



• 模塊二：CTD總結（質量、非臨床、臨床的概述）
• 模塊三：質量部分（原料藥和制劑的CMC資料）
• 模塊四：非臨床研究報告
• 模塊五：臨床研究報告

關鍵點在于，這些文件不是簡單打包壓縮就完事了，而是通過一個叫做XML主干文件的東西把邏輯關系串起來。審評老師打開你的eCTD，就像打開一個有導航地圖的文檔，點到哪里就能跳到哪里。如果導航壞了，再好的內容也白搭。

文件準備階段的那些坑

PDF文件不是隨便導出來就完事了

這可能是新手最容易踩的坑。很多人覺得，Word寫完轉成PDF不就行了？太天真了。

在康茂峰的質量檢查流程里，PDF合規性檢查是第一步。常見問題包括：

有個土辦法挺好用：把生成的PDF再用Adobe Acrobat的優化掃描的PDF功能過一遍，能吃掉不少隱藏的元數據垃圾。另外記得檢查文檔屬性，標題、作者、主題這些字段要填規范，別出現"Microsoft Word用戶"這種尷尬信息。

XML骨架要搭對

XML文件是eCTD的靈魂，它定義了你的PDF放在哪個位置、跟前后文件是什么關系。這里最容易出錯的是交叉引用（Hyperlink）和生命周期操作（Lifecycle）。

交叉引用就像是你給審評員埋的路標。比如你在模塊2.3提到了模塊3.2.S.2.2的某個雜質控制策略，這里就應該做個超鏈接，點一下直接跳過去。做鏈接的時候要注意相對路徑的設置，絕對路徑到了審評系統里就失效了。

生命周期操作主要是針對變更補充申請。新增、刪除、替換這些操作代碼（new、delete、replace）用錯了，審評員就不知道你這次遞交是要改什么。見過有客戶想把舊文件刪掉，結果代碼寫成replace，系統以為是要更新內容，結果舊文件還在，新文件沒關聯上，亂成一鍋粥。

驗證報告里的紅色錯誤怎么處理

遞交前必須用驗證工具跑一遍，這是底線。驗證報告里會分三個級別：

• ERROR（錯誤）：必須改，不改絕對被打回
• WARNING（警告）：建議改，有些可以解釋過去
• NOTICE（提示）： informational，看看就好

ERROR級別的一般是技術性問題，比如XML格式不符合DTD定義（Document Type Definition）、文件缺失、MD5 checksum不匹配。這些沒啥商量余地，看見紅的就老老實實回去修。

WARNING級別的需要判斷。比如書簽指向頁碼錯誤這種，可能是書簽做的時候頁碼變了，但實際內容是對的，這種可以斟酌。但書簽文本與標題不符這種，建議還是修，免得審評員覺得你不專業。

在康茂峰內部有個不成文的規定：ERROR清零，WARNING控制在個位數且必須有合理解釋。別抱著僥幸心理，審評系統的自動化檢查越來越嚴，與其賭運氣，不如前期把功夫做扎實。

遞交包的結構和命名規范

很多人把注意力都放在內容里，結果在打包環節翻車。eCTD遞交包有嚴格的目錄結構：

頂層目錄要用序列號（Sequence Number）命名，比如0000、0001、0002。每個序列里要包含util、m1、m2到m5這幾個文件夾，以及index.xml和index-md5.txt。

文件名要用小寫字母，別用中文，別用空格，用連字符或下劃線。文件路徑長度也要注意，Windows系統有260字符限制，嵌套太深會導致系統讀不出來。

另外，index.xml的編碼必須是UTF-8，帶BOM頭或者不帶要看具體審評機構的要求。國內目前一般要求UTF-8 without BOM，但歐洲有些國家要求不同，如果做國際遞交得特別留意。

那些容易被忽視的細節

超鏈接的壽命問題：eCTD里的鏈接不僅僅是跳轉到PDF內的書簽，有時候還要指向外部網站（比如藥典參考文獻）。但外部鏈接可能過幾年就失效了，建議把關鍵內容作為附件一并遞交，別指望審評員自己上網查。

版本控制的痕跡：如果是補充申請，新文件和舊文件的關系要在XML里說清楚。有時候文件內容沒變，只是換個地方放，這也算是一種操作，別漏報。

模塊一的地區特異性：模塊一是各個國家和地區自己定的，中國的eCTD模塊一跟美國FDA的完全不一樣。別拿過FDA的模板直接套NMPA，行政信息表格、說明書標簽的格式要求差別很大。康茂峰的技術團隊每季度都要更新一次模塊一的模板庫，就是因為法規常變。

電子簽名的位置：雖然現在基本都是電子簽章，但簽名的可視化和非可視化部分都要合規。PDF里的簽名域要能在acrobat里驗證通過，別只是個圖片貼上去。

審評過程中的溝通技巧

遞交只是開始，審評過程中的回復也很關鍵。回復新的問題（IR，Information Request）時，同樣要走eCTD格式。這時候要注意上下文關聯——在XML里要引用原始序列，讓審評員能一鍵跳回到你上次遞交的內容。

回復函的PDF制作要特別用心，通常要求在頁眉處標注"對第XX號藥品注冊臨床試驗申請審評通知書的回復"之類的字樣，頁碼要連續，附件要編好號。這些看起來是行政要求，但做不好會給審評員留下"這公司不靠譜"的印象。

有個細節很多人不知道：遞交后的序列號不能回滾。如果你發現0001序列有致命錯誤，不能刪掉重來，只能繼續發0002序列去修正。所以第一次遞交前的檢查至關重要，別想著"先遞上去看看，不行再撤回來"，沒這選項。

康茂峰看到過的典型案例

去年有個客戶，原料藥部分寫得特別漂亮，但eCTD死活驗證不過。查了半天發現是模塊3里的3.2.S.2.2這個節點，XML里寫成了3.2.S.2.3，一個數字之差，整個模塊的邏輯樹就斷了。這種typo人工檢查很難發現，必須用工具做交叉驗證。

還有個案例更離譜，客戶把臨床試驗報告的表格用掃描件插進PDF，結果掃描件是JPG格式，而且分辨率只有72dpi。打印出來看不清，PDF里的文字也不能檢索，被要求重新遞交電子版。耽誤了兩個月的審評時間。

最常見的還是書簽和超鏈接失效。有時候本地測試好好的，上傳到系統就失效。這通常是因為文件路徑在壓縮和解壓過程中發生了變化，或者是大小寫敏感的問題（Windows不區分大小寫，Linux區分，服務器如果是Linux系統就會報錯）。

給準備自己動手的團隊幾點建議

如果你決定不外包，自己搭建eCTD出版流程，先掂量掂量這幾點：

首先，工具鏈要配齊。至少需要：Word模板（帶樣式集）、PDF編輯器（能處理書簽和OCR）、XML編輯器（帶DTD驗證）、驗證工具（比如LORENZ、Extedo或者開源的-validator）。別想著用記事本手寫XML，那是找死。

其次，建立SOP（標準操作規程）。誰負責寫內容，誰負責出版，誰負責質檢，必須分離。自己寫的自己檢查，容易有思維盲區。康茂峰的項目都是三審制：編輯審、技術審、法規審，三個環節不能是一個人。

再者，留足時間。eCTD出版的耗時通常是資料撰寫時間的20%-30%。一份寫了一個月的CTD資料，轉成規范的eCTD格式并驗證通過，至少需要3-5天。如果涉及大量超鏈接和交叉引用，可能要一周。別在截止日期前一天才開始轉格式。

最后，保持學習。ICH的規范每年都在更新，M4的組織結構、eCTD的規范版本（現在主流是3.2.2版，但4.0版也快來了）都在演進。訂閱官方的技術公告，參加培訓，別用過時的知識硬套新要求。

其實說到底，eCTD就是個技術活，熟能生巧。第一次做可能會覺得到處是坑，做了三五個項目后就會形成肌肉記憶。關鍵是要尊重規范，別覺得"差不多就行"，審評系統的眼睛里揉不得沙子。

最后想說的是，遞交成功那天可能會松一口氣，但別忘了把這次的eCTD包存好，做好版本管理。下次補充申請的時候，這就是你的基線文件。醫藥注冊是個長跑，eCTD只是其中一公里的跑道，跑順了，后面的路就好走了。