药物质量控制实验室的数据完整性白皮书（一）
作者 Loren Smith 安捷伦科技公司 美国加利福尼亚州圣克拉拉市
白皮书
药物质量控制实验室的数据完整性问题推动了越来越多监管措施的实施。到底是哪些变化导致了所有这些活动？尽管我们得到了大量监管相关信息，但其中多数毫无用处，甚至更容易造成混淆。本文将基于已有资源的研究以及与美国食品药品监督管理局 (FDA) 员工及其顾问的直接交流总结事实，从而消除常见的误解。将讨论下列内容：
• 如何在历史背景下理解当前的执法环境
• 如何采用批判性思考方式来讨论有关数据完整性的各种误解
• 如何在新的期望下评估当前的实验室软件及相关程序
• 供应商如何重新设计实验室软件以帮助客户应对新的现实情况
数据完整性和 FDA 法规认证的定义与历史
在 Scientific Computing（2013 年 9 月）的一篇文章中，Bob McDowall 将数据完整性定义为“遵守适用的法规生成、转 换、保持、确保数据在其整个生命周期内的准确性、完整 性和一致性”。
一种常见的误解是适用的法规是全新内容。而事实上，21 CFR Part 11 的“电子记录；电子签名”首次发布于1997 年。到
2003 年，在制药行业已经对法规适应了一段时间后，FDA 发布了名为“范围与应用”的指南，其中对 Part 11
的某些要求进行了说明。这份指南还就 FDA 根据检查过程中所发现问题制定的选择性实施策略展开了讨论。2010 年，FDA
宣布其重点进行数据完整性检查。但是，当时 FDA 内部只有少数人能够理解计算机化系统的数据完整性问题。因此，针对包括化学专家、制造专家及拥有
GxP 专业知识的人员在内的对象，FDA 举办了大量数据完整性、数据完整性
检查和法规的培训活动。他们还雇佣了欺诈调查领域的专家，包括来自美国联邦调查局的人员。因此，从2013
年开始，数据完整性已成为主要检查项目，各个地区的数据完 整性执法活动明显增多。此外，自 2014 年起，FDA
在其警告函及相关公开信息文件中经常指明硬件和软件产品的名
称，有意无意地向硬件和软件制造商表明，管理部门希望他们能帮助客户解决数据完整性和法规认证方面的疑虑。
澄清误解
经常听到的另一个误解是，如果某家制药公司使用特定的软件系统，FDA
就会将其关停。这种担心可表述为：“整个生产机构或实验室的系统具有的潜在缺点都可能被视作数 据完整性风险。如果这一缺点尚未显现，那么 FDA
是否有 理由以 483 警告函的形式提出观察警告？”答案明显是否定的。有能力违规不等于已经违规。不妨看
看这个比喻：美国许多地方的限速是65英里每小时，但汽车有能力超速并不意味着汽车拥有者就会收到传票（被
判超速）。类似地，在制药公司中，如果没有利用潜在的 数据完整性缺点进行数据篡改或数据删除（或其他欺诈行
为），那么监管机构就没有理由发出传票或警告函。检查人员将与制药公司人员进行详谈，这时的重点将转向通过 程序控制确保已知缺点不会显现。
程序与技术控制
让我们先看看这样的说法：“这款软件符合 Part 11 法规要 求。”这种说法存在一些问题。首先，它在逻辑上是不可 能的。Part 11 中的一些内容无法通过计算机化系统中的技 术控制来满足要求。例如，CFR Part 11.10(j) 规定了电子签名的使用政策。这是色谱数据系统无法满足的一项要求。这只是一条法规要求，并不意味着能够通过技术控制来满足。软件实际不存在符不符合法规要求的问题。软件本身是没有对错的；仅仅是软件包括的技术控制措施是否能够支持满足适用法规的要求。除技术控制以外，还必须采用程序控制。有关程序控制与技术控制的讨论常见于 FDA 警告函中，在系统无法支持多种法规所要求的技术控制时尤 其如此。
利用标准操作程序 (SOP) 作为程序控制措施能够取代技术控制，前提条件是：
• 人员接受过该 SOP 的培训
• 该 SOP 得到执行
• 通过质量监督和/或认证审计确认 SOP 得到遵守
但是，通常情况下，即使存在 SOP，它们也未得到执行，遵守情况也未得到适当验证。因此，FDA 将要求采用系统 补救手段以防再次发生类似行为。
计算机化系统中的审核追踪是技术控制的一个例子。软件 生成的审核追踪必须能够包含法规要求的所有要素，然后 必须启用那些控制措施。
审核追踪记录 (21 CFR Part 11.10(e)) 自动说明系统正在运行且状态正常，并且可在审核或检查过程中查询，无需进行 任何额外人工操作。
软件验证或功能证书：它们是否有价值？
许多软件供应商提供软件验证证书，或提供一份根据 21 CFR Part 11 Readiness Claims中条款命名的证书。此类证书 的价值不大，因为FDA 期望由用户在使用环境下对软件的预期用途进行验证。尽管供应商向客户保证根据客户需求 来制造与设计系统，并在软件交付之前花费了大量时间进行测试，但供应商的开发和测试工作不会（并且无法）替 代客户宣称其预期用途以及按预期用途对他们的系统进行验证。
另一个相关要点是，FDA 对供应商的信息学软件部门不具有任何司法管辖权。因此（除非软件获得 FDA 医疗器械 注册认证），供应商提供的任何文件都无法获得 FDA 的认 可，因为 FDA 对公司的这部分业务没有执法权。
供应商可能会提供产品能够符合Part 11 的相关详细信息，但这些信息基于供应商对法规的解读。这种解读可能与其 他许多制药企业或 FDA 自身的解读不尽相同。供应商的解 读无法替代审计来确定软件功能是否满足监管要求。
您的责任：审计、评估和验证
数据完整性法规认证责任包括供应商审计、计算机系统评 估和软件验证。
在审计供应商时，存在由审计员自身引起的四重困境或一 系列问题。（参见 Mourrain, J., Therapeutic Innovation and Regulatory Science, Volume 40 (#2), pp. 177-183.）
第一重困境是不一致。法规内容很少。例如，不计入 1997 年 联邦公报序言中的信息，Part 11 法规一共只有三页篇幅。 而指南内容很多，对指南的解读更多。在许多审计情况下，解读的不一致会带来问题。例如，客户在审计过程中 可能会以某种方式理解某条法规，而供应商却以另一种方式来理解同一条法规。
偏好性是审计员遇到的另一个问题。审计报告比较片面而不够完整。某些审计员认为他们需要大量的审计结果。因 此，他们会分离出每个 SOP 中每个问题的调查结果，并将它们全部单独列出来，这就可能造成误解，即审计报告的 好坏仅仅取决于篇幅。其他审计员可能采用举例的方式并将这些例子包含到几次大范围的观察结果中，从而为审计中的主要调查结果提供支持。此类报告可能无法代表审计过程中了解到的全部内容。
审计员遇到的另一个问题是差异性。归根到底，审计员也是人。一些审计员会纠结于某些问题，例如灾难恢复，而其他审计员则可能专注于 Part 11。
易读性（并非字迹方面的）是另一个问题。审计员或许能够传达他们在审计过程中发现的问题。但是，他们通常难以表述“那又怎样”的问题。即，计算机化系统对患者、产品和数据完整性的影响。
这些审计困境的解决方案是什么？解决方案是采用模型而非检查表，该模型的组成部分包括：
• 规程
• 人员培训
• 软件开发活动
• 测试活动
• 质量管理体系
• 基础设施
最后一项通常不相关，除非供应商在云端应用等载体中保管 GxP 记录。
在模型方法中，评分能够将较为主观的过程转换为客观的测量体系，这一体系应支持可靠的个体供应商审计，并能对多家软件或服务供应商进行对比评估。所有活动的关键在于供应商审计能够施行基于风险的验证策略（根据 FDA“软件验证一般原则”的第 6.3 节所述）。供应商做的工作越出色，软件验证中需要做的工作就越少（至少理论上如此）。
-
焦点事件
