📚 课程目录第4章医疗数据标准与术语体系

4. 医疗数据标准与术语体系

多源医疗数据融合治理的第一道硬门槛，不是算力，也不是接口，而是“同一个概念在不同系统里叫什么、怎么编码、能不能对上”。临床诊断写“2型糖尿病”，病案首页用 ICD-10 编码 E11.9，护理记录可能写“T2DM”，检验系统只认 LOINC 编码，药品医嘱走 RxNorm 或院内码，影像又落在 DICOM 的私有字段里。如果这些编码体系之间没有明确的映射关系，融合后的数据表看似字段齐全，实际无法做人群统计、科研队列或跨机构交换。本节围绕六类核心标准，说明它们各自管什么、在融合治理中如何映射与落地。

六类标准的分工与边界

先建立一张“标准—管辖对象—典型标识”的对应关系，避免把术语标准和交换标准混为一谈。

标准	主要管辖对象	典型标识/结构	融合治理中的角色
ICD-10/ICD-11	疾病诊断、手术操作分类	E11.9、I10、ICD-9-CM-3 手术码	病案统计、医保结算、诊断归一
SNOMED CT	临床概念（症状、诊断、操作、解剖）	SCTID，如 44054006	细粒度临床语义、跨术语映射枢纽
LOINC	检验检查项目与观测	LOINC 码，如 4548-4（HbA1c）	检验结果跨院对齐
RxNorm	药品、成分、剂型、规格	RxCUI，如 860975	用药归一、药物相互作用分析
HL7 FHIR	数据交换的资源与接口	Patient、Observation、MedicationRequest 等资源	融合平台对外/对内交换骨架
DICOM	医学影像及其元数据	SOP Class/Instance UID、Tag 字段	影像归档、影像与临床数据关联

关键区别在于：ICD、SNOMED CT、LOINC、RxNorm 属于术语/编码标准，解决“概念怎么表示”；FHIR 属于交换与信息模型标准，解决“数据怎么组织和传输”；DICOM 则是影像领域的专用标准，既定义影像格式，也定义影像元数据。融合治理中，术语标准负责语义对齐，FHIR 负责结构承载，DICOM 负责影像侧接入，三者缺一不可。

映射落地的关键方法

术语映射不是“查字典”那么简单，实际工程中要处理一对多、多对一、粒度不匹配和上下文依赖四类问题。以诊断为例，院内 ICD-10 编码 E11.9（2型糖尿病不伴并发症）在 SNOMED CT 中对应 44054006（Diabetes mellitus type 2），但 SNOMED CT 还细分了“2型糖尿病伴肾病”“2型糖尿病伴视网膜病变”等更细概念。如果融合目标只是统计糖尿病患病率，映射到 44054006 即可；如果要做并发症分析，就必须保留 ICD-10 的亚目层级，不能粗暴合并。

检验项目映射到 LOINC 时，最容易被忽略的是“三要素匹配”：分析物 + 属性/时间 + 标本类型。例如“空腹血糖”对应 LOINC 1558-6（Glucose [Mass/volume] in Serum or Plasma），而“随机血糖”对应 2339-0。如果只按“血糖”两个字匹配，就会把空腹和随机混为一谈，导致统计偏差。实操中建议建立映射表时至少保留以下字段：

term_mapping 表结构示例
--------------------------------------------------------------
source_system   | 源系统标识，如 HIS_A
source_code     | 源编码，如 E11.9
source_name     | 源名称，如 2型糖尿病不伴并发症
target_standard | 目标标准，如 SNOMEDCT / LOINC / RxNorm
target_code     | 目标编码，如 44054006
target_name     | 目标名称，如 Diabetes mellitus type 2
map_type        | 映射类型：1对1 / 1对多 / 多对1 / 近似
confidence      | 置信度 0~1，人工审核后置为 1.0
review_status   | 待审核 / 已审核 / 已驳回
--------------------------------------------------------------

药品映射到 RxNorm 时，要区分“成分级”和“临床药品级”。RxNorm 的 RxCUI 860975 对应“Metformin 500 MG Oral Tablet”，而成分级 6809 只表示“Metformin”。如果融合目标是药物相互作用分析，应映射到成分级；如果是处方合理性审查，则映射到临床药品级。DICOM 侧则不需要做术语映射，而是通过 StudyInstanceUID 与 FHIR 的 ImagingStudy 资源建立关联，把影像检查与患者、诊断、检验结果串起来。

映射表上线前，建议抽取 200~500 条真实数据做“回放验证”：用映射后的编码反查原始记录，检查是否出现语义漂移。例如把“妊娠期糖尿病”误映射到“2型糖尿病”，在回放中会表现为同一患者同时出现两个互斥诊断，这类错误比编码缺失更危险。

FHIR 作为融合骨架的落地要点

FHIR 的价值在于把映射后的术语装进统一结构。以一条检验结果为例，Observation 资源中 code 字段放 LOINC 编码，valueQuantity 放数值和单位，subject 指向 Patient，encounter 指向就诊，effectiveDateTime 放采样时间。这样无论数据来自哪家医院，只要映射正确，下游查询就可以统一按 LOINC 码检索。实操中要注意 FHIR 的扩展机制：国内医院常用的“检验仪器型号”“标本采集人”等字段，标准资源里没有，应通过 extension 扩展，而不是塞进 text 字段。

DICOM 与 FHIR 的衔接通常走两条路：一是 PACS 侧提供 DICOMweb 接口，融合平台按 StudyInstanceUID 拉取影像元数据；二是通过 FHIR 的 ImagingStudy 资源登记检查信息，再与 DICOM 的 Series/Instance 层级做关联。无论哪条路，都要保证患者主索引（EMPI）在两侧一致，否则会出现“影像找到了、患者对不上”的典型问题。

常见误区：把 ICD 当作临床语义标准直接用于科研队列。ICD 是为统计和结算设计的分类体系，粒度粗、更新慢，不适合表达“左肺上叶腺癌伴 EGFR 突变”这类精细概念。正确做法是 ICD 用于统计口径，SNOMED CT 用于临床语义，两者通过映射表关联，而不是互相替代。

落地检查清单

是否明确了每个源系统的编码体系及其版本（如 ICD-10 国临版 vs 医保版）？
映射表是否包含置信度和审核状态，是否支持人工复核？
LOINC 映射是否校验了标本类型和时间属性，避免空腹/随机混淆？
RxNorm 映射是否区分成分级与临床药品级，是否保留原商品名？
FHIR 资源是否使用标准字段承载术语编码，扩展字段是否登记了 URL 和类型？
DICOM 与 FHIR 的患者主索引是否一致，StudyInstanceUID 是否可作为关联键？
是否建立了映射版本管理，标准升级时能追溯历史映射关系？

把这六类标准的关系理清后，融合治理的后续工作——数据抽取、清洗、入湖、质量评估——才有稳定的语义底座。标准不是束缚，而是让不同来源的数据在同一个坐标系里可比较、可计算、可追溯的前提。