查看“︁国家药监局关于实施药品电子通用技术文档申报的公告（2021年第119号）”︁的源代码

{{法规标题
| 标题 = 国家药监局关于实施药品电子通用技术文档申报的公告
| 年份 = 
| 发布标题 = 
| 发文字号 = （2021年第119号）
| 起草说明 = 
}}

<div style="text-indent:20px;">
为落实中共中央办公厅、国务院办公厅《关于深化审评审批制度改革鼓励药品医疗器械创新的意见》（厅字〔2017〕42号）和《国务院办公厅关于全面加强药品监管能力建设的实施意见》（国办发〔2021〕16号）文件精神，实现药品注册申请的电子申报，提升“互联网+药品监管”应用服务水平，国家药品监督管理局全面开展和推进了药品电子通用技术文档（eCTD）申报相关工作。现将实施eCTD申报有关事项公告如下：

一、 实施时间和实施范围

自2021年12月29日起，化学药品注册分类1类、5.1类，以及治疗用生物制品1类和预防用生物制品1类的上市许可申请，可按照eCTD进行申报。

二、 eCTD申报资料格式和实施要求

申请人应按照eCTD技术文件（附件1—4）要求准备和提交eCTD申报资料光盘，并在eCTD注册申请新报资料受理后5个工作日内，提交纸质资料。申请人如未按照规定时间提交纸质资料，按终止药品注册程序处理。同时，申请人应承诺所提交的电子资料与纸质资料内容完全一致，如因资料一致性产生的任何问题由申请人自行承担。

三、 其他事项和要求

为确保eCTD稳步推进，减少对申报工作的影响，对于上述注册申请，申请人仍可选择现有注册方式进行注册申报。

采用eCTD申报的注册申请，申请人无需再单独提交核查检验用申报资料光盘和临床试验数据库光盘。

相关技术指导原则可在国家局药品监督管理局药品审评中心网站查询。国家药品监督管理局药品审评中心做好本公告实施过程中的相关技术指导工作。

特此公告。

附件：

1.eCTD技术规范V1.0

2.eCTD验证标准V1.0

3.eCTD实施指南V1.0

4.eCTD技术规范V1.0附件包

</div>
<div style="text-align: right;">
国家药监局

2021年9月29日

</div>



{{CNinfobox
| 简称 = 
| 发文机关 =  国家药品监督管理局
| 发文字号 = 2021年第119号
| 发布日期 = 2021年9月29日
| 生效日期 = 
| 施行日期 = 2021年12月29日
| 征求意见日期 = 
| 意见征求结束 =
| 最新征求意见 = 
| 最新修订 = 
| 最新修改 =
| 废止日期 = 
| 现行法规 = 
| 现行法规施行 = 
| 法律效力位阶 = 规范性文件
| 原文链接 = https://www.nmpa.gov.cn/yaopin/ypggtg/20210930111641179.html
| 发布公告 = 
| 历史法规1 = 
| 历史法规2 = 
| 相关中国法规1 = 
| 相关欧美法规1 = 
| 现状 = 生效
}}
<div style="text-indent:20px;">
==附件1：eCTD技术规范==

===引言 ===

电子通用技术文档（eCTD）模型结构 

下图是针对一个 eCTD 新药申请首次申请首次提交的全套申报资料输出文件夹的结构示例，包括模块一至模块五的内容文件，2 个骨架文件（XML 文件），1 个存放 DTD 相关文件的 util 文件夹及 1 个存放 MD5 值的文本文件。 

[[文件:ECTD技术规范图0.png|thumb|left|none]]<br clear="all">

本文档结构说明 

本文档主要包含以下内容： 

第一章，介绍本文档的目的、范围和应用以及相关配套文件。 

第二章，介绍一套 eCTD 申报资料所需要包含的信息及其层级结构。 

第三章，对在《ICH eCTD 技术规范 V3.2.2》等相关规范中未作要求，或明确指出由实施地区监管机构自行决定的区域性管理信息进行说明。 

第四章，针对区域性管理信息中的模块一部分，对其总体架构进行具体说明。 

第五章，介绍本文档的参考文件。 

第六章，介绍本文档相关术语。 

===1. 介绍 ===

1.1  目的 

eCTD 是用于药品注册申报和审评的电子注册文件。通过可扩展标记语言（Extensible Markup Language，XML）将符合通用技术文档（CTD）规范的药品申报资料以电子化形式进行组织、传输和呈现。 

本文档为 eCTD 技术规范，用以指导 eCTD 软件公司开发符合要求的 eCTD 出版软件，及申请人制作符合要求的 eCTD 申报资料。 

在本文档中将使用 CN 作为中国的区域代码。 

1.2  范围和应用 

本文档对 eCTD 模块一行政文件和药品信息，以及其他区域性信息进行了说明。 

申请人准备eCTD申报资料，除本文档外，还应参考《ICH eCTD 技术规范 V3.2.2》等相关规范。 

1.3  配套文件 

eCTD 技术规范还包括以下配套文件： 

1. ICH 文档类型定义（DTD）文件和区域 Schema 文件
DTD 和 Schema 都是用于对 XML 文档结构进行规范并验证其有效性的定义和描述文件。 

DTD 文件指 ICH 发布的“ich-ectd-3-2.dtd”和“ich-stfv2-2.dtd”文件，用于对 eCTD 骨架文件、研究标签文件（STF）的有效性进行技术验证。模块二至模块五的骨架文件及研究标签文件中将引用上述 DTD 文件，请参考附件 2-1：ICH DTD 文件和附件 2-2：ICH STF DTD 文件。 

区域 Schema 文件指“cn-regional-1-0.xsd”文件，用于定义 eCTD 信封信息和模块一的标题，对区域性信息进行技术验证以确保申报资料相关信息的准确性， “xlink.xsd”和“xml.xsd”文件作为区域 Schema 文件的引用文件，用于定义 XML 文件的基本结构，请参考附件1-1：区域 Schema 文件、附件 3-1：w3c 标准 xlink 结构定义文件、附件 3-2：w3c 标准 xml 命名规范定义文件。 

2.	受控词汇文件 

一套 XML 格式的代码定义文件，用以实现多语言显示/处理。代码定义文件主要包含内容有：eCTD 的有效标题列表、提交的申请中使用的代码类型、代码名称、中英文显示值、以及包括有效日期在内的代码版本控制信息，请参考附件 1-2：受控词汇文件包。 

3.	eCTD 验证标准

验证标准提供了验证项目描述、验证项目详细说明、严重程度（错误、警告、提示信息)，用于对申报资料进行验证，指导申请人如何纠正错误，制作出符合 eCTD 标准的申报资料。 

4.	样式表格文件 

样式表格文件包括 ICH 发布的“ectd-2-0.xsl”文件、“ich-stf-stylesheet-2-2a.xsl” 或 “ich-stf-stylesheet-2-3.xsl”文件，以及模块一的样式表格文件“cn-regional-1-0.xsl”，分别用于规定模块二至模块五的骨架文件、申报资料中的 STF 文件和模块一的骨架文件的展示样式，请参考附件 2-3：ICH 样式文件、附件 2-4：ICH STF 样式文件 2-2a、附件 2-5：ICH STF 样式文件 2-3、附件 1-3：区域样式文件。 

5.	STF 相关属性和标签有效值定义文件 

ICH 发布的“valid-values.xml（version 5）”文件，用于定义 STF 文件中使用到的属性值和标签值，请参考附件 2-6：STF 标签值文件。 

6.	CTD 模块一文件组织结构 

用于定义模块一文件夹和文件的编号、标题名称、元素名称、相对路径等信息，请参考附件 1-4：CTD 模块一文件组织结构。 

===2. eCTD 申报资料结构 ===

eCTD 申报资料由申请、注册行为和序列三个层级来定义。每个层级都包含一系列相关信息，即申请信息、注册行为信息和序列信息。 

关于申请、注册行为、序列输出文件夹的层级示例如下图 1 所示。 

[[文件:ECTD技术规范图1.png|thumb|left|图1：申请、注册行为、序列输出文件夹的层级示例 ]]<br clear="all">

2.1  申请信息 

申请是指为了一个特殊的监管目的（如临床试验申请）来整理和提交的申报资料的集合。一个药品在临床试验和新药申请，或临床试验和仿制药申请两个阶段，对应两套独立的申报资料集合，即两个申请。 

每个申请信息包含申请编号、申请类型、产品类型、原始编号信息。 

2.1.1   申请编号 

申请编号是一个申请在其全生命周期内的唯一识别编号，由监管机构分配给申请人。 

在首次提交临床试验申请、新药申请或仿制药申请的 eCTD 序列时，申请人应从监管机构获取相应的申请编号。 

申请编号编码规则如下所示： 

字母（x=新药申请；y=仿制药申请；l=临床试验申请）+年份（4 位数字）+5 位流水号。 

例如：x202112345。 

2.1.2   申请类型 

申请类型是一组定义的类型，用以描述申请的目的。有关申请类型的详细信息请参考附件 1-2 受控词汇文件中 cvapplication-type.xml 文件的最新版本。 

2.1.3   产品类型 

产品类型是一组定义的类型，用以描述产品分类信息。有关产品类型的详细信息请参考附件 1-2 受控词汇文件中 cv-product-type.xml 文件的最新版本。 

2.1.4   原始编号 

原始编号是对一个进入注册审批程序的药品所给予的基本的和永久的资料代号，是用于标识申请人、活性成分和剂型的唯一识别码，由监管机构分配。 

原始编号编码规则为年份（4 位数字）+6 位流水号，例如：2021123456。 

2.2  注册行为信息 

注册行为是指针对某一特定注册目的从首次提交到获得批准的所有序列的申报资料集合，可以包含一个序列或多个序列。同一个注册行为中的多个序列可以是连续的序列，也可以是不连续的序列。 

每个注册行为信息包括注册行为类型信息和相关序列信息。 

2.2.1   注册行为类型 

注册行为类型是一组定义的类型，用于描述注册行为的目的。有关注册行为类型的详细信息请参考附件 1-2 受控词汇文件中 cv-regulatory-activity-type.xml 文件的最新版本。 

2.2.2   相关序列 

相关序列用于将一个申请中的序列按照注册行为进行分组。一个注册行为中首次提交的序列被称为该注册行为中提交的所有序列的相关序列。 

相关序列应用的具体示例如下表1和下表2所示：

表1：临床试验申请的相关序列示例
{| class="wikitable"
|序列 
|相关序列  
|注册行为类型  
|序列类型  
|序列描述 
|-
|0000 
|0000 
|首次申请  
|首次提交 
|适应症为 xx  的临床试验申请  
|-
|0001 
|0000 
|首次申请  
|回复  
|对序列0000  的发补回复  
|-
|0002 
|0002 
|补充申请  
|首次提交 
|生产工艺变更  
|-
|0003 
|0002 
|补充申请  
|回复  
|对序列0002  的发补回复  
|-
|0004 
|0004 
|新适应症和联合用药  
|首次提交 
|新增适应症为xx  的临床试验申请  
|-
|0005 
|0005 
|补充申请  
|首次提交 
|分析方法变更  
|-
|0006 
|0005 
|补充申请  
|回复  
|对序列0005  的发补回复  
|-
|0007 
|0004 
|新适应症和联合用药  
|回复  
|对序列0004  的发补回复  
|-
|0008 
|0008 
|研发期间安全性报告  
|首次提交 
|研发期间安全性更新报告提交  
|-
|0009 
|0009 
|研发期间安全性报告  
|首次提交 
|其他潜在的严重安全性风险信息  
|}
表2：新药申请的相关序列示例 
{| class="wikitable"
|序列 
|相关序列  
|注册行为类型  
|序列类型  
|序列描述 
|-
|0000 
|0000 
|首次申请  
|首次提交 
|适应症为 xx  的新药上市申请  
|-
|0001 
|0000 
|首次申请  
|回复  
|对序列0000  的发补回复  
|-
|0002 
|0000 
|首次申请  
|回复  
|对序列0000  的发补回复  
|-
|0003 
|0003 
|补充申请  
|首次提交 
|生产工艺变更  
|-
|0004 
|0004 
|补充申请  
|首次提交 
|分析方法变更  
|-
|0005 
|0003 
|补充申请  
|回复  
|对序列 0003  的发补回复  
|-
|0006 
|0006 
|新适应症  
|首次提交 
|增加新适应症 xx  
|-
|0007 
|0004 
|补充申请  
|回复  
|对序列0004  的发补回复  
|-
|0008 
|0008 
|再注册  
|首次提交 
|xx 产品再注册  
|}
2.3  序列信息 

序列是指在某一注册行为中单次提交的申报资料的集合。 

每个序列信息包括序列号、序列类型、序列描述和序列联系人信息。 

2.3.1   序列号 

序列号是申请中唯一的 4 位数字的字符串，是用于区分同一申请中不同提交序列的唯一标识。 

申请人应从 0000 开始提交，每次提交时须将序列号加1，并按先后次序提交，不得跳号提交。 

2.3.2   序列类型 

序列类型是一组定义的类型，用于描述序列的目的。有关序列类型的详细信息请参考附件 1-2 受控词汇文件中 cvsequence-type.xml 文件的最新版本。 

2.3.3   序列描述 

序列描述是对序列提交目的的简要描述，用于区分相似类型的序列。序列描述长度应在 120 个中文字符以内。 

以下列出了一些序列描述的示例： 

1.	适应症为 xx 的新药上市申请 

2.	对序列 xx 的发补回复 

3.	药品生产商的变更，从 xx 改为 yy 

4.	增加新的原料药生产商，xx 

5.	增加新适应症 xx 

6.	xx（方案编号）方案修正 

申请人填写的序列描述不得替代对监管机构问题的回复、说明函，或用于向监管机构提问等。  

2.3.4   序列联系人信息 

序列联系人信息是对该序列的申报资料负责的联系人信息。申请人需要提供的信息包括联系人姓名、电话及邮箱地址。 

2.4  申请、注册行为和序列的关系 

申请人应按照现行注册程序，并根据申报资料的实际情况选择对应的申请类型、注册行为类型和序列类型。有关申请类型、注册行为类型、序列类型对应关系的详细信息请参考附件 1-2 受控词汇文件中 depend-apt-rat-sqt.xml 文件的最新版本。下表 3 举例说明了申请类型、注册行为类型、序列类型的一些实际应用： 

表3：申请、注册行为和序列的关系
{| class="wikitable"
|申请类型 
|注册行为类型 
|序列类型   
|-
| rowspan="4" |临床试验申请  
|首次申请 
|首次提交

回复

撤回 
|-
|补充申请  
|首次提交

回复

撤回 
|-
|新适应症和联合用药  
|首次提交

回复

撤回 
|-
|研发期间安全性报告  
|首次提交

回复

撤回 
|-
| rowspan="7" |新药申请 
|首次申请  
|首次提交

回复

撤回 
|-
|补充申请  
|首次提交

回复

撤回 
|-
|备案  
|首次提交

回复

撤回 
|-
|报告  
|首次提交

回复

撤回 
|-
|新适应症 
|首次提交

回复

撤回 
|-
|再注册 
|首次提交

回复

撤回 
|-
|基线 
|首次提交

回复

撤回 
|-
| rowspan="7" |仿制药申请 
|首次申请 
|首次提交

回复

撤回 
|-
|补充申请 
|首次提交

回复

撤回 
|-
|备案 
|首次提交

回复

撤回 
|-
|报告 
|首次提交

回复

撤回 
|-
|新适应症 
|首次提交

回复

撤回 
|-
|再注册 
|首次提交

回复

撤回 
|-
|基线 
|首次提交

回复

撤回 
|}

===3. 区域性管理信息 ===

本章节规定了 eCTD 的区域性管理信息。 

3.1  模块一的行政文件和药品信息 

模块一的总体构架请参见本文档第四章节。 

3.2  3.2.R 章节的使用 

区域性药学信息应位于 3.2.R 章节。 

对于生物制品，3.2.R 章节需进行粒度细分以符合注册申报资料提交要求。该细分的粒度应使用扩展节点和子文件夹来构建。 

扩展节点的标题命名规则如下表 4 所示：

表4：3.2.R 章节扩展节点标题命名规则
{| class="wikitable"
|扩展节点标题  
|-
|3.2.R.1  工艺验证  
|-
|3.2.R.2  批记录  
|-
|3.2.R.3  分析方法验证报告  
|-
|3.2.R.4  稳定性图谱  
|-
|3.2.R.5  可比性方案  
|-
|3.2.R.6  其他 
|}
扩展节点在骨架文件中的内容如下图 2 所示：

[[文件:ECTD技术规范图2.png|thumb|left|图2：扩展节点骨架文件示例]]<br clear="all">

其他 3.2.R 章节的技术规范参照《ICH eCTD 技术规范V3.2.2》执行。 

3.3  文件和文件夹 

3.3.1   内容文件的格式 

对于 eCTD 申报资料，适用的文件格式有以下五种： 

1.	便携文件格式（PDF）- .pdf 文件扩展名

例如：审评内容文件 

2.	可扩展标记语言 （XML）- .xml 文件扩展名

例如：eCTD 骨架文件 

3.	SAS XPORT 传输文件 - .xpt 文件扩展名

例如：临床试验数据文件 

4.	文本文件（TXT）- .txt 文件扩展名

例如：程序代码文件 

5.	可扩展样式表语言文件（XSL）- .xsl 文件扩展名

例如：XML 文档的可视化格式文件 

3.3.2   文件和文件夹命名规则 

eCTD 申报资料文件及文件夹命名仅允许使用下列字符：小写字母“a”至“z”、数字“0”至“9”、中划线“-”和下划线1 “_”。 对于申报资料中的任一文件，由序列文件夹开始的所有文件夹和文件名（含扩展名）路径长度不应超过 180 个字符，单一文件夹或文件名称（含扩展名）长度不应超过 64 个字符。 

1《ICH eCTD技术规范V3.2.2》中规定的文件命名要求不允许使用下划线，但在临床数据集提交时，SAS XPORT文件的命名可能会使用下划线。考虑到在其他国家监管机构按照eCTD格式递交的临床数据集文件命名也允许使用下划线，并且在《ICH eCTD技术规范V4.0》中也将允许文件命名使用下划线，因此本技术规范允许在对文件和文件夹的命名中使用下划线。

其他命名规则参见下表 5。 

所有目录结构都必须在 XML 骨架文件中被引用，以有效地导航到指定位置。 

表5：文件与文件夹命名规则示例
{| class="wikitable"
| colspan="4" |文件夹 
|文件 
|命名规则 
|-
| colspan="5" |''x202112345''         
|由申请编号命名的申请文件夹  
|-
| rowspan="35" |  

  

  

  

  

  
| colspan="4" |''0000''               
|4 位数字组成的序列文件夹  
|-
| colspan="3" rowspan="2" |                 

                 
|index.xml 
|符合 ICH  要求的骨架文件  
|-
|index-md5.txt 
|符合 ICH  要求的 MD5  校验和文件  
|-
| rowspan="32" |  

  

  
| colspan="3" |m1               
|符合 ICH  要求的模块一内容文件夹  
|-
| rowspan="14" |  

  
| colspan="2" |cn           
|模块一区域文件夹  
|-
| rowspan="13" |      
|cn-regional.xml 
|模块一的骨架文件  
|-
|00  
|模块一 1.0  章节内容文件夹  
|-
|02  
|模块一 1.2  章节内容文件夹  
|-
|03  
|模块一 1.3  章节内容文件夹  
|-
|04  
|模块一 1.4  章节内容文件夹  
|-
|05  
|模块一 1.5  章节内容文件夹  
|-
|06  
|模块一 1.6  章节内容文件夹  
|-
|07  
|模块一 1.7  章节内容文件夹  
|-
|08  
|模块一 1.8  章节内容文件夹  
|-
|09  
|模块一 1.9  章节内容文件夹  
|-
|10  
|模块一 1.10  章节内容文件夹  
|-
|11  
|模块一 1.11  章节内容文件夹  
|-
|12  
|模块一 1.12  章节内容文件夹  
|-
| colspan="3" |m2               
|符合 ICH  要求的模块二内容文件夹  
|-
| colspan="3" |m3               
|符合 ICH  要求的模块三内容文件夹  
|-
| colspan="3" |m4               
|符合 ICH  要求的模块四内容文件夹  
|-
| colspan="3" |m5               
|符合 ICH  要求的模块五内容文件夹  
|-
| colspan="3" |util               
|符合 ICH  要求的工具文件夹  
|-
| rowspan="12" |  

  

  

  


  

  

  
| colspan="2" |dtd          
|符合 ICH  要求的 DTD  和 Schema  文件夹  
|-
| rowspan="5" |      

      

      

     

      
|cn-regional-1-0.xsd  
|模块一的 Schema  文件 
|-
|ich-ectd-3-2.dtd 
|ICH 标准的模块二至模块五 DTD  文件 
|-
|ich-stf-v2-2.dtd 
|ICH 标准的 STF  DTD 文件（如适用）  
|-
|xlink.xsd 
|W3C 标准 xlink  结构定义文件  
|-
|xml.xsd 
|W3C 标准 XML  命名规范定义文件  
|-
| colspan="2" |style       
|符合 ICH  要求的样式表格文件夹  
|-
| rowspan="5" |      
|cn-regional-1-0.xsl 
|模块一的样式表格文件  
|-
|ectd-2-0.xsl 
|ICH 标准的模块二至模块五样式表格文件  
|-
|ich-stf-stylesheet-2-3.xsl 
|ICH 标准的STF  样式表格文件（如适用）  
|-
|ich-stf-stylesheet-22a.xsl 
|ICH 标准的STF  样式表格文件（如适用）  
|-
|valid-values.xml 
|ICH 标准的 STF  标签值文件（如适用）  
|}
3.3.3   关于空缺章节的处理 

申请人提交的序列文件夹中不允许存在空文件夹，即没有文件或子文件夹的文件夹。 

申请人提交的序列中不允许存在占位文档，即不允许存在没有任何实际内容的文档。对于申请中不适用的章节，申请人应在模块一的说明函中进行说明，而无需在 eCTD 编制过程中单独递交“不适用”文档作为占位文档。 

3.3.4   文件的重复使用 

文件复用包括两种情况，即引用同一序列中的文件和引用同一申请中前序序列中的文件。申请人如需要在同一个申请中提交相同的文件，无需重复提交实体文件，只需在骨架文件中对应章节生成叶元素并引用相应实体文件的位置。 

不支持跨申请引用，即不允许引用另一个申请中提交的文件。 

更多关于文件复用的说明请参考《ICH eCTD 技术规范 V3.2.2》附录 6 中的文件重复使用章节。 

3.4  PDF 电子提交标准 

PDF 是 eCTD 申报资料的主要文件格式。《ICH eCTD 文件格式规范 V1.2》（参见本文档第五章节）为创建用于 eCTD 提交的 PDF 文件提出了建议，主要包括以下方面：限制、版本、文件大小、字体、字体大小、字体颜色、页面方向、页面大小和页边距、页眉和页脚、电子文件来源、创建 PDF 文档和图像的建议、压缩图像减少文件大小、图像颜色匹配、ICC 配置文件、文档导航（超文本链接、书签和目录）、页码、初始视图设置、优化、安全、使用 Acrobat 插件。 

除参考上述规范外，申请人还应遵循以下要求： 

1.	如果提交的单个申报资料文件（除外文参考资料、参考文献和申请表之外）内容超过五页，需要提供对应的目录（正文目录、表格目录、图表目录）和书签来辅助导航。 

2.	在不能使用目录和书签进行文档导航的情况下可使用超文本链接来帮助定位。例如，位于不同页的相关章节、文献、附件、表格及图表可以创建超文本链接进行导航。申请人创建的跨文档超文本链接至少应包括：由模块一的上市后变更/研究等项目到模块二至模块五中的具体内容之间的超文本链接、由模块二的概述和总结文件到模块三至模块五的详细信息之间的超文本链接、由临床研究报告到对应附件（如图表）之间的超文本链接、PDF 格式的临床数据集数据说明文件至相应 xpt 文件的超文本链接等。为避免超文本链接失效或定位错误，申请人不应在申报资料中创建跨申请超文本链接。 

3.	针对中文申报资料的要求： 

（1）	字体：宋体 

（2）	字号 

1）	正文：不小于小四号字 

2）	表格：不小于五号字 

3）	目录：小四号字 

4）	脚注：五号字 

（3）	字体颜色 

1）	叙述性文字：黑色 

2）	超文本链接：建议使用蓝色文字或黑色文字带蓝色框表示 

3.5  外文参考资料的要求 

申请人提交的全部申报资料应当使用中文并附原文，其他文种的资料可附后作为参考。中文译文应当与原文内容一致。 

在eCTD 骨架文件中，外文参考资料应放置在对应的中文申报资料同级目录结构中，即同一目录元素下的不同叶元素中。中文申报资料在前并使用中文叶标题进行标识，外文参考资料在后并使用外文叶标题进行标识，申请人可使用“xml:lang”属性对中文申报资料及其外文参考资料进行区分。

中外文申报资料在骨架文件中的内容示例如下图3所示：

[[文件:ECTD技术规范图3.png|thumb|left|图3：中外文申报资料骨架文件示例]]<br clear="all">

3.5.1   语言属性的设置 

在 eCTD 骨架文件中，每个叶元素都代表一个对应的文件。叶元素中包含了一个可选属性“xml:lang”，该属性标识了当前叶元素对应的文件将被视为中文申报资料或外文参考资料。设置该属性值时应遵循 ISO639-1 标准。在以下情况时，叶元素对应文件将被识别为中文申报资料： 

1.	语言属性设置为中文（zh），如下图 4 所示：

[[文件:ECTD技术规范图4.png|thumb|left|图4：语言属性设置为中文示例]]<br clear="all">

2.	语言属性设置为空，如下图 5 所示：

[[文件:ECTD技术规范图5.png|thumb|left|图5：语言属性设置为空示例]]<br clear="all">

3.	未设置语言属性，如下图 6 所示：

[[文件:ECTD技术规范图6.png|thumb|left|图6：未设置语言属性示例]]<br clear="all">

在以下情况时，叶元素对应文件将被识别为外文参考资料： 

1.	语言属性设置为外文，如下图 7 所示：

[[文件:ECTD技术规范图7.png|thumb|left|图7：语言属性设置为英文示例]]<br clear="all">

2.	语言属性设置为无效的值，如下图 8 所示：

[[文件:ECTD技术规范图8.png|thumb|left|图8：语言属性设置为无效的值示例]]<br clear="all">

3.5.2   语言属性的生命周期管理 

使用 eCTD 生命周期操作“替换”，将前序序列中提交的文件替换为新文件时，被替换的文件和新文件应具有相同的语言属性。即中文申报资料只能被另一份中文申报资料所替换，而外文参考资料只能被另一份外文参考资料所替换。 

3.6  eCTD 骨架属性和元数据 

eCTD 骨架属性指申报资料模块一至模块五章节的相关属性的集合，包括了本文档 4.3 章节中定义的信封元素属性以及《ICH eCTD 技术规范 V3.2.2》中定义的模块二至模块五的属性。

元数据是申请人为模块一至模块五章节相关属性设定的值的集合。 

ICH eCTD DTD 中定义了模块二至模块五部分章节的选填属性和必填属性（例如 2.3.S 及 3.2.S 中的活性成分及生产商为必填属性，2.3.P 及 3.2.P 中的产品名称、剂型、生产商为选填属性）。这些属性是为了对该特定章节的内容进行简单有用的描述，以便于对内容进行区分和分组。 

申请人对 ICH 元数据进行更新时，必须同时提交该属性对应的全部申报资料的内容变更。不允许在没有更新申报资料内容的情况下仅对元数据进行更改，也不允许在更新元数据时，仅对其对应部分申报资料的内容进行变更。例如，申请人更新 2.3.S 和 3.2.S 中的活性成分和生产商元数据时，必须删除已有的 2.3.S 和 3.2.S 章节内容，并在新的 2.3.S 和 3.2.S 章节中添加全部相关资料。 

更多关于如何合理使用 eCTD 模块二至模块五元数据的指导原则，请参考《ICH eCTD IWG 问题解答和规范变更要求文件 V1.31》。  

关于信封元素属性的使用，请参见本文档 4.3 章节。 

3.7  扩展节点 

扩展节点为申请人提供了自定义目录元素的途径，用以扩展技术规范中既定的 eCTD 目录元素结构，实现将多个叶元素在自定义目录元素下组合显示功能。 

扩展节点仅允许在产品类型为生物制品的提交序列的

3.2.R 章节中使用。 

3.8  研究标签文件 

模块四中的 4.2.X 章节和模块五中的 5.3.1.X-5.3.5.X 章节的所有文件应使用 STF。 

非临床试验报告可参考 CTD 模块四相关章节的目录结

构进行组织，并使用“pre-clinical-study-report”标签进行标记。 

临床研究报告可参考《ICH E3 临床研究报告的结构和内容》的要求，并使用适当的 STF 文件标签来展现文档的内容。未按照 ICH E3 相关指南编制的临床研究报告可提交单独的 PDF 文件，并使用“legacy-clinical-study-report”标签进行标记。 

临床研究报告相关的临床试验数据集应在 eCTD 申报资料中一并提交，在骨架文件中应位于相应的临床研究报告之后，并使用适当的 STF 标签进行标识。更多 eCTD 中临床试验数据集及相关资料的申报要求详见《药物临床试验数据递交指导原则（试行）》。 

模块五中的 5.2 所有临床研究列表、5.3.6 上市后报告和5.4 参考文献可以不使用 STF，作为独立的文件提交。更多关于 STF 的信息，请参照《ICH 研究标签文件的 eCTD 骨架文件技术规范 V2.6.1》。 

3.9  生命周期操作 

在 ICH 技术规范中，针对每个文件都赋予了 4 个生命周期的操作类型：新建、替换、删除和增补。 

推荐使用“新建”、“替换”和“删除”操作类型。除对 STF 进行的操作，其他情况下不建议使用“增补”操作类型。 

申请人对 STF 以外的文件进行增补操作，将导致申报资料验证时出现警告信息，对此申请人应在说明函中做出解释。对 STF 进行增补操作，验证时不会出现警告信息。 

3.10  电子签名 

符合《中华人民共和国电子签名法》要求的电子签名与手写签名或者盖章具有同等的法律效力。eCTD 申请中将接受上述电子签名的使用。 

3.11  eCTD 提交方式 

申请人准备的 eCTD 申报资料需通过物理电子媒介提交。目前只接受一次写入型光盘作为存储介质，包括 CD-R、DVD+R、DVD-R 这三类。不得使用双面DVD或对提交的申报资料设置密码保护。

===4. 模块一的总体架构 ===

《ICH eCTD 技术规范 V3.2.2》明确了模块一应包含区域特定的行政文件和药品信息。模块一的内容和编号要求参见《M4：人用药物注册申请通用技术文档》模块一文件。 

申请人需要提交的模块一的内容包含有模块一文件夹和文档以及模块一的骨架文件，其输出文件夹基本结构示例如下图9所示：

[[文件:ECTD技术规范图9.png|thumb|left|图9：模块一输出文件夹基本结构示例]]<br clear="all">

4.1  创建模块一骨架文件 

模块一骨架文件由 XML 根元素、信封元素、目录元素三个部分组成。申请人可按照以下步骤为给定的序列创建模块一的骨架文件： 

1.	创建一个标准的 XML 文件及 XML 根元素。 

2.	创建符合标准的信封信息，用来描述该序列。 

3.	按照《M4：人用药物注册申请通用技术文档》模块一文件的内容，创建该序列所需的目录元素和叶元素。 

（1）	目录元素，参照 CTD 模块一的目录结构。 

（2）	叶元素，包含序列中提交的单个文件的引用地址、校验和及生命周期操作等信息。 

4.	命名模块一的 eCTD 骨架文件为 cn-regional.xml，并将其放置在模块一的cn子文件夹中。 

4.2  XML 根元素 

所有模块一的骨架文件都应包含标准 XML 根元素。其信息包括 XML 声明以及根元素<cn_ectd>，该根元素的属性将这个 XML 文件链接到指定的 XML 定义文件。如下图10 所示：

[[文件:ECTD技术规范图10.png|thumb|left|图10：XML 根元素示例]]<br clear="all">

4.3  信封元素 

信封元素包含的属性信息如下表6所示，各属性详细介绍请参见本文档“申请信息”（2.1 章节）、“注册行为信息”（2.2 章节）、“序列信息”（2.3 章节）。 

表6：信封元素

针对申请人提交的每个序列，所有属性均为必填项，并有且仅有一个值。在同一申请中，申请人不允许更新申请级别的信封元素属性信息，即申请编号、申请类型、产品类型和原始编号。在同一注册行为中，申请人不允许更新注册行为级别的信封元素属性信息，即相关序列、注册行为类型。 

对于有受控词汇的信封元素属性，在骨架文件中记录的属性值必须为受控词汇文件中定义的代码名称，而信封实际显示信息中只展示对应代码的显示值。 

信封元素在骨架文件中的呈现形式如下图 11 所示：

[[文件:ECTD技术规范图11.png|thumb|left|图11：信封骨架文件示例]]<br clear="all">

信封元素的实际显示信息如下图 12 所示：

[[文件:ECTD技术规范图12.png|thumb|left|图12：信封实际显示信息示例]]<br clear="all">

受控词汇文件中的每个代码都有对应的版本号、生效日期、失效日期（可选），用来标识该代码适用的时间范围。申请人在使用代码时应注意其对应版本的开始生效日期和失效日期，并使用有效的代码。 

受控词汇文件的详细信息如下图 13 所示：

[[文件:ECTD技术规范图13.png|thumb|left|图13：受控词汇文件示例]]<br clear="all">

4.4  目录元素 

每个目录元素的内容由一个或多个叶元素组成。 

叶元素包含了《ICH eCTD 技术规范 V3.2.2》中定义的<title>元素及一系列属性，如“operation”、“xlink:href”、“checksum-type”、“checksum”等。其中“checksum-type”属性的值必须设置为“MD5”或“md5”。 

叶元素的叶标题内容应当简短、明确并能提供有用信息。 

目录元素在骨架文件中的内容如下图 14 所示：

[[文件:ECTD技术规范图14.png|thumb|left|图14：元素骨架文件示例]]<br clear="all">

目录元素实际显示信息如下图 15 所示：

[[文件:ECTD技术规范图15.png|thumb|left|图15：目录元素实际显示信息示例]]<br clear="all">

===5. 参考<sup>2</sup>===

<sup>2</sup> <small>相关参考文件可参见 ICH 网站（ https://www.ich.org/ ）、药品审评中心网站（ https://www.cde.org.cn/ ）</small>

以下文档规范应与本文档一起作为参考，以确保申报资料符合 eCTD 整体的要求。通常情况下，除非本文档中另有说明，否则应遵守以下这些文档规范。此外，除非在《eCTD 实施指南 V1.0》中有特别说明，申请人应遵循所有其它区域性的 CTD 指导文件。 

1.	ICH eCTD Specification and Related files 

——ICH eCTD 技术规范和相关文件，包括变更控制过程、变更请求表和问答文档。 

2.	ICH Electronic Common Technical Document Specification V3.2.2 

——《ICH eCTD 技术规范 V3.2.2》 

3.	ICH The eCTD Backbone File Specification for Study Tagging Files V2.6.1 

——《ICH 研究标签文件的 eCTD 骨架文件技术规范V2.6.1》 

4.	ICH Specification for Submission Formats for eCTD V1.2 

——《ICH eCTD 文件格式规范 V1.2》 

5.	ICH eCTD IWG Question and Answer and Specification Change Request Document V1.31 

——《ICH eCTD IWG 问题解答和规范变更要求文件V1.31》 

6.	ICH E3 Structure and Content of Clinical Study Reports 

——《ICH E3 临床研究报告的结构和内容》 

7.《M4 模块一行政文件和药品信息》 

8.《药物临床试验数据递交指导原则（试行）》

===6. 术语表===

{| class="wikitable"
|名词 
|定义 
|-
|电子通用技术文档（eCTD）  
|电子通用技术文档是用于药品注册申报和审评的电子注册文档。通过可扩展标记语言（Extensible  Markup Language，XML）将符合 CTD  规范的药品申报资料以电子化形式进行组织、传输和呈现。  
|-
|申请 
|申请是指为了一个特殊的监管目的（如临床试验申请）来整理和提交的申报资料的集合。  
|-
|注册行为 
|注册行为是针对某一特定注册目的从首次提交到获得批准的所有序列的申报资料集合，可以包含一个序列或多个序列。同一个注册行为中的多个序列可以是连续的序列，也可以是不连续的序列。  
|-
|序列 
|序列是在某一注册行为中单次提交的申报资料的集合。  
|-
|申请编号 
|申请编号是一个申请在其全生命周期内的唯一识别编号，由监管机构分配给申请人。  
|-
|原始编号 
|原始编号是对一个进入注册审批程序的药品所给予的基本的和永久的资料代号，是用于标识申请人、活性成分和剂型的唯一识别码，由监管机构分配。  
|-
|相关序列 
|一个注册行为中首次提交的序列被称为该注册行为中提交的所有序列的相关序列。  
|-
|序列号 
|序列号是申请中唯一的 4  位数字的字符串，是用于区分同一申请中不同提交序列的唯一标识。
|-
|叶元素（leaf element） 
|叶元素是 eCTD 骨架文件的一部分，是在序列中提交的单个文件的引用地址、显示名称、校验和及生命周期操作等信息的集合。  
|-
|信封信息 
|信封信息是 eCTD 区域骨架文件的一部分，给电子资料管理系统提供处理和组织申报资料时使用的元数据。  
|-
|受控词汇 
|受控词汇是对特定概念规定术语的限定列表。 
|-
|基线 
|基线指申请人将已以纸质递交获批上市许可的药品从纸质递交格式转换为 eCTD  提交的注册行为。  
|-
|扩展节点（node extension） 
|扩展节点为申请人提供了自定义目录元素的途径，用以扩展技术规范中既定的 eCTD  目录元素结构，实现将多个叶元素在自定义目录元素下组合显示功能。  
|-
|研究标签文件（ Study Tagging Files,  STF） 
|研究标签文件用以提供在 eCTD  骨架文件中没有包含的关于研究主题和研究报告的信息，例如研究全称，研究  ID，研究使用的种属，给药途径，研究时长，对照类型等。  
|-
|MD5  
|MD5  消息摘要算法（MD5  MessageDigest Algorithm），一种被广泛使用的密码散列函数，用于产生一个文件对应的数字指纹，即校验和。  
|-
|校验和（checksum） 
|使用 MD5 消息摘要算法产生的文件校验和，用以确保信息传输的完整性和一致性。  
|-
|DTD  
|文档类型定义（ Document  Type Definition）是一套为了进行程序间的数据交换而建立的关于标记符的语法规则，用于保证 eCTD 骨架文件的合法性，如元素和属性使用是否正确等。 
|-
|验证 
|指申请人和监管机构根据公开和统一的验证标准，对 eCTD 申报资料进行检查校验的过程。  
|}

==附件2：eCTD验证标准==


{| class="wikitable"
| style="background-color:gray";|'''序号'''
| style="background-color:gray";|'''描述'''
| style="background-color:gray";|'''说明'''
| style="background-color:gray; width: 4em;"|'''严重程度'''
|-
| style="background-color:lightgray"; colspan="4" |'''1 - 基础识别'''
|-
|1.1
|文件数量统计
|显示当前序列中包含的所有文件的数量。
|提示信息
|-
|1.2
|文件大小统计
|显示当前序列所有文件的总容量大小。
|提示信息
|-
|1.3
|空缺的章节统计
|显示当前序列中空缺的目录结构清单。
|提示信息
|-
| style="background-color:lightgray"; colspan="4" |'''2 - 文件/文件夹'''
|-
|2.1
|文件夹不能为空
|序列文件夹目录结构中不允许存在空文件夹（文件夹没有文件或子文件夹）。
|错误
|-
|2.2
|不能超出文件大小限制
|超出允许大小的文件会提示警告信息。

普通单个文件最大允许500MB，单个SAS XPT文件可支持4GB。
|警告
|-
|2.3
|不允许未被引用的文件
|m1至m5文件夹目录下的所有文件必须被骨架文件（index.xml或cn-regional.xml）引用，否则提示错误信息。
|错误
|-
|2.4
|文件类型（文件扩展名检查）
|所有被引用文件必须有且仅有一个文件扩展名，文件扩展名必须在《eCTD技术规范V1.0》规定的可接受的文件类型列表内。
|错误
|-
|2.5
|文件和文件夹命名规范必须正确
|文件和文件夹的命名规则必须符合《eCTD技术规范V1.0》第3.3.2章节的规定。
|错误
|-
|2.6
|m1文件夹存在但是不存放单个文件
|m1文件夹必须存在并且必须仅包含子文件夹而不是单个文件。
|错误
|-
|2.7
|util文件夹必须存在且包含的文件必须正确
|util文件夹必须存在，并检查该文件夹中的下列文件：

-         ich-ectd-3-2.dtd (checksum必须符合ICH发布的值)

-         cn-regional-1-0.xsd (checksum必须符合NMPA发布的值)

-         xml.xsd (checksum必须符合NMPA发布的值)

-         xlink.xsd (checksum必须符合NMPA发布的值)

-         ich-stf-v2-2.dtd (checksum必须符合ICH发布的值)

-         ectd-2-0.xsl (checksum必须符合ICH发布的值)

-         cn-regional-1-0.xsl (checksum必须符合NMPA发布的值)

-         ich-stf-stylesheet-2-3.xsl  (checksum必须符合ICH发布的值)

-         ich-stf-stylesheet-2-2a.xsl  (checksum必须符合ICH发布的值)

-         valid-values.xml (checksum必须符合ICH发布的值) 请注意，只有在当前序列使用到STF时才需要检查ich-stf-v2-2.dtd、stf样式表和valid-values.xml。另外，在STF中，ich-stf-stylesheet-2-3.xsl和ich-stf-stylesheet-2-2a.xsl样式表均可以被引用，此项验证标准仅检查在STF中被引用到的样式表是否在util\style文件夹中存在以及其checksum是否符合规范。
|错误
|-
|2.8
|序列号根文件夹不允许其他文件
|根文件夹（申请序列文件夹）除《eCTD技术规范V1.0》明确允许的文件外，不能有其他文件。
|错误
|-
|2.9
|序列文件夹要求
|序列文件夹名称必须仅包含4个数字。
|错误
|-
|2.10
|序列编号
|在注册文件生命周期内的每次提交都必须有一个序列号，初始序列号必须从0000开始，依次增加1（例如，0000，0001，0002，0003，依次类推）。序列号不允许跳号。如果序列号0003不存在，即便0004中不引用0003的内容，验证序列号为0004的提交时依然会提示错误信息。
|错误
|-
| style="background-color:lightgray"; colspan="4" |'''3 - ICH 骨架文件'''
|-
|3.1
|index.xml文件必须存在
|序列的根文件夹必须包含index.xml文件。
|错误
|-
|3.2
|index.xml中DTD的引用必须指向util文件夹中提供的DTD
|如何创建有效的引用请参考http://www.w3.org/TR/xml/ 和  <nowiki>http://www.ietf.org/rfc/rfc3986.txt（2005版本</nowiki> 第22页，第3.3章节）。
|错误
|-
|3.3
|index.xml文件必须有效。
|index.xml文件必须根据DTD文件ich-ectd-3-2.dtd给定的规则创建并且是有效的。
|错误
|-
|3.4
|文件引用（xlink:href）属性指向的文件必须存在
|XML叶元素中的文件引用链接必须有效，即引用的目标文件必须存在。
|错误
|-
|3.5
|文件在一个序列中不允许对应多个操作
|ICH骨架文件中的叶元素文件在同一个序列中不能作为“被修改文件对象（modified-file）”被多次引用。
|错误
|-
|3.6
|替换或增补的内容不能与之前文件相同
|当执行“替换（replace）”或“增补（append）”操作时，新内容必须与之前的内容不同（即checksum不能相同）。
|错误
|-
|3.7
|叶元素：新建、替换或增补的叶元素，必须有“文件引用（xlink:href）”值
|“操作（operation）”属性值为“新建（new）”、“替换（replace）”或“增补（append）”的所有叶元素，必须有“文件引用（xlink:href）”值。
|错误
|-
|3.8
|叶元素：删除的叶元素不能包含“文件引用（xlink:href）”值
|“操作（operation）”属性值为“删除（delete）”的所有叶元素，不能有“文件引用（xlink:href）”值。
|错误
|-
|3.9
|叶元素：对替换、删除和增补的叶元素，必须有对应的文件
|“操作（operation）”属性值为“替换（replace）”、“删除（delete）”或“增补（append） ”的所有叶元素，对应的“被修改文件对象（modified-file）”必须有值。
|错误
|-
|3.10
|叶元素：初始序列中所有文件必须为新建
|初始序列（即序列号为0000的序列）中所有内容文件的“操作（operation）”属性必须为“新建（new）”。
|错误
|-
|3.11
|被修改文件对象必须存在
|XML叶元素中的被修改文件的引用链接必须是有效的，即“被修改文件对象（modified-file）”对应的文件确实存在。
|错误
|-
|3.12
|只允许使用相对路径引用
|ICH骨架文件中引用文件使用的是相对路径，不允许使用绝对路径。

在“文件引用（ xlink:href ）”和“被修改文件对象（modified-file）”属性中只允许使用相对路径引用，并且路径中只允许使用正斜杠"/"，不允许使用反斜杠"\"。
|错误
|-
|3.13
|“checksum-type”属性
|“checksum-type”属性必须设置为“md5”或“MD5”。
|错误
|-
|3.14
|MD5值校验
|所有文件的MD5 checksum必须和骨架文件中提供的checksum值保持一致。
|错误
|-
|3.15
|骨架文件的MD5值校验
|骨架文件的MD5 checksum必须和MD5文本文件（index-md5.txt）中提供的值保持一致。
|错误
|-
|3.16
|扩展节点的使用要求
|扩展节点仅允许在产品类型为生物制品的序列的3.2.R章节使用。

如产品类型为生物制品的序列存在3.2.R章节，则必须使用扩展节点。
|错误
|-
|3.17
|扩展节点标题的命名规范
|对于生物制品，3.2.R章节扩展节点标题的构建和名称定义必须遵循《eCTD技术规范V1.0》第3.2章节中的规定。
|警告
|-
|3.18
|叶标题不能为空
|所有叶元素必须有子元素<title>，叶标题不能为空。
|错误
|-
|3.19
|删除的叶标题必须和被删除的叶标题保持一致
|“操作（operation）”属性为“删除（delete）”的叶元素，其叶标题必须和被删除的叶标题保持一致。
|错误
|-
|3.20
|叶标题开头和结尾不能为空格
|叶标题开头和结尾不能为空格。
|警告
|-
|3.21
|元素下必须有叶元素
|名称以“m”开始的元素必须有叶元素。
|错误
|-
|3.22
|m1行政文件和药品信息元素必须存在。
|元素“m1-administrative-information-and-prescribing-information”必须存在。
|错误
|-
|3.23
|增补（append）的使用
|不建议在STF定义范围外使用“增补（append）”。在STF定义范围外使用“增补（append）”操作，需要在说明函中进行说明。
|警告
|-
|3.24
|不能重新定位文件位置
|该规则适用于ICH模块二至模块五的叶元素。

当对现有文件进行修订时，新的叶元素应在骨架文件中的相同位置进行提交，并以增补、替换或删除的方式体现。

文件位置指的是文件在目录结构中的位置。该位置由CTD目录结构以及eCTD中的部分属性来定义。例如，申请人不能使用说明函章节修改的内容替换申请表章节中的内容。另外，申请人可使用eCTD属性创建自定义章节。 例如，m3-2-s-drug-substance中的每个“活性成分（substance）”或“生产商（manufacturer）”属性，或m3-2-p-drug-product中的“产品名称（product-name）”属性均可创建一个新的CTD章节，申请人同样不能使用其中一个章节的内容替换其他章节的内容。
|错误
|-
|3.25
|属性-适应症（indication）
|适应症属性在2.7.3和5.3.5章节中使用时为必填项，值不能为空。
|错误
|-
|3.26
|属性-生产商（manufacturer）
|生产商属性在2.3.S和3.2.S章节中使用时为必填项，值不能为空。
|错误
|-
|3.27
|属性-活性成分（substance）
|活性成分属性在2.3.S和3.2.S章节中使用时为必填项，值不能为空。
|错误
|-
|3.28
|属性值开头和结尾不能为空格
|属性值开头和结尾不能为空格。
|警告
|-
|3.29
|内容的引用
|骨架文件（index.xml）中不允许包含跨申请引用。当在骨架文件中引用另一个序列的内容时，只能引用同一申请中早先已提交序列的内容。
|错误
|-
|3.30
|检测无效的生命周期模式：增补操作造成分支
|已经被一个叶元素替换的叶元素不能再进行增补操作。
|错误
|-
|3.31
|检测无效的生命周期模式：删除操作造成分支
|已经被一个叶元素替换的叶元素不能再进行删除操作。
|错误
|-
|3.32
|检测无效的生命周期模式：替换操作造成分支
|已经被一个叶元素替换的叶元素不能再进行第二次替换操作。
|错误
|-
|3.33
|检测无效的生命周期模式：对已删除叶元素的操作
|已经被删除的叶元素不能再做其他任何操作。
|错误
|-
|3.34
|检测无效的生命周期模式：对增补的叶元素进行增补操作
|不允许对一个操作属性为增补的叶元素使用增补操作。该规则不适用于STF的情况。
|错误
|-
|3.35
|检测无效的生命周期模式：对不是最新的STF叶元素进行增补操作
|对于STF叶元素，增补操作必须针对该文件最新版本来进行。
|错误
|-
|3.36
|替换操作时语言属性不得变更
|对ICH骨架文件叶元素进行替换操作时，被替换的文件和替换后的文件应具有相同的语言属性。
|警告
|-
| style="background-color:lightgray"; colspan="4" |'''4 - 区域性管理信息'''
|-
| colspan="4" |'''4.1 - 基础信息'''
|-
|4.1.1
|模块一的区域骨架文件必须存在
|m1\cn文件夹中必须包含cn-regional.xml文件。
|错误
|-
|4.1.2
|cn-regional.xml中对Schema的引用必须指向util文件夹中提供的Schema
|如何创建有效的引用请参考http://www.w3.org/TR/xml/ 和  <nowiki>http://www.ietf.org/rfc/rfc3986.txt（2005版本</nowiki> 第22页，第3.3章节）。
|错误
|-
|4.1.3
|区域骨架文件必须有效
|使用申请文件夹中（util/dtd目录）给定的Schema对区域骨架文件进行验证。
|错误
|-
|4.1.4
|当前序列必须使用一个不低于先前序列所用的schema版本
|当前申请已使用较新版本Schema时，不允许返回早期版本。
|错误
|-
|4.1.5
|文件引用（xlink:href）属性指向的文件必须存在
|XML叶元素中的文件引用链接必须有效，即引用的目标文件必须存在。
|错误
|-
|4.1.6
|文件在一个序列中不允许对应多个操作
|区域骨架文件中的叶元素文件在同一个序列中不能作为“被修改文件对象（modified-file）”被多次引用。
|错误
|-
|4.1.7
|替换或增补的内容不能与之前文件相同
|当执行“替换（replace）”或“增补（append）”操作时，新内容必须与之前的内容不同（即 checksum不能相同）。
|错误
|-
|4.1.8
|叶元素：新建、替换或增补的叶元素，必须有“文件引用（xlink:href）”值
|“操作（operation）”属性值为“新建（new）”、“替换（replace）”或“增补（append）”的所有叶元素，必须有“文件引用（xlink:href）”值。
|错误
|-
|4.1.9
|叶元素：删除的叶元素不能包含“文件引用（xlink:href）”值
|“操作（operation）”属性值为“删除（delete）”的所有叶元素，不能有“文件引用（xlink:href）”值。
|错误
|-
|4.1.10
|叶元素：对替换、删除和增补的叶元素，必须有对应的文件
|“操作（operation）”属性值为“替换（replace）”、“删除（delete）”或“增补（append） ”的所有叶元素，对应的“被修改文件对象（modified-file）”必须有值。
|错误
|-
|4.1.11
|叶元素：初始序列中所有文件必须为新建
|初始序列（即序列号为0000的序列）中所有内容文件的“操作（operation）”属性必须为“新建（new）”。
|错误
|-
|4.1.12
|“checksum-type”属性
|“checksum-type”属性必须设置为“md5”或“MD5”。
|错误
|-
|4.1.13
|MD5值校验
|所有文件的MD5 checksum必须和区域骨架文件中提供的checksum值保持一致。
|错误
|-
|4.1.14
|说明函的“操作（operations）”属性
|所有说明函的“操作（operation）”属性值必须为“新建（new）”。
|错误
|-
|4.1.15
|申请表的“操作（operations）”属性
|序列类型为“首次提交”，且提交序列中包含申请表文件时，其“操作（operation）”属性值必须为“新建（new）”。
|错误
|-
|4.1.16
|不允许使用“扩展节点（Node Extension）”
|不允许在区域骨架文件结构中使用“扩展节点（Node Extension）”。
|错误
|-
|4.1.17
|叶标题不能为空
|所有叶元素必须有子元素<title>，叶标题不能为空。
|错误
|-
|4.1.18
|删除的叶标题必须和被删除的叶标题保持一致
|“操作（operation）”属性为“删除（delete）”的叶元素，其叶标题必须和被删除的叶标题保持一致。
|错误
|-
|4.1.19
|叶标题开头和结尾不能为空格
|叶标题开头和结尾不能为空格。
|警告
|-
|4.1.20
|元素下必须有叶元素
|名称以“cn-”开始的元素必须有叶元素。
|错误
|-
|4.1.21
|申请文件夹名称
|申请文件夹名称必须和信封信息中的申请编号保持一致。
|错误
|-
|4.1.22
|序列文件夹名称
|序列文件夹名称必须和信封信息中的序列号保持一致。
|错误
|-
|4.1.23
|m1文件夹目录结构
|模块一输出文件夹基本结构必须遵循《eCTD技术规范V1.0》第4章节中的规定。
|错误
|-
|4.1.24
|内容的引用
|区域骨架文件（cn-regional.xml）中不允许包含跨申请引用。当在区域骨架文件中引用另一个序列的内容时，只能引用同一申请中早先已提交序列的内容。
|错误
|-
|4.1.25
|检测无效的生命周期模式：增补操作造成分支
|已经被一个叶元素替换的叶元素不能再进行增补操作。
|错误
|-
|4.1.26
|检测无效的生命周期模式：删除操作造成分支
|已经被一个叶元素替换的叶元素不能再进行删除操作。
|错误
|-
|4.1.27
|检测无效的生命周期模式：替换操作造成分支
|已经被一个叶元素替换的叶元素不能再进行第二次替换操作。
|错误
|-
|4.1.28
|检测无效的生命周期模式：对已删除叶元素的操作
|已经被删除的叶元素不能再做其他任何操作。
|错误
|-
|4.1.29
|检测无效的生命周期模式：对增补的叶元素进行增补操作
|不允许对一个操作属性为增补的叶元素使用增补操作。该规则不适用于STF的情况。
|错误
|-
|4.1.30
|增补（append）的使用
|不建议在区域骨架文件中使用“增补（append）”操作属性。在区域骨架文件中使用“增补（append）”操作，需要在说明函中进行说明。
|警告
|-
|4.1.31
|替换操作时语言属性不得变更
|对区域骨架文件叶元素进行替换操作时，被替换的文件和替换后的文件应具有相同的语言属性。
|警告
|-
| colspan="4" |'''4.2 - 信封信息'''
|-
|4.2.1
|信封元素：申请编号
|申请编号必须符合《eCTD技术规范V1.0》中的的编码规则。
|错误
|-
|4.2.2
|信封元素：申请类型
|申请类型必须参考“cv-application-type.xml”中的定义。
|错误
|-
|4.2.3
|信封元素：产品类型
|产品类型必须参考“cv-product-type.xml”中的定义。
|错误
|-
|4.2.4
|信封元素：原始编号
|原始编号不能为空。
|错误
|-
|4.2.5
|信封元素：相关序列
|相关序列必须是4位数字，且小于或等于当前序列的序列号。
|错误
|-
|4.2.6
|信封元素：注册行为类型
|注册行为类型必须参考“cv-regulatory-activity-type.xml”中的定义。
|错误
|-
|4.2.7
|信封元素：序列号
|序列号必须由四位数字组成。
|错误
|-
|4.2.8
|信封元素：序列类型
|序列类型必须参考“cv-sequence-type.xml”中的定义。
|错误
|-
|4.2.9
|信封元素：序列描述
|序列描述不能为空，且总长度不能超过120个中文字符。
|错误
|-
|4.2.10
|信封元素：序列相关信息
|提交序列的申请类型、注册行为类型、序列类型之间的关联关系必须参考“depend-apt-rat-sqt.xml”中的定义。
|错误
|-
|4.2.11
|相关序列的值
|如果序列类型不是首次提交或格式转换，则相关序列不应与当前序列号相同。
|错误
|-
|4.2.12
|相关序列的值
|如果序列类型是首次提交或格式转换，则相关序列应与当前序列号相同。
|错误
|-
|4.2.13
|申请级别的信封元素必须保持不变
|初始序列中使用的申请级别的信封元素，即申请编号、申请类型、产品类型、原始编号的值在整个生命周期中不能更改。
|错误
|-
|4.2.14
|注册行为类型必须保持不变
|对于属于同一个注册行为的所有序列，其注册行为类型的值必须相同。
|错误
|-
| colspan="4" |'''4.3 - 内容完整性'''
|-
|4.3.1
|模块一完整性验证：
申请类型：新药申请
注册行为类型：首次申请或新适应症
序列类型：首次提交
|针对上述类型，提交序列必须包含以下元素

cn-1-0，cn-1-2，cn-1-3，cn-1-3-1，cn-1-3-1-2，cn-1-3-2，cn-1-3-2-2，cn-1-3-3，cn-1-3-8，cn-1-3-8-1，cn-1-3-8-2，cn-1-11
|错误
|-
|4.3.2
|模块一完整性验证：
申请类型：新药申请
注册行为类型：首次申请或新适应症
序列类型：首次提交
|针对上述类型，提交序列不能包含以下元素

cn-1-3-1-1，cn-1-3-2-1，cn-1-3-4，cn-1-3-4-1，cn-1-3-4-2，cn-1-3-4-3
|错误
|-
|4.3.3
|模块一完整性验证：
申请类型：新药申请
注册行为类型：首次申请或新适应症
序列类型：首次提交
|针对上述类型，提交序列必须包含以下元素

cn-1-0，cn-1-2，cn-1-3，cn-1-3-1，cn-1-3-1-2，cn-1-3-2，cn-1-3-2-2，cn-1-3-3，cn-1-3-8，cn-1-3-8-1，cn-1-3-8-2，cn-1-11
|错误
|-
|4.3.4
|模块一完整性验证：
申请类型：新药申请
注册行为类型：首次申请或新适应症
序列类型：首次提交
|针对上述类型，提交序列不能包含以下元素

cn-1-3-1-1，cn-1-3-2-1，cn-1-3-4，cn-1-3-4-1，cn-1-3-4-2，cn-1-3-4-3，cn-1-12
|错误
|-
|4.3.5
|模块一完整性验证：
申请类型：临床试验申请
注册行为类型：首次申请或新适应症和联合用药
序列类型：首次提交
|针对上述类型，提交序列必须包含以下元素

cn-1-0，cn-1-2，cn-1-3，cn-1-3-1，cn-1-3-1-1，cn-1-3-2，cn-1-3-2-1，cn-1-3-3，cn-1-3-4，cn-1-3-4-1，cn-1-3-4-2，cn-1-3-4-3，cn-1-3-8，cn-1-3-8-1，cn-1-3-8-2，cn-1-11
|错误
|-
|4.3.6
|模块一完整性验证：
申请类型：临床试验申请
注册行为类型：首次申请或新适应症和联合用药
序列类型：首次提交
|针对上述类型，提交序列不能包含以下元素

cn-1-3-1-2，cn-1-3-2-2，cn-1-3-5，cn-1-3-6
|错误
|-
|4.3.7
|模块一完整性验证：
申请类型：临床试验申请
注册行为类型：研发期间安全性报告
序列类型：首次提交
|针对上述类型，提交序列必须包含以下两个元素之一  

cn-1-8-1，cn-1-8-2
|错误
|-
|4.3.8
|模块一完整性验证：
申请类型：临床试验申请
注册行为类型：研发期间安全性报告
序列类型：首次提交
|针对上述类型，提交序列不能同时包含以下两个元素  

cn-1-8-1，cn-1-8-2
|错误
|-
|4.3.9
|元素包含的叶元素数量
|针对以下元素，其包含的叶元素数量建议不超过一个，如该元素中包含多个PDF文件，建议合并为一个文件提交

cn-1-1，cn-1-3-2-1，cn-1-3-2-2，cn-1-3-8-8，cn-1-4-1，cn-1-4-2，cn-1-4-3，cn-1-4-4， cn-1-4-5，cn-1-4-6，cn-1-4-7，cn-1-6-1，cn-1-6-3，cn-1-10-1，cn-1-10-2，cn-1-10-3，cn1-12
|提示信息
|-
| style="background-color:lightgray"; colspan="4" |'''5 - 研究标签文件（STF）'''
|-
|5.1
|STF文件必须有效
|STF文件必须根据ich-stf-v2-2.dtd创建并保证有效性。
|错误
|-
|5.2
|检查索引引用
|“文件引用（xlink:href）”对应的被引用文件必须存在。
|错误
|-
|5.3
|不建议使用“content-block”元素
|不建议使用“content-block”元素。
|警告
|-
|5.4
|文件引用值不能使用反斜杠
|文件引用（xlink:href）的值不能包含反斜杠（"\"）。
|错误
|-
|5.5
|研究标识的类别不能空
|研究标识/类别（study-identifier>>category）值不能是空的。
|警告
|-
|5.6
|研究标识的研究ID不能为空
|研究标识/研究ID（study-identifier>>study-id）值不能是空的。
|警告
|-
|5.7
|研究标识的标题必须与叶元素的叶标题匹配
|研究标识/标题（study-identifier>>title）的值必须与骨架文件（index.xml）中相应STF叶标题保持一致。
|警告
|-
|5.8
|标签属性和类别元素的值
|根据“valid-values.xml”文件（版本5）定义的内容检查STF文件的标签属性（tag）值和类别属性（category）值是否有效。
|警告
|-
|5.9
|STF的增补操作
|对STF叶元素进行增补操作时，其“被修改文件对象（modified-file）”必须是另一个STF叶元素。
|警告
|-
|5.10
|STF必须提供类别元素（category）信息
|见《ICH eCTD STF标准文件 V2.6.1》

类别（category）为研究组织提供了一个额外的级别，该级别是eCTD DTD目前不能提供的。该元素仅与下列CTD章节的研究有关：4.2.3.1，4.2.3.2，4.2.3.4.1，5.3.5.1。在上述章节，需提供类别（category）信息。
|警告
|-
|5.11
|STF不能引用另一个STF
|STF中的引用对象必须是有目标内容的文件，而不是另一个STF。
|警告
|-
|5.12
|STF文件必须至少引用一个叶元素
|不关联任何叶元素的STF会提示警告信息。
|警告
|-
|5.13
|STF的“study-id”值必须保持一致
|在申请的全生命周期内，同一个STF的“ study-id”值必须保持不变。
|警告
|-
|5.14
|无效的STF目录位置
|STF只存在于模块四（4.2.x章节）和模块五（5.3.1.x-5.3.5.x章节）中。
|警告
|-
|5.15
|STF“doc-content”的标签（file-tag）数量
|每个“doc-content”元素有且仅有1个“文件标签（file-tag）”。
|警告
|-
|5.16
|5.3.7章节病例报告表结构
|如果当前序列使用了STF，5.3.7章节将禁止被使用。病例报告表必须在STF中被引用和展现。
|错误
|-
|5.17
|使用STF
|第4.2章节中的叶元素必须使用STF引用。

第5.3.1至5.3.5章节中的叶元素必须使用STF引用。
|错误
|-
|5.18
|临床试验数据集相关文件必须使用正确的STF文件标签
|模块五（5.3章节）中xpt格式的临床数据集文件的有效文件标签有：data-tabulation-dataset-legacy；data-tabulation-dataset-sdtm；analysis-dataset-adam；analysis-dataset-legacy  XML格式的数据说明文件（define.xml）的有效文件标签有：data-tabulation-data-definition；  analysis-data-definition
|警告
|-
|5.19
|申请人递交的药物临床试验数据必须有正确的数据集文件和数据说明文件
|申请人提交的原始数据库中都应包含dm数据集和对应的数据说明文件，分析数据库中都应包含adsl数据集和对应的数据说明文件。
|警告
|-
|5.20
|同一个研究下提交的数据集不能重名
|对于模块五（5.3章节）中的同一研究，不应存在相同名称的数据集。
|警告
|-
| style="background-color:lightgray"; colspan="4" |'''6 - PDF分析'''
|-
|6.1
|PDF文件必须可读。
|针对被破坏或不可读的PDF文件（因内容无效，或页码数为0）进行检查，并提示错误信息。
|错误
|-
|6.2
|书签必须指向相对路径
|PDF文件中必须使用指向相对路径的书签，不允许使用指向绝对路径的书签。参考文献（2.7.5章节、3.3章节、4.3章节、5.4章节）和外文参考资料不做此要求。
|警告
|-
|6.3
|有网页、邮箱地址或其他外部链接的书签
|PDF文件中不允许使用包含网页链接、电子邮箱地址或其他外部链接的书签。参考文献（2.7.5章节、3.3章节、4.3章节、5.4章节）和外文参考资料不做此要求。
|错误
|-
|6.4
|不允许有未知动作的书签
|不允许使用GoTo，GoToR和Launch以外的操作类型的书签。参考文献（2.7.5章节、3.3章节、4.3章节、5.4章节）和外文参考资料不做此要求。
|错误
|-
|6.5
|书签不能失效
|不允许在PDF文件中使用失效的书签（例如：未分配任何操作的书签）。参考文献（2.7.5章节、3.3章节、4.3章节、5.4章节）和外文参考资料不做此要求。
|警告
|-
|6.6
|书签不能被损坏
|PDF文件中包含损坏的书签（例如：书签指向地址不存在）时将提示警告信息。参考文献（2.7.5章节、3.3章节、4.3章节、5.4章节）和外文参考资料不做此要求。
|警告
|-
|6.7
|书签不能有多个动作
|不允许有指定多个动作的书签（例如，打开两个不同的页面）。参考文献（2.7.5章节、3.3章节、4.3 章节、5.4章节）和外文参考资料不做此要求。
|警告
|-
|6.8
|书签必须承前缩放（Inherit Zoom）
|所有的书签的放大率设置应为承前缩放（Inherit Zoom）。参考文献（2.7.5章节、3.3章节、4.3章节、5.4章节）和外文参考资料不做此要求。
|警告
|-
|6.9
|超文本链接必须使用相对路径
|PDF文件中的超文本链接必须使用相对路径，不允许使用绝对路径。参考文献（2.7.5章节、3.3章节、4.3章节、5.4章节）和外文参考资料不做此要求。
|警告
|-
|6.10
|有网页、邮箱地址或其他外部链接的超文本链接
|PDF文件中不允许使用包含网页链接、电子邮箱地址或其他外部链接的超文本链接。参考文献（2.7.5 章节、3.3章节、4.3章节、5.4章节）和外文参考资料不做此要求。
|错误
|-
|6.11
|不允许有未知动作的超文本链接
|不允许在PDF文件使用除GoTo, GoToR和Launch以外动作类型的超文本链接。参考文献（2.7.5章节

、3.3章节、4.3章节、5.4章节）和外文参考资料不做此要求。
|错误
|-
|6.12
|超文本链接不能处于失效状态
|不允许在PDF文件中使用失效的超文本链接（例如：未指定任何操作的超文本链接）。参考文献（2.7.5章节、3.3章节、4.3章节、5.4章节）和外文参考资料不做此要求。
|警告
|-
|6.13
|超文本链接不能被损坏
|PDF文件中包含损坏的超文本链接（例如：超文本链接指向地址不存在）时将提示警告信息。参考文献（2.7.5章节、3.3章节、4.3章节、5.4章节）和外文参考资料不做此要求。
|警告
|-
|6.14
|超文本链接不能有多个动作
|不允许设置有多个指定动作(例如，打开两个不同的页面)的超文本链接。参考文献（2.7.5章节、3.3章节、4.3章节、5.4章节）和外文参考资料不做此要求。
|错误
|-
|6.15
|超文本链接必须承前缩放（Inherit Zoom）
|所有超文本链接的放大率设置应为承前缩放（Inherit Zoom）。参考文献（2.7.5章节、3.3章节、4.3 章节、5.4章节）和外文参考资料不做此要求。
|警告
|-
|6.16
|PDF版本必须正确
|允许的PDF文件版本为1.4，1.5，1.6，1.7，PDF/A-1，PDF/A-2。参考文献（2.7.5章节、3.3章节、4.3章节、5.4章节）和外文参考资料不做此要求。
|警告
|-
|6.17
|不允许带附件的PDF文件
|PDF文件中不能嵌入任何附件。参考文献（2.7.5章节、3.3章节、4.3章节、5.4章节）和外文参考资料不做此要求。
|错误
|-
|6.18
|有注释的PDF文件
|除了超文本链接以外，PDF文件中不能包含其他注释。参考文献（2.7.5章节、3.3章节、4.3章节、5.4 章节）和外文参考资料不做此要求。
|提示信息
|-
|6.19
|PDF文件不能有任何安全设置
|不能提交有安全设置的PDF文件，例如限制选择文本或图形等。参考文献（2.7.5章节、3.3章节、4.3 章节、5.4章节）和外文参考资料不做此要求。
|错误
|-
|6.20
|PDF初始视图正确
|根据《ICH eCTD技术规范V3.2.2》：有书签的文件在初始视图中应显示书签。放大率和页面布局应设置为默认。参考文献（2.7.5章节、3.3章节、4.3章节、5.4章节）和外文参考资料不做此要求。
|警告
|-
|6.21
|PDF文件不能有密码保护
|不能提交使用密码保护且无法打开的文件。
|错误
|-
|6.22
|PDF应该设置启用“快速Web访问（Fast Web Access）”
|不能提交未启用“快速Web访问（Fast Web  Access）”情况下创建的PDF文件。参考文献（2.7.5章节、3.3章节、4.3章节、5.4章节）和外文参考资料不做此要求。
|提示信息
|-
|6.23
|大于5页的文件必须有书签
|除外文参考资料、参考文献（2.7.5章节、3.3章节、4.3章节、5.4章节）和申请表之外，大于5页的文件必须有书签。
|警告
|-
|6.24
|PDF内容限制
|PDF文件不能包含JavaScript，3D内容或动态内容（音频/视频）。参考文献（2.7.5章节、3.3章节、4.3章节、5.4章节）和外文参考资料不做此要求。
|警告
|-
|6.25
|PDF内容可搜索
|PDF文件中的文本必须可搜索。 如果是扫描页面，则应使用OCR提供可搜索的文本。参考文献（2.7.5 章节、3.3章节、4.3章节、5.4章节）和外文参考资料不做此要求。
|警告
|-
|6.26
|如使用非标准字体，需嵌入在PDF文件中
|PDF文件应尽量使用标准字体。如果包含非标准字体，则需在文件中嵌入该非标准字体。标准字体列表如下：宋体

Times  New Roman

Times  New Roman Italic

Times  New Roman Bold

Times  New Roman Bold Italic

Arial

Arial  Italic

Arial  Bold

Arial  Bold Italic

Courier  New

Courier  New Italic

Courier  New Bold

Courier  New Bold Italic

Symbol

Zapf  Dingbats

参考文献（2.7.5章节、3.3章节、4.3章节、5.4章节）和外文参考资料不做此要求。
|警告
|-
|
|
|
|
|-
| style="background-color:gray"; colspan="4" |'''说明:'''
|-
|'''错误'''
| style="background-color:lightgray";|必须遵守的关键验证标准
| style="background-color:lightgray"; colspan="2" |任何错误信息均会导致申报资料被拒收；未来验证过程中会自动拒绝有错误的申报资料。
|-
|'''警告'''
| style="background-color:lightgray";|建议遵守的验证标准
| style="background-color:lightgray"; colspan="2" |警告信息可以在说明函中进行解释，但建议申请人在将eCTD申报资料递交给CDE前解决这些问题。
|-
|'''提示信息'''
| style="background-color:lightgray";|用于收集信息的验证标准
| style="background-color:lightgray"; colspan="2" |收集相关信息并在验证报告中体现，对申报资料的接收没有影响。
|}

==附件3：eCTD实施指南==

===1. 概述 ===

1.1  目的 

本文档为 eCTD 实施指南，用以指导申请人准备符合要求的 eCTD 申报资料并将其按要求提交至国家药品监督管理局。 

本指南规定了申请人制作和提交 eCTD 申报资料的一般性要求，请申请人务必仔细阅读，认真研究。未按照本指南要求制作和提交的 eCTD 申报资料将会导致申报资料的拒收或对后续的审评审批工作造成影响。 

随着相关法律法规调整、业务流程变化以及信息化系统的不断升级完善，本指南相关内容也将适时进行更新。 

1.2  适用范围 

本指南适用于化学药品、生物制品（按生物制品管理的体外诊断试剂除外）按照 eCTD 格式进行提交的药物临床试验、药品上市许可、再注册等申请以及补充申请。 

1.3  相关指导原则 

申请人应按照本指南，以及《eCTD 技术规范 V1.0》、《eCTD 验证标准 V1.0》、《ICH M8：电子通用技术文档（eCTD）》相关文件，准备和提交 eCTD 申报资料。 

===2. 基本要求 ===

2.1  申请人及监管机构的责任 

申请人应保证提交的 eCTD 申报资料的真实性。 

监管机构有责任保证所接收的 eCTD 申报资料的安全性和保密性，建立相应的保密机制。 

2.2  从纸质递交向 eCTD 电子提交过渡的考虑 

在 eCTD 实施初期，原纸质递交和电子提交将并行，申请人根据实际情况选择合适的方式，后续将全面实施 eCTD。 

对于从未提交过申报资料的药品，申请人可从临床试验申请、新药申请或仿制药申请的首次申请开始提交 eCTD 申报资料。 

对于已以纸质递交获批上市许可的药品，首次使用 eCTD 提交补充申请、再注册等注册行为之前，建议首先提交一个基线，从而使监管机构可以在 eCTD 生命周期内参阅所有以前递交的文档或至少部分以前递交的文档。已经提交了全套 eCTD 资料的申请，无需再进行基线提交。 

申请人使用 eCTD 提交申报资料后，针对此药品的所有后续提交，包括补正回复、发补回复、补充申请等，都应使用 eCTD 进行提交，不得再使用原纸质方式进行递交。 

2.3  存储介质的选择及刻录光盘的要求 

申请人应根据《eCTD 技术规范 V1.0》第 3.11 章节中的要求选择 eCTD 申报资料的存储介质。 

为降低存储介质在交付运输过程中带来的安全性风险，提交至监管机构的存储介质将不会归还给申请人。无法读取、验证不通过等情况下，对应的存储介质将由监管机构执行销毁操作。 

申报资料内容较多，容量需求较大时，申请人应使用一张 DVD 光盘而不是多张 CD 光盘进行提交。如果无法只提供一张光盘，或者大型提交不得不使用多张光盘，可按照模块进行拆分，除非单个模块大小超过光盘容量限制，否则不建议将单个模块的提交文档拆分到多张光盘上。在使用多张光盘提交申报资料时，为便于识别光盘内容，申请人须将模块一文件夹与 index.xml、index-md5.txt 文件放置于第一张光盘中提交。 

申请人提交的存储介质中的内容应以申请编号命名的申请文件夹作为根目录，并仅包含当前需要提交的一个序列，不应包含已经提交至监管机构的前序序列。 

建议申请人使用读写速度较快的存储介质，以提升申报

资料的读取速度，例如 16x 的 DVD 光盘等。申请人应对提交的存储介质承担全部责任，直至该存储介质交付至监管机构。在运输过程中，承载申报资料的存储介质的安全性和完整性由申请人负责。申报资料存储介质交付至监管机构之后，其安全性和完整性由监管机构负责。 

后续随 eCTD 全面实施，将加快推进电子提交网关建设，实现申报资料的网上提交。 

2.4  光盘封面信息 

申请人应从国家药品监督管理局网上办事大厅药品业务应用系统（以下简称药品业务应用系统）填写和打印光盘封面信息，并粘贴于光盘盒表面，随申报资料光盘一起提交。 

2.5  病毒检查 

申请人需对提交的 eCTD 申报资料提前进行病毒检查，并在说明函中提供病毒检查声明。监管机构接收到申报资料后将进行病毒检查，如发现病毒将导致申报资料的拒收。 

2.6  技术验证 

在 eCTD 申报资料制作完成后，应采用专业的验证软件（申请人可在药审中心网站下载免费版本的验证软件）对该申报资料进行验证。验证软件验证完成后将生成对应的验证报告，验证报告中会指出当前申报资料是否存在错误和警告。如果验证报告中对应的验证标准条目显示“错误”，说明此标准为必须遵守的关键验证标准。任何“错误”均会导致申报资料的拒收。 

如果验证报告中对应的验证标准条目显示“警告”，说明此标准为建议遵守的验证标准。建议申请人在将 eCTD 申报资料提交给监管机构前解决这些问题，并重新验证生成新的验证报告。针对未解决的“警告”，申请人应在说明函中进行解释。 

2.7  提交要求 

申请人需要提交一套 eCTD 申报资料光盘至监管机构。 

申请人提交 eCTD 申报资料时，应按要求将申报资料光盘封装在档案袋内，并在药品业务应用系统填写和打印档案袋封面信息，粘贴于档案袋表面。 

2.8  纸质资料的递交及要求 

申请人应在 eCTD 注册申请新报资料受理后 5 个工作日内，提交一套对应的纸质资料至国家药品监督管理局药品审评中心，如发生书面发补，还应在补充资料正式接收后 5 个工作日内，提交纸质资料，其他审评过程中提交的 eCTD 申报资料，申请人可将对应的纸质资料随电子资料一起提交。纸质资料应参照现有《药品注册申报资料格式体例与整理规范》进行整理。 

申请人需提交一套纸质资料，并保证所提交的纸质资料与 eCTD 申报资料内容完全一致，如因资料一致性产生的任何问题由申请人自行承担。申请人如未按照规定时间提交纸质资料，按终止药品注册程序处理。 

===3. eCTD 申报资料中的编号管理 ===

根据《eCTD 技术规范 V1.0》的规定，eCTD 申报资料中的编号包括原始编号、申请编号和序列号。申请人应注意正确使用相关编号。 

3.1  原始编号的应用 

原始编号是对一个进入注册审批程序的药品所给予的基本的和永久的资料代号，是用于标识申请人、活性成分和剂型的唯一识别码，由监管机构分配。 

申请人应从药品业务应用系统获取原始编号，并在 eCTD 信封信息中填写正确的原始编号。 

对于已以纸质递交获批上市许可的药品，如需转换为 eCTD 提交，则在首次提交 eCTD 申报资料时获取新的原始编号，后续提交补充申请、再注册等注册行为时均使用首次提交时得到的原始编号。 

如因品种转让、通用名核定等原因，导致原始编号中对应的申请人、药品名称等信息变更时，申请人应在药品业务应用系统进行原始编号对应信息的变更操作。 

3.2  申请编号的应用 

申请编号是一个申请在其全生命周期内的唯一识别编号，由监管机构分配给申请人。

申请人应从药品业务应用系统获取申请编号，并在 eCTD 信封信息中填写正确的申请编号。 

申请人应注意，一般情况下，只有临床试验申请、新药申请或仿制药申请的首次申请时需要获得新的申请编号，在同一申请类型内提交补充申请、新适应症、再注册等注册行为时均使用首次申请时得到的申请编号，以保证药品的全生命周期管理。 

对于已以纸质递交获批上市许可的药品，如需转换为 eCTD 提交，则在首次提交 eCTD 申报资料时获取新的申请编号，后续提交补充申请、再注册等注册行为时均使用首次提交时得到的申请编号。 

3.3  序列号的应用 

申请人每次提交的有效的 eCTD 申报资料都会产生一个新的序列号，用于区分同一个申请编号下提交的不同的 eCTD 序列。 

申请人应在 eCTD 信封信息中填写正确的序列号，序列号的使用要求请参考《eCTD 技术规范 V1.0》第 2.3.1 章节。 

3.4  各编号之间的关联性 

通常在一个新药的原始编号下会存在两个申请编号，分别对应该药品的临床试验申请和新药申请。在每个申请编号下包含多个序列号，分别对应单独提交的每份申报资料。 

一个典型的新药的编号管理示例如下表 1 所示：表1.新药的编号管理示例

3.5  其他编号 

药品研发和注册过程中产生的临床试验登记号、药品注册受理号等其他编号的要求按现行管理规定执行。 

===4. 模块信息的特殊说明 ===

eCTD 文件组织结构需符合《eCTD 技术规范 V1.0》的要求。 

模块一文件组织结构请参考《eCTD 技术规范 V1.0》附件 1-4：CTD 模块一文件组织结构。模块二到五的文件组织结构请参考《ICH eCTD 技术规范 V3.2.2》附录 4：eCTD 文件组织结构。 

4.1  模块一：行政文件和药品信息 

4.1.1   申请表的准备 

申请表的填报在药品业务应用系统在线完成，并导出成PDF 文件放置于 eCTD 申报资料对应的目录结构中。 

4.1.2   说明函的准备 

申请人提交的每个序列都应包含说明函，即 CTD 模块一 1.0 章节。 

eCTD 申报资料说明函包括以下内容： 

1.	CTD 模块一说明函所要求的内容 

2.	负责本次提交序列注册事务的联络人信息 

3.	本次提交序列不适用的文档清单或说明<sup>1 </sup>（如适用） 

<sup>1</sup><small>不适用的文档指本次提交序列中缺失的章节内容（参考CTD模块一至模块五目录结构）。</small >  

4.	本次提交序列验证的相关信息 

5.	关于纸质资料与 eCTD 申报资料内容一致的承诺 

6.	关于按规定时限一次性提交全部纸质申报资料的承诺 

7.	病毒检查声明 

4.1.3   信封信息的准备 

申请人提交的每个序列都应包含信封信息，对于信封信息管理的要求请参考《eCTD 技术规范 V1.0》第 4.3 章节。 

4.2  模块二：通用技术文档总结 

对于复方制剂中的多个原料药，申请人应在模块二中针对每种原料药提供独立的 2.3.S 章节，并提供对应的申报资料文件。 

4.3  模块三：质量 

按现行申报资料要求，需要单独提交 3.2.S 章节的情形，申请人应在模块三中提供独立的 3.2.S 章节，并提供对应的申报资料文件。 

当 3.2.R 章节使用扩展节点时，在 3.2.R.2 章节中，除文件大小超出限制，必须进行拆分的情况以外，每一批的批记录应以单个文件的方式提交。 

4.4  模块四：非临床试验报告 

对于模块四中的 4.2.X 章节，申请人应使用研究标签文件（STF）的方式进行组织和呈现。 

4.5  模块五：临床研究报告 

对于模块五中的 5.3.1.X 至 5.3.5.X 章节，申请人应使用 STF 的方式进行组织和呈现，对于 STF 的要求请参考《eCTD 技术规范 V1.0》第 3.8 章节。 

如果申报资料涵盖多个适应症，应针对每个适应症提供独立的 5.3.5 章节并提供对应的申报资料文件。 

在此情况下，如果有效性研究仅针对其中某个适应症，那么相关文件应被置于模块五的对应位置（例如：m5/53-clin-stud-rep/535-rep-effic-safety-stud/anxiety/5351-stud-rep-contr）。如果有效性研究针对多个适应症，此研究报告应被放置于 5.3.5 中最合适的章节，并在其他适应症下相应的章节进行复用。有关文件复用的要求请参考《eCTD 技术规范 V1.0》第3.3.4 章节。 

===5. 特定类型提交的建议<sup>2</sup>===

<sup>2</sup> <small>本章所提供示例仅为举例，不包含所有情况。 </small> 

制作 eCTD 申报资料时，申请人应明确该申报资料在申请、注册行为、序列各层级的类型，并参考《eCTD 技术规范V1.0》第 2.4 章节在信封信息中填写正确的类型。 

“临床试验申请”适用于药物临床试验申请及药物临床试验期间所提出的申请事项。制作上述类型申报资料时，应选择申请类型“临床试验申请”，并根据申请事项选择相应注册行为类型（首次申请、补充申请、新适应症和联合用药、研发期间安全性报告）。根据提交资料对某一注册行为的提交目的，序列类型可以选择为该注册行为的首次提交，或对补正、发补的回复，或对某一注册行为提交资料的撤回。 

“新药申请”适用于化学药品 1 类、2 类、5.1 类以及预防用生物制品、治疗用生物制品的上市许可申请及上市后变更、再注册等申请事项。制作上述类型申报资料时，应选择申请类型“新药申请”。并根据申请事项选择相应注册行为类型（首次申请、补充申请、备案、报告、新适应症、再注册、基线）。根据提交资料对某一注册行为的提交目的，序列类型可以选择为该注册行为的首次提交，或格式转换，或对补正、发补的回复，或对某一注册行为提交资料的撤回。 

“仿制药申请”适用于化学药品 3 类、4 类、5.2 类的上市许可申请及上市后变更、再注册等申请事项。制作上述类型申报资料时，应选择申请类型“仿制药申请”，并根据申请事项选择相应注册行为类型（首次申请、补充申请、备案、报告、新适应症、再注册、基线）。根据提交资料对某一注册行为的提交目的，序列类型选择为该注册行为的首次提交，或格式转换，或对补正、发补的回复，或对某一注册行为提交资料的撤回。 

5.1  临床试验申请的新适应症和联合用药 

获准开展药物临床试验的药物拟增加适应症以及增加与其他药物联合用药的，根据现行法规提交药物临床试验申请时，使用临床试验申请首次申请的申请编号，申请类型选择“临床试验申请”，注册行为类型选择“新适应症和联合用药”，与已获准的临床试验申请中重复的 eCTD 申报资料无需再次提交。具体示例如下表 2 所示： 

表2. 新适应症和联合用药示例

5.2  新药申请和仿制药申请的新适应症 

对于已上市药品增加境内未批准的新适应症、改变给药途径等，使用首次申请的申请编号和申请类型，注册行为类型选择“新适应症”，与已获准的新药申请中重复的 eCTD 申报资料无需再次提交。具体示例如下表 3 所示： 

表3. 新适应症示例一

对于已以纸质递交获批上市许可的药品，首次使用 eCTD 提交增加境内未批准的新适应症、改变给药途径等，从申请人之窗获取新的申请编号，申请类型选择“新药申请”，注册行为类型选择“新适应症”，并提交全套资料。具体示例如下表 4 所示： 

表4. 新适应症示例二

增加境内同品种已批准适应症，使用首次申请的申请编号和申请类型，注册行为类型选择“补充申请”。具体示例如下表 5 所示： 

表5. 增加适应症示例

5.3  基线 

基线指申请人将已以纸质递交获批上市许可的药品从纸质递交格式转换为 eCTD 提交的注册行为。基线提交的目的仅为格式转换，不应涉及任何已批准内容的变更。 

申请人提交的基线应至少包括模块一、模块二和模块三的全部最新已被批准的、合法有效的资料，并在说明函中承诺本次提交的申报资料与已批准并正在生效的申报资料没有任何内容上的改变，只有格式转化。 

提交基线时，从申请人之窗获取新的原始编号和申请编号，并选择与原纸质方式递交申报资料时对应的申请类型，注册行为类型选择“基线”。具体示例如下表 6 所示： 

表6. 基线示例

5.4  再注册 

药品再注册时，使用首次申请的申请编号和申请类型，注册行为类型选择“再注册”，并提交相关资料。具体示例如下表 7 所示： 

表7. 再注册示例

5.5  研发期间安全性报告 

开展临床试验期间，申请人应按照相关规定提交研发期间安全性更新报告及附件，或其他潜在的严重安全性风险信息。

提交此类申报资料时，使用首次申请的申请编号和申请类型，注册行为类型选择 “研发期间安全性报告”。具体示例如下表 8 所示： 

表8. 研发期间安全性报告示例

5.6  审评期间提交的申报资料 

按 eCTD 提交的申请，在其审评过程中，申请人需要提交的申报资料均应按 eCTD 提交，例如补充资料等允许审评期间提交的其他资料。 

提交此类文件时，其申请编号、申请类型、注册行为类型应与当前正在审评的注册行为保持一致，序列类型选择“回复”。 

5.7  首次申请的撤回 

对于临床试验申请、新药申请、仿制药申请的首次申请：

申请人如需撤回该注册行为，应提交一个新的序列用于关闭当前注册行为及申请编号。 

针对该注册行为不予受理、不予批准或终止药品注册审评审批的情况，申请人如对结果无异议，也需提交一个新的序列，用于关闭当前注册行为及申请编号。 

提交此类序列时，其申请编号、申请类型、注册行为类型应与当前注册行为保持一致，序列类型选择“回复”。序列内容包括说明函以及相关证明性文件。 

关闭的申请编号将不能继续使用，申请人如需再次提交上述申请，应从监管机构获取新的申请编号。 

5.8  首次申请后其他注册行为的撤回 

对于首次申请后进行的补充申请、再注册等其他后续注册行为： 

申请人如需撤回某个正在受理或审评过程中的注册行为，应提交一个新的序列用于撤回该注册行为中提交的所有申报资料，使有效的 eCTD 申报资料与该注册行为提交前保持一致。 

针对某个注册行为不予受理、不予批准或终止药品注册审评审批的情况，申请人如对结果无异议，也需提交一个新的序列，用于撤回该注册行为中提交的所有申报资料。

如申请人未提交撤回序列，会影响整套申报资料的生命周期管理，从而导致后续提交申报资料的拒收。 

提交此类序列时，其申请编号、申请类型、注册行为类型应与当前注册行为保持一致，序列类型选择“撤回”。有关撤回序列的生命周期操作要求请参见本文第 6.3 章节。

===6. 文件生命周期的管理 ===

申报资料中每个文件都有新建、替换、删除和增补四种生命周期的操作类型，详情请参考《ICH eCTD 技术规范V3.2.2》附录6中的操作属性章节。 

6.1  生命周期操作的基本要求 

执行“新建”操作时，其对应的文件必须包含在当前申请中。 

执行“替换”操作时，被替换文件必须在当前申请前序序列中存在，替换后的文件必须在当前申请中存在。 

执行“删除”操作时，被删除的文件必须在当前申请前序序列中存在。 

“增补”操作通常仅适用于对 STF 的操作，对 STF 进行增补操作时，其被增补的对象必须是同一个研究的当前最新版本的 STF，更多有关 STF 的操作要求请参考《ICH 研究标签文件的 eCTD 骨架文件技术规范 V2.6.1》。不建议申请人对申请中除 STF 以外的其他文件进行“增补”操作。 

针对同一个叶元素不能进行多次生命周期操作以避免产生版本上的分支。例如，一个序列 0000 中的叶元素不能在序列 0001 和 0002 中同时被替换也不能在序列 0001 中先被替换再被删除等。 

6.2  首次申请 

针对一个申请的首次申请的首次提交，其序列号应为0000，所有申报资料的生命周期操作类型均为“新建”。 

6.3  撤回操作 

申请人在序列类型为“撤回”的序列中需进行以下操作： 

1.	针对当前注册行为前序序列中新建的叶元素，需在本次序列的骨架文件中进行删除操作。其中，说明函、申请表除外，申请人应保留前序序列中的说明函、申请表，并在本次序列中创建新的说明函。 

2.	针对当前注册行为前序序列中替换的文件，需替换回前序序列中被替换的文件，申请人应在对应叶元素中引用前序序列已经提交的文件路径，不应上传新的文件。 

3.	针对当前注册行为前序序列中删除的叶元素，需在原位置新建叶元素，并引用前序序列中对应的文件路径，并保持叶元素标题等属性的一致性。 

4.	在撤回序列中，对模块四中的 4.2.X 章节或模块五中的 5.3.1.X 至 5.3.5.X 章节的文件进行新建和替换操作，均需生成对应的 STF；进行删除操作，无需生成对应的 STF。 

6.4  特定文件的生命周期定义 

针对模块一 1.0 章节中的说明函文件，其生命周期操作类型应始终为“新建”。 

针对模块一 1.2 章节中的申请表文件，在补正资料时要求修改申请表的情况下，其生命周期操作类型可为“替换”；其他情况下，其生命周期操作类型应始终为“新建”。 

6.5  并行变更的要求 

在多个注册行为同时提交进行审评的情况下，申请人应注意在对申报资料中的文件进行生命周期操作或复用时，不得引用未被监管机构批准的内容。 

6.6  eCTD 骨架属性的变更管理 

ICH eCTD DTD 中定义了模块二至模块五部分章节的选填属性和必填属性（例如 2.3.S 及 3.2.S 中的活性成分及生产商为必填属性，2.3.P 及 3.2.P 中的产品名称、剂型、生产商为选填属性）。这些属性是为了对该特定章节的内容进行简单有用的描述，以便于对内容进行区分和分组。如需更新属性值，必须删除已有的 2.3.S 和 3.2.S 章节内容，并在新的2.3.S 和 3.2.S 章节中提交全部相关资料。 

根据《ICH eCTD IWG 问题解答和规范变更要求文件 V1.31》第 66 条，“活性成分”属性主要是为了区分复方制剂中不同的原料药，建议使用通用名称。“生产商”属性是为了在原料药有不同生产商的情况下利于对生命周期进行管理，如果申请人认为不需要对各生产商区分不同的 3.2.S 章节，可使用“所有”或“申请人”或“未指定”的属性值，后续变更生产商时，可以在不变更属性值的情况下对申报资料内容进行更新。 

===7. 对 eCTD 申报资料文件的要求 ===

7.1  外文在提交资料中的要求 

申请人提交的全部申报资料应当使用中文并附原文，其他文种的资料可附后作为参考，中文译文应当与原文内容一致。临床试验数据递交要求请参见《药物临床试验数据递交指导原则（试行）》。语言属性设置为外文的参考资料将不受某些 eCTD 验证标准的约束，详见《eCTD 验证标准 V1.0》章节 6-PDF 分析。 

更多有关外文资料提交的技术要求请参见《eCTD 技术规范 V1.0》第 3.5 章节。 

7.2  文件格式、版本及 OCR 的要求 

制作 eCTD 申报资料时，申请人应根据《eCTD 技术规范 V1.0》第 3.3.1 章节的要求选择正确的文件格式。针对 PDF 格式的文件，其版本应为 1.4、1.5、1.6、1.7 或 PDF/A-1、PDF/A-2。 

PDF 文件中的内容需要符合可复制、可搜索的要求，建议申请人使用由源文件（如 WORD 文件）转化形成的 PDF 文件，而不是扫描后创建的 PDF 文件。 

如申报资料包含无法访问电子来源的文件或需要第三方签章的文件，该部分资料可以是扫描后创建的 PDF 文件。扫描后创建的 PDF 文件属于纸质文件的数字转化，建议参考中华人民共和国档案行业标准《纸质档案数字化规范》（DA/T 31—2017）有关要求。对于上述需要扫描后创建的 PDF 文件，应启动光学字符识别（OCR）功能，确保内容可复制、可搜索。 

申请人可通过以下操作检查确认内容已正确转换：一是突出显示某一文本区域；二是检索某个词或短语。若未能突出显示文本区域或检索结果中未能显示词或短语，则证明OCR 并未识别该文本。 

7.3  页码编制的要求 

页码编制要求请参考《ICH eCTD 文件格式规范V1.2》。 

7.4  书签与超文本链接的要求 

申请人应对中文申报资料在文件内部和文件之间建立书签和适当的超文本链接。基线类型的注册行为对书签和超文本链接不做要求。其他有关书签与超文本链接的具体要求请参考《eCTD 技术规范 V1.0》第 3.4 章节。 

7.5  对文件压缩、加密的要求 

申请人不得对提交的申报资料中的文件进行任何压缩处理。 

申请人不得对提交的媒体介质以及申报资料中任何级别的单个文件/文件夹进行安全设置或密码保护。文件设置应允许打印及文本和图形选择，第 2.7.5、3.3、4.3、5.4 章节除外。 

申请人提交的 eCTD 申报资料需按照《ICH eCTD 技术规范 V3.2.2》要求，使用 MD5 加密算法生成校验和并记录在骨架文件和文本文件中，以便监管机构确认申报资料的完整性和合法性。 

7.6  文件大小的要求 

申请人需控制申报资料中单个PDF文件在500MB以内。针对大于 500MB 的文件，建议申请人按照内容进行拆分，并通过标题名称来反映原文件被拆分，例如：文件标题-1、文件标题-2 等。 

单个临床数据集文件（xpt 格式）最大可允许 4GB。 

7.7  电子签名的要求 

申请人需对 eCTD 申报资料中的所有 PDF 文件使用申请人或注册代理机构的电子签名，对申请表还需使用法定代表人的电子签名。电子签名的申领和使用详见药审中心网站CA 直通车。 

药审中心将对 eCTD 申报资料中“1.0 说明函（含自查表）、1.2 申请表、1.3.8 产品相关证明性文件（如适用）、1.10 上市后变更（如适用）、1.11 申请人/生产企业证明性文件、1.12 小微企业证明文件（如适用）”章节内的所有 PDF 文件进行电子签名校验，校验不通过的 eCTD 申报资料将会被拒收。 

===8. eCTD 技术规范更新流程及时间 ===

eCTD 技术规范及其配套文件会随着相关法律法规调整进行修订，可能会影响 eCTD 出版工具和提交、受理流程。 eCTD 技术规范更新发布后，eCTD 出版工具需要进行同步更新。监管机构将会根据实际情况，设置相应的过渡期。 

===9. 其他 ===

其他未尽事宜请参照《药品注册管理办法》等现行的法律法规、技术指导原则有关文件执行。 

===10. 参考 <sup>3</sup> ===

<sup>3</sup> <small>相关参考文件可参见ICH网站（ https://www.ich.org/ ）、药品审评中心网站（ https://www.cde.org.cn/ ）  </small>

1.	ICH eCTD Specification and Related files 

——ICH eCTD 技术规范和相关文件，包括变更控制过程、变更请求表和问答文档。 

2.	ICH Electronic Common Technical Document Specification V3.2.2 

——《ICH eCTD 技术规范 V3.2.2》 

3.	ICH The eCTD Backbone File Specification for Study Tagging Files V2.6.1 

——《ICH 研究标签文件的 eCTD 骨架文件技术规范V2.6.1》 

4.	ICH Specification for Submission Formats for eCTD V1.2 

——《ICH eCTD 文件格式规范 V1.2》 

5. ICH eCTD IWG Question and Answer and Specification Change Request Document V1.31 

——《ICH eCTD IWG 问题解答和规范变更要求文件V1.31》 

6.	《eCTD 技术规范 V1.0》 

7.	《eCTD 验证标准 V1.0》 

8.	《药物临床试验数据递交指导原则（试行）》 

9.	《药品注册申报资料格式体例与整理规范》

==附件4：eCTD技术规范V1.0附件包==

  RAwiki暂未收录
</div>


{{template:上市许可申请}}
[[Category:中国法律法规]]
[[Category:规范性文件]]
[[Category:上市许可申请]]