Words that mean two things¶
A surprising amount of early confusion in FHIR to OMOP work is not conceptual difficulty. It is two communities using the same English word for different ideas, and nobody stopping to say so. This page is short on purpose. Read it, then come back to it the next time a meeting goes strangely.
The main offenders¶
| Word | In FHIR it means | In OMOP it means |
|---|---|---|
| Observation | A specific resource type covering vital signs, laboratory results, social history, survey answers, and more | A specific table for clinical facts that are not measurements, conditions, drugs, or procedures. Narrower than the FHIR resource, and the two overlap only partially |
| Concept | Rarely used as a formal term | The central unit of meaning. Every clinical idea has a numeric concept_id, and the model is built around them |
| Code | A symbol from a CodeSystem, carried inside a Coding element | The concept_code column, meaning the original symbol as it appeared in the source vocabulary |
| Domain | Not a formal concept | A property of every standard concept that determines which OMOP CDM table its rows belong in. Load-bearing |
| Value set | A named collection of codes, formally defined and often published | The closest equivalent is a concept set, which serves the same purpose in cohort definitions |
| System | The URI identifying a CodeSystem, as in http://loinc.org |
Roughly equivalent to vocabulary_id, as in LOINC |
| Encounter | A resource representing an interaction, at whatever granularity the source system chose | Nothing directly. It becomes VISIT_OCCURRENCE, VISIT_DETAIL, both, or neither depending on granularity |
| Profile | A formal constraint on a resource, published in an implementation guide | Not used in this sense. OMOP practitioners say "convention" for a similar idea, but conventions are documented prose rather than machine-validatable |
| Reference | A pointer from one resource to another | Foreign key, but the semantics differ. FHIR references can be to external servers, can be logical rather than literal, and can be unresolvable |
| Source | The originating system, informally | A specific and important pair of column patterns: _source_value and _source_concept_id, which preserve the original code alongside the standardized one |
| Type | The resource type, as in "an Observation" | The _type_concept_id columns, which record the provenance of a record: whether it came from a claim, an EHR problem list, a laboratory feed, and so on. Different idea entirely |
Two that cause real damage¶
"Standard"¶
In FHIR, standard is an adjective describing the specification itself. In OMOP, standard is a formal property of a concept, recorded in the standard_concept column. A concept is either standard (S), classification (C), or neither (NULL). Only standard concepts belong in the _concept_id columns of clinical tables. A non-standard concept is not lesser or wrong, it is simply not the one you analyze on.
When an OMOP practitioner says "is that code standard", they are asking a precise question with a lookup-able answer, not making a general comment about quality. This misunderstanding wastes a lot of meeting time.
"Mapping"¶
FHIR practitioners usually mean structural mapping: this field goes to that field. OMOP practitioners usually mean semantic mapping: this source code corresponds to that standard concept.
A FHIR to OMOP project needs both, and they are separate workstreams with separate skills and separate failure modes. When someone says "the mapping is done", ask which one they mean. The structural mapping being finished tells you almost nothing about whether the semantic mapping is finished, and the semantic mapping is usually the longer job.
Two that are genuinely equivalent¶
Good news exists.
- A FHIR CodeSystem and an OMOP vocabulary are the same idea.
http://snomed.info/sctandvocabulary_id = 'SNOMED'refer to the same thing. - A FHIR ValueSet and an OMOP concept set serve the same purpose: a named, reusable collection of codes that expresses a clinical idea.
The FHIR to OMOP Implementation Guide leans on both of these equivalences, which is part of why the guide is a useful shared reference point for mixed teams.
A practical suggestion¶
At the start of a FHIR to OMOP project, put this table in the project wiki and ask the team to use qualified language for the first month. "The FHIR Observation resource" and "the OMOP OBSERVATION table" rather than "observation". It feels stilted for two weeks and prevents a specific category of expensive misunderstanding for the rest of the project.