别把医疗AI当软件采购,肿瘤科副总裁谈系统落地

肿瘤学正在成为AI最关键的试验场。US Oncology数字转型与运营卓越副总裁Jackie Njoroge在复盘医疗AI落地时指出，核心是系统级工程改造。对于做AI应用落地的工程师来说，这揭示了医疗场景容错率极低时的架构设计底线。

先说结论：

• 环境记录与智能准备：利用LLM基础知识处理实时文档与跨系统上下文聚合，释放医生时间。
• Agent排程与状态机：引入代理AI处理呼叫中心呼入，自动识别实验室、预处理与输液的复杂时序。
• 工程落地原则：拒绝单纯的技术采购，必须从业务问题出发，让临床医生深度参与系统定义。

医疗AI落地为什么让一线工程师头疼？因为业务链条太长。一个患者从转诊到就诊，记录在多个设施和系统间流转。Jackie Njoroge提到，当医生一天接诊10名患者时，系统必须自动从多个系统拉取记录并生成简明摘要。这在工程上是一个典型的多源数据RAG问题。大语言模型现在具备 substantial base knowledge，在Prompt工程上可以减少Few-shot的示例数量，直接依靠模型内部的医学常识进行上下文对齐。但这要求你在RAG检索阶段提高Chunk的语义连贯性，否则模型自带的知识反而会干扰检索到的特定患者记录。

核心场景拆解与工程实现

原文拆解了四个核心工程场景。第一是环境记录（ambient scribing），AI处理实时文档，医生只需最终签字，这降低了系统的交互延迟要求。第二是智能访前准备，自动聚合多源数据。第三是肿瘤排程（Oncology scheduling），这是一个典型的约束满足问题。患者需要实验室检查、预处理，然后精确计时进行输液。传统的规则引擎很难处理动态变化，引入代理AI（agentic AI）接管呼叫中心，实际上是把状态机的转移逻辑交给了LLM的推理能力。第四是账单和护理导航（billing and care navigation），通过AI优化预先授权流程。这些场景的共同点是用自动化替代人工核对。

技术决策框架：如何选型与迭代

面对这些场景，技术决策者该怎么选型？不要试图用一个端到端的大模型解决所有问题。原文强调从业务问题出发，识别可重复任务。在工程架构上，你需要将系统拆分为多个专用Agent。例如，环境记录可以用轻量级的语音转文本加LLM摘要模型；而排程系统则需要基于规则引擎结合LLM的意图识别。原文提到不要花太长时间构建完美计划，在敏捷开发中，这要求你先跑通单点闭环，比如先上线环境记录，收集临床医生（tech champions）的反馈，再逐步串联全链路。如果一开始就追求大而全的系统，工具迭代的速度会让你之前的设计全部作废。

适用边界与失败条件排查

医疗AI落地的失败条件是什么？原文明确指出，如果把AI当成单纯的技术采购，就会表现不佳。从工程视角来看，失败通常发生在数据流断裂的时候。如果你只购买了AI API，而没有改造底层HIS系统的数据接口，AI就会因为缺乏实时、准确的上下文而产生幻觉。在高风险的护理环境中，盲目信任AI输出是致命的。因此，系统设计的边界必须明确：AI负责生成草稿和流程建议，最终的签字权和决策权必须保留在临床医生手中。同时，必须建立严格的反馈闭环，让一线医生参与定义什么是好的输出，通过不断测试和微调来赢得信任。

原文提及的 US Oncology 网络及 Forbes Technology Council 相关链接：

医疗AI的终局不是买几个模型，而是打造更智能、响应更快的组织架构。Jackie Njoroge的复盘给所有做AI落地的工程师提了个醒：技术只是工具，真正的壁垒在于你对业务流程的理解深度。当你的系统能够自动处理复杂的排程时序，让医生把注意力完全放在患者身上时，AI的业务价值才能落地。想入局医疗AI，先别急着调参，去临床一线看看他们的真实工作流。

评论区唠唠
你做过跨系统数据拉取的RAG吗？最坑的是哪个环节？

往期推荐

• ·维基百科 vs 人工智能，5%新词条被机器接管
• ·250万次对话 vs 诈骗犯，Apate AI 卧底耗尽17年
• ·单次修复对比分配 Copilot，一次处理 25 个警报

点击公众号头像 → 历史消息，可翻阅以上文章