计算机化系统验证的实际应用.docx

《计算机化系统验证的实际应用.docx》由会员分享，可在线阅读，更多相关《计算机化系统验证的实际应用.docx（13页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、计算机化系统验证的实际应用摘要：2010版药品生产质量管理规范(GMP)附录（计算机化系统）的公布，为我国制药行业计算机化系统的管理提出了要求。而其中计算机化系统验证的水平是国内药品生产企业的短板。基于（良好自动化生产实践指南(5版)）(GAMP5)这一国际通用的计算机化系统验证指南，本文以4类软件中最为复杂的SAP(即systemapplicationsandproducts)软件验证为例，详细讲明怎样施行计算机化系统验证。关键词：良好自动化生产实践指南(5版)(GAMP5)；计算机化系统；验证（良好自动化生产实践指南(5版)）(GoodAutomatedManufacturingPract

2、ice-Rev5，GAMP5)是由国际制药工程协会(ISPE)主编的计算机化系统验证的指导方针。GAMP5使用广泛，并得到了国际监管部门的公认，已有较多文献对其进行了具体描绘。例如计算机化系统的定义、软硬件的分类，以及基于不同类型软件的可增减的验证生命周期V模型等。因而本文不在概念及理论上给予过多篇幅的描绘，而是直接以业内运用最为普遍的企业资源计划(ERP)软件SAP(systemapplicationsandproducts)验证经过为例，讲述怎样以GAMP5为基础开展符合中国、美国以及欧盟药品生产质量管理规范(GMP)的计算机化系统验证。1供给商评估对于供给商的评估是2010版GMP附录（

3、计算机化系统）第四条“企业应对基于风险评估的结果提供与供给商质量体系和审计信息相关的文件的要求1。基于风险的供给商评估方法重点关注于重要供给商，下面是供给商评估的3种主要类型：基于现有信息的基础评估；使用调查问卷的邮件调查；由相关专家、审计员或审计小组进行的现场审计。需要注意的是SAP软件分为软件提供商和软件施行商，经风险分析以为SAP软件属于全球同行业使用最广泛的ERP软件，因而对于软件提供商的评估能够以调查问卷的邮件调查形式开展。而对于国内的软件施行商，水平参差不齐，因而基于风险的考虑应该由相关专家、审计员或审计小组进行的现场审计2。1.1邮件审计通常邮件审计的调查问卷包含下面内容：公司概

4、述，包括所采购产品的生产地址；组织机构，角色和职责，员工培训和经历；关键产品和(或)服务的历史与开发计划；质量管理体系在公司层面和相关产品生产经过中的执行情况；产品/项目管理；软件开发生命周期经过与交付物；软件开发生命周期支持流程；安全性。1.2现场审计现场审计人员中必须包括质量部门人员，还应指定审计组长，由其对审计的施行负全部责任。审计时能够邀请第三方审计人员共同介入，但应该事先通知供给商。审计主要通过质疑和检查来确定供给商的运营能否充分，重点关注的应该是供给商的质量管理体系能否能确保交付符合要求的产品，并且在产品生命周期内始终给予技术和服务上的支持。现场审计由3个部分组成：开场审计会议、审

5、查和检查、结束审计会议。2起草验证主计划验证主计划(VMP)是整个SAP软件验证经过的顶层文件，所有接下来的验证工作都以此文件为核心开展，验证主计划的内容通常包括下面内容。2.1简介简介部分应该包括：验证目的、验证根据、验证原因、验证类型、系统使用描绘、验证计划下发清单。2.2验证范围通常ERP软件的施行会涉及办公用品采购、库存管理、财务等非GMP模块，所以应明确本次验证的活动范围。2.3验证策略验证策略是验证主计划的核心内容，在验证策略的综述中应明确计算机化系统的编号、人员的培训方式、第三方服务介入的分工、所有本次验证文档的管理要求。随后根据系统生命周期(SDLC)原则将计算机化系统验证分为

6、5个阶段施行。项目启动和计划，包含项目计划的建立、计算机化系统的GxP(制药行业相关规范的统称，如GMP、GLP等)相关性断定。开发与获得，包含定义需求、供给商评估报告、系统分类、定义系统讲明、风险评估、设计确认。施行、验收与，包含安装、测试、权限测试、单元测试、集成测试、用户验收测试(UAT)、追溯矩阵、操作规程和手册、培训、系统验收和。系统运行和维护，包含问题管理、配置管理及变更管理、业务持续性计划、定期检查、记录保存及归档、偏差管理。系统退役和停运。2.4组织机构规定验证明施包含的所有角色及其职责。3计算机化系统的GxP相关性断定根据表1中所示问题进行判定，了解系统所能提供的功能。假如一

7、个或多个问题的回答是“是，则系统存在一个或多个功能要遵循GxP规范；假如所有问题的回答是“否，则系统没有任何功能需要遵循GxP规范3。4用户需求讲明(URS)URS旨在阐述用户的需求，描绘了用户对质量管理的业务经过及功能的需求。这份文件是构建起项目和系统的文件体系的基础，同时也是系统设计和验证的可接受标准的根据。用户需求应当基于对产品和流程的理解，包括对关键质量属性(criticalqualityattribution，CQA)法规的理解，按自上而下的方式撰写。URS不应该陷入技术细节，技术解决方案会在后续的功能讲明(FS)中描绘。当没有选定商用现成软件系统时，应避免需求陷入空想；中选定了商用

8、现成软件系统时，应避免陷入解决方案的陈述。4.1流程图SAP软件是一个全球各行业均能够使用的ERP系统。药品生产企业的部分业务流程要符合GMP规范，在此情况下SAP软件的一些标准功能需要进行改变。实际上，SAP软件也能根据企业的实际情况进行有限的配置和开发。所以，业务流程所有者应该和软件施行参谋商讨确定所有业务的流程，并以流程图的形式进行描绘。4.2需求内容根据业务流程图，将其中每一个流程节点所要到达的预期效果用文字描绘清楚就得到了需求内容，同时对每一条需求的优先级和其能否与GMP相关进行评估。用户需求GMP相关性断定是系统GMP相关性断定的延伸。这项评估有利于辨别更需要合规关注的活动和功能，

9、能够用来在后续的生命周期中，十分是测试经过中提高测试的效率。GMP评估还需要考虑到健康因素，即对于系统使用者可能的潜在影响。GMP评估应该包含对于电子记录和电子签名的使用。只要在电子记录和电子签名信息充足的时候，GMP评估才有意义。然而，在书写URS的时候，这些信息有可能是缺乏、不连贯、甚至是错误的。当发生这种情况时，能够把这次评估当成一次预评估，当信息充分之后，在后续的阶段进行再评估。URS的优先级能够使软件供给商、施行商愈加有目的性，愈加明晰地理解用户的需求。评估原则为：强迫的、必须的需求为高，例如业务强烈需求、直接影响到产品的质量或者法规的需求；与质量相关，但没有直接影响到最终产品的质量

10、，对于业务有重要提升作用的需求为中；仅对系统的功能有提升作用的需求为低。5定义系统讲明(SS)系统讲明包括功能讲明(FS)和设计讲明(DS)，以可验证的方式准确描绘了一个系统或组件的功能，以及提供断定这些功能能否能知足需求的流程。系统讲明和功能讲明是系统对用户需求讲明的描绘，是针对用户需求讲明制定的一个可行的解决方案。功能讲明和设计讲明在设计阶段创立，在单元测试和集成测试中被验证。URS、SS、FS和DS的关系见图14。系统讲明举例详见表4。功能讲明通过用例的形式具体讲明了每个用例的用户操作、系统响应和细节需求。每个用例通过用例表(表5)表达了系统应该怎样和最终用户或其他系统进行交互，来达成一

11、个指定的业务目的。6风险评估风险评估是基于对用户需求的具体评估，在适当的情况下设计确认(DQ)可能被包含在风险评估中。风险评估分为风险识别和风险控制两部分。风险识别主要有：风险确认，识别可能出现的故障以及产生的影响和产生的原因；风险分析，判定影响程度、发生概率、侦测概率；风险评估，对该故障进行风险分级，并确定风险优先级，通常采用“用例表的形式，见表5。风险控制主要有：风险降低，针对可能出现的故障提出降低风险的措施；风险沟通，确定能够验证该措施的文档；风险回首，重新进行风险分析，确保降低风险优先级为高的问题。用于风险评估的工具有很多，且已有文献对风险评估在验证中的应用进行具体描绘，本文不再重复。

12、7数据迁移数据可靠性是当下GMP热议的话题之一，新系统的上线必定会涉及旧数据的保存与转移。旧数据有纸质和电子两种形式，为了保证数据迁移时的完好性和可追溯性，应该针对系统功能进行划分，建立所有新系统所需数据的迁移方案。数据迁移方案应该遵循下面策略：数据源定义，在旧系统和文档中定义数据源，确认数据源的特性并重点关注GxP相关的数据，见表7；数据映射，定义并文档化每一个将在SAP系统中产生的字段与旧系统或者纸质文档中字段的映射关系；数据收集，根据源数据的情况确定能否需要使用工具导入(大批量GxP相关数据的导入应使用工具)，确认收集模板；根据数据收集模板收集数据并与源数据比对确认；数据输入，对手工输入

13、的数据进行复核，使用迁移工具则需提供迁移工具验证文档；数据确认，数据输入后复核，并导出签字确认。8SAP软件安装确认SAP系统的安装确认主要分为安装确认(IQ)、运行确认(OQ)和性能确认(PQ)。8.1IQ确认硬件的安装环境能否符合要求；确认硬件性能能否符合软件运行要求；确认操作系统能否知足软件运行要求；检查最新安装相关的SAP日志；基础安装参数定义；创立必要的文件系统；检查系统时区；安装介质准备；安装HANA(思爱普公司开发的一款数据库软件)数据库实例后安装日志检查；安装SAP应用实例后安装日志检查。8.2OQSTMS(SAP软件内部传输方式名称)传输系统功能；SAP软件受权；SAP系统一

14、致性检查；SAP生产HANA数据库切换检查；SAPGUI(用户图形操作界面)访问。8.3PQ操作系统资源检查；HANA数据库状态检查；STMS传输系统功能；SAP软件受权；SAP系统一致性检查；SAP生产系统HANA数据库备份检查；SAPGUI访问。测试是整个SAP系统验证最关键的环节之一，通过测试来确认系统的所有功能都能符合URS的条款。通常来讲，所有测试活动都要根据已文档化的系统需求来执行并记录。同时文档化的风险分析结果也决定了测试范围：任何使风险最小化的测试用例都应该包含于测试范围中。在适当的时候，反向测试(禁止行为的测试，测试相应的活动或访问以确保其没有执行或访问权限)也属于测试范围。

15、模块受权和系统受权是主要运用反向测试的场景。9.1起草测试用例测试用例是测试的方案脚本，编写测试用例时需要确保测试内容覆盖所有用户需求，必要时能够追溯到系统讲明(SS)和功能讲明(FS)。风险评估也是编写测试内容时需要重点参考的文档。测试用例要重点关注GMP相关功能的测试和权限控制的测试，这些GMP相关功能的测试和权限控制的测试是用户验收测试中需要强迫完成的部分。软件施行商要根据所需测试的系统功能，确保提供充足的测试数据供最终用户来进行测试用例的执行。每一个测试用例要包含测试目的、测试前提、测试经过、测试验收及关联文档。在测试经过中对步骤进行编号，同时记录模块、部门(或岗位)、步骤、操作讲明、

16、预期结果。9.2测试用例执行测试用例执行是基于测试用例，并附加上运行号、测试结果、测试的总体状况及验收。测试经过要按照测试用例中对应区域给出的执行步骤按顺序进行。每一步测试均需要生成一份（测试执行记录），记录测试的实际结果以及必要的截图。实际结果的记录不接受如“OK、“符合、“成功等简单的文字判定。需对实际出现的结果进行描绘，如展示文档的编号、重点期望的数据等。至少要填写“符合预期结果、“结果符合预期、“系统运行符合预期等内容。对于没有重点内容的测试步骤(如“下一个画面出现)，简单的描绘证实即可。9.3测试错误及问题处理在进行测试时，任何实际结果和用户需求之间的差异都需要记录在“实际结果中，并

17、断定为错误或问题。所有错误和问题都要填写相应的记录。错误或问题的影响等级由指定业务验收人和质量部门协商断定。影响等级的分类定义和处理方法参考如下。9.3.1微小，不需要变更错误或问题的影响较小，不会导致其他测试步骤失败，只需要进行微小的调整即可使该步骤符合预期结果。若在测试时能够调整，仅需在实际结果中记录调整前后的结果，并完成错误或问题记录即可。9.3.2中等，需变更错误或问题的影响较大，会导致其他的测试步骤失败，需要对系统的配置及设计文档进行变更。影响等级确以为中等后，需填写错误或问题记录，完成系统配置及相关文档的变更，最后将该测试用例以新的运行号执行测试。9.3.3严重，测试用例停止错误或

18、问题已经违犯了用户的需求，需要重新沟通需求内容并变更系统。确认后，填写错误或问题记录，在更新需求内容、系统配置及相关文档后，重新设置新的测试用例，并执行测试。在评估错误或问题的影响等级后，针对该错误或者问题分配解决人，由解决人提出解决方案并进行处理。解决方案的施行要经过用户验证，确认施行后的系统功能和相关文档符合需求。这个经过可能会需要重新执行测试用例，修订测试用例内容，甚至生成新的测试用例。10追溯矩阵追溯矩阵作为支持验证的关键因素和证实材料，用来建立先期产生的各种用户需求和相关文档之间的可追溯性。其关注的主要部分是：用户需求、系统讲明、GMP相关分析、风险分析、系统配置以及各种测试内容。1

19、1操作规程及手册、培训系统上线前应确保运行所必须的操作规程、手册已起草并被批准和用于培训，所需的操作规程至少应包括下面类型：（问题管理标准操作程序）、（变更标准操作程序）、（系统操作手册）、（数据备份标准操作程序）、（数据恢复标准操作程序）、（应急准备和响应标准操作程序）、（日常检查、维护标准操作程序）、（权限管理及设置标准操作程序）。12中期验证报告至此，SAP系统上线正式启用前的验证工作已完成，验证小组起草中期验证报告，涵盖了SAP项目施行中所有在计划阶段、开发阶段和施行阶段完成的验证内容。报告中应对每一验证内容产生的文档编号进行整理，再次确认每一验证内容能否都已经完成并符合要求。最终，中

20、期验证报告应给出能否同意系统上线启用的结论。13最终验证报告最终验证报告通常在系统上线的13个月后起草，此时系统已趋于稳定，变更及问题的数量也已经回落到正常水平。最终验证报告对系统上线后的运行情况、变更情况以及问题进行统计和分析，得出系统能否验证通过的最终结论。14系统运行和维护刚上线的系统必然还会碰到各种问题，此时就应该严格按相关流程记录所有的问题以及由此导致的变更，并且通常在系统运行1个月以后，针对运行情况给出最终的验证报告。在系统的运行和维护阶段应做到定期对系统进行回首，根据问题或变更的风险程度作出能否需要补充再验证的决定。15系统退役计算机化系统的退役或停运是正式终止一个系统的活动，标志着系统生命周期的结束。对于现存系统、数据和流程的潜在影响需要在退役或停运前进行检查。硬件和软件的退役需要制定一份项目计划，其中的活动可包括信息和文档的迁移、归档或删除。在停运计算机化系统之后，GMP相关文档和计算机化系统中的数据将根据相关GMP条例来保存。