MDT 会诊前，技术团队经常要面对一个很具体的问题：病历、检查结果、用药记录、会诊申请、既往记录散落在多个系统里，人工整理一份可读的会前摘要很耗时。本文只讨论技术架构和工程流程示例，不提供诊断、治疗、分诊或用药建议；所有规则均为示例，真实项目必须由医疗专业人员和机构规范确认。

问题背景：MDT 会前整理为什么适合 Agent 介入

MDT 的会前准备不是简单“摘要生成”。它更像一个多源信息对齐任务：先找到患者相关资料，再按时间线归并事件，最后把关键问题、待确认信息和原始出处一起交给人工复核。

传统脚本可以做抽取，但面对数据缺失、字段命名不一致、同一事件多处出现等情况，维护成本会上升。Agent 的价值不在于“替代会诊”，而是把会前资料整理拆成多个可控步骤：检索、去重、时间排序、摘要、质控提示，每一步都有输入输出和审计日志。

一个可落地的目标是：把 30 到 60 分钟的人工资料预整理，压缩成 5 到 10 分钟的人工复核。这里的时间只是工程优化目标，不代表医疗质量结论。

技术目标与边界

本文示例系统包含四个目标：

• 聚合多源文本数据：病程记录、检查报告文本、医嘱记录、会诊申请。
• 抽取标准化事件：时间、事件类型、摘要、来源 ID。
• 构建患者级时间线：支持按时间查询、按主题回溯。
• 生成 MDT 会前摘要：输出“已知信息、待确认问题、引用来源”。

边界也要写清楚：

• 不做自动诊断结论。
• 不输出治疗方案推荐。
• 不把示例风险规则当成行业标准。
• 不绕过人工复核和机构审批流程。

方案概览：把 Agent 拆成 5 个可审计节点

一个比较稳妥的结构是“工作流式 Agent”，而不是让一个大模型一次性读完所有资料后直接给结论。

推荐的技术栈如下：

• FastAPI：对外提供患者资料整理任务接口。
• 图数据库：保存患者、事件、来源文档之间的关系。
• 向量库：支持从原始文本中召回相关片段。
• LLM API：用于结构化抽取和摘要生成。
• 任务队列：异步执行长任务，避免接口阻塞。

这里的关键设计是：LLM 只负责“生成候选结构化结果”，系统负责校验、落库、溯源和人工确认。

数据模型：先设计可追溯事件，而不是先写 Prompt

MDT 会前摘要最怕“看起来通顺，但找不到出处”。因此事件表必须保存来源信息。

一个简化事件模型可以这样设计：

from pydantic import BaseModel, Field
from typing import Literal, Optional

class ClinicalEvent(BaseModel):
    patient_id: str
    event_time: str = Field(description="事件时间，ISO格式或原始时间文本")
    event_type: Literal["record", "exam", "order", "consult_request", "note"]
    summary: str = Field(description="事件摘要，只描述原文中可支持的信息")
    source_id: str
    source_text: str
    confidence: float = Field(ge=0, le=1)
    need_review: bool = True
    review_reason: Optional[str] = None

注意两个字段：source_text 和 need_review。前者用于追溯，后者用于把不确定内容推给人工确认。真实系统中还应增加操作者、版本号、更新时间、机构内权限字段。

核心实现：FastAPI 触发整理任务

下面是一段最小化示例，演示如何接收患者资料、调用抽取逻辑并返回时间线。为了便于阅读，示例中用函数模拟 LLM API 和向量库，生产环境应替换成可靠服务，并加入鉴权、审计和限流。

from fastapi import FastAPI
from pydantic import BaseModel
from typing import List
import re

app = FastAPI()

class SourceDoc(BaseModel):
    patient_id: str
    source_id: str
    source_type: str
    text: str

def mock_extract_events(doc: SourceDoc) -> List[dict]:
    # 示例规则：从文本中抓取日期，真实项目应按机构数据规范确认
    dates = re.findall(r"\d{4}-\d{2}-\d{2}", doc.text)
    event_time = dates[0] if dates else "unknown"

    review_reason = None
    if event_time == "unknown":
        review_reason = "未识别到明确日期，需人工确认"

    return [{
        "patient_id": doc.patient_id,
        "event_time": event_time,
        "event_type": doc.source_type,
        "summary": doc.text[:120],
        "source_id": doc.source_id,
        "source_text": doc.text,
        "confidence": 0.65 if review_reason else 0.85,
        "need_review": True,
        "review_reason": review_reason
    }]

@app.post("/mdt/prepare")
def prepare_mdt(docs: List[SourceDoc]):
    events = []
    for doc in docs:
        events.extend(mock_extract_events(doc))

    events.sort(key=lambda x: x["event_time"])
    summary = {
        "known_information": [e["summary"] for e in events],
        "timeline": events,
        "review_items": [
            {
                "source_id": e["source_id"],
                "reason": e["review_reason"] or "会前人工复核"
            }
            for e in events if e["need_review"]
        ]
    }
    return summary

测试请求可以这样组织：

curl -X POST http://127.0.0.1:8000/mdt/prepare \
  -H "Content-Type: application/json" \
  -d '[
    {
      "patient_id": "P001",
      "source_id": "DOC001",
      "source_type": "record",
      "text": "2026-05-20 患者提交会诊申请，主诉与既往记录待核对。"
    },
    {
      "patient_id": "P001",
      "source_id": "DOC002",
      "source_type": "exam",
      "text": "2026-05-22 检查结果已回传，需结合原始报告由专业人员确认。"
    }
  ]'

这段代码没有追求“智能”，但它明确了工程骨架：输入可控、输出结构化、结果可审计。

图数据库如何存时间线关系

如果只用关系表，按时间查询没问题；但 MDT 会前常见需求是“某条摘要来自哪些原文”“某个待确认问题关联哪些事件”。图数据库更适合表达这类关系。

示例 Cypher：

MERGE (p:Patient {id: $patient_id})
MERGE (d:Document {id: $source_id})
CREATE (e:Event {
  time: $event_time,
  type: $event_type,
  summary: $summary,
  confidence: $confidence,
  need_review: $need_review
})
MERGE (p)-[:HAS_EVENT]->(e)
MERGE (e)-[:FROM_SOURCE]->(d);

后续摘要 Agent 可以先从图数据库取患者时间线，再从向量库召回相关原文片段，最后生成带引用的会前摘要。这样比直接把所有文本塞进上下文更容易控成本，也更容易定位错误来源。

摘要生成：Prompt 要限制输出职责

MDT 会前摘要 Prompt 不应该要求模型“给出处理意见”，而应要求它“整理资料并标注不确定点”。

示例约束：

你是会前资料整理助手，只能基于输入材料生成结构化摘要。
禁止给出诊断、治疗、分诊或用药建议。
每条摘要必须引用 source_id。
如果资料不足，请输出待确认问题。
风险提示规则仅为示例，真实规则需由机构确认。

输出建议固定为 JSON，便于前端渲染和人工复核：

{
  "brief": "会前资料整理摘要",
  "timeline_highlights": [],
  "open_questions": [],
  "source_refs": []
}

优化点：减少耗时和 Token 成本

会前整理任务的瓶颈通常不是 FastAPI，而是 LLM 调用和长文本处理。可以从三处优化：

• 先切分再召回：不要把全部病历文本一次性传给模型。
• 事件级缓存：同一 source_id 内容未变化时复用抽取结果。
• 分层摘要：先生成单文档摘要，再生成患者级摘要。

我在类似原型中会把 source_id + content_hash + prompt_version 作为缓存 key。只要原文和 Prompt 版本不变，就不重复调用 LLM。这样做的收益取决于数据重复率，不能泛化声称固定提升比例，但对多次会前修订场景通常很有效。

踩坑与安全注意事项

第一，脱敏要前置。进入向量库和日志系统前，应按机构要求处理可识别信息，并控制访问权限。

第二，摘要必须带出处。没有 source_id 的句子不应进入正式会前材料，只能作为待复核草稿。

第三，示例规则不要硬编码成医疗规则。例如“缺少某字段则升级提醒”只能作为工程提示，真实升级规则需由专业人员和制度确认。

第四，保留人工确认状态。每个事件都应有 pending、accepted、rejected、edited 等状态，避免 AI 草稿和人工确认结果混在一起。

总结

Agent 可以承担 MDT 会诊前的信息整理工作，但更准确的定位是“资料预处理与摘要草稿生成器”，不是医疗决策系统。工程实现上，应把流程拆成数据接入、结构化抽取、时间线构建、检索增强摘要和人工复核几个节点，并保证每条信息可追溯。

如果要继续扩展，可以优先做三件事：接入真实权限体系、完善事件审核工作台、建立摘要质量评估集。只有把可审计、可复核、可配置做好，Agent 才能在 MDT 会前准备中稳定降低整理成本。

本文文献检索、文献挖掘以及文献翻译采用的是【超能文献| AI文献检索|AI文档翻译】。