外部体检系统对接技术方案
外部体检系统对接技术方案
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 适配模块，将其作为应对传统老旧系统的兜底手段，从而确保我方平台能够兼容并蓄，适应各类复杂的医疗信息化环境。