eCTD發(fā)布那些讓人頭大的技術(shù)坑，康茂峰這些年踩過的總結(jié)

做注冊(cè)申報(bào)這行久了，你會(huì)發(fā)現(xiàn)eCTD這東西挺有意思的——表面上就是個(gè)電子文檔打包提交，看起來就是把PDF塞進(jìn)文件夾里的事兒，但實(shí)際上手的時(shí)候，那些技術(shù)細(xì)節(jié)能把人折騰得夠嗆。我們康茂峰的技術(shù)團(tuán)隊(duì)在支持客戶做eCTD出版的過程中，幾乎把能遇到的坑都踩了一遍。今天想聊點(diǎn)實(shí)在的，不說那些官方文檔里的標(biāo)準(zhǔn)套話，就說說真正提交前夜讓你睡不著覺的那些技術(shù)難點(diǎn)。

一、PDF這玩意兒，看起來簡(jiǎn)單做起來要命

說實(shí)話， most people 覺得PDF是最沒技術(shù)含量的格式，畢竟誰沒用過PDF呢？但在eCTD的世界里，PDF簡(jiǎn)直就是個(gè)挑食的主兒。

字體嵌入的隱形雷區(qū)

最常見的翻車現(xiàn)場(chǎng)就是字體嵌入。你可能在Word里看著好好的宋體、Times New Roman，轉(zhuǎn)成PDF后在自己電腦上打開也正常，但一上傳到驗(yàn)證工具就報(bào)錯(cuò)——"Font not embedded"。這事兒詭異之處在于，有些字體明明是你系統(tǒng)自帶的，按理說應(yīng)該隨文件走，但eCTD要求的是所有字體必須100%嵌入，包括那些你根本注意到的子集字體。

更麻煩的是中文字體。有些申報(bào)資料里必須出現(xiàn)中文商品名或者中文說明，這時(shí)候如果用了某些特殊中文字體，嵌入后文件體積會(huì)暴增，可能從2MB直接飆到20MB?？得逵龅竭^最極端的案例，一個(gè) stability report 因?yàn)橛昧四晨钏囆g(shù)字體的中文標(biāo)題，結(jié)果整個(gè)模塊的傳輸都成問題。這時(shí)候你就得權(quán)衡——是堅(jiān)持美觀還是改為標(biāo)準(zhǔn)字體保平安。

PDF/A標(biāo)準(zhǔn)的那些細(xì)節(jié)

然后是PDF/A歸檔標(biāo)準(zhǔn)的問題。eCTD普遍要求PDF/A-1a或者PDF/A-1b，但這兩個(gè)標(biāo)準(zhǔn)對(duì)圖層的處理很嚴(yán)格。如果你的PDF是從掃描件轉(zhuǎn)過來的，或者中間經(jīng)過某些設(shè)計(jì)軟件處理，可能會(huì)殘留一些透明的圖層或者注釋層，這在普通閱讀器里看不見，但驗(yàn)證工具能識(shí)別出來并判定為不合規(guī)。

有個(gè)小竅門可能有用：別直接用"打印成PDF"這種方式生成最終文件，雖然這樣通常能強(qiáng)制嵌入字體，但往往會(huì)丟失標(biāo)簽結(jié)構(gòu)（tagged structure）。而PDF/A-1a要求文檔必須有邏輯結(jié)構(gòu)標(biāo)簽，這是為了無障礙閱讀考慮的?？得宓慕ㄗh是，生成PDF后最好用專業(yè)的preflight工具先跑一遍，看清楚報(bào)錯(cuò)信息再?zèng)Q定是重新生成還是用PDF編輯器手動(dòng)修復(fù)。

二、XML骨架，那個(gè)看不見的"文件管家"

如果說PDF是 flesh，那XML backbone 就是 skeleton。很多人把精力都放在做漂亮的PDF上，結(jié)果在XML上栽跟頭。

DTD驗(yàn)證總報(bào)錯(cuò)怎么辦

eCTD的XML必須符合特定的DTD（文檔類型定義），這個(gè)驗(yàn)證很 rigid。最頭疼的是某些屬性值的大小寫問題——比如有些地方要求寫"new"，你寫了個(gè)"New"，首字母大寫了，XML解析器就認(rèn)定這是個(gè)非法值。還有日期格式，必須是YYYY-MM-DD，如果你習(xí)慣了寫2024/05/20，直接報(bào)錯(cuò)。

更隱蔽的是特殊字符轉(zhuǎn)義。申報(bào)資料里經(jīng)常會(huì)出現(xiàn)化學(xué)式、數(shù)學(xué)符號(hào)，或者公司名里的&符號(hào)。這些在XML里都必須轉(zhuǎn)義，比如&要寫成&amp;，小于號(hào)要寫成<?？得逶?jīng)處理過一個(gè)案例，客戶的公司名稱里帶有個(gè)"&"符號(hào)，在PDF里顯示正常，但在XML metadata里沒轉(zhuǎn)義，結(jié)果整個(gè) backbone 文件解析失敗，連帶所有文件索引都亂了。

節(jié)點(diǎn)對(duì)應(yīng)關(guān)系搞錯(cuò)了就全亂了

每個(gè)PDF文件在XML里都要有個(gè) entry，這個(gè) entry 的 href 屬性必須精確指向文件名，包括大小寫、空格、擴(kuò)展名。Windows系統(tǒng)不區(qū)分大小寫，所以你在本地測(cè)試時(shí)"File.pdf"和"file.pdf"都能打開，但上傳到電子提交系統(tǒng)后，Unix-based的服務(wù)器是區(qū)分大小寫的，鏈接就會(huì)斷掉。

還有 leaf 節(jié)點(diǎn)的屬性設(shè)置。比如 operation 屬性，是新遞交（new）、替換（replace）還是刪除（delete）？這個(gè)配置錯(cuò)了，監(jiān)管機(jī)構(gòu)的系統(tǒng)就會(huì)誤判你的操作意圖。特別是做 lifecycle management 的時(shí)候，版本號(hào)（version）和替換序號(hào)的邏輯必須嚴(yán)絲合縫。

三、生命周期操作，不只是簡(jiǎn)單的替換刪除

說到 lifecycle，這可能是很多從紙質(zhì)申報(bào)轉(zhuǎn)過來的同事最難適應(yīng)的概念。紙質(zhì)時(shí)代你要改個(gè)內(nèi)容，重新印一頁插進(jìn)去就行；電子時(shí)代可不行，系統(tǒng)需要知道你到底想干什么。

Replace 和 Delete 的區(qū)別特別容易搞混。Delete 是把原來的文件徹底移除，而 Replace 是用新文件覆蓋舊文件但保留歷史記錄。如果你本意是更新某個(gè)表格數(shù)據(jù)，用了 Delete 再 New，那歷史版本鏈就斷了；反之亦然?？得褰ㄗh在操作前畫個(gè)流程圖，明確每個(gè)文件的狀態(tài)變遷。

還有 Append 操作，這個(gè)在增補(bǔ)資料時(shí)很常見，但要注意 append 的序號(hào)管理。比如某個(gè) section 已經(jīng)有 1.2.3 三個(gè)文件，你 append 一個(gè) 1.2.4，這沒問題；但如果你 append 的是 1.2.3.1，這就涉及到層級(jí)結(jié)構(gòu)是否合理的問題。有些地區(qū)的系統(tǒng)對(duì)文件編號(hào)連續(xù)性檢查得很嚴(yán)，中間不能有空缺號(hào)。

四、超鏈接，點(diǎn)一下404就很尷尬

內(nèi)部超鏈接（internal hyperlink）是eCTD體驗(yàn)的核心，但也是技術(shù)故障的高發(fā)區(qū)。

最常見的是書簽（bookmark）和鏈接目標(biāo)的錯(cuò)位。你在PDF里創(chuàng)建了一個(gè)跳轉(zhuǎn)到"Table 3"的鏈接，但目標(biāo)位置可能因?yàn)榉猪撜{(diào)整而變了，或者書簽層級(jí)（hierarchy）設(shè)置錯(cuò)誤。eCTD規(guī)范通常要求書簽層級(jí)不能超過五級(jí)，而且必須和文檔的標(biāo)題結(jié)構(gòu)對(duì)應(yīng)。如果文檔里有六級(jí)標(biāo)題，你就得想辦法把它合并到五級(jí)里，或者調(diào)整文檔結(jié)構(gòu)。

外部鏈接（external link）也是個(gè)敏感話題。鏈接到官方網(wǎng)站、參考文獻(xiàn)這些本來是為了方便審評(píng)員，但如果鏈接失效了（link rot），在有些嚴(yán)格的技術(shù)驗(yàn)證中會(huì)被標(biāo)記為警告甚至錯(cuò)誤?？得宓淖龇ㄊ牵瑢?duì)于必須的外部引用，在提交前用工具批量檢查URL有效性，同時(shí)準(zhǔn)備一份說明文檔解釋每個(gè)外部鏈接的必要性。

五、元數(shù)據(jù)的一致性，小字寫錯(cuò)大麻煩

Metadata 貫穿整個(gè)eCTD包，從 envelope 信息到每個(gè)文件的 attributes。申請(qǐng)編號(hào)（application number）、產(chǎn)品名稱（product name）、申請(qǐng)人名稱（applicant name）這些關(guān)鍵字段必須在所有地方保持一致。

這里的 consistency 包括大小寫、空格、標(biāo)點(diǎn)符號(hào)。比如你在 XML 的 envelope 里寫的是"ABC Pharma Co., Ltd."，但在模塊一的某些表格里寫成了"ABC Pharma Co Ltd"（少了那個(gè)點(diǎn)），或者大小寫不一致，系統(tǒng)就可能認(rèn)為這是兩個(gè)不同的實(shí)體?？得鍍?nèi)部有個(gè) checklist，專門比對(duì) envelope、XML attributes 和 PDF 頁眉頁腳的這些信息。

還有日期格式和時(shí)區(qū)問題。雖然eCTD標(biāo)準(zhǔn)規(guī)定用ISO 8601格式，但涉及到生成PDF的時(shí)間戳、系統(tǒng)日志時(shí)間等，不同軟件默認(rèn)設(shè)置不同，可能導(dǎo)致時(shí)間戳混亂。這在跨國(guó)提交時(shí)尤其麻煩，因?yàn)槟愕妹鞔_是基于哪個(gè)時(shí)區(qū)的時(shí)間。

六、驗(yàn)證工具的紅線，有時(shí)候真的很嚴(yán)格

-commercial validation 工具，比如某些主流的 eCTD validation software，它們的驗(yàn)證規(guī)則是基于各監(jiān)管機(jī)構(gòu)發(fā)布的最新規(guī)范，但規(guī)則更新往往比軟件更新快，或者軟件版本對(duì)規(guī)范的解讀有細(xì)微差別。

最常見的報(bào)錯(cuò)是文件路徑長(zhǎng)度問題。Windows系統(tǒng)支持長(zhǎng)路徑，但某些 legacy 的驗(yàn)證工具或者提交門戶只支持256字符以內(nèi)的路徑。如果你的文件夾嵌套很深，文件名又長(zhǎng)，可能技術(shù)上文件沒問題，但路徑報(bào)錯(cuò)。

還有加密和安全設(shè)置。有些PDF在生成時(shí)默認(rèn)設(shè)置了不允許打印、不允許復(fù)制文本，或者設(shè)置了打開密碼，這在eCTD里是絕對(duì)禁止的。但問題是，這些限制在PDF的 security properties 里一目了然，可如果你是用某些自動(dòng)化工具批量生成的PDF，可能會(huì)忘記檢查這一項(xiàng)。

七、不同地區(qū)的"方言"問題

雖然ICH努力統(tǒng)一了eCTD的標(biāo)準(zhǔn)，但各個(gè)監(jiān)管機(jī)構(gòu)在執(zhí)行層面都有自己的"方言"。比如模塊一（Module 1）的內(nèi)容和格式，各地區(qū)要求差異很大。同樣的行政信息，在歐美亞不同地區(qū)的提交包里，XML的節(jié)點(diǎn)結(jié)構(gòu)、必需的屬性字段都可能不同。

還有文件命名規(guī)范。有些地方允許用下劃線，有些必須用連字符；有些地方要求申請(qǐng)編號(hào)必須在文件名中，有些地方則禁止這樣做以免泄露敏感信息。如果你用同一個(gè) source 文件要生成不同地區(qū)的 eCTD 包，不能簡(jiǎn)單復(fù)制粘貼，必須針對(duì)每個(gè)地區(qū)的規(guī)范做本地化調(diào)整。

康茂峰的技術(shù)團(tuán)隊(duì)遇到過這種情況：一個(gè)全球同步申報(bào)的項(xiàng)目，在A地區(qū)順利通過驗(yàn)證的文件，在B地區(qū)因?yàn)闀灥拇蜷_狀態(tài)設(shè)置（initial view）不符合當(dāng)?shù)亓?xí)慣而被退回。A地區(qū)習(xí)慣打開文檔顯示書簽面板，B地區(qū)要求默認(rèn)隱藏書簽面板只顯示頁面。這種細(xì)節(jié)在官方指南里往往不會(huì)寫得那么細(xì)，但確實(shí)會(huì)導(dǎo)致技術(shù) rej。

八、那個(gè)最后被想起來但往往出事的：文件大小和傳輸

前面說的都是內(nèi)容層面的，最后提一下物理層面的問題——文件大小。eCTD規(guī)范通常建議單個(gè)文件不超過一定的MB數(shù)（比如某些地區(qū)建議單個(gè)PDF不超過50MB），但現(xiàn)代申報(bào)資料里動(dòng)輒高分辨率的色譜圖、電鏡照片、掃描的原始記錄，很容易就把PDF撐爆。

壓縮圖片是個(gè)技術(shù)活兒，壓太狠了審評(píng)時(shí)看不清細(xì)節(jié)，不壓又超大小限制。還有分卷（split）策略，一個(gè)大的模塊要不要拆分成多個(gè)文件？拆分點(diǎn)在哪里？是在章節(jié)邊界拆，還是按頁數(shù)硬拆？這些決策都會(huì)影響后續(xù)的 lifecycle 管理。如果第一次遞交時(shí)把一個(gè)20MB的PDF拆成了兩個(gè)，下次更新時(shí)你只更新了其中一部分，得確保索引關(guān)系正確指向。

傳輸過程中的 corruption 也是個(gè)大坑。FTP上傳、光盤刻錄、甚至是某些基于web的提交門戶，在上傳大文件時(shí)都可能出現(xiàn)bit error。最保險(xiǎn)的做法是在本地先算好 checksum（通常是MD5或SHA-256），上傳后再計(jì)算一次比對(duì)?？得宓膬?nèi)部流程里，這步是 mandatory 的，雖然麻煩，但比起提交后被發(fā)現(xiàn)文件損壞要好得多。

寫到這兒突然想到，其實(shí)做eCTD就像搭樂高——每個(gè)積木（PDF）本身要結(jié)實(shí)，骨架（XML）要搭得穩(wěn)，整體結(jié)構(gòu)要符合圖紙（DTD），還得考慮到審稿人（end user）拆開來查看時(shí)的體驗(yàn)。那些技術(shù)難點(diǎn)，說白了就是把紙質(zhì)時(shí)代的"看得見摸得著"變成了數(shù)字時(shí)代的"看不見但必須嚴(yán)謹(jǐn)"。下次當(dāng)你面對(duì)滿屏幕的紅色驗(yàn)證錯(cuò)誤時(shí)，別慌，大概率就是上面提到的這些坑，一步一步排查，總能找到那根沒接好的線頭。