刘浩南 刘浩南-AI实战派 2026年9月7日 08:56
8 月 11 日，开始闭关，我在 Codex 里敲下了一句话：我要做一个国内最好的开源 EMR。
到 9 月 6 日，过去了 26 天。需求、产品、架构和验收由我来定，代码主要交给 Codex 和 DeepSeek harness。现在，这个项目叫 HaoEMR ，已经开源。
先看它现在长什么样。
HaoEMR 登录页
HaoEMR 首页
门诊工作台：候诊队列、本次病历、诊断医嘱和患者时间线围绕同一次就诊展开。
门诊、急诊、住院，病历书写、质量管理、诊疗执行，再到数据、知识和 AI 医助，已经有了可以实际操作的系统。这个项目累计消耗约 73.1 亿token。看到token消耗结果时，我自己也觉得夸张。但打开系统以后，其实应该没人会在意我花了多少 Token。大家可能更想知道的是： 这个 EMR 到底有什么值得用的？
1、我把病历当成了整个产品的中心
HaoEMR 的入口分成门诊、急诊、住院三个工作域。
这三个工作域使用同一套患者、就诊和文书基础，但各自关心的事情不同。门诊重在接诊效率；急诊盯时间、风险和去向；住院要把几天甚至更长时间里的文书、医嘱、结果和责任连起来。
最核心就是病历。
我很早就说过，病历是这个项目的核心亮点，要往深处做。光有一个能输入文字的编辑框，距离我想做的东西还差很多。
现在，病历可以按章节编辑。主诉、现病史、既往史、过敏史、检查、评估和计划有各自的位置。医生可以停留在当前章节，按需查看质控、来源和版本，不必始终面对几十个展开的面板。
专注编辑页。章节、正文和质控入口放在同一个工作空间，当前展示的是已有草稿。
这种设计有一个后续收益：来源可以对应到字段，质控问题可以定位到章节，AI 起草的内容也可以按段落选择。编辑器和后面的能力用的是同一套文书结构。
保存还只是开始。病历进入签署、更正、补记、撤签、作废、归档后，原来写过什么、谁签过、后来为什么修改，都要落地。
所以我给病历做了版本和证据页。报告已经更正，病历仍引用旧结果，需要能找出来；两个人同时编辑，后一份表单不能无声地覆盖前一份；已经签过的内容需要修改，就产生对应的更正关系。
对医生而言，最好只需看到“当前版本”“有冲突”“这条来源已更新”。这些提示背后的约束，系统自己处理。
全院病历中心则从另一侧看同一批文书：按岗位权限汇总门诊、急诊、住院病历，把待审签、质控问题和抽查任务放在工作队列里。
病历中心可按患者和文书状态筛选，再进入处理、质控和证据页面。
我不想让“写病历”和“管病历”长成两套互不相认的产品。医生保存的内容，应该就是后续质控、审签和归档面对的那份内容。
2、门急住的区别，要体现在操作上
门诊页面里，我希望医生选中患者以后，可以连续完成这一轮工作。查看既往信息、写病历、维护诊断、开医嘱、看结果，切换的是工作内容，患者和本次就诊要保持一致。
在急诊，优先级就变了。
抢救发生在什么时候，护理评估是否完成，会诊有没有接手，留观患者最终去了哪里，这些信息应该直接出现在工作台上。需要立即处置的风险不能全体现在一篇长病历里。
急诊把分诊、抢救、护理、交接和留观去向放到同一屏，时间与责任更靠前。
住院更像一段持续更新的工作。一个患者今天该补哪份文书，哪些医嘱还在执行，检查结果需要谁复核，会诊意见有没有进入病程，出院前还差什么，都要看得见。
住院总览把文书任务、医嘱结果、会诊、路径和出院入口集中起来。
因此，住院文书有时限和审签任务，临床路径有阶段和必须完成的事项，出院有准备度检查。已经做过的端到端验证，也会从入院往后走到出院，而不是只验证“新增患者成功”。
这也是我没有从一开始为了求简单就把项目限定为诊所版的原因。我想先把医疗业务的基本关系想清楚，再通过配置处理机构差异。它还需要真实医院现场的检验，但设计时不能把这些关系省掉。
3、医嘱开出去以后，系统还得继续管
做 EMR 很容易停在医生这一端：病历保存了，医嘱开出去了，页面显示成功，流程结束。
接下来，药房要调配和核对，检验要处理标本，影像要安排检查，护理要记录执行。任何一个环节只记了自己的状态，医生看到的就可能还是另一回事。
HaoEMR 把这部分组织成诊疗执行中心。先选患者，再进入费用、药房、检验、影像、治疗、手术、麻醉、输血或设备监护的工作队列。
选择患者后进入执行工作区，各专业工作台保留自己的核验与状态。
这里我更在意一些不显眼的设计。例如发药的操作人和核对人是否分开，床旁给药是否核对了患者和医嘱，标本是否已经接收，影像的部位和侧别是否明确。
这些动作最终应该改变来源业务的状态。否则“已处理”只是另一张表里的一个标签。
任务中心负责把不同环节的责任串起来。谁来处理、多久处理、需要委托给谁、超时如何升级，都有对应记录。完成条件仍然由来源业务判断：某项检查没有复核，就不能为了清空待办把它随手勾掉。
任务队列保留来源、责任、时限和处理记录。
临床路径也沿用这个思路。患者进入某一版路径后，阶段任务与具体业务对象关联。文书审签、结果确认、会诊处理完成，才能成为推进路径的依据。发生变异，可以留下理由和审核记录。
路径执行展示当前阶段及来源要求。尚无证据的事项保持待处理，不自动涂成绿色。
我希望这个系统能少一些“医生已经做过一遍，还要在另一个页面再点一次完成”的操作。
4、病历写完以后，还有质量与保存
质量中心解决的是跨病例、跨科室的工作视角：病历质量、评级材料、院感与不良事件、临床资质，各自有台账，也能从总览进入处理。
具体到病历编辑，质控应该尽量靠近问题发生的地方。某一章节缺了内容，直接回那一节修改；保存后是否自动检查，由当前页面明确控制；同一次就诊的文书质量，可以汇总查看。
这部分还在继续扩展。我没有把完整院级质控、所有评分规则和申诉复核体系都算成已经完成的功能。
病案资产中心关心的是另一组问题：纸质病案、扫描件、电子文件，原件在哪里，是什么格式，有没有页数和校验记录，是否被借阅或封存。
病案目录中的合成扫描样例：文件经过实际上传与存储重读校验，保留来源、载体和校验信息。
我不希望“归档”只是给文件换一个目录名。原始文件、内容哈希、文书版本与归档清单需要联系起来，后续调阅和导出才有依据。OCR、外部存储与医院现有病案系统的适配，还需要按实际部署条件继续验证。
5、医院之间的差异，我放进配置里
同样一份文书，不同医院的模板会不一样；同样一个会诊任务，不同科室的时限和责任也会不同。
HaoEMR 现在有流程、表单、规则、职责范围、能力包和科室适配的配置入口。比如流程节点由谁处理、到期如何升级、哪个条件允许向后走，都有明确的位置。
已发布流程与候选草稿分开。运行中的业务需要知道自己使用的是哪一版配置。
我最不满意的一种“配置功能”，是页面很好看，保存也成功，但业务运行时压根不用。
所以这个项目的配置验收会继续往下查：修改并发布以后，哪个业务动作会使用它？产生了什么不同结果？能不能查到当时用的版本？
机构差异可以配置，患者身份、签署证据和权限等核心约束则不能被随意改掉。否则每增加一家医院，内核就会长出一份例外代码，后面谁也维护不动。
知识中心也遵循类似的边界。它保存临床路径等资料的内容、来源与版本，并提供审核和关系浏览。配置决定医院怎么采用，执行页面记录当前患者做到了哪里。
我借鉴过 Obsidian 的阅读和组织方式，但医院使用的知识中心还需要版本、审核与权限。个人笔记软件的体验可以参考，医院知识维护的工作不能省掉。
6、AI 医助在这里面，能帮到哪一步
现在系统里的AI医助叫 EVA。它有 14 组团队、58 个子医助，覆盖就诊摘要、文书起草、病历质控、结果处理、诊疗协同和部分专科任务。
医生可以在工作台里发起任务，也可以从当前业务页面带着患者和就诊上下文进入。得到的结果包括依据、缺失资料、风险提示，以及可继续采用的文书段落或任务候选。
EVA 可以从诊疗任务进入，也支持选择具体医助与数据范围。医疗 Harness 的设计后续单独文章介绍下。
9 月 6 日的隔离合成环境验收，逐个验证了 58 个子医助的真实模型调用，以及候选转提醒、转任务和完成确认。
我愿意公开这个阶段的产品，也是因为它已经有了可以讨论的具体对象。病历哪里难写，哪个队列不好用，配置有没有多余，医助有没有增加复核负担，打开页面就可以谈。
“国内最好的开源 EMR”依然是我的目标。现在我做出了一版“还不错”的 HaoEMR，离那个目标还有不少活要干。
如果你做医疗产品、医院信息化，或者也在用 AI 写复杂项目，可以一起交流！
微信扫一扫赞赏作者
收录于刘浩南AI产品