Skip to main content
FHIR ConceptMap/$translate across OMOP vocabularies

Overview

Translates codes between vocabularies using OMOP Maps to relationships. Supports both forward (source code to OMOP standard) and reverse (OMOP concept to source code) translation. Key R4/R5 difference: R4 responses use equivalence, R5/R6 use relationship.

Contract Parameters

string
default:"r4"
string
OMOP vocabulary release; defaults to the active release.
string
Header alternative to vocab_release; the header takes precedence.
FHIR wire version (r4, r4b, r5, or r6).
string
Forward source code; code is accepted as an alias.
object
Forward source Coding alternative.
string
System for sourceCode, or an optional reverse-result vocabulary filter.
string
R4/R4B target system. targetSystem is the R5/R6 spelling; either alias is accepted.
string
Target ValueSet URI when it identifies a supported system.
string
Concept code for reverse translation.
object
Coding alternative for reverse translation.
string
Optional canonical administrative ConceptMap URL.

Forward Translation

Translate a source code to its OMOP standard equivalent:

POST with sourceCoding

Reverse Translation

Look up the source code for an OMOP concept:

Parameters

Forward

*Provide either sourceCode + system or sourceCoding.

Reverse

*Provide either targetCode or targetCoding.

Response (R4)

Response Fields

string
Always Parameters.
array
Result and zero or more mapping matches.
string
result or match.
boolean | null
Whether a translation was found.
array
Match parts.
string
Match-part name.
string | null
R4 equivalence or R5/R6 relationship.
object | null
Translated Coding with system, code, and display.
array
OMOPHub product-property name/value parts.
The target system determines the coding representation in each match. With targetsystem=https://fhir-terminology.ohdsi.org (or with no target system), match.concept contains an OMOP concept_id. With a vocabulary-specific target such as http://snomed.info/sct, it contains that system URI and the vocabulary’s native concept_code. Unknown target systems return an HTTP 400 OperationOutcome; a known system with no mapping returns result: false and no match.
The target-table product property is OMOPHub-exclusive. It tells ETL developers exactly which OMOP CDM table the translated concept belongs to.
$translate returns both Maps to and Maps to value targets. The latter decomposes composite concepts into a value concept (HL7 FHIR-to-OMOP IG Value-as-Concept pattern) - e.g. SNOMED “Allergy to penicillin” yields an “Allergy to drug” match (Maps to) and a “Penicillin G” match (Maps to value). Each match carries an OMOPHub-exclusive omop-relationship product (Maps to vs Maps to value) so you can route the value concept to value_as_concept_id. Administrative code systems (gender, encounter class, …) translate via the IG’s administrative ConceptMaps.

R5/R6 Differences

On the /fhir/r5/ and /fhir/r6/ endpoints, the input parameter is named targetSystem instead of R4/R4B’s targetsystem, and equivalence is renamed to relationship in matches:

Equivalence Mapping