Thanks for the reference. I think in that context, the source_to_concept map is about mapping custom, source-specific codes to a vocabulary concept. For @Haroun_Chahed, I think he needs a new column like 'source_record_id' where you can store a record identifier from the source system. I'm not sure if a single column would solve this problem tho. I've seen ETLs where visits (in this example) could be sourced from multiple tables (an Encouter table, an ER admission table, etc) and so just tstoring a record ID may not give you the info you need to trace it back to the exact source table (unless you put formatted value in the column so you could indicate the source table + the table row ID). It makes sense from an ETL debugging perspective, but I don't imagine this type of information would be useful in an analytic use case.
@Haroun_Chahed: nothing restricts you from adding your own schema or tables to your local CDM instance. You could have a 'record_map' table in your database where during your ETL, when you create a visit record (which will have a visit_occurrence_id) you could write to a record_mapping table that records what CDM records map to your source system records. Then you can put the approprate level of detail into your mapping table to go from a CDM domain table (like visit) back to your local source table. I would most definitely prefer a solution that doesn't expand the CDM standard tables if there's another way to manage this outside of the CDM tables.