2. 医疗器械软件分类与审查路径

在医疗器械软件设计审查中，分类不是贴标签，而是决定后续审查深度、证据类型和风险控制策略的起点。同一段算法代码，放在独立App里和烧录在输液泵主控板里，其失效后果、更新方式和验证路径完全不同。因此，审查工程师必须先回答三个问题：软件是否本身构成医疗器械？软件是否驱动或控制硬件？软件是否可独立交付和独立更新？这三个问题的答案，基本决定了它属于SaMD、SiMD、嵌入式软件还是独立软件。

一、四类软件的定义边界与判断逻辑

SaMD（Software as a Medical Device）指不依附于特定硬件、本身用于医疗目的的软件。例如基于手机摄像头进行皮肤病变风险分级的App、云端心电图自动判读服务。其核心特征是：软件独立实现医疗用途，硬件只是通用计算平台。

SiMD（Software in a Medical Device）指嵌入在医疗器械硬件中、作为设备组成部分实现医疗功能的软件。例如CT机的图像重建软件、呼吸机的闭环控制软件。它不能脱离硬件单独销售，其安全有效性必须与整机一起评价。

嵌入式软件强调软件与微控制器、DSP、FPGA等资源受限硬件的紧耦合关系，通常以固件形式存在，运行在实时操作系统或裸机环境中。它更关注时序、中断、内存和硬件寄存器操作。

独立软件指可独立安装、运行于通用计算平台、具有独立界面的软件，可以是SaMD，也可以是医疗器械的配套软件。判断关键在于“是否可独立交付、独立运行、独立更新”。

二、不同类别对应的审查深度差异

分类确定后，审查深度并非一刀切。以SaMD为例，若其输出用于辅助诊断且错误可能导致严重伤害，审查会要求完整的算法描述、训练数据来源、验证集性能、假阴假阳分析以及临床评价；而低风险的独立软件，如医院内部使用的预约管理工具，若仅用于流程管理而不涉及诊断治疗，通常只需软件描述和基本功能测试。

SiMD和嵌入式软件的审查重点则转向硬件耦合面。审查工程师需要关注：软件是否在中断服务程序中执行关键控制？看门狗是否被正确喂狗？内存保护单元是否配置？通信超时后是否进入安全状态？这些问题的证据通常来自需求追溯、代码审查记录、时序测试报告和故障注入测试结果。例如，某输液泵嵌入式软件在审查中被要求提供“阻塞报警响应时间≤3秒”的验证记录，包括测试条件、传感器模拟方式和实测波形。

三、证据要求的层级化组织

审查证据可以按“需求—设计—实现—验证—风险”五条线索组织。需求侧看SRS是否覆盖了所有安全相关功能；设计侧看架构是否隔离了高风险模块；实现侧看编码规范、静态分析和单元测试覆盖率；验证侧看集成测试和系统测试是否覆盖了异常路径；风险侧看FMEA是否识别了软件失效模式并给出控制措施。

对于独立软件，还需额外关注更新机制。若软件支持在线升级，审查会要求提供更新包完整性校验、回滚策略和更新后验证方案。对于嵌入式软件，更新往往涉及固件烧录，审查会关注烧录失败后的恢复能力和版本一致性校验。

四、实操中的分类记录示例

在实际审查中，建议用一张分类判定表固定判断依据，避免口头结论。以下为示例字段，可根据项目裁剪：

填写时应注意：判定项之间不是简单累加，而是有优先顺序。先确认医疗目的，再判断硬件依附和交付方式，最后结合风险等级确定审查深度。对于边界模糊的软件，例如运行在通用平板上的康复训练软件，若其训练方案由治疗师配置且不直接控制能量输出，通常按低风险独立软件处理；若它实时调节电刺激参数，则应按SiMD或嵌入式路径审查。

掌握分类方法后，审查工程师才能在项目早期确定文档清单、测试范围和评审重点，避免在后期因分类错误导致证据不足或审查路径反复。分类是审查工程的第一道过滤器，也是后续所有验证活动的基准。