You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are about to release a cleaned up MeSH with new mappings. In contrast to the other vocabs, where we import all codes that exist, and map those we can map, for MeSH those would be too many. So, we will only import those that have a mapping to something useful for us (Condtiion, Drug, Procedure, Measurement). We will cover both Headings It will come out shortly. Check it out.
The problem with this approach is that we won't have the internal hierarchy of MeSH. Since MeSH codes are not Standard Concepts they don't participate in the concept_ancestor hierarchy. Also, if they are not mapped we won't have them. Not sure whether that is a problem. If yes, let me know, and we start thinking.
Problem 2.6 in the paper we will have no solution for. it is exactly what it says it is.
Problem 2.7 is nasty for us. Because we could map to higher level classes, but right now the only Concepts we have a mapping for would be SNOMED Drug Classes, but we don't accept them as Standard Concept (and hence cannot map into them). We will add SNOMED Classes as as Standard Classification for Drugs. That is in the plan anyway. But it requires a comprehensive mapping between SNOMED and RxNorm Drugs, which I have been toiling with for month now. It's wicked. But we will get it done.
Problem 2.8 is similar to problem 2.6. Usually, they don't just "split" a Concept, except in those stereoisomer situations. We would have a way to fix it, but that would be a big surgery. Maybe later.
This draft article provides some updated best practice for mining ADEs from MEDLINE MeSH tags:
http://mor.nlm.nih.gov/pubs/pdf/2015-jbi-rw.pdf
Update the MEDLINE method to use the recommendations in the next version.
The text was updated successfully, but these errors were encountered: