第三节--计算机化系统验证要点分析PPT格式课件下载.pptx

1、其中FMEA较为常用。风险事件识别在已经确定系统功能或子功能后，则应对造成相关风险的风险事件进行识别，并确定事件所产生的影响。风险发生概率的评判在确定所可能发生的风险事件及其影响后，应对这些风险事件发生的概率性作出判断。概率判断的标准并无统一规定，具体可根据事件的复杂程度来决定。较为简单的判断标准是将发生的概率分为高、中、低三个等级。风险事件严重性的评估风险事件影响的评估应当全面，不仅需评估风险的直接影响，还应评估这些影响对于企业的长期和广泛影响。某一风险事件可能导致与管理需求的危险的不一致，并且可能导致某些管理行为，严重性判断的标准同概率一样，并无统一规定，具体可根据事件的复杂程度来决定。较

2、为简单的判断标准是将事件的严重性分为高、中、低三个等级。风险等级的判定风险等级=概率严重性。风险等级由发生概率和严重性共同决定。评估风险检出率通过系统的方法，识别风险事件是否可以被确认或发现，即判断其被检出的能力。检出率判断的标准同概率一样，并无统一规定，具体可根据事件的复杂程度来决定。较为简单的判断标准是将事件的检出率分为高、中、低三个等级。制定风险降低措施在制定风险减低措施之前，应当对风险的优先程度进行判断，以决定是否需要采取相关措施。风险优先程度通常由风险优先数（Risk Priority Number，简称RPN）衡量，RPN=风险等级检出率。变更相关风险评估在系统的变更过程中，风险管

3、理的引入是非常必要的。风险评估表整个风险评估的过程是依靠风险评估表实现的，因此风险评估应该能够准确、全面地反映整个评估过程。（4）实施并验证控制措施）实施并验证控制措施步骤3中所确认的控制措施应该得到实施与验证。相关验证测试的广度和深度则取决于步骤3所得的风险评估结果。应对新引入的控制措施进行风险评估，确保其不会引入新的风险。（5）审核风险与监控控制措施）审核风险与监控控制措施系统正式运行后，应定期对系统及其控制措施进行审核，确保系统处于受控状态和控制措施处于有效的状态。风险审核的频率和范围由系统的风险水平决定。-考虑之前未被识别的危害是否存在；-判断之前确认的危害是否仍然存在，处于什么水平；

4、-之前所估计的危害的风险水平是否仍处于可接受范围内：-之前的风险评估是否仍然有效。Tip2 系系统统供供应应商商审计审计（1）确保QMS的一致性（2）完成对供应商的遴选（3）建立与供应商的长期合作供供应应商商审计实审计实施施步骤步骤（1）初步评估（Preliminary Audit）（2）详细审计（Detailed Audit）（3）后续审计（Follow-up Audit）（4）监督审计（Surveillance Audit）（1）初步评估-评估计算机化系统是否为成熟的、可信赖的产品，是否需要详细审计。主要评估产品市场信息（例如市场占有率）、产品历史、产品性能和供应商质量手册及其关键程序。-

5、确定一个准供应商清单。-向被审计供应商明确审计范围，为详细审计做准备。（2）审计准备设定审计范围组建审计小组联系供应商制订审计安排制订审计检查清单（3）实施审计 见面会审计应当以审计双方的见面会开始。现场审计现场审计应包括文件检查和现场检查两部分。通报会会议内容包括感谢被审计方对审计小组的热情接待，逐条通报审计中发现的缺陷项并讨论存在争议的缺陷项。（4）审计报告与缺陷信审计报告包括审计概况、审计范围、审计日常安排、审计检查内容、审计中发现的缺陷项，对该供应商的总体评价、审计结论以及审计日期和审计人员的签名。除了审计报告，审计小组还应将审计中发现的缺陷项以缺陷信的形式发予供应商，要求被审计方对缺

6、陷信中的内容作出及时的回复。（5）审核审计报告-无条件与供应商合作；-只使用供应商的部分产品或系统；-在供应商完成整改措施后，与其进行合作；-拒绝与供应商合作。（6）整改措施与后续审计对于审计方在缺陷信中所列出的缺陷项内容，供应商应该及时提出整改措施并验证整改措施的有效性。缺陷项可以分为关键缺陷（Critical Deficiency）、主要缺陷（Major Deficiency）和微小缺陷（Minor Deficiency）三类。当需要进行后续审计时，所采取的审计流程和方法可参考之前的详细审计，但应更具有针对性，可省略部分步骤从而简化审计流程。（7）监督审计监督审计所采用的审计流程和审计方法

7、应等同于之前的详细审计，但可根据之前审计经验简化审计流程，提高审计效率。Tip3 验证过验证过程的程的职责职责分配分配计算机化系统验证不仅应贯穿系统的整个生命周期，而且需系统涉及各方的积极参与。系统验证所涉及的相关方包括系统用户、供应商、系统维护部门和质量管理部门。上述各方在验证过程中应积极履行各自职责。1 系系统统用用户户（1）保证在制定URS时正确定义系统需求，并准确地反映功能需求。（2）起草系统确认（包括IQ、OQ和OQ）方案、执行确认测试、参与偏差处理及评价确认结果和撰写系统确认报告。（3）保证系统专用，由合格的、接受过培训的人员操纵。（4）对使用人员提供针对性培训。（5）建立并遵循系

8、统的标准操作规程。（6）保证各工作层使用权限，禁止未经授权的操作得到执行。另外，用户在数据贮、处理、检索中对保证安全的数据环境负有责任。（7）当使用过程中发现有不便之处时，可对系统的变更提出书面申请。（8）系统用户应参与对系统的周期性回顾，并形成文件记录。2 供应商（1）充分了解用户需求，严格按URS设计和开发计算机化系统。（2）接受系统用户质量体系审计。（3）在供应商处完成系统测试，包括单元测试及组装测试。（4）帮助用户完成计算机系统的安装及调试工作，必要时可与系统用户一起完成系统的确认测试工作。（5）供应商应为系统用户提供必须的技术培训，确保系统用户能够掌握操作和维护计算机系统的技能。（6

9、）在系统使用和维护过程中，供应商有责任为用户提供完善的售后服务，包括硬件的修复与更换、软件版本升级、系统运行故障修复等。3 系系统维护统维护部部门门（1）建立计算机化系统整个生命周期内所必须遵循的管理规程。（2）帮助系统用户建立系统需求定义，审核用户需求标准（URS）。（3）从技术角度完成供应商审计工作。（4）提供系统测试计划，建立测试环境，完成或帮助用户完成系统的测试工作，以保证系统的功能性。（5）从技术角度对计算机系统的变更实施控制，包括对变更申请的评估、审核，变更过程的控制、测试以及版本升级的管理等。（6）负责完成计算机系统软硬件的部分维护工作。（7）积极参与对系统的周期性回顾。4 质质

10、量管理部量管理部门门（1）建立计算机化系统整个生命周期内所应该实施的验证要求。（2）对所有的验证文件从 GMP 角度进行审核和审批。（3）从GMP角度完成供应商审计工作。（4）对所有验证实施过程进行控制，包括人员是否培训、是否严格按验证方案实施、结果是否符合预先设定的可接受标准、偏差是否得到有效处理等。（5）从 GMP 角度对计算机化系统的变更实施控制。（6）定期组织相关部门（包括系统用户和系统维护部门）对已验证过的计算机化系统进行周期性回顾。Tip4 相关相关验证验证文件文件形成相关验证文件是计算机化系统验证过程的重要组成部分，也是GXP管理的关键要求所在。1 用户需求标准（URS）介绍部分

11、。介绍部分。URS的相关信息：URS相关人员信息、文件的版本信息和与其他文件的关系。综述部分综述部分。对所需计算机化系统进行综述，解释“为什么需要”以及“需求是什么”。用户需求部分用户需求部分。对用户的需求做出了非常详细的定义。具体应当包括以下四部分：功能部分、数据部分、界面部分、环境部分。约束部分约束部分。对于系统开发的时间安排、兼容性、实用性以及工作程序作出了规定。生命周期部分生命周期部分。对整个计算机化系统验证的整个周期内的各项工作所需达到的要求作出了详细规定。术语部分术语部分。2 验证计验证计划与划与报报告告验证计划分为验证主计划（VMP）和具体验证方案（VP）两类。验证主计划前言。介

12、绍验证主计划的基本信息，例如起草、批准和变更信息、所涉及的范围、与其他文档的相互关系以及更新周期等。验证组织结构。规定所涉及的部门和人员及其职责。GXP关键性评估。规定GXP关键性评估的要求和基本流程。验证策略。概述所采用的总的验证策略、应遵循的验证程序以及所应用的生命周期模型。SOP和培训。规定如何编写或修改计算机化系统的SOP以及如何开展相关培训。变更控制。规定验证过程中变更控制的要求和流程。验证文件管理。规定验证文件管理的要求和流程。验证进度和资源安排。规定所需进行的验证的时间进度安排及其需配备的相关验证资源。术语部分具体验证方案1 介绍。2 相关职责。3 GXP关键性评估。4 验证策略

13、。5 验证交付条件。6 验收标准。7 验证程序8 变更控制。9 相关培训。10 文件管理。11 验证状态维护。12 术语。验证报告前言。验证结果总结。验证实施。偏差报告与处理。验证状态。培训。维护验证状态。术语3 功能功能标标准与准与设计标设计标准准1 功能标准功能标准-所有功能描述均应该明确定义；-措辞避免含糊、重复和矛盾；-使用统一的命名规则；-每个功能描述均应当是可测试的；-功能标准应当清晰、明确，便于相互沟通。介绍部分综述部分功能部分数据部分系统界面部分非功能属性部分术语部分2 硬件设计标准硬件设计标准介绍部分综述部分计算机系统部分输入输出部分环境部分电气部分术语部分3 软件设计标准软件设计标准介绍部分 综述部分 系统描述部分 系统数据部分模块描述部分 术语部分软件模块设计标准软件模块设计标准介绍部分 软件模块综述部分 软件模块数据部分 子程序描述部分 子程序数据部分 术语部分 Thanks!