正在进行的选举

时间是2026年8月，巴西的大选竞选活动正在进行中。 10月4日，158,745,463名符合条件的选民将投票选举总统、各州州长、参议员、联邦众议员以及各州或联邦区众议员。总统和州长选举的第二轮投票（如有）定于10月25日举行。上述日期和选民人数数据均来自巴西最高选举法院。

在这个时间节点上，随着数百万民众试图了解候选人背景、竞选主张及公共履历，公共信息已成为当务之急。巴西虽公开了大量选举和立法数据，但这些记录仍分散在各类文件、API、标识符及政府门户网站中。

正是在这样的背景下，我们开发了“TSE公共数据RAG探索器”。

开放数据丰富，但要得出答案却并非易事

一个看似简单的问题，可能需要有人先找到一个API，然后进行分页操作，下载ZIP压缩包，解码Latin-1格式的CSV文件，从PDF中提取文本，理解两个机构的标识符，在它们之间建立个人关联，最后阅读冗长的文档。

主要障碍在于数据访问：定位、关联并解读通过不同来源发布的记录。

该项目始于一个问题：

在选举年，我们如何将关于候选人和当选官员的海量公共数据转化为任何公民都能探索的信息？

该解决方案在孤立的过滤器以及语言模型的内部记忆之外，增添了一层基于证据的研究层。在敏感领域，可检索的证据是每个流畅回答的必要条件。

基于官方证据的自然语言处理层

TSE 公共数据 RAG 探索器与其说是一个选举聊天机器人，不如说是一个公共数据智能平台。

我们发布了首个在 InterSystems ObjectScript 和 IRIS 平台上衡量 LLM 能力的开放式基准测试：ObjectScript LLM 基准测试。

为何推出该基准

现有的编程基准测试——SWE-bench、LiveCodeBench、Terminal-Bench——均基于 Python、 JavaScript 和 shell 语言。其中没有一项涵盖 ObjectScript、IRIS SQL、嵌入式 Python 或 %CSP.REST。 已发布的编程评分无法直接应用于 IRIS 平台。这是首次尝试 直接衡量这一差距。

我们测量的内容

140个手工编写的项目，涵盖三个类别：代码生成、代码理解和错误修复。 主要评分器是一个实时运行的 IRIS 实例——模型响应会被编译并执行， 输出结果与预期字符串进行比对。对于 93 个基于执行结果评分的 题目，不存在主观评分。47 个理解类题目则采用基于评分标准的 LLM 评判器。

我们运行了14个模型（Claude 4.x/5、GPT-5变体以及三个自托管的Qwen3/DeepSeek模型）， 均采用其可用的最高推理配置，每个项目在温度为0的条件下生成一个响应。

总体结果

总体准确率在0.515至0.851之间。 排名前九的模型集中分布在 0.737 至 0.

Open Exchange 上有许多实用的项目，但很容易被忽略。如果你使用 InterSystems IRIS 进行开发，以下这 10 个项目值得收藏。

在完成了一堂内容丰富的数学课后，我们将把新学到的知识付诸实践，创建一个最优秀的上下文相关数据库之一。

快把放大镜和帽子准备好，因为向量·福尔摩斯又回来了。

你可能之前听说过“向量搜索”这个词。不过别担心，这可不是“向量·福尔摩斯”在贝克街221B号侦破案件。

那么，让我们一步一步地讲解如何处理向量数据搜索。

借助 PollingBusinessService 提升开发者体验

4.0.0 版本中最引人注目的新增功能之一是 PollingBusinessService。

在此版本之前，创建定时 Python 业务服务意味着需要 直接处理低级入站适配器模式。在 4.0.0 版本中，定时 Python 入口点可以直接编写为 PollingBusinessService， 框架会在后台自动使用默认的 IRIS 入站适配器。

以下是一个完整的小型示例：

from dataclasses import dataclass

from iop import BusinessOperation, Message, PollingBusinessService, Production, target


@dataclass
class HelloRequest(Message):
    text: str = "Hello World"


class HelloService(PollingBusinessService):
    Output = target()

    def on_poll(self):
        self.send_request_async(self.Output, HelloRequest())


class HelloOperation(BusinessOperation):
    def on_message(self, request: HelloRequest):
        self.log_info(request.text)
        return request


prod = Production("HelloWorld.Production", testing_enabled=True)
service = prod.service("HelloService", HelloService)
operation = prod.operation("HelloOperation", HelloOperation)
service.connect(HelloService.Output, operation)

PRODUCTIONS = [prod]

这一切始于我乘火车去看望父母的途中，当时我正和隔壁包厢的一位邻居聊天。像往常一样，话题转到了科技上，她抛出了一个非常具体的问题：“ChatGPT 能用来分析人类基因组吗？”我对它能否完成如此复杂的事情持高度怀疑态度。 但这个问题始终萦绕不去，深深扎根于我的脑海。等我踏进家门时，我的怀疑已经转变为一种挑战。 虽然手头没有基因组测序数据集，但我确实想看看标准的ChatGPT能否利用PyProd包从零开始构建一个可运行的互操作性生产环境。况且，这还能让我有机会参与“从构想到应用”社区赏金计划的第一轮，实现第三个创意。

在我的第一篇文章中，我介绍了 FHIR 患者快照代理的基础版本：这是一个基于 Streamlit 和 Python 的应用程序，它从 InterSystems IRIS for Health 中检索 FHIR 资源，并利用大型语言模型（LLM）生成简明扼要的患者摘要。

本文作为后续文章，将介绍我是如何通过添加两项针对 InterSystems 的功能来扩展该项目的：

• 源上下文向量搜索
• 用于 IRIS 兼容审查的嵌入式 Python 组件

目标是让该项目作为临床摘要原型更具实用性，同时保持设计足够精简，以便于理解和复现。

项目回顾

FHIR 患者快照代理（FHIR Patient Snapshot Agent）是一款基于人工智能的 FHIR 患者数据摘要工具。

该应用程序可检索所选患者的结构化资源：

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

Python 层将这些资源整合为一个紧凑的患者背景。用户随后可以生成以下任一内容：

• 确定性摘要，或
• 由大型语言模型（LLM）生成的针对特定角色的摘要

该 LLM 集成通过兼容 OpenAI 的聊天补全 API 使用 Nebius Token Factory。演示中使用的模型为：

该项目为开源项目：

项目链接

• 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 应用程序不会直接读取本地临床文件。

大家好， 

我创建了一个简短的演示和参考代码库，展示了如何将 Auth0 配置为 InterSystems IRIS FHIR 服务器的 OAuth 提供商，以及如何从 Python Flask 应用程序调用受保护的 FHIR 资源。 

以下链接包含一段视频演示以及一个 GitHub 仓库，其中包含视频中使用的示例应用程序 

链接 

视频演示： 

GitHub 仓库：https://github.com/MarshyKid/iris-fhir-oauth-demo

在问诊前，人工智能助手会先阅读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 则让这一切变得简单明了。

太长不读版（TL;DR:）:本文演示了如何利用iris-vector-graph包，完全在 InterSystems IRIS 环境中实现 GraphRAG 风格的混合检索——该方法结合了向量相似度、图遍历和全文搜索。 我们通过一个欺诈检测场景，展示了图模式如何揭示仅靠向量搜索无法发现的问题。

为何欺诈检测需要图技术

每年，企业和消费者因欺诈损失数十亿美元。仅在2024年，消费者报告的损失就达125亿美元——同比增幅达25%。 现代欺诈之所以难以被发现，是因为欺诈者很少单独行动。他们通过有组织的网络运作，实施协调一致的骗局，利用我们无法察觉看似无关的交易之间存在关联这一弱点。

举个简单的例子：从账户 A 转账至账户 B 的单笔交易看起来完全正常。金额合理，时间点符合常规，且两个账户均未被标记为可疑。传统的基于规则的系统，甚至那些孤立分析交易的机器学习模型，都会毫不犹豫地批准这笔交易。

但如果我们能看到全局呢？

同一笔交易其实是环形模式的一部分——资金在循环流动，每一步都会被截留一小部分。这是一种典型的洗钱结构，对于任何不分析交易关联性的系统来说，都是隐形的。

这一洞见——即欺诈隐藏在关联关系中，而非单个记录中——正是图数据库成为欺诈检测不可或缺工具的原因。

大家好，

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

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

🏥 关于 iris-fhir-agents 应用

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

大家好，

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

Intersystems_pyprod 是InterSystems Python Productions 的简称，它是一个 Python 库，使开发人员能够完全使用 Python 构建这些互操作性组件。该库设计灵活，支持混合方法：您可以将基于 Python 的新组件与现有的基于 ObjectScript 的组件无缝地混合在一起，并充分利用已建立的 IRIS 基础架构。这些 Python 组件一旦定义，就可以像其他组件一样进行管理；可以使用 IRIS 生产配置页面添加、配置和连接这些组件。

快速了解 InterSystems IRIS 生产系统

生产的关键要素

图片来自Learning Services培训材料

IRIS 生产系统通常从外部接口接收数据，通过协调的步骤进行处理，并将其传送到目的地。当信息在系统中移动时，它们会被自动持久化，从而通过 IRIS 的可视化跟踪和日志工具对整个流程进行全面跟踪。该架构依赖于某些关键要素：

1. 业务主机：这些是核心构件--服务、流程和操作--它们在彼此间传递可持久化的信息。
2. 适配器：入站和出站适配器管理与外部世界的交互，处理接收和发送数据所需的特定协议。
3. 回调：引擎使用特定的回调方法在主机之间同步或异步地传递消息。这些回调方法遵循严格的签名，并返回一个 Status 对象，以确保执行的完整性。

在基于 InterSystems IRIS 开发 Python 应用时，你很快就会发现存在多种执行上下文：

• 由 IRIS 直接启动的 Embedded Python；
• 加载本地 IRIS 安装中 Embedded Python 库的常规 python3进程；
• 通过官方原生驱动连接 IRIS 的外部 Python 应用。

这三种场景都非常有用，但在导入机制、系统配置、对象 API 以及 SQL 访问方面，它们的行为并不完全一致。iris-embedded-python-wrapper项目提供了一个稳定的 Python 门面（Facade），旨在减少这些差异，并提供一个统一的入口点：import iris。

存在的问题

在一个围绕 IRIS 构建的 Python 项目中，同一份代码可能需要在多种环境中运行：

• 在 IRIS 终端中，通过 iris python iris或 iris session iris后输入 :py；
• 通过 启动的本地 Python 脚本；
• 连接到 IRIS 实例的远程 Python 服务。

如果没有抽象层，许多细节往往就需要分别处理：

• Embedded Python 的 iris模块只有在 IRIS 运行时被正确加载时才可用；
• 原生 SDK​ 同样暴露了一个 包，这可能导致冲突或产生歧义的导入；
• 和 DB-API 连接在嵌入式模式和

大家好👋
我很高兴与大家分享我提交给本届InterSystems .Net、Java、Python 和 JavaScript 竞赛的项目——它叫做IRIStool 和 Data Manager，您可以在InterSystems Open Exchange和我的GitHub 页面上找到它。

今天，我发布了一个新的Open Exchange 软件包，用于直接在 IRIS 中生成合成数据。

当你想制作一个演示应用程序时，找到合适的数据集是一个令人沮丧的过程。也许数据集并不那么重要，但您仍然希望它看起来有点真实，并有几个链接表，可以直接在 IRIS 中使用 -> 的隐式连接。也许您只是想让链接表可以很容易地安装到 IPM 中，用于基准查询，那么这种数据集生成方式就再好不过了。

我选择使用嵌入式 Python 创建数据集，这些数据集可通过自定义配置文件进行配置。这些数据集直接用一个 IRIS 类方法生成，并可使用乘数进行缩放，以创建任意大小的数据集，而无需测量配置。

目前我有四个数据集：
- 金融服务（如银行卡、账户、交易）
- 零售（商店、产品、用户、库存）
- 供应链（产品、销售订单、库存移动）
- 主题公园管理（公园、区域、游乐设施、事故）

我不是这些领域的专家，所以我怀疑它们是否超级准确，而且数据生成使用了 faker 等 python 库，统计加权生成使用了 numpy，所以感觉有点人工合成。

老实说，作为一个我无法投入大量时间的副业项目，这个项目的成功离不开人工智能。我在设计数据集和生成创建数据集的代码时广泛使用了人工智能。我监督、测试了个人使用的案例，并积极参与了项目设计，但代码都是人工智能生成的，我没有仔细审查过数据集的生成过程。

高级工程的定义不在于代码量的多少，而在于策略性地避免代码量。在复杂的集成环境中，倾向于利用通用库来满足每一个细分需求会带来不必要的开销。要实现真正的架构成熟，就必须致力于 "最小化工具"--优先考虑有弹性、经过实战检验的系统实用程序，而不是自定义逻辑。本评估将检查我们的 PGP 加密/解密流水线，以展示如何从应用级库转向操作系统本地授权，从而提高系统的耐用性。

现状：重量级实现

我们当前的 MPHP.HS.PGPUtil 类是一种高摩擦设计。现有的 InterSystems IRIS 业务流程虽然功能强大，但依赖性很强。通过桥接嵌入式 Python 来使用 pgpy 库，我们引入了一个 "重型 "堆栈，需要 Python 运行时、第三方库管理和特定的加密二进制文件。

处理文件通常很简单：打开文件，读取并处理。这种方法非常有效，直到文件碰巧是 Excel 文件。

常见假设

起初，Excel 文件（.xlsx）看起来就像另一个数据文件，行、列和值。因此，我们很自然地认为它可以像 .txt 或 .csv 文件一样被读取。但问题就出在这里。

Excel 文件为何表现不同

关键区别在于数据的存储方式：

-> .txt / .csv - 纯文本，逐行存储。

-> .xlsx - 压缩、结构化格式（非纯文本）

excel 文件实际上不是一个简单的可读行流。从内部看，它是一个包含结构化数据的打包文件，标准文件读取命令无法解释这些数据。

如果把它当作文本文件处理，会发生什么情况？

• 执行过程中出现错误
• 输出看起来无法阅读

重要事项 --> 这不是限制，而是工具和文件格式不匹配 。

实用的处理方法

与其只使用基于文本的方法，还有更好的选择、

• 转换为 CSV
• 嵌入 Python （pandas 或 openpyxl 等库）
• IRIS 互操作性工具

如果有人曾在 IRIS 中处理过 Excel 文件，或有其他行之有效的方法，请随时分享。）

下面提到几个例子。

大家好！

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

🧑‍💻使用 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、批量数据访问、实施指南和负责任的人工智能集成模式。

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

我很高兴与大家分享 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.