从“全院多库”到“全院一库”的探索

发布时间:2025-04-17
浏览次数:

  近日,AI开源开出了Deepseek,数据更是成为智慧之源、智能之环。这是一个需要不断转型与进阶的时代。数据已变得越来越重要!但是医院的数据从何而来,却大都是来自各个信息系统的数据库。这种交织混合的复杂关系剪不断理还乱,带来许多数据应用服务的困扰和被动。

  数智化时代的到来让人们开始意识到:这些原本默默运转的系统数据库中,潜藏着巨大的数据价值。对数据的渴求迅速膨胀,推动医院信息化从“业务支撑”迈向“数据驱动”的深度变革。这既是机会也是挑战,就看我们能不能把握住这个发展机会,它应该是承前启后、轻松转型之路,也是避免空心化、走向数据系统自主可控的现实之路。

  今天,我们试着以新的视角来对照研究数据和信息的属性、关系、体系建设,旨在探索从信息系统走向数据系统的便捷之路。换句话说,我们真正需要什么样的数据系统以及支撑可持续发展所需要什么样的数据基座?如果说之前我们主要关注信息系统的功能,那么现在我们重点考虑信息系统的数据库效能了。

  首先,我们已经看到基于业务系统的数据库基础条件不是为数据系统应用设计的,因此数据应用必然会面临基础性制约和天花板限制;其次,由于传统数据库性能不足,面对每一类数据服务大都需要做一次数据仓库准备。诸如此类问题,从长远来看都需要系统性解决了。本质上从信息系统到数据系统再到AI系统,是一脉相承彻底融汇融合的过程,因此系统性规划与建设数据系统的基础与应用服务就变得十分重要。

  其实技术发展的今天,从信息系统到数据系统也可以很简单:

  1.与信息系统的流程差异化明显不同,数据系统应用大都是基于数据“查询、统计、插入”的过程,因此数据系统应用服务的过程都是相似的、具有一定的标准化过程。那么,我们只要建设好全面而迅捷的“数据基座”就基本可以了。

  2.针对数据基座,我们可以实现从“全院多库”到“全院一库”的汇聚迁移和梳理、并保证“全院一库”的数据基座具有“全、快、易”的功能性能条件,这样我们就可以迅捷实现从信息系统到数据系统的成功转型,按需即席数据利用,简单而可行。

  医疗信息化的进程中“全院多库”是合理的,全院多系统以横向低耦合架构支撑了医院核心业务流程的快速数字化,同时还避免了早期技术瓶颈引发的系统性风险。但是,当下全量各类数据需要深度融合应用、AI应用等场景对数据的要求是“全院实时”,这就暴露分散架构的“副作用”,历史优势成为眼前制约。因此,从“全院多库”到“全院一库”是面向未来医疗,以“驱动智能的数据战略基座”赋能医疗数据价值从“流程支撑”向“数据服务”跃进的必要性建设;而从“数据基座”入手、实现“全院一库”模式,不失为一种必要而可行的建设方案。

  “全院多库”局面,源于全院信息系统的多系统、多厂家建设历史

  1.为何不能是一个厂家做全院系统?

  医疗业务的强专业性和学科细分属性,决定了不可能由一家IT公司去承建医院所有的信息化系统建设。临床、检验、医技检查、药事、管理等数十个业务领域对信息系统的功能需求差异显著,单一厂商难以在多个领域中同时具备技术优势。同时,政策的频繁调整和医疗需求的不断变化,系统需要不断地升级迭代和改造,单一厂商难以同时满足所有系统的敏捷开发与优化需求服务。

  2. “全院多库”是医院多系统支撑医院信息化的自然选择和必然结果,彰显独特而有效

  正是这种多厂家、多系统的共建方式,让医院信息化在过去二十年走得快、铺得开,也跑得稳。但随着数据价值的不断显现,我们也逐渐看见了这种架构在“连接”和“融合”上的天然限制。医院历史上的信息化建设都是以“业务系统建设”为主的局面,不同系统因功能需要选择差异化的数据库架构(如Oracle、MySql、SQL server 、DB2、Caché...),形成“一个业务系统一个数据库”的分散模式(我们统称为“全院多库”)。这样的“全院多库”模式在以业务为中心的信息系统建设过程中是追求效率与稳定性的必然选择,多系统、多数据库的体系更容易维护、升级和扩展,更好灵活满足医院快速需求更新,是医院发展阶段中普遍存在的局面,本质是医疗行业精细化发展的必然结果。

  多库架构曾是最务实的选择。但时代正在进步,当医院想要的不再只是“跑得动、跑的稳”,而是“看得全、联得上、用得快”,按需即席利用数据,那些曾经的合理性也开始逐步显露出局限性。

  新时期发展追求释放数据价值,考验的是全院数据基座的功能与效能

  1.信息系统与数据系统,其“数据基座”的需求侧重点是不同的

  医院信息化建设发展走到今天,诞生许多业务生产源数据,这些全院数据价值的释放,是潜力巨大的“宝藏”。而AI应用不断深化所需的数据服务,在面向临床、科研、运营、管理的数据二次利用需求,绝大多数都是对全院数据的查询需求。这里的数据基座“存、管、用”都要谋求简单化、高速易用。在“全”和“快”两个问题面前,这时发现“全院多库”数据基座成为制约,体现为跨库查询和效率问题难以支撑全院数据按需快速分析与实时计算,无法满足搭建“全快易”数据系统的条件。

  这也提醒我们,曾经为医院发展打下坚实基础的“多库模式”,在今天未必还能承担起“数据驱动未来”的重任,“按需即席式”全量数据的迅捷响应成为标准。如果我们不尽快完成从“流程配合”到“数据服务”的认知转型,就可能在数字时代的浪潮中,被过去的合理性束缚住未来的可能性。

  2.怎样实现最大化、可持续性发展数据驱动?

  说到底,医院的信息化建设从最初到现在,确实已经打下了不错的基础,但大多数业务系统其实都是“为业务而建”,彼此之间独立运转,数据也是在跨表查询和大表查询方面面临巨大困难。

  在流程化的时代,这种“全院多库”架构确实跑得起来,也支撑了医院多年来高效的业务运转。但当我们真正想用数据去支撑决策、优化流程、提升管理时,就会发现——系统各忙各的,数据就像散落在各处的拼图,看起来啥都有,但每次想拼成完整一张图,都得一块一块慢慢找,这时候很多医院才开始意识到:信息化不仅要能跑业务,更要能用数据,这也是如今越来越多医院开始寻求数据中台、数据治理的原因。

  要想彻底释放AI新质生产力,实现数据价值最大化,需要从底层重构技术架构,将数据系统与业务系统解耦。首先就是要建立独立统一的“全院数据系统”,将全院业务系统的数据1:1汇聚到一个统一的“一库模式”中来,并且算力性能还要满足对数据快速、全面获取的需求。这样独立的数据系统建设,很多医院是薄弱的甚至是欠缺的。

  数据系统多种建设模式的对比

  过去医院信息系统的核心使命是“流程电子化”——通过HIS、PACS、LIS等系统固化业务流程,其数据架构本质是为“功能服务”。而智能医疗时代的数据系统需以“数据服务”为核心目标——让数据主动驱动医院全方位多维度的智慧发展。从流程支撑到数据服务是医院数据系统的范式变革,要实现这样的变革可选的方式有两大类:

  1. 局部数据仓库的数据系统建设模式:以数据仓库、数据湖、湖仓一体为代表,做法核心是通过ETL工具归集数据并预设主题模型。

  ● 优势:短期内可具有强针对性地满足部分数据服务场景的需求。

  ● 不足:缺失敏捷性,新增一个应用主题就需重构模型,复杂难执行,响应周期长达数月,重复性的建模工作耗时耗力;受到传统数据技术的制约,难以平衡数据汇聚要求越全越好及数据使用要求越快越好的矛盾。

  2. 全院全量数据汇聚的“全院一库”建设模式:基于高压缩内存计算技术、视图动态建模等技术,构建全院全量数据基座,其核心突破为:

  ● 内存计算架构:高压缩内存,兼顾数据量和响应效率的突破,免去硬盘I/O瓶颈,实现亿级数据关联分析秒级响应。

  ● 存算一体设计:基于内存计算引擎实现全量数据汇聚到统一平台,让数据“存、管、用”都简单化,省略了传统架构需组合多技术组件(如Hadoop+Spark+OLAP),让操作和运维复杂度得以大幅度降低。

  ● 动态建模能力:支持以视图自主建模,突破“预置式响应”转向“需求定义即服务交付”的模式,不再需要静态“数据快照”,也不再需要中间表加工,直接从原始数据池实时响应,将需求响应周期从小时级缩短至分钟级,实现“全、快、易”的新体验。

  “全院一库”模式更加符合当前医院场景对全院数据调度和使用的灵活和高效的要求,数据系统的建设不再预设模型,而是通过无损归集实现数据价值留存——全院沉淀原始数据,支持无限次回溯分析,具有更强大灵活的可扩展性。

  3. “全院一库”是统一性和效率性的兼顾

  从“全院多库”到“全院一库”,本质是医疗信息化从“业务流程化”向“数据资产化”的战略升维。这并非推翻既有成果,而是以统一数据基座激活冻结在孤岛中的“全量相关数据”,使其转化为医疗质量提升的核心生产资料——让数据流穿透系统壁垒,驱动诊疗、管理、科研迈向“需求即响应”的智能时代,最终形成“数据-业务互为反哺的双螺旋增长”新范式。

  从系统演进可行性角度分析,信息系统向数据系统转型已具备了简单化、标准化实施路径。数据系统的核心特征在于模块化的数据服务能力,无论是科研专病分析、数据上报、运营管理还是医保智能核查等场景,本质上均构建于数据基础操作层之上——即标准化的数据查询、统计、插入功能。基于此特征,数据系统应用服务呈现出显著的可复用性与流程相似性,那么,我们只要建设好全面而迅捷的“数据基座”就基本可以了,各类应用都可以按需即席、方便快捷。有了这样的数据基座,数据应用服务也就基本上有了。

  相关阅读:

  1.私有部署的DeepSeek,怎样敏捷调用医院全量数据?这里隐含着一个大问题!

  2.基于“AI一库”,DeepSeek就可以敏捷调用医院的全量数据!

  3.DeepSeek结合数据的高级应用,首先的挑战是大表和跨库查询!

  (本文由天助盈通供稿)