由于最近多次遇到DQ的问题,基于对验证的理解,遂以此文抛砖引玉。企业在设备用户需求说明(URS)中,往
往要求供应商提供DQ方案和报告。供应商却不知在现有的各种设计文件中,哪些可以作为DQ文件,因为在其文件体系中,没有一个被称为DQ的文件。
于是,供应商去问客户,您所说的DQ文件是到底什么样的文件,需要包括什么内容呢?用户也说不清楚,只知道DQ文件很重要,是必须的,而且设计由供应商完
成,那么再根据URS完成DQ,顺理成章。再者,某些指南也建议用户“尽可能利用供应商提供的测试和文件”,那
么找供应商来提供DQ文件,用户只需最终确认并签字,一切便安好。如此而言,难道DQ文件可以只是一份写着"DQ"二字的文件?
1 什么是DQ?
DQ,即Design Qualification,设计确认,简言之,就是对供应商提供的产品设计与用户URS要求的符合程度进行确认。
EMEA GMP附录15确认和验证中,对DQ的定义为:The documented verification that the
proposed design of the facilities, systems and equipment is suitable
for the intended purpose.
即,有文件记录的确认过程,证明设施、系统和设备的设计符合其预定用途。设计确认是设施、系统和设备从用户需求说明到终止使用整个生命周期中的一个环节。
DQ应证明设计符合GMP要求并有文件记录。URS中的要求应在DQ中进行确认。该定义和要求与PIC/S GMP附录15的要求是一致的。
CFDA发布的GMP第七章中对设计确认的要求为,应该以文件和记录证明厂房、设施、设备的设计符合预定用途和本规范要求。在2015年新增发布的附录
《确认与验证》中描述设计确认应当证明设计符合用户需求,并有相应的文件。该附录也给出了设计确认的定义:为确认设施、系统和设备的设计方案符合期望目标
所作的各种查证及文件记录。
由此,DQ的几个要素便清楚了,即要求、设计、符合性检查、文件记录。DQ就是有文件记录的,将设计与要求的符合性进行确认的过程。在DQ中,我们确认
的,通常包括以下几个问题:
能否达到预期用途?
配套公用工程是否满足?
能否通过测试进行验证?
是否符合产品质量的要求?
是否符合法规监管的要求?
2 为什么要做DQ?
在受GMP法规监管的制药行业,对此类“为什么”的问题,我们最常听到的答案便是“因为法
规要求”。这实际上只是表面的答案,因为“法规要求”的是DQ文件,也就是DQ被执行的证
据,而DQ的过程,之于任何一项设备采购活动,都是必然的。用户在确定购买或者付款之前,都会首先确认所购买的设备是符合其需求的。
在这个过程中,用户已经进行了DQ之实,并且可能已经保留了一些文件记录,比如URS响应表、设计方案沟通澄清的会议记录、投标方案评审记录等。我们缺失
的,可能仅仅是一份被称为DQ的文件报告。
进行DQ本身也是非常有益处的。在项目中尽早地发现设计或产品不符合要求,便能提前进行挽救并避免资金和时间的损失。如果设备已制造甚至交付,在IQ或
OQ中才发现问题,则有可能造成严重的时间延迟和昂贵的费用支出,甚至导致项目失败。
3 哪些系统要做DQ
在GMP监管的行业,我们流行且标准的回答是,“确认或验证的范围和程度应经过风险评估来确定”。企业应有计划
有组织地进行确认活动,包括DQ,而这些组织、计划及实施方式应在验证总计划(Validation Master Plan,
VMP)中进行描述。GMP规范中,第一百四十五条,明确规定企业应当制定验证总计划。因此,一个设备或系统是否需要进行DQ,理论上应当依据VMP的要
求。实践中,VMP可能还未制定。
VMP如何制定,或者在未制定VMP的情况下,如何判断一个设备或系统是否需要进行DQ。这需要从产品质量影响的角度出发,对该设备进行影响评估。参考
ISPE
C&Q指南的推荐,影响评估中定义为“直接影响”类的系统应进行确认,其它系统则可按照GEP
规范进行管理。
判断设备是否“直接影响”产品质量,应基于对产品、工艺和系统充分的理解,回答以下几个问题。如果对其中任何一
个问题的答案是肯定的,则该系统可以被判定为“直接影响”。需要指出,对这些问题的思考作为判断的重要依据,但
不应替代最终合适的有资质的人员作出的判断。
系统是否与产品直接接触?
系统是否为产品提供辅料、原料或溶剂?
系统是否用于产品或产品直接接触表面的清洗或灭菌?
系统是否用于维持产品性状?
系统产生的数据是否用于决定产品的放行?
系统是否为影响产品质量的工艺控制系统,且没有另一套独立的系统用来复核其性能?
4 怎么做DQ?
2011年,国家药监局药品认证管理中心组织编写并发布了《药品GMP指南》系列,其中“质量管理体系”一部在
“确认与验证”章节也对DQ的实施提出了一些指导意见。
通常,DQ包含以下项目:URS、设计说明文件、URS和设计说明对比、风险分析。DQ中将需求条款与供应商提供的详细设计方案进行核对,找出所有偏差项
目;考虑系统部件的关键性,对这些偏差项目进行风险分析,以确认后续降低风险的措施,如更改设计、确认中进行某项测试、增加相应的控制或检查程序等。最
后,基于以上信息编写DQ总结报告。
另外,对于需要进行DQ的设备或系统,我们仍然需要基于风险分析和科学的原则,确定该DQ的程度和范围,这取决于:
- 设备或系统对产品质量的影响
- 系统复杂性
- 对产品和供应商的熟悉度
- 设备标准化程度
对于标准化设计的设备,设计确认的内容可以根据设备的复杂程度以及“客户化”的程度相对简化,但至少需要确认标
准设计符合或超过用户需求,是可以接受的。如果是重复购买的设备,或者在原有标准设计上进行局部的定制,其设计确认的内容也可以相应简化。
5 什么时候做DQ?
进行DQ的时机,与DQ的目的是息息相关的,这可能是作出采购决策、作出付款决定、避免返工或改造等。另外,能否进行DQ,也取决于DQ所需的条件和设计
文件是否已经具备。根据项目的复杂性,DQ最晚也应在设备开始生产制造前,从而避免可能的返工或改造,甚至项目失败。
如下图显示(来源于ISPE C&Q指南,Enhanced Design
Review,与DQ同义),设计确认是在详细设计之后,设备制造之前进行。对于标准设备,无需定制设计过程,设计文件已经存在,便可以视设备的复杂性以
及供应商的配合,提前进行DQ。
6
谁来做DQ?
DQ应由具备合适资质的人员来完成。这里合适的资质,是指充分理解用户需求和法规要求,并且有能力对供应商的设计方案提出挑战。他必须是站在用户的立场,
可能是用户自己,也可能是来自第三方咨询,却不建议是供应商。因为供应商来做DQ,就好像运动员同时也是裁判,往往只会有一个结果“
通过”,问题却可能被留待项目执行的过程中逐渐暴露出来。此时,如果需要通过设计变更来解决问题,用户往往是需要付出额外成本的。
这并不是免除供应商的责任,而是指一个合理的DQ执行团队,应该由代表用户的人员来负责,供应商有义务配合。由于供应商最了解其设计,供应商的配合对于
DQ的高质量完成至关重要。对于目前用户要求供应商提供DQ的现象,我试图去理解,可能有以下几个原因:
1)用户没有合适资质的人员;
2)为了节省项目成本;
3)尽可能利用供应商的活动,减少自己的工作量。
7 结语
供应商提供的设计是否满足用户的需求,还是应当由用户自己来判断。试想您需要去购买一款手机,您已制定好所需的一些必备功能和要求,此时无论销售人员如何
推介产品优势并声称满足您的需求,您也会选择自己去核对并做出最终的判断。当然,如果用户未能明确提出URS,也便是没有了评价标准,可以参考&
amp;
amp;
amp;
ldquo;如何写好一份URS”一文。
笔者并不反对用户尽可能地让供应商去进行大部分DQ的工作,并保留自己最终批准的权力。但想指出,DQ的过程,是绝好的增加对工艺、设备或系统理解的机
会,它可能比后期供应商进行的设备原理、操作维护培训效果要好得多。
此文仅代表个人观点,欢迎交流讨论。~~