OHDSI Home | Forums | Wiki | Github

Help with a few fields (_source_concept_id)?

Hi, I’m working on planning the ETL to the CDM and I am a little confused about the fields ending in _source_concept_id. The documentation provides the following description:
“A foreign key to a (Condition/Procedure) Concept that refers to the code used in the source.”
I was wondering if someone could provide an example concept for these fields. If I’m understanding correctly, it is just a key to a concept that represents the encoding format of the source data? Our data are encoded in SNOMED, if that helps.

The specific fields are
PROCEDURE.procedure_source_concept_id
CONDITION.condition_source_concept_id
VISIT_OCCURRENCE.visit_source_concept_id

Additionally, I don’t quite understand these fields:
OBSERVATION.observation_event_id
OBSERVATION.obs_event_field_concept_id

Much appreciated!

Hi @dawsoneliasen,

The *SOURCE_CONCEPT_ID fields are there to help identify the source codes that were mapped into the standard concept stored in the _CONCEPT_ID field. For example, if you have a person with an ICD10CM code of M48.4 “Fatigue fracture of vertebra” it maps to the SNOMED concept id 4001458. For this record you would store the concept id for your ICD10CM code (1570677) in the CONDITION_SOURCE_CONCEPT_ID field and the standard concept 4001458 in the CONDITION_CONCEPT_ID field. You are lucky in that your data are coded in SNOMED so you can store the same concept id in both the *_SOURCE_CONCEPT_ID field and *_CONCEPT_ID field.

I see! That is helpful, thank you :slight_smile:

@clairblacketer. This is the kind of thing I would like to see in the CDM portion of TheBookOfOHDSI.

1 Like

@roger.carlson this is the exact thing we plan to cover in that chapter; in depth descriptions of fields and how they work. The ETL chapter will focus more on the logistics of getting your data into the CDM including pitfalls and solutions.

t