实验室系统软件验证 sop

[所属分类:技术资料] [发布时间:2020-1-13] [发布人:] [阅读次数:] [返回]

山东拓普生物工程有限公司

Shandong Tuopu Biol-Engineering Co.,Ltd

实验室系统软件验证 sop
这是一个标准操作程序的样版。它仅仅是一个建议和起点。文件的实施范围
和类型依赖于实施过程的环境。这个预定文件应该被适当的改遍和依据独立的风
险评估。该文件并不能保证通过调整后的检查。
一、目的
用于分析实验室的软件和计算机系统需要被验证，因为法规和商业的原因。
验证能够保证分析数据的准确性、可靠性和一致性。本 sop 为如何进行分析实验
室的验证提供指导。
二、范围
实验室计算机系统的验证会影响产品的质量。验证包括整个系统的生命周期
的不同阶段。商业的验证协议不在本文件范围内。不在本 sop 规定范围内的有分
析设备的确认，例如，HPLC 基线探测器的噪音和软件升级时的验证的细节。本
文件中的例外必须基于风险评估，合理的，文件规定的和被实验室经理和 QA 批
准的。
三、术语表和定义
验证：提供高度保证的证据证明工艺能够按照设计的工艺制造出预定质量的
产品。
DQ：设计确认
IQ：安装确认
OQ：运行确认
PQ: 性能确认
URS:用户需求描述
FS: 功能描述
GAMP：优良自动制造规范（论坛）
GAMP：在于帮助理解和使用计算机控制系统，不仅限于制药行业。
GAMP 类别 3：标准软件包。所有的应用软件问题可以被标准功能解决。但是
不代表所有的应用功能
GAMP 类别 4：可配置软件包。提供一个标准的界面和功能解决使用者的细节
应用。
GAMP 类别 5：自定义软件。用来解决应用的细节问题。自定义软件包可以是
一个完全独立的系统，也可以增加到标准软件包中。自定义软件包可以自行开发，
也可以由供应商提供。
标准功能：GAMP 类别 3 中规定的功能。
应急措施：
COTS:商业通用软件
四、参考资料
4.1 GAMP4 指导原则“自动控制系统验证”，ISPE，Brussels,2001,文件来源于
www.ispe.org
4.2 L.Huber Validation of Computerized Analytical and Networked Systems,
Interpharm/CRC,文件来源于 www.labcompliance.com/books/validation3
4.3 SOP S-134 “GXP 系统风险评估”，www.labcompliance.com/solutions/sops
4.4 SOP S-252 “计算机系统验证风险评估”，
www.labcompliance.com/solutions/sops
4.5 SOP S-265 “宏观项目和应用软件验证”，
www.labcompliance.com/solutions/sops
4.6 SOP XXX “卖主评估：准备，沟通和跟进”，
4.7 模版和例子 E-255”层析数据系统需求描述“
www.labcompliance.com/solutions/examples
4.8 SOP S-262 “软件和计算机系统变更控制”
www.labcompliance.com/solutions/sops
4.9 SOP S-283 “计算机网络和系统变更控制-计划变更“
www.labcompliance.com/solutions/sops
4.10 SOP S-284 “计算机网络和系统变更控制-非计划变更“
www.labcompliance.com/solutions/sops
4.11 模版和案例 E-362 “测试案例和文件-授权数据库“
www.labcompliance.com/solutions/examples
4.12 模版和案例 E-358 “电子表格测试文件（矩阵列表，第 29 页）”
www.labcompliance.com/solutions/examples
4.13 模版和案例 E-326 “网络基础和系统证明”
www.labcompliance.com/solutions/examples
4.14 缺陷分析和检查 E-158 “实验室计算机系统“
www.labcompliance.com/solutions/examples
五、职责
5.1 系统所有者
5.1.1 掌握验证活动和结果的细节，执行和文件过程。这需要系统所有者有一定
的计算机系统验证经验。
5.1.2 成立一个验证小组
5.1.3 起草验证文件
5.2 QC 经理
5.2.1 准备需求描述
5.2.2 准备测试资源
5.2.3 审核和批准验证文件
5.3 实验室职员
5.3.1 准备系统需求描述
5.3.2 审核系统需求描述
5.3.3 参与风险评估
5.4 IT 部门
5.4.1 审核有关网络基础设备的风险评估和测试范围的内容
5.4.2 审核和批准有关网络设备的验证文件
5.5 供应商
5.5.1 提供软件和计算机系统的功能描述
5.5.2 提供软件开发过程质量受控和软件经过验证的文件证据
5.5.3 如有必要，接受买家的审核
5.5.4 提供计算机系统安装环境的信息
5.6 工程部
5.6.1 为计算机系统支持人员提供符合安装信息的安装环境
5.7 质量保证部
5.7.1 审核规则和指南符合 GXP 和 part11 的要求
5.7.2 审核文件符合企业方针和政策
5.7.3 进行供应商审核
5.7.4 审核和批准验证文件
6.使用条件
6.1 新进系统的验证
6.2 系统升级和其他系统的改变
6.3 审核发现系统超出了验证时的指标
7.验证原则
7.1 概述
计算机系统验证不是一个一次性完成的过程。对于一个新系统而言，验证开始于
使用部门提出系统需要和系统需要解决什么问题。对于一个存在的系统，验证开
始于系统所有者确定的验证状态。验证完成于系统不再使用，或者所有的重要的
数据已经被转移到新的系统中。重要的步骤包括：验证计划，定义客户需求，验
证发展，供应商评估，安装，初始和进行测试，变更控制。换句话说，计算机系
统验证贯穿系统的整个生命周期。
因为计算机系统的复杂性和长期性，计算机验证通常可依据生命周期分为几个部
分。一些生命周期的模型在一些文献上有描述。一种经常使用的模型是 V 型模式。
它通常由客户需求描述（URS），功能描述（FS），设计描述（DS），开发和测试编
码，安装确认（IQ），运行确认（OQ），性能确认组成。（更多的细节请参照 4.1
和 4.2 涉及资料的内容）。
本 sop 的目的是因为 V 型模型的描述不够详细。例如，供应商的评估并没有包括
在内。其他的私人的或官方的指南文件也使用 4Q 模型，其中设计确认（DQ）包
括了供应商的评估。但是 4Q 模型不包括任何开发的活动。两个模型都不包括最
后的退出状态。本 sop 的目的就在于提供了一个结合了所有 4Q 和 V 型模型的要
素，并包括了所有其他系统要素的周期模型。下表提供了一个此模型的大纲：
客户代表定义客户或系统需求描述。（URS，SRS）如果供应商不能够提供一个商
业系统，软件需要开发和验证，遵照图表左边的步骤进行。程序员开发功能描述，
设计描述和源代码，并且对所有的要素进行测试。当一个商业系统使用到了 SRS
或者提供给一个或多个供应商的特定要求（见表右）。供应商需要符合每个需求
或者功能描述的最适合客户需求描述的部分。使用者将供应商提供的回应和他们
自己的要求进行对比。如果没有供应商能够满足所有的客户需求，将会选择最符
合的那个或者使用其他的按照图表左边的开发循环编写的符合客户需求的软件。
最适合客户技术和商业需求的供应商将被选择和确认。
下一步系统将被安装，运行和确认。在系统正式使用前，它必须在一个合适的环境
下测试确认其符合功能描述（OQ）和最终的操作情况符合 URS（PQ）。任何系统的变
更必须符合规定的变更程序，在系统淘汰前，所有系统产生的质量和相关记录必须
被成功的转移到新的系统中。
一个特定的验证项目活动应该遵循验证计划。验证计划描述了验证的任务，时间表，
分工和负责人。验证项目计划依据公司或者验证主计划的一个方面。验证的结果概
述在验证报告中说明。
7.2 定义
7.2.1 验证
本 sop 中提及的验证的定义为：“建立文件化的证据，该证据能保证某一特定过程/
工艺能够持续地生产符合事先规格标准和质量特征的产品。”（来源：FDA 验证指南，
1986 年 3 月）
7.2.2 计算机系统和计算机化系统
计算机系统由计算机硬件，软件和外设如打印机，CD、DVD 组成。
分析实验室内的计算机通常连接在分析仪器，如 HPLC、天平和分光光度计上。这种
将分析仪器，计算机和仪器操作系统结合在一起的系统，我们通常称为计算机化系
统。
7.3 软件种类的定义
验证的范围依赖于计算机系统的复杂性。验证的范围也取决于使用者使用系统的范
围。更多的通用软件被使用，很少有定制功能被通用软件使用，很少的测试被个人
使用者使用。GAMP 开发了基于不同特性的软件分类。整个软件被分为五类。本 sop
仅适用与第三到第五类。定义能够在 3 的术语表中找到。每个计算机系统都能够在
表中找到对应。
7.4 风险评估
验证的范围也依赖与记录的产生和系统与产品质量的关联度。所以风险种类应该被
每一个系统所定义。系统风险的种类依赖于风险等级和系统产生关键数据的数量。
风险的类型可分为高，中和低。
8.0 程序
8.1 建议和计划
8.1.1 实验室经理使用附件 9.1 中的表格提出新系统的需求。这个需求应包括系统
的用途，预计的地点和环境，如何解决当前的问题和一个简单的系统建议。这个需
求也应该包括商业利益，估价和供应商名单。
8.1.2 如果需求被批准，遵照 8.1.3 后程序进行。
8.1.3 实验室经理指定一个系统负责人。
8.1.4 系统负责人组织一个由以下人员组成的验证小组：
系统的使用者
QA
验证组（如果有的话）
IT 部门（如果系统计划联网运行的话）
8.2 责人起草一个验证项目计划草案并提交 验证组审核。
这个计划应该包括系统最初的风险评估。
8.3 基本功能描述
8.3.1 系统负责人应该基于以下信息起草一个客户需求描述：
系统使用者提出的技术需求
实验室经理提出的技术和商业要求
IT 部门（如果该系统计划连网）
QA 提出的法规需求
验证组提出的验证需求
模版和案例参考 4.7 中的参考资料或者一个等同的模版。一些特定的要求需要
加入：
描述预计的过程和环境
关键的功能描述
符合法规如 Part11 的要求
安全性
当前和未来网络的兼容性
未来的升级能力
供应商提供的软件系统的验证材料
供应商提供的其他服务，例如上门服务，培训，安装确认，运行确认和快速的
售后支持（电话、在线）。
测试功能
特定的识别信号，如序列号
验证活动的连续性：例如运行确认和性能确认可以追溯到客户需求。
选择性：功能的优先排列，例如，必须，想要，最好有
8.3.2 系统负责人起草并将按照 8.3.1 中的要求写好的需求描述供审核，并收
集信息，或在需要时修改文件。
8.3.3 系统负责人预选供应商并且给预选的供应商发送需求描述或 RFP。RFP 依
据需求描述制订。
8.3.4 系统负责人评估供应商的回复并且建议选择一个供应商。决定基于以下
因素：
符合 8.3.2 中提出的需求描述
供应商的资历
购买，使用和验证的价格
8.3.5 系统负责人需要记录功能需求和供应商提供的软件之间的偏差。如果没
有偏差按照 8.4 执行。
8.3.6 系统负责人需要描述 8.3.5 中提及的偏差与 8.3.1 中的不符之处。
8.3.7 验证组决定这个偏差是否可以被接受或者这个偏离的功能必须通过额外
的软件来实现。
8.3.8 如果这个偏差可以被接受，遵照 8.3.10 中的规定进行，如果不可被接受，
遵照 8.3.9 中的规定进行。
8.3.9 额外的软件必须可以消除客户需求描述的要求和标准软件之间的偏差。
这样一类软件属于 GAMP 5。开发中的开发和验证程序需要遵循 4.5 中的参考资
料的要求。
8.3.10 系统负责人修订验证项目计划，补充更多的细节使之符合验证范围，系
统风险分析测试，客户需求和 GAMP 分类。
8.4 供应商审核
8.4.1 QA 依照 4.6 中的 sop 对供应商进行审核。评估的程序依照：
使用和审核外部参考资料
使用和审核内部参考资料
邮件，如果需要的话，电话联系
第三方认证
直接认证
最终的结论依赖于：
系统的复杂性
系统的商业影响
系统使用的广泛性和成熟性
8.4.2 QA 做出供应商可接受或不可接受的决定并记录评估内容。
8.4.3 如果卖方不是软件系统合格供应商，则返回到 8.3.3 进行
8.5 安装和设置
8.5.1 系统负责人需要从卖方了解系统环境状况和空间需要。这类信息包括：
温度和湿度
电磁干扰
电源
空间需要
联网要求：网络结构
8.5.2 系统负责人安排设备维护（和 IT 部门一同如果系统联网的话）指定计算
机系统的安装地点。
8.5.3 在系统到来前，系统负责人检查系统和合同一致和系统物理状况。
8.5.4 系统负责人安排卖方安装系统。
8.5.5 卖方和使用者代表按照卖方说明书安装和配置系统。
8.5.6 卖方和使用者代表确认安装的硬件和软件条件适合。检查内容包括：
硬件安装检查
检查软件的安装正确完全
按照卖方的安装和使用说明书进行了测试
通常测试的范围和文件依据 4.4 中的 sop 规定
8.5.7 系统负责人依照 XXX 确认系统和所有的设置，或者等同的文件，或者配
置管理者设计的测试软件。
8.5.8 系统负责人确认软件备份是否可用，或者确认软件备份符合国家的或国
际的复制准则。系统负责人将软件备份放置在安全的地方。
8.5.9 安装文件应由 QA，系统使用者和供应商代表签名（如果安装是由供应尚
进行的）
8.6 在合适的环境中进行的功能测试（OQ）
以下测试在于确认系统运行在设计的环境中。
8.6.1 卖方和使用者代表确认计算机系统功能。特别要进行以下测试：
商业标准功能
非标准功能
物理或逻辑安全
数据的备份和恢复
标准测试非供应商测试资料确认测试环境符合要求
可能被客户的设置影响的功能
被客户使用环境影响的功能，如网络和交换机的距离，操作者技能
应用软件的启动和中断
错误的操作
软件冲突
对于网络系统：
网络连接
文件转移的正确性
考虑以下测试：
测试应该和用户需求对应
测试应该用数据来表示，测试文件应该包括可接受标准和实际结果
测试的案例和数据应该被设计和形成文件以便下次使用
测试应该包括测试的数据符合软件的使用范围，有界限和超过范围的功能测试
依照 4.11 中的参考资料进行测试。测试记录，界限测试，超标测试和记录的追
溯性测试依据 4.12 中的资料测试。
测试范围依赖与系统标准，成熟度，复杂性和客户定制的等级。依照 4.4 中的
sop 制定测试范围的标准。
8.6.2 测试文件应由 QA 签名，系统负责人签名和卖方代表签名如果卖方代表参
与了测试的话。
8.6.3 测试应该按照 8.6.1 中的内容进行再验证。验证周期为一年一次。
8.7 初始和后来的性能确认
这些测试在于确认使用者的应用和预期的一致。
使用者代表确认系统预期的技能和运行环境相称。测试范围和文件依据 4.4 的
sop。
对于实验室系统，这些测试应该能包括：
Processing of well characterized user specific data files
系统兼容性测试
Analysis of well characterized reference samples
8.7.2 测试文件应该有 QA 和系统负责人签名
8.7.3 在系统日常使用时，8.7.1 中的测试应该被重复进行。测试的内容和测试
的频率参考系统的测试内容和测试频率，但是他们应该被系统所有者定义。
8.7.4 为了确认系统的稳定性和数据的正确性，还应该进行额外的测试：
定期检查病毒
定期清除临时文件
定期检查系统数据库
8.7.5 QA 应该定期审核计算机系统。频率一般定为每年一次。最初和后来的审
核参考 XXXX 文件。
8.8 变更控制
8.8.1 任何系统的变更必须遵照变更程序
非联网的系统依据 4.8 中的 sop
联网的系统的计划内变更依据 4.9 中的 sop
联网的系统的非计划内变更依据 4.10 中的 sop
特别应注意：
评估商业计划变化带来的风险
分析变更对验证的影响，决定重新验证的内容
定义不同的系统谁有权利发起，同意和批准变更
回顾批准非计划变更
所有的变更都必须记录在 8.8.1 中涉及的 sop 或相同的文件中规定的变更记录
中。
8.9 系统引退
8.9.1 系统负责人负责使用 9.2 中的表格，发起系统引退程序。
8.9.2 如果数据在引退后不需要被再处理，遵照 8.9.4 中的内容进行
8.9.3 系统负责人负责安排制定数据转移的标准和确认数据转移到新系统处理
的正确性。
8.9.4 系统负责人负责将非标准化的电子表格转化成标准的电子表格。非标准
的电子表格能够被转化成标准的例如 PDF 或者 XML 或者其他能够被打印出来的
格式。这表明记录的内容和意思可以被保存。
8.9.5 系统负责人将系统引退表交 QA、实验室经理（对于联网的系统，交 IT
部门）审核和批准。
8.9.6 系统负责人升级系统详细的数据库。
8.10 验证报告
8.10.1 系统负责人在依照 8.7.1 进行的第一次 PQ 测试结束后起草验证报告。
报告应该包括：
系统概述
验证方法
大致的测试步骤
任何验证中出现的偏差和纠偏的措施
系统验证的综述
QA 和实验室经理和 IT 部门如果系统联网的话，批准。
8.10.2 系统负责人将最初的验证报告交 QA、实验室经理（对于联网的系统，交
IT 部门）批准。
8.11 现行系统的验证
在以下情况下需要对现行系统进行验证：
系统符合以往的 GXP 要求，但是不能证明符合现行的改进的要求。
系统不是使用在 GXP 和行业标准要求下，但是未来要在 GXP 和行业标准下使用。
一般验证现行系统和验证新系统没有什么不同。从 8.6 到 8.10 的步骤内容是一
样的。
8.1 到 8.5 的步骤放置到 8.11.1 到 8.11.4 之后。
8.11.1 系统负责人组织一个 验证小组，起草验证项目计划。
8.11.2 系统负责人确定系统的使用和功能。
8.11.3 系统负责人评估是否系统现有功能符合所有行业标准和法规。例如：
安全性能
是否符合 FDA Part11 对电子签名，电子记录等等电子记录修改追踪方面的要求。
8.11.4 系统负责人将审核结果交验证组，验证组决定
A、如果系统直接使用，按照 8.5.7 的步骤进行
B、如果系统要进行升级，按照 8.3.1 的步骤进行
C、如果不适合，也无法升级，则停止。