Vocabulary Metadata - OHDSI/Vocabulary-v5.0 GitHub Wiki
Additional metadata for the Vocabularies is stored in two tables:
- concept_metadata (stores metadata for concepts)
- concept_relationship_metadata (stores metadata for a relationship between two concepts)
The concept_metadata table stores metadata for each concept from the concept table.
The link between the concept table and the concept_metadata table is carried out by the concept_id field.
Table 1. Structure of the concept_metadata table
| Field | Data Type | Nullable | Accepted values | Description |
| concept_id | INT | No | Foreign key to the concept table | |
| concept_category | VARCHAR (20) | Yes | NULL, A, SA, SC, M, V
A – attribute of a clinical event rather than the event itself (e.g., Dose Form, Brand Name) in a reference terminology (e.g., RxNorm Extension). Non-standard by design. SA – attribute of a clinical event in a source vocabulary. Should be mapped to A in the reference terminology. SC – source classification term in traditionally non-standard vocabularies. M – metadata (e.g. SNOMED relationships and models). V – void (formerly 'junk') codes (cannot be mapped due to incompatibility with OMOP model). Include flavors of NULL, codes not in scope, etc. |
If the concept can be mapped and is not mapped, it SHOULD be mapped. Otherwise, it is a void (non-mappable) and SHOULD NOT be mapped |
| reuse_status | VARCHAR (20) | Yes | NULL - reuse either not assessed or not detected
R - Designates that code is Reusable; no information available on temporal context of Reuse; state of name in concept table is undetermined; RF -Designates that code is Reused in Future; current state of concept in concept table displays historically valid attributes (name, validity dates) provided by source RP - Designates that code is Reused in Past; current state of concept in concept table displays actual valid attributes (name, validity dates) provided by source |
Determines if code is reused or not;
Reuse complete change of semantics of code depending on its utilization time |
The concept_relationship_metadata table stores metadata for each relationship between concepts from the concept_relationship table.
The link between the concept_relationship table and the concept_relationship_metadata table is carried out by the concept_id_1, concept_id_2 and relationship_id fields.
Table 2. Structure of the concept_relationship_metadata table
| Field | Data Type | Nullable | Accepted values | Description |
| concept_id_1 | INT | NO | Foreign key to the concept_relationship table | |
| concept_id_2 | INT | NO | ||
| relationship_id | VARCHAR(20) | NO | ||
| relationship_predicate_id | VARCHAR(20) | Yes | exactMatch,
broadMatch narrowMatch |
measure of mapping precision |
| relationship_group | INT | Yes | 1, 2, 3, NULL
Indicator of logical group of relationships designed to minimize unnecessary Variabe-Value permutations or strictly link several Variables(Events); |
1, 2, 3, NULL
An indicator of a logical group of relationships designed to minimize unnecessary Variable-Value permutations or strictly link several Variables(Events); |
| mapping_source | VARCHAR(50) | Yes | Libraries and reference sets: UMLS, MEDDRA - SNOMED, OHDSI; etc
Tools: USAGI, BuilderRxE, LLM; etc |
Indicator of what library(-ies) and/or tool(s) was/were used to automate mapping; |
| confidence | FLOAT | Yes | 0 - 1 | The strength of evidence, how confident you are in mappings |
| mapping_tool | VARCHAR(50) | Yes | AM-lib_C - stands for automapping via library, curated;
AM-lib_U - stands for automapping via library, uncurated; AM-tool_C - stands for automapping via tool, curated; AM-tool_U - stands for automapping via tool, uncurated; MM_C - stands for manual mapping, curated; MM_U - stands for manual mapping, uncurated; NULL- mapping approach is not specified, likely manual; |
Indicator of mapping approach with its curation status (controlled/curated or uncontrolled/uncurated). |
| mapper | VARCHAR(50) | Yes | OZ; AD; VK, etc. | The person who performed the mapping. |
| reviewer | VARCHAR(50) | Yes | OZ; AD; VK, etc. | The person who performed the review. |
The DDL scripts for the concept_metadata and concept_relationship_metadata tables are included in the official OMOP CDM v5.5 DDL:
OMOP CDM v5.5 DDL scripts at OHDSI/CommonDataModel
Starting with the v20260829 release, the concept_metadata and concept_relationship_metadata tables are distributed through Athena as part of the Standardized Vocabularies download.
Before v20260829, metadata was distributed in the assets of the following GitHub releases:
- Metadata assets for v20240830
- Metadata assets for v20250227
- Metadata assets for v20250827
- Metadata assets for v20260227
Metadata is provided in CSV files that can be imported into a database.
The attributes in the CONCEPT_RELATIONSHIP_METADATA table have been developed with members of the Monarch Initiative and are based on the Simple Standard for Sharing Ontological Mappings (SSSOM).