📚 课程目录第4章健康数据标准化与互操作

4. 健康数据标准化与互操作

家庭健康管理平台的数据来源极其分散：智能手环记录步数与心率，电子血压计上传收缩压/舒张压，血糖仪产生指尖血糖值，用户手动录入用药与症状，医院导出的 PDF 报告又包含检验结果。如果每个设备、每个厂商都用自定义字段名和自定义编码，平台很快会陷入“数据能存不能用”的困境——同一个“收缩压”可能出现 sys_bp、SBP、高压 三种写法，无法聚合、无法比较、无法与医院数据对接。标准化与互操作要解决的正是这个问题：让不同来源的数据在语义层面对齐，在结构层面可交换。

四类标准的分工

在家庭健康场景中，最常被一起提及的是 HL7 FHIR、OMOP CDM、LOINC 和 SNOMED CT，但它们并不是同一层面的竞争关系，而是分工协作：

HL7 FHIR 是数据交换与资源建模标准，定义 Observation、Patient、MedicationStatement 等资源及其 RESTful 接口，解决“数据怎么传、怎么组织成一条可交换记录”。
LOINC 是观测指标与检验项目的编码体系，解决“这个测量项到底是什么”，例如收缩压对应 8480-6，空腹血糖对应 1558-6。
SNOMED CT 是临床术语与概念体系，覆盖症状、疾病、操作、身体部位等，解决“这个临床概念是什么”，例如“2 型糖尿病”有唯一概念标识。
OMOP CDM 是面向分析与研究的通用数据模型，把不同来源数据映射到统一的 person、measurement、drug_exposure 等表，解决“数据怎么统一存放以便统计与队列分析”。

可以这样理解：FHIR 管“传输与结构”，LOINC/SNOMED CT 管“语义编码”，OMOP 管“分析存储”。家庭平台通常以 FHIR 作为对外交换与内部资源建模的主干，用 LOINC/SNOMED CT 做编码绑定，再把需要长期分析的数据 ETL 到 OMOP。

FHIR 在家庭场景的裁剪

完整 FHIR 规范包含上百种资源，直接照搬会让家庭平台开发成本过高。合理的裁剪策略是：只保留与家庭监测强相关的资源，并约束必填字段。以一次血压测量为例，一条 Observation 资源至少需要以下要素：

{
  "resourceType": "Observation",
  "status": "final",
  "category": [{ "coding": [{ "system": "http://terminology.hl7.org/CodeSystem/observation-category",
                              "code": "vital-signs" }] }],
  "code": { "coding": [{ "system": "http://loinc.org", "code": "85354-9",
                         "display": "Blood pressure panel" }] },
  "subject": { "reference": "Patient/family-001" },
  "effectiveDateTime": "2025-03-12T08:15:00+08:00",
  "component": [
    { "code": { "coding": [{ "system": "http://loinc.org", "code": "8480-6" }] },
      "valueQuantity": { "value": 128, "unit": "mm[Hg]",
                         "system": "http://unitsofmeasure.org", "code": "mm[Hg]" } },
    { "code": { "coding": [{ "system": "http://loinc.org", "code": "8462-4" }] },
      "valueQuantity": { "value": 82, "unit": "mm[Hg]",
                         "system": "http://unitsofmeasure.org", "code": "mm[Hg]" } }
  ]
}

这里的关键点有三处：code 使用 LOINC 85354-9 表示“血压面板”，收缩压与舒张压分别用 8480-6 和 8462-4 作为 component；单位使用 UCUM 的 mm[Hg]，而不是中文“毫米汞柱”；effectiveDateTime 必须带时区，否则跨设备聚合时会出现时间错位。家庭平台可以进一步约束：status 只允许 final 或 amended，subject 必须指向本平台患者资源，从而减少脏数据。

LOINC 与 SNOMED CT 的绑定实践

LOINC 负责“测什么”，SNOMED CT 负责“是什么临床概念”。在家庭场景中，常见绑定关系如下表所示：

家庭数据项	LOINC 编码	SNOMED CT 概念	UCUM 单位
收缩压	8480-6	271649006（Systolic BP）	mm[Hg]
舒张压	8462-4	271650006（Diastolic BP）	mm[Hg]
空腹血糖	1558-6	271062006（Fasting glucose）	mg/dL
体重	29463-7	27113001（Body weight）	kg
步数	55423-8	129019007（Step count）	{steps}
2 型糖尿病	—	44054006（Type 2 diabetes）	—

需要注意，LOINC 与 SNOMED CT 并非一一对应。LOINC 偏观测与检验，SNOMED CT 偏临床概念与诊断。家庭平台在存储时建议同时保留两套编码：观测值用 LOINC，诊断与症状用 SNOMED CT，避免用 LOINC 硬编码疾病名称。

OMOP CDM 的映射与 ETL

当平台需要做“家庭血压控制率”“用药依从性与血糖关系”这类分析时，FHIR 资源并不适合直接跑 SQL。此时把数据 ETL 到 OMOP CDM 更高效。以血压 Observation 为例，映射到 measurement 表的关键字段包括：

measurement_concept_id：由 LOINC 8480-6 映射到 OMOP 标准概念 ID（如 3004249）。
person_id：由 FHIR Patient 映射到 OMOP person。
measurement_date：取 effectiveDateTime 的日期部分。
value_as_number：取 valueQuantity.value，如 128。
unit_source_value：保留原始单位 mm[Hg]，便于回溯与单位换算校验。

ETL 过程中最常见的错误是单位未归一。例如某血糖仪上传 7.1 mmol/L，而 OMOP 分析层默认 mg/dL，若不换算就会把 7.1 当成 7.1 mg/dL，导致严重误判。正确做法是在编码绑定阶段就统一到 UCUM 目标单位，并在 unit_source_value 中保留原值，形成可审计链路。

实践建议：家庭平台不必一开始就追求全量标准覆盖。优先把血压、血糖、体重、步数、用药五类数据完成 LOINC/SNOMED CT 绑定与 FHIR 资源化，再逐步扩展。每新增一个设备类型，先确认其输出字段能否映射到已有编码，不能映射时再评估是否需要新增 LOINC 或 SNOMED CT 概念。

常见误区：把 FHIR 当成数据库直接使用。FHIR 是交换与资源建模标准，不是为高频聚合查询设计的。家庭平台应把 FHIR 作为对外接口与内部资源层，分析类查询走 OMOP 或专用时序库，避免在 FHIR 资源上做复杂 JOIN。

标准化不是一次性工作，而是持续治理过程。建议平台建立一张“字段—编码—单位—来源设备”映射表，每次接入新设备或新报告格式时先查表、再映射、后入库。这样既能保证数据可聚合，也能在出现异常值时快速定位是设备问题、编码问题还是单位问题。