Fix to CDM v6.0 to add back cohort table

docs/cdm60.html

@@ -11,7 +11,7 @@
 
 
 
-<title>cdm60.utf8</title>
+<title>OMOP CDM v6.0</title>
 
 <script src="site_libs/header-attrs-2.6/header-attrs.js"></script>
 <script src="site_libs/jquery-1.11.3/jquery.min.js"></script>
@@ -518,12 +518,11 @@ div.tocify {
 
 
 
+<h1 class="title toc-ignore"><strong>OMOP CDM v6.0</strong></h1>
 
 </div>
 
 
-<div id="omop-cdm-v6.0" class="section level1">
-<h1><strong>OMOP CDM v6.0</strong></h1>
 <div id="note-about-cdm-v6.0" class="section level2">
 <h2>NOTE ABOUT CDM v6.0</h2>
 <p>Please be aware that v6.0 of the OMOP CDM is <strong>not</strong> fully supported by the OHDSI suite of tools and methods. The major difference in CDM v5.3 and CDM v6.0 involves switching the *_datetime fields to mandatory rather than optional. This switch radically changes the assumptions related to exposure and outcome timing. Rather than move forward with v6.0, CDM v5.4 was designed with additions to the model that have been requested by the community while retaining the date structure of medical events in v5.3. Please see our the specifications for <a href="http://ohdsi.github.io/CommonDataModel/cdm54.html">CDM v5.4</a> and detailed <a href="http://ohdsi.github.io/CommonDataModel/cdm54Changes.html">changes from CDM v5.3</a>. <strong>For new collaborators to OHDSI, please transform your data to <a href="https://github.com/OHDSI/CommonDataModel/releases/tag/v5.4">CDM v5.4</a> until such time that the v6 series of the CDM is ready for mainstream use.</strong></p>
@@ -13204,6 +13203,148 @@ No
 </tbody>
 </table>
 </div>
+<div id="cohort" class="section level3 tabset tabset-pills">
+<h3 class="tabset tabset-pills">COHORT</h3>
+<p><strong>Table Description</strong></p>
+<p>The COHORT table contains records of subjects that satisfy a given set of criteria for a duration of time. The definition of the cohort is contained within the COHORT_DEFINITION table. It is listed as part of the RESULTS schema because it is a table that users of the database as well as tools such as ATLAS need to be able to write to. The CDM and Vocabulary tables are all read-only so it is suggested that the COHORT and COHORT_DEFINTION tables are kept in a separate schema to alleviate confusion.</p>
+<p><strong>ETL Conventions</strong></p>
+<p>Cohorts typically include patients diagnosed with a specific condition, patients exposed to a particular drug, but can also be Providers who have performed a specific Procedure. Cohort records must have a Start Date and an End Date, but the End Date may be set to Start Date or could have an applied censor date using the Observation Period Start Date. Cohort records must contain a Subject Id, which can refer to the Person, Provider, Visit record or Care Site though they are most often Person Ids. The Cohort Definition will define the type of subject through the subject concept id. A subject can belong (or not belong) to a cohort at any moment in time. A subject can only have one record in the cohort table for any moment of time, i.e. it is not possible for a person to contain multiple records indicating cohort membership that are overlapping in time</p>
+<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
+<thead>
+<tr>
+<th style="text-align:left;">
+CDM Field
+</th>
+<th style="text-align:left;width: 3in; ">
+User Guide
+</th>
+<th style="text-align:left;width: 4in; ">
+ETL Conventions
+</th>
+<th style="text-align:left;width: 1in; ">
+Datatype
+</th>
+<th style="text-align:left;width: 1in; ">
+Required
+</th>
+<th style="text-align:left;width: 1in; ">
+Primary Key
+</th>
+<th style="text-align:left;width: 1in; ">
+Foreign Key
+</th>
+<th style="text-align:left;width: 1in; ">
+FK Table
+</th>
+<th style="text-align:left;width: 1in; ">
+FK Domain
+</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td style="text-align:left;font-weight: bold;">
+cohort_definition_id
+</td>
+<td style="text-align:left;width: 3in; ">
+</td>
+<td style="text-align:left;width: 4in; ">
+</td>
+<td style="text-align:left;width: 1in; ">
+integer
+</td>
+<td style="text-align:left;width: 1in; ">
+Yes
+</td>
+<td style="text-align:left;width: 1in; ">
+No
+</td>
+<td style="text-align:left;width: 1in; ">
+No
+</td>
+<td style="text-align:left;width: 1in; ">
+</td>
+<td style="text-align:left;width: 1in; ">
+</td>
+</tr>
+<tr>
+<td style="text-align:left;font-weight: bold;">
+subject_id
+</td>
+<td style="text-align:left;width: 3in; ">
+</td>
+<td style="text-align:left;width: 4in; ">
+</td>
+<td style="text-align:left;width: 1in; ">
+integer
+</td>
+<td style="text-align:left;width: 1in; ">
+Yes
+</td>
+<td style="text-align:left;width: 1in; ">
+No
+</td>
+<td style="text-align:left;width: 1in; ">
+No
+</td>
+<td style="text-align:left;width: 1in; ">
+</td>
+<td style="text-align:left;width: 1in; ">
+</td>
+</tr>
+<tr>
+<td style="text-align:left;font-weight: bold;">
+cohort_start_date
+</td>
+<td style="text-align:left;width: 3in; ">
+</td>
+<td style="text-align:left;width: 4in; ">
+</td>
+<td style="text-align:left;width: 1in; ">
+date
+</td>
+<td style="text-align:left;width: 1in; ">
+Yes
+</td>
+<td style="text-align:left;width: 1in; ">
+No
+</td>
+<td style="text-align:left;width: 1in; ">
+No
+</td>
+<td style="text-align:left;width: 1in; ">
+</td>
+<td style="text-align:left;width: 1in; ">
+</td>
+</tr>
+<tr>
+<td style="text-align:left;font-weight: bold;">
+cohort_end_date
+</td>
+<td style="text-align:left;width: 3in; ">
+</td>
+<td style="text-align:left;width: 4in; ">
+</td>
+<td style="text-align:left;width: 1in; ">
+date
+</td>
+<td style="text-align:left;width: 1in; ">
+Yes
+</td>
+<td style="text-align:left;width: 1in; ">
+No
+</td>
+<td style="text-align:left;width: 1in; ">
+No
+</td>
+<td style="text-align:left;width: 1in; ">
+</td>
+<td style="text-align:left;width: 1in; ">
+</td>
+</tr>
+</tbody>
+</table>
+</div>
 <div id="cohort_definition" class="section level3 tabset tabset-pills">
 <h3 class="tabset tabset-pills">COHORT_DEFINITION</h3>
 <p><strong>Table Description</strong></p>
@@ -13251,7 +13392,7 @@ This is the identifier given to the cohort, usually by the ATLAS application
 <td style="text-align:left;width: 4in; ">
 </td>
 <td style="text-align:left;width: 1in; ">
-bigint
+integer
 </td>
 <td style="text-align:left;width: 1in; ">
 Yes
@@ -13260,9 +13401,10 @@ Yes
 No
 </td>
 <td style="text-align:left;width: 1in; ">
-No
+Yes
 </td>
 <td style="text-align:left;width: 1in; ">
+COHORT
 </td>
 <td style="text-align:left;width: 1in; ">
 </td>
@@ -13429,7 +13571,6 @@ No
 </table>
 </div>
 </div>
-</div>
 
 
 

inst/csv/OMOP_CDMv6.0_Field_Level.csv

@@ -534,7 +534,11 @@ recorded. The default value is
 1-Jan-1970.",,No,No,,,,,
 DRUG_STRENGTH,valid_end_date,Yes,date,The date when then Concept became invalid.,,No,No,,,,,
 DRUG_STRENGTH,invalid_reason,No,varchar(1),"Reason the concept was invalidated. Possible values are D (deleted), U (replaced with an update) or NULL when valid_end_date has the default value.",,No,No,,,,,
-COHORT_DEFINITION,cohort_definition_id,Yes,bigint,"This is the identifier given to the cohort, usually by the ATLAS application",,No,No,,,,,
+COHORT,cohort_definition_id,Yes,integer,,,No,No,,,,,
+COHORT,subject_id,Yes,integer,,,No,No,,,,,
+COHORT,cohort_start_date,Yes,date,,,No,No,,,,,
+COHORT,cohort_end_date,Yes,date,,,No,No,,,,,
+COHORT_DEFINITION,cohort_definition_id,Yes,integer,"This is the identifier given to the cohort, usually by the ATLAS application",,No,Yes,COHORT,COHORT_DEFINITION_ID,,,
 COHORT_DEFINITION,cohort_definition_name,Yes,varchar(255),A short description of the cohort,,No,No,,,,,
 COHORT_DEFINITION,cohort_definition_description,No,varchar(MAX),A complete description of the cohort.,,No,No,,,,,
 COHORT_DEFINITION,definition_type_concept_id,Yes,integer,Type defining what kind of Cohort Definition the record represents and how the syntax may be executed.,,No,Yes,CONCEPT,CONCEPT_ID,,,

inst/csv/OMOP_CDMv6.0_Table_Level.csv

@@ -76,4 +76,5 @@ CONCEPT_ANCESTOR,VOCAB,No,,No,,,"The CONCEPT_ANCESTOR table is designed to simpl
 This table is entirely derived from the CONCEPT, CONCEPT_RELATIONSHIP and RELATIONSHIP tables.",,
 SOURCE_TO_CONCEPT_MAP,VOCAB,No,,No,,,"The source to concept map table is a legacy data structure within the OMOP Common Data Model, recommended for use in ETL processes to maintain local source codes which are not available as Concepts in the Standardized Vocabularies, and to establish mappings for each source code into a Standard Concept as target_concept_ids that can be used to populate the Common Data Model tables. The SOURCE_TO_CONCEPT_MAP table is no longer populated with content within the Standardized Vocabularies published to the OMOP community.",,
 DRUG_STRENGTH,VOCAB,No,,No,,,The DRUG_STRENGTH table contains structured content about the amount or concentration and associated units of a specific ingredient contained within a particular drug product. This table is supplemental information to support standardized analysis of drug utilization.,,
+COHORT,RESULTS,No,,No,,,The COHORT table contains records of subjects that satisfy a given set of criteria for a duration of time. The definition of the cohort is contained within the COHORT_DEFINITION table. It is listed as part of the RESULTS schema because it is a table that users of the database as well as tools such as ATLAS need to be able to write to. The CDM and Vocabulary tables are all read-only so it is suggested that the COHORT and COHORT_DEFINTION tables are kept in a separate schema to alleviate confusion.,,"Cohorts typically include patients diagnosed with a specific condition, patients exposed to a particular drug, but can also be Providers who have performed a specific Procedure. Cohort records must have a Start Date and an End Date, but the End Date may be set to Start Date or could have an applied censor date using the Observation Period Start Date. Cohort records must contain a Subject Id, which can refer to the Person, Provider, Visit record or Care Site though they are most often Person Ids. The Cohort Definition will define the type of subject through the subject concept id. A subject can belong (or not belong) to a cohort at any moment in time. A subject can only have one record in the cohort table for any moment of time, i.e. it is not possible for a person to contain multiple records indicating cohort membership that are overlapping in time"
 COHORT_DEFINITION,VOCAB,No,,No,,,"The COHORT_DEFINITION table contains records defining a Cohort derived from the data through the associated description and syntax and upon instantiation (execution of the algorithm) placed into the COHORT table. Cohorts are a set of subjects that satisfy a given combination of inclusion criteria for a duration of time. The COHORT_DEFINITION table provides a standardized structure for maintaining the rules governing the inclusion of a subject into a cohort, and can store operational programming code to instantiate the cohort within the OMOP Common Data Model.",,

rmd/cdm60.Rmd

@@ -1,4 +1,5 @@
 ---
+title: "**OMOP CDM v6.0**"
 output: 
   html_document:
       toc: true
@@ -18,8 +19,6 @@ library(stringr)
 
 ```
 
-# **OMOP CDM v6.0**
-
 ## NOTE ABOUT CDM v6.0
 
 Please be aware that v6.0 of the OMOP CDM is **not** fully supported by the OHDSI suite of tools and methods. The major difference in CDM v5.3 and CDM v6.0 involves switching the \*_datetime fields to mandatory rather than optional. This switch radically changes the assumptions related to exposure and outcome timing. Rather than move forward with v6.0, CDM v5.4 was designed with additions to the model that have been requested by the community while retaining the date structure of medical events in v5.3. Please see our the specifications for [CDM v5.4](http://ohdsi.github.io/CommonDataModel/cdm54.html) and detailed [changes from CDM v5.3](http://ohdsi.github.io/CommonDataModel/cdm54Changes.html). **For new collaborators to OHDSI, please transform your data to [CDM v5.4](https://github.com/OHDSI/CommonDataModel/releases/tag/v5.4) until such time that the v6 series of the CDM is ready for mainstream use.**