FDA 质量案例
FDA 器械和放射健康中心 （CDRH） 于 2011 年启动了 Case for Quality 计划，专注于生产高质量医疗器械的方法。在该计划期间，CSV 被确定为一个瓶颈，执行起来既繁琐又昂贵，例如：
当软件是从知名供应商、行业软件领导者或具有质量认证的软件提供商处购买时，不给予任何对价或确认。
客户现场的重复工作是常见的做法，也是一个重要的问题。
CSV 被视为追求自动化的主要障碍。
由于感知到的监管负担，CSV 的重点是为审计师收集书面证据，而不是测试和确保软件按预期工作。2015 年，FDA 成立了一个联合机构和行业团队来调查和评估替代方法。结果是计算机软件保障 （CSA）。
FDA CSA 指南：等待 Godot？
FDA 承诺在 2018 年为行业提供指南草案，但没有任何结果。这种真空允许一些行业团队成员通过消息 CSV 已失效，您必须过渡到 CSA 来推广 CSA。这导致了通过展示和发布进行“监管”，因为没有什么可以交叉引用这些主张。在指南草案发布之前，GAMP 论坛在良好实践指南 （GPG） 数据完整性设计附录 S2 中加入了 CSA，22 在 GPG 促进创新中加入了关于批判性思维的部分24，并在 GAMP 5 第二版12 中加入了 CSA 测试方法。FDA 指南草案最终于 2022 年 9 月发布，标题为《生产和质量体系软件的计算机软件保证》25。
本文将重点介绍制药行业受监管 GMP 实验室的 CSA。有关医疗器械 CSA 指南草案的详细和批判性审查，请阅读 Ozan Okutan 的优秀评论，可在 LinkedIn.26 上获得。
CSA：应许之地
在 FDA 指南草案发布之前，CSA 的主要原则被吹捧为对 CSV 的范式转变，包括：
专注于预期用途：定义软件的预期用途。
使用批判性思维：与其编写大量测试文档，不如使用批判性思维来集中测试。
允许无脚本和临时测试：测试脚本过于详细，包含点击级别的指示，经常运行到“数百页”，花费大量的时间和精力 - 并且由于其规范性，导致测试脚本偏差。典型的 CSV 计划拆分，其中 80% 的偏差是由于测试人员或测试脚本错误造成的，其中 20% 实际上是检测和解决功能错误。然而，似乎没有任何支持持证据支持这一说法。可能的原因可能是测试自定义软件而不是商业软件，或者测试人员没有接受过培训或不熟悉其操作的新应用程序的实施。
使用受信任的供应商：当软件是从知名供应商、行业软件领导者或具有质量认证的软件提供商处购买时，不会给予任何对价/确认。客户现场的重复工作是常见的做法，也是一个重要的问题。
证据应增加价值：大多数证据包括测试过程的屏幕截图或纸质打印件。这会减慢测试过程。
使用自动化：为了帮助软件开发和测试，请使用自动化测试工具。
软件验证的一般原则：查看基线
在我们开始审查 CSA 指南草案之前，我们需要考虑 CDRH 和生物制品中心于 2002 年发布的 FDA 指南软件验证通用原则 （GPSV）13。这构成了我们讨论 CSA 的基线，也是 CSV 过于繁琐的说法的核心。对于制药行业，有 GAMP 5 第一版和第二版11,12 以及实验室计算机化系统验证良好实践指南第二版和基于风险的系统测试第二版27,28。
GPSV 的结构如图 1 所示。在目录中，第 2.3 节的标题，以粗体大写字母打印，THE LEAST BURDENSOME APPROACH。该部分简单地指出，这应适用于医疗器械监管的所有领域。简单地说：根据需要进行尽可能多的验证，但不要再多，正如 Section 4.8 中重申的那样。大多数公司都忽略了这个建议。
图 1：FDA 指南软件验证的一般原则的结构。13 来源：Bob McDowall。
图 1 以绿色显示了 GPSV 的第 3、4 和 5 部分，它们是处理软件验证的指南的主要部分。第 4.8 节中是一个关键点：验证覆盖率应基于软件的复杂性和安全风险，而不是公司规模或资源限制13。
下面列出了这些部分的关键部分的摘要。
第 3 部分 软件验证的背景：需求和规范、验证和确认、作为系统设计一部分的软件开发、软件验证的好处和设计审查。
第 4 节 软件验证的原则：需求、缺陷预防、软件生命周期、计划、程序、更改后的软件验证、验证覆盖率、审查独立性以及灵活性和责任性。
第 5 节 活动和任务：软件生命周期活动，支持验证的任务：质量规划、需求、设计、构建或编码、软件开发人员的测试、用户站点测试、维护和软件更改。
您会注意到这三个部分中都有需求特征，这就引出了一个问题，为什么定义预期用途被称为一项新颖的 CSA 任务？事实上，GPSV 第 5.2.2 节指出，没有要求就无法验证软件13。该指南主要针对用于其生产和质量体系的医疗器械和软件。因此，由于供应商将参与其中，因此需要对这些原则进行一些解释：验证任务将在两者之间分配。这就是第 6 节的用武之地。
图 1 以红色显示了第 6 节，重点介绍了自动工艺设备和质量管理体系软件的验证。它还为制药行业 CSV 提供了一些很好的指导。验证市售软件第 6.1 节提供了市售软件的验证和升级示例：…谁选择不使用供应商提供的所有软件功能，只需验证将使用的那些功能，并且设备制造商依赖于软件结果作为生产或质量系统的一部分13当软件升级或对软件进行任何更改时，设备制造商应考虑这些更改如何影响软件的“已使用部分”，并且必须重新确认对已使用软件的那些部分的验证13总结：这很容易理解。采用基于风险的方法来解决自动化操作和软件复杂性。定义用户对自动化流程的依赖级别并建立用户需求。了解并记录您对所用软件功能的要求，确定所需的控制措施，并根据这些控制措施测试配置的应用程序。升级应用程序后，显示系统继续像以前一样运行。
指定预期用途要求第 6.2 节侧重于现成软件，强调了用户规范对于定义自动化系统或软件的预期用途的重要性。重申，第 5.2.2 节对此进行了强化，该节指出，如果没有预先确定和记录的软件要求，则无法验证软件13。此外，《质量体系法规》29 的序言注释 136 至 21 CFR 820 显示，FDA 纳入了对 21 CFR 820.70（i） 进行修改的反馈，以便生产和自动化系统中使用的软件必须针对其预期用途进行验证 。它在法规中！FDA 在 2018 年的数据完整性指南问题 4 中进一步提出了一点：如果您验证了计算机系统，但没有验证其预期用途，则无法知道您的工作流程是否正常运行19。这些对软件预期用途的现有引用引出了一个问题，为什么 FDA 行业工作组没有阅读 QSR 法规和 GPSV？利用供应商开发和测试第 6.313 节中提供了有关利用供应商材料的进一步验证建议：如果供应商可以提供有关其系统要求、软件要求、验证过程和验证结果的信息，则医疗器械制造商可以使用该信息作为其所需验证文档的起点。供应商的生命周期文档（例如测试协议和结果、源代码、设计规范和需求规范）可用于确定软件已经过验证。
审计应证明供应商对 OTS 软件执行的验证和确认活动的程序和结果对于使用该软件生产的医疗器械的安全性和有效性要求是适当且足够的13。此信息完全驳斥了 CSA 的说法，即供应商开发和测试工作被忽略，工作被复制。自 2002 年以来，GPSV 一直在利用供应商的工作。药品和保健商品监管局 （MHRA） 在 GXP 数据完整性指南的第 6.19 节中添加了一个警告：不接受供应商提供的验证数据，而将系统配置和用户的预期用途分开18。因此，您可以将供应商的软件开发和测试纳入您的验证工作中。但是，由于供应商不知道您将如何使用该软件，因此这只是 MHRA 声明所加强的整体工作的一部分。18 最终用户负责在受监管环境中使用的任何软件的整体风险管理和验证。这与制药行业的任何 GXP 法规一致。
GPSV 摘要第 6 节提供了有关定义系统的预期用途、验证商业软件和利用供应商工作的有用建议。由于第 6 节很有用，为什么 CSA 强调定义软件预期用途的重要性是一个谜，尤其是当它已经出现在适用的质量体系法规和 GPSV 中时？总之，GPSV 包含以下针对 QMS 和自动化软件的建议13：您必须记录系统的风险分析和预期用途：软件和分析仪器。您只需验证您使用的商业应用程序的各个部分。如果升级，请确保您使用的应用程序部分与以前一样运行并保持控制。您可以将供应商的开发和测试作为验证的一部分。简单！但是你读过并实施过吗？可能不是！2022 年 CSA 指南草案的发布终于，在 2022 年 9 月，Godot 来了！CSA 指南草案已发布以征询公众意见。25 CSA 指南草案的结构如图 2 所示。阅读它时，人们会惊讶于 CSA 的支持者所说的与指南草案中的内容之间存在巨大差距。
