计算机化系统标准管理规程.doc

(完整版)计算机化系统标准管理规程
计算机化系统管理规程
内 容:
1 计算机化系统定义：
由硬件、系统软件、应用软件以及相关外围设备组成的，可执行某一功能或一组功
能的体系.
2 计算机化系统管理原则：
2.1 计算机化系统代替人工操作时，应当确保不对产品的质量、过程控制和其质量保证水平造成负面影响，不增加总体风险。
2。2 风险管理应当贯穿计算机化系统的生命周期全过程，应当考虑数据完整性和产品质量。作为质量风险管理的一部分，应当根据书面的风险评估结果确定验证和数据完整性控制的程度。
2.3 供应商提供产品或服务时（如安装、配置、集成、验证、维护、数据处理等）,应当与供应商签订正式协议，明确双方责任，并基于风险评估的结果开展供应商质量体系审计。
3 术语：
3。1 计算机化系统生命周期：计算机化系统从提出用户需求到终止使用的过程，包括设计、设定标准、编程、测试、安装、运行、维护等阶段。
3。2 应用程序:安装在既定的平台/硬件上,提供特定功能的软件。
3。3 PLC（programmable logic controller）:可编程控制器。
3.4 URS：用户需求标准，用户需求说明书.
3.5 I／O:输入/输出
3。6 白盒法：白盒法也称为结构测试或者是逻辑驱动测试，是在软件测试过程中，由详细设计提供的文档，从软件的具体的逻辑结构和执行路径出发，设计测试用例，完成测试的目的，白盒法测试主要用于测试程序内部逻辑。
3。7 黑盒法：黑盒法也称功能测试或者数据驱动测试,是基于规格说明的测试,它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下,测试者在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性，常用如下4 种方法：
3.7。1 等价划分法（将系统的输入区域划分为若干等价类，用每个等价类中的一个具有代表性的数据作为测试数据）。
3.7。2 边界值分析法(尽可能选取边界值作为测试数据）。
3。7.3 因果图法(在系统功能说明中找出各种因果关系,设计测试用例）。
3.7.4 错误推测法（推测系统容易发生的各种错误,设计能检查出这些错误的测试用例）
3。8 计算机系统验证：是对用于药品开发及生产的计算机系统,是否按照要求的规格进行合理的开发,且在运用开始后是否进行合理的管理，作出评估和确认的行为称为计算机系统验证。
4 计算机化系统分类与验证方法:
分类
分类说明
验证内容
第1类：
基础结构软件
1 操作系统
2 常用办公软件
3 专业软件（编程软件、杀毒软件、绘图软件等）
1 确认名称及版本号。
2 确认被正确的安装在了计算机中的指定文件夹中的位置.
3 确认可以正常运行.
第2类软件：不再使用.
第3类:
不可配置软件
1 固件程序(固化在存储器中，不可修改或需特定刷新程序才能修改）。
2 智能仪表/智能工具等嵌入系统软件。
3 屏蔽了“可配置”功能的“可配置系统”或需要特殊权限的“可配置系统"。
1 用户需求标准（URS)
2 供应商审计。
3 确认名称及版本号。
4 确认被正确的安装在了计算机中的指定文件夹中的位置。
5 根据使用要求基于风险的必要的功能测试。
6 维持系统符合性的SOP.
第4类：
可配置软件
1 具有可配置参数的工业控制软件、检验仪器数据处理软件。
2 具有可配置参数的综合管理类软件。
例如：
LIMS系统：实验室信息管理系统。
SCADA系统：数据采集与监控系统.
 CDS系统：色谱数据系统。
 DCS系统：集散控制系统。
 HMI系统：人机界面系统.

1 用户需求标准（URS）。
2 供应商审计.
3 供应商质量体系评估。
4 设计说明与功能描述。
5 确认名称与版本号。
6 确认被正确的安装在了计算机中的指定文件夹中的位置。
7 在测试环境下基于风险的必要的输入／输出（I／O)测试。
8 在工艺流程中基于风险的必要的功能测试。
9 维持系统符合性的SOP。
第5类：
定制应用软件
1 定制的工业控制软件、数据处理软件,如定制的PLC控制软件、DCS、SCADA、BMS软件.
2 定制的管理类软件，如EXCEL中的宏、定制的ERP、定制的GMP质量管理软件。
1 在可配置软件所有验证项目基础上增加两项。
2 设计审核。
3 源代码审核。
5 计算机化系统清单管理：
5。1 我公司制定包含药品生产质量管理过程中涉及的所有计算机化系统清单,以GMP文件管理模式管理。 
5。2 计算机化系统清单内容应至少包括：计算机品牌、计算机型号、计算机编号、安装位置,与药品质量管理相关功能，计算机使用人，计算机类别等项目。
5.3 计算机化系统清单应在公司计算机化系统出现新增、报废、安装位置变更、软件升级、功能变动等情况出现时及时变更.
6 计算机化系统权限与密码管理：
6.1 计算机权限管理：
6.1。1 计算机权限分为：管理员权限（admintrator)，标准用户权限（power users），受限制用户权限(users)三级权限管理。
权限等级
人员
拥有的权限
管理员权限（admintrator）
质量负责人
拥有最高权限
可以修改电脑的任何配置
标准用户权限（power users)
各部门负责人
拥有大部分权限
可以设置安装软件
修改个别文件的权限
拷贝电子数据及文件
受限制用户权限（users）
设备使用人员
拥有受限制的权限
不允许安装各类软件及新建文件夹
不能修改系统时间
不能关闭系统
不能拷贝/删除电子数据及文件
6。2 计算机密码管理：
6。2.1 计算机密码管理分为管理员级别，标准用户级别,受限制级别三级密码管理。
6。2。2 每个操作人员拥有独立的账号,各操作人员不得使用其他账号登录系统 ，账号实行密码识别，确保每个账号的独立性.
6.2.3 密码要求不少于6位,必须由数字与字母共同组成，为避免内部冲突,不能使用“￥＠％”等特殊字符。
6。2.4 标准用户密码和受限制用户密码都必须在计算机管理员处登记备案.
6。2。5 计算机密码每三个月更换一次,管理员应定期(最长不超过三个月）审核每个用户的密码，用户每次更换密码要及时到管理员处备案，由管理员核对.
6。2。6 为防止密码遭暴力破解，每一个账户输入的密码错误的次数不能超过3次/天,如超过错误的次数账户即被锁定，需通知管理员解除锁定.
7 计算机化系统安全管理
7。1 系统应当安装在适当的位置，以防止外来因素干扰.
7.2 计算机化系统软件操作系统应设置登录用户名与密码,应设置系统屏保不超过10分钟，退出屏保进入操作系统时需要密码。
7.3 有人离开公司，该人使用的计算机系统要进行一次安全性评价与变更.
7.4 如果一个计算机系统不再使用，要保证3年内至少有一台仪器能够打开原有的资料.

8 计算机系统维护管理：
8。1 为保证计算机系统能够正常运行需对计算机进行定期维护，主要从硬件和软件方面入手。硬件包括计算机主要部件的保养，每年保养一次；软件包括计算机操作系统杀毒等，每周一次.
8。2 我公司办公用计算机系统维护除系统杀毒外其余工作由公司指定电脑公司负责，其余计算机系统（如工作站等）由设备供应商维护。
9 计算机系统验证管理。
计算机系统验证分六大周期，分别是：计划和需求阶段，设计阶段，测试阶段，配置阶段，使用阶段，隐退阶段。
9.1 计划和需求阶段：
内容
责任部门
1 风险评估:从技术及经济等方面系统地研究并论证开发／变更计算机系统的可行性,包括目的、规模、风险分析、投资分析等。
质量保证部
2 计算机化系统用户需求标准（URS）：用于描述满足使用目的的需求，包含以下内容：
2.1 系统说明:说明全系统要做什么,模块间怎样连接及相互作用,控制方式，执行的过程，操作人员对接口的要求及安全性要求等。
2。2 物理要求：物理要求包括有效空间、位置、所处的环境等。
2。3 硬件文件：硬件文件包括图纸、流程图、手册、部件清单等。 
2。4 软件文件：软件文件包括系统框图、配置清单等.
2。5 测试要求：系统开发过程中所要求进行的测试项目及记录.包括单独模块测试及集成测试等。
各使用部门
3 验证计划：验证计划应包含以下内容:
3.1 基于风险的验证方法。
3.2 验证方案。
3.3 必要的培训。
3.4 测试的方法。
3.5 各部门职责.
3.6 验证时间表。
质量保证部
4 供应商审计：应对计算机系统的供应商进行评价，以确保其系统能力及所提供的产品满足计算机系统验证要求，包括以下内容:
4。1 系统开发者的内部质量管理.
4。2 技术能力评估。 
4。3 软件开发及测试能力。 
4。4 程序编制人员的资格审定。
4.5 硬件开发及制造能力.
4。6 变更控制。
4。7 售后服务。
4。8 系统安全性。 

质量保证部
9。2 设计阶段：设计阶段分为设计标准、设计确认以及源代码回顾（定制系统）。
内容
责任部门
1 设计标准：用详细的技术语言来描述如何开发设备才能提供用户需要的功能。需要供应商提供,用户来进行批准。对于商业化的标准化的设备不需要这个文件。 具体包括如下：
1。1 硬件设计标准：如标准仪器、微控制器、可编程控制器（PLC）等。 
1。2 软件设计标准：如系统的整体框架、计算机语言、界面、屏幕设计、数据流程图、报告设计、图表设计、运算法则、安全测试、系统结构图、I／O 图（输入/输出）、工程制图、流程图解、程序体系图解等。
系统供应商
2 设计确认：以书面的形式确认该设备的设计能够满足用户需求标准（URS),需要质量受权人批准，批准后如果有什么变化是需要按照变更流程管理的，提出变更申请。
质量保证部
3 源代码回顾（定制系统)：基于风险评估来确定是否需要对定制系统进行源代码审核，该回顾用于确认代码符合程序的标准.
系统供应商
9.3 测试阶段：测试阶段主要对计算机系统进行安装确认、运行确认以及性能确认。
内容
责任部门
1 安装确认（IQ）：安装确认的目的是保证系统的安装符合设计标准,并保证所需技术资料俱全，具体确认内容包括如下： 
1.1 确认各种标准清单，包括使用者要求、功能性要求、物理要求、系统标准。
1。2 确认各种标准操作程序(SOP):包括硬件和软件的操作、预防维修、备份和数据存档、灾难（断电、硬软件损坏等)恢复及系统隐退。
1.3 确认计算机及相关设备的安装符合用户需求标准（URS）。
1。4 确认系统安装了正确版本的软件。
1。5 确认并记录系统安装的环境，包括清洁度、射频／电磁干扰、振动、物理安全性、噪声、照明。
1。6 记录安装过程，记录任何突发的或者不符合接受标准的事件及其解决办法。
系统供应商
2 运行确认（OQ）：运行确认的目的是保证系统及系统运行符合需求标准.运行确认应在一个与正常工作环境隔离的测试环境下实施，但应模拟生产环境。具体包括如下：
2.1 相对于用户需求标准（URS)和设计标准的功能性测试。
2。2 界面和接口确认。
2。3 系统安全性测试。
2。4 数据的采集及存储确认。
2。5 数据处理能力确认.
2。6 断电／修复测试。
2.7 灾难恢复测试。
系统供应商
3 性能确认(PQ）:性能确认是为了确认系统运行过程的有效性和稳定性，应在正常生产环境下进行测试。测试项目依据对系统运行希望达到的整体效果而定，测试应在正常生产环境下（相同条件下）重复3 次以上.注：当计算机系统取代人工系统时，可以进行平行的验证试验.
系统供应商
9。4 配置阶段：配置阶段主要从以下内容进行确认。
内容
责任部门
1 数据的录入和数据的转移
2 系统权限功能。
3 数据的保存、备份和恢复功能.
4 灾难恢复功能.
系统供应商
9。5 使用阶段:
内容
责任部门
1 人员培训:系统在正式投入使用之前，应对所有相关人员,包括操作人员、维修人员等进行培训，确认其能够按要求正确操作
系统供应商
2 计算机系统台账更新/管理：作为管理对象的计算机体系，全部要更新到计算机系统台账中,质量保证部负责管理该台账。
3 计算机系统操作规程：每类/台计算机系统都要建立标准操作规程，包括：操作事项，维护保养，安全管理等.
4 安全管理：必须定义控制计算机系统物理及逻辑通道的安全程序,安全程序涉及如下范畴：
4。1 系统软件及应用软件安全性。
4.2 硬件安全性。
5 备份、存档、灾难恢复：必须制定相应文件以控制系统备份、恢复程序、存档需求以及出现系统丢失事件时的灾难恢复程序， 根据需要定期进行体系及数据的备份。
6 问题报告：计算机系统在使用过程中所遇到的任何问题及缺陷均应进行记录和报告，以便对其运行效果及变更控制结果进行评价。
7 维护日志：记录所有计划的及非计划的维修活动。系统维护和变更控制是保证系统在受控及已验证状态下运行的两大关键。
8 变更控制:计算机系统经过验证后，保持已验证状态.如果系统发生变更，此种状态将会被破坏。 变更类型包括：硬件变更、软件变更及数据库中关键参数的变更。为了维持系统始终处于已验证状态,应对其变更实施控制，具体要求如下.
8.1 使用部门提出书面申请，包括变更理由、依据、内容及实施方案。
8。2 质量保证部门对变更进行评估及审批。
8.3 根据变更影响的范围决定是否应实施再验证,如变更已导致计算机系统的已验证状态发生偏移（如增加了某些功能等),系统必须针对变更部分实施再验证.决定实施再验证后，计算机系统将开始生命周期的另一循环。如经过评估确认不实施再验证，应有充分的依据作支持. 
8.4 所有变更必须经过相关人员批准后方可实施，不允许自行改变系统任何部分。 
8。5 变更应充分考虑是否对其他相关系统产生影响，需对其他受影响系统进行评价，必要时会对其他系统实施再验证。 
8。6 所有的变更申请、评估、审批及再验证活动均应有文件记录，以使之具有可追踪性
质量保证部及各使用部门

内容
责任部门
9 周期性回顾及再验证：
9。1 系统的变化一般可分为两种。一种为已知的、有形的变化，这种变化应按照以上所述的变更控制要求执行.
9.2 另一种变化是系统在长期频繁使用中,由于时间的变化、环境的变化、人员的变化、硬件的磨损等因素导致的一种未知的、无形的变化。对于这种变化，需要对系统进行周期性回顾，回顾周期为3 年。周期性回顾用以确保以下几方面:
9.2。1 系统运行始终处于已验证状态。
9.2。2 系统维护严格按相关程序执行。
9。2.3 系统文件及时而准确地反映了现行计算机系统的运行情况。 
9。3 如果通过回顾，发现计算机系统的已验证状态已发生偏移，系统必须实施再验证，系统回顾的范围、方法及结论均应有文件记录，以使之具有可追踪性。
质量保证部
9.6 隐退阶段:当一个计算机系统的现行功能不再适用，或执行一个新系统替代现有系统的功能时,该系统就从实际使用中引退,此阶段目标是要消除对原系统的依赖并提供一个如何从原系统中取回相关数据的方法。
内容
责任部门
1 隐退计划:
1。1 制定一个隐退计划以确定引退工作的步骤、鉴别将要替代原有系统的新系统、引退过程的期限及相关责任.
1。2 确定原系统数据是否应按照一定的格式存档。
1。3 如果原系统被另一个系统替代,存档的数据应该被装载在替代系统中，数据成功转移的确认是新系统验证的一部分。
1.4 系统引退时，应通知到所有受影响的用户，并完成以下工作.
1。4.1 撤销系统特殊的程序。
1。4.2 切断系统通道。 
1。4.3 整理系统所有逻辑值、符号和菜单参考。
1.4.4 删除所有软件和工作环境下存档的电子记录.
2 系统引退报告,系统引退报告用于总结整个系统引退工作的实际执行结果，确认是否按要求正确实施引退活动。
质量保证部
9.7 验证文件管理:所有的验证文件原件均在QA 处存档，这些资料构成每一个计算机系统整个生命周期的重要档案，具有原始的可追踪性。验证文件包括：用户需求标准(URS），
在系统供应商处进行的单体测试及组装测试报告，供应商审计报告，系统安装确认方案及报告，系统运行确认方案及报告，系统性能确认方案及报告,变更审批表,偏差处理表,系统再验证方案及报告，系统周期性回顾报告等。