Vocabulary Metadata

Vocabulary Metadata

Description

For Vocabularies, additional metadata is introduced, which is stored in two tables:

• concept_metadata (stores metadata for concepts)
• concept_relationship_metadata (stores metadata for a relationship between two concepts)

concept_metadata table

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, J A – attribute of a clinical event rather than 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). J – 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 junk (non-mappable) and SHOULD NOT be mapped
reuse_status	VARCHAR (20)	Yes	NULL, RF, RP,R	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 will be Reused in Future: name of a concept in concept table is actual (latest available name form source); historical name is unavailable in concept RP - Designates that code was Reused in Past: name of a concept in concept table is historical(first available name from in source); actual name is unavailable in concept

concept_relationship_metadata table

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	eq - equivalent [exactMatch], up- uphill [broadMatch], down - downhill [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);
mapping_source	VARCHAR(50)	Yes	Libraries and referense 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 mapping review.

DDL

The DDL script to create concept_metadata and concept_relationship metadata tables can be found in the GitHub repository:
DevV5_Metadata_DDL.sql at OHDSI/Vocabulary-v5.0