ISPE基准指南5《调试与确认》第二版.docx

1、ISPE基准指南5调试与确认第二版第一章 介绍此指南的第一章是介绍，介绍此指南的基本情况。首先大家要明确一点，此指南是替代原先的3本指南，分别是ISPE 基准指南 5 调试与确认（第1版），ISPE指南：基于科学和风险的设施、系统和设备交付方法，ISPE良好实践指南：基于风险评估方法的调试与确认。第二版指南的C&Q流程跟第一版完全不一样，下图是第一版中的C&Q流程，以V-模型为主要方式，强调确认源于设计的理念：ISPEBaseline第五卷 调试与确认（第一版，2001）第二版则着重强调了与工艺参数和属性相匹配的系统从选型开始，至设计、确认的过程，以CQA和CPP为起点，如下图：ISPEBas

2、eline第五卷 调试与确认（第二版，2019）流程的第一步是输入，包括产品和工艺风险评估和控制策略所得的CQAs/CPPs，合并法规要求、操作要求、EHS要求等指导URS的编写，标记为蓝色的即是后面的每一章，从URS到定期审核，以及支持程序和执行策略。我在后面的每一章介绍时会详细解读。此指南最大的一个变化是风险评估方法的改变，由第一版的系统影响性评估（SIA）和部件关键性评估（CCA），变为系统影响性评估和关键设计元素基于决策树方式的系统级别判断和基于CQAs/CPPs的系统风险评估（SRA），在第3章和第4章会跟大家详细解读。相关课程推荐扫码或者第一章 介绍此指南是ISPE基准指南：调试与

3、确认的第二版，所以此指南前一版中描述的C&Q方法的某些方面已经废弃，并被QRM和GEP取代，同时此指南提出了一些新的概念及方法。废弃的方法和概念部件关键性评估：此评估方法被关键设计元素（CDE）所替代。很多做过部件关键性评估的同事都说，系统影响性评估还简单一些，部件关键性评估太难了，如果供应商资料不全，如果对设备的几百个部件不了解，部件关键性评估根本无法开展。我个人的建议，在设备首次验证的时候，部件关键性评估可以被关键设计元素（CDE）所替代，但是在设备维护保养及设备变更管理的时候，部件关键性评估还是一个很实用的工具。间接影响系统：原先系统影响性评估把系统分为直接影响系统、间接影响系统和无影响

4、系统三类，新的系统分类把系统分为直接影响系统和非直接影响系统。间接影响系统和无影响系统只需要做调试，不需要做确认，合并成非直接影响系统，简化了分类。V-Model模型：V模型由集成的基于生命周期的C&Q方法所替代，流程图见上一篇新提出的方法和概念Critical Design Elements(CDEs) 关键设计元素：设计工程系统的功能或特征，这些功能和特征对始终如一的生产符合所要求质量属性的产品是必要的。基于对产品CQA，过程CPP和设备设计/自动化的技术理解，来识别和记录CDEs。CDEs通过CQ进行验证。CCA走了，CDE来了，这东东也不好整啊。产品影响属性：在做CQA和CPP评估的时

5、候，会遇到一个问题，对于直接用于药品生产的系统，这些术语很容易识别。但是，当评估到关键的公用工程，比如注射用水（WFI）系统，可能没有产品CQA，但确实药典对WFI有要求和CPP也需要控制，那么如何界定呢？此指南给了建议，可以把这些参数定义为关键参数，但不能称为最终产品质量属性。但为了统一，此指南对所有系统都使用CQA和CPP术语，包括WFI和上游设备。我们在使用这些概念的时候为了避免产生混淆，也可以引入关键物料属性（CMA）的概念，从CMA的角度出发，则这些系统仍然具有较高的关键性。第二章 用户需求说明用户需求说明（URS）被认为是一个最关键的文件，也是一个最基础的文件。此指南中指出，URS

6、可以包括多种形式，例如正式的文件、购买请求、功能说明、变更请求或技术数据表。针对一些固定型号的系统，或根据GAMP5判定为3类软件的非配置软件控制的系统，一个技术数据表可能比十多页的URS文件更合适。URS的开发如何开发或编写一份合格的URS，对系统使用者来说是一个艰巨的任务，此指南给出了建议的流程图：阴影框表示产品和工艺要求和来源。此指南还给了一份十多页的URS模板，有一定的参考价值。URS的批准和变更此指南提出，URS应由系统所有者、合适的主题专家和质量部门的批准。但是，如果质量部门已经批准了包含URS中质量要求的源文件，那么质量部门就不需要批准URS。遗留系统对于一些没有URS的遗留系统

7、，可以根据改造的需求开发URS。第三章 系统分类本指南根据系统对产品质量的影响性，将系统分为两类，如下：Direct impact systems（直接影响系统），进行调试和确认Not direct impact systems（非直接影响系统），进行调试系统分类的问题：本指南介绍了由八个问题组成的系统分类问题，对至少一个问题的YES响应表明该系统是直接影响系统。此八个问题跟ISPE指南：基于科学和风险的设施、系统和设备交付方法中的八个问题差别不大，基本是微调：o系统是否包含CAs / CDEs或执行功能用于满足一个或多个工艺要求（CQA），包括CPPs？o系统是否与产品或工艺流直接接触 ，并

8、对最终产品质量有潜在影响或给患者带来风险？o系统是否提供辅料或生产某一成分或溶剂（例如，WFI），并且该物质的质量是否会影响最终产品质量或给患者带来风险？o系统是否用于清洁、消毒或灭菌，并且系统故障可能导致清洁、消毒或灭菌的失败，从而给患者带来风险？o系统是否为工艺提供一个合适的环境（例如，氮气保护，密闭工艺，暴露灌装区的空气质量，温湿度的维护，且这些参数为产品CPP的一部分时），且系统功能如果发生故障，会给患者带来风险？o系统是否产生，处理或存储用于产品放行或拒收的数据，关键工艺参数，或21 CFR Part 11和EU GMP Vol. 4, Annex 11中相关的电子记录？o系统是否提

9、供容器密封或产品保护，如失败将会给患者带来风险或导致产品质量下降？o系统是否提供产品识别信息（例如，批号，有效期，防伪功能），对此系统没有进行独立的确证或者此系统是用于确证这些信息？此指南配套提供了2个表格，系统分类的空白表和典型CQA和CPP的直接影响系统的示例表-即找了一些直接影响系统，说明这些系统到底影响哪些CQA和哪些CPP，第2个表格的参考意义大一些。第四章 系统风险评估-1对于直接影响系统，上一版的调试与确认指南给出的建议是做部件关键性评估，这一版指南给出的建议是做系统风险评估。部件关键性评估针对的是部件，一个系统大概有几百个部件，对系统或设备不熟悉的人员，很难开展部件关键性评估；

10、另外，如果系统或设备的设计图纸或设计资料不全，也无法进行。系统风险评估，是从CQA和CPP出发，找到关键设计因素（CAs和CDE），通过程序/报警/参数范围等把风险降低至可接受范围的方法。系统风险评估偏工艺及功能评估，基本按系统的功能单元来评估，此评估比部件关键性评估的难度低一些，但是如果对工艺和系统没有一定的了解，系统风险评估也无法达到全面控制风险的目的。所以此指南强调，在进行系统风险评估的小组内，应当有对工艺和CQAs相关风险有科学理解的主题专家（SMEs)。此指南建议直接影响系统均需要进行系统风险评估。其他一些组织建议对于标准的成套设备和简单设备，如果不进行系统风险评估，可以用安装确认和

11、运行确认等代替。我个人的意见，直接影响系统均需要进行系统风险评估，因为一个系统可能构造简单，但如果此系统影响CQA和CPP，所以还是需要有程序/报警/参数范围等把风险控制住。下图C&Q活动和文件的关系图系统风险评估。当系统风险评估完成后，应当确认URS中已经包含了关键方面/关键设计元素，如果没有包括，URS应当升级并增加相关内容，程序控制元素应当增加到C&Q的范围内。系统的接收和放行包括系统风险评估中确定的控制措施如下：设计控制（CAs/CDEs）已经显示按照既定标准实施。程序控制已就位。传统的确认方法不直接利用调试的文件，反而经常依赖与额外的文件，如安装确认（IQ）和运行确认（OQ）方案。此

12、指南提倡更合理的方法进行C&Q，可以通过工程文件（如调试检查和测试文件）来提供文件证据证明系统已经按照要求进行了安装和运行。系统风险评估可以达到多个目的：识别、评估和记录关于CQA和相关控制的质量风险确定和记录控制和管理已识别的风险所要求的设计及程序控制-相关的控制也可以在系统风险评估中记录。-设计控制(CAs/CDEs)的测试和程序控制的确证提供了用于支持系统确认的文档提供了DQ的范围，如DQ的范围应当包含CAs/CDEs的设计提供基本的接收和放行要求的信息。为质量部门的监督提供了重点第四章 系统风险评估-2系统风险评估的流程系统分析评估的先决条件是，CQAs和相关CPPs已经在URS中定义

13、和记录。此指南建议通过下面的方法来开展系统风险评估。建立一个小的团队，用于开发初始的基准指南，包含工艺开发描述，以及设计和程序控制的定义。建立一个更大的团队，工作包括：审查这个初始基准草案，做出任何必要的修改以确保信息是正确的，没有遗漏任何风险或控制，并布置系统风险概要的后续工作。第一步：开发基准指南小的团队开发早期的基准草案应当考虑以下方面：有经验的指导者来指导这个过程有质量部门的代表工艺/系统主题专家（可能是一个主题专家，或者可以考虑增加包括供应商代表）参考19章（附录5）的基准系统风险评估的例子第二步：执行系统风险评估当最初的基准指南完成后，更大的团队会审核文件和确定风险概要。这个审查小

14、组一般由具有不同经验的更广泛团体的代表组成，以提供一个平衡的观点；这个小组可以包括:操作人员（生产）维护人员工程人员工艺开发人员供应商代表在确定风险概要之前，团队确定风险的来源(潜在的失败模式)，以及可以减轻或消除风险的设计方面和/或程序控制。风险等级的定义：o低风险：被认为是可以接受的，不需要采取任何行动。定义的控制操作发生风险的可能性被认为是低的，并且探测是稳健的。o中风险：通常被认为是不可接受的，需要通过设计(CAs/CDEs)和/或程序控制来缓解。然而，SME评审人员可能认为特定流程/系统可以接受中等风险，并决定接受该风险。o高风险：被认为是不可接受的，需要通过设计和/或程序控制来缓解

15、。在某些情况下，SME评审人员可能会认为这些控制是不合适的，例如，如果风险发生、操作挑战或其他原因，实现成本将超过已发生的成本。SME评审人员可以推荐接受风险较高的系统，在这种情况下，评估需要被高层管理人员接受。风险级别是通盘考虑工艺后定义的，因此，如果工艺变了，系统风险评估需要审核/升级。这方面应该通过变更管理来解决(参见第12章)。确定风险概况需要基于SME在工艺/系统方面的经验。在定义失败或发生危险的风险时，SME应考虑所列的控制措施已到位，并按预期运行。在系统风险评估期间定义的设计控制(CAs和/或CDEs)被认为是系统需求的一部分，应包括在URS内。在系统风险评估完成后，应更新URS

16、，纳入这些控制措施。如果使用追溯矩阵作为管理C&Q执行过程的工具，那么CDEs可能只添加到追溯矩阵中，而不需要更新URS。在系统风险评估期间确定的程序控制需要包括在C&Q计划范围内，也可以添加到追溯矩阵中。第三步：使用已完成的评估作为新系统基线草案的起点完成系统风险评估所获得的经验和文档可以应用于未来的系统。此外，许多用于制药生产和包装的系统都是标准系统，它们已经使用了一段合理的时间，具有内置的控制策略，并且由经验丰富的供应商开发，拥有已建立的工程质量系统。因此，任何与现有系统相同或相似的新系统都可以使用已完成的系统风险评估作为起点。开发基线草案的小型团队应根据相同/相似的现有系统的已完成的系统风险评估对新系统进行评估。SME应该确定所审查的系统是否具有不同的功能和/或组件。如果SME确定这些差异可能会带来额外的或不同的风险，那么需要更新基线草案，以包括风险和相关的风险控制。系统风险评估程序的其余部分将按照第二步的描述进行。更大的团队审查基线草案并确定新系统的风险概要。使用已完成的评估作为新系统基线草案的起点，可以提高过程的效率和一致性。