|
随着自动化和信息化水平的提供，制药企业使用的自动化和信息化系统逐渐变多。相比以往人工管理有了更好的标准化及规范化保证，同时也减少了人为失误带来的有意或无意操作的成本和质量风险。但是，软件运行出现故障需要修复是一件经常遇到的事，而制药企业作为一个高监管行业，承载着大众的生命健康安全，在软件修复方面尤为谨慎。同时，因为成本和运行的压力，也给软件修复工作带来的一定的疑惑，主要表现在以下方面： l 软件故障是否属于偏差，是否需要按照偏差流程处理？ l 有些修复需要立即进行（如涉及安全或者正在生产的产品），是否有流程支持？ l 修复后软件如何验证？ l 修复后软件切入生产环境无法运行或者产生新的问题。 一、软件故障是否属于偏差 按照GAMP5描述，软件故障不完全是偏差，但是可能影响产品质量和患者安全的事件（故障）需要汇报质量部，以确定是否需要按照偏差管理流程处理。所以建议单独建立计算机化系统事件和问题管理流程，以进行评估是否涉及GXP影响和快速解决非GXP影响的事件故障。具体可以参考本公众号其他文章。 二、是否有流程支持立即修复 1.GAMP5描述对事件故障进行三级支持，具体如下： “第1 级支持通常由IT SME 提供，通常是帮助台的工作人员。1 级支持团队收集描述事故的信息。1 级支持进行基本调查和故障排除，并解决常见问题，如访问问题、解决方案理解、设置问题、服务恢复等。 2 级支持对事件进行更深入的评估，并确定解决问题的可用解决方案。第2 级支持通常由服务台工作人员之外的IT SME 提供。如果没有可用的解决方案，则会提出问题并提交给第3 级支持人员进行进一步调查和技术解决。 3 级支持由SME 提供，如开发人员、开发/运营(DevOps)、架构师、工程师或外部软件或IT 服务供应商。第3 级支持调查潜在的设计和实施问题。可能需要技术解决方案来解决问题。 重大事件与业务运营的严重中断有关，应更加紧迫地解决。可组建一个重大事件团队，包括适当的业务、技术和质量专业知识来管理事件。可能需要调用业务连续性和灾难恢复计划。” 2.2010版GMP附录《计算机化系统》：“第二十条企业应当建立应急方案，以便系统出现损坏时启用。应急方案启用的及时性应当与需要使用该方案的紧急程度相关。例如，影响召回产品的相关信息应当能够及时获得。 第二十一条应当建立系统出现故障或损坏时进行处理的操作规程，必要时对该操作规程的相关内容进行验证。包括系统故障和数据错误在内的所有事故都应当被记录和评估。重大的事故应当进行彻底调查，识别其根本原因，并采取相应的纠正措施和预防措施。” 从法规和指南角度看，是支持在故障时进行应急方案，来支持业务的恢复，但是对于故障处理过程应该全部由记录和评估。但是，这里重点是要进行业务的修复而不是软件修复，如某个流程卡死了，检查发现软件某个服务停止了，进行软件服务重启以进行业务继续进行；但是软件服务为什么停止，需要进一步调查，如果是软件运行问题可能就需要进行软件修复。 当然，对生产类系统可能涉及到紧急维修，这个时候是无法按照规定的流程进行审批的，也要有应急预案，ISPE 《Risk based approach to GXP process control systems》描述“当无法遵循标准流程时，可能需要进行紧急维修，例如在周末和节假日。应定义基于风险的过程来指导行动，特别是在需要紧急维修的时刻(例如，从指定的质量代表处获得电话批准并记录对话)。随后，应充分审查、记录、验证和及时批准执行的维修。由于意外后果的可能性很高，紧急维修应由支持组织的高级成员执行，他们应全面了解PCS及其所支持的过程” 三、修复后软件如何验证 软件修复站在GAMP5角度看，属于问题处理的板块，也就是 软件修复从口语化来讲，可能包括配置修改、操作系统层面的设置等；但是从严格定义上来讲，应该属于软件产品层面的修改，属于代码层面的动作，也就是大家闻之色变的“5类软件”。但是既然是修复，就是少量或部分模块的修改，而不是整个系统所有业务的定制，所以其修改部分应该遵循定制软件的验证管理策略。定制模块可能作为配置项进行配置管理和配置测试，也可能嵌入到标准软件；具体可以参考本公众号关于定制软件验证的内容。因模块的改变，可能会影响其他业务流程，所以验证不能简单的考虑修复后模块的测试，还需要考虑关联模块的UAT回归测试。 四、修复后软件切入生产环境无法运行或者产生新的问题 尽管进行了严格的测试，但是有时候还是会产生一些不如意的事情，如软件无法运行或产生新的问题。这个可能会在近期或运行很长一段时间后出现，所以对软件的配置管理、回滚策略和灾难恢复流程充分，在出现问题时，可以及时的回滚到上一版本的配置是非常重要的，也可能为下次事件的修复手段之一。变更与配置管理可以参考本公众号其他文章。 五、软件修复流程图 尚未发现相关指南推出软件修复流程图，本文根据指南内容编制简单流程图供参考，不足之处还请留言沟通。  总结，对于软件的修复严格定义是产品层面的修复，而对于操作系统设置和配置修改可以口语化称呼为软件修复。通常软件修复是问题处理阶段实施，事件故障发生时优先考虑业务恢复；对于特殊情况的紧急修复可以不一定要按照既定的规程实施，可以按照日常的紧急方案实施，但是需要得到质量部的同意，这块可以在相应事件或偏差管理SOP中规定清楚。软件层面的修改涉及到定制即5类软件验证的，可以参考本公众号其他文章进行验证。软件修复前均需要进行配置项的记录和备份，以便环境失败的回滚，在最终验证放行后，还需要对原配置项进行备份保存，以防止后续问题的回滚。 |
|
|
