4. 软件安全分级
在医疗软件验证与确认工程中，IEC 62304 是贯穿全生命周期的核心标准。它并不要求所有软件都执行同样强度的 V&V 活动，而是先通过“软件安全分级”把软件划分为 A、B、C 三个等级，再按等级裁剪开发、验证与确认要求。理解这套分级逻辑，是后续制定验证策略、分配测试资源、判断文档深度的前提。
一、分级的判定对象：软件项，而非整个产品
IEC 62304 的分级对象是软件项（software item），而不是整台设备或整个软件系统。一个含软件的医疗器械，可能同时包含多个软件项：例如输液泵的“流速控制模块”和“日志导出模块”，二者失效后果完全不同，应分别定级。因此，实际工作中第一步是完成软件架构分解，识别出可独立评估的软件项，再逐项定级。
分级的依据不是软件规模、复杂度或开发难度，而是软件失效可能导致的危害后果。标准给出的判定准则可归纳为三个递进问题：
- A 级：软件失效不可能导致伤害，也不可能导致不可接受的健康风险。例如仅用于显示趋势、生成统计报表、非诊断用途的数据导出。
- B 级：软件失效可能导致非严重伤害（non-serious injury）。例如报警提示延迟但医护人员仍可及时干预，或剂量显示偏差在可纠正范围内。
- C 级：软件失效可能导致死亡或严重伤害（death or serious injury）。例如放疗剂量控制、呼吸机通气参数闭环控制、除颤能量输出控制。
这里的关键词是“可能导致”。分级不是看历史上是否发生过伤害，而是看失效后果的潜在严重度。如果某软件项失效后，其危害后果的严重度无法被判定为“非严重”，则应保守地归入 C 级。
二、基于风险确定等级：从危害分析到软件项定级
软件安全等级不能凭经验拍定，而应来自风险管理过程。典型路径是：先做系统级危害分析（如 ISO 14971 要求的 FMEA、FTA 或危害清单），识别危害、危害处境和伤害；再分析每个危害的风险控制措施；最后判断哪些风险控制措施由软件承担。若某软件项是某条风险控制链上的关键环节，其失效会直接使该控制措施失效，则该软件项的等级由该危害的严重度决定。
需要特别注意的是：风险控制措施本身也可能引入新的软件风险。例如，为降低“过量输注”风险而增加“软件限速”功能，这个限速软件项一旦失效，反而可能直接导致过量输注，因此它通常应定为 C 级。分级结果应记录在软件安全分级文件中，并随风险管理活动更新而复审。
三、A、B、C 级对 V&V 活动的具体要求差异
分级结果直接决定软件开发生命周期过程的“必做项”。IEC 62304 对三个等级的要求呈阶梯式递增，核心差异体现在以下方面：
| 活动领域 | A 级 | B 级 | C 级 |
|---|---|---|---|
| 软件单元验证 | 不要求 | 要求 | 要求，且需覆盖度分析 |
| 软件集成测试 | 不要求 | 要求 | 要求，含接口与集成顺序验证 |
| 软件系统测试 | 要求 | 要求 | 要求 |
| 代码覆盖率 | 不要求 | 不强制 | 要求语句/分支覆盖，必要时更严 |
| 独立验证 | 不要求 | 不要求 | 建议由独立人员或独立团队执行 |
| 详细设计文档 | 不要求 | 要求 | 要求，且需可追溯到单元 |
从表中可见，A 级软件只需保证系统级行为正确，验证重点在“整机功能是否满足预期用途”；B 级开始要求单元和集成层面的验证，确保模块内部逻辑与接口正确；C 级则进一步要求覆盖度分析、详细设计追溯和独立验证，以证明“没有未测试到的关键路径”。
四、实操中的定级与验证策略示例
假设某输液泵软件被分解为三个软件项：流速控制项、报警提示项、历史记录导出项。危害分析显示：流速控制失效可能导致过量输注，严重度为“严重伤害”，故定为 C 级；报警提示失效可能导致医护人员延迟响应，但不会直接造成不可逆伤害，定为 B 级；历史记录导出仅用于事后统计，失效不影响治疗，定为 A 级。
对应的 V&V 策略可设计为：
- 流速控制项（C 级）：对每个单元编写单元测试，要求语句覆盖率 100%、分支覆盖率 100%；执行集成测试验证传感器—控制器—电机驱动接口；系统测试覆盖最大流速、最小流速、阻塞报警、气泡报警等场景；由独立验证人员复核测试用例与结果。
- 报警提示项（B 级）：执行单元测试和集成测试，验证报警触发条件、优先级和显示逻辑；系统测试验证报警在正常和异常工况下均能正确呈现；不强制覆盖率指标，但需保留测试记录。
- 历史记录导出项（A 级）：仅执行系统级测试，验证导出文件格式、字段完整性和时间戳正确性；无需单元测试和集成测试。
五、常见误区与判断边界
实际工作中，分级最容易出现两类偏差。第一类是“就低不就高”：为了减少验证工作量，把本应定为 C 级的软件项归为 B 级。例如，某软件项虽然不直接控制治疗输出，但它负责计算剂量并传给控制模块，一旦计算错误会直接导致过量，这种“间接但关键”的软件项仍应定为 C 级。第二类是“整机一个等级”：把整个产品笼统定为 C 级，导致所有模块都执行最高强度验证，资源浪费严重。正确做法是逐软件项定级，再按等级组合验证策略。
判断边界可以借助一个简单问题：如果该软件项失效，且所有外部风险控制措施都未生效，是否可能导致死亡或严重伤害？若答案是“是”，则定为 C 级；若答案是“可能导致非严重伤害”，定为 B 级；若答案是“不可能导致伤害”，定为 A 级。这个判断必须基于危害分析，而不是开发人员的直觉。
掌握 A、B、C 级分类准则，本质上是在回答“验证做到什么程度才够”。等级越高，V&V 的深度、覆盖度和独立性要求越高；等级越低，越依赖系统级验证和风险管理结论。只有把分级做准，后续的验证计划、测试用例设计和确认活动才有可靠依据。