当前的EU GMP附录11在第9节审计追踪中仅包含三句话。这几条规定在执行过程中反复引起问题。在这方面，确实需要为新的附录11采取行动。“关于修订《药品生产质量管理规范——计算机化系统》指南附录11的概念文件”中的信息是否充分甚至有用，将在下文进行讨论。
为什么有审计追踪要求?
首先，应该解释审计追踪要求的目的。该要求来源于欧盟GMP指南第4章中关于纸质文件的规范。让我们先看看欧盟GMP指南第4章:
EU GMP第4章4.9节：文件中每一个条目的更改都应该签名并注明日期。尽管进行了更改，但原始信息仍应清晰可辨。如有说明，应记录变更的原因。
有趣的是，更改的原因不是强制性的。这在附录11第9节审计追踪中没有以同样的方式进行要求。
基于这些要求，因此我们需要软件功能允许实现纸质文档的这些需求(见下图)。
现行欧盟GMP附录11的内容
目前，与审计追踪有关的要求如下:
第9章《审计追踪》：在风险评估的基础上，应考虑将所有GMP相关变更和删除的记录整合到系统中(系统生成的审计追踪)。当GMP相关数据被更改或删除时，应记录原因。审计追踪必须是可用的，能够转换成一般可读的形式，并定期检查。
第一句话在解释上给我们带来了最大的问题。另外两句话很直白，但不足以进行适当的监管。对于风险评估应该达到的目标，总是有不同的解释。是否只涉及关键数据，如果是，哪些数据是关键的?还是决定哪些数据与GMP相关?或者是与是否有可能改变数据有关?
博主：关于GMP关键数据的文章如下。
什么是关键计算机化系统？
什么是GMP关键数据？（
什么是GMP关键数据？）
什么是GMP关键数据？）计算机化系统的GxP关键性评估
“所有与GMP相关的更改和删除”的措辞没有给我们任何余地。这意味着它不能仅仅是关于关键数据，尽管GMP数据无论如何也不可能是不重要的。风险评估用于决定是否需要审计追踪。在大多数情况下，它最终是必要的。在以下情况下，审计追踪功能可以省去，例如:
一种数据库，其中的数据不能修改，只能读取。
将数据转发到另一个系统(如MES)的现场仪器，仪器只记录测量值。在这种情况下，仪器本身不需要审计追踪功能，但是MES需要。
一个简单的控制器(PLC或微控制器)，例如，一台带有三个预定义程序的洗衣机和一台提供原始数据的连接的打印机。
除此之外，今天使用的系统和设备应该始终包括审计追踪功能(URS)。此要求也可以在PIC/S PI 041中找到，例如:
第9.6节《计算机化系统的审计追踪》：公司应该选择包含适当的电子审计追踪功能的软件。公司应该努力购买和升级旧系统，以实现包含电子审计追踪功能的软件。
另一个反复出现的问题来自审计追踪的不同需求。EU GMP附录11是明确的，它是关于更改和删除所有与GMP相关的数据。美国FDA的21CFR第11部分第11.10(e)条在这方面更进一步。它还要求在审计追踪中记录数据的输入(创建)。从欧盟的角度来看，这是不必要的，也不一定会减少审计追踪的混乱。当然，谁记录了哪些数据必须是已知的，但与审计追踪功能无关。
审计追踪与系统日志
除了第9节要求的更改和删除之外，还可以记录许多其他数据。然后在系统日志或所谓的事件日志中进行记录。两者都与欧盟GMP附录11的审计追踪无关。
日志文件(也称为系统日志)包含所有可能的系统内部信息(操作系统或软件)。独立于此的是记录用户信息的日志文件，特别是当用户登录或注销时。此类日志文件在EU GMP附录11 12.4中有明确要求(见下图)。
类似的说明也可以在GAMP®记录和数据完整性指南中找到:EU GMP附录11也要求电子系统记录创建电子记录的人员的身份以及日期和时间。即使不存在审计追踪，也需要这样做。
GAMP®5第2版还提到了审计追踪和系统日志之间的差异:根据各种法规的要求，数据审计追踪记录了操作员在正常操作过程中创建、修改或删除GMP记录的行为，并应与其他系统和技术日志明显区分。
审计追踪—变更的原因
欧盟GMP附录11第9章《审计追踪》的第二句话要求记录原因:修改或删除GMP相关数据时，应记录原因。
在这里，纸质文件中关于只有在必要时才应记录原因的要求实际上被忽略了(EU GMP第4章第4.9节：…如有说明，应记录变更的原因)。这一点绝对应该在修订中加以调整。
变更原因也出现在第11次工作小组的目标(第11次工作小组的Aide-Mémoire-计算机化系统的监测)中:
9-9变更或删除的理由如何形成文件?证明可以采用自由文本的形式。下拉菜单也是可以接受的。在任何情况下，辩护的内容必须是可理解的。正当理由的输入应由制度强制执行。
审计追踪—最终需求
EU GMP附录11第9章要求：审计追踪必须是可用的，能够转换成一般可读的形式，并定期检查。
这意味着审计追踪必须以能够轻松地再次检索的方式存储。没有办法绕过归档的概念。审计追踪是GMP文件的一部分。将它们与批处理文档一起归档是有意义的。
一般可读的形式也是针对内容的。审计追踪应包含以下信息:
旧值
新值
时间戳(更改时间)
修改或删除的操作人员姓名
改变的原因
定期检查的要求是一般性的，但给我们带来了两个问题：审计应该在什么时间间隔内进行，谁应该审查审计追踪?两者都没有明确规定。然而，在当前的数据可靠性指南中，这两点都有很多条款。
PIC/S PI 041-1第9.6章节：与每项操作相关的关键审计追踪应与与该操作相关的所有其他记录一起在操作完成审核之前(如批放行之前)进行独立审核，以确保关键数据及其变更是可接受的。
批放行当然起着核心作用。例如，如果使用HPLC进行与放行相关的含量测定，则在批放行前将检查该HPLC的审计追踪。对于所有其他审计追踪来说，会更加困难。在这里，时间间隔应该通过风险评估来确定。
PIC/S PI 041-1第9.6章节：非关键审计追踪评审可以在系统审核期间按照预先定义的频率进行。审核应由原有部门进行，必要时由质量部门进行确认(如在批放行、自检或调查活动中)。
然而，这就提出了一个问题:当涉及到更改或删除GMP相关数据时，哪些审计追踪不是关键的。
这方面的资料也可在第11次专题讨论小组的目标中找到:9-11审计追踪的定期审核多久进行一次?功能必须作为定期评估的一部分进行定期评估，并在必要时进行检查。间隔应以可理解的方式定义，并考虑到过程风险。关键数据的更改或删除应在批放行前进行评估。
现在由谁来进行审核?PIC/S PI 041-1中也有关于这一点的说明:审核应由原有部门进行，必要时由质量部门进行确认，例如在自检或调查活动中。公司的质量部门应建立一个程序和时间表，根据其重要性和系统的复杂性对审计追踪进行持续的审查。
类似的说明可以在GAMP®GPG记录和数据完整性指南中找到：审计追踪评审应由了解业务流程和所记录的行为的影响的个人执行。它们是验证授权用户所做更改和检测潜在数据完整性问题的有效手段。
在SOP中定义基本指导是很重要的:
谁审核审计追踪(人员和部门:QC、生产、QA、系统负责人、工艺负责人等)?
审核的具体责任在哪里?
博主：更多相关的文章见：
数据可靠性风险评估：确定电子数据和审计追踪审核的方式和频率（数据可靠性风险评估：确定电子数据和审计追踪审核的方式和频率）
数据可靠性风险评估：确定电子数据和审计追踪审核的方式和频率）QA审核QC批检验记录和审计追踪(续集)-更多FDA警告信和483表格案例（QA审核QC批检验记录和审计追踪(续集)-更多FDA警告信和483表格案例）
QA审核QC批检验记录和审计追踪(续集)-更多FDA警告信和483表格案例）FDA警告信和483表格确定了！QA需要审核QC批检验记录以及审计追踪（FDA警告信和483表格确定了！QA需要审核QC批检验记录以及审计追踪）
FDA警告信和483表格确定了！QA需要审核QC批检验记录以及审计追踪）计算机化系统审计追踪数据审核的频率（计算机化系统审计追踪数据审核的频率）
计算机化系统审计追踪数据审核的频率）数据可靠性风险评估：确定电子数据和审计追踪审核的方式和频率（数据可靠性风险评估：确定电子数据和审计追踪审核的方式和频率）
数据可靠性风险评估：确定电子数据和审计追踪审核的方式和频率）关于修订附录11的概念文件
关于附录11的概念文件共涉及7点，使其成为概念文件中最全面的一节。
18.[9]审计追踪功能应被视为强制性的，该功能可自动记录GMP关键系统上的所有手动交互，其中用户、数据或设置可手动更改；而不仅仅是“基于风险评估考虑”。在没有审计追踪功能的系统中控制过程或获取、持有或传输电子数据是不可接受的；在这个范围内的任何宽限期早已过期。
风险分析的必要性在这里显然被(错误地)不同地解释了。这已经在上面详细描述过了。根据附录11的现行解释，如果GMP数据可以更改或删除，则总是需要审计追踪。基于风险的审计追踪方法意味着:
如果系统不允许操作员/用户更改值，则不需要审计追踪。控制流程与审计追踪无关，因此(在审计追踪中)不是必需的。
19.[9] 审计追踪应该积极识别的用户做了一个改变,它应该给一个完整的账户改变,即新和旧值应该清晰可见,它应该包括完整的时间和日期更改,和所有其他的变化，除了输入一个值在一个空的字段或这完全是显而易见的,用户应提示的原因或理由为什么变化。
这实际上已经得到了充分的监管。然而，缺少的是需要陈述一个理由。对于纸质文档来说，这并不总是必要的。参见EU GMP第4章第4.9节：…如有说明，应记录变更的原因。
20.[9] 对于在系统上工作的普通用户或特权用户，不应该能够编辑审计追踪数据或禁用审计追踪功能。如果这些功能是可用的，它们应该仅供不参与GMP生产或系统日常工作的系统管理员使用(见“职责隔离”)。
该要求是正确的，并且实际上反映了遵守数据可靠性原则的需要。没有必要在附录11中单独强调这一点。职责分离总是适用的，不需要单独提及。
21.[9] 对审计追踪审查的概念和目的描述不充分。该过程应侧重于审查对系统进行的手动更改的完整性，例如验证更改的原因，以及是否在异常的日期、时间和异常的用户进行了更改。
这里也出现了一个问题，即是否必须在法律框架内加以说明。这实际上应该是规范用户相应SOP的一部分。另见PIC/S PI 041-1第9.8章节：应制定程序处理和调查任何审计线索不符之处，包括必要时通知高级管理层和国家机构的上报程序。
22.[9]应提供审计追踪审查可接受频率的准则。对于关键参数的审计追踪，例如，在BMS系统中设置报警，对与无菌灌装有关的压差进行报警，审计追踪审查应作为批放行的一部分，遵循基于风险的方法。
原则上，这是很重要的一点。然而，这实际上也不应该在法律框架中加以描述。这取决于受监管用户在SOP中对其进行相应的描述和定义。没有一个例子属于法律框架(在BMS系统中设置报警，在无菌灌装时发出压差警报)。
23. [9 ]审计追踪功能应该以足够的细节和实时的方式捕获数据条目，以便给出事件的完整和准确的图像。例如，如果系统通过写入错误消息通知受监管的用户数据输入中的不一致，而用户随后更改输入，然后提示消失，应该捕获完整的事件集。
问题是输入错误的追溯性是否真的有必要记录。这个要求太过分了。
博主：之前的文章讨论过这个问题，见：483表格：LIMS系统扫码识别样品后，还可以手动修改样品信息（483表格：LIMS系统扫码识别样品后，还可以手动修改样品信息）。
483表格：LIMS系统扫码识别样品后，还可以手动修改样品信息）。24. [9]应该指出的是，许多系统会产生大量的警报和事件数据，而这些经常与审计追踪条目混淆在一起。虽然警报和事件可能需要它们自己的日志、确认和审查，但不应将其与手动系统交互的审计追踪审查相混淆。因此，至少应该能够对它们进行排序。这通常是一个重要的注意事项。许多系统都会产生大量的告警和事件。这些通常与审计追踪条目混合在一起。
将警报和事件分配到它们自己的日志、确认和审查中是有意义的。这些审查不应与审计追踪审查混淆。至少应该有可能对它们进行排序。但是，问题是如何在附录11的案文中执行这一点。可以想象，审计追踪可能只包含与GMP相关的数据的更改和删除，而不包含其他内容。或者至少是一个排序函数!
博主：根据博主的经验，根据上文的概念，很多系统的审计追踪与系统日志是混合在一起的，用户可以通过某个界面查看这些混合的数据。因此，个人认为，在审计追踪审核落地的时候，没必要纠结审计追踪与系统日志的概念，直接通过风险评估，确定需要审核的内容和频率即可。更多内容见：操作系统日志是否属于计算机化系统审计追踪数据（操作系统日志是否属于计算机化系统审计追踪数据）。
操作系统日志是否属于计算机化系统审计追踪数据）。原文来自GMP Journal网站，点击“阅读原文”可以查看原文。
