病理、基因与 OMOP：跨模态语义对齐
一份较早的血液检测写着“EGFR 未检出”，一份较新的组织报告写着 exon 19 deletion。把它们压成一个布尔字段，系统不是丢掉了一个细节，而是丢掉了时间、样本和检测方法这三个决定性条件。
NSCLC 试验条件常把组织学、分期、既往治疗和分子标志物放在同一句话中。数据却散落在病理报告、基因检测表、用药记录和影像报告。跨模态对齐的目标不是把它们拼成一段摘要，而是形成可追溯的患者事件图。
FHIR 强于临床系统之间交换；OMOP CDM 的出发点是把不同观察性数据库转换到统一结构和标准词汇，使分析代码可复用。S05 OMOP 以 PERSON 为中心连接 Condition、Measurement、Drug Exposure 等事件，并同时保留 source value 与 standard concept。它适合队列定义和研究分析，但不是实时 EHR 工作流的替代品。
病理/基因进一步带来版本问题：同一变异可有不同表示，检测阴性只在检测范围与质量足够时有意义，报告签发时间不等于样本采集时间。Agent 若只抽取“EGFR negative”会丢掉 assay、specimen、覆盖范围和版本。
双模型加统一 Evidence
Section titled “双模型加统一 Evidence”交换侧保留 FHIR/DICOM 原始引用和事务语义；分析侧映射到 OMOP/标准概念，便于队列与统计；Evidence 同时保存 normalized fact 与 source locator，映射失败时保留原值并标 unknown。
基因 Evidence 至少包含 gene、variant/alteration、method、specimen、sample time、report time、result、assay coverage、reference build（适用时）、报告版本和限制。病理 Evidence 保留 specimen、site、histology、block/slide 和原文定位。
| 方案 | 解决 | 不解决 |
|---|---|---|
| FHIR | 系统交换与资源引用 S01 | 自动形成跨库可比队列 |
| OMOP | 统一分析结构/词汇 S05 | 实时授权和事务写入 |
| 自由文本 RAG | 快速搜索报告 | 稳定单位、变异和时间语义 |
| Evidence Graph | 跨模态关联与审计 | 源数据偏差和错误本身 |
python3 labs/run_lab.py --lab 08实验把三条来源事件映射为统一 Evidence，并检查 sample_time <= report_time、同一基因冲突与 source value 保留。遇到一次阴性、一次阳性且时间不同，程序输出 conflict，留给协议时间窗和人工判断。
先确认原始值和标准化值会同时保留，再把其中一条 sample_time 改到报告时间之后，最后观察程序拒绝的是时间不变量，而不是替你挑一个“看起来更合理”的结果。真实接入时，这种拒绝比自动合并更可解释。
EGFR 阴性为什么未必能直接写 not_met
Section titled “EGFR 阴性为什么未必能直接写 not_met”患者较早的血液检测报告写“EGFR 未检出”，后来组织检测发现 exon 19 deletion。若系统只保留 normalized EGFR=false/true，会看到布尔冲突却无法解释。完整 Evidence 显示两次 specimen 不同、assay 范围不同、采样时间不同；协议可能允许任一经验证方法，也可能要求特定样本。Eligibility Agent 因此先输出 conflict，规则或人工再根据协议消解。
“未检出”也不等于全基因阴性。panel 是否覆盖目标 exon、检测限、样本肿瘤含量和报告质量都会改变解释。工程合同至少保留 assay 名称/版本、specimen、coverage 摘要和报告原文定位。若这些字段缺失，最诚实的状态是 unknown。
病理同理。“腺癌”可能来自初诊小标本，后续手术标本提供更完整组织学；分期可能在不同时间更新。系统不应简单采用最新记录覆盖历史，而应形成按 sample/event time 的 timeline，并让 TrialCriterion 指定所需参照。
OMOP 映射流水线
Section titled “OMOP 映射流水线”源系统先落入 staging，保留原表、原 code 和加载批次；ETL 映射到 PERSON、CONDITION_OCCURRENCE、MEASUREMENT、DRUG_EXPOSURE 等域，并写 source value/source concept/standard concept。质量检查不只看行数，还看 unmapped 比例、domain 错位、日期异常、单位和值分布。OMOP 官方文档强调标准词汇和源值并存，正是为了跨库分析与追溯。S05
MedAgent Forge 不把 OMOP concept id 直接显示给协调员。Cohort Retrieval 可以用标准概念找到候选，Evidence 再回到源事件与临床可读术语。若映射信心不足，保留 source value，禁止用相似 concept 悄悄替代。
跨模态关联首先靠实体：Patient id 只是第一层，还要关联 encounter、specimen、order、report、study 和 treatment episode。病理 slide 属于哪个 specimen，基因检测是否来自同一 block，影像检查是否在治疗前，这些关系比“文本语义相似”更可靠。Evidence Graph 的边应带来源和置信，而不是模型自动生成后当事实。
时间至少区分 event/sample、result/report 和 recorded/load。排序用错时间会产生因果倒置。对日期只有月份或区间的记录，合同要表达精度，不能补成某一天再做精确 14 天判断。
FHIR 与 OMOP 双写的一致性
Section titled “FHIR 与 OMOP 双写的一致性”若系统同时读 FHIR 实时数据和 OMOP 批量仓库，数据新鲜度不同。每次任务记录各来源 snapshot；关键判断优先使用定义清楚且最新的来源，冲突不能无提示合并。可运行 reconciliation job 比较高价值字段，并把差异作为运维告警和工作台提示。
FHIR/SMART 解决受控应用访问，S01S03 OMOP 解决分析标准化，S05 DICOMweb 解决影像对象访问，S04 而 TrialGPT 展示匹配分层。S30 它们不是相互替代的框架。架构师的价值就在于为一个业务链规定交界合同：FHIR/OMOP 返回 Evidence，不让模型绕过来源；试验匹配只消费冻结 Criterion 与 Evidence。
映射评审练习可以这样做：为 EGFR exon 19 deletion 设计 source value、标准概念、assay、specimen 和时间字段；再构造一个无法映射的本地术语。正确处理是保留原值、映射状态和人工队列，而不是选相似 concept。统计 unmapped 并按对业务判断的影响排序，比追求“100% 映射率”更安全。
再比较 FHIR 实时记录与 OMOP 批次快照的新鲜度，规定冲突显示和重新抓取条件。将映射版本与来源批次一起写入 Evidence，否则同一事实无法在词汇升级后重放和解释。评审者必须能同时看到标准概念和原始值，否则停止发布。
- 术语映射不是纯字符串匹配，需要版本化词汇和人工 QA。
- 阴性结果不能脱离检测覆盖范围解释。
- OMOP 标准概念映射会丢细节，必须保留源值。
- 本章不教授病理或基因诊断，只处理工程数据合同。
完整的来源类型、用途与边界见教材来源注册表。
资料与延伸阅读
Section titled “资料与延伸阅读”- HL7 FHIR R4：理解实时临床交换的资源边界。
- OMOP Common Data Model：理解标准概念与 source value 为什么需要并存，以及它为何更适合观察性分析。
- SMART App Launch 和 DICOMweb：分别补齐应用授权和影像对象访问的交界面。
- TrialGPT 论文：回看跨模态 Evidence 如何最终服务于分层的试验匹配，而非生成一段病例摘要。