#确认 #确认4.0
导读
上一期,我们分享了《Qualification 4.0-Unused Opportunities》文章的第一部分。当时讲到确认效率低下的前3个原因以及我们的对应Tip建议。本文承接上一篇文字,先讲述确认效率低下的剩余4个原因及对应Tip建议。之后再对该文章进行总归、归纳。具体内容见:
4. 风险评估——数字化游戏
风险评估是原有的老说法,现在扩充为风险管理。当下对于GMP环境和风险管理而言已经确定并且比较重要的要求包含:基于相关工艺、产品乃至于最终用户来按计划执行潜在风险的识别、分析和评价;审核已确定的或仍需要采取的措施,来避免风险或将风险降低到可接受的水平;确保相关制定的措施得到实施,比如作为确认的核心要素;持续审查和调整风险评估,根据在持续运营过程中所了解到的情况对风险评估进行持续性的审核和调整。
特别是关于确认活动,现在非常清楚的是即使在这个阶段,也不是说只是一个单一的风险评估,而是要进行大量的单独的风险评估。必须考虑整个物流过程、各个技术系统、生产工艺、清洁工艺,以及灭菌和消毒程序等因素。风险评估除了输出设计标准和其他行动之外,确认和验证活动的范围和深度也可以由此得出(图 4所示)。
图4:不同层次的风险评估
在当今的制药行业中,风险评估并未以目标导向和务实的方式来执行。文件证据、包含相关的评估标准的失效模式和影响分析(FMEA)表和满足监管期望似乎是首要任务。对通用的技术系统基于相同的标准进行反复的讨论,然后FMEA的数值根据直觉来确定,所以最后出来的风险优先级系数结果是事先就已经知道的。
承接此处的剩余内容,可查看原文进行详细了解。此处我们仅摘取本小标题下的Tip供您参考:
Tip小贴士
应仔细考虑是否真的需要使用FMEA表计数,或者简单地分为“低”、“中”和“高”是否就足够了,通常最后的结果是一样的。应考虑由具体计划的操作引起的风险,所以应与专家一起基于经验进行审慎考量,如需要详细的技术知识,还应咨询系统生产商或供应商。
5. 设计确认——需要了解技术
由于设计确认(DQ)这个主题在后期才被引入法规中,对应要求也比较初步、原始。到目前为止几乎普遍接受的是,在DQ中将URS与功能/详细设计说明(FDS/DDS)进行比对,或者至少尝试这样做。
由于一个项目通常涉及多个专业学科(例如,建筑、基建设备、自动化、工艺设备),因此不可避免的是,必须与这些专业学科的专家进行深入讨论和确定什么时候哪个版本的文件要从常规的技术工作流程中挑选出来进行GMP审核,这种讨论甚至可能在项目开始之前执行。为此,建议制定相应的流程图,如图5所示:
图5:技术流程中GMP审核节点示例(摘录)
Tip小贴士
DQ应重点审核关键技术图纸和设计文件。应提前与相应的工程部门讨论工作流程,确定何时将哪个文档在哪个开发阶段拿出来进行审核,而不是将这类文件的每个版本都进行审核。通常情况下,审核确定方向的第一个版本、中间版本检查,当然还有对最后“放行进行施工”版本的检查就足够了。
6. 确认VS技术测试——假如 FAT 被误解
设计确认之后通常就是安装确认(IQ)和运行确认(OQ)。IQ是技术系统按计划进行细化解释、设计和安装的证据。OQ则是技术系统正常运行的证据。这无疑是历史最悠久的确认要素,现在所有的公司(包括供应商)都非常了解并建立了相关要求。具体的测试项目和测试范围也遵循普遍类似的标准。对于该部分,德恩可以提供给您的建议是:
Tip小贴士
风险评估应该用来确定确认活动的IQ和OQ阶段中真正需要证实的相关点。所有其他点,特别是常规测试,都应该转移到技术领域,比如,FAT、SAT和调试活动。技术测试的范围、深度和文档应在早期阶段与各技术部门商定。应确保技术测试文件是有序而务实的。应在确认文件中引用相关技术测试。质量部门只有在必要的情况下参与,比如确认文件。
7. 适当的文件化水平应当如何?
确认是一个系统的、有计划的、协调的、受控的,因此也是正式的流程。这正是这个工具的优势之一,为质量保证提供支持。为了尽可能完全排除不可接受的风险,采用系统化方法和文件化是必要的。这个非常重要,例如在空间技术领域,不要犯任何可能最终导致致命后果的错误。对此能有所帮助的是通过专家此前准备并经过多次检查和批准的检查清单来执行这项工作。但文件化水平要多高才是够?当然了,只要它仍然能为确认工作提供积极影响,那就可以接受。
Tip小贴士
重点应该放在确认的内容上,而不是表格形式上:应该证明什么、如何证明、由谁来做、验收标准是什么?文件应该设计得尽可能简单——少即是多。应坚持使用尽量少的首页签批人员。根据GMP要求明确规定相关责任人。避免使用不必要的检查表,尽可能以原始技术文件作为检查依据。文档编制后的初稿应该由经验稍欠的人员来阅读:如果这个人都能理解基本原理,那么这就是一个很好的文档。
04 确认4.0——未来会发生什么
工业 4.0、“物联网”、网络化和提供各式各样的数据:这是当前工业界的趋势,它也为效率提升和流程优化提供了新的方法。确认工作中若想要实现这一点,当然还是需要做很多准备工作的。例如:
确认的基本概念——监管部门允许什么和不允许什么——必须在相关法规中更详细、更具体地描述,并且必须更多地考虑技术方面的要求。一定的自由度有所帮助,但如果太自由就会适得其反。行业标准并不一定能提供更多的安全性。
对于通用典型的设备,必须推动其标准化。基本的工艺操作在制药和API行业都是众所周知的,它们所需的机器设备也是如此。
衍生于标准和规范的确认测试相关的数据信息,作为基础工具现在应当便于从互联网中直接获取(例如根据ISO 14644执行的洁净室测试)。
反之亦然,确认期间收集到的信息、结果和经验也应当存储在云端。这通常是没问题的,因为这些数据中的绝大多数都不是关键的专有技术。
如果我们按工业4.0的理念走得更远一些,那么我们可以假想一下:在某天扫描条码就可以从互联网上获取到具体机器/设备/仪器确认相关的所有信息和数据。无论是技术规范、详细图纸、资质证书、FAT结果,甚至是基础IQ和OQ测试的测试规范说明,无论在什么情况下,这都将是向前迈出的巨大一步,会在节省时间和成本方面产生重大影响。其中一些信息现在已经可以从网上获取到(例如设备手册、说明书),但遗憾的是只有部分信息,也不是针对有具体序列号的特定型号的机器。
05 结论
本文我们回顾了确认30多年的历史。从简单的、技术导向的检查清单开始,然后开发了DQ、IQ、OQ和PQ等基本要素。引入了基于风险的方法,将确认工作更多地关注患者安全的目标上,而不是只产生文件。设计了生命周期模型,确保在技术系统的使用寿命期间可以维持质量保证。通过在指南中引入URS和FAT等元素,建立了与工程活动的联系。行业权威机构对文件化要求和文书工作提出了建设性的评论,促使技术标准和建议越来越基于良好工程实践(GEP)。
然而形式主义的问题仍然存在,堆积如山的文件和工作量、并不总是有意义和目标导向的确认方法。还有的是,确认是花费时间和成本的因素,付出并不总是与结果成合理的比例。还有,GEP和GMP之间的交联只有零星的成功案例,良好工程实践的好处仍然没有被广泛认知。在这种背景下,“确认4.0”这个术语肯定是还用不上的,在有后续的提示之前都还是需要从我们的词汇表中删除。
尽管如此,对于所有想要提高确认的效率和意义的人,无论现代化理念还是云计算理念,在这里都给出了一些建议和提示。再次强调一下:
摆脱形式主义,将其减少到最低必要的限度——少即是多。
确保良好工程实践活动符合良好文件规范,并最大限度地利用它。
明确区分哪些是技术测试,哪些是确认中应当包含的内容。特别需要注意的是,URS应该是面向用户的文档,而不是一个技术规范。
基于常识执行风险评估,并以具体的关注点为重点。
仅在关键的GMP方面真正存在风险时,再让质量部门参与进来。
最后,建议仍然坚持同样具有30年历史的原则:GMP=Common Sense常识。