医疗器械计算机化系统验证（CSV）指南：软件确认范围、流程与测试怎么做

CSV（Computerized System Validation）常被译为“计算机化系统验证”。2025 版医疗器械 GMP 使用的直接表述是计算机软件确认：第 77 条要求，设计开发、生产、检验、仓储等过程中采用的软件如果影响产品质量，应在首次使用前确认，更改后按需要再确认，方法和活动与使用风险相适应，并保留记录和结论。

因此，企业不必为每一款办公软件套用同样厚的文件；也不能因为购买了知名 SaaS，就跳过自身用途和配置的确认。确认的目的，是用证据证明软件在企业的实际环境、用户、流程和数据下能够持续完成预定用途。

哪些系统需要纳入确认范围

先做软件清单和用途评估。通常优先关注：

电子批记录、生产执行、工艺参数采集；
检验、实验室数据、环境监测与设备校准；
物料批次、仓储状态和 UDI 追溯；
文件控制、培训、偏差 CAPA、变更和产品放行；
用于设计开发计算、风险分析或生成质量结论的软件。

普通邮件或排班工具若不产生、处理或控制质量关键数据，确认深度可以较低；电子表格若用于放行计算、趋势判断或检验结果，则可能属于高风险。判断依据是用途和失败影响，不是软件名称。

国家标准信息平台显示，GB/Z 42217-2022《医疗器械用于医疗器械质量体系软件的确认》为现行指导性技术文件，主管部门为国家药监局，可作为建立方法的参考；它不替代企业对适用法规和实际风险的判断。

一套可落地的 CSV 生命周期

1. 立项、范围和风险评估

明确系统边界、业务流程、接口、数据、用户和基础设施。评估失败可能导致的后果：能否放行错误产品、丢失原始数据、绕过审批、错配物料或中断追溯。风险越高，测试和复核越深入。

2. 用户需求说明（URS）

需求要可测试，避免只写“系统应安全可靠”。例如：“批记录批准后，普通用户不得修改；经授权更正时保留前值、后值、人员、时间和理由。”需求应覆盖权限、审计追踪、电子签名、备份恢复、报表、接口、性能和法规保存期。

3. 供应商与方案评估

了解供应商开发和测试能力、版本维护、安全与备份、缺陷处理、服务连续性和数据导出方式。供应商资料可以复用，但企业仍要验证自身配置、主数据、流程、权限和关键使用场景。

4. 配置、安装与测试

常见的 IQ/OQ/PQ 是行业实施方法，并非要求所有系统机械套用同一模板：

安装或配置检查：版本、环境、组件、账号和配置基线正确；
功能与控制测试：正常、边界、异常、权限、日志和恢复场景符合需求；
业务流程测试：由代表性用户以真实流程证明系统适合预定用途。

高风险功能应保留测试步骤、预期结果、实际结果和原始证据。测试失败要记录、评估、修复并重新测试，不能从报告中删除。

5. 数据迁移与接口确认

迁移不是“导入成功”就完成。应核对记录数量、关键字段、版本、附件、签名、历史审计信息和关联关系，并处理重复、缺失或格式转换。与设备、ERP 或 UDI 系统的接口还要测试传输失败、重复消息和补传机制。

6. 报告、批准与上线

总结需求覆盖、测试偏差、残余风险和使用限制，由业务、质量和 IT 按职责批准。上线前完成程序、培训、账号授权、备份、应急方案和支持安排。

上线后还要持续保持确认状态

软件确认不是一次性项目。企业应管理版本升级、配置和权限变化，定期复核账号、审计追踪、备份恢复、故障和供应商通知。变更先进入变更控制，再按风险决定回归测试和再确认范围。

云服务更新频繁时，应在协议中明确更新通知、测试窗口、数据归属、导出、备份和退出方案。系统停机期间的纸质应急记录也要受控，并在恢复后与电子记录关联。

CSV 与数据完整性的关系

CSV 证明系统适合预定用途；数据完整性 ALCOA+关注数据全生命周期是否可信。系统通过了测试，不代表使用者以后不会共享账号或绕过流程；反过来，认真操作也弥补不了软件覆盖数据、日志缺失等设计缺陷。两者必须同时成立。

对于电子批记录，至少应重点测试模板版本、步骤顺序、物料和设备状态、计算、偏差触发、复核放行、审计追踪和备份恢复。

常见失败方式

直接把供应商宣传册当作 URS；
只截几张成功页面，没有异常和权限测试；
所有软件都标成“低风险”，却没有判断依据；
测试环境与生产配置不同，差异未评估；
升级后未走变更，也未做必要回归测试；
数据可以导入却不能完整导出，退出服务时无法保持记录可读。

小结

CSV 的核心不是文件数量，而是风险、需求、测试和结论之间能相互追溯。企业要证明的是“这套具体配置在这个具体用途下可靠”，而不是证明供应商的软件抽象地“很好”。

GMP Vital 可提供质量与生产流程的数字化载体；企业部署时仍应确定系统边界，基于风险完成软件确认，并在变更和运维中保持受控状态。