E2B(R2)安全性消息处理和个例安全性报告技术规范

E2B(R2)安全性消息处理和个例安全性报告技术规范（版本号1.0）国家药品监督管理局药品审评中心二O一八年七月三十日目录一、前言.........................................................1二、电子报告要点.................................................3三、个例安全性报告（ICSR）电子传输的数据质量原则.................4四、生成有效ICH安全性消息.......................................5五、在CDE系统中正确上传ICH安全性消息的要求.....................7六、通用ICH安全性消息流.........................................8七、CDE系统中的ICH安全性消息流.................................10八、ICH安全性消息和个例安全性报告...............................13九、ICH确认消息................................................16十、ICSR分类...................................................37附录A业务规则................................................40附录BICSR验证................................................62附录C剂型查询列表策略........................................63附录D中国特殊要求............................................64附录E参考文件................................................65附录F变更表..................................................65附录G安全性信息电子交换相关术语...............................661一、前言本规范从各个方面对药品审评中心（CDE）所执行的消息处理和确认生成进行说明。本规范适用于所有业务相关方，即与CDE以电子方式交换安全性消息和ICSR者。本规范概述内容如下：电子报告要点（第二章）ICSR电子传输的数据质量原则（第三章）有效ICH安全性消息的生成（第四章）在CDE系统中正确上传ICH安全性消息的要求（第五章）通用ICH安全性消息流（第六章）CDE系统中的ICH安全性消息流（第七章）安全性消息和ICSR（第八章）ICH确认消息（第九章）ICSR分类（第十章）必填的ICHE2B(R2)数据元素描述和由CDE执行的验证检查完整列表，详见附录A。ICSR验证步骤见附录B。剂型查询列表策略描述见附录C。中国特殊要求描述见附录D。参考文件列表见附录E。变更表见附录F。2安全性信息电子交换相关的术语定义见附录G。验证规则（包括必填的ICHE2B(R2)数据元素）适用于可向CDE报告的所有ICSR。也适用于中国境内或境外符合加速报告标准的所有ICSR。3二、电子报告要点CDE负责接收、评价和处理中国药物研发过程中的可疑非预期严重不良反应（SUSAR）。CDE鼓励上市许可持有人（MAH）、申请人、干预性临床试验/非干预性研究申办者的可疑不良反应个例安全性报告的电子交换；早期检测与人用药物相关的可能安全性信号；持续监测和评价与所报告不良反应相关的潜在安全性问题；决策过程（基于对药物不良反应情况的更广泛了解）。4三、个例安全性报告（ICSR）电子传输的数据质量原则符合加速报告标准的ICSR相关医疗和管理数据应符合ICHE2A、ICHE2B(R2)、ICHM1和ICHM2标准，以电子传输方式向CDE进行报告。对于发送者已有的完整个例信息，应采用ICHE2B(R2)的所有适用和相关数据元素和术语，使用经完全结构化的格式填写的ICSR进行报告，必要时应重复。该规定适用于所有类型的ICSR，如病例初始报告、随访报告和后续标记为无效的报告（ICHE2B(R2)A.1.13：‘报告无效’设为‘是’，ICHE2B(R2)A.1.13.1：‘无效原因’已完成）。与个例相关的任何支持信息，均应在ICSR中充分说明，并附发送者持有的参考文档（ICHE2B(R2)A.1.8.2：‘发送者持有文档清单’），并可根据要求提供相应文档。与其他发送者曾传输的相同病例相关的任何信息，应在‘既往传输的其他病例标识符’（ICHE2B(R2)A.1.11）中提供。应遵照ICHE2B(R2)指导原则[1]附件3所述示例。该示例有助于检测和管理重复报告。基于当前的不良反应报告规则和实践，可能发生个例重复，应予以检测和管理。[1]ICH三方协调指导原则-ICH临床安全数据管理指导原则的维护：个例安全性报告传输的数据要素-E2B(R2)人用药品注册技术要求国际协调会议;第4版，2001年02月05日ICH文件：://estri.ich.org/e2br22/E2B_R2_Guideline.pdf四、生成有效ICH安全性消息本章内容主要介绍生成有效ICHICSR安全性消息（也称为安全性消息）的流程，即ICHM2文件[2]定义的符合ICH标准的安全性消息。这是确保各方与CDE顺利交换安全性消息的先决条件。安全性消息应参考文档类型定义（DTD）规范第2.1版。（一）XML可扩展标记语言（XML）是与CDE交换安全性消息和确认消息所采用的标准。XML是标准通用标记语言（SGML）的子集，与SGML完全兼容，因此，可以像超文本标记语言(HyperTextMarkupLanguage，HTML)一样在网络上服务、接收和处理通用SGML。XML便于实现，并可与SGML和HTML互通。为适应多语种的使用以及在ICHICSR消息的各种标签内识别文本的不同语言，为标签标记了语言属性。XML已广泛认可该方式。有效的XML安全性消息或确认消息需包括XML消息头（messagehead）和DTD引用。关于这点，还应声明安全性消息和确认消息所用的字符集。对于安全性消息，接受使用的字符集是UNICODE（UTF-8）。CDE用UTF-8返回确认消息，确保语言兼容。安全性消息应包括下列XML消息头：?xmlversion=”1.0”encoding=”UTF-8”?UNICODEUTF-8安全性消息应包括下列DTD规范2.1版：!DOCTYPEichicsrSYSTEM确认消息在消息层面应包括下述XML消息头和DTD规范。?xmlversion=”1.0”encoding=”UTF-8”?!DOCTYPEichicsrackSYSTEM[2]ICHM2EWG-个例安全性报告消息电子传输规范（ICHICSRDTD2.1版）,最终2.3版,2001年2月1日修订文档.人用药品注册技术要求国际协调会.6XML规范的符合级别分两级：结构良好和有效消息。1.结构良好的消息是指符合XML结构规则的XML文档：−第一行是前文规定的XML文档声明−文档应包含至少一个元素（或标签）−每个开始标签对应一个结束标签−不含数据的标签也可使用tag/−标签不得重叠为提高XML文件的可读性，应在每个结束标签后插入回车符，如starttag数值/endtag[CR][LF]。其中CR：回车，LF：换行符。此外，XML区分大小写，故所有字段和属性名称必须小写，确保符合XMLDTD。2.有效的XML文件是指含DTD引用且符合DTD规则的XML文件。DTD是用于定义特殊类型的XML文档中可能出现的有效元素（标签）和属性的文件。DTD还定义文档的元素嵌套规则。有效的XML文件亦应结构良好。文本中出现XML特殊字符“”、“”和“&”（不包括引号）时，应始终分别用“>”、“<”和“&”替换。关于XML的各个方面，应遵循W3C标准，见五、在CDE系统中正确上传ICH安全性消息的要求本章内容主要是能够与CDE顺利交换安全性消息应遵循的规则。关于这些规则，详见附录A。为了向CDE系统成功上传安全性消息，应符合安全性消息标准（ICHDTD），并应遵守附录A中规定的业务规则。8六、通用ICH安全性消息流本章主要介绍药物安全性监测相关方与CDE交换安全性消息。为确保将安全性消息发送至CDE，需正确规定数据元素的messagesenderidentifier（消息发送者标识符，ICHM2M.1.5）和数据元素的messagereceiveridentifier（消息接收者标识符，ICHM2M.1.6）。数据元素messagesenderidentifier（ICHM2M.1.5）应是发送者的组织标识符（即组织ID），应在安全性消息所附的每个ICSR中报告。数据元素messagesenderidentifier（ICHM2M.1.5）应与CDE的组织标识符清单对应，即只有在CDE注册后方可与CDE交换安全性消息。与CDE交换安全性消息的程序：1.使用ESTRI网关：中国本地已建立的药物警戒体系之间全自动化交换安全性消息和确认消息的工具。2.使用CDE门户网站（）：CDE网站→申请人之窗→药物警戒提交栏目。CDE向有关的注册者提供的半自动网络工具，通过CDE网络应用程序交换安全性消息和确认消息。CDE社区内的通信情境如下：呈报CDE：MAH、申请人和申办者向CDE发送安全性消息。CDE向MAH、申请人和申办者发送确认消息。(一)呈报CDE（图1）：9图1所示为安全性消息交换示例，包括MAH、申请人和申办者向CDE呈报的一个或多个ICSR。1.MAH、申请人和申办者将安全性消息中的ICSR发送给CDE；2.如安全性消息中指定的接收者标识符为CDETEST和CDEE2B，则安全性消息将分别传送到CDE测试环境或CDE正式环境；3.CDE发送确认消息（ACK），确认收到安全性消息和ICSR。图1.CDE系统中的安全性消息交换ICSRACK申请人、MAH、申办者CDE10七、CDE系统中的ICH安全性消息流本章介绍CDE系统中的安全性消息流，并概述生成和未生成确认消息时的情况（图2）。如未生成确认消息，则可能安全性消息的结构不正确和/或无效（参阅第四章了解生成有效的安全性消息）。CDE对传入的任何安全性消息执行验证，包括两步：(一)入站解析验证CDE对于传入的任何安全性消息执行基本验证，即验证指定DTD。发送者负责按照第四章的规定使用正确的安全性消息XML消息头。如果发送者未使用第四章所述的正确DTD参考消息头，则接收者无法保证返回确认消息。如CDE检测解析错误，则可能会出现下述情况：如在安全性消息解析过程中，CDE可检测到有效的发送者标识符，则将创建确认消息并将其发送给发送者，列出所检测到的错误。数据元素报告的transmissionacknowledgem