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

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

但这种自然的交流方式，在数字化病历系统中却可能遇到一个问题：医生能够听懂患者讲的粤语，不代表电子病历系统能够直接记录这些内容。

例如，一位患者在问诊时说：

呢排成日头晕，食完嘢仲有啲反胃。

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

患者自述近期反复头晕，进食后伴恶心感。

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

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

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

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

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

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

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

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

我冇胸痛，不过有时会觉得个心口翳住。

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

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

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

首先是方言声学识别。

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

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

其次是医学专业词汇。

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

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

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

最后是临床语义的保留。

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

例如：

• 患者说"冇发烧"，属于否认发热。
• 医生问"有冇胸痛"，只是询问是否存在胸痛。
• 患者说"好似有啲气促"，则包含不确定程度。

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

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

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

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

基本架构如下：

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

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

1. 音频预处理与 VAD

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

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

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

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

2. 粤语 ASR 识别

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

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

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

3. 医患角色区分

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

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

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

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

4. 临床信息结构化

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

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

{
  "speaker": "patient",
  "language": "yue",
  "original_text": "呢排成日头晕，食完嘢仲有啲反胃",
  "normalized_text": "近期反复头晕，进食后伴恶心感",
  "clinical_information": {
    "symptoms": ["头晕", "恶心感"],
    "trigger": "进食后出现恶心感",
    "duration": null,
    "diagnosis": null
  },
  "requires_review": true
}

这里有两个细节值得注意。

首先，系统保留了 original_text，使医生能够随时检查原始表达。

其次，患者没有明确提供症状持续天数，也没有给出诊断结果，因此 duration 和 diagnosis 不应由模型自行补全。

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

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

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

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

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

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

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

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

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

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

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

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

第一种：医院内网集中部署。

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

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

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

第二种：端侧离线部署。

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

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

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

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

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

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

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

因此，端侧离线的核心价值是减少对外部网络和远端推理服务的依赖，让语音识别过程在受控环境中完成，而不是简单地把"离线"等同于全部安全要求。

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

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

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

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

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

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

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

例如：

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

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

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

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

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

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

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

CER = (S + D + I) / N

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

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

假设一段问诊记录的大多数文字都被准确识别，但系统将"每日一次"错误识别为"每日三次"，那么仅从整体字符错误率来看，问题可能并不突出；从医疗安全角度看，这却是需要重点防范的错误。

因此，医疗语音识别应采用更有针对性的评测体系。

评测维度	具体关注内容
方言识别能力	粤语及普粤混说的 CER
医学术语识别	药品、疾病、检查项目和专业缩写
关键数字识别	剂量、时间、频次和检验数值
临床语义准确性	否定词、症状归属和不确定表达
医患角色区分	发言人识别与角色归属
端侧运行性能	延迟、内存占用、实时处理能力
病历草稿质量	临床要素完整性、错误添加率及医生修改量

尤其需要把 ASR 转写质量与病历生成质量分开评估。

例如，第一阶段检查系统是否正确识别患者原话；第二阶段检查规范化文本是否保留原始含义；第三阶段再检查生成的病历草稿是否遗漏关键信息，或添加患者并未提供的事实。

对于电子病历，医生审核确认仍然是不可省略的一步。

系统还应支持查看原始转写文本、回听对应音频以及修改结构化字段，以便医生快速核对模型输出。

六、从语音录入到病历辅助生成，真正改变的是什么？

过去，医生完成问诊以后，往往还需要将交流内容重新整理并输入电子病历。

在患者使用粤语的情况下，这个过程还包含从日常口语到医学书面语的转换。

如果语音识别能够在问诊过程中持续工作，就有机会把这部分重复劳动转移到系统后台。

患者仍然使用自己熟悉的语言描述症状，医生也不必为了适应软件而改变问诊方式。

系统负责采集对话、还原原话、区分发言人，并将可以确认的信息整理为病历草稿，最终由医生进行审核和补充。

但要实现这一流程，技术上的关键并不只是选择一个支持粤语的 ASR 模型。

还需要解决医疗术语识别、否定语义保留、医患角色区分、结构化字段准确性，以及端侧计算资源和数据安全等问题。

对于已经拥有成熟医疗信息系统的机构而言，采用独立语音模块、端侧离线推理或院内集中部署的方式，也为现有软件增加粤语能力提供了不同的技术路径。

医疗语音智能化真正的目标，不是让 AI 替医生写病历，而是让医生在保留临床判断和审核权的前提下，减少重复记录工作。

从这个角度来看，粤语 ASR 的价值并不局限于把一种方言转换成文字。

它更重要的作用，是让原本难以直接进入医疗信息系统的自然语言交流，成为能够被准确记录、核对和规范处理的临床信息。