作为我们致力于提升 FHIR 有效载荷导入速度工作的一部分,在 v2026.2 版本(目前已作为开发者预览版发布)中,我们引入了一项可选功能,用于跳过资源的结构验证。 例如,此举可节省 25% 的时间,在大规模数据导入场景中,这一时间节省将十分可观。
快速医疗保健互操作性资源(FHIR,发音为“fire”)是描述数据格式和元素(称为“资源”)的标准草案,也是用于交换电子健康记录的应用程序编程接口 (API)
作为我们致力于提升 FHIR 有效载荷导入速度工作的一部分,在 v2026.2 版本(目前已作为开发者预览版发布)中,我们引入了一项可选功能,用于跳过资源的结构验证。 例如,此举可节省 25% 的时间,在大规模数据导入场景中,这一时间节省将十分可观。
流行病学监测是公共卫生的基石之一。 Régis Júnior等人(2026)将其定义为一个针对健康事件的持续性数据收集、分析、解读和传播系统——该功能的有效性在很大程度上取决于信息系统的质量、数据分析能力以及不同医疗层级之间的协调。 在新冠疫情期间,这一职能的战略重要性已毋庸置疑:世界卫生组织(2021)的记录显示,拥有更健全监测系统的国家始终表现得更好,而监测能力方面的区域差异则直接导致了应对措施的不一致,并在发病率和死亡率方面产生了可测量的差异。
尽管医疗系统如今能够收集海量的标准化临床数据,但挑战在于如何将这些数据转化为及时且可付诸行动的洞见。传统的流行病学报告往往依赖于人工分析和定制数据库查询,由此产生的延迟可能会阻碍公共卫生部门的快速响应。
EpInsights通过整合 InterSystems IRIS for Health、嵌入式 Python 临床向量化技术、IRIS Vector Search 以及 LangChain4j 对话式智能助手,填补了这一空白。 该平台使流行病学家和卫生管理者能够提出自然语言问题,并即时获得基于真实FHIR数据的地理空间热力图、区域排名、相似聚类检测以及AI生成的建议,所有结果均在数秒内呈现。

EpInsights 采用三层架构,各层职责划分明确。
随着 v2026.1 版本的发布,HL7 FHIR 引入了一项非常重要的功能——支持SMART on FHIR v2 的细粒度作用域。
这使您能够对 FHIR 存储库中数据的访问权限进行更严格、更精确的控制。
这项新功能的一部分是拒绝不符合范围的请求,但更有趣的功能是能够根据提供的范围过滤结果。
在 v2026.2 版本(目前作为开发者预览版提供)中,我们新增了一项功能,可协助完成 FHIR 端点的 SMART/OAuth 授权——在受众值验证方面提供了更多开箱即用的灵活性。
在 v2026.2 版本(现已开放预览)中,我最期待的新功能之一就是“FHIR 资源管理器”。
作为 InterSystems FHIR 服务器的一部分,这项新功能允许用户通过友好且直观的用户界面探索 FHIR 数据:该界面能够构建(可能较为复杂的)FHIR 搜索 URL,将其发送至您的 FHIR 服务器(实际上是任何 FHIR 服务器……)进行查询,并显示查询结果。
以下是一个简单的操作流程:

要成功构建和部署人工智能代理以应对医疗保健领域的各种用例,关键在于高质量的数据和API,以及有效的治理与管理。 InterSystems IRIS FHIR 服务器不仅能满足上述所有需求,还精通 Python、向量搜索和互操作性。结合强大的大型语言模型(LLM),患者、医生、护理人员和管理者将能够利用最先进的技术来改善个人健康和公共卫生。
本文利用 InterSystems IRIS FHIR 存储库、FHIR API、嵌入式 Python 以及向量搜索作为数据服务和 API,从而使部署在 Ollama 上的 LLM lhama3 能够处理以下用例:临床摘要、 通过API使用自然语言探索FHIR数据、AI生成的患者临床指标图形分析,以及利用向量搜索进行病例相似性比较等用例。
1. 访问 Open Exchange 并查找应用程序 fhir assistant(https://openexchange.intersystems.com/package/fhir-assistant)
2. 将代码库克隆/通过 Git 拉取到任意本地目录:
$ git clone https://github.com/yurimarx/fhir-assistant.git3.
FHIR 患者快照代理(FHIR Patient Snapshot Agent)是一款专为 InterSystems AI 代理和 FHIR 编程竞赛开发的小型开源应用程序。
该项目实现了建议的“智能患者摘要生成器”构想:它检索所选患者的结构化 FHIR 资源,并生成一份简明扼要、针对特定角色的患者摘要。
其目的并非进行诊断或推荐治疗方案。该代理仅作为摘要生成助手,所有生成的内容都必须与源FHIR数据进行核对验证。
该应用程序使用 InterSystems IRIS for Health 作为 FHIR 互操作性层。
在本地部署环境中,IRIS for Health 提供了一个 FHIR R4 API。Python 应用程序通过查询该 API 来获取与患者相关的资源,包括:
该 Python 应用程序不会直接读取本地临床文件。
大家好,
我创建了一个简短的演示和参考代码库,展示了如何将 Auth0 配置为 InterSystems IRIS FHIR 服务器的 OAuth 提供商,以及如何从 Python Flask 应用程序调用受保护的 FHIR 资源。
以下链接包含一段视频演示以及一个 GitHub 仓库,其中包含视频中使用的示例应用程序
链接
视频演示:
在问诊前,人工智能助手会先阅读FHIR患者病历,根据已掌握的信息提出恰当的问题,识别关键的警示信号,并将分析结果反馈给医生——这样医生就能做好充分准备。
该项目灵感源自InterSystems编程大赛“FHIR人工智能代理”中建议的第10项任务(对话式FHIR分诊助手)。
在患者走进诊室之前,一个关键的疏漏已经发生:没有人阅读过他们的病史。医生只有15分钟的时间。患者不得不第三次向医生重复自己的病情、用药情况和过敏史——这已经是今年第三次了。 诸如华法林治疗期间的出血、心力衰竭伴随的胸痛、抑郁症伴随的自杀意念等“危险信号”,要么直到为时已晚才被询问,要么根本未被提及。
这并非技术上的缺口。 数据是存在的。它们存储在分布于不同系统中的数据仓库中,其中包含患者的纵向病历,涵盖病情、用药情况、实验室检查结果、过敏史及就诊史。真正的缺口在于诊疗现场的智能辅助——一个能在就诊前阅读病历、根据已知信息提出恰当问题,并将分析结果反馈给医生,使医生做好充分准备的智能助手。
在技术示例应用TriageAide中,我们以具体场景为切入点,探索如何将 InterSystems IRIS FHIR 服务器、模型上下文协议(MCP)和生成式人工智能(Generative AI)结合使用。该应用是一款人工智能助手,旨在优化患者接诊流程和临床交接工作。
大多数“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 的细粒度作用域来实现的。

![]()
我很高兴与大家分享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驱动的医疗保健工作流。
您还可以在此处查看更多信息:
GitHub 代码库:https://github.com/SeanConnelly/ai-studio-for-fhir
Open Exchange 页面:https://openexchange.intersystems.com/package/FHIR-Agent-Studio

我很高兴地告诉大家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 存储库,此外还提供一个面向临床医生的应用程序和一个面向患者的手机 应用程序,均运行在同一后端上。每次运行的每个步骤均可追溯。
应用程序界面已开放——只需点击即可探索:
| Link | |
|---|---|
| 引导式演示——从这里开始,快速了解全部十二个智能助手 | https://fhir-agent-studio.sandbox.developer.intersystems.com/clinical/#/demo |
人工智能将改变医疗保健行业,但前提是临床医生能够信任它,而开发人员 在构建它时无需每次都从头开始重新设计基础架构。 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位社区成员开发了
本次竞赛收到了令人印象深刻的参赛作品,每一件都体现了创新精神和创造性思维。面对如此众多优秀的参赛作品,评选出最佳作品确实是一项艰巨的任务。

让我们来认识一下获奖者,并了解他们的项目:
该方案成功将医疗设备数据纳入全院数据管理,实现了医疗设备数据的全流程高效采集与应用。
我很高兴与大家分享我提交至本期InterSystems .Net、Java、Python 和 JavaScript 竞赛的项目——它名为“支持混合搜索和 AI 摘要的 FHIR 数据探索器”,您可以在InterSystems Open Exchange以及我的GitHub 页面上找到该项目。
大家好,
你是否曾希望你的电子健康记录(EHR)能具备思考能力?不仅仅是显示数据,也不仅仅是触发警报。而是能够真正阅读病历、综合临床指南进行分析,并根据临床医生的单条信息,向系统生成结构化的转诊医嘱。
在本文中,我将向大家展示如何创建您自己的定制临床AI助手。
iris-fhir-agents是一个完全基于 InterSystems IRIS for Health 构建的多智能体临床 AI 平台

大家好,
在本文中,我将介绍我的应用程序iris-fhir-agents 这是一个由 InterSystems IRIS for Health 驱动的多智能体临床 AI 平台。该平台包含用于分诊、专科会诊、用药安全以及 FHIR 服务器探索的智能体——所有功能均基于 IRIS Vector Search RAG 构建。 平台包含一个无代码代理构建器,让您无需编写任何代码即可设计和部署自定义临床代理。
当将 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 个额外积分 (!) - 每个应用程序一次
智能患者摘要生成器
功能:从 FHIR 数据中创建简洁、便于临床医生使用的患者摘要,包括病情、用药、过敏症、最近就诊情况、化验和护理计划。
FHIR 资源:Patient, Condition, MedicationRequest, AllergyIntolerance, Observation, Encounter, CarePlan.
平台功能:FHIR API、FHIR SQL Builder、AI Hub。
1-2 周 MVP: 挑选一名患者,调取最近的 FHIR 资源,生成:
加分项:为不同角色生成不同摘要:ED 医生、护理经理、患者或家庭护理人员。
|
咨询 ID |
受影响的产品和版本 |
风险类别和评分 |
明确要求 |
|
IF-9396 |
InterSystems IRIS® for Health InterSystems Health Connect™ 版本 |
系统稳定性问题:3 |
受影响的配置无法从产品用户界面与 FHIR Server 功能交互 。 现有 API、终端和 ObjectScript 方法不受影响。
这会影响 InterSystems IRIS for Health 和 Health Connect 部署在所有支持 Web 服务器(IIS、Apache 和 Nginx)配置的操作系统上。
急诊医疗服务(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 日开课 ⚠️ 名额有限(一旦学员满额,报名者将被列入候补名单)。
本课程非常适合以下组织和团队参加
该计划由三个渐进的 5 周模块组成。学员可以参加单个模块的学习,也可以完成为期 15 周的全部课程。
每周包括
InterSystems IRIS® 数据平台、InterSystems IRIS® for Health 和HealthShare® Health Connect 的2026.1版本现已全面上市 (GA)。这是一个扩展维护 (EM) 版本。
版本亮点:
在现代医疗保健领域,寻找临床上相似的患者往往感觉像大海捞针。传统的关键字搜索往往会失败,因为医学语言具有高度的细微差别;搜索 "心力衰竭 "可能会漏掉包含 "充血性心力衰竭 "的记录。
我很高兴与大家分享 iris-medmatch,这是一个基于InterSystems IRIS for Health的人工智能患者匹配引擎。通过利用矢量搜索(vector search),该工具能够理解临床意图,而不仅仅是匹配字面字符串。
## 核心创新:语义临床搜索
iris-medmatch "在原始FHIR数据和可操作的人工智能洞察力之间架起了一座桥梁。该引擎利用 "all-MiniLM-L6-v2 "模型,将临床条件转化为数学向量。
标准搜索查找的是准确的单词,而该引擎能理解**临床上下文**。例如,它可以使用数学向量相似性将 "高血压 "患者与 "高血压 "搜索匹配起来。
该解决方案的优势在于其架构效率。通过嵌入式 Python 运行 Transformers,我们消除了 "数据重力 "问题。数据留在 IRIS 中,人工智能处理在数据所在的地方进行。
🚀应用演练
1.
什么是 FHIR Profile??
FHIRProfile是规则和约束的集合,用于定制和完善基础快速医疗互操作性资源 (FHIR) 资源(resource)。Profiling是一个重要的过程,它可以调整基础 FHIR 资源标准,以满足特定用例、地理区域、医疗机构或临床工作流程的独特要求。
基础 FHIR 规范为资源(如病人、观察或药物)提供了通用、灵活的定义,而Profiling则将这些通用资源转化为更精确的资源。这就确保了为特定社区或实施量身定制的数据交换的一致性和互操作性。
FHIR 旨在覆盖全球各种医疗保健场景。配置文件允许实施者在不丧失标准化优势的情况下调整这一通用平台。