.png)
InterSystems IRIS for Health™ 是全球第一个也是唯一一个专门为医疗应用程序的快速开发而设计的数据平台，用于管理全世界最重要的数据。它包括强大的开箱即用的功能：事务处理和分析、可扩展的医疗保健数据模型、基于 FHIR 的解决方案开发、对医疗保健互操作性标准的支持等等。所有这些将使开发者能够快速实现价值并构建具有突破性的应用程序。了解更多信息。
| 安全通告编号 | 受影响的产品 | 风险类别与评分 | 明确要求 |
| DP-456155 |
所有使用基于浏览器的XSLT的现有InterSystems互操作性产品和解决方案，包括：
|
运行状态：高 | 客户必须在浏览器变更前应用可用的产品更新，或采用下文所述的临时缓解措施。 |
简而言之：InterSystems IRIS for Health 允许开发人员直接在后端 ObjectScript 例程中执行 FHIR CRUD 操作，而无需依赖 HTTP REST 层。通过使用 HS.FHIRServer.Service，开发人员可以创建服务上下文、构建动态查询、验证模式，并高效地检索 FHIR 资源。
传统的 FHIR 实现通常通过 HTTP/REST 管道处理请求。本文探讨了绕过该层、直接在 IRIS 后端执行 FHIR 操作时的情况，重点介绍了该方法涉及的架构、服务上下文、查询处理、验证和资源访问。
本文适用对象：本指南专为InterSystems IRIS for Health、HealthShare 和 Health Connect 开发人员，以及需要在不依赖外部 HTTP 端点的情况下，直接在后端 ObjectScript 例程中执行低开销 FHIR 操作的医疗信息学工程师而设计。
部署在 InterSystems IRIS for Health、HealthShare 和 Health Connect 上的标准 FHIR 实现，依赖于通过 REST 应用层映射到 HS.FHIRServer.Service 的入站 HTTP 管道。
InterSystems IRIS可以很容易以动态对象(Dynamic Object) 方式操作JSON，但动态对象没有 schema，DTL 图形编辑器里没有字段可以拖拽。本文介绍一个把 JSON 报文做成 Virtual Document 的实现（下文称 JVDoc）：schema 来自 JSON Schema 或样例 JSON，DTL 编辑器、规则编辑器、搜索表和校验都能直接使用，报文本身仍然原样保存、无损透传。文末给出可以直接运行的测试用例。
在集成项目里处理 JSON 很常见，动态对象(Dynamic Object) 来处理JSON也很好用，但它没有schema，带来三个麻烦：
Document.{ 得到字段提示。常见的办法是用 %JSON.Adaptor 生成类。它能解决图形化映射，但有两个代价：每条报文都要先实例化为对象，大报文成本高；schema 里没有的字段在导入时会被丢掉，做不到无损透传。
IRIS的虚拟文档架构（Ens.VDoc.Interface）本来就是为没有对应类的结构化文档设计的：编辑器通过它取得字段树，运行时通过路径读写值。
为什么同一个人有两条记录，名字却不同？当相似的记录包含相互冲突的标识符时，系统应如何处理？当关键信息缺失时，系统应给出建议，还是应向来源方索取更多证据？
这些问题促使我开发了**“患者身份冲突审查助手”**。我希望在互操作性工作流中嵌入一个人工智能代理，供人工审查并可随时暂停。该代理负责收集证据并推荐处理方案；而人工审查员则负责授权记录之间的关联。
该应用程序使用了InterSystems IRIS Community AI Hub EAP 版本 154 中的原生 ObjectScript SDK。本文描述的是 pi-review1.1.0版本（提交编号 ab53930）。 所有案例和源数据均为合成数据，与任何医院均无关联。模型使用情况来自保存的实时呼叫记录。
项目链接：GitHub 代码库·Open Exchange 应用程序 (1.1.0)·带版本号的安装指南。下文所述的实现基于已固定的 1.1.0 源代码。
合成案例 c6 最初缺少身份标识符和出生日期。一名操作员明确启动了调查。代理读取了该案例，验证了其来源，检索了治理规则，并返回了 NEEDS_DATA。随后，生产环境通过原生 MCP 请求了数据丰富处理。
当操作员获取数据丰富结果时，服务器在更新案例前检查了收据、来源范围和版本。随后，操作员显式地启动了另一项调查
大家好， 在本系列的第一部分中，我们构建了用于镜像、主节点、备用节点和仲裁器的三个容器，创建了镜像，并将备用节点加入其中。 本部分将从那里继续，此时两个故障转移成员均已定义，仲裁器即将启动。内容涵盖如何正确读取仲裁器的连接状态、一夜之间完全自动发生的故障转移，以及因我在测试前等待时间不足而导致的数据库成为孤儿的情况。第 3 部分将进入分片（Sharding）环节。
在仅定义了主节点（Primary）的情况下创建镜像后，系统操作（System Operation）→ 镜像监视器（Mirror Monitor）页面立即显示仲裁器连接处于非活动状态。
初次看到这种情况时，可能会误以为是配置错误。但事实并非如此。 仲裁器的全部职责在于，当两个故障转移成员对对方是否仍处于活动状态存在分歧时，打破这种僵局。由于仅定义了一个成员，目前尚无需要仲裁的情况，因此该连接确实没有理由处于活动状态。这并非连接中断，只是在等待出现第二个成员以供参考。
当我在上一步中加入 mirror-backup 时，这种状态立即发生了逆转。
这一点值得亲自验证，而不是仅凭图表就轻信。动手搭建一下，观察同一 Portal 页面上的状态变化，仲裁器的实际作用范围就会一目了然——这是再多的文档阅读也无法完全传达的。
如果源表里有一列 FamilyName，而目标接口需要 FullName，集成程序应该怎么办？
可以因为两者都是文本，就把一个字段直接复制给另一个字段；也可以因为名称不同，就认为它们无法对应；还可以判断目标值可能需要由两个源字段组合而成——再确认这种理解是否符合当前集成场景。
这正是“匹配字段名称”和“设计数据映射”的区别。在 DataPipelineDemo 中，AI 会提出源数据与目标之间可能的对应关系；验证流程根据已有事实和约束检查这些建议；用户再审阅结果，并决定是否保存供后续管道生成使用。
这里有两个相关但不同层次的匹配：
因此，字段映射不只是两个名称的配对。它可以表示直接传值、组合多个值、提供常量，或执行术语映射等受控转换。源路径和目标路径固然重要，映射表达的意图同样重要。
字段名称是有用线索，但不能证明两个字段含义相同。两个都叫 Code 的字段可能属于不同编码体系或业务概念；名称不同的字段也可能表达同一个标识符。
结构和约束能补充更多上下文。目标可能要求必须提供某个值；字段可能需要日期、编码、引用或特定的 FHIR 路径。
不复制数据、不写同步脚本，在 InterSystems IRIS 上直接对业务对象做影响链分析与知识图谱分析
提到知识图谱，很多人的第一反应是：先建一个知识库，抽取实体和关系，再灌进一个图数据库。这条路没有错，但它默认了一个前提：知识是“另外一份东西”，需要单独采集、单独存放。
现实里，企业最有价值的知识往往早就躺在业务数据中了：
这些引用关系本身就是知识。每一个外键、每一个 Relationship、每一个对象引用，都是一条潜在的边。传统做法是把这些数据 ETL 到图库里再分析，代价是数据复制、同步延迟，以及一套额外的运维体系。
这里实现的IRIS Graph 子系统走另一条路：直接把业务对象的引用属性投影（projection）成图的边，边随对象的保存、更新、删除自动维护，业务表/对象依然是单一事实来源。这样不需要复制数据，就能立刻在业务数据上做影响链分析、可达性分析和知识图谱分析。
当然，传统知识库（文档、概念、实体）一样可以进图。同一个引擎同时支持两种来源，查询方式完全一致。下面逐一介绍。
注意，它不是InterSystems IRIS的官方特性。
Hi 大家好！
InterSystems技术分享线上课第四期来啦！这期课程我们将聚焦“定时任务的配置与监控”这一主题。
连接测试可以告诉我们服务器有响应，数据库结构可以告诉我们某列名叫 Code。但仅凭这两点，我们仍不知道这个编码代表什么，也不知道它是否应该映射到某个目标字段。
可靠的数据集成设计，要从这里开始。在决定哪个源资产对应哪个目标、哪些组件应组成一条数据管道之前，我们需要先理解接口——不只是接口的结构，还要理解这些结构在具体场景中的含义。
本文介绍 DataPipelineDemo 在 InterSystems IRIS for Health 上如何处理这个问题。核心原则是语义优先：先理解接口表达的含义，再做映射与管道设计决策。
这里的“语义优先”指的是下游决策顺序，并不是先让 AI 凭空猜测、再去看接口。实际流程是先采集结构和运行事实，再由大语言模型（LLM）基于这些事实进行解释，最后将分析结果作为后续决策的上下文。
连通性是必要条件，但它回答的问题很有限：当前应用能否访问这个端点？
它无法证明：
这些问题不同，需要的证据也不同。
LLM 可以建议把某个源字段映射到某个目标字段。这很有用，但还不能称为完成了一次数据集成。
接下来，还需要建立连接、理解目标约束、选择并连接组件、启动管道，以及检查数据到底有没有正确到达目标。
Quickstart 介绍了运行在 InterSystems IRIS for Health 上的 DataPipelineDemo。这一篇往前走一步：解释集成需求与平台能力，如何共同变成一条可运行、可验证的数据管道。
核心并不是“让 AI 写出所有东西”，而是：
让 AI 在明确边界内做集成决策，再让这些决策能够被执行、被观察、被验证。
整体链路可以概括为：
图 1：三个阶段；虚线反馈表示按适用路径做限定范围的修复，然后重新验证。
但这条链路包含三个不同的阶段。
设计与生成阶段，产出接口模型、字段映射、组件拓扑和 Production 定义。AI 参与语义分析、转换映射与管道规划。
运行阶段，源数据通过业务服务、转换流程和目标操作流转。已有组件执行确认后的转换指令，正常数据链路不会为每一行数据或每一条 FHIR 资源重新调用 LLM 做语义判断。
验证与反馈阶段，检查生成配置与运行证据；发现问题后，按适用路径修复映射或管道，再次验证。
这一区分很重要：AI 参与决策，IRIS 承担运行。例如，消息处理过程中查询术语映射，查的是术语服务器，并不是每次都让 LLM 重新判码。
一句话速览：登记数据源、选择目标，再让 LLM 设计数据集成流程。一条命令启动演示环境，再运行一条命令，就能端到端复现完整的数据管道。
git clone --recurse-submodules https://github.com/zlnick/DataPipelineDemo.git
cd DataPipelineDemo
bash tools/setup.sh && python3 tools/e2e_ui_flow.py
↑ 一次干净克隆环境中的实测：、验证通过，数据已写入目标 FHIR 仓库。
这是一个运行在 InterSystems IRIS for Health 上的完整演示：由数据源出发，自动生成并运行互操作性数据管道，其中的关键决策由 AI 完成。
/en
一套 IRIS 实例同时承担多个角色：FHIR 服务器（包含相互独立的源与目标两个仓库）、互操作性引擎（Production）、SQL 数据库，以及平台自身的元数据存储。
我们很高兴向您介绍全新的 InterSystems 软件分发平台，该平台将于10 月 8 日起在 downloads.intersystems.com 上线。
新网站对查找和下载 InterSystems 软件的体验进行了重新设计，让您能够更轻松地找到所需的产品、版本和组件。
全新体验包括：
在过渡期间，现有的 WRC 软件分发网站将继续提供服务，以便客户有时间熟悉新体验，并将现有的自动化流程迁移到新平台和 API 上。
自 10 月 8 日起，请访问 downloads.intersystems.com 探索全新的软件分发平台。
我们期待为您带来一种更简便、更现代的 InterSystems 软件访问方式。
在基于 InterSystems IRIS 数据平台开发解决方案的这些年里，我已实现了数百个与 REST API 的集成。而 IRIS 端涉及的 API 数量也不在少数！但在本文中，我想专门谈谈 REST 客户端。更确切地说，我想分享我尝试创建一个适用于所有 API 的通用客户端的经历。
简而言之：
omniEmbedding 是一个 100% 基于 ObjectScript 的网关，它将来自 10 家不同提供商（Ollama、OpenAI、Azure、Cohere、Gemini、Mistral、Voyage、 Jina、Bedrock、VertexAI）的嵌入数据，将其集中管理于 InterSystems IRIS 平台内，因此您既不会被锁定在单一提供商，也不会因在 RAG 管道中混合使用不兼容的向量而陷入困境。
我的想法并不是要锻造“至尊戒”——这事儿就留给托尔金和索伦去搞吧，😅。
事实上，原生类 %Embedding 和 %Embedding.OpenAi 让任何在 InterSystems IRIS 上进行向量搜索的人都轻松得不可思议。
不过，去年我不得不整合一个必须完全依赖 Azure OpenAI 平台的项目。情况变得有些复杂。我不得不对解决方案进行定制（在此要特别感谢 @Alex Woodhead在社区帖子中提供的关键帮助）。
现向大家介绍omniEmbedding：一个精简的、100% 基于 ObjectScript 的网关，用于在 10 家不同的 LLM 提供商之间路由嵌入向量。
该项目的真正差异化优势在于其背后的工程实践。
在 4.0.0 发布一周后，SQL DATA LENS 4.01 于 2026 年 8 月 30 日正式发布——这是一次重大版本更新，而非补丁更新。 其78项变更中的大部分都围绕一个主题：如何建立、保护和标记与IRIS或Caché的连接。本文将带您了解对于日常使用InterSystems数据库的用户而言最重要的部分，首先从我被问及最多的那个问题开始。
如果您曾使用 TLS 保护过 IRIS 超级服务器，然后尝试让 Java 客户端与其通信，您一定深有体会。在客户端，您需要
SSLDefs.ini- 风格的属性文件），keytool 构建的信任库，其中包含服务器或 CA 证书，社区中有关此主题的优秀文章不少——Mauro Aguirre 针对 ODBC/JDBC 客户端的分步指南以及Eduard Lebedyuk 的 Tableau 操作指南都值得一读。但这些文章之所以需要存在，且篇幅长达 6 到 13 分钟这一事实，本身就说明了一些问题。
docker login -u="your-username" -p="your-token" containers.intersystems.com
然后拉取镜像:
docker pull containers.intersystems.com/intersystems/irishealth:2025.3
为 InterSystems AI Hub 代理和外部 MCP 客户端构建一套受管控的 FHIR 工具集——以及那个让每次拒绝都拥有完美借口的日志记录漏洞。
大家好，社区的朋友们！ 我终于下定决心写下我的第一篇帖子——并决定直接挑战两个当下最热门的话题：AI 和安全。
先做个简短的免责声明：这是试图将两个在很长一段时间内都不会真正交汇的世界结合起来：AI 和老派的安全人员。让我来解释一下。
几年前，我曾参与一个非常老旧的航空医疗认证系统项目——该系统负责判定人员是否具备在航空领域工作和学习的体能及心理健康条件。项目本身以及我在其中的角色并不怎么有趣：主要是将系统从Cache迁移到IRIS，并根据新法规对客户端进行现代化改造。 但我至今仍记得那支由审计员和安全官员组成的团队：每次新的集成、每个新的封装层、每一步数据提取操作，都会引发数十个问题，产生数页的文档和数据流图。其中有三个问题让我印象深刻：
前两个问题我们轻松通过了。但第三个问题却让审计搁浅了：审计员要求提供针对医疗数据的特定访问记录，却未能找到。这并非因为没有发生访问：这些访问是合法的，检查机制也有效——我们只是在错误的层级上进行了日志记录。
InterSystems 宣布推出第四个预览版，作为 2026.3 版本开发者预览计划的一部分。该版本将包含 InterSystems IRIS® 数据平台、InterSystems IRIS® for Health™ 以及InterSystems Health Connect™。
2026.3 版本中已新增多项更新和增强功能：
初始文档可通过以下链接查阅。这些文档将在未来几周内持续更新，直至正式发布（一般可用版 - GA）：
未来的预览版本预计每两周更新一次，我们将根据功能开发进度陆续添加新特性。请通过开发者社区分享您的反馈，让我们共同打造更优质的产品。
目前有多个 EAP 项目可供选择。请访问此页面，并注册您感兴趣的项目。
此版本提供了适用于所有受支持平台的经典安装包，以及 Docker 容器格式的容器镜像。完整列表请参阅《受支持平台》文档。
| 警报 ID | 受影响的产品及版本 | 风险类别与评分 | 明确要求 |
| DP-453448 |
InterSystems IRIS® 数据平台 InterSystems IRIS® for Health InterSystems Health Connect™ |
运行状态：4 – 高风险 | 发生空闲超时，或者现代互操作性应用程序中的会话 应用程序的会话意外退出。 |
当用户单击打开任何现代（新）互操作性应用程序（生产配置、规则编辑器、DTL 编辑器、BPL 编辑器、消息搜索/查看器），然后让应用程序处于非活动状态（根据每个应用程序的闲置超时时间）时，会发生此问题。 此操作会将用户注销，随后应用程序将丢失命名空间的上下文。 因此，应用程序会错误地向服务器发送未在 URL 中指定命名空间的查询；由于 URL 格式不正确，当 ^%ISCLOG 设置为 1 或更高值时，该请求会在 messages.log 中生成一个或多个条目。 随着时间的推移，这些请求可能会导致大量错误消息。
当通过将 ^%ISCLOG 设置为 1 或更高值来启用该选项时，messages.log 中生成的海量错误可能会占用大量磁盘空间。此外，还可能会在审核日志和日志文件中生成重复条目。
SQL DATA LENS 4.02 于 2026 年 9 月 4 日发布。在其各项更新中，有一项我特别想重点提及，因为这是我多年来一直期待却从未在其他地方找到的功能：SQL DATA LENS 现在可以直接在“Global Browser”中打开一个 .gof 文件——即 InterSystems 的 %GOF 块格式global导出文件——直接在“Global Browser”中，因此您可以在收到导出文件后立即浏览其内容，而无需先将其导入任何地方。
这是一项全新的功能，而块格式最初是作为 IRIS 实例之间的内部传输格式设计的，从未被设想为第三方工具可读取的格式——因此我们是通过研究 IRIS 的写入内容来理解它的，而非基于任何规范。 这正是我撰写此文的原因：希望您能用自己的导出文件试用该功能，并告诉我们您的使用体验。下文将介绍该功能的工作原理、我认为其有用的原因、当前的局限性，以及哪些反馈对我们最有帮助。
.gof 文件必须先导入才能查看如果你长期使用 IRIS 或 Caché，.gof 文件就会开始堆积如山。 管理门户会生成这些文件（系统资源管理器 ▸ 全局变量 ▸ 导出，“块格式” | System Explorer ▸ Globals ▸ Export, "block format" ），^%GOF 会生成这些文件，##class(%Library.Global).Export(...)
大家好，社区的朋友们！
IRIS Interoperability 中的业务规则属于那种原本运行顺畅，却会突然失效的功能之一。您构建了一条规则，条件看起来正确，路由目标也无误，但消息却一直被转发到默认操作。事件日志中没有错误，可视化跟踪中也没有明显的线索。
最常见的原因之一是动态对象的属性无法按预期方式访问。本系列文章共分两部分，将全面介绍这一问题。 第 1 部分将引导我们使用 HL7 消息类型设置一个生产环境，并构建一个 BPL 业务流程，该流程通过动态对象对传入的 HL7 消息进行数据增强。第 2 部分将使用同一生产环境，演示七个在生产集成中导致“无声故障”的实际属性访问陷阱。
%DynamicObject 是一个无需定义类即可动态创建的无模式对象。%Set() 设置包含下划线等特殊字符的属性，并使用 %Get() 将其读回。本指南面向处理 BPL 业务流程和 HL7 路由的 IRIS 互操作性开发人员，旨在帮助他们了解如何在做出路由决策之前，通过动态对象来丰富消息内容。
Rule Editor的用户们，我们需要你们！我们正在重新设计规则编辑器的部分功能，希望那些每天都在使用这个工具的用户能来体验一下我们的设想！👩💻
如果您已经试用过新的（Angular）规则编辑器，并遇到了奇怪的边际情况，或者曾疑惑“为什么它会这样工作”，现在就是您畅所欲言的好时机！🗣️
以下是新版界面的抢先预览：
如果您有兴趣体验我们的交互式原型，请通过 📧 邮件联系InteropUXFeedback@intersystems.com，告知您的意向以及本周的空闲时间。
🗨️ 告诉我们你愿意参加！
📅 请附上你本周的空闲时间
🎯 帮助打造一款你真正“想用”的工具
您回复得越早，我们能为您做的就越多，所以请尽管联系我们！
本系列的第一部分。第二部分将介绍完整的工具目录。第三部分将介绍 ObjectScript 技能。第四部分将介绍基准测试以及如何衡量实际的改进效果。
托马斯·马祖尔（Thomas Mazur）关于 VS Code 生产力——Peacock、作用域工作区文件、Copilot 代理模式——的 博文《青蛙、鸡、AI 和 VS Code》 在评论区揭示了一个更尖锐的问题。皮耶特罗·迪·莱奥（Pietro Di Leo）和 Mike.W 指出，当你在 VS Code 中进行服务器端开发时， isfs:// 大多数 IRIS 生产环境所使用的“工作区”中，Copilot 只能看到编辑器中打开的文件，无法对虚拟文件系统进行索引。对于拥有数千个类的成熟 IRIS 应用程序而言，AI 的工作效果就像是透过钥匙孔观察一样。
John Murray 向大家推荐了我正在开发的项目——iris-agentic-dev——并指出目前开发者社区中尚无相关文章。因此，本文将阐述：该问题产生的原因、该工具如何解决该问题，以及如何在约五分钟内完成部署。
当你打开一个 isfs:// 工作区时，你的 IRIS 类存储在服务器上，而非本地磁盘。
刚开始接触 ObjectScript 时，我编写的大部分代码都遵循了 InterSystems 的现代编程模式。我使用类、方法、REST 服务、互操作性生产、JSON 对象以及 %Status 值。
与此同时，我负责维护的生产系统中，很大一部分代码采用的编写风格却截然不同。
该系统使用了例程、标签、global、缩写命令、“点-do”语法、共享局部变量以及错误处理模式——这些在基于类的 ObjectScript 普及之前就已经存在了。
起初，我曾以为这仅仅是旧语法与新语法的区别。随着时间的推移，我意识到最大的差异并非表面上的。传统的MUMPS风格代码与现代ObjectScript在变量作用域、执行层级、数据流和错误处理方面往往基于不同的假设。这种区别至关重要，因为旧代码很容易被误读。
某个例程看似未接收任何参数，却依赖于调用者创建的多个变量；某个标签在某处表现得像一个过程，在另一处却表现得像一个函数；一个点块（dot block）虽然会创建另一个执行层级，却可能看起来像缩进；一段代码在移入类后虽然能编译通过，但在运行时却可能表现得截然不同。
代码看起来依然很熟悉。语言依然是 ObjectScript。然而，它可能已经发生了变化。
本文介绍了我在处理遗留代码并将其与更现代的 ObjectScript 应用程序集成时所遇到的一些最重要的差异。
互操作性用户界面项目自 2025.1 版本以来持续推进，并已采纳了各位——我们的客户和合作伙伴——提出的许多建议和反馈。 我们将持续重视用户反馈，并不断优化这一重要的用户体验。在IRIS、IRIS for Health、Health Connect及 Health Connect Cloud 的最新版本 2026.2 中，“模式查看器”（只读模式）现已开放选配！
注意：
改进了 用于在“生产工具栏”视图与“主机工具栏”视图之间切换的 切换选项的可见性。
现在，即使未选择主机，主机操作也会始终显示在“主机工具栏”中。在选择主机且选项有效之前，这些操作处于禁用状态。
新增了在“类别”字段中以 逗号分隔的列表形式输入多个值 的功能。
新增了重命名现有类别的功能。
创建新流程类时，现在可以配置新规则以自动调用源代码控制操作，从而简化类导出和源代码控制集成工作流。
在 图形编辑器的顶部面板中 添加了用于独立滚动的边界 。
新增了按字母顺序对段字段路径表达式进行排序的功能。
现在，只读和内部属性 在 DTL 编辑器中会显示为灰色 ，以防止出现无效的映射。
IRIS 实例突然起不来。 WRC 工单已经提了，但生产环境还在等——这种时候，每一分钟都是煎熬。
Hi 开发者们，
我们将在8月21日带来一期线上分享，点击👉此处报名参会👈。
很多工程师都遇到过类似的场景：翻文档、跑指令、看日志，但真出问题时还是不确定自己排查的方向对不对，也不敢贸然操作。
这是一期实战排查分享。
我们将在30分钟的分享时间内，从一条 messages.log 开始，带你走完 IRIS 启动失败的完整排查链路：
✅ 哪些指令必须跑、输出怎么看
✅ 什么时候该继续自查、什么时候该等 WRC
✅ 一套 6 步法，最快速度把实例拉起来
8月21日下午14:00-14:30分，欢迎参会！
在会议进行过程中，如果您有任何疑问，或者希望与我们进一步讨论，可以在屏幕上方点击“提问”按钮，提交您的问题，我们会在分享结束后整理问题，并通过邮件向您回复。
参会期间，点击屏幕右上角“有奖调研”完成问卷，将有机会获得定制小礼品。
欢迎跟帖告诉我们您的想法！
大家好，
我在 IRIS for Health 上构建了一个小型临床 AI FHIR 代理网络，想和大家分享让它正常运行的关键组件。
本文将涵盖以下内容：