作者 Loren Smith 安捷伦科技公司 美国加利福尼亚州圣克拉拉市

 

 

药物质量控制实验室的数据完整性问题推动了越来越多监管措施的实施。到底是哪些变化导致了所有这些活动？尽管我们得到了大量监管相关信息，但其中多数毫无用处，甚至更容易造成混淆。本文将基于已有资源的研究以及与美国食品药品监督管理局 (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 节所述）。供应商做的工作越出色，软件验证中需要做的工作就越少（至少理论上如此）。

 

 

评估软件是否支持法规认证需要关注受法规监管的公司开展业务或计划开展业务地区的所有地方法规。如果有些受 法规监管的公司只在美国国内开展业务，或只在欧洲境内 开展业务，他们可选择只关注 Part 11 或只关注 Annex 11 的 要求。Part 11 和 Annex 11 具有共性。然而，任何软件的合 规性评估应以证据为基础，而不能道听途说（如仅体现在 Part 11 证书中）。

安捷伦与许多其他供应商一样，会收到大量的客户检查表，并提供产品答案作为简单直接的回应。然而，根据证 据对那些回应进行评估非常重要，而不要局限于供应商声称系统所具备的功能。审查领域应包括数据完整性问题、访问控制、审核追踪、设备检查等，具体根据适用的法规而定。这样的审查在软件评估过程中非常重要，因为观察到的不足表明可能需要进行程序控制或定制化软件功能。因此，十分有必要向供应商提供对任何观察到不足的反馈，由此避免补救性的程序控制或定制解决方案成为永久的方案。

另一个常见的对软件法规认证支持的误解是，“我购买了供应商的 IQ/OQ工具包，因此我的系统经过了验证”。然 而，购买供应商验证工具包（通常仅限于基础版软件 IQ 和核心的通用 OQ）不足以验证系统适合预期用途。不能将验证责任推给供应商，但供应商确实是（或应当是）您验证工作的可靠信息源和得力助手。

一个相关的验证误解是，“任何系统更改都需要进行全面重新验证”。现实情况是，无论何时更改软件，都必须对软 件更改进行评估，以确定更改对整个软件系统的影响以及该更改对患者安全、产品质量或数据完整性带来的风险。通常，公司会将更改验证局限于针对更改本身，或者他们 会走向另一个极端，那就是不必要地重复整个验证过程。正确的做法是介于两者之间。

 

结论：安捷伦的应对方案

 

安捷伦的目标是将 FDA 关注重点融入系统设计中，以避免交付的软件为客户带来或保留违规风险。FDA 正在明确推行越来越多的技术控制措施，使技术控制优先于程序 控制，并使预防性控制优先于检测控制。因此 21 CFR Part 11.10(a) 规定系统应“有能力检测无效或变更的记录”。 这是法规中唯一真正涉及到检测可能已通过不法手段被篡改的记录的部分。其余控制措施是预防性措施。所以我们说，检测控制措施固然重要，但预防性控制更胜一筹。法规中还强调了优先使用在线记录而非纸质报告打印输出。FDA 不一定会信任交到他们手中的文件。

系统设计的另一个例子是采用在线审核追踪审查。许多系统都可以生成打印版审核追踪报告，但新版 Agilent OpenLAB 色谱数据系统采用一种内置的工具，该工具使用户能够在线审查电子版审核追踪条目。这些审核追踪条目按类型排列，可进行在线审查并包含在线签名。

这些例子用于证明安捷伦如何采用批判性思考方式来重新设计实验室软件，以帮助应对全新的法规认证现状。

 

 

问题：新数据系统是否无需任何程序控制？

回答：并不是这样；由于采用了额外的技术控制，程序控制的需求将会减少，但始终需要某些程序控制，例如系统管理或用户管理。另一项程序控制涉及电子签名的合法应用的适用策略和程序。理想情况下，程序控制的数量会减少到由系统技术控制消除所有对数据完整性至关重要的人为差异，而仅保留围绕系统的程序控制。

 

问题：当软件更新后，需要何种程度的重新验证？

回答：FDA 指南：“软件验证一般原则”中重点介绍了有关重新验证的两个要点。首先，必须评估系统更改对特定公司系统预期用途的相对影响。例如，仪器支持功能的更改可能与用户的特定仪器配置无关，或者可能反映在未使用的功能上。根据供应商发布的文档，用户应能够确定已更新的特征和功能，以及软件中哪些缺陷得到了纠正。任何更改都应与预期用途进行比较，以确定任何重新验证影响。

其次，软件一经更改，用户都应亲自评估更改，包括采用一定程度的回归测试来确认软件或更新软件中的更改未以某种可能产生意外后果的方式造成影响。这种情况并不罕见，例如，更新家中计算机或电话的软件时，查找在更新之前正常运行但更新后无法使用的功能。

 

回答：在过去几年中，FDA 结合 ISPE GAMP v5 指南开始越来越多地讨论的另一个话题就是风险和基于风险的验证的概念。关于操作系统和杀毒程序更新，需要考虑的因素之一是系统中具有安全问题或病毒漏洞等的相对风险。有时，更新风险可能大于系统自身的初始风险（或反之）。一些公司配备豪华的员工阵容来处理网络和服务器基础设施认证，并能够使操作系统与软件验证本身隔离，负责通过安全和杀毒软件更新确保系统保持最佳状态。作为一般实践，公司应当通过操作系统或杀毒程序更新触发或仅仅是定期运行一小组标准回归测试，确保更改对系统没有任 何不良影响。

 

问题：采用新 PC 时，是否必须对软件进行重新验证？

回答：如果新 PC 与原 PC 相比具有相同或更强的功能，并使用相同版本的操作系统和软件，那就不需要进行重新验证，因为系统的功能完全相同。但是，需要重复安装认证工作以确认软件正确安装，或从备份中正确恢复至新PC。

提高这一过程的效率的一个细节是避免过度详细的指标文件。避免指定特定型号的 PC，特别是处理器速度或特定的 存储器或磁盘容量。使用指定名称“或更高性能的产品”将无需随技术进步而不断更新文档。

 

问题：关于 GMP 实验室数据完整性：在需要数据时，能否在任何情况下对其进行修改？

回答：通过 PC 直接采集的仪器数据应被视作庄严的实体；不得以任何理由修改原始数据。然而对于第二种数据，也 就是在采集后的重新积分、更改基线、删除与分析不相关的峰或其他计算等数据分析和数据处理过程中生成的数 据，则被看作是数据处理的正常组成部分，可以在受控条件下进行修改，所做修改将记录在审核追踪中。

 

问题：有时软件中的计算或算法非常复杂，例如色 谱图积分，软件用户是否有必要验证结果？

回答：有必要，计算结果必须得到验证。不仅所有的Microsoft Excel 计算结果，而且所有具体计算结果都会记录到可配置的报告中，例如使用报告模板和自动计算的 CDS 报告功能。如果计算被用于确定特定结果是否处于指标范围内，那么就需要通过指标范围内和范围外的数据对该计 算进行验证，以确保计算正常运行。这种验证还可以评估供应商开发优秀软件和执行准确计算的能力。

 

问题：一旦完成对供应商的审计，是否应当在建议 的时间内对供应商进行重新审计？

回答：在确定供应商审计频率时有多个因素需要考虑，其中涉及到系统对患者安全、药品质量和数据完整性的相对风险。还有一个因素是来自之前审计的供应商表现和回应。如果他们表现很好，重新审计的合理时间为每三年一次，间隔不宜过长。对于其他关键任务供应商或在之前审计中表现不佳的供应商，为实现详细审查，重新审计的合 理时间为每 12 个月一次。

 

回答：供应商有时会停业，或更常见的是停止对特定版本 软件提供支持。如果用户继续使用这类软件，风险水平将 会提高。因为如果出现问题，供应商可能无法解决缺陷或 不愿纠正他们不再提供支持的过时版本软件中的缺陷。然 而，这种风险在一定程度上取决于仪器和软件，特别是旧 款仪器和软件。只要那些系统得到正确管理和使用，也许 可以不需要对它们进行更新。安捷伦经常考虑升级能否提 供足够高的价值、足够新的功能或足够多的缺陷修复以值 得更换或重新验证系统所涉及的成本、时间和努力。

 

回答：回归测试是一种确认功能在进行任何更改之后仍可以正常工作的方式。回归测试应包括系统中最常用的功能 和/或风险分析过程中已确定的风险最高的功能，用于确定特定的软件更新是否改变了供应商文件中未直接提到的功 能。也就是确认系统本身没有倒退，或确认更改不会引起某种意外故障。

 

回答：通过审计。审计是唯一一种通过追踪来确保人们按 照培训进行操作的方法。

 

问题：制药公司是否通常到安捷伦进行现场审计以审查 SOP 等等，或者这些审计是否通常为书面审计？

回答：安捷伦收到的约 90% 的信息学软件产品审计请求均为书面审计，其余 10% 是现场审计。然而，书面审计并非 基于证据。它是基于声明书或者安捷伦选择表述的内容，因此在书面审计中无法对表述的内容进行任何验证。书面 审计通常是圈圈画画的例行公事，人们在纸上进行审计，然后说自己已完成了审计。一些客户将使用书面审计作为 现场审计的前奏，在他们到达现场之前粗略了解安捷伦的定位。

 

回答：IQ-OQ 工具包本身是真实的，并非误解。然而，IQ-OQ 工具包是必要却不充分的，因为它无法满足FDA 关于验证计算机化系统的所有要求。例如，IQ-OQ 工具包不包括验证计划文件或验证总结报告。IQ-OQ工具包也不包括需 求规格、用户要求、功能指标或从 IQ 和 OQ 测试本身到或用户要求或功能指标的可追溯性。

 

回答：许多旧系统仍在法规监管实验室中使用，这些系统运行状况良好。但针对这一问题的解决方法是大量使用包括书面记录在内的程序控制措施。根据其中涉及或系统经历的特定过程的重要程度和风险大小，程序要求可能需要 第二人的验证信息或实际同时见证所做的工作。审核追踪的目的是能够了解工作过程或重建电子记录的历史，不仅包括记录的创建，而且包括记录的更改或删除。如果系统具有有限或不完善的审核追踪功能，则必须以某种其他方式补充记录，通常采取书面记录的形式。例如，仪器旁边的使用记录本。技术控制措施使每位人员的工作更简单。

 

回答：否。始终需要采取程序控制。例如，授权用户访问 数据系统的程序，或变更、修改或移除个人对数据系统访 问的程序是法规要求的程序示例，而数据系统不一定能够 满足这些要求。当前，数据系统可创建帐户并更改用户权限。但是完成这些操作的程序通常需要保存某种类型的记 录，其中包括对系统访问权或系统访问权变更的管理审查 和批准。因此，程序控制不会完全消失。

 

回答：灾难恢复测试是法规的要求。欧洲法规对于这一主题有更明确的规定。由于假设错误，灾难恢复测试通常会 失败。灾难恢复测试对于关键任务系统尤其重要。

 

回答：一些具有电子审核追踪的系统无法表明那些审核追踪经过审查，导致必须将审核追踪审查划分为小块，并主要审查那些与数据关联性非常高的审核追踪。例如，对于药物批次放行而言，必须对涉及该产品制造的所有相关记录以及支持其制造过程的所有系统进行 QA 审查。如果 QA审查关注的是与那些记录相关的审核追踪条目，即使该审核追踪恰好是书面记录，其审查也与记录审查本身的相关性更高。因此，只要将问题划分为与实际记录相关性更高的小块，审查过程就会不那么繁琐。

 

回答：自动峰积分通常通过程序来解决，程序用于确定允许的自动峰积分和可能的重新积分的参数。一般来讲，积分或重新积分活动的灵活性在 SOP 或针对特定分析方法的 系统或过程验证中加以解决。

 

回答：选择系统管理员的最佳实践是确保特定系统的管理员对于该系统中的数据没有利益相关。这意味着在大型企业中，通常由 IT部门的某位员工来负责管理系统。职责分离是IBM 过去已经讨论过的主题，它在金融界也有重要意义。如果一个人没有动机对系统中的数据进行任何操纵，就可能不会构成问题。FDA 提出，如有任何证据表明故意造假，他们会将其视为犯罪活动予以追究，这也是他们的职责所在。

 

回答：这取决于公司政策和程序的要求。如果系统中存在充足的控制措施并且人员经过了充分的培训，那么在发生样品重新处理时（发生在适当的控制措施和程序到位的适当情况下），审核追踪备注可能就已足够。但是，如果程序未解决样品的重新处理问题，或如果它被视作异常或不寻常事件，则有必要提供明确记录的批准过程。