不是工作量一刀切减少，而是基于风险重新分配验证资源。

2026年2月3日，FDA正式发布《生产和质量管理系统软件的计算机软件保证（CSA）》指南最终版，替代2025年9月版指南。而在它生效的前一天——2026年2月2日，FDA质量体系法规（QMSR）也已正式实施，全面接轨ISO 13485:2016。

两份文件前后脚落地，宣告一件事：医药和医疗器械行业沿用了二十多年的"CSV（计算机化系统验证）时代"，正在让位于"CSA（计算机软件保证）时代"。

很多同行第一反应是："是不是以后可以少测试、少写文档了？"

这恰恰是最危险的理解。CSA不是给验证"松绑"，而是把验证资源从"低价值重复劳动"重新配置到"真正影响患者安全的地方"。理解错了方向，轻则审核时被开不符合项，重则把风险敞口留在了生产线上。

这篇文章基于FDA指南原文和国内标准体系，把CSA的核心逻辑和几个最容易踩坑的重难点讲清楚。

 

一、先看清楚：两份文件到底改了什么

第一份：QMSR（21 CFR Part 820修订），2026年2月2日生效。

FDA删除了原Part 820的大部分条款（包括我们熟悉的820.70），改为直接引用ISO 13485:2016。这意味着"软件确认"的法规出处从原来的820.70(i)变成了ISO 13485的三个子条款：4.1.6（质量体系软件）、7.5.6（生产和服务提供软件）、7.6（监视和测量软件）。

 

第二份：CSA指南最终版，2026年2月3日发布。

这份指南替代了FDA 2002年《软件验证通用原则》（GPSV）中"自动化过程设备与质量体系软件验证"章节（Section 6），是FDA对"生产和质量体系软件到底怎么验证"的最新官方表态。

一句话概括CSA的定义：一种基于风险的方法，用于建立并保持"软件适合其预期用途"的信心，并使软件在全生命周期内保持受控的"已验证状态"（validated state）。

它遵循FDA一贯的"最小负担原则"（least-burdensome）——验证的工作量不超过风险所需要的程度。

 

二、CSV与CSA：差的不是测试量，是思维方向

维度

传统CSV

CSA

出发点

证明"文件齐全、测试覆盖"

证明"软件适合预期用途"

风险定位

常按系统整体定风险

按功能/操作逐个定风险

测试方式

以脚本化测试为主

脚本化与非脚本化测试按风险选用

证据形式

截图、纸质记录堆叠

鼓励系统日志、审计追踪等数字化记录

供应商工作

常重复验证供应商已做的工作

在采购控制框架下利用供应商的验证结果

文档量

与风险关联弱，容易"一刀切"

与风险严格成比例

注意最后一个区别——CSA从来没有说"取消文档"。指南原文的表述是：文档不需要超过"证明该功能按预期运行"所必需的程度。换句话说：减掉的是冗余，不是证据。

FDA在指南里给了一个很直观的对比：同样是COTS电子表格软件，如果你只是用它"记录固化工序的时间和温度读数"，那么供应商评估＋安装配置可能就够了；但如果你在里面写了自定义公式，用来自动计算时间-温度统计量并监控工序性能，那就存在数据完整性方面的新风险，需要做额外的验证。

同一个软件，不同的预期用途，不同的验证深度——这就是CSA的底层逻辑。

 

三、CSA六步风险框架：流程不难，判断很难

指南给出了一个六步框架，骨架很简单：

明确预期用途（Identifying the Intended Use）

确定基于风险的方法（Determining the Risk-Based Approach）

处理软件变更（Software Changes）

确定适当的保证活动（Determining the Appropriate Assurance Activities）

其他考量（Additional Considerations，利用现有控制）

建立适当的记录（Establishing the Appropriate Record）

真正难的，是每一步里的判断题。下面四个重难点，是企业落地时最容易出错的地方。

 

重难点一："高过程风险"的判定——CSA的第一道分水岭

CSA风险框架的核心判定只有一个问题：这个功能如果失效，会不会产生一个"可预见地损害安全性"的质量问题？

是 → 高过程风险（high process risk），保证活动要和"医疗器械风险"相称；

否 → 非高过程风险，保证活动只需和"过程风险"相称。

指南列举了典型的高过程风险功能，值得每个企业对照自查：

维护影响产品物理特性或对器械安全至关重要的过程参数（温度、压力、湿度等）；

在很少或没有人工复核的情况下，对产品或过程进行测量、检验、分析或判定合格与否；

基于数据监测或自动反馈，在无人复核的情况下自动纠正、调整过程参数；

生成患者和用户必需的安全使用信息（如使用说明书）；

自动化监测、趋势分析对器械安全至关重要的数据（如网络安全监视）。

对应地，CAPA流转、投诉自动记录、变更控制自动化、仅用于监控的数据采集等，通常不属于高过程风险。

这里的坑在于：FDA特别说明，CSA的风险分析不等于ISO 14971的医疗器械风险分析。CSA风险分析关注的是"哪些因素可能导致软件无法按预期运行"——系统配置与管理、安全性、数据完整性、数据存储与传输、操作错误。两者的风险框架、方法、输出都不能简单互相替代。

指南里还有一个非常精彩的对比案例，两个ERP系统的物料补货功能：

A系统的功能只负责自动订料和送料，有资质的人员在投产前还会核对物料——失效只会造成混料这种质量问题，但会在人工核对时被拦截，不会"可预见地损害安全"→ 中等过程风险，做与过程风险相称的验证即可；

B系统同样自动订送料，但连投产前的物料核查也一并自动化了，无人复核→ 一旦失效，混料会直接进入生产 → 高过程风险，验证深度要向医疗器械风险看齐。

同一个功能，一个下游人工控制点的有无，决定了两档完全不同的验证深度。"过程里还有没有人在看"，是判定高过程风险时最实用的试金石。

另外，指南允许企业把风险定为"中等""中等偏低"等中间档位；但在保证活动策略判定上，FDA指南采用二元逻辑——只有判定为"高过程风险"走对应高保证路径，其余全部归入非高过程风险路径执行。企业内部的风险分级标签可以和CSA策略对接，但不必与FDA的二分逻辑混淆。

 

重难点二：预期用途的界定——比你想的更"细"

第一步"明确预期用途"远不是写一句系统描述那么简单。指南要求把软件拆解到**功能特性（feature）、功能（function）、操作（operation）**的粒度，逐个判断它是否被用于生产或质量体系，以及是"直接用于"还是"用于支持"：

直接用于：自动化生产过程、检验、测试、生产数据采集处理；自动化QMS过程、维护质量记录。

用于支持：开发工具、测试脚本工具、生产设备内嵌固件、非质量记录的一般性记录管理。

一般不在范围内：邮件、财务等与生产/QMS无关的业务软件；通用基础设施（网络、用户认证、备份）。

云端部署让这道题变难了。指南明确：SaaS、PaaS、IaaS都在CSA框架的考虑范围内，但不能一概而论。同样是IaaS云存储：

如果用来存放质量记录 → 直接用于QMS，保证工作要聚焦记录完整性和Part 11相关功能；

如果只是存放生产过程数据（不构成质量记录）→ 不算支持QMS，13485的验证条款不适用，按最小负担原则处理即可。

企业需要书面记录自己"判定某功能是否在范围内"的决策过程——这句话是指南的明确建议，也是审核时最容易被追问的证据。

重难点三：测试方法的选用——非脚本化测试不是"随便测"

第四步是CSA给行业松绑最多的地方，也是误读最多的地方。指南认可的测试方法分两大类：

非脚本化测试（Unscripted Testing）——测试人员的操作不由书面测试用例规定：

场景测试（Scenario/Ad-Hoc Testing）：基于操作序列和交互路径来测；

错误推测（Error Guessing）：基于测试人员对历史失效和失效模式的经验来设计测试；

探索性测试（Exploratory Testing）：测试人员基于已有知识边探索边设计边执行，主动寻找隐藏的、非预期的用户行为。

脚本化测试（Scripted Testing）——测试用例事先记录，可手工或自动执行，分"完整脚本"和"简化脚本"两档。

选择的原则：高过程风险功能 → 脚本化测试或脚本化＋非脚本化的混合方案；非高过程风险功能 → 优先考虑非脚本化测试。

但指南同时强调了两点，很容易被忽略：

这是原则不是铁律。非脚本化测试也可能更适合某些高过程风险功能；反过来，把低风险功能的脚本测试自动化，可能更高效。判断标准始终是"基于风险的测试"原则本身。

非脚本化≠无记录。即使是没有测试计划的场景测试，指南Table 1仍然要求记录：预期用途、风险分析结果、所测功能和测试内容的概述、发现的问题、可接受性结论、执行人和日期。测可以"不写脚本"，但不能"不留证据"。

一个实用的心法：脚本化测试验证"你想到了的"，非脚本化测试发现"你没想到的"。高过程风险功能两头都要抓。 另外，非脚本化测试产出的记录不需要复刻传统完整测试脚本，但依然要满足可追溯、可复核——这是它和"随意测"的本质区别。

 

重难点四：证据的形态——从"截图时代"到"日志时代"

第六步"建立适当的记录"里，FDA说了一句在行业里可以算里程碑的话：

FDA建议采用数字化记录——系统日志、审计追踪以及软件自身生成和维护的其他数据——来代替纸质文档、截图，或重复复制软件中已有的数字化留存结果。

记录的核心要素被明确为六项：预期用途、风险分析结果、所做保证活动的描述（含发现的问题）、可接受性结论（有问题要写清解决措施或风险论证）、执行人和日期、必要时的审核批准。

这对企业是双重利好：一方面减少了海量的截图和纸质证据；另一方面把"验证记录"和"系统运行记录"打通了，审计追踪本身成为验证证据。但前提是你的电子记录控制（Part 11）要先过关——指南特别提示：Part 11《范围与应用》指南中针对旧版21 CFR Part 820体系下计算机化系统验证的执法裁量政策，不再适用于QMSR下基于ISO 13485实施的软件确认活动。但这并不豁免电子记录/电子签名对Part 11法规本身的合规义务，企业不能借用旧CSV时代的执法裁量，来规避ISO 13485要求下的软件确认工作。

此外第五步"其他考量"也值得展开：FDA明确允许企业利用QMS中已有的控制措施来降低软件保证的工作量——下游检验/测试、采购控制体系、过程参数监视、软件上线后的持续性能监测和数据监测、开发生命周期工具链等。对低风险功能，供应商评估＋安装配置甚至可能就是全部所需的保证。

 

四、一个容易被忽略的事实：国内早已埋好了接口

很多企业担心"CSA是不是只跟出口企业有关"。其实不然。

我国2022年发布、2024年1月1日实施的GB/Z 42217-2022《医疗器械 用于医疗器械质量体系软件的确认》（修改采用ISO/TR 80002-2:2017），在理念上与FDA CSA高度同源，甚至在某些方面更早一步：

它同样要求基于风险确定确认的严格程度和工作量，明确"工作量宜与风险相称"；

它引入了**"批判性思维"（Critical Thinking）**方法论——反对"一刀切"的确认方案，要求针对每个软件的使用场景选择最有意义的建立信任的活动；

它给出了完整的**"工具箱"体系**：从过程定义、过程失效风险分析、预期用途，到软件失效风险分析、可追溯性分析、各类测试工具，再到维护阶段的系统监视、回归分析、退役管理；

它的附录提供了14个覆盖不同风险等级的完整案例——从PLC、自动化焊接、灭菌器、视觉系统，到电子表格、校准管理软件、AVL供应商清单系统，甚至包括"一个看似不需要确认、实际酿成数据损坏的电子表格"这样的反面案例。

国内《医疗器械生产质量管理规范》及其配套文件对软件确认的要求，与GB/T 42061-2022（等同采用ISO 13485:2016）的4.1.6、7.5.6、7.6条款一脉相承——而这也正是FDA QMSR现在的法规基础。

换句话说：中美两套监管体系，现在锚定在同一个ISO条款上，指向同一种基于风险的确认哲学。 对企业而言，建立一套"以预期用途为起点、以风险分析为驱动、以批判性思维为方法"的软件确认体系，可以同时满足国内合规和国际趋势，这比分别维护两套体系高效得多。

 

五、企业落地自检：六个问题

如果你的企业正在规划从CSV到CSA的转型，建议先用这六个问题做一次摸底：

我们是否能逐个功能说清楚：每个软件的每个操作是"直接用于"生产/QMS，还是"用于支持"，还是不在范围内？有没有书面记录这个判定过程？

我们的风险分析是否区分了"过程风险"与"医疗器械风险"，而不是直接套用ISO 14971的模板？

对于"高过程风险"功能，我们是否识别了下游人工控制点的有无，并据此调整验证深度？

我们的测试策略里，有没有非脚本化测试的位置？非脚本化测试的记录是否完整？

我们是否建立了利用供应商验证结果、审计报告（如SOC报告）、认证证书的程序？

我们的验证记录里，还有多少是可以被系统日志和审计追踪替代的截图？

如果这六个问题里有三个以上答不上来，说明企业的软件确认体系还在"CSV惯性"里。

 

写在最后

CSA不是法规的放松，而是监管哲学的升级：FDA不再问你"测了多少、写了多少"，而是问你"风险在哪里、证据凭什么"。

对质量人来说，这既是挑战也是机会——经验、判断力和对过程的理解，将取代文档体力活，成为软件确认工作的核心价值。

 

参考文件

1.FDA, Computer Software Assurance for Production and Quality Management System Software（《生产和质量管理系统软件的计算机软件保证》）, Guidance for Industry and FDA Staff, February 3, 2026

2.FDA, Final Rule: Quality Management System Regulation（21 CFR Part 820，质量管理体系法规最终规则）, 89 FR 7496, effective February 2, 2026

3.GB/Z 42217-2022《医疗器械 用于医疗器械质量体系软件的确认》（修改采用ISO/TR 80002-2:2017）

4.GB/T 42061-2022 / ISO 13485:2016《医疗器械 质量管理体系 用于法规的要求

5.FDA, Part 11, Electronic Records; Electronic Signatures — Scope and Application（《电子记录；电子签名——范围与应用》）

 

 

 

 

本文由广州佳誉医疗器械有限公司/佛山浩扬医疗器械有限公司联合编辑