简而言之： OMOP Common Data Model（Observational Medical Outcomes Partnership CDM），由 OHDSI 社区维护，是一个关系型数据库模式，可以将任何来源（电子健康记录、索赔、注册表）的健康数据转换为此模式，并附带一套标准化词汇表，将每个本地代码映射到一个标准的概念 ID。一旦数据库符合 OMOP 模式，相同的分析代码（队列定义、发病率估算、比较有效性研究）就可以在全球数百个数据库上运行而无需更改，并且只共享汇总结果。OMOP 是用于研究的模型；FHIR 是用于交换和护理的模型；已发布的映射连接了两者，并且大多数研究平台现在都接受 FHIR 作为其 OMOP ETL 的数据源。
模型概览图
OMOP 常用数据模型将一切表示为观察期内关于个人的事件，临床领域决定使用哪个表：condition_occurrence 用于诊断，drug_exposure 用于药物，measurement 用于实验室结果和生命体征，procedure_occurrence，visit_occurrence，observation 用于其他事实，此外还有 person、death、note、specimen、provider 和 cost 表。5.4 版本是运行最广泛的版本。
一切都是关于一个人在观察期内发生的事件，临床领域决定使用哪个表：
| 表 | 包含 | 标准词汇表（典型） | FHIR 源 |
|---|---|---|---|
| person | 每人一行：性别、出生日期、种族、民族、地点 | Gender、Race、Ethnicity 概念 | Patient |
| observation_period | 预计会有人相关数据的时段 | — | 从覆盖和就诊日期推导 |
| visit_occurrence (和 visit_detail) | 就诊：住院、门诊、急诊，包含日期 | Visit 概念 | Encounter |
| condition_occurrence | 诊断和问题，包含开始和结束日期 | SNOMED CT | Condition (ICD 代码映射到 SNOMED) |
| drug_exposure | 处方、配药、给药，包含数量和供应天数 | RxNorm (以及非美国药物的 RxNorm Extension) | MedicationRequest, MedicationStatement, MedicationAdministration, MedicationDispense |
| procedure_occurrence | 进行的手术 | SNOMED CT, CPT4, ICD10PCS | Procedure |
| measurement | 实验室结果和生命体征，包含数值、单位、范围 | LOINC，使用 UCUM 单位 | Observation (laboratory, vital signs) |
| observation | 其他临床事实：病史、社会因素、评分 | SNOMED CT, LOINC | Observation (other), QuestionnaireResponse, FamilyMemberHistory |
| device_exposure | 使用的设备 | SNOMED CT | DeviceUseStatement, Procedure |
| death | 日期和原因 | SNOMED CT | Patient.deceased, Observation |
| note, note_nlp | 临床笔记和 NLP 提取的术语 | — | DocumentReference, DiagnosticReport |
| specimen | 标本 | SNOMED CT | Specimen |
| provider, care_site, location | 临床医生、设施、地点 | Specialty 概念 | Practitioner, Organization, Location |
| cost, payer_plan_period | 费用和保险 | — | Coverage, Claim (如果可用) |
版本 5.4 是大多数站点运行的版本；版本 6 已存在但未被广泛采用，并且 5.x 系列的开发仍在继续。
词汇表
OMOP 标准化词汇表由 OHDSI 通过 Athena 分发，将一百多种代码系统（SNOMED CT、LOINC、RxNorm、ICD-10、ATC 等)加载到 concept、concept_relationship 和 concept_ancestor 表中。每个代码都变成一个 concept_id，要么是标准代码，要么映射到标准代码，因此分析只需编写一次，同时保留了原始源代码。
OMOP 的另一半是 Athena，即 OHDSI 的词汇表分发系统：它将一百多个代码系统（SNOMED CT、LOINC、RxNorm、ICD-10 及各国变体、ATC、CPT、Read 等）加载到 concept、concept_relationship、concept_ancestor 表中。每个代码都变成一个概念 ID；每个概念要么是标准的（分析使用的），要么是非标准的（映射到标准概念的源代码），要么是分类。ETL 同时存储源概念（记录所说的内容：ICD-10 E11.9）和标准概念（SNOMED 44054006），因此分析代码只需针对标准概念编写一次，同时保留原始信息。concept_ancestor 表允许队列通过一次连接查询“任何类型的糖尿病”。请参阅 SNOMED CT vs ICD-10 以了解为什么 SNOMED CT 是诊断的标准。
ETL
OMOP ETL 是将源数据库转换为通用数据模型的工作，由 OHDSI 工具支持：WhiteRabbit 对源进行分析，Rabbit-in-a-Hat 记录表映射，Usagi 将本地代码映射到标准概念，数据质量仪表板根据数千条规则检查结果，ACHILLES 对完成的数据库进行特征描述。
将源数据转换为 OMOP 是主要工作。OHDSI 的工具对此有所帮助：WhiteRabbit 扫描源数据并对其进行分析；Rabbit-in-a-Hat 记录从源表到 CDM 表的映射；Usagi 帮助将本地代码映射到标准概念；Data Quality Dashboard 根据数千条规则检查结果；ACHILLES 对数据库进行特征描述。典型的决策包括：如何定义就诊、如何将药物记录转换为带有供应天数的暴露记录、如何规范化单位、如何处理没有标准映射的代码，以及如何处理更新（完全重新加载 vs 增量）。
网络分析
OHDSI 网络中的分析工作方式是编写一次研究并在所有地方运行：研究人员在 ATLAS 中定义队列，使用 HADES R 包进行估计和预测，并将分析打包成代码，每个站点在本地的 OMOP 数据库上执行，只共享汇总结果。DARWIN EU 和 EHDEN 也遵循此模型。
ATLAS 是研究人员构建队列定义（患有 X 病症、接受 Y 药物治疗、在特定时间窗口内的人群）、对其进行特征描述并使用 HADES R 包（CohortMethod、PatientLevelPrediction、SelfControlledCaseSeries）运行估算和预测研究的 Web 工具。网络研究将分析打包成代码；每个站点在其 OMOP 数据库上本地运行分析并共享汇总结果；没有人会汇总记录级别的数据。这就是 OHDSI 社区在疫情期间快速完成大型跨国研究的方式，也是 EMA 的 DARWIN EU 网络和 EHDEN 项目背后的模式，该项目已将一百多个欧洲数据库转换为 OMOP。
FHIR 到 OMOP
FHIR 在两个层面映射到 OMOP：资源映射到表，元素映射到列，FHIR 代码通过 OMOP 的词汇表翻译成标准概念。HL7 的 FHIR 到 OMOP 实现指南和 OHDSI 的 FHIR 工作组发布了映射；多个平台直接从 FHIR 服务器或批量数据导出运行 ETL。
FHIR 和 OMOP 满足不同的需求：FHIR 在系统之间传递单个患者的详细记录；OMOP 则将大量患者的记录进行扁平化处理以进行统计分析。映射在资源级别（上表）自然进行，在元素级别进行详细映射：FHIR 代码通过 OMOP 的词汇表映射到标准概念；Observation.valueQuantity 转换为 measurement 的 value_as_number 和 unit_concept_id；Encounter.class 转换为 visit_concept_id。HL7 的 FHIR to OMOP implementation guide（通过 Vulcan 加速器）和 OHDSI 的 FHIR 工作组发布了映射和参考实现；多个平台直接从 FHIR 服务器或批量数据导出运行 ETL。在 FHIR 更丰富（多个编码、状态、来源）或 OMOP 需要 FHIR 缺乏的内容（供应天数、观察期）时，仍存在一些歧义。
OMOP 不是什么
OMOP 不是护理的格式，本身也不是匿名的：它丢弃叙述性信息，扁平化状态，不包含同意书、来源或工作流程信息，因此 FHIR 仍然是交换格式，而 OMOP 数据库仍然包含记录级数据，这些数据必须像任何健康数据库一样进行管理，通常在安全环境中包含假名化后的个人 ID。
它不是用于护理的格式：它会丢弃叙述性内容，扁平化状态，并且不包含同意、来源或工作流程信息。它本身不是匿名的：OMOP 数据库包含记录级别的数据，并像任何健康数据库一样受到管理，通常使用假名化的个人 ID 并在安全的环境中进行。请参阅 健康数据的二次使用 和 健康数据去标识化。
在 Anpheros 中
Anpheros 的记录是 FHIR R4 格式，使用标准代码（LOINC、SNOMED CT、ATC、ICD-10），这是 OMOP ETL 所需的输入；在获得患者同意用于研究目的的情况下，假名化的 FHIR 提取物可以输入研究平台的 ETL。Anpheros 本身仅计算 20 人或以上群体的汇总人群信号，并且不处理已识别数据的 OMOP 数据库。
相关页面
来源
- OHDSI: OMOP Common Data Model
- OHDSI: The Book of OHDSI
- OHDSI Athena: 标准化词汇表
- OHDSI: ATLAS
- HL7 Vulcan: FHIR to OMOP implementation guide
- EHDEN 项目
- EMA: DARWIN EU
常见问题
OMOP 是 FHIR 的替代品吗？
不是。FHIR 在系统之间交换单个患者的详细记录；OMOP 则将大量记录进行结构化处理以进行统计分析。研究平台接收 FHIR（或其他来源）数据，并生成 OMOP 数据。
我应该使用哪个 OMOP 版本？
5.4 是广泛部署的版本，拥有完整的工具支持；大多数新的转换都以它为目标。版本 6 引入了一些社区未广泛采用的更改。
为什么 OMOP 将 ICD 代码映射到 SNOMED CT？
这样，分析代码就可以针对单一的、分层的标准诊断词汇表编写一次，而无需考虑源数据使用的是 ICD-10、ICD-10-CM、ICD-9-CM 还是 Read 代码。源代码会一并保留。
OMOP 数据库是匿名的吗？
本身不是。它包含记录级别的数据，通常带有假名化的标识符且不包含直接标识符，并且必须像任何健康数据库一样受到保护和管理，通常是在安全的环境中。
在沙盒中免费试用
5 分钟完成第一次 FHIR 调用. 一个内置患者授权的 HL7 FHIR R4 API：先在沙盒中试用，然后连接您自己的应用或诊所系统。
免费 · 30 位合成患者 · 无需信用卡
Anpheros 致力于打造一个由患者掌控的医疗记录，并可在欧盟的 HL7 FHIR R4 平台上与任何诊所共享。这些指南旨在帮助您理解和整理您的健康信息，但不能替代您的医生。
关于 Anpheros →