最近不少同行在聊eCTD提交的問題，我發現大家對技術細節聊得挺多，但真正落到文件屬性這個層面時，反而有點懵。文件屬性聽起來挺簡單，不就是給文件起個名、存個位置嗎？但真正操作起來，門道可不少。今天咱們就聊聊這個話題，看看在實際工作中，哪些地方容易出問題，又該怎么避開那些坑。
先說句題外話，我在康茂峰這些年，見過太多因為文件屬性沒處理好而導致提交的案例了。有的被打回來要求重新整理，有的直接在驗證環節就卡住了，浪費的都是時間和精力。所以這篇文章，想把文件屬性這個看似基礎但又特別關鍵的部分，給大家掰開揉碎了講清楚。
eCTD，也就是電子通用技術文檔，是制藥行業提交 regulatory文件的標準格式。很多朋友可能覺得這玩意兒就是把所有文件打包上傳就行，但事實遠非如此。eCTD本質上是一套結構化的信息管理體系，每個文件都有它對應的"身份標識"，這些標識就是我們說的文件屬性。
你可以把文件屬性理解成文件的"身份證"。想想看，在一個完整的eCTD包里，可能包含成百上千個文件，審查人員怎么快速找到他們需要的內容？系統怎么知道各個文件之間的邏輯關系？靠的就是這些屬性。屬性設置對了，整個包脈絡清晰；屬性設置錯了，后續的審評和溝通都會變得特別費勁。
這里有個概念需要澄清一下。eCTD規范里對文件屬性的要求主要來自ICH和各個地區的regulatory機構，比如FDA、EMA，還有我們國家的NMPA。雖然大方向一致，但具體細節上還是有差異的。所以咱們在準備文件的時候，首先得搞清楚目標是哪個地區，然后按照對應的要求來配置屬性。
說到文件命名，這可能是最基礎但也最容易出錯的地方。很多朋友剛開始做eCTD的時候，喜歡用中文文件名，或者包含特殊字符的名字，覺得這樣看起來一目了然。但這樣做往往會帶來意想不到的麻煩。
先說命名規則本身。eCTD對文件名有嚴格的要求：只能使用字母、數字、下劃線和連字符，而且不建議使用中文和特殊符號。為什么這么規定？因為不同系統、不同地區的服務器對字符集的支持不一樣，一個在你電腦上顯示正常的文件名，傳到regulatory機構的系統里可能就變成亂碼了。到時候找不到對應文件，整個提交都會出問題。
還有一點值得注意的是文件名長度。大多數監管機構對文件名長度有限制，一般建議不超過64個字符。雖然這個長度看起來挺寬裕，但如果文件名取得太啰嗦，或者包含了版本號、日期之類的信息，很容易就超了。我的建議是，文件名盡量簡潔明了，能用縮寫就用縮寫，把詳細信息放到文件的元數據里去。
另外，文件名在同一個模塊內必須唯一，這個很多人會忽略。假設你在模塊3里放了兩個都叫"study-report.pdf"的文件，系統在驗證的時候就會報錯，因為無法區分。所以取名的時候，最好加一些區分標識，比如加上研究編號或者章節編號。
文件格式的選擇看似簡單，實際上直接影響著后續的審閱體驗。eCTD提交對格式是有明確要求的，PDF是最通用的格式，但也不是隨便一個PDF都行。
先說PDF的版本。現在普遍接受的是PDF 1.4及以上版本，但如果你用特別新的PDF 2.0，有些老系統可能讀不了。另外，PDF里面不要使用加密或者數字簽名功能——這倒不是說不能用電子簽名，而是說提交前的文件不應該有訪問限制，否則審評人員打不開就很尷尬了。
關于文件大小，各地區的要求不太一樣。FDA一般建議單個文件不超過500MB，EMA可能更嚴格一些。文件太大的話，審閱系統加載起來會很慢，影響工作效率。如果你的文件確實很大，比如生物樣本分析報告這種動輒幾百兆的，可以考慮拆分處理。但拆分的時候要注意保持文件的完整性，別把一個表格拆得七零八落的。
還有一點容易被忽視：圖片和表格的分辨率。提交審評的文件，需要保證文字清晰可讀，但圖片分辨率也不宜過高。一個滿是高分辨率圖片的PDF，文件大小會飆升，而且審閱系統不一定能良好顯示。我的經驗是，文字部分300dpi就足夠了，圖片可以適當提高，但沒必要追求攝影級的分辨率。
eCTD的目錄結構是它的精髓所在，也是最能體現文檔邏輯性的地方。一個好的目錄結構，應該讓審評人員能夠快速定位到他們需要的信息，而不需要在層層文件夾里反復翻找。
eCTD的目錄結構遵循ICH M4指南的基本框架，分成模塊1到模塊5。模塊1是地區行政信息，模塊2是CTD概要，模塊3是質量部分，模塊4是非臨床研究報告，模塊5是臨床研究報告。這個框架是固定的，但我們可以在這個框架內靈活組織文件。
在實際操作中，我建議采用"扁平為主、層級為輔"的原則。也就是說，能放在同一層級的東西就盡量放在一起，避免嵌套太深。比如一個研究的所有文件，可以放在以研究編號命名的文件夾下，而不是按照文件類型分散在不同的文件夾里。這樣審評人員想看某個研究的時候，直接點進去就能看到所有相關文件，不用在不同目錄之間跳來跳去。
另外，每個文件夾里建議放一個readme文件，說明這個文件夾里大概有什么內容。這不是eCTD的強制要求，但確實能提升用戶體驗。特別是對于那種包含很多子文件夾的復雜結構，有個readme文件能幫審評人員快速建立整體認知。
如果說文件名是文件的"小名"，那元數據就是文件的"大名"和"詳細檔案"。eCTD通過xmpmetaData來記錄每個文件的關鍵信息，這些信息對于文件的管理和檢索至關重要。
元數據里最核心的幾個字段包括：文件標題（Title）、創建日期（CreationDate）、修改日期（ModificationDate）、作者（Creator）。這些字段要如實填寫，別想著在上面玩什么花樣。有些申報團隊為了顯示文件是"最新版本"，把修改日期改成很近的時間，這種做法其實很容易被識破，而且對審評沒有任何幫助。
還有幾個字段容易被人忽略但同樣重要：Keywords和Description。Keywords可以用來標記文件的關鍵主題，方便后續檢索；Description則可以提供更詳細的說明，比如說明這個文件是某個研究的哪個版本。這些信息在文件少的時候可能感覺不到價值，但一旦文件數量多了，就能體會到它們的好處了。
在康茂峰的項目實踐中，我們通常會建立元數據模板，確保每個文件都按照統一的標準填寫。這樣做的好處是，后續如果需要修改或者補充信息，能夠保持一致性，不會出現有的文件有這個字段、有的文件沒有的情況。
eCTD提交不是一次性買賣，一個注冊申請在生命周期內可能會經歷多次更新。版本控制做得好不好，直接影響著后續變更管理的效率。
關于版本號，業界有一些約定俗成的規則。大版本號用整數表示，比如1.0、2.0，表示重大的結構性變化；小版本號用小數表示，比如1.1、1.2，表示小幅修訂。在文件屬性里，要明確標注目前是哪個版本，這樣審評人員就能知道這個文件相對于之前提交的內容有什么變化。
這里有個小技巧：對于每次提交的文件，最好在文件屬性里注明"supersedes"信息，說明這個文件取代了之前提交的哪個版本。這樣做不僅幫助審評人員理解文件的歷史沿革，也方便我們自己進行檔案管理。
還有一點要提醒：不要過度版本化。有些團隊每個小改動都出一個新版本，導致版本號飆升。實際上，版本號應該反映文件的實質性變化，單純的格式調整或者typo修復，沒必要單獨出一個版本。保持版本號的簡潔和有意義，是專業團隊的基本素養。
聊了這么多技術細節，最后說說實際操作中容易踩的坑吧。這些經驗都是實打實總結出來的，希望能幫大家少走彎路。
第一個坑是字符編碼問題。中文文件名在某些系統環境下可能出現亂碼，這個前面提到過。解決方案是統一使用英文文件名，或者使用Unicode兼容的編碼方式。但在實際操作中，我建議還是盡量用英文，從根本上避免這個問題。
第二個坑是文件鏈接失效。eCTD包里的超鏈接要確保指向正確的位置，而且鏈接目標要在包內存在。有些文件在本地測試的時候鏈接沒問題，但到了regulatory系統里因為路徑結構變化就失效了。建議在正式提交前，用驗證工具全面檢查一遍所有鏈接。
第三個坑是時區混亂。文件創建日期和修改日期在不同時區之間可能產生差異。比如你在中國創建的文件，顯示的時間可能和歐洲審評人員看到的不一致。解決方案是在元數據里統一使用UTC時間，并在文檔說明里注明。
第四個坑是附件遺漏。有時候一個主文件引用了附件，但附件沒有一起打包，或者附件的路徑寫錯了。這種問題很難通過自動化工具完全發現，往往需要人工檢查。建議在提交前，逐一核對每個文件引用的外部資源是否都包含在包內。
eCTD文件屬性這個話題，看似瑣碎，其實蘊含著很多講究。從文件名到目錄結構，從元數據到版本控制，每一個環節都影響著最終提交的質量和效率。
做文檔管理這些年來，我越來越覺得，這項工作做的其實就是"可維護性"和"可讀性"。一個好的eCTD包，不僅要通過監管機構的驗證，更要讓后續的審評、溝通、變更都變得順暢。而達到這個目標，就需要我們在文件屬性這種細節上下功夫。
如果你正在為eCTD提交頭疼，不妨從最基本的文件屬性檢查開始。很多看似復雜的問題，其實都是由一些基礎性的疏漏造成的。把基礎打牢，后續工作會輕松很多。
