3. 医疗数据标准与互操作工程

医疗真实世界数据平台最棘手的工程问题，往往不是“存不下”，而是“对不上”。同一名患者，在电子病历里叫“张某某”，在检验系统里是“门诊号 20240517-0031”，在医保结算里又变成“医保卡号 3301****2217”；同一个“空腹血糖”，在不同系统里可能写作“GLU”“血糖(空腹)”“Fasting blood glucose”，单位有 mmol/L 也有 mg/dL。标准与互操作工程要解决的，就是把这些分散、异构、语义不一致的数据，映射到统一、可计算、可追溯的模型上。

本节不逐一复述各标准的定义，而是围绕“平台落地映射”这一核心任务，说明六类标准各自扮演什么角色、在数据流中处于什么位置、以及如何协同完成从原始数据到分析就绪数据的转换。

六类标准在平台中的分工

可以把平台的数据链路理解为“采集—交换—标准化—分析”四层，六类标准分别在不同层承担不同职责：

• HL7 FHIR：面向交换与接口。以 Resource（资源）为单位组织数据，如 Patient、Observation、Encounter、MedicationRequest。平台通常用 FHIR 作为院内系统对接、第三方应用接入和 API 暴露的“通用语言”。
• CDISC：面向临床研究与监管递交。SDTM 规定采集数据的标准结构，ADaM 规定分析数据集结构。真实世界研究若要支持注册申报，需要把平台数据映射到 SDTM/ADaM 域。
• OMOP CDM：面向观察性数据分析。以 PERSON、VISIT_OCCURRENCE、DRUG_EXPOSURE、MEASUREMENT、CONDITION_OCCURRENCE 等表为核心，配合标准概念表（CONCEPT）和词汇映射表，支持跨机构、跨数据库的队列发现与统计建模。
• ICD-10/11：疾病诊断与分类编码，用于病种识别、分组和统计上报。ICD-11 在结构和粒度上有较大变化，平台需同时支持两版并处理版本间映射。
• LOINC：检验检查项目与观测指标的标识体系，解决“同一指标不同名称”的问题，是 MEASUREMENT 表映射的关键目标词表。
• SNOMED CT：临床术语本体，覆盖症状、诊断、操作、解剖部位等，具有层级和关系语义，适合做概念归一和语义推理。

这六类标准不是并列替代关系，而是互补协同：FHIR 管“怎么传”，CDISC 管“怎么报”，OMOP 管“怎么算”，ICD/LOINC/SNOMED 管“叫什么、归到哪”。

落地映射的关键工程动作

标准落地不是“选一个标准就完事”，而是建立一条可追溯的映射链。以“空腹血糖”为例，典型映射过程如下：

1. 源字段识别：从 LIS 检验结果表中找到项目代码 GLU_FAST、结果值 5.6、单位 mmol/L、参考范围 3.9–6.1。
2. 术语归一：将 GLU_FAST 映射到 LOINC 代码 1558-6（Fasting glucose [Mass/volume] in Serum or Plasma），单位统一为 mmol/L。
3. 模型落位：在 OMOP CDM 中写入 MEASUREMENT 表，measurement_concept_id 取 LOINC 对应标准概念 ID，value_as_number 存 5.6，unit_concept_id 取 UCUM 的 mmol/L 概念。
4. 交换暴露：通过 FHIR 的 Observation 资源对外提供，code 使用 LOINC 编码，valueQuantity 带单位，subject 指向 Patient 资源。
5. 研究递交：若该数据进入临床研究，再映射到 CDISC SDTM 的 LB 域，LBTESTCD 取 GLUC，LBORRES 存原始值，LBSTRESN 存标准化数值。

这条链上，ICD 负责诊断侧的分类，SNOMED CT 负责症状、操作等更细粒度的临床概念，LOINC 负责检验检查指标，OMOP CDM 负责分析模型，FHIR 负责接口交换，CDISC 负责研究递交。六者各司其职，缺一不可。

映射表设计示例

平台中通常需要维护一张“术语映射表”，记录源系统、源编码、目标标准、目标编码、映射类型、版本和审核状态。以下是一个可参考的字段结构示例：

版本管理与冲突处理

标准本身在演进：ICD-10 向 ICD-11 过渡、LOINC 每年多次发布、SNOMED CT 有国际版和各国扩展版、FHIR 有 R4/R5 等版本。平台必须把“标准版本”作为一等公民管理，而不是把编码写死在 ETL 脚本里。

常见冲突包括：同一源编码在不同版本下映射到不同目标编码；同一目标概念被多个源编码重复映射；单位不一致导致数值量纲错误。处理策略是：

• 映射表按“源系统 + 源编码 + 标准版本”建立唯一约束，避免版本混用。
• 对单位不一致的检验指标，在映射时同时记录原始单位和标准单位，并保留换算公式。
• 对无法自动映射的字段，进入人工复核队列，不允许静默丢弃。
• 每次标准升级，先跑影响分析：哪些映射会失效、哪些分析结果会变化，再决定升级窗口。

从映射到可计算：一个最小闭环

判断标准落地是否成功，不看映射表有多少行，而看能否回答一个真实的临床问题。例如：“在 2023 年 1 月至 2024 年 6 月期间，本院 2 型糖尿病患者的空腹血糖控制率是多少？”

要回答这个问题，平台需要：用 ICD-10/11 或 SNOMED CT 识别 2 型糖尿病患者；用 LOINC 1558-6 找到空腹血糖观测；用 OMOP CDM 的 MEASUREMENT 和 CONDITION_OCCURRENCE 做关联；用 FHIR Observation 暴露给前端；若用于研究递交，再转成 CDISC LB 域。整条链路打通，才说明标准映射真正落地。

因此，标准与互操作工程的核心交付物不是“用了哪些标准”，而是一套可维护、可追溯、可版本化的映射资产，以及围绕它建立的 ETL、质控和复核机制。只有把标准变成平台内部可执行的数据契约，真实世界数据才能真正从“能存”走向“能用”。