利用 IRIS for Health、Streamlit 和大型语言模型（LLM）构建 FHIR 患者快照代理

项目链接

• GitHub：https://github.com/vinogrannia/fhir-patient-snapshot-agent
• 在线演示：https://fhir-patient-snapshot-agent.onrender.com/
• YouTube 演示：https://youtu.be/Hsu10Nnujng

概述

FHIR 患者快照代理（FHIR Patient Snapshot Agent）是一款专为 InterSystems AI 代理和 FHIR 编程竞赛开发的小型开源应用程序。

该项目实现了建议的“智能患者摘要生成器”构想：它检索所选患者的结构化 FHIR 资源，并生成一份简明扼要、针对特定角色的患者摘要。

其目的并非进行诊断或推荐治疗方案。该代理仅作为摘要生成助手，所有生成的内容都必须与源FHIR数据进行核对验证。

InterSystems IRIS for Health 的应用方式

该应用程序使用 InterSystems IRIS for Health 作为 FHIR 互操作性层。

在本地部署环境中，IRIS for Health 提供了一个 FHIR R4 API。Python 应用程序通过查询该 API 来获取与患者相关的资源，包括：

• 患者
• 病情
• 用药请求
• 过敏与不耐受
• 观察
• 就诊
• 护理计划

该 Python 应用程序不会直接读取本地临床文件。IRIS for Health 返回的 FHIR 资源被视为摘要的权威来源。

应用工作流

工作流如下：

1. 用户输入一个 FHIR 患者 ID。
2. Python FHIR 客户端向 IRIS for Health FHIR R4 API 发起查询。
3. 标准化层提取患者人口统计信息、当前及既往病症、用药情况、过敏史、近期观察结果、就诊记录和护理计划。
4. 观察数据被分类为生命体征、实验室检查、问诊/社会史及其他观察数据。
5. 该应用可生成以下任一内容：
   • 确定性的 Markdown 摘要，
   • 一个大语言模型（LLM）提示词预览，
   • 或由大型语言模型生成的摘要。
6. 用户界面将源FHIR资源显示在可折叠的审查区域中，以便将生成的内容与原始数据进行核对。

LLM 集成

该 LLM 集成通过兼容 OpenAI 的聊天补全 API 使用 Nebius Token Factory。

已配置的模型为：

提示词采用了安全框架设计。它明确要求模型不得进行诊断、推荐治疗方案、制定新的护理计划、建议调整用药，或推断源FHIR上下文中不存在的事实。

该应用还支持针对以下角色的专属摘要：

• 临床医生
• 急诊科医生
• 护理经理
• 患者
• 家庭护理人员

每个受众群体使用的必填部分模板和措辞风格各不相同。

Streamlit 用户界面

Streamlit 用户界面允许用户：

• 输入患者 ID，
• 选择确定性摘要、LLM提示词预览或LLM摘要，
• 选择目标受众，
• 生成患者快照，
• 查看代理所使用的源 FHIR 资源。

该托管在线演示以公共演示模式运行，使用从本地 IRIS for Health FHIR 服务器配置中捕获的预打包“患者 1”数据。这可避免在公共部署中暴露私有的本地 FHIR 端点或 LLM API 密钥。

完整的实时 FHIR 工作流仍本地运行于 InterSystems IRIS for Health 上。

Docker 的使用

Docker 有两种使用方式：

1. 本地 InterSystems IRIS for Health FHIR 服务器通过外部的 InterSystems 社区 FHIR 模板运行。
2. 该代码库包含一个 Dockerfile 和 docker-compose.demo.yml 文件，用于运行 Python/Streamlit 在线演示模式。

可通过以下命令启动演示容器：

随后可通过以下地址访问该应用：

设置过程中发现的一条简短文档说明

在配置本地 InterSystems 社区 FHIR 模板时，我注意到一个可能影响初次使用者的文档细节。

该模板的 README 文件中列出了诸如以下形式的 FHIR API 测试 URL：

在我的本地 Docker 环境中，未经身份验证的请求返回了以下内容：

当提供 Basic Auth 凭据时，相同的端点即可正常工作：

这似乎是一个改进文档的小机会：添加一个经过身份验证的 curl 示例，并补充说明可通过 `docker ps` 命令检查映射的 Docker 主机端口，这样能让 FHIR API 验证的第一步更加清晰。

我已在此处提交了该建议：

https://github.com/intersystems-community/iris-fhir-template/issues/37

该项目为何有用

FHIR系统通常包含正确的信息，但这些信息分散在许多资源中。患者快照可以帮助用户在查看详细信息之前，快速了解源数据中包含哪些内容。

该原型展示了 AI 代理如何构建在 FHIR 互操作性层之上，在保持源资源可追溯性的同时生成结构化摘要。

最重要的设计原则是安全性：该代理仅对源数据进行摘要处理，绝不取代临床判断。

当前状态

该项目目前包括：

• 可运行的FHIR客户端逻辑，
• 针对多种FHIR资源类型的标准化处理，
• 确定性摘要模式，
• LLM提示词预览模式，
• 与Nebius/OpenAI兼容的LLM摘要模式，
• 基于角色的提示，
• Streamlit 网页界面，
• 托管在线演示，
• Docker 演示部署，
• 单元测试，
• 屏幕截图，
• YouTube 演示视频。

结论

这是我首次参与 InterSystems 竞赛。该项目帮助我学会了如何将 InterSystems IRIS for Health FHIR 服务器、Python、Streamlit、Docker 以及兼容 OpenAI 的 LLM 工作流结合起来，构建出一个虽小但功能完备的 AI 代理。

最终成果是一个实用的FHIR患者快照代理，它展示了如何将结构化的FHIR数据转换为通俗易懂且基于原始数据的临床摘要。