2. 药物警戒数据来源与采集工程
药物警戒数据平台的第一道工程难题不是算法,而是“数据从哪里来、以什么形态进来、进来后如何变成可分析的结构”。药物警戒的数据源天然异构:自发报告是结构化字段加自由文本,文献是半结构化的段落与表格,真实世界数据(RWD)是纵向随访的表结构,社交媒体则是完全非结构化的短文本流。本节围绕这四类来源,讲清来源特征、采集接口设计、ETL/ELT 流程以及数据接入规范,并给出一个可执行的实战任务。
一、四类数据源的工程特征
自发报告(如国家药品不良反应监测系统、企业上市后收集的 ICSR)以个案安全报告为核心,字段遵循 ICH E2B(R3) 结构,包含患者信息、可疑药品、不良反应事件、严重性判定、报告来源等。它的特点是字段规范但缺失率高,且“严重性”“因果关系”等关键判断依赖人工编码,采集时通常以 XML 或 API 批量拉取为主。
文献数据来自 PubMed、Embase、CNKI 等数据库,核心是“检索—筛选—提取”三步。工程上需要保存检索式、检索时间、命中数量、去重结果和最终纳入的个案,形成可追溯的文献监测记录。文献中的病例信息往往散落在正文段落和表格里,需要人工或模型抽取为结构化字段。
真实世界数据包括电子病历、医保理赔、登记队列、可穿戴设备等。它字段丰富、时间连续,但存在同一患者多系统标识不一致、事件时间与记录时间错位、编码体系(ICD、MedDRA、ATC)不统一等问题。采集时更强调主数据对齐和时间轴重建。
社交媒体数据来自论坛、微博、患者社区等,文本口语化、含大量否定与假设表达(如“我怀疑是吃了这个药”),噪声高、信号弱。它的价值在于发现早期信号和患者体验,但必须经过严格的去标识化和信号可信度评估,不能直接当作个案报告使用。
二、采集接口设计要点
接口设计要回答三个问题:拉什么、怎么拉、拉不到怎么办。以自发报告 API 为例,典型设计是“按报告日期增量拉取 + 分页 + 幂等写入”。请求参数可包含 report_date_from、report_date_to、page_size、cursor;响应返回报告列表和下一页游标。工程上必须记录每次拉取的“水位线”(watermark),即已成功入库的最大报告日期,下次从该日期之后继续,避免重复和遗漏。
对于数据库类 RWD,优先使用 CDC(变更数据捕获)而非全量快照,减少对源系统的压力。对于社交媒体,采用消息队列缓冲,先落原始文本,再做异步清洗,避免爬虫波动影响主链路。所有接口都应具备重试、限流、超时和失败落盘机制,失败记录进入死信队列,人工或定时任务补偿。
三、ETL 与 ELT 的选择
ETL 是“先转换后加载”,适合字段规范、转换逻辑稳定的场景,如 E2B 报告入库;ELT 是“先加载后转换”,适合数据量大、探索性强的场景,如社交媒体文本和 RWD。实际平台常采用混合模式:结构化报告走 ETL 保证质量,非结构化文本先以原始形态入湖(ELT),再按需加工。
无论哪种模式,处理层都要完成四件事:去重(同一患者同一事件多次上报)、编码映射(把自由文本的药品名映射到 WHODrug,把事件描述映射到 MedDRA PT)、脱敏(去除姓名、身份证、联系方式)、时间轴重建(区分事件发生时间、报告时间、入库时间)。
四、数据接入规范
接入规范是平台与数据源之间的“合同”,至少应约定:数据格式(XML/JSON/CSV)、必填字段与可选字段、编码标准版本、传输方式与频率、失败重传策略、数据保留期限、脱敏要求。以下是一份可直接参考的接入规范示例表。
| 规范项 | 自发报告 | 文献 | 真实世界数据 | 社交媒体 |
|---|---|---|---|---|
| 传输方式 | API 增量拉取 | 数据库导出 + 文件 | CDC / 批量文件 | 流式消息队列 |
| 频率 | 每日 | 每周 | 每日增量 | 准实时 |
| 主键 | 报告编号 | 文献 DOI + 病例序号 | 患者 ID + 事件时间 | 帖子 ID |
| 编码标准 | MedDRA / WHODrug | MedDRA | ICD / ATC | 无,需映射 |
| 脱敏要求 | 去除直接标识 | 去除作者信息 | 假名化 | 去除用户名与位置 |
| 失败处理 | 死信队列 + 重试 | 人工补录 | 断点续传 | 丢弃并告警 |
五、实战任务:搭建一条自发报告接入链路
任务目标:从模拟的自发报告 API 拉取数据,完成清洗、编码映射和入库,并输出质量报告。假设 API 返回 JSON,字段包括 report_id、report_date、patient_age、drug_name、event_desc、serious。
第一步,增量拉取。维护水位线文件 watermark.txt,记录上次最大 report_date。请求时带上该日期,只取之后的记录。第二步,清洗。去除 report_id 重复项,把 patient_age 统一为整数,缺失值标记为 UNKNOWN。第三步,编码映射。用字典把 drug_name 映射到 WHODrug 代码,把 event_desc 映射到 MedDRA PT,映射失败的记录写入 unmapped.csv 待人工处理。第四步,入库。写入 ODS 层原始表,再加工到 DWD 层标准表。第五步,质量校验。检查必填字段缺失率、重复率、映射成功率,输出如下示例报告。
批次号: 20240612-001
拉取记录数: 1280
去重后: 1265
必填字段缺失率: 3.2%
药品映射成功率: 96.8%
事件映射成功率: 91.5%
未映射记录: 108 条 -> unmapped.csv
入库成功: 1265
状态: 通过(映射成功率高于阈值 90%)
这条链路的价值在于:它把“多源异构”变成了“统一可分析”。自发报告保证合规与完整性,文献补充已发表证据,RWD 提供真实使用场景,社交媒体捕捉早期信号。四类数据在采集接口、处理流程和接入规范上各有侧重,但最终都汇入同一套标准化模型,才能支撑后续的信号检测、随访和风险沟通。