documentation:vocabulary:data_etl
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| documentation:vocabulary:data_etl [2015/01/24 12:57] – cgreich | documentation:vocabulary:data_etl [2024/09/02 09:43] (current) – jcruz | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ===== Data ETL ===== | ===== Data ETL ===== | ||
| - | The most important impact the Standardized Vocabularies have on the ETL process from raw to CDM-formatted data is the Domain of each Concept. Irrespective from which source table a record comes, or what coding scheme it is represented by, the destination table will be determined by the domain_id of the respective Concept. Any ETL will have to follow the following logic for process every record in the source data: | + | Thank you for visiting |
| - | * ** Retrieve the source code** from the record. | + | |
| - | * **Find the Concept** that corresponds to the source code. In most cases, that is done by looking up the source code in the concept_code field with the correct content of the vocabulary_id field in the [[documentation: | + | |
| - | * **Map to a Standard Concept** (standard_concept=' | + | |
| - | * **Write a record in the corresponding CDM table** for each destination Standard Concept based on the content of the domain_id field. Place the ID of the Standard Concept into the < | + | |
| - | + | ||
| - | ^domain_id^CDM table^Field^Comment^ | + | |
| - | |Generic|Any|Any|Generic Concepts can be in any field that ends in concept_id.| | + | |
| - | |Gender|[[documentation: | + | |
| - | |Race|[[documentation: | + | |
| - | |Ethnicity|[[documentation: | + | |
| - | |Visit|[[documentation: | + | |
| - | |Procedure|[[documentation: | + | |
| - | |Modifier|[[documentation: | + | |
| - | |Drug|[[documentation: | + | |
| - | |Route|[[documentation: | + | |
| - | |Unit|[[documentation: | + | |
| - | |Device|[[documentation: | + | |
| - | |Condition|[[documentation: | + | |
| - | |Measurement|[[documentation: | + | |
| - | |Meas Value Operator|[[documentation: | + | |
| - | |Meas Value|[[documentation: | + | |
| - | |Observation|[[documentation: | + | |
| - | |Relationship|[[documentation: | + | |
| - | |Place of Service|[[documentation: | + | |
| - | |Provider Specialty|[[documentation: | + | |
| - | |Currency|[[documentation: | + | |
| - | |Revenue Code|[[documentation: | + | |
| - | |Specimen|[[documentation: | + | |
| - | |Spec Anatomic Site|[[documentation: | + | |
| - | |Spec Disease Status|[[documentation: | + | |
| - | + | ||
| - | * For some Source Concepts there is **no mapping to a Standard Concept** (there is no record in the CONCEPT_RELATIONSHIP or SOURCE_TO_CONCEPT_MAP tables), usually because the Source Concept is too generic or otherwise ill-defined. In these cases, the domain_id field of the Source Concept itself should be used to place the record in the right table. Some Source Concepts have combination Domains, such as " | + | |
| - | + | ||
| - | If the Domain of the destination Concept is " | + | |
| - | + | ||
| - | The same is true if you find a Type Concept Domain, like "Obs Period Type", "Death Type", "Visit Type", " | + | |
| - | + | ||
documentation/vocabulary/data_etl.1422104234.txt.gz · Last modified: by cgreich
