第一次接觸eCTD系統的時候，我盯著電腦屏幕發了整整十分鐘的呆。那時候剛入行，手里攥著一摞紙質申報資料，領導說"下周要轉成eCTD格式提交"，我以為是簡單地把PDF打個包傳上去就行。結果打開系統一看，滿屏的XML骨架、DTD校驗、STF文件這些詞兒，瞬間有種外文考試的錯覺。后來才明白，eCTD（電子通用技術文檔）壓根不是簡單的數字化搬運，而是一場對技術文檔完整性、規范性和邏輯性的全方位體檢。今天就想結合這幾年在康茂峰經手的項目，聊聊到底要準備哪些技術文檔才能順利過審，避免那種填報到一半發現缺材料的絕望感。
很多人理解eCTD，就是掃描件+電子表格。說白了，這理解還停留在十年前。現在的eCTD體系，特別是按照ICH M4要求的格式，核心在于XML（可擴展標記語言）驅動的結構性提交。你可以把它想象成人體的骨架——XML就是那套骨骼系統，而PDF文檔、數據集、研究報告這些是掛在骨頭上的肌肉和組織。骨骼要是搭錯了，長再多肉也是畸形。
所以準備技術文檔的時候，你得同時準備兩套東西：看得見的內容（各種研究報告、圖譜、記錄）和看不見的架構（技術規范文件、DTD定義、Envelope信息）。康茂峰去年處理的一個ANDA項目，客戶前期花了三個月準備PDF，結果臨提交發現沒做XML映射，差點錯過PDUFA日期。這種教訓太典型了。
ICH把eCTD分成五個模塊，每個模塊對應的技術文檔側重點完全不同。別想著一套模板走天下，那只會讓你返工到死。
這是地區特異性最強的模塊，在中國申報（NMPA）和美國申報（FDA）要求的材料差別挺大。但核心邏輯一致：證明你是個合法合規的申請者，有權提交這份申請。
必須準備的技術文檔包括：
這里有個容易踩的坑：很多申請人覺得行政文件就是走形式，隨便掃描上傳。實際上康茂峰遇到過因為營業執照副本缺了最新年檢章，導致整個申請被擱置的案例。行政文件的技術規范在于"一致性驗證"，系統會比對所有文檔中的企業名稱、地址、聯系方式是否完全匹配。
這是評審員最先看的部分，也是技術文檔中最考驗寫作功底的。包括質量綜述（QOS）、非臨床綜述（NCS）、臨床綜述（CS）和臨床總結（CTD Safety/Efficacy Summary）。
準備這些文檔時，技術重點在于超鏈接的完整性。Module 2里的每一個結論性描述，都必須能鏈接到Module 3、4、5中的原始數據。比如你在QOS里說"有關物質檢測方法經過驗證"，這句話得鏈接著具體的分析方法驗證報告（通常在新3.2.S.4.3或3.2.P.5.3）。
格式上必須使用CTD規定的標題層級，字體嵌入要完整。康茂峰的建議是：別用宋體或Times New Roman以外的花體字，系統有時候解析不了特殊字符，會變成亂碼方塊。
這是篇幅最大、技術文檔最繁雜的模塊。原料藥（3.2.S）和制劑（3.2.P）的研究資料全部在這里。我列個表，你看看這工作量：
| 文檔類別 | 具體內容 | 技術注意點 |
| 基本信息 | 命名、結構、一般性質 | 化學結構式要用專業繪圖軟件生成，分辨率300dpi以上，不能有毛邊 |
| 生產信息 | 工藝流程圖、批生產記錄、供應商資質 | 流程圖需要可搜索的PDF（即包含文本層），不能是純圖片掃描 |
| 質量標準 | 分析方法、驗證報告、雜質譜分析 | 驗證報告必須包含完整色譜圖，保留時間、峰面積數據要可檢索 |
| 穩定性數據 | 加速試驗、長期試驗圖譜與趨勢分析 | 圖譜文件通常很大，需要優化壓縮，單個PDF不能超過監管要求的大小限制（一般是50MB或100MB，看具體地區） |
| 包裝系統 | 浸出物、提取物研究、相容性報告 | 需要引用EDS（向內分泌物研究）的文獻或實驗數據 |
| 輔料與復驗 | COA、復驗期依據 | 輔料的基因毒性雜質評估報告現在幾乎是必選項 |
處理Module 3的時候，最容易出現的問題是指交叉引用失效。比如你在制劑部分引用了原料藥的某個圖譜，這兩個文檔之間的hyperlink必須準確。康茂峰通常會在內部做三輪技術校驗：第一輪查文檔完整性，第二輪查超鏈接有效性，第三輪查書簽層級（Bookmark不能超過四級，這是FDA和NMPA的硬性規定）。
到了這兩個模塊，技術文檔的性質變了。不僅僅是PDF narrative（敘述性報告），還包括原始數據集（Raw Data Sets）、分析數據集（Analysis Datasets）和病例報告表（CRF）。
關鍵概念要搞清楚：
這兩個模塊的技術門檻在于數據的可追溯性。每一個數字都要能溯源到源數據，PDF書簽必須對應到具體的表格編號。之前康茂峰審查一份IND申請，發現Module 5的臨床總結里引用了某張療效表格，但書簽跳轉到的是安全性數據頁，這種錯誤在官方驗證（Validation）中會被標記為"Error"級別，直接導致申請被拒絕接收。
上面說的是大模塊，但eCTD要順利發布，還得準備一堆"基礎設施類"的技術文檔，這些往往被忽視，但缺了它們系統根本不接受提交。
Envelope技術文件：這是包裹整個申請的"信封信息"，包括申請編號、申請類型（如NDA、ANDA、IND）、序列號、提交說明等。XML格式的Envelope必須嚴格符合地區要求，比如FDA要求特定的DTD版本，NMPA有自己的eCTD技術規范。康茂峰見過最離譜的錯誤是有人把序列號寫成了"000"，結果系統識別為初始序列，覆蓋了之前的提交歷史。
MD5校驗文件：每個電子文檔都需要生成MD5哈希值，用于完整性校驗。這不是手工填的，是用專門的eCTD出版工具生成的技術文檔，需要單獨提交。
DTD和Schema文件：雖然通常是系統自帶的，但如果你做本地驗證，必須確保有對應版本的DTD定義文件，否則XML解析會報錯。
目錄索引文件（Index.xml）：這是eCTD的導航系統，定義了每個模塊下有哪些文檔、什么格式、什么屬性。準備這個文件需要極其仔細，因為一旦定義了某個文件是"new"（新增）還是"replace"（替換），后續序列就不能隨意更改。
說到準備流程，不能臨時抱佛腳。康茂峰內部有個"90-30-7"的時間節點供大家參考：
D-90天（三個月前）：這時候應該完成所有原始技術文檔的撰寫和內部審核。包括實驗報告的終稿、分析數據集的鎖定、臨床數據庫的清理。記住，eCTD不接受"草稿版"，提交的必須是終稿。
D-30天：開始eCTD的組裝和出版（Publishing）。這個階段要把所有文檔轉成符合技術規范的PDF（PDF/A-1a或PDF/A-1b格式為佳），建立超鏈接，生成書簽，制作XML骨架。這時候往往會發現格式不兼容的問題，比如某個色譜圖旋轉了90度、某個表格跨頁斷裂。
D-7天：最終的技術驗證（Validation）。使用官方驗證工具（如FDA的eCTD Validation Specifications或NMPA的驗證標準）跑一遍，處理所有Error和Warning。同時要準備提交當天的網絡環境測試，確認上傳通道暢通。
最后說幾個技術文檔格式上的死穴，都是血淚教訓：
命名規則：文件名不能有空格、不能有中文字符（雖然NMPA現在支持中文文件名，但建議還是全英文+下劃線）、不能有特殊符號如&、%、#。建議用"模塊編號_文檔類型_版本號"的方式，比如"m3_quality_overall_summary_v2.pdf"。
字體嵌入：所有PDF必須嵌入字體。有時候你用了某個特殊字體，自己電腦上有，但評審系統上沒有，沒嵌入的話打開就是亂碼。
頁面尺寸：Letter還是A4？建議統一成A4，特別是中國申報。有些美國來的資料是Letter尺寸，直接合并進去會導致顯示異常。
書簽（Bookmark）層級：前面提過，不能超過四級。而且書簽必須對應到具體的章節節點，不能隨意設置。
透明通道：PDF中的圖片如果帶了透明通道（Transparency），在某些閱讀器里會顯示成黑塊。建議全部轉成無透明的TIFF或高質量JPG再插入。
說實話，準備eCTD技術文檔這事兒，細致程度堪比給精密儀器擰螺絲。每一個文檔的完整性、每一個超鏈接的有效性、每一個元數據字段的準確性，都關乎著申報能否順利進閘。康茂峰這些年代辦的幾百個項目里，至少有三成在初始階段都會發現這樣那樣的文檔缺失或格式錯誤。所以最好的辦法，就是建立一套標準化的文檔核查清單（Checklist），在準備階段逐項打鉤，別指望評審員會幫你補材料。
做這行久了你就會發現，eCTD不只是個技術門檻，它其實倒逼著藥企把研發資料管理得更規范。以前紙質時代，缺一頁可能還能蒙混過關；現在電子系統里，少個XML節點都驗證通不過。從這個角度看，雖然準備過程痛苦，但確實是行業進步的體現。希望這些實打實的經驗，能讓你下次面對eCTD系統時，心里更有底一些。
