GAMP5中给出了8条让验证活动更有效的方法,我们分三天来说:
建立可测试核实的需求
手把手教你写用户需求和什么是好的用户需求?中分享了很多关于如何去写需求的心得,GAMP5中概述起来说有三个关键词:
定义完整---Fully Defined
可被核实---Verifiable
目标明克---Objective
用户需求不是拍脑袋定义出来的,应该是基于以下的几点考虑:
1)对产品工艺知识、业务流程、对产品质量属性的理解,任何自动化的系统都是为了支持工艺或者业务流程的。从产品的角度上来讲,产品有哪些关键的质量属性,这些关键的质量属性会受到哪些关键工艺参数的影响,对这些工艺参数要求控制的范围是什么,都是对自动化系统设计的输入;从业务流程的角度去讲,GAMP5用了一个很好的词,challenge against,这不是指人员之间的互掐,而是指对每一条需求的表述都要精心推敲,看和业务流程的要求是否匹配;
2)明确职责:在起草需求的过程中,各方面的职责是不同的,概述起来说,终端的用户部门负责人或者技术部门应该侧重于工艺知识的理解,并将工艺知识的理解转化成需求;供应商对于客户所提出的需求应该进行初步的把关,看自己的设备能否从技术上满足用户需求,或者结合自己产品的特点,给用户提一些改进的建议,而不能单纯为了卖出产品而进行忽悠;质量部门应该把握企业有哪些内部要求和外部法规要求,重点看验证的过程是否合规,而不是把质量部门变成所有领域的专家;
3)推敲每一条需求,做到需求的完整和准确,技术上可行,逻辑上合理,易于理解。
采用基于风险的决策法
基于风险的方法是GAMP5所一直强调的,尽管GAMP5中这段表述其实并不完全符合质量风险管理的理念:
基于风险的主要目的不是说定义哪些事情不做,而是应该侧重在哪些事情应该花更多的时间和精力,更有效的去做。
采用供应商的输入
之前写过一篇分享,供应商的文件可以直接用么,里面提到了哪些文件出自供应商其实是不合理的,当时提到了用户需求必需来源于制药企业,也提到了验证的计划往往不应该由供应商提供,应该由制药企业自己制订,不过这两天确实看到了一些NB的分析设备的供应商,居然除了传统意义上的3Q之外,还提供了确认计划,企业也对这份计划进行了签字确认表示认可,但是美中不足的是这个签字确认表示认可的过程更多的给我的感觉是流于形式,而没有真正起到确认这份计划是否符合企业标准的作用。
对于在哪些情况下可以采用供应商的文件,GAMP5给出了几点建议,需要对供应商进行如下的评估,包括对供应商的质量体系,技术能力以及供应商的一些项目的经验和能力评估。
GAMP5提出的一种观点其实还是比较新颖的,对于供应商的文件,制药企业的质量体系应该有一定的包容度,不要去过多纠结文件的格式而要关注内容本身
联系客服