FHIR Agent Studio 简介：InterSystems IRIS 平台上的 FHIR 人工智能代理

人工智能将改变医疗保健行业，但前提是临床医生能够信任它，而开发人员 在构建它时无需每次都从头开始重新设计基础架构。 FHIR Agent Studio 正是我 为实现这两点所做的尝试：它是一个平台，可以利用可重用的构建 模块为 FHIR 工作流构建 AI 代理，在真实的 InterSystems IRIS for Health 后端上运行它们，并精确 检查每个代理在每个步骤中执行了哪些操作。

这是我参加 InterSystems FHIR AI Agent 竞赛的参赛作品，它附带了 十二个可运行的代理，这些代理运行在一个包含约 1,000 名患者和 20,000 个资源的合成 FHIR 存储库上。 我的目标是打造一个“工作室”而非单一的演示程序：在这里，您可以 设计、运行和检查多个代理，进而构建自己的代理。所有操作均在单个 容器中运行，仅需一条命令，且无需 API 密钥。

克隆该仓库并运行 docker compose up --build。然后打开引导式演示，运行其中的任意一个代理。 每个步骤都可供您详细查看。

从引导式演示开始

如果你只能做一件事，那就打开引导式演示。它带你游览全部十二个代理， 每个代理都配有通俗易懂的说明、一个直接跳转到相应界面的“试一试”链接， 以及关于注意事项的提示。即使你对该项目一无所知， 也能在几分钟内探索其全部内容。

什么是代理

每个代理都是一个以数据形式描述的小型临床工作流，是一个你可以 从左到右阅读的处理流程：

Trigger → Evidence (FHIR · SQL · Vector Search) → Agent (LLM) → Action (draft FHIR) → Trace

该工作室将该定义编译成可部署的运行时构建产物，并在 真实的 IRIS 互操作性生产环境中运行。这十二个相同的代理随后出现在三个 位置，均基于同一后端。以下是每个代理的具体表现形式。

在 Studio 中构建代理

Studio 是开发者门户。每个代理都位于一个图库中：打开一个图库即可运行 该代理、检查其编译情况或进行编辑。创建新代理可以从空白 画布开始，也可以基于现成的启动模板，并只需单击一下即可完成部署。

构建代理是我最引以为豪的部分。与冗长的配置列表不同， 您将看到代理以步骤管道的形式呈现，其顺序与运行时执行的顺序完全一致， 并且在运行整个流程之前，您可以针对真实患者单独测试每个步骤。 读取 FHIR 记录并查看返回结果。运行向量 搜索并查看检索结果。最棒的是，在发起任何 AI 调用之前， 您可以预览代理将发送给模型的确切提示——该提示由上方证据组合而成。 保存时，工作室会编译七个运行时工件并将其部署。

在临床医生工作场所提供决策支持

在面向临床医生的电子健康记录系统Cedar Valley Health 中，同样出现了这些智能助手。它们 并非作为独立的“AI 标签页”附加在侧边，而是作为决策支持功能， 出现在临床医生日常查看的界面中：患者病历、问题列表、用药 清单，以及标记需要关注患者的工作列表。 代理提出的任何建议 都会以清晰的卡片形式呈现，临床医生可以批准或拒绝。未经人工确认， 任何内容都不会写入病历。

同样的人工智能，专为患者设计

第三个界面是患者手机应用。它运行相同的智能代理，但采用通俗 语言：用日常用语解释的实验室检查结果、个性化护理计划、本地支持 服务以及简单的症状自查。 这提醒我们，智能代理的输出结果仅仅是 结构化数据，因此同一结果可以以一种方式呈现给专科医生， 又以另一种方式呈现给患者。

十二个智能代理中的几个

这十二个代理涵盖了广泛的实际临床和行政工作。以下是 几个例子：

• 一名影像与结果随访Agent发现了一项异常结果，但无人 为其安排随访；该专员会分析其含义，并起草指令以完成 闭环。（漏做随访是患者悄然“掉队”的最常见原因之一。）
• 一个用药安全Agent会发现一名服用二甲双胍的患者，其肾功能已 下降到该药物不再安全的水平，并起草一份审查报告提交给 处方医生。
• 一个自然语言到FHIR查询Agent将显示HbA1c 超过9的糖尿病患者转换为可读且可执行的真实只读SQL查询。
• 事前授权Agent利用向量 搜索将患者信息与支付方政策进行比对，并列出仍缺失的证明材料。

其他代理涵盖智能患者摘要、护理缺口、护理规划、社会 护理转介、临床试验匹配、再入院风险以及对话式分诊。

每个代理都会展示其工作过程

透明度是内置的，而非事后添加的，因为一个能够解释 自身行为的临床智能助手，才是临床医生真正能使用的工具。对于每次运行，您可以打开：

• 记录：代理生成的精确提示词以及模型的原始响应。 模型返回的 JSON 数据即为屏幕上显示的结果。
• 可视化追踪：IRIS 自有的管理门户会以消息流的形式重放运行过程， 包括 FHIR 读取、SQL 查询、向量搜索、LLM 调用 （请求和响应）以及起草的 FHIR 操作。
• 响应历史记录：每个模型响应都会与其提示词、 时间戳和哈希值一同记录，您可以浏览所有记录。

当代理缺乏回答所需的依据时，它会明确说明并回退到一条 标注清晰的路径，该路径绝不会被呈现为 AI 生成的内容。 每个代理都基于检索到的证据（“仅使用所提供的信息，绝不虚构数值”），每项输出 都遵循严格的契约，且其提出的每项操作都是需经 人类 批准的 草案。我将在下一篇文章中更深入地探讨其背后的工程原理。

为什么 InterSystems IRIS 是 AI Agent的理想平台

构建可靠的人工智能代理通常意味着将一大堆独立的 服务拼凑在一起：数据库、向量存储、工作流引擎、集成层、FHIR 服务器。IRIS for Health 为您提供了一个集所有这些功能于一体的平台，而本项目 正是依托了该平台的各个组成部分：

• 编排层。其运行时是真正的 IRIS互操作性生产环境。每次智能代理的运行都是一个实际的业务服务 → 业务流程 → 业务操作的消息流，这正是医院现有的用于在系统间传输数据的 引擎，在此被专门用于协调和审计 AI 代理。而“可视化追踪”功能 正是由此而来，且完全免费。
• 一个支持原生向量搜索的数据库。同一个数据库同时存储应用程序 数据和嵌入向量。 检索是真正的原生操作 VECTOR_DOT_PRODUCT 基于向量 列进行，无需运行独立的向量存储，也无需保持数据同步，因此每位 患者都能获取适合自身的指导、政策和临床试验信息。
• 真正的 FHIR 服务器。临床数据存储在 IRIS for Health FHIR R4 存储库中，通过 FHIR SQL 投影进行查询，并以 FHIR 草稿资源的形式写回， 而非伪装成 FHIR 的 JSON 文件。
• 打包与部署。它以软件包形式安装（IPM 和 module.xml），并 通过一条 Docker 命令即可运行。

由于这是一个单一平台，一次代理运行即可读取 FHIR、执行 SQL 查询、进行 向量搜索、调用 LLM 并起草 FHIR 资源，所有操作均作为一条可追溯的流程进行， 幕后没有任何拼凑的环节。正是这种一致性，才使得 该项目能够保持精简且易于审查。

五分钟即可运行

git clone https://github.com/SeanConnelly/ai-studio-for-fhir
cd ai-studio-for-fhir
docker compose up --build

一条命令即可构建 React 应用、创建 IRIS 命名空间和 FHIR 端点、 加载并编译后端、生成合成患者群体和 向量嵌入，并启动互操作性生产环境。 待系统稳定后，请在 http://localhost:42773/clinical/#/demo 处打开 引导式演示。

这是一个原型，而非成品

我想明确说明这是什么。FHIR Agent Studio 是一款演示软件。 我开发它的 方式就像制作原型一样：快速完成，旨在验证一系列想法并检验它们是否 行得通。这个初始版本无论在代码质量还是 设计上都远未达到投入生产的要求，而且患者数据是经过特殊处理的合成数据，这背后是有原因的。它只是一个演示版本，并非正式产品。

它真正做好的是证明了一点：InterSystems IRIS 是一个 构建Agent Studio的绝佳平台。 正是因为将 FHIR 存储库、向量搜索、 互操作性运行时和审计日志整合于一体，才使这个雄心勃勃的 构想得以在竞赛规定的时间内真正落地并展示出来。

因此，我将其视为一个起点，而非最终成果。这个概念值得 进一步深入探索，如果有更多时间，它完全可以发展成一套全面、生产级别的 设计与实现方案。就目前而言，这是我能展示该理念 从头到尾有效运行的最有说服力的方式。