临床 AI 落地的真正瓶颈不是模型，而是集成

把 AI 模型从笔记本搬进真实运行的医院系统，是一件远比想象中困难的事。作者在过去数月与斯坦福、纽约大学、阿姆斯特丹大学医学中心（Amsterdam UMC）、剑桥大学医院（CUH）以及伦敦大学学院医院（UCLH）等机构的临床 AI 一线人员深入交流后发现：每一个严肃的临床 AI 项目都在重复搭建同一套基础设施，因为市面上根本没有现成方案，而最棘手的从来不是模型本身，而是「集成」。

两层基础设施：单点部署与跨院集成

作者把模型走向生产的过程拆成两层。

第一层：单点部署——让模型在一台机器上跑起来。这一层已有相对成熟的供应商，且真正可靠的厂商大多有深厚的学术研究背景，例如源自 UPMC/CMU/Pitt 联盟的 Abridge、源自 MIT 的 Layer Health。这一层问题可计价、可解决，但 Epic 这类大型电子病历系统始终是绕不开的边界。
第二层：跨院集成——接入真实临床数据、跨院点扩展、并保证可审计。模型一旦开始推理，「然后呢」的问题立刻浮现：需要从既有系统取数据，最好能同时在多家医院运行。这一层没有一家供应商能够独立拿下，因为生态过于碎片化。

在两层之外还存在一个「垂直方向」：不再横向铺更多医院，而是在单点之上叠加评估、监控与审计。

垂直扩展：评估正从后置补件变为默认配置

斯坦福的 ChatEHR → MedHELM 是这一方向的代表案例——整套系统从零自研、完全开源，由院方一手完成。之所以只有斯坦福能做到，是因为它是全球工程人才资源最充裕的学术医疗中心之一；即便如此，从部署到评估也花了三四年才把基础工程理顺。

创业公司在评估环节可以跑得更快，但前提是从别处带进来已有的基础设施经验。也就是说，速度仍然取决于创始人背景，而非行业整体能力的提升。值得注意的是，行业的预期正在转变：评估正从「部署跑通之后再补」变为「第一层供应商交付时的标配」。

「集成」一词，对不同角色意味着不同事情

对临床负责人而言，集成是把模型从「在回顾性数据上训练」变成「在 FHIR API 上实时运行」的过程，是把一个本地医院的概念证明嵌入端到端系统的关键。
对开发者而言，集成则是从零搭建所有底层依赖：访问权限、证书、网络、治理。写代码反而是最容易的部分；数据存储与安全必须在动手之前就想清楚。

归根结底，这是同一个「第二层」问题的两种视角：一个看到的是工作流，另一个看到的是布线。而底层约束始终是同一件事——既懂 AI/ML 又懂 FHIR 的工程师严重短缺，把新人带进医疗系统的过程又极为漫长；当关键开发者离开，机构知识也随之流失。

开源：打破壁垒的「超能力」

作者指出，今天真正的护城河其实是定制化的集成、机构经验与稀缺人才——而这恰恰是医疗 AI 最不该依赖的护城河。没有人能拥有的那一层基础设施，正是最不应该被每个医院重复重建的那一层。

作者认为开源是答案：把那些「无聊且不可拥有」的基础设施在开放环境下构建一次，护城河随之消失。具体而言：

FHIR 接入将变得像调用任何其他 API 一样简单；
治理与安全从埋在代码里，变成可协作、可审计、随规模扩展的公共文档；
那些靠时间积累的隐性知识不再随人员流失而消失，而是由不断壮大的社区共同维护。

当管道变成开放标准之后，曾经需要稀缺专家才能完成的定制集成，将变成 AI 智能体（AI agents）可以逐步胜任的工作。人的问题不会消失，但只需要在开放环境中被解决一次，而不必在每家医院的高墙后重复求解。

到那时，竞争的优势将不再是定制集成或少数机构才负担得起的经验，而回归到最朴素的一点：谁把东西做得最好。