夜雨聆风自上而下的推演：不要一上来就扎进代码里！要从系统的预期用途和架构出发，假设潜在的危险情况（Hazardous Situations）。 工具推荐：使用**故障树分析（FTA）**等方法，像剥洋葱一样，推导导致伤害的具体路径，看看软件在其中扮演了什么角色。
软件失效模式与影响分析 (SFMEA)：将它应用到你的软件架构元素上。 怎么做：列出各个软件项（Software Items）的需求，逐一分析：如果它没能满足需求（失效模式），会对预期功能产生什么影响？最终对系统边界和患者安全会造成什么后果（End Effect）？
💡 划重点：新软件的“100% 法则”
根据 IEC 62304 标准，目前业界并没有公认的方法来准确估计“新软件”的失效概率。因此，最稳妥、最保守的做法是：直接将新软件失效的概率设定为 100%！ > 此时，你的工作重心应该放在识别危险和增加风险控制措施上，而不是在一堆代码里死磕概率计算。
旧版软件 (Legacy Software)：如果你的软件已经有高质量的上市后数据（比如多年客诉记录、维修数据），你可以基于这些“真金白银”的历史使用情况，来定量估计它的失效概率。
🟢 A 类：人畜无害型。软件系统不会引发危险情况；或者即便引发了，在外部风险控制措施的保护下，风险也是可以接受的。 🟡 B 类：轻伤型。可能引发危险并导致不可接受的风险，但最多也就是非严重伤害 (Non-serious injury)。 🔴 C 类：高危型。可能引发危险并导致不可接受的风险，且可能导致死亡或严重伤害 (Death or serious injury)。
通过设计和制造实现内在安全：比如物理隔离，用硬件来限制软件的权限（例如给电机加上物理扭矩限制，软件再怎么抽风也转不快）。 保护措施：在代码层面加锁。比如输入算法的有效性检查、强制密码验证、看门狗定时器等。 安全信息和用户培训：最后一道防线。比如弹窗警告信息、蜂鸣器警报、或者强制要求医生在模拟器上完成培训。
确保需求正确：多用建模、仿真，多拉着同行做 Review（代码评审）。 定义架构并分类：清晰划分软件架构，并严格按照 IEC 62304 对所有模块进行安全分类。 确保正确实现：严格遵循结构化走查和测试流程。 努力“降级”：想尽一切办法，用软件外部的硬件或系统级控制措施，来降低软件模块的安全等级（把 C 降成 B，把 B 降成 A）。 减少危险暴露：增加冗余机制，降低用户接触到危险的可能性。
