外部体检系统对接技术方案

外部体检系统对接技术方案

1. 项目概述

1.1 对接目标

本项目旨在打通我方体检服务平台与各类外部体检机构信息系统（HIS/RIS/PACS）之间的数据壁垒，实现跨系统的患者信息自动同步与体检结果/报告的安全回传，最终构建完整的医疗业务闭环。

1.2 双方角色定义

  • 我方平台：由 Android APP（医护人员端）与 Java Spring Boot 后端组成。APP 负责轻量级的交互展示与业务操作；Java 后端作为核心枢纽，承担所有外部协议解析、数据转换与系统对接工作。
  • 三方机构（备开放接口能力）：指具备开放接口能力的现代化体检机构或第三方健康服务平台。此类机构通常提供标准的 RESTful API 或 Web Service 接口，支持基于 HTTP/HTTPS 协议的 JSON 数据交换，对接效率较高。
  • 医院机构（拥有 HIS/RIS/PACS）：指拥有传统医疗信息系统的实体医疗机构，主要包括 HIS（医院信息系统）、RIS（放射信息系统）或 PACS（影像归档和通信系统）。此类机构通常存在内网物理隔离，且多依赖 DICOM Worklist 等医疗专有协议进行数据交互。

2. 总体架构设计

2.1 职责分离原则

为保障系统的稳定性与可扩展性，架构设计严格遵循“后端适配、前端轻量”原则：

Android APP：仅负责 UI 渲染、用户交互及调用内部标准接口，绝不处理任何底层医疗协议（如 DICOM）或复杂的网络穿透逻辑。

Java 后端：作为统一的“桥梁”与“适配器”，集中处理所有外部对接工作，屏蔽不同体检机构系统的底层差异，向 APP 提供标准化的内部 API。

2.2 网络拓扑说明

针对医疗机构普遍存在的内网物理隔离问题，采用以下网络拓扑策略：

前置机/网关模式：在医院内网部署前置机或 API 网关，作为内外网交互的唯一合法通道。

安全策略：通过严格的 IP 白名单、端口映射及数据加密传输，确保医疗数据在跨网交互过程中的合规性与安全性。

2.3 架构链路描述

完整的数据流转链路如下：

1.Android APP发起业务请求

2.我方 Java 后端接收并路由

3.适配器层进行协议转换（HTTP/DICOM）

4.体检机构系统返回数据或接收结果

3. 核心协议解析：DICOM 与 Worklist

3.1 DICOM 协议定位

DICOM (Digital Imaging and Communications in Medicine) 是医疗影像领域的通用标准，可类比为医疗界的 TCP/IP + HTTP 协议族。它不仅定义了影像数据的存储格式，还规范了系统间的网络通信行为。

3.2 Worklist (MWL) 详解

定义：Modality Worklist Service Class 是 DICOM 标准中的一项核心服务，其本质是执行 C-FIND 查询指令，用于设备或系统从 RIS/HIS 获取待检患者列表。

局限性：

单向拉取：仅支持只读查询，无法主动推送数据。

字段受限：返回的数据字段固定且有限，难以满足复杂业务需求。

网络限制：通常仅限局域网内通信，不支持互联网直接访问。

适用场景：老旧医疗设备对接、无外网开放接口的纯内网环境。

3.3 HTTP API 优势

相比之下，基于 RESTful 架构的 HTTP API 具备显著优势：支持双向通信、数据结构丰富（JSON）、易于调试与扩展，是现代互联网医疗应用对接的首选方案。

3.4 Web 与 DICOM 概念映射

Web 开发概念

DICOM 协议概念

解释

IP + 端口

IP + 端口

完全一样。DICOM 默认端口通常是 104。

URL 路径

SOP Class UID

HTTP 用/api/v1/patients找资源；DICOM 用 SOP Class UID (如1.2.840...) 标识功能。

HTTP Method (GET/POST)

DICOM Command

HTTP 用 GET/POST；DICOM 用 C-FIND (查), C-STORE (存) 等。

JSON Body

DICOM Dataset

HTTP 用 JSON 传参；DICOM 用二进制标签 传参，如(0010,0010)代表姓名。

Token / 账号密码

AE Title

HTTP 用 Token 鉴权；DICOM 用 AE Title (系统代号) 互相验证身份。

HTTP 200 OK

Status Code (0x0000)

都是返回一个状态码告诉你操作成没成功。

4. 对接方案选型

4.1 方案 A：标准 HTTP API 对接（推荐）

适用对象：具备开放接口能力的现代化体检机构或区域卫生信息平台。

业务流程：我方后端通过 RESTful API 与体检机构进行 JSON 格式的数据交换，实现患者信息拉取与结果回传。

优势：开发成本低、联调效率高、易于维护。

4.2 方案 B：内网中间件/前置机模式

适用对象：网络物理隔离、仅支持内网访问的传统医院。

业务流程：

1. 在我方或院方内网部署专用的 Java 适配服务（前置机）。

2. 前置机通过 DICOM Worklist (C-FIND) 或读取数据库中间表获取体检数据。

3. 前置机将原始数据转换为标准 JSON 格式，通过安全通道暴露给我方外网后端调用。

4.3 方案 C：中间数据库表模式（备选）

•适用对象：网络物理隔离、无法部署前置机服务但允许受控数据库访问的传统医院。

•业务流程：

1.在医院内网建立独立的中间数据库表（或 Schema）。

2.HIS/RIS 系统在业务完成后，将患者信息与体检结果写入中间表。

3.我方前置机或定时任务通过只读账号轮询中间表，获取新数据并转换为 JSON 格式推送至我方后端。

•优势：实施成本极低，无需开发额外的接口服务；劣势：实时性略低于 API，需做好数据状态管理与防重处理。

5. 接口规范定义 (API Reference)

5.1 患者信息同步接口

用于从体检机构拉取待检患者信息。

属性

说明

方向

体检机构 ➔ 我方后端

请求方式

POST

请求路径

/api/v1/patients/sync

Content-Type

application/json

请求参数示例：

{ "patientId": "P202310240001", "name": "张三", "gender": "M", "age": 35, "examPackage": "精英男士全面体检套餐", "appointmentTime": "2023-10-25T09:00:00" }

5.2 体检结果回传接口

用于将体检结果及报告推送至体检机构系统。

属性

说明

方向

我方后端 ➔ 体检机构

请求方式

POST

请求路径

/api/v1/results/upload

Content-Type

application/json

请求参数示例：

{ "patientId": "P202310240001", "examItems": [ { "itemCode": "BG001", "itemName": "空腹血糖", "result": "5.2", "unit": "mmol/L", "reference": "3.9-6.1" }, { "itemCode": "XR002", "itemName": "胸部X光", "result": "正常", "conclusion": "心肺未见异常" } ], "reportPdfUrl": "https://oss.example.com/reports/P202310240001.pdf", "status": "COMPLETED" }

6. 实施步骤与风险控制

6.1 实施阶段规划

第一阶段：网络通道打通。完成 IP 白名单配置、端口映射及前置机部署，确保基础网络连通性。

第二阶段：接口联调与数据映射。完成 API 对接或 DICOM 协议解析，进行数据字段映射测试，确保数据准确性。

第三阶段：灰度上线与稳定性监控。选择小范围业务进行灰度测试，配置全链路监控与告警机制，验证系统稳定性后全量发布。

6.2 核心风险与应对

网络波动：引入重试机制与消息队列（MQ）进行异步削峰，确保数据不丢失。

数据格式不一致：在后端适配器层建立统一的数据清洗与校验规则，拦截脏数据。

患者隐私脱敏：严格遵循医疗数据合规要求，在传输和存储环节对敏感信息（如姓名、身份证）进行脱敏或加密处理。

7. 总结与建议

本方案确立了“后端适配、前端轻量”的核心架构思想，有效降低了 Android APP 的复杂度，提升了系统的整体可维护性。
在落地执行中，建议优先推动标准 HTTP API 方案，以获取最高的对接效率与数据丰富度；同时，保留并持续完善DICOM Worklist 适配模块，将其作为应对传统老旧系统的兜底手段，从而确保我方平台能够兼容并蓄，适应各类复杂的医疗信息化环境。