让 AI 接手数据集成：几分钟里跑起来

一句话速览：登记数据源、选择目标，再让 LLM 设计数据集成流程。一条命令启动演示环境，再运行一条命令，就能端到端复现完整的数据管道。

git clone --recurse-submodules https://github.com/zlnick/DataPipelineDemo.git
cd DataPipelineDemo
bash tools/setup.sh && python3 tools/e2e_ui_flow.py

↑ 一次干净克隆环境中的实测：result: OK、验证通过，数据已写入目标 FHIR 仓库。

这是什么

这是一个运行在 InterSystems IRIS for Health 上的完整演示：由数据源出发，自动生成并运行互操作性数据管道，其中的关键决策由 AI 完成。

• 数据源（2 种）：FHIR 接口、SQL 表
• 转换目标（3 种）：数据库表、SOAP 服务、FHIR 仓库
• 支持多种源与目标组合，也支持在同一个 Production 中运行多条数据管道
• 提供中英双语界面：默认中文，英文界面位于 /en

一套 IRIS 实例同时承担多个角色：FHIR 服务器（包含相互独立的源与目标两个仓库）、互操作性引擎（Production）、SQL 数据库，以及平台自身的元数据存储。

核心思路：LLM 做决策，代码做校验

不少“AI + 数据集成”演示会先请模型给出建议，之后再悄悄切回手写规则。本项目采取相反的做法：

如果 AI 路径失败——例如缺少密钥、调用超时或输出格式不合规——平台会在界面中明确报错，指出失败的 Agent 和原因。它不会静默降级为规则结果；只有在明确请求 allow_rule_fallback=true 时才会启用规则兜底，并在响应中标注 rule_fallback: true。

这也是这个演示值得关注的地方：它展示了一个由 Agent 驱动的集成工具应有的样子——模型需要为自己的输出负责。

↑ 同一思路在界面中的呈现：AI 将 SQL 资产匹配到 FHIR 目标，校验器逐项检查映射，并将结果以报告形式展示。

术语不是点缀

临床数据离不开编码。本项目在独立容器中运行一个术语服务器，它是开源项目 intersystems-ib/iris-terminology-server 的裁剪版（MIT 许可证；服务器由 Luis Angel Pérez Ramos 开发）。服务器本身的工作属于原作者；本项目使用的是裁剪后的版本，并维护演示数据与转换映射层。

术语服务器存储中文 ICD-10（约 2 万个概念）、中国药品目录（NRDL/CBIH）、RxNorm，以及一组 SNOMED CT 示例数据，是术语转换映射的事实源。

• 运行时，数据管道通过共享的业务操作实时查询 /mapping/lookup。找不到映射时，平台保留源编码，并为资源添加 unmapped 标记——状态明确可见，不会静默丢弃。
• 仓库提供了 81 条预置映射，让术语转换开箱可用。
• 扩充映射覆盖范围是可选步骤，与日常运行分开：先语义检索候选项，再由 LLM 判断，最后将判断结果写回术语服务器（tools/term_map_build.py）。

运行演示

前置条件：Docker 与 Docker Compose、免费的 InterSystems 容器仓库账号（用于拉取 IRIS 镜像），以及你自己的 LLM key。

bash tools/setup.sh          # 子模块、.env、容器、CLINIC 表、术语概念与映射
python3 tools/e2e_ui_flow.py # 登记数据源 → 造数 → 配置 FHIR 目标 → AI 匹配 → 生成管道

脚本会沿着 UI 用户的操作路径完成演示：登记 CLINIC SQL 数据源、测试连接、选择数据表、生成演示数据、登记 FHIR 目标、请求 AI 匹配资产与字段、保存映射，最后生成数据管道。

英文原文记录的一次干净克隆环境实测结果：

result: OK | validation ok: True | errors: 0
checks: compile · pipeline · query_dispatch · settle · smoke · start · target_effect
FHIR landing → Patient 3 / Encounter 4 / Condition 7 / MedicationRequest 7

映射由 LLM 决策，演示数据也带有随机性。因此，可复现的是流程与数据结构，不保证每次生成相同的编码或记录数量。

↑ 在界面中执行同一流程：点击一次即可生成并启动 Production；平台会编译配置，并按许可容量调度组件。

想直接通过界面逐步操作？请参阅仓库 README 中的 Demo Walkthrough。

实现概览

• 类型注册表是平台可用组件的权威目录。组件清单会传入管道规划提示词，因此模型只能从经过预研的组件中选择。
• Agent B（管道规划 Agent）选择管道设计 Skill，并生成组件拓扑；平台再为组件补充所需参数。
• 每条数据管道有自己的转换 BP 实例（例如 TransformProcess__...），因此各条管道可以独立启停和释放许可。
• IRIS 社区版许可总额度为 8 个许可单元；后端连接本身也会占用单元。平台会据此调度管道：超出可用额度的管道仍会生成，但初始处于停用状态；用户可以一键切换，平台也会自动停用其他活动管道以腾出容量。

当前限制

这是一个演示级项目，采用 Apache-2.0 许可证。运行需要 LLM key 和 InterSystems 容器仓库账号；许可容量受 IRIS 社区版限制。

AI 输出具有非确定性。当前支持的协议范围经过有意控制：已实现并预研的数据源是 FHIR 和 SQL，目标是 DB、SOAP 和 FHIR。Kafka、MQTT、任意 REST 接口等目前不在支持范围内。

试试看

• 项目仓库：zlnick/DataPipelineDemo——提供双语 README 和一键启动流程。
• 术语服务器：裁剪自 intersystems-ib/iris-terminology-server 的版本。项目使用的分支为 zlnick/iris-terminology-server 的 demo-community。
• 许可证：Apache-2.0。

如果你正在构建 Agent 驱动的工具，值得追问的并不只是“LLM 会不会写字段映射”，而是：

“能否把整条数据管道交给它？当它做不到时，系统能否明确报错？”

这正是这个演示试图回答的问题。

致谢

本项目建立在许多人的工作之上。这里特别说明各自的贡献：

• intersystems-ib/iris-terminology-server：开源多术语服务器，支持 SNOMED CT、LOINC、ICD 的导入与版本管理，提供持久化存储、SQL 访问、向量检索、原生术语 API、FHIR R4 术语接口，以及基于 Production 的处理能力。该项目采用 MIT 许可证，由 Luis Angel Pérez Ramos 开发，并作为社区项目发布在 InterSystems Open Exchange。

  术语服务器本身的所有贡献都应归于原作者。 本项目中的 iris-terminology 容器使用其裁剪版：仅针对单容器演示场景做了精简，并在其上添加本地演示数据集（中文 ICD-10、NRDL/CBIH 药品目录、RxNorm、SNOMED CT 示例）和转换映射层。谨致谢意。

• InterSystems：提供 IRIS for Health Community Edition 及官方 intersystemsdc/iris-community 镜像，其中包括本项目使用的 FHIR 仓库、互操作性 Production 引擎和 JDBC Java Gateway。

• 公开代码目录的维护者：感谢为演示初始化提供公开编码目录的维护者，包括 GB/T 14396-2016 中国 ICD-10、中国 NRDL 和 CBIH 药品目录。这些目录随项目放在 data/terms-inbox/ 中，同时仍受各自的许可条款约束。

如果术语服务器对你有帮助，欢迎为上游项目点 Star 或注明出处；术语服务器的核心工作来自上游项目。

本项目仅用于演示，不是 InterSystems 官方产品。