3. 绩效数据源与系统集成

绩效分析平台本身不产生业务数据，它的价值完全取决于能否把分散在各业务系统中的原始记录，准确、及时、可追溯地汇聚成一套可用于核算的指标口径。因此，数据源识别与系统集成是平台建设中最先落地、也最容易反复返工的一环。本节围绕“有哪些源、怎么连、怎么抽、难在哪”四个问题展开，并给出可执行的判断依据。

一、数据源识别：先分清“事实源”和“口径源”

医院绩效涉及的数据源可以按业务域划分，但更实用的分类是按数据角色划分：事实源提供原始业务事件，口径源提供核算规则和归属关系。事实源包括 HIS（挂号、收费、医嘱、住院登记）、EMR（病历文书、诊断、手术操作）、LIS（检验项目与结果）、PACS（检查报告与影像）、HRP（人力、物资、成本）、财务系统（凭证、科目、收支）。口径源则包括科室字典、人员主数据、收费项目与物价对照、成本中心与核算单元映射。

识别时不能只看系统名称，要落到具体表和字段。例如 HIS 中“收费明细”通常包含患者ID、就诊号、收费项目编码、数量、金额、执行科室、开单科室、收费时间；EMR 中“病案首页”提供主要诊断、手术编码、离院方式；LIS/PACS 提供检查检验的执行科室与执行时间。这些字段决定了后续能否按科室、按项目、按时间三个维度归集。若缺少“执行科室”或“开单科室”，绩效就无法区分“谁做的”和“谁开的”，这是最常见的口径缺口。

二、接口方式：按实时性和稳定性选择

常见接口方式有四种，选择依据是数据量、时效要求和源系统承受能力。

• 数据库直连（JDBC/ODBC）：直接读取源库视图或只读从库。优点是实现快、字段全；缺点是可能影响源库性能，且表结构变更会导致抽取失败。适合夜间批量抽取。
• 视图/中间表：由源系统厂商提供只读视图或定时写入中间表。稳定性优于直连，但需要厂商配合，变更周期长。
• 消息队列/CDC：通过 Kafka、Canal 等捕获增量变更，适合收费、医嘱等高频事件。延迟可控制在秒级，但需要处理乱序和重复。
• 文件/接口服务：厂商导出 CSV、XML 或提供 WebService/API。适合 PACS、财务等封闭系统，但文件格式和推送时间需约定。

实际工程中通常混合使用：HIS 收费走 CDC 或夜间批量，EMR 病案首页走文件交换，LIS/PACS 走视图，HRP 和财务走中间表。关键原则是不直接写源库、不在源库做复杂计算、不依赖源系统在线率。

三、数据抽取策略：全量、增量与拉链

抽取策略要解决三个问题：抽什么、抽多少、怎么合并。首次接入采用全量抽取建立基线，之后转为增量。增量识别优先使用源系统的时间戳字段（如 update_time、charge_time），没有时间戳时用自增主键或 CDC 日志。对于人员、科室、物价等缓慢变化维，采用拉链表保留历史归属，避免“现在科室”覆盖“当时科室”导致绩效追溯错误。

抽取频率按业务节奏设定：收费和医嘱每日一次或每小时一次；病案首页在出院后 T+1 抽取；HRP 成本数据按月抽取；财务凭证按会计期间抽取。每次抽取必须记录批次号、抽取时间、源表行数、目标表行数、失败行数，形成可核对的抽取日志。

-- 增量抽取示例（按收费时间）
SELECT patient_id, visit_id, item_code, qty, amount,
       exec_dept, order_dept, charge_time
FROM his.charge_detail
WHERE charge_time >= :last_watermark
  AND charge_time <  :current_watermark;
-- 水位线 last_watermark 存于 etl_job 表，成功后更新

四、集成难点与判断依据

集成难点集中在四类：主数据不一致（同一科室在 HIS、HRP、财务中编码不同）、时间口径不一致（收费时间、执行时间、出院时间混用）、数据质量缺口（执行科室为空、项目编码未对照）、源系统变更（字段改名、视图重建）。判断集成是否达标，可以看三个可观测指标：抽取日志中失败行数是否为 0；关键字段（执行科室、项目编码、金额）空值率是否低于约定阈值（例如 0.5%）；同一指标在平台与源系统报表中的差异是否可解释、可追溯。

五、落地建议

建议按“先事实、后口径、再成本”的顺序推进：第一周完成 HIS 收费与 EMR 病案首页接入，验证科室归集；第二周接入 LIS/PACS 执行数据，补齐项目维度；第三周接入 HRP 与财务，形成成本口径。每接入一个源，同步建立字段级对照表和空值监控，避免问题在核算阶段才暴露。集成不是一次性工程，源系统升级、科室调整、物价变更都会影响抽取结果，因此抽取日志、水位线和对照表必须纳入日常运维。