由于最近多次遇到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的过程，是绝好的增加对工艺、设备或系统理解的机
会，它可能比后期供应商进行的设备原理、操作维护培训效果要好得多。
此文仅代表个人观点，欢迎交流讨论。~~