Hi, @Vimala_Jacob,
My understanding:
source_concept_id is supposed to be a concept_id from the vocabulary. If it’s custom codes you’re mapping, then the source_concept_id should be set to 0. You should create your own internal vocabulary_id for the ‘source_vocabulary_id’ column. You should try to give your source code a description in the source_code_description but you can always re-use the source_code value there.
When would you have a non-zero source concept Id for your source codes? Imagine a case where there’s an EHR system that stores some of the medical data in an encoded format in a file such as ICD9:696.1. Now you could always have your ETL parse out the field to figure out what kind of code this is and map it directly during your etl, or you could create rows in your source_to_concept_map table for this example:
source_code: ICD9:696.1
source_concept_id 44819938 – Other psoriasis
source_vocabulary_id: CUSTOM_EHR_DIAG
target_concept_id: 75614 – Acrodermatitis continua
target_vocabulary_id : SNOMED
Then during your ETL you resolve the column value above to a soruce concept of the ICD9 and a target concept of the snomed concept.
Note to @Christian_Reich: Not sure why we need a target_vocabulary_id in this table, by specifying a target concept_id, you shoudl be able to look up the target concept’s vocabulary via a join to the concept table. Is there some other purpose of this column?
