个例安全性报告（ICSR）电子传输实施指南

本指南文件是遵循 ICH E2B（R3）规范制定的个例安全性报告（ICSR）电子传输标准 实施指南，已被 ICH1采纳。本实施指南（IG）由 ICH E2B（R3）和 M2 专家工作组（EWG） 共同编制完成。其中，E2B (R3) 专家工作组负责提供业务需求，M2 专家工作组为本实施指南提供技术支持。上述两个专家工作组于 2010 年 11 月合并，组建 ICH E2B (R3) 专家工作组。

从概念上看，ICSR 是描述个例患者发生的不良事件/反应的信息报告。

该 ICH 实施指南主要适用于人用药品和治疗用生物制剂。但同时，ICH 也意识到在某些区域使用该指南时，可能将其适用于更广泛的范围，例如可用于与疫苗、草药、化妆品、兽用医药产品或医疗器械相关的药物警戒活动。ICH 对该指南的应用主要为制药行业内部、监管机构之间、以及制药行业与监管机构之间交换药物警戒信息提供便利。

该实施指南还可支持软件研发与工具的安装部署，以创建、编辑、发送和接收电子

ICSR 信息。

本实施指南不适合作为药物警戒实践的参考指南使用；不适合用来解释药品安全性信息整理、分类、分析等有关的基础科学或医学问题；本指南的制定并非为了对合理报告安全性信息的基本原理进行解释。

本实施指南的重点是关于如何执行相关规范的技术细节。因此，适用读者包括系统开发人员、IT 专业人员、系统实施者和系统用户。这些人员可以了解如何构建以及使用有效的电子传输技术进行 ICSR 信息的传输。该实施指南已提供足够必要的信息，用以支持开发适用的信息化工具（如用于终端用户进行数据输入的表格及界面）。同时，该实施指南还提供了样式表格设计、数据转换、编码规范相关的信息技术要求。但是，该实施指南并不以明示或暗示方式推荐或介绍任何特定数据库技术或软件开发平台。取而代之的是，本实施指南详述了依据给定标准生成有效 XML 代码的技术要求。

以下章节解释了 ICSR 电子信息传输相关的业务内容，包括 ICH 文件的各类相关资料及其在药物警戒活动中的业务应用规则。

本 ICH 实施指南的业务目标是标准化不同类型 ICSR 电子传输的数据元素定义，不管ICSR 来源和目的地在哪里都可以遵守此标准。该实施指南描述了批准上市前后不良反应和不良事件报告中 ICSR 的数据元素。本实施指南的技术目的是协助报告者和接收者（包括制药公司、监管机构和非商业申办者）构建系统来传输 ICSR 信息。 规范 ICSR 的传输内容遵循国际标准，不依赖具体的平台、应用或供应商。

本实施指南通过定义数量众多的数据元素，规范 ICSR 的格式与内容，以实现向大多数商业伙伴（包括监管机构）准确报告医疗信息的目的。数据元素及其格式可用来描述多种类型的病例报告，诸如不良反应或未发生不良事件的病例报告，如妊娠期间用药、药物过量、用药错误或潜在缺乏疗效。因此，为维持标准的完整性和可用性，建议尽量避免申请纳入额外的当地数据。ICH E2B (R3) ICSR 的实施指南不包含对数据库结构的定义、纸质报告表的设计、质量控制/质量保证、或技术安全性问题。

基于国家或国际间的协议、规则、条例以及保护患者安全的需要，有必要加快安全性信息的交换（如 ICSR）：

●       确定的报告来源地和监管机构、制药公司之间；

●       监管机构之间；

●       制药公司和监管机构之间；

●       制药公司之间；

●       临床试验研究者、临床试验的申办者和伦理委员会之间；

●       监管机构和世界卫生组织（WHO）国际药物监测合作中心之间。

安全性信息交换可以通过纸质形式（例如黄卡、CIOMS I 表格、MedWatch 表格等）或电子媒介（例如在线访问、磁带、CD 等）进行传输。考虑到全球范围内存在众多、潜在的信息交流参与者，有必要制定一种标准格式，按照该标准格式进行信息传输，实现数据库间直接传输，实现电子传输对通用数据元素定义的一致性理解，并遵循标准传输流程。上述所涉及的要求，已在本文档中提供。

在过去十年，随着病例报告数量的增加，ICSR 交换越来越多地从纸质形式转换为电子传输形式，安全性信息的电子传输已成为全球药物警戒的重要组成部分。ICH 于 1997 年发

布了 ICSR 电子传输标准，该标准自首次采用后已经历了多次修订。数年来，ICH E2B（R2） 标准的使用一直基于合规监管目的。实际上，在一些 ICH 管辖地区此标准作为强制性要求

本实施指南的制订过程与一般 ICH 文件制订流程有所不同，本文件由 ICH 与外部机构

（标准开发机构，SDO）共同合作编制的信息传输标准。本实施指南中的信息标准确立之前，曾由 ICH M2 专家工作组编制了 ICH 电子信息传输标准，其名称为监管信息电子传输标准（ESTRI）。具体而言，当前的信息标准是由 ICH 与联合行动委员会（JIC）共同制定； 而 JIC 是国际标准化组织（ISO）、医疗信息交换标准（HL7）、欧洲标准化委员会

ICH 为监管机构与制药行业联合在一起，以协调解决药物注册的科学和技术问题。关于 ICH 及其工作成果的更多信息，请登录 ICH 网站查询。

1997 年 7 月 17 日批准了首个 ICH E2B 指南：个例安全性报告传输的数据元素。于

2000 年 11 月进行了修改，之后于 2001 年 2 月再次进行修改，作为 ICH 第四阶段的 E2B

（M）指南出版。作为 ICH 管理文件的一部分，2005 年 5 月将 E2B（M）指南的第四阶段版本命名为 E2B（R2）指南，业务内容保持不变。2001 年 ICH M2 专家工作组制定了个例安全性报告的电子传输信息规范，通过识别和定义 ICSR 的核心元素，使得无论何种信息来源或发向任一接收方的 ICSR，其数据元素能够标准化地进行电子传输。

考虑到大规模数据和大量潜在人员参与全球范围内进行安全性信息交换，目前仍需要通过交互型数据库进行数据处理和格式化，有效传输安全性报告。这一需要导致了 E2B 文件的定期修订，如第 2.1.2 节（上文）所述。E2B（R3）不断迭代，在数十年来以受控的方式发展为新版电子 ICSR 标准。

ICSR 电子传输的成功依赖于电子信息的标准、通用数据元素和语法定义。因此，采用标准化电子信息进行跨地区、监管机构和其他参与者传输至关重要。 2006 年，ICH 为寻求

2 GS1 是一个国际非营利协会，致力于全球标准和解决方案的设计和实施，以提高全球和各行业的供需链的效率和可见度。

为扩大 ICH 的推广范围，并能够制定出全球统一和可实施的电子信息传输标准，ICH 指导委员会（管理 ICH 的机构）决定与 SDO 共同开发此标准。ISO、HL7、CEN、CDISC 和IHTSDO 以及各自的技术委员会（TC）和健康信息学标准化的利益相关者共同合作、协调和配合，努力支持创建全球电子健康信息标准，进而整合应用到更广泛的医疗环境中。

为此，上述 SDO 提出一项联合倡议，通过商定的决策程序来处理和解决差异、重叠和可能产生相反效果标准的问题。联合倡议的管理是通过联合行动委员会（JIC）进行，其由每个成员 SDO 的代表组成。这种方法有助于通过参与 SDO、根据相互承认和认可的标准对每个问题采用单一最佳标准。对于 ICH，与 SDO 合作利用电子标准开发的资源，避免重叠、产生相反效果或反作用标准，对于实现和维护其自身的统一目标至关重要。

ICH 关于 ICSR 标准的 ISO 初始新工作项目提案号为 ISO 27953，随后于 2008 年 2 月批准作为联合倡议项目。全球各相关方借助明确的结构化数据的电子交换来改善患者安全， ICSR 标准是在 SDO 组织协调下的产物，以此满足监管和保护患者的安全的需求。

ISO 27953 基于 ISO 新工作项目提案 N545（药物警戒-个例安全性报告的结构和数据元素）、HL7 ICSR 版本 1 规范标准和 HL7 ICSR 版本 2 试用标准草案（DSTU）对内容和信息传递规范进行了整合。ICSR 标准经历了 ISO 投票程序、国际标准草案、国际标准草案终稿和国际标准（IS）等步骤完成制定。该标准由 ISO 于 2011 年 11 月发布。

HL7 版本 3（V3）信息传输标准是在 HL7 的开发活动范围内的的卫生保健信息静态模型。ISO 认可 HL7 作为认证的合作伙伴组织，可共同发布的标准。首个共同发布的标准是ISO/HL7 21731：2006 年健康信息学- HL7 版本 3 -参考信息模型-版本 1。3已开发 HL7 V3 来解决健康信息技术的多种需求。HL7 参考信息模型（RIM）是 HL7 V3 的基石，也是衍生所有 HL7 信息的基本模型。RIM 定义了特定情况下所需的数据内容，并且提供了各元素和信息之间的语义和词汇连接的明确说明。HL7 V3 有助于系统间互通性规范的开发。HL7 模型驱动的方法可用于制定基于共识的标准，用于医疗保健系统互通性和信息交换。HL7 V3 信息是基于 XML 编码语法。欲了解更多关于 HL7 V3 的信息，请参见 Andrew Hinchley 的“了解版本 3：HL7 版本 3 医疗互通性标准-规范版入门”。ISO/HL7 27953-2 标准建立在HL7 ICSR 标准版本 3（或 HL7 ICSR R3）的基础上。HL7 ICSR R3 标准是基于 HL7 V3 的特殊信息构成。

交换 ICSR 主要是为了保护患者安全，从而促进公众健康。此外，交换 ICSR 由相关利益者贯穿整个公众健康服务各个过程，可用于临床研究，批准上市后持续安全性监测。电子报告有助于信息传递，随时获得安全性数据，以便对 ICSR 进一步处理和分析。这些优势有利于监管机构、上市许可持有人、医疗保健专业人员（HCP）和消费者在使用健康产品上做出更明智的决定。

假如无统一标准，各区域和监管管辖区之间存在多种信息和(或)内容标准，将加大信息交换成本，增加报告者的负担。缺乏统一性可能给全球层面 ICSR 的一致性核查带来困难。统一的标准才能激励供应商为标准本身开发互相通用的“现成”工具。统一的标准还将有助于最大限度地提高数据的向前兼容，并将向后兼容的复杂性降至最低。鉴于这些原因，卫生监管部门和制药行业正在共同制定一个有意义的统一标准，以供所有成员使用。

为了支持 ICH E2B 指南，ICH M2 专家工作组于 2001 年 2 月发布了“个例安全性报告电子传输信息规范（ICH ICSR DTD 版本 2.1），最终版本 2.3”。当时，考虑到 HL7 和EDIFACT（管理、商务和运输的电子数据采集）的电子信息标准化已于前期开展的工作， ICH 选择 SGML（标准通用标记语言，ISO 8879：1986）作为信息传输标准化的首选。这是因为 SGML 是信息交换的实际标准。SGML 还支持 ICH 地区所需的多语言字符集。

尽管如此，基于 SGML 的 DTD（文档类型定义）方法已经不再是最佳的解决方案。因此，此处提及的当前信息标准依赖于 XML 架构。理由如下。

2.4.2.1                      标记语言4

标准通用标记语言（SGML）于 1988 年首次出版，作为一个 ISO 标准（ISO 8879），

基于对功能和程序要求的良好理解，制定软件规范（如 E2B（R3）的规范）以支持业务需求的过程，以便准确地反映到电子信息中。电子信息不仅必须包含数据元素（XML 架构）的准确定义，而且还必须保证数据元素之间的关系，以进行有效的信息交换。关系图、属性列表、数字代码和有约束 ICH ICSR 架构的开发，均为开发软件规范过程的组成部分， 用于促进 ICSR 的电子传输。ICH ICSR 架构针对不良事件/反应数据的报告，可以指导准确维护和达到 E2B（R3）文件的预期目的。该实施指南的第 3 节列出了确定的 E2B（R3）数据元素和基本组成，以适用开发和交换的 ICH ICSR 信息。 ICH ICSR 信息的必要模式（架构）见附录 I（A）。

下图 1 表示 E2B（R3）中主要章节之间 ICH ICSR 信息和 XML 描述标记的关系。图中的每个框表示 E2B（R3）数据元素结构的相关章节，该框中的所有数据元素均列在属性列表（第 3.4 节）中。例如，个例安全性报告识别图中的框 C.1 表示 E2B（R3）数据元素对应的 C.1 模块。

E2B（R3）规范定义了数据元素之间的相互关系，允许存在强制/必须、可选、唯一或可重复（信息模块）。元素之间的关系有所不同，如下所示：

●       1 ..1（必须有，且唯一）；

●       0 ..1（可以无，或至多一条）；

●       1 ..n（必须至少有一条，或可多条）；或

●       0 ..n（可以无，或有多条）。

第 3.4 节中进一步提供了详细信息，旨在帮助商业用户了解 ICSR 的各个章节如何相互关联，同时帮助应用程序开发人员了解如何设计和开发 XML，以便符合 E2B（R3）规范。

一个 ICSR 存在数个术语和受控词汇以描述或编码其信息。这些术语或代码集是通用的且已被许多应用程序使用，例如质量或时间单位或国家代码。其他针对医学章节的，如MedDRA（国际医学术语词典）。还有一些是为 ICH 创建的特定代码列表。本节将介绍该实施指南中使用的代码集、术语和词汇。对每个单独元素提供的具体指南，参见第 3.4 节。

尽管第 3.4 节提供了代码集的技术规范（例如：数据类型），但这仅在此版本实施指南发布时有效。规范可能会随时间发生变化，以适应新的技术和新的商业需求。最终，代码集的验证规范（例如：允许的技术格式和数值）由维护术语的特定组织定义，并且应向这些组织询问进展以获取代码集的最新规范。

对象标识符（OID）是唯一标识该对象的数字序列。这些数字表示一个按等级分配的命

external-code-system.MedDRA”分支表示。

组织可以通过从注册服务商处申请一个标识符来获得 OID，如需要，组织可以转为注册服务商，并随后对其内部对象生成子 OID。ICH 正在实施 OID 以识别 ICSR 信息交换中使用的代码系统。

本实施指南本章节的表 1 至表 7 列出了用于编码 ICH ICSR 数据元素的所有 OID。ICH 网站提供了 ICH 注册的 OID 列表。除了表 1 至 7 中的 OID 之外，由 HL7 注册的部分 OID 也可用于 ICSR 信息，以区分某些元素的预期用途（例如在数据元素 Fr4 和 Fr5 中，用于检查结果正常值，分别使用不同的 OID 来区分“低”和“高”）。虽然下表中未描述这些HL7 注册的 OID，附录 I（D）中的参考实例提供了其在本文档中中使用的所有 OID。

ISO 药品的识别（IDMP）

在与 ICH 协作下，ISO 制定了一套标准，以加强药品信息交换。这些包括标识符，允许给药途径、剂型和测量单位以及受控标识符的国际术语映射，以实现药品的跨境识别并映射到其核心部分，例如物质。

ISO IDMP 标准包括：

●       ISO 11238 健康信息学-医疗产品识别-关于物质规定信息的唯一标识和交换用数据元素和结构

●       ISO 11239 健康信息学-医疗产品识别-药物剂型、给药单位、给药途径和包装上规定信息的唯一标识和交换用数据元素和结构

●       ISO 11240 健康信息学-医疗产品识别-测量单位上规定信息的唯一标识和交换用数据元素和结构

●       ISO 11615 健康信息学-医疗产品识别-医疗产品信息规定的唯一标识和交换用数据元素和结构

●       ISO 11616 健康信息学-医疗产品识别-医药产品信息上规定的唯一标识和交换用数据元素和结构

本文件的第 3.4 节中对 ISO IDMP 词汇表的应用进行了说明。但是，当 ISO IDMP 术语和（或）标识符（例如：代码值）尚不可用时，本实施指南提供了替代方法来进行信息编码。

MedDRA -国际医学术语词典

MedDRA®-国际医学术语词典-是用于涉及生物药物和其他医疗产品（如医疗器械和疫苗）的不良事件信息分类的医学术语。将这些数据编码为一套标准的 MedDRA 术语，使监管机构和生物制药行业能够更便捷地交换和分析医疗产品使用后的安全性信息11。

MedDRA 由 ICH 开发，其商标由国际药品制造商协会联合会（IFPMA）表示 ICH 所有。

MSSO 作为 MedDRA 的维护和支持服务组织，承担 MedDRA 的智囊团、维护者和经销商的角色，同时作为信息来源，提供 MedDRA 及其在生物制药行业和监管机构中应用的最新信息。 MedDRA 用户可提交对术语的修改建议。 MSSO 组织中聘请了医生，这些医生遍布全球，负责审查和回复所有用户的提出的建议。

ICH ICSR 使用 MedDRA 来编码众多医学概念，比如不良反应或事件、药物使用适应症、病史等。以下元素需要使用 MedDR 的低位语（LLT）进行编码。请注意，对单个 ICSR 中

的数据元素进行编码，必须使用同一个版本的 MedDRA。

10 可用时，这些将替换为已注册的 OID 参考。

本节包含与本实施指南相关的专门为 ICH 创建的代码集和 OID 表；这些代码集由 ICH

维护或为 ICH 服务。

表 3：E2B（R3）数据元素和 ICH ICSR 信息代码 OID

表 4：E2B（R3）数据元素和 ICH ICSR 信息代码值 OID（受 ICH 限制的 UCUM 代码值）

有一个例外情况，对于 F.r.3.3“检查结果”，ICH 未限制 UCUM 代码值的使用，允许此元素使用各种 UCUM 单位。UCUM 代码值可以从原始 UCUM 列表中筛选得出，并在表 8 中列出了 UCUM 的 OID。

表 6：E2B（R3）数据元素和 Ack 信息命名空间 OID

本节包含与本实施指南相关的代码集和 OID，但并非仅为 ICH 建立、也非 ICH 专用。在国际上，这些代码集由 ICH 以外的组织和实体负责在各个地区进行维护。因此，允许的数值和格式由维护相关代码的组织进行限定。

信息中所使用的外部代码集和 OID 包括：

●       ISO 3166 第 1 部分（α-2）-用于表示国家及其分支名称的代码-第 1 部分：国家代码， 国家名称的定义代码、附属领土和特殊关注的地理区域（2 个字母的代码）

●       ISO 5218 -信息技术-表示人类性别的代码

●       ISO 639-2 -表示语言名称的代码

●       UCUM -测量单位的统一代码（UCUM），区分大小写12

12 关于 UCUM 的更多信息，请访问 http：//unitsofmeasure.org/

UCUM 标准可以从 http：//unitsofmeasure.org/trac/下载 xml 或 html 格式

以下例外未在上表中列出，即“发送者的（病例）安全报告唯一识别码”（C.1.1）和“全球唯一病例识别码”（C.1.8.1）中使用的代码值未列出，因为这两个字段在取值上参

考了 ISO 国家代码体系，但并非仅包含 ISO 3166 第 1 部分进行编码。有关此处的详细信息， 请参见 C.1.1 的用户指南。

ISO 3166 国家代码的使用

ICSR 中的多个数据元素与药物、事件、发送者或报告者的国家有关。E2B（R3）的国家相关数据元素参考了 ISO 3166-1α-2 中的国家代码。

关于开发方式，ICH 电子指南遵循 ICH M2 的建议使用 UTF-8 进行 XML 信息编码。

E2B（R3）规范详细列出了 ICH ICSR 中的每个数据元素的解释，以及有关传输和用户指南信息的说明。

有效安全性报告的最少信息应至少包括：

●                      一个可识别的患者-以下几个数据元素中任一可被认为足以确定出可识别患者的元素（例如姓名首字母缩写、年龄、性别）；

●                      一个可识别的报告者-以下几个数据元素中任一可被认为足以确定出可识别报告者的元素（例如姓名、地址、资质）；

●                      一例不良事件/反应（或结果）；和

●                      一种可疑或有相互作用的药物。

几个数据元素中的任意一个即可确定出一个可识别的患者（例如姓名首字母缩写、年龄和性别）或一个身份可识别的报告者（例如姓名首字母缩写、地址和资格）。ICH E2D 第 5.1 节指南（http：//www.ich.org/products/guidelines/efficacy/article/efficacy- guidelines.html）为此部分提供了进一步的指导，且认可患者和报告者可以是同一 人，这同样符合最低报告标准。 由于某些国家的数据隐私保护，在国家之间可能不能进行患者的姓名首字母和其他可识别信息的交换。但是，必须填写第 D.1 节中的至少一个数据元素，并为该数据元素提供用户指南。

注：在“最少信息”的验证规则上，部分区域层面可能存在额外验证要求。

ICSR 信息电子传输指南包括了有助于评估单个不良事件/反应报告的所有相关数据的传输规定。依据本指南的信息标准可以实现 ICSR 完整信息传输，但需注意的是，并非要求每个数据元素每次均被传输。

此外，除了一份 ICSR 报告所需最少信息（见第 3.3.1 节），还应提供某些具体的管理信息以便处理报告：

●                      发送者的（病例）安全报告的唯一识别码（C.1.1）；

●                      报告类型（C.1.3）；

●                      收到本报告最新信息的日期（C.1.5）；

●                      此病例是否符合加速报告的当地标准？（C.1.7）；

●                      全球唯一的病例识别码（C.1.8）；

●                      报告者的国家代码（C.2.r.3）；

●                      发送者所在的机构（C.3.2）；以及

●                      当报告类型为“来自研究的报告”时，反应（事件）被观察到的研究类型

（C.5.4）。

尽管 ICSR 报告需要完整信息，但一旦满足最少信息，即被认为是有效报告。这适用于所有类型的 ICSR，包括首次报告、随访报告和修正或作废的报告。

报告时，所有可用信息应使用相关的 E2B（R3）数据元素和适用的标准术语及完全结

构化的格式，这些术语包括 ISO（国家代码、性别代码和语言代码）、MedDRA（例如病史、适应症和反应/事件）、UCUM（测量单位）和 ISO IDMP（详细信息见第 3.2.1.1 节）。更

多信息请参见各标准。

虽然交换其他非结构化数据（例如已公布的文章、完整的临床记录、X 射线图像等）并不属于本实施指南的范围，但此类数据传输的技术解决方案也在第 3.5 节的附件中列出，以供参考。

基于区域性报告义务和药物警戒业务需要，ICSR 可能会在不同的发送者和接收者之间被多次传输。转发过程中，对于信息的“转发者”而言，如未获得该病例新的可用信息， 其所有“接收到”的医疗信息在转发时不可被忽略或更改。

●                      发送者的（病例）安全报告唯一的标识码（C.1.1）；

●                      创建日期（C.1.2）；

●                      首次从来源收到报告的日期（C.1.4）；

●                      收到本报告最新信息的日期（C.1.5）；

●                      是否有附加文件？（C.1.6.1）；

●                      该病例是否满足本地加速报告的标准？（C.1.7）；

●                      安全性报告发送者的信息（C.3）；

●                      事件层面的严重性标准（E.i.3.2）；

●                      提供更多信息（F.r.7）；

●                      药物与反应/事件的相关性评价（必要时重复）（G.k.9.i.2.r）；

●                      发送者的诊断（必要时重复）（H.3.r）；

●                      发送者的评论（H.4）；以及

●                      ICSR 中自由文本数据元素的英文翻译。

除这些数据元素，还可以使用最新版本的 MedDRA 词典更新 MedDRA 编码。可能会存在以下情况：一个以上的 ICSR 共享着相同的“全球唯一病例识别码”

（C.1.8.1）或者由于对同一病例的信息进行顺序更新，一个以上的 ICSR 共享着相同的“最新信息日期”（C.1.5）。对于这些情况，应使用“创建日期”（C.1.2）来识别病例的最新版本。

E2B（R3）数据元素具有分层树状结构。其由 2 个主要部分 A 和 B 组成，其中 A 包含管理和身份信息，B 包含病例信息。附属章节按数据的性质分类，分别为：

●                      A 部分

○                      C.1 –个例安全性报告的识别；

○                      C.2 -信息的主要来源；

○                      C.3 –个例安全性报告发送者的信息；

○                      C.4 -文献参考；

○                      C.5 -研究识别信息。

○                      D -患者特征；

○                      E -反应/事件；

○                      F -与患者相关的检查结果和手术

○                      G -药物信息；和

○                      H –事件描述与更多信息

除表示事件（E.i）或药物（G.k）的字母“i”和“k”表示多记录之外，字母“r”也用于表示某数据元素或章节为多记录。

        

由此可见，本实施指南中的数据元素的编号层级与E2B（R2）不同。

●                      日期/时间格式

HL7 使用单一格式表示日期和时间：CCYYMMDDHHMMSS.UUUU [+|-ZZzz]。完整的 日期时间信息（可精确至秒）可使用此格式进行报告。该日期格式可提供适当精准度的数据。

ICH ICSR 不可传输“未来日期”。当跨不同时区传输时，发送者和接收者应配置其系统（例如用 ZZzz 调整到世界统一时间），以防止日期和时间被解读为“未来日期”。

更多详情请参见本实施指南的附录 II。

对于 E2B（R3），每个日期数据元素的最小日期精准度水平已在 3.4 节中规定。

●                      所有自由文本数据元素（除“用母语表示的主要来源的反应/事件”（E.i.1.1a）和“用母语表示的病例总结和报告者评论”（H.5.r））将提供英语以便国际传输。但是， Control Act Wrapper 本身支持用于区域性信息交换的语言代码。此部分内容请参见区域性实施指南。

●                      MedDRA 通常用于 ICH 地区的 ICSR 报告。有关 MedDRA 编码的其他建议，请参见最新版本的 ICH 文件“MedDRA 术语选择：需考虑的要点”。

●                      对自由文本在某些情况下的传输进行了约定，包括全文的病例总结描述。对“更多信息” 无法使用标准化的术语和结构化的格式输入时可以使用文本数据元素。同一个 ICSR 的

相关数据元素的编码仅可使用一个版本的 MedDRA。因此，当填写 MedDRA 术语时， 均应确定使用的是相同的 MedDRA 版本。但是，单个批次提交多个 ICSR 时，不同的ICSR 可以使用不同的 MedDRA 版本。

应注意的是：

●                      每个元素的数据类型描述如下：

○                      A =字母：该数据类型主要用于 ICSR 中某些使用受控词汇的数据元素，例如“报告者的国家代码”（C.2.r.3）- 2A，以适应 ISO3166 代码。需要字符类型的字符串数据元素只能包含大小写字母，例如“JP”。不允许使用数字和特殊字符，例如“.,^”；

所有 E2B（R3）数据元素和信息规范，请参见第 3.4 节中的表格。E2B（R3）数据元素表格中包含：

○                      为本实施指南的目的，确认回执的数据元素将以字母 ACK 开头，例如：

●                      数据元素 N.1.2 是指第 3.4 节中详细描述的“批量（信息）编号”；以及

●                      ACK.M.1 是指确认回执中的“批号确认”。

●                      数据元素名称；

●                      “用户指南”定义如何填写每个 E2B（R3）数据元素的信息；

●                      “是否必填”表示数据元素的值是强制的/必须的还是可选的。因“技术”原因（例如是否正确解析）将要求填写某些数据元素，一旦省略将会产生错误。技术信息附录 I（G） 提供了所需元素列表。

●                      “数据类型”和数据元素长度-每个数据元素将使用一个数字来表示其长度，之后加 A 表示字母、N 表示数字或 AN 表示字母数字。对于参考的代码集（例如非自由文本）的数据元素，应向维护术语的机构征询进展以获得最新代码值；

●                      对象标识符（“OID”) -该数据元素适用的特定识别代码列表或命名空间。本实施指南中提供的 OID 将应用于 ICH ICSR 的 XML 信息传输；

●                      “允许值”表示数据元素的可能值；以及，

●                      “业务规则”提供了一些数据元素的验证规则及附加细节。

本实施指南中的信息传递规范是由 ICH 各方使用并认可的统一规则。这些是应用于“导入”ICH ICSR XML 信息的验证条件（如“接收者”），因此，在准备“导出”ICH ICSR XML 信息时，应使用本实施指南来验证数据录入的准确性和合规性。

鉴于实际，本文件中为某些代码列表打印的“允许值”信息可能已过时或不完整。此信息将在本实施指南之外进行维护。可参见附录 I（F）中的最新代码列表。

与 ICSR 第 C 至 F 节中的信息不同，“封装”信息仅用于传输目的（例如“发送人”到“接收人”），通常不保存或存档。假定已建立电子数据交互（EDI）协议，以约定信息编号、发送者 ID、接收者 ID 和信息日期的制定规则。