计算机系统验证 第一篇（持续更新中...........）

tooseven

happy1105 发表于 2014-3-2 00:28
楼主讲的很不错，学习

谢谢鼓励！

tooseven

药仙 发表于 2014-2-21 11:13
没有看到实际内容，但是大家都说好，看来大家跟楼主一样，也就这水平呵呵

我的帖子不会涉及实际的验证测试！让您失望了！

怜魂彡彡

不错  学习 学习 ，制药专业的 计算机人

药仙

tooseven 发表于 2014-3-2 20:51
我的帖子不会涉及实际的验证测试！让您失望了！

没事，以及很不错了，我可能太着急了，很想见到一个搞计算机验证的高手坛友共同提高，我的意思是具体的计算机验证的实施过程应该具体讲一下。
看来我的激将法没有起到作用

tooseven

很久没时间来论坛逛了！最近忙的不是一般！感觉时间严重不够用！有点日子不多的感觉！

上一篇帖子提到了质量风险评估，在正式启动风险评估之前，先跟大家聊一聊，目前工厂里面都有哪些质量管理和控制程序！

我说一说我了解的程序：

1.        培训管理

2.        文件管理

3.        变更管理

4.        偏差管理

5.        供应商审计

6.        校准

7.        验证管理

8.        SOP&受控表格

9.        记录&数据管理

。。。。。。

10.    质量风险管理

11.    内部审计

12.    外部审计

。。。。。。

很多管理和程序就不一一列举了，但以上这些都是一些基础的管理和控制程序！通常来说，药品是药厂的产品，制药企业的员工应该是产品的主人，因此制药企业的员工理所应当把自己的药品质量管好，因为你是它的主人。我们扩展一下，计算机系统，生产设备，HVAC，纯化水系统，实验室仪器等等，所有这些用来支持药品生产活动的设备系统，其本质也是一个个产品。这些产品到了企业以后，企业的人自然也就成了他们的主人。因此，企业的员工理所应当把其管好！这些产品与你生产的药品不同的是，药品基本上是在药企由自己的员工组装的（生产的）是亲儿子，但是这些设备系统干儿子。但是只要你当了爹，就都应该管好！因此质量管理同样适用于这些设备系统！

说道这，就基本上扯到正题了，所谓的质量风险评估，就是要评估你的这些干儿子如果出了问题，应该用什么质量管理手段去管理，或者如何管理，才能防止其出现潜在的问题！在上一篇中提到了，初步的系统上的风险评估。就是判定系统是不是与GMP相关。如果与GMP相关，就要看它会影响GMP的什么方面，对于计算机系统来说这3个方面就是产品质量，患者安全和法规记录的完整性。

因此风险评估的过程就是看这些干儿子应该用哪些质量管理工具才能管好！让其听话，为你的亲儿子服务！要想管好，你就得知道这些干儿子，要是出了问题，影响有多大（失败的危害有多大），哪些方面会导致其出问题，（失败的原因），这些导致失败的原因发生的可能性有多大。根据这些失败的危害性和发生的可能性确定风险的等级！并将根据失败的原因制定相应的控制策略。这就是风险评估的过程！这个过程肯定是要记录的，也就是文件化，对产生的控制策略，也要有追踪，以完成其管理！

至于需要做验证的，那就验呗！写个方案，测一测！

至于计算机系统到底对产品质量，患者安全和法规记录的完整性有什么危害，这个不能一概而论，要看你的知识水平！像对产品质量要求低，人命不值钱，法规监管也不是很严的国家，你评估其危害就可能低一些，像有的国家其要求高，重视生命，监管也严因此其危害可能就严重一些。但是所有患者都是人，人的生命应该是平等的，因此不应以国家和地域去判定危害的严重程度。这可能也是GMP要求风险管理是基于科学知识以及经验的原因。（纯属调侃）。

在此引用一个新闻联播里的片段，大家可以感受到！所有的风险管理概念都是一样的。

明朗

学习学习。。。。

longstory

很有见地！共同努力，把计算机验证推进一步！

tooseven

上一篇做了一个高度概括的风险评估和其控制程序的分析，如果不能理解其理念的人可能感觉有点假，大，空。就想新闻联播里说的一样，管理上访的工作也要有事前的风险评估，设置控制预案，其实想想新闻联播里说的是很有道理的关键要看你个人怎么理解。举例来说，你的小领导突然要你向你们公司最大的官汇报工作，这次汇报很重要，表现不好，你年底奖金就完蛋了，你说你是不是在汇报之前得好好想一想，我应该怎么汇报，大领导会问什么问题，我应该怎么回答，我是不是应该提前模拟演练几遍汇报的过程。这个过程就是一个风险评估和制定风险控制预案的过程。不谈假大空了来点实际的吧。
举个例子现在企业流行做ERP，也有叫MERP 还有 SAP的，东西都差不多。在药厂里面这个系统通常会包含一个业务流程就是“产品放行”。一般的技术水平，基本上就是人在计算机系统里做个产品状态的设定“放行”“reject 拒绝放行”“条件放行”，“hold住暂停放行”。这个过程基本没有自动化控制的就是说系统根据系统里的信息，系统自己判定产品是否放行。那我们对这一步做一个简单的风险分析的举例：
业务流程名称：
产品放行
失败的危害性（consequence）：高
危害那是相当的大，如果放行错误，会导致错误的产品流向市场，影响患者安全，可能会导致产品召回。（如果是生产无菌药品的企业比如注射剂的，危害可能还要考虑危害患者安全，比如不合格的产品放出去，有可能会死人的）
失败的原因
1.        硬件的错误：不适用
2.        软件的错误：错误的软件程序设计，比如设定产品状态为“reject 拒绝放行”，但仓库产品仍能正常出货发货。
3.        人的错误：1，没有资质放行的人做了错误的放行设定,2有资质放行的人做了错误的设定。
失败的可能性：（likely hood）
1.        硬件：不适用
2.        软件：低，可能行比较低。
3.        人的错误：中
风险等级：
1.        硬件：不适用
2.        软件：中等风险。
3.        人的错误：高风险
风险控制策略：
1.        硬件：不适用
2.        软件：A：设计确认；B：系统测试（可以理解为供应商在工厂安装调试完成以后做的SAT） C：用户接受测试(可以理解为OQ)
3.        人的错误：错误原因1：A，系统操作权限的控制（只有经过培训的人，有资格的人才能有系统放行操作的权限） B，SOP控制（确保放行的操作不是一个人完成的，要有双人的复核，避免个人的错误导致最后产品放行失败）
错误原因2 SOP控制（确保放行的操作不是一个人完成的，要有双人的复核，避免个人的错误导致最后产品放行失败）

没有用表格的形式，感性趣的人自己去设计表格吧！
从上面的分析过程基本上可以看出，风险评估就是根据计算机系统对你产品可能造成的影响进行了一个等级分类，并根据其发生的可能性进行一个等级分类，最后得到相应的风险等级。然后根据相应的失败的原因和风险等级制定相应的可行的控制策略。这个过程就是风险评估的过程。

这只是一个举例，具体的还是要看参与评估的人的知识和思想认识水平。危害性和可能性的判定是因人而异的，但是无论何种等级的风险，其最后都要落到相应的控制策略上，所谓的控制策略的具体形式，其实就是公司的质量管理手段例如“验证，培训，文件，SOP，培训，供应商审计………………”

抛砖引玉，大家评估一下自己的系统是不是做了相应的风险评估并制定了相应的控制策略！

tooseven

风险评估做完了，基本上整个项目所需的活动就知道的差不多了。因为针对不同的风险其控制策略基本已经明确，哪些需要验证，哪些要求应该体现在用户需求中以便供应商在设计上能考虑或者改进，哪些项目需要验证，哪些要求应该体现在工厂的SOP中以规范管理。
接下来的活动就是制定项目的控制策略和验证的计划。所谓的验证计划，就是把识别出来的控制措施，按照时间的先后顺序和计算机系统本身的项目逻辑和公司的管理程序做一个整体活动的安排。基本的架构就是，项目简介，目的，范围，系统概况介绍，项目的控制策略，验证活动的控制策略，验证过程的角色职责，验证交付物，验证成功的标准。
这个工作不是一个简单的工作，并不是所有人都能写出一个好的计划，需要很多方面的知识：要了解公司的质量管理流程，计算机系统生命周期的认识，计算机系统特有的质量管理活动和验证的理念把这些知识综合在一起才能写出一个好的验证计划。这个计划应该告诉项目团队，这个项目要解决什么问题，有哪些项目活动，这些活动执行的先后顺序和逻辑关系是什么，执行这些活动的过程中出了问题应该怎么解决，这些活动谁来做，要产生什么交付物，交付物的审核批准机制是什么，活动执行完成后，如何判定这些活动是符合要求的。

这个计划需要根据项目活动的进行及时回顾更新，如果计划前期评估的充分，各项活动计划安排的很好，符合项目的实际执行情况，也可以不升版。高手和新手的区别就在于，在项目还没有执行的时候，就知道整个项目需要做什么，先做什么后做什么，出现问题怎么解决。基本上可以分为三种人，第一种项目还没有开始执行就明白项目是怎么回事，应该怎么做，第二种边做边改，知道做完了才知道怎么回事，第三种，边做边改跟着别人把项目做完了，还不明白到底是怎么回事。
基于每个人都是认真做事的态度上，这三种人基本上是可以根据其知识和经验和思想水平的层次来划分的。往往是很多人既没知识，又没经验又没思想，如果态度不端正就变成了乱来了，计划执行的就有些盲目，常常会扯皮！这种人本不应该在项目团队中出现，但是往往组织中这种人是很常见的。参见我前面所说的电影 <十三罗汉>，如果这帮大盗纯粹就是，就为了成功以后为了“分赃”（项目成功后捞点受益），项目是很难成功的。

幻影

期待继续。

tooseven

现在看来前一章节的验证计划讲的有些过早，在此提个要求：在讲下一个章节的时候，要求大家自己研究一下一个课题“软件的生命周期”。否则，后面的讲述大家可能很难理解。
大家可以通过各种途径来了解一套软件从需求分析一直到最后停止使用，都是一个什么样的过程。如果大家了解了这个过程，基本上计算机验证就懂了一大半！我这么说的原因就是我前面所说的，计算机系统也是一个产品，只要是一个商业化产品就应有其相应的质量管理，药厂计算机系统的验证，无非就是增加了药厂的带有一些特殊法规要求的质量管理而已。仅此而已，如果你懂了SDLC，你就会明白，为什么我前面说的，民航，铁路，银行的系统也会做验证，只是他们不用验证这个名词而已。 大家在后面谈谈自己的研究完SDLC之后的感想，回复到100楼即开下一篇！

shj117

tooseven 发表于 2014-5-5 23:56
现在看来前一章节的验证计划讲的有些过早，在此提个要求：在讲下一个章节的时候，要求大家自己研究一下一个 ...

很不错的普及贴，但不知道你吧生命周期讲完了以后，你还会讲什么内容，期待 会是电子签名和电子记录吗？

tooseven

shj117 发表于 2014-5-15 17:18
很不错的普及贴，但不知道你吧生命周期讲完了以后，你还会讲什么内容，期待 会是电子签名和电子记录吗？

电子签名和电子记录不是制药行业计算机系统验证的核心，但是是必须考虑的内容。要想了解计算机系统怎么验证，必须要知道计算机系统是个什么东东，然后才能知道会对你有什么影响（也可以称为，哪些地方会有风险）。然后才能知道怎么去管理，然后才能知道怎么验证！逻辑就这么简单！前提是你要懂，什么是计算机系统，核心是SDLC，什么是法规的期望，什么是行业的good practice！

shj117

tooseven 发表于 2014-5-19 21:20
电子签名和电子记录不是制药行业计算机系统验证的核心，但是是必须考虑的内容。要想了解计算机系统怎么验 ...

呵呵，真不知道SDLH是什么，但是对于计算机化系统的验证，除了自动化控制系统，还有一些资源管理系统，像SAP，ERP，EDMS，系统，验证的过程相似，但侧重点截然不同，需要做的工作也就有很大的不同
只是拍拍砖啊，不必太认真啊！

tooseven

shj117 发表于 2014-5-22 21:05
呵呵，真不知道SDLH是什么，但是对于计算机化系统的验证，除了自动化控制系统，还有一些资源管理系统，像 ...

Software Development Life Cycle 软件开发的生命周期。整个GAMP5的理论都是围绕着这个生命周期进行了一个质量管理方面好的做法的总结。

shj117

tooseven 发表于 2014-5-22 23:34
Software Development Life Cycle 软件开发的生命周期。整个GAMP5的理论都是围绕着这个生命周期进行了一个 ...

呵呵   继续吧

snow200289

学习了，谢谢分享，期待继续

于磊

解析很透彻简单，计算机验证现在国内基本是空白，有也都是承包给国外公司来做！

fqlcjb2012

非常感谢，期待更多的分享

了了.

已收录蒲公英微信，持时发布，同时期待楼主的持续更新。再次感谢楼主。