OHDSI Home | Forums | Wiki | Github

Condition Status and Condition_type_concept_id

CDM Builders
#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

1 Like
Which field stores the secondary diagnosis?
#2

There’s another open question on condition_status_concept_id

We need to revive this discussion.

#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.

1 Like
#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.

1 Like
#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”?

atlas_estimation_covariate_list
atlas_estimation_covariate_list1350×930 79.2 KB

#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

1 Like
#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.

#8

Hi All,

Can we use 4307107, 4309641 as condition_status_concept_ids for primary diagnosis and secondary diagnosis codes respectively?

Thanks!

#9

32902 “Primary diagnosis” and 32908 “Secondary diagnosis”. Use Domain “Condition Status” only.

#10

Hi All,

I am trying to understand concept_id for ‘Primary diagnosis’.

There is no ‘Primary diagnosis’ for SNOMED vocabulary_id.
There is ‘Admitting diagnosis’ for SNOMED vocabulary_id.

Is there a reason why there is no SNOMED vocabulary_id for ‘Primary diagnosis’ ?

These are the definitions:
{
“concept_id”: “32902”,
“concept_name”: “Primary diagnosis”,
“domain_id”: “Condition Status”,
“vocabulary_id”: “Condition Status”,
“concept_class_id”: “Condition Status”,
“standard_concept”: “S”,
“concept_code”: “OMOP4976972”,
“valid_start_DATE”: “2020-08-20”,
“valid_end_DATE”: “2099-12-31”,
“invalid_reason”: null,
“load_table_id”: “athena_vocab”,
“load_row_id”: null
},
{
“concept_id”: “4203942”,
“concept_name”: “Admitting diagnosis”,
“domain_id”: “Observation”,
“vocabulary_id”: “SNOMED”,
“concept_class_id”: “Qualifier Value”,
“standard_concept”: “S”,
“concept_code”: “52870002”,
“valid_start_DATE”: “1970-01-01”,
“valid_end_DATE”: “2099-12-31”,
“invalid_reason”: null,
“load_table_id”: “athena_vocab”,
“load_row_id”: null
}
]

Thanks!

#11

Primary diagnosis concept is especially needed for healthcare claims processing. So it was introduced in OMOP because was absent in SNOMED. I don’t know the exact reason for the lack of this concept in SNOMED. But you can find here a lot of more detailed concepts in SNOMED with similar meaning (Athena) (in subsumes)

#12

You are right, there isn’t. We created our own concepts for this. Why are you worried about SNOMED?

#13

Not worried. I am new to to OMOP and trying to understand logic setup in my ETL.
Thanks for providing feedback!

#14

Is the idea of primary diagnosis somehow different from SNOMED concept 8319008 Principal diagnosis ?

#15

No. Same thing. But you need to use Condition Status concepts (the ones we made) for the Condition Status. No reason we couldn’t have used SNOMED ones and declared them the Standard. Except SNOMED didn’t have all the ones we needed, and then it would have been a hodgepodge anyway.

#16

Makes sense. Thanks @Christian_Reich

#17

@Christian_Reich
We are in the process of completing the VA Cerner Millennium build and are revisiting some of our ViSTa/CPRS transform decisions.

We do use inpatient position for all our inpatient data (ViSTA/CPRS & Cerner) and primary/secondary for outpatient data, both EHR based and claims based (we are both care delivery & 3rd party payor).

At the time we implemented initially, in conditions for example, condition_status fields did not exist so we put the inpatient data in condition_type_concept_id using the inpatient header 1-15 codes and outpatient we used primary/secondary.

As we transform Cerner, we have an opportunity to revisit this and move these position headers over to condition_status to make condition_type the consistent provenance data noted above (ehr vs claims). However, the header information is still listed in the CDM as ‘Condition Type’ in concept_class_id. So barring different guidance from you / this group, we were going to continue this implementation using the position sequence / primary/ secondary in condition_type and then preliminary/final/preop/admission/postop in condition_status.

If the spirit is to move the #'d inpatient headers to condition_status and name them ‘final inpatient header’ or something to denote final diagnoses (which they only get numbered when final), that would be great too.

Looking for guidance,
Thanks for your time as always!
Michael Matheny

#18

Hello @mmatheny,

The condition_type_concept_id identifies the provenance of a record, i.e. an inpatient claim record, an EHR’s Problem List record, an outpatient claim record, etc. The full list of acceptable concept_ids can be found here where the domain_id = “Type Concept” and standard_concept = ‘S’.

The community decided we had inadvertently crammed two different ideas into the condition_type_concept_id field and they needed to be split into two separate fields. So, when we discussed splitting the “status” of a condition out from the condition_type_concept_id, it was decided a type_concept_id can be identified if it finishes this sentence: “This record is derived from ______”.

Per the CDM conventions, the condition_status_concept_id “best represents the point during the visit when the diagnosis was given”. The acceptable concept_ids for status are found here where the domain_id = ‘Condition Status’ and standard_concept = ‘S’

For this example:

The condition_type_concept_id = 32855, inpatient header claim. The #'s have been eliminated. There are just the headers and details now, no positions.

For the condition_status_concept_id, I’m unsure if “final” is synonymous with “discharge”. If it is, the condition_status_concept_id = 32903, primary discharge diagnosis might be the most appropriate. Or there might be a more appropriate standard concept_id linked above.

#19

@MPhilofsky Thank you very much for your response! We can start making those convention changes, but how is position recorded now, as some of our users will continue to want that information? Condition status, as described, doesn’t seem to really encompass that either…?

Thanks again!

#20

Correct, condition status doesn’t represent a claim position. Since there isn’t a standardized way to represent a claim position, you have two choices:

  1. Petition for a convention/vocabulary change. Write up your network use case and present to the CDM WG, which is the governing organization for CDM conventions. It sounds like this is an “internal” only use case, if so, then proceed to option #2.

  2. Either put this information into the condition_status_source_value field or create an extension column to hold these data (poster on extension columns in the CDM). This allows the CDM to retain it’s shared universality, OHDSI tools run without error, concept_ids pass data quality checks, and your internal requirements are met. These data won’t be available for OHDSI network studies, so if your goal is to study claim position with other OHDSI collaborators, option #1 would be more appropriate.

t