implementation_international_drug_vocabulary
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| implementation_international_drug_vocabulary [2019/07/22 16:27] – ekorchmar | implementation_international_drug_vocabulary [2024/09/02 12:33] (current) – Depreciation of page and posting of corresponding link in Github wiki jcruz | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ===== International | + | ===== International |
| - | The most straightforward way to implement a local drug [[documentation: | + | Thank you for visiting |
| - | + | ||
| - | ==== Combined target structure ==== | + | |
| - | Standard concepts in [[documentation: | + | |
| - | + | ||
| - | - **Ingredients**: | + | |
| - | - **Dose form**: form in which drug is administered to patient. Examples: Oral Tablet, Transdermal System, Injectable Suspension; | + | |
| - | - **Marketed/ | + | |
| - | - **Dosage/ | + | |
| - | - **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/ | + | |
| - | + | ||
| - | 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 ' | + | |
| - | + | ||
| - | 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. | + | |
| - | + | ||
| - | === Challenges and problems === | + | |
| - | To implement a tool to create and maintain the above structure, a number of issues need to be taken care of: | + | |
| - | + | ||
| - | * **Excipients: | + | |
| - | * **Forms:** These are not used the same way across drug vocabularies. For example, RxNorm has a Form " | + | |
| - | * **Strength: | + | |
| - | * **Ingredient forms:** Ingredients might have ambiguous chemical forms, which RxNorm calls " | + | |
| - | + | ||
| - | === Creation of input tables === | + | |
| - | The new vocabulary should be prepared in the following tables: | + | |
| - | + | ||
| - | ==DRUG_CONCEPT_STAGE== | + | |
| - | + | ||
| - | ^ Field ^ Required | + | |
| - | | concept_name | + | |
| - | | domain_id | + | |
| - | | vocabulary_id | + | |
| - | | concept_class_id | + | |
| - | | concept_code | + | |
| - | | source_concept_class_id | + | |
| - | | possible_excipient | + | |
| - | | valid_start_date | + | |
| - | | valid_end_date | + | |
| - | | invalid_reason | + | |
| - | + | ||
| - | 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 | + | |
| - | * 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" | + | |
| - | + | ||
| - | Brand Names that are simple combinations of generic international name of active substance and manufacturer name (e.g. " | + | |
| - | + | ||
| - | Concepts that belong to the source vocabulary, but do not belong to Drug domain by OMOP CDM conventions, | + | |
| - | * 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, | + | |
| - | * Cosmetics, sunscreens, non-medicated shampoos and soaps, etc. | + | |
| - | * Surgical materials like bone cements | + | |
| - | * Topical/ | + | |
| - | + | ||
| - | 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, | + | |
| - | + | ||
| - | ^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/ | + | |
| - | |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 desirable to only use units that are in use by Standard native RxNorm concepts. Querry [[documentation: | + | |
| - | + | ||
| - | **Ingredients** must be usually mapped to Standard concepts one to one. If ingredient is given as a mix (e.g. Co-dried gel of Magnesium Carbonate and Aluminium Hydroxide), it should be split in multiple enitities with distinct new codes; each component of the mix must be mapped to standard ingredient. | + | |
| - | + | ||
| - | One to many mappings with precedence should be used if: | + | |
| - | * Source ingredient is an ion (like calcium, iron, zinc, etc.), which should be mapped to all it's salts; | + | |
| - | * Source ingredient is a herbal extract, which should be mapped to all suitable standard concepts; | + | |
| - | * Target vocabularies contain duplicates of standard ingredients. This is rare. | + | |
| - | + | ||
| - | **Dose Forms** are commonly mapped to multiple RxNorm dose forms with precedence. Modified release forms should be first mapped to corresponding forms in RxNorm vocabulary (like Delayed Release Oral Capsule), and then to more generic forms (Oral Capsule) with lower precedence. | + | |
| - | + | ||
| - | ==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), | + | |
| - | + | ||
| - | 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, | + | |
| - | 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/ | + | |
| - | + | ||
| - | * Inhalers, enemas or sprays that release certain dosage of active ingredient per activation should also be stored in numerator/ | + | |
| - | * All drugs with fixed amount must have dosage in amount fields and all solutions must have dosage filled in numerator and denominator fields. When liquid drugs in data contain concentration information without volume, DENOMINATOR_VALUE field is left empty. | + | |
| - | * Gases for inhalation must be put in numerator fields with % in unit field without filling denominator fields. It’s the only acceptable use of percents in DS_STAGE. Make sure to convert everything else to mg/ml or mg/mg. | + | |
| - | * Patches, drug implants and other forms that release molecules over a period of time (even extended release tablets or capsules) may also be stored in numerator/ | + | |
| - | * Inhalers, enemas or sprays that release certain dosage of active ingredient per activation should also be stored in numerator/ | + | |
| - | * If dose form for the source concept is given as a soluble powder without a solvent (except powder inhalers), dosage is stored in amount field. | + | |
| - | * For drugs that are administered in a form of oral liquid (solution, suspension, syrup), denominator value of 5 ML should be kept only when we are certain that the dosage is not given “per tbsp.”; if 5 ML is not an actual fixed administered dose (e.g. a sachet or vial), it should be treated as concentration (DENOMINATOR_VALUE = NULL). | + | |
| - | * Box size equal to 1 should be simply stored as NULL. | + | |
| - | * If source provides conflicted, mixed or incomplete info on one or more ingredients dosage or solution volume, drug should not have entries in ds_stage | + | |
| - | + | ||
| - | ==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, number of doses in each box and number of boxes 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. Packs are allowed to have branded drugs as components, although usually Brand Name is only attributed to packs as a whole. Supplier may only be atrributed to the pack as a whole. | + | |
| - | + | ||
| - | ==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: | + | |
| - | + | ||
| - | ^Field^Required^Type^Description^ | + | |
| - | |concept_code_1|Yes|string(255)|CONCEPT_CODE of source concept in either [[documentation: | + | |
| - | |concept_code_2|Yes|string(255)|CONCEPT_CODE of target concept in either [[documentation: | + | |
| - | |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: | + | |
| - | |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: | + | |
| - | + | ||
| - | This table needs not to be symmetrical like CONCEPT_RELATIONSHIP; | + | |
| - | Note that concepts with equivalence mappings in this table should not have relations to attributes in other input tables. | + | |
| - | + | ||
| - | + | ||
| - | === Quality of input tables === | + | |
| - | + | ||
| - | The input tables need to have the following quality requirements: | + | |
| - | + | ||
| - | ^ Rule ^ If rule is violated | + | |
| - | | Each record should be unique in all tables. | + | |
| - | | Concept Codes should be unique and should not repeat for different products. | + | |
| - | | Combinations of product components should be unique. These are Ingredient-strength(s) combination, | + | |
| - | | Each product should have links (records in INTERNAL_RELATIONSHIP_STAGE) to all their Ingredients. | + | |
| - | | Ingredients should be linked to their Standard Counterparts. | + | |
| - | | Dose Forms should be linked to their Standard Counterparts. | + | |
| - | | Brand Names should be linked to their Valid Counterparts. | + | |
| - | | All % in source dosages should be converted into mg/ml (mg) unless it is a gas. | A drug would not be mapped to it's Standard Conept | + | |
| - | | Marketed Product (a drug that has relationship to it's supplier in INTERNAL_RELATIONSHIP_STAGE) should have both dosage and Dose Form | The product won't be processed into CONCEPT_STAGE table. | + | |
| - | | Boxed drug should have both dosage and Dose Form. | The product won't be processed into CONCEPT_STAGE table. | + | |
| - | | Product ingredients should match in INTERNAL_RELATIONSHIP_STAGE and DS_STAGE | + | |
| - | | When mapping Ingredients, | + | |
| - | | Concepts with active 'Maps to' relations inside CONCEPT_RELATIONSHIP_MANUAL should not have any entries indicating relationships with attributes | Redundant branches of RxNorm Extension or multiple mappings may be created | | + | |
| - | + | ||
| - | For quality assurance of input tables you can use drug_stage_tables_QA.sql script from project' | + | |
| - | + | ||
| - | All propositions to add a new vocabulary into CDM may be submitted (optionally with prepared input tables) as [[https:// | + | |
| - | + | ||
| - | ** Matching ** | + | |
| - | This step is necessary to add inferred equivalence relationships between new and existing Standard Concepts. All matches are created. | + | |
| - | + | ||
| - | The matching considers all components (Ingredient-strength(s), | + | |
| - | + | ||
| - | ** Inferring of missing Concept Classes ** | + | |
| - | + | ||
| - | After RxNorm Extension Standard concept with the fullest attribute set will be created for each source entity, all missing preceding Concept Classes are inferred from the existing ones, from bottom upwards. | + | |
| - | + | ||
| - | ^Concept Class^Defined by^ | + | |
| - | |Clinical | + | |
| - | |Branded Drug Component|Ingredient-strength(s), | + | |
| - | |Clinical Drug Form|Ingredient(s), | + | |
| - | |Branded Drug Form|Ingredient(s), | + | |
| - | |Clinical Drug|Ingredient-strength(s), | + | |
| - | |Branded Drug|Ingredient-strength(s), | + | |
| - | |Quantified Clinical Drug|Ingredient-strength(s), | + | |
| - | |Quantified Branded Drug|Ingredient-strength(s), | + | |
| - | |Clinical Drug Box|Ingredient-strength(s), | + | |
| - | |Branded Drug Box|Ingredient-strength(s), | + | |
| - | |Quantified Clinical Box|Ingredient-strength(s), | + | |
| - | |Quantified Branded Box|Ingredient-strength(s), | + | |
| - | + | ||
| - | Even though all drug classes are inferred, only those will be written to the CONCEPT table that have no mapping to an existing equivalent Standard Concept. | + | |
implementation_international_drug_vocabulary.1563812823.txt.gz · Last modified: by ekorchmar
