门诊病历智能生成听上去像是一个算法问题实际上是一个系统问题。一位医生上午要看三四十个患者真正留给病历书写的时间是以秒计算的。很多门诊病历因此变成了“复制粘贴前次记录、改一下日期、改一下药量”的产物等病历质控抽查时一眼望去全是与本次就诊无关的既往描述。这种现状靠一个文本生成模型解决不了必须靠一整套系统架构来改造。我在整理门诊电子病历智能生成方向时发现很多团队把注意力放在“选哪个模型来生成文本”却忽略了真正决定一个项目能不能长期运行的因素数据从哪来、上下文怎么组装、结果怎么给医生审核、安全边界怎么控制、模型挂了怎么办。这篇文章就围绕这些点把门诊病历智能生成系统的架构决策拆开讲。它更像是对一张系统设计蓝图的重读而不是某个模型的教学笔记。1. 先回到病历现场把系统边界定义清楚1.1 门诊病历不是一个“要让 AI 写作文”的任务写病历的第一性不是生成一段好看的中文段落而是把患者的本次就诊信息准确、完整、结构化地记录下来。一位门诊医生写完病历后需要这套文书与诊断、处方、检查检验结果保持一致。病案录入、医保审核、科研统计、下一次复诊时还原病程都需要字段级的结构化数据。门诊病历不是一个自由文本而是一个有强字段约束的文档。因此在做架构之前要先想清楚一个问题你的生成系统要输入什么、输出什么。在常见实践里病历字段至少包括患者信息姓名、性别、年龄主诉、现病史既往史、过敏史查体、生命体征辅助检查结果诊断、处理意见、医师签名这些字段中有些能从 HIS/EMR 直接取到有些需要由医生录入有些可以由 AI 根据问诊和既往数据生成草稿。不能全让 AI 一次生成。一个常见的架构误区是让 AI 直接输出整份病历长文本再想办法去解析、拆分、映射到字段。这样做的代价很高模型一旦在结构上不自洽拆出来的字段就可能错位。更稳妥的思路是在服务层先定义好结构再让 AI 围绕结构去补齐内容。也就是先生成“骨架”再填充“血肉”。1.2 系统边界只做“受控草稿生成”如果系统一键就输出一份可提交的病历医生会面临两个问题一是信任二是责任。一旦生成结果出现幻觉或错误来源难以回溯又没有修改入口这个系统绝不会被真正使用。更适合的范围是输入边界采集来自挂号、问诊、既往史、检查检验、患者自述等数据源的信息而不是让 AI 自行推断缺失内容。输出边界生成一份按照模板结构排好的草稿由医生在可视化编辑器中审核确认。控制边界在提交前有强制校验提交后有版本记录。从工程经验来讲即使 AI 能力再强也应该保留“纯模板生成”和“手动填写”两条路。AI 生成只是减少医生的重复劳动而不能堵死医生自己的书写路径。可以用一句话总结系统目标把数据流整理成一条“多源采集 → 智能生成 → 医生审核 → 结构化入库”的受控流水线。1.3 与外部系统的数据契约医院场景里不能把数据对接当成一次简单的复制粘贴。门诊智能生成系统需要与 HIS/EMR 建立明确的数据契约。通常会用到的数据包括挂号与基础信息历次就诊摘要既往史与过敏史本次检验检查结果药品、诊断编码模板和质控规则这些数据在接口层面要有版本管理。字段一旦变化服务层要有兼容逻辑。否则模型生成到一半接口字段变了整条流程就断了。2. 分层架构接入层、服务层、AI 能力层、数据层2.1 四层划分而不是一个单体应用从工程实践看门诊病历智能生成系统更适合拆成四层而不是把生成逻辑直接塞进原来的门诊系统里。层级核心职责关键组成设计重点接入层面向医生端、HIS 前端提供统一接口医生编辑器、移动端、HIS 集成 SDK请求幂等、身份认证、并发控制服务层业务编排与流程控制任务调度、模板服务、权限校验、审计、状态机不承载具体算法负责调度与降级AI 能力层负责数据解析与文本生成ASR、NLP 抽取、NER、生成大模型、后处理模块独立部署、独立扩容、可替换数据层存储与查询EMR 快照、模板库、知识库、生成记录、日志数据分层、隐私保护为什么必须分层第一独立迭代。大模型演进很快半年换一个模型很正常。如果业务代码和 AI 代码耦合在一个应用里每次换模型都要动所有代码风险极高。分层之后AI 能力层只在内部做接口切换服务层不需要感知。第二成本控制。不同模型有不同的 Token 成本和延迟不同任务对模型的复杂度要求也不同。有些字段用轻量模型就能生成不需要每次都调用大模型。AI 能力层可以根据场景选择模型路由。第三安全边界。AI 层不能直接访问患者库只能接受服务层组装的受限上下文。这样即使模型服务被攻击泄露的也只是单次请求中的最小数据而不是整个病历库。2.2 服务层是“编排者”不是业务副本服务层是一个非常关键的层。很多人会把服务层理解成“把病历数据传给模型再把结果返回前端”的中间件但它的职责远不止这些。服务层要处理三件事权限装配医生进入生成页面之前服务层要确认“当前医生是否有权限查看这个患者”。这必须在调用 AI 能力之前完成。流程编排调用哪些 AI 组件、结果如何拼接、是先做模板生成再做智能改写还是并行调用多个组件都在服务层控制。降级与重试一次 AI 调用失败展示给医生的是友好错误或降级到手工编辑而不是一个无响应的页面。服务层不包含“生成”“推荐”等算法逻辑但它包含如何组织这些算法流程的策略。举一个例子当模型连续三次返回超时服务层会自动切换到“模板模式”让医生使用传统方式填写病历。这个降级策略必须是默认能力而不是临时补丁。2.3 AI 能力层要设计成“可替换组件”在 AI 能力层内部不建议把生成逻辑和某个具体模型强绑定。更合适的做法是把 AI 能力抽象成一组内部服务语音转写服务如果问诊过程有语音输入结构化信息抽取服务病历文本生成服务后处理与校验服务每个服务对服务层暴露统一接口。模型替换、Prompt 调整、阈值修改都发生在 AI 能力层内部。服务层不需要知道“这次生成用的是哪一版模型”。这么做还有一个好处不同医院的部署环境差异很大。有的医院要求模型必须跑在内网有的允许调用私有化部署的模型服务。把模型部署细节封装在 AI 层内部服务层可以保持相对稳定等到每家医院部署时再决定底部接什么引擎。3. 点击“生成”之后一次完整的调用链路3.1 从医生点击“生成草稿”开始一次典型的病历智能生成从用户点击“生成草稿”到前端看到结果主链路大致如下鉴权接入层通过 token 校验医生身份。权限校验服务层确认医生对当前患者有访问权限并获取当前就诊 ID。数据取数服务层从 EMR/HIS 获取本次就诊核心字段如主诉、症状、查体、检验、诊断等。上下文组装将字段按模板要求打包控制长度加入缺失信息标记。调用 AI 能力服务层调用 AI 能力层的“病历生成”接口传入上下文和模板 ID。生成与后处理AI 层返回结构化病历草稿后处理模块做语句去重、字段校验、敏感词替换。返回草稿服务层把草稿写入“待审核”状态接入层把它渲染在医生前端。医生编辑提交医生修改后提交系统记录生成版本与修改版本。这里需要特别强调第 4 步。上下文组装不是简单把所有字段拼接起来。上下文不仅包括当前页面文字还包括最新检验结果、与诊断相关的限制条件。举例如果本次就诊有异常指标应该把异常指标放到显眼位置让模型在生成现病史时引用它。如果既往史为空不能猜默认值而应标记“待补充”。3.2 同步还是异步门诊场景里的用户等待时间是有限的。生成任务有三种实现模式同步返回适合单段落生成几秒内返回。异步轮询适合较长病历、多个字段并行生成需要几十秒到几分钟。混合模式先同步返回主要部分草稿再在后台异步优化其他部分。从产品体感来说我更建议先采用“混合模式”。第一次请求时如果模型延迟很高服务层可以基于模板先生成一份可用的初步草稿保障医生能继续工作后台再异步进行智能补全给医生一个“优化建议”入口。这样既照顾了体验也避免了模型抖动带来的业务中断。3.3 接口返回建议结构化草稿而不是一大段文本如果只返回一个长字符串医生端很难做字段级修改和校验。更好的返回结构是一个 JSON 对象每个字段独立。{ task_id: txn_20250101_001, status: draft_ready, draft: { chief_complaint: { content: 反复咳嗽2周, status: confirmed }, present_illness: { content: 患者2周前受凉后出现阵发性咳嗽夜间明显伴少量白痰。无发热无气促。未自行用药今至门诊就诊。, status: ai_generated, confidence: 0.88 }, treatment_advice: { content: 建议完善血常规、胸部影像嘱多饮水、注意休息3日后复诊。, status: ai_generated } }, warnings: [ 既往史字段缺失已标记为待补充 ] }在这个示例里status可以让前端区分哪些内容是已经由医生确认的哪些是 AI 生成的。后续审计时也能还原病历最终版本来自何处。3.4 状态机设计生成任务不是一个简单的接口调用而是一个有生命周期的流程。建议在架构设计阶段就确定状态机pending待生成generating生成中draft_ready草稿已完成reviewing医生编辑中submitted已提交cancelled已放弃每个状态的变化都要记录时间、操作人和操作类型。状态机的好处是当医生中断编辑、模型调用失败、网络超时系统都能恢复到一个确定状态而不是一直停在“卡住”的模糊状态里。4. 安全、权限和审计不是加固项是架构的地基4.1 最小数据暴露原则在 AI 能力层要尽量减少不必要的患者隐私字段暴露。比如生成现病史时可能不需要完整身份证号、详细住址、手机号。可以做静态脱敏把姓名、身份证号、住址替换为占位符AI 层返回结果后再映射回去。不要把这个设计当成临时处理。脱敏与反脱敏应该做成独立组件所有调用模型服务的请求都经过它。这样即使模型调用日志被打印出来也不会暴露完整患者信息。4.2 权限收敛权限控制有一个基本原则先校验后取数。前端页面不能决定“医生能看哪些数据”服务层必须二次校验。数据按医生角色、科室、患者归属过滤。AI 能力层不能直接访问全量数据库只能接收服务层提供的隔离上下文。有些团队为了方便让 AI 服务直接连接病历库虽然模型生成效果可能更好但一旦发生越权查询问题会非常严重。架构上应该把“数据访问边界”写死。4.3 审计日志与版本记录门诊病历生成系统的审计日志需要记录生成请求对应的患者、医生、科室。使用了哪个模板、哪个模型。返回的 JSON 草稿。医生最终编辑后的版本。医生提交时间和提交人。这些数据不仅用于追溯还能帮助区分“AI 生成内容”和“医生修改内容”。审计日志本身要避免记录不必要的大段患者信息如果确需保留应进行脱敏存储或设置严格的访问权限。注意不要在服务器日志中打印完整病历文本。否则排查问题时很容易把患者隐私直接输出到日志文件里。5. 真正的难点上下文组装、受控生成和评估闭环5.1 上下文组装器决定生成质量的隐藏模块决定生成质量的往往不是采用哪个模型而是上下文里给了什么数据、怎么组织。上下文组装器Context Assembler就是解决这个问题的模块。它的核心职责包括从 EMR 取数中筛选与本次就诊相关的核心字段。按提示词模板排列字段顺序。控制输入长度避免超过模型上下文窗口。将缺失字段替换为“待补充”而不是让模型自行推断。引入临床知识库和科室模板约束。如果不做上下文组装直接把 EMR 里所有字段都倒入模型生成的病历会冗长、重复、信息密度低还可能超出上下文限制。更麻烦的是模型会把无关信息也写进病历史增加医生修改负担。经验上上下文组装时要按字段重要度做裁剪。主诉和现病史优先实验室数据只保留与当前症状相关的异常指标。长段既往史可以压缩为摘要而不是全部原文。5.2 受控生成约束要让生成尽量不产生幻觉除了提示词约束还要有规则校验。白名单校验诊断字段能否从常用 ICD 编码列表映射不能生成不存在的疾病名称。字段完整性校验主诉、现病史、查体、诊断、治疗意见不能为空必须用“待补充”标记。单位校验血压、体温、剂量等常见临床单位要符合规范。去重校验部分模型在生成长文本时容易把同一句话重复表述两次后处理时要自动去重。提示词是第一层约束后处理是第二层防线。提示词可以这样理解“这是一份门诊病历草稿请根据给定字段生成。不能虚构患者不存在的信息。缺失信息请用待补充标注。” 但真正保证质量的是后处理规则。5.3 效果评估从“文本看起来通顺”到“医生真的愿意改少”评估一个智能病历生成系统不能只看几个样例。我一般会建立一套以“编辑成本”为核心的指标指标计算方式解读生成采纳率医生最终直接使用 AI 草稿的比例比例过高或过低都值得分析平均编辑距离AI 草稿与医生提交版本的差异差异越小说明生成越贴合字段改写率修改字段数 / 生成字段数定位模型的薄弱字段生成时长从点击到返回的时间超过一定时限医生不会等放弃率医生点击生成后放弃/删除反映生成可用程度也要注意医生使用率低不一定是模型不行可能是入口不明显、模板不对、字段缺失。评估结论一定要结合医生反馈不能只看数字。5.4 反馈闭环AI 生成的草稿和医生编辑后的版本是重要的反馈数据。定期做差异对比可以为优化提示词、调整模板、增强模型微调提供素材。但要注意这些审核数据涉及患者隐私必须在脱敏、授权、合规范围内使用。不能简单把所有问答历史和病历文本一股脑收入训练集。6. 从试点到全院的落地策略与避坑清单6.1 选对第一个落地场景选择场景的优先级比模型选型更重要。我建议从以下三个维度筛选写病历量大、病种相对固定。比如呼吸内科、普通内科。病历类型具备较成熟的结构化工序。先从生成“主诉 现病史”开始而不是一上来就生成完整诊断和处理意见。诊断和处理意见带有强医疗决策性质作为第一步容易控制不好。可以先辅助完成病史描述类文本在积累足够反馈后再逐步扩大到其他字段。6.2 灰度发布、并发控制和容灾门诊系统有明显高峰时段。项目在接入门诊时测试环境要覆盖到真实高峰场景。不要只在低并发的测试环境里验证。发布时建议限制每秒并发请求数。为每个就诊时段设置调用配额。模型排队时提供模板生成作为降级路径。模型服务不可用时系统不要阻塞医生就诊流程。注意不要一上来就把并发数拉满先用一条样例确认输入、输出和日志都正常再逐步放开流量。6.3 典型避坑清单把历史自由文本直接当训练语料未脱敏未建立规范字段。忽略字段差异导致生成文本与现代病历字段不匹配。提示词跨科室共用不考虑不同科室的术语口径。没有超时和重试机制模型卡住后医生端一直无响应。把隐私数据直接写到日志文件里违反安全基线。一份病历只允许 AI 生成不提供人工编辑入口。这些坑里如果要说哪一条最容易踩我认为是丢失降级路径。生成系统是辅助门诊系统的主路径永远要保证能正常完成病历记录。如果 AI 层阻塞十秒以上医生不可能一直等。所以降级到模板、降级到手工必须是默认能力。7. 长期演进生成病历不是终点结构化沉淀才是目标7.1 从“一次生成”到“数据回写”如果只把生成结果当作一次性文本展示这个系统的价值会小很多。更有价值的做法是让生成过程产生结构化数据把现病史中的症状时间线、用药史、过敏史、检查结果的异常标记等拆出来写回中间数据结构。这样生成草稿的同时系统也在不断积累结构化的病历数据。这些数据后续可以用于病案首页、临床科研、随访计划、质控规则等方向。7.2 三个阶段第一阶段规则模板 少量 AI 辅助。把数据装配、权限、审计跑通形成最小可用闭环。第二阶段AI 受控生成。把提示词、后处理规则、评估指标跑通让生成结果真正进入医生工作流。第三阶段生成结果反哺数据。让病历中的结构化信息进入病案首页、科研随访、质控规则形成数据管道。这三个阶段的价值不是替医生写一段文字而是最终形成一个可复用、可分析的临床数据管道。到这一步门诊病历智能生成才会从“辅助工具”变成临床数据基础建设的组成部分。7.3 几个长期判断第一模型会越来越强但门诊病历生成的核心壁垒会转向数据工程、流程控制、医疗知识库建设。第二系统架构的最终目标是让 AI 生成在可控边界内工作。第三医生拥有最终审核权。这既是安全要求也是产品能被接受的基础。如果这个项目只是做出来一个 Demo生成几个漂亮样例那不是成功。真正有效的验证是医生在真实门诊时段愿意用、愿意改、敢提交。那才说明系统架构把 AI 能力放在了合适的位置。门诊病历智能生成真正值得投入的地方不是“更快生成一段文字”而是把一段重复劳动变成一套受控、可复用、可迭代的医疗数据流程。先把流程跑通再谈模型优化这才是这类项目最务实的路径。