Ok, @Christian_Reich, you win. How do we go about adding for example the Japanese drug codes? What format do you need them in, and where do I send them?
Why does it not feel like a win, but like work? 
I need a list of all products. For each product I need need each ingredient with its strength, and the form. If available, also provide a list of branded products and brands, with some link to the generic version. All of this can be in the format of the Japanese. We will then convert it into our formats as concept_stage and concept_relationship_stage, and from there we have a script that will bake it in, meaning, all products and ingredients and brands are either mapped to existing ones in the db, or new ones are created. All of them, however, will exist as a separate Japanese Drug vocabulary, mapped or not.
I’m trying to understand how drugs are structured in Vocab V5 (I couldn’t find proper documentation). Here’s what I understand so far:
(Bold titles indicate the main ‘concept’, the small letters below that describe where it is stored in the vocab) Basically, you’ve thrown out the need for redundancy in RxNorm (e.g. Branded Drug Component, Branded Drug Form, etc.), and structured the strength information.
The idea would be to map the Asian drugs to existing records in these tables when possible, and when not, create new records that we’ll label ‘pseudo-RxNorm’, right? If an ingredient doesn’t exist we can use ATC concepts as ingredients (indicated in red), or we could create pseudo-RxNorm ingredient concepts (which could have mappings to ATC concepts, not shown)
I’m reviving this topic: I think we currently have over a dozen non-US drug coding systems that only have partial mappings to the vocabulary because there are no suitable standard concepts. I still agree that the approach proposed by @Christian_Reich (adding new standard drug concepts to the vocab) is the nicest solution, but I’m getting a bit worried it is not feasible. Are we close to having a process for adding the new standard concepts, or should we start thinking about a less optimal but maybe more practical solution?
I understand your reticance totally. It has been promised for a while and you are tired of waiting.
But: We made significan progress:
- We created a process. It is described here: http://www.ohdsi.org/web/wiki/doku.php?id=documentation:international_drugs
- We mapped an American drug vocabulary (which is truly mapping, no new concepts): HCPCS is now fully automated
- We created the first new RxNormized drug vocabulary: DA_France. Unfortunately it doesn’t help you, because it is an IMS database. Unless you tell Ajit to buy it. But it looks very nice. It all works: Your above schema, the concept_ancestor relationships, Dose Forms, etc. We even added packages (called boxes, because the word “Pack” is already taken in RxNorm)
- I talked to Stuart Nelson and he agreed to review what we are doing.
So, my plan was to treat the following vocabularies next:
- DPD (Canadian Drugs, very clean)
- DM+D (UK, very messy, but basis for Gemscript, which will be mapped to it)
- Your Chinese and Japanese ones
- All NDCs that have no mapping
Lots of work, but we have an automated system that does all the complexity.
Ah, sorry, I hadn’t seen that Wiki document. That helps a lot.
Just curious: I remember that at NLM we discussed the distinction between ‘RxNorm blessed’ and ‘non-blessed’ RxNorm concepts. The current version of the vocab only contains the ‘blessed’ ones. Are the non-blessed ones (which typically are used only outside of the US) going to be included in the vocab as well?
Yes. And they will behave exactly the same way as the blessed ones, so you can fine Metamizole alongside Paracetamol under NSAIDS even though it is not in RxNorm (FDA-approved).
Do you have newer versions of the Asian tables? It has been a while.
The Hong Kong data is still the same. I will send you an updated version of the Japanese data.
@Christian_Reich, I don’t see an RxNorm concept for buformin in the Jan 21, 2016 release of the vocab, even though it is in RxNorm (RxNorm ID = 1803). I thought this was one of the non-blessed ones?
It’s in the RxNorm distribution, but it is still either an NDFRT or ATC concept.
We can’t use ATC as an extension of RxNorm ingredients. First. they are ambiguous (several codes for the same molecule, see your ibuprofen problem) and there are ill-defined and combinations among them.
Buformin you will get with the new Japanese vocabulary.
And here I am again, re-opening this conversation. As @Rijnbeek is leading efforts in Europe to map the European drug codes (every European country has its own system), and others around the world are pushing to get their data in the CDM, I notice the drug mapping process has become a major bottleneck.
Again, I think the solution proposed by @Christian_Reich, giving each drug its own concept ID which encodes its ingredient(s), strength, formulation, brand, etc., is a really elegant one. However, I see evidence that it simply doesn’t scale. The vast majority of non-US coding systems still don’t have complete mapping due to the lack of standard concepts to map to. Just one example is the CPRD database, which has been around a long time and was one of the first to be mapped to the CDM. As of today, still 10% of drug exposures in CPRD are mapped to the ingredient level, including ‘Clopidogrel 75mg tablets’, simply because that concept isn’t a standard in the vocab.
I would again like to put my original proposal on the table: the drug_exposure table should have fields for the ingredient, strength, formulation, and brand. We can have a separate field that links multi-ingredient products. This will greatly simplify the drug mapping process, and actually make life easier on the analytics side as well.
Happy to entertain your proposal, but I don’t understand what problem you are trying to solve:
There is Gemscript 37822462 “Clopidogrel 75mg tablets” properly mapped to RxNorm 19075601 “clopidogrel 75 MG Oral Tablet”. What else do you need?
Ok, bad example (the clopidogrel is an ETL issue on our end). Don’t worry, I have lots more 
How about this: one of the most frequently prescribed drugs in Japan is Carbocisteine 500mg Oral Tables (Mucodyne). We currently map to ingredients, because that clinical drug is not a standard. So right now, I lose the strength, form, and brand information in the CDM. Using my proposal, I would be able to maintain all that.
While we are at it, I would like to again argue for adding dose form and route into drug era table.
@schuemie you currently map it to an ingredients, because the Japanese vocabulary hasn’t made it to OMOP yet. When it is incorporated, you’ll be able to map every drug to it’s RxNorm/RxNorm Extension counterpart without losing any of its attributes. So, you won’t need to map them by yourself, distiguish non-drugs from drugs, think about complicated cases in mapping that we face in every single vocabulary, and so on.
So does it sound like a plan to wait until the end of August, when we add it to OMOP? 
We are not at “it”, @Vojtech_Huser. Unless you have a use case, of course. We are going to solve Martijn’s (long overdue).
Hi @aostropolets, I know how in theory the problem goes away when the missing concepts get added to RxNorm Extensions. However, my argument is that that process doesn’t scale very well. it has been three years since I first provided the JMDC drug list. We have similar lists for Hong Kong, Australia, Taiwan, Korea, and at least a dozen other countries. Either we make the process for adding stuff to RxNorm Extensions a lot faster (make an upload page for proposed new RxNorm Extention concepts?), or we go with my proposal here.
Good point. First of all, it the first time I hear you need other vocabularies to be added.
And then: we have lots of work related to all of the vocabularies, not only drugs. We prioritize based on the requests, importance and so on. So what I would love is if somebody can poke us saying “hey, we do need this done! You still haven’t done much about it”…
So please share the list with the order you prefer your vocabularies to be added. We will include it in the backlog and tell you the dates we expect to deliver them, so you can track.
Here are the case when RxNorm extension doesn’t solve the problem:
We have drugs with the dosage written in relative units, something like
“bevacizumab 5 mg/kg” (kg of patient weight) and we don’t know the patient weight, And actually we don’t have to, because relative dosage is more useful for the subsequent studies to know the exact intensity of the therapy.
And of course we can’t map it to any RxNorm (Extension),
so we map it to the Clinical Drug Form. but then, how to preserve the Quantity?
We know that the patient got this 5 mg/kg daily,
so we can map to to “Bevacizumab injectable solution”, put “5” in Quantity in drug_exposure, but then it will be treated as 5 mg (“mg” is a unit in drug_strength for “bevacizumab Injectable solution”), that is wrong.
We can populate the dose_unit_source_value, but I think nobody looks there.
And again, I think there’s no such a rule: to ignore the units in drug_strength if dose_unit_source_value is populated.
So, @schuemie, your suggestion might be really helpful here. And then we can add flag how do we populate the drug_exposure: looking on the dosage from drug_strength or on the dosage from the drug_exposure,
this way the elegant way of RxNorm Extension will be used in the most of the cases, but the complicated cases will be proceeded straightforward with the dosage in drug_exposure.
@Christian_Reich, @aostropolets, @abedtash_hamed, @Alexdavv, @ericaVoss
Thoughts?