项目介绍： 这是一个面向流程自动化的医疗报告智能解析工具。支持上传PDF、扫描件及手机拍照件，可自动处理检验报告、影像报告、体检报告、出院小结等多种文档，抽取患者信息、报告信息、检查指标、诊断结论、治疗方案及用药信息等核心字段，并输出统一结构的JSON格式。具备图像倾斜校正、透视矫正、表格区域还原、异常指标标记及原文坐标溯源能力。适用于在线问诊、保险理赔、智能导诊及医疗归档等场景。

GitHub项目地址：https://github.com/intsig-textin/xparse-sample-projects

在互联网医疗和保险理赔场景中，医疗文档始终是最关键的数据入口之一。检验报告、影像报告、体检报告、出院小结，看似都属于“报告”，实际结构却差异很大。更复杂的是，这些文件往往并非标准电子版，很多来自扫描件或手机拍照，常伴随倾斜、弯曲、反光和表格变形。

如果仍然依赖人工录入，不仅效率低，而且容易漏掉异常指标、关键时间和诊断信息。一个成熟的医疗报告解析方案，价值不在于把报告转成全文文本，而在于把异构文档整理成可直接用于问诊、理赔、归档和导诊的结构化数据。

一、医疗报告自动化处理的难点在哪里？

医疗文档的复杂性，主要体现在三个层面。

第一，报告类型多。 检验报告偏表格，影像报告更像长段落，病历和出院小结则混合诊断、治疗、用药和医嘱。

第二，输入质量不稳定。 很多真实业务场景里，文档来自拍照上传，存在图像畸变和排版破坏，单纯依赖传统 OCR 往往很难稳定还原结构。

第三，不同业务要求各异。 在线问诊关心异常指标和结论，理赔流程更关心患者信息、医院名称、时间和诊断依据。也就是说，系统要输出的是“可用信息”，而不是“可见文本”。

这意味着，真正有价值的方案，不能依赖为每一家医院、每一种报告单独维护模板，也不适合走“不断标注新报告、持续训练专用模型”的重路径。更高效的思路，是建立一条对医院版式变化有适应能力的文档结构化链路。

二、一条更适合医疗场景的技术路径

医疗报告解析更适合采用 “固定外层结构、灵活内层字段” 的方案：

[医疗文档]
    ↓
[版式感知 OCR]
  处理扫描件、拍照件、表格和段落
    ↓
[结构化理解层]
  识别报告类型与信息板块
    ↓
[字段抽取层]
  输出患者信息、报告信息、检查结果、诊断与治疗
    ↓
[证据回溯与人工复核]
    ↓
[问诊 / 理赔 / 导诊 / 归档系统]

这种方案的核心，不是追求一个“万能字段表”，而是先定义一套稳定的业务骨架，例如患者信息、报告信息、诊断、检查结果、治疗和随访建议。不同报告类型的细节字段，可以在这些骨架之下灵活展开。

这样做的好处很明显。前端展示不必为每一种报告重新设计，系统接入层也能获得更稳定的数据结构，而模型只需关注“这一类报告里真正有价值的信息是什么”。

三、如果希望快速落地，医疗报告工具至少要补足三层实现细节

医疗报告工具真正难做的部分，不是写出一个流程图，而是把 OCR、中间结构、字段抽取和证据回溯连成一条完整链路。要做到接近正式产品的能力，下面三层几乎缺一不可。

1. OCR 层必须面向扫描件和拍照件优化

医疗场景的 OCR 绝不能只做“识字”。它至少要负责：

• 倾斜校正
• 透视矫正
• 表格区域还原
• 标题和段落层级保留
• 页面图像与坐标同步返回 一个适合后续抽取的中间层结构可以是：

{
  "content_markdown": "...",
  "page_snapshots": [
    {
      "page_number": 1,
      "page_ref": "page_1",
      "page_size": { "width": 1240, "height": 1754 },
      "blocks": [
        { "text": "白细胞", "bbox": [132, 455, 210, 486] }
      ]
    }
  ]
}

其中，页级元数据可以理解成三样基础能力：

• page_ref：这一页的唯一引用，后续加载原图或做缓存时会用到
• page_size：这一页的原始尺寸，用来保证高亮坐标能准确叠加到页面预览上
• bbox：文本块在页面上的位置框，用于点击字段后回看原文

换句话说，这些字段不是为了“多返回一些技术细节”，而是为了让系统既能抽取结果，又能把结果定位回原始报告。

2. 抽取层建议采用“固定顶层骨架 + 动态字段内容”

医疗文档不适合做成死板的超长字段表，更适合围绕业务骨架组织结果。一个通用结构可以设计成：

{
  "report_type": "血常规检验报告",
  "patient_info": {},
  "report_info": {},
  "diagnosis": {},
  "examination": {},
  "treatment": {},
  "prognosis": {}
}

然后再根据不同文档类型，往各节中填充内容。这样做有三个直接收益：

• 前端不需要为每种报告重新设计结果页
• API 消费方可以稳定依赖顶层结构
• 新报告类型出现时，大多数情况下只需调整抽取策略，而不是推翻整套 schema

3. 表格型信息必须做成专项结构

检验指标和药物信息，是医疗报告里最容易漏项的部分。开发时最好单独设计数组结构：

{
  "examination": {
    "exam_items": [
      {
        "名称": "血红蛋白",
        "结果": "135",
        "单位": "g/L",
        "参考范围": "120-160",
        "状态": "正常"
      }
    ]
  },
  "treatment": {
    "medications": [
      {
        "药品名称": "阿莫西林",
        "用法用量": "0.5g",
        "给药途径": "口服"
      }
    ]
  }
}

如果没有这层专项设计，模型很容易把表格内容压缩成一段摘要，最终失去业务使用价值。

四、一个可直接复用的后端处理骨架

如果把逻辑抽象成服务编排，医疗报告的处理流程大致可以写成：

async function handleMedicalReport(file: File) {
  const ocr = await parseDocument(file);
  const extraction = await extractMedicalInfo(ocr.markdown, ocr.pages);

  return {
    parse_result: {
      markdown: ocr.markdown,
      pages: ocr.pages
    },
    extract_result: extraction.llm_json,
    raw_result: extraction.raw_json,
    page_meta: extraction.pages
  };
}

如果还希望进一步做成接近正式产品的体验，可以继续补两层：

• 页面图像异步加载与旋转修正
• 多种导出格式，例如解析 Markdown、解析 JSON 和抽取 JSON，方便定位问题究竟出在 OCR 层还是抽取层

五、为什么这类方案比持续标注模板更有价值？

医疗报告版式变化非常频繁。如果每新增一种样式，就重新标注、重新训练、重新维护模板，系统的长期成本会很快失控。

更合理的做法，是把适应能力建立在三个层面：

• 版式感知 OCR 负责还原文档结构，而不是只识别单行文本
• 结构化抽取层围绕业务语义组织结果，而不是围绕视觉位置写死字段
• 规则与证据层保证结果可校验、可回看、可进入人工复核流程

这套路线的价值，在于大多数新报告样式出现时，系统并不需要重新构建训练集，只需在抽取策略和规则层做有限调整。对于面向医院、保险和互联网医疗平台的方案来说，这是更现实的工业化路径。

六、一个可落地的业务工作流

1. 文档输入与预处理

系统接收 PDF、扫描件或手机拍照件，优先完成图像纠偏、透视矫正和结构还原。对医疗场景来说，这一步往往决定后续解析效果的上限。

2. 结构化提取

文档不再被当成普通文本处理，而是被映射为几个稳定的信息板块。对于检验报告，系统重点识别指标表格；对于病历和出院小结，则更关注诊断、治疗和医嘱段落。

3. 原文回溯与复核

一个面向实际业务的结果页，必须支持字段和原文之间的映射。用户点击指标、诊断或时间信息时，能够快速回看它在原始文档中的位置。

4. 进入业务系统

结构化结果可以直接送入问诊助手、理赔录入系统、智能导诊系统或医疗归档平台，减少人工二次整理成本。

七、工程实践建议：避免踩坑的五个关键点

1. 先解决输入质量，再追求抽取精度

对于医疗场景，拍照件和扫描件的可读性问题，往往比模型能力本身更关键。

2. 不要为每种报告设计一套完全不同的结果结构

更稳的做法，是固定业务骨架，让内层字段随报告类型变化。

3. 表格型信息要单独处理

检验指标、药物列表这类内容最容易漏行，开发时应作为独立结构处理，而不是混入普通段落字段。

4. 工具应聚焦“信息提取”，而不是越界做医疗判断

成熟方案的价值，在于整理文档和提供证据，而不是替代医疗决策。

5. 结果必须可追溯

在医疗和保险场景里，没有原文证据的结构化结果，很难真正进入审核流程。

八、医疗文档智能化的真正价值

医疗报告智能解析并不是把传统 OCR 换成一个更复杂的模型，而是在重构医疗数据进入业务系统的方式。系统先完成结构化整理，人工再基于结果做确认和判断，这种 “机器预处理 + 人工复核” 的组合，既能提升效率，也更容易满足真实业务对可靠性的要求。

从长远看，这类方案的意义不仅在于节省录入时间，更在于让医疗数据能够以更稳定的方式进入问诊、理赔和分析流程。只有文档先被正确理解，后续的智能服务才有真正落地的基础。

以上是一种“先骨架抽取，再细节展开”的医疗报告解析实践方案。核心思路是把低质量医疗文档（扫描件、拍照件、弯曲变形的报告）先通过版式感知OCR统一为保留表格、标题、段落与坐标信息的中间层，再将患者信息、报告信息、检查结果、诊断与治疗映射到多个语义板块，输出固定骨架的JSON，最终合并生成可追溯的结构化结果。方案已发布在GitHub，欢迎大家在项目中与我们交流。如果你在实际处理医疗报告时遇到更复杂的场景，或者有不同的架构思路，欢迎点击页面右侧加入技术交流群与我们探讨。