尧图网页设计 
近期医疗信息化圈子里中国卫生经济学会公立医院高质量发展分会学术年会是一个比较受关注的话题。会议主题里的“数智赋能、提质增效”这八个字看起来是管理层面的表达但落到技术侧其实对应的就是一套非常具体的工程能力医院那么多业务系统HIS、LIS、PACS、EMR、HRP数据怎么统一采集门诊收入、次均费用、床位使用率、药占比这些指标怎么保证每个科室算出来的口径一致领导要看运营日报能不能当天自动出数对于长期做医院信息化、智慧医疗项目的开发者来说这些问题基本都遇到过。网上关于“数据中台”的资料很多但针对医院场景的完整闭环案例很少。本文以“数智赋能、提质增效”为背景梳理一套从数据接入、数据治理、指标计算到对外API发布和可视化的实战方案。内容偏工程落地既有设计思路也有可以直接参考的SQL、Java代码和排查清单适合医疗信息化开发工程师、数据平台开发者和准备进入智慧医疗方向的同学。1. 数智赋能在医院信息化中的技术含义1.1 医院数据建设的现状大多数医院经过多年信息化建设都会形成“业务系统多、厂商多、数据库多、口径多”的局面。临床业务系统HIS医院信息系统、LIS检验信息系统、PACS影像归档与通信系统、EMR电子病历系统。运营管理系统HRP医院资源规划、财务系统、绩效系统、后勤管理系统。数据来源复杂有的数据库是 Oracle有的是 SQL Server还有一部分是 MySQL甚至少数老旧系统还通过 Excel 导出上报。这些系统各自都在产生数据但系统之间的数据标准不统一。同一个“门诊收入”财务系统按收费日期统计HIS 可能按就诊日期统计绩效系统又可能按结算日期统计。如果不做统一管理报表出来以后各科室互相质疑最后只能靠信息科手工核对效率非常低。1.2 数智赋能的技术落地路径“数智赋能”落到具体技术方案通常包含三层意思第一层是数据采集与集成。通过 ETL 工具或数据同步中间件把分散在各业务系统的数据周期性地抽取到统一的数据平台解决“数据孤岛”问题。第二层是数据治理与标准化。建立统一的病人主索引、科室编码字典、指标字典让所有系统在同一个口径下描述业务。这一步解决的是“数据不准、口径不一”的问题。第三层是数据应用与服务。基于治理后的数据计算门诊、住院、财务、人力等维度的运营指标通过 BI 报表、领导驾驶舱、数据服务接口等方式把数据价值返回给管理者和业务科室最终体现为管理效率的提升和运营成本的下降。简单说“数智赋能”不是引入一个大数据平台就结束而是要让数据在采集、治理、计算、服务这条链路上“跑得通、算得准、看得到、用得上”。1.3 数据中台与数据仓库的边界做医院数据平台时很多团队会把数据仓库和数据中台混在一起。这里简单区分一下数据仓库偏重于“存储与计算”核心是把历史数据按主题组织起来支撑报表和分析。它的服务对象主要是数据分析师和管理层。数据中台则在数据仓库之上更强调“服务复用”。它不仅提供报表还要把公共的数据能力抽象成 API比如科室运营指标查询接口、患者就诊趋势接口让 HIS、OA、绩效系统在后续开发时可以直接调用。在实际项目中不需要把两者对立起来。大多数医院级数据平台是“先建数仓分层模型再在中台层沉淀指标服务和数据 API”。本文后面的实战案例也采用这种思路。2. 环境准备与项目规划2.1 技术选型医院级数据平台不建议一上来就引入非常重的组件。很多地市级医院的信息科人员配置有限日常还要保障核心业务系统稳定所以技术选型要兼顾可维护性和成本。下面是一套比较稳的组合数据库MySQL 8.x用于元数据管理、指标字典存储。数据同步Apache DataX用于从 Oracle、SQL Server、MySQL 等数据源同步数据。调度引擎DolphinScheduler 或简单的 XXL-JOB用于定时执行同步任务和指标计算任务。应用服务Spring Boot 2.7.x MyBatis Plus用于提供指标查询 API。可视化Superset 或帆软 FineBI用于制作运营大屏和填报式报表。缓存Redis可选用于高频指标查询的缓存加速。版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路不是固定模板。2.2 环境清单操作系统CentOS 7.9 或 Ubuntu 20.04Windows 也可以跑通示例 JDK1.8 或 11 MySQL8.0 Spring Boot2.7.x DataX3.0开源版 DolphinScheduler3.x强调一点正式生产环境使用 DataX 或调度组件前先在测试环境完整验证。医院核心库是生产系统直接连源库做同步存在性能风险需要在数据库侧做只读账号、限流或从库同步方案。2.3 项目目录规划为了便于维护建议把整个数据平台工程拆成多个子模块而不是写到一个大项目里。hospital-data-platform ├── docs # 设计文档、指标口径说明 ├── db # 建表 SQL、初始化数据 │ ├── ods # 贴源层表结构 │ ├── dwd # 明细层表结构 │ ├── dim # 维度表结构 │ └── ads # 应用层表结构 ├── sync-job # 数据同步任务DataX JSON、Shell 脚本 ├── indicator-service # 指标服务Spring Boot 工程 │ ├── src/main/java │ └── src/main/resources └── sql # 指标计算 SQL、存储过程可选如果团队规模不大也可以先把 sync-job 和 indicator-service 合并成一个工程但表结构脚本一定要独立维护因为数据模型的变更频率远低于代码。3. 医院运营数据模型设计3.1 分层设计思路数据平台一般按 ODS、DWD、DIM、ADS 四层划分ODS贴源层同步源系统原始数据不做过多的清洗保留历史快照。DWD明细层对 ODS 数据做标准化加工统一编码、去重、清洗生成业务明细数据。DIM维度层科室维度、医生维度、时间维度、病人主索引等公共维度表。ADS应用层面向具体业务场景的汇总表比如门诊运营日汇总、住院运营日汇总、财务指标月汇总。分层的意义在于每层职责单一出现问题可以快速定位是在同步阶段、清洗阶段还是汇总阶段。3.2 核心表结构示例先看一张最核心的科室维度表-- 文件路径db/dim/dim_dept.sql CREATE TABLE dim_dept ( dept_id BIGINT NOT NULL COMMENT 科室ID, dept_code VARCHAR(64) NOT NULL COMMENT 科室编码, dept_name VARCHAR(128) NOT NULL COMMENT 科室名称, parent_dept_id BIGINT DEFAULT NULL COMMENT 上级科室ID, dept_type VARCHAR(32) COMMENT 科室类型临床/医技/行政/后勤, is_active TINYINT DEFAULT 1 COMMENT 是否有效1有效0无效, source_system VARCHAR(32) COMMENT 来源系统HIS/LIS/PACS/HRP, etl_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 同步时间, PRIMARY KEY (dept_id), UNIQUE KEY uk_dept_code (dept_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT科室维度表;这里要注意 dept_code 需要做唯一约束因为不同系统可能使用不同的科室编码后续通过映射表统一。再建一张 ODS 层的门诊挂号记录表模拟从 HIS 同步过来的原始数据-- 文件路径db/ods/ods_his_register.sql CREATE TABLE ods_his_register ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 自增ID, patient_id VARCHAR(64) NOT NULL COMMENT 患者ID, visit_no VARCHAR(64) NOT NULL COMMENT 就诊流水号, dept_code VARCHAR(64) COMMENT 科室编码源系统, doctor_code VARCHAR(64) COMMENT 医生编码源系统, register_time DATETIME COMMENT 挂号时间, register_fee DECIMAL(10,2) COMMENT 挂号费, visit_type VARCHAR(16) COMMENT 就诊类型门诊/急诊/住院, source_system VARCHAR(32) COMMENT 来源系统, sync_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 同步时间, PRIMARY KEY (id), KEY idx_visit_no (visit_no), KEY idx_register_time (register_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT门诊挂号记录ODS表;之后是 DWD 层的标准化明细表。DWD 表一般会冗余科室维度、医生维度字段避免指标查询时多次关联维度表-- 文件路径db/dwd/dwd_outpatient_visit.sql CREATE TABLE dwd_outpatient_visit ( visit_date DATE NOT NULL COMMENT 就诊日期, visit_no VARCHAR(64) NOT NULL COMMENT 就诊流水号, patient_id VARCHAR(64) NOT NULL COMMENT 患者ID脱敏后, dept_id BIGINT COMMENT 科室ID标准维度ID, doctor_id BIGINT COMMENT 医生ID标准维度ID, visit_type VARCHAR(16) COMMENT 就诊类型, register_fee DECIMAL(10,2) COMMENT 挂号费, settlement_amount DECIMAL(10,2) COMMENT 结算金额, is_valid TINYINT DEFAULT 1 COMMENT 是否有效就诊, etl_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT ETL时间, PRIMARY KEY (visit_date, visit_no), KEY idx_dept_id (dept_id), KEY idx_visit_date (visit_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT门诊就诊明细DWD表;最后是 ADS 层日汇总表直接服务指标查询-- 文件路径db/ads/ads_outpatient_daily.sql CREATE TABLE ads_outpatient_daily ( stat_date DATE NOT NULL COMMENT 统计日期, dept_id BIGINT NOT NULL COMMENT 科室ID, visit_count INT DEFAULT 0 COMMENT 就诊人次, register_fee_sum DECIMAL(12,2) DEFAULT 0 COMMENT 挂号费总额, settlement_sum DECIMAL(12,2) DEFAULT 0 COMMENT 结算金额总额, average_fee DECIMAL(12,2) DEFAULT 0 COMMENT 次均费用, medicine_ratio DECIMAL(5,4) DEFAULT 0 COMMENT 药占比测试口径, etl_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 统计时间, PRIMARY KEY (stat_date, dept_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT门诊运营指标日汇总表;需要说明的是这里的药占比、次均费用等字段只是演示使用。真实医院的口径往往由财务和医务部门定义不同医院可能完全不同开发时必须以本院最终确认的口径文档为准。4. 数据接入与同步实战4.1 同步策略选择医院业务系统对实时性要求不同。挂号、收费这类操作如果做实时同步往往需要接入消息队列和 CDC变更数据捕获组件复杂度较高。而运营指标分析通常不要求秒级实时一般按小时或者 T1 同步即可。建议同步策略日结类数据每天凌晨同步前一天全量变更数据。维度数据每晚同步一次变更频率低。实时性要求高的场景通过接口或消息队列对接而不是直接对源库做频繁轮询。首次上线时建议先做一次全量初始化之后切换到增量同步。增量同步最稳妥的字段是“更新时间”和“创建时间”前提是源系统这些字段维护得比较规范。4.2 使用 DataX 同步示例DataX 是常用的异构数据源离线同步工具。假设要从 Oracle 的 HIS 库读取前一天数据写入 MySQL 的 ODS 表可以配置一个 DataX job。由于不同医院的表名称和字段差异很大这里给出一个简化 JSON 示例核心思路是通用的{ job: { content: [ { reader: { name: oraclereader, parameter: { username: his_read, password: ******, column: [ PATIENT_ID, VISIT_NO, DEPT_CODE, DOCTOR_CODE, REGISTER_TIME, REGISTER_FEE ], connection: [ { jdbcUrl: [jdbc:oracle:thin:10.10.10.10:1521/hisdb], table: [his_register] } ], where: REGISTER_TIME SYSDATE - 1 AND REGISTER_TIME SYSDATE } }, writer: { name: mysqlwriter, parameter: { username: data_platform, password: ******, writeMode: insert, column: [ patient_id, visit_no, dept_code, doctor_code, register_time, register_fee ], connection: [ { jdbcUrl: jdbc:mysql://127.0.0.1:3306/hospital_dw, table: [ods_his_register] } ] } } } ], setting: { speed: { channel: 3 } } } }在 DataX 的 bin 目录下执行python datax.py /opt/datax/job/his_register_sync.json这里强调一个重点DataX 的 reader 账号建议使用源库的只读账号并且由 DBA 审核授权。直接使用高权限账号访问生产库一旦 SQL 写得不合适可能拖慢源库影响临床业务。4.3 用 Shell 脚本编排同步任务如果暂时没有引入 DolphinScheduler可以先通过 Shell 脚本加 crontab 管理同步任务。下面是一个简化示例#!/bin/bash # 文件路径sync-job/bin/sync_daily.sh BASE_DIR/opt/dataplatform/sync-job LOG_DIR${BASE_DIR}/logs TODAY$(date %Y-%m-%d) mkdir -p ${LOG_DIR} echo 开始执行门诊挂号数据同步${TODAY} ${LOG_DIR}/sync.log python ${BASE_DIR}/datax/bin/datax.py ${BASE_DIR}/job/his_register_sync.json ${LOG_DIR}/sync.log 21 if [ $? -eq 0 ]; then echo his_register_sync 执行成功 ${LOG_DIR}/sync.log else echo his_register_sync 执行失败请检查 ${LOG_DIR}/sync.log # 这里可以增加企业微信/钉钉告警脚本 exit 1 ficrontab 配置30 1 * * * /bin/bash /opt/dataplatform/sync-job/bin/sync_daily.sh这种方式适合初期快速跑通流程。当任务数量变多比如几十个同步任务和指标计算任务后建议尽快引入 DolphinScheduler因为可视化的任务依赖和失败重试会让运维轻松很多。4.4 同步后的数据质量校验数据同步不是“导完数据”就结束了。一个常见的问题是源系统当前有没有补录昨天的数据如果指标计算跑在了补录数据之前最后报表就会少数据。所以每次同步任务完成后建议做一次数据量校验-- 对比源表和目标表记录数这里只是示例 SELECT COUNT(*) AS source_count FROM his_registerhis_link WHERE REGISTER_TIME TRUNC(SYSDATE) - 1; SELECT COUNT(*) AS target_count FROM ods_his_register WHERE register_time CURDATE() - INTERVAL 1 DAY;如果两个数量差异较大需要触发告警。数据质量校验最好在调度任务中作为一个独立节点存在而不是只在开发时人工核对。5. 指标口径管理与计算5.1 指标字典设计指标计算最怕的就是口径不统一。不同科室对“门诊人次”的理解可能都不一样医保办可能按挂号人次统计财务科可能按计费人次统计医务科可能按实际就诊人次统计。为了避免争议需要一张指标字典表把指标定义、计算公式、统计维度、责任人都管理起来。-- 文件路径db/ads/ads_indicator_dict.sql CREATE TABLE ads_indicator_dict ( indicator_code VARCHAR(64) NOT NULL COMMENT 指标编码, indicator_name VARCHAR(128) NOT NULL COMMENT 指标名称, indicator_type VARCHAR(32) COMMENT 指标分类门诊/住院/财务/人力, calculate_formula VARCHAR(512) COMMENT 计算公式说明, stat_period VARCHAR(16) COMMENT 统计周期DAY/MONTH/QUARTER/YEAR, dimension_desc VARCHAR(256) COMMENT 统计维度说明, owner_dept VARCHAR(128) COMMENT 责任科室, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (indicator_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT运营指标字典表;这张表的作用不只是给开发看更重要的是给业务科室确认。上线一个新指标前先把字典表里的内容发给相关科室审核确认后再开发能省掉后面大量返工。5.2 核心指标计算 SQL下面以三个常见指标为例展示 ADS 层指标计算的 SQL 写法。第一个指标门诊就诊人次。-- 计算指定日期各科室门诊就诊人次 INSERT INTO ads_outpatient_daily (stat_date, dept_id, visit_count) SELECT visit_date, dept_id, COUNT(DISTINCT visit_no) AS visit_count FROM dwd_outpatient_visit WHERE visit_date 2025-01-06 AND visit_type 门诊 AND is_valid 1 GROUP BY visit_date, dept_id;这里使用COUNT(DISTINCT visit_no)而不是COUNT(1)是因为一个病人可能挂多个号同一个 visit_no 才是真正的一次就诊流水。如果不加 DISTINCT统计出来的人次会偏大。第二个指标门诊次均费用。UPDATE ads_outpatient_daily SET settlement_sum ( SELECT COALESCE(SUM(settlement_amount), 0) FROM dwd_outpatient_visit WHERE stat_date 2025-01-06 AND dept_id ads_outpatient_daily.dept_id ), average_fee CASE WHEN visit_count 0 THEN settlement_sum / visit_count ELSE 0 END WHERE stat_date 2025-01-06;次均费用的计算核心在于分子和分母的统计时间范围、科室归属必须一致。否则分子按收费日期、分母按就诊日期计算结果一定对不上。第三个指标床位使用率。床位使用率通常需要住院在床数据这里给一个简化的计算示例-- 简化示例每日床位使用率 当日实际占用床日数 / 实际开放床日数 SELECT stat_date, dept_id, SUM(occupied_bed_days) AS occupied_bed_days, SUM(open_bed_days) AS open_bed_days, CASE WHEN SUM(open_bed_days) 0 THEN SUM(occupied_bed_days) / SUM(open_bed_days) ELSE 0 END AS bed_usage_rate FROM dwd_inpatient_bed_daily WHERE stat_date 2025-01-06 GROUP BY stat_date, dept_id;注意这里的 open_bed_days 可能是“实际开放床位数 × 天数”由护理部或统计室确定不能自己想当然。5.3 指标幂等与重复计算指标计算任务最怕重复执行。比如调度系统重试了一次结果同一批数据被插了两遍报表金额直接翻倍。解决办法有两种第一种是删除式的“先删后插”。每次计算前先删除当天的旧数据再执行插入。DELETE FROM ads_outpatient_daily WHERE stat_date 2025-01-06; -- 再执行 INSERT 语句第二种是使用INSERT ... ON DUPLICATE KEY UPDATE。这要求表有唯一键比如uk_stat_date_dept。ALTER TABLE ads_outpatient_daily ADD UNIQUE KEY uk_stat_date_dept (stat_date, dept_id);推荐在生产环境同时使用“先删后插”和唯一键约束双保险。6. 对外指标服务与可视化6.1 基于 Spring Boot 提供指标 API数据平台的价值最终要体现为“可用”。除了 BI 报表外很多院内系统也需要通过 API 获取指标数据。下面演示一个最简化的 Spring Boot 服务。先创建基础工程pom.xml 引入核心依赖!-- 文件路径indicator-service/pom.xml -- dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3/version /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency /dependencies然后是实体类// 文件路径indicator-service/src/main/java/com/hospital/indicator/entity/OutpatientDaily.java package com.hospital.indicator.entity; import com.baomidou.mybatisplus.annotation.TableName; import lombok.Data; import java.math.BigDecimal; import java.time.LocalDate; Data TableName(ads_outpatient_daily) public class OutpatientDaily { private LocalDate statDate; private Long deptId; private Integer visitCount; private BigDecimal registerFeeSum; private BigDecimal settlementSum; private BigDecimal averageFee; private BigDecimal medicineRatio; }Mapper 接口// 文件路径indicator-service/src/main/java/com/hospital/indicator/mapper/OutpatientDailyMapper.java package com.hospital.indicator.mapper; import com.baomidou.mybatisplus.core.mapper.BaseMapper; import com.hospital.indicator.entity.OutpatientDaily; import org.apache.ibatis.annotations.Mapper; Mapper public interface OutpatientDailyMapper extends BaseMapperOutpatientDaily { }Service// 文件路径indicator-service/src/main/java/com/hospital/indicator/service/IndicatorService.java package com.hospital.indicator.service; import com.baomidou.mybatisplus.core.conditions.query.LambdaQueryWrapper; import com.hospital.indicator.entity.OutpatientDaily; import com.hospital.indicator.mapper.OutpatientDailyMapper; import org.springframework.stereotype.Service; import javax.annotation.Resource; import java.time.LocalDate; import java.util.List; Service public class IndicatorService { Resource private OutpatientDailyMapper outpatientDailyMapper; public ListOutpatientDaily queryOutpatientDaily(LocalDate statDate, Long deptId) { LambdaQueryWrapperOutpatientDaily wrapper new LambdaQueryWrapper(); wrapper.eq(OutpatientDaily::getStatDate, statDate); if (deptId ! null) { wrapper.eq(OutpatientDaily::getDeptId, deptId); } return outpatientDailyMapper.selectList(wrapper); } }Controller// 文件路径indicator-service/src/main/java/com/hospital/indicator/controller/IndicatorController.java package com.hospital.indicator.controller; import com.hospital.indicator.entity.OutpatientDaily; import com.hospital.indicator.service.IndicatorService; import org.springframework.format.annotation.DateTimeFormat; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RequestParam; import org.springframework.web.bind.annotation.RestController; import javax.annotation.Resource; import java.time.LocalDate; import java.util.List; RestController RequestMapping(/api/indicator) public class IndicatorController { Resource private IndicatorService indicatorService; GetMapping(/outpatient/daily) public ListOutpatientDaily queryOutpatientDaily( RequestParam(statDate) DateTimeFormat(iso DateTimeFormat.ISO.DATE) LocalDate statDate, RequestParam(value deptId, required false) Long deptId) { return indicatorService.queryOutpatientDaily(statDate, deptId); } }启动类// 文件路径indicator-service/src/main/java/com/hospital/indicator/IndicatorApplication.java package com.hospital.indicator; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; SpringBootApplication public class IndicatorApplication { public static void main(String[] args) { SpringApplication.run(IndicatorApplication.class, args); } }配置文件 application.yml 中数据库信息需要根据实际环境修改# 文件路径indicator-service/src/main/resources/application.yml server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://127.0.0.1:3306/hospital_dw?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: data_platform password: ******启动后访问GET http://localhost:8080/api/indicator/outpatient/daily?statDate2025-01-06deptId1001返回结果是 JSON 数组每个元素代表该科室当天的门诊运营指标。如果接口要提供给院外系统或第三方厂商务必在网关层增加认证鉴权建议使用 OAuth2 或至少 token 认证而不是直接暴露内网接口。6.2 数据脱敏与权限控制医院数据包含患者个人信息和诊疗信息属于敏感数据。在指标明细查询中如果返回了病人ID、姓名、身份证号等信息必须做脱敏处理。简单示例Java 侧做手机号脱敏。// 文件路径indicator-service/src/main/java/com/hospital/indicator/util/DesensitizeUtil.java package com.hospital.indicator.util; public class DesensitizeUtil { public static String maskPhone(String phone) { if (phone null || phone.length() 11) { return phone; } return phone.substring(0, 3) **** phone.substring(7); } public static String maskIdCard(String idCard) { if (idCard null || idCard.length() 8) { return idCard; } return idCard.substring(0, 4) ********** idCard.substring(14); } }真实项目中还要遵循最小权限原则普通科室只能看本科室数据院领导可以看全院数据跨科室数据必须经过授权。这个控制最好在 API 层做而不是靠前端隐藏。6.3 可视化展示如果使用 Superset只需要把 ADS 表作为数据源创建 Chart 和 Dashboard。操作步骤大致如下在 Superset 中配置 MySQL 数据源连接。在 SQL Lab 中验证指标查询 SQL。新建一个 Dataset选择ads_outpatient_daily表。创建 Chart统计维度选择stat_date指标选择visit_count、average_fee。将多个 Chart 组装到 Dashboard配置自动刷新。这个阶段的重点不是图表多好看而是数据口径正确。图表上的任何一个数字都要能追溯到指标字典里的定义和计算 SQL。如果业务科室对数字有疑问开发人员要能快速给出完整的口径说明和数据血缘这才叫数据可靠。7. 常见问题与排查思路医院数据平台开发和运维中最常见的问题集中在同步、计算、接口三个环节。问题现象常见原因解决思路同步任务执行成功但数据量为 0增量同步时间窗口判断不正确或源系统当天没有新数据检查 where 条件确认源表数据查看 DataX 日志指标数据重复翻倍调度任务重跑导致重复插入加唯一索引使用先删后插或使用 UPSERT 方式次均费用异常偏高/偏低分子分母口径不一致或包含退费、作废数据与业务科室核对公式增加 is_valid 过滤条件接口查询慢缺少索引或查询日期范围过大在 stat_date、dept_id 上建联合索引限制单次查询范围科室数据串了DWD 层科室维度关联错误检查科室映射表建设科室匹配核对清单报表和财务系统数字不一致与财务系统统计口径不同以指标字典为准明确单一责任部门确认口径一个比较容易忽略的问题是“时区”。如果应用服务器和数据库服务器时区不一致CURDATE()或SYSDATE取出来的日期可能差一天。建议所有服务器统一使用Asia/Shanghai时区并在连接串中也指定 serverTimezone。另一个常见问题是“历史数据修正”。月底财务调账后前一天的数据可能会被修改。如果数据平台只按日期做增量同步这些变更的数据不会重新同步导致最终报表不准。这种情况需要建立“对账机制”每天或每周对关键表做总量对比发现异常及时补数。8. 最佳实践与工程建议8.1 指标口径先行代码实现在后任何指标开发前先输出指标字典文档内容包括指标定义、计算公式、统计周期、统计维度、数据来源、责任科室。让医务科、财务科、信息科三方确认后再动手写 SQL。这样做看起来流程重了实际上是最省时间的方式。8.2 敏感数据全链路管控医院数据平台涉及患者隐私必须在项目启动时就考虑合规问题所有应用账号遵循最小权限原则只授予业务所需权限。源库同步账号尽量使用只读账号。明细数据在 ODS、DWD 层保留即可对外 API 层只输出聚合结果不输出患者级明细。如果确实需要患者级数据用于科研需要走院内审批流程并进行严格脱敏。数据同步、API 调用全过程记录日志方便审计。8.3 任务调度要有失败重试和告警数据平台中任何一个同步任务失败都可能影响当天所有指标。调度系统必须配置失败自动重试建议最多重试 2 次。重试仍失败后发送告警通知到责任人。关键任务设置前置依赖和超时时间。很多人会忽略“任务超时”。有些医院源库在月初业务高峰期响应很慢同步任务从原来的 5 分钟变成 2 小时。如果没有超时控制会阻塞后面的指标计算任务。8.4 数据血缘和版本管理当指标上线一段时间后业务部门会要求调整口径。这时候最容易出问题改完指标计算 SQL忘了更新指标字典或者只改了生产环境的 SQL没同步到代码仓库。建议所有指标计算 SQL 纳入 Git 管理和代码一起走版本发布。每次口径变更在指标字典中记录变更时间和变更原因。关键指标尽量保存历史版本口径方便回溯对比。8.5 性能优化优先考虑索引和预聚合医院数据平台的数据量虽然不像互联网那么大但也要注意性能。一个典型的门诊流水表一天可能有几万到几十万条记录月度查询就是百万级甚至千万级。优化建议所有查询都要走索引避免全表扫描。高频指标尽量用 ADS 层日汇总表而不是每次联查明细表。大范围趋势分析使用按月汇总表。接口场景使用 Redis 缓存热点指标设置合理过期时间。8.6 先试点后推广医院数据平台直接对接临床和运营系统风险控制很重要。新指标或新接口上线前先选择一两个科室试点与对方人工统计数据进行比对。比对通过后再全院推广能避免很多因口径争议导致的返工。9. 写在最后回到文章开头提到的那场学术年会。“数智赋能、提质增效”在管理端是一句战略口号但在工程端它最终要落实为“数据能不能每天按时跑到数仓”“指标口径能不能经得起业务科室追问”“接口返回的数字能不能直接用于管理决策”。能做到这三点智慧医院的数据底座才算真正发挥价值。这篇文章介绍了一条比较务实的落地路径先用 ODS、DWD、DIM、ADS 分层把数据管起来再用统一指标字典把口径定下来然后通过调度任务把数据算出来最后用 API 和报表把数据用起来。整条链路不复杂但每一步都有不少细节工作要做。如果你正在做医院数据中台或智慧医疗平台项目建议优先从“一个核心指标、一条完整链路”开始试点。比如先做门诊次均费用从源库同步到 ODS清洗到 DWD计算到 ADS再通过接口展示出来。把这条链路跑通后再横向复制到其他指标会比一上来就铺一个庞大的平台稳妥得多。 医院数据中台实战：从数据接入到指标API全流程落地
近期医疗信息化圈子里中国卫生经济学会公立医院高质量发展分会学术年会是一个比较受关注的话题。会议主题里的“数智赋能、提质增效”这八个字看起来是管理层面的表达但落到技术侧其实对应的就是一套非常具体的工程能力医院那么多业务系统HIS、LIS、PACS、EMR、HRP数据怎么统一采集门诊收入、次均费用、床位使用率、药占比这些指标怎么保证每个科室算出来的口径一致领导要看运营日报能不能当天自动出数对于长期做医院信息化、智慧医疗项目的开发者来说这些问题基本都遇到过。网上关于“数据中台”的资料很多但针对医院场景的完整闭环案例很少。本文以“数智赋能、提质增效”为背景梳理一套从数据接入、数据治理、指标计算到对外API发布和可视化的实战方案。内容偏工程落地既有设计思路也有可以直接参考的SQL、Java代码和排查清单适合医疗信息化开发工程师、数据平台开发者和准备进入智慧医疗方向的同学。1. 数智赋能在医院信息化中的技术含义1.1 医院数据建设的现状大多数医院经过多年信息化建设都会形成“业务系统多、厂商多、数据库多、口径多”的局面。临床业务系统HIS医院信息系统、LIS检验信息系统、PACS影像归档与通信系统、EMR电子病历系统。运营管理系统HRP医院资源规划、财务系统、绩效系统、后勤管理系统。数据来源复杂有的数据库是 Oracle有的是 SQL Server还有一部分是 MySQL甚至少数老旧系统还通过 Excel 导出上报。这些系统各自都在产生数据但系统之间的数据标准不统一。同一个“门诊收入”财务系统按收费日期统计HIS 可能按就诊日期统计绩效系统又可能按结算日期统计。如果不做统一管理报表出来以后各科室互相质疑最后只能靠信息科手工核对效率非常低。1.2 数智赋能的技术落地路径“数智赋能”落到具体技术方案通常包含三层意思第一层是数据采集与集成。通过 ETL 工具或数据同步中间件把分散在各业务系统的数据周期性地抽取到统一的数据平台解决“数据孤岛”问题。第二层是数据治理与标准化。建立统一的病人主索引、科室编码字典、指标字典让所有系统在同一个口径下描述业务。这一步解决的是“数据不准、口径不一”的问题。第三层是数据应用与服务。基于治理后的数据计算门诊、住院、财务、人力等维度的运营指标通过 BI 报表、领导驾驶舱、数据服务接口等方式把数据价值返回给管理者和业务科室最终体现为管理效率的提升和运营成本的下降。简单说“数智赋能”不是引入一个大数据平台就结束而是要让数据在采集、治理、计算、服务这条链路上“跑得通、算得准、看得到、用得上”。1.3 数据中台与数据仓库的边界做医院数据平台时很多团队会把数据仓库和数据中台混在一起。这里简单区分一下数据仓库偏重于“存储与计算”核心是把历史数据按主题组织起来支撑报表和分析。它的服务对象主要是数据分析师和管理层。数据中台则在数据仓库之上更强调“服务复用”。它不仅提供报表还要把公共的数据能力抽象成 API比如科室运营指标查询接口、患者就诊趋势接口让 HIS、OA、绩效系统在后续开发时可以直接调用。在实际项目中不需要把两者对立起来。大多数医院级数据平台是“先建数仓分层模型再在中台层沉淀指标服务和数据 API”。本文后面的实战案例也采用这种思路。2. 环境准备与项目规划2.1 技术选型医院级数据平台不建议一上来就引入非常重的组件。很多地市级医院的信息科人员配置有限日常还要保障核心业务系统稳定所以技术选型要兼顾可维护性和成本。下面是一套比较稳的组合数据库MySQL 8.x用于元数据管理、指标字典存储。数据同步Apache DataX用于从 Oracle、SQL Server、MySQL 等数据源同步数据。调度引擎DolphinScheduler 或简单的 XXL-JOB用于定时执行同步任务和指标计算任务。应用服务Spring Boot 2.7.x MyBatis Plus用于提供指标查询 API。可视化Superset 或帆软 FineBI用于制作运营大屏和填报式报表。缓存Redis可选用于高频指标查询的缓存加速。版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路不是固定模板。2.2 环境清单操作系统CentOS 7.9 或 Ubuntu 20.04Windows 也可以跑通示例 JDK1.8 或 11 MySQL8.0 Spring Boot2.7.x DataX3.0开源版 DolphinScheduler3.x强调一点正式生产环境使用 DataX 或调度组件前先在测试环境完整验证。医院核心库是生产系统直接连源库做同步存在性能风险需要在数据库侧做只读账号、限流或从库同步方案。2.3 项目目录规划为了便于维护建议把整个数据平台工程拆成多个子模块而不是写到一个大项目里。hospital-data-platform ├── docs # 设计文档、指标口径说明 ├── db # 建表 SQL、初始化数据 │ ├── ods # 贴源层表结构 │ ├── dwd # 明细层表结构 │ ├── dim # 维度表结构 │ └── ads # 应用层表结构 ├── sync-job # 数据同步任务DataX JSON、Shell 脚本 ├── indicator-service # 指标服务Spring Boot 工程 │ ├── src/main/java │ └── src/main/resources └── sql # 指标计算 SQL、存储过程可选如果团队规模不大也可以先把 sync-job 和 indicator-service 合并成一个工程但表结构脚本一定要独立维护因为数据模型的变更频率远低于代码。3. 医院运营数据模型设计3.1 分层设计思路数据平台一般按 ODS、DWD、DIM、ADS 四层划分ODS贴源层同步源系统原始数据不做过多的清洗保留历史快照。DWD明细层对 ODS 数据做标准化加工统一编码、去重、清洗生成业务明细数据。DIM维度层科室维度、医生维度、时间维度、病人主索引等公共维度表。ADS应用层面向具体业务场景的汇总表比如门诊运营日汇总、住院运营日汇总、财务指标月汇总。分层的意义在于每层职责单一出现问题可以快速定位是在同步阶段、清洗阶段还是汇总阶段。3.2 核心表结构示例先看一张最核心的科室维度表-- 文件路径db/dim/dim_dept.sql CREATE TABLE dim_dept ( dept_id BIGINT NOT NULL COMMENT 科室ID, dept_code VARCHAR(64) NOT NULL COMMENT 科室编码, dept_name VARCHAR(128) NOT NULL COMMENT 科室名称, parent_dept_id BIGINT DEFAULT NULL COMMENT 上级科室ID, dept_type VARCHAR(32) COMMENT 科室类型临床/医技/行政/后勤, is_active TINYINT DEFAULT 1 COMMENT 是否有效1有效0无效, source_system VARCHAR(32) COMMENT 来源系统HIS/LIS/PACS/HRP, etl_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 同步时间, PRIMARY KEY (dept_id), UNIQUE KEY uk_dept_code (dept_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT科室维度表;这里要注意 dept_code 需要做唯一约束因为不同系统可能使用不同的科室编码后续通过映射表统一。再建一张 ODS 层的门诊挂号记录表模拟从 HIS 同步过来的原始数据-- 文件路径db/ods/ods_his_register.sql CREATE TABLE ods_his_register ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 自增ID, patient_id VARCHAR(64) NOT NULL COMMENT 患者ID, visit_no VARCHAR(64) NOT NULL COMMENT 就诊流水号, dept_code VARCHAR(64) COMMENT 科室编码源系统, doctor_code VARCHAR(64) COMMENT 医生编码源系统, register_time DATETIME COMMENT 挂号时间, register_fee DECIMAL(10,2) COMMENT 挂号费, visit_type VARCHAR(16) COMMENT 就诊类型门诊/急诊/住院, source_system VARCHAR(32) COMMENT 来源系统, sync_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 同步时间, PRIMARY KEY (id), KEY idx_visit_no (visit_no), KEY idx_register_time (register_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT门诊挂号记录ODS表;之后是 DWD 层的标准化明细表。DWD 表一般会冗余科室维度、医生维度字段避免指标查询时多次关联维度表-- 文件路径db/dwd/dwd_outpatient_visit.sql CREATE TABLE dwd_outpatient_visit ( visit_date DATE NOT NULL COMMENT 就诊日期, visit_no VARCHAR(64) NOT NULL COMMENT 就诊流水号, patient_id VARCHAR(64) NOT NULL COMMENT 患者ID脱敏后, dept_id BIGINT COMMENT 科室ID标准维度ID, doctor_id BIGINT COMMENT 医生ID标准维度ID, visit_type VARCHAR(16) COMMENT 就诊类型, register_fee DECIMAL(10,2) COMMENT 挂号费, settlement_amount DECIMAL(10,2) COMMENT 结算金额, is_valid TINYINT DEFAULT 1 COMMENT 是否有效就诊, etl_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT ETL时间, PRIMARY KEY (visit_date, visit_no), KEY idx_dept_id (dept_id), KEY idx_visit_date (visit_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT门诊就诊明细DWD表;最后是 ADS 层日汇总表直接服务指标查询-- 文件路径db/ads/ads_outpatient_daily.sql CREATE TABLE ads_outpatient_daily ( stat_date DATE NOT NULL COMMENT 统计日期, dept_id BIGINT NOT NULL COMMENT 科室ID, visit_count INT DEFAULT 0 COMMENT 就诊人次, register_fee_sum DECIMAL(12,2) DEFAULT 0 COMMENT 挂号费总额, settlement_sum DECIMAL(12,2) DEFAULT 0 COMMENT 结算金额总额, average_fee DECIMAL(12,2) DEFAULT 0 COMMENT 次均费用, medicine_ratio DECIMAL(5,4) DEFAULT 0 COMMENT 药占比测试口径, etl_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 统计时间, PRIMARY KEY (stat_date, dept_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT门诊运营指标日汇总表;需要说明的是这里的药占比、次均费用等字段只是演示使用。真实医院的口径往往由财务和医务部门定义不同医院可能完全不同开发时必须以本院最终确认的口径文档为准。4. 数据接入与同步实战4.1 同步策略选择医院业务系统对实时性要求不同。挂号、收费这类操作如果做实时同步往往需要接入消息队列和 CDC变更数据捕获组件复杂度较高。而运营指标分析通常不要求秒级实时一般按小时或者 T1 同步即可。建议同步策略日结类数据每天凌晨同步前一天全量变更数据。维度数据每晚同步一次变更频率低。实时性要求高的场景通过接口或消息队列对接而不是直接对源库做频繁轮询。首次上线时建议先做一次全量初始化之后切换到增量同步。增量同步最稳妥的字段是“更新时间”和“创建时间”前提是源系统这些字段维护得比较规范。4.2 使用 DataX 同步示例DataX 是常用的异构数据源离线同步工具。假设要从 Oracle 的 HIS 库读取前一天数据写入 MySQL 的 ODS 表可以配置一个 DataX job。由于不同医院的表名称和字段差异很大这里给出一个简化 JSON 示例核心思路是通用的{ job: { content: [ { reader: { name: oraclereader, parameter: { username: his_read, password: ******, column: [ PATIENT_ID, VISIT_NO, DEPT_CODE, DOCTOR_CODE, REGISTER_TIME, REGISTER_FEE ], connection: [ { jdbcUrl: [jdbc:oracle:thin:10.10.10.10:1521/hisdb], table: [his_register] } ], where: REGISTER_TIME SYSDATE - 1 AND REGISTER_TIME SYSDATE } }, writer: { name: mysqlwriter, parameter: { username: data_platform, password: ******, writeMode: insert, column: [ patient_id, visit_no, dept_code, doctor_code, register_time, register_fee ], connection: [ { jdbcUrl: jdbc:mysql://127.0.0.1:3306/hospital_dw, table: [ods_his_register] } ] } } } ], setting: { speed: { channel: 3 } } } }在 DataX 的 bin 目录下执行python datax.py /opt/datax/job/his_register_sync.json这里强调一个重点DataX 的 reader 账号建议使用源库的只读账号并且由 DBA 审核授权。直接使用高权限账号访问生产库一旦 SQL 写得不合适可能拖慢源库影响临床业务。4.3 用 Shell 脚本编排同步任务如果暂时没有引入 DolphinScheduler可以先通过 Shell 脚本加 crontab 管理同步任务。下面是一个简化示例#!/bin/bash # 文件路径sync-job/bin/sync_daily.sh BASE_DIR/opt/dataplatform/sync-job LOG_DIR${BASE_DIR}/logs TODAY$(date %Y-%m-%d) mkdir -p ${LOG_DIR} echo 开始执行门诊挂号数据同步${TODAY} ${LOG_DIR}/sync.log python ${BASE_DIR}/datax/bin/datax.py ${BASE_DIR}/job/his_register_sync.json ${LOG_DIR}/sync.log 21 if [ $? -eq 0 ]; then echo his_register_sync 执行成功 ${LOG_DIR}/sync.log else echo his_register_sync 执行失败请检查 ${LOG_DIR}/sync.log # 这里可以增加企业微信/钉钉告警脚本 exit 1 ficrontab 配置30 1 * * * /bin/bash /opt/dataplatform/sync-job/bin/sync_daily.sh这种方式适合初期快速跑通流程。当任务数量变多比如几十个同步任务和指标计算任务后建议尽快引入 DolphinScheduler因为可视化的任务依赖和失败重试会让运维轻松很多。4.4 同步后的数据质量校验数据同步不是“导完数据”就结束了。一个常见的问题是源系统当前有没有补录昨天的数据如果指标计算跑在了补录数据之前最后报表就会少数据。所以每次同步任务完成后建议做一次数据量校验-- 对比源表和目标表记录数这里只是示例 SELECT COUNT(*) AS source_count FROM his_registerhis_link WHERE REGISTER_TIME TRUNC(SYSDATE) - 1; SELECT COUNT(*) AS target_count FROM ods_his_register WHERE register_time CURDATE() - INTERVAL 1 DAY;如果两个数量差异较大需要触发告警。数据质量校验最好在调度任务中作为一个独立节点存在而不是只在开发时人工核对。5. 指标口径管理与计算5.1 指标字典设计指标计算最怕的就是口径不统一。不同科室对“门诊人次”的理解可能都不一样医保办可能按挂号人次统计财务科可能按计费人次统计医务科可能按实际就诊人次统计。为了避免争议需要一张指标字典表把指标定义、计算公式、统计维度、责任人都管理起来。-- 文件路径db/ads/ads_indicator_dict.sql CREATE TABLE ads_indicator_dict ( indicator_code VARCHAR(64) NOT NULL COMMENT 指标编码, indicator_name VARCHAR(128) NOT NULL COMMENT 指标名称, indicator_type VARCHAR(32) COMMENT 指标分类门诊/住院/财务/人力, calculate_formula VARCHAR(512) COMMENT 计算公式说明, stat_period VARCHAR(16) COMMENT 统计周期DAY/MONTH/QUARTER/YEAR, dimension_desc VARCHAR(256) COMMENT 统计维度说明, owner_dept VARCHAR(128) COMMENT 责任科室, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (indicator_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT运营指标字典表;这张表的作用不只是给开发看更重要的是给业务科室确认。上线一个新指标前先把字典表里的内容发给相关科室审核确认后再开发能省掉后面大量返工。5.2 核心指标计算 SQL下面以三个常见指标为例展示 ADS 层指标计算的 SQL 写法。第一个指标门诊就诊人次。-- 计算指定日期各科室门诊就诊人次 INSERT INTO ads_outpatient_daily (stat_date, dept_id, visit_count) SELECT visit_date, dept_id, COUNT(DISTINCT visit_no) AS visit_count FROM dwd_outpatient_visit WHERE visit_date 2025-01-06 AND visit_type 门诊 AND is_valid 1 GROUP BY visit_date, dept_id;这里使用COUNT(DISTINCT visit_no)而不是COUNT(1)是因为一个病人可能挂多个号同一个 visit_no 才是真正的一次就诊流水。如果不加 DISTINCT统计出来的人次会偏大。第二个指标门诊次均费用。UPDATE ads_outpatient_daily SET settlement_sum ( SELECT COALESCE(SUM(settlement_amount), 0) FROM dwd_outpatient_visit WHERE stat_date 2025-01-06 AND dept_id ads_outpatient_daily.dept_id ), average_fee CASE WHEN visit_count 0 THEN settlement_sum / visit_count ELSE 0 END WHERE stat_date 2025-01-06;次均费用的计算核心在于分子和分母的统计时间范围、科室归属必须一致。否则分子按收费日期、分母按就诊日期计算结果一定对不上。第三个指标床位使用率。床位使用率通常需要住院在床数据这里给一个简化的计算示例-- 简化示例每日床位使用率 当日实际占用床日数 / 实际开放床日数 SELECT stat_date, dept_id, SUM(occupied_bed_days) AS occupied_bed_days, SUM(open_bed_days) AS open_bed_days, CASE WHEN SUM(open_bed_days) 0 THEN SUM(occupied_bed_days) / SUM(open_bed_days) ELSE 0 END AS bed_usage_rate FROM dwd_inpatient_bed_daily WHERE stat_date 2025-01-06 GROUP BY stat_date, dept_id;注意这里的 open_bed_days 可能是“实际开放床位数 × 天数”由护理部或统计室确定不能自己想当然。5.3 指标幂等与重复计算指标计算任务最怕重复执行。比如调度系统重试了一次结果同一批数据被插了两遍报表金额直接翻倍。解决办法有两种第一种是删除式的“先删后插”。每次计算前先删除当天的旧数据再执行插入。DELETE FROM ads_outpatient_daily WHERE stat_date 2025-01-06; -- 再执行 INSERT 语句第二种是使用INSERT ... ON DUPLICATE KEY UPDATE。这要求表有唯一键比如uk_stat_date_dept。ALTER TABLE ads_outpatient_daily ADD UNIQUE KEY uk_stat_date_dept (stat_date, dept_id);推荐在生产环境同时使用“先删后插”和唯一键约束双保险。6. 对外指标服务与可视化6.1 基于 Spring Boot 提供指标 API数据平台的价值最终要体现为“可用”。除了 BI 报表外很多院内系统也需要通过 API 获取指标数据。下面演示一个最简化的 Spring Boot 服务。先创建基础工程pom.xml 引入核心依赖!-- 文件路径indicator-service/pom.xml -- dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3/version /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency /dependencies然后是实体类// 文件路径indicator-service/src/main/java/com/hospital/indicator/entity/OutpatientDaily.java package com.hospital.indicator.entity; import com.baomidou.mybatisplus.annotation.TableName; import lombok.Data; import java.math.BigDecimal; import java.time.LocalDate; Data TableName(ads_outpatient_daily) public class OutpatientDaily { private LocalDate statDate; private Long deptId; private Integer visitCount; private BigDecimal registerFeeSum; private BigDecimal settlementSum; private BigDecimal averageFee; private BigDecimal medicineRatio; }Mapper 接口// 文件路径indicator-service/src/main/java/com/hospital/indicator/mapper/OutpatientDailyMapper.java package com.hospital.indicator.mapper; import com.baomidou.mybatisplus.core.mapper.BaseMapper; import com.hospital.indicator.entity.OutpatientDaily; import org.apache.ibatis.annotations.Mapper; Mapper public interface OutpatientDailyMapper extends BaseMapperOutpatientDaily { }Service// 文件路径indicator-service/src/main/java/com/hospital/indicator/service/IndicatorService.java package com.hospital.indicator.service; import com.baomidou.mybatisplus.core.conditions.query.LambdaQueryWrapper; import com.hospital.indicator.entity.OutpatientDaily; import com.hospital.indicator.mapper.OutpatientDailyMapper; import org.springframework.stereotype.Service; import javax.annotation.Resource; import java.time.LocalDate; import java.util.List; Service public class IndicatorService { Resource private OutpatientDailyMapper outpatientDailyMapper; public ListOutpatientDaily queryOutpatientDaily(LocalDate statDate, Long deptId) { LambdaQueryWrapperOutpatientDaily wrapper new LambdaQueryWrapper(); wrapper.eq(OutpatientDaily::getStatDate, statDate); if (deptId ! null) { wrapper.eq(OutpatientDaily::getDeptId, deptId); } return outpatientDailyMapper.selectList(wrapper); } }Controller// 文件路径indicator-service/src/main/java/com/hospital/indicator/controller/IndicatorController.java package com.hospital.indicator.controller; import com.hospital.indicator.entity.OutpatientDaily; import com.hospital.indicator.service.IndicatorService; import org.springframework.format.annotation.DateTimeFormat; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RequestParam; import org.springframework.web.bind.annotation.RestController; import javax.annotation.Resource; import java.time.LocalDate; import java.util.List; RestController RequestMapping(/api/indicator) public class IndicatorController { Resource private IndicatorService indicatorService; GetMapping(/outpatient/daily) public ListOutpatientDaily queryOutpatientDaily( RequestParam(statDate) DateTimeFormat(iso DateTimeFormat.ISO.DATE) LocalDate statDate, RequestParam(value deptId, required false) Long deptId) { return indicatorService.queryOutpatientDaily(statDate, deptId); } }启动类// 文件路径indicator-service/src/main/java/com/hospital/indicator/IndicatorApplication.java package com.hospital.indicator; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; SpringBootApplication public class IndicatorApplication { public static void main(String[] args) { SpringApplication.run(IndicatorApplication.class, args); } }配置文件 application.yml 中数据库信息需要根据实际环境修改# 文件路径indicator-service/src/main/resources/application.yml server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://127.0.0.1:3306/hospital_dw?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: data_platform password: ******启动后访问GET http://localhost:8080/api/indicator/outpatient/daily?statDate2025-01-06deptId1001返回结果是 JSON 数组每个元素代表该科室当天的门诊运营指标。如果接口要提供给院外系统或第三方厂商务必在网关层增加认证鉴权建议使用 OAuth2 或至少 token 认证而不是直接暴露内网接口。6.2 数据脱敏与权限控制医院数据包含患者个人信息和诊疗信息属于敏感数据。在指标明细查询中如果返回了病人ID、姓名、身份证号等信息必须做脱敏处理。简单示例Java 侧做手机号脱敏。// 文件路径indicator-service/src/main/java/com/hospital/indicator/util/DesensitizeUtil.java package com.hospital.indicator.util; public class DesensitizeUtil { public static String maskPhone(String phone) { if (phone null || phone.length() 11) { return phone; } return phone.substring(0, 3) **** phone.substring(7); } public static String maskIdCard(String idCard) { if (idCard null || idCard.length() 8) { return idCard; } return idCard.substring(0, 4) ********** idCard.substring(14); } }真实项目中还要遵循最小权限原则普通科室只能看本科室数据院领导可以看全院数据跨科室数据必须经过授权。这个控制最好在 API 层做而不是靠前端隐藏。6.3 可视化展示如果使用 Superset只需要把 ADS 表作为数据源创建 Chart 和 Dashboard。操作步骤大致如下在 Superset 中配置 MySQL 数据源连接。在 SQL Lab 中验证指标查询 SQL。新建一个 Dataset选择ads_outpatient_daily表。创建 Chart统计维度选择stat_date指标选择visit_count、average_fee。将多个 Chart 组装到 Dashboard配置自动刷新。这个阶段的重点不是图表多好看而是数据口径正确。图表上的任何一个数字都要能追溯到指标字典里的定义和计算 SQL。如果业务科室对数字有疑问开发人员要能快速给出完整的口径说明和数据血缘这才叫数据可靠。7. 常见问题与排查思路医院数据平台开发和运维中最常见的问题集中在同步、计算、接口三个环节。问题现象常见原因解决思路同步任务执行成功但数据量为 0增量同步时间窗口判断不正确或源系统当天没有新数据检查 where 条件确认源表数据查看 DataX 日志指标数据重复翻倍调度任务重跑导致重复插入加唯一索引使用先删后插或使用 UPSERT 方式次均费用异常偏高/偏低分子分母口径不一致或包含退费、作废数据与业务科室核对公式增加 is_valid 过滤条件接口查询慢缺少索引或查询日期范围过大在 stat_date、dept_id 上建联合索引限制单次查询范围科室数据串了DWD 层科室维度关联错误检查科室映射表建设科室匹配核对清单报表和财务系统数字不一致与财务系统统计口径不同以指标字典为准明确单一责任部门确认口径一个比较容易忽略的问题是“时区”。如果应用服务器和数据库服务器时区不一致CURDATE()或SYSDATE取出来的日期可能差一天。建议所有服务器统一使用Asia/Shanghai时区并在连接串中也指定 serverTimezone。另一个常见问题是“历史数据修正”。月底财务调账后前一天的数据可能会被修改。如果数据平台只按日期做增量同步这些变更的数据不会重新同步导致最终报表不准。这种情况需要建立“对账机制”每天或每周对关键表做总量对比发现异常及时补数。8. 最佳实践与工程建议8.1 指标口径先行代码实现在后任何指标开发前先输出指标字典文档内容包括指标定义、计算公式、统计周期、统计维度、数据来源、责任科室。让医务科、财务科、信息科三方确认后再动手写 SQL。这样做看起来流程重了实际上是最省时间的方式。8.2 敏感数据全链路管控医院数据平台涉及患者隐私必须在项目启动时就考虑合规问题所有应用账号遵循最小权限原则只授予业务所需权限。源库同步账号尽量使用只读账号。明细数据在 ODS、DWD 层保留即可对外 API 层只输出聚合结果不输出患者级明细。如果确实需要患者级数据用于科研需要走院内审批流程并进行严格脱敏。数据同步、API 调用全过程记录日志方便审计。8.3 任务调度要有失败重试和告警数据平台中任何一个同步任务失败都可能影响当天所有指标。调度系统必须配置失败自动重试建议最多重试 2 次。重试仍失败后发送告警通知到责任人。关键任务设置前置依赖和超时时间。很多人会忽略“任务超时”。有些医院源库在月初业务高峰期响应很慢同步任务从原来的 5 分钟变成 2 小时。如果没有超时控制会阻塞后面的指标计算任务。8.4 数据血缘和版本管理当指标上线一段时间后业务部门会要求调整口径。这时候最容易出问题改完指标计算 SQL忘了更新指标字典或者只改了生产环境的 SQL没同步到代码仓库。建议所有指标计算 SQL 纳入 Git 管理和代码一起走版本发布。每次口径变更在指标字典中记录变更时间和变更原因。关键指标尽量保存历史版本口径方便回溯对比。8.5 性能优化优先考虑索引和预聚合医院数据平台的数据量虽然不像互联网那么大但也要注意性能。一个典型的门诊流水表一天可能有几万到几十万条记录月度查询就是百万级甚至千万级。优化建议所有查询都要走索引避免全表扫描。高频指标尽量用 ADS 层日汇总表而不是每次联查明细表。大范围趋势分析使用按月汇总表。接口场景使用 Redis 缓存热点指标设置合理过期时间。8.6 先试点后推广医院数据平台直接对接临床和运营系统风险控制很重要。新指标或新接口上线前先选择一两个科室试点与对方人工统计数据进行比对。比对通过后再全院推广能避免很多因口径争议导致的返工。9. 写在最后回到文章开头提到的那场学术年会。“数智赋能、提质增效”在管理端是一句战略口号但在工程端它最终要落实为“数据能不能每天按时跑到数仓”“指标口径能不能经得起业务科室追问”“接口返回的数字能不能直接用于管理决策”。能做到这三点智慧医院的数据底座才算真正发挥价值。这篇文章介绍了一条比较务实的落地路径先用 ODS、DWD、DIM、ADS 分层把数据管起来再用统一指标字典把口径定下来然后通过调度任务把数据算出来最后用 API 和报表把数据用起来。整条链路不复杂但每一步都有不少细节工作要做。如果你正在做医院数据中台或智慧医疗平台项目建议优先从“一个核心指标、一条完整链路”开始试点。比如先做门诊次均费用从源库同步到 ODS清洗到 DWD计算到 ADS再通过接口展示出来。把这条链路跑通后再横向复制到其他指标会比一上来就铺一个庞大的平台稳妥得多。