mz-health/OMOP
mz-health
/
OMOP
mirror of https://github.com/OHDSI/CommonDataModel.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Updated Frequently Asked Questions (markdown)

clairblacketer 2017-12-11 09:24:56 -05:00
parent 345cfcfe4e
commit 8cc385931e
1 changed files with 50 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

50
Frequently-Asked-Questions.md

@ -73,3 +73,53 @@ In this case the standard SNOMED concept 201826 for type 2 diabetes mellitus wou
**13. Can RXNorm codes be stored in the model? Can I store multiple levels if I so choose? What if one collaborator uses a different level of RXNorm than I use when transforming their database?**
In the OMOP Common Data Model RXNorm is considered the standard vocabulary for representing drug exposures. One of the great things about the Standardized Vocabulary is that the hierarchical nature of RXNorm is preserved to enable efficient querying. It is agreed upon best practice to store the lowest level RXNorm available and then use the Vocabulary to explore any pertinent relationships. Drug ingredients are the highest-level ancestors so a query for the descendants of an ingredient should turn up all drug products (Clinical Drug or Branded Drug) containing that ingredient. A query designed in this way will find drugs of interest in any CDM regardless of the level of RXNorm used.
**14. What if the vocabulary has a mapping I don’t agree with? Can it be changed?**
Yes, that is the beauty of the community! If you find a mapping in the vocabulary that doesn’t seem to belong or that you think could be better, feel free to write a note on the [forums](https://forums.ohdsi.org/) or on the [vocabulary github](https://github.com/OHDSI/Vocabulary-v5.0/issues). If the community agrees with your assessment it will be addressed in the next vocabulary version.
**15. What if I have source codes that are specific to my site? How would these be mapped?**
We have a tool called [Usagi](https://github.com/OHDSI/Usagi) (pictured below) that is designed to create mappings between coding systems and the Vocabulary Standard Concepts by using concept names and synonyms to find potential matches.
![](https://github.com/OHDSI/CommonDataModel/blob/master/Documentation/CommonDataModel_Wiki_Files/Usagi.png)
**16. How are one-to-many mappings applied?**
If one source code maps to two Standard Concepts then two rows are stored in the corresponding clinical event table.
**17. What if I want to keep my original data as well as the mapped values? Is there a way for me to do that?**
Yes! Source values and Source Concepts are fully maintained within the OMOP Common Data Model. A Source Concept represents the code in the source data. Each Source Concept is mapped to one or more Standard Concepts during the ETL process and both are stored in the corresponding clinical event table. If no mapping is available, the Standard Concept with the concept_id = 0 is written into the *_concept_id field (Condition_concept_id, Procedure_concept_id, etc.) so as to preserve the record from the native data.
## Common Data Model Versioning
**18. Who decides when and how to change the data model?**
The community! There is a [working group](https://docs.google.com/document/d/144e_fc7dyuinfJfbYW5MsJeSijVSzsNE7GMY6KRX10g/edit?usp=sharing) designed around updating the model and everything is done by consensus. Members submit proposed changes to the [github](https://github.com/OHDSI/CommonDataModel) in the form of [issues](https://github.com/OHDSI/CommonDataModel/issues) and the group meets once a month to discuss and vote on the changes. Any ratified proposals are then added to the queue for a future version of the Common Data Model.
**19. Are changes to the model backwards compatible?**
Generally point version changes (5.1 -> 5.2) are backwards compatible and major version changes (4.0 -> 5.0) may not be. All updates to the model are listed in the release notes for each version and anything that could potentially affect backwards compatibility is clearly labeled.
**20. How frequently does the model change?**
The current schedule is for major versions to be released every year and point versions to be release every quarter though that is subject to the needs of the community.
**21. What is the dissemination plan for changes?**
Changes are first listed in the release notes on the [github](https://github.com/OHDSI/CommonDataModel/) and in the [common data model wiki](https://github.com/OHDSI/CommonDataModel/wiki). New versions are also announced on the weekly community calls and on the [community forums](https://forums.ohdsi.org).
## OHDSI Tools
**22. What are the currently available analytic tools?**
While there are a variety of tools freely available from the community, these are the most widely used:
* [ACHILLES](http://www.github.com/ohdsi/achilles) – a stand-alone tool for database characterization
* [ATLAS](http://www.ohdsi.org/web/atlas/#/home) - an integrated platform for vocabulary exploration, cohort definition, case review, clinical characterization, incidence estimation, population-level effect estimation design, and patient-level prediction design ([link to github](http://www.github.com/ohdsi/atlas))
* [ARACHNE](https://github.com/OHDSI/ArachneUI) – a tool to facilitate distributed network analyses
* [WhiteRabbit](https://github.com/OHDSI/whiterabbit) - an application that can be used to analyse the structure and contents of a database as preparation for designing an ETL
* [RabbitInAHat](https://github.com/OHDSI/whiterabbit) - an application for interactive design of an ETL to the OMOP Common Data Model with the help of the the scan report generated by White Rabbit
* [Usagi](https://github.com/OHDSI/usagi) - an application to help create mappings between coding systems and the Vocabulary standard concepts.