Vocabulary Metadata

Content

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)

Metadata tables

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 - 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

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);	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 review.