计算机化系统验证的实际应用范文
本站小编为你精心准备了计算机化系统验证的实际应用参考范文，愿这些范文能点燃您思维的火花，激发您的写作灵感。欢迎深入阅读并收藏。
摘要：2010版药品生产质量管理规范(GMP)附录《计算机化系统》的颁布，为我国制药行业计算机化系统的管理提出了要求。而其中计算机化系统验证的水平是国内药品生产企业的短板。基于《良好自动化生产实践指南(5版)》(GAMP5)这一国际通用的计算机化系统验证指南，本文以4类软件中最为复杂的SAP(即systemapplicationsandproducts)软件验证为例，具体说明如何实施计算机化系统验证。
关键词：良好自动化生产实践指南(5版)(GAMP5)；计算机化系统；验证
《良好自动化生产实践指南(5版)》(GoodAutomatedManufacturingPractice-Rev5，GAMP5)是由国际制药工程协会(ISPE)主编的计算机化系统验证的指导方针。GAMP5使用广泛，并得到了国际监管部门的公认，已有较多文献对其进行了详细描述。例如计算机化系统的定义、软硬件的分类，以及基于不同类型软件的可增减的验证生命周期V模型等。因此本文不在概念及理论上给予太多篇幅的描述，而是直接以业内运用最为普遍的企业资源计划(ERP)软件SAP(systemapplicationsandproducts)验证过程为例，讲述如何以GAMP5为基础开展符合中国、美国以及欧盟药品生产质量管理规范(GMP)的计算机化系统验证。
1供应商评估
对于供应商的评估是2010版GMP附录《计算机化系统》第四条“……企业应对基于风险评估的结果提供与供应商质量体系和审计信息相关的文件”的要求[1]。基于风险的供应商评估方法重点关注于重要供应商，以下是供应商评估的3种主要类型：基于现有信息的基础评估；使用调查问卷的邮件调查；由相关专家、审计员或审计小组进行的现场审计。需要注意的是SAP软件分为软件提供商和软件实施商，经风险分析认为SAP软件属于全球同行业使用最广泛的ERP软件，因此对于软件提供商的评估可以以调查问卷的邮件调查形式开展。而对于国内的软件实施商，水平参差不齐，因此基于风险的考虑应该由相关专家、审计员或审计小组进行的现场审计[2]。
1.1邮件审计通常邮件审计的调查问卷包含以下内容：公司概述，包括所采购产品的生产地址；组织机构，角色和职责，员工培训和经验；关键产品和(或)服务的历史与开发计划；质量管理体系在公司层面和相关产品生产过程中的执行情况；产品/项目管理；软件开发生命周期过程与交付物；软件开发生命周期支持流程；安全性。
1.2现场审计现场审计人员中必须包括质量部门人员，还应指定审计组长，由其对审计的实施负全部责任。审计时可以邀请第三方审计人员共同参与，但应该事先通知供应商。审计主要通过质疑和检查来确定供应商的运营是否充分，重点关注的应该是供应商的质量管理体系是否能确保交付符合要求的产品，并且在产品生命周期内始终给予技术和服务上的支持。现场审计由3个部分组成：开始审计会议、审查和检查、结束审计会议。
2起草验证主计划验证
主计划(VMP)是整个SAP软件验证过程的顶层文件，所有接下来的验证工作都以此文件为核心开展，验证主计划的内容通常包括以下内容。
2.1简介简介部分应该包括：验证目标、验证依据、验证原因、验证类型、系统使用描述、验证计划下发清单。
2.2验证范围通常ERP软件的实施会涉及办公用品采购、库存管理、财务等非GMP模块，所以应明确本次验证的活动范围。
2.3验证策略验证策略是验证主计划的核心内容，在验证策略的综述中应明确计算机化系统的编号、人员的培训方式、第三方服务参与的分工、所有本次验证文档的管理要求。随后根据系统生命周期(SDLC)原则将计算机化系统验证分为5个阶段实施。①项目启动和计划，包含项目计划的建立、计算机化系统的GxP(制药行业相关规范的统称，如GMP、GLP等)相关性判定。②开发与获得，包含定义需求、供应商评估报告、系统分类、定义系统说明、风险评估、设计确认。③实施、验收与，包含安装、测试、权限测试、单元测试、集成测试、用户验收测试(UAT)、追溯矩阵、操作规程和手册、培训、系统验收和。④系统运行和维护，包含问题管理、配置管理及变更管理、业务持续性计划、定期检查、记录保存及归档、偏差管理。⑤系统退役和停运。
2.4组织机构规定验证实施包含的所有角色及其职责。
3计算机化系统的GxP相关性判定
根据表1中所示问题进行判断，了解系统所能提供的功能。如果一个或多个问题的回答是“是”，则系统存在一个或多个功能要遵循GxP规范；如果所有问题的回答是“否”，则系统没有任何功能需要遵循GxP规范[3]。
4用户需求说明(URS)
URS旨在阐述用户的需求，描述了用户对质量管理的业务过程及功能的需求。这份文件是构建起项目和系统的文件体系的基础，同时也是系统设计和验证的可接受标准的依据。用户需求应当基于对产品和流程的理解，包括对关键质量属性(criticalqualityattribution，CQA)法规的理解，按自上而下的方式撰写。URS不应该陷入技术细节，技术解决方案会在后续的功能说明(FS)中描述。当没有选定商用现成软件系统时，应避免需求陷入空想；当选定了商用现成软件系统时，应避免陷入解决方案的陈述。
4.1流程图SAP软件是一个全球各行业均可以使用的ERP系统。药品生产企业的部分业务流程要符合GMP规范，在此情况下SAP软件的一些标准功能需要进行改变。实际上，SAP软件也能根据企业的实际情况进行有限的配置和开发。所以，业务流程所有者应该和软件实施顾问商讨确定所有业务的流程，并以流程图的形式进行描述。
4.2需求内容根据业务流程图，将其中每一个流程节点所要达到的预期效果用文字描述清楚就得到了需求内容，同时对每一条需求的优先级和其是否与GMP相关进行评估。用户需求GMP相关性判定是系统GMP相关性判定的延伸。这项评估有利于辨别更需要合规关注的活动和功能，可以用来在后续的生命周期中，特别是测试过程中提高测试的效率。GMP评估还需要考虑到健康因素，即对于系统使用者可能的潜在影响。GMP评估应该包含对于电子记录和电子签名的使用。只有在电子记录和电子签名信息充足的时候，GMP评估才有意义。然而，在书写URS的时候，这些信息有可能是不足、不连贯、甚至是错误的。当发生这种情况时，可以把这次评估当成一次预评估，当信息充分之后，在后续的阶段进行再评估。URS的优先级可以使软件供应商、实施商更加有目的性，更加清晰地理解用户的需求。评估原则为：强制的、必须的需求为高，例如业务强烈需求、直接影响到产品的质量或者法规的需求；与质量相关，但没有直接影响到最终产品的质量，对于业务有重要提升作用的需求为中；仅对系统的功能有提升作用的需求为低。
5定义系统说明(SS)
系统说明包括功能说明(FS)和设计说明(DS)，以可验证的方式精确描述了一个系统或组件的功能，以及提供判定这些功能是否能满足需求的流程。系统说明和功能说明是系统对用户需求说明的描述，是针对用户需求说明制定的一个可行的解决方案。功能说明和设计说明在设计阶段创建，在单元测试和集成测试中被验证。URS、SS、FS和DS的关系见图1[4]。系统说明举例详见表4。功能说明通过用例的形式详细说明了每个用例的用户操作、系统响应和细节需求。每个用例通过用例表(表5)表达了系统应该如何和最终用户或其他系统进行交互，来达成一个指定的业务目标。
6风险评估
风险评估是基于对用户需求的详细评估，在适当的情况下设计确认(DQ)可能被包含在风险评估中。风险评估分为风险识别和风险控制两部分。风险识别主要有：风险确认，识别可能出现的故障以及产生的影响和产生的原因；风险分析，判断影响程度、发生概率、侦测概率；风险评估，对该故障进行风险分级，并确定风险优先级，通常采用“用例表”的形式，见表5。风险控制主要有：风险降低，针对可能出现的故障提出降低风险的措施；风险交流，确定可以验证该措施的文档；风险回顾，重新进行风险分析，确保降低风险优先级为高的问题。用于风险评估的工具有很多，且已有文献对风险评估在验证中的应用进行详细描述，本文不再重复。
7数据迁移
数据可靠性是当下GMP热议的话题之一，新系统的上线必定会涉及旧数据的保存与转移。旧数据有纸质和电子两种形式，为了保证数据迁移时的完整性和可追溯性，应该针对系统功能进行划分，建立所有新系统所需数据的迁移方案。数据迁移方案应该遵循以下策略：数据源定义，在旧系统和文档中定义数据源，确认数据源的特性并重点关注GxP相关的数据，见表7；数据映射，定义并文档化每一个将在SAP系统中产生的字段与旧系统或者纸质文档中字段的映射关系；数据收集，根据源数据的情况确定是否需要使用工具导入(大批量GxP相关数据的导入应使用工具)，确认收集模板；根据数据收集模板收集数据并与源数据比对确认；数据输入，对手工输入的数据进行复核，使用迁移工具则需提供迁移工具验证文档；数据确认，数据输入后复核，并导出签字确认。
8SAP软件安装确认
SAP系统的安装确认主要分为安装确认(IQ)、运行确认(OQ)和性能确认(PQ)。
8.1IQ确认硬件的安装环境是否符合要求；确认硬件性能是否符合软件运行要求；确认操作系统是否满足软件运行要求；检查最新安装相关的SAP日志；基础安装参数定义；创建必要的文件系统；检查系统时区；安装介质准备；安装HANA(思爱普公司开发的一款数据库软件)数据库实例后安装日志检查；安装SAP应用实例后安装日志检查。
8.2OQSTMS(SAP软件内部传输方式名称)传输系统功能；SAP软件授权；SAP系统一致性检查；SAP生产HANA数据库切换检查；SAPGUI(用户图形操作界面)访问。
8.3PQ操作系统资源检查；HANA数据库状态检查；STMS传输系统功能；SAP软件授权；SAP系统一致性检查；SAP生产系统HANA数据库备份检查；SAPGUI访问。
9测试
测试是整个SAP系统验证最关键的环节之一，通过测试来确认系统的所有功能都能符合URS的条款。通常来说，所有测试活动都要根据已文档化的系统需求来执行并记录。同时文档化的风险分析结果也决定了测试范围：任何使风险最小化的测试用例都应该包含于测试范围中。在适当的时候，反向测试(禁止行为的测试，测试相应的活动或访问以确保其没有执行或访问权限)也属于测试范围。模块授权和系统授权是主要运用反向测试的场景。
9.1起草测试用例测试用例是测试的方案脚本，编写测试用例时需要确保测试内容覆盖所有用户需求，必要时可以追溯到系统说明(SS)和功能说明(FS)。风险评估也是编写测试内容时需要重点参考的文档。测试用例要重点关注GMP相关功能的测试和权限控制的测试，这些GMP相关功能的测试和权限控制的测试是用户验收测试中需要强制完成的部分。软件实施商要根据所需测试的系统功能，确保提供充足的测试数据供最终用户来进行测试用例的执行。每一个测试用例要包含测试目的、测试前提、测试过程、测试验收及关联文档。在测试过程中对步骤进行编号，同时记录模块、部门(或岗位)、步骤、操作说明、预期结果。
9.2测试用例执行测试用例执行是基于测试用例，并附加上运行号、测试结果、测试的总体状况及验收。测试过程要依照测试用例中对应区域给出的执行步骤按顺序进行。每一步测试均需要生成一份《测试执行记录》，记录测试的实际结果以及必要的截图。实际结果的记录不接受如“OK”、“符合”、“成功”等简单的文字判断。需对实际出现的结果进行描述，如展示文档的编号、重点期望的数据等。至少要填写“符合预期结果”、“结果符合预期”、“系统运行符合预期”等内容。对于没有重点内容的测试步骤(如“下一个画面出现”)，简单的描述证明即可。
9.3测试错误及问题处理在进行测试时，任何实际结果和用户需求之间的差异都需要记录在“实际结果”中，并判定为错误或问题。所有错误和问题都要填写相应的记录。错误或问题的影响等级由指定业务验收人和质量部门协商判定。影响等级的分类定义和处理方法参考如下。
9.3.1微小，不需要变更错误或问题的影响较小，不会导致其他测试步骤失败，只需要进行微小的调整即可使该步骤符合预期结果。若在测试时可以调整，仅需在实际结果中记录调整前后的结果，并完成错误或问题记录即可。
9.3.2中等，需变更错误或问题的影响较大，会导致其他的测试步骤失败，需要对系统的配置及设计文档进行变更。影响等级确认为中等后，需填写错误或问题记录，完成系统配置及相关文档的变更，最后将该测试用例以新的运行号执行测试。
9.3.3严重，测试用例停止错误或问题已经违背了用户的需求，需要重新沟通需求内容并变更系统。确认后，填写错误或问题记录，在更新需求内容、系统配置及相关文档后，重新设置新的测试用例，并执行测试。在评估错误或问题的影响等级后，针对该错误或者问题分配解决人，由解决人提出解决方案并进行处理。解决方案的实施要经过用户验证，确认实施后的系统功能和相关文档符合需求。这个过程可能会需要重新执行测试用例，修订测试用例内容，甚至生成新的测试用例。
10追溯矩阵
追溯矩阵作为支持验证的关键因素和证明材料，用来建立先期产生的各种用户需求和相关文档之间的可追溯性。其关注的主要部分是：用户需求、系统说明、GMP相关分析、风险分析、系统配置以及各种测试内容。
11操作规程及手册、培训
系统上线前应确保运行所必须的操作规程、手册已起草并被批准和用于培训，所需的操作规程至少应包括以下类型：《问题管理标准操作程序》、《变更标准操作程序》、《系统操作手册》、《数据备份标准操作程序》、《数据恢复标准操作程序》、《应急准备和响应标准操作程序》、《日常检查、维护标准操作程序》、《权限管理及设置标准操作程序》。
12中期验证
报告至此，SAP系统上线正式启用前的验证工作已完成，验证小组起草中期验证报告，涵盖了SAP项目实施中所有在计划阶段、开发阶段和实施阶段完成的验证内容。报告中应对每一验证内容产生的文档编号进行整理，再次确认每一验证内容是否都已经完成并符合要求。最终，中期验证报告应给出是否同意系统上线启用的结论。
13最终验证
报告最终验证报告通常在系统上线的1～3个月后起草，此时系统已趋于稳定，变更及问题的数量也已经回落到正常水平。最终验证报告对系统上线后的运行情况、变更情况以及问题进行统计和分析，得出系统是否验证通过的最终结论。
14系统运行和维护
刚上线的系统必然还会遇到各种问题，此时就应该严格按相关流程记录所有的问题以及由此导致的变更，并且通常在系统运行1个月以后，针对运行情况给出最终的验证报告。在系统的运行和维护阶段应做到定期对系统进行回顾，根据问题或变更的风险程度作出是否需要补充再验证的决定。
15系统退役
计算机化系统的退役或停运是正式终止一个系统的活动，标志着系统生命周期的结束。对于现存系统、数据和流程的潜在影响需要在退役或停运前进行检查。硬件和软件的退役需要制定一份项目计划，其中的活动可包括信息和文档的迁移、归档或删除。在停运计算机化系统之后，GMP相关文档和计算机化系统中的数据将根据相关GMP条例来保存。
作者：沈忱，陆振宇，徐秀卉，徐蓉，来聪聪 单位：杭州康恩贝制药有限公司