计算机化系统验证.docx

《计算机化系统验证.docx》由会员分享，可在线阅读，更多相关《计算机化系统验证.docx（4页珍藏版）》请在第一文库网上搜索。

1、计算机化系统验证验证计划1验证策略11指导原则根据初步风险评估结果，本次XXX模块功能升级属于XX类系统，依据ISPEGAMP5指南的验证“V模型”为指导，结合质量风险管理的理念，规划基于E1M模块完整的验证生命周期活动，主要分为以下五个部分：Ø计划阶段Ø规范阶段Ø配置开发阶段Ø测试确认阶段Ø总结阶段1.2.验证V模型13.验证的生命周期方法131.计划阶段13.1.1.供应商评估XXX确保供应商遵守广泛认可的国际标准、国家标准或行业标准等（如ISO、GB、HB等），因此对供应商XXX的质量体系、人员资质及开发过程等进行了评价。评价结果为合格，

2、具体参照供应商调查问卷及其附件。13.1.2.用户需求规范用户需求是项目实施验证的基础，用户需求规范将需求以可追溯的方式进行编号和分类，系统的设计、测试及验证均会追溯同用户需求说明，以确保所有已定义的需求都得到实现。完整的用户需求规范已由上海药明康德指定人员进行起草、审核和批准，参考用户需求说明。1.3.1.3.初步风险评估应对系统进行初步风险评估，评估系统的GXP关键性及系统影响，并根据GAMP5对系统进行软硬件分类，确定系统验证的生命周期活动，结合21CFRPart11）的法规要求，评估系统电子记录和电子签名的适用性，根据初步风险评估（文件编号：）的内容，得出结论需要对系统进行完整的验证。

3、132规范/设计阶段规范文件包括功能规范（FS）、配置规范（CS）,功能规范（FS）的内容覆盖所有的用户需求。本次XXX模块产品升级仅涉及功能规范、配置规范等。13.2.1功能规范功能规范将描述系统应有的功能，说明用户需求是如何被实现，所有的功能应体现在此文档中，最终可以以模块的形式呈现。功能规范中每一个功能说明应有唯一的标识。13.2.2.配置规范配置规范记录系统的所有配置信息，以实现XXX的个性化的业务要求。在配置规范中会对XXX模块中的配置进行定义。项目完成后，配置规范中定义的配置参数将作为系统维持验证状态的基准。1323设计规范设计规范主要针对XXX为满足XXX个性化需求进行的定制开发

4、部分内容。系统设计规范（DS）是为系统开发人员提供构建系统所需的信息，以便系统维护人员了解系统的预期功能，并了解如何完成功能而无需分析人员阅读源代码。设计规范必须对每项要求是如何实现的做明确地记录。系统的设计也应有明确的说明。在设计中使用的所有标准语言和工具均应被清晰地定义。1.3.2.4.设计确认设计确认是在规范阶段末尾的正式文件审查活动,通过文件记录的方式证明系统设计符合预期用途的活动。设计审查是一项在整个项目设计阶段持续进行的过程，以保证所有与设备或系统的具体项目相关的设计文件（例如功能说明、配置说明等）均符合GxP法规要求，而且设计能够满足URS要求。将根据对URS和系统/设备供应商所

5、提供的设计文件进行比较来编写DQ方案及DQ报告。132.5.功能风险评估质量风险管理贯穿于系统的整个生命周期。在评估过程中，应考虑业务流程风险、GXP合规风险和系统功能风险。风险评估过程允许项目组去识别和最小化不利事件的影响，同时为支持系统验证的验证方法提供了必要的理由。风险评估具体执行分为以下2个步骤：1）确定对患者安全、产品质量和数据可靠性有影响的功能针对系统所要实现的功能从“GxP关键性”“影响级别”两个层面上进行判断和分析，确定并识别系统对于患者安全、产品质量和数据可靠性有影响的功能。2）实施功能性风险评估并识别控制措施通过考虑可能的风险及确定如何控制由这些风险所引起的潜在危害来对关键

6、功能进行评估。应基于评估结果确定适当的控制措施，这些措施包括但不限于以下形式：Ø修改电子实验室管理流程设计或者系统设计；Ø通过外部程序；Ø提高规范的详细程度及正式程度；Ø增加设计审查的次数与详细程度；Ø增加验证活动的范围与严格性。133.测试/确认阶段13.3.1.工厂验收测试活动涵盖在XXX内部环境中的设计开发活动相关的所有测试，这些测试包括代码审核、单元测试、集成测试、系统测试，测试完成后会输出报告。1332现场验收测试SAT期间，XXX将在开发环境进行现场演示XXX模块的优化内容和新增功能，以确认设计原型是否符合XXX的用户需求。完成这些

7、活动后，若XXX确认原型符合预期需求，XXX将出具现场验收测试报告及记录作为项目交付物。原型确认后，系统将作为初始版本，作为转入验证环境中确认之前的软件基础版本。13.3.3.安装确认安装确认分为2个阶段，分别在验证环境和生产环境中进行。前置条件:。范围：活动：1.3.3.4.运行确认运行确认在验证环境中进行。前置条件：范围：活动：13.3.5.性能确认性能确认在生产环境中进行。前置条件：范围：活动：13.4.总结阶段134.1. 风险回顾在所有的确认活动完成后，对验证过程中发生的风险事件进行回顾分析。对风险评估活动中识别出的风险项在确认过程中仍出现偏离/变更的条目进行回顾分析；这些风险项虽然

8、已经采取了控制措施，但在确认活动中仍出现偏离/变更，说明该风险控制措施没有完全把风险降低，应结合偏离/变更的处理的结果，再次重新评估经过偏离/变更处理后的风险优先级，并考虑是否需要采取更严格、更有效的控制措施。与此同时，在确认过程中有系统功能之外的风险事件发生，同样以偏离/变更的形式进行了处理，将与功能风险一起进行回顾分析。134.2. 需求追溯矩阵需求追踪矩阵将作为一个单独的可交付物生成。它提供了用户需求、设计、配置和测试、确认活动之间的可跟踪性。在实际中，需求和不同的设计、配置或测试用例之间通常不是简单的一对一关系。一个配置或测试用例可以满足多个需求，或者一个需求可能需要多个不同的配置或测

9、试用例才能满足。134.3. 验证总结报告前置条件：在PQ完成之后，且需求追溯矩阵已批准。验证总结报告对验证结果进行总结，并给出结论，即所有需求都得到了解决。验证活动的执行、取得的结果、符合的标准和测试问题将在验证总结报告中进行总结。在验证总结报告获得批准之前，验证活动产生的任何问题都必须得到解决或适当地处理。2.验证支持工作验证状态的保持需要依赖于一套有效的质量管理规程：标准操作规程（不限于以下：使用，维护，审计追踪审核）、定期评审、培训、变更控制、事件管理、业务持续计划、灾难恢复计划等。2.1. 标准操作规程在系统上线前，上海药明康德业务部门应根据需要更新系统操作、业务流程操作、运维SOP

10、（如适用）以配合系统的使用、维护，如：问题管理流程、数据存储、数据备份、安全管理，权限管理，审计追踪的审核、日常检查流程、系统操作规程。22定期评审计算机系统需进行定期评审，以确认系统的验证状态未发生偏移，定期评审的周期应当基于科学的风险评估来确定。2.3. 培训I2.3.1. 培训计划与实施232.关键用户培训2.3.3.供应商培训1.1 .最终用户培训1.4 .变更控制25偏离管理1.6 .业务持续性计划1.7 .灾难恢复计划3 .可交付成果下列表格中的文件将作为交付成果的指导项，交付成果中的具体编号、文件名称和数量以实际为准。4 .可接受标准验证活动的可接受标准是：a.所有文档交付的内容

11、必须根据验证计划加以制定、审核和批准。b.验收活动出现以下情况：1）若URS中的所有条目完全满足，则为完全接受；2）若URS中存在部分条目不完全满足，则接受已完全符合的条目，并对不完全符合的条目进行评估，以确定是否接受该条目；3）若URS中存在部分条目完全不满足，则通过变更流程重新设计该条目相应功能，执行必要的评估和确认活动。C.用户需求必须可追溯到规范和相关测试或确认。d.测试/确认的计划/方案（QOQPQ）必须在计划/方案中定义该阶段的可接受标准。e.所有测试必须正常运行，所有测试或确认事件都必须予以记录，总体测试结果必须为通过。f.如果有事件在“上线”前未予解决，应有已制定并获批准的解决相应事件的行动计划。g.涉及到系统放行的所有限制条件都必须予以记录。h.验证总结报告必须经过起草、审核和批准。5 .文件管理验证文件的起草、审核、修订、版本控制、归档，以及脚本执行过程的书写规范要求，需遵循规定，并按规定对验证文件分配文件编号。6 .部署上线