计算机化系统验证享-GMP实施分享管鑫质量部,验证经理中美天津史克制药有限公司2015.05前言计算机技术逐渐应用于工业领域计算机主要用于控制设备,自身也是设备的一种计算机领域有着自专属的业领域业计算机领域有着自己专属的工业领域,IT工业计算机是种控制机器的机器计算机是一种控制机器的机器内容提要•什么是计算机化系统?•如何进行系统验证?如何进行系统验证验证实例备料自动打签系统•-什么是计算机化系统什是计算机化系《药品生产质量管理规范》2010 版十四章附则:用于报告或自动控制的集成系统包括数据输入电子处理和信息输出统,包括数据输入、电子处理和信息输出。
附录2《计算机化系统》第一条:本附录适用于在药品生产质量管理过程中应用的计算机化系统它由系列硬件和软件组成以满足特定的功能算机化系统,它由一系列硬件和软件组成,以满足特定的功能。
1.系统软件(System software)1(System software)操作操作系统和通用功能的一套程序。
在硬件及应用软件之间起接口的作用,且管理计算机的使用厂家提供诊断之间起接口的作用,且管理计算机的使用。
厂家提供诊断性测试,即确认该软件。
2.应用软件(Application software)2(A li ti ft)针对用户的特殊需求而开发、购买或修订的程序(主程序或子程序),它可执行数据的收集、处理、报告、存档及它可执行数据的收集处理报告存档及过程控制。
3.可配置软件(Configurable software)由供应商开发的程序(主程序或子程序),该软件可提供通用功能,使用户可按某种途径为自己设计程序。
功能使户按某种途径为自设程序4. 计算机系统(Computer system)4(Computer system)由硬件、系统软件、应用软件以及相关外围设备组成的,可执行某一功能或一组功能的系统。
可执行某一功能或一组功能的系统5. 计算机化系统(Computerized system)指受控系统、计算机控制系统以及人机接口的组合体系。
可以说计算机系统是计算机化系统的一部分。
如果计算机系统只是用于数据处理,则计算机系统本身就代表着待验系统只是用于数据处则计算机系统本身就代表着待验证的全系统。
6. 模块(Module)即实现某种特定功能的单元或程序段。
在软件开发中常常将程序各个部分继续划分,直至最小的基层单位,称为模块。
7. 源代码(Source code)7(Source code)以人类可阅读的形式(编程语言)表示的初始的计算机程序,在计算机执行之前,须译成机器可阅读的形式(机器语言)。
在计算机执行之前须译成机器可阅读的形式什么是计算机化系统-软、硬件分类分类软件例如硬件例如1基础软件‐已建立的商业软件Windows标准硬件个人计算机2‐基础软件工具Symentec客户定制组件……基础软件3不可配置的软件HPLC4需要配置的软件、BPCSLIMS5用户定制的软件GSK报销系统依据GAMP 5,此分类通常用来指导验证活动的流程,分类越高验证活动越复杂。
212软件是计算机化系统的重要组成部分企业应当根据风险评估的结果对于所2-12 软件是计算机化系统的重要组成部分。
企业应当根据风险评估的结果,对于所采用软件进行分级管理(如针对软件供应商的审计),评估供应商质量保证系统,保证软件符合企业需求。
如何进行系统验证-生命周期的概念如何进行系统验证-风险评估与验证内容26计算机化系统验证包括应用程序的验证和基础架构的确认其2-6 计算机化系统验证包括应用程序的验证和基础架构的确认,其范围与程度应当基于科学的风险评估。
风险评估应当充分考虑计算机化系统的使用范围和用途。
应当在计算机化系统生命周期中保持其验证状态其验证状态。
-如何进行系统验证资源和难点用户企业验证团队需要由如下人员组成:2-5 项目负责人(Project Manager ) 业务流程负责人(Process Owner ):负责业务流程的管理,确保计算机系统所控制的程序符合要求,拥有对系统中流程相关数据的所有权负责系统的释放也称为责任用户(Responsible User )中流程相关数据的所有权,负责系统的释放。
也称为责任用户(Responsible User )。
QA :负责整个验证过程的监督和控制。
计算机系统负责人(System Owner System Owner ):负责系统的正常运行、提供技术支持、维护系统的验证状态、系统数据安全等。
一般是企业的IT 部门人员或IT 专家)。
关键用户(Key User ):负责使用系统操作流程的关键功能。
IT 专家(Subject Matter Expert ,SME ):专指对计算机系统有专长的IT 专家,从计算机化系统项目的计划阶段就应该参与其中,尤其在系统测试方面起主导作用,这些工作包括:验证策略的制定、测试方法、接收标准的制定,以及测试结果的审核等。
有时也可外请。
(附录2第五条中有相关规定)供应商(Supplier )/开发者(Developer )方面: 可聘为SME (附录2第五条有相关规定) 负责确定软件开发方法负责提供软件产品和服务,供应商可以是第三方,也可以是企业内部开发组供商法模供应商应该使用最合适的开发方法和模型FMEA风险评估工具-失败模式分析Failure Mode and Effects AnalysisFMEA 作为系统工具主要用来:FMEA•识别潜在的失败模式及其原因和影响•依据严重性、可能性和可控性来对失败模式进行优先度排列严重性可能性和可控性•为针对失败模式而采取的纠正行动明确相关责任人•记录回顾流程以供未来参考风险评估手段严重性可能性可控性操作步骤打分描述判定标准10 特别严重微小改变就会影响关键质量属性7 中度严重很大的改变,或者微小改变的叠加影响关键质量属性4 轻微严重很大改变的叠加影响关键质量属性11 不严重对关键质量属性无影响打分可能性判定标准1 不可能一般用于使用的参数范围离可接受范围上下限度非常远,或者手工操作无错误发生的项目。
4微小可能一般用于使用的参数范围离可接受范围上下限度较远,或者手工操作错误率低的项目操作错误率低的项目。
7有可能一般用于使用的参数范围离可接受范围上下限度很接近,或者手工操作错误率比较高的项目。
10一般用于使用的参数范围离可接受范围上下限度几乎相同,或者10 非常可能般用于使用的参数范围离可接受范围上下限度几乎相同,或者手工操作错误率非常高的项目。
打分判定标准1发生的错误当时就能发现4发生的错误在下一工序被发现7发生的错误在最终检测被发现10发生的错误不能被发现,或者只能被消费者发现FMEAFMEA-实例工序潜在失败模式严重性可能性可控性RPN电话断了74128接电话客户突然挂断电话7117记录订单记录过程误会了客户的意思71428没有理解客户确切的意思474112获取地址写错地址10110100客户提供了错误地址10110100获取信用卡信息写错这些信息10110100客户提供错误的卡号10110100客户提供错的卡号1700 Month 0000Presentation title in footer用户需求是用非专业语言写成的需求URS功能需求是用专业语言写成的需求,是对用户需求的专业语言翻译,是功能测试的基础Design Specification/Review=Design Qualification如何进行系统验证验证般流程-验证一般流程配置标准中应包含系统中所有软件产品的配置情况,其中包括具体的设置和参数。
这一标准是在专业领域为功能服务的g g pPackage Configuration Specification如何行系统验验般程如何进行系统验证-验证一般流程功能测试前,需要确认配置正确,软件安装成功,测试内容完备。
PSOP1433中为何将安装确认放置在测试完成后,而测试前没有提及任何软件安装内容?Package Configuration Specification+TIP/TIR+TP/TC如何进行系统验证验证般流程-验证一般流程需求测试是用户的测试,此时必须有相应的支持系统完成。
包括偏差管理、变更管理、维修管理。
需要有操作规程,恢复规程,备份等。
如有必要,系统应该释放到PQ。
System Release Notification + PQP/PQRy Q Q如何进行系统验证-资源和难点用户完成用户与专业人员共同完成计划和需求阶段验证通常起始于一个确认商业需求的需求文件,项目团队在获得商业需求后将这些需求充分细化,用以产生用户需求标准。
在起草用户需求标准时需要充分考虑该系统的法规符合性和电子记录电子签名的要求。
子记录电子签名的要求在该验证阶段通常需要以下文件:用户需求标准(URS)、验证计划(VP)和供应商审计/评估(SA)。
URS应该关注于系统应该做什么,而不是详述怎样完成。
URS应该使用对于终端用户和潜在供应商可理解水平的语言,用以清晰定义系统需要做什么。
需要对任何必要的技术语言或潜在的不明确语言进行定义。
计算机系统的URS需考虑如下每部分内容:需考虑如下每部分内容供应商评估-附录2 -4/12•对于GMP计算机系统,必须要进行供应商评估,例如:网上搜索、类似系统使用的历史情况等。
•验证计划(基于风险评估的结果)应该说明评估的结果并且说明是否需要供应商审计;•供应商审计的目的就是…–将供应商验证活动/文件和我们的相比较–对于供应商不足的地方,确定自己应该采取的行动和措施供应商评估/审计中的主要关注点:技术能力评估;程序编制人员的资格审定;质量管理系统的有效性和应用(包括变更控制);软件开发标准及软件测试能力;软件开发标准及软件测试能力硬件开发及制造能力;对维护/进一步开发(如果需要)的支持性服务的有效性供应商的商业拓展能力(如:财务稳定性);有效性供应商的商业拓展能力(如财务稳定性)系统的安性;系统的安全性;售后服务。
设计阶段●设计标准;●设计回顾/设计确认;●源代码回顾(如果是定制的系统)。
设计标准上述和用户/系统需求有关联的设计文件包含了:●所有系统输入、输出和界面;●所有的功能和性能要求;●系统结构、组成& 它们的关系;●错误定义和处理。
错误定义和处理设计回顾/设计确认这是一个法规要求的验证活动来确认所有的法规和业务(用户需求标准)的需求:●均已涵盖在整个设计标准中;●完整的、可测的在设计回顾报告中记录回顾的结果。
在设计回顾报告中记录回顾的结果基于风险评估来确定是否需要对订制系统进行源代码审核,该回顾用于确认:●代码符合程序的标准;●和之前已定义的设计和标准相一致;●代码错误(例如:死代码的识别和& 移除)。