OHDSI Home | Forums | Wiki | Github

ICD9/CPT mappings to SNOMED for condition_occurrence table

As I am testing out the V2 of the Stanford ETL, I was running the Treatment Pathway Analysis study and found that I got a total of 0 patients left. I narrowed it down to the study using only SNOMED concepts to determine the patients with the desired condition. Our new (and cleaner) mapping, maps our visits table and its IC9/CPT codes to the condition/procedure_occurrence tables, as they are mapped to their corresponding concept_ids. @Christian_Reich is there a preferred mapping from these ICD9/CPT concept_ids to its corresponding SNOMED concept_ids? @jon_duke Did Regenstrief had to do a similar mapping, to populate the condition tables?

Our older ETL didn’t have this issue with the studies as we were using the extracted clinical notes terms in this table in conjunction with the the visits ICD9/CPTs, but now we are keeping them separated.

@Juan_Banda:

No such a thing as preferred mapping. How does the Treatment Pathway query: By SNOMED IDs and their children?

Why are you keeping conditions separate if they are coming from the notes or the EHR?

Are you running this off the VocabV5 that Christian just released two days
ago? http://ohdsi.org/web/ATHENA

Conditions are separated as the ones that come from our visits table via ICD9/CPT are put on the conditions_occurrence table. The NLP/Text derived ones from the unstructured notes are now placed on the observations in order not to pollute the table with mined terms.

Treatment pathway queries by:

"JOIN ohdsiv5.CONCEPT_ANCESTOR ca on ce.CONDITION_CONCEPT_ID = ca.DESCENDANT_CONCEPT_ID and ca.ANCESTOR_CONCEPT_ID in (201820)"

Extracted from:

select ip.PERSON_ID, ip.INDEX_DATE, ip.COHORT_END_DATE
from T2DM_IndexCohort ip
LEFT JOIN 
(
    select ce.PERSON_ID, ce.CONDITION_CONCEPT_ID
    FROM ohdsiv5.CONDITION_ERA ce
    JOIN T2DM_IndexCohort ip on ce.PERSON_ID = ip.PERSON_ID
    JOIN ohdsiv5.CONCEPT_ANCESTOR ca on ce.CONDITION_CONCEPT_ID = ca.DESCENDANT_CONCEPT_ID and ca.ANCESTOR_CONCEPT_ID in (201820)
    WHERE (ce.CONDITION_ERA_START_DATE between ip.OBSERVATION_PERIOD_START_DATE and ip.OBSERVATION_PERIOD_END_DATE)
        --cteConditionTargetClause    
) ct on ct.PERSON_ID = ip.PERSON_ID
GROUP BY  ip.PERSON_ID, ip.INDEX_DATE, ip.COHORT_END_DATE
HAVING COUNT(ct.CONDITION_CONCEPT_ID) >= 1
;

I am still running an older version of Vocabulary 5. Would using the new one solve this issue?

Juan:

Well, it’s not clear what the problem is. The query is looking for SNOMED codes. Your ICD9 codes should be mapped to those. How about we take a look together in a Webex?

Hello,

Sure, let me know what availability you have and we can take a look. I
might be incorrectly mapping our visit table only to icd9 concepts and not
SNOMED concepts.

Ah, the visit table should not have icd9 or snomed. There are 4 standard
visit concepts: inpatient, outpatient , er, and longterm care, which you
need to assign in your etl based on the source of the data. The diagnoses
associated with each visit would be stored in the condition occurrence
table, provided that the standard concept that your source code maps to has
a domain of condition.

Indeed, the visits table on cdmv5 does not contain any icd9 or SNOMED
concepts. It is the diagnoses that are associated with each visit in our
stride db are found in icd9 or cpt. When I map them to place them in the
conditions table they are from the condition domina but from icd9 and not
snomed. Hopefully this is more clear.

The icd9 codes are nonstandard source concepts. You need to use vocabv5 to
map these concepts to their standard concept counterparts, which are in
most cases snomed concepts in the condition domain.

Ok, just what I thought. Any preferred way of mapping them for vocab5? Or
should I just pre-map them before from icd9 to snomed and then map them to
vocab5.

The mapping from ICD9 to SNOMED is available in the CONCEPT_RELATIONSHIP
table. Here’s a query against the VocabV5 to show you how to identify the
ICD9 codes and find the standard concepts that they refer to. Note, ICD9
diagnosis codes are not all conditions; ~3800 of the ~19000 ICD9 codes map
to concepts which are Procedures, Measurements, Devices, other other
Observations. You need to use the target standard concept’s domain id to
determine where the data should be placed within the model.

select source.concept_id as source_concept_id, source.concept_code as
source_concept_code, source.concept_name as source_concept_name,
target.concept_id as target_concept_id, target.concept_name as
target_concept_name, target.domain_id as target_domain_id
from
(
select concept_id, concept_name, concept_code
from concept
where vocabulary_id = ‘ICD9CM’
) source
inner join
concept_relationship
on source.concept_id = concept_relationship.concept_id_1
and concept_relationship.relationship_id = ‘Maps to’
inner join
concept target
on concept_relationship.concept_id_2 = target.concept_id
and target.standard_concept = ‘S’
;

1 Like

Thanks!! This will do the trick. I was no t aware that the concept _
relationship table had this mapping. This should make the mapping a breeze.
Thanks for the heads up on the domain mappings. I had them already
properly separated, but didn’t map them all the way to snomed. Looking
forward to re-run achilles and all the studies on the new etl.

t