2026 年的 FDA E2B(R3)：先于 EDC 重建的分流决策

核心要点

2026 年十月 1 日是通过 FDA 下一代电子提交网关提交上市后个例安全性报告的过渡日期。商业 IND 电子报告要求生效更早，为 2026 年四月 1 日。这两个日期均不意味着每一份安全性文件都属于 E2B 消息、每个报告机构都必须使用网关，也不意味着每张临床试验电子病例报告表都需要新增字段。FDA 继续将安全报告门户描述为不具备 E2B 能力机构的一个可选途径，但对现有网关 ICSR 提交方施加了一项重要限制。[1]

因此，申办方或 CRO 当下面临的决策并非“我们是否已升级了 EDC？”，而是“来自何种法定报告背景的哪份报告正在通过哪条许可渠道提交？”只有在完成该分类之后，团队才能确定哪些源数据、安全性数据库映射、接口以及操作控制措施实际上需要变更。本文将 FDA 公布的适用范围转化为分流与变更控制框架；该框架属于我们的操作性解读，而非 FDA 强制要求的新增系统架构。

两个日期，两类报告群体

FDA 当前的不良事件监测系统（AEMS）电子提交页面将上市后报告与上市前 IND 报告区分开来。对于通过 ESG NextGen 发送的上市后人用药品、生物制品以及以药物或生物制品为主导的组合产品 ICSR，FDA 允许在 2026 年九月 30 日之前使用 E2B(R2)，并要求自十月 1 日起使用 E2B(R3)。已经开始发送 E2B(R3) 报告的公司应当继续使用该标准，而非在不同版本之间来回切换。对于现有的 SRP 提交方，该页面指出本次过渡无需采取任何操作。[1]

对于上市前报告，FDA 于 2024 年四月 1 日开始接收 E2B(R3) 提交。2024 年四月的最终指南使其电子提交要求自 2026 年四月 1 日起生效。其范围比“所有 IND 安全性信息”更窄：它涵盖根据 21 CFR 312.32(c)(1)(i) 提交的严重且非预期疑似不良反应报告，以及根据 312.32(c)(2) 提交的相关七天报告。它还明确豁免了非商业 IND 提交的法定电子格式要求，同时鼓励采用所描述的格式。[2]

当供应商将其系统描述为“E2B(R3) 就绪”时，请同时核实上市后传输能力以及申办方特有的商业 IND 报告群体。对于 SRP 路径，在决定是否需要更换之前，应根据实际数据流评估 EDC 接口。报告群体与提交渠道必须结合在一起进行评估。

该表结合了 FDA 当前的提交页面与最终指南的适用范围及豁免条款。它是一项分类辅助工具，不能替代基础的报告评估。[1] [2]

在选择格式前先确定可报告性

E2B(R3) 描述了个例安全性信息的传输。某项信息是否符合 IND 安全性报告的条件，始终属于法律与医学层面的评估。根据 21 CFR 312.32，不良事件与疑似不良反应不可互换：后者需要有提示因果关系的证据。严重性与非预期性也是具有明确定义的法定概念，而非仅仅根据 EDC 字段是否填写就能推断的标签。[3]

该电子提交最终指南明确排除了根据 312.32(c)(1)(ii) 提交的其他研究发现报告、根据 (iii) 提交的动物或体外试验发现报告，以及根据 (iv) 提交的严重疑似不良反应发生率增加报告。其脚注指引申办方参考 eCTD 指南及技术符合性指南，以获取这些类别的电子格式要求。它还排除了由 CBER 作为生物制品监管的特定类别医疗器械。[2]

这里存在一个细微但至关重要的区别。来自汇总分析的证据可以支持根据 (c)(1)(i)(C) 提交的严重且非预期疑似不良反应报告；该指南在其适用范围内探讨了此种情况。而根据 (c)(1)(iv) 提交的发生率增加报告类别则仍被单独排除在外。若制定一条将“所有汇总发现”统一分流至某一路径的规则，将会丧失这一监管层面的区分。在技术团队选择其传输目标之前，安全性与注册法规团队需要先对报告进行分类。[2] [3]

对于变更控制记录，我们建议在记录渠道决策的同时保留报告依据。一份实用的记录应阐明评估了哪项法规条款或报告类别、谁批准了该分类，以及由哪项适用技术规范来管控传输。当同一项临床观察在 EDC、安全性病例、定期报告与监管提交之间流转时，该记录应当展示每个现有报告类别背后的推导依据。

这种区别同样会改变测试方式。一条在技术层面有效的消息仍可能代表了错误的报告群体。因此，一套完整的测试用例应包含一个属于 E2B 工作流的病例，以及一个必须分流至其他途径的示例。应将分类规则与 XML 验证分开测试，包括需要不同报告路径的各种场景。

SRP 是一条切实可行的路径，具有明确的准入边界

FDA 阐述了电子 ICSR 的两种途径：通过 ESG NextGen 进行数据库到数据库的传输，以及通过安全报告门户进行人工录入。不具备 E2B 能力公司的申请人及责任人可使用 SRP 提交上市前与上市后 ICSR 及其附件。然而，网关合作伙伴——在该页面中定义为通过 ESG NextGen 电子提交 ICSR 的公司——不得将 SRP 用于此类提交。[1]

该定义取决于是否通过网关提交 ICSR，而非是否拥有任何类型的 ESG 账户。亦不可将 SRP 描述为生产环境网关传输失败时的自动备选退路。现有的网关合作伙伴不能假定该门户限制在系统停机期间会自行消失。

FDA 公布的 SRP 账户申请流程要求联系 AEMS 电子提交协调员，并说明账户激活大约需要七至十个工作日。这是账户开通所需时间的预估，并非报告截止期限的顺延，也不是有保证的服务等级承诺。计划使用 SRP 的机构需要在报告到期之前解决访问权限问题。[1]

考虑两种假设的操作模式。申办方 A 使用一家安全性服务提供商，由后者通过 ESG NextGen 传输其 ICSR。其差距评估必须明确实际的提交方安排、生产环境传输流程，以及符合网关限制的应急备选方案。申办方 B 缺乏 E2B 能力，采用经过授权的 SRP 流程。所引用的页面允许申办方 B 在没有 E2B(R3) 的情况下采用 SRP 路径，因此开发 XML 生成器项目需要单独的立项依据。申办方 B 仍需确保病例数据准确、用户经过授权、提交及时，并提供证明报告工作流按预期运行的证据。

这些假设的示例区分了系统需求说明书所必须明确的角色与接口。请分别定义“E2B 能力”、“网关合作伙伴”、“申办方”以及“EDC 客户”。

核对定期报告的各个独立组成部分

同样的分流原则也适用于上市后定期安全性报告。FDA 说明，PSR 由描述性部分以及在报告间隔期内收到的非快速报告 ICSR 组成。描述性部分遵循 eCTD 规范，并应说明 ICSR 已通过 ESG NextGen 或 SRP 完成电子化提交。非快速报告 ICSR 则走独立的 ICSR 提交路径，其提交截止日期不晚于 PSR 截止日期，且如果已经提交则不应重复提交。[1]

因此，数据核对必须确定每个必需组成部分的状态，而不能仅依赖单个“PSR已提交”复选框。团队需要明确该状态具体指代资料包的哪一部分。我们建议的控制措施是包含三项明确事实的资料包级核对：描述性递交的状态、属于该报告区间的 ICSR 集合以及每个个例的递交历史。其目标是在识别遗漏个例的同时，避免对已发送个例造成重复传输。

例如，定期报告编制流程可能会从安全数据库中汇总一份个例清单。如果其导出逻辑将该清单上的每个个例都视为新的递交，就会与 FDA 关于不得重新发送既往已递交 ICSR 的要求发生冲突。相反，若将 eCTD 描述性递交直接作为相关个例已传输的证据，则可能会掩盖遗漏。这些是基于分立递交结构推导出的假设性失效模式，而非实测错误率，亦非声称 FDA 要求使用某种特定的核对产品。

因此，向技术或服务提供商提出的问题是具体的：该工作流程能否区分报告资料包、单个个例以及该个例的某次特定递交？系统演示应当在包含既往已递交个例的代表性场景中展示这种区分能力。除了关于 eCTD 和 E2B 支持的销售陈述外，还应获取此类操作层面的证据。

EDC 中会发生哪些变化——以及哪些可能不会改变

FDA 现已针对 C.5.4“观察到反应/事件的研究类型”接受更多取值：4 代表患者支持项目，5 代表市场调研项目，6 代表源数据来自数字化平台的有组织数据收集系统。该机构说明这些变更是为了与其上市后安全数据指导原则 ICH E2D(R1) 保持一致。[1]

在为干预性临床试验 CRF 提议新增字段之前，应根据实际的来源类别和映射关系对这些取值进行评估。首先确定申办方是否处理相关的个例来源、由哪个系统负责对其进行分类，以及该分类如何传递至安全性递交环节。在一种实施方案中，它可能是个例管理元数据。在另一种实施方案中，可能需要对来自上游收集流程的信息进行映射。这些可能性都需要进行评估；两者都不能证明 EDC 未受影响。

有效的分界线存在于临床源信息与递交元数据之间。试验观察应当遵循试验方案以及经批准的数据收集要求。安全性工作流程可以将这些观察结果与医学评估、产品信息、个例标识符及来自其他来源的特定递交数据相结合。传输标准的变更应当促使对整个链条开展可追溯性审查，而不是盲目扩大试验中心的数据录入。

这是一个实施审查矩阵，而非声称 FDA 强制规定了这五个软件模块。单个平台可以执行多项功能；多家供应商也可以分担这些功能。关键在于权责归属必须明确，且交接环节必须可测试，而不能假定某一个产品的验证就能确立整条链路的正确性。

不仅询问“文件是否已发送？”的发布测试

对于正在准备与 E2B(R3) 相关的系统发布的申办方而言，价值最高的测试用例是那些对上述边界提出挑战的用例。我们建议至少测试一份范围内的报告、一份超出 ICSR 指导原则适用范围的安全性递交、一个附带有新信息的首发个例，以及一个包含已递交个例的定期报告场景。仅在申办方的报告人群使其具备相关性时，才添加来源类型场景。

对于每个场景，证据链均应将源信息与评估、转换后的记录、选定路径以及最终的递交状态关联起来。将传输、医学评估和个例内容作为工作流程的独立部分分别进行验证。通过记录在案的原因分析和变更控制流程来解决接口差异，同时保持临床源数据的完整性。该差异需要明确负责人，由其确定问题出在采集、映射、评估还是传输环节。

应从适用的生产规范中获取回执标签与成功代码释义。FDA 现行的区域实施指南、业务规则和适用的技术符合性文档是开展该项技术工作的恰当规范；FDA 在其递交页面中提供了这些文档的链接。供应商的实施验证需要依据这些规范和实际的测试证据，这超出了本文的讨论范围。[1]

研究团队在评估 EClinCloud 的 EDC, 相关的讨论在于研究构建和数据管理工作流程如何支持经批准的源数据要求与交接。应将药物警戒递交系统和合规职责与 EDC 平台的选择分开评估。有益的 实施讨论 始于报告人群、现有安全性工作流程以及待评估的确切接口边界。

2026 年十月的决策

2026 年的这两个日期确立了不同的电子报告里程碑。必要的迁移工作取决于每份安全性文件的报告类别以及每个试验数据库的实际角色。合理可行的项目范围应当从报告类别和获准递交渠道着手，保持临床采集与安全性递交之间的区分，并对确实可能改变报告含义或交付的交接环节进行测试。

对于正在决定是否需要重构 CRF 的团队而言，其说明责任应当是具体的：明确所需信息，指出该信息在哪里缺失或不适用，并解释为何必须变更经批准的临床收集流程。对于声称无需进行任何变更的团队，其举证责任同样具体：必须证明当前的分类、映射和递交工作流程覆盖了适用的报告人群。仅凭“R3”这几个字母，都无法得出上述任何一种结论。

参考来源

1. FDA. FDA 不良事件监测系统 (AEMS) 电子递交. “时间表”、“递交个例安全报告 (ICSR)、定期安全性报告 (PSR)”以及“与 ICH E2D(R1) 指导原则保持一致”章节。访问于 2026 年十月 11 日。

2. FDA. 以电子格式提供监管递交资料：IND 安全性报告. 最终指导原则，2024 年四月，第 III–IV 节，印刷页码第 3–6 页。适用范围、排除情形、非商业性 IND 豁免、实施日期及递交途径。电子格式要求是依据第 745A(a) 条发布的，而非仅仅是一项可选的建议。

3. 美国联邦电子法规库。21 CFR 312.32—IND 安全性报告. 第 (a) 款与第 (c) 款，访问于 2026 年十月 11 日；所显示的当前文本截至 2026 年十月 7 日为最新。报告定义与各不同报告类别。