ARTICLE · 1357753
医疗器械软件到底应该怎么开发?从立项到注册,一篇讲清全过程与文档清单
不是代码写完就算开发完成。真正合规的医疗器械软件，必须同时证明：需求正确、设计受控、风险可接受、测试有证据、版本可追溯。
医疗器械软件研发实操指南｜适用于独立软件、APP与云平台，以及呼吸机、监护仪等设备中的软件组件
在普通互联网项目中，开发团队往往首先关心功能能否上线、用户体验是否顺畅、迭代能否加快。但对医疗器械而言，仅有一套可以运行的程序远远不够。
监管人员还会关心：每一项软件功能来自哪个产品需求？其设计依据是什么？是否存在伤害风险？代码由谁修改？经过哪些测试？测试失败如何处理？最终注册版本与生产发布版本能否对应？
这些问题没有单靠源代码就能回答的答案。解决办法是建立一条由产品需求、软件需求、软件设计、受控实现、验证确认、风险管理和发布维护构成的完整证据链。
本文采用国内医疗器械监管视角，结合院内转运呼吸机的软件组件，介绍一套可供企业实施的工作方法。文中的文档名称及编号为推荐管理方式，实际项目应根据产品风险程度、适用法规和设计开发体系裁剪，并不意味着所有文件都要作为注册附件逐项提交。
启动研发前，最重要的不是选编程语言，而是确定医疗器械软件的产品边界和预期用途。
独立软件（SaMD）：软件本身实现医疗目的，通常运行在通用计算平台，例如符合医疗器械定义的影像分析软件、专用临床监护软件、部分医疗APP和云端算法服务。
软件组件（SiMD）：软件与医疗器械硬件共同实现预期用途，例如呼吸机的通气控制、监测显示、报警与电源管理固件，通常作为整机的一部分进行注册。
还要进一步区分第三方现成软件（SOUP）、必备软件、外部软件环境，以及仅用于企业质量管理的系统。不是所有云服务器、数据库、APP功能或研发工具，都自动成为医疗器械产品的一部分。但其失效如果影响医疗器械安全有效性，就必须纳入适当的评估和控制。
立项时至少回答六个问题：谁使用？用于什么医疗目的？在哪些环境使用？哪些功能影响诊疗决策或患者安全？软件与哪些硬件、外部系统和第三方组件交互？系统边界在哪里？
对应的起始文件通常包括《预期用途与产品边界说明》《用户需求说明书（URS）》《产品需求规格书（PRS）》及《适用法规标准清单》。
截至2026年11月，医疗器械软件企业应重点关注以下依据：
- 《医疗器械生产质量管理规范》（2025年第107号）
：已于2026年11月1日施行；独立软件企业还应符合适用的《规范》独立软件附录，并使用2026年修订的独立软件检查指导原则开展差距检查。软件组件相关检查参照执行。 - GB/T 42061-2022
：医疗器械质量管理体系，提供设计开发、文件记录、采购与外包、变更和可追溯管理框架。 - YY/T 0664-2020
：医疗器械软件生存周期过程，是组织软件策划、开发、维护、配置管理和问题解决的重要技术依据。 - GB/T 42062-2022
：医疗器械风险管理，要求风险分析、评价、控制、剩余风险评价及上市后信息反馈形成闭环。 - 《医疗器械软件注册审查指导原则（2022年修订版）》
：指导软件生命周期控制与软件注册研究资料的准备。 - 《医疗器械网络安全注册审查指导原则（2022年修订版）》
与《医疗器械可用性工程注册审查指导原则》（2024年）：分别覆盖适用的网络安全与使用风险控制。
另外，YY/T 1406-2026已发布，但其实施日期为2027年3月1日，本文发布时尚未实施。企业可以提前开展差距分析，不应把它误写成目前已实施的标准。对具体设备还应核对产品专用标准和注册审查指导原则。
法规识别不能停在“列标准名称”。建议建立法规符合性矩阵，明确每项适用要求对应哪份需求、哪项设计、哪项测试及哪个报告，无法适用的条款记录理由。
第一阶段：项目策划与风险分级。明确产品定义、软件组成、生命周期模型、角色职责、里程碑、评审节点和资源；识别安全相关功能与初始危害。形成《软件开发计划》《软件风险管理计划》《软件安全性级别判定报告》等。立项评审通过后建立项目受控基线。
第二阶段：需求分析。把用户需求、产品需求、适用标准和风险控制要求分解为可验证的软件需求。SRS不仅要描述正常功能，还应覆盖异常输入、边界值、状态转换、报警优先级、数据完整性、性能、接口、日志、维护与网络安全等。每条需求应有唯一编号、来源和明确的验证方式。完成需求评审后建立需求基线。
第三阶段：架构与详细设计。将SRS映射到软件项和软件单元，明确模块职责、接口协议、数据流、控制状态机、运行环境以及风险控制实现位置。形成《软件架构设计说明书》《软件详细设计说明书》《接口及通信协议说明书》《软件设计评审记录》等。对第三方组件评估适用性、版本、缺陷和维护安排。
第四阶段：编码、构建与单元测试。按批准的设计进行编码，执行代码审查、静态分析、单元测试及配置管理。保留受控源代码、提交记录、审查记录、构建环境、编译脚本、依赖版本和构建产物的唯一标识。不是“程序员电脑里能编译成功”就足够，而是要能重复构建、识别差异并回溯责任。
第五阶段：集成与系统验证。基于已批准的测试计划，开展软件单元、集成、系统、接口、性能、异常工况、回归及适用的网络安全测试。测试用例必须有输入、步骤、预期结果、实际结果、结论和异常处理记录。发现缺陷后，应评估影响范围、修复并进行适当回归测试。
第六阶段：设计确认与可用性评价。在预期用户、预期使用场景下证明软件及其所属产品能够满足用户需求和预期用途。对于关键操作任务，需要通过形成性评价不断改进界面，并依据使用风险开展总结性评价或其他适当确认活动。验证问“是否按需求正确实现”，确认问“是否满足实际使用需要”。两者不能相互替代。
第七阶段：受控发布、部署与维护。发布前批准版本、确认缺陷状态、核对风险与追溯、冻结配置项并生成发布包。发布后持续开展故障处理、网络安全监测、补丁升级、变更影响评估、必要的回归验证及上市后信息收集。
值得注意的是，瀑布、V模型、迭代或敏捷均可使用。监管关注的是活动是否充分、证据是否完整、变更是否受控，而不是软件项目必须画成某一种固定流程图。
建议按八组建立软件设计开发历史文档（DHF）索引，明确文件编号、版本、责任人、批准状态和相互引用关系：
A. 管理制度和计划类
《软件生存周期管理程序》《软件配置管理程序》《软件变更控制程序》《软件问题解决程序》《软件发布与维护程序》《软件开发计划》《软件质量保证计划（适用时）》《风险管理计划》《软件安全性级别判定报告》《法规及标准符合性矩阵》。
B. 用户需求和软件输入类
《用户需求说明书（URS）》《产品需求规格书（PRS）》《软件需求规格说明书（SRS）》《软件需求评审记录》《软件需求追溯关系表》《软件接口需求》《安全相关软件需求清单》《用户界面需求规范》《网络安全需求规范》。后几项可独立成文，也可以在SRS中明确索引。
C. 架构和设计输出类
《软件架构设计说明书》《软件详细设计说明书》《数据流及接口设计说明》《通信协议规范》《数据库/数据字典说明（适用时）》《核心算法设计及研究资料》《人机界面设计说明》《第三方软件组件清单与评估》《设计评审记录》。
D. 编码和配置管理类
《软件编码规范》《代码审查记录》《静态分析记录》《源代码版本及配置项清单》《开发与构建环境清单》《构建脚本和构建记录》《第三方依赖和许可评估记录》《软件问题/缺陷处理单》。
E. 软件验证与确认类
《软件验证与确认计划》《单元测试用例及记录》《集成测试计划及报告》《系统测试计划及报告》《功能/性能/接口/异常场景测试记录》《回归测试报告》《风险控制措施验证记录》《用户测试计划及报告》《设计确认报告》《软件验证确认总结报告》。按软件风险级别和适用性确定深度，不能因为没有单独文档标题就遗漏必须完成的活动。
F. 风险管理及可用性工程类
《软件风险分析报告》《软件风险控制措施清单》《剩余风险评价与综合剩余风险评价》《软件风险管理报告》《可用性工程计划》《关键任务及使用错误分析》《形成性评价记录》《总结性评价方案与报告（适用时）》《可用性工程研究资料》《使用风险可追溯分析》。产品风险管理与软件风险管理应衔接，而不是各写各的。
G. 网络安全类
《网络安全计划》《资产/接口/数据流清单》《网络安全威胁与风险分析》《安全架构和安全需求》《现成软件清单（SBOM，适用时）》《网络安全测试计划与报告》《漏洞扫描及漏洞评估报告》《渗透测试等专项记录（适用时）》《网络安全事件应急响应预案》《网络安全维护与补丁管理记录》。
H. 发布、维护及注册资料类
《软件发布评审与批准记录》《软件发布包及完整版本记录》《软件版本命名规则》《已知剩余缺陷清单及风险评价》《部署与安装验证记录》《软件维护计划》《软件变更影响评估》《回归验证记录》《软件设计历史文档集索引表》《自研软件研究报告》《网络安全研究报告》《可用性工程研究报告或使用错误评估报告》《外部软件环境评估资料（适用时）》。
提醒：上述是可用于建立研发文档体系的参考清单，不是所有项目统一的法定“文件数量”，更不等于每份原始记录都必须单独放进注册申报卷宗。企业可依文件控制程序合并同类记录，但应保证活动、证据和追溯关系完整。
第一条：风险管理不能只在结题时做一次。软件开发前应分析软件失效或错误使用可能引发的危险情况；软件设计阶段落实风险控制；测试阶段验证这些控制措施的有效性；发布前评价剩余风险；上市后用投诉、故障和漏洞信息更新评估。风险管理不仅是FMEA表格，更要说明危害、原因、危险情况、伤害、控制和验证之间的联系。
第二条：网络安全不等于“能上网才需要”。2022版网络安全指导原则涵盖电子数据交换、远程访问控制和用户访问等情形。USB导出、远程维护、登录权限、移动介质升级，都可能带来相关要求。应分析数据保密性、完整性、可得性以及身份鉴别、授权、日志、升级、补丁与漏洞响应。采用SOUP的产品还要持续关注组件漏洞和安全维护状态。
第三条：可用性不是界面好不好看。医疗器械的可用性是安全有效使用问题。例如：报警是否被正确识别、参数设置是否容易误触、单位是否容易混淆、紧急情况下能否完成关键操作。对于高使用风险医疗器械，原则上应进行完整的可用性工程生命周期控制；注册申报研究资料与中低风险产品存在差异。
假设一台院内转运呼吸机具有外部电源中断监测功能。一个良好的研发记录链可以是：
UN-005 用户需求：医护人员需要及时识别设备供电异常。
SRS-ALM-017 软件需求：当检测到外部供电中断并进入规定的供电状态时，软件按批准的报警策略提供相应视觉/听觉提示并记录事件；报警条件、响应时间、优先级和消除条件在受控参数表中确定。
SDS-ALM-009 软件设计：将电源监控信号、状态判断、报警状态机、屏幕提示、声音输出和日志记录分配至相应模块，并定义异常与恢复逻辑。
MOD-PWR-03 软件实现：对应受控模块的源代码、审查记录及构建版本。
TC-SYS-042 验证记录：模拟电源中断、备用供电切换、报警触发、状态恢复及异常组合，记录结果；必要时评估不同失效模式和单一故障情况下的表现。
RISK-023 与 UI-006：分别关联供电异常相关风险控制、报警识别等关键使用任务及其确认结果。
这些编号仅用于示意，并非某一实际产品的技术要求。关键是做到从需求向下能找到设计和测试，从失败的测试向上能追到需求和风险。未验证的需求、没有设计依据的代码、找不到风险控制证据的测试，都应成为评审时需要处理的问题。
企业常见的误区是：既然要交软件研究报告，就等到注册前再补一份漂亮的研究报告。实际上，注册资料应当是研发全过程原始证据的归纳和论证，而不是代替原始证据。
在研发与质量体系中，应保留需求、设计、源代码与版本控制、风险分析、各级测试原始记录、缺陷处理和批准记录等。对于中国第二类、第三类软件注册，申报时则按适用性和安全性级别准备自研软件研究报告、软件需求规范、相应测试计划与报告、可追溯分析、网络安全资料、可用性资料和风险管理资料等。
以2022版软件指导原则的自研软件研究报告框架为例：报告既有软件标识、软件安全性级别、结构功能、物理拓扑和运行环境，也有开发概况、风险管理、软件需求、生存周期、验证确认、可追溯、缺陷、更新历史和核心功能。严重级别软件的要求更详尽，相应的设计历史文档索引、编码规则、集成/系统/用户测试等证据尤其需要提前规划。
可用性方面，高使用风险产品注册原则上提交可用性工程研究报告；中、低使用风险产品可按照指导原则提交使用错误评估报告，或以适当的可用性工程研究报告替代。网络安全方面，应根据适用的接口、数据交换与访问功能，以及风险程度，准备相应的研究和漏洞评估资料。
也要注意：第二类、第三类的医疗器械注册分类，不等同于软件安全性级别。2022版软件指导原则采用轻微、中等、严重三个软件安全性级别，分别与YY/T 0664的A、B、C级对应，应依据软件可能引起的伤害严重程度及适用规则作出有根据的判定。对于控制生命支持功能的呼吸机软件，指导原则通常将其软件安全性级别归为严重。
如果企业刚开始规范软件设计开发，不必先堆出几十份没有内容的模板。建议优先建立五种动态记录：法规/标准符合性矩阵、需求与设计追溯矩阵、软件风险控制跟踪表、缺陷及变更台账、软件配置与版本基线清单。
再设置四个正式质量关口：
需求评审关：每条安全相关需求均有来源、唯一标识和验证方法，风险控制要求已经进入需求基线。
设计评审关：架构、接口、关键算法、SOUP及风险控制实现经过评估，不存在重大设计空白。
验证确认关：计划的测试完成，偏差与缺陷有处置结论，关键任务和风险控制均有客观证据。
发布批准关：版本、构建、风险、追溯、剩余缺陷、说明书和注册声明一致；未关闭事项有批准的风险评价和处理计划。
对于采用敏捷、CI/CD或云端部署的团队，这四个关口可以融入迭代与发布流程，不需要每次迭代都重新做整套文件，但每次影响安全有效性的变更都要进行适当影响评估、测试和记录。
医疗器械软件不是“研发写代码、测试找Bug、法规部门临时补文件”的串行接力。正确的组织方式，是研发、测试、临床、风险管理、质量和法规人员从一开始就共享需求、风险、版本与验证证据。
一个软件能运行，只能说明它具备某些功能；一个医疗器械软件能够合规发布，则需要证明它在预期用途和预期使用场景下，安全性与有效性已经得到充分论证。
从今天开始，不妨先审查手头的软件项目：有没有正式批准的SRS？每条重要需求能否找到设计和测试证据？严重风险的控制措施是否已验证？软件发布包能否重现？已知剩余缺陷和漏洞有没有被评价？
把这些问题回答清楚，软件开发文档才真正从“资料负担”变成“安全与注册的底座”。
参考依据（截至2026年11月）
国家药监局公告2025年第107号《医疗器械生产质量管理规范》（2026年11月1日施行）。 国药监械管〔2026〕17号《医疗器械生产质量管理规范独立软件检查指导原则》（2026年11月1日施行）。 GB/T 42061-2022《医疗器械 质量管理体系 用于法规的要求》；GB/T 42062-2022《医疗器械 风险管理对医疗器械的应用》。 YY/T 0664-2020《医疗器械软件 软件生存周期过程》；YY/T 1406-2026《医疗器械软件 GB/T 42062应用于医疗器械软件的指南》（2027年3月1日实施）。 《医疗器械软件注册审查指导原则（2022年修订版）》；《医疗器械网络安全注册审查指导原则（2022年修订版）》；《医疗器械可用性工程注册审查指导原则》（2024年）。 《呼吸机注册审查指导原则（2023年修订版）》（本文呼吸机软件场景参照）。
说明：本文为开发流程与质量管理实践介绍，不替代具体产品的适用性分析或注册申报要求；示例编号、报警逻辑均为教学示例。
03项检查、24项新增、21项未单列新版独立软件GMP到底变了什么？
2026-11-12
独立软件检查指导原则与通用医疗器械检查指导原则差异解读及企业实施指南
2026-11-12
2026-11-12
QP-0010_受控文件与技术文件控制程序_V1.0_（SAMD医疗器械独立软件体系文件）
2026-11-09
SCMP-HTV100A-001_院内转运呼吸机软件配置管理计划_A0（包含表单）
2026-10-23
2026-10-15
