4. PERSON 与人口学信息映射
PERSON 表是 OMOP CDM 中所有临床事件的“人口学锚点”。任何一条 VISIT_OCCURRENCE、CONDITION_OCCURRENCE 或 DRUG_EXPOSURE 记录，最终都要通过 person_id 关联回 PERSON，才能获得年龄、性别、种族等分析维度。因此 PERSON 映射的质量直接决定了后续所有队列筛选、分层分析和生存分析的可信度。本节聚焦 PERSON 与 DEATH 两张表，讨论从源系统人口学字段到 CDM 标准字段的转换规则，以及必须同步完成的隐私处理。
一、PERSON 表的核心字段与映射来源
PERSON 表在 OMOP CDM v5.4 中主要包含以下字段：person_id、gender_concept_id、year_of_birth、month_of_birth、day_of_birth、birth_datetime、race_concept_id、ethnicity_concept_id、location_id、provider_id、care_site_id、person_source_value、gender_source_value、gender_source_concept_id、race_source_value、race_source_concept_id、ethnicity_source_value、ethnicity_source_concept_id。其中 person_id 是本地生成的代理主键，其余字段分为“标准概念字段”和“源值留存字段”两类。
映射的基本模式是：源系统的原始值先写入 *_source_value，再通过概念映射得到 *_concept_id。例如源系统性别字段存的是“M/F/未知”，则 gender_source_value 保留原值，gender_concept_id 映射为 8507（MALE）、8532（FEMALE）或 0（未知）。这种“双轨留存”设计既保证了分析时使用标准概念，又保留了可追溯性，便于后续审计和映射质量核查。
二、患者标识与隐私处理
person_id 必须是本地生成的整数，不能直接使用源系统的病历号、身份证号或医保号。常见做法是维护一张“源标识—person_id”对照表，在 ETL 过程中通过哈希或自增序列生成 person_id。person_source_value 可以存放源系统的患者唯一标识，但若该标识本身是敏感信息（如身份证号），应先做不可逆哈希再写入，避免在 CDM 中直接暴露。
隐私红线：person_source_value 不得存放明文身份证号、手机号、姓名或完整病历号。若业务确需保留可追溯性，应使用带盐的 SHA-256 哈希，并将盐值存放在 ETL 配置的安全位置，不随 CDM 数据一起分发。
三、出生日期：精度降级与 birth_datetime 的取舍
出生日期是隐私风险最高的字段之一。OMOP 允许 year_of_birth 必填，month_of_birth 和 day_of_birth 可选。工程上通常采用“精度降级”策略：当源数据只有年份时，只填 year_of_birth；当有完整日期时，可填 year/month/day，但很多机构出于隐私考虑会统一只保留年份，或将日期偏移到每年 1 月 1 日或 6 月 15 日。
birth_datetime 是 datetime 类型，用于需要精确到时刻的场景（如新生儿研究）。若源系统只有日期，可将其转换为当天 00:00:00 写入，但必须在 ETL 文档中明确标注“时间部分为占位值”。若源系统日期缺失，year_of_birth 也不能为空，此时应使用一个约定的哨兵值（如 1900）并在数据质量报告中标记，而不是留 NULL 导致后续年龄计算失败。
四、性别、种族与民族的标准化
性别映射相对直接：源值“男/女/M/F/1/2”分别映射到 8507/8532。需要注意的是，部分源系统存在“未知”“其他”“未说明”等值，这些应统一映射到 0（Unknown），而不是强行归入某一性别。若源系统使用 HL7 Administrative Gender 代码，可直接按 M→8507、F→8532、UN→0 的规则处理。
种族（race）和民族（ethnicity）在 OMOP 中是两个独立字段。race_concept_id 使用 Race 词汇表，常见概念包括 8527（White）、8516（Black or African American）、8515（Asian）、8557（Native Hawaiian or Other Pacific Islander）、8657（American Indian or Alaska Native）等。ethnicity_concept_id 使用 Ethnicity 词汇表，主要区分 38003563（Hispanic or Latino）和 38003564（Not Hispanic or Latino）。中国数据源中，民族字段（如“汉族”“回族”）通常映射到 race_concept_id，而 ethnicity 可统一映射为 38003564 或 0，具体取决于研究需求。
五、DEATH 表的映射与一致性校验
DEATH 表结构简单：person_id、death_date、death_datetime、death_type_concept_id、cause_concept_id、cause_source_value、cause_source_concept_id。死亡日期来自源系统的死亡登记、病案首页或随访记录。death_type_concept_id 用于标识死亡信息的来源类型，例如 32817（EHR）或 32510（死亡证明）。
关键校验点：DEATH 表中的 person_id 必须存在于 PERSON 表；death_date 不得早于出生日期；若同一患者有多条死亡记录，应保留最早或最可信的一条，并在 ETL 日志中记录冲突。死亡日期同样属于高敏感字段，若研究不需要精确日期，可只保留年份或将日期偏移到月份级别。
六、映射质量校验与常见陷阱
完成映射后，至少应执行以下校验：person_id 是否唯一且非空；year_of_birth 是否在合理范围（如 1900–当前年份）；gender_concept_id 是否只出现 8507、8532、0 三个值；race_concept_id 和 ethnicity_concept_id 是否存在于对应词汇表；DEATH 表中 person_id 是否都能在 PERSON 中找到；death_date 是否不早于出生日期。这些校验应作为 ETL 流水线的固定环节，而不是一次性人工检查。
常见陷阱包括：把源系统的“未知性别”映射成 0 后，在分析时被误当作“其他”参与统计；出生日期只保留年份后，年龄计算出现 ±1 岁误差；DEATH 表与 PERSON 表使用了两套不同的 person_id 生成逻辑，导致关联失败；race 和 ethnicity 字段互换，把“汉族”写进了 ethnicity_concept_id。这些问题在数据量小时不易发现，一旦进入多中心研究就会放大为系统性偏差。
建议在 ETL 配置中维护一张“源值—标准概念”映射表，将性别、种族、民族的映射规则外置为可配置的 CSV 或数据库表。这样当源系统新增代码值或 OMOP 词汇表升级时，只需更新映射表而无需修改 ETL 代码，同时映射表本身也可以作为数据治理的审计依据。
PERSON 与 DEATH 的映射看似字段少、逻辑简单，但它承载了隐私保护与数据可用性之间的核心权衡。工程上应坚持“标准概念用于分析、源值留存用于追溯、敏感信息脱敏后入库”三条原则，并在 ETL 的每个环节留下可核查的记录。只有这样，后续的队列构建、倾向性评分和生存分析才能建立在可信的人口学基础之上。