OHDSI Home | Forums | Wiki | Github

Some problem about the treatment pathway study

HI ALL,

Recently, we converted a BIG patient claim database to CDM. (10 million patients)
We are trying to use the treatment pathway package to examine the database. We have some problem when running the package over this data set:

  1. The original diagnosis code in the claim data base is ICD9, thus we reused the ICD9 code in the condition table. However, the package used the SNOMED code in the query. Do you have a query using the ICD9 codes?

We tried to convert the SNOMED code to ICD9 code and reran the package. The result looks weird.

E.g., for the Depression:
“2”,“Number of persons with at least one drug exposure”,469401
“3”,“Number of persons with at least one drug exposure and >1 year of prior observation and >1 years of follow-up observation”,137093
“4”,“Number of persons in final qualifying cohort”,64

Is there a solution for the query codes using ICD9 instead of SNOMED?

  1. For the ERA table (drug_era, condition_era), is there a recommended GAP value? In one previous thread, I see someone used 36 days, other one used 30 days.

Thanks,
Yonghui

@yonghui:

I think this is a very similar question to your very first post about NDC and RxNorm. So, here is the answer:

When you convert the data to CDM, you have to create the CDM tables, but you also have to map your original codes to what is called “Standard Concepts” in the OMOP/OHDSI world. For conditions, these are mostly SNOMED, for drugs, they are mostly RxNorm. But you don’t have to know that. Here is what you do:

  1. For each code, find the so-called Source Concept in the CONCEPT table. So, for ICD-9-CM code 410 “Myocardial infarction” you look it up through select * from concept where vocabulary_id='ICD9CM' and concept_code='410' and invalid_reason is null; In this case this is concept_id=44832372.

  2. Map the Source Concept to a Standard Concept. This is easy as well: select * from concept_relationship where concept_id_1=44832372 and relationship_id='Maps to' and invalid_reason is null; This will return a record where concept_id_2=312327. This is the concept_id you need to put into the condition_concept_id field of your CONDITION_OCCURRENCE table. If you want to know what 312327 stands for you can just query the CONCEPT table again: select * from concept where concept_id=312327; and it will return a Standard SNOMED-CT concept for myocardial infarction.

In this example, ICD-9-CM was mapped to an equivalent SNOMED-CT Concept. But it doesn’t have to be that way. If you already had SNOMED in your data, and you tried to map it this way, it would still work: The CONCEPT_RELATIONSHIP record would map that Concept right to itself. It works the same way for NDC.

Christian

OHHHHH. I see the problem. We mistakenly used the source concept id as the standard concept id. Thanks Christian.

Regarding to the second question, do you have a recommended GAP value for the ‘drug_era’ and ‘condition_era’ tables?

Thanks,
Yonghui

@yonghui:

Not sure what you mean by “recommended GAP”. The gap_days are a value that is derived from the data, there is nothing to recommend. What you can play with as an input parameter is the persistence window for building eras. However, we set that to 30 days as a standard. If you want other eras you may want to generate cohorts.

More discussion about gap_days and persistence window you can find here: Where does gap_days come from when building CDM v5 drug_era?.

Yes, I meant the “persistence window” when asking about the GAP.
I will regenerate the tables and run the treatment pathway package.

Thanks for your answer.

Yonghui

Hi Christian,

I have a following up question about the standard concept mapping.

I found that there are multiple ‘Maps to’ concepts for some ‘source concept’. In that case, which one should be used?

For example:
The Icd9 code 344.40 can be mapped to source concept id 44820764. This source concept id (44820764) has the following two ‘map to’ concepts:

concept_id_1 | concept_id_2 | relationship_id | valid_start_date | valid_end_date | invalid_reason
--------------±-------------±----------------±-----------------±---------------±---------------
44820764 | 379012 | Maps to | 2013-10-10 | 2099-12-31 |
44820764 | 4093682 | Maps to | 2013-10-10 | 2099-12-31 |

concept_id | concept_name | domain_id | vocabulary_id | concept_class_id | standard_concept | concept_code | valid_start_date | valid_end_date | invalid_reason
------------±------------------±----------±--------------±-----------------±-----------------±-------------±-----------------±---------------±---------------
4093682 | Monoparesis - arm | Condition | SNOMED | Clinical Finding | S | 249944006 | 1970-01-01 | 2099-12-31 |

concept_id | concept_name | domain_id | vocabulary_id | concept_class_id | standard_concept | concept_code | valid_start_date | valid_end_date | invalid_reason
------------±-------------------------±----------±--------------±-----------------±-----------------±-------------±-----------------±---------------±---------------
379012 | Monoplegia of upper limb | Condition | SNOMED | Clinical Finding | S | 41764006 | 1970-01-01 | 2099-12-31 |

Thanks,
Yonghui

I believe how we handle this in our own ETL is that two condition occurrence records will be created for each of the Mapped To concepts that came from the source concept.

Thanks for your answer.
Is it a standard way to handle the multiple ‘map to’ relations?

Yonghui

I’m not the authority on this, but I believe the reason that you have one source concept mapping to multiple snomed concepts is that the source concept is a ‘mixed diagnosis’ type of code, which would be represented in SNOMED as two different codes. So, to capture that a patient had both diagnosis, you would want two separate records for each diagnosis. I can’t claim that this is the standard way of handling it, but I am pretty confident that creating two rows in condition occurrence is the proper action to take.

-Chris

It sounds reasonable.

Thank you, Chris.

Yonghui

t