电子病历(EHR/EMR)结构：HL7 FHIR、OMOP CDM

可视化演示

展示HL7 FHIR资源关系网络、FHIR与OMOP CDM表结构映射、以及从源数据到标准化模型的ETL流程。

病历基础概念

想象你是一个小镇的档案管理员。过去十年，镇上的医院用纸质病历，每个医生有自己的记法：张医生喜欢画图，李医生习惯写缩写，儿科甚至用贴纸记录疫苗接种。你最大的噩梦，是某天一位病人从别的镇转来，你翻开新病历，完全看不懂对方在说什么——这就是“互操作”问题。

电子病历就是把纸质档案搬到电脑里，但“搬到电脑里”还远远不够。EMR（Electronic Medical Record，电子医疗记录）是单个医院内部的数字化病历，解决的是“本院医生能看清楚”的问题；而 EHR（Electronic Health Record，电子健康档案）则强调跨机构共享，让病人在 A 院做的检查，B 院也能调阅。两者关系就像“科室内部日志”与“全镇共享健康档案”。

对 AI 而言，病历必须是结构化数据——也就是每个字段有明确含义、有统一编码。自由文本如“患者血糖偏高”是无法直接喂给模型的；结构化后变成“血糖=7.2mmol/L（空腹），异常”，模型才能计算。HL7、FHIR、OMOP 等标准，都是为了解决结构化与互操作这两个核心问题而生的。

1. EHR 与 EMR：EHR 强调跨机构共享的健康档案，EMR 是医院内部的电子医疗记录，二者常常被混用

$$EMR \subset EHR$$

2. 结构化数据：将自由文本转为带语义标签的字段，是 AI 分析的前提

$$Text \xrightarrow{NLP+标注} Structured Fields$$

3. 互操作级别：从语法互操作（格式一致）到语义互操作（含义一致）是分层递进的

$$Syntax \rightarrow Semantics \rightarrow Process$$

回到档案室的比喻：你买了一批一模一样的档案盒（EMR 标准化），又跟邻镇约定了相同的标签规则（EHR 共享），最后还约定每个标签的含义（语义互操作）——这样你才能真正看懂其他镇的档案，也才能让电脑帮你统计全镇的健康趋势。

HL7 FHIR 概览

假设你终于说服全镇医生使用统一的电子病历系统，但新问题来了：药房系统要读处方、检验科系统要读化验单、保险系统要读诊断记录。每家系统都有自己的数据库结构，数据交换变成了一场“翻译官”的噩梦——这就是为什么需要 HL7 FHIR。

HL7 是医疗信息交换标准的国际组织，从早期的 HL7 v2（基于管道字符的文本协议）进化到 v3（基于 XML 但过于复杂而少有落地），最终在 2014 年推出了 FHIR（Fast Healthcare Interoperability Resources，快速医疗互操作资源）。FHIR 的核心革命在于：它把 RESTful API 的思想引入医疗领域，让电子病历系统像互联网应用一样通过 HTTP 请求交换数据。

FHIR 的基本单元叫“资源”（Resource），比如 Patient（患者）、Observation（检查结果）、MedicationRequest（用药医嘱）。每种资源有固定的 JSON/XML 结构，像一份份填写好的标准表格。系统间交换数据，就是把这些资源通过 GET、POST、PUT 等 HTTP 操作传来传去——这跟手机 App 调后端接口是完全一样的模式。

档案室的比喻在这里有了新角色：FHIR 相当于全镇统一了档案的“快递协议”——每个档案盒都有标准编号（资源 ID），有标准尺寸（资源结构），有统一的寄送方式（REST API）。档案室之间传档案，不再需要人工抄写，而是像寄快递一样扫码、打包、发货，全程可追踪。

FHIR 资源详解

一个 FHIR 资源内部长什么样？我们以 Patient 资源为例拆开来看。在档案室的比喻里，Patient 资源就是每个人的“主档案袋”，上面贴满了标准标签：姓名、出生日期、性别、联系方式——每个标签在 FHIR 里叫“元素”（Element），而这些元素的值都有明确的类型约束，比如出生日期必须是 date 类型，性别必须来自枚举值表。

更妙的是资源的“引用”机制。Patient 资源上会记录“就诊历史”指向一组 Encounter（就诊）资源，而 Encounter 资源又指向 Observation（检查）资源——就像主档案袋里有一根根红色引线，连到不同颜色的子档案袋。这种通过逻辑引用（Reference）而非物理嵌的方式组织数据，让数据既可拆开独立传输，又能按需组装成完整画像。

FHIR 还允许通过“扩展”（Extension）机制添加标准之外的自定义字段——就像档案袋上可以贴便利贴，但便利贴必须按照规范格式写，不能随手涂鸦。当一次操作需要同时更新多个资源时，用 Bundle 把多个资源打包成一个事务包一次提交，保证所有操作要么全部成功、要么全部失败，这在“转诊转科”这类需要同时更新多张表的工作流里特别有用。

回到档案室：以前你想了解一个病人的完整情况，要翻遍整个档案室；现在有了 FHIR 的红色引线，你可以沿着 Patient → Encounter → Observation 的链条迅速调齐所有相关档案，还能用 Bundle 把“一次门诊”的所有新增记录打包存档，保证这批档案“要么全进库，要么全不进”。

OMOP CDM 设计

FHIR 解决了“怎么传”，但科研还要解决“怎么比”。假设你收集了全国 100 家医院的 FHIR 数据，却发现：有的医院诊断用 ICD-10，有的用 SNOMED-CT；有的记录“高血压”为疾病，有的记录为症状；有的用“mg/dL“有的用”mmol/L“作血糖单位——这时你需要一个统一的”分析型数据模型”，这就是 OMOP CDM。

OHDSI 组织（Observational Health Data Sciences and Informatics）推出的 OMOP CDM（Observational Medical Outcomes Partnership Common Data Model）是一套专门为观察性研究设计的关系型数据库模型。它把医疗数据按“人物（Person）”为中心组织成事实表，比如 condition_occurrence（疾病发生）、drug_exposure（药物暴露）、visit_occurrence（就诊事件）等，每张表都是行事件模型——每一行代表一次具体事件，而不是一条汇总记录。

OMOP 的灵魂是“标准化概念”（Standardized Concepts）。每个概念有唯一的概念 ID（如“高血压”对应概念 ID 320128），并挂载在概念层级里（比如“继发性高血压”是“高血压”的子概念）。这样，100 家医院的“高血压”病例，无论源系统用什么编码，映射到 OMOP 后都指向同一个概念 ID——这正是跨院大规模分析的基石。分析者只需写一行 SQL 就能统计所有医院的高血压患病率。

档案室的数据统计问题，在 OMOP 里变成了标准化的“统计台账”：不管原始档案是什么语言、什么格式，映射之后都落到统一模板里。研究者不再需要理解 100 种病历写法，只需要理解 OMOP 的 30 张表，就能写出通用的分析 SQL——这就像用统一的 Excel 表格统计 100 个班级的成绩，大家填同一个模板，汇总只需一个公式。

术语映射与 ETL

有了 FHIR 和 OMOP 这两个“目标格式”，下一步就是把医院真实数据转过去。这个过程的核心是 ETL（Extract-Transform-Load，抽取-转换-加载），而 ETL 中最难的不是技术，而是“翻译”——术语映射。

假设某医院系统里诊断编码用的是 ICD-10，其中 “E11.9“ 表示”2 型糖尿病不伴并发症“。而 OMOP 标准概念里，SNOMED-CT 的 ”44054006“ 表示”Type 2 diabetes mellitus“。怎么让两者对应？答案是用”术语映射表“（Concept Map）。OHDSI 提供了工具 Athena，可以下载标准概念表和映射关系包，其中包含源编码到标准概念 ID 的映射规则。有些映射是一对一的，有些是”一对多”的——一个粗粒度源编码可能要拆成多个标准概念，反之亦然。

ETL 的标准流程一般包括五步，我们用“档案翻译厂”来比喻：第一步“抽档”（Extract）——从源库拉出原始数据；第二步“翻标”（Transform）——对每条记录做术语映射和单位换算；第三步“质检”（Validate）——检查必填字段是否缺失、概念 ID 是否合法；第四步“归档”（Load）——写入目标 CDM 表；第五步“复盘”（Audit）——统计映射覆盖率与质量指标。真实工程中，映射覆盖率 90% 已经很优秀，剩余 10% 需要人工审核或建立局部映射。

档案翻译厂的核心竞争力不是翻译速度，而是“翻译质量”。一个编码映射错了，会导致后续所有统计结果跑偏——就像把“高血压”错翻成“低血压”，整个镇的慢性病统计全部作废。所以 ETL 过程的最后一步永远是质量复查，这跟档案室里的“双人核对”制度如出一辙。

数据治理与 AI 落地

最后一道大题：数据终于规范化了，接下来怎么给 AI 用？现实中医疗 AI 项目 80% 的时间都花在数据治理上，而非模型调参。

去标识化（De-identification）是第一道红线。HIPAA 规定 18 类标识符必须去除或加密，包括姓名、身份证号、电话号码、甚至精确到日的出生日期。在 FHIR 资源里，Patient.name 和 Patient.identifier 是需要重点处理的字段；在 OMOP 流程里，person 表的 person_id 需替换为随机生成的不可逆 ID。做联邦学习时，数据不出院，模型参数加密传输，则是另一层更严格的治理手段。

数据质量评估需要贯穿 ETL 全流程。常见维度包括完整性（必填字段缺失率）、一致性（同一患者年龄与出生日期是否矛盾）、时效性（数据是否过期）。在 OMOP 中，每个表都有主键约束和外键约束，违反约束的行必须被记录并修正。实践中通常建立“数据质量仪表盘”，每批数据入库后自动生成质量报告。

当数据底座就绪后，AI 落地路径变得清晰：从 OMOP 表提取特征 → 存入特征库（Feature Store）→ 训练模型 → 以 FHIR 资源形式输出预测结果接入临床系统。整个过程像流水线工厂：OMOP 是“原料仓库”，特征库是“精加工车间”，FHIR 是“包装出货区”——每个环节都有明确接口，缺一不可。

回到档案室的收尾场景：你终于可以用统计台账（OMOP）驱动“健康数据分析部”（AI 团队）挖掘全镇的健康规律，再把分析结果用标准档案盒（FHIR）送回临床科室。整个过程有规则、有质检、有追溯——这就是数据治理的意义，也是医疗 AI 从“实验室玩具”变成“临床工具”的关键一步。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""FHIR 资源解析与 OMOP 概念映射演示"""import jsonfrom datetime import datetime  FHIR_PATIENT = {    "resourceType": "Patient",    "id": "pat-001",    "identifier": [{"system": "http://hospital.org/mrn", "value": "MRN-88321"}],    "name": [{"family": "Zhang", "given": ["Wei"]}],    "birthDate": "1985-04-12",    "gender": "male"}  CONCEPT_MAP = {    "E11.9": 44054006,   # ICD-10 -> SNOMED CT    "I10": 320128,    "J45": 195967001}  class OMOPMapper:    def __init__(self, mapping):        self.mapping = mapping        self.concept_map = mapping     def map_code(self, source_code):        if source_code in self.concept_map:            return self.concept_map[source_code]        return 0   # unmapped, 0 = no matching concept  def parse_fhir_patient(resource):    if resource["resourceType"] != "Patient":        raise ValueError("Not a Patient resource")    birth_year = int(resource["birthDate"][:4])    age = datetime.now().year - birth_year    return {        "person_id": hash(resource["id"]) % 100000,        "gender": resource["gender"],        "age": age    }  def transform_condition(local_code, mapper):    concept_id = mapper.map_code(local_code)    if concept_id == 0:        raise ValueError(f"Unmappable code: {local_code}")    return {"condition_concept_id": concept_id, "source_code": local_code}  if __name__ == "__main__":    demo_mapper = OMOPMapper(CONCEPT_MAP)    pt = parse_fhir_patient(FHIR_PATIENT)    print("OMOP person:", pt)     cond = transform_condition("E11.9", demo_mapper)    print("Mapped condition:", cond)     unknown = transform_condition("Z99.9", demo_mapper)    print("Unknown code:", unknown)

1. FHIR_PATIENT = {...}硬编码一条 FHIR Patient 资源 JSON，模拟医院系统通过 FHIR API 返回的数据
2. CONCEPT_MAP = {...}定义 ICD-10 本地编码到 SNOMED-CT 标准概念 ID 的映射表，实际工程中从 Athena 下载
3. class OMOPMapper:封装了术语映射逻辑，map_code 方法负责编码翻译，未命中返回 0 表示“无法映射”
4. parse_fhir_patient(resource)从 FHIR 资源中提取 person_id、gender、age，用于写入 OMOP person 表
5. hash(resource["id"]) % 100000用哈希生成不可逆伪 ID，模拟去标识化，防止真实 MRN 泄露
6. transform_condition(local_code, mapper)将单条诊断编码映射为 OMOP 标准概念，并抛出异常提示未映射编码
7. if __name__ == "__main__":程序入口，依次执行解析与映射，演示一条真实数据的完整流转

常见误区

面试题