Concept ID = 0

We are currently mapping Drug data to OMOP, and have previously done Conditions and Procedures as well, and had a similar issue as to what I am about to go through.

We have a bunch of drugs, and we can’t find any valid drug concepts. Do we still copy them across to OMOP and set the Concept ID to 0, or do we not bring them across at all?
OMOP documentation at times seems to say 0 is not valid.
And by using 0, we could end up bringing millions of records across so just want to ensure that if we do set it as concept_id of 0, then there will be value and can be used even though this is not a standard concept ID.

The same situation applies for specific conditions and procedures. So what would we do in that situation?

And a slightly alternative scenario is what if we have a non-standard drug (or condition or procedure) and we cannot map to a standard drug (or condition or procedure), so would we then still map it to 0, or should we just discount it and not copy it across to OMOP?

What kind of drugs are these? Herbal remedies, over the counter medications, nutraceuticals, other? I’m concerned you have a bunch of drugs without concepts. The same applies to Conditions and Procedures.

The value in bringing unmapped data into the OMOP CDM is it is easier custom map those source values to standard concepts when they are needed for a research study. You can also use these records in SQL queries for internal uses.

The downside is the DQD will give you many errors on unmapped records and these records can’t be used in OHDSI network research.

Our data consists of data from GP, Hospitals and Prescriptions data.
But then the source data varies between sources and also varies within each dataset itself.
So for example, sometimes the data might have a Drug with a valid SNOMED code with it, so we can use it immediately. Sometimes the Drug might have an invalid SNOMED code (according to ATHENA) and when we use ATHENA’s matching, we can get a valid SNOMED code. And then sometimes we have an invalid SNOMED code, and we don’t get any matching valid SNOMED codes via ATHENA.

So what do we do when we can’t get a matching valid SNOMED Drug code? Do we still copy the data over to OMOP but set the Drug_Concept_Id as 0, or do we just not copy it over?

Thanks for the reply Melanie. What is the official HDR/OHDSI stance in this type of scenario? What do we need to do exactly? Because I completely understand that you are saying that we should bring it in, but then the documentation makes it clear that the concepts must be Standard, and Concept_Id = 0 is non-standard, hence the DQD errors. So if we bring these in, are we not going against the OHDSI standards?

Also, again following on from the above … Could we even say that when we have an invalid SNOMED drug code, and it can’t get mapped to a valid SNOMED code, then we stick with bringing in the invalid drug code and set the Drug_concept_id as an invalid SNOMED code

There is no such a thing like a valid SNOMED drug code. All drugs are either RxNorm or RxNorm Extension concepts. SNOMED drug codes are mapped to these, or, if the mapping is missing, have to be mapped to these.

Do you have an example?

@Khayam_Amin,

I don’t think you are correctly inserting your data into the OMOP CDM. A concept’s “valid” status does not determine if it can be used in the drug_concept_id field.

Besides concept_id = 0, all concept_ids in the drug_concept_id field must have standard_concept = ‘S’ and domain_id = ‘Drug’.

You should read The Book of OHDSI. And also review some of the OHDSI tutorials and EHDEN Academy. The Health Systems website has some helpful links for those who are new to OHDSI.

@MPhilofsky @Christian_Reich

Apologies, I misspoke. When I was saying Valid, I meant to say Standard. We use the ATHENA website vocab for everything as well as the DB, so what you have mentioned, I am aware of, thanks.
Feel free to read over what I said and replace Valid with Standard :slight_smile:
And thanks again for the links, and I have covered most of the literature mentioned already, hence the questions.

Just want to clarify again the question with a clear example included. If you could clarify what we are meant to do, then please do so. Hopefully I will stick to the correct terminology…

Scenario - Our source system has the following Drug concept code 430418009 (Athena) which is “Diclofenac sodium in oral dosage form”.
Looking in the DB and in ATHENA, there are no standard mappings we can use. And we have millions of records (from a large dataset) which hits a similar scenario, which is that we cannot find a Standard Drug mapping that we can use. Nothing that can be easily automated within ATHENA or via the DB.

So my question is - What do we do in this example of “Diclofenac sodium in oral dosage form”?
The options are :
1) We don’t copy it into OMOP at all because we cannot find a Standard RxNorm drug mapping
2) We still copy it over but set the Drug_Concept_Id to 0 and populate the Drug_Source_Value to 430418009 so that even though researchers will see a Drug_Concept_ID of 0, they still have the source data there to do their own mapping. But this will break DQD and goes against OHDSI documentation
3) We still copy it over but set the Drug_Concept_Id to 4328671 which is non-standard and will throw DQD errors, and goes against OHDSI documentation
4) Any alternatives you may suggest

And could you please explain whatever answer you go with, thanks.

On the other hand, as a separate example, we get a Drug concept code of 4298909 (Athena) which is Alteplase. But Alteplase DOES have a Standard mapping of Alteplace (Concept ID = 1347450) within the RxNorm dictionary which we can use. ATHENA shows this as a “Non-standard to Standard map (OMOP)” mapping
whilst the DB will have it as a “Maps to” relationship. So we can map Alteplase fine, without any problems.

Thanks again for your responses

Thank you for the clarification, @Khayam_Amin

There are a couple things you need to do.

  1. Create an issue in the Vocabulary GitHub about these deprecated concepts which don’t have a ‘maps to’ relationship. They can give you guidance on how to map these or if there is a plan to map these to standard concept_ids.

  2. Complete option #2:

Reasoning: You want to have the data available to researchers, so they can determine if they need to custom map them to standard concept_ids.

Use case for including these in the OMOP CDM: an investigator wants to run a study on persons who have been exposed to the drug Diclofenac sodium. They/you can query the drug_source_value field to identify all records which will need to be custom mapped to standard concepts before they can complete their study. This is most easily accomplished when the data are in the OMOP CDM. The DQD is also very useful in this situation because users of your CDM will know that you have an unmapped rate = ___% for the Drug domain. And your documentation (you need to document why you have the failures/errors) will let end users know they should check mapping coverage for their drug of interest.

In addition to putting the code in the drug_source_value field, I suggest you also put in the vocabulary name. Codes are not unique.

This doesn’t “break” DQD. DQD is there to inform you that not all your source values map to standard concept_ids. This is useful information. DQD is telling you to investigate these failures.

Please point out the OHDSI documentation which states to not use concept_id = 0. This is incorrect information. concept_id = 0 can be used in any concept_id field to denote an unmappable source code.

Does this help?

Perhaps I don’t understand the issue, but why are you worrying about mapping to SNOMED drug codes since they are never standard in OMOP? As @Christian_Reich pointed out you should always be mapping drugs to RxNorm or RxNorm Extension. Why wouldn’t you map “Diclofenac sodium in oral dosage form” to diclofenac sodium 75 MG Oral Tablet or similar?

Brilliant, thank you very much for clarifying and justifying @MPhilofsky. Very much appreciated.

Just some follow-up questions/comments then:

  1. It makes complete sense to mark the Concept ID as 0, so happy to do that. Currently the DQD seems to group up a single error message to cover the following 3 scenarios:
    i) Non Standard Concept ID has been used
    ii) Concept ID of 0 has been used
    iii) Concept ID belongs to a different Domain (eg a Procedure has come through for Drug Exposure)
    I am intending to raise an issue within Github to separate them. That will mean that it is clearer when we are getting the different sets of the 3 issues

  2. With regards to including the vocab name, where would you suggest that goes within OMOP?

  3. With regards to Concept ID = 0 … I think it was more implied within OHDSI documentation and DQD threw it up as a warning hence we were reluctant to use it. The OHDSI documentation says that non-standard concepts cannot be use (that is ignoring the use for a source_concept_id of course), and because 0 is a non-standard code, we didn’t want to use it. And when we did use it, DQD through it up as a failing.
    But as you have confirmed, I am happy to use Concept ID as 0, so thanks for making that clear

That was my mistake in explaining as I wasn’t concentrating exactly on what vocab the destination drug mapping was.
So just to explain, using the example above around Alteplase… ATHENA provides us the Standard mapping, but I mistakenly assumed that was SNOMED and didn’t realise it always does RxNorm. We basically follow whatever standard mapping ATHENA gives us.

To answer your question around Diclofenac sodium in oral dosage form (Athena)… Our source data has a Concept code of 430418009 (which maps to Concept ID 4328671 as above). We have created a C# application and that looks at all the vocabularies downloaded from ATHENA, which is basically the data that sits behind the ATHENA website. In this case, as you can see within ATHENA, there is no standard mapping available that would connect us to a Concept code of 430418009. We definitely don’t want to make assumptions, and even worse so, we don’t want to automate assumptions and do some kind of matching because we have thousands of drugs we process through, hence why we completely rely on ATHENA to provide us with valid mappings from SNOMED to RxNorm codes. If you are aware of any connections, then I’m open to them.

I guess my question would be …Why would we map to diclofenac sodium 75 MG Oral Tablet (Athena)? Is there an assumption that you are aware of? As in, is there a reason the same thing couldn’t be mapped to diclofenac sodium 100 MG Oral Tablet(Athena)?
We wouldn’t do either, because we don’t want to assume on a dosage.

@Khayam_Amin I think there’s a hidden assumption in your question that any source concept is automatically mappable to a standard concept via the concept_relationship table (where the Maps_to relationships are actually stored). This is an aspiration of OMOP but is not the reality today. Most sites have to perform some level of manual mapping. That’s why the “Rabbit tools” exist, including Usagi. With these tools you do perform “some kind of matching” to find the best standard concept for each of your unmapped source concepts.

You can also submit issues as @MPhilofsky suggested to expand the built-in mappings. But be aware that SNOMED mapping is probably the most complex task the vocabulary team performs and it is as automated as possible which makes it difficult or impossible to address specific concept issues.

There is also a question of whether you should be attempting to create OMOP drug_exposure records for drug administrations for which you don’t have a dose. I’m not sure what the convention is.