医院查房记录：医生口述生成电子病历草稿

医院查房记录：医生口述生成电子病历草稿

在三甲医院的住院部走廊里，主治医师一边翻看病历夹，一边对着平板低声叙述：“4床李芳，女，72岁，术后第三天，体温37.1℃，切口无红肿……”话音未落，屏幕上已实时浮现结构清晰的文字。这不是科幻场景，而是某试点科室正在使用的语音驱动电子病历草稿系统。

这样的转变背后，是语音识别技术对传统医疗工作流的一次静默革命。过去，医生平均每天要花近两小时手动录入病历，占门诊时间的三分之一以上。笔误、遗漏、格式不统一等问题屡见不鲜。如今，借助像Fun-ASR这样的本地化语音识别方案，医生只需口述，系统即可自动生成标准化文本初稿——效率提升的同时，还避免了敏感数据上传云端的风险。

这不仅仅是“说话变文字”的简单过程，而是一套融合了声学建模、语义规整与临床适配的完整技术闭环。

从一段查房录音说起

设想一个典型的工作日早晨：心血管内科主任带领团队完成一轮病房巡查，共查看16名患者。传统流程下，每位患者的查房记录需单独整理，耗时约8分钟，总计超过两小时。若采用 Fun-ASR 系统，则整个过程被压缩至30分钟以内。

其核心逻辑并不复杂：
医生口述内容通过麦克风采集，经由 VAD（语音活动检测）模块自动切分有效语段，再送入 ASR 模型进行高精度转写，最后通过 ITN（逆文本规整）将口语表达转化为标准医学书写格式。例如，“血压幺六零九五”会被自动纠正为“血压160/95mmHg”，“吃了拜新同”转为“服用硝苯地平控释片”。

整个链条中，最关键的不是单一技术点的突破，而是如何让大模型真正理解临床语言的节奏与语境。

Fun-ASR 是什么？它为何适合医疗场景？

Fun-ASR 并非通用语音 API 的复刻品，而是钉钉联合通义实验室专为中文优化的大规模语音识别系统。它的轻量化版本 Fun-ASR-Nano-2512 可在仅4GB显存的消费级 GPU 上运行，这意味着医院无需采购昂贵硬件即可部署。

这套系统的架构采用端到端深度学习框架，主要包括五个阶段：

1. 音频预处理：输入音频统一重采样至16kHz，使用短时傅里叶变换提取 Mel 频谱图；
2. 声学建模：基于 Conformer 结构的神经网络对每一帧进行音素预测；
3. 语言融合：引入上下文感知的语言模型，增强句子连贯性；
4. 文本后处理：启用 ITN 模块，将数字、单位、缩略语等规范化；
5. 输出结构化结果：支持 JSON 或 CSV 格式导出，便于对接 HIS 系统。

相比百度、讯飞等云服务，Fun-ASR 最大的优势在于完全本地化运行。所有音频数据不出内网，从根本上杜绝了患者隐私泄露风险。同时，由于无需依赖公网连接，响应延迟稳定在毫秒级，特别适合查房过程中频繁启停的使用模式。

更重要的是，它允许深度定制。比如可以注入“热词表”，强制模型优先识别“胺碘酮”“心电图ST段抬高”这类专业术语，显著降低误识率。有测试显示，在加入200个高频医学词汇后，相关术语识别准确率从83%提升至96%以上。

对于等级保护要求严格的医疗机构而言，这种“私有化+可控性”的组合几乎是唯一可行的选择。

VAD 如何让长录音变得聪明？

查房录音往往长达几十分钟，包含大量翻页声、脚步声和医患交流间隙。如果直接把整段音频扔给 ASR 模型，不仅计算资源浪费严重，还会因上下文过长导致识别混乱。

这时，VAD（Voice Activity Detection）就扮演了“智能剪辑师”的角色。

Fun-ASR 使用的是基于 FSMN 的小型神经网络 VAD 模型，它不仅能根据能量阈值判断是否有声音，还能区分人声与环境噪声。其工作流程如下：

1. 将音频按10ms帧长切分；
2. 提取每帧的能量、过零率及梅尔特征；
3. 输入训练好的分类器，输出“语音/非语音”标签；
4. 聚合连续语音帧为“语音段”，并设定最大单段时长（默认30秒）；
5. 输出带时间戳的语音片段列表，供后续分段识别。

这个机制解决了几个关键问题：

• 防内存溢出：避免一次性加载超长音频；
• 降噪提效：跳过静音段，减少无效推理；
• 精准定位：便于后期回溯某位患者的查房内容。

实际应用中，我们曾遇到一位医生在查房时习惯性停顿思考，导致 VAD 错误切割句子。后来通过调整vad_config.yaml中的“静音容忍时间”参数（从500ms延长至1200ms），成功合并了原本被拆分的语义单元。

from funasr import AutoModel # 初始化VAD模型 vad_model = AutoModel(model="speech_fsmn_vad_zh-cn-16k-common-pytorch") # 执行VAD检测 res = vad_model.generate(input="ward_round_20250405.mp3", max_single_segment_time=30000) # 输出示例 for i, seg in enumerate(res[0]["value"]): print(f"片段{i+1}: {seg['start']}ms → {seg['end']}ms, 文本: {seg['text']}")

这段代码展示了如何用 SDK 快速实现语音段检测。值得注意的是，max_single_segment_time=30000参数是为了防止个别语句过长引发模型崩溃——毕竟没人希望一句“患者有高血压糖尿病冠心病脑梗死后遗症”卡住整个系统。

实时识别：准流式的智慧妥协

严格意义上的“流式识别”要求模型支持在线解码，即边输入音频边输出文字。但大多数高性能 ASR 模型（包括 Paraformer）为追求准确率牺牲了这一能力。

Fun-ASR 的应对策略很务实：用 VAD 分段 + 快速识别模拟实时体验。

具体做法是在前端浏览器中利用 Web Audio API 获取麦克风流，每隔2秒截取一次音频缓冲区，并立即触发识别请求。虽然 technically 不是真正的流式，但在用户感知上几乎无差别——从说话到出字延迟控制在1~2秒之间。

navigator.mediaDevices.getUserMedia({ audio: true }) .then(stream => { const mediaRecorder = new MediaRecorder(stream); const chunks = []; mediaRecorder.ondataavailable = event => { chunks.push(event.data); sendAudioChunkToServer(new Blob(chunks, { type: 'audio/webm' })); }; mediaRecorder.start(2000); // 每2秒发送一次 });

这段 JavaScript 实现了定时采集与上传。选择.webm格式是因为它压缩率高且兼容性强。服务端接收到每个片段后，立即调用 ASR 模型并返回结果，前端则负责拼接成连续文本流。

当然，这种方式也有局限。长时间运行可能导致内存累积增长，尤其当医生连续讲述超过10分钟时。因此建议将其用于单条医嘱记录或短时口述，而非全程录音。更稳妥的做法是结合“手动开始/结束”按钮，由医生自主控制录制边界。

批量处理：解放重复劳动的利器

查房结束后，助理常常面临一项枯燥任务：逐一打开十几个录音文件，逐个转写、命名、归档。Fun-ASR 的批量处理功能正是为此设计。

系统采用任务队列机制，支持拖拽上传多个文件（如.wav,.mp3），后台按顺序异步执行识别，并实时反馈进度条。全部完成后可一键导出为 CSV 或 JSON 文件，字段包含原始文件名、识别文本、时间戳等信息。

import os from funasr import AutoModel asr_model = AutoModel(model="paraformer_realtime") # 复用实例节省内存 results = [] audio_files = sorted(os.listdir("input_dir")) for file in audio_files: if file.endswith((".wav", ".mp3")): result = asr_model.generate(input=f"input_dir/{file}", hotwords="主诉 查体 处置建议 医嘱") results.append({ "filename": file, "text": result[0]["text"], "timestamp": get_current_time() }) # 导出CSV import pandas as pd df = pd.DataFrame(results) df.to_csv("round_notes_20250405.csv", index=False)

脚本中的hotwords参数尤为关键。加入“查体”“处置建议”等结构化关键词后，模型更容易捕捉病历书写的固定句式，比如自动补全“查体：神清，精神可”这类模板化表达。

此外，共享同一个AutoModel实例能极大降低 GPU 显存占用——否则每处理一个文件都重新加载模型，极易导致 OOM（内存溢出）。这也是批量处理必须遵循的最佳实践。

系统落地：不只是技术，更是流程再造

Fun-ASR WebUI 在医院的实际部署并非简单的软件安装，而是一次跨部门协作的微流程重构。典型的系统架构如下：

[医生口述] ↓（麦克风录音 / 文件上传） [Web 浏览器] ←→ [Fun-ASR WebUI Server] ↓ [VAD + ASR 模型推理] ↓ [识别结果 + ITN 规整] ↓ [历史数据库 history.db 存储] ↓ [导出为病历草稿供编辑]

服务器部署于医院内网，医生通过任意终端访问http://ip:7860即可使用，无需联网。所有识别记录自动存入 SQLite 数据库，支持按日期、关键词搜索，形成可追溯的知识资产。

但在推广初期，我们也遇到了现实阻力。有的医生担心语音识别不准反而增加修改负担；有的护士质疑谁来负责校对；信息科则关注系统稳定性与维护成本。

为此，项目组采取了“小步快跑”策略：

• 先在心内科试点两周，收集真实查房录音做模型调优；
• 引入“双栏对比界面”：左侧显示原文，右侧展示识别结果，方便快速核对；
• 设置账号权限体系，确保只有授权人员可访问；
• 推荐使用指向性麦克风，实测信噪比提升12dB以上；
• 制定每周备份history.db的运维规范，防止单点故障。

最终数据显示，医生平均每人每天节省1.5小时文书时间，病历完整率从82%提升至98%。更重要的是，系统留下的每一次修改痕迹，都成为医疗质量管控的宝贵依据。

未来不止于“转写”

当前的 Fun-ASR 解决的是“语音→文本”的第一步。但真正的智能化，应该是“语音→结构化病历”。

设想这样一个场景：医生说：“3床张伟，男，68岁，主诉胸闷三天，既往高血压十年。”
系统不仅能转写，还能自动填充 EMR 表单：
- 姓名：张伟
- 性别：男
- 年龄：68
- 主诉：胸闷3天
- 既往史：高血压病史10年

这需要结合 NLP 实体识别与医疗知识图谱。好消息是，Fun-ASR 已预留接口，可通过插件形式接入下游分析模块。已有研究团队尝试将其输出连接至 CMeKG（中文医学知识图谱），初步实现症状与诊断建议的关联推荐。

或许不久的将来，这套系统不仅能帮医生写病历，还能提醒：“该患者符合急性冠脉综合征筛查指征，建议查肌钙蛋白。”

今天，它只是一个语音转文字工具；明天，它可能是嵌入临床决策链的 AI 助理。而这一切的起点，不过是医生在病房里轻轻说出的第一句话。