大多数“AI 代理 + FHIR”项目最终都呈现出相同的架构：这边是一个 FHIR 服务器，那边是一个向量数据库，中间则是一个 Python 服务，其职责是调用嵌入 API、在两端之间转换浮点数数组，并保持两个数据存储库的同步。 三个活动组件、两次网络跳转，以及一个你从此永久拥有的嵌入式客户端。

Triage Park：我们 提交给InterSystems 编程大赛:FHIR AI Agent的参赛作品，完全没有这些复杂结构。该代理从不计算嵌入向量，也从未导入过 OpenAI 嵌入向量客户端。 没有向量数据库。它将原始文本发送给 IRIS，剩下的工作由 IRIS 完成：它在服务器端计算嵌入向量，并通过针对与 FHIR 存储库位于同一数据库*中的表执行单条 VECTOR_COSINE SQL 语句来响应检索请求。

这就是 IRIS for Health 的“AI Hub”模式，一旦我采用该模式，我自己的代码中整整一层就消失了。以下是它的具体工作原理。

问题在于：分诊人员需要快速获得指导方针

Triage Park 是一款对话式分诊助手。患者描述症状（“我上楼梯时胸口发紧”），由大型语言模型（LLM）支持的助手会读取患者的真实 FHIR 病历，并生成分诊决策：自我护理 / 看全科医生 / 急诊护理 / 急诊科，同时附上依据说明。

“引用依据”(Cited rationale)是关键所在。

在开始开发“智能出院导航器(Smart Discharge Navigator)”时，我遇到了一个常见的难题：FHIR 数据以 JSON 数据包的形式存储，但我所需的分析需要将多个资源进行关联，而这正是 SQL 所擅长的领域。

InterSystems FHIR SQL Builder 彻底解决了这一问题。我无需在应用程序代码中解析 JSON 数据包，而是能够直接在 IRIS for Health 中针对 FHIR 资源投影编写纯 SQL 语句。本文将详细介绍我如何利用该工具构建了该应用程序核心——基于人群的再入院风险评分引擎。

临床问题

30 天内的医院再入院是医疗保健领域成本最高且本可预防的问题之一，每年给美国医疗系统造成 170 亿美元的损失。挑战并不在于事后识别风险因素，而在于在恰当的时机——即患者出院前——及时发现这些风险因素。

为了评估再入院风险，我需要针对每位患者同时回答以下五个问题：

• 该患者近期住院过几次？
• 该患者是否患有多种活动性慢性病？
• 该患者目前是否正在服用五种或更多种药物（多药联用）？
• 病历中是否有任何异常实验室检查结果？
• 是否有缺席随访的情况？

如果通过 Python 解析 FHIR 数据包来回答这五个问题，不仅速度慢，而且容易出错。而 FHIR SQL Builder 则让这一切变得简单明了。

在 v2026.1 版本中，我们为您的 FHIR 端点引入了更强大且符合实际安全需求的授权支持。

这是通过使用SMART on FHIR v2 的细粒度作用域来实现的。

重点——并非 SMART 本身，而是其细粒度作用域；简单易上手的示例

我很高兴地告诉大家FHIR Agent Studio现已在 InterSystems Developer Cloud 上作为在线托管演示运行—— 无需安装，无需配置，只需在浏览器中打开即可。

FHIR Agent Studio 是一个开发者门户，用于在单一的 InterSystems IRIS for Health 后端上 构建、运行和检查面向 FHIR 工作流的 AI代理。每个 代理都是一个小型临床工作流，您可以从左到右阅读其流程：

Trigger -> Evidence (FHIR / SQL / Vector Search) -> Agent (LLM) -> Action (draft FHIR) -> Trace

该平台随附十二个可运行的代理，基于一个包含约 1,000 名患者和 20,000 多个资源的合成 FHIR 存储库，此外还提供一个面向临床医生的应用程序和一个面向患者的手机 应用程序，均运行在同一后端上。每次运行的每个步骤均可追溯。

立即试用（无需登录）

应用程序界面已开放——只需点击即可探索：

我很高兴与大家分享FHIR Agent Studio 的演示视频，该视频现已在 YouTube 上发布。

FHIR Agent Studio 演示视频

https://www.youtube.com/watch?v=vktfq_kvNnk

FHIR Agent Studio 将 AI Agent与 FHIR、InterSystems IRIS、Vector Search 以及大型语言模型相结合，向开发者展示如何探索、构建和测试由Agent驱动的医疗保健工作流。

您还可以在此处查看更多信息：

介绍文章：https://community.intersystems.com/post/introducing-fhir-agent-studio-ai-agents-fhir-intersystems-iris

GitHub 代码库：https://github.com/SeanConnelly/ai-studio-for-fhir

Open Exchange 页面：https://openexchange.intersystems.com/package/FHIR-Agent-Studio

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

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

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

从引导式演示开始

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

大家好，

现在是时候公布InterSystems开发者竞赛：面向FHIR的AI Agent”的获奖名单了！ 

非常感谢我们的18位社区成员开发了

🌟20 款精彩绝伦的应用程序🌟

本次竞赛收到了令人印象深刻的参赛作品，每一件都体现了创新精神和创造性思维。面对如此众多优秀的参赛作品，评选出最佳作品确实是一项艰巨的任务。

让我们来认识一下获奖者，并了解他们的项目：

该方案成功将医疗设备数据纳入全院数据管理，实现了医疗设备数据的全流程高效采集与应用。

大家好，

在本文中，我将介绍我的应用程序iris-fhir-agents 这是一个由 InterSystems IRIS for Health 驱动的多智能体临床 AI 平台。该平台包含用于分诊、专科会诊、用药安全以及 FHIR 服务器探索的智能体——所有功能均基于 IRIS Vector Search RAG 构建。 平台包含一个无代码代理构建器，让您无需编写任何代码即可设计和部署自定义临床代理。

大家好，

你是否曾希望你的电子健康记录（EHR）能具备思考能力？不仅仅是显示数据，也不仅仅是触发警报。而是能够真正阅读病历、综合临床指南进行分析，并根据临床医生的单条信息，向系统生成结构化的转诊医嘱。

在本文中，我将向大家展示如何创建您自己的定制临床AI助手。

🏥 关于 iris-fhir-agents 应用

iris-fhir-agents是一个完全基于 InterSystems IRIS for Health 构建的多智能体临床 AI 平台

当将 IRIS For Health 从 2024.1 升级到 2024.2+（2025.1、2026.1 等）时，您可能会注意到，在以前访问 FHIR 门户的地方，现在会收到 "未找到 "的提示。

2024.2 之前：

截至 2024.2+：

这可能是因为它将进入 /csp/fhir-management，而不是之前的 /csp/healthshare。请参见此处的发布公告。

根据您的升级方式，配置可能是自动的，但如果您使用 IKO，请确保更新您的网络应用程序以包含 /csp/fhir-management：

    webgateway:
      replicas: 1
      image: containers.intersystems.com/intersystems/webgateway:2026.1
      applicationPaths:
        #; All of the IRIS instance's system default applications.
        #; For Management Portal only, just use '/csp/sys'.
        #; To support other applications, please add them to this list.
        - /csp/sys
        - /csp/broker
        - /api
        - /isc
        - /oauth2
        - /ui
        - /csp/healthshare
        - /csp/fhir-management

嗨，开发人员、

我们很高兴地宣布新一届 InterSystems 在线编程竞赛即将开始：

🏆InterSystems 开发者竞赛：面向 FHIR 的AI Agent🏆

持续时间： 2026 年 5 月 25 日至 6 月 14 日（美国东部时间）

奖金：12,000 美元

主题

开发一个可在互操作性 FHIR 解决方案中调用的AI Agent。 

实施建议任务可获得 5 个额外积分 (!) - 每个应用程序一次

1. 智能患者摘要生成器

   1. 功能：从 FHIR 数据中创建简洁、便于临床医生使用的患者摘要，包括病情、用药、过敏症、最近就诊情况、化验和护理计划。

   2. FHIR 资源：Patient, Condition, MedicationRequest, AllergyIntolerance, Observation, Encounter, CarePlan.

   3. 平台功能：FHIR API、FHIR SQL Builder、AI Hub。

   4. 1-2 周 MVP： 挑选一名患者，调取最近的 FHIR 资源，生成：

      • "当前问题；
      • "近期变更"；
      • "风险/随访项目"。

   5. 加分项：为不同角色生成不同摘要：ED 医生、护理经理、患者或家庭护理人员。

摘要

问题

• 使用非默认路径前缀时，部署无法为 FHIR 服务器、批量 FHIR、FHIR SQL 或相关安全用户界面提供服务。例如，在 Windows IIS、Apache 或其他网络服务器上使用逻辑路径配置时。
• 最常见的情况是使用单个 Web 服务器安装多个部署 ，或从 Web 服务器应用自定义逻辑路径来提供产品 UI 页面。

影响评估

受影响的配置无法从产品用户界面与 FHIR Server 功能交互 。 现有 API、终端和 ObjectScript 方法不受影响。

这会影响 InterSystems IRIS for Health 和 Health Connect 部署在所有支持 Web 服务器（IIS、Apache 和 Nginx）配置的操作系统上。

解决方法

• InterSystems 正在创建一套点版本来纠正这一问题：InterSystems IRIS for Health 2026.1.0.2 和 Health Connect 2026.1.0.2 将于 2026 年 4 月 14 日全面上市。

背景情况

急诊医疗服务（EMS）团队到达急诊科时，常常会遇到人口统计数据不完整或未知的病人——没有病历号（MRN），没有确认的姓名，有时甚至没有出生日期。然而，急救医疗运送记录仍然需要准确无误地记录在病历中。

为了支持安全可靠的记录，急救医疗机构、第三方集成服务和医院集成团队建立了安全接口，用于交换识别码和临床信息。当这些标识符不一致时，下游系统就无法自动发布转运记录，从而产生可避免的人工操作，并延误记录的完整性。本文概述了如何使用 FHIR Patient.Search (R4) 来填补最常见的人口统计空白并改进自动发布。

挑战

在许多 EMS 到医院的集成中，患者最初是以通用或临时标识符注册的。最终登记和任何记录合并可能要到稍后才会发生，有时是在出院后。在这些更新传播之前，EMS 患者标识符和电子病历 (EMR) 标识符可能一直不同步。

当转运记录因不匹配而无法发布时，集成通常会生成一个错误，并转到 EMR 工作队列进行人工审核。在 EMS 处理量大的情况下，队列会迅速增长。

简介

FHIR（快速医疗互操作资源）是存储和交换临床数据的现代标准。但是，一旦您的数据存储在 FHIR 服务器中，如何才能真正浏览这些数据呢？FHIR 数据以 JSON 格式存储，虽然功能强大，但直接读取并不实用。我希望有一种工具，可以让您点击病人，以简洁、可读的格式查看他们的病情、用药、化验结果等。于是，我创建了FHIR 患者查看器（FHIR Patient Viewer）。

如何运行

该应用完全在 Docker 中运行，并直接连接 InterSystems IRIS for Health FHIR 服务器。启动时，它会自动将 115 个合成患者载入 IRIS，无需手动设置。

• 浏览患者列表

• 点击任何患者，查看其所有临床记录

  

• 逐字段展开每条记录

• 随时查看底层原始 JSON 文件

  
   

数据

它预装了由Synthea生成的 115 个合成患者数据

Open Exchange 上有完整的源代码和设置说明：
https://openexchange.intersystems.com/package/FHIR-Patient-Viewer-2

欢迎反馈！

大家好！

我们很高兴地宣布推出一项新的实践培训计划：

🧑‍💻使用 Python 开发 FHIR 应用程序🧑‍💻

本课程以小组为基础，将开发人员从 FHIR 基础知识带入高级、真实的医疗互操作性解决方案，与典型的行业课程相比，课程内容更深入、更实用，并重点关注使用 InterSystems 技术的生产就绪技能。

第一批学员于 2026 年 2 月 15 日开课 ⚠️ 名额有限（一旦学员满额，报名者将被列入候补名单）。

谁应该参加？

本课程非常适合以下组织和团队参加

• 采用或扩展 FHIR
• 开发 SMART on FHIR 应用程序  
• 利用实用、真实的互操作性专业知识提高开发团队的能力

课程结构

该计划由三个渐进的 5 周模块组成。学员可以参加单个模块的学习，也可以完成为期 15 周的全部课程。

每周包括

• ~3 小时的异步视频和指导实验
• 1 小时由教师指导的现场互动讨论
• 两次讲座和一次动手实验室
• 可选的结课项目：SMART on FHIR 应用程序

模块概述

• 基础 （5 周）——扎实理解 FHIR 核心概念和实践基础，包括资源、REST 操作、搜索、验证和服务器交互。
• 中级 （5 周）——使用 Python 开发安全、可扩展的 FHIR 应用程序，包括 SMART on FHIR、批量数据访问、实施指南和负责任的人工智能集成模式。

InterSystems IRIS® 数据平台、InterSystems IRIS^® for Health 和HealthShare^® Health Connect 的2026.1版本现已全面上市 (GA)。这是一个扩展维护 (EM) 版本。

版本亮点：

• 数据库可扩展性增强：取消了历史数据库大小限制，实现了无缝增长，超过了以前的大小限制，无需进行数据转换。其他底层性能改进进一步优化了大规模操作。
• 表分区：根据用户定义的逻辑键拆分表和相关索引数据，以便在数据库间轻松映射。这可以实现存储分层，提高查询性能和超大表的运行效率。该功能是一项实验性功能，可通过 "早期访问计划"订阅更新并转达您的反馈意见。
• 互操作性用户体验改进：此更新具有新的 BPL 编辑器、对生产配置的额外改进以及 DTL 编辑器，其中包括人工智能辅助 DTL 解释。要了解更多信息，请访问InterSystems 学习中心。对于现有客户，这些功能仍可选择使用。在集成方面，该版本引入了 Mirth 迁移工具，以加速传统集成引擎的替换和现代化。
• FHIR 服务器授权、批量数据和管理更新： 大幅扩展 FHIR 功能，包括细粒度 OAuth 范围执行和结果过滤，从而实现更精确的数据访问控制。增强批量 FHIR（JWT 授权、从 EHR 计划导出）和更快的服务器/软件包管理。

在现代医疗保健领域，寻找临床上相似的患者往往感觉像大海捞针。传统的关键字搜索往往会失败，因为医学语言具有高度的细微差别；搜索 "心力衰竭 "可能会漏掉包含 "充血性心力衰竭 "的记录。

我很高兴与大家分享 iris-medmatch，这是一个基于InterSystems IRIS for Health的人工智能患者匹配引擎。通过利用矢量搜索（vector search），该工具能够理解临床意图，而不仅仅是匹配字面字符串。
## 核心创新：语义临床搜索

iris-medmatch "在原始FHIR数据和可操作的人工智能洞察力之间架起了一座桥梁。该引擎利用 "all-MiniLM-L6-v2 "模型，将临床条件转化为数学向量。

标准搜索查找的是准确的单词，而该引擎能理解**临床上下文**。例如，它可以使用数学向量相似性将 "高血压 "患者与 "高血压 "搜索匹配起来。

✨ 主要技术特点

• 核心：InterSystems IRIS、嵌入式 Python、InterSystems FHIR 服务器、矢量搜索
• 人工智能：Python、ONNX 运行时、HuggingFace 变换器
• 前端Angular 18+

技术架构

该解决方案的优势在于其架构效率。通过嵌入式 Python 运行 Transformers，我们消除了 "数据重力 "问题。数据留在 IRIS 中，人工智能处理在数据所在的地方进行。

🚀应用演练

1.