PDA近期发布了TR 80《Data Integrity Management System for Pharmaceutical Laboratories制药实验室数据完整性管理体系》，详细描述了实验室数据完整性的监管趋势、实验室数据完整性控制的一般考虑点、微生物实验室数据完整性、分析实验室数据完整性、数据监管体系风险评估以及如何整改数据完整性缺陷。目前GMP办公室正在组织翻译，有兴趣的同行可以加入GMP办公室翻译组参与讨论。翻译校对完成后将于近期发出，敬请期待。以下是关于计算机化系统验证的几个问答，分享给大家参考：
Certificates of Software Validation or Capability:Do They Provide Value?
软件验证或能力证书：它们是否有用？
Many software vendors provide a Certificate of Software Validation, or they may issue a certificate along the lines of 21 CFR Part 11 Readiness Claims. Such a certificate has limited value, because the FDA expects the software to be validated for its intended use by the users in the environment where it will be used. While vendors should engage customers to build and design systems according to customer needs, and spend considerable time testing that software before they deliver it, the development and testing work does not (and cannot) substitute for the customer declaring their intended use and then validating their system according to that intended use.
许多软件供应商提供了软件验证证书, 或者发布一份符合 21 CFR Part 11的声明。此类证书的价值有限, 因为 FDA 希望该软件能够被使用环境中的用户用来验证其用途。虽然供应商应与客户合作根据用户的需求来构建和设计系统, 并且在交付之前花费大量的时间测试该软件, 但开发和测试工作并不能代替客户声明他们的预期用途, 然后根据预期用途验证其系统。
Another related point is that the FDA does not have legal jurisdiction over a vendor’s informatics software organization. So (unless the software is registered as a Medical Device with the FDA) any documentation that the vendor might provide cannot be recognized by the FDA because of that lack of enforcement authority.
另一个相关的问题是 FDA 对供应商的信息软件机构没有法律管辖权。因此 (除非该软件是注册为医疗器械的), 供应商可能提供的所有文件都不能被 FDA 认可, 因为缺乏执法监管。
Vendors may be able to provide detailed information about a product’s abilities relative to Part 11, but that information is based on the vendor’s interpretation of the regulations.This interpretation may or may not agree with various pharmaceutical manufacturers, or the FDA itself. The vendor’s interpretation cannot substitute for an audit to determine the software’s functional ability to satisfy regulatory concerns.
供应商应该能够提供有关产品符合Part 11的能力的详细信息, 但该信息是根据供应商对这些法规的理解而制定的。这种理解可能会与不同制药生产商, 或 FDA相同或不同。供应商的理解不能替代审计, 以确定软件的功能能力, 以满足监管的关注。
Question: When software is updated my, how much revalidation is required?
当软件更新时, 需要多少重新验证？
Answer: The FDA guidance: General Principles of Software Validation focusses on two points related to revalidation. First, changes to the system must be evaluated for their relative impact to the particular company’s intended use for the system. For example, instrument support functionality changes may not be related to a user’s particular instrument configuration or may reflect unused features. From the vendor’s release documentation, it should be possible to determine what features and functionality have been updated, and what defects in the software have been corrected. Any changes should be compared against the intended use to determine any revalidation impact.
FDA 指南: 《软件验证一般原则》与重新确认相关要求集中在两点上。首先, 必须对系统的更改进行评估, 以确定其对公司对系统的特定预期用途的影响。例如, 仪表支持功能更改可能与用户仪器的某一配置无关, 或可能影响无用的功能。应该从供应商的发行文档中确定哪些功能和特性已更新, 以及软件中的哪些缺陷已被纠正。任何更改都应与预期的用途进行比较, 以确定任何重新验证的影响。
Second, whenever software is changed, the user should evaluate the change themselves, including some degree of regression testing to confirm that the change in the software or the updated software has not broken something else in some way that may have had unintended consequences. It is not uncommon, for example, when updating software for home computers or phones to find that features that worked before the update may not work afterwards.
其次, 当软件变更时, 用户应该评估变更本身, 包括某种程度的回归测试（回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。）, 以确认软件的变更或更新没有以某种方式破坏其他东西而导致意想不到的后果。这一点其实并不少见，例如, 在更新家用计算机或电话软件时，确认在更新之前的功能是否在更新之后失效。
Question: When a new PC is implemented, is it necessary to revalidate the software?
在使用新的 PC 时, 是否需要重新验证软件？
Answer: If the new PC has the same or greater capabilities than the original and is using the same version of the operating system and software, revalidation is not necessary since the functionality of the system is the same. However, repeating the installation qualification activities to confirm that the software has been properly installed or restored properly from the backup onto the new PC is required.
如果新 PC 的功能与原始计算机相同或更大, 并且使用相同版本的操作系统和软件, 则无需重新验证, 因为系统的功能是相同的。但是, 必须进行安装确认以证实软件已正确安装或从备份位置正确地恢复到新 PC 上。
One detail that can make this process more efficient is to avoid overly detailed specification documents. Avoid specifying
a particular model of PC, particular processor speed, or a particular memory or disk capacity. Use of the designation “or higher” will prevent having to continually update the documentation as technology advances.
一个可以使此过程更高效的细节是避免过于详细的规范文档。避免指定特定型号的 PC、特定处理器速度或特定内存或磁盘容量。使用指定 "或更高" 将防止在技术进步时必须不断更新文档。
Question: How can I ensure and prove that SOPs are followed?
我如何确保和证明 sop 得到遵循？
Answer: Through audits. Audits are the only way to follow up to make sure that people are doing what they have been trained to do.
答: 通过审计。审计是跟进以确保人们在做他们已经被培训做的事情的唯一方法。
Question: How do you deal with automatic updates of Windows or antivirus programs?
如何处理 Windows 或防病毒程序的自动更新？
Answer: Another item the FDA has started discussing more in the last few years, in conjunction with the ISPE GAMP v5 Guidance, is the concept of risk and risk-based validation. One of the things to think about with operating system and antivirus updates is the relative risk of having e.g. a security problem or a virus vulnerability in a system. Sometimes the update risk may be greater than the original risk to the system itself (or vice versa). Some companies have the luxury of staff to deal with networks and server infrastructure qualification and can insulate operating systems from the software validation itself, having the responsibility to make sure that the systems are being kept current with security and antivirus updates. As a general practice companies should periodically run a small set of standard regression tests, triggered by operating system or antivirus updates or simply on a periodic basis, to make sure that changes do not have any adverse impact on the system.
FDA讨论在过去几年中开始更多讨论的另外一个项目, 结合ISPE GAMP 5 指南, 是风险和基于风险的验证的概念。与操作系统和防病毒更新一起思考的一件事是, 在系统中有安全问题或病毒漏洞的相对风险。有时, 更新风险可能大于系统本身的原始风险 (反之亦然)。一些公司拥有大量负责确保系统保持最新安全和防病毒更新的员工来处理网络和服务器基础设施的确认, 并且可以将操作系统与软件验证隔离开来。通常情况下, 公司应定期运行一小套标准回归测试, 在操作系统或防病毒更新之后或简单地定期进行, 以确保这些变更不会对系统产生任何不利影响。
Question:What is regression testing?
什么是回归测试？
Answer: Regression testing is a way toconfirm that featuresworkingprior to any change are still working. Regression testing should involve eitherthe most commonly used functions in the system and/or the most high-riskfunctions determined during risk-analysis to determine whether or not aparticular software update has changed something not directly addressed in thevendor’s documentation. That is to confirm that the system itself has notregressed or that a change has not introduced some kind of an unintended failure.
答: 回归测试是确认功能在任何变更之后仍然在工作的一种方法。回归测试应包括系统中最常用的函数和/或风险分析确定的最高风险函数, 以确定特定软件更新是否更改了未直接体现在供应商文档中的内容。这是为了确认系统本身并没有倒退, 或者变更没有引入某种意想不到的失败。
8月1日起强制实施：欧盟计算机化系统验证指南
近期发布的欧盟计算机化系统验证指南，将于2018年8月1日强制实施，该指南由一个计算机系统验证的核心文件和2个附件（EXCEL表格的验证和验证复杂的计算机系统）组成，即：
此验证指南将不同的计算机系统验证进行了分类：
定义
举例
措施
豁免
没有校准功能
框架/分层软件
计算器，显微镜，照片或摄像机，标准办公电脑，微波炉等。
操作系统（例如Windows，Linux，Unix），网络软件，安全软件（病毒检查，防火墙），办公室应用软件（Word，Excel），数据库软件（例如Oracle，SQL，Access）等
无
简单
小部分软件
受限定制
pH计，氧化器，培养箱，滴定仪，比色计，温湿度计/湿度计，天平，粒度仪，紫外/可见分光计，液体闪烁计数器，TLC分析仪，AAS，微平板计数器，图像分析仪，旋光仪，CombiStats等
简化验证
- 校准
- 功能控制测试
复杂
额外的功能软件
扩展定制
LIMS（实验室信息管理系统），ERP（企业资源规划），eDMS（电子文档管理系统），ELN（电子实验室笔记本），用户开发的Excelspreadsheet，用户开发的Access应用程序，自动化样品处理系统，液相色谱仪（LC，HPLC），气相色谱仪（GC）包括自动进样器和检测系统（紫外，可见光，红外，质谱，核磁共振，放射性或荧光监测等），生物分析仪，心电图等。
验证
备注：操作系统，办公应用程序，数据库和框架软件包（如Windows，Excel，Oracle，SAS）不必由OMCL验证。 但是，使用这些软件包内部或通过这些软件包写入的应用程序，例如SAS过程，ORACLE应用程序和Excel电子表格（包括复杂的计算和宏）应该被验证。
GMP计算机系统验证现状浅析
从接触新版GMP至今，亲自实操的计算机化系统的验证(要集中在BMS/EMS)已有好几个了。再加上见到和了解到的其他人员或厂家的模板或操作，前后也有好几十个了。说实话，虽然大多都声称符合21 CFR Part 11，按照GAMP5走的，但真正严格按照计算机验证做到的，在我看来只有1个案例，可见其比例之低。
下面就我个人理解谈谈造成当前此种局面的原因。
说到计算机系统验证就不得不说说GAMP5，看到很多业主URS都写着要符合GAMP5或者按着GAMP5做。估计写的人自己也没搞明白什么叫符合GAMP5。这里有2个错误。首先，GAMP5不是法规要求的标准，没有法律约束力。第二，GAMP5更多的是将计算机系统的一个生命周期的活动如何开展，比如如何定义，开发，测试，调试，确认，培训，维护，退役等。
到处讲课的专家们大都是大谈特谈人人都查得到的分类表，可增减的Vmodel，黑盒白盒测试，审计追踪等内容，往深了谁都不谈，具体怎么做也都绕开不说。我们日常的验证大多只涉及到调试和确认，培训，其他的都无人提及或少提及，甚至能把调试确认和培训做好就不错了。
其实计算机系统验证难就难在软件，如软件系统的开发，测试，培训，操作，维护之类的。比如，开发者应有完整的质量管理体系(这一条就否定了大多数BMS/EMS供应商，为什么要求他们有完整的质量管理体系这个道理应该不用我说了吧)，在开发过程中要保留一系列的文件来证明开发和测试能证明软件是安全稳定的。
开发结束后的现场安装和调试，以及调试后的确认(如何确认的问题？)同样证明系统是安全稳定的。那么自然需要对系统进行详细的测试，如硬件方面的部件详细参数确认、部件连接确认、部件安装质量确认，仪表计量确认等，软件方面，如画面确认，各页面配置导航确认，安装是否正确确认等。以上测试完成后就进入运行确认，要证明硬件在软件的控制下是否能按照预期运行并达到预期效果的一类确认，如系统启停、用户密码安全、输入输出确认、报警功能确认、审计追踪确认，报告打印、备份和恢复确认、存档与检索确认、故障(软件、硬件、供电、通讯等)与恢复确认、功能确认等。
做这些确认并不难，难是难在现在的制药行业的很多计算机化系统是一个定制化的小众市场，由于各个药企的系统LIMS/QMS/DMS/BMS/EMS各不相同，系统规模不是很大，专业的软件开发公司并未介入太深，导致既没有现货产品可买，又没有实力强劲的软件开发公司进行严格的开发测试，即使有，也会由于项目的成本，时间，人力及规模而不可能实现满足GAMP5的整个生命周期的计算机化系统的验证。
说白了目前的医药计算机化系统规模小，而这类系统本身又因为多是定制化的系统，工作量一点不少，对于专业的软件公司来说根本不划算，对于业主来说又不愿花太多钱，那所以工程公司或信息技术公司的介入来填补空白，但工程公司没有软件开发资质和开发管理体系，信息技术公司又没有GMP概念和计算机系统验证经验，那结果可想而知，所以就造成了当前尴尬的局面。想做好的话，却发现整个开发过程都没有相应的支持材料来证明开发过程是受控的，开发结果是正确的。所以，自然就写不出好的QPP，URS，FS，HDS，SDS，NDS，无法进行代码或配置测试或确认，即使有，也仅是侧重于硬件的，针对系统功能或后补的东西。
只有具备完整的QMS，整个开发过程是受控的，且留有完整的文件资料的软件开发和配置过程才是可以验证的。当前的很多环境是开发，测试，运行环境合在一起，也即供应商在你将来使用的环境里进行开发和测试，测试完成就交给你运行。根本没有所谓的软件设计，如画面，颜色，画面内容，内部逻辑关系，软件功能等，边施工边开发，FS，HDS，SDS，NDS要么是不够详细，要么就是开发完了再重新起草，而且还不全。
造成以上问题的另一个原因是项目时间紧，费用低，业主对计算机系统不够专业，大家都想要好的东西，但不舍得投入，而且也不知道投入多少是合理的，所以导致了当前计算机验证市场的无序。
计算机系统验证难就难在那一堆SOPs，那一堆开发过程的策划、实施、过程和结果记录文件的提供，和操作维护手册、系统更新升级SOPs，系统断电恢复SOPs，备份和恢复SOPs，存档与查看SOPs，报告打印SOPs，系统退役管理SOPs，机房管理SOPs等等系列的支持这个计算机化系统稳定安全运行的SOPs。难就难在供应商和业主是否在其生命周期内对可能影响系统稳定和安全的方方面面都做了详细的规定和测试，都有相应的支持资料来告诉操作者该怎么做，怎么记录来证明其是按照要求做的。这是难点。这不是一般的信息技术公司可以完成的，也不是3，2个技术人员，极低的费用和很短的时间就能完成的。
造成当前这种局面的根本原因就是，我们在偷换概念。GAMP5是针对整个生命周期的，而不是仅针对调试确认的，GAMP5侧重于软件，侧重于对开发过程的控制。计机验证不是简单的对操作现场的系统进行一些简单的功能测试，也不是在这里进行代码，配置审核，对于代码配置这些内容的确认应在系统开发过程进行，应用开发过程文件来证明。完工后再去做这些开发过程的确认只有一个结果，那就是造假。所以，我们在最后确认时为什么只能对安装功能进行简单的确认的原因。
再说说软件分类，很多人到现在也没搞清楚1，3，4，5类软件的分类。这个都搞不清，自然更搞不清不同类别软件所应进行的验证。其实除了这个分类，在USP仪器确认章节中将软件分为固件系统，利用硬件仪器来实现其功能的系统和纯计算机系统3类。又有人将计算机系统分为A-stupid傻瓜化的系统，只能进行设定，不能打印和记录，所有数据都需要人工记录，如传递窗，B-能设定，但不能储存记录，只能当时打印的，如带打印机的天平，C类-可设定并储存记录的智能化系统，如HPLC。还有根据对产品质量或数据影响的程度，产品复杂程度，供应商熟悉程度，供应商的能力水平，同类产品的使用经验(如同规格同型号同品牌产品的再次购入)，产品是现货商用产品还是定制产品等进行风险分析，然后形成一个有针对性的开发测试计划。活学活用，这才是一个有针对性的开发测试确认，而不是只要是3类系统我们就千篇一律的做同样的事情。
比如我们遇到一个从未有合作经验的供应商提供的3类软件，肯定会加严控制，还要起草一系列的SOPs来支持系统，而一个已经有合作经验的供应商就完全不同了，如车间再从熟悉供应商处再购买一台同规格型号的设备，那么很多SOPs都直接使用前面已有的SOPs即可，人员也无需进行太多培训即可上手，开发过程可能只需要确认下对方是否都有确认文件及测试结果都即可，这就是一个的基于科学的风险分析基础上的简化版的3类软件的验证。即节省了人力物力财力和时间，同时又没有因此降低质量体系的保证程度。
再说说Part11，其实Part11就是电子记录和电子签名这两条。以BMS系统为例子，现在有的公司有满足审计追踪要求的BMS系统，但是因为日常控制达不到那么好的程度，又不想暴露出来给检察官看。于是都说有了EMS系统作为直接影响系统来验证并提供GMP数据，把BMS系统化为间接影响系统。这个做法其实有很大的法规风险，第一BMS毕竟控制着HVAC的运转，HVAC系统是直接影响系统，BMS系统按理讲应该算作其操作系统自然也应归为直接影响系统，也应验证，并满足part11的规定，提供GMP数据。另外，即使你有了EMS系统用于GMP申报检查，BMS系统即使不具备审计追踪功能，但也应有人工文字记录并保留系统的电子记录做参考。所以BMS系统严格意义上是无法绕过验证这道坎的。
总结，要想做好计算机系统验证，就应该选好供应商，就应该对加强对开发过程的控制，就应该将眼光放到整个生命周期的运行维护的可操作性，而不是仅仅局限在简单的几个功能的确认，更不能将所有的事多交给供应商就完事。业主也应该积极的参与进来，提出从操作、维护、日常管理、升级、数据存储、检索、备份、系统退役等各方面的需求，借助于供应商的专业能力将这些需求技术化，制度化，最终形成支持计算机系统整个生命周期内安全稳定运行的SOPs。
来源：制药工程论坛
