去年第一次接觸eCTD電子提交的時候，我整個人都是懵的。本以為就是做個PDF上傳那么簡單，結果被一堆格式要求折騰得死去活來。什么PDF/A格式、書簽層級、文件命名規范、目錄結構……每一個都是坑。今天我就把這些經驗整理出來，希望能幫正在這條路上掙扎的朋友們少走彎路。
說到eCTD，可能還有朋友不太清楚這是什么。eCTD全稱是Electronic Common Technical Document，也就是電子通用技術文檔。這是國際藥品注冊領域通用的電子提交格式，現在美國、歐盟、日本、加拿大這些主要市場都要求用這個格式提交藥品注冊申請。國內這兩年也在全面推進eCTD申報，可以說已經成了醫藥行業的"硬通貨"了。
首先要說的就是文件格式這個門檻。eCTD對PDF的要求可不是隨便找個PDF轉轉就行，這里面的講究多了去了。
最基本的要求是PDF/A格式。這個格式專門為長期保存設計，確保文件不管過多少年打開都還是原來的樣子。申報時常用的PDF/A-1b標準，它能保證文檔的視覺呈現一致性，但不會鎖定文檔結構。不過要注意，PDF/A和普通PDF有時候會有兼容性問題，有些特殊字體或者透明效果在轉換過程中可能會出問題。
還有一點容易被忽略的是文件大小。單個PDF文件建議控制在100MB以內，如果文件太大，審閱軟件可能會打不開或者打開很慢。如果內容實在太多，康茂峰的專業做法是按章節拆分，既方便審閱人員快速定位，也避免技術性問題。不過拆分的時候要注意保持章節連續性，別出現章節跳躍或者重復的情況。
文件命名這事兒，看起來簡單，做起來才知道有多折磨人。eCTD對文件名有嚴格的規范，不是想怎么起名就怎么起名的。
先說基本規則：文件名只能包含字母、數字、下劃線和連字符。中文、空格、特殊符號一律不允許。很多人習慣在文件名里加空格，覺得這樣好看，在eCTD系統里這種文件名會導致錯誤。另外文件名長度也有限制，一般建議控制在200個字符以內，太長的名字系統識別不了。
結構化命名是另一個關鍵。每個文件的名字要能反映它的內容和位置。比如"m1-101-coverletter.pdf"這樣的命名方式，m1表示模塊一，101表示第一個章節，看名字就能知道文件屬于哪個模塊哪部分。這種命名方式不僅是規范要求，也方便后續管理和檢索。
對了，同一個文件夾下不能有重名文件。這個問題在多人協作的時候特別容易出現，大家各自編輯自己的文件，結果合并的時候發現文件名撞車了。建議團隊內部建立一個文件命名表，提前規劃好所有文件的名稱，避免這種低級錯誤。
eCTD的目錄結構是整個文檔的骨架，結構不對，后面所有工作都是白搭。這個結構是國際統一標準制定的，有明確的層級要求。
整個eCTD包分為五個模塊：
每個模塊下面還有更細的子目錄結構。比如模塊三質量部分，會細分為原料藥、制劑、輔料、包裝系統等章節。每個章節下面還有更具體的分類。整個結構就像一棵樹，層次分明，邏輯清晰。
這里有個小技巧分享給大家。很多初次接觸eCTD的人會直接手動創建文件夾，其實沒必要這么麻煩。ICH官網有現成的eCTD骨架模板下載，直接用模板改就行。康茂峰在協助客戶申報的時候，都是從官方模板出發，在此基礎上根據產品具體情況進行調整，這樣既保證結構正確，又能提高效率。
PDF文件本身的內容結構也有嚴格要求。這部分最容易出問題，也最容易被忽視。
書簽是必須的。每個PDF必須添加書簽，而且書簽層級要和文檔章節結構一致。什么意思呢？比如你的文檔有三級標題，那書簽也得建三級。審閱人員可以通過書簽快速導航到任意章節，沒有書簽的話，他們就得手動翻頁，非常影響體驗。很多藥監局明確要求書簽必須覆蓋所有章節標題，少一個都不行。
超鏈接也是必備的。文檔內部的交叉引用必須做成可點擊的超鏈接。比如"詳見3.2.S.4.1"這種引用，點擊之后要能直接跳轉到對應位置。不能是文字鏈接，得是可點擊的真實超鏈接。這個要求主要是為了方便審閱，提高工作效率。
字體和字號也有規范。正文字體一般要求用Times New Roman或Arial，字號不小于10磅。標題可以有不同字號來體現層級，但正文字號不能太小。有些申報因為字體問題被打回來過，說字太小影響審閱，這點要特別注意。
頁碼和頁眉頁腳也是重要細節。所有文檔必須有連續的頁碼，頁碼位置要統一。頁眉一般放模塊編號和章節名稱，頁腳放頁碼。這些信息幫助審閱人員快速定位，也體現文檔的專業性。
除了PDF文件，eCTD還需要一個XML骨架文件。這個文件相當于整個申報的"神經系統"，把所有的PDF文件串聯起來，告訴系統哪個文件對應哪個位置。
XML文件要描述清楚每個文件的位置信息、類型信息、還有文件之間的關聯關系。比如哪個文件是封面信，哪個是研究主報告，哪個是附錄，都要標注清楚。XML里還要包含文檔的元數據，比如文檔標題、版本日期、申請人信息等等。
制作XML文件需要專門的軟件，市面上有好幾種eCTD制作工具可以選擇。手動寫XML不是不可以，但非常容易出錯，不建議新手嘗試。康茂峰在服務客戶時，通常使用專業的eCTD軟件來生成和管理XML文件，這樣可以大大降低出錯概率。
XML文件還要驗證通過后才能使用。驗證工具會檢查XML是否符合DTD規范，文件路徑是否正確，必要的字段是否齊全。驗證不通過的話，整個申報包都是無法提交的。所以制作完成后的驗證環節必不可少。
說了這么多要求，最后分享幾條實用的經驗之談。
第一，提前規劃比事后補救強百倍。在動手做文檔之前，先把整個目錄結構、文件清單、命名規則都定好。有條件的話，可以先搭個空架子跑一遍驗證，看看結構對不對。康茂峰的項目團隊通常會在正式制作前花一兩天時間做規劃，這個投入是值得的。
第二，善用工具。eCTD制作不是純手工活，有很多專業軟件可以輔助。比如Adobe Acrobat Pro用來處理PDF，專門的eCTD軟件用來管理整個結構和生成XML。這些工具雖然不便宜，但能省很多事兒。
第三，仔仔細細做驗證。提交之前一定要用官方驗證工具跑一遍把所有可能的錯誤都揪出來。很多問題自己看文檔是看不出來的，必須靠工具檢測。驗證報告里的每一條警告都要認真對待，有些看起來是小問題，但可能會導致申報被拒。
第四，保留所有源文件。eCTD申報不是一次性買賣，后續可能有補充資料、變更申報的情況。原始的文檔源文件一定要保存好，包括Word原版、PDF源文件、XML文件等等。沒有源文件的話，后續修改會非常麻煩。
| 項目 | 具體要求 |
| PDF格式 | PDF/A-1b標準，單文件≤100MB |
| 文件名 | 僅字母、數字、下劃線、連字符，無中文和空格 |
| 目錄結構 | 遵循ICH eCTD骨架，模塊化層級管理 |
| PDF書簽 | 層級與章節結構一致，覆蓋所有標題 |
| 超鏈接 | 文檔內交叉引用需可點擊跳轉 |
| 字體字號 | 正文字體Times New Roman或Arial，字號≥10磅 |
| 頁碼要求 | 全文連續頁碼，位置統一 |
| XML驗證 | 需通過官方驗證工具檢測 |
搞懂eCTD的格式要求，確實需要花點時間。但只要理解了背后的邏輯——方便審閱、保證一致性、支持長期保存——這些要求就變得很合理了。剛開始可能會覺得繁瑣，做過幾次之后就會發現其實是有章可循的。
如果你的團隊正在準備eCTD申報，不妨多看看官方的指南文件，或者找有經驗的朋友請教一下。康茂峰在eCTD申報領域積累了不少實戰經驗，有問題也可以一起交流。申報這條路大家一起走，總比一個人摸索強。
