计算机系统的验证

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

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

Shandong Tuopu Biol-Engineering Co.,Ltd

本部分主要从以下对计算机验证进行介绍：
1. 法规对计算机验证的要求；
2. 基本术语；
3. 实验室电子公式验证方法；
4. 计算机化系统的验证方法。
一、法规对计算机验证的要求
10 版 版 GMP ： ：
第八章 第八章 文件管理 文件管理
第一百六十三条 如使用电子数据处理系统、照相技术或其
它可靠方式记录数据资料，应有所用系统的详细规程；记
录的准确性应经过核对。
如果使用电子数据处理系统，只有受权人员方可通过计算
机输入或更改数据，更改和删除情况应有记录；应使用密
码或其它方式来限制数据系统的登录；关键数据输入后，
应由他人独立进行复核。
用电子方法保存的批记录，应采用磁带、缩微胶卷、纸质
副本或其它方法进行备份，以确保记录的安全，且数据资
料在保存期内应便于查阅。
新版GMP计划增加以下五个附录：
1. 确认和验证；
2. 计算机化系统；
3. 原辅料和包装材料的取样；
4. 参数放行；
5. 药用辅料。
附录11：
人员
1. 关键人员与计算机化系统人员之间需要紧密合作，相
关使用计算机化的系统人员应接受使用和管理的培训，
需要有资质的人员对计算机化系统的设计、验证、使用
等方面进行培训和指导。
验证
2. 应根据以下因素来决定计算机化系统的验证范围，这
些因素包括：该计算机化系统的用途、该验证是预验证
还是
欧盟 欧盟 GMP ：
回顾性验证、该计算机化的系统是否使用了新型的元素
等。计算机化系统的验证生命周期包括：计划、设定标
准、编程、测试、试运行、文档管理、运行、监控和升
级。
系统
3. 应注意设备安装在适当的位置，以防止外来因素干扰
系统的工作。
4. 应有一个详细描述系统的文件，并及时更新。此文件
应详细描述系统的工作原理、目的、安全措施和适用范
围、计算机运行方式的主要特征，以及如何与其他系统
和程序相接。
欧盟 欧盟 GMP ：
5. 软件是计算机化系统的重要组成部分。软件的
使用者应采取适当的措施，保证所编写的软件
符合质量保证系统。
6. 必要时，系统应当有数据正确输入和处理的内
置复核功能。
7. 在计算机化系统使用前，应当对系统进行全面
的测试，并确认系统可以获得预期的结果，当
计算机化系统替代某一人工系统时，作为测试
的一部分，两个系统应平行运行一段时间。
欧盟 欧盟 GMP ：
8. 数据的修改和输入只能由授权的人员进行。
可以采取以下措施防止未经许可的人员对数
据进行输入和修改：钥匙、通行卡、个人密
码和权限，并且应该生效相关的SOP来管理数
据的修改和输入。同时，应当考虑系统能记
录未经授权的人员试图访问系统的行为。
9. 当人工输入重要的数据时（例如：在备料过
程中输入物料的重量和批号），应当复核输
入记录的准确性，该复核操作可由另外一个
操作人员完成或采用经验证的电子方式。
欧盟 欧盟 GMP ：
10.计算机化系统应当记录输入和确认重要数据
人员的身份。只有少数指定人员，方可修改已
输入的数据。每次修改一个已输入的数据均应
经过批准，并记录修改的理由。计算机化系统
应具有可追溯性功能。
11.系统或某一程序的变化应当根据工厂的变更
控制流程进行，系统或某一程序的变化应经过
该系统负责人和质量部相关人员的批准，所有
的变化均应有记录，每一个大的变化都应经过
验证。
欧盟 欧盟 GMP ：
12. 在进行审计时，所存储的数据应能打印出来。
13.可采用实物和电子方法保证数据的安全，以
防止故意或以外的数据损害。应检查所储存数
据的可访问性、耐久性和准确性。如果更换计
算机设备或其程序，应当定期检查对储存的数
据进行检查。
14. 应定期对数据备份，以保护储存的数据。备
份数据应储存在另一个单独的、安全的地点。
欧盟 欧盟 GMP ：
15. 系统应有一个应急的方案，以防止系统出现
故障。应急方案启用的时间应和相关系统的重
要性相关。例如，影响召回产品的相关信息应
能在很短的时间内查得。
16.应建立系统故障时应遵守得程序，并对程序
进行验证。记录所发生得故障和采取得补救措
施。
17. 应建立记录和分析错误及采取的纠正措施的
规程。
欧盟 欧盟 GMP ：
18.  当使用公司外包代理商提供得计算机服务
时，与外包商之间应有正式得协议，并在协议
中明确规定其责任。
19. 当使用计算机化系统放行产品时，只有质量
受权人才能放行产品。此外，计算机化系统应
能辨认和记录放行产品人员得身份。
欧盟 欧盟 GMP ：
二、 基本术语
1.可配置软件(Configurable software)
由供应商开发的程序(主程序或子程序)，该软件可提
供通用功能，使用户可按某种途径为自己设计程序。
2. 系统软件(System software)
操作操作系统和通用功能的一套程序。在硬件及应用软
件之间起接口的作用，且管理计算机的使用。厂家提供
诊断性测试，即确认该软件。
3. 应用软件(Application software)
针对用户的特殊需求而开发、购买或修订的程序(主程序
或子程序)，它可执行数据的收集、处理、报告、存档及
过程控制。
2. 计算机系统(Computer system)
由硬件、系统软件、应用软件以及相关外围设备组成
的，可执行某一功能或一组功能的系统。
4. 计算机系统(Computer system)
由硬件、系统软件、应用软件以及相关外围设备组
成的，可执行某一功能或一组功能的系统。
5. 计算机化系统(Computerized system)
指受控系统、计算机控制系统以及人机接口的组合
体系。可以说计算机系统是计算机化系统的一部分。
如果计算机系统只是用于数据处理，则计算机系统
本身就代表着待验证的全系统。
6. 模块(Module)
即实现某种特定功能的单元或程序段。在软件开发
中常常将程序各个部分继续划分，直至最小的基层
单位，称为模块。
7. 源代码(Source code)
以人类可阅读的形式(编程语言)表示的初始的计
算机程序，在计算机执行之前，须译成机器可
阅读的形式(机器语言)。
8. 黑盒测试(Black box testing)
将系统(软件和硬件)看作不能打开的黑盒，在不
考虑系统内部结构和特性的情况下，测试者只
依靠系统需求，从可能的输入条件和输出条件
中确定测试数据，也就是根据系统的功能或外
部特性，设计测试用例(例如功能测试)。
9. 白盒测试(White box testing)
即结构测试或逻辑驱动测试。这种测试允许测试者考虑系统
的内部结构，并根据系统内部结构设计测试用例，而不考虑
系统的功能。
10. 运行(操作)确认(Operation qualification)
确认系统的各项运性功能符合用户需求标准。系统运行确认
应在一个与正常工作环境隔离的测试环境下实施，但应模拟
生产环境。
11.性能(工艺)确认(Performance qualification)
确认系统运行过程的有效性和稳定性，应在正常生产环境下
进行测试。测试项目依据对系统运行希望达到的整体效果而
定(如对生产出的产品质量各项特性进行测试)。测试应在正
常生产环境下(相同条件下)重复三次以上。
12. 封闭系统(Closed system)
封闭系统是指系统通道处于一种能够被一定的人员所控
制的环境，该人员有权限在系统上进行电子记录的操
作，
13.开放系统(Open system)
开放系统是指系统通道处于一种不能够被有权限在系统
上进行电子记录操作的人员所控制的环境，如电子信件
(E-mail)、在因特网上发送信息等。
三、 实验室电子公式验证方法
根据使用目的，了解电子表格工具的任何人

电子表格的作者不可是预测试的审查人/批准人
电子表格作者不可执行测试

可使用计算机验证开发和验证电子表格和应用
程序
作者
◦ 开发、验证和维护电子表格
◦ 确认所有重要的数据资源都已验证
◦ 必须有能力使用Excel开发电子表格

 用户
评估使用电子表格中产生的变更是否影响
GMP
 批准人
提供独立的审查和确认
必须了解和熟悉GMP和电子表格的要求
编码审查人
使用Excel开发和了解电子表格
部门经理

确认符合当地所有法规
QA/Validation
◦ 在法规符合性和验证活动方面提供指导
电子表格通常分为9个部分
◦ 电子表格的应用
◦ 变更历史
◦ 需求
◦ 设计
◦ 测试 （包含：需求追溯矩阵(RTM)）
◦ 系统访问
◦ 安装
◦ 验证报告
◦ 文件管理
为什么需要变更历史?
需要说明电子表格是如何被修改的
可以记录异常情况及其解决方法
可以记录测试中出现的问题
记录版本历史
根据应用要求附加变更历史
变更历史需记录内容：
版本号 - 每一版本的编号，包括最终版
异常情况编号 – 如果变更是由测试或者使用中
出现的问题引起的
修订日期 – 每次变更的日期
作者 – 编写或者修订电子表格的人
异常情况或者版本描述 – 每一版本中有哪些变
化，以及为什么
异常情况解决方法的描述
版本号应该一致 – 对于较大变更的所有编号，例如，
增加新的计算、增加新的表格、 根据异常情况或者改
进进行小数位变更
异常情况编号从1开始，是连续的
如果更新是由测试失败引起，那么需包括测试号
如果不是异常情况引起的变更 ，解决方法应该标为
“N/A” 
版本
号
异常情况编号 修订日期 作
者
异常情况和升版描
述
解决方法
01.0
0
N/A 2012.11.
04
张
三
新版本
N/A
从以下几个方面确定需求 从以下几个方面确定需求? ? ? ?
确定商业阶段的需求
� 附加应用需求�
� 如果适用，确定风险�
� 考虑输入数据（和计算规则）、计算（和假设）
�
� 使用参考附件支持方法和分析�
� 详述需求，以便测试每个需求�
3. 需求 需求
如通常需要考虑：
◦ 输入 – 是什么? 来自哪里? 什么格式? 有效的范
围是什么?�
◦ 功能 (只用于典型的模板) – 这些描述的位置
(CAP, BP etc)?�
◦ 需要一个复杂计算，还是大量中间计算？
◦ 输出 – 什么格式? �
3. 需求 需求
� 电子表格的设计通常从以下方面进行：
◦ 设计规范�
◦ 电子表格结构�
◦ 特定应用程序的配置�
� 完成需求追溯矩阵，确保设计时考虑了所有
的需求�
4. 设计 设计
� 包括高级设计方面的考虑——使用的工作表的数
量、配置和相互作用�
� 作者应该检查提供的默认内容，并根据个别的电
子表格要求进行必要的修改�
1 1 1 1
系统的计算 采用标准的 采用标准的 Excel功能和计算工具 功能和计算工具 S1
2
开发工具和相关软件
Excel S2
3
计算平台和环境
电子表格采用标准的Excel计算公式
进行，无须外部工具
S3
4
用户界面 通过标准的Excel界面输入，非用户
输入区采用密码保护。
S4
1. 应该默认标准页眉、页脚，文字取向一致。
2. 那些格的内容需要进行保护，如输入密码才能进行修改，
那些数据可以进行输入等。
� 如果已定义，依据数据验证法则输入内容；
� 文字结构有合适的宽度和格式，包括小数位数；
� 不止一个结构单元时，各自设定各自单元的规范。
1 1 1 1
数据的验
证
全部 全部5 5 5 5 个数据必须输入 个数据必须输入 —检查是否有空格，如果任 检查是否有空格，如果任
何一个数据没有输入，最终计算结果显示 何一个数据没有输入，最终计算结果显示“ “ “ “无效数 无效数
据
据” ” ” ”
S11
2
计算 斜率、截距和校正因子
S12
3
逻辑 使用”If”来判定结果
S13
4
输入
X=进样体积，Y＝峰面积
S14
� 独立的审核人回顾所有的结构单元，并了解Excel
及其应用�
� 代码回顾将：�
◦ 证明编写的代码符合预定的功能�
◦ 证明采用了良好的编程方法，符合编程标准�
◦ 检查可能的语法、参考内容和编码错误�
◦ 核查图形输入、输出格式和单元逻辑是正确的
�
◦ 识别和删除死代码�
◦ 确保没有多余的工作表�
◦ 确认所有使用的工作表结构是正确的�
测试中的注意事项：
� 确保已测试或者确认了所有的用户需求和规范 �
� 测试表格包括符合需求和规范标准的测试 �
� 确定执行的测试和其在测试中的顺序�
� 应该在测试环境下进行测试 �
� 屏幕打印件或者拷贝件应该做为证据，或者做为
独立的测试证据 �
� 测试时，必须附上所有拷贝测试结果的文件，并
标识出测试人员、日期、表格名称和版本。 �
� 不能改变预先规定的测试说明或者通过/失败标
准 �
5. 测试 测试
计算结
果名称
输入值 期望的
结果
实际结
果
合格 合格/ / / /失 失
败
测试人 测试日
期
峰面积1 36000
峰面积2 675000
峰面积3 990000
峰面积4 130000
0
峰面积5 157000
0
线性相
关系数
0.998
最终结
果
合格
计算结
果名称
输入值
的状态
期望的
结果
实际结
果
合格 合格/ / / /失 失
败
测试人 测试日
期
峰面积 多个空
白值
最终显
示“无效
结果”
峰面积2
随机选
择一个峰
面积不进
行任何输
入
最终显
示“无效
结果”
峰面积3
五个峰
面积全部
输入
最终显
示“成功”
或“失败”
� 在变更历史表格中对失败进行记录�
� 纠正导致失败的问题�
� 如果需要，重新测试�
� 确保在验证总结报告中记录问题�
� 电子表格应该储存在服务器上，并有访问控
制管理�
� 在系统访问工作表中规定用户访问表格的路
径�
� 使用密码，防止未授权人员访问�
� 设置不同级别的访问权限，或者设置不同要
求的安全功能�
� 安装说明�
◦ 考虑应用程序的名称、服务器的位置、如何
被加载以及如何检查安装是否令人满意�
◦ 从密码控制授权人处获取密码�
� 安装结果�
◦ 验证结束后，安装完成�
◦ 安装报告的批准意味着已经按照安装说明装
载了验证报告中批准的电子表格，并可以使
用。
� 完成剩余的总结�
� 质量人员批准报告�
� 批准表明：�
◦ 完成测试，符合接受标准�
◦ 文件完整，并符合规程�
◦ 缺陷已处理并测试�
◦ 成功处理异常情况�
◦ 表格可以安装和使用�
� 必须由责任人负责表格的使用和访问管理；
� 应该从一个服务器运行，最好有访问控制；
� 授权给需要的人访问，不需要的人不予授权；
� 可能会需要附加密码保护，例如，数据表格。
� 电子表格模板应该在只读的服务器上运行，不可在其
它地方存储，或者有不同的值�
� 打开模板，加载数据，打印后签名和日期�
� 如果需要保存数据等，那么需要按数据表格处理�
� 正如商业流程中规定的，用户文档或者规程指导用户
如何使用所需的应用程序。
类别 类型 举例
1
操作系统
Microsoft NT,
Linux
2
标准市售软件包
（包含固件系统）
分光光度计、
Minitab 统计软件
3
可配置软件包
安捷伦LIMS软件
4
为客户开发的软
件或硬件
客户自己要求供应
商开发的系统
验证阶段 验证文件
类别
1 1 1 1 2 2 2 2 3 3 3 3 4 4 4 4 5 5 5 5
计划和需求阶段
用户需求标准 √ √ √ √ √
验证方案 √ √ √ √ √
系统描述 X X X √ √
法规符合性判定 √ √ √ √ √
供应商审计/评估 X X X √ √
设计阶段
功能要求 X 1 X 1 X 1 X 1 √
设计要求 X 2 X 2 X 2 X 2 √
设计确认 √ √ √ √ √
系统构建 X X X X √
代码回顾 X X X X √
开发测试阶段
开发测试 X X X X √
确认阶段
安装确认 √ √ √ √ √
运行确认 X √ √ √ √
系统放行报告 X X X X √
性能确认 X X X X √
验证报告 √ √ √ √ √
使用阶段
标准操作规程 √ √ √ √ √
偏差管理 √ √ √ √ √
变更管理 √ √ √ √ √
周期性回顾 √ √ √ √ √
报废阶段
报废方案/报告 √ √ √ √ √
一、 计划和需求阶段
验证通常起始于一个确认商业需求的需求文
件，项目团队在获得商业需求后将这些需求
充分细化，用以产生用户需求标准。在起草
用户需求标准时需要充分考虑该系统的法规
符合性和电子记录电子签名的要求。
在该验证阶段通常需要以下文件：用户需求
标准（URS）、验证计划（VP）和供应商审
计/评估（SA）。
1. 用户需求标准（URS）
URS应该关注于系统应该做什么，而不是详
述怎样完成。
URS应该使用对于终端用户和潜在供应商可
理解水平的语言，用以清晰定义系统需要做
什么。需要对任何必要的技术语言或潜在的
不明确语言进行定义。
验证方法
1. 用户需求标准 用户需求标准
计算机系统的URS需考虑如下每部分内容：
对于GMP计算机系统,必须要进行供应商评估， 例
如：网上搜索、 类似系统使用的历史情况等。
验证计划（基于风险评估的结果）应该说明评估
的结果并且说明是否需要供应商审计；
供应商审计的目的就是…
◦ 将供应商验证活动/文件和我们的相比较
◦ 对于供应商不足的地方，确定自己应该采取的行
动和措施
供应商评估/审计中的主要关注点：
技术能力评估；
程序编制人员的资格审定；
质量管理系统的有效性和应用（包括变更控制）；
软件开发标准及软件测试能力；
硬件开发及制造能力；
对维护/进一步开发（如果需要）的支持性服务的有
效性供应商的商业拓展能力（如：财务稳定性）；
系统的安全性；
售后服务。
供应商评估
设计标准 ；
设计回顾/设计确认；
源代码回顾 (如果是定制的系统)。
上述和用户/系统需求有关联的设计文件包含了：
所有系统输入、输出和界面；
所有的功能和性能要求；
系统结构、组成 & 它们的关系；
错误定义和处理。
典型的由系统供应商提供和维护
这是一个法规要求的验证活动来确认所有的法规和业
务（用户需求标准）的需求：
均已涵盖在整个设计标准中；
完整的、可测的
在设计回顾报告中记录回顾的结果。
基于风险评估来确定是否需要对订制系统进行源代码
审核，该回顾用于确认：
代码符合程序的标准；
和之前已定义的设计和标准相一致；
代码错误（例如：死代码的识别和& 移除）。
需要记录所有的不符合项的名称及更改行动。
注意:
• 本次回顾需要由独立于开发人员来完成；
• 本次回顾应该在正式的测试开始之前完成 !
执行源代码回顾的人员必须对系统和设计语言
所需的代码具有足够的培训和知识。
源代码回顾应该主要关注于高风险部分。
在进行软件单元/模块的开发测试之前完成所有
的整改行动。对没有进行纠正的所有情况应该
用适当的理由来解释。
安装确认；
运行确认；
性能确认。
确认计算机及其相关的设备硬件安装， 例如在
控制系统中：
电线检查、 电的供应；
界面、接口。
确认安装了正确版本的软件；
记录安装过程，并且需要记录任何突发的或者
不符合接受标准的事件及其解决方法；
完成安装报告。
确认系统的运行，例如：
相对于用户需求和设计标准的功能性/运行测
试；
界面和接口；
安全性和授权；
数据存储和恢复。
记录运行操作过程，并且需要记录任何突发的或者
不符合接受标准的时间及其解决方法 ；
完成运行确认报告。
具体描述怎样进行测试及其测试的程度；
具体描述测试项目同用户需求标准间的关系；
具体描述测试策略/方法，并识别了例如以下问题…
- 正式的操作方法；
- 设计测试的范围；
- 失败模式，包括停电；
- 自动的纠正措施。
必须在正式测试之前批准测试方案 
系统测试是依据测试计划来执行的
在测试的同时，记录实时的测试结果，而不是测试之后或之
前；
对于关键的测试步骤， 需要保留例如截屏等测试证据，来支
持说明相应的结果 （标签、记录的次数、 签字 &日期）；
记录结论 (“通过” 或者 “失败”), 并不是随便的勾号记录和交叉
的参考
计算机和手动计算结果是一样的；
有的测试项目尤其是关键测试步骤没有预期的结果；
验证仅由软件结果和手动计算结果相比较而组成…而不
是有没有超限；
没有进行比如分母是0、不恰当的负数、可接受范围之
外的数值等的错误测试 ；
并没有进行无效数据、特殊情况(比如0)或者边界值的
测试。
被用来…
依据测试计划来分析总结所有的测试结果
总结每个阶段的测试
授权下一阶段测试的开始
总结了
测试的执行情况和任何重复的测试
任何失败了的测试
所有的测试偏差，并提供说明
确认系统在真实的操作环境下的运行；
它是典型的商业流程性能确认（IT系统）或者工
艺验证（生产设备）的一部分；
分析仪器可以以系统适应性测试，常规检验等形
式来进行性能确认；
完成性能确认报告。
• 数据录入和数据转移计划
• 标准操作规程 (SOPs)
•
方法...
系统权限
备份和恢复
数据保存和恢复
灾难恢复
• 关闭所有的变更
服务协议
验证报告
总结了所有的验证活动；
总结了偏差和任何没有在计划中的验证活
动；
结论；
验证的系统和所有相关的文件必须在变更控制
和周期性回顾下进行维护，以维持系统的验证
状态。
需要执行以下的流程:
变更控制
文件管理
周期性的法规符合性回顾和再验证
评估控制/逻辑和物理安全性
培训
备份/保存和恢复
报废的目的就是保证有计划按顺序的将系统从
GMP区域移除
在报废时需要考虑：
不再需要的标准操作规程的移除
关于数据转移等数据保存
保证在合适的保存期间内数据可以被查到的方
法
任何可证明保存的数据是安全的，可查到的等测
试方法