2. 生物信息学合规的重要性：为什么必须重视EMA/FDA要求

说实话，很多刚入行的生信工程师会觉得：我就是跑个流程、做个分析，跟药监局的法规有什么关系？

这种想法我见过太多次了。直到真的出了问题——数据被质疑、申报被打回、甚至产生法律纠纷——才意识到合规不是“上面的事”，而是我们每一行代码、每一条记录的事。

2.1 为什么监管要管到生物信息学？

你想想看，FDA和EMA批准一款药物或者医疗器械上市，依赖的是什么？

是数据。数据是审评决策的核心依据。

我个人习惯把生物信息学合规理解为“可审计的数据科学”。不是写代码跑通就完事，而是每一步都要能说得清、查得到、重复得出来。

2.2 核心风险点：哪些环节最容易翻车？

我在项目中遇到过不少合规问题，归纳下来主要有这几类——注意，这些都是真实踩过的坑。

风险类别	具体表现	后果
软件版本失控	开发库和运行库版本不一致；依赖项未冻结	结果不可复现，审评员直接拒收
数据完整性缺失	原始数据被覆盖或修改无记录；中间文件丢失	数据链断裂，无法支持结论
计算环境不可复现	未记录操作系统版本、依赖库、随机种子	实际运行环境与提交环境不符，被要求重新分析
验证文档缺失	软件安装确认（IQ）、操作确认（OQ）、性能确认（PQ）未执行或未记录	合规检查不通过，项目延期
源代码管理混乱	无版本控制；代码变更无记录；无变更评审流程	审计时无法证明代码质量可控

2.3 常见违规案例分析

我记得有一次接手一个合作方的项目复盘。对方用R包做差异表达分析，版本是自动更新的。结果两个月后需要重新跑一遍分析，因为R更新了底层的线性代数库，p-value跟原来差了3个数量级。

为什么会这样？因为没有锁定环境。

合规体系里有一条基本要求：你必须证明软件在“确定的状态”下运行，并且在整个生命周期内可追溯。

我建议：所有生物信息学分析项目，从一开始就把下面这份清单列出来——

# 必需的环境锁定清单
1. 操作系统版本（如 Ubuntu 20.04 LTS）
2. 编程语言版本（如 Python 3.9.18、R 4.2.3）
3. 核心依赖包版本（如 samtools 1.18、bwa 0.7.17）
4. 分析参数完整记录（命令行 + 配置文件）
5. 随机种子固定值（如需）
6. 容器镜像或 conda 环境导出文件

我曾见过一个团队因为没记录这个清单，在申报前补了整整三个月的数据重复工作，最后还是被要求重新提交一部分数据。

2.4 EMA与FDA的差异：其实关注点不完全一样

虽然两大机构都强调“数据完整性”和“软件验证”，但细看还是有偏重的——这也是为什么我们要单独开这堂课对比学习。

维度	FDA	EMA
对源代码的要求	需提供级别更高的设计文档和单元测试覆盖	更强调输出结果的完整验证链
电子记录规范	严格按照 21 CFR Part 11 执行	对应 Annex 11 要求，但允许一定灵活性
软件分类	按用途分为 SaMD 等级别	更倾向于按输出结果的风险分类
审计风格	现场检查非常详细，关注原始数据	理论检查与现场检查结合，关注流程文件

说白了，你如果只按一套标准准备，到了另一边的审计大概率会被卡住。

2.5 合规不是负担，是护身符

我见过太多做生信的人把合规当“额外的文档工作”。其实换个角度看——合规体系是你项目质量的防火墙。

我曾经帮一个团队整理合规文档，发现他们之前的分析根本没办法完全复现——环境飘了、种子没写、中间文件被误删。折腾了两个月，把所有的结果重新算了一遍。这个成本，如果一开始就按合规标准做，完全可以避免。

知识体系与核心逻辑

下面的 SVG 图梳理了本章的核心脉络：为什么生物信息学需要合规 → 哪里最可能出问题 → 怎么应对 → EMA/FDA的差异在哪里。

嗯，记住这一点，后面我们具体拆解每一项怎么落地。