公立医院数智化转型：从数据治理到管理闭环的落地路径

最近，一场以“数智赋能提质增效”为主题的学术年会，把公立医院高质量发展这个老话题放进了新的技术透镜下。会场里坐着几类人：信息科的人急着找平台，医务处的人关注质量指标，财务处的人更想读懂成本与绩效。同样几个字，在不同人心里是截然不同的任务。这恰恰点出了当前公立医院数智化转型最真实的图景：大家并不缺口号，缺的是把口号拆成可执行路径的共识。

我的核心判断是：公立医院高质量发展语境下的“数智赋能提质增效”，真正难的不是系统选型、不是设备采购，而是把分散在几十个系统里的数据，变成管理层愿意每天看、业务部门愿意用的日常管理闭环。数据和技术只是入口，流程改造和组织协同才是引擎。这也就是为什么，很多医院上了一堆系统，效率却没有明显提升；而另一些医院，看起来没有特别前沿的技术，却能用一张报表推动一个科室改变行为。

1. 一场学术年会为什么反复讲“数智赋能”

1.1 规模增长见顶后，管理必须靠“数据颗粒度”

过去很长一段时间，公立医院的竞争，集中在床位、门诊量、设备投入和学科体量上。这种增长模式下，信息科的核心任务是“支撑业务”：挂号不要排长队、报告能及时打印、医嘱能顺利开出来，工作就已经完成得相当不错。

但现在的行业语境已经在变。公立医院要走向高质量发展，意味着不能只依赖资源扩张，而是要在医疗质量、运行效率、成本控制和患者体验之间找到平衡。一旦进入这个阶段，管理就会遇到一个很现实的瓶颈：没有数据颗粒度，就谈不上精细化管理。

同样一个平均住院日，过去看一个全院总数值就够了；现在需要拆到科室、病种、医生、手术类型、入院方式、术前等待时长等多个维度。只有把指标拆到足够细，才能定位问题到底出在收治环节、检查环节、手术排程环节，还是出院环节。而“拆解”这个过程，天然依赖数据平台、指标体系和数据分析能力。

所以，“数智赋能”这个主题在学术会议上被反复强调，不是因为它听起来前沿，而是因为它回应了医院管理者当下最头痛的问题：决策不能只凭经验和感觉，必须依赖数据证据。如果一家医院连同一指标在不同科室的统计口径都统一不了，高质量发展就缺少最基础的管理底座。

1.2 “提质”和“增效”不是两个词，而是一条价值链

如果单独看“提质”和“增效”，容易被理解成两条平行线：一边抓医疗质量，一边抓运营效率。但实际运行中，这两个目标是一条价值链上的上下游。

“提质”关注的是医疗安全、规范诊疗和临床结局。要实现提质，不能等患者出院后再看结果，而是在就诊过程中就要持续监控：开药有没有禁忌、关键检查有没有遗漏、术后并发症有没有异常信号。

“增效”关注的是资源利用和成本控制。病床周转得快不快、手术室利用率高不高、检查设备排得满不满、医护人员有没有陷在重复劳动里。这些问题如果靠人工统计，通常滞后一个月，等发现问题时，浪费早就发生了。

这两条线一旦用数据打通，就会出现典型的“双向增益”：流程顺畅了，患者等待时间缩短，临床路径执行更规范；医疗质量稳定后，平均住院日和非必要费用也会降下来。反过来，如果数据各自隔离，质量是质量，效率是效率，那“数智赋能”就只是一堆大屏上的彩色数字。

更好的表述是：数智化要做的，是把“看得见”变成“看得懂”，再把“看得懂”变成“用得上”。

• 看得见，靠数据汇聚和平台建设；
• 看得懂，靠指标口径统一和数据分析；
• 用得上，靠流程改造、角色授权和常态化运营。

很多项目之所以高开低走，就是因为走完了第一步，第二步也做了，但到第三步就断了——报表停留在领导驾驶舱里，没有嵌入业务人员的日常操作。数字是新的，工作方式还是旧的。这不是技术问题，是落地机制的缺失。

2. 数智化要真正落地，需要踩准哪三个环节

2.1 第一环节：数据治理，比选平台更重要

医院里最容易出现的一种决策路径是：看到别人上了数据中台，于是也赶紧立项、招标、选厂商。但实际推进几个月后发现，数据中台有了，里面的数据却对不上。

问题通常不在平台，而在上游数据资产本身。医院几十个业务系统，可能是不同厂商在不同时期建设的，同一个患者在不同系统里有不同的姓名拼写或证件号；同一个科室有多个叫法；同一个指标，在门诊和住院报表里的统计口径也可能不一样。这些问题如果没有前置的数据治理动作，就急着建平台、跑分析，结果只能是“垃圾进，垃圾出”。

从项目经验看，新建数据分析类项目，最早该做的不应该是选型，而是数据盘点。至少要把下面几件事摸清楚：

• 核心系统都有哪些，哪些数据是业务源头；
• 主数据，尤其是科室、人员、药品、耗材、收费项目，是谁在维护，口径是否统一；
• 患者主索引是否已经建立，能不能把多次就诊、不同系统里的同一患者关联起来；
• 目标指标的计算逻辑是否存在歧义，由哪个业务部门说了算；
• 数据更新频率和接口稳定性如何，有没有人工补录的情况。

这五件事，看起来不像技术问题，却决定了后续所有分析能不能站住脚。

我见过一个典型案例：某医院上线了运营分析系统，管理层发现某个科室的耗材占比异常高，后来核查发现，是耗材字典里存在重复编码，同一类耗材被不同部门录成了两个名称。最后只能重新治理字典。原因一点都不复杂，但因为没有提前做，整个项目被拖了小半年。

这个环节需要反复强调：数据治理不是一次性的项目收尾工作，而是贯穿整个数智化过程的基础能力。业务规则在变，系统在升级，人员也在流动，主数据会持续出现偏差。必须有人持续维护，而不是上线时清理一次就完事。

2.2 第二环节：流程智能，选对场景比铺开更重要

很多人把“数智赋能”等同于大数据分析或人工智能，但医院里真正能快速产生价值的，往往不是复杂的AI模型，而是把跨系统的业务流程串起来，让数据在流程节点之间自动流动。

医院天然是“系统割裂”的重灾区：HIS、LIS、RIS、EMR、手麻、药事、物资、财务系统各司其职，但很多业务却需要横跨多个系统。过去靠的是电话、口头沟通、纸质单据和人工搬运信息。现在数智化可以先从这些环节入手，因为它们的规则相对明确，收益也可以量化。

常见且适合优先改造的场景包括：

• 检查检验自动预约与排队调度：把不同设备、不同科室的资源统一进一个调度池，减少患者往返和现场排队；
• 住院床位集中管理：通过规则引擎，把入院、转科、出院状态实时联动，减少“有床没人住、有人没床睡”的结构性浪费；
• 手术排程优化：把术间、麻醉医生、手术护士、耗材准备等信息汇总，给出可执行的排程建议，而不是靠经验手排；
• 高值耗材全程追溯：通过条码或物联网设备，把采购、入库、使用、计费、结算串起来，减少遗失和错计。

这些场景的共同特点是：业务过程跨多个系统，存在清晰的规则，数据能够采集，而且最终效果可以被衡量。

但也要注意，不是所有流程都适合马上智能化。有些流程依赖人工判断成分很高，比如复杂病例的诊疗方案，不是靠系统自动决定；有些流程的线上条件还不成熟，比如某些操作环节根本没有数据采集手段，硬要自动化只会逼着业务人员“补录”。

所以在流程智能阶段，真正的关键工作是“选场景”。选得好，试点三个月就能看到变化；选得不好，项目变成另一个没人用的报表系统。选场景时，我通常会按四个条件过滤：第一，业务方有真实痛点；第二，数据相对完整；第三，规则可以描述清楚；第四，结果能用指标验证。四个条件缺一个，就先把问题放一放。

2.3 第三环节：决策支持，数据必须落到具体管理动作

数据治理和流程智能已经产生了很多数据，但最后一个环节最容易被忽视：如何让数据真正变成管理动作。

医院里最典型的表现是驾驶舱大屏。很多医院花了不少钱，在会议室门口装了一块大屏，上面滚动着门诊量、住院量、手术量、平均住院日、收入结构等指标。领导看着很直观，但接下去的问题往往是：如果平均住院日环比上升了，下一步怎么办？如果某个科室的药占比异常，谁去处理？

决策支持系统要回答的，不是“数据是多少”，而是“数据变化意味着什么”以及“应该做什么”。这需要从三个层面建设：

• 指标预警：设定阈值，异常时主动推送，而不是等人打开报表才发现；
• 归因下钻：异常指标可以一路拆到科室、病种、医生、环节，看问题出在哪一层；
• 行动追踪：干预措施下发后，跟踪一段时间内的指标变化，评估措施是否有效。

这个过程很像项目管理里的“计划—执行—检查—处理”循环。数据平台真正该承担的，是把医院管理从“月底看月报”变成“日常有反馈”。管理层不需要记住每一个数据，但需要知道哪几个指标异常、异常的原因可能是什么、该找哪个科室沟通。

这里有一个很容易踩的坑：把决策支持设计成“给领导看的系统”，而不是“让业务负责人产生行动的机制”。如果业务科主任从来不看数据，医务处长看完数据只会转发给信息科，系统就只是个电子海报。真正有效的做法，是把数据权限下放到具体岗位，让数据回流到工作流里。

3. 可复用的落地路径：从一个最小闭环开始

3.1 先回答四个问题，再考虑采购和开发

很多医院在推动数智化项目时，第一反应是写需求、找厂商、报预算。但需求通常写得很大，比如“建设全院数据中台”“实现智能管理决策”，真正落地时却不知道从哪下手。与其这样，不如在立项前先逼自己回答四个问题：

• 这个系统最终是给谁用的？是给院领导决策，还是给医务处日常管理，还是给科室主任改善流程？
• 希望通过这个系统改变什么具体行为？是提醒医生及时提交病案，还是减少患者检查等待，还是优化耗材申领流程？
• 当前数据能不能支撑这个目标？如果不能，缺口在哪？需要谁配合？
• 谁为最终业务结果负责？如果指标没有改善，是哪个部门要复盘？

这四个问题，本质上是在逼项目组把“上线系统”的思维，换成“改进业务”的思维。

之前有家医院找到我们，说要建一套“精细化运营系统”。聊下来发现，他们最大的痛点是手术室空闲时段太多，却没有统一排程。如果把目标换成“提升手术室时段利用率”，项目就变得非常具体：接入各科室手术申请，汇总麻醉和护理资源，实现排程建议。而不是一开始就奔着全院运营管理平台去。

很多项目最终失败，不是技术不行，而是问题定义太宽。数智化的价值不是系统本身，而是它能否帮一个组织，更准确地发现可优化的环节。如果问题定义不清，后面所有环节都会失真。

3.2 五步法建立第一个“数智闭环”

在具体推进时，我比较推荐从一个很小的场景切入，用五步法跑通第一个闭环：

第一步，选场景。选择一个小范围、科室愿意配合、效果可以量化的场景。范围宁可小，不要大。最好是一个科室、一条流程、一个指标。

第二步，定指标。明确当前基线和目标值。比如“门诊患者候检时间当前平均35分钟，目标降到25分钟”。没有基线的改善项目，后期根本说不清有没有效果。

第三步，拉数据。不追求大而全的数据接入，只要把目标指标需要的关键字段，从两三个源头系统里拉通即可。最怕一开始就想着把几十个系统全部接入，结果迟迟接不完。

第四步，跑流程。让业务方真正在线操作。这时候要观察的不是系统跑没跑通，而是业务人员有没有把系统当成日常工具，还是一个“填给别人看”的任务。

第五步，看收益。按周或按月复盘指标。如果目标达成，说明流程、数据、系统、组织都打通了；如果没达成，回到前面环节去排查，是场景选错、数据不准，还是业务根本没有使用。

这个闭环周期通常建议控制在三个月以内。时间太长，热情会被消耗，管理层也会失去耐心。

一个实际感受是：第一个闭环最关键的价值，不是产生多大收益，而是让团队形成一套方法——知道如何定义问题、如何用数据验证、如何推动业务配合。这套方法，比某个具体指标改善更宝贵。

3.3 试点跑通后，再做三件事

第一个闭环跑通后，最忌讳的就是立刻扩大范围，把全院所有场景都铺开。更稳妥的做法是先做三件事。

第一，把经验文档化。记录选场景的方法、数据口径、实施步骤、遇到的风险，以及最后是怎么解决的。这份文档不是为了汇报，而是为了让后面复制时不需要重新踩坑。

第二，把规则固化到系统里。比如指标口径、数据质量规则、预警阈值、流程节点的责任岗位，都写成可配置的规则，而不是写在PPT里。

第三，明确边界。一个场景在某个科室跑通，不代表所有科室都能照搬。不同科室的病种结构、工作习惯、数据基础都可能不同。推广时，每到一个新科室，都要重新验证个性化规则，不能强行用统一模板。

这一步其实是最难做到的。很多医院试点很成功，一推广就失败，原因就在于把“试点经验”当成了“标准答案”，忽略了推广对象有不同的起点。

4. 项目做崩了，通常不是败在技术，而是败在这条链路上

4.1 一条经过实践检验的排查顺序

当一个数智化项目推进不下去，或者系统上了却没人用时，很多团队会第一时间怀疑选型不对、厂商不好。但换厂商往往解决不了问题。更合理的做法，是按下面这条链路逐层排查：目标、数据、流程、系统、组织。

先看“目标”是否清晰。当初立项时，到底要解决什么问题？这个问题是不是可以被量化？有没有明确的业务负责人？我见过太多项目，立项时只说“建平台、做可视化”，却没有回答“建完之后谁用、用来做什么”。目标不清，后面的所有投入都会左右摇摆。

再看“数据”是否可靠。指标背后的数据有没有接全？统计口径是不是统一？有没有持续的数据质量维护机制？很多系统看起来什么都展示了，但数据来自Excel手工导入，这样的数据只能支持汇报，不能支持决策。

再看“流程”是否真的在线。业务人员是不是还在线下按老一套做事，系统只用来事后补录？还是新流程已经嵌入了日常操作？如果“系统里面一条线，现实世界另一条线”，那系统再强也只是一层包装。

再看“系统”是否闭环。接口是否稳定、状态是否同步、异常是否自动通知？很多系统在测试环境没问题，生产环境一跑就断，问题往往出在容错和运维上。

最后看“组织”是否配套。有没有岗位负责日常运营？有没有人定期看指标、组织复盘？数智化不是上线一个系统，它是工作方式的改变，没有组织机制去承接，最终一定会退回旧模式。

这条排查顺序之所以重要，是因为它把焦点从“技术问题”拉回到“管理问题”。大多数项目失败，先卡在目标不清，接着卡在数据不稳，然后卡在流程不真，最后卡在组织不接。换一家厂商，大概率只会把最后一层问题重新演一遍。

4.2 信息部门千万别把自己做成“背锅方”

在公立医院，信息科往往夹在管理层、业务科室和厂商之间。管理层问“系统为什么没成效”，业务科室说“系统不好用”，厂商说“需求一直在变”。信息科如果只会承接需求、转发问题，最后很容易变成所有矛盾的汇聚点。

更有效的定位，是让信息科成为“业务翻译者”和“数据架构师”。一方面，要帮助业务科室把管理诉求翻译成可落地的数据指标和流程规则；另一方面，要守住数据标准和架构边界，避免被临时需求带偏。

同时，必须让业务部门承担“使用者”甚至“项目负责人”的角色。医务处、护理部、财务处、后勤保障部门，不能只当甲方，他们必须认领指标、参与定义需求、评估使用效果。信息科可以负责技术实现，但绝不应该为“业务是否改善”单独买单。

一个常见的成功协作机制是：每个数智化项目都指定一个业务负责人和一个技术负责人。业务负责人回答“为什么做、做成什么样”，技术负责人回答“怎么做、怎么确保稳定”。有了双负责人，项目才不会在没人负责时无声烂尾。

4.3 上线不是终点，运维才是真正的长期主战场

很多医院把系统上线看作项目成功的标志。但真正的考验，是上线三个月后。

业务规则会变，科室人员会调整，接口上游系统会升级，指标口径需要持续维护。如果没有运维机制，系统会逐渐变得“不准、不好用、没人用”。数智化系统的长期价值，取决于有没有一个团队持续做数据治理、流程监控、问题响应和迭代优化。

这个团队不一定要很多人，但至少要有人管三件事：第一，数据质量告警，及时发现数据缺失、字段异常；第二，业务反馈通道，让临床和管理部门能提出问题，并快速确认优先级；第三，知识沉淀，把常见问题和解决办法记录成文档，避免人员流动后经验丢失。

从实践看，一个数智化项目的长期健康度，往往取决于上线后第一个季度的响应速度。如果问题能被快速修复，业务部门会逐渐信任系统，并愿意提出新需求；如果问题无人响应，系统很快会被弃用。

5. 适用边界与下一步：不是所有医院都要上“大而全”

5.1 先判断自己处在哪个阶段，再决定做什么

“数智赋能提质增效”听起来很美，但落到每家医院，起点和路径并不一样。如果忽略自身基础，盲目照搬先进医院的方案，很可能会水土不服。比较务实的做法是先判断自己处在哪个阶段。

第一类，系统互通还比较薄弱的医院。核心业务系统覆盖不全，或科室之间数据没有打通。这个阶段的重点不是谈智能分析，而是先把数据规范起来：建立科室和人员主数据，统一患者标识，把核心业务流程数据采集完整。没有这个底座，AI、数据中台都是空谈。

第二类，基础系统已有，但数据分散、指标不统一的医院。可以先建设运营数据中心或数据平台，但不要一开始追求所有系统全部接入。优先接入与目标场景最相关的几个系统，用一个小场景去做试点验证，积累经验后再扩展。

第三类，信息化相对成熟，已经有统一平台、数据质量和组织机制都到位的医院。可以考虑更复杂的应用，比如面向临床的知识辅助、基于机器学习的风险预测、全院级的资源配置优化等。但即使到这个阶段，也仍然要遵循“先选场景、再看收益”的原则。

把“数智赋能”理解成一个按需演进的过程，比理解为某一项技术产品更接近真实。不同医院之间的差异不是谁的系统贵，而是谁更清楚自己的下一块短板在哪里。

5.2 数据负责发现问题，人负责解释和决定

还有一个容易被忽略的边界：数智化不是替代管理，而是辅助管理。数据平台可以发现异常、提示风险、优化排程，但“这个异常为什么发生”和“要不要采取某种干预”，往往仍然需要人来判断。

举一个例子。系统提示某个科室的平均住院日连续三周上升。数据告诉你结果，但原因可能是新收治的病种变重了，可能是手术排程出现问题，也可能是数据统计口径发生了改变。这几种原因，靠数据很难直接分辨，必须由熟悉业务的人去现场核实。

所以，一个成熟的组织，应该建立这样一种分工：数据平台负责持续监测和预警，管理层负责解释原因和决定行动，执行层负责采取具体措施，再通过数据平台确认效果。机器读数据，人读现场。两者结合，才能形成真正的管理闭环。

这个边界想清楚了，就会避免两个极端：一个极端是迷信数据，认为报表上的一切就是真相；另一个极端是漠视数据，继续拍脑袋决策。数智化的最终价值，是让人的判断有据可依，而不是代替人的判断。

5.3 从报表到嵌入智能，再到预防式管理

放眼未来，公立医院的数智化演进通常会经历几个阶段。

第一代，更多是“流程线上化”。把挂号、开单、检查、收费等业务流程搬进系统，解决了“业务能不能被数据记录”的问题。

第二代，是“数据可视化”。把记录下来的数据汇成报表，让管理者知道医院发生了什么。但目前很多医院还停留在这个阶段，问题是如何进一步往前走。

第三代，是“智能嵌入日常流程”。当医生开医嘱时，系统会提示潜在的药物相互作用；当申请检查时，系统会根据预约资源和患者情况推荐最优时间；当耗材即将低于安全库存时，系统会提醒补货。这种嵌入式的智能，才让数据真正变成工作流的一部分。

第四代，是“预防式管理”。在更大范围的数据基础上，医院可以预判疾病流行、设备老化、人力缺口和资源配置瓶颈，提前采取措施，而不是等指标恶化了再介入。这个阶段需要的数据质量和算法能力都会更高，不是短期内所有医院都能做到。

但从长期看，数智化方向不会变：从“事后看报表”，走向“事中给提示”，再走向“事前做预防”。每一步，都应该以业务收益和可复用的数据资产为基础。

回到文章开头那个会场。如果当时有人听完报告，回来第一件事是问信息科“我们是不是也该上数据中台”或“要不要部署一个AI助手”，我会觉得这仍然走在从概念到概念的路上。我更建议先回答一个问题：你想通过数据，改变医院里的哪一个具体行为？

找到那个行为，用一个小场景、一个小数据集合、一个小闭环去验证。跑通一个，再复制到相关的场景。这个过程比参加十场论坛、引进十个系统更枯燥，也更容易被忽视，但它才是“数智赋能提质增效”真正的起点。

公立医院高质量发展语境下的数智化，最终需要穿越的，不是技术表演，而是组织惯性。技术提供可能性，组织负责把它变成现实。那些能跑通闭环的医院，不一定拥有最贵的平台，但一定拥有一种真正的共识：数据不是用来汇报的，而是用来做决策的。有了这个共识，系统才会被用起来，数据才会越养越准，效率和质量才会在一次次小闭环里悄悄改善。