說實(shí)話，第一次接觸eCTD的時(shí)候，我也以為這不過是把紙質(zhì)文件掃個(gè)碼、傳上網(wǎng)的事兒。直到看見同事盯著退回的序列號(hào)一臉懵，才發(fā)現(xiàn)這玩意兒的水深得很——PDF書簽嵌套不能超過四級(jí)？超鏈接必須指向具體段落而不能是整個(gè)文檔？字體嵌入還要考慮子集化？這些細(xì)枝末節(jié)的規(guī)矩，真的能逼瘋一幫搞注冊(cè)的老手。在康茂峰處理過的幾百個(gè)申報(bào)案例里，今天這個(gè)報(bào)錯(cuò)明天那個(gè)退回，反反復(fù)復(fù)其實(shí)就那幾類問題。咱們今天就掰開了揉碎了聊聊，到底哪些地方最容易翻車。
咱們先說最基礎(chǔ)的PDF制作。很多人納悶：我用最新版軟件導(dǎo)出的文件，怎么一上傳就報(bào)"字體未嵌入"？問題在于，eCTD對(duì)PDF的要求不是"能打開看"就行，而是要保證在任何一臺(tái)電腦上顯示效果完全一致。這就導(dǎo)致了第一個(gè)大坑——字體。
常見的情況是，你用了某種漂亮的系統(tǒng)字體做表格，看起來好好的，傳到審評(píng)系統(tǒng)里就變成了亂碼或者宋體。解決方式聽起來簡(jiǎn)單：嵌入所有字體。但實(shí)際操作中，子集化嵌入和完全嵌入的區(qū)別又讓人頭大。康茂峰的技術(shù)團(tuán)隊(duì)遇到過最極端的案例，是一個(gè)化學(xué)藥申報(bào)資料因?yàn)榍度肓艘惶咨У幕瘜W(xué)符號(hào)字體，導(dǎo)致PDF體積暴漲到系統(tǒng)拒絕接收。最后只能手動(dòng)拆分，重新做子集化處理，來來回回折騰了兩天。
書簽層級(jí)是個(gè)典型的隱形殺手。ICH規(guī)范里寫得明白：四級(jí)以上嵌套就可能導(dǎo)致某些官方閱讀工具解析異常。但問題在于，很多制作人員習(xí)慣性地按照Word標(biāo)題樣式一鍵生成書簽，根本不管已經(jīng)嵌套了五六層。
比如模塊二的概要部分，理論上應(yīng)該是：
這已經(jīng)是三層了。如果你在2.3.S.1下面再細(xì)分特性、結(jié)構(gòu)式、分子量，很容易就超標(biāo)。審評(píng)老師打開文件點(diǎn)擊左側(cè)導(dǎo)航，發(fā)現(xiàn)點(diǎn)進(jìn)去直接卡死或者顯示空白，這印象分可就扣大了。更麻煩的是，書簽的文本描述還必須和實(shí)際頁(yè)面標(biāo)題一字不差，中英文混排時(shí)空格全角半角不對(duì)都會(huì)觸發(fā)驗(yàn)證警告。
另一個(gè)技術(shù)細(xì)節(jié)是超鏈接。很多人以為做個(gè)鏈接能點(diǎn)過去就行了，但eCTD要求的是跨文檔精準(zhǔn)定位。鏈接指向整個(gè)文件不行，必須落到具體段落；鏈接路徑用絕對(duì)路徑不行，必須是相對(duì)路徑。康茂峰去年處理過一個(gè)補(bǔ)充申請(qǐng)，申報(bào)方把穩(wěn)定性數(shù)據(jù)指向了模塊三的質(zhì)量文件，路徑寫得是"C:\Users\張三\Desktop\資料\..."，這種絕對(duì)路徑在審評(píng)系統(tǒng)里當(dāng)然打不開，直接被判為 broken link 退回。
技術(shù)問題好歹有軟件能檢查，內(nèi)容組織上的坑更隱蔽。eCTD的骨架是那五個(gè)模塊，但文件到底該放在哪個(gè)文件夾，粒度切分到多細(xì)，每個(gè)公司理解都不一樣。
最常見的混亂發(fā)生在模塊一和模塊三的交叉地帶。比如某張批記錄，既涉及處方工藝又涉及質(zhì)量控制，到底放在3.2.P.3還是3.2.S.2.2？這時(shí)候不能憑感覺，得看文件的主要屬性。如果這是為了證明工藝穩(wěn)定性，放生產(chǎn)部分；如果是為了證明檢測(cè)方法適用性，就得扔去分析部分。放錯(cuò)位置的后果是，審評(píng)老師在預(yù)期的地方找不到文件，直接給你開個(gè)deficiency。
new、replace、delete這三個(gè)操作的生命周期管理，是高級(jí)玩家的分水嶺。舉個(gè)例子，你在序列號(hào)0005里提交了一個(gè)文件，后來在0008發(fā)現(xiàn)這文件有錯(cuò)誤，想做替換。這時(shí)候用replace操作沒問題，但如果0005的那個(gè)文件其實(shí)是補(bǔ)充申請(qǐng)臨時(shí)提交的，主序列里根本沒有，那你就不能用replace，得重新new一個(gè)，然后delete舊的。
康茂峰見過最可惜的案例，是新藥申請(qǐng)到了發(fā)補(bǔ)階段，申報(bào)方想更新模塊二的概要，結(jié)果操作類型選錯(cuò)了選成delete，舊的刪了新的卻沒關(guān)聯(lián)上，導(dǎo)致審評(píng)系統(tǒng)里這一章節(jié)直接顯示"文件缺失"，審評(píng)老師以為資料沒交全，白白耽誤了兩周時(shí)間。
文件都準(zhǔn)備好了，點(diǎn)擊發(fā)送的那一刻，心跳往往最快。網(wǎng)關(guān)傳輸?shù)膯栴}通常分兩種：網(wǎng)絡(luò)層和信封層。
網(wǎng)絡(luò)層的問題比較直白，比如文件太大觸發(fā)超時(shí)。eCTD全套資料動(dòng)輒幾個(gè)G，有些地區(qū)的申報(bào)網(wǎng)關(guān)還特別挑瀏覽器，換臺(tái)電腦或者換個(gè)網(wǎng)絡(luò)環(huán)境可能就傳上去了。但更常見的是信封層錯(cuò)誤——就是那個(gè)XML格式的index文件和它的 envelope 信息沒對(duì)上。
比如你在index.xml里寫了提交編號(hào)是2024-ABC-001，但信封信息里手滑寫成了2024-ABC-01，少了一位零，系統(tǒng)可能直接拒收。還有申請(qǐng)類型，Original Application和Supplement的代碼填錯(cuò)了，整個(gè)包裹會(huì)被扔到完全不一樣的審評(píng)隊(duì)列里，等發(fā)現(xiàn)的時(shí)候可能半個(gè)月過去了。康茂峰的建議是，提交前一定要做完整的 envelope check，哪怕只是改個(gè)標(biāo)點(diǎn)符號(hào)，也要重新生成一遍索引。
序列號(hào)（Sequence Number）的連續(xù)性也是重災(zāi)區(qū)。理論上每次提交都要+1，從0000開始。但實(shí)際操作中，公司內(nèi)部可能同時(shí)跑著臨床申請(qǐng)、生產(chǎn)變更、 minor update 好幾條線，特別容易搞混。最慘的是跳號(hào)或者重號(hào)——比如0006還沒審?fù)昴兀?007先交上去了，或者兩個(gè)部門同時(shí)認(rèn)為下一個(gè)序列號(hào)是0012，結(jié)果系統(tǒng)里出現(xiàn)兩個(gè)0012，這在有些監(jiān)管機(jī)構(gòu)那里會(huì)被視為嚴(yán)重的流程失控。
現(xiàn)在各個(gè)地區(qū)的驗(yàn)證工具都越來越智能，能把你的eCTD包查個(gè)底朝天。但驗(yàn)證報(bào)告出來的那一堆warning和error，常常讓人看得頭皮發(fā)麻。
首先得分清楚fatal error、error、warning、note的級(jí)別。Fatal error是鐵定傳不上去的，比如MD5校驗(yàn)失敗或者XML格式損壞。但warning不代表不能交，它只是提醒你有潛在風(fēng)險(xiǎn)。康茂峰處理過一個(gè)生物制品申報(bào)，驗(yàn)證報(bào)告蹦出來八十多個(gè)warning，客戶當(dāng)場(chǎng)慌了，以為要重做。仔細(xì)一分析，七十多個(gè)是"書簽文本長(zhǎng)度超過50字符"這種 cosmetic issue，真正需要處理的就三個(gè)PDF加密問題。如果當(dāng)時(shí)真去逐個(gè)改那八十個(gè)警告，至少耽誤一周申報(bào)時(shí)間。
| 錯(cuò)誤類型 | 典型表現(xiàn) | 平均解決耗時(shí) | 緊急程度 |
| 書簽層級(jí)超標(biāo) | 嵌套深度>4級(jí)或循環(huán)引用 | 2-4小時(shí) | 中 |
| 字體未嵌入 | 文件顯示異常或亂碼 | 1-3小時(shí)（需重新生成） | 高 |
| 超鏈接斷裂 | 相對(duì)路徑錯(cuò)誤或錨點(diǎn)丟失 | 30分鐘-2小時(shí) | 中 |
| 生命周期沖突 | replace不存在的文件或重復(fù)new | 半天至一天（需邏輯梳理） | 高 |
| 信封信息不匹配 | 申請(qǐng)編號(hào)或類型代碼錯(cuò)誤 | 10分鐘-1小時(shí) | 致命 |
| MD5校驗(yàn)失敗 | 傳輸過程中文件損壞 | 視文件大小而定 | 致命 |
除了看得見的技術(shù)規(guī)范，還有一些軟性要求藏在審評(píng)指南的字里行間。比如文件命名習(xí)慣，雖然系統(tǒng)不強(qiáng)制要求，但一個(gè)官網(wǎng)上傳文件夾里全是"final_final_真的final_改logo版.pdf"這種命名，專業(yè)度可想而知。
再比如電子簽章的位置和層級(jí)。有些官方要求簽章必須出現(xiàn)在文檔屬性里可識(shí)別，光在最后一頁(yè)貼個(gè)掃描圖不行。還有勘誤和替換的透明度——如果你用新版本替換了舊文件，必須在申請(qǐng)信中明確說明變更內(nèi)容和理由，不能偷偷摸摸換掉就完事。康茂峰接觸過的一個(gè)案例，申報(bào)方發(fā)現(xiàn)模塊三的SOP寫錯(cuò)了版本號(hào)，悄無聲息地replace了，結(jié)果被審評(píng)部門追溯到變更歷史，質(zhì)疑數(shù)據(jù)完整性，這就上升到誠(chéng)信層面了。
如果你同時(shí)向多個(gè)國(guó)家和地區(qū)申報(bào)，事情更復(fù)雜。雖然ICH M2規(guī)定了統(tǒng)一的eCTD標(biāo)準(zhǔn)，但各地區(qū)執(zhí)行起來各有側(cè)重。有的地區(qū)對(duì)PDF/A格式要求特別死，有的地區(qū)則強(qiáng)制要求書簽必須包含特定關(guān)鍵詞。最頭疼的是跟隨函（Cover Letter）的格式——A地區(qū)要求必須放在模塊一第一位，B地區(qū)則要求單獨(dú)作為一個(gè)文件夾放在最外層。用同一套資料包提交不同地區(qū)，往往需要做本地化調(diào)整，而不是簡(jiǎn)單復(fù)制粘貼。
說了這么多問題，其實(shí)預(yù)防比補(bǔ)救重要得多。基于這些年處理的申報(bào)項(xiàng)目，建立標(biāo)準(zhǔn)化的制作流程是第一位的。建議在做第一個(gè)序列之前，先搭好目錄樹模板，定好文件命名規(guī)則，甚至做好書簽樣式的主文檔。
其次，版本控制工具必須用。不要用郵件傳來傳去改文件名管理版本，搞個(gè)正經(jīng)的文檔管理系統(tǒng)，誰能改、改了啥、什么時(shí)候改的，一目了然。康茂峰內(nèi)部有個(gè)"三審三校"的流程，制作人員自查一遍，技術(shù)專員用驗(yàn)證工具掃一遍，最后項(xiàng)目經(jīng)理整體過一遍信封和元數(shù)據(jù)，雖然費(fèi)時(shí)間，但能攔下九成五的低級(jí)錯(cuò)誤。
還有個(gè)小竅門：定期做"破壞性測(cè)試"。故意用不同的閱讀軟件打開你的eCTD包，在不同操作系統(tǒng)上試試，甚至把文件傳給完全不懂行的同事，讓他試著找到某個(gè)特定章節(jié)。如果他能輕松找到，說明你的書簽結(jié)構(gòu)和超鏈接做得夠直觀。
至于那些驗(yàn)證工具報(bào)出來的警告，建議建立一個(gè)內(nèi)部分級(jí)表，哪些必須立即改，哪些可以備注說明后提交，哪些純屬吹毛求疵可以忽略。這樣不至于每次看到紅色警告就手忙腳亂。
其實(shí)做eCTD這事兒，說到底就是個(gè)精細(xì)活。它不像寫研究方案那樣需要靈光一現(xiàn)，但需要你像拼樂高一樣，每個(gè)卡扣都對(duì)準(zhǔn)了，稍微歪一點(diǎn)就拼不上。當(dāng)你對(duì)著驗(yàn)證報(bào)告里突然冒出來的"XML Schema Validation Failed"抓耳撓腮的時(shí)候，不妨退一步想想，是不是剛才改文件屬性的時(shí)候手滑多敲了個(gè)空格？把這些瑣碎的規(guī)矩變成肌肉記憶，久而久之你會(huì)發(fā)現(xiàn)，那些曾經(jīng)讓人失眠的報(bào)錯(cuò)信息，其實(shí)都在幫你把資料打磨得更專業(yè)。畢竟，在藥品注冊(cè)這條路上，細(xì)節(jié)不是魔鬼，是護(hù)城河。
