OHDSI / Vocabulary-v5.0

Build process for the OHDSI Standardized Vocabularies. Currently not available as independent release.
The Unlicense
215 stars 75 forks source link

Hierarchy for TYPEs #180

Open ericaVoss opened 6 years ago

ericaVoss commented 6 years ago

@gowthamrao and I would like to see a simple classification system created for the TYPE fields. Basically if I want to know all the "patient reported" types or "claims" types I should be able to use the Vocab the find those.

Maybe the CONCEPT_CLASS_ID might be good enough for this?

CONCEPT_ID CONCEPT_NAME DOMAIN_ID VOCABULARY_ID CONCEPT_CLASS_ID
45756856 Outpatient detail - 2nd position Type Concept Procedure Type Claim Record
44814721 Patient reported Type Concept Observation Type Patient Reported
44818704 Patient reported value Type Concept Meas Type Patient Reported

I see there a whole bunch of SNOMED Type Concepts, I don't know how this idea would affect them. I know for the OMOP generated concepts, this would probably work. But this is just an idea, implementation could be as the Vocab team see fits.

cgreich commented 6 years ago

This is Themis #3.

cgreich commented 6 years ago

In fact, that's how we should fix this problem: Precoordinate concepts if we need to say more than one thing ("Outpatient detail", and "2nd position"), even though in this case I think we don't need the Outpatient detail thing. But let's discuss.

chrisknoll commented 6 years ago

@cgreich , there's a request to add a a feature to CIRCE related to excluding condition_type_concepts, and one idea was proposed to leverage concept set expressions (which assumes that there would be concepts in concept_ancestor for the concepts of interest).

Question: do you plan on having condition_type, drug_type, etc concepts in concept_ancestor so that we will have a hierarchy of {domain}_type concepts?

At the moment, we assume that there is no hierarchy (and infact, you wouldn't find any _type concepts in concept_ancestor), Is this assumption wrong, or is this assumption goign to change in the future if you support concept types in a hierarchy?

gowthamrao commented 6 years ago

@cgreich @chrisknoll {domain}_type_concepts have hierarchy

image

http://athena.ohdsi.org/search-terms/terms/32023?fullscreen=false&levels=10&standardsOnly=false&zoomLevel=4

chrisknoll commented 6 years ago

I'm not seeing any of that in my version of the cdm vocabulary v5.0 01-DEC-17.

@cgreich : is the figure presented by @gowthamrao based on concept_ancestor, or is there something else that is driving this view?

chrisknoll commented 6 years ago

Update, we got the v5.0 09-JUN-18 version installed, and it does appear we have type concepts in concept ancestor:

SELECT c.domain_id, c.vocabulary_id, COUNT(*)
FROM dbo.concept_ancestor ca 
JOIN dbo.concept c ON ca.ancestor_concept_id = c.concept_id
WHERE c.domain_id = 'Type Concept'
GROUP BY c.domain_id, c.vocabulary_id

Yields:

domain_id   vocabulary_id   n
Type Concept    Condition Type  102
Type Concept    Death Type  14
Type Concept    Device Type 3
Type Concept    Drug Type   15
Type Concept    Meas Type   6
Type Concept    Note Type   10
Type Concept    Obs Period Type 6
Type Concept    Observation Type    13
Type Concept    Procedure Type  95
Type Concept    Visit Type  48

Interesting to see so many condition types, here's the hierarchy query:

SELECT c.concept_name, count(*) AS children
FROM dbo.concept_ancestor ca 
JOIN dbo.concept c ON ca.ancestor_concept_id = c.concept_id
WHERE c.domain_id = 'Type Concept' AND c.vocabulary_id = 'Condition Type'
GROUP BY c.concept_id, c.concept_name

But all these rows say there is only 1 child (indicating that there isn't actually a hierarchy to any of these condition types). So, it's a little mysterious about how we use these values from concept ancestor as of this version of the vocabulary.

Visits do seem to have some level of hierarchy in it:

concept_name    children
Visit derived from encounter on claim   14
Visit derived from encounter on medical claim   10
Visit derived from encounter on medical facility claim  4
Visit derived from encounter on medical professional claim  4
Visit derived from EHR record   3
Visit derived from encounter on medical facility claim denied   1
Visit derived from encounter on medical professional claim denied   1
Visit derived from encounter on medical professional claim deferred 1
Visit derived from encounter on vision claim    1
Visit derived from encounter on dental claim    1
Visit derived from encounter on pharmacy claim  1
Visit derived from encounter on medical facility claim deferred 1
Visit derived from encounter on claim authorization 1
Visit derived from encounter on medical facility claim paid 1
Visit derived from encounter on medical professional claim paid 1
Visit derived from EHR encounter record 1
Clinical Study visit    1
Visit derived from EHR billing record   1
cgreich commented 6 years ago

@chrisknoll:

Thanks for bringing this up. I was thinking "If we introduce hierarchies to Types we need to tell Chris, so he can offer it in the tools". So, yes, I think this is where this goes. Will be done before the Symposium when we release Themis conventions and changes, but not much earlier.