1. 课程导入与法规全景
在医疗器械行业中，软件早已不是硬件的附属品。无论是输液泵的嵌入式控制固件、CT机的图像重建算法，还是独立用于辅助诊断的AI软件，只要其失效可能导致患者、操作者或环境受到伤害，它就必须被纳入风险管理的范围。本课程讨论的核心问题是：如何用工程化、可追溯、可审核的方式，证明医疗器械软件在其整个生命周期内的风险已被识别、评价并控制在可接受水平。
要回答这个问题，首先必须明确三个基础概念：什么是医疗器械软件、它如何分类、以及它遵循怎样的生命周期模型。这三者决定了后续风险管理的深度、文档量和验证强度。
一、医疗器械软件的定义与边界
医疗器械软件（Medical Device Software, MDSW）通常指本身即为医疗器械、或作为医疗器械组成部分、或用于驱动/控制医疗器械的软件。它既包括嵌入在硬件中的固件（如起搏器的控制程序），也包括运行在通用计算平台上的独立软件（如肺结节检测软件）。判断一个软件是否属于医疗器械软件，关键看其预期用途：如果软件的输出被用于疾病的诊断、预防、监护、治疗或缓解，它通常就落入监管范围。
需要特别区分的是“医疗器械软件”与“用于医疗环境的通用软件”。例如医院用于排班的系统、用于科研统计的脚本，通常不属于医疗器械软件；而一旦同一段算法被用于给出临床决策建议，其属性就可能改变。这个边界判断直接决定了后续是否需要执行ISO 14971和IEC 62304。
二、软件分类：安全等级决定工程强度
IEC 62304将医疗器械软件按“软件失效可能造成的伤害严重程度”分为A、B、C三个安全等级：
- A级：软件失效不会导致伤害，或只会导致不严重的伤害。例如仅用于显示非关键信息的软件。
- B级：软件失效可能导致不严重的伤害。例如某些监护参数的显示与报警。
- C级：软件失效可能导致死亡或严重伤害。例如放疗剂量控制、输液泵输注速率控制。
分类不是形式主义。A级软件可以只做基本的需求与验证；B级需要更完整的架构设计与集成测试；C级则要求最严格的详细设计、单元验证、追溯矩阵和缺陷管理。分类一旦确定，就应在软件安全分级文档中记录理由，并在需求变更时重新评估。
三、生命周期模型：风险贯穿始终
IEC 62304要求软件生存周期过程覆盖开发、维护和风险管理。典型模型包括瀑布、V模型、迭代增量以及敏捷。无论采用哪种模型，监管关注的核心不是“你用了什么模型”，而是每个阶段是否有明确的输入、输出、验证活动和可追溯性。V模型之所以在医疗器械软件中常见，是因为它天然地把需求、设计、实现与对应的验证活动一一对应，便于形成追溯链。
在V模型中，左侧是需求分解与设计，右侧是单元测试、集成测试、系统测试和确认。风险管理活动不是独立的一层，而是贯穿左右两侧：左侧识别危险、估计风险、制定控制措施；右侧验证控制措施是否有效、是否引入新的危险。
四、法规全景：四套要求如何协同
医疗器械软件风险管理不是单一标准能覆盖的，而是由多套法规与标准共同约束。理解它们的分工，是后续所有工程活动的前提。
| 法规/标准 | 核心作用 | 对风险管理的强制要求 |
|---|---|---|
| ISO 14971 | 风险管理通用过程标准 | 要求建立风险管理计划、危险识别、风险估计、风险评价、风险控制、综合剩余风险评价及生产和生产后信息反馈 |
| IEC 62304 | 医疗器械软件生存周期过程 | 要求软件安全分级、开发策划、需求分析、架构设计、详细设计、单元实现与验证、集成与系统测试、发布与维护 |
| FDA | 美国市场准入与审评 | 通过510(k)、PMA、De Novo等路径要求提交软件描述、风险分析、验证与确认证据；对AI/ML软件还有预定变更控制计划等特殊要求 |
| NMPA | 中国医疗器械注册与监管 | 依据《医疗器械软件注册审查指导原则》等文件，要求提交软件研究资料、风险管理资料、网络安全描述及验证报告 |
这四者不是并列关系，而是层次关系：ISO 14971给出“风险管理应该做什么”的通用框架；IEC 62304给出“软件生命周期中如何落地”的过程要求；FDA和NMPA则把这些要求转化为具体的注册申报资料和审评要点。企业在实际执行时，通常以ISO 14971为顶层框架，以IEC 62304为软件工程主线，再按目标市场的法规要求组织证据。
五、从法规要求到工程动作
以一款C级输液泵控制软件为例。按照IEC 62304，它需要完整的软件需求规格说明、架构设计、详细设计、单元验证记录和集成测试报告。按照ISO 14971，团队需要识别“输注速率计算错误”这一危险，估计其发生概率和严重度，评价风险是否可接受，并制定控制措施——例如增加独立的速度校验模块、设置硬限位、增加报警。控制措施实施后，还要验证其有效性，并评价是否引入了新的危险，比如报警过于频繁导致操作者忽略。
按照NMPA要求，这些活动需要形成软件研究资料和风险管理报告；按照FDA要求，若该软件通过510(k)申报，还需提供软件描述文档和相应的验证证据。可以看到，同一套工程活动，需要同时满足多个法规的输出要求，这也是为什么风险管理必须从项目一开始就规划，而不是在注册前补材料。
六、本课程的学习路径
后续章节将沿着“标准要求 → 工程方法 → 实操工具 → 案例复盘”的路径展开。你会看到如何编写风险管理计划、如何做危险识别与风险估计、如何设计风险控制措施并验证其有效性、如何建立追溯矩阵、如何应对FDA和NMPA的审评提问，以及如何在敏捷开发中保持合规。每一章都会尽量给出可参考的模板、参数示例和判断依据，帮助你把标准条款转化为可执行的工程动作。
在进入具体方法之前，请先记住一个基本判断：任何软件风险管理的起点，都是明确软件的预期用途和安全等级。预期用途决定了危险的分析边界，安全等级决定了工程活动的深度。这两件事没有做清楚，后续的需求、设计、测试和注册资料都会失去根基。