第二章 法规框架基础：FDA 21 CFR Part 11、EU GMP Annex 11、ICH Q7 解读

说实话，做生信Pipeline验证，最头疼的往往不是技术本身，而是搞不清楚「到底要验到什么程度」。我见过太多团队，要么把GxP那套全搬过来，把自己累死；要么觉得生信就是跑个软件，随便测两下就上线，结果审计出了大篓子。

所以，这一章我们得把法规的老底翻出来看看。我会挑三个最常碰到的法规——FDA 21 CFR Part 11、EU GMP Annex 11、ICH Q7——带你捋清楚它们到底在讲什么，尤其在生信Pipeline这个场景下，哪些条款是绝对不能踩的红线。

2.1 FDA 21 CFR Part 11：电子记录与电子签名的硬杠杠

这个法规，我个人觉得是所有监管要求的「地基」。它主要管两件事：电子记录（你Pipeline跑出来的数据）和电子签名（谁批准的、谁执行的）。

核心要点：

• 系统验证：你的Pipeline得按预期工作。说白了，你得证明它能稳定产出正确的结果。
• 审计追踪：谁、什么时候、改了啥、原来是什么，都得记下来。我最开始做的时候，觉得审计追踪就是应付检查，直到有一次某个关键参数被误改，要不是有审计日志，根本查不出来。
• 权限控制：什么人能改参数，什么人只能看结果，得区分开。避免「一个人说了算」的情况。
• 数据保护：原始数据、过程数据、结果数据，都不能被随手删掉或改掉。

2.2 EU GMP Annex 11：计算机化系统的欧盟视角

这个法规是欧盟那边的，跟FDA Part 11算是「遥相呼应」，但细节上有点差异。你想想看，如果你Pipeline的数据要出口到欧洲，或者你们公司是欧盟背景的企业，那这个你就得熟读。

关键差异点：

• 风险评估：Annex 11特别强调要基于风险来定验证深度。不是说所有功能都要全量验证，而是看这个功能出错了风险有多大。比如，一个测序数据质控的参数，如果错了会不会导致假阳性结果？会的，那就得重点验。
• 数据完整性：跟Part 11一样，但Annex 11更直白——要能确保数据在整个生命周期里都是完整、一致、准确的。
• 定期审核：系统上线不是结束。你得定期回头看看，验证是不是还够用。我见过一个案例，某公司的Pipeline用了三年没做过回顾性验证，结果软件小版本升级了无数次，最后审计直接给了个严重缺陷。

2.3 ICH Q7：原料药GMP中的计算机化系统影子

如果你是做原料药（API）相关的生信分析，比如药物安全性预测、合成路线优化，那ICH Q7你就绕不开。它虽然主要是讲原料药生产的GMP规范，但第八节专门提到了计算机化系统。

对生信的影响：

• 方法转移：当你把一个成熟的生信Pipeline从一个服务器移到另一个，或者换了软件版本，需要验证转移后的等效性。
• 偏差管理：假如某次分析结果异常（比如QC不合格），你得有流程去调查，是生物问题还是Pipeline本身的问题。
• 变更控制：哪怕是改了一个小小的参考基因组版本，也可能导致后续分析结果全部偏移。I CH Q7要求变更必须走流程，评估影响，验证OK才能切换。

2.4 三大法规的核心逻辑框架

你会发现这三个法规其实都是在讲一件事——可信赖的数据。为了帮你快速理清，我画了一张图，把它们的逻辑串起来。

2.5 关键条款速览表

为了方便你以后查阅，我把这三个法规里最常被审计官问到的条款整理了一下。你可以在做验证计划时，对着这张表一条一条地勾。

2.6 避坑指南：初学者常犯的三个错误

嗯，说到避坑，我自己走过来的经验还是挺有发言权的。这里列三个最容易中招的地方：

1. 把「参数调优」跟「验证」混为一谈
   我曾经见过一个团队，花了三个月在调BWA的比对参数，然后说「我们验证完了，比默认参数效果好」。可是流程上、权限上、文档上呢？验证不是调参，验证是证明系统在一个受控状态下能稳定运行。
2. 认为开源软件不需要验证
   这是个伪命题。你可能觉得「别人用了那么多次，肯定没问题」。但审计不会看这个，他只问你：「你有证据证明你的这个版本、在这个操作系统、在这批数据上，运行结果是正确的吗？」拿不出证据，就是不符合。
3. 忽视操作系统和依赖库的版本影响
   我记得有一次升级了服务器上的Python版本，从3.8升到3.9，结果某个依赖包没跟上，导致Variant Calling那一步的排序变了。虽然从生物学角度看结果还行，但从数据完整性角度看，这就是一次未经验证的变更。后来我们的验证范围必须包含整个软件栈。