3. 健康数据模型与标准化

数字健康管理平台最棘手的问题，往往不是“能不能采集到数据”，而是“采集到的数据能不能被理解、被复用、被交换”。同一次血压测量，在设备端可能叫 BP_SYS，在体检系统里叫“收缩压”，在App里叫“高压”，单位可能是 mmHg 也可能是 kPa；同一位用户的“糖尿病”诊断，在不同系统里可能是 ICD-10 的 E11.9、SNOMED CT 的概念码，或一句自由文本。健康数据模型与标准化的任务，就是把这些“各自表述”统一成机器可计算、跨系统可交换的语义结构。

一、健康信息模型：从“字段”到“语义结构”

健康信息模型是对健康相关实体及其关系的抽象描述。它至少要回答四类问题：谁（患者/居民/用户）、发生了什么（观察、诊断、用药、手术、随访）、何时发生（时间戳、时间段、频率）、由谁记录与依据什么（记录者、来源设备、机构、编码系统）。一个可用的模型通常包含：主体（Patient/Person）、事件（Encounter/Observation/MedicationStatement）、临床概念（CodeableConcept）、值（Quantity/ValueSet）、时间（effectiveDateTime/Period）以及溯源（Provenance）。

以一次家庭血压测量为例，若只存 {user_id, sys, dia, time}，平台无法判断这是坐位还是卧位、是左臂还是右臂、是家用电子血压计还是诊室水银柱。而按信息模型展开，应记录：观察对象（患者）、观察类型（收缩压/舒张压，带编码）、数值与单位、测量条件（体位、部位、设备类型）、时间、数据来源（设备序列号或手工录入）。这些“上下文”决定了数据能否用于后续的风险分层与临床解读。

二、FHIR 与 OMOP：交换标准与分析标准的分工

FHIR（Fast Healthcare Interoperability Resources）是面向交换与互操作的现代标准，以“资源（Resource）”为单位，如 Patient、Observation、Condition、MedicationRequest、Encounter。它强调 RESTful API、JSON/XML 表达、术语绑定（CodeSystem/ValueSet）与扩展（Extension）。FHIR 适合做平台与医院、可穿戴设备、区域健康档案之间的实时接口。

OMOP CDM（Observational Medical Outcomes Partnership Common Data Model）则是面向分析与研究的公共数据模型，把不同来源的数据映射到统一的表结构（PERSON、VISIT_OCCURRENCE、CONDITION_OCCURRENCE、DRUG_EXPOSURE、MEASUREMENT 等），并配合标准词汇表（SNOMED、LOINC、RxNorm 等）实现跨数据库的队列分析与药物安全监测。二者不是替代关系：FHIR 负责“把数据接进来、传出去”，OMOP 负责“把数据放到同一张分析桌上”。

三、指标编码体系：让“同一个指标”只有一个身份

编码体系是标准化的“字典”。在健康管理平台中，最常用的组合是：LOINC 标识检验与观察项目（如 8480-6 收缩压、8462-4 舒张压、2339-0 血糖），SNOMED CT 表达临床概念与发现（如“2型糖尿病”），ICD-10/11 用于诊断分类与医保结算，RxNorm/ATC 标识药品，UCUM 统一单位（如 mm[Hg]、mg/dL、kg/m2）。

实际落地时，平台应维护一张“指标映射表”，把设备原始字段、业务字段与标准编码关联起来。例如：设备字段 bp_sys → LOINC 8480-6 → 显示名“收缩压” → 单位 mm[Hg] → 参考范围 90–139。这样，无论数据来自哪台设备，进入平台后都归一到同一语义。对于无法直接映射的本地指标，应建立本地码（Local Code）并标注“待映射”，避免用自由文本充当编码。

四、个人健康档案建模：以“人”为主线的纵向记录

个人健康档案（PHR/EHR）不是一次就诊的切片，而是围绕同一位居民、跨越时间与机构的纵向记录。建模时建议以“主索引（EMPI）”为锚点，把身份、联系方式、保险、过敏史、慢病诊断、用药、检验检查、随访、生活方式等组织为若干资源或表，并保留时间轴与来源。关键设计点包括：

• 主索引与合并：同一人可能有多条记录，需通过身份证、手机号、医保号等做匹配与合并，合并后保留历史链接。
• 时间语义：区分“发生时间”与“记录时间”，前者用于临床判断，后者用于审计与数据质量评估。
• 状态与版本：诊断、用药会修正或停止，应保留状态（active/resolved/entered-in-error）与版本，而不是覆盖删除。
• 隐私与授权：敏感信息（精神疾病、传染病）需按授权范围隔离，FHIR 中可用 Security Label 与 Consent 资源表达。

五、数据字典与元数据管理：标准化的“施工图”

数据字典描述每个字段的名称、含义、类型、长度、取值范围、单位、是否必填、编码系统、来源与责任人。元数据管理则进一步记录数据的血缘（从设备到平台到分析表）、版本、质量规则与更新频率。一个可执行的数据字典条目示例：

元数据管理还应包含“映射规则”的版本控制。例如，当 LOINC 或 SNOMED 版本升级、或本地码调整时，必须记录映射变更时间、影响范围与回滚方案，否则历史数据可能被错误解释。对于 OMOP 分析层，还需维护“源值—标准概念”的映射表（source_to_concept_map），并定期做覆盖率与冲突检查。

总结来看，健康数据模型与标准化是数字健康管理平台的“语义底座”：信息模型定义结构，FHIR/OMOP 分别解决交换与分析，编码体系赋予指标唯一身份，个人健康档案把数据组织成以人为中心的纵向记录，数据字典与元数据管理则保证这套体系可维护、可审计、可演进。只有底座稳固，上层的风险分层、个性化干预与质量评估才具备可信的数据基础。