计算机化系统验证总结.docx

计算机化系统验证
——风险评估
1.前言
上一篇文章发出去之后，有位前辈帮我指出了一个比拟大的问题：“计算机化系统，在 此先给大家道个歉，由于自己疏忽没有用正确的文字去描述，在此更正。
开始前，我本来想自己解释下关于“计算机系统”与“计算机化系统”的概念或者区别，后 来百度之后发现另一个前辈解释的更好，在此我就引用这位前辈的解释了（如果涉及到相关 版权问题，我将尽快删除这段解释
PIC/S中关于“计算机系统”的定义是：软件与硬件的组合，实现特定的功能。
“A group of hardware components and associated software, designed and assembled to perform a specific function or group of functions."PIC/S中有另外的对于“计算机化系统”的定义是：通过计算机系统实现、与计算机系统集成的一系列 的流程或者操作。“计算机化系统”的关键词在于前半句"Process or operation"。
“A process or operation integrated with a computer system.H谈到“计算机化系统”♦实际包括的不仅是物理存在的系统本身♦也包括与系统所支持的流程与操 作。现在很多的企业在做“计算机化系统”验证的时候，更多侧重的往往是工程阶段的系统实施，侧 重的是对“计算机系统”本身的功能需求与功能测试，当然这不能说做得不对，但确实是做得不 够。
以笔者的感觉而言，很少有企业能够理解计算机系统运行、维护阶段的要求也是验证的一局部；很 少有企业能够清楚讲清楚系统究竟如何支持业务流程，产生哪些数据，这些数据应该如何保存，如 何销毁：很少有企业能够真正管理好计算机化系统，保持其验证状态.....运维阶段对于“计算机 化系统”而言其实往往比工程阶段的系统实施更为重要。
之前写了一篇关于计算机化系统（更正后）验证的概述的文章，写确实实很粗，当时因 为篇幅有限，无法完成整个计算机化系统验证的相关知识点的总结。接下来我会用N个“文 解释的是这只能算是电子签名的一种美化（前提是电子签名功能必须完整）。
完整的电子签名要求包括有（参考中华人民共和国电子签名法[2015]1）电子签名属于签名人专有，也就是说电子签名所属人必须妥善保管，并且当认为电 子签名数据失效后应及时告知有关放，并且终止使用该电子签名。。
2）签名时，其操作仅可由所属人控制，也就是说不能带签。
3）签名完成后，对电子签名的任何改动都能够被发现，也就是说系统必须有自动校验 功能。
4）对于签名后的数据或文件的改动，都能够被系统侦测到并明显提醒。
对于签名的形式，可以是任意的。哪怕是系统宋体的签名也是可以认可的。但对系统的电 子签名功能有了很高的要求。微软的电子签名认证做的就很完善。
6.总结
URS在编写过程中，本身即必须符合相关法规要求，同时应根据企业自身的条件而进 行优化，生搬硬抄的URS只会将企业限于更深的泥潭。主要表现在计算机化系统上线运行 后带来的管理本钱的提高，甚至无法做到其符合规范的管理。
对手明显存在高风险的需求，应当严格控制，尽管对软件系统供应商来说实现起来可能很 简单。比方原始数据的复制功能，其需求已经偏离了原始二字。
本来还想把数据可靠性的相关需求也加入到这篇文章中来，后来想想还是后续单独列出 来整理吧。
计算机化系统验证——验证计划
1 .前言
验证计划属于规划阶段的最关键的一节，其合理性、完整性决定了后续验证工作开展的顺 利程度。之前还见过一个版本的“验证计划”：甘特图，其实就是个任务时间安排，关键是安 排的还不是很合理。此“验证计划”就不能称之为验证计划了。
我认为合理的、完整的验证计划，至少应包含“做什么”、“谁去做”、“什么时候做”以及 “完成后的成果”。
2 .验证计划概述关键字：验证计划概述
在第一篇计算机话系统验证的那篇文章中，我把验证当做一个工程来看到，那验证计划 就等同于工程计划了。其包含的内容主要有：概述、相关规定、验证人员组织、任务时间安排、 培训管理计划、偏差管理计划、变更管理计划、报告管理计划、相关术语以及附录。
概述

图1验证计划框图
概述：主要用于该验证工程的整体描述，包括目的、范围、工程背景等。
相关规定：主要用于对该验证活动的一些特别说明。如假设供应商无法提供源代码时，从 而导致无法进行源代码审核，此时应说明由供应商提供相关质量保证文件。
验证人员组织：用于明确验证相关人员及组织架构。一般验证团队由供应商（或第三方 验证人员）、企业相关验证人员组成，并且应明确说明各个组织的相关职责。对于源代码审 核或设计审核企业用户无法完成时，应由第三方组织进行，或由企业提供相关质量保证证明。任
务时间安排：应明确验证任务以及任务时间安排、人员安排，任务分解至最小单元。
假设不能提供具体的人员安排，那么应明确在后续哪个文件中详细安排。如IQ人员安排此处假设 不能提供详细人员名单，那么必须在IQ方案中提供具体的人员名单。对于0Q和PQ的时间 安排，应结合软件系统的特性进行。0Q和PQ可以同步进行，也可以0Q完成之后进行 PQ0主要取决于软件系统的各个模块之间的强关联性。
培训管理计划：主要是对各个相关验证人员的培训安排，以确保后续相关活动的合规性。 如IQ、OQ、PQ进行前必须对相关人员进行培训，并形成培训记录，必要时可进行相关考 核。如IQ中相关软件的安装过程。
偏差管理计划：主要用来对验证过程中发生的偏差进行处理。对于一个计算机化系统中 的软件局部，不可能不发生偏差。
变更管理计划：主要是用来对于一些需求上的变更的管理。比方由于各种技术或法规的 要求，之前的URS中提及的某些功能已经无法满足需求或者有更好的技术实现，那么可以通 过变更管理计划完成。
报告管理计划：主要是用来记录或报告相关活动的成果，该管理计划中应说明什么报告 应经过什么样权限的人员去审核、去批准，并且对于发现问题的报告应如何处理等。报告应以 文档形式保存，且报告中相关记录应在验证过的系统中保存原始痕迹。
相关术语及附录：主要是用来说明相关缩写、名词介绍等。附录中可以明确验证过程中 使用的一些模板、流程等。如果验证计划有相关附件，也需增加相关附件说明。
3 .验证计划目录样例
如下列图示验证计划目录样例:
HEADINGS PAGES RESULTS1目的 2范围
3相关规定4组安架构及职责
/ 5参考文件5.1标准操作规程
» 6系统概述/ 7验证流程
7.1 验证藻程图任务时间安排
7.2 交付文档列表8责量管理计划
/ 9偏差/变更管理计划92偏差管理计划
93变更管理计划10报告管理计划
/ 11培训管理计划11.1供应商培训计划
112企业培训计划12预防性维护计划
13验证时间表14相关术语
图2验证计划目录结构样例
4.写在最后
在写章节3的时候，我一直想把我之前整理过的完整的验证计划文档粘贴进来，但总是出 现各种排版错误，后来想了想待后续一起打包发给大家吧。
这篇文章写到最后的时候，回头来看，过于简单了，本不想拿出来整理，后来想了想就当 自己总结吧。如果对您能有所帮助，也算是对我一点抚慰吧。
计算机化系统验证——供应商审计
1 .前言
关于供应商审计这块，咱们制药企业在做原物料供应商审计的时候做的已经非常好 了，但对于计算机化系统的供应商审计在我接触过的企业中，是比拟薄弱的，仍然采用之前 的方式进行相关审计，得来的结果只能是高风险的供应商。
那么如何规避此项风险，我们可以换个角度来思考，对于计算机化系统的供应商审 计，至少应从其供应商企业本身的质量管理抓起，通过各级审查从而得出其相对合格的供 应商。而对于软件系统代理商（其风险等同原物料的代理商）其要求就更严格了。因为其代 理权限的到期或者被收回，很可能就意味着其技术服务的中止。
2 .供应商审计概述关键字：供应商审计概述
抛开原物料供应商的审计过程，我们在此只谈关于计算机化系统的供应商的审计。在描述 审计过程之前，我们先看下GAMP5中关于供应商的规范化活动，这块GAMP5花了一个大 的章节包含14个小节来说明，从供应商的产品、应用及服务谈起，经过其质量管理、产品规 划、产品设计、编码开发、系统测试、产品发布、用户文档、技术支持到系统的退役全过程进行 详细的规范化管理说明。具体参见Supplier Activities 7 Sec GAMP5。
从其活动过程来看，GAMP5实际上在供应商建立：计算机化系统的全过程的活动中给出 了规范化的操作，也就是说供应商至少应按照这些活动来建立相关计算机化系统，才能保证其 系统满足相关法规的要求。那么企业在选择供应商时所进行的供应商审计即是围绕这些活动进行。 抛开供应商的财务状况、资质能力、企业合法性等，企业应当着重审计供应商的质量管理体系相 关文件，当然也存在无论是物料供应商还是计算机化系统供应商其有体系而不完全执行的风险。关于这个风险，按照GAMP5中的软件类别划分，如果是5类软件系统， 企业那么承当起监督的作用。而对于4类软件系统供应商那么审查其软件系统形成过程中的相 关产出物了。如软件系统设计/开发/测试过程产生的相关文档。
3 .供应商活动说明
无论是4类软件系统供应商还是5类软件系统供应商，其供应商活动都是一致的。对 于•个规范化的软件系统供应商，GAMP5给出了其规范化程序即良好实践。包含有建立 QMS、需求管理、质量计划管理、子供应商评估、产品规格、执行设计审核、软件开发/配 置、实施测试、系统的商业发布、提供的用户文档和培训、相关技术支持:、系统的更新换代与 退役。相关解释在GAMP5中有说明，在此我就不重复了。
1）建立QMS,供应商应提供一套标准化的程序已支持其后续的相关活动，同时应对 对相关人员进行培训，以确保参与系统建设活动的相关人员都明确。这套标准化的 程序建立应对符合供应商文件化程序的管理标准，包括后续的版本升级过程。这里 拥有CMMI 2级以上的供应商基本上都可以满足。
2）需求管理.，需求可以是用户提供（5类软件），也可以是供应商内部建立。标准化的 需求管理，最关犍的是表达在其跟踪、追溯方面的管理。
3）质量管理计划，供应商应建立相关质量管理系统，以保证其质量管理计划的执行。 至少应满足GAMP5给出的良好实践相关内容。
4）子供应商评估，供应商在产生相关的软件系统时，可•能会遇到与其子供应商合作的 情况，因此应当建立对子供应商的评估相关规程。
5）产品规格，对于产品开发，供应商应当建立系统的功能规格FS （包含软件功能规 格SFS、硬件功能规格HFS）、设计规格DS （包含软件设计规格SDS、硬件设计 规格（HDS）。功能规格主要明确软件、硬件将要做什么，而设计规格是基于功能规格 的，主要明确软件怎么做。
6）设计审核，供应商应对建立完善的设计审核制度，以确认产品的设计至少应对满足 其需求。同时建立用户需求跟踪矩阵，明确URS-FS-DS的对应关系，确保用户需 求已被完成相关设计。当然设计审核过程也包括了产品的设计的合理性、技术的先进 性等等。
7）软件开发/配置，供应商开发或配置团队根据相关设计文档进行编码开发或配置。
8）实施测试。供应商应对建立全面的测试计划，包括单元测试、集中测试、系统测试 以及白盒测试。测试过程应对涵盖所有FS。并且以文档化保存测试过程。
9）商业发布。供应商应对建立系统发布的相关规程，明确版本控制。发布时应对建立 与其对应的更新日志。如果是5类软件，还应对遵循应用企业的相关政策。
10） 用户文档和培训。供应商应建立完善的用户文档，包括操作文档、配置文档、
安装文档、培训文档等。
11） 供应商技术支持。供应商应当有完善的售后服务管理机制，以确保软件系统应用企业得到足够的技术支持。包括有变更管理计划、配置.管理计划、补丁管理计划、应急事 件管理计划、文件管理计划、备份还原计划、业务连续性计划、培训管理计划、系统 维护计划等。
12） 系统的退役或更新换代。供应商应对根据书面流程进行系统的退役及更新换代。这
里与微软的操作系统在退役或更新换代时所进行的相关流程类似。
以上，即是供应商在建立相关软件系统时所进行的活动。对•于供应商的测试过程文档是否可 以替代验证过程中的测试文档，应当根据软件类别（4类或5类）进行选择。对于4类软件， 由于其需求有可能是供应商自定义的，需求是否满足或局部满足相关法规要求而未知，因此无法完 全替代。而对于5类软件，由于系统建立过程是在企业与供应商共同参与下完成的，其验证过 程和供应商的软件系统建设过程同步进行，所以可以使用其测试过程文档代替验证过程的测试文 档，但需在验证计划中明确说明。
4 .供应商审计检查列表
了解了供应商的相关活动后，我们即可建立相关的供应商审计检查列表，通过对列表中的 条码一-确认，从而进行合格供应商的选择。如下是GAMP5的供应商审计检查列表（部 分），。
QUALITY SYSTEM Questions 度量体系魄
Answer
答案
Objective Evidence 客观证据
l.l. Quality system Framework 皮强体系的架构

1.1.1.Written Quality Commitment
书面的质呈承诺

1 l_l 1[)oes the supplier have a formal written
quality policy statement endlo w ed by senior management?
供皮商登否有正式的经禹级管理人员批准的质盅管理规 程？

1 1.12Is tie quality policy commurkated and
maintained throughout the organization (new & existing employees)?
质图管理W跷否在整系个统中培训(包括新的和现右的 员工)？

1 1.13Does the policy exp ess the object ves for
quality and commitmert to quality?
质受手册匣否表达质噩目桢版画？

1.1.2.Organiza Il ona 1 Stru cture (Roles and
Responsibili佃司组织架构(角色与责任)

1 12 1Is tie e a defined quality system?
是否有质量体系？

.总结
QUALITY SYSTEM Questions
皮量体系问题
Answe r
答案
Objii tive Evi dence 客观证据
11 .44Are meth ods in place to ensure that
changes to p ocedU esaie communicated to personnel responsible for performing the work?
在变要规程时，是否有规程规定变要后的规程需对相关 的人员进行培训？

1.1.5.Interna 1 Audits and Inspections 内部审
计和自检

1 1.5 1!Joes the quality system provide for
internal audits against quality system equirements? 质蛊体系^否根据质蛊要求自检？

11 .5 2(Jo internal audits address all areas of the
supplier's quality system?
自检是否七叶舌对所有供应商质量体系的审核？

1 1.5 3[Io audits verify c ompliance Io
procedure s?
亩计程序号否与规程一致？

1 154Are audits of th.equ ality system
pe iodically scheduled?
质董体系的审计牌否认期进行？

11 .5 5Do audits address the eft m： liveness of
the qualily system?
由计是否核实质量体系的有效性？

1 1.5 6Are devialio' s Io procedures and
P odUct standards idenified through aUd: s al'ld

关于供应商审计这块，我认为主要的还是我们要了解软件供应商的主题活动，即使没有 GAMP5提供的相关指导意见，我们也应当对我们选择的供应商的产品特性有所了解，从而才 能保证我们选择的供应商风险最低。
章”来具体说明，还是之前那句话，希望对新人有所帮助。
本篇我主要是想说明关于风险评估的一些关键知识点，当然这些也都是自己通过各种渠 道掌握或总结而来，如果有不对的地方还请大家指正。
同样的，还是围绕“为什么做，怎么做，谁去做，什么时候做”来一一阐述，希望大家在 读这篇文章的时候仍然按照这个逻辑去读。
2.风险评估概述关键字：风险评估概述
风险评估是在GAMP5中被加入进来的，而且是验证全过程进行风险评估及基于风险 评估进行决策，其目的和原因当然就很简单了，如果拿工程来说，是为了降低交付的产品、 服务或成果的产生的风险。在计算机化系统验证过程中，按照验证的V模型划分为规划、规范、 配置/开发、确认、报告等5个阶段，在每一个阶段都应进行相应的风险评估。而如果按照风 险过程划分的话，可划分为初步风险评估及决策、进一步风险评估及决策。
至于是否要做风险评估，大家认可的可能都是由质量部来决定。而这个由质量管理部“决定” 的依据是什么？是否有完整的方法？这本身就是一个风险。那要降低这个“决定”的风险，首 先我们要做的就是风险评估SOP,明确什么情况下要进行风险评估（相关的SOP我会在后 续整理出来）。在此基于我的理解，我举几个例子说明下什么情况下（不限于以下情况）应 该进行风险评估。
1）安装新的与产品质量相关（除无影响而外，如安装个打印机）的系统或设备；
2）现有系统或设备发生J'变化，如运行环境的改变；
3）与现有系统或设备相关的人员组织结构发生变化，如原技术服务商撤销；4）发生偏差后，调查结果发现系统处于非受控状态，或者相关操作规程无法防止事件 的再次发生.
5）……3 .风险评估
关键字：风险评估、方法计算机化系统验证
——数据可靠性.前言
前一段时间网上关于“数据可靠性”还是“数据完整性”讨论的异常热烈，好像每个人都 在不同的角度有不同的看法，一时间好像真的没法区分到底应该是可靠性还是完整性。在此我不 讨论关于他俩的区别或者谁对谁错，我也跟着国家机构用语而走使用数据可靠性。
无论是可靠性还是完整性，提出这个概念的人或组织其目的无非是为了保证数据的真实性、 平安性、可追溯性。说白了就是无论你怎么操作数据必须真实，数据保存或使用必须平安，同 时数据必须要能追溯。
1 .数据真实性关键字：数据真实
数据真实性从字面意思理解很简单了，就是数据要真实。那如何保证呢？最简单“粗暴”、最有效的做法就是企业或仪器供应商就不给你数据造假的可能！
从单机版的工作站到网络版的CDS,从不可操作的数据显示到可操作乂存储的设备单 元，从数据操作不受限到各种角色权限的控制，无•不是为了数据的真实性而努力。还记得某 个专家进入某家药企检查其带工作站的仪器，仅仅只是看了下工作站的操作权限控制后就开出了多个不符合项……
而今我们谈数据的真实性，无非就是想通过某一种手段从而确保任何人都不能进行数据 的非法修改。目前控制的无非如下几点：
1）工作站电脑的权限角色控制。企业建立相应的计算机使用管理规程，规定使用计算 机的用户管理、密码策略管理、权限管理（权限申请、分配、施放）、平安管理等。 有能力的企业甚至使用域管理，做到软件的各类操作管理等。这一点现在已经是必
查项了!
2）计算机软件系统用户、权限、角色控制、密码策略等管理。应用如第一条中的相关管 理规程，对应用系统相关进行设置，确保应用系统中的相关数据不能通过任一修改。 相关管理规程也是必查项！
3）通过相关的SOP、培训等提高企业用户的意识，做好相应的质量管理培训，确保应用 任一软件系统的人员都做到对数据真实性的足够重视。企业从上而下都应对数据的真 实而努力。这一点有的企业也己经建立相关的责任制，处分制等。
以匕无论通过哪种手段，其目的就一个，不给任何人造假数据的可能！从制度、硬件、设备、 管理、监督、监控等多方面入手，从而确保数据的真实性。
2 .数据平安性关键字：数据平安性
谈到数据平安，估计很多人第一反响都是数据备份。数据备份只是保证了数据存储的平安 性的提高（任何形式的备份都不可能到达百分百的平安）。其实往往忽略的•种平安就是数 据访问平安。
对于现在大多数的应用系统，都已经实现了网络化、B/S架构化。很多供应商在安装或 配置的时候都按照“供应商自己的方法”实现了数据的备份。给客户提出的各种备份方案也是 各种都有：冷备、热备、双机互备、异企业备份、异城市备份，甚至还有异国备份。其实我想说 你咋不做异地球备份呢。无论哪一种备份，其目的无非就是将风险逐渐降低而已，可这些备份 方案的产生乂是基于何种风险评估呢？异城市备份，如果备份到一个经常发生地震的城市，乂 何谈平安呢？如我最开始的概述文章中提到过的，异地其实就是异位，并不一定要以城市，应 基于企业的自身数据的要求，经过风险评估从而选择合适的备份策略，如果没有这些风险评估，就不担忧其备份策略被挑战吗？数据的备份平安在于合理的备份策略以 及正确的管理方式。试问，企业做了数据备份之后有定期做过数据恢复吗？你确定你备份出来 的数据就一定能还原回去吗？
关于数据访问平安，现在最容易被忽略。大家可以网上自行百度以下相关概念，如SQL注 入、SQL盲注、暴力破解、暴力损坏、默认端口扫描等等。有此应用系统都可以绕过其用户登录 直接可以访问系统。试问，这样的应用系统在访问过程中存在的这么大的平安隐患， 又何谈数据备份平安呢？访问过程中被恶意修改或者绕过应用系统进行或删除，这平安又在 哪呢？数据的访问平安在于最大程度的保护数据访问过程中的合法性。
关于数据平安这块，我忽然想到了非电子记录的平安。那备份策略又如何？难道也要进行个异城市？
3 .数据可追溯性
数据的可追溯性其目的是为了当对某个数据产生怀疑时，可追溯其数据的来源、产生过 程、时间等等。
作为软件应用系统，此追溯性在乎对数据的任何变化进行相关记录，即数据的审计跟踪。这些 审计跟踪的记录应当被平安保护，即不可通过任何方式进行修改。之前文章中提到的，不是所 有的数据都要进行审计跟踪，这一点不可混谈。那要做到正确的审计跟踪，就应该有相应的审 计跟踪策略，其策略的合规性理应通过其风险评估而来。而且这些策略应当被管理，不可随意进 行修改。
可追溯性这块，在前面的文章中有谈及过，从理论上来说这块实在是没啥好说的，具体的 还是要看各种应用系统的配置或设置了。但万变不离其中的一点就是：数据的可追溯性在 与对数据产生以后的生命周期的全过程监控以及数据产生前的连续性（也就是这个数据的来 源，来源的来源……）。
4 .总结
关于数据可靠性中所包含的内容的划分，网上也是有各种的版本，我想无非也就是以上三 点吧，脱离了这三点的数据，完整性也好，可靠性也罢，恐怕都无从谈起了……
最后，大家当前处在更换或升级改造各种仪器设备的浪潮当中，选择仪器设备的时候i定 要擦亮眼睛，去选择一些大品牌，大企业的相关仪器设备，切不可一味的跟风而丢了原本最重 要的东西。
计算机化系统验证——系统规格
1 .前言
系统规格包括了功能规格和设计规格，是供应商提供的相关文档中的重要文件。此处的 提供我说明4类软件系统和5类软件系统。当然这里的规格文件也并非软件开发过程文档 中的功能概述、设计概述、详细设计等中的任何一个文档。规格，是供应商提供的关于软件系 统的标准，是最小单元的描述，但又不是最详细的描述。在此我还是站在验证的角度来具体说明。
其实这块的东西对于非计算机相关专业或者没有学习过相关知识的人来说几乎是很难 看明白了…….功能规格FS
关键字：功能规格规格
功能规格包括有硬件功能规格HDS和软件功能规格SDS。其功能规格的文档的编写， 各个供应商都有不同的逻辑/模板。其实这里的功能规格描述主要是对URS中的各个需求描述 的实例化。比方：用户需求中要实现某个条码标签，其需求也给出了条码标签的模板，那在功能 规格中就必须给出这个条码标签的生成业务逻辑、标签中每个字段的长度、字段的类型（数字、 日期、字符、布尔值等）、字段的校验规那么等。其目的是在后续功能风险评估中有对应的风险 分析以及后续的测试用例的编写过程中对其进行详细的测试。又比方，URS中有库存管理的相 关需求，那么在功能规格中应当完成对库存管理功能的说明。如库存管理业务逻辑、相关的判定规 那么、使用条件、操作权限、数据增量说明、查询组合条件等等。对于4类软件甚至可以明确给 出相关的系统界面等。
对于中大型计算机软件系统，其功能规格可以由多个文档组成。详细程度应能正确实例 化URS中的需求项即可。必要时应增加相应的业务逻辑图以及截图说明。关键的还是对每 个需求描述中的相应的功能进行标准实例化，说白了就是应当说明这个功能能做什么、怎么做 的、怎么控制的等。还有一点就是要能看明白…….设计规格DS
设计规格同样的包括了硬件设计规格HDS和软件设计规格SDS,,其文档的主要内容是 用来完成系统的架构设计、编码语言的选择、编码逻辑的设计、数据库相关的设计、数据库字 段的实现等。
这块对于制药企业的用户来说，想看明白就更难了。后续的设计确认DQ更是无法完 成。所以国外的有些专家已经将设计确认DQ更改为了设计审核DR。尽管一词之差，但做 法就完全不同了。确认是获得证据以证实其设计的满足性、合理性。而审核只是进行审查与核 对，是对DS是否满足了功能规格中的相关功能描述进行核对。
对于4类软件来说，其设计审核可以不提供，当且仅当有个性化需求开发的时候才进行设 计审核DR,同时其设计审核报告的起草与批准由制药企业完成。对于后续的源代码审核 SCR应当由非编码人员进行，如果源代码处于供应商专利或保密策略中，也可以不进行相 关的源代码审核。但供应商应当出具相应的文件进行说明。对于5类软件来说，其DR、SCR 都应当由供应商提供，同时制药企业应当进行相应的审核并出具审核报告。
2 .需求跟踪矩阵RTM
此处的需求跟踪矩阵为第一版。主要用来描述用户需求说明书URS、功能规格FS、设 计规格DS之间的对应关系。
制药企业应当建立其需求跟踪矩阵编写规程。RTM其实是对供应商提供的FS和DS的 一个审核过程。应当对URS中提及的每一条需求进行逐一罗列其对应的FS和DSo可能会 出现一对多、多对一、多对多的关系。无论哪一种情况都应当罗列清楚以便于进行需求的跟踪。
需求跟踪矩阵是必查文档！
3 .文件职责清单
制药企业应当建立文件职责清单列表，以说明计算机化系统建设过程中的相关文件的起草、 审核、批准过程。
文件类型 (File Type >
用户 需求 说明 书
URS
供应 商设 计挨 &
SAR
蛉证 计划
VP
初步 尺险 评估 报告 A1R
功打 授格 FS
设计 妮格 DS
功微
评估 抠告 FRAR
需求跟 宏始於 RTM
设计审 核报告 DRR
源代码 审核报 告 SCRR
安装
♦认 IQ
功希
•认 0Q
ttK 确认
PQ
・认 总结
QSR
供应商 (Supplier)

P
P

P

系统用户
<Sys User>
P

P

P
P
P*

P*
P
供应商和系禁用 户(SupplierOr Sys User)

P

P-
P*

蛉证负责人 (Validation Management)
R
P
P
R
R
R
R
R
R
R
R
R
R
R
质里负责人 (Quality Management)
A
A
A
A
A
A
A
A
A
A
A
A
A
A
备注：P为起草，R为审核，A为批;t，♦表示包括执行。
图1文件列表清单
对于4类软件来说，源代码审核和审计审核报告可以不提供,但对于5类软件来说， 应进行提供或执行。
4 .总结
其实这块真没啥好说的，因为各个供应商都有一套自己的相应的质量管理体系，怎么做都 有明确的目标，至于提供的文档对或不对，是无法用一两句话来说明的，只是我们要清楚计算 机化系统关注的是什么(真实性、平安性、可追溯性)，提供的是否都包含了这些基本的要 求即可。
计算机化系统验证——安装确认IQ
1 .前言
首先给大家道个歉，这段时间太忙了， •直没有更新，在此给大家说声抱歉。
关于安装确认这块，大多数供应商也好、咱们制药企业也好，都觉得是非常简单的，按照操作手册一步步安装就是了，最后出个报告，0K 了……
其实按照软件系统或硬件系统提供的安装手册一步步安装最后出报告这个步骤来说没 错，然而少了一大局部最关键的东西一运行环境确认。运行环境确实认是整个IQ的关键。 其运行环境确定了供应商提供的软件系统或硬件系统能是否良好运行的必要条件，特别是软 件类，其运行环境的一点点差异都可能导致软件系统后续的良好运行。
2 .运行环境确认关键字：运行环境确认 环境环境确认
运行环境确实认到底在确认啥？怎么确认？确认的依据是什么？这个确认的内容又来 源于哪里？
要把以上几个问题搞明白，我们就得回头看URS 了。之前也讲过，URS是用户方或者 说是软件系统使用方提出的用户的基本的需求。用户这个时候是无法确定软件系统的运行的基 本环境的，只是提M了运行以后要到达的某些要求，比方性能要求、数据量要求、系统响应时 间要求等等。供应商收到URS后要对其进行分析，提供技术方案和用户需求分析报告。这个用 户需求分析报告里就包含了供应商提供的软件系统的运行环境以及相关配置（这里的运行环境 不等同于技术方案中的运行环境，技术方案中提供的是基本运行环境以及相关推荐配置以供用 户选择，用户一旦选择后在用户需求分析报告中就是最终确认好的运行环境以及相关硬件配置 了）。这就是我们在安装确认过程中要确认的内容的来源。
来源我们搞清楚了，但又到底要如何确认呢？依据又是什么？这个时候就应该查看供应商提 供的安装确认方案IQP文档了。该文档中详细描述了运行环境确实认步骤。比方服务器的相 关配置参数确实认、网络环境的参数配置确认、机房的环境确认等。其确认步骤是供应商按照 软件安装手册、软件配置手册进行编写。安装手册中明确描述了安装的过程，而配置手册明确的 是对软件安装过程中的配置说明。针对不同的运行环境可能配置情况都不同。安装手册以及配 置手册就是我们确认的依据。
总结：安装确认的进行，供应商提供的文档包括用户需求分析报告、系统安装手册、系 统配置手册、安装确认方案IQP （草稿）文档。
3 .安装确认方案IQP
在章节2中已经说明了安装确认方案文档的形成过程，那安装文档方案到底要如何来 写呢？步骤又应对写到什么程度？
完整的安装确认方案包含两局部，一是对软件系统或硬件系统运行环境确实认过程，二是 对软件系统或硬件系统的安装步骤确实认过程。这两局部都应当按照步骤一步步进行，对每一步 进行明确说明，同时提供预期值。而确认过程就是按照提供的步骤进行预期值的判定，从而得出实 际值。注意，这里的实际值切不可在文档中预先给出，实际值应当由确认人采用手工写出，并签 字确认。
当然，完整的IQ方案还应当包含相关执行人、执行时间，比方操作人、确认人、审批 人等。
安装确认方案IQ形成后,制药企业应当在文件的前面进行确认并批准。如下列图:
险证方案批准
The Approval of Validation Protocol
方童生单年n
Prepared by Dept
好名/取自 NameTuncbon
卷名 Signature
0期 Dale
机关部m

中总部fl
Review Dept
NameTunctioci
卷名 Signature
--：
Date
相关部门!

柏关部门1

相关¥门2

1
相关部门3

M量保ii部 QA

图1文档批准例如
Apcfftnal
Appro^ by
Sisnature
Date
度量。才人
I1ic Head of Quality

安装确认用例如下参考:
确认内容
Sample Manager 安装
目标
完成Sample Manager的安装确认，截取相关操作过程图表。
参考文件
Sample Manager安装操作手册
操作步骡
预期值
实际值
是否通过
备注（附录截图）
1）翻开 Sample Manager安装目 录，并双击 Setup.exe 文件。
Setup.exe 文件
被翻开
（手工填写）
（J或x）
见文档附录截图001

操作人/日期：确认人/日期：
.安装确认报告IQR
安装确认报告IQR的形成就比拟简单了，通过对安装确认方案的执行，填写时间结果 后最终形成安装确认报告。但报告文档中切不可忘记了相关总结。
安装确认报告应当在文档的最后被质量负责人放行。
4 .IQ执行时间
IQ的执行时间应当在正式环境下（生产环境下）进行，同时应当在0Q之前完成。但 有的软件系统的架构的缘故，比方一次安装后续功能的增加或修改不会对当前软件系统的运行 造成影响。因此可采用风险评估的方法将验证环境切换为正式环境。
对于已有软件系统但未做过相关的IQ的环境，应当重新卸载后再安装确认。但有的企业 的某些系统运行N年后可能存在一旦停机或卸载之后就无法再次重启的风险。那这样的系统 的风险就实在太高了，企业也只能吃哑巴亏了。还是选择适当的时候进行相关升级吧。
6.总结
安装确认过程，其方案是关键。方案的合理性、完整性影响的是后续安装确认过程的执行。
我的建议就是对每一个步骤进行详细推敲，是否存在相关风险，乂是如何进行规避的。
方案执行过程中发生偏差之后就应当执行相关偏差处理。完全没有偏差的过程•般很难， 因此一旦发生偏差之后我们正确对待即可。切不可人为的隐藏一些明显的偏差。比方有些软件系 统使用windows的运行环境，其配置过程中发生偏差的概率还是比拟大的，有些步骤中隐藏 「该偏差过程发生，而很有可能这个偏差的发生在国外的专家来看就是个大风险了。
关于风险评估，网上的例子一大堆，之前在学习这局部的时候看的我很蒙圈，往往是看完 之后不知所以然。在此我还是总结下自己的相关理解。
关于是否要进行风险评估，在概述中我已说明，在此不做重复。首先我们看下风险评估 流程。

图1风险评估流程
如图示，成立风险评估小组，即“谁去做”。该小组作为执行人，必须经过相关的培训， 熟悉相关流程以及具备相关的知识结构。而领取编号其FI的是为了做到任一个风险评估的管理 的追溯性。风险评估过程以及应对决策应有完整的方法论，包括风险的识别、风险的定晟分析、 风险的定性分析、