OHDSI Home | Forums | Wiki | Github

Does OHDSI support mappings to Value Sets and other more generic (less specific codes)?


(Gresh) #1

New to OHDSI and grateful for the OHDSI resources including the forum, Thank you!

We are looking to implement an OHDSI solution for a Datalake/Datawarehouse solution we have that has its own data model. Data in this system is from multiple sources and varies in how much of the data is coded and how it is coded. Using Rx as an example, we have data where we have RXNORM codes or NDC code in some cases. But in other cases we have only a text string and/or a mapping to a Value Set or a grouping of Value Sets that we have defined. For example in some cases we may only know that a patient is taking an Ace Inhibitor or a beta blocker and we would like to capture this.

Is there a way to use OHDSI to do each of the following:

  • Indicate that the patient is taking a medication that maps to an existing VSAC Value Set
  • Indicate that the patient is taking a medication that maps to a collection of VSAC Value Sets
  • Indicate that the patient is taking a medication that maps to a Value Set that is defined by us (i.e. can we create a Value Set internally in OHDSI and then map values to it)

A solution for this is not jumping out at me from the documentation I’m looking at here (but I am new to this and could be missing it). Is there other documentation that covers this specific topic?

https://ohdsi.github.io/CommonDataModel/cdm60.html

Thanks,
John


(Dermot Doyle) #2

HI John,

Am also new but might be able to help you in some respects.

If you have multiple datasets, and you are working on terminology or controlled vocabularies that change, there is a solution for that now (which is unique to my knowledge). See www.dynaccurate.com

I don’t think it covers everything for you, but if your DBs are relying on clinical terms (or if you want them to in the future) that would be a solution.

D


(Don Torok) #3

Initial advice is to not vary from the OMOP CDM standard. That is do not use the existing drug_concept_id as a reference to your internal value sets. If you start appropriating well define OMOP columns to you own needs you will soon end up with an uncommon CDM. However, that does not prevent you from adding attributes to a table if it meets some internal need. Using your example for Rx, you can save your Rx source code in drug_source_value. When the source code is NDC or SNOMED use the ‘Maps to’ relationship to find the standard concept id, that will go into drug_concept_id. The rules are more relaxed for the drug_source_concept_id, so that you can use concept is 723688 (ACE INHIBITORS, PLAIN) which is not a standard concept, but a classification concept (standard concept = ‘C’). If you do not find an existing concept to represent you internal Rx value sets you have the option of creating your own concepts with a concept id greater than two billion.
Using this approach will allow you to maintain a OMOP CDM that is compatible with existing OHDSI tools for QC and analysis while also meeting your specific internal needs.


(Gresh) #4

I’m still working out the details on this but there is a lot of helpful information in The Book of OHDSI (e.g. the chapters on defining cohorts and the sections on ATLAS as well as some other places). I’ll post when I’ve made more progress.


t