摘要：电子病历改造从来不只是一次系统升级。它同时牵动医务、病案、质控、信息科、数据团队和实施团队。作为省级人民医院信息科主任，我真正关心的，是如何让需求说得清、责任找得到、依据查得到、审批有记录，最终让改造成果进入日常工作，而不是停在汇报材料里。
需求只有一句话，背后却是一张复杂的协作网
"我们要重构电子病历系统。"
收到这个需求时，第一反应不是页面怎么设计、数据库怎么调整，而是：这件事会牵动多少人？
一家省级人民医院的电子病历，连接的不只是一个系统。医务处关心临床流程是否顺畅，病案室关心病历书写与归档要求，质控办关心问题能否发现、整改能否闭环，数据团队关心字段口径和取数边界，信息科还要统筹接口、安全、权限、迁移和上线节奏。外部实施团队进入项目后，又要尽快理解医院内部多年形成的规则。
每个人都很专业，但大家看的是同一件事的不同侧面。
过去做类似项目，最让人头疼的往往不是某个技术难点，而是协作失真：群里的消息往前翻几十页也找不到，会上形成的结论到了会后出现多个版本，同一个字段在不同文档里有不同解释，一句"这个问题再核对一下"说完，却没人能准确回答由谁核对、何时完成、完成后谁来确认。
如果这些问题不先解决，系统做得再快，也可能在后期付出更高的返工成本。
所以这一次，我们先做了一件看起来很基础、实际上非常关键的事：把项目的讨论、任务、数据、依据、文档、审批和成果，放进同一个协作环境里。
第一件事：先让所有人看到同一个项目
我们在平凯 Loop 中建立了"电子病历数据与质量看板"项目。
项目首页不只是展示一个完成百分比，而是把需求、负责人、任务进度、风险、相关文档和最终交付放在同一个视图中。每天早上，我先看项目整体健康度，再看哪些任务亮了红灯、哪些事项在等待确认、哪些风险需要跨部门协调。
以前，想知道一个问题卡在哪里，我可能要在群里询问、给同事打电话，再去翻会议纪要。现在，我可以先从项目总览定位到具体事项，再找到负责人和相关上下文。
管理方式由此改变了：项目不再依赖某个人"记得全部情况"，而是让团队共享同一份事实。
把会议和群聊里的"说过"，变成真正有人负责的"做完"
电子病历改造不可能只靠信息科闭门完成。
我们把信息科、医务处、病案室、质控办、数据团队和实施团队放到同一条项目协作主线上。医务同事提出业务场景，病案和质控同事补充规则，数据团队核对字段和数据来源，实施团队评估技术实现。不同专业 Agent 则帮助我们整理分歧、归纳结论、识别待办。
但我们也很清楚：有讨论，不等于有结果。
例如，频道里有人提出："这个字段需要重新核对。"过去，这句话很容易淹没在后续消息里。现在，它会被转成一项明确任务，带上负责人、优先级、截止时间、相关子任务和验收要求。
下次周会，我们不再逐个人问"进度怎么样"，而是直接看风险队列：
- 问题卡在业务定义，还是技术实现？
- 当前缺少谁的确认？
- 是否影响后续迁移或上线？
- 由谁拍板，什么时间必须完成？
这样做不是为了增加管理动作，恰恰是为了减少反复追问和无效会议。一句讨论只有进入任务、完成验收，才算真正闭环。
最容易引发争论的，往往是"大家以为已经一致"的数据口径
电子病历改造涉及患者主索引、就诊、诊断、医嘱、检验、病历文书等多类数据。
数据一多，最常见的问题就是版本和口径不一致：你拿的是昨天导出的表，我看的是上周整理的版本；同一个指标，业务部门和技术团队使用了不同的统计范围；字段名称相同，实际含义却不完全一样。
因此，我们把表结构、字段说明、更新时间、取数边界和相关责任统一放进数据空间管理。页面使用经过整理的数据服务，团队可以看到数据何时更新、按什么口径整理、由谁负责维护。
这一步带来的价值，并不是简单地"把表放到一起"，而是让每一个关键指标都能回答三个问题：
- 它从哪里来？
- 它按照什么规则计算？
- 出现异常时，应该沿着哪条路径追溯？
当数据来源和口径能够被追溯，讨论才有共同基础。大家不必再凭记忆争论，也不会因为人员变化，让原来的判断依据一起消失。
规范、方案和历史判断，不能散落在个人电脑里
改造过程中，我们会反复查阅电子病历规范、字段字典、数据治理材料和院内约定。
过去，这些材料可能分别存在共享盘、个人电脑、群文件和邮件附件里。项目做得越久，越容易出现"我记得某份文件里写过，但一时找不到"的情况。
我们把这些依据集中到知识库，并让讨论能够回到具体材料和对应章节。当有人问"这个字段为什么这样定义""这项质控规则依据是什么"时，团队可以直接核对来源。
同时，改造方案也不再由信息科单独写完后，再发给各部门轮流修改。我们使用协同文档共同完善现状问题、字段映射、迁移步骤和回滚方案：医务处补业务规则，病案室核对病历规范要求，质控办确认检查标准，数据团队补充实现细节。
每次修改都有记录，每条评论都落在原文附近。减少了多人分别保存文件后产生的版本混乱。
自动化可以提高效率，但不能替医院承担责任
项目进入数据准备、方案检查、业务确认和归档阶段后，我们通过工作流推动各步骤按顺序执行。
能够标准化的重复工作，可以交给 Agent 协助整理、检查和执行；但遇到业务口径、安全边界、权限调整或上线发布等关键节点，流程必须停下来，等待对应负责人审核。
这是我们在项目中始终坚持的一条原则：
Agent 可以帮助团队减少重复劳动，但不能替代医院作出最终判断。
效率提高，不代表责任被自动化带走。谁发起、谁复核、谁批准、依据是什么，都要留下清楚记录。尤其在医疗场景中，任何看似省事的"自动通过"，都可能把风险推到更靠后的环节。
因此，我们追求的不是"让系统替人决定"，而是让系统帮助人更完整地获取信息、更及时地发现问题，并在需要决策的地方把责任交还给正确的人。
改造不是交付一份报告，而是形成每天有人使用的工作台
项目完成后，我最不希望看到的，是所有成果最后停在一份汇报材料里。
电子病历改造的价值，要回到医院每天的管理和业务动作中。因此，我们把改造成果沉淀为"电子病历数据与质量看板"。在这里，可以查看病历完整率、完成及时率、接口新鲜度、科室差异、质控问题和整改进度，也可以根据问题继续找到到对应的整改工作项。
不同角色看到的是同一套数据服务，但关注点不同：
- 院领导看整体情况和重点风险；
- 科室看自身问题与整改进度；
- 信息科看数据链路和运行状态；
- 质控人员看问题分布与闭环情况。
这时，项目总览、频道协作、任务闭环、数据空间、知识库、协同文档、工作流审批和工作台，不再是八个孤立功能，而是串成了一条完整链路：
从需求提出，到多人讨论；从任务执行，到数据核对；从方案共创，到关键审批；最后再把结果变成日常可使用、可持续改进的工具。
重构背后，是一条可复用的工作路径
回头看这次电子病历改造，我们解决的并不只是页面、接口或数据表的问题。
更重要的是，我们通过这个跨部门、长周期、强专业的复杂项目，形成了一条清楚的工作路径：
- 需求看得见，不再散落在不同群聊和会议中；
- 责任找得到，每个问题都有明确负责人和验收要求；
- 依据查得到，规则、口径和历史判断能够随时核对；
- 审批有记录，关键决策仍由医院相关人员把关；
- 结果能持续使用，不因项目结项而失去价值。
对信息科来说，这才是一次电子病历改造真正应该实现的"透明化、协作化、可追溯"。
技术当然重要。但面对一家大型医院的复杂协作，我越来越相信：真正可靠的数字化，不只建成一套系统，更是让每一次讨论、判断、执行和交付，都能够沿着同一条路径向前推进。
声明：本文根据电子病历改造演示场景整理，采用匿名，不对应或披露特定医院、患者及真实项目数据；文中所述功能与流程以实际产品版本、部署配置及医院管理制度为准。