药物警戒不良事件处理

1客户嘴上要的

「药物警戒部门的不良事件报告越来越多。用 AI 自动处理：自动编码、自动写叙述、自动上报，节省人力。」

这是症状或现成方案，不一定是真问题。下面看两种做法。

2照字面做，会怎么烂

3好 FDE 的实际走法

共 10 周，分 5 个阶段。带三角标记的是这一步最容易踩的坑。

1. 1–2

   第 1–2 周看不良事件从哪里来

   • 跟药物警戒部 4 个 PV 专员各坐半天，再去客服中心和医学信息部门各看一天。不良事件的来源有：客服热线、医药代表、患者、医疗专业人员、文献检索、市场调研项目。
   • 发现最大的风险在入口：客服记录里有「吃了以后起疹子」「用药后住院了」这类描述，却被记成「产品咨询」或「投诉」，从没转到 PV 部门。而法规规定的报告时限，从公司首次获知时就开始计算。
   • 真问题是「多渠道识别不良事件 + 尽早立案」。成功标准改成：在客服记录测试集上，不良事件识别召回率 ≥ 98%；从首次获知到 PV 立案的时间 5 天 → 1 天；MedDRA 编码建议的前三项命中率 ≥ 90%。
2. 3

   第 3 周定范围 + 先见 QA

   • 砍范围：第一期只做两件事——从客服记录中识别疑似不良事件并转给 PV；对已立案病例给出编码建议和最低信息要素（可识别的患者、报告者、可疑药品、不良事件）的完整性检查。不做自动提交。
   • 约QA 负责人确定验证方案：用户需求说明、风险评估、测试脚本、验证报告。这是 GVP 体系下的要求，也是本案例周期比 6 周长的原因。
   • 踩坑不要等系统做完再找 QA。验证文档要和开发同步写，事后补写会返工。
3. 4–7

   第 4–7 周原型 + evals + 验证测试

   • 识别：每天扫描客服记录，标出疑似不良事件，附原文和理由，推送给 PV 专员确认。宁可多推，不能漏推。
   • 编码建议：对报告中的事件描述给出 MedDRA 低位语前三项建议，PV 专员选择或修改。
   • evals：取一年的客服记录，由 2 名 PV 专员标注 1000 条作为标准答案（含 150 条不良事件）。识别召回率 ≥ 98%；编码建议用 300 个历史病例测试。按验证方案执行测试脚本，记录每一项结果。
   • 踩坑召回率要按严重程度分开看。严重不良事件一条都不能漏，这一组单独设测试集。
4. 8–9

   第 8–9 周Demo + 试运行

   • 让 PV 专员本人和客服主管一起用两周。记录推送条数、PV 确认率、首次获知到立案的天数，和试运行前两周对比。客服主管看到被识别出的记录，才会推动客服人员改进记录方式。
5. 10

   第 10 周交接交接

   • 交接给药物警戒部一位PV 运营主管：负责识别规则、编码建议的复核和每月召回率抽查；QA 负责变更控制。运行手册写清：任何模型或提示词的改动都走变更控制，先回测测试集，再上线。

4这个案例教给你的可复用判断