蒲公英 - 制药技术的传播者 GMP理论的实践者

 找回密码
 立即注册

QQ登录

只需一步,快速开始

使用微信帐号登录

使用微信帐号登录

查看: 324|回复: 8
收起左侧

[其他] 【转载】实验室数据完整性风暴,“验证”后还在持续

[复制链接]
发表于 2018-10-8 12:45:55 | 显示全部楼层 |阅读模式



PDA技术报告80的整体结构有点散乱,试图大而全的涵盖QC实验室的方方面面,就阅读逻辑而言存在一定的重复性和冗余,海螺研习社将其中的主要内容进行重新编排,分三个方面结合我们实际的工作经验进行介绍和解读。

在大部分的国内企业听到数据完整性的时候,基本上认识点还停留在QC实验室仪器计算机复杂系统的供应商验证确认阶段,很多企业号称进行了数据完整性整改和升级,但是上至老板下至实验室分析测试人员都只认为有了供应商提供的验证就满意了,或是停留在更加初级的“全面审计追踪”功能升级了就满足了。这样的认知误区会导致大面积的数据完整性合规问题的持续爆发。实际上,数据完整性从2015年海正的警告信爆发为标志事件来看,直至今日,很多企业还是持续在这个领域翻船就是最好的例证。很多老板也抱怨自己已经投资升级了硬件和软件系统,QA/QC人员和反复参加了供应商和行业组织的数据完整性培训,但是为啥数据完整性的缺陷依然困扰着自己的实验室。究其本质,就是没有对仔细QC实验室计算机系统进行系统分级,并认真的对待软件系统升级,认为数据完整性是一次性的硬件投入,认为QC实验室只要仪器升级了就一劳永逸了,这些错误的观念导致了今天行业内的普遍问题的存在。

我们按照实验室数据系统的分级:简单/混合/复杂体系进行介绍,又特别重点的结合HPLC/GC色谱分析仪器主要介绍了复杂系统的数据完整性的风险识别流程、计算机系统的验证以及计算机系统日常管理要点。

就任何计算机系统的数据完整性管理来说,分成以下四个层次:
第一、基于风险的实验室数据管理流程的确认
第二、经过恰当分析软件系统计算机系统验证(CVS)
第三、对于计算机化软件系统的日常控制、管理、和定期审核(系统动态维护)
第四、参与校验、检验、复核、和日常维护的人员的培训和教育

本文介绍的内容索引如下:
1. 简单系统
2. 混合系统
3. 复杂系统

  a) 复杂系统的SOP管理控制要点

  b) 复杂系统的基础设施系统确认要点

  c) 市场上复杂系统供应商进行的计算机验证确认不足

  d) 基于数据流的复杂系统计算机完整验证确认要点

i. 数据的生成

ii. 进样序列的产生

iii. 数据处理和积分

iv. 数据报告和打印

v. 全面审计追踪

vi. 数据备份和恢复


做任何工作,都需要首先识别和认知我们管理的系统,就QC实验室的数据类型和风险等级而言,对于目前国内的QC实验室的现状,原始数据的产生和维护依赖于简单系统混合系统复杂系统,相关管理者可以考虑结合这些系统的特色建立自己的风险管理流程和等级,确保原始记录(涵盖源数据和元数据)的数据完整性得以有效的保证。这个阶段的工作可以做为独立的风险评估报告存在,也可以做为验证阶段的风险识别环节存在,但是无论如何,一旦定义和识别后,都必须有书面的SOP来定义、支持和管理这个系统,以便于在实验室的整个生命周期内进行有效的监控。

所谓的简单系统,值得的全部的数据产生由手动产生,比如溶液配制记录,培养基配制记录,手动滴定操作试验记录等等,这类系统完全由检测人员手动操作实验产生。一般来说必须由各种辅助记录和交叉记录来支撑起真实性,这也是传统现场核查中追溯性检查的重点。在2015年之前的FDA检查中,追溯性往往针对的是纸质系统的记录完整性,由于纸质记录本身的缺陷,这类缺陷的发现往往都不是直接的证据。
FDA警告信中关于简单系统缺陷的典型表现形式:
在垃圾桶内发现被撕毁的纸质记录;现场检查期间发现到了时间点应该进行的记录没有按照规程进行记录;在检查现场发现支持的仪器使用记录中缺失某些批号的信息等等。

在传统上说,只要检察官没有系统的将这些纸质记录的缺陷连成一个体系来写缺陷,只是单独的罗列缺失的记录,那么往往会被认为是人员的偶然失误带来的错误,在历史上也往往认为是“轻微的GMP错误”。除非在一个工厂的现场检查中大量不同岗位的纸质记录都存在这样或是那样的记录不完整的现象,才有可能被检察官上升到系统缺陷的层面,而往往到了这个层面,基本上也是导致对整个系统的不信任,可以因此全盘推翻整个公司GMP体系了。

这里提到的混合系统是指仪器同时产生电子源数据和纸质打印数据的系统,这种系统由固件(firmware)管理,提供了纸质记录,例如:天平、自动滴定仪、旋光仪、溶出仪、pH计等,和复杂的计算机系统的典型区别在于系统是否连有电脑,是否有专门的软件控制。

最简单的混合系统是没有数据储存的系统,只能显示或打印数据,这样的系统必须严格控制时间和日期的改变,并辅以仪器使用台账来确保检测的可追溯性和真实性。

带有数据储存功能的混合系统(例如溶出仪、滴定仪)必须定期检查储存的数据(涵盖数据备份和确认,数据的数量平衡等),同样也必须严格控制时间和日期的改变,并辅以仪器使用台账来确保检测的可追溯性和真实性。

一般来说混合系统的风险比简单系统要小,一般风险来源是:
・所有的数据的产生缺乏可追溯性;例如,和简单系统一样没有密码授权管理,没有全面审计追踪,或是时间/日期可以随意修改,还会出现大量和纸质辅助记录交叉不一致的现象。
・对于仪器和软件功能和特性缺乏了解也会带来额外的风险;例如,操作人员不熟悉系统自带的校验功能,内置时间的设置,报警功能的含义等等。在溶出仪等仪器中,出现的报警功能非常值得注意。【补充例1和例2】
・日常操作中存在检测到合格或重复打印相同的记录的问题;
・一般来说这样的系统存在脆弱的恢复和备份功能
・缺乏对于保留的电子数据的控制功能,例如工程师入口可以随意的修改时间,甚至是删除数据,清空系统,恢复到出厂设置等等。
・缺乏足够的第二人复核的证明

例1:对仪器的校验功能不熟悉,以下案例显示在2018年8月6日使用现场,系统自校准却是发生在2016年10月18日两年前,这肯定就存在明显的数据完整性缺陷了。

例2,这个例子更加具体的体现了自校准的历史,大量存在自校准不合格后公司关闭了仪器系统的自校准功能。

在实际的管理中,供应商应当提供详细的校准、验证/确认方案,定义系统的功能标准和自带的控制方法。公司的质量部门应该确保供应商验证/确认方案的正确理解和执行;并根据系统使用的目的和实际的用途,对系统进行必要的补充验证/确认和其他管理控制手段来确保系统的数据完整性缺陷可以被有效的控制和监管。QA部门在旅行这个职责的过程中,需要确保系统验证/确认(或补充验证)中必须考虑有以下方面:

・数据格式和储存能力,例如是否可以转化为CSV/TXT/ EXCEL/PDF文件格式?数据储存能力是否足够?是否会覆盖最先的数据或不保存数据?
・跨平台数据能力,例如KF水分仪往往需要按照一个特有的软件来储存和解读这些源数据,这样的情况下需要验证这一软件了,检查附加特征,并确保数据可以用常规软件(例如EXCEL/PDF)的数据相互交换,来确保是否存在数据被篡改的可能性。
・数据处理方式,QA必须确保数据端(产生)到端(最终用于决定放行)的数据处理流程的数据完整性,一般我们会要求有独立的系统管理员(IT人员)。最典型的例子就是天平时间是否锁定来预防称量记录的篡改。
・备份和数据回顾,最好每次测试或定期打印事件日志/报告,时间日期一致性,数据一致性的QA定期符合。最常见的场景就是计算中使用重量和分析天平打印条的一致性,其他辅助或相关仪器的时间点,定期数据数量平衡等交叉一致性的核对检查。
・数据备份和归档能力,这个很好理解,我们必须确保数据的备份,归档和恢复流程,确保不恰当的数据转移。
・复读到电脑的数据完整性问题,例如将数据储存为EXCEL格式,所有字段和数据,采集时间,测试结果等都不能被篡改。
・数据结果输出方式, 例如输出结果应该尽可能完整,必须涵盖原始数据、元数据、测量值、样品身份、批号、文件报告、计算值、测试人签名等等基础数据信息和周边支持数据信息。
・数据生命周期的管理:必须有SOP规定定期数据备份和存档,归档数据的离线保存和可恢复性,备份数据的可获得性和可读性(有时候软件系统升级会带来数据不可读,这需要保存老版本软件)
FDA警告信中关于混合系统缺陷的典型表现案例如下:
・检查官发现实验室分析员没有在天平称量的同时记录样品重量。特别是,用于计算中的样品重量是在色谱运行之后产生的。分析员承认此样品重量是被装扮成原始数据的,实际上是在分析之后返回日期制作的称量条,原始结果是记录在笔记本上的。这些样品重量是用于计算相关物质和杂质,用于支持递交给FDA的注册文件中的分析方法验证的。
・回顾KF电子数据是发现一个OOS结果没有报告。在数据表中报告的通过结果是另一个样品在同一天的一个小时之后检测得到的。

在当先的QC实验室中这类混合系统是普遍存在的,而且本质上也和纸质记录简单系统一样是不可避免的,更重要的是如何建立可信的监控体系去运营。往往合理的检察官会根据这些混合系统产生数据的质量安全重要性来判断这类缺陷的重要级别。比如如果你的称重条是非常重要的含量指标或是制剂溶出均一性指标的数据来源,那么这类混合系统的缺陷将会直接上升到关键级别,因为其直接影响到了产品的质量关键特性。
复杂系统一般指的是分析实验室计算机化系统,包括HPLC、GC、PSD、UV、IR、ICP-MS、XRD等各种类型的仪器操作系统以及LIMS之类的数据集成系统。复杂系统应该至少包括:分析仪器硬件本身,软件操作系统,操作平台和手册,操作管理维护SOP和经过培训的分析测试人员和数据复核QA人员。在目前的实际工作中,单机版系统、服务器版本系统和远程云端版本系统都有实际应用的情况存在。我们目前可以明确的说单机版软件系统存在固有的缺陷是重复测试管理和数据审核困难的问题,并同时存在数据的保存、备份和恢复的困境,这些都是单机版本软件固有的不可能弥补的风险缺陷。在本文中,我们没有针对单机版系统专门进行展开讨论,读者可以结合网络版的风险分析点进行单机版软件的风险点分析。

a) 复杂系统的SOP管理控制要点
基于网络管理的复杂系统(参见图1)应该建立SOP进行全面的控制,而不应该满足于一次性的供应商提供的系统验证(往往这样的系统验证还很不全面),这些控制必须考虑(不限于):

✔系统操作人的角色和职责; 防止利益相关,系统管理员的职责一般分配给IT人员,且任何角色或权限的改变,都需要QA的书面批准和监管。为了实现这个管理要求,必须采用的措施有:用户账号和密码唯一性;用户类别和许可;新系统的配置和注册;创建文件夹管理数据的层次(参见例4);谁负责进行备份/恢复以及频率;谁负责创建和修改方法;谁能够改变和调整方法;谁能够产生数据(进行检测);谁能够复核和批准数据;谁决定需要复核的内容;当数据“完成”后,谁能归档数据

✔有控制措施,确认审计追踪能够发现并记录,和准确记录(纸质或电子),用于支持任何调查; 要求是任何操作(参见例3都会在操作时就记录。必须采取的措施有:限制改变系统时间和日期、限制只有特定用户可以删除需要删除的信息、限制升级软件,改变配制,接入因特网,关闭自动升级

✔防止原始数据被覆盖,操作或删除,而且不被审计追踪记录的控制措施; 必须证明能在每一步操作发生时,在下一步操作开始前,防止数据和数据处理不被记录。典型的例子是,waters的empower3软件有打开预览就记录的功能,这样的功能需要有控制,并有SOP的规定。

✔原始的,经过批准的,经过验证的系统的定期确认;这是类似与产品年度质量审核的工作,要对计算机系统进行定期的审核确保其在整个生命周期内依然符合最初验证状态和符合其使用目的。

✔自动流程打断后的数据恢复和回顾; 类似于应急场景的处置,涵盖了所有报警项目和操作的解释和应急处理措施,这些都需要有SOP和对应的记录支持,也是定期系统审核的重要组成部分,由这些具体的系统报警/异常/崩溃数据构成了下个周期内系统的管理和监管级别。必须采取的措施还有:建议分析系统使用专用网络和服务器;如分析测试被打断(如断电或仪器故障),应有合适记录和评估;建立端对端数据流程图,识别和降低风险等措施

✔电子数据存储路径,文件夹和文件的名称一致性;

✔用于连接检测仪器的计算机不用用于其它用途(如创建SOP,发送Email等)

✔不能连接其它个人移动装置(手机,优盘等),预防病毒感染


图1 典型的基于网络服务器的复杂系统的数据流
例3

例4
一个映射层级错误的示例,按照上传层级配置应该上传的第3级文件(File 4),由于Map错误将不会上传。
注:ECM提供了建立ECM存储和本地存储的直观关联的方式——Map模式,使用Map模式时要考虑Map层级与上传层级之间的关系。一个容易犯的错误是,文件上传开始层级设定值高于本地与ECMFolder对应的文件夹,导致本地文件无法归属到具体的Folder(ECM),从而无法上传。

b) 复杂系统额基础设施系统确认要点
基于服务器的复杂系统基础设施硬件的验证/确认中还建议考虑的因素:
✔分配给系统一个唯一的识别编号;
✔服务器应置于一个安全的环境;
✔服务器的物理安全,限制进入;
✔操作系统详细信息和版本;
✔服务器用途的确认和防止误用的控制措施;
✔网络拓扑图和进行功能测试;
✔定义应用软件,操作系统和防病毒软件的升级频率;
✔远程登入的控制措施(例如维护保养或系统升级)

值得注意的是,目前基于服务器的复杂系统的基础设施硬件的确认都不涵盖在各个仪器提供商进行的计算机系统验证服务中,所以大部分的中国企业都忽略了这部分的工作。而实际上在日常工作中,因为该系统缺乏验证和管理带来的实验室偏差所占的比重也非常高。

最新的复杂系统还有一种最新的模式,那就是基于云端服务器的SaaS(软件即服务)- 虚拟系统
・制药公司作为终端用户,负责此技术的合理使用和控制

✔审核审计追踪、备份台账、变更控制

✔系统管理员账号的控制等

・应与SaaS服务供应商签署《服务协议》:

✔对于合规性,应各方的具体职责

✔供应商的具体信息

✔设施的物理和逻辑安全

✔防火墙的安全性

✔应用软件的使用环境受控:数据备份,软件相应时间,支持相应时间;

✔设定指标(Metircs)评估和监控SaaS服务供应商的服务质量

✔双方都应该建立业务连续性计划,确保数据不丢失(断网,硬件故障,网络攻击)

✔定期进行审计SaaS应用和宿主环境(至少一年一次,基于风险)

✔进行用户可接受测试


目前这种模式的复杂系统在国内企业中还非常罕见,所以目前提到有点超前。对于海螺学院APP来说正是一个很有指导意义的建议,我们会基于这个原则推出我们的GMP培训评价体系软件来帮助中国制药企业完善自己的人员培训工作。

图2 全生命周期数据完整性管理的法规基础

c) 市场上复杂系统供应商进行的计算机验证确认不足
现有的仪器供应商都会提供一定的系统软件验证服务,在这些服务中,有些涵盖了(不限于)以下内容,有些不涵盖以下内容:
・在提供软件前,供应商应已经完成了足够的测试,例如开发商进行了正式的结构测试,软件符合性证书;客户对定制软件进行开发阶段的确认或者审计等等
・软件目标功能:分析,数据采集,处理,报告,追溯和安全性
・软件名称、配制和版本号
・审计追踪的合规性(21 CFR Part 11)
・计算公式中算法的逻辑和基础,例如USP拖尾因子,积分参数等
・软件进行的常规统计计算和复杂统计计算,例如软件进行的常规统计计算和复杂统计计算,手动计算和软件值的比对、均值,SD,RSD、残留误差,回归曲线,斜率等
・计算机和服务器之间的数据传输和交互的检查,例如本地PC和服务器之间的网络断掉时,会怎么样;确保数据在传输过程中不被串改,变化,出错;与LIMS,EPR等数据管理软件之间的适用性
・升级包的安装负责人员的培训和资历证明
・通过变更程序和风险评估管理软件相关的变更
・用户登入的安全策略
・关闭数据修改,删除和复制的功能(管理员除外)
・限制数据删除的权限
・保存之前版本的详细权限列表和软件,经过QA批准的;法规要求,官方检查是要求查看;能够审核之前老版本软件中的数据:包括当时的审核、处理,审计追踪审核、备份/回复测试和报告的数据
・保留所有实验室目前使用的所有软件的详细权限列表
・建立定期回顾控制效果的流程;常规做法:新系统频率高(比如三个月一次审核),老系统频率降低(比如一年一次回顾审核);需要关注软件升级和补丁;必要时采取补救措施。

实际操作中取决于企业QA或系统管理员对法规的要求和对软件体系的了解程度,要知道从供应商的角度出发,他们不希望做这些合规的服务,或是做的越少越好,但是对于企业来说,供应商做的越多越好。对于在中国市场的主要仪器供应商我们都不能抱有太多的期望,我们强烈建议公司QA人员对照我们以上这些清单去逐一检查供应商提供的所谓计算机系统验证确认服务包,如果不能涵盖以上的完整内容和服务,我们只能是聘请有经验的第三方验证公司来进行系统的补充验证了。至少目前我们在整个服务售后博弈中,对于这些大型仪器生产企业,医药企业还是相对弱势的,所以也不能指望他们在短期内发生太大的改变。

d) 基于数据流的复杂系统计算机完整验证确认要点
图3 典型的分析仪器电子数据流程图


基于以上的典型电子数据流程图我们来说明下具体的数据管理全过程中需要关注的点和容易引入风险的关键点。这个流程图的解读对于QA日常审核数据完整性和审计方进行高效的数据完整性审核至关重要。

i. 数据生成:应有SOP规定,或在偏差调查中包括如下情况的处理:
✔什么数据是原始数据:如果在进样检测过程中断电,数据在哪里?什么形式?
✔如果进样在完成前中止;信号采集后是否可以重命名数据文件;
✔转移过程中数据丢失的处理;
✔能够识别使用以上方法故意损害数据的行为

ii. 进样序列:通过一个系列的命令让样品排队依次进行检测
质量部门在这个阶段的监控和审核重点是:
✔批准软件系统结构;
✔定义序列生成和修改的规则;
✔样品检测过程中,方法参数修改的控制;
✔数据采集之后,复制,移动,和重命名数据文件的规则
系统的审计追踪应能抓取:
✔序列名称和编号;
✔修改的原因
✔分析员名字;         
✔每个样品的方法
✔产品名称;            
✔序列执行前的第二人复核(建议)
以下情况也需要有SOP规定,并在功能要求中列入:
✔修改或执行部分序列;
✔仪器至相连电脑在传输过程的数据丢失;
✔序列开始后修改方法参数;
✔什么时候可以放弃序列,放弃后序列的可追溯性;
✔在序列开始后增加样品的标准;
✔色谱进样之间断电管理;
✔对于预检测,系统检查进样或单针进样的控制;
✔能够识别使用以上方法故意损害数据的行为

iii. 数据处理和积分:数据处理参数,方法和处理后数据的变化:应通过结果的版本区别或审计追踪记录,并记录变更理由;积分方法:通过标准方法,元数据和典型图谱定义;整个序列应该使用同样的积分方法,并与图谱一起打印。

尽可能避免手动积分:(参考4-7 手动积分管理案例
✔有SOP规定
✔通过权限控制(主管批准,在台账中记录)
✔预先规定可以手动积分的情况
✔持续出现不好的色谱峰或基线,应采取措施改进系统或方法(确保数据的持续性和可靠性)
图4典型的自动和手动积分
图5 适当比例,清晰基线和积分,单个完整峰的典型图谱
图6 比例不恰当,基线和积分不清晰的典型图谱
图7比例恰当,能看到没有积分的峰和消减过的峰
     发现了可能的篡改

抑制或忽略图谱中的任何峰 (8 不恰当的积分举例
✔科学合理的解释说明
✔相关物质检测中:空白峰,对照峰,溶剂峰等
✔所有按要求积分的峰都应该积分,积分限的设定(USP <621>报告限的一半)
✔已知原因的异常峰可以被剔除
✔未知峰应积分并按照SOP的规定调查

图8 不恰当的积分举例

iv. 数据报告和打印: 一些软件使用“Print” 或“Publish- ing”来表示检测完成后的结果输出;良好配制的受控系统:此步产生的结果–最终结果,不经过重处理就不能再改变
结果重处理:应有SOP规定,需要备注或解释说明 (参考图9
主管或质量部门审核:结果输出前,按照SOP规定进行
由于软件功能或资源限制:很多公司还是使用纸质打印的方式

图9 结果重处理需要输入重处理原因
每个检测,通过打印或输出,应产生以下项目或报告:
✔样品序列;
✔仪器方法;
✔积分事件/处理方法
✔结果(图谱);
✔方法,序列和结果的审计追踪
结果应包括如下信息:
✔分析人员姓名和签名;
✔结果处理的时间和日期;
✔方法,序列和结果的审计追踪;
✔可视坐标尺寸的图谱(含量和被测物质的峰高,纯度测试的峰低)

v. 全面审计追踪: 审计跟踪是记录“谁、做什么、何时、为什么”的表,能确保安全受控计算机所生成的,时间戳的电子记录是能够用于重建“与电子记录的创建、修改或删除有关的事件过程。

例如,对于HPLC运行的审核跟踪可以包括运行的用户名、日期和时间、积分使用的参数,以及再处理的细节,如果有的话,包括变更的理由。此外,进样日志可以包括在内,但是这个进样日志不包括审计跟踪进样信息(空白/系统适用性/批号)。进样日志指仪器运行停止的记录过程,这个日志不包含具体信息,一般是start/stop的状态记录或者是仪器部件运行的过程比如探针伸入,转盘转到位置等。【解释了审计追踪和仪器进样日志的区别】

审计跟踪功能应始终启用,并严格访问控制到位,具有数据处理能力但缺乏审计能力的设备应升级为 cGMP标准。在设备缺乏这种能力的情况下,适当的控制(例如,基于纸张的)应该被实施以确保所有数据和信息的产生,以及所有活动的历史可供回顾。【解释了对于历史不合规数据和过渡阶段系统的管理和控制方法】

审核跟踪应包括所有可能的数据更改;据此跟踪记录,审阅者可以判别是否数据更改是否是一个异常事件。

不同类型的审计跟踪提供不同功能的数据,每个都应该单独评估。然后,所有审计跟踪都应该被集体评估,以确定数据的完整性。特定仪器的软件提供了用于配置审计跟踪和模板的若干字段。选择哪一个进行显示。

10说明了审计跟踪分类的一种方法。

质量部门负责启用全面功能的审计跟踪,评估不同类型。元数据的捕获,并选择哪些字段需要验证和确保数据的可靠性和完整性。这种方法应仔细选择,以设计最合适的程序。为批放行,以及定期的定期审查。 【目前的建议还是批放行阶段即进行审核】

以下列表给出一个建议,审计的各种审计跟踪,每一个都在下面的章节中讨论:
系统层面审计跟踪11):任何尝试登录、成功或不成功;每次登录尝试的ID、日期和时间;每次注销的日期和时间;使用的设备;以及登录时执行的功能,即用户尝试的应用程序;成功或失败。

图11 系统层面的审计跟踪

系统审核跟踪覆盖了系统策略更改、用户活动相关的活动(登录、注销、未经授权的登录和用户权限更改,对项目的更改(创建、删除、修改和恢复),证明项目的完整性和对系统的变更。质量系统应回顾system audit trail为任何类型的删除动作建立的周期性检查。12显示了系统审计跟踪中典型的项目删除。审核系统跟踪 在调查中检查登录和注销时间以及任何基于系统的信息  ,这不是在应用程序级审计跟踪上捕获的。

图12 系统层面的典型的项目删除

・应用层面审计跟踪13):监视和记录用户活动,包括打开关闭哪些数据文件,以及采取了什么具体行动,例如查看、编辑、处理和删除。 记录字段和发布报告。这也可以称为项目级审计跟踪。一些应用程序可能足够敏感,在之后的演示中可以看到,一个捕获“之前”和“之后”信息的审计跟踪。对于每个修改的记录或在记录中改变的数据.

图13 典型的应用层面审计跟踪

・方法审计跟踪(14):方法审计跟踪方法所做的更改,通常包含以下信息:方法修改历史; 用于所有进样的方法;方法在序列之间进行修改。

图14 典型的方法审计跟踪

・结果审计跟踪(或进样审计跟踪):色谱图或报告提供结果审计追踪。15是一个结果审计跟踪报告模板,它显示了积分类型、获取的日期、处理的日期以及由谁处理的日期,以及在生成数据之后色谱图是否被改变。色谱图通常应包含: 样品描述 ,样品采集的日期和时间,处理结果的日期和时间(如果有),最小的方法参数,比如波长、进样量和方法 名称/ID号,积分类型,保留时间、打印、发布或保存时间,积分事件,执行后的样品名称变更 。

图15 典型的结果审计跟踪
筛选器还可以用于从大量数据中搜索所需信息。16代表筛选器搜索在多个项目中的样品进样。对于旧系统在功能有限的情况下,复核人应在纸质上签名并印章结果并按照质量单位政策复核电子数据。如果结果是电子发布的,复核人在审核后对结果进行电子签名并锁定签名文件。如果它将被用于任何调查目的,当电子数据被认为是最终的数据,质量单位必须按照公司的政策审查电子数据。一旦打印的数据被审核过,原始电子数据应该仅用于参考,不可更改。对批准的数据的任何修改都需要证明。

图16 典型的筛选器审计跟踪

✔序列审计跟踪: 序列审计跟踪或样品集审计跟踪,跟踪对样品序列或批所做的更改。17表示典型的序列审计跟踪报告,一般包含以下信息:样品采集或进样后的进样名称改变、样品集变更、 在序列执行过程中更改样品名称、用于所有进样的方法、取消序列。

图17 典型的序列审计跟踪
✔项目审计跟踪:通过启用审计跟踪选项时可以激活,项目将捕获关于样本集、进样、通道、结果、校准曲线和峰执行的所有活动。图18显示了项目审计跟踪记录一个删除的事件,来展现欺诈性数据的示例。

图18 典型的项目审计跟踪

✔事件日志/系统错误日志:如果启用了审计跟踪,一般不需要检查进样日志。

虽然它是一个好的工具,但是对于确保数据完整性来说并不是必需的。事件日志和系统错误日志是实时的、即时的特性,它们显示关于系统功能、用户活动和硬件相关问题或错误的弹出消息(图19-20)。

图19 典型的色谱事件日志
图20 典型的系统错误日志

日志中出现的消息可能来自应用软件、第三方软件,例如支持色谱软件系统的Oracle数据库或其他连接仪器(连接到HPLC的天平)或设备。一些色谱软件包提供了这种功能。 事件日志是系统级消息,临时存储并经常自动清除。由系统以时间为基础的定义了间隔清除;因此它们的实用性是时间敏感的。这些日志可能证明有利于趋势(例如,趋势最频繁的仪器或处理错误)公司可以相应地利用这些信息,有助于故障排除或研究目的(例如描述失败原因)。

在软件验证期间,消息将根据列出的类别(例如,一般性、安全性)作为信息、警告或错误呈现。在事件日志中可能出现的关于数据操作或数据删除的关键消息和操作必须在经过验证的审计跟踪(例如,系统、结果、序列或示例,或方法审计跟踪)中捕获。

理想情况下,对软件和产品有影响的错误消息的分类将在软件开发和供应商验证期间合并。一些标题很关键的错误(例如,电缆断开、连接丢失、通信失败)可能不会在经过验证的审计跟踪中捕获,而是记录在事件日志中。可能很难确认这些类型的消息都是由故意中断引起的,或者对产品质量数据有任何影响。因此有必要是要有适当的控制和程序,以确保真正的停电记录,特别是如果色谱运行受到影响。

实验室的质量部门必须在设备安装和验证期间建立和验证错误信息。一些错误消息是特定于软件的操作系统的,与数据或设备操作没有直接关系。与软件供应商一起工作以理解记录在事件日志中的消息的描述是很重要的,因为它们可能在检查期间受到评估。此外,重要的是识别那些关键的消息,即与数据和仪器操作有关的消息。对于现有或先前安装的设备(例如,遗留系统),在安装和验证期间,质量部门应确保审查和理解所有事件性日志消息,并确保在已验证的审计跟踪中识别关键消息。不需要保留不影响产品分析或质量属性的事件日志消息以及也记录在已验证的审计跟踪中的消息。

例如,如果从HPLC到LAC/E BOX的连接断开,那么数据将不被捕获,并且事件日志将显示消息作为由于连接断开导致的系统中断。

其他类型的设备 :事件日志也可从其他类型的自动化分析设备获得,如X射线衍射(XRD)或水分仪(KF)。图21说明如果审核员没有在系统上进行全面培训,则日志条目可能产生误导

图21 XRD系统典型日志案例

例如,尽管一个条目在XRD日志中读取“Deleted the journal entry”,但是显示消息的实际原因是作业中断。质量部门应该识别记录在事件日志中的关键消息,并确保它们记录在已验证的审计跟踪中。 【作业中断:(删除了未执行的后续ID’s),这些ID’s实际没有任何数据被生成。】

vi. 数据的备份和恢复:实际上这部分工作也是各大仪器供应商提供的系统验证服务包中最为匮乏的一个部分,也给企业长期稳定运行系统带来了很大的困扰。

对于混合系统而言,暂时存储的数据会被覆盖,打印出来/输出的记录是初级数据源。SOP必须规定如何规范使用这些打印出来/输出的记录。

对于计算机化复杂系统而言,所有产生的电子数据的备份,推荐把数据拷贝到硬盘上,拷贝到盘上的数据应检查是否完整和准确。这个对于网络版本的体系而言,就有明显的天生优势了,这个备份的过程完全采用避免人工干扰的形式进行。但是需要提醒的是,即便是服务器自动备份的方式,也需要是在两个不同的地点保存两份数据拷贝. 如果采用了任何云存储服务器,则云端的备份也应该应符合GMP进行必要的验证确认。

对于计算机复杂系统来说,一般还会有SOP规定基于风险的冷备份(一个预定的备份,没有任何人工干预)以避免出现意外和法规复杂性,如果备份中采用了电子签名体系,电子签名应符合21CFR Part11,并包括日期和时间戳。

在实际的操作中,企业应该有专门的电子数据备份,恢复和灾难管理SOP来规定这些行为,并做为全生命周期的一个重要环节去定期挑战这些备份和恢复操作的可信度。为了不对现有正常运行数据带来不良的影响,可以考虑采用虚拟服务器的方式进行一些挑战性工作,这些细节需要公司IT和供应商一起进行通力合作来解决。

FDA警告信中关于计算机化复杂系统的数据完整性的常见典型错误如下:
计算机单机系统:            
✔共享密码            
✔不控制数据生成            
✔修改数据采集日期和时间戳以改变实际的结果日期和时间            
✔没有自动软件更新的控制            
✔计算机系统/软件验证错误            
✔实验室内所有设备和计算机的时间同步
✔计算机系统中数据库不适当的保护
✔分析师未经授权的更改            
✔修改或设置计算机的时钟或色谱进样的日期和时间
服务器网络版系统:            
✔缺乏质量部门的监督            
✔验证错误            
✔导致数据传输损失的不当网络映射            
✔没有验证数据传输和数据丢失的云系统
分析仪器设备             
✔直接在仪器上进行的测试样品的单次进样或样品试验进样            
✔在没有服务器的情况下连接到计算机的独立设备(单机版)缺乏控制、常规审计跟踪检查以及防止分析员或其他人员删除数据的完整数据保留能力            
✔没有适当选择或参与的特征,例如,在没有在审计跟踪中捕获的情况下提供试验进样(意味着实验室人员缺乏理解或验证)            
✔计算机或存储设备的配置不当,可能导致数据的重复或伪造(意味着缺乏对IT人员的培训)            
✔不评估停电造成的数据损失            
✔改变系统的适应性,使其看起来像是由设备故障引起的样品失败
数据处理             
✔试进样试验样品            
✔数据完整性受损问题            
✔不审核/发布/启用审计跟踪            
✔不报告事件            
✔重新测试样品,删除OOS结果,只报告合格的结果用于稳定性或放行批次
✔数据删除            
✔数据操作,例如改变积分、日期和时间或方法参数            
✔数据未存档
✔ 数据存档在不可读取的磁盘
✔由于对相关数据完整性领域缺乏理解,审核人无法发现问题。            
✔中止序列
✔没有适当的科学论证,抑制峰/忽略峰

转载于海螺研习社微信公众号

发表于 2018-10-8 14:36:35 | 显示全部楼层
发表于 2018-10-8 14:42:14 | 显示全部楼层
发表于 2018-10-8 16:21:18 | 显示全部楼层
发表于 2018-10-8 17:03:38 | 显示全部楼层
发表于 2018-10-8 18:18:30 | 显示全部楼层
发表于 2018-10-9 14:34:04 | 显示全部楼层
发表于 2018-10-10 14:22:16 | 显示全部楼层
发表于 2018-10-11 23:14:21 来自手机 | 显示全部楼层
把流程搞得越复杂,也就越难作假,或者说做假的代价越高,不如重新来过也就避免了作假,从简单流程到复合流程,结果还是可以作假虽难度提升,但总能找到bug点,就像写程序一般。
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

×友情提示
1、无权下载附件会员可能原因:1.“待验证用户组“,请点击注册邮箱里面收到的确认邮件即可; 2.作者设定权限的,提高用户组级别即可
2、对本站的任何疑问或合作需求,请联系微信tank066,关于怎样提高用户组/积分:https://www.ouryao.com/thread-6764-1-1.html
3、注册用户在本社区发表、转载的任何作品仅代表其个人观点,不代表本社区认同其观点。
4、如果存在违反国家相关法律、法规、条例的行为,我们有权在不经作者准许的情况下删除其在本论坛所发表的文章。
5、所有网友不要盗用有明确版权要求的作品,转贴请注明来源,否则文责自负。

QQ|手机版|蒲公英|ouryao|蒲公英 ( 京ICP备14042168号 京ICP证150354号 )

GMT+8, 2018-12-10 17:59 , Processed in 0.149104 second(s), 49 queries .

Powered by Discuz! X3.2

© 2001-2012 Comsenz Inc.

返回顶部