计算机化系统验证总结

1、计算机化系统验证 风险评估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 中有另外的对于“计算机化系统”的定义是：通过计算机系统实现、与计算

2、机系统集成的一系列的流程或者操作。“计算机化系统”的关键词在于前半句“Process or operation”。“A process or operation integrated with a computer system.”谈到“计算机化系统”，实际包括的不仅是物理存在的系统本身，也包括与系统所支持的流程与操作。现在很多的企业在做“计算机化系统”验证的时候，更多侧重的往往是项目阶段的系统实施，侧重的是对“计算机系统”本身的功能需求与功能测试，当然这不能说做得不对，但确实是做得不够。以笔者的感觉而言，很少有企业能够理解计算机系统运行、维护阶段的要求也是验证的一部分；很少有企业能够清楚讲清

3、楚系统究竟如何支持业务流程，产生哪些数据，这些数据应该如何保留，如何销毁；很少有企业能够真正管理好计算机化系统，保持其验证状态运维阶段对于“计算机化系统”而言其实往往比项目阶段的系统实施更为重要。开始前，我本来想自己解释下关于“计算机系统”与“计算机化系统”的概念或者区别，后来百度之后发现另一个前辈解释的更好，在此我就引用这位前辈的解释了（如果涉及到相关版权问题，我将尽快删除这段解释）。之前写了一篇关于计算机化系统（更正后）验证的概述的文章，写的确实很粗，当时因为篇幅有限，无法完成整个计算机化系统验证的相关知识点的总结。接下来我会用 N 个“文章”来具体说明，还是之前那句话，希望对新人有所帮助

4、。本篇我主要是想阐明关于风险评估的一些关键知识点，当然这些也都是自己通过各种渠道掌握或总结而来，如果有不对的地方还请大家指正。同样的，还是围绕“为什么做，怎么做，谁去做，什么时候做”来一一阐述，希望大家在读这篇文章的时候仍然按照这个逻辑去读。2. 风险评估概述关键字：风险评估 概述风险评估是在 GAMP5 中被加入进来的，而且是验证全过程进行风险评估及基于风险评估进行决策，其目的和原因当然就很简单了，如果拿项目来说，是为了降低交付的产品、服务或成果的产生的风险。在计算机化系统验证过程中，按照验证的 V 模型划分为规划、规范、配置/开发、确认、报告等 5 个阶段，在每一个阶段都应进行相应的风险评

5、估。而如果按照风险过程划分的话，可划分为初步风险评估及决策、进一步风险评估及决策。至于是否要做风险评估，大家认可的可能都是由质量部来决定。而这个由质量管理部“决定”的依据是什么？是否有完整的方法？这本身就是一个风险。那要降低这个“决定”的风险，首先我们要做的就是风险评估 SOP，明确什么情况下要进行风险评估（相关的 SOP 我会在后续整理出来）。在此基于我的理解，我举几个例子说明下什么情况下（不限于以下情况）应该进行风险评估。1） 安装新的与产品质量相关（除无影响而外，如安装个打印机）的系统或设备；2） 现有系统或设备发生了变化，如运行环境的改变；3） 与现有系统或设备相关的人员组织结构发生变

6、化，如原技术服务商撤销；4） 发生偏差后，调查结果发现系统处于非受控状态，或者相关操作规程无法避免事件的再次发生。5） 3. 风险评估关键字：风险评估、方法关于风险评估，网上的例子一大堆，之前在学习这部分的时候看的我很蒙圈，往往是看完之后不知所以然。在此我还是总结下自己的相关理解。关于是否要进行风险评估，在概述中我已说明，在此不做重复。首先我们看下风险评估流程。图 1 风险评估流程如图示，成立风险评估小组，即“谁去做”。该小组作为执行人，必须经过相关的培训， 熟悉相关流程以及具备相关的知识结构。而领取编号其目的是为了做到任一个风险评估的管理的追溯性。风险评估过程以及应对决策应有完整的方法论，包

7、括风险的识别、风险的定量分析、风险的定性分析、风险的应对策略、未知风险的相关储备等。后续的风险报告的审核， 主要是对风险的识别是否完整、风险的应对策略是否合理等进行审核，确保对已识别风险的高低进行最低化控制处理。同时对未知风险的相关储备的合理性进行审核确认，确保未知风险来临时有足够的储备进行风险处理。3.1. 风险识别对于风险的识别，想必很多人都跟我一样，懵！有时候识别出来的风险都不见得是有用的。后来我再次去看了下关于信息系统项目管理的相关书籍，回头再看也就不那么迷糊了。关键点就一句话：未来或变化或选择的人或事或物是否对我当前的人或事或物产生影响，包括积极的影响。说白了就是可能发生的事是否对我

8、现在要做的事产生影响。风险识别过程应做好详细的记录，同时对风险进行分类，包括积极地、消极的、高风险、中风险、低风险等。至于风险的识别方法，可采用的有很多，我最常用的就是图解法、假设法以及头脑风暴。原理也很简单。图解法就是将整个过程进行依次分解为最小工作单元，而后逐一列出每个工作单元相关的人、事、物，而后进行逐一判断。假设法就更简单了，就是如果怎么样就怎么样的逐一进行分析。头脑风暴，并非天马行空，而是以共同目标为中心，相关参与人员畅所欲言，参会人员在他人的看法上建立自己的意见。以上三种方法并没有什么特定的使用环境，一般是想结合进行，从而确保对风险识别的完整。当然，对于识别出来的风险我们要逐一整理

9、而后进行风险分析。题外话：上初中的时候，我们数学老师跟我们说过，中小学生守则上写的都是不准怎么样，这样导致学生犯错误的几率太高了，因为不准的事永远考虑不周全，建议写成必须怎么样。尽管是个小插曲，但我想说的是，我们采用的假设法其实就是个不周全的方法，因为如果太多太多当然这件事也影响了我后来在编程软件系统的时候的一些逻辑，少采用ifelse，尽量只写应该怎么做。3.2. 风险分析风险分析包括了定性分析和定量分析。定性分析其实就是对风险进行等级划分。对于已识别的风险，风险小组应为风险进行打分，至少为 1 分。根据每个风险发生的概率，来确定风险的等级，并给出相应分数。其概率的估计可采用客观概率估计，即

10、根据历史数据或大量的试验来推定其概率。也可采用主观概率估计，即根据个人经验、预感或直觉估算出概率。高概率（3 分）、中概率（2 分）、低概率（1 分）。根据风险的可检出性来确定风险的优先级，并给出相应分数。可检出性可采用检出频次来进行划分，如凭运气检出（3 分）、可能检测到（2 分）、一直检测到（1 分）。根据风险的严重性进行划分，并给出其相应的分数，如严重（3 分）、较严重（2 分）、一般（1 分）。大多数制药企业采用的是那种死亡、重大伤害、轻度伤害的严重程度进行划分。对于计算机化系统本身来说，其严重性划分如采用此类方式，并不能准确的覆盖。我推荐使用如 1）严重：系统崩溃、数据丢失、数据毁坏

11、 2）较严重：操作性错误、错误结果 3）一般：小问题，不影响使用。将以上三种分数相乘，即可得出总体风险分数，风险总体分数（RPN）=严重性发生可能性可检出性，而后再根据这个总体风险分数将所有风险归类划分。图 2 风险等级与优先级矩阵定量分析是在定性风险分析的基础上进行，定量分析并不是获得数字化的结果，而是得到更精确的风险情况。是对这些风险事件的影响进行分析，从而得出更准确的风险等级。其具体的方法有很多，我就在这里不啰嗦了。总之，不管采用哪一种风险分析，其目的都是找到风险，从而确定风险的等级。为后续的风险应对决策做好准备。4. 风险应对决策关键字：风险应对、决策风险的应对决策应根据风险情况制定具

12、体的措施，其目的是降低/消除其风险。当然完全消除风险是基本不可能的。在此我就举几个系统功能上的风险应对措施。例一：身份证号文本输入框，人工输入时的风险根据其发生错误的概率、影响以及检测性可将此风险定位高风险。应对措施：通过软件编码增加各种权限控制，从而达到降低风险的措施。如身份证号码18 位长度判断、末尾字母判断等措施进行风险的降低。此时还并未消除风险。进一步降低则可使用与户籍系统对接，而后通过判定身份证号码的有效性来达到降低风险的目的。此时看来风险已经被消除了，然则，与户籍系统对接后的接口风险的存在，从而并未达到风险的消除的目的。所以如之前我说的，完全消除风险是几乎不可能的。例二：计算机化系

13、统数据备份风险，由于其备份方式的不同从而风险等级不同。应对措施：为降低这类风险，我们可采用多次备份、异位（地）备份、实时备份等不同的方式进行风险的降低。关于异位还是异地的解释，我在第一篇文章中有具体的解释，还是那句话，我认为做到异位的备份即可达到数据备份风险的接受。5. 风险评估步骤风险评估步骤这部分，可根据不同的计算机化系统进行具体的分步，一般采用的是初步风险评估，即该系统的整体化风险评估以及进行风险应对决策。其次进行规划阶段的风险评估及应对决策，再次进行的是功能性风险评估分析及应对决策。还有变更控制下的风险评估及应对决策。最后进行系统退役阶段进行相关的风险评估及应对决策。1） 计算机化系统

14、的特定风险对质量体系的影响风险2） 具体的业务流程采用计算机化系统后的影响风险3） 计算机化系统的合规性风险4） 企业相关人员整体素质风险5） 项目实施对当前工作的影响风险6） 针对以上风险，企业根据其自身情况给出其应对决策即可。计算机化系统验证用户需求编写规范1. 前言在写这篇文章的时候一直在纠结，到底要不要去把这个拿出来整理下，后来想了想觉得还是有必要的。之前做过的计算机软件系统项目，发现客户提供的用户需求实在是没法进行后续的 RTM（需求跟踪矩阵），因为缺了很多东西。通过此文章我主要是想整理下一份完整的用户需求规范文档到底如何来写，才能满足基本的验证要求，从而保证后续 RTM 的完整，进

15、而让供应商可完成无论是 4 类软件还是 5 类软件的相关配置或开发。2. 用户需求规范概述关键字：用户需求 规范 概述用户需求规范作为计算机化系统验证的第二阶段基础（第一阶段是系统评估），其完整性、规范性决定了该计算机化系统的规范、完整，同时也决定了应用该系统以后的相关数据可靠性的基本要求。从软件系统配置或开发的角度来说，用户需求规范决定了供应商提供的系统是否满足各项需求的同时仍满足其基本的法规要求。之前遇到的是制药企业提供的用户需求规范文档中本身就存在很大的漏洞，而作为软件或系统供应商，本应该是软件或系统的基本功能的反而变成了卖点。就如现在国外的汽车一样，ESP 是法规强制要求必须配置的，而

16、到了国内却成了“亮点”、“卖点”。3. 用户需求规范框架关键字：框架作为一份完整的用户需求规范文档（以下简写为URS），基本应包含（不限于）的是系统整体描述、系统的功能需求、系统运行的环境需求、系统运行的安全需求、系统数据的安全需求、系统的性能需求、系统的界面需求、系统的接口需求等。对于其他类型的系统可能还会有材质需求、工艺需求等等。见如下图：图 1 用户需求规范框图系统整体描述：用于对系统的高层次的需求的描述，主要包括背景、目的、范围、面向的用户以及该系统带来的益处；系统的主要功能概述；相关的 GxP 要求及其他相关的法规。系统功能需求：可按模块、业务类型进行分类描述。其描述应当是对功能的最

17、小单元需求，切不可出现如“系统应实现物料管理功能”的模糊描述。会造成供应商在响应其需求时更加的模糊，甚至模糊处理。其次，描述具体功能时尽量避免使用“等”字眼，同样的会造成 RTM 时不可追溯。对于关键数据定义应明确，包括其测量范围、参数控制、逻辑控制等。系统运行环境需求：物理条件中的温湿度、灰尘、噪音、震动；电源及设施需求；软件环境下（如适用）的数据库需求、服务器品牌需求（有些企业为了供应商的集中服务而统一采购同一品牌的服务器）等。系统运行的安全需求：软件系统访问时的传输协议需求（如 http/https）、网络环境需求（内网环境或VPN 访问）、防病毒需求、故障恢复需求等。系统的数据安全需求

18、：备份需求（热备/冷备/频率）、各类默认端口屏蔽需求、SQL 注入/盲注（web 系统基本需求，如适用）等。系统性能需求：软件系统的并发访问压力需求、响应速度需求、数据量增长需求（涉及到系统数据库规划）等。系统界面需求：语言需求、界面样式需求、布局需求等。系统接口需求：主要用于方便系统的扩展需求，目前常用的接口技术有 Web Services、JSON，由于其技术成熟，风险相对较小。（此处涉及系统集成，不同的系统集成一般不建议使用数据库层面的集成，其风险等级较高，一旦发生偏差则很难发现根本原因。但可采用数据库中间表的方式进行，此表至少应与任何一个系统的所属表隔离）。通过上述的各类需求（不限于）

19、的描述，基本可满足相关规范要求的同时保证供应商可对 URS 进行明确的响应。4. 功能需求-审计跟踪关键字：功能需求、审计跟踪审计跟踪功能本身并不神秘，无非就是对系统产生的数据做到跟踪处理，如发现修改时同时记录历史数据、修改时间、修改人、修改原因等，但不可与 workflow event log 混谈， WEL 仅仅是对工作流中的操作人、日期进行了记录，并未对其操作的数据进行跟踪记录， 是一个软件系统的基本功能。审计跟踪功能包含有全数据跟踪和部分数据跟踪。之前遇到过的需求中有要求全跟踪，综合分析下来发现其实是企业对风险评估不到位。全数据跟踪固然很完整，但对系统的压力、数据的存储等都提出了很高的

20、要求，系统长时间运行后其性能严重降低。所以大家在选择审计跟踪功能时，切不可一股脑的去选择全跟踪，应根据其功能风险评估去做好相应的选择。上面提到了，审计跟踪功能本身不神秘，但特别繁琐，不亚于其系统本身功能的开发成本，甚至还要比功能开发成本更高。对于软件系统供应商来说最好的做法就是通过各种配置去实现其审计跟踪功能，诚然成本也更高了。这一点国外的一些软件做的还是相当不错的， 比如国外系统供应商 Thermo Fisher 的一些软件在这方面就做的很好。5. 功能需求-电子签名关于电子签名需求这块，企业参考的无非就是 FDA_21_CFR_Part_11，但在实施项目过程当中发现企业对电子签名这块的理

21、解有个很大的误区：把手工签名后上传到系统中而后 在各种报告中展现出来认为是电子签名。这个我在跟一位 FDA 的专家沟通的时候，他跟我解释的是这只能算是电子签名的一种美化（前提是电子签名功能必须完整）。完整的电子签名要求包括有（ 参考中华人民共和国电子签名法【 2015 】 1） 电子签名属于签名人专有，也就是说电子签名所属人必须妥善保管，并且当认为电子签名数据失效后应及时告知有关放，并且终止使用该电子签名。2） 签名时，其操作仅可由所属人控制，也就是说不能带签。3） 签名完成后，对电子签名的任何改动都能够被发现，也就是说系统必须有自动校验功能。4） 对于签名后的数据或文件的改动，都能够被系统侦

22、测到并明显提醒。对于签名的形式，可以是任意的。哪怕是系统宋体的签名也是可以认可的。但对系统的电子签名功能有了很高的要求。微软的电子签名认证做的就很完善。6. 总结URS 在编写过程中，本身即必须符合相关法规要求，同时应根据企业自身的条件而进行优化，生搬硬抄的 URS 只会将企业限于更深的泥潭。主要表现在计算机化系统上线运行后带来的管理成本的提高，甚至无法做到其符合规范的管理。对于明显存在高风险的需求，应当严格控制，尽管对软件系统供应商来说实现起来可能很简单。比如原始数据的复制功能，其需求已经偏离了原始二字。本来还想把数据可靠性的相关需求也加入到这篇文章中来，后来想想还是后续单独列出来整理吧。计

23、算机化系统验证 验证计划1. 前言验证计划属于规划阶段的最关键的一节，其合理性、完整性决定了后续验证工作开展的顺利程度。之前还见过一个版本的“验证计划”：甘特图，其实就是个任务时间安排，关键是安排的还不是很合理。此“验证计划”就不能称之为验证计划了。我认为合理的、完整的验证计划，至少应包含“做什么”、“谁去做”、“什么时候做”以及“完成后的成果”。2. 验证计划概述关键字：验证计划 概述在第一篇计算机话系统验证的那篇文章中，我把验证当做一个项目来看到，那验证计划就等同于项目计划了。其包含的内容主要有：概述、相关规定、验证人员组织、任务时间安排、培训管理计划、偏差管理计划、变更管理计划、报告管理

24、计划、相关术语以及附录。图 1 验证计划框图概述：主要用于该验证项目的整体描述，包括目的、范围、项目背景等。相关规定：主要用于对该验证活动的一些特别说明。如若供应商无法提供源代码时，从而导致无法进行源代码审核，此时应说明由供应商提供相关质量保证文件。验证人员组织：用于明确验证相关人员及组织架构。一般验证团队由供应商（或第三方验证人员）、企业相关验证人员组成，并且应明确说明各个组织的相关职责。对于源代码审核或设计审核企业用户无法完成时，应由第三方组织进行，或由企业提供相关质量保证证明。任务时间安排：应明确验证任务以及任务时间安排、人员安排，任务分解至最小单元。若不能提供具体的人员安排，则应明确在

25、后续哪个文件中详细安排。如 IQ 人员安排此处若不能提供详细人员名单，则必须在 IQ 方案中提供具体的人员名单。对于 OQ 和 PQ 的时间安排，应结合软件系统的特性进行。OQ 和 PQ 可以同步进行，也可以 OQ 完成之后进行PQ。主要取决于软件系统的各个模块之间的强关联性。培训管理计划：主要是对各个相关验证人员的培训安排，以确保后续相关活动的合规性。如 IQ、OQ、PQ 进行前必须对相关人员进行培训，并形成培训记录，必要时可进行相关考核。如 IQ 中相关软件的安装过程。偏差管理计划：主要用来对验证过程中发生的偏差进行处理。对于一个计算机化系统中的软件部分，不可能不发生偏差。变更管理计划：主

26、要是用来对于一些需求上的变更的管理。比如由于各种技术或法规的要求，之前的 URS 中提及的某些功能已经无法满足需求或者有更好的技术实现，则可以通过变更管理计划完成。报告管理计划：主要是用来记录或报告相关活动的成果，该管理计划中应说明什么报告应经过什么样权限的人员去审核、去批准，并且对于发现问题的报告应如何处理等。报告应以文档形式保存，且报告中相关记录应在验证过的系统中保留原始痕迹。相关术语及附录：主要是用来说明相关缩写、名词介绍等。附录中可以明确验证过程中使用的一些模板、流程等。如果验证计划有相关附件，也需增加相关附件说明。3. 验证计划目录样例如下图示验证计划目录样例：图 2 验证计划目录结

27、构样例4. 写在最后在写章节 3 的时候，我一直想把我之前整理过的完整的验证计划文档粘贴进来，但总是出现各种排版错误，后来想了想待后续一起打包发给大家吧。这篇文章写到最后的时候，回头来看，过于简单了，本不想拿出来整理，后来想了想就当自己总结吧。如果对您能有所帮助，也算是对我一点安慰吧。计算机化系统验证 供应商审计1. 前言关于供应商审计这块，咱们制药企业在做原物料供应商审计的时候做的已经非常好了，但对于计算机化系统的供应商审计在我接触过的企业中，是比较薄弱的，仍然采用之前的方式进行相关审计，得来的结果只能是高风险的供应商。那么如何规避此项风险，我们可以换个角度来思考，对于计算机化系统的供应商审

28、 计，至少应从其供应商企业本身的质量管理抓起，通过各级审查从而得出其相对合格的供应商。而对于软件系统代理商（其风险等同原物料的代理商）其要求就更严格了。因为其代理权限的到期或者被收回，很可能就意味着其技术服务的中止。2. 供应商审计概述关键字：供应商审计 概述抛开原物料供应商的审计过程，我们在此只谈关于计算机化系统的供应商的审计。在描述审计过程之前，我们先看下 GAMP5 中关于供应商的规范化活动，这块 GAMP5 花了一个大的章节包含 14 个小节来说明，从供应商的产品、应用及服务谈起，经过其质量管理、产品规划、产品设计、编码开发、系统测试、产品发布、用户文档、技术支持到系统的退役全过程进行

29、详细的规范化管理说明。具体参见 Supplier Activities 7 Sec GAMP5。从其活动过程来看，GAMP5 实际上在供应商建立计算机化系统的全过程的活动中给出了规范化的操作，也就是说供应商至少应按照这些活动来建立相关计算机化系统，才能保证其系统满足相关法规的要求。那么企业在选择供应商时所进行的供应商审计即是围绕这些活动进行。抛开供应商的财务状况、资质能力、企业合法性等，企业应当着重审计供应商的质量管理体系相关文件，当然也存在无论是物料供应商还是计算机化系统供应商其有体系而不完全执行的风险。关于这个风险，按照 GAMP5 中的软件类别划分，如果是 5 类软件系统， 企业则承担起

30、监督的作用。而对于 4 类软件系统供应商则审查其软件系统形成过程中的相关产出物了。如软件系统设计/开发/测试过程产生的相关文档。3. 供应商活动说明无论是 4 类软件系统供应商还是 5 类软件系统供应商，其供应商活动都是一致的。对于一个规范化的软件系统供应商，GAMP5 给出了其规范化程序即良好实践。包含有建立QMS、需求管理、质量计划管理、子供应商评估、产品规格、执行设计审核、软件开发/配置、实施测试、系统的商业发布、提供的用户文档和培训、相关技术支持、系统的更新换代与退役。相关解释在 GAMP5 中有说明，在此我就不重复了。1） 建立 QMS，供应商应提供一套标准化的程序已支持其后续的相关

31、活动，同时应对对相关人员进行培训，以确保参与系统建设活动的相关人员都明确。这套标准化的程序建立应对符合供应商文件化程序的管理标准，包括后续的版本升级过程。这里拥有CMMI 2 级以上的供应商基本上都可以满足。2） 需求管理，需求可以是用户提供（5 类软件），也可以是供应商内部建立。标准化的需求管理，最关键的是体现在其跟踪、追溯方面的管理。3） 质量管理计划，供应商应建立相关质量管理系统，以保证其质量管理计划的执行。至少应满足 GAMP5 给出的良好实践相关内容。4） 子供应商评估，供应商在产生相关的软件系统时，可能会遇到与其子供应商合作的情况，因此应当建立对子供应商的评估相关规程。5） 产品规

32、格，对于产品开发，供应商应当建立系统的功能规格 FS（包含软件功能规格 SFS、硬件功能规格 HFS）、设计规格 DS（包含软件设计规格 SDS、硬件设计规格（HDS）。功能规格主要明确软件、硬件将要做什么，而设计规格是基于功能规格的，主要明确软件怎么做。6） 设计审核，供应商应对建立完善的设计审核制度，以确认产品的设计至少应对满足其需求。同时建立用户需求跟踪矩阵，明确URS-FS-DS 的对应关系，确保用户需求已被完成相关设计。当然设计审核过程也包括了产品的设计的合理性、技术的先进性等等。7） 软件开发/配置，供应商开发或配置团队根据相关设计文档进行编码开发或配置。8） 实施测试。供应商应对

33、建立全面的测试计划，包括单元测试、集中测试、系统测试以及白盒测试。测试过程应对涵盖所有FS。并且以文档化保存测试过程。9） 商业发布。供应商应对建立系统发布的相关规程，明确版本控制。发布时应对建立与其对应的更新日志。如果是 5 类软件，还应对遵循应用企业的相关政策。10） 用户文档和培训。供应商应建立完善的用户文档，包括操作文档、配置文档、安装文档、培训文档等。11） 供应商技术支持。供应商应当有完善的售后服务管理机制，以确保软件系统应用企业得到足够的技术支持。包括有变更管理计划、配置管理计划、补丁管理计划、应急事件管理计划、文件管理计划、备份还原计划、业务连续性计划、培训管理计划、系统维护计

34、划等。12） 系统的退役或更新换代。供应商应对根据书面流程进行系统的退役及更新换代。这里与微软的操作系统在退役或更新换代时所进行的相关流程类似。以上，即是供应商在建立相关软件系统时所进行的活动。对于供应商的测试过程文档是否可以替代验证过程中的测试文档，应当根据软件类别（4 类或 5 类）进行选择。对于 4 类软件，由于其需求有可能是供应商自定义的，需求是否满足或部分满足相关法规要求而未知， 因此无法完全替代。而对于 5 类软件，由于系统建立过程是在企业与供应商共同参与下完成的，其验证过程和供应商的软件系统建设过程同步进行，所以可以使用其测试过程文档代替验证过程的测试文档，但需在验证计划中明确说

35、明。4. 供应商审计检查列表了解了供应商的相关活动后，我们即可建立相关的供应商审计检查列表，通过对列表中的条码一一确认，从而进行合格供应商的选择。如下是 GAMP5 的供应商审计检查列表（部分），供大家参考。QUALITY SYSTEMQuestions庋量体系i啜Answer答案Objective Evidence客观证据1.1.Quality system Framework庋噩体系的架构1.1 .1 .Written Quality Commitment书面的质呈承诺1 1 _11)oes the supplier have a formal written quality policy

36、 statement endlo 飞 ed by senior management?供皮商登否有正式的经禹级管理人员批准的质蛊管理规程？1 1 _12Is the quality policy communic ated and maintained throughout the organization (new & existing employees)?质噩管理规程登否在整系个统中培训（包括新的和现有的员工）？1 1_13Does the policy expess the object ives for qLJality an d commitment t o quality?质曼手

37、册匣否体现质噩目标质汲蛋承诺？1.1.2.Organiza廿ona.l Stru cture (Roles andResponsib ili佃司组织架构（角色与责任）1 12_ 1Is thee a defined quality system?是否有质量体系？QUALITY SYSTEMQuestio n s庋量体系问题Answe答案Obj釭 tive Evi dence客观证据11 .44Are meth ods in place to ensure that changes to pocedlu e s ae communic ate dl to personnel responsibl

38、e for performing the work?在变要规程时，是否有规程规定变要后的规程需对相关的人员进行培训？1 .1.5.Interna l Audits and Inspections 内部审计和自检1 1.5 1!Joes the quality system provide for internal audits aga inst quality systemequirements?质蛊体系豐否根据质蛊要求自检？11 .5 2Jo int ernal audits address all areas of the suppliers quality system?自检是否七叶舌对

39、所有供应商质量体系的审核？1 1 .5 3lo audits verify c ompliance lo procedure s?亩计程序号否与规程一致？1 1.54Are audits of th.equ ality system peiodically scheduled?质董体系的审计豐否定期进行？11 .5 5Do audits address the eff 邸 liveness of the qualily system?亩计是否核实质量体系的有效性？1 1.5 6Are ,devialio111s lo procedure s andPodLJct standards, iden

40、tified through aLJdlit s alldl5. 总结关于供应商审计这块，我认为主要的还是我们要了解软件供应商的主题活动，即使没有GAMP5 提供的相关指导意见，我们也应当对我们选择的供应商的产品特性有所了解，从而才能保证我们选择的供应商风险最低。计算机化系统验证数据可靠性1. 前言前一段时间网上关于“数据可靠性”还是“数据完整性”讨论的异常热烈，好像每个人都在不同的角度有不同的看法，一时间好像真的没法区分到底应该是可靠性还是完整性。在此我不讨论关于他俩的区别或者谁对谁错，我也跟着国家机构用语而走使用数据可靠性。无论是可靠性还是完整性，提出这个概念的人或组织其目的无非是为了保证

41、数据的真实性、安全性、可追溯性。说白了就是无论你怎么操作数据必须真实，数据保存或使用必须安全，同时数据必须要能追溯。2. 数据真实性关键字：数据 真实数据真实性从字面意思理解很简单了，就是数据要真实。那如何保证呢？最简单“粗暴”、最有效的做法就是企业或仪器供应商就不给你数据造假的可能！从单机版的工作站到网络版的 CDS，从不可操作的数据显示到可操作又存储的设备单元，从数据操作不受限到各种角色权限的控制，无一不是为了数据的真实性而努力。还记得某个专家进入某家药企检查其带工作站的仪器，仅仅只是看了下工作站的操作权限控制后就开出了多个不符合项而今我们谈数据的真实性，无非就是想通过某一种手段从而确保任

42、何人都不能进行数据的非法修改。目前已知控制的无非如下几点：1） 工作站电脑的权限角色控制。企业建立相应的计算机使用管理规程，规定使用计算机的用户管理、密码策略管理、权限管理（权限申请、分配、施放）、安全管理等。有能力的企业甚至使用域管理，做到软件的各类操作管理等。这一点现在已经是必查项了！2） 计算机软件系统用户、权限、角色控制、密码策略等管理。应用如第一条中的相关管理规程，对应用系统相关进行设置，确保应用系统中的相关数据不能通过任一修改。相关管理规程也是必查项！3） 通过相关的 SOP、培训等提高企业用户的意识，做好相应的质量管理培训，确保应用任一软件系统的人员都做到对数据真实性的足够重视。

43、企业从上而下都应对数据的真实而努力。这一点有的企业也已经建立相关的责任制，处罚制等。以上，无论通过哪种手段，其目的就一个，不给任何人造假数据的可能！从制度、硬件、设备、管理、监督、监控等多方面入手，从而确保数据的真实性。3. 数据安全性关键字：数据 安全性谈到数据安全，估计很多人第一反应都是数据备份。数据备份只是保证了数据存储的安全性的提高（任何形式的备份都不可能达到百分百的安全）。其实往往忽略的一种安全就是数据访问安全。对于现在大多数的应用系统，都已经实现了网络化、B/S 架构化。很多供应商在安装或配置的时候都按照“供应商自己的办法”实现了数据的备份。给客户提出的各种备份方案也是各种都有：冷

44、备、热备、双机互备、异企业备份、异城市备份，甚至还有异国备份。其实我想说你咋不做异地球备份呢。无论哪一种备份，其目的无非就是将风险逐渐降低而已，可这些备份方案的产生又是基于何种风险评估呢？异城市备份，如果备份到一个经常发生地震的城市，又何谈安全呢？如我最开始的概述文章中提到过的，异地其实就是异位，并不一定要以城市，应基于企业的自身数据的要求，经过风险评估从而选择合适的备份策略，如果没有这些风险评估，就不担心其备份策略被挑战吗？数据的备份安全在于合理的备份策略以及正确的管理方式。试问，企业做了数据备份之后有定期做过数据恢复吗？你确定你备份出来的数据就一定能还原回去吗？关于数据访问安全，现在最容易

45、被忽略。大家可以网上自行百度以下相关概念，如 SQL 注入、SQL 盲注、暴力破解、暴力损坏、默认端口扫描等等。有些应用系统都可以绕过其用户登录直接可以访问系统。试问，这样的应用系统在访问过程中存在的这么大的安全隐患，又何谈数据备份安全呢？访问过程中被恶意修改或者绕过应用系统进行或删除，这安全又在哪呢？数据的访问安全在于最大程度的保护数据访问过程中的合法性。关于数据安全这块，我忽然想到了非电子记录的安全。那备份策略又如何？难道也要进行个异城市？4. 数据可追溯性数据的可追溯性其目的是为了当对某个数据产生怀疑时，可追溯其数据的来源、产生过程、时间等等。作为软件应用系统，此追溯性在于对数据的任何变

46、化进行相关记录，即数据的审计跟踪。这些审计跟踪的记录应当被安全保护，即不可通过任何方式进行修改。之前文章中提到的， 不是所有的数据都要进行审计跟踪，这一点不可混谈。那要做到正确的审计跟踪，就应该有 相应的审计跟踪策略，其策略的合规性理应通过其风险评估而来。而且这些策略应当被管理， 不可随意进行修改。可追溯性这块，在前面的文章中有谈及过，从理论上来说这块实在是没啥好说的，具体的还是要看各种应用系统的配置或设置了。但万变不离其中的一点就是：数据的可追溯性在与对数据产生以后的生命周期的全过程监控以及数据产生前的连续性（也就是这个数据的来源，来源的来源）。5. 总结关于数据可靠性中所包含的内容的划分，

47、网上也是有各种的版本，我想无非也就是以上三点吧，脱离了这三点的数据，完整性也好，可靠性也罢，恐怕都无从谈起了最后，大家当前处在更换或升级改造各种仪器设备的浪潮当中，选择仪器设备的时候一定要擦亮眼睛，去选择一些大品牌，大企业的相关仪器设备，切不可一味的跟风而丢了原本最重要的东西。计算机化系统验证 系统规格1. 前言系统规格包括了功能规格和设计规格，是供应商提供的相关文档中的重要文件。此处的提供我表明 4 类软件系统和 5 类软件系统。当然这里的规格文件也并非软件开发过程文档中的功能概述、设计概述、详细设计等中的任何一个文档。规格，是供应商提供的关于软件系统的标准，是最小单元的描述，但又不是最详细

48、的描述。在此我还是站在验证的角度来具体说明。其实这块的东西对于非计算机相关专业或者没有学习过相关知识的人来说几乎是很难看明白了2. 功能规格 FS关键字：功能规格 规格功能规格包括有硬件功能规格 HDS 和软件功能规格 SDS。其功能规格的文档的编写， 各个供应商都有不同的逻辑/模板。其实这里的功能规格描述主要是对 URS 中的各个需求描述的实例化。比如：用户需求中要实现某个条码标签，其需求也给出了条码标签的模板，那在功能规格中就必须给出这个条码标签的生成业务逻辑、标签中每个字段的长度、字段的类型（数字、日期、字符、布尔值等）、字段的校验规则等。其目的是在后续功能风险评估中有对应的风险分析以及

49、后续的测试用例的编写过程中对其进行详细的测试。又比如，URS 中有库存管理的相关需求，则在功能规格中应当完成对库存管理功能的说明。如库存管理业务逻辑、相关的判定规则、使用条件、操作权限、数据增量说明、查询组合条件等等。对于 4 类软件甚至可以明确给出相关的系统界面等。对于中大型计算机软件系统，其功能规格可以由多个文档组成。详细程度应能正确实例化 URS 中的需求项即可。必要时应增加相应的业务逻辑图以及截图说明。关键的还是对每个需求描述中的相应的功能进行标准实例化，说白了就是应当说明这个功能能做什么、怎么做的、怎么控制的等。还有一点就是要能看明白3. 设计规格 DS设计规格同样的包括了硬件设计规

50、格 HDS 和软件设计规格SDS。其文档的主要内容是用来完成系统的架构设计、编码语言的选择、编码逻辑的设计、数据库相关的设计、数据库字段的实现等。这块对于制药企业的用户来说，想看明白就更难了。后续的设计确认 DQ 更是无法完成。所以国外的有些专家已经将设计确认 DQ 更改为了设计审核 DR。尽管一词之差，但做法就完全不同了。确认是获得证据以证实其设计的满足性、合理性。而审核只是进行审查与核对，是对 DS 是否满足了功能规格中的相关功能描述进行核对。对于 4 类软件来说，其设计审核可以不提供，当且仅当有个性化需求开发的时候才进行设计审核 DR，同时其设计审核报告的起草与批准由制药企业完成。对于后

51、续的源代码审核SCR 应当由非编码人员进行，如果源代码处于供应商专利或保密策略中，也可以不进行相关的源代码审核。但供应商应当出具相应的文件进行说明。对于 5 类软件来说，其 DR、SCR 都应当由供应商提供，同时制药企业应当进行相应的审核并出具审核报告。4. 需求跟踪矩阵 RTM此处的需求跟踪矩阵为第一版。主要用来描述用户需求说明书 URS、功能规格 FS、设计规格 DS 之间的对应关系。制药企业应当建立其需求跟踪矩阵编写规程。RTM 其实是对供应商提供的 FS 和 DS 的一个审核过程。应当对 URS 中提及的每一条需求进行逐一罗列其对应的 FS 和 DS。可能会出现一对多、多对一、多对多的

52、关系。无论哪一种情况都应当罗列清楚以便于进行需求的跟踪。需求跟踪矩阵是必查文档！5. 文件职责清单制药企业应当建立文件职责清单列表，以说明计算机化系统建设过程中的相关文件的起草、审核、批准过程。图 1 文件列表清单对于 4 类软件来说，源代码审核和审计审核报告可以不提供，但对于 5 类软件来说， 应进行提供或执行。6. 总结其实这块真没啥好说的，因为各个供应商都有一套自己的相应的质量管理体系，怎么做都有明确的目标，至于提供的文档对或不对，是无法用一两句话来说明的，只是我们要清楚计算机化系统关注的是什么（真实性、安全性、可追溯性），提供的是否都包含了这些基本的要求即可。计算机化系统验证 安装确认

53、 IQ1. 前言首先给大家道个歉，这段时间太忙了，一直没有更新，在此给大家说声抱歉。关于安装确认这块，大多数供应商也好、咱们制药企业也好，都觉得是非常简单的，按照操作手册一步步安装就是了，最后出个报告，OK 了其实按照软件系统或硬件系统提供的安装手册一步步安装最后出报告这个步骤来说没 错，然而少了一大部分最关键的东西运行环境确认。运行环境的确认是整个 IQ 的关键。其运行环境确定了供应商提供的软件系统或硬件系统能是否良好运行的必要条件，特别是软件类，其运行环境的一点点差异都可能导致软件系统后续的良好运行。2. 运行环境确认关键字：运行环境确认 环境 环境确认运行环境的确认到底在确认啥？怎么确认

54、？确认的依据是什么？这个确认的内容又来源于哪里？要把以上几个问题搞明白，我们就得回头看 URS 了。之前也讲过，URS 是用户方或者说是软件系统使用方提出的用户的基本的需求。用户这个时候是无法确定软件系统的运行的基本环境的，只是提出了运行以后要达到的某些要求，比如性能要求、数据量要求、系统响应时间要求等等。供应商收到 URS 后要对其进行分析，提供技术方案和用户需求分析报告。这个用户需求分析报告里就包含了供应商提供的软件系统的运行环境以及相关配置（这里的运行环境不等同于技术方案中的运行环境，技术方案中提供的是基本运行环境以及相关推荐配置以供用户选择，用户一旦选择后在用户需求分析报告中就是最终确

55、认好的运行环境以及相关硬件配置了）。这就是我们在安装确认过程中要确认的内容的来源。来源我们搞清楚了，但又到底要如何确认呢？依据又是什么？这个时候就应该查看供应商提供的安装确认方案 IQP 文档了。该文档中详细描述了运行环境的确认步骤。比如服务器的相关配置参数的确认、网络环境的参数配置确认、机房的环境确认等。其确认步骤是供应商按照软件安装手册、软件配置手册进行编写。安装手册中明确描述了安装的过程，而配置手册明确的是对软件安装过程中的配置说明。针对不同的运行环境可能配置情况都不同。安装手册以及配置手册就是我们确认的依据。总结：安装确认的进行，供应商提供的文档包括用户需求分析报告、系统安装手册、系统

56、配置手册、安装确认方案 IQP（草稿）文档。3. 安装确认方案 IQP在章节 2 中已经说明了安装确认方案文档的形成过程，那安装文档方案到底要如何来写呢？步骤又应对写到什么程度？完整的安装确认方案包含两部分，一是对软件系统或硬件系统运行环境的确认过程，二是对软件系统或硬件系统的安装步骤的确认过程。这两部分都应当按照步骤一步步进行，对每一步进行明确说明，同时提供预期值。而确认过程就是按照提供的步骤进行预期值的判定， 从而得出实际值。注意，这里的实际值切不可在文档中预先给出，实际值应当由确认人采用手工写出，并签字确认。当然，完整的 IQ 方案还应当包含相关执行人、执行时间，比如操作人、确认人、审批人等。安装确认方案 IQ 形成后，制药企业应当在文件的前面进行确认并批准。如下图：图 1 文档批准示例安装确认用例如下参考：确认内容Sample Manager 安装目标完成 Sample Manager 的安装确认，截取相关操作过程图表。参考文件Sample Manager 安装操作手册操作步骤预期值实际值是否通过备注（附录截图）1）打