Triage Park：基于IRIS的多智能体临床平台
InterSystems 编程竞赛： https://openexchange.intersystems.com/contest/46上的 FHIR 人工智能代理 。
代码： https://github.com/eungi-hong/central-park
演示： https://triagepark.78-47-167-98.sslip.io/
就诊的前十分钟总是千篇一律：采集病史、调取病历、核对用药情况、判断病情紧急程度。Triage Park通过一支完全在 InterSystems IRIS for Health 内部运行的 AI 代理团队来完成这一初步筛查，并向临床医生提供一份附有依据且可解释的交接报告。 大多数“AI分诊”演示所忽略的部分，恰恰是我们最重视的：安全性。这里的所有安全机制都是确定性的且单向的。系统只能提高病例的紧急程度，绝不会降低，因此患者的安全绝不会取决于模型是否判断正确。
代理、检查与技能
该平台经过刻意划分：需要大量判断的工作以代理的形式运行（即使用工具的循环，负责决策和执行），安全关键型工作以确定性检查的形式运行（基于规则，而非大型语言模型），其余部分则专注于大型语言模型技能。 一个监督协调器将请求路由到相应组件，并在需要时串联多个组件，所有操作均在单个 IRIS 互操作性生产环境中进行，因此每次分诊都可在 Visual Trace 中形成可追溯的 Ens.MessageHeader 记录。
| 能力 | 类型 | 写入 |
|---|---|---|
| 协调器 | 监督代理 | （路由 + 将其余部分串联起来） |
| 分诊推理器 | 代理（工具循环） | Encounter, ServiceRequest, Communication |
| 自适应接案访谈（多语言） | 代理（自适应循环） | QuestionnaireResponse |
| 副驾驶 | 智能体（只读工具循环） | - |
| 评审员 | LLM 批评者 | （仅限升级处理） |
| 风险预警关口，安全/交互 | 确定性检查 | DetectedIssue |
| 护理缺口、结果随访 | 确定性检查 | Task |
| 队列分析 | 确定性（批处理） | - |
| 风险 | 集成机器学习/启发式 | - |
| 摘要、检查结果说明、护理计划、自然语言→FHIR查询 | 大语言模型技能 | CarePlan（护理计划） |
输入“总结该患者情况、检查再入院风险并标记护理缺口”，协调器将 summary → risk → gaps 整合为一个答案。控制台展示的工作列表包含关键绩效指标（KPI）、队列分析、基于自然语言的 FHIR Explore 视图，以及由协调器驱动的助手。 每个病例均仅基于FHIR数据进行可解释的重建。
自首次提交以来的更新
首次提交仅是在“红旗”门控机制后的一次单一分诊LLM调用。此后，它已发展成为一个平台：
| 领域 | 首次提交 | 当前 |
|---|---|---|
| 分诊推理 | 一次LLM调用 | 带约束的工具使用ReAct循环 + 一个自我批判式审阅器 |
| 接收 | 固定问题形式 | 自适应、多语言访谈 |
| 安全 | 仅设“红旗”门槛 | 筛查环节外加确定性的用药/过敏检查，结果记录为 DetectedIssue |
| 范围 | 一名分诊员 | 由一名主管协调员领导的一组人员 |
| 新功能 | （无） | 集成机器学习风险评估、队列分析、自然语言→FHIR查询 |
| FHIR写回 | 5种资源类型 | 8（新增 DetectedIssue、Task、CarePlan） |
核心原则未变：安全性始终保持确定性且单向性。所有新增功能均在此基础上构建，绝不绕过这一基础。
安全底层
分诊流程是一个 LangGraph 状态机，包含三个单向安全层：
gather_context → check_safety → validate_red_flags → reason (tool loop) → verify → escalate
- 红旗闸门（不使用LLM）：绝对不能遗漏的短语（中风、气道阻塞、过敏性休克、出血、晕厥、自杀意念）将直接跳转至急诊科，并设有否定条件，因此“无言语含糊”等情况不会触发。
- 药物相互作用检查（不使用LLM）：将药物和过敏史与主诉进行交叉比对，写入
DetectedIssue，并设定分诊层级。例如，一名正在服用ACE抑制剂且报告面部肿胀的患者，在生成令牌之前会被升级为血管性水肿。 - 审核员：剔除任何未实际检索到的引用，随后可升级但绝不降级：
if verdict == "escalate":
final_level = _higher(level, proposed) # escalate-only by construction
在门控和审核员之间，reason是一个有界ReAct循环：代理在确定处理方案前会获取更多指南、具体观察结果或风险评分，且始终能得到解决。 遗漏的关键字、虚构的引用或过于自信的模型，都只会使分诊结果更加审慎。
IRIS原生功能，非后加组件
- 向量搜索：将
VECTOR(float, 1536)作为指南语料库，通过VECTOR_COSINE进行查询；IRIS 通过%Embedding.OpenAI（AI Hub）在服务器端计算嵌入向量。 - IntegratedML：
CREATE MODEL/TRAIN MODEL+ 行级PREDICT用于再入院风险评估，作为工具进行参考。 - 互操作性：每次分诊都会在 Visual Trace 中生成一条可追溯的消息。
- FHIR R4：读取上下文，写入8种资源类型；叙述内容保存在
ServiceRequest上，因此无需重新运行LLM即可全面复查过往病例。
两点诚恳说明
- 采用 Sidecar 模式，而非嵌入式 Python。该代理仍是一流的业务操作，但此镜像中的 ARM64 嵌入式 Python 不稳定，因此 LangGraph 堆栈在 Sidecar 中运行，以确保每个评判者都能可靠启动。
- IntegratedML 处于禁用状态（
CP_ENABLE_ML=0针对 ARM64，因为 AutoML 需要相同的运行时环境）。风险代理会回退到带标签的启发式算法，因此它在任何环境下都可用，并且在 x86 平台上只需一个标志即可完全启用。
试试看
git clone https://github.com/eungi-hong/central-park.git
cd central-park && cp .env.example .env # set OPENAI_API_KEY=sk-...
docker compose up --build # IRIS cold start ~90s
打开 http://localhost:8501，在 /intake 处让演示患者经历胸闷场景，观察病例的生成、分诊及引用过程。安全逻辑已通过单元测试： docker compose exec agent python -m pytest tests/ -q。
这是 Hong Eungi 和 Antor Chowdhury 首次向 InterSystems Open Exchange 提交的贡献。如果您认同这种分层安全方法，欢迎在评论区为我们投票并提供反馈。