2. 医院运营数据平台总体架构设计

医院运营数据平台不是把HIS、电子病历、财务、人事等系统的数据简单堆到一个数据库里，而是要通过一套清晰的分层架构，把分散在各业务系统中的原始数据，逐层加工成可复用、可治理、可服务的数据资产，最终支撑运营分析、绩效评价、资源调度和领导决策。理解这套分层架构，是后续数据集成、建模、指标开发和平台运维的基础。

本节采用五层架构来组织平台：数据源层、数据集成层、数据存储层、数据服务层、应用层。这五层不是简单的技术堆叠，而是一条从“原始业务数据”到“运营决策价值”的加工链路。每一层都有明确的职责边界、核心组件和输入输出，层与层之间通过标准接口衔接，避免跨层直连和职责混乱。

各层职责与核心组件

数据源层是平台的输入起点，覆盖医院内部主要业务系统和外部数据。典型对象包括HIS中的挂号、收费、医嘱、住院记录，EMR中的病历文书，LIS/PACS的检验检查结果，财务系统的收入、成本、预算数据，人事系统的排班与人员信息，以及医保结算、区域卫生平台等外部接口数据。这一层的关键不是“接多少系统”，而是明确每个数据源的数据责任部门、更新频率、主键规则和可获取方式。例如HIS收费数据通常按分钟级增量产生，而财务月结数据按月批量提供，二者在集成策略上必须区别对待。

数据集成层承担“把数据搬进来并变干净”的任务。核心组件包括ETL/ELT引擎、CDC增量捕获、数据质量校验、主数据与编码映射、任务调度与监控。实际建设中，最容易被低估的是编码映射：同一个科室在HIS、财务、人事系统中可能有三套编码，同一个收费项目在不同系统中名称不一致。集成层必须建立统一的科室字典、人员字典、收费项目字典和指标口径字典，否则后续所有分析都会出现“同名不同义、同义不同名”的问题。数据质量校验则要设置非空率、主外键一致性、值域范围、重复率等规则，对不合格数据打标并阻断或告警。

数据存储层是平台的数据资产核心，通常按ODS、DWD、DWS、ADS四层组织。ODS贴源层保留原始快照，便于追溯和重跑；DWD明细层完成清洗、去重、标准化和维度关联，形成干净的业务明细事实；DWS汇总层按主题域构建宽表和轻度汇总，例如“门诊就诊主题”“住院费用主题”“人力资源主题”；ADS应用层直接面向指标结果，存放已计算好的运营指标表。此外，元数据与数据字典贯穿各层，记录表结构、字段含义、数据血缘和更新周期，是平台可维护、可审计的关键。

数据服务层把存储层的数据资产封装成统一、安全、可复用的服务。核心组件包括指标查询API、数据订阅与推送、权限与脱敏服务、缓存与查询加速、服务注册与网关。这一层要解决三个实际问题：一是口径统一，所有应用通过同一指标服务取数，避免各系统各算一套；二是权限可控，按角色、科室、数据敏感级别控制访问范围，患者身份信息需脱敏；三是性能可保障，对高频查询指标做预计算和缓存，避免直接压垮存储层。

应用层是价值出口，面向院领导、运营管理部门、临床科室和外部机构提供运营驾驶舱、绩效与成本分析、门诊住院监测、资源调度与预警、对外报送与共享等应用。应用层不直接访问底层数据库，而是通过数据服务层获取数据，从而保证口径一致、权限统一、变更可控。

层间交互关系与设计要点

五层之间的交互遵循“逐层加工、单向依赖、服务化访问”原则。数据源层到数据集成层是抽取与采集关系；数据集成层到数据存储层是加载与分层写入关系；数据存储层到数据服务层是发布与注册关系；数据服务层到应用层是调用与消费关系。反向来看，应用层不应绕过服务层直接查库，存储层也不应反向修改集成层数据，否则架构会迅速退化为难以治理的“烟囱式”系统。

在实际落地中，还需要注意几个关键设计点。第一，批流结合：收费、挂号等高频数据可采用CDC准实时入仓，财务、人事等低频数据采用批量抽取，二者在ODS层统一落地。第二，分层不跨层：DWD层只依赖ODS层，DWS层只依赖DWD层，ADS层只依赖DWS层，避免跨层引用导致血缘混乱。第三，指标即服务：每个运营指标在ADS层有唯一结果表，在服务层有唯一API，在应用层有统一展示口径。第四，可观测性：对每层设置数据量、延迟、质量、任务成功率等监控指标，例如ODS层关注抽取延迟，DWD层关注清洗通过率，ADS层关注指标产出及时率。

总体来看，五层架构的价值在于把复杂的数据加工过程拆解为职责清晰、接口标准的层次，使医院运营数据平台既能支撑当前的分析需求，也能在数据源增加、指标扩展、应用丰富时保持可维护和可扩展。掌握这套分层逻辑，是后续开展数据集成、数仓建模、指标开发和服务治理的前提。