在广东地区的医院和社区卫生服务中心，医生使用粤语与患者交流并不少见。尤其是面对习惯使用粤语的中老年患者，采用熟悉的语言询问症状、既往病史和用药情况，往往更有利于患者准确表达自身感受。

但这种自然的交流方式，在数字化病历系统中却可能遇到一个问题：

医生能够听懂患者讲的粤语，不代表电子病历系统能够直接记录这些内容。

医生可以很自然地理解这句话，但如果需要写入电子病历，通常需要转换为更加规范的表达：

这个过程看起来只是把粤语转换成普通话书面语，实际上却涉及语音识别、方言理解、临床信息提取以及文本规范化等多个技术环节。

随着 ASR（Automatic Speech Recognition，自动语音识别）和大语言模型的发展，利用语音技术辅助生成电子病历，已经开始进入实际医疗场景。

例如，深圳福田区部分社区卫生服务机构已经部署了基于医患对话的病历辅助生成系统，通过自然语言处理提取临床要素，并结合结构化模板生成病历草稿。

但对于粤语使用频繁的医疗场景而言，如何让系统准确处理方言表达，以及如何在保护患者信息的前提下部署语音能力，仍然是值得关注的工程问题。

一、粤语医疗 ASR，难点不只是识别方言

与普通会议转写相比，医疗语音识别的容错空间更小。

在一般会议中，某个词语出现识别错误，参会人员往往还能够根据上下文推断意思。但医疗问诊涉及症状、药物、剂量、时间和否定表达，一处看似细微的错误，就可能改变整句话的含义。

例如，粤语患者可能这样描述：

如果系统能够准确转写原话，医生就可以结合问诊上下文继续判断。

但如果 ASR 错误识别了“冇”这个否定词，或者直接把“心口翳住”解释成某一种明确疾病，就可能造成不正确的信息记录。

因此，粤语医疗 ASR 至少面临三个不同层次的技术问题。

粤语在声调、音系和日常用词上与普通话存在差异。普通话 ASR 即使在标准普通话语料上具有较高准确率，也不能直接保证粤语识别效果。

尤其是在老年患者、语速较快、发音不清晰或诊室存在背景噪声的情况下，模型还需要处理更加复杂的声学输入。

实际问诊中，患者可能使用粤语描述症状，医生则使用普通话医学术语，甚至夹杂英语缩写。

例如 ECG、CT、MRI，以及具体药物名称和检验项目。

这种混合语言环境要求 ASR 不仅能够识别日常粤语，还要准确保留医学术语、药名和检查名称。

语音识别系统需要区分患者已经出现的症状、医生提出的疑问，以及患者明确否认的症状。

这几种表达不能在病历结构化过程中被简单地统一为肯定的症状记录。

因此，医疗语音识别不仅需要关注字符错误率（CER），还需要针对否定词、时间、剂量和临床关键字段开展专项评测。

二、从粤语录音到电子病历，需要怎样的技术链路？

一个完整的粤语问诊辅助记录系统，可以拆分为音频处理、语音识别、角色区分、临床信息提取和病历生成几个模块。

诊室麦克风 / 医疗终端
          │
          ▼
    音频采集与预处理
          │
          ▼
      VAD 语音检测
          │
          ▼
      粤语 ASR 模型
          │
          ▼
    医患角色区分与时间戳
          │
          ▼
      口语文本规范化
          │
          ▼
    临床信息结构化提取
          │
          ▼
      电子病历草稿生成
          │
          ▼
       医生审核确认
          │
          ▼
       HIS / EMR 系统

其中每个模块都有不同的任务。

诊室环境中可能存在设备提示音、人员走动、其他患者交谈等背景噪声。

音频首先需要完成采集、格式转换和必要的降噪处理，再通过 VAD（Voice Activity Detection）识别有效语音片段。

例如，本地语音服务可以使用 16kHz、16-bit PCM 音频作为模型输入格式，但具体采样率仍应根据拾音设备和 ASR 模型要求确定。

VAD 需要在识别延迟和上下文完整性之间取得平衡。过短的切分窗口可能打断一句完整的症状描述，过长的静音等待则会影响实时转写体验。

ASR 负责把患者和医生的语音转换成文字。

对于实时问诊，可以使用流式识别架构，持续接收音频数据并输出临时识别结果。当一段话结束后，再输出稳定的最终文本。

业务系统应区分临时字幕和最终识别结果，避免将尚未稳定的文本直接写入电子病历。

医疗问诊不仅需要知道说了什么，还需要确定是谁说的。

如果诊室使用独立麦克风，可以利用音频通道辅助判断医生与患者的身份。如果只有一路混合音频，则可能需要 Speaker Diarization（说话人区分）技术。

不过，说话人区分通常只能识别不同的发言来源，并不能天然知道谁是医生、谁是患者。实际系统还需要结合麦克风绑定、人工确认或业务规则完成角色映射。

这一步非常重要，因为不能把医生提出的疑问，错误记录成患者已经存在的症状。

当系统获得带有时间戳和角色信息的转写文本后，就可以通过规则引擎、医学术语词典和大语言模型进一步提取信息。

例如，一段模拟问诊结果可以整理为：

，使医生能够随时检查原始表达。

其次，患者没有明确提供症状持续天数，也没有给出诊断结果，因此 

大模型的主要职责是整理已表达的临床信息，而不是根据不完整的对话自行推断诊断。

在生成病历草稿时，还应保留关键字段与原始音频片段的对应关系，方便医生核对。

三、为什么医疗语音识别适合考虑端侧离线部署？

目前，许多语音识别服务采用云端 API 架构。

客户端采集音频后，将数据上传到云端推理服务器，等待识别结果返回。

这种方式便于集中管理算力资源，应用开发也相对简单。

但在医疗场景中，数据传输路径往往需要经过更严格的审查。

医患对话可能包含姓名、年龄、联系方式、既往病史、用药记录以及其他敏感健康信息。

2025 年，国家卫生健康委等部门发布的《关于进一步加强医疗机构电子病历信息使用管理的通知》，明确要求医疗机构保护患者隐私，实行分级访问控制，并确保电子病历信息使用全过程可追溯。

因此，医疗语音系统除了关注识别效果，还需要考虑数据在什么位置处理、由谁访问，以及是否需要依赖外部网络。

一种可行的方案是将 ASR 模型部署在本地。

根据计算资源和业务规模，可以采用两种不同架构。

诊室终端
    │
    ▼
医院内部网络
    │
    ▼
院内 ASR 推理服务器
    │
    ▼
结构化文本
    │
    ▼
院内电子病历系统

这种方式适合多诊室统一使用语音识别服务。

医院可以集中配置推理服务器、模型版本和业务接口，终端不必承担完整的模型推理负载。

诊室工作站 / 医疗终端
          │
          ▼
     本地音频采集
          │
          ▼
     本地粤语 ASR
          │
          ▼
     本地转写结果
          │
          ▼
   医疗软件 / 病历编辑器

这种方式将识别过程放在设备内部完成，不需要把音频上传到外部语音服务。

对独立诊室、专用医疗设备以及需要减少网络依赖的场景而言，端侧处理具有一定优势。

但端侧部署也会带来新的工程约束。

例如，ASR 模型需要适应终端的 CPU、GPU 或 NPU 性能，以及可用内存和存储空间。

如果终端算力有限，就可能需要采用模型量化、推理加速或者更轻量的模型架构。

同时，端侧离线并不意味着所有数据安全问题都已经解决。设备本身仍然需要访问权限控制、必要的数据加密、日志审计和安全更新机制。

减少对外部网络和远端推理服务的依赖，让语音识别过程在受控环境中完成

，而不是简单地把“离线”等同于全部安全要求。

四、粤语 ASR 可以作为独立能力接入医疗软件

对于已经建设 HIS（医院信息系统）、EMR（电子病历系统）以及诊室工作站的医疗机构而言，增加粤语语音识别能力，并不意味着需要重新采购一套完整的问诊软件。

从软件架构角度看，ASR 完全可以作为底层能力模块，由现有业务系统按需调用。

例如，医疗软件厂商可以在原有病历编辑界面中增加语音录入功能，医生点击开始记录后，系统调用本地语音服务完成识别，再将结构化文本返回现有界面。

在这种模式下，语音识别模块不负责患者挂号、处方管理和病历存档等业务流程，只提供音频到文本的转换能力。

目前，熙瑾信息的语音识别技术已经应用于熙瑾会悟等产品，同时具备端侧、离线部署及独立模块集成的应用形态。其语音能力经过 CNAS 认可实验室检测，支持包括广东粤语在内的多达 25 种方言，产品也取得了银河麒麟、统信软件的兼容性互认证明。

在医疗软件的技术架构中，这类 ASR 能力可以承担底层粤语语音转写任务，再由上层医学文本处理模块完成临床要素提取、病历结构化和业务系统对接。

现有医疗软件
      │
      ▼
本地 ASR 服务接口
      │
      ▼
粤语 / 普通话语音识别
      │
      ▼
文本 + 时间戳 + 说话人信息
      │
      ▼
医学信息提取模块
      │
      ▼
电子病历草稿
      │
      ▼
医生审核后保存

采用这种方式，原有医疗软件的账户、权限、业务流程和数据库结构可以尽量保留，新增的语音能力主要通过接口与既有系统对接。

对于医疗设备厂商来说，也可以根据终端硬件配置，选择在设备本地运行 ASR，或者调用医院内网中的集中推理服务。

需要注意的是，支持粤语与通过方言能力检测，并不直接等于已经完成医疗专业术语识别和临床场景验证。部署到医疗业务之前，仍然需要针对实际科室、目标设备和病历工作流程开展专项测试。

五、医疗场景的语音识别，应该怎样评价效果？

医疗 ASR 的评测不能完全照搬普通语音转写。

对于常规语音识别，CER（Character Error Rate，字错误率）是常见指标：

其中 S 表示替换错误数，D 表示删除错误数，I 表示插入错误数，N 表示参考文本的字符数量。

但在医疗场景中，即使整体 CER 较低，也不能保证关键临床信息完全正确。

粤语医患对话如何转成电子病历？从方言 ASR 到端侧离线语音处理

人工智能

音视频

架构设计

广东医疗场景中粤语电子病历自动生成面临技术挑战。针对医院及社区机构，需构建包含粤语ASR、医患角色区分、否定语义识别和临床信息结构化的完整链路。重点解决方言声学差异、普粤医学术语混用及敏感数据保护问题，支持端侧离线部署。系统应区分ASR转写质量与病历草稿质量，保留原始语音对应关系，供医生审核确认。

自然语言处理

语音识别

数据安全

数据加密

软件架构

日志审计

数据库

服务器

语音产品特惠新用户14.9元起


让每一个 Agent，都跑在云上

4核4G3M云服务器 新用户低至38元/年！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

粤语医患对话如何转成电子病历？从方言 ASR 到端侧离线语音处理

粤语医患对话如何转成电子病历？从方言 ASR 到端侧离线语音处理

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐