1. 课程导入与法规全景

医疗器械软件（Medical Device Software，MDS）一旦进入注册或备案状态，其任何改动都不再是单纯的研发行为，而是一次可能触发监管动作的合规事件。理解这一点，是学习本课程的前提。很多团队在软件迭代时习惯用互联网产品的思维处理需求：小改动直接合并、大改动排期上线。但在医疗器械领域，一个看似微小的算法阈值调整、一句提示文案的修改、一次依赖库的升级，都可能改变产品的安全有效性结论，进而需要重新评估、重新验证，甚至重新注册。

监管的底层逻辑并不复杂：医疗器械上市许可的核心是"经确认的安全有效性"。软件作为器械的一部分（或作为独立软件器械SaMD），其变更管理的目的就是持续证明——变更之后，产品仍然满足原先获批的安全有效性要求，或者新的要求已被充分验证。因此，变更不是被禁止的，而是必须被"看见、评估、控制、记录"。

法规全景：从通用质量体系到软件专项要求

与软件变更直接相关的法规与标准构成一个多层结构。最上层是各国监管机构的注册与变更审批要求，例如中国NMPA的《医疗器械注册与备案管理办法》《医疗器械变更注册（备案）管理办法》，美国FDA的510(k)、De Novo、PMA及对应变更指南，欧盟MDR下的重大变更判定。中间层是质量体系要求，如ISO 13485和中国的《医疗器械生产质量管理规范》，它们规定了变更控制程序必须存在并有效运行。最贴近工程实践的是软件专项标准：IEC 62304（医疗器械软件生命周期过程）定义了软件安全分级（A/B/C）和变更后的活动要求，ISO 14971（风险管理）要求变更必须重新进入风险分析循环，IEC 82304-1针对独立软件产品，FDA的《软件变更指南》和IMDRF的SaMD文件则给出了更细的判定路径。

这些文件不是并列的清单，而是层层收窄的约束链：法规决定"要不要报、报什么"，质量体系决定"流程怎么走、记录怎么留"，技术标准决定"具体做哪些分析、验证到什么程度"。本课程后续章节会沿着这条链逐层展开。

核心术语：变更、影响分析、控制工程

变更（Change）在医疗器械语境下，指对已批准或已放行产品的任何修改，包括设计、材料、软件、标签、生产工艺等。软件变更的常见来源包括：需求新增或修改、缺陷修复、算法优化、第三方组件升级、运行环境适配、界面调整、日志与提示信息修改。需要特别注意的是，变更的"大小"不由代码行数决定，而由其对安全有效性的潜在影响决定。修改一行阈值判断，可能比新增一个报表页面风险更高。

影响分析（Impact Analysis）是变更控制的核心环节，其任务是系统性地回答三个问题：这次变更会影响哪些对象？影响的性质和严重程度如何？需要采取哪些措施来消除或降低风险？影响分析不是凭经验拍脑袋，而是沿着"需求—架构—模块—接口—风险控制措施—验证用例"的追溯链逐项排查。IEC 62304要求，变更后必须评估软件安全分级是否改变、架构是否受影响、已识别的风险控制措施是否失效、哪些测试需要重跑。

控制工程（Control Engineering）在这里不是指自动控制理论，而是指把变更管理当作一个受控的工程过程来建设：有明确的触发条件、有标准化的评估方法、有可执行的验证策略、有完整的记录与追溯、有变更后的持续监控。控制工程的目标是让变更"可预测、可重复、可审计"，而不是依赖某个资深工程师的个人判断。

课程目标与学习路径

本课程面向医疗器械软件研发、质量、法规注册和测试人员，目标是让学员能够独立完成一次规范的软件变更影响分析，并输出符合监管要求的变更控制记录。学习路径分为四个阶段：

• 基础认知阶段：建立法规全景和术语体系，理解变更为什么必须受控，明确不同安全分级（A/B/C）对变更活动的差异化要求。
• 分析能力阶段：掌握影响分析的方法，包括追溯链梳理、风险再评估、接口与依赖分析、变更分类判定（重大/轻微/无需注册）。
• 控制实施阶段：学习变更控制程序的设计与执行，包括变更申请、评审、验证策略制定、回归测试范围确定、文档更新与追溯。
• 实战与复盘阶段：通过典型案例（如算法阈值调整、第三方库升级、界面文案修改）演练完整闭环，并学习如何应对监管问询和审计。