图 2： 《计算机软件保障指南》草案的结构。25 来源：Bob McDowall。
CSA 指南仅取代 GPSV 第 6 节
首先，也是最重要的一点，CSV 并没有消亡！CSA 指南将补充 GPSV 并替换第 6.25 节的 5 页，因此，CSA 是 CSV 的子集，不得用于医疗器械软件的验证。CSA 和 CSV 并行存在。由于它们并行存在，因此您至少可以期望它们不会相互矛盾。事实并非如此。
前面讨论的 GPSV 第 6、13 节中包含非常好的建议，如果完全替换为 CSA 指南的最终版本，这些建议可能会丢失，从而使问题变得更加复杂。
FDA 尚未说明将如何替换 GPSV 第 6 节。最好更新并重新发布完整的 GPSV，将 CSA 的剩余部分合并到一个文档中。或者，将其替换为两个指导文件（医疗器械软件和 QMS 和生产软件）26（O. Okutan 个人通信）。
CSV 和 CSA 定义：软件还是系统？
软件验证和计算机软件保障的定义如表 1 所示。 第一个问题是两者都指软件而不是系统。计算机化系统的定义包括受控功能，由软件控制的仪器和经过培训的用户组成，如 PIC/S PI-011,14 的图 1 所示，这似乎已被两个 FDA 指南的作者遗忘。如果没有经过培训的用户操作程序和控制分析仪器，就无法操作计算机化的实验室系统。
比较这两个定义：
两者都提到了预期用途
只有 CSA 提到这是一种基于风险的方法，尽管风险评估嵌入在整个 GPSV 中
GPSV 寻找操作的一致性
GPSV 需要客观证据
CSA 只需要置信度（指南中未定义）。
虽然存在差异，但这两个定义的目标似乎相似。然而，令人担忧的是，CSA 的置信度削弱了 CSV 所需的客观证据。然而，客观证据并不明示或暗示地需要堆积如山的纸张和屏幕截图;对于实验室系统，它将包括电子记录，包括上下文元数据。GPSV 第 6.1 节指出，所需的证据与软件和自动化流程带来的风险成正比。13 第 5.2.6 节加强了这一点：用户站点测试应遵循预定义的书面计划，其中包含正式的测试摘要和正式验收记录。应保留所有测试程序、测试输入数据和测试结果的书面证据13。
计算机软件保障风险框架
CSA 风险框架由第 137 行至第 602 行的四个阶段组成，构成了指南草案的大部分，25 以下编号的小节引用了指南中的内容：
A. 确定预期用途：为什么定义预期用途甚至被认为是 CSA 的一种新颖方法？
如表 2 所示，自 1978 年以来，制药法规中一直在定义设备和计算机化系统的预期用途 21 CFR 211.63,1 自 2011 年以来，欧盟附录 115 第 4.4 条和 GPSV.13 第 6.2 节
没有什么新奇的，因为它是预期的验证成果。然而，CSA 指南草案中的第 182-183 行和脚注 5 使用了术语 feature、function 和 operations，但未能准确解释它们的含义。25 参见 Oku tan 的评论中的第 4.3.1 章，该章试图解释这三个术语26。
但是，GPSV 和 CSA 指南均未提及使用过程知识、过程改进/重新设计或 MHRA 要求的数据完整性风险评估。18 过程重新设计将在后面讨论。
direct 和 support 软件。前者必须根据 21 CFR 820.70（i）29 进行验证，但支持软件的风险较低，并且可以使用 CSA 方法。这是与验证所有软件的 QSR 和 GPSV 的矛盾13， 29。
FDA 建议对所采取的方法的所有决策都记录在案。25 附录 11 第 1 款的措辞更好：作为风险管理系统的一部分，关于验证程度和数据完整性控制的决策应基于对计算机化系统的合理和记录在案的风险评估5。
确定基于风险的方法：对于风险较低的软件，FDA 声明其风险与与医疗器械软件相关的风险不同，ISO 14971：201930 中的风险评估方法不合适。
一个。CSA 指南草案建议用户应考虑可能影响或阻止软件按预期运行的因素，例如正确的系统配置和管理、系统安全性、数据存储、数据传输或操作错误。25 关于质量风险管理的 ICH Q9（R1） 提供了 FMEA 的替代风险评估方法31。
该指南通过示例将过程风险分为二元高和不高，然后指出过程风险在一个范围内 （！？预期用途要求是评估风险的输入。27 这需要 URS 包含足够的详细信息，因为实验室系统通常不需要功能规范，而是需要配置规范。然而，自 2011.5 年以来，整个系统生命周期的风险管理一直是附录 11 第 1 条的要求。
确定适当的鉴证活动：此处的重点是测试软件，包括：
无脚本测试：基于 ISO 29119 的软件测试32 ，有临时测试、猜测错误和探索性测试，不需要大量文档。请注意，无脚本测试并不意味着无记录测试，D 部分 Establishing the Appropriate Record 中列出了记录要求列表。25 探索性测试将在后面讨论。
脚本化测试：FDA 的一个术语，分为稳健的脚本化测试和有限的脚本化测试。稳健的脚本化测试包括可重复性、需求可追溯性和可审计性的证据。25 在制药环境中，如果实验室必须符合附录 11 第 4.45 条中的可追溯性要求，这是唯一的选择，如表 2 所示。但是，有一些方法可以简化测试执行指令，并且仍然符合可追溯性和强大的脚本测试，稍后将讨论。
建立适当的记录：在间接引用 GPSV 中的“负担最小方法”时，CDS 提到鉴证活动的文档不需要包含超过必要的证据，以证明软件特性、功能或操作按照所识别风险的预期执行25。
有一张表格比较了每项鉴证活动所需的不同证据，以及一个探索性测试的工作示例。后者的问题在于，电子表格经过测试，这并不是在 GMP 监管环境中使用的最佳示例。25 季度升级的 SaaS 应用程序将是一个更有趣的选择（Eva Kelly，个人通信）。
自动化可用于 CSA 工作。自 2011 年以来，附录 11 第 4.7 条允许使用自动测试工具：自动测试工具......应该有记录的评估是否充分。5 请注意，评估不是验证。
CSA 指南指出：作为一种负担最少的方法，FDA 建议使用电子记录，例如系统日志、审计跟踪和软件生成的其他数据，而不是纸质文档和屏幕截图，以建立与鉴证活动相关的记录25。
同样，正如 GAMP 5 第一版第 8.5.3 节所述，这又是似曾相识的：系统可能具有审计跟踪，可以捕获传统上由屏幕打印捕获的大部分信息。如果存在这样的审计跟踪，并且是安全的，并且可供 SME 审查，则可能不需要捕获其他证据。11 此外，在 GAMP 5 第二版第 25.5.3 节中，它指出，在许多情况下，多产的屏幕截图不会增加价值，而且是不必要的。12 审计跟踪仍然需要验证以证明该功能有效。
