📚 课程目录第2章临床数据源系统剖析

2. 临床数据源系统剖析

临床数据仓库的第一道关口不是建模，而是把数据从各业务系统中"接出来"。HIS、EMR、LIS、RIS/PACS、药房、医保结算和可穿戴设备这七类系统，分别由不同厂商、在不同年代、按不同业务目标建设，它们的数据产生机制、接口方式、数据粒度和采集难点差异极大。理解这些差异，是设计抽取层（Staging/ODS）和后续主题域模型的前提。

一、各系统的数据产生机制与粒度

HIS（医院信息系统）是交易型主干系统，核心表围绕患者主索引、挂号、就诊、医嘱、收费展开。它的数据由前台业务操作实时触发写入，粒度通常是"一次就诊 + 一条医嘱/一条收费明细"。HIS 的强项是结构化程度高、主键清晰（如就诊号、医嘱号），弱项是字段语义常靠字典表解释，且历史版本多、字段含义随版本漂移。

EMR（电子病历）的数据产生机制与 HIS 不同：它由医生书写行为驱动，主体是病程记录、入院记录、手术记录、护理记录等半结构化或自由文本。粒度是"一份文书 + 文书内的段落/章节"。EMR 的采集难点在于文本非结构化、模板多样、同一语义在不同科室写法不同，需要靠自然语言处理或结构化模板抽取。

LIS（实验室信息系统）由检验仪器和人工审核共同产生数据。仪器通过 ASTM/HL7 协议把结果推送到 LIS，LIS 再关联申请单、标本、患者。粒度是"一个标本 + 一个检验项目 + 一次结果"。它的特点是数值型结果多、时间戳精确、有明确的参考区间和异常标志（H/L/危急值），是数据仓库中质量较高的数据源。

RIS/PACS 是影像链路。RIS 管理检查申请、预约、报告，PACS 存储 DICOM 影像。数据产生机制是"检查登记 → 影像采集 → 报告书写 → 审核发布"。粒度上，RIS 是"一次检查 + 一份报告"，PACS 是"一个检查序列 + 若干 DICOM 实例"。采集难点在于影像体积大、DICOM 元数据字段多、报告文本与影像需通过检查号关联。

药房系统覆盖门诊/住院发药、退药、库存和处方审核。数据由调剂和库存操作触发，粒度是"一张处方 + 一条发药明细"。它与 HIS 的医嘱、收费高度耦合，采集时要特别注意退药、拆零、批号效期等状态变化。

医保结算系统的数据产生于费用结算环节，粒度是"一次结算 + 一条费用明细 + 一条医保支付明细"。它的接口通常是对接医保局平台，数据格式受政策约束强，字段随医保版本调整，采集难点是政策口径变化和结算与临床数据的对账。

可穿戴设备是院外数据源，由设备按固定采样频率自动产生，粒度是"一个设备 + 一个时间点 + 一个指标"，如心率、血氧、步数、睡眠分期。它的采集难点是数据量大、时间戳可能不连续、设备型号多、传输协议不统一，且需要与患者身份做可靠绑定。

二、接口方式的选型逻辑

接口方式不是越新越好，而是要与源系统的能力和数据特征匹配。数据库直连或视图适合 HIS、LIS 这类关系型系统，优点是实现快、能拿到明细，缺点是直接读生产库可能影响性能，必须限定只读账号、错峰抽取，并优先使用增量字段（如更新时间、自增 ID）。HL7 v2 消息适合 EMR、LIS 的实时事件推送，能拿到"检查已发布""结果已审核"这类状态变化，但消息可能丢失或重复，需要幂等处理。WebService/REST 适合医保平台和部分 EMR，受接口限流和字段裁剪影响，往往拿不到全量明细。DICOM/DICOMweb 是影像链路的专用协议，元数据可通过 QIDO-RS 查询，影像本体通过 WADO-RS 拉取。可穿戴设备通常走厂商 SDK 或云 API，需要处理设备离线补传和时区问题。

选型原则：能增量不全量，能事件不轮询，能拿明细不拿汇总，能保留原始时间戳不改写。

三、采集难点与应对策略

第一类难点是主键与身份不一致。HIS 用就诊号，LIS 用标本号，PACS 用检查号，可穿戴设备用设备 ID，它们之间没有天然外键。应对方式是建立患者主索引（EMPI），用身份证、姓名、出生日期、手机号等做概率匹配，并保留匹配置信度和人工复核入口。

第二类难点是时间语义混乱。同一事件在 HIS 有开单时间、收费时间，在 LIS 有采样时间、上机时间、审核时间，在 PACS 有检查时间、报告时间。采集时必须区分"业务发生时间"和"系统记录时间"，统一时区，并保留原始字段，不能只留一个时间戳。

第三类难点是状态与版本。医嘱会作废、检验结果会复检、报告会修订、医保结算会冲正。如果只抽最终态，会丢失过程信息；如果全量保留，数据量又会膨胀。常见做法是采用拉链式或快照+变更日志的方式，在采集层保留变更轨迹，在主题层再取最新有效版本。

第四类难点是非结构化与半结构化数据。EMR 文本、PACS 报告、护理记录都需要抽取。可先用规则和模板解析结构化字段（如血压、体温），再用 NLP 抽取实体和关系，抽取结果要带置信度和原文定位，便于回溯。

四、采集配置示例

下面是一个 HIS 医嘱增量抽取的配置片段，用于说明关键参数如何落地。示例参数为教学假设，实际需按院内情况调整。

source:
  system: HIS
  type: oracle
  host: 10.10.20.31
  service: HISDB
  user: cdr_reader        # 只读账号
  table: V_ORDERS         # 视图，避免直连基表
  watermark_field: UPDATE_TIME
  watermark_init: 2024-01-01 00:00:00
  batch_size: 5000
  schedule: "0 */15 * * * *"   # 每15分钟增量
  fields:
    - ORDER_ID
    - VISIT_ID
    - PATIENT_ID
    - ORDER_TYPE
    - ORDER_CONTENT
    - START_TIME
    - UPDATE_TIME
target:
  layer: staging
  table: stg_his_orders
  dedup_key: [ORDER_ID, UPDATE_TIME]
  keep_raw: true
quality:
  - rule: ORDER_ID not null
  - rule: START_TIME <= UPDATE_TIME
  - rule: ORDER_TYPE in ('药品','检验','检查','手术')

运行后应观察三个指标：增量批次的行数是否稳定、水位字段是否持续推进、质量规则拦截率是否异常升高。如果某批次行数突然翻倍，通常是水位回退或重复抽取；如果拦截率升高，往往是源系统字段含义变化或字典更新。这些判断依据比"抽取成功"四个字更有实际价值。

五、采集层应交付的最小成果

每个数据源接入后，至少应形成一份源系统档案，包含：系统名称与厂商、接口方式与协议、抽取频率与水位字段、数据粒度与主键、关键字段清单、已知质量问题、责任人。这份档案是后续建模、血缘追踪和排障的基础，也是数据仓库可维护性的关键。

不要在没有源系统档案的情况下直接建模。字段含义、主键、时间语义和状态规则一旦理解错误，后续所有主题域都会继承这个错误。

把七类系统的产生机制、接口方式、粒度和难点梳理清楚，采集层才能做到"接得全、接得准、接得可追溯"。这是临床数据仓库从源头保证质量的第一步，也是后续主题域建模和指标计算能够成立的前提。