第1章：风险管理基础：ISO 14971在智能药盒开发中的应用
各位工程师朋友，咱们今天聊聊风险管理。说实话，很多人一听到「ISO 14971」就觉得头大，觉得是质量部门的事。但我个人经验告诉我——风险分析做不好，后面全是坑。
智能药盒这东西，说白了就是个人命关天的设备。你想想看，如果该提醒吃药的时候没提醒，或者多提醒了一次，患者吃错药了，后果谁来担？嗯，这就是风险管理要解决的问题。
1.1 为什么智能药盒必须做风险管理？
我见过不少初创团队，上来就画电路板、写代码，觉得功能跑通了就万事大吉。结果呢？送检的时候被审评老师一个问题问住了——「你们怎么证明这个药盒是安全的？」
ISO 14971就是回答这个问题的标准答案。它要求你系统性地识别危害、评估风险、控制风险。这不是走形式，而是实实在在保护患者，也保护你自己。
核心原则：风险可接受 ≠ 零风险。我们要做的是把风险降到合理可行的低水平（ALARP原则）。
1.2 危害识别：先搞清楚「哪里会出事」
我个人习惯把危害分成三类：
- 电气危害：比如电池短路、充电过热、漏电
- 机械危害：比如药盒夹手、出药机构卡住
- 软件/信息危害：比如时间不准、提醒错误、数据泄露
我在项目中遇到过最典型的案例：某款药盒的Wi-Fi模块在弱信号下反复重连，导致系统时钟偏移了15分钟。患者按错误时间吃了药，血糖直接飙了。你看，这就是软件危害的典型例子。
避坑指南：我曾经以为只有硬件才有危害，后来发现软件出问题的概率其实更高。尤其是实时时钟（RTC）的同步逻辑，一定要做边界测试。
1.3 风险估计：给危害「打分」
识别出危害之后，我们要给每个危害打个分。ISO 14971用的是严重度 × 发生概率的矩阵法。
| 严重度等级 | 描述 | 示例 |
|---|---|---|
| S1（可忽略） | 轻微不适，无需处理 | 药盒提示音略刺耳 |
| S2（轻度） | 需要干预，但无长期影响 | 漏服一次非关键药物 |
| S3（严重） | 可能导致住院或永久损伤 | 胰岛素剂量错误 |
| S4（灾难性） | 直接导致死亡 | 心脏药物过量 |
发生概率一般分5级：从「几乎不可能」到「频繁发生」。我建议你们做概率估计时，别太乐观。我见过太多团队把「偶尔发生」写成「几乎不可能」，结果上市后被打脸。
1.4 风险控制：怎么把风险降下来？
风险控制有三个层次，优先级从高到低：
- 设计上消除：比如用机械锁防止误开，而不是靠软件提示
- 保护措施：比如加装温度传感器，过热时自动断电
- 信息提示：比如在说明书里写「请勿在充电时使用」
嗯，这里要注意：千万别把希望全压在说明书上。你想想看，患者可能根本不看说明书。我有个血的教训——某款药盒的电池仓设计成可拆卸，结果用户把电池装反了，直接烧了主控。后来我们改成防反接电路，问题才解决。
重要提醒：风险控制措施必须经过验证。不是「我觉得这样就行了」，而是要有测试数据支撑。比如你加了个过流保护，就得实测短路电流和响应时间。
1.5 剩余风险与风险-受益分析
控制措施做完之后，肯定还有剩余风险。这时候要做个判断：这个剩余风险，患者能不能接受？
举个例子：智能药盒的Wi-Fi偶尔断连，导致提醒延迟5分钟。这个风险严重度是S2（轻度），发生概率是P2（偶尔）。查一下风险矩阵，落在「可接受」区域。但如果是胰岛素泵的通信延迟，那就不行了。
我个人习惯把剩余风险列个表，逐条写清楚：
- 风险是什么
- 控制措施是什么
- 剩余风险等级
- 为什么可接受
这个表在注册申报时特别有用。审评老师一看，就知道你认真分析过了。
1.6 风险管理文档：别偷懒
最后说一句：文档一定要写。ISO 14971要求你从项目开始就建立风险管理文档，并且持续更新。我见过最惨的案例——产品都量产了，才发现某个危害没识别到，结果召回。
文档至少包含：
- 风险管理计划
- 危害识别清单
- 风险估计与评价表
- 风险控制措施及验证记录
- 剩余风险可接受性判断
- 风险管理报告
嗯，我知道写文档很烦。但你想，万一出了事，这些文档就是你的救命稻草。它能证明你尽到了合理注意义务。
我的习惯：每次改版都同步更新风险管理文档。哪怕只是改了个电阻值，也要重新评估一下会不会影响安全。别等到送检前才补，那时候漏洞百出。
小结
这一章我们讲了ISO 14971在智能药盒中的完整流程：从危害识别，到风险估计，再到风险控制和文档管理。说白了，就是提前想好「哪里会出事」，然后把它堵死。
下一章我会讲软件生命周期管理，也就是IEC 62304在智能药盒中的应用。到时候咱们聊聊怎么写代码才能过审。嗯，敬请期待。