做藥品注冊這行年頭久了，你會發現一個挺有意思的現象：那些被打回的eCTD申報資料，往往不是因為臨床數據有問題，也不是因為CMC研究不充分，而是栽在一些特別基礎、特別細碎的地方。康茂峰這邊的技術團隊去年幫客戶做資料預審，十份里面差不多有六七份都存在這樣那樣的格式瑕疵。有些問題看起來很小，小到你覺得"應該沒關系吧"，但CDE的驗證系統可不講情面，一個XML標簽沒閉合，整個序列就傳不上去。
所以這篇文章就想單純聊聊，那些讓我們在加班改文件時捶胸頓足的常見錯誤，以及怎么在第一次就把事情做對。不是什么高深理論，就是實打實的操作經驗。
很多人第一次接觸eCTD，容易把它想象成普通的文件夾打包——就像整理電腦里的照片，建個文件夾往里拖文件就行。但實際上，eCTD的目錄結構是定死的，m1到m5的層級關系不是建議，是硬性規定。
最常見的錯誤是自定義文件夾名稱。比如有人覺得"2.3.1-Introduction"太死板，改成"2.3.1-引言介紹"，或者直接把空格改成下劃線。這在Windows系統里看著沒區別，但上傳到電子申報系統時，路徑識別會報錯?？得逵袀€客戶曾經因為這個原因，在提交截止前三小時被系統拒收，整個項目組手忙腳亂地重命名文件，那種絕望感我到現在都記得。
另外就是文件位置的錯亂。比如把m3的模塊內容放到了m2下面，或者CTD格式的總結和具體研究報告放反了。這里有個簡單的記憶方法：m1是各地的行政文件，m2是總結匯總，m3是質量部分，m4是非臨床，m5是臨床。記住這個邏輯，至少不會犯方向性錯誤。
| 容易犯的錯誤 | 正確的做法 |
| 使用中文文件夾名 | 嚴格使用英文CTD固定命名 |
| 在標準目錄下自建子文件夾 | 只在系統允許的leaf level放置文件 |
| 文件直接丟在模塊根目錄 | 必須放在最底層的指定文件夾內 |
| 混用大小寫（如PDF和pdf） | 統一使用小寫擴展名 |
這是最容易被低估的部分。很多人覺得PDF不就是文檔格式嗎，能打開看不就行了？但在eCTD的世界里，PDF是一種嚴格受限的容器。
先說字體。嵌入字體這個要求，十份資料里有八份第一次檢查都不合格。不是說你用了宋體或者Times New Roman就行，而是這些字體必須完整地嵌入到PDF文件里。舉個例子，如果你從Word轉成PDF時選擇了"標準轉換"而不是"符合PDF/A標準"，或者為了壓縮文件大小勾選了"僅嵌入使用的字符"，那這份文件在別的電腦上打開，或者通過CDE的驗證工具時，就可能出現亂碼或者字符丟失。
書簽是另一個重災區。eCTD要求PDF必須有符合CTD結構的書簽導航，而且書簽必須指向具體的頁面，不能指向整個文檔?？得宓募夹g顧問經常遇到這樣的情況：一個兩百頁的CMC報告，書簽只做了第一級的"3.2.S.1 General Information"，下面的二級、三級書簽全都沒做，或者做了但指向錯誤。審評員拿到這樣的文件，只能手動翻頁去找內容，體驗很差，也容易被記作缺陷。
還有版本問題。PDF必須是1.4版本，這是很多人不知道的。如果你用最新版的Acrobat導出了1.7或者2.0版本的PDF，技術上更先進，但就是不兼容老舊的驗證系統。這就像是你拿著USB-C的線想插進只有USB-A的接口里，再好也使不上勁。
提到XML，很多注冊專員就頭疼，覺得這是IT或者軟件工程師該管的事。但其實你只要把它理解為整個申報資料的"目錄頁"和"導航系統"就行。XML文件告訴電腦：這個PDF叫什么名字、放在哪里、是什么性質的內容、和其他文件什么關系。
最常見的XML錯誤是checksum（校驗值）不匹配。簡單說，XML里記錄了這個文件的"指紋"（MD5值），如果你后期又改了PDF內容但沒重新生成XML，指紋對不上，系統就會報錯。這種情況多發在"我先占位，后面再替換最終版"的工作方式中。記住，在eCTD里，任何文件的改動都必須同步更新XML，哪怕只是改了個錯別字。
還有序列號（sequence number）的管理。初次提交是0000，然后0001，0002這樣往上加。聽起來簡單，但經常有人搞混，比如把0000的XML骨架原封不動改成0001，但里面的ID沒改，導致系統識別為重復提交。或者是在做生命周期管理（lifecycle）時，operation屬性填錯——replace和delete是完全不同的操作，一旦選錯，可能就把不該刪的文件刪了，或者該替換的沒換掉。
這里分享一個康茂峰內部的小技巧：在準備XML之前，先列一張文件清單表，把每個文件的目的地（哪個m模塊、哪個subsection）、文件名稱、對應的書簽層級都列清楚。先在紙上理清楚邏輯，再動手寫XML，比邊做邊想要靠譜得多。
eCTD之所以叫"電子"通用技術文檔，很大程度上就是因為這些交叉引用和超鏈接的功能。但正是這些鏈接，成了很多申報資料的滑鐵盧。
斷裂的鏈接是最頭疼的。比如你在m2.3的總結里引用了一個m3.2.S.4.1的檢驗方法，做了個超鏈接指向那個PDF的 specific location。但如果后面那個PDF被更新了，哪怕只是頁碼變了，或者你重新導出時書簽ID變了，這個鏈接就失效了。更隱蔽的是相對路徑和絕對路徑的問題——在本地電腦上測試好好的鏈接，打包成eCTD結構后路徑變了，鏈接就斷了。
還有一種情況是鏈接到了不該鏈的地方。比如跨模塊的鏈接，從臨床部分鏈到質量部分，這在技術上是可行的，但很多時候注冊人員忘了考慮權限問題（雖然eCTD一般不考慮權限，但在內部審閱版本時可能有）。不過更常見的錯誤是內部鏈接循環，比如A鏈接到B，B又鏈接回A，這在某些驗證工具里會被標記為warning。
我的建議是：每做一個超鏈接，都要在最終的完整包里面實際點一下，確認能跳過去。不要只在源文件里測試，要在最終生成的eCTD文件夾結構里測試?？得宓馁|量部有個 checklist，最后一步永遠是"全鏈接遍歷測試"，雖然枯燥，但能救命。
文件名看起來是最沒技術含量的，但犯錯率極高。eCTD對文件名有嚴格規定：只能使用字母、數字、連字符、下劃線，不能有中文、空格、特殊符號。曾經有人把文件名寫成"階段性報告(最終版).pdf"，括號就是非法字符。還有用"—"（中文破折號）代替"-"（英文連字符）的，肉眼幾乎看不出區別，但系統能識別。
元數據（metadata）填寫也是，比如申請編號、版本號、日期格式。日期必須是DD-MMM-YYYY這種格式，寫成2024-01-01或者Jan 1, 2024都是錯的。這些小地方，單個看都不是大事，但累積起來就是 professionalism 的問題，也反映出制作流程不夠嚴謹。
另外，文件大小也有限制。雖然現在的系統支持大文件上傳，但單個PDF超過幾百兆還是會出問題，最好是控制在幾十兆以內。太大了要拆分，但拆分時又要注意邏輯完整性，不能把一個表格劈成兩半。
當你不是第一次提交，而是遞交補充申請或者回復問詢時，eCTD的生命周期操作（lifecycle operations）就登場了。這里最容易混淆的是replace和delete-and-add-new的區別。
簡單說，replace是用來更新一個已經存在的文件，比如你把3.2.S.2.3的供應商信息從A公司改成了B公司，這是replace。而如果你發現之前多交了一個完全不該交的文件，那是delete。但很多人會搞混，或者用了append（追加）其實想表達的是replace。這些操作在XML里的標簽寫法完全不同，如果用錯了，CDE看到的資料狀態就和你實際想表達的不一樣。
還有baseline的概念。每次提交新的序列，都要明確基于哪個baseline（通常是上一次獲批或者上一次提交的序列）。填錯了baseline，系統就會認為你在試圖修改一個不存在的歷史版本，直接報錯。
寫到這里，你可能會覺得eCTD申報太苛刻了，規矩多得記不住。但我在康茂峰這些年觀察下來，那些總能一次就通過驗證的客戶，往往不是因為他們技術多牛，而是因為他們有一套固化的檢查流程。
比如，在點擊"生成最終包"之前，必須有第二個人獨立核對XML和實際文件的一致性；比如，所有的PDF轉換必須使用經過驗證的虛擬打印機設置，而不是隨意另存為；比如，建立了一個錯誤案例庫，每次新項目開始前，先把之前犯過的錯過一遍，提醒自己別在同一個坑摔倒。
eCTD申報本質上是個精細活，像繡花一樣，針腳密了慢了，反而比快更快。那些被打回的資料，通常不是因為申請人不懂這些規則，而是因為趕時間、嫌麻煩、存僥幸。其實CDE的驗證標準都是公開的，每一版《eCTD技術規范》都寫得清清楚楚，花時間吃透這些文檔，比后期返工要劃算得多。
最后想說的是，別把eCTD當成負擔。它確實增加了工作量，但一旦你把這套邏輯內化成習慣，你會發現資料管理變得異常清晰，找歷史文件快多了，跨部門協作也順暢了。畢竟，規整的文件夾、有效的書簽、清晰的鏈接，這些本就是好的文檔管理應該具備的特質，eCTD只是把它標準化了而已。
下次準備提交資料前，不妨先停下來，把這篇文章里提到的幾個點在心里過一遍。文件夾結構對不對？PDF版本是1.4嗎？書簽到不到位？XML里面的指紋值重新算過了嗎？這些瑣碎的問題搞定了，你的申報之路就順暢了一大半。
