医院的信息化建设，从早期的信息系统堆叠，到以电子病历为核心的业务数字化，再到今天的智慧医院数智化体系，架构范式经历了明显的升级。这个领域的分量，先看一个数字：医疗信息化应用市场规模预计在2027年突破两千亿元。想看懂一家医院的信息化水平，不必逐一查看系统列表，从架构入手即可，架构决定了数据能否互通、业务能否协同、AI能否落地。厂商科普和同行交流时，常用一套通俗的架构语言：七大系统、五大主索引、四大数据中心、四大中台、四大数据概念。医院信息化架构可以划分为五个板块，自下而上依次是业务、数据关联、存储、数据底座、能力：板块 | 组成 | 一句话定位 |
业务层 | 七大系统（PRM、EMR、CIS、HIS、DSS、区域协同、MIS） | 医院业务运行的一线系统 |
数据关联层 | 五大主索引（病人、医嘱、工作人员、资产、科室） | 数据的唯一标识，实现跨系统对应 |
存储层 | 四大数据中心 | 数据放在哪 |
数据底座 | 四大数据概念（数据仓库、数据湖、湖仓一体、数据中台） | 用什么架构存 |
能力层 | 四大中台（数据、AI、技术、业务） | 从数据存储到能力复用 |
各层的关系是递进的：业务层产生数据，主索引实现数据的跨系统对应，数据中心完成数据存储，数据底座决定存储架构，中台让数据变成可复用的能力，AI应用在能力之上生长。其中存储层回答数据放在哪（数据中心），数据底座回答用什么架构存（仓库、湖、湖仓一体），两者是物理组织和技术选型的关系。下文逐层展开。行业里还有一种更工程化的分法：三层架构。基础设施层承载网络、计算、存储，平台层承载集成平台、数据中心，应用层承载各类业务系统。这套分法与卫健委官方标准的"业务应用、信息平台、基础设施"几乎一一对应。三种视角合起来看更完整：行业通说的五板块描述医院信息系统的构成，三层架构说明系统的分层关系，官方标准规范建设要求。七大系统是医院业务运行的一线系统，支撑所有医、护、患、管核心业务。它们的业务功能划分基本稳定，不管架构怎么升级，挂号、收费、病历这些功能始终要有系统承载；变化的是技术形态，传统单体HIS正被重构为微服务架构。系统 | 全称 | 核心职能 |
PRM | 患者关系管理系统（Patient Relationship Management，也称患者服务平台） | 预约、随访、患者服务 |
EMR | 电子病历系统（Electronic Medical Record） | 结构化病历、医嘱、临床决策支持、临床路径 |
CIS | 临床信息系统（Clinical Information System） | LIS、PACS、RIS、护理、手术麻醉、ICU |
HIS | 医院信息系统（Hospital Information System） | 收费、药品物资、医保结算、医嘱闭环 |
DSS | 决策支持系统（管理侧，即商业智能BI） | 绩效、成本核算、运营驾驶舱、预测分析 |
区域协同 | 区域协同系统（区域卫生信息平台） | 检查互认、双向转诊、区域质控、远程会诊 |
MIS | 管理信息系统（Management Information System） | OA、人事、科研、资产、综合运营 |
说明：各家医院对系统边界的划分并不完全一致，例如挂号功能有的医院置于PRM、有的置于HIS，区域协同系统严格说是区域平台，部分医院不把它算作院内系统。表格为行业典型划分，用于理解结构，无需逐项对应。七大系统可以分成三组。核心业务组（EMR、CIS、HIS）决定医疗业务能否正常运行，是全院变更风险很高的存量资产；运营支撑组（DSS、MIS）随管理要求调整，DRG/DIP落地之后，这两套系统的增量需求反而最活跃；连接层（PRM和区域协同）一端连接患者、一端连接区域，是医院对外协作的窗口。主索引解决一个非常实际的问题：同一个人的数据，在不同系统里无法对应。同一个患者，挂号系统里是编号A001，检验系统里是B002，住院系统里又是另一个编号，没有主索引，这些数据就无法归并为同一患者的完整记录。主索引 | 作用 |
病人主索引（MPI/PMI） | 患者的电子身份证，一人一号、终身唯一，避免重复建档；跨院区、跨机构场景扩展为企业级患者主索引（EMPI） |
医嘱主索引 | 统一医嘱的唯一标识，关联临床和执行记录 |
工作人员主索引 | 医生、护士等人员的统一身份，关联执业记录 |
资产主索引 | 设备、耗材等资产的统一标识，关联全生命周期 |
科室主索引 | 科室的统一编码，关联业务和成本核算 |
病人主索引是其中最核心的一个。一个人从挂号、门诊、住院到随访，所有记录依靠它串联为完整的个人健康档案；有了它，患者的历史就诊、过敏史、既往检查才能一键调出。主索引与数据治理、主数据管理（MDM）深度绑定，是中台建设的基础要素。四大数据中心代表医院信息化建设从系统建设走向数据集中阶段的思路：先将数据集中存储。它强调集中和汇聚，但缺少治理和复用能力。数据中心 | 内容 |
临床数据中心（CDR） | 诊疗数据的大仓库 |
管理数据中心 | 运营、绩效、财务等管理数据池 |
影像数据中心 | 影像等非结构化数据，占医院存储的主要部分 |
区域数据中心 | 跨院区、医联体的数据共享中心 |
这个阶段典型的痛点是：数据可存储但利用率低，数据中心越建越多、数据越积越乱，分析周期长，难以支撑AI与实时智能。数据中心解决的是数据的存储位置，它把散落在各系统的数据汇聚到一处，但汇聚之后如何治理、如何使用，是能力层中台要回答的问题。中台的出现，是为了解决传统数据中心孤岛、封闭、缓慢、难以复用的问题。它把数据、算法、技术、业务规则沉淀为共享能力，供前端系统按需调用。中台 | 定位 | 能力 |
数据中台 | 最先落地的中台核心 | 全域数据采集、治理、清洗、标准化、主数据管理、指标体系、数据API |
AI中台 | 智慧医院的大脑工厂 | 模型训练与管理、医疗大模型微调、影像AI/病历AI服务化 |
技术中台 | 系统复用的技术底座 | 云原生、微服务、API网关、统一权限、低代码平台、工作流引擎 |
业务中台 | 集团化医院的共享业务层 | 统一患者视图、统一医嘱规则、统一支付结算、统一质控 |
数据中台通常最先建设，没有干净、标准化的数据，其他中台都难以发挥作用；AI中台是数据治理到位之后的能力升级，把数据转化为算法；技术中台解决一个应用一套技术栈的重复建设；业务中台则是大型集团医院、双院区医院才会独立设置，把跨院区通用的业务能力沉淀下来。医院数据量急剧增加，非结构化数据占比超过八成，数据底座的选择决定了上层能力的上限。当前医院大数据平台常见四种架构模型，其中数据中台同时出现在上一个板块，因为它是能力层和数据底座的交叉点：架构 | 比喻 | 特点 |
数据仓库（DWH） | 精品冰箱 | 强治理、强结构，适合绩效运营分析；建设成本高、扩展性差、不适合AI |
数据湖（Data Lake） | 大湖泊 | 存储成本低、容量大，可存影像日志文本；易变成无人治理的数据沼泽 |
湖仓一体（Lakehouse） | 冰箱加湖泊 | 低成本存储加高性能分析，支持AI和流数据，当前重要演进方向 |
数据中台 | 中央厨房 | 负责治理、指标、主数据，与湖仓一体深度结合 |
医院数据的体量，可以从影像数据窥见：一次胸部CT的原始数据约350MB，一家年检查量十万次的三甲医院，仅CT一项一年就要新增约35TB。传统数据仓库在容量与性能上难以支撑这种体量的非结构化数据，这正是数据湖和湖仓一体出现的原因，既要满足存储容量，又要满足分析性能。湖仓一体使用Delta、Iceberg、Hudi等开源格式，同时支持结构化、非结构化、流数据，是当前医院大数据平台的重要演进方向。把五个板块串联起来，就是医院信息化架构演进的一条主线：七大系统完成业务全面数字化；五大主索引让数据可关联、可共享；四大数据中心实现数据集中，但尚未形成应用能力；数据中台把数据变成可复用的能力；AI中台让数据真正转化为算法和智能；技术中台和业务中台支撑系统快速迭代；湖仓一体为AI时代的数据增长和实时分析打下底座。一句话总结：系统数字化，数据集中化，能力平台化，数智化。演进仍在继续。2024年以来，行业里最受关注的新架构方向是微服务云原生HIS/EMR一体化：将传统单体HIS重构为微服务架构，同步完成信创适配，以医疗大数据平台和AI医疗中台为双翼。传统HIS的生命周期还有多长，是信息科近两年无法回避的问题。对医院来说，老架构的维护和新架构的迁移将并行多年，看懂架构，才能判断何时启动迁移、向何种架构演进。架构是医院的骨架，数据是血液，AI是大脑。看懂骨架，才能看清医院信息化还能走多远。
免责声明：
智慧医疗网转载其他网站内容，出于传递更多信息而非盈利之目的，内容仅供参考。版权归原作者所有，若有侵权，请联系我们删除。
本平台所发布信息的内容和准确性由提供消息的原单位或组织独立承担完全责任!
凡来源注明智慧医疗网的内容为智慧医疗网原创，转载需获授权。
