通过语音 AI + 本体，如何真正重构口腔电子病历？（方案干货收藏）

【一线数智资讯】前面两篇文章我们讨论了为什么大模型时代需要本体，大模型时代，本体为什么突然重要了？也讨论了如何从医学指南出发，构建口腔临床本体，以及如何对这套知识体系进行持续维护医学临床本体怎么建？从医学指南到企业级AI知识体系（以口腔为例）。

　　接下来，一个更实际的问题摆在面前：当我们已经有了口腔临床本体，又有了能够理解自然语言的大模型，能不能让医生在看诊过程中，通过自然语言完成大部分电子病历的书写？

　　如果可以，究竟应该怎么设计系统？医生需要如何使用？生成的病历是否足够准确？最终又如何证明它真正提高了工作效率和病历质量？

　　这些问题决定了一个 AI 项目能否从技术演示走向临床应用。

　　我的看法是，语音 AI 与本体的结合，真正要改变的不是病历的输入方式，而是病历的生产方式。

　　我们需要的不只是一个能够听懂医生说话、自动生成文字的助手，而是一个能够理解临床语义、组织诊疗信息、检查记录完整性，并在医生确认后生成结构化电子病历的临床辅助系统。

　　一、为什么有了语音识别和大模型，电子病历仍然不好写？

　　我们先看医生每天都在做什么。

　　患者进入诊室后，医生需要询问病史、了解主诉、进行检查、判断病情、形成诊断、制定治疗方案，并记录相应的诊疗过程。

　　与此同时，医生还要操作电子病历系统，选择牙位、填写检查结果、选择诊断、录入治疗内容，最后完成病历审核和签署。

　　对于医生而言，临床判断才是核心工作。但在很多信息化系统中，医生仍然需要花费相当多的时间，把已经理解的临床信息转换成系统要求的字段、选项和文档。

　　这中间存在一个明显的矛盾：

　　医生是按照临床思维开展工作的，电子病历却往往要求医生按照数据字段和表单结构完成记录。

　　语音 AI 的出现，首先解决了输入方式的问题。

　　医生可以通过自然语言描述患者情况，系统将语音转成文字，甚至直接生成一份看起来比较完整的病历。

　　但如果只做到这一步，实际上只是把原来的键盘输入换成了语音输入。因为病历不仅是一段文字。

　　在口腔临床中，病历涉及患者主诉、现病史、牙位、检查结果、诊断、治疗计划和实际操作等信息。这些信息之间存在明确的临床关系，也有不同的记录要求。

　　例如，医生说了一句：“右下后牙冷热刺激痛，叩诊有不适，建议进一步检查。”系统需要理解的，不仅是这句话的文字内容，还包括：

　　疼痛发生在哪个部位，牙位是否已经明确？

　　冷热刺激痛属于患者主诉、症状描述，还是某项检查的结果？

　　叩诊不适是针对哪颗牙记录的？

　　医生已经作出了诊断，还是仍处于检查和鉴别阶段？

　　“建议进一步检查”属于当前的诊疗计划，还是已经执行的检查？

　　如果系统只是把这些内容组织成一段流畅的文字，就可能出现信息归类错误、牙位关联错误，甚至把尚未确认的诊断写成确定结论的问题。

　　因此，真正的临床语音 AI，不能只关注语音识别准确率，也不能只关注生成的病历读起来是否通顺。它还需要理解临床信息的含义，以及这些信息应该以什么结构进入病历。这正是语音 AI 与口腔临床本体需要结合的原因。

　　二、语音 AI 与本体，究竟如何分工？

　　要把这套系统设计清楚，首先需要明确不同技术各自承担什么责任。我们可以把它归纳为四个部分：

　　1. 语音识别：准确记录医生说了什么

　　语音识别负责将医生的语音转换为文本。

　　口腔临床有大量专业术语，也可能存在相近的疾病名称、药物名称、牙位表达和检查术语，因此需要针对真实诊疗环境进行适配。

　　系统还需要考虑诊室中的环境噪声、医生的语速、口音，以及医生在描述病情时经常使用的口语表达。

　　但必须注意，语音识别的结果只是对声音内容的转写，并不代表系统已经正确理解了临床含义。

　　2. 大模型：理解语义，提取临床信息

　　在获得语音文本后，大模型负责理解医生表达的内容，并提取其中的临床信息。例如，从一段医患交互语音描述中识别主诉、现病史、症状、检查结果、诊断意见和治疗计划。

　　大模型还需要识别信息的不确定性。如果医生说“考虑根尖周炎”，系统就不应该擅自将其改成确定诊断；如果医生没有明确说出具体牙位，也不应该仅凭上下文猜测后直接写入正式病历。必要时，系统应该保留原始表达，或者向医生提出澄清问题。

　　3. 本体：提供统一的临床语义框架

　　本体负责明确口腔临床中有哪些核心概念，以及它们之间有什么关系。例如，牙位与检查结果之间的关联，症状与诊断之间的关系，诊断与治疗计划和治疗方案之间的关系，以及不同临床信息应该如何组织。

　　有了这套本体的语义框架，大模型从语音中提取出的内容就不再只是一些孤立的文字片段，而是可以映射到统一的临床概念体系中。同时本体还可以帮助系统识别概念歧义、关联并识别一些不完整和结构不一致的问题。

　　但这里需要明确：本体不是一个能够自动判断所有医学问题的智能医生。它提供的是概念、关系和之间的约束等，不能单独证明某项诊断正确，也不能替代医生的临床判断。

　　4. 规则与校验引擎：检查病历是否符合要求

　　当临床信息被提取并映射到本体后，系统还需要检查这些信息是否符合明确的记录要求。例如：

　　必填信息是否缺失？

　　检查结果是否关联了正确的牙位？

　　基于诊断必须做的检查是否有遗漏？

　　诊断是否存在尚未解决的歧义？

　　治疗计划是否与医生实际表达的内容一致？

　　病历中是否存在明显的前后矛盾？

　　其中，能够明确表达的完整性要求和业务规则，可以交给规则引擎执行；涉及复杂语义的情况，可以由大模型辅助识别，在工程落地时对于识别到的问题包括缺失内容，可以给出提示，再由医生确认。

　　经过这四部分共同构成了临床语音病历的核心链路：

　　语音识别负责听清楚，大模型负责理解，本体负责统一语义，规则引擎负责执行明确的校验要求，医生负责临床判断与最终确认。到此这才是一个相对完整的设计。

　　三、真正重要的不是自动生成病历，而是重新设计医生的工作流程

　　技术架构解决的是系统如何工作，临床流程决定的却是医生是否愿意使用。

　　如果 AI 虽然能够生成病历，但医生还需要反复切换页面、手动关联牙位、重新选择诊断、修改大量错误信息，那么系统的价值就会大打折扣。

　　因此，设计这类产品时，不能简单地把语音输入框放进原来的电子病历界面，而应该重新审视医生从接诊到完成病历的全过程。建议按照以下流程设计：

　　第一步：接诊前，系统准备好患者的基础信息

　　医生进入患者诊疗界面后，系统加载已经存在的患者基础资料、既往病历和相关检查信息。

　　这些信息应当来自经过授权的业务系统（比如影像结果、就诊登记表等），并且能够明确区分历史记录与本次就诊信息。

　　大模型可以利用这些上下文辅助理解医生后续的表达，但不能把历史病情自动当作本次已经确认的事实。

　　例如，患者过去的档案曾经记录过某颗牙的问题，并不意味着本次就诊仍然存在相同症状。系统必须保留信息来源和时间，避免把不同就诊过程中的信息混在一起。

　　第二步：诊疗过程中，医生自然表达，AI 实时组织信息

　　医生可以按照自然的诊疗节奏询问患者、描述检查结果。系统将语音转为文字，提取临床信息，并逐步形成病历草稿。例如，医生询问患者疼痛持续多久，患者回答后，系统将相关内容归入现病史；医生完成口腔检查后，系统将相应结果关联到具体牙位和检查项目。

　　这里有一个重要原则：医生没必要也不应该为了配合 AI 而被迫使用固定的说话格式。系统应该尽可能适应医生和患者之间自然的表达方式，同时在关键信息缺失或存在歧义时进行必要的确认。

　　当然，实际产品需要根据诊室环境、患者隐私要求和医生工作习惯，决定采用持续语音采集、按键录音还是分阶段录入。当然，持续录音还需要去做语音片段的分割。

　　第三步：本体帮助系统把零散表达转化为结构化临床信息

　　医生的自然语言往往是连续的，而电子病历需要按照特定结构组织内容。本体在这里发挥重要作用。

　　它帮助系统识别不同的临床概念，将信息映射到统一的语义模型，并建立牙位、检查结果、诊断和治疗计划之间的关系。

　　对于已经明确的信息，系统可以自动组织；对于存在歧义的信息，则应当保留不确定状态，对于缺失的检查或者相关信息进行明显的提示，这些都等待医生确认。

　　例如，医生提到“右下后牙”，但没有进一步明确牙位时，系统可以将其暂时记录为未精确定位的部位，而不是自动选择一颗牙。这比为了追求自动化程度而强行补全信息更加重要。

　　第四步：病历生成后，系统进行完整性和一致性检查

　　病历草稿生成后，系统依据病历模板、本体关系和经过审核的规则进行检查。

　　如果某些必需信息缺失，系统可以提示医生补充。

　　如果某项检查结果没有明确关联牙位，系统可以提醒医生确认。

　　如果医生的口述与最终病历之间存在明显差异，系统可以标记出来，供医生审核。但必须区分两类校验。

　　第一类是能够明确判断的结构性问题，例如必填字段缺失、格式不正确或牙位关联为空。

　　第二类是需要临床判断的问题，例如某项检查是否足以支持诊断、治疗方案是否适合患者。

　　前者可以通过规则和数据校验解决一部分；后者只能在适用的临床指南、可靠证据和医生判断基础上提供辅助，不能把模型提示当作自动诊断结论。

　　第五步：医生确认后，系统完成正式病历

　　最终生成的病历应该以医生可理解、可编辑、可追溯的方式呈现。

　　医生可以查看原始语音转写、结构化信息和生成后的病历，修改有误的内容，确认关键字段，最后完成审核和签署。

　　一旦正式签署，系统就应该按照医疗记录的管理要求保存记录，并保留必要的修改痕迹和审计信息。

　　AI 这里可以承担大量重复性的整理工作，但不能绕过医生的审核责任。

　　这套流程的目标不是让医生完全不再操作电子病历，而是尽量减少重复录入、机械整理和无效切换，让医生把更多精力放在患者沟通与临床判断上。

　　四、怎样进行AI电子病历的质量控制

　　这是整个项目最需要认真对待的问题。在一般办公场景中，AI生成的文字不够准确，用户可以修改后再使用。

　　但在医疗场景中，病历记录涉及临床事实、诊断依据、治疗过程和后续医疗决策。一个看似细小的错误，也可能影响后续诊疗和医疗质量管理。

　　因此，病历生成系统必须围绕临床事实建立质量控制机制。我认为至少要关注五个方面：

　　第一，事实不能凭空生成。

　　医生没有明确表达、检查系统没有提供、既往记录也没有证实的信息，不能因为它符合常见临床模式，就被模型自动补全为事实。

　　第二，不确定性必须被保留。

　　“考虑某种疾病”“不能排除某种情况”与“确诊某种疾病”具有不同的临床含义。系统不能为了让病历更完整，就把不确定的表达改成确定结论。

　　第三，牙位与临床信息必须准确关联。

　　口腔电子病历具有很强的部位特异性。同一项检查结果如果关联到了错误的牙位，即使文字本身没有错误，也可能导致病历出现实质性问题。

　　第四，诊疗计划与实际执行治疗方案步骤必须区分。

　　医生提出的治疗建议、已经制定的治疗计划，这些与实际完成的操作，是不同的临床事实。系统不能把“计划进行某项治疗”自动写成“已完成某项治疗”。

　　第五，所有关键内容都应能够追溯。

　　对于重要的结构化信息，系统应尽可能保留其来源，例如来自医生口述、既往病历、检查设备，还是人工补充。同样当医生修改了 AI 生成的内容时，也应当保留必要的修改记录。

　　这五点共同构成了临床 AI 病历生成的基本质量底线。

　　本体能够帮助统一概念、明确关系，规则引擎能够执行确定性的校验，大模型能够理解和组织语言，但这些技术都不能单独保证病历绝对正确。

　　因此，最终的质量控制必须建立在多层机制之上，而不是依赖某一个模型的能力。

　　写在最后：技术能跑通，不等于项目真正成功

　　从上面方案看出语音 AI 与本体结合，为口腔电子病历带来了新的可能。我们可以让医生用更自然的方式表达临床信息，让大模型负责理解和整理，让本体提供统一的临床语义，再通过规则校验和医生审核，形成更加规范的结构化病历。

　　但需要清醒地认识到，技术架构设计得再好，工作流程设计得再合理，也不能仅凭一次演示，就保证项目已经成功。

　　一份病历能够自动生成，不等于医生真的节省了时间；病历看起来更加完整，不等于临床质量一定提高；少数医生试用后觉得不错，也不等于系统适合在整个机构推广。

　　所以从技术上能够实现，到业务上真正产生价值，中间还缺少一个非常关键的环节：验证。这也是很多 AI 项目，尤其是那些技术上已经验证成功的项目，最容易忽略的地方。

　　我们往往花费大量精力证明模型能够工作，却没有在项目开始之前明确：究竟要解决什么业务问题？应该用什么指标衡量改善？怎样排除其他因素的影响？达到什么标准才能认为项目值得推广？

　　如果这些问题没有答案，AI 项目就可能停留在演示效果很好、实际价值却说不清楚的阶段。因此，下一篇我们将专门讨论一个容易被忽视、却直接决定 AI 项目能否真正落地的问题：

　　下一篇：AI 项目如何证明自己真的创造了价值？——从技术验证到业务验证，如何设计一套可信的试点方法。

　　我们将以口腔电子病历为例，具体讨论如何建立项目基线、设计对照测试、衡量病历书写效率、评估临床质量，以及如何根据真实数据判断一个 AI 项目是否具备推广价值。因为对于企业而言，最终需要回答的，从来不只是 AI 能不能做，而是它是否真正解决了问题，以及它创造的价值能否被可靠地验证。（来源：IT斜杠女青年 挨踢职场斜杠青年）

#企业AI#企业级AI#数智化#数字化#一线数智#企业AI应用场景#企业AI工具#制造#高质量发展