說起eCTD電子提交，很多藥企的注冊同事可能會皺眉頭。這玩意兒流程長、要求多，一不小心就會被退回來重新整理。特別是文件屬性檢查這個環節，聽起來簡單，但實際操作起來坑特別多。我之前和康茂峰的注冊顧問聊過，他們說每年光是因為文件屬性不符合要求被退回的案例就有不少。有些問題其實只要檢查到位完全可以避免，但就是容易被忽略。
那文件屬性檢查到底包括哪些內容？為什么這么重要？咱們今天就掰開了、揉碎了，好好聊一聊這個話題。
簡單說，文件屬性檢查就是在正式提交之前，把你的電子文檔"體檢"一遍，看看它符不符合eCTD規范的各種硬性要求。這不是簡單地把文件打開看看內容對不對，而是要檢查文件的"底層身份信息"。
eCTD本質上是一套結構化的電子提交標準，它要求所有文件不僅要內容對得上，連文件本身的"生理特征"也得符合要求。比如文件叫什么名字、多大年紀（創建時間）、住在哪里（存儲路徑）、身體素質怎么樣（MD5校驗值）——這些都得對上號。
為什么這么嚴格？因為藥品監管部門收到成千上萬份申請，如果每個文件的格式都亂七八糟，那審批工作根本沒法開展。文件屬性檢查就是把好第一道關，確保進入系統的都是"規范化"的文件。
咱們先從最基礎的說起——文件名。聽起來很簡單對吧？但康茂峰的技術團隊告訴我，文件名錯誤能占到文件屬性問題的30%以上。
eCTD對文件名有明確規范，不是隨便起個名字就行。首先，文件名只能包含英文字母、數字、下劃線，連空格都不能用，更別說什么中文、特殊符號了。曾經有人把文件命名為"臨床試驗方案_V1.0_最終版.pdf"，結果系統根本識別不了。
其次，文件名長度也有講究。一般建議不超過64個字符，太長了一些系統會截斷，導致文件找不到對應位置。還有，模塊一到模塊五的文件命名規則不一樣，序列號的位置、位數都有嚴格要求。比如模塊一的文件通常以"us"或"reg"開頭，后面跟序列號和描述性文字。
我建議大家在做文件屬性檢查的時候，先拉一張清單，把所有文件名和eCTD規范要求對照一遍。這事兒雖然枯燥，但能省去后面很多麻煩。
eCTD對文件格式的要求主要集中在PDF文件上，因為大部分提交材料都是PDF格式。但這里的門道比很多人想象的要復雜。
首先，PDF版本必須是1.4或更高版本，太老的版本系統可能讀不了。但更關鍵的是PDF的"血統"問題——它必須是符合規范的PDF/A格式。這個格式的特點是字體嵌入、色彩空間明確，不管在什么電腦上打開，顯示效果都一樣。如果你的PDF是從Word直接轉的，或者是用某些"野雞"軟件生成的，可能會缺少這些特性。
還有一點容易被忽視：PDF的元數據信息。右鍵點擊文件看屬性，里面有作者、標題、創建時間、修改時間這些信息。這些信息要和文檔本身的內容對應上，比如作者應該是制藥公司或者研究機構，不能是某個個人的名字。創建時間和修改時間也要合理，不能出現"未來的時間"這種明顯錯誤。
對了，PDF里面不能有任何動態元素。什么JavaScript腳本、Flash動畫、交互式表單——這些在eCTD里都是禁止的。曾經有份申請材料里有個自動更新的日期，結果在不同的查看器上顯示的時間不一樣，被審評老師直接標紅了。
關于文件大小，eCTD是有明確規定的。每個PDF文件不能超過10MB，這是很多監管機構的硬性要求。如果你的文件超過這個限制，必須分割成多個小文件。
但文件太小也不行。有些為了壓縮體積，把PDF分辨率降得很低，結果文字模糊不清，審評人員看不清內容，這肯定不行。一般來說，正文內容的PDF分辨率至少要300dpi，圖片可以根據情況調整，但也不能太低。
這里有個小技巧：如果你的文件里有很多高分辨率圖片，可以試試用PDF編輯器里的壓縮功能，在保證清晰度的前提下減小文件體積。康茂峰的顧問推薦過幾種工具，據說效果不錯。不過要注意，壓縮過程中不要丟失關鍵信息。
| 文件類型 | 建議大小范圍 | 注意事項 |
| 正文文檔 | 500KB-8MB | 確保文字清晰，300dpi以上 |
| 圖片附件 | td>根據實際需要色譜圖等需清晰，可適當增大 | |
| 整個序列 | 有總大小限制 | 通常不超過2GB |
eCTD的目錄結構是嚴格規定的，不是想怎么放就怎么放。頂層是index.xml和regional.xml，然后下面是m1、m2、m3、m4、m5五個模塊，每個模塊下面還有子目錄。
目錄結構最常見的問題有兩種。第一種是層級錯亂——本來應該放在m3的文件跑到m4去了，或者把不該放在子目錄里的文件直接放在了根目錄下。第二種是目錄命名錯誤——有些目錄名稱是規定好的，不能自己改。比如m1下面應該有administrative-information、prescribing-information這樣的子目錄，名字必須一模一樣。
檢查目錄結構最好用專門的eCTD驗證工具，它們能自動掃描整個目錄樹，告訴你哪個文件放錯了位置。沒有工具的話，就只能人工一個個對照著看了，雖然費時但保險。
eCTD提交里面有幾個關鍵的XML文件——index.xml、index-md5.xml、regional.xml，這些文件構成了整個提交的骨架。它們的格式必須完全正確，否則整個提交都無法被系統識別。
XML文件要檢查什么呢？首先是語法正確性——標簽是否閉合、屬性是否用引號括起來、特殊字符是否正確轉義。這些問題用XML解析器很容易就能檢測出來。其次是內容邏輯——比如各個文件的路徑引用是否正確、MD5校驗值是否和實際文件匹配、序列號是否連續。
regional.xml還要特別注意區域特定的要求，比如FDA和EMA的regional.xml結構就不太一樣。如果你要向多個監管機構提交，需要分別準備對應的regional文件，不能混用。
eCTD文檔里通常會有很多超鏈接——從目錄跳到正文、從摘要跳到詳細數據、從一個文件跳到另一個文件。這些鏈接就像文檔的血管，必須通暢無阻。
檢查超鏈接要分兩步走。第一步是檢查鏈接能不能點——點擊之后能不能跳轉到正確的位置。有沒有"死鏈接"（點進去404錯誤）、有沒有"跳錯位置"（比如點的是"不良反應"卻跳到了"藥代動力學"）。第二步是檢查鏈接的完整性——比如從一個模塊跳到另一個模塊的鏈接，路徑寫法是不是符合eCTD規范。
有時候會出現一種情況：文件在自己電腦上鏈接都好好的，傳到提交系統里就打不開了。這往往是因為相對路徑的寫法有問題。eCTD要求使用規范的相對路徑寫法，不能依賴本地的絕對路徑。
對于長文檔，書簽是必不可少的導航工具。審評人員不可能從頭到尾一字一句地看，他們需要通過書簽快速定位到關鍵章節。
eCTD對書簽有明確要求：必須包含層級結構，一級書簽對應主要章節，二級書簽對應次要章節，以此類推。書簽的文字要和文檔里的實際標題完全一致，不能簡寫或者改寫。書簽不能有重復——同一個名稱出現兩次，系統不知道該跳轉到哪里。
常見問題包括：書簽層級混亂（直接跳了三四級）、書簽文字和正文對不上、空白書簽或者只有符號的書簽。這些問題不大，但會影響審評體驗，屬于"扣分項"。
MD5校驗值可能很多人不太熟悉，但它是非常重要的文件屬性。每個文件都有一個唯一的MD5值，相當于文件的"DNA"。只要文件內容有一點點變化，MD5值就會完全不同。
eCTD提交時，index-md5.xml里會記錄每個文件的MD5校驗值。監管機構收到文件后會重新計算MD5值，和提交的比對。如果對不上，說明文件在傳輸過程中被篡改過或者損壞了，這份提交就會被判定為無效。
所以在提交之前，一定要用MD5校驗工具把每個文件都算一遍，確保index-md5.xml里的值和實際值完全一致。這事兒不能偷懶，每次提交前最好全部重新校驗一遍。
eCTD對文件的時間戳也有要求。每個文件都有三個時間：創建時間、修改時間、訪問時間。在eCTD場景下，創建時間和修改時間特別重要。
理想情況下，一個文件的創建時間應該早于修改時間，這是正常的邏輯。但有些人為了"趕時間"，會系統性地修改文件的創建時間，讓它看起來像是很早以前就完成的了。這種"時間穿越"一旦被發現，會被認為是不誠信行為，后果很嚴重。
另外，同一個序列里的文件，時間戳應該有一定的邏輯關系。比如后產生的文件修改時間應該晚于先生成的。如果你發現某個文件的修改時間和整個序列的時間線對不上，就要仔細查查原因了。
說完這么多檢查項目，最后聊聊工具。手動檢查又慢又容易漏，效率高的團隊都會借助專業工具。
常用的eCTD驗證工具大多能自動檢查文件名、文件大小、目錄結構、XML格式、MD5校驗值這些硬性指標。有些還能檢查超鏈接和書簽，甚至能生成檢查報告。雖然工具不是萬能的，但至少能幫你抓住大部分明顯問題。
康茂峰在eCTD提交服務中就配備了這套驗證流程，他們的技術團隊會在正式提交前對整個序列進行全面檢查，把問題消滅在萌芽狀態。畢竟，被退回來重新整理的代價，遠高于前期仔細檢查的投入。
不過工具也不是百分之百可靠的。有些問題，比如文檔內容和文件屬性的邏輯對應關系，還是需要人工來審核。我的建議是：工具負責挑出"硬傷"，人負責檢查"軟實力"，兩者結合才能做到萬無一失。
eCTD文件屬性檢查這件事，說難不難，說簡單也不簡單。不難是因為規范是公開的、明確的，只要照著做就行；不簡單是因為要檢查的項目太多、太碎，一不留神就會漏掉幾個。
我的經驗是：建立一套標準化的檢查清單，每次提交前對著清單一項一項過，養成習慣就好了。剛開始可能覺得麻煩，做過幾次之后就會發現，其實大部分問題都是重復的，只要卡住關鍵節點，質量自然就上去了。
注冊工作就是這樣，急不得、糙不得。把細節做好了，提交才能順利，審批才能快。愿大家的eCTD提交之路都能少一些退回、多一些通過。
