User Tools

Site Tools


documentation:next_cdm:schema_revisions

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
Last revision Both sides next revision
documentation:next_cdm:schema_revisions [2016/08/22 13:58]
frank_defalco created
documentation:next_cdm:schema_revisions [2017/12/18 00:20]
chrisknoll
Line 1: Line 1:
-===== Schema Revisions =====+===== CDM Schema Revisions ===== 
 +(needs rewriting to accommodate schemas in the specs)
  
   * Requesters: Frank DeFalco, Patrick Ryan   * Requesters: Frank DeFalco, Patrick Ryan
Line 5: Line 6:
 ---- ----
 ==== Proposal ==== ==== Proposal ====
-We propose changes to the tables included in the CDM schema in order to clarify their intent. ​ Specifically we propose ​that the the cohort, cohort_definition,​ cohort_attribute and attribute_definition tables move from the CDM specification to the results schema specification. ​ The results schema specification will be managed by a database migration package that will be developed in a separate ​GitHub repository.+We propose changes to the tables included in the CDM schema in order to clarify their intent. ​ Specifically we propose ​ 
 + 
 +  * The cohort, cohort_definition,​ cohort_attribute and attribute_definition tables move from the CDM specification to the results schema specification.  ​ 
 +  * The results schema specification will be managed by a database migration package that will be developed ​leveraging [[https://​flywaydb.org/​|Flyway]]. 
 +  * The table in the OHDSI schema named cohort_definition will be renamed as to avoid table name collision with the results schema specified cohort_definition table. 
 + 
 +== Background == 
 +The [[development:​data_architecture|OHDSI data architecture]] defines the different categories and relative schema that are used within the broader OHDSI architecture including the source (native schema), standardized (CDM schema), derived (results schema) and administrative (ohdsi schema). ​  
 + 
 +In April 2012 the [[http://​75.101.131.161/​download/​loadfile.php?​docname=CDM%20Specification%20V4.0|CDM V4 specification]] introduced the cohort table as location to store records that share a particular feature during a particular time span and defined cohorts as a group of entities exposed to a common circumstance. ​ This table has since been included as part of the DDL statements to create a CDM database. ​  
 + 
 +When the initial tool to create cohort definitions ([[documentation:​software:​circe|CIRCE]]) was introduced it introduced a new '​cohort'​ table that was found in the results schema where it would store people identified when a cohort definition is executed against a CDM database. ​  
 + 
 +Since that time many other tools have been created and new tables have appropriately been deployed in the separate ​results schema to store the data that they derive from the CDM schema. ​ This represents the fundamental issue we are seeking to resolve whereby some derived results are being stored in the CDM schema specified table and others are defined and maintained in the results schema.
  
 == Conventions == == Conventions ==
Line 11: Line 25:
  
 This is a subtle change but one that provides clear conventions for the intent of the different schemas. ​ The development of the database migration package will also provide a new and useful tool for users to be able to create the necessary tables to use OHDSI tools in a more flexible way.  This will remove the current limitation whereas the only way to create RESULTS schema tables is by installing and running the WebAPI. ​ The WebAPI will instead leverage this migration package to validate and migrate the tables required for its operation. This is a subtle change but one that provides clear conventions for the intent of the different schemas. ​ The development of the database migration package will also provide a new and useful tool for users to be able to create the necessary tables to use OHDSI tools in a more flexible way.  This will remove the current limitation whereas the only way to create RESULTS schema tables is by installing and running the WebAPI. ​ The WebAPI will instead leverage this migration package to validate and migrate the tables required for its operation.
 +
 +Additionally we propose that a convention be adopted whereby no table name is reused across any of the schemas defined in the data architecture in order to prevent collision or confusion.
  
 === Use Cases === === Use Cases ===
documentation/next_cdm/schema_revisions.txt · Last modified: 2018/02/12 20:23 by patrick_ryan