OHDSI Home | Forums | Wiki | Github

Condition Status and Condition_type_concept_id


(Melanie Philofsky) #1

@aostropolets, @Christian_Reich, @DTorok, @Dymshyts, and others with ideas/opinions,

The EHR WG discussed Condition Status and Condition Type concept_ids on our last call. Epic, AllScripts, “secret data asset”, PEDSnet, All of Us, academic institutions, business, new OMOP’ers and others joined the call. We discussed our varied needs and the granularity of our data. And now we are seeking some guidance :slight_smile:

What we have:

  • billing diagnoses (comes from a billing table), encounter diagnoses (originates in a Provider-Person interaction), problem list (All the Conditions you have now and in the past. Can be chronic or resolved), chief complaint (reason the Person sought treatment, not a Provider dx)

  • The above can have a primary vs other stated position. The Primary position is the main reason or Condition on why a Person sought care

  • Status = Admitting diagnosis, final diagnosis aka discharge diagnosis, active, resolved, inactive, preliminary

Conclusions:

  • Conventions are unclear on how and when to use which type_concept_id or status

  • The list of suggested Status concept_ids is short


Which field stores the secondary diagnosis?
(Dmytry Dymshyts) #2

There’s another open question on condition_status_concept_id

We need to revive this discussion.


(Seng Chan You) #3

What is the solution for ‘inpatient primary’ diagnosis?

Currently, when we extract the covariates by using useConditionOccurrencePrimaryInpatient in the FeatureExtraction package, it extracts the condition concept ids with condition type concept ids of (38000183, 38000184, 38000199, 38000200).

So should we add the information for ‘visit’ to the condition type concept Id? Since this is really important for cohort definition, we need a solid solution.


(Melanie Philofsky) #4

Hi @SCYou,

No, it isn’t necessary because the Visit data is already linked to the Condition table. Just select Conditions where the visit_concept_id = 9201 for inpatient

‘primary’ is the status of a Condition. These data will be located in the condition_status_concept_id field. See the notes here.

As a FYI, the condition_type_concept_ids you list above are specific to claims data. I’m not sure how many EHR data holders use them.


#5

Hello. I’m Seok.
After selecting “Condition-Primary Inpatient” among the covariates options for analyzing the Estimation (Population Level Effect Estimation) in ATLAS, R was executed and the feature was extracted using four condition_type_concept_ids (38000183, 38000184, 38000199, 38000200).

So is this covariate created for use only if it is “specific to claims data”?


(Seng Chan You) #6

This is where Development group and CDM group in OHDIS should be harmonized as a community.

I do agree with @MPhilofsky 's opinion in terms of CDM architecture.

Still, if we want to use OHDSI packages such as FeatureExtraction, CohortMethod, PatientLevelPrediction, we should use the condition concept ids with combined information (‘primary’ / ‘inpatient’).

How can we solve these conflicts? @schuemie @clairblacketer @Patrick_Ryan @Christian_Reich


(Melanie Philofsky) #7

Hi @kims,

The type_concept_ids represent the provenance of the data and are usually hard coded in the CDM. You should ask the data owner or review the specifications to see how it was coded for your data. If you used Colorado’s data, then your selection wouldn’t return any Condition records. Since Colorado used the EHR specific concept_ids for their Condition data.


t