最新发布:ICH《M8:电子通用技术文档(eCTD)v4.0》指导原则

4月20日，CDE发布关于公开征求ICH《M8：电子通用技术文档（eCTD）v4.0》指导原则及问答文件中文翻译稿意见的通知。

《M8：电子通用技术文档（eCTD）v4.0》

问答文件中文版

《M8：电子通用技术文档（eCTD）v4.0》

实施指南中文版

1. 目的

本文档为 eCTD v4.0 模块 2-5 实施指南与技术规范，采用 HL7 第 3 版受监管产品提交（RPS）第 2 版规范。需与《区域 / 模块 1 实施指南》结合使用，否则报文不完整。

2. 范围

仅包含所有地区共享的 eCTD v4.0 模块 2-5 提交技术规范，不含区域 / 模块 1 内容。定义药品监管提交电子交换消息，支持 v3.2.2 向 v4.0 转换与向前兼容。

2.1 业务案例

升级 eCTD v4.0 目标：促进电子监管提交处理审查，实现文档复用、文档与元数据生命周期管理、情境组管理。

3. 背景

3.1 一般背景与 eCTD 历史

eCTD 基于 ICH M4 CTD 结构，M2 EWG 制定 STF 规范用于模块 4-5 研究文件组织。2009 年启动 v4.0 需求，2010 年成立 M8 EWG，基于 HL7 RPS 第 2 版开发。

3.2 ICH 地区与观察员国实施经验

加拿大：2004 年接受 eCTD，2009 年起使用率升至 70%

欧盟：2002 年采纳 ICH eCTD，2010 年集中程序强制 eCTD，2017 年互认程序强制

日本：2004 年试点，2005 年正式接受，2009 年 v3.2.2 后提交量激增

瑞士：2010 年采用 v3.2.2，新药申请基本为 eCTD 格式

美国：2003 年接受 v3.0，2008 年 v3.2.2 为首选格式，2017 年上市申请强制 eCTD

3.3 ICH eCTD v4.0 框架

ICH 与 ISO、HL7、CEN 合作，基于 HL7 RPS 第 2 版制定 v4.0，目标建立全球通用电子消息标准。

3.4 eCTD v4.0 优势

统一提交单元：模块 1-5 整合为单一交换消息

文档复用：唯一 ID 支持跨提交、跨申请复用

使用情境生命周期：支持多对一替代关系，移除 “增补” 操作

情境组功能：替代 STF，按使用性质分组文档

3.5 变更控制

v4.0 基于 HL7 RPS 第 2 版，变更由 ICH M8 EWG/IWG 负责，遵循既定流程，SDO 标准变更同步跟进。

4. eCTD v4.0 组成部分

• 文件和文件夹

• 受控词汇表

• ICH eCTD v4.0 XML 架构

• 向前兼容

• eCTD v4.0 XML 报文

• OID 和 UUID

• 数据类型

• 《区域 / 模块 1 实施指南》

• 排除的业务流程

4.1 文件和文件夹

按规定结构组织，XML 报文引用文档，首次提交按文件夹存放。

4.2 受控词汇表

核心组件，保障系统互操作性，分 ICH、区域、HL7、外部组织、发送方定义五类。

4.3 ICH eCTD v4.0 XML 架构

分核心架构、RPS 架构、通用报文元素架构，可从 ICH 官网获取。

4.4 eCTD v4.0 XML 报文

基于 v4.0 架构，一个提交单元对应一条 XML 报文。

4.5 OID 和 UUID

OID：数字序列，分层命名空间，用于代码系统

UUID：8-4-4-4-12 格式十六进制文本，用于唯一标识

4.6 数据类型

支持文本、字母、字母数字、数值、布尔值、空值（未使用）。

4.7 《区域 / 模块 1 实施指南》

包含区域行政与产品信息，是完整报文必需文件。

实施者注意事项：本 ICH eCTD v4.0 实施指南中的信息具有必要性，但不足以用于创建完整的 XML 报文进行传输。需要《区域/模块 1 实施指南》，以发送完整的 XML报文。

《区域/模块 1 实施指南》可通过 ICH M8 eCTD v4.0 网站获取。

4.7.1 特定区域元素

各《区域/模块 1 实施指南》将涵盖特定于地区/国家的要素和业务规则（如适用）：

• application

o subject.reviewProcedure

o reference.applicationReference

o holder.applicant

o informationRecipient.territorialAuthority

• submission

o subject2.review

• subject1.manufacturedProduct

• holder.applicant

• author.territorialAuthority

• subject2.productCategory

• subject3.regulatoryStatus

o subject3.mode

o subject4.regulatoryReviewTime

o subject5.submissionGroup

• componentOf2.categoryEvent

o component.categoryEvent

有关所包含要素的地区/国家的更多信息，以及相关要素的具体技术要求和业务规则，请参阅《区域/模块 1 实施指南》。

4.8 排除的业务流程

本文档不涉及任何地区业务流程。地区业务流程可能包括但不限于以下内容：

• 双向沟通 – 包括监管机构与申请人沟通的信息。

• 注册申报资料管理/提交文档生命周期 – 包括提交单元、提交和申请的规则。

• 分组提交 – 由于监管流程的不同，各地区的处理方式可能不同。

有关地区/国家特定业务流程的更多信息，请参阅《区域/模块 1 实施指南》。

5. 提交内容、文件夹和文件结构

为随 XML 报文传输的文档内容指定的文件夹和文件结构应遵循本节所述的各规范和规则。

5.1 提交单元内容

提交提交单元的内容时，应使用以下结构：

图 1： 提交单元文件夹结构

特定地区文件夹将由地区/国家确定，更多信息见《区域/模块 1 实施指南》。某些地区可能不使用此文件夹。

所有地区的序列号文件夹应相同，并以提交单元的“序列号”（即序列号的实际值，例如 999）命名。当提交单元包含多个提交文档时，请参阅《区域/模块 1 实施指南》获取更多信息。二级文件夹应包括以下内容：

• 每 个 提 交 单 元 均 需 提 供 一 份 ICH eCTD v4.0 XML 报 文 ， 文 件 名 为“submissionunit.xml”。注：发送方不应发送架构文件，即不再需要 util 文件夹，XML 应引用正在使用的交互架构，参阅第 9.1 节。

• XML eCTD 实例（submissionunit.xml）的校验和也应包含在文本文件中，并命名为“sha256.txt”。文本文件必须包含在序列文件夹中，即与 XML eCTD 实例保存在同一目录中。

• 模块 1 至 5 的文件夹以及该提交单元(submission unit)中包含的内容。以下规则可能适用于该内容：

oM1 的文件夹结构应遵循各《区域/模块 1 实施指南》

oM2 至 M5 的文件夹结构应遵循本文档中提供的结构。参阅第 5.4 节和第 11节。

o这些文件夹中的所有文件应在 XML 报文中列出

o以前发送的文件无需再次发送

实施者注意事项 – submissionunit.xml 文件取代了之前的 v3.2.2 报文文件（即索引、地区和 stf XML 文件）。

实施者注意事项 – 当为 CTD 模块提供内容时，提交资料包应仅包含文件夹。提交资料包不应包含空文件夹。

5.2 命名规则

为实施 eCTD v4.0，修订了文件夹的命名规则。如需了解模块 2至 5的完整文件夹命名规则，请参阅第 11 节。

本小节未列出的其他命名规则指南包括：

• 文件夹和文件名应仅使用小写字母。

• 文件夹中的所有文件名应具有唯一性。当文件有特定命名要求时，可能需要添加额外的文件夹 。

• 所有文件应有一个且仅有一个文件扩展名。

• 文件扩展名应用于指明文件的格式。

• 一级文件夹应遵循相应《区域/模块 1 实施指南》中的详细规定。

5.2.1 允许使用的字符

所有实施方案应遵循 IETF 关于文件或文件夹名称的统一资源定位符（URL）规则（句点和星号除外）。所有字母和数字字符均可接受，特殊字符应限于下表中的字符。

表 5： 允许使用的特殊字符

参阅 IETF 关于统一资源标识符（URI）的文档：通用语法 RFC 3986。

有关允许使用的字符完整列表，包括研究数据文件中允许使用字符的附加说明，请参阅《区域/模块 1 实施指南》。

5.2.2 长度

文件或文件夹名称长度的限制应遵循以下规范：

• 最大文件名长度：64（包括文件扩展名）

• 最大文件夹名长度：64

• 包含一级文件夹的最大路径长度：180

• 注：这允许文件夹结构在逻辑驱动器中存在，并包含适合发送方环境的高层文件夹。如果路径超过 180 个字符限制或地区定义限制，则申请人创建的文件夹和文件名应缩写。

• 文件扩展名长度=3 或 4 个字符有关文件或文件夹长度的附加限制，请参阅《区域/模块 1 实施指南》。

5.3 路径名规则和最佳实践

路径名规则应使用斜杠符号（/）引用相对文件夹路径以分隔文件夹。例如，以下路径名表明文件相对于 submissionunit.xml 文件的位置，例如“m2/23-qos/introduction.pdf”。

5.4 文件夹层级结构

按照上述命名和路径名规则，文件夹层级结构应遵循第 11 节和《区域/模块 1 实施指南》中的指导。模块 3 示例如图 2 所示：模块 3 的文件夹层级结构示例。

图 2： 模块 3 的文件夹层级结构示例

如需了解模块 2 至 5 的完整文件夹层级结构，请参阅第 11 节。

注：在特定地区文件夹中，文件夹层级应不超过七（7）层（即嵌套层级不得超过 6层）。

这为不超过 ISO9660 规定的限值（8 层）提供了缓冲空间。可在发送方或接收方的文件目录中添加可能需要的附加文件夹。

5.5 文件格式

在 eCTD v4.0 报文中，未指定文件格式。有关任何提交内容（包括研究数据）可接受的文件格式的更多信息，请参阅《区域/模块 1 实施指南》。

注：有关 ICH 文件规范的更多信息，请参阅《eCTD 提交格式规范》。

5.6 校验和eCTD v4.0 XML 报文将包含所有 document.text.integrityCheck 元素的校验和。应采用 SHA-256 完整性检查算法，以获取给定提交单元内 document 元素中引用的所有文件的校验和。

获取校验和的目的如下：

• 每个文件的完整性可通过比较 XML 报文中提交的校验和与接收系统计算的校验和来验证。

• 校验和可用于验证文件在监管机构历史档案中未经更改。

5.7 压缩归档

压缩归档指添加到归档中，并经压缩以最小化存档文件大小的文件集合（例如 zip 文件和tar.gz 文件）。模块 2 至 5 的内容不应提交任何压缩归档。有关这些文件的更多信息，请参阅《区域/模块 1 实施指南》。

6. 受控词汇表

如第 4.2 节所述，在编制 eCTD v4.0 报文时广泛使用了受控词汇表。以下小节中的信息将概述用于编制 eCTD v4.0 报文的受控词汇表。受控词汇表有多个不同的权威来源，以下按受控词汇表的内容控制组织进行逐一阐述。第 6.1 节列出了 ICH eCTD v4.0 特定术语，即由 ICH确定的受控词汇表。

实施者注意事项：受控词汇表以通用代码和电子表格文件的形式提供。ICH 和地区控制的代码列表可在相应的实施包中获得。

截至 2024 年 01 月，ICH 的受控词汇表已拆分为单独的资料包，并进行了相应的版本命名。有关受控词汇表版本命名的更多信息，请参阅第 6.6 节。

ICH 和/或地区维护的受控词汇表将受版本控制。分配给每个代码列表的 OID 将显示其版本号。提交词汇时，必须提供有效版本。有关变更控制的更多信息，请参阅第 3.5 节。

6.1 ICH 规定的受控词汇表

下文提供了 ICH M8 为 eCTD v4.0 规定的受控词汇表，并简要描述了相关术语及获取详情的位置。ICH eCTD v4.0 实施包的通用代码和电子表格文件中提供了所有受 ICH 控制的词汇表。

• eCTD v4.0 – 使用情境代码：指定使用情境值的代码集，这些值将表示CTD结构（尤其是模块 2 至 5）中的标题。

请参阅《区域/模块 1 实施指南》，以完成允许使用的使用情境词汇列表。

• eCTD v4.0 – 关键词代码：指定含受控词汇的关键词类型（例如，种属、给药途径、持续时间和控制类型等）。

请参阅《区域/模块 1 实施指南》，以完成允许使用的关键词定义词汇列表。

• eCTD v4.0 – 关键词定义代码：指定 keywordDefinition 下的各类关键词代码（例如，生产商、剂型、原料药、适应症、文件类型、组标题等）。注：关于关键词定义的

发送方定义值属性，请参阅第 6.5 节。关于关键词定义类型，请参阅实施包中的电子版受控词汇表。

请参阅《区域/模块 1 实施指南》，以完成允许使用的关键词定义词汇类型列表。

• eCTD v4.0 – 介质类型：指定特定文档格式。可通过接收实施利用此附加信息，以实现内容的特殊处理。

请参阅《区域/模块 1 实施指南》，以完成允许使用的介质类型词汇列表。

6.2 区域规定的受控词汇表各地区为 eCTD v4.0 规定的受控词汇表如下所示。codeSystem 属性为将在《区域/模块 1 实施指南》中定义的各代码集提供 OID。

• eCTD v4.0 – 申请代码

有关允许使用的申请词汇完整列表，请参阅《区域/模块 1 实施指南》。

• eCTD v4.0 – 申请参考原因代码

有关允许使用的申请参考原因词汇完整列表，请参阅《区域/模块 1 实施指南》。

• eCTD v4.0 – 类别事件代码

有关允许使用的类别事件词汇完整列表，请参阅《区域/模块 1 实施指南》。

• eCTD v4.0 – 联系方代码

有关允许使用的联系方词汇完整列表，请参阅《区域/模块 1 实施指南》。

• eCTD v4.0 – 使用情境代码：指定用于表示 CTD 结构中地区当局指定标题的代码集（尤其是模块 1）。

有关允许使用的使用情境词汇完整列表，请参阅《区域/模块 1 实施指南》。

• eCTD v4.0 – 关键词代码：指定含受控词汇（地区当局可另行指定）的关键词类型。

有关允许使用的关键词汇完整列表，请参阅《区域/模块 1 实施指南》。

• eCTD v4.0 – 关键词定义代码：指定了地区当局指定关键词类型的关键词代码。

有关允许使用的关键词定义词汇完整列表，请参阅《区域/模块 1 实施指南》。

• eCTD v4.0 – 成分角色代码

有关允许使用的成分角色代码词汇的完整列表，请参阅《区域/模块 1 实施指南》。

• eCTD v4.0 – 制成品代码

有关允许使用的制成品词汇完整列表，请参阅《区域/模块 1 实施指南》。

eCTD v4.0 – 介质类型

有关允许使用的介质类型词汇完整列表，请参阅《区域/模块 1 实施指南》。

eCTD v4.0 – 模式代码

有关允许使用的模式词汇完整列表，请参阅《区域/模块 1 实施指南》。

eCTD v4.0 – 位置代码

有关允许使用的位置词汇完整列表，请参阅《区域/模块 1 实施指南》。

eCTD v4.0 – 产品类别代码

有关允许使用的产品类别词汇完整列表，请参阅《区域/模块 1 实施指南》。

eCTD v4.0 – 监管状态代码

有关允许使用的监管状态词汇完整列表，请参阅《区域/模块 1 实施指南》。

eCTD v4.0 – 监管审查时间代码

有关允许使用的监管审查时间词汇完整列表，请参阅《区域/模块 1 实施指南》。

• eCTD v4.0 – 审查程序代码

有关允许使用的审查程序词汇完整列表，请参阅《区域/模块 1 实施指南》。

eCTD v4.0 – 提交代码

有关允许使用的提交词汇完整列表，请参阅《区域/模块 1 实施指南》。

eCTD v4.0 – 提交单元代码

有关允许使用的提交单元词汇完整列表，请参阅《区域/模块 1 实施指南》。

• eCTD v4.0 – 原料药代码

有关允许使用的原料药词汇完整列表，请参阅《区域/模块 1 实施指南》。

eCTD v4.0 – 地区当局角色代码

有关允许使用的地区当局角色代码词汇的完整列表，请参阅《区域/模块 1 实施指南》。

eCTD v4.0 – 地区代码

有关允许使用的地区代码词汇的完整列表，请参阅《区域/模块 1 实施指南》。

6.3 HL7 规定的受控词汇表

下文提供了 HL7 规定的受控词汇表，并简要描述了相关术语及获取详情的位置。

• HL7 文档类型代码：此词汇表在 HL7 第 3 版标准中提供，用于 XML 报文中某些元素的 typeCode 属性。这些代码仅适用于 XML 架构中未固定的 typeCode 属性。对于任何 typeCode 属性，XML 报文中不需要 codeSystem OID。注：这些固定值在本文档第 9.2 节中提供，供需要指定 typeCode 的各元素使用。

• HL7 状态代码：此词汇表在 HL7 第 3 版标准中提供，用于 XML 报文中各元素的statusCode 元素部分。这些值应该在 XML 报文中用于 statusCode.code。状态代码不需要 codeSystem OID。注：状态代码只能使用 HL7 提供和 ICH 规定的值。

• HL7 更新模式代码：此词汇表在 HL7 第 3 版标准中提供，用于 XML 报文中某些元素的 updateMode 属性。这些代码是 updateMode 属性所必需的。该架构未加限制，

本文档为需要 updateMode 的各元素提供了允许值。有关更新模式的更多信息，请参阅 9.2.2.3。

实施者注意事项：HL7 RPS 标准要求的受控词汇表支持系统间通信，但并非总是在系统图形用户界面（GUI）中显示概念的理想方式。注意避免在 GUI 中使用技术代码，而应使用监管机构在《区域/模块 1 实施指南》中规定的业务友好型术语。

6.4 外部组织规定的受控词汇表

其他组织（非 ICH、地区或 HL7 管理组织）规定的受控词汇如下，包括责任组织、术语简要说明及获取详情的位置。

• 国际标准化组织（ISO） – 双字母语言代码：这是一个为 ISO 639.1 标准中规定语言指定的双字母代码。此词汇用于定义 text@language 属性。

• ISO 国家代码 – 双字母国家代码：这是 ISO 3166-1 标准中规定的国家代码。

6.5 发送方定义值

本节议题为将发送方定义值分配给 XML 元素提供了一般指导，以便在受监管行业内和行业之间的申请中确保一定程度的一致性。任何发送方定义值都应清晰、简洁，并保持最少的字符数，以便有意义地呈现信息。虽然发送方定义值没有最小字符长度限制，但如果超过显示参数（参数因地区而异），则可能需要在查看工具中进行截断处理。

6.5.1 关键词定义

对于发送方定义的词汇表，特别是 keywordDefinitions.value.item.code，报文中需包含 code 和codeSystem 值。申请人可使用其自行分配的这些值。此外，申请人可以但不需要遵循第 4.5.1节中提到的 OID 分配。如果采用 OID 分配，则可以使用任一种类型的 OID，因为它们具备技术兼容性。接收方将在单个申请中使用这些值。因此，在申请中使用 keyword 代码的值不应有任何冲突或问题。

实施者注意事项：可能存在需要跨申请管理发送方定义词汇的业务场景（例如，分组提交）。建议跨申请管理关键词定义，以优化其未来在各相关申请中作为使用情境关键词的使用。更多信息，请参阅《区域/模块 1 实施指南》。

6.6 受控词汇表实施包

本节概述了代码列表版本命名和单个代码值的受控词汇表内容。受控词汇表资料包涵盖以下内容：

• 自述文件 – 包括受控词汇表内容的历史和清单

• eCTD v4.0 CV – 包括每个代码系统的人类可读信息

• 通用代码文件夹 – 包括每个代码系统的机器可读文件

人类可读和机器可读的代码列表包含相同信息。

实施者注意事项：有关文件内容的说明，请参阅 ICH 受控词汇表实施包“自述”文件。有关地区代码列表的更多信息，请参阅《区域/模块 1 实施指南》。

6.6.1 代码列表

本节概述了各代码列表的相关信息。代码列表在受控词汇表资料包中提供。各代码列表均受版本控制，并包括其各版本的使用信息。

各代码列表包括以下关键信息，用于确定代码系统版本的支持日期：

• 代码系统名称：代码系统名称

• 描述：代码列表的简要说明

• XPATH：在 submissionunit.xml 模型中的路径，用于定位元素

• 代码系统 OID：代码系统版本的值

• 开始日期：代码列表/值集的开始支持日期

• 修订说明：指示在当前版本中对代码列表所做的更改。

• 每次列表上的代码发生变化时，都会更新代码列表的版本。如果代码列表有效，则可使用。

6.6.1.1 ICH 支持期

代码列表有 ICH 支持期。ICH 支持期具有起始日期和终止日期。在任何时间点，代码列表均可能有一个或多个有效版本。

表 6： 代码列表示例

以下小节描述了 ICH 支持期的解释方法，即代码列表是否有效或弃用，以及代码的生命周期。

6.6.1.1.1 有效代码列表

如果缺失 ICH 支持的终止日期，则表明代码列表有效。可同时支持多个代码系统版本。如果版本间发生以下变更，代码列表仍受支持：

• 无代码变更，但文本描述、映射或备注/注释发生变更

• 添加代码

表 6 中的示例显示了两个当前版本，即版本 3 和版本 4，并且二者均可使用。在本示例中，版本 4 的新代码不能与版本 3 的代码系统 OID 一并发送。有效值应存在于引用的代码系统中。

6.6.1.1.2 已弃用代码列表

如果代码列表已弃用，则将同时具有 ICH 支持起始日期和结束日期。已弃用代码列表在结束日期之后不再支持使用。如果版本间发生以下变更，代码列表可能弃用：

• 替换代码

• 删除代码

• 如果代码用于验证

表 6 中的示例展示了一个已弃用代码列表（版本 2）。自 ICH 支持结束日期 2022 年 01 月 01日起，该代码列表不可使用。如果版本 2 的代码系统 OID 在结束日期之后提交，则不予支持。

实施者注意事项：有关 ICH 支持期的使用，请参考验证标准。更多信息，请参阅《区域/模块 1 实施指南》。

6.6.1.2 修订历史

代码列表还包括修订历史，以总结仅针对当前版本的更改。

实施者注意事项：有关受控词汇表的详细历史记录，请参阅 ICH 受控词汇表实施包“自述”文件。如需了解更改历史详情，请参考之前版本的受控词汇表。

6.6.2 代码值

本节包含各代码列表代码值的相关信息。代码值可能随时间变化。当代码值状态发生变化时，各代码列表将提供操作和使用信息。

代码值始终包含以下信息：

• 代码 – 代码值标识符

• 描述 – 代码值的简称或解释

如适用，将提供以下信息：

• 引用 – 代码值使用指南的引用

• 备注/注释 – 表示与实施者相关的注释或备注

• 状态 – 表明代码是否有效并可用，或已弃用且不再有效。

• 操作 – 表明代码是否被添加、替换、删除或未变更。

• 先前有效代码 – 如果该代码是替换代码，则将显示先前的代码

• 当前有效代码 – 如果该代码已弃用，则将包括替换代码

• 最后有效版本 – 表明已弃用代码的最后有效版本

• 修订说明 – 实施者在修改后如何处理此代码的说明

实施者注意事项：所有情境组验证规则均适用。如果任何代码值发生变化，则该内容的生命周期将中断。内容应作为新内容提交，包含新的情境组元素；若先前内容不再相关，则中止。

以下小节提供代码列表内代码值随时间维护的相关附加信息。

6.6.2.1 状态

受控词汇表版本命名在各代码列表（即电子表格或通用代码文件的每个选项卡）中进行；但在这些代码列表中，各版本均具备有效值。代码值为“有效”或“弃用”。代码列表有效时，“有效”代码值可供使用。“弃用”代码值不再可用。它将包含于“最后有效版本”列中。最后有效版本示例参阅表 8。

6.6.2.2 操作

代码值与以下选项之一相关联：

• “不更改代码”包括对注释的更改和/或受控词汇表与通用代码文件之间的映射或更新

• 新增：在代码列表中添加一个或多个代码。如果所有更改均为新代码，则不应强制弃用前一版本。

• 替换：代码列表中的一个或多个代码值替换了另一个或多个代码值。

◦ 先前有效代码 – 如果代码值是替换项，则此列将包含对先前代码的引用

◦ 当前有效代码 – 如果代码值被替换，则此列将包含一个替代代码

• 删除：一个或多个代码值从代码列表中删除，且不应再使用

• 无/空白：如果该项在当前版本之前存在，则操作字段留空

表 7 总结了代码列表中代码值的潜在状态操作及其对内部或外部受控词汇表实施的影响。

表 7： 代码值操作

6.6.2.3 版本命名规则

对代码列表中代码值的以下更改可能会导致整个代码列表弃用，并为上一个代码列表版本分配 ICH 支持结束日期。

• 代码列表包括任何已删除值；或

• 被替换的代码值应专用；即，在任何情况下皆不应使用弃用代码值。

当现有代码值能与新代码值结合使用时，则无需弃用上一个受控词汇表版本。

6.6.2.4 代码列表示例

本节提供了代码列表变更的示例。表 8*展示了代码列表示例版本 2，其中对有效代码值进行了以下修订：

• 无代码变更：黄色（ich_color_2）和纯蓝色（ich_color_3）已更新以添加十六进制颜色参考编号。

• 新增：橙红色（ich_color_7）和橙色（ich_color_8）为新代码值。

• 替换：纯红色（ich_color_1）被鲜红色（ich_color_5）和深红色（ich_color_6）替换。在 ICH 支持结束日期（版本 1）之后，不得再使用纯红色。

• 删除：粉色已被删除，在 ICH 支持结束日期（版本 1）之后不得再使用。

表 8： 代码列表版本 2 中的代码值示例

*注：仅供说明之用，即数值为示例，不应提交。

7. ICH eCTD V4.0 XML 架构

7.1 核心架构

核心架构是 ICH eCTD v4.0 XML 架构的基础。这些架构不会直接引用，而是在 ICH eCTDv4.0 架构中相互间接引用。

7.1.1 InfrastructureRoot-r2

此架构定义了对所有其他架构中所有元素的有效属性。注：本实施指南中未直接引用此架构中的元素。

7.1.2 iso-21090hl7-r2_datatypes

该架构提供了用于定义元素和属性的 ISO-21090 数据类型。该文件定义了架构中 ISO-21090数据类型的组成，并包含在基础结构根架构中。

注：本实施指南中未直接引用此架构中的元素。

7.1.3 Voc-r2

此架构提供了标准中的词汇项。包括 eCTD v4.0 XML 架构中固定或受限的所有词汇。

注：本实施指南中未直接引用此架构中的元素。

7.2 eCTD v4.0 架构

eCTD v4.0 架构由分类为交互或报文类型的架构组成。本节介绍了相关的 eCTD v4.0 架构。

7.2.1 eCTD v4.0 交互架构

交互架构包含完整 XML 报文所需的三个组成部分：交互架构、传输包架构和控制活动架构。

7.2.1.1 发送的提交单元（PORP_IN000001UV.xsd）

此架构用于所有 eCTD v4.0 交互，以便发送方发送提交单元至接收方。此架构指示报文类型，即主要的有效载荷架构和必需的传输包。

7.2.1.2 传输包（MCCI_MT0001000UV01.xsd）

此架构提供所有 eCTD v4.0 报文所必需的传输包。它提供关于发送方和接收方的信息，以便进行各报文的确认。

注：本实施指南中仅提及此架构中的必需元素。有关必需元素，请参阅第 9.1 节。

7.2.1.3 控制活动包（MCAI_MT700201UV01.xsd）

此架构为正在发送的报文提供触发事件控制活动。

7.2.2 eCTD v4.0 有效载荷架构

7.2.2.1 有效载荷-报文类型（PORP_MT000001UV01.xsd）

此架构是 eCTD v4.0 的基础，包含了 eCTD v4.0 中所有的必需元素。此架构引用了上一节中提及的许多其他架构，包括来自通用产品模型和通用报文元素架构的组成项。引用的架构未在本文档中描述，实施方也不会直接访问这些架构。

8. 向前兼容

对于包含 v3.2.2 内容且正申请转换为 v4.0 报文的任何注册申报资料，应使用向前兼容。

v3.2.2 内容与 v4.0 内容的集成应能够：

• 使用一种工具向用户（构建者/查看者/审查者）无缝呈现 v3.2.2 和 v4.0 注册申报资料中的内容及信息，以支持发布和查看包含 v3.2.2 和 v4.0 提交文档的完整注册申报资料内容。

• 持续引用 v3.2.2 内容

• 启用 v3.2.2 有效内容的生命周期

• 启用 v3.2.2 内容的文档复用，包括尚未转换为 v4.0 的申请

• 一旦收到申请的 v4.0 提交单元，所有后续序列必须在 v4.0 中发送，即在收到首个v4.0 报文后，收到的 v3.2.2 报文将被拒收。

• 各地区将确定在转换为 v4.0 时如何处理开放注册行为（即是否有任何特殊说明）。

实施者注意事项 – 一旦申请转移为 v4.0 报文，这些说明应当能够实现向前兼容。具体细节请参阅《区域/模块 1 实施指南》。

8.1 向前兼容的考虑因素

• 提交 v3.2.2 内容引用的说明应符合以下条件：

• 提交内容的生命周期仅允许用于有效（如新建、替换）叶节点元素（即当前视图中的内容）；

• 替换 v3.2.2 内容时，必须遵循 v4.0 情境组生命周期规则；

• 将第一个 eCTD v4.0 序列提交到 eCTD v3.2.2 注册申报资料中时，下一个可用序列号以整数形式提交。例如，如果最后一条 eCTD v3.2.2报文的序列号为“0003”，则第一个 eCTD v4.0 提交单元的序列号为“4”；

• 验证规则适用于包含 v3.2.2 引用的提交单元；且仅当在提交单元中使用向前兼容时，才进行相关验证；以及

• 提交应与 v3.2.2 内容分组的 v4.0 内容时，关键词代码和值必须匹配。

8.1.1 v3.2.2 叶元素的专属链接

v4.0 报文对象需有唯一标识符，包括使用情境、相关使用情境和文档引用。

叶元素引用由以下信息组成：

• 申请标识符 – 跨申请引用以进行文档复用时申请的地区标识符

• 序列号 – 提交内容时分配给 v3.2.2 注册行为的编号（即四位数值）

• XML 类型 – v3.2.2 文件类型（如 ich 或地区性）

• 叶元素 ID – 在 v3.2.2 中提交的标识符，供引用提交内容

• 因此，引用 v3.2.2 内容时，应遵循以下规则：

• 在 id@root 属性中使用 v3.2.2 OID 作为“命名空间”，以表明该内容在前次申请中的特有性

• 在 id@extension 属性中使用叶元素 ID 作为“该命名空间中的标识符”，以引用 v3.2.2叶元素。叶元素 ID 应遵循以下模式之一：

• 生命周期引用（在同一申请中）：

• sequenceNumber.xmlType.leafId（例如，

  0000.ich#NLAS57D17EB601C9EDCA）

• 文档复用

• 在同一申请中：

• sequenceNumber.xmlType.leafId（例如，

  0000.ich#NLAS57D17EB601C9EDCA）

• 跨申请

• 具 有 地 区 分 配 的 申 请 类 型 和 编 号 的 申 请 标 识 符 ：

ApplicationTypeApplicationNumber.sequenceNumber.xmlType.leafId（例如，

nda123456.0000.ich#NLAS57D17EB601C9EDCA）

• 具 有 地 区 分 配 的 申 请 类 型 和 地 区 内 容 编 号 的 申 请 标 识 符 ：

ApplicationTypeApplicationNumber.sequenceNumber.xmlType.leafId（例如，

nda123456.0000.usregional#NLAS57D17EB601C9EDCA）

• 具 有 唯 一 标 识 符 的 申 请 标 识 符 （ 如 UUID ） ：

UUID.sequenceNumber.xmlType.leafId （ 例 如 ， 5f0e8436-e1df-4031-90d3413deff109e5.0000.ich#NLAS57D17EB601C9EDCA）

实施者注意事项 – 有关叶元素参考预期值的详细信息，请参阅《区域/模块 1 实施指南》。

8.1.2 向前兼容的特殊考虑因素

v3.2.2 中的内容可能来自 index.xml、region.xml 或 stf.xml 文件。当替换 ICH v3.2.2 内容或提交应与 v3.2.2 内容分组的新 v4.0 内容时，index.xml 属性值（例如 manufacturer）和 stf.xml 值（例如 study id title, file-tag）必须匹配。下表将内容映射到 v4.0 元素和属性以及预期用途

表 9： 属性映射

各前向兼容功能的说明见第 9.2 节和第 12 节。

9. eCTD V4.0 XML 报文

eCTD v4.0 XML 报文包含了比本节中定义的更多概念；本节仅重点介绍 CTD 模块 2 至 5 所需的组成部分。

9.1 报文头（Message header）

报文头信息提供一组元素，用于指定发送方和接收方，以及生成报文所用的 ICH 版本和《区域/模块 1 实施指南》版本。

9.1.1 XML 示例

以下 XML 显示了根据架构验证报文的必需元素/属性。

表 10： 报文头 XML 结构