1. 医疗器械软件设计审查总览
医疗器械软件设计审查，不是一次性的文档评审，也不是在软件发布前补做的一道“合规检查”。它是一条贯穿需求、设计、实现、验证与上市后维护的技术控制链，目的是在软件全生命周期中持续回答三个问题：软件要解决什么临床问题、它的设计是否足以安全有效地解决该问题、我们凭什么相信这一点。本章先建立全局视角，明确审查对象、法规边界与工程框架，为后续各章的具体方法打下坐标。
一、审查对象：从“软件”到“软件项”
医疗器械软件的范围比一般商业软件更宽。它既包括独立软件（SaMD，如影像辅助诊断App），也包括嵌入在硬件中的软件（如输液泵控制固件、CT重建模块），还包括作为医疗器械附件的软件（如配置与数据分析工具）。设计审查的对象不是笼统的“软件”，而是可被独立识别、控制和追溯的软件项（Software Item）：一个模块、一个算法、一个接口、一段状态机，甚至一条关键需求。
审查对象通常分为四类：需求项（功能、性能、接口、安全相关需求）、架构与设计项（分层、模块、数据流、控制流）、实现项（代码、配置、参数、第三方组件）、验证项（测试用例、覆盖分析、缺陷记录）。四类对象之间必须建立双向追溯：每条安全相关需求都能找到对应设计、代码和测试；每个关键设计决策都能回溯到需求或风险控制措施。
二、法规边界：IEC 62304 与风险管理双轨并行
国际电工委员会标准 IEC 62304 是医疗器械软件生命周期过程的核心依据，我国对应标准为 YY/T 0664。它把软件生命周期划分为开发、维护、风险管理、配置管理、问题解决等过程，并按软件安全分级（A/B/C）规定不同的活动强度。A级允许软件失效不造成伤害；B级可能造成非严重伤害；C级可能造成死亡或严重伤害。级别越高，对架构设计、单元验证、详细设计文档的要求越严。
与 IEC 62304 并行的是 ISO 14971 风险管理过程。软件设计审查必须与风险管理联动：风险分析输出“软件安全相关需求”，设计审查确认这些需求被正确实现，验证活动确认实现有效，剩余风险被评估并接受。两条轨道不是先后关系，而是持续交互——风险控制措施可能改变架构，架构变更又可能引入新的风险。
关键边界：设计审查不替代测试，也不替代法规注册审查。它关注的是“设计决策是否有依据、是否被正确表达、是否可被验证”，而不是“软件是否已经通过所有测试”。审查记录本身是质量体系文件的一部分，需可追溯、可审计。
三、工程框架：设计审查在生命周期中的位置
把设计审查放进软件生命周期，可以看到它并非孤立节点，而是与需求、架构、实现、验证、维护形成闭环。下图给出一个简化的工程框架：左侧是输入（用户需求、风险分析、法规要求），中间是设计审查的核心活动（需求审查、架构审查、详细设计审查、代码审查、验证审查），右侧是输出（审查记录、缺陷、变更请求、追溯矩阵），并通过配置管理和问题解决过程形成反馈回路。
图中左侧输入并非一次性交付，而是随项目推进不断更新；右侧输出也不是终点，缺陷和变更会回流到输入和设计，触发新一轮审查。这种闭环决定了设计审查必须是迭代的、有记录的、可追溯的。
四、实际怎么做：一次设计审查的最小闭环
以一个输液泵控制软件为例，假设其安全分级为C级。审查启动前，审查组长需要确认三件事：审查对象清单是否完整（需求项、架构项、详细设计项、代码模块、测试用例）、风险分析是否已输出安全相关需求、上一轮审查的缺陷是否已关闭。
审查过程中，针对“阻塞报警”这条安全相关需求，审查组会检查：需求是否写明报警触发条件、响应时间和最大延迟；架构中是否设计了独立的报警监控任务，与主控制任务隔离；详细设计中是否定义了传感器故障时的默认状态；代码中是否有看门狗和自检逻辑；测试用例是否覆盖了传感器断线、读数漂移和任务超时三种场景。任何一环缺失，都会生成缺陷记录并指定责任人。
审查结束后，输出一份审查记录，包含审查对象版本号、参与人员、检查项结论、缺陷清单和放行建议。若存在未关闭的严重缺陷，则不建议进入下一阶段。所有记录纳入配置管理，作为后续变更和注册申报的证据。
教学示例说明：上述输液泵场景为课程示例，用于说明审查闭环的检查逻辑，参数和场景均为合理假设，不代表任何实际产品的实测结果。
五、常见误区与边界意识
第一个误区是把设计审查等同于“开会签字”。有效的审查需要检查项、证据和判断准则，而不是凭印象通过。第二个误区是只审文档不审实现，导致设计与代码脱节。第三个误区是忽略软件安全分级，对A级软件套用C级模板，造成资源浪费；或对C级软件简化审查，留下安全隐患。