# DIB 数智桥平台总体架构蓝图

日期：2026-06-02
状态：v0.1 草案

## 1. 总体定位

DIB 数智桥平台定位为面向国家、省、市、县等多层级医疗健康治理与业务融合场景的统一连接、协同与运营底座，采用“一底座、多专区”的集约化建设模式，统一承载医疗业务、医疗协同、数据同步回写和业务监管等专区能力。

主口号：

```text
一桥贯通，多区协同，数智赋能
```

副口号：

```text
以数智桥统一底座支撑医疗健康业务专区建设
```

说明句：

```text
面向医疗健康行业，建设可适配国家、省、市、县多层级的数智桥统一底座，统一承载医疗业务、医疗协同、数据同步回写和业务监管等专区能力，减少重复建设、重复接入和重复运维，提升区域医疗健康数字化协同能力。
```

其中，“一底座”指 DIB Platform Core 提供统一组织治理、资源中心、插件中心、Agent 接入、权限审计、标准互操作和运行监测能力；“多专区”指医疗业务、医疗协同、数据同步回写、业务监管等专区能力在统一底座上分域建设、分权运营、共享接入能力。

层级适配说明：

```text
数智桥可按国家、省、市、县等不同治理层级部署为中心平台，也可按医共体、医院集团、专科联盟等组织形态裁剪实施。省级平台是当前材料中的典型样板场景，不是数智桥能力边界的上限。
```

主线技术栈基线见 `docs/architecture/dib-platform-technology-stack.md`。后续迁入项目先按 `platform-core/`、`dib-client/`、`dib-agent/`、`release/`、`suites/medical/` 等职责归位，再按基线选择 `.NET 10 LTS`、TypeScript、Node.js LTS、Vue 3、Vite、PostgreSQL、Supabase、PowerShell 7、Docker/Nginx 等技术栈。

## 2. 建设目标

1. 支撑国家、省、市、县等多层级统一建设数字底座，避免各业务条线重复建设、重复接入、重复运维。
2. 通过专区化承载医疗、医保、疾控等行业应用，既共享底座，又保持业务边界。
3. 通过 DIB Agent 打通机构内部资源与 DIB 中心平台，降低医院开放公网入站端口和暴露数据库连接的风险。
4. 通过标准互操作中心统一治理 HL7/FHIR、ICD-10、ICD-11 等行业标准，支撑跨机构、跨系统、跨部门协同。
5. 从项目制建设转向平台制运营，形成可持续扩展、可监测、可审计、可升级的多层级能力底座。

## 3. 总体架构

```mermaid
flowchart TB
  subgraph Province["DIB 数智桥中心平台\n国家/省/市/县可部署"]
    Core["DIB Platform Core\n一底座"]
    Medical["医疗专区\nDIB Medical Suite"]
    Insurance["医保专区\nDIB 医保 Suite"]
    Cdc["疾控专区\nDIB 疾控 Suite"]
  end

  subgraph CoreModules["平台核心能力"]
    Org["组织/租户/站点治理"]
    Resource["资源中心"]
    Plugin["插件中心"]
    Release["发布中心"]
    AgentOps["Agent 调度与运维"]
    Standards["标准互操作中心"]
    Audit["权限、审计与安全"]
    Monitor["运行监测驾驶舱"]
  end

  subgraph Institution["机构内网"]
    Client["DIB Client\n插件宿主与本地工作台"]
    Agent["DIB Agent\n安全连接器"]
    His["HIS/LIS/RIS/PACS 等内部资源"]
  end

  Core --> Medical
  Core --> Insurance
  Core --> Cdc
  Core --> Org
  Core --> Resource
  Core --> Plugin
  Core --> Release
  Core --> AgentOps
  Core --> Standards
  Core --> Audit
  Core --> Monitor
  Client --> Agent
  Agent --> His
  Agent --> Core
```

## 4. 一底座：DIB Platform Core

DIB Platform Core 是多层级可部署的统一底座，负责所有专区共享的平台能力。

| 能力 | 定位 |
| --- | --- |
| 组织/租户/站点治理 | 管理平台实例、专区、单位、机构、院区、部署站点和租户关系 |
| 资源中心 | 管理数据库、接口、文件、模型服务等内部或外部资源，按单位授权、按站点绑定 |
| 插件中心 | 管理插件包、插件版本、插件授权、站点安装和升级策略 |
| 发布中心 | 统一发布 DIB Client、Agent、插件和专区能力包 |
| Agent 调度与运维 | 管理 Agent 心跳、任务领取、执行状态、失败重试、版本和诊断 |
| 标准互操作中心 | 治理 HL7/FHIR、ICD-10、ICD-11、院内码映射和数据交换模型 |
| 权限、审计与安全 | 统一身份、角色、授权、操作审计、数据访问审计和安全策略 |
| 运行监测驾驶舱 | 监测机构接入、Agent 在线、任务积压、资源授权、插件运行和专区使用情况 |

核心原则：

```text
单位授权决定可选范围
站点绑定决定实际使用
Agent 只能使用已授权资源
插件只能访问声明过的 usageKey
专区只定义业务，不重复建设底座
```

资源中心最小模型见 `docs/architecture/dib-resource-center-minimal-model.md`。后续插件、Agent Profile 和专区业务访问生产资源时，均以资源中心登记、单位授权、站点绑定和 `usageKey` 下发为准。

## 5. 多专区：DIB Industry Suites

专区是行业业务能力的承载域。专区不是独立平台，也不是简单菜单分组，而是在统一底座之上的业务域。

专区应具备以下边界：

1. 共享 DIB Platform Core 的组织、资源、插件、Agent、权限、审计和标准能力。
2. 拥有独立业务模型、业务流程、业务数据表和运营指标。
3. 拥有独立权限边界和数据边界。
4. 通过标准 Profile 接入 DIB Agent，不建设独立 Agent Runtime。
5. 通过插件中心和发布中心完成客户端能力分发和升级。

### 5.1 DIB Medical Suite

DIB Medical Suite 是第一个重点行业套件，对外可称为医疗专区。

建议结构：

```text
DIB Medical Suite
├─ 医疗业务支撑
│  ├─ 门诊 EMR
│  ├─ 入院申请
│  └─ 院长看板
│
├─ 医疗协同支撑
│  └─ 转诊服务
│
├─ 医疗数据同步与回写
│  ├─ HIS 数据同步
│  ├─ LIS/RIS/PACS 资料同步
│  ├─ 病历回写
│  ├─ 入院申请回写
│  └─ 指标同步
│
└─ 业务监管支撑
   ├─ 质控规则
   ├─ 异常监测
   ├─ 运营监管
   └─ 合规审计
```

### 5.2 后续行业 Suite

后续可扩展：

```text
DIB 医保 Suite
├─ 医保业务支撑
├─ 医保协同支撑
├─ 医保数据同步与回写
└─ 医保监管支撑

DIB 疾控 Suite
├─ 疾控业务支撑
├─ 疾控协同支撑
├─ 疾控数据同步与上报
└─ 疾控监管支撑
```

## 6. DIB Client

DIB Client 是机构侧本地工作台和插件宿主，不承担长期数据同步任务。

职责：

1. 承载被授权插件。
2. 提供本地人员操作入口。
3. 展示站点、资源、插件和 Agent 状态。
4. 发起资源申请和授权状态查看。
5. 安装、升级、启动、停止和诊断 DIB Agent。

非职责：

1. 不长期执行 7x24 同步任务。
2. 不直接保存专区业务事实数据。
3. 不绕过资源中心直接读取内部资源。

## 7. DIB Agent

DIB Agent 是机构内网资源与 DIB 中心平台之间的安全连接器，生产形态应为 Windows Service 或同等级后台服务。

统一运行时基线见 `docs/architecture/dib-hospital-agent-runtime-unified-design.md`。后续院长看板、门诊病历、转诊、EMR 回写等业务都通过任务 Profile 接入该 Runtime，不建设独立业务 Agent。

职责：

1. 主动出站访问 DIB 服务端，不要求机构开放公网入站端口。
2. 读取资源中心授权的内部资源，如 HIS 只读库、LIS、RIS、PACS 或内部 API。
3. 领取白名单任务，执行 Profile 定义的查询、同步或回写。
4. 上传任务结果、心跳、版本、失败摘要和诊断信息。
5. 本地缓存任务状态，支持超时、失败、重试和资源撤销处理。

安全边界：

1. 云端任务不得下发任意 SQL。
2. Agent 使用 HIS 只读账号执行查询；写回场景必须走明确白名单接口或白名单写入任务。
3. 日志不得记录连接串全文、密码、访问令牌、患者隐私全文或处方明细全文。
4. 资源撤销或过期后，Agent 不得继续无限期执行任务。

## 8. 标准互操作中心

标准互操作中心属于 DIB Platform Core，而不是某个单一专区的附属字典。

一期建议：

1. 以 FHIR R4 作为一期兼容基线，设计上保留 FHIR R5 演进空间。
2. 以 ICD-10 诊断字典和院内诊断码映射作为一期落地点，预留 ICD-11 映射。
3. 建立最小医疗核心对象映射：患者、就诊、诊断、检验检查摘要、病历文书、转诊申请。
4. 为插件和 Agent Profile 提供标准能力声明。

示例映射：

| DIB 医疗对象 | 标准映射 |
| --- | --- |
| 患者 | FHIR Patient |
| 就诊 | FHIR Encounter |
| 诊断 | FHIR Condition + ICD-10 |
| 检验检查 | FHIR Observation / DiagnosticReport |
| 病历文书 | FHIR Composition / DocumentReference |
| 转诊申请 | FHIR ServiceRequest / Task |

## 9. 现有项目归属

当前分散项目先作为探索资产和迁移来源，不立即搬迁代码。

| 现有项目 | 建议归属 | 后续用途 |
| --- | --- | --- |
| digital-intelligence-bridge | DIB Platform Core、DIB Client、DIB Agent 的原型来源 | 资源中心、插件中心、发布中心、客户端、Agent Runtime 的主要基线 |
| cloud-medical-platform | DIB Medical Suite 的原型来源 | 医疗业务支撑、医疗协同支撑、医疗数据同步与回写的主要基线 |
| allinone-president-dashboard | 医疗业务监管和院长看板口径基线 | SQL 口径验证、指标迁移对账、试点基线 |
| allinone | 旧 HIS 工作区 | 现有业务入口、数据源、回写目标、迁移参考 |

迁移治理原则：

1. 第一阶段只做资产盘点和迁移清单，不整体搬迁旧项目代码。
2. 新开发进入 `C:\dev\dib-platform`，旧项目按能力切片渐进吸收。
3. `digital-intelligence-bridge` 作为底座、Client、Agent 的主要来源。
4. `cloud-medical-platform` 作为医疗专区云端业务和多租户能力来源。
5. `allinone-president-dashboard` 只作为院长看板 SQL 口径和指标对账基线。
6. `allinone` 只作为旧 HIS 数据源、业务入口和回写边界参考。
7. 迁移清单以 `docs/migration/migration-backlog.md` 为准。

## 10. 一期 MVP 建议

一期不追求所有专区同时落地，建议采用：

```text
一底座 + 医疗专区 MVP
```

最小闭环：

1. DIB Platform Core 建立组织、站点、资源、插件和 Agent 基础治理。
2. DIB Agent 能主动出站、上报心跳、领取任务、执行 DryRun 或只读查询、上传结果。
3. 医疗专区选择 1 到 2 个高价值场景先跑通，例如转诊服务、门诊 EMR 临床资料同步、院长看板指标同步。
4. 标准互操作中心先落 ICD-10 诊断字典和 FHIR R4 最小映射。
5. 运行监测驾驶舱展示机构接入、Agent 在线、任务成功率、资源授权、插件状态和专区使用情况。

## 11. 主要短板与应对

| 短板 | 风险 | 应对 |
| --- | --- | --- |
| 范围过大 | 一期难以交付 | 固定“一底座 + 医疗专区 MVP”，医保和疾控先作为扩展方向 |
| 专区边界不清 | 平台变成大杂烩 | 明确专区共享底座、独立业务模型、独立权限边界 |
| 标准化口号化 | HL7/FHIR、ICD 难落地 | 一期只做最小标准集，先服务转诊、诊断、患者、就诊 |
| 医院接入顾虑 | 安全和运维阻力大 | 强调 Agent 主动出站、云端不直连数据库、资源授权可审计 |
| 旧项目分散 | 开发和理解成本高 | 先建统一工作空间和蓝图，再逐步迁移新开发 |

## 12. 下一步

1. 固化 DIB 平台术语表。
2. 明确一期 MVP 范围和验收指标。
3. 梳理现有项目到新架构的迁移清单。
4. 形成领导汇报版“一图三表”：总体架构图、能力清单表、一期路线表、价值对比表。