1. ICSR工程全景与法规坐标系

个例安全报告（Individual Case Safety Report，ICSR）是药物警戒体系中最基础、也最不可替代的数据单元。它记录的是“某一位可识别的患者，在特定时间窗内，暴露于某一药品后，发生了某个或某些可疑不良反应”这一事实。围绕这一事实，企业需要完成从信息接收、编码、医学评估、质量审核，到按法规时限向不同监管机构递交，并保留完整可追溯证据链的全过程。ICSR工程，就是把这条链路从“人工经验驱动”转变为“规则驱动、系统承载、可度量、可审计”的工程化能力。

理解ICSR工程，首先要建立法规坐标系。ICH E2B(R3) 是数据结构的国际基准，它定义了ICSR的传输消息模型：一个报告由多个section组成，核心包括患者信息（如B.1）、药品信息（如B.4）、不良反应事件（如E.i）、报告者与发送方信息（如C.1、C.3）等。每个字段都有明确的OID、数据类型、必填/可选/条件必填规则，以及可重复性。E2B(R3) 不是“表格模板”，而是一套可被系统解析的XML消息规范，这决定了ICSR工程必须以数据模型为中心，而不是以Word或PDF为中心。

NMPA、FDA、EMA在E2B(R3)基础上，各自叠加了区域实施要求。NMPA通过药品不良反应监测系统接收报告，强调持有人直报、个例报告时限和随访更新；FDA要求通过FAERS相关通道递交，对E2B(R3)的字段映射、编码字典和电子递交网关有明确技术规范；EMA则通过EudraVigilance体系，对ICSR的电子递交、质量校验和重复报告管理提出要求。三者的共同点是：结构必须可解析、时限必须可计算、质量必须可验证、追溯必须可还原。差异点则集中在区域字段、编码字典版本、递交网关、语言要求和随访策略上。

从工程落地边界看，ICSR系统通常需要覆盖以下能力：第一，数据采集与结构化，把来自热线、邮件、文献、临床、监管转发的信息，映射到E2B(R3)字段；第二，医学编码，包括MedDRA对事件和适应症的编码、WHODrug对药品的编码；第三，时限管理，根据报告类型（初始、随访、文献、自发、研究等）和严重性，计算首次接收日、递交截止日、随访到期日；第四，质量校验，包括必填字段、逻辑一致性、编码有效性、重复报告识别；第五，电子递交与回执，生成符合区域规范的XML，通过网关发送并处理ACK；第六，审计追踪，记录谁在何时修改了哪个字段、修改前后值是什么。

下面这张图给出ICSR工程的全景数据流与法规坐标关系。它不替代具体操作，而是帮助读者看清：一份ICSR从源信息到多区域递交，中间经过哪些关键处理节点，以及E2B(R3)、NMPA、FDA、EMA分别在哪一层施加约束。

图中最值得关注的是“法规坐标层”与“处理层”的对应关系。E2B(R3) 决定字段结构和消息格式，NMPA、FDA、EMA 决定区域字段、递交通道和时限规则。工程实现时，不能把法规要求散落在代码或人工SOP里，而应把可配置的规则集中管理，例如：报告类型到时限的映射表、区域字段的必填规则、编码字典版本、网关地址和证书配置。这样当法规更新时，变更影响面可控。

时限是ICSR工程中最容易出错的环节之一。以常见的严重、非预期、自发报告为例，法规通常要求企业在首次接收日起15个日历日内完成向监管机构递交；致死或危及生命的非预期严重报告，部分区域要求7个日历日内递交，甚至24小时内快速报告。工程上需要把“首次接收日”定义为可审计字段，并区分“企业首次知悉日”和“报告者首次知悉日”。系统应自动计算截止日，并在临近截止前触发预警。若发生随访，随访报告通常不重新起算初始时限，但需在获得新信息后按区域要求及时递交。

质量与可追溯性要求同样需要工程化。质量校验至少包括：必填字段是否为空、日期逻辑是否合理（如事件发生日不能晚于报告日）、MedDRA编码是否指向有效PT、药品名称与WHODrug编码是否匹配、报告是否与已有案例重复。可追溯性则要求系统记录每一次字段修改的操作者、时间戳、修改前值和修改后值，并保留原始源文档。对于监管核查，能够还原“这份报告在何时、由谁、基于什么信息、做了哪些修改、最终递交了什么内容”是基本要求。

工程落地的边界也需要明确。ICSR系统可以自动化字段映射、编码建议、时限计算、格式校验和网关递交，但医学判断不能完全自动化。例如，因果关联性评价、严重性判断、预期性判断、随访策略制定，仍需具备资质的药物警戒人员完成。系统的作用是把这些判断结果结构化、可追踪地记录下来，而不是替代判断。另一个边界是数据质量：如果源信息本身缺失关键字段，系统只能标记为“未知”或“待随访”，不能凭空补全。因此，ICSR工程必须与随访流程、医学审核流程和质量管理流程协同设计。