Is it possible to add a new condition_type_concept_id for diagnoses that are suspicious (i.e. screening diagnosis codes used to justify lab or diagnostic procedures but do not necessarily suggest the patient actually has that condition/diagnosis)?
I am working with Japan claims data right now and they use a “suspicious” flag for conditions that are used to justify diagnostic procedures. I would like to retain this information to link the suspicious condition with the diagnostic procedure, but note in the type_concept_id field that the code is a screening or suspicious code. I can imagine that this type_concept_id would be applicable to other datasets that record screening codes.
I would like a type_concept_id for:
Suspicious condition in an inpatient setting
Suspicious condition in an outpatient setting
The designation of “inpatient” and “outpatient” settings give context as to where the condition was being treated (or screened) at.
Tagging @Christian_Reich but also applicable to anyone else working on vocabularies. Thanks!
Can condition_status_concept_id be used to meet this use case? Because ‘suspicion’ sounds like a status, not a type.
From condition occurrence table condition_type_concept_id - A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the source data from which the condition was recorded, the level of standardization, and the type of occurrence.
condition_status_concept_id - A foreign key to the predefined concept in the standard vocabulary reflecting the condition status.
source data : you could use condition_type_concept_id to say that the data was sourced from lab or diagnostic procedure condition_status_concept_id : you could use a concept id for suspicious when there is a suspicious flag. I would use this concept id: http://www.ohdsi.org/web/atlas/#/concept/45768444
The inpatient vs outpatient will be in visit_occurrence table. So maybe not needed here.
It’s a good question, We met with this problem making ICD10CM to SNOMED mapping,
there are a bunch of “suspected” conditions,
T76.12XS Child physical abuse, suspected, sequela
T76.22XS Child sexual abuse, suspected, sequela
and other.
@Christian_Reich,so, if we agree @Gowtham_Rao approach that condition_type_concept_id is suitable here,
my team also can make mappings adding new relationship_id =‘Has status’ to “suspected status”,
and probably this approach allows to make other concepts clarification, for example
“Abdominal migraine, not intractable” ‘Has status’ “not intractable”.
What do you think?
Yes. Suspected status as a condition_status_concept_id.
And suspected status totally meets Condition Status definition:
“The Condition Status reflects when the condition was diagnosed, implying a different depth of diagnostic work-up”.
Slow today with keeping up with all the Forum discussions.
We actually have that request already for marking those diagnostic codes that are used to claim reimbursement for diagnostic Procedures. We are planning to add “Condition to be tested by diagnostic procedure”. Does that solve @jenniferduryea’s problem?
Wait. Status is not the same as the types. Which one do you want to map to?
It will be a Standard Concept concept_id=5086, concept_name=“Condition tested for by diagnostic procedure”, domain_id=‘Type Concept’, vocabualry_id=‘Condition Type’ and concept_class_id=‘Condition Type’.
BTW: We should also talk about the other Condition Types. They are ugly. We have these Inpatient detail, Inpatient header, Outpatient detail, Outpatient header and Carrier claim header permuted with primary, and then 1st -15th position. Isn’t Inpatient and Outpatient something that doesn’t belong to a Condition, but to a definition of a visit? What is a Carrier Claim? Why not just turning them into “Primary diagnosis stated on claim”, “1st diagnosis stated on claim”, “2nd diagnosis stated on claim”?
@Christian_Reich I’m not sure you want to open this can of worms on this thread - it could be disastrous But, yes, I do agree that the Condition Types are a bit of a mess.
But, yes, I do agree that the Condition Types are a bit of a mess.