临床试验招募

你的 AI 匹配工具分不清中心静脉导管与心脏导管术——这正让你每天损失 80 万美元。

80% 的临床试验未能按时完成入组。瓶颈不在于患者供给,而在于匹配精度。通用 AI 只读取词面,而本体驱动的系统能够对医学概念进行推理、解析例外条款,并生成经得起监管审查的审计轨迹。

80 万美元/天

试验每延误一天损失的销售额

Tufts CSDD,2024

80%

的试验未能按时完成入组

行业共识,2025

1,200 美元

每例筛选失败的平均成本

Antidote.me,2025

我们构建定制化匹配系统,利用 SNOMED-CT 本体图谱与确定性逻辑对入组资格进行推理。面向运行复杂试验、且筛选失败率与入组延误以百万计的制药申办方、CRO 及学术医疗中心。

无人谈及的匹配难题

过去五年,业界一直在用大语言模型取代关键词检索。这解决了简单的情形,却没有解决真正重要的情形。

一个揭示全貌的错误

某 III 期抗凝药试验排除曾接受过 “心脏导管术” 的患者。某患者的电子病历中有一条记录,描述了 “中心静脉导管置入术” 在 ICU 中进行,用于静脉给药通路。

通用 AI 的做法:

看到“导管”+“静脉”+与心血管术语相近。向量相似度得分很高。该患者被标记为 不符合资格。一名符合资格的患者就此流失。

本体驱动匹配的做法:

将两者都映射到 SNOMED-CT 概念 ID。心脏导管术(SCTID: 41976001)归属于“心脏操作”。中心静脉导管术(SCTID: 392230005)归属于“静脉导管术”。属于不同分支。该患者 符合资格

这并非个别极端情形。它代表了一整类错误——术语相同但医学含义不同的操作、病症或药物。已发表的评估证实,AI 模型确实会犯下这种“心脏导管术等同于中心静脉穿刺”的错误(Fierce Biotech,2025)。再乘以数十项试验中数百条标准,你就得到一个系统性的资格漏失,而再多的提示词工程也无法修复。

当前匹配中的三大结构性缺陷

本体盲区

大语言模型按词元相邻性处理文本,而非按医学层级。“冠状动脉造影”与“外周动脉造影”得分相近,只因它们共用“造影”一词。SNOMED-CT 则知道前者是心脏操作,后者是血管通路操作。

例外条款的脆弱性

“排除患有高血压的患者, 除非 经稳定药物治疗已良好控制 3 个月以上。”大语言模型看到“高血压”后,要么直接排除(丢失一名符合资格的患者),要么直接纳入(遗漏时间条件检查)。如今的方案平均已含 27 项以上标准,其中许多带有嵌套条件(IQVIA,2026)。

非确定性输出

用上下文窗口略有差异的同一患者,两次通过基于大语言模型的匹配器运行,你可能得到不同的结果。临床试验要求 100% 可复现的审计轨迹。监管机构需要确切了解每名患者被纳入或排除的 原因

如今试验匹配领域各方的分工

在你下一次供应商评估会议上拿出这份分析。每个平台都有其长处,问题在于哪些短板对你的方案复杂度至关重要。

平台 其实际功能 数据访问 其失效之处
Tempus(含 Deep 6 AI) 基于大语言模型的患者查询代理读取非结构化记录,依据标准评分。在评估查询上达到 94% 准确率。收购 Deep 6 后接入 750 多个医疗机构站点。 专有基因组数据与临床数据。Tempus 网络站点。 缺乏本体支撑的概率性匹配。数据访问受限于 Tempus 网络。无供监管审计的正式推理轨迹。
IQVIA(IQVIA.ai) 与 NVIDIA 合作的统一代理式 AI 平台(2026 年 3 月)。拥有全球最大的医疗数据集。从可行性到入组的端到端覆盖。 2.5 亿+ 患者记录。与制药企业历经数十年的合作关系。 覆盖广泛但匹配偏通用。平台优先的策略可能无法处理你的特定方案细节。定制工作流的集成要求繁重。
Medidata(达索) 面向 Rave EDC 的 AI Study Build。CTMS 领导者。500 多项 AI 支持的研究。强大的 EDC 到匹配流水线。 来自 Rave 平台的试验数据。直接访问 EHR 的能力有限。 匹配只是更大型 CTMS 中的一项功能,而非核心重点。Rave API 的局限使大多数团队转向批量 ETL,而非实时匹配。
TriNetX 用于可行性评估与队列识别的真实世界数据网络。跨各医疗系统拥有 2.5 亿+ 患者记录。 联邦网络模式。聚焦结构化数据。 在可行性评估上表现强劲,但在非结构化记录解析上较弱。数据访问需要网络成员资格。
ConcertAI(ACT) 于 2026 年 2 月推出的代理式 AI 平台。声称可缩短 10-20 个月的时间线。聚焦肿瘤学的真实世界数据。 专有肿瘤学数据集。与罗氏相邻的生态系统。 新平台,生产环境实绩有限。以肿瘤学为中心;在其他治疗领域深度不足。
四大会计师事务所 / 大型系统集成商 实施并集成各类平台。配置 Medidata、Veeva、Oracle Clinical One。项目管理与变更管理。 通过合作项目获取的客户数据。 他们实施平台,而非构建智能。无本体工程或定制匹配能力。单是集成项目就需 50 万至 500 万美元以上,时间线长达 6-12 个月。
自建 临床信息学团队针对特定方案构建匹配规则或微调模型。 完全的 EHR 访问权限。无数据共享顾虑。 临床信息学专家稀缺且昂贵。本体维护(SNOMED 每半年更新一次,MedDRA 每季度更新一次)需要专门的人力。大多数自建项目止步于关键词匹配加少量 NLP。

上述每个平台都采用某种形式的 NLP 或大语言模型匹配。但没有一个公开实现以 SNOMED-CT 本体图谱进行确定性资格评估的 neuro-symbolic 推理。临床精度正存在于这道缺口之中。

我们构建什么

每项能力都针对当前匹配系统中某个特定的失效模式。这些不是现成的产品功能,而是针对你的方案组合、EHR 环境与监管要求量身定制的组件。

本体支撑的患者匹配引擎

我们构建的匹配系统,其资格判定是经过计算得出的,而非预测出来的。大语言模型抽取层利用强制输出 SCTID 的受限解码,将临床记录转换为 SNOMED-CT 概念 ID。知识图谱(Neo4j)存储 35 万+ 医学概念及其层级关系。符号推理器通过遍历图谱来评估资格:患者的操作是否为被排除操作的一个子类型?答案是确定性的。

当临床记录杂乱时(ICU 记录、手写转录),我们会采用 SAKT 风格的受限解码,因为在生成时强制模型输出有效的 SCTID,能在被幻觉出的医学实体进入推理流水线之前将其捕获。对于结构良好的 EHR 数据(带编码字段的 FHIR 资源),我们则完全绕过大语言模型,直接映射到本体。

道义逻辑方案解析器

试验方案并非布尔型清单。它们是带有义务、许可与禁止的规范性陈述,通过例外条款和时间约束相互作用。我们将方案解析为形式化道义逻辑,把“在 Z 时间范围内排除 X,除非 Y”分解为可计算的操作。

该解析器处理用于时长计算的时间集成逻辑(“12 个月内未行 PCI”)、通过知识图谱中 CYP 酶通路遍历得出的药物相互作用链(“任何与 CYP3A4 相互作用的药物”),以及标准 NLP 流水线会压平为错误答案的嵌套条件逻辑。每条解析后的标准都会生成一份形式化逻辑规约,由推理器针对患者表型执行。

EHR 本地部署架构

患者数据始终保留在你的防火墙之内。神经抽取层作为本地部署的临床语言模型运行(在你所在机构的记录模式上微调)。知识图谱与符号推理器在本地运行。FHIR R4 输入适配器可连接 Epic(通过 App Orchard 端点)、Oracle Health(Millennium FHIR API)或其他经认证的 EHR 系统。

我们从第一天起就为 HIPAA BAA 合规进行架构设计:对每一次患者数据访问进行审计日志记录、最小必要访问控制、与你的 IRB 方案对齐的基于角色的权限,以及对任何需要在系统间流转的聚合数据提供去标识化能力。受保护的健康信息绝不接触外部 API。

CTMS 集成与监管数据流水线

存在于独立系统中的匹配输出,就是会被忽视的匹配输出。我们构建连接器,将排序后的患者-试验匹配结果直接推送至 Medidata Rave、Veeva Vault CTMS 或 Oracle Clinical One。站点协调员在其已经使用的工具中看到结果,而不必再去查看另一个仪表板。

输出映射为 CDISC SDTM IE(纳入/排除)域格式,因此招募数据从第一天起就为监管提交而结构化。无需下游数据清洗或核对。该流水线还处理本地实验室代码标准化(LOINC 映射),以将站点特定的参考范围与方案定义的阈值进行核对。

治疗领域本体开发

SNOMED-CT 提供基础,我们在其之上构建治疗领域的深度。以肿瘤学为例:映射到特定检测阈值的 PD-L1 表达水平(22C3 vs SP263 vs SP142)、BRCA1/2 变异分类(按 ACMG 指南区分致病性 vs VUS vs 良性)、EGFR 突变亚型(19 号外显子缺失 vs L858R vs T790M)、ALK 重排状态、采用 AJCC 第 8 版映射的 TNM 分期,以及带治疗线归属的既往治疗方案史。

每套本体在上线前都会针对你试验组合中 10-15 个真实方案进行验证。验证意味着将系统运行于入组结果已知的已完成试验,并衡量其与人工金标准的一致性。我们随着 SNOMED-CT 每半年更新、MedDRA 每季度更新而维护本体,使概念映射保持最新。

运作方式:从临床记录到资格判定

走一遍某 III 期肿瘤学试验中单个患者的评估过程。这就是对每一个患者-标准配对运行的流程。

1

神经抽取

本地部署的临床大语言模型读取患者的非结构化记录。一名医生写道: “患者完成 4 周期卡铂/培美曲塞,末次输注 2025 年 3 月。PD-L1 TPS 45%(22C3)。ECOG 1。” 模型利用强制输出有效 SNOMED-CT 与 LOINC 的受限解码来抽取实体: 用药记录:卡铂(SCTID: 386905003)、培美曲塞(SCTID: 409342003)。检查发现:PD-L1 45%(LOINC: 85146-3)。检查发现:ECOG PS 1。

2

本体映射

抽取出的实体被映射到知识图谱。“卡铂”解析到铂类抗肿瘤药物分支。图谱知道卡铂 是一种(is-a) 烷化剂, 是一种(is-a) 铂类化合物, 相互作用于(interacts-with) CYP2C8。若方案排除“既往铂类治疗”,图谱遍历确认卡铂符合该条件。若其排除“既往免疫治疗”,图谱则确认卡铂不符合。毫无歧义。

3

道义逻辑评估

方案标准: “无针对晚期疾病的既往全身治疗,除非辅助/新辅助治疗在随机化前 > 12 个月已完成。” 解析器分解为:禁止(既往全身治疗) 除 许可(辅助 或 新辅助) 且 时间(完成日期 + 12 个月 < 随机化日期)。推理器检查:曾使用卡铂/培美曲塞。它是辅助治疗吗?图谱检查治疗时的疾病分期。间隔是否足够?末次输注为 2025 年 3 月,随机化为 2026 年 4 月 = 13 个月。结果: 符合资格(例外条款满足,时间约束达成)

4

置信度评分与推理轨迹

系统输出一个综合评分。确定性标准(本体匹配、时间计算)获得二元置信度。模糊标准(记录措辞不清、数据缺失)获得一个概率评分,并标注出具体的歧义之处。每条标准的推理轨迹都会被存储:匹配了哪个 SCTID、执行了哪次图谱遍历、哪个逻辑操作产生了该结果。该轨迹直接进入 CDISC SDTM IE 域格式,并进入协调员的 CTMS 视图。

与平台 AI 的关键区别:

系统从不向大语言模型询问“这名患者符合资格吗?”大语言模型读取文本,本体解析含义,逻辑引擎计算资格。每一层都有明确的职责和可验证的输出。当协调员看到“符合资格”或“被排除”时,他们能够确切追溯原因,直至决定该结果的 SNOMED 概念 ID 和图谱关系。

我们如何合作

三个阶段,共 14-20 周。每个阶段都有明确的交付物,并在推进前设有决策点。

第 1 阶段:第 1-4 周

招募运营审计

  • 按治疗领域和标准类型分析当前的筛选失败率
  • 梳理 EHR 数据全景:结构化 vs 非结构化、FHIR 成熟度、记录质量
  • 审阅你试验组合中 10-15 个具代表性的方案
  • 找出导致最多假阳性和漏配的标准类型
  • 交付:技术架构文档、基于你实际数据的 ROI 模型、监管路径建议

决策点:推进构建、调整范围,或判定某个平台更为合适。如果是这样,我们会如实相告。

第 2 阶段:第 5-16 周

构建

  • 优先治疗领域的本体开发(肿瘤学 6-8 周,罕见病 8-12 周)
  • 针对你所在机构的临床记录模式与缩写惯例进行大语言模型微调
  • 构建带 SNOMED-CT、MedDRA、LOINC 映射的知识图谱
  • 为你的方案模板配置带道义逻辑的符号推理器
  • 与你的 EHR 环境进行 FHIR R4 集成
  • 构建 CTMS 连接器(Medidata Rave、Veeva Vault 或 Oracle Clinical One)

第 3 阶段:第 17-20 周

验证与部署

  • 针对 3-5 个入组结果已知的已完成试验进行回顾性验证
  • 准确率基准测试:目标相对人工金标准召回率 >90%、精确率 >85%
  • 站点协调员工作流集成与培训
  • CDS 豁免文档与预期用途声明
  • 本体维护交接或持续支持协议

持续事项:SNOMED-CT 每半年更新,MedDRA 每季度更新。我们负责维护,或附文档交接。

诚实的注意事项

  • 瓶颈是 EHR 集成,而非 AI。 Epic App Orchard 认证需要 6-12 个月。如果你所在机构尚未启动该流程,第 2 阶段将受制于数据访问。我们协助应对认证流程,但无法加速它。
  • 数据质量决定上限。 如果临床记录稀疏、不一致,或大量使用未标准化的速记缩写,抽取准确率就会更低。第 1 阶段会在你投入构建之前识别出这些缺口。
  • 组织内部的认同至关重要。 曾被假阳性泛滥的工具所累的站点协调员,会抵触新系统。第 3 阶段包含变更管理,但协调员的信任是在数周准确结果中赢得的,而非在一次培训会上。

试验招募就绪度评估

回答关于你当前招募运营的六个问题。该评估会指出你的匹配流水线在何处漏掉了符合资格的患者,以及哪些改进对你的具体情况能带来最高的 ROI。

1. 你当前在所有进行中试验上的筛选失败率是多少?

买家问我们的问题

本体驱动匹配与 Tempus 或 IQVIA 已提供的方案有何不同?

Tempus Patient Query 与 IQVIA 的匹配工具使用大语言模型读取临床记录,并依据试验标准对相关性评分。这对直白的标准效果良好,但在本体性区分上会失效。当某方案排除“心脏导管术”,而患者记录提到“中心静脉导管置入术”时,一个基于向量相似度运行的大语言模型会看到两个涉及心血管系统的导管操作,从而标记为匹配。一个以 SNOMED-CT 为支撑的系统则识别出这两者位于操作层级中完全不同的分支(SCTID 41976001 vs. 392230005),并正确判定该患者符合资格。

实际差异体现在筛选失败率上。基于大语言模型的匹配在结构良好的标准上通常达到 85-94% 的准确率,但在含复杂本体性区分、时间逻辑或例外条款的方案上会降至 70-80%。本体驱动的匹配在所有标准类型上都保持 95% 以上的准确率,因为资格判定是由符号推理器计算得出的,而非由语言模型预测出来的。

另一项结构性差异是可审计性。大语言模型产出一个相关性评分。我们的系统则产出一条推理轨迹:患者具有 SCTID X,标准要求非-SCTID Y,按 SNOMED 层级 X 不是 Y 的子类型,因此符合资格。这条轨迹正是监管事务团队进行 FDA 提交文档所需要的。

这能否与我们现有的 EHR 系统集成,而无需将患者数据发送至外部 API?

可以,而且这是一项核心架构原则,并非事后补救。neuro-symbolic 架构将神经层(用于实体抽取的大语言模型)与符号层(知识图谱与逻辑求解器)分离。两者都可以完全在你的防火墙之内运行。

大语言模型抽取层作为本地模型部署,通常是一个在你的基础设施或安全私有云实例上运行的、经微调的临床语言模型。它绝不会将原始患者文本发送至外部 API。知识图谱(Neo4j 或同类产品)与 SNOMED-CT 本体位于本地。FHIR R4 是输入标准。对于 Epic 环境,我们针对通过 App Orchard 提供的 FHIR R4 端点进行构建,拉取 Patient、Condition、Procedure 和 MedicationAdministration 资源。对于 Oracle Health(Cerner),集成使用其 Millennium FHIR API。

抽取层在本地处理临床记录,将实体映射到 SCTID,符号推理器则针对方案标准评估资格。受保护的健康信息绝不离开你的安全环境。我们从第一天起就为 HIPAA BAA 合规进行架构设计,包括审计日志记录、最小必要访问控制,以及对任何确需在系统间流转的数据提供去标识化能力。

这适用于哪些治疗领域,本体搭建需要多长时间?

该架构适用于任何治疗领域,因为 SNOMED-CT 涵盖 35 万+ 医学概念。变量在于本体深度,即为你的特定方案预先配置了多少领域专属的映射、同义词和层级关系。

肿瘤学是我们大多数合作项目的起点,因为其标准最为复杂:生物标志物要求(PD-L1 表达水平、BRCA1/2 突变状态、EGFR 变异)、分期系统(TNM、AJCC 第 8 版)、带时间约束的既往治疗方案史,以及体能状态评分。一套涵盖前 50 个生物标志物、200 多种治疗方案和标准分期系统的、可投入生产的肿瘤学本体,需要 6-8 周来构建和验证。

心血管与中枢神经系统是接下来最常见的领域。心血管本体聚焦于操作层级(心脏导管术的区分只是其中数十项之一)、通过 CYP 酶通路的药物相互作用链,以及带站点特定参考值调整的实验室数值范围。中枢神经系统则增加了主观终点处理和认知评估评分映射。

罕见病在技术上最具挑战性,因为对于超罕见疾病,SNOMED 的覆盖可能很薄。我们用 Orphanet 本体映射加以补充,并构建反馈到图谱中的自定义概念扩展。罕见病治疗领域的搭建需要 8-12 周。每套本体在上线前都会针对你试验组合中的真实方案标准进行验证。

这如何处理现代试验方案中复杂的“除非”和“例外”条款?

这正是确定性逻辑最明显胜过概率性语言模型之处。标准 NLP 将入组资格标准视为有待解读的文本,我们则将其视为有待计算的形式化逻辑。

以一条真实标准为例:“排除患有高血压的患者,除非经稳定药物治疗至少 3 个月已良好控制。”大语言模型看到“高血压”一词,必须从上下文判断是否排除。它大多数时候都判断正确,但“大多数时候”意味着在每一项试验中都丢失符合资格的患者。

我们的解析器将其分解为道义算子。禁止:存在高血压。许可条件:高血压 且 已控制(按方案定义血压低于 140/90) 且 稳定用药(同一降压方案) 且 时间约束(持续 3 个月以上)。系统随后从知识图谱查询患者的用药史,识别出降压药,检查处方起始日期,计算相对筛查日期的持续时长差值,并核实观察窗口内的血压读数。每一步都产出一个可验证的输出。

同样的逻辑也能处理诸如“无既往化疗,除非新辅助治疗已于 6 个月前完成”这样的链条——通过检查治疗意图属性(新辅助 vs. 辅助 vs. 姑息)、结束日期和时间差值来实现。这些都不是极端情形。IQVIA 的数据显示,如今的方案平均已含 27 项以上入组资格标准,其中许多带有嵌套条件。每个方案中一条处理不当的例外条款,在数百名受筛查患者中累积起来,就会演变成数十例流失的入组。

一次典型的合作是什么样的,与授权使用某个平台相比成本如何?

一次典型的合作分为三个阶段,历时 14-20 周。第 1 阶段(3-4 周)是招募运营审计:我们分析你当前的筛选失败率,梳理你的 EHR 数据全景,审阅你试验组合中 10-15 个具代表性的方案,并找出导致最多假阳性和漏配的具体标准类型。本阶段交付一份技术架构文档和一个基于你实际数据的 ROI 模型。

第 2 阶段(8-12 周)是构建:针对你优先治疗领域的本体开发、在你的临床记录模式上进行大语言模型微调、知识图谱构建、符号推理器配置,以及与你的 EHR 环境进行 FHIR 集成。第 3 阶段(3-4 周)是验证:针对入组结果已知的已完成试验进行回顾性测试、准确率基准测试,以及协调员工作流集成。

成本取决于范围。带一项 EHR 集成的单一治疗领域构建通常为 18 万至 35 万美元。多治疗领域或多站点部署的成本随本体广度和集成复杂度而扩展。作为对比,Tempus 和 IQVIA 的平台授权每年为 20 万至 50 万美元以上,外加按患者或按试验计费。

根本的经济差异在于所有权。平台授权是带有供应商锁定的经常性支出。定制构建则是你拥有、维护并扩展的一项资产。对于每年运行 20 个以上试验的组织而言,定制构建通常在 18 个月内即可与平台授权达到盈亏平衡,并额外具备使匹配准确率契合你特定方案复杂度的优势。

这需要 FDA 许可吗,还是符合 CDS 豁免条件?

FDA 于 2026 年 1 月更新的临床决策支持指南是此处的相关框架。关键问题在于该系统是做出自主的临床决策,还是支持人类的决策制定。

我们的架构是为符合《21 世纪治愈法案》第 3060 条下的 CDS 豁免而设计的。该系统满足全部四项豁免标准:它无意获取、处理或分析医学影像或信号;它展示推荐的依据(完整的推理轨迹);它面向具备独立审查能力的医疗专业人员;并且在做出资格判定时不取代临床判断。

在实践中,这意味着系统输出带置信度评分和推理轨迹的排序后患者-试验匹配结果。站点协调员或临床研究助理(CRA)在任何患者接触之前审查每一项匹配。系统从不自动入组。

话虽如此,FDA 对 CDS 范围的解释仍在持续变化。如果你的组织计划使用匹配输出在无人工审查的情况下自动排除患者,该系统可能会跨入需要 510(k) 许可或 De Novo 分类的器械范畴。我们建议在设计阶段早期就与 FDA 的数字健康卓越中心接洽。我们将监管文档——包括 CDS 豁免论证、预期用途声明和临床评估报告——作为第 1 阶段的标准交付物来构建。

技术研究

本解决方案页面背后的研究。如需完整的技术架构、本体设计原理与临床验证方法。

超越句法:临床试验招募中的 neuro-symbolic AI 与本体驱动表型分析

对用于临床试验患者匹配的 neuro-symbolic 架构、SNOMED-CT 集成、道义逻辑框架及 GraphRAG 实现的完整技术分析。

入组每延误一天,都会让你的研发管线损失 80 万美元

10 项试验中 40% 的筛选失败率,意味着每年约 48 万美元浪费在筛选成本上——这还没算上入组延误的损失。

我们从一次 3-4 周的招募运营审计开始。你将获得一份架构文档、一个基于你实际筛选失败数据构建的 ROI 模型,以及一个关于定制构建是否适合你试验组合的明确答案。

招募运营审计

  • ✓ 按标准类型进行的筛选失败分析
  • ✓ EHR 数据全景梳理
  • ✓ 方案复杂度评估
  • ✓ 基于你实际数字的 ROI 模型

定制匹配系统构建

  • ✓ 面向你治疗领域的 SNOMED-CT 本体
  • ✓ 道义逻辑方案解析器
  • ✓ EHR 本地部署架构
  • ✓ CTMS 集成与监管数据流水线