OMOP Common Data Model Version 3.0 - Open Comment Period
CDM Version 2.0 has been in production in a variety of different organizations and has shown its effectiveness for outcome research purposes. A proposed updated CDM version is based on the CDM V2.0 experiences and feedback from collaborators, and includes a number of additional tables. The CDMV2.0 was reviewed for idiosyncrasies, unused fields and other possible improvements to the existing schema, and the resulting changes have been incorporated into Version 3.0. The CDMV3.0 reflects changes to existing tables (e.g., new fields added to existing tables and obsolete tables and fields) and the addition of new tables and fields being stored in the CDM.
Review the OMOP CDMv3 Frequently Asked Questions & Answers that have been asked by the research community.
OMOP CDM Version 3 - Conceptual Model - What is New?
Click on the documents below to obtain the OMOP CDMV3.0 Specifications (Draft for Public Comment) and the CDM webinar slides presented on December 2, 2011.
- OMOP Common Data Model Specifications Version 3.0
- OMOP Common Data Model Introduction - Webinar slides, December 2, 2011
- Watch the Presentation on the OMOP site
OMOP is conducting an open comment period available until January 9, 2012. Please contact OMOP, use the add new comment section below (you need to log-in with your OMOP web account to use this feature and post comments) or send an email to: welebob@omop.org to submit your feedback.
Once the CDM is finalized, OMOP will be creating new ETL specifications for data in the central research lab, and will release open-source tools that are CDMv3-compatible
Licensed under the Apache License, Version 2.0 (the "License"); you may not use these documents except in compliance with the License. You may obtain a copy of the License at http://omop.fnih.org/publiclicense.
Disclaimer - Privacy Policy - Terms of Use - Follow us: 
Comments
drug exposure
Combination drugs are not appropriately handled in the drug exposure table. Perhaps, ingredients and strengths should be added.
Hugh Kawabata
Costs
(1) Some patients in the US are covered by some form of capitation so what the plan (insurer) pays for a particular service may be zero (the patient will still likely have co-pays, deductibles, etc.). Hence it would be useful to have an allowed amount in the cost table -- usual and customary charges for the specific area and service.
(2) Some therapeutic areas are 'carved out' of a normal insurance plan and have different benefits. There should be an indicator of whether the specific costs are for such a service.
Hugh Kawabata
Annotation and Description Field Suggestion
Do you think there may be value providing an annotation field for structured metadata (shared vocabulary, ontology) and description field for unstructured data (text description) for drug_exposure, condition occurrence, procedure_occurence, observation and cohort? These fields may enable additional analyses as new dimensions of interest are discovered.
E Acker
OMOP CDMv3 - exchange rates
Question from the Dec 2 CDM webinar: Exchange rates are varying over time for non-US countries. For cost data, should the exchange rates of the nation's currency into US dollars at the time be recorded together? Any thoughts or suggestions?
CDM V3
Please submit your comments until January 9, 2012.
Thank you.
comment
For Comparative Effectiveness, the issue of moving out of study area is important.
Without such indicator, it is not possible to distinguish (A) loss of insurance coverage and radically reduced health services utilization from (B) moving-out-of-study-area
sometimes there is a request to transfer or export medical records captured electronically so from that one might deduce that the patient is moving out of state but it is a quite hard problem to address. Unless there is a specific question to the patient or returned mail event captured.
comment
On page 41 where
place_of_service_concept_id
is described as a column. It would be helpfull to referr to the parent concept_id which holds all the possible concepts which can apear in the place_of_service_concept_id column
So the improved description might be:
A foreign key that refers to a place of service
concept identifier in the vocabulary. The parent concept_id is 123456.
This generic issue applies to many columns in the CDM.
place_of_service_concept_id
Hi Voijtech:
That's a good idea. The problem is that we would have to create those parent concepts, and keep them maintained, which is the harder job.
The way we solve that (and don't do a good job communicating) is that we limit the content by concept_class or concept_type_id. But that is a convention, the database model doesn't prevent you from, say, putting a drug concept into the place_of_service_concept_id field. If you did do that the quality checks (like GROUCH) is going to catch you.
Hope this helps.
C