3. CFR Part 58 非临床实验室研究良好实验室规范（GLP）

21 CFR Part 58，圈内人通常直接叫它 GLP。它是 FDA 对非临床实验室研究的硬性法规。说白了，就是用来确保实验室数据真实、完整、可追溯的那套规矩。我刚入行时觉得这些条条框框太死板，后来在一次内部模拟审计中，亲眼看到因为原始记录涂改不规范，整批毒理数据被质疑——嗯，从那以后我再也不敢轻视 GLP 了。

你可能会问，GLP 跟生信流程验证有什么关系？关系大了。FDA 要求所有支持药物申报的非临床数据，包括生信分析结果，都必须在 GLP 合规的环境下产生。换句话说，你的生信流程如果不能证明它符合 GLP 对数据完整性和可追溯性的要求，那分析结果 FDA 是不认的。

3.1 什么是 GLP？为什么它绕不开？

GLP 最早在 1970 年代提出，目的是打击实验室数据造假。当时爆出不少丑闻，FDA 一怒之下制定了这套规范。它的核心就一句话：所有非临床研究数据必须能被完整追溯、独立复核。

适用范围包括毒理学、药理学、安全药理学等非临床研究。只要你的数据会用于 FDA 的 IND 或 NDA 申报，实验室环境就必须符合 GLP。很多生信团队觉得 GLP 是实验室的事，跟计算机分析无关——这是大错特错。

3.2 GLP 核心要素概览

整个 21 CFR Part 58 有十几条子项，但真正在生信验证中天天打交道的，集中在六个方面。我习惯把这六个要素画成一张图来记，每次做验证方案时对着它检查，不容易漏项。

这张图我每次做验证方案时都会对照一遍。你注意到底部那四个词没有？数据完整性、可追溯性、独立复核、电子记录合规——这四条是 GLP 对生信验证最直接的约束。

3.2.1 组织与人员

GLP 要求实验室必须明确研究负责人、试验人员、质量保证人员的职责。生信团队也一样。谁负责写流程？谁负责验证？谁负责审核？这些角色必须分开，不能一个人既是运动员又是裁判。

我建议你在项目启动前就建一个 角色职责矩阵，把每个人的 GL P 角色写清楚。FDA 审计时第一个查的就是这个。

3.2.2 设施与设备

别以为 GLP 的「设施设备」只指离心机和培养箱。你的服务器、工作站、存储阵列，全部算设备。需要做环境监控（温度、湿度、电力）、定期校准、维护记录。

3.2.3 标准操作规程（SOP）

SOP 是 GLP 的骨架。每项操作都必须有书面规程，生信流程更不例外。从数据导入、质控过滤、比对统计到结果输出，每一步都需要对应的 SOP。

SOP 的写法有讲究：要写清楚操作步骤、预期结果、异常处理、版本号、生效日期。我见过不少团队把 SOP 写成技术文档，但 FDA 要的是操作指引，不是原理说明。

文档编号: SOP-BIO-003
版本号: 2.1
生效日期: 2024-06-15
标题: RNA-seq 数据质控与比对流程操作

1. 目的
   规定 RNA-seq 原始数据从 FASTQ 到 BAM 的标准操作。

2. 适用范围
   所有用于 IND 申报的肿瘤转录组分析项目。

3. 操作步骤
   3.1 使用 FastQC v0.12.1 对原始 FASTQ 进行质控
   3.2 使用 Trimmomatic v0.39 去除接头和低质量碱基
   3.3 使用 STAR v2.7.10b 比对至参考基因组 GRCh38
   3.4 使用 samtools v1.18 排序并建立索引

4. 异常处理
   若比对率低于 80%，暂停分析并通知研究负责人。

5. 记录保存
   运行日志、参数文件、质控报告归档至项目共享目录。

3.2.4 测试系统

在 GLP 语境下，测试系统可以是动物、细胞系或化学物质。生信领域的「测试系统」就是你的 数据集和参考标准。比如用于验证的参考样本、掺入 spike-in 的阳性对照数据，它们的来源、批次、存储条件都必须记录。

我曾经在一个项目里发现验证用的参考数据来自内部测试集，没有正式的来源认证——审计时被开了观察项。后来我们给每套参考数据都建立了「来源证书」，类似细胞系的 COA。

3.2.5 数据与记录

这是生信验证与 GLP 交集最密集的地方。GLP 要求所有原始数据必须 实时、准确、清晰、可追溯。对于生信来说，原始数据就是 FASTQ、运行日志、参数配置文件、中间结果。

记录的形式可以是电子记录，但必须满足 21 CFR Part 11 的电子记录要求（下一章会细讲）。这里你只需记住：任何手动修改都必须留审计追踪，不能直接覆盖原始文件。

3.2.6 质量保证单元（QAU）

QAU 是 GLP 的「纪检委」。它独立于研究团队，直接向实验室管理层汇报。在生信验证中，QAU 的角色由验证工程师或独立的 QA 人员承担。

QAU 的工作包括：审核验证方案、抽查原始数据、检查 SOP 依从性、出具审计报告。我建议生信团队在验证过程中就主动邀请 QA 参与，不要等验证做完了再补审计——那样发现问题返工成本太高。

3.3 GLP 对生信流程验证的具体要求

好了，六个要素都过了一遍。咱们重点看看生信验证中最容易踩坑的几条。

GLP 要素	对生信验证的具体要求	常见违规点
数据与记录	原始数据不可篡改，分析过程可完全重现	只保存最终结果，丢弃中间文件和日志
SOP	每步分析有书面规程，版本受控	SOP 与实际运行命令不一致
测试系统	参考数据来源可追溯，版本固定	使用未经认证的公共数据集
质量保证	验证过程有独立复核和审计记录	验证和开发是同一人，缺少独立审核
设施与设备	计算环境一致性受控，有维护记录	软件依赖升级后未重新验证

这个表格是我做验证方案时对照的检查清单。每完成一项就打个勾，审计前心里有底。

3.4 实战经验与避坑指南

聊了这么多理论，说几个我亲身踩过的坑吧。

第一个坑： 把 GLP 合规理解成「只要结果对就行」。我曾经带过一个项目，生信流程跑出来的结果跟参考值完全吻合，但审计时发现运行日志缺失了中间步骤的时间戳。FDA 检查官直接说：「你怎么证明这个结果是今天跑的而不是上周就准备好的？」——这个问题，没有日志你根本解释不清。

第二个坑： SOP 写得太技术化。团队里一位同事把 SOP 写成了技术实现说明书，大段讲算法原理。检查官看了说：「我只想知道操作员该点哪个按钮，不需要知道算法怎么工作。」从那以后我写 SOP 就坚持「操作导向」，原理部分要么去掉，要么放附录。

第三个坑： 忽略角色分离。小团队里开发人员和验证人员经常是同一个人。GLP 明确要求 QAU 不能参与具体研究。如果实在人手不够，至少让不同项目的人互相交叉审核，并且保留独立的审核记录。