4. 药物警戒数据平台架构设计

药物警戒数据平台要同时承载个例安全性报告（ICSR）、E2B(R3) 报文、随访记录、文献、社交媒体信号、批签发与暴露数据等多源异构数据，还要满足监管对数据完整性、可追溯性和时限的要求。因此架构设计不是“选一套技术栈”，而是围绕数据流、合规边界与运行弹性做的一组取舍。本节从分层架构、微服务与模块化、数据湖与数据仓库选型、高可用与可扩展性、架构评审五个方面展开，并给出可落地的判断依据。

一、分层架构：把合规边界画进分层里

推荐采用“接入层—处理层—存储层—服务层—应用层”五层结构，但关键不是层数，而是每层的职责与数据形态。接入层负责协议适配与原始留存：E2B(R3) XML 通过 AS2/HTTPS 网关进入，先落原始报文并计算 SHA-256 校验值，保证“原文不可变”；处理层做解析、术语映射（MedDRA、WHODrug）、去重与编码，输出结构化事件；存储层区分原始区、明细区、汇总区；服务层以 API 暴露病例查询、信号计算、编码校验等能力；应用层面向录入员、医学评估员、信号管理团队和监管报送。

一个常见误区是把“原始报文”和“解析后字段”混在同一张表。正确做法是原始区只追加不修改，明细区允许按版本重算。例如同一病例收到 3 次随访，原始区保留 3 份报文，明细区以 case_id + version 形成 3 条版本记录，汇总区只保留最新有效版本，并保留版本指针。这样既满足审计追踪，又避免查询时反复解析 XML。

二、微服务与模块化：按业务能力切，不按技术切

微服务划分应围绕药物警戒的业务能力，而不是按“解析服务、数据库服务”这类技术职责切。推荐边界：病例管理（ICSR 生命周期）、术语与编码、信号检测、报送与网关、审计与权限、通知与任务。每个服务拥有独立数据存储，通过事件总线（如 Kafka）异步通信。例如病例管理服务在病例状态从“待评估”变为“已评估”时发布 case.evaluated 事件，信号检测服务订阅后触发 PRR/ROR 重算，报送网关订阅后判断是否达到 15 日或 7 日时限。

模块化还体现在“共享内核”的克制：MedDRA 版本、机构编码、时限规则属于共享配置，应通过配置中心下发，而不是复制到每个服务。服务间同步调用只用于强一致场景（如编码校验），其余走事件，避免级联故障。

三、数据湖与数据仓库选型：不是二选一，而是分工

药物警戒场景中，数据湖适合存放原始报文、非结构化文献、社媒文本和日志，保留全量历史；数据仓库适合存放已建模的病例明细、版本、信号指标和监管报表。选型判断可参考：需要保留原文与审计追踪的，入湖；需要高频关联查询、聚合和报表的，入仓。典型组合是“湖仓一体”：原始区用对象存储 + 开放表格式（如 Iceberg），明细区用列式仓库（如 ClickHouse、Doris 或云数仓），通过统一元数据打通。

四、高可用与可扩展性设计

高可用要落到具体指标：核心 API 可用性目标 99.9%，RPO≤5 分钟，RTO≤30 分钟。做法包括：接入层双网关 + 健康检查；Kafka 分区数按病例 ID 哈希，保证同一病例事件有序；存储层原始区跨可用区冗余，明细区主从 + 定期快照；服务层无状态化，会话与任务状态外置到 Redis 或数据库。

可扩展性重点在“热点可控”。病例查询按 case_id 分片，信号计算按产品 + 事件对分片。压测时可用如下示例参数评估：单节点 8 核 16GB，Kafka 6 分区，目标吞吐 200 条/秒，P95 写入延迟 < 800ms。若 P95 超过 1.5s，优先检查分区倾斜与术语映射缓存命中率，而不是直接加机器。

五、架构评审实战：用检查表把风险前置

架构评审不是听汇报，而是逐条验证关键假设。建议围绕数据完整性、时限、可追溯、弹性、安全五个维度准备检查项，并要求给出证据而非结论。例如“原始报文不可变”需提供对象存储版本控制或 WORM 配置截图；“15 日时限”需提供从接收时间到报送时间的端到端链路与监控告警；“病例版本可追溯”需演示按 case_id 查询全部版本及差异。

评审输出应包含：风险项、影响范围、整改责任人与验证方式。例如发现“信号计算服务直接读原始区 XML”，风险是解析耗时且口径不一致，整改为统一读明细区，验证方式为对比同一批病例在改造前后的信号结果一致性。通过这种“假设—证据—整改—验证”的闭环，架构评审才能真正降低上线后的返工成本。