LIMS 软件验证怎么做?CSV/CSA 落地与评审证据清单

很多机构上 LIMS 时，验收环节拿到的是一份厂商提供的"测试报告"，系统上线，事情就算完了。

等到认可评审被问到"你们这个系统的确认记录在哪""软件升级之前有没有做过变更确认"时，才发现手头只有验收单和一份厂商盖章的说明。

在 CNAS 的语境里，LIMS 的软件验证不是"买软件时附带的材料"，而是机构自己要能拿出来的证据。

一、先看清依据：准则到底要求了什么

很多机构以为软件验证是制药行业 GMP 的要求，跟检测机构没关系。其实 CNAS-CL01:2018 的 7.11 数据控制和信息管理直接写了这件事。

同时，7.11.2 还有一条非常关键的注2：

这句话是"减负条款"——它意味着不是所有软件都要做全套验证。用现成商业化软件、并且按其设计用途正常使用，可以视为已充分确认。真正要机构自己做确认的，是配置、集成和变更的部分。

二、别把软件验证和方法验证搞混

这两个词在实验室里经常被混用，对象完全不同。

两者不是一回事，也不能互相替代：方法验证做得好，不代表系统功能没问题；系统上线测试过了，也不代表方法适用。

三、验证深度由什么决定：不是所有系统做同一套测试

这是整篇文章最重要的一节。很多机构的软件验证之所以做成"负担"，是因为对所有系统用了同一个模板。

决定验证深度的三个因素：

1. 预期用途——这个系统承担什么功能？出具报告、存储原始记录、还是仅做台账管理？

2. 复杂度——功能是否复杂、集成是否多、配置是否深？

3. 风险——如果系统失效或数据被篡改，对结果有效性、客户、合规的影响有多大？

三者的组合决定"投入多少验证"。功能直接影响检测结果和报告完整性的系统（比如出报告、存原始记录的部分），验证要更充分；只做统计报表、内部台账的模块，验证可以简化。

四、GAMP 5 分类：一套可借鉴的风险分级工具

GAMP 5 是 ISPE（国际制药工程协会）发布的指南，第一版 2008 年，第二版 2022 年 7 月。它是指南而非法规，但在国际上是软件验证最常被引用的框架。

需要说明：GAMP 5 的出发点最初是制药行业，对第三方检测机构来说它是"可借鉴的方法"，不是强制要求。不过它对"怎么按风险分配验证工作量"的思路，很值得参考。

第二版仍在使用的软件类别是 1、3、4、5 四类（类别 2 在 GAMP 5 中已废除，早期版本用于指固件；如果你们的验证计划里还有"类别 2"，说明参照的是更早的版本）。

对检测机构来说，LIMS 通常落在类别 4——厂商写平台，你们做配置。但有两个实操要点：

• 一个系统可以包含多个类别。 一个类别 4 的 LIMS，如果配了自定义报表生成器或自研接口，那这些组件是类别 5，需要更高的验证投入，但平台本身不因此升级。

• 分类必须写下理由。 分类是整个验证工作量的起点——评审员如果不同意你的分类，下游的东西都会受到质疑。所以分类判断要落在验证计划里，并写明依据。

五、关于 IQ/OQ/PQ：可以借鉴，不要照搬

制药行业的 CSV 常讲 IQ（安装确认）、OQ（运行确认）、PQ（性能确认），对应 GAMP 的 V 模型：

• URS（用户需求）↔ PQ（性能确认）

• FS（功能规格）↔ OQ（运行确认）

• DS（设计规格）↔ IQ（安装确认）

V 模型的价值在于可追溯：每一条需求都有对应的测试，每一个测试都能追溯到需求。

但对检测机构来说，不必照搬制药的全套文件结构。务实的做法是：

• 保留 V 模型最核心的东西——URS 和可追溯矩阵（需求能否被验证覆盖）；

• IQ/OQ/PQ 的内容和深度按风险和类别裁剪，不必每个系统都拆三份协议；

• 测试方式可以灵活（这一点下面讲 CSA 时会展开）。

六、CSA：可以借鉴的另一个方向

FDA 于 2025 年 9 月 24 日正式发布最终指南《Computer Software Assurance for Production and Quality System Software》（计算机软件保证）。这份指南：

• 取代了 2022 年的草案版本；

• 正式取代了 FDA 2002 年《General Principles of Software Validation》的第 6 节（自动化过程设备和质量体系软件的验证）。

必须说明适用范围：这份指南面向的是医疗器械生产与质量体系软件。对第三方检测机构来说，它不是强制要求，但其中几个思路值得借鉴：

需要特别提醒：CSA 强调"减少不必要的文档"不等于"减少验证"——它把工作量从"全体一致的走流程"转向"把力气用在真实风险上"。如果把它理解成"可以少做点"，方向就错了。

七、文档清单：哪些必须有、哪些可以合并

下表是一套可裁剪的文档清单。"必要性"一栏按检测机构的实际评审场景给出，不是制药口径的照搬。

八、上线之后：变更触发再验证，定期做回顾

系统上线不是终点。CL01:2018 7.11.2 明确：任何变更，包括修改软件配置或现成的商业化软件，在实施前应被批准、形成文件并确认。

这意味着每一次变更都要回答三个问题：

1. 这次变更影响什么功能？（影响范围）

2. 要不要重新确认？确认到什么程度？（再验证范围）

3. 变更前后需不需要留痕、能不能回退？（受控性）

典型场景：

此外建议做定期回顾：每年结合管理评审，回顾系统运行情况、变更记录、异常与数据完整性事件——这部分可以并入管理评审的输入项。

九、评审证据清单（10 项）

如果明天就要迎评审，下面 10 项是围绕 LIMS 最可能被要的材料：

1. URS / 采购技术需求，以及它与测试的对应关系

2. 验证计划与风险评估（含系统分类及理由）

3. 配置说明（类别 4 系统的核心）

4. 测试方案与测试记录/报告

5. 可追溯矩阵（需求 ↔ 测试）

6. 供应商评估/审计记录（对应 7.11.4）

7. 变更确认记录（每一次变更的批准、文件、确认）

8. 权限与访问控制记录（对应 7.11.3 a）

9. 审计追踪与数据备份/恢复的验证记录（对应 7.11.3 b、d）

10. 系统失效与应急处置记录（对应 7.11.3 e）

最后

LIMS 的软件验证，本质上是一道"证据题"：你能不能用记录证明，这个系统在你的场景下适合你的用途。

它不需要照搬制药的全套文件，也不等于让厂商多盖几个章。真正需要机构自己做的，是把三件事说清楚——我配置了什么（配置说明）、我怎么证明它能用（测试与可追溯）、我改了之后怎么保证它还可靠（变更确认）。

这三件事做到位，评审查软件验证这一块，基本不会成为问题项。