Differences

This shows you the differences between two versions of the page.

--- implementation_international_drug_vocabulary [2019/07/22 12:34]
ekorchmar created
+++ implementation_international_drug_vocabulary [2024/09/02 12:33] (current)
jcruz Depreciation of page and posting of corresponding link in Github wiki
@@ Line 1: / Line 1: @@
-===== International drugs vocabulary implementation process =====
+===== International drug vocabulary implementation process =====
-The most straightforward way to implement a local drug [[documentation:vocabulary|Vocabulary]] is to utilize [[documentation:international_drugs|RxNorm Extension]] logic to extend standard Drug concept pool and map source drug products to concepts in RxNorm extended hierarchy.
+Thank you for visiting the wiki! This page has moved to https://github.com/OHDSI/Vocabulary-v5.0/wiki/International-Drug-Vocabulary-Implementation-Process.
-==== Combined target structure ====
-To incorporate a new set of drug information, a structure should be achieved that contains every Concept only once and preserves the RxNorm structure, no matter which vocabulary the additional Concept is coming from. In a way, it should create a mixed RxNorm/drug vocabularies union.
-In order to achieve this, any two equivalent Concepts have to be matched through its components: Ingredients to Ingredients, Forms to Forms, Supplier to Supplier, etc. Concepts are defined as matching if all components match. For example, a Clinical Drug matches another Clinical Drug if it contains the same Ingredients at the same strength and the same Dose Form.
-Standard concepts in [[documentation:vocabulary:drug|Drug domain]] are placed in a single comprehensive hierarchy based on their attributes. To correctly implement a vocabulary in CDM, following attributes must be extracted:
-  - Ingredients: active substance(-s) in pharmacological preparation. Examples: Aspirin, Trastuzumab, Ibuprofen etc.;
-  - Dose form: form in which drug is administered to patient. Examples: Oral Tablet, Transdermal System, Injectable Suspension;
-  - Marketed/Brand Name: Nurofen, Kadcyla, Prevenar 13 etc.;
-  - Dosage/strength of active substance, total volume of liquid drug or number of actuations for dosed inhalers or applicators;
-  - Information about combination pack contents, e.g. contraceptives calendar packs with varying dosages and ingredient combinations;
-  - Box size: number of unique package units (like bottles, blisters or syringes) in a packaged box.
-  - Manufacturer/supplier name (Reckitt Benckiser, TEVA, Ratiopharm etc). Generally, local branch and general name of international entity are considered same ("Teva Europe" is the same as "Teva").
-Such attributes may be given explicitly in a well-structured source vocabulary or have to be extracted from drug product names. In case of drug products or discrete attributes like Ingredients or Brand Names not having their own codes, new codes have to be constructed combining the word “OMOP” and a running number. The running number should be unique across all vocabularies. That means, each time a new vocabulary is added or refreshed, the next Concept Code should be the one of the last (without the 'OMOP' string) +1.
-All source vocabulary concepts, extracted attributes and dosage and packaging information must be staged in standardized format of input tables, that can processed to be included into CDM Standardized Vocabularies.
-=== Creation of input tables ===
-The new vocabulary should be prepared in the following tables:
-**DRUG_CONCEPT_STAGE**
-^ Field                    ^ Required  ^ Type         ^ Description                                                                                                                                                                                 ^
-| concept_name             | Yes       | string(255)  | An unambiguous, meaningful and descriptive name for the Concept in English language                                                                                                         |
-| domain_id                | Yes       | string(20)   | A foreign key to the DOMAIN table. The standard content is 'Drug', but for non-drugs it could be 'Device' of 'Observation'                                                                  |
-| vocabulary_id            | Yes       | string(20)   | A foreign key to the VOCABULARY table. The value of this field should be identical for all records, indicating the new vocabulary being added.                                              |
-| concept_class_id         | Yes       | string(20)   | One of the above listed RxNorm Concept Classes                                                                                                                                              |
-| concept_code             | Yes       | string(50)   | The code in the source vocabulary. If the source vocabulary does not contain a code, e.g. for ingredients or dose forms, they will be created automatically (see below OMOP created codes)  |
-| source_concept_class_id  | No        | string(20)   | Concept class that is given by the source vocabulary                                                                                                                                        |
-| possible_excipient       | No        | string(1)    | A flag only relevant to ingredients, indicating whether or not they are not active ingredients and could be omitted from an ingredient list.                                                |
-| valid_start_date         | No        | date         | Date when the Concept became valid. This may or may not coincide with the date the product went to market.                                                                                  |
-| valid_end_date           | No        | date         | Date when the Concept became invalid. Market withdrawal does not mean a Concept is invalid.                                                                                                 |
-| invalid_reason           | No        | string(1)    | Flag indicating wether the Concept is active (today's date between valid_start and valid_end_date), or upgraded ('U') or deprecated ('D').                                                  |
-This table is expected to contain as a minimum the comprehensive list of Concept Classes:
-  * Drug Product (Branded Drug, Clinical Drug, Marketed Product etc.)
-  * Form
-  * Brand Name
-  * Ingredient
-  * Unit
-  * Supplier
-  * Device (for source conccepts falling outside of Drug cathegory)
-It may contain Branded or Clinical Drug Forms or Components, but if not they will be derived (see below). Note that units should not have their own concept in the DRUG_CONCEPT_STAGE table. Instead, they should be used as verbatim. If the precise Concept Class is not known, it can be included as "Drug Product" and the correct Concept Class will be assigned during the incorporation automatically based on the availability of Strength, Dose Form, Brand Name, Supplier, Quantity and Box Size information.
-Brand Names that are simple combinations of generic international name of active substance and manufacturer name (e.g. "Aspirin Bayer") should not appear as attributes for Drug Products. Manufacturer information should be stored as a concept with Supplier class.
-Concepts that belong to the source vocabulary, but do not belong to Drug domain by OMOP rules., should be classified as 'Device'. Typically, these belong to different substance groups:
-  * Radiographic contrasts and dyes (barium sulfate, radiolabeled iodides)
-  * Nutritional supplements without stated mechanism of pharmaceutical action (e.g. herbal complexes, homeopathic preparations)
-  * Formulas for infant feeding
-  * Parenteral nutrition (aminoacids and/or lipid mixes)
-  * Solution for dialysis, catheter maintenance etc.
-  * Blood products for transfusion, blood plasma, autologous and non-autologous transplants of any kind
-  * Cosmetics, sunscreens, non-medicated shampoos and soaps, etc.
-  * Surgical materials like bone cements
-  * Topical/external disinfectants
-Animal drugs can be handled as Drugs or Devices, depending on what their role in patient data can be expected to be.
-Note that only concepts from Drug domain can have attributes.
-**RELATIONSHIP_TO_CONCEPT**
-This table should contain the mapping between source codes and Standard Concepts for Ingredients, Brand Names, Dose Forms, Suppliers and Units.It also may contain mapping from source drugs to Standard Concepts for related ATC classes. All other relationships will be ignored.
-^Field^Required^Type^Description^
-|concept_code_1|Yes|string(255)|The source code|
-|concept_id_2|Yes|integer|The existing target Concept|
-|precedence|No|integer|For multiple concept_code_1/concept_id_2 combination the order of precedence in which they should be considered for equivalence testing. The mapping with the highest prevalence among the drugs will be used for writing a record to the CONCEPT_RELATIONSHIP table. A missing precedence will be interpreted as precedence 1. Every precedence value should be unique per concept_code_1|
-|conversion_factor|No|float|The factor used to convert the source code to the target Concept. This is usually defined for units|
-This table should contain all mappings from the new to existing Concepts and their precedence.
-Units should be mapped to Standard Concept Units. Weight units should be converted to milligram, volume units should be mapped to milliliter, molar - to millimole with the right conversion factor. The source_code field should contain the verbatim string of the unit. It is highly preferrable to use the same units that are in use for valid drugs stored in RxNorm, not just Standard units.
-**INTERNAL_RELATIONSHIP_STAGE**
-^Field^Required^Type^Description^
-|concept_code_1|Yes|string(255)|One source code of the pair|
-|concept_code_2|Yes|string(255)|The other source code of the pair|
-This table should contain relationships for each Drug Concept: To the Ingredients (always), the Dose Form (if appropriate),the Supplier (if appropriate) and the Brand Name (if appropriate). All other relationships will be derived and ignored if they exist in the table. The relationships need not be symmetrical, only the one initiating from the Drug Concept is required.
-If Drug Product concept does not have an Ingredient attribute, it will not have any standard mapping target after processing. Supplier attribute will not be considered for concepts without DS_STAGE or PC_STAGE entry since Marketed Product concepts can not exist without dosage information.
-**DS_STAGE**
-^Field^Required^Type^Description^
-|drug_concept_code|Yes|string(255)|The source code of the Drug or Drug Component, either Branded or Clinical|
-|ingredient_concept_code|Yes|string(255)|The source code for one of the Ingredients|
-|amount_value|No|float|The numeric value for absolute content (usually solid formulations)|
-|amount_unit|No|string(255)|The verbatim unit of the absolute content (solids)|
-|numerator_value|No|float|The numerator value for a concentration (usually liquid formulations)|
-|numerator_unit|No|string(255)|The verbatim numerator unit of a concentration (liquids)|
-|denominator_value|No|float|The denominator value for a concentration (usally liquid formulations). It should contain a number for Quantified products, and null for everything else.|
-|denominator_unit|No|string(255)|The verbatim denominator unit of a concentration (liquids)|
-|box_size|No|integer|The amount of units per box|
-This table contains the dose of each ingredient in each drug, as well as the box_size. For drugs which have no strength information or have only for some of the containing ingredients, the ds_stage record must be omitted. '0' values in ds_stage are only allowed for inert drugs.
-Drug ingredients should match those in internal_relationship_stage.
-If ingredients are mapped to the same one in relationship_to_concept their dosages should be summed up.
-A drug should not contain ingredients in solid (amount) and liquid (numerator/denominator) form. This might be caused be either source data aberration or drug pack, which must be split into separate Drug Products and processed in PC_STAGE table.
-Inhalers, enemas or sprays that release certain dosage of active ingredient per activation should also be stored in numerator/denominator form with total number of actuations as denominator (e.g. X MG / Y ACTUAT). Drugs that release active substance over prolonged period of time, like transcutaneous patches or modified release oral pills, can also be stored as numerator/denominator with hours as denominators.
-**PС_STAGE**
-^Field^Required^Type^Description^
-|pack_concept_code|Yes|string(255)|The source code of the Pack, either Branded or Clinical|
-|drug_concept_code|Yes|string(255)|The component drug product in the Pack|
-|amount|No|integer|The number of units of the drug product in drug_concept_code|
-|box_size|No|integer|The number of packs if the pack is boxed (several packs in a larger container|
-This table contains the composition of a Clinical or Branded Pack: The Clinical or Branded Drug and the number in each pack. If it is a boxed Pack, it will also contain the box size, since Packs have no records in DS_STAGE like the other drug products.
-**CONCEPT_SYNONYM_STAGE**
-This table contains alternative names for concepts. These are either alternative names provided by source or names in original languages, since DRUG_CONCEPT_STAGE will contain english names only.
-^Field^Type^Description^
-|synonym_concept_id|integer|Always and empty field in this table|
-|synonym_name|string(255)|Alternative name of the concept. There is no need to copy the entry from DRUG_CONCEPT_STAGE|
-|synonym_concept_code|string(50)|Concept code in source vocabulary|
-|synonym_vocabulary_id|string(20)|VOCABULARY_ID of source vocabulary|
-|language_concept_id|integer|CONCEPT_ID for Standard concept representing language|
-**CONCEPT_RELATIONSHIP_MANUAL**
-This table allows to manually map source concepts to existing standard concept in OMOP CDM circumventing standard vocabulary building process. This is useful to represent source concepts that belong to a different domain, preserve relationships inside the vocabulary or to map concepts to standard Drug concepts from outside of RxNorm and RxNorm Extension logic (e.g. standard concepts in [[documentation:vocabulary:atc|ATC]] or [[documentation:vocabulary:cvx|CVX]] vocabulary.
-^Field^Required^Type^Description^
-|concept_code_1|Yes|string(255)|CONCEPT_CODE of source concept in either [[documentation:cdm:concept|CONCEPT]] or DRUG_CONCEPT_STAGE tables|
-|concept_code_2|Yes|string(255)|CONCEPT_CODE of target concept in either [[documentation:cdm:concept|CONCEPT]] or DRUG_CONCEPT_STAGE tables|
-|vocabulary_id_1|Yes|string(20)|VOCABULARY_ID value of source concept|
-|vocabulary_id_2|Yes|string(20)|VOCABULARY_ID value of target concept|
-|relationship_id|Yes|sting(20)|Indicates the type of relation from source to target; most usually will indicate equivalence mapping ('Maps to'). Must be one of the values from [[documentation:cdm:relationship|RELATIONSHIP table]]|
-|valid_start_date|No|date|Date when the relation became valid|
-|valid_end_date|No|date|Date when the relation became invalid|
-|invalid_reason|No|string(1)|Non-null entry allows for manual deprecation of existing relationship. Deprecated relationships that are absent from [[documentation:cdm:concept_relationship|CONCEPT_RELATIONSHIP table]] will not be added to Standardized Vocabularies|
-This table needs not to be symmetrical like CONCEPT_RELATIONSHIP; complementary relationships will be built automatically.
-Note that concepts with equivalence mappings in this table should not have relations to attributes in other input tables,

Observational Health Data Sciences and Informatics

User Tools

Site Tools

Differences

Page Tools