2. 医疗数据源识别与接入规划

多源医疗数据融合治理的第一步，不是急着建库、建表或写 ETL，而是把"数据从哪来、长什么样、怎么拿、先拿谁"这四件事说清楚。医院内部常见的数据源包括 HIS、LIS、PACS、EMR，外部则涉及可穿戴设备、医保结算和公共卫生上报。它们在数据模型、接口方式、更新频率、数据体量和合规约束上差异极大，若不加区分地统一接入，往往会在项目早期就陷入接口反复、字段对不上、历史数据补不齐的困境。因此，本节的核心任务是建立一套可操作的"数据源画像 + 接入优先级 + 可行性评估"方法。

一、七类数据源的特征画像

HIS（医院信息系统）是院内业务的主干，承载挂号、收费、医嘱、住院、药品与物资等事务性数据。它的特点是事务性强、更新频繁、主键体系相对稳定，通常以患者 ID、就诊号、住院号为核心关联键。HIS 一般由大型厂商（如东华、卫宁、创业慧康等）交付，数据库多为 Oracle 或 SQL Server，接口以视图、存储过程或 HL7 v2 消息为主。接入 HIS 的价值在于它是"就诊主索引"的来源，是其他数据源对齐的锚点。

LIS（实验室信息系统）管理检验申请、标本流转与检验结果。它的数据特点是结构化程度高、结果值带单位与参考区间、时间戳精确。LIS 接口常见为 HL7 v2 ORU^R01 消息或数据库视图，部分厂商提供 WebService。LIS 的难点不在结构，而在项目字典与结果编码的标准化——同一检验项目在不同医院可能用不同代码，需要映射到 LOINC 等标准。

PACS（影像归档与通信系统）存储 DICOM 影像及检查报告。它的数据体量最大，单次 CT 检查可达数百 MB，接口以 DICOM C-STORE/C-FIND 和 DICOMweb（WADO-RS、QIDO-RS）为主。PACS 接入的关键不是"能不能拿"，而是影像与报告、检查申请之间的关联，以及存储与传输成本。通常建议先接报告文本（结构化或半结构化），影像按需调阅。

EMR（电子病历）包含病程记录、护理记录、手术记录等大量半结构化与自由文本。它的接口形式多样，可能是 CDR 视图、文档对象或 HL7 CDA 文档。EMR 的价值在于临床语义丰富，但治理难度最高，需要 NLP 抽取与后结构化。接入 EMR 应优先选择结构化程度较高的部分（如入院记录、出院小结的固定字段），再逐步扩展到自由文本。

可穿戴设备（如动态心电、连续血糖、智能手环）产生高频、时序、个体化的数据。接口多为厂商云 API 或蓝牙网关，数据格式不统一，采样频率从秒级到分钟级不等。其核心挑战是设备标识与患者身份的绑定，以及时间对齐与数据质量（脱落、伪差）。

医保结算数据来自医保局或医院医保办，包含费用明细、诊断编码、结算金额等。它以批次、周期性方式提供，通常为文件交换（CSV/XML）或前置机接口。医保数据的价值在于费用与病种分析，但更新滞后、字段口径受政策影响大。

公共卫生上报数据涉及传染病报告、慢病登记、死亡登记等，通过国家或省级平台上报。它的特点是上报口径固定、字段标准化程度较高，但获取通常需要审批，且多为汇总或脱敏数据。

二、接入优先级：以"主索引锚点"为判断依据

优先级不是按数据源"名气"排序，而是按它能否为其他数据源提供关联锚点来排序。HIS 提供患者主索引与就诊主索引，LIS 和 PACS 都通过就诊号与之关联，因此 HIS 和 LIS 应列为 P0。EMR 和 PACS 虽然价值高，但体量大、治理复杂，列为 P1。可穿戴与医保结算属于补充维度，列为 P2。公共卫生上报通常为汇总数据，列为 P3。

一个实用的判断口诀是：先接"能当钥匙的"，再接"能当内容的"，最后接"只能当补充的"。如果医院尚未建立患者主索引（EMPI），那么 HIS 接入的第一件事就是抽取患者基本信息与就诊记录，构建 EMPI 候选集，而不是急着接检验结果。

三、工程可行性评估的四个维度

优先级高不等于马上能接。可行性评估要回答四个问题：

• 接口可得性：厂商是否开放接口？是标准协议还是私有协议？是否需要商务授权？
• 数据可理解性：字段是否有文档？编码字典是否可获取？是否需要现场调研？
• 性能与稳定性：接口能否承受批量抽取？是否会影响生产库性能？是否需要只读从库？
• 合规与安全：是否涉及患者隐私？是否需要脱敏？数据传输是否加密？

以某三甲医院为例，HIS 为 Oracle 数据库，厂商提供只读视图，但要求通过独立账号访问并限制查询时段；LIS 提供 HL7 v2 消息，但检验项目字典需要人工映射；PACS 的 DICOMweb 接口可用，但影像存储成本高，决定先接报告文本。这些约束直接决定了接入顺序和实现方式。

四、接入规划的可执行清单

在完成画像与评估后，应形成一份可执行的接入规划清单。清单至少包含：数据源名称、接口类型、接入方式（实时/批量）、主键字段、目标存储、优先级、责任方、风险点。以下是一个示例片段：

数据源: HIS
接口类型: Oracle 只读视图
接入方式: 每日增量 + 实时变更捕获
主键字段: PATIENT_ID, VISIT_ID
目标存储: ODS 层 his_patient / his_visit
优先级: P0
责任方: 信息科 + HIS 厂商
风险点: 生产库查询时段受限，需申请独立账号

数据源: LIS
接口类型: HL7 v2 ORU^R01
接入方式: MLLP 实时接收
主键字段: VISIT_ID, SPECIMEN_ID
目标存储: ODS 层 lis_result
优先级: P0
责任方: 检验科 + LIS 厂商
风险点: 检验项目字典需映射至 LOINC

五、常见误区与规避

第一个误区是先接数据量小的源，因为"容易出成果"。但小数据源往往缺乏主键关联能力，接进来也形成不了有价值的融合视图。第二个误区是忽视字典映射，直接按字段名对齐，导致检验项目、诊断编码、药品编码无法跨源比较。第三个误区是把接口可用性等同于数据可用性，接口通了不代表字段完整、时间戳准确、历史数据可补。规避方法是在接入前做一次小样本试抽，验证字段填充率、时间戳合理性和主键唯一性，再决定是否进入正式接入。

综上，数据源识别与接入规划的本质，是在"业务价值"与"工程可行性"之间找到一条可落地的路径。先画像、再排序、后评估、最后形成清单，每一步都应有明确的判断依据和可验证的输出，而不是凭经验拍板。