CS系列课 | CSV计算机化系统验证全流程：3/4/5类各做什么？哪些文件能合并？

计算机化系统验证，CSV，CS，验证流程，验证活动，验证文件

关于计算机化系统验证（CSV），大家关心的不是如何高效做好验证，反而是最基础的问题：如何做验证？其实验证流程没有统一答案，关键是看系统属于哪一类，风险是什么。类型确定了，接下来是最实际的问题：验证该怎么走？每个阶段要准备什么文件？哪些文件必须做，哪些文件能合并？

今天我们来梳理一下CSV全流程，希望对大家有所帮助。全文核心要点：4类做基准，3类做减法，5类做加法。我们把每个阶段的流程和文件差异做了图表对比，希望能帮大家一眼看清差异，也方便保存下来对照使用。

关于计算机化系统（CS）怎么分类，我们在《CS基础六问：小白从入门到厘清核心概念》里已经聊过（欢迎点击阅读）。

4类：验证流程的“基准线”

以4类可配置软件(如ERP、LIMS)为基准，介绍典型的验证流程，如图：

文件说明：

验证计划（VP）：用于定义验证策略，说明所需要开展的全部验证活动、遵循的质量管理体系以及实施计划等。
用户需求说明（URS）：用于记录用户对系统的所有需求，包括业务需求、技术需求、合规需求等等。用户需求也是PQ的可接受标准。
质量项目计划：面向欧美合规性的验证项目，有时候需要准备这份文件。该文件从项目管理的角度，说明供应商的QMS和项目管理。如果系统不涉及外部供应商，通常不需要考虑这份文件。
设计文档：通常包括功能设计和详细设计。功能设计采用通俗易懂的语言，说明系统设计是如何响应用户需求的；详细设计需要包括硬件、软件、网络等各项技术细节。
设计确认（DQ）：提供文件化的证据，证明系统设计充分考虑了用户需求。在设计文件批准后，即可实施设计确认。
风险评估报告：后续确认活动中的测试项，需要基于风险评估来确定；用户需求和设计文件批准后，风险评估也可以基于这些信息开展，编写风险评估报告。
工厂验收测试（FAT）& 现场验收测试（SAT）：大部分工艺自动化相关的系统都需要开展FAT和SAT，因为这些系统通常涉及供应商在工厂端的活动。对于纯软件类的系统，例如文件管理系统、ERP等常见的B/S架构软件，FAT和SAT可能并不适用。（需要注意的是：FAT和SAT的开展需要考虑项目的实际情况，但这个策略需要在VP中进行说明。）
安装确认（IQ）：静态检查，用于确认系统的安装、配置与连接等符合系统的设计，确保系统在运行起来之前，所有的条件都是满足的，避免运行的时候出现错误。
运行确认（OQ）：动态测试，用于确认系统的各项功能符合系统设计。通常需要覆盖到所有的关键功能模块。复杂系统特定的功能测试很多时候需要使用虚拟数据，确保高覆盖率，把特殊情况都要测试到。
性能确认（PQ）：用于确认系统符合预期用途。它以系统各项功能正确为前提，结合或者模拟实际业务进行测试，评价系统的业务需求符合性和稳定性。
风险评估审核报告：结合已开展的控制措施，对各项风险进行审核评价，生成风险评估审核报告。
需求追溯矩阵：结合需求在各阶段的追溯响应情况，完成需求追溯矩阵，对比VP。
验证总结报告：结合全部开展的活动和批准的文件，汇总形成验证总结报告，对系统的放行状态进行评价。