第二部分 — 文献：领域现状

文献综述一：开源软件的风险导向验证

这个领域首先解决的问题是如何在受监管的环境中看待开源软件—— 而历经十余年打磨的答案是：基于风险的评估。本章回顾这条研究脉络， 因为它的概念是此后一切内容所预设的语汇。

奠定框架的白皮书

最具权威性的表述是 R Validation Hub 的白皮书 A Risk-based Approach for Assessing R package Accuracy within a Validated Infrastructure (Nicholls、Bargo、Sims 与 R Validation Hub,2020)。它的思想架构经受住了时间的考验：

• 把基础设施与软件分开。 环境验证(服务器、操作系统、运行时) 遵循 GAMP 变更控制之类的标准实践；白皮书的主题是在已验证的基础设施 之内评估软件包的准确性。
• 按与用户的关系分类，而非按依赖距离。 用户实际加载的软件包—— Intended for Use——需要接受风险评估；传递性的 Imports 只需 从可复现性角度加以管理。仅此一个区分，就把一棵无从下手的依赖树 压缩成了一个可处理的审查面。
• 用四条标准评估：用途(统计类软件包风险更高，因为它们的缺陷 藏在数学里)、维护的良好实践、社区使用情况，以及测试。度量指标 输入给一位合格评估者与一位合格复核者的主观判断——这是刻意为之， 因为一个不透明的汇总分数会掩盖审计师需要看到的判断过程。
• 按比例响应：低风险的软件包无需整改；高风险的则配以与需求 挂钩的测试；假以时日，作者与软件包集合可以赢得"可信资源"的地位 (被点名的例子是 R Foundation 与 tidyverse 团队)。

Hub 随后构建了这套思路所要求的工具——用于采集指标的 {riskmetric} 软件包、用于组织级审查的 {riskassessment} Shiny 应用，以及较新的 {riskscore}——近来还在走向一个公开的监管资源库：标准化的质量 度量，以透明方式评估并公开发布，作为监管层面软件质量期望的中央论坛。 真实的落地已有案例研究记录；一个很好的例子是 SCHARP 的研究级风险框架， 发表于 PHUSE US Connect 2026，围绕研究目的、软件开发生命周期、社区 使用与测试构建，并因资源有限而首先在高关注度试验中强制推行。

生态系统的自我陈述

有一个安静却了不得的事实值得驻足：pharmaverse 项目——从 admiral 到 xportr 约五十个临床 R 软件包组成的精选网络——对它自己 FAQ 中的 问题"这是否经过验证 / 符合 GxP / 有监管保障？"给出一个干脆的 "No."。组件生态系统毫不含糊：它交付的是能力，而针对预期用途的 评估是采用者自己的职责。这不是生态系统的失败，而是正确的分工。但这 意味着，开源临床技术栈中最重要的一句话就是那句"No"，而它下游的一切 尚未建成。

筛查的边界

风险导向的筛查回答的是：哪些软件包值得关注，值得多少关注？它回答 不了接踵而至的问题：针对你的用途，你对这个软件包要求了什么？你 如何知道它满足了这些要求？倘若存在相关缺陷，你的测试能否发现它？ 这些是关于预期用途证据的问题，而筛查文献坦承自己止步于这条边界。 白皮书自己的整改建议——编写与需求挂钩的测试——朝边界那边挥了挥手， 却没有跨过去。

跨过去，是下一章的主题，也是一个日益壮大的研究分支(包括本书的 姊妹研究)的主题：以规格为驱动、多技术并用、留有可审计记录的验证。

检验。 问一个组织：它如何把一个开源软件包引入受监管的工作？ 如果答案止于"我们用 riskmetric 给它打了分，并把报告归了档"，那 他们拥有的是一套分诊系统，而不是验证系统——分数告诉了他们该 往哪里看，而没有人真的去看。