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

第一章介绍此指南的第一章是介绍，介绍此指南的根本状况。首 先大家要明确一点，此指南是替代原先的3本指南，分别是ISPE基准指南5调试与确认（第1版），ISPE指 南：基于科学和风险的设施、系统和设备交付方法， ISPE良好实践指南：基于风险评估方法的调试与确认。其次版指南的C&Q流程跟第一版完全不一样，以以下 图是第一版中的C&Q流程，以V-模型为主要方式，强调 确认源于设计的理念：ISPE Baseline®第五卷调试与确认（第一版，2023）其次版则着重强调了与工艺参数和属性相匹配的系统 从选型开头，至设计、确认的过程，以 CQA和CPP为起 点，如以以下图： 建立一个更大的团队，工作包括：审查这个初始基准 草案，做出任何必要的修改以确保信息是正确的，没有遗 漏任何风险或把握，并布置系统风险概要的后续工作。 第一步：开发基准指南小的团队开发早期的基准草案应当考虑以下方面： 有阅历的指导者来指导这个过程 有质量部门的代表 工艺/系统主题专家（可能是一个主题专家，或者可以考虑增加包括供给商代表）参考19章（附录5）的基准系统风险评估的例子其次步：执行系统风险评估当最初的基准指南完成后，更大的团队会审核文件和确定风险概要。这个审查小组一般由具有不同阅历的更广 泛团体的代表组成，以供给一个平衡的观点；这个小组可 以包括： 操作人员（生产） 维护人员 工程人员 工艺开发人员 供给商代表在确定风险概要之前，团队确定风险的来源 （潜在的失 败模式），以及可以减轻或消退风险的设计方面和 /或程序 把握。风险等级的定义：O低风险：被认为是可以承受的，不需要实行任何行动。定 义的把握操作发生风险的可能性被认为是低的，并且探测 是稳健的。O中风险：通常被认为是不行承受的，需要通过设计 （CAs/CDEs）和/或程序把握来缓解。然而， SME评审人 员可能认为特定流程/系统可以承受中等风险，并打算接 受该风险。o高风险：被认为是不行承受的，需要通过设计和/或程序把握来缓解。在某些状况下，SME评审人员可能会认为这些把握是不适宜的，例如，假设风险发生、操作挑战或 其他缘由，实现本钱将超过已发生的本钱。SME评审人员可以推举承受风险较高的系统，在这种状况下，评估需 要被高层治理人员承受。风险级别是通盘考虑工艺后定义的，因此，假设工艺 变了，系统风险评估需要审核 /升级。这方面应当通过变 更治理来解决（参见第12章）。确定风险概况需要基于 SME在工艺/系统方面的阅历。在定义失败或发生危急的 风险时，SME应考虑所列的把握措施已到位，并按预期 运行。在系统风险评估期间定义的设计把握（CAs和/或CDEs）被认为是系统需求的一局部，应包括在URS内。在系统风险评估完成后，应更URS ,纳入这些把握措施。假设使用追溯矩阵作为治理C&Q执行过程的工具，那么CDEs可能只添加到追溯矩阵中，而不需要更URS o在系统风险评估期间确定的程序把握需要包括在 C&Q打算范围内，也可以添加到追溯矩阵中。第三步：使用已完成的评估作为系统基线草案的起点完成系统风险评估所获得的阅历和文档可以应用于未来的系统。此外，很多用于制药生产和包装的系统都是标 准系统，它们已经使用了一段合理的时间，具有内置的控 制策略，并且由阅历丰富的供给商开发，拥有已建立的工程质量系统。因此，任何与现有系统一样或相像的系统 都可以使用已完成的系统风险评估作为起点。开发基线草案的小型团队应依据一样/相像的现有系统的已完成的系统风险评估对系统进展评估。SME应当确定 所审查的系统是否具有不同的功能和/或组件。假设SME确定这些差异可能会带来额外的或不同的风险，那 么需要更基线草案，以包括风险和相关的风险把握。系统风险评估程序的其余局部将依据其次步的描述进行。更大的团队审查基线草案并确定系统的风险概要。使 用已完成的评估作为系统基线草案的起点，可以提高过程 的效率和全都性。ISPE Baseline®第五卷 调试与确认(其次版，2023 )流程的第一步是输入，包括产品和工艺风险评估和控 制策略所得的CQAs/CPPs ,合并法规要求、操作要求、 EHS要求等指导URS的编写，标记为蓝色的即是后面的 每一章，从URS到定期审核，以及支持程序和执行策 略。我在后面的每一章介绍时会具体解读。此指南最大的一个变化是风险评估方法的转变，由第 一版的系统影响性评估(SIA )和部件关键性评估(CCA ),变为系统影响性评估和关键设计元素基于决 策树方式的系统级别推断和基于CQAs/CPPs的系统风险评估(SRA ),在第3章和第4章会跟大家具体解读。相关课程推荐扫码或者第一章介绍此指南是ISPE基准指南：调试与确认的其次版，所 以此指南前一版中描述的 C&Q方法的某些方面已经废 弃，并被QRM和GEP取代，同时此指南提出了一些 的概念及方法。废弃的方法和概念 部件关键性评估：此评估方法被关键设计元素（CDE ）所 替代。很多做过部件关键性评估的同事都说，系统影响性 评估还简洁一些，部件关键性评估太难了，假设 供给商资 料不全，假设对设备的几百个部件不了解，部件关键性评 估根本无法开展。我个人的建议，在设备首次验证的时 候，部件关键性评估可以被关键设计元素（ CDE ）所替 代，但是在设备维护保养及设备变更治理的时候，部件关 键性评估还是一个很有用的工具。间接影响系统：原先系统影响性评估把系统分为直接影响 系统、间接影响系统和无影响系统三类，的系统分类把系 统分为直接影响系统和非直接影响系统。间接影响系统和 无影响系统只需要做调试，不需要做确认，合并成非直接 影响系统，简化了分类。V-Model模型：V模型由集成的基于生命周期的 C&Q方 法所替代，流程图见上一篇提出的方法和概念Critical Design Elements(CDEs)关键设计元素：设计工程系统的功能或特征，这些功能和特征对始终如一的生产 符合所要求质量属性的产品是必要的。基于对产品CQA ,过程CPP和设备设计/自动化的技术理解，来识别 和记录CDEs。CDEs通过C&Q进展验证。CCA走了， CDE来了，这东东也不好整啊。产品影响属性：在做CQA和CPP评估的时候，会遇到一 个问题，对于直接用于药品生产的系统，这些术语很简洁 识别。但是，当评估到关键的公用工程，比方注射用水(WFI )系统，可能没有产品 CQA，但确实药典对WFI 有要求和CPP也需要把握，那么如何界定呢？此指南给 了建议，可以把这些参数定义为关键参数，但不能称为最 终产品质量属性。但为了统一，此指南对全部系统都使用 CQA和CPP术语，包括WFI和上游设备。我们在使用 这些概念的时候为了避开产生混淆，也可以引入关键物料 属性(CMA )的概念，从CMA的角度动身，则这些系 统照旧具有较高的关键性。其次章用户需求说明用户需求说明(URS )被认为是一个最关键的文件， 也是一个最根底的文件。此指南中指出，URS可以包括多种形式，例如正式的文件、购置恳求、功能说明、变更 恳求或技术数据表。针对一些固定型号的系统，或依据GAMP5判定为3类软件的非配置软件把握的系统，一个 技术数据表可能比十多页的URS文件更适宜。 URS的开发如何开发或编写一份合格的URS ,对系统使用者来说是一个困难的任务，此指南给出了建议的流程图：阴影框表示产品和工艺要求和来源。此指南还给了一份十多页的 URS模板，有确定的参考价 值。 URS的批准和变更此指南提出，URS应由系统全部者、适宜的主题专家和 质量部门的批准。但是，假设质量部门已经批准了包含 URS中质量要求的源文件，那么质量部门就不需要批准 URS o 遗留系统对于一些没有URS的遗留系统，可以依据改造的需求开 发 URS o第三章系统分类本指南依据系统对产品质量的影响性，将系统分为两类, 如下： Direct impact systems（直接影响系统），进展调试和确认, Not direct impact systems（非直接影响系统），进展调试系统分类的问题：本指南介绍了由八个问题组成的系统分类问题，对至 少一个问题的YES响应说明该系统是直接影响系统。此 八个问题跟ISPE指南：基于科学和风险的设施、系统和 设备交付方法中的八个问题差异不大，根本是微调：。系统是否包含CAs / CDEs或执行功能用于满足一个或多 个工艺要求（CQA ）,包括CPPs ?o系统是否与产品或工艺流直接接触，并对最终产品质量 有潜在影响或给患者带来风险？o系统是否供给辅料或生产某一成分或溶剂（例如，WFI ）,并且该物质的质量是否会影响最终产品质量或给 患者带来风险？o系统是否用于清洁、消毒或灭菌，并且系统故障可能导致 清洁、消毒或灭菌的失败，从而给患者带来风险？O系统是否为工艺供给一个 适宜的环境（例如，氮气保护， 密闭工艺，暴露灌装区的空气质量，温湿度的维护，且这 些参数为产品CPP的一局部时），且系统功能假设发生 故障，会给患者带来风险？O系统是否产生，处理或存储用于产品放行或拒收的数据,关键工艺参数，或21 CFR Part 11 和EU GMP VoL 4, Annex 11中相关的电子记录？o系统是否供给容器密封或产品保护，如失败将会给患者带 来风险或导致产品质量下降？o系统是否供给产品识别信息（例如，批号，有效期，防伪 功能），对此系统没有进展独立确实证或者此系统是用于确证这些信息？此指南配套供给了 2个表格，系统分类的空白表和典 型CQA和CPP的直接影响系统的例如表-即找了一些直 接影响系统，说明这些系统到底影响哪些 CQA和哪些 CPP ,第2个表格的参考意义大一些。第四章系统风险评估口对于直接影响系统，上一版的调试与确认指南给出的 建议是做部件关键性评估，这一版指南给出的建议是做系 统风险评估。部件关键性评估针对的是部件，一个系统或 许有几百个部件，对系统或设备不生疏的人员，很难开展 部件关键性评估；另外，假设系统或设备的设计图纸或设 计资料不全，也无法进展。系统风险评估，是从 CQA和 CPP动身，找到关键设计因素（CAs和CDE ）,通过程 序/报警/参数范围等把风险降低至可承受范围的方法。系 统风险评估偏工艺及功能评估，根本按系统的功能单元来 评估，此评估比部件关键性评估的难度低一些，但是假设对工艺和系统没有确定的了解，系统风险评估也无法到达 全面把握风险的目的。所以此指南强调，在进展系统风险 评估的小组内，应当有对工艺和 CQAs相关风险有科学理 解的主题专家(SMEs) o此指南建议直接影响系统均需要进展系统风险评估。 其他一些组织建议对于标准的成套设备和简洁设备，假设 不进展系统风险评估，可以用安装确认和运行确认等代 替。我个人的意见，直接影响系统均需要进展系统风险评 估，由于一个系统可能构造简洁，但假设此系统影响 CQA和CPP ,所以还是需要有程序/报警/参数范围等把 风险把握住。以以下图C&Q活动和文件的关系图系统风险评估。当系统风险评估完成后，应当确认 URS中已经包含了 关键方面/关键设计元素，假设没有包括，URS应当升级 并增加相关内容，程序把握元素应当增加到 C&Q的范围 内。系统的接收和放行包括系统风险评估中确定的把握措施如 下：设计把握(CAs/CDEs )已经显示依据既定标准实施。程序把握已就位。传统确实认方法不直接利用调试的文件，反而常常依 赖与额外的文件，如安装确认(IQ )和运行确认(0Q ) 方案。此指南提倡更合理的方法进展 C&Q ,可以通过工 程文件(如调试检查和测试文件)来供给文件证据证明系 统已经依据要求进展了安装和运行。系统风险评估可以到达多个目的： 识别、评估和记录关于 CQA和相关把握的质量风险确定和记录把握和治理己识别的风险所要求的设计及程 序把握 相关的把握也可以在系统风险评估中记录。 设计把握(CAs/CDEs)的测试和程序把握确实证供给了用 于支持系统确认的文档供给了 DQ的范围，如DQ的范围应当包含CAs/CDEs 的设计 供给根本的接收和放行要求的信息。 为质量部门的监视供给了重点第四章系统风险评估2系统风险评估的流程系统分析评估的先决条件是，CQAs和相关CPPs已经在URS中定义和记录。此指南建议通过下面的方法来开展系统风险评估。建立一个小的团队，用于开发初始的基准指南，包含工艺开发描述，以及设计和程序把握的定义。