ARTICLE · 1044573
医疗器械软件生命周期入门:不是“写完代码再补文档”,而是把风险管到退市
专注医疗器械全球注册与法规合规，分享实战经验，助你少走弯路。
如果一款医疗器械里有软件，研发团队迟早会遇到这样的问题：
软件已经测试通过了，为什么还要做需求追溯、版本控制、缺陷管理和上市后维护？
答案很简单：软件测试通过，不等于软件的风险已经被充分控制。
软件不像螺钉或导管那样会发生肉眼可见的磨损。它的失效可能没有明显征兆；一个看似很小的改动，也可能影响另一个功能。测试又不可能穷尽所有输入、设备组合和使用场景。因此，医疗器械软件的质量不能只靠最后一次测试来证明，而要靠一套贯穿产品始终的管理过程来建立。
这套过程，就是医疗器械软件生命周期。
一、什么是软件生命周期？
很多新人会把生命周期理解成“需求、设计、编码、测试、发布”这条开发流程。这个理解只对了一半。
根据《医疗器械软件注册审查指导原则（2022年修订版）》和YY/T 0664-2020，医疗器械软件生命周期至少包括五类过程：
1. 软件开发过程：从策划、需求、设计、编码，到验证、确认和发布。
2. 软件维护过程：软件发布后的更新需求评估、策划、实施、验证、确认、发布和用户告知。
3. 软件风险管理过程：识别危害，评价风险，实施控制，并评价综合剩余风险。
4. 软件配置管理过程：管住代码、文档、工具、第三方软件、版本和变更状态。
5. 软件缺陷管理过程：记录、评价、修复缺陷，并完成回归测试。
此外，还有一条非常重要的“线”——软件可追溯性。它把用户需求、系统需求、软件需求、设计、风险控制、测试和缺陷处理连接起来。
可以把整个体系理解成下面这个结构：
开发：策划 → 需求 → 设计 → 编码 → 验证/确认 → 发布
维护：问题/新需求 → 影响评估 → 修改 → 回归测试 → 再发布
贯穿全过程：风险管理｜配置管理｜缺陷管理｜可追溯性｜网络安全
所以，生命周期并不在产品拿到注册证时结束。软件上市后的投诉、不良事件、漏洞、操作系统补丁和功能更新，都属于生命周期管理的一部分。产品停止服务时，还要考虑用户告知、数据迁移、患者数据和隐私保护。
二、为什么第一步不是写代码，而是确定“风险有多高”？
医疗器械软件注册审查指导原则将软件安全性级别分为轻微、中等和严重：
• 轻微级别：软件不可能产生伤害 • 中等级别：软件可能直接或间接产生轻微伤害 • 严重级别：软件可能直接或间接产生严重伤害或导致死亡
判断时不能只看软件叫什么，还要结合预期用途、使用场景、核心功能、核心算法、输入输出和接口等因素。
这里有两个容易误解的地方：
第一，安全性级别原则上应基于采取风险控制措施前的情况判断。不能因为后来增加了报警功能，就倒推软件原本风险很低。
第二，级别越高，并不意味着软件一定不能上市，而是意味着生命周期控制要更严格、申报资料要更充分。
安全性级别本质上是在回答：我们需要用多大强度的过程和证据，才能对这款软件建立合理信心？
三、开发阶段到底要做什么？
1. 先策划，再开发
软件开发计划不应只是项目排期。它至少要说明采用什么生命周期模型、各阶段输出什么文档、由谁评审、何时测试、如何管理风险与配置，以及发现问题后按什么流程处理。
瀑布、迭代或敏捷开发都可以采用。关键不在模型名称，而在于活动和记录是否完整，特别是快速迭代时，需求、风险、测试和版本记录不能被冲刺节奏甩在后面。
2. 把需求写成“可验证”的要求
“界面友好”“运行稳定”“结果准确”都不是足够好的软件需求，因为它们无法直接判定是否满足。
一个合格的软件需求通常应明确：软件要完成什么功能；输入、输出和接口是什么；性能或精度达到什么范围；异常情况下如何响应；哪些要求来自风险控制；采用什么方法验证。
例如，与其写“系统应及时报警”，不如明确报警触发条件、响应时间、报警方式、优先级、复位逻辑及相关测试方法。
3. 用设计把需求变成可实现的结构
软件设计需要回答：系统由哪些软件项或模块组成，它们如何交互，关键数据怎样流动，外部接口如何工作，风险控制措施由哪个模块实现。
安全性级别越高，越需要把体系结构、接口和详细设计说明清楚。设计的价值不是为了“多一份文档”，而是让评审人员能判断：关键风险是否真的被落实到了合理的软件结构中。
4. 验证与确认不是一回事
可以用一句通俗的话区分：
• 验证关注“软件是否按照规定被正确地做出来” • 确认关注“做出来的软件是否满足预期用途和用户需要”
单元测试、集成测试、系统测试常用于验证；在代表性的使用环境、目标用户和工作流程下评价软件能否支持预期用途，则更接近确认。
测试不仅要覆盖正常路径，也要覆盖边界值、异常输入、通信中断、资源不足、错误操作和风险控制功能。修复缺陷后还要做回归测试，确认修改没有破坏既有功能。
5. 发布不是“把安装包发出去”
正式发布前，应确认计划活动已经完成，已知剩余缺陷经过评价，版本和配置项一致，交付文件齐全，并有可复现的发布记录。
一个常见问题是：测试报告对应版本、注册申报版本和最终生产发布版本不一致，却没有差异分析。版本号看似只是几个数字，背后代表的却是整套证据是否仍然有效。
四、四条贯穿始终的“生命线”
风险管理：每个控制措施都要落地
软件风险管理不是项目末尾补一张FMEA表。风险控制措施如果由软件实现，就应进入软件需求，并进一步落实到设计和测试。测试完成后，还要回到风险分析中确认控制措施有效、没有引入新的不可接受风险。
配置管理：确保大家谈的是同一个产品
配置管理的对象不只是源代码，还可能包括需求和设计文档、测试脚本、编译器及其版本、构建脚本、数据库、第三方库、操作系统和网络安全补丁。
它要解决三个基本问题：现在受控的是什么？发生过什么变更？某个发布版本由哪些配置项组成？
缺陷管理：缺陷可以存在，但不能失控
医疗器械软件并不要求“零缺陷”，因为复杂软件几乎不可能证明没有任何缺陷。真正重要的是：缺陷是否被记录、分类和评价；是否影响安全有效性；是否需要修复；不修复的理由是否充分；修复后是否完成回归测试。
可追溯性：让证据链闭环
一条典型的追溯链可以是：
危害 → 风险控制措施 → 软件需求 → 设计模块 → 测试用例 → 测试结果
追溯矩阵不是为了把编号堆在Excel里，而是帮助团队发现遗漏：某个高风险需求有没有测试？某项测试有没有需求来源？一次变更会影响哪些风险控制和验证证据？
五、软件发布后，生命周期才进入更难的一段
软件发布后可能遇到三类变化：
• 纠正类更新：修复软件缺陷 • 适应型更新：适配新的硬件、操作系统、数据库或运行环境 • 完善型更新：新增或改进功能、性能和易用性
任何更新都不应直接进入开发。第一步是影响评估：是否改变预期用途、核心功能、算法、接口或风险控制？是否引入新的危害？是否影响网络安全？需要多大范围的回归测试？是否构成重大软件更新并涉及变更注册？
对于操作系统、数据库、开源组件等现成软件，也不能把维护责任完全交给供应商。注册申请人仍需评价版本、补丁、兼容性、已知漏洞和停止支持风险，并决定是否更新以及如何验证。
六、网络安全为什么也是生命周期问题？
只要软件具有电子数据交换、远程访问、联网更新或外部存储介质等能力，就需要考虑网络安全风险。
网络安全不是产品上市前做一次渗透测试就结束。漏洞会持续出现，第三方组件会停止维护，攻击方法也会变化。因此，网络安全应进入需求、设计、风险管理、测试、配置、维护和事件响应全过程。
入门阶段可以先记住三个目标：
• 保密性：数据不被未授权获取 • 完整性：数据和软件不被未授权修改 • 可得性：需要使用时，系统和数据能够正常获得
医疗器械网络安全指导原则还强调网络安全可追溯性，即把网络安全需求、设计、源代码、测试和风险管理连接起来。换句话说，“做过安全测试”不够，还要说明测试对应哪些威胁和控制措施。
七、新人最容易踩的五个坑
坑一：产品快送检了才开始补生命周期文档。 这时需求、设计和代码已经脱节，追溯关系很难真实重建。
坑二：把软件测试报告当成全部软件研究资料。 测试只是证据链的一环，无法替代风险、设计、配置、缺陷和维护记录。
坑三：版本号随意命名。 完整版本、发布版本和模块版本之间没有规则，导致变更性质和证据适用范围无法判断。
坑四：认为第三方软件出了问题是供应商的责任。 对医疗器械最终安全有效性负责的仍是注册申请人。
坑五：修复一个缺陷，只测试被修改的功能。 软件修改可能产生连锁影响，回归测试范围必须经过影响分析确定。
八、一套可以立即开始的最小清单
如果团队刚开始建立软件生命周期体系，可以先确保以下十件事能够闭环：
1. 确定软件边界、预期用途和安全性级别 2. 建立软件开发计划和角色职责 3. 形成可验证的软件需求规范 4. 建立体系结构、接口和关键详细设计 5. 把软件风险控制措施写入需求并安排测试 6. 建立需求、设计、风险和测试之间的追溯关系 7. 对代码、文档、工具和第三方软件实施配置管理 8. 建立缺陷分级、影响评价、修复和回归测试流程 9. 为每次发布保留唯一版本、配置基线和发布记录 10. 建立上市后监测、软件更新、漏洞响应和停止服务方案
这十项不是全部法规要求，却能帮助团队搭起最基本的骨架。
写在最后
医疗器械软件生命周期的核心，不是制造一套看起来完整的文档，而是持续回答四个问题：
我们要做什么？为什么这样设计？如何证明它满足要求？发生变化后，原来的证据是否仍然成立？
当需求、风险、设计、测试、版本、缺陷和维护能够形成闭环，文档就不再是研发结束后的负担，而会成为团队控制产品风险、解释技术决策和支持注册申报的共同语言。
对于刚入门的人，不必一开始就记住所有条款。先建立“全生命周期”和“证据链”的思维，再逐步把每一项活动做实，通常比单纯背标准更有效。
互动话题：你在软件生命周期管理中踩过哪些坑？是版本追溯、缺陷管理还是网络安全？欢迎在评论区交流。
本文依据《医疗器械软件注册审查指导原则（2022年修订版）》、YY/T 0664-2020及《医疗器械网络安全注册审查指导原则（2022年修订版）》整理，供参考学习。具体操作请以最新法规和标准为准。