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

《计算机化系统验证总结.docx》由会员分享，可在线阅读，更多相关《计算机化系统验证总结.docx（34页珍藏版）》请在第一文库网上搜索。

1、计算机化系统验证风险评估1 .前言上一篇文章发出去之后，有位前辈帮我指出了一个比较大的问题：“计算机化系统”。在此先给大家道个歉，由于自己疏忽没有用正确的文字去描述，在此更正。开始前，我本来想自己解释下关于“计算机系统”与“计算机化系统”的概念或者区别，后来百度之后发现另一个前辈解释的更好，在此我就引用这位前辈的解释了（如果涉及到相关版权问题，我将尽快删除这段解释）。PIC/S中关于“计算机系统”的定义是：软件与硬件的组合，实现特定的功能。“A group of hardware components and associated software, designed and assemble

2、d toperform a specific function or group of functions/pic/s中有另外的对于“计算机化系统”的定义是：通过计算机系统实现、与计算机系统集成的一系列的流程或者操作。”计算机化系统”的关键词在于前半句Process or operation”。“A process or operation integrated with a computer system.w谈到“计算机化系统”，实际包括的不仅是物理存在的系统本身也包括与系统所支持的流程与操作。现在很多的企业在做“计算机化系统”验证的时候，更多侧重的往往是项目阶段的系统实施，侧重的是对“计算

3、机系统”本身的功能需求与功能测试，当然这不能说做得不对，但确实是做得不章”来具体说明，还是之前那句话，希望对新人有所帮助。本篇我主要是想阐明关于风险评估的一些关键知识点，当然这些也都是自己通过各种渠道掌握或总结而来，如果有不对的地方还请大家指正。同样的，还是围绕“为什么做，怎么做，谁去做，什么时候做”来一一阐述，希望大家在读这篇文章的时候仍然按照这个逻辑去读。2 .风险评估概述关键字：风险评估概述风险评估是在GAMP5中被加入进来的，而且是验证全过程进行风险评估及基于风险评估进行决策，其目的和原因当然就很简单了，如果拿项目来说，是为了降低交付的产品、服务或成果的产生的风险。在计算机化系统验证过

4、程中，按照验证的V模型划分为规划、规范、配置/开发、确认、报告等5个阶段，在每一个阶段都应进行相应的风险评估。而如果按照风险过程划分的话，可划分为初步风险评估及决策、进一步风险评估及决策。至于是否要做风险评估，大家认可的可能都是由质量部来决定。而这个由质量管理部“决定”的依据是什么？是否有完整的方法？这本身就是一个风险。那要降低这个“决定”的风险，首先我们要做的就是风险评估SOP,明确什么情况下要进行风险评估（相关的SOP我会在后续整理出来）。在此基于我的理解，我举几个例子说明下什么情况下（不限于以下情况）应该进行风险评估。1）安装新的与产品质量相关（除无影响而外，如安装个打印机）的系统或设备

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

6、是为了做到任一个风险评估的管理的追溯性。风险评估过程以及应对决策应有完整的方法论，包括风险的识别、风险的定量分析、风险的定性分析、风险的应对策略、未知风险的相关储备等。后续的风险报告的审核，主要是对风险的识别是否完整、风险的应对策略是否合理等进行审核，确保对已识别风险的高低进行最低化控制处理。同时对未知风险的相关储备的合理性进行审核确认，确保未知风险来临时有足够的储备进行风险处理。3.1. 风险识别对于风险的识别，想必很多人都跟我一样，懵！有时候识别出来的风险都不见得是有用的。后来我再次去看了下关于信息系统项目管理的相关书籍，回头再看也就不那么迷糊了。关键点就一句话：未来或变化或选择的人或事或

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

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

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

10、。我推荐使用如1）严重：系统崩溃、数据丢失、数据毁坏2）较严重：操作性错误、错误结果3）一般：小问题，不影响使用。将以上三种分数相乘，即可得出总体风险分数，风险总体分数（RPN）=严重性X发生可能性X可检出性，而后再根据这个总体风险分数将所有风险归类划分。低中局大211中321小332发生频率/可能性风险等级1 （高风险）风险等级2 （中度风险）风险等级3 （低风险）风险等级低中高1M-中2高中低3中低低可检出性H)ML)f fy z(高中低级级级先先先优优优优先级矩阵风险等级矩阵图2风险等级与优先级矩阵定量分析是在定性风险分析的基础上进行，定量分析并不是获得数字化的结果，而是得到更精确的风险

11、情况。是对这些风险事件的影响进行分析，从而得出更准确的风险等级。其具体的方法有很多，我就在这里不啰嗦了。总之，不管采用哪一种风险分析，其目的都是找到风险，从而确定风险的等级。为后续的风险应对决策做好准备。4 .风险应对决策关键字：风险应对、决策风险的应对决策应根据风险情况制定具体的措施，其目的是降低/消除其风险。当然完全消除风险是基本不可能的。在此我就举几个系统功能上的风险应对措施。例一：身份证号文本输入框，人工输入时的风险根据其发生错误的概率、影响以及检测性可将此风险定位高风险。应对措施：通过软件编码增加各种权限控制，从而达到降低风险的措施。如身份证号码18位长度判断、末尾字母判断等措施进行

12、风险的降低。此时还并未消除风险。进一步降低则可使用与户籍系统对接，而后通过判定身份证号码的有效性来达到降低风险的目的。此时看来风险已经被消除了，然则，与户籍系统对接后的接口风险的存在，从而并未达到风险的消除的目的。所以如之前我说的，完全消除风险是几乎不可能的。例二：计算机化系统数据备份风险，由于其备份方式的不同从而风险等级不同。应对措施：为降低这类风险，我们可采用多次备份、异位（地）备份、实时备份等不同的方式进行风险的降低。关于异位还是异地的解释，我在第一篇文章中有具体的解释，还是那句话，我认为做到异位的备份即可达到数据备份风险的接受。5 .风险评估步骤风险评估步骤这部分，可根据不同的计算机化

13、系统进行具体的分步，一般采用的是初步风险评估，即该系统的整体化风险评估以及进行风险应对决策。其次进行规划阶段的风险评估及应对决策，再次进行的是功能性风险评估分析及应对决策。还有变更控制下的风险评估及应对决策。最后进行系统退役阶段进行相关的风险评估及应对决策。1）计算机化系统的特定风险对质量体系的影响风险2）具体的业务流程采用计算机化系统后的影响风险3）计算机化系统的合规性风险4）企业相关人员整体素质风险5）项目实施对当前工作的影响风险6）针对以上风险，企业根据其自身情况给出其应对决策即可。计算机化系统验证用户需求编写规范1 .前言在写这篇文章的时候一直在纠结，到底要不要去把这个拿出来整理下，后

14、来想了想觉得还是有必要的。之前做过的计算机软件系统项目，发现客户提供的用户需求实在是没法进行后续的RTM （需求跟踪矩阵），因为缺了很多东西。通过此文章我主要是想整理下一份完整的用户需求规范文档到底如何来写，才能满足基本的验证要求，从而保证后续RTM的完整，进而让供应商可完成无论是4类软件还是5类软件的相关配置或开发。2 .用户需求规范概述关键字：用户需求规范概述用户需求规范作为计算机化系统验证的第二阶段基础（第一阶段是系统评估），其完整性、规范性决定了该计算机化系统的规范、完整，同时也决定了应用该系统以后的相关数据可靠性的基本要求。从软件系统配置或开发的角度来说，用户需求规范决定了供应商提供

15、的系统是否满足各项需求的同时仍满足其基本的法规要求。之前遇到的是制药企业提供的用户需求规范文档中本身就存在很大的漏洞，而作为软件或系统供应商，本应该是软件或系统的基本功能的反而变成了卖点。就如现在国外的汽车一样，ESP是法规强制要求必须配置的，而到了国内却成了 “亮点”、“卖点”。3 .用户需求规范框架关键字：框架作为一份完整的用户需求规范文档（以下简写为URS）,基本应包含（不限于）的是系统整体描述、系统的功能需求、系统运行的环境需求、系统运行的安全需求、系统数据的安全需求、系统的性能需求、系统的界面需求、系统的接口需求等。对于其他类型的系统可能还会有材质需求、工艺需求等等。见如下图：用户需求规范系统性能需求系统功能需求系统接口需求系统运行环境需求系统运行安全需求系统界面需求系统整体描述