山东大学软件学院创新实训--“智愈医院自助服务系统“-(3)-“诊断书导入分析”功能
一、功能定位与业务流程
1.1 在系统中的定位
"智愈"系统设计了三个用户角色：游客、注册用户和管理员。三个角色使用系统的深度逐级递增，而"病情诊断书导入分析"功能服务于已经登录的注册用户，是"智能医生"模块的重要补充：
- 智能医生：用户主动提问，AI 以对话形式回答健康咨询
- 诊断书导入分析：用户上传真实诊断书，系统自动识别、分析、关联知识库，生成结构化的解读报告
两者形成"主动咨询 + 报告解读"的双通道体验，覆盖用户寻医问药的完整场景。
1.2 核心业务流程
整个功能从用户上传文件到拿到分析报告，需要经历以下关键步骤：
用户上传诊断书 → 文件校验与存储 → Qwen-VL 多模态识别
→ 结构化信息提取 → 本地知识库关联匹配 → 生成解读报告 → 前端展示
二、功能设计
2.1 功能模块全景
我们将整个功能拆解为四个核心模块，每个模块承担明确的职责：
病情诊断书导入分析
文件接入
- 多格式上传
- OSS存储
- 格式校验
智能识别
- Qwen-VL识别
- 结构化提取
分析解读
- 疾病关联
- 药品匹配
- 通俗化解读生成
结果展示
- 诊断概览卡片
- 异常指标高亮
- 关联知识跳转
- 历史记录回溯
2.2 模块一：文件接入
职责：接收用户上传的诊断书文件，完成前置校验并存储到云端。
项目现有的 FileController.java 已经实现了文件上传的基础能力——通过 OssClient 将文件上传至阿里云 OSS 并返回 URL。本模块将直接复用这一能力，同时补充诊断书场景的特殊需求：
支持的文件格式：
| 格式 | 说明 | 处理策略 |
|---|---|---|
| JPG / PNG | 手机拍照的检验单、处方 | 直接送入 Qwen-VL |
| 电子病历、出院小结 | 基于 PDFBox 提取文本；若为扫描件则逐页转图片后送入 Qwen-VL |
上传交互流程：
- 用户在"智能医生"页面或专门的诊断书分析入口选择文件
- 前端校验文件格式与大小（限制 10MB）
- 点击上传后，通过 AJAX 异步提交至
/file/upload接口 - 文件存储至阿里云 OSS，返回可公开访问的 URL
- 前端展示缩略图预览，用户确认后点击"开始分析"
/**
* 文件控制器
*
*/
@RestController
@RequestMapping("/file")
public class FileController extends BaseController<User> {
@Autowired
private OssClient ossClient;
/**
* 上传文件
*/
@PostMapping("/upload")
public RespResult upload(@RequestParam("file") MultipartFile file) throws IOException {
String url = ossClient.upload(file, String.valueOf(loginUser.getId()));
if (Assert.isEmpty(url)) {
return RespResult.fail("上传失败", url);
}
return RespResult.success("上传成功", url);
}
}
2.3 模块二：智能识别
职责：调用 Qwen-VL 多模态模型，从诊断书图片中提取文字并进行结构化解析。
这是整个模块的技术核心。利用 Qwen-VL 一次调用完成"识别 + 理解"两个任务，不走传统 OCR + 后处理的两阶段路线。
项目现有的 ApiService.java 已经封装了对通义千问 DashScope SDK 的调用，但当前只使用了纯文本模型（QWEN_TURBO）。本模块需要在其基础上增加图片输入的支持，调用通义千问的多模态能力。
Prompt 设计方案：
要让 Qwen-VL 输出符合系统要求的结构化数据，关键在于系统指令（System Prompt）的设计：
你是一位专业的病历分析助手。请分析图片中的诊断书内容，
以 JSON 格式输出以下信息（如果某项不存在则设为 null）：
1. patient_info: { name, gender, age } // 患者信息
2. diagnosis: { disease_name, icd_code } // 诊断结论
3. indicators: [{ name, value, unit, reference_range, is_abnormal }] // 检查指标
4. prescriptions: [{ drug_name, usage, dosage }] // 处方信息
5. advice: string // 医嘱建议
6. summary: string // 通俗解读（用患者能听懂的语言解释诊断结果）
注意：务必基于图片中的实际内容输出，不要编造信息。
通过这样的 Prompt 设计，Qwen-VL 一次推理即可返回结构清晰的 JSON，后端无需再做复杂的文本解析。
2.4 模块三：分析解读
职责：将 Qwen-VL 提取出的诊断信息与系统中的本地知识库做关联匹配，生成有上下文的分析报告。
这是"AI + 本地知识库"混合架构的关键环节。匹配链路由三个步骤组成：
步骤一：疾病关联
将 Qwen-VL 识别出的 disease_name 与项目数据库中的 illness 表做模糊匹配：
- 完全匹配则直接关联
- 部分匹配则使用 MySQL
LIKE查询或分词匹配 - 匹配成功后获取：疾病名称、引起原因、主要症状、特殊症状
项目的 IllnessService.java 已有成熟的 findIllness() 方法实现了多字段模糊搜索，可以直接复用。
步骤二：药品关联
识别出的处方药品名称，与 medicine 表做关联：
- 获取药品功效、用法用量、禁忌、相互作用
- 通过
illness_medicine关联表反查该疾病对应的推荐药品列表 - 若处方药品不在本地库中，则标记为"未收录药品"，仅展示 AI 识别结果
步骤三：通俗化解读生成
第二次调用通义千问（纯文本模型），将结构化诊断数据 + 本地知识库信息整合为通俗易懂的解读文本：
- 避免医学术语堆砌
- 用自然语言解释"检查指标异常意味着什么"
- 给出生活建议和注意事项
- 附加"请以主治医生意见为准"的免责声明
2.5 模块四：结果展示
职责：将分析结果以清晰、直观的方式展示给用户。
Web 端采用项目现有的 Thymeleaf + jQuery + Bootstrap 技术栈，设计以下展示区域：
诊断概览卡片区：
- 顶部展示患者信息（已脱敏）和就诊日期
- 核心诊断结论用醒目字体展示
- 异常检查指标用红色高亮，正常指标用绿色
关联知识面板：
- 展示系统数据库中匹配到的疾病详情入口
- 展示推荐药品列表
- 展示药品相互作用与禁忌提醒
通俗解读区：
- AI 生成的通俗化解读报告全文
- 附加"本报告仅供参考，不构成医疗建议"的提示
2.6 处理流程时序图
用户 前端 后端服务 阿里云OSS Qwen-VL
│ │ │ │ │
│ ①选择诊断书并上传 │ │ │ │
│────────────────────>│ │ │ │
│ │ ②POST /file/upload │ │ │
│ │────────────────────>│ │ │
│ │ │ ③存储文件 │ │
│ │ │────────────────────>│ │
│ │ │<──── 返回文件URL ────│ │
│ │<─ 返回URL与预览图 ───│ │ │
│ ┌───────────────────│ │ │ │
│ │ ④用户确认分析 │ │ │ │
│ └───────────────────│ │ │ │
│ │ ⑤POST /diagnosis │ │ │
│ │ /analyze │ │ │
│ │────────────────────>│ │ │
│ │ │ ⑥调用Qwen-VL多模态 │ │
│ │ │──────────────────────────────────>│
│ │ │<── ⑦返回结构化JSON ───────────────│
│ │ │ │ │
│ │ │ ⑧解析JSON │ │
│ │ │ ⑨查询illness/ │ │
│ │ │ medicine知识库 │ │
│ │ │ │ │
│ │ │ ⑩调用QWEN_TURBO │ │
│ │ │ 生成通俗解读 │ │
│ │ │──────────────────────────────────>│
│ │ │<── ⑪返回解读文本 ────────────────│
│ │ │ │ │
│ │ │ ⑫持久化分析结果 │ │
│ │ │ │ │
│ │<─ ⑬返回完整分析结果─│ │ │
│ ┌───────────────────│ │ │ │
│ │ ⑭渲染展示结果 │ │ │ │
│ └───────────────────│ │ │ │
三、技术选型
3.1 整体技术栈
| 层次 | 技术选型 | 选型依据 |
|---|---|---|
| 前端渲染 | Thymeleaf + jQuery + Bootstrap | 项目现有技术栈 |
| 文件上传 | 阿里云 OSS SDK | 项目中 OssClient.java 已封装完整 |
| 多模态识别 | Qwen-VL（DashScope SDK） | 第二篇博客已完成选型论证 |
| 语义分析 | 通义千问 QWEN_TURBO（DashScope SDK） | 项目中 ApiService.java 已接入 |
| 数据存储 | MySQL + MyBatis-Plus | 项目现有 ORM 框架 |
| 异步处理 | Spring @Async + CompletableFuture |
零额外依赖，Spring Boot 原生支持 |
| PDF 解析 | Apache PDFBox | 成熟稳定，Apache 开源协议 |
3.2 异步处理策略
诊断书分析包含两次 AI 调用（Qwen-VL 多模态识别 + QWEN_TURBO 生成解读），耗时通常在 5-15 秒。如果采用同步处理，用户将长时间等待 HTTP 响应，体验极差。
因此采用异步处理架构：
前端提交分析 → 后端立即返回（状态：处理中）
→ 后端异步执行识别与分析
→ 前端轮询查询处理状态
→ 状态变更为"已完成"后拉取结果展示
项目使用 Spring Boot 自带的 @Async 注解即可实现异步执行，配合 CompletableFuture 编排多步骤任务，无需引入消息队列等重依赖。
3.3 为什么坚持"AI + 本地知识库"的混合架构？
纯 AI 方案的问题：
| 问题 | 具体表现 |
|---|---|
| 幻觉 | AI 可能生成系统中根本不存在的药品或疾病名称 |
| 不一致 | AI 对药品功效的描述可能与数据库中官方维护的信息矛盾 |
| 成本高 | 让 AI 完整生成所有关联信息，Token 消耗大 |
| 响应慢 | 生成长篇内容的延迟显著增加 |
混合方案的应对：
- AI 只做"理解"与"提取"——这是 AI 擅长且不可替代的部分
- 知识关联走本地数据库查询——结果 100% 准确且与系统已有数据一致
- 用户点击"查看详情"时跳转到现有的疾病详情页（illness-reviews.html）和药品详情页（medicine.html），体验无缝统一
- Token 消耗控制在全 AI 方案的 30%-40%
四、总结
本篇博客完成了"病情诊断书导入分析"模块的完整功能设计与技术选型。核心思路可以概括为三条设计原则：
- 继承：基于 Qwen-VL 构建识别能力，不做重复选型
- 复用：最大化复用"智愈"系统现有的文件上传、AI 集成、知识查询能力
- 混合：AI 做理解与提取，本地数据库做知识关联，各取所长
下一篇博客：
- 新建诊断书分析相关的数据表
- 实现 DiagnosisController 与 DiagnosisService
- 扩展 ApiService 支持 Qwen-VL 多模态调用
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
7
0- 0
已为社区贡献4条内容
所有评论(0)