| OHDSI Home | Forums | Wiki | Github |
Hi, OHDSI
In person table, there are various type of source, concept_id fields as source_value, concept_id, source_concept_id.
I know the concept_id which is generated by OMOP, source_value which is for mapping with concept_id for standardizing, but what does source_concept_id exist for?
Thank you all
Hi Micheal,
In short, source_concept_id represents the concept from source data which can be found in OMOP Vocabularies. For example, source data has ICD10 code âM05.04â (âFelty syndrome, handâ). Looking this code up in OMOP Vocabularies, we get concept_id=42616532 â this is the source_concept_id, as itâs obtained from source data. This concept, however, is non-standard, but Concept Relationship table provides the mapping to a standard concept 81097, which can be put in concept_id field.
For this example, source_value=âM05.04â, source_concept_id=42616532, concept_id=81097.
A brief description of different field types in CDM can be found here on GitHub.
Okay, for clear summary of this,
The source_value is an original raw data, and source_concept_id is that the source_value_code is translated into the id, and the standard_concept_id is only used in OMOP-CDM, being translated into the standard from source_concept_id.
Please tell me if I am wrong
Thank you
Yes, thatâs correct.
Thank you rookie 
your saying helped me a lot.
Does OHDSI newly convert source_value into source_concept_id?
And Is this for mapping the source_concept_id to Standard_concept_id?
@MichealJeong you donât need to care about the source_concept_id if youâre using Korean DB.
Studying with CDM specification, I donât understand a few fields in CDM.
Sorry if I too much require a lot, but I would like to know about all the fields.
In the future, I will analyze the synpuf full data with analysis tools. Thatâs my plan.
Actually, I was wrong @Christian_Reich.
Most source values in Korean DB donât have concept_id. Thatâs why we donât need to care about this.
Still, the condition table can have concept_id for ICD 10 codes. So⌠I was wrongâŚ
But wait: Donât you have your source data coded? In things like KCD6 etc.? Wouldnât that have to go into the source_concept_id?
@Christian_Reich
As long as I know, only OMOP concept_id can be stored in SOURCE_CONCEPT_ID. Technically, we should map the KCD6 to OMOP concept id for ICD 10 then, store the OMOP concept id for ICD10 in the database. Capturing source_concept_id is possible only for the condition in Korea.
As you might know, most health care services are covered by the national insurance in Korea. The HIRA (Health Insurance Review and Assessment Service) reviews whole claims and and National Health Insurance Service (NHIS) pays back to the hospital as the insurer. See the details here.
99% of claims are submitted electronically (details). Conditions are recorded in KCD-6, which is very similar to ICD-10 (The codes for oriental medicine are added). For drug, procedure, device, and measurement, Korea has unique national medical code system, EDI (Electronic Data Interchange) like READ in England.
So, Korea does have the national standardized code system, it would be great if this can be intergrated into OMOP CODE as the source. Then we can capture source_concept_id for other tables.
If KCD6 is a 100% copy of ICD10 (WHO edition) then yes, we donât need it as a separate vocabulary. However, the translations should be loaded into the CONCEPT_SYNONYM table. Most countries do some modifications, and I read that you use the U codes for traditional medicine. In that case, it is a vocabulary in its own right, and the U codes either are not mapped or we give them standard assignment. However, the UMLS says ICD10 corresponds to KCD5.
Which means now I am totally confused.
Iâm sorry, @Christian_Reich . The relationship between KCD and ICD10 is slightly confusing to me, tooâŚ
Iâll let you know after I investigate this problem more.