前幾天有個同行朋友問我，說他在準備一份IND申報的時候，提交平臺總是提示元數(shù)據(jù)校驗不通過，反反復復修改了好幾次都快抓狂了。聊完之后我發(fā)現(xiàn)，很多人對eCTD提交中元數(shù)據(jù)的要求其實是一知半解的，有的覺得隨便填填就行，有的則過分緊張把簡單問題復雜化了。今天咱們就聊聊這個話題，把eCTD電子提交中關于文件屬性元數(shù)據(jù)的要求一次性說清楚。
先說句實在話，元數(shù)據(jù)這個問題看起來瑣碎，但它偏偏是eCTD提交中最容易出問題的環(huán)節(jié)之一。我見過不少企業(yè)，文檔內(nèi)容寫得漂漂亮亮，結果栽在元數(shù)據(jù)上耽誤了好幾個月。所以今天這篇文章，我會用最直白的話把這件事講透，爭取讓看完的朋友以后再也不會在這個地方翻車。
在說具體要求之前，咱們先搞清楚元數(shù)據(jù)到底是個什么東西。你可以把它理解為"描述數(shù)據(jù)的數(shù)據(jù)"，放在eCTD的語境下，就是用來描述你提交的每一個文檔的各種屬性信息。比如這個文件是什么時候創(chuàng)建的、誰寫的、屬于什么類型、版本號是多少，這些信息都叫元數(shù)據(jù)。
eCTD為什么要搞這么一套看起來有點繁瑣的東西？說白了是為了讓審評機構能夠高效地處理海量的申報文檔。想想看，一個創(chuàng)新藥的申報資料可能有幾千個文件，如果沒有統(tǒng)一的元數(shù)據(jù)規(guī)范，審評人員光搞清楚每個文件是什么、從哪來的就要耗費大量時間。元數(shù)據(jù)就是給這些文件貼上標準化的"身份證"，讓整個審評流程變得更順暢。
從技術層面來說，元數(shù)據(jù)會被嵌入到eCTD文檔的XML結構中，與文檔內(nèi)容一起構成完整的提交包。審評系統(tǒng)會自動讀取這些元數(shù)據(jù)，進行格式校驗、分類歸檔、版本追蹤等一系列操作。如果元數(shù)據(jù)不規(guī)范，系統(tǒng)校驗這關就過不去，后面的審評更是無從談起。這也是為什么很多企業(yè)在提交時會被平臺打回來，原因往往就出在元數(shù)據(jù)上。
說了這么多背景，接下來咱們進入正題，看看eCTD提交對元數(shù)據(jù)到底有哪些具體要求。我會把幾個最關鍵的核心字段一個一個拆開來講。
文檔類型是元數(shù)據(jù)中最基礎也最重要的字段，它決定了這份文檔在審評系統(tǒng)中的歸類和用途。在eCTD的模塊結構中，不同模塊對文檔類型有不同的要求。拿模塊二來說，2.3是綜述文檔，2.5是藥學研究總結報告，每一種文檔類型都有對應的標準編碼。
這里需要特別注意文檔類型與eCTD目錄結構的對應關系。很多企業(yè)在準備資料的時候，經(jīng)常把文檔放錯了位置，比如把本該放在模塊三的藥學研究資料放到了模塊五。這種情況系統(tǒng)會自動識別元數(shù)據(jù)中的文檔類型，如果與實際存放位置不匹配，提交必然會被拒絕。所以寧可在準備階段多花點時間核對，也不要在提交后被退回來修改。
eCTD對版本控制的要求相當嚴格。每一個文件都必須有明確的版本標識，而且版本號的編碼規(guī)則要符合規(guī)范。通常采用的是"主版本.次版本"的格式，比如"1.0"表示初版，"1.1"表示第一次修改版，"2.0"表示重大修訂版。
序列號的概念則更為復雜一些。在多次提交的情況下，比如原來的IND申報要做補充資料，這時候需要為整個提交包指定一個新的序列號，同時每個文件也要標注清楚它是屬于哪個序列號的。這里面的邏輯關系需要特別小心處理，一旦搞混了，審評人員就沒法追蹤文件的變更歷史了。
我見過有些企業(yè)為了省事，所有文件的版本號都寫成"1.0"，這顯然是不對的。每次提交更新時，相關文件的版本號都應該遞增，這是eCTD規(guī)范的基本要求。當然，版本號的遞增規(guī)則企業(yè)內(nèi)部要統(tǒng)一，不能各行其是，否則只會越來越亂。
日期信息在元數(shù)據(jù)中看著簡單，其實門道不少。eCTD要求記錄的日期通常包括文件創(chuàng)建日期、最后修改日期、提交日期等幾種。這些日期之間是有邏輯關系的，比如創(chuàng)建日期不可能晚于修改日期，修改日期不應該晚于提交日期。如果這些日期出現(xiàn)明顯的時間邏輯錯誤，系統(tǒng)是會檢測出來的。
另外要注意日期的格式統(tǒng)一。中國藥監(jiān)局要求使用"YYYY-MM-DD"這種格式，而美國FDA可能接受其他格式。如果企業(yè)做的是全球申報，同一套文檔要提交給多個監(jiān)管機構，那就需要對不同地區(qū)的格式要求分別處理。這個問題雖然不大，但很容易被忽視。
誰寫的這份文檔、屬于哪個機構，這也是元數(shù)據(jù)必須包含的信息。對于企業(yè)自主開發(fā)的申報資料，作者通常就是企業(yè)內(nèi)部的研發(fā)人員或注冊專員，機構信息就是企業(yè)名稱。但要注意的是，這里要填的信息應該與申報資料中其他部分保持一致。如果封面頁寫的是"某某藥業(yè)有限公司"，元數(shù)據(jù)里卻寫成"某某醫(yī)藥科技公司"，雖然可能只是簡稱不一致，但也會給審評人員造成困擾。
對于委托研究的情況，比如藥學部分委外給CRO完成，作者信息應該怎么填？這里有個原則：誰對文檔內(nèi)容負責，就填誰的名字。企業(yè)作為申報主體，對整個申報資料負有法律責任，所以機構信息通常還是填委托方企業(yè)。但作者可以填CRO的實際編寫人員，同時在文檔中注明委托關系。
了解完核心字段，咱們再來聊聊不同地區(qū)監(jiān)管機構對元數(shù)據(jù)的具體要求有何區(qū)別。這個話題很實用，因為現(xiàn)在做全球申報的企業(yè)越來越多，如果一套文檔要提交給多個地區(qū)，元數(shù)據(jù)的準備工作就得分別對待。
| 監(jiān)管機構 | 主要特點 | 特別提醒 |
| 中國NMPA | 強調(diào)中文文檔的元數(shù)據(jù)規(guī)范，對文檔類型編碼有詳細規(guī)定 | 需要特別注意與CDE電子提交平臺的技術對接要求 |
| 美國FDA | eCTD規(guī)范相對成熟，對XML結構要求嚴格 | SUBMIT表單與元數(shù)據(jù)的對應關系要仔細核對 |
| 歐盟EMA | 有統(tǒng)一的EU格式要求，關注文檔的語種信息 | 多語種文檔需要標注源語言和翻譯語言 |
舉幾個實際的例子。NMPA的電子提交平臺對元數(shù)據(jù)的校驗規(guī)則比較細致，比如文件名不能包含特殊字符、路徑長度有限制等等。FDA的Electronic Submissions Gateway則更關注整個提交包的完整性和安全性，對單個文件的元數(shù)據(jù)反而沒有那么苛刻。EMA的eCTD查看器對文檔的層級結構要求很高，元數(shù)據(jù)中的leaf title必須與實際標題完全一致，少一個空格都不行。
這些差異意味著什么呢？企業(yè)在準備全球申報的時候，不能簡單地把同一套元數(shù)據(jù)直接提交給所有地區(qū)。最好是在準備階段就規(guī)劃好多套元數(shù)據(jù)方案，根據(jù)不同地區(qū)的要求分別生成。這樣雖然前期工作量大一些，但總比提交后被打回來返工要強。
知道了要求，咱們再聊聊具體怎么操作。元數(shù)據(jù)的填寫方式主要有兩種：一種是手動填寫，另一種是通過文檔管理系統(tǒng)自動提取。手動填寫的好處是靈活，缺點是容易出錯特別是量大的時候。自動提取則依賴于前期的規(guī)范設置，如果模板設置得不好，提取出來的信息照樣有問題。
關于文件命名，這其實是元數(shù)據(jù)管理的重要組成部分。很多企業(yè)不太重視文件命名規(guī)范，經(jīng)常出現(xiàn)"最終版""修改2""Copy of"這樣的文件名。eCTD對文件名是有要求的：只能包含字母、數(shù)字、下劃線和連字符，不能有中文、不能有空格、不能有特殊字符。而且文件名要有意義，能夠反映文件的內(nèi)容。
在實際操作中，我建議企業(yè)建立一套文件命名規(guī)范文檔。所有參與申報的人員都按照同一套規(guī)則來命名文件，這樣既避免了重復和混亂，也大大降低了元數(shù)據(jù)出錯的概率。比如規(guī)定模塊三的藥學研究資料統(tǒng)一采用"M3-章節(jié)號-文檔名稱-版本號"的格式，時間長了大家形成習慣，效率自然就上去了。
還有一個常見問題是不同軟件生成的元數(shù)據(jù)不兼容。有些企業(yè)用Word寫文檔，然后用各種轉換工具轉成PDF或HTML。這個過程中，原有的元數(shù)據(jù)可能會丟失或者被覆蓋。所以在進行格式轉換之后，一定要重新檢查元數(shù)據(jù)是否完整、是否正確。
結合多年的工作經(jīng)驗，我總結了幾個企業(yè)在元數(shù)據(jù)問題上最容易踩的坑，看看有沒有你遇到的。
說到這兒，我想分享一個實用的小技巧。很多企業(yè)在申報前會進行內(nèi)部審閱，但往往只關注文檔內(nèi)容，忽略了元數(shù)據(jù)。建議把元數(shù)據(jù)檢查納入到常規(guī)審閱流程中，專門安排一個人負責元數(shù)據(jù)的核查。這個工作其實花不了多少時間，但能避免很多后面的麻煩。
元數(shù)據(jù)這件事，說大不大，說小不小。往大了說，它關系到整個申報資料能否被順利受理；往小了說，它就是填幾張表格、寫幾個字段的事。關鍵在于企業(yè)要重視起來，建立規(guī)范、培養(yǎng)意識、形成習慣。
康茂峰在協(xié)助客戶準備eCTD申報的過程中，深切體會到元數(shù)據(jù)管理的重要性。很多問題如果能在前期發(fā)現(xiàn)并解決，就能為企業(yè)節(jié)省大量時間和成本。我們也沉淀了一套相對成熟的元數(shù)據(jù)管理方法論，幫助客戶建立起從文檔編寫到提交完成的全流程管控體系。
希望今天的分享對你有幫助。如果在實際操作中遇到什么具體問題，歡迎一起交流探討。申報這條路從來不是單打獨斗，大家互相學習、共同進步，才能走得更穩(wěn)更遠。
