| OHDSI Home | Forums | Wiki | Github |
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”?
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
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.
Hi All,
Can we use 4307107, 4309641 as condition_status_concept_ids for primary diagnosis and secondary diagnosis codes respectively?
Thanks!
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!
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)
You are right, there isn’t. We created our own concepts for this. Why are you worried about SNOMED?
Not worried. I am new to to OMOP and trying to understand logic setup in my ETL.
Thanks for providing feedback!
Is the idea of primary diagnosis somehow different from SNOMED concept 8319008 Principal diagnosis ?
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.
@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
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.
@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!
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:
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.
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.
For the positions, we still have Primary diagnosis for the primary or first position, and all subsequent positions are shrunk to Secondary diagnosis, @mmatheny. Rationale: There really is no difference between the, say, 4th and 13th position. Those positions are for diseases the patient is suffering from, but it’s not what led to the visit. They are an artifact of the reimbursement claim forms, and there is no deeper meaning defined for them.
Do you have a use case beyond “users continue to want”?
@Christian_Reich @MPhilofsky
Thank you both… we have extensively implemented custom columns for VA uses , we label them x_* type columns to distinguish them from omop standards, but in this case, since condition_status still encompasses primary and secondary, I"ll go to our ETL group with a proposal to just limit to primary/secondary in the status_concept_id slot and store the position number in the source_value… that allows for use, and if we get user feedback that it is computationally slow or other limitations we can adapt from there. Thanks for the consultation
Re-starting this thread. The documentation states:
“This concept represents the point during the visit the diagnosis was given (admitting diagnosis, final diagnosis), whether the diagnosis was determined due to laboratory findings, if the diagnosis was exclusionary, or if it was a preliminary diagnosis, among others.”
However, in the list of accepted Concepts, there are no concepts for an exclusionary diagnosis (neither for diagnosis due to laboratory findings). Further, according to OMOP conventions we should only record what was actually diagnosed. We should either update the documentation or add concepts to match.
@MPhilofsky A topic for Themis? @clairblacketer And CDM WG to fix documentation for now?
True, @MaximMoinat.
How about we take out the “exclusionary diagnosis” (because it actually wasn’t made) and add “lab-based diagnosis”. Do you have data with those?
