OHDSI Home | Forums | Wiki | Github

Lack of ICD9 Hierarchy

CDM Builders
#1

In developing HERMES one of the things I have been asked to provide is the ability to easily navigate hierarchical relationships. Instead of having to go to advanced filters and choose ancestors of distance=1 to find parents and then do it again after navigating to the parent, users would like the ability to view and navigate a simple tree structure. I think this is likely a worth-while feature.

However it has come to my attention that the “non-standard” ICD9 concepts don’t have any relationships to each other and so that hierarchical information is not available. This means that we can’t do something along the lines of what we find here. While I understand ICD9 concepts are non-standard they also happen to be the most frequently searched and used concepts among the users I encounter. We’ll similarly be unable to provide this functionality for ICD10 as well.

Interested if others feel this would useful information for the vocabulary to provide which would then enable this kind of a feature? Would adding the relationships be a detriment in someway to the vocabulary?

Vocabulary hierarchy exploration via Atlas
#2

Frank:

Makes a lot of sense. Let’s see what other folks say. It’d be easy to switch it on and create insular hierarchies amongh Source Codes, like an ICD-9 hierarchy. I wouldn’t have a problem with that. Same is true for ICD-10, DRG, maybe Read,

What I will heavily resist, though, is to connect these to the main hierarchy. The mappings from source to standard concept, especially from ICD-9 to SNOMED should not be travelled backwards. You will get nasty artifacts.

#3

Traversing a hierarchy makes sense.

By the way, if you can get to the Medical Entities Dictionary (try http://med.dmi.columbia.edu/browser.htm and then MEDviewer) you can look at another vocabulary browser. It is a different structure, but still useful to compare.

George

#4

Christian, is it possible to update the OMOP Vocabulary as needed to support these “insular” hierarchies?

EG: From UMLS MRCONSO + MRHIER.PTR, I can get this structure:

   A8360935    690-698.99  OTHER INFLAMMATORY CONDITIONS OF SKIN AND ... 
    A8341668    690 Erythematosquamous dermatosis
        A8339749    690.1   Seborrheic dermatitis
            A20885353   690.10  Seborrheic dermatitis, unspecified
            A8357070    690.11  Seborrhea capitis

It seems that all I need in the OMOP Vocabulary would be a new concept record for “690-698.99 OTHER INFLAMMATORY CONDITIONS OF SKIN AND SUBCUTANEOUS TISSUE”, and the corresponding concept_relationship entries to represent the ICD9 “hierarchy”.

By the way, was there discussion around having a “path-to-root” data element as in UMLS?
We’ve found that having this denormalized field simplifies our vocabulary browser code. Having this provided by OMOP would go a long way towards our goal of not having to maintain any “after market” tables.

Don

#5

I like the criteria they are listing for a good vocabulary. But the browser is down.

#6

Don:

You mean you want to add these “690-698.99” entries as Concepts? We could do that. ICD-10 has the same idea. Here is why I am as reluctant as I appear: ICD-9 hierarchies suck. They are not very well crafted. The best (worst) example is the following:

785 Symptoms involving cardiovascular system
    785.0 Tachycardia, unspecified
    785.1 Palpitations
    785.2 Undiagnosed cardiac murmurs
    785.3 Other abnormal heart sounds
    785.4 Gangrene
    785.5 Shock without mention of trauma
    785.6 Enlargement of lymph nodes
    785.9 Other symptoms involving cardiovascular system

These things do not belong into a hierarchical class. I can give you many examples. So, I really do not want to promote using ICD-9 for analytical purposes. Map the stuff over to SNOMED and work with a hierarchy that was designed to be a hierarchy of medical concepts.

Not sure what you mean by path-to-root data element? What is that? A trajectory of how you get from any Concept to the root? If so - in SNOMED not a good idea. There is rarely only one path. Just look at min_levels_of_separation and max_level_of_separation. If they are different, you know there are at least two paths. But why would you want such a thing?

#7

For our clients, using SNOMED only for analysis is not yet an option. (Someday). In our application, having these pseudo-hierarchies help navigation, since the end user is used to working with the codes.

Similarly, the path-to-root element is another convenience for our application; when navigating our hierarchies we can quickly explode a node to show the entire graph. Multiple graphs are not a problem, as long as they aren’t cyclical.

#8

I happen to agree @donohara. While we wholeheartedly encourage users to use concepts that OHDSI considers standard concepts most of the time they are thinking ICD9/ICD10. Providing the end user the ability to navigate the hierarchy of the concepts they are familiar with gives them a level of comfort in using our tools.

I’m planning on adding quite a set of features to HERMES once these ICD9 relationships are made available including a simple tree viewer. But more importantly, an ability to take a set of non-standard concepts and standardize them for use across our other tools.

Eagerly looking forward to their inclusion.

#9

So, apart from ICD9 and ICD10 - any other vocabularies where you are looking at that? I have no idea how to do that in Read.

t