计算机化的系统的验证

1.GMP对计算机化的系统的要求；2.计算机化的系统的分类和定义；3.计算机化的系统的验证流程；4.电子记录和电子签名。内容介绍：内容介绍：内容介绍：内容介绍：一、GMP对计算机化的系统的要求第八章　文件管理第一节　原　则第一百六十三条　如使用电子数据处理系统、照相技术或其他可靠方式记录数据资料，应当有所用系统的操作规程；记录的准确性应当经过核对。使用电子数据处理系统的，只有经授权的人员方可输入或更改数据，更改和删除情况应当有记录；应当使用密码或其他方式来控制系统的登录；关键数据输入后，应当由他人独立进行复核。用电子方法保存的批记录，应当采用磁带、缩微胶卷、纸质副本或其他方法进行备份，以确保记录的安全，且数据资料在保存期内便于查阅。人员1.关键人员和计算机系统人员之间紧密合作是非常重要的，管理及使用人员在其分管的职责中管理和使用计算机系统时，应接受管理和使用计算机系统的培训。这包括确保有适当的专业人员，对计算机系统的设计、验证、安装和运行等方面进行培训和指导。验证2.应根据多种因素来确定计算机系统的验证范围，包括：用途、预验证还是回顾性验证、是否采用了创新元件等。应当将验证看作计算机系统“验证生命周期”的组成环节。这个验证生命周期包括计划、设定标准、编程、测试、试运行、文档管理、运行、监控和修改升版等阶段。系统3.应注意设备安装在适当的位置，以防止外来因素干扰系统的正常运行。4.应有一详细描述系统的文件，并须及时更新。此文件应详细描述系统的工作原理、目的、安全措施和适用范围、计算机运行方式的主要特征，以及如何与其它系统和程序相接。5.软件是计算机系统的重要组成部分。软件的使用者应当采取适当措施，保证所编制的软件符合质量保证系统的要求。6.必要时，系统应当有数据正确输入和处理的内置复核功能。7.在计算机化的系统使用之前，应当对系统全面进行测试，并确认系统可以获得预期的结果。当计算机系统替代某一人工系统时，作为测试和验证的内容，两个系统应平行运行一段时间。8.仅有有权限的人员可以输入或修改数据。杜绝未经授权的人员进入系统的方法包括：钥匙、通行证、个人密码和权限对计算机终端的访问。应当就输入和修改数据制定一个授权、取消、授权更改，以及改变个人密码的规程。同时，应当考虑系统记录未经授权的人员试图访问系统的行为。9.当人工输入重要数据时（例如在称重过程中输入物料的重量和批号），应当复核输入记录的准确性。这个复核可以由另外一个操作人员完成，或采用经验证的电子方式。10.计算机系统应当记录输入或确认重要数据人员的身份。只有少数授权人员才可以修改已输入的数据，并应记录修改数据的理由。应当考虑在计算机系统中建立一个完整的输入和修改记录的可追溯性系统。11.应当根据预先制定的规程更换系统或计算机程序，规程应当包括验证、检查、批准和核实变更的条款。系统或计算机程序的变更，应经过计算机系统相关部门负责人员的认可，变更情况应有记录。每一个重大变更均应经过验证。12.在进行各种检查时，应能将储存的电子数据打印成清晰的文稿。13.同10版GMP要求。14.应定期对数据进行备份，以保护储存的数据。备份数据应储存在另一个单独的、安全的地点。15.系统应有一个应急方案，以便万一系统故障时启用，应急方案启用的时间应与需要使用该方案的紧急程度相关。例如，影响召回产品的信息应能在很短的时间内查得。16.应建立系统出现故障或损坏应遵循的程序，并对程序进行验证。所发生的故障和补救措施均应记录。17.应建立记录和分析错误及采取纠正措施的程序。18.当使用外包代理商提供的计算机服务时，与外包商之间应有正式的协议书，外包商的职责应在协议中明确规定。19.当采用计算机系统放行产品时，只有药品放行责任人员方能放行产品。此外，计算机系统应能辨认和记录放行产品人员的身份。二、计算机化的系统的分类和定义�种类1–基础软件：�已确立的或者已在商业领域应用的软件；�基础软件工具。�种类2–不再使用；�种类3–非配置的软件(现在包括固件)；�种类4–可以配置的软件；�种类5–客户定制的软件。GAMP5GAMP5GAMP5GAMP5中的软件种类已经改变：中的软件种类已经改变：中的软件种类已经改变：中的软件种类已经改变：1.可配置软件(Configurablesoftware)由供应商开发的程序(主程序或子程序)，该软件可提供通用功能，使用户可按某种途径为自己设计程序。2.系统软件(Systemsoftware)操作操作系统和通用功能的一套程序。在硬件及应用软件之间起接口的作用，且管理计算机的使用。厂家提供诊断性测试，即确认该软件。3.应用软件(Applicationsoftware)针对用户的特殊需求而开发、购买或修订的程序(主程序或子程序)，它可执行数据的收集、处理、报告、存档及过程控制。4.计算机系统(Computersystem)由硬件、系统软件、应用软件以及相关外围设备组成的，可执行某一功能或一组功能的系统。5.计算机化系统(Computerizedsystem)指受控系统、计算机控制系统以及人机接口的组合体系。可以说计算机系统是计算机化系统的一部分。如果计算机系统只是用于数据处理，则计算机系统本身就代表着待验证的整个系统。6.模块(Module)即实现某种特定功能的单元或程序段。在软件开发中常常将程序各个部分继续划分，直至最小的基层单位，称为模块。7.源代码(Sourcecode)以人类可阅读的形式(编程语言)表示的初始的计算机程序，在计算机执行之前，须译成机器可阅读的形式(机器语言)。8.黑盒测试(Blackboxtesting)将系统(软件和硬件)看作不能打开的黑盒，在不考虑系统内部结构和特性的情况下，测试者只依靠系统需求，从可能的输入条件和输出条件中确定测试数据，也就是根据系统的功能或外部特性，设计测试用例(例如功能测试)。9.白盒测试(Whiteboxtesting)即结构测试或逻辑驱动测试。这种测试允许测试者考虑系统的内部结构，并根据系统内部结构设计测试用例，而不考虑系统的功能。10.封闭系统(Closedsystem)封闭系统是指系统通道处于一种能够被一定的人员所控制的环境，该人员有权限在系统上进行电子记录的操作，11.开放系统(Opensystem)开放系统是指系统通道处于一种不能够被有权限在系统上进行电子记录操作的人员所控制的环境，如电子信件(E-mail)、在因特网上发送信息等。12.电子记录是指任何文本、图表、数据、声音、图示的或其他的以电子形式表现的信息的混合，它的建立、修改、维护、归档、检索或分发是由计算机系统来完成的。13.电子签名是指一种由一个人执行、采用或批准成为与其个人的手写签名具有相同的法律效力的计算机数据的任意符号或一系列符号的编译。三、计算机化的系统的验证流程计算机系统的验证：是个持续的过程，通过纸质的文档确保系统始终可以可靠的运行。而这个可靠的运行是根据之前确定好的接受标准和质量参数来定义的。�持续的过程...–从最初的概念开始，直到系统退出使用；�文档...–提供纸质的证据；�提前确定的...–在我们开始正式验证之前一定要以文件方式记载我们需要什么。相似的计算机系统可能验证的复杂程度不同，在进行计算机系统验证时需要考虑待验证的系统：�对于患者、产品质量、法规记录真实性的风险等级；�系统类型(例如：标准化的系统或订制的系统)；�系统的用途(例如:为无菌设备而建立的管理系统或为无菌区域而建立的管理系统)。�判定系统是否为GMP系统；�实施风险评估；�批准用户需求标准；�批准验证计划；�实施供应商评估。�确定风险的级别，例如：哪些是高风险、中风险、低风险；�判定任何潜在风险对验证方法或者系统设计的影响；�风险评估是根据已批准的文件来实施的（例如：高级别的商业需求）。用户需求标准清楚地定义了系统被要求来做什么(而不是怎么去做)。用户需要提供需求，要求是：�唯一可识别的(好处是你可以进行追踪)；�应该以一种可以被测试的方法来进行描述；�完全的而不仅仅是口译过来的描述；该文件用于描述满足使用目的的需求，用户需求标准通常在技术和质量部门的支持下由设备所属部门或使用部门起草，质量管理人员批准。用户需求标准中描述的需求应该具有“SMART”特性：①S,Specification每个需求应该具有具体的标准。②M,Measurable每个需求都能够进行测试或确认来证实该设备是否满足用户需求。③A,Achievable每个需求都应该是能够实现的、清楚和明确的。④R,Repeat每个需求的测试结果可以重复测得。⑤T,Traceability每个需求能够通过设计和测试进行追踪。电子记录和电子签名的要求：需要将对计算机系统中电子记录和电子签名的需求（例如：审计追踪）加入用户需求标准中。举例：一个法规的要求如何加入到用户需求标准中1.0安全1.1密码管理1.1.1系统必须强制用户输入最短7位字母来登陆用户需求标准通常验证计划包括以下内容：�验证方法(基于风险)�验证文件(文件&活动)�需要遵循的步骤�需要的培训�测试的策略�职责�时间表�对于GMP计算机系统,必须要进行供应商评估，例如：网上搜索、类似系统使用的历史情况等。�验证计划（基于风险评估的结果）应该说明评估的结果并且说明是否需要供应商审计；�供应商审计的目的就是…◦将供应商验证活动/文件和我们的相比较◦对于供应商不足的地方，确定自己应该采取的行动和措施供应商评估/审计中的主要关注点：�技术能力评估；�程序编制人员的资格审定；�质量管理系统的有效性和应用（包括变更控制）；�软件开发标准及软件测试能力；�硬件开发及制造能力；�对维护/进一步开发（如果需要）的支持性服务的有效性供应商的商业拓展能力（如：财务稳定性）；�系统的安全性；�售后服务。供应商评估�设计标准；�设计回顾/设计确认；�源代码回顾(如果是定制的系统)。上述和用户/系统需求有关联的设计文件包含了：�所有系统输入、输出和界面；�所有的功能和性能要求；�系统结构、组成&它们的关系；�错误定义和处理。典型的由系统供应商提供和维护这是一个法规要求的验证活动来确认所有的法规和业务（用户需求标准）的需求：�均已涵盖在整个设计标准中；�完整的、可测的在设计回顾报告中记录回顾的结果。基于风险评估来确定是否需要对订制系统进行源代码审核，该回顾用于确认：�代码符合程序的标准；�和之前已定义的设计和标准相一致；�代码错误（例如：死代码的识别和&移除）。需要记录所有的不符合项的名称及更改行动。注意:•本次回顾需要由独立于开发人员来完成；•本次回顾应该在正式的测试开始之前完成!执行源代码回顾的人员必须对系统和设计语言所需的代码具有足够的培训和知识。源代码回顾应该主要关注于高风险部分。在进行软件单元/模块的开发测试之前完成所有的整改行动。对没有进行纠正的所有情况应该用适当的理由来解释。�安装确认；�运行确认；�性能确认。�确认计算机及其相关的设备硬件安装，例如在控制系统中：�电线检查、电的供应；�界面、接口。�确认安装了正确版本的软件；�记录安装过程，并且需要记录任何突发的或者不符合接受标准的事件及其解决方法；�完成安装报告。�确认系统的运行，例如：�相对于用户需求和设计标准的功能性/运行测试；�界面和接口；�安全性和授权；�数据存储和恢复。�记录运行操作过程，并且需要记录任何突发的或者不符合接受标准的时间及其解决方法；�完成运行确认报告。�具体描述怎样进行测试及其测试的程度；�具体描述测试项目同用户需求标准间的关系；�具体描述测试策略/方法，并识别了例如以下问题…-正式的操作方法；-设计测试的范围；-失败模式，包括停电；-自动的纠正措施。�必须在正式测试之前批准测试方案�系统测试是依据测试计划来执行的�在测试的同时，记录实时的测试结果，而不是测试之后或之前；�对于关键的测试步骤，需要保留例如截屏等测试证据，来支持说明相应的结果（标签、记录的次数、签字&日期）；�记录结论(“通过”或者“失败”),并不是随便的勾号记录和交叉的参考�计算机和手动计算结果是一样的；�有的