ARTICLE · 1251100
独立软件 GMP 落地指引
——基于《独立软件检查指导原则（征求意见稿）》的内部对标与整改手册
文件性质说明：本指引为企业内部体系参考文件，编写依据为《医疗器械生产质量管理规范独立软件检查指导原则（征求意见稿）》（国家药监局综合司，2026-09-30 发布，征求意见截止 2026-10-13，以下简称"征求意见稿"）。该稿尚未生效，仅用于提前对标、预留整改窗口，不构成合规承诺。
0. 文件说明与适用边界
0.1 依据与版本脉络
文件 | 文号 / 时间 | 状态 | 在本指引中的作用 |
《医疗器械生产质量管理规范》（新修订） | 国家药监局公告2025年第107号；2025-11-04发布，2026-11-01施行（替代2014年64号公告） | 现行上位规范 | 征求意见稿对接的规范正文 |
《医疗器械生产质量管理规范检查指导原则》 | 国药监械管〔2026〕14号；2026-11-01施行（替代食药监械监〔2015〕218号） | 现行上位检查指导原则 | 检查判定与处置依据 |
《医疗器械生产质量管理规范附录独立软件》 | 国家药监局2019年第43号通告；2020-07-01实施 | 现行有效 | 独立软件与软件组件适用关系的法规源头 |
《医疗器械生产质量管理规范独立软件现场检查指导原则》 | 药监综械管〔2020〕57号；2020-05-29发布 | 现行执行 | 企业当前现场检查依据（11章105条） |
《独立软件检查指导原则（征求意见稿）》 | 国家药监局综合司2026-09-30；截止2026-10-13 | 征求意见中，未生效 | 本指引对标对象（203项） |
版本变化要点：检查项目由 2020 版 11 章 105 条，扩展为 203 项，并划分风险等级——关键项目（***）41 项、主要项目（**）95 项、一般项目（*）67 项。
特别提示：2026 年两份文件须严格区分——《医疗器械生产质量管理规范》（国家药监局公告2025年第107号）为规范正文；《医疗器械生产质量管理规范检查指导原则》（国药监械管〔2026〕14号）为其配套的检查判定与处置指导原则，二者均自 2026-11-01 施行。
0.2 重要合规提示（红线）
·征求意见稿尚未生效，企业当前仍按 2020 版（药监综械管〔2020〕57号）及《独立软件附录》（国家药监局2019年第43号通告）执行。
·本指引用于企业提前对标、预留整改窗口，不代表现行强制要求，不构成合规承诺。
·凡标注"（征求意见稿，未生效）"的条款，落地优先级以企业风险自评为准，但建议不晚于 2026-11-01 新修订 GMP 施行前完成文件对标与差距整改。
0.3 适用边界：独立软件与软件组件
依据《医疗器械生产质量管理规范附录独立软件》（国家药监局2019年第43号通告）1.1 条："本附录适用于独立软件，软件组件参照执行。"这是"独立软件 + 软件组件"双主线的法规源头。
类别 | 必备特征 | 典型形态 | 检查关注重心 |
独立软件 | ①医疗用途 ②无需医疗器械硬件即可完成预期用途 ③运行于通用计算平台 | 通用型（如 PACS）、专用型（如 Holter 分析软件） | 软件本身的全生存周期 |
软件组件 | ①医疗用途 ②控制（驱动）硬件 或 运行于专用（医用）计算平台 | 嵌入式（如心电图机固件）、控制型（如 CT 图像采集工作站） | 与硬件的接口、整机系统验证确认 |
注意：专用型独立软件随硬件注册时视为软件组件；本条直接决定第 1 部分"哪些活动可简化、哪些不可省"。软件定义援引《医疗器械软件注册技术审查指导原则》（2015 年第 50 号通告）。
0.4 本指引使用方法
·质量负责人/管代：以第 4、5 部分做差距评估与自查。
·体系工程师：以第 2、3 部分搭建/修订程序文件与技术文件。
·软件负责人：以第 1 部分核对独立软件与软件组件的活动颗粒度。
1. 独立软件与软件组件各应注意哪些事项
维度 | 独立软件应做 | 软件组件（嵌入式/控制型）应做 | 可简化项 | 不可省略项 |
需求分析 | 形成 SRS 及评审记录；覆盖法规/标准/用户/功能/性能/接口/UI/网络安全/警示；可追溯性 需求-风险、需求-产品需求 | SRS 可并入整机需求，但须明确软件部分需求；接口需求须含硬件交互 | 可不与硬件无关的通用需求单列 | 软件需求与整机需求的接口边界、可追溯性 |
设计 | 形成 SDS；含架构/功能/性能/算法/接口/UI/单元/网络安全 | 设计须与硬件架构协同；明确软硬件接口协议 | 单元级设计文档可并入整机设计 | 软硬件接口设计、整机层面的功能分配 |
编码 | 依 SDS 编写；源代码与注释符合编码规则文件；测试用例保证充分性 | 依 SDS；嵌入式须考虑资源约束、实时性 | 编码规则可沿用整机开发规范 | 源代码-设计、源代码-测试用例的可追溯 |
验证 | 源代码审核、静态/动态分析、单元/集成/系统测试；白盒覆盖率与安全性级别相适宜 | 单元测试可结合硬件在环；须做集成与系统测试 | 纯软件工具链测试可简化 | 与硬件接口的集成测试、系统测试 |
确认 | 用户测试、临床评价、评审；涵盖现成软件与网络安全 | 以整机功能测试为主，用户测试可融入整机验证 | 独立用户测试可合并 | 整机系统验证确认、临床评价（如适用） |
配置管理 | 控制软件版本、源代码、文件、工具、现成软件；用配置管理工具贯穿全过程 | 须将软件纳入整机配置管理 | 工具可共用 | 软件版本、源代码的独立可控 |
可追溯性 | 控制程序+报告+工具，贯穿全过程，涵盖现成软件、网络安全 | 须建立软件需求↔硬件需求↔整机需求 的追溯链 | 报告粒度可适配整机 | 关键安全功能的端到端追溯 |
版本控制 | 命名规则涵盖软件/现成软件/网络安全全部更新类型，字段无歧义 | 软件版本须与硬件版本联动标识 | 命名可纳入整机版本规则 | 版本变更须符合命名规则、可识别 |
现成软件 | 文件化确定风险管理/验证确认/缺陷/可追溯/更新/配置/文件记录/网络安全；遗留评估上市后数据；开源遵循许可 | 同样适用，但须评估对整机安全的传导影响 | 低风险现成组件可简化验证 | 缺陷管理、更新控制、许可合规 |
网络安全 | 事件应急、防护、交付全链条；应急响应文件化 | 须考虑与硬件/网络的边界防护 | 离线嵌入式可简化外部网络防护 | 数据安全、接口安全、事件应急 |
发布部署放行 | 发布文件化（创建/归档/版本标记/交付评估/病毒防护）；部署确定安装/设置/配置/培训；放行确定版本识别/安装卸载测试/完整性检查/批准 | 随硬件整机发布，软件放行作为整机放行子集 | 独立部署流程可简化 | 版本识别、完整性检查、放行批准记录 |
缺陷管理 | 评估/修复/回归测试/风险/配置/评审；缺陷分析报告与工具 | 须区分软件缺陷与硬件缺陷的归因 | 工具可共用 | 缺陷归因、回归测试、风险再评价 |
结论：软件组件在"纯软件工具链、独立用户测试、独立发布部署"上可适度简化，但与硬件接口、整机系统验证确认、整机功能测试、软硬件联合可追溯四项不可省略。简化须有文件依据，不得因"随硬件走"而完全缺失软件专项证据。
2. 企业如何落地
按"先定级、再建程序、配资源、跑通主线、补专项"的顺序推进。
步骤 | 关键活动 | 主要输出物 | 对应征求意见稿条款 |
① 定软件安全性级别 | 在采取风险控制措施之前，结合预期用途、使用场景、核心功能综合判定；仅可通过外部风险控制措施降低级别 | 软件安全性级别判定记录 | 2.3.2 |
② 建软件生存周期过程控制程序 | 覆盖需求分析、设计、编码、验证与确认、风险管理、缺陷管理、可追溯性、配置管理、文件与记录控制、现成软件使用、网络安全保证、评审 | 《软件生存周期过程控制程序》 | 2.3.8 |
③ 配人员与环境 | 明确软件负责人与职责；持续提供充分、适宜、有效的开发与测试环境并确保有效运行 | 岗位说明书、环境清单与维护记录 | 2.2.1（设备区域） |
④ 跑通主线 | 需求→设计→编码→验证→确认→发布→部署→放行，每环节留评审与记录 | SRS/SDS/源代码/测试报告/发布与放行记录 | 2.3.9–2.6.1 |
⑤ 现成软件专项 | 文件化确定全生命周期控制；遗留软件评估现有文件/上市后使用/投诉/不良事件/召回；开源遵循许可 | 现成软件清单与评估报告 | 2.3.7 |
⑥ 网络安全专项 | 文件化网络安全保证、事件应急响应（含验证、用户告知、召回） | 网络安全保证文件、应急响应预案 | 2.8.2 |
⑦ 配置与可追溯 | 用工具贯穿全过程；可追溯性分析报告覆盖现成软件、网络安全 | 配置库、可追溯性分析报告 | 2.3.4–2.3.6 |
⑧ 变更与委托控制 | 建立变更控制程序；委托研发/生产/外协/检验处于受控状态；外包供应商提前告知变更 | 变更控制程序、受托方管理文件 | 2.4.1、1.1.1 |
落地要点：
·步骤④中"验证"与"确认"须分离——验证回答"是否做对了（按需求）"，确认回答"是否做对了的产品（用户/临床）"。两者均须涵盖现成软件与网络安全。
·步骤③的环境包括开发工具链、测试环境、配置管理工具、病毒防护手段，须有有效性维护记录，避免"环境漂移"导致放行证据不可信。
·工具选型不强制，但须满足"贯穿全过程、可留痕、可追溯"的基本要求，并在配置管理程序中规定使用规则。
3. 需要修订/新增哪些体系文件
文件类型 | 文件名称 | 建设方式 | 对应条款 |
程序文件 | 《软件生存周期过程控制程序》 | 从零新增 | 2.3.8 |
程序文件 | 《软件配置管理程序》 | 新增/在文件管理中增补软件专章 | 2.3.4 |
程序文件 | 《软件可追溯性分析程序》 | 从零新增 | 2.3.6 |
程序文件 | 《现成软件使用控制程序》 | 从零新增 | 2.3.7 |
程序文件 | 《网络安全保证程序》 | 从零新增 | 2.8.2 |
程序文件 | 《软件发布/部署/放行程序》 | 从零新增 | 2.5.1、2.5.2、2.6.1、2.7.1 |
程序文件 | 《软件缺陷管理程序》 | 从零新增 | 2.3.17 |
程序文件 | 《软件安全性级别判定程序》 | 从零新增 | 2.3.2 |
程序文件 | 变更控制程序（委托/外包专章） | 在现有变更/采购程序中增补 | 2.4.1、1.1.1 |
技术文件模板 | 软件需求规格说明（SRS） | 模板新建 | 2.3.9 |
技术文件模板 | 软件设计文档（SDS） | 模板新建 | 2.3.10 |
技术文件模板 | 编码规则文件 | 新建/可沿用 | 2.3.11 |
技术文件模板 | 测试计划与报告（单元/集成/系统/用户） | 模板新建 | 2.3.12–2.3.15 |
技术文件模板 | 可追溯性分析报告 | 模板新建 | 2.3.6 |
技术文件模板 | 缺陷分析报告 | 模板新建 | 2.3.17 |
记录表单 | 安全性级别判定表、配置管理台账、发布/放行记录、部署记录、网络安全事件记录 | 从零新增 | 各对应条款 |
结论：8 个程序文件中多数从零新增；变更、采购、文件管理、生产管理四类现有程序须增补软件专章，避免"两套体系"割裂、软件活动游离于主体系之外。
4. 与 2020 版现场指导原则对比
维度 | 2020 版（药监综械管〔2020〕57号） | 征求意见稿（未生效） | 企业影响 | 优先级 |
条文形态 | 11 章 105 条，不分风险级 | 203 项，分***/**/*三级 | 检查更聚焦关键项，缺陷定级更清晰 | 高 |
结构体系 | 11 章（机构人员/厂房设施/设备/文件/设计开发/采购/生产/质控/销售售后/不合格品/不良事件） | 对齐新修订 GMP 章节，细化软件专项 | 文件架构须对齐新章节 | 中 |
适用主体 | 未显式单列委托 | 新增"独立软件注册人、受托生产企业"，委托研发/生产/外协/检验须受控（1.1.1 ***） | 受托方管理文件须补强 | 高 |
软件安全性级别 | 有要求但未前置 | 前置判定，且只能经外部措施降级（2.3.2） | 设计开发启动前须完成定级 | 高 |
现成软件 | 原则性要求 | 全生命周期控制，含遗留/开源（2.3.7） | 须建现成软件清单与评估 | 高 |
网络安全 | 较弱 | 事件应急、防护、交付全链条（2.8.2 等） | 须建网络安全保证与应急程序 | 高 |
配置/可追溯 | 原则性 | 工具化、报告化、贯穿全过程（2.3.4–2.3.6） | 须引入配置与追溯工具 | 中 |
发布部署放行 | 分散 | 文件化区分物理/网络交付（2.5.1、2.5.2、2.6.1、2.7.1） | 须建发布/部署/放行程序 | 中 |
4.1 过渡期行动建议（2026-11-01 前）
·以 203 项逐条映射现有体系，形成差距清单（建议 Excel 跟踪，含"现有/缺失/部分符合"三态）。
·优先闭环 4 个关键项（***）：主体责任、质量保证系统、变更控制、委托受控。
·完成安全性级别前置判定流程与现成软件、网络安全两项专项程序。
·待正式稿发布后，核对风险等级标注，修正本指引中"需核对官方原文"项。
5. 可直接套用的自查清单（覆盖关键项 ***）
序号 | 自查项 | 对应条款（征求意见稿） | 风险级 | 自查要点 | 证据/记录 |
1 | 质量安全主体责任落实 | 2.1.1 | *** | 是否明确独立软件注册人/受托方主体责任 | 组织架构、职责授权 |
2 | 质量保证系统建立 | 2.3.1（《规范》第九条） | *** | 是否有覆盖软件的质量保证系统文件 | QA 程序、内审记录 |
3 | 变更控制程序 | 2.4.1（《规范》第十条） | *** | 软件变更是否经程序控制、评审、留痕 | 变更申请/评审/实施记录 |
4 | 委托研发/生产/外协/检验受控 | 1.1.1 | *** | 受托方是否经审核、协议、监督 | 受托方名录、协议、审核报告 |
5 | 软件安全性级别前置判定 | 2.3.2 | 强化项 | 是否在风险控制前完成定级 | 级别判定记录 |
6 | 软件生存周期过程控制 | 2.3.8 | 主要 | 策划是否覆盖全部活动 | 开发策划文件 |
7 | 现成软件全生命周期控制 | 2.3.7 | 主要 | 是否有清单、评估、许可合规 | 现成软件台账、评估报告 |
8 | 网络安全事件应急 | 2.8.2 | 主要 | 是否有预案、验证、告知机制 | 应急文件、演练记录 |
9 | 软件发布与放行 | 2.5.1、2.6.1 | 主要/一般 | 发布/放行是否文件化、留批准记录 | 发布记录、放行批准 |
10 | 软件可追溯性分析 | 2.3.6 | 主要 | 是否贯穿全过程、含现成软件与网络安全 | 可追溯性分析报告 |
11 | 配置管理工具化 | 2.3.4 | 主要 | 是否用工具控制版本/源代码/文件 | 配置库、台账 |
12 | 缺陷管理闭环 | 2.3.17 | 主要 | 缺陷是否评估/修复/回归/再评价 | 缺陷分析报告 |
使用说明：序号 1–4 为征求意见稿明确标注的关键项目（***），须优先闭环；序号 5–12 为强化/高频项，具体风险等级以官方正式发布稿为准（本稿未生效，相关等级标注以正式稿发布后核对为准）。
附：引用法规清单
·《医疗器械生产质量管理规范》（国家药监局公告2025年第107号，2026-11-01 施行）
·《医疗器械生产质量管理规范检查指导原则》（国药监械管〔2026〕14号，2026-11-01 施行）
·《医疗器械生产质量管理规范附录独立软件》（国家药监局2019年第43号通告，2020-07-01 实施）
·《医疗器械生产质量管理规范独立软件现场检查指导原则》（药监综械管〔2020〕57号，2020-05-29 发布）
·《独立软件检查指导原则（征求意见稿）》（国家药监局综合司，2026-09-30 发布，未生效）
·《医疗器械软件注册技术审查指导原则》（2015 年第 50 号通告）
附：建议配套的记录清单（可直接建表头）
·软件安全性级别判定表：产品名称/型号、预期用途、使用场景、核心功能、判定级别、判定依据、判定人/日期
·现成软件台账：名称/版本、类型（遗留/开源/commercial）、使用方式、影响程度、风险控制措施、许可合规状态
·软件配置管理台账：配置项、版本号、基线日期、变更关联、责任人
·软件发布与放行记录：软件版本、完整性检查结果、安装卸载测试结果、放行批准人/日期
·软件部署记录：部署对象、安装/设置/配置内容、用户培训、验收标准与结果
·网络安全事件记录：事件描述、风险评价、应急措施、用户告知、召回决定
核心结论：征求意见稿将独立软件检查从"原则要求"升级为"分级、专项、工具化"的 203 项体系；企业应在 2026-11-01 前完成文件对标与专项程序补强，但当前现场仍以 2020 版及《独立软件附录》为准。本文件仅供内部对标参考，不构成合规承诺。
更多资料进入知识星球自行下载～～～
我们开放【72 小时完整试用】，浏览星球内容，看资料不满意可退，长按知识星球二维码诚意满满！！！
【长按下方二维码进入知识星球下载】
获益1：知识星球干货不间断更新～～～
获益2：加入知识星球，同步解锁IMA知识库，协助搭建workbuddy；
获益3：加入会员群和众多行业老师深度交流、共享经验，一站式获取专业干货与优质资源。
[知识星球内部分优质资源截图]
