第一部分 — 基础

什么是 GxP 统计计算环境？

在药企里随便问五个人什么是统计计算环境，你会得到五个相互交叠的 答案："我们的 SAS 环境"、"那几台经过验证的服务器"、"分析数据存放 的地方"、"QA 审计的那个东西"。这个术语从来没有过一个唯一的权威 定义，这件事本身就耐人寻味——SCE 的定义与其说是一份组件清单， 不如说是一项义务。本章为全书确定定义，把它们放回监管框架中，并 指明任何一个诚实的 SCE 都必须声称具备的性质。

一个工作定义

统计计算环境(statistical computing environment) 是一个组织将 临床数据转化为受监管的决策与交付物的、受管理的硬件、软件、数据与 规程的组合。GxP SCE 是指其产出可以进入受监管的工作——递交、 安全性审评、标签声明——并因此负有举证义务的 SCE：它必须能够对自 己产出的任何数字证明，这个数字是准确的，过程是可复现的，从数 据到决策的链条是可追溯的。

这三个词——准确性、可复现性、可追溯性——出自 R Validation Hub 的白皮书，该白皮书从监管实践中提炼出了它们(R Validation Hub 2020)。它们是每一场 SCE 对话的承重墙，而本书其余部分，无论以何 种方式，都是围绕建造能为这三者持续生成证据的机器展开的。

法规真正要求什么

让从制药业之外来的工程师感到意外的是，监管框架是多么地不具规定 性。FDA 关于 Part 11 范围与应用的指南，众所周知地收窄了该规则的 适用范围，并对具体的验证与审计追踪机制行使执法裁量权——同时让前 置义务(predicate obligations)完全保持效力，并建议验证决策应立 足于"一项有正当依据且有文档记录的风险评估"(FDA 2003)。最经典 的例证是那台只用来撰写 SOP 的文字处理器：无需验证。决定负担轻重 的是预期用途，而非技术类别。

由此得出两个结论。第一，法规并没有规定架构。框架中没有任何条 款指定你必须使用哪些数据库、语言或流水线工具；FDA 已明确表示它 不要求任何特定的统计软件，只要求递交材料记录所使用的东西及其版 本。第二，负担是真实的，但是有条件的：一旦你的产出进入某项 受监管的决策，关于验证、审计追踪与记录完整性的问题就会随之而来 ——由前置规则与行业标准(GAMP 基于风险的验证模型；欧盟针对计算 机化系统的 Annex 11)承载，而这些标准把如何回答这些问题落到了操 作层面。

所以诚实的概括是：法规告诉你要能拿出什么证据，而不是要运行什么 系统。这种不对称正是本书通篇利用的战略开口。

每个 SCE 共有的解剖结构

剥掉厂商差异，每个 GxP SCE 都在用机器回答同样的七个问题：

• 身份——谁在运行这个，拥有什么权限？
• 环境——哪些语言、包、版本，锁定在哪个基座上？
• 数据——哪些来源的哪个快照，出处从何而来？
• 代码——哪些程序，由谁评审，处于哪个版本？
• 执行——计算在哪里运行，如何记日志？
• 输出——数据集、表格、图形、报告——如何存储，如何寻址？
• 证据——当监管者或审计员发问时，什么能证明以上各项？

商业在位者在一家厂商的产品内部回答全部七个问题。开源世界则用一个 零件组成的生态来回答——而且，正如我们将看到的，它几乎把最后一个 问题完全留给了你。

那么，为什么要有这本书

在经过验证的巨石式系统与松散的生态之间，存在第三条路径，而它几乎 尚未作为公开的工程实践存在：把零件组装成一个信任层——一种流 水线产品，它的原生产出不仅是交付物，而是与证据焊接在一起的交付 物。下一章解释为什么这条路径必须翻越的高墙是由缺失的证据、而非 缺失的能力筑成的；本书的其余部分，就是那次翻越。

检验。 对于你称之为 SCE 的任何东西，问一问："它上一次在正 常工作中、不请自来地生成关于自身的证据，是什么时候？"只有在被 审计时才生成证据的系统，是在按需回忆。持续生成证据的系统，已经 不再回忆，而是开始记录。