药学学报  2015, Vol. 50 Issue (11): 1380-1387   PDF    
引用本文
YAN Charles, CHEN Feng, XIA Jia-lai, ZHENG Qing-shan, LIU Daniel. Computerized system validation of clinical researches[J]. Acta Pharm Sin, 2015, 50(11): 1380-1387.  
颜崇超, 陈峰, 夏结来, 郑青山, 刘川. 临床试验中计算机化系统的验证[J]. 药学学报, 2015, 50(11): 1380-1387.  
临床试验中计算机化系统的验证
颜崇超 , 陈峰, 夏结来, 郑青山, 刘川    
中国临床试验数据管理学组
收稿日期: 2015-10-10; 修回日期: 2015-10-20.
* 通讯作者: yancc@shhrp.com
摘要: 验证就是一个文件记录的过程, 是要高度证明计算机系统在其整个系统生命周期中, 能在受控状态下正确而始终如一地执行其设计功能的要求。根据监管要求验证过程始于系统设计/用户要求阶段, 延续至使用和维护, 直至最终退役和电子记录的保存。这样做的目的是确保每个信息技术应用程序都能达到其预期的功能目的。临床研究中的计算机系统的验证是GCP的要求, 以满足相关产品预设的质量、安全以及可追溯性的要求。本文描述企业如何按照验证标准操作规程 (SOP), 确定相关责任人, 执行验证的工作。验证过程中的特定工作可以外包, 但是系统验证的最终责任人始终是业务过程的所有者, 即申办者。为了提供证据证明系统已经并继续处于已验证状态, 必须建立详细的验证程序, 并提供适当的培训以及足够的文件。验证过程的质量也需要经质量控制 (QC) 与质量保证 (QA) 加以维护。
关键词: 计算机化系统     验证     临床研究    
Computerized system validation of clinical researches
YAN Charles , CHEN Feng, XIA Jia-lai, ZHENG Qing-shan, LIU Daniel    
On Behalf of Clinical Trial Data Management Working Group of China
Abstract: Validation is a documented process that provides a high degree of assurance. The computer system does exactly and consistently what it is designed to do in a controlled manner throughout the life. The validation process begins with the system proposal/requirements definition, and continues application and maintenance until system retirement and retention of the e-records based on regulatory rules. The objective to do so is to clearly specify that each application of information technology fulfills its purpose. The computer system validation (CSV) is essential in clinical studies according to the GCP standard, meeting product's pre-determined attributes of the specifications, quality, safety and traceability. This paper describes how to perform the validation process and determine relevant stakeholders within an organization in the light of validation SOPs. Although a specific accountability in the implementation of the validation process might be outsourced, the ultimate responsibility of the CSV remains on the shoulder of the business process owner-sponsor. In order to show that the compliance of the system validation has been properly attained, it is essential to set up comprehensive validation procedures and maintain adequate documentations as well as training records. Quality of the system validation should be controlled using both QC and QA means.
Key words: computerized system     validation     clinical research    

计算机化系统已广泛应用于临床试验的各个阶段,但如何证明计算机化系统的稳定性、可靠性和安全性已成为至关重要的问题。验证过程就是以文件化的证据来证实一个计算机化系统符合技术规范、达到了设计要求并满足用户需求。系统验证不是静态的,它贯穿于系统的整个生命周期。

医药产品的有效性和安全性依赖于数据的质量及其真实完整性。所以,任何系统如果产生的数据与医药工业的GLP、GCP和GMP有关,这个系统就必须经过验证。基于这个原则,所有临床试验中所使用的计算机化系统,如随机分组系统、数据管理系统、数据采集 (EDC) 系统等,在使用前都必须得到验证。

本文是在参考国内外相关监管部门和行业协会对系统验证的要求与规范[1, 2, 3, 4, 5, 6]的基础上,结合我国的具体实践撰写的,旨在为系统开发者和系统用户提供参考。

1 概述 1.1 验证的目的与意义

计算机化系统验证的目的是对计算机化系统的用户需求及其设计规格、安装、运行、性能的正确性以及对生产的适用性等进行全面的测试和确认,以证实该计算机化系统达到设计要求、技术指标以及用户要求。

通过计算机化系统的验证,可确保系统在其整个生命周期中的质量保证得以建立,并始终处于可控制状态下。计算机化系统验证既是企业自身风险管理的要求,也是法规的要求、行业规范的要求以及标准业务流程的要求[5, 6]。

1.2 验证责任人

临床试验项目中,系统验证的责任人是使用该系统的责任人,如申办者开展临床试验使用EDC系统,申办者可将EDC验证或EDC系统的运行与维护等外包给EDC服务商或有资质的第三方,但申办者不能外包对系统验证的责任,也就是说,该EDC系统用于临床试验项目的验证责任人就是申办者。同时,系统的使用责任人需加强对系统开发商的稽查,确保其产品开发的过程与质量符合监管部门的要求。

1.3 参与验证的人员与责任

参与验证的人员必须具有相应的知识背景与验证的工作经历,并获得足够的培训,足以胜任在验证中所担任的角色。在执行验证过程中,相关人员应严格遵守验证的标准操作规范,以保证验证的质量。

1.4 验证的方法

系统验证有多种方法,本文以目前国际上较为公认的V模型作为验证基础,介绍软件开发与测试的基本过程及其验证要求。V模型的特点是根据不同类型的软件,建立系统在测试各阶段的相应要求,以及开发阶段与测试阶段间的对应关系[5, 6] (图 1)。

图 1 计算机化系统验证的V模型
1.5 验证文件

验证文件是验证过程中产生的证明系统稳定性和可靠性的最直接的证据。验证文件既要能说明该系统符合监管部门相关法规的要求,亦能证实其达到了用户的功能需求,并呈现系统的稳定性、可靠性与安全性证据。

表 1是计算机化系统验证中各阶段的主要工作及其验证文件的描述[7, 8]。

表 1 计算机化系统验证各阶段工作和需交付的文件
1.6 系统清单

计算机化系统用户应编制一份所使用的系统清单 (system list),以便对系统的使用、状态与重要性等做出汇总[6]。系统清单应及时更新。

系统清单通常包括以下内容: 1系统名称和版本号; 2系统类型; 3系统所有者; 4系统使用的目的与范围 (如数据管理软件等); 5系统的重要性(如对产品质量的影响、是否需要遵守法规以及业务要求等); 6验证状态; 7验证日期 (实际日期或计划日期); 8开发类别 (如商用软件、或用户自主开发软件); 9软件类别与软件分类; 10是否满足电子记录和电子签名; 11计划下一次验证的时间等。

2 验证过程 2.1 验证的标准操作规范

验证工作必须遵守标准操作规范 (SOP),使得系统的开发、测试、实施、操作、维护以及下线等活动都满足监管部门的要求[7]。SOP应重点涉及以下内容: 1验证文档的管理与要求; 2软件的开发与测 试; 3系统的安装与调试; 4用户验收测试(UAT); 5培训; 6系统的安全性设置; 7系统的使用与维 护; 8用户支持; 9系统缺陷(bug) 的管理与追踪; 10系统的备份与恢复; 11业务持续计划; 12系统变 更管理; 13定期审查; 14系统下线; 15存档与恢复(retrieval); 16稽查与审查。

此外,SOP应当明确描述验证的工作范围与任务,验证人员的责任以及详细的工作流程。SOP的格式、内容、版本控制、签署以及发布应有明确规定。在SOP正式使用前,相关人员必须有相应的培训。

2.2 验证步骤

从项目的角度看,验证过程是由多项工作组成的项目。因此,这些工作的文件就构成了验证是否完成的最直接的证据。图 2是计算机化系统验证的主要过程的流程图。

图 2 计算机化系统验证的主要过程
2.2.1 验证工作的基本步骤

验证工作的基本步骤包括: 1识别计算机化系统验证所要遵守的标准与规范; 2识别所要验证的系统 (由1.6项系统清单中获得); 3指定验证的相关人员(如系统所有者、项目经理、验证经理、测试员等); 4明确用户需求; 5制定验证策略: 风险分析,系统组成、分类,内部开发的评估; 6制定验证计划; 7系统规格的审查与批准; 8建立测试计划; 9测试; 10验证报告; 11系统验证通过和批准报告,以及系统发布; 12运行期间的系统维护,定期审查与变更控制; 13系统下线。

验证工作必须在独立的验证环境中进行,以免破坏正式运行环境的使用与验证状态。临床试验中,未经验证的系统不得进入正式运行环境。

2.2.2 验证计划

在验证开始前,需要按照验证SOP的规定,依据风险评估的结果,在验证计划中明确规定验证的过程、责任、工作以及需提交的验证文件。

不同来源的系统 (如用户自行开发的系统,或市场购买的开发商的产品,或租用的系统等),可使用不同的验证策略。验证的相关工作可以由系统开发商、系统的使用责任人或其委托的第三方负责,但均应满足系统验证的所有要求。系统开发商在验证中的作用需在验证计划中明确规定。

作为验证的最终责任人,系统使用的责任人必须确保其验证的质量符合要求。

2.2.3 开发商的作用

系统开发商除了要保证其开发软件的质量外,在用户的验证过程中,开发商也可承担相应的角色与责任。开发商的验证文件可作为验证文件的一部分,但必须满足用户验证的要求,并有义务接受用户或用户委托的专业人员的稽查。

系统用户与开发商各自在验证中的责任应当在合同中有明确的规定。

开发商提供的系统,在特定的法律协议规定下或在特定的条件下 (如开发商破产),申办者应当可以获得开发商交于第三方保存的源代码及相关文件。

开发商的验证文件可作为用户验证文件的一部分,如: ① 软件开发人员的管理; ② 软件开发的生命周期文件; ③ 代码/编码/程序的标准; ④ 文档管理; ⑤ 系统设置管理; ⑥ 用户手册; ⑦ 系统发布声明; ⑧ 用户支持; ⑨ 系统变更管理等。

2.3 系统功能及其整合测试

验证中的测试主要包括: 功能单元模块测试 (如功能测试与构架测试) 和整合测试。其具体内容有:

(1) 安装确认 (installation qualification,IQ)。核实电子系统的单元装配正确无误或符合设计细则要求;

(2) 运行确认 (operational qualification,OQ)。系统的单个组件或者整个系统的功能测试,比较系统的功能是否与功能规格中的要求相一致。运行确认主要是通过单纯的功能测试,以考察系统的基本运行功能,包括可重复性、耐用性和可靠性,以及功能是否符合设计时的功能规格;

(3) 性能确认 (performance qualification,PQ)。即系统功能的总体测试,是系统验证测试的最后一步。它是系统在规定的运行条件下运行时,按照系统操作流程,对其性能表现予以确认,证明系统功能、操作条件、人员以及作业环境等的耐用性和可靠性,以核实系统对于用户需求的满足程度。

系统功能及其整合测试主要是通过测试计划中规定的测试脚本 (亦称测试用例) 的运行来实现的。测试的级别(如测试的范围与程度)将基于风险分析中确定的风险等级,即依据风险评估的结果来确定测试内容。

测试脚本的建立主要基于用户需求、功能规格和业务流程对系统的要求。测试脚本应当包括测试条件、测试数据和预期结果。测试中实际获得的观测结果可以与预期结果进行比较,以判断系统的性能是否满足用户的需求。

测试报告应尽可能的详尽,以便重现整个测试过程。测试中发现的缺陷,需经风险评估,以确定是否需要处理。重大的缺陷都必须得到改正和解决,并通过再次验证。

2.4 可追踪矩阵

可追踪矩阵 (traceability matrix) 是将用户需求、功能规范、设计要求、风险评估以及测试脚本等联系起来的一个验证文件。它是计算机化系统稽查的必需文件。可追踪矩阵用以证明用户需求在系统开发与验证过程中所实施的解决方法都已得到满足并获得足够的测试。可追溯矩阵的示意表见表 2。

表 2 可追溯矩阵示意。 GxP是GLP、GCP与GMP的总称; 数字代码为相应文档中的序号

编写可追踪矩阵时应该注意以下几点:

(1) 可追踪矩阵的起点是用户需求,所以,用户需求的准确性决定测试的可操作性。用户需求要便于测试,并避免重复以及相互矛盾等;

(2) 对用户需求进行编号,并在可追踪矩阵中填写用户需求的编号以及简单的描述;

(3) 可追踪矩阵中的其他各栏也以各自的编号填入,可追踪矩阵表要简洁、清晰;

(4) 对GxP的影响和对业务的影响这两栏,可以根据系统的实际情况取舍;

(5) 验证过程中,可追踪矩阵需及时更新,如当功能规格等变更时,相应的内容要填入可追踪矩阵;

(6) 可追踪矩阵完成之后,与之相关联的各种文件可能会有更新,如版本号的改变,建议编写更新后的文件名、文件编号以及修订编号的一览表。

2.5 测试报告与验证总结报告

验证测试报告是对各测试结果的总结。测试报 告应当包括测试所涵盖的内容总结、所发现的问题 或异常总结、系统或测试所带来的变更总结、仍然存在的问题总结,并作出系统是否可进入下一阶段测试的结论。测试报告中还应对测试中发现的问题作 风险评估。

验证测试报告还应当描述在系统开发、测试、合格性检验、用户接收活动全过程中所采用的质量标准及其按照这些原则所开展的活动,并列出相关支持性文件作为参考。最终的验证报告必须论述验证计划和文件中规定的所有计划步骤,并需对验证计划执行中出现的活动、偏离和结果予以说明。系统在完成验证总结报告并获得批准与签署后,方可发布并进入正式运行环境。

图 3表示系统测试过程中的测试报告以及测试总结报告的关系。

图 3 系统测试的步骤与各阶段的测试报告、测试总结报告的关系
2.6 回顾性验证

前瞻性验证是指系统在上线使用前所进行的验证,以确保系统的功能满足用户的需求。回顾性验证则是指当前使用的系统未经过验证或未经完整的验证,也无法提供完整有效的验证文件,此时,如果该系统需要继续使用,所应采取的验证方法。在我国新版GCP的要求下,临床试验系统应当避免使用回顾性验证。

回顾性验证应对系统及其相关验证文件进行重新评估,以发现系统的缺陷并予以记录。回顾性验证需补充完整的系统验证文件,如在系统升级时,用户可以通过对业已发现的缺陷,按照风险评估的结果开展验证,以完成所有验证工作。回顾性验证的计划与新系统的验证计划相同,也需得到审查与批准。只有当系统满足验证计划的所有要求后,系统才可以继续使用,并始终维护其验证状态,直到系统下线。

3 验证状态的维护

已验证的系统在使用过程中会受到各种已知或未知风险的影响而出现异常。因此,为减少这些风险,应当建立相应的应急预案和详细的处置流程,其中包括系统的安全性管理、运营管理、变更控制管理、定期审查、以及工作持续性计划等,以确保系统始终处于验证状态。这些流程应当处于用户的直接管理下。如果维护工作由系统开发商或者是第三方负责,相应的服务级别协议 (SLA) 则应当明确规定其内容与范围。

3.1 运营管理

通过验证的系统投入日常的运营和服务时,必须采取有效的措施以确保系统的运行和性能的正常与稳定。系统的运营管理应当贯穿于系统整个运行阶段,并满足以下操作要求: ① 系统的日常维护管理,确保系统的性能得到有效监控并保证系统正常使用; ② 系统的突发事件管理,确保系统发生的各种问题被正确记录并得到追踪和解决; ③ 纠正与预防措施 (CAPA),确保发现的系统问题得到根本性纠正,避免再次发生; ④ 数据定期备份与恢复,避免系统崩溃后原始数据的完整性和可用性受到损失; ⑤ 用户培训,确保所有的系统用户得到与其系统权限相对应的培训; ⑥ 用户支持,确保用户反馈的各种问题得到有效解决,并提供相应技术支持; ⑦ 系统相关文件的保存与归档,确保文件免受各种自然或非自然因素的损毁。

3.2 安全性管理

计算机化系统与数据的安全应当得到充分的保护,以免数据丢失、破坏或非授权的变更。系统的安全性需要至少从三个方面加以考虑,即网络或局域网监控、系统或运用程序的操作监控和个人电脑的 使用监控。因此,应当执行以下的措施: ① 制定系 统保密与安全管理策略和规程; ② 用户的权限管理与访问权限的审批; ③ 密码的命名规则与密码的定期更改; ④ 电子签名的管理与控制; ⑤ 系统的安全监控及定期审核; ⑥ 及时纠正已发现的安全漏洞或突发事件; ⑦ 数据的电子化传输的安全性; ⑧ 系统数据的备份与安全保存; ⑨ 系统数据库的保安措施和监控。

3.3 变更管理

变更管理是维持系统始终处于验证状态的一个重要步骤,目的是防止不必要的变更,并确保所有的变更都得到识别、授权、核实与确认,以达到系统提供的服务免受不必要的干扰,确保资源的有效利用。变更控制的基本要求包括: ① 系统变更的可追溯性; ② 人员职责的归属性; ③ 变更和维护的明确性; ④ 变更文件的可控性; ⑤ 变更流程的质控。

3.3.1 计划变更的类型

计划变更是已验证系统的最常见的和最主要的维护形式。在计划变更操作中,应当对系统已验证状态的各个方面影响进行逐一评估与描述。常见的变 更内容包括: ① 缺陷的修正; ② 安装补丁程序; ③ 安装额外的硬件或软件; ④ 版本的全面升级; ⑤ 修改应用程序配置; ⑥ 系统使用的变化。

3.3.2 变更控制的流程

变更的过程要遵守用户的相关流程,并在不同阶段实施评估与审批。变更的过程一般包括: 申请变更,审批变更,制订变更计划,实施变更开发、测试与验证,发布变更,以及变更的总结与关闭。

变更过程也是系统再验证的过程,其要求也和系统初次验证的要求相同,也需要遵守验证的SOP,并提交一系列与初次验证相对应的变更文件,包括相应的文档版本号以及发布或执行的日期等,并最终签署变更完成表。变更结束后,所有的变更文件均需归档。

同时,要根据变更的内容与性质对用户进行必要的培训、对涉及的业务流程以及SOP等进行同步更新 (如果涉及)。

3.4 定期审查

定期审查是指在规定时间内,对已验证系统的性能、表现和变更历史等作全面的审查,其目的是了解系统是否仍处于已验证状态。定期审查是维护系统的已验证状态的关键步骤。

3.4.1 定期审查的人员与内容

系统在运行期间可能会发生多种影响系统验证状态的事件。定期审查的主要内容包括: ① 系统本身是否发生了变化; ② 用户使用过程是否发生过变化或错误; ③ 系统功能是否有偏差; ④ 使用中是否发生过系统安全事件,如网络病毒等。

此外,审查期间还需对变更的历史等做回顾性总结,包括: ① 审查期内一共进行了多少次的变更; ② 有多少次是主要变更,多少次是紧急变更; ③ 这些变更是否涉及系统的重新验证,以及重新验证的日期。

定期审查的时间间隔需在验证总结报告中作明确的规定,一般是一年一次。参与定期审查的人员包括系统验证人员、质量保证人员、IT人员以及系统用户等。

3.4.2 定期审查的结果与报告

定期审查工作的结果是生成定期审查报告。报告中,首先是对系统及其验证信息作基本的确认,包括系统版本号、系统所有人、验证团队人员等。此外,定期审查报告中也要对系统进入正式运行环境后的系统变化与系统表现逐一进行评估,其中主要包括: ① 系统硬件有无变化或更新; ② 系统软件有无变化、升级或更新; ③ 系统的程序有无变化; ④ 系统的使用与业务流程有无变化; ⑤ 系统的安全性有无缺陷; ⑥ 系统有无“被动”关机,系统的重启或备份是否正常; ⑦ 是否实施系统修正程序; ⑧ 归档程序是否正常; ⑨ 系统有无重大的事件,包括重大的缺陷、在正常使用期间的系统瘫痪、以及其他重要的问题使得系统的工作无法完成。

报告还要对所发现的偏差与问题做风险评估,并采取纠正措施。

依据本次定期审查的结果,报告以定期审查的形式,对系统是否依然处于验证状态作出确认,为系统的继续使用提供文件性证据。

3.5 业务持续计划与灾难恢复计划

业务持续计划强调的是系统在应用过程中出现服务中断时,如何继续业务流程的方案。灾难恢复计划则是当灾难发生后,采取的使系统尽快恢复运行的一系列措施。它们都是确保当系统或其数据在受到破坏时所遭受的损失最小,或在数据恢复后其数据的完整性得以维护。例如,当某个系统文件被意外删除后,其最近一个备份文件可以及时替代。另一个极端的例子是当系统机房火灾时,其异地备份的数据依然可以及时获取。因此,应当重视以下的关键点: ① 制定硬件或软件更换的最低技术指标要求,以及时间窗口要求; ② 替代系统/流程的实施; ③ 系统恢复后再验证的步骤,以达到所需的使用标准; ④ 数据恢复的步骤与流程,以达到数据的及时恢复; ⑤ 明确列出各系统的关键联系人及其详细联系方式。

上述流程应当定期测试,相关人员应及时了解流程的变化,流程记录文件应及时存档。

4 验证的质量管理

计算机化系统验证的质量管理涉及到人员、系统、流程/步骤、工具以及技术,其目的就是确保系统达到并始终处于验证状态。质量管理的主要活动包括质量控制与质量保证。

4.1 质量控制

质量控制是验证过程各阶段中所进行的一系列日常工作,这些工作能够发现验证工作中的问题,如软件、硬件、人员以及流程,以保证验证工作的质量。验证过程中常见的QC工作主要有: ① 定期检查用户的问题记录表; ② 定期检查用户的权限; ③ 检查工作流程; ④ 检查系统的功能与表现; ⑤ 检查定期审查报告。

4.2 质量保证

质量保证是由质量管理部门根据监管部门的要求,按照计划、系统规程、质量标准及其业务流程对开发商、用户或服务商进行的稽查,以确保验证系统的质量。它是独立于验证质量控制的评价体系,并对未达到标准的工作采取纠正与预防措施 (CAPA)。

稽查主要关注的是系统的开发与实施过程是否达到了验证状态,以及是否维持在验证状态。稽查应针对所有遵守GxP的计算机化系统,如内部开发系统,或外部 (如市场购买的,以及CRO或临床研究单位使用) 的系统。

4.2.1 对内部系统的稽查

主要针对本机构自主开发的系统,确保系统的开发过程按照监管要求、业界规范和本机构的SOP标准进行。

4.2.2 对外部系统的稽查

稽查人员应确保外部机构的质量管理体系达到业界的标准 (如人员的培训与文档的管理)。稽查中发现的任何问题都应当进行风险评估。

4.2.2.1 CRO稽查

与CRO签署业务合同时,申办者必须明确对CRO的具体责任要求。如果CRO的计算机化系统涉及到业务合同的具体业务,稽查应当关注以下几点:

① 明确CRO所要提供服务的具体内容,以及所使用的SOP; ② 评估使用CRO计算机化系统可能面临的风险,提供避险的措施与方案; ③ 检查CRO的SOP遵守以及执行记录的文件、CRO的质量管理系统、CRO提供服务的计算机化系统的验证状态与验证文件、服务协议中系统的维护与仪器的标定; ④ 撰写稽查报告,阐述发现的问题; ⑤ 后续检查整改工作及安排的后续稽查; ⑥ 合同期内的定期稽查。

4.2.2.2 开发商稽查

对系统开发商的稽查,应关注以下内容:

(1) 关注系统的关键步骤与过程,如软件的开发过程,系统的安装,操作环境与用户培训等。

(2) 核查验证文件并评估系统的可能风险,如系统的设计规格,测试计划,测试结果,测试报告以及批准文件等。

(3) 稽查的主要内容包括: ① 软件开发标准规范; ② 软件开发质量管理系统文档,如系统的可追踪矩阵列表等; ③ 软件验证的文件; ④ 软件发布的策略; ⑤ 软件缺陷的信息记录与处理; ⑥ 开发商人员的培训记录; ⑦ 开发商提供的系统培训; ⑧ 开发商提供的系统管理手册和系统用户手册; ⑨ 源程序编码(在特定情况下); ⑩系统的维护,系统升级的变更控制,以及技术支持; 11最近接受稽查的稽查报告。

(4) 撰写稽查总结报告,阐述系统的验证状态,并指出发现的问题。

(5) 后续检查整改工作以及安排后续稽查。

(6) 进行合同期内的定期稽查以保证系统验证状态的维护。

4.2.2.3 研究机构的稽查

当申办者提供计算机化系统给临床研究机构使用时,对于机构的稽查主要包括: ① 系统的安全性; ② 系统用户的培训; ③ 系统的正确使用; ④ 系统的维护。

5 名词解释 5.1 临床试验计算机化系统(computerized system)

临床试验计算机化系统指的是在临床试验项目中使用的由计算机硬件、软件、运行环境以及操作人员和操作管理程序等组成的体系,其中包括临床试验的项目管理,以及临床试验数据的采集、整理、分析和报告等。

5.2 计算机化系统验证(computerized system validation)

计算机化系统验证是建立一套文件化的证据,以提供一个高水准的保证体系,证明该系统满足其设计的各种要求,确保该系统生产出的产品始终达到预定的标准和质量要求。

具体来说,计算机化系统验证是用记录的文件为证据,证明系统的开发,实施,操作以及维护等都处于监控的质量管理规程中,且贯穿于从系统开发到系统退役的整个生命周期 (SLC)。

5.3 计算机化系统的生命周期(computerized system life cycle)

计算机化系统的生命周期是指从系统开发到系统退役的整个过程,主要包括系统建立的启动,系统需求,系统设计,系统开发,系统配置,系统测试,系统验收,系统运营,系统维护以及系统下线 (其中包括系统数据的存档) 等。

5.4 国际制药工程协会(ISPE)

是全球制药行业者的交流平台,它提供涵盖制药领域如药品、医疗器械的生产等与健康管理有关的实用信息。

5.5 稽查轨迹(audit trail)

是监管机构对系统 (如数据管理系统) 的基本功能要求,是系统采用安全的、由计算机化系统产生的带有时间信息的稽查记录,用以独立标示系统用户的数据输入、修改或删除的电子数据及其记录的日期、时间和修改原因,以便日后数据的重现。稽查轨迹要求任何记录的改变都不会掩盖过往该数据的历史。稽查轨迹文档记录应当始终保留,并可供监管视察或稽查员的审阅。

5.6 用户验收测试(user acceptance test,UAT)

又称用户可接受测试,是计算机化系统开发生命周期中的一个阶段。由终端用户对照用户需求和功能规格在实际运营环境中对系统进行的正式测试,以确定所有系统的用户需求、设计标准和功能规格 是否达到设计要求和系统是否可投入运行使用。它 是一项确定产品是否能够满足合同或用户需求的测试活动。

5.7 变更控制(change control)

是一套用来管理计算机化系统硬件、软件、人员以及流程等变化的规程。

5.8 服务级别协议(service level agreement,SLA)

描述和定义计算机化系统服务商和系统用户之间服务供求关系的正式文件。

参考文献
[1] ICH E6. Harmonized Tripartite Guideline for Good Clinical Practice [S]. 1996.
[2] FDA. Computerized Systems Used in Clinical Trials [S]. 1999.
[3] FDA. General Principles of Software Validation [S]. 2002.
[4] FDA. Electronic Records; Electronic Signatures-Part 11, Scope and Application [S]. 2003.
[5] DIA. Computerized system in clinical research: current data quality and data integrity concept [M]. 2012.
[6] ISPE. Good Automated Manufacturing Practice 5 (GAMP5) [M]. 2008.
[7] ACDM. Computer system Validation in Clinical Research, A Practical Guide [M]. 1997.
[8] Yan CC. Data Management in Clinical Research (医药临床研究中的数据管理) [M]. Beijing: Science Press, 2011: 329-399.