feat：体检系统医院前置机、影像中心、体检医生端需求说明文档

2026-09-15 18:47:05 +08:00
parent 3e7cd268fa
commit c85d9c124e
25 changed files with 474 additions and 0 deletions
@@ -0,0 +1,94 @@
+# 体检医生小白盒终端 需求说明文档
+
+## 1. 系统概述
+
+体检医生小白盒终端是体检「检中」环节医生使用的 Android 应用，用于在体检过程中核销员工的体检项目。医生扫码确认员工身份后，核对并核销其已选体检项目，核销结果作为员工"已检"状态的数据来源回传体检管理端。
+
+- **使用角色**：体检医生
+- **终端形态**：
+  - 一体机版（扫码小白盒+PAD）：设备预装 APP，无需下载安装
+  - 手机版：外出体检时扫描二维码下载"医生工作端"手机版 APP
+- **版本差异**：手机版与一体机版功能界面一致，唯一区别是手机版使用手机摄像头扫码
+- **参考代码仓库**：[医生端小白盒程序（pad）](https://gitea.rk-health.com/yixiong/doctor-workstation-pad)
+- **参考代码仓库**：[医生端小白盒程序（mobile）](https://gitea.rk-health.com/yixiong/doctor-working-terminal-mobile)
+
+## 2. 功能模块说明
+
+### 2.1 登录
+
+输入账号、密码登录，可勾选"记住用户名"。账号由管理员在管理端创建，初始多为统一密码（修改见 2.6）。
+
+![登录界面](screenshots/whitebox-terminal/login.jpg)
+
+### 2.2 体检项目选择
+
+- **删除已选项目**：移除员工已选的体检项目
+- **添加项目**：点击"添加项目"弹出项目添加界面，可选择单项体检项目或项目组合
+- **修改项目**：点击"修改"开启项目编辑界面，调整已选项目
+- **保存**：选定后点击"确定"按钮保存
+
+![体检项目选择界面 1](screenshots/whitebox-terminal/select-1.jpg)
+![体检项目选择界面 2](screenshots/whitebox-terminal/select-2.jpg)
+![体检项目选择界面 3](screenshots/whitebox-terminal/select-3.jpg)
+
+### 2.3 项目组合查看
+
+- 首页点击项目组合图标，弹出该组合包含的体检项目明细
+- 添加项目界面长按项目组合图标，同样弹出组合包含的项目信息
+
+![项目组合查看 1](screenshots/whitebox-terminal/combo-1.jpg)
+![项目组合查看 2](screenshots/whitebox-terminal/combo-2.jpg)
+
+### 2.4 扫码核销
+
+1. 在项目选择界面点击"开始工作"，进入工作界面，等待员工扫码
+2. 员工扫码成功后，界面左侧显示员工信息与项目信息
+3. 倒计时 5 秒自动完成核销；期间可点击项目信息停止倒计时，核对无误后点击"确定"
+4. 倒计时结束或确认后，右侧"今日体检员工列表"刷新，左侧返回等待扫码界面
+
+![扫码核销 1](screenshots/whitebox-terminal/verify-1.jpg)
+![扫码核销 2](screenshots/whitebox-terminal/verify-2.jpg)
+![扫码核销 3](screenshots/whitebox-terminal/verify-3.jpg)
+
+### 2.5 今日体检员工列表
+
+展示当日已核销员工列表，随核销操作实时刷新。
+
+### 2.6 设置
+
+首页右上角"设置"按钮，弹出菜单包含：
+
+- **设置签名**：医生设置电子签名，点击后弹出签名编辑窗口
+- **修改密码**：账号多为统一初始密码，建议首次登录后修改
+- **检查新版本**：设备持续开机期间发布新版本时，手工检查并安装升级
+
+![设置 1](screenshots/whitebox-terminal/setting-1.jpg)
+![设置 2](screenshots/whitebox-terminal/setting-2.jpg)
+![设置 3](screenshots/whitebox-terminal/setting-3.jpg)
+
+### 2.7 软件安装与版本
+
+- 一体机版：出厂预装，无需下载安装
+- 手机版：扫描二维码下载安装"医生工作端"手机版 APP
+
+![下载二维码](screenshots/whitebox-terminal/qrcode.png)
+![一体机安装](screenshots/whitebox-terminal/install.png)
+
+手机版与一体机版功能界面一致，唯一区别是手机版使用手机摄像头扫码：
+
+![手机版界面](screenshots/whitebox-terminal/phone.jpg)
+
+## 3. 业务规则与数据流转
+
+- 医生账号由管理端管理员创建（初始统一密码）
+- 体检项目、项目组合配置来源于管理端
+- 核销结果回传管理端，作为"已检员工"与医生检查情况统计的数据来源
+- 核销确认方式：倒计时 5 秒自动完成，或医生人工点击"确定"
+
+### 存疑 / 待补充
+
+以下内容现有资料（医生端操作说明 PPT）未明确，整理时暂按业务常识推断，待与原始系统核对：
+
+- 员工扫码的二维码来源（是否体检指引单二维码）
+- 核销失败 / 项目不符的异常处理方式
+- 电子签名的具体用途（是否作为核销凭证落款）
@@ -0,0 +1,269 @@
+# 医院前置机 需求说明文档
+
+## 1. 系统概述
+
+医院前置机是「健康体检系统」与「医院 HIS 系统」之间的中间对接层（中转程序）。健康体检系统不直接连接医院数据库，而是通过本系统提供的 HTTP 接口，间接完成预约下发、取消预约、单位同步，以及体检项目字典、体检报告的回流。
+
+- **系统性质**：纯后端中转程序，无操作界面
+- **技术栈**：Java 17 + Solon 4.0.6 + MyBatis-Plus 3.5.9，数据库适配 Oracle / SQL Server
+- **部署方式**：一套代码 + 多套外置配置，通过 `hospital.active` 切换对接不同医院；打包为 jar 配合启动脚本运行，配置文件外置（`conf/app-{医院}.yml`），修改配置无需重新打包
+- **医院适配**：策略模式（`HospitalAdapter` 接口 + `HospitalRouter` 路由），方言基类 `BsmAdapterBase`（Oracle）/ `NxAdapterBase`（SqlServer）
+- **接口形态**：业务接口统一前缀 `/order`，管理接口统一前缀 `/api/admin`，支持 HTTP Basic 认证（可配置开关）
+- **参考代码仓库**：[医院前置机系统（Java）](https://gitea.rk-health.com/renkang/hospital-front)
+- **参考代码仓库**：[医院前置机探针-远程运维（Java）](https://gitea.rk-health.com/renkang/hospital-front-agent)
+
+> 本程序重构自旧版 `hospitalmiddle`（SpringBoot 2.7 + MyBatis-Plus），接口路径与出参结构保持与原程序一致（调用方契约，不可修改）。
+
+## 2. 总体架构与业务链路
+
+### 2.1 系统定位
+
+```mermaid
+flowchart TB
+    subgraph HS["健康体检系统"]
+        WEB["Web 管理端 / 员工端"]
+        CLIENT["MedicalApiService<br/>(HTTP 客户端封装)"]
+        JOB["XXL-JOB 定时任务"]
+    end
+
+    subgraph FRONT["医院前置机"]
+        API["OrderApi<br/>/order/** 业务接口"]
+        ADMIN["AdminApi<br/>/api/admin/** 运维接口"]
+        ROUTER["HospitalRouter<br/>策略路由"]
+    end
+
+    subgraph HOSP["医院 HIS 数据库"]
+        H1["兴隆园 Oracle"]
+        H2["庆阳 Oracle"]
+        H3["泾河 Oracle"]
+        H4["宁夏宝石花 SqlServer"]
+        H5["延安 SqlServer"]
+    end
+
+    WEB -->|"预约/取消/单位同步/字典同步"| CLIENT
+    JOB -->|"报告回流/单位同步"| CLIENT
+    CLIENT -->|"HTTP Basic 认证"| API
+    API --> ROUTER
+    ROUTER --> H1 & H2 & H3 & H4 & H5
+    ADMIN -.->|"远程运维"| FRONT
+```
+
+### 2.2 下发方向（健康体检系统 → 医院）
+
+```mermaid
+sequenceDiagram
+    autonumber
+    participant U as 员工/管理员
+    participant Q as Redis 阻塞队列
+    participant S as 健康体检系统
+    participant F as 医院前置机
+    participant H as 医院 HIS
+
+    Note over U,H: 预约下发（实时 + 队列重试）
+    U->>S: 发起预约
+    S->>Q: 写入预约队列
+    Q->>S: 消费者取出
+    S->>S: 组装 OrderVo<br/>(人员/单位/体检属性/职业/项目)
+    S->>F: POST /order/saveOrder
+    F->>H: 调医院存储过程写入
+    H-->>F: 返回 peId
+    F-->>S: 返回 peId
+    S->>S: 保存 peId / 失败进队列重试(3次)
+
+    Note over U,H: 单位同步（定时任务）
+    S->>S: 定时扫描二级/三级单位
+    S->>F: POST /order/addUnit
+    F->>H: 逐条写入医院单位表
+    F-->>S: 返回每条处理结果
+
+    Note over U,H: 取消预约（实时 / 批量）
+    U->>S: 取消预约
+    S->>F: POST /order/cancelOrder/{peId}
+    F->>H: 调医院取消预约存储过程
+    F-->>S: 返回取消结果
+```
+
+### 2.3 拉取方向（医院 → 健康体检系统）
+
+```mermaid
+sequenceDiagram
+    autonumber
+    participant J as 定时任务/管理端
+    participant S as 健康体检系统
+    participant F as 医院前置机
+    participant H as 医院 HIS
+
+    Note over J,H: 体检报告回流（4 个定时任务 + 手动补录）
+    J->>S: synUserResultYesterday<br/>(按昨日终审日期增量)
+    S->>F: GET /order/getExamListByDate
+    F->>H: 查当日终审人员(去重)
+    H-->>F: 人员清单
+    F-->>S: 人员清单
+    S->>S: 按身份证匹配本系统员工
+    S->>F: GET /order/getResultByPeId/{peId}
+    F->>H: 查报告主表/指标/结论/建议
+    F->>F: 组装报告(补 hospitalId/结论/建议)
+    F-->>S: 全量报告
+    S->>S: 落库 + 更新"已体检/已终审"
+
+    Note over J,H: 项目字典同步（管理端手动触发）
+    J->>S: 点击同步项目字典
+    S->>F: GET /order/getAllItemList
+    F->>H: 查指标项 + 组合项
+    H-->>F: 项目字典
+    F-->>S: 项目字典
+    S->>S: 更新指标项/组合项/映射表
+
+    Note over J,H: 预约兜底（预约时医院已存在记录）
+    S->>F: GET /order/getPeIdAndDateByIdcard
+    F->>H: 按身份证查当年 peId+预约日期
+    F-->>S: peId 列表
+    S->>S: 取最新同步项目 + 批量取消多余预约
+```
+
+## 3. 功能模块说明
+
+### 3.1 下发方向（健康体检系统 → 医院）
+
+#### 3.1.1 预约下发（实时 + 队列重试）
+
+员工发起预约后，健康体检系统组装预约信息写入 Redis 阻塞队列，由消费者线程调用前置机 `POST /order/saveOrder`，前置机转换为管道符字符串后调用医院存储过程写入，返回体检唯一编号 `peId`。
+
+下发数据包含五部分（由 `MedicalApiServiceImpl.generateOrderVo` 组装）：
+
+| 分类 | 字段 |
+|------|------|
+| 人员基本信息 | 姓名、性别、身份证号、出生日期、年龄、婚姻、民族、学历、移动电话、邮箱、员工编号 |
+| 单位组织 | 二级单位编码/名称、三级部门名称 |
+| 体检属性 | 预约日期、体检类型（健康/职业）、体检类别（岗前/在岗期间）、用工形式、入职时间、工作地 |
+| 职业健康信息 | 仅「职业体检」携带：危害因素编码/其他、工种编码/其他、接害时间 |
+| 项目清单 | 所选体检项目（`itemList`） |
+
+交互失败时进入 `medical_order_queue` 队列表重试（默认重试 3 次），成功后将 `peId` 写入 `user_form.md_pe_id`。
+
+#### 3.1.2 单位同步（定时任务）
+
+通过 XXL-JOB 定时任务扫描本系统单位组织，逐条推送给前置机 `POST /order/addUnit`，前置机逐条写入医院并返回每条处理结果，失败项汇总错误信息。
+
+- **二级单位**（组织编码长度 = 6）与**三级单位**（长度 = 9）分开同步
+- 三级单位存在两个版本：普通版、`ThirdNew` 版（单位名称带「二级-三级」前缀）
+- 字段：单位编码、单位名称、地址、上级单位编码、联系人1/电话1、联系人2/电话2
+
+#### 3.1.3 取消预约（实时 + 批量）
+
+健康体检系统按 `peId` 下发取消指令（附带姓名、身份证号），前置机调用医院取消预约存储过程完成取消。预约兜底场景下发现同一员工存在多条重复预约时，逐条批量取消多余 `peId`。
+
+### 3.2 拉取方向（医院 → 健康体检系统）
+
+#### 3.2.1 体检项目字典同步（管理端手动触发）
+
+从医院查询体检组合项目、指标项目（编码 + 名称），回流给健康体检系统用于项目配置与映射。落库三张表：`medical_hospital_item`（指标项）、`medical_hospital_item_rel`（指标-组合关联）、`medical_item_syn`（组合项）。
+
+#### 3.2.2 体检报告回流（4 个定时任务 + 手动补录）
+
+这是前置机承载的**核心业务**，通过 4 个 XXL-JOB 定时任务 + 手动补录接口完成：
+
+| 任务 | 触发方式 | 前置机接口 | 用途 |
+|------|---------|-----------|------|
+| `synUserResultJob` | 定时 | `getResultByPeId` | **补传**：查已预约但未拉取报告的人员，补拉全量报告 |
+| `synUserResultUpdateJob` | 定时 | `getResultStatusByPeId` → `getResultByPeId` | **更新**：先查报告状态比对终审日期，有更新才拉全量 |
+| `synUserResultUpdateJobForce` | 定时 | `getResultByPeId` | **强制更新**：指定医院+年份强制重拉 |
+| `synUserResultYesterday` | 定时 | `getExamListByAuditDate` → `getResultByPeId` | **增量**：查昨日终审人员清单→匹配员工→强制拉取 |
+| 手动补录 | 管理端接口 | `getResultByPeId` / `getResultByIdcardAndYearAll` | 单条清除后重新获取 |
+
+- **报告组装**：前置机逐条补 `hospitalId`、指标结果子表、体检结论（`序号.科室:结论`）、体检建议
+- **落库**：`middle_result`（中间表，供一库一中心）、`user_result` / `user_result_item` / `user_result_ext`、`hm_checkitem`
+- **状态联动**：拉到报告后自动把 `user_form.medical_status` 置「已体检」、`md_pe_status` 置「已终审」，并自动补已婚妇科项目
+- 三个同步任务共持一把 Redis 分布式锁（`medical:syn:task_lock`）互斥执行
+
+#### 3.2.3 预约兜底查询（实时）
+
+预约下发时若医院返回「本年度已存在 / 已登记 / 已存储预约记录」，说明医院侧已有预约记录。此时按身份证查询当年 `peId` 与预约日期，取最新一条同步项目，其余重复预约批量取消。
+
+#### 3.2.4 员工体检项目查询
+
+按 `peId` 查询某次预约员工已选/已完成的体检项目，用于预约成功后同步医院项目到本系统预约子表。
+
+#### 3.2.5 按身份证 + 年份查状态及项目
+
+按身份证号 + 年份查询员工当年体检状态及体检项目清单。
+
+### 3.3 接口认证与监控运维
+
+- **接口认证**：`/order/**` 走 HTTP Basic 认证（账号在各医院配置中设置，五家医院统一账号）；`/api/admin/**` 走 `X-Admin-Token` 请求头
+- **远程运维**：`/api/admin` 提供健康检查、版本查询、配置查看（脱敏）、配置读写、日志查看/下载、优雅重启、HTTP 代理、接口清单
+- **监控**：Uptime-Kuma 心跳上报（可配置，默认关闭）、数据库健康监测（缓存秒回）
+- **统一全局异常拦截**，返回友好错误提示
+
+## 4. 对外接口清单
+
+### 4.1 业务接口（`/order/**`）
+
+| 接口路径 | 方法 | 用途 | 状态 |
+|---------|------|------|------|
+| `/order/saveOrder` | POST | 提交预约 | ✅ 在用 |
+| `/order/cancelOrder/{peId}` | POST | 取消预约 | ✅ 在用 |
+| `/order/addUnit` | POST | 添加/修改单位 | ✅ 在用 |
+| `/order/getAllItemList` | GET | 全量指标项+组合项（项目字典） | ✅ 在用 |
+| `/order/getResultByPeId/{peId}` | GET | 按 peId 查全量报告（组装版） | ✅ 在用 |
+| `/order/getResultStatus/{peId}` | GET | 按 peId 查报告状态（简版） | ✅ 在用 |
+| `/order/getResultByIdcardAndYearAll/{idNo}/{year}` | GET | 按身份证+年份查全量结果 | ✅ 在用 |
+| `/order/getExamListByDate` | GET | 按终审日期查人员清单（去重） | ✅ 在用 |
+| `/order/getPeIdAndDateByIdcard/{idNo}` | GET | 按身份证查当年 peId+预约日期 | ✅ 在用 |
+| `/order/getPeIdAndDateByIdcardList/{idNo}` | GET | 同上（数组） | ✅ 在用 |
+| `/order/getEmpItem/{peId}` | GET | 员工体检项目 | ✅ 在用 |
+| `/order/getPeStatusAndItemList/{idNo}/{year}` | GET | 按身份证+年份查状态及项目 | ✅ 在用 |
+| `/order/getItemList` | GET | 体检组合项目（旧） | ⛔ 废弃 |
+| `/order/getPeItemList` | GET | 体检指标项（旧） | ⛔ 废弃 |
+| `/order/getItemInfo/{peItemCode}` | GET | 按指标项查所属组合（旧） | ⛔ 废弃 |
+| `/order/getPeStatus/{peIds}` | GET | 多 peId 状态查询（旧） | ⛔ 废弃 |
+| `/order/getResult/{peId}` | GET | 按 peId 查结果（旧） | ⛔ 废弃 |
+
+> 标注「⛔ 废弃」的接口在前置机中仍保留（调用方契约），但健康体检系统当前业务已不再调用，属历史遗留。
+
+### 4.2 管理接口（`/api/admin/**`）
+
+| 接口路径 | 用途 |
+|---------|------|
+| `/api/admin/health` | 健康检查（进程 + 数据库 + JVM） |
+| `/api/admin/version` | 版本信息 |
+| `/api/admin/config` | 查看当前生效配置（脱敏） |
+| `/api/admin/config/file` | 读取/写回医院配置文件 |
+| `/api/admin/log/files` | 日志文件列表 |
+| `/api/admin/log/tail` | 日志尾部查看 |
+| `/api/admin/log/download` | 日志全量下载 |
+| `/api/admin/restart` | 优雅重启 |
+| `/api/admin/httpProxy` | HTTP 代理（供 B 端接口测试工具） |
+| `/api/admin/apis` | 业务接口清单（反射扫描） |
+
+## 5. 核心业务规则
+
+### 5.1 数据版本（V1 / V2）
+
+由配置项 `hm.ver` 决定：V2 走新版字段（职业健康细分为「编码 + 其他 + 接害时间」），V1 用笼统单字段（工种 / 危害因素）。版本与医院绑定。
+
+### 5.2 职业 / 健康体检区分
+
+当体检类型为「健康体检」时，不下发职业相关字段（危害因素、工种、接害时间）；仅「职业体检」携带职业健康监护信息。健康体检系统侧（`generateOrderVo`）与前置机侧（`hm.occFlag` 开关，默认关闭）均有处理。
+
+### 5.3 单位编码截断（宁夏特殊）
+
+当二级单位编码为 9 位时，自动截取前 6 位下发，单位名称截取到第一个「-」之前。由配置开关 `allsecond.flag` 控制，默认关闭，属临时兼容规则。
+
+### 5.4 体检状态映射
+
+统一状态字典：预约 = 1、报到 = 2、检中 = 3、初审 = 4、终审 = 5。健康体检系统的「已体检 / 已终审」状态由**报告回流**自动更新，不依赖独立的体检状态回流接口。
+
+### 5.5 报告组装与文本清洗
+
+报告回流时逐条补充医院 ID、指标结果子表、汇总结论、汇总建议；结论 / 建议中的换行、制表符、空格统一清洗，个别医院额外去除固定尾缀文案。宁夏建议取首条 `guideContent`，其余医院按「序号.建议项:建议内容」拼接。
+
+## 6. 对接医院清单
+
+| 医院 | 配置标识 | 数据库 | 方言 | 数据版本 | 备注 |
+|------|---------|--------|------|---------|------|
+| 兴隆园医院 | xinglongyuan | Oracle | bsm | V2 | 走通用逻辑 |
+| 庆阳医院 | qingyang | Oracle | bsm | V2 | 库连接暂与泾河一致 |
+| 泾河医院 | jinghe | Oracle | bsm | V2 | 默认激活医院 |
+| 宁夏宝石花医院 | ningxia | SqlServer | nx | V2 | 规则最多、最特殊 |
+| 延安医院 | yanan | SqlServer | nx | V2 | 库结构与宁夏一致，需 TLS1.0 特殊安全策略 |
@@ -0,0 +1,111 @@
+# 影像中心 需求说明文档
+
+## 1. 系统概述
+
+影像中心是体检影像数据的接收、处理、存储、解析与浏览平台。它从各承检医院获取体检产生的影像数据（CT、核磁、超声、X射线、心电等 DICOM 影像及报告文件），经处理后供后台管理端查看、员工移动端浏览本人历次体检影像。
+
+- **系统性质**：后端数据处理平台 + Web 后台管理界面 + 医院前置机桥接程序
+- **技术架构**：SpringCloud 微服务（Nacos + Gateway）+ MyBatis-Plus + MySQL + Redis + xxl-job 定时任务 + Redisson 阻塞队列；DICOM 影像接入开源 Orthanc 服务器；文件存储于独立文件服务器
+- **本次范围**：仅「体检影像管理」部分，系统管理、系统监控不在本说明范围内
+- **参考代码仓库**：
+  - [影像中心服务端代码（Java）](https://gitea.rk-health.com/renkang/data-center-boot-spring3/src/branch/prod-cq/jeecg-module-imc)
+  - [影像中心前端代码（Vue）](https://gitea.rk-health.com/renkang/data-center-vue3/src/branch/dev-cq/src/views/imc)
+  - [影像原始文件在线预览组件（Orthanc）](https://www.orthanc-server.com/)
+  - [医院前置机（打包压缩）](https://gitea.rk-health.com/renkang/imgpack)
+  - [医院前置机（上传）](https://gitea.rk-health.com/renkang/imgupload)
+  - [医院前置机（解包处理）](https://gitea.rk-health.com/renkang/imgunpack)
+## 2. 核心业务流程
+
+影像数据从医院到体检系统共四段流程：
+
+![数据流向图](screenshots/imc/flow.jpg)
+
+### 2.1 影像数据接入（医院前置机 → 影像中心）
+
+1. 各医院前置机从医院 PACS 系统 / 体检系统采集影像数据（DICOM 影像 + 报告文件），按员工打包为 zip 压缩包
+2. 前置机调用影像中心 `/imc/file/upload` 接口，上传 zip 压缩包及结构化元数据（体检编号 peId、身份证号、体检年份、影像分类、医院、检查项目列表）
+3. 影像中心校验（必须为 zip、文件名不含空格）后，将 zip 存入文件服务器，生成「文件处理日志」记录（状态置为「待解析」）
+
+### 2.2 影像数据处理（影像中心内部）
+
+1. xxl-job 定时任务触发解析，筛选「待解析 / 失败待重试」的日志记录
+2. 下载 zip 并解压至本地临时目录，通过 Redisson 阻塞队列异步消费处理
+3. 队列消费者按元数据解析：
+   - 建立 / 更新「用户体检信息」（按 peId + 身份证号 + 体检年份 + 医院唯一）
+   - 为每个检查项目建立 / 更新「用户影像文件分类」记录
+   - 解析影像文件：DICOM（dic / dcm）上传至 Orthanc 服务器解析标签；非 DICOM 影像上传文件服务器
+   - 解析报告文件（png / jpg / pdf）上传文件服务器
+   - 每个文件生成「用户影像文件详细」记录
+4. 处理状态流转：新建 → 待解析 → 解析中 → 成功 / 失败待重试（最多重试 3 次）→ 最终失败
+
+### 2.3 影像数据下发（影像中心 → 体检系统）
+
+解析完成后，影像中心异步调用体检预约系统（四合一）接口 `medical/userImage/receiveItem`，推送影像数据（体检编号、身份证号、医院、体检年份、影像项目列表：检查项目名称、检查结果、报告时间、报告路径、研究实例 ID），供体检系统关联员工体检档案。
+注：线上系统目前是直接从影像服务将数据写入到了体检系统的数据库并未走接口通道
+
+### 2.4 影像浏览（影像中心 → 后台 / 移动端）
+
+- 后台管理端及员工移动端通过影像中心接口浏览影像
+- Orthanc 接口转发：预览 DCM、下载 DCM、获取标签、按研究实例浏览
+- 查询接口：按 peId + 医院查询影像项目列表
+
+## 3. 功能模块说明（体检影像管理）
+
+### 3.1 用户体检信息
+
+查看有影像信息的体检用户列表；展开某用户可查看其检查项目数据；支持预览影像文件、下载影像报告。
+
+![用户体检信息](screenshots/imc/user-images.jpg)
+
+![影像文件预览界面](screenshots/imc/user-preview.jpg)
+
+![影像报告查看](screenshots/imc/user-report.jpg)
+
+### 3.2 用户影像文件分类
+
+查看每个检查项目的影像文件处理情况，含影像文字报告（检查结果）、报告时间、文件解析情况等。
+
+![用户影像文件分类](screenshots/imc/images-class.jpg)
+
+### 3.3 用户影像文件详细
+
+查看每个文件（报告文件、DICOM 文件）的处理情况，含文件类型、影像序号、错误信息、DICOM 实例 ID 等。
+
+![用户影像文件详细](screenshots/imc/images-detail.jpg)
+
+### 3.4 文件处理日志
+
+查看每份上传的影像压缩包（zip）的处理情况，含文件大小、传输 / 解析时间、处理状态、错误信息等。
+
+![文件处理日志](screenshots/imc/file-log.jpg)
+
+## 4. 数据模型与数据字典
+
+### 4.1 数据模型
+
+| 表 | 用途 |
+|---|---|
+| imc_medical_user | 用户体检信息（有影像的体检用户） |
+| imc_medical_user_images_class | 用户影像文件分类（每个检查项目一条） |
+| imc_medical_user_images_info | 用户影像文件详细（每个文件一条） |
+| imc_medical_data_log | 文件处理日志（每份上传 zip 一条） |
+
+### 4.2 数据字典
+
+| 字典 | 取值 |
+|---|---|
+| 影像分类 image_class | 1 超声、2 CT、3 MRI、4 X射线、5 心电 |
+| 影像文件类型 image_file_type | 0 非DICOM、1 dic、2 dcm |
+| 报告文件类型 report_file_type | 1 png、2 jpg、3 pdf |
+| 文件类型 file_type | 1 影像、2 报告 |
+| 处理状态 handle_status | 1 新建、2 待解析、3 失败、4 解析中、5 成功、6 失败待重试、7 最终失败 |
+
+## 5. 核心业务规则
+
+- 上传文件必须为 zip 压缩包，文件名不能含空格
+- DICOM 影像（dic / dcm）上传 Orthanc 解析并提取标签（实例 ID、患者 ID、研究实例 ID），报告及非 DICOM 文件上传文件服务器
+- 文件后缀必须与声明的文件类型一致，否则不解析
+- 解析失败自动重试，最多 3 次，超过则标记「最终失败」
+- 超声影像只取最终报告、不取全部图像（对接约定，由前置机侧控制上传内容）
+- 影像数据以 peId + 身份证号 + 体检年份 + 医院 唯一确定一位员工的一次体检
+- 解析完成后通知体检预约系统，完成影像数据闭环